RFC 3765

RFC 3765: NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control 🎀

okay bestie, so this is RFC 3765, and it's giving informational vibes 💅 It was written by G. Huston from Telstra and dated April 2004. The title block doesn't list any RFCs it obsoletes or updates, so it's just doing its own thing 🦋

---

Status of This Memo ✨

this memo is here to give info to the internet community 🌐 it does not specify an internet standard of any kind, and distribution of it is unlimited 💖

Copyright Notice 🔒

Copyright (C) The Internet Society (2004). All Rights Reserved. 💜

Abstract 🌸

okay so this doc describes how to use a scope control Border Gateway Protocol (BGP) community 🛣️ it's a well-known advisory transitive community, and it lets an origin AS decide how far a specific route should get propagated outside its network 🌍 the star of the show is NOPEER, which lets an origin AS say that a route with this attribute doesn't need to be advertised across bilateral peer connections 🙈

---

1. Introduction 🧚

so BGP today has a limited number of commonly defined mechanisms for letting a route get propagated across some subset of the routing system 😭 the NOEXPORT community lets a BGP speaker say that redistribution should only stretch to the neighbouring AS 🫶 providers also tend to define a bunch of communities so their neighbours can say how advertised routes should get re-advertised 💅 right now, the operational practice is that these communities get defined on an AS by AS basis. they let an AS influence re-advertisement of routes passed from a neighbouring AS, but they don't let that scope definition get passed along transitively to a remote AS 🚫

advertisement scope specification is most useful for setting the boundary conditions of route propagation ✨ it can look like a bunch of different things: an 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 bunch of reasons to control the scope of advertising route prefixes 🌈 like supporting limited transit services where advertisements are restricted to certain transit providers, and different kinds of selective transit in a multi-homed environment 👑

this memo doesn't try to cover all of those scope control motivations. it focuses on 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 makes a form of destination-based traffic engineering with some level of fail over protection 🛟 the more specific routes usually stop being useful for any traffic engineering outcome beyond a certain radius of redistribution. so a way of saying those routes don't need to be distributed beyond that point is worth a lot, because it helps moderate one of the factors behind continued route table growth 📈

analysis of BGP routing tables shows a big use of advertising more specific prefixes alongside a covering aggregate 👀 to help with the overall growth of BGP routing tables across the Internet, plus the burden of globally propagating dynamic changes in reachability of those more specific prefixes, this memo describes a transitive BGP route attribute 💖 it lets more specific route table entries get discarded from BGP tables under appropriate conditions. specifically, NOPEER lets a remote AS not advertise a route object to a neighbour AS when the two ASs are interconnected under some form of sender keep all arrangement, as opposed to some form of provider / customer arrangement 🤝

---

2. NOPEER Attribute 🦄

this memo defines the use of a new well-known BGP transitive community, NOPEER 🎀

the semantics here are that an AS can interpret the presence of this community as an advisory qualification on readvertising a route prefix. it lets an AS not readvertise the route prefix to all external bilateral peer neighbour ASs 🙌 it's consistent with these semantics that an AS may filter received prefixes that come across a peering session the receiver regards as a bilateral peer session 🔍

3. Motivation 💫

the size of the BGP routing table has been growing at an accelerating rate since late 1998 📈🚀 when this memo was published, the BGP forwarding table had over 118,000 entries. the three year growth rate of this table shows a trend that can be correlated to a compound growth rate of no less than 10% per year [2] 😳

one thing about the current BGP routing table is how widespread it is to advertise both an aggregate and a bunch of more specific address prefixes 🍓 for example, the table might have a routing entry for the prefix 10.0.0.0/23 and also entries for the prefixes 10.0.0.0/24 and 10.0.1.0/24. here the specific routes fully cover the aggregate announcement 🙌 sparse coverage of aggregates with more specifics is also observed. for example, routing entries for 10.0.0.0/8 and 10.0.1.0/24 can both exist in the routing table 👀 all together, these more specific route entries take up some 51% of the routing table. so more than half the routing table doesn't add any new address reachability info to the routing system. instead, it's used to impose a finer level of detail on existing reachability info 💅

there are a bunch of reasons to have both an aggregate route and a number of more specific routes in the routing table, including various multi-homed setups where there's a need to specify a different reachability policy for part of the advertised address space 🧩

