RFC 6837

NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database ✨

okay bestie, here's the title block first 💅

• Stream: Independent Submission 🎀
• RFC: 6837
• Authors: E. Lear, Cisco Systems GmbH 🧚
• Category: Experimental 🔥
• Date: January 2013 🌸
• ISSN: 2070-1721
• Obsoletes / Updates: the header doesn't list any RFCs this one obsoletes or updates, so no drama there 🫶

Abstract 🦋

Okay so LISP (the Locator/ID Separation Protocol) wraps IP packets so end sites can route to each other without injecting routes from one end of the Internet to the other. This memo brings an experimental database, plus a discussion of how to get EID-to-RLOC mappings (EIDs are Endpoint IDs, RLOCs are Routing Locators) to routers in a reliable, scalable, and secure way. The analysis concludes that sending all EID-to-RLOC mappings scales well to at least 10^8 entries. Literally iconic 😭✨

Status of This Memo 🌸

Quick reality check: this document is not an Internet Standards Track specification. It's published for examination, experimental implementation, and evaluation 🙈

It defines an Experimental Protocol for the Internet community. It's a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor chose to publish it at their discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard, see Section 2 of RFC 5741 💅

For the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc6837 🔗

Copyright Notice 🎀

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document 👀

Table of Contents 📑

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
  1.1.  Applicability  . . . . . . . . . . . . . . . . . . . . . .  4
  1.2.  Base Assumptions . . . . . . . . . . . . . . . . . . . . .  4
  1.3.  What is NERD?  . . . . . . . . . . . . . . . . . . . . . .  5
  1.4.  Glossary . . . . . . . . . . . . . . . . . . . . . . . . .  6
2.  Theory of Operation  . . . . . . . . . . . . . . . . . . . . .  7
  2.1.  Database Updates . . . . . . . . . . . . . . . . . . . . .  7
  2.2.  Communications between ITR and ETR . . . . . . . . . . . .  8
  2.3.  Who are database authorities?  . . . . . . . . . . . . . .  8
3.  NERD Format  . . . . . . . . . . . . . . . . . . . . . . . . .  9
  3.1.  NERD Record Format . . . . . . . . . . . . . . . . . . . . 11
  3.2.  Database Update Format . . . . . . . . . . . . . . . . . . 12
4.  NERD Distribution Mechanism  . . . . . . . . . . . . . . . . . 12
  4.1.  Initial Bootstrap  . . . . . . . . . . . . . . . . . . . . 12
  4.2.  Retrieving Changes . . . . . . . . . . . . . . . . . . . . 12
5.  Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
  5.1.  Database Size  . . . . . . . . . . . . . . . . . . . . . . 14
  5.2.  Router Throughput versus Time  . . . . . . . . . . . . . . 16
  5.3.  Number of Servers Required . . . . . . . . . . . . . . . . 16
  5.4.  Security Considerations  . . . . . . . . . . . . . . . . . 18
    5.4.1.  Use of Public Key Infrastructures (PKIs) . . . . . . . 19
    5.4.2.  Other Risks  . . . . . . . . . . . . . . . . . . . . . 21
6.  Why not use XML? . . . . . . . . . . . . . . . . . . . . . . . 21
7.  Other Distribution Mechanisms  . . . . . . . . . . . . . . . . 22
  7.1.  What about DNS as a mapping retrieval model? . . . . . . . 22
  7.2.  Use of BGP and LISP+ALT  . . . . . . . . . . . . . . . . . 24
  7.3.  Perhaps use a hybrid model?  . . . . . . . . . . . . . . . 24
8.  Deployment Issues  . . . . . . . . . . . . . . . . . . . . . . 24
  8.1.  HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.  Open Questions . . . . . . . . . . . . . . . . . . . . . . . . 25
10. Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 26
11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
  12.1. Normative References . . . . . . . . . . . . . . . . . . . 27
  12.2. Informative References . . . . . . . . . . . . . . . . . . 27
Appendix A.  Generating and Verifying the Database Signature
             with OpenSSL  . . . . . . . . . . . . . . . . . . . . 30

1. Introduction ✨

So LISP ([RFC6830]) splits an IP address used by a host and local routing system from the Locators advertised by BGP participants on the Internet in general, and in the Default-Free Zone (DFZ) especially. How? By setting up a mapping between globally unique Endpoint IDs (EIDs) and Routing Locators (RLOCs). The payoff is less state change on routers inside the DFZ, while end sites can still be multihomed. It's giving efficiency 🧠💖

Now, in some mapping distribution approaches to LISP, the mapping gets learned through data-triggered control messages between Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs), going through an alternate routing topology ([RFC6836]). In other LISP approaches, the EID-to-RLOC mapping gets learned some other way. This memo looks at the different approaches and specifies a Not-so-novel EID-to-RLOC Database (NERD), plus methods to both receive the database and receive updates to it 🦋

NERD is offered mainly as a way to avoid dropping packets, and the underlying assumption is that dropping packets is bad for applications and end users. If you don't agree with that assumption, other approaches might make more sense for you, and that's totally valid 🫶

NERD is specified so the methods used to distribute or retrieve it can change over time. Multiple databases are supported so there can be multiple data sources. The team made an effort to divorce the database from access methods, so both can evolve independently through experimentation and operational validation. Separation goals, bestie 👑

1.1. Applicability

This memo is based on experiments performed in the 2007-2009 time frame. At the time of publication, the author is unaware of any operational use of NERD. If you want to pursue NERD, think hard about the substantial amount of work left for the future. See Section 10 for more details 🙈

1.2. Base Assumptions

To specify a mapping, it's important to understand how it will be used and what the mapped data is like. For LISP, these assumptions matter:

• The data in the mapping changes only on provisioning or configuration operations, and it isn't meant to change when a link fails or gets restored. Some other mechanism, such as the use of LISP Reachability Bits with mapping replies, handles healing operations, especially when a tail circuit within a service provider's aggregate goes down. NERD can be used as a verification method to make sure whatever operational mapping changes an ITR receives are authorized 🔐
• Weight and priority are defined, but they aren't hop-by-hop metrics. So the information in the mapping doesn't change based on where you sit within the topology 📍
• Because a purpose of LISP is to reduce control-plane overhead by reducing "rate X state" complexity, updates to the mapping will be relatively rare 🌙
• Because NERD is designed to ease interdomain routing, its use is meant for the inter-domain environment. That means NERD is best implemented at either the customer edge or the provider edge, and there will be on the order of as many ITRs and EID-Prefixes as there are connections to Internet service providers by end customers 🏠
• As such, NERD cannot be the sole means to implement host mobility, although NERD may be used in conjunction with other mechanisms 💫

