Route-Leaks & MITM Attacks Against BGPSEC

In order to understand how a Man In the Middle (MITM) Attack can be conducted using this attack vector, refer to the below example. Assume a multi-homed Autonomous System (AS), AS1, connects to two ISPs (ISP1 and ISP2) and wishes to insert themselves in the data-path between target network (prefix P) connected to ISP2 and systems in ISP1's network in order to proceed with an MITM attack.

Assume that an RPKI-enabled BGPSEC deployment is currently operational by all parties in 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, 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 Path Attributes, most commonly, LOCAL_PREF as illustrated in , that are evaluated earlier in the BGP Path Selection process than AS_PATH length. As currently defined, only provides two methods for validating an announced NLRI: Is the Autonomous System authorized to originate an IP prefix? 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 toward prefix P through their AS, AS1 must simply fail to scope the propagation of the target prefix P (1.1.1.0/24), received from ISP2. This is completed by announcing a syntactically correct BGPSEC update for prefix P to ISP1. This vulnerability is what authors refer to as a 'route-leak' or 'leak-attack', respectively, when intent aligns with 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 configured otherwise by a BGP speaker. Because ISP1 prefers prefixes learned from customers (AS1) over prefixes learned from peers (ISP2), ISP1 begins forwarding traffic for prefix P through the attacker (AS1), thus successfully completing the route hijack. It is important to note that the route-leaks described herein are not illegal NLRI origins. These are cases in which routes are propagated with an authentic origin AS, as per . 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 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, which is a common occurrence on the Internet. As a matter of fact, advertising these prefixes is the default behavior of many BGP implementations and explicit action must be taken to not advertise all prefixes learned in BGP. Such occurrences have been historically archived and presented to the operational community since 2007 . To date, over 9.6 million such events have been recorded within the . Said dataset serves as a basis for analysis and likely contains a degree of false positives. Even while some may debate how many of the incidents were malicious route-leaks versus accidental misconfiguration that resulted in leaked routes, the size of the dataset provides evidence of the magnitude of the issue. Determination of intent in these situations is difficult to ascertain and requires preventative controls be put in place to mitigate occurrences of route-leaks. In order to illustrate the difficulty in determining intent, consider the events that transpired on November 6th, 2012 . Google is the largest Internet site and processes billions of end-user transactions per day. It became unreachable for approximately 27 minutes. At their scale, an outage of 27 minutes is extremely visible and, most likely, a financially measurable event. In this example, its services became unreachable because a BGP peer improperly propagated the company's prefixes. Because this was a highly visible outage, there exists a public acknowledgment of improper intent executed by one of Google's peers, proving that and would be unable to detect or prevent this type of attack. In an environment where is fully deployed, it is expected that there would be substantial assurances as to the semantic integrity of the AS_PATH or BGPSEC_Path attribute. An operator would expect that such an attribute would accurately reflect the attacker's ASN in the appropriate location of the BGPSEC_Path. Unfortunately, as currently designed, is unable to distinguish whether an ASN is allowed, by policy, to add their ASN within the BGPSEC_Path attribute before the BGP update is propagated to downstream ASNs. This proves that mechanisms defined in would not stop an attacker from completing this type of attack. It should be noted that the attack scenario described in this document can be mitigated by performing proper route filtering techniques. Discussion of out of band methods to mitigate this attack are important; albeit beyond the scope of this document. This document is meant to provide input into routing protocol design choices being considered within the IETF, and to foster discussion of the practical implications of "policy" and "intent" in operational routing system security.