RFC 8893

Resource Public Key Infrastructure (RPKI) Origin Validation for BGP Export 🦋✨

okay bestie, this one is about BGP 🌐, the protocol that tells the whole internet where to send packets. Quick title-block tea ☕: this is RFC 8893, published in September 2020 🌸. It's a Standards Track document from the IETF (the consensus crew 🫶), written by Randy Bush (Internet Initiative Japan & Arrcus), Rüdiger Volk, and Jakob Heitz (Cisco) 💜. It updates RFC 6811 🔥 and doesn't obsolete anything, so no drama there 💅.

---

1. Introduction 🎀

okay so a BGP speaker can run RPKI origin validation 🔐 not just on routes it gets from neighbors (or redistributes from other routing protocols), but also on routes it sends out to neighbors 📤. That's the egress side, and it's giving main character energy 👑.

The thing that matters here is the effective origin AS 🧚, which is the Route Origin Autonomous System Number [RFC6811] of the UPDATE that's about to be sent to neighboring BGP speakers. The effective origin AS is decided by configuration and outbound policy, so it can get changed by stuff like removing private ASes, confederation [RFC5065], migration [RFC7705], and other knobs. 🙈

This doc does not change the protocol or semantics of [RFC6811] 🙅‍♀️. It just highlights a super important use case in external BGP (eBGP) egress policies and explains how to implement it correctly 💖.

A validating BGP speaker MUST apply Route Origin Validation policy semantics (see Section 2 of [RFC6811] and Section 4 of [RFC8481]) after applying any egress configuration and policy 🫶. And any AS_PATH modifications that change the effective origin AS MUST be taken into account 📝.

So this document updates [RFC6811] by making it clear that implementations must use the effective origin AS to figure out the Origin Validation state when applying egress policy 🌈. Lowkey a big clarification 😭.

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 📚.

2. Suggested Reading 📖

okay, the reader is assumed to already get BGP [RFC4271], the RPKI [RFC6480], Route Origin Authorizations (ROAs) [RFC6482], RPKI-based Prefix Validation [RFC6811], and Origin Validation Clarifications [RFC8481] 🧠. If you're new, go read those first bestie 🍓.

3. Egress Processing 🚀

BGP implementations that support RPKI-based origin validation MUST provide the same policy configuration primitives for decisions based on the validation state. Those primitives need to be usable in ingress, redistribution, and egress policies 🔁. When it's applied to egress policy, the validation state MUST be determined using the effective origin AS of the route as it will (or would) be announced to the peer 🎯.

The effective origin AS can be different from the route's origin in the RIB 🤯, thanks to things like private AS removal, AS path manipulation, confederation handling, and so on.

Egress policy handling can give you more robust protection for outbound eBGP than just relying on ingress redistribution (iBGP, eBGP, connected, static, etc.) being set up and working correctly 🛡️. It's better support for the robustness principle 💅 (this is the part I'm obsessed with ngl 🙈).

4. Operational Considerations 🛠️

Configs can get super complex, and sometimes the effective origin AS can't be easily figured out until the outbound policies have run 🌀. So it SHOULD be possible to specify a selective origin validation policy that gets applied after any existing non-validating outbound policies 🎀.

An implementation SHOULD be able to list announcements that weren't sent to a peer (for example, because they were marked Invalid) 📋, as long as the router still has them in memory 🧚.

5. Security Considerations 🔐

okay this is the serious bit, so listen up 👂✨. This document doesn't create any security considerations beyond the ones in [RFC6811] and [RFC8481] 🔒. What it does do is facilitate more correct validation, which helps improve BGP reliability 💜.

6. IANA Considerations 🌸

This document has no IANA actions. Nothing to register, bestie 💅.

7. References 📚

7.1. Normative References 💖

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
           Border Gateway Protocol 4 (BGP-4)", RFC 4271,
           DOI 10.17487/RFC4271, January 2006,
           <https://www.rfc-editor.org/info/rfc4271>.

[RFC5065]  Traina, P., McPherson, D., and J. Scudder, "Autonomous
           System Confederations for BGP", RFC 5065,
           DOI 10.17487/RFC5065, August 2007,
           <https://www.rfc-editor.org/info/rfc5065>.

[RFC6482]  Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
           Origin Authorizations (ROAs)", RFC 6482,
           DOI 10.17487/RFC6482, February 2012,
           <https://www.rfc-editor.org/info/rfc6482>.

[RFC6811]  Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
           Austein, "BGP Prefix Origin Validation", RFC 6811,
           DOI 10.17487/RFC6811, January 2013,
           <https://www.rfc-editor.org/info/rfc6811>.

[RFC7705]  George, W. and S. Amante, "Autonomous System Migration
           Mechanisms and Their Effects on the BGP AS_PATH
           Attribute", RFC 7705, DOI 10.17487/RFC7705, November 2015,
           <https://www.rfc-editor.org/info/rfc7705>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8481]  Bush, R., "Clarifications to BGP Origin Validation Based
           on Resource Public Key Infrastructure (RPKI)", RFC 8481,
           DOI 10.17487/RFC8481, September 2018,
           <https://www.rfc-editor.org/info/rfc8481>.

7.2. Informative References 🦋

[RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
           Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
           February 2012, <https://www.rfc-editor.org/info/rfc6480>.

Acknowledgments 🫶

Thanks to Linda Dunbar, Nick Hilliard, Benjamin Kaduk, Chris Morrow, Keyur Patel, Alvaro Retana, Job Snijders, Robert Sparks, and Robert Wilton for the reviews and comments 💕.

Authors' Addresses 💌

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

Email: randy@psg.com


Rüdiger Volk

Email: ietf@rewvolk.de


Jakob Heitz
Cisco
170 West Tasman Drive
San Jose, CA 95134
United States of America

Email: jheitz@cisco.com

---

That's the whole spec, bestie 🎀✨. The vibes are immaculate and the facts are untouched 💅🌈.