GROW                                                        D. McPherson
Internet-Draft                                            Verisign, Inc.
Intended status: Informational                                 S. Amante
Expires: November 4, 2013 February 2, 2014                   Level 3 Communications, Inc.
                                                            E. Osterweil
                                                          Verisign, Inc.
                                                             D. Mitchell
                                                           Twitter, Inc.
                                                             May 3,
                                                          August 1, 2013

               Route Leaks

               Route-Leaks & MITM Attacks Against BGPSEC
          draft-ietf-grow-simple-leak-attack-bgpsec-no-help-01
          draft-ietf-grow-simple-leak-attack-bgpsec-no-help-02

Abstract

   This document describes a very simple attack vector that illustrates
   how RPKI-enabled BGPSEC machinery as currently defined can be easily
   circumvented in order to launch a Man In The Middle (MITM) attack via
   BGP.  It is meant to serve as input to the IETF's Secure Inter-Domain Global Routing working
   Operations Working group (GROW) during routing security requirements
   discussions and subsequent specification.

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 November 4, 2013. February 2, 2014.

Copyright Notice

   Copyright (c) 2013 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5 6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6
   6.  Informative References  . . . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6 7

1.  Introduction

   This document describes a very simple attack vector that illustrates
   how RPKI-enabled BGPSEC [I-D.ietf-sidr-bgpsec-protocol] machinery, as
   currently defined, can be easily circumvented in order to launch a
   Man In The Middle (MITM) attack via BGP [RFC4271].  It is meant to
   serve as input to the IETF's SIDR Global Routing Operations Working Group
   (GROW) during routing security requirements discussions and
   subsequent specification.

   This draft shows evidence that the attack vector described herein is
   extremely common, with over 9.6 million candidate instances being
   recorded since 2007.  As a result of this evidence (and and additional
   contextual knowledge), knowledge, the authors believe the capability to prevent
   leaks and MITM leak-attacks should be a first-order primary engineering objective
   in any secure routing architecture.

   While the formal definition of a route leak 'route-leak' has proven elusive in the
   literature, their the rampant occurrence and persistent operational threats
   have proven to be anything but elusive. uncommon.  This document is intended
   to serve as an existence a proof of existence for this the referenced attack vector, vector and
   any supplementary formal models are left for future work.

