< draft-ietf-sidr-bgpsec-protocol-06.txt   draft-ietf-sidr-bgpsec-protocol-07.txt >
Network Working Group M. Lepinski, Ed. Network Working Group M. Lepinski, Ed.
Internet-Draft BBN Internet-Draft BBN
Intended status: Standards Track October 22, 2012 Intended status: Standards Track February 25, 2013
Expires: April 25, 2013 Expires: August 25, 2013
BGPSEC Protocol Specification BGPSEC Protocol Specification
draft-ietf-sidr-bgpsec-protocol-06 draft-ietf-sidr-bgpsec-protocol-07
Abstract Abstract
This document describes BGPSEC, an extension to the Border Gateway This document describes BGPSEC, an extension to the Border Gateway
Protocol (BGP) that provides security for the path of autonomous Protocol (BGP) that provides security for the path of autonomous
systems through which a BGP update message passes. BGPSEC is systems through which a BGP update message passes. BGPSEC is
implemented via a new optional non-transitive BGP path attribute that implemented via a new optional non-transitive BGP path attribute that
carries a digital signature produced by each autonomous system that carries a digital signature produced by each autonomous system that
propagates the update message. propagates the update message.
skipping to change at page 3, line 40 skipping to change at page 3, line 40
the documents referenced therein.) Any BGPSEC speaker who wishes to the documents referenced therein.) Any BGPSEC speaker who wishes to
send BGP update messages to external peers (eBGP) containing the send BGP update messages to external peers (eBGP) containing the
BGPSEC_Path needs to have the private key associated with an RPKI BGPSEC_Path needs to have the private key associated with an RPKI
router certificate [10] that corresponds to the BGPSEC speaker's AS router certificate [10] that corresponds to the BGPSEC speaker's AS
number. Note, however, that a BGPSEC speaker does not need such a number. Note, however, that a BGPSEC speaker does not need such a
certificate in order to validate update messages containing the certificate in order to validate update messages containing the
BGPSEC_Path attribute. BGPSEC_Path attribute.
2. BGPSEC Negotiation 2. BGPSEC Negotiation
This document defines two new BGP capabilities [6] that allow a BGP This document defines a new BGP capability [6] that allows a BGP
speaker to advertise to a neighbor the ability (respectively) to send speaker to advertise to a neighbor the ability to send or to receive
or to receive BGPSEC update messages (i.e., update messages BGPSEC update messages (i.e., update messages containing the
containing the BGPSEC_Path attribute). BGPSEC_Path attribute).
2.1. BGPSEC Send Capability 2.1. The BGPSEC Capability
This capability has capability code : TBD This capability has capability code : TBD
The capability length for this capability MUST be set to 3. The capability length for this capability MUST be set to 3.
The three octets of the capability value are specified as follows. The three octets of the capability value are specified as follows.
BGPSEC Send Capability Value: BGPSEC Send Capability Value:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---------------------------------------+ +---------------------------------------+
| Version | Reserved | | Version | Dir | Reserved |
+---------------------------------------+ +---------------------------------------+
| | | |
+------ AFI -----+ +------ AFI -----+
| | | |
+---------------------------------------+ +---------------------------------------+
The first four bits of the first octet indicate the version of BGPSEC The first four bits of the first octet indicate the version of BGPSEC
for which the BGP speaker is advertising support. This document for which the BGP speaker is advertising support. This document
defines only BGPSEC version 0 (all four bits set to zero). Other defines only BGPSEC version 0 (all four bits set to zero). Other
versions of BGPSEC may be defined in future documents. A BGPSEC versions of BGPSEC may be defined in future documents. A BGPSEC
speaker MAY advertise support for multiple versions of BGPSEC by speaker MAY advertise support for multiple versions of BGPSEC by
including multiple versions of the BGPSEC capability in its BGP OPEN including multiple versions of the BGPSEC capability in its BGP OPEN
message. message.
The remaining four bits of the first octet are reserved for future The fifth bit of the first octet is a direction bit which indicates
use. These bits are set to zero by the sender of the capability and whether the BGP speaker is advertising the capability to send BGPSEC
ignored by the receiver of the capability. update message or receive BGPSEC update messages. The BGP speaker
sets this bit to 0 to indicate the capability to receive BGPSEC
The second and third octets contain the 16-bit Address Family update messages. The BGP speaker sets this bit to 1 to indicate the
Identifier (AFI) which indicates the address family for which the capability to send BGPSEC update messages.
BGPSEC speaker is advertising support for BGPSEC. This document only
specifies BGPSEC for use with two address families, IPv4 and IPv6,
AFI values 1 and 2 respectively. BGPSEC for use with other address
families may be specified in future documents.
2.2. BGPSEC Receive Capability
This capability has capability code : TBD
The capability length for this capability MUST be set to 3.
The three octets of the capability value are specified as follows.
BGPSEC Receive Capability Value:
0 1 2 3 4 5 6 7
+---------------------------------------+
| Version | Reserved |
+---------------------------------------+
| |
| AFI |
| |
+---------------------------------------+
The first four bits of the first octet indicate the version of BGPSEC
for which the BGP speaker is advertising support. This document
defines only BGPSEC version 0 (all four bits set to zero). Other
versions of BGPSEC may be defined in future documents. A BGPSEC
speaker MAY advertise support for multiple versions of BGPSEC by
including multiple versions of the BGPSEC capability in its BGP OPEN
message.
The remaining four bits of the first octet are reserved for future The remaining three bits of the first octet are reserved for future
use. These bits are set to zero by the sender of the capability and use. These bits are set to zero by the sender of the capability and
ignored by the receiver of the capability. ignored by the receiver of the capability.
The second and third octets contain the 16-bit Address Family The second and third octets contain the 16-bit Address Family
Identifier (AFI) which indicates the address family for which the Identifier (AFI) which indicates the address family for which the
BGPSEC speaker is advertising BGPSEC support. This document only BGPSEC speaker is advertising support for BGPSEC. This document only
specifies BGPSEC for use with two address families, IPv4 and IPv6, specifies BGPSEC for use with two address families, IPv4 and IPv6,
AFI values 1 and 2 respectively. BGPSEC for use with other address AFI values 1 and 2 respectively. BGPSEC for use with other address
families may be specified in future documents. families may be specified in future documents.
2.3. Negotiating BGPSEC Support 2.2. Negotiating BGPSEC Support
A BGP speaker sends the BGPSEC Send Capability (see Section 2.1) in In order to indicate that a BGP speaker is willing to send BGPSEC
order to indicate that the speaker is willing to send BGP update update messages (for a particular address family), a BGP speaker
messages containing the BGPSEC_Path attribute (for a particular sends the BGPSEC Capability (see Section 2.1) with the Direction bit
address family). A BGP speaker sends the BGPSEC Receive Capability (the fifth bit of the first octet) set to 1. In order to indicate
(see Section 2.2) in order to indicate that the speaker is willing to that the speaker is willing to receive BGP update messages containing
receive messages containing the BPGSEC_Path attribute. the BGPSEC_Path attribute (for a particular address family), a BGP
speaker sends the BGPSEC capability with the Direction bit set to 0.
In order to advertise the capability to both send and receive BGPSEC
update messages, the BGP speaker sends two copies of the BGPSEC
capability (one with the direction bit set to 0 and one with the
direction bit set to 1).
Note that if the BGPSEC speaker wishes to use BGPSEC with two Similarly, if a BGP speaker wishes to use BGPSEC with two different
different address families (i.e., IPv4 and IPv6) over the same BGP address families (i.e., IPv4 and IPv6) over the same BGP session,
session, then the speaker includes two instances of this capability then the speaker includes two instances of this capability (one for
(one for each address family) in the BGP OPEN message. A BGPSEC each address family) in the BGP OPEN message. A BGP speaker SHOULD
speaker SHOULD NOT advertise the capability of BGPSEC support for a NOT advertise the capability of BGPSEC support for a particular AFI
particular AFI unless it has also advertised the multiprotocol unless it has also advertised the multiprotocol extension capability
extension capability for the same AFI combination [3]. for the same AFI combination [3].
In a session where BGP session, a peer is permitted to send update In a session where BGP session, a peer is permitted to send update
messages containing the BGPSEC_Path attribute if, and only if: messages containing the BGPSEC_Path attribute if, and only if:
o The given peer has sent the BGPSEC Send Capability for a o The given peer has sent the BGPSEC capability for a particular
particular version of BGPSEC and a particular address family; and version of BGPSEC and a particular address family with the
Direction bit set to 1; and
o The other peer has sent the BGPSEC Receive Capability for the same o The other peer has sent the BGPSEC capability for the same version
version of BGPSEC and the same address family. of BGPSEC and the same address family with the Direction bit set
to 0.
In such a session, we say that the use of (the particular version of) In such a session, we say that the use of (the particular version of)
BGPSEC has been negotiated (for a particular address family). BGP BGPSEC has been negotiated (for a particular address family). BGP
update messages without the BGPSEC_PATH attribute MAY be sent within update messages without the BGPSEC_PATH attribute MAY be sent within
a session regardless of whether or not the use of BGPSEC is a session regardless of whether or not the use of BGPSEC is
successfully negotiated. However, if BGPSEC is not successfully successfully negotiated. However, if BGPSEC is not successfully
negotiated, then BGP update messages containing the BGPSEC_PATH negotiated, then BGP update messages containing the BGPSEC_PATH
attribute MUST NOT be sent. attribute MUST NOT be sent.
This document defines the behavior of implementations in the case This document defines the behavior of implementations in the case
where BGPSEC version zero is the only version that has been where BGPSEC version zero is the only version that has been
successfully negotiated. If there exist multiple versions have successfully negotiated. If there exist multiple versions have
BGPSEC that are negotiated for a particular session, the behavior of BGPSEC that are negotiated for a particular session, the behavior of
the peers (e.g., which version of BGPSEC shall actually be used) will the peers (e.g., which version of BGPSEC shall actually be used) will
be specified in a future document. be specified in a future document.
BGPSEC cannot provide meaningful security guarantees without support BGPSEC cannot provide meaningful security guarantees without support
for four-byte AS numbers. Therefore, any BGP speaker that announces for four-byte AS numbers. Therefore, any BGP speaker that announces
the capability to send BGPSEC messages, MUST also announce the the BGPSEC capability, MUST also announce the capability for four-
capability for four-byte AS support [4]. If a BGP speaker sends the byte AS support [4]. If a BGP speaker sends the BGPSEC capability
BGPSEC send capability but not the four-byte AS support capability but not the four-byte AS support capability then BGPSEC has not been
then BGPSEC has not been successfully negotiated, and update messages successfully negotiated, and update messages containing the
containing the BGPSEC_Path attribute MUST NOT be sent within such a BGPSEC_Path attribute MUST NOT be sent within such a session.
session.
Note that BGPSEC update messages can be quite large, therefore any Note that BGPSEC update messages can be quite large, therefore any
BGPSEC speaker announcing the capability to receive BGPSEC messages BGPSEC speaker announcing the capability to receive BGPSEC messages
SHOULD also announce support for the capability to receive BGP SHOULD also announce support for the capability to receive BGP
extended messages [9]. extended messages [9].
3. The BGPSEC_Path Attribute 3. The BGPSEC_Path Attribute
The BGPSEC_Path attribute is a new optional non-transitive BGP path The BGPSEC_Path attribute is a new optional non-transitive BGP path
attribute. attribute.
skipping to change at page 35, line 25 skipping to change at page 35, line 25
Author's Address Author's Address
Matthew Lepinski (editor) Matthew Lepinski (editor)
BBN BBN
10 Moulton St 10 Moulton St
Cambridge, MA 55409 Cambridge, MA 55409
US US
Phone: +1 617 873 5939 Phone: +1 617 873 5939
Email: mlepinski@bbn.com Email: mlepinski.ietf@gmail.com
 End of changes. 16 change blocks. 
73 lines changed or deleted 48 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/