idnits 2.17.1 draft-ietf-drip-arch-06.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 179 has weird spacing: '...bserver x x...' == Line 285 has weird spacing: '...perator xxxxx...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (14 December 2020) is 1226 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-06 == Outdated reference: A later version (-37) exists of draft-ietf-drip-rid-04 -- Obsolete informational reference (is this intentional?): RFC 7484 (Obsoleted by RFC 9224) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 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: 17 June 2021 R. Moskowitz 6 HTT Consulting 7 S. Zhao (Editor) 8 Tencent 9 A. Gurtov 10 Linkoeping University 11 14 December 2020 13 Drone Remote Identification Protocol (DRIP) Architecture 14 draft-ietf-drip-arch-06 16 Abstract 18 This document defines an architecture for protocols and services to 19 support Unmanned Aircraft System Remote Identification and tracking 20 (UAS RID), plus RID-related communications, including required 21 architectural building blocks and their interfaces. 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 17 June 2021. 40 Copyright Notice 42 Copyright (c) 2020 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 UAS Remote ID (RID) and RID Standardization . . 3 58 1.2. Overview of Types of UAS Remote ID . . . . . . . . . . . 4 59 1.2.1. Network RID . . . . . . . . . . . . . . . . . . . . . 4 60 1.2.2. Broadcast RID . . . . . . . . . . . . . . . . . . . . 5 61 1.3. Overview of USS Interoperability . . . . . . . . . . . . 5 62 1.4. Overview of DRIP Archicture . . . . . . . . . . . . . . . 6 63 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 3. Definitions and Abbreviations . . . . . . . . . . . . . . . . 8 65 3.1. Additional Definitions . . . . . . . . . . . . . . . . . 8 66 3.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 8 67 4. HHIT for UAS Remote ID . . . . . . . . . . . . . . . . . . . 9 68 4.1. HIT as a Trustworthy Remote ID . . . . . . . . . . . . . 9 69 4.2. HHIT for Remote ID Registration and Lookup . . . . . . . 10 70 4.3. HHIT for Remote ID Encryption . . . . . . . . . . . . . . 10 71 5. DRIP RID Entities (WAS Entities and their interfaces) . . . . 11 72 5.1. Private Information Registry . . . . . . . . . . . . . . 11 73 5.1.1. Background . . . . . . . . . . . . . . . . . . . . . 11 74 5.1.2. Proposed Approach . . . . . . . . . . . . . . . . . . 11 75 5.2. Public Information Registry . . . . . . . . . . . . . . . 12 76 5.2.1. Background . . . . . . . . . . . . . . . . . . . . . 12 77 5.2.2. Proposed Approach . . . . . . . . . . . . . . . . . . 12 78 5.3. CS-RID concept . . . . . . . . . . . . . . . . . . . . . 12 79 5.3.1. Proposed optional CS-RID SDSP . . . . . . . . . . . . 13 80 5.3.2. Proposed optional CS-RID Finder . . . . . . . . . . . 13 81 6. UAS Remote Identifiers . . . . . . . . . . . . . . . . . . . 13 82 6.1. Background . . . . . . . . . . . . . . . . . . . . . . . 13 83 6.2. Proposed Approach . . . . . . . . . . . . . . . . . . . . 14 84 7. DRIP Transactions enabling Trustworthy . . . . . . . . . . . 15 85 8. Privacy for Broadcast PII . . . . . . . . . . . . . . . . . . 16 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 87 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 88 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 90 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 91 12.2. Informative References . . . . . . . . . . . . . . . . . 17 92 Appendix A. Overview of Unmanned Aircraft Systems (UAS) 93 Traffic . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 A.1. Operation Concept . . . . . . . . . . . . . . . . . . . . 20 95 A.2. UAS Service Supplier (USS) . . . . . . . . . . . . . . . 20 96 A.3. UTM Use Cases for UAS Operations . . . . . . . . . . . . 21 97 A.4. Automatic Dependent Surveillance Broadcast (ADS-B) . . . 21 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 100 1. Introduction 102 This document describes a natural Internet and MAC-layer broadcast- 103 based architecture for Unmanned Aircraft System Remote Identification 104 and tracking (UAS RID), conforming to proposed regulations and 105 external technical standards, satisfying the requirements listed in 106 the companion requirements document [I-D.ietf-drip-reqs]. 108 Many considerations (especially safety) dictate that UAS be remotely 109 identifiable. Civil Aviation Authorities (CAAs) worldwide are 110 mandating Unmanned Aircraft Systems (UAS) Remote Identification 111 (RID). CAAs currently (2020) promulgate performance-based 112 regulations that do not specify techniques, but rather cite industry 113 consensus technical standards as acceptable means of compliance. 115 1.1. Overview UAS Remote ID (RID) and RID Standardization 117 A RID is an application enabler for a UAS to be identified by a UTM/ 118 USS or third parties entities such as law enforcement. Many safety 119 and other considerations dictate that UAS be remotely identifiable. 120 CAAs worldwide are mandating UAS RID. The European Union Aviation 121 Safety Agency (EASA) has published [Delegated] and [Implementing] 122 Regulations. The FAA has published a Notice of Proposed Rule Making 123 [NPRM]. CAAs currently promulgate performance-based regulations that 124 do not specify techniques, but rather cite industry consensus 125 technical standards as acceptable means of compliance. 127 ASTM 129 ASTM International, Technical Committee F38 (UAS), Subcommittee 130 F38.02 (Aircraft Operations), Work Item WK65041, developed the new 131 ASTM [F3411-19] Standard Specification for Remote ID and Tracking. 133 ASTM defines one set of RID information and two means, MAC-layer 134 broadcast and IP-layer network, of communicating it. If a UAS 135 uses both communication methods, generally the same information 136 must provided via both means. The [F3411-19] is cited by FAA in 137 its RID [NPRM] as "one potential means of compliance" to a Remote 138 ID rule. 140 3GPP 142 With release 16, 3GPP completed the UAS RID requirement study 143 [TS-22.825] and proposed use cases in the mobile network and the 144 services that can be offered based on RID. Release 17 145 specification works on enhanced UAS service requirements and 146 provides the protocol and application architecture support which 147 is applicable for both 4G and 5G network. 149 1.2. Overview of Types of UAS Remote ID 151 1.2.1. Network RID 153 A RID data dictionary and data flow for Network RID are defined in 154 [F3411-19]. This flow is from a UAS via unspecified means (but at 155 least in part over the Internet) to a Network Remote ID Service 156 Provider (Net-RID SP). These Net-RID SPs provide this information to 157 Network Remote ID Display Providers (Net-RID DP). It is the Net-RID 158 DP that respond to queries from Network Remote ID clients (expected 159 typically, but not specified exclusively, to be web based) specifying 160 airspace volumes of interest. Network RID depends upon connectivity, 161 in several segments, via the Internet, from the UAS to the observer. 163 The Network RID is illustrated in Figure 1 below: 165 x x UA 166 xxxxx ******************** 167 | \ * ------*---+------------+ 168 | \ * / * | NET_RID_SP | 169 | \ * ------------/ +---*--+------------+ 170 | RF \ */ | * 171 | * INTERNET | * +------------+ 172 | /* +---*--| NET_RID_DP | 173 | / * +---*--+------------+ 174 + / * | * 175 x / *****************|*** x 176 xxxxx | xxxxx 177 x +------- x 178 x x 179 x x Operator (GCS) Observer x x 180 x x x x 182 Figure 1 184 Via the direct Radio Frequency (RF) link between the UA and GCS: 185 Command and Control (C2) flows between the GCS to the UA such that 186 either can communicate with the Net-RID SP. For all but the simplest 187 hobby aircraft, position and status flow from the UA to the GCS and 188 on to the Net-RID SP. Thus via the Internet, through three distinct 189 segments, Network RID information flows from the UAS to the Observer. 191 1.2.2. Broadcast RID 193 A set of RID messages are defined for direct, one-way, broadcast 194 transmissions from the UA over Bluetooth or Wi-Fi. These are 195 currently defined as MAC-Layer messages. Internet (or other Wide 196 Area Network) connectivity is only needed for UAS registry 197 information lookup by Observers using the locally directly received 198 UAS RID as a key. Broadcast RID should be functionally usable in 199 situations with no Internet connectivity. 201 The Broadcast RID is illustrated in Figure 2 below. 203 x x UA 204 xxxxx 205 | 206 | 207 | app messages directly over 208 | one-way RF data link (no IP) 209 | 210 | 211 + 212 x 213 xxxxx 214 x 215 x 216 x x Observer's device (e.g. smartphone) 217 x x 219 Figure 2 221 With Broadcast RID, an Observer is limited to their radio "visible" 222 airspace for UAS awareness and information. With Internet queries 223 using harvested RID, the Observer may gain more information about 224 those visible UAS. 226 1.3. Overview of USS Interoperability 228 Each UAS is registered to at least one USS. With Net-RID, there is 229 direct communication between the UAS and its USS. With Broadcast- 230 RID, the UAS Operator has either pre-filed a 4D space volume for USS 231 operational knowledge and/or Observers can be providing information 232 about observed UA to a USS. USS exchange information via a Discovery 233 and Synchronization Service (DSS) so all USS have knowledge about all 234 activities in a 4D airspace. The interactions among observer, UA and 235 USS is shown in Figure 3. 237 +----------+ 238 | Observer | 239 +----------+ 240 / \ 241 / \ 242 +-----+ +-----+ 243 | UA1 | | UA2 | 244 +-----+ +-----+ 245 \ / 246 \ / 247 +----------+ 248 | Internet | 249 +----------+ 250 / \ 251 / \ 252 +-------+ +-------+ 253 | USS-1 | <-------> | USS-2 | 254 +-------+ +-------+ 255 \ / 256 \ / 257 +------+ 258 | DSS | 259 +------+ 261 Figure 3 263 1.4. Overview of DRIP Archicture 265 The requirements document also provides an extended introduction to 266 the problem space, use cases, etc. Only a brief summary of that 267 introduction will be restated here as context, with reference to the 268 general architecture shown in Figure 4 below. 270 General x x Public 271 Public xxxxx xxxxx Safety 272 Observer x x Observer 273 x x 274 x x ---------+ +---------- x x 275 x x | | x x 276 | | 277 UA1 x x | | +------------ x x UA2 278 xxxxx | | | xxxxx 279 | + + + | 280 | xxxxxxxxxx | 281 | x x | 282 +----------+x Internet x+------------+ 283 UA1 | x x | UA1 284 Pilot x | xxxxxxxxxx | x Pilot 285 Operator xxxxx + + + xxxxx Operator 286 GCS1 x | | | x GCS2 287 x | | | x 288 x x | | | x x 289 x x | | | x x 290 | | | 291 +----------+ | | | +----------+ 292 | |------+ | +-------| | 293 | Public | | | Private | 294 | Registry | +-----+ | Registry | 295 | | | DNS | | | 296 +----------+ +-----+ +----------+ 298 Figure 4 300 Editor's note: the archteture may need more clarification, and 301 address the following: 303 * connectivity requirements among UA, GCS, SP, DP (if necessary) 305 DRIP will enable leveraging existing Internet resources (standard 306 protocols, services, infrastructure and business models) to meet UAS 307 RID and closely related needs. DRIP will specify how to apply IETF 308 standards, complementing [F3411-19] and other external standards, to 309 satisfy UAS RID requirements. DRIP will update existing and develop 310 new protocol standards as needed to accomplish the foregoing. 312 This document will outline the UAS RID architecture into which DRIP 313 must fit, and an architecture for DRIP itself. This includes 314 presenting the gaps between the CAAs' Concepts of Operations and 315 [F3411-19] as it relates to use of Internet technologies and UA 316 direct RF communications. Issues include, but are not limited to: 318 * Mechanisms to leverage Domain Name System (DNS: [RFC1034]) and 319 Extensible Provisioning Protocol (EPP [RFC5731]) technology to 320 provide for private (Section 5.1) and public (Section 5.2) 321 Information Registry. 323 * Trustworthy Remote ID and trust in RID messages Section 6 325 * Privacy in RID messages (PII protection) Section 8 327 Eiditor's Note: The following aspects are not covered in this 328 draft, yet. We may consider add sections for each of them if 329 necessary. 331 * UA -> Ground communications including Broadcast RID 333 * Broadcast RID 'harvesting' and secure forwarding into the UTM 335 * Secure UAS -> Net-RID SP communications 337 * Secure Observer -> Pilot communications 339 2. Conventions 341 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 342 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 343 "OPTIONAL" in this document are to be interpreted as described in BCP 344 14 [RFC2119] [RFC8174] when, and only when, they appear in all 345 capitals, as shown above. 347 3. Definitions and Abbreviations 349 3.1. Additional Definitions 351 Editor's Note: to be updated. 353 This document uses terms defined in [I-D.ietf-drip-reqs]. 355 3.2. Abbreviations 357 Editor's Note: to be updated. 359 ADS-B: Automatic Dependent Surveillance Broadcast 361 DSS: Discovery & Synchronization Service 363 EdDSA: Edwards-Curve Digital Signature Algorithm 365 GCS: Ground Control Station 366 HHIT: Hierarchical HIT Registries 368 HIP: Host Identity Protocol 370 HIT: Host Identity Tag 372 RID: Remote ID 374 Net-RID SP: Network RID Service Provider 376 Net-RID DP: Network RID Display Provider. 378 PII: Personally Identifiable Information 380 RF: Radio Frequency 382 SDSP: Supplemental Data Service Provider 384 UA: Unmanned Aircraft 386 UAS: Unmanned Aircraft System 388 USS: UAS Service Supplier 390 UTM: UAS Traffic Management 392 4. HHIT for UAS Remote ID 394 This section describes the use of Hierarchical Host Identity Tags 395 (HHITs) as self-asserting IPv6 addresses and thereby a trustable 396 Identifier for use as the UAS Remote ID. HHITs self-attest to the 397 included explicit hierarchy that provides Registrar discovery for 398 3rd-party ID attestation. 400 4.1. HIT as a Trustworthy Remote ID 402 For a Remote ID to be trustworthy in the Broadcast mode, there MUST 403 be an asymmetric keypair for proof of ID ownership. The common 404 method of using a key signing operation to assert ownership of an ID, 405 does not guarantee name uniqueness. Any entity can sign an ID, 406 claiming ownership. To mitigate spoofing risks, the ID needs to be 407 cryptographically generated from the public key, in such a manner 408 that it is statistically hard for an entity to create a public key 409 that would generate (spoof) the ID. Thus the signing of such an ID 410 becomes an attestation (compared to claim) of ownership. 412 HITs are statistically unique through the cryptographic hash feature 413 of second-preimage resistance. The cryptographically-bound addition 414 of the Hierarchy and a HHIT registration process (e.g. based on 415 Extensible Provisioning Protocol, [RFC5730]) provide complete, global 416 HHIT uniqueness. This is in contrast to general IDs (e.g. a UUID or 417 device serial number) as the subject in an X.509 certificate. 419 4.2. HHIT for Remote ID Registration and Lookup 421 Remote IDs need a deterministic lookup mechanism that rapidly 422 provides actionable information about the identified UA. The ID 423 itself needs to be the key into the lookup given the constraints 424 imposed by some of the broadcast media. This can best be achieved by 425 an ID registration hierarchy cryptographically embedded within the 426 ID. 428 The original proposal for HITs included a registration hierarchy 429 scheme. This was dropped during HIP development for lack of a use 430 case. No similar mechanism is possible within CGAs. It is a rather 431 straightforward design update to HITs to Hierarchical HITs (HHITs) to 432 meet the UAS Remote ID use case. 434 The HHIT needs to consist of a registration hierarchy, the hashing 435 crypto suite information, and the hash of these items along with the 436 underlying public key. Additional information, e.g. an IPv6 prefix, 437 may enhance the HHITs use beyond the basic Remote ID function (e.g. 438 use in HIP, [RFC7401]). 440 4.3. HHIT for Remote ID Encryption 442 The only (at time of Trustworthy Remote ID design) extant fixed 443 length ID cryptographically derived from a public key are the Host 444 Identity Tag [RFC7401], HITs, and Cryptographically Generated 445 Addresses [RFC3972], CGAs. Both lack a registration/retrieval 446 capability and CGAs have only a limited crypto agility [RFC4982]. 447 Distributed Hash Tables have been tried for HITs [RFC6537]; this is 448 really not workable for a globally deployed UAS Remote ID scheme. 450 The security of HHITs is achieved first through the cryptographic 451 hashing function of the above information, along with a registration 452 process to mitigate the probability of a hash collision (first 453 registered, first allowed). 455 5. DRIP RID Entities (WAS Entities and their interfaces) 457 Editor: This section descrips the DRIP RID ecosystem such as RID 458 design philosophy, PII registration, Still not sure this is a good 459 title since here mainly talks about regiter, maybe use this seciton 460 focus on HHIT RID registration?? I also have suggestion to move the 461 CS-RID to a seperated section 463 Any DRIP solutions for UAS RID must fit into the UTM (or U-space) 464 system. This implies interaction with entities including UA, GCS, 465 USS, Net-RID SP, Net-RID DP, Observers, Operators, Pilots In Command, 466 Remote Pilots, possibly SDSP, etc. The only additional entities 467 introduced in this document are registries, required but not 468 specified by the regulations and [RFC7401], and optionally CS-RID 469 SDSP and Finder nodes. 471 UAS registries hold both public and private UAS information. The 472 public information is primarily pointers to the repositories of, and 473 keys for looking up, the private information. Given these different 474 uses, and to improve scalability, security and simplicity of 475 administration, the public and private information can be stored in 476 different registries, indeed different types of registry. 478 Editor's note: what are differences & relationships among public & 479 private registries, DP, SP, USS 481 5.1. Private Information Registry 483 5.1.1. Background 485 The private information required for UAS RID is similar to that 486 required for Internet domain name registration. Thus a DRIP RID 487 solution can leverage existing Internet resources: registration 488 protocols, infrastructure and business models, by fitting into an ID 489 structure compatible with DNS names. This implies some sort of 490 hierarchy, for scalability, and management of this hierarchy. It is 491 expected that the private registry function will be provided by the 492 same organizations that run USS, and likely integrated with USS. 494 5.1.2. Proposed Approach 496 A DRIP UAS ID MUST be amenable to handling as an Internet domain name 497 (at an arbitrary level in the hierarchy), MUST be registered in at 498 least a pseudo-domain (e.g. .ip6.arpa for reverse lookup), and MAY be 499 registered as a sub-domain (for forward lookup). 501 A DRIP private information registry MUST support essential Internet 502 domain name registry operations (e.g. add, delete, update, query) 503 using interoperable open standard protocols. It SHOULD support the 504 Extensible Provisioning Protocol (EPP) and the Registry Data Access 505 Protocol (RDAP) with access controls. It MAY use XACML to specify 506 those access controls. It MUST be listed in a DNS: that DNS MAY be 507 private; but absent any compelling reasons for use of private DNS, 508 SHOULD be the definitive public Internet DNS hierarchy. The DRIP 509 private information registry in which a given UAS is registered MUST 510 be findable, starting from the UAS ID, using the methods specified in 511 [RFC7484]. A DRIP private information registry MAY support WebFinger 512 as specified in [RFC7033]. 514 5.2. Public Information Registry 516 5.2.1. Background 518 The public information required to be made available by UAS RID is 519 transmitted as cleartext to local observers in Broadcast RID and is 520 served to a client by a Net-RID DP in Network RID. Therefore, while 521 IETF can offer e.g. [RFC6280] as one way to implement Network RID, 522 the only public information required to support essential DRIP 523 functions for UAS RID is that required to look up Internet domain 524 hosts, services, etc. 526 5.2.2. Proposed Approach 528 A DRIP public information registry MUST be a standard DNS server, in 529 the definitive public Internet DNS hierarchy. It MUST support NS, 530 MX, SRV, TXT, AAAA, PTR, CNAME and HIP RR (the last per [RFC8005]) 531 types. If a DRIP public information registry lists, in a HIP RR, any 532 HIP RVS servers for a given DRIP UAS ID, those RVS servers MUST 533 restrict relay services per AAA policy; this may require extensions 534 to [RFC8004]. 536 5.3. CS-RID concept 538 Editor's Note: if CS-RID is optional, may be added in separately 539 section stating optional features Maybe add the CS into 540 architecture diagram 542 ASTM anticipated that regulators would require both Broadcast RID and 543 Network RID for large UAS, but allow RID requirements for small UAS 544 to be satisfied with the operator's choice of either Broadcast RID or 545 Network RID. The EASA initially specified Broadcast RID for UAS of 546 essentially all UAS and is now considering Network RID also. The FAA 547 NPRM requires both for Standard RID and specifies Network RID only 548 for Limited RID. One obvious opportunity is to enhance the 549 architecture with gateways from Broadcast RID to Network RID. This 550 provides the best of both and gives regulators and operators 551 flexibility. Such gateways could be pre-positioned (e.g. around 552 airports and other sensitive areas) and/or crowdsourced (as nothing 553 more than a smartphone with a suitable app is needed). As Broadcast 554 RID media have limited range, gateways receiving messages claiming 555 locations far from the gateway can alert authorities or a SDSP to the 556 failed sanity check possibly indicating intent to deceive. 557 Surveillance SDSPs can use messages with precise date/time/position 558 stamps from the gateways to multilaterate UA location, independent of 559 the locations claimed in the messages, which are entirely operator 560 self-reported in UAS RID and UTM. Further, gateways with additional 561 sensors (e.g. smartphones with cameras) can provide independent 562 information on the UA type and size, confirming or refuting those 563 claims made in the RID messages. CS-RID would be an option, beyond 564 baseline DRIP functionality; if implemented, it adds two more entity 565 types. 567 5.3.1. Proposed optional CS-RID SDSP 569 A CS-RID SDSP MUST appear (i.e. present the same interface) to a Net- 570 RID SP as a Net-RID DP. A CS-RID SDSP MUST appear to a Net-RID DP as 571 a Net-RID SP. A CS-RID SDSP MUST NOT present a standard GCS-facing 572 interface as if it were a Net-RID SP. A CS-RID SDSP MUST NOT present 573 a standard client-facing interface as if it were a Net-RID DP. A CS- 574 RID SDSP MUST present a TBD interface to a CS-RID Finder; this 575 interface SHOULD be based upon but readily distinguishable from that 576 between a GCS and a Net-RID SP. 578 5.3.2. Proposed optional CS-RID Finder 580 A CS-RID Finder MUST present a TBD interface to a CS-RID SDSP; this 581 interface SHOULD be based upon but readily distinguishable from that 582 between a GCS and a Net-RID SP. A CS-RID Finder must implement, 583 integrate, or accept outputs from, a Broadcast RID receiver. A CS- 584 RID Finder MUST NOT interface directly with a GCS, Net-RID SP, Net- 585 RID DP or Network RID client. 587 6. UAS Remote Identifiers 589 6.1. Background 591 A DRIP UA ID needs to be "Trustworthy". This means that within the 592 framework of the RID messages, an observer can establish that the RID 593 used does uniquely belong to the UA. That the only way for any other 594 UA to assert this RID would be to steal something from within the UA. 595 The RID is self-generated by the UAS (either UA or GCS) and 596 registered with the USS. 598 Within the limitations of Broadcast RID, this is extremely 599 challenging as: 601 * An RID can at most be 20 characters 603 * The ASTM Basic RID message (the message containing the RID) is 25 604 characters; only 3 characters are currently unused 606 * The ASTM Authentication message, with some changes from [F3411-19] 607 can carry 224 bytes of payload. 609 Standard approaches like X.509 and PKI will not fit these 610 constraints, even using the new EdDSA algorithm. An example of a 611 technology that will fit within these limitations is an enhancement 612 of the Host Identity Tag (HIT) of HIPv2 [RFC7401] introducing 613 hierarchy as defined in HHIT [I-D.ietf-drip-rid]; using Hierarchical 614 HITs for UAS RID is outlined in HHIT based UAS RID 615 [I-D.ietf-drip-rid]. As PKI with X.509 is being used in other 616 systems with which UAS RID must interoperate (e.g. the UTM Discovery 617 and Synchronization Service and the UTM InterUSS protocol) mappings 618 between the more flexible but larger X.509 certificates and the HHIT 619 based structures must be devised. 621 By using the EdDSA HHIT suite, self-assertions of the RID can be done 622 in as little as 84 bytes. Third-party assertions can be done in 200 623 bytes. An observer would need Internet access to validate a self- 624 assertion claim. A third-party assertion can be validated via a 625 small credential cache in a disconnected environment. This third- 626 party assertion is possible when the third-party also uses HHITs for 627 its identity and the UA has the public key for that HHIT. 629 6.2. Proposed Approach 631 A DRIP UAS ID MUST be a HHIT. It SHOULD be self-generated by the UAS 632 (either UA or GCS) and MUST be registered with the Private 633 Information Registry identified in its hierarchy fields. Each UAS ID 634 HHIT MUST NOT be used more than once, with one exception as follows. 636 Each UA MAY be assigned, by its manufacturer, a single HI and derived 637 HHIT encoded as a hardware serial number per [CTA2063A]. Such a 638 static HHIT SHOULD be used only to bind one-time use UAS IDs (other 639 HHITs) to the unique UA. Depending upon implementation, this may 640 leave a HI private key in the possession of the manufacturer (see 641 Security Considerations). 643 Each UA equipped for Broadcast RID MUST be provisioned not only with 644 its HHIT but also with the HI public key from which the HHIT was 645 derived and the corresponding private key, to enable message 646 signature. Each UAS equipped for Network RID MUST be provisioned 647 likewise; the private key SHOULD reside only in the ultimate source 648 of Network RID messages (i.e. on the UA itself if the GCS is merely 649 relaying rather than sourcing Network RID messages). Each observer 650 device MUST be provisioned with public keys of the UAS RID root 651 registries and MAY be provisioned with public keys or certificates 652 for subordinate registries. 654 Operators and Private Information Registries MUST possess and other 655 UTM entities MAY possess UAS ID style HHITs. When present, such 656 HHITs SHOULD be used with HIP to strongly mutually authenticate and 657 optionally encrypt communications. 659 7. DRIP Transactions enabling Trustworthy 661 Each Operator MUST generate a Host Identity of the Operator (HIo) and 662 derived Hierarchical HIT of the Operator (HHITo), register them with 663 a Private Information Registry along with whatever Operator data 664 (inc. PII) is required by the cognizant CAA and the registry, and 665 obtain a Certificate from the Registry on the Operator (Cro) signed 666 with the Host Identity of the Registry private key (HIr(priv)) 667 proving such registration. 669 To add an UA, an Operator MUST generate a Host Identity of the 670 Aircraft (HIa) and derived Hierarchical HIT of the Aircraft (HHITa), 671 create a Certificate from the Operator on the Aircraft (Coa) signed 672 with the Host Identity of the Operator private key (HIo(priv)) to 673 associate the UA with its Operator, register them with a Private 674 Information Registry along with whatever UAS data is required by the 675 cognizant CAA and the registry, obtain a Certificate from the 676 Registry on the Operator and Aircraft ("Croa") signed with the 677 HIr(priv) proving such registration, and obtain a Certificate from 678 the Registry on the Aircraft (Cra) signed with HIr(priv) proving UA 679 registration in that specific registry while preserving Operator 680 privacy. The operator then MUST provision the UA with HIa, 681 HIa(priv), HHITa and Cra. 683 UA engaging in Broadcast RID MUST use HIa(priv) to sign Auth Messages 684 and MUST periodically broadcast Cra. UAS engaging in Network RID MUST 685 use HIa(priv) to sign Auth Messages. Observers MUST use HIa from 686 received Cra to verify received Broadcast RID Auth messages. 687 Observers without Internet connectivity MAY use Cra to identify the 688 trust class of the UAS based on known registry vetting. Observers 689 with Internet connectivity MAY use HHITa to perform lookups in the 690 Public Information Registry and MAY then query the Private 691 Information Registry, which MUST enforce AAA policy on Operator PII 692 and other sensitive information. 694 8. Privacy for Broadcast PII 696 Editor's ntoe: move this to a subsction of Operator Privacy? 698 Broadcast RID messages may contain PII. This may be information 699 about the UA such as its destination or Operator information such as 700 GCS location. There is no absolute "right" in hiding PII, as there 701 will be times (e.g., disasters) and places (buffer zones around 702 airports and sensitive facilities) where policy may mandate all 703 information be sent as cleartext. Otherwise, the modern general 704 position (consistent with, e.g., the EU General Data Protection 705 Regulation) is to hide PII unless otherwise instructed. While some 706 have argued that a system like that of automobile registration plates 707 should suffice for UAS, others have argued persuasively that each 708 generation of new identifiers should take advantage of advancing 709 technology to protect privacy, to the extent compatible with the 710 transparency needed to protect safety. 712 A viable architecture for PII protection would be symmetric 713 encryption of the PII using a key known to the UAS and a USS service. 714 An authorized Observer may send the encrypted PII along with the 715 Remote ID (to their UAS display service) to get the plaintext. The 716 authorized Observer may send the Remote ID (to their UAS display 717 service) and receive the key to directly decrypt all PII content from 718 the UA. 720 PII is protected unless the UAS is informed otherwise. This may come 721 from operational instructions to even permit flying in a space/time. 722 It may be special instructions at the start or during an operation. 723 PII protection should not be used if the UAS loses connectivity to 724 the USS. The USS always has the option to abort the operation if PII 725 protection is disallowed. 727 An authorized observer may instruct a UAS via the USS that conditions 728 have changed mandating no PII protection or land the UA. 730 9. IANA Considerations 732 Editor's note: placeholder 734 10. Security Considerations 736 DRIP is all about safety and security, so content pertaining to such 737 is not limited to this section. The security provided by asymmetric 738 cryptographic techniques depends upon protection of the private keys. 739 A manufacturer that embeds a private key in an UA may have retained a 740 copy. A manufacturer whose UA are configured by a closed source 741 application on the GCS which communicates over the Internet with the 742 factory may be sending a copy of a UA or GCS self-generated key back 743 to the factory. Keys may be extracted from a GCS or UA; the RID 744 sender of a small harmless UA (or the entire UA) could be carried by 745 a larger dangerous UA as a "false flag." Compromise of a registry 746 private key could do widespread harm. Key revocation procedures are 747 as yet to be determined. These risks are in addition to those 748 involving Operator key management practices. 750 11. Acknowledgements 752 The work of the FAA's UAS Identification and Tracking (UAS ID) 753 Aviation Rulemaking Committee (ARC) is the foundation of later ASTM 754 and proposed IETF DRIP WG efforts. The work of ASTM F38.02 in 755 balancing the interests of diverse stakeholders is essential to the 756 necessary rapid and widespread deployment of UAS RID. IETF 757 volunteers who have contributed to this draft include Amelia 758 Andersdotter and Mohamed Boucadair. 760 12. References 762 12.1. Normative References 764 [I-D.ietf-drip-reqs] 765 Card, S., Wiethuechter, A., Moskowitz, R., and A. Gurtov, 766 "Drone Remote Identification Protocol (DRIP) 767 Requirements", Work in Progress, Internet-Draft, draft- 768 ietf-drip-reqs-06, 1 November 2020, . 771 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 772 Requirement Levels", BCP 14, RFC 2119, 773 DOI 10.17487/RFC2119, March 1997, 774 . 776 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 777 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 778 May 2017, . 780 12.2. Informative References 782 [CTA2063A] ANSI, "Small Unmanned Aerial Systems Serial Numbers", 783 2019. 785 [Delegated] 786 European Union Aviation Safety Agency (EASA), "EU 787 Commission Delegated Regulation 2019/945 of 12 March 2019 788 on unmanned aircraft systems and on third-country 789 operators of unmanned aircraft systems", 2019. 791 [F3411-19] ASTM, "Standard Specification for Remote ID and Tracking", 792 2019. 794 [I-D.ietf-drip-rid] 795 Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov, 796 "UAS Remote ID", Work in Progress, Internet-Draft, draft- 797 ietf-drip-rid-04, 1 November 2020, . 800 [Implementing] 801 European Union Aviation Safety Agency (EASA), "EU 802 Commission Implementing Regulation 2019/947 of 24 May 2019 803 on the rules and procedures for the operation of unmanned 804 aircraft", 2019. 806 [LAANC] United States Federal Aviation Administration (FAA), "Low 807 Altitude Authorization and Notification Capability", n.d., 808 . 811 [NPRM] United States Federal Aviation Administration (FAA), 812 "Notice of Proposed Rule Making on Remote Identification 813 of Unmanned Aircraft Systems", 2019. 815 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 816 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 817 . 819 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 820 RFC 3972, DOI 10.17487/RFC3972, March 2005, 821 . 823 [RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash 824 Algorithms in Cryptographically Generated Addresses 825 (CGAs)", RFC 4982, DOI 10.17487/RFC4982, July 2007, 826 . 828 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 829 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 830 . 832 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 833 Domain Name Mapping", STD 69, RFC 5731, 834 DOI 10.17487/RFC5731, August 2009, 835 . 837 [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., 838 Tschofenig, H., and H. Schulzrinne, "An Architecture for 839 Location and Location Privacy in Internet Applications", 840 BCP 160, RFC 6280, DOI 10.17487/RFC6280, July 2011, 841 . 843 [RFC6537] Ahrenholz, J., "Host Identity Protocol Distributed Hash 844 Table Interface", RFC 6537, DOI 10.17487/RFC6537, February 845 2012, . 847 [RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr, 848 "WebFinger", RFC 7033, DOI 10.17487/RFC7033, September 849 2013, . 851 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 852 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 853 RFC 7401, DOI 10.17487/RFC7401, April 2015, 854 . 856 [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data 857 (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March 858 2015, . 860 [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 861 Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, 862 October 2016, . 864 [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name 865 System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, 866 October 2016, . 868 [TS-22.825] 869 3GPP, "UAS RID requirement study", n.d., 870 . 873 [U-Space] European Organization for the Safety of Air Navigation 874 (EUROCONTROL), "U-space Concept of Operations", 2019, 875 . 878 Appendix A. Overview of Unmanned Aircraft Systems (UAS) Traffic 879 A.1. Operation Concept 881 The National Aeronautics and Space Administration (NASA) and FAAs' 882 effort of integrating UAS's operation into the national airspace 883 system (NAS) leads to the development of the concept of UTM and the 884 ecosystem around it. The UTM concept was initially presented in 885 2013. The eventual development and implementation are conducted by 886 the UTM research transition team which is the joint workforce by FAA 887 and NASA. World efforts took place afterward. The Single European 888 Sky ATM Research (SESAR) started the CORUS project to research its 889 UTM counterpart concept, namely [U-Space]. This effort is led by the 890 European Organization for the Safety of Air Navigation (Eurocontrol). 892 Both NASA and SESAR have published the UTM concept of operations to 893 guide the development of their future air traffic management (ATM) 894 system and make sure safe and efficient integrations of manned and 895 unmanned aircraft into the national airspace. 897 The UTM composes of UAS operation infrastructure, procedures and 898 local regulation compliance policies to guarantee UAS's safe 899 integration and operation. The main functionality of a UTM includes, 900 but is not limited to, providing means of communication between UAS 901 operators and service providers and a platform to facilitate 902 communication among UAS service providers. 904 A.2. UAS Service Supplier (USS) 906 A USS plays an important role to fulfill the key performance 907 indicators (KPIs) that a UTM has to offer. Such Entity acts as a 908 proxy between UAS operators and UTM service providers. It provides 909 services like real-time UAS traffic monitor and planning, 910 aeronautical data archiving, airspace and violation control, 911 interacting with other third-party control entities, etc. A USS can 912 coexist with other USS(s) to build a large service coverage map which 913 can load-balance, relay and share UAS traffic information. 915 The FAA works with UAS industry shareholders and promotes the Low 916 Altitude Authorization and Notification Capability [LAANC] program 917 which is the first implementation to realize UTM's functionality. 918 The LAANC program can automate the UAS's fly plan application and 919 approval process for airspace authorization in real-time by checking 920 against multiple aeronautical databases such as airspace 921 classification and fly rules associated with it, FAA UAS facility 922 map, special use airspace, Notice to airman (NOTAM) and Temporary 923 flight rule (TFR). 925 A.3. UTM Use Cases for UAS Operations 927 This section illustrates a couple of use case scenarios where UAS 928 participation in UTM has significant safety improvement. 930 1. For a UAS participating in UTM and takeoff or land in a 931 controlled airspace (e.g., Class Bravo, Charlie, Delta and Echo 932 in United States), the USS where UAS is currently communicating 933 with is responsible for UAS's registration, authenticating the 934 UAS's fly plan by checking against designated UAS fly map 935 database, obtaining the air traffic control (ATC) authorization 936 and monitor the UAS fly path in order to maintain safe boundary 937 and follow the pre-authorized route. 939 2. For a UAS participating in UTM and take off or land in an 940 uncontrolled airspace (ex. Class Golf in the United States), 941 pre-fly authorization must be obtained from a USS when operating 942 beyond-visual-of-sight (BVLOS) operation. The USS either accepts 943 or rejects received intended fly plan from the UAS. Accepted UAS 944 operation may share its current fly data such as GPS position and 945 altitude to USS. The USS may keep the UAS operation status near 946 real-time and may keep it as a record for overall airspace air 947 traffic monitor. 949 A.4. Automatic Dependent Surveillance Broadcast (ADS-B) 951 The ADS-B is the de facto technology used in manned aviation for 952 sharing locaiton infomraiton, which is a ground and satellite based 953 system designed in the early 2000s. Broadcast RID is conceptually 954 similar to ADS-B. However, for numerous technical and regulatory 955 reasons, ADS-B itself is not suitable for low-flying small UA. 956 Technical reasons include: needing RF-LOS to large, expensive (hence 957 scarce) ground stations; needing both a satellite receiver and 1090 958 MHz transceiver onboard CSWaP constrained UA; the limited bandwidth 959 of both uplink and downlink, which are adequate for the current 960 manned aviation traffic volume, but would likely be saturated by 961 large numbers of UAS, endangering manned aviation; etc. 962 Understanding these technical shortcomings, regulators world-wide 963 have ruled out use of ADS-B for the small UAS for which UAS RID and 964 DRIP are intended. 966 Authors' Addresses 967 Stuart W. Card 968 AX Enterprize 969 4947 Commercial Drive 970 Yorkville, NY, 13495 971 United States of America 973 Email: stu.card@axenterprize.com 975 Adam Wiethuechter 976 AX Enterprize 977 4947 Commercial Drive 978 Yorkville, NY, 13495 979 United States of America 981 Email: adam.wiethuechter@axenterprize.com 983 Robert Moskowitz 984 HTT Consulting 985 Oak Park, MI, 48237 986 United States of America 988 Email: rgm@labs.htt-consult.com 990 Shuai Zhao 991 Tencent 992 2747 Park Blvd 993 Palo Alto, 94588 994 United States of America 996 Email: shuai.zhao@ieee.org 998 Andrei Gurtov 999 Linkoeping University 1000 IDA 1001 SE-58183 Linkoeping Linkoeping 1002 Sweden 1004 Email: gurtov@acm.org