idnits 2.17.00 (12 Aug 2021) /tmp/idnits49984/draft-wkumari-deprecate-as-sets-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 : ---------------------------------------------------------------------------- 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 (August 31, 2010) is 4281 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-sidr-arch has been published as RFC 6480 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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: Informational August 31, 2010 5 Expires: March 4, 2011 7 Deprecation of BGP AS_SET. 8 draft-wkumari-deprecate-as-sets-00 10 Abstract 12 This document deprecates the use of the AS_SET type of the AS_PATH in 13 BGPv4. This is done to simply the design and implementation of the 14 BGP protocol and to make the semantics of the originator of a route 15 more clear. 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 March 4, 2011. 34 Copyright Notice 36 Copyright (c) 2010 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 Table of Contents 51 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Deployment and modification of behavior . . . . . . . . . . . 5 54 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 55 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 56 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 57 7. Normative References . . . . . . . . . . . . . . . . . . . . . 9 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 60 1. Requirements notation 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in [RFC2119]. 66 2. Introduction 68 The AS_SET path segment type of the AS_PATH attribute ([RFC4271], 69 Section 4.3) is created by a router that is performing route 70 aggregation and contains an unordered set of ASs that the update has 71 traversed. By performing aggregation, a router is, in essence, 72 combining multiple routes into a new route. 74 The RPKI ([I-D.ietf-sidr-arch]) provides a cryptographic means to 75 validate that a specific AS is authorized to announce a specific 76 network. The creation of an aggregate that contains an AS_SET means 77 that the aggregating router is originating a route for address space 78 that it cannot cryptographically prove that it is authorized to 79 originate. While it may be possible to include the route origin 80 attestations (ROA) from all of the routes that contribute to the 81 aggregate into the aggregate, this ends up being messy, inelegant and 82 has partial states that suck caterpillar snot! 84 From analysis of past Internet routing dumps it is apparent that 85 aggregation that involves AS_SETs is almost never used in practice 86 and, when it is usually contains reserved AS numbers ([RFC1930]) and 87 / or only a single AS in the AS_SET. The reductions in table size 88 provided by the aggregation is outweighed by additional complexity in 89 the BGP protocol and confusion regarding what exactly is meant by 90 originating a route. 92 3. Deployment and modification of behavior 94 It is expected that initially AS_SETs will be deprecated by the few 95 operators that are currently generating them, and operator policy 96 changing to filter them. Over time BGP implementations MAY no longer 97 support generating them, and eventually implementations MAY quietly 98 ignore updates with AS_SETs in them . Operators should take note 99 that new protocols (such as those that make use of the RPKI) are 100 likely to not work with AS_SETs and may ignore routes (treat as 101 infeasible) containing them. 103 4. IANA Considerations 105 This document contains no IANA considerations. 107 5. Security Considerations 109 By removing support for the AS_SET path segment type of the AS_PATH 110 attribute future BGP implementations can be simplified.. This will 111 also simplify the design and implementation of the RPKI and systems 112 that will rely on it. By removing corner cases we remove complexity 113 and code that is not exercised very often, which decreases the attack 114 surface. 116 6. Acknowledgements 118 The author would like to thank Randy Bush, Steve Bellovin, Russ 119 Housley, Steve Kent, Sandra Murphy, John Scudder, Sriram 120 Kotikalapudi, Chris Morrow, Rob Austein, Douglas Montgomery, Keyur 121 Patel, and everyone else who provided input. 123 Apologies to those who I may have missed. 125 7. Normative References 127 [I-D.ietf-sidr-arch] 128 Lepinski, M. and S. Kent, "An Infrastructure to Support 129 Secure Internet Routing", draft-ietf-sidr-arch-09 (work in 130 progress), October 2009. 132 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 133 selection, and registration of an Autonomous System (AS)", 134 BCP 6, RFC 1930, March 1996. 136 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 137 Requirement Levels", BCP 14, RFC 2119, March 1997. 139 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 140 Protocol 4 (BGP-4)", RFC 4271, January 2006. 142 Author's Address 144 Warren Kumari 145 Google, Inc. 146 1600 Amphitheatre Parkway 147 Mountain View, CA 94043 148 US 150 Phone: +1 571 748 4373 151 Email: warren@kumari.net