Dear Manav, I agree with all the points mentioned by you in the below mail. Only problem if we put AT before LLS is, there might exist a router in the network who supports LLS but not AT (less probability). He will not be able to decode LLS correctly when packet arrives with AT and LLS. Compatibility need to support for AT as well as LLS this seems to be a issue.
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]] On Behalf Of Bhatia, Manav (Manav) Sent: Thursday, January 20, 2011 5:22 AM To: Michael Barnes; [email protected] Cc: Acee Lindem Subject: Re: [OSPF] AT Bit Hi Michael, The design was kept this way since this is how it is done in OSPFv2. Besides getting rid of IPsec the idea is also to bring OSPFv3 at par with OSPFv2 and we would like both the protocols to behave in a similar fashion. In v2, the Auth data precedes the LLS block and there is a separate TLV that carries authentication data for the LLS block. I think we should do the same for the sake of consistency between the two protocols. The other idea behind putting AT before LLS was that if we did it the other way round, then implementations would NOT be able to support AT till they had at least minimal code that could understand and parse the LLS block. We didn't want that to happen as chances of seeing nodes supporting AT over LLS are higher. I think we can include another subsection that defines a Cryptographic Authentication TLV for LLS that could be used for OSPFv3. Alternately, we could respin a one page draft that updates rfc 5613, and permits the existing crypto auth TLV to be used for OSPFv3 as well. I would personally prefer the latter approach as its cleaner to keep these things separate. I don't think we should include the Session ID and Nonce here. That work will be done in KARP and it will take a looooooooong time before we finalize on a scheme that fixes OSPF authentication when using manual keying. Secondly, this draft is about bringing OSPFv3 auth at par with OSPFv2, since operators are using auth with v2 and are NOT doing it with v3. Implementing the AT draft is a matter of a few days, however, if you bring in the Session and the Nonce thing here, then we have already pushed it to a few years. I don't think we should wait for that long. Cheers, Manav > -----Original Message----- > From: Michael Barnes [mailto:[email protected]] > Sent: Wednesday, January 19, 2011 11.18 PM > To: [email protected]; Bhatia, Manav (Manav) > Cc: Acee Lindem > Subject: Re: [OSPF] AT Bit > > Hi Manav, > > I think that the authentication trailer should follow the LLS > and should > secure LLS as well as the other OSPF data. Even if an implementation > doesn't want to completely support LLS, I think it is reasonable to > require that in order to support the AT extension it can know how to > find the AT when there is an LLS block. > > I would also like to see this draft include similar Session > ID and Nonce > as defined in > draft-bhatia-karp-ospf-ip-layer-protection-01.txt although > perhaps make > it an optional feature. > > Thanks, > Michael > > On 01/19/2011 04:05 AM, Bhatia, Manav (Manav) wrote: > > > > 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 > > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
