< draft-gu-grow-bmp-route-leak-detection-00.txt   draft-gu-grow-bmp-route-leak-detection-01.txt >
Network Working Group Y. Gu Network Working Group Y. Gu
Internet-Draft S. Zhuang Internet-Draft Huawei
Intended status: Standards Track Huawei Intended status: Standards Track H. Chen
Expires: April 25, 2019 October 22, 2018 Expires: September 12, 2019 China Telecom Co., Ltd.
S. Zhuang
Huawei
March 11, 2019
BMP for BGP Route Leak Detection BMP for BGP Route Leak Detection
draft-gu-grow-bmp-route-leak-detection-00 draft-gu-grow-bmp-route-leak-detection-01
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 detect 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. This document extends
the BGP Monitoring Protocol (BMP) [RFC7854] to provide a routing the BGP Monitoring Protocol (BMP) [RFC7854] to provide a routing
skipping to change at page 1, line 44 skipping to change at page 1, line 47
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 April 25, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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. ISP Route Leak Prevention Methods . . . . . . . . . . . . 3
2.2. Challenge of the Current Route Leak Prevention Methods . 4 2.2. Challenge of the Current Route Leak Prevention Methods . 4
3. Existing RLD Methods Discussion . . . . . . . . . . . . . . . 4 3. Route Leak Detection Considerations . . . . . . . . . . . . . 4
4. BMP Extension for RLD . . . . . . . . . . . . . . . . . . . . 5 4. Extending BMP for RLD . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
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
skipping to change at page 3, line 30 skipping to change at page 3, line 30
gain access to each other's customers, typically without either AS gain access to each other's customers, typically without either AS
paying the other[Luckie]. RFC 7908 classifies six typical route paying the other[Luckie]. RFC 7908 classifies six typical route
leaks situations based on the documented events. leaks situations based on the documented events.
2.1. ISP Route Leak Prevention Methods 2.1. ISP Route Leak Prevention Methods
Since BGP itself does not provide any route leak prevention/ Since BGP itself does not provide any route leak prevention/
protection, in the current networks, network administrators/operators protection, in the current networks, network administrators/operators
typically configure export policies on the AS border routers (ASBRs) typically configure export policies on the AS border routers (ASBRs)
to prevent route leak. For example, refer to the topology in to prevent route leak. For example, refer to the topology in
Figure 1, an export policy is configured at ASBR R2 of AS1. The Figure 1, the bussiness relationship between AS2 and AS1 is P2C, and
export strategy is, for example, "routes from AS2 can be sent to AS3 P2C between AS1 and AS3, and C2P between AS1 and AS4. According to
and cannot be sent to AS4." After ASBR R1 of AS1 receives a route A RFC 7908, for AS1, any route received from the provider AS (i.e., AS2
from AS2, R1 marks A with BGP community attribute stating that route here) and then distributed to its provider AS (i.e., AS4) is treated
A is received from AS2. Then route A with this tag is transmitted to as route leak (Type 1 route leak). Thus, to prevent such case from
another ASBR R2 through the intermediate node of AS1. Now at ASBR happening, an export policy is configured at ASBR R2 of AS1. The
R2, it checks the export filter/policy to determine if Route A with export strategies are meant for the intention that "routes from AS2
the tag is allowed to be distributed to a certain AS. This tag can be sent to AS3, and cannot be sent to AS4." Routes received from
stands for the peering business relationship between AS 2 and AS 1, AS2 at AS1 (i.e., R1 here) are marked with BGP community attributes
so that ASBR R2 of AS 1 can use it to determine which ASes Route A so that when these routes arrive at any exit ASBR of AS1 (i.e., R2
can and cannot be distributed to prevent route leak (i.e., here) is filtered by the route leak policy configured at R2 by
distributing Route A to the wrong AS). Suppose the destination AS of identifying the community attribute attached from R1. This community
the route A is AS4, then R2 will not distribute Route A to AS4 were attribute stands for the peering business relationship between AS2
the export policies correctly configured. 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.
************************* *************************
* * * * "Send Route
Route A * AS1 * Route A * AS1 +*+-----> A to AS3"
---> * -----> Send A to AS3 +--> * + * +-----+
+-----+ * +---+ +---+ * +-----+ +-----+ * +---+ +---+ *+P2C+--|AS3 +----+ ...
... ---| AS2 |----|R1 |-----+---|R2 |-----| AS3 |--- ... +--+ AS2 +---+P2C+*+-+ R1+---------+ R2| * +-----+
+-----+ * +---+\ +---+ * +-----+ +-----+ * +-+-+\ +---+ *
* | \\ // |\ --X-- Not send A to AS4 * | \\ // |\ *
* | \\// | \ * +-----+ * | \\// | \ * "Do not send
. * | //\ | \----| AS4 |--- ... * | //\ | \+-------> Route A to AS4"
* | // \\ | * +-----+ * | // \\ | * +-----+
* | / \ | * * | / \ | *+C2P+--|AS4 +----+ ...
* +---+ +---+ * * +-+-+ +-+-+ * +-----+
. ---|R3 |---------|R4 | * +--+ R3+---------+ R4| *
* +---+ +---+ * * +---+ +---+ *
* * * *
************************* *************************
Figure 1: Routing between ISPs Figure 1: Route propagatin between ISPs
2.2. Challenge of the Current Route Leak Prevention Methods 2.2. Challenge of the Current Route Leak Prevention Methods
However, it could happen that the export policies configured at ASBRs However, it could happen that the export policies configured at ASBRs
to prevent route leak are incorrect. Thus, when the route leak to prevent route leak are misconfigured or simply out of date
prevnetion methods do not work, there requires a valid method to considering the changes of bussiness relationships between ASes. For
detect any occurred leak in a timely manner so that the incorrect example, the export policies at R2 fails to filter Route A and
policies/configurations can be modified to avoid further leak distributes it to AS4, then a route leak happens. Thus, in addition
affection. 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. Existing RLD Methods Discussion 3. Route Leak Detection Considerations
There are some existing methods proposed for Route Leak Detection There are some existing methods proposed for Route Leak Detection
(RLD). (RLD).
Many attempts have been made to infer relationships and strategies It's straightforward to think of the idea of using a route's AS path
between ASs, however, the accuracy of these techniques is often combined with the business relationship information between ISPs/ASes
questioned. It's mainly due to the fact that the knowledge base for to detect any route leak. However, there exist implementation
inferring the AS relationships and their corresponding export difficuties.
policies is limited to the routing information available at the data
collection points. In particular, the increase in the number of
Internet Exchange Points (IXPs) and their role in the recent
"flattening" of the Internet topology, makes that a large fraction of
AS relationships cannot be discovered using these data collection
points [Siddiqui].
Moreover, some other technologies extend existing routing protocols First of all, the business relationship information between ISPs/ASes
to realize RLD. For example, modify the BGP update message, which is not publicly disclosed due to confidentiality reasons. Thus, many
may bring about compatibility problems involved in the implementation attempts have been made to infer relationships and strategies between
of the solution. Beside, new extension brings interoperation, device ASs, however, the accuracy of these techniques is often questioned.
upgrade problems. Thus, extending the routing protocols to do RLD In particular, the increase in the number of Internet Exchange Points
should not be the first choice if there can be other options. (IXPs) and their role in the recent "flattening" of the Internet
topology, makes that a large fraction of AS relationships cannot be
discovered using these data collection points [Siddiqui].
Considering the implementation details, different ISPs may have Secondly, the acquisition of BGP AS path information is also no easy
concerns regarding security related data disclosure. Some BGP work. Some BGP monitoring tools, such as Looking Glass and Route
monitoring tools, such as Looking Glass, not only require third-party View, the data accuracy or completeness remains to be an issue. This
information to be collected in multiple favorable locations, but also has led to the such BGP monitoring tools not being well used by
have limited knowledge of inter-domain routing status information various ISPs.
(some ISPs are reluctant to provide some information for
confidentiality reasons). This has led to the current BGP monitoring Some other technologies extend existing routing protocols to realize
tools not being well used by various ISPs. For this reason, a RLD RLD. For example, modify the BGP update message, which may bring
solution should try to avoid reliance on any third party ISP data about compatibility problems involved in the implementation of the
availability. 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 Summarizing the above discussions, we have identified the following
requirements when design a RLD solution: considerations when designing a RLD solution:
Consideration 1: A route security protection scheme that a single o Consideration 1: The detection should not depend on inferred
carrier can deploy. business relationship information, which leads to inaccurate
detection;
Consideration 2: No changes required to control plane protocols o Consideration 2: The detection should not depend on inaccurate/
(e.g., BGP); incomplete AS path information , which leads to inaccurate
detection or a detection miss;
Consideration 3: No reliance on third party ISP information; o Consideration 3: The detection should try to avoid extension works
of routing protocols considering the interoperation issues;
4. BMP Extension for RLD BMP (BGP Monitoring Protocol) is currently deployed by OTT and
+--------+ operators to monitor the BGP routes, such as monitoring BGP Adj-RIB-
| RLD | In using the process defined in [RFC7854], and monitoring BGP Adj-
| Server | 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.
* ISP A | * There are several merits:
* AS A1 | *
AS B1 * | * AS E1
+-------+ * +---+ | +---+ * +-------+
... ---| ISP B |----|R1 |-----+---|R2 |-----| ISP E |--- ...
+-------+ * +---+\ +---+ * +-------+
AS C1 * /| \\ // | * AS F1
+-------+ * / | \\// | * +-------+
... ---| ISP C |--- | //\ | /---| ISP F |--- ...
+-------+ * | // \\ | / * +-------+
AS D1 * | / \ | / * AS G1
+-------+ * +---+ +---+ * +-------+
... ---| ISP D |----|R3 |---------|R4 |-----| ISP G |--- ...
+-------+ * +---+ +---+ * +-------+
* *
*************************
Figure 2: RLD Server for One ISP o First of all, it does not involve data disclosure issue since the
collected relationship information is only between itself and its
neighboring ASes;
Considering the above mentioned factors, BMP is a good choice for o Secondly, BMP provides accurate and complete BGP data monitoring
RLD, which has no dependency on third-party ISP, and no extension within a singe AS;
required for routing protocols. Beside, by collecting information
using BMP from devices is not an RLD inferring method, which provides
true validation of ASes' peering business relationships.
We can use BMP (BGP Monitoring Protocol) to easily monitor BGP o Thirdly, it does not require BGP extension work, and thus no
routes, such as monitoring BGP Adj-RIB-In using the process defined interoperation concern.
in [RFC7854], and monitoring BGP Adj-RIB-Out using the process
defined in [I-D.ietf-grow-bmp-adj-rib-out]. BMP is a management Thus, a single ISP can deploy this method to do RLD without relying
plane protocol and a non-control plane protocol. Therefore, the use on any other information from either other ISPs or third party tools.
of BMP does not impact the processing of BGP protocol, because BMP
can monitor the BGP protocol after the BGP protocol converges. This 4. Extending BMP for RLD
document ...
+------------+
| 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 * | A 1 +*+---------> 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:
+-------------------------------+
| Type | Value |
+-------------------------------+
Figure 3: Relationship TLV
Type = 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.
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 2, 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. Acknowledgements 5. Acknowledgements
TBD. TBD.
6. IANA Considerations 6. IANA Considerations
TBD. TBD.
7. Security Considerations 7. Security Considerations
TBD. TBD.
8. References 8. References
8.1. Normative References 8.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-02 (work Protocol (BMP)", draft-ietf-grow-bmp-adj-rib-out-03 (work
in progress), September 2018. in progress), December 2018.
[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 7, line 45 skipping to change at page 8, line 17
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>.
8.2. Informative References 8.2. Informative References
[Luckie] "AS Relationships, Customer Cones, and Validation", [Luckie] claffy, M. L. M. L. A. D. V. G. K., "AS Relationships,
October 2013. Customer Cones, and Validation", October 2013.
[Siddiqui] [Siddiqui]
"Route Leak Detection Using Real-Time Analytics on local Ramirez, M. S. S. D. M. M. Y. R. S. X. M. W., "Route Leak
BGP Information", 2014. Detection Using Real-Time Analytics on local BGP
Information", 2014.
Authors' Addresses Authors' Addresses
Yunan Gu Yunan Gu
Huawei Huawei
Huawei Bld., No.156 Beiqing Rd. Huawei Bld., No.156 Beiqing Rd.
Beijing 100095 Beijing 100095
China China
Email: guyunan@huawei.com Email: guyunan@huawei.com
Huanan Chen
China Telecom Co., Ltd.
109 Zhongshan W Ave
Guangzhou 510630
China
Email: chenhn8.gd@chinatelecom.cn
Shunwan Zhuang Shunwan Zhuang
Huawei Huawei
Huawei Bld., No.156 Beiqing Rd. Huawei Bld., No.156 Beiqing Rd.
Beijing 100095 Beijing 100095
China China
Email: zhuangshunwan@huawei.com Email: zhuangshunwan@huawei.com
 End of changes. 26 change blocks. 
123 lines changed or deleted 181 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/