idnits 2.17.1 draft-ietf-drip-arch-01.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 112 has weird spacing: '... Pilot xxxxx...' == Line 113 has weird spacing: '...perator x ...' == Line 178 has weird spacing: '...bserver x x...' -- The document date (26 May 2020) is 1431 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-01 == Outdated reference: A later version (-06) exists of draft-moskowitz-drip-uas-rid-01 -- 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: 27 November 2020 R. Moskowitz 6 HTT Consulting 7 S. Zhao 8 Tencent 9 26 May 2020 11 Drone Remote Identification Protocol (DRIP) Architecture 12 draft-ietf-drip-arch-01 14 Abstract 16 This document defines an architecture for protocols and services to 17 support Unmanned Aircraft System Remote Identification and tracking 18 (UAS RID), plus RID-related communications, including required 19 architectural building blocks and their interfaces. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 27 November 2020. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 5 56 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 5 57 2.2. Additional Definitions . . . . . . . . . . . . . . . . . 6 58 3. Entities and their Interfaces . . . . . . . . . . . . . . . . 6 59 3.1. Private Information Registry . . . . . . . . . . . . . . 6 60 3.1.1. Background . . . . . . . . . . . . . . . . . . . . . 6 61 3.1.2. Proposed Approach . . . . . . . . . . . . . . . . . . 6 62 3.2. Public Information Registry . . . . . . . . . . . . . . . 7 63 3.2.1. Background . . . . . . . . . . . . . . . . . . . . . 7 64 3.2.2. Proposed Approach . . . . . . . . . . . . . . . . . . 7 65 3.3. CS-RID concept . . . . . . . . . . . . . . . . . . . . . 7 66 3.3.1. Proposed optional CS-RID SDSP . . . . . . . . . . . . 8 67 3.3.2. Proposed optional CS-RID Finder . . . . . . . . . . . 8 68 4. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 8 70 4.2. Proposed Approach . . . . . . . . . . . . . . . . . . . . 9 71 5. DRIP Transactions enabling Trustworthy UAS RID . . . . . . . 10 72 6. Privacy for Broadcast PII . . . . . . . . . . . . . . . . . . 10 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 77 9.2. Informative References . . . . . . . . . . . . . . . . . 11 78 Appendix A. Overview of Unmanned Aircraft Systems (UAS) Traffic 79 Management (UTM) . . . . . . . . . . . . . . . . . . . . 13 80 A.1. Operation Concept . . . . . . . . . . . . . . . . . . . . 14 81 A.2. UAS Service Supplier (USS) . . . . . . . . . . . . . . . 14 82 A.3. UTM Use Cases for UAS Operations . . . . . . . . . . . . 15 83 A.4. Overview UAS Remote ID (RID) and RID Standardization . . 15 84 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 87 1. Introduction 89 This document describes a natural Internet based architecture for 90 Unmanned Aircraft System Remote Identification and tracking (UAS 91 RID), conforming to proposed regulations and external technical 92 standards, satisfying the requirements listed in the companion 93 requirements document [I-D.ietf-drip-reqs]. The requirements 94 document also provides an extended introduction to the problem space, 95 use cases, etc. Only a brief summary of that introduction will be 96 restated here as context, with reference to the general architecture 97 shown in Figure 1 below. 99 General x x Public 100 Public xxxxx xxxxx Safety 101 Observer x x Observer 102 x x 103 x x ---------+ +---------- x x 104 x x | | x x 105 | | 106 + + 107 xxxxxxxxxx 108 x x 109 +----------+x Internet x+------------+ 110 | x x | 111 UA1 x | xxxxxxxxxx | x UA2 112 Pilot xxxxx + + + xxxxx Pilot 113 Operator x | | | x Operator 114 x | | | x 115 x x | | | x x 116 x x | | | x x 117 | | | 118 +----------+ | | | +----------+ 119 | |------+ | +-------| | 120 | Public | | | Private | 121 | Registry | +-----+ | Registry | 122 | | | DNS | | | 123 +----------+ +-----+ +----------+ 125 Figure 1 127 Many considerations (especially safety) dictate that UAS be remotely 128 identifiable. Civil Aviation Authorities (CAAs) worldwide are 129 mandating Unmanned Aircraft Systems (UAS) Remote Identification 130 (RID). CAAs currently (2020) promulgate performance-based 131 regulations that do not specify techniques, but rather cite industry 132 consensus technical standards as acceptable means of compliance. 134 ASTM International, Technical Committee F38 (UAS), Subcommittee 135 F38.02 (Aircraft Operations), Work Item WK65041, developed the new 136 ASTM [F3411-19] Standard Specification for Remote ID and Tracking. 137 It defines one set of RID information and two means of communicating 138 it. If a UAS uses both communication methods, generally the same 139 information must provided via both means. While hybrids are possible 140 (and indeed one is proposed as an optional DRIP service), the two 141 basic methods are defined as follows: 143 Network RID defines a RID data dictionary and data flow: from a 144 UAS via unspecified means to a Network Remote ID Service Provider 145 (Net-RID SP); from the Net-RID SP to an integrated, or over the 146 Internet to a separate, Network Remote ID Display Provider (Net- 147 RID DP); from the Net-RID DP via the Internet to Network Remote ID 148 clients in response to their queries (expected typically, but not 149 specified exclusively, to be web based) specifying airspace 150 volumes of interest. Network RID depends upon connectivity, in 151 several segments, via the Internet, from the UAS to the Observer. 153 Broadcast RID defines a set of RID messages and how the UA 154 transmits them locally directly one-way, over Bluetooth or Wi-Fi. 155 Broadcast RID should need Internet (or other Wide Area Network) 156 connectivity only for UAS registry information lookup using the 157 locally directly received UAS ID as a key. Broadcast RID should 158 be functionally usable in situations with no Internet 159 connectivity. 161 The less constrained but more complex case of Network RID is 162 illustrated in Figure 2 below. 164 x x UA 165 xxxxx ******************** 166 | * ------*---+------------+ 167 | * / * | NET_Rid_DP | 168 | * ------------/ +---*--+------------+ 169 | RF */ | * 170 | * INTERNET | * +------------+ 171 | /* +---*--| NET_Rid_SP | 172 | / * +----*--+------------+ 173 + / * | * 174 x / ****************|*** x 175 xxxxx | xxxxx 176 x +------- x 177 x x 178 x x Operator (GCS) Observer x x 179 x x x x 181 Figure 2 183 Via the direct Radio Frequency (RF) link between the UA and GCS: 184 Command and Control (C2) flows from the GCS to the UA; for all but 185 the simplest hobby aircraft, position and status flow from the UA to 186 the GCS. Via the Internet, through three distinct segments, Network 187 RID information flows from the UAS (comprising the UA and its GCS) to 188 the Observer. 190 Other Standards Development Organizations (SDOs, e.g., 3GPP, 191 Appendix A.4) may define their own communication methods for both 192 Network and Broadcast RID. The CAAs expect any additional methods to 193 maintain consistency of the RID messages. 195 DRIP will enable leveraging existing Internet resources (standard 196 protocols, services, infrastructure and business models) to meet UAS 197 RID and closely related needs. DRIP will specify how to apply IETF 198 standards, complementing [F3411-19] and other external standards, to 199 satisfy UAS RID requirements. DRIP will update existing and develop 200 new protocol standards as needed to accomplish the foregoing. 202 This document will outline the UAS RID architecture into which DRIP 203 must fit, and an architecture for DRIP itself. This includes 204 presenting the gaps between the CAAs' Concepts of Operations and 205 [F3411-19] as it relates to use of Internet technologies and UA 206 direct RF communications. Issues include, but are not limited to: 208 * Trustworthy Remote ID and trust in RID messages 210 * Privacy in RID messages (PII protection) 212 * UA -> Ground communications including Broadcast RID 214 * Broadcast RID 'harvesting' and secure forwarding into the UTM 216 * Secure UAS -> Net-RID SP communications 218 * Secure Observer -> Pilot communications 220 2. Terms and Definitions 222 2.1. Requirements Terminology 224 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 225 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 226 "OPTIONAL" in this document are to be interpreted as described in BCP 227 14 [RFC2119] [RFC8174] when, and only when, they appear in all 228 capitals, as shown here. 230 2.2. Additional Definitions 232 This document uses terms defined in [I-D.ietf-drip-reqs]. 234 3. Entities and their Interfaces 236 Any DRIP solutions for UAS RID must fit into the UTM (or U-space) 237 system. This implies interaction with entities including UA, GCS, 238 USS, Net-RID SP, Net-RID DP, Observers, Operators, Pilots In Command, 239 Remote Pilots, possibly SDSP, etc. The only additional entities 240 introduced in this document are registries, required but not 241 specified by the regulations and [RFC7401], and optionally CS-RID 242 SDSP and Finder nodes. 244 UAS registries hold both public and private UAS information. The 245 public information is primarily pointers to the repositories of, and 246 keys for looking up, the private information. Given these different 247 uses, and to improve scalability, security and simplicity of 248 administration, the public and private information can be stored in 249 different registries, indeed different types of registry. 251 3.1. Private Information Registry 253 3.1.1. Background 255 The private information required for UAS RID is similar to that 256 required for Internet domain name registration. Thus a DRIP RID 257 solution can leverage existing Internet resources: registration 258 protocols, infrastructure and business models, by fitting into an ID 259 structure compatible with DNS names. This implies some sort of 260 hierarchy, for scalability, and management of this hierarchy. It is 261 expected that the private registry function will be provided by the 262 same organizations that run USS, and likely integrated with USS. 264 3.1.2. Proposed Approach 266 A DRIP UAS ID MUST be amenable to handling as an Internet domain name 267 (at an arbitrary level in the hierarchy), MUST be registered in at 268 least a pseudo-domain (e.g. .ip6 for reverse lookup), and MAY be 269 registered as a sub-domain (for forward lookup). 271 A DRIP private information registry MUST support essential Internet 272 domain name registry operations (e.g. add, delete, update, query) 273 using interoperable open standard protocols. It SHOULD support the 274 Extensible Provisioning Protocol (EPP) and the Registry Data Access 275 Protocol (RDAP) with access controls. It MAY use XACML to specify 276 those access controls. It MUST be listed in a DNS: that DNS MAY be 277 private; but absent any compelling reasons for use of private DNS, 278 SHOULD be the definitive public Internet DNS hierarchy. The DRIP 279 private information registry in which a given UAS is registered MUST 280 be locatable, starting from the UAS ID, using the methods specified 281 in [RFC7484]. 283 3.2. Public Information Registry 285 3.2.1. Background 287 The public information required to be made available by UAS RID is 288 transmitted as cleartext to local observers in Broadcast RID and is 289 served to a client by a Net-RID DP in Network RID. Therefore, while 290 IETF can offer e.g. [RFC6280] as one way to implement Network RID, 291 the only public information required to support essential DRIP 292 functions for UAS RID is that required to look up Internet domain 293 hosts, services, etc. 295 3.2.2. Proposed Approach 297 A DRIP public information registry MUST be a standard DNS server, in 298 the definitive public Internet DNS hierarchy. It MUST support NS, 299 MX, SRV, TXT, AAAA, PTR, CNAME and HIP RR (the last per [RFC8005]) 300 types. 302 3.3. CS-RID concept 304 ASTM anticipated that regulators would require both Broadcast RID and 305 Network RID for large UAS, but allow RID requirements for small UAS 306 to be satisfied with the operator's choice of either Broadcast RID or 307 Network RID. The EASA initially specified Broadcast RID for UAS of 308 essentially all UAS and is now considering Network RID also. The FAA 309 NPRM requires both for Standard RID and specifies Broadcast RID only 310 for Limited RID. One obvious opportunity is to enhance the 311 architecture with gateways from Broadcast RID to Network RID. This 312 provides the best of both and gives regulators and operators 313 flexibility. Such gateways could be pre-positioned (e.g. around 314 airports and other sensitive areas) and/or crowdsourced (as nothing 315 more than a smartphone with a suitable app is needed). Gateways can 316 also perform multilateration to provide independent measurements of 317 UA position, which is otherwise entirely operator self-reported in 318 UAS RID and UTM. CS-RID would be an option, beyond baseline DRIP 319 functionality; if implemented, it adds 2 more entity types. 321 3.3.1. Proposed optional CS-RID SDSP 323 A CS-RID SDSP MUST appear (i.e. present the same interface) to a Net- 324 RID SP as a Net-RID DP. A CS-RID SDSP MUST appear to a Net-RID DP as 325 a Net-RID SP. A CS-RID SDSP MUST NOT present a standard GCS-facing 326 interface as if it were a Net-RID SP. A CS-RID SDSP MUST NOT present 327 a standard client-facing interface as if it were a Net-RID DP. A CS- 328 RID SDSP MUST present a TBD interface to a CS-RID Finder; this 329 interface SHOULD be based upon but readily distinguishable from that 330 between a GCS and a Net-RID SP. 332 3.3.2. Proposed optional CS-RID Finder 334 A CS-RID Finder MUST present a TBD interface to a CS-RID SDSP; this 335 interface SHOULD be based upon but readily distinguishable from that 336 between a GCS and a Net-RID SP. A CS-RID Finder must implement, 337 integrate, or accept outputs from, a Broadcast RID receiver. A CS- 338 RID Finder MUST NOT interface directly with a GCS, Net-RID SP, Net- 339 RID DP or Network RID client. 341 4. Identifiers 343 4.1. Background 345 A DRIP UA ID needs to be "Trustworthy". This means that within the 346 framework of the RID messages, an observer can establish that the RID 347 used does uniquely belong to the UA. That the only way for any other 348 UA to assert this RID would be to steal something from within the UA. 349 The RID is self-generated by the UAS (either UA or GCS) and 350 registered with the USS. 352 Within the limitations of Broadcast RID, this is extremely 353 challenging as: 355 * An RID can at most be 20 characters 357 * The ASTM Basic RID message (the message containing the RID) is 25 358 characters; only 3 characters are currently unused 360 * The ASTM Authentication message, with some changes from [F3411-19] 361 can carry 224 bytes of payload. 363 Standard approaches like X.509 and PKI will not fit these 364 constraints, even using the new EdDSA algorithm. An example of a 365 technology that will fit within these limitations is an enhancement 366 of the Host Identity Tag (HIT) of HIPv2 [RFC7401] introducing 367 hierarchy as defined in HHIT [I-D.moskowitz-hip-hierarchical-hit]; 368 using Hierarchical HITs for UAS RID is outlined in HHIT based UAS RID 370 [I-D.moskowitz-drip-uas-rid]. As PKI with X.509 is being used in 371 other systems with which UAS RID must interoperate (e.g. the UTM 372 Discovery and Synchronization Service and the UTM InterUSS protocol) 373 mappings between the more flexible but larger X.509 certificates and 374 the HHIT based structures must be devised. 376 By using the EdDSA HHIT suite, self-assertions of the RID can be done 377 in as little as 84 bytes. Third-party assertions can be done in 200 378 bytes. An observer would need Internet access to validate a self- 379 assertion claim. A third-party assertion can be validated via a 380 small credential cache in a disconnected environment. This third- 381 party assertion is possible when the third-party also uses HHITs for 382 its identity and the UA has the public key for that HHIT. 384 4.2. Proposed Approach 386 A DRIP UAS ID MUST be a HHIT. It SHOULD be self-generated by the UAS 387 (either UA or GCS) and MUST be registered with the Private 388 Information Registry identified in its hierarchy fields. Each UAS ID 389 HHIT MUST NOT be used more than once, with one exception as follows. 391 Each UA MAY be assigned, by its manufacturer, a single HI and derived 392 HHIT encoded as a hardware serial number per [CTA2063A]. Such a 393 static HHIT SHOULD be used only to bind one-time use UAS IDs (other 394 HHITs) to the unique UA. Depending upon implementation, this may 395 leave a HI private key in the possession of the manufacturer (see 396 Security Considerations). 398 Each UA equipped for Broadcast RID MUST be provisioned not only with 399 its HHIT but also with the HI public key from which the HHIT was 400 derived and the corresponding private key, to enable message 401 signature. Each UAS equipped for Network RID MUST be provisioned 402 likewise; the private key SHOULD reside only in the ultimate source 403 of Network RID messages (i.e. on the UA itself if the GCS is merely 404 relaying rather than sourcing Network RID messages). Each observer 405 device MUST be provisioned with public keys of the UAS RID root 406 registries and MAY be provisioned with public keys or certificates 407 for subordinate registries. 409 Operators and Private Information Registries MUST possess and other 410 UTM entities MAY possess UAS ID style HHITs. When present, such 411 HHITs SHOULD be used with HIP to strongly mutually authenticate and 412 optionally encrypt communications. 414 5. DRIP Transactions enabling Trustworthy UAS RID 416 Each Operator MUST generate a "HIo" and derived "HHITo", register 417 them with a Private Information Registry along with whatever Operator 418 data (inc. PII) is required by the cognizant CAA and the registry, 419 and obtain a certificate "Cro" signed with "HIr(priv)" proving such 420 registration. 422 To add an UA, an Operator MUST generate a "HIa" and derived "HHITa", 423 create a certificate "Coa" signed with "HIo(priv)" to associate the 424 UA with its Operator, register them with a Private Information 425 Registry along with whatever UAS data is required by the cognizant 426 CAA and the registry, obtain a certificate "Croa" signed with 427 "HIr(priv)" proving such registration, and obtain a certificate "Cra" 428 signed with "HIr(priv)" proving UA registration in that specific 429 registry while preserving Operator privacy. The operator then MUST 430 provision the UA with "HIa", "HIa(priv)", "HHITa" and "Cra". 432 UA engaging in Broadcast RID MUST use "HIa(priv)" to sign Auth 433 Messages and MUST periodically broadcast "Cra". UAS engaging in 434 Network RID MUST use "HIa(priv)" to sign Auth Messages. Observers 435 MUST use "HIa" from received "Cra" to verify received Broadcast RID 436 Auth messages. Observers without Internet connectivity MAY use "Cra" 437 to identify the trust class of the UAS based on known registry 438 vetting. Observers with Internet connectivity MAY use "HHITa" to 439 perform lookups in the Public Information Registry and MAY then query 440 the Private Information Registry, which MUST enforce AAA policy on 441 Operator PII and other sensitive information. 443 6. Privacy for Broadcast PII 445 Broadcast RID messages may contain PII. This may be information 446 about the UA such as its destination or Operator information such as 447 GCS location. There is no absolute "right" in hiding PII, as there 448 will be times (e.g., disasters) and places (buffer zones around 449 airports and sensitive facilities) where policy may mandate all 450 information be sent as cleartext. Otherwise, the modern general 451 position (consistent with, e.g., the EU General Data Protection 452 Regulation) is to hide PII unless otherwise instructed. While some 453 have argued that a system like that of automobile registration plates 454 should suffice for UAS, others have argued persuasively that each 455 generation of new identifiers should take advantage of advancing 456 technology to protect privacy, to the extent compatible with the 457 transparency needed to protect safety. 459 A viable architecture for PII protection would be symmetric 460 encryption of the PII using a key known to the UAS and a USS service. 461 An authorized Observer may send the encrypted PII along with the 462 Remote ID (to their UAS display service) to get the plaintext. The 463 authorized Observer may send the Remote ID (to their UAS display 464 service) and receive the key to directly decrypt all PII content from 465 the UA. 467 PII is protected unless the UAS is informed otherwise. This may come 468 from operational instructions to even permit flying in a space/time. 469 It may be special instructions at the start or during a mission. PII 470 protection should not be used if the UAS loses connectivity to the 471 USS. The USS always has the option to abort the mission if PII 472 protection is disallowed. 474 An authorized Observer may instruct a UAS via the USS that conditions 475 have changed mandating no PII protection or land the UA. 477 7. IANA Considerations 479 This document does not make any request to IANA. 481 8. Security Considerations 483 DRIP is all about safety and security, so content pertaining to such 484 is not limited to this section. The security provided by asymmetric 485 cryptographic techniques depends upon protection of the private keys. 486 A manufacturer that embeds a private key in an UA may have retained a 487 copy. A manufacturer whose UA are configured by a closed source 488 application on the GCS which communicates over the Internet with the 489 factory may be sending a copy of a UA or GCS self-generated key back 490 to the factory. Compromise of a registry private key could do 491 widespread harm. Key revocation procedures are as yet to be 492 determined. These risks are in addition to those involving Operator 493 key management practices. 495 9. References 497 9.1. Normative References 499 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 500 Requirement Levels", BCP 14, RFC 2119, 501 DOI 10.17487/RFC2119, March 1997, 502 . 504 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 505 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 506 May 2017, . 508 9.2. Informative References 510 [ATIS-I-0000074] 511 ATIS, "Report on UAS in 3GPP", 512 . 515 [CTA2063A] ANSI, "Small Unmanned Aerial Systems Serial Numbers", 516 September 2019. 518 [Delegated] 519 European Union Aviation Safety Agency (EASA), "EU 520 Commission Delegated Regulation 2019/945 of 12 March 2019 521 on unmanned aircraft systems and on third-country 522 operators of unmanned aircraft systems", March 2019. 524 [F3411-19] ASTM, "Standard Specification for Remote ID and Tracking", 525 December 2019. 527 [I-D.ietf-drip-reqs] 528 Card, S., Wiethuechter, A., Moskowitz, R., and A. Gurtov, 529 "Drone Remote Identification Protocol (DRIP) 530 Requirements", Work in Progress, Internet-Draft, draft- 531 ietf-drip-reqs-01, 25 May 2020, 532 . 534 [I-D.moskowitz-drip-uas-rid] 535 Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov, 536 "UAS Remote ID", Work in Progress, Internet-Draft, draft- 537 moskowitz-drip-uas-rid-01, 5 May 2020, 538 . 541 [I-D.moskowitz-hip-hierarchical-hit] 542 Moskowitz, R., Card, S., and A. Wiethuechter, 543 "Hierarchical HITs for HIPv2", Work in Progress, Internet- 544 Draft, draft-moskowitz-hip-hierarchical-hit-05, 13 May 545 2020, . 548 [Implementing] 549 European Union Aviation Safety Agency (EASA), "EU 550 Commission Implementing Regulation 2019/947 of 24 May 2019 551 on the rules and procedures for the operation of unmanned 552 aircraft", May 2019. 554 [LANNC] United States Federal Aviation Administration (FAA), "Low 555 Altitude Authorization and Notification Capability", 556 . 559 [NPRM] United States Federal Aviation Administration (FAA), 560 "Notice of Proposed Rule Making on Remote Identification 561 of Unmanned Aircraft Systems", December 2019. 563 [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., 564 Tschofenig, H., and H. Schulzrinne, "An Architecture for 565 Location and Location Privacy in Internet Applications", 566 BCP 160, RFC 6280, DOI 10.17487/RFC6280, July 2011, 567 . 569 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 570 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 571 RFC 7401, DOI 10.17487/RFC7401, April 2015, 572 . 574 [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data 575 (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March 576 2015, . 578 [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name 579 System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, 580 October 2016, . 582 [TS-22.825] 583 3GPP, "UAS RID requirement study", 584 . 587 [TS-36.777] 588 3GPP, "UAV service in the LTE network", 589 . 592 [U-Space] European Organization for the Safety of Air Navigation 593 (EUROCONTROL), "U-space Concept of Operations", October 594 2019, 595 . 598 Appendix A. Overview of Unmanned Aircraft Systems (UAS) Traffic 599 Management (UTM) 601 A.1. Operation Concept 603 The National Aeronautics and Space Administration (NASA) and FAAs' 604 effort of integrating UAS's operation into the national airspace 605 system (NAS) leads to the development of the concept of UTM and the 606 ecosystem around it. The UTM concept was initially presented in 607 2013. The eventual development and implementation are conducted by 608 the UTM research transition team which is the joint workforce by FAA 609 and NASA. World efforts took place afterward. The Single European 610 Sky ATM Research (SESAR) started the CORUS project to research its 611 UTM counterpart concept, namely [U-Space]. This effort is led by the 612 European Organization for the Safety of Air Navigation (Eurocontrol). 614 Both NASA and SESAR have published the UTM concept of operations to 615 guide the development of their future air traffic management (ATM) 616 system and make sure safe and efficient integrations of manned and 617 unmanned aircraft into the national airspace. 619 The UTM composes of UAS operation infrastructure, procedures and 620 local regulation compliance policies to guarantee UAS's safe 621 integration and operation. The main functionality of a UTM includes, 622 but is not limited to, providing means of communication between UAS 623 operators and service providers and a platform to facilitate 624 communication among UAS service providers. 626 A.2. UAS Service Supplier (USS) 628 A USS plays an important role to fulfill the key performance 629 indicators (KPIs) that a UTM has to offer. Such Entity acts as a 630 proxy between UAS operators and UTM service providers. It provides 631 services like real-time UAS traffic monitor and planning, 632 aeronautical data archiving, airspace and violation control, 633 interacting with other third-party control entities, etc. A USS can 634 coexist with other USS(s) to build a large service coverage map which 635 can load-balance, relay and share UAS traffic information. 637 The FAA works with UAS industry shareholders and promotes the Low 638 Altitude Authorization and Notification Capability [LANNC] program 639 which is the first implementation to realize UTM's functionality. 640 The LAANC program can automate the UAS's fly plan application and 641 approval process for airspace authorization in real-time by checking 642 against multiple aeronautical databases such as airspace 643 classification and fly rules associated with it, FAA UAS facility 644 map, special use airspace, Notice to airman (NOTAM) and Temporary 645 flight rule (TFR). 647 A.3. UTM Use Cases for UAS Operations 649 This section illustrates a couple of use case scenarios where UAS 650 participation in UTM has significant safety improvement. 652 1. For a UAS participating in UTM and takeoff or land in a 653 controlled airspace (e.g., Class Bravo, Charlie, Delta and Echo 654 in United States), the USS where UAS is currently communicating 655 with is responsible for UAS's registration, authenticating the 656 UAS's fly plan by checking against designated UAS fly map 657 database, obtaining the air traffic control (ATC) authorization 658 and monitor the UAS fly path in order to maintain safe boundary 659 and follow the pre-authorized route. 661 2. For a UAS participating in UTM and take off or land in an 662 uncontrolled airspace (ex. Class Golf in the United States), 663 pre-fly authorization must be obtained from a USS when operating 664 beyond-visual-of-sight (BVLOS) operation. The USS either accepts 665 or rejects received intended fly plan from the UAS. Accepted UAS 666 operation may share its current fly data such as GPS position and 667 altitude to USS. The USS may keep the UAS flight status near 668 real-time and may keep it as a record for overall airspace air 669 traffic monitor. 671 A.4. Overview UAS Remote ID (RID) and RID Standardization 673 A RID is an application enabler for a UAS to be identified by a UTM/ 674 USS or third parties entities such as law enforcement. Many safety 675 and other considerations dictate that UAS be remotely identifiable. 676 CAAs worldwide are mandating UAS RID. The European Union Aviation 677 Safety Agency (EASA) has published [Delegated] and [Implementing] 678 Regulations. The FAA has published a Notice of Proposed Rule Making 679 [NPRM]. CAAs currently promulgate performance-based regulations that 680 do not specify techniques, but rather cite industry consensus 681 technical standards as acceptable means of compliance. 683 3GPP provides UA service in the LTE network since release 15 in 684 published technical specification [TS-36.777]. Start from its 685 release 16, it completed the UAS RID requirement study in [TS-22.825] 686 and proposed use cases in the mobile network and the services that 687 can be offered based on RID and ongoing release 17 specification 688 works on enhanced UAS service requirement and provides the protocol 689 and application architecture support which is applicable for both 4G 690 and 5G network. ATIS's recent report [ATIS-I-0000074] proposes 691 architecture approaches for the 3GPP network to support UAS and one 692 of which is put RID in higher 3GPP protocol stack such as using ASTM 693 remote ID [F3411-19]. 695 Acknowledgments 697 The work of the FAA's UAS Identification and Tracking (UAS ID) 698 Aviation Rulemaking Committee (ARC) is the foundation of later ASTM 699 and proposed IETF DRIP WG efforts. The work of ASTM F38.02 in 700 balancing the interests of diverse stakeholders is essential to the 701 necessary rapid and widespread deployment of UAS RID. IETF 702 volunteers who have contributed to this draft include Amelia 703 Andersdotter and Mohamed Boucadair. 705 Authors' Addresses 707 Stuart W. Card (editor) 708 AX Enterprize 709 4947 Commercial Drive 710 Yorkville, NY 13495 711 United States of America 713 Email: stu.card@axenterprize.com 715 Adam Wiethuechter 716 AX Enterprize 717 4947 Commercial Drive 718 Yorkville, NY 13495 719 United States of America 721 Email: adam.wiethuechter@axenterprize.com 723 Robert Moskowitz 724 HTT Consulting 725 Oak Park, MI 48237 726 United States of America 728 Email: rgm@labs.htt-consult.com 730 Shuai Zhao 731 Tencent 732 CA 733 United States of America 735 Email: shuaiizhao@tencent.com