idnits 2.17.1 draft-ymbk-idr-bgp-open-policy-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (November 14, 2016) is 2719 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) == Outdated reference: A later version (-11) exists of draft-ietf-idr-route-leak-detection-mitigation-03 == Outdated reference: A later version (-23) exists of draft-ietf-sidr-bgpsec-protocol-15 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Azimov 3 Internet-Draft E. Bogomazov 4 Intended status: Standards Track Qrator Labs 5 Expires: May 18, 2017 R. Bush 6 Internet Initiative Japan 7 K. Patel 8 Arrcus, Inc. 9 K. Sriram 10 US NIST 11 November 14, 2016 13 Route Leak Detection and Filtering using Roles in Update and Open 14 messages 15 draft-ymbk-idr-bgp-open-policy-02 17 Abstract 19 Route Leaks are the propagation of BGP prefixes which violate 20 assumptions of BGP topology relationships; e.g. passing a route 21 learned from one peer to another peer or to a transit provider, 22 passing a route learned from one transit provider to another transit 23 provider or to a peer. Today, approaches to leak prevention rely on 24 marking routes according to operator configuration options without 25 any check that the configuration corresponds to that of the BGP 26 neighbor, or enforcement that the two BGP speakers agree on the 27 relationship. This document enhances BGP Open to establish agreement 28 of the (peer, customer, provider, internal) relationship of two 29 neighboring BGP speakers to enforce appropriate configuration on both 30 sides. Propagated routes are then marked with a eOTC and iOTC 31 attributes according to agreed relationship allowing prevention and 32 detection of route leaks. 34 Requirements Language 36 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 37 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to 38 be interpreted as described in RFC 2119 [RFC2119] only when they 39 appear in all upper case. They may also appear in lower or mixed 40 case as English words, without normative meaning. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at http://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on May 18, 2017. 59 Copyright Notice 61 Copyright (c) 2016 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Role Definitions . . . . . . . . . . . . . . . . . . . . . . 4 78 3. BGP Role . . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 4. Role capability . . . . . . . . . . . . . . . . . . . . . . . 5 80 5. Role correctness . . . . . . . . . . . . . . . . . . . . . . 5 81 5.1. Strict mode . . . . . . . . . . . . . . . . . . . . . . . 6 82 6. Restrictions on the Complex role . . . . . . . . . . . . . . 6 83 7. BGP Internal Only To Customer attribute . . . . . . . . . . . 6 84 8. BGP External Only To Customer attribute . . . . . . . . . . . 7 85 9. Compatibility with BGPsec . . . . . . . . . . . . . . . . . . 8 86 10. Additional Considerations . . . . . . . . . . . . . . . . . . 8 87 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 88 12. Security Considerations . . . . . . . . . . . . . . . . . . . 9 89 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 90 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 91 14.1. Normative References . . . . . . . . . . . . . . . . . . 9 92 14.2. Informative References . . . . . . . . . . . . . . . . . 10 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 95 1. Introduction 97 For the purpose of this document, BGP route leaks are when a BGP 98 route was learned from transit provider or peer and is announced to 99 another provider or peer. See 100 [I-D.ietf-grow-route-leak-problem-definition]. These are usually the 101 result of misconfigured or absent BGP route filtering or lack of 102 coordination between two BGP speakers. 104 [I-D.ietf-idr-route-leak-detection-mitigation] describes a method of 105 marking and detecting leaks which relies on operator maintained 106 markings. Unfortunately, in most cases, a leaking router will likely 107 also be misconfigured to mark incorrectly. The mechanism proposed in 108 that draft provides the opportunity to detect route leaks made by 109 third parties but provides no support to strongly prevent route leak 110 creation. The leak prevention still relies on communities which are 111 optional and often missed due to mistakes or misunderstanding of the 112 BGP configuration process. 114 It has been suggested to use white list filtering, relying on knowing 115 the prefixes in the peer's customer cone as import filtering, in 116 order to detect route leaks. Unfortunately, a large number of 117 incidents in medium transit operators use a single prefix list as 118 only the ACL for export filtering, without community tagging and 119 without paying attention to the source of a learned route. So, if 120 they learn a customer's route from their provider or peer - they will 121 announce it in all directions, including other providers or peers. 122 This misconfiguration affects a limited number of prefixes; but such 123 route leaks will obviously bypass customer cone import filtering made 124 by upper level upstream providers. 126 Also, route tagging which relies on operator maintained policy 127 configuration is too easily and too often misconfigured. 129 This document specifies a new BGP Capability Code, [RFC5492] Sec 4, 130 which two BGP speakers MAY use to ensure that they MUST agree on 131 their relationship; i.e. customer and provider or peers. Either or 132 both may optionally be configured to require that this option be 133 exchanged for the BGP Open to succeed. 135 Also this document specifies a way to mark routes according to BGP 136 Roles established in Open and a way to create double-boundary filters 137 for prevention and detection of route leaks via a two new BGP Path 138 Attributes. 140 2. Role Definitions 142 As many of these terms are used differently in various contexts, it 143 is worth being explicit. 145 A Provider: sends their own routes and (possibly) a subset of routes 146 learned from their other customers, peers, and transit providers 147 to their customer. 149 A Customer: accepts 'transit routes' from its provider(s) and 150 announces their own routes and the routes they have learned from 151 the transitive closure of their customers (AKA their 'customer 152 cone') to their provider(s). 154 A Peer: announces their routes and the routes from their customer 155 cone to other Peers. 157 An Internal BGP Neighbor has one of the above relationships to 158 another internal BGP AS. 160 A Complex BGP relationship is an attempt to allow those whose policy 161 may vary by prefix. It is aptly named and the authors question 162 its real utility. 164 Of course, any BGP speaker may apply policy to reduce what is 165 announced, and a recipient may apply policy to reduce the set of 166 routes they accept. 168 3. BGP Role 170 BGP Role is new mandatory configuration option which must be set per 171 each address family. It reflects the real-world agreement between 172 two BGP speakers about their business relationship. 174 Allowed Role values are: 176 o Provider - sender is a transit provider to neighbor; 178 o Customer - sender is customer of neighbor; 180 o Peer - sender and neighbor are peers; 182 o Internal - sender is part of an internal AS of an organization 183 which has multiple ASs, or is a confederation, etc. 185 o Complex - sender has a non-standard relationship and wants to use 186 manual per-prefix based role policies. 188 Since BGP Role reflects the relationship between two BGP speakers, it 189 could also be used for more than route leak mitigation. 191 4. Role capability 193 The TLV (type, length, value) of the BGP Role capability are: 195 o Type - ; 197 o Length - 1 (octet); 199 o Value - integer corresponding to speaker' BGP Role. 201 +--------+----------------------+ 202 | Value | Role name | 203 +--------+----------------------+ 204 | 0 | Undefined | 205 | 1 | Sender is Peer | 206 | 2 | Sender is Provider | 207 | 3 | Sender is Customer | 208 | 4 | Sender is Internal | 209 | 5 | Sender is Complex | 210 +--------+----------------------+ 212 Table 1: Predefined BGP Role Values 214 5. Role correctness 216 Section 3 described how BGP Role is a reflection of the relationship 217 between two BGP speakers. But the mere presence of BGP Role doesn't 218 automatically guarantee role agreement between two BGP peers. 220 To enforce correctness, the BGP Role check is used with a set of 221 constrains on how speakers' BGP Roles MUST corresponded. Of course, 222 each speaker MUST announce and accept the BGP Role capability in the 223 BGP OPEN message exchange. 225 If a speaker receives a BGP Role capability, it SHOULD check value of 226 the received capability with its own BGP Role. The allowed pairings 227 are (first a sender's Role, second the receiver's Role): 229 +--------------+----------------+ 230 | Sender Role | Receiver Role | 231 +--------------+----------------+ 232 | Peer | Peer | 233 | Provider | Customer | 234 | Customer | Provider | 235 | Internal | Internal | 236 | Complex | Complex | 237 +--------------+----------------+ 239 Table 2: Allowed Role Capabilities 241 In all other cases speaker MUST send a Role Mismatch Notification 242 (code 2, sub-code ). 244 5.1. Strict mode 246 A new BGP configuration option "strict mode" is defined with values 247 of true or false. If set to true, then the speaker MUST refuse to 248 establish a BGP session with peers which do not announce the BGP Role 249 capability in their OPEN message. If a speaker rejects a connection, 250 it MUST send a Connection Rejected Notification [RFC4486] 251 (Notification with error code 6, subcode 5). By default strict mode 252 SHOULD be set to false for backward compatibility with BGP speakers, 253 that do not yet support this mechanism. 255 6. Restrictions on the Complex role 257 The Complex role should be set only if the relationship between BGP 258 neighbors can not be described using simple Customer/Provider/Peer 259 roles. For a example, if neighbor is literal peer, but for some 260 prefixes it provides full transit; the complex role SHOULD be set on 261 both sides. In this case roles Customer/Provider/Peer should be set 262 on per-prefix basis, keeping the abstraction from detection and 263 filtering mechanisms (Section 7 and Section 8). 265 If role is not Complex all per-prefix role settings MUST be ignored. 267 7. BGP Internal Only To Customer attribute 269 The Internal Only To Customer (iOTC) attribute is a new optional, 270 non-transitive BGP Path attribute with the Type Code . This 271 attribute has zero length as it is used only as a flag. 273 There are four rules for setting the iOTC attribute: 275 1. The iOTC attribute MUST be added to all incoming routes if the 276 receiver's Role is Customer or Peer; 278 2. The iOTC attribute MUST be added to all incoming routes if the 279 receiver's Role is Complex and the prefix Role is Customer or 280 Peer; 282 3. Routes with the iOTC attribute set MUST NOT be announced by a 283 sender whose Role is Customer or Peer; 285 4. Routes with the iOTC attribute set MUST NOT be announced if by a 286 sender whose Role is Complex and the prefix Role is Customer or 287 Peer; 289 These four rules provide mechanism that strongly prevents route leak 290 creation by an AS. 292 8. BGP External Only To Customer attribute 294 The External Only To Customer (eOTC) attribute is a new optional, 295 transitive BGP Path attribute with the Type Code . This 296 attribute is four bytes and contains an AS number of the AS that 297 added the attribute to the route. 299 There are four rules for setting the eOTC attribute: 301 1. If eOTC is not set and the sender's Role is Provider or Peer, the 302 eOTC attribute MUST be added with value equal to the sender's AS 303 number 305 2. If eOTC is not set and the sender's Role is Complex and the 306 prefix role is Provider or Peer, the eOTC attribute MUST be added 307 with value equal to to the sender's AS number. 309 3. If eOTC is set, the receiver's Role is Provider or Peer, and its 310 value is not the neighbor's AS number then the incoming route is 311 route leak and MUST be given a lower local preference, or MAY be 312 dropped. 314 4. If eOTC is set, the receiver's Role is Complex, the prefix role 315 Role is Provider or Peer, and the eOTC value is not equal to the 316 neighbor's AS number, then the incoming route is a route leak and 317 MUST be given a lower local preference, or they MAY be dropped. 319 These four rules provide mechanism for route leak detection that is 320 created by an distant party in the AS_Path. 322 9. Compatibility with BGPsec 324 For BGPsec [I-D.ietf-sidr-bgpsec-protocol] enabled routers, the Flags 325 field will have a bit added to indicate that an eOTC attribute 326 exists. The eOTC value will be automatically carried in AS field of 327 the added Secure_Path Segment. 329 When a route is translated from a BGPsec enabled router to a non- 330 BGPsec router, in addition to AS_PATH reconstruction, reconstruction 331 MUST be performed for the eOTC attribute.. If Flag bit was set in one 332 of Secure_Path Segments, the eOTC attribute SHOULD be added with the 333 AS number of the segment in which it appears for the first time. 335 10. Additional Considerations 337 As the BGP Role reflects the relationship between neighbors, it can 338 also have other uses. As an example, BGP Role might affect route 339 priority, or be used to distinguish borders of a network if a network 340 consists of multiple AS. 342 Though such uses may be worthwhile, they are not the goal of this 343 document. Note that such uses would require local policy control. 345 This document doesn't provide any security measures to check 346 correctness of per-prefix roles, so the Complex role should be used 347 with great caution. It is as dangerous as current BGP peering. 349 11. IANA Considerations 351 This document defines a new Capability Codes option [to be removed 352 upon publication: http://www.iana.org/assignments/capability-codes/ 353 capability-codes.xhtml] [RFC5492], named "BGP Role", assigned value 354 . The length of this capability is 1. 356 The BGP Role capability includes a Value field, for which IANA is 357 requested to create and maintain a new sub-registry called "BGP Role 358 Value". Assignments consist of Value and corresponding Role name. 359 Initially this registry is to be populated with the data in Table 1. 360 Future assignments may be made by a standard action procedure 361 [RFC5226]. 363 This document defines new subcode, "Role Mismatch", assigned value 364 in the OPEN Message Error subcodes registry [to be removed 365 upon publication: http://www.iana.org/assignments/bgp-parameters/bgp- 366 parameters.xhtml#bgp-parameters-6] [RFC4271]. 368 This document defines a new optional, non-transitive BGP Path 369 Attributes option, named "Internal Only To Customer", assigned value 370 [To be removed upon publication: 371 http://www.iana.org/assignments/bgp-parameters/bgp- 372 parameters.xhtml#bgp-parameters-2] [RFC4271]. The length of this 373 attribute is 0. 375 This document defines a new optional, transitive BGP Path Attributes 376 option, named "External Only To Customer", assigned value [To 377 be removed upon publication: http://www.iana.org/assignments/bgp- 378 parameters/bgp-parameters.xhtml#bgp-parameters-2] [RFC4271]. The 379 length of this attribute is 4. 381 12. Security Considerations 383 This document proposes a mechanism for prevention and detection of 384 route leaks that are the result of BGP policy misconfiguration. This 385 includes preventing route leaks created inside an AS (company), and 386 route leak detection if a route was leaked by third party. 388 Deliberate sending of a known conflicting BGP Role could be used to 389 sabotage a BGP connection. This is easily detectable. 391 Deliberate mis-marking of the eOTC flag could be used to affect the 392 BGP decision process, but could not sabotage a route's propagation. 394 BGP Role is disclosed only to an immediate BGP neighbor, so it will 395 not itself reveal any sensitive information to third parties. 397 On the other hand, eOTC is a transitive BGP AS_PATH attribute which 398 reveals a bit about a BGP speaker's business relationship. It will 399 give a strong hint that some link isn't customer to provider, but 400 will not help to distinguish if it is provider to customer or peer to 401 peer. If eOTC is BGPsec signed, it can not be removed for business 402 confidentiality. 404 13. Acknowledgments 406 The authors wish to thank Douglas Montgomery, Brian Dickson, and 407 Andrei Robachevsky for their contributions to a variant of this work. 409 14. References 411 14.1. Normative References 413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 414 Requirement Levels", BCP 14, RFC 2119, 415 DOI 10.17487/RFC2119, March 1997, 416 . 418 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 419 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 420 DOI 10.17487/RFC4271, January 2006, 421 . 423 [RFC4486] Chen, E. and V. Gillet, "Subcodes for BGP Cease 424 Notification Message", RFC 4486, DOI 10.17487/RFC4486, 425 April 2006, . 427 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 428 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 429 2009, . 431 14.2. Informative References 433 [I-D.ietf-grow-route-leak-problem-definition] 434 Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 435 and B. Dickson, "Problem Definition and Classification of 436 BGP Route Leaks", draft-ietf-grow-route-leak-problem- 437 definition-06 (work in progress), May 2016. 439 [I-D.ietf-idr-route-leak-detection-mitigation] 440 Sriram, K., Montgomery, D., Dickson, B., Patel, K., and A. 441 Robachevsky, "Methods for Detection and Mitigation of BGP 442 Route Leaks", draft-ietf-idr-route-leak-detection- 443 mitigation-03 (work in progress), May 2016. 445 [I-D.ietf-sidr-bgpsec-protocol] 446 Lepinski, M. and K. Sriram, "BGPsec Protocol 447 Specification", draft-ietf-sidr-bgpsec-protocol-15 (work 448 in progress), March 2016. 450 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 451 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 452 DOI 10.17487/RFC5226, May 2008, 453 . 455 Authors' Addresses 457 Alexander Azimov 458 Qrator Labs 460 Email: aa@qrator.net 461 Eugene Bogomazov 462 Qrator Labs 464 Email: eb@qrator.net 466 Randy Bush 467 Internet Initiative Japan 469 Email: randy@psg.com 471 Keyur Patel 472 Arrcus, Inc. 474 Email: keyurpat@yahoo.com 476 Kotikalapudi Sriram 477 US NIST 479 Email: ksriram@nist.gov