idnits 2.17.1 draft-ietf-drip-arch-08.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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 213 has weird spacing: '...bserver x x...' == Line 287 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 (21 January 2021) is 1188 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-06 -- Obsolete informational reference (is this intentional?): RFC 7484 (Obsoleted by RFC 9224) Summary: 1 error (**), 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: 25 July 2021 R. Moskowitz 6 HTT Consulting 7 S. Zhao (Editor) 8 Tencent 9 A. Gurtov 10 Linkoeping University 11 21 January 2021 13 Drone Remote Identification Protocol (DRIP) Architecture 14 draft-ietf-drip-arch-08 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 25 July 2021. 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 UAS Remote ID (RID) and RID Standardization . . 3 58 1.2. Overview of Types of UAS Remote ID . . . . . . . . . . . 4 59 1.2.1. Broadcast RID . . . . . . . . . . . . . . . . . . . . 4 60 1.2.2. Network RID . . . . . . . . . . . . . . . . . . . . . 5 61 1.3. Overview of USS Interoperability . . . . . . . . . . . . 6 62 1.4. Overview of DRIP Architecture . . . . . . . . . . . . . . 6 63 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 3. Definitions and Abbreviations . . . . . . . . . . . . . . . . 8 65 3.1. Additional Definitions . . . . . . . . . . . . . . . . . 8 66 3.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 8 67 3.3. Claims, Assertions, Attestations, and Certificates . . . 9 68 4. HHIT for UAS Remote ID . . . . . . . . . . . . . . . . . . . 10 69 4.1. UAS Remote Identifiers Problem Space . . . . . . . . . . 10 70 4.2. HIT as A Trustworthy UAS Remote ID . . . . . . . . . . . 11 71 4.3. HHIT for Remote ID Registration and Lookup . . . . . . . 11 72 4.4. HHIT for Remote ID Encryption . . . . . . . . . . . . . . 12 73 5. DRIP HHIT RID Registration and Registries . . . . . . . . . . 13 74 5.1. Public Information Registry . . . . . . . . . . . . . . . 13 75 5.1.1. Background . . . . . . . . . . . . . . . . . . . . . 13 76 5.1.2. Proposed Approach . . . . . . . . . . . . . . . . . . 13 77 5.2. Private Information Registry . . . . . . . . . . . . . . 13 78 5.2.1. Background . . . . . . . . . . . . . . . . . . . . . 14 79 5.2.2. Proposed Approach . . . . . . . . . . . . . . . . . . 14 80 6. Harvesting Broadcast Remote ID messages for UTM Inclusion . . 14 81 6.1. The CS-RID Finder . . . . . . . . . . . . . . . . . . . . 15 82 6.2. The CS-RID SDSP . . . . . . . . . . . . . . . . . . . . . 15 83 7. DRIP Transactions Enabling Trustworthy . . . . . . . . . . . 16 84 8. Privacy for Broadcast PII . . . . . . . . . . . . . . . . . . 17 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 86 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 89 11.2. Informative References . . . . . . . . . . . . . . . . . 18 90 Appendix A. Overview of Unmanned Aircraft Systems (UAS) 91 Traffic . . . . . . . . . . . . . . . . . . . . . . . . . 20 92 A.1. Operation Concept . . . . . . . . . . . . . . . . . . . . 20 93 A.2. UAS Service Supplier (USS) . . . . . . . . . . . . . . . 21 94 A.3. UTM Use Cases for UAS Operations . . . . . . . . . . . . 21 95 A.4. Automatic Dependent Surveillance Broadcast (ADS-B) . . . 22 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 98 1. Introduction 100 This document describes an architecture for protocols and services to 101 support Unmanned Aircraft System Remote Identification and tracking 102 (UAS RID), plus RID-related communications, conforming to proposed 103 regulations and external technical standards, satisfying the 104 requirements listed in the companion requirements document 105 [I-D.ietf-drip-reqs]. 107 Many considerations (especially safety) dictate that UAS be remotely 108 identifiable. Civil Aviation Authorities (CAAs) worldwide are 109 mandating Unmanned Aircraft Systems (UAS) Remote Identification 110 (RID). CAAs currently (2020) promulgate performance-based 111 regulations that do not specify techniques, but rather cite industry 112 consensus technical standards as acceptable means of compliance. 114 1.1. Overview UAS Remote ID (RID) and RID Standardization 116 A RID is an application enabler for a UAS to be identified by a UTM/ 117 USS or third parties entities such as law enforcement. Many safety 118 and other considerations dictate that UAS be remotely identifiable. 119 CAAs worldwide are mandating UAS RID. The European Union Aviation 120 Safety Agency (EASA) has published [Delegated] and [Implementing] 121 Regulations. The FAA has published a Notice of Proposed Rule Making 122 [NPRM]. CAAs currently promulgate performance-based regulations that 123 do not specify techniques, but rather cite industry consensus 124 technical standards as acceptable means of compliance. 126 ASTM 128 ASTM International, Technical Committee F38 (UAS), Subcommittee 129 F38.02 (Aircraft Operations), Work Item WK65041, developed the new 130 ASTM [F3411-19] Standard Specification for Remote ID and Tracking. 132 ASTM defines one set of RID information and two means, MAC-layer 133 broadcast and IP-layer network, of communicating it. If a UAS 134 uses both communication methods, generally the same information 135 must provided via both means. The [F3411-19] is cited by FAA in 136 its RID [NPRM] as "one potential means of compliance" to a Remote 137 ID rule. 139 3GPP 140 With release 16, 3GPP completed the UAS RID requirement study 141 [TS-22.825] and proposed use cases in the mobile network and the 142 services that can be offered based on RID. Release 17 143 specification works on enhanced UAS service requirements and 144 provides the protocol and application architecture support which 145 is applicable for both 4G and 5G network. 147 1.2. Overview of Types of UAS Remote ID 149 1.2.1. Broadcast RID 151 A set of RID messages are defined for direct, one-way, broadcast 152 transmissions from the UA over Bluetooth or Wi-Fi. These are 153 currently defined as MAC-Layer messages. Internet (or other Wide 154 Area Network) connectivity is only needed for UAS registry 155 information lookup by observers using the locally directly received 156 UAS RID as a key. Broadcast RID should be functionally usable in 157 situations with no Internet connectivity. 159 The Broadcast RID is illustrated in Figure 1 below. 161 x x UA 162 xxxxx 163 | 164 | 165 | app messages directly over 166 | one-way RF data link (no IP) 167 | 168 | 169 + 170 x 171 xxxxx 172 x 173 x 174 x x Observer's device (e.g. smartphone) 175 x x 177 Figure 1 179 With Broadcast RID, an Observer is limited to their radio "visible" 180 airspace for UAS awareness and information. With Internet queries 181 using harvested RID, the Observer may gain more information about 182 those visible UAS. 184 1.2.2. Network RID 186 A RID data dictionary and data flow for Network RID are defined in 187 [F3411-19]. This data flow is from a UAS via unspecified means (but 188 at least in part over the Internet) to a Network Remote ID Service 189 Provider (Net-RID SP). These Net-RID SPs provide the RID data 190 information to Network Remote ID Display Providers (Net-RID DP). It 191 is the Net-RID DP that responds to queries from Network Remote ID 192 observers (expected typically, but not specified exclusively, to be 193 web based) specifying airspace volumes of interest. Network RID 194 depends upon connectivity, in several segments, via the Internet, 195 from the UAS to the observer. 197 The Network RID is illustrated in Figure 2 below: 199 x x UA 200 xxxxx ******************** 201 | \ * ------*---+------------+ 202 | \ * / * | NET_RID_SP | 203 | \ * ------------/ +---*--+------------+ 204 | RF \ */ | * 205 | * INTERNET | * +------------+ 206 | /* +---*--| NET_RID_DP | 207 | / * +---*--+------------+ 208 + / * | * 209 x / *****************|*** x 210 xxxxx | xxxxx 211 x +------- x 212 x x 213 x x Operator (GCS) Observer x x 214 x x x x 216 Figure 2 218 Via the direct Radio Frequency (RF) link between the UA and GCS, 219 Command and Control (C2) flows between the GCS to the UA such that 220 either can communicate with the Net-RID SP. For all but the simplest 221 hobby aircraft, position and status flow from the UA to the GCS and 222 on to the Net-RID SP. Thus via the Internet, through three distinct 223 segments, Network RID information flows from the UAS to the Observer. 225 Informative note: The RF link between UA and GCS is not in 226 scope of the Network RID. 228 1.3. Overview of USS Interoperability 230 Each UAS is registered to at least one USS. With Net-RID, there is 231 direct communication between the UAS and its USS. With Broadcast- 232 RID, the UAS Operator has either pre-filed a 4D space volume for USS 233 operational knowledge and/or Observers can be providing information 234 about observed UA to a USS. USS exchange information via a Discovery 235 and Synchronization Service (DSS) so all USS have knowledge about all 236 activities in a 4D airspace. The interactions among observer, UA and 237 USS is shown in Figure 3. 239 +----------+ 240 | Observer | 241 +----------+ 242 / \ 243 / \ 244 +-----+ +-----+ 245 | UA1 | | UA2 | 246 +-----+ +-----+ 247 \ / 248 \ / 249 +----------+ 250 | Internet | 251 +----------+ 252 / \ 253 / \ 254 +-------+ +-------+ 255 | USS-1 | <-------> | USS-2 | 256 +-------+ +-------+ 257 \ / 258 \ / 259 +------+ 260 | DSS | 261 +------+ 263 Figure 3 265 1.4. Overview of DRIP Architecture 267 The requirements document [I-D.ietf-drip-reqs] also provides an 268 extended introduction to the problem space, use cases, etc. Only a 269 brief summary of that introduction will be restated here as context, 270 with reference to the general architecture shown in Figure 4 below. 272 General x x Public 273 Public xxxxx xxxxx Safety 274 Observer x x Observer 275 x x 276 x x ---------+ +---------- x x 277 x x | | x x 278 | | 279 UA1 x x | | +------------ x x UA2 280 xxxxx | | | xxxxx 281 | + + + | 282 | xxxxxxxxxx | 283 | x x | 284 +----------+x Internet x+------------+ 285 UA1 | x x | UA1 286 Pilot x | xxxxxxxxxx | x Pilot 287 Operator xxxxx + + + xxxxx Operator 288 GCS1 x | | | x GCS2 289 x | | | x 290 x x | | | x x 291 x x | | | x x 292 | | | 293 +----------+ | | | +----------+ 294 | |------+ | +-------| | 295 | Public | | | Private | 296 | Registry | +-----+ | Registry | 297 | | | DNS | | | 298 +----------+ +-----+ +----------+ 300 Figure 4 302 Editor's note 1: the architecture may need more clarification, and 303 address the following: 305 * connectivity requirements among UA, GCS, SP, DP (if necessary) 307 DRIP will enable leveraging existing Internet resources (standard 308 protocols, services, infrastructure and business models) to meet UAS 309 RID and closely related needs. DRIP will specify how to apply IETF 310 standards, complementing [F3411-19] and other external standards, to 311 satisfy UAS RID requirements. DRIP will update existing and develop 312 new protocol standards as needed to accomplish the foregoing. 314 This document will outline the UAS RID architecture into which DRIP 315 must fit, and an architecture for DRIP itself. This includes 316 presenting the gaps between the CAAs' Concepts of Operations and 317 [F3411-19] as it relates to use of Internet technologies and UA 318 direct RF communications. Issues include, but are not limited to: 320 * Mechanisms to leverage Domain Name System (DNS: [RFC1034]) and 321 Extensible Provisioning Protocol (EPP [RFC5731]) technology to 322 provide for private (Section 5.2) and public (Section 5.1) 323 Information Registry. 325 * Trustworthy Remote ID and trust in RID messages (Section 4) 327 * Privacy in RID messages (PII protection) (Section 8) 329 Editor's Note 2 : The following aspects are not covered in this 330 draft, yet. We may consider add sections for each of them if 331 necessary. 333 * UA -> Ground communications including Broadcast RID 335 * Broadcast RID 'harvesting' and secure forwarding into the UTM 337 * Secure UAS -> Net-RID SP communications 339 * Secure Observer -> Pilot communications 341 2. Conventions 343 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 344 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 345 "OPTIONAL" in this document are to be interpreted as described in BCP 346 14 [RFC2119] [RFC8174] when, and only when, they appear in all 347 capitals, as shown above. 349 3. Definitions and Abbreviations 351 3.1. Additional Definitions 353 This document uses terms defined in [I-D.ietf-drip-reqs]. 355 3.2. Abbreviations 357 ADS-B: Automatic Dependent Surveillance Broadcast 359 DSS: Discovery & Synchronization Service 361 EdDSA: Edwards-Curve Digital Signature Algorithm 363 GCS: Ground Control Station 365 HHIT: Hierarchical HIT Registries 367 HIP: Host Identity Protocol 368 HIT: Host Identity Tag 370 RID: Remote ID 372 Net-RID SP: Network RID Service Provider 374 Net-RID DP: Network RID Display Provider. 376 PII: Personally Identifiable Information 378 RF: Radio Frequency 380 SDSP: Supplemental Data Service Provider 382 UA: Unmanned Aircraft 384 UAS: Unmanned Aircraft System 386 USS: UAS Service Supplier 388 UTM: UAS Traffic Management 390 3.3. Claims, Assertions, Attestations, and Certificates 392 This section introduces the meaning of "Claims", "Assertions", 393 "Attestations", and "Certificates" in the context of DRIP. 395 This is due, in part, to the term "certificate" having significant 396 technologic and legal baggage associated with it, specifically around 397 X.509 certificates. These type of certificates and Public Key 398 Infrastructure invokes more legal and public policy considerations 399 than probably any other electronic communication sector. It emerged 400 as a governmental platform for trusted identity management and was 401 pursued in intergovernmental bodies with links into treaty 402 instruments. As such the following terms are being used in DRIP. 404 Claims: 406 For DRIP claims are used in the form of a predicate (X is Y, X has 407 property Y, and most importantly X owns Y). The basic form of a 408 claim is an entity using a HHIT as an identifier in the DRIP UAS 409 system. 411 Assertions: 413 Assertions, under DRIP, are defined as being a set of one or more 414 claims. This definition is borrowed from JWT/CWT. An HHIT in of 415 itself can be seen as a set of assertions. First that the 416 identifier is a handle to an asymmetric keypair owned by the 417 entity and that it also is part of the given registry (specified 418 by the HID). 420 Attestations: 422 An attestation is a signed claim. The signee may be the claimant 423 themselves or a third party. Under DRIP this is normally used 424 when a set of entities asserts a relationship between them along 425 with other information. 427 Certificates: 429 Certificates in DRIP have a narrow definition of being signed 430 exclusively by a third party and are only over identities. 432 4. HHIT for UAS Remote ID 434 This section describes the basic requirements of a DRIP UAS remote ID 435 per regulation constrains from ASTM [F3411-19] and explains the use 436 of Hierarchical Host Identity Tags (HHITs) as self-asserting IPv6 437 addresses and thereby a trustable Identifier for use as the UAS 438 Remote ID. HHITs self-attest to the included explicit hierarchy that 439 provides Registrar discovery for 3rd-party ID attestation. 441 4.1. UAS Remote Identifiers Problem Space 443 A DRIP UAS ID needs to be "Trustworthy". This means that within the 444 framework of the RID messages, an observer can establish that the RID 445 used does uniquely belong to the UA. That the only way for any other 446 UA to assert this RID would be to steal something from within the UA. 447 The RID is self-generated by the UAS (either UA or GCS) and 448 registered with the USS. 450 The data communication of using Broadcast RID faces extreme 451 challenging due to the limitation set by regulations. The ASTM 452 [F3411-19] defines the Basic RID message which is expected to 453 contained certain RID data and the Authentication message. The Basic 454 RID message has a maximum payload of 25 bytes and the maximum size 455 allocated by ASTM for the RID is 20 bytes and only 3 bytes are left 456 unused. currently, the authentication maximum payload is defined to 457 be 224 bytes. 459 Standard approaches like X.509 and PKI will not fit these 460 constraints, even using the new EdDSA An example of a technology that 461 will fit within these limitations is an enhancement of the Host 462 Identity Tag (HIT) of HIPv2 [RFC8032] algorithm.[RFC7401] using 463 Hierarchical HITs (HHITs) for UAS RID is outlined in HHIT based UAS 464 RID [I-D.ietf-drip-rid]. As PKI with X.509 is being used in other 465 systems with which UAS RID must interoperate (e.g. the UTM Discovery 466 and Synchronization Service and the UTM InterUSS protocol) mappings 467 between the more flexible but larger X.509 certificates and the HHIT 468 based structures must be devised. 470 By using the EdDSA HHIT suite, self-assertions of the RID can be done 471 in as little as 84 bytes. Third-party assertions can be done in 200 472 bytes. An observer would need Internet access to validate a self- 473 assertion claim. A third-party assertion can be validated via a 474 small credential cache in a disconnected environment. This third- 475 party assertion is possible when the third-party also uses HHITs for 476 its identity and the UA has the public key for that HHIT 478 4.2. HIT as A Trustworthy UAS Remote ID 480 For a Remote ID to be trustworthy in the Broadcast mode, there MUST 481 be an asymmetric keypair for proof of ID ownership. The common 482 method of using a key signing operation to assert ownership of an ID, 483 does not guarantee name uniqueness. Any entity can sign an ID, 484 claiming ownership. To mitigate spoofing risks, the ID needs to be 485 cryptographically generated from the public key, in such a manner 486 that it is statistically hard for an entity to create a public key 487 that would generate (spoof) the ID. Thus the signing of such an ID 488 becomes an attestation (compared to claim) of ownership. 490 HITs are statistically unique through the cryptographic hash feature 491 of second-preimage resistance. The cryptographically-bound addition 492 of the Hierarchy and a HHIT registration process (e.g. based on 493 Extensible Provisioning Protocol, [RFC5730]) provide complete, global 494 HHIT uniqueness. This is in contrast to general IDs (e.g. a UUID or 495 device serial number) as the subject in an X.509 certificate. 497 4.3. HHIT for Remote ID Registration and Lookup 499 Remote IDs need a deterministic lookup mechanism that rapidly 500 provides actionable information about the identified UA. The ID 501 itself needs to be the inquiry input into the lookup given the 502 constraints imposed by some of the broadcast media. This can best be 503 achieved by an ID registration hierarchy cryptographically embedded 504 within the ID. 506 The HHIT needs to consist of a registration hierarchy, the hashing 507 crypto suite information, and the hash of these items along with the 508 underlying public key. Additional information, e.g. an IPv6 prefix, 509 may enhance the HHITs use beyond the basic Remote ID function (e.g. 510 use in HIP, [RFC7401]). 512 A DRIP UAS ID SHOULD be a HHIT. It SHOULD be self-generated by the 513 UAS (either UA or GCS) and MUST be registered with the Private 514 Information Registry (More details in Section 5.2) identified in its 515 hierarchy fields. Each UAS ID HHIT MUST NOT be used more than once, 516 with one exception as follows. 518 Each UA MAY be assigned, by its manufacturer, a single HI and derived 519 HHIT encoded as a hardware serial number per [CTA2063A]. Such a 520 static HHIT SHOULD be used only to bind one-time use UAS IDs (other 521 HHITs) to the unique UA. Depending upon implementation, this may 522 leave a HI private key in the possession of the manufacturer (see 523 Security Considerations). 525 Each UA equipped for Broadcast RID MUST be provisioned not only with 526 its HHIT but also with the HI public key from which the HHIT was 527 derived and the corresponding private key, to enable message 528 signature. Each UAS equipped for Network RID MUST be provisioned 529 likewise; the private key SHOULD reside only in the ultimate source 530 of Network RID messages (i.e. on the UA itself if the GCS is merely 531 relaying rather than sourcing Network RID messages). Each observer 532 device MUST be provisioned with public keys of the UAS RID root 533 registries and MAY be provisioned with public keys or certificates 534 for subordinate registries. 536 Operators and Private Information Registries MUST possess and other 537 UTM entities MAY possess UAS ID style HHITs. When present, such 538 HHITs SHOULD be used with HIP to strongly mutually authenticate and 539 optionally encrypt communications. 541 4.4. HHIT for Remote ID Encryption 543 The only (at time of Trustworthy Remote ID design) extant fixed 544 length ID cryptographically derived from a public key are the Host 545 Identity Tag [RFC7401], HITs, and Cryptographically Generated 546 Addresses [RFC3972], CGAs. Both lack a registration/retrieval 547 capability and CGAs have only a limited crypto agility [RFC4982]. 548 Distributed Hash Tables have been tried for HITs [RFC6537]; this is 549 really not workable for a globally deployed UAS Remote ID scheme. 551 The security of HHITs is achieved first through the cryptographic 552 hashing function of the above information, along with a registration 553 process to mitigate the probability of a hash collision (first 554 registered, first allowed). 556 5. DRIP HHIT RID Registration and Registries 558 The DRIP HHIT RID registration goes beyond what is currently 559 envisioned in UTM for the UAS to USS registration/subscription 560 process. 562 UAS registries hold both public and private UAS information resulting 563 from the UAS RID registration. Given these different uses, and to 564 improve scalability, security and simplicity of administration, the 565 public and private information can be stored in different registries, 566 indeed different types of registry. 568 5.1. Public Information Registry 570 5.1.1. Background 572 The public registry provides trustable information such as 573 attestations of RID ownership and HDA registration. Optionally, 574 pointers to the repositories for the HDA and RAA implicit in the RID 575 can be included (e.g. for HDA and RAA HHIT|HI used in attestation 576 signing operations). This public information will principally used 577 by observers of Broadcast RID messages. Data on UAS that only use 578 Network RID, is only available via an observer's Net-RID DP that 579 would tend to directly provide all public registry information 580 directly. The observer may visually "see" these UAS, but they are 581 silent to the observer; the Net-RID DP is the only source of 582 information based on a query for an airspace volume. Thus there is 583 no need for information on them in a Public Registry. 585 5.1.2. Proposed Approach 587 A DRIP public information registry MUST respond to standard DNS 588 queries, in the definitive public Internet DNS hierarchy. It MUST 589 support NS, MX, SRV, TXT, AAAA, PTR, CNAME and HIP RR (the last per 590 [RFC8005]) types. If a DRIP public information registry lists, in a 591 HIP RR, any HIP RVS servers for a given DRIP UAS ID, those RVS 592 servers MUST restrict relay services per AAA policy; this may require 593 extensions to [RFC8004]. These public information registries SHOULD 594 use secure DNS transport (e.g. DNS over TLS) to deliver public 595 information that is not inherently trustable (e.g. everything other 596 than attestations). 598 5.2. Private Information Registry 599 5.2.1. Background 601 The private information required for DRIP RID is similar to that 602 required for Internet domain name registration. This information 603 SHOULD be available for ALL UAS, including those that only use 604 Network RID. A DRIP RID solution can leverage existing Internet 605 resources: registration protocols, infrastructure and business 606 models, by fitting into an ID structure compatible with DNS names. 607 This implies some sort of hierarchy, for scalability, and management 608 of this hierarchy. It is expected that the private registry function 609 will be provided by the same organizations that run USS, and likely 610 integrated with USS. 612 5.2.2. Proposed Approach 614 A DRIP RID MUST be amenable to handling as an Internet domain name 615 (at an arbitrary level in the hierarchy), MUST be registered in at 616 least a pseudo-domain (e.g. .ip6.arpa for reverse lookup), and MAY be 617 registered as a sub-domain (for forward lookup). This DNS 618 information MAY be protected with DNSSEC. Its access SHOULD be 619 protected with a secure DNS transport (e.g. DNS over TLS). 621 A DRIP private information registry MUST support essential Internet 622 domain name registry operations (e.g. add, delete, update, query) 623 using interoperable open standard protocols. It SHOULD support the 624 Extensible Provisioning Protocol (EPP) and the Registry Data Access 625 Protocol (RDAP) with access controls. It MAY use XACML to specify 626 those access controls. It MUST be listed in a DNS: that DNS MAY be 627 private; but absent any compelling reasons for use of private DNS, 628 SHOULD be the definitive public Internet DNS hierarchy. The DRIP 629 private information registry in which a given UAS is registered MUST 630 be findable, starting from the UAS ID, using the methods specified in 631 [RFC7484]. A DRIP private information registry MAY support WebFinger 632 as specified in [RFC7033]. 634 6. Harvesting Broadcast Remote ID messages for UTM Inclusion 636 ASTM anticipated that regulators would require both Broadcast RID and 637 Network RID for large UAS, but allow RID requirements for small UAS 638 to be satisfied with the operator's choice of either Broadcast RID or 639 Network RID. The EASA initially specified Broadcast RID for UAS of 640 essentially all UAS and is now also considering Network RID. The FAA 641 NPRM requires both for Standard RID and specifies Network RID only 642 for Limited RID. 644 One obvious opportunity is to enhance the architecture with gateways 645 from Broadcast RID to Network RID. This provides the best of both 646 and gives regulators and operators flexibility. It offers 647 considerable enhancement over some Network RID options such as only 648 reporting planned 4D operation space by the operator. 650 These gateways could be pre-positioned (e.g. around airports, public 651 gatherings, and other sensitive areas) and/or crowd-sourced (as 652 nothing more than a smartphone with a suitable app is needed). As 653 Broadcast RID media have limited range, gateways receiving messages 654 claiming locations far from the gateway can alert authorities or a 655 SDSP to the failed sanity check possibly indicating intent to 656 deceive. Surveillance SDSPs can use messages with precise date/time/ 657 position stamps from the gateways to multilaterate UA location, 658 independent of the locations claimed in the messages (which may have 659 a natural time lag as it is), which are entirely operator self- 660 reported in UAS RID and UTM. 662 Further, gateways with additional sensors (e.g. smartphones with 663 cameras) can provide independent information on the UA type and size, 664 confirming or refuting those claims made in the RID messages. This 665 Crowd Sourced Remote ID (CS-RID) would be a significant enhancement, 666 beyond baseline DRIP functionality; if implemented, it adds two more 667 entity types. 669 6.1. The CS-RID Finder 671 A CS-RID Finder is the gateway for Broadcast Remote ID Messages into 672 the UTM. It performs this gateway function via a CS-RID SDSP. A CS- 673 RID Finder must implement, integrate, or accept outputs from, a 674 Broadcast RID receiver. It MUST NOT interface directly with a GCS, 675 Net-RID SP, Net-RID DP or Network RID client. It MUST present a TBD 676 interface to a CS-RID SDSP; this interface SHOULD be based upon but 677 readily distinguishable from that between a GCS and a Net-RID SP. 679 6.2. The CS-RID SDSP 681 A CS-RID SDSP MUST appear (i.e. present the same interface) to a Net- 682 RID SP as a Net-RID DP. A CS-RID SDSP MUST appear to a Net-RID DP as 683 a Net-RID SP. A CS-RID SDSP MUST NOT present a standard GCS-facing 684 interface as if it were a Net-RID SP. A CS-RID SDSP MUST NOT present 685 a standard client-facing interface as if it were a Net-RID DP. A CS- 686 RID SDSP MUST present a TBD interface to a CS-RID Finder; this 687 interface SHOULD be based upon but readily distinguishable from that 688 between a GCS and a Net-RID SP. 690 7. DRIP Transactions Enabling Trustworthy 692 The UTM (U-SPACE) architecture leaves much about all the operators/ 693 UAS to the various USS. Each CAA will have some registration 694 requirements on operators (FAA part 105 is considered very minimal by 695 some CAA), along with some UAS and operation registration. DRIP 696 leverages this model with Identities for each component that augment 697 the DRIP RID and transactions to support these Identities. 699 To this end, in DRIP, each Operator MUST generate a Host Identity of 700 the Operator (HIo) and derived Hierarchical HIT of the Operator 701 (HHITo). These are registered with a Private Information Registry 702 along with whatever Operator data (inc. PII) is required by the 703 cognizant CAA and the registry. In response, the Operator will 704 obtain a Certificate from the Registry, an Operator (Cro), signed 705 with the Host Identity of the Registry private key (HIr(priv)) 706 proving such registration. 708 An Operator may now add a UA. 710 * An Operator MUST generate a Host Identity of the Aircraft (HIa) 711 and derived Hierarchical HIT of the Aircraft (HHITa) 713 * Create a Certificate from the Operator on the Aircraft (Coa) 714 signed with the Host Identity of the Operator private key 715 (HIo(priv)) to associate the UA with its Operator 717 * Register them with a Private Information Registry along with 718 whatever UAS data is required by the cognizant CAA and the 719 registry 721 * Obtain a Certificate from the Registry on the Operator and 722 Aircraft ("Croa") signed with the HIr(priv) proving such 723 registration 725 * And obtain a Certificate from the Registry on the Aircraft (Cra) 726 signed with HIr(priv) proving UA registration in that specific 727 registry while preserving Operator privacy. 729 The operator then MUST provision the UA with HIa, HIa(priv), HHITa 730 and Cra. 732 * UA engaging in Broadcast RID MUST use HIa(priv) to sign Auth 733 Messages and MUST periodically broadcast Cra. 735 * UAS engaging in Network RID MUST use HIa(priv) to sign Auth 736 Messages. 738 * Observers MUST use HIa from received Cra to verify received 739 Broadcast RID Auth messages. 741 * Observers without Internet connectivity MAY use Cra to identify 742 the trust class of the UAS based on known registry vetting. 744 * Observers with Internet connectivity MAY use HHITa to perform 745 lookups in the Public Information Registry and MAY then query the 746 Private Information Registry which MUST enforce AAA policy on 747 Operator PII and other sensitive information 749 8. Privacy for Broadcast PII 751 Broadcast RID messages may contain PII. A viable architecture for 752 PII protection would be symmetric encryption of the PII using a key 753 known to the UAS and its USS. An authorized Observer may send the 754 encrypted PII along with the Remote ID (to their UTM Service 755 Provider) to get the plaintext. Alternatively, the authorized 756 Observer may receive the key to directly decrypt all future PII 757 content from the UA. 759 PII SHOULD protected unless the UAS is informed otherwise. This may 760 come from operational instructions to even permit flying in a space/ 761 time. It may be special instructions at the start or during an 762 operation. PII protection should not be used if the UAS loses 763 connectivity to the USS. The UAS always has the option to abort the 764 operation if PII protection is disallowed. 766 An authorized observer may instruct a UAS via the USS that conditions 767 have changed mandating no PII protection or land the UA (abort the 768 operation). 770 9. Security Considerations 772 The security provided by asymmetric cryptographic techniques depends 773 upon protection of the private keys. A manufacturer that embeds a 774 private key in an UA may have retained a copy. A manufacturer whose 775 UA are configured by a closed source application on the GCS which 776 communicates over the Internet with the factory may be sending a copy 777 of a UA or GCS self-generated key back to the factory. Keys may be 778 extracted from a GCS or UA; the RID sender of a small harmless UA (or 779 the entire UA) could be carried by a larger dangerous UA as a "false 780 flag." Compromise of a registry private key could do widespread 781 harm. Key revocation procedures are as yet to be determined. These 782 risks are in addition to those involving Operator key management 783 practices. 785 10. Acknowledgements 787 The work of the FAA's UAS Identification and Tracking (UAS ID) 788 Aviation Rulemaking Committee (ARC) is the foundation of later ASTM 789 and proposed IETF DRIP WG efforts. The work of ASTM F38.02 in 790 balancing the interests of diverse stakeholders is essential to the 791 necessary rapid and widespread deployment of UAS RID. IETF 792 volunteers who have contributed to this draft include Amelia 793 Andersdotter and Mohamed Boucadair. 795 11. References 797 11.1. Normative References 799 [I-D.ietf-drip-reqs] 800 Card, S., Wiethuechter, A., Moskowitz, R., and A. Gurtov, 801 "Drone Remote Identification Protocol (DRIP) 802 Requirements", Work in Progress, Internet-Draft, draft- 803 ietf-drip-reqs-06, 1 November 2020, . 806 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 807 Requirement Levels", BCP 14, RFC 2119, 808 DOI 10.17487/RFC2119, March 1997, 809 . 811 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 812 Signature Algorithm (EdDSA)", RFC 8032, 813 DOI 10.17487/RFC8032, January 2017, 814 . 816 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 817 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 818 May 2017, . 820 11.2. Informative References 822 [CTA2063A] ANSI, "Small Unmanned Aerial Systems Serial Numbers", 823 2019. 825 [Delegated] 826 European Union Aviation Safety Agency (EASA), "EU 827 Commission Delegated Regulation 2019/945 of 12 March 2019 828 on unmanned aircraft systems and on third-country 829 operators of unmanned aircraft systems", 2019. 831 [F3411-19] ASTM, "Standard Specification for Remote ID and Tracking", 832 2019. 834 [I-D.ietf-drip-rid] 835 Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov, 836 "UAS Remote ID", Work in Progress, Internet-Draft, draft- 837 ietf-drip-rid-06, 31 December 2020, . 840 [Implementing] 841 European Union Aviation Safety Agency (EASA), "EU 842 Commission Implementing Regulation 2019/947 of 24 May 2019 843 on the rules and procedures for the operation of unmanned 844 aircraft", 2019. 846 [LAANC] United States Federal Aviation Administration (FAA), "Low 847 Altitude Authorization and Notification Capability", n.d., 848 . 851 [NPRM] United States Federal Aviation Administration (FAA), 852 "Notice of Proposed Rule Making on Remote Identification 853 of Unmanned Aircraft Systems", 2019. 855 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 856 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 857 . 859 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 860 RFC 3972, DOI 10.17487/RFC3972, March 2005, 861 . 863 [RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash 864 Algorithms in Cryptographically Generated Addresses 865 (CGAs)", RFC 4982, DOI 10.17487/RFC4982, July 2007, 866 . 868 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 869 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 870 . 872 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 873 Domain Name Mapping", STD 69, RFC 5731, 874 DOI 10.17487/RFC5731, August 2009, 875 . 877 [RFC6537] Ahrenholz, J., "Host Identity Protocol Distributed Hash 878 Table Interface", RFC 6537, DOI 10.17487/RFC6537, February 879 2012, . 881 [RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr, 882 "WebFinger", RFC 7033, DOI 10.17487/RFC7033, September 883 2013, . 885 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 886 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 887 RFC 7401, DOI 10.17487/RFC7401, April 2015, 888 . 890 [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data 891 (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March 892 2015, . 894 [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 895 Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, 896 October 2016, . 898 [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name 899 System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, 900 October 2016, . 902 [TS-22.825] 903 3GPP, "UAS RID requirement study", n.d., 904 . 907 [U-Space] European Organization for the Safety of Air Navigation 908 (EUROCONTROL), "U-space Concept of Operations", 2019, 909 . 912 Appendix A. Overview of Unmanned Aircraft Systems (UAS) Traffic 914 A.1. Operation Concept 916 The National Aeronautics and Space Administration (NASA) and FAAs' 917 effort of integrating UAS's operation into the national airspace 918 system (NAS) leads to the development of the concept of UTM and the 919 ecosystem around it. The UTM concept was initially presented in 920 2013. The eventual development and implementation are conducted by 921 the UTM research transition team which is the joint workforce by FAA 922 and NASA. World efforts took place afterward. The Single European 923 Sky ATM Research (SESAR) started the CORUS project to research its 924 UTM counterpart concept, namely [U-Space]. This effort is led by the 925 European Organization for the Safety of Air Navigation (Eurocontrol). 927 Both NASA and SESAR have published the UTM concept of operations to 928 guide the development of their future air traffic management (ATM) 929 system and make sure safe and efficient integrations of manned and 930 unmanned aircraft into the national airspace. 932 The UTM composes of UAS operation infrastructure, procedures and 933 local regulation compliance policies to guarantee UAS's safe 934 integration and operation. The main functionality of a UTM includes, 935 but is not limited to, providing means of communication between UAS 936 operators and service providers and a platform to facilitate 937 communication among UAS service providers. 939 A.2. UAS Service Supplier (USS) 941 A USS plays an important role to fulfill the key performance 942 indicators (KPIs) that a UTM has to offer. Such Entity acts as a 943 proxy between UAS operators and UTM service providers. It provides 944 services like real-time UAS traffic monitor and planning, 945 aeronautical data archiving, airspace and violation control, 946 interacting with other third-party control entities, etc. A USS can 947 coexist with other USS(s) to build a large service coverage map which 948 can load-balance, relay and share UAS traffic information. 950 The FAA works with UAS industry shareholders and promotes the Low 951 Altitude Authorization and Notification Capability [LAANC] program 952 which is the first implementation to realize UTM's functionality. 953 The LAANC program can automate the UAS's fly plan application and 954 approval process for airspace authorization in real-time by checking 955 against multiple aeronautical databases such as airspace 956 classification and fly rules associated with it, FAA UAS facility 957 map, special use airspace, Notice to airman (NOTAM) and Temporary 958 flight rule (TFR). 960 A.3. UTM Use Cases for UAS Operations 962 This section illustrates a couple of use case scenarios where UAS 963 participation in UTM has significant safety improvement. 965 1. For a UAS participating in UTM and takeoff or land in a 966 controlled airspace (e.g., Class Bravo, Charlie, Delta and Echo 967 in United States), the USS where UAS is currently communicating 968 with is responsible for UAS's registration, authenticating the 969 UAS's fly plan by checking against designated UAS fly map 970 database, obtaining the air traffic control (ATC) authorization 971 and monitor the UAS fly path in order to maintain safe boundary 972 and follow the pre-authorized route. 974 2. For a UAS participating in UTM and take off or land in an 975 uncontrolled airspace (ex. Class Golf in the United States), 976 pre-fly authorization must be obtained from a USS when operating 977 beyond-visual-of-sight (BVLOS) operation. The USS either accepts 978 or rejects received intended fly plan from the UAS. Accepted UAS 979 operation may share its current fly data such as GPS position and 980 altitude to USS. The USS may keep the UAS operation status near 981 real-time and may keep it as a record for overall airspace air 982 traffic monitor. 984 A.4. Automatic Dependent Surveillance Broadcast (ADS-B) 986 The ADS-B is the de facto technology used in manned aviation for 987 sharing location information, which is a ground and satellite based 988 system designed in the early 2000s. Broadcast RID is conceptually 989 similar to ADS-B. However, for numerous technical and regulatory 990 reasons, ADS-B itself is not suitable for low-flying small UA. 991 Technical reasons include: needing RF-LOS to large, expensive (hence 992 scarce) ground stations; needing both a satellite receiver and 1090 993 MHz transceiver onboard CSWaP constrained UA; the limited bandwidth 994 of both uplink and downlink, which are adequate for the current 995 manned aviation traffic volume, but would likely be saturated by 996 large numbers of UAS, endangering manned aviation; etc. 997 Understanding these technical shortcomings, regulators world-wide 998 have ruled out use of ADS-B for the small UAS for which UAS RID and 999 DRIP are intended. 1001 Authors' Addresses 1003 Stuart W. Card 1004 AX Enterprize 1005 4947 Commercial Drive 1006 Yorkville, NY, 13495 1007 United States of America 1009 Email: stu.card@axenterprize.com 1011 Adam Wiethuechter 1012 AX Enterprize 1013 4947 Commercial Drive 1014 Yorkville, NY, 13495 1015 United States of America 1017 Email: adam.wiethuechter@axenterprize.com 1018 Robert Moskowitz 1019 HTT Consulting 1020 Oak Park, MI, 48237 1021 United States of America 1023 Email: rgm@labs.htt-consult.com 1025 Shuai Zhao 1026 Tencent 1027 2747 Park Blvd 1028 Palo Alto, 94588 1029 United States of America 1031 Email: shuai.zhao@ieee.org 1033 Andrei Gurtov 1034 Linkoeping University 1035 IDA 1036 SE-58183 Linkoeping Linkoeping 1037 Sweden 1039 Email: gurtov@acm.org