< draft-gu-grow-bmp-route-leak-detection-02.txt   draft-gu-grow-bmp-route-leak-detection-03.txt >
Network Working Group Y. Gu Network Working Group Y. Gu
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track H. Chen Intended status: Standards Track H. Chen
Expires: October 4, 2019 China Telecom Co., Ltd. Expires: January 9, 2020 China Telecom Co., Ltd.
D. Ma D. Ma
ZDNS ZDNS
S. Zhuang S. Zhuang
Huawei Huawei
April 2, 2019 July 8, 2019
BMP for BGP Route Leak Detection BMP for BGP Route Leak Detection
draft-gu-grow-bmp-route-leak-detection-02 draft-gu-grow-bmp-route-leak-detection-03
Abstract Abstract
According to RFC7908 [RFC7908], Route leaks refer to case that the According to RFC7908 [RFC7908], Route leaks refer to case that the
delivery range of route advertisements is beyond the expected range. delivery range of route advertisements is beyond the expected range.
For many current security protection solutions, the ISPs (Internet For many current security protection solutions, the ISPs (Internet
Service Providers) are focusing on finding ways to detect the Service Providers) are focusing on finding ways to prevent the
happening of route leaks. However, the real-time route leak happening of route leaks. However, the real-time route leak
detection if any occurs is important as well. This document extends detection if any occurs is important as well, and serves as the basis
the BGP Monitoring Protocol (BMP) [RFC7854] to provide a routing for leak mitigation. This document extends the BGP Monitoring
security scheme suitable for ISPs to detect BGP route leaks within Protocol (BMP) [RFC7854] to provide a routing security scheme
their own networks. suitable for ISPs to detect BGP route leaks at the prefix level.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 4, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. ISP Route Leak Prevention Methods . . . . . . . . . . . . 3 2.1. Actions Against Route Leaks . . . . . . . . . . . . . . . 3
2.2. Challenge of the Current Route Leak Prevention Methods . 4 2.2. Challenges of the Current Actions against Route Leaks . . 4
3. Route Leak Detection Considerations . . . . . . . . . . . . . 4 3. Route Leak Detection (RLD) Design Considerations . . . . . . 5
4. Extending BMP for RLD . . . . . . . . . . . . . . . . . . . . 6 4. BMP Support for RLD . . . . . . . . . . . . . . . . . . . . . 5
5. Implementation Examples . . . . . . . . . . . . . . . . . . . 7 4.1. RLD TLV Format . . . . . . . . . . . . . . . . . . . . . 5
6. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. RLD TLV usage . . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Coordination with iOTC and RLP . . . . . . . . . . . . . 7
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Terminology 1. Terminology
BMP: BGP Monitoring Protocol BMP: BGP Monitoring Protocol
BMS: BGP Monitoring Station BMS: BGP Monitoring Station
C2P: Customer to Provider C2P: Customer to Provider
ISP: Internet Service Provider ISP: Internet Service Provider
P2P: Peer to Peer P2P: Peer to Peer
RIB: Routing Information Base RIB: Routing Information Base
RLP: Route Leak Protection
RLD: Route Leak Detection RLD: Route Leak Detection
2. Introduction 2. Introduction
RFC 7908 defines "Route Leak" as: A route leak is the propagation of RFC 7908 defines "Route Leak" as: A route leak is the propagation of
routing announcement(s) beyond their intended scope, which can result routing announcement(s) beyond their intended scope, which can result
in possible situations such as eavesdropping, device overload, route in possible situations such as eavesdropping, device overload, route
black hole and so on. More specifically, the intended scope of route black hole and so on. More specifically, the intended scope of route
announcements is usually defined by local route filtering/ announcements is usually defined by local route filtering/
distribution policies within devices. These policies are designed to distribution policies within devices. These policies are designed to
realise the pair-wise peering business relationships between ASes realise the pair-wise peering business relationships between ASes
(autonomous systems), which include Customer to Provider (C2P), Peer (autonomous systems), which include Customer to Provider (C2P), Peer
to Peer (Peer to Peer), and Provider to Customer (P2C). In a C2P to Peer (Peer to Peer), and Provider to Customer (P2C). In a C2P
relationship, the customer pays the provider for traffic sent between relationship, the customer pays the transit provider for traffic sent
the two ASes. In return, the customer gains access to the ASes the between the two ASes. In return, the customer gains access to the
provider can reach, including those which the provider reaches ASes that the transit provider can reach, including those which the
through its own providers. In a P2P relationship, the peering ASes transit provider reaches through its own transit providers. In a P2P
gain access to each other's customers, typically without either AS relationship, the peering ASes gain access to each other's customers,
paying the other[Luckie]. RFC 7908 classifies six typical route typically without either AS paying the other AS Relationships,
leaks situations based on the documented events. Customer Cones, and Validation [Luckie].
2.1. ISP Route Leak Prevention Methods More precisely, the route leaks we discuss in this draft, referring
to Type 1, 2, 3, and 4 Route Leaks defined in RFC 7908, 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.
Since BGP itself does not provide any route leak prevention/ 2.1. Actions Against Route Leaks
protection, in the current networks, network administrators/operators
typically configure export policies on the AS border routers (ASBRs)
to prevent route leak. For example, refer to the topology in
Figure 1, the bussiness relationship between AS2 and AS1 is P2C, and
P2C between AS1 and AS3, and C2P between AS1 and AS4. According to
RFC 7908, for AS1, any route received from the provider AS (i.e., AS2
here) and then distributed to its provider AS (i.e., AS4) is treated
as route leak (Type 1 route leak). Thus, to prevent such case from
happening, an export policy is configured at ASBR R2 of AS1. The
export strategies are meant for the intention that "routes from AS2
can be sent to AS3, and cannot be sent to AS4." Routes received from
AS2 at AS1 (i.e., R1 here) are marked with BGP community attributes
so that when these routes arrive at any exit ASBR of AS1 (i.e., R2
here) is filtered by the route leak policy configured at R2 by
identifying the community attribute attached from R1. This community
attribute stands for the peering business relationship between AS2
and AS1. Suppose the destination of the route A is AS4, then R2 will
not distribute Route A to AS4 were the export policies configured
correctly.
************************* There are serveral types of approaches against route leak from
* * "Send Route different perspectives. In this draft, we mainly discuss the
Route A * AS1 +*+-----> A to AS3" following three types:
+--> * + * +-----+
+-----+ * +---+ +---+ *+P2C+--|AS3 +----+ ...
+--+ AS2 +---+P2C+*+-+ R1+---------+ R2| * +-----+
+-----+ * +-+-+\ +---+ *
* | \\ // |\ *
* | \\// | \ * "Do not send
* | //\ | \+-------> Route A to AS4"
* | // \\ | * +-----+
* | / \ | *+C2P+--|AS4 +----+ ...
* +-+-+ +-+-+ * +-----+
+--+ R3+---------+ R4| *
* +---+ +---+ *
* *
*************************
Figure 1: Route propagatin between ISPs o 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.
2.2. Challenge of the Current Route Leak Prevention Methods o 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 [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.
However, it could happen that the export policies configured at ASBRs o Route leak mitigation: The approach to mitigate route leaks that
to prevent route leak are misconfigured or simply out of date already happened at either the local AS, or upstream AS per the
considering the changes of bussiness relationships between ASes. For propagation of BGP routes. Commonly used methods include reject,
example, the export policies at R2 fails to filter Route A and drop or stop propagating the invalid routes once detected the
distributes it to AS4, then a route leak happens. Thus, in addition existence of leaks.
to such route leak prevention methods, there requires a valid
detection method to detect any occurred leak in a timely manner so
that the incorrect policies can be identified to avoid further leaks.
3. Route Leak Detection Considerations 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).
There are some existing methods proposed for Route Leak Detection 2.2. Challenges of the Current Actions against Route Leaks
(RLD).
It's straightforward to think of the idea of using a route's AS path draft-ietf-idr-bgp-open-policy [I-D.ietf-idr-bgp-open-policy] updates
combined with the business relationship information between ISPs/ASes the BGP Open negotiation process with a new BGP capability to
to detect any route leak. However, there exist implementation exchange the BGP Roles between two BGP speakers, and also proposes to
difficuties. 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
[I-D.ietf-idr-bgp-open-policy].
First of all, the business relationship information between ISPs/ASes draft-ietf-grow-route-leak-detection-mitigation
is not publicly disclosed due to confidentiality reasons. Thus, many [I-D.ietf-grow-route-leak-detection-mitigation] describes a route
attempts have been made to infer relationships and strategies between leak detection and mitigation solution based on conveying route-leak
ASs, however, the accuracy of these techniques is often questioned. protection (RLP) information in a well-know transitive BGP community,
In particular, the increase in the number of Internet Exchange Points called the RLP community. The RLP community helps with detection and
(IXPs) and their role in the recent "flattening" of the Internet mitigation of route leaks that happen at the upstream AS (per the BGP
topology, makes that a large fraction of AS relationships cannot be routes propagation), as an inter-AS solution. For representation
discovered using these data collection points [Siddiqui]. simplification,we use RLP to refer to the method specified in draft-
ietf-grow-route-leak-detection-mitigation
[I-D.ietf-grow-route-leak-detection-mitigation].
Secondly, the acquisition of BGP AS path information is also no easy The above two drafts provide solutions for route leak prevention,
work. Some BGP monitoring tools, such as Looking Glass and Route detection and mitigation. To summarize:
View, the data accuracy or completeness remains to be an issue. This
has led to the such BGP monitoring tools not being well used by
various ISPs.
Some other technologies extend existing routing protocols to realize o iOTC is used for route leak prevention of the local AS. It does
RLD. For example, modify the BGP update message, which may bring not provide the detection or mitigation of route leaks of either
about compatibility problems involved in the implementation of the local As or upstream AS per the BGP routes propagation.
solution. Besides, new extension brings interoperation, device
upgrade issues. Thus, extending the routing protocols is not the
first choice for leak detection if there are other options.
Summarizing the above discussions, we have identified the following o iOTC is peer/AS-level route leak prevention, due to the fact the
considerations when designing a RLD solution: BGP Role negotiation is peer-level. It's does not provide prefix-
level route leak prevention.
o Consideration 1: The detection should not depend on inferred o RLP is used for route leak detection and mitigation of route leak
business relationship information, which leads to inaccurate that happens in the upstream AS (per the BGP Update distribution).
detection; It is prefix-level detection and mitigation.
o Consideration 2: The detection should not depend on inaccurate/ Thus, there lacks method for local AS route leak detection.
incomplete AS path information , which leads to inaccurate
detection or a detection miss;
o Consideration 3: The detection should try to avoid extension works 3. Route Leak Detection (RLD) Design Considerations
of routing protocols considering the interoperation issues;
BMP (BGP Monitoring Protocol) is currently deployed by OTT and Considering the challenges facing the existing approaches, this draft
operators to monitor the BGP routes, such as monitoring BGP Adj-RIB- proposes a method called Route Leak Detection (RLD). It utilizes the
In using the process defined in [RFC7854], and monitoring BGP Adj- BGP Monitoring Protocol (BMP) to convey the RLD information from to
RIB-Out using the process defined in [I-D.ietf-grow-bmp-adj-rib-out]. the BMP server to realize centralized leak detection. BMP is
Considering the above mentioned requirements of RLD design, extending currently deployed by OTT and carriers to monitor the BGP routes,
BMP to collect the business relationships between an ISP and its such as monitoring BGP Adj-RIB-In using the process defined in
neighboring ASes can be a good choice for this single ISP to do RLD. RFC7854 [RFC7854], and monitoring BGP Adj-RIB-Out using the process
There are several merits: defined in draft-ietf-grow-bmp-adj-rib-out
[I-D.ietf-grow-bmp-adj-rib-out]. 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.
o First of all, it does not involve data disclosure issue since the 4. BMP Support for RLD
collected relationship information is only between itself and its
neighboring ASes;
o Secondly, BMP provides accurate and complete BGP data monitoring 4.1. RLD TLV Format
within a singe AS;
o Thirdly, it does not require BGP extension work, and thus no A RLD TLV is defined for the BMP Route Monitoring Message.
interoperation concern. 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:
Thus, a single ISP can deploy this method to do RLD without relying 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
on any other information from either other ISPs or third party tools. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
There are cases where some networks' owners want to retain their | Type (2 octets) | Length (2 octets) |
route space internally, but they don't want them to be leaked +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
outside, then they can use the proposing suggestion in this document. | Value(1 octet)|
+-+-+-+-+-+-+-+-+
4. Extending BMP for RLD Figure 1: RLD TLV
o 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.
o 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.
o Value (1 octet): Currently 4 values are defined to represent the
business relationships, which are specified in Table 1.
+-------+-------------+
| Value | Business |
| | Relationship|
+---------------------+
| 0 | P2C |
| 1 | C2P |
| 2 | P2P |
| 3 | I2I |
+-------+-------------+
Table 1: Business relationship value
4.2. RLD TLV usage
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 [RFC7908] to detect the existence of
any route leak. As example is shown in Figure 2.
+------------+ +------------+
| BMP server | | BMP server |
+------> + +<-------+ +------> + +<-------+
| | RLD ser^er | | | | RLD server | |
+ +------------+ + + +------------+ +
BMP RM adj_rib_in: BMP RM adj_rib_out: BMP RM adj_rib_in: BMP RM adj_rib_out:
relationship between relationship between (AS2 --> AS1) (AS1 --> AS4)
AS2 and AS1 AS1 and AS4 P2C C2P
| + | +
***|********************* | ***|********************* |
* | * | "Send Route * | * | "Send Route
Route A * | AS1 +*+---------> A to AS3" Route A * | AS1 +*+---------> A to AS3"
+--> * | + * | +-----+ +--> * | + * | +-----+
+-----+ * +---+ +---+ *+P2C+-----+ AS3 +----+ ... +-----+ * +---+ +---+ *+P2C+-----+ AS3 +----+ ...
+--+ AS2 +---+P2C+*+-+ R1+---------+ R2| * | +-----+ +--+ AS2 +---+P2C+*+-+ R1+---------+ R2| * | +-----+
+-----+ * +-+-+\ +---+ * | +-----+ * +-+-+\ +---+ * |
* | \\ // |\ * | * | \\ // |\ * |
* | \\// | \ * | "Do not send * | \\// | \ * | "Do not send
skipping to change at page 6, line 42 skipping to change at page 7, line 34
* | // \\ | * | +-----+ * | // \\ | * | +-----+
* | / \ | *+C2P+-----+ AS4 +----+ ... * | / \ | *+C2P+-----+ AS4 +----+ ...
* +-+-+ +-+-+ * | +-----+ * +-+-+ +-+-+ * | +-----+
+--+ R3+---------+ R4+----------+ +--+ R3+---------+ R4+----------+
* +---+ +---+ * * +---+ +---+ *
* * * *
************************* *************************
Figure 2: RLD depolyment by a single ISP Figure 2: RLD depolyment by a single ISP
A Relationship TLV is defined for BMP Route Monitoring Message. As shown in Figure 2, with the RLD TLV attached to each Route
Considering that the AS relationships are sometims per route based Monitoring Message, the RLD server (also working as the BMP server)
instead of per peer/AS based, this TLV is added at the end of each combines the BMP adj_rib_in message collected from R1 and the BMP
BGP Update Message, and then wrapped up by the BMP per peer header adj_rib_out message collected from R4 to decide if there's a route
and comon header. The TLV format is defined as follows: 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
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 indicates a value of "1", then the RLD server knows there exists a
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ route leak.
| Type (2 octets) | Length (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value(1 octet)|
+-+-+-+-+-+-+-+-+
Figure 3: Relationship TLV
Type (2 octets) = TBD, the Relatiship TLV indicates that this TLV
represents the business relationship between the AS that sends the
route and the AS that receives the route.
Length (2 octets): Defines the length of the Value filed.
The Value field is a 2 bit field, and can be "00", "01", and "10",
which represents three types of relationships, i.e., P2C, P2P, C2P,
respectively.
As shown in Figure 3, with the Relationship 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 Relationship TLV in R1's adj_rib_in
message indicates a value of "00", and the Relationship TLV in R4's
adj_rib_out message indicates a value of "10", then the RLD server
knows there exists a route leak.
5. Implementation Examples
Let's take the topology of Figure 4 as an example to describe the
implementation of the Intra-AS route leak detection.
+--------+
| RLD |
| Server |
+---|----+
|
*************|***********
Route A * ISP A | *
---> * AS A1 | *
AS B1 * | * AS E1
+-------+ (1)+---+ (2) | +---+ +-------+
... ---| ISP B |----|R1 |-----+---|R2 |-----| ISP E |--- ...
+-------+ P1 +---+\ +---+ * +-------+
AS C1 * /| \\(2) // | * AS F1
+-------+ * / | \\// | * +-------+
... ---| ISP C |--- |(2) //\ | /---| ISP F |--- ...
+-------+ * | // \\ | / * +-------+
AS D1 * | / \ | / * AS G1
+-------+ * +---+ +---+ (3) +-------+
... ---| ISP D |----|R3 |---------|R4 |-----| ISP G |--- ...
+-------+ * +---+ +---+ P2 +-------+
* *
*************************
Figure 4: RLD Server for One ISP
Routing between multi-AS and doing route-leak verifications in Local-
AS (AS1):
o (1) R1 receives Route A from AS B1, Sets ISP-Specific community
per the business relation between AS A1 and AS B1; R1 sets
business relation to the BMP Route-Monitoring message that
including Route A within the message, and sends the BMP Route-
Monitoring message to RLD Server;
o (2) R1 sends Route A to the other border routers (e.g. R4);
o (3) Per the ISP-Specific community in Route A and the business
relation between AS A1 and AS F1/G1, R4 can control the route
advertisement, e.g., Send A to AS F1, Not send A to AS G1. R4
sets business relation to the BMP Route-Monitoring message that
including Route A within the message if Route A been sent to AS
F1/G1, and sends the BMP Route-Monitoring message to RLD Server;
o (4) RLD Server doing route-leak verifications using the BMP
information collecting from R1 & R4.
The above approach can be an ISP route leak self-checking method:
1.No dependency on third-party ISP; 2.No BGP extension required.
6. Benefits
BMP is a good choice for the detection information collection with 4.3. Coordination with iOTC and RLP
minor extension work while meeting above requirements.
o Do not change BGP protocol; 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.
o Not put heavy impact on BGP processes; o 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.
o Singe-ISP-Available solution. o 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.
7. Acknowledgements o 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.
The authors would like to acknowledge the review and inputs from 5. Acknowledgements
Jared Mauch, Alexander Azimov, Gang Yan, Zhenbin Li, Aijun Wang and
the working group.
8. Contributors 6. Contributors
Haibo Wang Haibo Wang
Huawei Huawei
Email: rainsword.wang@huawei.com Email: rainsword.wang@huawei.com
9. IANA Considerations 7. IANA Considerations
TBD. This document defines the following new BMP Route Monitoring message
TLV type (Section 4.1):
10. Security Considerations o 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.
8. Security Considerations
It is not believed that this document adds any additional security It is not believed that this document adds any additional security
considerations. considerations.
11. References 9. References
11.1. Normative References 9.1. Normative References
[I-D.ietf-grow-bmp-adj-rib-out] [I-D.ietf-grow-bmp-adj-rib-out]
Evens, T., Bayraktar, S., Lucente, P., Mi, K., and S. Evens, T., Bayraktar, S., Lucente, P., Mi, K., and S.
Zhuang, "Support for Adj-RIB-Out in BGP Monitoring Zhuang, "Support for Adj-RIB-Out in BGP Monitoring
Protocol (BMP)", draft-ietf-grow-bmp-adj-rib-out-04 (work Protocol (BMP)", draft-ietf-grow-bmp-adj-rib-out-06 (work
in progress), March 2019. in progress), June 2019.
[I-D.ietf-grow-route-leak-detection-mitigation]
Sriram, K. and A. Azimov, "Methods for Detection and
Mitigation of BGP Route Leaks", draft-ietf-grow-route-
leak-detection-mitigation-00 (work in progress), April
2019.
[I-D.ietf-idr-bgp-open-policy]
Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K.
Sriram, "Route Leak Prevention using Roles in Update and
Open messages", draft-ietf-idr-bgp-open-policy-05 (work in
progress), February 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
skipping to change at page 10, line 20 skipping to change at page 9, line 47
[RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP
Monitoring Protocol (BMP)", RFC 7854, Monitoring Protocol (BMP)", RFC 7854,
DOI 10.17487/RFC7854, June 2016, DOI 10.17487/RFC7854, June 2016,
<https://www.rfc-editor.org/info/rfc7854>. <https://www.rfc-editor.org/info/rfc7854>.
[RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E.,
and B. Dickson, "Problem Definition and Classification of and B. Dickson, "Problem Definition and Classification of
BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June
2016, <https://www.rfc-editor.org/info/rfc7908>. 2016, <https://www.rfc-editor.org/info/rfc7908>.
11.2. Informative References 9.2. Informative References
[Luckie] claffy, M. L. M. L. A. D. V. G. K., "AS Relationships, [Luckie] claffy, M. L. M. L. A. D. V. G. K., "AS Relationships,
Customer Cones, and Validation", October 2013. Customer Cones, and Validation", October 2013.
[Siddiqui] [Siddiqui]
Ramirez, M. S. S. D. M. M. Y. R. S. X. M. W., "Route Leak Ramirez, M. S. S. D. M. M. Y. R. S. X. M. W., "Route Leak
Detection Using Real-Time Analytics on local BGP Detection Using Real-Time Analytics on local BGP
Information", 2014. Information", 2014.
Authors' Addresses Authors' Addresses
 End of changes. 48 change blocks. 
244 lines changed or deleted 232 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/