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

From: Vishwas Manral <[email-masked]>
Date: Fri, 1 Oct 2010 16:21:32 -0700

Hi Stephen,

Can you look at this draft further as this does not provide "Generic
Authentication Header"?

Thanks,
Vishwas

On Fri, Oct 1, 2010 at 3:50 PM, Stephen Kent <[email-masked]> wrote:
> 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
> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp
>