Hmm .. besides this, AH is *never* export restricted. Also, i could
be mistaken, but isnt AH compliance mandatory in IPv6?
Earlier there were some issues in using ESP with TCP performance
enhancement proxies used in wireless networks, which couldnt deep
inspect the ESP packets to extract TCP flow IDs and seq numbers,
but that should all change with the new WESP proposal.
Jack
On Tue, May 26, 2009 at 8:21 AM, Merike Kaeo <[email protected]> wrote:
Coming from someone who is somewhat jaded.....politics.
Realistically there are some folks who believe that not having the
IP header (and with v6 also the option headers) integrity protected
is an issue. It's not. You have more risk of operation issues
from adding complexity of AH.....note that the fields that are
modified in transit in the headers are NOT included in the
integrity protection. So it really becomes an issue of is the IP
address protected and basically, yes that's done via IKE and the
way security associations work anyhow. [if you change IP address of
header you will not have appropriate security association match]
Once the technology is there to quickly differentiate ESP-Null from
ESP-encrypted packets the argument of "but you can inspect AH
packets" becomes irrelevant.
- merike
On May 25, 2009, at 5:23 PM, Glen Kent wrote:
Just a quick question: Why do we need AH when we have ESP-NULL? Is AH
now being supported only for legacy reasons? The only negative with
ESP-NULL afaik was that it could not be filtered (since packets could
not be inspected), however, this changes with the "wesp" proposal.
Also, the fact that AH is NAT unfriendly should be the final nail in
its coffin.
Any reasons why we still see it around?
Thanks,
Glen
On Tue, May 26, 2009 at 5:44 AM, Jack Kohn <[email protected]>
wrote:
Not really.
Currently, you cant even look at the ESP trailer to determine if
its an
encrypted or an integrity protected packet, because the trailer
itself could
be encrypted.
A router, by reading the next-header field from the ESP trailer can
never be
sure that its an OSPFv3 packet inside since it wouldnt know whether
the
packet is encrypted or not. One could have an encrypted packet
inside, for
which the next-header field turns out to be 89, but that may not
necessarily
mean that its an OSPFv3 packet. It could be a VoIP packet that just
happens
to look like OSPFv3 once encrypted. There is no indication sent on
the wire
that says that the packet is encrypted.
So, there is no way to identify/deep inspect/filter ESP packets unless
you're the recipient, which imo is the root cause of all heart burn
in the
intermediate devices like firewalls, transit routers, etc.
A couple of solutions were thrown at the WG and the current one
(wesp) was
selected as the best.
I agree that we should just throw out AH and stick to one protocol
which has
been extensively tested. A quick scan through some of vendors data
sheets
quickly reveals that most of them dont even provide support for AH.
Jack
On Tue, May 26, 2009 at 2:33 AM, Merike Kaeo <[email protected]> wrote:
Yeah - the main issue with using ESP is that there's a trailer at
end of
packet that tells you more info to determine whether you can
inspect the
packet. So you have to look at the end of the packet to see
whether ESP is
using encryption or null-encryption (i.e. just integrity
protection). Some
vendors do have proprietary mechanisms in software for now which
doesn't
scale. The work below will hopefully lock into a solution where hw
can be
built to quickly determine if ESP is used for integrity only.
AH is not really widely used (except for OSPFv3 since early
implementations
locked in on AH when the standard said to use IPsec for integrity
protection). Note that a subsequent standard now exists which
explicitly
states that ESP-Null MUST be supported and AH MAY be supported.
But how
many folks are actually running OSPF for a v6 environment and using
IPsec to
protect the communicating peers? Some but not many (yet).
Personally, I'd stick with ESP. AH complicates matters
(configuration,
nested environments when you do decide to also use ESP for
encryption maybe
later, NAT) and while is isn't officially deprecated vendors don't
test it
as much as ESP - at interoperability tests it's not stressed, at
least the
ones I've been to. Ask your vendor(s) what they think of the work
below and
see where they stand with implementing it.
Be happy to answer any more questions offline.
- merike
On May 25, 2009, at 6:24 AM, Jack Kohn wrote:
Glen,
IPSECME WG <http://www.ietf.org/html.charters/ipsecme-charter.html> at
IETF
is actually working on the exact issue that you have described
(unable to
deep inspect ESP-NULL packets).
You can look at
draft-ietf-ipsecme-traffic-visibility-02<http://tools.ietf.org/html/
draft-ietf-ipsecme-traffic-visibility-02>for
more details.
Jack
On Sat, May 23, 2009 at 5:06 AM, Glen Kent <[email protected]>
wrote:
Yes, thats what i had meant !
On Fri, May 22, 2009 at 10:46 PM, Christopher Morrow
<[email protected]> wrote:
On Fri, May 22, 2009 at 1:04 PM, Glen Kent <[email protected]>
wrote:
Hi,
It is well known in the community that AH is NAT unfriendly while ESP
cannot
be filtered, and most firewalls would not let such packets pass. I am
NOT
'the content of the esp packet can't be filtered in transit' I think
you mean... right?
interested in encrypting the data, but i do want origination
authentication
(Integrity Protection). Do folks in such cases use AH or ESP-NULL,
given
that both have some issues?
Thanks,
Glen
