draft-ietf-sidr-bgpsec-protocol-16.txt   draft-ietf-sidr-bgpsec-protocol-17.txt 
Network Working Group M. Lepinski, Ed. Network Working Group M. Lepinski, Ed.
Internet-Draft NCF Internet-Draft NCF
Intended status: Standards Track K. Sriram, Ed. Intended status: Standards Track K. Sriram, Ed.
Expires: December 21, 2016 NIST Expires: December 23, 2016 NIST
June 21, 2016 June 23, 2016
BGPsec Protocol Specification BGPsec Protocol Specification
draft-ietf-sidr-bgpsec-protocol-16 draft-ietf-sidr-bgpsec-protocol-17
Abstract Abstract
This document describes BGPsec, an extension to the Border Gateway This document describes BGPsec, an extension to the Border Gateway
Protocol (BGP) that provides security for the path of autonomous Protocol (BGP) that provides security for the path of autonomous
systems through which a BGP update message passes. BGPsec is systems through which a BGP update message passes. BGPsec is
implemented via a new optional non-transitive BGP path attribute that implemented via an optional non-transitive BGP path attribute that
carries a digital signature produced by each autonomous system that carries a digital signature produced by each autonomous system that
propagates the update message. propagates the update message.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" are to be interpreted as described in RFC 2119 [1] only "OPTIONAL" are to be interpreted as described in RFC 2119 [1] only
when they appear in all upper case. They may also appear in lower or when they appear in all upper case. They may also appear in lower or
mixed case as English words, without normative meaning. mixed case as English words, without normative meaning.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 December 21, 2016. This Internet-Draft will expire on December 23, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 29 skipping to change at page 2, line 29
2.1. The BGPsec Capability . . . . . . . . . . . . . . . . . . 3 2.1. The BGPsec Capability . . . . . . . . . . . . . . . . . . 3
2.2. Negotiating BGPsec Support . . . . . . . . . . . . . . . . 4 2.2. Negotiating BGPsec Support . . . . . . . . . . . . . . . . 4
3. The BGPsec_Path Attribute . . . . . . . . . . . . . . . . . . 6 3. The BGPsec_Path Attribute . . . . . . . . . . . . . . . . . . 6
3.1. Secure_Path . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Secure_Path . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Signature_Block . . . . . . . . . . . . . . . . . . . . . 8 3.2. Signature_Block . . . . . . . . . . . . . . . . . . . . . 8
4. BGPsec Update Messages . . . . . . . . . . . . . . . . . . . . 10 4. BGPsec Update Messages . . . . . . . . . . . . . . . . . . . . 10
4.1. General Guidance . . . . . . . . . . . . . . . . . . . . . 10 4.1. General Guidance . . . . . . . . . . . . . . . . . . . . . 10
4.2. Constructing the BGPsec_Path Attribute . . . . . . . . . . 12 4.2. Constructing the BGPsec_Path Attribute . . . . . . . . . . 12
4.3. Processing Instructions for Confederation Members . . . . 16 4.3. Processing Instructions for Confederation Members . . . . 16
4.4. Reconstructing the AS_PATH Attribute . . . . . . . . . . . 18 4.4. Reconstructing the AS_PATH Attribute . . . . . . . . . . . 18
5. Processing a Received BGPsec Update . . . . . . . . . . . . . 19 5. Processing a Received BGPsec Update . . . . . . . . . . . . . 20
5.1. Overview of BGPsec Validation . . . . . . . . . . . . . . 21 5.1. Overview of BGPsec Validation . . . . . . . . . . . . . . 21
5.2. Validation Algorithm . . . . . . . . . . . . . . . . . . . 22 5.2. Validation Algorithm . . . . . . . . . . . . . . . . . . . 22
6. Algorithms and Extensibility . . . . . . . . . . . . . . . . . 25 6. Algorithms and Extensibility . . . . . . . . . . . . . . . . . 25
6.1. Algorithm Suite Considerations . . . . . . . . . . . . . . 25 6.1. Algorithm Suite Considerations . . . . . . . . . . . . . . 25
6.2. Extensibility Considerations . . . . . . . . . . . . . . . 26 6.2. Extensibility Considerations . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
7.1 Security Guarantees . . . . . . . . . . . . . . . . . . . . 27 7.1 Security Guarantees . . . . . . . . . . . . . . . . . . . . 27
7.2 On the Removal of BGPsec Signatures . . . . . . . . . . . . 27 7.2 On the Removal of BGPsec Signatures . . . . . . . . . . . . 28
7.3 Mitigation of Denial of Service Attacks . . . . . . . . . . 29 7.3 Mitigation of Denial of Service Attacks . . . . . . . . . . 29
7.4 Additional Security Considerations . . . . . . . . . . . . . 29 7.4 Additional Security Considerations . . . . . . . . . . . . . 30
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.1. Authors . . . . . . . . . . . . . . . . . . . . . . . . . 30 9.1. Authors . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 31 9.2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 32
10. Normative References . . . . . . . . . . . . . . . . . . . . 31 10. Normative References . . . . . . . . . . . . . . . . . . . . 32
11. Informative References . . . . . . . . . . . . . . . . . . . 32 11. Informative References . . . . . . . . . . . . . . . . . . . 33
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
This document describes BGPsec, a mechanism for providing path This document describes BGPsec, a mechanism for providing path
security for Border Gateway Protocol (BGP) [2] route advertisements. security for Border Gateway Protocol (BGP) [2] route advertisements.
That is, a BGP speaker who receives a valid BGPsec update has That is, a BGP speaker who receives a valid BGPsec update has
cryptographic assurance that the advertised route has the following cryptographic assurance that the advertised route has the following
property: Every AS on the path of ASes listed in the update message property: Every AS on the path of ASes listed in the update message
has explicitly authorized the advertisement of the route to the has explicitly authorized the advertisement of the route to the
subsequent AS in the path. subsequent AS in the path.
This document specifies a new optional (non-transitive) BGP path This document specifies an optional (non-transitive) BGP path
attribute, BGPsec_Path. It also describes how a BGPsec-compliant BGP attribute, BGPsec_Path. It also describes how a BGPsec-compliant BGP
speaker (referred to hereafter as a BGPsec speaker) can generate, speaker (referred to hereafter as a BGPsec speaker) can generate,
propagate, and validate BGP update messages containing this attribute propagate, and validate BGP update messages containing this attribute
to obtain the above assurances. to obtain the above assurances.
BGPsec is intended to be used to supplement BGP Origin Validation BGPsec is intended to be used to supplement BGP Origin Validation
[19][20] and when used in conjunction with origin validation, it is [19][20] and when used in conjunction with origin validation, it is
possible to prevent a wide variety of route hijacking attacks against possible to prevent a wide variety of route hijacking attacks against
BGP. BGP.
skipping to change at page 3, line 36 skipping to change at page 3, line 36
the documents referenced therein.) Any BGPsec speaker who wishes to the documents referenced therein.) Any BGPsec speaker who wishes to
send, to external (eBGP) peers, BGP update messages containing the send, to external (eBGP) peers, BGP update messages containing the
BGPsec_Path needs to possess a private key associated with an RPKI BGPsec_Path needs to possess a private key associated with an RPKI
router certificate [9] that corresponds to the BGPsec speaker's AS router certificate [9] that corresponds to the BGPsec speaker's AS
number. Note, however, that a BGPsec speaker does not need such a number. Note, however, that a BGPsec speaker does not need such a
certificate in order to validate received update messages containing certificate in order to validate received update messages containing
the BGPsec_Path attribute (see Section 5.2). the BGPsec_Path attribute (see Section 5.2).
2. BGPsec Negotiation 2. BGPsec Negotiation
This document defines a new BGP capability [6] that allows a BGP This document defines a BGP capability [6] that allows a BGP speaker
speaker to advertise to a neighbor the ability to send or to receive to advertise to a neighbor the ability to send or to receive BGPsec
BGPsec update messages (i.e., update messages containing the update messages (i.e., update messages containing the BGPsec_Path
BGPsec_Path attribute). attribute).
2.1. The BGPsec Capability 2.1. The BGPsec Capability
This capability has capability code : TBD This capability has capability code : TBD
The capability length for this capability MUST be set to 3. The capability length for this capability MUST be set to 3.
The three octets of the capability value are specified as follows. The three octets of the capability value are specified as follows.
BGPsec Send Capability Value: BGPsec Send Capability Value:
skipping to change at page 5, line 14 skipping to change at page 5, line 14
Similarly, if a BGP speaker wishes to use BGPsec with two different Similarly, if a BGP speaker wishes to use BGPsec with two different
address families (i.e., IPv4 and IPv6) over the same BGP session, address families (i.e., IPv4 and IPv6) over the same BGP session,
then the speaker includes two instances of this capability (one for then the speaker includes two instances of this capability (one for
each address family) in the BGP OPEN message. A BGP speaker MUST each address family) in the BGP OPEN message. A BGP speaker MUST
support the BGP multiprotocol extension [3]. Additionally, a BGP support the BGP multiprotocol extension [3]. Additionally, a BGP
speaker MUST NOT advertise the capability of BGPsec support for a speaker MUST NOT advertise the capability of BGPsec support for a
particular AFI unless it has also advertised the multiprotocol particular AFI unless it has also advertised the multiprotocol
extension capability for the same AFI [3]. extension capability for the same AFI [3].
In a session where BGP session, a peer is permitted to send update In a BGPsec peering session, a peer is permitted to send update
messages containing the BGPsec_Path attribute if, and only if: messages containing the BGPsec_Path attribute if, and only if:
o The given peer sent the BGPsec capability for a particular version o The given peer sent the BGPsec capability for a particular version
of BGPsec and a particular address family with the Direction bit of BGPsec and a particular address family with the Direction bit
set to 1; and set to 1; and
o The other peer sent the BGPsec capability for the same version of o The other (receiving) peer sent the BGPsec capability for the same
BGPsec and the same address family with the Direction bit set to version of BGPsec and the same address family with the Direction
0. bit set to 0.
In such a session, we say that the use of (the particular version of) In such a session, we say that the use of the particular version of
BGPsec has been negotiated (for a particular address family). BGP BGPsec has been negotiated for a particular address family. BGP
update messages without the BGPsec_Path attribute MAY be sent within update messages without the BGPsec_Path attribute MAY be sent within
a session regardless of whether or not the use of BGPsec is a session regardless of whether or not the use of BGPsec is
successfully negotiated. However, if BGPsec is not successfully successfully negotiated. However, if BGPsec is not successfully
negotiated, then BGP update messages containing the BGPsec_Path negotiated, then BGP update messages containing the BGPsec_Path
attribute MUST NOT be sent. attribute MUST NOT be sent.
This document defines the behavior of implementations in the case This document defines the behavior of implementations in the case
where BGPsec version zero is the only version that has been where BGPsec version zero is the only version that has been
successfully negotiated. Any future document which specifies successfully negotiated. Any future document which specifies
additional versions of BGPsec will need to specify behavior in the additional versions of BGPsec will need to specify behavior in the
skipping to change at page 6, line 7 skipping to change at page 6, line 7
successfully negotiated, and update messages containing the successfully negotiated, and update messages containing the
BGPsec_Path attribute MUST NOT be sent within such a session. BGPsec_Path attribute MUST NOT be sent within such a session.
Note that BGPsec update messages can be quite large, therefore any Note that BGPsec update messages can be quite large, therefore any
BGPsec speaker announcing the capability to receive BGPsec messages BGPsec speaker announcing the capability to receive BGPsec messages
SHOULD also announce support for the capability to receive BGP SHOULD also announce support for the capability to receive BGP
extended messages [8]. extended messages [8].
3. The BGPsec_Path Attribute 3. The BGPsec_Path Attribute
The BGPsec_Path attribute is a new optional non-transitive BGP path The BGPsec_Path attribute is an optional non-transitive BGP path
attribute. attribute.
This document registers a new attribute type code for this attribute This document registers an attribute type code for this attribute :
: TBD TBD
The BGPsec_Path attribute carries the secured information regarding The BGPsec_Path attribute carries the secured information regarding
the path of ASes through which an update message passes. This the path of ASes through which an update message passes. This
includes the digital signatures used to protect the path information. includes the digital signatures used to protect the path information.
We refer to those update messages that contain the BGPsec_Path We refer to those update messages that contain the BGPsec_Path
attribute as "BGPsec Update messages". The BGPsec_Path attribute attribute as "BGPsec Update messages". The BGPsec_Path attribute
replaces the AS_PATH attribute in a BGPsec update message. That is, replaces the AS_PATH attribute in a BGPsec update message. That is,
update messages that contain the BGPsec_Path attribute MUST NOT update messages that contain the BGPsec_Path attribute MUST NOT
contain the AS_PATH attribute, and vice versa. contain the AS_PATH attribute, and vice versa.
The BGPsec_Path attribute is made up of several parts. The following The BGPsec_Path attribute is made up of several parts. The following
high-level diagram provides an overview of the structure of the high-level diagram provides an overview of the structure of the
BGPsec_Path attribute: BGPsec_Path attribute:
High-Level Diagram of the BGPsec_Path Attribute High-Level Diagram of the BGPsec_Path Attribute
skipping to change at page 8, line 9 skipping to change at page 8, line 9
| One or More Secure_Path Segments (variable) | | One or More Secure_Path Segments (variable) |
+-----------------------------------------------+ +-----------------------------------------------+
The Secure_Path Length contains the length (in octets) of the entire The Secure_Path Length contains the length (in octets) of the entire
Secure_Path (including the two octets used to express this length Secure_Path (including the two octets used to express this length
field). As explained below, each Secure_Path segment is six octets field). As explained below, each Secure_Path segment is six octets
long. Note that this means the Secure_Path Length is two greater long. Note that this means the Secure_Path Length is two greater
than six times the number Secure_Path Segments (i.e., the number of than six times the number Secure_Path Segments (i.e., the number of
AS numbers in the path). AS numbers in the path).
The Secure_Path contains one Secure_Path Segment for each (distinct) The Secure_Path contains one Secure_Path Segment for each Autonomous
Autonomous System in the path to the originating AS of the NLRI System in the path to the originating AS of the NLRI specified in the
specified in the update message. update message.
Secure_Path Segment Secure_Path Segment
+----------------------------+ +----------------------------+
| pCount (1 octet) | | pCount (1 octet) |
+----------------------------+ +----------------------------+
| Flags (1 octet) | | Flags (1 octet) |
+----------------------------+ +----------------------------+
| AS Number (4 octets) | | AS Number (4 octets) |
+----------------------------+ +----------------------------+
skipping to change at page 10, line 30 skipping to change at page 10, line 30
Section 4.4 contains instructions for reconstructing the AS_PATH Section 4.4 contains instructions for reconstructing the AS_PATH
attribute in cases where a BGPsec speaker receives an update message attribute in cases where a BGPsec speaker receives an update message
with a BGPsec_Path attribute and wishes to propagate the update with a BGPsec_Path attribute and wishes to propagate the update
message to a peer who does not support BGPsec. message to a peer who does not support BGPsec.
4.1. General Guidance 4.1. General Guidance
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 whom the update message is update message for each unique peer AS to whom 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 would be unable to construct a valid BGPsec update multiple NLRI would be unable to construct a valid BGPsec update
message (i.e., valid path signatures) containing a subset of the NLRI message (i.e., valid path signatures) containing a subset of the NLRI
in the received update. If a BGPsec speaker wishes to advertise in the received update. If a BGPsec speaker wishes to advertise
routes to multiple NLRI, then it MUST generate a separate BGPsec routes to multiple NLRI, then it MUST generate a separate BGPsec
update message for each NLRI. Additionally, a BGPsec update message update message for each NLRI. Additionally, a BGPsec update message
skipping to change at page 11, line 11 skipping to change at page 11, line 11
In order to create or add a new signature to a BGPsec update message In order to create or add a new signature to a BGPsec update message
with a given algorithm suite, the BGPsec speaker must possess a with a given algorithm suite, the BGPsec speaker must possess a
private key suitable for generating signatures for this algorithm private key suitable for generating signatures for this algorithm
suite. Additionally, this private key must correspond to the public suite. Additionally, this private key must correspond to the public
key in a valid Resource PKI end-entity certificate whose AS number key in a valid Resource PKI end-entity certificate whose AS number
resource extension includes the BGPsec speaker's AS number [9]. Note resource extension includes the BGPsec speaker's AS number [9]. Note
also that new signatures are only added to a BGPsec update message also that new signatures are only added to a BGPsec update message
when a BGPsec speaker is generating an update message to send to an 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 equal to 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 speaker who the BGPsec speaker's own AS number). Therefore, a BGPsec speaker who
only sends BGPsec update messages to peers within its own AS, it does only sends BGPsec update messages to peers within its own AS does not
not need to possess any private signature keys. need to possess any private signature keys.
The Resource PKI enables the legitimate holder of IP address The Resource PKI enables the legitimate holder of IP address
prefix(es) to issue a signed object, called a Route Origination prefix(es) to issue a signed object, called a Route Origination
Authorization (ROA), that authorizes a given AS to originate routes Authorization (ROA), that authorizes a given AS to originate routes
to a given set of prefixes (see [7]). It is expected that most to a given set of prefixes (see [7]). It is expected that most
relying parties will utilize BGPsec in tandem with origin validation relying parties will utilize BGPsec in tandem with origin validation
(see [19] and [20]). Therefore, it is RECOMMENDED that a BGPsec (see [19] and [20]). Therefore, it is RECOMMENDED that a BGPsec
speaker only originate a BGPsec update advertising a route for a speaker only originate a BGPsec update advertising a route for a
given prefix if there exists a valid ROA authorizing the BGPsec given prefix if there exists a valid ROA authorizing the BGPsec
speaker's AS to originate routes to this prefix. speaker's AS to originate routes to this prefix.
If a BGPsec router has received only a non-BGPsec update message If a BGPsec router has received only a non-BGPsec update message
(without the BGPsec_Path attribute), containing the AS_PATH (without the BGPsec_Path attribute), containing the AS_PATH
attribute, from a peer for a given prefix then it MUST NOT attach a attribute, from a peer for a given prefix then it MUST NOT attach a
BGPsec_Path attribute when it propagates the update message. (Note BGPsec_Path attribute when it propagates the update message. (Note
that a BGPsec router may also receive a non-BGPsec update message that a BGPsec router may also receive a non-BGPsec update message
from an internal peer without the AS_PATH attribute, i.e., with just from an internal peer without the AS_PATH attribute, i.e., with just
the NLRI in it. In that case, the prefix is originating from that AS the NLRI in it. In that case, the prefix is originating from that
and hence the BGPsec speaker SHOULD sign and forward the update to AS, and if it is selected for advertisement, the BGPsec speaker
its external BGPsec-speaking peers.) SHOULD attach a BGPsec_Path attribute and send a signed route (for
that prefix) to its external BGPsec-speaking peers.)
Conversely, if a BGPsec router has received a BGPsec update message Conversely, if a BGPsec router has received a BGPsec update message
(with the BGPsec_Path attribute) from a peer for a given prefix and (with the BGPsec_Path attribute) from a peer for a given prefix and
it chooses to propagate that peer's route for the prefix, then it it chooses to propagate that peer's route for the prefix, then it
SHOULD propagate the route as a BGPsec update message containing the SHOULD propagate the route as a BGPsec update message containing the
BGPsec_Path attribute. BGPsec_Path attribute.
Note that removing BGPsec signatures (i.e., propagating a route Note that removing BGPsec signatures (i.e., propagating a route
advertisement without the BGPsec_Path attribute) has significant advertisement without the BGPsec_Path attribute) has significant
security ramifications. (See Section 7 for discussion of the security ramifications. (See Section 7 for discussion of the
skipping to change at page 12, line 42 skipping to change at page 12, line 43
removed even in the case where the BGPsec update message has not been removed even in the case where the BGPsec update message has not been
successfully validated. (See Section 5 for more information on successfully validated. (See Section 5 for more information on
validation, and Section 7 for the security ramifications of removing validation, and Section 7 for the security ramifications of removing
BGPsec signatures.) BGPsec signatures.)
4.2. Constructing the BGPsec_Path Attribute 4.2. Constructing the BGPsec_Path Attribute
When a BGPsec speaker receives a BGPsec update message containing a When a BGPsec speaker receives a BGPsec update message containing a
BGPsec_Path attribute (with one or more signatures) from an (internal BGPsec_Path attribute (with one or more signatures) from an (internal
or external) peer, it may choose to propagate the route advertisement or external) peer, it may choose to propagate the route advertisement
by sending to its (internal or external) peers by creating a new by sending to its other (internal or external) peers. When sending
BGPsec advertisement for the same prefix. Similarly, when sending a said route advertisement to an internal BGPsec-speaking peer, the
new route advertisement to an external, BGPsec-speaking peer, the BGPsec_Path attribute SHALL NOT be modified. When sending said route
BGPsec speaker may send a BGPsec Update message by generating a new advertisement to an external BGPsec-speaking peer, the following
BGPsec_Path attribute. procedures are used to form or update the BGPsec_Path attribute.
To generate the BGPsec_Path attribute on the outgoing update message, To generate the BGPsec_Path attribute on the outgoing update message,
the BGPsec speaker first generates a new Secure_Path Segment. Note the BGPsec speaker first generates a new Secure_Path Segment. Note
that if the BGPsec speaker is not the origin AS and there is an that if the BGPsec speaker is not the origin AS and there is an
existing BGPsec_Path attribute, then the BGPsec speaker prepends its existing BGPsec_Path attribute, then the BGPsec speaker prepends its
new Secure_Path Segment (places in first position) onto the existing new Secure_Path Segment (places in first position) onto the existing
Secure_Path. Secure_Path.
The AS number in this Secure_Path segment MUST match the AS number in The AS number in this Secure_Path segment MUST match the AS number in
the AS number resource extension field of the Resource PKI router the AS number resource extension field of the Resource PKI router
skipping to change at page 13, line 27 skipping to change at page 13, line 28
times in the AS_PATH of a non-BGPsec update message (e.g., for times in the AS_PATH of a non-BGPsec update message (e.g., for
traffic engineering purposes). traffic engineering purposes).
To prevent unnecessary processing load in the validation of BGPsec To prevent unnecessary processing load in the validation of BGPsec
signatures, a BGPsec speaker SHOULD NOT produce multiple consecutive signatures, a BGPsec speaker SHOULD NOT produce multiple consecutive
Secure_Path Segments with the same AS number. This means that to Secure_Path Segments with the same AS number. This means that to
achieve the semantics of prepending the same AS number k times, a achieve the semantics of prepending the same AS number k times, a
BGPsec speaker SHOULD produce a single Secure_Path Segment -- with BGPsec speaker SHOULD produce a single Secure_Path Segment -- with
pCount of k -- and a single corresponding Signature Segment. pCount of k -- and a single corresponding Signature Segment.
A route server that participates in the BGP control path, but does A route server that participates in the BGP control plane, but does
not act as a transit AS in the data plane, may choose to set pCount not act as a transit AS in the data plane, may choose to set pCount
to 0. This option enables the route server to participate in BGPsec to 0. This option enables the route server to participate in BGPsec
and obtain the associated security guarantees without increasing the and obtain the associated security guarantees without increasing the
effective length of the AS path. (Note that BGPsec speakers compute effective length of the AS path. (Note that BGPsec speakers compute
the effective length of the AS path by summing the pCount values in the effective length of the AS path by summing the pCount values in
the BGPsec_Path attribute, see Section 5.) However, when a route the BGPsec_Path attribute, see Section 5.) However, when a route
server sets the pCount value to 0, it still inserts its AS number server sets the pCount value to 0, it still inserts its AS number
into the Secure_Path segment, as this information is needed to into the Secure_Path segment, as this information is needed to
validate the signature added by the route server. (See [18] for a validate the signature added by the route server. (See [18] for a
discussion of setting pCount to 0 to facilitate AS Number Migration.) discussion of setting pCount to 0 to facilitate AS Number Migration.)
skipping to change at page 14, line 5 skipping to change at page 14, line 6
Next, the BGPsec speaker generates one or two Signature_Blocks. Next, the BGPsec speaker generates one or two Signature_Blocks.
Typically, a BGPsec speaker will use only a single algorithm suite, Typically, a BGPsec speaker will use only a single algorithm suite,
and thus create only a single Signature_Block in the BGPsec_Path and thus create only a single Signature_Block in the BGPsec_Path
attribute. However, to ensure backwards compatibility during a attribute. However, to ensure backwards compatibility during a
period of transition from a 'current' algorithm suite to a 'new' period of transition from a 'current' algorithm suite to a 'new'
algorithm suite, it will be necessary to originate update messages algorithm suite, it will be necessary to originate update messages
that contain a Signature_Block for both the 'current' and the 'new' that contain a Signature_Block for both the 'current' and the 'new'
algorithm suites (see Section 6.1). algorithm suites (see Section 6.1).
If the received BGPsec update message contains two Signature_ Blocks If the received BGPsec update message contains two Signature_Blocks
and the BGPsec speaker supports both of the corresponding algorithms and the BGPsec speaker supports both of the corresponding algorithm
suites, then the new update message generated by the BGPsec speaker suites, then the new update message generated by the BGPsec speaker
SHOULD include both of the Signature_Blocks. If the received BGPsec SHOULD include both of the Signature_Blocks. If the received BGPsec
update message contains two Signature_Blocks and the BGPsec speaker update message contains two Signature_Blocks and the BGPsec speaker
only supports one of the two corresponding algorithm suites, then the only supports one of the two corresponding algorithm suites, then the
BGPsec speaker MUST remove the Signature_Block corresponding to the BGPsec speaker MUST remove the Signature_Block corresponding to the
algorithm suite that it does not understand. If the BGPsec speaker algorithm suite that it does not understand. If the BGPsec speaker
does not support the algorithm suites in any of the Signature_Blocks does not support the algorithm suites in any of the Signature_Blocks
contained in the received update message, then the BGPsec speaker contained in the received update message, then the BGPsec speaker
MUST NOT propagate the route advertisement with the BGPsec_Path MUST NOT propagate the route advertisement with the BGPsec_Path
attribute. (That is, if it chooses to propagate this route attribute. (That is, if it chooses to propagate this route
advertisement at all, it must do so as an unsigned BGP update advertisement at all, it must do so as an unsigned BGP update
message. See Section 4.4 for more information on converting to an message. See Section 4.4 for more information on converting to an
unsigned BGP message.) unsigned BGP message.)
Note that in the case where the BGPsec_Path has two Signature_Blocks Note that in the case where the BGPsec_Path has two Signature_Blocks
(corresponding to different algorithm suites), the validation (corresponding to different algorithm suites), the validation
algorithm (see Section 5.2) deems a BGPsec update message to be algorithm (see Section 5.2) deems a BGPsec update message to be
'Valid' if there is at least one supported algorithm suite (and 'Valid' if there is at least one supported algorithm suite (and
corresponding Signature_Block) that is deemed 'Valid'. This means corresponding Signature_Block) that is deemed 'Valid'. This means
that a 'Valid' BGPsec update message may contain a Signature_Block that a 'Valid' BGPsec update message may contain a Signature_Block
which is not deemed 'Valid' (e.g., contains signatures that the which is not deemed 'Valid' (e.g., contains signatures that BGPsec
BGPsec does not successfully verify). Nonetheless, such does not successfully verify). Nonetheless, such Signature_Blocks
Signature_Blocks MUST NOT be removed. (See Section 7 for a MUST NOT be removed. (See Section 7 for a discussion of the security
discussion of the security ramifications of this design choice.) ramifications of this design choice.)
For each Signature_Block corresponding to an algorithm suite that the For each Signature_Block corresponding to an algorithm suite that the
BGPsec speaker does support, the BGPsec speaker adds a new Signature BGPsec speaker does support, the BGPsec speaker adds a new Signature
Segment to the Signature_Block. This Signature Segment is prepended Segment to the Signature_Block. This Signature Segment is prepended
to the list of Signature Segments (placed in the first position) so to the list of Signature Segments (placed in the first position) so
that the list of Signature Segments appear in the same order as the that the list of Signature Segments appear in the same order as the
corresponding Secure_Path segments. The BGPsec speaker populates the corresponding Secure_Path segments. The BGPsec speaker populates the
fields of this new signature segment as follows. fields of this new signature segment as follows.
The Subject Key Identifier field in the new segment is populated with The Subject Key Identifier field in the new segment is populated with
skipping to change at page 15, line 5 skipping to change at page 15, line 7
advertisement to identify the proper certificate to use in verifying advertisement to identify the proper certificate to use in verifying
the signature. the signature.
The Signature field in the new segment contains a digital signature The Signature field in the new segment contains a digital signature
that binds the NLRI and BGPsec_Path attribute to the RPKI router that binds the NLRI and BGPsec_Path attribute to the RPKI router
certificate corresponding to the BGPsec speaker. The digital certificate corresponding to the BGPsec speaker. The digital
signature is computed as follows: signature is computed as follows:
o For clarity, let us number the Secure_Path and corresponding o For clarity, let us number the Secure_Path and corresponding
Signature Segments from 1 to N as follows. Let Secure_Path Segment Signature Segments from 1 to N as follows. Let Secure_Path Segment
1 and Signature Segment 1 be the segments produced by the origin 1 and Signature Segment 1 be the segments produced by the origin
AS. Let Secure_Path Segment 2 and Signature Segment 2 be the AS. Let Secure_Path Segment 2 and Signature Segment 2 be the
segments added by the next AS after the origin. Continue this segments added by the next AS after the origin. Continue this
method of numbering and ultimately let Secure_Path Segment N be method of numbering and ultimately let Secure_Path Segment N be
the Secure_Path segment that is being added by the current AS. the Secure_Path segment that is being added by the current AS.
o In order to construct the digital signature for Signature Segment o In order to construct the digital signature for Signature Segment
N (the signature segment being produced by the current AS), first N (the signature segment being produced by the current AS), first
construct the following sequence of octets to be hashed. construct the following sequence of octets to be hashed.
Sequence of Octets to be Hashed Sequence of Octets to be Hashed
skipping to change at page 16, line 23 skipping to change at page 16, line 24
The Signature Length field is populated with the length (in octets) The Signature Length field is populated with the length (in octets)
of the value in the Signature field. of the value in the Signature field.
4.3. Processing Instructions for Confederation Members 4.3. Processing Instructions for Confederation Members
Members of autonomous system confederations [5] MUST additionally Members of autonomous system confederations [5] MUST additionally
follow the instructions in this section for processing BGPsec update follow the instructions in this section for processing BGPsec update
messages. messages.
When a confederation member sends a BGPsec update message to a peer When a confederation member sends a BGPsec update message to a peer
that is a member of the same confederation, the confederation member that is a member of the same Member-AS, the confederation member
puts its (private) Member-AS Number (as opposed to the public AS SHALL NOT modify the BGPsec_Path attribute. When a confederation
Confederation Identifier) in the AS Number field of the Secure_Path member sends a BGPsec update message to a peer that is a member of
Segment that it adds to the BGPsec update message. Additionally, in the same confederation but is a different Member-AS, the
this case, the confederation member that generates the Secure_Path confederation member puts its (private) Member-AS Number (as opposed
Segment sets the Confed_Segment flag to one. This means that in a to the public AS Confederation Identifier) in the AS Number field of
BGPsec update message, an AS number appears in a Secure_Path Segment the Secure_Path Segment that it adds to the BGPsec update message.
with the Confed_Segment flag set whenever, in a non-BGPsec update Additionally, in this case, the confederation member that generates
message, the AS number would appear in a segment of type the Secure_Path Segment sets the Confed_Segment flag to one. This
AS_CONFED_SEQUENCE. means that in a BGPsec update message, an AS number appears in a
Secure_Path Segment with the Confed_Segment flag set whenever, in a
non-BGPsec update message, the AS number would appear in a segment of
type AS_CONFED_SEQUENCE.
Within a confederation, the verification of BGPsec signatures added Within a confederation, the verification of BGPsec signatures added
by other members of the confederation is optional. If a by other members of the confederation is optional. If a
confederation chooses not to have its members verify signatures added confederation chooses not to have its members verify signatures added
by other confederation members, then when sending a BGPsec update by other confederation members, then when sending a BGPsec update
message to a peer that is a member of the same confederation, the message to a peer that is a member of the same confederation, the
confederation members MAY set the Signature field within the confederation members MAY set the Signature field within the
Signature Segment that it generates to be zero (in lieu of Signature Segment that it generates to be zero (in lieu of
calculating the correct digital signature as described in Section calculating the correct digital signature as described in Section
4.2). Note that if a confederation chooses not to verify digital 4.2). Note that if a confederation chooses not to verify digital
skipping to change at page 18, line 16 skipping to change at page 18, line 21
in the corresponding Secure_Path segment is set to one. If the in the corresponding Secure_Path segment is set to one. If the
Confed_Sequence flag is set to one in the corresponding Secure_Path Confed_Sequence flag is set to one in the corresponding Secure_Path
segment, the confederation member does not perform any further checks segment, the confederation member does not perform any further checks
on the Signature Segment and immediately moves on to the next on the Signature Segment and immediately moves on to the next
Signature Segment (and checks its corresponding Secure_Path segment). Signature Segment (and checks its corresponding Secure_Path segment).
Note that as specified in Section 5.2, it is an error when a BGPsec Note that as specified in Section 5.2, it is an error when a BGPsec
speaker receives from a peer, who is not in the same AS speaker receives from a peer, who is not in the same AS
confederation, a BGPsec update containing a Confed_Sequence flag set confederation, a BGPsec update containing a Confed_Sequence flag set
to one. (As discussed in Section 5.2, any error in the BGPsec_Path to one. (As discussed in Section 5.2, any error in the BGPsec_Path
attribute MUST be handled using the "treat-as-withdraw", approach as attribute MUST be handled using the "treat-as-withdraw", approach as
defined in RFC 7606 [11].) defined in RFC7606 [11].)
4.4. Reconstructing the AS_PATH Attribute 4.4. Reconstructing the AS_PATH Attribute
BGPsec update messages do not contain the AS_PATH attribute. However, BGPsec update messages do not contain the AS_PATH attribute. However,
the AS_PATH attribute can be reconstructed from the BGPsec_Path the AS_PATH attribute can be reconstructed from the BGPsec_Path
attribute. This is necessary in the case where a route advertisement attribute. This is necessary in the case where a route advertisement
is received via a BGPsec update message and then propagated to a peer is received via a BGPsec update message and then propagated to a peer
via a non-BGPsec update message (e.g., because the latter peer does via a non-BGPsec update message (e.g., because the latter peer does
not support BGPsec). Note that there may be additional cases where an not support BGPsec). Note that there may be additional cases where an
implementation finds it useful to perform this reconstruction. Before implementation finds it useful to perform this reconstruction. Before
skipping to change at page 19, line 38 skipping to change at page 19, line 42
* In the case where the most recently added segment in the * In the case where the most recently added segment in the
AS_PATH is of type AS_SEQUENCE then add (prepend to the AS_PATH is of type AS_SEQUENCE then add (prepend to the
segment) a number of elements equal to the pCount field in the segment) a number of elements equal to the pCount field in the
current Secure_Path segment. The value of each of these current Secure_Path segment. The value of each of these
elements shall be the AS number contained in the current elements shall be the AS number contained in the current
Secure_Path segment. (That is, if the pCount field is X, then Secure_Path segment. (That is, if the pCount field is X, then
add X copies of the Secure_Path segment's AS Number field to add X copies of the Secure_Path segment's AS Number field to
the existing AS_SEQUENCE.) the existing AS_SEQUENCE.)
As part of the above described procedure, the following additional
actions are performed in order not to exceed the size limitations of
AS_SEQUENCE and AS_CONFED_SEQUENCE. While adding the next Secure_Path
segment (with its prepends, if any) to the AS_PATH being assembled,
if it would cause the AS_SEQUENCE (or AS_CONFED_SEQUENCE) at hand to
exceed the 255 ASN per segment limit [2][5], then the BGPsec speaker
would follow the recommendations in RFC4271 [2] and RFC5065 [5] of
creating another segment of the same type (AS_SEQUENCE or
AS_CONFED_SEQUENCE) and continue filling that.
5. Processing a Received BGPsec Update 5. Processing a Received BGPsec Update
Upon receiving a BGPsec update message from an external (eBGP) peer, Upon receiving a BGPsec update message from an external (eBGP) peer,
a BGPsec speaker SHOULD validate the message to determine the a BGPsec speaker SHOULD validate the message to determine the
authenticity of the path information contained in the BGPsec_Path authenticity of the path information contained in the BGPsec_Path
attribute. Typically, a BGPsec speaker will also wish to perform attribute. Typically, a BGPsec speaker will also wish to perform
origin validation (see [19] and [20]) on an incoming BGPsec update origin validation (see [19] and [20]) on an incoming BGPsec update
message, but such validation is independent of the validation message, but such validation is independent of the validation
described in this section. described in this section.
skipping to change at page 20, line 17 skipping to change at page 20, line 32
MAY temporarily defer validation of incoming BGPsec update messages. MAY temporarily defer validation of incoming BGPsec update messages.
The treatment of such BGPsec update messages, whose validation has The treatment of such BGPsec update messages, whose validation has
been deferred, is a matter of local policy. However, an been deferred, is a matter of local policy. However, an
implementation SHOULD ensure that deferment of validation and status implementation SHOULD ensure that deferment of validation and status
of deferred messages is visible to the operator. of deferred messages is visible to the operator.
The validity of BGPsec update messages is a function of the current The validity of BGPsec update messages is a function of the current
RPKI state. When a BGPsec speaker learns that RPKI state has changed RPKI state. When a BGPsec speaker learns that RPKI state has changed
(e.g., from an RPKI validating cache via the RPKI-to-Router protocol (e.g., from an RPKI validating cache via the RPKI-to-Router protocol
[15]), the BGPsec speaker MUST re-run validation on all affected [15]), the BGPsec speaker MUST re-run validation on all affected
update messages stored in its ADJ-RIB-IN. That is, when a given RPKI update messages stored in its Adj-RIB-In. For example, when a given
certificate ceases to be valid (e.g., it expires or is revoked), all RPKI certificate ceases to be valid (e.g., it expires or is revoked),
update messages containing a signature whose SKI matches the SKI in all update messages containing a signature whose SKI matches the SKI
the given certificate must be re-assessed to determine if they are in the given certificate must be re-assessed to determine if they are
still valid. If this reassessment determines that the validity state still valid. If this reassessment determines that the validity state
of an update has changed then, depending on local policy, it may be of an update has changed then, depending on local policy, it may be
necessary to re-run best path selection. necessary to re-run best path selection.
BGPsec update messages do not contain an AS_PATH attribute. BGPsec update messages do not contain an AS_PATH attribute.
Therefore, a BGPsec speaker MUST utilize the AS path information in Therefore, a BGPsec speaker MUST utilize the AS path information in
the BGPsec_Path attribute in all cases where it would otherwise use the BGPsec_Path attribute in all cases where it would otherwise use
the AS path information in the AS_PATH attribute. The only exception the AS path information in the AS_PATH attribute. The only exception
to this rule is when AS path information must be updated in order to to this rule is when AS path information must be updated in order to
propagate a route to a peer (in which case the BGPsec speaker follows propagate a route to a peer (in which case the BGPsec speaker follows
skipping to change at page 21, line 29 skipping to change at page 21, line 43
certificates. In particular, it is necessary that the recipient have certificates. In particular, it is necessary that the recipient have
access to the following data obtained from valid RPKI certificates: access to the following data obtained from valid RPKI certificates:
the AS Number, Public Key and Subject Key Identifier from each valid the AS Number, Public Key and Subject Key Identifier from each valid
RPKI router certificate. RPKI router certificate.
Note that the BGPsec speaker could perform the validation of RPKI Note that the BGPsec speaker could perform the validation of RPKI
certificates on its own and extract the required data, or it could certificates on its own and extract the required data, or it could
receive the same data from a trusted cache that performs RPKI receive the same data from a trusted cache that performs RPKI
validation on behalf of (some set of) BGPsec speakers. (For example, validation on behalf of (some set of) BGPsec speakers. (For example,
the trusted cache could deliver the necessary validity information to the trusted cache could deliver the necessary validity information to
the BGPsec speaker using the router key PDU [16] for the RTR protocol the BGPsec speaker using the router key PDU [16] for the RPKI-to-
[15].) Router protocol [15].)
To validate a BGPsec update message containing the BGPsec_Path To validate a BGPsec update message containing the BGPsec_Path
attribute, the recipient performs the validation steps specified in attribute, the recipient performs the validation steps specified in
Section 5.2. The validation procedure results in one of two states: Section 5.2. The validation procedure results in one of two states:
'Valid' and 'Not Valid'. 'Valid' and 'Not Valid'.
It is expected that the output of the validation procedure will be It is expected that the output of the validation procedure will be
used as an input to BGP route selection. That said, BGP route used as an input to BGP route selection. That said, BGP route
selection, and thus the handling of the validation states is a matter selection, and thus the handling of the validation states is a matter
of local policy, and is handled using local policy mechanisms. of local policy, and is handled using local policy mechanisms.
skipping to change at page 23, line 4 skipping to change at page 23, line 20
that none of the Secure_Path segments contain a Flags field with that none of the Secure_Path segments contain a Flags field with
the Confed_Sequence flag set to one. the Confed_Sequence flag set to one.
5. If the update message was received from a peer that is not 5. If the update message was received from a peer that is not
expected to set pCount equal to zero (see Section 4.2) then check expected to set pCount equal to zero (see Section 4.2) then check
to ensure that the pCount field in the most-recently added to ensure that the pCount field in the most-recently added
Secure_Path segment is not equal to zero. Secure_Path segment is not equal to zero.
If any of these checks fail, it is an error in the BGPsec_Path If any of these checks fail, it is an error in the BGPsec_Path
attribute. Any of these errors in the BGPsec_Path attribute are attribute. Any of these errors in the BGPsec_Path attribute are
handled as per RFC 7606 [11]. BGPsec speakers MUST handle these handled as per RFC7606 [11]. BGPsec speakers MUST handle these errors
errors using the "treat-as-withdraw" approach as defined in RFC 7606 using the "treat-as-withdraw" approach as defined in RFC7606 [11].
[11].
Next, the BGPsec speaker examines the Signature_Blocks in the Next, the BGPsec speaker examines the Signature_Blocks in the
BGPsec_Path attribute. A Signature_Block corresponding to an BGPsec_Path attribute. A Signature_Block corresponding to an
algorithm suite that the BGPsec speaker does not support is not algorithm suite that the BGPsec speaker does not support is not
considered in validation. If there is no Signature_Block considered in validation. If there is no Signature_Block
corresponding to an algorithm suite that the BGPsec speaker supports, corresponding to an algorithm suite that the BGPsec speaker supports,
then the BGPsec speaker MUST treat the update message in the same then the BGPsec speaker MUST treat the update message in the same
manner that the BGPsec speaker would treat an (unsigned) update manner that the BGPsec speaker would treat an (unsigned) update
message that arrived without a BGPsec_Path attribute. message that arrived without a BGPsec_Path attribute.
skipping to change at page 23, line 28 skipping to change at page 23, line 43
suite supported by the BGPsec speaker), the BGPsec speaker iterates suite supported by the BGPsec speaker), the BGPsec speaker iterates
through the Signature segments in the Signature_Block, starting with through the Signature segments in the Signature_Block, starting with
the most recently added segment (and concluding with the least the most recently added segment (and concluding with the least
recently added segment). Note that there is a one-to-one recently added segment). Note that there is a one-to-one
correspondence between Signature segments and Secure_Path segments correspondence between Signature segments and Secure_Path segments
within the BGPsec_Path attribute. The following steps make use of within the BGPsec_Path attribute. The following steps make use of
this correspondence. this correspondence.
o (Step 0): For clarity, let us number the Secure_Path and o (Step 0): For clarity, let us number the Secure_Path and
corresponding Signature Segments from 1 to N as follows. Let corresponding Signature Segments from 1 to N as follows. Let
Secure_Path Segment 1 and Signature Segment 1 be the segments Secure_Path Segment 1 and Signature Segment 1 be the segments
produced by the origin AS. Let Secure_Path Segment 2 and Signature produced by the origin AS. Let Secure_Path Segment 2 and Signature
Segment 2 be the segments added by the next AS after the origin. Segment 2 be the segments added by the next AS after the origin.
Continue this method of numbering and ultimately let Signature Continue this method of numbering and ultimately let Signature
Segment N be the Signature Segment that is currently being Segment N be the Signature Segment that is currently being
verified and let Secure_Path Segment N be the corresponding verified and let Secure_Path Segment N be the corresponding
Secure_Path Segment. Secure_Path Segment.
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 router certificate data and look up all valid (AS, SKI, RPKI router certificate data and look up all valid (AS, SKI,
skipping to change at page 24, line 44 skipping to change at page 25, line 11
member of a confederation), the AS number used here MUST be the AS member of a confederation), the AS number used here MUST be the AS
number announced in the OPEN message for the BGP session over number announced in the OPEN message for the BGP session over
which the BGPsec update was received. which the BGPsec update was received.
For each other Signature Segment, the 'Target AS Number' is the AS For each other Signature Segment, the 'Target AS Number' is the AS
number in the Secure_Path segment that corresponds to the number in the Secure_Path segment that corresponds to the
Signature Segment added immediately after the one being processed. Signature Segment added immediately after the one being processed.
(That is, in the Secure_Path segment that corresponds to the (That is, in the Secure_Path segment that corresponds to the
Signature segment that the validator just finished processing.) Signature segment that the validator just finished processing.)
Additionally, the Secure_Path and Signature Segment are obtained The Secure_Path and Signature Segment are obtained from the
from the BGPsec_Path attribute. The Address Family Identifier BGPsec_Path attribute. The Address Family Identifier (AFI),
(AFI), Subsequent Address Family Identifier (SAFI), and Network Subsequent Address Family Identifier (SAFI), and Network Layer
Layer Reachability Information (NLRI) fields are obtained from the Reachability Information (NLRI) fields are obtained from the
MP_REACH_NLRI attribute. Additionally, in the Prefix field of the MP_REACH_NLRI attribute. Additionally, in the Prefix field of the
NLRI (from MP_REACH_NLRI), all of the trailing bits MUST be set to NLRI (from MP_REACH_NLRI), all of the trailing bits MUST be set to
zero when constructing this sequence. zero when constructing this sequence.
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.
skipping to change at page 25, line 33 skipping to change at page 25, line 49
deemed to be 'Valid'. (That is, if a BGPsec update message contains deemed to be 'Valid'. (That is, if a BGPsec update message contains
two Signature_Blocks then the update message is deemed 'Valid' if the two Signature_Blocks then the update message is deemed 'Valid' if the
first Signature_Block is marked 'Valid' OR the second Signature_Block first Signature_Block is marked 'Valid' OR the second Signature_Block
is marked 'Valid'.) is marked 'Valid'.)
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
(using BGP capabilities) between BGPsec peers to use of a particular (using BGP capabilities) between BGPsec peers to use a particular
(digest and signature) algorithm suite. This is because the algorithm (digest and signature) algorithm suite. This is because the algorithm
suite used by the sender of a BGPsec update message must be 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 it is directly sending the
message, but also by all BGPsec speakers to whom the route message, but also by all BGPsec speakers to whom the route
advertisement is eventually propagated. Therefore, selection of an advertisement is eventually propagated. Therefore, selection of an
algorithm suite cannot be a local matter negotiated by BGP peers, but algorithm suite cannot be a local matter negotiated by BGP peers, but
instead must be coordinated throughout the Internet. instead must be coordinated throughout the Internet.
To this end, a mandatory algorithm suites document exists which To this end, a mandatory algorithm suites document exists which
specifies a mandatory-to-use 'current' algorithm suite for use by all specifies a mandatory-to-use 'current' algorithm suite for use by all
BGPsec speakers [10]. BGPsec speakers [10].
We anticipate that, in the future, the mandatory algorithm suites We anticipate that, in the future, the mandatory algorithm suites
document will be updated to specify a transition from the 'current' document will be updated to specify a transition from the 'current'
algorithm suite to a 'new' algorithm suite. During the period of algorithm suite to a 'new' algorithm suite. During the period of
transition (likely a small number of years), all BGPsec update transition (likely a small number of years), all BGPsec update
messages SHOULD simultaneously use both the 'current' algorithm suite messages SHOULD simultaneously use both the 'current' algorithm suite
and the 'new' algorithm suite. (Note that Sections 3 and 4 specify and the 'new' algorithm suite. (Note that Sections 3 and 4 specify
how the BGPsec_Path attribute can contain signatures, in parallel, how the BGPsec_Path attribute can contain signatures, in parallel,
for two algorithm suites.) Once the transition is complete, use of for two algorithm suites.) Once the transition is complete, use of
the old 'current' algorithm will be deprecated, use of the 'new' the old 'current' algorithm will be deprecated, use of the 'new'
algorithm will be mandatory, and a subsequent 'even newer' algorithm algorithm will be mandatory, and a subsequent 'even newer' algorithm
suite may be specified as recommend to implement. Once the suite may be specified as recommended to implement. Once the
transition has successfully been completed in this manner, BGPsec transition has successfully been completed in this manner, BGPsec
speakers SHOULD include only a single Signature_Block (corresponding speakers SHOULD include only a single Signature_Block (corresponding
to the 'new' algorithm). 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 and thus substantial changes to the processing of the BGPsec_Path and thus
necessitate a new version of BGPsec. Examples of such changes necessitate a new version of BGPsec. Examples of such changes
include: include:
skipping to change at page 26, line 34 skipping to change at page 26, line 49
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_Block is not equal to the number of signatures in the Signature_Block is not equal to the number of
ASes in the Secure_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., attributes other than the 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_TWO, which is designed to accommodate the let's call it BGPsec_Path_Two, which is designed to accommodate the
desired changes to BGPsec. In such a case, the mandatory algorithm desired changes to BGPsec. In such a case, the mandatory algorithm
suites document would be updated to specify algorithm suites suites document would be updated to specify algorithm suites
appropriate for the new version of BGPsec. 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
algorithm transition discussed in Section 6.1. During the transition algorithm transition discussed in Section 6.1. During the transition
period all BGPsec speakers SHOULD simultaneously include both the period all BGPsec speakers should simultaneously include both the
BGPsec_Path attribute and the new BGPsec_PATH_TWO attribute. Once BGPsec_Path attribute and the new BGPsec_Path_Two attribute. Once
the transition is complete, the use of BGPsec_Path could then be the transition is complete, the use of BGPsec_Path could then be
deprecated, at which point BGPsec speakers SHOULD include only the deprecated, at which point BGPsec speakers should include only the
new BGPsec_PATH_TWO attribute. Such a process could facilitate a new BGPsec_Path_Two attribute. Such a process could facilitate a
transition to a new BGPsec semantics in a backwards compatible transition to a new BGPsec semantics in a backwards compatible
fashion. fashion.
7. Security Considerations 7. Security Considerations
For a discussion of the BGPsec threat model and related security For a discussion of the BGPsec threat model and related security
considerations, please see [14]. considerations, please see [14].
7.1 Security Guarantees 7.1 Security Guarantees
When used in conjunction with Origin Validation (see [19] and [20]), When used in conjunction with Origin Validation (see [19] and [20]),
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:
skipping to change at page 27, line 24 skipping to change at page 27, line 39
o The origin AS number corresponds to an autonomous system that has o The origin AS number corresponds to an autonomous system that has
been authorized, in the RPKI, by the IP address space holder to been authorized, in the RPKI, by the IP address space holder to
originate route advertisements for the given prefix. originate route advertisements for the given prefix.
o For each AS in the path, a BGPsec speaker authorized by the holder o For each AS in the path, a BGPsec speaker authorized by the holder
of the AS number intentionally chose (in accordance with local of the AS number intentionally chose (in accordance with local
policy) to propagate the route advertisement to the subsequent AS policy) to propagate the route advertisement to the subsequent AS
in the path. in the path.
That is, the recipient of a valid BGPsec update message is assured That is, the recipient of a valid BGPsec update message is assured
that the update propagated via the sequences ASes listed in the that the update propagated via the sequence of ASes listed in the
Secure_Path portion of the BGPsec_Path attribute. (It should be noted Secure_Path portion of the BGPsec_Path attribute. (It should be noted
that BGPsec does not offer any guarantee that the data packets would that BGPsec does not offer any guarantee that the data packets would
flow along the indicated path; it only guarantees that the BGP update flow along the indicated path; it only guarantees that the BGP update
conveying the path indeed propagated along the indicated path.) conveying the path indeed propagated along the indicated path.)
Furthermore, the recipient is assured that this path terminates in an Furthermore, the recipient is assured that this path terminates in an
autonomous system that has been authorized by the IP address space autonomous system that has been authorized by the IP address space
holder as a legitimate destination for traffic to the given prefix. holder as a 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
skipping to change at page 28, line 35 skipping to change at page 28, line 51
validation status of a BGPsec update. validation status of a BGPsec update.
Note also that during a period of partial BGPsec deployment, a Note also that during a period of partial BGPsec deployment, a
'downstream' entity might reasonably treat unsigned messages 'downstream' entity might reasonably treat unsigned messages
differently from BGPsec updates that contain a single set of 'Not differently from BGPsec updates that contain a single set of 'Not
Valid' signatures. That is, by removing the set of 'Not Valid' Valid' signatures. That is, by removing the set of 'Not Valid'
signatures the BGPsec speaker might actually cause a downstream signatures the BGPsec speaker might actually cause a downstream
entity to 'upgrade' the status of a route advertisement from 'Not entity to 'upgrade' the status of a route advertisement from 'Not
Valid' to unsigned. Finally, note that in the above scenario, the Valid' to unsigned. Finally, note that in the above scenario, the
BGPsec speaker might have deemed algorithm A signatures 'Valid' only BGPsec speaker might have deemed algorithm A signatures 'Valid' only
because of some issue with RPKI state local to his AS (for example, because of some issue with RPKI state local to its AS (for example,
his AS might not yet have obtained a CRL indicating that a key used its AS might not yet have obtained a CRL indicating that a key used
to verify an algorithm A signature belongs to a newly revoked to verify an algorithm A signature belongs to a newly revoked
certificate). In such a case, it is highly desirable for a certificate). In such a case, it is highly desirable for a
downstream entity to treat the update as 'Not Valid' (due to the downstream entity to treat the update as 'Not Valid' (due to the
revocation) and not as 'unsigned' (which would happen if the 'Not revocation) and not as 'unsigned' (which would happen if the 'Not
Valid' Signature_Blocks were removed). Valid' Signature_Blocks were removed).
A similar argument applies to the case where a BGPsec speaker (for A similar argument applies to the case where a BGPsec speaker (for
some reason such as lack of viable alternatives) selects as his best some reason such as lack of viable alternatives) selects as its best
path (to a given prefix) a route obtained via a 'Not Valid' BGPsec path (to a given prefix) a route obtained via a 'Not Valid' BGPsec
update message. In such a case, the BGPsec speaker should propagate a update message. In such a case, the BGPsec speaker should propagate a
signed BGPsec update message, adding his signature to the 'Not Valid' signed BGPsec update message, adding its signature to the 'Not Valid'
signatures that already exist. Again, this is to ensure that signatures that already exist. Again, this is to ensure that
'downstream' entities are able to make an informed decision and not 'downstream' entities are able to make an informed decision and not
erroneously treat the route as unsigned. It should also be noted erroneously treat the route as unsigned. It should also be noted
that due to possible differences in RPKI data observed at different that due to possible differences in RPKI data observed at different
vantage points in the network, a BGPsec update deemed 'Not Valid' at vantage points in the network, a BGPsec update deemed 'Not Valid' at
an upstream BGPsec speaker may be deemed 'Valid' by another BGP an upstream BGPsec speaker may be deemed 'Valid' by another BGP
speaker downstream. speaker downstream.
Indeed, when a BGPsec speaker signs an outgoing update message, it is Indeed, when a BGPsec speaker signs an outgoing update message, it is
not attesting to a belief that all signatures prior to its are valid. not attesting to a belief that all signatures prior to its are valid.
Instead it is merely asserting that: Instead it is merely asserting that:
o The BGPsec speaker received the given route advertisement with the o The BGPsec speaker received the given route advertisement with the
indicated NLRI and Secure_Path; and indicated NLRI and Secure_Path; and
o The BGPsec speaker chose to propagate an advertisement for this o The BGPsec speaker chose to propagate an advertisement for this
route to the peer (implicitly) indicated by the 'Target AS' route to the peer (implicitly) indicated by the 'Target AS'.
7.3 Mitigation of Denial of Service Attacks 7.3 Mitigation of Denial of Service Attacks
The BGPsec update validation procedure is a potential target for The BGPsec update validation procedure is a potential target for
denial of service attacks against a BGPsec speaker. Here we consider denial of service attacks against a BGPsec speaker. Here we consider
the mitigation only of denial of service attacks that are specific to the mitigation only of denial of service attacks that are specific to
BGPsec. BGPsec.
To mitigate the effectiveness of such denial of service attacks, To mitigate the effectiveness of such denial of service attacks,
BGPsec speakers should implement an update validation algorithm that BGPsec speakers should implement an update validation algorithm that
skipping to change at page 30, line 20 skipping to change at page 30, line 37
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 within which an upstream entity recipient of a BGPsec update message within which an upstream entity
two or more hops away has set pCount to zero is unable to verify for two or more hops away has set pCount to zero is unable to verify for
themselves whether pCount was set to zero legitimately. themselves whether pCount was set to zero legitimately.
BGPsec does not provide protection against attacks at the transport BGPsec does not provide protection against attacks at the transport
layer. As with any BGP session, an adversary on the path between a layer. As with any BGP session, an adversary on the path between a
BGPsec speaker and its peer is able to perform attacks such as BGPsec speaker and its peer is able to perform attacks such as
modifying valid BGPsec updates to cause them to fail validation, modifying valid BGPsec updates to cause them to fail validation,
injecting (unsigned) BGP update messages without injecting (unsigned) BGP update messages without BGPsec_Path
BGPsec_Path_Signature attributes, injecting BGPsec update messages attributes, injecting BGPsec update messages with BGPsec_Path
with BGPsec_Path_Signature attributes that fail validation, or attributes that fail validation, or causing the peer to tear-down the
causing the peer to tear-down the BGP session. The use of BGPsec does BGP session. The use of BGPsec does nothing to increase the power of
nothing to increase the power of an on-path adversary -- in an on-path adversary -- in particular, even an on-path adversary
particular, even an on-path adversary cannot cause a BGPsec speaker cannot cause a BGPsec speaker to believe a BGPsec-invalid route is
to believe a BGPsec-invalid route is valid. However, as with any BGP valid. However, as with any BGP session, BGPsec sessions SHOULD be
session, BGPsec sessions SHOULD be protected by appropriate transport protected by appropriate transport security mechanisms.
security mechanisms.
8. IANA Considerations 8. IANA Considerations
This document registers a new capability in the registry of BGP This document registers a new capability in the registry of BGP
Capabilities. The description for the new capability is "BGPsec Capabilities. The description for the new capability is "BGPsec
Capability". The reference for the new capability is this document Capability". The reference for the new capability is this document
(i.e., the RFC that replaces draft-ietf-sidr-bgpsec-protocol), see (i.e., the RFC that replaces draft-ietf-sidr-bgpsec-protocol), see
Section 2.1. Section 2.1.
This document registers a new path attribute in the registry of BGP This document registers a new path attribute in the registry of BGP
Path Attributes. The code for this new attribute is "BGPsec_PATH". Path Attributes. The code for this new attribute is "BGPsec_Path".
The reference for the new capability is this document (i.e., the RFC The reference for the new capability is this document (i.e., the RFC
that replaces draft-ietf-sidr-bgpsec-protocol), see Section 3. that replaces draft-ietf-sidr-bgpsec-protocol), see Section 3.
This document does not create any new IANA registries. This document does not create any new IANA registries.
9. Contributors 9. Contributors
9.1. Authors 9.1. Authors
Rob Austein Rob Austein
 End of changes. 49 change blocks. 
101 lines changed or deleted 114 lines changed or added

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