draft-spaghetti-grow-nrtm-v4.xml

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<?rfc sortrefs="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>

<rfc
  category="std"
  docName="draft-spaghetti-grow-nrtm-v4-00"
  ipr="trust200902">

<front>

  <title abbrev="NRTM v4">Near Real Time Mirroring (NRTM) version 4</title>

  <author fullname="Sasha Romijn" initials="S." surname="Romijn">
    <organization>DashCare</organization>
    <address>
      <postal>
        <street />
        <city>Amsterdam</city>
        <code />
        <country>Netherlands</country>
      </postal>
      <email>sasha@dashcare.nl</email>
    </address>
  </author>

  <author fullname="Job Snijders" initials="J." surname="Snijders">
    <organization>Fastly</organization>
    <address>
      <postal>
        <street />
        <city>Amsterdam</city>
        <code />
        <country>Netherlands</country>
      </postal>
      <email>job@fastly.com</email>
    </address>
  </author>

  <author fullname="Edward Shryane" initials="E." surname="Shryane">
    <organization>RIPE NCC</organization>
    <address>
      <postal>
        <street />
        <city>Amsterdam</city>
        <code />
        <country>Netherlands</country>
      </postal>
      <email>eshryane@ripe.net</email>
    </address>
  </author>

  <author fullname="Stavros Konstantaras" initials="S." surname="Konstantaras">
    <organization>AMS-IX</organization>
    <address>
      <postal>
        <street />
        <city>Amsterdam</city>
        <code />
        <country>Netherlands</country>
      </postal>
      <email>stavros.konstantaras@ams-ix.net</email>
    </address>
  </author>
  <date />

  <area>OPS</area>
  <workgroup>GROW</workgroup>
  <keyword>NRTM</keyword>
  <keyword>RPSL</keyword>
  <keyword>IRR</keyword>

  <abstract>
    <t>
      This document specifies a synchronization protocol for Internet Routing Registry (IRR) records.
      The protocol allows instances of IRR database servers to mirror IRR records, specified in in the Routing Policy Specification Language (RPSL), between each other.
    </t>
  </abstract>

  <note title="Requirements Language">
    <t>
      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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.
    </t>
  </note>

</front>

