Hi Michael, > First I want to applaud you and your co-authors for addressing these > security problems for OSPF. Thank you.
Thanks Mike! > > 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? I think it should be done immediately without waiting for the Hello timer to expire. > > During the challenge and response on a broadcast links, are > the packets > unicast or multicast? 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? This has to be used *all* the time. > > RFC2328 defines the AuType field, you've chosen to rename it to > AuthType. I suggest we continue to use AuType for continuity. Sure, will do that. > > 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. It's a typo. We need to remove the two fields shown as Authentication from the two figures! > > Please describe how LLS will be covered using this new > authentication type. This extension has no bearing on the LLS since LLS isnt really a part of the OSPF payload. Its length is not included in the length of the OSPF packet, but is included in the IPv4 packet length. Is there something specific that you are looking at? And thanks for your comments! Cheers, Manav > > 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-protect > ion-01.txt > > > > Cheers, Manav > > > > -- > > Manav Bhatia, > > IP Division, Alcatel-Lucent, > > Bangalore - India > > > > > > _______________________________________________ > > karp mailing list > > k...@ietf.org > > https://www.ietf.org/mailman/listinfo/karp > > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
