draft-ietf-opsec-routing-capabilities-00.txt		draft-ietf-opsec-routing-capabilities-01.txt
	OPSEC Working Group Y. Zhao		OPSEC Working Group Y. Zhao
	Internet-Draft F. Miao		Internet-Draft F. Miao
	Intended status: Informational Huawei Technologies		Intended status: Informational Huawei Technologies
	Expires: April 13, 2007 R. Callon		Expires: August 29, 2007 R. Callon
	Juniper Networks		Juniper Networks
	October 10, 2006		February 25, 2007
	Routing Control Plane Security Capabilities		Routing Control Plane Security Capabilities
	draft-ietf-opsec-routing-capabilities-00.txt		draft-ietf-opsec-routing-capabilities-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 36		skipping to change at page 1, line 36
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on April 13, 2007.		This Internet-Draft will expire on August 29, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	The document lists the security capabilities needed for the routing		The document lists the security capabilities needed for the routing
	control plane of an IP infrastructure to support the practices		control plane of an IP infrastructure to support the practices
	defined in Operational Security Current Practices. In particular		defined in Operational Security Current Practices. In particular
	this includes capabilities for route filtering and for authentication		this includes capabilities for route filtering, for authentication of
	of routing protocol packets.		routing protocol packets, and for ensuring resource availability for
			control functions.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Threat model . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Threat model . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. Format and Definition of Capabilities . . . . . . . . . . 3		1.2. Format and Definition of Capabilities . . . . . . . . . . 3
	1.3. Packet Filtering versus Route Filtering . . . . . . . . . 4		1.3. Packet Filtering versus Route Filtering . . . . . . . . . 4
	2. Route Filtering Capabilities . . . . . . . . . . . . . . . . . 5		2. Route Filtering Capabilities . . . . . . . . . . . . . . . . . 5
	2.1. General Route Filtering Capabilities . . . . . . . . . . . 5		2.1. General Route Filtering Capabilities . . . . . . . . . . . 5
	2.1.1. Ability to Filter Inbound or Outbound Routes . . . . . 5		2.1.1. Ability to Filter Inbound or Outbound Routes . . . . . 5
	skipping to change at page 2, line 25		skipping to change at page 2, line 25
	2.2. Route Filtering of Exterior Gateway Protocol . . . . . . . 6		2.2. Route Filtering of Exterior Gateway Protocol . . . . . . . 6
	2.2.1. Ability to Filter Routes by Route Attributes . . . . . 6		2.2.1. Ability to Filter Routes by Route Attributes . . . . . 6
	2.2.2. Ability to Filter Routing Update by TTL . . . . . . . 7		2.2.2. Ability to Filter Routing Update by TTL . . . . . . . 7
	2.2.3. Ability to Limit the Number of Routes from a Peer . . 8		2.2.3. Ability to Limit the Number of Routes from a Peer . . 8
	2.2.4. Ability to Limit the Length of Prefixes . . . . . . . 9		2.2.4. Ability to Limit the Length of Prefixes . . . . . . . 9
	2.2.5. Ability to Cooperate in Outbound Route Filtering . . . 9		2.2.5. Ability to Cooperate in Outbound Route Filtering . . . 9
	2.3. Route Filtering of Interior Gateway Protocols . . . . . . 10		2.3. Route Filtering of Interior Gateway Protocols . . . . . . 10
	2.3.1. Route Filtering Within an IGP Area . . . . . . . . . . 10		2.3.1. Route Filtering Within an IGP Area . . . . . . . . . . 10
	2.3.2. Route Filtering Between IGP Areas . . . . . . . . . . 10		2.3.2. Route Filtering Between IGP Areas . . . . . . . . . . 10
	2.4. Route Filtering during Redistribution . . . . . . . . . . 11		2.4. Route Filtering during Redistribution . . . . . . . . . . 11
	3. Route Authentication Capabilities . . . . . . . . . . . . . . 12		3. Route Authentication Capabilities . . . . . . . . . . . . . . 11
	3.1. Ability to configure an authentication mechanism . . . . . 12		3.1. Ability to configure an authentication mechanism . . . . . 12
	3.2. Ability to support authentication key chains . . . . . . . 12		3.2. Ability to support authentication key chains . . . . . . . 12
	4. Ability to Damp Route Flap . . . . . . . . . . . . . . . . . . 13		4. Ability to Damp Route Flap . . . . . . . . . . . . . . . . . . 13
	5. Performance and Prioritization . . . . . . . . . . . . . . . . 14		5. Resource Availability for Router Control Functions . . . . . . 13
	5.1. Ensure Resources for Management Functions . . . . . . . . 14		5.1. Ensure Resources for Management Functions . . . . . . . . 13
	5.2. Ensure Resources for Routing Functions . . . . . . . . . . 15		5.2. Ensure Resources for Routing Functions . . . . . . . . . . 15
	5.3. Limit Resources used by IP Multicast . . . . . . . . . . . 16		5.3. Limit Resources used by IP Multicast . . . . . . . . . . . 16
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 17		6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 17		8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
	8.2. Informative References . . . . . . . . . . . . . . . . . . 18		8.2. Informative References . . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
	Intellectual Property and Copyright Statements . . . . . . . . . . 20		Intellectual Property and Copyright Statements . . . . . . . . . . 20
	skipping to change at page 10, line 21		skipping to change at page 10, line 21
	implementations support prefix-based ORF.		implementations support prefix-based ORF.
	Considerations.		Considerations.
	None.		None.
	2.3. Route Filtering of Interior Gateway Protocols		2.3. Route Filtering of Interior Gateway Protocols
	This section describes route filtering as it may be applied to OSPF		This section describes route filtering as it may be applied to OSPF
	and IS-IS when used as the interior gateway protocol (Internal		and IS-IS when used as the interior gateway protocol (Internal
	Gateway Protocol or "IGP") used within a routing domain. Route		Gateway Protocol or "IGP") used within a routing domain.
	filtering with RIP is TBD.
	2.3.1. Route Filtering Within an IGP Area		2.3.1. Route Filtering Within an IGP Area
	A critical design principle of OSPF and IS-IS is that each router		A critical design principle of OSPF and IS-IS is that each router
	within an area has the same view of the topology, thereby allowing		within an area has the same view of the topology, thereby allowing
	consistent routes to be computed by all routers within the area. For		consistent routes to be computed by all routers within the area. For
	this reason, all properly authenticated (if applicable) routing		this reason, all properly authenticated (if applicable) routing
	topology advertisements (Link State Advertisements or LSAs in OSPF,		topology advertisements (Link State Advertisements or LSAs in OSPF,
	or Link State Packets or LSPs in IS-IS) are flooded unchanged		or Link State Packets or LSPs in IS-IS) are flooded unchanged
	throughout the area. Route filtering within an OSPF or IS-IS area is		throughout the area. Route filtering within an OSPF or IS-IS area is
	skipping to change at page 11, line 36		skipping to change at page 11, line 33
	processes running in the single device.		processes running in the single device.
	Supported Practices.		Supported Practices.
	Route redistribution bridges between different route domains and		Route redistribution bridges between different route domains and
	improves the flexibility of routing system. This allows for the		improves the flexibility of routing system. This allows for the
	transmission of reachable destinations learned in one protocol		transmission of reachable destinations learned in one protocol
	through another protocol. However, without careful consideration		through another protocol. However, without careful consideration
	it may lead to looping or black holes as well.		it may lead to looping or black holes as well.
	Filters always needed when routes redistributing between IGP and		Filters is always needed when routes redistributing between IGP
	BGP. For example, it is unfeasible to inject all internet routes		and BGP. For example, it is unfeasible to inject all internet
	from BGP to IGPs, since IGPs are not able to deal with such a		routes from BGP to IGPs, since IGPs are not able to deal with such
	large number of routes.		a large number of routes.
	Current Implementations.		Current Implementations.
	Most implementations allow applying a filter based on a prefix		Most implementations allow applying a filter based on a prefix
	list to control redistribution.		list to control redistribution.
	Considerations		Considerations
	TBD.		TBD.
	skipping to change at page 14, line 5		skipping to change at page 13, line 44
	MAO [19] described a flaw of current BGP RFD standard RFC2439,		MAO [19] described a flaw of current BGP RFD standard RFC2439,
	which shows that route flap damping could suppress relatively		which shows that route flap damping could suppress relatively
	stable routes and affect routing convergence.		stable routes and affect routing convergence.
	Since none of vendors has corrected his BGP implementation,		Since none of vendors has corrected his BGP implementation,
	RIPE378 [20] proposes that, with the current implementations of		RIPE378 [20] proposes that, with the current implementations of
	BGP flap damping, the application of flap damping in ISP networks		BGP flap damping, the application of flap damping in ISP networks
	is not recommended.		is not recommended.
	5. Performance and Prioritization		5. Resource Availability for Router Control Functions
	5.1. Ensure Resources for Management Functions		5.1. Ensure Resources for Management Functions
	Capability.		Capability.
	This capability specifies that device implementations ensure that		This capability specifies that device implementations ensure that
	at least a certain minimum sufficient level of resources are		at least a certain minimum sufficient level of resources are
	available for management functions. This may include resources at		available for management functions. This may include such
	ingress to the device, on egress from the device, for internal		resources as memory, processor cycle, data structure and/or
	transmission, and processing. This may include at least protocols		bandwidth at ingress to the device, on egress from the device, for
	used for configuration, monitoring, configuration backup, logging,		internal transmission and processing. This may include at least
	time synchronization, and authentication.		protocols used for configuration, monitoring, configuration
			backup, logging, time synchronization, authentication and
			authorization.
	Supported Practices.		Supported Practices.
	Certain attacks (and normal operation) can cause resource		Certain attacks (and normal operation) can cause resource
	saturation such as link congestion, memory exhaustion or CPU		saturation such as link congestion, memory exhaustion or CPU
	overload. In these cases it is important that resources be		overload. In these cases it is important that resources be
	available for management functions in order to ensure that		available for management functions in order to ensure that
	operators have the tools needed to recover from the attack.		operators have the tools needed to recover from the attack.
	Current Implementations.		Current Implementations.
	skipping to change at page 15, line 13		skipping to change at page 15, line 11
	(e.g., ingress, egress, internal transit, processing). To the		(e.g., ingress, egress, internal transit, processing). To the
	extent that this is done across an entire network, the overall		extent that this is done across an entire network, the overall
	effect will be to ensure that the network remains manageable.		effect will be to ensure that the network remains manageable.
	5.2. Ensure Resources for Routing Functions		5.2. Ensure Resources for Routing Functions
	Capability.		Capability.
	This capability specifies that a device implementation ensures at		This capability specifies that a device implementation ensures at
	least a certain minimum sufficient level of resources are		least a certain minimum sufficient level of resources are
	available for routing protocol functions. This may include		available for routing protocol functions. This may include such
	resources at ingress to the device, on egress from the device, for		resources as memory, processor cycle, data structure and bandwidth
	internal transmission, and processing. This may include at least		at ingress to the device, on egress from the device, for internal
	protocols used for routing protocol operation, including resources		transmission, and processing. This may include at least protocols
	used for routing HELLO packets for BGP, IS-IS, and OSPF.		used for routing protocol operation, including resources used for
			routing HELLO packets for BGP, IS-IS, and OSPF.
	Supported Practices.		Supported Practices.
	Certain attacks (and normal operation) can cause resource		Certain attacks (and normal operation) can cause resource
	saturation such as link congestion, memory exhaustion or CPU		saturation such as link congestion, memory exhaustion or CPU
	overload. In these cases it is important that resources be		overload. In these cases it is important that resources be
	available for the operation of routing protocols in order to		available for the operation of routing protocols in order to
	ensure that the network continues to operate (for example, that		ensure that the network continues to operate (for example, that
	routes can be computed in order to allow management traffic to be		routes can be computed in order to allow management traffic to be
	delivered). For many routing protocols the loss of HELLO packets		delivered). For many routing protocols the loss of HELLO packets
	skipping to change at page 15, line 44		skipping to change at page 15, line 43
	How this is implemented depend upon the details of the device.		How this is implemented depend upon the details of the device.
	There are a variety of ways that this may be ensured such as		There are a variety of ways that this may be ensured such as
	prioritizing routing functions in comparison with other functions		prioritizing routing functions in comparison with other functions
	performed by the device, providing separate queues for routing		performed by the device, providing separate queues for routing
	traffic, use of operating systems or other methods that partition		traffic, use of operating systems or other methods that partition
	resources between processes or functions, and so on.		resources between processes or functions, and so on.
	Consideration.		Consideration.
	If routing HELLO packets are not prioritized, then it is possible		For example, if routing HELLO packets are not prioritized, then it
	during DoS attacks or during severe network congestion for routing		is possible during DoS attacks or during severe network congestion
	protocols to drop HELLO packets, causing routing adjacencies to be		for routing protocols to drop HELLO packets, causing routing
	lost. This in turn can cause overall failure of a network. A DoS		adjacencies to be lost. This in turn can cause overall failure of
	attack against hosts can therefore become a DoS attack against the		a network. A DoS attack against hosts can therefore become a DoS
	network.		attack against the network.
	Guaranteeing resources within routers is not a panacea. Routing		Guaranteeing resources within routers is not a panacea. Routing
	packets may not make it across a saturated link (thus for example		packets may not make it across a saturated link (thus for example
	it may also be desirable to prioritize routing packets for		it may also be desirable to prioritize routing packets for
	transmission across link layer devices such as Ethernet switches).		transmission across link layer devices such as Ethernet switches).
	This requirement simply says that the device should prioritize		This requirement simply says that the device should prioritize
	routing functions within its scope of control (e.g., ingress,		routing functions within its scope of control (e.g., ingress,
	egress, internal transit, processing). To the extent that this is		egress, internal transit, processing). To the extent that this is
	done across an entire network, the overall effect will be to		done across an entire network, the overall effect will be to
	ensure that the network continues to operate.		ensure that the network continues to operate.
	skipping to change at page 19, line 17		skipping to change at page 19, line 17
	Shangdi Information Industry Base		Shangdi Information Industry Base
	Haidian District, Beijing 100085		Haidian District, Beijing 100085
	P. R. China		P. R. China
	Phone: +86 10 8288 2008		Phone: +86 10 8288 2008
	Email: miaofy@huawei.com		Email: miaofy@huawei.com
	Ross W. Callon		Ross W. Callon
	Juniper Networks		Juniper Networks
	10 Technology Park Drive		10 Technology Park Drive
	Shangdi Information Industry Base
	Westford, MA 01886		Westford, MA 01886
	USA		USA
	Email: rcallon@juniper.net		Email: rcallon@juniper.net
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2007).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Intellectual Property		Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
End of changes. 17 change blocks.
	39 lines changed or deleted		41 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/