< draft-ietf-karp-threats-reqs-06.txt		draft-ietf-karp-threats-reqs-07.txt >
	KARP Working Group G. Lebovitz		KARP Working Group G. Lebovitz
	Internet-Draft		Internet-Draft
	Intended status: Informational M. Bhatia		Intended status: Informational M. Bhatia
	Expires: March 31, 2013 Alcatel-Lucent		Expires: June 22, 2013 Alcatel-Lucent
	September 27, 2012		B. Weis
			Cisco Systems
			December 19, 2012
	Keying and Authentication for Routing Protocols (KARP) Overview,		Keying and Authentication for Routing Protocols (KARP) Overview,
	Threats, and Requirements		Threats, and Requirements
	draft-ietf-karp-threats-reqs-06		draft-ietf-karp-threats-reqs-07
	Abstract		Abstract
	Different routing protocols employ different mechanisms for securing		Different routing protocols employ different mechanisms for securing
	protocol packets on the wire. While most already have some method		protocol packets on the wire. While most already have some method
	for accomplishing cryptographic message authentication, in many cases		for accomplishing cryptographic message authentication, in many cases
	the existing methods are dated, vulnerable to attack, and employ		the existing methods are dated, vulnerable to attack, and employ
	cryptographic algorithms that have been deprecated. The "Keying and		cryptographic algorithms that have been deprecated. The "Keying and
	Authentication for Routing Protocols" (KARP) effort aims to overhaul		Authentication for Routing Protocols" (KARP) effort aims to overhaul
	and improve these mechanisms.		and improve these mechanisms.
	skipping to change at page 2, line 11 ¶		skipping to change at page 2, line 13 ¶
	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 March 31, 2013.		This Internet-Draft will expire on June 22, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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
	skipping to change at page 7, line 19 ¶		skipping to change at page 7, line 19 ¶
	and identity authentication mechanism are used in the system. A		and identity authentication mechanism are used in the system. A
	peer key generally would be provided by a KMP and would later be		peer key generally would be provided by a KMP and would later be
	used to derive fresh traffic keys.		used to derive fresh traffic keys.
	PSK (Pre-Shared Key)		PSK (Pre-Shared Key)
	A key used to communicate with one or more peers in a secure		A key used to communicate with one or more peers in a secure
	configuration. Always distributed out-of-band prior to a first		configuration. Always distributed out-of-band prior to a first
	connection.		connection.
			Replayed Messages
			Replayed messages are genuine messages that have been re-sent by
			an attacker. Messages may be replayed within a session (i.e.,
			intra-session) or replayed from a different session (i.e., inter-
			session). For non-TCP based protocols like OSPF [RFC2328], IS-IS
			[RFC1195], etc., two routers are said to have a session up if they
			are able to exchange protocol packets (i.e., the peers have an
			adjacency). Messages replayed during an adjacency are intra-
			session replays while message replayed between two peers who re-
			establish an adjacency after a reboot or loss of connectivity are
			inter-session replays.
	Routing Protocol		Routing Protocol
	When used with capital "R" and "P" in this document the term		When used with capital "R" and "P" in this document the term
	refers the Routing Protocol for which work is being done to its		refers the Routing Protocol for which work is being done to its
	packets on the wire.		packets on the wire.
	SA (Security Association)		SA (Security Association)
	A relationship established between two or more entities to enable		A relationship established between two or more entities to enable
	them to protect data they exchange. Examples of attributes that		them to protect data they exchange. Examples of attributes that
	skipping to change at page 11, line 36 ¶		skipping to change at page 11, line 36 ¶
	be measured by how deployable the solution is by operator teams,		be measured by how deployable the solution is by operator teams,
	with consideration for their deployment processes and		with consideration for their deployment processes and
	infrastructures. Specifically, KARP design teams will try to		infrastructures. Specifically, KARP design teams will try to
	make these solutions fit as well as possible into current		make these solutions fit as well as possible into current
	operational practices and router deployment methodologies. Doing		operational practices and router deployment methodologies. Doing
	so will depend heavily on operator input during KARP design		so will depend heavily on operator input during KARP design
	efforts. Hopefully, operator input will lead to a more		efforts. Hopefully, operator input will lead to a more
	deployable solution, which will, in turn, lead to more production		deployable solution, which will, in turn, lead to more production
	deployments. Deployment of incrementally more secure routing		deployments. Deployment of incrementally more secure routing
	infrastructure in the Internet is the final measure of success.		infrastructure in the Internet is the final measure of success.
	Measurably, in reports like [ISR2008], we would like to see an		We would like to see an increase in the number of respondents to
	increase in the number of surveyed respondents who report		surveys such as [ISR2008] to report deploying the updated
	deploying the updated authentication and integrity mechanisms in		authentication and integrity mechanisms in their networks, as
	their networks, as well as a sharp rise in usage for the total		well as see a sharp rise in usage for the total percentage of
	percentage of their network's routers.		their network's routers.
	Interviews with operators show several points about routing		Interviews with operators show several points about routing
	security. First, according to [ISR2008], over 70% of operators		security. First, according to [ISR2008], over 70% of operators
	have deployed transport connection protection via TCP-MD5		have deployed transport connection protection via TCP-MD5
	[RFC3562] on their exterior Border Gateway Protocol (eBGP)		[RFC3562] on their exterior Border Gateway Protocol (eBGP)
	sessions. Over 55% also deploy TCP-MD5 on their interior Border		sessions. Over 55% also deploy TCP-MD5 on their interior Border
	Gateway Protocol (iBGP connections, and 50% make use of TCP-MD5		Gateway Protocol (iBGP) connections, and 50% make use of TCP-MD5
	offered on some other internal gateway protocol (IGP). The same		offered on some other internal gateway protocol (IGP). The same
	survey states that "a considerable increase was observed over		survey states that "a considerable increase was observed over
	previous editions of the survey for use of TCP MD5 with external		previous editions of the survey for use of TCP MD5 with external
	peers (eBGP), internal peers (iBGP) and MD5 extensions for IGPs."		peers (eBGP), internal peers (iBGP) and MD5 extensions for IGPs."
	Though the data is not captured in the report, the authors		Though the data is not captured in the report, the authors
	believe anecdotally that of those who have deployed TCP-MD5		believe anecdotally that of those who have deployed TCP-MD5
	somewhere in their network, only about 25-30% of the routers in		somewhere in their network, only about 25-30% of the routers in
	their network are deployed with the authentication enabled. None		their network are deployed with the authentication enabled. None
	report using IPsec [RFC4301] to protect the routing protocol, and		report using IPsec [RFC4301] to protect the routing protocol, and
	this was a decline from the few that reported doing so in the		this was a decline from the few that reported doing so in the
	skipping to change at page 13, line 44 ¶		skipping to change at page 13, line 44 ¶
	for TCP-AO, for as many other routing protocols with similar		for TCP-AO, for as many other routing protocols with similar
	characteristics and properties as possible.		characteristics and properties as possible.
	8. Bridge any gaps between IETF Routing and IETF Security Areas by		8. Bridge any gaps between IETF Routing and IETF Security Areas by
	recording agreements on work items, roadmaps, and guidance from		recording agreements on work items, roadmaps, and guidance from
	the cognizant Area Directors and the Internet Architecture Board		the cognizant Area Directors and the Internet Architecture Board
	(IAB).		(IAB).
	2.4. Non-Goals		2.4. Non-Goals
	The following two goals are considered out-of-scope for this effort:		The following goals are considered out-of-scope for this effort:
	o Confidentiality of the packets on the wire. Once this roadmap is		o Confidentiality and non-repudiation of the packets on the wire.
	realized, we may revisit work on confidentiality.		Once this roadmap is realized, work on confidentiality may be
			considered.
			o Non-repudiation of the packets on the wire.
	o Message content validity (routing database validity). This work		o Message content validity (routing database validity). This work
	is being addressed in other IETF efforts. For example, BGP		is being addressed in other IETF efforts. For example, BGP
	message content validity is being addressed in the SIDR working		message content validity is being addressed in the SIDR working
	group.		group.
	2.5. Audience		2.5. Audience
	The audience for this document includes:		The audience for this document includes:
	skipping to change at page 20, line 9 ¶		skipping to change at page 20, line 9 ¶
	A. NOT FORWARDING PACKETS - cannot be prevented with		A. NOT FORWARDING PACKETS - cannot be prevented with
	cryptographic authentication. Note: If sequence numbers with		cryptographic authentication. Note: If sequence numbers with
	sliding windows are used in the solution (as is done, for		sliding windows are used in the solution (as is done, for
	example, in BFD [RFC5880]), a receiver can at least detect the		example, in BFD [RFC5880]), a receiver can at least detect the
	occurrence of this attack.		occurrence of this attack.
	B. DELAYING MESSAGES - cannot be prevented with cryptographic		B. DELAYING MESSAGES - cannot be prevented with cryptographic
	authentication. Note: Timestamps can be used to detect		authentication. Note: Timestamps can be used to detect
	delays.		delays.
	C. DENIAL OF RECEIPT - cannot be prevented with cryptographic		C. DENIAL OF RECEIPT (non-repudiation) - cannot be prevented with
	authentication		cryptographic authentication
	D. UNAUTHORIZED MESSAGE CONTENT - the work of the IETF's SIDR		D. UNAUTHORIZED MESSAGE CONTENT - the work of the IETF's SIDR
	working group		working group
	(http://www.ietf.org/html.charters/sidr-charter.html).		(http://www.ietf.org/html.charters/sidr-charter.html).
	E. DoS attacks not involving the routing protocol. For example,		E. DoS attacks not involving the routing protocol. For example,
	a flood of traffic that fills the link ahead of the router, so		a flood of traffic that fills the link ahead of the router, so
	that the router is rendered unusable and unreachable by valid		that the router is rendered unusable and unreachable by valid
	packets is NOT an attack that KARP will address. Many such		packets is NOT an attack that KARP will address. Many such
	examples could be contrived.		examples could be contrived.
	skipping to change at page 21, line 42 ¶		skipping to change at page 21, line 42 ¶
	3. Algorithm agility for the cryptographic algorithms used in the		3. Algorithm agility for the cryptographic algorithms used in the
	authentication MUST be specified, and protocol specifications		authentication MUST be specified, and protocol specifications
	MUST be clear how new algorithms are specified and used within		MUST be clear how new algorithms are specified and used within
	the protocol. This requirement exists because research		the protocol. This requirement exists because research
	identifying weaknesses in cryptographic algorithms can cause the		identifying weaknesses in cryptographic algorithms can cause the
	security community to reduce confidence in some algorithms.		security community to reduce confidence in some algorithms.
	Breaking a cipher isn't a matter of if, but when it will occur.		Breaking a cipher isn't a matter of if, but when it will occur.
	Having the ability to specify alternate algorithms (algorithm		Having the ability to specify alternate algorithms (algorithm
	agility) within the protocol specification to support such an		agility) within the protocol specification to support such an
	event is essential. Additionally, more than one algorithm MUST		event is essential. Additionally, more than one algorithm MUST
	be specified. Mandating support for two algorithms provides		be specified. Mandating support for two algorithms (i.e., one
	both redundancy, and a mechanism for enacting that redundancy.		mandatory to implement algorithm and one or more backup
			algorithms to guide transition) provides both redundancy, and a
			mechanism for enacting that redundancy.
	4. Secure use of PSKs, offering both operational convenience and a		4. Secure use of PSKs, offering both operational convenience and a
	baseline level of security, MUST be specified.		baseline level of security, MUST be specified.
	5. Routing Protocols (or the transport or network mechanism		5. Routing Protocols (or the transport or network mechanism
	protecting routing protocols) SHOULD be able to detect and		protecting routing protocols) SHOULD be able to detect and
	reject replayed messages. For non-TCP based protocols like OSPF		reject replayed intra-session and inter-session messages.
	[RFC2328], IS-IS [RFC1195] , etc., two routers are said to have
	a session up if they are able to exchange protocol packets.
	Packets captured from one session MUST not be able to be re-sent		Packets captured from one session MUST NOT be able to be re-sent
	and accepted during a later session. Additionally, replay		and accepted during a later session (i.e., inter-session
	mechanisms MUST work correctly even in the presence of routing		replay). Additionally, replay mechanisms MUST work correctly
	protocol packet prioritization by the router.		even in the presence of routing protocol packet prioritization
			by the router.
	There is a specific case of replay attack combined with spoofing		There is a specific case of replay attack combined with spoofing
	that must be addressed. In several routing protocols (e.g.,		that must be addressed. Several routing protocols (e.g., OSPF
	OSPF [RFC2328], IS-IS [RFC1195], BFD [RFC5880], RIP [RFC2453],		[RFC2328], IS-IS [RFC1195], BFD [RFC5880], RIP [RFC2453], etc.),
	etc.), all speakers share the same key (K) on a broadcast		require all speakers to share the same authentication and
	segment. The ability to run a MAC operation with K is used for		message association key on a broadcast segment. It is important
	(group level) authentication and message integrity, and		that an integrity check associated with a message fail if an
	(currently) no other identity validation check is performed. It		attacker has replayed the message with a different origin.
	is important that an integrity check associated with a message
	fail if an attacker has re-addressed it to appear that it was
	originated by a different origin.
	6. A change of security parameters MUST force a change of session		6. A change of security parameters MUST force a change of session
	traffic keys. The specific security parameters for the various		traffic keys. The specific security parameters for the various
	routing protocols will differ, and will be defined by each		routing protocols will differ, and will be defined by each
	protocols design team. Some examples may include: master key,		protocols design team. Some examples may include: master key,
	key lifetime, cryptographic algorithm, etc. If one of these		key lifetime, cryptographic algorithm, etc. If one of these
	configured parameters changes, then a new session traffic key		configured parameters changes, then a new session traffic key
	MUST immediately be established using the updated parameters.		MUST immediately be established using the updated parameters.
	The routing protocol security mechanisms MUST support this		The routing protocol security mechanisms MUST support this
	behavior.		behavior.
	skipping to change at page 23, line 39 ¶		skipping to change at page 23, line 37 ¶
	KMP.		KMP.
	13. The authentication mechanism in a Routing Protocol MUST be		13. The authentication mechanism in a Routing Protocol MUST be
	decoupled from the key management system used. The		decoupled from the key management system used. The
	authentication protocol MUST include a specification for		authentication protocol MUST include a specification for
	agreeing on keying material. This will accommodate both manual		agreeing on keying material. This will accommodate both manual
	keying and the use of KMPs.		keying and the use of KMPs.
	14. Convergence times of the Routing Protocols SHOULD NOT be		14. Convergence times of the Routing Protocols SHOULD NOT be
	materially affected. Changes in the convergence time will be		materially affected. Changes in the convergence time will be
	immediately verifiable by convergence performance test beds		immediately and independently verifiable by convergence
	already in use (e.g. those maintained by router vendors, service		performance test beds already in use (e.g. those maintained by
	providers, and researchers). An increase in convergence time in		router vendors, service providers, and researchers). An
	excess of 5% is likely to be considered to have materially		increase in convergence time in excess of 5% is likely to be
	affected convergence by network operators. A number of other		considered to have materially affected convergence by network
	facts can also change convergence over time (e.g., speed of		operators. A number of other facts can also change convergence
	processors used on individual routing peers, processing power		over time (e.g., speed of processors used on individual routing
	increases due to Moore's law, implementation specifics), and the		peers, processing power increases due to Moore's law,
	effect of an authentication mechanism on Routing Protocols will		implementation specifics), and the effect of an authentication
	need to take these into account by implementors. Protocol		mechanism on Routing Protocols will need to take these into
	designers should consider the impact on convergence times as a		account by implementors. Protocol designers should consider the
	function of both the total number of protocol packets that must		impact on convergence times as a function of both the total
	be exchanged and the required computational processing of		number of protocol packets that must be exchanged and the
	individual messages in the specification, understanding that the		required computational processing of individual messages in the
	operator community's threshold for increase of convergence times		specification, understanding that the operator community's
	is very low, as stated above.		threshold for increase of convergence times is very low, as
			stated above.
	15. The changes to or addition of security mechanisms SHOULD NOT		15. The changes to or addition of security mechanisms SHOULD NOT
	cause a refresh of route advertisements or cause additional		cause a refresh of route advertisements or cause additional
	route advertisements to be generated.		route advertisements to be generated.
	16. Router implementations provide prioritized treatment for certain		16. Router implementations provide prioritized treatment for certain
	protocol packets. For example, OSPF HELLO packets and ACKs are		protocol packets. For example, OSPF HELLO packets and ACKs are
	prioritized for processing above other OSPF packets. The		prioritized for processing above other OSPF packets. The
	security mechanism SHOULD NOT interfere with the ability to		security mechanism SHOULD NOT interfere with the ability to
	observe and enforce such prioritization. Any effect on such		observe and enforce such prioritization. Any effect on such
	skipping to change at page 24, line 42 ¶		skipping to change at page 24, line 41 ¶
	that originated the packet, MUST either protect the IP header or		that originated the packet, MUST either protect the IP header or
	provide some other means to authenticate the neighbor.		provide some other means to authenticate the neighbor.
	[RFC6039] describes some attacks that motivate this requirement.		[RFC6039] describes some attacks that motivate this requirement.
	19. Every new KARP-developed security mechanisms MUST support		19. Every new KARP-developed security mechanisms MUST support
	incremental deployment. It will not be feasible to deploy a new		incremental deployment. It will not be feasible to deploy a new
	Routing Protocol authentication mechanism throughout a network		Routing Protocol authentication mechanism throughout a network
	instantaneously. Indeed, it may not actually be feasible to		instantaneously. Indeed, it may not actually be feasible to
	deploy such a mechanism to all routers in a large autonomous		deploy such a mechanism to all routers in a large autonomous
	system (AS) in a bounded timeframe. Proposed solutions MUST		system (AS) in a bounded timeframe. Proposed solutions MUST
	support an incremental deployment method that provides some		support an incremental deployment method that benefits those who
	benefit for those who participate. Because of this, there are		participate. Because of this, there are several requirements
	several requirements that any proposed KARP mechanism should		that any proposed KARP mechanism should consider.
	consider.
	A. The Routing Protocol security mechanism MUST enable each		A. The Routing Protocol security mechanism MUST enable each
	router to configure use of the security mechanism on a per-		router to configure use of the security mechanism on a per-
	peer basis where the communication is peer-to-peer		peer basis where the communication is peer-to-peer
	(unicast).		(unicast).
	B. Every new KARP-developed security mechanism MUST provide		B. Every new KARP-developed security mechanism MUST provide
	backward compatibility with respect to message formatting,		backward compatibility with respect to message formatting,
	transmission, and processing of routing information carried		transmission, and processing of routing information carried
	through a secure and non-secure security environment.		through a secure and non-secure security environment.
	skipping to change at page 29, line 14 ¶		skipping to change at page 29, line 14 ¶
	7. Acknowledgements		7. Acknowledgements
	The majority of the text for version -00 of this document was taken		The majority of the text for version -00 of this document was taken
	from "Roadmap for Cryptographic Authentication of Routing Protocol		from "Roadmap for Cryptographic Authentication of Routing Protocol
	Packets on the Wire", draft-lebovitz-karp-roadmap, authored by		Packets on the Wire", draft-lebovitz-karp-roadmap, authored by
	Gregory M. Lebovitz.		Gregory M. Lebovitz.
	Brian Weis provided significant assistance in handling the many		Brian Weis provided significant assistance in handling the many
	comments that came back during IESG review, including making textual		comments that came back during IESG review, including making textual
	edits.		edits directly to the XML. For his extensive efforts he was added as
			an author on -07.
	We would like to thank the following people for their thorough		We would like to thank the following people for their thorough
	reviews and comments: Brian Weis, Yoshifumi Nishida, Stephen Kent,		reviews and comments: Brian Weis, Yoshifumi Nishida, Stephen Kent,
	Vishwas Manral, Barry Leiba, Sean Turner, Uma Chunduri.		Vishwas Manral, Barry Leiba, Sean Turner, Uma Chunduri.
	Author Gregory M. Lebovitz was employed at Juniper Networks, Inc. for		Author Gregory M. Lebovitz was employed at Juniper Networks, Inc. for
	much of the time he worked on this document, though not at the time		much of the time he worked on this document, though not at the time
	of its publishing. Thus Juniper sponsored much of this effort.		of its publishing. Thus Juniper sponsored much of this effort.
	8. References		8. References
	skipping to change at line 1227 ¶		skipping to change at page 32, line 20 ¶
	Email: gregory.ietf@gmail.com		Email: gregory.ietf@gmail.com
	Manav Bhatia		Manav Bhatia
	Alcatel-Lucent		Alcatel-Lucent
	Bangalore,		Bangalore,
	India		India
	Phone:		Phone:
	Email: manav.bhatia@alcatel-lucent.com		Email: manav.bhatia@alcatel-lucent.com
			Brian Weis
			Cisco Systems
			170 W. Tasman Drive
			San Jose, California 95134-1706
			USA
			Phone:
			Email: bew@cisco.com
			URI: http://www.cisco.com
End of changes. 17 change blocks.
	54 lines changed or deleted		71 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/