One document matched: draft-foo-sidr-simple-leak-attack-bgpsec-no-help-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1998 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1998.xml">
<!ENTITY RFC4271 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.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">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- used by XSLT processors -->
<?rfc strict="yes" ?> <!-- give errors regarding ID-nits and DTD validation -->
<?rfc toc="yes"?> <!-- generate a ToC -->
<?rfc tocdepth="2"?> <!-- the number of levels of subsections in ToC. default: 3 -->
<?rfc symrefs="yes"?> <!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?> <!-- sort the reference entries alphabetically -->
<?rfc compact="yes" ?> <!-- do not start each main section on a new page -->
<?rfc subcompact="yes" ?> <!-- keep one blank line between list items -->
<rfc category="info" docName="draft-foo-sidr-simple-leak-attack-bgpsec-no-help-02" ipr="trust200902">
<!-- end of popular PIs -->
<front>
<title>Route Leaks & MITM Attacks Against BGPSEC</title>
<author fullname="Danny McPherson" initials="D." surname="McPherson">
<organization>Verisign, Inc.</organization>
<address>
<postal>
<street>12061 Bluemont Way</street>
<city>Reston</city>
<region>VA</region>
<code>20190</code>
<country>USA</country>
</postal>
<phone>+1 703.948.3200</phone>
<email>dmcpherson@verisign.com</email>
<!-- <uri/> -->
</address>
</author>
<author fullname="Shane Amante" initials="S." surname="Amante">
<organization>Level 3 Communications, Inc.</organization>
<address>
<postal>
<street>1025 Eldorado Boulevard</street>
<city>Broomfield</city>
<region>CO</region>
<code>80021</code>
<country>US</country>
</postal>
<phone>+1 720.888.1000</phone>
<email>shane@level3.net</email>
<!-- <uri/> -->
</address>
</author>
<author fullname="Eric Osterweil" initials="E." surname="Osterweil">
<organization>Verisign, Inc.</organization>
<address>
<postal>
<street>12061 Bluemont Way</street>
<city>Reston</city>
<region>VA</region>
<code>20190</code>
<country>USA</country>
</postal>
<email>eosterweil@verisign.com</email>
</address>
</author>
<date year="2012" />
<area>RTG</area>
<workgroup>SIDR</workgroup>
<!-- <keyword/> -->
<!-- <keyword/> -->
<!-- <keyword/> -->
<!-- <keyword/> -->
<abstract>
<t> 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 Routing
working group during routing security requirements discussions
and subsequent specification.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This document describes a very simple attack vector that
illustrates how RPKI-enabled BGPSEC
<xref target="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 <xref target="RFC4271"/>.
It is meant to serve as input to the IETF's SIDR Working Group
during routing security requirements discussions and subsequent
specification.
</t>
<t>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 additional contextual knowledge),
the authors believe the capability to prevent leaks and
MITM leak-attacks should be a
first-order engineering objective in any secure routing
architecture.
</t>
<t>While the formal definition of a route leak has proven elusive
in the literature, their rampant occurrence and persistent
operational threats have proven to be anything but elusive.
This document is intended to serve as an existence
proof for this threat vector, and any supplementary formal models are
left for future work.
</t>
</section>
<section title="Discussion">
<t>In order to understand how a MITM attack can be launched with this
attack vector,
assume a multi-homed Autonomous System (AS), AS1, connects to
two ISPs (ISP1 & 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) attack. Further, assume that an RPKI-enabled
BGPSEC <xref target="I-D.ietf-sidr-bgpsec-protocol"/> as currently
defined is fully deployed by all parties in this scenario and
functioning as designed.
</t>
<figure>
<preamble></preamble>
<artwork
alt='[picture of topology 1]'>
+------+ +------+
| ISP1 | | ISP2 |_
+------+ +------ \
\ / ( P )
\ / \___/
+-----+
| AS1 |
+-----+
</artwork>
<postamble>This figure depicts a multi-homed AS1, who is connected to
two upstream ISPs (ISP1 and ISP2).</postamble>
</figure>
<t>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 <xref target="RFC4271"/> Path Attributes, most commonly,
LOCAL_PREF as illustrated in <xref target="RFC1998"/>, that are
evaluated earlier in the BGP Path Selection process than AS_PATH
length.
</t>
<t>As currently defined, <xref target="I-D.ietf-sidr-bgpsec-protocol"/> only provides two functions:</t>
<t>
<list style="numbers">
<t>Is an Autonomous System authorized to originate
an IP prefix?
</t>
<t>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?
</t>
</list>
</t>
<t>In order for an attacker (AS1) to divert traffic from ISP1
for prefix P through their AS they simply fail to scope the
propagation of the target prefix P (received from ISP2) by
announcing a (syntactically correct) BGPSEC update for prefix
P to ISP1. This vulnerability is what the authors refer to
as a 'route leak' or a 'leak-attack' (when intent aligns with
actions). It is important to note that the default
behavior in BGP <xref target="RFC4271"/> is to announce all
best paths to external BGP peers, unless explicitly scoped
by a BGP speaker through configuration. Because ISP1 prefers
prefixes learned from customers (AS1) over prefixes learned
from peers (ISP2), they begin forwarding traffic for prefix P
destinations through the attacker's AS (AS1). Voila!
</t>
<t>It is important to note that the route leaks described herein are
NOT 'misorginiations.' Rather, these are cases in which routes are
propagated with their authentic origins, but are
misdirected through unexpected intermediaries.
</t>
<t>It should be understood that any multi-homed AS can potentially
launch such an attack, even if through simple misconfiguration,
as is a common occurrence today on the Internet. As a matter of
fact, advertising these prefixes is the default behavior is many
BGP implementations, and explicit action must be taken to not
advertise all prefixes learned in BGP.
Such occurrences have been historically archived <xref
target="ROUTE_LEAK_DETECTION_TOOL"/> and
presented to the operational community <xref target="NANOG_LEAK_TALK"/>
since 2007. To date, over 9.6 million such events have been recorded
and are queriable <xref target="ROUTE_LEAK_DETECTION_TOOL"/>.
This corpus serves as a low pass filter, and likely contains
some degree of false positives. Thus, while some may debate
how many of the occurrences were malicious, or how many were actually
real leaks, the corpus itself (and its sheer size) serves as evidence
of the large magnitude of this problem. Determination
of benign versus malicious intent in these situations is usually
imperceptible, and as such, preventative controls are requisite.
</t>
<t>
To illustrate the above point, consider the events that transpired on
November 6th, 2012 <xref target="LEAK_ATTACK_ON_GOOGLE"/>. On that day
a large Internet property (who services hundreds of billions of public end user transactions
every day) became unreachable for roughly 27 minutes. At a transaction
volume like that, an outage of 27 minutes is a very visible (and likely financially
measurable) event. In this case, services became unreachable because a peered
AS improperly propagated the impacted party's AS' prefix(s). In leaks such as this, there exists
public acknowledgment by the impacted party that <xref target="RFC6480"/> and
<xref target="I-D.ietf-sidr-bgpsec-protocol"/> would be unable to detect or
remediate this attack.
</t>
<t>In an environment where <xref target="I-D.ietf-sidr-bgpsec-protocol"/> is fully deployed, it is expected
that there would be
high assurances that guard the syntactic integrity of the AS_PATH
(or BGPSEC_Path) attribute. As such, one would expect that
such an attribute would, indeed, accurately reflect the attacker's
AS number in the appropriate location of the AS_PATH; however,
it would not prevent an attacker from inserting his AS in the first
place. That is, nothing in <xref target="I-D.ietf-sidr-bgpsec-protocol"/> would
stop an attacker from launching this type of leak-attack.
</t>
<t>Discussion of out of band methods to mitigate this attack
are beyond the scope of this document, as its objective is to
inform routing protocol design choices currently being
considered within the IETF's SIDR Working Group.
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
</section>
<section anchor="IANA" title="IANA Considerations">
</section>
<section title="Security Considerations">
<t> 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 that exists as a result of
"leaks" and attacks that conform to this type of behavior.
</t>
<t>The authors believe the capability to prevent leaks and leak-attacks should be a
first-order engineering objective in any secure routing
architecture.
</t>
</section>
</middle>
<back>
<references title="Informative References">
&RFC1998;
&RFC4271;
&RFC6480;
&I-D.ietf-sidr-bgpsec-protocol;
<reference anchor="ROUTE_LEAK_DETECTION_TOOL" target="http://puck.nether.net/bgp/leakinfo.cgi">
<front>
<title abbrev="PUCK ROUTE LEAKS">BGP Routing Leak Detection System Routing Leak Detection System</title>
<author initials="J" surname="Mauch">
<organization></organization>
</author>
<date month="September" year="2007"/>
</front>
</reference>
<reference anchor="NANOG_LEAK_TALK" target="http://www.nanog.org/meetings/nanog41/presentations/mauch-lightning.pdf">
<front>
<title abbrev="PUCK LEAK TALK">Detecting Routing Leaks by Counting</title>
<author initials="J" surname="Mauch">
<organization></organization>
</author>
<date month="October" year="2007"/>
</front>
</reference>
<reference anchor="LEAK_ATTACK_ON_GOOGLE" target="http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about">
<front>
<title abbrev="GOOGLE LEAK">Why Google Went Offline Today and a Bit about How the Internet Works</title>
<author initials="CF" surname="CloudFlare">
<organization></organization>
</author>
<date month="November" year="2012"/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:20:24 |