Internet DRAFT - draft-ng-sobgp-bgp-extensions
draft-ng-sobgp-bgp-extensions
Network Working Group James Ng
Internet Draft (editor)
Expiration Date: October 2004 Cisco Systems
File Name: draft-ng-sobgp-bgp-extensions-02.txt April 2004
Extensions to BGP to Support Secure Origin BGP (soBGP)
draft-ng-sobgp-bgp-extensions-02.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet Drafts are working documents of the Internet Engineering
Task Force (IETF), its Areas, and its Working Groups. Note that other
groups may also distribute working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress".
The list of current Internet-Drafts can be accessed at
http//www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http//www.ietf.org/shadow.html.
1. Contributors
A large number of people contributed to or provided valuable feedback
on this document; we've tried to include all of them here (in no
particular order), but might have missed a few: Russ White, Alvaro
Retana, Dave Cook, John Scudder, David Ward, Martin Djernaes, Chris
Lonvick, Brian Weiss, Tim Gage, Scott Fanning, Barry Friedman, Jim
Duncan, Yi Yang, Robert Adams, Tony Tauber, Iljitsch van Beijnum, and
Jonathan Natale.
Ng, et al. [Page 1]
INTERNET DRAFT Secure Origin BGP (soBGP) April 2004
2. Abstract
There is a great deal of concern over the security of routing systems
within the Internet, particularly in relation to the Border Gateway
Protocol [BGP], which is used to provide routing information between
autonomous systems. This document proposes a system where the origin
of any advertisement within BGP can be verified and authenticated,
preventing the advertisement of prefix blocks by unauthorized
networks, and verifying that the final destination in the path is
actually within the autonomous system to which the packets are being
routed.
This document does not:
o Attempt to provide information on how such a security system
could or should be deployed; readers are referenced to [SOBGP-
DEPLOY] for this discussion.
o Attempt to determine what sorts of keys should be used within
such a system, nor how any sort of trust relationship can or
should be built between the entities cooperating within the
routing system. These are considered in [SOBGP-CERTIFICATE].
o Attempt to analyse the performance, memory utilization, or other
impacts on devices running this protocol; these are addressed in
[SOBGP-DEPLOY].
o Attempt to analyse the security protection provided by the pro-
posed security system.
This document primarily focuses on extensions to the BGP protocol
itself to support such a security system. This document is to solve
several vulnerabilities within a BGP routing system given the follow-
ing constraints and assumptions:
o Any signalling which must take place to provide security should
be specified in as flexible a way as possible. For instance, any
certificates exchanged may be solely contained with the BGP pro-
tocol, or through some other transport/distribution mechanism.
[SOBGP-DEPLOY] contains more discussion on this issue.
o The proposed solution should be incrementally deployable, and
require minimal changes in a network to support it (software
changes only along the path where support is required, for
instance).
o The proposed solution should not rely on the routing system it
is securing to reach information necessary to secure the routing
Ng, et al. [Page 2]
INTERNET DRAFT Secure Origin BGP (soBGP) April 2004
system (reliance on an IGP to reach destinations within a rout-
ing domain is acceptable, but reliance on BGP to reach destina-
tions outside the routing domain is unacceptable).
o The operator may configure various levels of trust, preferring
faster convergence over security validtion, or more immediate
and stronger security validation over convergence times.
o All routing information received from peering relationships
within an autonomous system is implicitly trusted.
o No current optimizations in implementations of the BGP protocol
should be affected, if possible.
It's important to note that any given security system is a tradeoff
between several factors, including the actual security provided and
the difficulty entailed in deploying the system; different solutions
may provide different levels of protection between these, leaving
some parts of the problem unsolved.
This proposal does not protect against:
o Attacks through all forms of autonomous system spoofing. This
proposal can be subverted if an attacker is able to masquerade
as an autonomous system under some network conditions. It is
assumed that management of inter-AS connections and policy
implementation can resolve these possible attacks.
o Path Authentication. While this system allows the path any given
update advertises to be checked against paths known to be valid,
it does not ensure this particular update provides the best
path. It is observed that there are many possible valid paths
within a BGP routing system, and BGP itself is designed to find
the correct path among the possible paths.
o Authentication of path attributes, such as the community and MED
attributes passed with a prefix.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this docu-
ment. For more information consult the online list of claimed rights.
Ng, et al. [Page 3]
INTERNET DRAFT Secure Origin BGP (soBGP) April 2004
3. Definitions
o Entity: A participant in the internetwork routing system.
4. The Security Message
This document proposes a new message type, the SECURITY message,
which is to be used for carrying security information within the BGP
protocol. The SECURITY message is type 6. The SECURITY message is
used to transport the certificates described in [SOBGP-CERTIFICATE].
4.1. Negotiating Security Capability
The ability to exchange SECURITY messages shall be negotiated at ses-
sion startup, as described in [CAPABILITY]. The capability code is
<to be assigned by IANA>. A pair of BGP speakers MAY negotiate to
send messages in the SECURITY message type only (exchange no NLRI or
forwarding information).
If two BGP speakers have negotiated to exchange SECURITY messages,
they should exchange the certificates contained in their local data-
bases.
If two speakers have negotiated to exchange SECURITY messages and
NLRI messages (as described in [BGP]), no NLRI or SECURITY informa-
tion SHOULD be transmitted by a speaker other than a SECURITY Option
message until it receives a SECURITY Option message from its peer.
4.2. The Security Message Format
The SECURITY message is formatted as described in [BGP], with a type
code of 6. Within each message is a series of TLVs, or security mes-
sage blocks, formatted as:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| Type | Length |
+-------------------------------+-------------------------------+
| Data |
+---------
o Type: A two octet unsigned integer describing the type of infor-
mation contained within the data field.
Ng, et al. [Page 4]
INTERNET DRAFT Secure Origin BGP (soBGP) April 2004
o Length: A two octet unsigned integer describing the length of
the data field, in octets.
o Data: The data, as described within this and other documents
which describe information to be carried within the SECURITY
message type.
Two TLVs are currently defined within the SECURITY message.
Further TLVs are defined for carrying certificates in [SOBGP-
CERTIFICATE].
4.2.1. The SECURITY Option TLV
The SECURITY Option TLV provides a way for exchanging speakers to
inform their peers about local configurations which may pertain to
the peering session. SECURITY Option TLVs are encapsulated within a
TLV Type 1, and transmitted within the SECURITY message type.
If SECURITY Option TLVs are transmitted, they MUST be transmitted
before the transmission of any other SECURITY data.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| TLV Type | Length |
+-------------------------------+-------------------------------+
| Options |
+---------------------------------------------------------------+
o TLV type: (2 octets), 1 (0x0001)
o Length: (2 octets), set to 2
o Options: (4 octets), a bitfield, described below
The options field is a 32 bit bitfield, allowing up to 32 different
options to be specified.
o Bit 0: If set, indicates that SECURITY information should be
sent before NLRI information on this session; if cleared, indi-
cates that NLRI information should be sent before SECURITY
information.
o Bit 1: If set, indicates that this peer will only transmit vali-
dated certificates of any type along this session (valid only on
iBGP sessions).
Ng, et al. [Page 5]
INTERNET DRAFT Secure Origin BGP (soBGP) April 2004
o Bit 2: If set, indicates that this peer will only accept vali-
dated certificates of any type along this session (valid only on
iBGP sessions).
Bit 0 in the option field allows the operator to configure the local
device so it receives all prefixes first, decreasing convergence to
the minimum time, or receives all SECURITY information first, allow-
ing all prefixes to be validated before they are installed.
Bits 1 and 2 allow peers along an iBGP session to trust the certifi-
cations they receive without validating them. If bit 1 is set on the
transmitting peer, and bit 2 is set on the receiving peer, the
receiving peer may accept all received certificates from the
transmitting peer as already validated.
4.2.2. The Request TLV
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| TLV Type | Request Type |
+-------------------------------+-------------------------------+
| Length | Reserved |
+-------------------------------+-------------------------------+
| Request Indicator SubTV |
+---------------------------
o TLV type: (2 octets), 2
o Request Type: (2 octets), treated as an unsigned integer indi-
cating the type of the type of information requested.
o Length: (2 octets), set to the total length of the request in
octets.
o Reserved: (2 octets), set to 0x0000.
o Request Indicator: The information indicated by the request type
bit field.
The Request Type field indicates the type of certificates requested.
Three request types are defined in this document.
1 Any certificate matching the Request Indicator are requested.
2 EntityCerts matching the Request Indicator are requested.
Ng, et al. [Page 6]
INTERNET DRAFT Secure Origin BGP (soBGP) April 2004
3 ASPolicyCerts matching the Request Indicator are requested.
4 PrefixPolicyCerts matching the Request Indicator are requested.
Request indicator SubTVs restrict the set of certificates returned;
there may be one or more request indicator SubTVs included in a
request. Each SubTV consists of a two octet type field, treated as an
unsigned integer, and a fixed length field containing the request
indicator.
o Type 1: A four octet origin/authorized AS Number; two octet AS
numbers shall be right justified within this field (placed in
the two least significant octets).
o Type 2: A four octet signer/authorizer AS Number; two octet AS
numbers shall be right justified within this field (placed in
the two least significant octets).
o Type 3: A four octet IPv4 address is included in the request
indicator.
o Type 4: A sixteen octet IPv6 address is included in the request
indicator.
o Type 5: An eight octet starting serial number is included in the
request indicator.
o Type 6: An eight octet ending serial number is included in the
request indicator.
5. Receiving and Processing SECURITY messages
The section sbelow describe the receipt and processing of SECURITY
messages.
5.1. The Level of Certificate Processing
Each section below describes the processing of SECURITY messages
based on the way in which soBGP is deployed on the BGP speaker. For
more information on deployment options, see [SOBGP-DEPLOY].
Ng, et al. [Page 7]
INTERNET DRAFT Secure Origin BGP (soBGP) April 2004
5.1.1. Full Local Certificate Processing
If a BGP speaker is fully processing certificates locally, for each
received certificate it must:
o The unique identifiers (described for each certificate type in
[SOBGP-CERTIFICATE] of any certificate received MUST be compared
to the unique identifiers of certificates already held in local
databases. Any certificate which matches a certificate already
held in a local database MUST be discarded.
o Certificates received from untrusted peers and certificates
received without the VALIDATED bit set SHOULD be placed in a
local certificate database, and processed according to [SOBGP-
CERTIFICATE].
o Certificates received from iBGP peers which have negotiated
trusted certificate exchange SHOULD placed in a local certifi-
cate database, and processed as though they were all sucessfully
validated according to the process described in [SOBGP-
CERTIFICATE].
o All certificates received and placed in the local certificate
database, and marked as validated, SHOULD be readvertised to all
iBGP peers which have a trusted peering relationship, marked as
VALIDATED. Signatures SHOULD be stripped from any certificate
advertised to an iBGP peer with a trusted peering relationship.
o All certificates received and placed in the local certificate
database, and not marked as validated, should be readvertised to
trusted iBGP peers; they MUST not be marked as VALIDATED.
o All certificates received and placed in the local certificate
database should be readvertised to all BGP peers which have
negotiated the untrusted exchange of soBGP certificates.
5.1.2. No Local Cryptographic Processing
If a BGP speaker is accepting certificates only from trusted peering
relationships, for each received certificate, it must:
o The unique identifiers (described for each certificate type in
[SOBGP-CERTIFICATE] of any certificate received MUST be compared
to the unique identifiers of certificates already held in local
databases. Any certificate which matches a certificate already
Ng, et al. [Page 8]
INTERNET DRAFT Secure Origin BGP (soBGP) April 2004
held in a local database MUST be discarded.
o Certificates received from iBGP peers which have negotiated
trusted certificate exchange and marked as VALIDATED must be
placed in a local certificate database, and processed as though
they were all sucessfully validated according to the process
described in [SOBGP-CERTIFICATE].
o Certificates received from any BGP peer which has not negotiated
trusted certificate exchange, and any received certificate which
is not marked as VALIDATED, should be readvertised to all BGP
peers which have not negotiated trusted certificate exchange.
These certificates MUST be discarded; they must not be stored
locally.
5.1.3. No Local Certificate Processing
If a BGP speaker is validating routing information through direct
interaction with another device performing soBGP processing, and is
not processing or storing certificates locally, for each soBGP certi-
ficate received, it must readvertise all certificates received from
any BGP peer to all other BGP peers which have negotiated soBGP cer-
tificate exchange through the SECURITY message. The BGP speaker MUST
NOT mark the readvertised certificates as VALIDATED.
5.2. Filtering of Certificates
A BGP speaker may, for reasons of policy, filter soBGP certificates
received from a peer.
o If a BGP speaker is part of a transit AS, it SHOULD NOT filter
soBGP certificates.
o A BGP speaker MAY discard soBGP certificates which describe the
authorization of address space which is being filtered out of
the local routing information.
5.3. Receiving and Processing Requests
If a device receives a Request TLV, as described in the section "The
Security Message," above, it should:
o Examine the request to ensure it is logically consistent. For
instance, requesting an Entitycert based on an IPv4 address
Ng, et al. [Page 9]
INTERNET DRAFT Secure Origin BGP (soBGP) April 2004
range is not logically consistent, since these certificates only
contain an AS and a Signer AS.
o If the request is not logically consistent, discard it.
o If the request is logically consistent, examine its local data-
bases, and transmit the certificates requested which fulfill the
conditions supplied in the request indicator SubTVs.
o If more than one of the same request indicator is included in a
request message, they shall be treated as an OR condition; if
any of the conditions match, the certificate shall match the
set.
6. Operation and General Requirements
This section discusses the processing of routing updates, validation
of the AS_PATH contained in routing updates, general BGP requirements
for autonomous systems running soBGP, and requirements for BGP ses-
sions exchanging soBGP certificates.
6.1. Receiving and Validating Prefixes
A local database of authorized prefix/origin AS/policy triples is
built using the techniques described in [SOBGP-CERTIFICATE], and used
to validate updates as they are received (or updates which exist in
the AdjRIB-In), as described in this section. This local database is
termed the "authorization database."
Since one of the goals of soBGP, stated at the beginning of this
document, is to impact the performance of the BGP protocol as little
as possible, there is no requirement to perform the steps outlined in
this section at any particular time in the processing of received BGP
updates. The validation of routes received may occur as these routes
are received, before they are placed in the Adj-RIB-In, periodically,
or some time after convergence has been attained, as determined by
configuration on the device validating the routes received.
o The local authorization database is examined, and the entries
with the longest prefix length which encompasses the range of
addresses described by the prefix is chosen.
o This set of entries is examined to determine if the route is
originated from one of the AS' listed in the set of entries.
Ng, et al. [Page 10]
INTERNET DRAFT Secure Origin BGP (soBGP) April 2004
o If the route is not originated from one of the AS' listed in the
set of entries, the route is said to be invalid, and should be
excluded from further consideration for installation in to the
local RIB.
o If the authorization database entry indicates the Second Hop
must be checked, the second hop of the AS PATH should be veri-
fied as described in the section "Verifying the Second Hop,"
below. If the second hop check fails, the route is said to be
invalid, and should be removed from further consideration for
installation into the local RIB.
o If the authorization database indicates the AS_PATH of the
update must be checked, the AS PATH of the route should be veri-
fied, as described in the section "Verifying the AS PATH,"
below. If the AS_PATH is not validated, the route should be
removbed from further consideration for installation in the
local RIB.
o Other policies contained in the local authorization database
should be applied as directed by the policy.
o If there is no entry in the local authorization database which
encompasses the range of addresses described by the prefix, then
the route is said to be unverified, and should be handled
according to local policy (either discarded, or have its secu-
rity preference lowered).
6.2. Aggregation
Aggregation is a difficult problem with any method which attempts to
verify the origin of any given prefix, since aggregation removes the
relationship between prefixes originated and originators. Prefixes
may only be aggregated by an entity which is otherwise authorized to
advertise the aggregated prefix.
6.3. Verifying the Path
In order to verify the path of any given advertisement, we propose to
build a directed graph of all possible transit paths within the
Internet, and verifying the path of each advertisement against this
graph. Note that for any given prefix, this graph will contain a
superset of all valid paths for the prefix. The BGP protocol itself
is designed to choose the correct path out of the possible paths.
In order to build the directed graph, each entity within the routing
Ng, et al. [Page 11]
INTERNET DRAFT Secure Origin BGP (soBGP) April 2004
system may advertise the autonomous systems it is connected to using
the attached AS' field carried in a certificate as described in
[SOBGP-CERTIFICATE]. This graph is called the PATH database.
6.3.1. Building and Using the Directed Graph
Each device verifying routing information it is receiving may build a
directed graph from the information contained in the Policy Certifi-
cate for each AS (as described above), which provides a list of all
known valid paths through the internetwork. Each link between a pair
of AS' may be verified from both ends of the link (using a two way
connectivity check), thus ensuring that no single AS may advertise
itself as connected to an entity it is not connected to.
As routes are validated, the AS PATH contained in the route may be
checked against the PATH database for congruence with a known good
path. If the AS PATH traverses a link which cannot be verified to
exist in both directions (the link fails the two way connectivity
check), it's security preference may be lowered or the route may be
discarded, as local device configuration directs.
6.4. Verifying the Second Hop
As a prefix is processed by a receiving the device, the originator
and second hop in the AS PATH may be checked against the authorized
originator and the list of attached AS' advertised by that origina-
tor. If the second hop in the AS path (the second entry in the AS
PATH) does not match one of the attached AS' advertised by the origi-
nator, the prefix should be treated as invalid, and discarded.
6.5. Requirements for Systems Running soBGP
There are three general requirements imposed on autonomous system
border routers and devices running soBGP:
o Any peering session along the border of an autonomous system
running soBGP SHOULD be authenticated through some means such as
[BGP-MD5], IPsec ([ESP], [AH]), or through some other current,
effective means of protecting BGP sessions from being hijaaked,
or otherwise abused.
o Any peering session along which soBGP certificates are exchanged
MUST be authenticated through some means such as [BGP-MD5],
IPsec ([ESP, [AH]), or through some other current, effective
Ng, et al. [Page 12]
INTERNET DRAFT Secure Origin BGP (soBGP) April 2004
means of protecting BGP sessions from being hijaaked, or other-
wise abused.
o The AS_PATH of any routing information received from any BGP
peer outside the autonomous system MUST be checked to validate
the next hop AS is the AS the update was received from. If the
next hop AS in any received update does not match the configured
AS the route is learned from, the update MUST be discarded.
7. The Security Preference
As indicated in other sections of this document, the user has a wide
range of flexibility when determining the level of security to be
applied to each prefix. The level of security may be translated into
a Security Preference and used to influence the route selection pro-
cess [BGP].
To determine the Secuirty Preference of a prefix, the following algo-
rithm may be used:
1 A Security Preference is assigned to each prefix indicating neu-
tral trust. The neutral value is locally significant to the
autonomous system, and all routers in it MUST use the same
value.
2 The Security Preference SHOULD be lowered for any of the follow-
ing cases:
o The AS_PATH verification failed at a link other than the
second hop.
o The Second Hop verification failed.
o The prefix is unverified.
o The prefix is invalid.
Each of these cases represents a different degree of failure in
the validation and verification process. The amount by which
the Security Preference is lowered is locally significant to the
autonomous system, and all routers in it MUST use the same
value. If the local policy determines that a prefix may be used
(even if it may have failed the validation and verification pro-
cess), it is recommended that the Security Preference be lowered
such that a lower value is assigned to invalid paths.
3 The Security Preference SHOULD be increased for any of the
Ng, et al. [Page 13]
INTERNET DRAFT Secure Origin BGP (soBGP) April 2004
following cases:
o The prefix is validated.
o The Second Hop verification passed.
o The AS_PATH verification passed for the whole path.
The amount by which the Security Preference is increased is
locally significant to the autonomous system, and all routers in
it MUST use the same value. It is recommended that the Security
Preference be increased such that a higher value is assigned to
paths that pass all the validation and verification steps.
The resulting Security Preference value may be used to select among
different routes for the same prefix; the higher value MUST be pre-
ferred. Any of the following methods may be used:
A Consider the Security Preference prior to calculating the degree
of preference [BGP] for a prefix.
B Assign the value of the Security Preference to any of the attri-
butes used in the Decision Process [BGP]. Care must be taken
with attributes for which the lower value is preferred.
C Use a Cost Community [COST] and its associated methods to con-
sider the Security Preference at any step in the Decision Pro-
cess [BGP] without overloading other attributes. Care must be
taken as the lowest value in a Cost Community is preferred.
The method selected MUST be consistent through the local Autonomous
System.
8. Security Considerations
This document defines extensions to BGP that address specific secu-
rity concerns for the protocol. While it adds functionality, the
flexilibty allows it to not introduce any new security concerns.
Ng, et al. [Page 14]
INTERNET DRAFT Secure Origin BGP (soBGP) April 2004
9. IANA Considerations
This document defines the Security Message for BGP, which contains a
series of TLVs. IANA is expected to maintain a registry of all the
values defined, as follows:
The SECURITY message Type field :
o Type value 0 is reserved.
o Type values 1 and 2 are assigned in this document.
o Type values 3 through 16575 MUST be assigned using the "IETF
Consensus" policy defined in RFC2434 [RFC2434].
o Type values 16576 through 32895 SHOULD be assigned using the
"Specification Required" policy defined in RFC2434 [RFC2434].
o Type values 32896 through 65535 are for "Private Use" as defined
in RFC2434 [RFC2434].
Request TLV Request Type Field:
o Bits 1 through 3 are assigned in this document.
o Bits 4 thru 8 MUST be assigned using the "IETF Consensus" pol-
icy defined in RFC2434 [RFC2434].
o Bits 9 thru 16 are for "Private Use" as defined in RFC2434
[RFC2434].
10. Normative References
[BGP] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995.
[MULTIPROTOCOL-BGP]
Bates, T., Chandra, R., Katz, D., and Rekhter, Y., "Multiproto-
col Extensions for BGP-4", RFC 2858, June 2000
[CAPABILITY]
Chandra, R., Scudder, J., "Capabilities Advertisement with BGP-
4", RFC2842, May 2000
[SOBGP-DEPLOY]
White, R. (editor), "Architecture and Deployment Considerations
for Secure Origin BGP (soBGP) Deployment", draft-white-sobgp-
Ng, et al. [Page 15]
INTERNET DRAFT Secure Origin BGP (soBGP) April 2004
deployment-02, April 2004
[SOBGP-CERTIFICATE]
Weiss, Brian (editor), "Secure Origin BGP (soBGP) Certificates",
draft-weis-sobgp-certificates-01.txt, October 2003
11. Informative References
[COST]
Retana, A., White, R., "BGP Custom Decision Process", draft-
retana-bgp-custom-decision-00, October 2002.
[RFC2434]
Narten, T., Alvestrand, H., "Guidelines for Writing an IANA Con-
siderations Section in RFCs", RFC 2434, October 1998.
[BGP-MD5]
Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Sig-
nature Option", RFC2385, August 1998
[ESP] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload",
RFC 2406, November 1998.
[AH] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[SOBGP-RADIUS]
Lovnick, C, "RADIUS Attributes for soBGP Support", draft-
lonvick-sobgp-radius-04.txt, February 2004
12. Editor's Address
James Ng (Editor)
Cisco Systems
7025 Kit Creek Road
Research Triangle Park, NC 27709
jamng@cisco.com
Ng, et al. [Page 16]
