Routing Policy System Security
updated by
- rfc-4012 — Routing Policy Specification Language next generation (RPSLng)
Extracted elements (30)
Multiple authentication methods (mail-from through pgpkey) are supported and selected per-object because strong encryption software may not be legally available in all jurisdictions, yet the authorization model must prevent weak per-object authentication from undermining overall database integrity.
Route object addition requires dual authentication against both the origin AS (aut-num) and the address prefix (route or inetnum) because routes involve both the holder of the AS number and the holder of the address space. Either party acting alone is insufficient to authorize route announcements.
The auth-override mechanism requires 60-day delays and notifies the maintainer so that a legitimate maintainer who is merely slow to respond can remove the override before it takes effect, reducing the risk of unauthorized takeover while still enabling recovery from truly unresponsive maintainers.
The reclaim and no-reclaim attributes were designed to remain policy-neutral regarding address lending disputes. They allow either outcome—ISP retaining reclaim rights or customer having full control—without the registry taking sides, while still enabling court-order compliance in a distributed registry environment.
The referral-by attribute is immutable after creation so that an accountability trail can always be traced from an unresponsive maintainer back up the chain to a maintainer that can be contacted to take corrective action or confirm the entity no longer exists.
Objects without mnt-by attributes still exist in deployed registries. A missing mnt-by is interpreted as the absence of any control. New additions must conform to new requirements, but existing non-conformant data cannot be unconditionally purged.
The pgp-from authentication method is deprecated in favor of pgpkey so that the public key certificate is stored in the registry itself rather than an external keyring, making it accessible to remote repositories.
To reference objects in external repositories, the object key is preceded by the repository name and the delimiter ::, e.g., RIPE::CO19. Within a local repository, a bare key defaults to the local repository, but cross-repository references are unambiguous.
A reclaim attribute can only be added to an existing object if there are no existing exact matches or more specific objects overlapped by the new reclaim attribute, or if the submitter is listed in the mnt-by of overlapped objects, or if any overlapped object is listed in a no-reclaim attribute.
Adding a route object must satisfy two authentication criteria: it must match the authentication specified in the aut-num AND the authentication specified in either a matching route object or, if no applicable route object is found, an inetnum.
An auth-override attribute can only be added to a maintainer if that maintainer has been inactive for the prior 60 days, and the override date specified must be at least 60 days from the current date unless there is already authorization to modify the maintainer.
For route and inetnum objects, the applicable maintainer for authorization is taken from mnt-routes attributes if present; only in the absence of mnt-routes are mnt-by attributes used for that object.
Repositories are encouraged to disallow the addition of auth attributes with the deprecated pgp-from method. Repositories may elect to disallow weaker forms of authentication for local transaction submissions.
The mnt-by attribute is mandatory in all objects. A missing mnt-by attribute is interpreted as the absence of any control over changes, which is highly inadvisable, and most repositories will no longer allow this.
The referral-by attribute is mandatory in the maintainer object, records which maintainer created it, and may never be altered after the addition of the maintainer. Maintainers cannot be deleted as long as they are referenced by a referral-by attribute elsewhere.
Transactions should be signed using multiple digital signature techniques to allow repositories or mirrors that only use a subset of techniques to verify at least one of the signatures.
When adding an aut-num, the submission must match the authentication specified in the maintainer for the most specific AS-block. If the aut-num does not exist on a route add, the addition is rejected.
The as-block object delegates a range of AS numbers to a given repository. Its key attribute specifies two AS numbers separated by a dash (e.g., AS1321 - AS1335), enabling hierarchical authorization and directed queries across multiple repositories.
The auth-override attribute in a maintainer object, added by the referral-by maintainer, contains only the future date when it takes effect. After that date, the referral-by maintainer gains authorization to modify the maintained object, enabling recovery from unresponsive maintainers.
The maintainer object (mntner) serves as a container for authentication filters. It is referenced by name via mnt-by attributes in other objects to define authorization for operations on those objects. It must contain mnt-by and referral-by attributes.
The mnt-lower attribute may appear in inetnum, route, as-block, or aut-num objects. In inetnum/route objects it acts like mnt-routes but only for more specific prefixes; in as-block it allows addition of more specific as-block or aut-num objects.
The mnt-routes attribute may appear in aut-num, inetnum, or route objects and references a maintainer used for authorizing addition of route objects. It may optionally be constrained to a subset of more specific routes via a prefix list in curly braces or the keyword ANY.
The reclaim attribute in as-block, aut-num, inetnum, or route objects allows the maintainer of the less specific object to modify or delete any more specific object of the same type. The value specifies the range as defined in RPSL, with ALL covering all more specifics.
Authentication and authorization of database queries is explicitly out of scope. Mutual authentication of both the query origin and the repository from which results are obtained is also out of scope. This document only addresses integrity of additions, deletions, and changes.
Routing protocols provide no assurance that route origination is legitimate. Without a means to determine who is authorized to announce specific prefixes, there is no integrity of global routing information and an opportunity exists for a highly effective denial-of-service attack via injection of more specific CIDR prefixes.
The authorization model ensures that use of weak authentication in parts of the database does not compromise overall database integrity by tying route object addition to authorization derived from both the AS and the address prefix hierarchy.
The use of weak authentication methods (mail-from, crypt-pw) is discouraged because mail forgery is easy and crypt-pw passwords are transmitted in cleartext and are subject to guessing attacks via the exposed encrypted form. Strong cryptographic authentication (pgpkey) is preferred.
RPSL objects are represented externally as ASCII text. Each attribute is a single line: attribute name, colon, optional whitespace, value. Line continuation uses a trailing backslash or a following line beginning with whitespace. Objects are separated by blank lines.
The as-block key attribute specifies a range as two AS numbers including the substring AS separated by a dash delimiter with optional surrounding whitespace (e.g., AS1321 - AS1335).
The pgpkey auth attribute takes the form PGPKEY-hhhhhhhh where hhhhhhhh is the eight hex-digit representation of the four-byte PGP public key ID. The corresponding public key certificate is stored in a separate key-cert object.