RFC 6811

BGP Prefix Origin Validation

📅 published January 2013, from ietf

RFC 6811: BGP Prefix Origin Validation 💖

Okay bestie, this is RFC 6811, a Standards Track doc published in January 2013 📅 with ISSN 2070-1721. Five authors wrote it: P. Mohapatra and D. Ward from Cisco Systems, J. Scudder from Juniper Networks, R. Bush from Internet Initiative Japan, and R. Austein from Dragon Research Labs 👑. The title block doesn't list any RFCs it obsoletes or updates 🧚.

Abstract 🌸

So BGP has some well-known threats, like prefix mis-announcing and monkey-in-the-middle attacks 😭, and one of the big security requirements for dealing with them is being able to validate the origination Autonomous System (AS) of BGP routes. Basically, you need to check that the AS number claiming to originate a prefix (derived from the AS_PATH attribute of the BGP route) is actually authorized by the prefix holder to do so 🫶. This doc describes a simple validation mechanism that only partially covers that requirement 💅.

Status of This Memo ✨

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6811.

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents 🦋

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
  1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 4
2.  Prefix-to-AS Mapping Database . . . . . . . . . . . . . . . . . 4
  2.1.  Pseudo-Code . . . . . . . . . . . . . . . . . . . . . . . . 6
3.  Policy Control  . . . . . . . . . . . . . . . . . . . . . . . . 6
4.  Interaction with Local Cache  . . . . . . . . . . . . . . . . . 7
5.  Deployment Considerations . . . . . . . . . . . . . . . . . . . 7
6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
  8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
  8.2.  Informational References  . . . . . . . . . . . . . . . . . 9

1. Introduction ✨

A BGP route links an address prefix to a set of Autonomous Systems (ASes) that show the interdomain path the prefix has taken through BGP announcements. This set is stored in the AS_PATH attribute in BGP [RFC4271], and it starts with the AS that originated the prefix 🌈. Those well-known BGP threats, like prefix mis-announcing and monkey-in-the-middle attacks, are the reason one of the security requirements is being able to validate the origination AS of BGP routes. More specifically, you need to check that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is actually authorized by the prefix holder to do so. This document describes a simple validation mechanism that only partially satisfies this requirement 💖.

The Resource Public Key Infrastructure (RPKI) is an approach for building a formally verifiable database of IP addresses and AS numbers as resources 🔥. Its overall architecture, defined in [RFC6480], has three main components:

  • a public key infrastructure (PKI) with the necessary certificate objects,
  • digitally signed routing objects, and
  • a distributed repository system to hold the objects that would also support periodic retrieval.

The RPKI system is built on resource certificates, which define extensions to X.509 to represent IP addresses and AS identifiers [RFC3779]. That's where the name RPKI comes from 🧚. Route Origin Authorizations (ROAs) [RFC6482] are separate digitally signed objects that define associations between ASes and IP address blocks. Last but not least, the repository system is operated in a distributed fashion through the IANA, Regional Internet Registry (RIR) hierarchy, and ISPs 🎀.

To benefit from the RPKI system, it's envisioned that relying parties, at either the AS or organization level, obtain a local copy of the signed object collection, verify the signatures, and process them. The cache must also be refreshed periodically. The exact access mechanism used to retrieve the local cache is beyond the scope of this document 🙈.

Individual BGP speakers can use the processed data in the local cache to validate BGP announcements. The protocol details for getting that processed data from the local cache to the BGP speakers are beyond the scope of this document (refer to [RFC6810] for such a mechanism). This document proposes a way for a BGP speaker to use the processed data so it can assign a "validation state" to each prefix in a received BGP UPDATE message 🍓.

Note that checking the complete path attestation against the AS_PATH attribute of a route is outside the scope of this document 💅.

Like the DNS, the global RPKI presents only a loosely consistent view, depending on timing, updating, fetching, and so on. So one cache or router may have different data about a particular prefix than another cache or router. There's no 'fix' for this; it's just the nature of distributed data with distributed caches 😭.

Although RPKI provides the context for this document, it's equally possible to use any other database that can map prefixes to their authorized origin ASes. Each distinct database will have its own operational and security characteristics, and those characteristics are beyond the scope of this document 👑.

1.1. Requirements Language 💜

Okay, so the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" get interpreted as described in RFC 2119 [RFC2119], but only when they appear in all upper case. They can also show up in lower or mixed case as plain English words with no special meaning 🫶.

2. Prefix-to-AS Mapping Database 🎀

