Interfacing from IPAM to the RIR systems
draft-michaelson-rir-interface-01

Abstract

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.

Status of This Memo

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 Notice

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.

Table of Contents

• 1. Introduction
• 2. Conventions Used In This Document
• 3. Potentially Unexpected Abbreviations and terms used in this document
• 4. Basic Operational Model
• 5. possible protocols
• 5.1. RIPE API and related bindings (draft)
• 5.2. ARIN API (TBD)
• 5.3. APNIC API (ddraftraft)
• 5.4. LACNIC API (draft)
• 5.5. AFRINIC
• 5.5.1. "MyAFRINIC"
• 5.5.2. Email WHOIS Submission
• 5.5.3. WHOIS web form
• 5.5.4. WHOIS port 43
• 5.5.5. RDAP
• 5.5.6. RPKI
• 6. matrix of support by RIR and protocol/task
• 7. IANA Considerations
• 8. Security Considerations
• 9. Acknowledgements
• 10. Notes
• 11. Normative References
• Authors' Addresses

1. Introduction

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).

2. Conventions Used In This Document

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.

3. Potentially Unexpected Abbreviations and terms used in this document

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

4. Basic Operational Model

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:

1. 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.
2. 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).
3. register Nameservers (NS) to be associated with specified (sub)sets of IPv4 and IPv6 addresses, for reverse-DNS delegation.
4. register Delegation Signer (DS) records, to bind DNSSEC over the specified (sub)sets of IPv4 and IPv6 addresses for secure reverse-DNS delegation.
5. enable RPKI, and exchange basic business PKI b(PKI) identity information to be used over the provisioning protocol channel.
6. manage WHOIS objects for internet routing (IRR). Create, delete and modify records.
7. manage WHOIS objects for customer/more-specific sub-assignment record keeping. Create, delete and modify records.
8. request INR in line with the RIR policy.
9. register interest in acquiring INR, subject to RIR policy.
10. register interest in releasing INR, either for return to the registry or for transfer, subject to RIR policy.

5. possible protocols

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.

1. RIPE Whois v3 'Syncupdates' (whois objects, reverse DNS)
2. ARIN API [TBD]
3. APNIC API (some whois objects, reverse DNS)
4. LACNIC API
5. AFRINIC
6. RPKI provisioning protocol
7. email submission of WHOIS updates
8. WHOIS query (port 43)
9. RDAP query
10. RPKI publication protocol

5.1. RIPE API and related bindings (draft)

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>

5.2. ARIN API (TBD)

RESTful API to ARIN public whois services

see <https://www.arin.net/resources/whoisrws/whois_api.html>

5.3. APNIC API (ddraftraft)

see <https://www.apnic.net/manage-ip/apnic-services/services-roadmap/public-api-draft-for-members/>

5.4. LACNIC API (draft)

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:

1. Point-of-Contact management
2. Managing Organizations
3. Managing IPv4 / IPv6 ranges (including reverse DNS delegations)
4. Managing ASN registrations

More information can be found at: <http://www.lacnic.net/en/web/lacnic/sara>

5.5. AFRINIC

5.5.1. "MyAFRINIC"

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.

5.5.2. Email WHOIS Submission

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.

5.5.3. WHOIS web form

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.

5.5.4. WHOIS port 43

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

5.5.5. RDAP

Standard RDAP. Reference multiple RFCs here.

5.5.6. RPKI

Reference AFRINIC public repo.

6. matrix of support by RIR and protocol/task

7. IANA Considerations

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

8. Security Considerations

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

9. Acknowledgements

10. Notes

''' 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. '''

11. Normative References

Authors' Addresses