Hi Manav, Michael, On Jan 19, 2011, at 8:15 PM, Bhatia, Manav (Manav) wrote:
> Hi Michael, > >> OSPFv2 is the way it is because of the order in which features where >> introduced, in order to maintain backward compatibility, not because >> anyone thought this was the best way to authenticate LLS. I think we > > Yes. > >> should not follow a precedence which is poor. IMHO the right >> way to do >> this for v3 is to have one authentication block for the >> OSPFv3 packet as >> well as the LLS block. > > I don't have a very strong opinion either ways. Would like to hear what > others think about this. > >> >>> 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 have a hard time believing that is a real issue. If the AT followed >> the LLS block, it would be pretty trivial find the length of the LLS >> block and calculate the position of the AT. > > Which means that they would have to add minimal code to support understanding > the "L" bit in the Options field and adding the parsing code so that they can > reach the start of the AT. I would not be against mandating support of LLS parsing for OSPFv3 AT support. It is as simple as examining the L-bit and bypassing the LLS block to get to the AT. > >>> 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. >> >> If the fields are including in the initial definition, even if unused >> then it will ease implementation later. Let's please at least reserve >> space for them in the AT. > > Just reserving space for the Nonce and the Session ID in the AT may not be > enough, as you would need to do something for your neighbors too. So, while > we could reserve some space in the AT, that may still not be good enough when > we get about fixing the manual keying for OSPFv3. > > I suggest that we leave out these details now. If we make a good progress in > the karp draft by the time this draft is ready for IESG we could certainly > add the required fields as you have suggested. > draft-bhatia-karp-ospf-ip-layer-protection is still an individual submission > and I would not like to change things here based on what has been proposed > there! Agreed. Thanks, Acee > > Cheers, Manav > >> >> Thanks, >> Michael >> >>> 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
