idnits 2.17.1 draft-ymbk-grow-blackholing-01.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 (July 29, 2015) is 3194 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 271 == Outdated reference: A later version (-12) exists of draft-ietf-idr-ix-bgp-route-server-07 == 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: January 30, 2016 J. Snijders 6 NTT 7 G. Doering 8 SpaceNet AG 9 G. Hankins 10 Alcatel-Lucent 11 July 29, 2015 13 BLACKHOLE BGP Community for Blackholing 14 draft-ymbk-grow-blackholing-01 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 January 30, 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 mechanism 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 as 108 o implementing and monitoring blackholing gets easier if 109 implementation and operational guides do not cover many options to 110 trigger blackholing 111 o the amount 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 a new well-known BGP transitive 121 community, BLACKHOLE. 123 The semantics of this attribute is to allow a network to interpret 124 the presence of this community as an advisory qualification to drop 125 any 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 destinated 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 communities to prevent propagation of this route outside the local 142 AS. 144 Unintentional leaking of more specific IP prefixes to neighboring 145 networks can have adverse effects. Extreme caution should be used 146 when purposefully propagating IP prefixes tagged with the BLACKHOLE 147 BGP community outside the local routing domain. 149 3.3. Accepting Blackholed IP Prefixes 151 It has been observed announcements of IP prefixes larger than /24 for 152 IPv4 and /48 for IPv6 are usually not accepted on the Internet (see 153 section 6.1.3 [RFC7454]). However, blackhole routes should be as 154 small as possible in order to limit the impact of discarding traffic 155 for adjacent IP space that is not under DDoS duress. Typically, the 156 blackhole route's prefix length is as specific as /32 for IPv4 and 157 /128 for IPv6. 159 BGP speakers SHOULD only accept and honor BGP announcements carrying 160 the BLACKHOLE community if the announced prefix is covered by a 161 shorter prefix for which the neighboring network is authorized to 162 advertise. 164 3.4. IXPs: Peering at Route Servers 166 Many IXPs provide the so-called policy control feature as part of 167 their route servers [I-D.ietf-idr-ix-bgp-route-server] (see e.g. the 168 LINX website [1]). Policy control allows members to specify by using 169 BGP communities which ASNs connected to the route server receive a 170 particular BGP announcement. 172 Combined usage of the BGP communities for blackholing and policy 173 control allows a fine-grained control of a blackhole. 175 In some implementations of blackholing at IXPs, the route server 176 after receiving a BGP announcement tagged with the BLACKHOLE BGP 177 community rewrites the next-hop IP address to the pre-defined 178 blackholing IP address before redistributing the announcement. 180 4. IANA Considerations 182 The IANA is requested to register BLACKHOLE as a well-known BGP 183 community with global significance: 185 BLACKHOLE (= 0xFFFF029A) 187 The low-order two octets in decimal are 666, amongst IP network 188 operators a value commonly associated with BGP blackholing. 190 5. Security Considerations 192 BGP contains no specific mechanism to prevent the unauthorized 193 modification of information by the forwarding agent. This allows 194 routing information to be modified, removed, or false information to 195 be added by forwarding agents. Recipients of routing information are 196 not able to detect this modification. Also, RPKI [RFC6810] and 197 BGPSec [I-D.ietf-sidr-bgpsec-overview] do not fully resolve this 198 situation. For instance, BGP communities can still be added or 199 altered by a forwarding agent even if RPKI and BGPSec are in place. 201 The BLACKHOLE BGP community does not alter this situation. 203 A new additional attack vector is introduced into BGP by using the 204 BLACKHOLE BGP community: denial of service attacks for IP prefixes. 206 Unauthorized addition of the BLACKHOLE BGP community to an IP prefix 207 by a forwarding agent may cause a denial of service attack based on 208 denial of reachability. The denial of service will happen if an IP 209 network or IXP offering blackholing is traversed. However, denial of 210 service attack vectors to BGP are not new as the injection of false 211 routing information is already possible. 213 In order to further limit the impact of unauthorized BGP 214 announcements carrying the BLACKHOLE BGP community the receiving BGP 215 speaker SHOULD verify by applying strict filtering (see section 216 6.2.1.1.2. [RFC7454]) that the peer announcing the prefix is 217 authorized to do so. If not, the BGP announcement should be filtered 218 out. 220 The presence of this BLACKHOLE BGP community may introduce a resource 221 exhaustion attack to BGP speakers. If a BGP speaker receives many IP 222 prefixes containing the BLACKHOLE BGP community its internal 223 resources such as CPU power and/or memory might get consumed, 224 especially if usual prefix sanity checks (e.g. such as IP prefix 225 length or number of prefixes) are disabled (see Section 3.3). 227 6. References 229 6.1. Normative References 231 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 232 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 233 . 235 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 236 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 237 RFC2119, March 1997, 238 . 240 6.2. Informative References 242 [I-D.ietf-idr-ix-bgp-route-server] 243 Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, 244 "Internet Exchange BGP Route Server", draft-ietf-idr-ix- 245 bgp-route-server-07 (work in progress), June 2015. 247 [I-D.ietf-sidr-bgpsec-overview] 248 Lepinski, M., "An Overview of BGPsec", draft-ietf-sidr- 249 bgpsec-overview-07 (work in progress), June 2015. 251 [RFC3882] Turk, D., "Configuring BGP to Block Denial-of-Service 252 Attacks", RFC 3882, DOI 10.17487/RFC3882, September 2004, 253 . 255 [RFC5635] Kumari, W. and D. McPherson, "Remote Triggered Black Hole 256 Filtering with Unicast Reverse Path Forwarding (uRPF)", 257 RFC 5635, DOI 10.17487/RFC5635, August 2009, 258 . 260 [RFC6810] Bush, R. and R. Austein, "The Resource Public Key 261 Infrastructure (RPKI) to Router Protocol", RFC 6810, DOI 262 10.17487/RFC6810, January 2013, 263 . 265 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations 266 and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, 267 February 2015, . 269 6.3. URIs 271 [1] https://www.linx.net/members/support/route-servers.html 273 Appendix A. Acknowledgements 275 The authors gratefully acknowledges the contributions of: 277 o Petr Jiran, NIX.CZ, Milesovska 1136/5, Praha 130 00, Czech 278 Republic, Email: pj@nix.cz 279 o Yordan Kritski, NetIX Ltd., 3 Grigorii Gorbatenko Str., Sofia 280 1784, Bulgaria, Email: ykritski@netix.net 281 o Christian Seitz, STRATO AG, Pascalstr. 10, Berlin 10587, Germany, 282 Email: seitz@strato.de 284 Authors' Addresses 286 Thomas King 287 DE-CIX Management GmbH 288 Lichtstrasse 43i 289 Cologne 50825 290 Germany 292 Email: thomas.king@de-cix.net 294 Christoph Dietzel 295 DE-CIX Management GmbH 296 Lichtstrasse 43i 297 Cologne 50825 298 Germany 300 Email: christoph.dietzel@de-cix.net 302 Job Snijders 303 NTT Communications, Inc. 304 Theodorus Majofskistraat 100 305 Amsterdam 1065 SZ 306 NL 308 Email: job@ntt.net 310 Gert Doering 311 SpaceNet AG 312 Joseph-Dollinger-Bogen 14 313 Munich 80807 314 Germany 316 Email: gert@space.net 318 Greg Hankins 319 Alcatel-Lucent 320 777 E. Middlefield Road 321 Mountain View, CA 94043 322 USA 324 Email: greg.hankins@alcatel-lucent.com