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. Manufacturers that wish to participate in DRIP should not only support DRIP as a Session ID type for their aircraft but could also generate a DET then encode it as a Serial Number (Section 4.2 of ). This would allow aircraft under CAA mandates to fly only ID Type 1 (Serial Number) to still use DRIP and most of its benefits. Even if DRIP is not supported for Serial Numbers by a Manufacturer it is hoped that they would still run a DIME to store their Serial Numbers and allow look ups for generic model information. This look up could be especially helpful in UTM for Situational Awareness when an aircraft flying with a Serial Number is detected and allow for a general aircraft profile to be displayed. 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. This document adds support for UAS Serial Numbers in DNS. It creates two new roles: Manufacturer Code Authority (MCA) for RAAs and the Manufacturer Unmanned Aircraft Authority (MAA) role for HDAs. MCA is part of a new allocated range in RAA values as the conversion of Manufacturer Codes is across the entire HID.

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 .

DIME Roles

Manufacturer Code Authority (MCA) An RAA-level DIME that hands out HDA values to participating Manufacturer's that hold an Manufacturer Code used in that is issued by ICAO. To manage the large Manufacturer Code space (34 character set; 4 characters; 1,336,336 possible codes) a range of RAA values are set aside for the use case. These are the RAA values of 4000 (0x0FA0) up to 4095 (0x0FFF). This allows a single HDA for each Manufacturer Code. See for the HDA allocation of Manufacturer Codes under these RAAs.

• Note: the upper RAAs in the range (4083 to 4095) are not used but are left reserved in this space for future action if required.

Manufacturer Unmanned Aircraft Authority (MAA) An HDA-level DIME run by a manufacturer of UAS systems that participate in Remote ID. Stores UAS Serial Numbers under a specific Manufacturer Code (assigned to the manufacturer by ICAO). A DET can be encoded into a Serial Number (see , Section 4.2) and this DIME MUST hold a mapping from the Serial Number to the DET and its artifacts.

Manufacturer Code Allocation The first 4 characters of every UAS Serial Number represents the manufacturer and is known as the Manufacturer Code. The allocation of a specific RAA (out of MCA space) and HDA (i.e. HID) for a Manufacturer Code uses the following derivation: A character in a UAS Serial Number "shall include any combination of digits and uppercase letters, except the letters O and I, but may include all digits" . For HID determination, the character space [0-9,A-H,J-N,P-Z] is mapped to [0-34] to convert the 4 place Base34 Manufacturer Code to Base10 (Note this is different than the Base32 process in Section 4.2 of ).

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

IANA DRIP Registry

Aircraft Information Registry This document requests a new registry for aircraft information fields under the DRIP registry group.

Aircraft Information Fields:

list of acceptable keys to be used in UA Information during a UA registration to a DIME. Future additions to this registry are to be made through First Come First Served (Section 4.4 of ). The following values are defined:

Key Name	Type	Description
length	float	length, in millimeters
width	float	width, in millimeters
height	float	height, in millimeters
constructionMaterial	tstr	materials, comma separated if multiple
color	tstr	colors, comma separated if multiple
serial	tstr	ANSI CTA 2063-A Serial Number
manufacturer	tstr	manufacturer name
make	tstr	aircraft make
model	tstr	aircraft model
dryWeight	float	weight of aircraft with no payloads
numRotors	int	Number of rotators
propLength	float	Length of props, in centimeters
numBatteries	int
batteryCapacity	float	in milliampere hours
batteryWeight	float	in kilograms
batteryVoltage	float	in volts
batteryChemistry	tstr
maxTakeOffWeight	float	in kilograms
maxPayloadWeight	float	in kilograms
maxFlightTime	float	in minutes
minOperatingTemp	float	in Celsius
maxOperatingTemp	float	in Celsius
ipRating	tstr	standard IP rating
engineType	tstr
fuelType	tstr
fuelCapacity	float	in liters
previousSerial	tstr	legacy serial number(s)

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 related metadata is performed via 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 (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 recent detached messages were signed by the registered owner of the DRIP Entity Tag (DET) claimed. 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.

UAS Serial Number FQDN

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

UAS Characteristic DNS Resource Record This appendix is informative. This RR format is a WIP and comments are welcome.

Wire Format any, * tstr => any }) ]]> The wire format for the DNS record is presented in CBOR in the form of a semantic tag made up of a CBOR map. Common keys have been defined, matching those found in and other can be added at later dates. The serial and previousSerial keys should not be used to avoid PII leakage. It is recommended that any vendor specific details be placed in the vendor_specific key.

Presentation Format Presentation of the data found in this RR are expected to be handled by UAS domain aware devices. Its format is a WIP.

DNS Examples

Serial Method 1

Serial Method 2

Serial Method 3

Serial Method 4