AX Enterprize, LLC

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

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

Introduction The lookup of Serial Number for Uncrewed Aerial Systems (UAS) is a major concern. On one hand if a pilot plans to use DRIP Entity Tags (DETs, ) or other Session IDs the Serial Number is considered, by many Civil Aviation Authorities (CAAs), PII. However when this is not the case, the Serial Number can be used in the clear as the UAS ID, and generally will be by default. It may be helpful for receiving devices or other devices presented with a UAS Serial Number to look up additional information of the aircraft, if the manufacturer wishes to provide it publicly. This information could be general specifications, such as number or props or color. DRIP directly uses the Serial Number format as defined in to encode a DET. A such a way to lookup a Serial Number to see if it corresponds to a DET is important and something that does not currently address. already adds support for such DRIP Serial Numbers with the creation of the Manufacturer Code Authority (MCA) and Manufacturer Unmanned Aircraft Authority (MAA) roles.

Supported Scenarios

1. UA using manufacturer generated Serial Number for UAS ID. No additional information provided.
2. UA using manufacturer generated Serial Number for UAS ID. Manufacturer using a DIME. Manufacturer MUST provided pointer to additional information via DNS (even if null).
3. UA using manufacturer generated Serial Number which is mapped to a DET by manufacturer for UAS ID. UA using manufacturer generated DET for Authentication. Manufacturer using a DIME. DIME MUST place public DET information into DNS (i.e. HI). DIME MUST provide mapping of Serial Number to DET in DNS. Manufacturer MUST provide pointer to additional information via DNS (even if null).
4. UA using manufacturer generated DRIP enhanced Serial Number for UAS ID. UA using manufacturer generated DET for Authentication. Manufacturer using a DIME. DIME MUST place public information into DNS (i.e. HI) - either directly or as a mapping to a DET. DIME MUST provide pointer to additional information via DNS (even if null).
5. UA using manufacturer generated Serial Number for UAS ID. UA using user generated DET for Authentication. User uses DIME with capability to publicly map Serial Number to a DET (via a USS). DIME MUST place public DET information into DNS (i.e. HI). DIME MUST provide mapping of Serial Number to DET in DNS. DIME MUST provide pointer to additional information via DNS (even if null).

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 .

Serial Number Registration There are four ways a Serial Number can be registered and used by DRIP:

1. As a clear-text string with additional information ()
2. As a clear-text string mapped to a DET "post" generation by the manufacturer (for use in authentication) and additional information ()
3. As a clear-text string mapped to a DET "post" generation by the user (via an HDA) (for use in authentication) and additional information ()
4. As an encoding of an HI and associated DET by the manufacturer (for use in authentication) with additional information ()

• Note: additional information here refers to any subset of keys defined in .

Serial Method 1 This is where a UA is provisioned with a Serial Number by the manufacturer. The Serial Number is just text string, defined by . The manufacturer runs an Name Server delegated under the Serial Number apex and points to information using a DET RR (filling in only the Serial Number and URI fields).

Example DIME:MAA with Serial Number Registration o | * * +----o----+ (d) | | * * | | | * * | (c) | DIA/RDDS | * * v | | * * +----o--------+ | | * * | Registry/NS | | | * * +-------------+ | | * * +----------+ * * * ***************************************** (a) Serial Number, UA Information (b) Success Code (c) DET RR (d) UA Information ]]>

Serial Method 2 This is where a UAS is provisioned with a Serial Number and DET by the manufacturer enabling their devices to use and provide additional information. A public mapping of the Serial Number to DET and all public artifacts MUST be provided by the manufacturer. The manufacturer MUST use an MAA for this task. The device MAY allow the DET to be regenerated dynamically with the MAA.

Example DIME:MAA with Serial Number + DET Registration o | * * +----o----+ (d) | | * * | | | * * | (c) | DIA/RDDS | * * v | | * * +----o--------+ | | * * | Registry/NS | | | * * +-------------+ | | * * +----------+ * * * ***************************************** (a) Serial Number, UA Information, Self-Endorsement: UA (b) Success Code, Broadcast Endorsement: MAA on UA (c) DET RR, PTR RR (d) UA Information ]]>

