One document matched: draft-ietf-sidr-as-migration-02.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-02"
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="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 draft 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>There is a method of managing an ASN migration using some BGP knobs
that, while commonly-used, are not formally part of the <xref
target="RFC4271">BGP4</xref> protocol specification and may be
vendor-specific in exact implementation. In order to ensure that this
behavior is understood and considered for future modifications to the
BGP4 protocol specification, especially as it concerns the handling of
AS_PATH attributes, the behavior and process has been described in <xref
target="I-D.ietf-idr-as-migration">draft-ietf-idr-as-migration</xref>.
Accordingly, it is necessary to discuss this de facto standard 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 draft 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 draft 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, as they will be heavily referenced here. The use
case being discussed in the referenced draft 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). Confederations <xref
target="RFC5065">RFC 5065</xref> are *not* being implemented between the
ASNs, but configuration knobs are being used to modify BGP's default
behavior and allow the migrating PE to masquerade as the old ASN for the
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 case 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 should strip the affected signatures before propagating the
route to its eBGP neighbors.</t>
<t>In the following examples, AS64510 is being subsumed by AS64500, and
both ASNs represent a Service Provider (SP) network (see Figure 1 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 a recent addition to the BGP4 protocol implementation, being
previously a vendor-specific feature. This feature is 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 draft and migration is
that companies 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.</t>
<section title="Origin Validation">
<t>Origin Validation 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 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, meaning that there will be
overlapping ROAs until all routers originating prefixes from AS64510
are migrated to AS64500. Overlapping ROAs 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 SHOULD 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 through which the update message passes has explicitly
authorized the advertisement of the route to the subsequent AS in the
path." (see point #2 in 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
BGPSec protocol specification 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 consider 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>These requirements are written under the assumption that the
currently vendor-specific implementations will be standardized via <xref
target="I-D.ietf-idr-as-migration">draft-ietf-idr-as-migration</xref>,
as it makes little sense to build support into a standard for something
that is not actually a standard itself. However, should IETF choose not
to standardize the discussed method of AS migration, it is possible that
this draft could be considered implementation guidance for those vendors
that have support for this method of AS migration and wish to support it
in their BGPSec implementation. 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 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 one might think that 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 local-as 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
associated with AS64510 (using the transition knobs detailed in the
companion draft). 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 draft 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 draft 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 ASBR will generate that when it
forward signs towards its eBGP peers as defined in normal BGPSec
operation. This is a deviation from standard BGPSec behavior in that
typically a signature is not added when a routing update is sent
across an iBGP session, and the next signature is added by the ASBR
when it forward-signs toward its eBGP peer as the routing update exits
the ASN.</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 the current BGPSec specification,
routers that receive updates from iBGP neighbors MUST NOT reject
updates with new (valid) 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>
</section>
<section 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, and Terry
Manderson for their review comments.</t>
<t>Additionally, the solution presented in this draft 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 draft 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;
&RFC5398;
&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;
&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:57:47 |