RFC 8210
The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1
RFC 8210: The RPKI to Router Protocol, Version 1 💖
okay bestie, grab your snacks because this one is a protocol (a set of rules that machines follow to talk to each other) and it is about to be so iconic 🦋✨
Here's the tea on the title block 🎀. The doc is by R. Bush (Internet Initiative Japan) and R. Austein (Dragon Research Labs). It's published by the IETF as a Standards Track document, so it's an official standard, not just a suggestion 💅. It came out in September 2017, and it's listed as ISSN: 2070-1721. The big plot twist 🙈 is that it updates RFC 6810, which means it's a glow-up of that earlier protocol. Version 0 lives in RFC 6810, and this one is version 1 🌸.
The vibe of the whole thing: routers need a way to check whether the networks announced over BGP (the internet's routing gossip 💜) actually belong to who's claiming them. To do that, they grab prefix origin data and router keys from a trusted cache. This RFC is the rulebook for delivering that data 🧚.
Here's the full table of contents, so you know what's coming 🍓:
1. Introduction
1.1. Requirements Language
1.2. Changes from RFC 6810
2. Glossary
3. Deployment Structure
4. Operational Overview
5. Protocol Data Units (PDUs)
5.1. Fields of a PDU
5.2. Serial Notify
5.3. Serial Query
5.4. Reset Query
5.5. Cache Response
5.6. IPv4 Prefix
5.7. IPv6 Prefix
5.8. End of Data
5.9. Cache Reset
5.10. Router Key
5.11. Error Report
6. Protocol Timing Parameters
7. Protocol Version Negotiation
8. Protocol Sequences
8.1. Start or Restart
8.2. Typical Exchange
8.3. No Incremental Update Available
8.4. Cache Has No Data Available
9. Transport
9.1. SSH Transport
9.2. TLS Transport
9.3. TCP MD5 Transport
9.4. TCP-AO Transport
10. Router-Cache Setup
11. Deployment Scenarios
12. Error Codes
13. Security Considerations
14. IANA Considerations
15. References
15.1. Normative References
15.2. Informative References
Acknowledgements
Authors' AddressesPart 1 covers the intro and the basics, so let's get into it 🫶
1. Introduction ✨
Okay so, routers need to verify the origin Autonomous Systems (ASes, basically the network operators 🌈) and AS paths of BGP announcements. To do that, they need a simple but reliable way to receive cryptographically validated RPKI [RFC6480] prefix origin data and router keys from a trusted cache. This doc describes the protocol that delivers them. The design is intentionally constrained so it works on a lot of the ISP router platforms that exist right now 💅.
This document updates [RFC6810].
Here's the roadmap 🗺️. Section 3 covers the deployment structure, and Section 4 gives the operational overview. The binary payloads are formally described in Section 5, and the expected Protocol Data Unit (PDU) sequences are in Section 8. Transport options are in Section 9, and Section 10 explains how routers and caches get configured to connect and authenticate 🔐. Section 11 covers 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 things need to change later 🦋.
1.1. 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. 🎀
1.2. Changes from RFC 6810
This section sums up the big changes between [RFC6810] and the protocol in this document 🌸.
- New Router Key PDU type (Section 5.10) added. 🔑
- Explicit timing parameters (Section 5.8, Section 6) added. ⏱️
- Protocol version number incremented from 0 (zero) to 1 (one). 📈
- Protocol version number negotiation (Section 7) added. 🤝
2. Glossary 📖
These terms have special meanings in this doc, so bookmark them bestie 🔖.
Global RPKI: The authoritative RPKI data gets published across a distributed set of servers run by the IANA, Regional Internet Registries (RIRs), National Internet Registries (NIRs), and ISPs. See [RFC6481].
Cache: A cache is a coalesced copy of the published Global RPKI data. It gets fetched or refreshed periodically, directly or indirectly, using the rsync protocol [RFC5781] or some successor. 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 provider and a Relying Party 🫣.
Serial Number: "Serial Number" is a 32-bit strictly increasing unsigned integer that wraps from 2^32-1 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 updates, new incoming data and implicit deletes are associated with the new serial but MUST NOT be sent until the fetch is complete. A Serial Number is not commensurate between different caches or different protocol versions, and it doesn't need to be kept 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 ID to uniquely identify that cache instance and bind it to the sequence of Serial Numbers that instance will generate. This lets a router restart a failed session knowing the Serial Number it's using is commensurate with the cache's ✨.
Payload PDU: A payload PDU is a protocol message carrying data for the router, as opposed to a PDU that carries the control mechanisms of this protocol. Prefixes and Router Keys are examples of payload PDUs 💜.
3. Deployment Structure 🏗️
Getting the RPKI out to routers has a three-level structure, and it goes like this 🌈.
Global RPKI: The authoritative RPKI data is published across a distributed set of servers at the IANA, RIRs, NIRs, and ISPs (see [RFC6481]).
Local Caches: Local caches are a local set of one or more collected and verified caches of RPKI data. A Relying Party, e.g., a router or other client, MUST have a trust relationship with, and a trusted transport channel to, any cache(s) it uses. 🔐
Routers: A router fetches data from a local cache using the protocol described in this document, and it's called a client of that cache. There MAY be mechanisms for the router to assure itself of the cache's authenticity and to authenticate itself to the cache (see Section 9). 🦋
4. Operational Overview ✨
Okay so, a router sets up a connection to one or more caches it has a client/server thing going with, and it keeps that connection open 💖. It has a semi-ordered list of caches in its config, and it connects to the most preferred cache (or set of caches) that will actually accept the connection 🎀.
The router MUST choose the most preferred cache or set of caches according to its configuration. That way the operator can keep the load on their caches and on the Global RPKI under control 🫶.
Every so often, the router sends the cache the most recent Serial Number it got data from that cache, which is basically its current Serial Number, in the form of a Serial Query 🦋. When a router starts a brand new session with a cache, or wants to reset an existing one, it sends a Reset Query 🔄.
The cache answers a Serial Query with all the data changes that happened since that Serial Number. That could be the null set, and in that case the End of Data PDU (Section 5.8) still gets sent 🌸. Also, the Serial Number comparison used to figure out "since the given Serial Number" MUST take wrap-around into account, so check [RFC1982] 🧠.
Once the router has received all the data records from the cache, it sets its current Serial Number to whatever Serial Number was in the received End of Data PDU ✅.
When the cache updates its database, it sends a Notify PDU to every router that's currently connected 🔔. This is just a hint that now would be a good time for the router to poll for an update. It's only a hint though! The protocol requires the router to poll for updates periodically anyway 💅.
Strictly speaking, 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 lets it transfer just the data records that changed since the last update, which is so much cleaner ✨. As with any update protocol based on incremental transfers, the router must be prepared to fall back to a full transfer if, for any reason, the cache can't provide the necessary incremental data. Unlike some incremental transfer protocols, this one requires the router to make an explicit request to start the fallback. This is deliberate! The cache has no way of knowing whether the router has also set up sessions with other caches that might be able to give better service 👑.
A cache server has to evaluate certificates and ROAs (Route Origin Authorizations; see [RFC6480]), and those are time dependent, so the servers' clocks MUST be correct to a tolerance of approximately an hour ⏰. Time is not a vibe, bestie 🙈.
5. Protocol Data Units (PDUs) 🎀
The exchanges between the cache and the router are sequences of exchanges of the following PDUs, following the rules in Section 8 📜.
Reserved fields (marked "zero" in PDU diagrams) MUST be zero on transmission and MUST be ignored on receipt 🤍.
5.1. Fields of a PDU 🍓
PDUs contain the following data elements:
Protocol Version: An 8-bit unsigned integer, currently 1, denoting the version of this protocol.PDU Type: An 8-bit unsigned integer, denoting the type of the PDU, e.g., IPv4 Prefix.Serial Number: The Serial Number of the RPKI cache when this set of PDUs was received from an upstream cache server or gathered from the Global RPKI. A cache increments its Serial Number when it completes a rigorously validated update from a parent cache or the Global RPKI 🔢.Session ID: A 16-bit unsigned integer. When a cache server starts up, it generates a Session ID to identify that instance of the cache and to bind it to the sequence of Serial Numbers that cache instance will generate 🪪. This lets the router restart a failed session knowing that the Serial Number it's using is commensurate with the cache's. If, at any time after the protocol version has been negotiated (Section 7), either the router or the cache finds that the value of the Session ID is not the same as the other's, the party that detects the mismatch MUST immediately terminate the session with an Error Report PDU with code0("Corrupt Data"), and the router MUST flush all data learned from that cache 🚨.
Sessions are specific to a particular protocol version. Here's the tea: if a cache server supports multiple versions of this protocol, happens to use the same Session ID value for multiple protocol versions, and also happens to use the same Serial Number values for two or more sessions that share a Session ID but have different Protocol Version values, then the Serial Numbers are not commensurate. The full test for whether Serial Numbers are commensurate requires comparing Protocol Version, Session ID, and Serial Number together 🧩. To reduce the risk of confusion, cache servers SHOULD NOT use the same Session ID across multiple protocol versions. Even if they do, routers MUST treat sessions with different Protocol Version fields as separate sessions, even if they happen to have the same Session ID 🙅♀️.
Should a cache erroneously reuse a Session ID so that a router doesn't realize the session has changed (the old and new Session IDs have the same numeric value), the router may get confused about what's in the cache 😵💫. How long it takes the router to figure out it's confused depends on whether the Serial Numbers are also reused. 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 🎉. If the Serial Numbers are close, though, the cache may respond 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 will notice some discrepancy between the state the cache expects and its own state. For example, the Cache Response might tell the router to drop a record the router doesn't hold, or to add a record the router already has. In those cases, the router will detect the error and reset the session. The one situation where the router might stay out of sync is when nothing in the Cache Response contradicts any data the router currently holds 🫠.
Using persistent storage for the Session ID, or a clock-based scheme for generating Session IDs, should avoid the risk of Session ID collisions 💾.
The Session ID might be a pseudorandom value, a strictly increasing value if the cache has reliable storage, et cetera. A seconds-since-epoch timestamp value, such as the one from the POSIX time() function, makes a good Session ID value ⏱️.
Length: A 32-bit unsigned integer whose value is the count of the bytes in the entire PDU, including the 8 bytes of header, which includes the length field 📏.Flags: The lowest-order bit of the Flags field is 1 for an announcement and 0 for a withdrawal 📣. For a Prefix PDU (IPv4 or IPv6), the flag indicates whether this PDU announces a new right to announce the prefix or withdraws a previously announced right. A withdraw effectively deletes one previously announced Prefix PDU with the exact same Prefix, Length, Max-Len, and Autonomous System Number (ASN). Similarly, for a Router Key PDU, the flag indicates whether this PDU announces a new Router Key or deletes one previously announced Router Key PDU with the exact same AS Number, subjectKeyIdentifier, and subjectPublicKeyInfo 🔑.
The remaining bits in the Flags field are reserved for future use. In protocol version 1, they MUST be zero on transmission and MUST be ignored on receipt 🧊.
Prefix Length: An 8-bit unsigned integer denoting the shortest prefix allowed by the Prefix element 📐.Max Length: An 8-bit unsigned integer denoting the longest prefix allowed by the Prefix element. This MUST NOT be less than the Prefix Length element 🚫.Prefix: The IPv4 or IPv6 prefix of the ROA 🗺️.Autonomous System Number: A 32-bit unsigned integer representing an ASN that's allowed to announce a prefix or that's associated with a router key 🛰️.Subject Key Identifier: The 20-octet Subject Key Identifier (SKI) value of a router key, as described in [RFC6487] 🗝️.Subject Public Key Info: A router key's subjectPublicKeyInfo value, as described in [RFC8208]. This is the full ASN.1 DER encoding of the subjectPublicKeyInfo, including the ASN.1 tag and length values of the subjectPublicKeyInfo SEQUENCE 🧾.Refresh Interval: The interval between normal cache polls. See Section 6 ⏳.Retry Interval: The interval between cache poll retries after a failed cache poll. See Section 6 🔁.Expire Interval: The interval during which data fetched from a cache remains valid in the absence of a successful subsequent cache poll. See Section 6 ⌛.
5.2. Serial Notify 🔔
The cache notifies the router that the cache has new data 📬.
The Session ID reassures the router that the Serial Numbers are commensurate, i.e., the cache session has not been changed 🤝.
Upon receipt of a Serial Notify PDU, the router MAY issue an immediate Serial Query (Section 5.3) or Reset Query (Section 5.4) without waiting for the Refresh Interval timer (see Section 6) to expire 🏃♀️.
Serial Notify is the only message the cache can send that is not in response to a message from the router. Main character energy 👑.
If the router receives a Serial Notify PDU during the initial startup period, while the router and cache are still negotiating to agree on a protocol version, the router MUST simply ignore the Serial Notify PDU, even if the Serial Notify PDU is for an unexpected protocol version. See Section 7 for details 🙈.
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| 1 | 0 | |
+-------------------------------------------+
| |
| Length=12 |
| |
+-------------------------------------------+
| |
| Serial Number |
| |
`-------------------------------------------'5.3. Serial Query ✨
okay so the router sends a Serial Query to ask the cache for every announcement and withdrawal that has happened since the Serial Number in that query 📬
The cache replies with a Cache Response PDU (Section 5.5) if it has a (possibly null) record of the changes since the Serial Number the router sent. After that come zero or more payload PDUs and an End Of Data PDU (Section 5.8) 💌
Bestie, the cache MUST return the minimum set of changes needed to bring the router into sync with the cache 🫶 So if a prefix or router key got changed a bunch of times between the router's Serial Number and the cache's current one, the cache MUST merge all of those changes so the router sees the simplest possible version 🧹 Generally that means that for any prefix or router key, the data stream has at most one withdrawal followed by at most one announcement. If everything cancels out, the prefix or router key doesn't show up at all 🙈
Why do it this way? The whole point of the RPKI-Router protocol is to offload work from the router onto the cache, so the cache should be the one doing the simplifying. That means less work for the router 💅
If the cache doesn't have the data it needs to update the router, maybe because its records don't go back to the Serial Number in the Serial Query, it replies with a Cache Reset PDU (Section 5.9) 💀
The Session ID tells the cache which instance the router expects. That's how everyone confirms the Serial Numbers are commensurate, i.e., the cache session hasn't been changed 🦋
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| 1 | 1 | |
+-------------------------------------------+
| |
| Length=12 |
| |
+-------------------------------------------+
| |
| Serial Number |
| |
`-------------------------------------------'5.4. Reset Query 🌸
the router is basically saying "hey cache, I want everything." It asks for the total active, current, non-withdrawn database 🗂️ The cache answers with a Cache Response PDU (Section 5.5), then zero or more payload PDUs, then an End of Data PDU (Section 5.8) 🎀
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | zero |
| 1 | 2 | |
+-------------------------------------------+
| |
| Length=8 |
| |
`-------------------------------------------'5.5. Cache Response 🧁
the cache responds to queries with zero or more payload PDUs. For a Serial Query (Section 5.3), it sends the announcements and withdrawals that happened since the Serial Number the router sent. For a Reset Query (Section 5.4), it sends every data record it has. In that second case, the withdraw/announce field in the payload PDUs MUST have the value 1 (announce) 📣
For a Reset Query, the new Session ID tells the router which instance of the cache session to use for future confirmation 🪪 For a Serial Query, a matching Session ID reassures the router that the Serial Numbers are commensurate, i.e., the cache session hasn't changed. Nice and steady 🧘♀️
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| 1 | 3 | |
+-------------------------------------------+
| |
| Length=8 |
| |
`-------------------------------------------'5.6. IPv4 Prefix 💜
this is the IPv4 payload PDU, and it's giving very structured 💅
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | zero |
| 1 | 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. So one bit decides whether the router adds or removes the route 🔁
Now the RPKI drama 🎭 Nothing stops a signing certificate from issuing two identical ROAs. In that case there's no semantic difference between the objects, just some process redundancy, like doing the same thing twice 🙃
There's also a real reason you might see what looks like identical IPvX PDUs to a router. This can happen when an upstream certificate gets reissued, or when there's an address ownership transfer up the validation chain. The ROA would be identical in the router sense, meaning it has the same {Prefix, Len, Max-Len, ASN}, but it would have a different validation path in the RPKI. That matters a lot 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 🔒 If the router client gets 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 🦋
the IPv6 version of the payload PDU, same layout, just bigger 👑
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | zero |
| 1 | 6 | |
+-------------------------------------------+
| |
| Length=32 |
| |
+-------------------------------------------+
| | Prefix | Max | |
| Flags | Length | Length | zero |
| | 0..128 | 0..128 | |
+-------------------------------------------+
| |
+--- ---+
| |
+--- IPv6 Prefix ---+
| |
+--- ---+
| |
+-------------------------------------------+
| |
| Autonomous System Number |
| |
`-------------------------------------------'Analogous to the IPv4 Prefix PDU, it has 96 more bits and no magic ✨
5.8. End of Data 🏁
the cache tells the router it has no more data for the request. The end, bestie 🎬
The Session ID and Protocol Version MUST be the same as those of the Cache Response that began the (possibly null) sequence of payload PDUs 🤝
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| 1 | 7 | |
+-------------------------------------------+
| |
| Length=24 |
| |
+-------------------------------------------+
| |
| Serial Number |
| |
+-------------------------------------------+
| |
| Refresh Interval |
| |
+-------------------------------------------+
| |
| Retry Interval |
| |
+-------------------------------------------+
| |
| Expire Interval |
| |
`-------------------------------------------'The Refresh Interval, Retry Interval, and Expire Interval are all 32-bit elapsed times measured in seconds ⏱️ They're the timing settings the cache expects the router to use when deciding when to send the next Serial Query or Reset Query PDUs. For how those values work and which ranges are allowed, see Section 6 📖
5.9. Cache Reset 🙃
the cache may respond to a Serial Query to tell the router it can't do an incremental update starting from the Serial Number the router sent. Oof 😭 The router then has to decide whether to issue a Reset Query or switch to a different cache, and it must decide one of those 🔀
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | zero |
| 1 | 8 | |
+-------------------------------------------+
| |
| Length=8 |
| |
`-------------------------------------------'5.10. Router Key ✨
Okay bestie, this PDU is the one that carries a router's key info 🔑 Here's the layout:
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | | |
| Version | Type | Flags | zero |
| 1 | 9 | | |
+-------------------------------------------+
| |
| Length |
| |
+-------------------------------------------+
| |
+--- ---+
| Subject Key Identifier |
+--- ---+
| |
+--- ---+
| (20 octets) |
+--- ---+
| |
+-------------------------------------------+
| |
| AS Number |
| |
+-------------------------------------------+
| |
| Subject Public Key Info |
| |
`-------------------------------------------'The lowest-order bit of the Flags field is 1 for an announcement and 0 for a withdrawal 🦋
The cache server MUST ensure that it has told the router client to have one and only one Router Key PDU for a unique {SKI, ASN, Subject Public Key} at any one point in time 💅 No duplicates, no drama. If the router client gets a Router Key PDU with a {SKI, ASN, Subject Public Key} that's identical to one it already has active, it SHOULD raise a Duplicate Announcement Received error 🙈
Note that a particular ASN can show up in multiple Router Key PDUs with different Subject Public Key values, and a particular Subject Public Key value can show up in multiple Router Key PDUs with different ASNs. Lowkey this is by design: to keep announcement and withdrawal semantics as simple as possible for the router, this protocol makes no attempt to compress either of these cases 🌸
Also, it's possible (albeit very unlikely) for multiple distinct Subject Public Key values to hash to the same SKI 👀 That's why implementations MUST compare Subject Public Key values as well as SKIs when detecting duplicate PDUs. Main character energy means checking both! 👑
5.11. Error Report 🚨
This PDU is used by either party to report an error to the other.
Error reports are only sent as responses to other PDUs, not to report errors in Error Report PDUs. Don't report the report, periodt 💀
Error codes are described in Section 12 🧚
If the error is generic (e.g., "Internal Error") and isn't associated with the PDU it's responding to, the Erroneous PDU field MUST be empty and the Length of Encapsulated PDU field MUST be zero.
An Error Report PDU MUST NOT be sent for an Error Report PDU. If an erroneous Error Report PDU is received, the session SHOULD be dropped 😭
If the error is associated with a PDU of excessive length (too long to be any legal PDU other than another Error Report), or with a possibly corrupt length, the Erroneous PDU field MAY be truncated 🫶
The diagnostic text is optional; if it isn't present, the Length of Error Text field MUST be zero. If error text is present, it MUST be a string in UTF-8 encoding (see [RFC3629]) 🎀
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Error Code |
| 1 | 10 | |
+-------------------------------------------+
| |
| Length |
| |
+-------------------------------------------+
| |
| Length of Encapsulated PDU |
| |
+-------------------------------------------+
| |
~ Erroneous PDU ~
| |
+-------------------------------------------+
| |
| Length of Error Text |
| |
+-------------------------------------------+
| |
| Arbitrary Text |
| of |
~ Error Diagnostic Message ~
| |
`-------------------------------------------'6. Protocol Timing Parameters ⏰
Okay so the data the cache hands out over the RPKI-Router protocol gets pulled from the Global RPKI system at intervals that only the cache knows about 🌈 That means only the cache can really tell how often it makes sense for the router to poll it, or how long the data stays valid (or at least unchanged).
To give the cache some say over the load its client routers put on it, the End Of Data PDU carries three values that let the cache share timing parameters with the router:
- Refresh Interval: This parameter tells the router how long to wait before next attempting to poll the cache, and between subsequent attempts, using a Serial Query or Reset Query PDU. The router SHOULD NOT poll the cache sooner than this parameter says. Receipt of a Serial Notify PDU overrides this interval and suggests the router issue an immediate query without waiting for the Refresh Interval to expire ⚡ The countdown for this timer starts when the containing End Of Data PDU is received.
- Minimum allowed value: 1 second.
- Maximum allowed value: 86400 seconds (1 day).
- Recommended default: 3600 seconds (1 hour).
- Retry Interval: This parameter tells the router how long to wait before retrying a failed Serial Query or Reset Query. The router SHOULD NOT retry sooner than this parameter says. A protocol version mismatch overrides this interval, though: if the router needs to downgrade to a lower protocol version number, it MAY send the first Serial Query or Reset Query immediately 🏃♀️ The countdown for this timer starts when the query fails, and it restarts after each subsequent failure until a query succeeds.
- Minimum allowed value: 1 second.
- Maximum allowed value: 7200 seconds (2 hours).
- Recommended default: 600 seconds (10 minutes).
- Expire Interval: This parameter tells the router how long it can keep using the current version of the data while it's unable to complete a successful subsequent query. The router MUST NOT retain the data past the time this parameter indicates 🗑️ The countdown for this timer starts when the containing End Of Data PDU is received.
- Minimum allowed value: 600 seconds (10 minutes).
- Maximum allowed value: 172800 seconds (2 days).
- Recommended default: 7200 seconds (2 hours).
If the router has never issued a successful query against a particular cache, it SHOULD retry periodically using the default Retry Interval above 🌷
Caches MUST set Expire Interval to a value larger than either Refresh Interval or Retry Interval. No exceptions, bestie 💖
7. Protocol Version Negotiation 🤝
A router MUST start each transport connection by issuing either a Reset Query or a Serial Query. That query tells the cache which version of this protocol the router implements 🧠
If a cache that supports version 1 receives a query from a router that specifies version 0, the cache MUST either downgrade to protocol version 0 [RFC6810] or send a version 1 Error Report PDU with Error Code 4 ("Unsupported Protocol Version") and terminate the connection.
If a router that supports version 1 sends a query to a cache that only supports version 0, one of two things will happen:
- The cache may terminate the connection, perhaps with a version 0 Error Report PDU. In this case, the router MAY retry the connection using protocol version 0.
- The cache may reply with a version 0 response. In this case, the router MUST either downgrade to version 0 or terminate the connection.
In any of the downgraded combinations above, the new features of version 1 won't be available, and all PDUs will have 0 in their version fields 🥲
If either party receives a PDU containing an unrecognized Protocol Version (neither 0 nor 1) during this negotiation, it MUST either downgrade to a known version or terminate the connection, with an Error Report PDU unless the received PDU is itself an Error Report PDU 🚫
The router MUST ignore any Serial Notify PDUs it might receive from the cache during this initial startup period, regardless of the Protocol Version field in the Serial Notify PDU. Why? Since Session ID and Serial Number values are specific to a particular protocol version, the values in the notification aren't useful to the router. Even if they were meaningful, processing the notification would only trigger exactly the same Reset Query or Serial Query the router has already sent as part of the not-yet-complete version negotiation. So there's literally nothing to gain by processing notifications until version negotiation completes 🙅♀️
Caches SHOULD NOT send Serial Notify PDUs before version negotiation completes. Routers, however, MUST handle such notifications (by ignoring them) for backwards compatibility with caches serving protocol version 0 🫶
Once the cache and router have agreed on a Protocol Version through the negotiation process above, that version is stable for the life of the session. See Section 5.1 for a discussion of the interaction between Protocol Version and Session ID 🔗
If either party receives a PDU for a different Protocol Version once the above negotiation completes, that party MUST drop the session. Unless the PDU containing the unexpected Protocol Version was itself an Error Report PDU, the party dropping the session SHOULD send an Error Report with an error code of 8 ("Unexpected Protocol Version") 💅
8. Protocol Sequences 🎬
The sequences of PDU transmissions fall into four conversations as follows:
8.1. Start or Restart ✨
Okay bestie, so this is the very first handshake moment 💖 Look at this little diagram:
Cache Router
~ ~
| <----- Reset Query -------- | R requests data (or Serial Query)
| |
| ----- Cache Response -----> | C confirms request
| ------- Payload PDU ------> | C sends zero or more
| ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix,
| ------- Payload PDU ------> | or Router Key PDUs
| ------- End of Data ------> | C sends End of Data
| | and sends new serial
~ ~When a transport connection is first established, the router MUST send either a Reset Query or a Serial Query. 🎀 A Serial Query is the move if the router still has significant unexpired data from a broken session with the same cache and remembers the Session ID of that session 🧚. In that case, a Serial Query containing the Session ID from the previous session lets the router catch up while making sure the Serial Numbers are commensurate and that the router and cache are speaking compatible versions of the protocol 💅. In all other cases, the router doesn't have the stuff it needs for fast resync, so it MUST fall back to a Reset Query 😭.
The Reset Query sequence also shows up when the router gets a Cache Reset, picks a new cache, or feels like it's lost its way 🌸. Main character energy for sure 💀.
See Section 7 for the details on version negotiation 🦋.
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 periodically. ✨ This also works as a keep-alive at the application layer 💜. See Section 6 for the required polling frequency 🔥.
8.2. Typical Exchange 🍓
Cache Router
~ ~
| -------- Notify ----------> | (optional)
| |
| <----- Serial Query ------- | R requests data
| |
| ----- Cache Response -----> | C confirms request
| ------- Payload PDU ------> | C sends zero or more
| ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix,
| ------- Payload PDU ------> | or Router Key PDUs
| ------- End of Data ------> | C sends End of Data
| | and sends new serial
~ ~So the cache server SHOULD send a Notify PDU with its current Serial Number when the cache's serial changes 🌈, with the expectation that the router MAY then issue a Serial Query earlier than it otherwise might 🫶. This is basically the same vibe as DNS NOTIFY in [RFC1996] 🧚. The cache MUST rate-limit Serial Notifies to no more than one per minute 🙈.
When the transport layer is up and either a timer goes off in the router or the cache has sent a Notify PDU, the router asks for new data by sending a Serial Query, and the cache sends all the data newer than the serial in that Serial Query 💖.
To limit how long a cache has to keep old withdraws, a router MUST send either a Serial Query or a Reset Query periodically. 🦋 See Section 6 for the required polling frequency 👑.
8.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
| ------- Payload PDU ------> | C sends zero or more
| ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix,
| ------- Payload PDU ------> | or Router Key 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 🙈, basically saying "sorry bestie, I can't give you an incremental update from the Serial Number you sent" 😭. This might happen because the cache lost its state, or because the router waited too long between polls and the cache cleaned up old data it no longer thinks it needs, or because the cache ran out of storage and had to expire some old data early 🥺. Whatever caused it, the cache replies with a Cache Reset to tell the router it can't honor the request 💅. When a router gets this, the router 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. 🔥
8.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 to say it can't supply any update at all 🌸. The most likely reason is that the cache lost its state, maybe from a restart, and hasn't recovered yet 🧚. It's possible a cache could get into this state without dropping any of its active sessions, but a router is more likely to see it 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, the router 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. 👑
9. Transport 🦋
The transport-layer session between a router and a cache carries the binary PDUs in a persistent session 💜.
Authentication between the router and the cache is highly desirable 🔥, because it helps prevent cache spoofing and DoS attacks by illegitimate routers 🙈. Integrity protection for payloads is also desirable, to guard against monkey-in-the-middle (MITM) attacks 💅. Unfortunately, there is no protocol to do so on all currently used platforms 😭. So, as of the writing of this document, there is no mandatory-to-implement transport that provides authentication and integrity protection 💀.
To reduce exposure to dropped but non-terminated sessions, both caches and routers SHOULD enable keep-alives when they're available in the chosen transport protocol 🫶.
It's expected that, when the TCP Authentication Option (TCP-AO) [RFC5925] is available on all 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 14. 🎀 Operators SHOULD use procedural means, e.g., access control lists (ACLs), to reduce exposure to authentication issues 🧚.
If unprotected TCP is the transport, the cache and routers MUST be on the same trusted and controlled network 🌈.
If 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-rtr port.
- Caches and routers MAY use Secure Shell version 2 (SSHv2) transport [RFC4252] using the normal SSH port. For an example, see Section 9.1. ✨
- Caches and routers MAY use TCP MD5 transport [RFC2385] using the rpki-rtr port. Note that TCP MD5 has been obsoleted by TCP-AO [RFC5925] 💀.
- Caches and routers MAY use TCP over IPsec transport [RFC4301] using the rpki-rtr port.
- Caches and routers MAY use Transport Layer Security (TLS) transport [RFC5246] using port rpki-rtr-tls (324); see Section 14. 💜
9.1. SSH Transport 🧚
To run over SSH, the client router first sets up an SSH transport connection using the SSHv2 transport protocol, and the client and server exchange keys for message integrity and encryption 🔐. The client then invokes the "ssh-userauth" service to authenticate the application, as described in the SSH authentication protocol [RFC4252] 💅. Once the application is successfully authenticated, the client invokes the "ssh-connection" service, also known as the SSH connection protocol 🦋.
After the ssh-connection service is established, the client opens a channel of type "session", which results in an SSH session ✨.
Once the SSH session is up, the application invokes the application transport as an SSH subsystem called "rpki-rtr" 🌸. Subsystem support is a feature of 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 stuff, like a system message sent at shell startup 💖.
It's assumed that the router and cache have exchanged keys out of band by some reasonably secured means 🫶.
Cache servers supporting SSH transport MUST accept RSA 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 MITM attacks 🛡️💜
9.2. TLS Transport 🔒
okay bestie, TLS transport is where client routers have to show their ID, no cap. 🪪 Client routers using TLS MUST present client-side certificates to prove who they are to the cache. That lets the cache manage its load by turning away connections from unauthorized routers 🙅♀️. In principle, any type of certificate and Certification Authority (CA) can be used. But cache operators usually wanna make their own small-scale CA and hand out certificates to each authorized router, and honestly that's giving organized 💅. It makes credential rollover way easier, since any unrevoked, unexpired certificate from the proper CA can be used ✨.
Certificates used to authenticate client routers in this protocol MUST include a subjectAltName extension [RFC5280] containing one or more iPAddress identities. When the cache authenticates the router's certificate, it MUST check the IP address of the TLS connection against those iPAddress identities, and it SHOULD reject the connection if none of them match 🚫. Routers also MUST verify the cache's TLS server certificate, using subjectAltName dNSName identities as described in [RFC6125], so nobody can MITM them 👀. The rules and guidelines in [RFC6125] apply here too, with a few extra things to keep in mind:
- Support for the DNS-ID identifier type (that is, the
dNSNameidentity in the subjectAltName extension) is REQUIRED inrpki-rtrserver and client implementations which use TLS. Certification authorities which issuerpki-rtrserver certificates MUST support the DNS-ID identifier type, and the DNS-ID identifier type MUST be present inrpki-rtrserver certificates. 🎀 - DNS names in
rpki-rtrserver certificates SHOULD NOT contain the wildcard character "*". 🙅♀️ rpki-rtrimplementations which use TLS MUST NOT use Common Name (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-rtrcache. 🧚
9.3. TCP MD5 Transport 🔐
so if TCP MD5 is in use, implementations MUST support key lengths of at least 80 printable ASCII bytes, per Section 4.5 of [RFC2385]. They MUST also support hexadecimal sequences of at least 32 characters, i.e., 128 bits 🔢.
ngl, key rollover with TCP MD5 is kinda problematic 😭. Cache servers SHOULD support [RFC4808] 🫶.
9.4. TCP-AO Transport 🦋
implementations MUST support key lengths of at least 80 printable ASCII bytes 🔑. They MUST also support hexadecimal sequences of at least 32 characters, i.e., 128 bits. Message Authentication Code (MAC) 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 ✨.
10. Router-Cache Setup 🌸
a cache has the public authentication data for each router it's configured to support 🗝️.
a router can be configured to peer with a bunch of caches, and a cache can be configured to support a bunch of routers. Each side has to have the name of, and the authentication data for, each peer 🤝. Also, on the router, this list has a non-unique preference value for each server. This preference just shows proximity, not trust, preferred belief, et cetera, so don't read into it too much 🙃. The client router tries to set up 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 these elements:
Preference: An unsigned integer showing 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. 🌐
Cache Credential(s): Any credential (such as a public key) needed to authenticate the cache's identity to the router. 🔓
Router Credential(s): Any credential (such as a private key or certificate) needed to authenticate the router's identity to the cache. 🔏
because the RPKI is distributed, caches simply cannot be rigorously synchronous 🌍. A client can hold data from multiple caches, but it MUST keep the data marked with its source, since later updates MUST affect the correct data 🏷️.
just like there can be more than one covering ROA from a single cache, there can 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 they validate BGP announcements 🚫.
when a more-preferred cache becomes available, it would be prudent for the client to start fetching from it, if resources allow 📈.
the client SHOULD try to keep at least one set of data, whether or not it has picked a different cache or made a new connection to the previous one 🫶.
a client MAY drop the data from a particular cache when it's fully in sync with one or more other caches 🧹.
see Section 6 for details on what to do when the client can't refresh from a particular cache 📖.
if a client loses connectivity to a cache it's using, or otherwise decides to switch to a new cache, it SHOULD keep 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 👑.
11. Deployment Scenarios 🏡
for illustration, here are three likely deployment scenarios 🎨:
Small End Site: The small multihomed end site may wish to outsource the RPKI cache to one or more of their 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 one fetches from a serving cache that's closer to the Global RPKI 🏰. They might also configure fallback 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). These caches would fetch from each other in an ISP-dependent topology, so they don't put undue load on the Global RPKI 🌐💅.
experience with large DNS cache deployments has shown that complex topologies are ill-advised, because it's easy to make errors in the graph, e.g., to not maintain a loop-free condition 🌀😵💫.
of course, these are just 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 which load from the distributed Global RPKI don't all do it 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 🎲✨.
12. Error Codes 🚨
this section has a preliminary list of error codes. The authors expect more additions during development of the initial implementations 🛠️. There's an IANA registry where valid error codes are listed; see Section 14. Errors which are considered fatal MUST cause the session to be dropped 💔.
0Corrupt Data (fatal): The receiver believes the received PDU is corrupt in a way not specified by another error code. 🥴1Internal Error (fatal): The party reporting the error ran into some kind of internal error unrelated to protocol operation (ran out of memory, a coding assertion failed, et cetera). 🧯2No Data Available: The cache believes itself to be in good working order, but it can't answer either a Serial Query or a Reset Query because it has no useful data available at this time. This is likely to be a temporary error, and most likely means the cache hasn't finished pulling down an initial current data set from the Global RPKI system after some event that wiped out whatever data it held before (reboot, network partition, et cetera). 🫠3Invalid Request (fatal): The cache server believes the client's request is invalid. 🙅♀️4Unsupported Protocol Version (fatal): The Protocol Version isn't known by the receiver of the PDU. 🤷♀️5Unsupported PDU Type (fatal): The PDU Type isn't known by the receiver of the PDU. 🧩6Withdrawal of Unknown Record (fatal): The received PDU hasFlag=0, but a matching record (a{Prefix, Len, Max-Len, ASN}tuple for an IPvX PDU, or a{SKI, ASN, Subject Public Key}tuple for a Router Key PDU) doesn't exist in the receiver's database. 👻7Duplicate Announcement Received (fatal): The received PDU hasFlag=1, but a matching record (a{Prefix, Len, Max-Len, ASN}tuple for an IPvX PDU, or a{SKI, ASN, Subject Public Key}tuple for a Router Key PDU) is already active in the router. 👯♀️8Unexpected Protocol Version (fatal): The received PDU has a Protocol Version field that differs from the protocol version negotiated in Section 7. 💅
that's the vibe for part 6 bestie 🌈✨
13. Security Considerations ✨
okay bestie, this is the security part and it's SERIOUS 🔒 Most of the security stuff is already sprinkled through the earlier sections, so this bit just points out the sneaky things that might not be obvious anywhere else 👀
Cache Validation: So a bunch of caches (the setup from Section 11) only stay in sync if they all use the same trust anchors for their internal validation. 🤝 The spec just assumes those get handed out out-of-band, so make sure everyone's on the same page before the party starts 🎉
Cache Peer Identification: The router is the one that starts the transport connection to a cache 📞 It finds that cache by IP address or by fully qualified domain name. Be careful, though: a DNS or address spoofing attack could make the correct cache unreachable 😱 And if that happens, no session gets set up, because the authorization keys wouldn't match. Honestly, that's kind of a safety net, but it also means the router just can't reach its cache 💀
Transport Security: Okay this one is the big deal 💅 The RPKI trusts the object, not the server or the transport. The IANA root trust anchor gets shipped to every cache through some out-of-band method, and then each cache can use it to validate certificates and ROAs all the way down the tree 🌳 Because the inter-cache relationships are built on this object security model, the inter-cache transport can be lightly protected 🧚
BUT (and this is the plot twist) this protocol assumes routers can't do the validation cryptography 😭 So the last link, from cache to router, is only secured by server authentication and transport-level security. And that 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. Literally. 🎲
Heads up, bestie: while the spec can't say the cache must be on the same LAN (especially if an enterprise wants to offload the cache job to its upstream ISP(s)), locality, trust, and control are super important here 🚨
The cache(s) really SHOULD be as close as possible to the router(s), in the sense of being controlled and protected (against DDoS and MITM) transport 🛡️ 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 gets exchanged 🫶 Mutual check-ins only, no strangers allowed 💅
Transports that can't provide the necessary authentication and integrity (see Section 9) have to rely on network design and operational controls to protect against spoofing and corruption attacks 🧱 As mentioned in Section 9, TCP-AO is the long-term plan 🔥 Protocols that provide integrity and authenticity SHOULD be used. And if they can't be used, i.e., TCP is the transport, then the router and cache MUST be on the same trusted, controlled network 🏠 No exceptions, periodt 💀
14. IANA Considerations 🧾
Okay, so this section only covers the updates needed in the existing IANA protocol registries to fit version 1 of this protocol 📚 If you want the IANA stuff from the original (version 0) protocol, go check [RFC6810] 💜
All the existing entries in the IANA "rpki-rtr-pdu" registry stay valid for protocol version 0 ✅ All of the PDU types allowed in version 0 are also allowed in version 1, plus the brand-new Router Key PDU 🔑 To keep things from getting confusing, the PDU number used by the Router Key PDU in version 1 is now registered as reserved (and unused) in version 0 🧠
The policy for adding to the registry is RFC Required per [RFC8126]. The document must be either Standards Track or Experimental 📝
The "rpki-rtr-pdu" registry has been updated like this 👇
Protocol PDU
Version Type Description
-------- ---- ---------------
0-1 0 Serial Notify
0-1 1 Serial Query
0-1 2 Reset Query
0-1 3 Cache Response
0-1 4 IPv4 Prefix
0-1 6 IPv6 Prefix
0-1 7 End of Data
0-1 8 Cache Reset
0 9 Reserved
1 9 Router Key
0-1 10 Error Report
0-1 255 ReservedAll the existing entries in the IANA "rpki-rtr-error" registry remain valid for all protocol versions 🌈 Version 1 adds one brand-new error code 🆕
Error
Code Description
----- ---------------------------
8 Unexpected Protocol Version15. References 📚
15.1. Normative References
These are the must-reads, the ones you absolutely need to know to get the whole vibe 🤓
- [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, DOI 10.17487/RFC1982, August 1996, <https://www.rfc-editor.org/info/rfc1982>.
- [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>.
- [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 1998, <https://www.rfc-editor.org/info/rfc2385>.
- [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
- [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, January 2006, <https://www.rfc-editor.org/info/rfc4252>.
- [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.
- [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
- [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, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
- [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>.
- [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)", RFC 5926, DOI 10.17487/RFC5926, June 2010, <https://www.rfc-editor.org/info/rfc5926>.
- [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, DOI 10.17487/RFC6125, March 2011, <https://www.rfc-editor.org/info/rfc6125>.
- [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, <https://www.rfc-editor.org/info/rfc6487>.
- [RFC6810] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol", RFC 6810, DOI 10.17487/RFC6810, January 2013, <https://www.rfc-editor.org/info/rfc6810>.
- [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>.
- [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
- [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>.
- [RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key Formats, and Signature Formats", RFC 8208, DOI 10.17487/RFC8208, September 2017, <http://www.rfc-editor.org/info/rfc8208>.
15.2. Informative References
These are the extra-credit reads for when you want to go deeper 🧐
- [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, August 1996, <https://www.rfc-editor.org/info/rfc1996>.
- [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", RFC 4808, DOI 10.17487/RFC4808, March 2007, <https://www.rfc-editor.org/info/rfc4808>.
- [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010, <https://www.rfc-editor.org/info/rfc5781>.
- [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>.
- [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, DOI 10.17487/RFC6481, February 2012, <https://www.rfc-editor.org/info/rfc6481>.
Acknowledgements 🫶
The authors want to thank Nils Bars, Steve Bellovin, Tim Bruijnzeels, Rex Fernando, Richard Hansen, Paul Hoffman, Fabian Holler, Russ Housley, Pradosh Mohapatra, Keyur Patel, David Mandelberg, Sandy Murphy, Robert Raszuk, Andreas Reuter, Thomas C. Schmidt, John Scudder, Ruediger Volk, Matthias Waehlisch, and David Ward 💖 Special shoutout to Hannes Gredler for showing everyone the dangers of unnecessary fields 🙈
No doubt this list is incomplete 🥺 Apologies to any contributor whose name got missed 🌸
Authors' Addresses 🖋️
Randy Bush Internet Initiative Japan 5147 Crystal Springs Bainbridge Island, Washington 98110 United States of America
Email: randy@psg.com
Rob Austein Dragon Research Labs
Email: sra@hactrn.net
📦 where this page comes from
- ietf: rfc8210 2017-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms