Internet Engineering Task Force C. Gray Internet-Draft S. Mansoor Intended status: Standards Track Bangor University Expires: January 27, 2016 July 26, 2015 An Exceptions Capability for Distributed Null-Routing in BGP draft-cgray-ietf-bgpexceptions-00 Abstract There is not currently any standardized method of dealing with distributed or other large scale threats other than individual firewall and/or null routing instructions. This Internet Draft describes an optional BGP Capability (as defined by RFC 5492) that allowed Autonomous Systems to self-censor utilizing the existing Inter-Domain Routing system. This capability does not add any automatic actions and must be explicitly activated by an administrator. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months 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." This Internet-Draft will expire on January 27, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Gray & Mansoor Expires January 27, 2016 [Page 1] Internet-Draft BGP Exceptions July 2015 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. BGP Exceptions . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Motivations . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Protocol Extensions . . . . . . . . . . . . . . . . . . . 4 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Local Configuration Settings . . . . . . . . . . . . . . 5 3.2. Operation Modes . . . . . . . . . . . . . . . . . . . . . 5 3.3. Exception BGP Path Attribute Format . . . . . . . . . . . 6 3.4. Withdrawn Routes & NLRI Fields . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 6.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Dealing with either large scale, or distributed abuse traffic is far from a standard process. Some upstream providers offer Community based announcement controls, others offer ad-hoc blocking based on a support request. Some existing options takes the control away from the attacked network administrators. Whilst in some situations these solutions can suffice, collateral damage cannot be avoided. The current Inter-Domain Routing system, namely BGP, is fundamentally designed to deliver packets around obstacles. As there is no centralized control, it confounds most attempts to prevent that delivery. In the event of a distributed and/or large scale attack this traffic is not desired, however providers attempt to deliver the packets anyway. Smaller ASs, which tend to be leaf nodes in the Internet graph, have a vested interest in avoiding this traffic which can effectively disconnect them, if sufficiently large. For every AS in the middle, there is little point in incurring the cost of delivery when it would be dropped at the destination anyway. In order to equip network administrators with necessary tools to defend against modern threats, this Internet Draft proposes a new Capability-based overlay to BGP. The primary motivation is to stop attacks (however the recipient defines it) as close to the source(s) as possible. Gray & Mansoor Expires January 27, 2016 [Page 2] Internet-Draft BGP Exceptions July 2015 The overlay distributes exceptions, smaller prefixes than any AS originate that should specifically be null-routed, as a different type of prefix/route. These exceptions MUST be signed using the Resource PKI specification RFC 3779 [RFC3779] and RFC 6480 [RFC6480] to prove authenticity. As a different form of routing update, this approach sidesteps the need to de-aggregate announcements and limits the potential for routing table size explosion. (Although the necessary growth depending on usage is expected.) By delivering the exceptions in this form, hardware manufacturers are able to reuse the existing TCAM architectures, bypassing most CPU processing. As an optional capability that is subject to the usual negotiation process, the overlay/capability can be rolled out gradually negating the need for a mass, coordinated upgrade. However, this capability will only become useful once a critical mass has been achieved. We expect that market forces, from content providers initially, would drive further uptake until near-universal support is achieved. We also expect that some providers, especially so-called "Bulletproof" hosts, will attempt to actively avoid the protections that this capability would provide. This document sets out three possible operation modes that MUST be supported; suggested configuration options that are RECOMMENDED and details of possible side-effects that MAY need to be addressed. Fundamentally, the operation modes differ in where the null-route SHALL be installed. The modes take into account that any provider may either ignore, circumvent or not support this capability. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. BGP Exceptions BGP Exceptions are individual null-routing requests propagated through the BGP Internet routing infrastructure as a new attribute of the BGP UPDATE message. 2.1. Motivations By most (or even all) accounts [ARBOR] [F5DDOS], the size and scale of distributed packet attacks is growing year-on-year. The current organizational structure of Autonomous Systems does not lend itself to a universal response to these threats. Creation and near- universal application of such a response, could lead to the end of this type of threat. Gray & Mansoor Expires January 27, 2016 [Page 3] Internet-Draft BGP Exceptions July 2015 Secondly, apart from the biggest Tier 1 providers, there is an economic cost to these forms of attacks. Both the originating providers and the recipient provider will have to meet the costs. Even if the transit is provided settlement-free, all concerned would still be required to build out their infrastructures to cope with the extra throughput. 2.2. Protocol Extensions 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. Any New BGP speaker uses BGP Capabilities Announcements [RFC5492] to advertise its support for using BGP Exceptions to its neighbors (either internal or external) as detailed in that document. The speaker MUST include the maximum configured exception size (as an integer number of bits) in the Capability Value field of the announcement. Neighbors MAY choose to fail negotiation of this capability if the sizes are not equal or less than their locally configured parameter. Assuming the capability is negotiated and enabled: o A New BGP speaker MAY emit BGP UPDATE messages utilizing the Exception BGP Path Attribute for any prefix smaller than the locally configured maximum. The value of this attribute MUST be one of the valid operation modes, see the Operation Modes section (Section 3.2), and if in any other mode than GB the target AS of the null route. o A New BGP speaker MUST be capable of receiving BGP UPDATE messages which include the Exception BGP Path Attribute. The message MUST be relayed to other neighbors except where the target AS field is the local AS (in AC operation mode) or the the target AS is the foreign AS in (HC operation mode). 3. Operation This section describes the basic operation of BGP speakers when using the BGP Exceptions Capability. Packet and field formats follow later in this section. Gray & Mansoor Expires January 27, 2016 [Page 4] Internet-Draft BGP Exceptions July 2015 3.1. Local Configuration Settings This subsection provides details of local configuration attributes that all New BGP speakers are RECOMMENDED to have. It is also recommended that the attributes be made available in the global BGP context as well as available for overriding on a per session basis. This subsection does not limit other configuration options as long as they do not interfere with other operational requirements. These limits are independent, the final outcome is the result of a logical AND on the individual filter results - i.e. all filters must be satisfied to accept the exception request. o Maximum Exception Size This attribute is a single 6-bit unsigned value (0-127), representing the maximum length (inclusive) of an excluded prefix that this speaker will accept. A value of 0 or the attribute being unset implies no limit. This is not extended to 128 as all compliant devices MUST accept single IP (/32 for IPv4 and /128 for IPv6) prefixes. A value greater than 31 MUST NOT be accepted for an IPv4 session. o Maximum Exception Count Accepted Per-AS This attribute is a single unsigned byte value (0-255), representing the maximum number (count) of exception instructions to accept from a single AS. Note: this is based on the originating AS, not the AS the exception was learnt from. A value of 0 or the attribute not being set implies no limit. o Maximum Lifetime Per-Exception This attribute is a single unsigned short (0-65535), representing the maximum number of minutes any single exception can be in force for. This attribute is only checked when the originating AS places a temporal restriction on their exception. Whilst the maximum value supported by the data type is 65535, implementations are RECOMMENDED to restrict this maximum to 44640 (the number of minutes in a 30 day month). A value of 0 or unset implies no limit. 3.2. Operation Modes There are three modes implementations of the Capability MUST support. 1. Active Collaborator (AC) Mode Gray & Mansoor Expires January 27, 2016 [Page 5] Internet-Draft BGP Exceptions July 2015 An active collaborator is an AS that is being trusted to police their own users by placing the null routing instruction at or within their own borders. In this mode the external border speakers will receive the instructions targeting that AS. They SHALL honor all the null routes unless the request violates conditions set in their local configuration. (The only valid conditions for rejection are those specified in this document.) As the target AS is performing the filtering, the only ASs REQUIRED to retain the exception in their RIB are the target AS and those with configured external sessions to the target. 2. Hostile Target (HT) Mode A hostile target is an AS that either cannot be trusted to enforce the null-routing instruction or is actively violating it. In this mode all ASs with a external BGP session with the target AS MUST NOT accept packets matching the exception, from the target AS on the ingress interface. This applies equally to transit, upstream, downstream or peer session types. In this mode only those with a session with the target AS are REQUIRED to keep the exception in their RIB, no matter the current status of that session. 3. Global Block (GB) Mode In the Global Block mode, there is no target AS specified in the Exception Path Attribute. All New BGP speakers are REQUIRED to honor the Exception and null-route the prefix specified unless the request violates conditions set in their local configuration. As such, all New BGP speakers SHALL retain the exception in their RIB. 3.3. Exception BGP Path Attribute Format As a standard BGP Path Attribute the general pattern is; 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O|T|P|E| U | ATTRIB CODE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For the BGP Exception Path Attribute, the value of O (Optional) MUST be 1, T (Transitive) MUST be 1, P (Partial) MUST be 0, E (Extended) MUST be 0. The U elements are unused and MUST be set to 0. The one byte Attribute Code will be assigned by IANA. This combination of options results in an Optional-Transitive Complete Attribute with a length not exceeding the capacity of one unsigned byte. Gray & Mansoor Expires January 27, 2016 [Page 6] Internet-Draft BGP Exceptions July 2015 The length of a BGP Exception Path Attribute will depend only on the target AS. If the two New BGP speakers have negotiated the 4-byte ASN [RFC6793] capability, that format will also be used in the Exception Path Attribute. The result is that the path attribute will be; a) 19 bits (Temporal Global Block or non-temporal 2 byte target ASN), b) 35 bits (Non-Temporal 4 byte target ASN or c) 51 bits (Temporal 4 byte target ASN). 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | M |T| Temporal Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T L| TAS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TAS| 4AS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |4AS| +-+-+ M is the mode for this Exception; 0 = AC, 1 = HT, 2 = GB. T is the temporal bit. If T = 0 (not-set); there is no temporal length so the speaker SHOULD NOT expect the two-byte Temporal Length field. TAS is the target AS number (2 byte form), this field will be set for either AC or HT modes. 4AS is the extension field used when 4 byte ASNs are correctly negotiated and required. 3.4. Withdrawn Routes & NLRI Fields The Withdrawn Routes and Network Layer Reachability Information fields of the Exception UPDATE message are laid out and formatted as in a normal BGP UPDATE message. This includes support for AFIs and SAFIs, variable prefix lengths, etc. The data contained in these fields are the prefixes that the originating AS wishes to be censored. The prefixes must equal or be contained by a prefix originated by that AS as part of a network statement. This capability DOES NOT permit upstream providers to re- originate Exceptions for downstream customers. 4. IANA Considerations This specification will require an assignment of a well-known BGP Capability Code from http://www.iana.org/assignments/capability- codes/capability-codes.xhtml [CAPCODE]. IANA are also requested to assign an Optional-Transitive BGP Path Attribute Code from http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml [BGPPARAM]. Gray & Mansoor Expires January 27, 2016 [Page 7] Internet-Draft BGP Exceptions July 2015 5. Security Considerations As this capability involves preventing traffic flow across the Internet, the security concerns are paramount. The essential element is establishing ownership and/or control of Internet resources. Without checking this ownership any party could inject an exception for any range preventing access. The advent and rise of Resource Authorization using the RPKI system [RFC3779] gives an ideal platform. All Exception UPDATE messages must be signed with the appropriate certificate issued for the containing IP block by the responsible Regional Internet Registry (RIR). The signature SHOULD be verified using the RPKI to Router protocol as specified in RFC 6810 [RFC6810]. In addition, the exception MUST be matched to a containing or equal prefix in the BGP speaker's RIB. The originating AS Numbers MUST match to be accepted as a valid BGP Exception. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, DOI 10.17487/RFC3779, June 2004, . [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 2009, . [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, . [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, DOI 10.17487/RFC6793, December 2012, . Gray & Mansoor Expires January 27, 2016 [Page 8] Internet-Draft BGP Exceptions July 2015 [RFC6810] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol", RFC 6810, DOI 10.17487/RFC6810, January 2013, . 6.2. Informative References [ARBOR] Arbor Networks Inc., "Arbor Networks Detects Largest Ever DDoS Attack in Q1 2015 DDoS Report", White Paper, April 2015. [BGPPARAM] IANA, "Border Gateway Protocol (BGP) Parameters", 2015, . [CAPCODE] IANA, "Well-Known BGP Capability Codes Registry", 2015, . [F5DDOS] Lyon, B., "DDoS 2015: Understanding the Current and Pending DDoS Threat Landscape", White Paper, January 2015. Authors' Addresses Cameron C. Gray Bangor University School of Computer Science, Dean Street Bangor, Gwynedd LL57 1UT UK Phone: +44 1248 382686 Email: c.gray@bangor.ac.uk Sa'ad P. Mansoor Bangor University School of Computer Science, Dean Street Bangor, Gwynedd LL57 1UT UK Phone: +44 1248 382686 Email: s.mansoor@bangor.ac.uk Gray & Mansoor Expires January 27, 2016 [Page 9]