< draft-ietf-ospf-security-extension-manual-keying-09.txt		draft-ietf-ospf-security-extension-manual-keying-10.txt >
	OSPF Working Group M. Bhatia		OSPF Working Group M. Bhatia
	Internet-Draft Ionos Networks		Internet-Draft Ionos Networks
	Intended status: Standards Track S. Hartman		Intended status: Standards Track S. Hartman
	Expires: April 9, 2015 Painless Security		Expires: April 29, 2015 Painless Security
	D. Zhang		D. Zhang
	Huawei Technologies co., LTD.		Huawei Technologies co., LTD.
	A. Lindem		A. Lindem, Ed.
	Cisco		Cisco
	October 6, 2014		October 26, 2014
	Security Extension for OSPFv2 when using Manual Key Management		Security Extension for OSPFv2 when using Manual Key Management
	draft-ietf-ospf-security-extension-manual-keying-09		draft-ietf-ospf-security-extension-manual-keying-10
	Abstract		Abstract
	The current OSPFv2 cryptographic authentication mechanism as defined		The current OSPFv2 cryptographic authentication mechanism as defined
	in RFC 2328 and RFC 5709 is vulnerable to both inter-session and		in RFC 2328 and RFC 5709 is vulnerable to both inter-session and
	intra-session replay attacks when using manual keying. Additionally,		intra-session replay attacks when using manual keying. Additionally,
	the existing cryptographic authentication mechanism does not cover		the existing cryptographic authentication mechanism does not cover
	the IP header. This omission can be exploited to carry out various		the IP header. This omission can be exploited to carry out various
	types of attacks.		types of attacks.
	skipping to change at page 1, line 47 ¶		skipping to change at page 1, line 47 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on April 9, 2015.		This Internet-Draft will expire on April 29, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	skipping to change at page 2, line 29 ¶		skipping to change at page 2, line 29 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Requirements Section . . . . . . . . . . . . . . . . . . . 3		1.1. Requirements Section . . . . . . . . . . . . . . . . . . . 3
	1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 4		1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 4
	2. Replay Protection using Extended Sequence Numbers . . . . . . 4		2. Replay Protection using Extended Sequence Numbers . . . . . . 4
	3. OSPF Packet Extensions . . . . . . . . . . . . . . . . . . . . 5		3. OSPF Packet Extensions . . . . . . . . . . . . . . . . . . . . 5
	4. OSPF Packet Key Selection . . . . . . . . . . . . . . . . . . 6		4. OSPF Packet Key Selection . . . . . . . . . . . . . . . . . . 6
	4.1. Key Selection for Unicast OSPF Packet Transmission . . . . 7		4.1. Key Selection for Unicast OSPF Packet Transmission . . . . 7
	4.2. Key Selection for Multicast OSPF Packet Transmission . . . 8		4.2. Key Selection for Multicast OSPF Packet Transmission . . . 8
	4.3. Key Selection for OSPF Packet Reception . . . . . . . . . 8		4.3. Key Selection for OSPF Packet Reception . . . . . . . . . 8
	5. Securing the IP header . . . . . . . . . . . . . . . . . . . . 9		5. Securing the IP header . . . . . . . . . . . . . . . . . . . . 9
	6. Mitigating Cross-Protocol Attacks . . . . . . . . . . . . . . 9		6. Mitigating Cross-Protocol Attacks . . . . . . . . . . . . . . 10
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 10		7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 11		9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
	9.2. Informative References . . . . . . . . . . . . . . . . . . 12		9.2. Informative References . . . . . . . . . . . . . . . . . . 12
	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
	against replay attacks. The sequence numbers increase monotonically		against replay attacks. The sequence numbers increase monotonically
	so that attempts to replay stale packets can be thwarted. The		so that attempts to replay stale packets can be thwarted. The
	sequence number values are maintained as a part of neighbor adjacency		sequence number values are maintained as a part of neighbor adjacency
	skipping to change at page 6, line 40 ¶		skipping to change at page 6, line 40 ¶
	| |		| |
	~ Authentication Data ~		~ Authentication Data ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1 - Extended Sequence Number Packet Extensions		Figure 1 - Extended Sequence Number Packet Extensions
	4. OSPF Packet Key Selection		4. OSPF Packet Key Selection
	This section describes how the proposed security solution selects		This section describes how the proposed security solution selects
	long-lived keys from key tables. [I-D.ietf-karp-crypto-key-table].		long-lived keys from key tables. [RFC7210]. In this context, we are
	Generally, a key used for OSPFv2 packet authentication should satisfy		selecting the key and corresponding Security Association (SA) as
	the following requirements:		defined in section 3.2 of [RFC5709]. Generally, a key used for
			OSPFv2 packet authentication should satisfy the following
			requirements:
	o For packet transmission, the key validity interval as defined by		o For packet transmission, the key validity interval as defined by
	SendLifetimeStart and SendLifetimeEnd must include the current		SendLifetimeStart and SendLifetimeEnd must include the current
	time.		time.
	o For packet reception, the key validity interval as defined by		o For packet reception, the key validity interval as defined by
	AcceptLifetimeStart and AcceptLifetimeEnd must include the current		AcceptLifetimeStart and AcceptLifetimeEnd must include the current
	time.		time.
	o The key must be valid for the desired security algorithm.		o The key must be valid for the desired security algorithm.
	skipping to change at page 11, line 38 ¶		skipping to change at page 11, line 43 ¶
	This document requests a new code point from the "OSPF Shortest Path		This document requests a new code point from the "OSPF Shortest Path
	First (OSPF) Authentication Codes" registry:		First (OSPF) Authentication Codes" registry:
	o 3 - Cryptographic Authentication with Extended Sequence Numbers.		o 3 - Cryptographic Authentication with Extended Sequence Numbers.
	This document also requests a new code point from the "Authentication		This document also requests a new code point from the "Authentication
	Cryptographic Protocol ID" registry defined under "Keying and		Cryptographic Protocol ID" registry defined under "Keying and
	Authentication for Routing Protocols (KARP) Parameters":		Authentication for Routing Protocols (KARP) Parameters":
	o 2 - OSPFv2.		o TBD (3 Suggested) - OSPFv2.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.		[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
	[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M.,		[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M.,
	Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic		Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic
	Authentication", RFC 5709, October 2009.		Authentication", RFC 5709, October 2009.
	9.2. Informative References		9.2. Informative References
	[FIPS-198]		[FIPS-198]
	US National Institute of Standards & Technology, "The		US National Institute of Standards & Technology, "The
	Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB		Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB
	198 , March 2002.		198 , March 2002.
	[I-D.ietf-karp-crypto-key-table]
	Housley, R., Polk, T., Hartman, S., and D. Zhang,
	"Database of Long-Lived Symmetric Cryptographic Keys",
	draft-ietf-karp-crypto-key-table-10 (work in progress),
	December 2013.
	[RFC1213] McCloghrie, K. and M. Rose, "Management Information Base		[RFC1213] McCloghrie, K. and M. Rose, "Management Information Base
	for Network Management of TCP/IP-based internets:MIB-II",		for Network Management of TCP/IP-based internets:MIB-II",
	STD 17, RFC 1213, March 1991.		STD 17, RFC 1213, March 1991.
	[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,		Hashing for Message Authentication", RFC 2104,
	February 1997.		February 1997.
	[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
	skipping to change at page 13, line 10 ¶		skipping to change at page 13, line 13 ¶
	Routing Protocols", RFC 6094, February 2011.		Routing Protocols", RFC 6094, February 2011.
	[RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and		[RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and
	Authentication for Routing Protocols (KARP) Overview,		Authentication for Routing Protocols (KARP) Overview,
	Threats, and Requirements", RFC 6862, March 2013.		Threats, and Requirements", RFC 6862, March 2013.
	[RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security		[RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security
	According to the Keying and Authentication for Routing		According to the Keying and Authentication for Routing
	Protocols (KARP) Design Guide", RFC 6863, March 2013.		Protocols (KARP) Design Guide", RFC 6863, March 2013.
			[RFC7210] Housley, R., Polk, T., Hartman, S., and D. Zhang,
			"Database of Long-Lived Symmetric Cryptographic Keys",
			RFC 7210, April 2014.
	Authors' Addresses		Authors' Addresses
	Manav Bhatia		Manav Bhatia
	Ionos Networks		Ionos Networks
	Bangalore,		Bangalore,
	India		India
	Phone:		Phone:
	Email: manav@ionosnetworks.com		Email: manav@ionosnetworks.com
	skipping to change at page 13, line 35 ¶		skipping to change at page 13, line 42 ¶
	Dacheng Zhang		Dacheng Zhang
	Huawei Technologies co., LTD.		Huawei Technologies co., LTD.
	Beijing,		Beijing,
	China		China
	Phone:		Phone:
	Fax:		Fax:
	Email: zhangdacheng@huawei.com		Email: zhangdacheng@huawei.com
	URI:		URI:
	Acee Lindem		Acee Lindem (editor)
	Cisco		Cisco
	USA		USA
	Phone:		Phone:
	Email: acee@cisco.com		Email: acee@cisco.com
End of changes. 13 change blocks.
	20 lines changed or deleted		19 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/