RFC 2725

Routing Policy System Security

📅 published December 1999, from ietf

Routing Policy System Security 🎀

okay bestie, this is RFC 2725 and it is SO good 💖 here's the title block tea:

Working group: Network Working Group 🫶
Request for Comments: 2725
Category: Standards Track ✨
Date: December 1999 📅
Authors: C. Villamizar (Avici), C. Alaettinoglu (ISI), D. Meyer (Cisco), S. Murphy (TIS) 👯
Obsoletes / Updates: the title block doesn't list any RFCs this one obsoletes or updates 🙈

Status of this Memo 📜

This doc specifies an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 💬. For the standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈.

Copyright Notice ©️

Abstract 🦋

So the RIPE database specs and the RPSL language are the ones that define the languages used to represent info in a routing policy system 🗂️. A repository for that info is called a routing registry, and a routing registry gives people a way to swap the info they need for lots of important Internet operations stuff 🔁. If a routing policy system is going to be of any real operational use, it has to keep some degree of integrity while it's being implemented and deployed 🔐. This doc is all about keeping that data trustworthy by bringing in an authentication and authorization model. Main character energy 👑.

Table of Contents 📚

1  Overview  . . . . . . . . . . . . . . . . . . . . . . . . .  3
2  Background  . . . . . . . . . . . . . . . . . . . . . . . .  3
3  Implicit Policy Assumptions . . . . . . . . . . . . . . . .  5
4  Scope of Security Coverage  . . . . . . . . . . . . . . . .  5
5  Organization of this Document   . . . . . . . . . . . . . .  6
6  Goals and Requirements  . . . . . . . . . . . . . . . . . .  6
7  Data Representation . . . . . . . . . . . . . . . . . . . . 10
8  Authentication Model  . . . . . . . . . . . . . . . . . . . 10
9  Authorization Model . . . . . . . . . . . . . . . . . . . . 12
  9.1   Maintainer Objects . . . . . . . . . . . . . . . . . . 12
  9.2   as-block and aut-num objects . . . . . . . . . . . . . 13
  9.3   inetnum objects  . . . . . . . . . . . . . . . . . . . 13
  9.4   route objects  . . . . . . . . . . . . . . . . . . . . 14
  9.5   reclaim and no-reclaim attributes  . . . . . . . . . . 14
  9.6   Other Objects  . . . . . . . . . . . . . . . . . . . . 15
  9.7   Objects with AS Hierarchical Names . . . . . . . . . . 16
  9.8   Query Processing . . . . . . . . . . . . . . . . . . . 16
  9.9   Adding to the Database . . . . . . . . . . . . . . . . 17
  9.10  Modifying or Deleting Database Objects . . . . . . . . 19
10  Data Format Summaries  . . . . . . . . . . . . . . . . . . 20
  10.1  Changes to the RIPE/RPSL Schema  . . . . . . . . . . . 20
Appendicies
A  Core and Non-Core Functionality . . . . . . . . . . . . . . 23
B  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . 23
C  Technical Discussion  . . . . . . . . . . . . . . . . . . . 26
  C.1   Relaxing requirements for ease of registry   . . . . . 27
  C.2   The address lending issue  . . . . . . . . . . . . . . 28
  C.3   Dealing with non-conformant or questionable older
        data . . . . . . . . . . . . . . . . . . . . . . . . . 29
D  Common Operational Cases  . . . . . . . . . . . . . . . . . 30
  D.1   simple hierarchical address allocation and route
        allocation . . . . . . . . . . . . . . . . . . . . . . 31
  D.2   aggregation and multihomed more specific routes  . . . 32
  D.3   provider independent addresses and multiple origin
        AS . . . . . . . . . . . . . . . . . . . . . . . . . . 32
  D.4   change in Internet service provider  . . . . . . . . . 32
  D.5   renumbering grace periods  . . . . . . . . . . . . . . 32
E  Deployment Considerations . . . . . . . . . . . . . . . . . 33
F  Route Object Authorization Pseudocode . . . . . . . . . . . 35
Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 37
Intellectual Property Notice . . . . . . . . . . . . . . . . . 38
References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Security Considerations  . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 40
Full Copyright Statement   . . . . . . . . . . . . . . . . . . 41

1. Overview ✨

The Internet Routing Registry (IRR) grew up to meet a need for Internet-wide coordination 🌍. That need was described in RFC-1787, an informational RFC written on behalf of the IAB [14]. Here's the vibe from Section 7 of RFC-1787 🫶:

Basically, as the Internet keeps growing, Internet-wide coordination gets harder, BUT routing would be way more stable and consistent if orgs could share info about their routing requirements across organizational lines 🤝. That info is useful for everything from troubleshooting to spotting and fixing conflicting routing requirements 🔍. Because the Internet is so huge, the info should be spread out, so people are setting up depositories (Routing Registries) and building tools to analyze and use that info 🛠️.

A routing registry has to keep some degree of integrity or it's not useful at all 🥲. How much integrity it needs depends on how the routing policy system is being used 📊.

At first, routing policy systems like the RIPE database were mostly used in an advisory role, writing down the intended routing policies so people could debug things 🐛. For that job, a super weak form of authentication was considered good enough 🙃.

The IRR is now being used for stuff that needs much stronger data integrity and security 💪. This doc covers integrity and security issues that fit how the IRR is actually used, and that avoid hurting data integrity and security even when the IRR is spread across less trusted repositories 🔐.

2. Background 🕰️

An early routing policy system on the NSFNET was the policy routing database (PRDB) 🧠. It let people figure out who was allowed to announce specific prefixes to the NSFNET backbone. People realized they needed a policy database as far back as 1989 [6, 4], and by 1991 it was up and running [5]. Authentication happened by requiring confirmation, which was a super manual process 😩. That solved the problem for the NSFNET, but it was built to hold the routing policy of one single organization.

The problem has gotten way harder since then 📈. New requirements have shown up, like:

There is a need to represent the routing policies of many organizations.
CIDR and overlapping prefixes, the growing complexity of routing policies, and the needs of aggregation have introduced new requirements.
There is a need to assure integrity of the data and delegate authority for the data representing specifically allocated resources to multiple persons or organizations.
There is a need to assure integrity of the data and distribute the storage of data subsets to multiple repositories.

The RIPE effort focused specifically on the first issue and the needs of the European community 🇪🇺. Its predecessor, the PRDB, served the needs of a single organization, the NSF. The RIPE database formats described in [2] were the basis of the original IRR 🧱.

Routing protocols on their own give no assurance that a route's origination is legitimate or that the route can actually reach the stated destination 😬. CIDR lets more specific prefixes override less specific prefixes [9, 15, 8]. Even with signed route origination, you can't tell whether a more specific prefix is legit and should override a less specific route announcement unless you have a way to determine who is authorized to announce specific prefixes 🕵️. Skip that, and there's zero assurance of global routing integrity, and it opens the door to a very effective form of denial of service attack 🚨.

The Routing Policy System Language (RPSL) [1, 13] was a pretty big evolutionary step in data representation, mostly aimed at the second group of needs 🦋. The PRDB handled CIDR in 1993 [12], and the RIPE database took CIDR prefixes from day one. RPSL brings a bunch of needed improvements though, including explicit support for aggregation 💜.

This document tackles the third group of needs listed above 🎯.

The current implementation that supports weak authentication doesn't guarantee data integrity, but it does have solid mechanisms to make sure all the involved parties get notified when a change hits the database, whether it was malicious or intended 📣. That's inadequate protection against additions 😤. Since this software now configures big chunks of the Internet's infrastructure, knowing about unintended changes and being able to roll them back isn't enough anymore 🔙. So we need more active security mechanisms that stop these problems before they happen 🛡️.

A separate document will be needed to address the fourth group of needs 📄.

3. Implicit Policy Assumptions 🧚

The authorization model bakes in certain policies for allocating address numbers and AS numbers, and for announcing routes 🗺️. There's a very small number of policy assumptions baked into the authorization model, and they are:

Address numbers are allocated hierarchically. The IANA delegates portions of the address space to the regional registries (currently ARIN, APNIC and RIPE), which in turn delegate address space to their members, who can assign addresses to their customers 🌳.
AS numbers are allocated either singly or in small blocks by registries. Registries are allocated blocks of AS numbers, which makes the allocation hierarchical 🪜.
Routes should only be announced with the consent of the holder of the origin AS number of the announcement and with the consent of the holder of the address space 🤝.
AS numbers and IP address registries may be different entities from routing registries 🏢.

For subsets of any of these three allocation spaces (network addresses, AS numbers, and routes), these restrictions may be loosened or disabled by specifying a very weak authorization method or an authentication method of none 🔓. Even when no authentication mechanism is used, though, all involved parties can still be notified about the changes that happened through the existing notify attribute 📬.