<middle>

  <section title="Introduction">
    <t>
      The Internet Routing Registry (IRR) consists of several different 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.
      RPSL objects serve many purposes, ranging from manual research by operators to automated network configuration and filtering.
    </t>

    <t>
      Most of these well known IRR Databases mirror RPSL 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, analyse RPSL objects, or other purposes.
    </t>

    <t>
      NRTM version 4 is designed to address issues in existing IRR Database mirroring protocols.
      In NRTMv4, IRR Databases publish their records on a 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 <xref target="RFC8182"/>, as there are overlaps between the two protocols.
    </t>

  </section>

  <section title="Informal overview">
    <t>
      In NRTMv4, a mirror server is an instance of IRR Database software that has a database of RPSL objects and publishes them to allow mirroring by others.
      This can be retrieved by mirror clients, which then load the RPSL objects into their local databases.
    </t>
    <t>
      Publication consists of three different files:
      <list style="symbols">
        <t>
          A single Update Notification File.
          This specifies the current Database version and locations of the Snapshot File and Delta Files.
          Additionally, there is an Update Notification Signature File, used to verify the authenticity of the Update Notification File.
        </t>
        <t>
          A single active Snapshot File.
          This contains all published RPSL objects at a particular version.
          The mirror server periodically generates a new snapshot.
        </t>
        <t>
          Zero or more Delta Files.
          These contain the changes between two database versions.
        </t>
       </list>
     </t>
     <t>
       Mirror clients initially retrieve the small Update Notification File and a Snapshot File, from which they initialise 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 minimises data transfer.
       Deltas have sequential versions. <!-- note: negative cache attack? -->
     </t>
     <t>
       A mirror client is configured with a public signing key which it uses to verify the Update Notification File, which in turn contains hashes of all the Snapshot and Delta Files.
     </t>
     <t>
       Upon initialization, the mirror server generates a session ID for the Database.
       This is used to allow for 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.
     </t>
     <t>
       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.
     </t>
     <t>
       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.
      </t>
    </section>

  <section title="Mirror server use">

    <section title="Key Configuration">
      <t>
        When enabling NRTMv4 publication for an IRR Database, an operator MUST configure a private Ed25519 <xref target="RFC8032"/>. key to be used for Update Notification Signature Files.
      </t>
      <t>
        It is RECOMMENDED that implementations provide easily accessible tools for operators to generate new Ed25519 keys to enter into their configuration, and generate the public keys from the current configuration.
        Configuration options SHOULD be clearly named to indicate that they are private keys.
      </t>
    </section>

    <section title="Snapshot Initialisation">
      <t>
        A mirror server MUST follow the initialisation 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.
      </t>
      <t>
        In other words, either the mirror server guarantees that clients following the deltas have a correct and complete view, or MUST reinitialise, which will force clients to reinitialise as well.
        !<-- SK: Should we define a procedure for that??? -->
      </t>
      <t>
        Initialisation consists of these actions:
        <list style="symbols">
          <t>
            The mirror server MUST generate a new session ID.
            This MUST be a random v4 UUID <xref target="RFC4122"/> and MUST be the same across all client sessions. However, if the server instance is serving two different IRR databases (e.g. RIPE IRR and RIPE-NONAUTH IRR), then it MUST generate two session IDs, each one associated with the different database. 
          </t>
          <t>
            The server MUST generate a snapshot for version number one.
            This may contain an empty array of objects if the IRR Database is currently empty.
          </t>
          <t>
            The server MUST generate a new Update Notification File with the new session ID, a reference to the new snapshot, and no deltas.
          </t>
          <t>
            The Update Notification Signature File MUST be updated for the new Update Notification File contents.
          </t>
        </list>
      </t>
      <t>
        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 from each other, with different session IDs.
        This applies even if the same IRR server instance produces both.
      </t>
    </section>

    <section title="Publishing updates">
      <section title="Delta Files">
        <t>
          Changes to RPSL objects MUST be recorded in Delta Files. One Delta File can contain multiple changes.
        </t>
        <t>
          Updates are generated as follows:
        </t>
        <t>
          <list style="symbols">
            <t>
              A mirror server MUST publish a Delta File approximately every minute, if there have been changes to RPSL objects in that time frame.
            </t>
            <t>
              If multiple changes have occurred within the time frame that would cancel each other out, like an addition and immediate deletion of the same object, the mirror server MUST still include all these changes.
            </t>
            <t>
              If a mirror server is lagging in production of Delta Files, such as after an initialisation or server downtime, it MUST generate one larger "catch up" Delta File, rather than individual Delta Files for every one minute window.
            </t>
            <t>
              A new Delta File MUST be generated with a new version, one greater than the last Delta File version, or one greater than the last Snapshot File version if there were no prior deltas at all.
            </t>
            <t>
              The Delta File MUST include all changes that happened during the time frame, in the order in which they occurred.
            </t>
            <t>
              The URL where the Delta File is published MUST contain the session ID and version number to allow it to be indefinitely cached.
            </t>
            <t>
              The Update Notification File MUST be updated to include the new Delta File and update the version.
            </t>
            <t>
              The Update Notification Signature File MUST be updated for the new Update Notification File contents.
            </t>
          </list>
        </t>
      </section>
      <section title="Snapshot Files">
        <t>
          Snapshot Files after initialisation are generated as follows:
        </t>
        <t>
          <list style="symbols">
            <t>
              The mirror server MUST generate a new Snapshot File between once per hour and once per day, if there have been changes to the RPSL objects.
            </t>
            <t>
              The version number of the new snapshot MUST be equal to the last Delta File version.
            </t>
            <t>
              If there have been no changes to the RPSL objects since the last snapshot, the mirror server MUST NOT generate a new snapshot.
            </t>
            <t>
              The URL where the Snapshot File is published MUST contain the session ID and version number to allow it to be indefinitely cached.
            </t>
            <t>
              If, after generating the Snapshot File, the total size of all current Delta Files up to the snapshot version, exceeds the size of the snapshot, older Delta Files MUST be removed, until the total size of the deltas is less than the size of the snapshot.
              This avoids mirror clients downloading more data than necessary.
            </t>
            <t>
              The Update Notification File MUST be updated to include the new snapshot, if one was generates.
            </t>
            <t>
              The Update Notification Signature File MUST be updated for the new Update Notification File contents.
            </t>
          </list>
        </t>
      </section>
      <section title="Publication Policy Restrictions">
        <t>
          A mirror server MAY have a policy that restricts the publication of certain RPSL objects or attributes, or modifies these before publication.
          Typical scenarios for this include preventing the distribution of certain personal data or password hashes.
          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.
        </t>
        <t>
          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.
        </t>
        <t>
          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.
        </t>
      </section>
    </section>
  </section>

  <section title="Mirror client use">

    <section title="Initialisation from snapshot">
      <t>
        Mirror clients are configured with the URL to an Update Notification File, the name of the IRR Database to mirror, and the public key of the IRR Database.
        Clients MUST NOT allow mirroring to be configured when one of these settings is missing.
      </t>
      <t>
        Clients MUST initialise from a Snapshot File when initially configured, or -if they are not able to update their local data- from the provided Delta Files:
      </t>
      <list style="symbols">
        <t>
          The client MUST retrieve the Update Notification File.
        </t>
        <t>
          The client MUST verify that the source attribute in the Update Notification File matches the configured IRR Database name.
        </t>
        <t>
          The client MUST retrieve the Snapshot File and load the objects into its local storage.
        </t>
        <t>
          The mirror client MUST verify that the hash of the Snapshot File matches the hash on the Update Notification File that referenced it.
          In case of a mismatch of this hash, the file MUST be rejected.
        </t>
        <t>
          The client MUST record the configured URL and the session_id and version from the Update Notification File.
        </t>
      </list>
    </section>
    <section title="Processing Delta Files">
      <t>
        If a mirror client has previously initialised from a snapshot:
      </t>
      <t>
        <list style="symbols">
          <t>
            The client MUST verify that the configured Update Notification File URL matches the previously known URL. If this does not match, the client MUST reinitialise from the Snapshot File, using the new Update Notification File URL.
          </t>
          <t>
            The client MUST retrieve the Update Notification File.
          </t>
          <t>
            The client MUST verify that the session ID matches the previously known session ID.
            If this does not match, the client MUST reinitialise from the snapshot.
          </t>
          <t>
            The client MUST verify that the Update Notification File version is the same or higher than the client's current most recent version, to the latest version in the Update Notification File.
            If not, the Update Notification File MUST be rejected.
          </t>
          <t>
            The client MUST verify that the Update Notification File contains one contiguous set of Delta File versions from the client's current most recent version, to the latest version in the Update Notification File.
            If this is not found, the client MUST reinitialise from the snapshot.
          </t>
          <t>
            The client MUST retrieve all Delta Files for versions since the client's last known version, if there are any.
          </t>
          <t>
            The mirror client MUST verify that the hash of each newly downloaded Delta File matches the hash on the Update Notification File that referenced it. In case of a mismatch of this hash, the Delta File MUST be rejected.
          </t>
          <t>
            The client MUST process all changes in the Delta Files, in order of the Delta File version number first, order in the "changes" attribute of individual Delta Files second.
          </t>
          <t>
            The client MUST update its most recent version to the version of the Update Notification File.
          </t>
        </list>
      </t>
      <t>
        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.
      </t>
    </section>
    <section title="Signature Verification">
      <t>
        Every time a mirror client retrieves a new version of the Update Notification File, it MUST retrieve and verify the signature.
        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.
      </t>
    </section>
    <section title="Policy Restrictions">
      <t>
        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.
      </t>
      <t>
        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.
      </t>
    </section>
  </section>

  <section title="Update Notification File">

    <section title="Purpose">
      <t>
        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 the mirror client's state.
        It also describes the location of the Snapshot File and incremental Delta Files.
      </t>
      <t>
        The mirror server MUST generate a new Update Notification File every time there are new deltas or snapshots.
      </t>
    </section>

    <section title="Cache concerns">
      <t>
        A mirror server may use caching infrastructure to cache the Update Notification File and reduce the load of HTTPS requests.
      </t>
      <t>
        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.
      </t>
    </section>

    <section title="File format and validation">
      <t>
        Example Update Notification File:
      </t>
      <t>
