idnits 2.17.1 draft-gu-grow-bmp-route-leak-detection-00.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 (October 22, 2018) is 2013 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 274, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-grow-bmp-adj-rib-out-02 ** 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 S. Zhuang 4 Intended status: Standards Track Huawei 5 Expires: April 25, 2019 October 22, 2018 7 BMP for BGP Route Leak Detection 8 draft-gu-grow-bmp-route-leak-detection-00 10 Abstract 12 According to RFC7908 [RFC7908], Route leaks refer to case that the 13 delivery range of route advertisements is beyond the expected range. 14 For many current security protection solutions, the ISPs (Internet 15 Service Providers) are focusing on finding ways to detect the 16 happening of route leaks. However, the real-time route leak 17 detection if any occurs is important as well. This document extends 18 the BGP Monitoring Protocol (BMP) [RFC7854] to provide a routing 19 security scheme suitable for ISPs to detect BGP route leaks within 20 their own networks. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 25, 2019. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2.1. ISP Route Leak Prevention Methods . . . . . . . . . . . . 3 65 2.2. Challenge of the Current Route Leak Prevention Methods . 4 66 3. Existing RLD Methods Discussion . . . . . . . . . . . . . . . 4 67 4. BMP Extension for RLD . . . . . . . . . . . . . . . . . . . . 5 68 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 73 8.2. Informative References . . . . . . . . . . . . . . . . . 7 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Terminology 78 BMP: BGP Monitoring Protocol 80 BMS: BGP Monitoring Station 82 C2P: Customer to Provider 84 ISP: Internet Service Provider 86 P2P: Peer to Peer 88 RIB: Routing Information Base 90 RLD: Route Leak Detection 92 2. Introduction 94 RFC 7908 defines "Route Leak" as: A route leak is the propagation of 95 routing announcement(s) beyond their intended scope, which can result 96 in possible situations such as eavesdropping, device overload, route 97 black hole and so on. More specifically, the intended scope of route 98 announcements is usually defined by local route filtering/ 99 distribution policies within devices. These policies are designed to 100 realise the pair-wise peering business relationships between ASes 101 (autonomous systems), which include Customer to Provider (C2P), Peer 102 to Peer (Peer to Peer), and Provider to Customer (P2C). In a C2P 103 relationship, the customer pays the provider for traffic sent between 104 the two ASes. In return, the customer gains access to the ASes the 105 provider can reach, including those which the provider reaches 106 through its own providers. In a P2P relationship, the peering ASes 107 gain access to each other's customers, typically without either AS 108 paying the other[Luckie]. RFC 7908 classifies six typical route 109 leaks situations based on the documented events. 111 2.1. ISP Route Leak Prevention Methods 113 Since BGP itself does not provide any route leak prevention/ 114 protection, in the current networks, network administrators/operators 115 typically configure export policies on the AS border routers (ASBRs) 116 to prevent route leak. For example, refer to the topology in 117 Figure 1, an export policy is configured at ASBR R2 of AS1. The 118 export strategy is, for example, "routes from AS2 can be sent to AS3 119 and cannot be sent to AS4." After ASBR R1 of AS1 receives a route A 120 from AS2, R1 marks A with BGP community attribute stating that route 121 A is received from AS2. Then route A with this tag is transmitted to 122 another ASBR R2 through the intermediate node of AS1. Now at ASBR 123 R2, it checks the export filter/policy to determine if Route A with 124 the tag is allowed to be distributed to a certain AS. This tag 125 stands for the peering business relationship between AS 2 and AS 1, 126 so that ASBR R2 of AS 1 can use it to determine which ASes Route A 127 can and cannot be distributed to prevent route leak (i.e., 128 distributing Route A to the wrong AS). Suppose the destination AS of 129 the route A is AS4, then R2 will not distribute Route A to AS4 were 130 the export policies correctly configured. 132 ************************* 133 * * 134 Route A * AS1 * 135 ---> * -----> Send A to AS3 136 +-----+ * +---+ +---+ * +-----+ 137 ... ---| AS2 |----|R1 |-----+---|R2 |-----| AS3 |--- ... 138 +-----+ * +---+\ +---+ * +-----+ 139 * | \\ // |\ --X-- Not send A to AS4 140 * | \\// | \ * +-----+ 141 . * | //\ | \----| AS4 |--- ... 142 * | // \\ | * +-----+ 143 * | / \ | * 144 * +---+ +---+ * 145 . ---|R3 |---------|R4 | * 146 * +---+ +---+ * 147 * * 148 ************************* 150 Figure 1: Routing between ISPs 152 2.2. Challenge of the Current Route Leak Prevention Methods 154 However, it could happen that the export policies configured at ASBRs 155 to prevent route leak are incorrect. Thus, when the route leak 156 prevnetion methods do not work, there requires a valid method to 157 detect any occurred leak in a timely manner so that the incorrect 158 policies/configurations can be modified to avoid further leak 159 affection. 161 3. Existing RLD Methods Discussion 163 There are some existing methods proposed for Route Leak Detection 164 (RLD). 166 Many attempts have been made to infer relationships and strategies 167 between ASs, however, the accuracy of these techniques is often 168 questioned. It's mainly due to the fact that the knowledge base for 169 inferring the AS relationships and their corresponding export 170 policies is limited to the routing information available at the data 171 collection points. In particular, the increase in the number of 172 Internet Exchange Points (IXPs) and their role in the recent 173 "flattening" of the Internet topology, makes that a large fraction of 174 AS relationships cannot be discovered using these data collection 175 points [Siddiqui]. 177 Moreover, some other technologies extend existing routing protocols 178 to realize RLD. For example, modify the BGP update message, which 179 may bring about compatibility problems involved in the implementation 180 of the solution. Beside, new extension brings interoperation, device 181 upgrade problems. Thus, extending the routing protocols to do RLD 182 should not be the first choice if there can be other options. 184 Considering the implementation details, different ISPs may have 185 concerns regarding security related data disclosure. Some BGP 186 monitoring tools, such as Looking Glass, not only require third-party 187 information to be collected in multiple favorable locations, but also 188 have limited knowledge of inter-domain routing status information 189 (some ISPs are reluctant to provide some information for 190 confidentiality reasons). This has led to the current BGP monitoring 191 tools not being well used by various ISPs. For this reason, a RLD 192 solution should try to avoid reliance on any third party ISP data 193 availability. 195 Summarizing the above discussions, we have identified the following 196 requirements when design a RLD solution: 198 Consideration 1: A route security protection scheme that a single 199 carrier can deploy. 201 Consideration 2: No changes required to control plane protocols 202 (e.g., BGP); 204 Consideration 3: No reliance on third party ISP information; 206 4. BMP Extension for RLD 207 +--------+ 208 | RLD | 209 | Server | 210 +--|-----+ 211 | 212 *************|*********** 213 * ISP A | * 214 * AS A1 | * 215 AS B1 * | * AS E1 216 +-------+ * +---+ | +---+ * +-------+ 217 ... ---| ISP B |----|R1 |-----+---|R2 |-----| ISP E |--- ... 218 +-------+ * +---+\ +---+ * +-------+ 219 AS C1 * /| \\ // | * AS F1 220 +-------+ * / | \\// | * +-------+ 221 ... ---| ISP C |--- | //\ | /---| ISP F |--- ... 222 +-------+ * | // \\ | / * +-------+ 223 AS D1 * | / \ | / * AS G1 224 +-------+ * +---+ +---+ * +-------+ 225 ... ---| ISP D |----|R3 |---------|R4 |-----| ISP G |--- ... 226 +-------+ * +---+ +---+ * +-------+ 227 * * 228 ************************* 230 Figure 2: RLD Server for One ISP 232 Considering the above mentioned factors, BMP is a good choice for 233 RLD, which has no dependency on third-party ISP, and no extension 234 required for routing protocols. Beside, by collecting information 235 using BMP from devices is not an RLD inferring method, which provides 236 true validation of ASes' peering business relationships. 238 We can use BMP (BGP Monitoring Protocol) to easily monitor BGP 239 routes, such as monitoring BGP Adj-RIB-In using the process defined 240 in [RFC7854], and monitoring BGP Adj-RIB-Out using the process 241 defined in [I-D.ietf-grow-bmp-adj-rib-out]. BMP is a management 242 plane protocol and a non-control plane protocol. Therefore, the use 243 of BMP does not impact the processing of BGP protocol, because BMP 244 can monitor the BGP protocol after the BGP protocol converges. This 245 document ... 247 5. Acknowledgements 249 TBD. 251 6. IANA Considerations 253 TBD. 255 7. Security Considerations 257 TBD. 259 8. References 261 8.1. Normative References 263 [I-D.ietf-grow-bmp-adj-rib-out] 264 Evens, T., Bayraktar, S., Lucente, P., Mi, K., and S. 265 Zhuang, "Support for Adj-RIB-Out in BGP Monitoring 266 Protocol (BMP)", draft-ietf-grow-bmp-adj-rib-out-02 (work 267 in progress), September 2018. 269 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 270 Requirement Levels", BCP 14, RFC 2119, 271 DOI 10.17487/RFC2119, March 1997, 272 . 274 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 275 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 276 DOI 10.17487/RFC4271, January 2006, 277 . 279 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 280 Monitoring Protocol (BMP)", RFC 7854, 281 DOI 10.17487/RFC7854, June 2016, 282 . 284 [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 285 and B. Dickson, "Problem Definition and Classification of 286 BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 287 2016, . 289 8.2. Informative References 291 [Luckie] "AS Relationships, Customer Cones, and Validation", 292 October 2013. 294 [Siddiqui] 295 "Route Leak Detection Using Real-Time Analytics on local 296 BGP Information", 2014. 298 Authors' Addresses 300 Yunan Gu 301 Huawei 302 Huawei Bld., No.156 Beiqing Rd. 303 Beijing 100095 304 China 306 Email: guyunan@huawei.com 308 Shunwan Zhuang 309 Huawei 310 Huawei Bld., No.156 Beiqing Rd. 311 Beijing 100095 312 China 314 Email: zhuangshunwan@huawei.com