drip Working Group A. Wiethuechter, Ed. Internet-Draft AX Enterprize, LLC Intended status: Standards Track J. Reid Expires: 4 September 2025 RTFM llp 3 March 2025 DRIP Entity Tags (DET) in the Domain Name System (DNS) draft-ietf-drip-registries-24 Abstract This document describes the discovery and management of DRIP Entity Tags (DETs) in DNS. Authoritative Name Servers, with DRIP specific DNS structures and standard DNS methods, are the Public Information Registries for DETs and their related metadata. 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 4 September 2025. Copyright Notice Copyright (c) 2025 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 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. Wiethuechter & Reid Expires 4 September 2025 [Page 1] Internet-Draft DET in DNS March 2025 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. General Concept . . . . . . . . . . . . . . . . . . . . . 4 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Required Terminology . . . . . . . . . . . . . . . . . . 4 2.2. Additional Definitions . . . . . . . . . . . . . . . . . 4 3. DET Hierarchy in DNS . . . . . . . . . . . . . . . . . . . . 5 3.1. Use of Existing DNS Models . . . . . . . . . . . . . . . 6 3.1.1. DNS Model Considerations for DIMEs . . . . . . . . . 6 4. Public Information Registry . . . . . . . . . . . . . . . . . 8 5. Resource Records . . . . . . . . . . . . . . . . . . . . . . 9 5.1. HHIT Resource Record . . . . . . . . . . . . . . . . . . 9 5.1.1. Text Representation . . . . . . . . . . . . . . . . . 9 5.1.2. Field Descriptions . . . . . . . . . . . . . . . . . 10 5.2. UAS Broadcast RID Resource Record . . . . . . . . . . . . 10 5.2.1. Text Representation . . . . . . . . . . . . . . . . . 11 5.2.2. Field Descriptions . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6.1. DET Prefix Delegation . . . . . . . . . . . . . . . . . . 13 6.2. IANA DRIP Registry . . . . . . . . . . . . . . . . . . . 13 6.2.1. DRIP RAA Allocations . . . . . . . . . . . . . . . . 13 6.2.2. HHIT Entity Type . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7.1. DNS Operational Considerations . . . . . . . . . . . . . 16 7.2. Public Key Exposure . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction Registries are fundamental to Unmanned Aircraft System (UAS) Remote Identification (RID). Only very limited operational information can be sent via Broadcast RID, but extended information is sometimes needed. The most essential element of information from RID is the UAS ID, the unique key for lookup of extended information in relevant registries (see Figure 1; Figure 4 of [RFC9434]). Wiethuechter & Reid Expires 4 September 2025 [Page 2] Internet-Draft DET in DNS March 2025 *************** *************** * UAS1 * * UAS2 * * * * * * +--------+ * DAA/V2V * +--------+ * * | UA o--*----------------------------------------*--o UA | * * +--o--o--+ * * +--o--o--+ * * | | * +------+ Lookups +------+ * | | * * | | * | GPOD o------. .------o PSOD | * | | * * | | * +------+ | | +------+ * | | * * | | * | | * | | * * C2 | | * V2I ************ V2I * | | C2 * * | '-----*--------------* *--------------*-----' | * * | * * * * | * * | o====Net-RID===* *====Net-RID===o | * * +--o--+ * * Internet * * +--o--+ * * | GCS o-----*--------------* *--------------*-----o GCS | * * +-----+ * Registration * * Registration * +-----+ * * * (and UTM) * * (and UTM) * * *************** ************ *************** | | | +----------+ | | | +----------+ | Public o---' | '---o Private | | Registry | | | Registry | +----------+ | +----------+ +--o--+ | DNS | +-----+ DAA: Detect And Avoid GPOD: General Public Observer Device PSOD: Public Safety Observer Device V2I: Vehicle-to-Infrastructure V2V: Vehicle-to-Vehicle Figure 1: Global UAS RID Usage Scenario (Figure 4 of RFC9434) When a DRIP Entity Tag (DET) [RFC9374] is used as the UAS ID in RID, extended information can be retrieved from a DRIP Identity Management Entity (DIME), which manages registration of and associated lookups from DETs. In this document it is assumed the DIME is a function of UAS Service Suppliers (USS) (Appendix A.2 of [RFC9434]) but a DIME can be independent or handled by another entity as well. Wiethuechter & Reid Expires 4 September 2025 [Page 3] Internet-Draft DET in DNS March 2025 1.1. General Concept DRIP Entity Tags (DETs) embedded a hierarchy scheme which is mapped onto the Domain Name System (DNS) [STD13]. DIMEs enforce registration and information access of data associated with a DET while also providing the trust inherited from being a member of the hierarchy. Other identifiers and their methods are out of scope for this document. Authoritative Name Servers of the DNS provide the public information such as the cryptographic keys, endorsements and certificates of DETs and pointers to private information resources. Cryptographic (public) keys are used to authenticate anything signed by a DET, such as in the Authentication defined in [RFC9575] for Broadcast RID. Endorsements and certificates are used to endorse the claim of being part of the hierarchy. This document does not specify AAA mechanisms used by Private Information Registries to store and protect Personally Identifiable Information (PII). 1.2. Scope The scope of this document is the DNS registration of DETs with the DNS delegation of the reverse domain of IPv6 Prefix, assigned by IANA for DETs 2001:30::/28 and RRsets used to handle DETs. Other sectors may adopt this technology. It is recommended that a global apex (i.e., IPv6 prefix) and international apex manager be designated for each sector. 2. Terminology 2.1. Required Terminology 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. 2.2. Additional Definitions This document makes use of the terms (USS, etc.) defined in [RFC9153]. Other terms (DIME, Endorsement, etc.) are from [RFC9434], while others (RAA, HDA, etc.) are from [RFC9374]. Wiethuechter & Reid Expires 4 September 2025 [Page 4] Internet-Draft DET in DNS March 2025 3. DET Hierarchy in DNS [RFC9374] defines the HHIT and further specifies an instance of them used for UAS RID called DETs. The HHIT is a 128-bit value that is as an IPv6 address intended primarily as an identifier rather than locator. Its format is in Figure 2, shown here for reference, and further information is in [RFC9374]. +-------------+--------------+---------------+-------------+ | IPv6 Prefix | Hierarchy ID | HHIT Suite ID | ORCHID Hash | | (28 bits) | (28 bits) | (8 bits) | (64 bits) | +-------------+--------------+---------------+-------------+ / \ / \ / \-----------------------------\ / \ / \ +--------------------------------+-----------------------+ | Registered Assigning Authority | HHIT Domain Authority | | (14 bits) | (14 bits) | +--------------------------------+-----------------------+ Figure 2: DRIP Entity Tag Breakdown The IPv6 Prefix, assigned by IANA for DETs is 2001:30::/28. The corresponding domain (nibble reversed as 3.0.0.1.0.0.2.ip6.arpa) is owned by the IAB. Due to the nature of the hierarchy split and its relationship to nibble reversing of the IPv6 address, the upper level of hierarchy (i.e., Registered Assigning Authority (RAA)) "borrows" the upper two bits of their respective HHIT Domain Authority (HDA) space for DNS delegation. As such the IPv6 prefix of RAAs are 2001:3x:xxx::/44 and HDAs are 2001:3x:xxxy:yy::/56 with respective nibble reverse domains of x.x.x.x.3.0.0.1.0.0.2.ip6.arpa and y.y.y.x.x.x.x.3.0.0.1.0.0.2.ip6.arpa. This document preallocates a subset of RAAs based on the ISO 3166-1 Numeric Nation Code [ISO3166-1]. This is to support the initial use case of DETs in UAS RID on an international level. See Section 6.2.1 for the RAA allocations. The HDA values of 0, 4096, 8192 and 12288 are reserved for operational use of an RAA (a by-product of the above mentioned borrowing of bits), specifically when to register with the apex and endorse delegations of HDAs in their namespace. Wiethuechter & Reid Expires 4 September 2025 [Page 5] Internet-Draft DET in DNS March 2025 The administration, management and policy for operation a DIME at any level in the hierarchy (Apex, RAA or HDA), be it external or from a parent level, is out of scope for this document. In some cases, such as the RAAs and HDAs of a nation, these are national matters which are to be dealt with by those parties accordingly. 3.1. Use of Existing DNS Models DRIP relies on the DNS and as such roughly follows the registrant- registrar-registry model. In the UAS ecosystem, the registrant would be the end user who owns/controls the Unmanned Aircraft. They are ultimately responsible for the DET and any other information that gets published in the DNS. Registrants use agents known as registrars to manage their interactions with the registry. Registrars typically provide optional additional services such as DNS hosting. The registry maintains a database of the registered domain names and their related metadata such as the contact details for domain name holder and the relevant registrar. The registry provides DNS service for the zone apex which contains delegation information for domain names. Registries generally provide services such as WHOIS [RFC3912] or RDAP [STD95] to publish metadata about the registered domain names and their registrants and registrars. Registrants have contracts with registrars who in turn have contracts with registries. Payments follow this model too: the registrant buys services from a registrar who pays for services provided by the registry. By definition, there can only be one registry for a domain name. Since that registry is a de facto monopoly, the scope of its activities is usually kept to a minimum to reduce the potential for market distortions or anti-competitive practices. A registry can have an arbitrary number of registrars who compete with each other on price, service and customer support. 3.1.1. DNS Model Considerations for DIMEs Wiethuechter & Reid Expires 4 September 2025 [Page 6] Internet-Draft DET in DNS March 2025 Apex Registry/Registrar (IANA) +=========================+ | 3.0.0.1.0.0.2.ip6.arpa. | +============o============+ | --------------------------------------|------------------------- National | Registries/Registrars | (RAA) | | +--------------+--------------o-+---------------+ | | | | +=====o====+ +====o=====+ +=====o====+ +=====o====+ | 0.0.0.0. | | 1.0.0.0. | | 2.0.0.0. | | 3.0.0.0. | +====o=====+ +====o=====+ +====o=====+ +====o=====+ | ---------------------------------------|------------------------ Local | Registries/Registrars | (HDA) | | +--------------+---------------o--------...-----+ | | | | +=====o====+ +====o=====+ +====o=====+ +=====o====+ | 1.0.0. | | 2.0.0. | | 3.0.0. | | f.f.f. | +====o=====+ +=====o====+ +====o=====+ +====o=====+ | ---------------------------------------|------------------------ Local | Registrants | +=====================o================+ | x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.5.0. | +======================================+ Figure 3: Example DRIP DNS Model While the registrant-registrar-registry model is mature and well understood, it may not be appropriate for DRIP registrations in some circumstances. It could add costs and complexity: developing policies and contracts as outlined above. On the other hand, registries and registrars offer customer service/support and can provide the supporting infrastructure for reliable DNS and WHOIS or RDAP service. Wiethuechter & Reid Expires 4 September 2025 [Page 7] Internet-Draft DET in DNS March 2025 Another approach could be to handle DRIP registrations in a comparable way to how IP address space gets provisioned. Here, blocks of addresses get delegated to a "trusted" third party, typically an ISP, who then issues IP addresses to its customers. For DRIP, blocks of IP addresses could be delegated from the 3.0.0.1.0.0.2.ip6.arpa domain (reverse domain of prefix allocated by [RFC9374]) to an entity chosen by the appropriate Civil Aviation Authority (CAA). This third party would be responsible for the corresponding DNS and WHOIS or RDAP infrastructure for these IP address blocks. They would also provision the Hierarchial Host Identity Tag (HHIT, [RFC9374]) records for these IP addresses. In principle a manufacturer or vendor of UAS devices could provide that role. This is shown as an example in Figure 3. Dynamic DRIP registration is another possible solution, for example when the operator of a UAS device registers its corresponding HHIT record and other resources before a flight and deletes them afterwards. This may be feasible in controlled environments with well-behaved actors. However, this approach may not scale since each device is likely to need credentials for updating the IT infrastructure which provisions the DNS. Registration policies - pricing, renewals, registrar and registrant agreements, etc. - will need to be developed. These considerations should be determined by the CAA, perhaps in consultation with local stakeholders to assess the cost-benefits of these approaches (and others). All of these are out of scope for this document. The specifics for the UAS RID use case are detailed in the rest of document. 4. Public Information Registry Per [RFC9434] all information classified, by all parties involved, as public is stored in the DNS, specifically Authoritative Name Servers, to satisfy REG-1 from [RFC9153]. Authoritative Name Servers use domain names as handles and data is stored in Resource Records (RR) with associated RRTypes. This document defines two new RRTypes, one for HHIT metadata (HHIT, Section 5.1) and another for UAS Broadcast RID information (BRID, Section 5.2). The former RRType is particularly important as it contains a URI (as part of the certificate) that point to Private Information resources. Wiethuechter & Reid Expires 4 September 2025 [Page 8] Internet-Draft DET in DNS March 2025 DETs, being IPv6 addresses, are to be under ip6.arpa (nibble reversed per convention) and MUST ultimately resolve, at minimum, to an HHIT RRType. Depending on local circumstances or additional use cases other RRTypes MAY be present. For UAS RID the BRID RRType MUST be present to provide the Broadcast Endorsements defined in [RFC9575]. DNSSEC is strongly RECOMMENDED (especially for RAA-level and higher zones). When a DIME decides to use DNSSEC they SHOULD define a framework for cryptographic algorithms and key management [RFC6841]. This may be influenced by frequency of updates, size of the zone, and policies. UAS specific information, such as physical characteristics, MAY also be stored in DNS but is out of scope for this document. Lookups of the above RRTypes are performed with the standard DNS methodology using the nibble reversed DET as the query name affixed to the ip6.arpa domain apex and asking for the specific RRType. The HHIT RRType provides the public key for signature verification and URIs via the certificate. The BRID RRType provides static Broadcast RID information such as the Broadcast Endorsements sent following [RFC9575]. 5. Resource Records 5.1. HHIT Resource Record The HHIT Resource Record is a metadata record for various bits of HHIT specific information that isn't available in the pre-existing HIP RRType. It does not replace the HIP RRType. The primary advantage of this RRType over the existing RRType is the inclusion a certificate containing an entity's public key signed by the registrar, or other trust anchor, to confirm registration. The data MUST be encoded in CBOR [RFC8949] bytes. The CDDL [RFC8610] of the data is provided in Figure 4. 5.1.1. Text Representation The data is represented in base64 [RFC4648] and may be divided into any number of white-space-separated substrings, down to single base64 digits, which are concatenated to obtain the full object. These substrings can span lines using the standard parenthesis. Note that the data has internal subfields, but these do not appear in the master file representation only a single logical base64 string will appear. Wiethuechter & Reid Expires 4 September 2025 [Page 9] Internet-Draft DET in DNS March 2025 5.1.1.1. Presentation Representation The data MAY, for display purposes only, be represented using the Extended Diagnostic Notation as defined in Appendix G of [RFC8610]. 5.1.2. Field Descriptions hhit-rr = [ hhit-entity-type: uint, abbreviation: tstr .size(15), registration-cert: bstr ] Figure 4: HHIT Wire Format CDDL HHIT Entity Type: This field is a number with values defined in Section 6.2.2. It is envisioned that there may be many types of HHITs in use. In some cases, it may be helpful to understand the HHITs role in the ecosystem like described in [drip-dki]. This field provides such context. This field MAY provide a signal of additional information and/or different handling of the data beyond what is defined in this document. HID Abbreviation: This field is a string meant to provide an abbreviation to the HID structure for display devices. The convention for such abbreviations is a matter of local policy. Absent of such a policy, this field MUST be filled with the four chracter hexadecimal representations of the RAA and HDA (in that order) with a seperator character such as a space. For example a DET with an RAA value of 10 and HDA value of 20 would be abbreviated as: 000A 0014. Canonical Registration Certificate: This field is reserved for any certificate to endorse registration that contains the DET. It MUST be encoded as X.509 DER. This certificate MAY be self-signed when the entity is acting as a root of trust (i.e., an apex). Such self-signed behavior is defined by policy, such as in [drip-dki], and is out of scope for this document. 5.2. UAS Broadcast RID Resource Record The UAS Broadcast RID Resource Record type (BRID) is a format to hold public information typically sent of the UAS Broadcast RID that is static. It can act as a data source if information is not received over Broadcast RID or for cross validation. The primary function for DRIP is the inclusion of one or more Broadcast Endorsements as defined in [RFC9575] in the auth field. These Endorsements are generated by the registrar upon successful registration and broadcast Wiethuechter & Reid Expires 4 September 2025 [Page 10] Internet-Draft DET in DNS March 2025 by the entity. The data MUST be encoded in CBOR [RFC8949] bytes. The CDDL [RFC8610] of the data is provided in Figure 5. 5.2.1. Text Representation The data is represented in base64 [RFC4648] and may be divided into any number of white-space-separated substrings, down to single base64 digits, which are concatenated to obtain the full object. These substrings can span lines using the standard parenthesis. Note that the data has internal subfields, but these do not appear in the master file representation only a single logical base64 string will appear. 5.2.1.1. Presentation Representation The data MAY, for display purposes only, be represented using the Extended Diagnostic Notation as defined in Appendix G of [RFC8610]. All byte strings longer than a length of 20 SHOULD be displayed as base64 when possible. 5.2.2. Field Descriptions Wiethuechter & Reid Expires 4 September 2025 [Page 11] Internet-Draft DET in DNS March 2025 bcast-rr = { uas_type => nibble-field, uas_ids => [+ uas-id-grp], ? auth => [+ auth-grp], ? self_id => self-grp, ? area => area-grp, ? classification => classification-grp, ? operator_id => operator-grp } uas-id-grp = ( id_type: &uas-id-types, uas_id: bstr .size(20) ) auth-grp = ( a_type: &auth-types, a_data: bstr .size(1..362) ) area-grp = [ area_count: 1..255, area_radius: float, # in decameters area_floor: float, # wgs84-hae in meters area_ceiling: float # wgs84-hae in meters ] classification-grp = [ class_type: 0..8, class: nibble-field, category: nibble-field ] self-grp = [ desc_type: 0..255, description: tstr .size(23) ] operator-grp = [ operator_id_type: 0..255, operator_id: bstr .size(20) ] uas-id-types = (none: 0, serial: 1, session_id: 4) auth-types = (none: 0, specific_method: 5) nibble-field = 0..15 uas_type = 0 uas_ids = 1 auth = 2 self_id = 3 area = 4 classification = 5 operator_id = 6 Figure 5: BRID Wire Format CDDL Wiethuechter & Reid Expires 4 September 2025 [Page 12] Internet-Draft DET in DNS March 2025 The field names and their general typing are borrowed from the ASTM [F3411] data dictionary (Table 1 and Table 2). See that document for additional context and background information on aviation application-specific interperation of the field semantics. The excplicitly enumerated values included in the CDDL above are relevant to DRIP for its operation. Other values may be valid but are outside the scope of DRIP operation. Application-specific fields, such as UAS Typeare transported and authenticated by DRIP but are regarded as opaque user data to DRIP. 6. IANA Considerations 6.1. DET Prefix Delegation This document requests that IANA manage delegations in the 3.0.0.1.0.0.2.ip6.arpa domain. Delegations will typically be to sector governing bodies, e.g., for aviation, ICAO. IANA will be responsible for processing requests under the guidance of the Designated Experts. 6.2. IANA DRIP Registry 6.2.1. DRIP RAA Allocations This document requests a new registry for RAA Allocations under the DRIP registry group (https://www.iana.org/assignments/drip/ drip.xhtml) to be managed by IANA. RAA Allocations: a 14-bit value used to represent RAAs. Future additions to this registry are to be made through Expert Review (Section 4.5 of [RFC8126]). The following values/ranges are defined: +===============+===========+======================+===========+ | RAA Value(s) | Status | Allocation | Reference | +===============+===========+======================+===========+ | 0 - 3 | Reserved | N/A | N/A | +---------------+-----------+----------------------+-----------+ | 4 - 3999 | Allocated | ISO 3166-1 Countries | This RFC | +---------------+-----------+----------------------+-----------+ | 4000 - 15359 | Reserved | N/A | N/A | +---------------+-----------+----------------------+-----------+ | 15360 - 16383 | Allocated | Experimental Use | This RFC | +---------------+-----------+----------------------+-----------+ Table 1 Wiethuechter & Reid Expires 4 September 2025 [Page 13] Internet-Draft DET in DNS March 2025 To support DNS delegation in ip6.arpa a single RAA is given 4 delegations by borrowing the upper two bits of HDA space. This enables a clean nibble boundary in DNS to delegate from (i.e., the prefix 2001:3x:xxx0::/44). These HDAs (0, 4096, 8192 and 12288) are reserved for the RAA. The mapping between ISO 3166-1 Numeric Numbers and RAAs can be found as a CSV file on GitHub (https://github.com/ietf-wg-drip/draft-ietf- drip-registries/blob/main/iso3166-raa.csv). Each Nation is assigned four RAAs that are left to the national authority for their purpose. For RAAs under this range, a shorter prefix of 2001:3x:xx00::/40 MAY be delegated to each CAA, which covers all 4 RAAs (and reserved HDAs) assigned to them. 6.2.1.1. Expert Guidance A request for a value and/or range is judged on the specific application of its use (i.e. like the ISO 3166 range for UAS). Common applications should reuse exsiting allocated space if possible before allocation of a new value/range. Single point allocations are allowed to individual entities but it is recommended that allocations are made in groupings of 4 to maintain a cleaner nibble boundry. 6.2.1.2. Registration Form * Allocation Title * Contact Information: contact point such as email or person operating allocation * Reference: public document reference for allocation, containing required information to register for HDAs under it 6.2.2. HHIT Entity Type This document requests a new registry for HHIT Entity Type under the DRIP registry group (https://www.iana.org/assignments/drip/ drip.xhtml). HHIT Entity Type: numeric, field of the HHIT RRType to encode the HHIT Entity Type. Future additions to this registry are to be made through Expert Review (Section 4.5 of [RFC8126]). The following values are defined by this document: Wiethuechter & Reid Expires 4 September 2025 [Page 14] Internet-Draft DET in DNS March 2025 +=========+===========================================+===========+ | Value | HHIT Type | Reference | +=========+===========================================+===========+ | 0 | Not Defined | This RFC | +---------+-------------------------------------------+-----------+ | 1 | DRIP Identity Management Entity (DIME) | This RFC | +---------+-------------------------------------------+-----------+ | 2 - 4 | Reserved | This RFC | +---------+-------------------------------------------+-----------+ | 5 | Apex | This RFC | +---------+-------------------------------------------+-----------+ | 6 - 8 | Reserved | This RFC | +---------+-------------------------------------------+-----------+ | 9 | Registered Assigning Authority (RAA) | This RFC | +---------+-------------------------------------------+-----------+ | 10 - 12 | Reserved | This RFC | +---------+-------------------------------------------+-----------+ | 13 | HHIT Domain Authority (HDA) | This RFC | +---------+-------------------------------------------+-----------+ | 14 - 15 | Reserved | This RFC | +---------+-------------------------------------------+-----------+ | 16 | Uncrewed Aircraft (UA) | This RFC | +---------+-------------------------------------------+-----------+ | 17 | Ground Control Station (GCS) | This RFC | +---------+-------------------------------------------+-----------+ | 18 | Uncrewed Aircraft System (UAS) | This RFC | +---------+-------------------------------------------+-----------+ | 19 | Remote Identification (RID) Module | This RFC | +---------+-------------------------------------------+-----------+ | 20 | Pilot | This RFC | +---------+-------------------------------------------+-----------+ | 21 | Operator | This RFC | +---------+-------------------------------------------+-----------+ | 22 | Discovery & Synchronization Service (DSS) | This RFC | +---------+-------------------------------------------+-----------+ | 23 | UAS Service Supplier (USS) | This RFC | +---------+-------------------------------------------+-----------+ | 24 | Network RID Service Provider (SP) | This RFC | +---------+-------------------------------------------+-----------+ | 25 | Network RID Display Provider (DP) | This RFC | +---------+-------------------------------------------+-----------+ | 26 | Supplemental Data Service Provider (SDSP) | This RFC | +---------+-------------------------------------------+-----------+ Table 2 The remaining values (27 to 18446744073709551615) are left unallocated. Wiethuechter & Reid Expires 4 September 2025 [Page 15] Internet-Draft DET in DNS March 2025 6.2.2.1. Expert Guidance The value space of HHIT Entity Types is rather large, but care should still be given to conflicting or confusing allocations. Justification should be provided if there is an existing allocation that could be used. Future additions to this registry MUST NOT be allowed if they can be covered under an existing registration. 6.2.2.2. Registration Template For registration the following template is to be used: * HHIT Type: title to be used for the requested value * Reference: public reference document allocating the value 7. Security Considerations 7.1. DNS Operational Considerations The Registrar and Registry are commonly used concepts in the DNS. These components interface the DIME into the DNS hierarchy and thus operation SHOULD follow best common practices, specifically in security (such as running DNSSEC) as appropriate. The following RFC provide suitable guidance: [RFC7720], [RFC4033], [RFC4034], [RFC4035], [RFC5155], [RFC8945], [RFC2182], [RFC4786], [RFC3007]. If DNSSEC is used, a DNSSEC Practice Statement SHOULD be developed and published. It SHOULD explain how DNSSEC has been deployed and what security measures are in place. [RFC6841] documents a Framework for DNSSEC Policies and DNSSEC Practice Statements. The interfaces and protocol specifications for registry-registrar interactions are intentionally not specified in this document. These will depend on nationally defined policy and prevailing local circumstances. It is expected registry-registrar activity will use the Extensible Provisioning Protocol (EPP) [STD69]. The registry SHOULD provide a lookup service such as WHOIS [RFC3912] or RDAP [STD95] to provide public information about registered domain names. Decisions about DNS or registry best practices and other operational matters SHOULD be made by the CAA, ideally in consultation with local stakeholders. This document RECOMMENDS that DNSSEC SHOULD be used by both Apex (to control RAA levels) and RAA (to control HDA level) zones. Wiethuechter & Reid Expires 4 September 2025 [Page 16] Internet-Draft DET in DNS March 2025 7.2. Public Key Exposure DETs are built upon asymmetric keys. As such the public key must be revealed to enable clients to perform signature verifications. [RFC9374] security considerations cover various attacks on such keys. While unlikely the forging of a corresponding private key is possible if given enough time (and computational power). As such it is RECOMMENDED that the public key for any DET not be exposed in DNS (under any RRType) unless and until it is required for use in verification by other parties. Optimally this requires the UAS somehow signal the DIME that a flight using a Specific Session ID will soon be underway or complete. It may also be facilitated under UTM if the USS (which may or may not be a DIME) signals when a given operation using a Session ID goes active. 8. Acknowledgements Thanks to Stuart Card (AX Enterprize, LLC) and Bob Moskowitz (HTT Consulting, LLC) for their early work on the DRIP registries concept. Their early contributions laid the foundations for the content and processes of this architecture and document. 9. References 9.1. Normative References [F3411] ASTM International, "Standard Specification for Remote ID and Tracking", ASTM F3411-22A, DOI 10.1520/F3411-22A, July 2022, . [ISO3166-1] International Standards Organization (ISO), "Codes for the representation of names of countries and their subdivisions", ISO 3166-1:2020, August 2020, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . Wiethuechter & Reid Expires 4 September 2025 [Page 17] Internet-Draft DET in DNS March 2025 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [RFC9374] Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov, "DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID)", RFC 9374, DOI 10.17487/RFC9374, March 2023, . 9.2. Informative References [drip-dki] Moskowitz, R. and S. W. Card, "The DRIP DET public Key Infrastructure", Work in Progress, Internet-Draft, draft- ietf-drip-dki-03, 15 November 2024, . [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection and Operation of Secondary DNS Servers", BCP 16, RFC 2182, DOI 10.17487/RFC2182, July 1997, . [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, . [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, DOI 10.17487/RFC3912, September 2004, . [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, . [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, . Wiethuechter & Reid Expires 4 September 2025 [Page 18] Internet-Draft DET in DNS March 2025 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, . [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, December 2006, . [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, . [RFC6841] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A Framework for DNSSEC Policies and DNSSEC Practice Statements", RFC 6841, DOI 10.17487/RFC6841, January 2013, . [RFC7720] Blanchet, M. and L. Liman, "DNS Root Name Service Protocol and Deployment Requirements", BCP 40, RFC 7720, DOI 10.17487/RFC7720, December 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, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . [RFC8945] Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D., Gudmundsson, O., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", STD 93, RFC 8945, DOI 10.17487/RFC8945, November 2020, . [RFC9153] Card, S., Ed., Wiethuechter, A., Moskowitz, R., and A. Gurtov, "Drone Remote Identification Protocol (DRIP) Requirements and Terminology", RFC 9153, DOI 10.17487/RFC9153, February 2022, . Wiethuechter & Reid Expires 4 September 2025 [Page 19] Internet-Draft DET in DNS March 2025 [RFC9434] Card, S., Wiethuechter, A., Moskowitz, R., Zhao, S., Ed., and A. Gurtov, "Drone Remote Identification Protocol (DRIP) Architecture", RFC 9434, DOI 10.17487/RFC9434, July 2023, . [RFC9575] Wiethuechter, A., Ed., Card, S., and R. Moskowitz, "DRIP Entity Tag (DET) Authentication Formats and Protocols for Broadcast Remote Identification (RID)", RFC 9575, DOI 10.17487/RFC9575, June 2024, . [STD13] Internet Standard 13, . At the time of writing, this STD comprises the following: Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [STD69] Internet Standard 69, . At the time of writing, this STD comprises the following: Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, . Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", STD 69, RFC 5731, DOI 10.17487/RFC5731, August 2009, . Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732, August 2009, . Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, August 2009, . Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Transport over TCP", STD 69, RFC 5734, DOI 10.17487/RFC5734, August 2009, . Wiethuechter & Reid Expires 4 September 2025 [Page 20] Internet-Draft DET in DNS March 2025 [STD95] Internet Standard 95, . At the time of writing, this STD comprises the following: 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, . Hollenbeck, S. and N. Kong, "Security Services for the Registration Data Access Protocol (RDAP)", STD 95, RFC 7481, DOI 10.17487/RFC7481, March 2015, . Hollenbeck, S. and A. Newton, "Registration Data Access Protocol (RDAP) Query Format", STD 95, RFC 9082, DOI 10.17487/RFC9082, June 2021, . Hollenbeck, S. and A. Newton, "JSON Responses for the Registration Data Access Protocol (RDAP)", STD 95, RFC 9083, DOI 10.17487/RFC9083, June 2021, . Blanchet, M., "Finding the Authoritative Registration Data Access Protocol (RDAP) Service", STD 95, RFC 9224, DOI 10.17487/RFC9224, March 2022, . Authors' Addresses Adam Wiethuechter (editor) AX Enterprize, LLC 4947 Commercial Drive Yorkville, NY 13495 United States of America Email: adam.wiethuechter@axenterprize.com Jim Reid RTFM llp St Andrews House 382 Hillington Road, Glasgow Scotland G51 4BL United Kingdom Email: jim@rfc1035.com Wiethuechter & Reid Expires 4 September 2025 [Page 21]