<artwork><![CDATA[
{
  "nrtm_version": 4,
  "type": "notification",
  "source": "EXAMPLE",
  "session_id": "ca128382-78d9-41d1-8927-1ecef15275be",
  "version": 3,
  "snapshot": {
    "version": 2,
    "url": "https://example.com/ca..be/nrtm-snapshot.2.json",
    "hash": "9a..86"
  }
  "deltas": [
    {
      "version": 1,
      "url": "https://example.com/ca..be/nrtm-delta.1.json",
      "hash": "62..a2"
    }
    {
      "version": 2,
      "url": "https://example.com/ca..be/nrtm-delta.2.json",
      "hash": "25..9a"
    }
    {
      "version": 3,
      "url": "https://example.com/ca..be/nrtm-delta.3.json",
      "hash": "b4..13"
    }
  ]
}
]]></artwork>
      </t>
      <t>
        Note: URIs and hash values in this example are shortened because of formatting.
      </t>
      <t>
        The following validation rules MUST be observed when creating or parsing Update Notification Files:
      </t>
      <t>
        <list style="symbols">
          <t>
            The nrtm_version MUST be 4.
          </t>
          <t>
            The type MUST be "notification".
          </t>
          <t>
            The source MUST be a valid RPSL object name <xref target="RFC2622"/>.
          </t>
          <t>
            The session_id attribute MUST be a random v4 UUID <xref target="RFC4122"/> unique to this session for this source.
          </t>
          <t>
            The version MUST be an unsigned positive integer and be equal to the highest version of the deltas and snapshot.
          </t>
          <t>
            The file MUST contain exactly one snapshot.
          </t>
          <t>
            The file MAY contain one or more deltas.
          </t>
          <t>
            The deltas MUST have a sequential contiguous set of version numbers.
          </t>
          <t>
            Each snapshot and delta element MUST have a version, URL and hash attribute.
          </t>
          <t>
            The hash attribute in snapshot and delta elements MUST be the hexadecimal encoding of the SHA-256 hash <xref target="SHS"/> of the referenced file.
            The mirror client MUST verify this hash when the file is retrieved and reject the file if the hash does not match.
          </t>
          <t>
            The file MUST be UTF-8 encoded.
          </t>
        </list>
      </t>
    </section>
    <section title="Signature">
      <t>
        The contents of Update Notification File MUST be signed using Ed25519 <xref target="RFC8032"/>.
        The public key for this signature must be published by the operator of the mirror server.
        The signature of the Update Notification File MUST be published under the same path as the Update Notification File, appending ".sig".
      </t>
    </section>
  </section>

  <section title="Snapshot File">

    <section title="Purpose">
      <t>
        The Snapshot File reflects the complete and current contents of all RPSL objects in an IRR Database.
        Mirror clients MUST use this to initialise their local copy of the IRR Database.
      </t>
    </section>

    <section title="Cache Concerns">
      <t>
        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.
      </t>
      <t>
        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.
      </t>
      <t>
        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.
      </t>
      <!--SK: Shouldn't we consider and expiration time for the snapshot file? Like its automatically expired when the new snaphsot is published OR 5 minutes after the new snapshot file is published? -->
    </section>

    <section title="File format and validation">
      <t>
        Example Snapshot File:
      </t>
      <t>
