Network Working Group Y. Gu
Internet-Draft Huawei
Intended status: Standards Track H. Chen
Expires: October 4, 2019 China Telecom Co., Ltd.
D. Ma
ZDNS
S. Zhuang
Huawei
April 2, 2019
BMP for BGP Route Leak Detection
draft-gu-grow-bmp-route-leak-detection-02
Abstract
According to RFC7908 [RFC7908], Route leaks refer to 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 detect the
happening of route leaks. However, the real-time route leak
detection if any occurs is important as well. This document extends
the BGP Monitoring Protocol (BMP) [RFC7854] to provide a routing
security scheme suitable for ISPs to detect BGP route leaks within
their own networks.
Requirements Language
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 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 4, 2019.
Gu, et al. Expires October 4, 2019 [Page 1]
Internet-Draft Route Leak Detection April 2019
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. ISP Route Leak Prevention Methods . . . . . . . . . . . . 3
2.2. Challenge of the Current Route Leak Prevention Methods . 4
3. Route Leak Detection Considerations . . . . . . . . . . . . . 4
4. Extending BMP for RLD . . . . . . . . . . . . . . . . . . . . 6
5. Implementation Examples . . . . . . . . . . . . . . . . . . . 7
6. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Terminology
BMP: BGP Monitoring Protocol
BMS: BGP Monitoring Station
C2P: Customer to Provider
ISP: Internet Service Provider
P2P: Peer to Peer
RIB: Routing Information Base
Gu, et al. Expires October 4, 2019 [Page 2]
Internet-Draft Route Leak Detection April 2019
RLD: Route Leak Detection
2. Introduction
RFC 7908 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, route
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 provider for traffic sent between
the two ASes. In return, the customer gains access to the ASes the
provider can reach, including those which the provider reaches
through its own providers. In a P2P relationship, the peering ASes
gain access to each other's customers, typically without either AS
paying the other[Luckie]. RFC 7908 classifies six typical route
leaks situations based on the documented events.
2.1. ISP Route Leak Prevention Methods
Since BGP itself does not provide any route leak prevention/
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.
Gu, et al. Expires October 4, 2019 [Page 3]
Internet-Draft Route Leak Detection April 2019
*************************
* * "Send Route
Route A * AS1 +*+-----> A to AS3"
+--> * + * +-----+
+-----+ * +---+ +---+ *+P2C+--|AS3 +----+ ...
+--+ AS2 +---+P2C+*+-+ R1+---------+ R2| * +-----+
+-----+ * +-+-+\ +---+ *
* | \\ // |\ *
* | \\// | \ * "Do not send
* | //\ | \+-------> Route A to AS4"
* | // \\ | * +-----+
* | / \ | *+C2P+--|AS4 +----+ ...
* +-+-+ +-+-+ * +-----+
+--+ R3+---------+ R4| *
* +---+ +---+ *
* *
*************************
Figure 1: Route propagatin between ISPs
2.2. Challenge of the Current Route Leak Prevention Methods
However, it could happen that the export policies configured at ASBRs
to prevent route leak are misconfigured or simply out of date
considering the changes of bussiness relationships between ASes. For
example, the export policies at R2 fails to filter Route A and
distributes it to AS4, then a route leak happens. Thus, in addition
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
There are some existing methods proposed for Route Leak Detection
(RLD).
It's straightforward to think of the idea of using a route's AS path
combined with the business relationship information between ISPs/ASes
to detect any route leak. However, there exist implementation
difficuties.
First of all, the business relationship information between ISPs/ASes
is not publicly disclosed due to confidentiality reasons. Thus, many
attempts have been made to infer relationships and strategies between
ASs, however, the accuracy of these techniques is often questioned.
In particular, the increase in the number of Internet Exchange Points
(IXPs) and their role in the recent "flattening" of the Internet
Gu, et al. Expires October 4, 2019 [Page 4]
Internet-Draft Route Leak Detection April 2019
topology, makes that a large fraction of AS relationships cannot be
discovered using these data collection points [Siddiqui].
Secondly, the acquisition of BGP AS path information is also no easy
work. Some BGP monitoring tools, such as Looking Glass and Route
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
RLD. For example, modify the BGP update message, which may bring
about compatibility problems involved in the implementation of the
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
considerations when designing a RLD solution:
o Consideration 1: The detection should not depend on inferred
business relationship information, which leads to inaccurate
detection;
o Consideration 2: The detection should not depend on inaccurate/
incomplete AS path information , which leads to inaccurate
detection or a detection miss;
o Consideration 3: The detection should try to avoid extension works
of routing protocols considering the interoperation issues;
BMP (BGP Monitoring Protocol) is currently deployed by OTT and
operators 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 [I-D.ietf-grow-bmp-adj-rib-out].
Considering the above mentioned requirements of RLD design, extending
BMP to collect the business relationships between an ISP and its
neighboring ASes can be a good choice for this single ISP to do RLD.
There are several merits:
o First of all, it does not involve data disclosure issue since the
collected relationship information is only between itself and its
neighboring ASes;
o Secondly, BMP provides accurate and complete BGP data monitoring
within a singe AS;
o Thirdly, it does not require BGP extension work, and thus no
interoperation concern.
Gu, et al. Expires October 4, 2019 [Page 5]
Internet-Draft Route Leak Detection April 2019
Thus, a single ISP can deploy this method to do RLD without relying
on any other information from either other ISPs or third party tools.
There are cases where some networks' owners want to retain their
route space internally, but they don't want them to be leaked
outside, then they can use the proposing suggestion in this document.
4. Extending BMP for RLD
+------------+
| BMP server |
+------> + +<-------+
| | RLD ser^er | |
+ +------------+ +
BMP RM adj_rib_in: BMP RM adj_rib_out:
relationship between relationship between
AS2 and AS1 AS1 and AS4
| +
***|********************* |
* | * | "Send Route
Route A * | AS1 +*+---------> A to AS3"
+--> * | + * | +-----+
+-----+ * +---+ +---+ *+P2C+-----+ AS3 +----+ ...
+--+ AS2 +---+P2C+*+-+ R1+---------+ R2| * | +-----+
+-----+ * +-+-+\ +---+ * |
* | \\ // |\ * |
* | \\// | \ * | "Do not send
* | //\ | \+-----------> Route A to AS4"
* | // \\ | * | +-----+
* | / \ | *+C2P+-----+ AS4 +----+ ...
* +-+-+ +-+-+ * | +-----+
+--+ R3+---------+ R4+----------+
* +---+ +---+ *
* *
*************************
Figure 2: RLD depolyment by a single ISP
A Relationship TLV is defined for BMP Route Monitoring Message.
Considering that the AS relationships are sometims per route based
instead of per peer/AS based, this TLV is added at the end of each
BGP Update Message, and then wrapped up by the BMP per peer header
and comon header. The TLV format is defined as follows:
Gu, et al. Expires October 4, 2019 [Page 6]
Internet-Draft Route Leak Detection April 2019
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
Gu, et al. Expires October 4, 2019 [Page 7]
Internet-Draft Route Leak Detection April 2019
+--------+
| 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.
Gu, et al. Expires October 4, 2019 [Page 8]
Internet-Draft Route Leak Detection April 2019
6. Benefits
BMP is a good choice for the detection information collection with
minor extension work while meeting above requirements.
o Do not change BGP protocol;
o Not put heavy impact on BGP processes;
o Singe-ISP-Available solution.
7. Acknowledgements
The authors would like to acknowledge the review and inputs from
Jared Mauch, Alexander Azimov, Gang Yan, Zhenbin Li, Aijun Wang and
the working group.
8. Contributors
Haibo Wang
Huawei
Email: rainsword.wang@huawei.com
9. IANA Considerations
TBD.
10. Security Considerations
It is not believed that this document adds any additional security
considerations.
11. References
11.1. Normative References
[I-D.ietf-grow-bmp-adj-rib-out]
Evens, T., Bayraktar, S., Lucente, P., Mi, K., and S.
Zhuang, "Support for Adj-RIB-Out in BGP Monitoring
Protocol (BMP)", draft-ietf-grow-bmp-adj-rib-out-04 (work
in progress), March 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Gu, et al. Expires October 4, 2019 [Page 9]
Internet-Draft Route Leak Detection April 2019
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP
Monitoring Protocol (BMP)", RFC 7854,
DOI 10.17487/RFC7854, June 2016,
<https://www.rfc-editor.org/info/rfc7854>.
[RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E.,
and B. Dickson, "Problem Definition and Classification of
BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June
2016, <https://www.rfc-editor.org/info/rfc7908>.
11.2. Informative References
[Luckie] claffy, M. L. M. L. A. D. V. G. K., "AS Relationships,
Customer Cones, and Validation", October 2013.
[Siddiqui]
Ramirez, M. S. S. D. M. M. Y. R. S. X. M. W., "Route Leak
Detection Using Real-Time Analytics on local BGP
Information", 2014.
Authors' Addresses
Yunan Gu
Huawei
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: guyunan@huawei.com
Huanan Chen
China Telecom Co., Ltd.
109 Zhongshan W Ave
Guangzhou 510630
China
Email: chenhn8.gd@chinatelecom.cn
Gu, et al. Expires October 4, 2019 [Page 10]
Internet-Draft Route Leak Detection April 2019
Di Ma
ZDNS
4 South 4th St. Zhongguancun
Beijing, Haidian
China
Email: madi@zdns.cn
Shunwan Zhuang
Huawei
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: zhuangshunwan@huawei.com
Gu, et al. Expires October 4, 2019 [Page 11]