Re: [IPsec] Avoiding Authentication Header (AH)

[RJ Atkinson <[e-mail]>]

On 02  Jan 2012, at 10:16 , Bhatia, Manav (Manav) wrote:

> [clipped]
> 
>> Most major IPv6 routers, for example multiple product lines from both Cisco 
>> and Juniper, also support AH in shipping product and have done for some while now.  
>> So AH remains a very widely available protocol.
> 
> It may be widely available, but clearly it isnt as widely used.

Use of AH to protect OSPFv3 is not uncommon within
the set of sites that deploy OSPFv3.  It provides
protections that no other mechanism can provide,
for example it can be used to detect options-based
attacks.

> You might also be interested in the following draft which will be published as RFC any time now:
> http://tools.ietf.org/html/draft-ietf-ospf-auth-trailer-ospfv3-11

I am well aware of it.  That document does NOT deprecate 
use of AH with OSPFv3 either.

>> 	- Some IPv6 profiles, including the US Government
>> 	  profile for IPv6, require AH support either generally
>> 	  or in certain situations (example: to protect OSPFv3,
>> 	  to authenticate certain IP options or IP extension
>> 	  headers).
> 
> Just trying to understand. Is there a reason why ESP-NULL cant be used?

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 null cannot reliably be parsed past.

>> This WG ought not make existing legitimate uses of AH invalid or not recommended.  
> 
> What makes you think that this draft is trying to do that?

The text in your two drafts on the topic.

>> There is no available alternative for authenticating IP-layer options, extension headers, and so forth.  
>> AH is the only available way to do such authentication at present.
> 
> If you include the ESP header before the extension headers can you not use it to authenticate the extension headers?

That isn't possible, for various reasons.  

For IPv4, options always appear before the ESP header.

For IPv6, there are multiple reasons, including but not
limited to:
	- There still is no 100% reliable way to parse past an
	  ESP NULL header 
	-- IPv6 has strict rules on the order of headers
	   and an ESP NULL header can't appear before either 
	   a Routing Header or a Hop-by-Hop Options Header 
	   because those two header types need to be 100% readable 
	   by routers handling the IPv6 packet.


>> FIREWALLS & MIDDLEBOXES:
>> 
>> While this WG has produced some documents with guidance on how to approach parsing 
>> past an ESP header when NULL encryption is used, we still do not have a completely 
>> reliable way to parse past an ESP header when NULL encryption is used.  
> 
> And pray why is that?

The existing documents' methods aren't 100% reliable.
I wish they were, but they aren't.

Yours,

Ran