Internet-Draft RDAP RIR Search October 2022
Harrison & Singh Expires 9 April 2023 [Page]
Workgroup:
Internet Engineering Task Force
Internet-Draft:
draft-harrison-regext-rdap-rir-search-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
T. Harrison
APNIC
J. Singh
ARIN

RDAP RIR Search

Abstract

The Registration Data Access Protocol (RDAP) is used by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs) to provide access to their resource registration information. The core specifications for RDAP define basic search functionality, but there are various IP and ASN-related search options provided by RIRs via their Whois services for which there is no corresponding RDAP functionality. This document extends RDAP to support those search options.

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 https://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 9 April 2023.

Table of Contents

1. Introduction

The Registration Data Access Protocol (RDAP) [RFC7480] is used by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs) to provide access to their resource registration information. The core specifications for RDAP define basic search functionality, but this is limited to domains, nameservers, and entities. No searches were defined for IP networks or autonomous system numbers.

In an effort to have RDAP reach feature parity with the existing RIR Whois services in this respect, this document defines additional search options for IP networks and autonomous system numbers, along with an additional link relation for finding more-specific resources.

1.1. Requirements Language

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] [RFC8174].

2. Search Path Segment Specification

The new resource type path segments for search are:

Search path segments are formed using the same logic as in section 3.2 of [RFC9082].

Syntax: ips?handle=<handle search pattern>

Syntax: ips?name=<name search pattern>

Searches for IP network information by handle are specified using the form:

ips?handle=XXXX

XXXX is a search pattern representing an IP network identifier, the syntax for which is specific to the registration provider. The following URL would be used to find information for IP networks with handles matching the "NET-199*" pattern:

https://example.com/rdap/ips?handle=NET-199*

Searches for IP network information by name are specified using the form:

ips?name=XXXX

XXXX is a search pattern representing an IP network identifier that is assigned to the network registration by the registration holder. The following URL would be used to find information for IP networks with names matching the "NET-EXAMPLE-*" pattern:

https://example.com/rdap/ips?name=NET-EXAMPLE-*

2.2. Autonomous System Number Search

Syntax: autnums?handle=<handle search pattern>

Syntax: autnums?name=<name search pattern>

Searches for autonomous system number information by handle are specified using the form:

autnums?handle=XXXX

XXXX is a search pattern representing an autonomous system number identifier, the syntax for which is specific to the registration provider. The following URL would be used to find information for autonomous system numbers with handles matching the "AS1*" pattern:

https://example.com/rdap/autnums?handle=AS1*

Searches for autonomous system number information by name are specified using the form:

autnums?name=XXXX

XXXX is a search pattern representing an autonomous system number identifier that is assigned to the autonomous system number registration by the registration holder. The following URL would be used to find information for autonomous system numbers with names matching the "ASN-EXAMPLE-*" pattern:

https://example.com/rdap/autnums?name=ASN-EXAMPLE-*

3. Responding To Searches

As with [RFC9083], responses to the IP network and autonomous system number searches defined in the previous section take the form of an array of object instances, where each instance is an appropriate object class for the search (i.e., a search for /ips yields an array of IP network object instances, and a search for /autnums yields an array of autonomous system number object instances). These arrays are contained within the response object.

The names of the arrays are as follows:

An IP network, autonomous system number, or reverse domain object may have a 'parent' object and one or more 'child' objects. The 'parent' object is the next-least-specific object that exists in the relevant registry, while the 'child' objects are the next-most-specific objects that exist in the relevant registry. For example, for a registry with the following four IP network objects:

the parent object of 192.0.2.0/32 would be 192.0.2.0/25, the parent object of 192.0.2.128/25 would be 192.0.2.0/24, the parent object of 192.0.2.0/25 would be 192.0.2.0/24, and 192.0.2.0/24 would have no parent object. Conversely, the child objects for 192.0.2.0/24 would be 192.0.2.0/25 and 192.0.2.128/25, for 192.0.2.0/25 192.0.2.0/32, and for 192.0.2.128/25 and 192.0.2.0/32 there would be no child objects.

