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

From: mark Brown <[email-masked]>
Date: Fri, 1 Oct 2010 22:35:37 +0530

Manav,

Unlike OSPFv2, we are still left with plenty of OSPFv3 options in the v3 header.

http://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtml#ospfv3-parameters-1

You could easily take up an option bit from there which would indicate
that an Authentication trailer has been appended to the OSPFv3 packet
- This would obviate the need for routers to implicitly deduce that
the packet is carrying the authentication trailer that you have
described in your draft.

This also helps when someone is using link local signalling with OSPFv3.

I btw find this mechanism more amenable than defining a new IPv6
extension header that you had proposed earlier.

Mark

On Wed, Sep 29, 2010 at 4:50 AM, Bhatia, Manav (Manav)
<[email-masked]> 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
>
> ----- Forwarded Message ----
> From: "[email-masked]" <[email-masked]>
> To: [email-masked]
> Sent: Tue, September 28, 2010 11:15:01 PM
> Subject: I-D ACTION:draft-bhatia-manral-auth-trailer-ospfv3-00.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>    Title        : Supporting Authentication Trailer for OSPFv3
>    Author(s)    : M. Bhatia, V. Manral
>    Filename    : draft-bhatia-manral-auth-trailer-ospfv3-00.txt
>    Pages        : 12
>    Date        : 2010-9-28
>
> Currently OSPFv3 uses IPsec for authenticating the protocol
>      packets. There however are some environments (mobile ad-hoc),
>      where IPsec is difficult to configure and maintain, and this
>      mechanism cannot be used. This draft proposes an alternative
>      mechanism that can be used so that OSPFv3 does not depend upon
>      IPsec for security.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-bhatia-manral-auth-trailer-ospfv3-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> --
> Manav Bhatia,
> IP Division, Alcatel-Lucent,
> Bangalore - India
>
>
>
> --
> Manav Bhatia,
> IP Division, Alcatel-Lucent,
> Bangalore - India
>
>
> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp
>

---

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

Hi Mark,

Thanks for the review.

We could certainly use the OSPFv3 option bit to explicitly indicate that an Authentication trailer has been appended. We will also add some text in the next version about how this would work with link local signaling. The LLS block will come between the OSPFv3 protocol payload and the Authentication trailer.

And thanks for the support!

Cheers, Manav 

> -----Original Message-----
> From: mark Brown [mailto:[email-masked]] 
> Sent: Friday, October 01, 2010 10.36 PM
> To: Bhatia, Manav (Manav)
> Cc: [email-masked]
> Subject: Re: [karp] draft-bhatia-manral-auth-trailer-ospfv3-00.txt
> 
> Manav,
> 
> > 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.
> >