idnits 2.17.1 draft-ietf-drip-arch-15.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 243 has weird spacing: '...bserver x x...' == Line 344 has weird spacing: '...perator xxxxx...' == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (25 July 2021) is 998 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-drip-reqs-17 -- 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 (~~), 6 warnings (==), 5 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: 26 January 2022 R. Moskowitz 6 HTT Consulting 7 S. Zhao (Editor) 8 Tencent 9 A. Gurtov 10 Linköping University 11 25 July 2021 13 Drone Remote Identification Protocol (DRIP) Architecture 14 draft-ietf-drip-arch-15 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 26 January 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 . . . . . . . . . . . . . . . . . . . . 9 65 2.1. Architecture Terminology . . . . . . . . . . . . . . . . 9 66 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . 11 71 4.2. HIT as A Trustworthy DRIP Entity Identifier . . . . . . . 11 72 4.3. HHIT for DRIP Identifier Registration and Lookup . . . . 13 73 4.4. HHIT for DRIP Identifier Cryptographic . . . . . . . . . 13 74 5. DRIP Identifier Registration and Registries . . . . . . . . . 13 75 5.1. Public Information Registry . . . . . . . . . . . . . . . 13 76 5.1.1. Background . . . . . . . . . . . . . . . . . . . . . 14 77 5.1.2. DNS as the Public DRIP Identifier Registry . . . . . 14 78 5.2. Private Information Registry . . . . . . . . . . . . . . 14 79 5.2.1. Background . . . . . . . . . . . . . . . . . . . . . 14 80 5.2.2. EPP and RDAP as the Private DRIP Identifier 81 Registry . . . . . . . . . . . . . . . . . . . . . . 15 82 5.2.3. Alternative Private DRIP Registry methods . . . . . . 15 83 6. Harvesting Broadcast Remote ID messages for UTM Inclusion . . 15 84 6.1. The CS-RID Finder . . . . . . . . . . . . . . . . . . . . 16 85 6.2. The CS-RID SDSP . . . . . . . . . . . . . . . . . . . . . 16 86 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 16 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 88 9. Privacy & Transparency Considerations . . . . . . . . . . . . 17 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 90 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 91 10.2. Informative References . . . . . . . . . . . . . . . . . 17 92 Appendix A. Overview of Unmanned Aircraft Systems (UAS) Traffic 93 Management (UTM) . . . . . . . . . . . . . . . . . . . . 20 94 A.1. Operation Concept . . . . . . . . . . . . . . . . . . . . 20 95 A.2. UAS Service Supplier (USS) . . . . . . . . . . . . . . . 21 96 A.3. UTM Use Cases for UAS Operations . . . . . . . . . . . . 21 98 Appendix B. Automatic Dependent Surveillance Broadcast 99 (ADS-B) . . . . . . . . . . . . . . . . . . . . . . . . . 22 100 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 22 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 103 1. Introduction 105 This document describes an architecture for protocols and services to 106 support Unmanned Aircraft System Remote Identification and tracking 107 (UAS RID), plus RID-related communications. The architecture takes 108 into account both current (including proposed) regulations and non- 109 IETF technical standards. 111 The architecture adheres to the requirements listed in the DRIP 112 Requirements document [I-D.ietf-drip-reqs]. 114 1.1. Overview of Unmanned Aircraft System (UAS) Remote ID (RID) and 115 Standardization 117 CAAs currently promulgate performance-based regulations that do not 118 specify techniques, but rather cite industry consensus technical 119 standards as acceptable means of compliance. 121 UAS Remote Identification (RID) is an application enabler for a UAS 122 to be identified by Unmanned Aircraft Systems Traffic Management 123 (UTM) and UAS Service Supplier (USS) (Appendix A) or third parties 124 entities such as law enforcement. Many considerations (e.g., safety) 125 dictate that UAS be remotely identifiable. Civil Aviation 126 Authorities (CAAs) worldwide are mandating UAS RID. For example, the 127 European Union Aviation Safety Agency (EASA) has published 128 [Delegated] and [Implementing] Regulations. 130 Federal Aviation Administration (FAA) 132 The FAA published a Notice of Proposed Rule Making [NPRM] in 2019 133 and whereafter published the "Final Rule" in 2021 [FAA_RID]. In 134 FAA's final rule, it is clearly stated that Automatic Dependent 135 Surveillance Broadcast (ADS-B) Out and transponders can not be 136 used to serve the purpose of an remote identification. More 137 details about ADS-B can be found in Appendix B. 139 American Society for Testing and Materials (ASTM) 141 ASTM International, Technical Committee F38 (UAS), Subcommittee 142 F38.02 (Aircraft Operations), Work Item WK65041, developed the 143 ASTM [F3411-19] Standard Specification for Remote ID and Tracking. 145 ASTM defines one set of RID information and two means, MAC-layer 146 broadcast and IP-layer network, of communicating it. If an UAS 147 uses both communication methods, the same information must be 148 provided via both means. [F3411-19] is cited by FAA in its RID 149 final rule [FAA_RID] as "a potential means of compliance" to a 150 Remote ID rule. 152 The 3rd Generation Partnership Project (3GPP) 154 With release 16, the 3GPP completed the UAS RID requirement study 155 [TS-22.825] and proposed a set of use cases in the mobile network 156 and the services that can be offered based on RID. Release 17 157 specification focuses on enhanced UAS service requirements and 158 provides the protocol and application architecture support that 159 will be applicable for both 4G and 5G networks. 161 1.2. Overview of Types of UAS Remote ID 163 1.2.1. Broadcast RID 165 A set of RID messages are defined for direct, one-way, broadcast 166 transmissions from the UA over Bluetooth or Wi-Fi. These are 167 currently defined as MAC-Layer messages. Internet (or other Wide 168 Area Network) connectivity is only needed for UAS registry 169 information lookup by Observers using the directly received UAS ID. 170 Broadcast RID should be functionally usable in situations with no 171 Internet connectivity. 173 The minimum Broadcast RID data flow is illustrated in Figure 1. 175 x x UA 176 xxxxx 177 | 178 | 179 | app messages directly over 180 | one-way RF data link (no IP) 181 | 182 | 183 + 184 x 185 xxxxx 186 x 187 x 188 x x Observer's device (e.g. smartphone) 189 x x 191 Figure 1 193 With queries sent over the Internet using harvested RID (see 194 Section 6), the Observer may gain more information about those 195 visible UAS" is only true if the locally observed UAS is (or very 196 recently was) observed somewhere else; harvesting RID is not so much 197 about learning more about directly observed nearby UAS as it is about 198 surveillance of areas too large for local direct visual observation & 199 direct RF link based ID (e.g., an entire air force base, or even 200 larger, a national forest) 202 1.2.2. Network RID 204 A RID data dictionary and data flow for Network RID are defined in 205 [F3411-19]. This data flow is emitted from an UAS via unspecified 206 means (but at least in part over the Internet) to a Network Remote ID 207 Service Provider (Net-RID SP). A Net-RID SP provides the RID data to 208 Network Remote ID Display Providers (Net-RID DP). It is the Net-RID 209 DP that responds to queries from Network Remote ID Observers 210 (expected typically, but not specified exclusively, to be web-based) 211 specifying airspace volumes of interest. Network RID depends upon 212 internet connectivity to fulfill Observers the RID data query to the 213 NET-RID DP. The summary of network RID data flows work as follows: 215 * The UA's RID data is generated from a UAS which consists of UAs 216 and GCSs. 218 * The RID data is transferred from the UA to the GCS via a RF (Radio 219 Frequency) link. 221 * The GCS or UA (e.g. BVLOS and autonomous operation) provides the 222 UA's RID data to a NET_RID_SP via a secure internet connection. 224 * NET_RID_DP as a NET_RID_SP subscriber and satisfies the Observer's 225 query request also via a secure internet connection. 227 The mimunum Network RID data flow is illustrated in Figure 2: 229 x x UA 230 xxxxx ******************** 231 | \ * ------*---+------------+ 232 | \ * / * | NET_RID_SP | 233 | \ * ------------/ +---*--+------------+ 234 | RF \ */ | * 235 | * INTERNET | * +------------+ 236 | /* +---*--| NET_RID_DP | 237 | / * +---*--+------------+ 238 + / * | * 239 x / *****************|*** x 240 xxxxx | xxxxx 241 x +------- x 242 x x 243 x x Operator (GCS) Observer x x 244 x x x x 246 Figure 2 248 Command and Control (C2) must flow from the GCS to the UA via some 249 path, currently (in the year of 2021) typically a direct RF link, but 250 with increasing beyond Visual Line of Sight (BVLOS) operations 251 expected often to be wireless links at either end with the Internet 252 between. 254 Telemetry (at least UA's position and heading) flows from the UA to 255 the GCS via some path, typically the reverse of the C2 path. Thus, 256 RID information pertaining to both the GCS and the UA can be sent, by 257 whichever has Internet connectivity, to the Net-RID SP, typically the 258 USS managing the UAS operation. 260 The Net-RID SP forwards RID information via the Internet to 261 subscribed Net-RID DP, typically USS. Subscribed Net-RID DP forward 262 RID information via the Internet to subscribed Observer devices. 263 Regulations require and [F3411-19] describes RID data elements that 264 must be transported end-to-end from the UAS to the subscribed 265 Observer devices. 267 [F3411-19] prescribes the protocols only between the Net-RID SP, Net- 268 RID DP, and the Discovery and Synchronization Service (DSS). DRIP 269 can address standardization of protocols between the UA and GCS, 270 between the UAS and the Net-RID SP, and/or between the Net-RID DP and 271 Observer devices. 273 [F3411-19] prescribes the protocols between the Net-RID SP, Net-RID 274 DP, and the Discovery and Synchronization Service (DSS). It also 275 prescribes data elements (in JSON) between Observer and DSS. DRIP 276 addresses standardization of secure protocols between the UA and GCS 277 (over direct wireless and Internet connection), between the UAS and 278 the Net-RID SP, and/or between the Net-RID DP and Observer devices. 280 Informative note: Neither link layer protocols nor the use of 281 links (e.g., the link often existing between the GCS and the 282 UA) for any purpose other than carriage of RID information is 283 in the scope of [F3411-19] Network RID. 285 1.3. Overview of USS Interoperability 287 With Net-RID, there is direct communication between the UAS and its 288 USS. With Broadcast-RID, the UAS Operator has either pre-filed a 4D 289 space volume for USS operational knowledge and/or Observers can be 290 providing information about observed UA to a USS. USS exchange 291 information via a Discovery and Synchronization Service (DSS) so all 292 USS collectively have knowledge about all activities in a 4D 293 airspace. 295 The interactions among Observer, UA, and USS are shown in Figure 3. 297 +----------+ 298 | Observer | 299 +----------+ 300 / \ 301 / \ 302 +-----+ +-----+ 303 | UAS1 | | UAS2 | 304 +-----+ +-----+ 305 \ / 306 \ / 307 +----------+ 308 | Internet | 309 +----------+ 310 / \ 311 / \ 312 +-------+ +-------+ 313 | USS1 | <-------> | USS2 | 314 +-------+ +-------+ 315 \ / 316 \ / 317 +------+ 318 | DSS | 319 +------+ 320 Figure 3 322 1.4. Overview of DRIP Architecture 324 The requirements document [I-D.ietf-drip-reqs] provides an extended 325 introduction to the problem space and use cases. Only a brief 326 summary of that introduction is restated here as context, with 327 reference to the general UAS RID usage scenarios shown in Figure 4. 329 General x x Public 330 Public xxxxx xxxxx Safety 331 Observer x x Observer 332 x x 333 x x ---------+ +---------- x x 334 x x | | x x 335 | | 336 UA1 x x | | +------------ x x UA2 337 xxxxx | | | xxxxx 338 | + + + | 339 | xxxxxxxxxx | 340 | x x | 341 +----------+x Internet x+------------+ 342 UA1 | x x | UA1 343 Pilot x | xxxxxxxxxx | x Pilot 344 Operator xxxxx + + + xxxxx Operator 345 GCS1 x | | | x GCS2 346 x | | | x 347 x x | | | x x 348 x x | | | x x 349 | | | 350 +----------+ | | | +----------+ 351 | |------+ | +-------| | 352 | Public | | | Private | 353 | Registry | +-----+ | Registry | 354 | | | DNS | | | 355 +----------+ +-----+ +----------+ 357 Figure 4 359 DRIP is meant to leverage existing Internet resources (standard 360 protocols, services, infrastructures, and business models) to meet 361 UAS RID and closely related needs. DRIP will specify how to apply 362 IETF standards, complementing [F3411-19] and other external 363 standards, to satisfy UAS RID requirements. 365 This document outlines the UAS RID architecture. This includes 366 presenting the gaps between the CAAs' Concepts of Operations and 367 [F3411-19] as it relates to the use of Internet technologies and UA 368 direct RF communications. Issues include, but are not limited to: 370 - Design of trustworthy remote ID and trust in RID messages 371 (Section 4) 373 - Mechanisms to leverage Domain Name System (including DNS: 374 [RFC1034]), Extensible Provisioning Protocol (EPP [RFC5731]) 375 and Registration Data Access Protocol (RDAP) ([RFC7482]) for 376 publishing public and private information (see Section 5.1 and 377 Section 5.2). 379 - Harvesting broadcast RID messages for UTM inclusion 380 (Section 6). 382 - Privacy in RID messages (PII protection) (Section 9). 384 2. Terms and Definitions 386 2.1. Architecture Terminology 388 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 389 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 390 "OPTIONAL" in this document are to be interpreted as described in BCP 391 14 [RFC2119] [RFC8174] when, and only when, they appear in all 392 capitals, as shown above. 394 2.2. Abbreviations 396 ADS-B: Automatic Dependent Surveillance Broadcast 398 DSS: Discovery & Synchronization Service 400 EdDSA: Edwards-Curve Digital Signature Algorithm 402 GCS: Ground Control Station 404 HHIT: Hierarchical HIT Registries 406 HIP: Host Identity Protocol 408 HIT: Host Identity Tag 410 RID: Remote ID 412 Net-RID SP: Network RID Service Provider 413 Net-RID DP: Network RID Display Provider. 415 PII: Personally Identifiable Information 417 RF: Radio Frequency 419 SDSP: Supplemental Data Service Provider 421 UA: Unmanned Aircraft 423 UAS: Unmanned Aircraft System 425 USS: UAS Service Supplier 427 UTM: UAS Traffic Management 429 2.3. Additional Definitions 431 This document uses terms defined in [I-D.ietf-drip-reqs]. 433 3. Claims, Assertions, Attestations, and Certificates 435 This section introduces the terms "Claims", "Assertions", 436 "Attestations", and "Certificates" as used in DRIP. DRIP certificate 437 has a different context compared with security certificates and 438 Public Key Infrastructure used in X.509. 440 Claims: 442 A claim in DRIP is a predicate (e.g., "X is Y", "X has property 443 Y", and most importantly "X owns Y" or "X is owned by Y"). 445 Assertions: 447 An assertion in DRIP is a set of claims. This definition is 448 borrowed from JWT [RFC7519] and CWT [RFC8392]. 450 Attestations: 452 An attestation in DRIP is a signed assertion. The signer may be a 453 claimant or a third party. Under DRIP this is normally used when 454 an entity asserts a relationship with another entity, along with 455 other information, and the asserting entity signs the assertion, 456 thereby making it an attestation. 458 Certificates: 460 A certificate in DRIP is an attestation, strictly over identity 461 information, signed by a third party. 463 4. HHIT as the DRIP Entity Identifier 465 This section describes the DRIP architectural approach to meeting the 466 basic requirements of a DRIP entity identifier within external 467 technical standard ASTM [F3411-19] and regulatory constraints. It 468 justifies and explains the use of Hierarchical Host Identity Tags 469 (HHITs) as self-asserting IPv6 addresses suitable as a UAS ID type 470 and more generally as trustworthy multipurpose remote identifiers. 472 Self-asserting in this usage is given the Host Identity (HI), the 473 HHIT ORCHID construction and a signature of the HHIT by the HI can 474 both be validated. The explicit registration hierarchy within the 475 HHIT provides registry discovery (managed by a Registrar) to either 476 yield the HI for 3rd-party (who is looking for ID attestation) 477 validation or prove the HHIT and HI have uniquely been registered. 479 4.1. UAS Remote Identifiers Problem Space 481 A DRIP entity identifier needs to be "Trustworthy" (See DRIP 482 Requirement about GEN-1, ID-4 and ID-5 in [I-D.ietf-drip-reqs]). 483 This means that within the framework of the RID messages, an Observer 484 can establish that the DRIP identifier uniquely belong to the UAS. 485 That the only way for any other UAS to assert this DRIP identifier 486 would be to steal something from within the UAS. The DRIP identifier 487 is self-generated by the UAS (either UA or GCS) and registered with 488 the USS. 490 The Broadcast RID data exchange faces extreme challenges due to the 491 limitation of the demanding support for Bluetooth. The ASTM 492 [F3411-19] defines the basic RID message which is expected to contain 493 certain RID data and the Authentication message. The Basic RID 494 message has a maximum payload of 25 bytes and the maximum size 495 allocated by ASTM for the RID is 20 bytes. currently, the 496 authentication maximum payload is defined to be 201 bytes (9 paged 497 Bluetooth 4 messages). 499 4.2. HIT as A Trustworthy DRIP Entity Identifier 501 A Remote ID that can be trustworthily used in the RID Broadcast mode 502 can be built from an asymmetric keypair. Rather than using a key 503 signing operation to claim ownership of an ID that does not guarantee 504 name uniqueness, in this method the ID is cryptographically derived 505 directly from the public key. The proof of ID ownership (verifiable 506 attestation, versus mere claim) is guaranteed by signing this 507 cryptographic ID with the associated private key. The association 508 between the ID and the private key is ensured by cryptographically 509 binding the public key with the ID, more specifically the ID results 510 from the hash of the public key. It is statistically hard for 511 another entity to create a public key that would generate (spoof) the 512 ID. 514 The HITs is designed statistically unique through the cryptographic 515 hash feature of second-preimage resistance. The cryptographically- 516 bound addition of the Hierarchy and an HHIT registration process 517 (e.g. based on Extensible Provisioning Protocol, [RFC5730]) provide 518 complete, global HHIT uniqueness. This registration forces the 519 attacker to generate the same public key rather than a public key 520 that generates the same HHIT. This is in contrast to general IDs 521 (e.g. a UUID or device serial number) as the subject in an X.509 522 certificate. 524 A DRIP identifier can be assigned to a UAS as a static HHIT by its 525 manufacturer, such as a single HI and derived HHIT encoded as a 526 hardware serial number per [CTA2063A]. Such a static HHIT can only 527 be used to bind one-time use DRIP identifiers to the unique UA. 528 Depending upon implementation, this may leave a HI private key in the 529 possession of the manufacturer (more details in Section 8). 531 In another case, a UAS equipped for Broadcast RID can be provisioned 532 not only with its HHIT but also with the HI public key from which the 533 HHIT was derived and the corresponding private key, to enable message 534 signature. A UAS equipped for Network RID can be provisioned 535 likewise; the private key resides only in the ultimate source of 536 Network RID messages (i.e. on the UA itself if the GCS is merely 537 relaying rather than sourcing Network RID messages). Each Observer 538 device can be provisioned either with public keys of the DRIP 539 identifier root registries or certificates for subordinate 540 registries. 542 HHITs can also be used throughout the USS/UTM system. The Operators, 543 Private Information Registries, as well as other UTM entities, can 544 use HHITs for their IDs. Such HHITs can facilitate DRIP security 545 functions such as used with HIP to strongly mutually authenticate and 546 encrypt communications. 548 A self-attestation of the HHIT RID can be done in as little as 84 549 bytes, by avoiding an explicit encoding technology like ASN.1 or 550 Concise Binary Object Representation (CBOR [RFC8949]). This 551 attestation consists of only the HHIT, a timestamp, and the EdDSA 552 signature on them. 554 An Observer would need Internet access to validate a self- 555 attestations claim. A third-party Certificate can be validated via a 556 small credential cache in a disconnected environment. This third- 557 party Certificate is possible when the third-party also uses HHITs 558 for its identity and the UA has the public key and the Certificate 559 for that HHIT. 561 4.3. HHIT for DRIP Identifier Registration and Lookup 563 Remote ID needs a deterministic lookup mechanism that rapidly 564 provides actionable information about the identified UA. Given the 565 size constraints imposed by the Bluetooth 4 broadcast media, the 566 Remote ID itself needs to be a non-spoofable inquiry input into the 567 lookup. 569 A DRIP registration process based on the explicit hierarchy within a 570 HHIT provides manageable uniqueness of the HI for the HHIT (defense 571 against a cryptographic hash second pre-image attack on the HHIT; 572 e.g. multiple HIs yielding the same HHIT). A lookup of the HHIT into 573 this registration data provides the registered HI for HHIT proof. A 574 first-come-first-serve registration for a HHIT provides deterministic 575 access to any other needed actionable information based on inquiry 576 access authority (more details in Section 5.2). 578 4.4. HHIT for DRIP Identifier Cryptographic 580 The only (known to the authors of this document at the time of its 581 writing) extant fixed-length ID cryptographically derived from a 582 public key are the Host Identity Tag [RFC7401], HITs, and 583 Cryptographically Generated Addresses [RFC3972], CGAs. However, both 584 HITs and CGAs lack registration/retrieval capability. HHIT, on the 585 other hand, is capable of providing a cryptographic hashing function, 586 along with a registration process to mitigate the probability of a 587 hash collision (first registered, first allowed). 589 5. DRIP Identifier Registration and Registries 591 DRIP registries hold both public and private UAS information 592 resulting from the DRIP identifier registration process. Given these 593 different uses, and to improve scalability, security, and simplicity 594 of administration, the public and private information can be stored 595 in different registries. This section introduces the public and 596 private information registries for DRIP identifiers. 598 5.1. Public Information Registry 599 5.1.1. Background 601 The public registry provides trustable information such as 602 attestations of RID ownership and registration with the HDA 603 (Hierarchical HIT Domain Authority). Optionally, pointers to the 604 repositories for the HDA and RAA (Registered Assigning 605 Authority)implicit in the RID can be included (e.g., for HDA and RAA 606 HHIT|HI used in attestation signing operations). This public 607 information will be principally used by Observers of Broadcast RID 608 messages. Data on UAS that only use Network RID, is available via an 609 Observer's Net-RID DP that would tend to directly provide all public 610 registry information. The Observer may visually "see" these Net-RID 611 UAS, but they may be silent to the Observer. The Net-RID DP is the 612 only source of information based on a query for an airspace volume. 614 5.1.2. DNS as the Public DRIP Identifier Registry 616 A DRIP identifier is amenable to handling as an Internet domain name 617 (at an arbitrary level in the hierarchy, e.g. in .ip6.arpa). Thus 618 DNS can provide all the needed public DRIP information. A 619 standardized HHIT FQDN (Fully Qualified Domain Name) can deliver the 620 HI via a HIP RR (Resource Record) [RFC8005] and other public 621 information (e.g., RRA and HDA ptrs, and HIP RVS (Rendezvous Servers) 622 [RFC8004]). These public information registries can use secure DNS 623 transport (e.g. DNS over TLS) to deliver public information that is 624 not inherently trustable (e.g. everything other than attestations). 626 5.2. Private Information Registry 628 5.2.1. Background 630 The private information required for DRIP identifiers is similar to 631 that required for Internet domain name registration. A DRIP 632 identifier solution can leverage existing Internet resources: 633 registration protocols, infrastructure, and business models, by 634 fitting into an ID structure compatible with DNS names. The HHIT 635 hierarchy can provide the needed scalability and management 636 structure. It is expected that the private registry function will be 637 provided by the same organizations that run a USS, and likely 638 integrated with a USS. The lookup function may be implemented by the 639 Net-RID DPs. 641 5.2.2. EPP and RDAP as the Private DRIP Identifier Registry 643 A DRIP private information registry supports essential registry 644 operations (e.g. add, delete, update, query) using interoperable open 645 standard protocols. It can accomplish this by using the Extensible 646 Provisioning Protocol (EPP [RFC5730]) and the Registry Data Access 647 Protocol (RDAP RFC7480] [RFC7482] [RFC7483]). The DRIP private 648 information registry in which a given UAS is registered needs to be 649 findable, starting from the UAS ID, using the methods specified in 650 [RFC7484]. 652 5.2.3. Alternative Private DRIP Registry methods 654 A DRIP private information registry might be an access controlled DNS 655 (e.g. via DNS over TLS). Additionally, WebFinger [RFC7033] can be 656 deployed. These alternative methods may be used by Net-RID DP with 657 specific customers. 659 6. Harvesting Broadcast Remote ID messages for UTM Inclusion 661 ASTM anticipated that regulators would require both Broadcast RID and 662 Network RID for large UAS, but allow RID requirements for small UAS 663 to be satisfied with the operator's choice of either Broadcast RID or 664 Network RID. The EASA initially specified Broadcast RID for UAS of 665 essentially all UAS and is now also considering Network RID. The FAA 666 RID Final Rules [FAA_RID] only specify Broadcast RID for UAS, 667 however, still encourages Network RID for complementary 668 functionality, especially in support of UTM. 670 One obvious opportunity is to enhance the architecture with gateways 671 from Broadcast RID to Network RID. This provides the best of both 672 and gives regulators and operators flexibility. It offers 673 considerable enhancement over some Network RID options such as only 674 reporting planned 4D operation space by the operator. 676 These gateways could be pre-positioned (e.g. around airports, public 677 gatherings, and other sensitive areas) and/or crowd-sourced (as 678 nothing more than a smartphone with a suitable app is needed). As 679 Broadcast RID media have limited range, gateways receiving messages 680 claiming locations far from the gateway can alert authorities or a 681 SDSP to the failed sanity check possibly indicating intent to 682 deceive. Surveillance SDSPs can use messages with precise date/time/ 683 position stamps from the gateways to multilaterate UA location, 684 independent of the locations claimed in the messages (which may have 685 a natural time lag as it is), which are entirely operator self- 686 reported in UAS RID and UTM, and thus are subject not only to natural 687 time lag and error but also operator misconfiguration or intentional 688 deception. 690 Further, gateways with additional sensors (e.g. smartphones with 691 cameras) can provide independent information on the UA type and size, 692 confirming or refuting those claims made in the RID messages. This 693 Crowd Sourced Remote ID (CS-RID) would be a significant enhancement, 694 beyond baseline DRIP functionality; if implemented, it adds two more 695 entity types. 697 6.1. The CS-RID Finder 699 A CS-RID Finder is the gateway for Broadcast Remote ID Messages into 700 the UTM. It performs this gateway function via a CS-RID SDSP. A CS- 701 RID Finder could implement, integrate, or accept outputs from, a 702 Broadcast RID receiver. However, it should not depend upon a direct 703 interface with a GCS, Net-RID SP, Net-RID DP or Network RID client. 704 It would present a TBD interface to a CS-RID SDSP; this interface 705 should be based upon but readily distinguishable from that between a 706 GCS and a Net-RID SP. 708 6.2. The CS-RID SDSP 710 A CS-RID SDSP would present a TBD interface to a CS-RID Finder; this 711 interface should be based upon but readily distinguishable from that 712 between a GCS and a Net-RID SP. A CS-RID SDSP should appear (i.e. 713 present the same interface) to a Net-RID SP as a Net-RID DP. 715 7. IANA Consideration 717 This document does not make any IANA request. 719 8. Security Considerations 721 The security provided by asymmetric cryptographic techniques depends 722 upon protection of the private keys. A manufacturer that embeds a 723 private key in an UA may have retained a copy. A manufacturer whose 724 UA are configured by a closed source application on the GCS which 725 communicates over the Internet with the factory may be sending a copy 726 of a UA or GCS self-generated key back to the factory. Keys may be 727 extracted from a GCS or UA. The RID sender of a small harmless UA 728 (or the entire UA) could be carried by a larger dangerous UA as a 729 "false flag." Compromise of a registry private key could do 730 widespread harm. Key revocation procedures are as yet to be 731 determined. These risks are in addition to those involving Operator 732 key management practices. 734 9. Privacy & Transparency Considerations 736 Broadcast RID messages can contain PII. A viable architecture for 737 PII protection would be symmetric encryption of the PII using a 738 session key known to the UAS and its USS. An authorized Observer 739 could send the encrypted PII along with the UAS ID (to the USS in 740 which the UAS ID is registered if that can be determined, e.g., from 741 received Broadcast RID information such as the UAS ID itself, or to 742 the Observer's USS, or to a Public Safety USS) to get the plaintext. 743 Alternatively, the authorized Observer can receive the key to 744 directly decrypt all PII content sent by that UA during that session 745 (UAS operation). 747 An authorized Observer can instruct a UAS via the USS that conditions 748 have changed mandating no PII protection or land the UA (abort the 749 operation). 751 PII can be protected unless the UAS is informed otherwise. This 752 could come as part of UTM operation authorization. It can be special 753 instructions at the start or during an operation. PII protection can 754 not be used if the UAS loses connectivity to the USS. The UAS always 755 has the option to abort the operation if PII protection is 756 disallowed. 758 10. References 760 10.1. Normative References 762 [I-D.ietf-drip-reqs] 763 Card, S. W., Wiethuechter, A., Moskowitz, R., and A. 764 Gurtov, "Drone Remote Identification Protocol (DRIP) 765 Requirements", Work in Progress, Internet-Draft, draft- 766 ietf-drip-reqs-17, 7 July 2021, 767 . 770 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 771 Requirement Levels", BCP 14, RFC 2119, 772 DOI 10.17487/RFC2119, March 1997, 773 . 775 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 776 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 777 May 2017, . 779 10.2. Informative References 781 [CTA2063A] ANSI, "Small Unmanned Aerial Systems Serial Numbers", 782 2019. 784 [Delegated] 785 European Union Aviation Safety Agency (EASA), "EU 786 Commission Delegated Regulation 2019/945 of 12 March 2019 787 on unmanned aircraft systems and on third-country 788 operators of unmanned aircraft systems", 2019. 790 [F3411-19] ASTM, "Standard Specification for Remote ID and Tracking", 791 2019. 793 [FAA_RID] United States Federal Aviation Administration (FAA), 794 "Remote Identification of Unmanned Aircraft", 2021, 795 . 798 [FAA_UAS_Concept_Of_Ops] 799 United States Federal Aviation Administration (FAA), 800 "Unmanned Aircraft System (UAS) Traffic Management (UTM) 801 Concept of Operations (V2.0)", 2020, 802 . 805 [Implementing] 806 European Union Aviation Safety Agency (EASA), "EU 807 Commission Implementing Regulation 2019/947 of 24 May 2019 808 on the rules and procedures for the operation of unmanned 809 aircraft", 2019. 811 [LAANC] United States Federal Aviation Administration (FAA), "Low 812 Altitude Authorization and Notification Capability", n.d., 813 . 816 [NPRM] United States Federal Aviation Administration (FAA), 817 "Notice of Proposed Rule Making on Remote Identification 818 of Unmanned Aircraft Systems", 2019. 820 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 821 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 822 . 824 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 825 RFC 3972, DOI 10.17487/RFC3972, March 2005, 826 . 828 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 829 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 830 . 832 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 833 Domain Name Mapping", STD 69, RFC 5731, 834 DOI 10.17487/RFC5731, August 2009, 835 . 837 [RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr, 838 "WebFinger", RFC 7033, DOI 10.17487/RFC7033, September 839 2013, . 841 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 842 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 843 RFC 7401, DOI 10.17487/RFC7401, April 2015, 844 . 846 [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access 847 Protocol (RDAP) Query Format", RFC 7482, 848 DOI 10.17487/RFC7482, March 2015, 849 . 851 [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the 852 Registration Data Access Protocol (RDAP)", RFC 7483, 853 DOI 10.17487/RFC7483, March 2015, 854 . 856 [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data 857 (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March 858 2015, . 860 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 861 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 862 . 864 [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 865 Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, 866 October 2016, . 868 [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name 869 System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, 870 October 2016, . 872 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 873 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 874 May 2018, . 876 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 877 Representation (CBOR)", STD 94, RFC 8949, 878 DOI 10.17487/RFC8949, December 2020, 879 . 881 [TS-22.825] 882 3GPP, "Study on Remote Identification of Unmanned Aerial 883 Systems (UAS)", n.d., 884 . 887 [U-Space] European Organization for the Safety of Air Navigation 888 (EUROCONTROL), "U-space Concept of Operations", 2019, 889 . 892 Appendix A. Overview of Unmanned Aircraft Systems (UAS) Traffic 893 Management (UTM) 895 A.1. Operation Concept 897 The National Aeronautics and Space Administration (NASA) and FAA's 898 effort of integrating UAS's operation into the national airspace 899 system (NAS) led to the development of the concept of UTM and the 900 ecosystem around it. The UTM concept was initially presented in 2013 901 and version 2.0 was published in 2020 [FAA_UAS_Concept_Of_Ops]. 903 The eventual concept refinement, initial prototype implementation and 904 testing were conducted by the UTM research transition team which is 905 the joint workforce by FAA and NASA. World efforts took place 906 afterward. The Single European Sky ATM Research (SESAR) started the 907 CORUS project to research its UTM counterpart concept, namely 908 [U-Space]. This effort is led by the European Organization for the 909 Safety of Air Navigation (Eurocontrol). 911 Both NASA and SESAR have published the UTM concept of operations to 912 guide the development of their future air traffic management (ATM) 913 system and ensure safe and efficient integrations of manned and 914 unmanned aircraft into the national airspace. 916 The UTM comprises UAS operation infrastructure, procedures and local 917 regulation compliance policies to guarantee safe UAS integration and 918 operation. The main functionality of a UTM includes, but is not 919 limited to, providing means of communication between UAS operators 920 and service providers and a platform to facilitate communication 921 among UAS service providers. 923 A.2. UAS Service Supplier (USS) 925 A USS plays an important role to fulfill the key performance 926 indicators (KPIs) that a UTM has to offer. Such Entity acts as a 927 proxy between UAS operators and UTM service providers. It provides 928 services like real-time UAS traffic monitoring and planning, 929 aeronautical data archiving, airspace and violation control, 930 interacting with other third-party control entities, etc. A USS can 931 coexist with other USS to build a large service coverage map which 932 can load-balance, relay and share UAS traffic information. 934 The FAA works with UAS industry shareholders and promotes the Low 935 Altitude Authorization and Notification Capability [LAANC] program 936 which is the first system to realize some of the UTM envisioned 937 functionality. The LAANC program can automate the UAS's flight plan 938 application and approval process for airspace authorization in real- 939 time by checking against multiple aeronautical databases such as 940 airspace classification and fly rules associated with it, FAA UAS 941 facility map, special use airspace, Notice to Airman (NOTAM), and 942 Temporary Flight Rule (TFR). 944 A.3. UTM Use Cases for UAS Operations 946 This section illustrates a couple of use case scenarios where UAS 947 participation in UTM has significant safety improvement. 949 1. For a UAS participating in UTM and taking off or landing in a 950 controlled airspace (e.g., Class Bravo, Charlie, Delta and Echo 951 in the United States), the USS under which the UAS is operating 952 is responsible for verifying UA registration, authenticating the 953 UAS operational intent (flight plan) by checking against 954 designated UAS fly map database, obtaining the air traffic 955 control (ATC) authorization and monitor the UAS flight path in 956 order to maintain safe margins and follow the pre-authorized 957 sequence of authorized 4-D volumes (route). 959 2. For a UAS participating in UTM and taking off or landing in an 960 uncontrolled airspace (ex. Class Golf in the United States), 961 pre-flight authorization must be obtained from a USS when 962 operating beyond-visual-of-sight (BVLOS). The USS either accepts 963 or rejects received operational intent (flight plan) from the 964 UAS. Accepted UAS operation may share its current flight data 965 such as GPS position and altitude to USS. The USS may keep the 966 UAS operation status near real-time and may keep it as a record 967 for overall airspace air traffic monitoring. 969 Appendix B. Automatic Dependent Surveillance Broadcast (ADS-B) 971 The ADS-B is the de jure technology used in manned aviation for 972 sharing location information, from the aircraft to ground and 973 satellite-based systems, designed in the early 2000s. Broadcast RID 974 is conceptually similar to ADS-B, but with the receiver target being 975 the general public on generally available devices (e.g. smartphones). 977 For numerous technical reasons, ADS-B itself is not suitable for low- 978 flying small UA. Technical reasons include but not limited to the 979 following: 981 1. Lack of support for the 1090 MHz ADS-B channel on any consumer 982 handheld devices 984 2. Weight and cost of ADS-B transponders on CSWaP constrained UA 986 3. Limited bandwidth of both uplink and downlink, which would likely 987 be saturated by large numbers of UAS, endangering manned aviation 989 Understanding these technical shortcomings, regulators worldwide have 990 ruled out the use of ADS-B for the small UAS for which UAS RID and 991 DRIP are intended. 993 Acknowledgements 995 The work of the FAA's UAS Identification and Tracking (UAS ID) 996 Aviation Rulemaking Committee (ARC) is the foundation of later ASTM 997 and proposed IETF DRIP WG efforts. The work of ASTM F38.02 in 998 balancing the interests of diverse stakeholders is essential to the 999 necessary rapid and widespread deployment of UAS RID. IETF 1000 volunteers who have contributed to this draft include Amelia 1001 Andersdotter and Mohamed Boucadair. 1003 Authors' Addresses 1005 Stuart W. Card 1006 AX Enterprize 1007 4947 Commercial Drive 1008 Yorkville, NY, 13495 1009 United States of America 1011 Email: stu.card@axenterprize.com 1013 Adam Wiethuechter 1014 AX Enterprize 1015 4947 Commercial Drive 1016 Yorkville, NY, 13495 1017 United States of America 1019 Email: adam.wiethuechter@axenterprize.com 1021 Robert Moskowitz 1022 HTT Consulting 1023 Oak Park, MI, 48237 1024 United States of America 1026 Email: rgm@labs.htt-consult.com 1028 Shuai Zhao 1029 Tencent 1030 2747 Park Blvd 1031 Palo Alto, 94588 1032 United States of America 1034 Email: shuai.zhao@ieee.org 1036 Andrei Gurtov 1037 Linköping University 1038 IDA 1039 SE-58183 Linköping Linköping 1040 Sweden 1042 Email: gurtov@acm.org