From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6472.txt | 283 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 283 insertions(+) create mode 100644 doc/rfc/rfc6472.txt (limited to 'doc/rfc/rfc6472.txt') diff --git a/doc/rfc/rfc6472.txt b/doc/rfc/rfc6472.txt new file mode 100644 index 0000000..42aeeef --- /dev/null +++ b/doc/rfc/rfc6472.txt @@ -0,0 +1,283 @@ + + + + + + +Internet Engineering Task Force (IETF) W. Kumari +Request for Comments: 6472 Google, Inc. +BCP: 172 K. Sriram +Category: Best Current Practice U.S. NIST +ISSN: 2070-1721 December 2011 + + + Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP + +Abstract + + This document recommends against the use of the AS_SET and + AS_CONFED_SET types of the AS_PATH in BGPv4. This is done to + simplify the design and implementation of BGP and to make the + semantics of the originator of a route more clear. This will also + simplify the design, implementation, and deployment of ongoing work + in the Secure Inter-Domain Routing Working Group. + +Status of This Memo + + This memo documents an Internet Best Current Practice. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + BCPs is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6472. + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + +Kumari & Sriram Best Current Practice [Page 1] + +RFC 6472 AS_SET, AS_CONFED_SET Use Deprecation December 2011 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Requirements Notation ...........................................3 + 3. Recommendation to Network Operators .............................3 + 4. Security Considerations .........................................4 + 5. Acknowledgements ................................................4 + 6. References ......................................................4 + 6.1. Normative References .......................................4 + 6.2. Informative References .....................................4 + +1. Introduction + + The AS_SET path segment type of the AS_PATH attribute (Sections 4.3 + and 5.1.2 of [RFC4271]) is created by a router that is performing + route aggregation and contains an unordered set of Autonomous Systems + (ASes) that the update has traversed. The AS_CONFED_SET path type + ([RFC5065]) of the AS_PATH attribute is created by a router that is + performing route aggregation and contains an unordered set of Member + AS Numbers in the local confederation that the update has traversed. + It is very similar to AS_SETs but is used within a confederation. + + By performing aggregation, a router is, in essence, combining + multiple existing routes into a single new route. This type of + aggregation blurs the semantics of what it means to originate a + route. Said aggregation can therefore cause operational issues, such + as not being able to authenticate a route origin for the aggregate + prefix in new BGP security technologies (such as those that take + advantage of the "X.509 Extensions for IP Addresses and AS + Identifiers" [RFC3779]). This in turn would result in reachability + problems for the aggregated prefix and its components (i.e., more + specifics). Said aggregation also creates traffic engineering + issues, because the precise path information for the component + prefixes is not preserved. + + From analysis of past Internet routing data, it is apparent that + aggregation that involves AS_SETs is very seldom used in practice on + the public network [Analysis] and, when it is used, it is usually + used incorrectly -- reserved AS numbers ([RFC1930]) and/or only a + single AS in the AS_SET are by far the most common case. Because the + aggregation involving AS_SETs is very rarely used, the reduction in + table size provided by said aggregation is extremely small, and any + advantage thereof is outweighed by additional complexity in BGP. As + noted above, said aggregation also poses impediments to + implementation of said new BGP security technologies. + + + + + + +Kumari & Sriram Best Current Practice [Page 2] + +RFC 6472 AS_SET, AS_CONFED_SET Use Deprecation December 2011 + + + In the past, AS_SET had been used in a few rare cases to allow route + aggregation where two or more providers could form the same prefix, + using the exact match of the other's prefix in some advertisement and + configuring the aggregation differently elsewhere. The key to + configuring this correctly was to form the aggregate at the border in + the outbound BGP policy and omit prefixes from the AS that the + aggregate was being advertised to. The AS_SET therefore allowed this + practice without the loss of BGP's AS_PATH loop protection. This use + of AS_SET served a purpose that fell in line with the original + intended use. Without the use of AS_SET, aggregates must always + contain only less specific prefixes (not less than or equal to), and + must never aggregate an exact match. + +2. Requirements Notation + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +3. Recommendation to Network Operators + + It is RECOMMENDED that operators not generate any new announcements + containing AS_SETs or AS_CONFED_SETs. If they have already announced + routes with AS_SETs or AS_CONFED_SETs in them, then they SHOULD + withdraw those routes and re-announce routes for the component + prefixes (i.e., the additional specifics of the previously aggregated + prefix) without AS_SETs in the updates. This involves undoing the + aggregation that was previously performed (with AS_SETs), and + announcing more specifics (without AS_SETs). Route aggregation that + was previously performed by proxy aggregation (i.e., without the use + of AS_SETs) is still possible under some conditions. As with any + change, the operator should understand the full implications of the + change. + + It is worth noting that new technologies (such as those that take + advantage of the "X.509 Extensions for IP Addresses and AS + Identifiers" [RFC3779]) might not support routes with AS_SETs/ + AS_CONFED_SETs in them, and may treat as infeasible routes containing + them. Future BGP implementations may also do the same. It is + expected that, even before the deployment of these new or future + technologies, operators may filter routes with AS_SETs/AS_CONFED_SETs + in them. Other than making that observation, this document is not + intended to make any recommendation for how an operator should behave + when receiving a route with AS_SET or AS_CONFED_SET in it. This + document's focus is entirely on the sender side, as discussed in the + preceding paragraph. + + + + + +Kumari & Sriram Best Current Practice [Page 3] + +RFC 6472 AS_SET, AS_CONFED_SET Use Deprecation December 2011 + + +4. Security Considerations + + This document discourages the use of aggregation techniques that + create AS_SETs. Future work may update the protocol to remove + support for the AS_SET path segment type of the AS_PATH attribute. + This future work will remove complexity and code that are not + exercised very often, thereby decreasing the attack surface. This + future work will also simplify the design and implementation of the + Resource Public Key Infrastructure (RPKI) and systems that will + rely on it. + +5. Acknowledgements + + The authors would like to thank Tony Li, Randy Bush, John Scudder, + Curtis Villamizar, Danny McPherson, Chris Morrow, Tom Petch, and Ilya + Varlashkin, as well as Douglas Montgomery, Enke Chen, Florian Weimer, + Jakob Heitz, John Leslie, Keyur Patel, Paul Jakma, Rob Austein, Russ + Housley, Sandra Murphy, Steve Bellovin, Steve Kent, Steve Padgett, + Alfred Hoenes, Alvaro Retana, everyone in the IDR working group, and + everyone else who provided input. + + Apologies to those who we may have missed; it was not intentional. + +6. References + +6.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +6.2. Informative References + + [Analysis] Sriram, K. and D. Montgomery, "Measurement Data on AS_SET + and AGGREGATOR: Implications for {Prefix, Origin} + Validation Algorithms", SIDR WG presentation, IETF 78, + July 2010, . + + [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, + selection, and registration of an Autonomous System + (AS)", BCP 6, RFC 1930, March 1996. + + [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP + Addresses and AS Identifiers", RFC 3779, June 2004. + + + + + + + +Kumari & Sriram Best Current Practice [Page 4] + +RFC 6472 AS_SET, AS_CONFED_SET Use Deprecation December 2011 + + + [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A + Border Gateway Protocol 4 (BGP-4)", RFC 4271, + January 2006. + + [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous + System Confederations for BGP", RFC 5065, August 2007. + +Authors' Addresses + + Warren Kumari + Google, Inc. + 1600 Amphitheatre Parkway + Mountain View, CA 94043 + US + + Phone: +1 571 748 4373 + EMail: warren@kumari.net + + + Kotikalapudi Sriram + U.S. NIST + 100 Bureau Drive + Gaithersburg, MD 20899 + US + + Phone: +1 301 975 3973 + EMail: ksriram@nist.gov + + + + + + + + + + + + + + + + + + + + + + + + +Kumari & Sriram Best Current Practice [Page 5] + -- cgit v1.2.3