diff options
Diffstat (limited to 'doc/rfc/rfc4277.txt')
| -rw-r--r-- | doc/rfc/rfc4277.txt | 1067 |
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc4277.txt b/doc/rfc/rfc4277.txt new file mode 100644 index 0000000..97707a4 --- /dev/null +++ b/doc/rfc/rfc4277.txt @@ -0,0 +1,1067 @@ + + + + + + +Network Working Group D. McPherson +Request for Comments: 4277 Arbor Networks +Category: Informational K. Patel + Cisco Systems + January 2006 + + + Experience with the BGP-4 Protocol + +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 memo 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 1773 and describes additional + knowledge and understanding gained in the time between when the + protocol was made a Draft Standard and when it was submitted for + Standard. + + + + + + + + + + + + + + + + + + + + +McPherson & Patel Informational [Page 1] + +RFC 4277 Experience with the BGP-4 Protocol January 2006 + + +Table of Contents + + 1. Introduction ................................................. 3 + 2. BGP-4 Overview ............................................... 3 + 2.1. A Border Gateway Protocol .............................. 3 + 3. Management Information Base (MIB) ............................ 3 + 4. Implementation Information ................................... 4 + 5. Operational Experience ....................................... 4 + 6. TCP Awareness ................................................ 5 + 7. Metrics ...................................................... 5 + 7.1. MULTI_EXIT_DISC (MED) .................................. 5 + 7.1.1. MEDs and Potatoes .............................. 6 + 7.1.2. Sending MEDs to BGP Peers ...................... 7 + 7.1.3. MED of Zero Versus No MED ...................... 7 + 7.1.4. MEDs and Temporal Route Selection .............. 7 + 8. Local Preference ............................................. 8 + 9. Internal BGP In Large Autonomous Systems ..................... 9 + 10. Internet Dynamics ............................................ 9 + 11. BGP Routing Information Bases (RIBs) ......................... 10 + 12. Update Packing ............................................... 10 + 13. Limit Rate Updates ........................................... 11 + 13.1. Consideration of TCP Characteristics ................... 11 + 14. Ordering of Path Attributes .................................. 12 + 15. AS_SET Sorting ............................................... 12 + 16. Control Over Version Negotiation ............................. 13 + 17. Security Considerations ...................................... 13 + 17.1. TCP MD5 Signature Option ............................... 13 + 17.2. BGP Over IPsec ......................................... 14 + 17.3. Miscellaneous .......................................... 14 + 18. PTOMAINE and GROW ............................................ 14 + 19. Internet Routing Registries (IRRs) ........................... 15 + 20. Regional Internet Registries (RIRs) and IRRs, A Bit + of History ................................................... 15 + 21. Acknowledgements ............................................. 16 + 22. References ................................................... 17 + 22.1. Normative References ................................... 17 + 22.2. Informative References ................................. 17 + + + + + + + + + + + + + + +McPherson & Patel Informational [Page 2] + +RFC 4277 Experience with the BGP-4 Protocol January 2006 + + +1. Introduction + + The purpose of this memo 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 [RFC1773] and describes additional + knowledge and understanding gained in the time between when the + protocol was made a Draft Standard and when it was submitted for + Standard. + +2. BGP-4 Overview + + BGP is an inter-autonomous system routing protocol designed for + TCP/IP internets. The primary function of a BGP speaking system is + to exchange network reachability information with other BGP systems. + This network reachability information includes information on the + list of Autonomous Systems (ASes) that reachability information + traverses. This information is sufficient to construct a graph of AS + connectivity for this reachability, from which routing loops may be + pruned and some policy decisions, at the AS level, may be enforced. + + The initial version of the BGP protocol was published in [RFC1105]. + Since then, BGP Versions 2, 3, and 4 have been developed and are + specified in [RFC1163], [RFC1267], and [RFC1771], respectively. + Changes to BGP-4 after it went to Draft Standard [RFC1771] are listed + in Appendix N of [RFC4271]. + +2.1. A Border Gateway Protocol + + The initial version of the BGP protocol was published in [RFC1105]. + BGP version 2 is defined in [RFC1163]. BGP version 3 is defined in + [RFC1267]. BGP version 4 is defined in [RFC1771] and [RFC4271]. + Appendices A, B, C, and D of [RFC4271] provide summaries of the + changes between each iteration of the BGP specification. + +3. Management Information Base (MIB) + + The BGP-4 Management Information Base (MIB) has been published + [BGP-MIB]. The MIB was updated from previous versions, which are + documented in [RFC1657] and [RFC1269], respectively. + + Apart from a few system variables, the BGP MIB is broken into two + tables: the BGP Peer Table and the BGP Received Path Attribute Table. + + + + + +McPherson & Patel Informational [Page 3] + +RFC 4277 Experience with the BGP-4 Protocol January 2006 + + + The Peer Table reflects information about BGP peer connections, such + as their state and current activity. The Received Path Attribute + Table contains all attributes received from all peers before local + routing policy has been applied. The actual attributes used in + determining a route are a subset of the received attribute table. + +4. Implementation Information + + There are numerous independent interoperable implementations of BGP + currently available. Although the previous version of this report + provided an overview of the implementations currently used in the + operational Internet, at that time it has been suggested that a + separate BGP Implementation Report [RFC4276] be generated. + + It should be noted that implementation experience with Cisco's BGP-4 + implementation was documented as part of [RFC1656]. + + For all additional implementation information please reference + [RFC4276]. + +5. Operational Experience + + This section discusses operational experience with BGP and BGP-4. + + BGP has been used in the production environment since 1989; BGP-4 has + been used since 1993. Production use of BGP includes utilization of + all significant features of the protocol. The present production + environment, where BGP is used as the inter-autonomous system routing + protocol, is highly heterogeneous. In terms of link bandwidth, it + varies from 56 Kbps to 10 Gbps. In terms of the actual routers that + run BGP, they range from relatively slow performance, general purpose + CPUs to very high performance RISC network processors, and include + both special purpose routers and the general purpose workstations + that run various UNIX derivatives and other operating systems. + + In terms of the actual topologies, it varies from very sparse to + quite dense. The requirement for full-mesh IBGP topologies has been + largely remedied by BGP Route Reflection, Autonomous System + Confederations for BGP, and often some mix of the two. BGP Route + Reflection was initially defined in [RFC1966] and was updated in + [RFC2796]. Autonomous System Confederations for BGP were initially + defined in [RFC1965] and were updated in [RFC3065]. + + At the time of this writing, BGP-4 is used as an inter-autonomous + system routing protocol between all Internet-attached autonomous + systems, with nearly 21k active autonomous systems in the global + Internet routing table. + + + + +McPherson & Patel Informational [Page 4] + +RFC 4277 Experience with the BGP-4 Protocol January 2006 + + + BGP is used both for the exchange of routing information between a + transit and a stub autonomous system, and for the exchange of routing + information between multiple transit autonomous systems. There is no + protocol distinction between sites historically considered + "backbones" versus "regional" or "edge" networks. + + The full set of exterior routes carried by BGP is well over 170,000 + aggregate entries, representing several times that number of + connected networks. The number of active paths in some service + provider core routers exceeds 2.5 million. Native AS path lengths + are as long as 10 for some routes, and "padded" path lengths of 25 or + more autonomous systems exist. + +6. TCP Awareness + + BGP employs TCP [RFC793] as it's Transport Layer protocol. As such, + all characteristics inherent to TCP are inherited by BGP. + + For example, due to TCP's behavior, bandwidth capabilities may not be + realized because of TCP's slow start algorithms and slow-start + restarts of connections, etc. + +7. Metrics + + This section discusses different metrics used within the BGP + protocol. BGP has a separate metric parameter for IBGP and EBGP. + This allows policy-based metrics to overwrite the distance-based + metrics; this allows each autonomous system to define its independent + policies in Intra-AS, as well as Inter-AS. BGP Multi Exit + Discriminator (MED) is used as a metric by EBGP peers (i.e., inter- + domain), while Local Preference (LOCAL_PREF) is used by IBGP peers + (i.e., intra-domain). + +7.1. MULTI_EXIT_DISC (MED) + + BGP version 4 re-defined the old INTER-AS metric as a MULTI_EXIT_DISC + (MED). This value may be used in the tie-breaking process when + selecting a preferred path to a given address space, and provides BGP + speakers with the capability of conveying the optimal entry point + into the local AS to a peer AS. + + Although the MED was meant to only be used when comparing paths + received from different external peers in the same AS, many + implementations provide the capability to compare MEDs between + different autonomous systems. + + Though this may seem a fine idea for some configurations, care must + be taken when comparing MEDs of different autonomous systems. BGP + + + +McPherson & Patel Informational [Page 5] + +RFC 4277 Experience with the BGP-4 Protocol January 2006 + + + speakers often derive MED values by obtaining the IGP metric + associated with reaching a given BGP NEXT_HOP within the local AS. + This allows MEDs to reasonably reflect IGP topologies when + advertising routes to peers. While this is fine when comparing MEDs + of multiple paths learned from a single adjacent AS, it can result in + potentially bad decisions when comparing MEDs of different autonomous + systems. This is most typically the case when the autonomous systems + use different mechanisms to derive IGP metrics, BGP MEDs, or perhaps + even use different IGP protocols with vastly contrasting metric + spaces. + + Another MED deployment consideration involves the impact of the + aggregation of BGP routing information on MEDs. Aggregates are often + generated from multiple locations in an AS to accommodate stability, + redundancy, and other network design goals. When MEDs are derived + from IGP metrics associated with said aggregates, the MED value + advertised to peers can result in very suboptimal routing. + + The MED was purposely designed to be a "weak" metric that would only + be used late in the best-path decision process. The BGP working + group was concerned that any metric specified by a remote operator + would only affect routing in a local AS if no other preference was + specified. A paramount goal of the design of the MED was to ensure + that peers could not "shed" or "absorb" traffic for networks they + advertise. + +7.1.1. MEDs and Potatoes + + Where traffic flows between a pair of destinations, each is connected + to two transit networks, each of the transit networks has the choice + of sending the traffic to the peering closest to another transit + provider or passing traffic to the peering that advertises the least + cost through the other provider. The former method is called "hot + potato routing" because, like a hot potato held in bare hands, + whoever has it tries to get rid of it quickly. Hot potato routing is + accomplished by not passing the EBGP-learned MED into the IBGP. This + minimizes transit traffic for the provider routing the traffic. Far + less common is "cold potato routing", where the transit provider uses + its own transit capacity to get the traffic to the point in the + adjacent transit provider advertised as being closest to the + destination. Cold potato routing is accomplished by passing the + EBGP-learned MED into IBGP. + + If one transit provider uses hot potato routing and another uses cold + potato routing, traffic between the two tends to be symmetric. + Depending on the business relationships, if one provider has more + capacity or a significantly less congested transit network, then that + provider may use cold potato routing. The NSF-funded NSFNET backbone + + + +McPherson & Patel Informational [Page 6] + +RFC 4277 Experience with the BGP-4 Protocol January 2006 + + + and NSF-funded regional networks are examples of widespread use of + cold potato routing in the mid 1990s. + + In some cases, a provider may use hot potato routing for some + destinations for a given peer AS, and cold potato routing for others. + The different treatment of commercial and research traffic in the + NSFNET in the mid 1990s is an example of this. However, this might + best be described as 'mashed potato routing', a term that reflects + the complexity of router configurations in use at the time. + + Seemingly more intuitive references, which fall outside the vegetable + kingdom, refer to cold potato routing as "best exit routing", and hot + potato routing as "closest exit routing". + +7.1.2. Sending MEDs to BGP Peers + + [RFC4271] allows MEDs received from any EBGP peers by a BGP speaker + to be passed to its IBGP peers. Although advertising MEDs to IBGP + peers is not a required behavior, it is a common default. MEDs + received from EBGP peers by a BGP speaker SHOULD NOT be sent to other + EBGP peers. + + Note that many implementations provide a mechanism to derive MED + values from IGP metrics to allow BGP MED information to reflect the + IGP topologies and metrics of the network when propagating + information to adjacent autonomous systems. + +7.1.3. MED of Zero Versus No MED + + [RFC4271] requires an implementation to provide a mechanism that + allows MED to be removed. Previously, implementations did not + consider a missing MED value the same as a MED of zero. [RFC4271] + now requires that no MED value be equal to zero. + + Note that many implementations provide a mechanism to explicitly + define a missing MED value as "worst", or less preferable than zero + or larger values. + +7.1.4. MEDs and Temporal Route Selection + + Some implementations have hooks to apply temporal behavior in MED- + based best path selection. That is, all things being equal up to MED + consideration, preference would be applied to the "oldest" path, + without preference for the lower MED value. The reasoning for this + is that "older" paths are presumably more stable, and thus + preferable. However, temporal behavior in route selection results in + non-deterministic behavior, and as such, may often be undesirable. + + + + +McPherson & Patel Informational [Page 7] + +RFC 4277 Experience with the BGP-4 Protocol January 2006 + + +8. Local Preference + + The LOCAL_PREF attribute was added to enable a network operator to + easily configure a policy that overrides the standard best path + determination mechanism without independently configuring local + preference policy on each router. + + One shortcoming in the BGP-4 specification was the suggestion that a + default value of LOCAL_PREF be assumed if none was provided. + Defaults of zero or the maximum value each have range limitations, so + a common default would aid in the interoperation of multi-vendor + routers in the same AS (since LOCAL_PREF is a local administration + attribute, there is no interoperability drawback across AS + boundaries). + + [RFC4271] requires that LOCAL_PREF be sent to IBGP Peers and not to + EBGP Peers. Although no default value for LOCAL_PREF is defined, the + common default value is 100. + + Another area where exploration is required is a method whereby an + originating AS may influence the best path selection process. For + example, a dual-connected site may select one AS as a primary transit + service provider and have one as a backup. + + /---- transit B ----\ + end-customer transit A---- + /---- transit C ----\ + + In a topology where the two transit service providers connect to a + third provider, the real decision is performed by the third provider. + There is no mechanism to indicate a preference should the third + provider wish to respect that preference. + + A general purpose suggestion has been the possibility of carrying an + optional vector, corresponding to the AS_PATH, where each transit AS + may indicate a preference value for a given route. Cooperating + autonomous systems may then choose traffic based upon comparison of + "interesting" portions of this vector, according to routing policy. + + While protecting a given autonomous systems routing policy is of + paramount concern, avoiding extensive hand configuration of routing + policies needs to be examined more carefully in future BGP-like + protocols. + + + + + + + + +McPherson & Patel Informational [Page 8] + +RFC 4277 Experience with the BGP-4 Protocol January 2006 + + +9. Internal BGP In Large Autonomous Systems + + While not strictly a protocol issue, another concern has been raised + by network operators who need to maintain autonomous systems with a + large number of peers. Each speaker peering with an external router + is responsible for propagating reachability and path information to + all other transit and border routers within that AS. This is + typically done by establishing internal BGP connections to all + transit and border routers in the local AS. + + Note that the number of BGP peers that can be fully meshed depends on + a number of factors, including the number of prefixes in the routing + system, the number of unique paths, stability of the system, and, + perhaps most importantly, implementation efficiency. As a result, + although it's difficult to define "a large number of peers", there is + always some practical limit. + + In a large AS, this leads to a full mesh of TCP connections + (n * (n-1)) and some method of configuring and maintaining those + connections. BGP does not specify how this information is to be + propagated. Therefore, alternatives, such as injecting BGP routing + information into the local IGP, have been attempted, but turned out + to be non-practical alternatives (to say the least). + + To alleviate the need for "full mesh" IBGP, several alternatives have + been defined, including BGP Route Reflection [RFC2796] and AS + Confederations for BGP [RFC3065]. + +10. Internet Dynamics + + As discussed in [RFC4274], the driving force in CPU and bandwidth + utilization is the dynamic nature of routing in the Internet. As the + Internet has grown, the frequency of route changes per second has + increased. + + We automatically get some level of damping when more specific NLRI is + aggregated into larger blocks; however, this is not sufficient. In + Appendix F of [RFC4271], there are descriptions of damping techniques + that should be applied to advertisements. In future specifications + of BGP-like protocols, damping methods should be considered for + mandatory inclusion in compliant implementations. + + BGP Route Flap Damping is defined in [RFC2439]. BGP Route Flap + Damping defines a mechanism to help reduce the amount of routing + information passed between BGP peers, which reduces the load on these + peers without adversely affecting route convergence time for + relatively stable routes. + + + + +McPherson & Patel Informational [Page 9] + +RFC 4277 Experience with the BGP-4 Protocol January 2006 + + + None of the current implementations of BGP Route Flap Damping store + route history by unique NRLI or AS Path, although RFC 2439 lists this + as mandatory. A potential result of failure to consider each AS Path + separately is an overly aggressive suppression of destinations in a + densely meshed network, with the most severe consequence being + suppression of a destination after a single failure. Because the top + tier autonomous systems in the Internet are densely meshed, these + adverse consequences are observed. + + Route changes are announced using BGP UPDATE messages. The greatest + overhead in advertising UPDATE messages happens whenever route + changes to be announced are inefficiently packed. Announcing routing + changes that share common attributes in a single BGP UPDATE message + helps save considerable bandwidth and reduces processing overhead, as + discussed in Section 12, Update Packing. + + Persistent BGP errors may cause BGP peers to flap persistently if + peer dampening is not implemented, resulting in significant CPU + utilization. Implementors may find it useful to implement peer + dampening to avoid such persistent peer flapping [RFC4271]. + +11. BGP Routing Information Bases (RIBs) + + [RFC4271] states "Any local policy which results in routes being + added to an Adj-RIB-Out without also being added to the local BGP + speaker's forwarding table, is outside the scope of this document". + + However, several well-known implementations do not confirm that + Loc-RIB entries were used to populate the forwarding table before + installing them in the Adj-RIB-Out. The most common occurrence of + this is when routes for a given prefix are presented by more than one + protocol, and the preferences for the BGP-learned route is lower than + that of another protocol. As such, the route learned via the other + protocol is used to populate the forwarding table. + + It may be desirable for an implementation to provide a knob that + permits advertisement of "inactive" BGP routes. + + It may be also desirable for an implementation to provide a knob that + allows a BGP speaker to advertise BGP routes that were not selected + in the decision process. + +12. Update Packing + + Multiple unfeasible routes can be advertised in a single BGP Update + message. In addition, one or more feasible routes can be advertised + in a single Update message, as long as all prefixes share a common + attribute set. + + + +McPherson & Patel Informational [Page 10] + +RFC 4277 Experience with the BGP-4 Protocol January 2006 + + + The BGP4 protocol permits advertisement of multiple prefixes with a + common set of path attributes in a single update message, which is + commonly referred to as "update packing". When possible, update + packing is recommended, as it provides a mechanism for more efficient + behavior in a number of areas, including: + + o Reduction in system overhead due to generation or receipt of + fewer Update messages. + + o Reduction in network overhead as a result of less packets and + lower bandwidth consumption. + + o Reduction in frequency of processing path attributes and looking + for matching sets in the AS_PATH database (if you have one). + Consistent ordering of the path attributes allows for ease of + matching in the database, as different representations of the + same data do not exist. + + The BGP protocol suggests that withdrawal information should be + packed in the beginning of an Update message, followed by information + about reachable routes in a single UPDATE message. This helps + alleviate excessive route flapping in BGP. + +13. Limit Rate Updates + + The BGP protocol defines different mechanisms to rate limit Update + advertisement. The BGP protocol defines a + MinRouteAdvertisementInterval parameter that determines the minimum + time that must elapse between the advertisement of routes to a + particular destination from a single BGP speaker. This value is set + on a per-BGP-peer basis. + + Because BGP relies on TCP as the Transport protocol, TCP can prevent + transmission of data due to empty windows. As a result, multiple + updates may be spaced closer together than was originally queued. + Although it is not common, implementations should be aware of this + occurrence. + +13.1. Consideration of TCP Characteristics + + If either a TCP receiver is processing input more slowly than the + sender, or if the TCP connection rate is the limiting factor, a form + of backpressure is observed by the TCP sending application. When the + TCP buffer fills, the sending application will either block on the + write or receive an error on the write. In early implementations or + naive new implementations, setting options to block on the write or + setting options for non-blocking writes are common errors. Such + implementations treat full buffer related errors as fatal. + + + +McPherson & Patel Informational [Page 11] + +RFC 4277 Experience with the BGP-4 Protocol January 2006 + + + Having recognized that full write buffers are to be expected, + additional implementation pitfalls exist. The application should not + attempt to store the TCP stream within the application itself. If + the receiver or the TCP connection is persistently slow, then the + buffer can grow until memory is exhausted. A BGP implementation is + required to send changes to all peers for which the TCP connection is + not blocked, and is required to send those changes to the remaining + peers when the connection becomes unblocked. + + If the preferred route for a given NLRI changes multiple times while + writes to one or more peers are blocked, only the most recent best + route needs to be sent. In this way, BGP is work conserving + [RFC4274]. In cases of extremely high route change, a higher volume + of route change is sent to those peers that are able to process it + more quickly; a lower volume of route change is sent to those peers + that are not able to process the changes as quickly. + + For implementations that handle differing peer capacities to absorb + route change well, if the majority of route change is contributed by + a subset of unstable NRLI, the only impact on relatively stable NRLI + that makes an isolated route change is a slower convergence, for + which convergence time remains bounded, regardless of the amount of + instability. + +14. Ordering of Path Attributes + + The BGP protocol suggests that BGP speakers sending multiple prefixes + per an UPDATE message sort and order path attributes according to + Type Codes. This would help their peers quickly identify sets of + attributes from different update messages that are semantically + different. + + Implementers may find it useful to order path attributes according to + Type Code, such that sets of attributes with identical semantics can + be more quickly identified. + +15. AS_SET Sorting + + AS_SETs are commonly used in BGP route aggregation. They reduce the + size of AS_PATH information by listing AS numbers only once, + regardless of the number of times it might appear in the process of + aggregation. AS_SETs are usually sorted in increasing order to + facilitate efficient lookups of AS numbers within them. This + optimization is optional. + + + + + + + +McPherson & Patel Informational [Page 12] + +RFC 4277 Experience with the BGP-4 Protocol January 2006 + + +16. Control Over Version Negotiation + + Because pre-BGP-4 route aggregation can't be supported by earlier + versions of BGP, an implementation that supports versions in addition + to BGP-4 should provide the version support on a per-peer basis. At + the time of this writing, all BGP speakers on the Internet are + thought to be running BGP version 4. + +17. Security Considerations + + BGP provides a flexible and extendable mechanism for authentication + and security. The mechanism allows support for schemes with various + degrees of complexity. BGP sessions are authenticated based on the + IP address of a peer. In addition, all BGP sessions are + authenticated based on the autonomous system number advertised by a + peer. + + Because BGP runs over TCP and IP, BGP's authentication scheme may be + augmented by any authentication or security mechanism provided by + either TCP or IP. + +17.1. TCP MD5 Signature Option + + [RFC2385] defines a way in which the TCP MD5 signature option can be + used to validate information transmitted between two peers. This + method prevents a third party from injecting information (e.g., a TCP + Reset) into the datastream, or modifying the routing information + carried between two BGP peers. + + At the moment, TCP MD5 is not ubiquitously deployed, especially in + inter-domain scenarios, largely because of key distribution issues. + Most key distribution mechanisms are considered to be too "heavy" at + this point. + + Many have naively assumed that an attacker must correctly guess the + exact TCP sequence number (along with the source and destination + ports and IP addresses) to inject a data segment or reset a TCP + transport connection between two BGP peers. However, recent + observation and open discussion show that the malicious data only + needs to fall within the TCP receive window, which may be quite + large, thereby significantly lowering the complexity of such an + attack. + + As such, it is recommended that the MD5 TCP Signature Option be + employed to protect BGP from session resets and malicious data + injection. + + + + + +McPherson & Patel Informational [Page 13] + +RFC 4277 Experience with the BGP-4 Protocol January 2006 + + +17.2. BGP Over IPsec + + BGP can run over IPsec, either in a tunnel or in transport mode, + where the TCP portion of the IP packet is encrypted. This not only + prevents random insertion of information into the data stream between + two BGP peers, but also prevents an attacker from learning the data + being exchanged between the peers. + + However, IPsec does offer several options for exchanging session + keys, which may be useful on inter-domain configurations. These + options are being explored in many deployments, although no + definitive solution has been reached on the issue of key exchange for + BGP in IPsec. + + Because BGP runs over TCP and IP, it should be noted that BGP is + vulnerable to the same denial of service and authentication attacks + that are present in any TCP based protocol. + +17.3. Miscellaneous + + Another routing protocol issue is providing evidence of the validity + and authority of routing information carried within the routing + system. This is currently the focus of several efforts, including + efforts to define threats that can be used against this routing + information in BGP [BGPATTACK], and efforts to develop a means of + providing validation and authority for routing information carried + within BGP [SBGP] [soBGP]. + + In addition, the Routing Protocol Security Requirements (RPSEC) + working group has been chartered, within the Routing Area of the + IETF, to discuss and assist in addressing issues surrounding routing + protocol security. Within RPSEC, this work is intended to result in + feedback to BGP4 and future protocol enhancements. + +18. PTOMAINE and GROW + + The Prefix Taxonomy (PTOMAINE) working group, recently replaced by + the Global Routing Operations (GROW) working group, is chartered to + consider and measure the problem of routing table growth, the effects + of the interactions between interior and exterior routing protocols, + and the effect of address allocation policies and practices on the + global routing system. Finally, where appropriate, GROW will also + document the operational aspects of measurement, policy, security, + and VPN infrastructures. + + GROW is currently studying the effects of route aggregation, and also + the inability to aggregate over multiple provider boundaries due to + inadequate provider coordination. + + + +McPherson & Patel Informational [Page 14] + +RFC 4277 Experience with the BGP-4 Protocol January 2006 + + + Within GROW, this work is intended to result in feedback to BGPv4 and + future protocol enhancements. + +19. Internet Routing Registries (IRRs) + + Many organizations register their routing policy and prefix + origination in the various distributed databases of the Internet + Routing Registry. These databases provide access to information + using the RPSL language, as defined in [RFC2622]. While registered + information may be maintained and correct for certain providers, the + lack of timely or correct data in the various IRR databases has + prevented wide spread use of this resource. + +20. Regional Internet Registries (RIRs) and IRRs, A Bit of History + + The NSFNET program used EGP, and then BGP, to provide external + routing information. It was the NSF policy of offering different + prices and providing different levels of support to the Research and + Education (RE) and the Commercial (CO) networks that led to BGP's + initial policy requirements. In addition to being charged more, CO + networks were not able to use the NSFNET backbone to reach other CO + networks. The rationale for higher prices was that commercial users + of the NSFNET within the business and research entities should + subsidize the RE community. Recognition that the Internet was + evolving away from a hierarchical network to a mesh of peers led to + changes away from EGP and BGP-1 that eliminated any assumptions of + hierarchy. + + Enforcement of NSF policy was accomplished through maintenance of the + NSF Policy Routing Database (PRDB). The PRDB not only contained each + networks designation as CO or RE, but also contained a list of the + preferred exit points to the NSFNET to reach each network. This was + the basis for setting what would later be called BGP LOCAL_PREF on + the NSFNET. Tools provided with the PRDB generated complete router + configurations for the NSFNET. + + Use of the PRDB had the fortunate consequence of greatly improving + reliability of the NSFNET, relative to peer networks of the time. + PRDB offered more optimal routing for those networks that were + sufficiently knowledgeable and willing to keep their entries current. + + With the decommission of the NSFNET Backbone Network Service in 1995, + it was recognized that the PRDB should be made less single provider + centric, and its legacy contents, plus any further updates, should be + made available to any provider willing to make use of it. The + European networking community had long seen the PRDB as too US- + centric. Through Reseaux IP Europeens (RIPE), the Europeans created + an open format in RIPE-181 and maintained an open database used for + + + +McPherson & Patel Informational [Page 15] + +RFC 4277 Experience with the BGP-4 Protocol January 2006 + + + address and AS registry more than policy. The initial conversion of + the PRDB was to RIPE-181 format, and tools were converted to make use + of this format. The collection of databases was termed the Internet + Routing Registry (IRR), with the RIPE database and US NSF-funded + Routing Arbitrator (RA) being the initial components of the IRR. + + A need to extend RIPE-181 was recognized and RIPE agreed to allow the + extensions to be defined within the IETF in the RPS WG, resulting in + the RPSL language. Other work products of the RPS WG provided an + authentication framework and a means to widely distribute the + database in a controlled manner and synchronize the many + repositories. Freely available tools were provided, primarily by + RIPE, Merit, and ISI, the most comprehensive set from ISI. The + efforts of the IRR participants has been severely hampered by + providers unwilling to keep information in the IRR up to date. The + larger of these providers have been vocal, claiming that the database + entry, simple as it may be, is an administrative burden, and some + acknowledge that doing so provides an advantage to competitors that + use the IRR. The result has been an erosion of the usefulness of the + IRR and an increase in vulnerability of the Internet to routing based + attacks or accidental injection of faulty routing information. + + There have been a number of cases in which accidental disruption of + Internet routing was avoided by providers using the IRR, but this was + highly detrimental to non-users. Filters have been forced to provide + less complete coverage because of the erosion of the IRR; these types + of disruptions continue to occur infrequently, but have an + increasingly widespread impact. + +21. Acknowledgements + + We would like to thank Paul Traina and Yakov Rekhter for authoring + previous versions of this document and providing valuable input on + this update. We would also like to acknowledge Curtis Villamizar for + providing both text and thorough reviews. Thanks to Russ White, + Jeffrey Haas, Sean Mentzer, Mitchell Erblich, and Jude Ballard for + supplying their usual keen eyes. + + Finally, we'd like to think the IDR WG for general and specific input + that contributed to this document. + + + + + + + + + + + +McPherson & Patel Informational [Page 16] + +RFC 4277 Experience with the BGP-4 Protocol January 2006 + + +22. References + +22.1. Normative References + + [RFC1966] Bates, T. and R. Chandra, "BGP Route Reflection An + alternative to full mesh IBGP", RFC 1966, June 1996. + + [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP + MD5 Signature Option", RFC 2385, August 1998. + + [RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route + Flap Damping", RFC 2439, November 1998. + + [RFC2796] Bates, T., Chandra, R., and E. Chen, "BGP Route + Reflection - An Alternative to Full Mesh IBGP", RFC 2796, + April 2000. + + [RFC3065] Traina, P., McPherson, D., and J. Scudder, "Autonomous + System Confederations for BGP", RFC 3065, February 2001. + + [RFC4274] Meyer, D. and K. Patel, "BGP-4 Protocol Analysis", RFC + 4274, January 2006. + + [RFC4276] Hares, S. and A. Retana, "BGP 4 Implementation Report", + RFC 4276, January 2006. + + [RFC4271] Rekhter, Y., Li, T., and S. Hares, Eds., "A Border + Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. + + [RFC1657] Willis, S., Burruss, J., Chu, J., "Definitions of Managed + Objects for the Fourth Version of the Border Gateway + Protocol (BGP-4) using SMIv2", RFC 1657, July 1994. + + [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + +22.2. Informative References + + [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 Engineering Task Force Internet + Routing Protocol Standardization Criteria", RFC 1264, + October 1991. + + + + +McPherson & Patel Informational [Page 17] + +RFC 4277 Experience with the BGP-4 Protocol January 2006 + + + [RFC1267] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol 3 + (BGP-3)", RFC 1267, October 1991. + + [RFC1269] Willis, S. and J. Burruss, "Definitions of Managed + Objects for the Border Gateway Protocol: Version 3", RFC + 1269, October 1991. + + [RFC1656] Traina, P., "BGP-4 Protocol Document Roadmap and + Implementation Experience", RFC 1656, July 1994. + + [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 + (BGP-4)", RFC 1771, March 1995. + + [RFC1773] Traina, P., "Experience with the BGP-4 protocol", RFC + 1773, March 1995. + + [RFC1965] Traina, P., "Autonomous System Confederations for BGP", + RFC 1965, June 1996. + + [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. + + [BGPATTACK] Convery, C., "An Attack Tree for the Border Gateway + Protocol", Work in Progress. + + [SBGP] "Secure BGP", Work in Progress. + + [soBGP] "Secure Origin BGP", Work in Progress. + +Authors' Addresses + + Danny McPherson + Arbor Networks + + EMail: danny@arbor.net + + + Keyur Patel + Cisco Systems + + EMail: keyupate@cisco.com + + + + + + + + +McPherson & Patel Informational [Page 18] + +RFC 4277 Experience with the BGP-4 Protocol 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). + + + + + + + +McPherson & Patel Informational [Page 19] + |