idnits 2.17.1 draft-ietf-drip-arch-24.txt: -(10): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 372 has weird spacing: '... Public o---...' -- The document date (10 June 2022) is 658 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-49) exists of draft-ietf-drip-auth-12 == Outdated reference: A later version (-14) exists of draft-ietf-drip-registries-03 -- Obsolete informational reference (is this intentional?): RFC 7484 (Obsoleted by RFC 9224) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 drip S. Card 3 Internet-Draft A. Wiethuechter 4 Intended status: Informational AX Enterprize 5 Expires: 12 December 2022 R. Moskowitz 6 HTT Consulting 7 S. Zhao (Editor) 8 Tencent 9 A. Gurtov 10 Linköping University 11 10 June 2022 13 Drone Remote Identification Protocol (DRIP) Architecture 14 draft-ietf-drip-arch-24 16 Abstract 18 This document describes an architecture for protocols and services to 19 support Unmanned Aircraft System (UAS) Remote Identification (RID) 20 and tracking, plus UAS RID-related communications. This architecture 21 adheres to the requirements listed in the DRIP Requirements document 22 (RFC9153). 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 12 December 2022. 41 Copyright Notice 43 Copyright (c) 2022 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Revised BSD License text as 52 described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Revised BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Overview of Unmanned Aircraft System (UAS) Remote ID (RID) 59 and Standardization . . . . . . . . . . . . . . . . . . . 3 60 1.2. Overview of Types of UAS Remote ID . . . . . . . . . . . 4 61 1.2.1. Broadcast RID . . . . . . . . . . . . . . . . . . . . 5 62 1.2.2. Network RID . . . . . . . . . . . . . . . . . . . . . 5 63 1.3. Overview of USS Interoperability . . . . . . . . . . . . 7 64 1.4. Overview of DRIP Architecture . . . . . . . . . . . . . . 8 65 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 10 66 2.1. Additional Abbreviations . . . . . . . . . . . . . . . . 10 67 2.2. Additional Definitions . . . . . . . . . . . . . . . . . 11 68 3. HHIT as the DRIP Entity Identifier . . . . . . . . . . . . . 11 69 3.1. UAS Remote Identifiers Problem Space . . . . . . . . . . 12 70 3.2. HHIT as A Trustworthy DRIP Entity Identifier . . . . . . 12 71 3.3. HHIT for DRIP Identifier Registration and Lookup . . . . 14 72 3.4. HHIT as a Cryptographic Identifier . . . . . . . . . . . 14 73 4. DRIP Identifier Registration and Registries . . . . . . . . . 14 74 4.1. Public Information Registry . . . . . . . . . . . . . . . 15 75 4.1.1. Background . . . . . . . . . . . . . . . . . . . . . 15 76 4.1.2. DNS as the Public DRIP Identifier Registry . . . . . 15 77 4.2. Private Information Registry . . . . . . . . . . . . . . 15 78 4.2.1. Background . . . . . . . . . . . . . . . . . . . . . 15 79 4.2.2. EPP and RDAP as the Private DRIP Identifier 80 Registry . . . . . . . . . . . . . . . . . . . . . . 16 81 4.2.3. Alternative Private DRIP Registry methods . . . . . . 16 82 5. DRIP Identifier Trust . . . . . . . . . . . . . . . . . . . . 16 83 6. Harvesting Broadcast Remote ID messages for UTM Inclusion . . 17 84 6.1. The CS-RID Finder . . . . . . . . . . . . . . . . . . . . 18 85 6.2. The CS-RID SDSP . . . . . . . . . . . . . . . . . . . . . 18 86 7. DRIP Contact . . . . . . . . . . . . . . . . . . . . . . . . 18 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 88 8.1. Private Key Physical Security . . . . . . . . . . . . . . 20 89 8.2. Post Quantum Computing Out Of Scope . . . . . . . . . . . 20 90 8.3. Denial Of Service (DOS) Protection Out Of Scope . . . . . 20 91 9. Privacy & Transparency Considerations . . . . . . . . . . . . 21 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 93 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 94 10.2. Informative References . . . . . . . . . . . . . . . . . 21 95 Appendix A. Overview of Unmanned Aircraft Systems (UAS) Traffic 96 Management (UTM) . . . . . . . . . . . . . . . . . . . . 25 98 A.1. Operation Concept . . . . . . . . . . . . . . . . . . . . 25 99 A.2. UAS Service Supplier (USS) . . . . . . . . . . . . . . . 26 100 A.3. UTM Use Cases for UAS Operations . . . . . . . . . . . . 26 101 Appendix B. Automatic Dependent Surveillance Broadcast 102 (ADS-B) . . . . . . . . . . . . . . . . . . . . . . . . . 27 103 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 27 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 106 1. Introduction 108 This document describes an architecture for protocols and services to 109 support Unmanned Aircraft System (UAS) Remote Identification (RID) 110 and tracking, plus RID-related communications. The architecture 111 takes into account both current (including proposed) regulations and 112 non-IETF technical standards. 114 The architecture adheres to the requirements listed in the DRIP 115 Requirements document [RFC9153]. The requirements document provides 116 an extended introduction to the problem space and use cases. 118 1.1. Overview of Unmanned Aircraft System (UAS) Remote ID (RID) and 119 Standardization 121 UAS Remote Identification (RID) is an application that enables a UAS 122 to be identified by Unmanned Aircraft Systems Traffic Management 123 (UTM) and UAS Service Supplier (USS) (Appendix A) or third party 124 entities such as law enforcement. Many considerations (e.g., safety) 125 dictate that UAS be remotely identifiable. 127 Civil Aviation Authorities (CAAs) worldwide are mandating UAS RID. 128 CAAs currently promulgate performance-based regulations that do not 129 specify techniques, but rather cite industry consensus technical 130 standards as acceptable means of compliance. 132 USA Federal Aviation Administration (FAA) 134 The FAA published a Notice of Proposed Rule Making [NPRM] in 2019 135 and thereafter published a "Final Rule" in 2021 [FAA_RID], 136 imposing requirements on UAS manufacturers and operators, both 137 commercial and recreational. The rule clearly states that 138 Automatic Dependent Surveillance Broadcast (ADS-B) Out and 139 transponders cannot be used to satisfy the UAS RID requirements on 140 UAS to which the rule applies (see Appendix B). 142 European Union Aviation Safety Agency (EASA) 143 The EASA published a [Delegated] regulation in 2019 imposing 144 requirements on UAS manufacturers and third-country operators, 145 including but not limited to UAS RID requirements. The same year, 146 EASA also published an [Implementing] regulation laying down 147 detailed rules and procedures for UAS operations and operating 148 personnel then was updated in 2021 [Implementing_update]. A 149 Notice of Proposed Amendment [NPA] was published in 2021 to 150 provide more information about the development of acceptable means 151 of compliance and guidance material to support the U-space 152 regulation. 154 American Society for Testing and Materials (ASTM) 156 ASTM International, Technical Committee F38 (UAS), Subcommittee 157 F38.02 (Aircraft Operations), Work Item WK65041, developed the 158 ASTM [F3411] Standard Specification for Remote ID and Tracking. 160 ASTM defines one set of UAS RID information and two means, MAC- 161 layer broadcast and IP-layer network, of communicating it. If an 162 UAS uses both communication methods, the same information must be 163 provided via both means. [F3411] is cited by the FAA in its UAS 164 RID final rule [FAA_RID] as "a potential means of compliance" to a 165 Remote ID rule. 167 The 3rd Generation Partnership Project (3GPP) 169 With release 16, the 3GPP completed the UAS RID requirement study 170 [TS-22.825] and proposed a set of use cases in the mobile network 171 and services that can be offered based on UAS RID. Release 17 172 specification focuses on enhanced UAS service requirements and 173 provides the protocol and application architecture support that 174 will be applicable for both 4G and 5G networks. The study of 175 Further Architecture Enhancement for Uncrewed Aerial Vehicles 176 (UAV) and Urban Air Mobility (UAM) [FS_AEUA] in release 18 further 177 enhances the communication mechanism between UAS and USS/UTM. The 178 DRIP Entity Tag in Section 3 may be used as the 3GPP CAA-level UAS 179 ID for Remote Identification purposes. 181 1.2. Overview of Types of UAS Remote ID 183 This specification introduces two types UAS Remote ID defined in ASTM 184 [F3411]. 186 1.2.1. Broadcast RID 188 [F3411] defines a set of UAS RID messages for direct, one-way, 189 broadcast transmissions from the UA over Bluetooth or Wi-Fi. These 190 are currently defined as MAC-Layer messages. Internet (or other Wide 191 Area Network) connectivity is only needed for UAS registry 192 information lookup by Observers using the directly received UAS ID. 193 Broadcast RID should be functionally usable in situations with no 194 Internet connectivity. 196 The minimum Broadcast RID data flow is illustrated in Figure 1. 198 +------------------------+ 199 | Unmanned Aircraft (UA) | 200 +-----------o------------+ 201 | 202 | 203 | 204 | app messages directly over 205 | one-way RF data link (no IP) 206 | 207 | 208 v 209 +------------------o-------------------+ 210 | Observer's device (e.g., smartphone) | 211 +--------------------------------------+ 213 Figure 1 215 Broadcast RID provides information only about unmanned aircraft (UA) 216 within direct Radio Frequency (RF) Line-Of-Sight (LOS), typically 217 similar to Visual LOS (VLOS), with a range up to approximately 1 km. 218 This information may be 'harvested' from received broadcasts and made 219 available via the Internet, enabling surveillance of areas too large 220 for local direct visual observation or direct RF link-based ID (see 221 Section 6). 223 1.2.2. Network RID 225 [F3411], using the same data dictionary that is the basis of 226 Broadcast RID messages, defines a Network Remote Identification (Net- 227 RID) data flow as follows. 229 * The information to be reported via UAS RID is generated by the 230 UAS. Typically some of this data is generated by the UA and some 231 by the GCS (Ground Control Station), e.g., their respective Global 232 Navigation Satellite System (GNSS) derived locations. 234 * The information is sent by the UAS (UA or GCS) via unspecified 235 means to the cognizant Network Remote Identification Service 236 Provider (Net-RID SP), typically the USS under which the UAS is 237 operating if participating in UTM. 239 * The Net-RID SP publishes via the Discovery and Synchronization 240 Service (DSS) over the Internet that it has operations in various 241 4-D airspace volumes (Section 2.2 of [RFC9153]), describing the 242 volumes but not the operations. 244 * An Observer's device, which is expected, but not specified, to be 245 web-based, queries a Network Remote Identification Display 246 Provider (Net-RID DP), typically also a USS, about any operations 247 in a specific 4-D airspace volume. 249 * Using fully specified web-based methods over the Internet, the 250 Net-RID DP queries all Net-RID SP that have operations in volumes 251 intersecting that of the Observer's query for details on all such 252 operations. 254 * The Net-RID DP aggregates information received from all such Net- 255 RID SP and responds to the Observer's query. 257 The minimum Net-RID data flow is illustrated in Figure 2: 259 +-------------+ ****************** 260 | UA | * Internet * 261 +--o-------o--+ * * 262 | | * * 263 | | * * +------------+ 264 | '--------*--(+)-----------*-----o | 265 | * | * | | 266 | .--------*--(+)-----------*-----o Net-RID SP | 267 | | * * | | 268 | | * .------*-----o | 269 | | * | * +------------+ 270 | | * | * 271 | | * | * +------------+ 272 | | * '------*-----o | 273 | | * * | Net-RID DP | 274 | | * .------*-----o | 275 | | * | * +------------+ 276 | | * | * 277 | | * | * +------------+ 278 +--o-------o--+ * '------*-----o Observer's | 279 | GCS | * * | Device | 280 +-------------+ ****************** +------------+ 281 Figure 2 283 Command and Control (C2) must flow from the GCS to the UA via some 284 path. Currently (in the year 2022) this is typically a direct RF 285 link; however, with increasing Beyond Visual Line of Sight (BVLOS) 286 operations, it is expected often to be a wireless link at either end 287 with the Internet between. 289 Telemetry (at least UA's position and heading) flows from the UA to 290 the GCS via some path, typically the reverse of the C2 path. Thus, 291 UAS RID information pertaining to both the GCS and the UA can be 292 sent, by whichever has Internet connectivity, to the Net-RID SP, 293 typically the USS managing the UAS operation. 295 The Net-RID SP forwards UAS RID information via the Internet to 296 subscribed Net-RID DPs, typically USS. Subscribed Net-RID DPs then 297 forward RID information via the Internet to subscribed Observer 298 devices. Regulations require and [F3411] describes UAS RID data 299 elements that must be transported end-to-end from the UAS to the 300 subscribed Observer devices. 302 [F3411] prescribes the protocols between the Net-RID SP, Net-RID DP, 303 and the DSS. It also prescribes data elements (in JSON) between the 304 Observer and the Net-RID DP. DRIP could address standardization of 305 secure protocols between the UA and GCS (over direct wireless and 306 Internet connection), between the UAS and the Net-RID SP, and/or 307 between the Net-RID DP and Observer devices. 309 Informative note: Neither link layer protocols nor the use of 310 links (e.g., the link often existing between the GCS and the 311 UA) for any purpose other than carriage of UAS RID information 312 is in the scope of [F3411] Network RID. 314 1.3. Overview of USS Interoperability 316 With Net-RID, there is direct communication between each UAS and its 317 USS. Multiple USS exchange information with the assistance of a DSS 318 so all USS collectively have knowledge about all activities in a 4D 319 airspace. The interactions among an Observer, multiple UAS, and 320 their USS are shown in Figure 3. 322 +------+ +----------+ +------+ 323 | UAS1 | | Observer | | UAS2 | 324 +---o--+ +-----o----+ +--o---+ 325 | | | 326 ******|*************|************|****** 327 * | | | * 328 * | +---o--+ | * 329 * | .------o USS3 o------. | * 330 * | | +--o---+ | | * 331 * | | | | | * 332 * +-o--o-+ +--o--+ +-o--o-+ * 333 * | o----o DSS o-----o | * 334 * | USS1 | +-----+ | USS2 | * 335 * | o----------------o | * 336 * +------+ +------+ * 337 * * 338 * Internet * 339 **************************************** 341 Figure 3 343 1.4. Overview of DRIP Architecture 345 Figure 4 illustrates a global UAS RID usage scenario. Broadcast RID 346 links are not shown as they reach from any UA to any listening 347 receiver in range and thus would obscure the intent of the figure. 348 Figure 4 shows, as context, some entities and interfaces beyond the 349 scope of DRIP (as currently (2022) chartered). 351 *************** *************** 352 * UAS1 * * UAS2 * 353 * * * * 354 * +--------+ * DAA/V2V * +--------+ * 355 * | UA o--*----------------------------------------*--o UA | * 356 * +--o--o--+ * * +--o--o--+ * 357 * | | * +------+ Lookups +------+ * | | * 358 * | | * | GPOD o------. .------o PSOD | * | | * 359 * | | * +------+ | | +------+ * | | * 360 * | | * | | * | | * 361 * C2 | | * V2I ************ V2I * | | C2 * 362 * | '-----*--------------* *--------------*-----' | * 363 * | * * * * | * 364 * | o====Net-RID===* *====Net-RID===o | * 365 * +--o--+ * * Internet * * +--o--+ * 366 * | GCS o-----*--------------* *--------------*-----o GCS | * 367 * +-----+ * Registration * * Registration * +-----+ * 368 * * (and UTM) * * (and UTM) * * 369 *************** ************ *************** 370 | | | 371 +----------+ | | | +----------+ 372 | Public o---' | '---o Private | 373 | Registry | | | Registry | 374 +----------+ | +----------+ 375 +--o--+ 376 | DNS | 377 +-----+ 379 DAA: Detect And Avoid 380 GPOD: General Public Observer Device 381 PSOD: Public Safety Observer Device 382 V2I: Vehicle-to-Infrastructure 383 V2V: Vehicle-to-Vehicle 385 Figure 4 387 DRIP is meant to leverage existing Internet resources (standard 388 protocols, services, infrastructures, and business models) to meet 389 UAS RID and closely related needs. DRIP will specify how to apply 390 IETF standards, complementing [F3411] and other external standards, 391 to satisfy UAS RID requirements. 393 This document outlines the DRIP architecture in the context of the 394 UAS RID architecture. This includes presenting the gaps between the 395 CAAs' Concepts of Operations and [F3411] as it relates to the use of 396 Internet technologies and UA direct RF communications. Issues 397 include, but are not limited to: 399 - Design of trustworthy remote identifiers (Section 3). 401 - Mechanisms to leverage Domain Name System (DNS [RFC1034]), 402 Extensible Provisioning Protocol (EPP [RFC5731]) and 403 Registration Data Access Protocol (RDAP) ([RFC9082]) for 404 publishing public and private information (see Section 4.1 and 405 Section 4.2). 407 - Specific authentication methods and message payload formats to 408 enable verification that Broadcast RID messages were sent by 409 the claimed sender (Section 5) and that sender is in the 410 claimed registry (Section 4 and Section 5). 412 - Harvesting Broadcast RID messages for UTM inclusion, with the 413 optional DRIP extension of Crowd Sourced Remote ID (CS-RID, 414 Section 6), using the DRIP support for gateways required by 415 GEN-5 [RFC9153]. 417 - Methods for instantly establishing secure communications 418 between an Observer and the pilot of an observed UAS 419 (Section 7), using the DRIP support for dynamic contact 420 required by GEN-4 [RFC9153]. 422 - Privacy in UAS RID messages (PII protection) (Section 9). 424 2. Terms and Definitions 426 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 427 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 428 "OPTIONAL" in this document are to be interpreted as described in BCP 429 14 [RFC2119] [RFC8174] when, and only when, they appear in all 430 capitals, as shown here. 432 To encourage comprehension necessary for adoption of DRIP by the 433 intended user community, the UAS community's norms are respected 434 herein. 436 This document uses terms defined in [RFC9153]. 438 2.1. Additional Abbreviations 440 DET: DRIP Entity Tag 442 EdDSA: Edwards-Curve Digital Signature Algorithm 444 HHIT: Hierarchical HIT 446 HI: Host Identity 447 HIP: Host Identity Protocol 449 HIT: Host Identity Tag 451 2.2. Additional Definitions 453 This section introduces the terms "Claims", "Assertions", 454 "Attestations", and "Certificates" as used in DRIP. DRIP certificate 455 has a different context compared with security certificates and 456 Public Key Infrastructure used in X.509. 458 Claims: 460 A claim in DRIP is a predicate (e.g., "X is Y", "X has property 461 Y", and most importantly "X owns Y" or "X is owned by Y"). 463 Assertions: 465 An assertion in DRIP is a set of claims. This definition is 466 borrowed from JWT [RFC7519] and CWT [RFC8392]. 468 Attestations: 470 An attestation in DRIP is a signed assertion. The signer may be 471 the claimant or a related party with stake in the assertion(s). 472 Under DRIP this is normally used when an entity asserts a 473 relationship with another entity, along with other information, 474 and the asserting entity signs the assertion, thereby making it an 475 attestation. 477 Certificates: 479 A certificate in DRIP is an attestation, strictly over identity 480 information, signed by a third party. This third party should be 481 one with no stake in the attestation(s) over which it is signing. 483 3. HHIT as the DRIP Entity Identifier 485 This section describes the DRIP architectural approach to meeting the 486 basic requirements of a DRIP entity identifier within external 487 technical standard ASTM [F3411] and regulatory constraints. It 488 justifies and explains the use of Hierarchical Host Identity Tags 489 (HHITs) [RFC7401] as self-asserting IPv6 addresses suitable as a UAS 490 ID type and, more generally, as trustworthy multipurpose remote 491 identifiers. 493 Self-asserting in this usage means that, given the Host Identity 494 (HI), the HHIT ORCHID construction and a signature of the registry on 495 the HHIT, the HHIT can be verified by the receiver. The explicit 496 registration hierarchy within the HHIT provides registry discovery 497 (managed by a Registrar) to either yield the HI for a 3rd-party 498 (seeking UAS ID attestation) validation or prove that the HHIT and HI 499 have been registered uniquely. 501 3.1. UAS Remote Identifiers Problem Space 503 A DRIP entity identifier needs to be "Trustworthy" (See DRIP 504 Requirement GEN-1, ID-4 and ID-5 in [RFC9153]). This means that 505 given a sufficient collection of UAS RID messages, an Observer can 506 establish that the identifier claimed therein uniquely belongs to the 507 claimant. To satisfy DRIP requirements and maintain important 508 security properties, the DRIP identifier should be self-generated by 509 the entity it names (e.g., a UAS) and registered (e.g., with a USS, 510 see Requirements GEN-3 and ID-2). 512 Broadcast RID, especially its support for Bluetooth 4.x, imposes 513 severe constraints. ASTM UAS RID [F3411] allows a UAS ID of types 1, 514 2 and 3 of 20 bytes; a revision to [F3411], currently in balloting 515 (as of Oct 2021), adds type 4, Specific Session ID, to be 516 standardized by IETF and other standards development organizations 517 (SDOs) as extensions to ASTM UAS RID, consumes one of those bytes to 518 index the sub-type, leaving only 19 for the identifier (see DRIP 519 Requirement ID-1). 521 Likewise, the maximum ASTM UAS RID [F3411] Authentication Message 522 payload is 201 bytes for most authentication types. A type 5 is also 523 added in this revision for IETF and other SDOs to develop Specific 524 Authentication Methods as extensions to ASTM UAS RID. One byte out 525 of 201 bytes is consumed to index the sub-type which leaves only 200 526 for DRIP authentication payloads, including one or more DRIP entity 527 identifiers and associated authentication data. 529 3.2. HHIT as A Trustworthy DRIP Entity Identifier 531 A Remote UAS ID that can be trustworthy for use in Broadcast RID can 532 be built from an asymmetric keypair. In this method, the UAS ID is 533 cryptographically derived directly from the public key. The proof of 534 UAS ID ownership (verifiable attestation, versus mere claim) is 535 guaranteed by signing this cryptographic UAS ID with the associated 536 private key. The association between the UAS ID and the private key 537 is ensured by cryptographically binding the public key with the UAS 538 ID; more specifically, the UAS ID results from the hash of the public 539 key. The public key is designated as the HI while the UAS ID is 540 designated as the HIT. 542 By construction, the HIT is statistically unique through the 543 cryptographic hash feature of second-preimage resistance. The 544 cryptographically-bound addition of the Hierarchy and an HHIT 545 registration process provide complete, global HHIT uniqueness. This 546 registration forces the attacker to generate the same public key 547 rather than a public key that generates the same HHIT. This is in 548 contrast to general IDs (e.g., a UUID or device serial number) as the 549 subject in an X.509 certificate. 551 A UA equipped for Broadcast RID MUST be provisioned not only with its 552 HHIT but also with the HI public key from which the HHIT was derived 553 and the corresponding private key, to enable message signature. A 554 UAS equipped for Network RID SHOULD be provisioned likewise; the 555 private key resides only in the ultimate source of Network RID 556 messages (i.e., on the UA itself if the GCS is merely relaying rather 557 than sourcing Network RID messages). Each Observer device SHOULD be 558 provisioned either with public keys of the DRIP identifier root 559 registries or certificates for subordinate registries. 561 HHITs can also be used throughout the USS/UTM system. Operators and 562 Private Information Registries, as well as other UTM entities, can 563 use HHITs for their IDs. Such HHITs can facilitate DRIP security 564 functions such as used with HIP to strongly mutually authenticate and 565 encrypt communications. 567 A self-attestation of a HHIT used as a UAS ID can be done in as 568 little as 84 bytes when Ed25519 [RFC8032] is used, by avoiding an 569 explicit encoding technology like ASN.1 or Concise Binary Object 570 Representation (CBOR [RFC8949]). This attestation consists of only 571 the HHIT, a timestamp, and the EdDSA signature on them. 573 Ed25519 [RFC8032] is used as the HHIT signing algorithm as [RFC9153] 574 GEN-1 and ID-5 can best be met by restricting the HI to 32 bytes. A 575 larger public key would rule out the offline attestation feature that 576 fits within the 200-byte Authentication Message maximum length. 577 Other algorithms that meet this 32 byte constraint can be added as 578 deemed needed. 580 A DRIP identifier can be assigned to a UAS as a static HHIT by its 581 manufacturer, such as a single HI and derived HHIT encoded as a 582 hardware serial number per [CTA2063A]. Such a static HHIT SHOULD 583 only be used to bind one-time use DRIP identifiers to the unique UA. 584 Depending upon implementation, this may leave a HI private key in the 585 possession of the manufacturer (see also Section 8). 587 In general, Internet access may be needed to validate Attestations or 588 Certificates. This may be obviated in the most common cases (e.g., 589 attestation of the UAS ID), even in disconnected environments, by 590 prepopulating small caches on Observer devices with Registry public 591 keys and a chain of Attestations or Certificates (tracing a path 592 through the Registry tree). This is assuming all parties on the 593 trust path also use HHITs for their identities. 595 3.3. HHIT for DRIP Identifier Registration and Lookup 597 UAS RID needs a deterministic lookup mechanism that rapidly provides 598 actionable information about the identified UA. Given the size 599 constraints imposed by the Bluetooth 4 broadcast media, the UAS ID 600 itself needs to be a non-spoofable inquiry input into the lookup. 602 A DRIP registration process based on the explicit hierarchy within a 603 HHIT provides manageable uniqueness of the HI for the HHIT. This is 604 the defense against a cryptographic hash second pre-image attack on 605 the HHIT (e.g., multiple HIs yielding the same HHIT, see Requirement 606 ID-3). A lookup of the HHIT into this registration data provides the 607 registered HI for HHIT proof of ownership. A first-come-first-served 608 registration for a HHIT provides deterministic access to any other 609 needed actionable information based on inquiry access authority (more 610 details in Section 4.2). 612 3.4. HHIT as a Cryptographic Identifier 614 The only (known to the authors at the time of this writing) existing 615 types of IP address compatible identifiers cryptographically derived 616 from the public keys of the identified entities are Cryptographically 617 Generated Addresses (CGAs) [RFC3972] and Host Identity Tags (HITs) 618 [RFC7401]. CGAs and HITs lack registration/retrieval capability. To 619 provide this, each HHIT embeds plaintext information designating the 620 hierarchy within which it is registered and a cryptographic hash of 621 that information concatenated with the entity's public key, etc. 622 Although hash collisions may occur, the registrar can detect them and 623 reject registration requests rather than issue credentials, e.g., by 624 enforcing a first-claimed, first-attested policy. Pre-image hash 625 attacks are also mitigated through this registration process, locking 626 the HHIT to a specific HI 628 4. DRIP Identifier Registration and Registries 630 DRIP registries [I-D.ietf-drip-registries] hold both public and 631 private UAS information (See PRIV-1 in [RFC9153]) resulting from the 632 DRIP identifier registration process. Given these different uses, 633 and to improve scalability, security, and simplicity of 634 administration, the public and private information can be stored in 635 different registries. This section introduces the public and private 636 information registries for DRIP identifiers. This DRIP Identifier 637 registration process satisfies the following DRIP requirements 638 defined in [RFC9153]: GEN-3, GEN-4, ID-2, ID-4, ID-6, PRIV-3, PRIV-4, 639 REG-1, REG-2, REG-3 and REG-4. 641 4.1. Public Information Registry 643 4.1.1. Background 645 The public information registry provides trustable information such 646 as attestations of UAS RID ownership and registration with the HDA 647 (Hierarchical HIT Domain Authority). Optionally, pointers to the 648 registries for the HDA and RAA (Registered Assigning Authority) 649 implicit in the UAS RID can be included (e.g., for HDA and RAA 650 HHIT|HI used in attestation signing operations). This public 651 information will be principally used by Observers of Broadcast RID 652 messages. Data on UAS that only use Network RID, is available via an 653 Observer's Net-RID DP that would directly provide all public 654 information registry information. The Net-RID DP is the only source 655 of information for a query on an airspace volume. 657 4.1.2. DNS as the Public DRIP Identifier Registry 659 A DRIP identifier SHOULD be registered as an Internet domain name (at 660 an arbitrary level in the hierarchy, e.g., in .ip6.arpa). Thus DNS 661 can provide all the needed public DRIP information. A standardized 662 HHIT FQDN (Fully Qualified Domain Name) can deliver the HI via a HIP 663 RR (Resource Record) [RFC8005] and other public information (e.g., 664 RRA and HDA PTRs, and HIP RVS (Rendezvous Servers) [RFC8004]). These 665 public information registries can use secure DNS transport (e.g., DNS 666 over TLS) to deliver public information that is not inherently 667 trustable (e.g., everything other than attestations). 669 This DNS entry for the HHIT can also provide a revocation service. 670 For example, instead of returning the HI RR it may return some record 671 showing that the HI (and thus HHIT) has been revoked. 673 4.2. Private Information Registry 675 4.2.1. Background 677 The private information required for DRIP identifiers is similar to 678 that required for Internet domain name registration. A DRIP 679 identifier solution can leverage existing Internet resources: 680 registration protocols, infrastructure, and business models, by 681 fitting into an UAS ID structure compatible with DNS names. The HHIT 682 hierarchy can provide the needed scalability and management 683 structure. It is expected that the private information registry 684 function will be provided by the same organizations that run a USS, 685 and likely integrated with a USS. The lookup function may be 686 implemented by the Net-RID DPs. 688 4.2.2. EPP and RDAP as the Private DRIP Identifier Registry 690 A DRIP private information registry supports essential registry 691 operations (e.g., add, delete, update, query) using interoperable 692 open standard protocols. It can accomplish this by using the 693 Extensible Provisioning Protocol (EPP [RFC5730]) and the Registry 694 Data Access Protocol (RDAP [RFC7480] [RFC9082] [RFC9083]). The DRIP 695 private information registry in which a given UAS is registered needs 696 to be findable, starting from the UAS ID, using the methods specified 697 in [RFC7484]. 699 4.2.3. Alternative Private DRIP Registry methods 701 A DRIP private information registry might be an access-controlled DNS 702 (e.g., via DNS over TLS). Additionally, WebFinger [RFC7033] can be 703 deployed. These alternative methods may be used by Net-RID DP with 704 specific customers. 706 5. DRIP Identifier Trust 708 While the DRIP entity identifier is self-asserting, it alone does not 709 provide the trustworthiness (non-repudiability, protection vs. 710 spoofing, message integrity protection, scalability, etc.) essential 711 to UAS RID, as justified in [RFC9153]. For that it MUST be 712 registered (under DRIP Registries) and be actively used by the party 713 (in most cases the UA). A sender's identity can not be approved by 714 only possessing a DRIP Entity Tag (DET), which is an HHIT-based UA ID 715 and broadcasting a claim that it belongs to that sender. Even the 716 sender using that HI's private key to sign static data proves nothing 717 as well, as it is subject to trivial replay attacks. Only sending 718 the DET and a signature on frequently changing data that can be 719 sanity-checked by the Observer (such as a Location/Vector message) 720 proves that the observed UA possesses the claimed UAS ID. 722 For Broadcast RID, it is a challenge to balance the original 723 requirements of Broadcast RID and the efforts needed to satisfy the 724 DRIP requirements all under severe constraints. From received 725 Broadcast RID messages and information that can be looked up using 726 the received UAS ID in online registries or local caches, it is 727 possible to establish levels of trust in the asserted information and 728 the Operator. 730 Optimization of different DRIP Authentication Messages allows an 731 Observer, without Internet connection (offline) or with (online), to 732 be able to validate a UAS DRIP ID in real-time. First is the sending 733 of Broadcast Attestations (over DRIP Link Authentication Messages) 735 [I-D.ietf-drip-auth] containing the relevant registration of the UA's 736 DRIP ID in the claimed Registry. Next is sending DRIP Wrapper 737 Authentication Messages that sign over both static (e.g., above 738 registration) and dynamically changing data (such as UA location 739 data). Combining these two sets of information, an Observer can 740 piece together a chain of trust and real-time evidence to make their 741 determination of the UA's claims. 743 This process (combining the DRIP entity identifier, Registries and 744 Authentication Formats for Broadcast RID) can satisfy the following 745 DRIP requirement defined in [RFC9153]: GEN-1, GEN-2, GEN-3, ID-2, ID- 746 3, ID-4 and ID-5. 748 6. Harvesting Broadcast Remote ID messages for UTM Inclusion 750 ASTM anticipated that regulators would require both Broadcast RID and 751 Network RID for large UAS, but allow UAS RID requirements for small 752 UAS to be satisfied with the operator's choice of either Broadcast 753 RID or Network RID. The EASA initially specified Broadcast RID for 754 essentially all UAS, and is now also considering Network RID. The 755 FAA UAS RID Final Rules [FAA_RID] permit only Broadcast RID for rule 756 compliance, but still encourage Network RID for complementary 757 functionality, especially in support of UTM. 759 One opportunity is to enhance the architecture with gateways from 760 Broadcast RID to Network RID. This provides the best of both and 761 gives regulators and operators flexibility. It offers advantages 762 over either form of UAS RID alone: greater fidelity than Network RID 763 reporting of planned area operations; surveillance of areas too large 764 for local direct visual observation and direct RF-LOS link based 765 Broadcast RID (e.g., a city or a national forest). 767 These gateways could be pre-positioned (e.g., around airports, public 768 gatherings, and other sensitive areas) and/or crowd-sourced (as 769 nothing more than a smartphone with a suitable app is needed). As 770 Broadcast RID media have limited range, gateways receiving messages 771 claiming locations far from the gateway can alert authorities or a 772 SDSP to the failed sanity check possibly indicating intent to 773 deceive. Surveillance SDSPs can use messages with precise date/time/ 774 position stamps from the gateways to multilaterate UA location, 775 independent of the locations claimed in the messages, which are 776 entirely operator self-reported in UAS RID and UTM, and thus are 777 subject not only to natural time lag and error but also operator 778 misconfiguration or intentional deception. 780 Multilateration technologies use physical layer information, such as 781 precise Time Of Arrival (TOA) of transmissions from mobile 782 transmitters at receivers with a priori precisely known locations, to 783 estimate the locations of the mobile transmitters. 785 Further, gateways with additional sensors (e.g., smartphones with 786 cameras) can provide independent information on the UA type and size, 787 confirming or refuting those claims made in the UAS RID messages. 789 Section 6.1 and Section 6.2 define two additional entities that are 790 required to provide this Crowd Sourced Remote ID (CS-RID). 792 This approach satisfies the following DRIP requirements defined in 793 [RFC9153]: GEN-5, GEN-11, and REG-1. As Broadcase messages are 794 inherently multicast, GEN-10 is met for local-link multicast to 795 multiple Finders (how multilateration is possible). 797 6.1. The CS-RID Finder 799 A CS-RID Finder is the gateway for Broadcast Remote ID Messages into 800 UTM. It performs this gateway function via a CS-RID SDSP. A CS-RID 801 Finder could implement, integrate, or accept outputs from a Broadcast 802 RID receiver. However, it should not depend upon a direct interface 803 with a GCS, Net-RID SP, Net-RID DP or Network RID client. It would 804 present a new interface to a CS-RID SDSP, similar to but readily 805 distinguishable from that between a GCS and a Net-RID SP. 807 6.2. The CS-RID SDSP 809 A CS-RID SDSP aggregates and processes (e.g., estimates UA location 810 using multilateration when possible) information collected by CS-RID 811 Finders. A CS-RID SDSP should appear (i.e., present the same 812 interface) to a Net-RID SP as a Net-RID DP. 814 7. DRIP Contact 816 One of the ways in which DRIP can enhance [F3411] with immediately 817 actionable information is by enabling an Observer to instantly 818 initiate secure communications with the UAS remote pilot, Pilot In 819 Command, operator, USS under which the operation is being flown, or 820 other entity potentially able to furnish further information 821 regarding the operation and its intent and/or to immediately 822 influence further conduct or termination of the operation (e.g., land 823 or otherwise exit an airspace volume). Such potentially distracting 824 communications demand strong "AAA" (Authentication, Attestation, 825 Authorization, Access Control, Accounting, Attribution, Audit) per 826 applicable policies (e.g., of the cognizant CAA). 828 A DRIP entity identifier based on a HHIT as outlined in Section 3 829 embeds an identifier of the registry in which it can be found 830 (expected typically to be the USS under which the UAS is flying) and 831 the procedures outlined in Section 5 enable Observer verification of 832 that relationship. A DRIP entity identifier with suitable records in 833 public and private registries as outlined in Section 5 can enable 834 lookup not only of information regarding the UAS, but also identities 835 of and pointers to information regarding the various associated 836 entities (e.g., the USS under which the UAS is flying an operation), 837 including means of contacting those associated entities (i.e., 838 locators, typically IP addresses). 840 A suitably equipped Observer could initiate a cryptographic handshake 841 to a similarly equipped and identified entity: the UA itself, if 842 operating autonomously; the GCS, if the UA is remotely piloted and 843 the necessary records have been populated in DNS; the USS, etc. 844 Assuming mutual authentication is successful, keys can then be 845 negotiated for an IPsec Encapsulating Security Payload (ESP) tunnel, 846 over which arbitrary standard higher layer protocols can then be used 847 for Observer to Pilot (O2P)communications (e.g., SIP [RFC3261] et 848 seq), V2X communications (e.g., [MAVLink]), etc. Certain 849 preconditions are necessary: each party needs a currently usable 850 means (typically DNS) of resolving the other party's DRIP entity 851 identifier to a currently usable locator (IP address); and there must 852 be currently usable bidirectional IP (not necessarily Internet) 853 connectivity between the parties. One method directly supported by 854 the use of HHITs as DRIP entity identifiers is initiation of a HIP 855 Base Exchange (BEX) and Bound End-to-End Tunnel (BEET). 857 This approach satisfies DRIP requirement GEN-6 Contact, supports 858 satisfaction of requirements [RFC9153] GEN-8, GEN-9, PRIV-2, PRIV-5 859 and REG-3, and is compatible with all other DRIP requirements. 861 8. Security Considerations 863 The size of the public key hash in the HHIT is vulnerable to a 864 second-image attack. It is well within current server array 865 technology to compute another key pair that hashes to the same HHIT. 866 Thus, if a receiver were to check HHIT validity only by verifying 867 that the received HI and associated information, when hashed in the 868 ORCHID construction, reproduce the received HHIT, an adversary could 869 impersonate a validly registered UA. To defend against this, on-line 870 receivers should verify the received HHIT and received HI with the 871 USS with which the HHIT purports to be registered. On-line and off- 872 line receivers can use a chain of received DRIP link attestations 873 from a root of trust through the RAA and the HDA to the UA, as 874 described in [I-D.ietf-drip-auth] and [I-D.ietf-drip-registries]. 876 Compromise of a registry private key could do widespread harm. Key 877 revocation procedures are as yet to be determined. These risks are 878 in addition to those involving Operator key management practices and 879 will be addressed as part of the registry process. 881 8.1. Private Key Physical Security 883 The security provided by asymmetric cryptographic techniques depends 884 upon protection of the private keys. It may be necessary for the GCS 885 to have the key pair to register the HHIT to the USS. Thus it may be 886 the GCS that generates the key pair and delivers it to the UA, making 887 the GCS a part of the key security boundary. Leakage of the private 888 key either from the UA or GCS to the component manufacturer is a 889 valid concern and steps need to be in place to ensure safe keeping of 890 the private key. 892 Since it is possible for the UAS RID sender of a small harmless UA 893 (or the entire UA) to be carried by a larger dangerous UA as a "false 894 flag", it is out of scope to deal wtih secure store for the private 895 key. 897 8.2. Post Quantum Computing Out Of Scope 899 There has been no effort, at this time, to address post quantum 900 computing cryptography. UAs and Broadcast Remote ID communications 901 are so constrained that current post quantum computing cryptography 902 is not applicable. Plus since a UA may use a unique HHIT for each 903 operation, the attack window could be limited to the duration of the 904 operation. 906 Finally, as the HHIT contains the ID for the cryptographic suite used 907 in its creation, a future post quantum computing safe algorithm that 908 fits the Remote ID constraints may readily be added. 910 8.3. Denial Of Service (DOS) Protection Out Of Scope 912 Remote ID services from the UA use a wireless link in a public space. 913 As such, they are open to many forms of RF jamming. It is trivial 914 for an attacker to stop any UA messages from reaching a wireless 915 receiver. Thus it is pointless to attempt to provide relief from DOS 916 attacks as there is always the ultimate RF jamming attack. Subtle 917 DOS attacks of message content altering are not practical with the 918 basic message error correction provided. Finally, this whole 919 architecture is put forth to make DOS spoofing/replay attacks very 920 hard. 922 9. Privacy & Transparency Considerations 924 Broadcast RID messages can contain Personally Identifiable 925 Information (PII). A viable architecture for PII protection would be 926 symmetric encryption of the PII using a session key known to the UAS 927 and its USS. Authorized Observers could obtain plaintext in either 928 of two ways. An Observer can send the UAS ID and the cyphertext to a 929 server that offers decryption as a service. An Observer can send the 930 UAS ID only to a server that returns the session key, so that 931 Observer can directly locally decrypt all cyphertext sent by that UA 932 during that session (UAS operation). In either case, the server can 933 be: a Public Safety USS, the Observer's own USS, or the UA's USS if 934 the latter can be determined (which under DRIP it can be, from the 935 UAS ID itself). PII can be protected unless the UAS is informed 936 otherwise. This could come as part of UTM operation authorization. 937 It can be special instructions at the start or during an operation. 938 PII protection MUST NOT be used if the UAS loses connectivity to the 939 USS. The UAS always has the option to abort the operation if PII 940 protection is disallowed. 942 10. References 944 10.1. Normative References 946 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 947 Requirement Levels", BCP 14, RFC 2119, 948 DOI 10.17487/RFC2119, March 1997, 949 . 951 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 952 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 953 May 2017, . 955 [RFC9153] Card, S., Ed., Wiethuechter, A., Moskowitz, R., and A. 956 Gurtov, "Drone Remote Identification Protocol (DRIP) 957 Requirements and Terminology", RFC 9153, 958 DOI 10.17487/RFC9153, February 2022, 959 . 961 10.2. Informative References 963 [CTA2063A] ANSI, "Small Unmanned Aerial Systems Serial Numbers", 964 2019. 966 [Delegated] 967 European Union Aviation Safety Agency (EASA), "EU 968 Commission Delegated Regulation 2019/945 of 12 March 2019 969 on unmanned aircraft systems and on third-country 970 operators of unmanned aircraft systems", 2019, 971 . 974 [F3411] ASTM International, "Standard Specification for Remote ID 975 and Tracking", February 2020, 976 . 978 [FAA_RID] United States Federal Aviation Administration (FAA), 979 "Remote Identification of Unmanned Aircraft", 2021, 980 . 983 [FAA_UAS_Concept_Of_Ops] 984 United States Federal Aviation Administration (FAA), 985 "Unmanned Aircraft System (UAS) Traffic Management (UTM) 986 Concept of Operations (V2.0)", 2020, 987 . 990 [FS_AEUA] "Study of Further Architecture Enhancement for UAV and 991 UAM", 2021, . 994 [I-D.ietf-drip-auth] 995 Wiethuechter, A., Card, S., and R. Moskowitz, "DRIP Entity 996 Tag Authentication Formats & Protocols for Broadcast 997 Remote ID", Work in Progress, Internet-Draft, draft-ietf- 998 drip-auth-12, 25 May 2022, 999 . 1002 [I-D.ietf-drip-registries] 1003 Wiethuechter, A., Card, S., Moskowitz, R., and J. Reid, 1004 "DRIP Entity Tag Registration & Lookup", Work in Progress, 1005 Internet-Draft, draft-ietf-drip-registries-03, 11 May 1006 2022, . 1009 [Implementing] 1010 European Union Aviation Safety Agency (EASA), "EU 1011 Commission Implementing Regulation 2019/947 of 24 May 2019 1012 on the rules and procedures for the operation of unmanned 1013 aircraft", 2019, . 1016 [Implementing_update] 1017 European Union Aviation Safety Agency (EASA), "EU 1018 COMMISSION IMPLEMENTING REGULATION (EU) 2021/664 of 22 1019 April 2021 on a regulatory framework for the U-space", 1020 2021, . 1023 [LAANC] United States Federal Aviation Administration (FAA), "Low 1024 Altitude Authorization and Notification Capability", n.d., 1025 . 1028 [MAVLink] "Micro Air Vehicle Communication Protocol", 2021, 1029 . 1031 [NPA] European Union Aviation Safety Agency (EASA), "Notice of 1032 Proposed Amendment 2021-14 Development of acceptable means 1033 of compliance and guidance material to support the U-space 1034 regulation", 2021, 1035 . 1037 [NPRM] United States Federal Aviation Administration (FAA), 1038 "Notice of Proposed Rule Making on Remote Identification 1039 of Unmanned Aircraft Systems", 2019. 1041 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1042 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1043 . 1045 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1046 A., Peterson, J., Sparks, R., Handley, M., and E. 1047 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1048 DOI 10.17487/RFC3261, June 2002, 1049 . 1051 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1052 RFC 3972, DOI 10.17487/RFC3972, March 2005, 1053 . 1055 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1056 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 1057 . 1059 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1060 Domain Name Mapping", STD 69, RFC 5731, 1061 DOI 10.17487/RFC5731, August 2009, 1062 . 1064 [RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr, 1065 "WebFinger", RFC 7033, DOI 10.17487/RFC7033, September 1066 2013, . 1068 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 1069 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 1070 RFC 7401, DOI 10.17487/RFC7401, April 2015, 1071 . 1073 [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the 1074 Registration Data Access Protocol (RDAP)", STD 95, 1075 RFC 7480, DOI 10.17487/RFC7480, March 2015, 1076 . 1078 [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data 1079 (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March 1080 2015, . 1082 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1083 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1084 . 1086 [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 1087 Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, 1088 October 2016, . 1090 [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name 1091 System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, 1092 October 2016, . 1094 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 1095 Signature Algorithm (EdDSA)", RFC 8032, 1096 DOI 10.17487/RFC8032, January 2017, 1097 . 1099 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 1100 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 1101 May 2018, . 1103 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 1104 Representation (CBOR)", STD 94, RFC 8949, 1105 DOI 10.17487/RFC8949, December 2020, 1106 . 1108 [RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access 1109 Protocol (RDAP) Query Format", STD 95, RFC 9082, 1110 DOI 10.17487/RFC9082, June 2021, 1111 . 1113 [RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the 1114 Registration Data Access Protocol (RDAP)", STD 95, 1115 RFC 9083, DOI 10.17487/RFC9083, June 2021, 1116 . 1118 [TS-22.825] 1119 3GPP, "Study on Remote Identification of Unmanned Aerial 1120 Systems (UAS)", n.d., 1121 . 1124 [U-Space] European Organization for the Safety of Air Navigation 1125 (EUROCONTROL), "U-space Concept of Operations", 2019, 1126 . 1129 Appendix A. Overview of Unmanned Aircraft Systems (UAS) Traffic 1130 Management (UTM) 1132 A.1. Operation Concept 1134 The National Aeronautics and Space Administration (NASA) and FAA's 1135 effort to integrate UAS operations into the national airspace system 1136 (NAS) led to the development of the concept of UTM and the ecosystem 1137 around it. The UTM concept was initially presented in 2013 and 1138 version 2.0 was published in 2020 [FAA_UAS_Concept_Of_Ops]. 1140 The eventual concept refinement, initial prototype implementation, 1141 and testing were conducted by the joint FAA and NASA UTM research 1142 transition team. World efforts took place afterward. The Single 1143 European Sky ATM Research (SESAR) started the CORUS project to 1144 research its UTM counterpart concept, namely [U-Space]. This effort 1145 is led by the European Organization for the Safety of Air Navigation 1146 (Eurocontrol). 1148 Both NASA and SESAR have published their UTM concepts of operations 1149 to guide the development of their future air traffic management (ATM) 1150 system and ensure safe and efficient integration of manned and 1151 unmanned aircraft into the national airspace. 1153 UTM comprises UAS operations infrastructure, procedures and local 1154 regulation compliance policies to guarantee safe UAS integration and 1155 operation. The main functionality of UTM includes, but is not 1156 limited to, providing means of communication between UAS operators 1157 and service providers and a platform to facilitate communication 1158 among UAS service providers. 1160 A.2. UAS Service Supplier (USS) 1162 A USS plays an important role to fulfill the key performance 1163 indicators (KPIs) that UTM has to offer. Such an Entity acts as a 1164 proxy between UAS operators and UTM service providers. It provides 1165 services like real-time UAS traffic monitoring and planning, 1166 aeronautical data archiving, airspace and violation control, 1167 interacting with other third-party control entities, etc. A USS can 1168 coexist with other USS to build a large service coverage map that can 1169 load-balance, relay, and share UAS traffic information. 1171 The FAA works with UAS industry shareholders and promotes the Low 1172 Altitude Authorization and Notification Capability [LAANC] program, 1173 which is the first system to realize some of the envisioned 1174 functionality of UTM. The LAANC program can automate UAS operational 1175 intent (flight plan) submission and application for airspace 1176 authorization in real-time by checking against multiple aeronautical 1177 databases such as airspace classification and operating rules 1178 associated with it, FAA UAS facility map, special use airspace, 1179 Notice to Airmen (NOTAM), and Temporary Flight Restriction (TFR). 1181 A.3. UTM Use Cases for UAS Operations 1183 This section illustrates a couple of use case scenarios where UAS 1184 participation in UTM has significant safety improvement. 1186 1. For a UAS participating in UTM and taking off or landing in 1187 controlled airspace (e.g., Class Bravo, Charlie, Delta, and Echo 1188 in the United States), the USS under which the UAS is operating 1189 is responsible for verifying UA registration, authenticating the 1190 UAS operational intent (flight plan) by checking against 1191 designated UAS facility map database, obtaining the air traffic 1192 control (ATC) authorization, and monitoring the UAS flight path 1193 in order to maintain safe margins and follow the pre-authorized 1194 sequence of authorized 4-D volumes (route). 1196 2. For a UAS participating in UTM and taking off or landing in 1197 uncontrolled airspace (e.g., Class Golf in the United States), 1198 pre-flight authorization must be obtained from a USS when 1199 operating beyond-visual-of-sight (BVLOS). The USS either accepts 1200 or rejects the received operational intent (flight plan) from the 1201 UAS. Accepted UAS operation may share its current flight data 1202 such as GPS position and altitude to USS. The USS may keep the 1203 UAS operation status near real-time and may keep it as a record 1204 for overall airspace air traffic monitoring. 1206 Appendix B. Automatic Dependent Surveillance Broadcast (ADS-B) 1208 The ADS-B is the de jure technology used in manned aviation for 1209 sharing location information, from the aircraft to ground and 1210 satellite-based systems, designed in the early 2000s. Broadcast RID 1211 is conceptually similar to ADS-B, but with the receiver target being 1212 the general public on generally available devices (e.g., 1213 smartphones). 1215 For numerous technical reasons, ADS-B itself is not suitable for low- 1216 flying small UAS. Technical reasons include but not limited to the 1217 following: 1219 1. Lack of support for the 1090 MHz ADS-B channel on any consumer 1220 handheld devices 1222 2. Weight and cost of ADS-B transponders on CSWaP constrained UA 1224 3. Limited bandwidth of both uplink and downlink, which would likely 1225 be saturated by large numbers of UAS, endangering manned aviation 1227 Understanding these technical shortcomings, regulators worldwide have 1228 ruled out the use of ADS-B for the small UAS for which UAS RID and 1229 DRIP are intended. 1231 Acknowledgements 1233 The work of the FAA's UAS Identification and Tracking (UAS ID) 1234 Aviation Rulemaking Committee (ARC) is the foundation of later ASTM 1235 and proposed IETF DRIP WG efforts. The work of ASTM F38.02 in 1236 balancing the interests of diverse stakeholders is essential to the 1237 necessary rapid and widespread deployment of UAS RID. Thanks to 1238 Alexandre Petrescu and Stephan Wenger for the helpful and positive 1239 comments. Thanks to chairs Daniel Migault and Mohamed Boucadair for 1240 direction of our team of authors and editor, some of whom are 1241 newcomers to writing IETF documents. Laura Welch is also thanked for 1242 her valuable review comments that led to great improvements of this 1243 memo. Thanks especially to Internet Area Director Eric Vyncke for 1244 guidance and support. 1246 Authors' Addresses 1248 Stuart W. Card 1249 AX Enterprize 1250 4947 Commercial Drive 1251 Yorkville, NY, 13495 1252 United States of America 1253 Email: stu.card@axenterprize.com 1254 Adam Wiethuechter 1255 AX Enterprize 1256 4947 Commercial Drive 1257 Yorkville, NY, 13495 1258 United States of America 1259 Email: adam.wiethuechter@axenterprize.com 1261 Robert Moskowitz 1262 HTT Consulting 1263 Oak Park, MI, 48237 1264 United States of America 1265 Email: rgm@labs.htt-consult.com 1267 Shuai Zhao 1268 Tencent 1269 2747 Park Blvd 1270 Palo Alto, 94588 1271 United States of America 1272 Email: shuai.zhao@ieee.org 1274 Andrei Gurtov 1275 Linköping University 1276 IDA 1277 SE-58183 Linköping Linköping 1278 Sweden 1279 Email: gurtov@acm.org