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