2.  Discussion

   In order to understand how a MITM attack Man In the Middle (MITM) Attack can be launched with
   conducted using this attack vector, assume refer to the below example.

   Assume a multi-homed Autonomous System (AS), AS1, connects to two
   ISPs (ISP1 & ISP2), and ISP2) and wishes to insert themselves in the data-path
   between a target network (prefix P) connected to ISP2 and systems in
   ISP1's network in order to launch a Man In The
   Middle (MITM) proceed with an MITM attack.  Further, assume

   Assume that an RPKI-enabled BGPSEC deployment
   [I-D.ietf-sidr-bgpsec-protocol] as currently defined is fully
   deployed currently operational by all
   parties in this the scenario and functioning as designed.

                +------+   peer   +------+
                | ISP1 | <------> | ISP2 |_
                +------+          +------   \
                     \            /    (  P  )  )--1.1.1.0/24
                      \ customer /      \___/
                       +-----+
                       \        /
                       +-------+
                       |  AS1  |
                       +-----+
                       +-------+

   This figure depicts a multi-homed AS, AS1, who that is a customer
   connected to two upstream ISPs (ISP1 and ISP2).  ISP2 has a second
   customer, P, that is assigned prefix 1.1.1.0/24.

   Network operators on the Internet today typically prefer customer
   routes over routes learned from bi-lateral or settlement free peers.
   Network operators commonly accomplish this via application of one or
   more BGP [RFC4271] Path Attributes, most commonly, LOCAL_PREF as
   illustrated in [RFC1998], that are evaluated earlier in the BGP Path
   Selection process than AS_PATH length.

   As currently defined, [I-D.ietf-sidr-bgpsec-protocol] only provides
   two functions: methods for validating an announced NLRI:

   1.  Is an the Autonomous System authorized to originate an IP prefix?
   2.  Is the AS_PATH (or any similarly derived attribute such as
       BGPSEC_Path) in the route the same as the list of ASes through
       which the NLRI traveled?

   In order for an attacker (AS1) to divert traffic from ISP1 for toward
   prefix P through their AS they AS, AS1 must simply fail to scope the
   propagation of the target prefix P (received (1.1.1.0/24), received from ISP2) ISP2.
   This is completed by announcing a (syntactically
   correct) syntactically correct BGPSEC update
   for prefix P to ISP1.

   This vulnerability is what the authors refer to as a 'route leak' 'route-leak' or a 'leak-attack' (when
   'leak-attack', respectively, when intent aligns with actions). actions.  It is
   important to note that the default behavior in BGP [RFC4271] is to
   announce all best paths to external BGP peers, unless explicitly scoped
   configured otherwise by a BGP speaker through
   configuration. speaker.  Because ISP1 prefers prefixes
   learned from customers (AS1) over prefixes learned from peers (ISP2), they begin
   ISP1 begins forwarding traffic for prefix P destinations through the attacker's AS (AS1).
   Voila! attacker
   (AS1), thus successfully completing the route hijack.

   It is important to note that the route leaks route-leaks described herein are NOT
   'misorginiations.'  Rather, these not
   illegal NLRI origins.  These are cases in which routes are propagated
   with their an authentic origins, but are misdirected origin AS, as per [RFC6480].  Furthermore, the
   BGPSEC route for prefix P is propagated through intermediate ASN's,
   in this case AS1, that each applies a valid BGPSEC_Path attribute to
   the route.  Ultimately, ISP1 receives two, valid BGPSEC routes for
   prefix P, (one directly from ISP2 and one directly from AS1);
   however, due to the local policy implemented within ISP1, it prefers
   the customer route, due to higher LOCAL_PREF, received from customer
   AS1.  This will cause ISP1 to misdirect packets through
   unexpected intermediaries. a invalid
   intermediate ASN, AS1, to reach prefix P.

   It should be understood that any multi-homed AS can potentially
   launch such an attack, even if through simple misconfiguration, as which
   is a common occurrence today on the Internet.  As a matter of fact,
   advertising these prefixes is the default behavior is of many BGP
   implementations,
   implementations and explicit action must be taken to not advertise
   all prefixes learned in BGP.

   Such occurrences have been historically archived [ROUTE_LEAK_DETECTION_TOOL] and presented to the
   operational community [NANOG_LEAK_TALK] since 2007. 2007 [NANOG_LEAK_TALK].  To date, over
   9.6 million such events have been recorded and are queriable within the
   [ROUTE_LEAK_DETECTION_TOOL].  This corpus

   Said dataset serves as a low pass
   filter, basis for analysis and likely contains some a
   degree of false positives.  Thus,  Even while some may debate how many of
   the occurrences incidents were malicious, or
   how many were actually real leaks, the corpus itself (and its sheer
   size) serves as malicious route-leaks versus accidental
   misconfiguration that resulted in leaked routes, the size of the
   dataset provides evidence of the large magnitude of this problem. the issue.

   Determination of benign versus malicious intent in these situations is usually imperceptible, difficult to ascertain
   and as such, requires preventative controls are
   requisite.

   To be put in place to mitigate
   occurrences of route-leaks.  In order to illustrate the above point, difficulty in
   determining intent, consider the events that transpired on November
   6th, 2012 [LEAK_ATTACK_ON_GOOGLE].  On that day a large

   Google is the largest Internet property (who services hundreds of site and processes billions of public end end-
   user transactions every day) per day.  It became unreachable for roughly approximately
   27 minutes.  At a transaction volume like that, their scale, an outage of 27 minutes is a very extremely
   visible (and likely and, most likely, a financially measurable) measurable event.  In this
   case,
   example, its services became unreachable because a peered AS BGP peer
   improperly propagated the impacted party's AS' prefix(s).  In leaks such as
   this, company's prefixes.  Because this was a
   highly visible outage, there exists a public acknowledgment of
   improper intent executed by the impacted party one of Google's peers, proving that
   [RFC6480] and [I-D.ietf-sidr-bgpsec-protocol] would be unable to
   detect or remediate prevent this type of attack.

   In an environment where [I-D.ietf-sidr-bgpsec-protocol] is fully
   deployed, it is expected that there would be high substantial assurances that
   guard
   as to the syntactic semantic integrity of the AS_PATH (or BGPSEC_Path) or BGPSEC_Path attribute.  As such, one
   An operator would expect that such an attribute would,
   indeed, would accurately
   reflect the attacker's AS number ASN in the appropriate location of the AS_PATH; however, it would not prevent
   BGPSEC_Path.  Unfortunately, as currently designed,
   [I-D.ietf-sidr-bgpsec-protocol] is unable to distinguish whether an
   attacker from inserting his AS in
   ASN is allowed, by policy, to add their ASN within the first place.  That is, nothing BGPSEC_Path
   attribute before the BGP update is propagated to downstream ASNs.
   This proves that mechanisms defined in
   [I-D.ietf-sidr-bgpsec-protocol] would not stop an attacker from
   launching
   completing this type of leak-attack. attack.

   Discussion of out of band methods to mitigate this attack are
   important but
   important; albeit beyond the scope of this document, as its objective document.  This document
   is meant to inform provide input into routing protocol design choices currently being
   considered within the IETF's SIDR Working Group. IETF, and to foster discussion of the practical
   implications of "policy" and "intent" in operational routing system
   security.

