Subject: [OSPF] Supporting Authentication Trailer for OSPFv3

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 15 Oct 2010 05:06:23 +0530

Hi,

We have posted the new version of this draft for the WG to review.

Changes from -00:

o Uses a new option bit (AT) present in the Hellos and DDs to indicate that the router will use an Authentication trailer in all OSPFv3 packets on that link. This will obviously be negotiated and the routers will only do this if both the routers turn on the AT bit.

o Describes where the new authentication trailer is placed wrt link local signaling (LLS) block defined in RFC5613.

o Some editorial changes.

Acee, Vishwas and Manav

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Bhatia, Manav (Manav)
> Sent: Wednesday, September 29, 2010 4.50 AM
> To: [email-masked]
> Subject: [OSPF] draft-bhatia-manral-auth-trailer-ospfv3-00.txt
> 
> 
> 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-t
> railer-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
> 
>  
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf
>

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 18 Oct 2010 14:05:50 -0400

Hi,

Though the spirit of the draft is good, I have few comments on draft-bhatia-karp-non-ipsec-ospfv3-auth-01.txt. 

1. Page 3 - Sec 1 - I saw couple of places referencing [RFC4522], LDAP?? 

2. Sec 2.2 
   I didn't understand on what exactly is the requirement that this has to be similar to OSPFv2?

3. Sec 3:
   - Mentions Key-ID is 32 bit?? But from Figure-3 it's 8 bit?
   - Do you need to consider any thing in draft-housley-saag-crypto-key-table-04.txt? It suggests 16 Bit Key-IDs
     (this could be important as in future it should be tied to AKMs for RPs?)
   - Probably, it's better to be more than  8 bit to facilitate association lkup from the DB.

4. Sec 4.1

   - Figure-3 (Reserved , instead of 0?)
   - Key-ID length inconsistency
 
5. Sec 4.2
    
   - I understand the proposal made is similar to OSPFv2 - but as this as any way new for OSPF3 does it have to be limited to HMAC-xxx?
     Can AES-XCBC-xx  be considered (to give more choice and for differentiation) 
        - not questioning HMAC-SHA-256, HMAC-SHA-384 etc..
        - as said to facilitate more options (in-built crypto accelerators)

6. Sec 4.3

   - It would be better if this sections show what is input/output to the crypto and what is authenticated through 1-2 figures?
   - Probably HMAC/crypto aspect can be as part of Appendix (..you can keep the APAD aspect here)

7. Would it be better to include IPv6 header too as part of OSPF3 packet (..not only as current available AH option  gives this protection)
   
Thanks,
Uma

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bhatia, Manav (Manav)
Sent: Thursday, October 14, 2010 4:36 PM
To: [email-masked]; [email-masked]
Subject: [OSPF] Supporting Authentication Trailer for OSPFv3

Hi,

Changes from -00:

Acee, Vishwas and Manav

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Bhatia, Manav (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.
> 
> OSPFv2 and implementations can reuse most of the existing code for 
> authenticating OSPFv2.
> 
> 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.
>

---

From: mark Brown <[email-masked]>
Date: Tue, 19 Oct 2010 04:02:00 +0530

> Though the spirit of the draft is good, I have few comments on draft-bhatia-karp-non-ipsec-ospfv3-auth-01.txt.

+1. I think its a good idea.

> 1. Page 3 - Sec 1 - I saw couple of places referencing [RFC4522], LDAP??

I suspect its a typo and the authors really meant 4552.

>   I didn't understand on what exactly is the requirement that this has to be similar to OSPFv2?

I think the requirement is just to move away from IPSec which has
proven difficult to deploy in the field.

I'll let the authors comment on the other questions.

> 7. Would it be better to include IPv6 header too as part of OSPF3 packet (..not only as current available AH option  gives this protection)

While draft-ietf-karp-threats-reqs-01.txt states that routing
protocols must protect the IP header, I dont think the WG has yet
reached a consensus on this particular issue. NOTE that this draft is
still under discussion and has not yet been finalized.

Mark

> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp
>

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 18 Oct 2010 18:56:36 -0400

>   I didn't understand on what exactly is the requirement that this has to be similar to OSPFv2?

I think the requirement is just to move away from IPSec which has proven difficult to deploy in the field.

Yeah, right. Got this. I should have been more specific.  I was  thinking as mentioned in other comments - why the AUTH_trailer/choice-of-auth-algos/auth-scope-of-the packet/etc..have to be similar to OSPFv2 as there is 
  -  no  backward compatibility issue
  -  this can well address identified/potential weaknesses in OSPFv2 auth (as seen in ip-header/src protection draft) and 
  -  future flexibility (auth type)
  -  need to anyways align to/consider auto-key-management requirements

Thanks,
Uma 

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

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 19 Oct 2010 06:26:05 +0530

Hi Uma,

Thanks for the comments.
 
> 1. Page 3 - Sec 1 - I saw couple of places referencing 

My bad - it should have been RFC 4552 - "Authentication/Confidentiality for OSPFv3".

> that this has to be similar to OSPFv2?

It isnt. We're first trying to bring it at par with OSPFv2. Once the WG agrees that its something that they would want to work on we can introduce other changes. 

>    - Mentions Key-ID is 32 bit?? But from Figure-3 it's 8 bit?

Thanks for catching this - will fix the figure in the next version.

>    - Do you need to consider any thing in 
> draft-housley-saag-crypto-key-table-04.txt? It suggests 16 Bit Key-IDs

We are suggesting a 32 bit Key ID, so I guess that would take care of this too.

>    - Figure-3 (Reserved , instead of 0?)

Yes, will do.

>    - Key-ID length inconsistency

Yup!

>  
> 5. Sec 4.2
>     
>    - I understand the proposal made is similar to OSPFv2 - 
> but as this as any way new for OSPF3 does it have to be 
> limited to HMAC-xxx?

Yes, this definitely can be done. 

Currently OSPFv2 only supports HMAC. Its in my TODO list to write a small proposal about how OSPFv2 and OSPFv3 can use AEC-XCBC-xx algorithms for authenticating their protocol packets. I don't think there's any hurry as most vendors are still implementing rfc 5709.

> 
> 6. Sec 4.3
> 
>    - It would be better if this sections show what is 
> input/output to the crypto and what is authenticated through 
> 1-2 figures?
> 7. Would it be better to include IPv6 header too as part of 
> OSPF3 packet (..not only as current available AH option  
> gives this protection)

As I said earlier, I would first like to see if the WG is interested in working on a non IPSec authentication mechanism for OSPFv3. These things that can be sorted out once we have a go-ahead.

Cheers, Manav