idnits 2.17.1 draft-cgray-ietf-bgpexceptions-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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: For the purposes of this specification we define any BGP speaker which does not support the Exceptions capability as 'Old BGP' and those that can negotiate this capability as 'New BGP'. If a session is between an Old BGP and New BGP speaker, or two New BGP speakers with the Exceptions capability is disable; both speakers MUST not send an Exceptions UPDATE message. If an errant message is passed through a session that does not have the Exception capability negotiated, this message MUST not be passed on - even if the message is otherwise syntactically and semantically valid. -- The document date (July 26, 2015) is 3197 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) ** Downref: Normative reference to an Informational RFC: RFC 6480 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force C. Gray 3 Internet-Draft S. Mansoor 4 Intended status: Standards Track Bangor University 5 Expires: January 27, 2016 July 26, 2015 7 An Exceptions Capability for Distributed Null-Routing in BGP 8 draft-cgray-ietf-bgpexceptions-00 10 Abstract 12 There is not currently any standardized method of dealing with 13 distributed or other large scale threats other than individual 14 firewall and/or null routing instructions. This Internet Draft 15 describes an optional BGP Capability (as defined by RFC 5492) that 16 allowed Autonomous Systems to self-censor utilizing the existing 17 Inter-Domain Routing system. This capability does not add any 18 automatic actions and must be explicitly activated by an 19 administrator. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 27, 2016. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. BGP Exceptions . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Motivations . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.2. Protocol Extensions . . . . . . . . . . . . . . . . . . . 4 60 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. Local Configuration Settings . . . . . . . . . . . . . . 5 62 3.2. Operation Modes . . . . . . . . . . . . . . . . . . . . . 5 63 3.3. Exception BGP Path Attribute Format . . . . . . . . . . . 6 64 3.4. Withdrawn Routes & NLRI Fields . . . . . . . . . . . . . 7 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 69 6.2. Informative References . . . . . . . . . . . . . . . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 Dealing with either large scale, or distributed abuse traffic is far 75 from a standard process. Some upstream providers offer Community 76 based announcement controls, others offer ad-hoc blocking based on a 77 support request. Some existing options takes the control away from 78 the attacked network administrators. Whilst in some situations these 79 solutions can suffice, collateral damage cannot be avoided. 81 The current Inter-Domain Routing system, namely BGP, is fundamentally 82 designed to deliver packets around obstacles. As there is no 83 centralized control, it confounds most attempts to prevent that 84 delivery. In the event of a distributed and/or large scale attack 85 this traffic is not desired, however providers attempt to deliver the 86 packets anyway. Smaller ASs, which tend to be leaf nodes in the 87 Internet graph, have a vested interest in avoiding this traffic which 88 can effectively disconnect them, if sufficiently large. For every AS 89 in the middle, there is little point in incurring the cost of 90 delivery when it would be dropped at the destination anyway. In 91 order to equip network administrators with necessary tools to defend 92 against modern threats, this Internet Draft proposes a new 93 Capability-based overlay to BGP. The primary motivation is to stop 94 attacks (however the recipient defines it) as close to the source(s) 95 as possible. 97 The overlay distributes exceptions, smaller prefixes than any AS 98 originate that should specifically be null-routed, as a different 99 type of prefix/route. These exceptions MUST be signed using the 100 Resource PKI specification RFC 3779 [RFC3779] and RFC 6480 [RFC6480] 101 to prove authenticity. As a different form of routing update, this 102 approach sidesteps the need to de-aggregate announcements and limits 103 the potential for routing table size explosion. (Although the 104 necessary growth depending on usage is expected.) By delivering the 105 exceptions in this form, hardware manufacturers are able to reuse the 106 existing TCAM architectures, bypassing most CPU processing. As an 107 optional capability that is subject to the usual negotiation process, 108 the overlay/capability can be rolled out gradually negating the need 109 for a mass, coordinated upgrade. However, this capability will only 110 become useful once a critical mass has been achieved. We expect that 111 market forces, from content providers initially, would drive further 112 uptake until near-universal support is achieved. We also expect that 113 some providers, especially so-called "Bulletproof" hosts, will 114 attempt to actively avoid the protections that this capability would 115 provide. 117 This document sets out three possible operation modes that MUST be 118 supported; suggested configuration options that are RECOMMENDED and 119 details of possible side-effects that MAY need to be addressed. 120 Fundamentally, the operation modes differ in where the null-route 121 SHALL be installed. The modes take into account that any provider 122 may either ignore, circumvent or not support this capability. 124 1.1. Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC 2119 [RFC2119]. 130 2. BGP Exceptions 132 BGP Exceptions are individual null-routing requests propagated 133 through the BGP Internet routing infrastructure as a new attribute of 134 the BGP UPDATE message. 136 2.1. Motivations 138 By most (or even all) accounts [ARBOR] [F5DDOS], the size and scale 139 of distributed packet attacks is growing year-on-year. The current 140 organizational structure of Autonomous Systems does not lend itself 141 to a universal response to these threats. Creation and near- 142 universal application of such a response, could lead to the end of 143 this type of threat. 145 Secondly, apart from the biggest Tier 1 providers, there is an 146 economic cost to these forms of attacks. Both the originating 147 providers and the recipient provider will have to meet the costs. 148 Even if the transit is provided settlement-free, all concerned would 149 still be required to build out their infrastructures to cope with the 150 extra throughput. 152 2.2. Protocol Extensions 154 For the purposes of this specification we define any BGP speaker 155 which does not support the Exceptions capability as 'Old BGP' and 156 those that can negotiate this capability as 'New BGP'. If a session 157 is between an Old BGP and New BGP speaker, or two New BGP speakers 158 with the Exceptions capability is disable; both speakers MUST not 159 send an Exceptions UPDATE message. If an errant message is passed 160 through a session that does not have the Exception capability 161 negotiated, this message MUST not be passed on - even if the message 162 is otherwise syntactically and semantically valid. 164 Any New BGP speaker uses BGP Capabilities Announcements [RFC5492] to 165 advertise its support for using BGP Exceptions to its neighbors 166 (either internal or external) as detailed in that document. The 167 speaker MUST include the maximum configured exception size (as an 168 integer number of bits) in the Capability Value field of the 169 announcement. Neighbors MAY choose to fail negotiation of this 170 capability if the sizes are not equal or less than their locally 171 configured parameter. 173 Assuming the capability is negotiated and enabled: 175 o A New BGP speaker MAY emit BGP UPDATE messages utilizing the 176 Exception BGP Path Attribute for any prefix smaller than the 177 locally configured maximum. The value of this attribute MUST be 178 one of the valid operation modes, see the Operation Modes section 179 (Section 3.2), and if in any other mode than GB the target AS of 180 the null route. 182 o A New BGP speaker MUST be capable of receiving BGP UPDATE messages 183 which include the Exception BGP Path Attribute. The message MUST 184 be relayed to other neighbors except where the target AS field is 185 the local AS (in AC operation mode) or the the target AS is the 186 foreign AS in (HC operation mode). 188 3. Operation 190 This section describes the basic operation of BGP speakers when using 191 the BGP Exceptions Capability. Packet and field formats follow later 192 in this section. 194 3.1. Local Configuration Settings 196 This subsection provides details of local configuration attributes 197 that all New BGP speakers are RECOMMENDED to have. It is also 198 recommended that the attributes be made available in the global BGP 199 context as well as available for overriding on a per session basis. 201 This subsection does not limit other configuration options as long as 202 they do not interfere with other operational requirements. These 203 limits are independent, the final outcome is the result of a logical 204 AND on the individual filter results - i.e. all filters must be 205 satisfied to accept the exception request. 207 o Maximum Exception Size 209 This attribute is a single 6-bit unsigned value (0-127), 210 representing the maximum length (inclusive) of an excluded prefix 211 that this speaker will accept. A value of 0 or the attribute 212 being unset implies no limit. This is not extended to 128 as all 213 compliant devices MUST accept single IP (/32 for IPv4 and /128 for 214 IPv6) prefixes. A value greater than 31 MUST NOT be accepted for 215 an IPv4 session. 217 o Maximum Exception Count Accepted Per-AS 219 This attribute is a single unsigned byte value (0-255), 220 representing the maximum number (count) of exception instructions 221 to accept from a single AS. Note: this is based on the 222 originating AS, not the AS the exception was learnt from. A value 223 of 0 or the attribute not being set implies no limit. 225 o Maximum Lifetime Per-Exception 227 This attribute is a single unsigned short (0-65535), representing 228 the maximum number of minutes any single exception can be in force 229 for. This attribute is only checked when the originating AS 230 places a temporal restriction on their exception. Whilst the 231 maximum value supported by the data type is 65535, implementations 232 are RECOMMENDED to restrict this maximum to 44640 (the number of 233 minutes in a 30 day month). A value of 0 or unset implies no 234 limit. 236 3.2. Operation Modes 238 There are three modes implementations of the Capability MUST support. 240 1. Active Collaborator (AC) Mode 241 An active collaborator is an AS that is being trusted to police 242 their own users by placing the null routing instruction at or 243 within their own borders. In this mode the external border 244 speakers will receive the instructions targeting that AS. They 245 SHALL honor all the null routes unless the request violates 246 conditions set in their local configuration. (The only valid 247 conditions for rejection are those specified in this document.) 248 As the target AS is performing the filtering, the only ASs 249 REQUIRED to retain the exception in their RIB are the target AS 250 and those with configured external sessions to the target. 252 2. Hostile Target (HT) Mode 254 A hostile target is an AS that either cannot be trusted to 255 enforce the null-routing instruction or is actively violating it. 256 In this mode all ASs with a external BGP session with the target 257 AS MUST NOT accept packets matching the exception, from the 258 target AS on the ingress interface. This applies equally to 259 transit, upstream, downstream or peer session types. In this 260 mode only those with a session with the target AS are REQUIRED to 261 keep the exception in their RIB, no matter the current status of 262 that session. 264 3. Global Block (GB) Mode 266 In the Global Block mode, there is no target AS specified in the 267 Exception Path Attribute. All New BGP speakers are REQUIRED to 268 honor the Exception and null-route the prefix specified unless 269 the request violates conditions set in their local configuration. 270 As such, all New BGP speakers SHALL retain the exception in their 271 RIB. 273 3.3. Exception BGP Path Attribute Format 275 As a standard BGP Path Attribute the general pattern is; 277 0 1 278 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 |O|T|P|E| U | ATTRIB CODE | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 For the BGP Exception Path Attribute, the value of O (Optional) MUST 284 be 1, T (Transitive) MUST be 1, P (Partial) MUST be 0, E (Extended) 285 MUST be 0. The U elements are unused and MUST be set to 0. The one 286 byte Attribute Code will be assigned by IANA. This combination of 287 options results in an Optional-Transitive Complete Attribute with a 288 length not exceeding the capacity of one unsigned byte. 290 The length of a BGP Exception Path Attribute will depend only on the 291 target AS. If the two New BGP speakers have negotiated the 4-byte 292 ASN [RFC6793] capability, that format will also be used in the 293 Exception Path Attribute. The result is that the path attribute will 294 be; a) 19 bits (Temporal Global Block or non-temporal 2 byte target 295 ASN), b) 35 bits (Non-Temporal 4 byte target ASN or c) 51 bits 296 (Temporal 4 byte target ASN). 298 0 1 299 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | M |T| Temporal Length | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 |T L| TAS | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 |TAS| 4AS | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 |4AS| 308 +-+-+ 310 M is the mode for this Exception; 0 = AC, 1 = HT, 2 = GB. T is the 311 temporal bit. If T = 0 (not-set); there is no temporal length so the 312 speaker SHOULD NOT expect the two-byte Temporal Length field. TAS is 313 the target AS number (2 byte form), this field will be set for either 314 AC or HT modes. 4AS is the extension field used when 4 byte ASNs are 315 correctly negotiated and required. 317 3.4. Withdrawn Routes & NLRI Fields 319 The Withdrawn Routes and Network Layer Reachability Information 320 fields of the Exception UPDATE message are laid out and formatted as 321 in a normal BGP UPDATE message. This includes support for AFIs and 322 SAFIs, variable prefix lengths, etc. 324 The data contained in these fields are the prefixes that the 325 originating AS wishes to be censored. The prefixes must equal or be 326 contained by a prefix originated by that AS as part of a network 327 statement. This capability DOES NOT permit upstream providers to re- 328 originate Exceptions for downstream customers. 330 4. IANA Considerations 332 This specification will require an assignment of a well-known BGP 333 Capability Code from http://www.iana.org/assignments/capability- 334 codes/capability-codes.xhtml [CAPCODE]. IANA are also requested to 335 assign an Optional-Transitive BGP Path Attribute Code from 336 http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml 337 [BGPPARAM]. 339 5. Security Considerations 341 As this capability involves preventing traffic flow across the 342 Internet, the security concerns are paramount. The essential element 343 is establishing ownership and/or control of Internet resources. 344 Without checking this ownership any party could inject an exception 345 for any range preventing access. The advent and rise of Resource 346 Authorization using the RPKI system [RFC3779] gives an ideal 347 platform. 349 All Exception UPDATE messages must be signed with the appropriate 350 certificate issued for the containing IP block by the responsible 351 Regional Internet Registry (RIR). The signature SHOULD be verified 352 using the RPKI to Router protocol as specified in RFC 6810 [RFC6810]. 353 In addition, the exception MUST be matched to a containing or equal 354 prefix in the BGP speaker's RIB. The originating AS Numbers MUST 355 match to be accepted as a valid BGP Exception. 357 6. References 359 6.1. Normative References 361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 362 Requirement Levels", BCP 14, RFC 2119, 363 DOI 10.17487/RFC2119, March 1997, 364 . 366 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 367 Addresses and AS Identifiers", RFC 3779, 368 DOI 10.17487/RFC3779, June 2004, 369 . 371 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 372 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 373 2009, . 375 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 376 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 377 February 2012, . 379 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 380 Autonomous System (AS) Number Space", RFC 6793, 381 DOI 10.17487/RFC6793, December 2012, 382 . 384 [RFC6810] Bush, R. and R. Austein, "The Resource Public Key 385 Infrastructure (RPKI) to Router Protocol", RFC 6810, 386 DOI 10.17487/RFC6810, January 2013, 387 . 389 6.2. Informative References 391 [ARBOR] Arbor Networks Inc., "Arbor Networks Detects Largest Ever 392 DDoS Attack in Q1 2015 DDoS Report", White Paper, April 393 2015. 395 [BGPPARAM] 396 IANA, "Border Gateway Protocol (BGP) Parameters", 2015, 397 . 400 [CAPCODE] IANA, "Well-Known BGP Capability Codes Registry", 2015, 401 . 404 [F5DDOS] Lyon, B., "DDoS 2015: Understanding the Current and 405 Pending DDoS Threat Landscape", White Paper, January 406 2015. 408 Authors' Addresses 410 Cameron C. Gray 411 Bangor University 412 School of Computer Science, Dean Street 413 Bangor, Gwynedd LL57 1UT 414 UK 416 Phone: +44 1248 382686 417 Email: c.gray@bangor.ac.uk 419 Sa'ad P. Mansoor 420 Bangor University 421 School of Computer Science, Dean Street 422 Bangor, Gwynedd LL57 1UT 423 UK 425 Phone: +44 1248 382686 426 Email: s.mansoor@bangor.ac.uk