1.3. What is NERD?

NERD is a Not-so-novel EID-to-RLOC Database. It has four components:

1. a network database format;
2. a change distribution format;
3. a database retrieval/bootstrapping method; and
4. a change distribution method.

The network database format is compressible. However, at this time, we specify no compression method. NERD will make use of potentially several transport methods, but most notably HTTP ([RFC2616]). HTTP has restart and compression capabilities, and it's also widely deployed. Very reliable vibes 🧡

There are many methods to show differences between two versions of a database or a file, and UNIX's "diff" is the classic example. Here, because the data is well structured and easily keyed, we can use a very simple format for version differences. It just gives a list of EID-to-RLOC mappings that have changed, using the same record format as the database, plus a list of EIDs that are to be removed. Simple is slay 💅

1.4. Glossary

The reader is once again referred to [RFC6830] for a general glossary of terms related to LISP. The following terms are specific to this memo 📚

Base Distribution URI: An Absolute-URI as defined in Section 4.3 of [RFC3986] from which other references are relative. The base distribution URI is used to construct a URI to an EID-to-RLOC mapping database. If more than one NERD is known, there will be one or more base distribution URIs associated with each one (although each such base distribution URI may have the same value) 🔗

EID Database Authority: The authority that will sign database files and updates. It is the source of both 🖊️

The Authority: Shorthand for the EID Database Authority ✍️

NERD: Not-so-novel EID-to-RLOC Database 🌸

AFI: Address Family Identifier 🧩

Pull Model: An architecture where clients pull only the information they need at any given time, such as when a packet arrives for forwarding 🧲

Push Model: An architecture in which clients receive an entire dataset, containing data they may or may not require, such as mappings for EIDs that no host served is attempting to send to 📦

Hybrid Model: An architecture in which some information is pushed toward the receiver from a source, and some information is pulled by the receiver 🍓

2. Theory of Operation 🧚

Operational functions are split into two components: database updates, and state exchange between ITR and ETR during a communication.

2.1. Database Updates 💖

okay so here's the lowdown on how NERDs get made and kept fresh ✨ (the nitty gritty is in Section 3, bestie 🧚). The general flow goes like this:

1. A NERD is generated by an authority that allocates Provider-Independent (PI) addresses, like IANA or a Regional Internet Registry (RIR), and sites use those addresses as EIDs 🎀. As part of this, the authority makes a digest for the database and signs it with a private key whose public key is part of an X.509 certificate [ITU.X509.2000] 🔐. That signature, plus a copy of the authority's public key, gets included in the NERD.
2. The NERD gets distributed to a group of well-known servers 🌸.
3. ITRs grab an initial copy of the NERD over HTTP when they come into service 🚀.
4. ITRs are preconfigured with a group of certificates. Database authorities use the matching private keys to sign the NERD. This list of certificates should be configurable by administrators 🛠️.
5. ITRs then check both that the public key is valid and that the signed digest checks out. If either one fails, the ITR tries to retrieve the NERD from a different source 😤. It keeps going until it finds a valid database or runs out of sources.
6. Once a valid NERD is retrieved, the ITR installs it into both non-volatile and local memory 💾.
7. At some point the authority updates the NERD and increments the database version counter 📈. At the same time, it generates a list of changes and signs that too, same as it did with the original database ✍️.
8. Periodically, ITRs poll their list of servers to see if a new version of the database exists 👀. When one is found, the ITR attempts to retrieve a change file from its preconfigured servers.
9. The ITR validates a change file just like it does the original database. If the change file passes validation, the ITR installs new entries, overwrites existing ones, and removes empty entries, based on what the change file says 🧹.

As time goes on, it's quite possible that an ITR probes a list of configured peers for a database or change file copy 🔍. It's equally possible that peers advertise their database version numbers to each other 📣. These methods aren't explored in depth in this memo, but they're mentioned for future consideration 🔮.

2.2. Communications between ITR and ETR 🛰️

[RFC6830] describes the basic approach to what happens when a packet arrives at an ITR, and what communications between the ITR and ETR take place. NERD gives an optimistic approach to setting up communications with an ETR that's responsible for a given EID-Prefix 🤞. State must be kept, however, on an ITR to determine whether that ETR is actually reachable 👀. It's expected that this is a common requirement across LISP mapping systems, and it'll be handled in the core LISP architecture 💅.

2.3. Who are database authorities? 👑

This memo doesn't specify who the database authority is 🤷‍♀️. That's because there are several possible operational models. In every case, the number of database authorities is meant to be small, so ITRs only need to keep a small list of authorities, kinda like how a name server caches a list of root servers 🌐.

• A single database authority exists. Here, all entries in the database are registered to a single entity, and that entity distributes the database. Because the EID space is provider-independent address space, there's no architectural requirement that address space be distributed hierarchically to anyone, unlike provider-assigned address space. So there's a natural affinity between the IANA function and the database authority function 🏛️.
• Each region runs a database authority. Here, PI address space is allocated to RIRs or to affiliates of such organizations of network operations guilds (NOGs) 🗺️. The benefit is that no single organization controls the database, and one database authority can back up another 🤝. You could picture as many as ten database authorities in this scenario. One drawback, though, is that any reference to a region imposes a notion of locality, which could potentially diminish the split between Locator and identifier 😬.
• Each country runs a database authority. This could happen should countries decide to regulate this function 🌍. It limits the scope of any single database authority, like the previous scenario describes, but it adds overhead, since the list of database authorities would grow to as many as 200, and possibly more if jurisdictions within countries attempted to regulate the function 📈. There are two drawbacks. First, as distribution of EIDs is driven to more local jurisdictions, an EID-Prefix is tied even more tightly to a location 📍. Second, a large number of database authorities will demand some sort of discovery mechanism 🔎.
• Independent operators manage database authorities. This has the appeals of being location independent and enabling competition for good performance 🏃‍♀️. The drawback is that it potentially requires a discovery mechanism.

