AH or ESP

Tue May 26 04:03:55 UTC 2009

IPsec as a whole is compliance mandatory for IPv6 although for new  
version of IPv6 Node requirements that came out recently I think they  
changed that to a 'SHOULD'.  Wireless devices (phones) have issues  
with battery life when IPsec implemented.  Note that all standards  
say ESP-Null is 'MUST' (mandatory-to-implement ) algorithm and AH is  
a 'MAY' support.

Yep.....integrity was specifically decoupled due to export  
restrictions on cryptography technologies used for encryption - the  
restrictions do not apply for just authentication/integrity  
cryptography.  Hence AH and ESP.   ESP-Null came about when folks  
realized AH could not traverse NATs.

- merike

On May 25, 2009, at 8:26 PM, Jack Kohn wrote:

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