NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control
The information below is for an old version of the document that is already published as an RFC.
This is an older version of an Internet-Draft that was ultimately published as RFC 3765.
|2015-10-14 (Latest revision 2003-05-13)
|Intended RFC status
|Mailing list discussion
|Became RFC 3765 (Informational)
|Send notices to
Ptomaine G. Huston Internet-Draft Telstra Expires: November 11, 2003 May 13, 2003 NOPEER community for BGP route scope control draft-ietf-ptomaine-nopeer-03.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 11, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document describes the use of a scope control BGP community. This well-known advisory transitive community allows an origin AS to specify the extent to which a specific route should be externally propagated. In particular this community, NOPEER, allows an origin AS to specify that a route with this attribute need not be advertised across bilateral peer connections. 1. Introduction BGP today has a limited number of commonly defined mechanisms that allow a route to be propagated across some subset of the routing system. The NOEXPORT community allows a BGP speaker to specify that redistribution should extend only to the neighbouring AS. Providers Huston Expires November 11, 2003 [Page 1] Internet-Draft NOPEER May 2003 commonly define a number of communities that allow their neighbours to specify how advertised routes should be re-advertised. Current operational practice is that such communities are defined on as AS by AS basis, and while they allow an AS to influence the re- advertisement behaviour of routes passed from a neighbouring AS, they do not allow this scope definition ability to be passed in a transitive fashion to a remote AS. Advertisement scope specification is of most use in specifying the boundary conditions of route propagation. The specification can take on a number of forms, including as AS transit hop count, a set of target ASs, the presence of a particular route object, or a particular characteristic of the inter-AS connection. There are a number of motivations for controlling the scope of advertisement of route prefixes, including support of limited transit services where advertisements are restricted to certain transit providers, and various forms of selective transit in a multi-homed environment. This memo does not attempt to address all such motivations of scope control, and addresses in particular the situation of both multi- homing and traffic engineering. The commonly adopted operational technique is that the originating AS advertises an encompassing aggregate route to all multi-home neighbours, and also selectively advertises a collection of more specific routes. This implements a form of destination-based traffic engineering with some level of fail over protection. The more specific routes typically cease to lever any useful traffic engineering outcome beyond a certain radius of redistribution, and a means of advising that such routes need not to be distributed beyond such a point is of some value in moderating one of the factors of continued route table growth. Analysis of the BGP routing tables reveals a significant use of the technique of advertising more specific prefixes in addition to advertising a covering aggregate. In an effort to ameliorate some of the effects of this practice, in terms of overall growth of the BGP routing tables in the Internet and the associated burden of global propagation of dynamic changes in the reachability of such more specific address prefixes, this memo describes the use of a transitive BGP route attribute that allows more specific route tables entries to be discarded from the BGP tables under appropriate conditions. Specifically, this attribute, NOPEER, allows a remote AS not to advertise a route object to a neighbour AS when the two AS's are interconnected under the conditions of some form of sender keep all arrangement, as distinct from some form of provider / customer arrangement. Huston Expires November 11, 2003 [Page 2] Internet-Draft NOPEER May 2003 2. NOPEER Attribute This memo defines the use a new well-known bgp transitive community, NOPEER. The semantics of this attribute is to allow an AS to interpret the presence of this community as an advisory qualification to readvertisement of a route prefix, permitting an AS not to readvertise the route prefix to all external bilateral peer neighbour AS's. It is consistent with these semantics that an AS may filter received prefixes that are received across a peering session that the receiver regards as a bilateral peer sessions. 3. Motivation The size of the BGP routing table has been increasing at an accelerating rate since late 1998. At the time of publication of this memo the BGP forwarding table contains over 118,000 entries, and the three year growth rate of this table shows a trend rate which can be correlated to a compound growth rate of no less than 10% per year . One of the aspects of the current BGP routing table is the widespread use of the technique of advertising both an aggregate and a number of more specific address prefixes. For example, the table may contain a routing entry for the prefix 10.0.0.0/23 and also contain entries for the prefixes 10.0.0.0/24 and 10.0.1.0/24. In this example the specific routes fully cover the aggregate announcement. Sparse coverage of aggregates with more specifics is also observed, where, for example, routing entries for 10.0.0.0/8 and 10.0.1.0/24 both exist in the routing table. In total, these more specific route entries occupy some 51% of the routing table, so that more than one half of the routing table does not add additional address reachability information into the routing system, but instead is used to impose a finer level of detail on existing reachability information. There are a number of motivations for having both an aggregate route and a number of more specific routes in the routing table, including various forms of multi-homed configurations, where there is a requirement to specify a different reachability policy for a part of the advertised address space. One of the observed common requirements in the multi-homed network configuration is that of undertaking some form of load balancing of incoming traffic across a number of external connections to a number of different neighbouring ASs. If, for example, an AS wishes to use a multi-homed configuration for routing-based load balancing and some Huston Expires November 11, 2003 [Page 3] Internet-Draft NOPEER May 2003 form of mutual fail over between the multiple access connections for incoming traffic, then one approach is for the AS to advertise the same aggregate address prefix to a number of its upstream transit providers, and then advertise a number of more specifics to individual upstream providers. In such a case all of the traffic destined to the more specific address prefixes will be received only over those connections where the more specific has been advertised. If the neighbour BGP peering session of the more specific advertisement fails, the more specific will cease to be announced and incoming traffic will then be passed to the originating network based on the path associated with the advertisement of the encompassing aggregate. In this situation the more specific routes are not automatically subsumed by the presence of the aggregate at any remote AS. Both the aggregate and the associated more specifics are redistributed across the entire external BGP routing domain. In many cases, particularly those associated with desire to undertake traffic engineering and service resilience, the more specific routes are redistributed well beyond the scope where there is any outcomes in terms of traffic differentiation. To the extent that remote analysis of BGP tables can observe this form of configuration, the number of entries in the BGP forwarding table where more specific entries share a common origin AS with their immediately enclosing aggregates comprise some 20% of the total number of FIB entries. Using a slightly stricter criteria where the AS path of the more specific route matches the immediately enclosing aggregate, the number of more specific routes comprises some 14% of the number of FIB entries. One protocol mechanism that could be useful in this context is to allow the originator of an advertisement to state some additional qualification on the redistribution of the advertisement, allowing a remote AS to suppress further redistribution under some originator- specified criteria. The redistribution qualification condition can be specified either by enumeration or by classification. Enumeration would encompass the use of a well-known transitive extended community to specify a list of remote AS's where further redistribution is not advised. The weakness of this approach is that the originating AS would need to constantly revise this enumerated AS list to reflect the changes in inter-AS topology, as, otherwise, the more specific routes would leak beyond the intended redistribution scope. An approach of classification allows an originating AS to specify the conditions where further redistribution is not advised without having to refer to the particular AS's where a match to such conditions are anticipated. The approach described here to specifying the redistribution boundary Huston Expires November 11, 2003 [Page 4] Internet-Draft NOPEER May 2003 condition is one based on the type of bilateral inter-AS peering. Where one AS can be considered as a customer, and the other AS can be considered as a contracted agent of the customer, or provider, then the relationship is one where the provider, as an agent of the customer, carries the routes and associated policy associated with the routes. Where neither AS can be considered as a customer of the other, then the relationship is one of bilateral peering, and neither AS can be considered as an agent of the other in redistributing policies associated with routes. This latter arrangement is commonly referred to as a "sender keep all peer" relationship, or "peering". This peer boundary can be regarded as a logical point where the redistribution of additional reachability policy imposed by the origin AS on a route is no longer an imposed requirement. This approach allows an originator of a prefix to attach a commonly defined policy to a route prefix, indicate that a route should be re-advertised conditionally, based on the characteristics of the inter-AS connection. 4. IANA considerations The IANA should register NOPEER as a well-known community, as defined in , as having global significance. NOPEER (0xFFFFFF04) This is an advisory qualification to readvertisement of a route prefix, permitting an AS not to readvertise the route prefix to all external bilateral peer neighbour AS's. It is consistent with these semantics that an AS may filter received prefixes that are received across a peering session that the receiver regards as a bilateral peer sessions 5. Security considerations BGP is an instance of a relaying protocol, where route information is received, processed and forwarded. BGP contains no specific mechanisms to prevent the unauthorized modification of the information by a forwarding agent, allowing routing information to be modified, deleted or false information to be inserted without the knowledge of the originator of the routing information or any of the recipients. The NOPEER community does not alter this overall situation concerning the integrity of BGP as a routing system. Use of the NOPEER community has the capability to introduce additional attack mechanisms into BGP by allowing the potential for Huston Expires November 11, 2003 [Page 5] Internet-Draft NOPEER May 2003 man-in-the-middle, session-hijacking, or denial of service attacks for an address prefix range being launched by a remote AS. Unauthorized addition of this community to a route prefix by a transit provider where there is no covering aggregate route prefix may cause a denial of service attack based on denial of reachability to the prefix. Even in the case that there is a covering aggregate, if the more specific route has a different origin AS than the aggregate, the addition of this community by a transit AS may cause a denial of service attack on the origin AS of the more specific prefix. BGP is already vulnerable to a denial of service attack based on the injection of false routing information. It is possible to use this community to limit the redistribution of a false route entry such that its visibility can be limited and detection and rectification of the problem can be more difficult under the circumstances of limited redistribution. References Normative References:  Chandrasekeran, R., Traina, P. and T. Li, "BGP Communities Attribute", RFC 1997, August 1996. INformative References:  Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001. Author's Address Geoff Huston Telstra Huston Expires November 11, 2003 [Page 6] Internet-Draft NOPEER May 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Huston Expires November 11, 2003 [Page 7] Internet-Draft NOPEER May 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Huston Expires November 11, 2003 [Page 8]