One document matched: draft-ymbk-grow-blackholing-00.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc comments="yes"?>
<?rfc compact="yes"?>
<?rfc inline="yes"?>
<?rfc sortrefs="yes"?>
<?rfc subcompact="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc tocompact="yes"?>
<rfc category="std" docName="draft-ymbk-grow-blackholing-00" ipr="noDerivativesTrust200902">
<front>
<title>BLACKHOLEIXP BGP Community for Blackholing at IXPs</title>
<author fullname="Thomas King" initials="T." surname="King">
<organization>DE-CIX Management GmbH</organization>
<address>
<postal>
<street>Lichtstrasse 43i</street>
<city>Cologne</city>
<code>50825</code>
<country>Germany</country>
</postal>
<email>thomas.king@de-cix.net</email>
</address>
</author>
<author fullname="Christoph Dietzel" initials="C." surname="Dietzel">
<organization>DE-CIX Management GmbH</organization>
<address>
<postal>
<street>Lichtstrasse 43i</street>
<city>Cologne</city>
<code>50825</code>
<country>Germany</country>
</postal>
<email>christoph.dietzel@de-cix.net</email>
</address>
</author>
<author fullname="Gert Döring" initials="G." surname="Döring">
<organization>SpaceNet AG</organization>
<address>
<postal>
<street>Joseph-Dollinger-Bogen 14</street>
<city>Munich</city>
<code>80807</code>
<country>Germany</country>
</postal>
<email>gert@space.net</email>
</address>
</author>
<author fullname="Greg Hankins" initials="G." surname="Hankins">
<organization>Alcatel-Lucent</organization>
<address>
<postal>
<street>777 E. Middlefield Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>USA</country>
</postal>
<email>greg.hankins@alcatel-lucent.com</email>
</address>
</author>
<author fullname="Christian Seitz" initials="C." surname="Seitz">
<organization>STRATO AG</organization>
<address>
<postal>
<street>Pascalstr. 10</street>
<city>Berlin</city>
<code>10587</code>
<country>Germany</country>
</postal>
<email>seitz@strato.de</email>
</address>
</author>
<author fullname="Petr Jiran" initials="P." surname="Jiran">
<organization>NIX.CZ</organization>
<address>
<postal>
<street>Milešovská 1136/5</street>
<city>Praha</city>
<code>130 00</code>
<country>Czech Republic</country>
</postal>
<email>pj@nix.cz</email>
</address>
</author>
<author fullname="Yordan Kritski" initials="Y." surname="Kritski">
<organization>NetIX Ltd.</organization>
<address>
<postal>
<street>3 Grigorii Gorbatenko Str.</street>
<city>Sofia</city>
<code>1784</code>
<country>Bulgaria</country>
</postal>
<email>ykritski@netix.net</email>
</address>
</author>
<date month="May" year="2015" />
<abstract>
<t>
This document describes the use of a well-known Border Gateway Protocol (BGP)
community for blackholing at Internet Exchange Points (IXP). This well-known advisory transitive BGP
community, namely BLACKHOLEIXP, allows an origin AS to specify through the route server
that IXPs should blackhole a specific route.
</t>
</abstract>
<note title="Requirements Language">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
are to be interpreted as described in
<xref target="RFC2119" />
only when they appear in all upper
case. They may also appear in
lower or mixed case as English
words, without normative meaning.
</t>
</note>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
Massive DDoS attacks targeting Internet Exchange Point (IXP) members may cause a congestion of their peering port(s).
In order to limit the impact of such a scenario on legitimate traffic, IXPs adopted
a feature called blackholing. A member may trigger blackholing via BGP through the
<xref target="I-D.ietf-idr-ix-bgp-route-server">route
server</xref>. All traffic destined to the such announced prefixes is discarded on the
switching fabric of the IXP. This resolves the port congestion caused by the DDoS attack.
</t>
<t>
The concept of blackholing at IXPs is similar to blackholing
in <xref target="RFC3882">iBGP scenarios</xref> and the expansion <xref target="RFC5635">RTBH filtering</xref>.
</t>
<t>
Different operators of IXPs specified various mechanisms for their
members to trigger blackholing. This includes but is not limited to
BGP communities from the private community space
or specific next hop IP addresses.
</t>
<t>
Having several different mechanisms to trigger blackholing at
different IXPs makes it an unnecessary complex, error-prone and cumbersome task for IXPs
members.
A well-known and commonly agreed BGP community for blackholing at
IXPs allows members to easily utilize this feature for all their IXP peerings.
</t>
<t>
Having such a well-known and commonly agreed BGP community for blackholing
also supports IXPs as
<list style='symbols'>
<t> implementing and monitoring blackholing gets easier if implementation
and operational guides do not cover many options to trigger blackholing
</t>
<t> the amount of support requests from members about how to trigger
blackholing at a particular IXP will be reduced as the mechanism is unified for
all IXPs
</t>
</list>
</t>
<t>
Making it considerably easier for operators and members of IXP to utilize blackholing
will reduce the impact of massive DDoS attacks and thus make the Internet more reliable.
</t>
</section>
<section anchor="attribute" title="BLACKHOLEIXP Attribute">
<t>
This document defines the use a new well-known BGP transitive community,
BLACKHOLEIXP.
</t>
<t>
The semantics of this attribute is to allow an IXP to interpret the
presence of this community as an advisory qualification to drop any traffic
being sent towards this prefix.
</t>
</section>
<section anchor="recommendation" title="Operational Recommendations">
<section anchor="control" title="Peering at Route Servers">
<t>
If a member of an IXP experiences a massive DDoS attack, blackholing can be leveraged to limit
the arising collateral damage. Therefore, the member must tag the BGP announcements of their prefix with the
BLACKHOLEIXP BGP community. However, if only a sub-prefix is affected by the attack a more
specific announcement SHOULD be used.
</t>
<t>
Many IXPs provide the so-called policy control feature as part of their route servers (see e.g. the
<eref target="https://www.linx.net/members/support/route-servers.html">LINX website</eref>). Policy control allows to
specify by using BGP communities which ASNs connected to the IXP receives a particular BGP announcement.
</t>
<t>
Combined usage of the BGP communities for blackholing and policy control allows a fine-grained
control of a blackhole. Traffic from certain ASes can be blackholed exclusively.
</t>
<!--<t>
If the BGP announcement carrying the BLACKHOLEIXP BGP community is supposed to be local to the IXP the <xref target="RFC1997">
NO_ADVERTISE</xref> BGP community SHOULD be used.
<todo>Will man das hier wirklich so schreiben? Will man es nicht empfehlen und auf die Gefahr hinweisen? Würden wir uns dann auf Wissen oder auf eine berechtigte Vermutung stützen??</todo>
</t> -->
<t>
In many implementations of blackholing at IXPs, the route server after receiving a BGP announcement carrying the BLACKHOLEIXP BGP community rewrites the next hop IP address
to the pre-defined Blackholing IP address before redistruting the announcement.
</t>
</section>
<!-- <section anchor="bilateral" title="Bilateral Peering">
<t>
Besides multilateral peering, which means peering through the route server, bilateral peering is also common at an IXP.
Bilateral peering refers to a relation between two routers setting up a direct BGP session. In this case the BLACKHOLEIXP
BGP community is not of any good until the two routers implement mechanisms such as filters that drop traffic received for IP prefixes that are marked
by the BLACKHOLEIXP BGP community. Hence, the blackholing infrastructure of the IXP is not involved at all.
</t>
</section>-->
<section anchor="small" title="Accepting Blackholed IP Prefixes">
<t>
In order to limit the space required to store the routing table on a router, IP prefixes larger than /24 for IPv4
and /48 for IPv6 are usually not accepted (see <xref target="RFC7454">section 6.1.3</xref>). However, blackholes in the IP space should be as small as possible in order
to limit the impact of blackholing for IP space that is
not experiencing a massive DDoS attack.
</t>
<t>
Routers SHOULD accept BGP announcements carrying the BLACKHOLEIXP BGP community up to /32 for IPv4 and /128 for IPv6.
</t>
</section>
</section>
<section anchor="iana" title="IANA Considerations">
<t>
The IANA is requested to register BLACKHOLEIXP as a well-known community with global significance:
<list>
<t>
BLACKHOLEIXP (= 0xFFFF029A)
</t>
</list>
</t>
<t>
The value 0xFFFF029A is preferable as it can also be written as 65535:666 following the ASN:ASN (16-bit) notation. 65535 is from the
reserved ASN space and 666 is often used to signal blackholing in iBGP and eBGP transit provider networks scenarios.
</t>
</section>
<section anchor="security" title="Security Considerations">
<t>
BGP contains no specific mechanism to prevent the unauthorized modification of information by the forwarding agent. This allows
routing information to be modified, removed, or false information to be added by forwarding agents. Recipients of routing information
are not able to detect this modification. Also, <xref target="RFC6810">RKPI</xref> and <xref target="I-D.ietf-sidr-bgpsec-overview">BGPSec</xref> do not fully
resolve this situation. For instance, BGP communities can still be added
or altered by a forwarding agent even if RPKI and BGPSec are in place.
</t>
<t>
The BLACKHOLEIXP BGP community does not alter this situation.
</t>
<t>
A new additional attack vector is introduced into BGP by using the BLACKHOLEIXP BGP community: denial of service attacks
for IP prefixes.<!--Elaborate on the possible danger of -->
</t>
<t>
Unauthorized addition of the BLACKHOLEIXP BGP community to an IP prefix by a forwarding agent may cause a denial of service
attack based on denial of reachability. The denial of service will happen if an IXP offering blackholing is traversed.
However, denial of service attack vectors to BGP are not new as the injection of false routing information is already possible.
</t>
<t>
In order to further limit the impact of unauthorized BGP announcements carrying the BLACKHOLEIXP BGP community the receiving router
or route server SHOULD verify by applying strict filtering (see <xref target="RFC7454">section 6.2.1.1.2.</xref>) that the peer
announcing the prefix is authorized to do so. If not, the BGP announcement should be filtered out.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.I-D.ietf-idr-ix-bgp-route-server"?>
<?rfc include="reference.RFC.1997"?>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.3882"?>
<?rfc include="reference.RFC.5635"?>
<?rfc include="reference.RFC.6810"?>
<?rfc include="reference.RFC.7454"?>
<?rfc include="reference.I-D.ietf-sidr-bgpsec-overview"?>
</references>
<!--- <references title="Informative References"> <?rfc include="reference.I-D.ietf-sidr-bgpsec-protocol"?>
</references> -->
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 05:45:51 |