part 1 of 10 done, bestie 💜 next up is Section 4, Scope of Security Coverage 🦋

4. Scope of Security Coverage 🔐

okay so this doc has ONE job 💅 it's only here to make sure the policy data in a registry stays legit and nobody messes with it. authentication and authorization cover additions, deletions, and changes to the database, and that's it ✨ checking authentication and authorization of database queries is explicitly out of scope 🙅‍♀️ mutual authentication of queries is out too. that's checking BOTH who's asking AND which repository the results came from, so it's not this doc's problem bestie 🫶

5. Organization of this Document 🗂️

familiarity with RIPE-181 [2] and RPSL [1] is assumed the whole way through, so have those open 📖 goals are in Section 6. Section 7 through Section 9 cover the changes and the discussion 💜 Section 10 is the concise summary of data formats and semantics 🍓 and Appendix C through Appendix E have the extra technical discussion, examples, and deployment considerations 🧚

here's the tour:

Goals and Requirements: Section 6 digs into the issues and names the specific problems that need solving. some of them need a bit of teamwork from the Internet community 🤝
Data Representation: Section 7 covers some characteristics of RPSL and the formats for external representations of information 🎀
Authentication Model: Section 8 describes current practice, proposes extra authentication methods, and explains the extension mechanism in case more methods are needed later 🔑
Authorization Model: Section 9 explains how to figure out whether a transaction has the authorization needed to add, modify, or delete specific data objects, based on the authentication requirements stated in related data objects ✅
Data Format Summaries: Section 10 is your quick reference for the data formats and the steps in transaction processing ⭐
Technical Discussion: Section C talks through some technical tradeoffs 🦋
Common Operational Cases: Section D has examples from past operational experience with the IRR 🌈
Deployment Considerations: Section E covers some deployment issues and possible ways to fix them 🛠️

6. Goals and Requirements 🎯

okay the Internet is an OPEN network, and that openness plus the sheer scale of it can cause real operational problems 😭 technical weaknesses that let a misconfiguration or errant operation in one part of the network spread globally, or that open the door to simple denial of service attacks, should be eliminated as far as is practical 🔥 the integrity of routing information is critical for making sure traffic actually goes where it's supposed to go 💖

an accidental misconfiguration can send traffic toward routers that can't reach a destination they're advertising reachability for 💀 this is commonly caused by misconfigured static routes, though there are plenty of other possible causes. static routes are often used to give constant apparent reachability to single homed destinations, and some of the biggest ISPs literally have thousands of them in their networks 😳 operators usually enter these by hand, and mistyping can divert traffic from a totally unrelated destination to a router with no actual reachability to the advertised destination 🙈 this can happen, and it does happen somewhat regularly. implementation bugs or severe misconfigurations that cause loss of BGP AS path information or changes to prefix length can lead to advertising big sets of routes at once. it's considerably more rare, but on a few occasions when this happened the results were catastrophic 😱

where there's potential for an accidental misconfiguration in a remote part of the Internet to affect the global Internet, there's also potential for malice 👀 for example, it's been shown by accident that multiple hour outages at a major institution can be caused by a laptop and a dial account if proper precautions aren't taken 💻 the dial account doesn't need to be with the same provider the major institution uses. no cap, scary stuff ✨

