idnits 2.17.1 draft-ietf-drip-arch-03.txt: -(10): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 115 has weird spacing: '... Pilot xxxxx...' == Line 116 has weird spacing: '...perator x ...' == Line 181 has weird spacing: '...bserver x x...' -- The document date (13 July 2020) is 1383 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 ---------------------------------------------------------------------------- == Unused Reference: 'RFC4122' is defined on line 653, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 7484 (Obsoleted by RFC 9224) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DRIP S. Card, Ed. 3 Internet-Draft A. Wiethuechter 4 Intended status: Informational AX Enterprize 5 Expires: 14 January 2021 R. Moskowitz 6 HTT Consulting 7 S. Zhao 8 Tencent 9 A. Gurtov 10 Linköping University 11 13 July 2020 13 Drone Remote Identification Protocol (DRIP) Architecture 14 draft-ietf-drip-arch-03 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 14 January 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 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 5 58 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 5 59 2.2. Additional Definitions . . . . . . . . . . . . . . . . . 6 60 3. Entities and their Interfaces . . . . . . . . . . . . . . . . 6 61 3.1. Private Information Registry . . . . . . . . . . . . . . 6 62 3.1.1. Background . . . . . . . . . . . . . . . . . . . . . 6 63 3.1.2. Proposed Approach . . . . . . . . . . . . . . . . . . 6 64 3.2. Public Information Registry . . . . . . . . . . . . . . . 7 65 3.2.1. Background . . . . . . . . . . . . . . . . . . . . . 7 66 3.2.2. Proposed Approach . . . . . . . . . . . . . . . . . . 7 67 3.3. CS-RID concept . . . . . . . . . . . . . . . . . . . . . 7 68 3.3.1. Proposed optional CS-RID SDSP . . . . . . . . . . . . 8 69 3.3.2. Proposed optional CS-RID Finder . . . . . . . . . . . 8 70 4. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 8 72 4.2. Proposed Approach . . . . . . . . . . . . . . . . . . . . 9 73 5. DRIP Transactions enabling Trustworthy UAS RID . . . . . . . 10 74 6. Privacy for Broadcast PII . . . . . . . . . . . . . . . . . . 10 75 7. Architectural implications of EASA requirements . . . . . . . 11 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 80 10.2. Informative References . . . . . . . . . . . . . . . . . 12 81 Appendix A. Overview of Unmanned Aircraft Systems (UAS) Traffic 82 Management (UTM) . . . . . . . . . . . . . . . . . . . . 15 83 A.1. Operation Concept . . . . . . . . . . . . . . . . . . . . 16 84 A.2. UAS Service Supplier (USS) . . . . . . . . . . . . . . . 16 85 A.3. UTM Use Cases for UAS Operations . . . . . . . . . . . . 17 86 A.4. Overview UAS Remote ID (RID) and RID Standardization . . 17 87 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 90 1. Introduction 92 This document describes a natural Internet based architecture for 93 Unmanned Aircraft System Remote Identification and tracking (UAS 94 RID), conforming to proposed regulations and external technical 95 standards, satisfying the requirements listed in the companion 96 requirements document [drip-requirements]. The requirements document 97 also provides an extended introduction to the problem space, use 98 cases, etc. Only a brief summary of that introduction will be 99 restated here as context, with reference to the general architecture 100 shown in Figure 1 below. 102 General x x Public 103 Public xxxxx xxxxx Safety 104 Observer x x Observer 105 x x 106 x x ---------+ +---------- x x 107 x x | | x x 108 | | 109 + + 110 xxxxxxxxxx 111 x x 112 +----------+x Internet x+------------+ 113 | x x | 114 UA1 x | xxxxxxxxxx | x UA2 115 Pilot xxxxx + + + xxxxx Pilot 116 Operator x | | | x Operator 117 x | | | x 118 x x | | | x x 119 x x | | | x x 120 | | | 121 +----------+ | | | +----------+ 122 | |------+ | +-------| | 123 | Public | | | Private | 124 | Registry | +-----+ | Registry | 125 | | | DNS | | | 126 +----------+ +-----+ +----------+ 128 Figure 1 130 Many considerations (especially safety) dictate that UAS be remotely 131 identifiable. Civil Aviation Authorities (CAAs) worldwide are 132 mandating Unmanned Aircraft Systems (UAS) Remote Identification 133 (RID). CAAs currently (2020) promulgate performance-based 134 regulations that do not specify techniques, but rather cite industry 135 consensus technical standards as acceptable means of compliance. 137 ASTM International, Technical Committee F38 (UAS), Subcommittee 138 F38.02 (Aircraft Operations), Work Item WK65041, developed the new 139 ASTM [F3411-19] Standard Specification for Remote ID and Tracking. 140 It defines one set of RID information and two means of communicating 141 it. If a UAS uses both communication methods, generally the same 142 information must provided via both means. While hybrids are possible 143 (and indeed one is proposed as an optional DRIP service), the two 144 basic methods are defined as follows: 146 Network RID defines a RID data dictionary and data flow: from a 147 UAS via unspecified means to a Network Remote ID Service Provider 148 (Net-RID SP); from the Net-RID SP to an integrated, or over the 149 Internet to a separate, Network Remote ID Display Provider (Net- 150 RID DP); from the Net-RID DP via the Internet to Network Remote ID 151 clients in response to their queries (expected typically, but not 152 specified exclusively, to be web based) specifying airspace 153 volumes of interest. Network RID depends upon connectivity, in 154 several segments, via the Internet, from the UAS to the Observer. 156 Broadcast RID defines a set of RID messages and how the UA 157 transmits them locally directly one-way, over Bluetooth or Wi-Fi. 158 Broadcast RID should need Internet (or other Wide Area Network) 159 connectivity only for UAS registry information lookup using the 160 locally directly received UAS ID as a key. Broadcast RID should 161 be functionally usable in situations with no Internet 162 connectivity. 164 The less constrained but more complex case of Network RID is 165 illustrated in Figure 2 below. 167 x x UA 168 xxxxx ******************** 169 | * ------*---+------------+ 170 | * / * | NET_Rid_SP | 171 | * ------------/ +---*--+------------+ 172 | RF */ | * 173 | * INTERNET | * +------------+ 174 | /* +---*--| NET_Rid_DP | 175 | / * +----*--+------------+ 176 + / * | * 177 x / ****************|*** x 178 xxxxx | xxxxx 179 x +------- x 180 x x 181 x x Operator (GCS) Observer x x 182 x x x x 184 Figure 2 186 Via the direct Radio Frequency (RF) link between the UA and GCS: 187 Command and Control (C2) flows from the GCS to the UA; for all but 188 the simplest hobby aircraft, position and status flow from the UA to 189 the GCS. Via the Internet, through three distinct segments, Network 190 RID information flows from the UAS (comprising the UA and its GCS) to 191 the Observer. 193 Other Standards Development Organizations (SDOs, e.g., 3GPP, 194 Appendix A.4) may define their own communication methods for both 195 Network and Broadcast RID. The CAAs expect any additional methods to 196 maintain consistency of the RID messages. 198 DRIP will enable leveraging existing Internet resources (standard 199 protocols, services, infrastructure and business models) to meet UAS 200 RID and closely related needs. DRIP will specify how to apply IETF 201 standards, complementing [F3411-19] and other external standards, to 202 satisfy UAS RID requirements. DRIP will update existing and develop 203 new protocol standards as needed to accomplish the foregoing. 205 This document will outline the UAS RID architecture into which DRIP 206 must fit, and an architecture for DRIP itself. This includes 207 presenting the gaps between the CAAs' Concepts of Operations and 208 [F3411-19] as it relates to use of Internet technologies and UA 209 direct RF communications. Issues include, but are not limited to: 211 * Trustworthy Remote ID and trust in RID messages 213 * Privacy in RID messages (PII protection) 215 * UA -> Ground communications including Broadcast RID 217 * Broadcast RID 'harvesting' and secure forwarding into the UTM 219 * Secure UAS -> Net-RID SP communications 221 * Secure Observer -> Pilot communications 223 2. Terms and Definitions 225 2.1. Requirements Terminology 227 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 228 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 229 "OPTIONAL" in this document are to be interpreted as described in BCP 230 14 [RFC2119] [RFC8174] when, and only when, they appear in all 231 capitals, as shown here. 233 2.2. Additional Definitions 235 This document uses terms defined in [drip-requirements]. 237 3. Entities and their Interfaces 239 Any DRIP solutions for UAS RID must fit into the UTM (or U-space) 240 system. This implies interaction with entities including UA, GCS, 241 USS, Net-RID SP, Net-RID DP, Observers, Operators, Pilots In Command, 242 Remote Pilots, possibly SDSP, etc. The only additional entities 243 introduced in this document are registries, required but not 244 specified by the regulations and [RFC7401], and optionally CS-RID 245 SDSP and Finder nodes. 247 UAS registries hold both public and private UAS information. The 248 public information is primarily pointers to the repositories of, and 249 keys for looking up, the private information. Given these different 250 uses, and to improve scalability, security and simplicity of 251 administration, the public and private information can be stored in 252 different registries, indeed different types of registry. 254 3.1. Private Information Registry 256 3.1.1. Background 258 The private information required for UAS RID is similar to that 259 required for Internet domain name registration. Thus a DRIP RID 260 solution can leverage existing Internet resources: registration 261 protocols, infrastructure and business models, by fitting into an ID 262 structure compatible with DNS names. This implies some sort of 263 hierarchy, for scalability, and management of this hierarchy. It is 264 expected that the private registry function will be provided by the 265 same organizations that run USS, and likely integrated with USS. 267 3.1.2. Proposed Approach 269 A DRIP UAS ID MUST be amenable to handling as an Internet domain name 270 (at an arbitrary level in the hierarchy), MUST be registered in at 271 least a pseudo-domain (e.g. .ip6.arpa for reverse lookup), and MAY be 272 registered as a sub-domain (for forward lookup). 274 A DRIP private information registry MUST support essential Internet 275 domain name registry operations (e.g. add, delete, update, query) 276 using interoperable open standard protocols. It SHOULD support the 277 Extensible Provisioning Protocol (EPP) and the Registry Data Access 278 Protocol (RDAP) with access controls. It MAY use XACML to specify 279 those access controls. It MUST be listed in a DNS: that DNS MAY be 280 private; but absent any compelling reasons for use of private DNS, 281 SHOULD be the definitive public Internet DNS hierarchy. The DRIP 282 private information registry in which a given UAS is registered MUST 283 be locatable, starting from the UAS ID, using the methods specified 284 in [RFC7484]. 286 3.2. Public Information Registry 288 3.2.1. Background 290 The public information required to be made available by UAS RID is 291 transmitted as cleartext to local observers in Broadcast RID and is 292 served to a client by a Net-RID DP in Network RID. Therefore, while 293 IETF can offer e.g. [RFC6280] as one way to implement Network RID, 294 the only public information required to support essential DRIP 295 functions for UAS RID is that required to look up Internet domain 296 hosts, services, etc. 298 3.2.2. Proposed Approach 300 A DRIP public information registry MUST be a standard DNS server, in 301 the definitive public Internet DNS hierarchy. It MUST support NS, 302 MX, SRV, TXT, AAAA, PTR, CNAME and HIP RR (the last per [RFC8005]) 303 types. 305 3.3. CS-RID concept 307 ASTM anticipated that regulators would require both Broadcast RID and 308 Network RID for large UAS, but allow RID requirements for small UAS 309 to be satisfied with the operator's choice of either Broadcast RID or 310 Network RID. The EASA initially specified Broadcast RID for UAS of 311 essentially all UAS and is now considering Network RID also. The FAA 312 NPRM requires both for Standard RID and specifies Broadcast RID only 313 for Limited RID. One obvious opportunity is to enhance the 314 architecture with gateways from Broadcast RID to Network RID. This 315 provides the best of both and gives regulators and operators 316 flexibility. Such gateways could be pre-positioned (e.g. around 317 airports and other sensitive areas) and/or crowdsourced (as nothing 318 more than a smartphone with a suitable app is needed). Gateways can 319 also perform multilateration to provide independent measurements of 320 UA position, which is otherwise entirely operator self-reported in 321 UAS RID and UTM. CS-RID would be an option, beyond baseline DRIP 322 functionality; if implemented, it adds two more entity types. 324 3.3.1. Proposed optional CS-RID SDSP 326 A CS-RID SDSP MUST appear (i.e. present the same interface) to a Net- 327 RID SP as a Net-RID DP. A CS-RID SDSP MUST appear to a Net-RID DP as 328 a Net-RID SP. A CS-RID SDSP MUST NOT present a standard GCS-facing 329 interface as if it were a Net-RID SP. A CS-RID SDSP MUST NOT present 330 a standard client-facing interface as if it were a Net-RID DP. A CS- 331 RID SDSP MUST present a TBD interface to a CS-RID Finder; this 332 interface SHOULD be based upon but readily distinguishable from that 333 between a GCS and a Net-RID SP. 335 3.3.2. Proposed optional CS-RID Finder 337 A CS-RID Finder MUST present a TBD interface to a CS-RID SDSP; this 338 interface SHOULD be based upon but readily distinguishable from that 339 between a GCS and a Net-RID SP. A CS-RID Finder must implement, 340 integrate, or accept outputs from, a Broadcast RID receiver. A CS- 341 RID Finder MUST NOT interface directly with a GCS, Net-RID SP, Net- 342 RID DP or Network RID client. 344 4. Identifiers 346 4.1. Background 348 A DRIP UA ID needs to be "Trustworthy". This means that within the 349 framework of the RID messages, an observer can establish that the RID 350 used does uniquely belong to the UA. That the only way for any other 351 UA to assert this RID would be to steal something from within the UA. 352 The RID is self-generated by the UAS (either UA or GCS) and 353 registered with the USS. 355 Within the limitations of Broadcast RID, this is extremely 356 challenging as: 358 * An RID can at most be 20 characters 360 * The ASTM Basic RID message (the message containing the RID) is 25 361 characters; only 3 characters are currently unused 363 * The ASTM Authentication message, with some changes from [F3411-19] 364 can carry 224 bytes of payload. 366 Standard approaches like X.509 and PKI will not fit these 367 constraints, even using the new EdDSA algorithm. An example of a 368 technology that will fit within these limitations is an enhancement 369 of the Host Identity Tag (HIT) of HIPv2 [RFC7401] introducing 370 hierarchy as defined in HHIT [hierarchical-hit]; using Hierarchical 371 HITs for UAS RID is outlined in HHIT based UAS RID [drip-uas-rid]. 373 As PKI with X.509 is being used in other systems with which UAS RID 374 must interoperate (e.g. the UTM Discovery and Synchronization Service 375 and the UTM InterUSS protocol) mappings between the more flexible but 376 larger X.509 certificates and the HHIT based structures must be 377 devised. 379 By using the EdDSA HHIT suite, self-assertions of the RID can be done 380 in as little as 84 bytes. Third-party assertions can be done in 200 381 bytes. An observer would need Internet access to validate a self- 382 assertion claim. A third-party assertion can be validated via a 383 small credential cache in a disconnected environment. This third- 384 party assertion is possible when the third-party also uses HHITs for 385 its identity and the UA has the public key for that HHIT. 387 4.2. Proposed Approach 389 A DRIP UAS ID MUST be a HHIT. It SHOULD be self-generated by the UAS 390 (either UA or GCS) and MUST be registered with the Private 391 Information Registry identified in its hierarchy fields. Each UAS ID 392 HHIT MUST NOT be used more than once, with one exception as follows. 394 Each UA MAY be assigned, by its manufacturer, a single HI and derived 395 HHIT encoded as a hardware serial number per [CTA2063A]. Such a 396 static HHIT SHOULD be used only to bind one-time use UAS IDs (other 397 HHITs) to the unique UA. Depending upon implementation, this may 398 leave a HI private key in the possession of the manufacturer (see 399 Security Considerations). 401 Each UA equipped for Broadcast RID MUST be provisioned not only with 402 its HHIT but also with the HI public key from which the HHIT was 403 derived and the corresponding private key, to enable message 404 signature. Each UAS equipped for Network RID MUST be provisioned 405 likewise; the private key SHOULD reside only in the ultimate source 406 of Network RID messages (i.e. on the UA itself if the GCS is merely 407 relaying rather than sourcing Network RID messages). Each observer 408 device MUST be provisioned with public keys of the UAS RID root 409 registries and MAY be provisioned with public keys or certificates 410 for subordinate registries. 412 Operators and Private Information Registries MUST possess and other 413 UTM entities MAY possess UAS ID style HHITs. When present, such 414 HHITs SHOULD be used with HIP to strongly mutually authenticate and 415 optionally encrypt communications. 417 5. DRIP Transactions enabling Trustworthy UAS RID 419 Each Operator MUST generate a Host Identity of the Operator (HIo) and 420 derived Hierarchical HIT of the Operator (HHITo), register them with 421 a Private Information Registry along with whatever Operator data 422 (inc. PII) is required by the cognizant CAA and the registry, and 423 obtain a Certificate from the Registry on the Operator (Cro) signed 424 with the Host Identity of the Registry private key (HIr(priv)) 425 proving such registration. 427 To add an UA, an Operator MUST generate a Host Identity of the 428 Aircraft (HIa) and derived Hierarchical HIT of the Aircraft (HHITa), 429 create a Certificate from the Operator on the Aircraft (Coa) signed 430 with the Host Identity of the Operator private key (HIo(priv)) to 431 associate the UA with its Operator, register them with a Private 432 Information Registry along with whatever UAS data is required by the 433 cognizant CAA and the registry, obtain a Certificate from the 434 Registry on the Operator and Aircraft ("Croa") signed with the 435 HIr(priv) proving such registration, and obtain a Certificate from 436 the Registry on the Aircraft (Cra) signed with HIr(priv) proving UA 437 registration in that specific registry while preserving Operator 438 privacy. The operator then MUST provision the UA with HIa, 439 HIa(priv), HHITa and Cra. 441 UA engaging in Broadcast RID MUST use HIa(priv) to sign Auth Messages 442 and MUST periodically broadcast Cra. UAS engaging in Network RID MUST 443 use HIa(priv) to sign Auth Messages. Observers MUST use HIa from 444 received Cra to verify received Broadcast RID Auth messages. 445 Observers without Internet connectivity MAY use Cra to identify the 446 trust class of the UAS based on known registry vetting. Observers 447 with Internet connectivity MAY use HHITa to perform lookups in the 448 Public Information Registry and MAY then query the Private 449 Information Registry, which MUST enforce AAA policy on Operator PII 450 and other sensitive information. 452 6. Privacy for Broadcast PII 454 Broadcast RID messages may contain PII. This may be information 455 about the UA such as its destination or Operator information such as 456 GCS location. There is no absolute "right" in hiding PII, as there 457 will be times (e.g., disasters) and places (buffer zones around 458 airports and sensitive facilities) where policy may mandate all 459 information be sent as cleartext. Otherwise, the modern general 460 position (consistent with, e.g., the EU General Data Protection 461 Regulation) is to hide PII unless otherwise instructed. While some 462 have argued that a system like that of automobile registration plates 463 should suffice for UAS, others have argued persuasively that each 464 generation of new identifiers should take advantage of advancing 465 technology to protect privacy, to the extent compatible with the 466 transparency needed to protect safety. 468 A viable architecture for PII protection would be symmetric 469 encryption of the PII using a key known to the UAS and a USS service. 470 An authorized Observer may send the encrypted PII along with the 471 Remote ID (to their UAS display service) to get the plaintext. The 472 authorized Observer may send the Remote ID (to their UAS display 473 service) and receive the key to directly decrypt all PII content from 474 the UA. 476 PII is protected unless the UAS is informed otherwise. This may come 477 from operational instructions to even permit flying in a space/time. 478 It may be special instructions at the start or during an operation. 479 PII protection should not be used if the UAS loses connectivity to 480 the USS. The USS always has the option to abort the operation if PII 481 protection is disallowed. 483 An authorized Observer may instruct a UAS via the USS that conditions 484 have changed mandating no PII protection or land the UA. 486 7. Architectural implications of EASA requirements 488 According to EASA, in EU broadcasting drone identification will be 489 mandatory from July 2020. Following info should be sent in cleartext 490 over Wifi or Bluetooth. In real time during the whole duration of 491 the flight, the direct periodic broadcast from the UA using an open 492 and documented transmission protocol, of the following data, in a way 493 that they can be received directly by existing mobile devices within 494 the broadcasting range: 496 i) the UAS operator registration number; 498 ii) the unique physical serial number of the UA compliant with 499 standard ANSI/CTA2063; 501 iii) the geographical position of the UA and its height above the 502 surface or take-off point; 504 iv) the route course measured clockwise from true north and ground 505 speed of the UA; and 507 v) the geographical position of the remote pilot or, if not 508 available, the take-off point; 510 The architecture proposed in this document partially satisfies EASA 511 requirements. In particular, i) is included to Operator-ID Message 512 as optional. ii) cannot be directly supported due to its heavy 513 privacy implications. A cryptographic identifier that needs to be 514 resolved is proposed instead. iii) and iv) are included into 515 Location/Vector Message. v) is included into a System Message 516 (optional). 518 8. IANA Considerations 520 This document does not make any request to IANA. 522 9. Security Considerations 524 DRIP is all about safety and security, so content pertaining to such 525 is not limited to this section. The security provided by asymmetric 526 cryptographic techniques depends upon protection of the private keys. 527 A manufacturer that embeds a private key in an UA may have retained a 528 copy. A manufacturer whose UA are configured by a closed source 529 application on the GCS which communicates over the Internet with the 530 factory may be sending a copy of a UA or GCS self-generated key back 531 to the factory. Compromise of a registry private key could do 532 widespread harm. Key revocation procedures are as yet to be 533 determined. These risks are in addition to those involving Operator 534 key management practices. 536 10. References 538 10.1. Normative References 540 [drip-requirements] 541 Card, S., Wiethuechter, A., Moskowitz, R., and A. Gurtov, 542 "Drone Remote Identification Protocol (DRIP) 543 Requirements", Work in Progress, Internet-Draft, draft- 544 ietf-drip-reqs-01, 25 May 2020, 545 . 547 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 548 Requirement Levels", BCP 14, RFC 2119, 549 DOI 10.17487/RFC2119, March 1997, 550 . 552 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 553 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 554 May 2017, . 556 10.2. Informative References 558 [ATIS-I-0000074] 559 ATIS, "Report on UAS in 3GPP", 560 . 563 [crowd-sourced-rid] 564 Moskowitz, R., Card, S., Wiethuechter, A., Zhao, S., and 565 H. Birkholz, "Crowd Sourced Remote ID", Work in Progress, 566 Internet-Draft, draft-moskowitz-drip-crowd-sourced-rid-04, 567 20 May 2020, . 570 [CTA2063A] ANSI, "Small Unmanned Aerial Systems Serial Numbers", 571 September 2019. 573 [Delegated] 574 European Union Aviation Safety Agency (EASA), "EU 575 Commission Delegated Regulation 2019/945 of 12 March 2019 576 on unmanned aircraft systems and on third-country 577 operators of unmanned aircraft systems", March 2019. 579 [drip-auth] 580 Wiethuechter, A., Card, S., and R. Moskowitz, "DRIP 581 Authentication Formats", Work in Progress, Internet-Draft, 582 draft-wiethuechter-drip-auth-01, 10 July 2020, 583 . 586 [drip-identity-claims] 587 Wiethuechter, A., Card, S., and R. Moskowitz, "DRIP 588 Identity Claims", Work in Progress, Internet-Draft, draft- 589 wiethuechter-drip-identity-claims-00, 23 March 2020, 590 . 593 [drip-secure-nrid-c2] 594 Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov, 595 "Secure UAS Network RID and C2 Transport", Work in 596 Progress, Internet-Draft, draft-moskowitz-drip-secure- 597 nrid-c2-00, 6 April 2020, . 600 [drip-uas-rid] 601 Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov, 602 "UAS Remote ID", Work in Progress, Internet-Draft, draft- 603 moskowitz-drip-uas-rid-02, 28 May 2020, 604 . 607 [F3411-19] ASTM, "Standard Specification for Remote ID and Tracking", 608 December 2019. 610 [hhit-registries] 611 Moskowitz, R., Card, S., and A. Wiethuechter, 612 "Hierarchical HIT Registries", Work in Progress, Internet- 613 Draft, draft-moskowitz-hip-hhit-registries-02, 9 March 614 2020, . 617 [hierarchical-hit] 618 Moskowitz, R., Card, S., and A. Wiethuechter, 619 "Hierarchical HITs for HIPv2", Work in Progress, Internet- 620 Draft, draft-moskowitz-hip-hierarchical-hit-05, 13 May 621 2020, . 624 [Implementing] 625 European Union Aviation Safety Agency (EASA), "EU 626 Commission Implementing Regulation 2019/947 of 24 May 2019 627 on the rules and procedures for the operation of unmanned 628 aircraft", May 2019. 630 [LAANC] United States Federal Aviation Administration (FAA), "Low 631 Altitude Authorization and Notification Capability", 632 . 635 [new-hip-crypto] 636 Moskowitz, R., Card, S., and A. Wiethuechter, "New 637 Cryptographic Algorithms for HIP", Work in Progress, 638 Internet-Draft, draft-moskowitz-hip-new-crypto-04, 23 639 January 2020, . 642 [new-orchid] 643 Moskowitz, R., Card, S., and A. Wiethuechter, "Using 644 cSHAKE in ORCHIDs", Work in Progress, Internet-Draft, 645 draft-moskowitz-orchid-cshake-01, 21 May 2020, 646 . 649 [NPRM] United States Federal Aviation Administration (FAA), 650 "Notice of Proposed Rule Making on Remote Identification 651 of Unmanned Aircraft Systems", December 2019. 653 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 654 Unique IDentifier (UUID) URN Namespace", RFC 4122, 655 DOI 10.17487/RFC4122, July 2005, 656 . 658 [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., 659 Tschofenig, H., and H. Schulzrinne, "An Architecture for 660 Location and Location Privacy in Internet Applications", 661 BCP 160, RFC 6280, DOI 10.17487/RFC6280, July 2011, 662 . 664 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 665 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 666 RFC 7401, DOI 10.17487/RFC7401, April 2015, 667 . 669 [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data 670 (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March 671 2015, . 673 [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name 674 System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, 675 October 2016, . 677 [TS-22.825] 678 3GPP, "UAS RID requirement study", 679 . 682 [TS-36.777] 683 3GPP, "UAV service in the LTE network", 684 . 687 [U-Space] European Organization for the Safety of Air Navigation 688 (EUROCONTROL), "U-space Concept of Operations", October 689 2019, 690 . 693 Appendix A. Overview of Unmanned Aircraft Systems (UAS) Traffic 694 Management (UTM) 696 A.1. Operation Concept 698 The National Aeronautics and Space Administration (NASA) and FAAs' 699 effort of integrating UAS's operation into the national airspace 700 system (NAS) leads to the development of the concept of UTM and the 701 ecosystem around it. The UTM concept was initially presented in 702 2013. The eventual development and implementation are conducted by 703 the UTM research transition team which is the joint workforce by FAA 704 and NASA. World efforts took place afterward. The Single European 705 Sky ATM Research (SESAR) started the CORUS project to research its 706 UTM counterpart concept, namely [U-Space]. This effort is led by the 707 European Organization for the Safety of Air Navigation (Eurocontrol). 709 Both NASA and SESAR have published the UTM concept of operations to 710 guide the development of their future air traffic management (ATM) 711 system and make sure safe and efficient integrations of manned and 712 unmanned aircraft into the national airspace. 714 The UTM composes of UAS operation infrastructure, procedures and 715 local regulation compliance policies to guarantee UAS's safe 716 integration and operation. The main functionality of a UTM includes, 717 but is not limited to, providing means of communication between UAS 718 operators and service providers and a platform to facilitate 719 communication among UAS service providers. 721 A.2. UAS Service Supplier (USS) 723 A USS plays an important role to fulfill the key performance 724 indicators (KPIs) that a UTM has to offer. Such Entity acts as a 725 proxy between UAS operators and UTM service providers. It provides 726 services like real-time UAS traffic monitor and planning, 727 aeronautical data archiving, airspace and violation control, 728 interacting with other third-party control entities, etc. A USS can 729 coexist with other USS(s) to build a large service coverage map which 730 can load-balance, relay and share UAS traffic information. 732 The FAA works with UAS industry shareholders and promotes the Low 733 Altitude Authorization and Notification Capability [LAANC] program 734 which is the first implementation to realize UTM's functionality. 735 The LAANC program can automate the UAS's fly plan application and 736 approval process for airspace authorization in real-time by checking 737 against multiple aeronautical databases such as airspace 738 classification and fly rules associated with it, FAA UAS facility 739 map, special use airspace, Notice to airman (NOTAM) and Temporary 740 flight rule (TFR). 742 A.3. UTM Use Cases for UAS Operations 744 This section illustrates a couple of use case scenarios where UAS 745 participation in UTM has significant safety improvement. 747 1. For a UAS participating in UTM and takeoff or land in a 748 controlled airspace (e.g., Class Bravo, Charlie, Delta and Echo 749 in United States), the USS where UAS is currently communicating 750 with is responsible for UAS's registration, authenticating the 751 UAS's fly plan by checking against designated UAS fly map 752 database, obtaining the air traffic control (ATC) authorization 753 and monitor the UAS fly path in order to maintain safe boundary 754 and follow the pre-authorized route. 756 2. For a UAS participating in UTM and take off or land in an 757 uncontrolled airspace (ex. Class Golf in the United States), 758 pre-fly authorization must be obtained from a USS when operating 759 beyond-visual-of-sight (BVLOS) operation. The USS either accepts 760 or rejects received intended fly plan from the UAS. Accepted UAS 761 operation may share its current fly data such as GPS position and 762 altitude to USS. The USS may keep the UAS flight status near 763 real-time and may keep it as a record for overall airspace air 764 traffic monitor. 766 A.4. Overview UAS Remote ID (RID) and RID Standardization 768 A RID is an application enabler for a UAS to be identified by a UTM/ 769 USS or third parties entities such as law enforcement. Many safety 770 and other considerations dictate that UAS be remotely identifiable. 771 CAAs worldwide are mandating UAS RID. The European Union Aviation 772 Safety Agency (EASA) has published [Delegated] and [Implementing] 773 Regulations. The FAA has published a Notice of Proposed Rule Making 774 [NPRM]. CAAs currently promulgate performance-based regulations that 775 do not specify techniques, but rather cite industry consensus 776 technical standards as acceptable means of compliance. 778 3GPP provides UA service in the LTE network since release 15 in 779 published technical specification [TS-36.777]. Start from its 780 release 16, it completed the UAS RID requirement study in [TS-22.825] 781 and proposed use cases in the mobile network and the services that 782 can be offered based on RID and ongoing release 17 specification 783 works on enhanced UAS service requirement and provides the protocol 784 and application architecture support which is applicable for both 4G 785 and 5G network. ATIS's recent report [ATIS-I-0000074] proposes 786 architecture approaches for the 3GPP network to support UAS and one 787 of which is put RID in higher 3GPP protocol stack such as using ASTM 788 remote ID [F3411-19]. 790 Acknowledgments 792 The work of the FAA's UAS Identification and Tracking (UAS ID) 793 Aviation Rulemaking Committee (ARC) is the foundation of later ASTM 794 and proposed IETF DRIP WG efforts. The work of ASTM F38.02 in 795 balancing the interests of diverse stakeholders is essential to the 796 necessary rapid and widespread deployment of UAS RID. IETF 797 volunteers who have contributed to this draft include Amelia 798 Andersdotter and Mohamed Boucadair. 800 Authors' Addresses 802 Stuart W. Card (editor) 803 AX Enterprize 804 4947 Commercial Drive 805 Yorkville, NY 13495 806 United States of America 808 Email: stu.card@axenterprize.com 810 Adam Wiethuechter 811 AX Enterprize 812 4947 Commercial Drive 813 Yorkville, NY 13495 814 United States of America 816 Email: adam.wiethuechter@axenterprize.com 818 Robert Moskowitz 819 HTT Consulting 820 Oak Park, MI 48237 821 United States of America 823 Email: rgm@labs.htt-consult.com 825 Shuai Zhao 826 Tencent 827 CA 828 United States of America 830 Email: shuaiizhao@tencent.com 831 Andrei Gurtov 832 Linköping University 833 IDA 834 SE-58183 Linköping 835 Sweden 837 Email: gurtov@acm.org