AX Enterprize, LLC

4947 Commercial Drive Yorkville NY 13495 USA adam.wiethuechter@axenterprize.com

RTFM llp

St Andrews House 382 Hillington Road, Glasgow Scotland G51 4BL UK jim@rfc1035.com

Internet drip Working Group Internet-Draft 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.

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 4 of ). When a DRIP Entity Tag (DET) 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 we assume the DIME is a function of UAS Service Suppliers (USS) (Appendix A.2 of ) but a DIME can be independent or handled by another entity as well.

General Concept DETs embedded a hierarchy scheme which is mapped onto DNS. DIME's 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 Domain Name System (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 for Broadcast RID. Endorsements and certificates are used to endorse the claim of being part of the hierarchy. Aspects of Private Information Registries to store and protect, through AAA mechanisms, Personally Identifiable Information (PII) are not described in this document.

Use of Existing DNS Models DRIP relies on the DNS and as such roughly follows the registrant-registrar-registry model. In DRIP, 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 or RDAP 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 are 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. It is not necessary, and in some case may not be desirable, for DRIP registrations to strictly follow this registrant-registrar-registry model. Prevailing circumstances and/or local policy may mean some combination of these roles could be combined. A DRIP registry might be operated by the CAA. Or it could be outsourced to a DNS registry provider. 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. They are are out of scope for this document. The specifics for the UAS RID use case are detailed in the rest of document.

Scope The scope of this document is limited to the 2001:30::/28 IPv6 prefix and its associated reverse domain in DNS for DETs being used in UAS RID for participating parties (UA, Observer devices, DIMEs, etc.). 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.

Terminology

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 when, and only when, they appear in all capitals, as shown here.

Additional Definitions This document makes use of the terms (PII, USS, etc.) defined in . Other terms (DIME, Endorsement, etc.) are from , while others (RAA, HDA, etc.) are from .

DET Hierarchy in DNS defines the Hierarchical Host Identity Tag (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. It's format is in and further information is in .

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. RAAs) "borrows" the upper two bits of their respective HDA space for DNS delegation. As such the IPv6 prefix of RAAs are 2001:3x:xxx::/44 and HDAs are 2001:3x:xxxx:xx::/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. Preallocations have been made based on the ISO 3166-1 Numeric Nation Code . This is to support the initial use case of DETs in UAS RID on an international level. See 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. 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.

Public Information Registry Per all information classified, by all parties involved, as public is stored in the DNS, specifically Authoritative Name Servers, to satisfy REG-1 from . 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, ) and another for UAS Broadcast RID information (BRID, ). The former RRType is particularly important as it contains a URI (as part of the certificate) that point to Private Information resources. DETs, being IPv6 addresses, are to be under ip6.arpa (nibble reversed per convention) with at minimum 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 . 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 . 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. This specification information is currently drafted in . An example, from Apex to client, of the DNS zones in available in . 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 .

Resource Records

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 is encoded as a CBOR array.

Wire Format The wire format for the HHIT RRType MUST be encoded in CBOR. The CDDL of the RRType is provided in .

HHIT Wire Format CDDL

Presentation Format The presentation format of the HHIT RRType MUST be in Extended Diagnostic Notation as defined in Appendix G of . provides an example of a HHIT RRType in this form. It is RECOMMENDED to have all byte strings, except for IPv6 addresses, be displayed as base64.

HHIT Presentation Format

Field Descriptions

HHIT Entity Type:

This field is two octets with values defined in . 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 . This field provides such context.

HID Abbreviation:

This field is meant to provide an abbreviation to the HID structure for display devices. The specific contents of this field are not defined here.

Canonical Registration Certificate:

This field is reserved for any certificate to endorse registration that contains the DET. It is in either encoded as X.509 DER or C.509.

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.

Wire Format The wire format for the BRID RRType MUST be encoded in CBOR. The CDDL of the RRType is provided in .

BRID Wire Format CDDL

