< draft-ietf-karp-isis-analysis-01.txt		draft-ietf-karp-isis-analysis-02.txt >
	KARP Working Group U. Chunduri		KARP Working Group U. Chunduri
	Internet-Draft A. Tian		Internet-Draft A. Tian
	Intended status: Informational W. Lu		Intended status: Informational W. Lu
	Expires: April 23, 2014 Ericsson Inc.,		Expires: August 9, 2014 Ericsson Inc.,
	October 20, 2013		February 5, 2014
	KARP IS-IS security analysis		KARP IS-IS security analysis
	draft-ietf-karp-isis-analysis-01		draft-ietf-karp-isis-analysis-02
	Abstract		Abstract
	This document analyzes the threats applicable for Intermediate system		This document analyzes the threats applicable for Intermediate system
	to Intermediate system (IS-IS) routing protocol and security gaps		to Intermediate system (IS-IS) routing protocol and security gaps
	according to the KARP Design Guide. This document also provides		according to the KARP Design Guide. This document also provides
	specific requirements to address the gaps with both manual and auto		specific requirements to address the gaps with both manual and auto
	key management protocols.		key management protocols.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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 23, 2014.		This Internet-Draft will expire on August 9, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 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
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 27 ¶		skipping to change at page 2, line 19 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3		1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Current State . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Current State . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Key Usage . . . . . . . . . . . . . . . . . . . . . . . . 4		2.1. Key Usage . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1.1. Sub network Independent . . . . . . . . . . . . . . . 4		2.1.1. Sub network Independent . . . . . . . . . . . . . . . 4
	2.1.2. Sub network dependent . . . . . . . . . . . . . . . . 4		2.1.2. Sub network dependent . . . . . . . . . . . . . . . . 4
	2.2. Key Agility . . . . . . . . . . . . . . . . . . . . . . . 5		2.2. Key Agility . . . . . . . . . . . . . . . . . . . . . . . 5
	2.3. Security Issues . . . . . . . . . . . . . . . . . . . . . 5		2.3. Security Issues . . . . . . . . . . . . . . . . . . . . . 5
	2.3.1. Replay Attacks . . . . . . . . . . . . . . . . . . . 5		2.3.1. Replay Attacks . . . . . . . . . . . . . . . . . . . 5
	2.3.1.1. Current Recovery mechanism for LSPs . . . . . . . 7		2.3.1.1. Current Recovery mechanism for LSPs . . . . . . . 6
	2.3.2. Spoofing Attacks . . . . . . . . . . . . . . . . . . 7		2.3.2. Spoofing Attacks . . . . . . . . . . . . . . . . . . 7
	2.3.3. DoS Attacks . . . . . . . . . . . . . . . . . . . . . 8		2.3.3. DoS Attacks . . . . . . . . . . . . . . . . . . . . . 8
	3. Gap Analysis and Security Requirements . . . . . . . . . . . 8		3. Gap Analysis and Security Requirements . . . . . . . . . . . 8
	3.1. Manual Key Management . . . . . . . . . . . . . . . . . . 8		3.1. Manual Key Management . . . . . . . . . . . . . . . . . . 8
	3.2. Key Management Protocols . . . . . . . . . . . . . . . . 9		3.2. Key Management Protocols . . . . . . . . . . . . . . . . 9
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 10		5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	7.1. Normative References . . . . . . . . . . . . . . . . . . 11		7.1. Normative References . . . . . . . . . . . . . . . . . . 10
	7.2. Informative References . . . . . . . . . . . . . . . . . 11		7.2. Informative References . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	This document analyzes the current state of Intermediate system to		This document analyzes the current state of Intermediate system to
	Intermediate system (IS-IS) protocol according to the requirements		Intermediate system (IS-IS) protocol according to the requirements
	set forth in [RFC6518] for both manual and auto key management		set forth in [RFC6518] for both manual and auto key management
	protocols.		protocols.
	skipping to change at page 6, line 33 ¶		skipping to change at page 6, line 30 ¶
	2. Today LSPs have intra-session replay protection as LSP header		2. Today LSPs have intra-session replay protection as LSP header
	contains 32-bit sequence number which is verified for every		contains 32-bit sequence number which is verified for every
	received packet against the local LSP database. But, if a node		received packet against the local LSP database. But, if a node
	in the network is out of service (is undergoing some sort of high		in the network is out of service (is undergoing some sort of high
	availability condition, or an upgrade) for more than LSP refresh		availability condition, or an upgrade) for more than LSP refresh
	time and the rest of the network ages out the LSPs of the node		time and the rest of the network ages out the LSPs of the node
	under consideration, an adversary can potentially plunge in		under consideration, an adversary can potentially plunge in
	inter-session replay attacks in the network. If the key is not		inter-session replay attacks in the network. If the key is not
	changed in the above circumstances, attack can be launched by		changed in the above circumstances, attack can be launched by
	replaying a old LSP with higher sequence number and fewer		replaying an old LSP with higher sequence number and fewer
	prefixes or fewer adjacencies. This may force the receiver to		prefixes or fewer adjacencies. This may force the receiver to
	accept and remove the routes from the routing table, which		accept and remove the routes from the routing table, which
	eventually causes traffic disruption to those prefixes. However,		eventually causes traffic disruption to those prefixes. However,
	as per the IS-IS specification there is a built-in recovery		as per the IS-IS specification there is a built-in recovery
	mechanism for LSPs from inter-session replay attacks and it is		mechanism for LSPs from inter-session replay attacks and it is
	further discussed in Section 2.3.1.1.		further discussed in Section 2.3.1.1.
	3. In any IS-IS network (broadcast or otherwise), if a old and an		3. In any IS-IS network (broadcast or otherwise), if an old and an
	empty Complete Sequence Number packet (CSNP) is replayed this can		empty Complete Sequence Number packet (CSNP) is replayed this can
	cause LSP flood in the network. Similarly a replayed Partial		cause LSP flood in the network. Similarly a replayed Partial
	Sequence Number packet (PSNP) can cause LSP flood in the		Sequence Number packet (PSNP) can cause LSP flood in the
	broadcast network.		broadcast network.
	2.3.1.1. Current Recovery mechanism for LSPs		2.3.1.1. Current Recovery mechanism for LSPs
	In the event of inter-session replay attack by an adversary, as LSP		In the event of inter-session replay attack by an adversary, as LSP
	with higher sequence number gets accepted, it also gets propagated		with higher sequence number gets accepted, it also gets propagated
	until it reaches the originating node of the LSP. The originator		until it reaches the originating node of the LSP. The originator
	skipping to change at page 7, line 40 ¶		skipping to change at page 7, line 31 ¶
	If the same underlying topology is shared across multiple instances		If the same underlying topology is shared across multiple instances
	to transport routing/application information as defined in [RFC6822],		to transport routing/application information as defined in [RFC6822],
	it is necessary to use different authentication credentials for		it is necessary to use different authentication credentials for
	different instances. In this connection, based on the deployment		different instances. In this connection, based on the deployment
	considerations, if certain topologies in a particular IS-IS instance		considerations, if certain topologies in a particular IS-IS instance
	require more protection from spoofing attacks and less exposure,		require more protection from spoofing attacks and less exposure,
	topology specific authentication credentials can be used for LSPs and		topology specific authentication credentials can be used for LSPs and
	SNPs as facilitated in [RFC6822].		SNPs as facilitated in [RFC6822].
	Currently possession of the key it self is used as authentication		Currently possession of the key itself is used as authentication
	check and there is no identity check done separately. Spoofing		check and there is no identity check done separately. Spoofing
	occurs when an illegitimate device assumes the identity of a		occurs when an illegitimate device assumes the identity of a
	legitimate one. An attacker can use spoofing as a means for		legitimate one. An attacker can use spoofing as a means for
	launching various types of attacks. For example:		launching various types of attacks. For example:
	1. The attacker can send out unrealistic routing information that		1. The attacker can send out unrealistic routing information that
	might cause the disruption of network services such as block		might cause the disruption of network services such as block
	holes.		holes.
	2. A rogue system having access to the common key used to protect		2. A rogue system having access to the common key used to protect
	skipping to change at page 11, line 29 ¶		skipping to change at page 11, line 25 ¶
	7.2. Informative References		7.2. Informative References
	[I-D.hartman-karp-mrkmp]		[I-D.hartman-karp-mrkmp]
	Hartman, S., Zhang, D., and G. Lebovitz, "Multicast Router		Hartman, S., Zhang, D., and G. Lebovitz, "Multicast Router
	Key Management Protocol (MaRK)", draft-hartman-karp-		Key Management Protocol (MaRK)", draft-hartman-karp-
	mrkmp-05 (work in progress), September 2012.		mrkmp-05 (work in progress), September 2012.
	[I-D.ietf-karp-crypto-key-table]		[I-D.ietf-karp-crypto-key-table]
	Housley, R., Polk, T., Hartman, S., and D. Zhang,		Housley, R., Polk, T., Hartman, S., and D. Zhang,
	"Database of Long-Lived Symmetric Cryptographic Keys",		"Database of Long-Lived Symmetric Cryptographic Keys",
	draft-ietf-karp-crypto-key-table-08 (work in progress),		draft-ietf-karp-crypto-key-table-10 (work in progress),
	July 2013.		December 2013.
	[I-D.weis-gdoi-mac-tek]		[I-D.weis-gdoi-mac-tek]
	Weis, B. and S. Rowles, "GDOI Generic Message		Weis, B. and S. Rowles, "GDOI Generic Message
	Authentication Code Policy", draft-weis-gdoi-mac-tek-03		Authentication Code Policy", draft-weis-gdoi-mac-tek-03
	(work in progress), September 2011.		(work in progress), September 2011.
	[I-D.yeung-g-ikev2]		[I-D.yeung-g-ikev2]
	Rowles, S., Yeung, A., Tran, P., and Y. Nir, "Group Key		Rowles, S., Yeung, A., Tran, P., and Y. Nir, "Group Key
	Management using IKEv2", draft-yeung-g-ikev2-06 (work in		Management using IKEv2", draft-yeung-g-ikev2-07 (work in
	progress), April 2013.		progress), November 2013.
	[RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with		[RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with
	Digital Signatures", RFC 2154, June 1997.		Digital Signatures", RFC 2154, June 1997.
	[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic		[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
	Key Management", BCP 107, RFC 4107, June 2005.		Key Management", BCP 107, RFC 4107, June 2005.
	[RFC5309] Shen, N. and A. Zinin, "Point-to-Point Operation over LAN		[RFC5309] Shen, N. and A. Zinin, "Point-to-Point Operation over LAN
	in Link State Routing Protocols", RFC 5309, October 2008.		in Link State Routing Protocols", RFC 5309, October 2008.
End of changes. 11 change blocks.
	14 lines changed or deleted		14 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/