The BGP speaker loads validated objects from the cache into local storage. The objects that get loaded have the content (IP address, prefix length, maximum length, origin AS number). We call this locally stored object a "Validated ROA Payload" or "VRP" 🦋.

We define a few more terms besides "VRP." When these terms are used, they're capitalized:

  • Prefix: (IP address, prefix length), interpreted as is customary (see [RFC4632]).
  • Route: Data derived from a received BGP UPDATE, as defined in [RFC4271], Section 1.1. The Route includes one Prefix and an AS_PATH. It may include other attributes to characterize the prefix ✨.
  • VRP Prefix: The Prefix from a VRP.
  • VRP ASN: The origin AS number from a VRP.
  • Route Prefix: The Prefix derived from a route.
  • Route Origin ASN: The origin AS number derived from a Route as follows:
    • the rightmost AS in the final segment of the AS_PATH attribute in the Route if that segment is of type AS_SEQUENCE, or
    • the BGP speaker's own AS number if that segment is of type AS_CONFED_SEQUENCE or AS_CONFED_SET or if the AS_PATH is empty, or
    • the distinguished value "NONE" if the final segment of the AS_PATH attribute is of any other type.
  • Covered: A Route Prefix is said to be Covered by a VRP when the VRP prefix length is less than or equal to the Route prefix length, and the VRP prefix address and the Route prefix address are identical for all bits specified by the VRP prefix length. (That is, the Route prefix is either identical to the VRP prefix or more specific than the VRP prefix.) 🌸
  • Matched: A Route Prefix is said to be Matched by a VRP when the Route Prefix is Covered by that VRP, the Route prefix length is less than or equal to the VRP maximum length, and the Route Origin ASN is equal to the VRP ASN 💖.

Given these definitions, any given BGP Route will be found to have one of the following validation states:

  • NotFound: No VRP Covers the Route Prefix.
  • Valid: At least one VRP Matches the Route Prefix.
  • Invalid: At least one VRP Covers the Route Prefix, but no VRP Matches it.

We observe that no VRP can have the value "NONE" as its VRP ASN. So a Route whose Origin ASN is "NONE" can't be Matched by any VRP. Similarly, no valid Route can have an Origin ASN of zero [AS0]. So no Route can be Matched by a VRP whose ASN is zero 🙈.

When a BGP speaker receives an UPDATE from a neighbor, it SHOULD perform a lookup as described above for each of the Routes in the UPDATE message. The lookup SHOULD also be applied to routes that are redistributed into BGP from another source, such as another protocol or a locally defined static route. An implementation MAY provide configuration options to control which routes the lookup is applied to. The validation state of the Route MUST be set to reflect the result of the lookup. The implementation should consider the validation state as described in the document as a local property or attribute of the Route. If validation is not performed on a Route, the implementation SHOULD initialize the validation state of such a route to "NotFound" 🔥.

Use of the validation state is discussed in Sections 3 and 5. An implementation MUST NOT exclude a route from the Adj-RIB-In or from consideration in the decision process as a side effect of its validation state, unless it's explicitly configured to do so 👑.

We observe that a Route can be Matched or Covered by more than one VRP. This procedure doesn't mandate an order in which VRPs must be visited. However, the validation state output is fully determined 🌈.

2.1. Pseudo-Code 💅

okay so bestie, here's the pseudo-code that shows the procedure above in action 🧚 but if the code and the procedure ever seem to disagree, the procedure above is the one to trust, not the code 🫶

result = BGP_PFXV_STATE_NOT_FOUND;

//Iterate through all the Covering entries in the local VRP
//database, pfx_validate_table.
entry = next_lookup_result(pfx_validate_table, route_prefix);

while (entry != NULL) {
  prefix_exists = TRUE;

  if (route_prefix_length <= entry->max_length) {
    if (route_origin_as != NONE
        && entry->origin_as != 0
        && route_origin_as == entry->origin_as) {
      result = BGP_PFXV_STATE_VALID;
      return (result);
    }
  }
  entry = next_lookup_result(pfx_validate_table, input.prefix);
}

//If one or more VRP entries Covered the route prefix, but
//none Matched, return "Invalid" validation state.
if (prefix_exists == TRUE) {
  result = BGP_PFXV_STATE_INVALID;
}

return (result);

3. Policy Control ⭐

okay this part is about policy, and it's giving "you need the controls" 🎛️ every implementation MUST provide a way to match and set the validation state of routes as part of its route policy filtering function 💖 Section 5 explains how validation state gets used in policy, and if you want the operational policy side, check out [ORIGIN-OPS] 📖

