One document matched: draft-ietf-sidr-as-migration-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC1930 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1930.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4271 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml">
<!ENTITY RFC5065 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5065.xml">
<!ENTITY RFC5398 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5398.xml">
<!ENTITY RFC6480 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6480.xml">
<!ENTITY I-D.ietf-sidr-bgpsec-protocol SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sidr-bgpsec-protocol.xml">
<!ENTITY I-D.ietf-idr-as-migration SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-as-migration.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-sidr-as-migration-04"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="BGPSec-as-migration">BGPSec Considerations for AS
Migration</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Wesley George" initials="W" surname="George">
<organization>Time Warner Cable</organization>
<address>
<postal>
<street>13820 Sunrise Valley Drive</street>
<!-- Reorder these if your country does things differently -->
<city>Herndon</city>
<region>VA</region>
<code>20171</code>
<country>US</country>
</postal>
<phone>+1 703-561-2540</phone>
<email>wesley.george@twcable.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Sandy Murphy" initials="S" surname="Murphy">
<organization>SPARTA, Inc., a Parsons Company</organization>
<address>
<postal>
<street>7110 Samuel Morse Drive</street>
<!-- Reorder these if your country does things differently -->
<city>Columbia</city>
<region>MD</region>
<code>21046</code>
<country>US</country>
</postal>
<phone>+1 443-430-8000</phone>
<email>sandy@tislabs.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date day="" month="" year=""/>
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Routing</area>
<workgroup>SIDR</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>as-migration, SIDR, BGPSec, AS_PATH</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This document discusses considerations and methods for supporting and
securing a common method for AS-Migration within the BGPSec
protocol.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>A method of managing a BGP Autonomous System Number (ASN) migration
was just recently described in <xref
target="I-D.ietf-idr-as-migration">draft-ietf-idr-as-migration</xref>.
Since it concerns the handling of AS_PATH attributes, it is necessary to
ensure that the process and features are properly supported in <xref
target="I-D.ietf-sidr-bgpsec-protocol">BGPSec</xref>, because BGPSec is
explicitly designed to protect against changes in the BGP AS_PATH,
whether by choice, by misconfiguration, or by malicious intent. It is
critical that the BGPSec protocol framework is able to support this
operationally necessary tool without creating an unacceptable security
risk or exploit in the process.</t>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
<section title="Documentation note">
<t>This document uses Autonomous System Numbers (ASNs) from the range
reserved for documentation as described in <xref target="RFC5398">RFC
5398</xref>. In the examples used here, they are intended to represent
Globally Unique ASNs, not private ASNs as documented in <xref
target="RFC1930">RFC 1930</xref> section 10.</t>
</section>
</section>
<section title="General Scenario">
<t>This document assumes that the reader has read and understood the ASN
migration method discussed in <xref
target="I-D.ietf-idr-as-migration">draft-ietf-idr-as-migration</xref>
including its examples (see section 2 of the referenced document), as
they will be heavily referenced here. The use case being discussed in
the referenced document is as follows: For whatever the reason, a
provider is in the process of merging two or more ASNs, where eventually
one subsumes the other(s). BGP AS Confederations <xref
target="RFC5065">RFC 5065</xref> is not enabled between the ASNs, but
configuration knobs are being used to modify BGP's default behavior and
allow the migrating Provider Edge router (PE) to masquerade as the old
ASN for the Provider Edge to Customer Edge (PE-CE) eBGP session, or to
manipulate the AS_PATH, or both. While <xref
target="I-D.ietf-sidr-bgpsec-protocol">BGPSec</xref> does have a method
to handle standard confederation implementations, it is not applicable
in this exact case. The reason that this migration requires a slightly
different solution in BGPSec than for a standard confederation is that
unlike in a confederation, eBGP peers may not be peering with the
"correct" external ASN, and the forward-signed updates are for a public
ASN, rather than a private one, so there is no expectation that the BGP
speaker would strip the affected signatures before propagating the route
to its eBGP neighbors.</t>
<t>In the following examples <xref target="Example">(section
5.4)</xref>, AS64510 is being subsumed by AS64500, and both ASNs
represent a Service Provider (SP) network (see Figures 1 & 2 in
<xref
target="I-D.ietf-idr-as-migration">draft-ietf-idr-as-migration</xref>).
AS64496 and 64499 represent end customer networks. References to PE, CE,
and P routers mirror the diagrams and references in the above cited
draft.</t>
</section>
<section title="RPKI Considerations">
<t>The methods and implementation discussed in <xref
target="I-D.ietf-idr-as-migration">draft-ietf-idr-as-migration</xref>
are widely used during network integrations resulting from mergers and
acquisitions, as well as network redesigns, and therefore it is
necessary to support this capability on any BGPSec-enabled routers/ASNs.
What follows is a discussion of the potential issues to be considered
regarding how ASN-migration and BGPSec <xref
target="I-D.ietf-sidr-bgpsec-protocol"/> validation might interact.</t>
<t>One of the primary considerations for this document and migration is
that service providers (SPs) rarely stop after one
merger/acquisition/divestiture, and end up accumulating several legacy
ASNs over time. Since they are using methods to migrate that do not
require coordination with customers, they do not have a great deal of
control over the length of the transition period as they might with
something completely under their administrative control (e.g. a key
roll). This leaves many SPs with multiple legacy ASNs which don't go
away very quickly, if at all. As solutions were being proposed for RPKI
implementations to solve this transition case, operational complexity
and hardware scaling considerations associated with maintaining multiple
legacy ASN keys on routers throughout the combined network have been
carefully considered. While SPs SHOULD NOT remain in this transition
phase indefinitely because of the operational complexity and scaling
considerations associated with maintaining multiple legacy ASN keys on
routers throughout the combined network, this is of limited utility as a
solution, and so every effort has been made to keep the additional
complexity during the transition period to a minimum, on the assumption
that it will likely be protracted. Note: While this document primarily
discusses service provider considerations, it is not solely applicable
to SPs, as enterprises often migrate between ASNs using the same
functionality.</t>
<section title="Origin Validation">
<t>Route Origin Validation as defined by <xref target="RFC6480">RFC
6480</xref> does not need a unique solution to enable migration, as
the existing protocol and procedure allows for a solution. In the
scenario discussed, AS64510 is being replaced by AS64500. If there are
any existing routes originated by AS64510 on the router being moved
into the new ASN, this simply requires generating new ROAs for the
routes with the new ASN and treating them as new routes to be added to
AS64500. However, we also need 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 from any that the router under migration
is originating. PE1 (which is now a part of AS64500 and instructed to
use replace-as as defined in <xref target="RFC6480">RFC 6480</xref> to
remove AS64510 from the path) needs to be able to properly handle
routes originated from AS64510. If the route now shows up as
originating from AS64500, any downstream peers' validation check will
fail unless a ROA is *also* available for 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 necessary to generate ROAs for
65400 for prefixes that are originating on routers still in 65410,
since the AS replacement function will change the origin AS in some
cases. This means that there will be multiple ROAs showing different
ASes authorized to orignate the same prefixes until all routers
originating prefixes from AS64510 are migrated to AS64500. Multiple
ROAs of this type are permissible per <xref target="RFC6480">RFC
6480</xref> section 3.2, and so managing origin validation during a
migration like this is merely applying the defined case where a set of
prefixes are originated from more than one ASN. Therefore, for each
ROA that authorizes AS64510 to originate a prefix, a new ROA MUST also
be created that authorizes AS64500 to originate the same prefix.</t>
</section>
<section title="Path Validation">
<t>BGPSec Path Validation requires that each router in the AS Path
cryptographically sign its update to assert that "Every AS on the path
of ASes listed in the update message has explicitly authorized the
advertisement of the route to the subsequent AS in the path." (see
intro of <xref target="I-D.ietf-sidr-bgpsec-protocol"/>) Since the
referenced AS migration technique is explicitly modifying the AS_PATH
between two eBGP peers who are not coordinating with one another (are
not in the same administrative domain), no level of trust can be
assumed, and therefore it may be difficult to identify legitimate
manipulation of the AS_PATH for migration activities when compared to
manipulation due to misconfiguration or malicious intent.</t>
<section title="Outbound announcements (PE-->CE)">
<t>When PE1 is moved from AS64510 to AS64500, it will be provisioned
with the appropriate keys for AS64500 to allow it to forward-sign
routes using AS64500. However, there is currently no guidance in the
<xref target="I-D.ietf-sidr-bgpsec-protocol">BGPSec protocol
specification</xref> on whether or not the forward-signed ASN value
MUST match the configured remote AS to validate 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 there is no ASN
mismatch on the BGP session itself, but if CE1 receives updates from
its remote neighbor (PE1) forward-signed from AS64500, there is no
guidance as to whether the BGPSec validator on CE1 still considers
those valid by default. <xref target="RFC4271">RFC4271</xref>
section 6.3 mentions this match between the ASN of the peer and the
AS_PATH data, but it is listed as an optional validation, rather
than a requirement. Assuming that this mismatch will be allowed by
vendor implementations and using it as a means to solve this
migration case is likely to be problematic.</t>
</section>
<section title="Inbound announcements (CE-->PE)">
<t>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
AS64510, not AS64500. The BGPSec speaker cannot manipulate previous
signatures, and therefore cannot manipulate the previous AS Path
without causing a mismatch that will invalidate the route. If the
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
appear in the BGPSec_Path_Signature in order that receivers can
validate the BGPSEC_Path_Signature arrived intact/whole. However, if
the updates are left intact, this will cause the AS Path length to
be increased, which is undesirable as discussed in <xref
target="I-D.ietf-idr-as-migration">draft-ietf-idr-as-migration</xref>.</t>
</section>
</section>
</section>
<section title="Requirements">
<t>In order to be deployable, any solution to the described problem
needs to consider the following requirements, listed in no particular
order:</t>
<t><list style="symbols">
<t>BGPSec MUST support AS Migration for both inbound and outbound
route announcements (see Section 3.2.1 and 3.2.2). It SHOULD do this
without reducing BGPSec's protections for route path</t>
<t>MUST NOT require any reconfiguration on the remote eBGP neighbor
(CE)</t>
<t>SHOULD confine configuration changes to the migrating PEs e.g.
can't require global configuration changes to support migration</t>
<t>MUST NOT lengthen AS Path during migration</t>
<t>MUST operate within existing trust boundaries e.g. can’t
expect remote side to accept pCount=0 (see Section 3 of <xref
target="I-D.ietf-sidr-bgpsec-protocol"/>) from untrusted/non-confed
neighbor</t>
</list></t>
</section>
<!-- This PI places the pagebreak correctly (before the section title) in the text output -->
<?rfc needLines="8" ?>
<section anchor="Solution" title="Solution">
<t>As noted in <xref target="I-D.ietf-sidr-bgpsec-protocol"/>, section
4.2, BGPSec already has a solution for hiding ASNs where increasing the
AS Path length is undesirable. So a simple solution would be to retain
the keys for AS64510 on PE1, and forward-sign towards CE1 with AS64510
and pCount=0. However, this would mean passing a pCount=0 between two
ASNs that are in different administrative and trust domains such that it
could represent a significant attack vector to manipulate BGPSec-signed
paths. The expectation for legitimate instances of pCount=0 (to make a
route-server that is not part of the transit path invisible) is that
there is some sort of existing trust relationship between the operators
of the route-server and the downstream peers such that the peers could
be explicitly configured by policy to accept pCount=0 announcements only
on the sessions where they are expected. For the same reason that things
like <xref target="I-D.ietf-idr-as-migration">"Local AS"</xref> are used
for ASN migration without end customer coordination, it is unrealistic
to assume any sort of coordination between the SP and the administrators
of CE1 to ensure that they will by policy accept pCount=0 signatures
during the transition period, and therefore this is not a workable
solution.</t>
<t>A better solution presents itself when considering how to handle
routes coming from the CE toward the PE, where the routes are
forward-signed to AS64510, but will eventually need to show AS64500 in
the outbound route announcement. Because both AS64500 and AS64510 are in
the same administrative domain, a signature from AS64510 forward-signed
to AS64500 with pCount=0 would be acceptable as it would be within the
appropriate trust boundary so that each BGP speaker could be explicitly
configured to accept pCount=0 where appropriate between the two ASNs. At
the very simplest, this could potentially be used at the eBGP boundary
between the two ASNs during migration. Since the AS_PATH manipulation
described above usually happens at the PE router on a per-session basis,
and does not happen network-wide simultaneously, it is not generally
appropriate to apply this AS hiding technique across all routes
exchanged between the two ASNs, as it may result in routing loops and
other undesirable behavior. Therefore the most appropriate place to
implement this is on the local PE that still has eBGP sessions with
peers expecting to peer with AS64510 (using the transition knobs
detailed in <xref
target="I-D.ietf-idr-as-migration">draft-ietf-idr-as-migration</xref>).
Since that PE has been moved to AS64500, it is not possible for it to
forward-sign AS64510 with pCount=0 without some minor changes to the
BGPSec implementation to address this use case.</t>
<t>AS migration is using AS_PATH and remote AS manipulation to act as if
a PE under migration exists simultaneously in both ASNs even though it
is only configured with one global ASN. This document proposes applying
a similar technique to the BGPSec signatures generated for routing
updates processed through this migration machinery. Each 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 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 internal BGP hop and the
update was passed across an eBGP session between AS64500 and AS64510,
configured to use and accept pCount=0, while eliminating the processing
and storage overhead of creating an actual eBGP session between the two
ASNs within the PE router. This will result in a properly secured AS
Path in the affected route updates, because the PE router will be
provisioned with valid keys for both AS64500 and AS64510. An important
distinction here is that while AS migration under standard BGP4 is
manipulating the AS_PATH attribute, BGPSec uses an attribute called the
Secure_Path (see Section 3 of <xref
target="I-D.ietf-sidr-bgpsec-protocol"/>), and BGPSec capable neighbors
do not exchange AS_PATH information in their route announcements.
However, a BGPSec neighbor peering with a non-BGPSec-capable neighbor
will use the information found in Secure_Path to reconstruct a standard
AS_PATH for updates sent to that neighbor. Unlike in Secure_Path where
the ASN to be hidden is still present, but ignored when considering AS
Path (due to pCount=0), when reconstructing 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 the above-referenced draft). This document is not
changing existing AS_PATH reconstruction behavior, merely highlighting
it for clarity.</t>
<t>The procedure to support AS Migration in BGPSec is slightly different
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 destined toward
the eBGP peers ("outbound" as in section 3.2.1).</t>
<section title="Outbound (PE->CE)">
<t>When a PE router receives an update destined for an eBGP neighbor
that is locally configured with AS-migration knobs as discussed in
<xref
target="I-D.ietf-idr-as-migration">draft-ietf-idr-as-migration</xref>,
it MUST generate a valid BGPSec signature as defined in <xref
target="I-D.ietf-sidr-bgpsec-protocol"/> for _both_ configured ASNs.
It MUST 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 signature from the old (local) ASN to the target eBGP ASN with
pCount=1 as normal.</t>
</section>
<section title="Inbound (CE->PE)">
<t>When a PE router receives an update from an eBGP neighbor that is
locally configured with AS-migration knobs (i.e. the opposite
direction of the previous route flow), it MUST generate a signature
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
the new (global) ASN because the Autonomous System Border Router
(ASBR) will generate that when it forward signs towards its eBGP peers
as defined in normal BGPSec operation. Note that a signature is not
normally added when a routing update is sent across an iBGP session.
The requirement to sign updates in iBGP represents a change to the
normal behavior for this specific AS-migration implementation
only.</t>
</section>
<section title="Other considerations">
<t>In this case, the PE is adding BGPSec attributes to routes received
from or destined to an iBGP neighbor, and using pCount=0 to mask them.
While this is not prohibited by <xref
target="I-D.ietf-sidr-bgpsec-protocol">BGPSec</xref>, routers that
receive updates from iBGP neighbors MUST accept updates with new
(properly-formed) BGPSec attributes, including the presence of
pCount=0 on a previous signature, or they will interfere with this
implementation. In similar fashion, any route-reflectors in the path
of these updates MUST reflect them transparently to their clients.</t>
<t>In order to secure this set of signatures, the PE router MUST be
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 sessions
are migrated to the new ASN. Downstream neighbors will see this as a
valid BGPSec path, as they will simply trust that their upstream
neighbor accepted pCount=0 because it was explicitly configured to do
so based on a trust relationship and business relationship between the
upstream and its neighbor (the old and new ASNs).</t>
<t>Additionally, section 4 of <xref
target="I-D.ietf-idr-as-migration">draft-ietf-idr-as-migration</xref>
discusses methods in which AS migrations can be completed for iBGP
peers such that a session between two routers will be treated as iBGP
even if the neighbor ASN is not the same ASN on each peer's global
configuration. As far as BGPSec is concerned, this requires the same
procedure as when the routers migrating are applying AS migration
knobs to eBGP peers, but the router functioning as the "ASBR" between
old and new ASN is different. In eBGP, the router being migrated has
direct eBGP sessions to the old ASN and signs from old ASN to new with
pCount=0 before passing the update along to additional routers in its
global (new) ASN. In iBGP, the router being migrated is receiving
updates (that may have originated either from eBGP neighbors or other
iBGP neighbors) from its downstream neighbors in the old ASN, and MUST
sign those updates from old ASN to new with pCount=0 before sending
them on to other peers.</t>
</section>
<section anchor="Example" title="Example">
<t>The following example will illustrate the method being used above.
As with previous examples, PE1 is the router being migrated, AS64510
is the old AS, which is being subsumed by AS64500, the "keep" AS.
64505 is another external peer, used to demonstrate what the
announcements will look like to a third party peer that is not part of
the migration. Some additional notation is used to delineate the
details of each signature as follows:</t>
<t>The origin BGPSEC signature attribute takes the form:
sig(<Target ASN>, Origin ASN, pCount, NLRI Prefix) key</t>
<t>Intermediate BGPSEC signature attributes take the form:
sig(<Target ASN>, Signer ASN, pCount, <most recent sig
field>) key</t>
<t>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 Secure_Path
shows the AS Path as represented between BGPSec peers.</t>
<t>Note: The representation of signature attribute generation is being
simplified here somewhat for the sake of brevity; the actual details
of the signing process are as described Sections 4.1 and 4.2 in <xref
target="I-D.ietf-sidr-bgpsec-protocol"/>. For example, what is covered
by the signature also includes Flags, Algorithm Suite ID, NLRI length,
etc. Also, the key is not carried in the update, instead the SKI is
carried.</t>
<t><figure>
<preamble>Before Merger</preamble>
<artwork><![CDATA[ 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>, O=64499, pCount=1, N)K_64499-CE2 [sig1]
Equivalent AS_PATH=(64499)
Secure_Path=(64499)
length=sum(pCount)=1
PE-2 to 64505: sig(<64505>, 64500, pCount=1, <sig1>)K_64500-PE2 [sig2]
sig(<64500>, 64499, pCount=1, N)K_64499-CE2 [sig1]
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)
Secure_Path=(64500,64499)
length=sum(pCount)=2
PE-1 to CE-1: sig(<64496>, 64510, pCount=1, <sig3>)K_64510-PE1 [sig4]
sig(<64510>, 64500, pCount=1, <sig1>)K_64500-PE2 [sig3]
sig(<64500>, 64499, pCount=1, N)K_64499-CE2 [sig1]
Equivalent AS_PATH= (64510,64500,64499)
Secure_Path=(64510,64500,64499)
length=sum(pCount)=3]]></artwork>
</figure></t>
<t><figure>
<preamble>Migrating, route flow outbound PE-1 to CE-1</preamble>
<artwork><![CDATA[ 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]
sig(<64510>, 64500, pCount=0, <sig11>)K_64500-PE2 [sig13]
sig(<64500>, 64499, pCount=1, N)K_64499-CE2 [sig11]
Equivalent AS_PATH=(64510,64499)
Secure_Path=(64510, 64500(pCount=0),64499)
length=sum(pCount)=2 (length is NOT 3)
#PE1 adds [sig13] acting as AS64500
#PE1 accepts [sig13] with pCount=0 acting as AS64510,
#as it would if it received sig13 from an eBGP peer]]></artwork>
</figure></t>
<t><figure>
<preamble>Migrating, route flow inbound CE-1 to PE-1</preamble>
<artwork><![CDATA[ 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-1 to PE-1: sig(<64510>, 64496, pCount=1, N)K_64496-CE1 [sig21]
Equivalent AS_PATH=(64496)
Secure_Path=(64496)
length=sum(pCount)=1
PE-1 to PE-2: sig(<64500>, 64510, pCount=0, <sig21>)K_64510-PE1 [sig22]
sig(<64510>, 64496, pCount=1, N)K_64496-CE1 [sig21]
Equivalent AS_PATH=(64496)
Secure_Path=(64510 (pCount=0),64496)
length=sum(pCount)=1 (length is NOT 2)
#PE1 adds [sig22] acting as AS64510
#PE1 accepts [sig22] with pCount=0 acting as AS64500,
#as it would if it received sig22 from an eBGP peer
PE-2 to 64505: sig(<64505>, 64500, pCount=1, <sig22>)K_64500-PE2 [sig23]
sig(<64500>, 64510, pCount=0, <sig21>)K_64510-PE1 [sig22]
sig(<64510>, 64496, pCount=1, N)K_64496-CE1 [sig21]
Equivalent AS_PATH=(64500,64496)
Secure_Path=(64500,64510 (pCount=0), 64496)
length=sum(pCount)=2 (length is NOT 3)
PE-2 to CE-2: sig(<64499>, 64500, pCount=1, <sig22>)K_64500-PE2 [sig24]
sig(<64500>, 64510, pCount=0, <sig21>)K_64510-PE1 [sig22]
sig(<64510>, 64496, pCount=1, N)K_64496-CE1 [sig21]
Equivalent AS_PATH=(64500,64496)
Secure_Path=(64500, 64510 (pCount=0), 64496)
length=sum(pCount)=2 (length is NOT 3)]]></artwork>
</figure></t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Thanks to Kotikalapudi Sriram, Shane Amante, Warren Kumari, Terry
Manderson, Keyur Patel, Alia Atlas, and Alvaro Retana for their review
comments.</t>
<t>Additionally, the solution presented in this document is an amalgam
of several SIDR interim meeting discussions plus a discussion at IETF85,
collected and articulated thanks to Sandy Murphy.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document discusses a process by which one ASN is migrated into
and subsumed by another. Because this process involves manipulating the
AS_Path in a BGP route to make it deviate from the actual path that it
took through the network, this migration process is attempting to do
exactly what BGPSec is working to prevent. BGPSec MUST be able to manage
this legitimate use of AS_Path manipulation without generating a
vulnerability in the RPKI route security infrastructure.</t>
<t>The solution discussed above is considered to be reasonably secure
from exploitation by a malicious actor because it requires both
signatures to be secured as if they were forward-signed between two eBGP
neighbors. This requires any router using this solution to be
provisioned with valid keys for both the migrated and subsumed ASN so
that it can generate valid signatures for each of the two ASNs it is
adding to the path. If the AS's keys are compromised, or zero-length
keys are permitted, this does potentially enable an AS_PATH shortening
attack, but this is not fundamentally altering the existing security
risks for BGPSec.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
&I-D.ietf-sidr-bgpsec-protocol;
&I-D.ietf-idr-as-migration;
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC1930;
&RFC4271;
&RFC5065;
&RFC5398;
&RFC6480;
</references>
<!-- Change Log
v00 2006-03-15 EBD Initial version
v01 2006-04-03 EBD Moved PI location back to position 1 -
v3.1 of XMLmind is better with them at this location.
v02 2007-03-07 AH removed extraneous nested_list attribute,
other minor corrections
v03 2007-03-09 EBD Added comments on null IANA sections and fixed heading capitalization.
Modified comments around figure to reflect non-implementation of
figure indent control. Put in reference using anchor="DOMINATION".
Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH Major changes: shortened discussion of PIs,
added discussion of rfc include.
v05 2007-03-10 EBD Added preamble to C program example to tell about ABNF and alternative
images. Removed meta-characters from comments (causes problems). -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 15:52:51 |