draft-ietf-opsec-blackhole-urpf-04.txt   rfc5635.txt 
Opsec Working Group W. Kumari Network Working Group W. Kumari
Internet Draft Google Request for Comments: 5635 Google
<draft-ietf-opsec-blackhole-urpf-04> D. McPherson Category: Informational D. McPherson
Category: Informational Arbor Networks Arbor Networks
Expires: December 4, 2009 August 2009
June 4, 2009
Remote Triggered Black Hole filtering with uRPF
<draft-ietf-opsec-blackhole-urpf-04.txt>
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Remote Triggered Black Hole Filtering
Task Force (IETF), its areas, and its working groups. Note that with Unicast Reverse Path Forwarding (uRPF)
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Abstract
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Remote Triggered Black Hole (RTBH) filtering is a popular and
http://www.ietf.org/ietf/1id-abstracts.txt. effective technique for the mitigation of denial-of-service attacks.
This document expands upon destination-based RTBH filtering by
outlining a method to enable filtering by source address as well.
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 4, 2009. This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
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
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract
Remote Triggered Black Hole (RTBH) filtering is a popular and
effective technique for the mitigation of denial-of-service attacks.
This document expands upon destination-based RTBH filtering by
outlining a method to enable filtering by source address as well.
Table of Contents Table of Contents
1. Introduction ....................................................3 1. Introduction ....................................................2
2. Terminology .....................................................4 2. Terminology .....................................................3
3. Destination address RTBH filtering ..............................4 3. Destination Address RTBH Filtering ..............................3
3.1. Overview ...................................................4 3.1. Overview ...................................................3
3.2. Detail .....................................................5 3.2. Detail .....................................................4
4. Source address RTBH filtering ...................................8 4. Source Address RTBH Filtering ...................................7
4.1. Steps to deploy RTBH filtering with uRPF ...................9 4.1. Steps to Deploy RTBH Filtering with uRPF for Source
Filtering ..................................................8
5. Security Considerations .........................................9 5. Security Considerations .........................................9
6. IANA Considerations ............................................10 6. Acknowledgments .................................................9
7. Acknowledgments ................................................10 7. References ......................................................9
8. References .....................................................10 7.1. Normative References .......................................9
8.1. Normative References ......................................10 7.2. Informative References ....................................10
8.2. Informative References ....................................10 Appendix A. Cisco Router Configuration Sample .....................11
A. Cisco Router Configuration Sample...............................11 Appendix B. Juniper Configuration Sample ..........................12
B. Juniper Configuration Sample....................................13 Appendix C. A Brief History of RTBH ...............................14
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).
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 (DoS) attacks. While different
varying strengths and weaknesses, from an implementation perspective techniques have varying strengths and weaknesses, from an
the selection of which method to use for each type of attack involves implementation perspective, the selection of which method to use for
evaluating the tradeoffs associated with each method. each type of attack involves 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
traffic and often results in collateral damage or negative effects to traffic and often results in collateral damage or negative effects to
other customers or the network infrastructure as well. Rather than other customers or the network infrastructure as well. Rather than
having all destinations on their network be affected by the attack, having all destinations on their network be affected by the attack,
the customer may ask their service provider to filter traffic the customer may ask their service provider to filter traffic
destined to the target destination IP address(es), or the service destined to the target destination IP address(es), or the service
provider may determine that this is necessary themselves, in order to provider may determine that this is necessary themselves, in order to
preserve network availability. preserve network availability.
One method that the service provider can use to implement this One method that the service provider can use to implement this
filtering is to deploy access control lists on the edge of their filtering is to deploy access control lists on the edge of their
network. While this technique provides a large amount of flexibility network. While this technique provides a large amount of flexibility
in the filtering, it runs into scalability issues, both in terms of in the filtering, it runs into scalability issues, both in terms of
the number of entries in the filter and the packet rate. the number of entries in the filter and the packet rate.
Most routers are able to forward traffic at a much higher rate than Most routers are able to forward traffic at a much higher rate than
they are able to filter, and are able to hold many more forwarding they are able to filter, and they are able to hold many more
table entries and routes than filter entries. RTBH filtering forwarding table entries and routes than filter entries. RTBH
leverages the forwarding performance of modern routers to filter both filtering leverages the forwarding performance of modern routers to
more entries and at a higher rate than access control lists would filter more entries and at a higher rate than access control lists
otherwise allow. would otherwise allow.
However, with destination-based RTBH filtering, the impact of the However, with destination-based RTBH filtering, the impact of the
attack on the target is complete. That is, destination-based RTBH attack on the target is complete. That is, destination-based RTBH
filtering injects a discard route into the forwarding table for the filtering injects a discard route into the forwarding table for the
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 (uRPF) [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 on
based on source addresses of unwanted traffic. Note that this will source addresses of unwanted traffic. Note that this will drop all
drop all traffic to / from the address, and not just the traffic to traffic to/from the address, and not just the traffic to the victim.
the victim.
This document is broken up into three logical parts, the first This document is broken up into three logical parts: the first
outlines how to configure destination based RTBH, the second covers outlines how to configure destination-based RTBH, the second covers
source based RTBH and the third part has examples and a history of source-based RTBH, and the third part has examples and a history of
the technique. the technique.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Destination address RTBH filtering 3. Destination Address RTBH Filtering
3.1. Overview 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
with the destination set to the discard (or null) interface. In order the destination set to the discard (or null) interface. In order to
to use RTBH filtering for a single IP address (or prefix), a BGP use RTBH filtering for a single IP address (or prefix), a BGP route
route for the address to be filtered is announced, with the next-hop for the address to be filtered is announced, with the next-hop set as
set as the "discard" route. This causes traffic to the announced the discard route. This causes traffic to the announced network
network prefix to be forwarded to the discard interface so that it prefix to be forwarded to the discard interface so that it does not
does not transit the network wasting resources or triggering transit the network wasting resources or triggering collateral damage
collateral damage to other resources along the path towards the 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.
3.2. Detail 3.2. Detail
Before deploying RTBH filtering, there is some preparation and Before deploying RTBH filtering, there is some preparation and
planning that needs to occur and decisions that need to be made. planning that needs to occur and decisions that need to be made.
These include: These include:
- what are the discard addresses? - 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: - What are the discard BGP communities?
Step 1. Select your Discard Address schema. An address is chosen to - What is the largest prefix that can be black-holed?
become the "discard address". This is often chosen from 192.0.2.0/24
(TEST-NET [RFC3330]), or from RFC 1918 [RFC1918] space. Multiple - What is the smallest advertisement that your provider will accept?
addresses allow an operator to configure multiple static routes, one
for each incident: Steps to configure destination-based RTBH filtering:
Step 1. Select Your Discard Address Schema
An address is chosen to become the "discard address". This is often
chosen from 192.0.2.0/24 (TEST-NET [RFC3330]), or from RFC 1918
[RFC1918] space. Multiple addresses allow an operator to configure
multiple static routes, one 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 (Distributed DoS) attack can be pointed
192.0.2.1. Customer #2 can be pointed to discard route 192.0.2.2. If to discard route 192.0.2.1. Customer #2 can be pointed to discard
capable, the router can then count the drops for each, providing some route 192.0.2.2. If capable, the router can then count the drops for
level of telemetry on the volume of drops as well as status of an each, providing some level of telemetry on the volume of drops as
ongoing attack. A consistent address schema facilitates operations. well as status of an ongoing attack. A consistent address schema
facilitates operations.
Step 2. Configure the Discard Route(s) on each router, A route for Step 2. Configure the Discard Route(s) on Each Router
the "discard address" is installed on the routers that form the
edge/perimeter of the network, in all routers in the network, or some
subset (e.g., peering, but not customer, etc.). The destination of
the route is set to the "discard" or "null" interface. This route is
called the "discard route". Implementation experience demonstrates
the value of configuring each ingress router with a capability for
dropping traffic via RTBH filtering.
Step 3. Configure the RTBH BGP Policy on each router. A BGP policy A route for the "discard address" is installed on the routers that
is configured on all routers that have the discard route so that form the edge/perimeter of the network in all routers in the network
routes announced with a chosen community will have their next hop set or some subset (e.g., peering, but not customer, etc.). The
to the discard address. The BGP policy should be made restrictive so destination of the route is set to the "discard" or "null" interface.
that only BGP routes covering a defined number of hosts addresses This route is called the "discard route". Implementation experience
will be accepted. That is, typically, only specific /32s are demonstrates the value of configuring each ingress router with a
necessary. Shorter prefix blocks may also be required or desirable, capability for dropping traffic via RTBH filtering.
for example if larger numbers of attack targets are located within a
single prefix, or the employment of this mechanism is to drop
traffic bound for specific networks. When filtering based on shorter
prefixes, extreme caution should be used as to avoid collateral
damage to other hosts that reside within those address blocks. Full
implementations will have multiple communities, with each community
used for different parts of a provider's network and for different
security incidents.
Step 4. Configure the Safety Egress Prefix Filters. There is always Step 3. Configure the RTBH BGP Policy on Each Router
a chance that the triggering BGP Update could leak from the network
and so egress prefix filters are strongly recommended. These egress A BGP policy is configured on all routers that have the discard route
prefix filter details may vary, but experience has demonstrated that so that routes announced with a chosen community will have their
the following works: next-hop set to the discard address. The BGP policy should be made
restrictive so that only BGP routes covering a defined number of
hosts addresses will be accepted. That is, typically, only specific
/32s are necessary. Shorter prefix blocks may also be required or
desirable, for example, if larger numbers of attack targets are
located within a single prefix, or the employment of this mechanism
is to drop traffic bound for specific networks. When filtering based
on shorter prefixes, extreme caution should be used as to avoid
collateral damage to other hosts that reside within those address
blocks. Full implementations will have multiple communities, with
each community used for different parts of a provider's network and
for different security incidents.
Step 4. Configure the Safety Egress Prefix Filters
There is always a chance that the triggering BGP update could leak
from the network and so egress prefix filters are strongly
recommended. These egress prefix filter details may vary, but
experience has demonstrated that the following works:
- Deny all prefixes longer than the longest prefix that you expect - Deny all prefixes longer than the longest prefix that you expect
to to announce. For example, if the longest prefix that you expect
announce. For example, if the longest prefix that you expect to to announce is /24, deny all prefixes of length /25 though /32.
announce is /24, deny all prefixes of length /25 though /32. If If your triggering BGP update is only /32s, then this egress
your triggering BGP update is only /32s, then this egress prefix prefix filter will add a safe measure in case the NO_EXPORT
filter will add a safe measure in case the NO_EXPORT community community does not work.
does not work.
- Deny all communities used for triggering RTBH filtering. This is - Deny all communities used for triggering RTBH filtering. This is
also a "safety" measure in case the NO_EXPORT community does also a "safety" measure in case the NO_EXPORT community does not
not work. work.
Step 5: Configure the Trigger Router. Configure the trigger router, Step 5: Configure the Trigger Router
workstation, or other device so that adding and removing the triggers
can be done easily and quickly. The BGP Update should have the Configure the trigger router, workstation, or other device so that
NO_EXPORT community as a mandatory attribute. An egress prefix filter adding and removing the triggers can be done easily and quickly. The
or policy which prevents RTBH filtering prefixes in the /8 to /24 BGP update should have the NO_EXPORT community as a mandatory
range is also recommended as a safety tool. The trigger router can be attribute. An egress prefix filter or policy that prevents RTBH
set up as a iBGP route reflector client which does not receive any filtering prefixes in the /8 to /24 range is also recommended as a
prefixes from its BGP peer. This allows a low cost router / safety tool. The trigger router can be set up as an iBGP (Internal
workstation to be used as the trigger router. BGP) route reflector client that does not receive any prefixes from
its BGP peer. This allows a low-cost router/workstation to be used
as the trigger router.
Using the RTBH filtering: Using the RTBH filtering:
1. 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),
with the chosen "RTBH" community and with the NO_EXPORT community, tagged with the chosen "RTBH" community and with the NO_EXPORT
and passed via iBGP. The receiving routers check the BGP policy, set community, and passed via iBGP. The receiving routers check the
the next-hop to be the discard route, resulting in a FIB entry BGP policy, set the next-hop to be the discard route, resulting in
pointing to a discard address. a Forwarding Information Base (FIB) entry pointing to a discard
address.
2. 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.
2.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
routes and communities to allow for monitoring of the discarded addresses, routes, and communities to allow for monitoring of
traffic volume on devices that support multiple discard interfaces. the discarded traffic volume on devices that support multiple
As mentioned earlier, each router can have a discard address schema discard interfaces. As mentioned earlier, each router can
to allow the operator to distinguish multiple incidents from each have a discard address schema to allow the operator to
other - making it easier to monitor the life-cycle of the incidents. distinguish multiple incidents from each other -- making it
easier to monitor the life-cycle of the incidents.
2.2 Multiple "Trigger Communities" for Network Wide Granularity. The 2.2: Multiple "Trigger Communities" for Network-Wide Granularity.
network can be sectioned into multiple communities, providing the The network can be sectioned into multiple communities,
operator with an ability to drop in discrete parts of their network. providing the operator with an ability to drop in discrete
For example, the network can be divided into the following parts of their network. For example, the network can be
communities: divided into the following communities (where XXX represents
the operator's AS number):
XXX:600 RTBH filtering on all router XXX:600 RTBH filtering on all routers
XXX:601 RTBH filtering on only peering router XXX:601 RTBH filtering on only peering routers
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 data centers (to see if the
is the data center 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
which provides flexibility while reflecting topological schema that provides flexibility while reflecting topological
considerations. considerations.
2.3 "Customer Triggered" RTBH filtering. The technique can also be 2.3: "Customer-Triggered" RTBH filtering. The technique can also
expanded by relaxing the AS path rule to allow customers of a service be expanded by relaxing the Autonomous System (AS) path rule
provider to enable RTBH filtering without interacting with the to allow customers of a service provider to enable RTBH
service provider's trigger routers. If this is configured, an filtering without interacting with the service provider's
operator MUST only accept announcements for prefixes from the trigger routers. If this is configured, an operator MUST
customer that the customer is authorized to advertise, in order to only accept announcements from the customer for prefixes that
prevent the customer from accidentally (or intentionally) black- the customer is authorized to advertise, in order to 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
specific of an authorized prefix only if the blackhole communities is longer prefix within an authorized prefix only if the black
attached, append NO_EXPORT, NO_ADVERTISE, or similar communities, and hole communities are attached, append NO_EXPORT,
then also accept from the customer the original aggregate prefix that NO_ADVERTISE, or similar communities, and then also accept
will be advertised as standard policy permits. from the customer the original aggregate prefix that 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
specifics beyond the local routing domain, unless policy explicitly more specifics beyond the local routing domain, unless policy
aims at doing just that. explicitly aims at doing just that.
4. 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 it desirable to employ a technique
black-holing to be based on source address desirable. that allows black-holing to be based on source address.
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
address. uRPF performs a route lookup of the source address of the source address. uRPF performs a route lookup of the source address
packet and checks to see if the ingress interface of the packet is a of the packet and checks to see if the ingress interface of the
valid egress interface for the packet source address (strict mode) or packet is a valid egress interface for the packet source address
if any route to the source address of the packet exists (loose mode). (strict mode) or if any route to the source address of the packet
If the check fails, the packet is typically dropped. In loose mode exists (loose mode). If the check fails, the packet is typically
some vendors also verify that the destination route does not point to dropped. In loose mode, some vendors also verify that the
an invalid next-hop - this allows source based RTBH filtering to be destination route does not point to an invalid next-hop -- this
deployed in networks that cannot implement strict (or feasible path) allows source-based RTBH filtering to be deployed in networks that
mode uRPF. Before enabling uRPF (in any mode), it is vital that you cannot implement strict (or feasible path) mode uRPF. Before
fully understand the implications of doing so: 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 - Strict mode will cause the router to drop all ingress traffic if
if the best path back to the source address of the traffic is the best path back to the source address of the traffic is not the
not the interface from which the traffic was received. interface from which the traffic was received. Asymmetric routing
Asymetric routing will cause strict mode uRPF to drop will cause strict mode uRPF to drop legitimate traffic.
legitimate traffic.
- Loose mode causes the router to check if a route for the source - Loose mode causes the router to check if a route for the source
address of the traffic exists. This may also cause legitimate address of the traffic exists. This may also cause legitimate
traffic to be discarded. traffic to be discarded.
It is hoped that in the future, vendors will implement a "DoS- It is hoped that in the future, vendors will implement a "DoS-
mitigation" mode in addition to the Loose and Strict modes -- in this 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 mode, the uRPF check will only fail if the next-hop for the source of
the packet is a discard interface. 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 predetermined points in
in their network and announcing the source address(es) of attack 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 that they
originate. originate.
4.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 and the packets to be discarded. The causing the uRPF check to fail and the packets to be discarded. The
destination based RTBH filtering community should not be used for destination-based RTBH filtering community should not be used for
source based RTBH filtering, and the routes tagged with the selected source-based RTBH filtering, and the routes tagged with the selected
community should be carefully 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
skipping to change at page 9, line 50 skipping to change at page 9, line 19
5. 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).
6. IANA Considerations 6. Acknowledgments
No action required.
7. Acknowledgments
I would like to thank Joe Abley, Ron Bonica, Rodney Dunn, Alfred I would like to thank Joe Abley, Ron Bonica, Rodney Dunn, Alfred
Hoenes, Donald Smith, Joel Jaeggli, and Steve Williams for their Hoenes, Donald Smith, Joel Jaeggli, and Steve Williams for their
assistance, feedback and not laughing *too* much at the quality of the assistance, feedback and not laughing *too* much at the quality of
initial drafts. the initial versions.
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
for getting this implemented and Chris Morrow for publicizing the Greene for getting this implemented and Chris Morrow for publicizing
technique in multiple talks. the technique in multiple talks.
8. References 7. References
8.1. Normative References 7.1. Normative References
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,
and E. Lear, "Address Allocation for Private Internets", G., and E. Lear, "Address Allocation for Private
BCP 5, RFC 1918, February 1996. Internets", 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.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for
Networks", BCP 84, RFC 3704, March 2004. Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3882] Turk, D., "Configuring BGP to Block Denial-of-Service [RFC3882] Turk, D., "Configuring BGP to Block Denial-of-Service
Attacks", RFC 3882, September 2004. Attacks", RFC 3882, September 2004.
9.2. Informative References 7.2. Informative References
[Greene2001] Greene Barry Raveendran and Jarvis Neil "Unicast Reverse [Greene2001] Greene Barry Raveendran and Jarvis Neil, "Unicast
Path Forwarding (uRPF) Enhancements for the ISP-ISP Edge", Reverse Path Forwarding (uRPF) Enhancements for the
[ftp://ftp- ISP-ISP Edge", ftp://ftp-eng.cisco.com/
eng.cisco.com/cons/isp/documents/uRPF_Enhancement.pdf], cons/isp/documents/uRPF_Enhancement.pdf, 2001.
2001.
Appendix A: Cisco Router Configuration Sample Appendix A. Cisco Router Configuration Sample
This section provides a partial configuration for configuring RTBH This section provides a partial configuration for configuring RTBH
filtering on a Cisco router. This is not a complete configuration and filtering on a Cisco router. This is not a complete configuration
should be customized before being used. and should be customized before being used.
Announcing router: Announcing router:
! The discard route ! The discard route
ip route 192.0.2.1 255.255.255.255 Null0 ip route 192.0.2.1 255.255.255.255 Null0
! !
! Matches and empty AS-PATH only. ! Matches and empty AS-PATH only.
ip as-path access-list 10 permit ^$ ip as-path access-list 10 permit ^$
! !
! This route-map matches routes with tag 666 and sets the next-hop ! This route-map matches routes with tag 666 and sets the next-hop
! to be the discard route. ! to be the discard route.
skipping to change at page 14, line 5 skipping to change at page 12, line 16
! Don't accept any other announcements with the RTBH community. ! Don't accept any other announcements with the RTBH community.
route-map black-hole-filter deny 20 route-map black-hole-filter deny 20
match community 65505:666 match community 65505:666
! !
route-map black-hole-filter permit 30 route-map black-hole-filter permit 30
! !
! An interface for source-based RTBH filtering with uRPF loose mode. ! An interface for source-based RTBH filtering with uRPF loose mode.
interface FastEthernet 0/0 interface FastEthernet 0/0
ip verify unicast source reachable-via any ip verify unicast source reachable-via any
Appendix B: Juniper Configuration Sample Appendix B. Juniper Configuration Sample
This section provides a partial configuration for configuring RTBH This section provides a partial configuration for configuring RTBH
filtering on a Juniper router. This is not a complete configuration filtering on a Juniper router. This is not a complete configuration
and should be customized before being used. and should be customized before being used.
Announcing router: Announcing router:
routing-options { routing-options {
static { static {
/* EXAMPLE ATTACK SOURCE */ /* EXAMPLE ATTACK SOURCE */
skipping to change at page 17, line 5 skipping to change at page 14, line 18
unit 201 { unit 201 {
vlan-id 201; vlan-id 201;
family inet { family inet {
rpf-check; rpf-check;
address 10.11.12.1/24; address 10.11.12.1/24;
} }
} }
} }
} }
Appendix C: A Brief History of RTBH filtering Appendix C. A Brief History of RTBH Filtering
Understanding the history and motivation behind the development of a Understanding the history and motivation behind the development of a
technique often helps with understanding how to best utilize the technique often helps with understanding how to best utilize the
technique. In this spirit we present a history of Unicast RPF and technique. In this spirit, we present a history of unicast RPF and
RTBH filtering. RTBH filtering.
This section provided by Barry Raveendran Greene: This section has been provided by Barry Raveendran Greene:
Unicast RPF Loose Check (uRPF Loose Check) was created by Neil Jarvis Unicast RPF Loose Check (uRPF Loose Check) was created by Neil Jarvis
and Barry Greene to be used with dRTBH as a rapid reaction tool to and Barry Greene to be used with destination-based RTBH as a rapid
DDoS Attacks. The requirements for this rapid reaction tool was based reaction tool to DDoS attacks. The requirements for this rapid
on post mortem conversation after the Feb 2000 attacks on several big reaction tool was based on post mortem conversation after the
content hosting companies. The summary of the requirement became the February 2000 attacks on several big content hosting companies. The
"Exodus Requirement" which stated: summary of the requirement became the "Exodus Requirement" which
stated:
"We need a tool to drop packets based on source IP address that can We need a tool to drop packets based on source IP address that can
be pushed out to over 60 routers within 60 seconds, be longer than a be pushed out to over 60 routers within 60 seconds, be longer than
thousand lines, be modified on the fly, and work in all your a thousand lines, be modified on the fly, and work in all your
platforms filtering at line rate." platforms filtering at line rate.
A variety of options were looked at to meet this requirement, from A variety of options were looked at to meet this requirement, from
reviving COPS, to pushing out ACLs with BGP, creating a new protocol. reviving Common Open Policy Service (COPS), to pushing out Access
In 2000, the quickest way to meet the "Exodus requirement" was to Control Lists (ACLs) with BGP, creating a new protocol. In 2000, the
marry two functions. First, modify Unicast RPF so that the interface quickest way to meet the "Exodus requirement" was to marry two
check was no longer required and to make sure that a "null" or functions. First, modify unicast RPF so that the interface check was
discard route would drop the packet (i.e. loose check). Second, the no longer required and to make sure that a "null" or discard route
technique where BGP is used to trigger a distributed drop is dusted would drop the packet (i.e., loose check). Second, the technique
off and documented. Combining these two techniques was deemed a fast where BGP is used to trigger a distributed drop is dusted off and
way to put a distributed capability to drop packets out into the documented. Combining these two techniques was deemed a fast way to
industry. put a distributed capability to drop packets out into the industry.
To clarify and restate, uRPF Loose Check was created as one part of a To clarify and restate, uRPF loose check was created as one part of a
rapid reaction tool to DDoS attacks that "drop packets based on rapid reaction tool to DDoS attacks that "drop packets based on
source IP address that can be pushed out to over 60 routers with in source IP address that can be pushed out to over 60 routers with in
60 seconds, be longer than a thousand lines, be modified on the fly, 60 seconds, be longer than a thousand lines, be modified on the fly,
and work in all your platforms filtering at line rate." The secondary and work in all your platforms filtering at line rate". The
benefits of using uRPF Loose Check for other functions is a secondary secondary benefits of using uRPF Loose Check for other functions is a
benefit - not the primary goal for its creation. secondary benefit -- not the primary goal for its creation.
To facilitate the adoption to the industry, uRPF Loose Check was not To facilitate the adoption to the industry, uRPF Loose Check was not
patented. It was publicly published and disclosed in "Unicast Reverse patented. It was publicly published and disclosed in "Unicast
PathForwarding (uRPF) Enhancements for the ISP-ISP Edge" Reverse PathForwarding (uRPF) Enhancements for the ISP-ISP Edge"
[Greene2001]. [Greene2001].
Authors' Addresses Authors' Addresses
Warren Kumari Warren Kumari
Google Google
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
Email: warren@kumari.net
EMail: warren@kumari.net
Danny McPherson Danny McPherson
Arbor Networks, Inc. Arbor Networks, Inc.
Email: danny@arbor.net
EMail: danny@arbor.net
 End of changes. 79 change blocks. 
271 lines changed or deleted 262 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/