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 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! Cheers, Manav > > Thanks, > Michael > > > Cheers, Manav > > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