The latter two approaches aren't mutually exclusive. While this specification allows for multiple databases, discovery mechanisms are left as future work 🔮.

3. NERD Format 🧩

The NERD consists of a header that contains a database version and a signature. The signature is generated by ignoring the signature field and setting the authentication block length to 0 (NULL) 🧮. The authentication block itself consists of a signature and a certificate whose private-key counterpart was used to generate the signature 🔏.

Records are kept sorted in numeric order, with AFI plus EID as the primary key and prefix length as the secondary key 🗂️. This way, after a database update, it should be possible to reconstruct the database to verify the digest signature, which may be retrieved separately from the database for verification purposes ✅.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Schema Vers=1 |  DB Code      |     Database Name Size        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Database Version                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Old Database Version or 0                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                        Database Name                          |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       PKCS#7 Block Size       |          Reserved             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |      PKCS#7 Block Containing Certificate and Signature        |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Database Header 📦

The DB Code field is 0 if what follows is an entire database, or 1 if what follows is an update 🔢. The Database Version field holds the database file version, which gets incremented each time the complete database is generated by the authority 🆙. In the case of an update, this field indicates the new database file version, and the old database file version is indicated in the Old Database Version field 🔄. Routers use the database file version to determine whether or not they have the most current database 💯.

The Database Name field holds a DNS-ID, as specified in [RFC6125] 🏷️. This is the name that will appear in the Subject field of the certificate used to verify the database. The whole point of the database name is to allow for more than one database, and such databases would be merged by the router 🧃. It's important that an EID-to-RLOC mapping be listed in no more than one database, lest inconsistencies arise ⚠️. However, it may be possible to transition a mapping from one database to another. During the transition period, the mappings would be identical. When they aren't, the resultant behavior will be undefined 🌀. The database name is padded with NULLs to the nearest fourth byte.

The PKCS#7 [RFC2315] authentication block contains a DER-encoded [ITU.X509.2000] signature and associated public key 🔑. For the purposes of this experiment, all implementations will support the RSA encryption signature algorithm and the SHA1 digest algorithm, and the standard attributes are expected to be present 🧪.

N.B., it has been suggested that the Cryptographic Message Syntax (CMS) [RFC5652] be used instead of PKCS#7 💭. At the time this experiment was performed, CMS wasn't yet widely deployed. However, it is certainly the correct direction and should be strongly considered in future related work 🚀.

3.1. NERD Record Format 🎀

okay so here's what a NERD record looks like once it's floating around the network 🦋 (the diagram is lowkey the main character):

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Num. RLOCs    | EID Pref. Len  |           EID AFI            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Endpoint identifier                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Priority 1    |    Weight 1   |             AFI 1             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Routing Locator 1                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Priority 2    |    Weight 2   |             AFI 2             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Routing Locator 2                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Priority 3    |    Weight 3   |             AFI 3             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Routing Locator 3...                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

so EID AFI is the AFI of the EID 💅. Priority N, Weight N, and AFI N all go together and belong to Routing Locator N. there's always at least one RLOC, no cap 🫶. the minimum record size for IPv4 is 16 bytes, and every extra IPv4 RLOC adds 8 bytes. the whole point of this format is keeping the database compact but still somewhat easy to read 🧚. the meaning of weight and priority is described in [RFC6830]. the AFI format is specified by IANA in the "Address Family Numbers" registry, except for how IPv6 EID-Prefixes get stored ✨.

okay now this part is so iconic 😭. NERD assumes the EIDs in the database are prefixes, so they always come with prefix lengths. to keep IPv6 storage and transmission small, only the number of bytes the prefix length actually needs get kept, rounded to the nearest 4-byte (word) boundary. for example, a /49 prefix needs 8 bytes after that rounding 🌸. IPv6 RLOCs are just normal 128-bit IPv6 addresses 💜.

3.2. Database Update Format 🦋

a database update is basically a bundle of changes to a database that already exists 💖. every {AFI, EID, mask-length} tuple can have zero or more RLOCs attached. if there are no RLOCs, the EID entry gets removed from the database 💀. if the EID and prefix length weren't listed before, the record just gets added. if they were, the old record gets replaced with the newer info 🔥. the record format used by the update is the same one from Section 3.1, so no new format to learn, bestie 🍓.

4. NERD Distribution Mechanism ✨

4.1. Initial Bootstrap 🌈

bootstrap happens when a router needs the entire database. it knows it needs all of it because either it has none, or the update is too big to process, which could happen if the router has been offline for a seriously long time 😭.

so to bootstrap, the ITR tacks the database name plus "/current/entiredb" onto a base distribution URI and grabs the file over HTTP 🎀. here's the formal version, using ABNF from [RFC5234]:

   entire-db =    base-uri dbname "/current/entiredb"
   base-uri  =    uri ; from RFC 3986
   dbname    =    DNS-ID ; from RFC 6125

for example, if the base distribution URI is http://www.example.com/eiddb/ and the database name is nerd.arin.net, the ITR would request http://www.example.com/eiddb/nerd.arin.net/current/entiredb 🧚. before installing the database, routers check its signature, and they also check that the database schema matches one they understand 🔐. once a router has a valid database, it stores it in some kind of non-volatile memory (like disk, flash memory, etc) 💾.

N.B., the host part of those URIs should not resolve to a LISP EID, or we'd create a circular dependency and nobody wants that 🙈.

4.2. Retrieving Changes 💅

to grab a set of database changes, an ITR has to have already retrieved the entire database first. that means it knows which version it currently has 🫶. step one for changes is grabbing the current version number: append "/current/version" to the base distribution URI and database name, then retrieve that file. it's plain text and holds the integer value of the current database version 🍓.

once the ITR has the current version, it compares it with its local copy. if there's no difference, the router is up to date and doesn't need to do anything else until its next check ✨.

if the versions differ, the router next requests the right change file by appending "current/changes/" plus the text form of its local version number to the base distribution URI. formally:

   db-version    =    base-uri dbname "/current/version"
   db-curupdate  =    base-uri dbname "/current/changes/" old-version
   old-version   =    1*DIGIT

for example, say the current database version is 1105503, the router's version is 1105500, and the base URI and database name are the same as before. the router would first request http://www.example.com/eiddb/nerd.arin.net/current/version to confirm it's out of date and to learn the current version. then it would try to retrieve http://www.example.com/eiddb/nerd.arin.net/current/changes/1105500 🦋.

the server might not have that change file, either because there are too many versions between the router's version and the current one, or because no such change file was ever generated 💀. if the server has changes from the router's version to any later version, it issues an HTTP redirect to that change file, and the router retrieves and processes it 🔥. formally:

   db-incupdate    =    base-uri dbname "/" newer-version
                        "/changes/" old-version
   newer-version   =    1*DIGIT

for example, http://www.example.com/eiddb/nerd.arin.net/1105450/changes/1105401 would update a router from version 1105401 to 1105450 💜. once it's done, the router should repeat the process until it's fully caught up 🌸.

okay but this begs the question 👀: how does a router know to retrieve version 1105450 in our example? it can't. the server has to give a redirect to that URI when the router asks for differences from the current version, which in this case is 1105503 🎀.

is version wrapping a thing? unlikely 🙈, since database versions are 32-bit integers. but just in case it happens, ITRs should first try to retrieve a change file when their current version number is within 10,000 of 2^32 and they see an available version that's less than 10,000. if there's no change file available, the ITR can still assume the database version has wrapped and retrieve a fresh copy 🧚. it may be safer in future work to include additional wrap information or a larger field, so nobody has to rely on heuristics 🫶.

5. Analysis 💖

we're gonna start by looking at how much data gets transferred to a router during bootstrap. then we'll look at the bandwidth required. next, we'll turn to servers. finally, we'll ponder what happens when only changes are provided 🔮.

in the analysis below, we treat the overhead of the database header as insignificant (because it is) ✨. the analysis should look similar whether a single database or multiple databases are used, since we'd assume no entry shows up more than once 🌈.

5.1. Database Size 🍓

by its very nature, the information being transported is pretty static and is specifically designed to be topologically insensitive 💅. basically, every ITR is meant to have the same set of RLOCs for a given EID. some processing power is needed to install a table, but it should be way less than what a routing information database needs, because the level of entropy is meant to be lower 🦋.

for this analysis, we're going to assume the world has migrated to IPv6, because that makes the database bigger, which is our main concern 😭. to keep the size increase in check, we've limited the size of the prefix that gets transmitted. for this analysis, we'll assume an average prefix length of 64 bits 🎀.

based on that assumption, Section 3.1 says mapping information for each EID/prefix includes a group of RLOCs, each with its own priority and weight. a minimum record size with IPv6 EIDs that have at least one RLOC is 30 bytes uncompressed, and each additional IPv6 RLOC costs 20 bytes 💜.

             +-----------+--------+--------+---------+
             | 10^n EIDs | 2 RLOC | 4 RLOC |  8 RLOC |
             +-----------+--------+--------+---------+
             |         4 | 500 KB | 900 KB | 1.70 MB |
             |         5 | 5.0 MB | 9.0 MB | 17.0 MB |
             |         6 |  50 MB |  90 MB |  170 MB |
             |         7 | 500 MB | 900 MB | 1.70 GB |
             |         8 | 5.0 GB | 9.0 GB | 17.0 GB |
             +-----------+--------+--------+---------+

   Table 1: Database size for IPv6 routes with average prefix length of
                                  64 bits

the entries in the table above come from this formula 🧮:

    E * (30 + 20 * (R - 1 ))

where E = number of EIDs (10^n), and R = number of RLOCs per EID 🌸.

our scaling target is to accommodate 10^8 multihomed systems 👑, which is one order of magnitude more than what's discussed in [CARP07]. at 10^8 entries, a device could be expected to use between 5 and 17 GB of RAM for the mapping 😳. no matter the distribution method, any router sitting in the core of the Internet would need close to that much memory to perform the ITR function. large-enterprise ETRs would be similarly strained, just because of how many different sites talk to one another 💀. the good news is that this isn't our starting point, it's our scaling target, a number we intend to reach by the year 2050 🧚. our starting point is more likely around 10^4 or 10^5 EIDs, which means somewhere between 500 KB and 17 MB 🎀✨.

5.2. Router Throughput versus Time 🚀

Okay so, the table is the whole vibe here, so here it is:

       +-------------------+---------+---------+----------+--------+
       | Table Size (10^n) |  1 MB/s | 10 MB/s | 100 MB/s | 1 GB/s |
       +-------------------+---------+---------+----------+--------+
       |                 6 |       8 |     0.8 |     0.08 |  0.008 |
       |                 7 |      80 |       8 |      0.8 |   0.08 |
       |                 8 |     800 |      80 |        8 |    0.8 |
       |                 9 |   8,000 |     800 |       80 |      8 |
       |                10 |  80,000 |   8,000 |      800 |     80 |
       |                11 | 800,000 |  80,000 |    8,000 |    800 |
       +-------------------+---------+---------+----------+--------+

                Table 2: Number of seconds to process NERD

Bestie, the length of time it takes to receive the whole database is a big deal 😭 If the device grabs the entire table, then during that window either the router can't route packets with LISP, or it has to use some kind of query mechanism for specific EIDs while the rest of the table is still loading. Rough, right? 💀

Table 2 shows that at our scaling target, a router using 1 MB/s of bandwidth takes about 80 seconds. For any transfer speed faster than that, we can measure the processing time in small numbers of hours 🧚 The fastest processing time in the table is 8 seconds for an entire table of 10^9 bytes, and 80 seconds for 10^10 bytes. Iconic speed, no cap 🔥

5.3. Number of Servers Required