Presentation Format The presentation format of the BRID RRType MUST be in Extended Diagnostic Notation as defined in Appendix G of . provides an example of a BRID RRType in this form. All byte strings longer than 20 SHOULD be displayed as base64 when possible.

BRID Presentation Format

Field Descriptions The field names and their general typing are borrowed from the ASTM data dictionary. See that document for additional information on fields semantics and units.

IANA Considerations

DRIP Prefix Delegation This document requests that the IANA delegate the 3.0.0.1.0.0.2.ip6.arpa domain following instructions to be provided by the IAB. Names within this zone are to be further delegated to the appropriated RAA's described by this document.

IANA DRIP Registry

DRIP RAA Allocations This document requests a new registry for RAA Allocations under the DRIP registry group 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 ). 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 - 16375	Reserved	N/A	N/A
16376 - 16383	Allocated	DRIP WG (Experimental Use)	This RFC

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. 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. Requests in the DRIP WG allocation block MUST be forwarded to the contact point in the DRIP WG to evaluate the request and MUST contain a desired/proposed length of time for the allocation. Allocations in the block are not permanent and have a limited time the delegation is to be supported (max of 12 months). The length of the time proposed is evaluated on a case-by-case basis by the DRIP WG and can result in negotiations for adjustment.

HHIT Entity Type This document requests a new registry for HHIT Entity Type under the DRIP registry group.

HHIT Entity Type:

numeric, 16-bit, 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 ). The following values are defined:

Value	Type	Reference
0	Not Defined	This RFC
1	DRIP Identity Management Entity (DIME)	This RFC
2	DIME: Authentication CA
3	DIME: Issuing CA
4	Reserved	This RFC
5	Apex	This RFC
6	Apex: Authentication CA
7	Apex: Issuing CA
8	Reserved	This RFC
9	Registered Assigning Authority (RAA)	This RFC
10	RAA: Authentication CA
11	RAA: Issuing CA
12	Reserved	This RFC
13	HHIT Domain Authority (HDA)	This RFC
14	HDA: Authentication CA
15	HDA: Issuing CA
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
27 - 65535	Reserved	N/A

Future additions to this registry MUST NOT be allowed if they can be covered under an existing registration.

Security Considerations

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: , , , , , , , , . If DNSSEC is used, a DNSSEC Practice Statement (DPS) SHOULD be developed and published. It SHOULD explain how DNSSEC has been deployed and what security measures are in place. 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) . The registry SHOULD provide a lookup service such as WHOIS or RDAP 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.

Public Key Exposure DETs are built upon asymmetric keys. As such the public key must be revealed to enable clients to perform signature verifications. 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) until it is required. 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.

Contributors 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. Bob Moskowitz is also instrumental in the PKIX work defined in this document with his parallel work in ICAO.

