idnits 2.17.1 draft-ietf-drip-arch-17.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 363 has weird spacing: '...perator xxxxx...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Broadcast RID messages can contain Personally Identifiable Information (PII). A viable architecture for PII protection would be symmetric encryption of the PII using a session key known to the UAS and its USS. Authorized Observers could obtain plaintext in either of two ways. An Observer can send the UAS ID and the cyphertext to a server that offers decryption as a service. An Observer can send the UAS ID only to a server that returns the session key, so that 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 it can be, from the UAS ID itself). PII can be protected unless the UAS is informed otherwise. This could come as part of UTM operation authorization. It can be special instructions at the start or during an operation. PII protection MUST not be used if the UAS loses connectivity to the USS. The UAS always has the option to abort the operation if PII protection is disallowed. -- The document date (10 November 2021) is 896 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 7482 (Obsoleted by RFC 9082) -- Obsolete informational reference (is this intentional?): RFC 7483 (Obsoleted by RFC 9083) -- Obsolete informational reference (is this intentional?): RFC 7484 (Obsoleted by RFC 9224) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 4 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: 14 May 2022 R. Moskowitz 6 HTT Consulting 7 S. Zhao (Editor) 8 Tencent 9 A. Gurtov 10 Linköping University 11 10 November 2021 13 Drone Remote Identification Protocol (DRIP) Architecture 14 draft-ietf-drip-arch-17 16 Abstract 18 This document describes an architecture for protocols and services to 19 support Unmanned Aircraft System Remote Identification and tracking 20 (UAS RID), plus RID-related communications. This architecture 21 adheres to the requirements listed in the DRIP Requirements document. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 14 May 2022. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Overview of Unmanned Aircraft System (UAS) Remote ID (RID) 58 and Standardization . . . . . . . . . . . . . . . . . . . 3 59 1.2. Overview of Types of UAS Remote ID . . . . . . . . . . . 4 60 1.2.1. Broadcast RID . . . . . . . . . . . . . . . . . . . . 4 61 1.2.2. Network RID . . . . . . . . . . . . . . . . . . . . . 5 62 1.3. Overview of USS Interoperability . . . . . . . . . . . . 7 63 1.4. Overview of DRIP Architecture . . . . . . . . . . . . . . 8 64 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 10 65 2.1. Architecture Terminology . . . . . . . . . . . . . . . . 10 66 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 10 67 2.3. Additional Definitions . . . . . . . . . . . . . . . . . 10 68 3. Claims, Assertions, Attestations, and Certificates . . . . . 10 69 4. HHIT as the DRIP Entity Identifier . . . . . . . . . . . . . 11 70 4.1. UAS Remote Identifiers Problem Space . . . . . . . . . . 12 71 4.2. HHIT as A Trustworthy DRIP Entity Identifier . . . . . . 12 72 4.3. HHIT for DRIP Identifier Registration and Lookup . . . . 14 73 4.4. HHIT as a Cryptographic Identifier . . . . . . . . . . . 14 74 5. DRIP Identifier Registration and Registries . . . . . . . . . 14 75 5.1. Public Information Registry . . . . . . . . . . . . . . . 15 76 5.1.1. Background . . . . . . . . . . . . . . . . . . . . . 15 77 5.1.2. DNS as the Public DRIP Identifier Registry . . . . . 15 78 5.2. Private Information Registry . . . . . . . . . . . . . . 15 79 5.2.1. Background . . . . . . . . . . . . . . . . . . . . . 15 80 5.2.2. EPP and RDAP as the Private DRIP Identifier 81 Registry . . . . . . . . . . . . . . . . . . . . . . 16 82 5.2.3. Alternative Private DRIP Registry methods . . . . . . 16 83 6. DRIP Identifier Trust . . . . . . . . . . . . . . . . . . . . 16 84 7. Harvesting Broadcast Remote ID messages for UTM Inclusion . . 17 85 7.1. The CS-RID Finder . . . . . . . . . . . . . . . . . . . . 18 86 7.2. The CS-RID SDSP . . . . . . . . . . . . . . . . . . . . . 18 87 8. DRIP Contact . . . . . . . . . . . . . . . . . . . . . . . . 18 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 89 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 90 11. Privacy & Transparency Considerations . . . . . . . . . . . . 19 91 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 92 12.1. Normative References . . . . . . . . . . . . . . . . . . 20 93 12.2. Informative References . . . . . . . . . . . . . . . . . 20 94 Appendix A. Overview of Unmanned Aircraft Systems (UAS) Traffic 95 Management (UTM) . . . . . . . . . . . . . . . . . . . . 23 96 A.1. Operation Concept . . . . . . . . . . . . . . . . . . . . 23 97 A.2. UAS Service Supplier (USS) . . . . . . . . . . . . . . . 24 98 A.3. UTM Use Cases for UAS Operations . . . . . . . . . . . . 24 99 Appendix B. Automatic Dependent Surveillance Broadcast 100 (ADS-B) . . . . . . . . . . . . . . . . . . . . . . . . . 25 101 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 25 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 104 1. Introduction 106 This document describes an architecture for protocols and services to 107 support Unmanned Aircraft System Remote Identification and tracking 108 (UAS RID), plus RID-related communications. The architecture takes 109 into account both current (including proposed) regulations and non- 110 IETF technical standards. 112 The architecture adheres to the requirements listed in the DRIP 113 Requirements document [I-D.ietf-drip-reqs]. The requirements 114 document provides an extended introduction to the problem space and 115 use cases. 117 1.1. Overview of Unmanned Aircraft System (UAS) Remote ID (RID) and 118 Standardization 120 UAS Remote Identification (RID) is an application enabler for a UAS 121 to be identified by Unmanned Aircraft Systems Traffic Management 122 (UTM) and UAS Service Supplier (USS) (Appendix A) or third parties 123 entities such as law enforcement. Many considerations (e.g., safety) 124 dictate that UAS be remotely identifiable. 126 Civil Aviation Authorities (CAAs) worldwide are mandating UAS RID. 127 CAAs currently promulgate performance-based regulations that do not 128 specify techniques, but rather cite industry consensus technical 129 standards as acceptable means of compliance. 131 Federal Aviation Administration (FAA) 133 The FAA published a Notice of Proposed Rule Making [NPRM] in 2019 134 and thereafter published a "Final Rule" in 2021 [FAA_RID], 135 imposing requirements on UAS manufacturers and operators, both 136 commercial and recreational. The rule clearly states that 137 Automatic Dependent Surveillance Broadcast (ADS-B) Out and 138 transponders cannot be used to satisfy the RID requirements on UAS 139 to which the rule applies (see Appendix B). 141 European Union Aviation Safety Agency (EASA) 142 The EASA published a [Delegated] regulation in 2019 imposing 143 requirements on UAS manufacturers and third-country operators, 144 including but not limited to RID requirements. The EASA also 145 published in 2019 an [Implementing] regulation laying down 146 detailed rules and procedures for UAS operations and operating 147 personnel. 149 American Society for Testing and Materials (ASTM) 151 ASTM International, Technical Committee F38 (UAS), Subcommittee 152 F38.02 (Aircraft Operations), Work Item WK65041, developed the 153 ASTM [F3411] Standard Specification for Remote ID and Tracking. 155 ASTM defines one set of RID information and two means, MAC-layer 156 broadcast and IP-layer network, of communicating it. If an UAS 157 uses both communication methods, the same information must be 158 provided via both means. [F3411] is cited by FAA in its RID final 159 rule [FAA_RID] as "a potential means of compliance" to a Remote ID 160 rule. 162 The 3rd Generation Partnership Project (3GPP) 164 With release 16, the 3GPP completed the UAS RID requirement study 165 [TS-22.825] and proposed a set of use cases in the mobile network 166 and the services that can be offered based on RID. Release 17 167 specification focuses on enhanced UAS service requirements and 168 provides the protocol and application architecture support that 169 will be applicable for both 4G and 5G networks. 171 1.2. Overview of Types of UAS Remote ID 173 1.2.1. Broadcast RID 175 [F3411] defines a set of RID messages for direct, one-way, broadcast 176 transmissions from the UA over Bluetooth or Wi-Fi. These are 177 currently defined as MAC-Layer messages. Internet (or other Wide 178 Area Network) connectivity is only needed for UAS registry 179 information lookup by Observers using the directly received UAS ID. 180 Broadcast RID should be functionally usable in situations with no 181 Internet connectivity. 183 The minimum Broadcast RID data flow is illustrated in Figure 1. 185 +------------------------+ 186 | Unmanned Aircraft (UA) | 187 +-----------o------------+ 188 | 189 | 190 | 191 | app messages directly over 192 | one-way RF data link (no IP) 193 | 194 | 195 v 196 +------------------o-------------------+ 197 | Observer's device (e.g., smartphone) | 198 +--------------------------------------+ 200 Figure 1 202 Broadcast RID provides information only about unmanned aircraft (UA) 203 within direct RF LOS, typically similar to visual Light-Of-Sight 204 (LOS), with a range up to approximately 1 km. This information may 205 be 'harvested' from received broadcasts and made available via the 206 Internet, enabling surveillance of areas too large for local direct 207 visual observation or direct RF link based ID (see Section 7). 209 1.2.2. Network RID 211 [F3411], using the same data dictionary that is the basis of 212 Broadcast RID messages, defines a Network Remote Identification (Net- 213 RID) data flow as follows. 215 * The information to be reported via RID is generated by the UAS 216 (typically some by the UA and some by the GCS, e.g. their 217 respective GNSS derived locations). 219 * The information is sent by the UAS (UA or GCS) via unspecified 220 means to the cognizant Network Remote Identification Service 221 Provider (Net-RID SP), typically the USS under which the UAS is 222 operating if participating in UTM. 224 * The Net-RID SP publishes via the Discovery and Synchronization 225 Service (DSS) over the Internet that it has operations in various 226 4-D airspace volumes, describing the volumes but not the 227 operations. 229 * An Observer's device, expected typically but not specified to be 230 web based, queries a Network Remote Identification Display 231 Provider (Net-RID DP), typically also a USS, about any operations 232 in a specific 4-D airspace volume. 234 * Using fully specified web based methods over the Internet, the 235 Net-RID DP queries all Net-RID SP that have operations in volumes 236 intersecting that of the Observer's query for details on all such 237 operations. 239 * The Net-RID DP aggregates information received from all such Net- 240 RID SP and responds to the Observer's query. 242 The minimum Net-RID data flow is illustrated in Figure 2: 244 +-------------+ ****************** 245 | UA | * Internet * 246 +--o-------o--+ * * 247 | | * * 248 | | * * +------------+ 249 | '--------*--(+)-----------*-----o | 250 | * | * | | 251 | .--------*--(+)-----------*-----o NET-RID SP | 252 | | * * | | 253 | | * .------*-----o | 254 | | * | * +------------+ 255 | | * | * 256 | | * | * +------------+ 257 | | * '------*-----o | 258 | | * * | NET-RID DP | 259 | | * .------*-----o | 260 | | * | * +------------+ 261 | | * | * 262 | | * | * +------------+ 263 +--o-------o--+ * '------*-----o Observer's | 264 | GCS | * * | Device | 265 +-------------+ ****************** +------------+ 267 Figure 2 269 Command and Control (C2) must flow from the GCS to the UA via some 270 path, currently (in the year of 2021) typically a direct RF link, but 271 with increasing beyond Visual Line of Sight (BVLOS) operations 272 expected often to be wireless links at either end with the Internet 273 between. 275 Telemetry (at least UA's position and heading) flows from the UA to 276 the GCS via some path, typically the reverse of the C2 path. Thus, 277 RID information pertaining to both the GCS and the UA can be sent, by 278 whichever has Internet connectivity, to the Net-RID SP, typically the 279 USS managing the UAS operation. 281 The Net-RID SP forwards RID information via the Internet to 282 subscribed Net-RID DP, typically USS. Subscribed Net-RID DP forward 283 RID information via the Internet to subscribed Observer devices. 284 Regulations require and [F3411] describes RID data elements that must 285 be transported end-to-end from the UAS to the subscribed Observer 286 devices. 288 [F3411] prescribes the protocols between the Net-RID SP, Net-RID DP, 289 and the Discovery and Synchronization Service (DSS). It also 290 prescribes data elements (in JSON) between Observer and Net-RID DP. 291 DRIP could address standardization of secure protocols between the UA 292 and GCS (over direct wireless and Internet connection), between the 293 UAS and the Net-RID SP, and/or between the Net-RID DP and Observer 294 devices. 296 Informative note: Neither link layer protocols nor the use of 297 links (e.g., the link often existing between the GCS and the 298 UA) for any purpose other than carriage of RID information is 299 in the scope of [F3411] Network RID. 301 1.3. Overview of USS Interoperability 303 With Net-RID, there is direct communication between the UAS and its 304 USS. With Broadcast-RID and UTM, the UAS Operator has either pre- 305 filed a 4D space volume for USS operational knowledge and/or 306 Observers can be providing information about observed UA to a 307 Surveillance Supplemental Data Service Provider (SDSP). USS exchange 308 information via a Discovery and Synchronization Service (DSS) so all 309 USS collectively have knowledge about all activities in a 4D 310 airspace. 312 The interactions among Observer, UA, and USS are shown in Figure 3. 314 +----------+ 315 | Observer | 316 +----------+ 317 / \ 318 / \ 319 +------+ +------+ 320 | UAS1 | | UAS2 | 321 +------+ +------+ 322 \ / 323 \ / 324 +----------+ 325 | Internet | 326 +----------+ 327 / \ 328 / \ 329 +------+ +------+ 330 | USS1 | <-------> | USS2 | 331 +------+ +------+ 332 \ / 333 \ / 334 +------+ 335 | DSS | 336 +------+ 338 Figure 3 340 Editor-note-1: (Stu) re-draw this figure and propose text. Then 341 double check the langauge in Editor-note-8 343 1.4. Overview of DRIP Architecture 345 Figure 4 illustrates a brief summary of the general UAS RID usage 346 scenarios in DRIP. 348 General x x Public 349 Public xxxxx xxxxx Safety 350 Observer x x Observer 351 x x 352 x x ---------+ +---------- x x 353 x x | | x x 354 | | 355 UA1 x x | | +------------ x x UA2 356 xxxxx | | | xxxxx 357 | + + + | 358 | xxxxxxxxxx | 359 | x x | 360 +----------+x Internet x+------------+ 361 UA1 | x x | UA1 362 Pilot x | xxxxxxxxxx | x Pilot 363 Operator xxxxx + + + xxxxx Operator 364 GCS1 x | | | x GCS2 365 x | | | x 366 x x | | | x x 367 x x | | | x x 368 | | | 369 +----------+ | | | +----------+ 370 | |------+ | +-------| | 371 | Public | | | Private | 372 | Registry | +-----+ | Registry | 373 | | | DNS | | | 374 +----------+ +-----+ +----------+ 376 Figure 4 378 Editor-note-2: Stu: replace figure 4 380 DRIP is meant to leverage existing Internet resources (standard 381 protocols, services, infrastructures, and business models) to meet 382 UAS RID and closely related needs. DRIP will specify how to apply 383 IETF standards, complementing [F3411] and other external standards, 384 to satisfy UAS RID requirements. 386 This document outlines the DRIP architecture in the context of the 387 UAS RID architecture. This includes presenting the gaps between the 388 CAAs' Concepts of Operations and [F3411] as it relates to the use of 389 Internet technologies and UA direct RF communications. Issues 390 include, but are not limited to: 392 o Design of trustworthy remote identifiers (Section 4). 394 - Mechanisms to leverage Domain Name System (DNS [RFC1034]), 395 Extensible Provisioning Protocol (EPP [RFC5731]) and 396 Registration Data Access Protocol (RDAP) ([RFC7482]) for 397 publishing public and private information (see Section 5.1 and 398 Section 5.2). 400 - Specific authentication methods and message payload formats to 401 enable verification that Broadcast RID messages were sent by 402 the claimed sender (Section 6) and that sender is in the 403 claimed registry (Section 5 and Section 6). 405 - Harvesting broadcast RID messages for UTM inclusion 406 (Section 7). 408 - Methods for instantly establishing secure communications 409 between an Observer and the pilot of an observed UAS 410 (Section 8). 412 - Privacy in RID messages (PII protection) (Section 11). 414 2. Terms and Definitions 416 2.1. Architecture Terminology 418 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 419 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 420 "OPTIONAL" in this document are to be interpreted as described in BCP 421 14 [RFC2119] [RFC8174] when, and only when, they appear in all 422 capitals, as shown above. 424 2.2. Abbreviations 426 EdDSA: Edwards-Curve Digital Signature Algorithm 428 HHIT: Hierarchical HIT 430 HIP: Host Identity Protocol 432 HIT: Host Identity Tag 434 2.3. Additional Definitions 436 This document uses terms defined in [I-D.ietf-drip-reqs]. 438 3. Claims, Assertions, Attestations, and Certificates 440 Editor-note-7: (Bob) move section 3 to Section 2.4? 441 This section introduces the terms "Claims", "Assertions", 442 "Attestations", and "Certificates" as used in DRIP. DRIP certificate 443 has a different context compared with security certificates and 444 Public Key Infrastructure used in X.509. 446 Claims: 448 A claim in DRIP is a predicate (e.g., "X is Y", "X has property 449 Y", and most importantly "X owns Y" or "X is owned by Y"). 451 Assertions: 453 An assertion in DRIP is a set of claims. This definition is 454 borrowed from JWT [RFC7519] and CWT [RFC8392]. 456 Attestations: 458 An attestation in DRIP is a signed assertion. The signer may be 459 the claimant or a related party with stake in the assertion(s). 460 Under DRIP this is normally used when an entity asserts a 461 relationship with another entity, along with other information, 462 and the asserting entity signs the assertion, thereby making it an 463 attestation. 465 Certificates: 467 A certificate in DRIP is an attestation, strictly over identity 468 information, signed by a third party. This third party should be 469 one with no stake in the attestation(s) its signing over. 471 4. HHIT as the DRIP Entity Identifier 473 This section describes the DRIP architectural approach to meeting the 474 basic requirements of a DRIP entity identifier within external 475 technical standard ASTM [F3411] and regulatory constraints. It 476 justifies and explains the use of Hierarchical Host Identity Tags 477 (HHITs) as self-asserting IPv6 addresses suitable as a UAS ID type 478 and more generally as trustworthy multipurpose remote identifiers. 480 Self-asserting in this usage is given the Host Identity (HI), the 481 HHIT ORCHID construction and a signature of the HHIT by the HI can 482 both be validated. The explicit registration hierarchy within the 483 HHIT provides registry discovery (managed by a Registrar) to either 484 yield the HI for 3rd-party (who is looking for ID attestation) 485 validation or prove the HHIT and HI have uniquely been registered. 487 4.1. UAS Remote Identifiers Problem Space 489 A DRIP entity identifier needs to be "Trustworthy" (See DRIP 490 Requirement GEN-1, ID-4 and ID-5 in [I-D.ietf-drip-reqs]). This 491 means that given a sufficient collection of RID messages, an Observer 492 can establish that the identifier claimed therein uniquely belongs to 493 the claimant: that the only way for any other entity to prove 494 ownership of that identifier would be to obtain information that 495 ought to be available only to the legitimate owner of the identifier 496 (e.g., a cryptographic private key). 498 To satisfy DRIP requirements and maintain important security 499 properties, the DRIP identifier should be self-generated by the 500 entity it names (e.g., a UAS) and registered (e.g., with a USS, see 501 Requirements GEN-3 and ID-2). 503 Broadcast RID, especially its support for Bluetooth 4, imposes severe 504 constraints. ASTM RID [F3411] allows a UAS ID of types 1, 2 and 3 of 505 20 bytes; a revision to [F3411], currently in balloting (as of Oct 506 2021), adds type 4, Session IDs, to be standardized by IETF and other 507 standard development organizations (SDOs) as extensions to ASTM RID, 508 consumes one of those bytes to index the sub-type, leaving only 19 509 for the identifier (see DRIP Requirement ID-1). Likewise, the 510 maximum ASTM RID [F3411] Authentication Message payload is 201 bytes 511 for most authentication types, but for type 5, also added in this 512 revision, for IETF and other SDOs to develop Specific Authentication 513 Methods as extensions to ASTM RID, one byte is consumed to index the 514 sub-type, leaving only 200 for DRIP authentication payloads, 515 including one or more DRIP entity identifiers and associated 516 authentication data. 518 4.2. HHIT as A Trustworthy DRIP Entity Identifier 520 A Remote ID that can be trustworthily used in the RID Broadcast mode 521 can be built from an asymmetric keypair. Rather than using a key 522 signing operation to claim ownership of an ID that does not guarantee 523 name uniqueness, in this method the ID is cryptographically derived 524 directly from the public key. The proof of ID ownership (verifiable 525 attestation, versus mere claim) is guaranteed by signing this 526 cryptographic ID with the associated private key. The association 527 between the ID and the private key is ensured by cryptographically 528 binding the public key with the ID, more specifically the ID results 529 from the hash of the public key. It is statistically hard for 530 another entity to create a public key that would generate (spoof) the 531 ID. 533 The basic HIT is designed statistically unique through the 534 cryptographic hash feature of second-preimage resistance. The 535 cryptographically-bound addition of the Hierarchy and an HHIT 536 registration process (e.g. based on Extensible Provisioning Protocol, 537 [RFC5730]) provide complete, global HHIT uniqueness. This 538 registration forces the attacker to generate the same public key 539 rather than a public key that generates the same HHIT. This is in 540 contrast to general IDs (e.g. a UUID or device serial number) as the 541 subject in an X.509 certificate. 543 A DRIP identifier can be assigned to a UAS as a static HHIT by its 544 manufacturer, such as a single HI and derived HHIT encoded as a 545 hardware serial number per [CTA2063A]. Such a static HHIT SHOULD 546 only be used to bind one-time use DRIP identifiers to the unique UA. 547 Depending upon implementation, this may leave a HI private key in the 548 possession of the manufacturer (more details in Section 10). 550 A UA equipped for Broadcast RID SHOULD be provisioned not only with 551 its HHIT but also with the HI public key from which the HHIT was 552 derived and the corresponding private key, to enable message 553 signature. A UAS equipped for Network RID SHOULD be provisioned 554 likewise; the private key resides only in the ultimate source of 555 Network RID messages (i.e. on the UA itself if the GCS is merely 556 relaying rather than sourcing Network RID messages). Each Observer 557 device SHOULD be provisioned either with public keys of the DRIP 558 identifier root registries or certificates for subordinate 559 registries. 561 HHITs can also be used throughout the USS/UTM system. The Operators, 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, by avoiding an explicit encoding technology like 569 ASN.1 or Concise Binary Object Representation (CBOR [RFC8949]). This 570 attestation consists of only the HHIT, a timestamp, and the EdDSA 571 signature on them. 573 An Observer would need Internet access to validate a self- 574 attestations claim. A third-party Certificate can be validated via a 575 small credential cache in a disconnected environment. This third- 576 party Certificate is possible when the third-party also uses HHITs 577 for its identity and the UA has the public key and the Certificate 578 for that HHIT. 580 Editor-note-3: review the last/above pragraph. 582 4.3. HHIT for DRIP Identifier Registration and Lookup 584 Remote ID needs a deterministic lookup mechanism that rapidly 585 provides actionable information about the identified UA. Given the 586 size constraints imposed by the Bluetooth 4 broadcast media, the UAS 587 ID itself needs to be a non-spoofable inquiry input into the lookup. 589 A DRIP registration process based on the explicit hierarchy within a 590 HHIT provides manageable uniqueness of the HI for the HHIT. This is 591 the defense against a cryptographic hash second pre-image attack on 592 the HHIT (e.g. multiple HIs yielding the same HHIT, see Requirement 593 ID-3). A lookup of the HHIT into this registration data provides the 594 registered HI for HHIT proof. A first-come-first-serve registration 595 for a HHIT provides deterministic access to any other needed 596 actionable information based on inquiry access authority (more 597 details in Section 5.2). 599 4.4. HHIT as a Cryptographic Identifier 601 The only (known to the authors at the time of this writing) extant 602 types of IP address compatible identifiers cryptographically derived 603 from the public keys of the identified entities are Cryptographically 604 Generated Addresses (CGAs) [RFC3972] and Host Identity Tags (HITs) 605 [RFC7401]. CGAs and HITs lack registration/retrieval capability. To 606 provide this, each HHIT embeds plaintext information designating the 607 hierarchy within which is registered and a cryptographic hash of that 608 information concatenated with the entity's public key, etc. Although 609 hash collisions may occur, the registrar can detect them and reject 610 registration requests rather than issue credentials, e.g., by 611 enforcing a first-claimed, first-attested policy. Pre-image hash 612 attacks are also mitigated through this registration process, locking 613 the HHIT to a specific HI 615 5. DRIP Identifier Registration and Registries 617 Editor-note-4: Section 5 needs to cite the corresponding numbered 618 requirement that it supports. 620 DRIP registries hold both public and private UAS information 621 resulting from the DRIP identifier registration process. Given these 622 different uses, and to improve scalability, security, and simplicity 623 of administration, the public and private information can be stored 624 in different registries. This section introduces the public and 625 private information registries for DRIP identifiers. 627 5.1. Public Information Registry 629 5.1.1. Background 631 The public registry provides trustable information such as 632 attestations of RID ownership and registration with the HDA 633 (Hierarchical HIT Domain Authority). Optionally, pointers to the 634 registries for the HDA and RAA (Registered Assigning 635 Authority)implicit in the RID can be included (e.g., for HDA and RAA 636 HHIT|HI used in attestation signing operations). This public 637 information will be principally used by Observers of Broadcast RID 638 messages. Data on UAS that only use Network RID, is available via an 639 Observer's Net-RID DP that would tend to directly provide all public 640 registry information. The Observer may visually "see" these Net-RID 641 UAS, but they may be silent to the Observer. The Net-RID DP is the 642 only source of information based on a query for an airspace volume. 644 5.1.2. DNS as the Public DRIP Identifier Registry 646 A DRIP identifier SHOULD be registered as an Internet domain name (at 647 an arbitrary level in the hierarchy, e.g. in .ip6.arpa). Thus DNS 648 can provide all the needed public DRIP information. A standardized 649 HHIT FQDN (Fully Qualified Domain Name) can deliver the HI via a HIP 650 RR (Resource Record) [RFC8005] and other public information (e.g., 651 RRA and HDA PTRs, and HIP RVS (Rendezvous Servers) [RFC8004]). These 652 public information registries can use secure DNS transport (e.g. DNS 653 over TLS) to deliver public information that is not inherently 654 trustable (e.g. everything other than attestations). 656 5.2. Private Information Registry 658 5.2.1. Background 660 The private information required for DRIP identifiers is similar to 661 that required for Internet domain name registration. A DRIP 662 identifier solution can leverage existing Internet resources: 663 registration protocols, infrastructure, and business models, by 664 fitting into an ID structure compatible with DNS names. The HHIT 665 hierarchy can provide the needed scalability and management 666 structure. It is expected that the private registry function will be 667 provided by the same organizations that run a USS, and likely 668 integrated with a USS. The lookup function may be implemented by the 669 Net-RID DPs. 671 5.2.2. EPP and RDAP as the Private DRIP Identifier Registry 673 A DRIP private information registry supports essential registry 674 operations (e.g. add, delete, update, query) using interoperable open 675 standard protocols. It can accomplish this by using the Extensible 676 Provisioning Protocol (EPP [RFC5730]) and the Registry Data Access 677 Protocol (RDAP RFC7480] [RFC7482] [RFC7483]). The DRIP private 678 information registry in which a given UAS is registered needs to be 679 findable, starting from the UAS ID, using the methods specified in 680 [RFC7484]. 682 5.2.3. Alternative Private DRIP Registry methods 684 A DRIP private information registry might be an access controlled DNS 685 (e.g. via DNS over TLS). Additionally, WebFinger [RFC7033] can be 686 deployed. These alternative methods may be used by Net-RID DP with 687 specific customers. 689 6. DRIP Identifier Trust 691 Editor-note-5: Section 6 doesn't use the word "authentication" in the 692 section title, is there a reason to avoid it? 694 While the DRIP entity identifier is self-asserting, it alone does not 695 provide the "trustworthiness" specified in [I-D.ietf-drip-reqs]. For 696 that it MUST be registered (under DRIP Registries) and be actively 697 used by the party (in most cases the UA). For Broadcast RID this is 698 a challenge to balance the original requirements of Broadcast RID and 699 the efforts needed to satisfy the DRIP requirements all under severe 700 constraints. 702 An optimization of different DRIP Authentication Messages allows an 703 Observer, without Internet connection (offline) or with (online), to 704 be able to validate a UAS DRIP ID in real-time. First is the sending 705 of Broadcast Attestations (over DRIP Link Authentication Messages) 706 containing the relevant registration of the UA's DRIP ID in the 707 claimed Registry. Next is sending DRIP Wrapper Authentication 708 Messages that sign over both static (e.g. above registration) and 709 dynamically changing data (such as UA location data). Combining 710 these two sets of information an Observer can piece together a chain 711 of trust and real-time evidence to make their determination of the 712 UAs claims. 714 This process (combining the DRIP entity identifier, Registries and 715 Authentication Formats for Broadcast RID) can satisfy the following 716 DRIP requirement defined in [I-D.ietf-drip-reqs]: GEN-1, GEN-2, GEN- 717 3, ID-2, ID-3, ID-4 and ID-5. 719 7. Harvesting Broadcast Remote ID messages for UTM Inclusion 721 Editor-note-6: Section 7 needs to cite the corresponding numbered 722 requirement that it supports. 724 ASTM anticipated that regulators would require both Broadcast RID and 725 Network RID for large UAS, but allow RID requirements for small UAS 726 to be satisfied with the operator's choice of either Broadcast RID or 727 Network RID. The EASA initially specified Broadcast RID for UAS of 728 essentially all UAS and is now also considering Network RID. The FAA 729 RID Final Rules [FAA_RID] permit only Broadcast RID for rule 730 compliance, but still encourage Network RID for complementary 731 functionality, especially in support of UTM. 733 One obvious opportunity is to enhance the architecture with gateways 734 from Broadcast RID to Network RID. This provides the best of both 735 and gives regulators and operators flexibility. It offers advantages 736 over either form of RID alone: greater fidelity than Network RID 737 reporting of planned area operations; surveillance of areas too large 738 for local direct visual observation and direct RF-LOS link based 739 Broadcast RID (e.g., a city or a national forest). 741 These gateways could be pre-positioned (e.g. around airports, public 742 gatherings, and other sensitive areas) and/or crowd-sourced (as 743 nothing more than a smartphone with a suitable app is needed). As 744 Broadcast RID media have limited range, gateways receiving messages 745 claiming locations far from the gateway can alert authorities or a 746 SDSP to the failed sanity check possibly indicating intent to 747 deceive. Surveillance SDSPs can use messages with precise date/time/ 748 position stamps from the gateways to multilaterate UA location, 749 independent of the locations claimed in the messages, which are 750 entirely operator self-reported in UAS RID and UTM, and thus are 751 subject not only to natural time lag and error but also operator 752 misconfiguration or intentional deception. 754 Further, gateways with additional sensors (e.g. smartphones with 755 cameras) can provide independent information on the UA type and size, 756 confirming or refuting those claims made in the RID messages. This 757 Crowd Sourced Remote ID (CS-RID) would be a significant enhancement, 758 beyond baseline DRIP functionality; if implemented, it adds two more 759 entity types. 761 7.1. The CS-RID Finder 763 A CS-RID Finder is the gateway for Broadcast Remote ID Messages into 764 the UTM. It performs this gateway function via a CS-RID SDSP. A CS- 765 RID Finder could implement, integrate, or accept outputs from, a 766 Broadcast RID receiver. However, it should not depend upon a direct 767 interface with a GCS, Net-RID SP, Net-RID DP or Network RID client. 768 It would present a TBD interface to a CS-RID SDSP, similar to but 769 readily distinguishable from that between a GCS and a Net-RID SP. 771 7.2. The CS-RID SDSP 773 A CS-RID SDSP aggregates and processes (e.g., estimates UA location 774 using including using multilateration when possible) information 775 collected by CS-RID Finders. A CS-RID SDSP should appear (i.e. 776 present the same interface) to a Net-RID SP as a Net-RID DP. 778 Editor-note-8: double check above paragraph after Editor-note-1 is 779 resolved. 781 8. DRIP Contact 783 One of the ways in which DRIP can enhance [F3411] with immediately 784 actionable information is by enabling an Observer to instantly 785 initiate secure communications with the UAS remote pilot, Pilot In 786 Command, operator, USS under which the operation is being flown, or 787 other entity potentially able to furnish further information 788 regarding the operation and its intent and/or to immediately 789 influence further conduct or termination of the operation (e.g., land 790 or otherwise exit an airspace volume). Such potentially distracting 791 communications demand strong "AAA" (Authentication, Attestation, 792 Authorization, Access Control, Accounting, Attribution, Audit) per 793 applicable policies (e.g., of the cognizant CAA). 795 A DRIP entity identifier based on a HHIT as outlined in Section 4 796 embeds an identifier of the registry in which it can be found 797 (expected typically to be the USS under which the UAS is flying) and 798 the procedures outlined in Section 6 enable Observer verification of 799 that relationship. A DRIP entity identifier with suitable records in 800 public and private registries as outlined in Section 5 can enable 801 lookup not only of information regarding the UAS but also identities 802 of and pointers to information regarding the various associated 803 entities (e.g., the USS under which the UAS is flying an operation), 804 including means of contacting those associated entities (i.e., 805 locators, typically IP addresses). An Observer equipped with HIP can 806 initiate a Base Exchange (BEX) and establish a Bound End to End 807 Tunnel (BEET) protected by IPsec Encapsulating Security Payload (ESP) 808 encryption to a likewise equipped and identified entity: the UA 809 itself, if operating autonomously; the GCS, if the UA is remotely 810 piloted and the necessary records have been populated in DNS; 811 likewise the USS, etc. Certain preconditions are necessary: each 812 party to the communication needs a currently usable means (typically 813 DNS) of resolving the other party's DRIP entity identifier to a 814 currently usable locator (IP address); and there must be currently 815 usable bidirectional IP (not necessarily Internet) connectivity 816 between the parties. Given a BEET, arbitrary standard higher layer 817 protocols can then be used for Observer to Pilot (O2P) communications 818 (e.g., SIP [RFC3261] et seq), V2X communications (e.g., [MAVLink]), 819 etc. This approach satisfies DRIP requirement GEN-6 Contact, 820 supports satisfaction of requirements [I-D.ietf-drip-reqs] GEN-8, 821 GEN-9, PRIV-2, PRIV-5 and REG-3, and is compatible with all other 822 DRIP requirements. 824 9. IANA Considerations 826 This document does not make any IANA request. 828 10. Security Considerations 830 The security provided by asymmetric cryptographic techniques depends 831 upon protection of the private keys. A manufacturer that embeds a 832 private key in an UA may have retained a copy. A manufacturer whose 833 UA are configured by a closed source application on the GCS which 834 communicates over the Internet with the factory may be sending a copy 835 of a UA or GCS self-generated key back to the factory. Keys may be 836 extracted from a GCS or UA. The RID sender of a small harmless UA 837 (or the entire UA) could be carried by a larger dangerous UA as a 838 "false flag." Compromise of a registry private key could do 839 widespread harm. Key revocation procedures are as yet to be 840 determined. These risks are in addition to those involving Operator 841 key management practices. 843 11. Privacy & Transparency Considerations 845 Broadcast RID messages can contain Personally Identifiable 846 Information (PII). A viable architecture for PII protection would be 847 symmetric encryption of the PII using a session key known to the UAS 848 and its USS. Authorized Observers could obtain plaintext in either 849 of two ways. An Observer can send the UAS ID and the cyphertext to a 850 server that offers decryption as a service. An Observer can send the 851 UAS ID only to a server that returns the session key, so that 852 Observer can directly locally decrypt all cyphertext sent by that UA 853 during that session (UAS operation). In either case, the server can 854 be: a Public Safety USS; the Observer's own USS; or the UA's USS if 855 the latter can be determined (which under DRIP it can be, from the 856 UAS ID itself). PII can be protected unless the UAS is informed 857 otherwise. This could come as part of UTM operation authorization. 858 It can be special instructions at the start or during an operation. 859 PII protection MUST not be used if the UAS loses connectivity to the 860 USS. The UAS always has the option to abort the operation if PII 861 protection is disallowed. 863 12. References 865 12.1. Normative References 867 [I-D.ietf-drip-reqs] 868 Card, S. W., Wiethuechter, A., Moskowitz, R., and A. 869 Gurtov, "Drone Remote Identification Protocol (DRIP) 870 Requirements", Work in Progress, Internet-Draft, draft- 871 ietf-drip-reqs-18, 8 September 2021, 872 . 875 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 876 Requirement Levels", BCP 14, RFC 2119, 877 DOI 10.17487/RFC2119, March 1997, 878 . 880 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 881 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 882 May 2017, . 884 12.2. Informative References 886 [CTA2063A] ANSI, "Small Unmanned Aerial Systems Serial Numbers", 887 2019. 889 [Delegated] 890 European Union Aviation Safety Agency (EASA), "EU 891 Commission Delegated Regulation 2019/945 of 12 March 2019 892 on unmanned aircraft systems and on third-country 893 operators of unmanned aircraft systems", 2019. 895 [F3411] ASTM International, "Standard Specification for Remote ID 896 and Tracking", February 2020, 897 . 899 [FAA_RID] United States Federal Aviation Administration (FAA), 900 "Remote Identification of Unmanned Aircraft", 2021, 901 . 904 [FAA_UAS_Concept_Of_Ops] 905 United States Federal Aviation Administration (FAA), 906 "Unmanned Aircraft System (UAS) Traffic Management (UTM) 907 Concept of Operations (V2.0)", 2020, 908 . 911 [Implementing] 912 European Union Aviation Safety Agency (EASA), "EU 913 Commission Implementing Regulation 2019/947 of 24 May 2019 914 on the rules and procedures for the operation of unmanned 915 aircraft", 2019. 917 [LAANC] United States Federal Aviation Administration (FAA), "Low 918 Altitude Authorization and Notification Capability", n.d., 919 . 922 [MAVLink] "Micro Air Vehicle Communication Protocol", 2021, 923 . 925 [NPRM] United States Federal Aviation Administration (FAA), 926 "Notice of Proposed Rule Making on Remote Identification 927 of Unmanned Aircraft Systems", 2019. 929 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 930 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 931 . 933 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 934 A., Peterson, J., Sparks, R., Handley, M., and E. 935 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 936 DOI 10.17487/RFC3261, June 2002, 937 . 939 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 940 RFC 3972, DOI 10.17487/RFC3972, March 2005, 941 . 943 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 944 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 945 . 947 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 948 Domain Name Mapping", STD 69, RFC 5731, 949 DOI 10.17487/RFC5731, August 2009, 950 . 952 [RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr, 953 "WebFinger", RFC 7033, DOI 10.17487/RFC7033, September 954 2013, . 956 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 957 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 958 RFC 7401, DOI 10.17487/RFC7401, April 2015, 959 . 961 [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access 962 Protocol (RDAP) Query Format", RFC 7482, 963 DOI 10.17487/RFC7482, March 2015, 964 . 966 [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the 967 Registration Data Access Protocol (RDAP)", RFC 7483, 968 DOI 10.17487/RFC7483, March 2015, 969 . 971 [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data 972 (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March 973 2015, . 975 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 976 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 977 . 979 [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 980 Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, 981 October 2016, . 983 [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name 984 System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, 985 October 2016, . 987 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 988 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 989 May 2018, . 991 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 992 Representation (CBOR)", STD 94, RFC 8949, 993 DOI 10.17487/RFC8949, December 2020, 994 . 996 [TS-22.825] 997 3GPP, "Study on Remote Identification of Unmanned Aerial 998 Systems (UAS)", n.d., 999 . 1002 [U-Space] European Organization for the Safety of Air Navigation 1003 (EUROCONTROL), "U-space Concept of Operations", 2019, 1004 . 1007 Appendix A. Overview of Unmanned Aircraft Systems (UAS) Traffic 1008 Management (UTM) 1010 A.1. Operation Concept 1012 The National Aeronautics and Space Administration (NASA) and FAA's 1013 effort of integrating UAS's operation into the national airspace 1014 system (NAS) led to the development of the concept of UTM and the 1015 ecosystem around it. The UTM concept was initially presented in 2013 1016 and version 2.0 was published in 2020 [FAA_UAS_Concept_Of_Ops]. 1018 The eventual concept refinement, initial prototype implementation, 1019 and testing were conducted by the UTM research transition team which 1020 is the joint workforce by FAA and NASA. World efforts took place 1021 afterward. The Single European Sky ATM Research (SESAR) started the 1022 CORUS project to research its UTM counterpart concept, namely 1023 [U-Space]. This effort is led by the European Organization for the 1024 Safety of Air Navigation (Eurocontrol). 1026 Both NASA and SESAR have published the UTM concept of operations to 1027 guide the development of their future air traffic management (ATM) 1028 system and ensure safe and efficient integration of manned and 1029 unmanned aircraft into the national airspace. 1031 The UTM comprises UAS operation infrastructure, procedures and local 1032 regulation compliance policies to guarantee safe UAS integration and 1033 operation. The main functionality of a UTM includes, but is not 1034 limited to, providing means of communication between UAS operators 1035 and service providers and a platform to facilitate communication 1036 among UAS service providers. 1038 A.2. UAS Service Supplier (USS) 1040 A USS plays an important role to fulfill the key performance 1041 indicators (KPIs) that a UTM has to offer. Such an Entity acts as a 1042 proxy between UAS operators and UTM service providers. It provides 1043 services like real-time UAS traffic monitoring and planning, 1044 aeronautical data archiving, airspace and violation control, 1045 interacting with other third-party control entities, etc. A USS can 1046 coexist with other USS to build a large service coverage map that can 1047 load-balance, relay, and share UAS traffic information. 1049 The FAA works with UAS industry shareholders and promotes the Low 1050 Altitude Authorization and Notification Capability [LAANC] program 1051 which is the first system to realize some of the UTM envisioned 1052 functionality. The LAANC program can automate the UAS operational 1053 intent (flight plan) submission and application for airspace 1054 authorization in real-time by checking against multiple aeronautical 1055 databases such as airspace classification and operating rules 1056 associated with it, FAA UAS facility map, special use airspace, 1057 Notice to Airmen (NOTAM), and Temporary Flight Restriction (TFR). 1059 A.3. UTM Use Cases for UAS Operations 1061 This section illustrates a couple of use case scenarios where UAS 1062 participation in UTM has significant safety improvement. 1064 1. For a UAS participating in UTM and taking off or landing in a 1065 controlled airspace (e.g., Class Bravo, Charlie, Delta, and Echo 1066 in the United States), the USS under which the UAS is operating 1067 is responsible for verifying UA registration, authenticating the 1068 UAS operational intent (flight plan) by checking against 1069 designated UAS facility map database, obtaining the air traffic 1070 control (ATC) authorization, and monitoring the UAS flight path 1071 in order to maintain safe margins and follow the pre-authorized 1072 sequence of authorized 4-D volumes (route). 1074 2. For a UAS participating in UTM and taking off or landing in 1075 uncontrolled airspace (ex. Class Golf in the United States), 1076 pre-flight authorization must be obtained from a USS when 1077 operating beyond-visual-of-sight (BVLOS). The USS either accepts 1078 or rejects the received operational intent (flight plan) from the 1079 UAS. Accepted UAS operation may share its current flight data 1080 such as GPS position and altitude to USS. The USS may keep the 1081 UAS operation status near real-time and may keep it as a record 1082 for overall airspace air traffic monitoring. 1084 Appendix B. Automatic Dependent Surveillance Broadcast (ADS-B) 1086 The ADS-B is the de jure technology used in manned aviation for 1087 sharing location information, from the aircraft to ground and 1088 satellite-based systems, designed in the early 2000s. Broadcast RID 1089 is conceptually similar to ADS-B, but with the receiver target being 1090 the general public on generally available devices (e.g. smartphones). 1092 For numerous technical reasons, ADS-B itself is not suitable for low- 1093 flying small UA. Technical reasons include but not limited to the 1094 following: 1096 1. Lack of support for the 1090 MHz ADS-B channel on any consumer 1097 handheld devices 1099 2. Weight and cost of ADS-B transponders on CSWaP constrained UA 1101 3. Limited bandwidth of both uplink and downlink, which would likely 1102 be saturated by large numbers of UAS, endangering manned aviation 1104 Understanding these technical shortcomings, regulators worldwide have 1105 ruled out the use of ADS-B for the small UAS for which UAS RID and 1106 DRIP are intended. 1108 Acknowledgements 1110 The work of the FAA's UAS Identification and Tracking (UAS ID) 1111 Aviation Rulemaking Committee (ARC) is the foundation of later ASTM 1112 and proposed IETF DRIP WG efforts. The work of ASTM F38.02 in 1113 balancing the interests of diverse stakeholders is essential to the 1114 necessary rapid and widespread deployment of UAS RID. Thanks to 1115 Alexandre Petrescu and Stephan Wenger for the helpful and positive 1116 comments. Thanks to chairs Daniel Migault and Mohamed Boucadair for 1117 direction of our team of authors and editor, some of whom are 1118 newcomers to writing IETF documents. Thanks especially to Internet 1119 Area Director Eric Vyncke for guidance and support. 1121 Authors' Addresses 1123 Stuart W. Card 1124 AX Enterprize 1125 4947 Commercial Drive 1126 Yorkville, NY, 13495 1127 United States of America 1129 Email: stu.card@axenterprize.com 1130 Adam Wiethuechter 1131 AX Enterprize 1132 4947 Commercial Drive 1133 Yorkville, NY, 13495 1134 United States of America 1136 Email: adam.wiethuechter@axenterprize.com 1138 Robert Moskowitz 1139 HTT Consulting 1140 Oak Park, MI, 48237 1141 United States of America 1143 Email: rgm@labs.htt-consult.com 1145 Shuai Zhao 1146 Tencent 1147 2747 Park Blvd 1148 Palo Alto, 94588 1149 United States of America 1151 Email: shuai.zhao@ieee.org 1153 Andrei Gurtov 1154 Linköping University 1155 IDA 1156 SE-58183 Linköping Linköping 1157 Sweden 1159 Email: gurtov@acm.org