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
