draft-ietf-idr-bgp-analysis-07.txt | rfc4274.txt | |||
---|---|---|---|---|
INTERNET-DRAFT D. Meyer | Network Working Group D. Meyer | |||
draft-ietf-idr-bgp-analysis-07.txt K. Patel | Request for Comments: 4274 K. Patel | |||
Category Informational | Category: Informational Cisco Systems | |||
Expires: June 2005 December 2004 | January 2006 | |||
BGP-4 Protocol Analysis | BGP-4 Protocol Analysis | |||
<draft-ietf-idr-bgp-analysis-07.txt> | ||||
Status of this Memo | ||||
Status of this Memo | Status of This Memo | |||
This document is an Internet-Draft and is subject to all | ||||
provisions of section 3 of RFC 3667. By submitting this | ||||
Internet-Draft, each author represents that any applicable patent | ||||
or other IPR claims of which he or she is aware have been or will | ||||
be disclosed, and any of which he or she become aware will be | ||||
disclosed, in accordance with RFC 3668. | ||||
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/1id-abstracts.txt. | ||||
The list of Internet-Draft Shadow Directories can be accessed | ||||
at http://www.ietf.org/shadow.html. | ||||
This document is a product of the IDR Working Group | This memo provides information for the Internet community. It does | |||
WG. Comments should be addressed to the authors, or the | not specify an Internet standard of any kind. Distribution of this | |||
mailing list at idr@ietf.org. | memo is unlimited. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2004). All Rights Reserved. | Copyright (C) The Internet Society (2006). | |||
Abstract | Abstract | |||
The purpose of this report is to document how the requirements for | The purpose of this report is to document how the requirements for | |||
advancing a routing protocol from Draft Standard to full Standard | publication of a routing protocol as an Internet Draft Standard have | |||
have been satisfied by Border Gateway Protocol version 4 (BGP-4). | been satisfied by Border Gateway Protocol version 4 (BGP-4). | |||
This report satisfies the requirement for "the second report", as | This report satisfies the requirement for "the second report", as | |||
described in Section 6.0 of [RFC1264]. In order to fulfill the | described in Section 6.0 of RFC 1264. In order to fulfill the | |||
requirement, this report augments [RFC1774] and summarizes the key | requirement, this report augments RFC 1774 and summarizes the key | |||
features of BGP-4 protocol, and analyzes the protocol with respect | features of BGP-4, as well as analyzes the protocol with respect to | |||
to scaling and performance. | scaling and performance. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction ....................................................2 | |||
2. Key Features and algorithms of the BGP protocol. . . . . . . . 4 | 2. Key Features and Algorithms of BGP ..............................3 | |||
2.1. Key Features. . . . . . . . . . . . . . . . . . . . . . . . 4 | 2.1. Key Features ...............................................3 | |||
2.2. BGP Algorithms. . . . . . . . . . . . . . . . . . . . . . . 5 | 2.2. BGP Algorithms .............................................4 | |||
2.3. BGP Finite State Machine (FSM). . . . . . . . . . . . . . . 6 | 2.3. BGP Finite State Machine (FSM) .............................4 | |||
3. BGP Capabilities . . . . . . . . . . . . . . . . . . . . . . . 7 | 3. BGP Capabilities ................................................5 | |||
4. BGP Persistent Peer Oscillations . . . . . . . . . . . . . . . 7 | 4. BGP Persistent Peer Oscillations ................................6 | |||
5. Implementation Guidelines. . . . . . . . . . . . . . . . . . . 7 | 5. Implementation Guidelines .......................................6 | |||
6. BGP Performance characteristics and Scalability. . . . . . . . 8 | 6. BGP Performance Characteristics and Scalability .................6 | |||
6.1. Link bandwidth and CPU utilization. . . . . . . . . . . . . 8 | 6.1. Link Bandwidth and CPU Utilization .........................7 | |||
6.1.1. CPU utilization. . . . . . . . . . . . . . . . . . . . . 9 | 7. BGP Policy Expressiveness and its Implications ..................9 | |||
6.1.2. Memory requirements. . . . . . . . . . . . . . . . . . . 10 | 7.1. Existence of Unique Stable Routings .......................10 | |||
7. BGP Policy Expressiveness and its Implications . . . . . . . . 11 | 7.2. Existence of Stable Routings ..............................11 | |||
7.1. Existence of Unique Stable Routings . . . . . . . . . . . . 12 | 8. Applicability ..................................................12 | |||
7.2. Existence of Stable Routings. . . . . . . . . . . . . . . . 13 | 9. Acknowledgements ...............................................12 | |||
8. Applicability. . . . . . . . . . . . . . . . . . . . . . . . . 14 | 10. Security Considerations .......................................12 | |||
9. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 15 | 11. References ....................................................13 | |||
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 | 11.1. Normative References ....................................13 | |||
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 | 11.2. Informative References ..................................14 | |||
12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 17 | ||||
12.1. Normative References . . . . . . . . . . . . . . . . . . . 17 | ||||
12.2. Informative References . . . . . . . . . . . . . . . . . . 18 | ||||
13. Author's Addresses. . . . . . . . . . . . . . . . . . . . . . 19 | ||||
1. Introduction | 1. Introduction | |||
BGP-4 is an inter-autonomous system routing protocol designed for | BGP-4 is an inter-autonomous system routing protocol designed for | |||
TCP/IP internets. Version 1 of the BGP-4 protocol was published in | TCP/IP internets. Version 1 of BGP-4 was published in [RFC1105]. | |||
[RFC1105]. Since then BGP versions 2, 3, and 4 have been developed. | Since then, BGP versions 2, 3, and 4 have been developed. Version 2 | |||
Version 2 was documented in [RFC1163]. Version 3 is documented in | was documented in [RFC1163]. Version 3 is documented in [RFC1267]. | |||
[RFC1267]. Version 4 is documented in the [BGP4] (version 4 of BGP | Version 4 is documented in [BGP4] (version 4 of BGP will hereafter be | |||
will hereafter be referred to as BGP). The changes between versions | referred to as BGP). The changes between versions are explained in | |||
are explained in Appendix A of [BGP4]. Possible applications of BGP | Appendix A of [BGP4]. Possible applications of BGP in the Internet | |||
in the Internet are documented in [RFC1772]. | are documented in [RFC1772]. | |||
BGP introduced support for Classless Inter-Domain Routing | BGP introduced support for Classless Inter-Domain Routing (CIDR) | |||
[RFC1519]. Since earlier versions of BGP lacked the support | [RFC1519]. Because earlier versions of BGP lacked the support for | |||
for CIDR, they are considered obsolete and unusable in | CIDR, they are considered obsolete and unusable in today's Internet. | |||
today's Internet. | ||||
2. Key Features and algorithms of the BGP protocol | The purpose of this report is to document how the requirements for | |||
publication of a routing protocol as an Internet Draft Standard have | ||||
been satisfied by Border Gateway Protocol version 4 (BGP-4). | ||||
This section summarizes the key features and algorithms of the | This report satisfies the requirement for "the second report", as | |||
BGP protocol. BGP is an inter-autonomous system routing | described in Section 6.0 of [RFC1264]. In order to fulfill the | |||
protocol; it is designed to be used between multiple | requirement, this report augments [RFC1774] and summarizes the key | |||
autonomous systems. BGP assumes that routing within an | features of BGP-4, as well as analyzes the protocol with respect to | |||
autonomous system is done by an intra-autonomous system | scaling and performance. | |||
routing protocol. BGP also assumes that data packets are | ||||
routed from source towards destination independent of the | ||||
source. BGP does not make any assumptions about | ||||
intra-autonomous system routing protocols deployed within the | ||||
various autonomous systems. Specifically, BGP does not require | ||||
all autonomous systems to run the same intra-autonomous system | ||||
routing protocol (i.e., interior gateway protocol or IGP). | ||||
Finally, note that BGP is a real inter-autonomous system | 2. Key Features and Algorithms of BGP | |||
routing protocol, and as such it imposes no constraints on the | ||||
underlying interconnect topology of the autonomous | This section summarizes the key features and algorithms of BGP. BGP | |||
systems. The information exchanged via BGP is sufficient to | is an inter-autonomous system routing protocol; it is designed to be | |||
construct a graph of autonomous systems connectivity from | used between multiple autonomous systems. BGP assumes that routing | |||
which routing loops may be pruned and many routing policy | within an autonomous system is done by an intra-autonomous system | |||
decisions at the autonomous system level may be enforced. | routing protocol. BGP also assumes that data packets are routed from | |||
source towards destination independent of the source. BGP does not | ||||
make any assumptions about intra-autonomous system routing protocols | ||||
deployed within the various autonomous systems. Specifically, BGP | ||||
does not require all autonomous systems to run the same intra- | ||||
autonomous system routing protocol (i.e., interior gateway protocol | ||||
or IGP). | ||||
Finally, note that BGP is a real inter-autonomous system routing | ||||
protocol; and, as such, it imposes no constraints on the underlying | ||||
interconnect topology of the autonomous systems. The information | ||||
exchanged via BGP is sufficient to construct a graph of autonomous | ||||
systems connectivity from which routing loops may be pruned, and many | ||||
routing policy decisions at the autonomous system level may be | ||||
enforced. | ||||
2.1. Key Features | 2.1. Key Features | |||
The key features of the protocol are the notion of path | The key features of the protocol are the notion of path attributes | |||
attributes and aggregation of Network Layer Reachability | and aggregation of Network Layer Reachability Information (NLRI). | |||
Information (NLRI). | ||||
Path attributes provide BGP with flexibility and | Path attributes provide BGP with flexibility and extensibility. Path | |||
extensibility. Path attributes are partitioned into well-known | attributes are either well-known or optional. The provision for | |||
and optional. The provision for optional attributes allows | optional attributes allows experimentation that may involve a group | |||
experimentation that may involve a group of BGP routers | of BGP routers without affecting the rest of the Internet. New | |||
without affecting the rest of the Internet. New optional | optional attributes can be added to the protocol in much the same way | |||
attributes can be added to the protocol in much the same way | that new options are added to, for example, the Telnet protocol | |||
that new options are added to, say, the Telnet protocol [RFC854]. | [RFC854]. | |||
One of the most important path attributes is the Autonomous | One of the most important path attributes is the Autonomous System | |||
System Path, or AS_PATH. As the reachability information | Path, or AS_PATH. As the reachability information traverses the | |||
traverses the Internet, this (AS_PATH) information is | Internet, this (AS_PATH) information is augmented by the list of | |||
augmented by the list of autonomous systems that have been | autonomous systems that have been traversed thus far, forming the | |||
traversed thus far, forming the AS_PATH. The AS_PATH allows | AS_PATH. The AS_PATH allows straightforward suppression of the | |||
straightforward suppression of the looping of routing | looping of routing information. In addition, the AS_PATH serves as a | |||
information. In addition, the AS_PATH serves as a powerful and | powerful and versatile mechanism for policy-based routing. | |||
versatile mechanism for policy-based routing. | ||||
BGP enhances the AS_PATH attribute to include sets of autonomous | BGP enhances the AS_PATH attribute to include sets of autonomous | |||
systems as well as lists via the AS_SET attribute. This extended | systems as well as lists via the AS_SET attribute. This extended | |||
format allows generated aggregate routes to carry path information | format allows generated aggregate routes to carry path information | |||
from the more specific routes used to generate the aggregate. It | from the more specific routes used to generate the aggregate. It | |||
should be noted however, that as of this writing, AS_SETs are | should be noted, however, that as of this writing, AS_SETs are rarely | |||
rarely used in the Internet [ROUTEVIEWS]. | used in the Internet [ROUTEVIEWS]. | |||
2.2. BGP Algorithms | 2.2. BGP Algorithms | |||
BGP uses an algorithm that is neither a pure distance vector | BGP uses an algorithm that is neither a pure distance vector | |||
algorithm or a pure link state algorithm. It is instead a | algorithm or a pure link state algorithm. Instead, it uses a | |||
modified distance vector algorithm referred to as a "Path | modified distance vector algorithm, referred to as a "Path Vector" | |||
Vector" algorithm that uses path information to avoid | algorithm. This algorithm uses path information to avoid traditional | |||
traditional distance vector problems. Each route within BGP | distance vector problems. Each route within BGP pairs information | |||
pairs destination with path information to that | about the destination with path information to that destination. | |||
destination. Path information (also known as AS_PATH | Path information (also known as AS_PATH information) is stored within | |||
information) is stored within the AS_PATH attribute in | the AS_PATH attribute in BGP. The path information assists BGP in | |||
BGP. The path information assists BGP in detecting AS loops | detecting AS loops, thereby allowing BGP speakers to select loop-free | |||
thereby allowing BGP speakers select loop free routes. | routes. | |||
BGP uses an incremental update strategy in order to conserve | BGP uses an incremental update strategy to conserve bandwidth and | |||
bandwidth and processing power. That is, after initial | processing power. That is, after initial exchange of complete | |||
exchange of complete routing information, a pair of BGP | routing information, a pair of BGP routers exchanges only the changes | |||
routers exchanges only changes to that information. Such an | to that information. Such an incremental update design requires | |||
incremental update design requires reliable transport between | reliable transport between a pair of BGP routers in order to function | |||
a pair of BGP routers to function correctly. BGP solves this | correctly. BGP solves this problem by using TCP for reliable | |||
problem by using TCP for reliable transport. | transport. | |||
In addition to incremental updates, BGP has added the concept | In addition to incremental updates, BGP has added the concept of | |||
of route aggregation so that information about groups of | route aggregation so that information about groups of destinations | |||
destinations | ||||
that use hierarchical address assignment (e.g., CIDR) may be | that use hierarchical address assignment (e.g., CIDR) may be | |||
aggregated and sent as a single Network Layer Reachability | aggregated and sent as a single Network Layer Reachability (NLRI). | |||
(NLRI). | ||||
Finally, note that BGP is a self-contained protocol. That is, | Finally, note that BGP is a self-contained protocol. That is, BGP | |||
BGP specifies how routing information is exchanged both | specifies how routing information is exchanged, both between BGP | |||
between BGP speakers in different autonomous systems, and | speakers in different autonomous systems, and between BGP speakers | |||
between BGP speakers within a single autonomous system. | within a single autonomous system. | |||
2.3. BGP Finite State Machine (FSM) | 2.3. BGP Finite State Machine (FSM) | |||
The BGP FSM is a set of rules that are applied to a BGP | The BGP FSM is a set of rules that is applied to a BGP speaker's set | |||
speaker's set of configured peers for the BGP operation. A BGP | of configured peers for the BGP operation. A BGP implementation | |||
implementation requires that a BGP speaker must connect to and | requires that a BGP speaker must connect to and listen on TCP port | |||
listen on TCP port 179 for accepting any new BGP connections | 179 for accepting any new BGP connections from its peers. The BGP | |||
from its peers. The BGP Finite State Machine, or FSM, must be | Finite State Machine, or FSM, must be initiated and maintained for | |||
initiated and maintained for each new incoming and outgoing | each new incoming and outgoing peer connection. However, in steady | |||
peer connections. However, in steady state operation, there | state operation, there will be only one BGP FSM per connection per | |||
will be only one BGP FSM per connection per peer. | peer. | |||
There may be a short period during which a BGP peer may have | There may be a short period during which a BGP peer may have separate | |||
separate incoming and outgoing connections resulting in the | incoming and outgoing connections resulting in the creation of two | |||
creation of two different BGP FSMs relating to a peer (instead | different BGP FSMs relating to a peer (instead of one). This can be | |||
of one). This can be resolved by following the BGP connection | resolved by following the BGP connection collision rules defined in | |||
collision rules defined in the [BGP4] specification. | the [BGP4] specification. | |||
The BGP FSM has the following states associated with each of its | The BGP FSM has the following states associated with each of its | |||
peers: | peers: | |||
IDLE: State when BGP peer refuses any incoming | IDLE: State when BGP peer refuses any incoming connections. | |||
connections. | ||||
CONNECT: State in which BGP peer is waiting for | CONNECT: State in which BGP peer is waiting for its TCP | |||
its TCP connection to be completed. | connection to be completed. | |||
ACTIVE: State in which BGP peer is trying to acquire a | ACTIVE: State in which BGP peer is trying to acquire a peer | |||
peer by listening and accepting TCP connection. | by listening and accepting TCP connection. | |||
OPENSENT: BGP peer is waiting for OPEN message from its | OPENSENT: BGP peer is waiting for OPEN message from its peer. | |||
peer. | ||||
OPENCONFIRM: BGP peer is waiting for KEEPALIVE or NOTIFICATION | OPENCONFIRM: BGP peer is waiting for KEEPALIVE or NOTIFICATION | |||
message from its peer. | message from its peer. | |||
ESTABLISHED: BGP peer connection is established and exchanges | ESTABLISHED: BGP peer connection is established and exchanges | |||
UPDATE, NOTIFICATION, and KEEPALIVE messages with | UPDATE, NOTIFICATION, and KEEPALIVE messages with its | |||
its peer. | peer. | |||
There are an number of BGP events that operate on above | There are a number of BGP events that operate on the above mentioned | |||
mentioned states of the BGP FSM for BGP peers. Support of | states of the BGP FSM for BGP peers. Support of these BGP events is | |||
these BGP events are either mandatory or optional. They are | either mandatory or optional. These events are triggered by the | |||
triggered by the protocol logic as part of the BGP or using an | protocol logic as part of the BGP or by using an operator | |||
operator intervention via a configuration interface to the BGP | intervention via a configuration interface to the BGP protocol. | |||
protocol. | ||||
These BGP events are of following types: Optional events | These BGP events are of following types: Optional events linked to | |||
linked to Optional Session attributes, Administrative Events, | Optional Session attributes, Administrative Events, Timer Events, TCP | |||
Timer Events, TCP Connection based Events, and BGP | Connection-based Events, and BGP Message-based Events. Both the FSM | |||
Message-based Events. Both the FSM and the BGP events are | and the BGP events are explained in detail in [BGP4]. | |||
explained in detail in [BGP4]. | ||||
3. BGP Capabilities | 3. BGP Capabilities | |||
The BGP Capability mechanism [RFC2842] provides an easy and flexible | The BGP capability mechanism [RFC3392] provides an easy and flexible | |||
way to introduce new features within the protocol. In particular, the | way to introduce new features within the protocol. In particular, | |||
BGP capability mechanism allows a BGP speaker to advertise to its | the BGP capability mechanism allows a BGP speaker to advertise to its | |||
peers during startup various optional features supported by the | peers during startup various optional features supported by the | |||
speaker (and receive similar information from the peers). This allows | speaker (and receive similar information from the peers). This | |||
the base BGP protocol to contain only essential functionality, while | allows the base BGP to contain only essential functionality, while | |||
at the same time providing a flexible mechanism for signaling | providing a flexible mechanism for signaling protocol extensions. | |||
protocol extensions. | ||||
4. BGP Persistent Peer Oscillations | 4. BGP Persistent Peer Oscillations | |||
Whenever a BGP speaker detects an error in any peer connection, it | Whenever a BGP speaker detects an error in a peer connection, it | |||
shuts down the peer and changes its FSM state to IDLE. BGP speaker | shuts down the peer and changes its FSM state to IDLE. BGP speaker | |||
requires a Start event to re-initiate its idle peer connection. If | requires a Start event to re-initiate an idle peer connection. If | |||
the error remains persistent and BGP speaker generates Start event | the error remains persistent and BGP speaker generates a Start event | |||
automatically then it may result in persistent peer flapping. | automatically, then it may result in persistent peer flapping. | |||
However, although peer oscillation is found to be wide-spread in BGP | Although peer oscillation is found to be wide-spread in BGP | |||
implementations, methods for preventing persistent peer oscillations | implementations, methods for preventing persistent peer oscillations | |||
are outside the scope of base BGP protocol specification. | are outside the scope of base BGP specification. | |||
5. Implementation Guidelines | 5. Implementation Guidelines | |||
A robust BGP implementation is work conserving. This means that if | A robust BGP implementation is "work conserving". This means that if | |||
the number of prefixes is bounded, arbitrarily high levels of route | the number of prefixes is bounded, arbitrarily high levels of route | |||
change can be tolerated with bounded impact on route convergence for | change can be tolerated. High levels can be tolerated with bounded | |||
occasional changes in generally stable routes. | impact on route convergence for occasional changes in generally | |||
stable routes. | ||||
A robust implementation of BGP should have the following | A robust implementation of BGP should have the following | |||
characteristics: | characteristics: | |||
1. It is able to operate in almost arbitrarily high levels | ||||
of route flap without losing peerings (failing to send | ||||
keepalives) or loosing other protocol adjacencies as a | ||||
result of BGP load. | ||||
2. Instability of a subset of routes should not affect the | 1. It is able to operate in almost arbitrarily high levels of | |||
route advertisements or forwarding associated with the set | route flap without losing peerings (failing to send | |||
of stable routes. | keepalives) or losing other protocol adjacencies as a result | |||
of BGP load. | ||||
3. High levels of instability and peers of different CPU speed | 2. Instability of a subset of routes should not affect the route | |||
or load resulting in faster or slower processing of routes | advertisements or forwarding associated with the set of stable | |||
should not cause instability and should have a bounded | routes. | |||
impact on the convergence time for generally stable routes. | ||||
3. Instability should not be caused by peers with high levels of | ||||
instability or with different CPU speed or load that result in | ||||
faster or slower processing of routes. These instable peers | ||||
should have a bounded impact on the convergence time for | ||||
generally stable routes. | ||||
Numerous robust BGP implementations exist. Producing a robust | Numerous robust BGP implementations exist. Producing a robust | |||
implementation is not a trivial matter but clearly achievable. | implementation is not a trivial matter, but is clearly achievable. | |||
6. BGP Performance characteristics and Scalability | 6. BGP Performance Characteristics and Scalability | |||
In this section, we provide "order of magnitude" answers to the | In this section, we provide "order of magnitude" answers to the | |||
questions of how much link bandwidth, router memory and router CPU | questions of how much link bandwidth, router memory and router CPU | |||
cycles the BGP protocol will consume under normal conditions. In | cycles BGP will consume under normal conditions. In particular, we | |||
particular, we will address the scalability of BGP and its | will address the scalability of BGP and its limitations. | |||
limitations. | ||||
6.1. Link bandwidth and CPU utilization | 6.1. Link Bandwidth and CPU Utilization | |||
Immediately after the initial BGP connection setup, BGP peers | Immediately after the initial BGP connection setup, BGP peers | |||
exchange complete set of routing information. If we denote the total | exchange complete sets of routing information. If we denote the | |||
number of routes in the Internet by N, the total path attributes (for | total number of routes in the Internet as N, the total path | |||
all N routes) received from a peer as A, and assume that the networks | attributes (for all N routes) received from a peer as A, and assume | |||
are uniformly distributed among the autonomous systems, then the | that the networks are uniformly distributed among the autonomous | |||
worst case amount of bandwidth consumed during the initial exchange | systems, then the worst-case amount of bandwidth consumed during the | |||
between a pair of BGP speakers (P) is | initial exchange between a pair of BGP speakers (P) is | |||
BW = O((N + A) * P) | BW = O((N + A) * P) | |||
BGP-4 was created specifically to reduce the size of the set | BGP-4 was created specifically to reduce the size of the set of NLRI | |||
of NLRI entries which have to be carried and exchanged by | entries, which has to be carried and exchanged by border routers. | |||
border routers. The aggregation scheme, defined in [RFC1519], | The aggregation scheme, defined in [RFC1519], describes the | |||
describes the provider-based aggregation scheme in use in | provider-based aggregation scheme in use in today's Internet. | |||
today's Internet. | ||||
Due to the advantages of advertising a few large aggregate blocks | Due to the advantages of advertising a few large aggregate blocks | |||
instead of many smaller class-based individual networks, it is | (instead of many smaller class-based individual networks), it is | |||
difficult to estimate the actual reduction in bandwidth and | difficult to estimate the actual reduction in bandwidth and | |||
processing that BGP-4 has provided over BGP-3. If we simply | processing that BGP-4 has provided over BGP-3. If we simply | |||
enumerate all aggregate blocks into their individual class-based | enumerate all aggregate blocks into their individual, class-based | |||
networks, we would not take into account "dead" space that has been | networks, we would not take into account "dead" space that has been | |||
reserved for future expansion. The best metric for determining the | reserved for future expansion. The best metric for determining the | |||
success of BGP's aggregation is to sample the number NLRI entries in | success of BGP's aggregation is to sample the number NLRI entries in | |||
the globally connected Internet today and compare it to projected | the globally-connected Internet today, and compare it to growth rates | |||
growth rates before BGP was deployed. | that were projected before BGP was deployed. | |||
At the time of this writing, the full set of exterior routes carried | At the time of this writing, the full set of exterior routes carried | |||
by BGP is approximately 134,000 network entries [ROUTEVIEWS]. | by BGP is approximately 134,000 network entries [ROUTEVIEWS]. | |||
6.1.1. CPU utilization | 6.1.1. CPU Utilization | |||
An important and fundamental feature of BGP is that BGP's CPU | An important and fundamental feature of BGP is that BGP's CPU | |||
utilization depends only on the stability of its network which | utilization depends only on the stability of its network which | |||
relates to BGP in terms of BGP UPDATE message announcements. If the | relates to BGP in terms of BGP UPDATE message announcements. If the | |||
BGP network is stable: all the BGP routers within its network are in | BGP network is stable, all the BGP routers within its network are in | |||
the steady state; then the only link bandwidth and router CPU cycles | the steady state. Thus, the only link bandwidth and router CPU | |||
consumed by BGP are due to the exchange of the BGP KEEPALIVE | cycles consumed by BGP are due to the exchange of the BGP KEEPALIVE | |||
messages. The KEEPALIVE messages are exchanged only between peers. | messages. The KEEPALIVE messages are exchanged only between peers. | |||
The suggested frequency of the exchange is 30 seconds. The KEEPALIVE | The suggested frequency of the exchange is 30 seconds. The KEEPALIVE | |||
messages are quite short (19 octets), and require virtually no | messages are quite short (19 octets) and require virtually no | |||
processing. As a result, the bandwidth consumed by the KEEPALIVE | processing. As a result, the bandwidth consumed by the KEEPALIVE | |||
messages is about 5 bits/sec. Operational experience confirms that | messages is about 5 bits/sec. Operational experience confirms that | |||
the overhead (in terms of bandwidth and CPU) associated with the | the overhead (in terms of bandwidth and CPU) associated with the | |||
KEEPALIVE messages should be viewed as negligible. | KEEPALIVE messages should be viewed as negligible. | |||
During periods of network instability, BGP routers within the network | During periods of network instability, BGP routers within the network | |||
are generating routing updates that are exchanged using the BGP | are generating routing updates that are exchanged using the BGP | |||
UPDATE messages. The greatest overhead per UPDATE message occurs | UPDATE messages. The greatest overhead per UPDATE message occurs | |||
when each UPDATE message contains only a single network. It should be | when each UPDATE message contains only a single network. It should | |||
pointed out that in practice routing changes exhibit strong locality | be pointed out that, in practice, routing changes exhibit strong | |||
with respect to the route attributes. That is, routes that change | locality with respect to the route attributes. That is, routes that | |||
are likely to have common route attributes. In this case, multiple | change are likely to have common route attributes. In this case, | |||
networks can be grouped into a single UPDATE message, thus | multiple networks can be grouped into a single UPDATE message, thus | |||
significantly reducing the amount of bandwidth required (see also | significantly reducing the amount of bandwidth required (see also | |||
Appendix F.1 of [BGP4]). | Appendix F.1 of [BGP4]). | |||
6.1.2. Memory requirements | 6.1.2. Memory Requirements | |||
To quantify the worst case memory requirements for BGP, we denote the | To quantify the worst-case memory requirements for BGP, we denote the | |||
total number of networks in the Internet by N, the mean AS distance | total number of networks in the Internet as N, the mean AS distance | |||
of the Internet by M (distance at the level of an autonomous system, | of the Internet as M (distance at the level of an autonomous system, | |||
expressed in terms of the number of autonomous systems), the total | expressed in terms of the number of autonomous systems), the total | |||
number of unique AS paths as A. Then the worst case memory | number of unique AS paths as A. Then the worst-case memory | |||
requirements (MR) can be expressed as | requirements (MR) can be expressed as | |||
MR = O(N + (M * A)) | MR = O(N + (M * A)) | |||
Since a mean AS distance M is a slow moving function of the | Because a mean AS distance M is a slow moving function of the | |||
interconnectivity ("meshiness") of the Internet, for all practical | interconnectivity ("meshiness") of the Internet, for all practical | |||
purposes the worst case router memory requirements are on the order | purposes the worst-case router memory requirements are on the order | |||
of the total number of networks in the Internet times the number of | of the total number of networks in the Internet multiplied by the | |||
peers the local system is peering with. We expect that the total | number of peers that the local system is peering with. We expect | |||
number of networks in the Internet will grow much faster than the | that the total number of networks in the Internet will grow much | |||
average number of peers per router. As a result, BGP's memory | faster than the average number of peers per router. As a result, | |||
scaling properties are linearly related to the total number of | BGP's memory-scaling properties are linearly related to the total | |||
networks in the Internet. | number of networks in the Internet. | |||
The following table illustrates typical memory requirements of a | The following table illustrates typical memory requirements of a | |||
router running BGP. We denote average number of routes advertised by | router running BGP. We denote the average number of routes | |||
each peer as N, the total number of unique AS paths as A, the mean AS | advertised by each peer as N, the total number of unique AS paths as | |||
distance of the Internet as M (distance at the level of an autonomous | A, the mean AS distance of the Internet as M (distance at the level | |||
system, expressed in terms of the number of autonomous systems), | of an autonomous system, expressed in terms of the number of | |||
number of octets required to store a network as R, and number of | autonomous systems), the number of octets required to store a network | |||
bytes required to store one AS in an AS path as P. It is assumed | as R, and the number of bytes required to store one AS in an AS path | |||
that each network is encoded as four bytes, each AS is encoded as two | as P. It is assumed that each network is encoded as four bytes, each | |||
bytes, and each networks is reachable via some fraction of all of the | AS is encoded as two bytes, and each networks is reachable via some | |||
peers (# BGP peers/per net). For purposes of the estimates here, we | fraction of all the peers (# BGP peers/per net). For purposes of the | |||
will calculate MR = (((N * R) + (M * A) * P) * S). | estimates here, we will calculate MR = (((N * R) + (M * A) * P) * S). | |||
# Networks Mean AS Distance # AS's # BGP peers/per net Memory Req | # Networks Mean AS Distance # ASes # BGP peers/per net Memory Req | |||
(N) (M) (A) (P) (MR) | (N) (M) (A) (P) (MR) | |||
---------- ---------------- ------ ------------------- -------------- | ---------- ---------------- ------ ------------------- ------------- | |||
100,000 20 3,000 20 10,400,000 | 100,000 20 3,000 20 10,400,000 | |||
100,000 20 15,000 20 20,000,000 | 100,000 20 15,000 20 20,000,000 | |||
120,000 10 15,000 100 78,000,000 | 120,000 10 15,000 100 78,000,000 | |||
140,000 15 20,000 100 116,000,000 | 140,000 15 20,000 100 116,000,000 | |||
In analyzing BGP's memory requirements, we focus on the size of the | In analyzing BGP's memory requirements, we focus on the size of the | |||
BGP RIB table (ignoring implementation details). In particular, we | BGP RIB table (ignoring implementation details). In particular, we | |||
derive upper bounds for the size of the BGP RIB table. For example, | derive upper bounds for the size of the BGP RIB table. For example, | |||
at the time of this writing, the BGP RIB tables of a typical backbone | at the time of this writing, the BGP RIB tables of a typical backbone | |||
router carry on the order of 120,000 entries. Given this number, one | router carry on the order of 120,000 entries. Given this number, one | |||
might ask whether it would be possible to have a functional router | might ask whether it would be possible to have a functional router | |||
with a table that will have 1,000,000 entries. Clearly the answer to | with a table containing 1,000,000 entries. Clearly, the answer to | |||
this question is more related to how BGP is implemented. A robust BGP | this question is more related to how BGP is implemented. A robust | |||
implementation with a reasonable CPU and memory should not have | BGP implementation with a reasonable CPU and memory should not have | |||
issues scaling to such limits. | issues scaling to such limits. | |||
7. BGP Policy Expressiveness and its Implications | 7. BGP Policy Expressiveness and its Implications | |||
BGP is unique among deployed IP routing protocols in that routing is | BGP is unique among deployed IP routing protocols in that routing is | |||
determined using semantically rich routing policies. Although | determined using semantically rich routing policies. Although | |||
routing policies are usually the first thing that comes to a network | routing policies are usually the first BGP issue that comes to a | |||
operator's mind concerning BGP, it is important to note that the | network operator's mind, it is important to note that the languages | |||
languages and techniques for specifying BGP routing policies are not | and techniques for specifying BGP routing policies are not part of | |||
actually a part of the protocol specification ([RFC2622] for an | the protocol specification (see [RFC2622] for an example of such a | |||
example of such a policy language). In addition, the BGP | policy language). In addition, the BGP specification contains few | |||
specification contains few restrictions, either explicitly or | restrictions, explicit or implicit, on routing policy languages. | |||
implicitly, on routing policy languages. These languages have | These languages have typically been developed by vendors and have | |||
typically been developed by vendors and have evolved through | evolved through interactions with network engineers in an environment | |||
interactions with network engineers in an environment lacking | lacking vendor-independent standards. | |||
vendor-independent standards. | ||||
The complexity of typical BGP configurations, at least in provider | The complexity of typical BGP configurations, at least in provider | |||
networks, has been steadily increasing. Router vendors typically | networks, has been steadily increasing. Router vendors typically | |||
provide hundreds of special commands for use in the configuration of | provide hundreds of special commands for use in the configuration of | |||
BGP, and this command set is continually expanding. For example, BGP | BGP, and this command set is continually expanding. For example, BGP | |||
communities [RFC1997] allow policy writers to selectively attach tags | communities [RFC1997] allow policy writers to selectively attach tags | |||
to routes and use these to signal policy information to other | to routes and to use these to signal policy information to other | |||
BGP-speaking routers. Many providers allow customers, and | BGP-speaking routers. Many providers allow customers, and sometimes | |||
sometimes peers, to send communities that determine the scope | peers, to send communities that determine the scope and preference of | |||
and preference of their routes. These developments have | their routes. Due to these developments, the task of writing BGP | |||
increasingly given the task of writing BGP configurations | configurations has increasingly more aspects associated with open- | |||
aspects associated with open-ended programming. This has | ended programming. This has allowed network operators to encode | |||
allowed network operators to encode complex policies in order | complex policies in order to address many unforeseen situations, and | |||
to address many unforeseen situations, and has opened the door | has opened the door for a great deal of creativity and | |||
for a great deal of creativity and experimentation in routing | experimentation in routing policies. This policy flexibility is one | |||
policies. This policy flexibility is one of the main reasons | of the main reasons why BGP is so well suited to the commercial | |||
why BGP is so well suited to the commercial environment of the | environment of the current Internet. | |||
current Internet. | ||||
However, this rich policy expressiveness has come with a cost | However, this rich policy expressiveness has come with a cost that is | |||
that is often not recognized. In particular, it is possible | often not recognized. In particular, it is possible to construct | |||
to construct locally defined routing policies that can lead to | locally defined routing policies that can lead to protocol divergence | |||
unexpected global routing anomalies such as (unintended) | and unexpected global routing anomalies such as (unintended) non- | |||
non-determinism and to protocol divergence. If the | determinism. If the interacting policies causing such anomalies are | |||
interacting policies causing such anomalies are defined in | defined in different autonomous systems, then these problems can be | |||
different autonomous systems, then these problems can be very | very difficult to debug and correct. In the following sections, we | |||
difficult to debug and correct. In the following sections, we | describe two such cases relating to the existence (or lack thereof) | |||
describe two such cases relating to the existence (or lack | of stable routings. | |||
thereof) of stable routings. | ||||
7.1. Existence of Unique Stable Routings | 7.1. Existence of Unique Stable Routings | |||
One can easily construct sets of policies for which BGP can not | One can easily construct sets of policies for which BGP can not | |||
guarantee that stable routings are unique. This can be illustrated | guarantee that stable routings are unique. This is illustrated by | |||
by the following simple example. Consider the example of four | the following simple example. Consider four Autonomous Systems, AS1, | |||
Autonomous Systems, AS1, AS2, AS3, and AS4. AS1 and AS2 are peers, | AS2, AS3, and AS4. AS1 and AS2 are peers, and they provide transit | |||
and they provide transit for AS3 and AS4 respectively, Suppose | for AS3 and AS4, respectively. Suppose AS3 provides transit for AS4 | |||
further that AS3 provides transit for AS4 (in this case AS3 is a | (in this case AS3 is a customer of AS1, and AS4 is a multihomed | |||
customer of AS1, and AS4 is a multihomed customer of both AS3 and | customer of both AS3 and AS2). AS4 may want to use the link to AS3 | |||
AS2). AS4 may want to use the link to AS3 as a "backup" link, and | as a "backup" link, and sends AS3 a community value that AS3 has | |||
sends AS3 a community value that AS3 has configured to lower the | configured to lower the preference of AS4's routes to a level below | |||
preference of AS4's routes to a level below that of its upstream | that of its upstream provider, AS1. The intended "backup routing" to | |||
provider, AS1. The intended "backup routing" to AS4 is illustrated | AS4 is illustrated here: | |||
here: | ||||
AS1 ------> AS2 | AS1 ------> AS2 | |||
/|\ | | /|\ | | |||
| | | | | | |||
| | | | | | |||
| \|/ | | \|/ | |||
AS3 ------- AS4 | AS3 ------- AS4 | |||
That is, the AS3-AS4 link is intended to be used only when the | ||||
AS2-AS4 link is down (for outbound traffic, AS4 simply gives routes | That is, the AS3-AS4 link is intended to be used only when the AS2- | |||
from AS2 a higher local preference). This is a common scenario in | AS4 link is down (for outbound traffic, AS4 simply gives routes from | |||
today's Internet. But note that this configuration has another | AS2 a higher local preference). This is a common scenario in today's | |||
stable solution: | Internet. But note that this configuration has another stable | |||
solution: | ||||
AS1 ------- AS2 | AS1 ------- AS2 | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
\|/ \|/ | \|/ \|/ | |||
AS3 ------> AS4 | AS3 ------> AS4 | |||
In this case, AS3 does not translate the "depref my route" community | In this case, AS3 does not translate the "depref my route" community | |||
received from AS4 into a "depref my route" community for AS1, and so | received from AS4 into a "depref my route" community for AS1. | |||
if AS1 hears the route to AS4 that transits AS3 it will prefer that | Therefore, if AS1 hears the route to AS4 that transits AS3, it will | |||
route (since AS3 is a customer). This state could be reached, for | prefer that route (because AS3 is a customer). This state could be | |||
example, by starting in the "correct" backup routing shown first, | reached, for example, by starting in the "correct" backup routing | |||
bringing down the AS2-AS4 BGP session, and then bringing it back up. | shown first, bringing down the AS2-AS4 BGP session, and then bringing | |||
In general, BGP has no way to prefer the "intended" solution over the | it back up. In general, BGP has no way to prefer the "intended" | |||
anomalous one, and which is picked will depend on the unpredictable | solution over the anomalous one. The solution picked will depend on | |||
order of BGP messages. | the unpredictable order of BGP messages. | |||
While this example is relatively simple, many operators may fail to | While this example is relatively simple, many operators may fail to | |||
recognize that the true source of the problem is that the BGP | recognize that the true source of the problem is that the BGP | |||
policies of ASes can interact in unexpected ways, and that these | policies of ASes can interact in unexpected ways, and that these | |||
interactions can result in multiple stable routings. One can imagine | interactions can result in multiple stable routings. One can imagine | |||
that the interactions could be much more complex in the real | that the interactions could be much more complex in the real | |||
Internet. We suspect that such anomalies will only become more | Internet. We suspect that such anomalies will only become more | |||
common as BGP continues to evolve with richer policy expressiveness. | common as BGP continues to evolve with richer policy expressiveness. | |||
For example, extended communities provide an even more flexible means | For example, extended communities provide an even more flexible means | |||
of signaling information within and between autonomous systems than | of signaling information within and between autonomous systems than | |||
is possible with [RFC1997] communities. At the same time, | is possible with [RFC1997] communities. At the same time, | |||
applications of communities by network operators are evolving to | applications of communities by network operators are evolving to | |||
address complex issues of inter-domain traffic engineering. | address complex issues of inter-domain traffic engineering. | |||
7.2. Existence of Stable Routings | 7.2. Existence of Stable Routings | |||
One can also construct a set of policies for which BGP can not | One can also construct a set of policies for which BGP can not | |||
guarantee that a stable routing exists (or worse, that a stable | guarantee that a stable routing exists (or, worse, that a stable | |||
routing will ever be found). For example, [RFC3345] documents | routing will ever be found). For example, [RFC3345] documents | |||
several scenarios that lead to route oscillations associated | several scenarios that lead to route oscillations associated with the | |||
with the use of the Multi-Exit Discriminator or MED, | use of the Multi-Exit Discriminator (MED) attribute. Route | |||
attribute. Route | ||||
oscillation will happen in BGP when a set of policies has no | oscillation will happen in BGP when a set of policies has no | |||
solution. That is, when there is no stable routing that satisfies | solution. That is, when there is no stable routing that satisfies | |||
the constraints imposed by policy, then BGP has no choice by to keep | the constraints imposed by policy, BGP has no choice but to keep | |||
trying. In addition, BGP configurations can have a stable routing, | trying. In addition, even if BGP configurations can have a stable | |||
yet the protocol may not be able to find it; BGP can "get trapped" | routing, the protocol may not be able to find it; BGP can "get | |||
down a blind alley that has no solution. | trapped" down a blind alley that has no solution. | |||
Protocol divergence is not, however, a problem associated solely with | Protocol divergence is not, however, a problem associated solely with | |||
use of the MED attribute. This potential exists in BGP even without | use of the MED attribute. This potential exists in BGP even without | |||
the use of the MED attribute. Hence, like the unintended | the use of the MED attribute. Hence, like the unintended | |||
nondeterminism described in the previous section, this type of | nondeterminism described in the previous section, this type of | |||
protocol divergence is an unintended consequence of the unconstrained | protocol divergence is an unintended consequence of the unconstrained | |||
nature of BGP policy languages. | nature of BGP policy languages. | |||
8. Applicability | 8. Applicability | |||
In this section we identify the environments for which BGP well | In this section we identify the environments for which BGP is well | |||
suited, and for which environments it is not suitable. This question | suited, and the environments for which it is not suitable. This | |||
is partially answered in Section 2 of BGP [BGP4], which states: | question is partially answered in Section 2 of BGP [BGP4], which | |||
states: | ||||
"To characterize the set of policy decisions that can be | "To characterize the set of policy decisions that can be enforced | |||
enforced using BGP, one must focus on the rule that an AS | using BGP, one must focus on the rule that an AS advertises to its | |||
advertises to its neighbor ASs only those routes that it | neighbor ASes only those routes that it itself uses. This rule | |||
itself uses. This rule reflects the "hop-by-hop" routing | reflects the "hop-by-hop" routing paradigm generally used | |||
paradigm generally used throughout the current Internet. | throughout the current Internet. Note that some policies cannot | |||
Note that some policies cannot be supported by the | be supported by the "hop-by-hop" routing paradigm and thus require | |||
"hop-by-hop" routing paradigm and thus require techniques | techniques such as source routing to enforce. For example, BGP | |||
such as source routing to enforce. For example, BGP does | does not enable one AS to send traffic to a neighbor AS intending | |||
not enable one AS to send traffic to a neighbor AS | that the traffic take a different route from that taken by traffic | |||
intending that the traffic take a different route from | originating in the neighbor AS. On the other hand, BGP can | |||
that taken by traffic originating in the neighbor AS. On | support any policy conforming to the "hop-by-hop" routing | |||
the other hand, BGP can support any policy conforming to | paradigm. Since the current Internet uses only the "hop-by-hop" | |||
the "hop-by-hop" routing paradigm. Since the current | routing paradigm and since BGP can support any policy that | |||
Internet uses only the "hop-by-hop" routing paradigm and | conforms to that paradigm, BGP is highly applicable as an inter-AS | |||
since BGP can support any policy that conforms to that | routing protocol for the current Internet." | |||
paradigm, BGP is highly applicable as an inter-AS routing | ||||
protocol for the current Internet." | ||||
One of the important points here is that the BGP protocol contains | One of the important points here is that BGP contains only essential | |||
only the functionality that is essential, while at the same time | functionality, while at the same time providing a flexible mechanism | |||
providing a flexible mechanism within the protocol that allows us to | within the protocol that allows us to extend its functionality. For | |||
extend its functionality. For example, BGP capabilities provide an | example, BGP capabilities provide an easy and flexible way to | |||
easy and flexible way to introduce new features within the protocol. | introduce new features within the protocol. Finally, because BGP was | |||
Finally, since BGP was designed with flexibility and | designed to be flexible and extensible, new and/or evolving | |||
extensibility in mind, new and/or evolving requirements can be | requirements can be addressed via existing mechanisms. | |||
addressed via existing mechanisms. | ||||
To summarize, BGP is well suited as an inter-autonomous system | To summarize, BGP is well suited as an inter-autonomous system | |||
routing protocol for any internet that is based on IP [RFC791] | routing protocol for any internet that is based on IP [RFC791] as the | |||
as the internet protocol and "hop-by-hop" routing paradigm. | internet protocol and the "hop-by-hop" routing paradigm. | |||
9. Acknowledgments | 9. Acknowledgements | |||
We would like to thank Paul Traina for authoring previous | We would like to thank Paul Traina for authoring previous versions of | |||
versions of this document. Elwyn Davies, Tim Griffin, Randy | this document. Elwyn Davies, Tim Griffin, Randy Presuhn, Curtis | |||
Presuhn, Curtis Villamizar and Atanu Ghosh also provided many | Villamizar and Atanu Ghosh also provided many insightful comments on | |||
insightful comments on earlier versions of this document. | earlier versions of this document. | |||
10. Security Considerations | 10. Security Considerations | |||
BGP provides flexible mechanisms with varying levels of complexity | BGP provides flexible mechanisms with varying levels of complexity | |||
for security purposes. BGP sessions are authenticated using BGP | for security purposes. BGP sessions are authenticated using BGP | |||
session addresses and the assigned AS number. Since BGP | session addresses and the assigned AS number. Because BGP sessions | |||
sessions use TCP (and IP) for reliable transport, BGP sessions | use TCP (and IP) for reliable transport, BGP sessions are further | |||
are further authenticated and secured by any authentication | authenticated and secured by any authentication and security | |||
and security mechanisms used by TCP and IP. | mechanisms used by TCP and IP. | |||
BGP uses TCP MD5 option for validating data and protecting against | BGP uses TCP MD5 option for validating data and protecting against | |||
spoofing of TCP segments exchanged between its sessions. The usage | spoofing of TCP segments exchanged between its sessions. The usage | |||
of TCP MD5 option for BGP is described at length in [RFC 2385]. The | of TCP MD5 option for BGP is described at length in [RFC 2385]. The | |||
TCP MD5 Key management is discussed in [RFC 3562]. BGP data | TCP MD5 Key management is discussed in [RFC 3562]. BGP data | |||
encryption is provided using IPsec mechanism which encrypts the IP | encryption is provided using the IPsec mechanism, which encrypts the | |||
payload data (including TCP and BGP data). The IPsec mechanism can | IP payload data (including TCP and BGP data). The IPsec mechanism | |||
be used in both, the transport mode as well as the tunnel mode. The | can be used in both the transport mode and the tunnel mode. The | |||
IPsec mechanism is described in [RFC 2406]. Both, the TCP MD5 option | IPsec mechanism is described in [RFC2406]. Both the TCP MD5 option | |||
and the IPsec mechanism are not widely deployed security mechanisms | and the IPsec mechanism are not widely deployed security mechanisms | |||
for BGP in today's Internet and hence it is difficult to gauge their | for BGP in today's Internet. Hence, it is difficult to gauge their | |||
real performance impact when using with BGP. However, since both the | real performance impact when using with BGP. However, because both | |||
mechanisms are TCP and IP based security mechanisms, the Link | the mechanisms are TCP- and IP-based security mechanisms, the Link | |||
Bandwidth, CPU utilization and router memory consumed by BGP protocol | Bandwidth, CPU utilization and router memory consumed by BGP would be | |||
using it would be same as any other TCP and IP based protocols. | the same as any other TCP- and IP-based protocols. | |||
BGP uses IP TTL value to protect its External BGP (EBGP) sessions | BGP uses the IP TTL value to protect its External BGP (EBGP) sessions | |||
from any TCP (or IP) based CPU intensive attacks. It is a simple | from any TCP- or IP-based CPU-intensive attacks. It is a simple | |||
mechanism which suggests the use of filtering BGP (TCP) segments | mechanism that suggests the use of filtering BGP (TCP) segments, | |||
using the IP TTL value carried within the IP header of BGP (TCP) | using the IP TTL value carried within the IP header of BGP (TCP) | |||
segments exchanged between the EBGP sessions. The BGP TTL mechanism | segments that are exchanged between the EBGP sessions. The BGP TTL | |||
is described in [RFC3682]. Usage of [RFC3682] impacts performance in | mechanism is described in [RFC3682]. Usage of [RFC3682] impacts | |||
a similar way as using any ACL policies for BGP. | performance in a similar way as using any access control list (ACL) | |||
policies for BGP. | ||||
Such flexible TCP and IP based security mechanisms, allow BGP to | Such flexible TCP- and IP-based security mechanisms, allow BGP to | |||
prevent insertion/deletion/modification of BGP data, any snooping of | prevent insertion/deletion/modification of BGP data, any snooping of | |||
the data, session stealing, etc. However, BGP is vulnerable to the | the data, session stealing, etc. However, BGP is vulnerable to the | |||
same security attacks that are present in TCP. The [BGP-VUL] | same security attacks that are present in TCP. The [BGP-VULN] | |||
explains in depth about the BGP security vulnerability. At the time | explains in depth about the BGP security vulnerability. At the time | |||
of this writing, several efforts are underway for creating and | of this writing, several efforts are underway for creating and | |||
defining an appropriate security infrastructure within the BGP | defining an appropriate security infrastructure within the BGP | |||
protocol to provide authentication and security for its routing | protocol to provide authentication and security for its routing | |||
information; some of which include [SBGP] and [SOBGP]. | information; these efforts include [SBGP] and [SOBGP]. | |||
11. IANA Considerations | ||||
This document presents an analysis of the BGP protocol and hence | ||||
presents no new IANA considerations. | ||||
12. References | ||||
12.1. Normative References | 11. References | |||
[BGP4] Rekhter, Y., T. Li., and S. Hares, Editors, "A | 11.1. Normative References | |||
Border Gateway Protocol 4 (BGP-4)", | ||||
draft-ietf-idr-bgp4-2.txt. Work in progress. | ||||
[RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, | [BGP4] Rekhter, Y., Li., T., and S. Hares, Eds., "A Border | |||
"Classless Inter-Domain Routing (CIDR): an Address | Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. | |||
Assignment and Aggregation Strategy", RFC 1519, | ||||
September, 1993. | ||||
[RFC791] "INTERNET PROTOCOL", DARPA INTERNET PROGRAM | [RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless | |||
PROTOCOL SPECIFICATION, RFC 791, September, | Inter-Domain Routing (CIDR): an Address Assignment and | |||
1981. | Aggregation Strategy", RFC 1519, September 1993. | |||
[RFC1997] Chandra. R, and T. Li, "BGP Communities | [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, | |||
Attribute", RFC 1997, August, 1996. | September 1981. | |||
[RFC2385] Heffernan, A., "Protection of BGP Sessions via | [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities | |||
the TCP MD5 Signature Option", RFC 2385, | Attribute", RFC 1997, August 1996. | |||
August, 1998. | ||||
[RFC2842] Chandra, R. and J. Scudder, "Capabilities | [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP | |||
Advertisement with BGP-4", RFC 2842, May 2000. | MD5 Signature Option", RFC 2385, August 1998. | |||
[RFC3345] McPherson, D., Gill, V., Walton, D., and | [RFC3345] McPherson, D., Gill, V., Walton, D., and A. Retana, | |||
A. Retana, "Border Gateway Protocol (BGP) Persistent | "Border Gateway Protocol (BGP) Persistent Route | |||
Route Oscillation Condition", RFC 3345, | Oscillation Condition", RFC 3345, August 2002. | |||
August, 2002. | ||||
[RFC3562] Leech, M., "Key Management Considerations for | [RFC3562] Leech, M., "Key Management Considerations for the TCP | |||
the TCP MD5 Signature Option", RFC 3562, | MD5 Signature Option", RFC 3562, July 2003. | |||
July, 2003. | ||||
[RFC3682] Gill, V., Heasley, J., and D. Meyer, "The | [RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized | |||
Generalized TTL Security Mechanism (GTSM)", RFC | TTL Security Mechanism (GTSM)", RFC 3682, February | |||
3682, February, 2004. | 2004. | |||
[SOBGP] White, R., "Architecture and Deployment | ||||
Considerations for Secure Origin BGP (soBGP)", | ||||
draft-white-sobgp-architecture-00.txt. Work in | ||||
Progress. | ||||
[BGP_VULN] Murphy, S., "BGP Security Vulnerabilities Analysis", | [RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement | |||
draft-ietf-idr-bgp-vuln-01.txt. Work in progress | with BGP-4", RFC 3392, November 2002. | |||
[SBGP] Lynn, C., Mikkelson, J., and K. Seo, "Secure BGP S-BGP", | [BGP-VULN] Murphy, S., "BGP Security Vulnerabilities Analysis", | |||
Internet-Draft, Work in Progress. | RFC 4272, January 2006. | |||
12.2. Informative References | [SBGP] Seo, K., S. Kent and C. Lynn, "Secure Border Gateway | |||
Protocol (Secure-BGP)", IEEE Journal on Selected Areas | ||||
in Communications Vol. 18, No. 4, April 2000, pp. 582- | ||||
592. | ||||
[RFC854] Postel, J. and J. Reynolds, "TELNET PROTOCOL | 11.2. Informative References | |||
SPECIFICATION", RFC 854, May, 1983. | ||||
[RFC1105] Lougheed, K., and Y. Rekhter, "Border Gateway | [RFC854] Postel, J. and J. Reynolds, "Telnet Protocol | |||
Protocol BGP", RFC 1105, June 1989. | Specification", STD 8, RFC 854, May 1983. | |||
[RFC1163] Lougheed, K., and Rekhter, Y, "Border Gateway | [RFC1105] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol | |||
Protocol BGP", RFC 1105, June 1990. | (BGP)", RFC 1105, June 1989. | |||
[RFC1264] Hinden, R., "Internet Routing Protocol | [RFC1163] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol | |||
Standardization Criteria", RFC 1264, October 1991. | (BGP)", RFC 1163, June 1990. | |||
[RFC1267] Lougheed, K., and Rekhter, Y, "Border Gateway | [RFC1264] Hinden, R., "Internet Routing Protocol Standardization | |||
Protocol 3 (BGP-3)", RFC 1105, October 1991. | Criteria", RFC 1264, October 1991. | |||
[RFC1771] Rekhter, Y., and T. Li, "A Border Gateway | [RFC1267] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol 3 | |||
Protocol 4 (BGP-4)", RFC 1771, March 1995. | (BGP-3)", RFC 1267, October 1991. | |||
[RFC1772] Rekhter, Y., and P. Gross, Editors, "Application | [RFC1772] Rekhter, Y., and P. Gross, Editors, "Application | |||
of the Border Gateway Protocol in the Internet", | of the Border Gateway Protocol in the Internet", RFC | |||
RFC 1772, March 1995. | 1772, March 1995. | |||
[RFC1774] Traina, P., "BGP-4 protocol analysis", | [RFC1774] Traina, P., "BGP-4 Protocol Analysis", RFC 1774, March | |||
RFC 1774, March, 1995. | 1995. | |||
[RFC2622] Alaettinoglu, C., et. al., "Routing Policy | [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, | |||
Specification Language (RPSL)" RFC 2622, May, | D., Meyer, D., Bates, T., Karrenberg, D., and M. | |||
1998. | Terpstra, "Routing Policy Specification Language | |||
(RPSL)", RFC 2622, June 1999. | ||||
[RFC2406] Kent, S., Atkinson, R., "IP Encapsulating Security | [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security | |||
Payload (ESP)", RFC 2406, November, 1998. | Payload (ESP)", RFC 2406, November 1998. | |||
[ROUTEVIEWS] Meyer, D., "The Route Views Project", | [ROUTEVIEWS] Meyer, D., "The Route Views Project", | |||
http://www.routeviews.org | http://www.routeviews.org. | |||
13. Author's Addresses | [SOBGP] White, R., "Architecture and Deployment Considerations | |||
for Secure Origin BGP (soBGP)", Work in Progress, May | ||||
2005. | ||||
Authors' Addresses | ||||
David Meyer | David Meyer | |||
Email: dmm@1-4-5.net | ||||
EMail: dmm@1-4-5.net | ||||
Keyur Patel | Keyur Patel | |||
Cisco Systems | Cisco Systems | |||
Email: keyupate@cisco.com | ||||
Intellectual Property Statement | EMail: keyupate@cisco.com | |||
Full Copyright Statement | ||||
Copyright (C) The Internet Society (2006). | ||||
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 | The IETF takes no position regarding the validity or scope of any | |||
Intellectual Property Rights or other rights that might be claimed to | Intellectual Property Rights or other rights that might be claimed to | |||
pertain to the implementation or use of the technology described in | pertain to the implementation or use of the technology described in | |||
this document or the extent to which any license under such rights | 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 | might or might not be available; nor does it represent that it has | |||
made any independent effort to identify any such rights. Information | made any independent effort to identify any such rights. Information | |||
on the procedures with respect to rights in RFC documents can be | on the procedures with respect to rights in RFC documents can be | |||
found in BCP 78 and BCP 79. | found in BCP 78 and BCP 79. | |||
skipping to change at page 19, line 44 | skipping to change at page 16, line 45 | |||
such proprietary rights by implementers or users of this | such proprietary rights by implementers or users of this | |||
specification can be obtained from the IETF on-line IPR repository at | specification can be obtained from the IETF on-line IPR repository at | |||
http://www.ietf.org/ipr. | http://www.ietf.org/ipr. | |||
The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention any | |||
copyrights, patents or patent applications, or other proprietary | copyrights, patents or patent applications, or other proprietary | |||
rights that may cover technology that may be required to implement | rights that may cover technology that may be required to implement | |||
this standard. Please address the information to the IETF at | this standard. Please address the information to the IETF at | |||
ietf-ipr@ietf.org. | ietf-ipr@ietf.org. | |||
Disclaimer of Validity | Acknowledgement | |||
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. | ||||
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. | ||||
Acknowledgment | ||||
Funding for the RFC Editor function is currently provided by the | Funding for the RFC Editor function is provided by the IETF | |||
Internet Society. | Administrative Support Activity (IASA). | |||
End of changes. 117 change blocks. | ||||
470 lines changed or deleted | 425 lines changed or added | |||
This html diff was produced by rfcdiff 1.28, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |