Dear Bhatia,
Few suggestions 1) Section 4 Key selection can be removed completely and directly we can refer to RFC 2328.Since in OSPF, Key selection is based on interface configuration. 2) Nonce can be moved to body of Hello Packet (assuming only used by Hello), No need to have in OSPF header. 3)Its better we consider OSPFv3 also since in ospfv3 Authentication trailer draft is coming up. So suggestion here is to Move the additional fields which we have added in the body of Hello packet (such as neighbor session ID and neighbor Nonce), to just before the auth payload. Since in OSPFv3 there might be a router in network who cannot understand authentication trailer and he might not process hello correctly. Just a thought. 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: Friday, January 14, 2011 7:06 AM To: [email protected] Subject: [OSPF] Security Extension for OSPFv2 when using Manual Key Management For those who are not in the KARP mailing list. > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Bhatia, Manav (Manav) > Sent: Thursday, January 13, 2011 6.13 AM > To: [email protected] > Subject: [karp] Security Extension for OSPFv2 when using > Manual Key Management > > 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 > [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
