Internet Engineering Task Force W. George
Internet-Draft Time Warner Cable
Intended status: Informational September 24, 2012
Expires: March 28, 2013
BGPSec Considerations for AS Migration
draft-george-sidr-as-migration-00
Abstract
This draft discusses considerations for supporting and securing a
common method for AS-Migration within the BGPSec protocol.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 28, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
George Expires March 28, 2013 [Page 1]
Internet-Draft as-migration September 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
2. General Scenario . . . . . . . . . . . . . . . . . . . . . . . 3
3. RPKI Considerations . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Origin Validation . . . . . . . . . . . . . . . . . . . . . 4
3.2. Path Validation . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Outbound announcements (PE-->CE) . . . . . . . . . . . 5
3.2.2. Inbound announcements (CE-->PE) . . . . . . . . . . . . 6
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
George Expires March 28, 2013 [Page 2]
Internet-Draft as-migration September 2012
1. Introduction
There is a common method of managing an ASN migration using some BGP
knobs that while commonly-used are not formally part of the BGP4
[RFC4271] 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 defined in
draft-ga-idr-as-migration [I-D.ga-idr-as-migration]. Accordingly, it
is necessary to discuss this de facto standard to ensure that the
process and features are properly supported in BGPSec
[I-D.ietf-sidr-bgpsec-protocol], because it 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.
1.1. Requirements Language
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 RFC 2119 [RFC2119].
2. General Scenario
The use case being discussed in draft-ga-idr-as-migration
[I-D.ga-idr-as-migration] 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 RFC 5065
[RFC5065] are *not* being implemented between the ASNs, but vendor-
specific configuration knobs are being used to masquerade as the old
ASN for the PE-CE eBGP session, or to manipulate the AS_PATH, or
both. While BGPSec [I-D.ietf-sidr-bgpsec-protocol] does have a case
to handle standard confederation implementations, it may not be
applicable in this exact case. The reason that this may drive a
slightly different solution in BGPSec than 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 updates before propagating the
route to its eBGP neighbors.
In the following examples, AS200 is being subsumed by AS300, and both
ASNs represent an SP network. AS100 and 400 represent end customer
networks.
George Expires March 28, 2013 [Page 3]
Internet-Draft as-migration September 2012
3. RPKI Considerations
Since the methods and implementation discussed in
draft-ga-idr-as-migration [I-D.ga-idr-as-migration] are not
technically a part of the BGP4 protocol implementation, but rather a
vendor-specific optimization, BGPSec is not technically required to
ensure that it continues functioning as it does today. However, this
is widely used during network integrations resulting from mergers and
acquisitions, as well as network redesigns, and therefore it is not
feasible to simply eliminate 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 RPKI validation
might interact.
Additionally, companies rarely stop with 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 like a key roll. This
leaves many SPs with multiple legacy ASNs which don't go completely
and cleanly away very quickly, if at all. As solutions are 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 to be carefully considered. While part of the
recommendation may be "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 needs to be made to allow
the transition period to be less onerous, on the assumption that it
will likely be protracted.
3.1. Origin Validation
In the scenario discussed, AS200 is being replaced by AS300. If
there are any existing routes originated by AS200 on the router being
moved into the new ASN, this is likely as simple as generating new
ROAs for the routes with the new ASN and treating them as new routes
to be added to AS300/removed from AS200. However, consider the
situation where one or more PEs are still in AS200, and are
originating one or more routes. When those routes arrive at PE1,
which is now a part of AS300 and instructed to use replace-as to
remove AS200 from the path, how does it handle routes originated from
AS200? If the route now shows up as originating from AS300, any
downstream peers' validation check will fail unless a ROA is *also*
available for AS300 as the origin ASN, meaning that there will be
George Expires March 28, 2013 [Page 4]
Internet-Draft as-migration September 2012
overlapping ROAs until all routers originating prefixes from AS200
are migrated to AS300.
[AUTHOR's NOTE, remove before publishing: may need a citation to the
specific text in the Origin validation spec RFC 6480 [RFC6480] or
related documents that allows an overlap period on ROAs for
transitions like this. also may need to rewrite this as a procedure
in RFC2119 language, rather than a discussion. END NOTE]
3.2. Path Validation
BGPSec Path Validation requires that each router in the AS_PATH
cryptographically sign its update to assert that "Every AS listed in
the AS_PATH attribute of the update explicitly authorized the
advertisement of the route to the subsequent AS in the AS_PATH."
Since this 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.
3.2.1. Outbound announcements (PE-->CE)
When PE1 is moved from AS200 to AS300, it will be provisioned with
the appropriate keys for AS300 so that it can begin forward-signing
routes using AS300. 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 200", the
presence of "local-as 200" 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 AS300, should the
BGPSec validator on CE1 still consider those valid by default? If it
does, is there any potential attack vector to consider?
If enabling strict validation that remote-AS and forward-signed-AS
match is desirable, a possible alternative would be to retain the
keys for AS200 on PE1, and forward-sign towards CE1 with AS200 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
permit PCount=0 announcements only on the sessions where they are
George Expires March 28, 2013 [Page 5]
Internet-Draft as-migration September 2012
expected, and otherwise reject them. 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 may not be a workable solution.
3.2.2. Inbound announcements (CE-->PE)
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 AS200,
not AS300. The BGPSec speaker cannot [MUST NOT??] 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 200 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 as previously stated is undesirable. More
discussion is needed to determine possible solutions that enable this
transition without defeating the added security that BGPSec provides.
4. Requirements
PLACEHOLDER for a set of requirements, defining what SIDR Origin
Validation/BGPSEC <RFC2119-word> do to enable this migration strategy
to work securely. Need input from WG as to how to proceed.
Options:
1. Add implementation considerations and/or protocol changes to
support AS-Migration into the BGPSec protocol doc or another
existing BGPSec document
2. Use this draft to document how BGPSec and Origin Validation will
need to handle the AS-migration procedure (move to PS status?),
possibly as an update to the BGPSec protocol document
3. Explicitly prohibit/deprecate this process for AS-Migration (a la
AS_Sets) as something that cannot be properly secured within
BGPSec
4. define a new/updated/improved standard method for asymmetric ASN
migrations which is explicitly designed to operate within the
bounds of BGPSec (instead of trying to make the existing
implementations work with no changes) - probably in IDR
George Expires March 28, 2013 [Page 6]
Internet-Draft as-migration September 2012
The author does not believe that option #3 is the correct course of
action because this is in wide use among operators today, and no
acceptable alternative exists to make the act of merging ASNs less
onerous.
5. Acknowledgements
Thanks to Kotikalapudi Sriram and Shane Amante for their comments.
6. IANA Considerations
This memo includes no request to IANA.
7. Security Considerations
This draft discusses a process by which one ASN is migrated into and
subsumed by another. Because this involves manipulating the AS_Path
to make it deviate from the actual path that it took through the
network, it is in some ways attempting to do exactly what BGPSec is
working to prevent. The BGPSec implementation MUST be able to manage
this legitimate use of AS_Path manipulation without generating a
vulnerability in the RPKI route security infrastructure that can be
exploited by a malicious actor.
8. References
8.1. Normative References
[I-D.ga-idr-as-migration]
George, W. and S. Amante, "Autonomous System (AS)
Migration Features and Their Effects on the BGP AS_PATH
Attribute", draft-ga-idr-as-migration-00 (work in
progress), September 2012.
[I-D.ietf-sidr-bgpsec-protocol]
Lepinski, M., "BGPSEC Protocol Specification",
draft-ietf-sidr-bgpsec-protocol-05 (work in progress),
September 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
George Expires March 28, 2013 [Page 7]
Internet-Draft as-migration September 2012
8.2. Informative References
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous
System Confederations for BGP", RFC 5065, August 2007.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, February 2012.
Author's Address
Wesley George
Time Warner Cable
13820 Sunrise Valley Drive
Herndon, VA 20171
US
Phone: +1 703-561-2540
Email: wesley.george@twcable.com
George Expires March 28, 2013 [Page 8]