draft-ietf-opsec-blackhole-urpf-03.txt		draft-ietf-opsec-blackhole-urpf-04.txt
	Opsec Working Group W. Kumari		Opsec Working Group W. Kumari
	Internet Draft Google		Internet Draft Google
	<draft-ietf-opsec-blackhole-urpf-03> D. McPherson		<draft-ietf-opsec-blackhole-urpf-04> D. McPherson
	Category: Informational Arbor Networks		Category: Informational Arbor Networks
	Expires: September 30, 2009		Expires: December 4, 2009
	March 30, 2009		June 4, 2009
	Remote Triggered Black Hole filtering with uRPF		Remote Triggered Black Hole filtering with uRPF
	<draft-ietf-opsec-blackhole-urpf-03.txt>		<draft-ietf-opsec-blackhole-urpf-04.txt>
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and 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
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 34		skipping to change at page 1, line 34
	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 September 5, 2009.		This Internet-Draft will expire on December 4, 2009.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 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 in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 3, line 8		skipping to change at page 3, line 8
	Abstract		Abstract
	Remote Triggered Black Hole (RTBH) filtering is a popular and		Remote Triggered Black Hole (RTBH) filtering is a popular and
	effective technique for the mitigation of denial-of-service attacks.		effective technique for the mitigation of denial-of-service attacks.
	This document expands upon destination-based RTBH filtering by		This document expands upon destination-based RTBH filtering by
	outlining a method to enable filtering by source address as well.		outlining a method to enable filtering by source address as well.
	Table of Contents		Table of Contents
	1. Introduction ....................................................3		1. Introduction ....................................................3
	2. Terminology .....................................................3		2. Terminology .....................................................4
	3. Background ......................................................3		3. Destination address RTBH filtering ..............................4
	4. Destination address RTBH filtering ..............................4		3.1. Overview ...................................................4
	4.1. Overview ...................................................4		3.2. Detail .....................................................5
	4.2. Detail .....................................................5		4. Source address RTBH filtering ...................................8
	5. Source address RTBH filtering ...................................7		4.1. Steps to deploy RTBH filtering with uRPF ...................9
	5.1. Steps to deploy RTBH filtering with uRPF ...................8		5. Security Considerations .........................................9
	6. Security Considerations .........................................9		6. IANA Considerations ............................................10
	7. IANA Considerations .............................................9		7. Acknowledgments ................................................10
	8. Acknowledgments .................................................9		8. References .....................................................10
	9. References ......................................................9		8.1. Normative References ......................................10
	9.1. Normative References .......................................9		8.2. Informative References ....................................10
	9.2. Informative References ....................................10
	A. Cisco Router Configuration Sample...............................11		A. Cisco Router Configuration Sample...............................11
	B. Juniper Configuration Sample....................................13		B. Juniper Configuration Sample....................................13
	C. A Brief History of RTBH.........................................15		C. A Brief History of RTBH.........................................15
	1. Introduction		1. Introduction
	This document expands upon the technique outlined in "Configuring BGP		This document expands upon the technique outlined in "Configuring BGP
	to Block Denial-of-Service Attacks" [RFC3882] to demonstrate a method		to Block Denial-of-Service Attacks" [RFC3882] to demonstrate a method
	that allows for filtering by source address(es).		that allows for filtering by source address(es).
	2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119. [RFC2119].
	3. Background
	Network operators have developed a variety of techniques for		Network operators have developed a variety of techniques for
	mitigating denial of service attacks. While different techniques have		mitigating denial of service attacks. While different techniques have
	varying strengths and weaknesses, from an implementation perspective		varying strengths and weaknesses, from an implementation perspective
	the selection of which method to use for each type of attack involves		the selection of which method to use for each type of attack involves
	evaluating the tradeoffs associated with each method.		evaluating the tradeoffs associated with each method.
	A common DoS attack directed against a customer of a service provider		A common DoS attack directed against a customer of a service provider
	involves generating a greater volume of attack traffic destined for		involves generating a greater volume of attack traffic destined for
	the target than will fit down the links from the service provider(s)		the target than will fit down the links from the service provider(s)
	to the victim (customer). This traffic "starves out" legitimate		to the victim (customer). This traffic "starves out" legitimate
	skipping to change at page 4, line 34		skipping to change at page 4, line 25
	target prefix. All packets towards that destination, attack traffic		target prefix. All packets towards that destination, attack traffic
	AND legitimate traffic, are then dropped by the participating		AND legitimate traffic, are then dropped by the participating
	routers,thereby taking the target completely offline. The benefit is		routers,thereby taking the target completely offline. The benefit is
	that collateral damage to other systems or network availability at		that collateral damage to other systems or network availability at
	the customer location or in the ISP network is limited, but the		the customer location or in the ISP network is limited, but the
	negative impact to the target itself is arguably increased.		negative impact to the target itself is arguably increased.
	By coupling unicast reverse path forwarding (RPF) [RFC3704]		By coupling unicast reverse path forwarding (RPF) [RFC3704]
	techniques with RTBH filtering, BGP can be used to distribute discard		techniques with RTBH filtering, BGP can be used to distribute discard
	routes that are based not on destination or target addresses, but		routes that are based not on destination or target addresses, but
	based on source addresses of unwanted traffic.		based on source addresses of unwanted traffic. Note that this will
			drop all traffic to / from the address, and not just the traffic to
			the victim.
	4. Destination address RTBH filtering		This document is broken up into three logical parts, the first
			outlines how to configure destination based RTBH, the second covers
			source based RTBH and the third part has examples and a history of
			the technique.
	4.1. Overview		2. Terminology
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in RFC 2119. [RFC2119].
			3. Destination address RTBH filtering
			3.1. Overview
	A "discard" route is installed on each edge router in the network		A "discard" route is installed on each edge router in the network
	with the destination set to the discard (or null) interface. In order		with the destination set to the discard (or null) interface. In order
	to use RTBH filtering for a single IP address (or prefix), a BGP		to use RTBH filtering for a single IP address (or prefix), a BGP
	route for the address to be filtered is announced, with the next-hop		route for the address to be filtered is announced, with the next-hop
	set as the "discard" route. This causes traffic to the announced		set as the "discard" route. This causes traffic to the announced
	network prefix to be forwarded to the discard interface so that it		network prefix to be forwarded to the discard interface so that it
	does not transit the network wasting resources or triggering		does not transit the network wasting resources or triggering
	collateral damage to other resources along the path towards the		collateral damage to other resources along the path towards the
	target.		target.
	While this does "complete" the attack in that the target address(es)		While this does "complete" the attack in that the target address(es)
	are made unreachable, collateral damage is minimized. It may also be		are made unreachable, collateral damage is minimized. It may also be
	possible to move the host or service on the target IP address(es) to		possible to move the host or service on the target IP address(es) to
	another address and keep the service up, for example by updating		another address and keep the service up, for example by updating
	associated DNS resource records.		associated DNS resource records.
	4.2. Detail		3.2. Detail
			Before deploying RTBH filtering, there is some preparation and
			planning that needs to occur and decisions that need to be made.
			These include:
			- what are the discard addresses?
			- what are the discard BGP communities?
			- what is the largest prefix that can be black-holed?
			- what is the smallest advertisement that your provider will
			accept?
	Steps to configure destination based RTBH filtering:		Steps to configure destination based RTBH filtering:
	1. Select your Discard Address schema. An address is chosen to become		Step 1. Select your Discard Address schema. An address is chosen to
	the "discard address". This is often chosen from 192.0.2.0/24 (TEST-		become the "discard address". This is often chosen from 192.0.2.0/24
	NET [RFC3330]), or from RFC 1918 [RFC1918] space. Multiple addresses		(TEST-NET [RFC3330]), or from RFC 1918 [RFC1918] space. Multiple
	allow an operator to configure multiple static routes, one for each		addresses allow an operator to configure multiple static routes, one
	incident:		for each incident:
	192.0.2.1 = Incident #1		192.0.2.1 = Incident #1
	192.0.2.2 = Incident #2		192.0.2.2 = Incident #2
	192.0.2.3 = Incident #3		192.0.2.3 = Incident #3
	192.0.2.4 = Incident #4		192.0.2.4 = Incident #4
	192.0.2.5 = Incident #5		192.0.2.5 = Incident #5
	Customer #1 who has a DDoS attack can be pointed to discard route		Customer #1 who has a DDoS attack can be pointed to discard route
	192.0.2.1. Customer #2 can be pointed to discard route 192.0.2.2. If		192.0.2.1. Customer #2 can be pointed to discard route 192.0.2.2. If
	capable, the router can then count the drops for each, providing some		capable, the router can then count the drops for each, providing some
	level of telemetry on the volume of drops as well as status of an		level of telemetry on the volume of drops as well as status of an
	ongoing attack. A consistent address schema facilitates operations.		ongoing attack. A consistent address schema facilitates operations.
	2. Set the Discard Route(s) on each router. A route for the "discard		Step 2. Configure the Discard Route(s) on each router, A route for
	address" is installed on the routers that form the edge/perimeter of		the "discard address" is installed on the routers that form the
	the network, in all routers in the network, or some subset (e.g.,		edge/perimeter of the network, in all routers in the network, or some
	peering, but not customer, etc.). The destination of the route is set		subset (e.g., peering, but not customer, etc.). The destination of
	to the "discard" or "null" interface. This route is called the		the route is set to the "discard" or "null" interface. This route is
	"discard route". Implementation experience demonstrates the value of		called the "discard route". Implementation experience demonstrates
	configuring each ingress router with a capability for dropping		the value of configuring each ingress router with a capability for
	traffic via RTBH filtering.		dropping traffic via RTBH filtering.
	3. Configure the RTBH BGP Policy on each router. A BGP policy is		Step 3. Configure the RTBH BGP Policy on each router. A BGP policy
	configured on all routers that have the discard route so that routes		is configured on all routers that have the discard route so that
	announced with a chosen community will have their next hop set to the		routes announced with a chosen community will have their next hop set
	discard address. The BGP policy should be made restrictive so that		to the discard address. The BGP policy should be made restrictive so
	only BGP routes covering a defined number of hosts addresses will be		that only BGP routes covering a defined number of hosts addresses
	accepted. That is, typically, only specific /32s are necessary.		will be accepted. That is, typically, only specific /32s are
	Shorter prefix blocks may also be required or desirable, for example		necessary. Shorter prefix blocks may also be required or desirable,
	if larger numbers of attack targets are located within a single		for example if larger numbers of attack targets are located within a
	prefix, or the employment of this mechanism is to drop traffic bound		single prefix, or the employment of this mechanism is to drop
	for specific networks. When filtering based on shorter prefixes,		traffic bound for specific networks. When filtering based on shorter
	extreme caution should be used as to avoid collateral damage to other		prefixes, extreme caution should be used as to avoid collateral
	hosts that reside within those address blocks. Full implementations		damage to other hosts that reside within those address blocks. Full
	will have multiple communities, with each community used for		implementations will have multiple communities, with each community
	different parts of a provider's network and for different security		used for different parts of a provider's network and for different
	incidents.		security incidents.
	4. Configure the Safety Egress Prefix Filters (Murphy Prefix		Step 4. Configure the Safety Egress Prefix Filters. There is always
	Filters). There is always a chance that the triggering BGP Update		a chance that the triggering BGP Update could leak from the network
	could leak from the network. This has happened [ Youtube/Pakistan		and so egress prefix filters are strongly recommended. These egress
	incident ]. Egress prefix filters are recommended. These egress		prefix filter details may vary, but experience has demonstrated that
	prefix filter details may varying, but experience has demonstrated		the following works:
	that the following works:
	4.1 Deny all prefixes /30 through /32 from leaving your network. If		- Deny all prefixes longer than the longest prefix that you expect
			to
			announce. For example, if the longest prefix that you expect to
			announce is /24, deny all prefixes of length /25 though /32. If
	your triggering BGP update is only /32s, then this egress prefix		your triggering BGP update is only /32s, then this egress prefix
	filter will add a safe measure in case the NO_EXPORT community does		filter will add a safe measure in case the NO_EXPORT community
			does not work.
			- Deny all communities used for triggering RTBH filtering. This is
			also a "safety" measure in case the NO_EXPORT community does
	not work.		not work.
	4.2 Deny all communities used for triggering RTBH filtering. This is		Step 5: Configure the Trigger Router. Configure the trigger router,
	also a "safety" measure in case the NO_EXPORT community does not		workstation, or other device so that adding and removing the triggers
	work.		can be done easily and quickly. The BGP Update should have the
			NO_EXPORT community as a mandatory attribute. An egress prefix filter
			or policy which prevents RTBH filtering prefixes in the /8 to /24
			range is also recommended as a safety tool. The trigger router can be
			set up as a iBGP route reflector client which does not receive any
			prefixes from its BGP peer. This allows a low cost router /
			workstation to be used as the trigger router.
	5: Configure the Trigger Router. Set the trigger router, workstation,		Using the RTBH filtering:
	or other device so that adding and removing the triggers can be done
	easily and quickly. The BGP Update should have the NO_EXPORT
	community as a mandatory attribute. An egress prefix filter or policy
	which prevents RTBHing prefixes in the /8 to /24 range is also
	recommended as a safety tool. The trigger router can be set up as a
	iBGP route reflector client which does not receive any prefixes from
	its BGP peer. This allows a low cost router/workstation to be used
	as the trigger router.
	6. When RTBH filtering is desired for a specific address, that		1. When RTBH filtering is desired for a specific address, that
	address is announced from a trigger router (or route server), tagged		address is announced from a trigger router (or route server), tagged
	with the chosen "RTBH" community and with the NO_EXPORT community,		with the chosen "RTBH" community and with the NO_EXPORT community,
	and passed via iBGP. The receiving routers check the BGP policy, set		and passed via iBGP. The receiving routers check the BGP policy, set
	the next-hop to be the discard route, resulting in a FIB entry		the next-hop to be the discard route, resulting in a FIB entry
	pointing to a discard address.		pointing to a discard address.
	7. Traffic entering the network will now be forwarded to the discard		2. Traffic entering the network will now be forwarded to the discard
	interface on all edge routers and will therefore be dropped at the		interface on all edge routers and will therefore be dropped at the
	edge of the network, saving resources.		edge of the network, saving resources.
	7.1 Multiple Discard Addresses for Incident Granularity. This		2.1 Multiple Discard Addresses for Incident Granularity. This
	technique can be expanded by having multiple discard addresses,		technique can be expanded by having multiple discard addresses,
	routes and communities to allow for monitoring of the discarded		routes and communities to allow for monitoring of the discarded
	traffic volume on devices that support multiple discard interfaces.		traffic volume on devices that support multiple discard interfaces.
	As mentioned earlier, each router can have a discard address schema		As mentioned earlier, each router can have a discard address schema
	to allow the operator to distinguish multiple incidents from each		to allow the operator to distinguish multiple incidents from each
	other - making it easier to monitor the life-cycle of the incidents.		other - making it easier to monitor the life-cycle of the incidents.
	7.2 Multiple "Trigger Communities" for Network Wide Granularity. The		2.2 Multiple "Trigger Communities" for Network Wide Granularity. The
	network can be sectioned into multiple communities, providing the		network can be sectioned into multiple communities, providing the
	operator with an ability to drop in discreete parts of their network.		operator with an ability to drop in discrete parts of their network.
	For example, the network can be divided into the following		For example, the network can be divided into the following
	communities:		communities:
	XXX:600 RTBH filtering on all router		XXX:600 RTBH filtering on all router
	XXX:601 RTBH filtering on only peering router		XXX:601 RTBH filtering on only peering router
	XXX:602 RTBH filtering on only customers who peer BGP		XXX:602 RTBH filtering on only customers who peer BGP
	XXX:603 RTBH filtering on Datacenters (to see if the data center		XXX:603 RTBH filtering on Datacenters (to see if the data center
	is the		is the
	source of attack)		source of attack)
	XXX:604 RTBH filtering on all customers (to see how many		XXX:604 RTBH filtering on all customers (to see how many
	customers are		customers are
	being used by the attacker)		being used by the attacker)
	Some diligent thinking is required to develop a community schema		Some diligent thinking is required to develop a community schema
	which provides flexibility while reflecting topological		which provides flexibility while reflecting topological
	considerations.		considerations.
	7.3 "Customer Triggered" RTBH filtering. The technique can also be		2.3 "Customer Triggered" RTBH filtering. The technique can also be
	expanded by relaxing the AS path rule to allow customers of a service		expanded by relaxing the AS path rule to allow customers of a service
	provider to enable RTBH filtering without interacting with the		provider to enable RTBH filtering without interacting with the
	service provider's trigger routers. If this is configured, an		service provider's trigger routers. If this is configured, an
	operator MUST only accept announcements for prefixes from the		operator MUST only accept announcements for prefixes from the
	customer that the customer is authorized to advertise, in order to		customer that the customer is authorized to advertise, in order to
	prevent the customer from accidentally (or intentionally) black-		prevent the customer from accidentally (or intentionally) black-
	holing space that they are not allowed to advertise.		holing space that they are not allowed to advertise.
	A common policy for this type of setup would first permit any more		A common policy for this type of setup would first permit any more
	specific of an authorized prefix only if the blackhole communities is		specific of an authorized prefix only if the blackhole communities is
	attached, append NO_EXPORT, NO_ADVERTISE, or similar communities, and		attached, append NO_EXPORT, NO_ADVERTISE, or similar communities, and
	then also accept from the customer the original aggregate prefix that		then also accept from the customer the original aggregate prefix that
	will be advertised as standard policy permits.		will be advertised as standard policy permits.
	Extreme caution should be used in order to avoid leaking any more		Extreme caution should be used in order to avoid leaking any more
	specifics beyond the local routing domain, unless policy explicitly		specifics beyond the local routing domain, unless policy explicitly
	aims at doing just that.		aims at doing just that.
	5. Source address RTBH filtering.		4. Source address RTBH filtering.
	In many instances denial-of-service attacks sourced from botnets are		In many instances denial-of-service attacks sourced from botnets are
	being configured to "follow DNS" (the attacking machines are		being configured to "follow DNS" (the attacking machines are
	instructed to attack www.example.com, and re-resolve this		instructed to attack www.example.com, and re-resolve this
	periodically. Historically the attacks were aimed simply at an IP		periodically. Historically the attacks were aimed simply at an IP
	address and so renumbering www.example.com to a new address was an		address and so renumbering www.example.com to a new address was an
	effective mitigation). This makes employing technique that allows		effective mitigation). This makes employing technique that allows
	black-holing to be based on source address desirable.		black-holing to be based on source address desirable.
	By combining traditional RTBH filtering with unicast Reverse Path		By combining traditional RTBH filtering with unicast Reverse Path
	Forwarding (uRPF) a network operator can filter based upon the source		Forwarding (uRPF) a network operator can filter based upon the source
	address. uRPF performs a route lookup of the source address of the		address. uRPF performs a route lookup of the source address of the
	packet and checks to see if the ingress interface of the packet is a		packet and checks to see if the ingress interface of the packet is a
	valid egress interface for the packet source address (strict mode) or		valid egress interface for the packet source address (strict mode) or
	if any route to the source address of the packet exists (loose mode).		if any route to the source address of the packet exists (loose mode).
	If the check fails, the packet is typically dropped. In loose mode		If the check fails, the packet is typically dropped. In loose mode
	some vendors also verify that the destination route does not point to		some vendors also verify that the destination route does not point to
	a discard interface - this allows source based RTBH filtering to be		an invalid next-hop - this allows source based RTBH filtering to be
	deployed in networks that cannot implement strict (or feasible path)		deployed in networks that cannot implement strict (or feasible path)
	mode uRPF.		mode uRPF. Before enabling uRPF (in any mode), it is vital that you
			fully understand the implications of doing so:
			- Strict mode will cause the router to drop all ingress traffic
			if the best path back to the source address of the traffic is
			not the interface from which the traffic was received.
			Asymetric routing will cause strict mode uRPF to drop
			legitimate traffic.
			- Loose mode causes the router to check if a route for the source
			address of the traffic exists. This may also cause legitimate
			traffic to be discarded.
			It is hoped that in the future, vendors will implement a "DoS-
			mitigation" mode in addition to the Loose and Strict modes -- in this
			mode, the uRPF check will only fail if the next-hop for the source of
			the packet is a discard interface.
	By enabling the uRPF feature on interfaces at pre-determined points		By enabling the uRPF feature on interfaces at pre-determined points
	in their network and announcing the source address(es) of attack		in their network and announcing the source address(es) of attack
	traffic, a network operator can effectively drop the identified		traffic, a network operator can effectively drop the identified
	attack traffic at specified devices (ideally ingress edge) of their		attack traffic at specified devices (ideally ingress edge) of their
	network based on source address.		network based on source address.
	While administrators may choose to drop traffic from any prefix they		While administrators may choose to drop traffic from any prefix they
	wish, it is recommended when employing source-based RTBH filtering		wish, it is recommended when employing source-based RTBH filtering
	inter-domain that explicit policy be defined that enables peers to		inter-domain that explicit policy be defined that enables peers to
	only announce source-based RTBH routes for prefixes which they		only announce source-based RTBH routes for prefixes which they
	originate.		originate.
	5.1 Steps to deploy RTBH filtering with uRPF for source filtering.		4.1 Steps to deploy RTBH filtering with uRPF for source filtering.
	The same steps that are required to implement destination address		The same steps that are required to implement destination address
	RTBH filtering are taken with the additional step of enabling unicast		RTBH filtering are taken with the additional step of enabling unicast
	reverse path forwarding on predetermined interfaces. When a source		reverse path forwarding on predetermined interfaces. When a source
	address (or network) needs to be blocked, that address (or network)		address (or network) needs to be blocked, that address (or network)
	is announced using BGP tagged with a community. This will cause the		is announced using BGP tagged with a community. This will cause the
	route to be installed with a next hop of the discard interface,		route to be installed with a next hop of the discard interface,
	causing the uRPF check to fail. The destination based RTBH filtering		causing the uRPF check to fail and the packets to be discarded. The
	community should not be used for source based RTBH filtering, and the		destination based RTBH filtering community should not be used for
	routes tagged with the selected community should be carefully		source based RTBH filtering, and the routes tagged with the selected
	filtered.		community should be carefully filtered.
	The BGP policy will need to be relaxed to accept announcements tagged		The BGP policy will need to be relaxed to accept announcements tagged
	with this community to be accepted even though they contain addresses		with this community to be accepted even though they contain addresses
	not controlled by the network announcing them. These announcements		not controlled by the network announcing them. These announcements
	must NOT be propagated outside the local AS and should carry the		must NOT be propagated outside the local AS and should carry the
	NO_EXPORT community.		NO_EXPORT community.
	As a matter of policy, operators SHOULD NOT accept source-based RTBH		As a matter of policy, operators SHOULD NOT accept source-based RTBH
	announcements from their peers or customers, they should only be		announcements from their peers or customers, they should only be
	installed by local or attack management systems within their		installed by local or attack management systems within their
	administrative domain.		administrative domain.
	6. Security Considerations		5. Security Considerations
	The techniques presented here provide enough power to cause		The techniques presented here provide enough power to cause
	significant traffic forwarding loss if incorrectly deployed. It is		significant traffic forwarding loss if incorrectly deployed. It is
	imperative that the announcements that trigger the black-holing are		imperative that the announcements that trigger the black-holing are
	carefully checked and that the BGP policy that accepts these		carefully checked and that the BGP policy that accepts these
	announcements is implemented in such a manner that the announcements:		announcements is implemented in such a manner that the announcements:
	- Are not propagated outside the AS (NO_EXPORT).		- Are not propagated outside the AS (NO_EXPORT).
	- Are not accepted from outside the AS (except from customers).		- Are not accepted from outside the AS (except from customers).
	- Except where source based filtering is deployed, that the network		- Except where source based filtering is deployed, that the network
	contained in the announcement falls within the address ranges		contained in the announcement falls within the address ranges
	controlled by the announcing AS (i.e.: for customers that the		controlled by the announcing AS (i.e.: for customers that the
	address falls within their space).		address falls within their space).
	7. IANA Considerations		6. IANA Considerations
	No action required.		No action required.
	8. Acknowledgments		7. Acknowledgments
	I would like to thank Joe Abley, Rodney Dunn, Alfred Hoenes, Donald		I would like to thank Joe Abley, Ron Bonica, Rodney Dunn, Alfred
	Smith, Joel Jaeggli and Steve Williams for their assistance, feedback		Hoenes, Donald Smith, Joel Jaeggli, and Steve Williams for their
	and not laughing *too* much at the quality of the initial drafts.		assistance, feedback and not laughing *too* much at the quality of the
			initial drafts.
	I would also like to thank all of the regular contributors to the		I would also like to thank all of the regular contributors to the
	OpSec Working Group and Google for 20% time :-)		OpSec Working Group and Google for 20% time :-)
	The authors would also like to thank Steven L Johnson and Barry Greene		The authors would also like to thank Steven L Johnson and Barry Greene
	for getting this implemented and Chris Morrow for publicizing the		for getting this implemented and Chris Morrow for publicizing the
	technique in multiple talks.		technique in multiple talks.
	9. References		8. References
	9.1. Normative References		8.1. Normative References
	[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,		[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
	and E. Lear, "Address Allocation for Private Internets",		and E. Lear, "Address Allocation for Private Internets",
	BCP 5, RFC 1918, February 1996.		BCP 5, RFC 1918, February 1996.
	[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.
	[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September		[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September
	2002.		2002.
End of changes. 35 change blocks.
	100 lines changed or deleted		135 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/