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