One document matched: draft-ng-sobgp-bgpextensions-00.txt
Network Working Group James Ng
Internet Draft (editor)
Expiration Date: October 2004 Cisco Systems
File Name: draft-ng-sobgp-bgpextensions-00.txt April 2004
Extensions to BGP Transport soBGP Certificates
draft-ng-sobgp-bgpextensions-00.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 Weis, 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, verifying that the final destination in the path is
actually within the autonomous system to which the packets are being
routed, and proving the validity of the AS Path contained in the
update.
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-
ARCH] 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-ARCH].
o Attempt to analyze the security protection provided by the pro-
posed security system. This may be address in a future draft.
This document primarily focuses on extensions to the BGP protocol
itself to support such a security system through the transport of the
certificates described in [SOBGP-CERTIFICATE].
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 2]
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 [TBD]. The SECURITY message is
used to transport the certificates described in [SOBGP-CERTIFICATE].
4.1. Negotiating Security Capability
The ability to exchange SECURITY messages MAY be negotiated at ses-
sion startup, as described in [CAPABILITY]. The capability code is
<to be assigned by IANA>.
o Speakers MAY negotiate the exchange of SECURITY information only
or SECURITY and NLRIs.
o If the exchange of SECURITY messages is negotiated, the SECURITY
option message MUST be exchanged before any other SECURITY mes-
sages are exchanged. The option bits in this message determine
if SECURITY messages or NLRIs will be exchanged first.
o If two BGP speakers have negotiated to exchange SECURITY mes-
sages, they SHOULD exchange the soBGP certificates contained in
their local databases.
4.2. The Security Message Format
The SECURITY message is formatted as described in [BGP], with a type
code of [TBD]. Within each message is a series of TLVs, or security
message 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 |
+---------
Ng, et al. [Page 3]
INTERNET DRAFT Secure Origin BGP (soBGP) April 2004
o Type: A two octet unsigned integer describing the type of infor-
mation contained within the data field.
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
Ng, et al. [Page 4]
INTERNET DRAFT Secure Origin BGP (soBGP) April 2004
validated certificates of any type along this session. This bit
MUST NOT be used for eBGP sessions.
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, bit 2 is set on the receiving peer, and the BGP
peering session is an authenticated or encrypted iBGP session, the
receiving peer may accept all received certificates from the
transmitting peer as already validated. This is called a trusted
peering relationship.
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 | Length |
+-------------------------------+-------------------------------+
| Request Type | Length |
+-------------------------------+-------------------------------+
| Request Indicator SubTV .... |
+---------------------------
| Request Type | Length |
+-------------------------------+-------------------------------+
| Request Indicator SubTV .... |
+---------------------------
o TLV type: (2 octets), 2
o Length: (2 octets), set to the total length of the request in
octets.
o Request Type: (2 octets), treated as an unsigned integer indi-
cating the type of information requested.
o Length: (2 octets), set to the number of requests of the request
type included in this request.
Ng, et al. [Page 5]
INTERNET DRAFT Secure Origin BGP (soBGP) April 2004
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.
Four request types are defined in this document.
1 Any certificate matching the Request Indicator are requested.
2 EntityCerts matching the Request Indicator are requested.
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.
Ng, et al. [Page 6]
INTERNET DRAFT Secure Origin BGP (soBGP) April 2004
4.2.3. The Cluster List 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 | Length |
+-------------------------------+-------------------------------+
| Cluster ID |
+-------------------------------+-------------------------------+
| .... |
+---------------------------
o TLV type: (2 octets), 3
o Length: (2 octets), set to the number of cluster IDs in the TLV
The use of the Cluster List TLV is described in the Reflecting SECU-
RITY messages section below.
5. Receiving and Processing SECURITY messages
Each section below describes the receipt and processing of SECURITY
messages.
5.1. Processing SECURITY Messages Containing a Certificate
For each certificate received, the BGP speaker MUST:
o Examine the certificate to determine if a copy of this certifi-
cate already exists in the local database. Any certificate
which is found to already be held locally MUST be discarded.
o If the certificate is received through an untrusted peering
relationship, place the certificate in a local certificate data-
base and process according to [SOBGP-CERTIFICATE].
o If the certificate is received through a trusted peering rela-
tionship, place certificate in a local certificate database,
treating it as if it is already validated according to [SOBGP-
CERTIFICATE].
o If a received certificate is sucessfully validated using the
process described in [SOBGP-CERTIFICATE], it should be readver-
tised to all peers outside the local autonomous system (eBGP
peers). If the peering relationship is trusted, the certificate
Ng, et al. [Page 7]
INTERNET DRAFT Secure Origin BGP (soBGP) April 2004
should be advertised as validated by marking it as indicated in
[SOBGP-CERTIFICATE].
5.2. Reflecting SECURITY Messages
A BGP speaker MAY be configured to reflect received SECURITY mes-
sages, with or without processing them, in a way similar to the way
BGP routing information is reflected among iBGP speakers, described
in [BGP-REFLECTION]. When reflecting SECURITY messages, a BGP speaker
MUST:
o Examine the SECURITY message for the presence of a Cluster List
TLV.
o If a Cluster List TLV exists, and the local router ID is con-
tained in the list of Cluster IDs, discard the SECURITY mes-
sage.
o If a Cluster List TLV exists, and the local router ID is not
contained in the list of Cluster IDs, add the local router ID
to the list and retransmit the SECURITY message to all BGP
peers which have negotiated receipt of SECURITY messages.
o If a Cluster List TLV does not exist, add a new Cluster List
TLV to the SECURITY message, including the local router ID in
the new TLV.
5.3. 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.
Ng, et al. [Page 8]
INTERNET DRAFT Secure Origin BGP (soBGP) April 2004
5.4. 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
range is not logically consistent, since these certificates only
contain an AS and a Signer AS. 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. Security Considerations
This document defines extensions to BGP that address specific secu-
rity concerns for the protocol. While it adds functionality, the
flexibility allows it to not introduce any new security concerns.
7. 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 through 3 are assigned in this document.
o Type values 4 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].
Ng, et al. [Page 9]
INTERNET DRAFT Secure Origin BGP (soBGP) April 2004
Request TLV Request Type Field:
o Types 1 through 3 are assigned in this document.
o Types 4 thru 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].
8. 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-ARCH]
White, R. (editor), "Architecture and Deployment Considerations
for Secure Origin BGP (soBGP)", draft-white-sobgp-deployment-03,
April 2004
[SOBGP-CERTIFICATE]
Weis, Brian (editor), "Secure Origin BGP (soBGP) Certificates",
draft-weis-sobgp-certificates-01.txt, October 2003
Ng, et al. [Page 10]
INTERNET DRAFT Secure Origin BGP (soBGP) April 2004
9. Informative References
[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 Signa-
ture 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
[BGP-REFLECTION]
Bates, T, et al, "BGP Route Reflection - An Alternative to Full
Mesh IBGP", draft-ietf-idr-rfc2796bis-00.txt, March 2004
10. Editor's Address
James Ng (Editor)
Cisco Systems
7025 Kit Creek Road
Research Triangle Park, NC 27709
jamng@cisco.com
Ng, et al. [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-22 13:47:51 |