draft-ietf-ptomaine-nopeer-01.txt   draft-ietf-ptomaine-nopeer-02.txt 
Internet Engineering Task Force Geoff Huston Internet Engineering Task Force Geoff Huston
Internet Draft Telstra Internet Draft Telstra
Document: draft-ietf-ptomaine-nopeer-01.txt February 2003 Document: draft-ietf-ptomaine-nopeer-02.txt February 2003
Status: proposed as Informational Expires: August 2003 Status: proposed as Informational Expires: August 2003
NOPEER community for BGP route scope control NOPEER community for BGP route scope control
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1]. all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 1, line 34 skipping to change at page 1, line 34
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Comments on this draft should be directed to gih@telstra.net. Comments on this draft should be directed to gih@telstra.net.
Abstract Abstract
This document proposes the use of a scope control BGP community. This document describes the use of a scope control BGP community.
This proposed well-known advisory transitive community is intended This well-known advisory transitive community allows an origin AS to
to allow an origin AS to specify the extent to which a specific specify the extent to which a specific route should be externally
route should be externally propagated. In particular this community, propagated. In particular this community, NOPEER, allows an origin
termed here as NOPEER, allows an origin AS to specify that a route AS to specify that a route with this attribute need not be
with this attribute need not be advertised across bilateral peer advertised across bilateral peer connections.
connections.
1. Introduction 1. Introduction
BGP today has a limited number of commonly defined mechanisms that BGP today has a limited number of commonly defined mechanisms that
allow a route to be propagated across some subset of the routing allow a route to be propagated across some subset of the routing
system. The NOEXPORT community allows a BGP speaker to specify that system. The NOEXPORT community allows a BGP speaker to specify that
redistribution should extend only to the neighbouring AS. Providers redistribution should extend only to the neighbouring AS. Providers
commonly define a number of communities that allow their neighbours commonly define a number of communities that allow their neighbours
to specify how advertised routes should be re-advertised. Current to specify how advertised routes should be re-advertised. Current
operational practice is that such communities are defined on as AS operational practice is that such communities are defined on as AS
skipping to change at page 2, line 22 skipping to change at page 2, line 21
on a number of forms, including as AS transit hop count, a set of 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 target ASs, the presence of a particular route object, or a
particular characteristic of the inter-AS connection. particular characteristic of the inter-AS connection.
There are a number of motivations for controlling the scope of There are a number of motivations for controlling the scope of
advertisement of route prefixes, including support of limited advertisement of route prefixes, including support of limited
transit services where advertisements are restricted to certain transit services where advertisements are restricted to certain
transit providers, and various forms of selective transit in a transit providers, and various forms of selective transit in a
multi-homed environment. multi-homed environment.
This proposal does not attempt to address all such motivations of This memo does not attempt to address all such motivations of scope
scope control, and addresses in particular the situation of both control, and addresses in particular the situation of both multi-
multi-homing and traffic engineering. The commonly adopted homing and traffic engineering. The commonly adopted operational
operational technique is that the originating AS advertises an technique is that the originating AS advertises an encompassing
encompassing aggregate route to all multi-home neighbours, and also aggregate route to all multi-home neighbours, and also selectively
selectively advertises a collection of more specific routes. This advertises a collection of more specific routes. This implements a
implements a form of destination-based traffic engineering with some form of destination-based traffic engineering with some level of
level of fail over protection. The more specific routes typically fail over protection. The more specific routes typically cease to
cease to lever any useful traffic engineering outcome beyond a lever any useful traffic engineering outcome beyond a certain radius
certain radius of redistribution, and a means of advising that such of redistribution, and a means of advising that such routes need not
routes need not to be distributed beyond such a point is of some to be distributed beyond such a point is of some value in moderating
value in moderating one of the factors of continued route table one of the factors of continued route table growth.
growth.
Analysis of the BGP routing tables reveals a significant use of the Analysis of the BGP routing tables reveals a significant use of the
technique of advertising more specific prefixes in addition to technique of advertising more specific prefixes in addition to
advertising a covering aggregate. In an effort to ameliorate some of advertising a covering aggregate. In an effort to ameliorate some of
the effects of this practice, in terms of overall growth of the BGP the effects of this practice, in terms of overall growth of the BGP
routing tables in the Internet and the associated burden of global routing tables in the Internet and the associated burden of global
propagation of dynamic changes in the reachability of such more propagation of dynamic changes in the reachability of such more
specific address prefixes, this draft proposes the use of a specific address prefixes, this memo describes the use of a
transitive BGP route attribute that is intended to allow more transitive BGP route attribute that allows more specific route
specific route tables entries to be discarded from the BGP tables tables entries to be discarded from the BGP tables under appropriate
under appropriate conditions. Specifically, this attribute, NOPEER, conditions. Specifically, this attribute, NOPEER, allows a remote AS
allows a remote AS not to advertise a route object to a neighbour AS not to advertise a route object to a neighbour AS when the two AS's
when the two AS's are interconnected under the conditions of some are interconnected under the conditions of some form of sender keep
form of sender keep all arrangement, as distinct from some form of all arrangement, as distinct from some form of provider / customer
provider / customer arrangement. arrangement.
2. Proposal 2. NOPEER Attribute
The proposal is to define a new well-known bgp transitive community,
This memo defines the use a new well-known bgp transitive community,
NOPEER. NOPEER.
The intended semantics of this attribute is to allow an AS to The semantics of this attribute is to allow an AS to interpret the
interpret the presence of this community as an advisory presence of this community as an advisory qualification to
qualification to re advertisement of a route prefix, permitting an readvertisement of a route prefix, permitting an AS not to
AS not to re advertise the route prefix to all external bilateral readvertise the route prefix to all external bilateral peer
peer neighbour AS's. It is consistent with the intended semantics neighbour AS's. It is consistent with these semantics that an AS may
that an AS may filter received prefixes that are received across a filter received prefixes that are received across a peering session
peering session that the receiver regards as a bilateral peer that the receiver regards as a bilateral peer sessions.
sessions.
3. Motivation 3. Motivation
The size of the BGP routing table has been increasing at an The size of the BGP routing table has been increasing at an
accelerating rate since late 1998. At the time of writing (April accelerating rate since late 1998. At the time of publication of
2002) the BGP forwarding table contains over 100,000 entries, and this memo (February 2003) the BGP forwarding table contains over
the three year growth rate of this table shows a trend rate which 118,000 entries, and the three year growth rate of this table shows
can be correlated to a compound growth rate of no less than 40% per a trend rate which can be correlated to a compound growth rate of no
year [2]. less than 10% per year [2].
One of the aspects of the current BGP routing table is the One of the aspects of the current BGP routing table is the
widespread use of the technique of advertising both an aggregate and widespread use of the technique of advertising both an aggregate and
a number of more specific address prefixes. For example, the table 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 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 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 this example the specific routes fully cover the aggregate
announcement. Sparse coverage of aggregates with more specifics is announcement. Sparse coverage of aggregates with more specifics is
also observed, where, for example, routing entries for 10.0.0.0/8 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 and 10.0.1.0/24 both exist in the routing table. In total, these
more specific route entries occupy some 52% of the routing table[3], more specific route entries occupy some 51% of the routing table[3],
so that more than one half of the routing table does not add so that more than one half of the routing table does not add
additional address reachability information into the routing system, additional address reachability information into the routing system,
but instead is used to impose a finer level of detail on existing but instead is used to impose a finer level of detail on existing
reachability information. reachability information.
There are a number of motivations for having both an aggregate route There are a number of motivations for having both an aggregate route
and a number of more specific routes in the routing table, including and a number of more specific routes in the routing table, including
various forms of multi-homed configurations, where there is a various forms of multi-homed configurations, where there is a
requirement to specify a different reachability policy for a part of requirement to specify a different reachability policy for a part of
the advertised address space. the advertised address space.
skipping to change at page 4, line 31 skipping to change at page 4, line 29
the scope where there is any outcomes in terms of traffic the scope where there is any outcomes in terms of traffic
differentiation. differentiation.
To the extent that remote analysis of BGP tables can observe this To the extent that remote analysis of BGP tables can observe this
form of configuration, the number of entries in the BGP forwarding form of configuration, the number of entries in the BGP forwarding
table where more specific entries share a common origin AS with table where more specific entries share a common origin AS with
their immediately enclosing aggregates comprise some 20% of the their immediately enclosing aggregates comprise some 20% of the
total number of FIB entries. Using a slightly stricter criteria total number of FIB entries. Using a slightly stricter criteria
where the AS path of the more specific route matches the immediately where the AS path of the more specific route matches the immediately
enclosing aggregate, the number of more specific routes comprises enclosing aggregate, the number of more specific routes comprises
some 13% of the number of FIB entries [3]. some 14% of the number of FIB entries [3].
One protocol mechanism that could be useful in this context is to One protocol mechanism that could be useful in this context is to
allow the originator of an advertisement to state some additional allow the originator of an advertisement to state some additional
qualification on the redistribution of the advertisement, allowing a qualification on the redistribution of the advertisement, allowing a
remote AS to suppress further redistribution under some originator- remote AS to suppress further redistribution under some originator-
specified criteria. specified criteria.
The redistribution qualification condition can be specified either The redistribution qualification condition can be specified either
by enumeration or by classification. Enumeration would encompass the by enumeration or by classification. Enumeration would encompass the
use of a well-known transitive extended community to specify a list use of a well-known transitive extended community to specify a list
of remote AS's where further redistribution is not advised. The of remote AS's where further redistribution is not advised. The
weakness of this approach is that the originating AS would need to weakness of this approach is that the originating AS would need to
constantly revise this enumerated AS list to reflect the changes in constantly revise this enumerated AS list to reflect the changes in
inter-AS topology, as, otherwise, the more specific routes would inter-AS topology, as, otherwise, the more specific routes would
leak beyond the intended redistribution scope. An approach of leak beyond the intended redistribution scope. An approach of
classification allows an originating AS to specify the conditions classification allows an originating AS to specify the conditions
where further redistribution is not advised without having to refer where further redistribution is not advised without having to refer
to the particular AS's where a match to such conditions are to the particular AS's where a match to such conditions are
anticipated. anticipated.
The approach proposed here to specifying the redistribution boundary The approach described here to specifying the redistribution
condition is one based on the type of bilateral inter-AS peering. boundary condition is one based on the type of bilateral inter-AS
Where one AS can be considered as a customer, and the other AS can peering. Where one AS can be considered as a customer, and the other
be considered as a contracted agent of the customer, or provider, AS can be considered as a contracted agent of the customer, or
then the relationship is one where the provider, as an agent of the provider, then the relationship is one where the provider, as an
customer, carries the routes and associated policy associated with agent of the customer, carries the routes and associated policy
the routes. Where neither AS can be considered as a customer of the associated with the routes. Where neither AS can be considered as a
other, then the relationship is one of bilateral peering, and customer of the other, then the relationship is one of bilateral
neither AS can be considered as an agent of the other in peering, and neither AS can be considered as an agent of the other
redistributing policies associated with routes. This latter in redistributing policies associated with routes. This latter
arrangement is commonly referred to as a "sender keep all peer" arrangement is commonly referred to as a "sender keep all peer"
relationship, or "peering". This peer boundary can be regarded as a relationship, or "peering". This peer boundary can be regarded as a
logical point where the redistribution of additional reachability logical point where the redistribution of additional reachability
policy imposed by the origin AS on a route is no longer an imposed policy imposed by the origin AS on a route is no longer an imposed
requirement. requirement.
This approach allows an originator of a prefix to attach a commonly This approach allows an originator of a prefix to attach a commonly
defined policy to a route prefix, indicate that a route should be defined policy to a route prefix, indicate that a route should be
re-advertised conditionally, based on the characteristics of the re-advertised conditionally, based on the characteristics of the
inter-AS connection. inter-AS connection.
4. IANA considerations 4. IANA considerations
Adoption of this proposal would imply the request to IANA for the The IANA should register NOPEER as a new BGP well-known transitive
registration of a new BGP well-known transitive community field from community field.
IANA.
5. Security considerations 5. Security considerations
BGP is an instance of a relaying protocol, where route information BGP is an instance of a relaying protocol, where route information
is received, processed and forwarded. BGP contains no specific is received, processed and forwarded. BGP contains no specific
mechanisms to prevent the unauthorized modification of the mechanisms to prevent the unauthorized modification of the
information by a forwarding agent, allowing routing information to information by a forwarding agent, allowing routing information to
be modified, deleted or false information to be inserted without the be modified, deleted or false information to be inserted without the
knowledge of the originator of the routing information or any of the knowledge of the originator of the routing information or any of the
recipients. recipients.
This proposed NOPEER community does not alter this overall situation The NOPEER community does not alter this overall situation
concerning the integrity of BGP as a routing system. concerning the integrity of BGP as a routing system.
This proposal has the capability to introduce additional attack Use of the NOPEER community has the capability to introduce
mechanisms into BGP by allowing the potential for denial of service additional attack mechanisms into BGP by allowing the potential for
attacks for an address prefix range being launched by a remote AS. 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 Unauthorized addition of this community to a route prefix by a
transit provider where there is no covering aggregate route prefix transit provider where there is no covering aggregate route prefix
may cause a denial of service attack based on denial of reachability 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, 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 if the more specific route has a different origin AS than the
aggregate, the addition of this community by a transit AS may cause 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 a denial of service attack on the origin AS of the more specific
prefix. prefix.
skipping to change at page 7, line 10 skipping to change at page 7, line 10
community to limit the redistribution of a false route entry such community to limit the redistribution of a false route entry such
that its visibility can be limited and detection and rectification that its visibility can be limited and detection and rectification
of the problem can be more difficult under the circumstances of of the problem can be more difficult under the circumstances of
limited redistribution. limited redistribution.
References References
[1] "The Internet Standards Process -- Revision 3", S. Bradner, RFC [1] "The Internet Standards Process -- Revision 3", S. Bradner, RFC
2026, October 1996. 2026, October 1996.
[2] "Commentary in Inter-Domain Routing in the Internet", G. [2] "Commentary in Inter-Domain Routing in the Internet", G. Huston,
Huston, RFC 3221, December 2001. RFC 3221, December 2001.
[3] Analysis of BGP table data - http://bgp.potaroo.net [3] Analysis of BGP table data - http://bgp.potaroo.net
Author's Address Author's Address
Geoff Huston Geoff Huston
Telstra Telstra
Email: gih@telstra.net Email: gih@telstra.net
 End of changes. 14 change blocks. 
65 lines changed or deleted 63 lines changed or added

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