Considerations in Validating the Path in BGP
RFC 5123
|
| Document |
Type |
|
RFC - Informational
(February 2008; Errata)
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
ISE
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
ISE state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 5123 (Informational)
|
|
Telechat date |
|
|
|
Responsible AD |
|
Alex Zinin
|
|
Send notices to |
|
(None)
|
Network Working Group R. White
Request for Comments: 5123 B. Akyol
Category: Informational Cisco Systems
February 2008
Considerations in Validating the Path in BGP
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.
IESG Note
After consultation with the RPSEC WG, the IESG thinks that this work
is related to IETF work done in WG RPSEC, but this does not prevent
publishing.
This RFC is not a candidate for any level of Internet Standard. The
IETF disclaims any knowledge of the fitness of this RFC for any
purpose and in particular notes that the decision to publish is not
based on IETF review for such things as security, congestion control,
or inappropriate interaction with deployed protocols. The RFC Editor
has chosen to publish this document at its discretion. Readers of
this document should exercise caution in evaluating its value for
implementation and deployment. See RFC 3932 for more information.
Abstract
This document examines the implications of hop-by-hop forwarding,
route aggregation, and route filtering on the concept of validation
within a BGP Autonomous System (AS) Path.
1. Background
A good deal of thought has gone into, and is currently being given
to, validating the path to a destination advertised by BGP. The
purpose of this work is to explain the issues in validating a BGP AS
Path, in the expectation that it will help in the evaluation of
schemes seeking to improve path validation. The first section
defines at least some of the types of questions a BGP speaker
receiving an update from a peer not in the local autonomous system
(AS) could ask about the information within the routing update. The
following sections examine the answers to these questions in
consideration of specific deployments of BGP.
White & Akyol Informational [Page 1]
RFC 5123 Path Validation Considerations February 2008
The examples given in this document are intended to distill
deployments down to their most critical components, making the
examples easier to understand and consider. In many situations, the
specific path taken in the example may not be relevant, but that does
not nullify the principles considered in each example. It has been
suggested that these examples are "red herrings", because they do not
illustrate actual problems with specific policies. On the contrary,
these examples are powerful because they are simple. Any topology in
which one of these example topologies is a subtopology will exhibit
the characteristics explained in this document. Rather than focusing
on a specific topology, then dismissing that single topology as a
"corner case", this document shows the basic issues with assertions
about the AS Path attribute within BGP. These generalized issues can
then be applied to more specific cases.
With the heightened interest in network security, the security of the
information carried within routing systems running BGP, as described
in [RFC4271], is being looked at with great interest. While there
are techniques available for securing the relationship between two
devices exchanging routing protocol information, such as [BGP-MD5],
these techniques do not ensure various aspects of the information
carried within routing protocols are valid or authorized.
The following small internetwork is used to examine the concepts of
validity and authorization within this document, providing
definitions used through the remainder of the document.
10.1.1.0/24--(AS65000)---(AS65001)--(AS65002)
Assume a BGP speaker in AS65002 has received an advertisement for
10.1.1.0/24 from a BGP speaker in AS65001, with an AS Path of {65000,
65001}.
1.1. Is the Originating AS Authorized to Advertise Reachability to the
Destination?
The most obvious question the receiving BGP speaker can ask about
this advertisement is whether or not the originating AS, in this case
AS65000, is authorized to advertise the prefix contained within the
advertisement, in this case 10.1.1.0/24. Whether or not a BGP
speaker receiving a route to 10.1.1.0/24 originating in AS65000 can
verify that AS65000 is, indeed, authorized to advertise 10.1.1.0/24
is outside the scope of this document.
White & Akyol Informational [Page 2]
RFC 5123 Path Validation Considerations February 2008
Show full document text