draft-ietf-sidr-bgpsec-protocol-01.txt   draft-ietf-sidr-bgpsec-protocol-02.txt 
Network Working Group M. Lepinski, Ed. Network Working Group M. Lepinski, Ed.
Internet-Draft BBN Internet-Draft BBN
Intended status: Standards Track October 31, 2011 Intended status: Standards Track March 12, 2012
Expires: May 3, 2012 Expires: September 13, 2012
BGPSEC Protocol Specification BGPSEC Protocol Specification
draft-ietf-sidr-bgpsec-protocol-01 draft-ietf-sidr-bgpsec-protocol-02
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 AS-PATH attribute in Protocol (BGP) that provides security for the AS-PATH attribute in
BGP update messages. BGPSEC is implemented via a new optional non- BGP update messages. BGPSEC is implemented via a new optional non-
transitive BGP path attribute that carries a digital signature transitive BGP path attribute that carries a digital signature
produced by each autonomous system on the AS-PATH. produced by each autonomous system on the AS-PATH.
Requirements Language Requirements Language
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 May 3, 2012. This Internet-Draft will expire on September 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. BGPSEC Negotiation . . . . . . . . . . . . . . . . . . . . . . 3 2. BGPSEC Negotiation . . . . . . . . . . . . . . . . . . . . . . 3
3. The BGPSEC_Path_Signatures Attribute . . . . . . . . . . . . . 5 3. The BGPSEC_Path_Signatures Attribute . . . . . . . . . . . . . 6
4. Generating a BGPSEC Update . . . . . . . . . . . . . . . . . . 7 4. Generating a BGPSEC Update . . . . . . . . . . . . . . . . . . 9
4.1. Originating a New BGPSEC Update . . . . . . . . . . . . . 8 4.1. Originating a New BGPSEC Update . . . . . . . . . . . . . 10
4.2. Propagating a Route Advertisement . . . . . . . . . . . . 11 4.2. Propagating a Route Advertisement . . . . . . . . . . . . 13
4.2.1. Propogating an Update without the Path_Signatures 5. Processing a Received BGPSEC Update . . . . . . . . . . . . . 16
attribute . . . . . . . . . . . . . . . . . . . . . . 14
5. Processing a Received BGPSEC Update . . . . . . . . . . . . . 15
5.1. Validation Algorithm . . . . . . . . . . . . . . . . . . . 17 5.1. Validation Algorithm . . . . . . . . . . . . . . . . . . . 17
6. Algorithms and Extensibility . . . . . . . . . . . . . . . . . 21 6. Algorithms and Extensibility . . . . . . . . . . . . . . . . . 20
6.1. Algorithm Suite Considerations . . . . . . . . . . . . . . 21 6.1. Algorithm Suite Considerations . . . . . . . . . . . . . . 21
6.2. Extensibility Considerations . . . . . . . . . . . . . . . 21 6.2. Extensibility Considerations . . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26 8.1. Authors . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.1. Authors . . . . . . . . . . . . . . . . . . . . . . . . . 26 8.2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 26
9.2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 27 9. Normative References . . . . . . . . . . . . . . . . . . . . . 26
10. Normative References . . . . . . . . . . . . . . . . . . . . . 27 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28
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) [1] route advertisements. security for Border Gateway Protocol (BGP) [1] 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 that has been explicitly 1. The route was originated by an AS that has been explicitly
skipping to change at page 3, line 47 skipping to change at page 3, line 47
2. BGPSEC Negotiation 2. BGPSEC Negotiation
This document defines a new BGP capability [3]that allows a BGP This document defines a new BGP capability [3]that allows a BGP
speaker to advertise to its neighbors the ability to send and/or speaker to advertise to its neighbors the ability to send and/or
receive BGPSEC update messages (i.e., update messages containing the receive BGPSEC update messages (i.e., update messages containing the
BGPSEC_Path_Signatures attribute). BGPSEC_Path_Signatures attribute).
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 5.
The three octets of the capability value are specified as follows. The three octets of the capability value are specified as follows.
Capability Value: Capability Value:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---------------------------------------+ +---------------------------------------+
| Send | Receive | Reserved | Version | | Send | Receive | Reserved | Version |
+---------------------------------------+ +---------------------------------------+
| AFI | | AFI |
+---------------------------------------+ +---------------------------------------+
| | | |
+---------------------------------------+ +---------------------------------------+
| Reserved |
+---------------------------------------+
| SAFI |
+---------------------------------------+
The high order bit (bit 0) of the first octet is set to 1 to indicate The high order bit (bit 0) of the first octet is set to 1 to indicate
that the sender is able to send BGPSEC update messages, and is set to that the sender is able to send BGPSEC update messages, and is set to
zero otherwise. The next highest order bit (bit 1) of this octet is zero otherwise. The next highest order bit (bit 1) of this octet is
set to 1 to indicate that the sender is able to receive BGPSEC update set to 1 to indicate that the sender is able to receive BGPSEC update
messages, and is set to zero otherwise. The next two bits of the messages, and is set to zero otherwise. The next two bits of the
capability value (bits 2 and 3) are reserved for future use. capability value (bits 2 and 3) are reserved for future use. These
reserved bits should be set to zero by the sender and ignored by the
receiver.
The four low order bits (4, 5, 6 and 7) of the first octet indicate The four low order bits (4, 5, 6 and 7) of the first octet indicate
the version of BGPSEC for which the BGP speaker is advertising the version of BGPSEC for which the BGP speaker is advertising
support. This document defines only BGPSEC version 0 (all four bits support. This document defines only BGPSEC version 0 (all four bits
set to zero). Other versions of BGPSEC may be defined in future set to zero). Other versions of BGPSEC may be defined in future
documents. A BGPSEC speaker MAY advertise support for multiple documents. A BGPSEC speaker MAY advertise support for multiple
versions of BGPSEC by including multiple versions of the BGPSEC versions of BGPSEC by including multiple versions of the BGPSEC
capability in its BGP OPEN message. capability in its BGP OPEN message.
If there does not exist at least one version of BGPSEC that is If there does not exist at least one version of BGPSEC that is
skipping to change at page 4, line 43 skipping to change at page 4, line 49
not been negotiated. (That is, in such a case, messages containing not been negotiated. (That is, in such a case, messages containing
the BGPSEC_Path_Signatures MUST NOT be sent.) the BGPSEC_Path_Signatures MUST NOT be sent.)
If version 0 is the only version of BGPSEC for which both peers (in a If version 0 is the only version of BGPSEC for which both peers (in a
BGP session) advertise support, then the use of BGPSEC has been BGP session) advertise support, then the use of BGPSEC has been
negotiated and the BGPSEC peers MUST adhere to the specification of negotiated and the BGPSEC peers MUST adhere to the specification of
BGPSEC provided in this document. (If there are multiple versions of BGPSEC provided in this document. (If there are multiple versions of
BGPSEC which are supported by both peers, then the behavior of those BGPSEC which are supported by both peers, then the behavior of those
peers is outside the scope of this document.) peers is outside the scope of this document.)
The second two octets contain the 16-bit Address Family Identifier The second and third octets contain the 16-bit Address Family
(AFI) which indicates the address family for which the BGPSEC speaker Identifier (AFI) which indicates the address family for which the
is advertising support for BGPSEC. This document only specifies BGPSEC speaker is advertising support for BGPSEC. This document only
BGPSEC for use with two address families, IPv4 and IPv6. BGPSEC for specifies BGPSEC for use with two address families, IPv4 and IPv6,
use with other address families may be specified in future documents. AFI values 1 and 2 respectively. BGPSEC for use with other address
families may be specified in future documents.
The fourth octet in the capability is reserved. It is anticipated
that this octet will not be used until such a time as the reserved
octet in the Multi-protocol extensions capability advertisement [2]
is specified for use. The reserved octet should be set to zero by
the sender and ignored by the receiver.
The fifth octet in the capability contains the 8-bit Subsequent
Address Family Identifier (SAFI). This value is encoded as in the
BGP multiprotocol extensions [2].
Note that if the BGPSEC speaker wishes to use BGPSEC with two Note that if the BGPSEC speaker wishes to use BGPSEC with two
different address families (i.e., IPv4 and IPv6) over the same BGP different address families (i.e., IPv4 and IPv6) over the same BGP
session, then the speaker must include two instances of this session, then the speaker must include two instances of this
capability (one for each address family) in the BGP OPEN message. capability (one for each address family) in the BGP OPEN message. A
Also note that a BGPSEC speaker SHOULD NOT advertise the capability BGPSEC speaker SHOULD NOT advertise the capability of BGPSEC support
of BGPSEC support for IPv6 unless it has also advertised support for for any <AFI, SAFI> combination unless it has also includes the
IPv6 [2]. multiprotocol extension capability for the same <AFI, SAFI>
combination [2].
By indicating support for receiving BGPSEC update messages, a BGP By indicating support for receiving BGPSEC update messages, a BGP
speaker is, in particular, indicating that the following are true: speaker is, in particular, indicating that the following are true:
o The BGP speaker understands the BGPSEC_Path_Signatures attribute o The BGP speaker understands the BGPSEC_Path_Signatures attribute
(see Section 3). (see Section 3).
o The BGP speaker supports 4-byte AS numbers (see RFC 4893). o The BGP speaker supports 4-byte AS numbers (see RFC 4893).
Note that BGPSEC update messages can be quite large, therefore any Note that BGPSEC update messages can be quite large, therefore any
skipping to change at page 5, line 41 skipping to change at page 6, line 16
The BGPSEC_Path_Signatures attribute is a new optional (non- The BGPSEC_Path_Signatures attribute is a new optional (non-
transitive) BGP path attribute. transitive) BGP path 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_Signatures attribute has the following structure: The BGPSEC_Path_Signatures attribute has the following structure:
BGPSEC_Path_Signatures Attribute BGPSEC_Path_Signatures Attribute
+---------------------------------------------------------+ +---------------------------------------------------------+
| Expire Time (8 octets) | | Flags Octet (1 octet) |
+---------------------------------------------------------+ +---------------------------------------------------------+
| Sequence of one or two Signature-List Blocks (variable) | | Algorithm Suite Identifier 1 (1 octet) |
+---------------------------------------------------------+
| Algorithm Suite Identifier 2 (1 octet) |
+---------------------------------------------------------+
| Reserved (8 octets) |
+---------------------------------------------------------+
| Sequence of Signature-Segments (variable) |
+---------------------------------------------------------+ +---------------------------------------------------------+
Expire Time contains a binary representation of a time as an unsigned The flags octet is an unsigned octet that contains flags to aid in
integer number of (non-leap) seconds that have elapsed since midnight receiver processing.
UTC January 1, 1970. The Expire Time indicates the latest point in
time that the route advertised in the update message can possibly be
considered valid (see Section 5 for details on validity of BGPSEC
update messages).
The BGPSEC_Path_Signatures attribute will contain one or two Flags Octet in Path_Signatures Attribute
Signature-List Blocks, each of which corresponds to a different
algorithm suite. Each of the Signature-List Blocks will contain a
signature segment for each AS in the AS Path attribute. In the most
common case, the BGPSEC_Path_Signatures attribute will contain only a
single Signature-List Block. However, in order to enable a
transition from an old algorithm suite to a new algorithm suite, it
will be necessary to include two Signature-List Blocks (one for the
old algorithm suite and one for the new algorithm suite) during the
transition period.
Signature-List Block 0 1 2 3 4 5 6 7
+-------------------------------------------+
| Two Algorithms | Reserved |
+-------------------------------------------+
+---------------------------------------------+ The first bit in the Flags octet is set to zero in the common case
| Algorithm Suite Identifier (1 octet) | that each Signature-Segment contains a single signature. The first
+---------------------------------------------+ bit of the Flags octet is set to one in the case that each Signature-
| Signature-List Block Length (2 octets) | Segment contains two signatures, produced by two different algorithm
+---------------------------------------------+ suites. (Note that this second case is necessary to support a
| Sequence of Signature-Segments (variable) | transition between two algorithm suites, see Section 8.) The
+---------------------------------------------+ remaining 7 bits of the Flags octet are reserved for future use.
These bits should be set to zero by the sender and ignored by the
receiver.
An algorithm suite consists of a digest algorithm and a signature Algorithm Suite Identifier 1 contains a one-octet identifier
algorithm. This version of BGPSEC only supports signature algorithms specifying the digest algorithm and digital signature algorithm used
that produce a signatures of fixed length. Future registrations of to produce the first signature in each Signature-Segment. An IANA
algorithm suites for BGPSEC must specify the length of signatures registry of algorithm identifiers for use in BGPSEC is created in the
produced by the algorithm suite. This specification creates an IANA BGPSEC algorithms document[10].
registry of one-octet BGPSEC algorithm suite identifiers (see Section
8).
The Signature-List Block Length is the total number of octets in all Algorithm Suite Identifier 2 contains a one-octet identifier
Signature-Segments (i.e., the total size of the variable-length specifying the digest algorithm and digital signature algorithm used
portion of the Signature-List block.) to produce the second signature in each Signature-Segment. This
field is ignored by the receiver if the first bit in the Flags octet
is set to zero (indicating that only one signature algorithm is used
in this BGPSEC update). An IANA registry of algorithm identifiers
for use in BGPSEC is created in the BGPSEC algorithms document[10].
A Signature-Segment has the following structure: There are eight octets reserved for future use. These octets are
digitally signed (see Section 4 below).
EDITOR'S NOTE: In a previous version of this document there was an
Expire Time that was used to provide protection against replay of old
(stale) digital signatures or failure to propagate a withdrawal
message. This mechanism was removed from the current version of the
document. Please see the SIDR mailing list for discussions related
to protection against replay attacks. Depending on the result of
discussions within the SIDR working group this reserved field could
at some future point be used to re-introduce Expire Time, or some
other octets used in a future replay protection mechanism.
The BGPSEC_Path_Signatures attribute contains one Signature-Segment
for each AS along the path of the route advertisement in this update
message. (For a detailed explanation of how an AS processes a BGPSEC
update message and adds a new Signature_Segment, see Section 4.) A
Signature-Segment has the following structure:
Signature Segments Signature Segments
+-------------------------------------------- + +-------------------------------------------- +
| pCount (1 octet) | | AS Number (4 octets) |
+---------------------------------------------+ +---------------------------------------------+
| Subject Key Identifier Length (1 octet) | | pCount (1 octet) |
+---------------------------------------------+ +---------------------------------------------+
| Subject Key Identifier (variable) | | Subject Key Identifier 1 Length (1 octet) |
+---------------------------------------------+ +---------------------------------------------+
| Signature (fixed by algorithm suite) | | Subject Key Identifier 1 (variable) |
+---------------------------------------------+
| Signature 1 Length (1 octet) |
+---------------------------------------------+
| Signature 1 (variable) |
+---------------------------------------------+
| Subject Key Identifier 2 Length (1 octet) |
+---------------------------------------------+
| Subject Key Identifier 2 (variable) |
+---------------------------------------------+
| Signature Length 2 (1 octet) |
+---------------------------------------------+
| Signature 2 (variable) |
+---------------------------------------------+ +---------------------------------------------+
The AS Number is the Autonomous System Number of the BGPSEC speaker
that produced the digital signature(s) in this Signature Segment.
The pCount field contains an unsigned integer indicating the number The pCount field contains an unsigned integer indicating the number
of repetitions of the associated autonomous system number that the of repetitions of the associated autonomous system number that the
signature covers. This field enables a BGPSEC speaker to mimic the signature covers. This field enables a BGPSEC speaker to mimic the
semantics of adding multiple copies of their AS to the AS-PATH semantics of adding multiple copies of their AS to the AS-PATH
without requiring the speaker to generate multiple signatures. without requiring the speaker to generate multiple signatures.
The Subject Key Identifier Length contains the size (in octets) of The Subject Key Identifier 1 Length field contains the size (in
the value in the Subject Key Identifier field of the Signature- octets) of the value in the Subject Key Identifier 1 field of the
Segment. The Subject Key Identifier contains the value in the Signature-Segment. The Subject Key Identifier 1 field contains the
Subject Key Identifier extension of the RPKI end-entity certificate value in the Subject Key Identifier extension of the RPKI end-entity
that is used to verify the signature (see Section 5 for details on certificate that is used to verify the first signature in the
validity of BGPSEC update messages). Signature-Segment (see Section 5 for details on validity of BGPSEC
update messages).
The Signature contains a digital signature that protects the NLRI, The Signature 1 Length field contains the size (in octets) of the
the AS_Path and the BGPSEC_Path_Signatures attribute (see Sections 4 value in the Signature 1 field. The Signature 1 field contains a
and 5 for details on generating and verifying this signature, digital signature that protects the NLRI and the
respectively). The length of the Signature field is a function of BGPSEC_Path_Signatures attribute (see Sections 4 and 5 for details on
the algorithm suite for a given Signature-List Block. The generating and verifying this signature, respectively).
specification for each BGPSEC algorithm suite must provide the length
of signatures constructed using the given algorithm suite. The Subject Key Identifier 2 Length field contains the size (in
octets) of the value in the Subject Key Identifier 2 field of the
Signature-Segment. This length field SHOULD be zero if the first bit
in the Flags octet is zero (indicating that only one algorithm suite
is being used to generate signatures for this update message). The
Subject Key Identifier 2 field contains the value in the Subject Key
Identifier extension of the RPKI end-entity certificate that is used
to verify the second signature in the Signature-Segment (see Section
5 for details on validity of BGPSEC update messages). This field is
ignored by the receiver when the first bit in the Flags octet is zero
(indicating that only one algorithm suite is being used to generate
signatures for this update message).
The Signature 2 Length field contains the size (in octets) of the
value in the Signature 2 field. This length field SHOULD be zero if
the first bit in the Flags octet is zero (indicating that only one
algorithm suite is being used to generate signatures for this update
message). The Signature 2 field contains a digital signature that
protects the NLRI and the BGPSEC_Path_Signatures attribute (see
Sections 4 and 5 for details on generating and verifying this
signature, respectively). This field is ignored by the receiver when
the first bit in the Flags octet is zero (indicating that only one
algorithm suite is being used to generate signatures for this update
message).
4. Generating a BGPSEC Update 4. Generating a BGPSEC Update
Sections 4.1 and 4.2 cover two cases in which a BGPSEC speaker may Sections 4.1 and 4.2 cover two cases in which a BGPSEC speaker may
generate an update message containing the BGPSEC_Path_Signatures generate an update message containing the BGPSEC_Path_Signatures
attribute. The first case is that in which the BGPSEC speaker attribute. The first case is that in which the BGPSEC speaker
originates a new route advertisement (Section 4.1). That is, the originates a new route advertisement (Section 4.1). That is, the
BGPSEC speaker is constructing an update message in which the only AS BGPSEC speaker is constructing an update message in which the only AS
to appear in the AS Path attribute is the speaker's own AS (normally to appear in the AS_PATH attribute is the speaker's own AS (normally
appears once but may appear multiple times if AS prepending is appears once but may appear multiple times if AS prepending is
applied). The second case is that in which the BGPSEC speaker applied). The second case is that in which the BGPSEC speaker
receives a route advertisement from a peer and then decides to receives a route advertisement from a peer and then decides to
propagate the route advertisement to an external (eBGP) peer (Section propagate the route advertisement to an external (eBGP) peer (Section
4.2). That is, the BGPSEC speaker has received a BGPSEC update 4.2). That is, the BGPSEC speaker has received a BGPSEC update
message and is constructing a new update message for the same NLRI in message and is constructing a new update message for the same NLRI in
which the AS Path attribute will contain AS number(s) other than the which the AS_PATH attribute will contain AS number(s) other than the
speaker's own AS. speaker's own AS.
In the remaining case where the BGPSEC speaker is sending the update In the remaining case where the BGPSEC speaker is sending the update
message to an internal (iBGP) peer, the BGPSEC speaker populates the message to an internal (iBGP) peer, the BGPSEC speaker populates the
BGPSEC_Path_Signatures attribute by copying the BGPSEC_Path_Signatures attribute by copying the
BGPSEC_Path_Signatures attribute from the received update message. BGPSEC_Path_Signatures attribute from the received update message.
That is, the BGPSEC_Path_Signatures attribute is copied verbatim. That is, the BGPSEC_Path_Signatures attribute is copied verbatim.
Note that in the case that a BGPSEC speaker chooses to forward to an Note that in the case that a BGPSEC speaker chooses to forward to an
iBGP peer a BGPSEC update message that has not been successfully iBGP peer a BGPSEC update message that has not been successfully
validated (see Section 5), the BGPSEC_Path_Signatures attribute validated (see Section 5), the BGPSEC_Path_Signatures attribute
SHOULD NOT be removed. (See Section 7 for the security ramifications SHOULD NOT be removed. (See Section 7 for the security ramifications
of removing BGPSEC signatures.) of removing BGPSEC signatures.)
The information protected by the signature on a BGPSEC update message The information protected by the signature on a BGPSEC update message
includes the AS number of the peer to whom the update message is includes the AS number of the peer to whom the update message is
being sent. Therefore, if a BGPSEC speaker wishes to send a BGPSEC being sent. Therefore, if a BGPSEC speaker wishes to send a BGPSEC
update to multiple BGP peers, it MUST generate a separate BGPSEC update to multiple BGP peers, it MUST generate a separate BGPSEC
skipping to change at page 8, line 34 skipping to change at page 10, line 26
sent. sent.
A BGPSEC update message MUST advertise a route to only a single NLRI. A BGPSEC update message MUST advertise a route to only a single NLRI.
This is because a BGPSEC speaker receiving an update message with This is because a BGPSEC speaker receiving an update message with
multiple NLRI is unable to construct a valid BGPSEC update message multiple NLRI is unable to construct a valid BGPSEC update message
(i.e., valid path signatures) containing a subset of the NLRI in the (i.e., valid path signatures) containing a subset of the NLRI in the
received update. If a BGPSEC speaker wishes to advertise routes to received update. If a BGPSEC speaker wishes to advertise routes to
multiple NLRI, then it MUST generate a separate BGPSEC update message multiple NLRI, then it MUST generate a separate BGPSEC update message
for each NLRI. for each NLRI.
Note that in order to create or add a new signature to a Signature- Note that in order to create or add a new signature to a BGPSEC
List Block for a given algorithm suite, the BGPSEC speaker must update message with a given algorithm suite, the BGPSEC speaker must
possess a private key suitable for generating signatures for this possess a private key suitable for generating signatures for this
algorithm suite. Additionally, this private key must correspond to algorithm suite. Additionally, this private key must correspond to
the public key in a valid Resource PKI end-entity certificate whose the public key in a valid Resource PKI end-entity certificate whose
AS number resource extension includes the BGPSEC speaker's AS number. AS number resource extension includes the BGPSEC speaker's AS number
Note also new signatures are only added to a BGPSEC update message [11]. Note also new signatures are only added to a BGPSEC update
when a BGPSEC speaker is generating an update message to send to an message when a BGPSEC speaker is generating an update message to send
external peer (i.e., when the AS number of the peer is not equal to to an external peer (i.e., when the AS number of the peer is not
the BGPSEC speaker's own AS number). Therefore, a BGPSEC speaker who equal to the BGPSEC speaker's own AS number). Therefore, a BGPSEC
only sends BGPSEC update messages to peers within its own AS, it does speaker who only sends BGPSEC update messages to peers within its own
not need to possess any private signature keys. AS, it does not need to possess any private signature keys.
4.1. Originating a New BGPSEC Update 4.1. Originating a New BGPSEC Update
In an update message that originates a new route advertisement (i.e., In an update message that originates a new route advertisement (i.e.,
an update whose AS_Path contains a single AS number), the BGPSEC an update whose AS_Path contains a single AS number), a BGPSEC
speaker creates one Signature-List Block for each algorithm suite speaker will use only a single algorithm suite. That is, the BGPSEC
that will be used. Typically, a BGPSEC speaker will use only a speaker will set the Two_Algorithms flag to 0 in the
single algorithm suite. However, to ensure backwards compatibility BGPSEC_Path_Signatures attribute and include only a single signature
during a period of transition from a 'current' algorithm suite to a in the Signature-Segment (setting the Signature 2 Length and Subject
'new' algorithm suite, it will be necessary to originate update Key Identifier 2 Lengths to zero). However, to ensure backwards
messages containing Signature-List Blocks for both the 'current' and compatibility during a period of transition from a 'current'
the 'new' algorithm suites (see Section 6.1). algorithm suite to a 'new' algorithm suite, it will be necessary to
originate update messages containing both the 'current' and the 'new'
algorithm suites (see Section 6.1). In such a case the BGPSEC
speaker will set the Two_Algorithms flag to 1 in the
BGPSEC_Path_Signatures attribute and include two separate digital
signatures (one for each algorithm suite). For the remainder of this
section we describe the common case where the Two_Algorithms flag is
set to one. However, the construction of the second signature is
completely analogous (the only change is the replacement of 1 by 2 in
the field names corresponding to the second signature).
The Resource PKI enables the legitimate holder of IP address The Resource PKI enables the legitimate holder of IP address
prefix(es) to issue a signed object, called a Route Origination prefix(es) to issue a signed object, called a Route Origination
Authorization (ROA), that authorizes a given AS to originate routes Authorization (ROA), that authorizes a given AS to originate routes
to a given set of prefixes (see [6]). Note that validation of a to a given set of prefixes (see [6]). Note that validation of a
BGPSEC update message will fail (i.e., the validation algorithm, BGPSEC update message will fail (i.e., the validation algorithm,
specified in Section 5.1, returns 'Not Good') unless there exists a specified in Section 5.1, returns 'Not Good') unless there exists a
valid ROA authorizing the first AS in the AS PATH attribute to valid ROA authorizing the first AS in the AS PATH attribute to
originate routes to the prefix being advertised. Therefore, a BGPSEC originate routes to the prefix being advertised. Therefore, a BGPSEC
speaker SHOULD NOT originate a BGPSEC update advertising a route for speaker SHOULD NOT originate a BGPSEC update advertising a route for
a given prefix unless there exists a valid ROA authorizing the BGPSEC a given prefix unless a ROA has previously been created (and
published in the repository system) that authorizing the BGPSEC
speaker's AS to originate routes to this prefix. speaker's AS to originate routes to this prefix.
The Expire Time field is set to specify a time at which the route EDITOR'S NOTE: In a previous version of this document there was a
advertisement specified in the update message will cease to be valid. description here of a mechanism that used that used periodic
Once the Expire Time has been reached, all BGPSEC speakers who have repetition of update messages (aka "beaconing") to protect against
received the advertisement will treat it as invalid. The purpose of replay of old (stale) digital signatures or failure to propagate a
this field is to protect the BGPSEC speaker against attacks in which withdrawal message. This mechanism was removed from the current
a malicious BGPSEC peer either replays a stale update message, or version of the document. Please see the SIDR mailing list for
else fails to propagate the withdrawal for a prefix. discussions related to protection against replay attacks. Depending
on the result of discussions within the SIDR working group a
mechanism for protection against replay of digital signatures may be
re-introduced into BGPSEC in the future.
It is therefore necessary for the originating BGPSEC speaker to issue When originating a new route advertisement, the
a new BGPSEC update, for the given prefix, prior to reaching the BGPSEC_Path_Signatures attribute MUST contain a single Signature-
Expire Time. Setting appropriate values for Expire Time and for the Segment. The following describes how the BGPSEC speaker populates
rate at which new updates are sent out for a given prefix is an the fields of the Signature-Segment (see Section 3 for more
operational choice that involves trade offs between the window of information on the syntax of the Signature-Segment).
replay protection versus network and processing load. Therefore,
these settings are discussed in more detail in BGPSEC Operational
Considerations document [9].
When originating a new route advertisement, each Signature-List Block The AS field is set to the AS number of the BGPSEC speaker. That is,
MUST consist of a single Signature-Segment. The following describes the AS number that the BGPSEC speaker advertised in the Open message
how the BGPSEC speaker populates the fields of the Signature-List of the current BGP session.
Block (see Section 3 for more information on the syntax of Signature-
List Blocks).
The pCount field is typically set to the value 1. However, a BGPSEC The pCount field is typically set to the value 1. However, a BGPSEC
speaker may set the pCount field to a value greater than 1. Setting speaker may set the pCount field to a value greater than 1. Setting
the pCount field to a value greater than one has the same semantics the pCount field to a value greater than one has the same semantics
as repeating an AS number multiple times in the AS-PATH of a non- as repeating an AS number multiple times in the AS_PATH of a non-
BGPSEC update message (e.g., for traffic engineering purposes). BGPSEC update message (e.g., for traffic engineering purposes).
However, even when the pCount field is set to a value greater than 1, Setting the pCount field to a value greater than one permits this
the BGPSEC speaker still only places a single copy of its AS number repetition without requiring a separate digital signature for each
in the AS-PATH attribute. This is because the BGPSEC validation repetition.
algorithm (see Section 5) requires a one-to-one correspondence
between signatures and AS numbers in the AS-PATH. That is, setting a
pCount value greater than 1 achieves the same semantics as
repetition, but requires the generation of only a single signatures.
Whereas a BGPSEC update message with actual repetition in the AS-PATH
attribute would fail validation unless the BGPSEC speaker generated
multiple signatures (one for each copy of the AS number placed in the
AS-PATH).
The Subject Key Identifier field (see Section 3) is populated with The Subject Key Identifier 1 field (see Section 3) 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 end-entity certificate used by the BGPSEC speaker. This the RPKI end-entity certificate (containing keys suitable for use
Subject Key Identifier will be used by recipients of the route with Algorithm Suite 1) used by the BGPSEC speaker. This Subject Key
advertisement to identify the proper certificate to use in verifying Identifier will be used by recipients of the route advertisement to
the signature. identify the proper certificate to use in verifying the signature.
The Subject Key Identifier Length field is populated with the length The Subject Key Identifier 1 Length field is populated with the
(in octets) of the Subject Key Identifier. length (in octets) of the Subject Key Identifier 1 field.
The Signature field contains a digital signature that binds the NLRI, The Signature 1 field contains a digital signature that binds the
AS_Path attribute and BGPSEC_Path_Signatures attribute to the RPKI NLRI, AS_Path attribute and BGPSEC_Path_Signatures attribute to the
end-entity certificate used by the BGPSEC speaker. The digital RPKI end-entity certificate used by the BGPSEC speaker. The digital
signature is computed as follows: signature is computed as follows:
o Construct a sequence of octets by concatenating the Expire Time, o Construct a sequence of octets by concatenating the Target AS
Target AS Number, Origin AS Number, Algorithm Suite Identifier, Number, AS Number (from the Signature_Segment), pCount, Algorithm
pCount and NLRI. The Target AS Number is the AS to whom the Suite Identifier 1, Reserved field of the BGPSEC_Path_Signatures
attribute and NLRI. The Target AS Number is the AS to whom the
BGPSEC speaker intends to send the update message. (Note that the BGPSEC speaker intends to send the update message. (Note that the
Target AS number is the AS number announced by the peer in the Target AS number is the AS number announced by the peer in the
OPEN message of the BGP session within which the update is sent.) OPEN message of the BGP session within which the update is sent.)
The Origin AS number prepend to this sequence the Target AS (the
AS to whom the BGPSEC speaker intends to send the update message)
and the Origin AS Number refers to the AS of the BGPSEC speaker
who is originating the route advertisement.
Sequence of Octets to be Signed Sequence of Octets to be Signed
+---------------------------------------+ +----------------------------------------+
| Expire Time (8 octets) | | Target AS Number (4 octets) |
+---------------------------------------+ +----------------------------------------+
| Target AS Number (4 octets) | | AS Number (4 octets) |
+---------------------------------------+ +----------------------------------------+
| Origin AS Number (4 octets) | | pCount (1 octet) |
+---------------------------------------+ +----------------------------------------+
| Algorithm Suite Identifier (1 octet) | | Algorithm Suite Identifier 1 (1 octet) |
+---------------------------------------+ +----------------------------------------+
| pCount (1 octet) | | Expire Time (8 octets) |
+---------------------------------------+ +----------------------------------------+
| NLRI Length (1 octet) | | NLRI Length (1 octet) |
+---------------------------------------+ +----------------------------------------+
| NLRI Prefix (variable) | | NLRI Prefix (variable) |
+---------------------------------------+ +----------------------------------------+
o Apply to this octet sequence the digest algorithm (for the o Apply to this octet sequence the digest algorithm (for Algorithm
algorithm suite of this Signature-List) to obtain a digest value. Suite 1) to obtain a digest value.
o Apply to this digest value the signature algorithm, (for the o Apply to this digest value the signature algorithm, (for Algorithm
algorithm suite of this Signature-List) to obtain the digital Suite 1) to obtain the digital signature. Then populate the
signature. Then populate the Signature Field with this digital Signature 1 field with this digital signature.
signature.
The Signature 1 Length field is populated with the length (in octets)
of the Signature 1 field.
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_Signatures algorithm (with one or more signatures) from a BGPSEC_Path_Signatures algorithm (with one or more signatures) from a
(internal or external) peer, it may choose to propagate the route (internal or external) peer, it may choose to propagate the route
advertisement by sending to its (internal or external) peers by advertisement by sending to its (internal or external) peers by
creating a new BGPSEC advertisement for the same prefix. creating a new BGPSEC advertisement for the same prefix.
A BGPSEC speaker MUST NOT generate an update message containing the A BGPSEC speaker MUST NOT generate an update message containing the
skipping to change at page 12, line 13 skipping to change at page 13, line 40
attribute. However, a BGPSEC speaker MAY propagate a route attribute. However, a BGPSEC speaker MAY propagate a route
advertisement by generating a (non-BGPSEC) update message that does advertisement by generating a (non-BGPSEC) update message that does
not contain the BGPSEC_Path_Signatures attribute. Note that if a not contain the BGPSEC_Path_Signatures attribute. Note that if a
BGPSEC speaker receives a route advertisement containing the BGPSEC speaker receives a route advertisement containing the
BGPSEC_Path_Signatures attribute and chooses for any reason (e.g., BGPSEC_Path_Signatures attribute and chooses for any reason (e.g.,
its peer is a non-BGPSEC speaker) to propagate the route its peer is a non-BGPSEC speaker) to propagate the route
advertisement as a non-BGPSEC update message without the advertisement as a non-BGPSEC update message without the
BGPSEC_Path_Signatures attribute, then it MUST follow the BGPSEC_Path_Signatures attribute, then it MUST follow the
instructions in Section 4.2.1. instructions in Section 4.2.1.
The Subject Key Identifier 1 field (see Section 3) is populated with
the identifier contained in the Subject Key Identifier extension of
the RPKI end-entity certificate (containing keys suitable for use
with Algorithm Suite 1) used by the BGPSEC speaker. This Subject Key
Identifier will be used by recipients of the route advertisement to
identify the proper certificate to use in verifying the signature.
The Subject Key Identifier 1 Length field is populated with the
length (in octets) of the Subject Key Identifier 1 field.
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_Signatures attribute) has advertisement without the BGPSEC_Path_Signatures attribute) has
significant security ramifications. (See Section 7 for discussion of significant security ramifications. (See Section 7 for discussion of
the security ramifications of removing BGPSEC signatures.) the security ramifications of removing BGPSEC signatures.)
Therefore, when a route advertisement is received via a BGPSEC update Therefore, when a route advertisement is received via a BGPSEC update
message, propagating the route advertisement without the message, propagating the route advertisement without the
BGPSEC_Path_Signatures attribute is NOT RECOMMENDED. Furthermore, BGPSEC_Path_Signatures attribute is NOT RECOMMENDED. Furthermore,
note that when a BGPSEC speaker propagates a route advertisement with note that when a BGPSEC speaker propagates a route advertisement with
the BGPSEC_Path_Signatures attribute it is attesting to the fact the BGPSEC_Path_Signatures attribute it is attesting to the fact
that: (1) it received a BGPSEC update message that advertised this that: (1) it received a BGPSEC update message that advertised this
skipping to change at page 12, line 35 skipping to change at page 14, line 23
validation state of the update message it received. (See Section 7 validation state of the update message it received. (See Section 7
for more discussion of the security semantics of BGPSEC signatures.) for more discussion of the security semantics of BGPSEC signatures.)
If the BGPSEC speaker is producing an update message which contains If the BGPSEC speaker is producing an update message which contains
an AS-SET (e.g., the BGPSEC speaker is performing proxy aggregation), an AS-SET (e.g., the BGPSEC speaker is performing proxy aggregation),
then the BGPSEC speaker MUST NOT include the BGPSEC_Path_Signatures then the BGPSEC speaker MUST NOT include the BGPSEC_Path_Signatures
attribute. In such a case, the BGPSEC speaker must remove any attribute. In such a case, the BGPSEC speaker must remove any
existing BGPSEC_Path_Signatures in the received advertisement(s) for existing BGPSEC_Path_Signatures in the received advertisement(s) for
this prefix and produce a standard (non-BGPSEC) update message. this prefix and produce a standard (non-BGPSEC) update message.
To generate the BGPSEC_Path_Signatures attribute on the outgoing If the received BGPSEC update message uses two algorithm suites
update message, the BGPSEC first copies the Expire Time directly from (i.e., the Two_Algorithms flag is set to 1) and the BGPSEC speaker
the received update message to the new update message (that it is supports both of the corresponding algorithms suites, then the BGPSEC
constructing). Note that the BGPSEC speaker MUST NOT change the speaker SHOULD generate a new update message that uses both algorithm
Expire Time as any change to Expire Time will cause the new BGPSEC suites (i.e., set the Two_Algorithms flag to 1). If the received
update message to fail validation (see Section 5). BGPSEC update message that uses two algorithm suites and the BGPSEC
speaker does not support the second algorithm suite, then the BGPSEC
speaker MUST set the Two_Algorithms flag to 1 and remove the
Signature 2 and Subject Key Identifier 2 fields from each Signature-
Segment in the BGPSEC_Path_Signatures attribute (and set the
corresponding lengths to zero). Note that this case can happen
during an algorithm transition when the BGPSEC speaker has not yet
been updated to support the new algorithm, see Section 6 for more
details. If the BGPSEC speaker does not support the first algorithm
suite in a BGPSEC update message, then the BGPSEC speaker MUST NOT
propagate the route advertisement with the BGPSEC_Path_Signatures
attribute. (Note that if this case occurs, something has gone wrong,
as algorithm transitions are designed to never produce this case.)
If the received BGPSEC update message contains two Signature-List The Reserved field from the BGPSEC_Path_Signatures attribute is
Blocks and the BGPSEC speaker supports both of the corresponding copied directly from the Reserved field in the received update
algorithms suites, then the BGPSEC speaker SHOULD generate a new message.
update message that includes both of the Signature-List Blocks. If
the received BGPSEC update message contains two Signature-List Blocks
and the BGPSEC speaker only supports one of the two corresponding
algorithm suites, then the BGPSEC speaker MUST remove the Signature-
List Block corresponding to the algorithm suite that it does not
understand. If the BGPSEC speaker does not support the algorithm
suites in any of the Signature-List Blocks contained in the received
update message, then the BGPSEC speaker MUST NOT propagate the route
advertisement with the BGPSEC_Path_Signatures attribute. (See
Section 4.2.1 for information on removing the BGPSEC_Path_Signatures
attribute when propagating route advertisements.)
Note that in the case where there are two Signature-List Blocks The BGPSEC speaker then creates a new Signature-Segment. This
(corresponding to different algorithm suites) that the validation Signature-Segment is prepended to the list of Signature-Segments
algorithm (see Section 5.1) deems a BGPSEC update message to be (placed in the first position) so that the list of Signature-Segments
'Good' if there is at least one supported algorithm suite (and appears in the same order as the corresponding AS numbers in the
corresponding Signature-List Block) that is deemed 'Good'. This AS_PATH attribute. The BGPSEC speaker populates the fields of this
means that a 'Good' BGPSEC update message may contain a Signature- new Signature-Segment as follows.
List Block which is deemed 'Not Good' (e.g., contains signatures that
the BGPSEC is unable to verify). Nonetheless, such Signature-List
Blocks MUST NOT be removed. (See Section 7 for a discussion of the
security ramifications of this design choice.)
For each Signature-List Block corresponding to an algorithm suite The AS field is set to the AS number of the BGPSEC speaker. That is,
that the BGPSEC speaker does support, the BGPSEC speaker then adds a the AS number that the BGPSEC speaker advertised in the Open message
new Signature-Segment to the Signature-List Block. This Signature- of the current BGP session.
Segment is prepended to the list of Signature-Segments (placed in the
first position) so that the list of Signature-Segments appears in the
same order as the corresponding AS numbers in the AS-Path attribute.
The BGPSEC speaker populates the fields of this new signature-segment
as follows.
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
the pCount field to a value greater than 1. (See Section 4.1 for a the pCount field to a value greater than 1. (See Section 4.1 for a
discussion of setting pCount to a value greater than 1.) A route discussion of setting pCount to a value greater than 1.) A route
server that participates in the BGP control path, but does not act as server that participates in the BGP control path, but does not act as
a transit AS in the data plane, may choose to set pCount to 0. This a transit AS in the data plane, may choose to set pCount to 0. This
option enables the route server to participate in BGPSEC and obtain option enables the route server to participate in BGPSEC and obtain
the associated security guarantees without increasing the effective the associated security guarantees without increasing the effective
length of the AS-PATH. (Note that BGPSEC speakers compute the length of the AS_PATH. (Note that the Signature_Segmenet still
effective length of the AS-PATH by summing the pCount values in the contains the AS Number of the route server as this information is
BGPSEC_Path_Signatures attribute, see Section 5.) However, when a necessary for signature verification.) Note that the option of
route server sets the pCount value to 0, it still inserts its AS
number into the AS-PATH, as this information is needed to validate
the signature added by the route server. Note that the option of
setting pCount to 0 is intended only for use by route servers that setting pCount to 0 is intended only for use by route servers that
desire not to increase the effective AS-PATH length of routes they desire not to increase the effective AS-PATH length of routes they
advertise. The pCount field SHOULD NOT be set to 0 in other advertise. The pCount field SHOULD NOT be set to 0 in other
circumstances. BGPSEC speakers SHOULD drop incoming update messages circumstances. BGPSEC speakers SHOULD drop incoming update messages
with pCount set to zero in cases where the BGPSEC speaker does not with pCount set to zero in cases where the BGPSEC speaker does not
expect its peer to set pCount to zero (i.e., cases where the peer is expect its peer to set pCount to zero (i.e., cases where the peer is
not acting as a route server). not acting as a route server).
The Subject Key Identifier field in the new segment is populated with The Subject Key Identifier 1 field (see Section 3) 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 end-entity certificate used by the BGPSEC speaker. This the RPKI end-entity certificate (containing keys suitable for use
Subject Key Identifier will be used by recipients of the route with Algorithm Suite 1) used by the BGPSEC speaker. This Subject Key
advertisement to identify the proper certificate to use in verifying Identifier will be used by recipients of the route advertisement to
the signature. identify the proper certificate to use in verifying the signature.
The Subject Key Identifier Length field is populated with the length The Subject Key Identifier 1 Length field is populated with the
(in octets) of the Subject Key Identifier. length (in octets) of the Subject Key Identifier 1 field.
The Signature field in the new segment contains a digital signature The Signature 1 field in the new segment contains a digital signature
that binds the NLRI, AS_Path attribute and BGPSEC_Path_Signatures that binds the NLRI, AS_Path attribute and BGPSEC_Path_Signatures
attribute to the RPKI end-entity certificate used by the BGPSEC attribute to the RPKI end-entity certificate used by the BGPSEC
speaker. The digital signature is computed as follows: speaker. The digital signature is computed as follows:
o Construct a sequence of octets by concatenating the signature o Construct a sequence of octets by concatenating the Signature 1
field of the most recent Signature-Segment (the one corresponding Length and Signature 1 fields of the most recent Signature-Segment
to AS from whom the BGPSEC speaker's AS received the announcement) (the one corresponding to AS from whom the BGPSEC speaker's AS
with the pCount field inserted by the signer, and the Target AS received the announcement) with the pCount field inserted by the
(the AS to whom the BGPSEC speaker intends to send the update signer, and the Target AS (the AS to whom the BGPSEC speaker
message). Note that the Target AS number is the AS number intends to send the update message). Note that the Target AS
announced by the peer in the OPEN message of the BGP session number is the AS number announced by the peer in the OPEN message
within which the BGPSEC update message is sent. of the BGP session within which the BGPSEC update message is sent.
Sequence of Octets to be Signed Sequence of Octets to be Signed
+-----------------------------------------------------------+ +-------------------------------------------------------------+
| Most Recent Signature Field (fixed by algorithm suite) | | Most Recent Signature 1 Length Field (1 octet) |
+-----------------------------------------------------------+ +-------------------------------------------------------------+
| pCount Field of Signer (1 octet) | | Most Recent Signature 1 Field (variable) |
+-----------------------------------------------------------+ +-------------------------------------------------------------+
| Target AS Number (4 octets) | | pCount Field of Signer (1 octet) |
+-----------------------------------------------------------+ +-------------------------------------------------------------+
| Target AS Number (4 octets) |
+-------------------------------------------------------------+
o Apply to this octet sequence the digest algorithm (for the o Apply to this octet sequence the digest algorithm (for the
algorithm suite of this Signature-List) to obtain a digest value. algorithm suite of this Signature-List) to obtain a digest value.
o Apply to this digest value the signature algorithm, (for the o Apply to this digest value the signature algorithm, (for the
algorithm suite of this Signature-List) to obtain the digital algorithm suite of this Signature-List) to obtain the digital
signature. Then populate the Signature Field with this digital signature. Then populate the Signature Field with this digital
signature. signature.
4.2.1. Propogating an Update without the Path_Signatures attribute The Subject Key Identifier 1 Length field is populated with the
length (in octets) of the Subject Key Identifier 1 field.
As discussed earlier in Section 4.2, a BGPSEC speaker may receive a
BGPSEC update message that contains the BGPSEC_Path_Signatures
Attribute and propagate the associated route in a non-BGPSEC update
message that does not contain the BGPSEC_Path_Signatures attribute.
A BGPSEC speaker MUST remove the BGPSEC_Path_Signatures attribute
when propagating a route advertisement to a peer that has not
advertised support BGPSEC (see Section 2), when propagating a route
advertisement that contains an AS-SET in the AS-PATH, or when the
BGPSEC speaker does not support any algorithm suite used to generate
signatures in the received update message. In all other cases, the
BGPSEC speaker SHOULD NOT remove the BGPSEC_Path_Signatures
attribute.
When the BGPSEC speaker receives a BGPSEC update message that
contains the BGPSEC_Path_Signatures Attribute and propagates the
associated route in a non-BGPSEC update message, the BGPSEC MUST
perform a transformation on the AS-PATH in the non-BGPSEC update
message that it generates. The reason for this is that the AS-PATH
attribute has slightly different semantics in a BGPSEC update message
than it has in a non-BGPSEC update message.
To generate the AS-PATH in the outgoing non-BGPSEC update message,
the BGPSEC speaker performs the following steps for each AS number in
the AS-PATH of the received BGPSEC update message. (Note that there
is a one-to-one correspondence between the AS numbers in the AS-PATH
of a BGPSEC update message and the Signature Segments in the
Signature-List Block of the BGPSEC_Path_Signatures attribute. The
follows step will make use of this correspondence.)
o For each AS number in the AS-PATH of the received BGPSEC update
message, locate the pCount value in the corresponding Signature
Segment.
o If the pCount value is equal to 0, then do not include the
corresponding AS in the AS-PATH of the outgoing non-BGPSEC update
message.
o If the pCount value is greater than or equal to 1, insert into the
AS-PATH of the outgoing update message a number of copies of the
corresponding AS number equal to the pCount value.
Other than the above transformation that is applied to the AS-PATH,
no additional special behavior is required when removing BGPSEC
signatures from BGPSEC update messages. That is, all other
attributes in the outgoing non-BGPSEC update message are generated as
they would normally be generated by the BGP speaker in a non-BGPSEC
update message.
5. Processing a Received BGPSEC Update 5. Processing a Received BGPSEC Update
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 particular, to validate update messages containing the
BGPSEC_Path_Signatures attribute, it is necessary that the recipient BGPSEC_Path_Signatures attribute, it is necessary that the recipient
have access to the following data obtained from valid RPKI have access to the following data obtained from valid RPKI
certificates and ROAs: certificates and ROAs:
skipping to change at page 16, line 20 skipping to change at page 16, line 48
extension, the AS Number, Public Key and Subject Key Identifier extension, the AS Number, Public Key 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. (The latter validation on behalf of (some set of) BGPSEC speakers. (The latter
case in analogous to the use of the RPKI-RTR protocol [10] for origin case in analogous to the use of the RPKI-RTR protocol [12] for origin
validation.) validation.)
To validate a BGPSEC update message containing the To validate a BGPSEC update message containing the
BGPSEC_Path_Signatures attribute, the recipient performs the BGPSEC_Path_Signatures attribute, the recipient performs the
validation steps specified in Section 5.1. The validation procedure validation steps specified in Section 5.1. The validation procedure
results in one of two states: 'Good' and 'Not Good'. results in one of two states: 'Good' and 'Not Good'.
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
skipping to change at page 17, line 6 skipping to change at page 17, line 34
policy in the AS determines the specific means for conveying the policy in the AS determines the specific means for conveying the
validation status through various pre-existing mechanisms (e.g., validation status through various pre-existing mechanisms (e.g.,
modifying an attribute). As discussed in Section 4, when a BGPSEC modifying an attribute). As discussed in Section 4, when a BGPSEC
speaker chooses to forward a (syntactically correct) BGPSEC update speaker chooses to forward a (syntactically correct) BGPSEC update
message, it SHOULD be forwarded with its BGPSEC_Path_Signatures message, it SHOULD be forwarded with its BGPSEC_Path_Signatures
attribute intact (regardless of the validation state of the update attribute intact (regardless of the validation state of the update
message). Based entirely on local policy settings, an egress router message). Based entirely on local policy settings, an egress router
MAY trust the validation status conveyed by an ingress router or it MAY trust the validation status conveyed by an ingress router or it
MAY perform its own validation. MAY perform its own validation.
Upon receiving a BGPSEC update message, a BGPSEC speaker SHOULD sum EDITOR'S NOTE: Text will be inserted here for dealing with the
the pCount values within BGPSEC_Path_Signatures attribute to AS_PATH attribute. Note that the BGPGSEC_Path_Signatures attribute
determine the effective length of the AS Path. The BGPSEC speaker now contains all of the information needed to construct the AS_PATH
SHOULD use this sum of pCount values in precisely the same way as it attribute. Therefore, there seem to be two options. One option the
uses the length of the AS Path in non-BGPSEC update messages. BGPSEC speaker checks the AS_PATH attribute against the information
in the BGPSEC_Path_Signatures attribute and returns "Not Good" if the
two do not match. The other option is that the BGPSEC speaker
discards anything in the AS_PATH attribute and reconstructs the
AS_PATH from the data in the BGPSEC_Path_Signatures attribute. I
believe that there are no interoperability problems if the choice
between these two options is left up to the BGPSEC speaker.
5.1. Validation Algorithm 5.1. Validation Algorithm
This section specifies an algorithm for validation of BGPSEC update This section specifies an algorithm for validation of BGPSEC update
messages. A conformant implementation MUST include an BGPSEC update messages. A conformant implementation MUST include an BGPSEC update
validation algorithm that is functionally equivalent to the external validation algorithm that is functionally equivalent to the external
behavior of this algorithm. behavior of this algorithm.
First, the recipient of a BGPSEC update message performs a check to First, the recipient of a BGPSEC update message performs a check to
ensure that the message is properly formed. Specifically, the ensure that the message is properly formed. Specifically, the
recipient performs the following checks: recipient checks that the BGPSEC_Path_Signatures attribute is
properly formed (as specified in Section 3). If the
o Check to ensure that the entire BGPSEC_Path_Signatures attribute BGPSEC_Path_Signatures attribute is not properly formed, then the
is syntactically correct (conforms to the specification in this recipient should log that an error occurred and drop the update
document). message containing the error.
o Check to ensure that the AS-Path attribute contains no AS-Set
segments.
o Check that each Signature-List Block contains one Signature-
Segment for each AS in the AS-Path attribute. (Note that the
entirety of each Signature-List Block must be checked to ensure
that it is well formed, even though the validation process may
terminate before all signatures are cryptographically verified.)
If there are two Signature-List Blocks within the
BGPSEC_Path_Signatures attribute and one of them is poorly formed (or
contains the wrong number of Signature-Segments) , then the recipient
should log that an error occurred, strip off that particular
Signature-List Block and process the update message as though it
arrived with a single Signature-List Block. If the
BGPSEC_Path_Signatures attribute contains a syntax error that is not
local to one of two Signature-List Blocks, then the recipient should
log that an error occurred and drop the update message containing the
error. Similarly, if an update message contains both the
BGPSEC_Path_Signatures attribute and an AS-Path attribute that
contains an AS-Set segment, then the recipient should log that an
error occurred and drop the update message containing the error.
Second, the BGPSEC speaker verifies that the update message has not
yet expired. To do this, locate the Expire Time field in the
BGPSEC_Path_Signatures attribute, and compare it with the current
time. If the current time is later than the Expire Time, the BGPSEC
update is 'Not Good' and the validation algorithm terminates.
Third, the BGPSEC speaker verifies that the origin AS is authorized Second, the BGPSEC speaker verifies that the origin AS is authorized
to advertise the prefix in question. To do this, consult the valid to 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 ROA 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 AS-Path. If the origin AS in (least recently added) AS number in the AS-Path. If the origin AS in
the AS-Path is not in the set of AS numbers associated with the given the AS-Path is not in the set of AS numbers associated with the given
prefix, then BGPSEC update message is 'Not Good' and the validation prefix, then BGPSEC update message is 'Not Good' and the validation
algorithm terminates. algorithm terminates.
Finally, the BGPSEC speaker examines the Signature-List Blocks in the Third, the BGPSEC speaker examines the Algorithm Suite identifiers
BGPSEC_Path_Signatures attribute. Any Signature-List Block and the Two-Algorithms flag in the BGPSEC_Path_Signatures attribute.
corresponding to an algorithm suite that the BGPSEC speaker does not If the BGPSEC speaker does not support the first Algorithm Suite,
support is not considered in validation. If there does not exist a then the BGPSEC speaker MUST treat the update message in the same
Signature-List Block corresponding to an algorithm suite that the manner that the BGPSEC speaker would treat an update message that
BGPSEC speaker supports, then the BGPSEC speaker MUST treat the arrived without a BGPSEC_Path_Signatures attribute. (Note that
update message in the same manner that the BGPSEC speaker would treat algorithm transitions are designed so that this case will never
an update message that arrived without a BGPSEC_Path_Signatures happen, therefore if this case occurs the BGPSEC speaker SHOULD log
attribute. an error message.) If the Two-Algorithms flag is set to 1 and the
BGPSEC speaker supports only the first algorithm suite then it
For each remaining Signature-List Block (corresponding to an follows the instructions below to validate the signatures using the
algorithm suite supported by the BGPSEC speaker), the BGPSEC speaker first algorithm suite, and ignore Signature 2 in each Signature-
iterates through the Signature-Segments in the Signature-List block, Segment. If the Two-Algorithms flag is set to 1 and the BGPSEC
starting with the most recently added segment (and concluding with speaker supports both algorithm suites, then the BGPSEC speaker
the least recently added segment). Note that there is a one-to-one follows the instructions below to validate the signatures using the
correspondence between Signature-Segments and AS numbers in the AS- first algorithm suite. The BGPSEC speaker MAY then analogously
Path attribute, and the following steps make use of this validate the second set of signatures using Algorithm Suite 2. If
correspondence. the BGPSEC speaker chooses to validate both sets of signatures, it
returns "Good" if either the first or the second set of signatures
successfully validate.
o (Step I): Locate the public key needed to verify the signature (in o (Step I): Locate the public key needed to verify the signature (in
the current Signature-Segment). To do this, consult the valid the current Signature-Segment). To do this, consult the valid
RPKI end-entity certificate data and look for an SKI that matches RPKI end-entity certificate data and look for an SKI that matches
the value in the SKI field of the Signature-Segment. If no such the value in the Subject Key Identifier 1 field of the Signature-
SKI value is found in the valid RPKI data then mark the entire Segment. If no such SKI value is found in the valid RPKI data
Signature-List Block as 'Not Good' and proceed to the next then validation fails and returns "Not Good". Similarly, if the
Signature-List Block. Similarly, if the SKI exists but the AS SKI exists but the AS Number associated with the SKI does NOT
Number associated with the SKI does NOT match the AS Number (in match the AS Number in the Signature-Segment, then validation
the AS-Path attribute) which corresponds to the current Signature- fails and returns "Not Good".
Segment, then mark the entire Signature-List Block as 'Not Good'
and proceed to the next Signature-List Block.
o (Step II): Compute the digest function (for the given algorithm o (Step II): Compute the digest function (for Algorithm Suite 1) on
suite) on the appropriate data. If the segment is not the (least the appropriate data. If the segment is not the (least recently
recently added) segment corresponding to the origin AS, then the added) segment corresponding to the origin AS, then the digest
digest function should be computed on the following sequence of function should be computed on the following sequence of octets:
octets:
Sequence of Octets to be Hashed Sequence of Octets to be Hashed
+-------------------------------------------------+ +----------------------------------------------------------+
| Signature Field in the Next Segment (variable) | | Signature 1 Length Field in the Next Segment (1 octet) |
+-------------------------------------------------+ +----------------------------------------------------------+
| pCount Field in the Current Segment (1 octet) | | Signature 1 Field in the Next Segment (variable) |
+-------------------------------------------------+ +----------------------------------------------------------+
| AS Number of Subsequent AS (4 octets) | | pCount Field in the Current Segment (1 octet) |
+-------------------------------------------------+ +----------------------------------------------------------+
| AS Number of Previous AS (4 octets) |
+----------------------------------------------------------+
The 'Signature Field in the Next Segment' is the Signature field The 'Signature 1 Field in the Next Segment' and 'Signature 1 Length
found in the Signature-Segment that is next to be processed (that is, Field in Next Segment' are the Signature 1 field and Signature 1
the next most recently added Signature- Segment). The 'pCount Field Length fields found in the Signature-Segment that is next to be
in the Current Segment' is the pCount field found in the Signature- processed (that is, the next most recently added Signature- Segment).
Segment that is currently being processed. The 'pCount Field in the Current Segment' is the pCount field found
in the Signature-Segment that is currently being processed.
For the first segment to be processed (the most recently added For the first segment to be processed (the most recently added
segment), the 'AS Number of Subsequent AS' is the AS number of the segment), the 'AS Number of Subsequent AS' is the AS number of the
BGPSEC speaker validating the update message. Note that if a BGPSEC BGPSEC speaker validating the update message. Note that if a BGPSEC
speaker uses multiple AS Numbers (e.g., the BGPSEC speaker is a speaker uses multiple AS Numbers (e.g., the BGPSEC speaker is a
member of a confederation), the AS number used here MUST be the AS member of a confederation), the AS number used here MUST be the AS
number announced in the OPEN message for the BGP session over which number announced in the OPEN message for the BGP session over which
the BGPSEC update was received. the BGPSEC update was received.
For each other Signature-Segment, the 'AS Number of Subsequent AS' is For each other Signature-Segment, the 'AS Number of Previous AS' is
the AS that corresponds to the Signature-Segment added immediately the AS number in the Signature-Segment that was most recently
after the one being processed. (That is, find the AS number processed.
corresponding to the Signature-Segment currently being processed and
the 'AS Number of Subsequent AS' is the next AS number that was added
to the AS-Path attribute.)
Alternatively, if the segment being processed corresponds to the Alternatively, if the segment being processed corresponds to the
origin AS, then the digest function should be computed on the origin AS, then the digest function should be computed on the
following sequence of octets: following sequence of octets:
Sequence of Octets to be Hashed Sequence of Octets to be Hashed
-------------------------------------------+
+----------------------------------------+ | AS Number of Previous AS (4 octets) |
| Expire Time (8 octets) | +------------------------------------------+
-----------------------------------------+ | Origin AS Number (4 octets) |
| AS Number of Subsequent AS (4 octets) | +------------------------------------------+
+----------------------------------------+ | Algorithm Suite 1 Identifier (1 octet) |
| Origin AS Number (4 octets) | +------------------------------------------+
+----------------------------------------+ | pCount (1 octet) |
| Algorithm Suite Identifier (1 octet) | +------------------------------------------+
+----------------------------------------+ | NLRI Length (1 octet) |
| pCount (1 octet) | +------------------------------------------+
+----------------------------------------+ | NLRI Prefix (variable) |
| NLRI Length (1 octet) | +------------------------------------------+
+----------------------------------------+
| NLRI Prefix (variable) |
+----------------------------------------+
The NLRI Length, NLRI Prefix, Expire Time, and Algorithm Suite The NLRI Length, NLRI Prefix, Expire Time, and Algorithm Suite
Identifier are all obtained in a straight forward manner from the Identifier are all obtained in a straight forward manner from the
NLRI of the update message or the BGPSEC_Path_Signatures attribute NLRI of the update message or the BGPSEC_Path_Signatures attribute
being validated. The pCount field is taken from the Signature- being validated. The pCount field is taken from the Signature-
Segment currently being processed. Segment currently being processed.
The Origin AS Number is the same Origin AS Number that was located in The Origin AS Number is the same Origin AS Number that was located in
Step I above. (That is, the AS number corresponding to the least Step I above. (That is, the AS number in the least recently added
recently added Signature-Segment.) Signature-Segment.)
The 'AS Number of Subsequent AS' is the AS Number added to the AS- The 'AS Number of Previous AS' is the AS Number in the Signature-
Path immediately after the Origin AS Number. (That is, the second AS Segment that was most recently processed (i.e., processed before the
Number that was added to the AS Path.) current segment).
o (Step III): Use the signature validation algorithm (for the given o (Step III): Use the signature validation algorithm (for the given
algorithm suite) to verify the signature in the current segment. algorithm suite) to verify the signature in the current segment.
That is, invoke the signature validation algorithm on the That is, invoke the signature validation algorithm on the
following three inputs: the value of the Signature field in the following three inputs: the value of the Signature field in the
current segment; the digest value computed in Step II above; and current segment; the digest value computed in Step II above; and
the public key obtained from the valid RPKI data in Step I above. the public key obtained from the valid RPKI data in Step I above.
If the signature validation algorithm determines that the If the signature validation algorithm determines that the
signature is invalid, then mark the entire Signature-List Block as signature is invalid, validation has failed and return 'Not Good'.
'Not Good' and proceed to the next Signature-List Block. If the If the signature validation algorithm determines that the
signature validation algorithm determines that the signature is signature is valid, then continue processing Signature-Segments.
valid, then continue processing Signature-Segments (within the
current Signature-List Block).
If all Signature-Segments within a Signature-List Block pass
validation (i.e., all segments are processed and the Signature-List
Block has not yet been marked 'Not Good'), then the Signature-List
Block is marked as 'Good'.
If at least one Signature-List Block is marked as 'Good', then the If all Signature-Segments pass validation (i.e., all segments are
validation algorithm terminates and the BGPSEC update message is processed and the algorithm has not yet returned 'Not Good'), then
deemed to be 'Good'. (That is, if a BGPSEC update message contains validation succeeds and returns 'Good'.
two Signature-List Blocks then the update message is deemed 'Good' if
the first Signature-List block is marked 'Good' OR the second
Signature-List block is marked 'Good'.)
6. Algorithms and Extensibility 6. Algorithms and Extensibility
6.1. Algorithm Suite Considerations 6.1. Algorithm Suite Considerations
Note that there is currently no support for bilateral negotiation Note that there is currently no support for bilateral negotiation
between BGPSEC peers to use of a particular (digest and signature) between BGPSEC peers to use of a particular (digest and signature)
algorithm suite using BGP capabilities. This is because the algorithm suite using BGP capabilities. This is because the
algorithm suite used by the sender of a BGPSEC update message must be algorithm suite used by the sender of a BGPSEC update message must be
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
skipping to change at page 21, line 44 skipping to change at page 21, line 33
algorithm suite to the 'new' algorithm suite. During the period of algorithm suite to the '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_Signatures attribute can contain signatures, in how the BGPSEC_Path_Signatures attribute can contain signatures, in
parallel, for two algorithm suites.) Once the transition is parallel, for two algorithm suites.) Once the transition is
complete, use of the old 'current' algorithm will be deprecated, use complete, use of the old 'current' algorithm will be deprecated, use
of the 'new' algorithm will be mandatory, and a subsequent 'even of the 'new' algorithm will be mandatory, and a subsequent 'even
newer' algorithm suite may be specified as recommend to implement. newer' algorithm suite may be specified as recommend to implement.
Once the transition has successfully been completed in this manner, Once the transition has successfully been completed in this manner,
BGPSEC speakers SHOULD include only a single Signature-List Block BGPSEC speakers SHOULD include only a signatures corresponding to the
(corresponding to the 'new' algorithm). 'new' algorithm.
6.2. Extensibility Considerations 6.2. Extensibility Considerations
This section discusses potential changes to BGPSEC that would require This section discusses potential changes to BGPSEC that would require
substantial changes to the processing of the BGPSEC_Path_Signatures substantial changes to the processing of the BGPSEC_Path_Signatures
and thus necessitate a new version of BGPSEC. Examples of such and thus necessitate a new version of BGPSEC. Examples of such
changes include: changes include
o A new type of signature algorithm that produces signatures of
variable length
o A new type of signature algorithm for which the number of o A new type of signature algorithm for which the number of
signatures in the Signature-List Block is not equal to the number signatures in the Signature-List Block is not equal to the number
of ASes in the AS-PATH (e.g., aggregate signatures) of ASes in the AS_PATH (e.g., aggregate signatures)
o Changes to the data that is protected by the BGPSEC signatures o Changes to the data that is protected by the BGPSEC signatures
(e.g., protection of attributes other than AS-PATH) (e.g., protection of attributes other than AS_PATH)
In the case that such a change to BGPSEC were deemed desirable, it is In the case that such a change to BGPSEC were deemed desirable, it is
expected that a subsequent version of BGPSEC would be created and expected that a subsequent version of BGPSEC would be created and
that this version of BGPSEC would specify a new BGP Path Attribute, that this version of BGPSEC would specify a new BGP Path Attribute,
let's call it BGPSEC_PATH_SIG_TWO, which is designed to accommodate let's call it BGPSEC_PATH_SIG_TWO, which is designed to accommodate
the desired changes to BGPSEC. In such a case, the mandatory the desired changes to BGPSEC. In such a case, the mandatory
algorithm suites document would be updated to specify algorithm algorithm suites document would be updated to specify algorithm
suites appropriate for the new version of BGPSEC. suites appropriate for the new version of BGPSEC.
At this point a transition would begin which is analogous to the At this point a transition would begin which is analogous to the
skipping to change at page 23, line 34 skipping to change at page 23, line 19
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 'Good' (as Note that there may be cases where a BGPSEC speaker deems 'Good' (as
per the validation algorithm in Section 5.1) a BGPSEC update message per the validation algorithm in Section 5.1) a BGPSEC update message
that contains both a 'Good' and a 'Not Good' Signature-List Block. that contains two sets of signatures, one 'Good' and one 'Not Good'.
That is, the update message contains two sets of signatures That is, the update message contains two sets of signatures
corresponding to two algorithm suites, and one set of signatures corresponding to two algorithm suites, and one set of signatures
verifies correctly and the other set of signatures fails to verify. verifies correctly and the other set of signatures fails to verify.
In this case, the protocol specifies that if the BGPSEC speaker In this case, the protocol specifies that if the BGPSEC speaker
propagates the route advertisement received in such an update message propagates the route advertisement received in such an update message
then the BGPSEC speaker SHOULD add its signature to each of the then the BGPSEC speaker SHOULD add its signature using both the
Signature-List Blocks using both the corresponding algorithm suite. algorithm suites. Thus the BGPSEC speaker creates a signature using
Thus the BGPSEC speaker creates a signature using both algorithm both algorithm suites and creates a new update message that contains
suites and creates a new update message that contains both the 'Good' both the 'Good' and the 'Not Good' set of signatures (from its own
and the 'Not Good' set of signatures (from its own vantage point). 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 'Good' and a set of algorithm B of algorithm A signatures which are 'Good' and a set of algorithm B
signatures which are 'Not Good'. In such a case it is possible signatures which are 'Not Good'. In such a case it is possible
(perhaps even quite likely) that some of the BGPSEC speaker's peers (perhaps even quite likely) that some of the BGPSEC speaker's peers
(or other entities further 'downstream' in the BGP topology) do not (or other entities further 'downstream' in the BGP topology) do not
support algorithm A. Therefore, if the BGPSEC speaker were to remove support algorithm A. Therefore, if the BGPSEC speaker were to remove
the 'Not Good' set of signatures corresponding to algorithm B, such the 'Not Good' set of signatures corresponding to algorithm B, such
entities would treat the message as though it were unsigned. By entities would treat the message as though it were unsigned. By
skipping to change at page 24, line 25 skipping to change at page 24, line 10
the BGPSEC speaker might actually cause a downstream entity to the BGPSEC speaker might actually cause a downstream entity to
'upgrade' the status of a route advertisement from 'Not Good' to 'upgrade' the status of a route advertisement from 'Not Good' to
unsigned. Finally, note that in the above scenario, the BGPSEC unsigned. Finally, note that in the above scenario, the BGPSEC
speaker might have deemed algorithm A signatures 'Good' only because speaker might have deemed algorithm A signatures 'Good' only because
of some issue with RPKI state local to his AS (for example, his AS 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 to might not yet have obtained a CRL indicating that a key used to
verify an algorithm A signature belongs to a newly revoked 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 Good' (due to the downstream entity to treat the update as 'Not Good' (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
Good' Signature-List Blocks were removed). Good' signatures 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 Good' BGPSEC route to a given prefix a route obtained via a 'Not Good' BGPSEC
update message. (That is, a BGPSEC update containing only 'Not Good' update message. (That is, a BGPSEC update containing only 'Not Good'
Signature-List Blocks.) In such a case, the BGPSEC speaker should signatures.) In such a case, the BGPSEC speaker should propagate a
propagate a signed BGPSEC update message, adding his signature to the signed BGPSEC update message, adding his signature to the 'Not Good'
'Not Good' signatures that already exist. Again, this is to ensure signatures that already exist. Again, this is to ensure that
that 'downstream' entities are able to make an informed decision and 'downstream' entities are able to make an informed decision and not
not erroneously treat the route as unsigned. It may also be noted erroneously treat the route as unsigned. It may also be noted here
here that due to possible differences in RPKI data at different that due to possible differences in RPKI data at different vantage
vantage points in the network, a BGPSEC update that was deemed 'Not points in the network, a BGPSEC update that was deemed 'Not Good' at
Good' at an upstream BGPSEC speaker may indeed be deemed 'Good' at an upstream BGPSEC speaker may indeed be deemed 'Good' at another BGP
another BGP speaker downstream. speaker downstream.
Therefore, it is important to note that when a BGPSEC speaker signs Therefore, it is important to note that when a BGPSEC speaker signs
an outgoing update message, it is not attesting to a belief that all an outgoing update message, it is not attesting to a belief that all
signatures prior to its are valid. Instead it is merely asserting signatures prior to its are valid. Instead it is merely asserting
that: that:
1. The BGPSEC speaker received the given route advertisement with 1. The BGPSEC speaker received the given route advertisement with
the indicated NLRI and AS Path; the indicated NLRI and AS Path;
2. The BGPSEC speaker selected this route as the best route to the 2. The BGPSEC speaker selected this route as the best route to the
skipping to change at page 25, line 24 skipping to change at page 25, line 8
Section 5.1 was chosen so as to perform checks which are likely to be Section 5.1 was chosen so as to perform checks which are likely to be
expensive after checks that are likely to be inexpensive. However, expensive after checks that are likely to be inexpensive. However,
the relative cost of performing required validation steps may vary the relative cost of performing required validation steps may vary
between implementations, and thus the algorithm specified in Section between implementations, and thus the algorithm specified in Section
5.1 may not provide the best denial of service protection for all 5.1 may not provide the best denial of service protection for all
implementations. implementations.
Finally, the mechanism of setting the pCount field to zero is Finally, the mechanism of setting the pCount field to zero is
included in this specification to enable route servers in the control included in this specification to enable route servers in the control
path to participate in BGPSEC without increasing the effective length path to participate in BGPSEC without increasing the effective length
of the AS-PATH. However, entities other than route servers could of the 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 in which an upstream entity that
is two or more hops away set pCount to zero is unable to verify for is two or more hops away 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.
8. IANA Considerations 8. Contributors
IANA is requested to create a registry of BGPSEC algorithm suite
identifiers. This registry shall contain four fields, a one octet
Algorithm Suite Identifier, the name of the suite's digest algorithm,
the name of the suite's signature algorithm, and a specification
pointer containing a reference to the formal specification of the
algorithm suite. That is, entries in the registry have the following
form:
Algorithm Suite Digest Signature Specification
Identifier Algorithm Algorithm Pointer
+-----------------+--------------+----------------+---------------+
| | | | |
+-----------------+--------------+----------------+---------------+
The entries in this registry shall be managed by IETF consensus.
9. Contributors
9.1. Authors 8.1. Authors
Rob Austein Rob Austein
Dragon Research Labs Dragon Research Labs
sra@hactrn.net sra@hactrn.net
Steven Bellovin Steven Bellovin
Columbia University Columbia University
smb@cs.columbia.edu smb@cs.columbia.edu
Randy Bush Randy Bush
skipping to change at page 27, line 16 skipping to change at page 26, line 20
dougm@nist.gov dougm@nist.gov
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
Cobham Cobham
weiler+ietf@watson.org weiler+ietf@watson.org
9.2. Acknowledgements 8.2. Acknowledgements
The authors would like to thank Luke Berndt, Sharon Goldberg, Ed The authors would like to thank Luke Berndt, Wes George, 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 9. Normative References
[1] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border [1] 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.
[2] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [2] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[3] Scudder, J. and R. Chandra, "Capabilities Advertisement with [3] Scudder, J. and R. Chandra, "Capabilities Advertisement with
BGP-4", RFC 5492, February 2009. BGP-4", RFC 5492, February 2009.
skipping to change at page 28, line 7 skipping to change at page 27, line 12
[6] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route [6] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations", February 2011. Origin Authorizations", February 2011.
[7] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure [7] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure
Internet Routing", February 2011. Internet Routing", February 2011.
[8] Kent, S., "Threat Model for BGP Path Security", June 2011. [8] Kent, S., "Threat Model for BGP Path Security", June 2011.
[9] Bush, R., "BGPsec Operational Considerations", October 2011. [9] Bush, R., "BGPsec Operational Considerations", October 2011.
[10] Bush, R. and R. Austein, "The RPKI/Router Protocol", [10] Turner, S., "BGP Algorithms, Key Formats, & Signature Formats",
December 2011.
[11] Reynolds, M., Turner, S., and S. Kent, "A Profile for BGPSEC
Router Certificates, Certificate Revocation Lists, and
Certification Requests", December 2011.
[12] Bush, R. and R. Austein, "The RPKI/Router Protocol",
October 2011. October 2011.
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
 End of changes. 95 change blocks. 
474 lines changed or deleted 446 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/