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