idnits 2.17.1 draft-card-drip-arch-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 691 has weird spacing: '...mulgate perfo...' -- The document date (21 April 2020) is 1459 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7484 (Obsoleted by RFC 9224) == Outdated reference: A later version (-05) exists of draft-moskowitz-hip-hierarchical-hit-04 == Outdated reference: A later version (-10) exists of draft-moskowitz-hip-new-crypto-04 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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: 23 October 2020 R. Moskowitz 6 HTT Consulting 7 S. Zhao 8 Tencent 9 21 April 2020 11 Drone Remote Identification Protocol (DRIP) Architecture 12 draft-card-drip-arch-02 14 Abstract 16 This document defines an architecture for Drone Remote Identification 17 Protocol (DRIP) Working Group protocols and services to support 18 Unmanned Aircraft System Remote Identification (UAS RID) and RID- 19 related communications, including its building blocks and their 20 interfaces, all to be standardized. 22 CAVEAT LECTOR: This draft version is undergoing substantial 23 restructuring and is submitted to the DRIP WG only to spark 24 discussion on architecture and to be adopted as a placeholder if 25 there is consensus that there should be an architecture document 26 (however far from any future consensus on that architecture this 27 draft may be). 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 23 October 2020. 46 Copyright Notice 48 Copyright (c) 2020 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Simplified BSD License text 57 as described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. UAS RID Uses . . . . . . . . . . . . . . . . . . . . . . 4 64 1.2. UAS RID Design Considerations . . . . . . . . . . . . . . 5 65 1.3. DRIP Goals . . . . . . . . . . . . . . . . . . . . . . . 5 66 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 5 67 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 6 68 2.2. Additional Definitions . . . . . . . . . . . . . . . . . 6 69 3. Entities and their Interfaces . . . . . . . . . . . . . . . . 7 70 3.1. Private Information Registry . . . . . . . . . . . . . . 7 71 3.1.1. Background . . . . . . . . . . . . . . . . . . . . . 7 72 3.1.2. Proposed Approach . . . . . . . . . . . . . . . . . . 7 73 3.2. Public Information Registry . . . . . . . . . . . . . . . 8 74 3.2.1. Background . . . . . . . . . . . . . . . . . . . . . 8 75 3.2.2. Proposed Approach . . . . . . . . . . . . . . . . . . 8 76 3.3. CS-RID concept . . . . . . . . . . . . . . . . . . . . . 8 77 3.3.1. Proposed optional CS-RID SDSP . . . . . . . . . . . . 8 78 3.3.2. Proposed optional CS-RID Finder . . . . . . . . . . . 9 79 4. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 9 81 4.2. Proposed Approach . . . . . . . . . . . . . . . . . . . . 10 82 5. Proposed Transactions . . . . . . . . . . . . . . . . . . . . 10 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 85 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 88 9.2. Informative References . . . . . . . . . . . . . . . . . 12 89 Appendix A. Overview of Unmanned Aircraft Systems (UAS) Traffic 90 Management (UTM) . . . . . . . . . . . . . . . . . . . . 14 91 A.1. Operation Concept . . . . . . . . . . . . . . . . . . . . 14 92 A.2. UAS service supplier (USS) . . . . . . . . . . . . . . . 14 93 A.3. UTM Use cases for UAS operation . . . . . . . . . . . . . 15 94 A.4. Overview UAS Remote ID (RID) and RID Standardization . . 15 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 97 1. Introduction 99 Many safety and other considerations dictate that Unmanned Aircraft 100 (UA) be remotely identifiable. Civil Aviation Authorities (CAAs) 101 worldwide are mandating Unmanned Aircraft Systems (UAS) Remote 102 Identification (RID). The European Union Aviation Safety Agency 103 (EASA) has published [Delegated] and [Implementing] Regulations. The 104 United States Federal Aviation Administration (FAA) has published a 105 Notice of Proposed Rule Making [NPRM]. CAAs currently promulgate 106 performance-based regulations that do not specify techniques, but 107 rather cite industry consensus technical standards as acceptable 108 means of compliance. 110 ASTM International, Technical Committee F38 (UAS), Subcommittee 111 F38.02 (Aircraft Operations), Work Item WK65041, developed the new 112 ASTM [F3411-19] Standard Specification for Remote ID and Tracking. 113 It defines 1 set of RID information and 2 means of communicating it 114 (if a UAS uses both communication methods, the CAAs are expected to 115 mandate that the RID information content will be identical over both 116 methods). 118 Network RID defines a RID data dictionary and data flow: from a 119 UAS via unspecified means to a Network Remote ID Service Provider 120 (Net-RID SP); from the Net-RID SP to an integrated, or over the 121 Internet to a separate, Network Remote ID Display Provider (Net- 122 RID DP); from the Net-RID DP via the Internet to Network Remote ID 123 clients in response to their queries (expected typically, but not 124 specified exclusively, to be web based) specifying airspace 125 volumes of interest. Network RID depends upon connectivity, in 126 several segments, including the Internet, from the UAS to the 127 Observer. 129 Broadcast RID defines a set of RID messages and how the UA 130 transmits them locally directly one-way, over Bluetooth or Wi-Fi. 131 Broadcast RID should need Internet (or other Wide Area Network) 132 connectivity only for UAS registry information lookup using the 133 locally directly received UAS ID as a key. Broadcast RID should 134 be functionally usable in situations with no Internet 135 connectivity. 137 Other SDOs (e.g. 3GPP, Appendix A.4) may define their own 138 communication methods for both Network and Broadcast RID. The CAAs 139 expect any additional methods to maintain consistency of the RID 140 messages. 142 [F3411-19] specifies 3 UAS ID Types. 144 1. 1: a static, manufacturer assigned, hardware serial number per 145 ANSI/CTA-2063-A "Small Unmanned Aerial System Serial Numbers" 146 [CTA2063A]. 148 2. 2: a CAA assigned (presumably static) ID. 150 3. 3: a UAS Traffic Management (UTM) system assigned UUID v4 151 [RFC4122], which can but need not be dynamic. 153 The EU allows only Type 1. The US allows Types 1 and 3, but requires 154 Type 3 IDs (if used) each to be used only once (for a single UAS 155 flight, which in the context of UTM is called an "operation"). 156 [F3411-19] Broadcast RID transmits all information in the clear as 157 plaintext, so Types 1 and 2 static IDs enable trivial correlation of 158 patterns of use, unacceptable in many applications (e.g. package 159 delivery routes of competitors). 161 1.1. UAS RID Uses 163 An ID is not an end in itself; it exists to enable lookups and 164 provision of services complementing mere identification. 166 Minimal specified information must be made available to the public. 167 Access to other data, e.g. UAS operator Personally Identifiable 168 Information (PII), must be limited to strongly authenticated 169 personnel, properly authorized per policy. [F3411-19] specifies only 170 how to get the UAS ID to the observer; how the observer can perform 171 these lookups, and how the registries first can be populated with 172 information, is unspecified. 174 Dynamic establishment of secure communications between the observer 175 and the UAS pilot seems to have been contemplated by the FAA UAS ID 176 and Tracking Aviation Rulemaking Committee (ARC) in their 177 [Recommendations], but it is not addressed in any of the subsequent 178 proposed regulations or technical specifications. 180 Using UAS RID to facilitate related services, such as Detect And 181 Avoid (DAA) and other applications of Vehicle to Vehicle or Vehicle 182 to Infrastructure (V2V, V2I, collectively V2X) communications, is an 183 obvious application. This is explicitly contemplated in the FAA 184 NPRM, but has been omitted from [F3411-19]. DAA has been explicitly 185 declared out of scope in ASTM working group discussions, based on a 186 distinction between RID as a security standard vs DAA as a safety 187 application. 189 1.2. UAS RID Design Considerations 191 The need for near-universal deployment of UAS RID is pressing. This 192 implies the need to support use by observers of already ubiquitous 193 mobile devices (smartphones and tablets). UA onboard RID devices are 194 severely constrained in Cost, Size, Weight and Power ($SWaP). Cost 195 is a significant impediment to the necessary near-universal adoption 196 of UAS send and observer receive RID capabilities. 198 To accommodate the most severely constrained cases, all these 199 conspire to motivate system design decisions, especially for the 200 Broadcast RID data link, which complicate the protocol design 201 problem: one-way links; extremely short packets; and Internet- 202 disconnected operation of UA onboard devices. Internet-disconnected 203 operation of observer devices has been deemed by ASTM F38.02 too 204 infrequent to address, but for some users is important and presents 205 further challenges. Heavyweight security protocols are infeasible, 206 yet trustworthiness of UAS RID information is essential. Under 207 [F3411-19], even the most basic datum, the UAS ID string (typically 208 number) itself can be merely an unsubstantiated claim. 210 1.3. DRIP Goals 212 DRIP will enable leveraging existing Internet resources (standard 213 protocols, services, infrastructure and business models) to meet UAS 214 RID and closely related needs. DRIP will specify how to apply IETF 215 standards, complementing [F3411-19] and other external standards, to 216 satisfy UAS RID requirements. DRIP will update existing and develop 217 new protocol standards as needed to accomplish the foregoing. 219 This document will outline the UAS RID architecture into which DRIP 220 must fit, and an architecture for DRIP itself. This includes 221 presenting the gaps between the CAAs' Concepts of Operations and 222 [F3411-19] as it relates to use of Internet technologies and UA 223 direct RF communications. Issues include, but are not limited to: 225 * Trustworthy Remote ID and trust in RID messages 227 * Privacy in RID messages (PII protection) 229 * UA -> Ground communications including Broadcast RID 231 * Broadcast RID 'harvesting' and secure forwarding into the UTM 233 * Secure UAS -> Net-RID SP communications 235 2. Terms and Definitions 236 2.1. Requirements Terminology 238 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 239 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 240 "OPTIONAL" in this document are to be interpreted as described in BCP 241 14 [RFC2119] [RFC8174] when, and only when, they appear in all 242 capitals, as shown here. 244 2.2. Additional Definitions 246 Most terminology needed in the DRIP context is introduced in the 247 paired Requirements document (currently draft-card-drip-reqs). 249 CS-RID 250 Crowd Sourced Remote Identification. An optional DRIP WG service 251 that gateways Broadcast RID to Network RID, and supports 252 verification of RID position/velocity claims with independent 253 measurements (e.g. by multilateration), via a SDSP. 255 HI 256 Host Identity. The public key portion of an asymmetric key pair 257 from HIP. In this document it is assumed that the HI is based on 258 an EdDSA25519 key pair. This is supported by new crypto defined 259 in [I-D.moskowitz-hip-new-crypto]. 261 HIP 262 Host Identity Protocol. The origin of HI, HIT, and HHIT, required 263 for DRIP. Optional full use of HIP enables additional DRIP 264 functionality. 266 HHIT 267 Hierarchical Host Identity Tag. A HIT with extra information not 268 found in a standard HIT. Defined in 269 [I-D.moskowitz-hip-hierarchical-hit]. 271 HIT 272 Host Identity Tag. A 128 bit handle on the HI. Defined in HIPv2 273 [RFC7401]. 275 3. Entities and their Interfaces 277 Any DRIP WG solutions for UAS RID must fit into the UTM (or U-space) 278 system. This implies interaction with entities including UA, GCS, 279 USS, Net-RID SP, Net-RID DP, Observers, Operators, Pilots In Command, 280 Remote Pilots, possibly SDSP, etc. The only additional entities 281 introduced in this document are registries, required but not 282 specified by the regulations and [RFC7401], and optionally CS-RID 283 SDSP and Finder nodes. The DRIP WG may yet introduce other entities 284 if/as needed. 286 UAS registries hold both public and private UAS information. The 287 public information is primarily pointers to the repositories of, and 288 keys for looking up, the private information. Given these different 289 uses, and to improve scalability, security and simplicity of 290 administration, the public and private information can be stored in 291 different registries, indeed different types of registry. 293 3.1. Private Information Registry 295 3.1.1. Background 297 The private information required for UAS RID is similar to that 298 required for Internet domain name registration. Thus a DRIP RID 299 solution can leverage existing Internet resources: registration 300 protocols, infrastructure and business models, by fitting into an ID 301 structure compatible with DNS names. This implies some sort of 302 hierarchy, for scalability, and management of this hierarchy. It is 303 expected that the private registry function will be provided by the 304 same organizations that run USS, and likely integrated with USS. 306 3.1.2. Proposed Approach 308 A DRIP UAS ID MUST be amenable to handling as an Internet domain name 309 (at an arbitrary level in the hierarchy), MUST be registered in at 310 least a pseudo-domain (e.g. .ip6 for reverse lookup), and MAY be 311 registered as a sub-domain (for forward lookup). 313 A DRIP private information registry MUST support essential Internet 314 domain name registry operations (e.g. add, delete, update, query) 315 using interoperable open standard protocols. It SHOULD support the 316 Extensible Provisioning Protocol (EPP) and the Registry Data Access 317 Protocol (RDAP) with access controls. It MAY use XACML to specify 318 those access controls. It MUST be listed in a DNS: that DNS MAY be 319 private; but absent any compelling reasons for use of private DNS, 320 SHOULD be the definitive public Internet DNS hierarchy. The DRIP 321 private information registry in which a given UAS is registered MUST 322 be locatable, starting from the UAS ID, using the methods specified 323 in [RFC7484]. 325 3.2. Public Information Registry 327 3.2.1. Background 329 The public information required to be made available by UAS RID is 330 transmitted as clear plaintext to local observers in Broadcast RID 331 and is served to a client by a Net-RID DP in Network RID. Therefore, 332 while IETF can offer e.g. [RFC6280] as one way to implement Network 333 RID, the only public information required to support essential DRIP 334 functions for UAS RID is that required to look up Internet domain 335 hosts, services, etc. 337 3.2.2. Proposed Approach 339 A DRIP public information registry MUST be a standard DNS server, in 340 the definitive public Internet DNS hierarchy. It MUST support NS, 341 MX, SRV, TXT, AAAA, PTR, CNAME and HIP RR types. 343 3.3. CS-RID concept 345 ASTM anticipated that regulators would require both Broadcast RID and 346 Network RID for large UAS, but allow RID requirements for small UAS 347 to be satisfied with the operator's choice of either Broadcast RID or 348 Network RID. The EASA initially specified Broadcast RID for UAS of 349 essentially all UAS and is now considering Network RID also. The FAA 350 NPRM requires both for Standard RID and specifies Broadcast RID only 351 for Limited RID. One obvious opportunity is to enhance the 352 architecture with gateways from Broadcast RID to Network RID. This 353 provides the best of both and gives regulators and operators 354 flexibility. Such gateways could be pre-positioned (e.g. around 355 airports and other sensitive areas) and/or crowdsourced (as nothing 356 more than a smartphone with a suitable app is needed). Gateways can 357 also perform multilateration to provide independent measurements of 358 UA position, which is otherwise entirely operator self-reported in 359 UAS RID and UTM. CS-RID would be an option, beyond baseline DRIP 360 functionality; if implemented, it adds 2 more entity types. 362 3.3.1. Proposed optional CS-RID SDSP 364 A CS-RID SDSP MUST appear (i.e. present the same interface) to a Net- 365 RID SP as a Net-RID DP. A CS-RID SDSP MUST appear to a Net-RID DP as 366 a Net-RID SP. A CS-RID SDSP MUST NOT present a standard GCS-facing 367 interface as if it were a Net-RID SP. A CS-RID SDSP MUST NOT present 368 a standard client-facing interface as if it were a Net-RID DP. A CS- 369 RID SDSP MUST present a TBD interface to a CS-RID Finder; this 370 interface SHOULD be based upon but readily distinguishable from that 371 between a GCS and a Net-RID SP. 373 3.3.2. Proposed optional CS-RID Finder 375 A CS-RID Finder MUST present a TBD interface to a CS-RID SDSP; this 376 interface SHOULD be based upon but readily distinguishable from that 377 between a GCS and a Net-RID SP. A CS-RID Finder must implement, 378 integrate, or accept outputs from, a Broadcast RID receiver. A CS- 379 RID Finder MUST NOT interface directly with a GCS, Net-RID SP, Net- 380 RID DP or Network RID client. 382 4. Identifiers 384 4.1. Background 386 A DRIP UA ID needs to be "Trustworthy". This means that within the 387 framework of the RID messages, an observer can establish that the RID 388 used does uniquely belong to the UA. That the only way for any other 389 UA to assert this RID would be to steal something from within the UA. 390 The RID is self-generated by the UAS (either UA or GCS) and 391 registered with the USS. 393 Within the limitations of Broadcast RID, this is extremely 394 challenging as: 396 * An RID can at most be 20 characters 398 * The ASTM Basic RID message (the message containing the RID) is 25 399 characters; only 3 characters are currently unused 401 * The ASTM Authentication message, with some changes from [F3411-19] 402 can carry 224 bytes of payload. 404 Standard approaches like X.509 and PKI will not fit these 405 constraints, even using the new EdDSA algorithm. An example of a 406 technology that will fit within these limitations is an enhancement 407 on the Host Identity Tag (HIT) HIPv2 [RFC7401] as defined in HHIT 408 [I-D.moskowitz-hip-hierarchical-hit]. 410 By using the EdDSA HHIT suite, self-assertions of the RID can be done 411 in as little as 84 bytes. Third-party assertions can be done in 200 412 bytes. An observer would need Internet access to validate a self- 413 assertion claim. A third-party assertion can be validated via a 414 small credential cache in a disconnected environment. This third- 415 party assertion is possible when the third-party also uses HHITs for 416 its identity and the UA has the public key for that HHIT. 418 4.2. Proposed Approach 420 A DRIP UAS ID MUST be a HHIT. It SHOULD be self-generated by the UAS 421 (either UA or GCS) and MUST be registered with the Private 422 Information Registry identified in its hierarchy fields. Each UAS ID 423 HHIT MUST NOT be used more than once, with one exception as follows. 425 Each UA MAY be assigned, by its manufacturer, a single HI and derived 426 HHIT encoded as a hardware serial number per [CTA2063A]. Such a 427 static HHIT SHOULD be used only to bind one-time use UAS IDs (other 428 HHITs) to the unique UA. Depending upon implementation, this may 429 leave a HI private key in the possession of the manufacturer (see 430 Security Considerations). 432 Each UA equipped for Broadcast RID MUST be provisioned not only with 433 its HHIT but also with the HI public key from which the HHIT was 434 derived and the corresponding private key, to enable message 435 signature. Each UAS equipped for Network RID MUST be provisioned 436 likewise; the private key SHOULD reside only in the ultimate source 437 of Network RID messages (i.e. on the UA itself if the GCS is merely 438 relaying rather than sourcing Network RID messages). Each observer 439 device MUST be provisioned with public keys of the UAS RID root 440 registries and MAY be provisioned with public keys or certificates 441 for subordinate registries. 443 Operators and Private Information Registries MUST possess and other 444 UTM entities MAY possess UAS ID style HHITs. When present, such 445 HHITs SHOULD be used with HIP to strongly mutually authenticate and 446 optionally encrypt communications. 448 5. Proposed Transactions 450 Each Operator MUST generate a "HIo" and derived "HHITo", register 451 them with a Private Information Registry along with whatever Operator 452 data (inc. PII) is required by the cognizant CAA and the registry, 453 and obtain a certificate "Cro" signed with "HIr(priv)" proving such 454 registration. 456 To add an UA, an Operator MUST generate a "HIa" and derived "HHITa", 457 create a certificate "Coa" signed with "HIo(priv)" to associate the 458 UA with its Operator, register them with a Private Information 459 Registry along with whatever UAS data is required by the cognizant 460 CAA and the registry, obtain a certificate "Croa" signed with 461 "HIr(priv)" proving such registration, and obtain a certificate "Cra" 462 signed with "HIr(priv)" proving UA registration in that specific 463 registry while preserving Operator privacy. The operator then MUST 464 provision the UA with "HIa", "HIa(priv)", "HHITa" and "Cra". 466 UA engaging in Broadcast RID MUST use "HIa(priv)" to sign Auth 467 Messages and MUST periodically broadcast "Cra". UAS engaging in 468 Network RID MUST use "HIa(priv)" to sign Auth Messages. Observers 469 MUST use "HIa" from received "Cra" to verify received Broadcast RID 470 Auth messages. Observers without Internet connectivity MAY use "Cra" 471 to identify the trust class of the UAS based on known registry 472 vetting. Observers with Internet connectivity MAY use "HHITa" to 473 perform lookups in the Public Information Registry and MAY then query 474 the Private Information Registry, which MUST enforce AAA policy on 475 Operator PII and other sensitive information. 477 6. IANA Considerations 479 It is likely that an IPv6 prefix will be needed for the HHIT (or 480 other identifier) space: this should be coordinated with ICAO; this 481 will be specified in other drafts. 483 7. Security Considerations 485 DRIP is all about safety and security, so content pertaining to such 486 is not limited to this section. The security provided by asymmetric 487 cryptographic techniques depends upon protection of the private keys. 488 A manufacturer that embeds a private key in an UA may have retained a 489 copy. A manufacturer whose UA are configured by a closed source 490 application on the GCS which communicates over the Internet with the 491 factory may be sending a copy of a UA or GCS self-generated key back 492 to the factory. Compromise of a registry private key could do 493 widespread harm. Key revocation procedures are as yet to be 494 determined. These risks are in addition to those involving Operator 495 key management practices. 497 8. Acknowledgments 499 The work of the FAA's UAS Identification and Tracking (UAS ID) 500 Aviation Rulemaking Committee (ARC) is the foundation of later ASTM 501 and proposed IETF DRIP WG efforts. The work of ASTM F38.02 in 502 balancing the interests of diverse stakeholders is essential to the 503 necessary rapid and widespread deployment of UAS RID. 505 Appendix A was provided by Shuai Zhao of Tencent. 507 9. References 509 9.1. Normative References 511 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 512 Requirement Levels", BCP 14, RFC 2119, 513 DOI 10.17487/RFC2119, March 1997, 514 . 516 [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data 517 (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March 518 2015, . 520 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 521 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 522 May 2017, . 524 9.2. Informative References 526 [ATIS-I-0000074] 527 ATIS, "Report on UAS in 3GPP", 528 . 531 [CTA2063A] ANSI, "Small Unmanned Aerial Systems Serial Numbers", 532 September 2019. 534 [Delegated] 535 European Union Aviation Safety Agency (EASA), "EU 536 Commission Delegated Regulation 2019/945 of 12 March 2019 537 on unmanned aircraft systems and on third-country 538 operators of unmanned aircraft systems", March 2019. 540 [F3411-19] ASTM, "Standard Specification for Remote ID and Tracking", 541 December 2019. 543 [I-D.moskowitz-hip-hierarchical-hit] 544 Moskowitz, R., Card, S., and A. Wiethuechter, 545 "Hierarchical HITs for HIPv2", Work in Progress, Internet- 546 Draft, draft-moskowitz-hip-hierarchical-hit-04, 3 March 547 2020, . 550 [I-D.moskowitz-hip-new-crypto] 551 Moskowitz, R., Card, S., and A. Wiethuechter, "New 552 Cryptographic Algorithms for HIP", Work in Progress, 553 Internet-Draft, draft-moskowitz-hip-new-crypto-04, 23 554 January 2020, . 557 [Implementing] 558 European Union Aviation Safety Agency (EASA), "EU 559 Commission Implementing Regulation 2019/947 of 24 May 2019 560 on the rules and procedures for the operation of unmanned 561 aircraft", May 2019. 563 [LANNC] United States Federal Aviation Administration (FAA), "Low 564 Altitude Authorization and Notification Capability", 565 . 568 [NPRM] United States Federal Aviation Administration (FAA), 569 "Notice of Proposed Rule Making on Remote Identification 570 of Unmanned Aircraft Systems", December 2019. 572 [Recommendations] 573 FAA UAS Identification and Tracking Aviation Rulemaking 574 Committee, "UAS ID and Tracking ARC Recommendations Final 575 Report", September 2017. 577 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 578 Unique IDentifier (UUID) URN Namespace", RFC 4122, 579 DOI 10.17487/RFC4122, July 2005, 580 . 582 [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., 583 Tschofenig, H., and H. Schulzrinne, "An Architecture for 584 Location and Location Privacy in Internet Applications", 585 BCP 160, RFC 6280, DOI 10.17487/RFC6280, July 2011, 586 . 588 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 589 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 590 RFC 7401, DOI 10.17487/RFC7401, April 2015, 591 . 593 [TS-22.825] 594 3GPP, "UAS RID requirement study", 595 . 598 [TS-36.777] 599 3GPP, "UAV service in the LTE network", 600 . 603 [U-Space] European Organization for the Safety of Air Navigation 604 (EUROCONTROL), "U-space Concept of Operations", October 605 2019, 606 . 609 Appendix A. Overview of Unmanned Aircraft Systems (UAS) Traffic 610 Management (UTM) 612 A.1. Operation Concept 614 The National Aeronautics and Space Administration (NASA) and FAAs' 615 effort of integrating UAS's operation into the national airspace 616 system (NAS) leads to the development of the concept of UTM and the 617 ecosystem around it. The UTM concept was initially presented in 618 2013. The eventual development and implementation are conducted by 619 the UTM research transition team (RTT) which is the joint workforce 620 by FAA and NASA. World efforts took place afterward. The Single 621 European Sky ATM Research (SESAR) started the CORUS project to 622 research its UTM counterpart concept, namely [U-Space]. This effort 623 is led by the European Organization for the Safety of Air Navigation 624 (Eurocontrol). 626 Both NASA and SESAR have published the UTM concept of operations to 627 guide the development of their future air traffic management (ATM) 628 system and make sure safe and efficient integrations of manned and 629 unmanned aircraft into the national airspace. 631 The UTM composes of UAS operation infrastructure, procedures and 632 local regulation compliance policies to guarantee UAS's safe 633 integration and operation. The main functionality of a UTM includes 634 but not limited to provides means of communication between UAS 635 operators and service providers and a platform to facilitate 636 communication among UAS service providers. 638 A.2. UAS service supplier (USS) 640 A USS plays an important role to fulfill the key performance 641 indicators (KPIs) that a UTM has to offer. Such Entity acts as a 642 proxy between UAS operators and UTM service providers. It provides 643 services like real-time UAS traffic monitor and planning, 644 aeronautical data archiving, airspace and violation control, 645 interacting with other third-party control entities, etc. A USS can 646 coexist with other USS(s) to build a large service coverage map which 647 can load-balance, relay and share UAS traffic information. 649 The FAA works with UAS industry shareholders and promotes the Low 650 Altitude Authorization and Notification Capability [LANNC] program 651 which is the first implementation to realize UTM's functionality. 652 The LAANC program can automate the UAS's fly plan application and 653 approval process for airspace authorization in real-time by checking 654 against multiple aeronautical databases such as airspace 655 classification and fly rules associated with it, FAA UAS facility 656 map, special use airspace, Notice to airman (NOTAM) and Temporary 657 flight rule (TFR). 659 A.3. UTM Use cases for UAS operation 661 This section illustrates a couple of use case scenarios where UAS's 662 participation in UTM has significant safety improvement. 664 1. For a UAS participating in UTM and takeoff or land in a 665 controlled airspace (ex. Class Bravo, Charlie, Delta and Echo in 666 United Stated), the USS where UAS is currently communicating with 667 is responsible for UAS's registration, authenticating the UAS's 668 fly plan by checking against designated UAS fly map database, 669 obtaining the air traffic control (ATC) authorization and monitor 670 the UAS fly path in order to maintain safe boundary and follow 671 the pre-authorized route. 673 2. For a UAS participating in UTM and take off or land in an 674 uncontrolled airspace (ex. Class Golf in the United States), 675 pre-fly authorization must be obtained from a USS when operating 676 beyond-visual-of-sight (BVLOS) operation. The USS either accepts 677 or rejects received intended fly plan from the UAS. Accepted UAS 678 operation may share its current fly data such as GPS position and 679 altitude to USS. The USS may keep the UAS flight status near 680 real-time and may keep it as a record for overall airspace air 681 traffic monitor. 683 A.4. Overview UAS Remote ID (RID) and RID Standardization 685 A RID is an application enabler for a UAS to be identified by a UTM/ 686 USS or third parties entities such as law enforcement. Many safety 687 and other considerations dictate that UAS be remotely identifiable. 688 CAAs worldwide are mandating UAS RID. The European Union Aviation 689 Safety Agency (EASA) has published [Delegated] and [Implementing] 690 Regulations. The FAA has published a Notice of Proposed Rule Making 691 [NPRM]. CAAs currently promulgate performance-based regulations 692 that do not specify techniques, but rather cite industry consensus 693 technical standards as acceptable means of compliance. 695 3GPP provides UA service in the LTE network since release 15 in 696 published technical specification [TS-36.777]. Start from its 697 release 16, it completed the UAS RID requirement study in [TS-22.825] 698 and proposed use cases in the mobile network and the services that 699 can be offered based on RID and ongoing release 17 specification 700 works on enhanced UAS service requirement and provides the protocol 701 and application architecture support which is applicable for both 4G 702 and 5G network. ATIS's recent report [ATIS-I-0000074] proposes 703 architecture approaches for the 3GPP network to support UAS and one 704 of which is put RID in higher 3GPP protocol stack such as using ASTM 705 remote ID [F3411-19]. 707 Authors' Addresses 709 Stuart W. Card 710 AX Enterprize 711 4947 Commercial Drive 712 Yorkville, NY 13495 713 United States of America 715 Email: stu.card@axenterprize.com 717 Adam Wiethuechter 718 AX Enterprize 719 4947 Commercial Drive 720 Yorkville, NY 13495 721 United States of America 723 Email: adam.wiethuechter@axenterprize.com 725 Robert Moskowitz 726 HTT Consulting 727 Oak Park, MI 48237 728 United States of America 730 Email: rgm@labs.htt-consult.com 732 Shuai Zhao 733 Tencent 734 CA 735 United States of America 737 Email: shuaiizhao@tencent.com