idnits 2.17.1 draft-gu-grow-bmp-route-leak-detection-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7908], [RFC7854]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (April 2, 2019) is 1850 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4271' is defined on line 411, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-grow-bmp-adj-rib-out-04 ** Downref: Normative reference to an Informational RFC: RFC 7908 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Gu 3 Internet-Draft Huawei 4 Intended status: Standards Track H. Chen 5 Expires: October 4, 2019 China Telecom Co., Ltd. 6 D. Ma 7 ZDNS 8 S. Zhuang 9 Huawei 10 April 2, 2019 12 BMP for BGP Route Leak Detection 13 draft-gu-grow-bmp-route-leak-detection-02 15 Abstract 17 According to RFC7908 [RFC7908], Route leaks refer to case that the 18 delivery range of route advertisements is beyond the expected range. 19 For many current security protection solutions, the ISPs (Internet 20 Service Providers) are focusing on finding ways to detect the 21 happening of route leaks. However, the real-time route leak 22 detection if any occurs is important as well. This document extends 23 the BGP Monitoring Protocol (BMP) [RFC7854] to provide a routing 24 security scheme suitable for ISPs to detect BGP route leaks within 25 their own networks. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on October 4, 2019. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2.1. ISP Route Leak Prevention Methods . . . . . . . . . . . . 3 70 2.2. Challenge of the Current Route Leak Prevention Methods . 4 71 3. Route Leak Detection Considerations . . . . . . . . . . . . . 4 72 4. Extending BMP for RLD . . . . . . . . . . . . . . . . . . . . 6 73 5. Implementation Examples . . . . . . . . . . . . . . . . . . . 7 74 6. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 76 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 78 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 81 11.2. Informative References . . . . . . . . . . . . . . . . . 10 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 84 1. Terminology 86 BMP: BGP Monitoring Protocol 88 BMS: BGP Monitoring Station 90 C2P: Customer to Provider 92 ISP: Internet Service Provider 94 P2P: Peer to Peer 96 RIB: Routing Information Base 97 RLD: Route Leak Detection 99 2. Introduction 101 RFC 7908 defines "Route Leak" as: A route leak is the propagation of 102 routing announcement(s) beyond their intended scope, which can result 103 in possible situations such as eavesdropping, device overload, route 104 black hole and so on. More specifically, the intended scope of route 105 announcements is usually defined by local route filtering/ 106 distribution policies within devices. These policies are designed to 107 realise the pair-wise peering business relationships between ASes 108 (autonomous systems), which include Customer to Provider (C2P), Peer 109 to Peer (Peer to Peer), and Provider to Customer (P2C). In a C2P 110 relationship, the customer pays the provider for traffic sent between 111 the two ASes. In return, the customer gains access to the ASes the 112 provider can reach, including those which the provider reaches 113 through its own providers. In a P2P relationship, the peering ASes 114 gain access to each other's customers, typically without either AS 115 paying the other[Luckie]. RFC 7908 classifies six typical route 116 leaks situations based on the documented events. 118 2.1. ISP Route Leak Prevention Methods 120 Since BGP itself does not provide any route leak prevention/ 121 protection, in the current networks, network administrators/operators 122 typically configure export policies on the AS border routers (ASBRs) 123 to prevent route leak. For example, refer to the topology in 124 Figure 1, the bussiness relationship between AS2 and AS1 is P2C, and 125 P2C between AS1 and AS3, and C2P between AS1 and AS4. According to 126 RFC 7908, for AS1, any route received from the provider AS (i.e., AS2 127 here) and then distributed to its provider AS (i.e., AS4) is treated 128 as route leak (Type 1 route leak). Thus, to prevent such case from 129 happening, an export policy is configured at ASBR R2 of AS1. The 130 export strategies are meant for the intention that "routes from AS2 131 can be sent to AS3, and cannot be sent to AS4." Routes received from 132 AS2 at AS1 (i.e., R1 here) are marked with BGP community attributes 133 so that when these routes arrive at any exit ASBR of AS1 (i.e., R2 134 here) is filtered by the route leak policy configured at R2 by 135 identifying the community attribute attached from R1. This community 136 attribute stands for the peering business relationship between AS2 137 and AS1. Suppose the destination of the route A is AS4, then R2 will 138 not distribute Route A to AS4 were the export policies configured 139 correctly. 141 ************************* 142 * * "Send Route 143 Route A * AS1 +*+-----> A to AS3" 144 +--> * + * +-----+ 145 +-----+ * +---+ +---+ *+P2C+--|AS3 +----+ ... 146 +--+ AS2 +---+P2C+*+-+ R1+---------+ R2| * +-----+ 147 +-----+ * +-+-+\ +---+ * 148 * | \\ // |\ * 149 * | \\// | \ * "Do not send 150 * | //\ | \+-------> Route A to AS4" 151 * | // \\ | * +-----+ 152 * | / \ | *+C2P+--|AS4 +----+ ... 153 * +-+-+ +-+-+ * +-----+ 154 +--+ R3+---------+ R4| * 155 * +---+ +---+ * 156 * * 157 ************************* 159 Figure 1: Route propagatin between ISPs 161 2.2. Challenge of the Current Route Leak Prevention Methods 163 However, it could happen that the export policies configured at ASBRs 164 to prevent route leak are misconfigured or simply out of date 165 considering the changes of bussiness relationships between ASes. For 166 example, the export policies at R2 fails to filter Route A and 167 distributes it to AS4, then a route leak happens. Thus, in addition 168 to such route leak prevention methods, there requires a valid 169 detection method to detect any occurred leak in a timely manner so 170 that the incorrect policies can be identified to avoid further leaks. 172 3. Route Leak Detection Considerations 174 There are some existing methods proposed for Route Leak Detection 175 (RLD). 177 It's straightforward to think of the idea of using a route's AS path 178 combined with the business relationship information between ISPs/ASes 179 to detect any route leak. However, there exist implementation 180 difficuties. 182 First of all, the business relationship information between ISPs/ASes 183 is not publicly disclosed due to confidentiality reasons. Thus, many 184 attempts have been made to infer relationships and strategies between 185 ASs, however, the accuracy of these techniques is often questioned. 186 In particular, the increase in the number of Internet Exchange Points 187 (IXPs) and their role in the recent "flattening" of the Internet 188 topology, makes that a large fraction of AS relationships cannot be 189 discovered using these data collection points [Siddiqui]. 191 Secondly, the acquisition of BGP AS path information is also no easy 192 work. Some BGP monitoring tools, such as Looking Glass and Route 193 View, the data accuracy or completeness remains to be an issue. This 194 has led to the such BGP monitoring tools not being well used by 195 various ISPs. 197 Some other technologies extend existing routing protocols to realize 198 RLD. For example, modify the BGP update message, which may bring 199 about compatibility problems involved in the implementation of the 200 solution. Besides, new extension brings interoperation, device 201 upgrade issues. Thus, extending the routing protocols is not the 202 first choice for leak detection if there are other options. 204 Summarizing the above discussions, we have identified the following 205 considerations when designing a RLD solution: 207 o Consideration 1: The detection should not depend on inferred 208 business relationship information, which leads to inaccurate 209 detection; 211 o Consideration 2: The detection should not depend on inaccurate/ 212 incomplete AS path information , which leads to inaccurate 213 detection or a detection miss; 215 o Consideration 3: The detection should try to avoid extension works 216 of routing protocols considering the interoperation issues; 218 BMP (BGP Monitoring Protocol) is currently deployed by OTT and 219 operators to monitor the BGP routes, such as monitoring BGP Adj-RIB- 220 In using the process defined in [RFC7854], and monitoring BGP Adj- 221 RIB-Out using the process defined in [I-D.ietf-grow-bmp-adj-rib-out]. 222 Considering the above mentioned requirements of RLD design, extending 223 BMP to collect the business relationships between an ISP and its 224 neighboring ASes can be a good choice for this single ISP to do RLD. 225 There are several merits: 227 o First of all, it does not involve data disclosure issue since the 228 collected relationship information is only between itself and its 229 neighboring ASes; 231 o Secondly, BMP provides accurate and complete BGP data monitoring 232 within a singe AS; 234 o Thirdly, it does not require BGP extension work, and thus no 235 interoperation concern. 237 Thus, a single ISP can deploy this method to do RLD without relying 238 on any other information from either other ISPs or third party tools. 239 There are cases where some networks' owners want to retain their 240 route space internally, but they don't want them to be leaked 241 outside, then they can use the proposing suggestion in this document. 243 4. Extending BMP for RLD 245 +------------+ 246 | BMP server | 247 +------> + +<-------+ 248 | | RLD ser^er | | 249 + +------------+ + 250 BMP RM adj_rib_in: BMP RM adj_rib_out: 251 relationship between relationship between 252 AS2 and AS1 AS1 and AS4 253 | + 254 ***|********************* | 255 * | * | "Send Route 256 Route A * | AS1 +*+---------> A to AS3" 257 +--> * | + * | +-----+ 258 +-----+ * +---+ +---+ *+P2C+-----+ AS3 +----+ ... 259 +--+ AS2 +---+P2C+*+-+ R1+---------+ R2| * | +-----+ 260 +-----+ * +-+-+\ +---+ * | 261 * | \\ // |\ * | 262 * | \\// | \ * | "Do not send 263 * | //\ | \+-----------> Route A to AS4" 264 * | // \\ | * | +-----+ 265 * | / \ | *+C2P+-----+ AS4 +----+ ... 266 * +-+-+ +-+-+ * | +-----+ 267 +--+ R3+---------+ R4+----------+ 268 * +---+ +---+ * 269 * * 270 ************************* 272 Figure 2: RLD depolyment by a single ISP 274 A Relationship TLV is defined for BMP Route Monitoring Message. 275 Considering that the AS relationships are sometims per route based 276 instead of per peer/AS based, this TLV is added at the end of each 277 BGP Update Message, and then wrapped up by the BMP per peer header 278 and comon header. The TLV format is defined as follows: 280 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 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Type (2 octets) | Length (2 octets) | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Value(1 octet)| 285 +-+-+-+-+-+-+-+-+ 287 Figure 3: Relationship TLV 289 Type (2 octets) = TBD, the Relatiship TLV indicates that this TLV 290 represents the business relationship between the AS that sends the 291 route and the AS that receives the route. 293 Length (2 octets): Defines the length of the Value filed. 295 The Value field is a 2 bit field, and can be "00", "01", and "10", 296 which represents three types of relationships, i.e., P2C, P2P, C2P, 297 respectively. 299 As shown in Figure 3, with the Relationship TLV attached to each 300 Route Monitoring Message, the RLD server (also working as the BMP 301 server) combines the BMP adj_rib_in message collected from R1 and the 302 BMP adj_rib_out message collected from R4 to decide if there's a 303 route leak. For example, if the Relationship TLV in R1's adj_rib_in 304 message indicates a value of "00", and the Relationship TLV in R4's 305 adj_rib_out message indicates a value of "10", then the RLD server 306 knows there exists a route leak. 308 5. Implementation Examples 310 Let's take the topology of Figure 4 as an example to describe the 311 implementation of the Intra-AS route leak detection. 313 +--------+ 314 | RLD | 315 | Server | 316 +---|----+ 317 | 318 *************|*********** 319 Route A * ISP A | * 320 ---> * AS A1 | * 321 AS B1 * | * AS E1 322 +-------+ (1)+---+ (2) | +---+ +-------+ 323 ... ---| ISP B |----|R1 |-----+---|R2 |-----| ISP E |--- ... 324 +-------+ P1 +---+\ +---+ * +-------+ 325 AS C1 * /| \\(2) // | * AS F1 326 +-------+ * / | \\// | * +-------+ 327 ... ---| ISP C |--- |(2) //\ | /---| ISP F |--- ... 328 +-------+ * | // \\ | / * +-------+ 329 AS D1 * | / \ | / * AS G1 330 +-------+ * +---+ +---+ (3) +-------+ 331 ... ---| ISP D |----|R3 |---------|R4 |-----| ISP G |--- ... 332 +-------+ * +---+ +---+ P2 +-------+ 333 * * 334 ************************* 336 Figure 4: RLD Server for One ISP 338 Routing between multi-AS and doing route-leak verifications in Local- 339 AS (AS1): 341 o (1) R1 receives Route A from AS B1, Sets ISP-Specific community 342 per the business relation between AS A1 and AS B1; R1 sets 343 business relation to the BMP Route-Monitoring message that 344 including Route A within the message, and sends the BMP Route- 345 Monitoring message to RLD Server; 347 o (2) R1 sends Route A to the other border routers (e.g. R4); 349 o (3) Per the ISP-Specific community in Route A and the business 350 relation between AS A1 and AS F1/G1, R4 can control the route 351 advertisement, e.g., Send A to AS F1, Not send A to AS G1. R4 352 sets business relation to the BMP Route-Monitoring message that 353 including Route A within the message if Route A been sent to AS 354 F1/G1, and sends the BMP Route-Monitoring message to RLD Server; 356 o (4) RLD Server doing route-leak verifications using the BMP 357 information collecting from R1 & R4. 359 The above approach can be an ISP route leak self-checking method: 360 1.No dependency on third-party ISP; 2.No BGP extension required. 362 6. Benefits 364 BMP is a good choice for the detection information collection with 365 minor extension work while meeting above requirements. 367 o Do not change BGP protocol; 369 o Not put heavy impact on BGP processes; 371 o Singe-ISP-Available solution. 373 7. Acknowledgements 375 The authors would like to acknowledge the review and inputs from 376 Jared Mauch, Alexander Azimov, Gang Yan, Zhenbin Li, Aijun Wang and 377 the working group. 379 8. Contributors 381 Haibo Wang 383 Huawei 385 Email: rainsword.wang@huawei.com 387 9. IANA Considerations 389 TBD. 391 10. Security Considerations 393 It is not believed that this document adds any additional security 394 considerations. 396 11. References 398 11.1. Normative References 400 [I-D.ietf-grow-bmp-adj-rib-out] 401 Evens, T., Bayraktar, S., Lucente, P., Mi, K., and S. 402 Zhuang, "Support for Adj-RIB-Out in BGP Monitoring 403 Protocol (BMP)", draft-ietf-grow-bmp-adj-rib-out-04 (work 404 in progress), March 2019. 406 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 407 Requirement Levels", BCP 14, RFC 2119, 408 DOI 10.17487/RFC2119, March 1997, 409 . 411 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 412 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 413 DOI 10.17487/RFC4271, January 2006, 414 . 416 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 417 Monitoring Protocol (BMP)", RFC 7854, 418 DOI 10.17487/RFC7854, June 2016, 419 . 421 [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 422 and B. Dickson, "Problem Definition and Classification of 423 BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 424 2016, . 426 11.2. Informative References 428 [Luckie] claffy, M. L. M. L. A. D. V. G. K., "AS Relationships, 429 Customer Cones, and Validation", October 2013. 431 [Siddiqui] 432 Ramirez, M. S. S. D. M. M. Y. R. S. X. M. W., "Route Leak 433 Detection Using Real-Time Analytics on local BGP 434 Information", 2014. 436 Authors' Addresses 438 Yunan Gu 439 Huawei 440 Huawei Bld., No.156 Beiqing Rd. 441 Beijing 100095 442 China 444 Email: guyunan@huawei.com 446 Huanan Chen 447 China Telecom Co., Ltd. 448 109 Zhongshan W Ave 449 Guangzhou 510630 450 China 452 Email: chenhn8.gd@chinatelecom.cn 453 Di Ma 454 ZDNS 455 4 South 4th St. Zhongguancun 456 Beijing, Haidian 457 China 459 Email: madi@zdns.cn 461 Shunwan Zhuang 462 Huawei 463 Huawei Bld., No.156 Beiqing Rd. 464 Beijing 100095 465 China 467 Email: zhuangshunwan@huawei.com