implementations treat full buffer related errors as fatal.
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.
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.
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.
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
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.
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.
[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
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).