Hi Acee, I think the idea behind this logic was for the purposes of backward compatibility. I agree that this is not right if *all* routers support the AT capability. However, if you have even one router that does not support this, then you would probably need this mechanism.How would an implementation, that is AT incapable, send an OSPFv3 + LLS block to a router, if the receiving end always implicitly assumes the presence of an authentication trailer? One could argue that if the AT router has turned ON authentication then it MUST only accept packets with the AT block, but then we are taking a giant leap of faith where we're assuming that ALL routers will simultaneously turn on the AT mechanism.
If folks think that this opens a security hole, then vendors could add a knob that could toggle this behavior. By default, the knob could assume the presence of an authentication trailer if auth has been turned on. The second state would be where authentication trailer is assumed to be present only if the AT bit is set. If folks agree to this, then we could add a note about this in the next revision. Cheers, Manav ________________________________ From: Acee Lindem [mailto:[email protected]] Sent: Wednesday, January 19, 2011 4.34 PM To: Rajesh Shetty Cc: Bhatia, Manav (Manav); [email protected] Subject: Re: [OSPF] AT Bit Hi Rajesh, You are correct. I thought that this was in the draft but see that it is not. Right, we should drop packets with the AT Bit clear when authentication is configured on the receiving side. OSPFv3 will drop packets not containing the options field (LS-Request, LS-Update, and Ack) if the adjacency is not in Exchange state or higher. Thanks, Acee On Jan 19, 2011, at 5:19 AM, Rajesh Shetty wrote: Dear All, AT Bit Definition: AT bit must be set in all ospfv3 protocol packets that contain an authentication trailer. On the receiving side authentication trailer is only examined if AT bit is set. Consider a scenario where authentication trailer draft is supported by all the routers and authentication is configured on receiving side but not on sending side. Even in this scenario receiving side will successfully accept the packet (Since AT bit is not set), this is a security threat. Please correct me if I am missing something. Thanks Rajesh This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Acee Lindem Sent: Friday, January 07, 2011 8:39 PM To: Bhatia, Manav (Manav) Cc: [email protected]<mailto:[email protected]>; Vishwas Manral Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 Actually I was just making sure everyone was paying attention :^) Since I'm an author, I'll validate with Abhay and Stewart but I think we can move forward and make this a WG document. Thanks, Acee On Jan 6, 2011, at 8:46 PM, Bhatia, Manav (Manav) wrote: > I am sure Acee meant that the he and the authors would like to see this draft > adopted up as a WG draft. > > I agree with that sentiment and would request this to be accepted as a WG > document. We've had several mails in the past where this work was supported > and none that was against. > > Cheers, Manav > >> -----Original Message----- >> From: Acee Lindem [mailto:[email protected]] >> Sent: Friday, January 07, 2011 2.11 AM >> To: [email protected]<mailto:[email protected]> >> Cc: Bhatia, Manav (Manav); Vishwas Manral >> Subject: Supporting Authentication Trailer for OSPFv3 >> >> Speaking as WG Co-Chair: >> >> At the last OSPF WG meeting, there was some interest in this >> draft. I'm now asking for opinions for and against. >> >> Speaking as a WG member: >> >> The authors (myself included) would not like to make this a >> WG draft. On the OSPF list and at the OSPF WG meeting, the >> only dissent was on along the lines of making IPsec >> (including IKEv2) work better with OSPFv3 rather than doing >> this. I don't disagree that this should be a goal but I don't >> think it should preclude this work. >> >> Thanks, >> Acee _______________________________________________ OSPF mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
