idnits 2.17.1 draft-ietf-idr-deprecate-as-set-confed-set-00.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 : ---------------------------------------------------------------------------- -- The abstract seems to indicate that this document updates RFC4271, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 3, 2019) is 1668 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Kumari 3 Internet-Draft Google, Inc. 4 Intended status: Standards Track K. Sriram 5 Expires: March 6, 2020 USA NIST 6 September 3, 2019 8 Deprecation of AS_SET and AS_CONFED_SET in BGP 9 draft-ietf-idr-deprecate-as-set-confed-set-00 11 Abstract 13 BCP 172 (i.e., RFC 6472) recommends not using AS_SET and 14 AS_CONFED_SET in Border Gateway Protocol (BGP). This document 15 updates RFC 4271 and proscribes the use of the AS_SET and 16 AS_CONFED_SET types of path segments in the AS_PATH. This is done to 17 simplify the design and implementation of BGP and to make the 18 semantics of the originator of a route clearer. This will also 19 simplify the design, implementation, and deployment of various BGP 20 security mechanisms. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 6, 2020. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 58 3. Recommendation to Network Operators . . . . . . . . . . . . . 3 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 64 7.2. Informative References . . . . . . . . . . . . . . . . . 5 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 67 1. Introduction 69 BCP 172 [RFC6472] makes a recommendation for not using AS_SET and 70 AS_CONFED_SET in Border Gateway Protocol (BGP). This document 71 advances the recommendation to a standards requirement in BGP. It 72 updates [RFC4271] and proscribes the use of the AS_SET and 73 AS_CONFED_SET types of path segments in the AS_PATH. 75 The AS_SET path segment in the AS_PATH attribute (Sections 4.3 and 76 5.1.2 of [RFC4271]) is created by a router that is performing route 77 aggregation and contains an unordered set of Autonomous Systems 78 (ASes) that the update has traversed. The AS_CONFED_SET path segment 79 (see [RFC5065]) in the AS_PATH attribute is created by a router that 80 is performing route aggregation and contains an unordered set of 81 Member AS Numbers in the local confederation that the update has 82 traversed. It is very similar to AS_SETs but is used within a 83 confederation. 85 By performing aggregation, a router is combining multiple existing 86 routes into a single new route. The aggregation together with the 87 use of AS_SET blurs the semantics of origin AS for the prefix being 88 announced. Therefore, the aggregation with AS_SET (or AS_CONFED_SET) 89 can cause operational issues, such as not being able to authenticate 90 a route origin for the aggregate prefix in new BGP security 91 technologies such as those that take advantage of X.509 extensions 92 for IP addresses and AS identifiers [RFC3779] [RFC6811] [RFC8205]. 93 This in turn could result in reachability problems for the aggregated 94 prefix and its components (i.e., more-specific prefixes). The 95 aggregation as described above could also create traffic engineering 96 issues, because the precise path information for the component 97 prefixes are not preserved. 99 From analysis of past Internet routing data, it is apparent that 100 aggregation that involves AS_SETs is very seldom used in practice on 101 the public Internet [Analysis] and when it is used, it is often used 102 incorrectly -- reserved AS numbers ([RFC1930]) and/or only a single 103 AS in the AS_SET are by far the most common cases. Because the 104 aggregation involving AS_SETs is very rarely used, the reduction in 105 table size provided by said aggregation is extremely small, and any 106 advantage thereof is outweighed by additional complexity in BGP. As 107 noted above, said aggregation also poses impediments to 108 implementation of new BGP security technologies. 110 In the past, AS_SET had been used in a few rare cases to allow route 111 aggregation where two or more providers could form the same aggregate 112 prefix, using the exact match of the other's aggregate prefix in some 113 advertisement and configuring the aggregation differently elsewhere. 114 The key to configuring this correctly was to form the aggregate at 115 the border in the outbound BGP policy and omit prefixes from the AS 116 that the aggregate was being advertised to. The AS_SET therefore 117 allowed this practice without the loss of BGP's AS_PATH loop 118 protection. This use of AS_SET served a purpose that fell in line 119 with the original intended use. Without the use of AS_SET, 120 aggregates must always contain only less-specific prefixes (not less 121 than or equal to) and must never aggregate an exact match. 123 2. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 127 "OPTIONAL" in this document are to be interpreted as described in BCP 128 14 [RFC2119] [RFC8174] when, and only when, they appear in all 129 capitals, as shown here. 131 3. Recommendation to Network Operators 133 Operators MUST NOT generate any new announcements containing AS_SETs 134 or AS_CONFED_SETs. If they have already announced routes with 135 AS_SETs or AS_CONFED_SETs in them, then they MUST withdraw those 136 routes and re-announce routes for the component prefixes (i.e., the 137 more-specific prefixes subsumed by the previously aggregated prefix) 138 without AS_SETs or CONFED_SETs in the updates. Route aggregation 139 that was previously performed by proxy aggregation (i.e., without the 140 use of AS_SETs) is still possible under some conditions. When doing 141 this, operators MUST form the aggregate at the border in the outbound 142 BGP policy and omit any prefixes from the AS that the aggregate was 143 being advertised to. As with any change, the operator should 144 understand the full implications of the change. 146 It is worth noting that new BGP security technologies (such as those 147 that take advantage of X.509 extensions for IP addresses and AS 148 identifiers [RFC3779] [RFC6811] [RFC8205]) might not support routes 149 with AS_SETs/AS_CONFED_SETs in them, and may treat routes containing 150 them as infeasible. Future BGP implementations may also do the same. 151 It is expected that, even before the deployment of these new or 152 future technologies, operators may filter routes with AS_SETs/ 153 AS_CONFED_SETs in them. Other than making that observation, this 154 document is not intended to make any recommendation for how an 155 implementation should behave when receiving a route with AS_SET or 156 AS_CONFED_SET in it. This document's focus is entirely on the sender 157 side, as discussed in the preceding paragraph. 159 4. Security Considerations 161 This document obsoletes the use of aggregation techniques that create 162 AS_SETs or AS_CONFED_SETs. Obsoleting these path segment types from 163 BGP and removal of the related code from implementations would 164 potentially decrease the attack surface for BGP. 166 5. IANA Considerations 168 This document requires no IANA actions. 170 6. Acknowledgements 172 The authors would like to thank Tony Li, Randy Bush, John Scudder, 173 Curtis Villamizar, Danny McPherson, Chris Morrow, Tom Petch, Ilya 174 Varlashkin, Douglas Montgomery, Enke Chen, Florian Weimer, Jakob 175 Heitz, John Leslie, Keyur Patel, Paul Jakma, Rob Austein, Russ 176 Housley, Sandra Murphy, Steve Bellovin, Steve Kent, Steve Padgett, 177 Alfred Hoenes, and Alvaro Retana. 179 7. References 181 7.1. Normative References 183 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 184 Requirement Levels", BCP 14, RFC 2119, 185 DOI 10.17487/RFC2119, March 1997, 186 . 188 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 189 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 190 DOI 10.17487/RFC4271, January 2006, 191 . 193 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 194 System Confederations for BGP", RFC 5065, 195 DOI 10.17487/RFC5065, August 2007, 196 . 198 7.2. Informative References 200 [Analysis] 201 Sriram, K. and D. Montgomery, "Measurement Data on AS_SET 202 and AGGREGATOR: Implications for {Prefix, Origin} 203 Validation Algorithms", SIDR WG presentation, IETF 78, 204 July 2010, . 207 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 208 selection, and registration of an Autonomous System (AS)", 209 BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996, 210 . 212 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 213 Addresses and AS Identifiers", RFC 3779, 214 DOI 10.17487/RFC3779, June 2004, 215 . 217 [RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using 218 AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472, 219 DOI 10.17487/RFC6472, December 2011, 220 . 222 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 223 Austein, "BGP Prefix Origin Validation", RFC 6811, 224 DOI 10.17487/RFC6811, January 2013, 225 . 227 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 228 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 229 May 2017, . 231 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 232 Specification", RFC 8205, DOI 10.17487/RFC8205, September 233 2017, . 235 Authors' Addresses 237 Warren Kumari 238 Google, Inc. 239 1600 Amphitheatre Parkway 240 Mountain View, CA 94043 241 US 243 Phone: +1 571 748 4373 244 Email: warren@kumari.net 246 Kotikalapudi Sriram 247 USA NIST 248 100 Bureau Drive 249 Gaithersburg, MD 20899 250 US 252 Phone: +1 301 975 3973 253 Email: sriram.ietf@gmail.com