Considerations in Validating the Path in BGP
RFC 5123
Document | Type | RFC - Informational (February 2008; Errata) | |
---|---|---|---|
Authors | Russ White , Bora Akyol | ||
Last updated | 2020-01-21 | ||
Stream | Independent Submission | ||
Formats | plain text html pdf htmlized (tools) htmlized with errata bibtex | ||
Stream | ISE state | (None) | |
Consensus Boilerplate | Unknown | ||
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5123 (Informational) | |
Action Holders |
(None)
|
||
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 1.2. Is the Path Contained in the Advertised Routing Information Valid? If a BGP speaker receives an advertisement from a peer outside theShow full document text