< draft-kumari-deprecate-as-set-confed-set-13.txt   draft-kumari-deprecate-as-set-confed-set-14.txt >
Network Working Group W. Kumari Network Working Group W. Kumari
Internet-Draft Google, Inc. Internet-Draft Google, Inc.
Intended status: Standards Track K. Sriram Intended status: Standards Track K. Sriram
Expires: July 21, 2019 USA NIST Expires: February 6, 2020 USA NIST
January 17, 2019 August 5, 2019
Deprecation of AS_SET and AS_CONFED_SET in BGP Deprecation of AS_SET and AS_CONFED_SET in BGP
draft-kumari-deprecate-as-set-confed-set-13 draft-kumari-deprecate-as-set-confed-set-14
Abstract Abstract
RFC 6472 (i.e., BCP 172) recommends not using AS_SET and BCP 172 (i.e., RFC 6472) recommends not using AS_SET and
AS_CONFED_SET in BGP. This document updates RFC 4271 and proscribes AS_CONFED_SET in Border Gateway Protocol (BGP). This document
the use of the AS_SET and AS_CONFED_SET types of the AS_PATH in updates RFC 4271 and proscribes the use of the AS_SET and
BGPv4. This is done to simplify the design and implementation of BGP AS_CONFED_SET types of path segments in the AS_PATH. This is done to
and to make the semantics of the originator of a route more clear. simplify the design and implementation of BGP and to make the
This will also simplify the design, implementation, and deployment of semantics of the originator of a route clearer. This will also
ongoing work in the Secure Inter-Domain Routing Working Group. simplify the design, implementation, and deployment of various BGP
security mechanisms.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 21, 2019. This Internet-Draft will expire on February 6, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Recommendation to Network Operators . . . . . . . . . . . . . 3 3. Recommendation to Network Operators . . . . . . . . . . . . . 3
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
7.1. Normative References . . . . . . . . . . . . . . . . . . 4 7.1. Normative References . . . . . . . . . . . . . . . . . . 4
7.2. Informative References . . . . . . . . . . . . . . . . . 5 7.2. Informative References . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
RFC 6472 (i.e., BCP 172) [RFC6472] makes a recommendation for not BCP 172 [RFC6472] makes a recommendation for not using AS_SET and
using AS_SET and AS_CONFED_SET in BGP. This document advances the AS_CONFED_SET in Border Gateway Protocol (BGP). This document
recommendation to a standards requirement in BGP. It updates RFC advances the recommendation to a standards requirement in BGP. It
4271 and proscribes the use of the AS_SET and AS_CONFED_SET types of updates [RFC4271] and proscribes the use of the AS_SET and
the AS_PATH in BGPv4. AS_CONFED_SET types of path segments in the AS_PATH.
The AS_SET path segment type of the AS_PATH attribute (Sections 4.3 The AS_SET path segment in the AS_PATH attribute (Sections 4.3 and
and 5.1.2 of [RFC4271]) is created by a router that is performing 5.1.2 of [RFC4271]) is created by a router that is performing route
route aggregation and contains an unordered set of Autonomous Systems aggregation and contains an unordered set of Autonomous Systems
(ASes) that the update has traversed. The AS_CONFED_SET path type (ASes) that the update has traversed. The AS_CONFED_SET path segment
([RFC5065]) of the AS_PATH attribute is created by a router that is (see [RFC5065]) in the AS_PATH attribute is created by a router that
performing route aggregation and contains an unordered set of Member is performing route aggregation and contains an unordered set of
AS Numbers in the local confederation that the update has traversed. Member AS Numbers in the local confederation that the update has
It is very similar to AS_SETs but is used within a confederation. traversed. It is very similar to AS_SETs but is used within a
confederation.
By performing aggregation, a router is, in essence, combining By performing aggregation, a router is combining multiple existing
multiple existing routes into a single new route. This type of routes into a single new route. The aggregation together with the
aggregation blurs the semantics of what it means to originate a use of AS_SET blurs the semantics of origin AS for the prefix being
route. Said aggregation can therefore cause operational issues, such announced. Therefore, the aggregation with AS_SET (or AS_CONFED_SET)
as not being able to authenticate a route origin for the aggregate can cause operational issues, such as not being able to authenticate
prefix in new BGP security technologies (such as those that take a route origin for the aggregate prefix in new BGP security
advantage of the "X.509 Extensions for IP Addresses and AS technologies such as those that take advantage of X.509 extensions
Identifiers" [RFC3779]). This in turn would result in reachability for IP addresses and AS identifiers [RFC3779] [RFC6811] [RFC8205].
problems for the aggregated prefix and its components (i.e., more This in turn could result in reachability problems for the aggregated
specifics). Said aggregation also creates traffic engineering prefix and its components (i.e., more-specific prefixes). The
aggregation as described above could also create traffic engineering
issues, because the precise path information for the component issues, because the precise path information for the component
prefixes is not preserved. prefixes are not preserved.
From analysis of past Internet routing data, it is apparent that From analysis of past Internet routing data, it is apparent that
aggregation that involves AS_SETs is very seldom used in practice on aggregation that involves AS_SETs is very seldom used in practice on
the public network [Analysis] and, when it is used, it is usually the public Internet [Analysis] and when it is used, it is often used
used incorrectly -- reserved AS numbers ([RFC1930]) and/or only a incorrectly -- reserved AS numbers ([RFC1930]) and/or only a single
single AS in the AS_SET are by far the most common case. Because the AS in the AS_SET are by far the most common cases. Because the
aggregation involving AS_SETs is very rarely used, the reduction in aggregation involving AS_SETs is very rarely used, the reduction in
table size provided by said aggregation is extremely small, and any table size provided by said aggregation is extremely small, and any
advantage thereof is outweighed by additional complexity in BGP. As advantage thereof is outweighed by additional complexity in BGP. As
noted above, said aggregation also poses impediments to noted above, said aggregation also poses impediments to
implementation of said new BGP security technologies. implementation of new BGP security technologies.
In the past, AS_SET had been used in a few rare cases to allow route 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, aggregation where two or more providers could form the same aggregate
using the exact match of the other's prefix in some advertisement and prefix, using the exact match of the other's aggregate prefix in some
configuring the aggregation differently elsewhere. The key to advertisement and configuring the aggregation differently elsewhere.
configuring this correctly was to form the aggregate at the border in The key to configuring this correctly was to form the aggregate at
the outbound BGP policy and omit prefixes from the AS that the the border in the outbound BGP policy and omit prefixes from the AS
aggregate was being advertised to. The AS_SET therefore allowed this that the aggregate was being advertised to. The AS_SET therefore
practice without the loss of BGP's AS_PATH loop protection. This use allowed this practice without the loss of BGP's AS_PATH loop
of AS_SET served a purpose that fell in line with the original protection. This use of AS_SET served a purpose that fell in line
intended use. Without the use of AS_SET, aggregates must always with the original intended use. Without the use of AS_SET,
contain only less specific prefixes (not less than or equal to), and aggregates must always contain only less-specific prefixes (not less
must never aggregate an exact match. than or equal to) and must never aggregate an exact match.
2. Requirements Notation 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Recommendation to Network Operators 3. Recommendation to Network Operators
Operators MUST NOT generate any new announcements containing AS_SETs Operators MUST NOT generate any new announcements containing AS_SETs
or AS_CONFED_SETs. If they have already announced routes with or AS_CONFED_SETs. If they have already announced routes with
AS_SETs or AS_CONFED_SETs in them, then they MUST withdraw those AS_SETs or AS_CONFED_SETs in them, then they MUST withdraw those
routes and re-announce routes for the component prefixes (i.e., the routes and re-announce routes for the component prefixes (i.e., the
more-specifics of the previously aggregated prefix) without AS_SETs more-specific prefixes subsumed by the previously aggregated prefix)
or CONFED_SETs in the updates. This involves undoing the aggregation without AS_SETs or CONFED_SETs in the updates. Route aggregation
that was previously performed (with AS_SETs/CONFED_SETs), and that was previously performed by proxy aggregation (i.e., without the
announcing more specifics (without AS_SETs/CONFED_SETs). Route use of AS_SETs) is still possible under some conditions. When doing
aggregation that was previously performed by proxy aggregation (i.e., this, operators MUST form the aggregate at the border in the outbound
without the use of AS_SETs) is still possible under some conditions. BGP policy and omit any prefixes from the AS that the aggregate was
As with any change, the operator should understand the full being advertised to. As with any change, the operator should
implications of the change. understand the full implications of the change.
It is worth noting that new technologies (such as those that take It is worth noting that new BGP security technologies (such as those
advantage of the "X.509 Extensions for IP Addresses and AS that take advantage of X.509 extensions for IP addresses and AS
Identifiers" [RFC3779]) might not support routes with AS_SETs/ identifiers [RFC3779] [RFC6811] [RFC8205]) might not support routes
AS_CONFED_SETs in them, and may treat as infeasible routes containing with AS_SETs/AS_CONFED_SETs in them, and may treat routes containing
them. Future BGP implementations may also do the same. It is them as infeasible. Future BGP implementations may also do the same.
expected that, even before the deployment of these new or future It is expected that, even before the deployment of these new or
technologies, operators may filter routes with AS_SETs/AS_CONFED_SETs future technologies, operators may filter routes with AS_SETs/
in them. Other than making that observation, this document is not AS_CONFED_SETs in them. Other than making that observation, this
intended to make any recommendation for how an operator should behave document is not intended to make any recommendation for how an
when receiving a route with AS_SET or AS_CONFED_SET in it. This implementation should behave when receiving a route with AS_SET or
document's focus is entirely on the sender side, as discussed in the AS_CONFED_SET in it. This document's focus is entirely on the sender
preceding paragraph. side, as discussed in the preceding paragraph.
4. IANA Considerations 4. Security Considerations
This document requires no IANA actions. This document obsoletes the use of aggregation techniques that create
AS_SETs or AS_CONFED_SETs. Obsoleting these path segment types from
BGP and removal of the related code from implementations would
potentially decrease the attack surface for BGP.
5. Security Considerations 5. IANA Considerations
This document obsoletes the use of aggregation techniques that create This document requires no IANA actions.
AS_SETs or AS_CONFED_SETs. Future work, intended for securing BGP,
may update the protocol to remove support for the AS_SET and
AS_CONFED_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.
6. Acknowledgements 6. Acknowledgements
The authors would like to thank Tony Li, Randy Bush, John Scudder, The authors would like to thank Tony Li, Randy Bush, John Scudder,
Curtis Villamizar, Danny McPherson, Chris Morrow, Tom Petch, and Ilya Curtis Villamizar, Danny McPherson, Chris Morrow, Tom Petch, Ilya
Varlashkin, as well as Douglas Montgomery, Enke Chen, Florian Weimer, Varlashkin, Douglas Montgomery, Enke Chen, Florian Weimer, Jakob
Jakob Heitz, John Leslie, Keyur Patel, Paul Jakma, Rob Austein, Russ Heitz, John Leslie, Keyur Patel, Paul Jakma, Rob Austein, Russ
Housley, Sandra Murphy, Steve Bellovin, Steve Kent, Steve Padgett, Housley, Sandra Murphy, Steve Bellovin, Steve Kent, Steve Padgett,
Alfred Hoenes, Alvaro Retana, everyone in the IDR working group, and Alfred Hoenes, and Alvaro Retana.
everyone else who provided input.
Apologies to those who we may have missed; it was not intentional.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous
System Confederations for BGP", RFC 5065,
DOI 10.17487/RFC5065, August 2007,
<https://www.rfc-editor.org/info/rfc5065>.
7.2. Informative References 7.2. Informative References
[Analysis] [Analysis]
Sriram, K. and D. Montgomery, "Measurement Data on AS_SET Sriram, K. and D. Montgomery, "Measurement Data on AS_SET
and AGGREGATOR: Implications for {Prefix, Origin} and AGGREGATOR: Implications for {Prefix, Origin}
Validation Algorithms", SIDR WG presentation, IETF 78, Validation Algorithms", SIDR WG presentation, IETF 78,
July 2010, <http://www.nist.gov/itl/antd/upload/ July 2010, <http://www.nist.gov/itl/antd/upload/
AS_SET_Aggregator_Stats.pdf>. AS_SET_Aggregator_Stats.pdf>.
[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation,
selection, and registration of an Autonomous System (AS)", selection, and registration of an Autonomous System (AS)",
BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996, BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996,
<https://www.rfc-editor.org/info/rfc1930>. <https://www.rfc-editor.org/info/rfc1930>.
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, Addresses and AS Identifiers", RFC 3779,
DOI 10.17487/RFC3779, June 2004, DOI 10.17487/RFC3779, June 2004,
<https://www.rfc-editor.org/info/rfc3779>. <https://www.rfc-editor.org/info/rfc3779>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous
System Confederations for BGP", RFC 5065,
DOI 10.17487/RFC5065, August 2007,
<https://www.rfc-editor.org/info/rfc5065>.
[RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using [RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using
AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472, AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472,
DOI 10.17487/RFC6472, December 2011, DOI 10.17487/RFC6472, December 2011,
<https://www.rfc-editor.org/info/rfc6472>. <https://www.rfc-editor.org/info/rfc6472>.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Austein, "BGP Prefix Origin Validation", RFC 6811,
DOI 10.17487/RFC6811, January 2013,
<https://www.rfc-editor.org/info/rfc6811>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol
Specification", RFC 8205, DOI 10.17487/RFC8205, September
2017, <https://www.rfc-editor.org/info/rfc8205>.
Authors' Addresses Authors' Addresses
Warren Kumari Warren Kumari
Google, Inc. Google, Inc.
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
US US
Phone: +1 571 748 4373 Phone: +1 571 748 4373
Email: warren@kumari.net Email: warren@kumari.net
 End of changes. 27 change blocks. 
103 lines changed or deleted 116 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/