Re: [OSPF] Supporting Authentication Trailer for OSPFv3

["Bhatia, Manav (Manav)" <[e-mail]>]

Hi Uma,

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

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

> 
> 2. Sec 2.2 
>    I didn't understand on what exactly is the requirement 
> 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. 

> 
> 3. Sec 3:
>    - 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
>      (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.

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

> 
> 4. Sec 4.1
> 
>    - 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?
>      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)

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?
>    - 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)

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

>    
> Thanks,
> Uma