idnits 2.17.1 draft-ymbk-idr-bgp-open-policy-01.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 (October 26, 2016) is 2731 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-04 == Outdated reference: A later version (-23) exists of draft-ietf-sidr-bgpsec-protocol-18 -- 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: April 29, 2017 R. Bush 6 Internet Initiative Japan 7 October 26, 2016 9 Route Leak Detection and Filtering using Roles in Update and Open 10 messages 11 draft-ymbk-idr-bgp-open-policy-01 13 Abstract 15 Route Leaks are propagation of BGP prefixes which violate assumptions 16 of BGP topology relationships; e.g. passing a route learned from one 17 peer to another peer or to a transit provider, passing a route 18 learned from one transit provider to another transit provider or to a 19 peer. Today, approaches to leak prevention rely on marking routes 20 according to some configuration options without any check of the 21 configuration corresponds to that of the BGP neighbor, or enforcement 22 that the two BGP speakers agree on the relationship. This document 23 enhances BGP Open to establish agreement of the (peer, customer, 24 provider, internal) relationship of two BGP neighboring speakers to 25 enforce appropriate configuration on both sides. Propagated routes 26 are then marked with a eOTC and iOTC attributes according to agreed 27 relationship allowing prevetion and detection of route leaks. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to 33 be interpreted as described in RFC 2119 [RFC2119] only when they 34 appear in all upper case. They may also appear in lower or mixed 35 case as English words, without normative meaning. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on April 29, 2017. 54 Copyright Notice 56 Copyright (c) 2016 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 2. BGP Role . . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 3. Role capability . . . . . . . . . . . . . . . . . . . . . . . 4 74 4. Role correctness . . . . . . . . . . . . . . . . . . . . . . 4 75 4.1. Strict mode . . . . . . . . . . . . . . . . . . . . . . . 5 76 5. Restrictions on the Complex role . . . . . . . . . . . . . . 5 77 6. BGP Internal Only To Customer attribute . . . . . . . . . . . 5 78 7. BGP External Only To Customer attribute . . . . . . . . . . . 6 79 8. Compatibility with BGPsec . . . . . . . . . . . . . . . . . . 6 80 9. Additional Considerations . . . . . . . . . . . . . . . . . . 6 81 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 82 11. Security Considerations . . . . . . . . . . . . . . . . . . . 7 83 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 84 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 85 12.2. Informative References . . . . . . . . . . . . . . . . . 8 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 88 1. Introduction 90 For the purposes of this document BGP route leaks are when a BGP 91 route was learned from transit provider or peer and is announced to 92 another provider or peer. See [RFC7908]. These are usually the 93 result of misconfigured or absent BGP route filtering or lack of 94 coordination between two BGP speakers. 96 [I-D.ietf-idr-route-leak-detection-mitigation] describes a method of 97 marking and detecting leaks which relies on operator maintained 98 markings. Unfortunately, in most cases, a leaking router will likely 99 also be misconfigured to mark incorrectly. The proposed mechanism 100 provides an opportunity to detect route leaks made by third parties 101 but provides no support to prevent route leak creation. The leak 102 prevention still relies on communities which are optional and often 103 missed due to mistakes or misunderstanding of the BGP configuration 104 process. 106 It has been suggested to use white list filtering, relying on knowing 107 the prefixes in the customer cone as import filtering, in order to 108 detect route leaks. Unfortunately, a large number of incidents is 109 created medium size transit operators use a single prefix list as 110 only the ACL for export filtering, without community tagging and 111 paying attention to the source of a learned route. So, if they learn 112 a customer's route from their provider or peer - they will announce 113 it in all directions, including other providers or peers. This 114 misconfiguration affects a limited number of prefixes; but such route 115 leaks will obviously bypass customer cone import filtering made by 116 upper level upstream providers. 118 Also, route tagging which relies on operator maintained policy 119 configuration is too easily and too often misconfigured. 121 This document specifies a new BGP Capability Code, [RFC5492] Sec 4, 122 which two BGP speakers MAY use to ensure that they MUST agree on 123 their relationship; i.e. customer and provider or peers. Either or 124 both may optionally be configured to require that this option be 125 exchanged for the BGP Open to succeed. 127 Also this document specifies a way to mark routes according to BGP 128 Roles and a way to create double-boundary filters for prevention and 129 detection of route leaks via a two new BGP Path Attributes. 131 2. BGP Role 133 BGP Role is new mandatory configuration option which must be set per 134 each address family. It reflects the real-world agreement between 135 two BGP speakers about their business relationship. 137 Allowed Role values are: 139 o Provider - sender is a transit provider to neighbor; 141 o Customer - sender is customer of neighbor; 143 o Peer - sender and neighbor are peers; 144 o Internal - sender is part of an internal AS of an organization 145 which has multiple ASs, is a confederation, ... 147 o Complex - sender has non-standard agreement and wants to use 148 manual policies. 150 Since BGP Role reflects the relationship between two BGP speakers, it 151 could also be used for more than route leak mitigation. 153 3. Role capability 155 The TLV (type, length, value) of the BGP Role capability are: 157 o Type - ; 159 o Length - 1 (octet); 161 o Value - integer corresponding to speaker' BGP Role. 163 +--------+----------------------+ 164 | Value | Role name | 165 +--------+----------------------+ 166 | 0 | Undefined | 167 | 1 | Sender is Peer | 168 | 2 | Sender is Provider | 169 | 3 | Sender is Customer | 170 | 4 | Sender is Internal | 171 | 5 | Sender is Complex | 172 +--------+----------------------+ 174 Table 1: Predefined BGP Role Values 176 4. Role correctness 178 Section 2 described how BGP Role is a reflection of the relationship 179 between two BGP speakers. But the mere presence of BGP Role doesn't 180 automatically guarantee role agreement between two BGP peers. 182 To enforce correctness, use the BGP Role check with a set of 183 constrains on how speakers' BGP Roles MUST corresponded. Of course, 184 each speaker MUST announce and accept the BGP Role capability in the 185 BGP OPEN message exchange. 187 If a speaker receives a BGP Role capability, it SHOULD check value of 188 the received capability with its own BGP Role. The allowed pairings 189 are (first a sender's Role, second the receiver's Role): 191 +--------------+----------------+ 192 | Sender Role | Receiver Role | 193 +--------------+----------------+ 194 | Peer | Peer | 195 | Provider | Customer | 196 | Customer | Provider | 197 | Internal | Internal | 198 | Complex | Complex | 199 +--------------+----------------+ 201 Table 2: Allowed Role Capabilities 203 In all other cases speaker MUST send a Role Mismatch Notification 204 (code 2, sub-code ). 206 4.1. Strict mode 208 A new BGP configuration option "strict mode" is defined with values 209 of true or false. If set to true, then the speaker MUST refuse to 210 establish a BGP session with peers which do not announce BGP Role 211 capability in their OPEN message. If a speaker rejects a connection, 212 it MUST send a Connection Rejected Notification [RFC4486] 213 (Notification with error code 6, subcode 5). By default strict mode 214 SHOULD be set to false for backward compatibility with BGP speakers, 215 that do not yet support this mechanism. 217 5. Restrictions on the Complex role 219 Complex role should be set only if relations between BGP neighbors 220 could not be described using simple Customer/Provider/Peer roles. 221 For a example, if neighbor is literal peer, but for some prefixes it 222 provides full transit, complex role SHOULD be set on both sides. In 223 this case configuration of detection and filtering mechanisms 224 (Section 6 and Section 7) should be set on per-prefix basis upon 225 local policy. 227 6. BGP Internal Only To Customer attribute 229 The Internal Only To Customer (iOTC) attribute is a new optional, 230 non-transitive BGP Path attribute with the Type Code . This 231 attribute has zero length as it used only as a flag. 233 There are two rules for setting the iOTC attribute: 235 1. The iOTC attribute MUST be added to all incoming routes if the 236 receiver's Role is Customer or Peer; 238 2. Routes with the iOTC attribute set MUST NOT be announced if the 239 sender's Role is Customer or Peer; 241 These two rules provide mechanism that prevent route leak creation by 242 an AS. In case of Complex role usage the way of iOTC process is not 243 automated and upon local policy. 245 7. BGP External Only To Customer attribute 247 The External Only To Customer (eOTC) attribute is a new optional, 248 transitive BGP Path attribute with the Type Code . This 249 attribute has four bytes length and contain an AS number of AS, that 250 added attribute to the route. 252 There are two rules for setting the eOTC attribute: 254 1. If eOTC is not set and sender's Role is Provider or Peer the eOTC 255 attribute MUST be added with value equal to its ASN. 257 2. If eOTC is set, receiver's Role is Provider or Peer, and its 258 value is not equal to neighbor ASN then such incoming route is 259 route leak and MUST be given a lower local preference, or they 260 MAY be dropped. 262 These two rules provide mechanism for route leak detection that is 263 made by some party in ASPath. In case of Complex role usage the way 264 of eOTC process is not automated and upon local policy. 266 8. Compatibility with BGPsec 268 In BGPsec [I-D.ietf-sidr-bgpsec-protocol] enabled routers eOTC 269 attribute MUST be turned into one bit of Flags field of Secure_Path 270 Segment and MUST NOT be added as separate attribute. 272 When route is transmitted from BGPsec enabled router to BGPsec 273 disabled device, in addition to AS_PATH reconstruction MUST be 274 performed eOTC attribute reconstruction. If corresponded bit was set 275 in one of Secure_Path Segments, eOTC attribute SHOULD be added with 276 value that equals to ASN in which segment it appears for the first 277 time. 279 9. Additional Considerations 281 As BGP Role reflects the relationship between neighbors, it can also 282 have other uses. As an example, BGP Role might affect route 283 priority, or be used to distinguish borders of a network if a network 284 consists of multiple AS. 286 Though such uses may be worthwhile, they are not the goal of this 287 document. Note that such uses would require local policy control. 289 This document doesn't provide any security measures to check 290 correctness of attributes usage in case of Complex role, so Complex 291 role should be set with great caution. 293 10. IANA Considerations 295 This document defines a new Capability Codes option [to be removed 296 upon publication: http://www.iana.org/assignments/capability-codes/ 297 capability-codes.xhtml] [RFC5492], named "BGP Role", assigned value 298 . The length of this capability is 1. 300 The BGP Role capability includes a Value field, for which IANA is 301 requested to create and maintain a new sub-registry called "BGP Role 302 Value". Assignments consist of Value and corresponding Role name. 303 Initially this registry is to be populated with the data in Table 1. 304 Future assignments may be made by a standard action procedure 305 [RFC5226]. 307 This document defines new subcode, "Role Mismatch", assigned value 308 in the OPEN Message Error subcodes registry [to be removed 309 upon publication: http://www.iana.org/assignments/bgp-parameters/bgp- 310 parameters.xhtml#bgp-parameters-6] [RFC4271]. 312 This document defines a new optional, non-transitive BGP Path 313 Attributes option, named "Internal Only To Customer", assigned value 314 [To be removed upon publication: 315 http://www.iana.org/assignments/bgp-parameters/bgp- 316 parameters.xhtml#bgp-parameters-2] [RFC4271]. The length of this 317 attribute is 0. 319 This document defines a new optional, transitive BGP Path Attributes 320 option, named "External Only To Customer", assigned value [To 321 be removed upon publication: http://www.iana.org/assignments/bgp- 322 parameters/bgp-parameters.xhtml#bgp-parameters-2] [RFC4271]. The 323 length of this attribute is 4. 325 11. Security Considerations 327 This document proposes a mechanism for prevention and detection of 328 route leaks, that are the result of BGP policy misconfiguration. 329 That includes preventing route leaks created inside an AS (company), 330 and route leak detection, if a route was leaked by third party. 332 Deliberate sending of a known conflicting BGP Role could be used to 333 sabotage a BGP connection. This is easily detectable. 335 Deliberate mis-marking of the eOTC flag could be used to could affect 336 BGP decision process but could not sabotage a route's propagation. 338 BGP Role is disclosed only to an immediate BGP speaker, so it will 339 not itself reveal any sensitive information to third parties. 341 On the other hand, eOTC is a transitive BGP AS_PATH attribute which 342 reveals a bit about a BGP speaker's business relationship. It will 343 give a strong hint that some link isn't customer to provider, but 344 will not help to distinguish if it is provider to customer or peer to 345 peer. If eOTC is BGPsec signed, it can not be removed for business 346 confidentiality. 348 12. References 350 12.1. Normative References 352 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 353 Requirement Levels", BCP 14, RFC 2119, 354 DOI 10.17487/RFC2119, March 1997, 355 . 357 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 358 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 359 DOI 10.17487/RFC4271, January 2006, 360 . 362 [RFC4486] Chen, E. and V. Gillet, "Subcodes for BGP Cease 363 Notification Message", RFC 4486, DOI 10.17487/RFC4486, 364 April 2006, . 366 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 367 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 368 2009, . 370 12.2. Informative References 372 [I-D.ietf-idr-route-leak-detection-mitigation] 373 Sriram, K., Montgomery, D., Dickson, B., Patel, K., and A. 374 Robachevsky, "Methods for Detection and Mitigation of BGP 375 Route Leaks", draft-ietf-idr-route-leak-detection- 376 mitigation-04 (work in progress), July 2016. 378 [I-D.ietf-sidr-bgpsec-protocol] 379 Lepinski, M. and K. Sriram, "BGPsec Protocol 380 Specification", draft-ietf-sidr-bgpsec-protocol-18 (work 381 in progress), August 2016. 383 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 384 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 385 DOI 10.17487/RFC5226, May 2008, 386 . 388 [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 389 and B. Dickson, "Problem Definition and Classification of 390 BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 391 2016, . 393 Authors' Addresses 395 Alexander Azimov 396 Qrator Labs 398 Email: aa@qrator.net 400 Eugene Bogomazov 401 Qrator Labs 403 Email: eb@qrator.net 405 Randy Bush 406 Internet Initiative Japan 408 Email: randy@psg.com