Internet DRAFT - draft-michaelson-rir-interface
draft-michaelson-rir-interface
Network Working Group G. Michaelson
Internet-Draft APNIC
Intended status: Informational D. Shaw
Expires: January 1, 2018 AFRINIC
C. Martinez
LACNIC
June 30, 2017
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
Michaelson, et al. Expires January 1, 2018 [Page 1]
Internet-Draft IPAM to RIR Interface June 2017
(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
2. Conventions Used In This Document . . . . . . . . . . . . . . 3
3. Potentially Unexpected Abbreviations and terms used in this
document . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Basic Operational Model . . . . . . . . . . . . . . . . . . . 4
5. possible protocols . . . . . . . . . . . . . . . . . . . . . 4
5.1. RIPE API and related bindings (draft) . . . . . . . . . . 5
5.2. ARIN API (TBD) . . . . . . . . . . . . . . . . . . . . . 5
5.3. APNIC API (ddraftraft) . . . . . . . . . . . . . . . . . 5
5.4. LACNIC API (draft) . . . . . . . . . . . . . . . . . . . 5
5.5. AFRINIC . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.5.1. "MyAFRINIC" . . . . . . . . . . . . . . . . . . . . . 6
5.5.2. Email WHOIS Submission . . . . . . . . . . . . . . . 6
5.5.3. WHOIS web form . . . . . . . . . . . . . . . . . . . 6
5.5.4. WHOIS port 43 . . . . . . . . . . . . . . . . . . . . 6
5.5.5. RDAP . . . . . . . . . . . . . . . . . . . . . . . . 6
5.5.6. RPKI . . . . . . . . . . . . . . . . . . . . . . . . 6
6. matrix of support by RIR and protocol/task . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
10. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
11. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
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
Michaelson, et al. Expires January 1, 2018 [Page 2]
Internet-Draft IPAM to RIR Interface June 2017
'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:_
o INR Internet Number Resources - the combination of IPv4 addresses,
IPv6 addresses and AS numbers - are collectively referred to as
INR.
o 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]
o APNIC
o AFRINIC
o LACNIC
o ARIN
o RIPE
o CNNIC
o TWNIC
o KRNIC
o VNNIC
o APJII
o IRNN
o Registro.BR
Michaelson, et al. Expires January 1, 2018 [Page 3]
Internet-Draft IPAM to RIR Interface June 2017
o RPSL
o RPKI
o 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
Michaelson, et al. Expires January 1, 2018 [Page 4]
Internet-Draft IPAM to RIR Interface June 2017
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)
Michaelson, et al. Expires January 1, 2018 [Page 5]
Internet-Draft IPAM to RIR Interface June 2017
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
o All tasks/operations, including writes/requests.
o Web based - manual (no API currently).
o Single factor auth - password login or certificate authentication.
o 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.
o Not an API, just a web form.
o All read-only queries possible on port 43 are supported.
o Also provides for updates/writes.
o 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.
Michaelson, et al. Expires January 1, 2018 [Page 6]
Internet-Draft IPAM to RIR Interface June 2017
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.
Michaelson, et al. Expires January 1, 2018 [Page 7]
Internet-Draft IPAM to RIR Interface June 2017
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
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
Authors' Addresses
George G. Michaelson
APNIC P/L.
6 Cordelia St
Brisbane, Queensland 4101
Australia
Phone: +61 7 3858 3100
Email: ggm@apnic.net
Daniel Shaw
AFRINIC Ltd.
11th floor, Standard Chartered Tower
Ebene
Mauritius
Phone: +230 403 5134
Email: daniel@afrinic.net
Carlos M. Martinez
LACNIC
Rambla Republica de Mexico 6125, 11400 Montevideo, Uruguay
Montevideo
Uruguay
Phone: +598 2 6042222
Email: carlos@lacnic.net
Michaelson, et al. Expires January 1, 2018 [Page 8]
