BMP for BGP Route Leak
DetectionHuaweiHuawei Bld., No.156 Beiqing Rd.Beijing100095Chinaguyunan@huawei.comChina Telecom Co., Ltd.109 Zhongshan W AveGuangzhou510630Chinachenhn8.gd@chinatelecom.cnZDNS4 South 4th St. ZhongguancunBeijingHaidianChinamadi@zdns.cnHuaweiHuawei Bld., No.156 Beiqing Rd.Beijing100095Chinazhuangshunwan@huawei.comAccording to RFC7908, Route leaks refer
to the case that the delivery range of route advertisements is beyond
the expected range. For many current security protection solutions, the
ISPs (Internet Service Providers) are focusing on finding ways to
prevent the happening of BGP route leaks.
However, the real-time route leak detection if any occurs is important
as well, and serves as the basis for leak mitigation. This document
extends the BGP Monitoring Protocol (BMP)
to provide a routing security scheme suitable for ISPs to detect BGP
route leaks at the prefix level.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.BMP: BGP Monitoring ProtocolBMS: BGP Monitoring StationC2P: Customer to ProviderISP: Internet Service ProviderP2C: Provider to CustomerP2P: Peer to PeerRIB: Routing Information BaseRLP: Route Leak ProtectionRLD: Route Leak DetectionRFC7908 defines "Route Leak" as: A route leak
is the propagation of routing announcement(s) beyond their intended
scope, which can result in possible situations such as eavesdropping,
device overload, routing black hole and so on. More specifically, the
intended scope of route announcements is usually defined by local route
filtering/distribution policies within devices. These policies are
designed to realise the pair-wise peering business relationships between
ASes (autonomous systems), which include Customer to Provider (C2P),
Peer to Peer (Peer to Peer), and Provider to Customer (P2C). In a C2P
relationship, the customer pays the transit provider for traffic sent
between the two ASes. In return, the customer gains access to the ASes
that the transit provider can reach, including those which the transit
provider reaches through its own transit providers. In a P2P
relationship, the peering ASes gain access to each other's customers,
typically without either AS paying the other AS
Relationships, Customer Cones, and Validation.More precisely, the route leaks we discuss in this draft, referring
to Type 1, 2, 3, and 4 Route Leaks defined in RFC7908 , can be summarized as: a route leak occurs when a
route received from a transit provider or a lateral peer is propagated
to another transit provider or a lateral peer.There are serveral types of approaches against route leak from
different perspectives. In this draft, we mainly discuss the following
three types:Route leak prevention: The approach to prevent route leak from
happening. Commonly used methods inlcude inbound/outbound
prefix/peer/AS filtering policies configured at the ingress/egress
nodes of ASes per the propagation of BGP routes.Route leak detection: The approach to detect the existence of
route leaks that happen at either the local AS, or upstream AS per
the propagation of BGP routes. An intuitive way of detecting route
leak is by checking the business relationship information at both
the ingress and egress nodes of the local AS along the BGP route
propagation path with the route leak violation rules defined in
RFC7908. Thus, it requires the
knowledge of the actual route propagation trace, as well as the
resulting business relationship information at the ingress and
egress nodes. With the above information collected, the analysis
can be done by the routing device or a centralized server. This
draft specifies one such method.Route leak mitigation: The approach to mitigate route leaks
that already happened at either the local AS, or upstream AS per
the propagation of BGP routes. Commonly used methods include
reject, drop or stop propagating the invalid routes once detected
the existence of leaks.The above mentioned actions can be used seperately or
combinely, depending on the entities (routing devices, network
manager) that execute the actions, and the relative positions of the
executing entities from the leaking point (local or downstream).draft-ietf-idr-bgp-open-policy
updates the BGP Open negotiation process with a new BGP capability to
exchange the BGP Roles between two BGP speakers, and also proposes to
use a new BGP attribute, called the iOTC (Internal Only To Customer)
Path attribute to mark routes according to the BGP Roles established
in Open Message. The iOTC attribute of the incoming route is set at
the ingress node of the local AS, and is conveyed with the BGP Update
to the egress node of the local AS for outbound filtering to prevent
route leaks in the local AS. This attribute is removed at the egress
node before the BGP Update is sent to eBGP neighbors. For
representation simplification,we use iOTC to refer to the method
specified in draft-ietf-idr-bgp-open-policy.draft-ietf-grow-route-leak-detection-mitigation
describes a route leak detection and mitigation solution based on
conveying route-leak protection (RLP) information in a well-know
transitive BGP community, called the RLP community. The RLP community
helps with detection and mitigation of route leaks that happen at the
upstream AS (per the BGP routes propagation), as an inter-AS solution.
For representation simplification,we use RLP to refer to the method
specified in draft-ietf-grow-route-leak-detection-mitigation.The above two drafts provide solutions for route leak prevention,
detection and mitigation. To summarize:iOTC is used for route leak prevention of the local AS. It does
not provide the detection or mitigation of route leaks of either
local As or upstream AS per the BGP routes propagation.iOTC is peer/AS-level route leak prevention, due to the fact
the BGP Role negotiation is peer-level. It's does not provide
prefix-level route leak prevention.RLP is used for route leak detection and mitigation of route
leak that happens in the upstream AS (per the BGP Update
distribution). It is prefix-level detection and mitigation.Thus, there lacks method for local AS route leak
detection.Considering the challenges facing the existing approaches, this draft
proposes a method called Route Leak Detection (RLD). It utilizes the BGP
Monitoring Protocol (BMP) to convey the RLD information from to the BMP
server to realize centralized leak detection. BMP is currently deployed
by OTT and carriers to monitor the BGP routes, such as monitoring BGP
Adj-RIB-In using the process defined in RFC7854, and monitoring BGP Adj-RIB-Out using
the process defined in RFC8671 . On the other
hand, the RLD information is in fact a representation of the business
relationships between the local AS and its neighboring AS. It does not
involve any information disclosure issue regarding third parties. Thus,
a single ISP can deploy RLD without relying on any information from
either other ISPs or other third parties.A RLD TLV is defined for the BMP Route Monitoring Message.
Considering that the AS relationships are sometims per route based
instead of per peer/AS based, this TLV is appended to each route,
following the BGP Update Message. The order of placing the RLD TLV
among other BMP supported TLVs is out of the scope of this draft. The
TLV format is defined as follows:Type (2 octets) = TBD1, the RLD TLV represents the prefix-level
business relationship between the transmitter AS and the receiver
AS. The local AS is a transmitter or a receiver, depending on if
the route is an incoming route from a neighbor AS or an outgoing
route to a neighbor AS.Length (2 octets): Defines the length of the Value filed. It
SHOULD be set to 0x01, considering the Value field is of 1 octect
fixed length.Value (1 octet): Currently 4 values are defined to represent
the business relationships, which are specified in Table 1.The RLD TLV, presenting the business relationship between the
neighbor AS and the local AS of the incoming route, SHOULD be
prepended to the Adj-rib-in at the ingress node of the local AS. The
RLD TLV, representing the business relationship between the local AS
and the neighbor AS of the outgoing route, SHOULD also be prepended to
the Adj-rib-out at the egress node of the local AS. The BMP server, by
analyzing the above two RLD TLVs of the same route, can use the rules
defined in RFC7908 to detect the
existence of any route leak. As example is shown in Figure 2. As shown in Figure 2, with the RLD TLV attached to each
Route Monitoring Message, the RLD server (also working as the BMP
server) combines the BMP adj_rib_in message collected from R1 and the
BMP adj_rib_out message collected from R4 to decide if there's a route
leak. For example, if the RLD TLV in R1's adj_rib_in message indicates
a value of "0", and the RLD TLV in R4's adj_rib_out message indicates
a value of "1", then the RLD server knows there exists a route
leak.RLD can be used as a complementary method to the existing methods
against route leaks. More specifically, RLD can coordination with both
iOTC and RLP.With the settlement of the iOTC draft, the iOTC attribute is
naturally included in the BGP Update and can be collected to the
BMP server without BMP extension. With the RLD TLV collected also
by BMP (more specifically, the iBGP adj-rib-in of the ingress
node), the BMP server can do validate the consistency of the iOTC
attribute with the RLD. If contradiction detected, the BMP server
may further check the bussiness contract for the actual business
relationship.For special prefixes that does not obey the peer/AS level
business relationship negotiated through BGP Open Message, the BMP
server can use the RLD TLV to detect such routes since the RLD TLV
is set at prefix level.For devices that do not support RLP, using RLD to collect the
BGP routes, which conveys the RLD information from upstream ASes,
allows the BMP server to detect and mitigate the route leaks that
happen in the upstream AS. In other words, the detection and
mitigation process can be also done in the BMP server, should the
BMP server collects the BGP Update messages at the ingress or
egress nodes.Haibo WangHuaweiEmail: rainsword.wang@huawei.comThis document defines the following new BMP Route Monitoring message
TLV type (Section 4.1):Type = TBD1, the RLD TLV represents the prefix-level business
relationship between the transmitter AS and the receiver AS. The
local AS is a transmitter or a receiver, depending on if the route
is an incoming route from a neighbor AS or an outgoing route to a
neighbor AS.It is not believed that this document adds any additional security
considerations.AS Relationships, Customer Cones, and ValidationRoute Leak Detection Using Real-Time Analytics on local BGP
Information