rfc7474v3.txt		rfc7474.txt
	skipping to change at page 2, line 24		skipping to change at page 2, line 24
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	2. Replay Protection Using Extended Sequence Numbers . . . . . . 3		2. Replay Protection Using Extended Sequence Numbers . . . . . . 3
	3. OSPF Packet Extensions . . . . . . . . . . . . . . . . . . . 4		3. OSPF Packet Extensions . . . . . . . . . . . . . . . . . . . 4
	4. OSPF Packet Key Selection . . . . . . . . . . . . . . . . . . 5		4. OSPF Packet Key Selection . . . . . . . . . . . . . . . . . . 5
	4.1. Key Selection for Unicast OSPF Packet Transmission . . . 6		4.1. Key Selection for Unicast OSPF Packet Transmission . . . 6
	4.2. Key Selection for Multicast OSPF Packet Transmission . . 7		4.2. Key Selection for Multicast OSPF Packet Transmission . . 7
	4.3. Key Selection for OSPF Packet Reception . . . . . . . . . 7		4.3. Key Selection for OSPF Packet Reception . . . . . . . . . 8
	5. Securing the IP Header . . . . . . . . . . . . . . . . . . . 8		5. Securing the IP Header . . . . . . . . . . . . . . . . . . . 8
	6. Mitigating Cross-Protocol Attacks . . . . . . . . . . . . . . 9		6. Mitigating Cross-Protocol Attacks . . . . . . . . . . . . . . 9
	7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 9		7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 10		8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	10.1. Normative References . . . . . . . . . . . . . . . . . . 11		10.1. Normative References . . . . . . . . . . . . . . . . . . 11
	10.2. Informative References . . . . . . . . . . . . . . . . . 11		10.2. Informative References . . . . . . . . . . . . . . . . . 11
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	The OSPFv2 cryptographic authentication mechanism as described in		The OSPFv2 cryptographic authentication mechanism as described in
	[RFC2328] uses per-packet sequence numbers to provide protection		[RFC2328] uses per-packet sequence numbers to provide protection
	skipping to change at page 6, line 29		skipping to change at page 6, line 29
	Assume that a router R1 tries to send a unicast OSPF packet from its		Assume that a router R1 tries to send a unicast OSPF packet from its
	interface I1 to the interface I2 of a remote router R2 using security		interface I1 to the interface I2 of a remote router R2 using security
	protocol P via interface I at time T. First, consider the		protocol P via interface I at time T. First, consider the
	circumstances where R1 and R2 are not connected with a virtual link.		circumstances where R1 and R2 are not connected with a virtual link.
	R1 then needs to select a long-lived symmetric key from its key		R1 then needs to select a long-lived symmetric key from its key
	table. Because the key should be shared by both R1 and R2 to protect		table. Because the key should be shared by both R1 and R2 to protect
	the communication between I1 and I2, the key should satisfy the		the communication between I1 and I2, the key should satisfy the
	following requirements:		following requirements:
	o The Peers field is unused. OSPF authentication is interface		o The Peers field contains the area ID or, if no key containing the
	based.		area ID is present, the string "all".
	o The Interfaces field includes the local IP address of the
	interface for numbered interfaces or the MIB-II [RFC1213] ifIndex
	for unnumbered interfaces.
	o The Direction field is either "out" or "both".		o The Direction field is either "out" or "both".
	o If multiple keys match the Interfaces field, the key with the most		o The Interfaces field matches I1 or "all".
	recent SendLifetimeStart time will be selected. This will
	facilitate graceful key rollover.		o If multiple keys match the Interface field, keys that explicitly
			match I1 should be preferred over keys matching "all". If there
			are still multiple keys that match, the key with the most recent
			SendLifetimeStart will be selected. This will facilitate graceful
			key rollover.
	o The Key ID field in the OSPFv2 header (refer to Figure 1) will be		o The Key ID field in the OSPFv2 header (refer to Figure 1) will be
	set to the selected key's LocalKeyName.		set to the selected key's LocalKeyName.
	When R1 and R2 are connected to a virtual link, the Interfaces field		When R1 and R2 are connected to a virtual link, the Peers field must
	must identify the virtual endpoint rather than the virtual link.		identify the virtual endpoint rather than the virtual link. Since
	Since there may be virtual links to the same router, the transit area		there may be virtual links to the same router, the transit area ID
	ID must be part of the identifier. Hence, the key should satisfy the		must be part of the identifier. Hence, the key should satisfy the
	following requirements:		following requirements:
	o The Peers field is unused. OSPF authentication is interface		o The Peers field includes both the virtual endpoint's OSPF router
	based.		ID and the transit area ID for the virtual link in the form of the
			transit area ID, followed by a colon, followed by the router ID.
			If no such key exists, then a key with the Peers field set to the
			transit area ID is used, followed by a key with the Peers field
			set to "all".
	o The Interfaces field includes both the virtual endpoint's OSPF		o The Interfaces field is not used for key selection on virtual
	router ID and the transit area ID for the virtual link.		links.
	o The Direction field is either "out" or "both".		o The Direction field is either "out" or "both".
	o If multiple keys match the Interfaces field, the key with the most		o If multiple keys match the Peers field, keys that explicitly match
	recent SendLifetimeStart time will be selected. This will		the router ID should be preferred, followed by keys with a transit
			area specified, followed by keys with the Peers field set to
			"all". If there are still multiple keys that match, the key with
			the most recent SendLifetimeStart will be selected. This will
	facilitate graceful key rollover.		facilitate graceful key rollover.
	o The Key ID field in the OSPFv2 header (refer to Figure 1) will be		o The Key ID field in the OSPFv2 header (refer to Figure 1) will be
	set to the selected key's LocalKeyName.		set to the selected key's LocalKeyName.
	4.2. Key Selection for Multicast OSPF Packet Transmission		4.2. Key Selection for Multicast OSPF Packet Transmission
	If a router R1 sends an OSPF packet from its interface I1 to a		If a router R1 sends an OSPF packet from its interface I1 to a
	multicast address (i.e., AllSPFRouters or AllDRouters), it needs to		multicast address (i.e., AllSPFRouters or AllDRouters), it needs to
	select a key according to the following requirements:		select a key according to the following requirements:
	o The Peers field is unused. OSPF authentication is interface		o First, try a key with the Peers field containing the area ID to
	based.		which the interface belongs. If no key exists, try a key with the
			Peers field "all".
	o The Interfaces field includes the local IP address of the		o The Interfaces field matches the interface over which the packet
	interface for numbered interfaces or the MIB-II [RFC1213] ifIndex		is sent or "all".
	for unnumbered interfaces.
	o The Direction field is either "out" or "both".		o The Direction field is either "out" or "both".
	o If multiple keys match the Interfaces field, the key with the most		o If multiple keys match the Interface field, keys that explicitly
	recent SendLifetimeStart time will be selected. This will		match I1 should be preferred over keys matching "all". If there
	facilitate graceful key rollover.		are still multiple keys that match, the key with the most resent
			SendLifetimeStart will be selected. This will facilitate graceful
			key rollover.
	o The Key ID field in the OSPFv2 header (refer to Figure 1) will be		o The Key ID field in the OSPFv2 header (refer to Figure 1) will be
	set to the selected key's LocalKeyName.		set to the selected key's LocalKeyName.
	4.3. Key Selection for OSPF Packet Reception		4.3. Key Selection for OSPF Packet Reception
	When cryptographic authentication is used, the ID of the		When cryptographic authentication is used, the ID of the
	authentication key is included in the authentication field of the		authentication key is included in the authentication field of the
	OSPF packet header. Using this Key ID, it is straight forward for a		OSPF packet header. Using this Key ID, it is straight forward for a
	receiver to locate the corresponding key. The simple requirements		receiver to locate the corresponding key. The simple requirements
	skipping to change at page 8, line 9		skipping to change at page 8, line 23
	o The interface on which the key was received is associated with the		o The interface on which the key was received is associated with the
	key's interface.		key's interface.
	o The Key ID obtained from the OSPFv2 packet header corresponds to		o The Key ID obtained from the OSPFv2 packet header corresponds to
	the neighbor's PeerKeyName. Since OSPFv2 keys are symmetric, the		the neighbor's PeerKeyName. Since OSPFv2 keys are symmetric, the
	LocalKeyName and PeerKeyName for OSPFv2 keys will be identical.		LocalKeyName and PeerKeyName for OSPFv2 keys will be identical.
	Hence, the Key ID will be used to select the correct local key.		Hence, the Key ID will be used to select the correct local key.
	o The Direction field is either "in" or "both".		o The Direction field is either "in" or "both".
			o The Peers field matches as described in Sections Section 4.1 and
			Section 4.2.
	5. Securing the IP Header		5. Securing the IP Header
	This document updates the definition of the Apad constant, as it is		This document updates the definition of the Apad constant, as it is
	defined in [RFC5709], to include the IP source address from the IP		defined in [RFC5709], to include the IP source address from the IP
	header of the OSPFv2 protocol packet. The overall cryptographic		header of the OSPFv2 protocol packet. The overall cryptographic
	authentication process defined in [RFC5709] remains unchanged. To		authentication process defined in [RFC5709] remains unchanged. To
	reduce the potential for confusion, this section minimizes the		reduce the potential for confusion, this section minimizes the
	repetition of text from RFC 5709 [RFC5709]. The changes are:		repetition of text from RFC 5709 [RFC5709]. The changes are:
	RFC 5709, Section 3.3 describes how the cryptographic authentication		RFC 5709, Section 3.3 describes how the cryptographic authentication
	skipping to change at page 11, line 34		skipping to change at page 11, line 48
	Authentication", RFC 5709, October 2009,		Authentication", RFC 5709, October 2009,
	<http://www.rfc-editor.org/info/rfc5709>.		<http://www.rfc-editor.org/info/rfc5709>.
	10.2. Informative References		10.2. Informative References
	[FIPS-198]		[FIPS-198]
	"US National Institute of Standards and Technology, "The		"US National Institute of Standards and Technology, "The
	Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB		Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB
	198-1, July 2008.		198-1, July 2008.
	[RFC1213] McCloghrie, K. and M. Rose, "Management Information Base
	for Network Management of TCP/IP-based internets: MIB-II",
	STD 17, RFC 1213, March 1991,
	<http://www.rfc-editor.org/info/rfc1213>.
	[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-		[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
	Hashing for Message Authentication", RFC 2104, February		Hashing for Message Authentication", RFC 2104, February
	1997, <http://www.rfc-editor.org/info/rfc2104>.		1997, <http://www.rfc-editor.org/info/rfc2104>.
	[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model		[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model
	(USM) for version 3 of the Simple Network Management		(USM) for version 3 of the Simple Network Management
	Protocol (SNMPv3)", STD 62, RFC 3414, December 2002,		Protocol (SNMPv3)", STD 62, RFC 3414, December 2002,
	<http://www.rfc-editor.org/info/rfc3414>.		<http://www.rfc-editor.org/info/rfc3414>.
	[RFC4222] Choudhury, G., Ed., "Prioritized Treatment of Specific		[RFC4222] Choudhury, G., Ed., "Prioritized Treatment of Specific
	skipping to change at page 13, line 40		skipping to change at page 13, line 40
	Sam Hartman		Sam Hartman
	Painless Security		Painless Security
	EMail: hartmans-ietf@mit.edu		EMail: hartmans-ietf@mit.edu
	Dacheng Zhang		Dacheng Zhang
	Huawei Technologies Co., Ltd.		Huawei Technologies Co., Ltd.
	Beijing		Beijing
	China		China
	EMail: dacheng.zdc@alibaba-inc.com		EMail: dacheng.zhang@gmail.com
	Acee Lindem (editor)		Acee Lindem (editor)
	Cisco		Cisco
	United States		United States
	EMail: acee@cisco.com		EMail: acee@cisco.com
End of changes. 15 change blocks.
	36 lines changed or deleted		43 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/