Hi Manav, I've finally read this draft and I'm less enamored with it than Michael. I think the requirement to protect the source address is valid. However, I think the assumptions regarding sequence number management which are used to justify the challenge/nouce are flawed. If you tie the sequence number to the clock (which I'd guess most rational implementations already do), then there is no reason for this nouncense :^). Even with a 32 sequence number, one could increment it every 1/10 second and get 13.3 years since the last cold boot. If you were willing to live with 1 second between sequence number increments, you'd get 133 years. Furthermore, since a new auth type will be required to protect the source address, the sequence number could also be extended to 64 bits to allow for greater precision.
Thanks, Acee On Jan 13, 2011, at 11:59 PM, Michael Barnes wrote: > Hello Manav, > > First I want to applaud you and your co-authors for addressing these security > problems for OSPF. Thank you. > > I have some initial questions and comments. > > During the challenge and response are the hello packets sent immediately to > each other or by the standard hello timer? > > During the challenge and response on a broadcast links, are the packets > unicast or multicast? > > Regarding the new format for hello packets, is this format to be used only > during challenge and response, or for all hello packets when this new form of > authentication is enabled? > > RFC2328 defines the AuType field, you've chosen to rename it to AuthType. I > suggest we continue to use AuType for continuity. > > In the figures which illustrate the header and hello packet fields, I suggest > that instead of showing two words as just "Authentication" that the figure > shows the sub-fields. In the context of this specification those words will > have a single definition, so there is no reason to leave them loosely defined. > > Please describe how LLS will be covered using this new authentication type. > > Regards, > Michael > > > On 01/12/2011 04:43 PM, Bhatia, Manav (Manav) wrote: >> Hi, >> >> Sam, Dacheng and I have written a small draft attempting to fix the issues >> that exist when using OSPFv2 with manual keying. It introduces two >> additional variables - the Nonce and the Session ID, that need to be >> maintained per neighbor, that will, we believe, fix most issues that >> currently exist as described in RFC 6039. >> >> As per the KARP design guide we first need to fix the manual keying before >> we move to a fully automated key management system for the routing >> protocols. This draft attempts to address the first part, i.e., fixes the >> issues that exist when using manual keying for OSPF. >> >> It would be great to hear the feedback from the WG. >> >> http://www.ietf.org/id/draft-bhatia-karp-ospf-ip-layer-protection-01.txt >> >> Cheers, Manav >> >> -- >> Manav Bhatia, >> IP Division, Alcatel-Lucent, >> Bangalore - India >> >> >> _______________________________________________ >> karp mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/karp >> > _______________________________________________ > OSPF mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
