Hi Anton, We are updating the security in OSPFv2 as well with draft-ietf-ospf-security-extension-manual-keying-05.txt. This a different mechanism but it is where we ultimately want to get.
Thanks, Acee On Oct 8, 2013, at 7:46 AM, Anton Smirnov wrote: > Hi Acee, > RFC 6506 inherited this property from RFC 5709 which has this text word for > word: > >> In the event that the last key associated >> with an interface expires, it is unacceptable to revert to an >> unauthenticated condition, and not advisable to disrupt routing. >> Therefore, the router should send a "last Authentication Key >> expiration" notification to the network manager and treat the key as >> having an infinite lifetime until the lifetime is extended, the key >> is deleted by network management, or a new key is configured. > > To me this property looks wrong from security point of view and in general I > would agree to have it removed. OTOH difference between v2 and v3 specs is > highly undesirable, so if RFC 6506 is changed so that this property is > dropped (or made optional) then at the same time we should evaluate how the > same change can be pushed into RFC 5709. > > Anton > > > > > > > On 10/08/2013 12:35 AM, Acee Lindem wrote: >> Hi Mike, >> I agree and don't see why this one configuration error should be handled >> explicitly when there are many other possible errors. Actually, I'd looked >> at this text before and meant to address it since I'd never implement this. >> I'll discuss with the other authors. >> Thanks, >> Acee >> >> On Oct 7, 2013, at 6:19 PM, Mike Dubrovskiy (mdubrovs) wrote: >> >>> Hi Acee, >>> >>> I like the change but we currently have the following text in rfc6506 >>> >>> "In the event that the last key associated >>> with an interface expires, it is unacceptable to revert to an >>> unauthenticated condition and not advisable to disrupt routing. >>> Therefore, the router SHOULD send a "last Authentication Key >>> expiration" notification to the network operator and treat the key as >>> having an infinite lifetime until the lifetime is extended, the key >>> is deleted by the network operator, or a new key is configured." >>> >>> The above text is difficult to apply to Accept keys. It should be either >>> deleted >>> or modified. >>> >>> Thank you, >>> Mike >>> >>>> -----Original Message----- >>>> From: [email protected] [mailto:[email protected]] On Behalf Of >>>> Acee Lindem >>>> Sent: Monday, October 07, 2013 1:25 PM >>>> To: OSPF List >>>> Subject: [OSPF] One more RFC 6506BIS Clarification >>>> >>>> One more thing I intend to add is explicit specification that the OSPFv3 >>>> packet >>>> should be dropped if the Security Association isn't found or has expired. >>>> The >>>> text is analogous to the original RFC 2328 Appendix D text. This will be >>>> added >>>> to section 4.6. >>>> >>>> *************** >>>> *** 976,981 **** >>>> --- 976,986 ---- >>>> and the IPv6 header length is less than the amount necessary to >>>> include an Authentication Trailer. >>>> >>>> + Locate the receiving interface's OSPFv3 SA using the SA ID in the >>>> + received AT. If the SA is not found, or if the SA is not valid for >>>> + reception (i.e., current time < KeyStartAccept or current time >= >>>> + KeyStopAccept), the OSPFv3 packet is dropped. >>>> + >>>> If the cryptographic sequence number in the AT is less than or equal >>>> to the last sequence number in the last OSPFv3 packet of the same >>>> OSPFv3 type successfully received from the neighbor, the OSPFv3 >>>> >>>> Although I would hope no one would complain about this since it was always >>>> implied in section 3 (see excerpt below), please speak now if you have any >>>> concerns. >>>> >>>> o Security Association Identifier (SA ID) >>>> >>>> This is a 16-bit unsigned integer used to uniquely identify an >>>> OSPFv3 SA, as manually configured by the network operator. >>>> >>>> The receiver determines the active SA by looking at the SA ID >>>> field in the incoming protocol packet. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> OSPF mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/ospf >> _______________________________________________ >> OSPF mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/ospf > > _______________________________________________ > OSPF mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
