idnits 2.17.1 draft-kumari-deprecate-as-set-confed-set-09.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 (January 3, 2017) is 2641 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: July 7, 2017 US NIST 6 January 3, 2017 8 Deprecation of AS_SET and AS_CONFED_SET in BGP 9 draft-kumari-deprecate-as-set-confed-set-09 11 Abstract 13 RFC 6472 (i.e., BCP 172) recommends not using AS_SET and 14 AS_CONFED_SET in BGP. This document updates RFC 4271 and proscribes 15 the use of the AS_SET and AS_CONFED_SET types of the AS_PATH in 16 BGPv4. This is done to simplify the design and implementation of BGP 17 and to make the semantics of the originator of a route more clear. 18 This will also simplify the design, implementation, and deployment of 19 ongoing work in the Secure Inter-Domain Routing Working Group. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 7, 2017. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 57 3. Recommendation to Network Operators . . . . . . . . . . . . . 3 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 60 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 63 7.2. Informative References . . . . . . . . . . . . . . . . . 5 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 66 1. Introduction 68 RFC 6472 (i.e., BCP 172) [RFC6472] makes a recommendation for not 69 using AS_SET and AS_CONFED_SET in BGP. This document advances the 70 recommendation to a standards requirement in BGP. It updates RFC 71 4271 and proscribes the use of the AS_SET and AS_CONFED_SET types of 72 the AS_PATH in BGPv4. 74 The AS_SET path segment type of the AS_PATH attribute (Sections 4.3 75 and 5.1.2 of [RFC4271]) is created by a router that is performing 76 route aggregation and contains an unordered set of Autonomous Systems 77 (ASes) that the update has traversed. The AS_CONFED_SET path type 78 ([RFC5065]) of the AS_PATH attribute is created by a router that is 79 performing route aggregation and contains an unordered set of Member 80 AS Numbers in the local confederation that the update has traversed. 81 It is very similar to AS_SETs but is used within a confederation. 83 By performing aggregation, a router is, in essence, combining 84 multiple existing routes into a single new route. This type of 85 aggregation blurs the semantics of what it means to originate a 86 route. Said aggregation can therefore cause operational issues, such 87 as not being able to authenticate a route origin for the aggregate 88 prefix in new BGP security technologies (such as those that take 89 advantage of the "X.509 Extensions for IP Addresses and AS 90 Identifiers" [RFC3779]). This in turn would result in reachability 91 problems for the aggregated prefix and its components (i.e., more 92 specifics). Said aggregation also creates traffic engineering 93 issues, because the precise path information for the component 94 prefixes is not preserved. 96 From analysis of past Internet routing data, it is apparent that 97 aggregation that involves AS_SETs is very seldom used in practice on 98 the public network [Analysis] and, when it is used, it is usually 99 used incorrectly -- reserved AS numbers ([RFC1930]) and/or only a 100 single AS in the AS_SET are by far the most common case. Because the 101 aggregation involving AS_SETs is very rarely used, the reduction in 102 table size provided by said aggregation is extremely small, and any 103 advantage thereof is outweighed by additional complexity in BGP. As 104 noted above, said aggregation also poses impediments to 105 implementation of said new BGP security technologies. 107 In the past, AS_SET had been used in a few rare cases to allow route 108 aggregation where two or more providers could form the same prefix, 109 using the exact match of the other's prefix in some advertisement and 110 configuring the aggregation differently elsewhere. The key to 111 configuring this correctly was to form the aggregate at the border in 112 the outbound BGP policy and omit prefixes from the AS that the 113 aggregate was being advertised to. The AS_SET therefore allowed this 114 practice without the loss of BGP's AS_PATH loop protection. This use 115 of AS_SET served a purpose that fell in line with the original 116 intended use. Without the use of AS_SET, aggregates must always 117 contain only less specific prefixes (not less than or equal to), and 118 must never aggregate an exact match. 120 2. Requirements Notation 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 3. Recommendation to Network Operators 128 Operators MUST NOT generate any new announcements containing AS_SETs 129 or AS_CONFED_SETs. If they have already announced routes with 130 AS_SETs or AS_CONFED_SETs in them, then they MUST withdraw those 131 routes and re-announce routes for the component prefixes (i.e., the 132 more-specifics of the previously aggregated prefix) without AS_SETs 133 or CONFED_SETs in the updates. This involves undoing the aggregation 134 that was previously performed (with AS_SETs/CONFED_SETs), and 135 announcing more specifics (without AS_SETs/CONFED_SETs). Route 136 aggregation that was previously performed by proxy aggregation (i.e., 137 without the use of AS_SETs) is still possible under some conditions. 138 As with any change, the operator should understand the full 139 implications of the change. 141 It is worth noting that new technologies (such as those that take 142 advantage of the "X.509 Extensions for IP Addresses and AS 143 Identifiers" [RFC3779]) might not support routes with AS_SETs/ 144 AS_CONFED_SETs in them, and may treat as infeasible routes containing 145 them. Future BGP implementations may also do the same. It is 146 expected that, even before the deployment of these new or future 147 technologies, operators may filter routes with AS_SETs/AS_CONFED_SETs 148 in them. Other than making that observation, this document is not 149 intended to make any recommendation for how an operator should behave 150 when receiving a route with AS_SET or AS_CONFED_SET in it. This 151 document's focus is entirely on the sender side, as discussed in the 152 preceding paragraph. 154 4. IANA Considerations 156 This document requires no IANA actions. 158 5. Security Considerations 160 This document obsoletes the use of aggregation techniques that create 161 AS_SETs or AS_CONFED_SETs. Future work, intended for securing BGP, 162 may update the protocol to remove support for the AS_SET and 163 AS_CONFED_SET path segment type of the AS_PATH attribute. This 164 future work will remove complexity and code that are not exercised 165 very often, thereby decreasing the attack surface. 167 6. Acknowledgements 169 The authors would like to thank Tony Li, Randy Bush, John Scudder, 170 Curtis Villamizar, Danny McPherson, Chris Morrow, Tom Petch, and Ilya 171 Varlashkin, as well as Douglas Montgomery, Enke Chen, Florian Weimer, 172 Jakob Heitz, John Leslie, Keyur Patel, Paul Jakma, Rob Austein, Russ 173 Housley, Sandra Murphy, Steve Bellovin, Steve Kent, Steve Padgett, 174 Alfred Hoenes, Alvaro Retana, everyone in the IDR working group, and 175 everyone else who provided input. 177 Apologies to those who we may have missed; it was not intentional. 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 7.2. Informative References 190 [Analysis] 191 Sriram, K. and D. Montgomery, "Measurement Data on AS_SET 192 and AGGREGATOR: Implications for {Prefix, Origin} 193 Validation Algorithms", SIDR WG presentation, IETF 78, 194 July 2010, . 197 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 198 selection, and registration of an Autonomous System (AS)", 199 BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996, 200 . 202 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 203 Addresses and AS Identifiers", RFC 3779, 204 DOI 10.17487/RFC3779, June 2004, 205 . 207 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 208 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 209 DOI 10.17487/RFC4271, January 2006, 210 . 212 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 213 System Confederations for BGP", RFC 5065, 214 DOI 10.17487/RFC5065, August 2007, 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 Authors' Addresses 224 Warren Kumari 225 Google, Inc. 226 1600 Amphitheatre Parkway 227 Mountain View, CA 94043 228 US 230 Phone: +1 571 748 4373 231 Email: warren@kumari.net 232 Kotikalapudi Sriram 233 US NIST 234 100 Bureau Drive 235 Gaithersburg, MD 20899 236 US 238 Phone: +1 301 975 3973 239 Email: ksriram@nist.gov