<artwork><![CDATA[
{
  "nrtm_version": 4,
  "type": "snapshot",
  "source": "EXAMPLE",
  "session_id": "ca128382-78d9-41d1-8927-1ecef15275be",
  "version": 2,
  "objects": [
    "route: 192.0.2.0/24\norigin: AS65530\nsource: EXAMPLE",
    "route: 2001:db8::/32\norigin: AS65530\nsource: EXAMPLE"
  ]
}
]]></artwork>
      </t>
      <t>
        Note: RPSL object texts in this example are shortened because of formatting.
      </t>
      <t>
        The following validation rules MUST be observed when creating or parsing Snapshot Files:
      </t>
      <t>
        <list style="symbols">
          <t>
            The nrtm_version MUST be 4.
          </t>
          <t>
            The type MUST be "snapshot".
          </t>
          <t>
            The source MUST match the source in the Update Notification File.
          </t>
          <t>
            The session_id attribute MUST match the session_id in the Update Notification File.
          </t>
          <t>
            The version MUST be an unsigned positive integer, matching the Update Notification File entry for this snapshot.
          </t>
          <t>
            The objects attribute MUST be an array of zero or more elements, each containing a string representation of an RPSL object.
          </t>
          <t>
            The source attribute in the RPSL object texts MUST match the source attribute of the Snapshot File.
          </t>
          <t>
            The file MUST be UTF-8 encoded.
          </t>
        </list>
      </t>
    </section>

  </section>

  <section title="Delta File">

    <section title="Purpose">
      <t>
        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.
      </t>
    </section>
    <!--SK: Under which circumstances a new Delta file is published? Is this something that we need to define? -->

    <section title="Cache Concerns">
      <t>
        Deltas reflects 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.
      </t>
      <t>
        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.
      </t>
    </section>

    <section title="File format and validation">
      <t>
        Example Delta File:
      </t>
      <t>