and it MUST also support four-octet AS numbers [RFC6793] 🔥 no skipping that one, periodt 💅

4. Interaction with Local Cache 🦋

so every BGP speaker that does prefix validation (the way this document describes) is expected to talk to one or more RPKI caches 🌸 each cache keeps its own local copy of the global RPKI database. the protocol mechanisms for gathering, validating, and handing that data over to BGP speakers are described in [RFC6810] ✨

the prefix-to-AS mappings a BGP speaker uses are expected to change over time 🌈 when a mapping gets added or deleted, the implementation MUST re-validate any affected prefixes, and run the BGP decision process if it's needed 🫶 an "affected prefix" is any prefix that was matched by a deleted or updated mapping, or that could be matched by an added or updated mapping 🍓

5. Deployment Considerations 💜

once a Route gets selected for validation, it's categorized using the procedure in Section 2 🎀 after that, routing policy (from Section 3) can take action based on the validation state ✨

some policies you could totally implement: filtering routes based on validation state (like rejecting all "invalid" routes) 🙅‍♀️ or adjusting a route's degree of preference in the selection algorithm based on its validation state 💅 the second one could be done by tweaking attributes like LOCAL_PREF 👑 considering invalid routes in the BGP decision process is a purely local policy matter, and it should be done with utmost care 🥹

the bit about IBGP is important, so read it twice 💀

in some cases, especially when the selection algorithm is influenced by changing a route property that doesn't get propagated into Internal BGP (IBGP), it could be necessary for routing correctness to pass the validation state along to the IBGP peer 🧚 this can be done on the sending side by setting a community or extended community based on the validation state, and on the receiving side by matching that (extended) community and setting the validation state 🦋

6. Security Considerations 🚨

okay this section is SERIOUS bestie, so grab your snacks 🍿 even though this specification talks about just one piece of a system for validating BGP routes, it should be noted that it relies on a database (RPKI or other) to provide validation information 😭 that means the security properties of that database must be considered to figure out how secure the overall solution actually is 🔐

if "invalid" routes get blocked the way this specification suggests, the overall system becomes a possible denial-of-service vector 💀 for example, if an attacker is able to inject (or remove) one or more records into (or from) the validation database, they could make an otherwise valid route get marked as invalid 🙈

also, this system is only able to give limited protection against a determined attacker 😤 the attacker just needs to prepend the "valid" source AS to a forged BGP route announcement, and that's enough to get around the protection this system provides 💔

this mechanism does not protect against "AS-in-the-middle attacks" and doesn't provide any path validation ❌ it only attempts to verify the origin 🫠 overall, this system should be thought of more as a protection against misconfiguration than as true "security" in the strong sense 🧸

7. Acknowledgments 🫶

the authors want to thank Rex Fernando, Hannes Gredler, Mouhcine Guennoun, Russ Housley, Junaid Israr, Miya Kohno, Shin Miyakawa, Taka Mizuguchi, Hussein Mouftah, Keyur Patel, Tomoya Yoshida, Kannan Varadhan, Wes George, Jay Borkenhagen, and Sandra Murphy 💖 they're also grateful for the feedback from the members of the SIDR working group 🌟

Junaid Israr's contribution to this specification was part of his PhD research work and thesis at University of Ottawa 🎓👑

8. References 📚

8.1. Normative References 🔒

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.
  • [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
  • [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.
  • [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012.
  • [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, December 2012.

8.2. Informational References 🌷

  • [AS0] Kumari, W., Bush, R., Schiller, H., and K. Patel, "Codification of AS 0 processing.", Work in Progress, August 2012.
  • [ORIGIN-OPS] Bush, R., "RPKI-Based Origin Validation Operation", Work in Progress, August 2012.
  • [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.
  • [RFC6810] Bush, R. and R. Austein, "The RPKI/Router Protocol", RFC 6810, January 2013.

Authors' Addresses 🦋

Pradosh Mohapatra
Cisco Systems
170 W. Tasman Drive
San Jose, CA  95134
USA

EMail: pmohapat@cisco.com


John Scudder
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA  94089
USA

EMail: jgs@juniper.net


David Ward
Cisco Systems
170 W. Tasman Drive
San Jose, CA  95134
USA

EMail: dward@cisco.com


Randy Bush
Internet Initiative Japan
5147 Crystal Springs
Bainbridge Island, WA  98110
USA

EMail: randy@psg.com


Rob Austein
Dragon Research Labs

EMail: sra@hactrn.net

that's the whole RFC, bestie! 🌈✨💖

📦 where this page comes from