Re: [IPsec] Avoiding Authentication Header (AH)

[RJ Atkinson <[e-mail]>]

On 02  Jan 2012, at 19:51 , Bhatia, Manav (Manav) wrote:
> It doesn't need to because nobody uses it.

I know of multiple sites who have it deployed today.

> The reason the above draft exists is because there were
> many people (at least service providers) who said that
> they did NOT want to use IPsec for OSPFv3.

More precisely, a few service providers and a few vendors 
said this.  Major vendors had already shipped the capability,
and numerous users had deployed it.  

Unfortunately, the IETF has long-standing challenges with 
getting users/operators, especially enterprise/academic/
government users, to participate in its WGs.

Service providers are overwhelmingly using IS-IS for IPv6, 
not OSPFv3, in any event.

> I am sure you have customers who love using IPsec for OSPFv3,
> but there is a larger percentage that doesn't.

One of my clients operates a multi-continent IP network.
I also have non-ISP clients.  You acknowledge that you 
have no contact with the IPsec for OSPFv3 users.
So, by your own admission, I have more data than you do.

We disagree on the percentages.

> Routing Header is a security nightmare.
> You were probably not aware that it has been recently deprecated by the IETF.
> 
> http://tools.ietf.org/html/rfc5095

Actually, the IPv6 Routing Header itself is not deprecated.
Only the RH Type 0 was deprecated by RFC-5095.

IANA.org reports the Type 2 and Type 3 IPv6 Routing 
Headers remain valid and are not deprecated (Type 3 
is work in progress, but allocated already).

> From the draft-bhatia-ipsecme-avoiding-ah-00:
> 
>   Hop-by-Hop options are not an issue, as the intermediate
>   hops do not have keys to verify the message authentication
>   code so they cannot really be protected anyways.

That claim isn't true either.  

Please consider deployments where the intermediate hops 
DO have those keys, obtained for example from a KDC.  
The IETF has standardised Kerberos, for example, so
a standards-based solution exists in this area.

Separately, RFC-4359 specifies how one can use 
RSA/SHA-1 signatures within AH.  So it is entirely
possible to give a middle box a verification key --
without also giving the middle box a signing key
for the traffic being protected.

I'm not going to write the I-D for you, nor am I going
to waste my time enumerating every single problem
with the draft.  There are too many technical flaws
and it would take too long.  I can't improve upon 
Dan Harkins' explanation of why trying to fix the 
I-D is a waste of time and energy.

Yours,

Ran