<artwork><![CDATA[
{
  "nrtm_version": 4,
  "type": "delta",
  "source": "EXAMPLE",
  "session_id": "ca128382-78d9-41d1-8927-1ecef15275be",
  "version": 3,
  "changes": [
    {
      "action": "delete",
      "existing_object": "route: 192.0.2.0/24\norigin: AS65530\nsource: EXAMPLE",
    }
    {
      "action": "add_modify",
      "new_object": "route: 2001:db8::/32\norigin: AS65530\nsource: EXAMPLE",
    }
  ]
}
]]></artwork>
      </t>
      <t>
        Note: RPSL object texts in this example are shortened because of formatting.
      </t>
      <t>
        The following validation rules MUST be observed when creating or parsing Delta Files:
      </t>
      <t>
        <list style="symbols">
          <t>
            The nrtm_version MUST be 4.
          </t>
          <t>
            The type MUST be "delta".
          </t>
          <t>
            The source MUST match the source in the Update Notification File.
          </t>
          <t>
            The session_id attribute MUST match the session_id in the Update Notification File.
          </t>
          <t>
            The version MUST be an unsigned positive integer, matching the Update Notification File entry for this delta.
          </t>
          <t>
            The changes attribute MUST be an array of one or more elements, each having:
            <list style="symbols">
              <t>
                An action attribute, which is either "delete" for object deletions, or "add_modify" for additions or modifications.
              </t>
              <t>
                If action is "delete": an existing_object attribute with the RPSL text of the last version of the object prior to deletion.
              </t>
              <t>
                If action is "add_modify": a new_object attribute with the RPSL text of the new version of the object.
              </t>
            </list>
          </t>
          <t>
             The source attribute in the RPSL object texts MUST match the source attribute of the Delta File.
          </t>
          <t>
            The file MUST be UTF-8 encoded.
          </t>
        </list>
      </t>
    </section>
  </section>

  <section title="Operational Considerations">

    <section title="RPSL Object Validation">
      <t>
        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.
      </t>
      <t>
        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.
      </t>
      <t>
        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.
      </t>
      <t>
        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 RPSL objects of the server and client, and logs facilitate later analysis.
      </t>
      <t>
        It is RECOMMENDED for mirror clients to be flexible where possible and reasonable when applying their own validation rules to RPSL 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-" <xref target="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.
      </t>
    </section>

    <section title="Intermediate mirror instances">
      <t>
        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 RPSL objects from the authoritative source, and simultaneously function as a mirror server to yet another mirror client.
      </t>
      <t>
        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.
      </t>
    </section>

    <section title="HTTPS Considerations">
      <t>
        TODO
      </t>
    </section>

  </section>

  <section title="Security Considerations">

    <t>
      RPSL objects serve many purposes, including automated network configuration and filtering.
      Manipulation of RPSL objects can therefore have a significant security impact.
      However, security in existing protocols is mostly absent.
    </t>
    <t>
      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.
    </t>
    <t>
      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.
    </t>
    <t>
      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.
    </t>

  </section>

  <section title="IANA Considerations">
    <t>
      This document requests IANA to ...
    </t>
  </section>

  <section title="Acknowledgements">
    <t>
      The authors would like to thank
      ...
      and
      ...
      for their helpful review of this document.
    </t>
  </section>

</middle>

<back>

  <references title="Normative References">
    <?rfc include="reference.RFC.2119.xml"?>
    <?rfc include="reference.RFC.2622.xml"?>
    <?rfc include="reference.RFC.4122.xml"?>
    <?rfc include="reference.RFC.8032.xml"?>
    <?rfc include="reference.RFC.8174.xml"?>
    <reference anchor="SHS" target="http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf">
      <front>
        <title>Secure Hash Standard</title>
        <author>
        <organization>National Institute of Standards and Technology</organization>
        </author>
        <date month="March" year="2012" />
      </front>
    </reference>
  </references>

  <references title="Informative References">
    <?rfc include="reference.RFC.8182.xml"?>
  </references>

</back>

</rfc>