Re: AH or ESP

[Jack Kohn <kohn.jack () gmail com>]

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 <kaeo () merike com> 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 <kohn.jack () gmail com> 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 <kaeo () merike com> 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 <glen.kent () gmail com>
> > > > > wrote:
> > > > >
> > > > >  Yes, thats what i had meant !
> > > > > > On Fri, May 22, 2009 at 10:46 PM, Christopher Morrow
> > > > > > <morrowc.lists () gmail com> wrote:
> > > > > >
> > > > > >
> > > > > > > On Fri, May 22, 2009 at 1:04 PM, Glen Kent <glen.kent () gmail com>
> > > > > > > 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