[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/