Hi Acee, Is it reasonable to assume that the router will never reboot (crash, upgrade and maintenance, etc). If it is then i believe this is a better alternative and the authors should consider this.
Glen On Sat, Jan 22, 2011 at 5:22 AM, Acee Lindem <[email protected]> wrote: > 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 > > _______________________________________________ > karp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/karp > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