References Normative References This document defines terminology and requirements for solutions produced by the Drone Remote Identification Protocol (DRIP) Working Group. These solutions will support Unmanned Aircraft System Remote Identification and tracking (UAS RID) for security, safety, and other purposes (e.g., initiation of identity-based network sessions supporting UAS applications). DRIP will facilitate use of existing Internet resources to support RID and to enable enhanced related services, and it will enable online and offline verification that RID information is trustworthy. This document describes the use of Hierarchical Host Identity Tags (HHITs) as self-asserting IPv6 addresses, which makes them trustable identifiers for use in Unmanned Aircraft System Remote Identification (UAS RID) and tracking. Within the context of RID, HHITs will be called DRIP Entity Tags (DETs). HHITs provide claims to the included explicit hierarchy that provides registry (via, for example, DNS, RDAP) discovery for third-party identifier endorsement. This document updates RFCs 7401 and 7343. This document describes an architecture for protocols and services to support Unmanned Aircraft System Remote Identification and tracking (UAS RID), plus UAS-RID-related communications. This architecture adheres to the requirements listed in the Drone Remote Identification Protocol (DRIP) Requirements document (RFC 9153). In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References HTT Consulting AX Enterprize, LLC The DRIP Entity Tag (DET) public Key Infrastructure (DKI) is a specific variant of classic Public Key Infrastructures (PKI) where the organization is around the DET, in place of X.520 Distinguished Names. Further, the DKI uses DRIP Endorsements in place of X.509 certificates for establishing trust within the DKI. There are two X.509 profiles for shadow PKI behind the DKI, with many of their X.509 fields mirroring content in the DRIP Endorsements. This PKI can at times be used where X.509 is expected and non- constrained communication links are available that can handle their larger size. C509 (CBOR) encoding of all X.509 certificates are also provided as an alternative for where there are gains in reduced object size. AX Enterprize, LLC This document describes a way Uncrewed Aerial System (UAS) Serial Numbers are placed into and retrieved from the Domain Name System (DNS). This is to directly support DRIP-based Serial Numbers. This document describes an application-layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 4930. [STANDARDS-TRACK] This document presents a framework to assist writers of DNS Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements, such as domain managers and zone operators on both the top level and secondary level, who are managing and operating a DNS zone with Security Extensions implemented. In particular, the framework provides a comprehensive list of topics that should be considered for inclusion into a DNSSEC Policy definition and Practice Statement. This document is not an Internet Standards Track specification; it is published for informational purposes. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using "RESTful" web access patterns. These uniform patterns define the query syntax for the Registration Data Access Protocol (RDAP). This document obsoletes RFC 7482. The Drone Remote Identification Protocol (DRIP), plus trust policies and periodic access to registries, augments Unmanned Aircraft System (UAS) Remote Identification (RID), enabling local real-time assessment of trustworthiness of received RID messages and observed UAS, even by Observers lacking Internet access. This document defines DRIP message types and formats to be sent in Broadcast RID Authentication Messages to verify that attached and recently detached messages were signed by the registered owner of the DRIP Entity Tag (DET) claimed. The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record (RR) for authenticated denial of existence. This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence. However, it also provides measures against zone enumeration and permits gradual expansion of delegation-centric zones. [STANDARDS-TRACK] This document describes a protocol for transaction-level authentication using shared secrets and one-way hashing. It can be used to authenticate dynamic updates to a DNS zone as coming from an approved client or to authenticate responses as coming from an approved name server. No recommendation is made here for distributing the shared secrets; it is expected that a network administrator will statically configure name servers and clients using some out-of-band mechanism. This document obsoletes RFCs 2845 and 4635. This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] This document proposes a method for performing secure Domain Name System (DNS) dynamic updates. [STANDARDS-TRACK] This document discusses the selection of secondary servers for DNS zones.The number of servers appropriate for a zone is also discussed, and some general secondary server maintenance issues considered. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. The DNS root name service is a critical part of the Internet architecture. The protocol and deployment requirements for the DNS root name service are defined in this document. Operational requirements are out of scope. This document updates the specification of the WHOIS protocol, thereby obsoleting RFC 954. The update is intended to remove the material from RFC 954 that does not have to do with the on-the-wire protocol, and is no longer applicable in today's Internet. This document does not attempt to change or update the protocol per se, or document other uses of the protocol that have come into existence since the publication of RFC 954. [STANDARDS-TRACK] As the Internet has grown, and as systems and networked services within enterprises have become more pervasive, many services with high availability requirements have emerged. These requirements have increased the demands on the reliability of the infrastructure on which those services rely. Various techniques have been employed to increase the availability of services deployed on the Internet. This document presents commentary and recommendations for distribution of services using anycast. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. ASTM International International Standards Organization (ISO)

DET DNS Zone Examples This appendix is informative, showing an example of the DNS zone setup/content from Apex to a client. For this example the following DETs are shown:

• Apex = 2001:0030:0000:0005:fad8:7fea:e0f6:90ad
• RAA = 2001:003f:fe00:0005:618a:cd8e:76d3:b790
• HDA = 2001:003f:fe00:0105:ad79:a278:1c10:5443
• Client = 2001:003f:fe00:0105:6a26:21d4:ef57:2ef5

The RAA allocation of 16376 and an HDA of 1 have been selected.

Apex Zones

RAA Zones

HDA Zone