Okay, so retrieving is easy for a router, but the aggregate information might be hard for servers to send out, assuming it's sent in aggregate. (We'll come back to that assumption later, don't worry 🫶)

   +----------------+------------+-----------+------------+------------+
   | # Simultaneous | 10 Servers |       100 |      1,000 |     10,000 |
   |       Requests |            |   Servers |    Servers |    Servers |
   +----------------+------------+-----------+------------+------------+
   |            100 |        720 |        72 |         72 |         72 |
   |          1,000 |      7,200 |       720 |         72 |         72 |
   |         10,000 |     72,000 |     7,200 |        720 |         72 |
   |        100,000 |    720,000 |    72,000 |      7,200 |        720 |
   |      1,000,000 |  7,200,000 |   720,000 |     72,000 |      7,200 |
   |     10,000,000 | 72,000,000 | 7,200,000 |    720,000 |     72,000 |
   +----------------+------------+-----------+------------+------------+

         Table 3: Retrieval time per number of servers in seconds

This assumes an average of 10^8 entries with 4 RLOCs per EID. It also assumes each server has access to 1 GB/s, gets 100% efficient use of that bandwidth, and does no compression 💅

So here's how the entries in that table were made 🍓 For 10^8 entries with four RLOCs per EID, the table size is 9.0 GB, based on our previous table. Assume 1 GB/s transfer rates and 100% utilization. Protocol overhead is ignored for this exercise. That means a single transfer X takes 48 seconds and can't get any faster.

With that in mind, each entry is:

            max(1X,N*X/S)

where:

     N = number of transfers,
     X = 72 seconds, and
     S = number of servers.

Now, if we have a distribution model where every device has to retrieve the mapping information when it starts up, Table 3 shows how long it takes a given number of servers to finish a transfer to a given number of devices 👀 For example, it would take 72,000 seconds (20 hours) for 1,000,000 ITRs to all retrieve the database at once from 1,000 servers, assuming the load is spread out equally. Bestie, that's a LOT 😭

If a cold-start scenario happens, this number should be a concern. So it's important to take steps both to avoid that scenario and to ease the load if it does happen 🌸 The primary defense should be for ITRs to first try retrieving their databases from their peers or upstream providers. Secondary defenses could include data sanity checks inside ITRs, with agreed norms for how much the database should change in any single update or over any given period of time. And as we'll see below, sending out changes is way less volume, so it's giving relief 🦋

     +----------------+-------------+---------------+----------------+
     | % Daily Change | 100 Servers | 1,000 Servers | 10,000 Servers |
     +----------------+-------------+---------------+----------------+
     |           0.1% |         300 |            30 |              3 |
     |           0.5% |       1,500 |           150 |             15 |
     |             1% |       3,000 |           300 |             30 |
     |             5% |      15,000 |         1,500 |            150 |
     |            10% |      30,000 |         3,000 |            300 |
     +----------------+-------------+---------------+----------------+

       Table 4: Transfer times for hourly updates, shown in seconds

Assuming 10 million routers and a database size of 9 GB, Table 4 gives the transfer times for hourly updates, in seconds, for a given number of servers and daily rate of change. Note that when there aren't enough resources devoted to the servers, you get an unsustainable situation where updates for the next batch would start before the current batch finishes. That's a whole mess 💀

This table shows that with 10,000 servers, the average transfer time over 1 GB/s links for 10,000,000 routers will be 300 seconds, with 10% daily change spread over 24 hourly updates. For a 0.1% daily change, that number is 3 seconds for a database of 9.0 GB ✨

The amount of change is tied to the purpose of LISP 🎀

If the purpose is to give end customers effective multihoming support, then we might expect relatively few changes. But if service providers try to use LISP for some form of traffic engineering, we can expect the same data to change more often. Honestly, we can't conclude much about this without more operational experience. The one thing we can say is that different applications of LISP may need new and different distribution mechanisms. That optimization is left for another day 🧚

5.4. Security Considerations 🔐

Okay, this section is serious, so let's go 🫶

If an attacker can forge an update or tamper with the database, they can basically redirect traffic to end sites. Which is a disaster 😭 So integrity and authenticity of the NERD are critical. A means is also required to determine whether a source is authorized to modify a given database. No data privacy is required, and in fact, this information will be necessary for any ITR. Iykyk 🙈

The first question you have to ask is who to trust to give the ITR a mapping. Ultimately, the owner of the EID-Prefix is the most authoritative source for the mapping to RLOCs. But if every owner signed all of their own mappings, ITRs would need to know which owner is authorized to modify which mapping, which creates an O(N^2) complexity problem. Nobody wants that 💀

