Interfacing from IPAM to the RIR systems
APNIC P/L.
6 Cordelia St
Brisbane
4101
Australia
Queensland
+61 7 3858 3100
ggm@apnic.net
AFRINIC Ltd.
11th floor, Standard Chartered Tower
Ebene
Mauritius
+230 403 5134
daniel@afrinic.net
LACNIC
Rambla República de México 6125, 11400 Montevideo, Uruguay
Montevideo
Uruguay
+598 2 6042222
carlos@lacnic.net
Internet
RIR
IPAM
CASM
The CASM BoF at IETF98 discussed the need for Coordinated Address Space Management, in a 'downward' facing manner: the application of automatic configuration to information systems under the control of an entity.
This document explores the requirements for 'upward' facing systems interfaces to permit the address space related information to be fetched from assigning bodies, and maintained inside their systems as required.
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
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.
'''