Network Working Group R. Bush Internet-Draft IIJ Research & Arrcus Intended status: Standards Track T. Harrison Expires: 8 May 2025 APNIC 4 November 2024 Generalized RPSL External Reference draft-ymbk-opsawg-rpsl-extref-02 Abstract The Routing Policy Specification Language (RPSL), which has operationally evolved since it was standardized in 1999, has recently added a geofeed: attribute to the innet[6]num: class to reference data external to RPSL. There is now a proposal add another attribute referencing external data, prefixlen:. This document describes a more general and extensible mechanism for external references. It also tries to anticipate the RIRs evolving from RPSL to Registration Data Access Protocol (RDAP). 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 8 May 2025. Copyright Notice Copyright (c) 2024 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 (https://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 Bush & Harrison Expires 8 May 2025 [Page 1] Internet-Draft Generalized RPSL External Reference November 2024 extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 2. Existing External References . . . . . . . . . . . . . . . . 3 3. inetnum: Class . . . . . . . . . . . . . . . . . . . . . . . 3 4. Registration Data Access Protocol . . . . . . . . . . . . . . 4 5. Operational Considerations . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 9.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction The Routing Policy Specification Language (RPSL), which has operationally evolved since standardization in [RFC2622], has recently added a geofeed: attribute [RFC9632] to the inetnum: [INETNUM] and inet6num: [INET6NUM] classes to reference data external to RPSL. There is now a proposal add another attribute, prefixlen: [I-D.gasser-opsawg-prefix-lengths] referencing external data. This document describes a more general and extensible mechanism for external references to augment the RPSL inetnum: class [INETNUM] to refer to external data. In all places inetnum:, [INETNUM], is used, inet6num:, [INET6NUM], should also be assumed. It also tries to anticipate the RIRs evolving from RPSL to Registration Data Access Protocol (RDAP), [RFC7480], see Section 4. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Bush & Harrison Expires 8 May 2025 [Page 2] Internet-Draft Generalized RPSL External Reference November 2024 2. Existing External References RPSL, [RFC2622], as used by the Regional Internet Registries (RIRs), has been augmented with the inetnum: [INETNUM] and the inet6num: [INET6NUM] classes; each of which describes an IP address range and its attributes. Ongoing work has added and/or proposes to add multiple attributes to RPSL to reference objects external to RPSL. [RFC9632] descrbes how to reference geofeed files ([RFC8805]) from an RPSL inetnum: class. It is widely deployed. [I-D.gasser-opsawg-prefix-lengths] proposes to refrence prefixlen files from an RPSL inetnum: class. This way lies chaos. Where there are two, there will be more. This will cause continuing problems for work such as [I-D.ietf-regext-rdap-geofeed]. 3. inetnum: Class This document describes a generalized mechanism for external references. RPSL would be augmented to define a new RPSL extref: attribute in the inetnum: class. For example, given the two sub- types described above: inetnum: 192.0.2.0/24 # example extref: Geofeed https://example.com/geofeed extref: Prefixlen https://example.com/prefixlen Any particular inetnum: class MAY have at most one extref: of a particular sub-type. inetnum: classes form a hierarchy, see [INETNUM] Section 4.2.4.1, Hierarchy of INETNUM Objects. extref references SHOULD be at the lowest applicable inetnum: class. When fetching, the most specific inetnum: class with an extref reference of a particular sub-type MUST be used. When extref: references are provided by multiple inetnum: classes which have identical address ranges, then the extref: reference on the inetnum: with the most recent last-modified: attribute SHOULD be preferred. Bush & Harrison Expires 8 May 2025 [Page 3] Internet-Draft Generalized RPSL External Reference November 2024 4. Registration Data Access Protocol The Registration Data Access Protocol (RDAP) [RFC7480] is used by the RIRs and other Internet Number Registries to provide access to IP address registration data. In RDAP, the object that corresponds to the RPSL inetnum/inet6num object is the "ip network" object. This type of object may contain a set of links, with each link based on the structure defined in RFC 5988. For example: { "objectClassName": "ip network", "startAddress": "192.0.2.0", "endAddress": "192.0.2.127", ... "links": [ { "href": "https://rdap.example.net/ip/192.0.2.0/25", "rel": "self", "type": "application/rdap+json", "value": "https://rdap.example.net/ip/192.0.2.0/25" }, { "href": "https://rdap.example.net/ip/192.0.2.0/24", "rel": "up", "type": "application/rdap+json", "value": "https://rdap.example.net/ip/192.0.2.0/25" }, ... ], ... } Instances of external reference types defined in accordance with this document may be included in RDAP "ip network" objects in reliance on the existing link structure and syntax defined in RDAP. In RDAP, the only mandatory members of a link object are "value", "rel", and "href". "value" is the link context, and "href" is the link target, so those members are trivial to include, but "rel" is the link relation type, describing the relationship between the link context and the link target. While it would be possible to use a very generic link relation type, such as "related", for all external reference instances, using a more specific link relation type helps clients to find relevant links more quickly and easily. External reference subtype specifications SHOULD document the link relation type to be used for RDAP links for those references. Bush & Harrison Expires 8 May 2025 [Page 4] Internet-Draft Generalized RPSL External Reference November 2024 "type" is a link object member for the media type of the link target. It is not mandatory, but it is very common for it to be present. Similarly to link relation types, external reference subtype specifications SHOULD document the media type (or types) to be used for RDAP links for those references. RDAP defines an extension model that can be used to add new functionality to servers, or to add new members to existing object types, among other things. While it is not necessary to define an RDAP extension simply to make use of a new link relation type or media type in a link object in an RDAP response, an extension identifier can be used to signal to clients that an RDAP server has that data, and will make it available where it exists. External reference subtype specification authors SHOULD consider registering an RDAP extension for the subtype, in order to signal related behaviour to clients. 5. Operational Considerations To create the needed inetnum: classes, an operator wishing to register extref: attributes needs to coordinate with their RIR/NIR and/or any provider LIR which has assigned prefixes to them. RIRs/ NIRs provide means for assignees to create and maintain inetnum: classes. They also provide means of [sub-]assigning IP address resources and allowing the assignee to create whois data, including inetnum: classes, and thereby using extref: attributes. For a particular sub-type, the RFC defining it SHOULD specify the transport over which the reference SHOULD or MUST be fetched. Multiple inetnum: classes MAY refer to the same external resource. 6. Security Considerations It would be generally prudent for a consumer of extref data to also use other sources to cross-validate the data. All of the Security Considerations of the RFC defining a sub-type apply here as well. Many RPSL repositories have weak if any authentication. This would allow spoofing of inetnum: classes pointing to malicious extref files. If an inetnum: for a wide prefix (e.g. a /16) points to an external file, a customer or attacker could publish an equal or narrower (e.g. a /24) inetnum: in a whois registry which has weak authorization. Bush & Harrison Expires 8 May 2025 [Page 5] Internet-Draft Generalized RPSL External Reference November 2024 The RPSL providers have had to throttle fetching from their servers due to too-frequent queries. Usually they throttle by the querying IP address or block. Similar defenses will likely need to be deployed by extref file servers. Directing users and programs to external data has legal and technical risk exposure. Hence adding to the IANA SubTypee registry requires an RFC. One should still be cautious following links to or using external data. IF RDAP is used, the Security Considerations in [RFC7480] and therefore [RFC7481] should be considered. 7. IANA Considerations The IANA is requested to create an "rpsl-extref-subtype: registry as follows: SubType MIME Type Reference ------- ------------------------ --------- Geofeed application/geofeed+csv RFC9632 Registration of new SubTypes is by RFC per [RFC8126] Section 4. 8. Acknowledgements Thanks to the authors of [RFC8805], [RFC9092], and [RFC9632] and the folk they acknowledge from whom ideas and text have been liberally expropriated. George Michaelson also contributed. 9. References 9.1. Normative References [I-D.gasser-opsawg-prefix-lengths] Gasser, O., Bush, R., Candela, M., and R. Housley, "Publishing End-Site Prefix Lengths", Work in Progress, Internet-Draft, draft-gasser-opsawg-prefix-lengths-02, 4 November 2024, . [INET6NUM] RIPE, "Description of the INET6NUM Object", . Bush & Harrison Expires 8 May 2025 [Page 6] Internet-Draft Generalized RPSL External Reference November 2024 [INETNUM] RIPE, "Description of the INETNUM Object", . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, "Routing Policy Specification Language (RPSL)", RFC 2622, DOI 10.17487/RFC2622, June 1999, . [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, March 2015, . [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the Registration Data Access Protocol (RDAP)", STD 95, RFC 7481, DOI 10.17487/RFC7481, March 2015, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References [I-D.ietf-regext-rdap-geofeed] Singh, J. and T. Harrison, "An RDAP Extension for Geofeed Data", Work in Progress, Internet-Draft, draft-ietf- regext-rdap-geofeed-08, 18 October 2024, . [RFC8805] Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W. Kumari, "A Format for Self-Published IP Geolocation Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020, . Bush & Harrison Expires 8 May 2025 [Page 7] Internet-Draft Generalized RPSL External Reference November 2024 [RFC9092] Bush, R., Candela, M., Kumari, W., and R. Housley, "Finding and Using Geofeed Data", RFC 9092, DOI 10.17487/RFC9092, July 2021, . [RFC9632] Bush, R., Candela, M., Kumari, W., and R. Housley, "Finding and Using Geofeed Data", RFC 9632, DOI 10.17487/RFC9632, August 2024, . Authors' Addresses Randy Bush IIJ Research & Arrcus 5147 Crystal Springs Bainbridge Island, Washington 98110 United States of America Email: randy@psg.com Tom Harrison Asia Pacific Network Information Centre 6 Cordelia St South Brisbane QLD 4101 Australia Email: tomh@apnic.net Bush & Harrison Expires 8 May 2025 [Page 8]