draft-ietf-sidr-bgpsec-protocol-02.txt   draft-ietf-sidr-bgpsec-protocol-03.txt 
Network Working Group M. Lepinski, Ed. Network Working Group M. Lepinski, Ed.
Internet-Draft BBN Internet-Draft BBN
Intended status: Standards Track March 12, 2012 Intended status: Standards Track May 11, 2012
Expires: September 13, 2012 Expires: November 12, 2012
BGPSEC Protocol Specification BGPSEC Protocol Specification
draft-ietf-sidr-bgpsec-protocol-02 draft-ietf-sidr-bgpsec-protocol-03
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 September 13, 2012. This Internet-Draft will expire on November 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
skipping to change at page 2, line 16 skipping to change at page 2, line 16
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 . . . . . . . . . . . . . 6 3. The BGPSEC_Path_Signatures Attribute . . . . . . . . . . . . . 6
4. Generating a BGPSEC Update . . . . . . . . . . . . . . . . . . 9 3.1. Secure_Path . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Originating a New BGPSEC Update . . . . . . . . . . . . . 10 3.2. Additional_Info . . . . . . . . . . . . . . . . . . . . . 9
4.2. Propagating a Route Advertisement . . . . . . . . . . . . 13 3.3. Signature_Block . . . . . . . . . . . . . . . . . . . . . 11
5. Processing a Received BGPSEC Update . . . . . . . . . . . . . 16 4. Generating a BGPSEC Update . . . . . . . . . . . . . . . . . . 12
5.1. Validation Algorithm . . . . . . . . . . . . . . . . . . . 17 4.1. Originating a New BGPSEC Update . . . . . . . . . . . . . 13
6. Algorithms and Extensibility . . . . . . . . . . . . . . . . . 20 4.2. Propagating a Route Advertisement . . . . . . . . . . . . 16
6.1. Algorithm Suite Considerations . . . . . . . . . . . . . . 21 5. Processing a Received BGPSEC Update . . . . . . . . . . . . . 19
6.2. Extensibility Considerations . . . . . . . . . . . . . . . 21 5.1. Validation Algorithm . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 6. Algorithms and Extensibility . . . . . . . . . . . . . . . . . 24
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.1. Algorithm Suite Considerations . . . . . . . . . . . . . . 24
8.1. Authors . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.2. Extensibility Considerations . . . . . . . . . . . . . . . 25
8.2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 26 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
9. Normative References . . . . . . . . . . . . . . . . . . . . . 26 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1. Authors . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 30
9. Normative References . . . . . . . . . . . . . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31
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 6, line 13 skipping to change at page 6, line 13
update messages in its open message. update messages in its open message.
3. The BGPSEC_Path_Signatures Attribute 3. The BGPSEC_Path_Signatures Attribute
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 algorithm carries the secured AS Path
information, including the digital signatures that protect this AS
Path information. We refer to those update messages that contain the
BGPSEC_Path_Signatures attribute as "BGPSEC Update messages". The
BGPSEC_Path_Signatures attribute replaces the AS_PATH attribute.
Update messages that contain the BGPSEC_Path_Signatures attribute
MUST NOT contain the AS_PATH or AS4_PATH attribute.
BGPSEC_Path_Signatures Attribute The BGPSEC_Path_Signatures attribute is made up of several parts.
+---------------------------------------------------------+ The following high-level diagram provides an overview of the
| Flags Octet (1 octet) | structure of the BGPSEC_Path_Signatures attribute
+---------------------------------------------------------+ High-Level Diagram of the BGPSEC_Path_Signatures Attribute
| Algorithm Suite Identifier 1 (1 octet) | BGPSEC_Path_Signatures
+---------------------------------------------------------+
| Algorithm Suite Identifier 2 (1 octet) |
+---------------------------------------------------------+
| Reserved (8 octets) |
+---------------------------------------------------------+ +---------------------------------------------------------+
| Sequence of Signature-Segments (variable) | | +-----------------+ |
| | Secure Path | +-----------------+ |
| +-----------------+ | Additional Info | |
| | AS X | +-----------------+ |
| | pCount X | | Info Type | |
| | Flags X | | Info Length | |
| | AS Y | | Info Value | |
| | pCount Y | +-----------------+ |
| | Flags Y | |
| | ... | |
| +-----------------+ |
| |
| +-----------------+ +-----------------+ |
| | Sig Block 1 | | Sig Block 2 | |
| +-----------------+ +-----------------+ |
| | Alg Suite 1 | | Alg Suite 2 | |
| | SKI X | | SKI X | |
| | Sig Length X | | Sig Length X | |
| | Signature X | | Signature X | |
| | SKI Length Y | | SKI Length Y | |
| | SKI Y | | SKI Y | |
| | Sig Length Y | | Sig Length Y | |
| | Signature Y | | Signature Y | |
| | ... | | .... | |
| +-----------------+ +-----------------+ |
| |
+---------------------------------------------------------+ +---------------------------------------------------------+
The flags octet is an unsigned octet that contains flags to aid in The following is a more detailed explanation of the format of the
receiver processing. BGPSEC_Path_Signatures attribute.
Flags Octet in Path_Signatures Attribute BGPSEC_Path_Signatures Attribute
0 1 2 3 4 5 6 7 +-------------------------------------------------------+
+-------------------------------------------+ | Secure_Path (variable) |
| Two Algorithms | Reserved | +-------------------------------------------------------+
+-------------------------------------------+ | Additional_Info (variable) |
+-------------------------------------------------------+
| Sequence of one or two Signature_Blocks (variable) |
+-------------------------------------------------------+
The first bit in the Flags octet is set to zero in the common case The Secure_Path contains AS Path information for the BGPSEC update
that each Signature-Segment contains a single signature. The first message. This is logically equivalent to the information that would
bit of the Flags octet is set to one in the case that each Signature- be contained in the AS4_PATH attribute. A BGPSEC udpate message
Segment contains two signatures, produced by two different algorithm containing the BGPSEC_PATH_SIGNATURES attribute MUST NOT contain the
suites. (Note that this second case is necessary to support a AS_PATH or AS4_PATH attribute. The format of the Secure_Path is
transition between two algorithm suites, see Section 8.) The described below in Section 3.1.
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.
Algorithm Suite Identifier 1 contains a one-octet identifier The Additional_Info contains additional signed information about the
specifying the digest algorithm and digital signature algorithm used update message. Additional_Info is specified as a type-length-value
to produce the first signature in each Signature-Segment. An IANA field for future extensibility. However, this specification defines
registry of algorithm identifiers for use in BGPSEC is created in the only a single (null) type of Additional Info which has zero length.
BGPSEC algorithms document[10]. It is anticipated that future specifications may specify semantics
for Info Types other than zero. See Section 3.2 below for more
detail.
Algorithm Suite Identifier 2 contains a one-octet identifier The BGPSEC_Path_Signatures attribute will contain one or two
specifying the digest algorithm and digital signature algorithm used Signature_Blocks, each of which corresponds to a different algorithm
to produce the second signature in each Signature-Segment. This suite. Each of the Signature_Blocks will contain a signature segment
field is ignored by the receiver if the first bit in the Flags octet for each AS number (i.e, secure path segment) in the Secure_Path. In
is set to zero (indicating that only one signature algorithm is used the most common case, the BGPSEC_Path_Signatures attribute will
in this BGPSEC update). An IANA registry of algorithm identifiers contain only a single Signature_Block. However, in order to enable a
for use in BGPSEC is created in the BGPSEC algorithms document[10]. transition from an old algorithm suite to a new algorithm suite, it
will be necessary to include two Signature_Blocks (one for the old
algorithm suite and one for the new algorithm suite) during the
transition period. (See Section 6.1 for more discussion of algorithm
transitions.) The format of the Signature_Blocks is described below
in Section 3.3.
There are eight octets reserved for future use. These octets are 3.1. Secure_Path
digitally signed (see Section 4 below).
Here we provide a detailed description of the Secure_Path information
in the BGPSEC_Path_Signatures attribute.
Signature_Path
+-----------------------------------------------+
| Secure_Path Length (2 octets) |
+-----------------------------------------------+
| One or More Secure_Path Segments (variable) |
+-----------------------------------------------+
The Secure_Path Length contains the length (in octets) of the
variable-length sequence of Secure_Path Segments. Note that this
means the length is six times the number Secure_Path Segments (i.e.,
the number of AS numbers in the path).
The Secure_Path contains one Secure_Path segment for each (distinct)
Autonomous System in the path to the NLRI specified in the update
message.
Secure_Path Segment
+----------------------------+
| AS Number (4 octets) |
+----------------------------+
| pCount (1 octet) |
+----------------------------+
| Flags (1 octet) |
+----------------------------+
The AS Number is the AS number of the BGP speaker that added this
Secure_Path segment to the BGPSEC_Path_Signatures attribute. (See
Section 4 for more information on populating this field.)
The pCount field contains the number of repetitions of the associated
autonomous system number that the signature covers. This field
enables a BGPSEC speaker to mimic the semantics of adding multiple
copies of their AS to the AS_PATH without requiring the speaker to
generate multiple signatures.
The Flags field is reserved for future use. This octet is digitally
signed. These octets MUST be set to zero by the sender. The
receiver uses this octet to verify the digital signature (regardless
of what value they contain), but otherwise ignores the octet (see
Section 4 for sender instructions and Section 5 for reciever
validation instructions).
EDITOR'S NOTE: The existence of a signed flags field provides the
possibility of adding in the future (in a backwards compatible
fashion) a new feature that requires per-AS signed bits. For
example, one could use a couple bits from this flag field to mark
some property of the connection between two ASes.
3.2. Additional_Info
Here we provide a detailed description of the Additional_Info in the
BGPSEC_Path_Signatures attribute.
Signature-Block
+---------------------------------------------+
| Info Type (1 octet) |
+---------------------------------------------+
| Info Length (1 octet) |
+---------------------------------------------+
| Info Value (variable) |
+---------------------------------------------+
The Info Type field is a one-octet value that identifies the type of
additional information included in the Info Value field. This
specification defines a single (null) type of Additional_Info. The
Info Type for this null type is zero.
The Info Length field contains the length in octets of the Info Value
field. For the (null) Info Type zero specified in this document, the
Info Length MUST be zero.
The syntax and semantics contained in the Info Value field depends on
the type contained in the Info Type field. For the (null) Info Type
zero specified in this document, the Info Value field is empty (since
the Info Length field must be zero).
Implementations compliant with this specification MUST set the Info
Type to zero in BGPSEC update messages for route advertisements that
they originate (see Section 4.1 for more details). When an
implementation compliant with this specification receives a BGPSEC
update message with an Info Type field that it does not understand
(i.e., an Info Type other than zero), the implementation MUST use the
Additional_Info when it verifies digital signatures (as per Section
5.1). However, other than signature verification, the implementation
MUST ignore the Info Value field when it does not understand the Info
Type.
EDITOR'S NOTE: In a previous version of this document there was an 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 Expire Time that was used to provide protection against replay of old
(stale) digital signatures or failure to propagate a withdrawal (stale) digital signatures or failure to propagate a withdrawal
message. This mechanism was removed from the current version of the message. This mechanism was removed from the current version of the
document. Please see the SIDR mailing list for discussions related document. Please see the SIDR mailing list for discussions related
to protection against replay attacks. Depending on the result of to protection against replay attacks. Depending on the result of
discussions within the SIDR working group this reserved field could discussions within the SIDR working group this Additional Info field
at some future point be used to re-introduce Expire Time, or some could at some future point be used to re-introduce Expire Time, or
other octets used in a future replay protection mechanism. some other octets used in a future replay protection mechanism. The
authors believe that the current instructions whereby the sender uses
a null Additional_Info type and the receiver ignores Additional_Info
types that it does not understand provides an oportunity to use these
octets in the future in a backwards-compatible fashion.
The BGPSEC_Path_Signatures attribute contains one Signature-Segment 3.3. Signature_Block
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 Here we provide a detailed description of the Signature_Blocks in the
BGPSEC_Path_Signatures attribute.
Signature_Block
+-------------------------------------------- +
| AS Number (4 octets) |
+---------------------------------------------+
| pCount (1 octet) |
+---------------------------------------------+
| Subject Key Identifier 1 Length (1 octet) |
+---------------------------------------------+
| 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) | | Algorithm Suite Identifier (1 octet) |
+---------------------------------------------+ +---------------------------------------------+
| Signature Length 2 (1 octet) | | Signature_Block Length (2 octets) |
+---------------------------------------------+ +---------------------------------------------+
| Signature 2 (variable) | | Sequence of Signature Segments (variable) |
+---------------------------------------------+ +---------------------------------------------+
The AS Number is the Autonomous System Number of the BGPSEC speaker The Algorithm Suite Identifier is a one-octet identifier specifying
that produced the digital signature(s) in this Signature Segment. the digest algorithm and digital signature algorithm used to produce
the digital signature in each Signature Segment. An IANA registry of
algorithm identifiers for use in BGPSEC is created in the BGPSEC
algorithms document[10].
The pCount field contains an unsigned integer indicating the number The Signature_Block Length is the total number of octets in all
of repetitions of the associated autonomous system number that the Signature Segments (i.e., the total size of the variable-length
signature covers. This field enables a BGPSEC speaker to mimic the portion of the Signature_Block.)
semantics of adding multiple copies of their AS to the AS-PATH
without requiring the speaker to generate multiple signatures.
The Subject Key Identifier 1 Length field contains the size (in A Signature_Block has exactly one Signature Segment for each
octets) of the value in the Subject Key Identifier 1 field of the Secure_Path Segment in the Secure_Path portion of the
Signature-Segment. The Subject Key Identifier 1 field contains the BGPSEC_Path_Signatures Attribute. (That is, one Signature Segment
value in the Subject Key Identifier extension of the RPKI end-entity for each distinct AS on the path for the NLRI in the Update message.)
certificate that is used to verify the first signature in the
Signature-Segment (see Section 5 for details on validity of BGPSEC
update messages).
The Signature 1 Length field contains the size (in octets) of the Signature Segments
value in the Signature 1 field. The Signature 1 field contains a +---------------------------------------------+
digital signature that protects the NLRI and the | Subject Key Identifier (20 octets) |
BGPSEC_Path_Signatures attribute (see Sections 4 and 5 for details on +---------------------------------------------+
generating and verifying this signature, respectively). | Signature Length (2 octets) |
+---------------------------------------------+
| Signature (variable) |
+---------------------------------------------+
The Subject Key Identifier 2 Length field contains the size (in The Subject Key Identifier contains the value in the Subject Key
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 Identifier extension of the RPKI end-entity certificate that is used
to verify the second signature in the Signature-Segment (see Section to verify the signature (see Section 5 for details on validity of
5 for details on validity of BGPSEC update messages). This field is BGPSEC update messages).
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 The Signature Length field contains the size (in octets) of the value
value in the Signature 2 field. This length field SHOULD be zero if in the Signature field of the Signature Segment.
the first bit in the Flags octet is zero (indicating that only one
algorithm suite is being used to generate signatures for this update The Signature contains a digital signature that protects the NLRI and
message). The Signature 2 field contains a digital signature that the BGPSEC_Path_Signatures attribute (see Sections 4 and 5 for
protects the NLRI and the BGPSEC_Path_Signatures attribute (see details on generating and verifying this signature, respectively).
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 BGPSEC_Path_Signatures is the speaker's own AS. The
appears once but may appear multiple times if AS prepending is second case is that in which the BGPSEC speaker receives a route
applied). The second case is that in which the BGPSEC speaker advertisement from a peer and then decides to propagate the route
receives a route advertisement from a peer and then decides to advertisement to an external (eBGP) peer (Section 4.2). That is, the
propagate the route advertisement to an external (eBGP) peer (Section BGPSEC speaker has received a BGPSEC update message and is
4.2). That is, the BGPSEC speaker has received a BGPSEC update constructing a new update message for the same NLRI in which the
message and is constructing a new update message for the same NLRI in BGPSEC_Path_Signatures attribute will contain AS number(s) other than
which the AS_PATH attribute will contain AS number(s) other than the 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 10, line 20 skipping to change at page 12, line 48
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
update message for each unique peer AS to which the update message is update message for each unique peer AS to which the update message is
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 would be unable to construct a valid BGPSEC update
(i.e., valid path signatures) containing a subset of the NLRI in the message (i.e., valid path signatures) containing a subset of the NLRI
received update. If a BGPSEC speaker wishes to advertise routes to in the received update. If a BGPSEC speaker wishes to advertise
multiple NLRI, then it MUST generate a separate BGPSEC update message routes to multiple NLRI, then it MUST generate a separate BGPSEC
for each NLRI. update message for each NLRI.
Note that in order to create or add a new signature to a BGPSEC Note that in order to create or add a new signature to a BGPSEC
update message with 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
[11]. Note also new signatures are only added to a BGPSEC update [9]. Note also new signatures are only added to a BGPSEC update
message when a BGPSEC speaker is generating an update message to send message when a BGPSEC speaker is generating an update message to send
to an external peer (i.e., when the AS number of the peer is not to an external peer (i.e., when the AS number of the peer is not
equal to the BGPSEC speaker's own AS number). Therefore, a BGPSEC equal to the BGPSEC speaker's own AS number). Therefore, a BGPSEC
speaker who only sends BGPSEC update messages to peers within its own speaker who only sends BGPSEC update messages to peers within its own
AS, it does 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), a BGPSEC an update whose path will contain only a single AS number), the
speaker will use only a single algorithm suite. That is, the BGPSEC BGPSEC speaker creates a new BGPSEC_Path_Signatures attribute as
speaker will set the Two_Algorithms flag to 0 in the follows.
BGPSEC_Path_Signatures attribute and include only a single signature
in the Signature-Segment (setting the Signature 2 Length and Subject
Key Identifier 2 Lengths to zero). However, to ensure backwards
compatibility during a period of transition from a 'current'
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 First, the BGPSEC speaker constructs the Secure_Path with a single
prefix(es) to issue a signed object, called a Route Origination Secure_Path Segment. The AS in this path is the BGPSEC speaker's own
Authorization (ROA), that authorizes a given AS to originate routes AS number. In particular, this AS number MUST match the AS number in
to a given set of prefixes (see [6]). Note that validation of a the AS number resource extension field of the Resource PKI end-entity
BGPSEC update message will fail (i.e., the validation algorithm, certificate(s) that will be used to verify the digital signature(s)
specified in Section 5.1, returns 'Not Good') unless there exists a constructed by this BGPSEC speaker.
valid ROA authorizing the first AS in the AS PATH attribute to
originate routes to the prefix being advertised. Therefore, a BGPSEC
speaker SHOULD NOT originate a BGPSEC update advertising a route for
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.
EDITOR'S NOTE: In a previous version of this document there was a Note that the BGPSEC_Path_Signatures attribute and the AS4_Path
description here of a mechanism that used that used periodic attribute are mutually exclusive. That is, any update message
repetition of update messages (aka "beaconing") to protect against containing the BGPSEC_Path_Signatures attribute MUST NOT contain the
replay of old (stale) digital signatures or failure to propagate a AS4_Path attribute nor the AS_Path attribute. The information that
withdrawal message. This mechanism was removed from the current would be contained in the AS4_Path (or AS_Path) attribute is instead
version of the document. Please see the SIDR mailing list for conveyed in the Secure_Path portion of the BGPSEC_Path_Signatures
discussions related to protection against replay attacks. Depending attribute.
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.
When originating a new route advertisement, the Note that the Resource PKI enables the legitimate holder of IP
BGPSEC_Path_Signatures attribute MUST contain a single Signature- address prefix(es) to issue a signed object, called a Route
Segment. The following describes how the BGPSEC speaker populates Origination Authorization (ROA), that authorizes a given AS to
the fields of the Signature-Segment (see Section 3 for more originate routes to a given set of prefixes (see [6]). Note that
information on the syntax of the Signature-Segment). validation of a BGPSEC update message will fail (i.e., the validation
algorithm, specified in Section 5.1, returns 'Not Good') unless there
exists a valid ROA authorizing the first AS in the Secure_Path
portion of the BGPSEC_Path_Signatures attribute to originate routes
to the prefix being advertised. Therefore, a BGPSEC speaker SHOULD
NOT originate a BGPSEC update advertising a route for a given prefix
unless there exists a valid ROA authorizing the BGPSEC speaker's AS
to originate routes to this prefix.
The AS field is set to the AS number of the BGPSEC speaker. That is, The pCount field of the Secure_Path Segment is typically set to the
the AS number that the BGPSEC speaker advertised in the Open message value 1. However, a BGPSEC speaker may set the pCount field to a
of the current BGP session. value greater than 1. Setting 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-BGPSEC update message (e.g., for
traffic engineering purposes). Setting the pCount field to a value
greater than one permits this repetition without requiring a separate
digital signature for each repetition.
The pCount field is typically set to the value 1. However, a BGPSEC The Flags field of the Secure_Path Segment MUST be set to zero. It
speaker may set the pCount field to a value greater than 1. Setting is anticipated that future specifications may instruct BGPSEC
the pCount field to a value greater than one has the same semantics speakers to set the Flags field to values other than zero.
as repeating an AS number multiple times in the AS_PATH of a non- Therefore, BGPSEC receivers compliant with this specification must be
BGPSEC update message (e.g., for traffic engineering purposes). able to accept values of the Flags field other than zero. Such
Setting the pCount field to a value greater than one permits this receivers will use the Flags field to verify digital signatures (see
repetition without requiring a separate digital signature for each Section 5) but will otherwise ignore non-zero values in the Flags
repetition. field.
The Subject Key Identifier 1 field (see Section 3) is populated with The BGPSEC speaker next constructs the Additional_Info portion of the
the identifier contained in the Subject Key Identifier extension of BGPSEC_Path_Signatures atttribute. The Info Type MUST be set to zero
the RPKI end-entity certificate (containing keys suitable for use and the Info Length MUST also be set to zero. The Info Value field
with Algorithm Suite 1) used by the BGPSEC speaker. This Subject Key is empty (has length zero). It is anticipated that future
Identifier will be used by recipients of the route advertisement to specifications may specify values of Info Type other than zero.
identify the proper certificate to use in verifying the signature. Therefore, BGPSEC receivers compliant with this specification must be
able to accept Additional_Info fields with non-zero Info Type. Such
receivers will use the Additional_Field to verify digital signatures
(see Section 5) but will otherwise ignore Additional_Field non-zero
Info Fields.
The Subject Key Identifier 1 Length field is populated with the Typically, a BGPSEC speaker will use only a single algorithm suite,
length (in octets) of the Subject Key Identifier 1 field. and thus create only a single Signature_Block in the
BGPSEC_Path_Signatures attribute. However, to ensure backwards
compatibility during a period of transition from a 'current'
algorithm suite to a 'new' algorithm suite, it will be necessary to
originate update messages that contain a Signature_Block for both the
'current' and the 'new' algorithm suites (see Section 6.1).
The Signature 1 field contains a digital signature that binds the When originating a new route advertisement, each Signature_Block MUST
NLRI, AS_Path attribute and BGPSEC_Path_Signatures attribute to the consist of a single Signature Segment. The following describes how
RPKI end-entity certificate used by the BGPSEC speaker. The digital the BGPSEC speaker populates the fields of the Signature_Block.
signature is computed as follows:
The Subject Key Identifier field (see Section 3) is populated with
the identifier contained in the Subject Key Identifier extension of
the RPKI end-entity certificate 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 Signature field contains a digital signature that binds the NLRI
and BGPSEC_Path_Signatures attribute to the RPKI end-entity
certificate used by the BGPSEC speaker. The digital signature is
computed as follows:
o Construct a sequence of octets by concatenating the Target AS o Construct a sequence of octets by concatenating the Target AS
Number, AS Number (from the Signature_Segment), pCount, Algorithm Number, the Secure_Path (Origin AS, pCount, and Flags), the
Suite Identifier 1, Reserved field of the BGPSEC_Path_Signatures Additional_Info (Info Type, Info Length, and Info Value),
attribute and NLRI. The Target AS Number is the AS to whom the Algorithm Suite Identifier, and NLRI. The Target AS Number is the
BGPSEC speaker intends to send the update message. (Note that the AS to whom the BGPSEC speaker intends to send the update message.
Target AS number is the AS number announced by the peer in the (Note that the Target AS number is the AS number announced by the
OPEN message of the BGP session within which the update is sent.) peer in the OPEN message of the BGP session within which the
update is sent.)
Sequence of Octets to be Signed Sequence of Octets to be Signed
+----------------------------------------+ +------------------------------------+
| Target AS Number (4 octets) | | Target AS Number (4 octets) |
+----------------------------------------+ +------------------------------------+
| AS Number (4 octets) | | Origin AS Number (4 octets) | ---\
+----------------------------------------+ +------------------------------------+ \
| pCount (1 octet) | | pCount (1 octet) | > Secure_Path
+----------------------------------------+ +------------------------------------+ /
| Algorithm Suite Identifier 1 (1 octet) | | Flags (1 octet) | ---/
+----------------------------------------+ +------------------------------------+
| Expire Time (8 octets) | | Info Type (1 octet) | ---\
+----------------------------------------+ +------------------------------------+ \
| NLRI Length (1 octet) | | Info Length (1 octet) | > Additional_Info
+----------------------------------------+ +------------------------------------+ /
| NLRI Prefix (variable) | | Info Value (variable) | ---/
+----------------------------------------+ +------------------------------------+
| Algorithm Suite Id. (1 octet) |
+------------------------------------+
| NLRI Length (1 octet) |
+------------------------------------+
| NLRI Prefix (variable) |
+------------------------------------+
o Apply to this octet sequence the digest algorithm (for Algorithm o Apply to this octet sequence the digest algorithm (for the
Suite 1) to obtain a digest value. algorithm suite of this Signature_Block) to obtain a digest value.
o Apply to this digest value the signature algorithm, (for Algorithm o Apply to this digest value the signature algorithm, (for the
Suite 1) to obtain the digital signature. Then populate the algorithm suite of this Signature_Block) to obtain the digital
Signature 1 field with this digital signature. signature. Then populate the Signature Field with this digital
signature.
The Signature 1 Length field is populated with the length (in octets) The Signature Length field is populated with the length (in octets)
of the Signature 1 field. of the Signature field.
4.2. Propagating a Route Advertisement 4.2. Propagating a Route Advertisement
EDITOR'S NOTE: There is a known issue in this section with regards to
confederations. BGPSEC update messages do not include the AS4_Path
or AS_Path attributes. Therefore, BGPSEC update messages can not use
AS_CONFED_SEQUENCE segments within AS4_Path (or AS_Path) to convey
confederation information (see RFC 5065). However, in this current
version of the BGPSEC specification there is no alternative mechanism
specified to convey confederation information. This needs to be
fixed in a future version of this document.
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 attribute (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 If a BGPSEC router has received only non-BGPSEC update messages
BGPSEC_Path_Signatures attribute unless it has selected, as the best (without the BGPSEC_Path_Signatures attribute) from a peer for a
route to the given prefix, a route that it received in an update given prefix and if it chooses to propagate that peer's route for the
message containing the BGPSEC_Path_Signatures attribute. In prefix, then it MUST NOT attach any BGPSEC_Path_Signatures attribute
particular, this means that whenever a BGPSEC speaker generates an to the corresponding update being propagated.
update message with a BGPSEC_Path_Signatures attribute that it will
possess a received update message for the same prefix that also
contains a BGPSEC_Path_Signatures attribute.
Additionally, whenever a BGPSEC speaker selects as the best route to
a given prefix a route that it received in an update message
containing the BGPSEC_Path_Signatures attribute, it is RECOMMENDED
that if the BGPSEC speaker chooses to propagate the route that it
generate an update message containing the BGPSEC_Path_Signatures
attribute. However, a BGPSEC speaker MAY propagate a route
advertisement by generating a (non-BGPSEC) update message that does
not contain the BGPSEC_Path_Signatures attribute. Note that if a
BGPSEC speaker receives a route advertisement containing the
BGPSEC_Path_Signatures attribute and chooses for any reason (e.g.,
its peer is a non-BGPSEC speaker) to propagate the route
advertisement as a non-BGPSEC update message without the
BGPSEC_Path_Signatures attribute, then it MUST follow the
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 Conversely, if a BGPSEC router has received a BGPSEC update message
length (in octets) of the Subject Key Identifier 1 field. (with the BGPSEC_Path_Signatures attribute) from a peer for a given
prefix and it chooses to propagate that peer's route for the prefix,
then it SHOULD propogate the route as a BGPSEC update message
containing the BGPSEC_Path_Signatures attribute. However, the BGPSEC
speaker MAY propogate the route as a (unsigned) BGP update message
without the BGPSEC_Path_Signatures attribute.
Note that removing BGPSEC signatures (i.e., propagating a route Note that removing BGPSEC signatures (i.e., propagating a route
advertisement without the BGPSEC_Path_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. Furtherore,
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 not attesting to the
that: (1) it received a BGPSEC update message that advertised this
route; and (2) it chose this route as its best path to the given
prefix. That is, the BGPSEC speaker is not attesting to the
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.
If the received BGPSEC update message uses two algorithm suites To generate the BGPSEC_Path_Signatures attribute on the outgoing
(i.e., the Two_Algorithms flag is set to 1) and the BGPSEC speaker update message, the BGPSEC speaker first prepends a new Secure_Path
supports both of the corresponding algorithms suites, then the BGPSEC Segment (places in first position) to the Secure_Path. The AS number
speaker SHOULD generate a new update message that uses both algorithm in this Secure_Path segment MUST match the AS number in the AS number
suites (i.e., set the Two_Algorithms flag to 1). If the received resource extension field of the Resource PKI end-entity
BGPSEC update message that uses two algorithm suites and the BGPSEC certificate(s) that will be used to verify the digital signature(s)
speaker does not support the second algorithm suite, then the BGPSEC constructed by this BGPSEC speaker.
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.)
The Reserved field from the BGPSEC_Path_Signatures attribute is
copied directly from the Reserved field in the received update
message.
The BGPSEC speaker then creates a new Signature-Segment. This
Signature-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 AS field is set to the AS number of the BGPSEC speaker. That is,
the AS number that the BGPSEC speaker advertised in the Open message
of the current BGP session.
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 the Signature_Segmenet still length of the AS path. (Note that BGPSEC speakers compute the
contains the AS Number of the route server as this information is effective length of the AS path by summing the pCount values in the
necessary for signature verification.) Note that the option of BGPSEC_Path_Signatures attribute, see Section 5.) However, when a
setting pCount to 0 is intended only for use by route servers that route server sets the pCount value to 0, it still inserts its AS
desire not to increase the effective AS-PATH length of routes they number into the Secure_Path segment, as this information is needed to
advertise. The pCount field SHOULD NOT be set to 0 in other validate the signature added by the route server. Note that the
circumstances. BGPSEC speakers SHOULD drop incoming update messages option of setting pCount to 0 is intended only for use by route
with pCount set to zero in cases where the BGPSEC speaker does not servers that desire not to increase the effective AS-PATH length of
expect its peer to set pCount to zero (i.e., cases where the peer is routes they advertise. The pCount field SHOULD NOT be set to 0 in
not acting as a route server). other circumstances. BGPSEC speakers SHOULD drop incoming update
messages 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 not acting as a route server).
The Subject Key Identifier 1 field (see Section 3) is populated with The Flags field of the Secure_Path Segment MUST be set to zero. It
the identifier contained in the Subject Key Identifier extension of is anticipated that future specifications may instruct BGPSEC
the RPKI end-entity certificate (containing keys suitable for use speakers to set the Flags field to values other than zero.
with Algorithm Suite 1) used by the BGPSEC speaker. This Subject Key Therefore, BGPSEC receivers compliant with this specification must be
Identifier will be used by recipients of the route advertisement to able to accept values of the Flags field other than zero. Such
identify the proper certificate to use in verifying the signature. receivers will use the Flags field to verify digital signatures (see
Section 5) but will otherwise ignore non-zero values in the Flags
field.
The Subject Key Identifier 1 Length field is populated with the The BGPSEC speaker next copies the Additional_Info portion of the
length (in octets) of the Subject Key Identifier 1 field. BGPSEC_Path_Signatures directly from the received update message to
the new update message (that it is constructing). Note that the
BGPSEC speaker MUST NOT change the Additional_Info as any change to
Additional_Info will cause the new BGPSEC update message to fail
validation (see Section 5).
The Signature 1 field in the new segment contains a digital signature If the received BGPSEC update message contains two Signature_ Blocks
that binds the NLRI, AS_Path attribute and BGPSEC_Path_Signatures and the BGPSEC speaker supports both of the corresponding algorithms
attribute to the RPKI end-entity certificate used by the BGPSEC suites, then the new update message generated by the BGPSEC speaker
speaker. The digital signature is computed as follows: SHOULD include both of the Signature_Blocks. If the received BGPSEC
update message contains two Signature_Blocks and the BGPSEC speaker
only supports one of the two corresponding algorithm suites, then the
BGPSEC speaker MUST remove the Signature_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_Blocks
contained in the received update message, then the BGPSEC speaker
MUST NOT propagate the route advertisement with the
BGPSEC_Path_Signatures attribute (as an unsigned BGP update message).
o Construct a sequence of octets by concatenating the Signature 1 Note that in the case where there are two Signature_Blocks
Length and Signature 1 fields of the most recent Signature-Segment (corresponding to different algorithm suites) that the validation
(the one corresponding to AS from whom the BGPSEC speaker's AS algorithm (see Section 5.1) deems a BGPSEC update message to be
received the announcement) with the pCount field inserted by the 'Good' if there is at least one supported algorithm suite (and
signer, and the Target AS (the AS to whom the BGPSEC speaker corresponding Signature_Block) that is deemed 'Good'. This means
intends to send the update message). Note that the Target AS that a 'Good' BGPSEC update message may contain a Signature_Block
number is the AS number announced by the peer in the OPEN message which is not deemed 'Good' (e.g., contains signatures that the BGPSEC
of the BGP session within which the BGPSEC update message is sent. does not sucessfully verify). Nonetheless, such Signature_Blocks
MUST NOT be removed. (See Section 7 for a discussion of the security
ramifications of this design choice.)
Sequence of Octets to be Signed For each Signature_Block corresponding to an algorithm suite that the
BGPSEC speaker does support, the BGPSEC speaker then adds a new
Signature Segment to the Signature_Block. This Signature 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 Secure_Path segments numbers in the
Secure_Path portion of the BGPSEC_Path_Signatures attribute. The
BGPSEC speaker populates the fields of this new signature segment as
follows.
+-------------------------------------------------------------+ The Subject Key Identifier field in the new segment is populated with
| Most Recent Signature 1 Length Field (1 octet) | the identifier contained in the Subject Key Identifier extension of
+-------------------------------------------------------------+ the RPKI end-entity certificate used by the BGPSEC speaker. This
| Most Recent Signature 1 Field (variable) | Subject Key Identifier will be used by recipients of the route
+-------------------------------------------------------------+ advertisement to identify the proper certificate to use in verifying
| pCount Field of Signer (1 octet) | the signature.
+-------------------------------------------------------------+
| Target AS Number (4 octets) | The Signature field in the new segment contains a digital signature
+-------------------------------------------------------------+ that binds the NLRI and BGPSEC_Path_Signatures attribute to the RPKI
end-entity certificate used by the BGPSEC speaker. The digital
signature is computed as follows:
o Construct a sequence of octets by concatenating the Target AS
number, the Secure_Path segment is being added by the BGPSEC
speaker constructing the signature, and the signature field of the
most recent Signature Segment (the one corresponding to AS from
whom the BGPSEC speaker's AS received the announcement). Note
that the Target AS number is the AS number announced by the peer
in the OPEN message of the BGP session within which the BGPSEC
update message is sent.
Sequence of Octets to be Signed
+--------------------------------------+
| Target AS Number (4 octets) |
+--------------------------------------+
| Signer's AS Number (4 octets) | ---\
+--------------------------------------+ \
| pCount (1 octet) | > Secure_Path
+--------- ----------------------------+ /
| Flags (1 octet) | ---/
+--------------------------------------+
| Most Recent Sig Field (variable) |
+--------------------------------------+
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_Block) 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_Block) to obtain the digital
signature. Then populate the Signature Field with this digital signature. Then populate the Signature Field with this digital
signature. signature.
The Subject Key Identifier 1 Length field is populated with the The Signature Length field is populated with the length (in octets)
length (in octets) of the Subject Key Identifier 1 field. of the Signature field.
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 48 skipping to change at page 20, line 9
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 [12] for origin case in analogous to the use of the RPKI-RTR protocol [11] 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
matter of local policy, and shall be handled using existing local matter of local policy, and shall be handled using existing local
policy mechanisms. It is expected that BGP peers will generally policy mechanisms. It is expected that BGP peers will generally
prefer routes received via 'Good' BGPSEC update messages over routes prefer routes received via 'Good' BGPSEC update messages over routes
received via 'Not Good' BGPSEC update messages as well as routes received via 'Not Good' BGPSEC update messages as well as routes
received via update messages that do not contain the received via update messages that do not contain the
BGPSEC_Path_Signatures attribute. However, BGPSEC specifies no BGPSEC_Path_Signatures attribute. However, BGPSEC specifies no
changes to the BGP decision process and leaves to the operator the changes to the BGP decision process and leaves to the operator the
selection of an appropriate policy mechanism to achieve the selection of an appropriate policy mechanism to achieve the
operator's desired results within the BGP decision process. operator's desired results within the BGP decision process.
BGPSEC validation need only be performed at eBGP edge. The BGPSEC validation needs only be performed at eBGP edge. The
validation status of a BGP signed/unsigned update MAY be conveyed via validation status of a BGP signed/unsigned update MAY be conveyed via
iBGP from an ingress edge router to an egress edge router. Local iBGP from an ingress edge router to an egress edge router. Local
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.
EDITOR'S NOTE: Text will be inserted here for dealing with the Upon receiving a BGPSEC update message, a BGPSEC speaker SHOULD sum
AS_PATH attribute. Note that the BGPGSEC_Path_Signatures attribute the pCount values within BGPSEC_Path_Signatures attribute to
now contains all of the information needed to construct the AS_PATH determine the effective length of the AS Path. The BGPSEC speaker
attribute. Therefore, there seem to be two options. One option the SHOULD use this sum of pCount values in precisely the same way as it
BGPSEC speaker checks the AS_PATH attribute against the information uses the length of the AS Path in non-BGPSEC update messages.
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 checks that the BGPSEC_Path_Signatures attribute is recipient performs the following checks:
properly formed (as specified in Section 3). If the
BGPSEC_Path_Signatures attribute is not properly formed, then the
recipient should log that an error occurred and drop the update
message containing the error.
Second, the BGPSEC speaker verifies that the origin AS is authorized o Check to ensure that the entire BGPSEC_Path_Signatures attribute
to advertise the prefix in question. To do this, consult the valid is syntactically correct (conforms to the specification in this
ROA data to obtain a list of AS numbers that are associated with the document).
o Check that each Signature_Block contains one Signature segment for
each Secure_Path segment in the Secure_Path portion of the
BGPSEC_Path_Signatures attribute. (Note that the entirety of each
Signature_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_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_Block and process
the update message as though it arrived with a single
Signature_Block. If the BGPSEC_Path_Signatures attribute contains a
syntax error that is not local to one of two Signature_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 either an
AS_Path or AS4_Path attribute, then the recipient should log that an
error occurred and drop the update message containing the error.
Next, the BGPSEC speaker verifies that the origin AS is authorized 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
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 Secure_Path portion of the
the AS-Path is not in the set of AS numbers associated with the given BGPSEC_Path_Signatures attribute. If the origin AS in the
prefix, then BGPSEC update message is 'Not Good' and the validation Secure_Path is not in the set of AS numbers associated with the given
algorithm terminates. prefix, then the BGPSEC update message is 'Not Good' and the
validation algorithm terminates.
Third, the BGPSEC speaker examines the Algorithm Suite identifiers Finally, the BGPSEC speaker examines the Signature_Blocks in the
and the Two-Algorithms flag in the BGPSEC_Path_Signatures attribute. BGPSEC_Path_Signatures attribute. A Signature_Block corresponding to
If the BGPSEC speaker does not support the first Algorithm Suite, an algorithm suite that the BGPSEC speaker does not support is not
considered in validation. If there does not exist a Signature_Block
corresponding to an algorithm suite that the BGPSEC speaker supports,
then the BGPSEC speaker MUST treat the update message in the same then the BGPSEC speaker MUST treat the update message in the same
manner that the BGPSEC speaker would treat an update message that manner that the BGPSEC speaker would treat an (unsigned) update
arrived without a BGPSEC_Path_Signatures attribute. (Note that message that arrived without a BGPSEC_Path_Signatures attribute.
algorithm transitions are designed so that this case will never
happen, therefore if this case occurs the BGPSEC speaker SHOULD log For each remaining Signature_Block (corresponding to an algorithm
an error message.) If the Two-Algorithms flag is set to 1 and the suite supported by the BGPSEC speaker), the BGPSEC speaker iterates
BGPSEC speaker supports only the first algorithm suite then it through the Signature segments in the Signature_Block, starting with
follows the instructions below to validate the signatures using the the most recently added segment (and concluding with the least
first algorithm suite, and ignore Signature 2 in each Signature- recently added segment). Note that there is a one-to-one
Segment. If the Two-Algorithms flag is set to 1 and the BGPSEC correspondence between Signature segments and Secure_Path segments
speaker supports both algorithm suites, then the BGPSEC speaker within the BGPSEC_Path_Signatures attribute. The following steps
follows the instructions below to validate the signatures using the make use of this correspondence.
first algorithm suite. The BGPSEC speaker MAY then analogously
validate the second set of signatures using Algorithm Suite 2. If
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 up all valid (AS, SKI,
the value in the Subject Key Identifier 1 field of the Signature- Public Key) triples in which the AS matches the AS number in the
Segment. If no such SKI value is found in the valid RPKI data corresponding Secure_Path segment. Of these triples that match
then validation fails and returns "Not Good". Similarly, if the the AS number, check whether where is an SKI that matches the
SKI exists but the AS Number associated with the SKI does NOT value in the Subject Key Identifier field of the Signature
match the AS Number in the Signature-Segment, then validation segment. If no such SKI value is found in the valid RPKI data
fails and returns "Not Good". 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 Algorithm Suite 1) on o (Step II): Compute the digest function (for the given algorithm
the appropriate data. If the segment is not the (least recently suite) on the appropriate data. If the segment is not the (least
added) segment corresponding to the origin AS, then the digest recently added) segment corresponding to the origin AS, then the
function should be computed on the following sequence of octets: digest function should be computed on the following sequence of
octets:
Sequence of Octets to be Hashed Sequence of Octets to be Hashed
+----------------------------------------------------------+ +-------------------------------------------+
| Signature 1 Length Field in the Next Segment (1 octet) | | AS Number of Target AS (4 octets) |
+----------------------------------------------------------+ +-------------------------------------------+
| Signature 1 Field in the Next Segment (variable) | | AS Number (4 octets) | ---\
+----------------------------------------------------------+ +-------------------------------------------+ \
| pCount Field in the Current Segment (1 octet) | | pCount (1 octet) | > Secure_Path
+----------------------------------------------------------+ +-------------------------------------------+ /
| AS Number of Previous AS (4 octets) | | Flags (1 octet) | ---/
+----------------------------------------------------------+ +-------------------------------------------+
| Sig Field in the Next Segment (variable) |
The 'Signature 1 Field in the Next Segment' and 'Signature 1 Length +-------------- ----------------------------+
Field in Next Segment' are the Signature 1 field and Signature 1
Length fields found in the Signature-Segment that is next to be
processed (that is, the next most recently added Signature- Segment).
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 Target AS' is the AS number of the BGPSEC
BGPSEC speaker validating the update message. Note that if a BGPSEC speaker validating the update message. Note that if a BGPSEC speaker
speaker uses multiple AS Numbers (e.g., the BGPSEC speaker is a uses multiple AS Numbers (e.g., the BGPSEC speaker is a member of a
member of a confederation), the AS number used here MUST be the AS confederation), the AS number used here MUST be the AS number
number announced in the OPEN message for the BGP session over which announced in the OPEN message for the BGP session over which the
the BGPSEC update was received. BGPSEC update was received.
For each other Signature-Segment, the 'AS Number of Previous AS' is For each other Signature-Segment, the 'AS Number of Target AS' is the
the AS number in the Signature-Segment that was most recently AS number in the Secure_Path segment that corresponds to the
processed. Signature segment added immediately after the one being processed.
(That is, in the Secure_Path segment that corresponds to the
Signature segment that the validator just finished processing.)
The AS Number, pCount and Flags fields are taken from the Secure_Path
segment that corresponds to the Signature segment currently being
processed. The 'Signature Field in the Next Segment' is the
Signature field found in the Signature segment that is next to be
processed (that is, the next most recently added Signature segment).
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 (i.e., if it is the least recently added segment), then the
following sequence of octets: digest function should be computed on the following sequence of
octets:
Sequence of Octets to be Hashed Sequence of Octets to be Hashed
-------------------------------------------+ +------------------------------------+
| AS Number of Previous AS (4 octets) | | AS Number of Target AS (4 octets) |
+------------------------------------------+ +------------------------------------+
| Origin AS Number (4 octets) | | Origin AS Number (4 octets) | ---\
+------------------------------------------+ +------------------------------------+ \
| Algorithm Suite 1 Identifier (1 octet) | | pCount (1 octet) | > Secure_Path
+------------------------------------------+ +------------------------------------+ /
| pCount (1 octet) | | Flags (1 octet) | ---/
+------------------------------------------+ +------------------------------------+
| NLRI Length (1 octet) | | Info Type (1 octet) | ---\
+------------------------------------------+ +------------------------------------+ \
| NLRI Prefix (variable) | | Info Length (1 octet) | > Additional_Info
+------------------------------------------+ +------------------------------------+ /
| Info Value (variable) | ---/
+------------------------------------+
| Algorithm Suite Id. (1 octet) |
+------------------------------------+
| NLRI Length (1 octet) |
+------------------------------------+
| NLRI Prefix (variable) |
+------------------------------------+
The NLRI Length, NLRI Prefix, Expire Time, and Algorithm Suite The NLRI Length, NLRI Prefix, Additional_Info, 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 Origin AS Number, pCount, and Flags fields are
Segment currently being processed. taken from the Secure_Path segment corresponding to the Signature
segment currently being processed.
The Origin AS Number is the same Origin AS Number that was located in
Step I above. (That is, the AS number in the least recently added
Signature-Segment.)
The 'AS Number of Previous AS' is the AS Number in the Signature- The 'AS Number of Target AS' is the AS Number from the Secure_Path
Segment that was most recently processed (i.e., processed before the segment that was added immediately after the Secure_Path segment
current segment). containing the Origin AS Number. (That is, the Secure_Path segment
corresponding to the Signature segment that the receiver just
finished processing prior to the current Signature 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, validation has failed and return 'Not Good'. signature is invalid, then mark the entire Signature-List Block as
If the signature validation algorithm determines that the 'Not Good' and proceed to the next Signature_Block. If the
signature is valid, then continue processing Signature-Segments. signature validation algorithm determines that the signature is
valid, then continue processing Signature-Segments (within the
current Signature-List Block).
If all Signature-Segments pass validation (i.e., all segments are If all Signature-Segments within a Signature-List Block pass
processed and the algorithm has not yet returned 'Not Good'), then validation (i.e., all segments are processed and the Signature-List
validation succeeds and returns 'Good'. Block has not yet been marked 'Not Good'), then the Signature_Block
is marked as 'Good'.
If at least one Signature_Block is marked as 'Good', then the
validation algorithm terminates and the BGPSEC update message is
deemed to be 'Good'. (That is, if a BGPSEC update message contains
two Signature_Blocks then the update message is deemed 'Good' if the
first Signature_Block is marked 'Good' OR the second Signature_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 33 skipping to change at page 25, line 22
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 signatures corresponding to the BGPSEC speakers SHOULD include only a single Signature_Block
'new' algorithm. (corresponding to the '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_Block is not equal to the number of
of ASes in the AS_PATH (e.g., aggregate signatures) ASes in the Secure_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., attributes other than the 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 22, line 33 skipping to change at page 26, line 24
considerations, please see [8]. considerations, please see [8].
A BGPSEC speaker who receives a valid BGPSEC update message, A BGPSEC speaker who receives a valid BGPSEC update message,
containing a route advertisement for a given prefix, is provided with containing a route advertisement for a given prefix, is provided with
the following security guarantees: the following security guarantees:
o The origin AS number corresponds to an autonomous system that has o The origin AS number corresponds to an autonomous system that has
been authorized by the IP address space holder to originate route been authorized by the IP address space holder to originate route
advertisements for the given prefix. advertisements for the given prefix.
o For each subsequent AS number in the AS-Path, a BGPSEC speaker
authorized by the holder of the AS number selected the given route
as the best route to the given prefix.
o For each AS number in the AS Path, a BGPSEC speaker authorized by o For each AS number in the AS Path, a BGPSEC speaker authorized by
the holder of the AS number intentionally propagated the route the holder of the AS number intentionally chose (in aacordance
advertisement to the next AS in the AS-Path. with local policy) to propagate the route advertisement to the
next AS in the Secure_Path.
That is, the recipient of a valid BGPSEC Update message is assured That is, the recipient of a valid BGPSEC Update message is assured
that the AS-Path corresponds to a sequence of autonomous systems who that the Secure_Path corresponds to a sequence of autonomous systems
have all agreed in principle to forward packets to the given prefix who have all agreed in principle to forward packets to the given
along the indicated path. (It should be noted BGPSEC does not offer prefix along the indicated path. (It should be noted BGPSEC does not
a precise guarantee that the data packets would propagate along the offer a precise guarantee that the data packets would propagate along
indicated path; it only guarantees that the BGP update conveying the the indicated path; it only guarantees that the BGP update conveying
path indeed propagated along the indicated path.) Furthermore, the the path indeed propagated along the indicated path.) Furthermore,
recipient is assured that this path terminates in an autonomous the recipient is assured that this path terminates in an autonomous
system that has been authorized by the IP address space holder as a system that has been authorized by the IP address space holder as a
legitimate destination for traffic to the given prefix. legitimate destination for traffic to the given prefix.
Note that although BGPSEC provides a mechanism for an AS to validate Note that although BGPSEC provides a mechanism for an AS to validate
that a received update message has certain security properties, the that a received update message has certain security properties, the
use of such a mechanism to influence route selection is completely a use of such a mechanism to influence route selection is completely a
matter of local policy. Therefore, a BGPSEC speaker can make no matter of local policy. Therefore, a BGPSEC speaker can make no
assumptions about the validity of a route received from an external assumptions about the validity of a route received from an external
BGPSEC peer. That is, a compliant BGPSEC peer may (depending on the BGPSEC peer. That is, a compliant BGPSEC peer may (depending on the
local policy of the peer) send update messages that fail the validity local policy of the peer) send update messages that fail the validity
test in Section 5. Thus, a BGPSEC speaker MUST completely validate test in Section 5. Thus, a BGPSEC speaker MUST completely validate
all BGPSEC update messages received from external peers. (Validation all BGPSEC update messages received from external peers. (Validation
of update messages received from internal peers is a matter of local of update messages received from internal peers is a matter of local
policy, see Section 5). policy, see Section 5).
Note that there may be cases where a BGPSEC speaker deems '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 two sets of signatures, one 'Good' and one 'Not Good'. that contains both a 'Good' and a 'Not Good' Signature_Block. That
That is, the update message contains two sets of signatures is, the update message contains two sets of signatures corresponding
corresponding to two algorithm suites, and one set of signatures to two algorithm suites, and one set of signatures verifies correctly
verifies correctly and the other set of signatures fails to verify. and the other set of signatures fails to verify. In this case, the
In this case, the protocol specifies that if the BGPSEC speaker protocol specifies that if the BGPSEC speaker propagates the route
propagates the route advertisement received in such an update message advertisement received in such an update message then the BGPSEC
then the BGPSEC speaker SHOULD add its signature using both the speaker SHOULD add its signature to each of the Signature_Blocks
algorithm suites. Thus the BGPSEC speaker creates a signature using using both the corresponding algorithm suite. Thus the BGPSEC
both algorithm suites and creates a new update message that contains speaker creates a signature using both algorithm suites and creates a
both the 'Good' and the 'Not Good' set of signatures (from its own new update message that contains both the 'Good' and the 'Not Good'
vantage point). set of signatures (from its own vantage point).
To understand the reason for such a design decision consider the case To understand the reason for such a design decision consider the case
where the BGPSEC speaker receives an update message with both a set where the BGPSEC speaker receives an update message with both a set
of algorithm A signatures which are '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 10 skipping to change at page 27, line 47
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' signatures were removed). Good' Signature_Blocks were removed).
A similar argument applies to the case where a BGPSEC speaker (for A similar argument applies to the case where a BGPSEC speaker (for
some reason such as lack of viable alternatives) selects as his best some reason such as lack of viable alternatives) selects as his best
route to a given prefix a route obtained via a 'Not 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'
signatures.) In such a case, the BGPSEC speaker should propagate a Signature-List Blocks.) In such a case, the BGPSEC speaker should
signed BGPSEC update message, adding his signature to the 'Not Good' propagate a signed BGPSEC update message, adding his signature to the
signatures that already exist. Again, this is to ensure that 'Not Good' signatures that already exist. Again, this is to ensure
'downstream' entities are able to make an informed decision and not that 'downstream' entities are able to make an informed decision and
erroneously treat the route as unsigned. It may also be noted here not erroneously treat the route as unsigned. It may also be noted
that due to possible differences in RPKI data at different vantage here that due to possible differences in RPKI data at different
points in the network, a BGPSEC update that was deemed 'Not Good' at vantage points in the network, a BGPSEC update that was deemed 'Not
an upstream BGPSEC speaker may indeed be deemed 'Good' at another BGP Good' at an upstream BGPSEC speaker may indeed be deemed 'Good' at
speaker downstream. another BGP 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 o The BGPSEC speaker received the given route advertisement with the
the indicated NLRI and AS Path; indicated NLRI and Secure_Path; and
2. The BGPSEC speaker selected this route as the best route to the
given prefix; and
3. The BGPSEC speaker chose to propagate an advertisement for this o The BGPSEC speaker chose to propagate an advertisement for this
route to the peer (implicitly) indicated by the 'Target AS' route to the peer (implicitly) indicated by the 'Target AS'
The BGPSEC update validation procedure is a potential target for The BGPSEC update validation procedure is a potential target for
denial of service attacks against a BGPSEC speaker. To mitigate the denial of service attacks against a BGPSEC speaker. To mitigate the
effectiveness of such denial of service attacks, BGPSEC speakers effectiveness of such denial of service attacks, BGPSEC speakers
should implement an update validation algorithm that performs should implement an update validation algorithm that performs
expensive checks (e.g., signature verification) after less expensive expensive checks (e.g., signature verification) after less expensive
checks (e.g., syntax checks). The validation algorithm specified in checks (e.g., syntax checks). The validation algorithm specified in
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 The mechanism of setting the pCount field to zero is included in this
included in this specification to enable route servers in the control specification to enable route servers in the control path to
path to participate in BGPSEC without increasing the effective length participate in BGPSEC without increasing the effective length of the
of the AS_PATH. However, entities other than route servers could AS-PATH. However, entities other than route servers could
conceivably use this mechanism (set the pCount to zero) to attract conceivably use this mechanism (set the pCount to zero) to attract
traffic (by reducing the effective length of the AS_PATH) traffic (by reducing the effective length of the AS-PATH)
illegitimately. This risk is largely mitigated if every BGPSEC illegitimately. This risk is largely mitigated if every BGPSEC
speaker drops incoming update messages that set pCount to zero but speaker drops incoming update messages that set pCount to zero but
come from a peer that is not a route server. However, note that a come from a peer that is not a route server. However, note that a
recipient of a BGPSEC update message in which an upstream entity that recipient of a BGPSEC update message 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.
Finally, BGPSEC does not provide protection against all attacks at
the transport layer. An adversary on the path between a BGPSEC
speaker and its peer is able to perform attacks such as modifying
valid BGPSEC updates to cause them to fail validation, injecting
(unsigned) BGP update messages without BGPSEC_Path_Signature
attributes, or injecting BGPSEC update messages with
BGPSEC_Path_Signature attributes that fail validation, or causing the
peer to tear-down the BGP session. Therefore, BGPSEC implementations
MUST support appropriate transport security mechanisms.
EDITOR'S NOTE: Do we want to mandate a specific transport security
mechanism (e.g., TCP-AO)?
8. Contributors 8. Contributors
8.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
skipping to change at page 26, line 22 skipping to change at page 30, line 22
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
8.2. Acknowledgements 8.2. Acknowledgements
The authors would like to thank Luke Berndt, Wes George, Sharon The authors would like to thank Luke Berndt, Sharon Goldberg, Ed
Goldberg, Ed Kern, Chris Morrow, Doug Maughan, Pradosh Mohapatra, Kern, Chris Morrow, Doug Maughan, Pradosh Mohapatra, Russ Mundy,
Russ Mundy, Sandy Murphy, Keyur Patel, Mark Reynolds, Heather Sandy Murphy, Keyur Patel, Mark Reynolds, Heather Schiller, Jason
Schiller, Jason Schiller, John Scudder, Ruediger Volk and David Ward Schiller, John Scudder, Ruediger Volk and David Ward for their
for their valuable input and review. valuable input and review.
9. 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
skipping to change at page 27, line 10 skipping to change at page 31, line 10
BGP", March 2011. BGP", March 2011.
[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] Reynolds, M., Turner, S., and S. Kent, "A Profile for BGPSEC
Router Certificates, Certificate Revocation Lists, and
Certification Requests", December 2011.
[10] Turner, S., "BGP Algorithms, Key Formats, & Signature Formats", [10] Turner, S., "BGP Algorithms, Key Formats, & Signature Formats",
December 2011. December 2011.
[11] Reynolds, M., Turner, S., and S. Kent, "A Profile for BGPSEC [11] Bush, R. and R. Austein, "The RPKI/Router Protocol",
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. 103 change blocks. 
528 lines changed or deleted 704 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/