Interfacing from IPAM to the RIR systems

The idea here is to give some "why" background, to the need for this document. It is in the problem-specification space, saying there is a role for an upward facing interface to be specified, and what kinds of things can be done over it. CASM explores the application of address space management to a complex system of network routers and switches and associated systems. Its basic operating model is documented elsewhere. A common element of this operating model is that the address space is a 'given' - a set of resources are assumed to exist for application into the network. But, this 'given' is not an axiom of the system, it is something which lives inside another information management model, the one operated in common by the RIR, under the aegis of the NRO. The RIR information systems consist of completely independent software suites, developed over a long time and reflecting specific information management goals of each instance. There is currently no unified access model, no unified identity and authorisation model and some shared information models (such as RPSL, RDAP, RPKI, reverse-DNS).

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in when they appear in ALL CAPS. These words may also appear in this document in lower case as plain English words, absent their normative meanings.

It's possible this won't be necessary, INR feels like it may need defining. And some others: INR Internet Number Resources - the combination of IPv4 addresses, IPv6 addresses and AS numbers - are collectively referred to as INR. NIR National Internet Registry - a sub registry of the APNIC or LACNIC region, which has independent status and authority under the global address policy and co-ordinates INR for a given economy, under the aegis of an RIR. [TBD] APNIC AFRINIC LACNIC ARIN RIPE CNNIC TWNIC KRNIC VNNIC APJII IRNN Registro.BR RPSL RPKI reverse-DNS

It is assumed that an entity seeking to apply a CASM approach to INR management has an account with one or more RIR, and is able to register for online services in some manner with the RIR. Given some secure access method (eg, a 2 factor authentication system, or an API key system which issues an ephemeral session token) the entity should be able to perform the following: get a list of supported functions from this RIR parent, which might be a subset of the remaining functions since not all services are provided at all RIR. request a list of all INR held, by category. This will be a set of addresses and AS numbers, in a canonical form (no overlaps, all resources represented as either prefix or ranges). register Nameservers (NS) to be associated with specified (sub)sets of IPv4 and IPv6 addresses, for reverse-DNS delegation. register Delegation Signer (DS) records, to bind DNSSEC over the specified (sub)sets of IPv4 and IPv6 addresses for secure reverse-DNS delegation. enable RPKI, and exchange basic business PKI b(PKI) identity information to be used over the provisioning protocol channel. manage WHOIS objects for internet routing (IRR). Create, delete and modify records. manage WHOIS objects for customer/more-specific sub-assignment record keeping. Create, delete and modify records. request INR in line with the RIR policy. register interest in acquiring INR, subject to RIR policy. register interest in releasing INR, either for return to the registry or for transfer, subject to RIR policy.

At the time of writing, there is not a single definition of interface across this space for all RIR. Interfaces will have to be developed in some cases, and prior information systems exist in others, which can be adapted to provide some of the functions. RIPE Whois v3 'Syncupdates' (whois objects, reverse DNS) ARIN API [TBD] APNIC API (some whois objects, reverse DNS) LACNIC API AFRINIC RPKI provisioning protocol email submission of WHOIS updates WHOIS query (port 43) RDAP query RPKI publication protocol

RIPE NCC have a number of member related APIs documented at A beta hosted CA API to manage hosted ROA services is documented at Whois maintenance via a REST API is documented at: syncupdates and mail-updates which may also be available at APNIC and AFRINIC, are documented here:

RESTful API to ARIN public whois services see

see

LACNIC currently operates a project named SARA (SARA is the Spanish acronym for "Automated Resource Management System"). SARA provides an EPP-based interface for members allowing them to perform, among others, the following operations: Point-of-Contact management Managing Organizations Managing IPv4 / IPv6 ranges (including reverse DNS delegations) Managing ASN registrations More information can be found at:

AFRINIC's member portal All tasks/operations, including writes/requests. Web based - manual (no API currently). Single factor auth - password login or certificate authentication. Also non-CASM related RIR functions.

AFRINIC allows for updates of the WHOIS database by email submission. Authentication is supported by plain password in the body (not recommended), or by PGP signed emails.

The AFRINIC web site includes an embedded web interface to the WHOIS DB. Not an API, just a web form. All read-only queries possible on port 43 are supported. Also provides for updates/writes. Single factor (password) authentication.

Standard port 43. Reference port 43 RFC here. Supports "RIPE" flags.

Standard RDAP. Reference multiple RFCs here.

Reference AFRINIC public repo.

IANA is not expected to have a direct role in this problem space

AAA models have to be developed which preserve the integrity of the resource management systems in the RIR systems.

''' If you like, the primary driver CASM cares about is: "list all my resources If we simply specify how that can be done, at each RIR, then we can leave the rest as TBD. For APNIC (for instance) this would be a set of WHOIS or RDAP queries which specified a member. Once we have org-id implemented it would be as simple as an inverse-query in WHOIS on an org-id. Because we don't have that, it currently demands a bit more ad-hoc heuristics. RIPE has org-id so for RIPE, this is really done. It's possible the best we can say is that absent a single consistent mechanism, a CASM specified IPAM system should let somebody declare by fiat what resources they control, and use some consistent representation of them, and how they are confirmed inside an RIR is out of scope. I think that's a low goal and would probably stand as the implicit problem definition: we should do better. The secondary set includes things like: "manage my reverse-DNS" "manage my publicly visible WHOIS/RDAP" "manage my IRR" "manage my RPKI" "manage my contact and other ownership info" "request more resources" "formally acquire more resources" "transfer resources out" Not all of these exist in all API at all RIR, or in ways which it makes sense to say are machine managed online. We don't have a cross RIR consistent view on auth, tokens. We don't all use the same representations across our API. This is just a given. '''