We can reduce this problem a lot by putting some trust in a small number of entities that are allowed to sign entries. If an authority manages EIDs the way a domain name registrar handles domains, then the owner of the EID picks a database authority they trust. ITRs must trust each such authority in order to map the EIDs that authority lists to RLOCs. This cuts the management complexity on the ETR down to keeping track of O(# authorities). It does require that each authority set up procedures for authenticating the owner of an EID, though. Those procedures don't need to be the same across authorities 💅

There are two classic methods to ensure integrity of data:

• secure transport of the source of the data to the consumer, such as Transport Layer Security (TLS) [RFC5246]; and
• provide object-level security.

These methods aren't mutually exclusive, although you can argue about whether the first one is needed at all once you have the second 🤷‍♀️

With TLS, when it's implemented properly, the objects being transported can't easily be modified by interlopers or so-called men in the middle 🌈 But when data objects are distributed to multiple servers, each of those servers has to be trusted. As we saw above, we could have quite a large number of servers, which gives an attacker a large number of targets. So we conclude that some form of object-level security is required 😤

Object-level security means an authority signs an object in a way that a consumer, e.g., a router, can easily verify. In this case, we'd want the mapping table and any incremental update to be signed by the originator of the update. That implies we can't just use a tool like CVS [CVS]. Instead, the originator will want to generate diffs, sign them, and make them available either directly or through some sort of content distribution or peer-to-peer network ✨

5.4.1. Use of Public Key Infrastructures (PKIs) 🔐

okay so X.509 has a certificate hierarchy that has literally scaled to the size of the whole Internet 🌐 iconic. It's most manageable when there are few certificates to manage 🧚. The model in this memo uses one current certificate per database authority ✨. That means there are two pieces of information you need to verify a signature:

• the certificate of the database authority, which can be provided along with the database; and
• the certificate authority's certificate.

Those last two bits (the "latter two," lol) must be super well known and must be configured on each ITR 🎀. Both are expected to change very rarely, and it wouldn't be unreasonable for those updates to just ride along with a normal OS release process 🍓.

Tools for signing AND verifying are super easy to get 💅. OpenSSL (http://www.openssl.org) has tools and libraries for both, and other tools commonly exist too.

ngl, using PKIs is not drama-free 😭. There's implementation complexity, operational complexity, and risk. These are the risks and mitigations identified for NERD's use of PKIs:

The private key of a NERD authority is exposed: okay this one is scary 💀. An attacker could sign a false database update, either redirecting traffic or otherwise causing havoc. The NERD administrator must revoke its existing key and issue a new one. The certificate gets added to a certificate revocation list (CRL), which may be distributed with both this and other databases, as well as through other channels. Because this event is expected to be rare, and the number of database authorities is expected to be small, a CRL will be small 🤏. When a router receives a revocation, it checks it against its existing databases and attempts to update the one that's been revoked. This implies that before issuing the revocation, the database authority would sign an update with the new key. Routers would discard updates they've already received that were signed after the revocation was generated. If a router can't confirm whether the authority's certificate was revoked before or after a particular update, it will retrieve a fresh new copy of the database with a valid signature 🔄.

The private key associated with a CA in the chain of trust of the Authority's certificate is compromised: now it's possible for an attacker to masquerade as the database authority 🎭. To ameliorate the damage, the database authority revokes its certificate and gets a new certificate issued from a CA that is not compromised. Once it has done so, the previous procedure is followed. The compromised certificate can be removed during the normal OS upgrade cycle. In the case of the root authority, the situation could be more serious 😬. Updates to the OS in the ITR need to be validated prior to installation. One possible method of doing this is provided in [RFC4108]. Trust anchors are assumed to be updated as part of an OS update, so implementors should consider using a key other than the trust anchor for validating OS updates.

An algorithm used if either the certificate or the signature is cracked: this is a catastrophic failure 🚨 and all the forms of attack above become possible. The only mitigation is to use a new algorithm. In theory this should be possible, but in practice it has proved very difficult. For this reason, additional work is recommended to make alternative algorithms available.

The NERD authority loses its key or disappears: in this case nobody can update the existing database 😢. There are few programmatic mitigations. If the database authority places its private keys and suitable amounts of information in escrow, under agreed-upon circumstances (for example, no updates for three days), the escrow agent would release the information to a party competent to generate a database update 🗝️.

5.4.2. Other Risks 💅

Because this specification does not require secure transport, if an attacker prevents updates to an ITR so the ITR keeps using a compromised ETR, the ITR could keep using an old version of the database without realizing a new version has been made available 👀. If you're worried about that kind of attack, a secure channel (such as SSL) to a secure chain back to the database authority should be used. After some operational experience, later versions of this format might include additional semantics to address this attack. SSL would also prevent attempts to spoof false database versions on the server 🔒.

As discussed above, the substantial risk would be a cold-start scenario. If an attacker found a bug in a common OS that let them erase an ITR's database, and was able to spread that bug, the collective ability of ITRs to retrieve new copies of the database could be taxed by collective demand 📉.

The remedy is for devices to share copies of the database with their peers, which makes each potential requester a potential service 🫶.

6. Why not use XML? 🧾

Lots of objects these days are distributed as XML pages or something derived from XML [W3C.REC-xml11-20040204], like SOAP [W3C.REC-soap12-part1-20070427] [W3C.REC-soap12-part2-20070427]. Using well-known standards like these allows for high-level tools and library reuse 🛠️. XML's strength is extensibility, and without a doubt XML would be more extensible than a fixed field database. So why not use these standards here? The biggest concern the author had was compactness of the data stream. As long as this mechanism is used at all in the future, so long as that concern can be addressed, and so long as signatures of the database can be verified, XML probably should be considered 💜.

7. Other Distribution Mechanisms 🌈

We now look at various different mechanisms. Distributing changes across databases is as old as databases itself 🕰️. The author knows of two obvious approaches that have been used well in the past. One is the wide distribution of CVS repositories. However, for reasons mentioned in Section 5.4, CVS is insufficient to the task.

The other tried and true approach is periodic updates in the form of messages. The good old Network News Transfer Protocol (NNTP) [RFC3977] itself provides two separate mechanisms (one push and one pull) for a coherent update process 📬. This was in fact used to update molecular biology databases [gb91] in the early 1990s. Netnews offers a way to determine whether articles with specified Article-Ids have been received. In the case where the mapping file source of authority wishes to transmit updates, it can sign a change file and then post it into the network. Routers merely need to keep a record of the article ids they have received. Netnews systems years ago handled far greater volume of traffic than we envision [Usenet]. Initially this is probably overkill, but it may not be so later in this process. Some consideration should be given to a mechanism known to widely distribute vast amounts of data, as instantaneously as either the sender or the receiver wishes 🚀.

To get an additional level of hierarchy in the distribution network, service providers could retrieve information to their own local servers and configure their routers with the host portion of the above URI 🏠.

Another possibility would be for providers to agree on a small set of anycast addresses for this purpose. There are limitations to anycast, particularly with TCP. In the midst of a routing flap, an anycast address can become all but unusable 😵. Careful study of such a use, as well as appropriate use of HTTP redirects, is expected.

7.1. What about DNS as a mapping retrieval model? 🤔

It has been proposed that a query/response mechanism be used for this information, and specifically that the Domain Name System (DNS) [RFC1034] be used. The previous models do not preclude DNS. DNS has the advantage that the administrative lines are well drawn, and that the ID-to-RLOC mapping is likely to appear very close to those boundaries 📍. DNS also has the added benefit that an entire distribution infrastructure already exists. There are, however, some problems that could impact end hosts when intermediate routers make queries, some of which were first pointed out in [RFC1383]:

• Any query mechanism offers an opportunity for a resource attack if an attacker can force the ITR to query for information. In this case, all that would be necessary is for a "botnet" (a group of computers that have been compromised and used as vehicles to attack others) to ping or otherwise contact some normal service hosts that sit behind the ETR. If the botnet hosts themselves are behind ETRs, the victim's ITR will need to query for each and every one of them, thus becoming part of a classic reflector attack 🤖.
• Packets will be delayed at the very least, and probably dropped in the process of a mapping query. This could happen at the beginning of a communication, but it will be impossible for a router to conclude with certainty that this is the case.
• The DNS has a backoff algorithm that presumes applications are making queries prior to the beginning of a communication. This is appropriate for end hosts, who know exactly when a communication begins. An end user may not enjoy a router waiting seconds for a retry ⏳.
• While the administrative lines may appear to be correct, the location of name servers may not be. If name servers sit within PI address space, thus requiring LISP to reach, a circular dependency is created. This is precisely where many enterprise name servers sit. The LISP experiment should not predicate its success on relocation of such name servers 🙈.

Nevertheless, DNS may be able to play a role in giving the enterprise control over the mapping of its EIDs to RLOCs. Posit a new DNS record EID2RLOC. This record is used by the authority to collect and aggregate mapping information so that it may be distributed through one of the other mechanisms. As an example:

$ORIGIN 0.10.PI-SPACE.
 128   EID2RLOC   mask 23 priority 10 weight 5 172.16.5.60
       EID2RLOC   mask 23 priority 15 weight 5 192.168.1.5

In the above figure, network 10.0.128/23 would be delegated to some end system, say, EXAMPLE.COM. They would manage the above zone information. This would allow a DNS mechanism to work, but it would also allow someone to aggregate the information and distribute a table 🎀✨.

7.2. Use of BGP and LISP+ALT 🦋

Okay so BGP [RFC4271] is already the thing that moves inter-domain routing around the whole Internet 🌐 So why not just use BGP to distribute mapping entries too? Or give it a rendezvous mechanism to set up mapping entries? 🤔 That's literally what LISP Alternative Topology (LISP+ALT) [RFC6836] does! It runs on a completely separate topology from the normal DFZ 💅 It reuses existing code paths and expertise, which is so smart. The alternative topology also gives an extremely accurate control path from ITRs to ETRs. NERD's model, on the other hand, needs an optimistic assumption, plus control-plane logic that cycles through unresponsive ETRs in an EID-Prefix's mapping entry 😬 LISP+ALT's memory-scaling is extremely attractive because strong aggregation is expected, while NERD barely tries to aggregate at all 🌸

A bunch of key deployment issues are still open 🫶 The big one is whether it's acceptable for routers to drop packets now and then while mapping information is being gathered. This should be future research for ALT, because avoiding exactly that situation was a key design goal of NERD ✨

---

7.3. Perhaps use a hybrid model? 🧚

Maybe it would be useful to combine a prepopulated database like NERD with a query mechanism (maybe LISP+ALT, LISP-CONS [LISP-CONS], or DNS) to figure out an EID-to-RLOC mapping 💜 One idea is to only receive a subset of the mappings, like taking only the NERD data for certain regions. That cuts down the need to drop packets for some destinations, assuming your traffic is localized to a particular region 🍓 If you don't have a local entry for a particular EID, you'd then make a query.

One way to use DNS to query live is to periodically walk the "interesting" parts of the network, hunting for relevant records, and cache them to non-volatile storage 🔍 Walking prevents resource attacks, but the walk itself could be seen as an attack if the algorithm isn't selective enough about what counts as interesting 🙈 A similar approach could work for LISP+ALT or LISP-CONS by forcing a data-driven Map Reply for certain sites.

---

8. Deployment Issues 🚧

LISP and NERD are still experiments right now, but it's already obvious that you have to take circular dependencies seriously, both in the protocols being used and in the elements inside them 🔄

8.1. HTTP 🌐

To the extent that HTTP depends on DNS, whether through the authority section of a URI or through the configured base distribution URI, these same concerns apply 😬 On top of that, any HTTP server that itself uses Provider-Independent addresses would be a poor choice for distributing the database, for these exact same reasons.

One issue with HTTP is that a middlebox of some kind, like a cache, might intercept and process requests 👀 Sometimes that's a good thing! If a cache correctly returns a database, some bandwidth gets saved 🎀 But if the cache itself fails to work properly for whatever reason, end-to-end connectivity could get impaired 💀 For example, if the cache depended on the mapping being in place and functional, a cold-start scenario could leave the cache misbehaving, which then gives routers no way to update their databases. Some care must be taken to avoid circumstances like that 🫠

---

9. Open Questions 🤔✨

Do we need to talk about reachability in more detail? This was clearly an issue at the IST-RING (Information Science Technologies - Routing in Next Generation) workshop 🌈 There are two key issues. First, what's the right architectural separation between the data plane and the control plane? Second, is there some specific way that NERD affects the data plane?

Should we specify a (perhaps compressed) tarball that splits the difference on that last question? Each update tarball would contain both a signature for the update and a signature for the entire database, once the update is applied 📦

Should we compress? 🗜️ In some early testing with databases of 1, 5, and 10 million IPv4 EIDs and a random distribution of IPv4 RLOCs, the current format in this document compressed by between 35% and 36%, using the Burrows-Wheeler block sorting text compression algorithm (bzip2). The NERD used random EIDs with prefix lengths varying from 19-29 bits, with the probability weighted toward the smaller masks. That only very roughly reflects reality, though 😅 A better test would start with the existing prefixes found in the DFZ.

---

10. Conclusions 👑

This memo specified a database format, an update format, a URI convention, an update method, and a validation method for EID-to-RLOC mappings 💖 We showed that, beyond the predictions of 10^8 EID-prefix entries, the aggregate database size would likely be at most 17 GB. We considered how many servers it would take to distribute that information, and we showed the limits of a simple content distribution network and other well-known mechanisms 🌸 The effort needed to retrieve a database change works out to between 3 and 30 seconds of processing time per hour at today's gigabit speeds ⚡ So we conclude there's no need for an off-box query mechanism today, and there are distinct disadvantages to having one in the control plane 🙅‍♀️

We also looked at alternatives that allow hybrid models using query mechanisms, in case our operating assumptions turn out to be overly optimistic 🦋 Using NERD today doesn't rule out those models later, and honestly both models can happily coexist 🫶

Since the first draft of this document in 2007, parts of this work have been implemented 🎉 Future work should consider the size of fields like the version field, along with key roll-over and revocation issues. As noted earlier, CMS is now widely deployed 💅 Current work on DNS-based authentication of named entities [RFC6698] may offer a way to test whether a NERD provider is authorized to carry a specific prefix 🔐

We leave to future work how the list of databases gets distributed, how BGP can play a role in distributing knowledge of the databases, and how DNS can play a role in aggregating information into these databases 📚

We also leave to future work whether HTTP is the best protocol for the job, and whether the scheme in this document is the most efficient. You could easily imagine that in high-delay or high-loss environments, a broadcast or multicast method might work better 📡

Speaking of multicast, we also leave to future work how multicast is implemented, if at all, either alongside this model or as an extension of it 🌀

Finally, maybe the most interesting future work would be figuring out if and how NERD could be integrated with the LISP mapping server [RFC6833] 🧠✨

---

11. Acknowledgments 🫶

Dino Farinacci, Patrik Faltstrom, Dave Meyer, Joel Halpern, Jim Schaad, Dave Thaler, Mohamed Boucadair, Robin Whittle, Max Pritikin, Scott Brim, S. Moonesamy, and Stephen Farrel were super helpful with their reviews of this work 💜 Thanks also to the participants of the Routing Research Group and the IST-RING workshop held in Madrid in December of 2007 for their incisive comments 🇪🇸 The astute will notice a lengthy References section 👀 This work stands on the shoulders of many others' efforts 🌟

---

12. References 📚

12.1. Normative References 📖

• [ITU.X509.2000] International Telecommunications Union, "Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks", ITU-T Recommendation X.509, ISO Standard 9594-8, March 2000.
• [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
• [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
• [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
• [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, January 2013.

12.2. Informative References 📚✨

Okay, here are the receipts, bestie 💅 These are the "for more reading" sources. You don't need them to get the main idea, but they're good to know about 🫶

• [CARP07] Carpenter, B., "IETF Plenary Presentation: Routing and Addressing: Where we are today", March 2007.
• [CVS] Grune, R., Baalbergen, E., Waage, M., Berliner, B., and J. Polk, "CVS: Concurrent Versions System", November 1985.
• [LISP-CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A Content distribution Overlay Network Service for LISP", Work in Progress, April 2008.
• [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
• [RFC1383] Huitema, C., "An Experiment in DNS Based IP Routing", RFC 1383, December 1992.
• [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998.
• [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
• [RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", RFC 3977, October 2006.
• [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages", RFC 4108, August 2005.
• [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
• [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
• [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
• [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, August 2012.
• [RFC6833] Farinacci, D. and V. Fuller, "Locator/ID Separation Protocol (LISP) Map-Server Interface", RFC 6833, January 2013.
• [RFC6836] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, January 2013.
• [Usenet] Wikipedia, "Usenet", January 2013, <http://en.wikipedia.org/w/index.php?title=Usenet&oldid=531545312>.
• [W3C.REC-soap12-part1-20070427] Gudgin, M., Lafon, Y., Moreau, J., Hadley, M., Karmarkar, A., Mendelsohn, N., and H. Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)", World Wide Web Consortium Recommendation REC-soap12-part1-20070427, April 2007, <http://www.w3.org/TR/2007/REC-soap12-part1-20070427>.
• [W3C.REC-soap12-part2-20070427] Karmarkar, A., Hadley, M., Mendelsohn, N., Nielsen, H., Lafon, Y., Gudgin, M., and J. Moreau, "SOAP Version 1.2 Part 2: Adjuncts (Second Edition)", World Wide Web Consortium Recommendation REC-soap12-part2-20070427, April 2007, <http://www.w3.org/TR/2007/REC-soap12-part2-20070427>.
• [W3C.REC-xml11-20040204] Cowan, J., Maler, E., Sperberg-McQueen, C., Paoli, J., Bray, T., and F. Yergeau, "Extensible Markup Language (XML) 1.1", World Wide Web Consortium First Edition REC-xml11-20040204, February 2004, <http://www.w3.org/TR/2004/REC-xml11-20040204>.
• [gb91] Smith, R., Gottesman, Y., Hobbs, B., Lear, E., Kristofferson, D., Benton, D., and P. Smith, "A mechanism for maintaining an up-to-date GenBank database via Usenet", Computer Applications in the Biosciences (CABIOS), April 1991.

---

Appendix A. Generating and Verifying the Database Signature with OpenSSL 🔐

Okay, PKI can feel like pure magic 🪄 so this appendix is here to demystify the signing and verifying part, with real command-line examples 💻 One goal of NERD was to use off-the-shelf tools to both generate and retrieve the database, so we're leaning on those. Fair warning: how you get the entries themselves isn't covered here. We're assuming they already exist and you just want to sign the database 🫶

To sign the database, start with a database file that has a database header described in Section 3. The block size should be zero, and there should be no PKCS#7 block at this point. You'll also need a certificate and its private key to sign with 🔑

The OpenSSL "smime" command has everything we need from here on out. To sign the database, run this:

      openssl smime -binary -sign -outform DER -signer yourcert.crt \
              -inkey yourcert.key -in database-file -out signature

Here's what each flag does:

• -binary says that no MIME canonicalization should be performed.
• -sign says that you're signing the file given as the argument to -in.
• -outform sets the output format to binary DER.
• -signer takes your public certificate, and -inkey takes your key.
• -out is where the signature itself gets written.

Then the resulting file signature gets copied into the PKCS#7 block in the database header, its size in bytes gets recorded in the PKCS#7 block size field, and boom, the file is ready to be distributed to ITRs ✨

To verify a database file, first pull the PKCS#7 block out of the file by copying the right number of bytes into another file, say, signature. Next, zero this field and set the block size field to 0. Then use the "smime" command to verify the signature like so:

    openssl smime -binary -verify -inform DER -content database-file
            -out /dev/null -in signature

If the signature is correct, OpenSSL will print Verification OK 🎉 And honestly? OpenSSL provides rich enough libraries to do all of the above inside a C program in a single pass 👑

Author's Address 📮

Eliot Lear
Cisco Systems GmbH
Richtistrasse 7
Wallisellen  CH-8304
Switzerland

Phone: +41 44 878 9200
EMail: lear@cisco.com