Internet DRAFT - draft-cgray-ietf-bgpexceptions

draft-cgray-ietf-bgpexceptions







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,
              <http://www.rfc-editor.org/info/rfc2119>.

   [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,
              <http://www.rfc-editor.org/info/rfc3779>.

   [RFC5492]  Scudder, J. and R. Chandra, "Capabilities Advertisement
              with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February
              2009, <http://www.rfc-editor.org/info/rfc5492>.

   [RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
              Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
              February 2012, <http://www.rfc-editor.org/info/rfc6480>.

   [RFC6793]  Vohra, Q. and E. Chen, "BGP Support for Four-Octet
              Autonomous System (AS) Number Space", RFC 6793,
              DOI 10.17487/RFC6793, December 2012,
              <http://www.rfc-editor.org/info/rfc6793>.







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,
              <http://www.rfc-editor.org/info/rfc6810>.

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,
              <http://www.iana.org/assignments/bgp-parameters/
              bgp-parameters.xhtml>.

   [CAPCODE]  IANA, "Well-Known BGP Capability Codes Registry", 2015,
              <http://www.iana.org/assignments/capability-codes/
              capability-codes.xhtml>.

   [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]