RFC 8481

Clarifications to BGP Origin Validation Based on Resource Public Key Infrastructure (RPKI)

📅 published September 2018, from ietf

RFC 8481: Clarifications to BGP Origin Validation Based on Resource Public Key Infrastructure (RPKI) ✨

Bestie, this one is a clarification doc, and it's giving "we fixed the vibes before they got messy" 🎀

Who wrote it: Randy Bush, from Internet Initiative Japan 🌸 Stream: IETF 🦋 Category: Standards Track 💜 Date: September 2018 📅 Updates: RFC 6811 🔧 ISSN: 2070-1721 🧚

Abstract 💖

okay so, rolling out BGP origin validation based on RPKI is being slowed down by vendors implementing it differently in two key spots: which routes get validated, and whether policy gets applied when the configuration never asked for it. This doc clears up the confusion behind those mismatches. It updates RFC 6811 by making clear that all prefixes should have their validation state set, and that policy must not be applied without operator configuration. 💅

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 went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 7841. 📚

You can find the current status, any errata, and how to send feedback at https://www.rfc-editor.org/info/rfc8481. 🔗

Copyright (c) 2018 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 (https://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License. ⚖️

Table of Contents 🗺️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
3.  Suggested Reading . . . . . . . . . . . . . . . . . . . . . .   3
4.  Evaluate ALL Prefixes . . . . . . . . . . . . . . . . . . . .   3
5.  Set State, Don't Act  . . . . . . . . . . . . . . . . . . . .   4
6.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
8.  Normative References  . . . . . . . . . . . . . . . . . . . .   4
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   5
Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

1. Introduction 🌸

So deploying RPKI-based BGP origin validation is getting held up by vendors misimplementing it in two critical areas: which routes are validated, and whether policy is applied when the configuration never specified it. This doc is here to clear up the possible misunderstandings causing those mismatches. 💅

When a route gets distributed into BGP, its origin validation state is set to NotFound, Valid, or Invalid, per [RFC6811]. Operational testing showed that the specs in that RFC weren't enough to stop implementations from diverging. This document tries to clarify two areas that seem to be causing the confusion. ✨

The implementation problems don't really seem to be about how to validate, meaning how to decide if a route is NotFound, Valid, or Invalid. The actual questions are which routes should be evaluated and have their evaluation state set, and whether to apply policy without operator configuration. 🤔

2. Requirements Language 🔑

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 🧚

3. Suggested Reading 📚

It's assumed you already get BGP [RFC4271], the RPKI [RFC6480], Route Origin Authorizations (ROAs) [RFC6482], and RPKI-based Prefix Validation [RFC6811]. No pressure, but these are the good reads. 💜

4. Evaluate ALL Prefixes 🔥

Significant Clarification: A router MUST evaluate and set the validation state of all routes in BGP coming from any source (e.g., eBGP, iBGP, or redistribution from static or connected routes), unless specifically configured otherwise by the operator.

Here's why this matters, bestie. If the router doesn't do this, the operator can't drop Invalid routes coming from every possible source. That leaves them open to complaints from neighbors about Invalid routes getting propagated. 😭 So [RFC6811] says:

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.

[RFC6811] goes on to say, "An implementation MAY provide configuration options to control which routes the lookup is applied to." 🎀

When you redistribute into BGP from any source (e.g., IGP, iBGP, or from static or connected routes), the input has no AS_PATH, so there's nothing to let you do RPKI validation of the originating Autonomous System (AS). 🫶 In those cases, the router MUST use the AS from the router's BGP configuration. If that's ambiguous because of confederation, AS migration, or other multi-AS configuration, then the router configuration MUST provide a means of specifying the AS to be used on the redistribution, either per redistribution or globally. 👑

5. Set State, Don't Act 💅

Significant Clarification: Once routes are evaluated and have their state set, the operator should be in complete control of any policy applied based on the evaluation state. Absent specific operator configuration, policy MUST NOT be applied.

Automatic origin validation policy actions, like the ones described in "BGP Prefix Origin Validation State Extended Community" [RFC8097], MUST NOT be carried out or otherwise applied unless the operator specifically configures them. 🙅‍♀️ The operator is the one in charge here, always. 💖

6. Security Considerations 💀

This document doesn't create any security considerations beyond the ones in [RFC6811]. 🔐

7. IANA Considerations 🧚

This document has no IANA actions. ✨

8. Normative References 📚

Acknowledgments 🫶

Huge thanks to John Scudder, who was patient enough to give constructive review multiple times, and to Keyur Patel, who noticed the AS might have to be specified. George Michaelson, Jay Borkenhagen, John Heasley, and Matthias Waehlisch kindly helped tidy up the loose wording. 🌈

Author's Address 🦋

Randy Bush Internet Initiative Japan 5147 Crystal Springs Bainbridge Island, Washington 98110 United States of America

Email: randy@psg.com 💌

📦 where this page comes from