idnits 2.17.1 draft-ymbk-idr-bgp-eotr-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 (March 17, 2018) is 2233 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 (-24) exists of draft-ietf-idr-bgp-open-policy-02 ** Downref: Normative reference to an Informational RFC: RFC 7908 == 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 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). 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: September 18, 2018 R. Bush 6 Internet Initiative Japan 7 K. Patel 8 Arrcus, Inc. 9 March 17, 2018 11 Route Leak Detection and Filtering using Roles in Update and Open 12 messages 13 draft-ymbk-idr-bgp-eotr-policy-02 15 Abstract 17 [draft-ietf-idr-bgp-open-policy] defines a BGP OPEN capability and 18 consequent route marking which enforces a valley-free peering 19 relationship. This document defines an eOTC (external Only To 20 Customer) transitive BGP attribute which propagates the specific 21 marking to automatically detect route leaks. The goal is to allow a 22 distant AS to determine a violation of valley-free peering. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to 28 be interpreted as described in RFC 2119 [RFC2119] only when they 29 appear in all upper case. They may also appear in lower or mixed 30 case as English words, without normative meaning. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 18, 2018. 49 Copyright Notice 51 Copyright (c) 2018 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. BGP External Only To Customer attribute . . . . . . . . . . . 3 68 3. Compatibility with BGPsec . . . . . . . . . . . . . . . . . . 3 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 73 6.2. Informative References . . . . . . . . . . . . . . . . . 5 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 76 1. Introduction 78 For the purpose of this document, BGP route leaks are when a BGP 79 route was learned from transit provider or peer is announced to 80 another provider or peer. See [RFC7908]. These are usually the 81 result of misconfigured or absent BGP route filtering or lack of 82 coordination between two BGP speakers. 84 [I-D.ietf-idr-route-leak-detection-mitigation] describes a method of 85 marking and detecting leaks which relies on operator maintained 86 markings. Unfortunately, in most cases, a leaking router will likely 87 also be misconfigured to mark incorrectly. 89 It has been suggested to use white list filtering, relying on knowing 90 the prefixes in the peer's customer cone as import filtering, in 91 order to detect route leaks. Unfortunately, a large number of medium 92 transit operators use a single prefix list as only the ACL for export 93 filtering, without community tagging and without paying attention to 94 the source of a learned route. So, if they learn a customer's route 95 from their provider or peer - they will announce it in all 96 directions, including other providers or peers. This 97 misconfiguration affects a limited number of prefixes; but such route 98 leaks will obviously bypass customer cone import filtering made by 99 upper level upstream providers. 101 This document specifies a way to to create automatic filters for 102 detection of route leaks via new BGP Path Attribute which is set 103 according to BGP Roles ([I-D.ietf-idr-bgp-open-policy]) . While iOTC 104 provides strong vendor-code-based enforcement of route leak 105 prevention, route leaks could still exist as result of misconfigured 106 old BGP implementations. Route leaks could also be result of 107 malicious activity such as MITM attacks or DoS. The goal of this 108 proposal is to allow a distant AS to determine a violation of valley- 109 free peering that is made by mistake or by purpose. 111 2. BGP External Only To Customer attribute 113 The External Only To Customer (eOTC) attribute is a new optional, 114 transitive BGP Path attribute with the Type Code . This 115 attribute is four bytes and contains an AS number of the AS that 116 added the attribute to the route. 118 There are two rules for setting the eOTC attribute: 120 1. If eOTC is not set and the sender's Role is Provider or Peer, the 121 eOTC attribute MUST be added with value equal to the sender's AS 122 number. 124 2. If eOTC is set, the receiver's Role is Provider or Peer, and its 125 value is not the neighbor's AS number then the incoming route is 126 route leak and MUST be given a lower local preference, or MAY be 127 dropped. 129 These two rules provide mechanism for route leak detection that is 130 created by a distant party in the AS_Path. 132 3. Compatibility with BGPsec 134 For BGPsec [I-D.ietf-sidr-bgpsec-protocol] enabled routers, the Flags 135 field will have a bit added to indicate that an eOTC attribute 136 exists. The eOTC value will be automatically carried in AS field of 137 the added Secure_Path Segment. 139 When a route is translated from a BGPsec enabled router to a non- 140 BGPsec router, in addition to AS_PATH reconstruction, reconstruction 141 MUST be performed for the eOTC attribute. If Flag bit was set in one 142 of Secure_Path Segments, the eOTC attribute SHOULD be added with the 143 AS number of the segment in which it appears for the first time. 145 4. IANA Considerations 147 This document defines a new optional, transitive BGP Path Attributes 148 option, named "External Only To Customer", assigned value [To 149 be removed upon publication: http://www.iana.org/assignments/bgp- 150 parameters/bgp-parameters.xhtml#bgp-parameters-2] [RFC4271]. The 151 length of this attribute is 4. 153 5. Security Considerations 155 This document proposes a mechanism for detection of route leaks that 156 are the result of BGP policy misconfiguration. If BGPSec is enabled 157 it will also provide mechanism to detect leaks that are result of 158 malicious activity. 160 Deliberate mis-marking of the eOTC flag could be used to affect the 161 BGP decision process, but could not sabotage a route's propagation. 163 eOTC is a transitive BGP AS_PATH attribute which reveals a 164 information about a BGP speaker's peering relationship. It will give 165 a strong hint that some link isn't customer to provider, but will not 166 help to distinguish if it is provider to customer or peer to peer. 167 In addition it could reveal sequence of p2c to downstream ISPs. If 168 eOTC is BGPsec signed, it can not be removed for peering 169 confidentiality. 171 Still, any Tier-1 number in AS_PATH could be used in the same way to 172 reveal possible p2c sequence. 174 6. References 176 6.1. Normative References 178 [I-D.ietf-idr-bgp-open-policy] 179 Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K. 180 Sriram, "Route Leak Prevention using Roles in Update and 181 Open messages", draft-ietf-idr-bgp-open-policy-02 (work in 182 progress), January 2018. 184 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 185 Requirement Levels", BCP 14, RFC 2119, 186 DOI 10.17487/RFC2119, March 1997, . 189 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 190 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 191 DOI 10.17487/RFC4271, January 2006, . 194 [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 195 and B. Dickson, "Problem Definition and Classification of 196 BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 197 2016, . 199 6.2. Informative References 201 [I-D.ietf-idr-route-leak-detection-mitigation] 202 Sriram, K., Montgomery, D., Dickson, B., Patel, K., and A. 203 Robachevsky, "Methods for Detection and Mitigation of BGP 204 Route Leaks", draft-ietf-idr-route-leak-detection- 205 mitigation-03 (work in progress), May 2016. 207 [I-D.ietf-sidr-bgpsec-protocol] 208 Lepinski, M. and K. Sriram, "BGPsec Protocol 209 Specification", draft-ietf-sidr-bgpsec-protocol-15 (work 210 in progress), March 2016. 212 Authors' Addresses 214 Alexander Azimov 215 Qrator Labs 217 Email: aa@qrator.net 219 Eugene Bogomazov 220 Qrator Labs 222 Email: eb@qrator.net 224 Randy Bush 225 Internet Initiative Japan 227 Email: randy@psg.com 229 Keyur Patel 230 Arrcus, Inc. 232 Email: keyur@arrcus.com