characteristic of the Internet in terms of the routing space is the
increasing number of distinct route policies that are associated with
each multi-homed network within the Internet.
One way to limit the proliferation of such policies across the entire
inter-domain space is to associate attributes to such advertisements
that specify the conditions whereby a remote transit AS may proxy-
aggregate this route object with other route objects.
7.5 Extend or Replace BGP
A final consideration is to consider whether these requirements can
best be met by an approach of a set of upward-compatible extensions
to BGP, or by a replacement to BGP. No recommendation is made here,
and this is a topic requiring further investigation.
The general approach in extending BGP appears to lie in increasing
the number of supported transitive route attributes, allowing the
route originator greater control in specifying the scope of
propagation of the route and the intended outcome in terms of policy
and traffic engineering. It may also be necessary to allow BGP
sessions to negotiate additional functionality intended to improve
the convergence behavior of the protocol. Whether such changes can
produce a scalable and useful outcome in terms of inter-domain
routing remains, at this stage, an open question.
An alternative approach is that of a replacement protocol, and such
an approach may well be based on the adoption of a link-state
behavior. The issues of policy opaqueness and link-state protocols
have been described above. The other major issue with such an
approach is the need to limit the extent of link state flooding,
where the inter-domain space would need some further levels of
imposed structure similar to intra-domain areas. Such structure may
well imply the need for an additional set of operator inter-
relationships such as mutual transit, and this may prove challenging
to adapt to existing practices.
The potential sets of actions include more than extend or replace the
BGP protocol. A third approach is to continue to use BGP as the
basic means of propagating route objects and their associated AS
paths and other attributes, and use one or more overlay protocols to
support inter-domain traffic engineering and other forms of inter-
domain policy negotiation. This approach would appear to offer a
means of transition for the large installed base currently using BGP4
as their inter-domain routing protocol, placing additional
functionality in the overlay protocols while leaving the basic
functionality of BGP4 intact. The resultant inter-dependencies
between BGP and the overlay protocols would require very careful
attention, as this would be the most critical aspect of such an
approach.
8. Directions for Further Activity
While there may exist short term actions based on providing various
incentives for network operators to remove redundant or inefficiently
grouped entries from the BGP routing table, such actions are short
term palliative measures, and will not provide long term answers to
the need to a scalable inter-domain routing protocol.
One potential short term protocol refinement is to allow a set of
grouped advertisements to be aggregated into a single route
advertisement. This form of proxy aggregation would take a set of
bit-wise aligned routing entries with matching route attributes, and
under certain well identified circumstances, aggregate these routing
entries into a single re-advertised aggregate routing entry. This
technique removes information from the routing system, and some care
must be taken to define a set of proxy aggregation conditions that do
not materially alter the flow of traffic, or the ability of
originating ASes to announce routing policy.
A further refinement to this approach is to consider the definition
of the syntax and semantics of a number of additional route
attributes. Such attributes could define the extent to which
specific route advertisements should be propagated in the inter-
domain space, allowing the advertisement to be subsumed by a larger
aggregate advertisement at the boundary of this domain. This could
be used to form part of the preconditions of automated proxy
aggregation of specific routes, and also limit the extent to which
announcement and withdrawals are propagated across the routing
domain.
It is unclear that such measures would result in substantial longer
term changes to the scaling and convergence properties of BGP4.
Taking the requirement set enumerated in section 6 of this document,
one approach to the longer term requirements may be to preserve a
number of attributes of the current BGP protocol, while refine other
aspects of the protocol to improve its scaling and convergence
properties. A minimal set of alterations could retain the Autonomous
System concept to allow for boundaries of information summarization,
as well as retaining the approach of associating each prefix
advertisement with an originating AS. The concept of policy
opaqueness would also be retained in such an approach, implying that
each AS accepts a set of route advertisements, applies local policy
constraints, and re-advertises those advertisements permitted by the
local policy constraints. It could be feasible to consider
alterations to the distance vector path selection algorithm,
particularly as it relates to intermediate states during processing
of a route withdrawal. It is also feasible to consider the use of
compound route attributes, allowing a route object to include an
aggregate route, and a number of specifics of the aggregate route,
and attach attributes that may apply to the aggregate or a specific
address prefix. Such route attributes could be used to support
multi-homing and inter-domain traffic engineering mechanisms. The
overall intent of this approach is to address the major requirements
in the inter-domain routing space without using an increasing set of
globally propagated specific route objects.
A potential applied research topic is to consider the feasibility of
de-coupling the requirements of inter-domain connectivity management
with the applications of policy constraints and the issues of sender-
and/or receiver-managed traffic engineering requirements. Such an
approach may use a link-state protocol as a means of maintaining a
consistent view of the topology of inter-domain network, and then use
some form of overlay protocol to negotiate policy requirements of
each AS, and use a further overlay to support inter-domain traffic
engineering requirements. The underlying assumption of such an
approach is that by dividing up the functional role of inter-domain
routing into distinct components each component will have superior
scaling and convergence properties which in turn to result in
superior properties for the entire routing system. Obviously, this
assumption requires some testing.
Research topics with potential longer term application include the
approach of drawing a distinction between a network's identity, a
network's location relative to other networks, and a feasible path
between a source and destination network that satisfies various
policy and traffic engineering constraints. Again the intent of such
an approach would be to divide the current routing function into a
number of distinct scalable components.
9. Security Considerations
Any adopted inter-domain routing protocol needs to be secure against
disruption. Disruption comes from two primary sources:
- Accidental misconfiguration
- Malicious attacks
Given past experience with routing protocols, both can be significant
sources of harm.
Given that it is not reasonable to guarantee the security of all the
routers involved in the global Internet inter-domain routing system,
there is also every reason to believe that malicious attacks may come
from peer routers, in addition to coming from external sources.
A protocol design should therefore consider how to minimize the
damage to the overall routing computation that can be caused by a
single or small set of misbehaving routers.
The routing system itself needs to be resilient against accidental or
malicious advertisements of a route object by a route server not
entitled to generate such an advertisement. This implies several
things, including the need for cryptographic validation of
announcements, cryptographic protection of various critical routing
messages and an accurate and trusted database of routing assignments
via which authorization can be checked.
10. References
[1] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC2026, October 1996.
[2] Clark, D., Chapin, L., Cerf, V., Braden, R. and R. Hobby,
"Towards the Future Internet Architecture", RFC1287, December
1991.
[3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification, RFC2460, December 1998.
[4] Srisuresh, P. and K. Egevang, "Traditional IP Network Address
Translator (Traditional NAT)", RFC3022, January 2001.
[5] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless Inter-
Domain Routing (CIDR): an Address Assignment and Aggregation
Strategy", RFC1519, September 1993.
[6] Huston, G., "The BGP Routing Table", The Internet Protocol
Journal, vol. 4, No. 1, March 2001.
[7] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC1771, March 1995.
[8] Vohara, Q. and E. Chen, "BGP support for four-octet AS number
space", Work in Progress.
[9] Hain, T., "Architectural Implications of NAT", RFC2993,
November 2000.
[10] Labovitz, C., Ahuja, A., Bose, A. and J. Jahanian, "Delayed
Internet Routing Convergence", Proceedings ACM SIGCOMM 2000,
August 2000.
[11] Lothberg, P., personal communication, December 2000.
11. Acknowledgements
This document is the outcome of a collaborative effort of the IAB,
and the editor acknowledges the contributions of the members of the
IAB in the preparation of the document. The contributions of John
Leslie, Thomas Narten and Abha Ahuja in reviewing this document are
also acknowledged.
12. Author
Internet Architecture Board
Email: iab@ietf.org
Geoff Huston
Telstra
5/490 Northbourne Ave
Dickson ACT 2602
Australia
EMail: gih@telstra.net
13. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.