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