idnits 2.17.1 draft-gu-grow-bmp-route-leak-detection-04.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 (September 11, 2020) is 1313 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 419, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-grow-route-leak-detection-mitigation-03 == Outdated reference: A later version (-24) exists of draft-ietf-idr-bgp-open-policy-13 ** 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: March 15, 2021 China Telecom Co., Ltd. 6 D. Ma 7 ZDNS 8 S. Zhuang 9 Huawei 10 September 11, 2020 12 BMP for BGP Route Leak Detection 13 draft-gu-grow-bmp-route-leak-detection-04 15 Abstract 17 According to RFC7908 [RFC7908], Route leaks refer to the case that 18 the delivery range of route advertisements is beyond the expected 19 range. For many current security protection solutions, the ISPs 20 (Internet Service Providers) are focusing on finding ways to prevent 21 the happening of BGP [RFC4271] route leaks. However, the real-time 22 route leak detection if any occurs is important as well, and serves 23 as the basis for leak mitigation. This document extends the BGP 24 Monitoring Protocol (BMP) [RFC7854] to provide a routing security 25 scheme suitable for ISPs to detect BGP route leaks at the prefix 26 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 March 15, 2021. 50 Copyright Notice 52 Copyright (c) 2020 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 serveral 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 inlcude 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 seperately or combinely, 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 draft-ietf-idr-bgp-open-policy [I-D.ietf-idr-bgp-open-policy] updates 167 the BGP Open negotiation process with a new BGP capability to 168 exchange the BGP Roles between two BGP speakers, and also proposes to 169 use a new BGP attribute, called the iOTC (Internal Only To Customer) 170 Path attribute to mark routes according to the BGP Roles established 171 in Open Message. The iOTC attribute of the incoming route is set at 172 the ingress node of the local AS, and is conveyed with the BGP Update 173 to 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 draft-ietf-idr-bgp-open-policy 178 [I-D.ietf-idr-bgp-open-policy]. 180 draft-ietf-grow-route-leak-detection-mitigation 181 [I-D.ietf-grow-route-leak-detection-mitigation] describes a route 182 leak detection and mitigation solution based on conveying route-leak 183 protection (RLP) information in a well-know transitive BGP community, 184 called the RLP community. The RLP community helps with detection and 185 mitigation of route leaks that happen at the upstream AS (per the BGP 186 routes propagation), as an inter-AS solution. For representation 187 simplification,we use RLP to refer to the method specified in draft- 188 ietf-grow-route-leak-detection-mitigation 189 [I-D.ietf-grow-route-leak-detection-mitigation]. 191 The above two drafts provide solutions for route leak prevention, 192 detection and mitigation. To summarize: 194 o iOTC is used for route leak prevention of the local AS. It does 195 not provide the detection or mitigation of route leaks of either 196 local As or upstream AS per the BGP routes propagation. 198 o iOTC is peer/AS-level route leak prevention, due to the fact the 199 BGP Role negotiation is peer-level. It's does not provide prefix- 200 level route leak prevention. 202 o RLP is used for route leak detection and mitigation of route leak 203 that happens in the upstream AS (per the BGP Update distribution). 204 It is prefix-level detection and mitigation. 206 Thus, there lacks method for local AS route leak detection. 208 3. Route Leak Detection (RLD) Design Considerations 210 Considering the challenges facing the existing approaches, this draft 211 proposes a method called Route Leak Detection (RLD). It utilizes the 212 BGP Monitoring Protocol (BMP) to convey the RLD information from to 213 the BMP server to realize centralized leak detection. BMP is 214 currently deployed by OTT and carriers to monitor the BGP routes, 215 such as monitoring BGP Adj-RIB-In using the process defined in 216 RFC7854 [RFC7854], and monitoring BGP Adj-RIB-Out using the process 217 defined in RFC8671 [RFC8671]. On the other hand, the RLD information 218 is in fact a representation of the business relationships between the 219 local AS and its neighboring AS. It does not involve any information 220 disclosure issue regarding third parties. Thus, a single ISP can 221 deploy RLD without relying on any information from either other ISPs 222 or other third parties. 224 4. BMP Support for RLD 226 4.1. RLD TLV Format 228 A RLD TLV is defined for the BMP Route Monitoring Message. 229 Considering that the AS relationships are sometims per route based 230 instead of per peer/AS based, this TLV is appended to each route, 231 following the BGP Update Message. The order of placing the RLD TLV 232 among other BMP supported TLVs is out of the scope of this draft. 233 The TLV format is defined as follows: 235 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 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Type (2 octets) | Length (2 octets) | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Value(1 octet)| 240 +-+-+-+-+-+-+-+-+ 242 Figure 1: RLD TLV 244 o Type (2 octets) = TBD1, the RLD TLV represents the prefix-level 245 business relationship between the transmitter AS and the receiver 246 AS. The local AS is a transmitter or a receiver, depending on if 247 the route is an incoming route from a neighbor AS or an outgoing 248 route to a neighbor AS. 250 o Length (2 octets): Defines the length of the Value filed. It 251 SHOULD be set to 0x01, considering the Value field is of 1 octect 252 fixed length. 254 o Value (1 octet): Currently 4 values are defined to represent the 255 business relationships, which are specified in Table 1. 257 +-------+-------------+ 258 | Value | Business | 259 | | Relationship| 260 +---------------------+ 261 | 0 | P2C | 262 | 1 | C2P | 263 | 2 | P2P | 264 | 3 | I2I | 265 +-------+-------------+ 267 Table 1: Business relationship value 269 4.2. RLD TLV Usage 271 The RLD TLV, presenting the business relationship between the 272 neighbor AS and the local AS of the incoming route, SHOULD be 273 prepended to the Adj-rib-in at the ingress node of the local AS. The 274 RLD TLV, representing the business relationship between the local AS 275 and the neighbor AS of the outgoing route, SHOULD also be prepended 276 to the Adj-rib-out at the egress node of the local AS. The BMP 277 server, by analyzing the above two RLD TLVs of the same route, can 278 use the rules defined in RFC7908 [RFC7908] to detect the existence of 279 any route leak. As example is shown in Figure 2. 281 +------------+ 282 | BMP server | 283 +------> + +<-------+ 284 | | RLD server | | 285 + +------------+ + 286 BMP RM adj_rib_in: BMP RM adj_rib_out: 287 (AS2 --> AS1) (AS1 --> AS4) 288 P2C C2P 289 | + 290 ***|********************* | 291 * | * "Send Route 292 Route A * | AS1 +*+---> A to AS3" 293 +--> * | + * | +-----+ 294 +-----+ * +---+ +---+ *+P2C+-----+ AS3 +----+ ... 295 +--+ AS2 +---+P2C+*+-+ R1+---------+ R2| * | +-----+ 296 +-----+ * +-+-+\ +---+ * | 297 * | \\ // |\ * | 298 * | \\// | \ * "Do not send 299 * | //\ | \+-----> Route A to AS4" 300 * | // \\ | * | +-----+ 301 * | / \ | *+C2P+-----+ AS4 +----+ ... 302 * +-+-+ +-+-+ * | +-----+ 303 +--+ R3+---------+ R4+----------+ 304 * +---+ +---+ * 305 * * 306 ************************* 308 Figure 2: RLD depolyment by a single ISP 310 As shown in Figure 2, with the RLD TLV attached to each Route 311 Monitoring Message, the RLD server (also working as the BMP server) 312 combines the BMP adj_rib_in message collected from R1 and the BMP 313 adj_rib_out message collected from R4 to decide if there's a route 314 leak. For example, if the RLD TLV in R1's adj_rib_in message 315 indicates a value of "0", and the RLD TLV in R4's adj_rib_out message 316 indicates a value of "1", then the RLD server knows there exists a 317 route leak. 319 4.3. Coordination with iOTC and RLP 321 RLD can be used as a complementary method to the existing methods 322 against route leaks. More specifically, RLD can coordination with 323 both iOTC and RLP. 325 o With the settlement of the iOTC draft, the iOTC attribute is 326 naturally included in the BGP Update and can be collected to the 327 BMP server without BMP extension. With the RLD TLV collected also 328 by BMP (more specifically, the iBGP adj-rib-in of the ingress 329 node), the BMP server can do validate the consistency of the iOTC 330 attribute with the RLD. If contradiction detected, the BMP server 331 may further check the bussiness contract for the actual business 332 relationship. 334 o For special prefixes that does not obey the peer/AS level business 335 relationship negotiated through BGP Open Message, the BMP server 336 can use the RLD TLV to detect such routes since the RLD TLV is set 337 at prefix level. 339 o For devices that do not support RLP, using RLD to collect the BGP 340 routes, which conveys the RLD information from upstream ASes, 341 allows the BMP server to detect and mitigate the route leaks that 342 happen in the upstream AS. In other words, the detection and 343 mitigation process can be also done in the BMP server, should the 344 BMP server collects the BGP Update messages at the ingress or 345 egress nodes. 347 5. Acknowledgements 349 6. Contributors 351 Haibo Wang 353 Huawei 355 Email: rainsword.wang@huawei.com 357 7. IANA Considerations 359 This document defines the following new BMP Route Monitoring message 360 TLV type (Section 4.1): 362 o Type = TBD1, the RLD TLV represents the prefix-level business 363 relationship between the transmitter AS and the receiver AS. The 364 local AS is a transmitter or a receiver, depending on if the route 365 is an incoming route from a neighbor AS or an outgoing route to a 366 neighbor AS. 368 8. Security Considerations 370 It is not believed that this document adds any additional security 371 considerations. 373 9. References 375 9.1. Normative References 377 [I-D.ietf-grow-route-leak-detection-mitigation] 378 Sriram, K. and A. Azimov, "Methods for Detection and 379 Mitigation of BGP Route Leaks", draft-ietf-grow-route- 380 leak-detection-mitigation-03 (work in progress), July 381 2020. 383 [I-D.ietf-idr-bgp-open-policy] 384 Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K. 385 Sriram, "Route Leak Prevention using Roles in Update and 386 Open messages", draft-ietf-idr-bgp-open-policy-13 (work in 387 progress), July 2020. 389 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 390 Requirement Levels", BCP 14, RFC 2119, 391 DOI 10.17487/RFC2119, March 1997, 392 . 394 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 395 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 396 DOI 10.17487/RFC4271, January 2006, 397 . 399 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 400 Monitoring Protocol (BMP)", RFC 7854, 401 DOI 10.17487/RFC7854, June 2016, 402 . 404 [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 405 and B. Dickson, "Problem Definition and Classification of 406 BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 407 2016, . 409 [RFC8671] Evens, T., Bayraktar, S., Lucente, P., Mi, P., and S. 410 Zhuang, "Support for Adj-RIB-Out in the BGP Monitoring 411 Protocol (BMP)", RFC 8671, DOI 10.17487/RFC8671, November 412 2019, . 414 9.2. Informative References 416 [Luckie] claffy, M. L. M. L. A. D. V. G. K., "AS Relationships, 417 Customer Cones, and Validation", October 2013. 419 [Siddiqui] 420 Ramirez, M. S. S. D. M. M. Y. R. S. X. M. W., "Route Leak 421 Detection Using Real-Time Analytics on local BGP 422 Information", 2014. 424 Authors' Addresses 426 Yunan Gu 427 Huawei 428 Huawei Bld., No.156 Beiqing Rd. 429 Beijing 100095 430 China 432 Email: guyunan@huawei.com 434 Huanan Chen 435 China Telecom Co., Ltd. 436 109 Zhongshan W Ave 437 Guangzhou 510630 438 China 440 Email: chenhn8.gd@chinatelecom.cn 442 Di Ma 443 ZDNS 444 4 South 4th St. Zhongguancun 445 Beijing, Haidian 446 China 448 Email: madi@zdns.cn 450 Shunwan Zhuang 451 Huawei 452 Huawei Bld., No.156 Beiqing Rd. 453 Beijing 100095 454 China 456 Email: zhuangshunwan@huawei.com