idnits 2.17.1 draft-ietf-grow-blackholing-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (November 9, 2015) is 3091 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 270 == Outdated reference: A later version (-12) exists of draft-ietf-idr-ix-bgp-route-server-09 == Outdated reference: A later version (-08) exists of draft-ietf-sidr-bgpsec-overview-07 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. King 3 Internet-Draft C. Dietzel 4 Intended status: Standards Track DE-CIX Management GmbH 5 Expires: May 12, 2016 J. Snijders 6 NTT 7 G. Doering 8 SpaceNet AG 9 G. Hankins 10 Alcatel-Lucent 11 November 9, 2015 13 BLACKHOLE BGP Community for Blackholing 14 draft-ietf-grow-blackholing-00 16 Abstract 18 This document describes the use of a well-known Border Gateway 19 Protocol (BGP) community for blackholing at IP networks and Internet 20 Exchange Points (IXP). This well-known advisory transitive BGP 21 community, namely BLACKHOLE, allows an origin AS to specify that a 22 neighboring IP network or IXP should blackhole a specific IP prefix. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to 28 be interpreted as described in [RFC2119] only when they appear in all 29 upper case. They may also appear in lower or mixed case as English 30 words, without normative meaning. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on May 12, 2016. 49 Copyright Notice 51 Copyright (c) 2015 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. BLACKHOLE Attribute . . . . . . . . . . . . . . . . . . . . . 3 68 3. Operational Recommendations . . . . . . . . . . . . . . . . . 3 69 3.1. IP Prefix Announcements with BLACKHOLE Community Attached 3 70 3.2. Local Scope of Blackholes . . . . . . . . . . . . . . . . 3 71 3.3. Accepting Blackholed IP Prefixes . . . . . . . . . . . . 4 72 3.4. IXPs: Peering at Route Servers . . . . . . . . . . . . . 4 73 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 75 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 77 6.2. Informative References . . . . . . . . . . . . . . . . . 6 78 6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 82 1. Introduction 84 The network infrastructure has been getting hammered by DDoS attacks 85 for years. In order to block DDoS attacks, IP networks have offered 86 BGP blackholing to neighboring networks (iBGP scenarios [RFC3882] and 87 RTBH filtering [RFC5635]), much like some IXPs have recently started 88 to do. 90 DDoS attacks targeting a certain IP network may cause congestion of 91 links used to connect to other networks. In order to limit the 92 impact of such a scenario on legitimate traffic, IP networks and IXPs 93 adopted a mechanism called BGP blackholing. A network that wants to 94 trigger blackholing needs to understand the triggering mechanism 95 adopted by its neighboring IP networks and IXPs. Different IP 96 networks and IXPs provide different BGP mechanisms to trigger 97 blackholing, including pre-defined blackhole next- hop IP addresses 98 and pre-defined BGP communities. 100 Having several different mechanisms to trigger blackholing at 101 different IP networks and IXPs makes it an unnecessarily complex, 102 error-prone and cumbersome task for network operators. Therefore a 103 well-known BGP community [RFC1997] is defined for operational ease. 105 Having such a well-known BGP community for blackholing also supports 106 IP networks and IXPs because 108 o implementing and monitoring blackholing gets easier if 109 implementation and operational guides do not cover many options 110 that trigger blackholing 111 o the number of support requests from customers about how to trigger 112 blackholing at a particular IP network or IXP will be reduced as 113 the mechanism is unified 115 Making it considerably easier for network operators to utilize 116 blackholing makes operations easier. 118 2. BLACKHOLE Attribute 120 This document defines the use of a new well-known BGP transitive 121 community, BLACKHOLE. 123 The semantics of this attribute allow a network to interpret the 124 presence of this community as an advisory qualification to drop any 125 traffic being sent towards this prefix. 127 3. Operational Recommendations 129 3.1. IP Prefix Announcements with BLACKHOLE Community Attached 131 When an IP network is under DDoS duress, it MAY announce an IP prefix 132 covering the victim's IP address(es) for the purpose of signaling to 133 neighboring IP networks or IXPs that any traffic destined for these 134 IP address(es) should be discarded. In such a scenario, the network 135 operator SHOULD attach BLACKHOLE BGP community. 137 3.2. Local Scope of Blackholes 139 A BGP speaker receiving a BGP announcement tagged with the BLACKHOLE 140 BGP community SHOULD add a NO_ADVERTISE, NO_EXPORT or similar 141 community to prevent propagation of this route outside the local AS. 143 Unintentional leaking of more specific IP prefixes to neighboring 144 networks can have adverse effects. Extreme caution should be used 145 when purposefully propagating IP prefixes tagged with the BLACKHOLE 146 BGP community outside the local routing domain. 148 3.3. Accepting Blackholed IP Prefixes 150 It has been observed that announcements of IP prefixes larger than 151 /24 for IPv4 and /48 for IPv6 are usually not accepted on the 152 Internet (see section 6.1.3 [RFC7454]). However, blackhole routes 153 should be as small as possible in order to limit the impact of 154 discarding traffic for adjacent IP space that is not under DDoS 155 duress. Typically, the blackhole route's prefix length is as 156 specific as /32 for IPv4 and /128 for IPv6. 158 BGP speakers SHOULD only accept and honor BGP announcements carrying 159 the BLACKHOLE community if the announced prefix is covered by a 160 shorter prefix for which the neighboring network is authorized to 161 advertise. 163 3.4. IXPs: Peering at Route Servers 165 Many IXPs provide the so-called policy control feature as part of 166 their route servers [I-D.ietf-idr-ix-bgp-route-server] (see e.g. the 167 LINX website [1]). Policy control allows members to specify, by 168 using BGP communities, which ASNs connected to the route server 169 receive a particular BGP announcement. 171 Combined usage of the BGP communities for blackholing and policy 172 control allows a fine-grained control of a blackhole. 174 In some implementations of blackholing at IXPs, the route server 175 after receiving a BGP announcement tagged with the BLACKHOLE BGP 176 community rewrites the next-hop IP address to the pre-defined 177 blackholing IP address before redistributing the announcement. 179 4. IANA Considerations 181 The IANA is requested to register BLACKHOLE as a well-known BGP 182 community with global significance: 184 BLACKHOLE (= 0xFFFF029A) 186 The low-order two octets in decimal are 666, amongst IP network 187 operators a value commonly associated with BGP blackholing. 189 5. Security Considerations 191 BGP contains no specific mechanism to prevent the unauthorized 192 modification of information by the forwarding agent. This allows 193 routing information to be modified, removed, or false information to 194 be added by forwarding agents. Recipients of routing information are 195 not able to detect this modification. Also, RPKI [RFC6810] and 196 BGPSec [I-D.ietf-sidr-bgpsec-overview] do not fully resolve this 197 situation. For instance, BGP communities can still be added or 198 altered by a forwarding agent even if RPKI and BGPSec are in place. 200 The BLACKHOLE BGP community does not alter this situation. 202 A new additional attack vector is introduced into BGP by using the 203 BLACKHOLE BGP community: denial of service attacks for IP prefixes. 205 The unauthorized addition of the BLACKHOLE BGP community to an IP 206 prefix by a forwarding agent may cause a denial of service attack 207 based on denial of reachability. The denial of service will happen 208 if an IP network or IXP offering blackholing is traversed. However, 209 denial of service attack vectors to BGP are not new as the injection 210 of false routing information is already possible. 212 In order to further limit the impact of unauthorized BGP 213 announcements carrying the BLACKHOLE BGP community, the receiving BGP 214 speaker SHOULD verify by applying strict filtering (see section 215 6.2.1.1.2. [RFC7454]) that the peer announcing the prefix is 216 authorized to do so. If not, the BGP announcement should be filtered 217 out. 219 The presence of this BLACKHOLE BGP community may introduce a resource 220 exhaustion attack to BGP speakers. If a BGP speaker receives many IP 221 prefixes containing the BLACKHOLE BGP community, its internal 222 resources such as CPU power and/or memory might get consumed, 223 especially if usual prefix sanity checks (e.g. such as IP prefix 224 length or number of prefixes) are disabled (see Section 3.3). 226 6. References 228 6.1. Normative References 230 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 231 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 232 . 234 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 235 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 236 RFC2119, March 1997, 237 . 239 6.2. Informative References 241 [I-D.ietf-idr-ix-bgp-route-server] 242 Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, 243 "Internet Exchange BGP Route Server", draft-ietf-idr-ix- 244 bgp-route-server-09 (work in progress), October 2015. 246 [I-D.ietf-sidr-bgpsec-overview] 247 Lepinski, M., "An Overview of BGPsec", draft-ietf-sidr- 248 bgpsec-overview-07 (work in progress), June 2015. 250 [RFC3882] Turk, D., "Configuring BGP to Block Denial-of-Service 251 Attacks", RFC 3882, DOI 10.17487/RFC3882, September 2004, 252 . 254 [RFC5635] Kumari, W. and D. McPherson, "Remote Triggered Black Hole 255 Filtering with Unicast Reverse Path Forwarding (uRPF)", 256 RFC 5635, DOI 10.17487/RFC5635, August 2009, 257 . 259 [RFC6810] Bush, R. and R. Austein, "The Resource Public Key 260 Infrastructure (RPKI) to Router Protocol", RFC 6810, DOI 261 10.17487/RFC6810, January 2013, 262 . 264 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations 265 and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, 266 February 2015, . 268 6.3. URIs 270 [1] https://www.linx.net/members/support/route-servers.html 272 Appendix A. Acknowledgements 274 The authors gratefully acknowledges the contributions of: 276 o Petr Jiran, NIX.CZ, Milesovska 1136/5, Praha 130 00, Czech 277 Republic, Email: pj@nix.cz 278 o Yordan Kritski, NetIX Ltd., 3 Grigorii Gorbatenko Str., Sofia 279 1784, Bulgaria, Email: ykritski@netix.net 280 o Christian Seitz, STRATO AG, Pascalstr. 10, Berlin 10587, Germany, 281 Email: seitz@strato.de 283 Authors' Addresses 285 Thomas King 286 DE-CIX Management GmbH 287 Lichtstrasse 43i 288 Cologne 50825 289 Germany 291 Email: thomas.king@de-cix.net 293 Christoph Dietzel 294 DE-CIX Management GmbH 295 Lichtstrasse 43i 296 Cologne 50825 297 Germany 299 Email: christoph.dietzel@de-cix.net 301 Job Snijders 302 NTT Communications, Inc. 303 Theodorus Majofskistraat 100 304 Amsterdam 1065 SZ 305 NL 307 Email: job@ntt.net 309 Gert Doering 310 SpaceNet AG 311 Joseph-Dollinger-Bogen 14 312 Munich 80807 313 Germany 315 Email: gert@space.net 317 Greg Hankins 318 Alcatel-Lucent 319 777 E. Middlefield Road 320 Mountain View, CA 94043 321 USA 323 Email: greg.hankins@alcatel-lucent.com