Re: [IPsec] Avoiding Authentication Header (AH)

[RJ Atkinson <[e-mail]>]

On 02  Jan 2012, at 19:28 , Nico Williams wrote:
> On Mon, Jan 2, 2012 at 3:11 PM, RJ Atkinson <[e-mail]> wrote:
>> I gave a list earlier of a number of different scenarios where
>> and reasons why AH is used.  A subset of that list:
>>        - ESP null does not protect options/optional headers.
> 
> ESP in tunnel mode is supposed to be the replacement for AH,
> and gets you this.

Sadly, it cannot do so.  

Tunnel-mode isn't especially helpful here -- particularly 
for options or optional headers that are intended to be 
read/seen and their contents considered when forwarding 
transit IP packets.

In IPv4, ESP can't protect any IPv4 options, because the
ESP header always follows the IPv4 options.

In IPv6, there are also problems.  For example, if one has 
a Routing Header or Hop-by-Hop header then that would come 
BEFORE the ESP header -- precisely so that applicable routers 
or other middle boxes can see those headers in order to use 
their information during transit packet processing.  

>>        - ESP null cannot reliably be parsed past.
> 
> WESP is supposed to provide this.

Sadly, at present there is still no 100% reliable
method for parsing past an ESP header with NULL encryption.
There are various documents describing methods which
have various success probabilities, but none that is
100% reliable.

> Would tunnel mode be too expensive for new protocols that need
> integrity protection of outer headers?

As noted above, tunnel-mode would not solve the 
technical problem.

> In any case, if there's no way to remove AH support from existing
> implementations any time soon, then there's not much benefit to moving
> AH to Historic either.  And it's clear that the controversy that has
> arisen will take a fair bit of energy to resolve.  It may be best to
> simply publish an Informational RFC providing advice on what new
> protocols that say "use IPsec" should do.

We disagree on that.  Existing IPsec RFCs are clear enough.
If folks aren't going to read those, then they are not likely
to read any new Informational RFC either.  

Dan Harkins' analysis was spot-on, IMHO.

Yours,

Ran