idnits 2.17.1 draft-ietf-drip-arch-14.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 232 has weird spacing: '...bserver x x...' == Line 339 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 (9 July 2021) is 1021 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 == Outdated reference: A later version (-37) exists of draft-ietf-drip-rid-07 -- Obsolete informational reference (is this intentional?): RFC 7482 (Obsoleted by RFC 9082) -- Obsolete informational reference (is this intentional?): RFC 7484 (Obsoleted by RFC 9224) Summary: 0 errors (**), 0 flaws (~~), 7 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: 10 January 2022 R. Moskowitz 6 HTT Consulting 7 S. Zhao (Editor) 8 Tencent 9 A. Gurtov 10 Linköping University 11 9 July 2021 13 Drone Remote Identification Protocol (DRIP) Architecture 14 draft-ietf-drip-arch-14 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 10 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 . . . . . . . . . . . . 6 63 1.4. Overview of DRIP Architecture . . . . . . . . . . . . . . 7 64 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 3. Definitions and Abbreviations . . . . . . . . . . . . . . . . 9 66 3.1. Additional Definitions . . . . . . . . . . . . . . . . . 9 67 3.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 9 68 3.3. Claims, Assertions, Attestations, and Certificates . . . 10 69 4. HHIT as the Primary DRIP Entity Identifier . . . . . . . . . 11 70 4.1. UAS Remote Identifiers Problem Space . . . . . . . . . . 11 71 4.2. HIT as A Trustworthy DRIP Entity Identifier . . . . . . . 12 72 4.3. HHIT for DRIP Identifier Registration and Lookup . . . . 14 73 4.4. HHIT for DRIP Identifier Cryptographic . . . . . . . . . 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. Proposed Approach . . . . . . . . . . . . . . . . . . 15 78 5.2. Private Information Registry . . . . . . . . . . . . . . 15 79 5.2.1. Background . . . . . . . . . . . . . . . . . . . . . 15 80 5.2.2. Proposed Approach . . . . . . . . . . . . . . . . . . 16 81 6. Harvesting Broadcast Remote ID messages for UTM Inclusion . . 16 82 6.1. The CS-RID Finder . . . . . . . . . . . . . . . . . . . . 17 83 6.2. The CS-RID SDSP . . . . . . . . . . . . . . . . . . . . . 17 84 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 17 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 86 9. Privacy & Transparency Considerations . . . . . . . . . . . . 18 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 89 10.2. Informative References . . . . . . . . . . . . . . . . . 18 90 Appendix A. Overview of Unmanned Aircraft Systems (UAS) Traffic 91 Management (UTM) . . . . . . . . . . . . . . . . . . . . 21 92 A.1. Operation Concept . . . . . . . . . . . . . . . . . . . . 21 93 A.2. UAS Service Supplier (USS) . . . . . . . . . . . . . . . 22 94 A.3. UTM Use Cases for UAS Operations . . . . . . . . . . . . 22 95 Appendix B. Automatic Dependent Surveillance Broadcast 96 (ADS-B) . . . . . . . . . . . . . . . . . . . . . . . . . 23 98 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 101 1. Introduction 103 This document describes an architecture for protocols and services to 104 support Unmanned Aircraft System Remote Identification and tracking 105 (UAS RID), plus RID-related communications. The architecture takes 106 into account both current (including proposed) regulations and non- 107 IETF technical standards. 109 The architecture adheres to the requirements listed in the DRIP 110 Requirements document [I-D.ietf-drip-reqs]. 112 1.1. Overview of Unmanned Aircraft System (UAS) Remote ID (RID) and 113 Standardization 115 CAAs currently promulgate performance-based regulations that do not 116 specify techniques, but rather cite industry consensus technical 117 standards as acceptable means of compliance. 119 UAS Remote Identification (RID) is an application enabler for a UAS 120 to be identified by Unmanned Aircraft Systems Traffic Management 121 (UTM) and UAS Service Supplier (USS) (Appendix A) or third parties 122 entities such as law enforcement. Many considerations (e.g., safety) 123 dictate that UAS be remotely identifiable. Civil Aviation 124 Authorities (CAAs) worldwide are mandating UAS RID. For example, the 125 European Union Aviation Safety Agency (EASA) has published 126 [Delegated] and [Implementing] Regulations. 128 Federal Aviation Administration (FAA) 130 The FAA published a Notice of Proposed Rule Making [NPRM] in 2019 131 and whereafter published the "Final Rule" in 2021 [FAA_RID]. In 132 FAA's final rule, it is clearly stated that Automatic Dependent 133 Surveillance Broadcast (ADS-B) Out and transponders can not be 134 used to serve the purpose of an remote identification. More 135 details about ADS-B can be found in Appendix B. 137 American Society for Testing and Materials (ASTM) 139 ASTM International, Technical Committee F38 (UAS), Subcommittee 140 F38.02 (Aircraft Operations), Work Item WK65041, developed the 141 ASTM [F3411-19] Standard Specification for Remote ID and Tracking. 143 ASTM defines one set of RID information and two means, MAC-layer 144 broadcast and IP-layer network, of communicating it. If an UAS 145 uses both communication methods, the same information must be 146 provided via both means. [F3411-19] is cited by FAA in its RID 147 final rule [FAA_RID] as "a potential means of compliance" to a 148 Remote ID rule. 150 The 3rd Generation Partnership Project (3GPP) 152 With release 16, the 3GPP completed the UAS RID requirement study 153 [TS-22.825] and proposed a set of use cases in the mobile network 154 and the services that can be offered based on RID. Release 17 155 specification focuses on enhanced UAS service requirements and 156 provides the protocol and application architecture support that 157 will be applicable for both 4G and 5G networks. 159 1.2. Overview of Types of UAS Remote ID 161 1.2.1. Broadcast RID 163 A set of RID messages are defined for direct, one-way, broadcast 164 transmissions from the UA over Bluetooth or Wi-Fi. These are 165 currently defined as MAC-Layer messages. Internet (or other Wide 166 Area Network) connectivity is only needed for UAS registry 167 information lookup by Observers using the directly received UAS ID. 168 Broadcast RID should be functionally usable in situations with no 169 Internet connectivity. 171 The minimum Broadcast RID data flow is illustrated in Figure 1. 173 x x UA 174 xxxxx 175 | 176 | 177 | app messages directly over 178 | one-way RF data link (no IP) 179 | 180 | 181 + 182 x 183 xxxxx 184 x 185 x 186 x x Observer's device (e.g. smartphone) 187 x x 189 Figure 1 191 With queries sent over the Internet using harvested RID (see 192 Section 6), the Observer may gain more information about those 193 visible UAS" is only true if the locally observed UAS is (or very 194 recently was) observed somewhere else; harvesting RID is not so much 195 about learning more about directly observed nearby UAS as it is about 196 surveillance of areas too large for local direct visual observation & 197 direct RF link based ID (e.g., an entire air force base, or even 198 larger, a national forest) 200 1.2.2. Network RID 202 A RID data dictionary and data flow for Network RID are defined in 203 [F3411-19]. This data flow is emitted from an UAS via unspecified 204 means (but at least in part over the Internet) to a Network Remote ID 205 Service Provider (Net-RID SP). A Net-RID SP provides the RID data to 206 Network Remote ID Display Providers (Net-RID DP). It is the Net-RID 207 DP that responds to queries from Network Remote ID Observers 208 (expected typically, but not specified exclusively, to be web-based) 209 specifying airspace volumes of interest. Network RID depends upon 210 connectivity, in several segments, via the Internet, from the UAS to 211 the Observer. 213 Editor-note 1: + list all the segments mentioned above + specify 214 how DRIP provide solutions for each segment 216 The mimunum Network RID data flow is illustrated in Figure 2: 218 x x UA 219 xxxxx ******************** 220 | \ * ------*---+------------+ 221 | \ * / * | NET_RID_SP | 222 | \ * ------------/ +---*--+------------+ 223 | RF \ */ | * 224 | * INTERNET | * +------------+ 225 | /* +---*--| NET_RID_DP | 226 | / * +---*--+------------+ 227 + / * | * 228 x / *****************|*** x 229 xxxxx | xxxxx 230 x +------- x 231 x x 232 x x Operator (GCS) Observer x x 233 x x x x 235 Figure 2 237 Command and Control (C2) must flow from the GCS to the UA via some 238 path, currently (in the year of 2021) typically a direct RF link, but 239 with increasing beyond Visual Line of Sight (BVLOS) operations 240 expected often to be wireless links at either end with the Internet 241 between. 243 Editor-note 2: Explain the difference with wireless and RF link 244 includes what are the end entities, usages for each transport 245 media. 247 For all but the simplest hobby aircraft, telemetry (at least position 248 and heading) flows from the UA to the GCS via some path, typically 249 the reverse of the C2 path. Thus, RID information pertaining to both 250 the GCS and the UA can be sent, by whichever has Internet 251 connectivity, to the Net-RID SP, typically the USS managing the UAS 252 operation. 254 Editor-note 3: Does all UAS support telemetry? explain what are 255 simplsest hobby aircraft vs UAS in general. Is it necessary to 256 keep "For all but the simplest hobby aircraft"? 258 The Net-RID SP forwards RID information via the Internet to 259 subscribed Net-RID DP, typically USS. Subscribed Net-RID DP forward 260 RID information via the Internet to subscribed Observer devices. 261 Regulations require and [F3411-19] describes RID data elements that 262 must be transported end-to-end from the UAS to the subscribed 263 Observer devices. 265 [F3411-19] prescribes the protocols only between the Net-RID SP, Net- 266 RID DP, and the Discovery and Synchronization Service (DSS). DRIP 267 may also address standardization of protocols between the UA and GCS, 268 between the UAS and the Net-RID SP, and/or between the Net-RID DP and 269 Observer devices. 271 Editor-note 4: "DRIP may also..." Specify what protocol DRIP can 272 or will standardize. 274 Informative note: Neither link layer protocols nor the use of 275 links (e.g., the link often existing between the GCS and the 276 UA) for any purpose other than carriage of RID information is 277 in the scope of [F3411-19] Network RID. 279 1.3. Overview of USS Interoperability 281 With Net-RID, there is direct communication between the UAS and its 282 USS. With Broadcast-RID, the UAS Operator has either pre-filed a 4D 283 space volume for USS operational knowledge and/or Observers can be 284 providing information about observed UA to a USS. USS exchange 285 information via a Discovery and Synchronization Service (DSS) so all 286 USS collectively have knowledge about all activities in a 4D 287 airspace. 289 The interactions among Observer, UA, and USS are shown in Figure 3. 291 +----------+ 292 | Observer | 293 +----------+ 294 / \ 295 / \ 296 +-----+ +-----+ 297 | UAS1 | | UAS2 | 298 +-----+ +-----+ 299 \ / 300 \ / 301 +----------+ 302 | Internet | 303 +----------+ 304 / \ 305 / \ 306 +-------+ +-------+ 307 | USS1 | <-------> | USS2 | 308 +-------+ +-------+ 309 \ / 310 \ / 311 +------+ 312 | DSS | 313 +------+ 315 Figure 3 317 1.4. Overview of DRIP Architecture 319 The requirements document [I-D.ietf-drip-reqs] provides an extended 320 introduction to the problem space and use cases. Only a brief 321 summary of that introduction is restated here as context, with 322 reference to the general UAS RID usage scenarios shown in Figure 4. 324 General x x Public 325 Public xxxxx xxxxx Safety 326 Observer x x Observer 327 x x 328 x x ---------+ +---------- x x 329 x x | | x x 330 | | 331 UA1 x x | | +------------ x x UA2 332 xxxxx | | | xxxxx 333 | + + + | 334 | xxxxxxxxxx | 335 | x x | 336 +----------+x Internet x+------------+ 337 UA1 | x x | UA1 338 Pilot x | xxxxxxxxxx | x Pilot 339 Operator xxxxx + + + xxxxx Operator 340 GCS1 x | | | x GCS2 341 x | | | x 342 x x | | | x x 343 x x | | | x x 344 | | | 345 +----------+ | | | +----------+ 346 | |------+ | +-------| | 347 | Public | | | Private | 348 | Registry | +-----+ | Registry | 349 | | | DNS | | | 350 +----------+ +-----+ +----------+ 352 Figure 4 354 DRIP is meant to leverage existing Internet resources (standard 355 protocols, services, infrastructures, and business models) to meet 356 UAS RID and closely related needs. DRIP will specify how to apply 357 IETF standards, complementing [F3411-19] and other external 358 standards, to satisfy UAS RID requirements. 360 This document outlines the UAS RID architecture. This includes 361 presenting the gaps between the CAAs' Concepts of Operations and 362 [F3411-19] as it relates to the use of Internet technologies and UA 363 direct RF communications. Issues include, but are not limited to: 365 - Design of trustworthy remote ID and trust in RID messages 366 (Section 4) 368 - Mechanisms to leverage Domain Name System (including DNS: 369 [RFC1034]), Extensible Provisioning Protocol (EPP [RFC5731]) 370 and Registration Data Access Protocol (RDAP) ([RFC7482]) for 371 publishing public and private information (see Section 5.1 and 372 Section 5.2). 374 - Harvesting broadcast RID messages for UTM inclusion 375 (Section 6). 377 - Privacy in RID messages (PII protection) (Section 9). 379 2. Conventions 381 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 382 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 383 "OPTIONAL" in this document are to be interpreted as described in BCP 384 14 [RFC2119] [RFC8174] when, and only when, they appear in all 385 capitals, as shown above. 387 3. Definitions and Abbreviations 389 Editor-note 13: 1) should we merge Section 2 and Section 3 2) how 390 should we list abbr in the Arch? Previous WG agreement is that 391 all the DRIP terms shall be defined in -reqs, which may or may not 392 be used in -reqs itself, but other documents such as Arch-. And 393 arch- can list terms when they are used in the arch- only. So 394 which is which ? 396 3.1. Additional Definitions 398 This document uses terms defined in [I-D.ietf-drip-reqs]. 400 3.2. Abbreviations 402 ADS-B: Automatic Dependent Surveillance Broadcast 404 DSS: Discovery & Synchronization Service 406 EdDSA: Edwards-Curve Digital Signature Algorithm 408 GCS: Ground Control Station 410 HHIT: Hierarchical HIT Registries 412 HIP: Host Identity Protocol 414 HIT: Host Identity Tag 415 RID: Remote ID 417 Net-RID SP: Network RID Service Provider 419 Net-RID DP: Network RID Display Provider. 421 PII: Personally Identifiable Information 423 RF: Radio Frequency 425 SDSP: Supplemental Data Service Provider 427 UA: Unmanned Aircraft 429 UAS: Unmanned Aircraft System 431 USS: UAS Service Supplier 433 UTM: UAS Traffic Management 435 3.3. Claims, Assertions, Attestations, and Certificates 437 This section introduces the terms "Claims", "Assertions", 438 "Attestations", and "Certificates" as used in DRIP. DRIP certificate 439 has a different context compared with security certificates and 440 Public Key Infrastructure used in X.509. 442 Editor-note 5: To be confirmed 444 Claims: 446 A claim in DRIP is a predicate (e.g., "X is Y", "X has property 447 Y", and most importantly "X owns Y" or "X is owned by Y"). 449 Assertions: 451 An assertion in DRIP is a set of claims. This definition is 452 borrowed from JWT [RFC7519] and CWT [RFC8392]. 454 Attestations: 456 An attestation in DRIP is a signed assertion. The signer may be a 457 claimant or a third party. Under DRIP this is normally used when 458 an entity asserts a relationship with another entity, along with 459 other information, and the asserting entity signs the assertion, 460 thereby making it an attestation. 462 Certificates: 464 A certificate in DRIP is an attestation, strictly over identity 465 information, signed by a third party. 467 4. HHIT as the Primary DRIP Entity Identifier 469 This section describes the DRIP architectural approach to meeting the 470 basic requirements of a DRIP entity identifier within external 471 technical standard ASTM [F3411-19] and regulatory constraints. It 472 justifies and explains the use of Hierarchical Host Identity Tags 473 (HHITs) as self-asserting IPv6 addresses suitable as a UAS ID type 474 and more generally as trustworthy multipurpose remote identifiers. 476 A HHIT, together with the Host Identity (HI) from which it is partly 477 derived, self-attests to its included explicit registration 478 hierarchy, providing Registrar discovery for a 3rd-party who is 479 looking for ID attestation retrieves the necessary information to the 480 registrar via a DNS request HHIT. 482 Editor-note 6: Is there a need to specify how self-attest works? 483 if yes then where? possible a new section under Section 4} 485 4.1. UAS Remote Identifiers Problem Space 487 Editor-note 14: Good to have: adding match requirment numbering 488 from requirement document 490 A DRIP entity identifier needs to be "Trustworthy". This means that 491 within the framework of the RID messages, an Observer can establish 492 that the DRIP identifier uniquely belong to the UAS. That the only 493 way for any other UAS to assert this DRIP identifier would be to 494 steal something from within the UAS. The DRIP identifier is self- 495 generated by the UAS (either UA or GCS) and registered with the USS. 497 The Broadcast RID data exchange faces extreme challenges due to the 498 limitation of the demanding support for Bluetooth. The ASTM 499 [F3411-19] defines the basic RID message which is expected to contain 500 certain RID data and the Authentication message. The Basic RID 501 message has a maximum payload of 25 bytes and the maximum size 502 allocated by ASTM for the RID is 20 bytes and only 3 bytes are left 503 unused. currently, the authentication maximum payload is defined to 504 be 201 bytes. 506 Editor-note 7: To be more specific about the RID message header 507 and payload structure, such as 1) list different type of BRID 508 messages defined in ASTM F3411, 2) how many bytes for each filed. 510 Standard approaches like X.509 and PKI will not fit these 511 constraints, even using the new EdDSA [RFC8032] algorithm cannot fit 512 within the maximum 201 byte limit, due in large measure to ASN.1 513 encoding format overhead. 515 An example of a technology that will fit within these limitations is 516 an enhancement of the Host Identity Tag (HIT) of HIPv2 [RFC7401] 517 using Hierarchical HITs (HHITs) for UAS RID [I-D.ietf-drip-rid]. As 518 PKI with X.509 is being used in other systems with which UAS RID must 519 interoperate (e.g. Discovery and Synchronization Service and any 520 other communications involving USS) mappings between the more 521 flexible but larger X.509 certificates and the HHIT-based structures 522 can must be devised. This could be as in [RFC8002] or simply the 523 HHIT as Subject Alternative Name (SAN) and no Distinguished Name 524 (DN). 526 Editor-note 8: is there a need to explain the how binding/proxy/ 527 translation between the HHIT and X509? Should this be addressed 528 in Arch- or solution? 530 A self-attestation of the HHIT RID can be done in as little as 84 531 bytes, by avoiding an explicit encoding technology like ASN.1 or 532 Concise Binary Object Representation (CBOR [RFC8949]). This 533 compressed attestation consists of only the HHIT, a timestamp, and 534 the EdDSA signature on them. 536 Editor-note 9: to be more specific regarding how HHIT can only use 537 as little as 84 bytes to address the crypto concern. 539 The HHIT prefix and suiteID provide crypto agility and implicit 540 encoding rules. Similarly, a self-attestation of the Hierarchical 541 registration of the RID (an attestation of a RID third-party 542 registration "certificate") can be done in 200 bytes. Both these are 543 detailed in UAS RID [I-D.ietf-drip-rid]. 545 Editor-note 10: to be more specific why 200 bytes is sufficient. 547 An Observer would need Internet access to validate a self- 548 attestations claim. A third-party Certificate can be validated via a 549 small credential cache in a disconnected environment. This third- 550 party Certificate is possible when the third-party also uses HHITs 551 for its identity and the UA has the public key and the Certificate 552 for that HHIT. 554 4.2. HIT as A Trustworthy DRIP Entity Identifier 556 Editor-note 15: general comments about rewrite of this section due 557 to lack of coherence. 559 A Remote ID that can be trustworthily used in the RID Broadcast mode 560 can be built from an asymmetric keypair. Rather than using a key 561 signing operation to claim ownership of an ID that does not guarantee 562 name uniqueness, in this method the ID is cryptographically derived 563 directly from the public key. The proof of ID ownership (verifiable 564 attestation, versus mere claim) is guaranteed by signing this 565 cryptographic ID with the associated private key. The association 566 between the ID and the private key is ensured by cryptographically 567 binding the public key with the ID, more specifically the ID results 568 from the hash of the public key. It is statistically hard for 569 another entity to create a public key that would generate (spoof) the 570 ID. 572 The HITs is designed statistically unique through the cryptographic 573 hash feature of second-preimage resistance. The cryptographically- 574 bound addition of the Hierarchy and an HHIT registration process 575 (e.g. based on Extensible Provisioning Protocol, [RFC5730]) provide 576 complete, global HHIT uniqueness. This registration forces the 577 attacker to generate the same public key rather than a public key 578 that generates the same HHIT. This is in contrast to general IDs 579 (e.g. a UUID or device serial number) as the subject in an X.509 580 certificate. 582 Editor-note 11: Explain how HIT itself and HHIT registry address 583 naming collision. 585 A DRIP identifier can be assigned to a UAS as a static HHIT by its 586 manufacturer, such as a single HI and derived HHIT encoded as a 587 hardware serial number per [CTA2063A]. Such a static HHIT can only 588 be used to bind one-time use DRIP identifiers to the unique UA. 589 Depending upon implementation, this may leave a HI private key in the 590 possession of the manufacturer (more details in Section 8). 592 In another case, a UAS equipped for Broadcast RID can be provisioned 593 not only with its HHIT but also with the HI public key from which the 594 HHIT was derived and the corresponding private key, to enable message 595 signature. A UAS equipped for Network RID can be provisioned 596 likewise; the private key resides only in the ultimate source of 597 Network RID messages (i.e. on the UA itself if the GCS is merely 598 relaying rather than sourcing Network RID messages). Each Observer 599 device can be provisioned either with public keys of the DRIP 600 identifier root registries or certificates for subordinate 601 registries. 603 HHITs can also be used throughout the USS/UTM system. The Operators, 604 Private Information Registries, as well as other UTM entities, can 605 use HHITs for their IDs. Such HHITs can facilitate DRIP security 606 functions such as used with HIP to strongly mutually authenticate and 607 encrypt communications. 609 4.3. HHIT for DRIP Identifier Registration and Lookup 611 Remote ID needs a deterministic lookup mechanism that rapidly 612 provides actionable information about the identified UA. Given the 613 size constraints imposed by the Bluetooth 4 broadcast media, the 614 Remote ID itself needs to be the inquiry input into the lookup. An 615 HHIT DRIP identifier contains cryptographically embedded registration 616 information. This HHIT registration hierarchy, along with the IPv6 617 prefix, is trustable and sufficient information that can be used to 618 perform such a lookup. Additionally, the IPv6 prefix can enhance the 619 HHITs use beyond the basic Remote ID function (e.g use in HIP, 620 [RFC7401]). 622 Editor-note 12: more description regarding 1) Is that something we 623 should address in the Arch- 2) if yes, then adding more text about 624 how a trustable lookup is performed 626 Therefore, a DRIP identifier can be represented as a HHIT. It can be 627 self-generated by a UAS (either UA or GCS) and registered with the 628 Private Information Registry (More details in Section 5.2) identified 629 in its hierarchy fields. Each DRIP identifier represented as an HHIT 630 can not be used more than once. 632 4.4. HHIT for DRIP Identifier Cryptographic 634 The only (known to the authors of this document at the time of its 635 writing) extant fixed-length ID cryptographically derived from a 636 public key are the Host Identity Tag [RFC7401], HITs, and 637 Cryptographically Generated Addresses [RFC3972], CGAs. However, both 638 HITs and CGAs lack registration/retrieval capability. HHIT, on the 639 other hand, is capable of providing a cryptographic hashing function, 640 along with a registration process to mitigate the probability of a 641 hash collision (first registered, first allowed). 643 5. DRIP Identifier Registration and Registries 645 Editor-note 16: Fundamentally disagree with not actually 646 specifying an architecture in the DRIP Architecture document (From 647 Stuart Card) 649 UAS registries can hold both public and private UAS information 650 resulting from the DRIP identifier registration process. Given these 651 different uses, and to improve scalability, security, and simplicity 652 of administration, the public and private information can be stored 653 in different registries. A DRIP identifier is amenable to handling 654 as an Internet domain name (at an arbitrary level in the hierarchy). 655 It also can be registered in at least a pseudo-domain (e.g. .ip6.arpa 656 for reverse lookup), or as a sub-domain (for forward lookup). This 657 section introduces the public and private information registries for 658 DRIP identifiers. 660 5.1. Public Information Registry 662 5.1.1. Background 664 The public registry provides trustable information such as 665 attestations of RID ownership and HDA registration. Optionally, 666 pointers to the repositories for the HDA and RAA implicit in the RID 667 can be included (e.g. for HDA and RAA HHIT|HI used in attestation 668 signing operations). This public information will be principally 669 used by Observers of Broadcast RID messages. Data on UAS that only 670 use Network RID, is only available via an Observer's Net-RID DP that 671 would tend to provide all public registry information directly. The 672 Observer can visually "see" these UAS, but they are silent to the 673 Observer; the Net-RID DP is the only source of information based on a 674 query for an airspace volume. 676 5.1.2. Proposed Approach 678 A DRIP public information registry can respond to standard DNS 679 queries, in the definitive public Internet DNS hierarchy. If a DRIP 680 public information registry lists, in a HIP RR, any HIP RVS servers 681 for a given DRIP identifier, those RVS servers can restrict relay 682 services per AAA policy; this requires extensions to [RFC8004]. 683 These public information registries can use secure DNS transport 684 (e.g. DNS over TLS) to deliver public information that is not 685 inherently trustable (e.g. everything other than attestations). 687 5.2. Private Information Registry 689 5.2.1. Background 691 The private information required for DRIP identifiers is similar to 692 that required for Internet domain name registration. A DRIP 693 identifier solution can leverage existing Internet resources: 694 registration protocols, infrastructure and business models, by 695 fitting into an ID structure compatible with DNS names. This implies 696 some sort of hierarchy, for scalability, and management of this 697 hierarchy. It is expected that the private registry function will be 698 provided by the same organizations that run a USS, and likely 699 integrated with a USS. 701 5.2.2. Proposed Approach 703 A DRIP private information registry can support essential Internet 704 domain name registry operations (e.g. add, delete, update, query) 705 using interoperable open standard protocols. It can also support the 706 Extensible Provisioning Protocol (EPP) and the Registry Data Access 707 Protocol (RDAP) with access controls. It might be listed in a DNS: 708 that DNS could be private; but absent any compelling reasons for use 709 of private DNS, a public DNS hierarchy needs to be in place. The 710 DRIP private information registry in which a given UAS is registered 711 needs to be findable, starting from the UAS ID, using the methods 712 specified in [RFC7484]. A DRIP private information registry can also 713 support WebFinger as specified in [RFC7033]. 715 6. Harvesting Broadcast Remote ID messages for UTM Inclusion 717 ASTM anticipated that regulators would require both Broadcast RID and 718 Network RID for large UAS, but allow RID requirements for small UAS 719 to be satisfied with the operator's choice of either Broadcast RID or 720 Network RID. The EASA initially specified Broadcast RID for UAS of 721 essentially all UAS and is now also considering Network RID. The FAA 722 RID Final Rules [FAA_RID] only specify Broadcast RID for UAS, 723 however, still encourages Network RID for complementary 724 functionality, especially in support of UTM. 726 One obvious opportunity is to enhance the architecture with gateways 727 from Broadcast RID to Network RID. This provides the best of both 728 and gives regulators and operators flexibility. It offers 729 considerable enhancement over some Network RID options such as only 730 reporting planned 4D operation space by the operator. 732 These gateways could be pre-positioned (e.g. around airports, public 733 gatherings, and other sensitive areas) and/or crowd-sourced (as 734 nothing more than a smartphone with a suitable app is needed). As 735 Broadcast RID media have limited range, gateways receiving messages 736 claiming locations far from the gateway can alert authorities or a 737 SDSP to the failed sanity check possibly indicating intent to 738 deceive. Surveillance SDSPs can use messages with precise date/time/ 739 position stamps from the gateways to multilaterate UA location, 740 independent of the locations claimed in the messages (which may have 741 a natural time lag as it is), which are entirely operator self- 742 reported in UAS RID and UTM, and thus are subject not only to natural 743 time lag and error but also operator misconfiguration or intentional 744 deception. 746 Further, gateways with additional sensors (e.g. smartphones with 747 cameras) can provide independent information on the UA type and size, 748 confirming or refuting those claims made in the RID messages. This 749 Crowd Sourced Remote ID (CS-RID) would be a significant enhancement, 750 beyond baseline DRIP functionality; if implemented, it adds two more 751 entity types. 753 6.1. The CS-RID Finder 755 A CS-RID Finder is the gateway for Broadcast Remote ID Messages into 756 the UTM. It performs this gateway function via a CS-RID SDSP. A CS- 757 RID Finder could implement, integrate, or accept outputs from, a 758 Broadcast RID receiver. However, it should not depend upon a direct 759 interface with a GCS, Net-RID SP, Net-RID DP or Network RID client. 760 It would present a TBD interface to a CS-RID SDSP; this interface 761 should be based upon but readily distinguishable from that between a 762 GCS and a Net-RID SP. 764 6.2. The CS-RID SDSP 766 A CS-RID SDSP would present a TBD interface to a CS-RID Finder; this 767 interface should be based upon but readily distinguishable from that 768 between a GCS and a Net-RID SP. A CS-RID SDSP should appear (i.e. 769 present the same interface) to a Net-RID SP as a Net-RID DP. 771 7. IANA Consideration 773 This document does not make any IANA request. 775 8. Security Considerations 777 The security provided by asymmetric cryptographic techniques depends 778 upon protection of the private keys. A manufacturer that embeds a 779 private key in an UA may have retained a copy. A manufacturer whose 780 UA are configured by a closed source application on the GCS which 781 communicates over the Internet with the factory may be sending a copy 782 of a UA or GCS self-generated key back to the factory. Keys may be 783 extracted from a GCS or UA. The RID sender of a small harmless UA 784 (or the entire UA) could be carried by a larger dangerous UA as a 785 "false flag." Compromise of a registry private key could do 786 widespread harm. Key revocation procedures are as yet to be 787 determined. These risks are in addition to those involving Operator 788 key management practices. 790 9. Privacy & Transparency Considerations 792 Broadcast RID messages can contain PII. A viable architecture for 793 PII protection would be symmetric encryption of the PII using a 794 session key known to the UAS and its USS. An authorized Observer 795 could send the encrypted PII along with the UAS ID (to the USS in 796 which the UAS ID is registered if that can be determined, e.g., from 797 received Broadcast RID information such as the UAS ID itself, or to 798 the Observer's USS, or to a Public Safety USS) to get the plaintext. 799 Alternatively, the authorized Observer can receive the key to 800 directly decrypt all PII content sent by that UA during that session 801 (UAS operation). 803 An authorized Observer can instruct a UAS via the USS that conditions 804 have changed mandating no PII protection or land the UA (abort the 805 operation). 807 PII can be protected unless the UAS is informed otherwise. This 808 could come as part of UTM operation authorization. It can be special 809 instructions at the start or during an operation. PII protection can 810 not be used if the UAS loses connectivity to the USS. The UAS always 811 has the option to abort the operation if PII protection is 812 disallowed. 814 10. References 816 10.1. Normative References 818 [I-D.ietf-drip-reqs] 819 Card, S. W., Wiethuechter, A., Moskowitz, R., and A. 820 Gurtov, "Drone Remote Identification Protocol (DRIP) 821 Requirements", Work in Progress, Internet-Draft, draft- 822 ietf-drip-reqs-17, 7 July 2021, 823 . 826 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 827 Requirement Levels", BCP 14, RFC 2119, 828 DOI 10.17487/RFC2119, March 1997, 829 . 831 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 832 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 833 May 2017, . 835 10.2. Informative References 837 [CTA2063A] ANSI, "Small Unmanned Aerial Systems Serial Numbers", 838 2019. 840 [Delegated] 841 European Union Aviation Safety Agency (EASA), "EU 842 Commission Delegated Regulation 2019/945 of 12 March 2019 843 on unmanned aircraft systems and on third-country 844 operators of unmanned aircraft systems", 2019. 846 [F3411-19] ASTM, "Standard Specification for Remote ID and Tracking", 847 2019. 849 [FAA_RID] United States Federal Aviation Administration (FAA), 850 "Remote Identification of Unmanned Aircraft", 2021, 851 . 854 [FAA_UAS_Concept_Of_Ops] 855 United States Federal Aviation Administration (FAA), 856 "Unmanned Aircraft System (UAS) Traffic Management (UTM) 857 Concept of Operations (V2.0)", 2020, 858 . 861 [I-D.ietf-drip-rid] 862 Moskowitz, R., Card, S. W., Wiethuechter, A., and A. 863 Gurtov, "UAS Remote ID", Work in Progress, Internet-Draft, 864 draft-ietf-drip-rid-07, 28 January 2021, 865 . 868 [Implementing] 869 European Union Aviation Safety Agency (EASA), "EU 870 Commission Implementing Regulation 2019/947 of 24 May 2019 871 on the rules and procedures for the operation of unmanned 872 aircraft", 2019. 874 [LAANC] United States Federal Aviation Administration (FAA), "Low 875 Altitude Authorization and Notification Capability", n.d., 876 . 879 [NPRM] United States Federal Aviation Administration (FAA), 880 "Notice of Proposed Rule Making on Remote Identification 881 of Unmanned Aircraft Systems", 2019. 883 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 884 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 885 . 887 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 888 RFC 3972, DOI 10.17487/RFC3972, March 2005, 889 . 891 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 892 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 893 . 895 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 896 Domain Name Mapping", STD 69, RFC 5731, 897 DOI 10.17487/RFC5731, August 2009, 898 . 900 [RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr, 901 "WebFinger", RFC 7033, DOI 10.17487/RFC7033, September 902 2013, . 904 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 905 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 906 RFC 7401, DOI 10.17487/RFC7401, April 2015, 907 . 909 [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access 910 Protocol (RDAP) Query Format", RFC 7482, 911 DOI 10.17487/RFC7482, March 2015, 912 . 914 [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data 915 (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March 916 2015, . 918 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 919 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 920 . 922 [RFC8002] Heer, T. and S. Varjonen, "Host Identity Protocol 923 Certificates", RFC 8002, DOI 10.17487/RFC8002, October 924 2016, . 926 [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 927 Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, 928 October 2016, . 930 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 931 Signature Algorithm (EdDSA)", RFC 8032, 932 DOI 10.17487/RFC8032, January 2017, 933 . 935 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 936 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 937 May 2018, . 939 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 940 Representation (CBOR)", STD 94, RFC 8949, 941 DOI 10.17487/RFC8949, December 2020, 942 . 944 [TS-22.825] 945 3GPP, "Study on Remote Identification of Unmanned Aerial 946 Systems (UAS)", n.d., 947 . 950 [U-Space] European Organization for the Safety of Air Navigation 951 (EUROCONTROL), "U-space Concept of Operations", 2019, 952 . 955 Appendix A. Overview of Unmanned Aircraft Systems (UAS) Traffic 956 Management (UTM) 958 A.1. Operation Concept 960 The National Aeronautics and Space Administration (NASA) and FAA's 961 effort of integrating UAS's operation into the national airspace 962 system (NAS) led to the development of the concept of UTM and the 963 ecosystem around it. The UTM concept was initially presented in 2013 964 and version 2.0 was published in 2020 [FAA_UAS_Concept_Of_Ops]. 966 The eventual concept refinement, initial prototype implementation and 967 testing were conducted by the UTM research transition team which is 968 the joint workforce by FAA and NASA. World efforts took place 969 afterward. The Single European Sky ATM Research (SESAR) started the 970 CORUS project to research its UTM counterpart concept, namely 971 [U-Space]. This effort is led by the European Organization for the 972 Safety of Air Navigation (Eurocontrol). 974 Both NASA and SESAR have published the UTM concept of operations to 975 guide the development of their future air traffic management (ATM) 976 system and ensure safe and efficient integrations of manned and 977 unmanned aircraft into the national airspace. 979 The UTM comprises UAS operation infrastructure, procedures and local 980 regulation compliance policies to guarantee safe UAS integration and 981 operation. The main functionality of a UTM includes, but is not 982 limited to, providing means of communication between UAS operators 983 and service providers and a platform to facilitate communication 984 among UAS service providers. 986 A.2. UAS Service Supplier (USS) 988 A USS plays an important role to fulfill the key performance 989 indicators (KPIs) that a UTM has to offer. Such Entity acts as a 990 proxy between UAS operators and UTM service providers. It provides 991 services like real-time UAS traffic monitoring and planning, 992 aeronautical data archiving, airspace and violation control, 993 interacting with other third-party control entities, etc. A USS can 994 coexist with other USS to build a large service coverage map which 995 can load-balance, relay and share UAS traffic information. 997 The FAA works with UAS industry shareholders and promotes the Low 998 Altitude Authorization and Notification Capability [LAANC] program 999 which is the first system to realize some of the UTM envisioned 1000 functionality. The LAANC program can automate the UAS's flight plan 1001 application and approval process for airspace authorization in real- 1002 time by checking against multiple aeronautical databases such as 1003 airspace classification and fly rules associated with it, FAA UAS 1004 facility map, special use airspace, Notice to Airman (NOTAM), and 1005 Temporary Flight Rule (TFR). 1007 A.3. UTM Use Cases for UAS Operations 1009 This section illustrates a couple of use case scenarios where UAS 1010 participation in UTM has significant safety improvement. 1012 1. For a UAS participating in UTM and taking off or landing in a 1013 controlled airspace (e.g., Class Bravo, Charlie, Delta and Echo 1014 in the United States), the USS under which the UAS is operating 1015 is responsible for verifying UA registration, authenticating the 1016 UAS operational intent (flight plan) by checking against 1017 designated UAS fly map database, obtaining the air traffic 1018 control (ATC) authorization and monitor the UAS flight path in 1019 order to maintain safe margins and follow the pre-authorized 1020 sequence of authorized 4-D volumes (route). 1022 2. For a UAS participating in UTM and taking off or landing in an 1023 uncontrolled airspace (ex. Class Golf in the United States), 1024 pre-flight authorization must be obtained from a USS when 1025 operating beyond-visual-of-sight (BVLOS). The USS either accepts 1026 or rejects received operational intent (flight plan) from the 1027 UAS. Accepted UAS operation may share its current flight data 1028 such as GPS position and altitude to USS. The USS may keep the 1029 UAS operation status near real-time and may keep it as a record 1030 for overall airspace air traffic monitoring. 1032 Appendix B. Automatic Dependent Surveillance Broadcast (ADS-B) 1034 The ADS-B is the de jure technology used in manned aviation for 1035 sharing location information, from the aircraft to ground and 1036 satellite-based systems, designed in the early 2000s. Broadcast RID 1037 is conceptually similar to ADS-B, but with the receiver target being 1038 the general public on generally available devices (e.g. smartphones). 1040 For numerous technical reasons, ADS-B itself is not suitable for low- 1041 flying small UA. Technical reasons include but not limited to the 1042 following: 1044 1. Lack of support for the 1090 MHz ADS-B channel on any consumer 1045 handheld devices 1047 2. Weight and cost of ADS-B transponders on CSWaP constrained UA 1049 3. Limited bandwidth of both uplink and downlink, which would likely 1050 be saturated by large numbers of UAS, endangering manned aviation 1052 Understanding these technical shortcomings, regulators worldwide have 1053 ruled out the use of ADS-B for the small UAS for which UAS RID and 1054 DRIP are intended. 1056 Acknowledgements 1058 The work of the FAA's UAS Identification and Tracking (UAS ID) 1059 Aviation Rulemaking Committee (ARC) is the foundation of later ASTM 1060 and proposed IETF DRIP WG efforts. The work of ASTM F38.02 in 1061 balancing the interests of diverse stakeholders is essential to the 1062 necessary rapid and widespread deployment of UAS RID. IETF 1063 volunteers who have contributed to this draft include Amelia 1064 Andersdotter and Mohamed Boucadair. 1066 Authors' Addresses 1068 Stuart W. Card 1069 AX Enterprize 1070 4947 Commercial Drive 1071 Yorkville, NY, 13495 1072 United States of America 1074 Email: stu.card@axenterprize.com 1075 Adam Wiethuechter 1076 AX Enterprize 1077 4947 Commercial Drive 1078 Yorkville, NY, 13495 1079 United States of America 1081 Email: adam.wiethuechter@axenterprize.com 1083 Robert Moskowitz 1084 HTT Consulting 1085 Oak Park, MI, 48237 1086 United States of America 1088 Email: rgm@labs.htt-consult.com 1090 Shuai Zhao 1091 Tencent 1092 2747 Park Blvd 1093 Palo Alto, 94588 1094 United States of America 1096 Email: shuai.zhao@ieee.org 1098 Andrei Gurtov 1099 Linköping University 1100 IDA 1101 SE-58183 Linköping Linköping 1102 Sweden 1104 Email: gurtov@acm.org