3.  Acknowledgements

4.  IANA Considerations

   There are no actions for IANA in the document.

5.  Security Considerations

   This document describes an attack on an RPKI-enabled BGPSEC and is
   meant to inform the IETF Secure Inter-Domain Routing working group on
   the vulnerability community that this vulnerability exists as
   a result of "leaks" route-leaks and attacks that conform to this type of behavior.
   behavior, and that operators should not assume that that work items
   and designs address these operational security issues.

   The authors believe the capability to prevent leaks route-leaks and leak-attacks leak-
   attacks should be a first-order primary engineering objective in any secure
   routing architecture.

6.  Informative References

   [I-D.ietf-sidr-bgpsec-protocol]
              Lepinski, M., "BGPSEC Protocol Specification",
              February 2013.

   [LEAK_ATTACK_ON_GOOGLE]
              CloudFlare, CF., "Why Google Went Offline Today and a Bit
              about How the Internet Works", November 2012, <http://
              blog.cloudflare.com/
              why-google-went-offline-today-and-a-bit-about>.

   [NANOG_LEAK_TALK]
              Mauch, J., "Detecting Routing Leaks by Counting",
              October 2007, <http://www.nanog.org/meetings/nanog41/
              presentations/mauch-lightning.pdf>.

   [RFC1998]  Chen, E. and T. Bates, "An Application of the BGP
              Community Attribute in Multi-home Routing", RFC 1998,
              August 1996.

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.

   [RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
              Secure Internet Routing", RFC 6480, February 2012.

   [ROUTE_LEAK_DETECTION_TOOL]
              Mauch, J., "BGP Routing Leak Detection System Routing Leak
              Detection System", September 2007,
              <http://puck.nether.net/bgp/leakinfo.cgi>.

Authors' Addresses

   Danny McPherson
   Verisign, Inc.
   12061 Bluemont Way
   Reston, VA  20190
   USA

   Phone: +1 703.948.3200
   Email: dmcpherson@verisign.com

   Shane Amante
   Level 3 Communications, Inc.
   1025 Eldorado Boulevard
   Broomfield, CO  80021
   US

   Phone: +1 720.888.1000
   Email: shane@level3.net

   Eric Osterweil
   Verisign, Inc.
   12061 Bluemont Way
   Reston, VA  20190
   USA

   Phone: +1 703.948.3200
   Email: eosterweil@verisign.com
   Dave Mitchell
   Twitter, Inc.
   1355 Market Street, Suite 900
   San Francisco, CA  94103
   USA

   Email: dave@twitter.com