idnits 2.17.1 draft-spaghetti-grow-nrtm-v4-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 60 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: A mirror server may use caching infrastructure to cache the Database Configuration File and reduce the load of HTTPS requests. Unlike some of the other files, this file is both very small and quite rarely retrieved, limiting the need for and benefits of caching. Since this file is used by mirror clients to determine the current signing key, this SHOULD not cached for longer than one minute to support key rotations. -- The document date (3 February 2022) is 812 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) ** Downref: Normative reference to an Informational RFC: RFC 8032 -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GROW S. Romijn 3 Internet-Draft Reliably Coded 4 Intended status: Standards Track J. Snijders 5 Expires: 7 August 2022 Fastly 6 E. Shryane 7 RIPE NCC 8 S. Konstantaras 9 AMS-IX 10 3 February 2022 12 Near Real Time Mirroring (NRTM) version 4 13 draft-spaghetti-grow-nrtm-v4-00 15 Abstract 17 This document specifies a one-way synchronization protocol for 18 Internet Routing Registry (IRR) records. The protocol allows 19 instances of IRR database servers to mirror IRR records, specified in 20 in the Routing Policy Specification Language (RPSL), between each 21 other. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 27 "OPTIONAL" in this document are to be interpreted as described in BCP 28 14 [RFC2119] [RFC8174] when, and only when, they appear in all 29 capitals, as shown here. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on 7 August 2022. 48 Copyright Notice 50 Copyright (c) 2022 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Revised BSD License text as 59 described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Revised BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Informal overview . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Mirror server use . . . . . . . . . . . . . . . . . . . . . . 5 67 3.1. Key Configuration and the Database Configuration File . . 5 68 3.2. Snapshot Initialization . . . . . . . . . . . . . . . . . 5 69 3.3. Publishing updates . . . . . . . . . . . . . . . . . . . 6 70 3.3.1. Delta Files . . . . . . . . . . . . . . . . . . . . . 6 71 3.3.2. Snapshot Files . . . . . . . . . . . . . . . . . . . 7 72 3.3.3. Update Notification File . . . . . . . . . . . . . . 7 73 3.3.4. Publication Policy Restrictions . . . . . . . . . . . 8 74 4. Mirror client use . . . . . . . . . . . . . . . . . . . . . . 8 75 4.1. Configuration . . . . . . . . . . . . . . . . . . . . . . 8 76 4.2. Initialization from snapshot . . . . . . . . . . . . . . 8 77 4.3. Processing Delta Files . . . . . . . . . . . . . . . . . 9 78 4.4. Signature and Staleness Verification . . . . . . . . . . 10 79 4.5. Policy Restrictions . . . . . . . . . . . . . . . . . . . 10 80 5. Database Configuration File . . . . . . . . . . . . . . . . . 10 81 5.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 5.2. Cache concerns . . . . . . . . . . . . . . . . . . . . . 11 83 5.3. File format and validation . . . . . . . . . . . . . . . 11 84 6. Update Notification File . . . . . . . . . . . . . . . . . . 12 85 6.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 6.2. Cache concerns . . . . . . . . . . . . . . . . . . . . . 12 87 6.3. File format and validation . . . . . . . . . . . . . . . 12 88 6.4. Signature . . . . . . . . . . . . . . . . . . . . . . . . 14 89 7. Snapshot File . . . . . . . . . . . . . . . . . . . . . . . . 14 90 7.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 7.2. Cache Concerns . . . . . . . . . . . . . . . . . . . . . 14 92 7.3. File format and validation . . . . . . . . . . . . . . . 15 93 8. Delta File . . . . . . . . . . . . . . . . . . . . . . . . . 16 94 8.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 16 95 8.2. Cache Concerns . . . . . . . . . . . . . . . . . . . . . 16 96 8.3. File format and validation . . . . . . . . . . . . . . . 16 97 9. Operational Considerations . . . . . . . . . . . . . . . . . 18 98 9.1. IRR object Validation . . . . . . . . . . . . . . . . . . 18 99 9.2. Intermediate mirror instances . . . . . . . . . . . . . . 19 100 9.3. Reading from local files . . . . . . . . . . . . . . . . 19 101 9.4. Public key rotation . . . . . . . . . . . . . . . . . . . 19 102 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 103 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 104 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 105 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 106 13.1. Normative References . . . . . . . . . . . . . . . . . . 20 107 13.2. Informative References . . . . . . . . . . . . . . . . . 22 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 110 1. Introduction 112 The Internet Routing Registry (IRR) consists of several different IRR 113 Databases, each storing objects in the Routing Policy Specification 114 Language (RPSL). About a dozen larger IRR Databases are well known 115 and widely used, operated by different organisations, like RIRs and 116 some large network operators. IRR objects serve many purposes, 117 ranging from manual research by operators to automated network 118 configuration and filtering. 120 Most of these well known IRR Databases mirror IRR objects from some 121 others, so that queries run against these instances provide a 122 comprehensive view. Some parties also mirror IRR Databases to 123 private IRR server instances, to reduce latency in queries, analyze 124 IRR objects, or other purposes. 126 NRTM version 4 is a protocol for IRR mirroring, designed to address 127 issues in existing IRR Database mirroring protocols. In NRTMv4, IRR 128 Databases publish their records on a HTTPS endpoint, with periodic 129 Snapshot Files and regular Delta Files. Signing allows integrity 130 checks. By only generating files once and publishing them over 131 HTTPS, scalability is dramatically improved. It borrows some 132 concepts in [RFC8182], as there are overlaps between the two 133 protocols. 135 2. Informal overview 137 In NRTMv4, a mirror server is an instance of IRR Database software 138 that has a database of IRR objects and publishes them to allow 139 mirroring by others. This can be retrieved by mirror clients, which 140 then load the IRR objects into their local storage. 142 Publication consists of three different files: 144 * A single Update Notification File. This specifies the current 145 Database version and locations of the Snapshot File and Delta 146 Files. Additionally, there is an Update Notification Signature 147 File, used to verify the authenticity of the Update Notification 148 File. 150 * A single active Snapshot File. This contains all published IRR 151 objects at a particular version. The mirror server periodically 152 generates a new snapshot. 154 * Zero or more Delta Files. These contain the changes between two 155 database version numbers. 157 Mirror clients initially retrieve the small Update Notification File 158 and a Snapshot File, from which they initialize their local copy of 159 the Database. After that, mirror clients only retrieve the Update 160 Notification File periodically to determine whether there are any 161 changes, and then retrieve only the relevant Delta Files, if any. 162 This minimizes data transfer. Deltas have sequential versions. 164 A mirror client is configured from a Database Configuration File on a 165 well-known URL, which contains a public signing key which it uses to 166 verify the Update Notification File, which in turn contains hashes of 167 all the Snapshot and Delta Files. 169 Upon initialization, the mirror server generates a session ID for the 170 Database. This allows long term caching and used by the client to 171 determine that the Delta Files continue to form a full set of changes 172 allowing an update to the latest version. If the mirror server loses 173 partial history, or the mirror client starts mirroring from a 174 different server, the session ID change will force a full reload from 175 the latest Snapshot File, ensuring there are no accidental mirroring 176 gaps. 178 Mirror servers can use caching to reduce their load, particularly 179 because snapshots and deltas are immutable for a given session ID and 180 version number. These are also the largest files. Update 181 Notification Files may not be cached for longer than one minute, but 182 are fairly small. 184 Note that in NRTMv4, a contiguous version number is used for the 185 Database version and Delta Files. This is different and unrelated to 186 the serial in NRTMv3. NRTMv3 serials refer to a single change to a 187 single object, whereas a NRTMv4 version refers to one delta, possibly 188 containing multiple changes to multiple objects. NRTMv3 serials can 189 also contain gaps, NRTMv4 versions may not. 191 3. Mirror server use 193 3.1. Key Configuration and the Database Configuration File 195 _REMOVE BEFORE PUBLICATION: this whole section is wide open to 196 suggestions / ideas_ 198 When enabling NRTMv4 publication for an IRR Database, the operator 199 MUST generate and configure a private Ed25519 [RFC8032] key. Then, 200 the operator MUST publish the public key, the name of the IRR 201 Database and the URL of the Update Notification File in the Database 202 Configuration File. This is a JSON file on a well-known URI on the 203 "irr-nrtm.json" suffix on the operator's authoritative domain name 204 [RFC8615]. 206 The authoritative domain name is the domain which is generally known 207 by the IRR community to belong to the operator of the IRR Database. 208 Note that the Update Notification File, Snapshot File and Delta Files 209 MAY also be hosted on the authoritative domain, or an entirely 210 different host or domain. 212 It is RECOMMENDED that implementations provide easily accessible 213 tools for operators to generate new Ed25519 keys to enter into their 214 configuration, and propose a Database Configuration File from the 215 current configuration. Configuration options SHOULD be clearly named 216 to indicate that they are private keys. 218 3.2. Snapshot Initialization 220 A mirror server MUST follow the initialization steps upon the first 221 export for an IRR Database by that mirror server, or if the server 222 lost history and can not reliably produce a continuous set of deltas 223 from a previous state. 225 In other words, either the mirror server guarantees that clients 226 following the deltas have a correct and complete view, or MUST 227 reinitialize, which will force clients to reinitialize as well. 229 Initialization consists of these actions: 231 * The mirror server MUST generate a new session ID. This MUST be a 232 random v4 UUID [RFC4122] and MUST be the same across all client 233 sessions. However, if the server instance is serving two 234 different IRR databases (e.g. RIPE IRR and RIPE-NONAUTH IRR), 235 then it MUST generate two session IDs, each one associated with 236 the different database. 238 * The server MUST generate a snapshot for version number one. This 239 may contain an empty array of objects if the IRR Database is 240 currently empty. 242 * The server MUST generate a new Update Notification File with the 243 new session ID, a reference to the new snapshot, and no deltas. 245 * The Update Notification Signature File MUST be updated for the new 246 Update Notification File contents. 248 Note that session IDs, versions and all files always relate to a 249 specific IRR Database. For example, a mirror server publishing 250 NRTMv4 for RIPE and RIPE-NONAUTH, will generate two Update 251 Notification Files, referring two Snapshot Files, and two sets of 252 Delta Files each with contiguous version numbers - all completely 253 independent to each other, with different session IDs. This applies 254 even if the same IRR server instance produces both. 256 3.3. Publishing updates 258 3.3.1. Delta Files 260 Changes to IRR objects MUST be recorded in Delta Files. One Delta 261 File can contain multiple changes. 263 Updates are generated as follows: 265 * A mirror server MUST publish a Delta File approximately every 266 minute, if there have been changes to IRR objects in that time 267 frame. 269 * If multiple changes have occurred within the time frame that would 270 cancel each other out, like an addition and immediate deletion of 271 the same object, the mirror server MUST still include all these 272 changes. 274 * If a mirror server is lagging in production of Delta Files, such 275 as after an initialization or server downtime, it MUST generate 276 one larger "catch up" Delta File, rather than individual Delta 277 Files for every one minute window. 279 * A new Delta File MUST be generated with a new version, one greater 280 than the last Delta File version, or one greater than the last 281 Snapshot File version if there were no prior deltas at all. 283 * The Delta File MUST include all changes that happened during the 284 time frame, in the order in which they occurred. 286 * The URL where the Delta File is published MUST contain the session 287 ID and version number to allow it to be indefinitely cached. It 288 MUST also contain a random value that can not be predicted before 289 publication, to counter negative caching issues. 291 * After generating a new Delta File, a mirror server MUST remove all 292 Delta Files older than 24 hours. 294 * The Update Notification File MUST be updated to include the new 295 Delta File and update the database version. 297 3.3.2. Snapshot Files 299 Snapshot Files after initialization are generated as follows: 301 * The mirror server MUST generate a new Snapshot File between once 302 per hour and once per day, if there have been changes to the IRR 303 objects. 305 * The version number of the new snapshot MUST be equal to the last 306 Delta File version. 308 * If there have been no changes to the IRR objects since the last 309 snapshot, the mirror server MUST NOT generate a new snapshot. 311 * The URL where the Snapshot File is published MUST contain the 312 session ID and version number to allow it to be indefinitely 313 cached. It MUST also contain a random value that can not be 314 predicted before publication, to counter negative caching issues. 316 * The Update Notification File MUST be updated to include the new 317 snapshot, if one was generated. 319 3.3.3. Update Notification File 321 The Update Notification File must be updated when a new Delta or 322 Snapshot File is published and, even if there have been no changes, 323 at least every 24 hours. 325 After any update to the Update Notification file, the mirror server 326 MUST also update the Update Notification Signature File for the new 327 Update Notification File contents. 329 3.3.4. Publication Policy Restrictions 331 A mirror server MAY have a policy that restricts the publication of 332 certain IRR objects or attributes, or modifies these before 333 publication. Typical scenarios for this include preventing the 334 distribution of certain personal data or password hashes, or 335 excluding objects which do not meet validation rules like RPKI 336 consistency. It is RECOMMENDED to modify objects in such a way that 337 this change is evident to humans reading the object text, for example 338 by adding remark lines or comments. 340 Mirror servers are RECOMMENDED to remove password hashes from the 341 auth lines in mntner objects, as they have little use beyond the 342 authoritative server, and their publication may be a security risk. 344 If a mirror server has a policy that restricts or modifies object 345 publication, this MUST be applied consistently to Snapshot Files and 346 Delta Files from the moment the policy is enacted or modified. 348 4. Mirror client use 350 4.1. Configuration 352 _REMOVE BEFORE PUBLICATION: this whole section is wide open to 353 suggestions / ideas_ 355 Mirror clients are configured with the name of an IRR Database to 356 mirror and the domain considered authoritative by the mirror client 357 operator, which hosts the Database Configuration File. The mirror 358 client MUST retrieve this file, look for an entry under the expected 359 IRR Database name, and read the Update Notification File URL and the 360 public key. The mirror client MUST only allow retrieval of this file 361 over HTTPS. 363 The mirror client MUST retrieve the Database Configuration File every 364 24 hours, and update its local configuration if any settings in the 365 file have changed. 367 4.2. Initialization from snapshot 369 Clients MUST initialize from a Snapshot File when initially 370 configured or if they are not able to update their local data from 371 the provided Delta Files: 373 * The client MUST retrieve the Update Notification File. 375 * The client MUST verify that the source attribute in the Update 376 Notification File matches the configured IRR Database name. 378 * The client MUST retrieve the Snapshot File and load the objects 379 into its local storage. 381 * The mirror client MUST verify that the hash of the Snapshot File 382 matches the hash in the Update Notification File that referenced 383 it. In case of a mismatch of this hash, the file MUST be 384 rejected. 386 * The client MUST record the configured authoritative domain, the 387 session_id and version from the Update Notification File. 389 4.3. Processing Delta Files 391 If a mirror client has previously initialized from a snapshot: 393 * The client MUST verify that the configured Update Notification 394 File URL matches the previously known URL. If this does not 395 match, the client MUST reinitialize from the Snapshot File, using 396 the new Update Notification File URL. 398 * The client MUST retrieve the Update Notification File. 400 * The client MUST verify that the session ID matches the previously 401 known session ID. If this does not match, the client MUST 402 reinitialize from the snapshot. 404 * The client MUST verify that the Update Notification File version 405 is the same or higher than the client's current most recent 406 version, to the latest version in the Update Notification File. 407 If not, the Update Notification File MUST be rejected. 409 * The client MUST verify that the Update Notification File contains 410 one contiguous set of Delta File versions from the client's 411 current most recent version up to the latest version in the Update 412 Notification File. If this is not found, the client MUST 413 reinitialize from the snapshot. 415 * The client MUST retrieve all Delta Files for versions since the 416 client's last known version, if there are any. 418 * The mirror client MUST verify that the hash of each newly 419 downloaded Delta File matches the hash in the Update Notification 420 File that referenced it. In case of a mismatch of this hash, the 421 Delta File MUST be rejected. 423 * The client MUST process all changes in the Delta Files in order: 424 lowest Delta File version number first, and in the order of the 425 changes list in the Delta File. 427 * The client MUST update its record of the most recent version to 428 the version of the Update Notification File. 430 If the Update Notification File or one of the Delta Files is 431 rejected, the mirror client MUST NOT process any newer Deltas than 432 those that are valid and have been successfully verified. 434 4.4. Signature and Staleness Verification 436 Every time a mirror client retrieves a new version of the Update 437 Notification File, it MUST retrieve and verify the Update 438 Notification Signature File. The signature MUST be valid for the 439 configured public key for the contents of the Update Notification 440 File. 442 If the signature does not match, the mirror client MUST reject the 443 Update Notification File and retrieve the Database Configuration 444 File, as a mismatch may be caused by a key rotation by the mirror 445 server operator. If the Database Configuration File contains a new 446 public key, the mirror client will attempt to use that key for 447 signature verification instead. 449 A mirror client can use the generation timestamp in the Update 450 Notification File to check whether the file is stale, as the mirror 451 server must update this file at least every 24 hours. If the 452 generation timestamp is more than 24 hours ago, the file is stale and 453 the mirror client SHOULD warn the operator in log messages or other 454 alerting, but MAY continue to process it otherwise. 456 4.5. Policy Restrictions 458 A mirror client MAY have a policy that restricts the processing of 459 objects to certain object classes, or other limitations on which 460 objects it processes. 462 If a mirror client has a policy that restricts object processing, 463 this MUST be applied consistently to Snapshot Files and Delta Files 464 from the moment the policy is enacted or modified. 466 5. Database Configuration File 468 _REMOVE BEFORE PUBLICATION: this whole section is wide open to 469 suggestions / ideas_ 471 5.1. Purpose 473 The Database Configuration File is provided by the IRR Database 474 operator as configuration information for mirror clients. For each 475 IRR Database run by an operator, it contains the current signing key, 476 Snapshot Notification File URL and the IRR Database name. This JSON 477 file MUST be placed on a well-known URI [RFC8615] on the "irr- 478 nrtm.json" suffix on the authoritative domain name of the IRR 479 Database operator and must be available over HTTPS. 481 The operator MUST update this file if any of these configuration 482 details change. 484 5.2. Cache concerns 486 A mirror server may use caching infrastructure to cache the Database 487 Configuration File and reduce the load of HTTPS requests. Unlike 488 some of the other files, this file is both very small and quite 489 rarely retrieved, limiting the need for and benefits of caching. 490 Since this file is used by mirror clients to determine the current 491 signing key, this SHOULD not cached for longer than one minute to 492 support key rotations. 494 5.3. File format and validation 496 Example Database Configuration File: 498 [ 499 { 500 "source": "EXAMPLE-A", 501 "update_notification": "https://example.net/db/nrtmv4/example-a/notification.json", 502 "key": "96..ae" 503 }, 504 { 505 "source": "EXAMPLE-B", 506 "update_notification": "https://cdn.example.com/db/nrtmv4/example-b/notification.json", 507 "key": "b6..3d", 508 } 509 ] 511 Note: the keys in this example are shortened because of formatting. 513 The following validation rules MUST be observed when creating or 514 parsing Database Configuration Files: 516 * The source contains the IRR Database name and MUST be a valid IRR 517 object name [RFC2622], which matches the source in the referred 518 Update Notification File. 520 * The update_notification MUST be the HTTPS URL of the Update 521 Notification File. 523 * The key MUST be the Ed25519 [RFC8032] public key encoded in base64 524 [RFC4648], which the mirror server uses to sign the Update 525 Notification File. 527 * The file MUST contain at least one entry for an IRR Database, but 528 MAY contain multiple with different source values. 530 * The file MUST only contain US-ASCII characters. 532 6. Update Notification File 534 6.1. Purpose 536 The Update Notification File is generated by the mirror server and 537 used by mirror clients to discover whether any changes exist between 538 the state of the IRR mirror server and of the mirror client's. It 539 also describes the location of the Snapshot File and incremental 540 Delta Files. Finally, the generation timestamp can be used to detect 541 whether the file is stale. 543 The mirror server MUST generate a new Update Notification File every 544 time there are new deltas or snapshots and, even if there have been 545 no changes, at least every 24 hours. 547 6.2. Cache concerns 549 A mirror server may use caching infrastructure to cache the Update 550 Notification File and reduce the load of HTTPS requests. 552 However, since this file is used by mirror clients to determine 553 whether any updates are available, the mirror server SHOULD ensure 554 that this file is not cached for longer than one minute. An 555 exception to this rule is that it is better to serve a stale Update 556 Notification File rather than no Update Notification File. 558 6.3. File format and validation 560 Example Update Notification File: 562 { 563 "nrtm_version": 4, 564 "timestamp": "2022-01-00T15:00:00Z", 565 "type": "notification", 566 "source": "EXAMPLE", 567 "session_id": "ca128382-78d9-41d1-8927-1ecef15275be", 568 "version": 3, 569 "snapshot": { 570 "version": 2, 571 "url": "https://example.com/ca128382-78d9-41d1-8927-1ecef15275be/nrtm-snapshot.2.047595d0fae972fbed0c51b4a41c7a349e0c47bb.json", 572 "hash": "9a..86" 573 } 574 "deltas": [ 575 { 576 "version": 1, 577 "url": "https://example.com/ca128382-78d9-41d1-8927-1ecef15275be/nrtm-delta.1.784a2a65aba22e001fd25a1b9e8544e058fbc703.json", 578 "hash": "62..a2" 579 } 580 { 581 "version": 2, 582 "url": "https://example.com/ca128382-78d9-41d1-8927-1ecef15275be/nrtm-delta.2.0f681f07cfab5611f3681bf030ec9f6fa3442fb0.json", 583 "hash": "25..9a" 584 } 585 { 586 "version": 3, 587 "url": "https://example.com/ca128382-78d9-41d1-8927-1ecef15275be/nrtm-delta.3.d9c194acbb2cb0d4088c9d8a25d5871cdd802c79.json", 588 "hash": "b4..13" 589 } 590 ] 591 } 593 Note: hash values in this example are shortened because of 594 formatting. 596 The following validation rules MUST be observed when creating or 597 parsing Update Notification Files: 599 * The nrtm_version MUST be 4. 601 * The timestamp MUST be an [RFC3339] timestamp. 603 * The type MUST be "notification". 605 * The source MUST be a valid IRR object name [RFC2622]. 607 * The session_id attribute MUST be a random v4 UUID [RFC4122] unique 608 to this session for this source. 610 * The version MUST be an unsigned positive integer and be equal to 611 the highest version of the deltas and snapshot. 613 * The file MUST contain exactly one snapshot. 615 * The file MAY contain one or more deltas. 617 * The deltas MUST have a sequential contiguous set of version 618 numbers. 620 * Each snapshot and delta element MUST have a version, HTTPS URL and 621 hash attribute. 623 * The hash attribute in snapshot and delta elements MUST be the 624 hexadecimal encoding of the SHA-256 hash [SHS] of the referenced 625 file. The mirror client MUST verify this hash when the file is 626 retrieved and reject the file if the hash does not match. 628 * The file MUST only contain US-ASCII characters. 630 6.4. Signature 632 The contents of Update Notification File MUST be signed using Ed25519 633 [RFC8032]. The public key for this signature is published in the 634 Database Configuration File. The signature of the Update 635 Notification File MUST be published under the same path as the Update 636 Notification File, appending ".sig". 638 7. Snapshot File 640 7.1. Purpose 642 The Snapshot File reflects the complete and current contents of all 643 IRR objects in an IRR Database. Mirror clients MUST use this to 644 initialize their local copy of the IRR Database. 646 7.2. Cache Concerns 648 A snapshot reflects the content of the IRR Database at a specific 649 point in time; for that reason, it can be considered immutable data. 650 Snapshot Files MUST be published at a URL that is unique to the 651 specific session and version. The URL MUST also contain a random 652 value that can not be predicted before publication, to counter 653 negative caching issues. 655 Because these files never change, they MAY be cached indefinitely. 656 However, as snapshots are large and old snapshots will no longer be 657 referred by newer Update Notification Files, it is RECOMMENDED that a 658 limited interval is used in the order of hours or days. 660 To avoid race conditions where a mirror client retrieves an Update 661 Notification File moments before it's updated, mirror servers SHOULD 662 retain old Snapshot Files for at least 5 minutes after a new Update 663 Notification File is published. 665 7.3. File format and validation 667 Example Snapshot File: 669 { 670 "nrtm_version": 4, 671 "type": "snapshot", 672 "source": "EXAMPLE", 673 "session_id": "ca128382-78d9-41d1-8927-1ecef15275be", 674 "version": 2, 675 "objects": [ 676 "route: 192.0.2.0/24\norigin: AS65530\nsource: EXAMPLE", 677 "route: 2001:db8::/32\norigin: AS65530\nsource: EXAMPLE" 678 ] 679 } 681 Note: IRR object texts in this example are shortened because of 682 formatting. 684 The following validation rules MUST be observed when creating or 685 parsing Snapshot Files: 687 * The nrtm_version MUST be 4. 689 * The type MUST be "snapshot". 691 * The source MUST match the source in the Update Notification File. 693 * The session_id attribute MUST match the session_id in the Update 694 Notification File. 696 * The version MUST be an unsigned positive integer, matching the 697 Update Notification File entry for this snapshot. 699 * The objects attribute MUST be an array of zero or more elements, 700 each containing a string representation of an IRR object. The 701 string representation MUST be encoded in UTF-8 in Quoted-Printable 702 encoding [RFC2045]. 704 * The source attribute in the IRR object texts MUST match the source 705 attribute of the Snapshot File. 707 * The file MUST only contain US-ASCII characters. 709 8. Delta File 711 8.1. Purpose 713 A Delta File contains all changes for exactly one incremental update 714 of the IRR Database. It may include new, modified and deleted 715 objects. Delta Files can contain multiple alterations to multiple 716 objects. 718 8.2. Cache Concerns 720 Deltas reflect the difference in content of the IRR Database from one 721 version to another; for that reason, it can be considered immutable 722 data. Delta Files MUST be published at a URL that is unique to the 723 specific session and version. The URL MUST also contain a random 724 value that can not be predicted before publication, to counter 725 negative caching issues. 727 To avoid race conditions where a mirror client retrieves an Update 728 Notification File moments before it's updated, mirror servers SHOULD 729 retain old Delta Files for at least 5 minutes after a new Update 730 Notification File is published that no longer contains these Delta 731 Files. 733 8.3. File format and validation 735 Example Delta File: 737 { 738 "nrtm_version": 4, 739 "type": "delta", 740 "source": "EXAMPLE", 741 "session_id": "ca128382-78d9-41d1-8927-1ecef15275be", 742 "version": 3, 743 "changes": [ 744 { 745 "action": "delete", 746 "existing_object": "route: 192.0.2.0/24\norigin: AS65530\nsource: EXAMPLE", 747 } 748 { 749 "action": "add_modify", 750 "new_object": "route: 2001:db8::/32\norigin: AS65530\nsource: EXAMPLE", 751 } 752 ] 753 } 755 Note: IRR object texts in this example are shortened because of 756 formatting. 758 The following validation rules MUST be observed when creating or 759 parsing Delta Files: 761 * The nrtm_version MUST be 4. 763 * The type MUST be "delta". 765 * The source MUST match the source in the Update Notification File. 767 * The session_id attribute MUST match the session_id in the Update 768 Notification File. 770 * The version MUST be an unsigned positive integer, matching the 771 Update Notification File entry for this delta. 773 * The changes attribute MUST be an array of one or more elements, 774 each having: 776 - An action attribute, which is either "delete" for object 777 deletions, or "add_modify" for additions or modifications. 779 - If action is "delete": an existing_object attribute with the 780 RPSL text of the last version of the object prior to deletion. 782 - If action is "add_modify": a new_object attribute with the RPSL 783 text of the new version of the object. 785 - The string representation of the objects MUST be encoded in 786 UTF-8 in Quoted-Printable encoding [RFC2045]. 788 * The source attribute in the IRR object texts MUST match the source 789 attribute of the Delta File. 791 * The file MUST only contain US-ASCII characters. 793 9. Operational Considerations 795 9.1. IRR object Validation 797 Throughout the years, various implementations of IRR servers have 798 taken liberties with the various RFCs regarding RPSL. 799 Implementations have introduced different new object classes, 800 attributes and validation rules. Current IRR Databases also contain 801 legacy objects which were created under different validation rules. 802 In practice, there is no uniformly implemented standard for RPSL, but 803 merely rough outlines partially documented in different places. 805 This has the potential to create interoperability issues. Some are 806 addressed by NRTMv4, like having a consistent character set when 807 mirroring data between implementations. However, some issues can not 808 be addressed in this way, such as one implementation introducing a 809 new object class that is entirely unknown to another implementation. 811 A mirror client SHOULD be able to handle unknown object classes and 812 objects that are invalid according to its own validation rules, which 813 may mean simply discarding them, without rejecting remaining objects 814 or preventing future updates. 816 It is RECOMMENDED for mirror clients to log these cases, particularly 817 those where an object was discarded due to violating validation 818 rules. These cases create an inconsistency between the IRR objects 819 of the server and client, and logs facilitate later analysis. 821 It is RECOMMENDED for mirror clients to be flexible where possible 822 and reasonable when applying their own validation rules to IRR 823 objects retrieved from mirror servers. For example, a route object 824 with an origin attribute that is not a valid AS number can't be 825 usefully interpreted. There is no way for an IRR server to correctly 826 parse and index such an object. However, a route-set object whose 827 name does not start with "RS-" [RFC2622], or an inetnum with an 828 unknown extra "org" attribute, still allows the mirror client to 829 interpret it unambiguously even if it does not meet the mirror 830 client's own validation rules for authoritative records. 832 9.2. Intermediate mirror instances 834 An IRR Database generally has a single authoritative source. In some 835 cases, an instance run by a third party will function as a kind of 836 intermediate: both being a mirror client, mirroring IRR objects from 837 the authoritative source, and simultaneously function as a mirror 838 server to yet another mirror client. 840 There are various operational reasons for such a setup, such as the 841 intermediate filtering certain records. Regardless of the reason, 842 the mirror client and server function of an IRR server must be 843 treated as separate processes. In particular, this means they MUST 844 have separate session IDs. The intermediate server MUST NOT 845 republish the same files it retrieved from the authoritative source 846 with the same session ID. 848 9.3. Reading from local files 850 In the typical use case for NRTMv4, a mirror client retrieves files 851 from an HTTPS endpoint. However, implementations MAY also support 852 reading from files on the local filesystem instead, for when 853 operators want to use a different method to retrieve or distribute 854 the files. When reading from local files, mirror clients SHOULD 855 still follow all validation rules, including the validation of the 856 signature and hashes. 858 9.4. Public key rotation 860 It is RECOMMENDED that IRR Database operators rotate the signing key 861 on their mirror server about once per year. To support this, the 862 mirror server implementation MUST provide a way for operators to 863 immediately generate a new Update Notification File on demand. To 864 perform the rotation, the operator then: 866 * Generates a new key. 868 * Prepares a new Database Configuration File with the new public 869 key. 871 * Configures the new private key in the mirror server software. 873 * Makes the mirror server software generate a new Update 874 Notification File. 876 * Publishes the new Database Configuration File. 878 Mirror clients will load the Update Notification File, find the 879 signature to be invalid, retrieve the Database Configuration File and 880 configure the new key. Note that key rotation will briefly but 881 significantly increase the retrievals of the Database Configuration 882 File, as almost every current mirror client will retrieve it within 883 the minute after publication of the new Update Notification File. 885 10. Security Considerations 887 IRR objects serve many purposes, including automated network 888 configuration and filtering. Manipulation of IRR objects can 889 therefore have a significant security impact. However, security in 890 existing protocols is mostly absent. 892 Before NRTMv4, the most common protocols for IRR Database mirroring 893 are FTP for retrieving full snapshots, and NRTM version 3 for 894 retrieving later changes. There are no provisions for integrity or 895 authenticity, and there are various scenarios where mirroring may not 896 be reliable. 898 NRTMv4 requires integrity verification. The Delta and Snapshot Files 899 are verified using the SHA-256 hash in the Update Notification File, 900 and the Update Notification File is verified using its signature 901 file. Additionally, the channel security offered by HTTPS further 902 limits security risks. 904 By allowing publication on any HTTPS endpoint, NRTMv4 allows for 905 extensive scaling, and there are many existing techniques and 906 services to protect against denial-of-service attacks. In contrast, 907 NRTMv3 required mirror clients to directly query the IRR server 908 instance with special whois queries. This scales poorly, and there 909 are no standard protections against denial-of-service available. 911 The HTTPS endpoint used for NRTMv4 MUST be configured according to 912 the best practices in [RFC7525]. 914 11. IANA Considerations 916 This document requests IANA to ... 918 12. Acknowledgments 920 The authors would like to thank ... and ... for their helpful 921 review of this document. 923 13. References 925 13.1. Normative References 927 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 928 Extensions (MIME) Part One: Format of Internet Message 929 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 930 . 932 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 933 Requirement Levels", BCP 14, RFC 2119, 934 DOI 10.17487/RFC2119, March 1997, 935 . 937 [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., 938 Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, 939 "Routing Policy Specification Language (RPSL)", RFC 2622, 940 DOI 10.17487/RFC2622, June 1999, 941 . 943 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 944 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 945 . 947 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 948 Unique IDentifier (UUID) URN Namespace", RFC 4122, 949 DOI 10.17487/RFC4122, July 2005, 950 . 952 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 953 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 954 . 956 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 957 "Recommendations for Secure Use of Transport Layer 958 Security (TLS) and Datagram Transport Layer Security 959 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 960 2015, . 962 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 963 Signature Algorithm (EdDSA)", RFC 8032, 964 DOI 10.17487/RFC8032, January 2017, 965 . 967 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 968 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 969 May 2017, . 971 [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers 972 (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, 973 . 975 [SHS] National Institute of Standards and Technology, "Secure 976 Hash Standard", March 2012, 977 . 980 13.2. Informative References 982 [RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, 983 "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, 984 DOI 10.17487/RFC8182, July 2017, 985 . 987 Authors' Addresses 989 Sasha Romijn 990 Reliably Coded 991 Amsterdam 992 Netherlands 994 Email: sasha@reliablycoded.nl 996 Job Snijders 997 Fastly 998 Amsterdam 999 Netherlands 1001 Email: job@fastly.com 1003 Edward Shryane 1004 RIPE NCC 1005 Amsterdam 1006 Netherlands 1008 Email: eshryane@ripe.net 1010 Stavros Konstantaras 1011 AMS-IX 1012 Amsterdam 1013 Netherlands 1015 Email: stavros.konstantaras@ams-ix.net