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.
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
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.
[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.
[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
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).