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]
