Internet Drafts
Basic BGP Convergence Benchmarking Methodology for Data Plane Convergence
BGP is widely deployed and used by several service providers as the
default Inter AS routing protocol. It is of utmost importance to
ensure that when a BGP peer or a downstream link of a BGP peer fails,
the alternate paths are rapidly used and routes via these alternate
paths are installed. This document provides the basic BGP
Benchmarking Methodology using existing BGP Convergence Terminology,
RFC 4098.
Internet Exchange Route Server
This document outlines a specification for multilateral
interconnections at Internet exchange points (IXPs). Multilateral
interconnection is a method of exchanging routing information between
three or more exterior BGP speakers using a single intermediate
broker system, referred to as a route server. Route servers are
typically used on shared access media networks, such as Internet
exchange points (IXPs), to facilitate simplified interconnection
between multiple Internet routers.
Internet Exchange Route Server Operations
The popularity of Internet exchange points (IXPs) brings new
challenges to interconnecting networks. While bilateral eBGP
sessions between exchange participants were historically the most
common means of exchanging reachability information over an IXP, the
overhead associated with this interconnection method causes serious
operational and administrative scaling problems for IXP participants.
Multilateral interconnection using Internet route servers can
dramatically reduce the administrative and operational overhead
associated with connecting to IXPs; in some cases, route servers are
used by IXP participants as their preferred means of exchanging
routing information.
This document describes operational considerations for multilateral
interconnections at IXPs.
An Overview of BGPSEC
This document provides an overview of a security extension to the
Border Gateway Protocol (BGP) referred to as BGPSEC. BGPSEC improves
security for BGP routing.
BGP Extensions for Inter-AS Traffic Engineering (TE) Link Distribution
Protocol extensions to Interial Gataway Protocols (IGPs) have been
specified for the flooding of Traffice Engineering (TE) information
of the Inter-Autonomous System (AS) links into the local AS (RFC 5392
and RFC 5316), in which some information of the inter-AS links needs
to be manually configured. This document proposes BGP extensions for
dynamic advertisement of TE information of Inter-AS links between
adjacent ASes. Such mechanism may also be used for the distribution
of Inter-AS TE link information to some external entities, such as
Path Computation Element (PCE).
Making BGP filtering a habit: Impact on policies
This document describes how unexpected traffic flows can emerge
across an autonomous system, as the result of other autonomous
systems filtering, or restricting the propagation of overlapping
prefixes. We provide a review of the techniques to detect the
occurrence of this issue and defend against it.
BGP vector routing
Network architectures have begun to shift from pure destination based
routing to service aware routing. Operator requirements in this
space include forcing traffic through particular service nodes (e.g.
firewall, NAT) or segments. This document proposes an enhancement to
BGP to accommodate these new requirements.
This document proposes a pure control plane solution which allows
traffic to be routed via an ordered set of transit points (links,
nodes, or services) on the way to traffic's destination, with no
change in the forwarding plane. This approach is in contrast to
other proposal in this space which provide similar capabilities via
modifications to the forwarding plane.
BGP Auto Discovery
This document describes a method for automating portions of a
router's BGP configuration via discovery of BGP peers with which to
establish further sessions from an initial "bootstrap" router. This
method can apply for establishment of either Internal or External BGP
peering sessions.
Methods for Detection and Mitigation of BGP Route Leaks
In [I-D.ietf-sriram-route-leak-problem-definition], the authors have
provided a definition of the route leak problem, and also enumerated
several types of route leaks. In this document, we first examine
which of those route-leak types are detected and mitigated by the
existing BGPSEC protocol [I-D.ietf-sidr-bgpsec-protocol-09]. Where
the current BGPSEC protocol doesn't offer a solution, this document
suggests an enhancement that would extend the route-leak detection
and mitigation capability of BGPSEC. The solution can be implemented
in BGP without necessarily tying it to BGPSEC. Incorporating the
solution in BGPSEC is one way of implementing it in a secure way. We
do not claim to have provided a solution for all possible types of
route leaks, but the solution covers several, especially considering
some significant route-leak attacks or occurrences that have been
observed in recent years. The document also includes a stopgap
method for detection and mitigation of route leaks for the phase when
BGPSEC (path validation) is not yet deployed but only origin
validation is deployed.
Problem Definition and Classification of BGP Route Leaks
A systemic vulnerability of the Border Gateway Protocol routing
system, known as 'route leaks', has received significant attention in
recent years. Frequent incidents that result in significant
disruptions to Internet routing are labeled "route leaks", but to
date we have lacked a common definition of the term. In this
document, we provide a working definition of route leaks, keeping in
mind the real occurrences that have received significant attention.
Further, we attempt to enumerate (though not exhaustively) different
types of route leaks based on observed events on the Internet. We
aim to provide a taxonomy that covers several forms of route leaks
that have been observed and are of concern to Internet user community
as well as the network operator community.
Enhancement to BGPSEC for Protection against Route Leaks
This document enumerates different types of route leaks based on
observed events on the Internet. It illustrates how BGPSEC in its
current form (as described in draft-ietf-sidr-bgpsec-protocol-09)
already provides protection against all but one of these route-leaks
scenarios. The document further discusses a design enhancement to
the BGPSEC protocol that will extend protection against this one
remaining type of route-leak attack as well. With the inclusion of
this enhancement, BGPSEC is expected to provide protection against
all types of route-leaks. The document also includes a stopgap
method for detection and mitigation of route leaks for the phase when
BGPSEC (path validation) is not yet deployed but only origin
validation is deployed.
RFCs
Threat Model for BGP Path Security
This document describes a threat model for the context in which
External Border Gateway Protocol (EBGP) path security mechanisms will
be developed. The threat model includes an analysis of the Resource
Public Key Infrastructure (RPKI) and focuses on the ability of an
Autonomous System (AS) to verify the authenticity of the AS path info
received in a BGP update. We use the term "PATHSEC" to refer to any
BGP path security technology that makes use of the RPKI. PATHSEC
will secure BGP, consistent with the inter-AS security focus of the
RPKI.
The document characterizes classes of potential adversaries that are
considered to be threats and examines classes of attacks that might
be launched against PATHSEC. It does not revisit attacks against
unprotected BGP, as that topic has already been addressed in the
BGP-4 standard. It concludes with a brief discussion of residual
vulnerabilities.
Security Requirements for BGP Path Validation
This document describes requirements for a BGP security protocol
design to provide cryptographic assurance that the origin Autonomous
System (AS) has the right to announce the prefix and to provide
assurance of the AS Path of the announcement.
BGP Prefix Origin Validation
To help reduce well-known threats against BGP including prefix mis-
announcing and monkey-in-the-middle attacks, one of the security
requirements is the ability to validate the origination Autonomous
System (AS) of BGP routes. More specifically, one needs to validate
that the AS number claiming to originate an address prefix (as
derived from the AS_PATH attribute of the BGP route) is in fact
authorized by the prefix holder to do so. This document describes a
simple validation mechanism to partially satisfy this requirement.
Distribution of Diverse BGP Paths
The BGP4 protocol specifies the selection and propagation of a single
best path for each prefix. As defined and widely deployed today, BGP
has no mechanisms to distribute alternate paths that are not
considered best path between its speakers. This behavior results in
a number of disadvantages for new applications and services.
The main objective of this document is to observe that by simply
adding a new session between a route reflector and its client, the
Nth best path can be distributed. This document also compares
existing solutions and proposed ideas that enable distribution of
more paths than just the best path.
This proposal does not specify any changes to the BGP protocol
definition. It does not require a software upgrade of provider edge
(PE) routers acting as route reflector clients.
Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP
This document recommends against the use of the AS_SET and
AS_CONFED_SET types of the AS_PATH in BGPv4. This is done to
simplify the design and implementation of BGP and to make the
semantics of the originator of a route more clear. This will also
simplify the design, implementation, and deployment of ongoing work
in the Secure Inter-Domain Routing Working Group.
Multi-Threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) Routing Information Export Format with Geo-Location Extensions
This document updates the Multi-threaded Routing Toolkit (MRT) export
format for Border Gateway Protocol (BGP) routing information by
extending it to include optional terrestrial coordinates of a BGP
collector and its BGP peers.
BGP Traffic Engineering Attribute
This document defines a new BGP attribute, the Traffic Engineering
attribute, that enables BGP to carry Traffic Engineering information.
The scope and applicability of this attribute currently excludes its
use for non-VPN reachability information.
Capabilities Advertisement with BGP-4
This document defines an Optional Parameter, called Capabilities,
that is expected to facilitate the introduction of new capabilities
in the Border Gateway Protocol (BGP) by providing graceful capability
advertisement without requiring that BGP peering be terminated.
Outbound Route Filtering Capability for BGP-4
This document defines a BGP-based mechanism that allows a BGP speaker
to send to its BGP peer a set of Outbound Route Filters (ORFs) that
the peer would use to constrain/filter its outbound routing updates
to the speaker.
Address-Prefix-Based Outbound Route Filter for BGP-4
This document defines a new Outbound Router Filter (ORF) type for
BGP, termed "Address Prefix Outbound Route Filter", that can be used
to perform address-prefix-based route filtering. This ORF-type
supports prefix-length- or range-based matching, wild-card-based
address prefix matching, as well as the exact address prefix matching
for address families.
Address-Prefix-Based Outbound Route Filter for BGP-4
This document defines a new Outbound Router Filter (ORF) type for
BGP, termed "Address Prefix Outbound Route Filter", that can be used
to perform address-prefix-based route filtering. This ORF-type
supports prefix-length- or range-based matching, wild-card-based
address prefix matching, as well as the exact address prefix matching
for address families.
Avoid BGP Best Path Transitions from One External to Another
In this document, we propose an extension to the BGP route selection
rules that would avoid unnecessary best path transitions between
external paths under certain conditions. The proposed extension
would help the overall network stability, and more importantly, would
eliminate certain BGP route oscillations in which more than one
external path from one BGP speaker contributes to the churn.
Multiprotocol Extensions for BGP-4
This document defines extensions to BGP-4 to enable it to carry
routing information for multiple Network Layer protocols (e.g., IPv6,
IPX, L3VPN, etc.). The extensions are backward compatible - a router
that supports the extensions can interoperate with a router that
doesn't support the extensions.
BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)
The Border Gateway Protocol (BGP) is an inter-autonomous system
routing protocol designed for TCP/IP internets. Typically, all BGP
speakers within a single AS must be fully meshed so that any external
routing information must be re-distributed to all other routers
within that Autonomous System (AS). This represents a serious
scaling problem that has been well documented with several
alternatives proposed.
This document describes the use and design of a method known as
"route reflection" to alleviate the need for "full mesh" Internal BGP
(IBGP).
BGP MULTI_EXIT_DISC (MED) Considerations
The BGP MULTI_EXIT_DISC (MED) attribute provides a mechanism for BGP
speakers to convey to an adjacent AS the optimal entry point into the
local AS. While BGP MEDs function correctly in many scenarios, a
number of issues may arise when utilizing MEDs in dynamic or complex
topologies.
This document discusses implementation and deployment considerations
regarding BGP MEDs and provides information with which implementers
and network operators should be familiar.
BGP Communities for Data Collection
BGP communities (RFC 1997) are used by service providers for many
purposes, including tagging of customer, peer, and geographically
originated routes. Such tagging is typically used to control the
scope of redistribution of routes within a provider's network and to
its peers and customers. With the advent of large-scale BGP data
collection (and associated research), it has become clear that the
information carried in such communities is essential for a deeper
understanding of the global routing system. This memo defines
standard (outbound) communities and their encodings for export to BGP
route collectors.
BGP Extended Communities Attribute
This document describes the "extended community" BGP-4 attribute.
This attribute provides a mechanism for labeling information carried
in BGP-4. These labels can be used to control the distribution of
this information, or for other applications.
BGP-4 Protocol Analysis
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.
BGP Security Vulnerabilities Analysis
Border Gateway Protocol 4 (BGP-4), along with a host of other
infrastructure protocols designed before the Internet environment
became perilous, was originally designed with little consideration
for protection of the information it carries. There are no
mechanisms internal to BGP that protect against attacks that modify,
delete, forge, or replay data, any of which has the potential to
disrupt overall network routing behavior.
This document discusses some of the security issues with BGP routing
data dissemination. This document does not discuss security issues
with forwarding of packets.
A Border Gateway Protocol 4 (BGP-4)
This document discusses the Border Gateway Protocol (BGP), which is
an inter-Autonomous System routing protocol.
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 for constructing a graph of AS
connectivity for this reachability from which routing loops may be
pruned, and, at the AS level, some policy decisions may be enforced.
BGP-4 provides a set of mechanisms for supporting Classless Inter-
Domain Routing (CIDR). These mechanisms include support for
advertising a set of destinations as an IP prefix, and eliminating
the concept of network "class" within BGP. BGP-4 also introduces
mechanisms that allow aggregation of routes, including aggregation of
AS paths.
BGP Wedgies
It has commonly been assumed that the Border Gateway Protocol (BGP)
is a tool for distributing reachability information in a manner that
creates forwarding paths in a deterministic manner. In this memo we
will describe a class of BGP configurations for which there is more
than one potential outcome, and where forwarding states other than
the intended state are equally stable. Also, the stable state where
BGP converges may be selected by BGP in a non-deterministic manner.
These stable, but unintended, BGP states are termed here "BGP
Wedgies".
Configuring BGP to Block Denial-of-Service Attacks
This document describes an operational technique that uses BGP
communities to remotely trigger black-holing of a particular
destination network to block denial-of-service attacks. Black-holing
can be applied on a selection of routers rather than all BGP-speaking
routers in the network. The document also describes a sinkhole
tunnel technique using BGP communities and tunnels to pull traffic
into a sinkhole router for analysis.
Border Gateway Protocol (BGP) Persistent Route Oscillation Condition
In particular configurations, the BGP scaling mechanisms defined in
"BGP Route Reflection - An Alternative to Full Mesh IBGP" and
"Autonomous System Confederations for BGP" will introduce persistent
BGP route oscillation. This document discusses the two types of
persistent route oscillation that have been identified, describes
when these conditions will occur, and provides some network design
guidelines to avoid introducing such occurrences.
BGP Route Flap Damping
A usage of the BGP routing protocol is described which is capable of
reducing the routing traffic passed on to routing peers and therefore
the load on these peers without adversely affecting route convergence
time for relatively stable routes. This technique has been
implemented in commercial products supporting BGP. The technique is
also applicable to IDRP.
The overall goals are:
o to provide a mechanism capable of reducing router processing load
caused by instability
o in doing so prevent sustained routing oscillations
o to do so without sacrificing route convergence time for generally
well behaved routes.
This must be accomplished keeping other goals of BGP in mind:
o pack changes into a small number of updates
o preserve consistent routing
o minimal addition space and computational overhead
An excessive rate of update to the advertised reachability of a
subset of Internet prefixes has been widespread in the Internet.
This observation was made in the early 1990s by many people involved
in Internet operations and remains the case. These excessive updates
are not necessarily periodic so route oscillation would be a
misleading term. The informal term used to describe this effect is
"route flap". The techniques described here are now widely deployed
and are commonly referred to as "route flap damping".
Protection of BGP Sessions via the TCP MD5 Signature Option
This memo describes a TCP extension to enhance security for BGP. It
defines a new TCP option for carrying an MD5 [RFC1321] digest in a
TCP segment. This digest acts like a signature for that segment,
incorporating information known only to the connection end points.
Since BGP uses TCP as its transport, using this option in the way
described in this paper significantly reduces the danger from certain
security attacks on BGP.
A Unified Approach to Inter-Domain Routing
This memo is an informational RFC which outlines one potential
approach for inter-domain routing in future global internets. The
focus is on scalability to very large networks and functionality, as
well as scalability, to support routing in an environment of
heterogeneous services, requirements, and route selection criteria.
Note: The work of D. Estrin and S. Hotz was supported by the National
Science Foundation under contract number NCR-9011279, with matching
funds from GTE Laboratories. The work of Y. Rekhter was supported by
the Defense Advanced Research Projects Agency, under contract
DABT63-91-C-0019. Views and conclusions expressed in this paper are
not necessarily those of the Defense Advanced Research Projects
Agency and National Science Foundation.
Border Gateway Protocol 3 (BGP-3)
This memo, together with its companion document, "Application of the
Border Gateway Protocol in the Internet", define an inter-autonomous
system routing protocol for the Internet. This RFC specifies an IAB
standards track protocol for the Internet community, and requests
discussion and suggestions for improvements. Please refer to the
current edition of the "IAB Official Protocol Standards" for the
standardization state and status of this protocol. Distribution of
this memo is unlimited.
Border Gateway Protocol (BGP)
This RFC, together with its companion RFC-1164, "Application of the
Border Gateway Protocol in the Internet", define a Proposed Standard
for an inter-autonomous system routing protocol for the Internet.
This protocol, like any other at this initial stage, may undergo
modifications before reaching full Internet Standard status as a
result of deployment experience. Implementers are encouraged to
track the progress of this or any protocol as it moves through the
standardization process, and to report their own experience with the
protocol.
This protocol is being considered by the Interconnectivity Working
Group (IWG) of the Internet Engineering Task Force (IETF).
Information about the progress of BGP can be monitored and/or
reported on the IWG mailing list (IWG@nri.reston.va.us).
Please refer to the latest edition of the "IAB Official Protocol
Standards" RFC for current information on the state and status of
standard Internet protocols.
