Internet-Draft | NRTM v4 | November 2022 |
Romijn, et al. | Expires 25 May 2023 | [Page] |
This document specifies a one-way synchronization protocol for Internet Routing Registry (IRR) records. The protocol allows instances of IRR database servers to mirror IRR records, specified in the Routing Policy Specification Language (RPSL), between each other.¶
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 25 May 2023.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The Internet Routing Registry (IRR) consists of several IRR Databases, each storing objects in the Routing Policy Specification Language (RPSL). About a dozen larger IRR Databases are well known and widely used, operated by different organisations, like RIRs and some large network operators. IRR objects serve many purposes, ranging from manual research by operators to automated network configuration and filtering.¶
Most of these well known IRR Databases mirror IRR objects from some others, so that queries run against these instances provide a comprehensive view. Some parties also mirror IRR Databases to private IRR server instances, to reduce latency in queries, analyze IRR objects, or other purposes.¶
NRTM version 4 is a protocol for IRR mirroring, designed to address issues in existing IRR Database mirroring protocols. In NRTMv4, IRR Databases publish their records on an HTTPS endpoint, with periodic Snapshot Files and regular Delta Files. Signing allows integrity checks. By only generating files once and publishing them over HTTPS, scalability is dramatically improved. It borrows some concepts in [RFC8182], as there are overlaps between the two protocols.¶
In NRTMv4, a mirror server is an instance of IRR Database software that has a database of IRR objects and publishes them to allow mirroring by others. This can be retrieved by mirror clients, which then load the IRR objects into their local storage.¶
Publication consists of three different files:¶
All files MUST be in the JavaScript Object Notation (JSON) format [RFC4627].¶
Mirror clients initially retrieve the small Update Notification File and a Snapshot File, from which they initialize their local copy of the Database. After that, mirror clients only retrieve the Update Notification File periodically to determine whether there are any changes, and then retrieve only the relevant Delta Files, if any. This minimizes data transfer. Deltas have sequential versions.¶
Mirror clients are configured with the URL of an Update Notification File, name of the IRR Database, and a public signing key. This public key is used to verify the Update Notification File, which in turn contains hashes of all the Snapshot and Delta Files.¶
Upon initialization, the mirror server generates a session ID for the Database. This allows long term caching and used by the client to determine that the Delta Files continue to form a full set of changes allowing an update to the latest version. If the mirror server loses partial history, or the mirror client starts mirroring from a different server, the session ID change will force a full reload from the latest Snapshot File, ensuring there are no accidental mirroring gaps.¶
Mirror servers can use caching to reduce their load, particularly because snapshots and deltas are immutable for a given session ID and version number. These are also the largest files. Update Notification Files may not be cached for longer than one minute, but are fairly small.¶
Note that in NRTMv4, a contiguous version number is used for the Database version and Delta Files. This is different and unrelated to the serial in NRTMv3. NRTMv3 serials refer to a single change to a single object, whereas a NRTMv4 version refers to one delta, possibly containing multiple changes to multiple objects. NRTMv3 serials can also contain gaps, NRTMv4 versions may not.¶
When enabling NRTMv4 publication for an IRR Database, the operator MUST generate and configure a private Ed25519 [RFC8032] key. The operator then provides this public key, the name of the IRR Database, and publication URL of the Update Notification File to any operators of mirror clients. The process for providing this is not in scope of this protocol, but a typical case is publication on the operator's known website. Key rotation is described in Section 8.4.¶
It is RECOMMENDED that implementations provide easily accessible tools for operators to generate new Ed25519 keys to enter into their configuration and assist with key rotation. All configuration options SHOULD be clearly named to indicate that they are private keys.¶
A mirror server MUST follow the initialization steps upon the first export for an IRR Database by that mirror server, or if the server lost history and can not reliably produce a continuous set of deltas from a previous state.¶
In other words, either the mirror server guarantees that clients following the deltas have a correct and complete view, or MUST reinitialize, which will force clients to reinitialize as well.¶
Initialization consists of these actions:¶
Note that session IDs, versions and all files always relate to a specific IRR Database. For example, a mirror server publishing NRTMv4 for RIPE and RIPE-NONAUTH, will generate two Update Notification Files, referring two Snapshot Files, and two sets of Delta Files each with contiguous version numbers - all completely independent to each other, with different session IDs. This applies even if the same IRR server instance produces both.¶
Changes to IRR objects MUST be recorded in Delta Files. One Delta File can contain multiple changes.¶
Updates are generated as follows:¶
Snapshot Files after initialization are generated as follows:¶
The Update Notification File must be updated when a new Delta or Snapshot File is published and, even if there have been no changes, at least every 24 hours.¶
After any update to the Update Notification file, the mirror server MUST also update the Update Notification Signature File for the new Update Notification File contents.¶
A mirror server MAY have a policy that restricts the publication of certain IRR objects or attributes, or modifies these before publication. Typical scenarios for this include preventing the distribution of certain personal data or password hashes, or excluding objects which do not meet validation rules like RPKI consistency. It is RECOMMENDED to modify objects in such a way that this change is evident to humans reading the object text, for example by adding remark lines or comments.¶
Mirror servers are RECOMMENDED to remove password hashes from the auth lines in mntner objects, as they have little use beyond the authoritative server, and their publication may be a security risk.¶
If a mirror server has a policy that restricts or modifies object publication, this MUST be applied consistently to Snapshot Files and Delta Files from the moment the policy is enacted or modified.¶
Mirror clients are configured with the name of the IRR Database, the URL of the Update Notification File, and the public key currently used for signing the Update Notification File. Key rotation is described in Section 8.4.¶
Clients MUST initialize from a Snapshot File when initially configured or if they are not able to update their local data from the provided Delta Files:¶
If a mirror client has previously initialized from a snapshot:¶
If the Update Notification File or one of the Delta Files is rejected, the mirror client MUST NOT process any newer Deltas than those that are valid and have been successfully verified.¶
Every time a mirror client retrieves a new version of the Update Notification File, it MUST retrieve and verify the Update Notification Signature File. The signature MUST be valid for the configured public key for the contents of the Update Notification File. If the signature does not match, the mirror client MUST reject the Update Notification File, unless a key rotation is in progress as described in Section 8.4.¶
A mirror client can use the generation timestamp in the Update Notification File to check whether the file is stale, as the mirror server must update this file at least every 24 hours. If the generation timestamp is more than 24 hours ago, the file is stale and the mirror client SHOULD warn the operator in log messages or other alerting, but MAY continue to process it otherwise.¶
A mirror client MAY have a policy that restricts the processing of objects to certain object classes, or other limitations on which objects it processes.¶
If a mirror client has a policy that restricts object processing, this MUST be applied consistently to Snapshot Files and Delta Files from the moment the policy is enacted or modified.¶
The Update Notification File is generated by the mirror server and used by mirror clients to discover whether any changes exist between the state of the IRR mirror server and of the mirror client's. It also describes the location of the Snapshot File and incremental Delta Files. Finally, the generation timestamp can be used to detect whether the file is stale.¶
The mirror server MUST generate a new Update Notification File every time there are new deltas or snapshots and, even if there have been no changes, at least every 24 hours.¶
A mirror server may use caching infrastructure to cache the Update Notification File and reduce the load of HTTPS requests.¶
However, since this file is used by mirror clients to determine whether any updates are available, the mirror server SHOULD ensure that this file is not cached for longer than one minute. An exception to this rule is that it is better to serve a stale Update Notification File rather than no Update Notification File.¶
Example Update Notification File:¶
{ "nrtm_version": 4, "timestamp": "2022-01-00T15:00:00Z", "type": "notification", "next_signing_key": "96..ae", "source": "EXAMPLE", "session_id": "ca128382-78d9-41d1-8927-1ecef15275be", "version": 4, "snapshot": { "version": 3, "url": "https://example.com/ca128382-78d9-41d1-8927-1ecef15275be/nrtm-snapshot.2.047595d0fae972fbed0c51b4a41c7a349e0c47bb.json", "hash": "9a..86" }, "deltas": [ { "version": 2, "url": "https://example.com/ca128382-78d9-41d1-8927-1ecef15275be/nrtm-delta.1.784a2a65aba22e001fd25a1b9e8544e058fbc703.json", "hash": "62..a2" }, { "version": 3, "url": "https://example.com/ca128382-78d9-41d1-8927-1ecef15275be/nrtm-delta.2.0f681f07cfab5611f3681bf030ec9f6fa3442fb0.json", "hash": "25..9a" }, { "version": 4, "url": "https://example.com/ca128382-78d9-41d1-8927-1ecef15275be/nrtm-delta.3.d9c194acbb2cb0d4088c9d8a25d5871cdd802c79.json", "hash": "b4..13" } ] }¶
Note: hash values in this example are shortened because of formatting.¶
The following validation rules MUST be observed when creating or parsing Update Notification Files:¶
The contents of Update Notification File MUST be signed using Ed25519 [RFC8032]. The public key for this signature is configured in the client. The signature of the Update Notification File MUST be published under the same path as the Update Notification File, appending ".sig".¶
The Snapshot File reflects the complete and current contents of all IRR objects in an IRR Database. Mirror clients MUST use this to initialize their local copy of the IRR Database.¶
A snapshot reflects the content of the IRR Database at a specific point in time; for that reason, it can be considered immutable data. Snapshot Files MUST be published at a URL that is unique to the specific session and version. The URL MUST also contain a random value that can not be predicted before publication, to counter negative caching issues.¶
Because these files never change, they MAY be cached indefinitely. However, as snapshots are large and old snapshots will no longer be referred by newer Update Notification Files, it is RECOMMENDED that a limited interval is used in the order of hours or days.¶
To avoid race conditions where a mirror client retrieves an Update Notification File moments before it's updated, mirror servers SHOULD retain old Snapshot Files for at least 5 minutes after a new Update Notification File is published.¶
Example Snapshot File:¶
{ "nrtm_version": 4, "type": "snapshot", "source": "EXAMPLE", "session_id": "ca128382-78d9-41d1-8927-1ecef15275be", "version": 3, "objects": [ "route: 192.0.2.0/24\norigin: AS65530\nsource: EXAMPLE", "route: 2001:db8::/32\norigin: AS65530\nsource: EXAMPLE" ] }¶
Note: IRR object texts in this example are shortened because of formatting.¶
The following validation rules MUST be observed when creating or parsing Snapshot Files:¶
A Delta File contains all changes for exactly one incremental update of the IRR Database. It may include new, modified and deleted objects. Delta Files can contain multiple alterations to multiple objects.¶
Deltas reflect the difference in content of the IRR Database from one version to another; for that reason, it can be considered immutable data. Delta Files MUST be published at a URL that is unique to the specific session and version. The URL MUST also contain a random value that can not be predicted before publication, to counter negative caching issues.¶
To avoid race conditions where a mirror client retrieves an Update Notification File moments before it's updated, mirror servers SHOULD retain old Delta Files for at least 5 minutes after a new Update Notification File is published that no longer contains these Delta Files.¶
Example Delta File:¶
{ "nrtm_version": 4, "type": "delta", "source": "EXAMPLE", "session_id": "ca128382-78d9-41d1-8927-1ecef15275be", "version": 3, "changes": [ { "action": "delete", "object_class": "person", "primary_key": "PRSN1-EXAMPLE" }, { "action": "delete", "object_class": "route", "primary_key": "192.0.2.0/24AS65530" }, { "action": "add_modify", "object": "route: 2001:db8::/32\norigin: AS65530\nsource: EXAMPLE" } ] }¶
Note: IRR object texts in this example are shortened because of formatting.¶
The following validation rules MUST be observed when creating or parsing Delta Files:¶
The changes attribute MUST be an array of one or more elements, each having:¶
Throughout the years, various implementations of IRR servers have taken liberties with the various RFCs regarding RPSL. Implementations have introduced different new object classes, attributes and validation rules. Current IRR Databases also contain legacy objects which were created under different validation rules. In practice, there is no uniformly implemented standard for RPSL, but merely rough outlines partially documented in different places.¶
This has the potential to create interoperability issues. Some are addressed by NRTMv4, like having a consistent character set when mirroring data between implementations. However, some issues can not be addressed in this way, such as one implementation introducing a new object class that is entirely unknown to another implementation.¶
A mirror client SHOULD be able to handle unknown object classes and objects that are invalid according to its own validation rules, which may mean simply discarding them, without rejecting remaining objects or preventing future updates.¶
It is RECOMMENDED for mirror clients to log these cases, particularly those where an object was discarded due to violating validation rules. These cases create an inconsistency between the IRR objects of the server and client, and logs facilitate later analysis.¶
It is RECOMMENDED for mirror clients to be flexible where possible and reasonable when applying their own validation rules to IRR objects retrieved from mirror servers. For example, a route object with an origin attribute that is not a valid AS number can't be usefully interpreted. There is no way for an IRR server to correctly parse and index such an object. However, a route-set object whose name does not start with "RS-" [RFC2622], or an inetnum with an unknown extra "org" attribute, still allows the mirror client to interpret it unambiguously even if it does not meet the mirror client's own validation rules for authoritative records.¶
An IRR Database generally has a single authoritative source. In some cases, an instance run by a third party will function as a kind of intermediate: both being a mirror client, mirroring IRR objects from the authoritative source, and simultaneously function as a mirror server to yet another mirror client.¶
There are various operational reasons for such a setup, such as the intermediate filtering certain records. Regardless of the reason, the mirror client and server function of an IRR server must be treated as separate processes. In particular, this means they MUST have separate session IDs. The intermediate server MUST NOT republish the same files it retrieved from the authoritative source with the same session ID.¶
In the typical use case for NRTMv4, a mirror client retrieves files from an HTTPS endpoint. However, implementations MAY also support reading from files on the local filesystem instead, for when operators want to use a different method to retrieve or distribute the files. When reading from local files, mirror clients SHOULD still follow all validation rules, including the validation of the signature and hashes.¶
It is RECOMMENDED that IRR Database operators rotate the signing key on their mirror server about once per year. The next_signing_key field in the Update Notification File supports in-band key rotation using the following process:¶
If a mirror client never retrieves an Update Notification file at any point during the rotation process, it will no longer be able to verify the signature. In that scenario manual recovery is required, similar to a first time configuration of a new mirror client.¶
IRR objects serve many purposes, including automated network configuration and filtering. Manipulation of IRR objects can therefore have a significant security impact. However, security in existing protocols is mostly absent.¶
Before NRTMv4, the most common protocols for IRR Database mirroring are FTP for retrieving full snapshots, and NRTM version 3 for retrieving later changes. There are no provisions for integrity or authenticity, and there are various scenarios where mirroring may not be reliable.¶
NRTMv4 requires integrity verification. The Delta and Snapshot Files are verified using the SHA-256 hash in the Update Notification File, and the Update Notification File is verified using its signature file. Additionally, the channel security offered by HTTPS further limits security risks.¶
By allowing publication on any HTTPS endpoint, NRTMv4 allows for extensive scaling, and there are many existing techniques and services to protect against denial-of-service attacks. In contrast, NRTMv3 required mirror clients to directly query the IRR server instance with special whois queries. This scales poorly, and there are no standard protections against denial-of-service available.¶
The HTTPS endpoint used for NRTMv4 MUST be configured according to the best practices in [RFC7525].¶
This document requests IANA to ...¶
The authors would like to thank George Michaelson, and ... for their helpful review of this document.¶