idnits 2.17.1 draft-ietf-ptomaine-nopeer-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 4 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2003) is 7741 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 3221 (ref. '2') -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Geoff Huston 2 Internet Draft Telstra 3 Document: draft-ietf-ptomaine-nopeer-01.txt February 2003 4 Status: proposed as Informational Expires: August 2003 6 NOPEER community for BGP route scope control 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026 [1]. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. Internet-Drafts are draft documents valid for a maximum of 17 six months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- Drafts 19 as reference material or to cite them other than as "work in 20 progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Comments on this draft should be directed to gih@telstra.net. 30 Abstract 32 This document proposes the use of a scope control BGP community. 33 This proposed well-known advisory transitive community is intended 34 to allow an origin AS to specify the extent to which a specific 35 route should be externally propagated. In particular this community, 36 termed here as NOPEER, allows an origin AS to specify that a route 37 with this attribute need not be advertised across bilateral peer 38 connections. 40 1. Introduction 42 BGP today has a limited number of commonly defined mechanisms that 43 allow a route to be propagated across some subset of the routing 44 system. The NOEXPORT community allows a BGP speaker to specify that 45 redistribution should extend only to the neighbouring AS. Providers 46 commonly define a number of communities that allow their neighbours 47 to specify how advertised routes should be re-advertised. Current 48 operational practice is that such communities are defined on as AS 49 by AS basis, and while they allow an AS to influence the re- 50 advertisement behaviour of routes passed from a neighbouring AS, 51 they do not allow this scope definition ability to be passed in a 52 transitive fashion to a remote AS. 54 Advertisement scope specification is of most use in specifying the 55 boundary conditions of route propagation. The specification can take 56 on a number of forms, including as AS transit hop count, a set of 57 target ASs, the presence of a particular route object, or a 58 particular characteristic of the inter-AS connection. 60 There are a number of motivations for controlling the scope of 61 advertisement of route prefixes, including support of limited 62 transit services where advertisements are restricted to certain 63 transit providers, and various forms of selective transit in a 64 multi-homed environment. 66 This proposal does not attempt to address all such motivations of 67 scope control, and addresses in particular the situation of both 68 multi-homing and traffic engineering. The commonly adopted 69 operational technique is that the originating AS advertises an 70 encompassing aggregate route to all multi-home neighbours, and also 71 selectively advertises a collection of more specific routes. This 72 implements a form of destination-based traffic engineering with some 73 level of fail over protection. The more specific routes typically 74 cease to lever any useful traffic engineering outcome beyond a 75 certain radius of redistribution, and a means of advising that such 76 routes need not to be distributed beyond such a point is of some 77 value in moderating one of the factors of continued route table 78 growth. 80 Analysis of the BGP routing tables reveals a significant use of the 81 technique of advertising more specific prefixes in addition to 82 advertising a covering aggregate. In an effort to ameliorate some of 83 the effects of this practice, in terms of overall growth of the BGP 84 routing tables in the Internet and the associated burden of global 85 propagation of dynamic changes in the reachability of such more 86 specific address prefixes, this draft proposes the use of a 87 transitive BGP route attribute that is intended to allow more 88 specific route tables entries to be discarded from the BGP tables 89 under appropriate conditions. Specifically, this attribute, NOPEER, 90 allows a remote AS not to advertise a route object to a neighbour AS 91 when the two AS's are interconnected under the conditions of some 92 form of sender keep all arrangement, as distinct from some form of 93 provider / customer arrangement. 95 2. Proposal 96 The proposal is to define a new well-known bgp transitive community, 97 NOPEER. 99 The intended semantics of this attribute is to allow an AS to 100 interpret the presence of this community as an advisory 101 qualification to re advertisement of a route prefix, permitting an 102 AS not to re advertise the route prefix to all external bilateral 103 peer neighbour AS's. It is consistent with the intended semantics 104 that an AS may filter received prefixes that are received across a 105 peering session that the receiver regards as a bilateral peer 106 sessions. 108 3. Motivation 110 The size of the BGP routing table has been increasing at an 111 accelerating rate since late 1998. At the time of writing (April 112 2002) the BGP forwarding table contains over 100,000 entries, and 113 the three year growth rate of this table shows a trend rate which 114 can be correlated to a compound growth rate of no less than 40% per 115 year [2]. 117 One of the aspects of the current BGP routing table is the 118 widespread use of the technique of advertising both an aggregate and 119 a number of more specific address prefixes. For example, the table 120 may contain a routing entry for the prefix 10.0.0.0/23 and also 121 contain entries for the prefixes 10.0.0.0/24 and 10.0.1.0/24. In 122 this example the specific routes fully cover the aggregate 123 announcement. Sparse coverage of aggregates with more specifics is 124 also observed, where, for example, routing entries for 10.0.0.0/8 125 and 10.0.1.0/24 both exist in the routing table. In total, these 126 more specific route entries occupy some 52% of the routing table[3], 127 so that more than one half of the routing table does not add 128 additional address reachability information into the routing system, 129 but instead is used to impose a finer level of detail on existing 130 reachability information. 132 There are a number of motivations for having both an aggregate route 133 and a number of more specific routes in the routing table, including 134 various forms of multi-homed configurations, where there is a 135 requirement to specify a different reachability policy for a part of 136 the advertised address space. 138 One of the observed common requirements in the multi-homed network 139 configuration is that of undertaking some form of load balancing of 140 incoming traffic across a number of external connections to a number 141 of different neighbouring ASs. If, for example, an AS wishes to use 142 a multi-homed configuration for routing-based load balancing and 143 some form of mutual fail over between the multiple access 144 connections for incoming traffic, then one approach is for the AS to 145 advertise the same aggregate address prefix to a number of its 146 upstream transit providers, and then advertise a number of more 147 specifics to individual upstream providers. In such a case all of 148 the traffic destined to the more specific address prefixes will be 149 received only over those connections where the more specific has 150 been advertised. If the neighbour BGP peering session of the more 151 specific advertisement fails, the more specific will cease to be 152 announced and incoming traffic will then be passed to the 153 originating network based on the path associated with the 154 advertisement of the encompassing aggregate. In this situation the 155 more specific routes are not automatically subsumed by the presence 156 of the aggregate at any remote AS. Both the aggregate and the 157 associated more specifics are redistributed across the entire 158 external BGP routing domain. In many cases, particularly those 159 associated with desire to undertake traffic engineering and service 160 resilience, the more specific routes are redistributed well beyond 161 the scope where there is any outcomes in terms of traffic 162 differentiation. 164 To the extent that remote analysis of BGP tables can observe this 165 form of configuration, the number of entries in the BGP forwarding 166 table where more specific entries share a common origin AS with 167 their immediately enclosing aggregates comprise some 20% of the 168 total number of FIB entries. Using a slightly stricter criteria 169 where the AS path of the more specific route matches the immediately 170 enclosing aggregate, the number of more specific routes comprises 171 some 13% of the number of FIB entries [3]. 173 One protocol mechanism that could be useful in this context is to 174 allow the originator of an advertisement to state some additional 175 qualification on the redistribution of the advertisement, allowing a 176 remote AS to suppress further redistribution under some originator- 177 specified criteria. 179 The redistribution qualification condition can be specified either 180 by enumeration or by classification. Enumeration would encompass the 181 use of a well-known transitive extended community to specify a list 182 of remote AS's where further redistribution is not advised. The 183 weakness of this approach is that the originating AS would need to 184 constantly revise this enumerated AS list to reflect the changes in 185 inter-AS topology, as, otherwise, the more specific routes would 186 leak beyond the intended redistribution scope. An approach of 187 classification allows an originating AS to specify the conditions 188 where further redistribution is not advised without having to refer 189 to the particular AS's where a match to such conditions are 190 anticipated. 192 The approach proposed here to specifying the redistribution boundary 193 condition is one based on the type of bilateral inter-AS peering. 194 Where one AS can be considered as a customer, and the other AS can 195 be considered as a contracted agent of the customer, or provider, 196 then the relationship is one where the provider, as an agent of the 197 customer, carries the routes and associated policy associated with 198 the routes. Where neither AS can be considered as a customer of the 199 other, then the relationship is one of bilateral peering, and 200 neither AS can be considered as an agent of the other in 201 redistributing policies associated with routes. This latter 202 arrangement is commonly referred to as a "sender keep all peer" 203 relationship, or "peering". This peer boundary can be regarded as a 204 logical point where the redistribution of additional reachability 205 policy imposed by the origin AS on a route is no longer an imposed 206 requirement. 208 This approach allows an originator of a prefix to attach a commonly 209 defined policy to a route prefix, indicate that a route should be 210 re-advertised conditionally, based on the characteristics of the 211 inter-AS connection. 213 4. IANA considerations 215 Adoption of this proposal would imply the request to IANA for the 216 registration of a new BGP well-known transitive community field from 217 IANA. 219 5. Security considerations 221 BGP is an instance of a relaying protocol, where route information 222 is received, processed and forwarded. BGP contains no specific 223 mechanisms to prevent the unauthorized modification of the 224 information by a forwarding agent, allowing routing information to 225 be modified, deleted or false information to be inserted without the 226 knowledge of the originator of the routing information or any of the 227 recipients. 229 This proposed NOPEER community does not alter this overall situation 230 concerning the integrity of BGP as a routing system. 232 This proposal has the capability to introduce additional attack 233 mechanisms into BGP by allowing the potential for denial of service 234 attacks for an address prefix range being launched by a remote AS. 236 Unauthorized addition of this community to a route prefix by a 237 transit provider where there is no covering aggregate route prefix 238 may cause a denial of service attack based on denial of reachability 239 to the prefix. Even in the case that there is a covering aggregate, 240 if the more specific route has a different origin AS than the 241 aggregate, the addition of this community by a transit AS may cause 242 a denial of service attack on the origin AS of the more specific 243 prefix. 245 BGP is already vulnerable to a denial of service attack based on the 246 injection of false routing information. It is possible to use this 247 community to limit the redistribution of a false route entry such 248 that its visibility can be limited and detection and rectification 249 of the problem can be more difficult under the circumstances of 250 limited redistribution. 252 References 254 [1] "The Internet Standards Process -- Revision 3", S. Bradner, RFC 255 2026, October 1996. 257 [2] "Commentary in Inter-Domain Routing in the Internet", G. 258 Huston, RFC 3221, December 2001. 260 [3] Analysis of BGP table data - http://bgp.potaroo.net 262 Author's Address 264 Geoff Huston 265 Telstra 266 Email: gih@telstra.net