Serial Method 3 This is where a UAS has a Serial Number (from the manufacturer) and the user (via a DIME) has a mechanism to generate and map a DET to the Serial Number after production. This can provide dynamic signing keys for DRIP Authentication Messages via for UAS that MUST fly only using Serial Numbers. Registration SHOULD be allowed to any relevant DIME that supports it. A public mapping of the DET to the Serial Number SHOULD be provided.

Example DIME with Serial Number + DET Registration o | * * +----o----+ (d) | | * * | | | * * | (c) | DIA/RDDS | * * v | | * * +----o--------+ | | * * | Registry/NS | | | * * +-------------+ | | * * +----------+ * * * ***************************************** (a) Serial Number, UA Information, Self-Endorsement: UA (b) Success Code, Broadcast Endorsement: DIME on UA (c) DET RR (d) UA Information ]]>

Serial Method 4 This is where a UAS manufacturer chooses to use the Serial Number scheme defined in to create Serial Numbers, their associated DETs for and provide additional information. This document RECOMMENDS that the manufacturer "locks" the device from changing its authentication method so identifiers in both the Basic ID Message and Authentication Message do not de-sync. The manufacturer MUST use an MAA for this task, with the mapping between their Manufacturer Code and the upper portion of the DET publicly available.

Example DIME:MAA with DRIP Serial Number Registration o | * * +----o----+ (d) | | * * | | | * * | (c) | DIA/RDDS | * * v | | * * +----o--------+ | | * * | Registry/NS | | | * * +-------------+ | | * * +----------+ * * * ***************************************** (a) Serial Number, UA Information, Self-Endorsement: UA (b) Success Code, Broadcast Endorsement: MAA on UA (c) DET RR (d) UA Information ]]>

Serial Numbers in DNS

• Author Note: There MUST be an entry point in DNS for the lookup of UAS Serial Numbers. This section is very much a shot in the dark on how this looks and functions.

This document specifies the creation and delegation to an apex organization (TBD) of the subdomain uas.arpa. To enable lookup of Serial Numbers a subdomains of sn.uas.arpa is maintained. All entries under sn.uas.arpa are to follow the convention found in . This is to enable a singular lookup point for Serial Numbers for UAS. Note that other subdomains under uas.arpa can be made to support other identifiers in UAS. The creation and use of other such other subdomains are out of scope for this document. The further use and creation of items under uas.arpa is the authority of the apex organization (which has been delegated control). DETs MUST not have a subdomain in uas.arpa (such as det.uas.arpa) as they fit within the predefined ip6.arpa as they are IPv6 addresses as defined in .

IANA Considerations TODO

Security Considerations TODO

References Normative References AX Enterprize, LLC RTFM llp This document describes the high level architecture for the registration and discovery of DRIP Entity Tags (DETs) using DNS. Discovery of DETs and their artifacts are through DRIP specific DNS structures and standard DNS methods. A general overview of the interfaces required between involved components is described in this document with future supporting documents giving technical specifications. 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 AX Enterprize, LLC AX Enterprize, LLC HTT Consulting The Drone Remote Identification Protocol (DRIP), plus trust policies and periodic access to registries, augments Unmanned Aircraft System Remote Identification (UAS RID), enabling local real time assessment of trustworthiness of received RID messages and observed UAS, even by Observers then lacking Internet access. This document defines DRIP message types and formats to be sent in Broadcast RID Authentication Messages to verify that attached and recent detached messages were signed by the registered owner of the DRIP Entity Tag (DET) claimed.

UAS Serial Number FQDN

• {id}.{length}.{manufacturer-code}.{apex}.

DNS Examples

Serial Method 1

Serial Method 2

Serial Method 3

Serial Method 4