Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3

From: Alan Davey <[email-masked]>
Date: Thu, 28 Oct 2010 11:05:42 +0100

Folks

Sorry for the delay in sending this email, but I have read the draft-bhatia-manral-auth-trailer-ospfv3-01 and I have some doubts and questions.  I have listed these below, together with a minor editorial nit that I noticed as I went through the draft.

Please let me know your thoughts.

Regards

Alan

Alan Davey
Software Engineer, Network Technologies Division
Metaswitch Networks
[email-masked]<mailto:[email-masked]>
+44 (0) 20 8366 1177
www.metaswitch.com<http://www.metaswitch.com/>

Comments and questions.

1.  Section 2.1 AT-Bit in Options Field,  states that "OSPFv3 routers MUST set the AT-bit in OSPFv3 Hello and Database Description packets to indicate that the OSPFv3 router will include the authentication trailer in all OSPFv3 packets on the link".  I would expect that local configuration would indicate that the authentication trailer must be included in all OSPFv3 packets on the link.  Use of the authentication trailer would not be a matter for negotiation between OSPFv3 neighbors, as was mentioned in previous emails on the subject.  Do you agree?

2.  In fact I have a doubt as to whether the AT-bit is required.  Can the presence or otherwise of the authentication trailer provide the same meaning as an AT-bit?

3.  Section 2.2, paragraph 2; s/its/it is/

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 28 Oct 2010 16:12:47 +0530

Hi Alan,
 
I have removed KARP from the CC as the questions are not related to the security mechanisms discussed in the draft. Please find my comments inline:

> 1.  Section 2.1 AT-Bit in Options Field,  states that "OSPFv3 
> routers MUST set the AT-bit in OSPFv3 Hello and Database Description 
> packets to indicate that the OSPFv3 router will include 
> the authentication trailer in all OSPFv3 packets on the link".  
> I would expect that local configuration would indicate that 
> the authentication trailer must be included in all OSPFv3 packets on 
> the link.  Use of the authentication trailer would not be a matter 
> for negotiation between OSPFv3 neighbors, as was mentioned in previous 
> emails on the subject.  Do you agree?

You need this bit for the receiving end to verify the authentication data that's being carried in the trailer. Also, it is a matter of negotiation in the sense that you may still have some routers in your network that don't understand this extension. Also refer to my comments below.

> 2.  In fact I have a doubt as to whether the AT-bit is required.  
> Can the presence or otherwise of the authentication trailer 
> provide the same meaning as an AT-bit?

This would be an issue in the presence of an LLS block in the HELLOs or the DDs. How would the receiving router know that what follows the OSPFv3 protocol packet is an Authentication trailer and not an LLS block? This one could argue, can be fixed by putting the trailer after the LLS block, as then the incoming router would be able to reach the right offsets. However, this requires all implementations that want to support Auth trailer to also provide some minimal support for LLS (at least the packet parsing bit) so that it can reach the right offsets. This we thought was an overkill, which can be fixed trivially by explicitly signaling the presence of an Authentication trailer.

> 3.  Section 2.2, paragraph 2; s/its/it is/

Sure, will fix that.

Thanks for the review!

Cheers, Manav