idnits 2.17.1 draft-gu-grow-bmp-route-leak-detection-03.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 date (July 8, 2019) is 1746 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 399, but no explicit reference was found in the text == Unused Reference: 'Siddiqui' is defined on line 419, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-grow-bmp-adj-rib-out-06 == Outdated reference: A later version (-10) exists of draft-ietf-grow-route-leak-detection-mitigation-00 == Outdated reference: A later version (-24) exists of draft-ietf-idr-bgp-open-policy-05 ** Downref: Normative reference to an Informational RFC: RFC 7908 Summary: 2 errors (**), 0 flaws (~~), 6 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 9, 2020 China Telecom Co., Ltd. 6 D. Ma 7 ZDNS 8 S. Zhuang 9 Huawei 10 July 8, 2019 12 BMP for BGP Route Leak Detection 13 draft-gu-grow-bmp-route-leak-detection-03 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 prevent the 21 happening of route leaks. However, the real-time route leak 22 detection if any occurs is important as well, and serves as the basis 23 for leak mitigation. This document extends the BGP Monitoring 24 Protocol (BMP) [RFC7854] to provide a routing security scheme 25 suitable for ISPs to detect BGP route leaks at the prefix level. 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 January 9, 2020. 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. 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 P2P: Peer to Peer 97 RIB: Routing Information Base 98 RLP: Route Leak Protection 100 RLD: Route Leak Detection 102 2. Introduction 104 RFC 7908 defines "Route Leak" as: A route leak is the propagation of 105 routing announcement(s) beyond their intended scope, which can result 106 in possible situations such as eavesdropping, device overload, route 107 black hole and so on. More specifically, the intended scope of route 108 announcements is usually defined by local route filtering/ 109 distribution policies within devices. These policies are designed to 110 realise the pair-wise peering business relationships between ASes 111 (autonomous systems), which include Customer to Provider (C2P), Peer 112 to Peer (Peer to Peer), and Provider to Customer (P2C). In a C2P 113 relationship, the customer pays the transit provider for traffic sent 114 between the two ASes. In return, the customer gains access to the 115 ASes that the transit provider can reach, including those which the 116 transit provider reaches through its own transit providers. In a P2P 117 relationship, the peering ASes gain access to each other's customers, 118 typically without either AS paying the other AS Relationships, 119 Customer Cones, and Validation [Luckie]. 121 More precisely, the route leaks we discuss in this draft, referring 122 to Type 1, 2, 3, and 4 Route Leaks defined in RFC 7908, can be 123 summarized as: a route leak occurs when a route received from a 124 transit provider or a lateral peer is propagated to another transit 125 provider or a lateral peer. 127 2.1. Actions Against Route Leaks 129 There are serveral types of approaches against route leak from 130 different perspectives. In this draft, we mainly discuss the 131 following three types: 133 o Route leak prevention: The approach to prevent route leak from 134 happening. Commonly used methods inlcude inbound/outbound 135 prefix/peer/AS filtering policies configured at the ingress/egress 136 nodes of ASes per the propagation of BGP routes. 138 o Route leak detection: The approach to detect the existence of 139 route leaks that happen at either the local AS, or upstream AS per 140 the propagation of BGP routes. An intuitive way of detecting 141 route leak is by checking the business relationship information at 142 both the ingress and egress nodes of the local AS along the BGP 143 route propagation path with the route leak violation rules defined 144 in RFC7908 [RFC7908]. Thus, it requires the knowledge of the 145 actual route propagation trace, as well as the resulting business 146 relationship information at the ingress and egress nodes. With 147 the above information collected, the analysis can be done by the 148 routing device or a centralized server. This draft specifies one 149 such method. 151 o Route leak mitigation: The approach to mitigate route leaks that 152 already happened at either the local AS, or upstream AS per the 153 propagation of BGP routes. Commonly used methods include reject, 154 drop or stop propagating the invalid routes once detected the 155 existence of leaks. 157 The above mentioned actions can be used seperately or combinely, 158 depending on the entities (routing devices, network manager) that 159 execute the actions, and the relative positions of the executing 160 entities from the leaking point (local or downstream). 162 2.2. Challenges of the Current Actions against Route Leaks 164 draft-ietf-idr-bgp-open-policy [I-D.ietf-idr-bgp-open-policy] updates 165 the BGP Open negotiation process with a new BGP capability to 166 exchange the BGP Roles between two BGP speakers, and also proposes to 167 use a new BGP attribute, called the iOTC (Internal Only To Customer) 168 Path attribute to mark routes according to the BGP Roles established 169 in Open Message. The iOTC attribute of the incoming route is set at 170 the ingress node of the local AS, and is conveyed with the BGP Update 171 to the egress node of the local AS for outbound filtering to prevent 172 route leaks in the local AS. This attribute is removed at the egress 173 node before the BGP Update is sent to eBGP neighbors. For 174 representation simplification,we use iOTC to refer to the method 175 specified in draft-ietf-idr-bgp-open-policy 176 [I-D.ietf-idr-bgp-open-policy]. 178 draft-ietf-grow-route-leak-detection-mitigation 179 [I-D.ietf-grow-route-leak-detection-mitigation] describes a route 180 leak detection and mitigation solution based on conveying route-leak 181 protection (RLP) information in a well-know transitive BGP community, 182 called the RLP community. The RLP community helps with detection and 183 mitigation of route leaks that happen at the upstream AS (per the BGP 184 routes propagation), as an inter-AS solution. For representation 185 simplification,we use RLP to refer to the method specified in draft- 186 ietf-grow-route-leak-detection-mitigation 187 [I-D.ietf-grow-route-leak-detection-mitigation]. 189 The above two drafts provide solutions for route leak prevention, 190 detection and mitigation. To summarize: 192 o iOTC is used for route leak prevention of the local AS. It does 193 not provide the detection or mitigation of route leaks of either 194 local As or upstream AS per the BGP routes propagation. 196 o iOTC is peer/AS-level route leak prevention, due to the fact the 197 BGP Role negotiation is peer-level. It's does not provide prefix- 198 level route leak prevention. 200 o RLP is used for route leak detection and mitigation of route leak 201 that happens in the upstream AS (per the BGP Update distribution). 202 It is prefix-level detection and mitigation. 204 Thus, there lacks method for local AS route leak detection. 206 3. Route Leak Detection (RLD) Design Considerations 208 Considering the challenges facing the existing approaches, this draft 209 proposes a method called Route Leak Detection (RLD). It utilizes the 210 BGP Monitoring Protocol (BMP) to convey the RLD information from to 211 the BMP server to realize centralized leak detection. BMP is 212 currently deployed by OTT and carriers to monitor the BGP routes, 213 such as monitoring BGP Adj-RIB-In using the process defined in 214 RFC7854 [RFC7854], and monitoring BGP Adj-RIB-Out using the process 215 defined in draft-ietf-grow-bmp-adj-rib-out 216 [I-D.ietf-grow-bmp-adj-rib-out]. On the other hand, the RLD 217 information is in fact a representation of the business relationships 218 between the local AS and its neighboring AS. It does not involve any 219 information disclosure issue regarding third parties. Thus, a single 220 ISP can deploy RLD without relying on any information from either 221 other ISPs 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 sometims 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 octect 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 RM adj_rib_in: BMP RM 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-bmp-adj-rib-out] 377 Evens, T., Bayraktar, S., Lucente, P., Mi, K., and S. 378 Zhuang, "Support for Adj-RIB-Out in BGP Monitoring 379 Protocol (BMP)", draft-ietf-grow-bmp-adj-rib-out-06 (work 380 in progress), June 2019. 382 [I-D.ietf-grow-route-leak-detection-mitigation] 383 Sriram, K. and A. Azimov, "Methods for Detection and 384 Mitigation of BGP Route Leaks", draft-ietf-grow-route- 385 leak-detection-mitigation-00 (work in progress), April 386 2019. 388 [I-D.ietf-idr-bgp-open-policy] 389 Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K. 390 Sriram, "Route Leak Prevention using Roles in Update and 391 Open messages", draft-ietf-idr-bgp-open-policy-05 (work in 392 progress), February 2019. 394 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 395 Requirement Levels", BCP 14, RFC 2119, 396 DOI 10.17487/RFC2119, March 1997, 397 . 399 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 400 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 401 DOI 10.17487/RFC4271, January 2006, 402 . 404 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 405 Monitoring Protocol (BMP)", RFC 7854, 406 DOI 10.17487/RFC7854, June 2016, 407 . 409 [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 410 and B. Dickson, "Problem Definition and Classification of 411 BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 412 2016, . 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