one common requirement in multi-homed network configurations is doing some form of load balancing of incoming traffic across several external connections to several different neighbouring ASs ⚖️ say an AS wants a multi-homed config for routing-based load balancing and some form of mutual fail over between its multiple access connections for incoming traffic. one approach is for the AS to advertise the same aggregate address prefix to several upstream transit providers, then advertise a number of more specifics to individual upstream providers 🛰️ in that case, all the traffic headed for the more specific prefixes will only be received over those connections where the more specific has been advertised. if the neighbour BGP peering session carrying the more specific advertisement fails, the more specific stops being announced, and incoming traffic gets passed to the originating network based on the path tied to the advertisement of the encompassing aggregate 🔄 the more specific routes aren't automatically subsumed by the aggregate at any remote AS, though. both the aggregate and the associated more specifics get redistributed across the entire external BGP routing domain 🌊 in lots of cases, especially with traffic engineering and service resilience in mind, the more specific routes get redistributed well beyond the scope where they make any difference to traffic differentiation 😭

to the extent that remote analysis of BGP tables can see this kind of config, the entries in the BGP forwarding table where more specific entries share a common origin AS with their immediately enclosing aggregates make up 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, more specific routes make up some 14% of the FIB entries 🧮

one protocol mechanism that could be useful here is letting the originator of an advertisement state some extra qualification on its redistribution. that way a remote AS can suppress further redistribution under originator-specified criteria 🔐

the redistribution qualification condition can be specified either by enumeration or by classification 🗂️ enumeration would use a well-known transitive extended community to specify a list of remote ASs where further redistribution isn't advised. the weakness of this approach is that the originating AS would need to constantly revise this enumerated AS list to reflect changes in inter-AS topology. otherwise the more specific routes would leak beyond the intended redistribution scope 💀 classification lets an originating AS specify the conditions where further redistribution isn't advised, without having to name the particular ASs where a match to those conditions is expected ✨

the approach here to specifying the redistribution boundary condition is based on the type of bilateral inter-AS peering 🤍 when one AS can be considered a customer, and the other AS can be considered 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 the associated policy attached to them 📦 when neither AS can be considered a customer of the other, the relationship is bilateral peering, and neither AS can be considered an agent of the other when redistributing policies tied to routes 🫱🫲 this latter arrangement is commonly called a "sender keep all peer" relationship, or "peering" 💜

this peer boundary can be seen as a logical point where redistribution of the additional reachability policy the origin AS imposed on a route is no longer a required thing 🛑

this approach lets a prefix originator attach a commonly defined policy to a route prefix, and indicate that the route should be re-advertised conditionally, based on the characteristics of the inter-AS connection 🎀

4. IANA Considerations 📋

the IANA has registered NOPEER as a well-known community, as defined in [1], with global significance 🌍

NOPEER (0xFFFFFF04)

this is an advisory qualification on readvertising a route prefix, letting an AS not readvertise the route prefix to all external bilateral peer neighbour ASs. it's consistent with these semantics that an AS may filter received prefixes that come across a peering session the receiver regards as a bilateral peer sessions 🙈

5. Security Considerations 🔐

Okay so bestie, this section is the one where we get real, because BGP is basically a game of telephone where every router is a relay. 📞 Route info gets received, processed, and forwarded along, and BGP has no specific mechanisms to stop a forwarding agent from messing with it. So routing info can get modified, deleted, or have false stuff slipped in, and neither the originator nor any of the recipients would know. Yikes, that's giving chaos 💀

The NOPEER community does not change that. It doesn't fix the integrity of BGP as a routing system at all 🫶

Now the spicy part: using NOPEER can actually introduce new attack mechanisms into BGP 😭 It opens the door to man-in-the-middle, session-hijacking, or denial of service attacks against an address prefix range, and a remote AS could be the one launching them. Not me being dramatic, it's literally on the page 🙈

Unauthorized addition of this community to a route prefix by a transit provider with no covering aggregate route prefix can cause a denial of service attack, because the prefix becomes unreachable. 🚫

Even if there is a covering aggregate, if the more specific route has a different origin AS than the aggregate, a transit AS adding this community can still cause a denial of service attack on the origin AS of that more specific prefix. Main character energy for the wrong reasons 💅

Last thing, and it's kind of a bummer: BGP is already vulnerable to denial of service through injected false routing information. On top of that, NOPEER can be used to limit how far a false route gets redistributed. So its visibility stays small, and detecting and fixing the problem gets way harder when redistribution is limited 🌧️ Lowkey the sneakiest part of this whole doc ✨

6. References 📚

6.1. Normative References 🎀

[1] Chandrasekeran, R., Traina, P. and T. Li, "BGP Communities Attribute", RFC 1997, August 1996.

6.2. Informative References 🌸

[2] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001.

7. Author's Address 🦋

Geoff Huston Telstra

EMail: gih@telstra.net

8. Full Copyright Statement 🌈

Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 💜

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society.