idnits 2.17.1 draft-mitchell-grow-remove-private-as-04.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 date (April 20, 2015) is 3294 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GROW J. Mitchell 3 Internet-Draft 4 Intended status: Informational D. Rao 5 Expires: October 22, 2015 Cisco 6 R. Raszuk 7 April 20, 2015 9 Private Autonomous System (AS) Removal Requirements 10 draft-mitchell-grow-remove-private-as-04 12 Abstract 14 This document specifies operator's requirements for implementations 15 that remove Private Use Autonomous System (AS) numbers from the AS 16 path of routes sent to external Border Gateway Protocol (BGP) peers. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on October 22, 2015. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 1. Introduction 52 After the original IANA reservation of Autonomous System Numbers 53 (ASNs) for Private Use was allocated via [RFC1930] implementation 54 specific features were released that removed ASNs from the Border 55 Gateway Protocol AS_PATH attribute. The details of such 56 implementations were driven by multiple operators use cases and 57 varied accordingly. At times, implementation differences, mis- 58 understanding of feature behavior and mis-configurations have led to 59 operators leaking Private Use ASNs to the Internet. Since an 60 additional range of Private Use ASNs has been documented in [RFC6996] 61 implementations will likely require update and even more 62 implementation variation is possible. 64 This document captures operator's requirements across various use 65 cases, being cognizant of the operations of current implementations 66 that remove Private Use ASNs, and provides a set of requirements for 67 Private Use ASN removal implementations in the hopes of reducing 68 inconsistencies and variations between implementations. 70 2. Requirements Language 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in [RFC2119]. 76 3. Basic Requirements 78 An implementation that removes Private Use ASNs MUST provide a 79 configuration option to remove them from both the AS_PATH attribute 80 of [RFC4271] and if Four-Octet AS Support [RFC6793] is present, the 81 AS4_PATH attribute of the route. This configuration option MUST be 82 configurable at least at the External Border Gateway Protocol (EBGP) 83 peering session level, i.e. per neighbor, and will impact the as path 84 attributes associated with any NLRI sent to the router to which is 85 configured. The option SHOULD be configurable per AFI/SAFI so that 86 implementations may provide different behaviors per address family. 87 The implementation MUST remove all Private Use ASNs from the as path 88 attributes up to the first non-Private Use AS in the as path, except 89 as dictated by Section 4. An implementation MAY remove Private Use 90 ASNs from the entire as path (past the first ASN in the as path 91 attributes), however if it does so, it SHOULD provide an operator 92 configurable option to disable this behavior if desired. The reason 93 for this behavior is that operators would prefer visibility to which 94 network is leaking Private Use ASNs to the global Internet (or any 95 other network) so the behavior can be corrected directly by the 96 upstream network providing connectivity to the Private Use ASN rather 97 than hiding the issue, which may not fully correct the problem if the 98 downstream network has multiple providers. 100 4. Loop Prevention when using Private Use ASN Removal 102 Implementations of the Private Use ASN removal feature MAY provide 103 basic loop prevention to prevent a dual-homed network utilizing a 104 Private Use ASN which connects to a single ASN from receiving an 105 update with it's own (Private) ASN removed that was sent back to the 106 non-originating connection if the ASN to which it is connected has 107 configured the feature towards it's other location. The 108 implementation SHOULD validate that the peer ASN does not appear in 109 the as path prior to removing Private ASNs from the path. If the 110 peer ASN does appear, the Private Use removal feature should not 111 manipulate the path. Otherwise, due to the standard BGP path 112 selection process described in Section 9.1.2.2 of [RFC4271] EBGP 113 routes will be preferred over IBGP routes which may have been from 114 within the AS, so without further attribute manipulation, this can 115 pose a risk of a routing information loop to some networks. 116 Therefore a router SHOULD NOT remove Private Use ASN's from an 117 AS_PATH or AS4_PATH attribute if it encounters the EBGP AS of the 118 neighbor on which it is configured in the AS_PATH or AS4_PATH that 119 would be removed. 121 5. Unnecessary Restrictions on Local or Peer AS 123 Implementations of this feature SHOULD NOT have any unnecessary 124 restrictions on Private Use ASN use on either the local ASN of the 125 router that is configuring the feature or the peer ASN that will be 126 receiving the routes. Both use cases are prevalent in some networks 127 as Private Use ASN removal features have sometimes been used in 128 network mergers or other situations where masking the Private Use 129 ASN's behind a particular AS, which may also be a Private Use ASN, is 130 necessary to avoid conflict with Private Use ASN's inside the 131 neighboring network. In these cases, as long as both the router with 132 the feature configured and the peer have a unique Private ASN from 133 each other, all routes originated from behind their networks 134 containing Private ASN's can be masked to be their ASN. In the case 135 where the AS where the feature is configured is a Private Use ASN and 136 the router also has policy configured to prepend the local AS to the 137 as path, an implementation SHOULD NOT remove the ASN's that have been 138 locally prepended as per policy configuration, as it is expected that 139 the local ASN cannot be removed from the path with the feature, and 140 prepending is utilized by operators for various traffic engineering 141 scenarios. 143 6. Private ASN Replacement Alternative 145 Implementations of this feature MAY include the capability to 146 alternatively replace Private Use ASN's, or for that matter any 147 arbitrary set of ASN's, in the AS Path with the local router ASN, 148 thereby maintaining the original as path length when advertising the 149 update to upstream networks. If this capability exists, it SHOULD 150 NOT be the default behavior of the Private ASN removal feature and 151 therefore MUST be operator configurable. 153 7. Behavior Towards other Special-Use ASNs 155 Implementations of this feature SHOULD NOT remove Documentation ASNs 156 [RFC5398] as this may encourage their use by operators. These ASNs 157 are not reserved for Private Use and use of them is likely the result 158 of a misconfiguration. Due to historical reasons and lack of 159 operator guidance on Last ASNs prior to [RFC7300] implementations MAY 160 remove Last ASNs, which are deployed in some networks as if they are 161 Private Use ASNs, even though this is not recommended to operators 162 for the reasons specified in that document. If the implementation 163 supports this, the behavior towards Last ASNs SHOULD be consistent 164 with the behavior of the implementation towards Private Use ASNs as 165 specified in this document. 167 8. Operational Considerations 169 It should be noted that removing items from the AS_PATH or AS4_PATH 170 poses some risk and could introduce the chance of a routing loop. 171 Further operational considerations for the use of Private Use ASNs 172 are documented in [RFC6996]. 174 9. IANA Considerations 176 There are no IANA actions required by this document. Current Private 177 Use, Documentation and Last ASN registrations discussed in this 178 document are located in the IANA AS Numbers registry [IANA.AS]. 180 10. Security Considerations 182 There are no new security concerns in relation to the feature 183 described in this document. General BGP security considerations are 184 discussed in [RFC4271] and [RFC4272]. Identification of the 185 originator of a route with a Private Use ASN in the AS path would 186 have to be done by tracking the route back to the neighboring 187 globally unique AS in the path or by inspecting other attributes. 189 11. References 191 11.1. Normative References 193 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 194 Requirement Levels", BCP 14, RFC 2119, March 1997. 196 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 197 Protocol 4 (BGP-4)", RFC 4271, January 2006. 199 [RFC5398] Huston, G., "Autonomous System (AS) Number Reservation for 200 Documentation Use", RFC 5398, December 2008. 202 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 203 Autonomous System (AS) Number Space", RFC 6793, December 204 2012. 206 [RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for 207 Private Use", BCP 6, RFC 6996, July 2013. 209 [RFC7300] Haas, J. and J. Mitchell, "Reservation of Last Autonomous 210 System (AS) Numbers", BCP 6, RFC 7300, July 2014. 212 11.2. Informative References 214 [IANA.AS] IANA, , "Autonomous System (AS) Numbers", April 2015, 215 . 217 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 218 selection, and registration of an Autonomous System (AS)", 219 BCP 6, RFC 1930, March 1996. 221 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 222 4272, January 2006. 224 Appendix A. Acknowledgements 226 JM - Placeholder. 228 Authors' Addresses 230 Jon Mitchell 232 Email: jrmitche@puck.nether.net 233 Dhananjaya Rao 234 Cisco 235 170 West Tasman Dr. 236 San Jose, CA 95134 237 USA 239 Email: dhrao@cisco.com 241 Robert Raszuk 243 Email: robert@raszuk.net