RFC 6810
The Resource Public Key Infrastructure (RPKI) to Router Protocol
The Resource Public Key Infrastructure (RPKI) to Router Protocol 💖
Okay bestie, let's get into RFC 6810 🦋 It's a Standards Track document, so it's the real deal, and it was published in January 2013 🎀 The authors are R. Bush from Internet Initiative Japan and R. Austein from Dragon Research Labs ✨ It's also tagged with ISSN 2070-1721 🌸 The title block doesn't say it obsoletes or updates anything, so this is a fresh start 💅
Abstract ✨
Routers need to check which Autonomous System is really allowed to originate a BGP announcement, and to do that verifiably, they need a simple but reliable way to get Resource Public Key Infrastructure (RFC 6480) prefix origin data from a trusted cache 🔐 This document describes a protocol for delivering that validated prefix origin data to routers 🚀
Status of This Memo 📜
This is an Internet Standards Track document 🌈
It's a product of the Internet Engineering Task Force (IETF), so it reflects what the IETF community agreed on 🫶 It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check out Section 2 of RFC 5741 📚
Want the current status, any errata, or a way to send feedback? Head to http://www.rfc-editor.org/info/rfc6810 💌
Copyright Notice ©️
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) as they're in effect on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 🙈 Any Code Components pulled out of this document have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 🍓
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Deployment Structure . . . . . . . . . . . . . . . . . . . . . 4
4. Operational Overview . . . . . . . . . . . . . . . . . . . . . 4
5. Protocol Data Units (PDUs) . . . . . . . . . . . . . . . . . . 6
5.1. Fields of a PDU . . . . . . . . . . . . . . . . . . . . . 6
5.2. Serial Notify . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Serial Query . . . . . . . . . . . . . . . . . . . . . . . 8
5.4. Reset Query . . . . . . . . . . . . . . . . . . . . . . . 9
5.5. Cache Response . . . . . . . . . . . . . . . . . . . . . . 9
5.6. IPv4 Prefix . . . . . . . . . . . . . . . . . . . . . . . 10
5.7. IPv6 Prefix . . . . . . . . . . . . . . . . . . . . . . . 11
5.8. End of Data . . . . . . . . . . . . . . . . . . . . . . . 12
5.9. Cache Reset . . . . . . . . . . . . . . . . . . . . . . . 12
5.10. Error Report . . . . . . . . . . . . . . . . . . . . . . . 12
6. Protocol Sequences . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Start or Restart . . . . . . . . . . . . . . . . . . . . . 14
6.2. Typical Exchange . . . . . . . . . . . . . . . . . . . . . 15
6.3. No Incremental Update Available . . . . . . . . . . . . . 15
6.4. Cache Has No Data Available . . . . . . . . . . . . . . . 16
7. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. SSH Transport . . . . . . . . . . . . . . . . . . . . . . 18
7.2. TLS Transport . . . . . . . . . . . . . . . . . . . . . . 18
7.3. TCP MD5 Transport . . . . . . . . . . . . . . . . . . . . 19
7.4. TCP-AO Transport . . . . . . . . . . . . . . . . . . . . . 19
8. Router-Cache Setup . . . . . . . . . . . . . . . . . . . . . . 20
9. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 21
10. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 22
11. Security Considerations . . . . . . . . . . . . . . . . . . . 23
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
14.1. Normative References . . . . . . . . . . . . . . . . . . . 25
14.2. Informative References . . . . . . . . . . . . . . . . . . 261. Introduction 🌸
Okay so, the whole point here is verifiably validating the origin Autonomous Systems (ASes) of BGP announcements 🔍 Routers need a simple but reliable way to receive Resource Public Key Infrastructure (RPKI) [RFC6480] data that's been cryptographically validated, straight from a trusted cache 🔐 This document describes a protocol that delivers that validated prefix origin data to routers. And the design is intentionally constrained so it can run on a lot of the ISP router platforms that exist right now 🫶
Here's the tour 🗺️ Section 3 covers the deployment structure, and Section 4 gives you the operational overview. The binary payloads are formally described in Section 5, and the expected PDU sequences are in Section 6. Section 7 has the transport options, and Section 8 explains how routers and caches get configured to connect and authenticate. Section 9 walks through likely deployment scenarios, and the traditional security and IANA considerations wrap things up 🎀
The protocol is extensible, so new PDUs with new semantics can be added if deployment experience shows they're needed 🦋 PDUs are versioned too, in case deployment experience calls for a change 🌈
For an implementation report (not an interoperability report), see [RTR-IMPL] 📝
1.1. Requirements Language 💅
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] only when they appear in all upper case 🧚 When they show up in lower or mixed case, they're just regular English words with no special meaning 💜
2. Glossary 📖
These terms have a special meaning in this document ✨
Global RPKI: The authoritative RPKI data is published across a distributed set of servers at the IANA, the Regional Internet Registries (RIRs), the National Internet Registries (NIRs), and ISPs. See [RFC6481] 🌍
Cache: A coalesced copy of the RPKI. It's periodically fetched or refreshed, directly or indirectly, from the Global RPKI using the [RFC5781] protocol and tools. Relying party software gathers and validates the distributed RPKI data into a cache. How far you trust that cache is a matter between the cache's provider and the relying party 🔐
Serial Number: A 32-bit, strictly increasing unsigned integer that wraps from 2^32-1 back to 0 🔢 It denotes the logical version of a cache. A cache increments the value when it successfully updates its data from a parent cache or from primary RPKI data. While a cache is receiving, the new incoming data and implicit deletes get associated with the new serial, but they MUST NOT be sent until the fetch is complete ⚠️ A Serial Number isn't commensurate between caches, and it doesn't need to be maintained across resets of the cache server. For way too much detail on the topic, see [RFC1982] on DNS Serial Number Arithmetic 🤓
Session ID: When a cache server starts, it generates a session identifier. This uniquely identifies that cache instance and binds it to the sequence of Serial Numbers that the instance will generate 🪪 This lets a router restart a failed session knowing the Serial Number it's using matches the cache's 🫶
3. Deployment Structure 🏗️
Getting the RPKI out to routers has a three-level structure 🪜
Global RPKI: The authoritative RPKI data is published across a distributed set of servers, which are RPKI publication repositories. Examples include the IANA, the RIRs, the NIRs, and ISPs. See [RFC6481] 🌐
Local Caches: A local set of one or more collected and verified caches. A relying party (a router or some other client) MUST have a trust relationship with any authoritative cache it uses, and it MUST also have a trusted transport channel to that cache 🔒
Routers: A router fetches data from a local cache using the protocol described in this document, which makes it a client of that cache 🧸 There MAY be mechanisms that let the router verify the cache is authentic, and that let the router authenticate itself to the cache 🦋
4. Operational Overview 🔭
A router sets up and keeps open a connection to one or more caches it has client/server relationships with 🤝 It's configured with a semi-ordered list of caches, and it connects to the most preferred cache, or set of caches, that accept the connection 💖
The router MUST choose the most preferred cache or set of caches, based on configuration, so the operator can control the load on their caches and on the Global RPKI 🎛️
Every so often, the router sends the cache the Serial Number of the highest-numbered data it has received from that cache. That's its current Serial Number 🔁 When a router sets up a new connection to a cache, or wants to reset an existing relationship, it sends a Reset Query 🔄
The cache responds with all the data records that have Serial Numbers greater than the one in the router's query 📦 That could be the null set, in which case the End of Data PDU still gets sent 🌙 Heads up: 'greater' has to account for wrap-around, so check [RFC1982] for the details ⚠️
Once the router has received all the data records from the cache, it sets its current Serial Number to the Serial Number in the End of Data PDU 🏁
When the cache updates its database, it sends a Notify message to every router that's currently connected 🔔 This is only a hint that now might be a good time for the router to poll for an update. It's just a hint, though, and the protocol requires the router to poll for updates periodically anyway 🫧
Technically, a router could track a cache by asking for a complete data set every single time it updates, but that would be super inefficient 😩 The Serial Number based incremental update mechanism gives an efficient transfer of just the data records that changed since the last update 🚀 With any update protocol built on incremental transfers, the router must be ready to fall back to a full transfer if the cache can't provide the needed incremental data for any reason 🛟 Unlike some incremental transfer protocols, this one requires the router to explicitly request the fallback. That's on purpose, because the cache has no way of knowing whether the router has also set up sessions with other caches that might give better service 🧠
Cache servers have to evaluate certificates and ROAs (Route Origin Attestations; see [RFC6480]), and those are time dependent, so servers' clocks MUST be correct to within a tolerance of approximately an hour ⏰
5. Protocol Data Units (PDUs) 📨
The exchanges between the cache and the router are sequences of the following PDUs, following the rules in Section 6 🔗
Fields with unspecified content MUST be zero on transmission and MAY be ignored on receipt 🧼
5.1. Fields of a PDU
okay so PDUs are packed with these data elements, bestie 💅
Protocol Version: An eight-bit unsigned integer, currently 0, that tells you the version of this protocol. 🎀
PDU Type: An eight-bit unsigned integer that says what kind of PDU it is, like IPv4 Prefix, etc. 🦋
Serial Number: The Serial Number of the RPKI Cache when this set of PDUs got received from an upstream cache server or gathered from the Global RPKI. A cache bumps its Serial Number when it finishes a rigorously validated update from a parent cache or the Global RPKI. 🔥
Session ID: When a cache server starts up, it generates a Session ID to identify that instance of the cache and lock it to the sequence of Serial Numbers that instance is going to generate. ✨ This lets the router restart a failed session knowing the Serial Number it's using lines up with the cache. If, at any time, either the router or the cache sees that the session identifier isn't the same as the other's, they MUST completely drop the session, and the router MUST flush all data learned from that cache. 🚨
Should a cache accidentally reuse a Session ID so the router doesn't realize the session changed (old and new Session IDs have the same numeric value), the router may get confused about what the cache has. How long it takes the router to notice depends on whether the Serial Numbers got reused too. If the Serial Numbers in the old and new sessions are different enough, the cache will answer the router's Serial Query with a Cache Reset, and that solves the problem. 💖 But if the Serial Numbers are close together, the cache may answer with a Cache Response, which might not be enough to bring the router back in sync. In those cases it's likely but not certain that the router spots some mismatch between what the cache expects and what the router actually holds. For example, the Cache Response might tell the router to drop a record it doesn't have, or to add a record it already has. In those cases the router will catch the error and reset the session. 🙈 The one time the router might stay out of sync is when nothing in the Cache Response contradicts any data the router is already holding.
Using persistent storage for the session identifier, or a clock-based scheme for generating session identifiers, should avoid the risk of session identifier collisions. 🌸
The Session ID might be a pseudo-random value, a strictly increasing value if the cache has reliable storage, etc. 🧚
Length: A 32-bit unsigned integer whose value is the count of the bytes in the entire PDU, including the eight bytes of header that end with the length field. 📏
Flags: The lowest order bit of the Flags field is 1 for an announcement and 0 for a withdrawal, depending on whether this PDU announces a new right to announce the prefix or withdraws a previously announced right. A withdraw effectively deletes one previously announced IPvX (IPv4 or IPv6) Prefix PDU with the exact same Prefix, Length, Max-Len, and Autonomous System Number (ASN). 💅
Prefix Length: An 8-bit unsigned integer denoting the shortest prefix allowed for the prefix. 🌈
Max Length: An 8-bit unsigned integer denoting the longest prefix allowed by the prefix. This MUST NOT be less than the Prefix Length element. 😭
Prefix: The IPv4 or IPv6 prefix of the ROA. 🍓
Autonomous System Number: The ASN allowed to announce this prefix, a 32-bit unsigned integer. 👑
Zero: Fields shown as zero or reserved MUST be zero. The value of such a field MUST be ignored on receipt. 💀
5.2. Serial Notify
the cache pings the router to say it has fresh data. 📣
The Session ID reassures the router that the Serial Numbers are commensurate, aka the cache session hasn't been changed. 🫶
Serial Notify is the only message the cache can send that isn't a reply to something the router asked for. It's giving unprompted main character energy 🦋
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| 0 | 0 | |
+-------------------------------------------+
| |
| Length=12 |
| |
+-------------------------------------------+
| |
| Serial Number |
| |
`-------------------------------------------'5.3. Serial Query
Serial Query: the router sends this to ask the cache for all payload PDUs with Serial Numbers higher than the Serial Number in the Serial Query. It's basically the router saying "what did I miss?" 🌸
The cache replies to this query with a Cache Response PDU (Section 5.5) if it has a, possibly null, record of the changes since the Serial Number the router gave. If nothing has changed since the router last asked, the cache sends an End Of Data PDU. 💖
If the cache doesn't have the data needed to update the router, maybe because its records don't go back to the Serial Number in the Serial Query, then it responds with a Cache Reset PDU (Section 5.9). 🔥
The Session ID tells the cache which instance the router expects, so the Serial Numbers can be confirmed as commensurate, aka the cache session hasn't changed. ✨
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| 0 | 1 | |
+-------------------------------------------+
| |
| Length=12 |
| |
+-------------------------------------------+
| |
| Serial Number |
| |
`-------------------------------------------'5.4. Reset Query
Reset Query: the router tells the cache it wants the whole total active, current, non-withdrawn database. The fresh start era 🧹 The cache answers with a Cache Response PDU (Section 5.5). 🎀
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | reserved = zero |
| 0 | 2 | |
+-------------------------------------------+
| |
| Length=8 |
| |
`-------------------------------------------'5.5. Cache Response
Cache Response: the cache responds with zero or more payload PDUs. When it's replying to a Serial Query (Section 5.3), the cache sends every data record it has with Serial Numbers greater than the one the client router sent. When it's replying to a Reset Query, the cache sends every data record it has. In that case, the withdraw/announce field in the payload PDUs MUST have the value 1 (announce). 🦋
In response to a Reset Query, the new Session ID tells the router which instance of the cache session to confirm against in the future. 🫶 In response to a Serial Query, the Session ID being the same reassures the router that the Serial Numbers are commensurate, aka the cache session hasn't changed. 💅
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| 0 | 3 | |
+-------------------------------------------+
| |
| Length=8 |
| |
`-------------------------------------------'5.6. IPv4 Prefix
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | reserved = zero |
| 0 | 4 | |
+-------------------------------------------+
| |
| Length=20 |
| |
+-------------------------------------------+
| | Prefix | Max | |
| Flags | Length | Length | zero |
| | 0..32 | 0..32 | |
+-------------------------------------------+
| |
| IPv4 Prefix |
| |
+-------------------------------------------+
| |
| Autonomous System Number |
| |
`-------------------------------------------'The lowest order bit of the Flags field is 1 for an announcement and 0 for a withdrawal. 🌈
In the RPKI, nothing stops a signing certificate from issuing two identical ROAs. In that case there's no semantic difference between the objects, just process redundancy. 🙈
In the RPKI there's also a real need for what might look like identical IPvX PDUs to a router. This can happen when an upstream certificate is being reissued, or when address ownership transfers up the validation chain. The ROA would be identical in the router sense, aka it has the same {Prefix, Len, Max-Len, ASN}, but it has a different validation path in the RPKI. This matters to the RPKI, but not to the router. 🧚
The cache server MUST ensure that it has told the router client to have one and only one IPvX PDU for a unique {Prefix, Len, Max-Len, ASN} at any one point in time. Should the router client receive an IPvX PDU with a {Prefix, Len, Max-Len, ASN} identical to one it already has active, it SHOULD raise a Duplicate Announcement Received error. 😭
5.7. IPv6 Prefix 🧚
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | reserved = zero |
| 0 | 6 | |
+-------------------------------------------+
| |
| Length=32 |
| |
+-------------------------------------------+
| | Prefix | Max | |
| Flags | Length | Length | zero |
| | 0..128 | 0..128 | |
+-------------------------------------------+
| |
+--- ---+
| |
+--- IPv6 Prefix ---+
| |
+--- ---+
| |
+-------------------------------------------+
| |
| Autonomous System Number |
| |
`-------------------------------------------'This is basically the IPv4 Prefix PDU's glow-up: same energy, but with 96 more bits and still no magic 💅✨
5.8. End of Data 💌
End of Data is the cache basically saying "bestie, that's all I've got for you" 🫶 The cache tells the router it has no more data for the request.
The Session ID MUST match the one on the Cache Response that kicked off the sequence of data PDUs. That sequence might be totally empty (the "possibly null" part 🙈), but the ID still has to line up.
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| 0 | 7 | |
+-------------------------------------------+
| |
| Length=12 |
| |
+-------------------------------------------+
| |
| Serial Number |
| |
`-------------------------------------------'5.9. Cache Reset 🔄
Okay so the cache can answer a Serial Query with a Cache Reset to say "sorry hun, I can't do an incremental update from the Serial Number you gave me" 💔 The router must decide whether to issue a Reset Query or switch to a different cache. No cap, it's a big decision moment.
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | reserved = zero |
| 0 | 8 | |
+-------------------------------------------+
| |
| Length=8 |
| |
`-------------------------------------------'5.10. Error Report 🚨
This PDU is the drama-alert button 💀 Either party can use it to report an error to the other.
Error reports are only sent as responses to other PDUs. No random unprompted tea ☕
The Error Code is described in Section 10.
Say the error is a generic oops, like "Internal Error", and it isn't tied to the PDU it's replying to. Then the Erroneous PDU field MUST be empty and the Length of Encapsulated PDU field MUST be zero. Nothing to copy, nothing to show 🙈
An Error Report PDU MUST NOT be sent for an Error Report PDU. Ever. If an erroneous Error Report PDU is received, the session SHOULD be dropped. Yikes, we do not do error loops here 🫠
If the error is tied to a PDU of excessive length (too long to be any legal PDU other than another Error Report), or a possibly corrupt length, the Erroneous PDU field MAY be truncated. Kinda like cutting the story short so nobody gets overwhelmed 💅
The diagnostic text is optional. If it's not there, the Length of Error Text field MUST be zero. If error text is there, it MUST be a string in UTF-8 encoding (see [RFC3269]). Tea must be properly encoded, periodt ✨
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Error Code |
| 0 | 10 | |
+-------------------------------------------+
| |
| Length |
| |
+-------------------------------------------+
| |
| Length of Encapsulated PDU |
| |
+-------------------------------------------+
| |
~ Copy of Erroneous PDU ~
| |
+-------------------------------------------+
| |
| Length of Error Text |
| |
+-------------------------------------------+
| |
| Arbitrary Text |
| of |
~ Error Diagnostic Message ~
| |
`-------------------------------------------'6. Protocol Sequences 🎬
PDU transmissions come in three main conversations, and they go like this:
6.1. Start or Restart 🌸
Cache Router
~ ~
| <----- Reset Query -------- | R requests data (or Serial Query)
| |
| ----- Cache Response -----> | C confirms request
| ------- IPvX Prefix ------> | C sends zero or more
| ------- IPvX Prefix ------> | IPv4 and IPv6 Prefix
| ------- IPvX Prefix ------> | Payload PDUs
| ------ End of Data ------> | C sends End of Data
| | and sends new serial
~ ~When a transport session is first established, the router MAY send a Reset Query, and then the cache responds with a data sequence of all the data it has. Main character entrance 👑
Alternatively, if the router has significant unexpired data from a broken session with the same cache, it MAY start with a Serial Query containing the Session ID from the previous session. That's how it makes sure the Serial Numbers are commensurate 🤓
This Reset Query sequence also shows up when the router gets a Cache Reset, picks a new cache, or fears that it has otherwise lost its way. Relatable 😭
To limit how long a cache has to keep the data it needs for incremental updates, a router MUST send either a Serial Query or a Reset Query no less frequently than once an hour. This also doubles as a keep-alive at the application layer 💜
As the cache MAY not keep updates for little more than one hour, the router MUST have a polling interval of no greater than once an hour. Set your alarm, bestie ⏰
6.2. Typical Exchange 🦋
Cache Router
~ ~
| -------- Notify ----------> | (optional)
| |
| <----- Serial Query ------- | R requests data
| |
| ----- Cache Response -----> | C confirms request
| ------- IPvX Prefix ------> | C sends zero or more
| ------- IPvX Prefix ------> | IPv4 and IPv6 Prefix
| ------- IPvX Prefix ------> | Payload PDUs
| ------ End of Data ------> | C sends End of Data
| | and sends new serial
~ ~The cache server SHOULD send a notify PDU with its current Serial Number whenever the cache's serial changes. The idea is that the router MAY then issue a Serial Query earlier than it otherwise might, like a little heads-up text 📱 This is analogous to DNS NOTIFY in [RFC1996]. The cache MUST rate limit Serial Notifies to no more frequently than one per minute. Nobody likes a spammer 🙅♀️
When the transport layer is up and either a timer has gone off in the router, or the cache has sent a Notify, the router queries for new data by sending a Serial Query. Then the cache sends all data newer than the serial in that Serial Query. Simple, clean, iconic ✨
To limit how long a cache has to keep old withdraws, a router MUST send either a Serial Query or a Reset Query no less frequently than once an hour. Consistency is the whole vibe 💅
6.3. No Incremental Update Available 💔
Cache Router
~ ~
| <----- Serial Query ------ | R requests data
| ------- Cache Reset ------> | C cannot supply update
| | from specified serial
| <------ Reset Query ------- | R requests new data
| ----- Cache Response -----> | C confirms request
| ------- IPvX Prefix ------> | C sends zero or more
| ------- IPvX Prefix ------> | IPv4 and IPv6 Prefix
| ------- IPvX Prefix ------> | Payload PDUs
| ------ End of Data ------> | C sends End of Data
| | and sends new serial
~ ~The cache may respond to a Serial Query with a Cache Reset, telling the router that it can't supply an incremental update from the Serial Number the router asked for. This might be because the cache has lost state. It might also be because the router waited too long between polls and the cache cleaned up old data it no longer thinks it needs. Or the cache might have run out of storage space and had to expire some old data early 🥲 Regardless of how the state got this way, the cache replies with a Cache Reset to say it can't honor the request.
When a router gets this, it SHOULD attempt to connect to any more preferred caches in its cache list. If there are no more preferred caches, it MUST issue a Reset Query and get an entire new load from the cache. Fresh start, new era 🌈
6.4. Cache Has No Data Available 🫥
Cache Router
~ ~
| <----- Serial Query ------ | R requests data
| ---- Error Report PDU ----> | C No Data Available
~ ~Cache Router
~ ~
| <----- Reset Query ------- | R requests data
| ---- Error Report PDU ----> | C No Data Available
~ ~The cache may respond to either a Serial Query or a Reset Query, informing the router that it can't supply any update at all. The most likely cause is that the cache has lost state, maybe because it restarted, and hasn't recovered yet. It's possible for a cache to get into this state without dropping any of its active sessions. But a router is more likely to see this when it first connects and sends a Reset Query while the cache is still rebuilding its database 🛠️
When a router gets this kind of error, it SHOULD attempt to connect to any other caches in its cache list, in preference order. If no other caches are available, the router MUST issue periodic Reset Queries until it gets a new usable load from the cache. Keep knocking, it'll open 🚪🫶
7. Transport ✨
okay so the transport-layer session between a router and a cache is where the binary PDUs live, all chilling inside one persistent session 💅
real talk, it is highly desirable that the router and the cache authenticate each other 🫶 that stops cache spoofing and DoS attacks from illegitimate routers 🙅. integrity protection for payloads is also desirable so nobody can pull off a monkey-in-the-middle (MITM) attack 😭. unfortunately there's no protocol for that on all the platforms in use right now 💀. so as of writing, there is no mandatory-to-implement transport that gives you both authentication and integrity protection. the vibe is rough rn.
to lower the risk of sessions that drop without terminating, caches and routers SHOULD enable keep-alives whenever the chosen transport protocol has them 🌸
it's expected that once the TCP Authentication Option (TCP-AO) [RFC5925] is available on all the platforms operators deploy, it will become the mandatory-to-implement transport 👑
caches and routers MUST implement unprotected transport over TCP using a port, rpki-rtr (323); see Section 12 🎀. operators SHOULD use procedural means, like access control lists (ACLs), to reduce exposure to authentication issues 🧚
caches and routers SHOULD use TCP-AO, SSHv2, TCP MD5, or IPsec transport ✨
if unprotected TCP is the transport, the cache and routers MUST be on the same trusted and controlled network 🙈
if it's available to the operator, caches and routers MUST use one of the following more protected protocols 🔥
- caches and routers SHOULD use TCP-AO transport [RFC5925] over the
rpki-rtrport. - caches and routers MAY use SSHv2 transport [RFC4252] over the normal SSH port. for an example, see Section 7.1 🌈
- caches and routers MAY use TCP MD5 transport [RFC2385] over the
rpki-rtrport. note that TCP MD5 has been obsoleted by TCP-AO [RFC5925] 💀 - caches and routers MAY use IPsec transport [RFC4301] over the
rpki-rtrport. - caches and routers MAY use TLS transport [RFC5246] using a port,
rpki-rtr-tls (324); see Section 12.
7.1. SSH Transport
to run over SSH, the client router first sets up an SSH transport connection using SSHv2, and the client and server exchange keys for message integrity and encryption 🔐. then the client invokes the ssh-userauth service to authenticate the application, as described in the SSH authentication protocol [RFC4252] 🪪. once the application is authenticated, the client invokes the ssh-connection service, also known as the SSH connection protocol.
once the ssh-connection service is up, the client opens a channel of type session, which results in an SSH session 🎬
once the SSH session exists, the application invokes the application transport as an SSH subsystem called rpki-rtr. subsystem support is a feature of SSH version 2 (SSHv2) and is not included in SSHv1. running this protocol as an SSH subsystem means the application doesn't have to recognize shell prompts or skip over extra junk, like a system message that gets sent at shell start-up 🙌
it's assumed that the router and cache exchanged keys out of band by some reasonably secured means 🗝️
cache servers supporting SSH transport MUST accept RSA and Digital Signature Algorithm (DSA) authentication and SHOULD accept Elliptic Curve Digital Signature Algorithm (ECDSA) authentication. user authentication MUST be supported; host authentication MAY be supported. implementations MAY support password authentication. client routers SHOULD verify the public key of the cache to avoid monkey-in-the-middle attacks 🛡️
7.2. TLS Transport
client routers using TLS transport MUST present client-side certificates to authenticate themselves to the cache, so the cache can manage load by rejecting connections from unauthorized routers 🚫. in principle, any type of certificate and certificate authority (CA) may be used. but in general, cache operators will wish to create their own small-scale CA and issue certificates to each authorized router. this makes credential rollover simpler: any unrevoked, unexpired certificate from the proper CA may be used 🎟️
certificates used to authenticate client routers in this protocol MUST include a subjectAltName extension [RFC5280] containing one or more iPAddress identities. when authenticating the router's certificate, the cache MUST check the IP address of the TLS connection against these iPAddress identities and SHOULD reject the connection if none of the iPAddress identities match 📍
routers MUST also verify the cache's TLS server certificate, using subjectAltName dNSName identities as described in [RFC6125], to avoid monkey-in-the-middle attacks 🕵️. the rules and guidelines defined in [RFC6125] apply here, with the following considerations:
- support for the DNS-ID identifier type (that is, the dNSName identity in the subjectAltName extension) is REQUIRED in rpki-rtr server and client implementations that use TLS. certification authorities that issue rpki-rtr server certificates MUST support the DNS-ID identifier type, and the DNS-ID identifier type MUST be present in rpki-rtr server certificates 🪄
- DNS names in rpki-rtr server certificates SHOULD NOT contain the wildcard character "*" 🙅♀️
- rpki-rtr implementations that use TLS MUST NOT use CN-ID identifiers. a CN field may be present in the server certificate's subject name, but it MUST NOT be used for authentication within the rules described in [RFC6125] 💅
- the client router MUST set its "reference identifier" to the DNS name of the rpki-rtr cache 🎯
7.3. TCP MD5 Transport
if TCP MD5 is used, implementations MUST support key lengths of at least 80 printable ASCII bytes, per Section 4.5 of [RFC2385]. implementations MUST also support hexadecimal sequences of at least 32 characters, i.e., 128 bits 🔑
key rollover with TCP MD5 is problematic 😩. cache servers SHOULD support [RFC4808].
7.4. TCP-AO Transport
implementations MUST support key lengths of at least 80 printable ASCII bytes. implementations MUST also support hexadecimal sequences of at least 32 characters, i.e., 128 bits. MAC (Message Authentication Code) lengths of at least 96 bits MUST be supported, per Section 5.1 of [RFC5925] 🔐✨
the cryptographic algorithms and associated parameters described in [RFC5926] MUST be supported 🧁
8. Router-Cache Setup 🌷
a cache has the public authentication data for each router it is configured to support 🗂️
a router may be configured to peer with a selection of caches, and a cache may be configured to support a selection of routers. each must have the name of, and authentication data for, each peer. also, in a router, this list has a non-unique preference value for each server. this preference just denotes proximity, not trust, preferred belief, etc. 📶 the client router tries to establish a session with each potential serving cache in preference order, then starts loading data from the most preferred cache it can connect to and authenticate. the router's list of caches has the following elements:
- Preference: an unsigned integer denoting the router's preference to connect to that cache; the lower the value, the more preferred.
- Name: the IP address or fully qualified domain name of the cache.
- Key: any needed public key of the cache.
- MyKey: any needed private key or certificate of this client.
due to the distributed nature of the RPKI, caches simply cannot be rigorously synchronous 🌐. a client may hold data from multiple caches, but it MUST keep the data marked as to source, since later updates MUST affect the correct data 🏷️
just like there may be more than one covering ROA from a single cache, there may be multiple covering ROAs from multiple caches. the results are as described in [RFC6811] 🧩
if data from multiple caches is held, implementations MUST NOT distinguish between data sources when performing validation 🙅
when a more preferred cache becomes available, if resources allow, it would be prudent for the client to start fetching from that cache 🚀
the client SHOULD attempt to maintain at least one set of data, whether or not it has chosen a different cache or set up a new connection to the previous cache 💾
a client MAY drop the data from a particular cache when it is fully in sync with one or more other caches 🫧
a client SHOULD delete the data from a cache when it has been unable to refresh from that cache for a configurable timer value. the default for that value is twice the polling period for that cache ⏰
if a client loses connectivity to a cache it is using, or otherwise decides to switch to a new cache, it SHOULD retain the data from the previous cache until it has a full set of data from one or more other caches. note that this may already be true at the point of connection loss if the client has connections to more than one cache 🥹
9. Deployment Scenarios 🏡
for illustration, we present three likely deployment scenarios 🎨
- Small End Site: the small multihomed end site may wish to outsource the RPKI cache to one or more of its upstream ISPs. they would exchange authentication material with the ISP using some out-of-band mechanism, and their router(s) would connect to the cache(s) of one or more upstream ISPs. the ISPs would likely deploy caches intended for customer use separately from the caches their own BGP speakers peer with 🧁
- Large End Site: a larger multihomed end site might run one or more caches, arranging them in a hierarchy of client caches, each fetching from a serving cache that is closer to the Global RPKI. they might configure fall-back peerings to upstream ISP caches 🏗️
- ISP Backbone: a large ISP would likely have one or more redundant caches in each major point of presence (PoP), and these caches would fetch from each other in an ISP-dependent topology so as not to place undue load on the Global RPKI 🌍
experience with large DNS cache deployments has shown that complex topologies are ill-advised, since it's easy to make errors in the graph, e.g., to not maintain a loop-free condition 🌀
of course, these are illustrations, and there are other possible deployment strategies 💜. it is expected that minimizing load on the Global RPKI servers will be a major consideration 🫶
to keep load on Global RPKI services from unnecessary peaks, it is recommended that primary caches that load from the distributed Global RPKI not all do so at the same times, e.g., on the hour. choose a random time, perhaps the ISP's AS number modulo 60, and jitter the inter-fetch timing ⏳✨
10. Error Codes ✨
okay so this section is a preliminary list of error codes 🍓 The authors expect more codes to get added while the first implementations are being built. There's an IANA registry where the valid error codes are listed (see Section 12 💅). Errors that are considered fatal SHOULD cause the session to be dropped 💀
0: Corrupt Data (fatal). The receiver thinks the PDU it got is corrupt, in a way that none of the other error codes cover 🙈1: Internal Error (fatal). The party reporting the error hit some kind of internal problem that has nothing to do with protocol operation, like running out of memory or a coding assertion failing, et cetera ✨2: No Data Available. The cache is confident it's in good working order, but it can't answer a Serial Query or a Reset Query because it has no useful data right now. This is probably temporary 🦋 It most likely means the cache hasn't finished pulling down an initial current data set from the Global RPKI system yet, after something wiped out whatever it had before (a reboot, a network partition, et cetera) 🌈3: Invalid Request (fatal). The cache server thinks the client's request is invalid 🚫4: Unsupported Protocol Version (fatal). The Protocol Version isn't one the receiver knows 🎀5: Unsupported PDU Type (fatal). The PDU Type isn't one the receiver knows 🧚6: Withdrawal of Unknown Record (fatal). The received PDU hasFlag=0, but there's no record in the receiver's database for that{Prefix, Len, Max-Len, ASN}tuple. Can't withdraw what isn't there, bestie 😭7: Duplicate Announcement Received (fatal). The received PDU has an identical{Prefix, Len, Max-Len, ASN}tuple to a PDU that's still active in the router. Double-announcing the same thing is a no-go 💜
11. Security Considerations
okay this one is SERIOUS 🔐 This document describes a security protocol, so a lot of the security stuff lives in the relevant sections. This section just calls out the bits that might not be obvious from reading the other sections 👀
Cache Validation: For a bunch of caches (like the ones described in Section 9) to give a consistent view, they need to be handed consistent trust anchors to use in their internal validation process 🫶 Getting that consistent trust anchor out to everyone is assumed to happen out of band.
Cache Peer Identification: The router starts a transport session to a cache, and it identifies that cache by either IP address or fully qualified domain name. Be aware that a DNS or address spoofing attack could make the correct cache unreachable 😱 No session would get established, because the authorization keys wouldn't match.
Transport Security: The RPKI relies on object trust, not server or transport trust 💅 The IANA root trust anchor gets distributed to all caches through some out-of-band means. Then each cache can use it to validate certificates and ROAs all the way down the tree. The inter-cache relationships are built on this object security model, so the inter-cache transport can be lightly protected 🌸
But this protocol document assumes that routers can't do the validation cryptography. So the last link, from cache to router, is secured by server authentication and transport-level security. This is dangerous, because server authentication and transport have very different threat models than object security 💀
So the strength of the trust relationship and the transport between the router(s) and the cache(s) is critical. You're betting your routing on this 🎰
While we can't say the cache has to be on the same LAN (partly because an enterprise might want to offload the cache task to its upstream ISP(s)), locality, trust, and control are super critical issues here 🫠 The cache(s) really SHOULD be as close as possible to the router(s), in the sense of controlled and protected transport (protected against DDoS and MITM) 🛡️ It also SHOULD be topologically close, so that a minimum of validated routing data is needed to bootstrap a router's access to a cache 🧭
The identity of the cache server SHOULD be verified and authenticated by the router client, and vice versa, before any data are exchanged 🤝
Transports that can't provide the necessary authentication and integrity (see Section 7) must rely on network design and operational controls to protect against spoofing and corruption attacks. As pointed out in Section 7, TCP-AO is the long-term plan 🦋 Protocols that provide integrity and authenticity SHOULD be used. And if they can't be, i.e., if TCP is used as the transport, the router and cache MUST be on the same trusted, controlled network 🔥
12. IANA Considerations
IANA assigned 'well-known' TCP Port Numbers to the RPKI-Router Protocol for the following (see Section 7) 🎀
rpki-rtr
rpki-rtr-tlsIANA created a registry for tuples of Protocol Version / PDU Type, and each of those can range from 0 to 255 🌈 The registry is called "rpki-rtr-pdu". The policy for adding to it is RFC Required per [RFC5226], and entries have to be either Standards Track or Experimental. The initial entries are below ✨
Protocol PDU
Version Type Description
-------- ---- ---------------
0 0 Serial Notify
0 1 Serial Query
0 2 Reset Query
0 3 Cache Response
0 4 IPv4 Prefix
0 6 IPv6 Prefix
0 7 End of Data
0 8 Cache Reset
0 10 Error Report
0 255 ReservedIANA also created a registry for Error Codes 0 to 255 🍓 It's called "rpki-rtr-error". The policy for adding to it is Expert Review per [RFC5226], where the responsible IESG Area Director should appoint the Expert Reviewer. The initial entries should be as follows 💖
Error
Code Description
----- ----------------
0 Corrupt Data
1 Internal Error
2 No Data Available
3 Invalid Request
4 Unsupported Protocol Version
5 Unsupported PDU Type
6 Withdrawal of Unknown Record
7 Duplicate Announcement Received
255 ReservedAnd IANA added an SSH Connection Protocol Subsystem Name, as defined in [RFC4250], of 'rpki-rtr' 🐚
13. Acknowledgments
The authors wanted to thank Steve Bellovin, Rex Fernando, Paul Hoffman, Russ Housley, Pradosh Mohapatra, Keyur Patel, Sandy Murphy, Robert Raszuk, John Scudder, Ruediger Volk, and David Ward 🫶 Particular thanks go to Hannes Gredler for showing everyone the dangers of unnecessary fields 💅
14. References
14.1. Normative References
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic",
RFC 1982, August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP
MD5 Signature Option", RFC 2385, August 1998.
[RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for
Reliable Multicast Transport (RMT) Building Blocks and
Protocol Instantiation documents", RFC 3269, April 2002.
[RFC4250] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH)
Protocol Assigned Numbers", RFC 4250, January 2006.
[RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, January 2006.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 5280, May 2008.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010.
[RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms
for the TCP Authentication Option (TCP-AO)", RFC 5926,
June 2010.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Austein, "BGP Prefix Origin Validation", RFC 6811,
January 2013.14.2. Informative References
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, August 1996.
[RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5",
RFC 4808, March 2007.
[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI
Scheme", RFC 5781, February 2010.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, February 2012.
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile
for Resource Certificate Repository Structure", RFC 6481,
February 2012.
[RTR-IMPL] Bush, R., Austein, R., Patel, K., Gredler, H., and M.
Waehlisch, "RPKI Router Implementation Report", Work
in Progress, January 2012.Authors' Addresses
Randy Bush
Internet Initiative Japan
5147 Crystal Springs
Bainbridge Island, WA 98110
US
EMail: randy@psg.com
Rob Austein
Dragon Research Labs
EMail: sra@hactrn.net📦 where this page comes from
- ietf: rfc6810 2013-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms