Re: [IPsec] Avoiding Authentication Header (AH)

["Bhatia, Manav (Manav)" <[e-mail]>]

[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.

Are you suggesting that newer protocols should mandate AH or they should be proposing extensions to AH? I think all we're saying is that newer protocols should suggest extensions to ESP-NULL wherever possible. They must have a good reason to suggest mandating AH. What is the problem with this?

>	- Many IPv6 deployments using OSPFv3 have enabled
>	  OSPFv3 protection using AH.  Most router vendors,
>	  including (for example) multiple product lines 
>	  from both Cisco and Juniper, shipped this capability 
>	  long ago -- and this use of AH is both interoperable 
>	  and widespread, largely within IPv6 enterprise
>	  deployments.  OSPFv3 itself is largely deployed in
>	  enterprises today, as I/IS-IS is more popular with
>	  ISPs.

The RFC that describes OSPFv3 authentication has the following line:

In order to provide authentication to OSPFv3, implementations MUST support ESP and MAY support AH.

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

>
>	  [NOTE WELL:  AH for OSPFv3 has NOT been deprecated, and
>	  remains on the IETF standards track.  It is interesting,
>	  however, that author of this AH draft is trying to kill 
>	  off the use of AH to protect routing information -- 
>	  apparently because his employer does not offer this 
>	  AH for OSPFv3 capability in its released products.]

Really? I would like to try whatever you've been smoking.

>	- 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?

> 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?

> 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?

> 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?

Manav