Subject: Re: [karp] draft-bhatia-manral-auth-trailer-ospfv3-00.txt

From: Stephen Kent <[email-masked]>
Date: Fri, 1 Oct 2010 18:50:07 -0400

At 4:50 AM +0530 9/29/10, Bhatia, Manav (Manav) wrote:
>Hi,
>
>Proposing another mechanism for doing non Ipsec authentication for 
>OSPFv3. In this proposal the OSPFv3 authentication information is 
>appended to the OSPFv3 packet and is not considered a part of the 
>protocol payload; it is instead included in the IPv6 packet's 
>payload length.
>
>The mechanism described is very similar to how it is done for OSPFv2 
>and implementations can reuse most of the existing code for 
>authenticating OSPFv2.
>
>So whats the difference between this and the 
>draft-bhatia-karp-non-ipsec-ospfv3-auth-01.txt?
>
>The main difference is that the latter introduces a new IPv6 
>extension header that can be used by all protocols that want to use 
>non IPSec security. The main issue that I see is that while it is 
>generic I don't see too many applications that might want to use 
>this. The advantage of the new mechanism is that its restricted to 
>OSPFv3 and is also backward compatible. Implementations that don't 
>support this extension can continue to ignore this trailer attached 
>to the OSPFv3 payload.
>
>The other difference is regarding the code reusability. In the new 
>mechanism (Authentication Trailer) very little new code needs to be 
>added, while the earlier (Generic Authentication Header) mechanism 
>would require new source code to be added.
>
>Would be great if the WG can review this document!
>
>Cheers, Manav

Manav,

The IETF already has a protocol that operates at the IP layer, in v6,
that provides integrity and authenticity: Ipsec/ESP-NULL (also AH, but that is
generally deprecated now) in the IPsec context So, if you want to 
propose the "Generic Authentication Header" for general use, it will 
be evaluated relative to the extant, standard solution, in the 
general context, not just the OSPFv3 context.

As your document notes, WESP allows for easy differentiation between 
encrypted and non-encrypted (authenticated-only) traffic, so that is 
not a distinguishing feature of the proposal you documented, in 
environments where this distinction is needed.

Your proposal calls for Key ID that also specifies the algorithm used 
for authentication, as well as a key. It says that this value is 
manually configured for each OSPFv3 SA, which makes this description 
specific to this protocol, not generic. Also, this is very limited 
capability compared to the functionality provided by IPsec/ESP-NULL, 
especially if IKE (v1 or v2) is used for SA management. The 
description of Key Id also suggests a specific key management method 
(a key chain) that is not generic. (It may be appropriate for the 
OSPFv3 environment, but it is much less capable than what IPsec and 
IKE offer).

The description of the integrity algorithm is also very restrictive. 
We found it useful in IPsec to define specific algorithms in a 
separate doc, a model I think you should consider for your proposal, 
even if it this protocol were considered only in the OSPFv3 context.

The anti-reply feature of your proposal describes recovery from 
counter warp-around in an OSPFv3-specific fashion. Thus that aspect 
of the protocol would need to be redesigned for it to be generally 
applicable. (Also, this procedure is noted in 4.1, but not in the 
more detailed discussion of what a sender and a receiver do for 
packet processing. Those sections need to reflect this approach
to dealing with counter wrap, and would need to define a mechanism 
that is not protocol-specific.) I also wonder if router vendors and 
ISPs will find it acceptable to have an OSPF link die as a 
side-effect of counter wrap.

Overall I don't think the "Generic Authentication Header" merits 
consideration as an alternative to IPsec/ESP-NULL in a broad context, 
based on what you have written.

Steve

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sat, 2 Oct 2010 04:59:05 +0530

Hi Stephen,

You have reviewed draft-bhatia-karp-non-ipsec-ospfv3-auth-01, but you have replied to a mail that is for draft-bhatia-manral-auth-trailer-ospfv3-00.txt. These are two different drafts (though the end goal in both is the same).

The former, the one that you have reviewed, introduces a new Generic Authentication Header that lies between the IPv6 main header the Upper protocol payload (in this case OSPFv3). I realize that there are issues with it, which is why we (Vishwas and I) came out with the other proposal that's very specific to OSPFv3 - draft-bhatia-manral-auth-trailer-ospfv3-00.txt.

Would be great if you can review draft-bhatia-manral-auth-trailer-ospfv3-00.txt and then provide feedback.

Cheers, Manav

> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]] 
> Sent: Saturday, October 02, 2010 4.20 AM
> To: Bhatia, Manav (Manav)
> Cc: [email-masked]
> Subject: Re: [karp] draft-bhatia-manral-auth-trailer-ospfv3-00.txt
>