| < draft-kumari-blackhole-urpf-00.txt | draft-kumari-blackhole-urpf-01.txt > | |||
|---|---|---|---|---|
| Internet Draft W. Kumari | Internet Draft W. Kumari | |||
| <draft-kumari-blackhole-urpf-00.txt> Google | <draft-kumari-blackhole-urpf-01.txt> Google | |||
| Category: Informational D. McPherson | Category: Informational D. McPherson | |||
| Expires: January 31, 2008 Arbor Networks | Expires: March 27, 2009 Arbor Networks | |||
| July 31, 2008 | September 27, 2008 | |||
| Triggered black-hole routing with uRPF | ||||
| <draft-kumari-blackhole-urpf-00.txt> | Remote Triggered Black Hole filtering with uRPF | |||
| <draft-kumari-blackhole-urpf-01.txt> | ||||
| Status of this Memo | Status of this Memo | |||
| Distribution of this memo is unlimited. | Distribution of this memo is unlimited. | |||
| 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. | |||
| skipping to change at page 1, line 38 ¶ | skipping to change at page 1, line 39 ¶ | |||
| or to cite them other than as "work in progress." | 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/1id-abstracts.html | http://www.ietf.org/1id-abstracts.html | |||
| 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. | |||
| Abstract | Abstract | |||
| Remote triggered black hole (RTBH) routing is a popular and effective | Remote Triggered Black Hole (RTBH) filtering is a popular and effective | |||
| technique for the mitigation of denial of service attacks. This document | technique for the mitigation of denial of service attacks. This document | |||
| expands upon destination-based remote triggered black hole routing by | expands upon destination-based RTBH filtering by outlining a method to | |||
| outlining a method to enable filtering by source address as well. It | enable filtering by source address as well. It also defines a standard | |||
| also defines a standard BGP community for black hole prefixes to | BGP community for black hole prefixes to simplify associated semantics. | |||
| simplify associated semantics. | ||||
| Table of Contents | Table of Contents | |||
| 1. Introduction ....................................................2 | 1. Introduction ....................................................2 | |||
| 2. Background ......................................................2 | 2. Background ......................................................2 | |||
| 3. Destination address RTBH filtering ..............................3 | 3. Destination address RTBH filtering ..............................3 | |||
| 3.1. Overview ...................................................3 | 3.1. Overview ...................................................3 | |||
| 3.2. Detail .....................................................3 | 3.2. Detail .....................................................3 | |||
| 4. Source address RTBH filtering ...................................4 | 4. Source address RTBH filtering ...................................4 | |||
| 5. Security Considerations .........................................6 | 5. Security Considerations .........................................6 | |||
| skipping to change at page 2, line 25 ¶ | skipping to change at page 2, line 25 ¶ | |||
| 7. Acknowledgments .................................................7 | 7. Acknowledgments .................................................7 | |||
| 8. References ......................................................7 | 8. References ......................................................7 | |||
| A. Cisco Router Configuration Sample................................8 | A. Cisco Router Configuration Sample................................8 | |||
| B. Juniper Configuration Sample....................................10 | B. Juniper Configuration Sample....................................10 | |||
| 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] and presents a method | to Block Denial-of-Service Attacks" [RFC3882] and presents a method | |||
| to allow filtering by source address. It also defines a standard BGP | to allow filtering by source address. It also defines a standard BGP | |||
| community to signal that Remote Triggered Black Hole (RTBH) routing | community to signal that Remote Triggered Black Hole (RTBH) filtering | |||
| should occur for a network. | should occur for a network. | |||
| 2. Background | 2. Background | |||
| Denial of Service (DoS) attacks that starve out legitimate traffic by | Denial of Service (DoS) attacks that starve out legitimate traffic by | |||
| saturating circuits are becoming an increasingly common occurrence. | saturating circuits are becoming an increasingly common occurrence. | |||
| Network operators have developed a selection of techniques for | Network operators have developed a selection of techniques for | |||
| mitigating these attacks. Different techniques have different | mitigating these attacks. Different techniques have different | |||
| strengths and weaknesses -- the selection of which technique to use | strengths and weaknesses -- the selection of which technique to use | |||
| for each type of attack involves tradeoffs. | for each type of attack involves tradeoffs. | |||
| skipping to change at page 3, line 8 ¶ | skipping to change at page 3, line 8 ¶ | |||
| provides a large amount of flexibility in the filtering, it runs into | provides a large amount of flexibility in the filtering, it runs into | |||
| scalability issues, both in terms of the number of entries in the | scalability issues, both in terms of the number of entries in the | |||
| filter and the packet rate. | 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 are able to hold many more forwarding | |||
| table entries and routes than filter entries. RTBH leverages the | table entries and routes than filter entries. RTBH leverages the | |||
| forwarding performance of modern routers to filter both more entries | forwarding performance of modern routers to filter both more entries | |||
| and at a higher rate than access control lists would allow. | and at a higher rate than access control lists would allow. | |||
| However, with destination-based RTBH routing, the impact is that you | However, with destination-based RTBH filtering, the impact is that | |||
| effectively complete the attack. That is, with destination-based | you effectively complete the attack. That is, with destination-based | |||
| blackhole routing you inject a discard route into the forwarding | RTBH filtering you inject a discard route into the forwarding table | |||
| table for the prefix in question. All packets towards that | for the prefix in question. All packets towards that destination, | |||
| destination, attack traffic AND legitimate traffic, are then dropped | attack traffic AND legitimate traffic, are then dropped by the | |||
| by the participating routers, thereby taking the target completely | participating routers, thereby taking the target completely offline. | |||
| offline. The benefit is that collateral damage to other systems or | The benefit is that collateral damage to other systems or network | |||
| network availability at the customer location or in the ISP network | availability at the customer location or in the ISP network is | |||
| is limited, but the negative impact to the target itself is arguably | limited, but the negative impact to the target itself is arguably | |||
| increased. | increased. | |||
| By coupling unicast reverse path forwarding (RPF) [REF] techniques | By coupling unicast reverse path forwarding (RPF) [REF] techniques | |||
| with RTBH, BGP can be used to distribute discard routes that are | with RTBH, BGP can be used to distribute discard routes that are | |||
| based not on destination or target addresses, but based on source | based not on destination or target addresses, but based on source | |||
| addresses. | addresses. | |||
| 3. Destination address RTBH filtering | 3. Destination address RTBH filtering | |||
| 3.1. Overview | 3.1. Overview | |||
| skipping to change at page 5, line 27 ¶ | skipping to change at page 5, line 27 ¶ | |||
| holing based upon source address desirable. | holing based upon source address desirable. | |||
| By combining traditional RTBH filtering with unicast Reverse Path | By combining traditional RTBH filtering with unicast Reverse Path | |||
| Forwarding (uRPF [RFC3704]) a network operator can filter based upon | Forwarding (uRPF [RFC3704]) a network operator can filter based upon | |||
| source address. uRPF performs a route lookup of the source address of | source address. uRPF performs a route lookup of the source address of | |||
| the packet and checks to see if the ingress interface of the packet | the packet and checks to see if the ingress interface of the packet | |||
| is a valid egress interface for the packet source address (strict | is a valid egress interface for the packet source address (strict | |||
| mode) or if any route or the source address of the packet exists | mode) or if any route or the source address of the packet exists | |||
| (loose mode). If the check fails, the packet is (generally) dropped. | (loose mode). If the check fails, the packet is (generally) dropped. | |||
| In loose mode some vendors also verify that the destination route | In loose mode some vendors also verify that the destination route | |||
| does not point to a discard interface. | does not point to a discard interface - this allows source based RTBH | |||
| filtering to be deployed in networks that cannot implement strict (or | ||||
| feasible path) mode uRPF. | ||||
| By enabling the uRPF feature on interfaces on pre-determined points | By enabling the uRPF feature on interfaces on pre-determined points | |||
| of their network and announcing the source address(es) of attack | of their network and announcing the source address(es) of attack | |||
| traffic, a network operator can effectively drop the attack traffic | traffic, a network operator can effectively drop the attack traffic | |||
| at the edge of their network based on source addresses. | at the edge of their network based on source addresses. | |||
| Note: This will block all traffic sourced from the attacking | Note: This will block all traffic sourced from the attacking | |||
| addresses and may cause collateral damage that exceeds the benefit of | addresses and may cause collateral damage that exceeds the benefit of | |||
| this technique. Announcing space (even within your own network) that | this technique. Announcing space (even within your own network) that | |||
| you don't control is bad form -- the decision to use this technique | you don't control is bad form -- the decision to use this technique | |||
| should not be taken lightly. | should not be taken lightly. | |||
| 4.1 Steps to deploy RTBH w/ uRPF for source filtering. | 4.1 Steps to deploy RTBH w/ 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 the community [IANA - INSERT | is announced using BGP tagged with a community. This will cause the | |||
| REGISTERED COMMUNITY HERE]. This will cause the route to be | route to be installed with a next hop of the discard interface, | |||
| installed with a next hop of the discard interface, causing the uRPF | causing the uRPF check to fail. The destination based RTBH filtering | |||
| check to fail. | community ([IANA - INSERT REGISTERED COMMUNITY HERE]) should not be | |||
| used for source based RTBH filtering, and the routes tagged with the | ||||
| selected 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 current AS and should carry the | must NOT be propagated outside the current 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 | |||
| skipping to change at page 6, line 31 ¶ | skipping to change at page 6, line 35 ¶ | |||
| - 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 within the announcement falls with the address ranges | contained within the announcement falls with the address ranges | |||
| controlled by the announcing AS (i.e.: for customer that the address | controlled by the announcing AS (i.e.: for customer that the address | |||
| falls within their space). | falls within their space). | |||
| 6. IANA Considerations | 6. IANA Considerations | |||
| This document requests registration of a regular Type, non-transitive | This document requests registration of a regular Type, non-transitive | |||
| BGP Extended Communities Attribute [RFC4360] from the First Come, | BGP Extended Communities Attribute [RFC4360] from the First Come, | |||
| First Served range to be named "Remote Triggered Black Hole Filter" | First Served range to be named "Remote Triggered Black Hole Filter". | |||
| This community will provide a standard method to signal a provider | ||||
| that RTBH filtering should occur for a destination and will eliminate | ||||
| the need for customers to track different communities for each | ||||
| provider. | ||||
| 7. Acknowledgments | 7. Acknowledgments | |||
| I would like to thank Joel Jaeggli, Joe Abley and Danny McPherson for | I would like to thank Joel Jaeggli, Joe Abley and Danny McPherson for | |||
| their assistance, feedback and not laughing *too* much at the quality | their assistance, feedback and not laughing *too* much at the quality | |||
| of the initial drafts. I would also like to thank all regular | of the initial drafts. I would also like to thank all regular | |||
| contributors to the OpSec Working Group and Google for 20% time :-) | contributors to the OpSec Working Group and Google for 20% time :-) | |||
| The authors are not aware of who initially developed this technique, | The authors are not aware of who initially developed this technique, | |||
| but would like to thank Chris Morrow for publicizing it. | but would like to thank Chris Morrow for publicizing it. | |||
| skipping to change at page 8, line 9 ¶ | skipping to change at page 8, line 9 ¶ | |||
| 8.2. Informative References | 8.2. Informative References | |||
| [2223BIS] Reynolds, J. and R. Braden, "Instructions to Request for | [2223BIS] Reynolds, J. and R. Braden, "Instructions to Request for | |||
| Comments (RFC) Authors", draft-rfc-editor- | Comments (RFC) Authors", draft-rfc-editor- | |||
| rfc2223bis-08.txt, August 2004. | rfc2223bis-08.txt, August 2004. | |||
| Appendix A: Cisco Router Configuration Sample | Appendix A: Cisco Router Configuration Sample | |||
| This section provides a partial configuration for configuring RTBH on | This section provides a partial configuration for configuring RTBH on | |||
| a Cisco router. This is not a complete configuration and should be | a Cisco router. This is not a complete configuration and should be | |||
| customized for before being used. | 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 the tag 666 and sets the next-hop | ! This route-map matches routes with the tag 666 and sets the next-hop | |||
| ! to be the discard route. | ! to be the discard route. | |||
| route-map remote-trigger-black-hole permit 10 | route-map remote-trigger-black-hole permit 10 | |||
| skipping to change at page 8, line 36 ¶ | skipping to change at page 8, line 36 ¶ | |||
| set origin igp | set origin igp | |||
| ! | ! | |||
| route-map remote-trigger-black-hole permit 20 | route-map remote-trigger-black-hole permit 20 | |||
| ! | ! | |||
| router bgp 65505 | router bgp 65505 | |||
| no synchronization | no synchronization | |||
| bgp log-neighbor-changes | bgp log-neighbor-changes | |||
| redistribute static route-map remote-trigger-black-hole | redistribute static route-map remote-trigger-black-hole | |||
| no auto-summary | no auto-summary | |||
| ! | ! | |||
| ! An example IP that we are applying RTBH routing to. | ! An example IP that we are applying RTBH filtering to. | |||
| ! All traffic destined to 10.0.0.1 will now be dropped! | ! All traffic destined to 10.0.0.1 will now be dropped! | |||
| ip route 10.0.0.1 255.255.255.255 null0 tag 666 | ip route 10.0.0.1 255.255.255.255 null0 tag 666 | |||
| ! | ! | |||
| Filtering router: | Filtering 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. | |||
| skipping to change at page 9, line 4 ¶ | skipping to change at page 9, line 5 ¶ | |||
| ! 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 ^$ | |||
| ! | ! | |||
| route-map black-hole-filter permit 10 | route-map black-hole-filter permit 10 | |||
| match ip address prefix-list only-host-routes | match ip address prefix-list only-host-routes | |||
| match as-path 10 | match as-path 10 | |||
| match community 65505:666 no-export | match community 65505:666 no-export | |||
| ! | ! | |||
| ! 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 with uRPF loose mode. | ||||
| interface FastEthernet 0/0 | ||||
| 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 on | This section provides a partial configuration for configuring RTBH on | |||
| a Juniper router. This is not a complete configuration and should be | a Juniper router. This is not a complete configuration and should be | |||
| customized for before being used. | customized for before being used. | |||
| Announcing router: | Announcing router: | |||
| routing-options { | routing-options { | |||
| static { | static { | |||
| # The discard route. | # The discard route. | |||
| route 192.0.2.1/32 discard; | route 192.0.2.1/32 discard; | |||
| # An example route to be RTBH filtered. | # An example route to be RTBH filtered. | |||
| route 10.0.0.1/32 { | route 10.0.0.1/32 { | |||
| next-hop 192.0.2.1; | next-hop 192.0.2.1; | |||
| resolve; | resolve; | |||
| tag 666; | tag 666; | |||
| } | } | |||
| } | } | |||
| autonomous-system 65505; | autonomous-system 65505; | |||
| } | } | |||
| protocols { | protocols { | |||
| bgp { | bgp { | |||
| import remote-trigger-black-hole; | import remote-trigger-black-hole; | |||
| local-as 65505; | local-as 65505; | |||
| } | } | |||
| } | } | |||
| policy-options { | policy-options { | |||
| policy-statement remote-trigger-black-hole { | policy-statement remote-trigger-black-hole { | |||
| term black-hole-filter { | term black-hole-filter { | |||
| skipping to change at page 11, line 11 ¶ | skipping to change at page 11, line 11 ¶ | |||
| community black-hole members 65505:666; | community black-hole members 65505:666; | |||
| community no-export members no-export; | community no-export members no-export; | |||
| } | } | |||
| Filtering router: | Filtering router: | |||
| routing-options { | routing-options { | |||
| static { | static { | |||
| # The discard route. | # The discard route. | |||
| route 192.0.2.1/32 discard; | route 192.0.2.1/32 discard; | |||
| } | } | |||
| autonomous-system 65505; | autonomous-system 65505; | |||
| # Enable feasible-paths mode uRPF. | ||||
| forwarding-table { | ||||
| unicast-reverse-path feasible-paths; | ||||
| } | ||||
| } | } | |||
| protocols { | protocols { | |||
| bgp { | bgp { | |||
| group iBGP { | group iBGP { | |||
| import black-hole-filter; | import black-hole-filter; | |||
| } | } | |||
| } | } | |||
| } | } | |||
| policy-options { | policy-options { | |||
| policy-statement black-hole-filter { | policy-statement black-hole-filter { | |||
| skipping to change at page 11, line 37 ¶ | skipping to change at page 11, line 41 ¶ | |||
| } | } | |||
| then { | then { | |||
| community set no-export; | community set no-export; | |||
| next-hop 192.0.2.1; | next-hop 192.0.2.1; | |||
| } | } | |||
| } | } | |||
| community black-hole members 65505:666; | community black-hole members 65505:666; | |||
| community no-export members no-export; | community no-export members no-export; | |||
| as-path LocalOnly "^$"; | as-path LocalOnly "^$"; | |||
| } | } | |||
| # Enable uRPF on an interface for source based uRPF. | ||||
| interfaces { | ||||
| so-0/0/0 { | ||||
| unit 0 { | ||||
| family inet { | ||||
| rpf-check; | ||||
| } | ||||
| } | ||||
| } | ||||
| } | ||||
| Authors' Addresses | Authors' Addresses | |||
| Warren Kumari | Warren Kumari | |||
| 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 | |||
| End of changes. 17 change blocks. | ||||
| 31 lines changed or deleted | 56 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||