Considerations in Validating the Path in BGP
RFC 5123

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 09

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 the