One document matched: draft-jdurand-bgp-security-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- A set of on-line citation libraries are maintained on the xml2rfc web site.
The next line defines an entity named RFC2629, which contains the necessary XML
for the reference element, and is used much later in the file. This XML contains an
anchor (also RFC2629) which can be used to cross-reference this item in the text.
You can also use local file names instead of a URI. The environment variable
XML_LIBRARY provides a search path of directories to look at to locate a
relative path name for the file. There has to be one entity for each item to be
referenced. -->
<!ENTITY RFC2234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2234.xml">
<!ENTITY RFC2827 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2827.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3056 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3056.xml">
<!ENTITY RFC3849 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3849.xml">
<!ENTITY RFC3879 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3879.xml">
<!ENTITY RFC4012 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4012.xml">
<!ENTITY RFC4193 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4193.xml">
<!ENTITY RFC4234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4234.xml">
<!ENTITY RFC4271 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml">
<!ENTITY RFC4291 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml">
<!ENTITY RFC5082 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5082.xml">
<!ENTITY RFC5735 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5735.xml">
<!ENTITY RFC5925 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5925.xml">
<!-- There is also a library of current Internet Draft citations. It isn't a good idea to
actually use one for the template because it might have disappeared when you come to test
this template. This is the form of the entity definition
<!ENTITY I-D.mrose-writing-rfcs SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mrose-writing-rfcs.xml">
corresponding to a draft filename draft-mrose-writing-rfcs-nn.txt. The citation will be
to the most recent draft in the sequence, and is updated roughly hourly on the web site.
For working group drafts, the same principle applies: file name starts draft-ietf-wgname-..
and entity file is reference.I-D.ietf-wgname-... The corresponding entity name is
I-D.ietf-wgname-... (I-D.mrose-writing-rfcs for the other example). Of course this doesn't
change when the draft version changes.
-->
<!-- Fudge for XMLmind which doesn't have this built in -->
<!ENTITY nbsp " ">
]>
<!-- Extra statement used by XSLT processors to control the output style. -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<rfc
category="bcp"
ipr="trust200902"
docName="draft-jdurand-bgp-security-01.txt" >
<?rfc strict="yes" ?>
<?rfc comments="no" ?>
<?rfc inline="no" ?>
<?rfc editing="no" ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="no"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<front>
<title abbrev="BGP OPSEC">BGP operations and security</title>
<author
fullname="Jerome Durand"
initials="J."
surname="Durand">
<organization abbrev="CISCO Systems, Inc.">CISCO Systems, Inc.</organization>
<address>
<postal>
<street>11 rue Camille Desmoulins</street>
<code>92782 CEDEX</code>
<city>Issy-les-Moulineaux</city>
<country>FR</country>
</postal>
<email>jerduran@cisco.com</email>
</address>
</author>
<author
fullname="Ivan Pepelnjak"
initials="I."
surname="Pepelnjak">
<organization abbrev="NIL">NIL Data Communications</organization>
<address>
<postal>
<street>Tivolska 48</street>
<code>1000</code>
<city>Ljubljana</city>
<country>Slovenia</country>
</postal>
<email>ip@nil.com</email>
</address>
</author>
<author
fullname="Gert Doering"
initials="G."
surname="Doering">
<organization abbrev="SpaceNet">SpaceNet AG</organization>
<address>
<postal>
<street>Joseph-Dollinger-Bogen 14</street>
<code>D-80807</code>
<city>Muenchen</city>
<country>Germany</country>
</postal>
<email>gert@space.net</email>
</address>
</author>
<date year="2012" month="June"/>
<area>Operations & Management</area>
<workgroup>Internet Engineering Task Force</workgroup>
<abstract>
<t>BGP (Border Gateway Protocol) is the protocol used in the internet to exchange routing information between network domains. This protocol does not directly include mechanisms that control that routes exchanged conform to the various rules defined by the Internet community. This document intends to summarize most common existing rules and help network administrators applying simply coherent BGP policies. First it recalls mechanisms that administrators can use to protect the BGP sessions, with TTL and MD5. Then the document describes the prefix filters that can be used, how some of them can be automated, and where they apply in the BGP network. Afterwards, applicability of other methods including BGP route flap dampening, limiting maximum prefixes per peering, AS-path filtering and community scrubbing is analyzed.</t>
</abstract>
<note title="Foreword">
<t>A placeholder to list general observations about this document.</t>
</note>
<note title="Requirements Language">
<t>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 <xref target="RFC2119">RFC 2119</xref>.
</t>
</note>
</front>
<middle>
<section anchor="Intro" title="Introduction">
<t><xref target="RFC4271">BGP</xref> is the protocol used in the internet to exchange routing information between network domains. This protocol does not directly include mechanisms that control that routes exchanged conform to the various rules defined by the Internet community. This document intends to summarize most common existing rules and help network administrators applying simply coherent BGP policies.</t>
</section>
<section anchor="Definition" title="Definitions">
<t><list style="symbols">
<t>BGP peering: any TCP BGP connection on the Internet.</t>
</list>
</t>
</section>
<section anchor="SessionProtection" title="Protection of BGP sessions">
<section anchor="SessionProtectionMD5" title="MD5 passwords on BGP peerings">
<t>BGP sessions can be secured with MD5 passwords <xref target="RFC5925" />, to protect against attacks that could bring down the session (by sending spoofed TCP RST packets) or possibly insert packets into the TCP stream (routing attacks).</t>
<t>The drawback of TCP/MD5 is additional management overhead for password maintenance. MD5 protection is recommended when peerings are established over shared networks where spoofing can be done (like internet exchanges, IXPs).</t>
<t>You should block spoofed packets (packets with source IP address belonging to your IP address space) at all edges of your network, making TCP/MD5 protection of BGP sessions unnecessary on iBGP session or EBGP sessions run over point-to-point links.</t>
</section>
<section anchor="SessionProtectionTTL" title="BGP TTL security">
<t>BGP sessions can be made harder to spoof with the TTL security <xref target="RFC5082" />. Instead of sending TCP packets with TTL value = 1, the routers send the TCP packets with TTL value = 255 and the receiver checks that the TTL value equals 255. Since it's impossible to send an IP packet with TTL = 255 to a non-directly-connected IP host, BGP TTL security effectively prevents all spoofing attacks coming from third parties not directly connected to the same subnet as the BGP-speaking routers.</t>
<t>Note: Like MD5 protection, TTL security has to be configured on both ends of a BGP session.</t>
</section>
</section>
<section anchor="PrefixFiltering" title="Prefix filtering">
<t>The main aspect of securing BGP resides in controlling the prefixes that are received/advertised on the BGP peerings. Prefixes exchanged between BGP peers are controlled with inbound and outbound filters that can match on IP prefixes (prefix filters, <xref target="PrefixFiltering" />), AS paths (as-path filters, <xref target="ASpathFilters" />) or any other attributes of a BGP prefix (for example, BGP communities, <xref target="CommunityFilters" />).</t>
<section anchor="PrefixFilteringDefinition" title="Definition of prefix filters">
<t>This section list the most commonly used prefix filters. Following sections will clarify where these filters should be applied.</t>
<section anchor="PrefixFilteringNoRoute" title="Prefixes that MUST not be routed by definition">
<section anchor="PrefixFilteringNoRouteIPv4" title="IPv4">
<t><xref target="RFC5735">RFC5735</xref> clarifies "special" IPv4 prefixes and their status in the Internet. Since publication of the RFC another prefix has been added on the list of the special use prefixes. Following prefixes MUST NOT cross network boundaries (ie. ASN) and therefore MUST be filtered:
<list style="symbols">
<t>10.0.0.0/8 and more specific - private use <xref target="RFC5735" /></t>
<t>100.64.0.0/10 and more specific - shared address space <xref target="SharedSpace" /></t>
<t>127.0.0.0/8 and more specific - loopbacks <xref target="RFC5735" /></t>
<t>169.254.0.0/16 and more specific - link-local <xref target="RFC5735" /></t>
<t>172.16.0.0/12 and more specific - private use <xref target="RFC5735" /></t>
<t>192.0.2.0/24 and more specific - documentation <xref target="RFC5735" /></t>
<t>192.168.0.0/16 and more specific - private use <xref target="RFC5735" /></t>
<t>224.0.0.0/4 and more specific - multicast <xref target="RFC5735" /></t>
<t>240.0.0.0/4 and more specific - reserved <xref target="RFC5735" /></t>
</list></t>
</section>
<section anchor="PrefixFilteringNoRouteIPv6" title="IPv6">
<t>There is no equivalent of RFC5735 for IPv6. This document recalls the prefixes that MUST not cross network boundaries and therefore MUST be filtered:
<list style="symbols">
<t>2001:DB8::/32 and more specific - documentation <xref target="RFC3849" /></t>
<t>Prefixes more specific than 2002::/16 - 6to4 <xref target="RFC3056" />. Only 2002::/16 6to4 prefix can cross network boundaries.</t>
<t>3FFE::/16 and more specific - was initially used for the 6Bone (worldwide IPv6 test network) and returned to IANA.</t>
<t>FC00::/7 and more specific - ULA (Unique Local Addresses) <xref target="RFC4193" /></t>
<t>FE80::/10 and more specific - link-local addresses <xref target="RFC4291" /></t>
<t>FEC0::/10 and more specific - initially reserved for unicast site-local addresses <xref target="RFC3879" />. As some networks may still use it for private addressing it is worth considering it when filtering private prefixes.</t>
<t>FF00::/8 and more specific - multicast</t>
</list></t>
<t>The list of IPv6 prefixes that MUST not cross network boundaries can be simplified as IANA allocates prefixes to RIR's only in 2000::/3 prefix <xref target="IANAipv6AddressSpace" />. All other prefixes (ULA's, link-local, multicast… are outside of that prefix) and therefore the simplified list becomes:
<list style="symbols">
<t>2001:DB8::/32 and more specific - documentation <xref target="RFC3849" /></t>
<t>Prefixes more specific than 2002::/16 - 6to4 <xref target="RFC3056" /></t>
<t>3FFE::/16 and more specific - was initially used for the 6Bone (worldwide IPv6 test network) and returned to IANA.</t>
<t>All prefixes that are outside 2000::/3 prefix</t>
</list></t>
</section>
</section>
<section anchor="PrefixFilteringNotAllocated" title="Prefixes not allocated">
<t>IANA allocates prefixes to RIRs which in turn allocate prefixes to LIRs. It is wise not to accept in the routing table prefixes that are not allocated. This could mean allocation made by IANA and/or allocations done by RIRs. This section details the options for building list of allocated prefixes at every level. It is important to understand that filtering prefixes not allocated requires constant updates as IANA and RIRs keep allocating prefixes. Therefore automation of such prefix filters is key for the success of this approach. One should probably not consider solutions described in this section if it is not capable of maintaining updated prefix filters: damage would probably be worse than the intended security policy.</t>
<section anchor="PrefixFilteringNotAllocatedIANA" title="IANA allocated prefixes filters">
<t>IANA has allocated all the IPv4 available space. Therefore there is no reason why one would keep checking prefixes are in the <xref target="IANAipv4AllocatedPrefixes">IANA allocated address space</xref>. No specific filter need to be put in place by administrators who want to make sure that IPv4 prefixes they receive have been allocated by IANA.</t>
<t>For IPv6, given the size of the address space, it can be seen as wise accepting only prefixes derived from those allocated by IANA. Administrators can dynamically build this list from the <xref target="IANAipv6AllocatedPrefixes">IANA allocated IPv6 space</xref>. As IANA keeps allocating prefixes to RIRs, the aforementioned list should be checked regularly against changes and if they occur, prefix filter should be computed and pushed on network devices. As there is delay between the time a RIR receives a new prefix and the moment it starts allocating portions of it to its LIRs, there is no need doing this step quickly and frequently. At least process in place should make sure there is no more than one month between the time the IANA IPv6 allocated prefix list changes and the moment all IPv6 prefix filters have been updated.</t>
<t>If process in place (manual or automatic) cannot guarantee that the list is updated regularly then it's better not to configure any filter. The IPv4 experience has shown that many network operators implemented filters for prefixes not allocated by IANA but did not update them on a regular basis. This created problems for latest allocations and required a extra work for RIR's that had to "de-boggonize" the newly allocated prefixes.</t>
</section>
<section anchor="PrefixFilteringNotAllocatedRIR" title="RIR allocated prefixes filters">
<t>A more precise check can be performed as one would like to make sure that prefixes they receive are being originated by the autonomous system which actually own the prefix. It has been observed in the past that one could easily advertise someone else's prefix (or more specific prefixes) and create black holes or security threats. To overcome that risk, administrators would need to make sure BGP advertisements correspond to information located in the existing registries. At this stage 2 options can be considered (short and long term options). They are described in the following subsections.</t>
</section>
<section anchor="PrefixFilteringNotAllocatedIRR" title="Prefix filters creation from Internet Routing Registries (IRR)">
<t>An Internet Routing Registry (IRR) is a database containing internet routing information, described using Routing Policy Specification Language objects <xref target="RFC4012" />. Network engineers are given privileges to describe routing policies of their own networks in the IRR and information is published, usually publicly. Most of Regional Internet Registries do also operate an IRR and can control that registered routes conform to allocations made.</t>
<t>It is possible to use IRR information in order to build for a given BGP neighbor a list of prefixes, with corresponding originating autonomous system. This can be done relatively easily using scripts and existing tools capable of retrieving this information in the registries. This approach is exactly the same for both IPv4 and IPv6.</t>
<t>The macro-algorithm for the script is described as follows. For the peer that is considered, the distant network administrator has provided the autonomous system and may be able to provide an AS-SET object (aka AS-MACRO). An AS-SET is an object which contains AS numbers or other AS-SET's. An operator may create an AS-SET defining all the AS numbers of its customers. A tier 1 transit provider might create an AS-SET describing the AS-SET of connected operators, which in turn describe the AS numbers of their customers. Using recursion, it is possible to retrieve from an AS-SET the complete list of AS numbers that the peer is susceptible to announce. For each of these AS numbers, it is also easy to check in the corresponding IRR all associated prefixes. With these 2 mechanisms a script can build for a given peer the list of allowed prefixes and the AS number from which they should be originated.</t>
<t>As prefixes, AS numbers and AS-SET's may not all be under the same RIR authority, a difficulty resides choosing for each object the appropriate IRR to poll. Some IRR have been created and are not restricted to a given region or authoritative RIR. They allow RIRs to publish information contained in their IRR in a common place. They also make it possible for any subscriber (probably under contract) to publish information too. When doing requests inside such an IRR, it is possible to specify the source of information in order to have the most reliable data. One could check the central registry and only check that the source is one of the 5 RIRs. The probably most famous registry of that kind is the <xref target="RADB">RADB</xref> (Routing Assets Database).</t>
<t>As objects in IRR's may quickly vary over time, it is important that prefix filters computed using this mechanism are refreshed regularly. A daily basis could even been considered as some routing changes must be done sometimes in a certain emergency and registries may be updated at the very last moment. It has to be noted that this approach significantly increases the complexity of the router configurations as it can quickly add more than ten thousands configuration lines for some important peers.</t>
</section>
<section anchor="PrefixFilteringNotAllocatedRIRsidr" title="SIDR - Secure Inter Domain Routing">
<t>IETF has created a working group called SIDR (Secure Inter-Domain Routing) in order to create an architecture to secure internet advertisements. At the time this document is written, many document has been published and a framework is proposed so that advertisements can be checked against signed routing objects in RIR routing registries. Implementing mechanisms proposed by this working group is the solution that will solve at a longer term the BGP routing security. But as it may take time objects are signed and deployments are done such a solution will need to be combined at the time being with other mechanisms proposed in this document. The rest of this section assumes the reader understands all technologies associated with SIDR.</t>
<t>Each received route on a router should be checked against the RPKI data set: if a corresponding ROA is found and is valid then the prefix should be accepted. It the ROA is found and is INVALID then the prefix should be discarded. If an ROA is not found then the prefix should be accepted but corresponding route should be given a low preference.</t>
</section>
</section>
<section anchor="PrefixFilteringTooSpecific" title="Prefixes too specific">
<section anchor="PrefixFilteringTooSpecificIPv4" title="IPv4">
<t>Prefixes longer than /24 are usually not announced in the IPv4 internet <xref target="RIPE-399" /></t>
</section>
<section anchor="PrefixFilteringTooSpecificIPv6" title="IPv6">
<t>Prefixes longer than /48 are usually not announced in the IPv6 internet <xref target="RIPE-532" /></t>
</section>
</section>
<section anchor="PrefixFilteringSelfPrefixes" title="Filtering prefixes belonging to local AS">
<t>A network SHOULD filter its own prefixes on peerings with all its peers (inbound direction). This prevents local traffic (from a local source to a local destination) to leak over an external peering in case someone else is announcing the prefix over the Internet. This also protects the infrastructure which may directly suffer in case backbone's prefix is suddenly preferred over the Internet. To an extent, such filters can also be configured on a network for the prefixes of its downstreams in order to protect them too. Such filters must be defined with caution as they can break existing redundancy mechanisms. For example in case an operator has a multihomed customer, it should keep accepting the customer prefix from its peers and upstreams. This will make it possible for the customer to keep accessing its operator network (and other customers) via the internet in case the BGP peering between the customer and the operator is down.</t>
</section>
<section anchor="PrefixFilteringExchangePoint" title="Internet exchange point (IXP) LAN prefixes">
<section anchor="PrefixFilteringExchangePointNetworkSecurity" title="Network security">
<t>When a network is present on an exchange point (IXP) and peers with other IXP members over a common subnet (IXP LAN prefix), it MUST NOT accept more specific prefixes for the IXP LAN prefix from any of all its external BGP peers. Accepting these routes would create a black hole for connectivity to the IXP LAN.</t>
<t>If the IXP LAN prefix is accepted as an "exact match", care needs to be taken to avoid other routers in the network sending IXP traffic towards the externally-learned IXP LAN prefix (recursive route lookup pointing into the wrong direction). This can be achieved by preferring IGP routes before eBGP, or by using "BGP next-hop-self" on all routes learned on that IXP.</t>
<t>If the IXP LAN prefix is accepted at all, it MUST only be accepted from the ASes that the IXP authorizes to announce it - which will usually be automatically achieved by filtering announcements by IRR DB.</t>
</section>
<section anchor="PrefixFilteringExchangePointPMTUD" title="pMTUd and loose uRPF problem">
<t>In order to have pMTUd working in the presence of loose uRPF, it is necessary that all the networks that may source traffic that could flow through the IXP (ie. IXP members and their downstreams) have a route for the IXP LAN prefix. This is necessary as "packet too big" ICMP messages sent by IXP members' routers may be sourced using an address of the IXP LAN prefix. In the presence of loose uRPF, this ICMP packet is dropped if there is no route for the IXP LAN prefix or a less specific route covering IXP LAN prefix.</t>
<t>Then any IXP member SHOULD make sure it has a route for the IXP LAN prefix or a less specific prefix on all its routers and that it announces the IXP LAN prefix or less specific (up to a default route) to its downstreams. The announcements done for this purpose SHOULD pass IRR-generated filters described in <xref target="PrefixFilteringNotAllocatedIRR" /> as well as "prefixes too specific" filters described in <xref target="PrefixFilteringTooSpecific" />. The easiest way to implement this is that the IXP itself takes care of the origination of its prefix and advertises it to all IXP members through a BGP peering. Most likely the BGP route servers would be used for this. The IXP would most likely send its entire prefix which would be equal or less specific than the IXP LAN prefix.</t>
</section>
<section anchor="PrefixFilteringExchangePointExample" title="Example">
<t>Let's take as an example an IXP in RIPE region for IPv4. It would be allocated a /22 by RIPE NCC (X.Y.0.0/22 in our example) and use a /23 of this /22 for the IXP LAN (let say X.Y.0.0/23). This IXP LAN prefix is the one used by IXP members to configure eBGP peerings. The IXP could also be allocated an AS number (AS64496 in our example).</t>
<t>Any IXP member MUST make sure it filters prefixes more specific than X.Y.0.0/23 from all its eBGP peers. If it received X.Y.0.0/24 or X.Y.0.1/24 this could seriously impact its routing.</t>
<t>The IXP SHOULD originate X.Y.0.0/22 and advertise it to its members through its BGP route servers (configured with AS64496).</t>
<t>The IXP members SHOULD accept the IXP prefix only if it passes the IRR generated filters (see <xref target="PrefixFilteringNotAllocatedIRR" />)</t>
<t>IXP members SHOULD then advertise X.Y.0.0/22 prefix to their downstreams. This announce would pass IRR based filters as it is originated by the IXP.</t>
</section>
</section>
<section anchor="PrefixFilteringDefault" title="Default route">
<section anchor="PrefixFilteringDefaultIPv4" title="IPv4">
<t>0.0.0.0/0 prefix MUST NOT be announced on the Internet but it is usually exchanged on upstream/customer peerings.</t>
</section>
<section anchor="PrefixFilteringDefaultIPv6" title="IPv6">
<t>::/0 prefix MUST NOT be announced on the Internet but it is usually exchanged on upstream/customer peerings.</t>
</section>
</section>
</section>
<section anchor="PrefixFilteringFullRouting" title="Prefix filtering recommendations in full routing networks">
<t>For networks that have the full internet BGP table, some policies should be applied on each BGP peer for received and advertised routes. It is recommended that each autonomous system configures rules for advertised and received routes at all its borders as this will protect the network and its peer even in case of misconfiguration. The most commonly used filtering policy is proposed in this section.</t>
<section anchor="PrefixFilteringInternetPeers" title="Filters with internet peers">
<section anchor="PrefixFilteringInternetPeersInbound" title="Inbound filtering">
<t>There are basically 2 options, the loose one where no check will be done against RIR allocations and the strict one where it will be verified that announcements strictly conform to what is declared in routing registries.</t>
<section anchor="PrefixFilteringInternetPeersInboundLoose" title="Inbound filtering loose option">
<t>In that case, the following prefixes received from a BGP peer will be filtered:
<list style="symbols">
<t><xref target="PrefixFilteringNoRoute">Prefixes not routable</xref></t>
<t><xref target="PrefixFilteringNotAllocatedIANA">Prefixes not allocated by IANA (IPv6 only)</xref></t>
<t><xref target="PrefixFilteringTooSpecific">Routes too specific</xref></t>
<t><xref target="PrefixFilteringSelfPrefixes">Prefixes belonging to local AS</xref></t>
<t><xref target="PrefixFilteringExchangePoint">Exchange points LAN prefixes</xref></t>
<t><xref target="PrefixFilteringDefault">Default route</xref></t>
</list></t>
</section>
<section anchor="PrefixFilteringInternetPeersInboundStrict" title="Inbound filtering strict option">
<t>In that case, filters are applied to make sure advertisements strictly conform to what is declared in routing registries <xref target="PrefixFilteringNotAllocatedRIR" />. It must be checked that in case of script failure all routes are rejected.</t>
<t>In addition to this, one could apply following filters beforehand in case routing registry used as source of information by the script is not fully trusted:
<list style="symbols">
<t><xref target="PrefixFilteringNoRoute">Prefixes not routable</xref></t>
<t><xref target="PrefixFilteringTooSpecific">Routes too specific</xref></t>
<t><xref target="PrefixFilteringSelfPrefixes">Prefixes belonging to local AS</xref></t>
<t><xref target="PrefixFilteringExchangePoint">Exchange points LAN prefixes</xref></t>
<t><xref target="PrefixFilteringDefault">Default route</xref></t>
</list></t>
</section>
</section>
<section anchor="PrefixFilteringInternetPeersOutbound" title="Outbound filtering">
<t>Configuration in place will make sure that only appropriate prefixes are sent. These can be for example prefixes belonging to the considered networks and those of its customers. This can be done using BGP communities or many other solution. Whatever scenario considered, it can be desirable that following filters are positioned before to avoid unwanted route announcement due to bad configuration:
<list style="symbols">
<t><xref target="PrefixFilteringNoRoute">Prefixes not routable</xref></t>
<t><xref target="PrefixFilteringTooSpecific">Routes too specific</xref></t>
<t><xref target="PrefixFilteringExchangePoint">Exchange points LAN prefixes</xref></t>
<t><xref target="PrefixFilteringDefault">Default route</xref></t>
</list></t>
<t>In case it is possible to list the prefixes to be advertised, then just configuring the list of allowed prefixes and denying the rest is sufficient.</t>
</section>
</section>
<section anchor="PrefixFilteringCustomers" title="Filters with customers">
<section anchor="PrefixFilteringCustomersInbound" title="Inbound filtering">
<t>Inbound policy with end customers is pretty straightforward: only customers prefixes must be accepted, all others should be discarded. The list of accepted prefixes can be manually specified, after having verified that they are valid. This validation can be done with the appropriate IP address management authorities.</t>
<t>Same rules apply in case the customer is also a network connecting other customers (for example a tier 1 transit provider connecting service providers). An exception can be envisaged in case it is known that the customer network applies strict inbound/outbound prefix filtering, and the number of prefixes announced by that network is too large to list them in the router configuration. In that case filters as in <xref target="PrefixFilteringInternetPeersInbound" /> can be applied.</t>
</section>
<section anchor="PrefixFilteringCustomersOutbound" title="Outbound filtering">
<t>Outbound policy with customers may vary according to the routes customer wants to receive. In the simplest possible scenario, customer wants to receive only the default route, which can be done easily by applying a filter with the default route only.</t>
<t>In case the customer wants to receive the full routing (in case it is multihomed or if wants to have a view on the internet table), the following filters can be simply applied on the BGP peering:
<list style="symbols">
<t><xref target="PrefixFilteringNoRoute">Prefixes not routable</xref></t>
<t><xref target="PrefixFilteringTooSpecific">Routes too specific</xref></t>
<t><xref target="PrefixFilteringDefault">Default route</xref></t>
</list></t>
<t>There can be a difference for the default route that can be announced to the customer in addition to the full BGP table. This can be done simply by removing the filter for the default route. As the default route may not be present in the routing table, one may decide to originate it only for peerings where it has to be advertised.</t>
</section>
</section>
<section anchor="PrefixFilteringUpstreams" title="Filters with upstream providers">
<section anchor="PrefixFilteringUpstreamsInbound" title="Inbound filtering">
<t>In case the full routing table is desired from the upstream, the prefix filtering to apply is more or less the same than the one for peers <xref target="PrefixFilteringInternetPeersInbound" />. There can be a difference for the default route that can be desired from an upstream provider even if it advertises the full BGP table. In case the upstream provider is supposed to announce only the default route, a simple filter will be applied to accept only the default prefix and nothing else.</t>
</section>
<section anchor="PrefixFilteringUpstreamsOutbound" title="Outbound filtering">
<t>The filters to be applied should not differ from the ones applied for internet peers (<xref target="PrefixFilteringInternetPeersOutbound" />).</t>
</section>
</section>
</section>
<section anchor="PrefixFilteringLeafNetworks" title="Prefix filtering recommendations for leaf networks">
<section anchor="PrefixFilteringLeafNetworksInbound" title="Inbound filtering">
<t>The leaf network will position the filters corresponding to the routes it is requesting from its upstream. In case a default route is requested, simple inbound filter will be applied to accept only that default route (<xref target="PrefixFilteringDefault" />). In case the leaf network is not capable of listing the prefix because the amount is too large (for example if it requires the full internet routing table) then it should configure filters to avoid receiving bad announcements from its upstream:
<list style="symbols">
<t><xref target="PrefixFilteringNoRoute">Prefixes not routable</xref></t>
<t><xref target="PrefixFilteringTooSpecific">Routes too specific</xref></t>
<t><xref target="PrefixFilteringSelfPrefixes">Prefixes belonging to local AS</xref></t>
<t><xref target="PrefixFilteringDefault">Default route</xref> depending if the route is requested or not</t>
</list></t>
</section>
<section anchor="PrefixFilteringLeafNetworksOutbound" title="Outbound filtering">
<t>A leaf network will most likely have a very straightforward policy: it will only announce its local routes. It can also configure the following prefixes filters described in <xref target="PrefixFilteringInternetPeersOutbound" /> to avoid announcing invalid routes to its upstream provider.</t>
</section>
</section>
</section>
<section anchor="RouteFlapDampening" title="BGP route flap dampening">
<t>BGP route flap dampening mechanism makes it possible to give penalties to routes each time they change in the BGP routing table. Initially this mechanism was created to protect the entire internet from multiple events impacting a single network. RIPE community now recommends not using BGP route flap dampening <xref target="RIPE-378" />. Author of this document proposes to follow the proposal of the RIPE community.</t>
</section>
<section anchor="MaximumPrefixes" title="Maximum prefixes on a peering">
<t>It is recommended to configure a limit on the number of routes to be accepted from a peer. Following rules are generally recommended:
<list style="symbols">
<t>From peers, it is recommended to have a limit lower than the number of routes in the internet. This will shut down the BGP peering if the peer suddenly advertises the full table. One can also configure different limits for each peer, according to the number of routes they are supposed to advertise.</t>
<t>From upstreams which provide full routing, it is recommended to have a limit much higher than the number of routes in the internet. A limit is still useful in order to protect the network (and in particular the routers' memory) if too many routes are sent by the upstream. The limit should be chosen according to the number of routes that can actually be handled by routers.</t>
</list>
It is important to review regularly the limits that are configured as the internet can quickly change over time. Some vendors propose mechanisms to have 2 thresholds: while the higher number specified will shutdown the peering, the first threshold will only trigger a log and can be used to passively adjust limits based on observations made on the network.</t>
</section>
<section anchor="ASpathFilters" title="AS-path filtering">
<t>The following rules should be applied on BGP AS-paths:
<list style="symbols">
<t>Do not accept anything other than customer’s AS number from the customer. Alternatively, only accept AS-paths with a single AS number (potentially repeated several times) from your customers. The latter option is easier to configure than per-customer AS-path filters: the default BGP logic will make sure in that case that the first AS number in the AS-path is the one of the peer.</t>
<t>Do not accept overly long AS path prepending from the customer.</t>
<t>Do not accept more than two distinct AS path numbers in the AS path if your customer is an ISP with customers. This rule becomes useless in case prefix filters are built from registries as described in <xref target="PrefixFilteringNotAllocatedIRR" />.</t>
<t>Do not advertise prefixes with non-empty AS-path if you’re not transit.</t>
<t>Do not advertise prefixes with upstream AS numbers in the AS path to your peering AS.</t>
<t>Do not accept private AS numbers except from customers</t>
<t>Do not advertise private AS numbers. Exception: Customers using BGP without having their own AS number must use private AS numbers to advertise their prefixes to their upstream. The private AS number is usually provided by the upstream.</t>
<t>Do not accept prefixes when the first AS number in the AS-path is not the one of the peer. In case the peering is done toward a BGP route-server <xref target="RouteServer" /> (connection on an Internet eXchange Point - IXP) with transparent AS path handling, this verification needs to be de-activated as the first AS number will be the one of an IXP member whereas the peer AS number will be the one of the BGP route-server.</t>
</list></t>
</section>
<section anchor="CommunityFilters" title="BGP community scrubbing">
<t>Optionally we can consider the following rules on BGP AS-paths:
<list style="symbols">
<t>Scrub inbound communities with your AS number in the high-order bits – allow only those communities that customers/peers can use as a signaling mechanism</t>
<t>Do not remove other communities: your customers might need them to communicate with upstream providers. In particular do not (generally) remove the no-export community as it is usually announced by your peer for a certain purpose.</t>
</list></t>
</section>
<section anchor="ChangeLog" title="Change logs">
<section anchor="ChangeLogJdurandV0" title="Diffs between draft-jdurand-bgp-security-01 and draft-jdurand-bgp-security-00">
<t>Following changes have been made since previous document draft-jdurand-bgp-security-00:
<list style="symbols">
<t>"This documents" typo corrected in the former abstract</t>
<t>Add normative reference for RFC5082 in former section 3.2</t>
<t>"Non routable" changed in title of former section 4.1.1</t>
<t>Correction of typo for IPv4 loopback prefix in former section 4.1.1.1</t>
<t>Added shared transition space 100.64.0.0/10 in former section 4.1.1.1</t>
<t>Clarification that 2002::/16 6to4 prefix can cross network boundaries in former section 4.1.1.2</t>
<t>Rationale of 2000::/3 explained in former section 4.1.1.2</t>
<t>Added 3FFE::/16 prefix forgotten initially in the simplified list of prefixes that MUST not be routed by definition in former section 4.1.1.2</t>
<t>Warn that filters for prefixes not allocated by IANA must only be done if regular refresh is guaranteed, with some words about the IPv4 experience, in former section 4.1.2.1</t>
<t>Replace RIR database with IRR. A definition of IRR is added in former section 4.1.2.2</t>
<t>Remove any reference to anti-spoofing in former section 4.1.4</t>
<t>Clarification for IXP LAN prefix and pMTUd problem in former section 4.1.5</t>
<t>"Autonomous filters" typo (instead of Autonomous systems) corrected in the former section 4.2</t>
<t>Removal of an example for manual address validation in former section 4.2.2.1</t>
<t>RFC5735 obsoletes RFC3300</t>
<t>Ingress/Egress replaced by Inbound/Outbound in all the document</t>
</list></t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Authors would like to thank the following people for their comments and support: Daniel Ginsburg, David Groves, Tim Kleefass, Matjaz Straus, Carlos Pignataro, Tony Tauber, Gunter Van de Velde.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document is entirely about BGP operational security.</t>
</section>
</middle>
<back>
<!-- References split to informative and normative -->
<references title="Normative References">
<!-- A *really* full, totally OTT reference - Note, the "target" attribute of the
"reference": if you want a URI printed in the reference, this is where it goes. -->
<reference anchor='RFC2119'
target='http://xml.resource.org/public/rfc/html/rfc2119.html'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement
Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
<list>
<t>
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.</t>
</list>
</t>
<t>
Note that the force of these words is modified by the requirement level of
the document in which they are used.</t>
</abstract>
</front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='ftp://ftp.isi.edu/in-notes/rfc2119.txt' />
<format type='HTML' octets='14486'
target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5661'
target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>
&RFC2629;
&RFC3056;
&RFC3879;
&RFC4193;
&RFC4271;
&RFC4291;
&RFC5082;
&RFC5925;
</references>
<references title="Informative References">
&RFC2234;
&RFC2827;
&RFC3849;
&RFC4012;
&RFC4234;
&RFC5735;
<reference anchor="RIPE-378">
<front>
<title>RIPE-378 - RIPE Routing Working Group Recommendations On Route-flap Damping</title>
<author initials="P." surname="Smith">
<organization/>
</author>
<author initials="C." surname="Panigl">
<organization/>
</author>
<date month="May" year="2006" />
</front>
</reference>
<reference anchor="RIPE-399">
<front>
<title>RIPE-399 - RIPE Routing Working Group Recommendations on Route Aggregation</title>
<author initials="P." surname="Smith">
<organization/>
</author>
<author initials="R." surname="Evans">
<organization/>
</author>
<author initials="M." surname="Hughes">
<organization/>
</author>
<date month="December" year="2006" />
</front>
</reference>
<reference anchor="RIPE-532">
<front>
<title>RIPE-532 - RIPE Routing Working Group Recommendations on IPv6 Route Aggregation</title>
<author initials="P." surname="Smith">
<organization/>
</author>
<author initials="R." surname="Evans">
<organization/>
</author>
<date month="November" year="2011" />
</front>
</reference>
<reference anchor="GertIPv6BGPFilterRecommendations" target="http://www.space.net/~gert/RIPE/ipv6-filters.html">
<front>
<title>IPv6 BGP Filter Recommendations</title>
<author initials="G." surname="Doering">
<organization/>
</author>
<date month="November" year="2009" />
</front>
</reference>
<reference anchor="IANAipv4AllocatedPrefixes" target="http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml">
<front>
<title>IANA IPv4 Address Space Registry</title>
<author>
<organization/>
</author>
<date/>
</front>
</reference>
<reference anchor="IANAipv6AddressSpace" target="http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml">
<front>
<title>IANA IPv6 Address Space</title>
<author>
<organization/>
</author>
<date/>
</front>
</reference>
<reference anchor="IANAipv6AllocatedPrefixes" target="http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xml">
<front>
<title>IANA IPv6 Address Space Registry</title>
<author>
<organization/>
</author>
<date/>
</front>
</reference>
<reference anchor="RADB" target="http://www.radb.net">
<front>
<title>Routing Assets Database</title>
<author>
<organization/>
</author>
<date/>
</front>
</reference>
<reference anchor="SIDR" target="http://datatracker.ietf.org/wg/sidr/">
<front>
<title>Secure Inter-Domain Routing IETF working group</title>
<author>
<organization/>
</author>
<date/>
</front>
</reference>
<reference anchor="RouteServer" target="http://tools.ietf.org/id/draft-jasinska-ix-bgp-route-server-03.txt">
<front>
<title>Internet Exchange Route Server</title>
<author>
<organization/>
</author>
<date/>
</front>
</reference>
<reference anchor="SharedSpace" target="http://tools.ietf.org/id/draft-weil-shared-transition-space-request-15.txt">
<front>
<title> IANA Reserved IPv4 Prefix for Shared Address Space </title>
<author>
<organization/>
</author>
<date/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:34:51 |