rfc8206v1.txt   rfc8206.txt 
Internet Engineering Task Force (IETF) W. George Internet Engineering Task Force (IETF) W. George
Request for Comments: 8206 Request for Comments: 8206 Neustar
Updates: 8205 S. Murphy Updates: 8205 S. Murphy
Category: Standards Track SPARTA, Inc., a Parsons Company Category: Standards Track SPARTA, Inc., a Parsons Company
ISSN: 2070-1721 June 2017 ISSN: 2070-1721 September 2017
BGPsec Considerations for Autonomous System (AS) Migration BGPsec Considerations for Autonomous System (AS) Migration
Abstract Abstract
This document discusses considerations and methods for supporting and This document discusses considerations and methods for supporting and
securing a common method for Autonomous System (AS) migration within securing a common method for Autonomous System (AS) migration within
the BGPsec protocol. the BGPsec protocol.
Status of This Memo Status of This Memo
skipping to change at page 1, line 29 skipping to change at page 1, line 29
This is an Internet Standards Track document. This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841. Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata, Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc8206. https://www.rfc-editor.org/info/rfc8206.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
1.2. Documentation Note . . . . . . . . . . . . . . . . . . . 3 1.2. Documentation Note . . . . . . . . . . . . . . . . . . . 3
2. General Scenario . . . . . . . . . . . . . . . . . . . . . . 3 2. General Scenario . . . . . . . . . . . . . . . . . . . . . . 3
3. RPKI Considerations . . . . . . . . . . . . . . . . . . . . . 3 3. RPKI Considerations . . . . . . . . . . . . . . . . . . . . . 3
3.1. Origin Validation . . . . . . . . . . . . . . . . . . . . 4 3.1. Origin Validation . . . . . . . . . . . . . . . . . . . . 4
3.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 5 3.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Outbound Announcements (PE->CE) . . . . . . . . . . . 5 3.2.1. Outbound Announcements (PE-->CE) . . . . . . . . . . 5
3.2.2. Inbound Announcements (CE->PE) . . . . . . . . . . . 6 3.2.2. Inbound Announcements (CE-->PE) . . . . . . . . . . . 6
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Outbound (PE->CE) . . . . . . . . . . . . . . . . . . . . 8 5.1. Outbound (PE-->CE) . . . . . . . . . . . . . . . . . . . 8
5.2. Inbound (CE->PE) . . . . . . . . . . . . . . . . . . . . 8 5.2. Inbound (CE-->PE) . . . . . . . . . . . . . . . . . . . . 8
5.3. Other Considerations . . . . . . . . . . . . . . . . . . 9 5.3. Other Considerations . . . . . . . . . . . . . . . . . . 9
5.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
skipping to change at page 4, line 5 skipping to change at page 4, line 5
widely used during network integrations resulting from mergers and widely used during network integrations resulting from mergers and
acquisitions, as well as network redesigns; therefore, it is acquisitions, as well as network redesigns; therefore, it is
necessary to support this capability on any BGPsec-enabled routers/ necessary to support this capability on any BGPsec-enabled routers/
ASNs. What follows is a discussion of the potential issues to be ASNs. What follows is a discussion of the potential issues to be
considered regarding how ASN migration and BGPsec [RFC8205] considered regarding how ASN migration and BGPsec [RFC8205]
validation might interact. validation might interact.
One of the primary considerations for this document and migration is One of the primary considerations for this document and migration is
that service providers (SPs) rarely stop after one that service providers (SPs) rarely stop after one
merger/acquisition/divestiture; they end up accumulating several merger/acquisition/divestiture; they end up accumulating several
legacy ASNs over time. Since they are using methods to migrate that legacy ASNs over time. Since SPs are using migration methods that
are transparent to, and therefore do not require coordination with are transparent to customers and therefore do not require
customers, they do not have a great deal of control over the length coordination with customers, they do not have as much control over
of the transition period as they might with something completely the length of the transition period as they might with something
under their administrative control (e.g., a key roll). Because they completely under their administrative control (e.g., a key roll).
are not forcing a simultaneous migration (i.e., both ends switch to Because they are not forcing a simultaneous migration (i.e., both
the new ASN at an agreed-upon time), there is no incentive for a ends switch to the new ASN at an agreed-upon time), there is no
given customer to complete the move from the old ASN to the new one. incentive for a given customer to complete the move from the old ASN
This leaves many SPs with multiple legacy ASNs that don't go away to the new one. This leaves many SPs with multiple legacy ASNs that
very quickly, if at all. As solutions were being proposed for don't go away very quickly, if at all. As solutions were being
Resource Public Key Infrastructure (RPKI) implementations to solve proposed for Resource Public Key Infrastructure (RPKI)
this transition case, the WG carefully considered operational implementations to solve this transition case, the WG carefully
complexity and hardware scaling issues associated with maintaining considered operational complexity and hardware scaling issues
multiple legacy ASN keys on routers throughout the combined network. associated with maintaining multiple legacy ASN keys on routers
While SPs who choose to remain in this transition phase indefinitely throughout the combined network. While SPs who choose to remain in
invite added risks because of the operational complexity and scaling this transition phase indefinitely invite added risks because of the
considerations associated with maintaining multiple legacy ASN keys operational complexity and scaling considerations associated with
on routers throughout the combined network, saying "don't do this" is maintaining multiple legacy ASN keys on routers throughout the
of limited utility as a solution. As a result, this solution combined network, saying "don't do this" is of limited utility as a
attempts to minimize the additional complexity during the transition solution. As a result, this solution attempts to minimize the
period, on the assumption that it will likely be protracted. Note additional complexity during the transition period, on the assumption
that while this document primarily discusses service provider that it will likely be protracted. Note that while this document
considerations, it is not solely applicable to SPs, as enterprises primarily discusses service provider considerations, it is not solely
often migrate between ASNs using the same functionality. What applicable to SPs, as enterprises often migrate between ASNs using
follows is a discussion of origin and path validation functions and the same functionality. What follows is a discussion of origin and
how they interact with ASN migrations. path validation functions and how they interact with ASN migrations.
3.1. Origin Validation 3.1. Origin Validation
Route Origin Validation as defined by RFC 6480 [RFC6480] does not Route Origin Validation as defined by RFC 6480 [RFC6480] does not
modification to enable AS migration, as the existing protocol and require modification to enable AS migration, as the existing protocol
procedure allow for a solution. In the scenario discussed in RFC and procedure allow for a solution. In the scenario discussed in RFC
7705 [RFC7705], AS64510 is being replaced by AS64500. If there are 7705 [RFC7705], AS64510 is being replaced by AS64500. If there are
any existing routes originated by AS64510 on the router being moved any existing routes originated by AS64510 on the router being moved
into the new ASN, this simply requires generating new Route Origin into the new ASN, new Route Origination Authorizations (ROAs) for the
Authorizations (ROAs) for the routes with the new ASN and treating routes with the new ASN should be generated, and they should be
them as new routes to be added to AS64500. However, we also need to treated as new routes to be added to AS64500. However, we also need
consider the situation where one or more other PEs are still in to consider the situation where one or more other PEs are still in
AS64510 and are originating one or more routes that may be distinct AS64510 and are originating one or more routes that may be distinct
from any that the router under migration is originating. PE1 (which from any that the router under migration is originating. PE1 (which
is now a part of AS64500 and instructed to use "Replace Old AS" as is now a part of AS64500 and instructed to use "Replace Old AS" as
defined in [RFC7705] to remove AS64510 from the path) needs to be defined in [RFC7705] to remove AS64510 from the path) needs to be
able to properly handle routes originated from AS64510. If the route able to properly handle routes originated from AS64510. If the route
now shows up as originating from AS64500, any downstream peers' now shows up as originating from AS64500, any downstream peers'
validation check will fail unless a ROA is *also* available for validation check will fail unless a ROA is *also* available for
AS64500 as the origin ASN. In addition to generating a ROA for 65400 AS64500 as the origin ASN. In addition to generating a ROA for 65400
for any prefixes originated by the router being moved, it may be for any prefixes originated by the router being moved, it may be
necessary to generate ROAs for 65400 for prefixes that are necessary to generate ROAs for 65400 for prefixes that are
skipping to change at page 5, line 20 skipping to change at page 5, line 20
permissible per Section 3.2 of RFC 6480 [RFC6480] so managing origin permissible per Section 3.2 of RFC 6480 [RFC6480] so managing origin
validation during a migration like this is merely applying the validation during a migration like this is merely applying the
defined case where a set of prefixes are originated from more than defined case where a set of prefixes are originated from more than
one ASN. Therefore, for each ROA that authorizes the old ASN (e.g., one ASN. Therefore, for each ROA that authorizes the old ASN (e.g.,
AS64510) to originate a prefix, a new ROA MUST also be created that AS64510) to originate a prefix, a new ROA MUST also be created that
authorizes the replacing ASN (e.g., AS64500) to originate the same authorizes the replacing ASN (e.g., AS64500) to originate the same
prefix. prefix.
3.2. Path Validation 3.2. Path Validation
BGPsec path validation requires that each router in the AS Path BGPsec path validation requires that each router in the AS path
cryptographically sign its update to assert that "every Autonomous cryptographically sign its update to assert that "every Autonomous
System (AS) on the path of ASes listed in the update message has System (AS) on the path of ASes listed in the UPDATE message has
explicitly authorized the advertisement of the route to the explicitly authorized the advertisement of the route to the
subsequent AS in the path" (see Section 1 of RFC 8205 [RFC8205]). subsequent AS in the path" (see Section 1 of RFC 8205 [RFC8205]).
Since the referenced AS-migration technique explicitly modifies the Since the referenced AS-migration technique explicitly modifies the
AS_PATH between two eBGP peers who are not coordinating with one AS_PATH between two eBGP peers who are not coordinating with one
another (are not in the same administrative domain), no level of another (are not in the same administrative domain), no level of
trust can be assumed; therefore, it may be difficult to identify trust can be assumed; therefore, it may be difficult to identify
legitimate manipulation of the AS_PATH for migration activities when legitimate manipulation of the AS_PATH for migration activities when
compared to manipulation due to misconfiguration or malicious intent. compared to manipulation due to misconfiguration or malicious intent.
3.2.1. Outbound Announcements (PE->CE) 3.2.1. Outbound Announcements (PE-->CE)
When PE1 is moved from AS64510 to AS64500, it will be provisioned When PE1 is moved from AS64510 to AS64500, it will be provisioned
with the appropriate keys for AS64500 to allow it to forward-sign with the appropriate keys for AS64500 to allow it to forward-sign
routes using AS64500. However, there is no guidance in the BGPsec routes using AS64500. However, there is no guidance in the BGPsec
protocol specification [RFC8205] on whether or not the forward-signed protocol specification [RFC8205] on whether or not the forward-signed
ASN value is required to match the configured remote AS to validate ASN value is required to match the configured remote AS to validate
properly. That is, if CE1's BGP session is configured as "remote AS properly. That is, if CE1's BGP session is configured as "remote AS
64510", the presence of "local AS 64510" on PE1 will ensure that 64510", the presence of "local AS 64510" on PE1 will ensure that
there is no ASN mismatch on the BGP session itself, but if CE1 there is no ASN mismatch on the BGP session itself, but if CE1
receives updates from its remote neighbor (PE1) forward-signed from receives updates from its remote neighbor (PE1) forward-signed from
AS64500, there is no guidance as to whether the BGPsec validator on AS64500, there is no guidance as to whether the BGPsec validator on
CE1 still considers those valid by default. Section 6.3 of RFC 4271 CE1 still considers those valid by default. Section 6.3 of RFC 4271
[RFC4271] mentions this match between the ASN of the peer and the [RFC4271] mentions this match between the ASN of the peer and the
AS_PATH data, but it is listed as an optional validation, rather than AS_PATH data, but it is listed as an optional validation, rather than
a requirement. We cannot assume that this mismatch will be allowed a requirement. We cannot assume that this mismatch will be allowed
by vendor implementations, so using it as a means to solve this by vendor implementations, so using it as a means to solve this
migration case is likely to be problematic. migration case is likely to be problematic.
3.2.2. Inbound Announcements (CE->PE) 3.2.2. Inbound Announcements (CE-->PE)
Inbound is more complicated, because the CE doesn't know that PE1 has Inbound is more complicated, because the CE doesn't know that PE1 has
changed ASNs, so it is forward-signing all of its routes with changed ASNs, so it is forward-signing all of its routes with
AS64510, not AS64500. The BGPsec speaker cannot manipulate previous AS64510, not AS64500. The BGPsec speaker cannot manipulate previous
signatures and therefore cannot manipulate the previous AS Path signatures and therefore cannot manipulate the previous AS path
without causing a mismatch that will invalidate the route. If the without causing a mismatch that will invalidate the route. If the
updates are simply left intact, the ISP would still need to publish updates are simply left intact, the ISP would still need to publish
and maintain valid and active public keys for AS 64510 if it is to and maintain valid and active public keys for AS 64510 if it is to
appear in the BGPsec_Path_Signature so that receivers can validate appear in the BGPsec_PATH signature so that receivers can validate
that the BGPsec_Path_Signature arrived intact/whole. However, if the that the BGPsec_PATH signature arrived intact/whole. However, if the
updates are left intact, this will cause the AS Path length to be updates are left intact, this will cause the AS path length to be
increased, which is unacceptable as discussed in RFC 7705 [RFC7705]. increased, which is unacceptable as discussed in RFC 7705 [RFC7705].
4. Requirements 4. Requirements
In order to be deployable, any solution to the described problem In order to be deployable, any solution to the described problem
needs to consider the following requirements, listed in no particular needs to consider the following requirements, listed in no particular
order. BGPsec: order. BGPsec:
o MUST support AS migration for both inbound and outbound route o MUST support AS migration for both inbound and outbound route
announcements (see Sections 3.2.1 and 3.2.2), without reducing announcements (see Sections 3.2.1 and 3.2.2), without reducing
BGPsec's protections for route path. BGPsec's protections for route path.
o MUST NOT require any reconfiguration on the remote eBGP neighbor o MUST NOT require any reconfiguration on the remote eBGP neighbor
(CE). (CE).
o SHOULD NOT require global (i.e., network-wide) configuration o SHOULD NOT require global (i.e., network-wide) configuration
changes to support migration. The goal is to limit required changes to support migration. The goal is to limit required
configuration changes to the devices (PEs) being migrated. configuration changes to the devices (PEs) being migrated.
o MUST NOT lengthen the AS Path during migration. o MUST NOT lengthen the AS path during migration.
o MUST operate within existing trust boundaries, e.g., can't expect o MUST operate within existing trust boundaries, e.g., can't expect
remote side to accept pCount=0 (see Section 4.2 of RFC 8205 remote side to accept pCount=0 (see Section 4.2 of RFC 8205
[RFC8205]) from untrusted/non-confed neighbor. [RFC8205]) from untrusted/non-confederation neighbor.
5. Solution 5. Solution
As noted in Section 4.2 of RFC 8205 [RFC8205], BGPsec already has a As noted in Section 4.2 of RFC 8205 [RFC8205], BGPsec already has a
solution for hiding ASNs where increasing the AS Path length is solution for hiding ASNs where increasing the AS path length is
undesirable. So a simple solution would be to retain the keys for undesirable. So a simple solution would be to retain the keys for
AS64510 on PE1 and forward-sign towards CE1 with AS64510 and AS64510 on PE1 and forward-sign towards CE1 with AS64510 and
pCount=0. However, this would mean passing a pCount=0 between two pCount=0. However, this would mean passing a pCount=0 between two
ASNs that are in different administrative and trust domains such that ASNs that are in different administrative and trust domains such that
it could represent a significant attack vector to manipulate BGPsec- it could represent a significant attack vector to manipulate BGPsec-
signed paths. The expectation for legitimate instances of pCount=0 signed paths. The expectation for legitimate instances of pCount=0
(to make a route server that is not part of the transit path (to make a route server that is not part of the transit path
invisible) is that there is some sort of existing trust relationship invisible) is that there is some sort of existing trust relationship
between the operators of the route server and the downstream peers between the operators of the route server and the downstream peers
such that the peers could be explicitly configured by policy to such that the peers could be explicitly configured by policy to
skipping to change at page 7, line 50 skipping to change at page 7, line 50
applying a similar technique to the BGPsec signatures generated for applying a similar technique to the BGPsec signatures generated for
routing updates processed through this migration machinery. Each routing updates processed through this migration machinery. Each
routing update that is received from or destined to an eBGP neighbor routing update that is received from or destined to an eBGP neighbor
that is still using the old ASN (64510) will be signed twice, once that is still using the old ASN (64510) will be signed twice, once
with the ASN to be hidden and once with the ASN that will remain with the ASN to be hidden and once with the ASN that will remain
visible. In essence, we are treating the update as if the PE had an visible. In essence, we are treating the update as if the PE had an
internal BGP hop and the update was passed across an eBGP session internal BGP hop and the update was passed across an eBGP session
between AS64500 and AS64510, configured to use and accept pCount=0, between AS64500 and AS64510, configured to use and accept pCount=0,
while eliminating the processing and storage overhead of creating an while eliminating the processing and storage overhead of creating an
actual eBGP session between the two ASNs within the PE router. This actual eBGP session between the two ASNs within the PE router. This
will result in a properly secured AS Path in the affected route will result in a properly secured AS path in the affected route
updates, because the PE router will be provisioned with valid keys updates, because the PE router will be provisioned with valid keys
for both AS64500 and AS64510. An important distinction here is that for both AS64500 and AS64510. An important distinction here is that
while AS migration under standard BGP4 is manipulating the AS_PATH while AS migration under standard BGP4 is manipulating the AS_PATH
attribute, BGPsec uses an attribute called the "Secure_Path" (see attribute, BGPsec uses an attribute called the "Secure_Path" (see
Section 3.1 of RFC 8205 [RFC8205]) and BGPsec-capable neighbors do Section 3.1 of RFC 8205 [RFC8205]) and BGPsec-capable neighbors do
not exchange AS_PATH information in their route announcements. not exchange AS_PATH information in their route announcements.
However, a BGPsec neighbor peering with a non-BGPsec-capable neighbor However, a BGPsec neighbor peering with a non-BGPsec-capable neighbor
will use the information found in the Secure_Path to reconstruct a will use the information found in the Secure_Path to reconstruct a
standard AS_PATH for updates sent to that neighbor. Unlike in the standard AS_PATH for updates sent to that neighbor. Unlike in the
Secure_Path where the ASN to be hidden is still present but ignored Secure_Path where the ASN to be hidden is still present but ignored
when considering the AS Path (due to pCount=0), when reconstructing when considering the AS path (due to pCount=0), when reconstructing
an AS_PATH for a non-BGPsec neighbor, the pCount=0 ASNs will not an AS_PATH for a non-BGPsec neighbor, the pCount=0 ASNs will not
appear in the AS_PATH at all (see Section 4.4 of RFC 8205 [RFC8205]). appear in the AS_PATH at all (see Section 4.4 of RFC 8205 [RFC8205]).
This document is not changing existing AS_PATH reconstruction This document is not changing existing AS_PATH reconstruction
behavior, merely highlighting it for clarity. behavior, merely highlighting it for clarity.
The procedure to support AS migration in BGPsec is slightly different The procedure to support AS migration in BGPsec is slightly different
depending on whether the PE under migration is receiving the routes depending on whether the PE under migration is receiving the routes
from one of its eBGP peers ("inbound" as in Section 3.2.2) or from one of its eBGP peers ("inbound" as in Section 3.2.2) or
destined toward the eBGP peers ("outbound" as in Section 3.2.1). destined toward the eBGP peers ("outbound" as in Section 3.2.1).
5.1. Outbound (PE->CE) 5.1. Outbound (PE-->CE)
When a PE router receives an update destined for an eBGP neighbor When a PE router receives an update destined for an eBGP neighbor
that is locally configured with AS-migration mechanisms as discussed that is locally configured with AS-migration mechanisms as discussed
in RFC 7705 [RFC7705], it MUST generate a valid BGPsec signature as in RFC 7705 [RFC7705], it MUST generate a valid BGPsec signature as
defined in RFC 8205 [RFC8205] for _both_ configured ASNs. It MUST defined in RFC 8205 [RFC8205] for _both_ configured ASNs. It MUST
generate a signature from the new (global) ASN forward-signing to the generate a signature from the new (global) ASN forward-signing to the
old (local) ASN with pCount=0, and then it MUST generate a forward old (local) ASN with pCount=0, and then it MUST generate a forward
signature from the old (local) ASN to the target eBGP ASN with signature from the old (local) ASN to the target eBGP ASN with
pCount=1 as normal. pCount=1 as normal.
5.2. Inbound (CE->PE) 5.2. Inbound (CE-->PE)
When a PE router receives an update from an eBGP neighbor that is When a PE router receives an update from an eBGP neighbor that is
locally configured with AS-migration mechanisms (i.e., the opposite locally configured with AS-migration mechanisms (i.e., the opposite
direction of the previous route flow), it MUST generate a signature direction of the previous route flow), it MUST generate a signature
from the old (local) ASN forward-signing to the new (global) ASN with from the old (local) ASN forward-signing to the new (global) ASN with
pCount=0. It is not necessary to generate the second signature from pCount=0. It is not necessary to generate the second signature from
the new (global) ASN because the Autonomous System Border Router the new (global) ASN because the Autonomous System Border Router
(ASBR) will generate that when it forward-signs towards its eBGP (ASBR) will generate that when it forward-signs towards its eBGP
peers as defined in normal BGPsec operation. Note that a signature peers as defined in normal BGPsec operation. Note that a signature
is not normally added when a routing update is sent across an iBGP is not normally added when a routing update is sent across an iBGP
(internal BGP) session. The requirement to sign updates in iBGP (internal BGP) session. The requirement to sign updates in iBGP
represents a change to the normal behavior for this specific AS- represents a change to the normal behavior for this specific AS-
migration scenario only. migration scenario only.
5.3. Other Considerations 5.3. Other Considerations
In this case, the PE is adding BGPsec attributes to routes received In the inbound case discussed in Section 5.2, the PE is adding BGPsec
from or destined to an iBGP neighbor and using pCount=0 to mask them. attributes to routes received from or destined to an iBGP neighbor
While this is not prohibited by BGPsec [RFC8205], BGPsec-capable and using pCount=0 to mask them. While this is not prohibited by
routers that receive updates from BGPsec-enabled iBGP neighbors MUST BGPsec [RFC8205], BGPsec-capable routers that receive updates from
accept updates with new (properly formed) BGPsec attributes, BGPsec-enabled iBGP neighbors MUST accept updates with new (properly
including the presence of pCount=0 on a previous signature, or they formed) BGPsec attributes, including the presence of pCount=0 on a
will interfere with this method. In a similar fashion, any BGPsec- previous signature, or they will interfere with this method. In a
capable route-reflectors in the path of these updates MUST reflect similar fashion, any BGPsec-capable route-reflectors in the path of
them transparently to their BGPsec-capable clients. these updates MUST reflect them transparently to their BGPsec-capable
clients.
In order to secure this set of signatures, the PE router MUST be In order to secure this set of signatures, the PE router MUST be
provisioned with valid keys for _both_ configured ASNs (old and new), provisioned with valid keys for _both_ configured ASNs (old and new),
and the key for the old ASN MUST be kept valid until all eBGP and the key for the old ASN MUST be kept valid until all eBGP
sessions are migrated to the new ASN. Downstream neighbors will see sessions are migrated to the new ASN. Downstream neighbors will see
this as a valid BGPsec path, as they will simply trust that their this as a valid BGPsec path, as they will simply trust that their
upstream neighbor accepted pCount=0 because it was explicitly upstream neighbor accepted pCount=0 because it was explicitly
configured to do so based on a trust relationship and business configured to do so based on a trust relationship and business
relationship between the upstream and its neighbor (the old and new relationship between the upstream and its neighbor (the old and new
ASNs). ASNs).
skipping to change at page 10, line 5 skipping to change at page 10, line 5
5.4. Example 5.4. Example
The following example will illustrate the method being used above. The following example will illustrate the method being used above.
As with previous examples, PE1 is the router being migrated, AS64510 As with previous examples, PE1 is the router being migrated, AS64510
is the old ASN, which is being subsumed by AS64500, the ASN to be is the old ASN, which is being subsumed by AS64500, the ASN to be
permanently retained. 64505 is another external peer, used to permanently retained. 64505 is another external peer, used to
demonstrate what the announcements will look like to a third-party demonstrate what the announcements will look like to a third-party
peer that is not part of the migration. Some additional notation is peer that is not part of the migration. Some additional notation is
used to delineate the details of each signature as follows: used to delineate the details of each signature as follows:
The origin BGPsec signature attribute takes the form: The origin BGPsec Signature Segment takes the form:
sig(<Target ASN>, Origin ASN, pCount, NLRI Prefix) key. sig(Target ASN, (pCount,...,Origin ASN), NLRI) key.
Intermediate BGPsec signature attributes take the form: Intermediate BGPsec Signature Segments take the form:
sig(<Target ASN>, Signer ASN, pCount, <most recent sig field>) key. sig(Target ASN,...,(pCount,...,Signer ASN),...,NLRI) key.
(pCount,...,ASN) refers to the new Secure_Path Segment added to the
BGPsec_PATH attribute by the ASN (Origin ASN or Signer ASN).
"Equivalent AS_PATH" refers to what the AS_PATH would look like if it "Equivalent AS_PATH" refers to what the AS_PATH would look like if it
was reconstructed to be sent to a non-BGPsec peer, while the was reconstructed to be sent to a non-BGPsec peer, while the
Secure_Path shows the AS Path as represented between BGPsec peers. Securedpath shows the AS path as represented between BGPsec peers.
Note: The representation of signature attribute generation is being Note: The representation of Signature Segment generation is being
simplified here somewhat for the sake of brevity; the actual details simplified here somewhat for the sake of brevity; the actual details
of the signing process are as described in Sections 4.1 and 4.2 of of the signing process are as described in Sections 4.1 and 4.2 of
RFC 8205 [RFC8205]. For example, what is covered by the signature [RFC8205]. For example, what is covered by the signature also
also includes Flags, Algorithm Suite ID, NLRI length, etc. Also, the includes Flags, Algorithm Suite Identifier, NLRI length, etc. Also,
key is not carried in the update, instead the Subject Key Identifier the key is not carried in the update; instead, the Subject Key
(SKI) is carried. Identifier (SKI) is carried.
Before Merger Before Merger
64505
|
ISP B ISP A
CE-1 <--- PE-1 <------------------- PE-2 <--- CE-2
64496 Old_ASN: 64510 Old_ASN: 64500 64499
CE-2 to PE-2: sig(64500, (pCount=1,...,64499), N)K_64499-CE2
Equivalent AS_PATH=(64499)
Securedpath=(64499)
length=sum(pCount)=1
PE-2 to 64505: sig(64505,...,(pCount=1,...,64500),...,N)K_64500-PE2
sig(64500, (pCount=1,...,64499), N)K_64499-CE2
Equivalent AS_PATH=(64500,64499)
Securedpath=(64500,64499)
length=sum(pCount)=2
PE-2 to PE-1: sig(64510,...,(pCount=1,...,64500),...,N)K_64500-PE2
sig(64500, (pCount=1,...,64499), N)K_64499-CE2
Equivalent AS_PATH=(64500,64499)
Securedpath=(64500,64499)
length=sum(pCount)=2
PE-1 to CE-1: sig(64496,...,(pCount=1,...,64510),...,N)K_64510-PE1
sig(64510,...,(pCount=1,...,64500),...,N)K_64500-PE2
sig(64500, (pCount=1,...,64499), N)K_64499-CE2
Equivalent AS_PATH= (64510,64500,64499)
Securedpath=(64510,64500,64499)
length=sum(pCount)=3
Migrating, route flow outbound PE-1 to CE-1
64505 64505
| |
ISP B ISP A ISP A' ISP A'
CE-1 <--- PE-1 <------------------- PE-2 <--- CE-2 CE-1 <--- PE-1 <------------------- PE-2 <--- CE-2
64496 Old_ASN: 64510 Old_ASN: 64500 64499 64496 Old_ASN: 64510 Old_ASN: 64500 64499
New_ASN: 64500 New_ASN: 64500
CE-2 to PE-2: sig(<64500>, O=64499, pCount=1, N)K_64499-CE2 [sig1] CE-2 to PE-2: sig(64500, (pCount=1,...,64499), N)K_64499-CE2
Equivalent AS_PATH=(64499) Equivalent AS_PATH=(64499)
Secure_Path=(64499) Securedpath=(64499)
length=sum(pCount)=1 length=sum(pCount)=1
PE-2 to 64505: sig(<64505>, 64500, pCount=1, <sig1>)K_64500-PE2 [sig2] PE-2 to 64505: sig(64505,...,(pCount=1,...,64500),...,N)K_64500-PE2
sig(<64500>, 64499, pCount=1, N)K_64499-CE2 [sig1] sig(64500, (pCount=1,...,64499), N)K_64499-CE2
Equivalent AS_PATH=(64500,64499)
Secure_Path=(64500,64499)
length=sum(pCount)=2
PE-2 to PE-1: sig(<64510>, 64500, pCount=1, <sig1>)K_64500-PE2 [sig3]
sig(<64500>, 64499, pCount=1, N)K_64499-CE2 [sig1]
Equivalent AS_PATH=(64500,64499) Equivalent AS_PATH=(64500,64499)
Secure_Path=(64500,64499) Securedpath=(64500,64499)
length=sum(pCount)=2 length=sum(pCount)=2
PE-1 to CE-1: sig(<64496>, 64510, pCount=1, <sig3>)K_64510-PE1 [sig4] PE-2 to PE-1: sig(64500, (pCount=1,...,64499), N)K_64499-CE2
sig(<64510>, 64500, pCount=1, <sig1>)K_64500-PE2 [sig3] Equivalent AS_PATH=(64499)
sig(<64500>, 64499, pCount=1, N)K_64499-CE2 [sig1] Securedpath=(64499)
Equivalent AS_PATH= (64510,64500,64499) length=sum(pCount)=1
Secure_Path=(64510,64500,64499) #PE-2 sends to PE-1 (in iBGP) the exact same update
length=sum(pCount)=3 #as it received from AS64499.
Migrating, route flow outbound PE-1 to CE-1
64505
|
ISP A' ISP A'
CE-1 <--- PE-1 <------------------- PE-2 <--- CE-2
64496 Old_ASN: 64510 Old_ASN: 64500 64499
New_ASN: 64500 New_ASN: 64500
CE-2 to PE-2: sig(<64500>, 64499, pCount=1, N)K_64499-CE2 [sig11]
Equivalent AS_PATH=(64499)
Secure_Path=(64499)
length=sum(pCount)=1
PE-2 to 64505: sig(<64505>, 64500, pCount=1, <sig11>)K_64500-PE2 [sig12]
sig(<64500>, 64499, pCount=1, N)K_64499-CE2 [sig11]
Equivalent AS_PATH=(64500,64499)
Secure_Path=(64500,64499)
length=sum(pCount)=2
PE-2 to PE-1: sig(<64500>, 64499, pCount=1, N)K_64499-CE2 [sig11]
Equivalent AS_PATH=(64499)
Secure_Path=(64499)
length=sum(pCount)=1
#PE-2 sends to PE-1 (in iBGP) the exact same update
#as received from AS64499.
PE-1 to CE-1: sig(<64496>, 64510, pCount=1, <sig13>)K_64510-PE1 [sig14] PE-1 to CE-1: sig(64496,...,(pCount=1,...,64510),...,N)K_64510-PE1
sig(<64510>, 64500, pCount=0, <sig11>)K_64500-PE2 [sig13] sig(64510,...,(pCount=0,...,64500),...,N)K_64500-PE2 (*)
sig(<64500>, 64499, pCount=1, N)K_64499-CE2 [sig11] sig(64500, (pCount=1,...,64499), N)K_64499-CE2
Equivalent AS_PATH=(64510,64499) Equivalent AS_PATH=(64510,64499)
Secure_Path=(64510, 64500(pCount=0),64499) Securedpath=(64510, 64500 (pCount=0),64499)
length=sum(pCount)=2 (length is NOT 3) length=sum(pCount)=2 (length is NOT 3)
#PE1 adds [sig13] acting as AS64500 #PE-1 adds the Secure_Path Segment in (*) acting as AS64500
#PE1 accepts [sig13] with pCount=0 acting as AS64510, #PE-1 accepts (*) with pCount=0 acting as AS64510,
#as it would if it received sig13 from an eBGP peer #as it would if it received (*) from an eBGP peer
Migrating, route flow inbound CE-1 to PE-1 Migrating, route flow inbound CE-1 to PE-1
64505 64505
| |
ISP A' ISP A' ISP A' ISP A'
CE-1 ---> PE-1 -------------------> PE-2 ---> CE-2 CE-1 ---> PE-1 -------------------> PE-2 ---> CE-2
64496 Old_ASN: 64510 Old_ASN: 64500 64499 64496 Old_ASN: 64510 Old_ASN: 64500 64499
New_ASN: 64500 New_ASN: 64500 New_ASN: 64500 New_ASN: 64500
CE-1 to PE-1: sig(<64510>, 64496, pCount=1, N)K_64496-CE1 [sig21] CE-1 to PE-1: sig(64510, (pCount=1,...,64496), N)K_64496-CE1
Equivalent AS_PATH=(64496) Equivalent AS_PATH=(64496)
Secure_Path=(64496) Securedpath=(64496)
length=sum(pCount)=1 length=sum(pCount)=1
PE-1 to PE-2: sig(<64500>, 64510, pCount=0, <sig21>)K_64510-PE1 [sig22] PE-1 to PE-2: sig(64500,...,(pCount=0,...,64510),...,N)K_64510-PE1 (**)
sig(<64510>, 64496, pCount=1, N)K_64496-CE1 [sig21] sig(64510, (pCount=1,...,64496), N)K_64496-CE1
Equivalent AS_PATH=(64496) Equivalent AS_PATH=(64496)
Secure_Path=(64510 (pCount=0),64496) Securedpath=(64510 (pCount=0),64496)
length=sum(pCount)=1 (length is NOT 2) length=sum(pCount)=1 (length is NOT 2)
#PE1 adds [sig22] acting as AS64510 #PE-1 adds the Secure_Path Segment in (**) acting as AS64510
#PE1 accepts [sig22] with pCount=0 acting as AS64500, #PE-1 accepts (**) with pCount=0 acting as AS64500,
#as it would if it received sig22 from an eBGP peer #as it would if it received (**) from an eBGP peer
#PE-1, as AS64500, sends the update including (**) to PE-2 (in iBGP)
PE-2 to 64505: sig(<64505>, 64500, pCount=1, <sig22>)K_64500-PE2 [sig23] PE-2 to 64505: sig(64505,...,(pCount=1,...,64500),...,N)K_64500-PE2
sig(<64500>, 64510, pCount=0, <sig21>)K_64510-PE1 [sig22] sig(64500,...,(pCount=0,...,64510),...,N)K_64510-PE1
sig(<64510>, 64496, pCount=1, N)K_64496-CE1 [sig21] sig(64510, (pCount=1,...,64496), N)K_64496-CE1
Equivalent AS_PATH=(64500,64496) Equivalent AS_PATH=(64500,64496)
Secure_Path=(64500,64510 (pCount=0), 64496) Securedpath=(64500,64510 (pCount=0), 64496)
length=sum(pCount)=2 (length is NOT 3) length=sum(pCount)=2 (length is NOT 3)
PE-2 to CE-2: sig(<64499>, 64500, pCount=1, <sig22>)K_64500-PE2 [sig24] PE-2 to CE-2: sig(64499,...,(pCount=1,...,64500),...,N)K_64500-PE2
sig(<64500>, 64510, pCount=0, <sig21>)K_64510-PE1 [sig22] sig(64500,...,(pCount=0,...,64510),...,N)K_64510-PE1
sig(<64510>, 64496, pCount=1, N)K_64496-CE1 [sig21] sig(64510, (pCount=1,...,64496), N)K_64496-CE1
Equivalent AS_PATH=(64500,64496) Equivalent AS_PATH=(64500,64496)
Secure_Path=(64500, 64510 (pCount=0), 64496) Securedpath=(64500, 64510 (pCount=0), 64496)
length=sum(pCount)=2 (length is NOT 3) length=sum(pCount)=2 (length is NOT 3)
6. IANA Considerations 6. IANA Considerations
This document does not require any IANA actions. This document does not require any IANA actions.
7. Security Considerations 7. Security Considerations
RFC 7705 [RFC7705] discusses a process by which one ASN is migrated RFC 7705 [RFC7705] discusses a process by which one ASN is migrated
into and subsumed by another. Because this process involves into and subsumed by another. Because this process involves
skipping to change at page 14, line 27 skipping to change at page 14, line 28
keys are permitted, this does potentially enable an AS_PATH keys are permitted, this does potentially enable an AS_PATH
shortening attack, but these are existing security risks for BGPsec. shortening attack, but these are existing security risks for BGPsec.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7705] George, W. and S. Amante, "Autonomous System Migration [RFC7705] George, W. and S. Amante, "Autonomous System Migration
Mechanisms and Their Effects on the BGP AS_PATH Mechanisms and Their Effects on the BGP AS_PATH
Attribute", RFC 7705, DOI 10.17487/RFC7705, November 2015, Attribute", RFC 7705, DOI 10.17487/RFC7705, November 2015,
<http://www.rfc-editor.org/info/rfc7705>. <https://www.rfc-editor.org/info/rfc7705>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <http://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol
Specification", RFC 8205, DOI 10.17487/RFC8205, June 2017. Specification", RFC 8205, DOI 10.17487/RFC8205, June 2017.
8.2. Informative References 8.2. Informative References
[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation,
selection, and registration of an Autonomous System (AS)", selection, and registration of an Autonomous System (AS)",
BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996, BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996,
<http://www.rfc-editor.org/info/rfc1930>. <https://www.rfc-editor.org/info/rfc1930>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<http://www.rfc-editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
[RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous
System Confederations for BGP", RFC 5065, System Confederations for BGP", RFC 5065,
DOI 10.17487/RFC5065, August 2007, DOI 10.17487/RFC5065, August 2007,
<http://www.rfc-editor.org/info/rfc5065>. <https://www.rfc-editor.org/info/rfc5065>.
[RFC5398] Huston, G., "Autonomous System (AS) Number Reservation for [RFC5398] Huston, G., "Autonomous System (AS) Number Reservation for
Documentation Use", RFC 5398, DOI 10.17487/RFC5398, Documentation Use", RFC 5398, DOI 10.17487/RFC5398,
December 2008, <http://www.rfc-editor.org/info/rfc5398>. December 2008, <https://www.rfc-editor.org/info/rfc5398>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <http://www.rfc-editor.org/info/rfc6480>. February 2012, <https://www.rfc-editor.org/info/rfc6480>.
Acknowledgements Acknowledgements
Thanks to Kotikalapudi Sriram, Shane Amante, Warren Kumari, Terry Thanks to Kotikalapudi Sriram, Shane Amante, Warren Kumari, Terry
Manderson, Keyur Patel, Alia Atlas, and Alvaro Retana for their Manderson, Keyur Patel, Alia Atlas, and Alvaro Retana for their
review comments. review comments.
The authors particularly wish to acknowledge Kotikalapudi Sriram,
Oliver Borchert, and Michael Baer for their review and suggestions
for the examples in Section 5.4, which made an important contribution
to the quality of the text.
Additionally, the solution presented in this document is an amalgam Additionally, the solution presented in this document is an amalgam
of several Secure Inter-Domain Routing (SIDR) interim meeting of several Secure Inter-Domain Routing (SIDR) interim meeting
discussions plus a discussion at IETF 85, collected and articulated discussions plus a discussion at IETF 85, collected and articulated
thanks to Sandy Murphy. thanks to Sandy Murphy.
Authors' Addresses Authors' Addresses
Wesley George Wesley George
Neustar
45980 Center Oak Plaza
Sterling, VA 20166
United States of America
Email: wesgeorge@puck.nether.net Email: wesgeorge@puck.nether.net
Sandy Murphy Sandy Murphy
SPARTA, Inc., a Parsons Company SPARTA, Inc., a Parsons Company
7110 Samuel Morse Drive 7110 Samuel Morse Drive
Columbia, MD 21046 Columbia, MD 21046
United States United States of America
Phone: +1 443-430-8000 Phone: +1 443-430-8000
Email: sandy@tislabs.com Email: sandy@tislabs.com
 End of changes. 60 change blocks. 
156 lines changed or deleted 169 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/