draft-ietf-sidr-bgpsec-protocol-08.txt   draft-ietf-sidr-bgpsec-protocol-09.txt 
Network Working Group M. Lepinski, Ed. Network Working Group M. Lepinski, Ed.
Internet-Draft BBN Internet-Draft BBN
Intended status: Standards Track November 5, 2013 Intended status: Standards Track July 4, 2014
Expires: May 5, 2014 Expires: January 5, 2015
BGPSEC Protocol Specification BGPSEC Protocol Specification
draft-ietf-sidr-bgpsec-protocol-08 draft-ietf-sidr-bgpsec-protocol-09
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 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 25, 2013. This Internet-Draft will expire on January 5, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. BGPSEC Negotiation . . . . . . . . . . . . . . . . . . . . . . 3 2. BGPSEC Negotiation . . . . . . . . . . . . . . . . . . . . . . 3
2.1. BGPSEC Send Capability . . . . . . . . . . . . . . . . . . 3 2.1. The BGPSEC Capability . . . . . . . . . . . . . . . . . . 3
2.2. BGPSEC Receive Capability . . . . . . . . . . . . . . . . 4 2.2. Negotiating BGPSEC Support . . . . . . . . . . . . . . . . 4
2.3. Negotiating BGPSEC Support . . . . . . . . . . . . . . . . 5 3. The BGPSEC_Path Attribute . . . . . . . . . . . . . . . . . . 5
3. The BGPSEC_Path Attribute . . . . . . . . . . . . . . . . . . 6 3.1. Secure_Path . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Secure_Path . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Signature_Block . . . . . . . . . . . . . . . . . . . . . 8
3.2. Signature_Block . . . . . . . . . . . . . . . . . . . . . 9 4. Generating a BGPSEC Update . . . . . . . . . . . . . . . . . . 10
4. Generating a BGPSEC Update . . . . . . . . . . . . . . . . . . 11 4.1. Originating a New BGPSEC Update . . . . . . . . . . . . . 11
4.1. Originating a New BGPSEC Update . . . . . . . . . . . . . 12 4.2. Propagating a Route Advertisement . . . . . . . . . . . . 13
4.2. Propagating a Route Advertisement . . . . . . . . . . . . 14 4.3. Processing Instructions for Confederation Members . . . . 17
4.3. Processing Instructions for Confederation Members . . . . 18 4.4. Reconstructing the AS_PATH Attribute . . . . . . . . . . . 19
4.4. Reconstructing the AS_PATH Attribute . . . . . . . . . . . 20 5. Processing a Received BGPSEC Update . . . . . . . . . . . . . 20
5. Processing a Received BGPSEC Update . . . . . . . . . . . . . 21 5.1. Overview of BGPSEC Validation . . . . . . . . . . . . . . 22
5.1. Overview of BGPSEC Validation . . . . . . . . . . . . . . 23 5.2. Validation Algorithm . . . . . . . . . . . . . . . . . . . 23
5.2. Validation Algorithm . . . . . . . . . . . . . . . . . . . 24 6. Algorithms and Extensibility . . . . . . . . . . . . . . . . . 27
6. Algorithms and Extensibility . . . . . . . . . . . . . . . . . 28 6.1. Algorithm Suite Considerations . . . . . . . . . . . . . . 27
6.1. Algorithm Suite Considerations . . . . . . . . . . . . . . 28 6.2. Extensibility Considerations . . . . . . . . . . . . . . . 27
6.2. Extensibility Considerations . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 7.1 Security Guarantees . . . . . . . . . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 7.2 On the Removal of BGPSEC Signatures . . . . . . . . . . . . 29
7.3 Mitigation of Denial of Service Attacks . . . . . . . . . . 30
7.4 Additional Security Considerations . . . . . . . . . . . . . 31
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.1. Authors . . . . . . . . . . . . . . . . . . . . . . . . . 32 9.1. Authors . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 34 9.2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 32
10. Normative References . . . . . . . . . . . . . . . . . . . . . 34 10. Normative References . . . . . . . . . . . . . . . . . . . . 33
11. Informative References . . . . . . . . . . . . . . . . . . . . 35 11. Informative References . . . . . . . . . . . . . . . . . . . 33
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 35 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
This document describes BGPSEC, a mechanism for providing path This document describes BGPSEC, a mechanism for providing path
security for Border Gateway Protocol (BGP) [2] route advertisements. security for Border Gateway Protocol (BGP) [2] route advertisements.
That is, a BGP speaker who receives a valid BGPSEC update has That is, a BGP speaker who receives a valid BGPSEC update has
cryptographic assurance that the advertised route has the following cryptographic assurance that the advertised route has the following
two properties: two properties:
1. The route was originated by an AS explicitly authorized by the 1. The route was originated by an AS explicitly authorized by the
skipping to change at page 4, line 26 skipping to change at page 4, line 24
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 fifth bit of the first octet is a direction bit which indicates The fifth bit of the first octet is a direction bit which indicates
whether the BGP speaker is advertising the capability to send BGPSEC whether the BGP speaker is advertising the capability to send BGPSEC
update message or receive BGPSEC update messages. The BGP speaker update messages or receive BGPSEC update messages. The BGP speaker
sets this bit to 0 to indicate the capability to receive BGPSEC sets this bit to 0 to indicate the capability to receive BGPSEC
update messages. The BGP speaker sets this bit to 1 to indicate the update messages. The BGP speaker sets this bit to 1 to indicate the
capability to send BGPSEC update messages. capability to send BGPSEC update messages.
The remaining three 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
skipping to change at page 5, line 18 skipping to change at page 5, line 16
address families (i.e., IPv4 and IPv6) over the same BGP session, address families (i.e., IPv4 and IPv6) over the same BGP session,
then the speaker includes two instances of this capability (one for then the speaker includes two instances of this capability (one for
each address family) in the BGP OPEN message. A BGP speaker SHOULD each address family) in the BGP OPEN message. A BGP speaker SHOULD
NOT advertise the capability of BGPSEC support for a particular AFI NOT advertise the capability of BGPSEC support for a particular AFI
unless it has also advertised the multiprotocol extension capability unless it has also advertised the multiprotocol 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 capability for a particular o The given peer sent the BGPSEC capability for a particular version
version of BGPSEC and a particular address family with the of BGPSEC and a particular address family with the Direction bit
Direction bit set to 1; and set to 1; and
o The other peer has sent the BGPSEC capability for the same version o The other peer sent the BGPSEC capability for the same version of
of BGPSEC and the same address family with the Direction bit set BGPSEC and the same address family with the Direction bit set to
to 0. 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. Any future document which specifies
BGPSEC that are negotiated for a particular session, the behavior of additional versions of BGPSEC will need to specify behavior in the
the peers (e.g., which version of BGPSEC shall actually be used) will case that support for multiple versions is negotiated.
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 BGPSEC capability, MUST also announce the capability for four- the BGPSEC capability, MUST also announce the capability for four-
byte AS support [4]. If a BGP speaker sends the BGPSEC capability byte AS support [4]. If a BGP speaker sends the BGPSEC capability but
but not the four-byte AS support capability then BGPSEC has not been not the four-byte AS support capability then BGPSEC has not been
successfully negotiated, and update messages containing the successfully negotiated, and update messages containing the
BGPSEC_Path attribute MUST NOT be sent within such a session. BGPSEC_Path attribute MUST NOT be sent within such a 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.
This document registers a new attribute type code for this attribute This document registers a new attribute type code for this attribute
: TBD : TBD
The BGPSEC_Path attribute carries the secured information regarding The BGPSEC_Path attribute carries the secured information regarding
the path of ASes through which an update message passes. This the path of ASes through which an update message passes. This
includes the digital signatures used to protect this information. We includes the digital signatures used to protect the path information.
refer to those update messages that contain the BGPSEC_Path attribute We refer to those update messages that contain the BGPSEC_Path
as "BGPSEC Update messages". The BGPSEC_Path attribute replaces the attribute as "BGPSEC Update messages". The BGPSEC_Path attribute
AS_PATH attribute in a BGPSEC update message. That is, update replaces the AS_PATH attribute in a BGPSEC update message. That is,
messages that contain the BGPSEC_Path attribute MUST NOT contain the update messages that contain the BGPSEC_Path attribute MUST NOT
AS_PATH attribute, and vice versa. contain the AS_PATH attribute, and vice versa.
The BGPSEC_Path attribute is made up of several parts. The following The BGPSEC_Path attribute is made up of several parts. The following
high-level diagram provides an overview of the structure of the high-level diagram provides an overview of the structure of the
BGPSEC_Path attribute: BGPSEC_Path attribute:
High-Level Diagram of the BGPSEC_Path Attribute High-Level Diagram of the BGPSEC_Path Attribute
+---------------------------------------------------------+ +---------------------------------------------------------+
| +-----------------+ | | +-----------------+ |
| | Secure Path | | | | Secure Path | |
| +-----------------+ | | +-----------------+ |
skipping to change at page 9, line 36 skipping to change at page 8, line 36
autonomous system number that the signature covers. This field autonomous system number that the signature covers. This field
enables a BGPSEC speaker to mimic the semantics of prepending enables a BGPSEC speaker to mimic the semantics of prepending
multiple copies of their AS to the AS_PATH without requiring the multiple copies of their AS to the AS_PATH without requiring the
speaker to generate multiple signatures. speaker to generate multiple signatures.
The first bit of the Flags field is the Confed_Segment flag. The The first bit of the Flags field is the Confed_Segment flag. The
Confed_Segment flag is set to one to indicate that the BGPSEC speaker Confed_Segment flag is set to one to indicate that the BGPSEC speaker
that constructed this Secure_Path segment is sending the update that constructed this Secure_Path segment is sending the update
message to a peer AS within the same Autonomous System confederation message to a peer AS within the same Autonomous System confederation
[5]. (That is, the Confed_Segment flag is set in a BGPSEC update [5]. (That is, the Confed_Segment flag is set in a BGPSEC update
message whenever in a non-BGPSEC update message the BGP speaker's AS message whenever, in a non-BGPSEC update message, the BGP speaker's
would appear in a AS_PATH segment of type AS_CONFED_SEQUENCE.) In AS would appear in a AS_PATH segment of type AS_CONFED_SEQUENCE.) In
all other cases the Confed_Segment flag is set to zero. all other cases the Confed_Segment flag is set to zero.
The remaining seven bits of the Flags MUST be set to zero by the The remaining seven bits of the Flags MUST be set to zero by the
sender, and ignored by the receiver. Note, however, that the sender, and ignored by the receiver. Note, however, that the
signature is computed over all eight bits of the flags field. signature is computed over all eight bits of the flags field.
3.2. Signature_Block 3.2. Signature_Block
Here we provide a detailed description of the Signature_Blocks in the Here we provide a detailed description of the Signature_Blocks in the
BGPSEC_Path attribute. BGPSEC_Path attribute.
skipping to change at page 10, line 22 skipping to change at page 9, line 22
| Sequence of Signature Segments (variable) | | Sequence of Signature Segments (variable) |
+---------------------------------------------+ +---------------------------------------------+
The Signature_Block Length is the total number of octets in the The Signature_Block Length is the total number of octets in the
Signature_Block (including the two octets used to express this length Signature_Block (including the two octets used to express this length
field). field).
The Algorithm Suite Identifier is a one-octet identifier specifying The Algorithm Suite Identifier is a one-octet identifier specifying
the digest algorithm and digital signature algorithm used to produce the digest algorithm and digital signature algorithm used to produce
the digital signature in each Signature Segment. An IANA registry of the digital signature in each Signature Segment. An IANA registry of
algorithm identifiers for use in BGPSEC is created in the BGPSEC algorithm identifiers for use in BGPSEC is specified in the BGPSEC
algorithms document[11]. algorithms document [11].
A Signature_Block has exactly one Signature Segment for each A Signature_Block has exactly one Signature Segment for each
Secure_Path Segment in the Secure_Path portion of the BGPSEC_Path Secure_Path Segment in the Secure_Path portion of the BGPSEC_Path
Attribute. (That is, one Signature Segment for each distinct AS on Attribute. (That is, one Signature Segment for each distinct AS on
the path for the NLRI in the Update message.) the path for the NLRI in the Update message.)
Signature Segments Signature Segments
+---------------------------------------------+ +---------------------------------------------+
| Subject Key Identifier (20 octets) | | Subject Key Identifier (20 octets) |
+---------------------------------------------+ +---------------------------------------------+
skipping to change at page 14, line 42 skipping to change at page 13, line 42
4.2. Propagating a Route Advertisement 4.2. Propagating a Route Advertisement
When a BGPSEC speaker receives a BGPSEC update message containing a When a BGPSEC speaker receives a BGPSEC update message containing a
BGPSEC_Path attribute (with one or more signatures) from an (internal BGPSEC_Path attribute (with one or more signatures) from an (internal
or external) peer, it may choose to propagate the route advertisement or external) peer, it may choose to propagate the route advertisement
by sending to its (internal or external) peers by creating a new by sending to its (internal or external) peers by creating a new
BGPSEC advertisement for the same prefix. BGPSEC advertisement for the same prefix.
If a BGPSEC router has received only a non-BGPSEC update message If a BGPSEC router has received only a non-BGPSEC update message
(without the BGPSEC_Path attribute), containing the AS_Path (without the BGPSEC_Path attribute), containing the AS_Path
attribute, from a peer for a given prefix and if it chooses to attribute, from a peer for a given prefix then it MUST NOT attach a
propagate that peer's route for the prefix, then it MUST NOT attach BGPSEC_Path attribute when it propagates the update message. (Note
any BGPSEC_Path attribute to the corresponding update being that a BGPSEC router may also receive a non-BGPSEC update message
propagated. (Note that a BGPSEC router may also receive a non-BGPSEC from an internal peer without the AS_Path attribute, i.e., with just
update message from an internal peer without the AS_Path attribute, the NLRI in it. In that case, the prefix is originating from that AS
i.e., with just the NLRI in it. In that case, the prefix is and hence the BGPSEC speaker SHOULD sign and forward the update to
originating from that AS and hence the BGPSEC speaker SHOULD sign and its external peers, as specified in Section 4.1.)
forward the update to its external peers, as specified in Section
4.1.)
Conversely, if a BGPSEC router has received a BGPSEC update message Conversely, if a BGPSEC router has received a BGPSEC update message
(with the BGPSEC_Path attribute) from a peer for a given prefix and (with the BGPSEC_Path attribute) from a peer for a given prefix and
it chooses to propagate that peer's route for the prefix, then it it chooses to propagate that peer's route for the prefix, then it
SHOULD propagate the route as a BGPSEC update message containing the SHOULD propagate the route as a BGPSEC update message containing the
BGPSEC_Path attribute. However, the BGPSEC speaker MAY propagate the BGPSEC_Path attribute.
route as a (unsigned) BGP update message without the BGPSEC_Path
attribute.
Note that removing BGPSEC signatures (i.e., propagating a route Note that removing BGPSEC signatures (i.e., propagating a route
advertisement without the BGPSEC_Path attribute) has significant advertisement without the BGPSEC_Path attribute) has significant
security ramifications. (See Section 7 for discussion of the security ramifications. (See Section 7 for discussion of the
security ramifications of removing BGPSEC signatures.) Therefore, security ramifications of removing BGPSEC signatures.) Therefore,
when a route advertisement is received via a BGPSEC update message, when a route advertisement is received via a BGPSEC update message,
propagating the route advertisement without the BGPSEC_Path attribute propagating the route advertisement without the BGPSEC_Path attribute
is NOT RECOMMENDED, unless the message is sent to a peer that did not is NOT RECOMMENDED, unless the message is sent to a peer that did not
advertise the capability to receive BGPSEC update messages (see advertise the capability to receive BGPSEC update messages (see
Section 4.4). Section 4.4).
skipping to change at page 15, line 33 skipping to change at page 14, line 29
advertisement with the BGPSEC_Path attribute it is not attesting to advertisement with the BGPSEC_Path attribute it is not attesting to
the validation state of the update message it received. (See Section the validation state of the update message it received. (See Section
7 for more discussion of the security semantics of BGPSEC 7 for more discussion of the security semantics of BGPSEC
signatures.) signatures.)
If the BGPSEC speaker is producing an update message which would, in If the BGPSEC speaker is producing an update message which would, in
the absence of BGPSEC, contain an AS_SET (e.g., the BGPSEC speaker is the absence of BGPSEC, contain an AS_SET (e.g., the BGPSEC speaker is
performing proxy aggregation), then the BGPSEC speaker MUST NOT performing proxy aggregation), then the BGPSEC speaker MUST NOT
include the BGPSEC_Path attribute. In such a case, the BGPSEC include the BGPSEC_Path attribute. In such a case, the BGPSEC
speaker must remove any existing BGPSEC_Path in the received speaker must remove any existing BGPSEC_Path in the received
advertisement(s) for this prefix and produce a standard (non-BGPSEC) advertisement(s) for this prefix and produce a traditional (non-
update message. It should be noted that BCP 172 [13] recommends BGPSEC) update message. It should be noted that BCP 172 [13]
against the use of AS_SET and AS_CONFED_SET in AS_PATH in BGP recommends against the use of AS_SET and AS_CONFED_SET in the AS_PATH
updates. of BGP updates.
To generate the BGPSEC_Path attribute on the outgoing update message, To generate the BGPSEC_Path attribute on the outgoing update message,
the BGPSEC speaker first prepends a new Secure_Path Segment (places the BGPSEC speaker first prepends a new Secure_Path Segment (places
in first position) to the Secure_Path. The AS number in this in first position) to the Secure_Path. The AS number in this
Secure_Path segment MUST match the AS number in the AS number Secure_Path segment MUST match the AS number in the AS number
resource extension field of the Resource PKI router certificate(s) resource extension field of the Resource PKI router certificate(s)
that will be used to verify the digital signature(s) constructed by that will be used to verify the digital signature(s) constructed by
this BGPSEC speaker[10]. this BGPSEC speaker[10].
The pCount is typically set to the value 1. A BGPSEC speaker may set The pCount is typically set to the value 1. A BGPSEC speaker may set
skipping to change at page 16, line 40 skipping to change at page 15, line 36
only supports one of the two corresponding algorithm suites, then the only supports one of the two corresponding algorithm suites, then the
BGPSEC speaker MUST remove the Signature_Block corresponding to the BGPSEC speaker MUST remove the Signature_Block corresponding to the
algorithm suite that it does not understand. If the BGPSEC speaker algorithm suite that it does not understand. If the BGPSEC speaker
does not support the algorithm suites in any of the Signature_Blocks does not support the algorithm suites in any of the Signature_Blocks
contained in the received update message, then the BGPSEC speaker contained in the received update message, then the BGPSEC speaker
MUST NOT propagate the route advertisement with the BGPSEC_Path MUST NOT propagate the route advertisement with the BGPSEC_Path
attribute. (That is, if it chooses to propagate this route attribute. (That is, if it chooses to propagate this route
advertisement at all, it must do so as an unsigned BGP update advertisement at all, it must do so as an unsigned BGP update
message). message).
Note that in the case where there are two Signature_Blocks Note that in the case where the BGPSEC_Path has two Signature_Blocks
(corresponding to different algorithm suites) that the validation (corresponding to different algorithm suites), the validation
algorithm (see Section 5.2) deems a BGPSEC update message to be algorithm (see Section 5.2) deems a BGPSEC update message to be
'Valid' if there is at least one supported algorithm suite (and 'Valid' if there is at least one supported algorithm suite (and
corresponding Signature_Block) that is deemed 'Valid'. This means corresponding Signature_Block) that is deemed 'Valid'. This means
that a 'Valid' BGPSEC update message may contain a Signature_Block that a 'Valid' BGPSEC update message may contain a Signature_Block
which is not deemed 'Valid' (e.g., contains signatures that the which is not deemed 'Valid' (e.g., contains signatures that the
BGPSEC does not successfully verify). Nonetheless, such BGPSEC does not successfully verify). Nonetheless, such
Signature_Blocks MUST NOT be removed. (See Section 7 for a Signature_Blocks MUST NOT be removed. (See Section 7 for a
discussion of the security ramifications of this design choice.) discussion of the security ramifications of this design choice.)
For each Signature_Block corresponding to an algorithm suite that the For each Signature_Block corresponding to an algorithm suite that the
BGPSEC speaker does support, the BGPSEC speaker then adds a new BGPSEC speaker does support, the BGPSEC speaker adds a new Signature
Signature Segment to the Signature_Block. This Signature Segment is Segment to the Signature_Block. This Signature Segment is prepended
prepended to the list of Signature Segments (placed in the first to the list of Signature Segments (placed in the first position) so
position) so that the list of Signature Segments appears in the same that the list of Signature Segments appear in the same order as the
order as the corresponding Secure_Path segments in the Secure_Path corresponding Secure_Path segments. The BGPSEC speaker populates the
portion of the BGPSEC_Path attribute. The BGPSEC speaker populates fields of this new signature segment as follows.
the fields of this new signature segment as follows.
The Subject Key Identifier field in the new segment is populated with The Subject Key Identifier field in the new segment is populated with
the identifier contained in the Subject Key Identifier extension of the identifier contained in the Subject Key Identifier extension of
the RPKI router corresponding to the BGPSEC speaker[10]. This the RPKI router corresponding to the BGPSEC speaker [10]. This
Subject Key Identifier will be used by recipients of the route Subject Key Identifier will be used by recipients of the route
advertisement to identify the proper certificate to use in verifying advertisement to identify the proper certificate to use in verifying
the signature. the signature.
The Signature field in the new segment contains a digital signature The Signature field in the new segment contains a digital signature
that binds the NLRI and BGPSEC_Path attribute to the RPKI router that binds the NLRI and BGPSEC_Path attribute to the RPKI router
certificate corresponding to the BGPSEC speaker. The digital certificate corresponding to the BGPSEC speaker. The digital
signature is computed as follows: signature is computed as follows:
o Construct a sequence of octets by concatenating the Target AS o Construct a sequence of octets by concatenating the Target AS
skipping to change at page 18, line 23 skipping to change at page 17, line 19
messages. messages.
When a confederation member sends a BGPSEC update message to a peer When a confederation member sends a BGPSEC update message to a peer
that is a member of the same confederation, the confederation member that is a member of the same confederation, the confederation member
puts its (private) Member-AS Number (as opposed to the public AS puts its (private) Member-AS Number (as opposed to the public AS
Confederation Identifier) in the AS Number field of the Secure_Path Confederation Identifier) in the AS Number field of the Secure_Path
Segment that it adds to the BGPSEC update message. Furthermore, when Segment that it adds to the BGPSEC update message. Furthermore, when
a confederation member sends a BGPSEC update message to a peer that a confederation member sends a BGPSEC update message to a peer that
is a member of the same confederation, the BGPSEC speaker that is a member of the same confederation, the BGPSEC speaker that
generates the Secure_Path Segment sets the Confed_Segment flag to generates the Secure_Path Segment sets the Confed_Segment flag to
one. Note that this means that in a BGPSEC update message, an AS one. This means that in a BGPSEC update message, an AS number
number appears in a Secure_Path Segment with the Confed_Segment flag appears in a Secure_Path Segment with the Confed_Segment flag set
set to one, in precisely those circumstances where the AS number whenever, in a non-BGPSEC update message, the AS number would appear
would appear in a segment of type AS_CONFED_SEQUENCE in a non-BGPSEC in a segment of type AS_CONFED_SEQUENCE in a non-BGPSEC update
update message. message.
Within a confederation, the verification of BGPSEC signatures added Within a confederation, the verification of BGPSEC signatures added
by other members of the confederation is optional. If a by other members of the confederation is optional. If a
confederation chooses to have its members not verify signatures added confederation chooses not to have its members verify signatures added
by other confederation members, then when sending a BGPSEC update by other confederation members, then when sending a BGPSEC update
message to a peer that is a member of the same confederation, the message to a peer that is a member of the same confederation, the
confederation MAY set the Signature field within the confederation members MAY set the Signature field within the
Signature_Segment that it generates to be zero (in lieu of Signature_Segment that it generates to be zero (in lieu of
calculating the correct digital signature as described in Sections calculating the correct digital signature as described in Sections
4.1 and 4.2). Note that if a confederation chooses not to verify 4.1 and 4.2). Note that if a confederation chooses not to verify
digital signatures within the confederation, then BGPSEC is able to digital signatures within the confederation, then BGPSEC is able to
provide no assurances about the integrity of the (private) Member-AS provide no assurances about the integrity of the (private) Member-AS
Numbers placed in Secure_Path segments where the Confed_Segment flag Numbers placed in Secure_Path segments where the Confed_Segment flag
is set to one. is set to one.
When a confederation member receives a BGPSEC update message from a When a confederation member receives a BGPSEC update message from a
peer within the confederation and propagates it to a peer outside the peer within the confederation and propagates it to a peer outside the
skipping to change at page 19, line 46 skipping to change at page 18, line 42
Identifier of the validating BGPSEC speaker's own confederation. Identifier of the validating BGPSEC speaker's own confederation.
(Note that the algorithm in Section 5.2 processes Secure_Path (Note that the algorithm in Section 5.2 processes Secure_Path
Segments in order from most recently added to least recently added, Segments in order from most recently added to least recently added,
therefore this special case will apply to the first Secure_Path therefore this special case will apply to the first Secure_Path
segment that the algorithm encounters that has the Confed_Segment segment that the algorithm encounters that has the Confed_Segment
flag set to zero.) flag set to zero.)
Finally, as discussed above, an AS confederation may optionally Finally, as discussed above, an AS confederation may optionally
decide that its members will not verify digital signatures added by decide that its members will not verify digital signatures added by
members. In such a federation, when a confederation member runs the members. In such a federation, when a confederation member runs the
algorithm in Section 5.2, when processing a Signature_Segment, the algorithm in Section 5.2, the confederation member, during processing
confederation member first checks whether the Confed_Sequence flag in of a Signature_Segment, first checks whether the Confed_Sequence flag
the corresponding Secure_Path segment is set to one. If the in the corresponding Secure_Path segment is set to one. If the
Confed_Sequence flag is set to one in the corresponding Secure_Path Confed_Sequence flag is set to one in the corresponding Secure_Path
segment, the confederation member does not perform any further checks segment, the confederation member does not perform any further checks
on the Signature_Segment and immediately moves on to the next on the Signature_Segment and immediately moves on to the next
Signature_Segment (and checks its corresponding Secure_Path segment). Signature_Segment (and checks its corresponding Secure_Path segment).
Note that as specified in Section 5.2, it is an error for a BGPSEC Note that as specified in Section 5.2, it is an error when a BGPSEC
speaker to receive a BGPSEC update messages containing a Secure_Path speaker receives from a peer, who is not in the same AS
segment with the Confed_Sequence flag set to one from a peer who is confederation, a BGPSEC update containing a Confed_Sequence flag set
not a member of the same AS confederation. (As discussed in Section to one. (As discussed in Section 5.2, any error in the BGPSEC_Path
5.2, any error in the BGPSEC_Path attribute MUST be handled using the attribute MUST be handled using the "treat-as-withdraw", approach as
"treat-as-withdraw", approach as defined in RFC WXYZ [12].) defined in RFC WXYZ [12].)
4.4. Reconstructing the AS_PATH Attribute 4.4. Reconstructing the AS_PATH Attribute
BGPSEC update messages do not contain the AS_PATH attribute. Note, BGPSEC update messages do not contain the AS_PATH attribute.
however, that the AS_PATH attribute can be reconstructed from the However, the AS_PATH attribute can be reconstructed from the
BGPSEC_Path attribute. This is necessary in the case where a route BGPSEC_Path attribute. This is necessary in the case where a route
advertisement is received via a BGPSEC update message and then advertisement is received via a BGPSEC update message and then
propagated to a peer via a non-BGPSEC update message. There may be propagated to a peer via a non-BGPSEC update message (e.g., because
the latter peer does not support BGPSEC). Note that there may be
additional cases where an implementation finds it useful to perform additional cases where an implementation finds it useful to perform
this reconstruction. this reconstruction.
The AS_PATH attribute can be constructed from the BGPSEC_Path The AS_PATH attribute can be constructed from the BGPSEC_Path
attribute as follows. Starting with an empty AS_PATH attribute, attribute as follows. Starting with an empty AS_PATH attribute,
process the Secure_Path segments in order from least-recently added process the Secure_Path segments in order from least-recently added
(corresponding to the origin) to most-recently added. For each (corresponding to the origin) to most-recently added. For each
Secure_Path segment perform the following steps: Secure_Path segment perform the following steps:
1. If the Confed_Segment flag in the Secure_Path segment is set to 1. If the Confed_Segment flag in the Secure_Path segment is set to
skipping to change at page 21, line 51 skipping to change at page 20, line 51
once) a BGPSEC speaker MAY temporarily defer validation of incoming once) a BGPSEC speaker MAY temporarily defer validation of incoming
BGPSEC update messages. The treatment of such BGPSEC update BGPSEC update messages. The treatment of such BGPSEC update
messages, whose validation has been deferred, is a matter of local messages, whose validation has been deferred, is a matter of local
policy. policy.
The validity of BGPSEC update messages is a function of the current The validity of BGPSEC update messages is a function of the current
RPKI state. When a BGPSEC speaker learns that RPKI state has changed RPKI state. When a BGPSEC speaker learns that RPKI state has changed
(e.g., from an RPKI validating cache via the RTR protocol), the (e.g., from an RPKI validating cache via the RTR protocol), the
BGPSEC speaker MUST re-run validation on all affected update messages BGPSEC speaker MUST re-run validation on all affected update messages
stored in its ADJ-RIB-IN. That is, when a given RPKI certificate stored in its ADJ-RIB-IN. That is, when a given RPKI certificate
ceases to be valid (e.g., it expires or revoked), all update messages ceases to be valid (e.g., it expires or is revoked), all update
containing a signature whose SKI matches the SKI in the given messages containing a signature whose SKI matches the SKI in the
certificate must be re-assessed to determine if they are still valid. given certificate must be re-assessed to determine if they are still
Note that this reassessment determines that the validity state of an valid. If this reassessment determines that the validity state of an
update has changed then, depending on local policy, it may be update has changed then, depending on local policy, it may be
necessary to re-run best path selection. necessary to re-run best path selection.
BGPSEC update messages do not contain an AS_PATH attribute. BGPSEC update messages do not contain an AS_PATH attribute.
Therefore, a BGPSEC speaker MUST utilize the AS path information in Therefore, a BGPSEC speaker MUST utilize the AS path information in
the BGPSEC_Path attribute in all cases where it would otherwise use the BGPSEC_Path attribute in all cases where it would otherwise use
the AS path information in the AS_PATH attribute. The only exception the AS path information in the AS_PATH attribute. The only exception
to this rule is when AS path information must be updated in order to to this rule is when AS path information must be updated in order to
propagate a route to a peer (in which case the BGPSEC speaker follows propagate a route to a peer (in which case the BGPSEC speaker follows
the instructions in Section 4). Section 4.4 provides an algorithm the instructions in Section 4). Section 4.4 provides an algorithm
skipping to change at page 23, line 13 skipping to change at page 22, line 13
first contained a signature that was invalid). first contained a signature that was invalid).
5.1. Overview of BGPSEC Validation 5.1. Overview of BGPSEC Validation
Validation of a BGPSEC update messages makes use of data from RPKI Validation of a BGPSEC update messages makes use of data from RPKI
certificates and signed Route Origination Authorizations (ROA). In certificates and signed Route Origination Authorizations (ROA). In
particular, to validate update messages containing the BGPSEC_Path particular, to validate update messages containing the BGPSEC_Path
attribute, it is necessary that the recipient have access to the attribute, it is necessary that the recipient have access to the
following data obtained from valid RPKI certificates and ROAs: following data obtained from valid RPKI certificates and ROAs:
o For each valid RPKI router certificate containing an AS Number o For each valid RPKI router certificate, the AS Number, Public Key
extension, the AS Number, Public Key and Subject Key Identifier and Subject Key Identifier are required,
are required,
o For each valid ROA, the AS Number and the list of IP address o For each valid ROA, the AS Number and the list of IP address
prefixes. prefixes.
Note that the BGPSEC speaker could perform the validation of RPKI Note that the BGPSEC speaker could perform the validation of RPKI
certificates and ROAs on its own and extract the required data, or it certificates and ROAs on its own and extract the required data, or it
could receive the same data from a trusted cache that performs RPKI could receive the same data from a trusted cache that performs RPKI
validation on behalf of (some set of) BGPSEC speakers. (For example, validation on behalf of (some set of) BGPSEC speakers. (For example,
the trusted cache could deliver the necessary validity information to the trusted cache could deliver the necessary validity information to
the BGPSEC speaker using the router key PDU [16] for the RTR protocol the BGPSEC speaker using the router key PDU [16] for the RTR protocol
skipping to change at page 23, line 37 skipping to change at page 22, line 36
To validate a BGPSEC update message containing the BGPSEC_Path To validate a BGPSEC update message containing the BGPSEC_Path
attribute, the recipient performs the validation steps specified in attribute, the recipient performs the validation steps specified in
Section 5.2. The validation procedure results in one of two states: Section 5.2. The validation procedure results in one of two states:
'Valid' and 'Not Valid'. 'Valid' and 'Not Valid'.
It is expected that the output of the validation procedure will be It is expected that the output of the validation procedure will be
used as an input to BGP route selection. However, BGP route used as an input to BGP route selection. However, BGP route
selection, and thus the handling of the two validation states is a selection, and thus the handling of the two validation states is a
matter of local policy, and is handled using local policy mechanisms. matter of local policy, and is handled using local policy mechanisms.
It is expected that BGP peers will generally prefer routes received
via 'Valid' BGPSEC update messages over routes received via 'Not
Valid' BGPSEC update messages as well as routes received via update
messages that do not contain the BGPSEC_Path attribute. However,
BGPSEC specifies no changes to the BGP decision process. (See [17]
for related operational considerations.)
BGPSEC validation needs only be performed at eBGP edge. The It is expected that BGP peers will generally prefer routes received
via 'Valid' BGPSEC update messages over both routes received via 'Not
Valid' BGPSEC update messages and routes received via update messages
that do not contain the BGPSEC_Path attribute. However, BGPSEC
specifies no changes to the BGP decision process. (See [17] for
related operational considerations.)
BGPSEC validation needs only be performed at the eBGP edge. The
validation status of a BGP signed/unsigned update MAY be conveyed via validation status of a BGP signed/unsigned update MAY be conveyed via
iBGP from an ingress edge router to an egress edge router via some iBGP from an ingress edge router to an egress edge router via some
mechanism, according to local policy within an AS. As discussed in mechanism, according to local policy within an AS. As discussed in
Section 4, when a BGPSEC speaker chooses to forward a (syntactically Section 4, when a BGPSEC speaker chooses to forward a (syntactically
correct) BGPSEC update message, it SHOULD be forwarded with its correct) BGPSEC update message, it SHOULD be forwarded with its
BGPSEC_Path attribute intact (regardless of the validation state of BGPSEC_Path attribute intact (regardless of the validation state of
the update message). Based entirely on local policy, an egress the update message). Based entirely on local policy, an egress
router receiving a BGPSEC update message from within its own AS MAY router receiving a BGPSEC update message from within its own AS MAY
choose to perform its own validation. choose to perform its own validation.
skipping to change at page 24, line 47 skipping to change at page 23, line 47
expected to set pCount equal to zero (see Section 4.2) then check expected to set pCount equal to zero (see Section 4.2) then check
to ensure that the pCount field in the most-recently added to ensure that the pCount field in the most-recently added
Secure_Path segment is not equal to zero. Secure_Path segment is not equal to zero.
If any of these checks fail, it is an error in the BGPSEC_Path If any of these checks fail, it is an error in the BGPSEC_Path
attribute. Any of these errors in the BGPSEC_Path attribute are attribute. Any of these errors in the BGPSEC_Path attribute are
handled as per RFC WXYZ [12]. BGPSEC speakers MUST handle these handled as per RFC WXYZ [12]. BGPSEC speakers MUST handle these
errors using the "treat-as-withdraw" approach as defined in RFC WXYZ errors using the "treat-as-withdraw" approach as defined in RFC WXYZ
[12]. [12].
an error in the BGPSEC_Path attribute, then the implementation should
notify the operator that an error has occurred and treat the update
in a manner consistent with other BGP errors (i.e., following RFC
4271 [2] or any future updates to that document).
Next, the BGPSEC speaker verifies that the origin AS is authorized to Next, the BGPSEC speaker verifies that the origin AS is authorized to
advertise the prefix in question. To do this, consult the valid ROA advertise the prefix in question. To do this, consult the valid ROA
data to obtain a list of AS numbers that are associated with the data to obtain a list of AS numbers that are associated with the
given IP address prefix in the update message. Then locate the last given IP address prefix in the update message. Then locate the last
(least recently added) AS number in the Secure_Path portion of the (least recently added) AS number in the Secure_Path portion of the
BGPSEC_Path attribute. If the origin AS in the Secure_Path is not in BGPSEC_Path attribute. If the origin AS in the Secure_Path is not in
the set of AS numbers associated with the given prefix, then the the set of AS numbers associated with the given prefix, then the
BGPSEC update message is 'Not Valid' and the validation algorithm BGPSEC update message is 'Not Valid' and the validation algorithm
terminates. terminates.
Finally, the BGPSEC speaker examines the Signature_Blocks in the Finally, the BGPSEC speaker examines the Signature_Blocks in the
BGPSEC_Path attribute. A Signature_Block corresponding to an BGPSEC_Path attribute. A Signature_Block corresponding to an
algorithm suite that the BGPSEC speaker does not support is not algorithm suite that the BGPSEC speaker does not support is not
considered in validation. If there does not exist a Signature_Block considered in validation. If there is no Signature_Block
corresponding to an algorithm suite that the BGPSEC speaker supports, corresponding to an algorithm suite that the BGPSEC speaker supports,
then the BGPSEC speaker MUST treat the update message in the same then the BGPSEC speaker MUST treat the update message in the same
manner that the BGPSEC speaker would treat an (unsigned) update manner that the BGPSEC speaker would treat an (unsigned) update
message that arrived without a BGPSEC_Path attribute. message that arrived without a BGPSEC_Path attribute.
For each remaining Signature_Block (corresponding to an algorithm For each remaining Signature_Block (corresponding to an algorithm
suite supported by the BGPSEC speaker), the BGPSEC speaker iterates suite supported by the BGPSEC speaker), the BGPSEC speaker iterates
through the Signature segments in the Signature_Block, starting with through the Signature segments in the Signature_Block, starting with
the most recently added segment (and concluding with the least the most recently added segment (and concluding with the least
recently added segment). Note that there is a one-to-one recently added segment). Note that there is a one-to-one
skipping to change at page 28, line 30 skipping to change at page 27, line 30
understood not only by the peer to whom he is directly sending the understood not only by the peer to whom he is directly sending the
message, but also by all BGPSEC speakers to whom the route message, but also by all BGPSEC speakers to whom the route
advertisement is eventually propagated. Therefore, selection of an advertisement is eventually propagated. Therefore, selection of an
algorithm suite cannot be a local matter negotiated by BGP peers, but algorithm suite cannot be a local matter negotiated by BGP peers, but
instead must be coordinated throughout the Internet. instead must be coordinated throughout the Internet.
To this end, a mandatory algorithm suites document will be created To this end, a mandatory algorithm suites document will be created
which specifies a mandatory-to-use 'current' algorithm suite for use which specifies a mandatory-to-use 'current' algorithm suite for use
by all BGPSEC speakers [11]. by all BGPSEC speakers [11].
It is anticipated that in the future mandatory algorithm suites It is anticipated that, in the future mandatory, the algorithm suites
document will be updated to specify a transition from the 'current' document will be updated to specify a transition from the 'current'
algorithm suite to a 'new' algorithm suite. During the period of algorithm suite to a 'new' algorithm suite. During the period of
transition (likely a small number of years), all BGPSEC update transition (likely a small number of years), all BGPSEC update
messages SHOULD simultaneously use both the 'current' algorithm suite messages SHOULD simultaneously use both the 'current' algorithm suite
and the 'new' algorithm suite. (Note that Sections 3 and 4 specify and the 'new' algorithm suite. (Note that Sections 3 and 4 specify
how the BGPSEC_Path attribute can contain signatures, in parallel, how the BGPSEC_Path attribute can contain signatures, in parallel,
for two algorithm suites.) Once the transition is complete, use of for two algorithm suites.) Once the transition is complete, use of
the old 'current' algorithm will be deprecated, use of the 'new' the old 'current' algorithm will be deprecated, use of the 'new'
algorithm will be mandatory, and a subsequent 'even newer' algorithm algorithm will be mandatory, and a subsequent 'even newer' algorithm
suite may be specified as recommend to implement. Once the suite may be specified as recommend to implement. Once the
skipping to change at page 29, line 38 skipping to change at page 28, line 38
deprecated, at which point BGPSEC speakers SHOULD include only the deprecated, at which point BGPSEC speakers SHOULD include only the
new BGPSEC_PATH_TWO attribute. Such a process could facilitate a new BGPSEC_PATH_TWO attribute. Such a process could facilitate a
transition to a new BGPSEC semantics in a backwards compatible transition to a new BGPSEC semantics in a backwards compatible
fashion. fashion.
7. Security Considerations 7. Security Considerations
For discussion of the BGPSEC threat model and related security For discussion of the BGPSEC threat model and related security
considerations, please see [14]. considerations, please see [14].
7.1 Security Guarantees
A BGPSEC speaker who receives a valid BGPSEC update message, A BGPSEC speaker who receives a valid BGPSEC update message,
containing a route advertisement for a given prefix, is provided with containing a route advertisement for a given prefix, is provided with
the following security guarantees: the following security guarantees:
o The origin AS number corresponds to an autonomous system that has o The origin AS number corresponds to an autonomous system that has
been authorized, in the RPKI, by the IP address space holder to been authorized, in the RPKI, by the IP address space holder to
originate route advertisements for the given prefix. originate route advertisements for the given prefix.
o For each AS in the path, a BGPSEC speaker authorized by the holder o For each AS in the path, a BGPSEC speaker authorized by the holder
of the AS number intentionally chose (in accordance with local of the AS number intentionally chose (in accordance with local
policy) to propagate the route advertisement to the subsequent AS policy) to propagate the route advertisement to the subsequent AS
in the path. in the path.
That is, the recipient of a valid BGPSEC Update message is assured That is, the recipient of a valid BGPSEC Update message is assured
that the Secure_Path portion of the BGPSEC_Path attribute corresponds that the Secure_Path portion of the BGPSEC_Path attribute corresponds
to a sequence of autonomous systems who have all agreed in principle to a sequence of autonomous systems who have all agreed in principle
to forward packets to the given prefix along the indicated path. (It to forward packets to the given prefix along the indicated path. (It
should be noted that BGPSEC does not offer any guarantee that the should be noted that BGPSEC does not offer any guarantee that the
data packets would propagate along the indicated path; it only data packets would flow along the indicated path; it only guarantees
guarantees that the BGP update conveying the path indeed propagated that the BGP update conveying the path indeed propagated along the
along the indicated path.) Furthermore, the recipient is assured indicated path.) Furthermore, the recipient is assured that this
that this path terminates in an autonomous system that has been path terminates in an autonomous system that has been authorized by
authorized by the IP address space holder as a legitimate destination the IP address space holder as a legitimate destination for traffic
for traffic to the given prefix. to the given prefix.
Note that although BGPSEC provides a mechanism for an AS to validate Note that although BGPSEC provides a mechanism for an AS to validate
that a received update message has certain security properties, the that a received update message has certain security properties, the
use of such a mechanism to influence route selection is completely a use of such a mechanism to influence route selection is completely a
matter of local policy. Therefore, a BGPSEC speaker can make no matter of local policy. Therefore, a BGPSEC speaker can make no
assumptions about the validity of a route received from an external assumptions about the validity of a route received from an external
BGPSEC peer. That is, a compliant BGPSEC peer may (depending on the BGPSEC peer. That is, a compliant BGPSEC peer may (depending on the
local policy of the peer) send update messages that fail the validity local policy of the peer) send update messages that fail the validity
test in Section 5. Thus, a BGPSEC speaker MUST completely validate test in Section 5. Thus, a BGPSEC speaker MUST completely validate
all BGPSEC update messages received from external peers. (Validation all BGPSEC update messages received from external peers. (Validation
of update messages received from internal peers is a matter of local of update messages received from internal peers is a matter of local
policy, see Section 5). policy, see Section 5).
Note that there may be cases where a BGPSEC speaker deems 'Valid' (as 7.2 On the Removal of BGPSEC Signatures
per the validation algorithm in Section 5.2) a BGPSEC update message
that contains both a 'Valid' and a 'Not Valid' Signature_Block. That There may be cases where a BGPSEC speaker deems 'Valid' (as per the
is, the update message contains two sets of signatures corresponding validation algorithm in Section 5.2) a BGPSEC update message that
to two algorithm suites, and one set of signatures verifies correctly contains both a 'Valid' and a 'Not Valid' Signature_Block. That is,
the update message contains two sets of signatures corresponding to
two algorithm suites, and one set of signatures verifies correctly
and the other set of signatures fails to verify. In this case, the and the other set of signatures fails to verify. In this case, the
protocol specifies that if the BGPSEC speaker propagates the route protocol specifies that a BGPSEC speaker choosing to propagate the
advertisement received in such an update message then the BGPSEC route advertisement in such an update message SHOULD add its
speaker SHOULD add its signature to each of the Signature_Blocks signature to each of the Signature_Blocks. Thus the BGPSEC speaker
using both the corresponding algorithm suite. Thus the BGPSEC creates a signature using both algorithm suites and creates a new
speaker creates a signature using both algorithm suites and creates a update message that contains both the 'Valid' and the 'Not Valid' set
new update message that contains both the 'Valid' and the 'Not Valid' of signatures (from its own vantage point).
set of signatures (from its own vantage point).
To understand the reason for such a design decision consider the case To understand the reason for such a design decision consider the case
where the BGPSEC speaker receives an update message with both a set where the BGPSEC speaker receives an update message with both a set
of algorithm A signatures which are 'Valid' and a set of algorithm B of algorithm A signatures which are 'Valid' and a set of algorithm B
signatures which are 'Not Valid'. In such a case it is possible signatures which are 'Not Valid'. In such a case it is possible
(perhaps even quite likely) that some of the BGPSEC speaker's peers (perhaps even likely, depending on the state of the algorithm
(or other entities further 'downstream' in the BGP topology) do not transition) that some of the BGPSEC speaker's peers (or other
support algorithm A. Therefore, if the BGPSEC speaker were to remove entities further 'downstream' in the BGP topology) do not support
the 'Not Valid' set of signatures corresponding to algorithm B, such algorithm A. Therefore, if the BGPSEC speaker were to remove the 'Not
entities would treat the message as though it were unsigned. By Valid' set of signatures corresponding to algorithm B, such entities
including the 'Not Valid' set of signatures when propagating a route would treat the message as though it were unsigned. By including the
advertisement, the BGPSEC speaker ensures that 'downstream' entities 'Not Valid' set of signatures when propagating a route advertisement,
have as much information as possible to make an informed opinion the BGPSEC speaker ensures that 'downstream' entities have as much
about the validation status of a BGPSEC update. information as possible to make an informed opinion about the
validation status of a BGPSEC update.
Note also that during a period of partial BGPSEC deployment, a Note also that during a period of partial BGPSEC deployment, a
'downstream' entity might reasonably treat unsigned messages 'downstream' entity might reasonably treat unsigned messages
different from BGPSEC updates that contain a single set of 'Not differently from BGPSEC updates that contain a single set of 'Not
Valid' signatures. That is, by removing the set of 'Not Valid' Valid' signatures. That is, by removing the set of 'Not Valid'
signatures the BGPSEC speaker might actually cause a downstream signatures the BGPSEC speaker might actually cause a downstream
entity to 'upgrade' the status of a route advertisement from 'Not entity to 'upgrade' the status of a route advertisement from 'Not
Valid' to unsigned. Finally, note that in the above scenario, the Valid' to unsigned. Finally, note that in the above scenario, the
BGPSEC speaker might have deemed algorithm A signatures 'Valid' only BGPSEC speaker might have deemed algorithm A signatures 'Valid' only
because of some issue with RPKI state local to his AS (for example, because of some issue with RPKI state local to his AS (for example,
his AS might not yet have obtained a CRL indicating that a key used his AS might not yet have obtained a CRL indicating that a key used
to verify an algorithm A signature belongs to a newly revoked to verify an algorithm A signature belongs to a newly revoked
certificate). In such a case, it is highly desirable for a certificate). In such a case, it is highly desirable for a
downstream entity to treat the update as 'Not Valid' (due to the downstream entity to treat the update as 'Not Valid' (due to the
revocation) and not as 'unsigned' (which would happen if the 'Not revocation) and not as 'unsigned' (which would happen if the 'Not
Valid' Signature_Blocks were removed). Valid' Signature_Blocks were removed).
A similar argument applies to the case where a BGPSEC speaker (for A similar argument applies to the case where a BGPSEC speaker (for
some reason such as lack of viable alternatives) selects as his best some reason such as lack of viable alternatives) selects as his best
route to a given prefix a route obtained via a 'Not Valid' BGPSEC path (to a given prefix) a route obtained via a 'Not Valid' BGPSEC
update message. (That is, a BGPSEC update containing only 'Not update message. In such a case, the BGPSEC speaker should propagate a
Valid' Signature_Blocks.) In such a case, the BGPSEC speaker should signed BGPSEC update message, adding his signature to the 'Not Valid'
propagate a signed BGPSEC update message, adding his signature to the signatures that already exist. Again, this is to ensure that
'Not Valid' signatures that already exist. Again, this is to ensure 'downstream' entities are able to make an informed decision and not
that 'downstream' entities are able to make an informed decision and erroneously treat the route as unsigned. It should also be noted
not erroneously treat the route as unsigned. It may also be noted that due to possible differences in RPKI data observed at different
here that due to possible differences in RPKI data at different vantage points in the network, a BGPSEC update deemed 'Not Valid' at
vantage points in the network, a BGPSEC update that was deemed 'Not an upstream BGPSEC speaker may be deemed 'Valid' by another BGP
Valid' at an upstream BGPSEC speaker may indeed be deemed 'Valid' at speaker downstream.
another BGP speaker downstream.
Therefore, it is important to note that when a BGPSEC speaker signs Indeed, when a BGPSEC speaker signs an outgoing update message, it is
an outgoing update message, it is not attesting to a belief that all not attesting to a belief that all signatures prior to its are valid.
signatures prior to its are valid. Instead it is merely asserting Instead it is merely asserting that:
that:
o The BGPSEC speaker received the given route advertisement with the o The BGPSEC speaker received the given route advertisement with the
indicated NLRI and Secure_Path; and indicated NLRI and Secure_Path; and
o The BGPSEC speaker chose to propagate an advertisement for this o The BGPSEC speaker chose to propagate an advertisement for this
route to the peer (implicitly) indicated by the 'Target AS' route to the peer (implicitly) indicated by the 'Target AS'
7.3 Mitigation of Denial of Service Attacks
The BGPSEC update validation procedure is a potential target for The BGPSEC update validation procedure is a potential target for
denial of service attacks against a BGPSEC speaker. To mitigate the denial of service attacks against a BGPSEC speaker. To mitigate the
effectiveness of such denial of service attacks, BGPSEC speakers effectiveness of such denial of service attacks, BGPSEC speakers
should implement an update validation algorithm that performs should implement an update validation algorithm that performs
expensive checks (e.g., signature verification) after performing less expensive checks (e.g., signature verification) after performing less
expensive checks (e.g., syntax checks). The validation algorithm expensive checks (e.g., syntax checks). The validation algorithm
specified in Section 5.2 was chosen so as to perform checks which are specified in Section 5.2 was chosen so as to perform checks which are
likely to be expensive after checks that are likely to be likely to be expensive after checks that are likely to be
inexpensive. However, the relative cost of performing required inexpensive. However, the relative cost of performing required
validation steps may vary between implementations, and thus the validation steps may vary between implementations, and thus the
algorithm specified in Section 5.2 may not provide the best denial of algorithm specified in Section 5.2 may not provide the best denial of
service protection for all implementations. service protection for all implementations.
7.4 Additional Security Considerations
The mechanism of setting the pCount field to zero is included in this The mechanism of setting the pCount field to zero is included in this
specification to enable route servers in the control path to specification to enable route servers in the control path to
participate in BGPSEC without increasing the effective length of the participate in BGPSEC without increasing the effective length of the
AS-PATH. However, entities other than route servers could AS-PATH. However, entities other than route servers could
conceivably use this mechanism (set the pCount to zero) to attract conceivably use this mechanism (set the pCount to zero) to attract
traffic (by reducing the effective length of the AS-PATH) traffic (by reducing the effective length of the AS-PATH)
illegitimately. This risk is largely mitigated if every BGPSEC illegitimately. This risk is largely mitigated if every BGPSEC
speaker drops incoming update messages that set pCount to zero but speaker drops incoming update messages that set pCount to zero but
come from a peer that is not a route server. However, note that a come from a peer that is not a route server. However, note that a
recipient of a BGPSEC update message in which an upstream entity that recipient of a BGPSEC update message within which an upstream entity
is two or more hops away set pCount to zero is unable to verify for two or more hops away has set pCount to zero is unable to verify for
themselves whether pCount was set to zero legitimately. themselves whether pCount was set to zero legitimately.
Finally, BGPSEC does not provide protection against attacks at the BGPSEC does not provide protection against attacks at the transport
transport layer. An adversary on the path between a BGPSEC speaker layer. An adversary on the path between a BGPSEC speaker and its
and its peer is able to perform attacks such as modifying valid peer is able to perform attacks such as modifying valid BGPSEC
BGPSEC updates to cause them to fail validation, injecting (unsigned) updates to cause them to fail validation, injecting (unsigned) BGP
BGP update messages without BGPSEC_Path_Signature attributes, or update messages without BGPSEC_Path_Signature attributes, or
injecting BGPSEC update messages with BGPSEC_Path_Signature injecting BGPSEC update messages with BGPSEC_Path_Signature
attributes that fail validation, or causing the peer to tear-down the attributes that fail validation, or causing the peer to tear-down the
BGP session. Therefore, BGPSEC sessions SHOULD be protected by BGP session. Therefore, BGPSEC sessions SHOULD be protected by
appropriate transport security mechanisms. appropriate transport security mechanisms.
8. IANA Considerations 8. IANA Considerations
TBD: Need IANA to assign numbers for the two capabilities and the TBD: Need IANA to assign numbers for the two capabilities and the
BGPSEC_PATH attribute. BGPSEC_PATH attribute.
skipping to change at page 34, line 7 skipping to change at page 32, line 51
Kotikalapudi Sriram Kotikalapudi Sriram
USA National Institute of Standards and Technology USA National Institute of Standards and Technology
kotikalapudi.sriram@nist.gov kotikalapudi.sriram@nist.gov
Samuel Weiler Samuel Weiler
Sparta Sparta
weiler+ietf@watson.org weiler+ietf@watson.org
9.2. Acknowledgements 9.2. Acknowledgements
The authors would like to thank Luke Berndt, Sharon Goldberg, Ed The authors would like to thank Michael Baer, Luke Berndt, Sharon
Kern, Chris Morrow, Doug Maughan, Pradosh Mohapatra, Russ Mundy, Goldberg, Ed Kern, Chris Morrow, Doug Maughan, Pradosh Mohapatra,
Sandy Murphy, Keyur Patel, Mark Reynolds, Heather Schiller, Jason Russ Mundy, Sandy Murphy, Keyur Patel, Mark Reynolds, Heather
Schiller, John Scudder, Ruediger Volk and David Ward for their Schiller, Jason Schiller, John Scudder, Ruediger Volk and David Ward
valuable input and review. for their valuable input and review.
10. Normative References 10. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border [2] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border
Gateway Protocol 4", RFC 4271, January 2006. Gateway Protocol 4", RFC 4271, January 2006.
[3] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [3] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
skipping to change at page 34, line 41 skipping to change at page 33, line 36
BGP-4", RFC 5492, February 2009. BGP-4", RFC 5492, February 2009.
[7] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure [7] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure
Internet Routing", RFC 6480, February 2012. Internet Routing", RFC 6480, February 2012.
[8] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route [8] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)", RFC 6482, February 2012. Origin Authorizations (ROAs)", RFC 6482, February 2012.
[9] Patel, K., Ward, D., and R. Bush, "Extended Message support for [9] Patel, K., Ward, D., and R. Bush, "Extended Message support for
BGP", draft-ietf-idr-bgp-extended-messages (work in progress), BGP", draft-ietf-idr-bgp-extended-messages (work in progress),
August 2013. January 2014.
[10] Reynolds, M., Turner, S., and S. Kent, "A Profile for BGPSEC [10] Reynolds, M., Turner, S., and S. Kent, "A Profile for BGPSEC
Router Certificates, Certificate Revocation Lists, and Router Certificates, Certificate Revocation Lists, and
Certification Requests", draft-ietf-sidr-bgpsec-pki-profiles Certification Requests", draft-ietf-sidr-bgpsec-pki-profiles
(work in progress), September 2013. (work in progress), March 2014.
[11] Turner, S., "BGP Algorithms, Key Formats, & Signature Formats", [11] Turner, S., "BGP Algorithms, Key Formats, & Signature Formats",
draft-ietf-sidr-bgpsec-algs (work in progress), September 2013. draft-ietf-sidr-bgpsec-algs (work in progress), July 2014.
[12] Scudder, J., Chen, E., Mohapatra, P., and K. Patel, "Revised [12] Scudder, J., Chen, E., Mohapatra, P., and K. Patel, "Revised
Error Handling for BGP UPDATE Messages", draft-ietf-idr-error- Error Handling for BGP UPDATE Messages", draft-ietf-idr-error-
handling (work in progress), June 2013. handling (work in progress), June 2014.
11. Informative References 11. Informative References
[13] Kumari, W. and K. Sriram, "Recommendation for Not Using AS_SET [13] Kumari, W. and K. Sriram, "Recommendation for Not Using AS_SET
and AS_CONFED_SET in BGP", RFC 6472, December 2011. and AS_CONFED_SET in BGP", RFC 6472, December 2011.
[14] Kent, S., "Threat Model for BGP Path Security", draft-ietf- [14] Kent, S., "Threat Model for BGP Path Security", draft-ietf-
sidr-bgpsec-threats (work in progress), Octoboer 2013. sidr-bgpsec-threats (work in progress), December 2013.
[15] Bush, R. and R. Austein, "The Resource Public Key [15] Bush, R. and R. Austein, "The Resource Public Key
Infrastructure (RPKI) to Router Protocol", RFC 6810, January Infrastructure (RPKI) to Router Protocol", RFC 6810, January
2013. 2013.
[16] Bush, R., Patel, K., and S. Turner, "Router Key PDU for RPKI- [16] Bush, R., Patel, K., and S. Turner, "Router Key PDU for RPKI-
Router Protocol", draft-ymbk-rpki-rtr-keys (work in progress), Router Protocol", draft-ymbk-rpki-rtr-keys (work in progress),
April 2013. April 2013.
[17] Bush, R., "BGPsec Operational Considerations", draft-ietf-sidr- [17] Bush, R., "BGPsec Operational Considerations", draft-ietf-sidr-
bgpsec-ops (work in progress), May 2012. bgpsec-ops (work in progress), May 2012.
Author's Address Author's Address
Matthew Lepinski (editor) Matthew Lepinski (editor)
BBN BBN Technologies
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.ietf@gmail.com Email: mlepinski.ietf@gmail.com
 End of changes. 55 change blocks. 
180 lines changed or deleted 178 lines changed or added

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