Re: [IPsec] Avoiding Authentication Header (AH)

[Tero Kivinen <[e-mail]>]

Bhatia, Manav (Manav) writes:
> > There is no evidence of any recent change either to the operational 
> > circumstances or to the available alternatives.  So no update is
> > appropriate at this time. 
> 
> One major recent change is the publication of WESP [RFC 5840] and
> the standard for using Heuristics for detecting ESP-NULL packets
> [RFC 5879].  
> 
> This takes away one major reason why folks wanted to use AH - that
> of being able to deep inspect packets. 
> 
> Even the NIST guidelines for IPv6 deployment says that the main
> argument in favor of AH is the ability to inspect packets. With WESP
> even that goes away. 

Getting WESP implemented to the boxes will require a lot of time.
There are still lots of boxes which do not even support IKEv2 (which
is required for WESP) and IKEv2 has been out for 6 years already. AH
might already be implemented on some boxes, so using it might offer
faster deployment time than WESP. The only *protocol* benefit WESP
have over AH is that it works through NATs.

As I see it the main reason AH is now MAY, not MUST, is that there has
not been that much use for it, and that has caused it to be as second
class citizen in the VPN driven IPsec work. Because of that testing
etc has been somewhat ommitted. For example most of the
interoperability events has concentrated ESP testing, and only very
briefly done some AH testing (if there has been extra time).

Because quite a lot of IPsec development have been driven by the VPN
vendors, who do not have use for AH (or WESP), those vendors have seen
the previous mandatory to implment AH, as unnecessary burden for their
implementations. Thats why degrading it to MAY was good way forward in
the RFC4301.

This does not mean there is no use for AH in some environments. I
personally (at least now) think that it would have been more useful to
just say use AH than to create WESP (and heuristics) at all... That
would have given some use cases for AH, which would have then perhaps
moved it back to used track in the IPsec protocol family.

I myself think there is no reason to say anything about AH at this
point. It is MAY, so nobody needs to implement it. Every new protocol
using IPsec should consider whether they want to use ESP, ESP-NULL,
WESP, or AH and make their own decisions based on what would be best
for that environment and protocol. I.e if you require confidentiality
then you needs to use ESP, if you require transport mode outer IP
option protection you need to use AH, otherwise you can pick any of
them...

If you want to make sure other protocols do not unnecessarely specify
AH for their use, you should just participate in writing those
specifications and explain why do you think AH should be avoided in
that environment. 
-- 
[e-mail]