the potential for error goes up because of the CIDR preference for more specific routes [8] 📈 if an institution advertises a single route of a given length, and a distant router advertises a more specific route covering critical hosts, then the more specific route (if it's accepted at all) gets preferred no matter the administrative weighting or any routing protocol attributes 🙃

there's a need for some form of checks on whether a route advertisement is valid ✅ today those checks are typically made against the border AS advertising the route. this stops routes from being accepted from border ASes that couldn't legitimately advertise them 🛡️ these checks rely on information registered in the IRR to generate lists of prefixes a specific border AS could advertise. checks can also be made against the origin AS. if policy information were sufficiently populated, checks could be made against the entire AS path, but that isn't feasible yet 😔

using a routing registry can also make it harder for prefixes to be used without authorization, like unallocated prefixes or prefixes allocated to another party 🙅‍♀️

in summary, some of the problems being addressed are:

Localizing the impact of accidental misconfiguration made by Internet Providers to that provider's networks only.
Eliminating the potential for an Internet provider's customer to use malicious misconfiguration of routing as a denial of service attack if the provider route filters their customers. Localizing the denial of service to that Internet provider only if the immediate Internet service provider does not route filter their customers but other providers route filter the route exchange at the interprovider peering.
Eliminating the unauthorized use of address space.

if the data inside a routing registry is critical, then the ability to change that data must be controlled 🔒 centralized authorities can provide that control, but centralization can cause scaling problems (and it's politically distasteful too, ngl) 🙄

address allocation and name allocation are already delegated. since delegation can go to outside registries, it's at least somewhat distributed [11] 🌍 autonomous System (AS) numbers are allocated by the same authorities. it makes sense to delegate the routing number space in a way similar to address allocation and AS number allocation 🧩 that delegation to lots of registries makes it harder to keep the whole body of information intact 😤

as a first step, the database can be somewhat centrally administered, with authority given to many parties to change the information 💜 that's the current IRR setup: there are a very small number of well trusted repositories and a very large number of parties allowed to make changes. control has to be exercised over who can make changes AND what changes they can make 👑 the distinction between who and what is what separates authentication from authorization:

Authentication is the means to determine who is attempting to make a change.
Authorization is the determination of whether a transaction passing a specific authentication check is allowed to perform a given operation.

different parts of the database need different methods of authentication 🎀 some applications will need authentication based on strong encryption. in other cases, software supporting strong encryption may not be necessary or may not be legally available 🌸 for this reason, multiple authentication methods must be supported, selected on a per object basis through the authentication methods in the maintainer object "auth" attribute 🫶 the methods can range from very weak data integrity checks all the way up to cryptographically strong signatures. the authorization model must ensure that using weak integrity checks in parts of the database doesn't compromise the overall integrity of the database 🛡️

there are extra requirements on the authorization model if the database is widely distributed with delegations made to parties who may not be trustworthy or whose security practices may be lacking 😬 this problem must be addressed in the authorization model so the registry can later evolve into a more distributed routing registry 🦋

autonomous system numbers can be delegated in blocks, subdelegated as needed, and then individual AS numbers assigned 🧚 address allocation is a simple numeric hierarchy. route allocation is somewhat more complicated 🤓 the key attributes in a route object (the ones that make it unique) contain both an address prefix and an AS number, known as the origin AS. the addition of a route object must be validated against the authorization criteria for both the AS and the address prefix ✅ route objects may exist for the same prefix with multiple origin AS values, because of a common multihoming practice that doesn't require a unique origin AS 🍓 there's often no correlation between the origin AS of a prefix and the origin AS of overlapping more specific prefixes. it's giving chaotic but it's real 💀

there are lots of operational cases that have to be accommodated. the more common ones are listed below 📋 they're explored in more detail in Appendix D, with the technical tradeoffs in Appendix C:

simple hierarchical address allocation and route allocation
aggregation and multihomed more specific routes
provider independent addresses and multiple origin AS
changing Internet service providers
renumbering grace periods

the authorization model must accommodate a variety of policies about allocating address space, and it cannot mandate any one model 🌈 there's no standardization of address allocation policies, though guidelines do exist [11, 16] 📚 whether authorization allows recovery of address space must be selectable on a per object basis, and it may differ in parts of the database. this is discussed further in Appendix C ✨

7. Data Representation ✨

okay so RPSL gives you a complete description of what's inside a routing repository [1] 💖 A bunch of RPSL data objects are unchanged from the RIPE specs, and RPSL points back to the RIPE-181 spec as recorded in RFC-1786 [2] 🦋 RPSL handles external data representation, so the outside view is the spec, and a registry can store things differently on the inside 🧚

Some database object types or database attributes MUST be added to RPSL to record the delegation of authority and to improve the authentication and authorization mechanisms. Don't panic, these additions are super few and they're described in Section 8 and Section 9 🫶

Some form of encapsulation MUST be used to exchange data. The defacto encapsulation is the one the RIPE tools accept: a plain text file, or plain text in the body of an RFC-822 formatted mail message, with the info needed for authentication pulled from the mail headers or the body of the message. Merit tweaked it a little by using the PGP signed portion of a plain text file, or the PGP signed portion of the body of a mail message 🔐 These very simple forms of encapsulation are fine for the initial submission of a database transaction ✨

The encapsulation of registry transaction submissions, registry queries and registry responses and exchanges between registries is outside the scope of this document. The encapsulation of registry transaction submissions and exchanges between registries is outside the scope of this document. (yes, it says that twice, the RFC really wanted to be sure 💀)

8. Authentication Model

The maintainer objects are containers that hold authentication filters 🗂️ A reference to a maintainer inside another object defines authorization to perform operations on that object or on a set of related objects. The maintainer is typically referenced by name in mnt-by attributes of objects. More on maintainers in Section 9.1 💅

The maintainer contains one or more auth attributes. Each auth attribute starts with a keyword naming the authentication method, followed by the authentication information needed to enforce that method. The PGPKEY method is a little syntactically different, in that the method PGPKEY is a substring.

Authentication methods currently supported include the following. Note that pgp-from is being replaced by the pgpkey (see Section 10 and [18]).

mail-from: This is a very weak authentication check and is discouraged. The authentication information is a regular expression over ASCII characters. The maintainer is authenticated if the from or reply-to fields in RFC-822 mail headers are matched by this regular expression. Since mail forgery is quite easy, this is a very weak form of authentication. 📭
crypt-pw: This is another weak form of authentication. The authentication information is a fixed encrypted password in UNIX crypt format. The maintainer is authenticated if the transaction contains the clear text password of the maintainer. Since the password is in clear text in transactions, it can be captured by snooping. Since the encrypted form of the password is exposed, it is subject to password guessing attacks. 😬
pgp-from: This format is being replaced by the "pgpkey" so that the public key certificate will be available to remote repositories. This is Merit's PGP extension. The authentication information is a signature identity pointing to an external public key ring. The maintainer is authenticated if the transaction (currently PGP signed portion of a mail message) is signed by the corresponding private key. 🗝️
pgpkey: This keyword takes the form PGPKEY-hhhhhhhh, where hhhhhhhh is the hex representation of the four byte id of the PGP public key used for authentication. The public key certificate is stored in a separate object as described in [18]. 🌟

Repositories may elect to disallow the addition of auth attributes specifying weaker forms of authentication and/or disallow their use in local transaction submissions. Repositories are encouraged to disallow the addition of auth attributes with the deprecated pgp-from method. bye bye, old-school stuff 👋

Any digital signature technique can in principle be used for authentication. Transactions SHOULD be signed using multiple digital signature techniques, so that repositories or mirrors that only use a subset of the techniques can verify at least one of the signatures. The selection of digital signature techniques is not within the scope of this document. 🔏

9. Authorization Model

The authorization model MUST accommodate the requirements outlined in Section 6. A key feature is the recognition that authorization for the addition of certain types of data objects MUST be derived from related data objects. this is the heart of the whole model 💜

With multiple repositories, objects not found in RPSL are needed to control AS delegations, and new attributes are needed in existing objects to control subdelegation. The definition of RPSL objects used to implement a distributed routing registry system is not within the scope of this document. 🧩

9.1. Maintainer Objects

The maintainer objects serve as a container to hold authentication filters. The authentication methods are described in Section 8. The maintainer can be referenced by name in other objects, most notably in the mnt-by attributes of those objects. 🎀

Maintainers themselves contain mnt-by attributes. In some cases the mnt-by in a maintainer will reference the maintainer itself. In this case, authorization to modify the maintainer is provided to a (usually very limited) set of identities. A good practice is to create a maintainer containing a long list of identities authorized to make specific types of changes, but have the maintainer's mnt-by attribute reference a far more restrictive maintainer that tightly controls changes to the maintainer object itself. 🔒✨

The mnt-by attribute is mandatory in all objects. Some data already exists without mnt-by attributes. A missing mnt-by attribute is interpreted as the absence of any control over changes. This is highly inadvisable, and most repositories will no longer allow this. 🙈

An additional maintainer reference can occur through a new attribute, mnt-routes, which is used in aut-num, inetnum and route objects. The mnt-routes attribute is an extension to RPSL and is described in detail in Section 10. 🦋

A mnt-routes attribute in an aut-num object allows addition of route objects with that AS number as the origin to the maintainers listed. A mnt-routes attribute in an inetnum object allows addition of route objects with exact matching or more specific prefixes. A mnt-routes attribute in a route object allows addition of route objects with exact matching or more specific prefixes. A mnt-routes attribute does not allow changes to the aut-num, inetnum, or route object where it appears. A mnt-routes MAY optionally be constrained to only apply to a subset of more specific routes. 🌈

Where mnt-routes or mnt-lower are applicable, any maintainer referenced in the mnt-by still applies. The set of applicable maintainers for whatever check is being made is the union of the mnt-routes or mnt-lower and the mnt-by. For example, when authorizing a route object, software would look at mnt-routes. If it does not exist, it looks at mnt-lower, and if that does not exist, it looks at mnt-by. 🧠💖

9.2. as-block and aut-num objects

An as-block object is needed to delegate a range of AS numbers to a given repository. This is needed for authorization, and it is needed to avoid having to make an exhaustive search of all repositories to find a specific AS. This search would not be an issue now, but would be if a more distributed routing repository is used. Distributed registry issues are not within the scope of this document. 🌍

The as-block object also makes it possible to separate AS number allocation from registration of AS routing policy.

      as-block:        AS1321 - AS1335

The aut-num describes the routing policy for an AS, and it is critical for router configuration of that AS and for analysis performed by another AS. For the purpose of this document, it is sufficient to consider the aut-num solely as a place holder identifying the existence of an AS, and providing a means to associate authorization with that AS when adding route objects. 📌

The as-block object is proposed here solely as a means of recording the delegation of blocks of AS numbers to alternate registries. In doing so, it provides a means to direct queries and a means to support hierarchical authorization across multiple repositories. 🧚‍♀️

9.3. inetnum objects

The inetnum exists to support address allocation. For external number registries, such as those using [r]whoisd[++], the inet-num can serve as a secondary record that is added when an address allocation is made in the authoritative database. Such records could be added by an address registry such as ARIN as a courtesy to the corresponding routing registry. 🏠

      inetnum:        193.0.0.0 - 193.0.0.255
      source:         IANA

9.4. route objects

Right now there are quite a few route objects in more than one registry. Quite a few are registered with an origin AS for which they have never been announced. There is a legitimate reason to be in more than one origin AS. 👀

The route object is used to record routes which may appear in the global routing table. Explicit support for aggregation is provided. Route objects exist both for the configuration of routing information filters used to isolate incidents of erroneous route announcements (Section 6), and to support network problem diagnosis. 🔥

9.5. reclaim and no-reclaim attributes ✨

okay so the reclaim attribute is needed in as-block, inetnum and route objects 💅 it lets you keep control over more specific AS, IP address or route space by getting modify and delete privileges no matter what the mnt-by says in the object itself 🔑

bestie this is literally how address lending gets enforced 🫶 it's how cleanup happens when entities just stop existing 💀 and it's also a last presort means to fix mistakes, like when parties accidentally lock themselves out of their own objects 😭 to cover all more specific objects, the reclaim attribute value should be "ALL". if you want finer control, you can specify a set of prefixes instead 🎀

the no-reclaim attribute is for explicit exceptions 🙈 a reclaim attribute can only be added to an existing object if adding it doesn't take away the autonomy of existing more specific objects covered by the new reclaim attribute. so you can add one when:

there are no existing exact matches or more specific objects overlapped by the new reclaim attribute, or
the submitter is listed in the maintainer pointed to by the mnt-by of the objects which are overlapped, or
any overlapped object is listed in a no-reclaim attribute in the object where the reclaim is being added.

deleting a no-reclaim attribute is similar but stricter 🥹 a submitter may delete a no-reclaim attribute from an object only when that submitter is the only maintainer listed in the mnt-by attributes of any overlapped objects. if the submitter isn't listed in any of the maintainers pointed to by the mnt-by attributes for one or more overlapped objects, then they are not permitted to delete the no-reclaim attribute 🚫

and if neither a reclaim nor a no-reclaim attribute is present, then more specific objects of a given object cannot be modified by the maintainer of the less specified object, unless that maintainer is also listed as a maintainer in the more specific object. ngl the one twist is that adding a new route or inetnum object must pass authentication of the largest less specific prefix as part of the authentication check described in Section 9.9 🔐

see Section 10 for a full description of the reclaim and no-reclaim attributes 📖

9.6. Other Objects 🧚

many RPSL ancillary objects have no natural hierarchy, unlike AS numbers, Internet addresses and routes, which do have a numeric hierarchy 🌸 some examples are "maintainers", "people" and "role" objects. for these, the lack of any hierarchy causes two problems:

there's no hierarchy you can exploit to direct queries to alternate registries. at some point, the query strategy of searching all known registries becomes impractical 😩
there's no hierarchy to base authorizations of additions on.

the first problem can be addressed by treating the name space for each ancillary object as unique only within the local database, and using explicit references to an external repository where needed. to specify an external repository reference, the object key is preceded by the name of the repository and the delimiter ::. for example, a NIC handle may take the form RIPE::CO19 ✨ right now there's a desire to keep NIC handles unique, so the naming convention of appending a dash and the repository name is used. prepending the repository name gives you the unique name space, since an object in the RIPE database referencing CO19 would be interpreted as RIPE::CO19 by default, but it's still possible to query or reference IANA::CO19. there's no chance of accidentally forgetting to follow the conventions when making an addition, and existing objects are accommodated, including cases where name conflicts have already happened 🙌

the second problem can be partially addressed by using a referral system for adding maintainers, and by requiring that any other object be submitted by a registered maintainer or by IANA 🫶 the referral system would let any existing maintainer add another maintainer. this can be used in parallel with the addition of other object types to support maintaining those objects. for example, when adding a subdomain to the "domain" hierarchy (in the RIPE repository, where domains are also handled), even when adding a new domain to a relatively flat domain such as com, there's already a maintainer for the existing domain 👑 that existing maintainer can add the maintainer that will be needed for the new domain, in addition to adding the new domain and giving the new maintainer the right to modify it.

an organization getting a presence on the Internet for the first time would be given a maintainer 🎀 this maintainer may list a small number of very trusted employees who are authorized to modify the maintainer itself. the organization can then add another maintainer that lists a larger set of employees, but lists the more restrictive maintainer in the mnt-by attributes of the maintainers themselves. after that, the organization can add person and role objects as needed, and any other objects as needed and as authorization permits 💖

9.7. Objects with AS Hierarchical Names 🌈

lots of RPSL objects don't have a natural hierarchy of their own, but they do allow hierarchical names 🍓 some examples are the object types "as-set" and "route-set". an as-set may have a name that corresponds to no naming hierarchy, like AS-Foo, or it may have a hierarchical name of the form AS1:AS-Bar.

when a hierarchical name isn't used, authorization for objects such as "as-set" and "route-set" corresponds to the rules for objects with no hierarchy described in Section 9.6 🫧

if hierarchical names are used, then the addition of an object must be authorized by the aut-num whose key is named by everything to the left of the rightmost colon in the name of the object being added. authorization is determined by first using the mnt-lower maintainer reference, or, if that's absent, using the mnt-by reference 🔑

9.8. Query Processing 🔍

a query may have to span multiple repositories 🧚 all queries should be directed toward a local repository, which may mirror the root repository and others. currently, each IRR repository mirrors all other repositories. that way, the query may be answered by the local repository but still draw data from others 💜

the mechanism below, when applied to multiple repositories, assumes the existence of an attribute for traversing the repositories. the definition of this attribute is considered a distributed registry issue and is out of scope for this document 🙈

for object types that have a natural hierarchy, such as aut-num, inet-num and route, the search begins at the root database and follows the hierarchy 🌳 for object types that have no natural hierarchy, such as maintainer, person and role objects, the search is confined to a default database, unless a database is specified. the default database is the same database as the object a reference was made from, if the query is launched through the need to follow a reference. otherwise the default is generally the local database, or a default set by the repository. the default can be specified in the query itself, as described in Section 9.7 ✨

in the absence of attributes to traverse multiple registries, a search of all repositories is needed 😩 with such attributes, the search goes like this. when searching for an AS, the delegation attribute in AS blocks can be consulted, moving the search to data from other repositories. eventually the AS is either found or the search fails. the search for an inetnum is similar: less specific inetnums may refer the search to other databases, and eventually the most specific inetnum is found and its status (assigned or not assigned) can be determined. the definition of attributes for traversing repositories is considered a distributed registry issue and is not within the scope of this document 🫶

the search for a route, in the presence of attributes for traversing multiple registries, is similar, except the search may branch to more than one repository 🦋 the most specific route in one repository may be more specific than the most specific in another. when looking for a route object, it makes sense to return the most specific route that is not more specific than the query requests, regardless of which repository that route is in, rather than returning one route from each repository that contains a less specific overlap 👑

9.9. Adding to the Database 🌸

Okay so the mechanism below, when you apply it across multiple repositories, quietly assumes there's an attribute for traversing the repositories 🧚. Defining that attribute is a distributed registry issue, so it's totally out of scope for this doc 💅.

The root repository must be initially populated at some epoch with a few entries 🌱. An initial maintainer is needed to add more maintainers 🔑. In this special case, the referral-by attribute can be set to refer to itself (Section 10 describes the referral-by) 🪞. When adding an inetnum or a route object, an existing exact match or a less specific overlap must exist 🧐. A route object may be added based on an exact match or a less specific inetnum ✨. The root repository must be initially populated with the allocation of an inetnum covering 0/0, which basically says some address allocation authority exists 👑. Similarly, an initial as-block is needed covering the full AS number range 🌈.

When adding an object with no natural hierarchy, the search for an existing object follows the procedure outlined in Section 9.8 🔍.

When adding an aut-num (an AS), the same procedure used in a query is used to figure out the right repository for the addition and which maintainer applies 🎯. The sequence of AS-block objects and repository delegations is followed. If the aut-num doesn't exist, then the submission must match the authentication specified in the maintainer for the most specific AS-block in order to be added 🫶.

Adding an inetnum is similar 💖. The sequence of inet-num blocks is followed until the most specific one is found. The submission must match the authentication specified in the maintainer for the most specific inetnum overlapping the addition 🦋.

Adding a route object is somewhat more complicated, ngl 😭. The route object submission must satisfy two authentication criteria. It must match the authentication specified in the aut-num, and it must match the authentication specified in either a route object or, if no applicable route object is found, then an inetnum 🔐.

An addition is submitted with an AS number and prefix as its key. If the object already exists, then the submission is treated as a modify (see Section 9.10) ✏️. If the aut-num doesn't exist on a route add, then the addition is rejected (see Section C for further discussion of tradeoffs) 🙅‍♀️. If the aut-num exists, then the submission is checked against the applicable maintainer 💅. A search is then done for the prefix, first looking for an exact match. If the search for an exact match fails, a search is made for the longest prefix match that is less specific than the prefix specified. If this search succeeds, it will return one or more route objects. The submission must match an applicable maintainer in at least one of these route objects for the addition to succeed 🎀. If the search for a route object fails, then a search is performed for an inetnum that exactly matches the prefix, or for the most specific inetnum that is less specific than the route object submission. The search for an inetnum should never fail, but it may return an unallocated or reserved range 🤷‍♀️. The inetnum status must be "allocated", and the submission must match the maintainer ✅.

Having found the AS and either a route object or inetnum, the authorization is taken from these two objects 🧩. The applicable maintainer object is any referenced by the mnt-routes attributes. If one or more mnt-routes attributes are present in an object, the mnt-by attributes are not considered. In the absence of a mnt-routes attribute in a given object, the mnt-by attributes are used for that object 🗝️. The authentication must match one of the authorizations in each of the two objects 💜.

If the addition of a route object or inetnum contains a reclaim attribute, then any more specific objects of the same type must be examined 🕵️‍♀️. The reclaim attribute can only be added if there are no more specific overlaps, or if the authentication on the addition is present in the authorization of a less specific object that already has a reclaim attribute covering the prefix range, or if the authentication on the addition is authorized for the modification of all existing more specific prefixes covered by the addition 👑✨.

9.10. Modifying or Deleting Database Objects 🦋

When modifying or deleting any existing object, a search for the object is performed as described in Section 9.8 🔎. If the submission matches an applicable maintainer for the object, then the operation can proceed 🥰. An applicable maintainer for a modification is any maintainer referenced by the mnt-by attribute in the object. For route and inet-num objects, an applicable maintainer may be listed in a less specific object with a reclaim attribute 🌸.

If the submission is for a route object, a search is done for all less specific route objects and inetnums. If the submission is for an inetnum, a search is done for all less specific inetnums 🧐. If the submission fails the authorization in the object itself but matches the reclaim attribute in any of the less specific objects, then the operation can proceed. Section C contains discussion of the rationale behind the use of the reclaim attribute 📖.

A modification to an inetnum object that adds a reclaim attribute or removes a no-reclaim attribute must be checked against all existing inetnums that are more specific. The same check of the reclaim attribute that is made during addition must be made when a reclaim attribute is added by a modification (see Section 9.9) 🔁.

A deletion is considered a special case of the modify operation 🗑️. The deleted object may remain in the database with a "deleted" attribute, in which case the mnt-by can still be consulted to remove the "deleted" attribute 💀.

10. Data Format Summaries 📚

RIPE-181 [2] and RPSL [1] data is represented externally as ASCII text 🔤. Objects consist of a set of attributes, and attributes are name value pairs 💖. A single attribute is represented as a single line, with the name followed by a colon, followed by whitespace characters (space, tab, or line continuation), and then the value 🎀. Within a value, all whitespace is equivalent to a single space ✨. Line continuation is supported by a backslash at the end of a line, or by the following line beginning with whitespace 🌈. When transferred, attributes are generally broken into shorter lines using line continuation, though this is not a requirement 🧵. An object is externally represented as a series of attributes, and objects are separated by blank lines 🫧.

There are about 80 attribute types in the current RIPE schema and about 15 object types 🧠. Some of the attributes are mandatory in certain objects, and some attributes may appear multiple times 😵‍💫. One or more attributes may form a key. Some attributes or sets of attributes may be required to be unique across all repositories 🔑. Some of the attributes may reference a key field in an object type and may be required to be a valid reference 🔗. Some attributes may be used in inverse lookups 🔄.

A review of the entire RIPE or RPSL schema would be too lengthy to include here, so only the differences in the schema are described 📝.

10.1. Changes to the RIPE/RPSL Schema ✨

okay so the RIPE/RPSL schema is getting a glow-up 💅 One brand new object type shows up, plus a bunch of new attributes, and the rules for whether adding an object is authorized get a major rewrite. no cap, this is the main character moment of the whole doc 🎀

The new object type is below. The first attribute is the key attribute, and it also names the object type 🦋

as-block        key  mandatory  single    unique
descr                optional   multiple
remarks              optional   multiple
admin-c              mandatory  multiple
tech-c               mandatory  multiple
notify               optional   multiple
mnt-by               mandatory  multiple
changed              mandatory  multiple
source               mandatory  single

In that object type, only the key attribute as-block is brand new 🌸

as-block: this one gives you the AS number range for an "as-block" object. It's two AS numbers, each including the substring "AS", separated by a "-" delimiter, with optional whitespace before and after the delimiter. Very neat 🍓

To level up authentication, the following keywords get added to the auth attribute 🔐

pgp-from: the rest of the attribute is the string that identifies a PGP identity whose public key lives in an external keyring. Heads up, this method is deprecated in favor of the pgpkey method 🙈
pgpkey: see [18]. 🔑

And there's a new none authentication method for when you want to disable authentication and let literally anyone through. It has no arguments 🌈

The auth attribute can now also show up in a person or role object. The auth method role or person can point at a role or person object and pull the auth fields from there. Implementations need to be careful here: they have to detect circular references and stop expanding, or skip the references they've already visited. Circular references are not the vibe 💀

A few attributes are added to the schema too ✨

mnt-routes: this one can appear in an aut-num, inetnum, or route object. It references a maintainer object that's used when figuring out authorization for adding route objects. After the maintainer reference, you can have an optional list of prefix ranges (as defined in RPSL) inside curly braces, or the keyword ANY. If you don't specify any extra set items, the default is ANY, which means all more specifics. mnt-routes is optional and multiple. See usage details in Section 9.1 🦋
mnt-lower: this one can appear in an inetnum, route, as-block, or aut-num object. It references a maintainer object. In an inetnum or route object, it works the same as mnt-routes, except it only applies to prefixes that are more specific than the prefix of the object it's sitting in 🫶 In an as-block object, mnt-lower allows adding more specific as-block objects or aut-num objects. In an aut-num object, mnt-lower names a maintainer that can be used to add objects with hierarchical names, as described in Section 9.7 🌸
reclaim: this one can appear in as-block, aut-num, inetnum, or route objects. Any object of the same type further down the hierarchy can be modified or deleted by the maintainer of the object that has the reclaim attribute. The value is a set or range of objects of the same type, and the set or range syntax is as defined in RPSL. See Section 9.5 for restrictions on adding reclaim attributes 🍓
no-reclaim: this one goes hand in hand with reclaim. It negates any reclaim attribute it overlaps. See Section 9.5 for restrictions on deleting no-reclaim attributes 👑
referral-by: this attribute is required in the maintainer object. It can never be altered after the maintainer is added. It refers to the maintainer that created this maintainer. It can be multiple if more than one signature showed up on the transaction that created the object 🧚
auth-override: a transaction submitted by a maintainer listed in the referral-by can add, delete, or change an auth-override. An auth-override can only be added to a maintainer if that maintainer has been inactive for the prior 60 days. The attribute itself only holds the date when it goes into effect, and that date must be at least 60 days from the current date, unless there's already authorization to modify the maintainer. Once that date is reached, the people identified by the maintainer in the referral-by are authorized to modify the maintainer. This attribute is basically a cleanup tool for when the holder of a maintainer goes unresponsive, and it only takes effect if the maintainer doesn't remove the auth-override in response to the automatic notification that goes out on changes 🥺

The existing mnt-by attribute references the maintainer object type. mnt-by is now mandatory in all object types. Any existing maintainer can add a new maintainer. The referral-by attribute is now mandatory in the maintainer object, so there's a record of which maintainer made the addition, and it can never be changed. And a maintainer can't be deleted as long as some other referral-by attribute is still referencing it 🔒

A. Core and Non-Core Functionality 💖

Most of the objects and attributes in this document are essential to the authorization framework. Those are the "core" functionality. A few attributes listed here are "non-core" 🌈

The reclaim and no-reclaim attributes are a convenience that gives you flexibility when you're implementing address lending 🦋

The auth-override attribute is a convenience that helps with recovery in any environment where repository data gets redistributed 🫶

The referal-by attribute is a "core" feature. An individual registry can express its autonomy by creating a self-referencing maintainer, one whose referal-by points to itself ✨ Other registries can decide case by case whether to treat that entry as valid 💅 A registry can also choose to only let referal-by refer to a specific maintainer that the registry controls. That extra restriction is purely local to the registry, so it's up to them 🌸

B. Examples ✨

Okay bestie, these examples leave out some required attributes that aren't needed to illustrate the objects and attributes in this document 💅 Missing are admin-c, tech-c, changed, and source. Also missing are attributes like mnt-nfy, which are a good practice but aren't strictly required 🫶

To do anything at all you need a maintainer 😭 At some epoch a single maintainer gets populated in one repository, and that maintainer has a referal-by pointing to itself. Every other referal-by reference can be traced back to that maintainer 🌸 At the same epoch the as-block AS0- AS65535 and the inetnum 0.0.0.0-255.255.255.255 are also allocated. Other ancilliary objects may also be needed to bootstrap ✨

mntner:        ROOT-MAINTAINER
auth:          pgpkey-12345678

mnt-by:        ROOT-MAINTAINER
referal-by:    ROOT-MAINTAINER

This root maintainer might add a top level maintainer for some organization 👑

mntner:        WIZARDS
descr:         High level Technical Folks
auth:          pgpkey-23456789
auth:          pgpkey-3456789a
mnt-by:        WIZARDS
referal-by:    ROOT-MAINTAINER

That maintainer might add another one with more limited capabilities 💖

mntner:        MORTALS
descr:         Maintain day to day operations
auth:          pgpkey-456789ab
auth:          pgpkey-56789abc
auth:          pgpkey-6789abcd
mnt-by:        WIZARDS
referal-by:    WIZARDS

Note that the WIZARDS can change their own maintainer object and the MORTALS maintainer object but MORTALS cannot 🙈

At some point an as-block is allocated and broken down. In the example below, private number space is used 🦋

as-block:      AS65500-AS65510
mnt-by:        SOME-REGISTRY
mnt-lower:     WIZARDS

Note that a registry has control over the object they created to represent the allocation, but has given the party the allocation was made to the ability to create more specific objects. Below this as-block, an aut-num is added. Note that import and export are normally required for an aut-num but are not shown here 🧚

aut-num:       AS65501
mnt-by:        WIZARDS
mnt-lower:     MORTALS

In the aut-num above, the WIZARDS maintainer can modify the aut-num itself. The MORTALS maintainer can add route objects using this AS as the origin if they also have authorization for the IP number space in a less specific route or inetnum 🔥

We also need an inetnum allocation. In this example the inetnum is allocated to a completely different organization. Again, attributes are omitted which would normally be needed in an inetnum 🌈

inetnum:       192.168.144.0-192.168.151.255
mnt-by:        SOME-REGISTRY
mnt-lower:     ISP
reclaim:       ALL

The maintainer ISP can add more specific inetnums or routes with this address space. Note that the registry has declared its ability to reclaim the address space 💅

If ISP wished to reclaim all allocations but some suballocation of theirs resisted, we might get something like the following, in which they will reclaim only the top half of an allocation (possibly if it remains unused) 😭

inetnum:       192.168.144.0-192.168.147.255
mnt-by:        ISP
mnt-lower:     EBG-COM
reclaim:       192.168.146/23+

If we assume that the maintainer EBG-COM and the maintainer MORTALS want to add a route object, one way to do it is for both parties to sign. If EBG-COM for some reason couldn't aggregate into a single top level route (which is inexcusable these days), or there was a preference for some reason to avoid the joint signature approach on a submission, either party could give the other permission to make the addition. A mnt-routes could be added to the aut-num, or a mnt-lower could be added to an inetnum 🫶

aut-num:       AS65501
mnt-by:        WIZARDS
mnt-lower:     MORTALS
mnt-routes:    EBG-COM {192.168.144/23}

With this change to the aut-num, the maintainer EBG-COM could add a route with origin AS65501, but only with a limited address range 🎀

route:         192.168.144/24
origin:        AS65501
descr:         These boneheads don't aggregate
mnt-by:        EBG-COM
mnt-by:        FICTION::MORTALS

Note that while the maintainer EBG-COM added the object, they allowed the maintainer MORTALS the ability to modify it 💜

If an object ended up in another repository, a single maintainer could still be used. In the example above, the notation FICTION::MORTALS indicates that the route object is in a different repository, and rather than duplicate the maintainer, a reference is made to the repository in which the MORTALS object resides 🌸

In the example below, a pair of route-sets are added and hierarchical names are used ✨

route-set:     AS65501:Customers
mnt-by:        WIZARDS
mnt-lower:     MORTALS

route-set:     AS65501:Customers:EBG-COM
mnt-by:        MORTALS
mnt-lower:     EBG-COM

Suppose that in the 192.168.144/24 object above, only the EBG-COM maintainer is listed. If EBG-COM goes bankrupt, no longer needs address space, and stops responding, it could be difficult to delete this object 😭 The maintainer listed in the EBG-COM referral-by attribute could be contacted. They could add an auth-override attribute to the EBG-COM object. Later they could modify the EBG-COM object, and then any objects with EBG-COM in the mnt-by 🧚

mntner:        EBG-COM
mnt-by:        EBG-COM
auth-override: 19990401

The examples above stray significantly from realism 🙈 They do provide simple illustrations of the usage of the objects, type, and attributes described in this document, and hopefully in doing some, they are of some value 🦋

C. Technical Discussion 🧠

A few design tradeoffs exist. Some of these tradeoffs, the selected solution, and the alternatives are discussed here. Some of the issues are listed below 👑

Whether to err on the side of permissiveness and weaken authorization controls, or risk the possibility of erecting barriers to registering information.
Whether to support enforceable address lending, or provide the smaller or end user with ultimate control over the registration of the prefixes they are using.
What to do with older objects that either don't conform to newer requirements regarding minimum authorization, authentication, and accountability, or are of questionable validity.

C.1. Relaxing requirements for ease of registry

If the requirement that an aut-num exists is relaxed, then it is possible for anyone to make use of an unassigned AS number, or to make use of an assigned AS number for which the aut-num has not been entered 😳 Placing requirements on the entry of aut-nums presumes cooperation of the Internet address allocation authority (if separate from the routing registry). The address allocation authority must be willing to field requests to populate skeleton aut-nums from the party for which the allocation has been made. These aut-nums must include a reference to a maintainer. A request to the address allocation authority must therefore include a reference to an existing maintainer 🔑

The ability to add route objects is also tied to the existence of less specific route objects or inetnums. The Internet address allocation authority (if separate from the routing registry) must also be willing to field requests to add inetnum records for the party already allocated the address space 🌍

The Internet address allocation authority should also add inetnums and aut-nums for new allocations. In order to do so, a maintainer must exist. If a party is going to connect to the Internet, they can get a maintainer by making a request to the Internet service provider they will be connecting to. Once they have a maintainer, they can make a request for address space or an AS number. The maintainer can contain a public key for a cryptographically strong authorization method, or could contain a "crypt-key" or "mail-to" authorization check if that is considered adequate by the registering party. Furthermore, an address allocation authority should verify that the request for an AS number or for address space matches the authorization criteria in the maintainer 💅

Currently only the registries themselves may add maintainers. This becomes a problem for the registry, particularly in verifying public keys. This requirement is relaxed by allowing existing maintainers to add maintainers. Unfortunately, the accountability trail does not exist for existing maintainers. The requirement then should be relaxed such that existing maintainers may remain, but only existing maintainers that have a "referral-by" attribute can add maintainers. The "referral-by" cannot be modified. This requirement can be relaxed slightly so that a "referral-by" can be added to a maintainer by an existing maintainer with a "referral-by". This will allow the accountability trail to be added to existing maintainers, and these maintainers can then add new maintainers 🫶

Verifying that a party is who they claim to be on initial addition is one of the problems that currently falls upon the AS number and address registry. This problem is reduced by allowing existing maintainers to add maintainers. This may actually make it easier to get maintainers, and therefore easier to register. The number authority still must verify that the AS or address space is actually needed by the party making a request 🌸

Authorization checks made during the addition of route objects that refer to AS objects and inetnums strongly rely on the cooperation of the Internet address allocation authorities. The number authorities must register as-blocks, aut-nums, or inetnums as AS numbers or address space is allocated. If only a subset of the number authorities cooperate, then either an inetnum or as-block can be created covering the space that registry allocates, essentially requiring null allocation (for example, a "crypt-pw" authentication where the password is given in the remarks in the object or its maintainer), or those obtaining addresses from that number authority will have trouble registering in the routing registry. The authorization model supports either option, though it would be preferable if the number authorities cooperated and the issue never surfaced in practice 🦋

The maintainer requirements can be relaxed slightly for existing maintainers, making it easier to register. Relaxing requirements on other objects may defeat the authorization model, hence is not an option 🚫✨

C.2. The address lending issue 🦋

Okay so the big question here is whether lending contracts should be enforceable, and that really comes down to who should ultimately get to control allocations of address space 💅. The routing registry would be wise to stay as neutral as possible when third parties are fighting. The reclaim and no-reclaim attributes exist so that either outcome is possible for whether the holder of a less specific inetnum or route object can exercise control over suballocations in the registry. The routing registry itself must decide whether to keep control for itself, and if it does, it should very clearly state under what conditions it would intervene. A registry could even go full dramatic and say it will only step in after the dispute has been resolved in court and a court order has been issued ⚖️😭

When an allocation is made by a registry, the registry should keep a reclaim attribute in the less specific object and make a strong policy statement that the reclaim privilege will not be used except under very clearly defined special circumstances. At the very minimum, those circumstances would include a court order 🔥. If the allocation gets further subdivided, the party subdividing the allocation and the party accepting the suballocation must decide whether a reclaim can be kept by the holder of the less specific allocation, or whether a no-reclaim must be added to transfer control to the holder of the more specific. The registry is not involved in that decision at all 🙅‍♀️. Different pairs of third parties may reach different decisions about reclaim and about any contractual restrictions on its use. Those restrictions can live outside the registry in a legal contract, and the courts would sort it out in the event of a bitter dispute 💀

By keeping reclaim rights, the registry keeps the ability to abide by a court order ✨. This may only truly become an issue in a distributed registry environment. There, registries will be rechecking the authorization of transactions made somewhere else, and they may fail to process another registry's attempt to abide by a court order. The fix is overriding normal authorization to change the registry contents, but only if a reclaim is present 🧚

C.3. Dealing with non-conformant or questionable older data 🧹

Some of the newer requirements say that all objects must reference a maintainer object responsible for the integrity of the object. They also require that accountability for the creation of maintainers gets recorded in the maintainer objects, so you can trace it back when a maintainer goes quiet 🕵️‍♀️. If contact information is absent or incorrect on objects and there's any question about whether they're valid, the maintainer can be contacted. If that maintainer is unresponsive, the maintainer that authorized the addition of that maintainer can be contacted. They can either update the contact information on the maintainer, or confirm that the entity no longer exists or is no longer actively using the Internet or the registry 🌈

Lots of route objects exist with no maintainers at all, and there are no inetnum or AS objects for them either. Some of them contain the now obsoleted guardian attribute instead of a mnt-by 🥲

It isn't practical to unconditionally purge old data that has no maintainers or doesn't conform to the authorization hierarchy. New additions have to conform to the new requirements, or the requirements are meaningless 💅. New requirements can be phased in by requiring modifications to conform to them.

A great deal of questionable data exists in the current registry 🙈. The requirement that all objects have maintainers, plus the improved accountability requirements for maintainers themselves, may make it easier to figure out contact information, even when objects haven't been updated to reflect contact changes.

It's not unreasonable to require valid contact information on existing data 🫶. A lot of data appears to be unused, such as route objects where no announcement has been seen in many months or years. An attempt should be made to contact the people listed in the object. Next try the maintainer if there is one, then go up the maintainer referral-by chain if there is one. If there's no maintainer accountability trail to follow, use the number registry or origin AS contact information. Experience so far shows that most deletions identified by comparing registered prefixes against route dumps will either get positively confirmed (which allows the deletion) or get no response because the contact information is invalid. In many cases the IRR contact information points to nsfnet-admin@merit.edu 📭

By letting the registry modify or delete any objects that are disconnected from the maintainer accountability trail, cleanup becomes possible 🧼. Mail header forging could in many cases have the same effect, but it's preferable to record the fact that the registry itself made the cleanup. In the future, a mechanism may also be needed to let the maintainer in the referral-by override maintainer privileges in a referred maintainer, but only if all contacts for that maintainer have become unresponsive 👑. The referral-by maintainer is allowed to add an auth-override attribute, which becomes usable as an auth within 60 days from the time it was added. The maintainer themselves would be notified of the change. They could remove the auth-override attribute before it becomes effective, ask why it was added, and correct whatever problem existed ✨. This can be supported immediately or added later if needed.

D. Common Operational Cases 🌸

In principle, address allocation and route allocation should be hierarchical, with the hierarchy matching the physical topology 🗺️. In practice, that's often not the case, for numerous reasons. The primary reasons are that the topology is not strictly tree structured and that the topology can change. More specifically:

The Internet topology is not strictly tree structured.
- At the top level, the network more closely resembles a moderately dense mesh.
- Near the bottom level, many attachments to the Internet are multi-homed to more than one Internet provider.
The Internet topology can and does change.
- Many attachments switch providers to get better service or terms.
- Service providers may modify adjacencies to get better transit service or terms.
- Service providers may disappear completely, scattering attachments, or they may merge.

Renumbering is viewed as a practical means to maintain a strict numeric hierarchy [16]. It's also acknowledged that renumbering IPv4 networks can be difficult [16, 3, 17] 😩. We'll look first at the simple case where hierarchy still exists. Then we'll look at the operational cases where the initial topology isn't tree structured, or where the topology changes.

D.1. simple hierarchical address allocation and route allocation 🧩

This is the simplest case. Large ranges of inetnums are assigned to address registries. Those registries in turn assign smaller ranges for direct use, or to topologically large entities, where allocations that follow topology can reduce the amount of routing information needed (promoting better route aggregation) 📦

AS objects are allocated as the topology dictates the need for additional AS [10]. Route objects can be registered by those with authorization given by the AS and by the address owner. This is never an issue where the maintainer of the AS and the inetnum are the same 🥰. Where they differ, either the provider can give permission to add route objects for their AS, or the party allocated the address space can give the provider permission to add route objects for their address space, or both parties can sign the transaction. Permission is provided by adding to maintainer attributes.

D.2. aggregation and multihomed more specific routes 🧃

Aggregation is normally not a problem if a provider is aggregating address space that was allocated to the provider, and then suballocating it internally and/or to customers. In fact, the provider would be expected to do so ✅. This isn't a problem even if the route object for the aggregation is added after the more specific route objects, since only less specific objects are considered.

Aggregation is potentially a problem if a provider, or a set of providers, plans to aggregate address space that was never explicitly allocated as a block to those providers, and instead remains the allocation of an address registry 🚨. These large aggregations can be expected to be uncommon, but they're relatively easy to deal with. Superaggregates of this type will generally be formed by topologically close entities who have also managed to draw adjacent address allocations. In effect, the registry must give permission to form such a superaggregate, either by granting permission in the mnt-routes of an inetnum, or by signing the submission along with the other parties 🫡

D.3. provider independent addresses and multiple origin AS 🌐

Provider independent addresses and multihoming arrangements using multiple origin AS present a problem similar to multihoming. The maintainer of the address space and the maintainer of the AS are not the same. Permission can be granted using mnt-routes, or multiple signatures can appear on the submission 🤝

D.4. change in Internet service provider 🔄

A change in Internet service provider is similar to multihoming. One small difference is that the AS for the more specific route will be the AS of the new provider, rather than the AS of the multihomed customer. Permission can be granted using mnt-routes, or multiple signatures can appear on the submission 💜

D.5. renumbering grace periods ⏳

Renumbering grace periods let a provider who wants to keep an address allocation intact allow a customer who has chosen to go to another provider to renumber their network gradually, then return the address space once renumbering is complete. Whether to require immediate renumbering or offer grace periods, how long those periods should be, or whether they should be indefinite has been the topic of bitter disputes 🍿. The authorization model can support no renumbering grace period, a finite renumbering grace period, or an indefinite renumbering grace period. The reclaim attribute described in Section 9.1 provides a means to end the grace period 🎀

E. Deployment Considerations ✨

Okay bestie, this section is all about the real-world rollout drama 🌍. It's not a deployment plan, just a bunch of issues and approaches to think about 💅.

The use of routing registries is not yet universally accepted 🙈. Some Internet providers still don't see the point of the extra assurance of accurate routing information from Section 6. Honestly, they think the benefits just aren't worth the cost. Mostly that's because, until recently, a very major router vendor couldn't handle prefix lists big enough to set routing policy on a per prefix basis 😤.

Another reason people give is that filtering on a prefix basis is risky when the routing registry info is incomplete or inaccurate, because it can break connectivity 💀.

There's a clear critical mass problem with routing registries 🌸. A small minority of providers use the existing IRR to filter on a per prefix basis. Another small minority don't support the IRR at all and generally don't register prefixes until someone reports a connectivity problem. The majority register their prefixes but don't actually do strict prefix filtering. Iconic behaviour, not gonna lie 💅.

Deploying new authentication mechanisms has no adverse consequences. This has been proven with Merit's deployment of PGP 🔐✨.

When it comes to deploying new authorization mechanisms, the big issue is dealing with existing data of very questionable origin 😭. A huge number of route objects refer to prefixes that haven't been announced in years. Other route objects refer to prefixes that are no longer announced with the origin AS they're registered under, and some were registered incorrectly from the start. There are a bunch of reasons this happened:

During the transition from the NSFNET PRDB to the RADB, a large number of prefixes were registered with an origin AS matching the border AS where the NSFNET had once heard the route announcements. The PRDB didn't support origin AS, so border AS was used instead. Many of these routes weren't in use anymore at the time, and they're still routed with a submitter listed as nsfnet-admin@merit.edu 🙃.
As CIDR got deployed, aggregates replaced previously separate more specific prefixes. The route objects for those more specific prefixes were never withdrawn from the routing registries 🧹.
Some prefixes are simply no longer in use. Some networks have been renumbered, and some networks no longer exist. The routing registry info often doesn't get withdrawn either 👻.
As provider AS adjacencies changed, and as end customers switched providers, the actual origin AS often changed too. That often wasn't reflected in the routing registry 🔄.

Inaccuracies are going to keep happening for all the reasons above, except the first one 🥲. The hierarchical authorization gives you more accountability, though 🦋. If the contacts for specific objects stop responding, you can traverse up the authorization hierarchy to help figure out which parties previously provided authorization. Those contacts may still have enough authorization to do the cleanup. This issue is discussed in Section C 🎀.

A great deal of information is still missing from the IRR 😩. Quite a few AS have no aut-num. Quite a lot of data has no maintainer, and the vast majority of maintainers only use the weakest authentication methods. The registries can't do much to fix that 🤷‍♀️. For missing objects needed for authorization, the default has to be to make no authentication checks at all 💜.

The transition can be staged like this 🪜:

Add and make use of stronger authorization models.
Make schema modifications necessary to support delegations.
Add delegation attributes needed for query traversal.
Base query traversal on delegations rather than a search of all known registries.
Obtain the cooperation of the address registries for the purpose of populating the "inetnum" entries on an ongoing basis.
Add hierarchical authorization support for critical object types, "aut-num", "inetnum" and "route".
Add the requirement that database objects either be in use or have valid contact information. If queries are made by the registry, a response from a contact indicating that the object serves a purpose is needed if it isn't clear what its use is.
Begin to purge data which is clearly not in use and for which there is no valid contact information or no response from the contacts 🧼.

Deploying hierarchical authorization needs cooperation among the existing routing registries 🤝. New code will have to be deployed. In some cases there are minimal development resources available, and there's a lot of inertia because everyone relies on the current repository and needs to avoid disruption 😮‍💨.

If hierarchical authorization of route objects depends on the existence of address registration information, you need minimal cooperation from the currently separate address registries. That cooperation basically means sending cryptographically signed transactions from the address registry to the number registry whenever address allocations are made, or providing equivalent access to new address allocations 🔐🌈.

Right now, most registries return query results from all of the known repositories using their mirrored copies. Cross registry authorizations aren't implemented yet 🚧. Minimal schema changes have to be made to support delegating objects that have an authorization hierarchy, and to support queries and references to other repositories. For AS delegations, "as-block" objects need to be created solely for the purpose of traversal 🧚.

F. Route Object Authorization Pseudocode

Here's a quick review of the basic concepts 📝✨.

The route object submission must satisfy two authentication criteria. It must match the authentication specified in the aut-num, and it must match the authentication specified in either a route object or, if no applicable route object is found, an inetnum 🔑.
When checking for prefix authorization, an exact route object prefix match is checked for first. If there isn't an exact match, then a longest prefix match that is less specific than the prefix is searched for. If the route prefix search fails, then a search is performed for an inetnum that exactly matches the prefix, or for the most specific inetnum that is less specific than the route object submission.

The search for an inetnum should never fail, but it may return an unallocated or reserved range. The inetnum status must be "allocated", and the submission must pass its maintainer authorization in order to get authorization from an inetnum. So an unallocated or reserved range inetnum will cause the route object submission to fail 🚫.

A route object must pass authorization from both the referenced aut-num object and the route or inetnum object. Authorization shall be tested using the maintainer(s) referenced in the "mnt-routes" attribute(s) first. If that check fails, the "mnt-lower" attributes are checked. If that check fails too, the "mnt-by" attributes are used for the authorization check 🔁.
The "reclaim" attribute can appear in inetnum, route and as-block objects, and it provides a means to support address lending 🤝🦋. "reclaim" gives authorization over more specific objects, regardless of the "mnt-by" in the object. The value of a "reclaim" attribute can be a list or set of objects, which gives you finer grain control.

The "reclaim" attribute matters here because it affects prefix/origin authentication when a new route object is submitted 👀.

The "no-reclaim" attribute is used to provide explicit exceptions 🙅‍♀️.

The following pseudocode outlines the algorithm used to check for proper authorization of a route object submission 💖.

Case #1.  Route object add
          (ie, no exact prefix/origin match exists).

/* first check the aut-num authorization */

if ( the referenced aut-num object does not exist or
     the aut-num authorization fails )
  authorization fails

/* next we check for prefix authorization */

if ( a less specific route(s) with the longest prefix is found ) [
  if ( authorization does not pass for at least one of the less
       specific route(s) )
    authorization fails

/* now check for a "reclaim" attr */

  if ( the object has a "reclaim" attribute ) [
    if ( no more-specifics exist
         OR a less specific exists which passes
            authorization and has a "reclaim" attribute

         OR all more specifics routess pass modify authorization )
      authorization passes
    else
      authorization fails
  ] else
    authorization passes
]

/* there are no less specific routes to check for prefix
   authentication, so we need to try and get authorization from an
   inetnum object */

if ( ( an inetnum is found that is an exact match
       OR is less specific and it's status is "allocated" )
     AND a maintainer referenced by the inetnum
         passes authorization )
  authorization succeeds

/* if there is no inetnum or route object then then
   authorization fails.  This should never happen if
   the DB is initialized properly. */

authorization fails.

Case #2.  Route object modify/delete
          (ie, exact prefix/origin match exists).

if ( the mnt-by passes authorization )
  authorization succeeds

/* if the authorization did not pass from the matched object,
   we can still get authorization from a less specific route if it
   has a "reclaim" attribute and we pass authorization */

if ( a less specific route or inetnum object passes authorization
     AND has a "reclaim" attribute applicable to
         the object to be modified )
  authorization succeeds
else
  authorization fails

Acknowledgments 🫶

This document draws ideas from loads of discussions and contributions from the IETF Routing Policy System Work Group and the RIPE Routing Work Group 🌸. Earlier drafts of this document listed Carol Orange as a co-author. Carol Orange made contributions to this document while at RIPE 💜.

Gerald Winters provided the pseudocode in an email message to the RIPE dbsec mailing list, and that message was the basis of the pseudocode found in appendix F 🧠. Susan Harris provided comments and numerous editorial corrections 👑✨.

Intellectual Property Notice ✨

okay so the IETF is like "we are NOT saying whether any patents or rights apply to this tech, and we're not saying we looked 🙃." 💅 If you want the rules on rights for standards-track stuff, go check BCP-11. Any rights claims, promises of licenses, or attempts to get general permission to use proprietary rights can be requested from the IETF Secretariat 📬. And if you spot any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to practice this standard, tell the IETF about it. Send that info to the IETF Executive Director 🫶.

References

[1] Alaettinoglu, C., Bates, T., Gerich, E., Karrenberg, D., Meyer, D., Terpstra M. and C. Villamizar, "Routing Policy Specification Language (RPSL)", RFC 2280, January 1998.
[2] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J-M., Karrenberg, D., Terpstra, M. and J. Yu, "Representation of IP Routing Policies in a Routing Registry (ripe-81++)", RFC 1786, March 1995.
[3] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 1997.
[4] Braun, H-W., "Models of policy based routing", RFC 1104, June 1989.
[5] Braun, H-W. and Y. Rekhter, "Advancing the NSFNET routing architecture", RFC 1222, May 1991.
[6] Clark, D., "Policy routing in Internet protocols", RFC 1102, May 1989.
[7] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[8] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
[9] Internet Engineering Steering Group and R. Hinden, "Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR)", RFC 1517, September 1993.
[10] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", RFC 1930, March 1996.
[11] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D. and J. Postel, "Internet Registry IP Allocation Guidelines", BCP 12, RFC 2050, November 1996.
[12] Knopper, M. and S. Richardson, "Aggregation Support in the NSFNET Policy-Based Routing Database", RFC 1482, June 1993.
[13] Meyer, D., Prior, M., Alaettinoglu, C., Schmitz, J. and Carol Orange, "Using RPSL in Practice", RFC 2650, August 1999.
[14] Rekhter, Y., "Routing in a Multi-provider Internet", RFC 1787, April 1995.
[15] Rekhter Y. and T. Li, "An Architecture for IP Address Allocation with CIDR", RFC 1518, September 1993.
[16] Rekhter Y. and T. Li, "Implications of Various Address Allocation Policies for Internet Routing", RFC 2008, October 1996.
[17] Rekhter, Y., Lothberg, P., Hinden, R., Deering, S. and J. Postel, "An IPv6 Provider-Based Unicast Address Format", RFC 2073, January 1997.
[18] Zsako, J., "PGP Authentication for RIPE Database Updates", RFC 2726, December 1999.

Security Considerations 🔐

okay this section is serious bestie, so no cap, pay attention 👀. This document is mainly about authorization rules for making additions, deletions, and changes to routing policy information repositories. The strong cryptographic authentication of these transactions is covered by [18], which is referenced throughout this document. The authorization rules are built so that any party mirroring a repository can verify the integrity of a transaction on its own, to make sure the rules were followed. For that to work, the mirror has to already contain data that is known to be properly authorized. In other words, the mirror must be complete, and authentication and authorization checks must be done continuously as changes to the repository are received and processed, in order.

Authentication on its own is not a complete security model 🙅‍♀️. Current practice only specifies authorization for deletions and changes, not for additions. The authorization rules in this document complete the security model for additions, deletions, and changes. They do this by very explicitly defining rules for additions, and by clarifying procedures for exception cases, like organizations that have ceased to exist and are therefore completely unresponsive 💀.

Authentication and authorization of queries are explicitly stated to be out of scope for this document 🙈.

Authors' Addresses

Curtis Villamizar Avici Systems EMail: curtis@avici.com

Cengiz Alaettinoglu ISI EMail: cengiz@ISI.EDU

David M. Meyer Cisco EMail: dmm@cisco.com

Sandy Murphy Trusted Information Systems EMail: sandy@tis.com

Full Copyright Statement ⚖️

okay so you can copy this document and share it with others, and you can make derivative works that comment on or explain it or help with implementing it, and you can prepare, copy, publish, and distribute those, in whole or in part, with no restrictions of any kind 🌈. The only catch is that the copyright notice and this paragraph have to stay on all copies and derivative works. This document itself cannot be modified in any way, like removing the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when it's needed for developing Internet standards, in which case the copyright procedures in the Internet Standards process must be followed, or when it's translated into languages other than English 🌍.

The limited permissions above are perpetual and will not be revoked by the Internet Society or its successors or assigns 💜.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society. ✨

📦 where this page comes from

ietf: rfc2725 1999-12
💖 girlified by claude-haiku-5-5 on 2026-10-16: a language model's rewrite of the original, under its terms