| Network Working Group | G. Michaelson |
| Internet-Draft | APNIC |
| Intended status: Standards Track | D. Shaw |
| Expires: January 1, 2018 | AFRINIC |
| C. Martinez | |
| LACNIC | |
| June 30, 2017 |
Interfacing from IPAM to the RIR systems
draft-michaelson-rir-interface-00
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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 1, 2018.
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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 [RFC2119] 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:
[TBD]
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:
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 NCC have a number of member related APIs documented at <https://www.ripe.net/support/documentation/developer-documentation>
A beta hosted CA API to manage hosted ROA services is documented at <https://www.ripe.net/support/documentation/developer-documentation/rpki-management-api>
Whois maintenance via a REST API is documented at: <https://github.com/RIPE-NCC/whois/wiki/WHOIS-REST-API>
syncupdates and mail-updates which may also be available at APNIC and AFRINIC, are documented here: <https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/updating-objects-in-the-ripe-database/6-3-syncupdates> <https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/updating-objects-in-the-ripe-database/6-4-email-updates>
RESTful API to ARIN public whois services
see <https://www.arin.net/resources/whoisrws/whois_api.html>
see <https://www.apnic.net/manage-ip/apnic-services/services-roadmap/public-api-draft-for-members/>
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:
More information can be found at: <http://www.lacnic.net/en/web/lacnic/sara>
AFRINIC's member portal
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.
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. '''
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |