RFC 9434

Drone Remote Identification Protocol (DRIP) Architecture

📅 published July 2023, from ietf

🛸 RFC 9434: Drone Remote Identification Protocol (DRIP) Architecture 🎀

Bestie, this one is about drones, and it's a whole vibe. ✨ It's an Informational doc from the IETF, published in July 2023 with ISSN 2070-1721. It's not a Standards Track spec, so think of it as the architecture guide for the DRIP work, not a rulebook 📖. The authors are S. Card (AX Enterprize), A. Wiethuechter (AX Enterprize), R. Moskowitz (HTT Consulting), S. Zhao (Intel, the editor 🫶), and A. Gurtov (Linköping University). The title block doesn't list any RFCs it obsoletes or updates, so it's standing on its own 💅.

The RFC number is 9434 and the title is Drone Remote Identification Protocol (DRIP) Architecture 🦋. Here's the front matter, unfiltered:

Internet Engineering Task Force (IETF)                           S. Card
Request for Comments: 9434                               A. Wiethuechter
Category: Informational                                    AX Enterprize
ISSN: 2070-1721                                             R. Moskowitz
                                                          HTT Consulting
                                                            S. Zhao, Ed.
                                                                   Intel
                                                               A. Gurtov
                                                    Linköping University
                                                               July 2023

Abstract ✨

okay so the abstract is the elevator pitch 🛗. This doc describes an architecture for protocols and services that support Unmanned Aircraft System Remote Identification and tracking (UAS RID), plus UAS-RID-related communications 🌸. It's built to meet the requirements in the Drone Remote Identification Protocol (DRIP) Requirements document (RFC 9153) 💖.

Status of This Memo 📜

Not a standards track spec, it's published "for informational purposes" 🧚. It is an IETF product that reflects IETF community consensus, got public review, and was approved by the IESG. Not every IESG-approved doc is a candidate for any level of Internet Standard, so see Section 2 of RFC 7841 for that 🙈. Errata, feedback, and the current status live at https://www.rfc-editor.org/info/rfc9434.

Copyright (c) 2023 IETF Trust and the document authors, all rights reserved 🌈. The doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they were on the publication date, so go read those, they're your rights and restrictions 😭. Code Components pulled from this doc have to include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, per the Revised BSD License 🍓.

Table of Contents 🗺️

1.  Introduction
  1.1.  Overview of UAS RID and Its Standardization
  1.2.  Overview of Types of UAS Remote ID
    1.2.1.  Broadcast RID
    1.2.2.  Network RID
  1.3.  Overview of USS Interoperability
  1.4.  Overview of DRIP Architecture
2.  Terms and Definitions
  2.1.  Additional Abbreviations
  2.2.  Additional Definitions
3.  HHIT as the DRIP Entity Identifier
  3.1.  UAS Remote Identifiers Problem Space
  3.2.  HHIT as a Cryptographic Identifier
  3.3.  HHIT as a Trustworthy DRIP Entity Identifier
  3.4.  HHIT for DRIP Identifier Registration and Lookup
4.  DRIP Identifier Registration and Registries
  4.1.  Public Information Registry
    4.1.1.  Background
    4.1.2.  Public DRIP Identifier Registry
  4.2.  Private Information Registry
    4.2.1.  Background
    4.2.2.  Information Elements
    4.2.3.  Private DRIP Identifier Registry Methods
    4.2.4.  Alternative Private DRIP Registry Methods
5.  DRIP Identifier Trust
6.  Harvesting Broadcast Remote ID Messages for UTM Inclusion
  6.1.  The CS-RID Finder
  6.2.  The CS-RID SDSP
7.  DRIP Contact
8.  IANA Considerations
9.  Security Considerations
  9.1.  Private Key Physical Security
  9.2.  Quantum Resistant Cryptography
  9.3.  Denial-of-Service (DoS) Protection
  9.4.  Spoofing and Replay Protection
  9.5.  Timestamps and Time Sources
10. Privacy and Transparency Considerations
11. References
  11.1.  Normative References
  11.2.  Informative References
Appendix A.  Overview of UAS Traffic Management (UTM)
  A.1.  Operation Concept
  A.2.  UAS Service Supplier (USS)
  A.3.  UTM Use Cases for UAS Operations
Appendix B.  Automatic Dependent Surveillance Broadcast (ADS-B)
Acknowledgments
Authors' Addresses

1. Introduction 🚁

This doc is the architecture for UAS RID protocols and services, plus the UAS-RID-related comms 💜. The architecture takes both current (and proposed) regulations and non-IETF technical standards into account, which is very responsible of them 🫡.

It adheres to the DRIP Requirements document [RFC9153] and shows how all of those requirements can be met, except GEN-7 QoS, which is left for future work 🔥. The requirements doc has the extended intro to the problem space and use cases. This architecture doc also frames the DRIP Entity Tag (DET) [RFC9374] within the architecture 🧚.

1.1. Overview of UAS RID and Its Standardization 🌍

UAS RID is an application that lets UAS be identified by UAS Traffic Management (UTM), UAS Service Suppliers (USS) (Appendix A), and third-party entities like law enforcement 👮‍♀️. Lots of considerations, like safety and security, mean UAS should be remotely identifiable.

Civil Aviation Authorities (CAAs) around the world are mandating UAS RID 🌸. Their rules are performance-based, so they don't spell out techniques. Instead they point to industry-consensus technical standards as acceptable ways to comply 💅.

USA Federal Aviation Administration (FAA)

The FAA published a Notice of Proposed Rule Making [NPRM] in 2019, then a "Final Rule" in 2021 [FAA_RID] 📜. It puts requirements on UAS manufacturers and operators, both commercial and recreational. The rule says Automatic Dependent Surveillance Broadcast (ADS-B) Out and transponders can't be used to satisfy the UAS RID requirements on UAS covered by the rule (see Appendix B) 🙈.

European Union Aviation Safety Agency (EASA)

For the "U-space" concept, a single European airspace safely shared by manned and unmanned aircraft 🛫, EASA published a [Delegated] regulation in 2019 🦋. It puts requirements on UAS manufacturers and third-country operators, including but not limited to UAS RID. The same year, EASA also published a regulation [Implementing] laying out detailed rules and procedures for UAS operations and operating personnel, which got updated in 2021 [Implementing_update]. A Notice of Proposed Amendment [NPA] came out in 2021 to share more about the development of acceptable means of compliance and guidance material for U-space rules 🧚.

American Society for Testing and Materials (ASTM)

ASTM International's Technical Committee F38 (UAS), Subcommittee F38.02 (Aircraft Operations), Work Item WK65041 developed an ASTM standard [F3411-22a] called "Standard Specification for Remote ID and Tracking" 🎀.

ASTM defines one set of UAS RID information and two ways to communicate it: Media Access Control (MAC) layer broadcast and IP layer network 🌈. If a UAS uses both methods, the same information must be provided over both 😭. [F3411-22a] is the technical standard basis of the Means Of Compliance (MOC) specified in [F3586-22]. The FAA accepted [F3586-22] as a MOC for its UAS RID Final Rule [FAA_RID], with some caveats per [MOC-NOA] 💅. Other CAAs are expected to accept the same or other MOCs, based on [F3411-22a], likewise.

3rd Generation Partnership Project (3GPP)

With Release 16, 3GPP finished the UAS RID requirement study [TR-22.825] and proposed a bunch of use cases for mobile networks and the services they could offer based on UAS RID 📶. The Release 17 study [TR-23.755] and specification [TS-23.255] focus on enhanced UAS service requirements and give protocol and application architecture support that applies to both 4G and 5G networks ⭐. The Release 18 study of Further Architecture Enhancement for Uncrewed Aerial Vehicles (UAV) and Urban Air Mobility (UAM) [FS_AEUA] goes further and improves the communication mechanism between UAS and USS/UTM 🚀. And the DET in Section 3 may be used as the 3GPP CAA-level UAS ID for RID purposes 🫶.

1.2. Overview of Types of UAS Remote ID 🪪

This spec introduces two types of UAS Remote IDs, as defined in ASTM [F3411-22a] 🌟.

1.2.1. Broadcast RID 📡

Okay so this is the one with no Internet needed! 🙌 [F3411-22a] defines a set of UAS RID messages for direct, one-way broadcast from the Unmanned Aircraft (UA) over Bluetooth or Wi-Fi 💙. Right now they're defined as MAC layer messages. Internet (or other Wide Area Network) connectivity is only needed for Observers to look up UAS registry info using the directly received UAS ID. Broadcast RID should be functionally usable with no Internet connectivity at all 🍃.

The minimum Broadcast RID data flow is in Figure 1 👇:

                   +------------------------+
                   | Unmanned Aircraft (UA) |
                   +-----------o------------+
                               |
                               | app messages directly over
                               | one-way RF data link (no IP)
                               |
                               v
             +------------------o-------------------+
             | Observer's device (e.g., smartphone) |
             +--------------------------------------+

                 Figure 1: Minimum Broadcast RID Data Flow

Broadcast RID only gives info about UA inside direct Radio Frequency (RF) Line Of Sight (LOS), which is usually similar to Visual LOS (VLOS), with a range up to about 1 km 🔭. Here's the glow-up: that info may be harvested from received broadcasts and made available over the Internet. That lets you watch areas way too big for local direct visual observation or direct RF link-based identification (see Section 6) 👑.

Part 1 of 7 done, bestie! 🌈💖 More parts coming, so stay tuned! 🦋

1.2.2. Network RID ✨

okay bestie, [F3411-22a] uses the same data dictionary as Broadcast RID messages 💅 and lays out a Network Remote Identification (Net-RID) data flow. here's how it goes:

  • the info that gets reported via UAS RID is generated by the UAS 🛸. usually some of it comes from the UA and some from the Ground Control Station (GCS), like their locations derived from the Global Navigation Satellite System (GNSS) 🛰️
  • the UAS (UA or GCS) sends that info via unspecified means to the cognizant Network Remote Identification Service Provider (Net-RID SP), which is typically the USS the UAS is operating under if it's participating in UTM 💖
  • the Net-RID SP publishes, via the Discovery and Synchronization Service (DSS) over the Internet, that it has operations in various 4-D airspace volumes (Section 2.2 of [RFC9153]) 🗺️ it describes the volumes but NOT the operations themselves 🙈
  • an Observer's device, which is expected but not specified to be based on the Web, asks a Network Remote Identification Display Provider (Net-RID DP), typically also a USS, about any operations in a specific 4-D airspace volume 👀
  • using fully specified Web-based methods over the Internet, the Net-RID DP queries all Net-RID SPs that have operations in volumes intersecting the Observer's query, to get details on all of those operations 🕸️
  • the Net-RID DP aggregates the info from all those Net-RID SPs and responds to the Observer's query 🎀

the minimum Net-RID data flow is illustrated in Figure 2:

    +-------------+     ******************
    |     UA      |     *    Internet    *
    +--o-------o--+     *                *
       |       |        *                *     +------------+
       |       '--------*--(+)-----------*-----o            |
       |                *   |            *     |            |
       |       .--------*--(+)-----------*-----o Net-RID SP |
       |       |        *                *     |            |
       |       |        *         .------*-----o            |
       |       |        *         |      *     +------------+
       |       |        *         |      *
       |       |        *         |      *     +------------+
       |       |        *         '------*-----o            |
       |       |        *                *     | Net-RID DP |
       |       |        *         .------*-----o            |
       |       |        *         |      *     +------------+
       |       |        *         |      *
       |       |        *         |      *     +------------+
    +--o-------o--+     *         '------*-----o Observer's |
    |     GCS     |     *                *     | Device     |
    +-------------+     ******************     +------------+

Figure 2: Minimum Net-RID Data Flow

okay so, Command and Control (C2) has to flow from the GCS to the UA via some path 🎮. right now (in the year 2023) that's typically a direct RF link 📡. but with more Beyond Visual Line Of Sight (BVLOS) operations popping off, it's expected to often be a wireless link at either end with the Internet in between 🌐 very main character.

telemetry (at least the UA's position and heading) flows from the UA to the GCS via some path, usually the reverse of the C2 path 🔁. so UAS RID info about both the GCS and the UA can be sent by whichever one has Internet connectivity to the Net-RID SP, which is typically the USS managing the UAS operation 🫶

the Net-RID SP forwards UAS RID info via the Internet to subscribed Net-RID DPs, typically the USS 📨. then the subscribed Net-RID DPs forward RID info via the Internet to subscribed Observer devices 📲. regulations require, and [F3411-22a] describes, the UAS RID data elements that must be transported end to end from the UAS to the subscribed Observer devices 📋

[F3411-22a] prescribes the protocols between the Net-RID SP, Net-RID DP, and DSS. it also prescribes data elements (in JSON) between the Observer and the Net-RID DP 🧾. DRIP could address standardization of secure protocols between the UA and the GCS (over direct wireless and Internet connection), between the UAS and the Net-RID SP, and/or between the Net-RID DP and Observer devices 🔐

Neither link-layer protocols nor the use of links (e.g., the link often existing between the GCS and the UA) for any purpose other than carriage of UAS RID information are in the scope of Network RID [F3411-22a]. 🚫

1.3. Overview of USS Interoperability

okay bestie, with Net-RID there's direct communication between each UAS and its USS 🤝. multiple USSs exchange info with the help of a DSS so that all USSs collectively know about all activities in a 4-D airspace 🌍. here's how an Observer, multiple UAS, and their USSs interact (Figure 3) 👇

                   +------+    +----------+    +------+
                   | UAS1 |    | Observer |    | UAS2 |
                   +---o--+    +-----o----+    +--o---+
                       |             |            |
                 ******|*************|************|******
                 *     |             |            |     *
                 *     |         +---o--+         |     *
                 *     |  .------o USS3 o------.  |     *
                 *     |  |      +--o---+      |  |     *
                 *     |  |         |          |  |     *
                 *   +-o--o-+    +--o--+     +-o--o-+   *
                 *   |      o----o DSS o-----o      |   *
                 *   | USS1 |    +-----+     | USS2 |   *
                 *   |      o----------------o      |   *
                 *   +------+                +------+   *
                 *                                      *
                 *               Internet               *
                 ****************************************

Figure 3: Interactions Between Observers, UAS, and USS

1.4. Overview of DRIP Architecture

ok so Figure 4 shows a global UAS RID usage scenario 🌏. Broadcast RID links aren't drawn, because they reach from any UA to any listening receiver in range and would totally hide the point of the figure 🙈. Figure 4 also shows, as context, some entities and interfaces that are beyond DRIP's scope (as currently chartered in 2023) 🧩. multiple UAS are shown, each with its own UA controlled by its own GCS, possibly using the same or different USS. the UAs can also talk directly to each other (V2V), especially for low-latency, safety-related purposes (DAA) 🚨

  ***************                                        ***************
  *    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 4: Global UAS RID Usage Scenario
Informative note: See [RFC9153] for detailed definitions. 💡

DRIP is meant to leverage existing Internet resources (standard protocols, services, infrastructures, and business models) to meet UAS RID and closely related needs 🌈. DRIP will specify how to apply IETF standards, complementing [F3411-22a] and other external standards, to satisfy UAS RID requirements 💜.

this document outlines the DRIP architecture in the context of the UAS RID architecture 🦋. that includes closing the gaps between the CAAs' concepts of operations and [F3411-22a] as it relates to the use of Internet technologies and UA-direct RF communications. the issues include, but aren't limited to, the following:

  • the design of trustworthy remote identifiers required by GEN-1 (Section 3), especially but not exclusively for use as single-use session IDs,
  • mechanisms to leverage the Domain Name System (DNS) [RFC1034] for registering and publishing public and private information (see Sections 4.1 and 4.2), as required by REG-1 and REG-2,
  • specific authentication methods and message payload formats to enable verification that Broadcast RID messages were sent by the claimed sender (Section 5) and that the sender is in the claimed DRIP Identity Management Entity (DIME) (see Sections 4 and 5), as required by GEN-2,
  • harvesting Broadcast RID messages for UTM inclusion, with the optional DRIP extension of Crowdsourced Remote ID (CS-RID) (Section 6), using the DRIP support for gateways required by GEN-5 [RFC9153],
  • methods for instantly establishing secure communications between an Observer and the pilot of an observed UAS (Section 7), using the DRIP support for dynamic contact required by GEN-4 [RFC9153], and
  • privacy in UAS RID messages (personal data protection) (Section 10).

this document should serve as a main point of entry into the set of IETF documents addressing the basic DRIP requirements 🚪✨

2. Terms and Definitions

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 📖 (read the fine print, bestie 🤓).

to encourage the comprehension needed for DRIP to be adopted by its intended user community, the UAS community's norms are respected here 🫶

this document uses terms defined in [RFC9153] 💅

some of the acronyms have plural forms that stay the same as their singular forms. e.g., "UAS" can expand to "Unmanned Aircraft System" (singular) or "Unmanned Aircraft Systems" (plural), whichever fits the context 🛩️. this usage is consistent with Section 2.2 of [RFC9153] 🎀

2.1. Additional Abbreviations

here are the extra abbreviations, sorted for you 🌸

DET:      DRIP Entity Tag

EdDSA:    Edwards-curve Digital Signature Algorithm

HHIT:     Hierarchical HIT

HI:       Host Identity

HIP:      Host Identity Protocol

HIT:      Host Identity Tag

2.2. Additional Definitions ✨

okay so this bit introduces four words we're gonna be using all over DRIP: "Claim", "Evidence", "Endorsement", and "Certificate" 🎀 heads up though, a DRIP certificate is NOT the same vibe as the security certificates and PKI you know from X.509, so don't mix them up bestie 🙈

  • Claim: a claim is the same thing as a claim in Remote ATtestation procedureS (RATS) [RFC9334] 🧚 it's a piece of asserted info, sometimes written as a name/value pair. You can also think of it as a predicate, like "X is Y", "X has property Y", and most importantly "X owns Y" or "X is owned by Y" 💜
  • Evidence: DRIP borrows the RATS [RFC9334] definition of evidence, which is just a set of claims 🌸
  • Endorsement: this one is inspired by RATS [RFC9334] too. It's a secure (aka signed) statement that vouches for the integrity and veracity of evidence 🔥
  • Certificate: in DRIP, a certificate is an endorsement that's strictly about identity info and gets signed by a third party. That third party should be one with no stake in the endorsement it's signing, so no conflicts of interest, periodt 💅
  • DRIP Identity Management Entity (DIME): a DIME is basically a domain registrar/registry vibes 🦋 it vets Claims and/or Evidence from a registrant and then hands back Endorsements and/or Certificates. It's a high-level entity in the DRIP registration/provisioning process, and it can hold the role of HHIT Domain Authority (HDA), Registered Assigning Authority (RAA), or root of trust (typically the HHIT prefix owner or DNS apex owner) for DETs ✨

3. HHIT as the DRIP Entity Identifier 🦋

this section is all about how DRIP meets the basic requirements for a DRIP entity identifier, while staying inside the external technical standard ASTM [F3411-22a] and the regulatory constraints 🎀 it explains why we use Hierarchical Host Identity Tags (HHITs) [RFC9374] as self-asserting IPv6 addresses. They work as a UAS ID type and, more generally, as trustworthy multipurpose remote identifiers. main character energy for sure 👑

Self-asserting here means that, given the Host Identity (HI), the HHIT Overlay Routable Cryptographic Hash IDentifier (ORCHID) construction (see Section 3.5 of [RFC9374]), and a signature from the DIME on the HHIT and HI, the receiver can verify the HHIT as a trusted UAS ID 🧚 The explicit registration hierarchy inside the HHIT gives you registration discovery (managed by a DIME). That discovery either gets you the HI for a third party that's checking a UAS ID endorsement, or it proves the HHIT and HI were registered uniquely 🫶

3.1. UAS Remote Identifiers Problem Space

a DRIP entity identifier needs to be "Trustworthy" (see DRIP requirements GEN-1, ID-4, and ID-5 in [RFC9153]) 💖 This means that, given enough UAS RID messages, an Observer can figure out that the identifier claimed in them uniquely belongs to the claimant 👀 To meet the DRIP requirements and keep the important security properties, the DRIP identifier should be self-generated by the entity it names (e.g., a UAS) and registered (e.g., with a USS; see DRIP requirements GEN-3 and ID-2) 🔐

but, Broadcast RID, especially its support for Bluetooth 4, puts some seriously harsh constraints on everything 😭 An older revision of the ASTM UAS RID, [F3411-19], allowed a UAS ID of types (1, 2, and 3), each of 20 bytes. [F3411-22a] adds type 4, Specific Session ID, so other Standards Development Organizations (SDOs) can extend ASTM UAS RID. Type 4 uses one byte to index the Specific Session ID subtype, which leaves 19 bytes (see ID-1 of DRIP Requirements [RFC9153]). As described in Section 3 of [RFC9153], ASTM has given Specific Session ID subtype 1 to IETF DRIP 🍓

The maximum ASTM UAS RID Authentication Message payload is 201 bytes each for Authentication Types 1, 2, 3, and 4. [F3411-22a] adds Authentication Type 5 for other SDOs (including the IETF) to extend ASTM UAS RID with Specific Authentication Methods (SAMs). With Type 5, one of the 201 bytes gets eaten up to index the SAM Type, which leaves only 200 bytes for DRIP authentication payloads. Those have to fit one or more DRIP entity identifiers plus the associated authentication data 💀

3.2. HHIT as a Cryptographic Identifier

the only existing types of IP-address-compatible identifiers that are cryptographically derived from the public keys of the entities they identify (as far as the authors knew when writing this) are Cryptographically Generated Addresses (CGAs) [RFC3972] and Host Identity Tags (HITs) [RFC7401] 🌈 The problem is that CGAs and HITs lack registration/retrieval capability. So each HHIT embeds plaintext info that designates the hierarchy it's registered in, plus a cryptographic hash of that info concatenated with the entity's public key, etc. ✨

Hash collisions may happen, but the DIME can detect them and reject the registration request instead of issuing credentials. One way to do that is enforcing a First Come First Served policy [RFC8126] 🫶 Preimage hash attacks get mitigated through this registration process too, since it locks the HHIT to a specific HI 🔒

3.3. HHIT as a Trustworthy DRIP Entity Identifier

a Remote UAS ID that can be trustworthy for Broadcast RID can be built from an asymmetric key pair 🔑 In this method, the UAS ID is cryptographically derived directly from the public key. Proof of UAS ID ownership (a verifiable endorsement versus a mere claim) is guaranteed by signing this cryptographic UAS ID with the matching private key. The link between the UAS ID and the private key is ensured by cryptographically binding the public key to the UAS ID. More specifically, the UAS ID is the hash of the public key. The public key is called the HI, and the UAS ID is called the HIT 💜

By construction, the HIT is statistically unique thanks to the mandatory use of cryptographic hash functions with second-preimage resistance. The cryptographically bound hierarchy plus a HHIT registration process gives you complete, global HHIT uniqueness 🌍 Registration forces an attacker to generate the same public key, rather than some other public key that generates the same HHIT. This is different from general IDs (like a Universally Unique Identifier (UUID) or a device serial number) used as the subject in an X.509 certificate 🙈

A UA equipped for Broadcast RID MUST be provisioned not only with its HHIT, but also with the HI public key the HHIT was derived from, plus the corresponding private key so it can sign messages 🎀

A UAS equipped for DRIP-enhanced Network RID MUST be provisioned likewise. The private key lives only in the ultimate source of Network RID messages. If the GCS is the source of the Network RID messages, the GCS MUST hold the private key. If the UA is the source of the Network RID messages and they're being relayed by the GCS, the UA MUST hold the private key, same as a UA that connects directly to the network instead of going through its GCS 🛸

Each Observer device with Internet connectivity MAY be provisioned with either public keys of the DRIP identifier root registries or certificates for subordinate registries. Each Observer device that needs to operate without Internet connectivity at any time MUST be provisioned that way 📡

HHITs can also be used throughout the USS/UTM system. Operators and Private Information Registries, plus other UTM entities, can use HHITs for their IDs ✨ These HHITs can support DRIP security functions, like the ones used with HIP, to strongly mutually authenticate and encrypt communications 🔐

A self-endorsement of a HHIT used as a UAS ID can be done in as little as 88 bytes when Ed25519 [RFC8032] is used. You only need to include the 16-byte HHIT, two 4-byte timestamps, and the 64-byte Ed25519 signature. Math checks out: 88 🧮

Ed25519 [RFC8032] is the mandatory-to-implement signing algorithm for HHIT, because GEN-1 and ID-5 [RFC9153] are best met by restricting the HI to 32 bytes. A larger public key would rule out the offline endorsement feature, which has to fit within the 200-byte Authentication Message maximum length. Other algorithms that meet this 32-byte constraint can be added as deemed needed 🌸

A DRIP identifier can be assigned to a UAS as a static HHIT by its manufacturer, for example a single HI and derived HHIT encoded as a hardware serial number, per [CTA2063A]. A static HHIT SHOULD only be used to bind one-time-use DRIP identifiers to the unique UA. Depending on the implementation, this may leave a HI private key in the manufacturer's possession (see also Section 9) 👀

In general, Internet access may be needed to validate Endorsements or Certificates. This may be avoided in the most common cases (e.g., endorsement of the UAS ID), even in disconnected environments, by prepopulating small caches on Observer devices with DIME public keys and a chain of Endorsements or Certificates that traces a path through the DIME tree. This assumes all parties on the trust path also use HHITs for their identities 🧚

3.4. HHIT for DRIP Identifier Registration and Lookup

UAS RID needs a deterministic lookup mechanism that quickly gives actionable info about the identified UA ⚡ Because Bluetooth 4 broadcast media is so size-limited, the UAS ID itself has to be a non-spoofable inquiry input into the lookup 🫶

A DRIP registration process based on the explicit hierarchy within a HHIT gives manageable uniqueness of the HI for the HHIT. The hierarchy is defined in [RFC9374] and has 2 levels: an RAA and then an HDA. The registration within this hierarchy is the defense against a cryptographic hash second-preimage attack on the HHIT (e.g., multiple HIs yielding the same HHIT; see Requirement ID-3 in [RFC9153]). The First Come First Served registration policy is adequate 💅

A lookup of the HHIT into the DIME gives you the registered HI for HHIT proof of ownership, plus deterministic access to any other needed actionable info, based on inquiry access authority (more details in Section 4.2) 🔍

4. DRIP Identifier Registration and Registries 🌟

DRIP registries hold both public and private UAS info (see PRIV-1 in [RFC9153]) that comes out of the DRIP identifier registration process 🗂️ Since these have different uses, and to improve scalability, security, and simplicity of administration, the public and private info can be stored in different registries. This section introduces the public and private information registries for DRIP identifiers. For ease of comprehension, it describes the registry functions using familiar terminology, without detailing which specific entities implement them (or using unfamiliar jargon) 🧁 Elsewhere in this document, and in upcoming documents about the DRIP registration processes and entities, the more specific term "DRIP Identity Management Entity" (DIME) will be used. This DRIP identifier registration process satisfies these DRIP requirements defined in [RFC9153]: GEN-3, GEN-4, ID-2, ID-4, ID-6, PRIV-3, PRIV-4, REG-1, REG-2, REG-3, and REG-4 ✅

4.1. Public Information Registry 📖

4.1.1. Background ✨

Okay so the public information registry is basically where the trustable stuff lives 💅 like endorsements that a UAS RID is owned by and registered with the HDA. 🫶 You can optionally include pointers to the registries for the HDA and RAA that are implicit in the UAS RID (like the HDA and RAA HHIT|HI used for endorsement signing ops) 🔐. This public info is mainly for Observers of Broadcast RID messages 👀. Data on UAS that only use Network RID lives in an Observer's Net-RID DP, which directly provides all the public registry info 🌸. Honestly, the Net-RID DP is the only source for a query on an airspace volume 🛸.

Note: In the above paragraph, | signifies concatenation of information, e.g., X | Y is the concatenation of X and Y.

4.1.2. Public DRIP Identifier Registry 🌐

Bestie, a DRIP identifier MUST be registered as an Internet domain name (at an arbitrary level in the hierarchy, e.g., in .ip6.arpa) 💖. That means DNS can provide all the public DRIP info it needs, no cap. A standardized HHIT Fully Qualified Domain Name (FQDN) can deliver the HI through a HIP Resource Record (RR) [RFC8005], plus other public goodies like RAA and HDA PTRs and HIP Rendezvous Servers (RVSs) [RFC8004] 🎀. These public information registries can use DNSSEC to deliver the public info that isn't inherently trustable (so basically everything except endorsements) 🧚.

The same DNS entry for the HHIT can double as a revocation service 💀. For example, instead of handing back the HI RR, it may return some record showing that the HI (and thus HHIT) has been revoked 🙈.

4.2. Private Information Registry 🔒

4.2.1. Background

The private info needed for DRIP identifiers is giving the same energy as Internet domain name registration 🍓. A DRIP identifier solution can borrow existing Internet resources, like registration protocols, infrastructure, and business models, by fitting into a UAS ID structure that's compatible with DNS names ✨. The HHIT hierarchy can provide the scalability and management structure needed 👑. It's expected that the private information registry function will be run by the same organizations that operate a USS, and it'll likely be integrated with a USS 🦋. The lookup function may be implemented by the Net-RID DPs.

4.2.2. Information Elements 📝

When a DET is used as a UA's Session ID, the matching manufacturer-assigned serial number MUST be stored in a private information registry that can be identified uniquely from the DET 🔥. When a DET is used as either a UA's Session ID or a UA's manufacturer-assigned serial number, and the operation is being flown under UTM, the matching UTM-system-assigned Operational Intent Identifier SHOULD be stored that way too 🌈. Other information MAY be stored as well, and often must, to satisfy CAA regulations or USS operator policies 📋.

4.2.3. Private DRIP Identifier Registry Methods ⭐

A DRIP private information registry supports the essential registry operations (add, delete, update, and query) using interoperable open standard protocols 🫶. It pulls this off by leveraging aspects of the Extensible Provisioning Protocol (EPP) [RFC5730] and the Registry Data Access Protocol (RDAP) [RFC7480] [RFC9082] [RFC9083] ✨. The DRIP private information registry where a given UAS is registered needs to be findable, starting from the UAS ID, using the methods specified in [RFC9224] 🔍.

4.2.4. Alternative Private DRIP Registry Methods 🦋

A DRIP private information registry might be an access-controlled DNS (e.g., via DNS over TLS) 🔐. WebFinger [RFC7033] can also be supported 💜. These alternative methods may be used by a Net-RID DP with specific customers 🧁.

5. DRIP Identifier Trust 👑

Okay, real talk: the DRIP entity identifier is self-asserting, but on its own it does not provide the trustworthiness (non-repudiation, protection vs. spoofing, message integrity protection, scalability, etc.) that's essential to UAS RID, as justified in [RFC9153] 😭. So it MUST be registered (under DRIP registries) and actively used by the party, which in most cases is the UA 💅. A sender's identity can't be proved just by possessing a DRIP Entity Tag (DET) and broadcasting it as a claim that it belongs to that sender 🙅‍♀️. Signing data with that HI's private key proves very little, since it's subject to trivial replay attacks using previously broadcast messages 💀. Only sending the DET plus a signature on novel data (frequently changing and unpredictable) that the Observer can externally validate proves that the observed UA possesses the private key and thus the claimed UAS ID 🔥. An example is a signed Location/Vector message that matches actually seeing the UA at the location and time reported in the signed message 📍.

The severe constraints of Broadcast RID make it really hard to satisfy UAS RID requirements 😩. Still, from received Broadcast RID messages and info that can be looked up using the received UAS ID in online registries or local caches, it's possible to establish levels of trust in the asserted information and the operator 🌸.

A combination of different DRIP Authentication Messages lets an Observer validate a UAS DRIP ID in real time, whether offline (without Internet connection) or online (with one) ✨. Some messages must contain the relevant registration of the UA's DRIP ID in the claimed DIME. Some messages must contain sender signatures over both static data (e.g., registration) and dynamically changing data (e.g., current UA location) 🧚. Put those two sets of info together and an Observer can piece together a chain of trust, including real-time evidence, to make a determination on the UA's claims 🕵️‍♀️.

This process (combining the DRIP entity identifier, registries, and authentication formats for Broadcast RID) can satisfy the following DRIP requirements defined in [RFC9153]: GEN-1, GEN-2, GEN-3, ID-2, ID-3, ID-4, and ID-5 🎀.

6. Harvesting Broadcast Remote ID Messages for UTM Inclusion 🛸

ASTM expected that regulators would require both Broadcast RID and Network RID for large UAS, but would let small UAS satisfy UAS RID requirements with the operator's choice of either one 🍓. The EASA first specified Broadcast RID for basically all UAS and is now also considering Network RID 🌈. The FAA UAS RID Final Rules [FAA_RID] only permit Broadcast RID for rule compliance, but they still encourage Network RID for complementary functionality, especially for UTM 💜.

One opportunity is to enhance the architecture with gateways from Broadcast RID to Network RID 🌉. This gives you the best of both worlds and gives regulators and operators flexibility 🫶. It beats either form of UAS RID alone: you get greater fidelity than Network RID reporting of [FAA_RID] planned area operations, plus surveillance of areas too big for local direct visual observation and direct Radio Frequency Line Of Sight (RF-LOS) link-based Broadcast RID (like a city or a national forest) 🌲.

These gateways could be pre-positioned (around airports, public gatherings, and other sensitive areas) and/or crowdsourced, since all you need is a smartphone with a suitable app 📱. Crowdsourcing can be encouraged by quid pro quo, by providing CS-RID Surveillance Supplemental Data Service Provider (SDSP) outputs only to CS-RID Finders 🎁. Broadcast RID media have a limited range, so messages claiming sender (typically UA) locations far from a physical layer receiver ("Finder" below, typically Observer device) should arouse suspicion of possible intent to deceive 👀. A fast, computationally inexpensive consistency check can be performed (by the Finder or the Surveillance SDSP) on application layer data present in the gateway, comparing claimed UA location against physical receiver location, and authorities can be alerted to failed checks 🚨. CS-RID SDSPs can use messages with precise date/time/position stamps from the gateways to multilaterate UA locations, independent of the locations claimed in the messages 🧮. Those claimed locations are entirely self-reported by the operator in UAS RID and UTM, so they're subject not only to natural time lag and error, but also to operator misconfiguration or intentional deception 😤.

Multilateration uses physical layer info, like the precise Time Of Arrival (TOA) of transmissions from mobile transmitters at receivers with a priori precisely known locations, to estimate where those mobile transmitters are 📡.

Gateways with extra sensors (like smartphones with cameras) can also give independent info on UA type and size, confirming or refuting the claims made in UAS RID messages 📸.

Sections 6.1 and 6.2 define two additional entities that are required to provide this Crowdsourced Remote ID (CS-RID) 🧚.

This approach satisfies the following DRIP requirements defined in [RFC9153]: GEN-5, GEN-11, and REG-1. Since Broadcast messages are inherently multicast, GEN-10 is met for local-link multicast to multiple Finders (and that's exactly how multilateration is possible) 🦋.

6.1. The CS-RID Finder 🎧

A CS-RID Finder is the gateway for Broadcast Remote ID Messages into UTM 🚪. It does this gateway job via a CS-RID SDSP. A CS-RID Finder could implement, integrate, or accept outputs from a Broadcast RID receiver. However, it should not depend upon a direct interface with a GCS, Net-RID SP, Net-RID DP, or Net-RID client 🙅‍♀️. Instead, it would present a new interface to a CS-RID SDSP, similar to but easily distinguishable from the one a UAS (UA or GCS) presents to a Net-RID SP ✨.

6.2. The CS-RID SDSP 🌈

A CS-RID SDSP aggregates and processes information collected by CS-RID Finders, for example by estimating UA locations using multilateration when possible 📊. A CS-RID SDSP should present the same interface to a Net-RID SP as it does to a Net-RID DP, and to a Net-RID DP as it does to a Net-RID SP 🔁. Its data source, though, must be easily distinguishable via Finders rather than coming directly from the UAS itself 💖.

7. DRIP Contact 📞✨

okay so one of the ways DRIP can level up [F3411-22a] is by giving Observers info they can actually act on 💅. An Observer can instantly start secure comms with the UAS remote pilot, Pilot In Command, operator, the USS the operation is flying under, or any other entity that could share more about the operation and what it's up to, and/or immediately influence how the operation continues or ends (e.g., land or otherwise exit an airspace volume) 🛬. ngl that kind of communication is lowkey distracting, so it needs strong "AAA" (Authentication, Attestation, Authorization, Access Control, Accounting, Attribution, Audit) 🔐, following whatever applicable policies apply (e.g., of the cognizant CAA) 🎀.

A DRIP entity identifier based on a HHIT, as in Section 3, bakes in an identifier of the DIME it can be found in (usually the USS the UAS is flying under 🦋), and the procedures in Section 5 let an Observer verify that relationship ✅. A DRIP entity identifier with suitable records in public and private registries, as outlined in Section 5, can unlock lookup of not just info about the UAS but also the identities of, and pointers to info about, the various associated entities (e.g., the USS the UAS is flying an operation under) 🗂️, including ways to contact those associated entities (i.e., locators, typically IP addresses) 📬.

A suitably equipped Observer could start a secure communication channel, using the DET HI, to a similarly equipped and identified entity: the UA itself if it's operating autonomously, the GCS if the UA is remotely piloted and the necessary records have been populated in the DNS, the USS, etc. 🤖 Assuming secure communication setup (e.g., via IPsec or HIP), arbitrary standard higher-layer protocols can then be used for Observer to Pilot (O2P) communications (e.g., SIP [RFC3261] et seq), Vehicle to Everything (V2X) (or more specifically Aircraft to Anything (A2X)) communications (e.g., [MAVLink]), etc. 🌈 Certain preconditions are necessary: 1) each party needs a currently usable means (typically a DNS) of resolving the other party's DRIP entity identifier to a currently usable locator (IP address), and 2) there must be currently usable bidirectional IP connectivity (not necessarily via the Internet) between the parties. One method directly supported by the use of HHITs as DRIP entity identifiers is initiation of a HIP Base Exchange (BEX) and Bound End-to-End Tunnel (BEET) 🔥.

This approach satisfies DRIP requirement GEN-6 Contact, supports satisfaction of DRIP requirements GEN-8, GEN-9, PRIV-2, PRIV-5, and REG-3 [RFC9153], and is compatible with all other DRIP requirements 💖.

8. IANA Considerations 🧾

good news bestie: this document has no IANA actions 🌸.

9. Security Considerations 🚨

okay this section is SERIOUS, so pay attention 🙈. The size of the public key hash in the HHIT is vulnerable to a second-preimage attack 💀. It's well within current server array technology to compute another key pair that hashes to the same HHIT (given the current ORCHID construction hash length, which has to fit UAS RID and IPv6 address constraints). So if a receiver were to check HHIT/HI pair validity only by verifying that the received HI and associated information, when hashed in the ORCHID construction, reproduce the received HHIT, an adversary could impersonate a validly registered UA 😱. To defend against this, online receivers should verify the received HHIT and received HI with the HDA (typically USS) that the HHIT/HI pair purports to be registered with. Online and offline receivers can use a chain of received DRIP link endorsements from a root of trust through the RAA and the HDA to the UA, e.g., as described in [DRIP-AUTH] and [DRIP-REGISTRIES] 🔗.

Compromise of a DIME private key could do widespread harm [DRIP-REGISTRIES]. In particular, it would let bad actors impersonate trusted members of said DIME 🥀. These risks are in addition to those involving key management practices, and they'll be addressed as part of the DIME process. All DRIP public keys can be found in the DNS, so they can be revoked in the DNS, and users SHOULD check the DNS when available 🔍. Specific key revocation procedures are as yet to be determined ⏳.

9.1. Private Key Physical Security 🗝️

the security provided by asymmetric cryptographic techniques depends on protection of the private keys 🛡️. It may be necessary for the GCS to have the key pair to register the HHIT to the USS. So it may be the GCS that generates the key pair and delivers it to the UA, which makes the GCS part of the key security boundary. Leakage of the private key, from either the UA or the GCS, to the component manufacturer is a valid concern, and steps need to be in place to ensure safe keeping of the private key 🔐. Since it's possible for the UAS RID sender of a small harmless UA (or the entire UA) to be carried by a larger dangerous UA as a "false flag" 🚩, it is out of scope to deal with secure storage of the private key 🙃.

9.2. Quantum Resistant Cryptography 🔮

there has been no effort as of yet in DRIP to address post quantum computing cryptography 🕰️. Small UAS and Broadcast Remote ID communications are so constrained that current post quantum computing cryptography is not applicable 📉. Fortunately, since a UA may use a unique HHIT for each operation, the attack window can be limited to the duration of the operation ✨. One potential future DRIP use for post quantum cryptography is for key pairs that have long usage lives but that rarely, if ever, need to be transmitted over bandwidth constrained links, such as for serial numbers or operators 🧩. As the HHIT contains the ID for the cryptographic suite used in its creation, a future post quantum computing safe algorithm that fits Remote ID constraints may be readily added 💜. This is left for future work 📚.

9.3. Denial-of-Service (DoS) Protection 🛑

Remote ID services from the UA use a wireless link in a public space, so they're open to many forms of RF jamming 📡. It's trivial for an attacker to stop any UA messages from reaching a wireless receiver 😬. So it's pointless to attempt relief from DoS attacks, since there's always the ultimate RF jamming attack 🙄. Also, DoS may be attempted with spoofing/replay attacks, for which see Section 9.4 🔁.

9.4. Spoofing and Replay Protection 👻

as noted in Section 5, spoofing is combatted by the intrinsic self-attesting properties of HHITs, plus their registration 🪪. Also, as noted in Section 5, to combat replay attacks, a receiver MUST NOT trust any claims nominally received from an observed UA (not even the Basic ID message purportedly identifying that UA) until the receiver verifies that the private key used to sign those claims is trusted, that the sender actually possesses that key, and that the sender appears indeed to be that observed UA 🚫. This requires receiving a complete chain of endorsement links from a root of trust to the UA's leaf DET, plus a message containing suitable nonce-like data signed with the private key corresponding to that DET, and verifying all the foregoing 📝. The term "nonce-like" describes data that is readily available to the prover and the verifier, changes frequently, is not predictable by the prover, and can be checked quickly at low computational cost by the verifier 🎲. A Location/Vector message is an obvious choice 📍.

9.5. Timestamps and Time Sources ⏰

Section 6 and, more fundamentally, Section 3.3 both require timestamps 🕒. In Broadcast RID messages, [F3411-22a] specifies both 32-bit Unix-style UTC timestamps (seconds since midnight going into the 1st day of 2019, rather than 1970) and 16-bit relative timestamps (tenths of seconds since the start of the most recent hour or other specified event). [F3411-22a] requires that 16-bit timestamp accuracy, relative to the time of applicability of the data being timestamped, also be reported, with a worst allowable case of 1.5 seconds ⏱️. [F3411-22a] does not specify the time source, but GNSS is generally assumed, since latitude, longitude, and geodetic altitude must be reported and most small UAS use GNSS for positioning and navigation 🛰️.

Informative note: For example, to satisfy [FAA_RID], [F3586-22] specifies tamper protection of the entire RID subsystem and use of the GPS operated by the US Government. The GPS has sub-microsecond accuracy and 1.5-second precision. In this example, UA-sourced messages can be assumed to have timestamp accuracy and precision of 1.5 seconds at worst. 🇺🇸

GCS often have access to cellular LTE or other time sources better than the foregoing, and such better time sources would be required to support multilateration in Section 6, but such better time sources cannot be assumed generally for purposes of security analysis 📶.

10. Privacy and Transparency Considerations 🫶

Broadcast RID messages can contain personal data (Section 3.2 of [RFC6973]), such as the operator ID, and, in most jurisdictions, must contain the pilot/GCS location 📍. The DRIP architectural approach for personal data protection is symmetric encryption of the personal data using a session key known to the UAS and its USS, as follows 🔐. Authorized Observers obtain plaintext in either of two ways: 1) an Observer can send the UAS ID and the cyphertext to a server that offers decryption as a service, and 2) an Observer can send just the UAS ID to a server that returns the session key so that the Observer can directly, locally decrypt all cyphertext sent by that UA during that session (UAS operation) 🗝️. In either case, the server can be a public safety USS, the Observer's own USS, or the UA's USS if the latter can be determined (which, under DRIP, can be from the UAS ID itself) 🏛️. Personal data is protected unless the UAS is otherwise configured, i.e., as part of DRIP-enhanced RID subsystem provisioning, as part of UTM operation authorization, or via subsequent authenticated communications from a cognizant authority ✅.

Personal data protection MUST NOT be used if the UAS loses connectivity to its USS 🚫. If the UAS loses connectivity, Observers nearby likely also won't have connectivity enabling decryption of the personal data 📵. The UAS always has the option to abort the operation if personal data protection is disallowed, but if this occurs during flight, the UA then MUST broadcast the personal data without protection until it lands and is powered off 🛬. Note that normative language was used only minimally in this section, since privacy protection requires refinement of the DRIP architecture and specification of interoperable protocol extensions, which are left for future DRIP documents 🌷.

11. References 📚

11.1. Normative References 📚✨

11.2. Informative References 🦋

Appendix A. Overview of UAS Traffic Management (UTM) 🌸

A.1. Operation Concept 🌸

Okay so NASA and the FAA wanted to fit UAS (aka drones 💖) into the national airspace system (NAS), and that's how the UTM concept and the whole ecosystem around it got started. The UTM concept first showed up in 2013, and version 2.0 dropped in 2020 [FAA_UAS_Concept_Of_Ops] ✨

The final concept refinement, the first prototype, and the testing were handled by the joint FAA and NASA UTM research transition team. Then the rest of the world got involved. SESAR kicked off CORUS (Concept of Operation for EuRopean UTM Systems) to research its UTM counterpart, which is [U-Space]. This effort is led by EUROCONTROL (the European Organization for the Safety of Air Navigation) 🇪🇺

Both NASA and SESAR published their UTM concepts of operations, which are basically the blueprints for future air traffic management (ATM) systems. The goal is keeping manned and unmanned aircraft integrated in the national airspace in a way that's safe and efficient 🫶

UTM is made up of UAS operations infrastructure, procedures, and local regulation compliance policies that keep UAS integration and operation safe. Its main jobs include, but aren't limited to, giving UAS operators and service providers a way to communicate, plus a platform where UAS service providers can talk to each other 💬

A.2. UAS Service Supplier (USS)

A USS is a big deal for hitting the key performance indicators (KPIs) that UTM is supposed to deliver 👑 It acts as a proxy between UAS operators and UTM service providers. It offers services like real-time UAS traffic monitoring and planning, aeronautical data archiving, airspace and violation control, and interacting with other third-party control entities, etc. A USS can coexist with other USS to build a large service coverage map that can load-balance, relay, and share UAS traffic information. Main character energy, honestly 🦋

The FAA works with UAS industry shareholders and promotes the Low Altitude Authorization and Notification Capability [LAANC] program. LAANC is the first system to realize some of the functionality UTM envisioned, and it's giving real progress 🔥 It can automate UAS operational intent (flight plan) submissions and applications for airspace authorization in real time. It does this by checking against multiple aeronautical databases, including airspace classification and the operating rules that go with it, the FAA UAS facility map, special use airspace, Notice to Airmen (NOTAM), and Temporary Flight Restriction (TFR) 🧚

A.3. UTM Use Cases for UAS Operations

This section walks through a couple of use case scenarios where UAS participation in UTM makes a significant safety improvement. Iconic 💅

  1. For a UAS participating in UTM and taking off or landing in controlled airspace (e.g., Class Bravo, Charlie, Delta, and Echo in the United States), the USS the UAS is operating under is responsible for a lot 😭 It verifies UA registration, authenticates the UAS operational intent (flight plan) by checking against a designated UAS facility map database, obtains air traffic control (ATC) authorization, and monitors the UAS flight path to keep safe margins and follow the pre-authorized sequence of authorized 4-D volumes (route). Periodt.
  2. For a UAS participating in UTM and taking off or landing in uncontrolled airspace (e.g., Class Golf in the United States), preflight authorization must be obtained from a USS when operating BVLOS. The USS either accepts or rejects the operational intent (flight plan) it receives from the UAS 🙈 An accepted UAS operation may, and in some cases must, share its current flight data, like GPS position and altitude, with the USS. The USS may maintain the UAS operation status near real time in the short term, and provide it to authorized requestors. It may also retain at least some of it in the longer term, e.g., for overall airspace traffic monitoring 🌈

Appendix B. Automatic Dependent Surveillance Broadcast (ADS-B) ✨

ADS-B is the de jure technology used in manned aviation for sharing location information. It sends data from the aircraft to ground and satellite-based systems, and it was designed in the early 2000s 🛩️ Broadcast RID is conceptually similar to ADS-B, but its receiver target is the general public on generally available devices (e.g., smartphones). So it's the same vibe, just for everyday people 📱

Okay, but for numerous technical reasons, ADS-B itself is not suitable for low-flying, small UAS. These reasons include, but aren't limited to, the following:

  1. lack of support for the 1090-MHz ADS-B channel on any consumer handheld devices 🙃
  2. Cost, Size, Weight, and Power (CSWaP) requirements of ADS-B transponders on CSWaP-constrained UA 💸
  3. limited bandwidth of both uplink and downlink, which would likely be saturated by large numbers of UAS, endangering manned aviation 💀

Understanding these technical shortcomings, regulators worldwide have ruled out the use of ADS-B for the small UAS that UAS RID and DRIP are intended for. Which is why we need them, bestie 🫶

Acknowledgments

The work of the FAA's UAS Identification and Tracking (UAS ID) Aviation Rulemaking Committee (ARC) is the foundation of later ASTM and IETF DRIP WG efforts 🌸 The work of ASTM F38.02 in balancing the interests of diverse stakeholders is essential to the rapid and widespread deployment of UAS RID that's needed. Huge thanks to all the reviewers who gave helpful, positive comments: Alexandre Petrescu, Stephan Wenger, Kyle Rose, Roni Even, Thomas Fossati, Valery Smyslov, Erik Kline, John Scudder, Murray Kucheraway, Robert Wilton, Roman Daniliw, Warren Kumari, Zaheduzzaman Sarker, and Dave Thaler 🎀 Thanks to Laura Welch for her assistance in greatly improving this document 💜 Thanks to Dave Thaler, again, for showing the authors how to leverage the RATS model for attestation in DRIP 🧚 Thanks to chairs Daniel Migault and Mohamed Boucadair for directing the team of authors and editors, some of whom were relative newcomers to writing IETF documents 🦋 And thanks especially to Internet Area Director Éric Vyncke for guidance and support 👑

Authors' Addresses

Here's who made this happen, bestie 💖

Stuart W. Card
AX Enterprize
4947 Commercial Drive
Yorkville, NY 13495
United States of America
Email: stu.card@axenterprize.com
Adam Wiethuechter
AX Enterprize
4947 Commercial Drive
Yorkville, NY 13495
United States of America
Email: adam.wiethuechter@axenterprize.com
Robert Moskowitz
HTT Consulting
Oak Park, MI 48237
United States of America
Email: rgm@labs.htt-consult.com
Shuai Zhao (editor)
Intel
2200 Mission College Blvd.
Santa Clara,  95054
United States of America
Email: shuai.zhao@ieee.org
Andrei Gurtov
Linköping University
IDA
SE-58183 Linköping
Sweden
Email: gurtov@acm.org
📦 where this page comes from