idnits 2.17.1 draft-ietf-drip-arch-12.txt: 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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([I-D.ietf-drip-reqs]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 226 has weird spacing: '...bserver x x...' == Line 320 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 (May 10, 2021) is 1081 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-10 == 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: 2 errors (**), 0 flaws (~~), 6 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: November 11, 2021 R. Moskowitz 6 HTT Consulting 7 S. Zhao (Editor) 8 Tencent 9 A. Gurtov 10 Linkoeping University 11 May 10, 2021 13 Drone Remote Identification Protocol (DRIP) Architecture 14 draft-ietf-drip-arch-12 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, conforming to proposed 21 and final regulations plus external technical standards, satisfying 22 the requirements listed in the companion requirements document 23 [I-D.ietf-drip-reqs]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 11, 2021. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Overview of Unmanned Aircraft System (UAS) Remote ID 61 (RID) and Standardization . . . . . . . . . . . . . . . . 3 62 1.2. Overview of Types of UAS Remote ID . . . . . . . . . . . 4 63 1.2.1. Broadcast RID . . . . . . . . . . . . . . . . . . . . 4 64 1.2.2. Network RID . . . . . . . . . . . . . . . . . . . . . 5 65 1.3. Overview of USS Interoperability . . . . . . . . . . . . 6 66 1.4. Overview of DRIP Architecture . . . . . . . . . . . . . . 7 67 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 3. Definitions and Abbreviations . . . . . . . . . . . . . . . . 9 69 3.1. Additional Definitions . . . . . . . . . . . . . . . . . 9 70 3.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 9 71 3.3. Claims, Assertions, Attestations, and Certificates . . . 10 72 4. HHIT for DRIP Entity Identifier . . . . . . . . . . . . . . . 11 73 4.1. UAS Remote Identifiers Problem Space . . . . . . . . . . 11 74 4.2. HIT as A Trustworthy DRIP Entity Identifier . . . . . . . 12 75 4.3. HHIT for DRIP Identifier Registration and Lookup . . . . 13 76 4.4. HHIT for DRIP Identifier Cryptographic . . . . . . . . . 13 77 5. DRIP Identifier Registration and Registries . . . . . . . . . 14 78 5.1. Public Information Registry . . . . . . . . . . . . . . . 14 79 5.1.1. Background . . . . . . . . . . . . . . . . . . . . . 14 80 5.1.2. Proposed Approach . . . . . . . . . . . . . . . . . . 14 81 5.2. Private Information Registry . . . . . . . . . . . . . . 15 82 5.2.1. Background . . . . . . . . . . . . . . . . . . . . . 15 83 5.2.2. Proposed Approach . . . . . . . . . . . . . . . . . . 15 84 6. Harvesting Broadcast Remote ID messages for UTM Inclusion . . 15 85 6.1. The CS-RID Finder . . . . . . . . . . . . . . . . . . . . 16 86 6.2. The CS-RID SDSP . . . . . . . . . . . . . . . . . . . . . 16 87 7. Privacy for Broadcast PII . . . . . . . . . . . . . . . . . . 16 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 89 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 91 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 92 10.2. Informative References . . . . . . . . . . . . . . . . . 18 93 Appendix A. Overview of Unmanned Aircraft Systems (UAS) Traffic 94 Management (UTM) . . . . . . . . . . . . . . . . . . 20 95 A.1. Operation Concept . . . . . . . . . . . . . . . . . . . . 20 96 A.2. UAS Service Supplier (USS) . . . . . . . . . . . . . . . 21 97 A.3. UTM Use Cases for UAS Operations . . . . . . . . . . . . 21 98 A.4. Automatic Dependent Surveillance Broadcast (ADS-B) . . . 22 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 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, conforming to proposed 106 and final regulations plus external technical standards, satisfying 107 the requirements listed in the companion requirements document 108 [I-D.ietf-drip-reqs]. 110 This document assumes the reader is familiar with 111 [I-D.ietf-drip-reqs]. 113 1.1. Overview of Unmanned Aircraft System (UAS) Remote ID (RID) and 114 Standardization 116 UAS Remote Identification (RID) is an application enabler for a UAS 117 to be identified by Unmanned Aircraft Systems Traffic Management 118 (UTM) and UAS Service Supplier (USS) (Appendix A) or third parties 119 entities such as law enforcement. Many safety and other 120 considerations dictate that UAS be remotely identifiable. Civil 121 Aviation Authorities (CAAs) worldwide are mandating UAS RID. The 122 European Union Aviation Safety Agency (EASA) has published 123 [Delegated] and [Implementing] Regulations. 125 CAAs currently promulgate performance-based regulations that do not 126 specify techniques, but rather cite industry consensus technical 127 standards as acceptable means of compliance. 129 Federal Aviation Administration (FAA) 131 The FAA published a Notice of Proposed Rule Making [NPRM] in 2019 132 and whereafter published the Final Rule [FAA_RID] in 2021. In 133 FAA's final rule, it is clearly stating that Automatic Dependent 134 Surveillance Broadcast (ADS-B) Out and transponders can not be 135 used to serve the purpose of an remote identification. (More 136 about ADS-B in Appendix A.4) 138 American Society for Testing and Materials (ASTM) 140 ASTM International, Technical Committee F38 (UAS), Subcommittee 141 F38.02 (Aircraft Operations), Work Item WK65041, developed the 142 ASTM [F3411-19] Standard Specification for Remote ID and Tracking. 144 ASTM defines one set of RID information and two means, MAC-layer 145 broadcast and IP-layer network, of communicating it. If a UAS 146 uses both communication methods, the same information must be 147 provided via both means. The [F3411-19] is cited by FAA in its 148 RID final rule [FAA_RID] as "a potential means of compliance" to a 149 Remote ID rule. 151 The 3rd Generation Partnership Project (3GPP) 153 With release 16, 3GPP completed the UAS RID requirement study 154 [TS-22.825] and proposed use cases in the mobile network and the 155 services that can be offered based on RID. Release 17 156 specification works on enhanced UAS service requirements and 157 provides the protocol and application architecture support which 158 is applicable for both 4G and 5G network. 160 1.2. Overview of Types of UAS Remote ID 162 1.2.1. Broadcast RID 164 A set of RID messages are defined for direct, one-way, broadcast 165 transmissions from the UA over Bluetooth or Wi-Fi. These are 166 currently defined as MAC-Layer messages. Internet (or other Wide 167 Area Network) connectivity is only needed for UAS registry 168 information lookup by Observers using the locally directly received 169 UAS RID as a key. Broadcast RID should be functionally usable in 170 situations with no Internet connectivity. 172 The Broadcast RID is illustrated in Figure 1 below. 174 x x UA 175 xxxxx 176 | 177 | 178 | app messages directly over 179 | one-way RF data link (no IP) 180 | 181 | 182 + 183 x 184 xxxxx 185 x 186 x 187 x x Observer's device (e.g. smartphone) 188 x x 190 Figure 1 192 With Broadcast RID, an Observer is limited to their radio "visible" 193 airspace for UAS awareness and information. With Internet queries 194 using harvested RID (see Section 6), the Observer may gain more 195 information about those visible UAS. 197 1.2.2. Network RID 199 A RID data dictionary and data flow for Network RID are defined in 200 [F3411-19]. This data flow is emitted from a UAS via unspecified 201 means (but at least in part over the Internet) to a Network Remote ID 202 Service Provider (Net-RID SP). These Net-RID SPs provide the RID 203 data to Network Remote ID Display Providers (Net-RID DP). It is the 204 Net-RID DP that responds to queries from Network Remote ID Observers 205 (expected typically, but not specified exclusively, to be web-based) 206 specifying airspace volumes of interest. Network RID depends upon 207 connectivity, in several segments, via the Internet, from the UAS to 208 the Observer. 210 The Network RID is illustrated in Figure 2 below: 212 x x UA 213 xxxxx ******************** 214 | \ * ------*---+------------+ 215 | \ * / * | NET_RID_SP | 216 | \ * ------------/ +---*--+------------+ 217 | RF \ */ | * 218 | * INTERNET | * +------------+ 219 | /* +---*--| NET_RID_DP | 220 | / * +---*--+------------+ 221 + / * | * 222 x / *****************|*** x 223 xxxxx | xxxxx 224 x +------- x 225 x x 226 x x Operator (GCS) Observer x x 227 x x x x 229 Figure 2 231 Command and Control (C2) must flow from the GCS to the UA via some 232 path, currently (in the year of 2021) typically a direct RF link, but 233 with increasing BVLOS operations expected often to be wireless links 234 at either end with the Internet between. For all but the simplest 235 hobby aircraft, telemetry (at least position and heading) flows from 236 the UA to the GCS via some path, typically the reverse of the C2 237 path. Thus RID information pertaining to both the GCS and the UA can 238 be sent, by whichever has Internet connectivity, to the Net-RID SP, 239 typically the USS managing the UAS operation. 241 The Net-RID SP forwards RID information via the Internet to 242 subscribed Net-RID DP, typically a USS. Subscribed Net-RID DP 243 forward RID information via the Internet to subscribed Observer 244 devices. Regulations require and [F3411-19] describes RID data 245 elements that must be transported end-to-end from the UAS to the 246 subscribed Observer devices. 248 [F3411-19] prescribes the protocols only between the Net-RID SP, Net- 249 RID DP, and the Discovery and Synchronization Service (DSS). DRIP 250 may also address standardization of protocols between the UA and GCS, 251 between the UAS and the Net-RID SP, and/or between the Net-RID DP and 252 Observer devices. 254 Informative note: Neither link layer protocols nor the use of 255 links (e.g., the link often existing between the GCS and the 256 UA) for any purpose other than carriage of RID information is 257 in the scope of [F3411-19] Network RID. 259 1.3. Overview of USS Interoperability 261 Each UAS is registered to at least one USS. With Net-RID, there is 262 direct communication between the UAS and its USS. With Broadcast- 263 RID, the UAS Operator has either pre-filed a 4D space volume for USS 264 operational knowledge and/or Observers can be providing information 265 about observed UA to a USS. USS exchange information via a Discovery 266 and Synchronization Service (DSS) so all USS collectively have 267 knowledge about all activities in a 4D airspace. 269 The interactions among Observer, UA, and USS are shown in Figure 3. 271 +----------+ 272 | Observer | 273 +----------+ 274 / \ 275 / \ 276 +-----+ +-----+ 277 | UA1 | | UA2 | 278 +-----+ +-----+ 279 \ / 280 \ / 281 +----------+ 282 | Internet | 283 +----------+ 284 / \ 285 / \ 286 +-------+ +-------+ 287 | USS-1 | <-------> | USS-2 | 288 +-------+ +-------+ 289 \ / 290 \ / 291 +------+ 292 | DSS | 293 +------+ 295 Figure 3 297 1.4. Overview of DRIP Architecture 299 The requirements document [I-D.ietf-drip-reqs] also provides an 300 extended introduction to the problem space, use cases, etc. Only a 301 brief summary of that introduction will be restated here as context, 302 with reference to the general UAS RID usage scenarios shown in 303 Figure 4 below. 305 General x x Public 306 Public xxxxx xxxxx Safety 307 Observer x x Observer 308 x x 309 x x ---------+ +---------- x x 310 x x | | x x 311 | | 312 UA1 x x | | +------------ x x UA2 313 xxxxx | | | xxxxx 314 | + + + | 315 | xxxxxxxxxx | 316 | x x | 317 +----------+x Internet x+------------+ 318 UA1 | x x | UA1 319 Pilot x | xxxxxxxxxx | x Pilot 320 Operator xxxxx + + + xxxxx Operator 321 GCS1 x | | | x GCS2 322 x | | | x 323 x x | | | x x 324 x x | | | x x 325 | | | 326 +----------+ | | | +----------+ 327 | |------+ | +-------| | 328 | Public | | | Private | 329 | Registry | +-----+ | Registry | 330 | | | DNS | | | 331 +----------+ +-----+ +----------+ 333 Figure 4 335 DRIP will enable leveraging existing Internet resources (standard 336 protocols, services, infrastructure, and business models) to meet UAS 337 RID and closely related needs. DRIP will specify how to apply IETF 338 standards, complementing [F3411-19] and other external standards, to 339 satisfy UAS RID requirements. DRIP will update existing and develop 340 new protocol standards as needed to accomplish the foregoing. 342 This document will outline the UAS RID architecture into which DRIP 343 must fit and the architecture for DRIP itself. This includes 344 presenting the gaps between the CAAs' Concepts of Operations and 345 [F3411-19] as it relates to the use of Internet technologies and UA 346 direct RF communications. Issues include, but are not limited to: 348 * Design of trustworthy remote ID and trust in RID messages 349 (Section 4) 351 * Mechanisms to leverage Domain Name System (DNS: [RFC1034]), 352 Extensible Provisioning Protocol (EPP [RFC5731]) and 353 Registration Data Access Protocol (RDAP) ([RFC7482]) to provide 354 for private (Section 5.2) and public (Section 5.1) Information 355 Registry. 357 * Harvesting broadcast remote ID messages for UTM inclusion 358 (Section 6) 360 * Privacy in RID messages (PII protection) (Section 7) 362 2. Conventions 364 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 365 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 366 "OPTIONAL" in this document are to be interpreted as described in BCP 367 14 [RFC2119] [RFC8174] when, and only when, they appear in all 368 capitals, as shown above. 370 3. Definitions and Abbreviations 372 3.1. Additional Definitions 374 This document uses terms defined in [I-D.ietf-drip-reqs]. 376 3.2. Abbreviations 378 ADS-B: Automatic Dependent Surveillance Broadcast 380 DSS: Discovery & Synchronization Service 382 EdDSA: Edwards-Curve Digital Signature Algorithm 384 GCS: Ground Control Station 386 HHIT: Hierarchical HIT Registries 388 HIP: Host Identity Protocol 390 HIT: Host Identity Tag 392 RID: Remote ID 394 Net-RID SP: Network RID Service Provider 395 Net-RID DP: Network RID Display Provider. 397 PII: Personally Identifiable Information 399 RF: Radio Frequency 401 SDSP: Supplemental Data Service Provider 403 UA: Unmanned Aircraft 405 UAS: Unmanned Aircraft System 407 USS: UAS Service Supplier 409 UTM: UAS Traffic Management 411 3.3. Claims, Assertions, Attestations, and Certificates 413 This section introduces the terms "Claims", "Assertions", 414 "Attestations", and "Certificates" as used in DRIP. 416 This is due to the term "certificate" having significant 417 technological and legal baggage associated with it, specifically 418 around X.509 certificates. These types of certificates and Public 419 Key Infrastructure invoke more legal and public policy considerations 420 than probably any other electronic communication sector. It emerged 421 as a governmental platform for trusted identity management and was 422 pursued in intergovernmental bodies with links into treaty 423 instruments. 425 Claims: 427 A claim in DRIP is a predicate (e.g., "X is Y", "X has property 428 Y", and most importantly "X owns Y" or "X is owned by Y"). One 429 basic use case of a claim is an entity using an HHIT as an 430 identifier, e.g., a UAS using an HHIT as a UAS ID. 432 Assertions: 434 An assertion in DRIP is a set of claims. This definition is 435 borrowed from JWT/CWT. An HHIT of itself can be seen as an 436 assertion: a claim that the identifier is a handle to an 437 asymmetric keypair owned by the entity, and a claim that the 438 identifier is in the registry specified by the HID embedded in the 439 identifier. 441 Attestations: 443 An attestation in DRIP is a signed assertion. The signer may be a 444 claimant or a third party. Under DRIP this is normally used when 445 an entity asserts a relationship with another entity, along with 446 other information, and the asserting entity signs the assertion, 447 thereby making it an attestation. 449 Certificates: 451 A certificate in DRIP is an attestation, strictly over identity 452 information, signed by a third party. 454 4. HHIT for DRIP Entity Identifier 456 This section describes the basic requirements of a DRIP entity 457 identifier per regulation constrains from ASTM [F3411-19] and 458 explains the use of Hierarchical Host Identity Tags (HHITs) as self- 459 asserting IPv6 addresses and thereby a trustable DRIP identifier for 460 use as the UAS Remote ID. HHITs self-attest to the included explicit 461 hierarchy that provides Registrar discovery for 3rd-party ID 462 attestation. 464 4.1. UAS Remote Identifiers Problem Space 466 A DRIP entity identifier needs to be "Trustworthy". This means that 467 within the framework of the RID messages, an Observer can establish 468 that the DRIP identifier used does uniquely belong to the UAS. That 469 the only way for any other UAS to assert this DRIP identifier would 470 be to steal something from within the UAS. The DRIP identifier is 471 self-generated by the UAS (either UA or GCS) and registered with the 472 USS. 474 The data communication of using Broadcast RID faces extreme 475 challenges due to the limitation of the demanding support for 476 Bluetooth. The ASTM [F3411-19] defines the basic RID message which 477 is expected to contain certain RID data and the Authentication 478 message. The Basic RID message has a maximum payload of 25 bytes and 479 the maximum size allocated by ASTM for the RID is 20 bytes and only 3 480 bytes are left unused. currently, the authentication maximum payload 481 is defined to be 201 bytes. 483 Standard approaches like X.509 and PKI will not fit these 484 constraints, even using the new EdDSA [RFC8032] algorithm cannot fit 485 within the maximum 201 byte limit, due in large measure to ASN.1 486 encoding format overhead. 488 An example of a technology that will fit within these limitations is 489 an enhancement of the Host Identity Tag (HIT) of HIPv2 [RFC7401] 490 using Hierarchical HITs (HHITs) for UAS RID is outlined in HHIT based 491 UAS RID [I-D.ietf-drip-rid]. As PKI with X.509 is being used in 492 other systems with which UAS RID must interoperate (e.g. Discovery 493 and Synchronization Service and any other communications involving 494 USS) mappings between the more flexible but larger X.509 certificates 495 and the HHIT-based structures must be devised. This could be as in 496 [RFC8002] or simply the HHIT as Subject Alternative Name (SAN) and no 497 Distinguished Name (DN). 499 A self-attestation of the HHIT RID can be done in as little as 84 500 bytes, by avoiding an explicit encoding technology like ASN.1 or 501 Concise Binary Object Representation (CBOR [RFC8949]). This 502 compressed attestation consists of only the HHIT, a timestamp, and 503 the EdDSA signature on them. The HHIT prefix and suiteID provide 504 crypto agility and implicit encoding rules. Similarly, a self- 505 attestation of the Hierarchical registration of the RID (an 506 attestation of a RID third-party registration "certificate") can be 507 done in 200 bytes. Both these are detailed in UAS RID 508 [I-D.ietf-drip-rid]. 510 An Observer would need Internet access to validate a self- 511 attestations claim. A third-party Certificate can be validated via a 512 small credential cache in a disconnected environment. This third- 513 party Certificate is possible when the third-party also uses HHITs 514 for its identity and the UA has the public key and the Certificate 515 for that HHIT. 517 4.2. HIT as A Trustworthy DRIP Entity Identifier 519 A Remote ID that can be trustworthily used in the RID Broadcast mode 520 can be built from an asymmetric keypair. Rather than using a key 521 signing operation to claim ownership of an ID that does not guarantee 522 name uniqueness, in this method the ID is cryptographically derived 523 directly from the public key. The proof of ID ownership (verifiable 524 attestation, versus mere claim) comes from signing this cryptographic 525 ID with the associated private key. It is statistically hard for 526 another entity to create a public key that would generate (spoof) the 527 ID. 529 HITs are so designed; they are statistically unique through the 530 cryptographic hash feature of second-preimage resistance. The 531 cryptographically-bound addition of the Hierarchy and an HHIT 532 registration process (e.g. based on Extensible Provisioning Protocol, 533 [RFC5730]) provide complete, global HHIT uniqueness. This 534 registration forces the attacker to generate the same public key 535 rather than a public key that generates the same HHIT. This is in 536 contrast to general IDs (e.g. a UUID or device serial number) as the 537 subject in an X.509 certificate. 539 4.3. HHIT for DRIP Identifier Registration and Lookup 541 Remote ID needs a deterministic lookup mechanism that rapidly 542 provides actionable information about the identified UA. Given the 543 size constraints imposed by the Bluetooth 4 broadcast media, the 544 Remote ID itself needs to be the inquiry input into the lookup. An 545 HHIT DRIP identifier contains cryptographically embedded registration 546 information. This HHIT registration hierarchy, along with the IPv6 547 prefix, is trustable and sufficient information that can be used to 548 perform such a lookup. Additionally, the IPv6 prefix can enhance the 549 HHITs use beyond the basic Remote ID function (e.g use in HIP, 550 [RFC7401]). 552 Therefore, a DRIP identifier can be represented as a HHIT. It can be 553 self-generated by a UAS (either UA or GCS) and registered with the 554 Private Information Registry (More details in Section 5.2) identified 555 in its hierarchy fields. Each DRIP identifier represented as an HHIT 556 can not be used more than once. 558 A DRIP identifier can be assigned to a UAS as a static HHIT by its 559 manufacturer, such as a single HI and derived HHIT encoded as a 560 hardware serial number per [CTA2063A]. Such a static HHIT can only 561 be used to bind one-time use DRIP identifiers to the unique UA. 562 Depending upon implementation, this may leave a HI private key in the 563 possession of the manufacturer (more details in Section 8). 565 In another case, a UAS equipped for Broadcast RID can be provisioned 566 not only with its HHIT but also with the HI public key from which the 567 HHIT was derived and the corresponding private key, to enable message 568 signature. A UAS equipped for Network RID can be provisioned 569 likewise; the private key resides only in the ultimate source of 570 Network RID messages (i.e. on the UA itself if the GCS is merely 571 relaying rather than sourcing Network RID messages). Each Observer 572 device can be provisioned either with public keys of the DRIP 573 identifier root registries or certificates for subordinate 574 registries. 576 HHITs can be used throughout the UAS/UTM system. The Operators, 577 Private Information Registries, as well as other UTM entities, can 578 use HHITs for their IDs. Such HHITs can facilitate DRIP security 579 functions such as used with HIP to strongly mutually authenticate and 580 encrypt communications. 582 4.4. HHIT for DRIP Identifier Cryptographic 584 The only (known to the authors of this document at the time of its 585 writing) extant fixed-length ID cryptographically derived from a 586 public key are the Host Identity Tag [RFC7401], HITs, and 587 Cryptographically Generated Addresses [RFC3972], CGAs. However, both 588 HITs and CGAs lack registration/retrieval capability. HHIT, on the 589 other hand, is capable of providing a cryptographic hashing function, 590 along with a registration process to mitigate the probability of a 591 hash collision (first registered, first allowed). 593 5. DRIP Identifier Registration and Registries 595 UAS registries can hold both public and private UAS information 596 resulting from the DRIP identifier registration process. Given these 597 different uses, and to improve scalability, security, and simplicity 598 of administration, the public and private information can be stored 599 in different registries. A DRIP identifier is amenable to handling 600 as an Internet domain name (at an arbitrary level in the hierarchy). 601 It also can be registered in at least a pseudo-domain (e.g. .ip6.arpa 602 for reverse lookup), or as a sub-domain (for forward lookup). This 603 section introduces the public and private information registries for 604 DRIP identifiers. 606 5.1. Public Information Registry 608 5.1.1. Background 610 The public registry provides trustable information such as 611 attestations of RID ownership and HDA registration. Optionally, 612 pointers to the repositories for the HDA and RAA implicit in the RID 613 can be included (e.g. for HDA and RAA HHIT|HI used in attestation 614 signing operations). This public information will be principally 615 used by Observers of Broadcast RID messages. Data on UAS that only 616 use Network RID, is only available via an Observer's Net-RID DP that 617 would tend to provide all public registry information directly. The 618 Observer can visually "see" these UAS, but they are silent to the 619 Observer; the Net-RID DP is the only source of information based on a 620 query for an airspace volume. 622 5.1.2. Proposed Approach 624 A DRIP public information registry can respond to standard DNS 625 queries, in the definitive public Internet DNS hierarchy. If a DRIP 626 public information registry lists, in a HIP RR, any HIP RVS servers 627 for a given DRIP identifier, those RVS servers can restrict relay 628 services per AAA policy; this requires extensions to [RFC8004]. 629 These public information registries can use secure DNS transport 630 (e.g. DNS over TLS) to deliver public information that is not 631 inherently trustable (e.g. everything other than attestations). 633 5.2. Private Information Registry 635 5.2.1. Background 637 The private information required for DRIP identifiers is similar to 638 that required for Internet domain name registration. A DRIP 639 identifier solution can leverage existing Internet resources: 640 registration protocols, infrastructure and business models, by 641 fitting into an ID structure compatible with DNS names. This implies 642 some sort of hierarchy, for scalability, and management of this 643 hierarchy. It is expected that the private registry function will be 644 provided by the same organizations that run USS, and likely 645 integrated with USS. 647 5.2.2. Proposed Approach 649 A DRIP private information registry can support essential Internet 650 domain name registry operations (e.g. add, delete, update, query) 651 using interoperable open standard protocols. It can also support the 652 Extensible Provisioning Protocol (EPP) and the Registry Data Access 653 Protocol (RDAP) with access controls. It might be listed in a DNS: 654 that DNS could be private; but absent any compelling reasons for use 655 of private DNS, a public DNS hierarchy needs to be in place. The 656 DRIP private information registry in which a given UAS is registered 657 needs to be findable, starting from the UAS ID, using the methods 658 specified in [RFC7484]. A DRIP private information registry can also 659 support WebFinger as specified in [RFC7033]. 661 6. Harvesting Broadcast Remote ID messages for UTM Inclusion 663 ASTM anticipated that regulators would require both Broadcast RID and 664 Network RID for large UAS, but allow RID requirements for small UAS 665 to be satisfied with the operator's choice of either Broadcast RID or 666 Network RID. The EASA initially specified Broadcast RID for UAS of 667 essentially all UAS and is now also considering Network RID. The FAA 668 RID Final Rules only specifies Broadcast RID for UAS, however, still 669 encourages Network RID for complementary functionality, especially in 670 support of UTM. 672 One obvious opportunity is to enhance the architecture with gateways 673 from Broadcast RID to Network RID. This provides the best of both 674 and gives regulators and operators flexibility. It offers 675 considerable enhancement over some Network RID options such as only 676 reporting planned 4D operation space by the operator. 678 These gateways could be pre-positioned (e.g. around airports, public 679 gatherings, and other sensitive areas) and/or crowd-sourced (as 680 nothing more than a smartphone with a suitable app is needed). As 681 Broadcast RID media have limited range, gateways receiving messages 682 claiming locations far from the gateway can alert authorities or a 683 SDSP to the failed sanity check possibly indicating intent to 684 deceive. Surveillance SDSPs can use messages with precise date/time/ 685 position stamps from the gateways to multilaterate UA location, 686 independent of the locations claimed in the messages (which may have 687 a natural time lag as it is), which are entirely operator self- 688 reported in UAS RID and UTM. 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 can not interface directly with 703 a GCS, Net-RID SP, Net-RID DP or Network RID client. It would 704 present a TBD interface to a CS-RID SDSP; this interface needs to be 705 based upon but readily distinguishable from that between a GCS and a 706 Net-RID SP. 708 6.2. The CS-RID SDSP 710 A CS-RID SDSP would appear (i.e. present the same interface) to a 711 Net-RID SP as a Net-RID DP. A CS-RID SDSP can not present a standard 712 GCS-facing interface as if it were a Net-RID SP. A CS-RID SDSP would 713 present a TBD interface to a CS-RID Finder; this interface can be 714 based upon but readily distinguishable between a GCS and a Net-RID 715 SP. 717 7. Privacy for Broadcast PII 719 Broadcast RID messages can contain PII. A viable architecture for 720 PII protection would be symmetric encryption of the PII using a key 721 known to the UAS and its USS. An authorized Observer could send the 722 encrypted PII along with the UAS ID (to entities such as USS of the 723 Observer, or to the UAS in which the UAS ID is registered if that can 724 be determined from the UAS ID itself or to a Public Safety USS) to 725 get the plaintext. Alternatively, the authorized Observer can 726 receive the key to directly decrypt all future PII content from the 727 UA. 729 PII can be protected unless the UAS is informed otherwise. This 730 could come from operational instructions to even permit flying in a 731 space/time. It can be special instructions at the start or during an 732 operation. PII protection can not be used if the UAS loses 733 connectivity to the USS. The UAS always has the option to abort the 734 operation if PII protection is disallowed. 736 An authorized Observer can instruct a UAS via the USS that conditions 737 have changed mandating no PII protection or land the UA (abort the 738 operation). 740 8. Security Considerations 742 The security provided by asymmetric cryptographic techniques depends 743 upon protection of the private keys. A manufacturer that embeds a 744 private key in an UA may have retained a copy. A manufacturer whose 745 UA are configured by a closed source application on the GCS which 746 communicates over the Internet with the factory may be sending a copy 747 of a UA or GCS self-generated key back to the factory. Keys may be 748 extracted from a GCS or UA. The RID sender of a small harmless UA 749 (or the entire UA) could be carried by a larger dangerous UA as a 750 "false flag." Compromise of a registry private key could do 751 widespread harm. Key revocation procedures are as yet to be 752 determined. These risks are in addition to those involving Operator 753 key management practices. 755 9. Acknowledgements 757 The work of the FAA's UAS Identification and Tracking (UAS ID) 758 Aviation Rulemaking Committee (ARC) is the foundation of later ASTM 759 and proposed IETF DRIP WG efforts. The work of ASTM F38.02 in 760 balancing the interests of diverse stakeholders is essential to the 761 necessary rapid and widespread deployment of UAS RID. IETF 762 volunteers who have contributed to this draft include Amelia 763 Andersdotter and Mohamed Boucadair. 765 10. References 767 10.1. Normative References 769 [I-D.ietf-drip-reqs] 770 Card, S. W., Wiethuechter, A., Moskowitz, R., and A. 771 Gurtov, "Drone Remote Identification Protocol (DRIP) 772 Requirements", draft-ietf-drip-reqs-10 (work in progress), 773 April 2021. 775 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 776 Requirement Levels", BCP 14, RFC 2119, 777 DOI 10.17487/RFC2119, March 1997, 778 . 780 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 781 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 782 May 2017, . 784 10.2. Informative References 786 [CTA2063A] 787 ANSI, "Small Unmanned Aerial Systems Serial Numbers", 788 2019. 790 [Delegated] 791 European Union Aviation Safety Agency (EASA), "EU 792 Commission Delegated Regulation 2019/945 of 12 March 2019 793 on unmanned aircraft systems and on third-country 794 operators of unmanned aircraft systems", 2019. 796 [F3411-19] 797 ASTM, "Standard Specification for Remote ID and Tracking", 798 2019. 800 [FAA_RID] United States Federal Aviation Administration (FAA), 801 "Remote Identification of Unmanned Aircraft", 2021, 802 . 805 [FAA_UAS_Concept_Of_Ops] 806 United States Federal Aviation Administration (FAA), 807 "Unmanned Aircraft System (UAS) Traffic Management (UTM) 808 Concept of Operations (V2.0)", 2020, 809 . 812 [I-D.ietf-drip-rid] 813 Moskowitz, R., Card, S. W., Wiethuechter, A., and A. 814 Gurtov, "UAS Remote ID", draft-ietf-drip-rid-07 (work in 815 progress), January 2021. 817 [Implementing] 818 European Union Aviation Safety Agency (EASA), "EU 819 Commission Implementing Regulation 2019/947 of 24 May 2019 820 on the rules and procedures for the operation of unmanned 821 aircraft", 2019. 823 [LAANC] United States Federal Aviation Administration (FAA), "Low 824 Altitude Authorization and Notification Capability", n.d., 825 . 828 [NPRM] United States Federal Aviation Administration (FAA), 829 "Notice of Proposed Rule Making on Remote Identification 830 of Unmanned Aircraft Systems", 2019. 832 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 833 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 834 . 836 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 837 RFC 3972, DOI 10.17487/RFC3972, March 2005, 838 . 840 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 841 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 842 . 844 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 845 Domain Name Mapping", STD 69, RFC 5731, 846 DOI 10.17487/RFC5731, August 2009, 847 . 849 [RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr, 850 "WebFinger", RFC 7033, DOI 10.17487/RFC7033, September 851 2013, . 853 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 854 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 855 RFC 7401, DOI 10.17487/RFC7401, April 2015, 856 . 858 [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access 859 Protocol (RDAP) Query Format", RFC 7482, 860 DOI 10.17487/RFC7482, March 2015, 861 . 863 [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data 864 (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March 865 2015, . 867 [RFC8002] Heer, T. and S. Varjonen, "Host Identity Protocol 868 Certificates", RFC 8002, DOI 10.17487/RFC8002, October 869 2016, . 871 [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 872 Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, 873 October 2016, . 875 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 876 Signature Algorithm (EdDSA)", RFC 8032, 877 DOI 10.17487/RFC8032, January 2017, 878 . 880 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 881 Representation (CBOR)", STD 94, RFC 8949, 882 DOI 10.17487/RFC8949, December 2020, 883 . 885 [TS-22.825] 886 3GPP, "UAS RID requirement study", n.d., 887 . 890 [U-Space] European Organization for the Safety of Air Navigation 891 (EUROCONTROL), "U-space Concept of Operations", 2019, 892 . 895 Appendix A. Overview of Unmanned Aircraft Systems (UAS) Traffic 896 Management (UTM) 898 A.1. Operation Concept 900 The National Aeronautics and Space Administration (NASA) and FAAs' 901 effort of integrating UAS's operation into the national airspace 902 system (NAS) leads to the development of the concept of UTM and the 903 ecosystem around it. The UTM concept was initially presented in 2013 904 and version 2.0 is published in 2020 [FAA_UAS_Concept_Of_Ops]. 906 The eventual development and implementation are conducted by the UTM 907 research transition team which is the joint workforce by FAA and 908 NASA. World efforts took place afterward. The Single European Sky 909 ATM Research (SESAR) started the CORUS project to research its UTM 910 counterpart concept, namely [U-Space]. This effort is led by the 911 European Organization for the Safety of Air Navigation (Eurocontrol). 913 Both NASA and SESAR have published the UTM concept of operations to 914 guide the development of their future air traffic management (ATM) 915 system and make sure safe and efficient integrations of manned and 916 unmanned aircraft into the national airspace. 918 The UTM composes of UAS operation infrastructure, procedures and 919 local regulation compliance policies to guarantee UAS's safe 920 integration and operation. The main functionality of a UTM includes, 921 but is not limited to, providing means of communication between UAS 922 operators and service providers and a platform to facilitate 923 communication among UAS service providers. 925 A.2. UAS Service Supplier (USS) 927 A USS plays an important role to fulfill the key performance 928 indicators (KPIs) that a UTM has to offer. Such Entity acts as a 929 proxy between UAS operators and UTM service providers. It provides 930 services like real-time UAS traffic monitor and planning, 931 aeronautical data archiving, airspace and violation control, 932 interacting with other third-party control entities, etc. A USS can 933 coexist with other USS(s) to build a large service coverage map which 934 can load-balance, relay and share UAS traffic information. 936 The FAA works with UAS industry shareholders and promotes the Low 937 Altitude Authorization and Notification Capability [LAANC] program 938 which is the first system to realize some of the UTM envisioned 939 functionality. The LAANC program can automate the UAS's flight plan 940 application and approval process for airspace authorization in real- 941 time by checking against multiple aeronautical databases such as 942 airspace classification and fly rules associated with it, FAA UAS 943 facility map, special use airspace, Notice to Airman (NOTAM), and 944 Temporary Flight Rule (TFR). 946 A.3. UTM Use Cases for UAS Operations 948 This section illustrates a couple of use case scenarios where UAS 949 participation in UTM has significant safety improvement. 951 1. For a UAS participating in UTM and takeoff or land in a 952 controlled airspace (e.g., Class Bravo, Charlie, Delta and Echo 953 in United States), the USS where UAS is currently communicating 954 with is responsible for UAS's registration, authenticating the 955 UAS's fly plan by checking against designated UAS fly map 956 database, obtaining the air traffic control (ATC) authorization 957 and monitor the UAS fly path in order to maintain safe boundary 958 and follow the pre-authorized route. 960 2. For a UAS participating in UTM and take off or land in an 961 uncontrolled airspace (ex. Class Golf in the United States), 962 pre-fly authorization must be obtained from a USS when operating 963 beyond-visual-of-sight (BVLOS) operation. The USS either accepts 964 or rejects received intended fly plan from the UAS. Accepted UAS 965 operation may share its current fly data such as GPS position and 966 altitude to USS. The USS may keep the UAS operation status near 967 real-time and may keep it as a record for overall airspace air 968 traffic monitor. 970 A.4. Automatic Dependent Surveillance Broadcast (ADS-B) 972 The ADS-B is the de jure technology used in manned aviation for 973 sharing location information, from the aircraft to ground and 974 satellite-based systems, designed in the early 2000s. Broadcast RID 975 is conceptually similar to ADS-B, but with the receiver target being 976 the general public on generally available devices (e.g. smartphones). 978 For numerous technical reasons, ADS-B itself is not suitable for low- 979 flying small UA. Technical reasons include but not limited to the 980 following: 982 1. Lack of support for the 1090 MHz ADS-B channel on any consumer 983 handheld devices 985 2. Weight and cost of ADS-B transponders on CSWaP constrained UA 987 3. Limited bandwidth of both uplink and downlink, which would likely 988 be saturated by large numbers of UAS, endangering manned aviation 990 Understanding these technical shortcomings, regulators worldwide have 991 ruled out the use of ADS-B for the small UAS for which UAS RID and 992 DRIP are intended. 994 Authors' Addresses 996 Stuart W. Card 997 AX Enterprize 998 4947 Commercial Drive 999 Yorkville, NY 13495 1000 USA 1002 Email: stu.card@axenterprize.com 1004 Adam Wiethuechter 1005 AX Enterprize 1006 4947 Commercial Drive 1007 Yorkville, NY 13495 1008 USA 1010 Email: adam.wiethuechter@axenterprize.com 1011 Robert Moskowitz 1012 HTT Consulting 1013 Oak Park, MI 48237 1014 USA 1016 Email: rgm@labs.htt-consult.com 1018 Shuai Zhao 1019 Tencent 1020 2747 Park Blvd 1021 Palo Alto 94588 1022 USA 1024 Email: shuai.zhao@ieee.org 1026 Andrei Gurtov 1027 Linkoeping University 1028 IDA 1029 Linkoeping SE-58183 Linkoeping 1030 Sweden 1032 Email: gurtov@acm.org