One document matched: draft-jdurand-idr-next-hop-liveliness-00.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 RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4271 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml">
<!ENTITY RFC5880 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5880.xml">
<!ENTITY RFC7454 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7454.xml">
<!ENTITY nbsp " ">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<rfc
category="std"
ipr="trust200902"
docName="draft-jdurand-idr-next-hop-liveliness-00.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 Next-Hop Liveliness">Path validation toward BGP next-hop</title>
<author
fullname="Jerome Durand"
initials="J."
surname="Durand">
<organization abbrev="CISCO">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>
<date year="2015" month="February"/>
<area>Operations & Management</area>
<workgroup>Internet Engineering Task Force</workgroup>
<abstract>
<t>This proposal introduces a new BGP attribute that can be used by BGP routers to advertise their capability to support any kind of host liveliness checking protocols (for example BFD). This attribute can be used to avoid black-holes scenarios seen when BGP next-hop is not the peer, in particular on Internet eXchange Points (IXPs) implementing BGP Route-Servers. IXP member routers can exchange their capability to implement a given host liveliness checking </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="Introduction" title="Introduction">
<t>Internet eXchange Points (IXPs) implement BGP Route-Servers (RS) <xref target="RouteServer" /> so that connected members do not need to configure BGP peerings with every other member to exchange routes. Through a single peering with the RS, a member will receive routes of all the other members peering with the RS. The RS redistributes routes and could simply be described as a Route-Reflector for eBGP peerings.</t>
<t>Usually, deployed RS do not modify BGP next-hop of exchanged routes so traffic exchanged between IXP members do not pass through the RS, which keeps only a control-plane role, exactly as for a BGP RR. The drawback is that it may happen that peering stays up between members and route-server while there is no connectivity between members. This results in black holes for members with no easy troubleshooting: usually upon such problem a member just shuts its connectivity to the IXP. This situation has happened several times on many different IXPs and many members do not want to peer with route-servers for this reason.</t>
<figure anchor="ProblemDescriptionSchema">
<artwork>
eBGP UP----> RS <-------eBGP UP
| | |
| | |
----------------IXP LAN---------------------
| | | |
V | | V
Member 1 <================> Member 2
BROKEN
CONNECTIVITY
</artwork>
</figure>
<t>This proposal intends to solve this situation with a new BGP attribute that can be used by BGP routers to advertise their capability to support any kind of host liveliness checking protocols (for example BFD).</t>
</section>
<section anchor="Definition" title="Definitions and Accronyms">
<t><list style="symbols">
<t>BFD: Bidirectional Forwarding Detection protocol <xref target="RFC5880" /></t>
<t>BGP: Border Gateway Protocol</t>
<t>IXP: Internet eXchange Point</t>
<t>RR: Route Reflector (BGP Route-Reflector)</t>
<t>RS: Route Server (BGP Route-Server)</t>
</list>
</t>
</section>
<section anchor="Requirements" title="Solution Requirements">
<t>Solution involves 3 different mechanisms:
<list style="symbols">
<t>The BGP next-hop liveliness checking protocol</t>
<t>The advertisement of BGP next-hop capability to support liveliness checking protocol</t>
<t>The use of BGP next-hop liveliness status</t>
</list>
</t>
<t>Host liveliness checking mechanisms have been existing for years (BFD...) and are not under the scope of this proposal. This document will focus on how BGP routers can advertise their mutual liveliness checking mechanisms and what actions to take depending on the actual liveliness.</t>
<t>Solution should be as simple as possible and avoid if possible the creation of a new protocol. As goal is to make sure BGP next-hops can check their mutual liveliness, it appears quickly that BGP can be easily adapted to announce the liveliness checking protocol capability.</t>
<t>Solution should be independent of liveliness checking protocol. It should be possible to integrate future protocols without changing main aspects of the solution.</t>
<t>BGP next-hops should not rely on any implementation on the IXP route-server to exchange their liveliness checking capability. In other words the RS should be transparent for next-hops when they advertise their liveliness checking capabilities.</t>
</section>
<section anchor="Solution" title="Solution Overview">
<t>Connected member will announce their capability to implement host liveliness mechanisms (for example BFD) through new proposed BGP attribute called NH_REACHABLE_CAPABILITY. This attribute needs to be transitive optional so it can be re-advertised by route-server which may not support it. Upon reception of routes with this attribute, a given member may know capability of the advertising next-hop and may decide to start probing its reachability.</t>
<t>In previous example, in case member 1 and 2 support BFD, they would send their routes to the RS with NH_REACHABLE_CAPABILITY attribute with TLV describing BFD capability. RS will redistribute the routes with the attribute untouched (as this is a transitive optional attribute). Upon reception of the routes, member 1 will know member 2 next-hop is BFD-capable and vice-versa. They may start probing each other and detect when there is broken connectivity between them. When that occurs they will be able to decide what to do with corresponding routes (withdraw, change local preference...)</t>
</section>
<section anchor="AttributeDescription" title="NH_REACHABLE_CAPABILITY attribute description">
<t>The NH_REACHABLE_CAPABILITY attribute follows the following schema in full conformance with BGP specifications <xref target="RFC4271" />:</t>
<figure anchor="AttributeDescriptionSchema">
<artwork>
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+---------------+---------------+---------------+---------------+
| Attr. Flags |Attr. Type Code| Attr. Length | |
+---------------+---------------+---------------+ |
| List of TLVs |
. .
. .
</artwork>
</figure>
<t>Fields of this BFD_CAPABILITY attribute are described in the following sub-sections.</t>
<section anchor="FieldAttrFlags" title="Attribute Flags">
<t>Attribute flags are following:
<list style="symbols">
<t>bit 0 - Optional bit: MUST be 1 as the NH_REACHABLE_CAPABILITY attribute is optional and may not be implemented on all BGP routers.</t>
<t>bit 1 - Transitive bit: MUST be 1 as it should pass at least the BGP RS which may not implement NH_REACHABLE_CAPABILITY attribute processing.</t>
<t>bit 2 - Partial bit. It MUST be 1 if the router attaching the NH_REACHABLE_CAPABILITY attribute is not the originator. It MUST be 0 if the router attaching the NH_REACHABLE_CAPABILITY attribute is the originator.</t>
<t>bit 3 - Extended Length bit: MUST be 0 as attribute length is 1 octet.</t>
<t>The lower-order four bits of the Attribute Flags octet are unused and MUST be 0.</t>
</list>
</t>
</section>
<section anchor="FieldAttrTypeCode" title="Attribute Type Code">
<t>Attribute type code is to be provided by IANA.</t>
</section>
<section anchor="FieldAttrLength" title="Attribute Length">
<t>Represents the total attribute length (in bytes) and is dependent on used TLVs.</t>
</section>
<section anchor="TLVDefinition" title="TLV Definition">
<t>Each associated TLV indicates a host liveliness capability. TLV data structure is used to make it possible to use different protocols to check BGP next-hop liveliness. At the time being only BFD TLV is envisaged and therefore described in this document. TLVs have the following format:</t>
<figure anchor="TLVSchema">
<artwork>
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+---------------+---------------+---------------+----------- - -
| Type | Length | Value
+---------------+---------------+---------------+----------- - -
</artwork>
</figure>
<section anchor="BFDTLV" title="BFD TLV">
<t>BFD TLV is used to indicate BFD capability of the BGP router. It is described with a Type set to numerical value 1. BFD TLV have Value field format:</t>
<figure anchor="BFDTLVSchema">
<artwork>
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+---------------+---------------+---------------+--------------+
| BFD Flags | Next-Hop IP address |
+---------------+ |
| |
. .
</artwork>
</figure>
<section anchor="FieldBFDFlags" title="BFD Flags">
<t>The high-order bit of the flag field is the BFD-Capable flag. It MUST be set to 1 in case the next-hop is BFD capable. It is set to 0 otherwise.</t>
<t>All the other bits are left unused.</t>
</section>
<section anchor="FieldNextHopIPAddress" title="Next-Hop IP address">
<t>Contains the IP address (IPv4 or IPv6) of the router that can be probed with BFD. It MUST be the IP address used to advertise the route (ie. the BGP next-hop).</t>
</section>
</section>
</section>
</section>
<section anchor="ProtocolDescription" title="Protocol description">
<t>This section details router operations with the aforementioned BGP attribute.</t>
<section anchor="ProtocolDescriptionSending" title="Generating and sending the attribute">
<t>When a router wants to advertise that it supports a host liveliness protocol, it SHOULD attach the NH_REACHABLE_CAPABILITY with appropriate TLVs to prefixes it advertises.</t>
<t>A router MUST NOT attach the NH_REACHABLE_CAPABILITY if it is not announcing itself as the BGP next-hop. For example BGP route-servers and BGP route-reflectors MUST NOT attach NH_REACHABLE_CAPABILITY for routes they relay.</t>
<t>A BGP router will most likely attach the attribute to all prefixes it advertises. There is apparently no reason why some prefixes would be checked against router liveliness while other would not benefit of this mechanism. But attribute structure makes it possible to attach the attribute only to part of the prefixes so there is no protocol restriction for attaching the attribute to only a subset of advertised routes.</t>
<t>For sake of limiting the number of bytes sent for each BGP transaction, it is important that the routes are grouped in BGP communications to transmit the attribute once for all impacted prefixes as BGP protocol <xref target="RFC4271" /> allows.</t>
</section>
<section anchor="ProtocolDescriptionReception" title="Upon reception of the NH_REACHABLE_CAPABILITY BGP attribute">
<t>As the attribute is optional transitive it will be received by downstream BGP routers. Any router implementing NH_REACHABLE_CAPABILITY MUST do the following actions in following order:<list style="symbols">
<t>If the router is a BGP route-server or a BGP route-reflector, it MUST NOT process or change this attribute.</t>
<t>If the router is not a BGP RR or RS, and has no BGP route with BGP next-hop corresponding to address embedded in NH_REACHABLE_CAPABILITY then it MUST remove the attribute from subsequent advertisements to avoid useless downstream propagation of this attribute.</t>
<t>If the router is not a BGP RR or RS, and has at least one BGP route with BGP next-hop corresponding to address embedded in NH_REACHABLE_CAPABILITY then:<list style="symbols">
<t>It MAY start the host liveliness checking mechanisms advertised. Choice of parameters for the mechanism... is out of the scope of this document. For example, in case a BFD TLV is received, the routers will negociate this parameters with BFD control packets as described in <xref target="RFC5880" />.</t>
<t>It SHOULD NOT have more than one host liveliness checking mechanism with a given next-hop. If multiple routes are received with the same NH_REACHABLE_CAPABILITY, having a single host liveliness checking "session" is sufficient to validate reachability of the BGP next-hop.</t>
<t>It MAY take any action for a received route based on host liveliness provided by that mechanism. It is important to understand that while ordinary BGP session is shut when remote peer is detected as dead, the action has to occur this time at the route level as there is no BGP peering with the probed router. For example the router MAY withdraw the route, change its local preference, add a NO_EXPORT community...</t>
<t>It MUST remove the attribute from subsequent advertisements to avoid useless propagation of this attribute.</t>
</list></t>
</list></t>
</section>
</section>
<section anchor="OtherUseCases" title="Possible other use cases">
<t>While the primary focus of the authors is to solve the issue met with BGP route-servers on IXPs described in section <xref target="Introduction" />, the proposed solution may also apply to the following use cases:
<list style="symbols">
<t>iBGP route-reflector: the scenario described for BGP route-server could also apply for iBGP route-reflector. The solution described in this draft could be used to validate received iBGP routes against real reachability of BGP next-hop (a router in same AS in case next-hop self is used, or the eBGP next-hop announcing the route.</t>
<t>Any eBGP peering: the proposed solution would enable host liveliness protocols auto-deployment on every eBGP peering. Peers would just exchange their BGP parameters and host liveliness protocol would automatically "harden" the peering without the need of any additional configuration.</t>
</list>
</t>
</section>
<section anchor="FutureWork" title="Future Work">
<section anchor="FutureWorkoptimization" title="Possible Optimization">
<t>To avoid attachment of the attribute to all prefixes and useless pollution of downstream, a "magic prefix" with this attribute could be sufficient to declare host liveliness checking capability of the peer.</t>
<t>At a first glance, the "magic prefix" that would appear most relevant would be the host address of the next-hop. A BGP router would announce its own next-hop address (/32 for IPv4 and /128 for IPv6) in addition to all other regular prefixes. Nevertheless this approach goes against filtering policies usually applied on IXPs <xref target="RFC7454" /> and cannot be selected here.</t>
<t>Another solution would be to reserve a new special use addresses and have a unique well-known "magic prefix" across the Internet. This raises other problems such as security, useless address use, BGP best path selection algorithm modification to interprete differently this well known magic prefix...</t>
<t>At the time of writing this document such an optimization needs to be further studied.</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank the following people for their comments and support: [TBD].</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>A new BGP Attribute Type Code is requested to IANA for this new NH_REACHABLE_CAPABILITY attribute.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>As the proposed attribute is transitive optional, it will be passed onward by all routers. There is no way to keep the attribute local to the IXP.</t>
<t>The attribute may contain IP address of an advertising router (this is the case if BFD TLV is used for instance). It is then possible that any downstream BGP router knows that the route has transited through it and that the router is capable of supporting some host liveliness protocol. This may be used by an attacker aware of vulnerabilities on such protocol.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC4271;
&RFC5880;
<reference anchor="RouteServer" target="http://tools.ietf.org/id/draft-ietf-idr-ix-bgp-route-server-00.txt">
<front>
<title>Internet Exchange Route Server</title>
<author>
<organization/>
</author>
<date/>
</front>
</reference>
</references>
<references title="Informative References">
&RFC7454;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:45:01 |