1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
|
<pre>Network Working Group G. Huston
Request for Comments: 3765 Telstra
Category: Informational April 2004
<span class="h1">NOPEER Community for Border Gateway Protocol (BGP)</span>
<span class="h1">Route Scope Control</span>
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document describes the use of a scope control Border Gateway
Protocol (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.
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
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
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.
<span class="grey">Huston Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3765">RFC 3765</a> NOPEER April 2004</span>
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.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. NOPEER Attribute</span>
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.
<span class="grey">Huston Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3765">RFC 3765</a> NOPEER April 2004</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Motivation</span>
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
[<a href="#ref-2" title=""Commentary on Inter-Domain Routing in the Internet"">2</a>].
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
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
<span class="grey">Huston Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3765">RFC 3765</a> NOPEER April 2004</span>
AS. Both the aggregate and the associated more specific routes 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
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".
<span class="grey">Huston Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3765">RFC 3765</a> NOPEER April 2004</span>
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.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. IANA Considerations</span>
The IANA has registered NOPEER as a well-known community, as defined
in [<a href="#ref-1" title=""BGP Communities Attribute"">1</a>], 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
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
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
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
<span class="grey">Huston Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3765">RFC 3765</a> NOPEER April 2004</span>
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.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. References</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Normative References</span>
[<a id="ref-1">1</a>] Chandrasekeran, R., Traina, P. and T. Li, "BGP Communities
Attribute", <a href="./rfc1997">RFC 1997</a>, August 1996.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Informative References</span>
[<a id="ref-2">2</a>] Huston, G., "Commentary on Inter-Domain Routing in the Internet",
<a href="./rfc3221">RFC 3221</a>, December 2001.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Author's Address</span>
Geoff Huston
Telstra
EMail: gih@telstra.net
<span class="grey">Huston Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc3765">RFC 3765</a> NOPEER April 2004</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Full Copyright Statement</span>
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> 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 <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
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
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
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.
Huston Informational [Page 7]
</pre>
|
