idnits 2.17.1 draft-gu-grow-bmp-route-leak-detection-05.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], [RFC4271], [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 date (July 10, 2021) is 1021 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: 'Siddiqui' is defined on line 418, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-grow-route-leak-detection-mitigation-05 == Outdated reference: A later version (-24) exists of draft-ietf-idr-bgp-open-policy-15 ** 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: January 11, 2022 China Telecom Co., Ltd. 6 D. Ma 7 ZDNS 8 S. Zhuang 9 Huawei 10 July 10, 2021 12 BMP for BGP Route Leak Detection 13 draft-gu-grow-bmp-route-leak-detection-05 15 Abstract 17 According to Route-Leak Problem Definition [RFC7908], Route leaks 18 refer to the case that the delivery range of route advertisements is 19 beyond the expected range. For many current security protection 20 solutions, the ISPs (Internet Service Providers) are focusing on 21 finding ways to prevent the happening of BGP [RFC4271] route leaks. 22 However, the real-time route leak detection if any occurs is 23 important as well, and serves as the basis for leak mitigation. This 24 document extends the BGP Monitoring Protocol (BMP) [RFC7854] to 25 provide a routing security scheme suitable for ISPs to detect BGP 26 route leaks at the prefix level. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 11, 2022. 50 Copyright Notice 52 Copyright (c) 2021 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. Actions Against Route Leaks . . . . . . . . . . . . . . . 3 70 2.2. Challenges of the Current Actions against Route Leaks . . 4 71 3. Route Leak Detection (RLD) Design Considerations . . . . . . 5 72 4. BMP Support for RLD . . . . . . . . . . . . . . . . . . . . . 5 73 4.1. RLD TLV Format . . . . . . . . . . . . . . . . . . . . . 5 74 4.2. RLD TLV Usage . . . . . . . . . . . . . . . . . . . . . . 6 75 4.3. Coordination with iOTC and RLP . . . . . . . . . . . . . 7 76 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 77 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 82 9.2. Informative References . . . . . . . . . . . . . . . . . 9 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 85 1. Terminology 87 BMP: BGP Monitoring Protocol 89 BMS: BGP Monitoring Station 91 C2P: Customer to Provider 93 ISP: Internet Service Provider 95 P2C: Provider to Customer 96 P2P: Peer to Peer 98 RIB: Routing Information Base 100 RLP: Route Leak Protection 102 RLD: Route Leak Detection 104 2. Introduction 106 RFC7908 [RFC7908] defines "Route Leak" as: A route leak is the 107 propagation of routing announcement(s) beyond their intended scope, 108 which can result in possible situations such as eavesdropping, device 109 overload, routing black hole and so on. More specifically, the 110 intended scope of route announcements is usually defined by local 111 route filtering/distribution policies within devices. These policies 112 are designed to realise the pair-wise peering business relationships 113 between ASes (autonomous systems), which include Customer to Provider 114 (C2P), Peer to Peer (Peer to Peer), and Provider to Customer (P2C). 115 In a C2P relationship, the customer pays the transit provider for 116 traffic sent between the two ASes. In return, the customer gains 117 access to the ASes that the transit provider can reach, including 118 those which the transit provider reaches through its own transit 119 providers. In a P2P relationship, the peering ASes gain access to 120 each other's customers, typically without either AS paying the other 121 AS Relationships, Customer Cones, and Validation [Luckie]. 123 More precisely, the route leaks we discuss in this draft, referring 124 to Type 1, 2, 3, and 4 Route Leaks defined in RFC7908 [RFC7908], can 125 be summarized as: a route leak occurs when a route received from a 126 transit provider or a lateral peer is propagated to another transit 127 provider or a lateral peer. 129 2.1. Actions Against Route Leaks 131 There are several types of approaches against route leak from 132 different perspectives. In this draft, we mainly discuss the 133 following three types: 135 o Route leak prevention: The approach to prevent route leak from 136 happening. Commonly used methods include inbound/outbound 137 prefix/peer/AS filtering policies configured at the ingress/egress 138 nodes of ASes per the propagation of BGP routes. 140 o Route leak detection: The approach to detect the existence of 141 route leaks that happen at either the local AS, or upstream AS per 142 the propagation of BGP routes. An intuitive way of detecting 143 route leak is by checking the business relationship information at 144 both the ingress and egress nodes of the local AS along the BGP 145 route propagation path with the route leak violation rules defined 146 in RFC7908 [RFC7908]. Thus, it requires the knowledge of the 147 actual route propagation trace, as well as the resulting business 148 relationship information at the ingress and egress nodes. With 149 the above information collected, the analysis can be done by the 150 routing device or a centralized server. This draft specifies one 151 such method. 153 o Route leak mitigation: The approach to mitigate route leaks that 154 already happened at either the local AS, or upstream AS per the 155 propagation of BGP routes. Commonly used methods include reject, 156 drop or stop propagating the invalid routes once detected the 157 existence of leaks. 159 The above mentioned actions can be used alone or in combination, 160 depending on the entities (routing devices, network manager) that 161 execute the actions, and the relative positions of the executing 162 entities from the leaking point (local or downstream). 164 2.2. Challenges of the Current Actions against Route Leaks 166 Route Leak Prevention [I-D.ietf-idr-bgp-open-policy] updates the BGP 167 Open negotiation process with a new BGP capability to exchange the 168 BGP Roles between two BGP speakers, and also proposes to use a new 169 BGP attribute, called the iOTC (Internal Only To Customer) Path 170 attribute to mark routes according to the BGP Roles established in 171 Open Message. The iOTC attribute of the incoming route is set at the 172 ingress node of the local AS, and is conveyed with the BGP Update to 173 the egress node of the local AS for outbound filtering to prevent 174 route leaks in the local AS. This attribute is removed at the egress 175 node before the BGP Update is sent to eBGP neighbors. For 176 representation simplification, we use iOTC to refer to the method 177 specified in Route Leak Prevention [I-D.ietf-idr-bgp-open-policy]. 179 Route-Leak Detection and Mitigation 180 [I-D.ietf-grow-route-leak-detection-mitigation] describes a route 181 leak detection and mitigation solution based on conveying route-leak 182 protection (RLP) information in a well-known transitive BGP 183 community, called the RLP community. The RLP community helps with 184 detection and mitigation of route leaks that happen at the upstream 185 AS (per the BGP routes propagation), as an Inter-AS solution. For 186 representation simplification, we use RLP to refer to the method 187 specified in Route-Leak Detection and Mitigation 188 [I-D.ietf-grow-route-leak-detection-mitigation]. 190 The above two drafts provide solutions for route leak prevention, 191 detection and mitigation. To summarize: 193 o iOTC is used for route leak prevention of the local AS. It does 194 not provide the detection or mitigation of route leaks of either 195 local As or upstream AS per the BGP routes propagation. 197 o iOTC is peer/AS-level route leak prevention, due to the fact the 198 BGP Role negotiation is peer-level. It does not provide prefix- 199 level route leak prevention. 201 o RLP is used for route leak detection and mitigation of route leak 202 that happens in the upstream AS (per the BGP Update distribution). 203 It is prefix-level detection and mitigation. 205 Thus, there lacks method for local AS route leak detection. 207 3. Route Leak Detection (RLD) Design Considerations 209 Considering the challenges facing the existing approaches, this draft 210 proposes a method called Route Leak Detection (RLD). It utilizes the 211 BGP Monitoring Protocol (BMP) to convey the RLD information from to 212 the BMP server to realize centralized leak detection. BMP is 213 currently deployed by OTT and carriers to monitor the BGP routes, 214 such as monitoring BGP Adj-RIB-In using the process defined in 215 RFC7854 [RFC7854], and monitoring BGP Adj-RIB-Out using the process 216 defined in RFC8671 [RFC8671]. On the other hand, the RLD information 217 is in fact a representation of the business relationships between the 218 local AS and its neighboring AS. It does not involve any information 219 disclosure issue regarding third parties. Thus, a single ISP can 220 deploy RLD without relying on any information from either other ISPs 221 or other third parties. 223 4. BMP Support for RLD 225 4.1. RLD TLV Format 227 A RLD TLV is defined for the BMP Route Monitoring Message. 228 Considering that the AS relationships are sometimes per route based 229 instead of per peer/AS based, this TLV is appended to each route, 230 following the BGP Update Message. The order of placing the RLD TLV 231 among other BMP supported TLVs is out of the scope of this draft. 232 The TLV format is defined as follows: 234 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 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Type (2 octets) | Length (2 octets) | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Value(1 octet)| 239 +-+-+-+-+-+-+-+-+ 241 Figure 1: RLD TLV 243 o Type (2 octets) = TBD1, the RLD TLV represents the prefix-level 244 business relationship between the transmitter AS and the receiver 245 AS. The local AS is a transmitter or a receiver, depending on if 246 the route is an incoming route from a neighbor AS or an outgoing 247 route to a neighbor AS. 249 o Length (2 octets): Defines the length of the Value filed. It 250 SHOULD be set to 0x01, considering the Value field is of 1 octet 251 fixed length. 253 o Value (1 octet): Currently 4 values are defined to represent the 254 business relationships, which are specified in Table 1. 256 +-------+-------------+ 257 | Value | Business | 258 | | Relationship| 259 +---------------------+ 260 | 0 | P2C | 261 | 1 | C2P | 262 | 2 | P2P | 263 | 3 | I2I | 264 +-------+-------------+ 266 Table 1: Business relationship value 268 4.2. RLD TLV Usage 270 The RLD TLV, presenting the business relationship between the 271 neighbor AS and the local AS of the incoming route, SHOULD be 272 prepended to the Adj-RIB-In at the ingress node of the local AS. The 273 RLD TLV, representing the business relationship between the local AS 274 and the neighbor AS of the outgoing route, SHOULD also be prepended 275 to the Adj-RIB-Out at the egress node of the local AS. The BMP 276 server, by analyzing the above two RLD TLVs of the same route, can 277 use the rules defined in RFC7908 [RFC7908] to detect the existence of 278 any route leak. As example is shown in Figure 2. 280 +------------+ 281 | BMP server | 282 +------> + +<-------+ 283 | | RLD server | | 284 + +------------+ + 285 BMP Adj_RIB_In: BMP Adj_RIB_Out: 286 (AS2 --> AS1) (AS1 --> AS4) 287 P2C C2P 288 | + 289 ***|********************* | 290 * | * "Send Route 291 Route A * | AS1 +*+---> A to AS3" 292 +--> * | + * | +-----+ 293 +-----+ * +---+ +---+ *+P2C+-----+ AS3 +----+ ... 294 +--+ AS2 +---+P2C+*+-+ R1+---------+ R2| * | +-----+ 295 +-----+ * +-+-+\ +---+ * | 296 * | \\ // |\ * | 297 * | \\// | \ * "Do not send 298 * | //\ | \+-----> Route A to AS4" 299 * | // \\ | * | +-----+ 300 * | / \ | *+C2P+-----+ AS4 +----+ ... 301 * +-+-+ +-+-+ * | +-----+ 302 +--+ R3+---------+ R4+----------+ 303 * +---+ +---+ * 304 * * 305 ************************* 307 Figure 2: RLD depolyment by a single ISP 309 As shown in Figure 2, with the RLD TLV attached to each Route 310 Monitoring Message, the RLD server (also working as the BMP server) 311 combines the BMP Adj_RIB_In message collected from R1 and the BMP 312 Adj_RIB_Out message collected from R4 to decide if there's a route 313 leak. For example, if the RLD TLV in R1's Adj_RIB_In message 314 indicates a value of "0", and the RLD TLV in R4's Adj_RIB_Out message 315 indicates a value of "1", then the RLD server knows there exists a 316 route leak. 318 4.3. Coordination with iOTC and RLP 320 RLD can be used as a complementary method to the existing methods 321 against route leaks. More specifically, RLD can coordination with 322 both iOTC and RLP. 324 o With the settlement of the iOTC draft, the iOTC attribute is 325 naturally included in the BGP Update and can be collected to the 326 BMP server without BMP extension. With the RLD TLV collected also 327 by BMP (more specifically, the iBGP Adj-RIB-In of the ingress 328 node), the BMP server can do validate the consistency of the iOTC 329 attribute with the RLD. If contradiction detected, the BMP server 330 may further check the bussiness contract for the actual business 331 relationship. 333 o For special prefixes that does not obey the peer/AS level business 334 relationship negotiated through BGP Open Message, the BMP server 335 can use the RLD TLV to detect such routes since the RLD TLV is set 336 at prefix level. 338 o For devices that do not support RLP, using RLD to collect the BGP 339 routes, which conveys the RLD information from upstream ASes, 340 allows the BMP server to detect and mitigate the route leaks that 341 happen in the upstream AS. In other words, the detection and 342 mitigation process can be also done in the BMP server, should the 343 BMP server collects the BGP Update messages at the ingress or 344 egress nodes. 346 5. Acknowledgements 348 6. Contributors 350 Haibo Wang 352 Huawei 354 Email: rainsword.wang@huawei.com 356 7. IANA Considerations 358 This document defines the following new BMP Route Monitoring message 359 TLV type (Section 4.1): 361 o Type = TBD1, the RLD TLV represents the prefix-level business 362 relationship between the transmitter AS and the receiver AS. The 363 local AS is a transmitter or a receiver, depending on if the route 364 is an incoming route from a neighbor AS or an outgoing route to a 365 neighbor AS. 367 8. Security Considerations 369 It is not believed that this document adds any additional security 370 considerations. 372 9. References 374 9.1. Normative References 376 [I-D.ietf-grow-route-leak-detection-mitigation] 377 Sriram, K. and A. Azimov, "Methods for Detection and 378 Mitigation of BGP Route Leaks", draft-ietf-grow-route- 379 leak-detection-mitigation-05 (work in progress), April 380 2021. 382 [I-D.ietf-idr-bgp-open-policy] 383 Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K. 384 Sriram, "Route Leak Prevention using Roles in Update and 385 Open messages", draft-ietf-idr-bgp-open-policy-15 (work in 386 progress), January 2021. 388 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 389 Requirement Levels", BCP 14, RFC 2119, 390 DOI 10.17487/RFC2119, March 1997, 391 . 393 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 394 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 395 DOI 10.17487/RFC4271, January 2006, 396 . 398 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 399 Monitoring Protocol (BMP)", RFC 7854, 400 DOI 10.17487/RFC7854, June 2016, 401 . 403 [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 404 and B. Dickson, "Problem Definition and Classification of 405 BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 406 2016, . 408 [RFC8671] Evens, T., Bayraktar, S., Lucente, P., Mi, P., and S. 409 Zhuang, "Support for Adj-RIB-Out in the BGP Monitoring 410 Protocol (BMP)", RFC 8671, DOI 10.17487/RFC8671, November 411 2019, . 413 9.2. Informative References 415 [Luckie] claffy, M. L. M. L. A. D. V. G. K., "AS Relationships, 416 Customer Cones, and Validation", October 2013. 418 [Siddiqui] 419 Ramirez, M. S. S. D. M. M. Y. R. S. X. M. W., "Route Leak 420 Detection Using Real-Time Analytics on local BGP 421 Information", 2014. 423 Authors' Addresses 425 Yunan Gu 426 Huawei 427 Huawei Bld., No.156 Beiqing Rd. 428 Beijing 100095 429 China 431 Email: guyunan@huawei.com 433 Huanan Chen 434 China Telecom Co., Ltd. 435 109 Zhongshan W Ave 436 Guangzhou 510630 437 China 439 Email: chenhn8.gd@chinatelecom.cn 441 Di Ma 442 ZDNS 443 4 South 4th St. Zhongguancun 444 Beijing, Haidian 445 China 447 Email: madi@zdns.cn 449 Shunwan Zhuang 450 Huawei 451 Huawei Bld., No.156 Beiqing Rd. 452 Beijing 100095 453 China 455 Email: zhuangshunwan@huawei.com