BGPSec Considerations for AS Migration
draft-george-sidr-as-migration-00

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]