In order to permit clients to locate the parent object for a given object, an operator MAY include a link using the "up" link relation that links to the parent object. Similarly, in order to permit clients to locate the child objects for a given object, an operator MAY include a link using the "down" link relation that when resolved, returns a response that has the same format as a search for the relevant object type containing all of the child objects for that object. For example:

{
  ...
  "links": [
    ...,
    {
      "value": "http://rdap.example.com/ip/192.0.2.0/25",
      "rel": "up",
      "href": "http://rdap.example.com/ip/192.0.2.0/24",
      "type": "application/rdap+json"
    },
    {
      "value": "http://rdap.example.com/ip/192.0.2.0/25",
      "rel": "down",
      "href": "http://rdap.example.com/ip-down/192.0.2.0/25",
      "type": "application/rdap+json"
    }
  ]
}

In the example above, the link target for the link with the "down" relation is "http://rdap.example.com/ip-down/192.0.2.0/25". However, the link structure used by a server for these links is not defined by this specification, and clients MUST NOT make inferences about supported behaviour by inspecting the structure of these links.

RDAP reverse search is defined by [I-D.ietf-regext-rdap-reverse-search]. That document limits reverse search to domains, nameservers, and entities. This document extends reverse search to cover IP networks and autonomous system numbers as well, by incorporating the text from section 2 and additionally permitting "searchable-resource-type" to be "ips" or "autnums".

6. RDAP Conformance

A server that supports all of the functionality specified in this document MUST include the string literal "rir_search" in the rdapConformance array in their response objects.

7. Privacy Considerations

The search functionality defined in this document may affect the privacy of entities in the registry (and elsewhere) in various ways: see [RFC6973] for a general treatment of privacy in protocol specifications. Registry operators should be aware of the tradeoffs that result from implementation of this functionality.

Many jurisdictions have laws or regulations that restrict the use of "Personal Data", per the definition in [RFC6973]. Given that, registry operators should ascertain whether the regulatory environment in which they operate permits implementation of the functionality defined in this document.

8. Security Considerations

[RFC7481] describes security requirements and considerations for RDAP generally.

9. IANA Considerations

IANA is requested to register the following value in the RDAP Extensions Registry:

IANA is also requested to register the following value in the Link Relations Registry:

10. Acknowledgements

TBD

11. References

11.1. Normative References

Loffredo, M. and M. Martinelli, "Registration Data Access Protocol (RDAP) Reverse search capabilities", Work in Progress, Internet-Draft, draft-ietf-regext-rdap-reverse-search-14, , <https://www.ietf.org/archive/id/draft-ietf-regext-rdap-reverse-search-14.txt>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC7481]
Hollenbeck, S. and N. Kong, "Security Services for the Registration Data Access Protocol (RDAP)", STD 95, RFC 7481, DOI 10.17487/RFC7481, , <https://www.rfc-editor.org/info/rfc7481>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC9082]
Hollenbeck, S. and A. Newton, "Registration Data Access Protocol (RDAP) Query Format", STD 95, RFC 9082, DOI 10.17487/RFC9082, , <https://www.rfc-editor.org/info/rfc9082>.
[RFC9083]
Hollenbeck, S. and A. Newton, "JSON Responses for the Registration Data Access Protocol (RDAP)", STD 95, RFC 9083, DOI 10.17487/RFC9083, , <https://www.rfc-editor.org/info/rfc9083>.

11.2. Informative References

[RFC6973]
Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, , <https://www.rfc-editor.org/info/rfc6973>.
[RFC7480]
Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the Registration Data Access Protocol (RDAP)", STD 95, RFC 7480, DOI 10.17487/RFC7480, , <https://www.rfc-editor.org/info/rfc7480>.

Authors' Addresses

Tom Harrison
Asia Pacific Network Information Centre
6 Cordelia St
South Brisbane QLD 4101
Australia
Jasdip Singh
American Registry for Internet Numbers
PO Box 232290
Centreville, VA 20120
United States of America