idnits 2.17.1 draft-ietf-drip-reqs-10.txt: -(8): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1896): 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 4 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 171 has weird spacing: '...perator x ...' == Line 995 has weird spacing: '...bserver x x...' -- The document date (27 April 2021) is 1095 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 ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 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: 29 October 2021 R. Moskowitz 6 HTT Consulting 7 A. Gurtov 8 Linköping University 9 27 April 2021 11 Drone Remote Identification Protocol (DRIP) Requirements 12 draft-ietf-drip-reqs-10 14 Abstract 16 This document defines terminology and requirements for Drone Remote 17 Identification Protocol (DRIP) Working Group solutions to support 18 Unmanned Aircraft System Remote Identification and tracking (UAS RID) 19 for security, safety, and other purposes (e.g., initiation of 20 identity based network sessions supporting UAS applications). 21 Complementing external technical standards as regulator-accepted 22 means of compliance with UAS RID regulations, DRIP will facilitate 23 use of existing Internet resources to support RID and to enable 24 enhanced related services, and will enable online and offline 25 verification that RID information is trustworthy. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 29 October 2021. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Motivation and External Influences . . . . . . . . . . . 3 62 1.2. Concerns and Constraints . . . . . . . . . . . . . . . . 8 63 1.3. DRIP Scope . . . . . . . . . . . . . . . . . . . . . . . 10 64 1.4. Document Scope . . . . . . . . . . . . . . . . . . . . . 11 65 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 11 66 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 11 67 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 11 68 3. UAS RID Problem Space . . . . . . . . . . . . . . . . . . . . 19 69 3.1. Network RID . . . . . . . . . . . . . . . . . . . . . . . 21 70 3.2. Broadcast RID . . . . . . . . . . . . . . . . . . . . . . 25 71 3.3. USS in UTM and RID . . . . . . . . . . . . . . . . . . . 28 72 3.4. DRIP Focus . . . . . . . . . . . . . . . . . . . . . . . 29 73 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 30 74 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 30 75 4.2. Identifier . . . . . . . . . . . . . . . . . . . . . . . 32 76 4.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 33 77 4.4. Registries . . . . . . . . . . . . . . . . . . . . . . . 35 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 36 80 7. Privacy and Transparency Considerations . . . . . . . . . . . 37 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 38 83 8.2. Informative References . . . . . . . . . . . . . . . . . 38 84 Appendix A. Discussion and Limitations . . . . . . . . . . . . . 42 85 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 43 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 88 1. Introduction 90 For any unfamiliar or _a priori_ ambiguous terminology herein, see 91 Section 2. 93 1.1. Motivation and External Influences 95 Many considerations (especially safety and security) necessitate 96 Unmanned Aircraft Systems (UAS) Remote Identification and tracking 97 (RID). 99 Unmanned Aircraft (UA) may be fixed wing, rotary wing (e.g., 100 helicopter), hybrid, balloon, rocket, etc. Small fixed wing UA 101 typically have Short Take-Off and Landing (STOL) capability; rotary 102 wing and hybrid UA typically have Vertical Take-Off and Landing 103 (VTOL) capability. UA may be single- or multi-engine. The most 104 common today are multicopters: rotary wing, multi engine. The 105 explosion in UAS was enabled by hobbyist development, for 106 multicopters, of advanced flight stability algorithms, enabling even 107 inexperienced pilots to take off, fly to a location of interest, 108 hover, and return to the take-off location or land at a distance. 109 UAS can be remotely piloted by a human (e.g., with a joystick) or 110 programmed to proceed from Global Navigation Satellite System (GNSS) 111 waypoint to waypoint in a weak form of autonomy; stronger autonomy is 112 coming. 114 Small UA are "low observable" as they: 116 * typically have small radar cross sections; 118 * make noise quite noticeable at short ranges but difficult to 119 detect at distances they can quickly close (500 meters in under 13 120 seconds by the fastest consumer mass market drones available in 121 early 2021); 123 * typically fly at low altitudes (e.g., for those to which RID 124 applies in the US, under 400 feet Above Ground Level (AGL) as per 125 [Part107]); 127 * are highly maneuverable so can fly under trees and between 128 buildings. 130 UA can carry payloads including sensors, cyber and kinetic weapons, 131 or can be used themselves as weapons by flying them into targets. 132 They can be flown by clueless, careless, or criminal operators. Thus 133 the most basic function of UAS RID is "Identification Friend or Foe" 134 (IFF) to mitigate the significant threat they present. 136 Diverse other applications can be enabled or facilitated by RID. 137 Internet protocols typically start out with at least one entity 138 already knowing an identifier or locator of another; but an entity 139 (e.g., UAS or Observer device) encountering an _a priori_ unknown UA 140 in physical space has no identifier or logical space locator for that 141 UA, unless and until one is provided somehow. RID provides an 142 identifier, which, if well chosen, can facilitate use of a variety of 143 Internet family protocols and services to support arbitrary 144 applications, beyond the basic security functions of RID. For most 145 of these, some type of identifier is essential, e.g., Network Access 146 Identifier (NAI), Digital Object Identifier (DOI), Uniform Resource 147 Identifier (URI), domain mame, or public key. DRIP motivations 148 include both the basic security and the broader application support 149 functions of RID. 151 The general UAS RID usage scenario is illustrated in Figure 1. 153 UA1 UA2 154 x x x x 155 xxxxx xxxxx 157 General x x Public 158 Public xxxxx xxxxx Safety 159 Observer x x Observer 160 x x 161 x x ---------+ +---------- x x 162 x x | | x x 163 | | 164 + + 165 xxxxxxxxxx 166 x x 167 +----------+x Internet x+------------+ 168 | x x | 169 UA1 x | xxxxxxxxxx | x UA2 170 Pilot/ xxxxx + + + xxxxx Pilot/ 171 Operator x | | | x Operator 172 x | | | x 173 x x | | | x x 174 x x | | | x x 175 | | | 176 +----------+ | | | +----------+ 177 | |------+ | +-------| | 178 | Public | | | Private | 179 | Registry | +-----+ | Registry | 180 | | | DNS | | | 181 +----------+ +-----+ +----------+ 183 Figure 1: "General UAS RID Usage Scenario" 185 Figure 1 illustrates a typical case where there may be: multiple 186 Observers, some of them members of the general public, others 187 government officers with public safety/security responsibilities; 188 multiple UA in flight within observation range, each with its own 189 pilot/operator; at least one registry each for lookup of public and 190 (by authorized parties only) private information regarding the UAS 191 and their pilots/operators; and in the DRIP vision, DNS resolving 192 various identifiers and locators of the entities involved. Note the 193 absence of any links to/from the UA in the figure; this is because 194 UAS RID and other connectivity involving the UA varies as described 195 below. 197 An Observer of UA may need to classify them, as illustrated 198 notionally in Figure 2, for basic airspace Situational Awareness 199 (SA). An Observer who classifies a UAS: as Taskable, can ask it to 200 do something useful; as Low Concern, can reasonably assume it is not 201 malicious and would cooperate with requests to modify its flight 202 plans for safety concerns that arise; as High Concern or 203 Unidentified, can focus surveillance on it. 205 xxxxxxx +--------------+ 206 x x No | | 207 x ID? x+---->| Unidentified | 208 x x | | 209 xxxxxxx +--------------+ 210 + 211 | Yes 212 v 213 xxxxxxx 214 x x 215 +---------+x Type? x+----------+ 216 | x x | 217 | xxxxxxx | 218 | + | 219 v v v 220 +--------------+ +--------------+ +--------------+ 221 | | | | | | 222 | Taskable | | Low Concern | | High Concern | 223 | | | | | | 224 +--------------+ +--------------+ +--------------+ 226 Figure 2: "Notional UAS Classification" 228 ASTM International, Technical Committee F38 (UAS), Subcommittee 229 F38.02 (Aircraft Operations), Work Item WK65041, developed the widely 230 cited Standard Specification for Remote ID and Tracking [F3411-19]: 231 the published standard is available for purchase from ASTM and as an 232 ASTM membership premium; early drafts are freely available as 233 [OpenDroneID] specifications. [F3411-19] is frequently referenced in 234 DRIP, where building upon its link layers and both enhancing support 235 for and expanding the scope of its applications are central foci. 237 In many applications, including UAS RID, identification and 238 identifiers are not ends in themselves; they exist to enable lookups 239 and provision of other services. 241 Using UAS RID to facilitate vehicular (V2X) communications and 242 applications such as Detect And Avoid (DAA), which would impose 243 tighter latency bounds than RID itself, is an obvious possibility, 244 explicitly contemplated in the United States (US) Federal Aviation 245 Administration (FAA) Remote Identification of Unmanned Aircraft rule 246 [FRUR]. However, applications of RID beyond RID itself, including 247 DAA, have been declared out of scope in ASTM F38.02 WK65041, based on 248 a distinction between RID as a security standard vs DAA as a safety 249 application. Each SDO has its own cultural set of connotations of 250 safety vs security; ICAO's denotative definitions are cited in 251 Section 2. 253 [Opinion1] and [WG105] cite the Direct Remote Identification (DRI) 254 previously required and specified, explicitly stating that whereas 255 DRI is primarily for security purposes, the "Network Identification 256 Service" [Opinion1] (in the context of U-space [InitialView]) or 257 "Electronic Identification" [WG105] is primarily for safety purposes 258 (e.g., Air Traffic Management, especially hazards deconfliction) and 259 also is allowed to be used for other purposes such as support of 260 efficient operations. These emerging standards allow the security 261 and safety oriented systems to be separate or merged. In addition to 262 mandating both Broadcast and Network one-way to Observers, they will 263 use V2V to other UAS (also likely to and/or from some manned 264 aircraft). These reflect the broad scope of the European Union (EU) 265 U-space concept, as being developed in the Single European Sky ATM 266 Research (SESAR) Joint Undertaking, the U-space architectural 267 principles of which are outlined in [InitialView]. 269 ASD-STAN is an Associated Body to CEN (European Committee for 270 Standardization) for Aerospace Standards. It is publishing an EU 271 standard "Aerospace series - Unmanned Aircraft Systems - Part 002: 272 Direct Remote Identification; English version prEN 4709-002:2020" for 273 which a current (early 2021) informal overview is freely available in 274 [ASDRI]. It will provide compliance to cover the identical DRI 275 requirements applicable to drones of classes C1 - [Delegated] Part 2, 276 C2 - [Delegated] Part 3, C3 - [Delegated] Part 4, C5 - [Amended] Part 277 16, and C6 - [Amended] Part 17. 279 The standard contemplated in [ASDRI] will provide UA capability to be 280 identified in real time during the whole duration of the flight, 281 without specific connectivity or ground infrastructure link, 282 utilizing existing mobile devices within broadcast range. It will 283 use Bluetooth 4, Bluetooth 5, Wi-Fi Neighbor Awareness Networking 284 (NAN, also known as Wi-Fi Aware, [WiFiNAN]) and/or IEEE 802.11 Beacon 285 modes. The EU standard emphasis was compatibility with [F3411-19], 286 although there are differences in mandatory and optional message 287 types and fields. 289 The [ASDRI] contemplated DRI system will broadcast locally: 291 1. the UAS operator registration number; 293 2. the [CTA2063A] compliant unique serial number of the UA; 295 3. a time stamp, the geographical position of the UA, and its height 296 AGL or above its take-off point; 298 4. the UA ground speed and route course measured clockwise from true 299 north; 301 5. the geographical position of the remote pilot, or if that is not 302 available, the geographical position of the UA take-off point; 303 and 305 6. for Classes C1, C2, C3, the UAS emergency status. 307 Under the [ASDRI] contemplated standard, data will be sent in plain 308 text and the UAS operator registration number will be represented as 309 a 16-byte string including the (European) state code. The 310 corresponding private ID part will contain 3 characters that are not 311 broadcast but used by authorities to access regional registration 312 databases for verification. 314 ASD-STAN also contemplates corresponding Network Remote 315 Identification (NRI) functionality. The ASD-STAN RID target is to 316 revise their current standard with additional functionality (e.g., 317 DRIP) to be published before 2022 [ASDRI]. 319 Security oriented UAS RID essentially has two goals: enable the 320 general public to obtain and record an opaque ID for any observed UA, 321 which they can then report to authorities; enable authorities, from 322 such an ID, to look up information about the UAS and its operator. 323 Safety oriented UAS RID has stronger requirements. Aviation 324 community Standards Development Organizations (SDOs) set a higher bar 325 for safety than for security, especially with respect to reliability. 327 Although dynamic establishment of secure communications between the 328 Observer and the UAS pilot seems to have been contemplated by the FAA 329 UAS ID and Tracking Aviation Rulemaking Committee (ARC) in their 330 [Recommendations], it is not addressed in any of the 331 subsequent regulations or international SDO technical specifications, 332 other than DRIP, known to the authors as of early 2021. 334 1.2. Concerns and Constraints 336 Disambiguation of multiple UA flying in close proximity may be very 337 challenging, even if each is reporting its identity, position, and 338 velocity as accurately as it can. 340 The origin of information in UAS RID and UAS Traffic Management (UTM) 341 generally is the UAS or its operator. Self-reports may be initiated 342 by the remote pilot at the console of the Ground Control Station 343 (GCS, the UAS subsystem used to remotely operate the UA), or 344 automatically by GCS software; in Broadcast RID, they typically would 345 be initiated automatically by a process on the UA. Data in the 346 reports may come from sensors available to the operator (e.g., radar 347 or cameras), the GCS (e.g., "dead reckoning" UA location, starting 348 from the takeoff location and estimating the displacements due to 349 subsequent piloting commands, wind, etc.), or the UA itself (e.g., an 350 on-board GNSS receiver); in Broadcast RID, all the data must be sent 351 proximately by, and most of the data comes ultimately from, the UA 352 itself. Whether information comes proximately from the operator, or 353 from automated systems configured by the operator, there are 354 possibilities not only of unintentional error in but also of 355 intentional falsification of this data. 357 Minimal specified information must be made available to the public. 358 Access to other data, e.g., UAS operator Personally Identifiable 359 Information (PII), must be limited to strongly authenticated 360 personnel, properly authorized in accordance with applicable policy. 361 The balance between privacy and transparency remains a subject for 362 public debate and regulatory action; DRIP can only offer tools to 363 expand the achievable trade space and enable trade-offs within that 364 space. [F3411-19], the basis for most current (2021) thinking about 365 and efforts to provide UAS RID, specifies only how to get the UAS ID 366 to the Observer: how the Observer can perform these lookups and how 367 the registries first can be populated with information are 368 unspecified therein. 370 The need for nearly universal deployment of UAS RID is pressing: 371 consider how negligible the value of an automobile license plate 372 system would be if only 90% of the cars displayed plates. This 373 implies the need to support use by Observers of already ubiquitous 374 mobile devices (typically smartphones and tablets). Anticipating 375 Civil Aviation Authority (CAA) requirements to support legacy 376 devices, especially in light of [Recommendations], [F3411-19] 377 specifies that any UAS sending Broadcast RID over Bluetooth must do 378 so over Bluetooth 4, regardless of whether it also does so over newer 379 versions; as UAS sender devices and Observer receiver devices are 380 unpaired, this implies extremely short "advertisement" (beacon) 381 frames. 383 Wireless data links to or from UA are challenging. Flight is often 384 amidst structures and foliage at low altitudes over varied terrain. 385 UA are constrained in both total energy and instantaneous power by 386 their batteries. Small UA imply small antennas. Densely populated 387 volumes will suffer from link congestion: even if UA in an airspace 388 volume are few, other transmitters nearby on the ground, sharing the 389 same license free spectral band, may be many. Thus air to air and 390 air to ground links will generally be slow and unreliable. 392 UAS Cost, Size, Weight, and Power (CSWaP) constraints are severe. 393 CSWaP is a burden not only on the designers of new UAS for sale, but 394 also on owners of existing UAS that must be retrofit. Radio 395 Controlled (RC) aircraft modelers, "hams" who use licensed amateur 396 radio frequencies to control UAS, drone hobbyists, and others who 397 custom build UAS, all need means of participating in UAS RID, 398 sensitive to both generic CSWaP and application-specific 399 considerations. 401 To accommodate the most severely constrained cases, all these 402 conspire to motivate system design decisions that complicate the 403 protocol design problem. 405 Broadcast RID uses one-way local data links. UAS may have Internet 406 connectivity only intermittently, or not at all, during flight. 408 Internet-disconnected operation of Observer devices has been deemed 409 by ASTM F38.02 too infrequent to address. However, the preamble to 410 [FRUR] cites "remote and rural areas that do not have reliable 411 Internet access" as a major reason for requiring Broadcast rather 412 than Network RID, and states that "Personal wireless devices that are 413 capable of receiving 47 CFR part 15 frequencies, such as smart 414 phones, tablets, or other similar commercially available devices, 415 will be able to receive broadcast remote identification information 416 directly without reliance on an Internet connection". Internet- 417 disconnected operation presents challenges, e.g., for Observers 418 needing access to the [F3411-19] web based Broadcast Authentication 419 Verifier Service or external lookups. 421 As RID must often operate within these constraints, heavyweight 422 cryptographic security protocols or even simple cryptographic 423 handshakes are infeasible, yet trustworthiness of UAS RID information 424 is essential. Under [F3411-19], _even the most basic datum, the UAS 425 ID itself, can be merely an unsubstantiated claim_. 427 Observer devices being ubiquitous, thus popular targets for malware 428 or other compromise, cannot be generally trusted (although the user 429 of each device is compelled to trust that device, to some extent); a 430 "fair witness" functionality (inspired by [Stranger]) is desirable. 432 Despite work by regulators and SDOs, there are substantial gaps in 433 UAS standards generally and UAS RID specifically. [Roadmap] catalogs 434 UAS related standards, ongoing standardization activities and gaps 435 (as of 2020); Section 7.8 catalogs those related specifically to UAS 436 RID. DRIP will address the most fundamental of these gaps, as 437 foreshadowed above. 439 1.3. DRIP Scope 441 DRIP's initial charter is to make RID immediately actionable, in both 442 Internet and local-only connected scenarios (especially emergencies), 443 in severely constrained UAS environments, balancing legitimate (e.g., 444 public safety) authorities' Need To Know trustworthy information with 445 UAS operators' privacy. By "immediately actionable" is meant 446 information of sufficient precision, accuracy, timeliness, etc. for 447 an Observer to use it as the basis for immediate decisive action, 448 whether that be to trigger a defensive counter-UAS system, to attempt 449 to initiate communications with the UAS operator, to accept the 450 presence of the UAS in the airspace where/when observed as not 451 requiring further action, or whatever, with potentially severe 452 consequences of any action or inaction chosen based on that 453 information. For further explanation of the concept of immediate 454 actionability, see [ENISACSIRT]. 456 Note that UAS RID must achieve nearly universal adoption, but DRIP 457 can add value even if only selectively deployed. Authorities with 458 jurisdiction over more sensitive airspace volumes may set a higher 459 than generally mandated RID requirement for flight in such volumes. 460 Those with a greater need for high-confidence IFF can equip with 461 DRIP, enabling strong authentication of their own aircraft and allied 462 operators without regard for the weaker (if any) authentication of 463 others. 465 DRIP (originally Trustworthy Multipurpose Remote Identification, TM- 466 RID) potentially could be applied to verifiably identify other types 467 of registered things reported to be in specified physical locations, 468 and providing timely trustworthy identification data is also 469 prerequisite to identity-oriented networking, but the urgent 470 motivation and clear initial focus is UAS. Existing Internet 471 resources (protocol standards, services, infrastructure, and business 472 models) should be leveraged. 474 1.4. Document Scope 476 This document describes the problem space for UAS RID conforming to 477 proposed regulations and external technical standards, defines common 478 terminology, specifies numbered requirements for DRIP, identifies 479 some important considerations (IANA, security, privacy and 480 transparency), and discusses limitations. 482 A natural Internet-based approach to meet these requirements is 483 described in a companion architecture document [drip-architecture] 484 and elaborated in other DRIP documents. 486 2. Terms and Definitions 488 2.1. Requirements Terminology 490 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 491 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 492 "OPTIONAL" in this document are to be interpreted as described in BCP 493 14 [RFC2119] [RFC8174] when, and only when, they appear in all 494 capitals, as shown here. 496 2.2. Definitions 498 This section defines a non-comprehensive set of terms expected to be 499 used in DRIP documents. This list is meant to be the DRIP 500 terminology reference; as such, some of the terms listed below are 501 not used in this document. 503 [RFC4949] provides a glossary of Internet security terms that should 504 be used where applicable. 506 In the UAS community, the plural form of acronyms generally is the 507 same as the singular form, e.g., Unmanned Aircraft System (singular) 508 and Unmanned Aircraft Systems (plural) are both represented as UAS. 509 On this and other terminological issues, to encourage comprehension 510 necessary for adoption of DRIP by the intended user community, that 511 community's norms are respected herein, and definitions are quoted in 512 cases where they have been found in that community's documents. Most 513 of the listed terms are from that community (even if specific source 514 documents are not cited); any that are DRIP-specific or invented by 515 the authors of this document are marked "(DRIP)". 517 4-D 518 Four-dimensional. Latitude, Longitude, Altitude, Time. Used 519 especially to delineate an airspace volume in which an operation 520 is being or will be conducted. 522 AAA 523 Attestation, Authentication, Authorization, Access Control, 524 Accounting, Attribution, Audit, or any subset thereof (uses differ 525 by application, author, and context). (DRIP) 527 ABDAA 528 AirBorne DAA. Accomplished using systems onboard the aircraft 529 involved. Supports "self-separation" (remaining "well clear" of 530 other aircraft) and collision avoidance. 532 ADS-B 533 Automatic Dependent Surveillance - Broadcast. "ADS-B Out" 534 equipment obtains aircraft position from other on-board systems 535 (typically GNSS) and periodically broadcasts it to "ADS-B In" 536 equipped entities, including other aircraft, ground stations, and 537 satellite based monitoring systems. 539 AGL 540 Above Ground Level. Relative altitude, above the variously 541 defined local ground level, typically of a UA, measured in feet or 542 meters. Should be explicitly specified as either barometric 543 (pressure) or geodetic (GNSS) altitude. 545 ATC 546 Air Traffic Control. Explicit flight direction to pilots from 547 ground controllers. Contrast with ATM. 549 ATM 550 Air Traffic Management. A broader functional and geographic scope 551 and/or a higher layer of abstraction than ATC. "The dynamic, 552 integrated management of air traffic and airspace including air 553 traffic services, airspace management and air traffic flow 554 management - safely, economically and efficiently - through the 555 provision of facilities and seamless services in collaboration 556 with all parties and involving airborne and ground-based 557 functions" [ICAOATM]. 559 Authentication Message 560 [F3411-19] Message Type 2. Provides framing for authentication 561 data, only; the only message that can be extended in length by 562 segmenting it across more than one page. 564 Basic ID Message 565 [F3411-19] Message Type 0. Provides UA Type, UAS ID Type, and UAS 566 ID, only. 568 Broadcast Authentication Verifier Service 569 System component designed to handle any authentication of 570 Broadcast RID by offloading signature verification to a web 571 service [F3411-19]. 573 BVLOS 574 Beyond Visual Line Of Sight. See VLOS. 576 byte 577 Used here in its now-customary sense as a synonym for "octet", as 578 "byte" is used exclusively in definitions of data structures 579 specified in [F3411-19] 581 CAA 582 Civil Aviation Authority of a regulatory jurisdiction. Often so 583 named, but other examples include the United States Federal 584 Aviation Administration (FAA) and the Japan Civil Aviation Bureau. 586 CSWaP 587 Cost, Size, Weight, and Power. 589 C2 590 Command and Control. Previously mostly used in military contexts. 591 Properly refers to a function, exercisable over arbitrary 592 communications; but in the small UAS context, often refers to the 593 communications (typically RF data link) over which the GCS 594 controls the UA. 596 DAA 597 Detect And Avoid, formerly Sense And Avoid (SAA). A means of 598 keeping aircraft "well clear" of each other and obstacles for 599 safety. "The capability to see, sense or detect conflicting 600 traffic or other hazards and take the appropriate action to comply 601 with the applicable rules of flight" [ICAOUAS]. 603 DRI (not to be confused with DRIP) 604 Direct Remote Identification. EU regulatory requirement for "a 605 system that ensures the local broadcast of information about a UA 606 in operation, including the marking of the UA, so that this 607 information can be obtained without physical access to the UA". 608 [Delegated] that presumably can be satisfied with appropriately 609 configured [F3411-19] Broadcast RID. 611 DSS 612 Discovery and Synchronization Service. The UTM system overlay 613 network backbone. Most importantly, it enables one USS to learn 614 which other USS have UAS operating in a given 4-D airspace volume, 615 for strategic deconfliction of planned operations and Network RID 616 surveillance of active operations. [F3411-19] 618 EUROCAE 619 European Organisation for Civil Aviation Equipment. Aviation SDO, 620 originally European, now with broader membership. Cooperates 621 extensively with RTCA. 623 GBDAA 624 Ground Based DAA. Accomplished with the aid of ground based 625 functions. 627 GCS 628 Ground Control Station. The part of the UAS that the remote pilot 629 uses to exercise C2 over the UA, whether by remotely exercising UA 630 flight controls to fly the UA, by setting GNSS waypoints, or 631 otherwise directing its flight. 633 GNSS 634 Global Navigation Satellite System. Satellite based timing and/or 635 positioning with global coverage, often used to support 636 navigation. 638 GPS 639 Global Positioning System. A specific GNSS, but in the UAS 640 context, the term is typically misused in place of the more 641 generic term GNSS. 643 GRAIN 644 Global Resilient Aviation Interoperable Network. ICAO managed 645 IPv6 overlay internetwork based on IATF, dedicated to aviation 646 (but not just aircraft). Currently (2021) in design, 647 accommodating the proposed DRIP identifier. 649 IATF 650 International Aviation Trust Framework. ICAO effort to develop a 651 resilient and secure by design framework for networking in support 652 of all aspects of aviation. 654 ICAO 655 International Civil Aviation Organization. A United Nations 656 specialized agency that develops and harmonizes international 657 standards relating to aviation. 659 IFF 660 Identification Friend or Foe. Originally, and in its narrow sense 661 still, a self-identification broadcast in response to 662 interrogation via radar, to reduce friendly fire incidents, which 663 led to military and commercial transponder systems such as ADS-B. 664 In the broader sense used here, any process intended to 665 distinguish friendly from potentially hostile UA or other entities 666 encountered. 668 LAANC 669 Low Altitude Authorization and Notification Capability. Supports 670 ATC authorization requirements for UAS operations: remote pilots 671 can apply to receive a near real-time authorization for operations 672 under 400 feet in controlled airspace near airports. FAA 673 authorized partial stopgap in the US until UTM comes. 675 Location/Vector Message 676 [F3411-19] Message Type 1. Provides UA location, altitude, 677 heading, speed, and status. 679 LOS 680 Line Of Sight. An adjectival phrase describing any information 681 transfer that travels in a nearly straight line (e.g., 682 electromagnetic energy, whether in the visual light, RF, or other 683 frequency range) and is subject to blockage. A term to be avoided 684 due to ambiguity, in this context, between RF LOS and VLOS. 686 Message Pack 687 [F3411-19] Message Type 15. The framed concatenation, in message 688 type index order, of at most one message of each type of any 689 subset of the other types. Required to be sent in Wi-Fi NAN and 690 in Bluetooth 5 Extended Advertisements, if those media are used; 691 cannot be sent in Bluetooth 4. 693 MSL 694 Mean Sea Level. Shorthand for relative altitude, above the 695 variously defined mean sea level, typically of a UA (but in [FRUR] 696 also for a GCS), measured in feet or meters. Should be explicitly 697 specified as either barometric (pressure) or geodetic (e.g., as 698 indicated by GNSS, referenced to the WGS84 ellipsoid). 700 Net-RID DP 701 Network RID Display Provider. [F3411-19] logical entity that 702 aggregates data from Net-RID SPs as needed in response to user 703 queries regarding UAS operating within specified airspace volumes, 704 to enable display by a user application on a user device. 705 Potentially could provide not only information sent via UAS RID 706 but also information retrieved from UAS RID registries or 707 information beyond UAS RID. Under superseded [NPRM], not 708 recognized as a distinct entity, but a service provided by USS, 709 including Public Safety USS that may exist primarily for this 710 purpose rather than to manage any subscribed UAS. 712 Net-RID SP 713 Network RID Service Provider. [F3411-19] logical entity that 714 collects RID messages from UAS and responds to NetRID-DP queries 715 for information on UAS of which it is aware. Under superseded 716 [NPRM], the USS to which the UAS is subscribed ("Remote ID USS"). 718 Network Identification Service 719 EU regulatory requirement in [Opinion1] and [WG105] that 720 presumably can be satisfied with appropriately configured 721 [F3411-19] Network RID. 723 Observer 724 An entity (typically but not necessarily an individual human) who 725 has directly or indirectly observed a UA and wishes to know 726 something about it, starting with its ID. An Observer typically 727 is on the ground and local (within VLOS of an observed UA), but 728 could be remote (observing via Network RID or other surveillance), 729 operating another UA, aboard another aircraft, etc. (DRIP) 731 Operation 732 A flight, or series of flights of the same mission, by the same 733 UAS, separated by at most brief ground intervals. (Inferred from 734 UTM usage, no formal definition found) 736 Operator 737 "A person, organization or enterprise engaged in or offering to 738 engage in an aircraft operation" [ICAOUAS]. 740 Operator ID Message 741 [F3411-19] Message Type 5. Provides CAA issued Operator ID, only. 742 Operator ID is distinct from UAS ID. 744 page 745 Payload of a frame, containing a chunk of a message that has been 746 segmented, to allow transport of a message longer than can be 747 encapsulated in a single frame. [F3411-19] 749 PIC 750 Pilot In Command. "The pilot designated by the operator, or in 751 the case of general aviation, the owner, as being in command and 752 charged with the safe conduct of a flight" [ICAOUAS]. 754 PII 755 Personally Identifiable Information. In the UAS RID context, 756 typically of the UAS Operator, Pilot In Command (PIC), or Remote 757 Pilot, but possibly of an Observer or other party. This specific 758 term is used primarily in the US; other terms with essentially the 759 same meaning are more common in other jurisdictions (e.g., 760 "personal data" in the EU). Used herein generically to refer to 761 personal information, which the person might wish to keep private, 762 or may have a statutorily recognized right to keep private (e.g., 763 under the EU [GDPR]), potentially imposing (legally or ethically) 764 a confidentiality requirement on protocols/systems. 766 Remote Pilot 767 A pilot using a GCS to exercise proximate control of a UA. Either 768 the PIC or under the supervision of the PIC. "The person who 769 manipulates the flight controls of a remotely-piloted aircraft 770 during flight time" [ICAOUAS]. 772 RF 773 Radio Frequency. Adjective, e.g., "RF link", or noun. 775 RF LOS 776 RF Line Of Sight. Typically used in describing a direct radio 777 link between a GCS and the UA under its control, potentially 778 subject to blockage by foliage, structures, terrain, or other 779 vehicles, but less so than VLOS. 781 RTCA 782 Radio Technical Commission for Aeronautics. US aviation SDO. 783 Cooperates extensively with EUROCAE. 785 Safety 786 "The state in which risks associated with aviation activities, 787 related to, or in direct support of the operation of aircraft, are 788 reduced and controlled to an acceptable level." From Annex 19 of 789 the Chicago Convention, quoted in [ICAODEFS] 791 Security 792 "Safeguarding civil aviation against acts of unlawful 793 interference." From Annex 17 of the Chicago Convention, quoted in 794 [ICAODEFS] 796 Self-ID Message 797 [F3411-19] Message Type 3. Provides a 1 byte descriptor and 23 798 byte ASCII free text field, only. Expected to be used to provide 799 context on the operation, e.g., mission intent. 801 SDO 802 Standards Development Organization. ASTM, IETF, et al. 804 SDSP 805 Supplemental Data Service Provider. An entity that participates 806 in the UTM system, but provides services beyond those specified as 807 basic UTM system functions (e.g., weather data). [FAACONOPS] 809 System Message 810 [F3411-19] Message Type 4. Provides general UAS information, 811 including remote pilot location, multiple UA group operational 812 area, etc. 814 U-space 815 EU concept and emerging framework for integration of UAS into all 816 classes of airspace, specifically including high density urban 817 areas, sharing airspace with manned aircraft [InitialView]. 819 UA 820 Unmanned Aircraft. In popular parlance, "drone". "An aircraft 821 which is intended to operate with no pilot on board" [ICAOUAS]. 823 UAS 824 Unmanned Aircraft System. Composed of UA, all required on-board 825 subsystems, payload, control station, other required off-board 826 subsystems, any required launch and recovery equipment, all 827 required crew members, and C2 links between UA and control station 828 [F3411-19]. 830 UAS ID 831 UAS identifier. Although called "UAS ID", it is actually unique 832 to the UA, neither to the operator (as some UAS registration 833 numbers have been and for exclusively recreational purposes are 834 continuing to be assigned), nor to the combination of GCS and UA 835 that comprise the UAS. _Maximum length of 20 bytes_ [F3411-19]. 837 UAS ID Type 838 UAS Identifier type index. 4 bits, see Section 3, Paragraph 6 for 839 currently defined values 0-3. [F3411-19] 841 UAS RID 842 UAS Remote Identification and tracking. System to enable 843 arbitrary Observers to identify UA during flight. 845 USS 846 UAS Service Supplier. "A USS is an entity that assists UAS 847 Operators with meeting UTM operational requirements that enable 848 safe and efficient use of airspace" and "... provide services to 849 support the UAS community, to connect Operators and other entities 850 to enable information flow across the USS Network, and to promote 851 shared situational awareness among UTM participants" [FAACONOPS]. 853 UTM 854 UAS Traffic Management. "A specific aspect of air traffic 855 management which manages UAS operations safely, economically and 856 efficiently through the provision of facilities and a seamless set 857 of services in collaboration with all parties and involving 858 airborne and ground-based functions" [ICAOUTM]. In the US, 859 according to the FAA, a "traffic management" ecosystem for 860 "uncontrolled" low altitude UAS operations, separate from, but 861 complementary to, the FAA's ATC system for "controlled" operations 862 of manned aircraft. 864 V2V 865 Vehicle-to-Vehicle. Originally communications between 866 automobiles, now extended to apply to communications between 867 vehicles generally. Often, together with Vehicle-to- 868 Infrastructure (V2I) etc., generalized to V2X. 870 VLOS 871 Visual Line Of Sight. Typically used in describing operation of a 872 UA by a "remote" pilot who can clearly directly (without video 873 cameras or any aids other than glasses or under some rules 874 binoculars) see the UA and its immediate flight environment. 875 Potentially subject to blockage by foliage, structures, terrain, 876 or other vehicles, more so than RF LOS. 878 3. UAS RID Problem Space 880 CAAs worldwide are mandating UAS RID. The European Union Aviation 881 Safety Agency (EASA) has published [Delegated] and [Implementing] 882 Regulations. The US FAA has published a "final" rule [FRUR] and has 883 described the key role that UAS RID plays in UAS Traffic Management 884 (UTM) in [FAACONOPS] (especially Section 2.6). CAAs currently (2021) 885 promulgate performance-based regulations that do not specify 886 techniques, but rather cite industry consensus technical standards as 887 acceptable means of compliance. 889 The most widely cited such industry consensus technical standard for 890 UAS RID is [F3411-19], which defines two means of UAS RID: 892 Network RID defines a set of information for UAS to make available 893 globally indirectly via the Internet, through servers that can be 894 queried by Observers. 896 Broadcast RID defines a set of messages for UA to transmit locally 897 directly one-way over Bluetooth or Wi-Fi (without IP or any other 898 protocols between the data link and application layers), to be 899 received in real time by local Observers. 901 UAS using both means must send the same UAS RID application layer 902 information via each [F3411-19]. The presentation may differ, as 903 Network RID defines a data dictionary, whereas Broadcast RID defines 904 message formats (which carry items from that same data dictionary). 905 The interval (or rate) at which it is sent may differ, as Network RID 906 can accommodate Observer queries asynchronous to UAS updates (which 907 generally need be sent only when information, such as location, 908 changes), whereas Broadcast RID depends upon Observers receiving UA 909 messages at the time they are transmitted. 911 Network RID depends upon Internet connectivity in several segments 912 from the UAS to each Observer. Broadcast RID should need Internet 913 (or other Wide Area Network) connectivity only to retrieve UAS 914 registry information using the directly locally received UAS 915 Identifier (UAS ID) as the primary unique key for database lookup. 916 Broadcast RID does not assume IP connectivity of UAS; messages are 917 encapsulated by the UA _without IP_, directly in link layer frames 918 (Bluetooth 4, Bluetooth 5, Wi-Fi NAN, IEEE 802.11 Beacon, or in the 919 future perhaps others). 921 [F3411-19] specifies three UAS ID Type values: 923 1 A static, manufacturer assigned, hardware serial number as defined 924 in ANSI/CTA-2063-A "Small Unmanned Aerial System Serial Numbers" 925 [CTA2063A]. 927 2 A CAA assigned (generally static) ID, like the registration number 928 of a manned aircraft. 930 3 A UTM system assigned UUID [RFC4122], which can but need not be 931 dynamic. 933 Per [Delegated], the EU allows only UAS ID Type 1. Under [FRUR], the 934 US allows types 1 and 3. [NPRM] proposed that a type 3 "Session ID" 935 would be "e.g., a randomly-generated alphanumeric code assigned by a 936 Remote ID UAS Service Supplier (USS) on a per-flight basis designed 937 to provide additional privacy to the operator", but given the 938 omission of Network RID from [FRUR], how this is to be assigned in 939 the US is still to be determined. 941 As yet apparently there are no CAA public proposals to use UAS ID 942 Type 2. In the preamble of [FRUR], the FAA argues that registration 943 numbers should not be sent in RID, insists that the capability of 944 looking up registration numbers from information contained in RID 945 should be restricted to FAA and other Government agencies, and 946 implies that Session ID would be linked to the registration number 947 only indirectly via the serial number in the registration database. 948 The possibility of cryptographically blinding registration numbers, 949 such that they can be revealed under specified circumstances, does 950 not appear to be mentioned in applicable regulations or external 951 technical standards. 953 Under [Delegated], the EU also requires an operator registration 954 number (an additional identifier distinct from the UAS ID) that can 955 be carried in an [F3411-19] optional Operator ID message. 957 [FRUR] allows RID requirements to be met by either the UA itself, 958 which is then designated a "standard remote identification unmanned 959 aircraft", or by an add-on "remote identification broadcast module". 960 Relative to a standard RID UA, the different requirements for a 961 module are that the latter: must transmit its own serial number 962 (neither the serial number of the UA to which it is attached, nor a 963 Session ID); must transmit takeoff location as a proxy for the 964 location of the pilot/GCS; need not transmit UA emergency status; and 965 is allowed to be used only for operations within VLOS of the remote 966 pilot. 968 Jurisdictions may relax or waive RID requirements for certain 969 operators and/or under certain conditions. For example, [FRUR] 970 allows operators with UAS not equipped for RID to conduct VLOS 971 operations at counter-intuitively named "FAA-recognized 972 identification areas" (FRIA); radio controlled model aircraft flying 973 clubs and other eligible organizations can apply to the FAA for such 974 recognition of their operating areas. 976 3.1. Network RID 977 x x UA 978 xxxxxxx 979 | \ 980 | \ 981 | \ 982 | \ ******************** 983 | \* ------*---+------------+ 984 | *\ / * | NET-Rid SP | 985 | * ------------/ +---*--+------------+ 986 | RF */ | * 987 | / INTERNET | * +------------+ 988 | /* +---*--| NET-Rid DP | 989 | / * +----*--+------------+ 990 + / * | * 991 x / ****************|*** x 992 xxxxx | xxxxx 993 x +------- x 994 x x 995 x x Operator's GCS Observer x x 996 x x x x 998 Figure 3: "Network RID Information Flow" 1000 Figure 3 illustrates Network RID information flows. Only two of the 1001 three typically wireless links shown involving the UAS (UA-GCS, UA- 1002 Internet, and GCS-Internet) need exist. All three may exist, at the 1003 same or different times, especially in Beyond Visual Line Of Sight 1004 (BVLOS) operations. There must be some information flow path (direct 1005 or indirect) between the GCS and the UA, for the former to exercise 1006 C2 over the latter. If this path is two-way (as increasingly it is, 1007 even for inexpensive small UAS), the UA will also send its status 1008 (and position, if suitably equipped, e.g., with GNSS) to the GCS. 1009 There also must be some path between at least one subsystem of the 1010 UAS (UA or GCS) and the Internet, for the former to send status and 1011 position updates to its USS (serving _inter alia_ as a Net-RID SP). 1013 Direct UA-Internet wireless links are expected to become more common, 1014 especially on larger UAS, but currently (2021) are rare. Instead, 1015 the RID data flow typically originates on the UA and passes through 1016 the GCS, or originates on the GCS. Network RID data makes three 1017 trips through the Internet (GCS-SP, SP-DP, DP-Observer, unless any of 1018 them are colocated), implying use of IP (and other middle layer 1019 protocols, e.g., TLS/TCP or DTLS/UDP) on those trips. IP is not 1020 necessarily used or supported on the UA-GCS link (if indeed that 1021 direct link exists, as it typically does now, but in BVLOS operations 1022 often will not). 1024 Network RID is publish-subscribe-query. In the UTM context: 1026 1. The UAS operator pushes an "operational intent" (the current term 1027 in UTM corresponding to a flight plan in manned aviation) to the 1028 USS (call it USS#1) that will serve that UAS (call it UAS#1) for 1029 that operation, primarily to enable deconfliction with other 1030 operations potentially impinging upon that operation's 4-D 1031 airspace volume (call it Volume#1). 1033 2. Assuming the operation is approved and commences, UAS#1 1034 periodically pushes location/status updates to USS#1, which 1035 serves _inter alia_ as the Network RID Service Provider (Net-RID 1036 SP) for that operation. 1038 3. When users of any other USS (whether they be other UAS operators 1039 or Observers) develop an interest in any 4-D airspace volume 1040 (e.g., because they wish to submit an operational intent or 1041 because they have observed a UA), they query their own USS on the 1042 volumes in which they are interested. 1044 4. Their USS query, via the UTM Discovery and Synchronization 1045 Service (DSS), all other USS in the UTM system, and learn of any 1046 USS that have operations in those volumes (including any volumes 1047 intersecting them); thus those USS whose query volumes intersect 1048 Volume#1 (call them USS#2 through USS#n) learn that USS#1 has 1049 such operations. 1051 5. Interested parties can then subscribe to track updates on that 1052 operation of UAS#1, via their own USS, which serve as Network RID 1053 Display Providers (Net-RID DP) for that operation. 1055 6. USS#1 (as Net-RID SP) will then publish updates of UAS#1 status 1056 and position to all other subscribed USS in USS#2 through USS#n 1057 (as Net-RID DP). 1059 7. All Net-RID DP subscribed to that operation of UAS#1 will deliver 1060 its track information to their users who subscribed to that 1061 operation of UAS#1 (via means unspecified by [F3411-19] etc., but 1062 generally presumed to be web browser based). 1064 Network RID has several connectivity scenarios: 1066 _Persistently Internet connected UA_ can consistently directly 1067 source RID information; this requires wireless coverage throughout 1068 the intended operational airspace volume, plus a buffer (e.g., 1069 winds may drive the UA out of the volume). 1071 _Intermittently Internet connected UA_, can usually directly 1072 source RID information, but when offline (e.g., due to signal 1073 blockage by a large structure being inspected using the UAS), need 1074 the GCS to proxy source RID information. 1076 _Indirectly connected UA_ lack the ability to send IP packets that 1077 will be forwarded into and across the Internet, but instead have 1078 some other form of communications to another node that can relay 1079 or proxy RID information to the Internet; typically this node 1080 would be the GCS (which to perform its function must know where 1081 the UA is, although C2 link outages do occur). 1083 _Non-connected UA_ have no means of sourcing RID information, in 1084 which case the GCS or some other interface available to the 1085 operator must source it. In the extreme case, this could be the 1086 pilot or other agent of the operator using a web browser/ 1087 application to designate, to a USS or other UTM entity, a time- 1088 bounded airspace volume in which an operation will be conducted. 1089 This is referred to as a "non-equipped network participant" 1090 engaging in "area operations". This may impede disambiguation of 1091 ID if multiple UAS operate in the same or overlapping 4-D volumes. 1092 In most airspace volumes, most classes of UA will not be permitted 1093 to fly if non-connected. 1095 In most cases in the near term (2021), the Network RID first hop data 1096 link is likely to be cellular, which can also support BVLOS C2 over 1097 existing large coverage areas, or Wi-Fi, which can also support 1098 Broadcast RID. However, provided the data link can support at least 1099 UDP/IP and ideally also TCP/IP, its type is generally immaterial to 1100 higher layer protocols. The UAS, as the ultimate source of Network 1101 RID information, feeds a Net-RID SP (typically the USS to which the 1102 UAS operator subscribes), which proxies for the UAS and other data 1103 sources. An Observer or other ultimate consumer of Network RID 1104 information obtains it from a Net-RID DP (also typically a USS), 1105 which aggregates information from multiple Net-RID SPs to offer 1106 airspace Situational Awareness (SA) coverage of a volume of interest. 1107 Network RID Service and Display providers are expected to be 1108 implemented as servers in well-connected infrastructure, 1109 communicating with each other via the Internet, and accessible by 1110 Observers via means such as web Application Programming Interfaces 1111 (APIs) and browsers. 1113 Network RID is the less constrained of the defined UAS RID means. 1114 [F3411-19] specifies only Net-RID SP to Net-RID DP information 1115 exchanges. It is presumed that IETF efforts supporting the more 1116 constrained Broadcast RID (see next section) can be generalized for 1117 Network RID and potentially also for UAS to USS or other UTM 1118 communications. 1120 3.2. Broadcast RID 1122 x x UA 1123 xxxxx 1124 | 1125 | 1126 | app messages directly over one-way RF data link 1127 | 1128 | 1129 + 1130 x 1131 xxxxx 1132 x 1133 x 1134 x x Observer's device (e.g., smartphone) 1135 x x 1137 Figure 4: "Broadcast RID Information Flow" 1139 Figure 4 illustrates Broadcast RID information flow. Note the 1140 absence of the Internet from the figure. This is because Broadcast 1141 RID is one-way direct transmission of application layer messages over 1142 a RF data link (without IP) from the UA to local Observer devices. 1143 Internet connectivity is involved only in what the Observer chooses 1144 to do with the information received, such as verify signatures using 1145 a web-based Broadcast Authentication Verifier Service and look up 1146 information in registries using the UAS ID as the primary unique key. 1148 Broadcast RID is conceptually similar to Automatic Dependent 1149 Surveillance - Broadcast (ADS-B). However, for various technical and 1150 other reasons, regulators including the EASA have not indicated 1151 intent to allow, and FAA has explicitly prohibited, use of ADS-B for 1152 UAS RID. 1154 [F3411-19] specifies four Broadcast RID data links: Bluetooth 4.x, 1155 Bluetooth 5.x with Extended Advertisements and Long Range Coded PHY 1156 (S=8), Wi-Fi NAN at 2.4 GHz, and Wi-Fi NAN at 5 GHz. A UA must 1157 broadcast (using advertisement mechanisms where no other option 1158 supports broadcast) on at least one of these. If sending on 1159 Bluetooth 5.x, it is also required concurrently to do so on 4.x 1160 (referred to in [F3411-19] as Bluetooth Legacy); current (2021) 1161 discussions in ASTM F38.02 on revising the standard, motivated by 1162 European standards drafts, suggest that both Bluetooth versions will 1163 be required. If broadcasting Wi-Fi NAN at 5 GHz, it is also required 1164 concurrently to do so at 2.4 GHz; current discussions in F38.02 1165 include relaxing this. Wi-Fi Beacons are also under consideration. 1166 Future revisions of [F3411-19] may allow other data links. 1168 The selection of the Broadcast media was driven by research into what 1169 is commonly available on 'ground' units (smartphones and tablets) and 1170 what was found as prevalent or 'affordable' in UA. Further, there 1171 must be an API for the Observer's receiving application to have 1172 access to these messages. As yet only Bluetooth 4.x support is 1173 readily available, thus the current focus is on working within the 31 1174 byte payload limit of the Bluetooth 4.x "Broadcast Frame" transmitted 1175 as an "advertisement" on beacon channels. After overheads, this 1176 limits the RID message to 25 bytes and UAS ID string to a maximum 1177 length of 20 bytes. 1179 Length constraints also preclude a single Bluetooth 4.x frame 1180 carrying not only the UAS ID but also position, velocity, and other 1181 information that should be bound to the UAS ID, much less strong 1182 authentication data. Messages that cannot be encapsulated in a 1183 single frame (thus far, only the Authentication Message) must be 1184 segmented into message "pages" (in the terminology of [F3411-19]). 1185 Message pages must somehow be correlated as belonging to the same 1186 message. Messages carrying position, velocity and other data must 1187 somehow be correlated with the Basic ID message that carries the UAS 1188 ID. This correlation is expected to be done on the basis of MAC 1189 address: this may be complicated by MAC address randomization; not 1190 all the common devices expected to be used by Observers have APIs 1191 that make sender MAC addresses available to user space receiver 1192 applications; and MAC addresses are easily spoofed. Data elements 1193 are not so detached on other media (see Message Pack in the paragraph 1194 after next). 1196 [F3411-19] Broadcast RID specifies several message types. The 4 bit 1197 message type field in the header can index up to 16 types. Only 7 1198 are currently defined. Only 2 are mandatory. All others are 1199 optional, unless required by a jurisdictional authority, e.g., a CAA. 1200 To satisfy both EASA and FAA rules, all types are needed, except 1201 Self-ID and Authentication, as the data elements required by the 1202 rules are scattered across several message types (along with some 1203 data elements not required by the rules). 1205 The Message Pack (type 0xF) is not actually a message, but the framed 1206 concatenation of at most one message of each type of any subset of 1207 the other types, in type index order. Some of the messages that it 1208 can encapsulate are mandatory, others optional. The Message Pack 1209 itself is mandatory on data links that can encapsulate it in a single 1210 frame (Bluetooth 5.x and Wi-Fi). 1212 +-----------------------+-----------------+-----------+-----------+ 1213 | Index | Name | Req | Notes | 1214 +-----------------------+-----------------+-----------+-----------+ 1215 | 0x0 | Basic ID | Mandatory | - | 1216 +-----------------------+-----------------+-----------+-----------+ 1217 | 0x1 | Location/Vector | Mandatory | - | 1218 +-----------------------+-----------------+-----------+-----------+ 1219 | 0x2 | Authentication | Optional | paged | 1220 +-----------------------+-----------------+-----------+-----------+ 1221 | 0x3 | Self-ID | Optional | free text | 1222 +-----------------------+-----------------+-----------+-----------+ 1223 | 0x4 | System | Optional | - | 1224 +-----------------------+-----------------+-----------+-----------+ 1225 | 0x5 | Operator | Optional | - | 1226 +-----------------------+-----------------+-----------+-----------+ 1227 | 0xF | Message Pack | - | BT5 and | 1228 | | | | Wi-Fi | 1229 +-----------------------+-----------------+-----------+-----------+ 1230 | See Section 5.4.5 and | - | - | - | 1231 | Table 3 of [F3411-19] | | | | 1232 +-----------------------+-----------------+-----------+-----------+ 1234 Table 1: F3411-19 Message Types 1236 [F3411-19] Broadcast RID specifies very few quantitative performance 1237 requirements: static information must be transmitted at least once 1238 per 3 seconds; dynamic information (the Location/Vector message) must 1239 be transmitted at least once per second and be no older than one 1240 second when sent. [FRUR] requires all information be sent at least 1241 once per second. 1243 [F3411-19] Broadcast RID transmits all information as cleartext 1244 (ASCII or binary), so static IDs enable trivial correlation of 1245 patterns of use, unacceptable in many applications, e.g., package 1246 delivery routes of competitors. 1248 Any UA can assert any ID using the [F3411-19] required Basic ID 1249 message, which lacks any provisions for verification. The Position/ 1250 Vector message likewise lacks provisions for verification, and does 1251 not contain the ID, so must be correlated somehow with a Basic ID 1252 message: the developers of [F3411-19] have suggested using the MAC 1253 addresses on the Broadcast RID data link, but these may be randomized 1254 by the operating system stack to avoid the adversarial correlation 1255 problems of static identifiers. 1257 The [F3411-19] optional Authentication Message specifies framing for 1258 authentication data, but does not specify any authentication method, 1259 and the maximum length of the specified framing is too short for 1260 conventional digital signatures and far too short for conventional 1261 certificates (e.g., X.509). Fetching certificates via the Internet 1262 is not always possible (e.g., Observers working in remote areas, such 1263 as national forests), so devising a scheme whereby certificates can 1264 be transported over Broadcast RID is necessary. The one-way nature 1265 of Broadcast RID precludes challenge-response security protocols 1266 (e.g., Observers sending nonces to UA, to be returned in signed 1267 messages). Without DRIP extensions to [F3411-19], an Observer would 1268 be seriously challenged to validate the asserted UAS ID or any other 1269 information about the UAS or its operator looked up therefrom. 1271 3.3. USS in UTM and RID 1273 UAS RID and UTM are complementary; Network RID is a UTM service. The 1274 backbone of the UTM system is comprised of multiple USS: one or 1275 several per jurisdiction; some limited to a single jurisdiction, 1276 others spanning multiple jurisdictions. USS also serve as the 1277 principal or perhaps the sole interface for operators and UAS into 1278 the UTM environment. Each operator subscribes to at least one USS. 1279 Each UAS is registered by its operator in at least one USS. Each 1280 operational intent is submitted to one USS; if approved, that UAS and 1281 operator can commence that operation. During the operation, status 1282 and location of that UAS must be reported to that USS, which in turn 1283 provides information as needed about that operator, UAS, and 1284 operation into the UTM system and to Observers via Network RID. 1286 USS provide services not limited to Network RID; indeed, the primary 1287 USS function is deconfliction of airspace usage by different UAS and 1288 other (e.g., manned aircraft, rocket launch) operations. Most 1289 deconfliction involving a given operation is hoped to be completed 1290 prior to commencing that operation, and is called "strategic 1291 deconfliction". If that fails, "tactical deconfliction" comes into 1292 play; ABDAA may not involve USS, but GBDAA likely will. Dynamic 1293 constraints, formerly called UAS Volume Restrictions (UVR), can be 1294 necessitated by local emergencies, extreme weather, etc., specified 1295 by authorities on the ground, and propagated in UTM. 1297 No role for USS in Broadcast RID is currently specified by regulators 1298 or [F3411-19]. However, USS are likely to serve as registries (or 1299 perhaps registrars) for UAS (and perhaps operators); if so, USS will 1300 have a role in all forms of RID. Supplemental Data Service Providers 1301 (SDSP) are also likely to find roles, not only in UTM as such but 1302 also in enhancing UAS RID and related services. Whether USS, SDSP, 1303 etc. are involved or not, RID services, narrowly defined, provide 1304 regulator specified identification information; more broadly defined, 1305 RID services may leverage identification to facilitate related 1306 services or functions, likely beginning with V2X. 1308 3.4. DRIP Focus 1310 In addition to the gaps described above, there is a fundamental gap 1311 in almost all current or proposed regulations and technical standards 1312 for UAS RID. As noted above, ID is not an end in itself, but a 1313 means. Protocols specified in [F3411-19] etc. provide limited 1314 information potentially enabling, and no technical means for, an 1315 Observer to communicate with the pilot, e.g., to request further 1316 information on the UAS operation or exit from an airspace volume in 1317 an emergency. The System Message provides the location of the pilot/ 1318 GCS, so an Observer could physically go to the asserted location to 1319 look for the remote pilot; this is at best slow and may not be 1320 feasible. What if the pilot is on the opposite rim of a canyon, or 1321 there are multiple UAS operators to contact, whose GCS all lie in 1322 different directions from the Observer? An Observer with Internet 1323 connectivity and access privileges could look up operator PII in a 1324 registry, then call a phone number in hopes someone who can 1325 immediately influence the UAS operation will answer promptly during 1326 that operation; this is at best unreliable and may not be prudent. 1327 Should pilots be encouraged to answer phone calls while flying? 1328 Internet technologies can do much better than this. 1330 Thus complementing [F3411-19] with protocols enabling strong 1331 authentication, preserving operator privacy while enabling immediate 1332 use of information by authorized parties, is critical to achieve 1333 widespread adoption of a RID system supporting safe and secure 1334 operation of UAS. 1336 DRIP will focus on making information obtained via UAS RID 1337 immediately usable: 1339 1. by making it trustworthy (despite the severe constraints of 1340 Broadcast RID); 1342 2. by enabling verification that a UAS is registered for RID, and if 1343 so, in which registry (for classification of trusted operators on 1344 the basis of known registry vetting, even by Observers lacking 1345 Internet connectivity at observation time); 1347 3. by facilitating independent reports of UA aeronautical data 1348 (location, velocity, etc.) to confirm or refute the operator 1349 self-reports upon which UAS RID and UTM tracking are based; 1351 4. by enabling instant establishment, by authorized parties, of 1352 secure communications with the remote pilot. 1354 The foregoing considerations, beyond those addressed by baseline UAS 1355 RID standards such as [F3411-19], imply the following requirements 1356 for DRIP. 1358 4. Requirements 1360 The following requirements apply to DRIP as a set of related 1361 protocols, various subsets of which, in conjunction with other IETF 1362 and external technical standards, may suffice to comply with the 1363 regulations in any given jurisdiction or meet any given user need. 1364 It is not intended that each and every DRIP protocol alone satisfy 1365 each and every requirement. 1367 4.1. General 1369 GEN-1 Provable Ownership: DRIP MUST enable verification that the 1370 UAS ID asserted in the Basic ID message is that of the actual 1371 current sender of the message (i.e., the message is not a 1372 replay attack or other spoof, authenticating, e.g., by 1373 verifying an asymmetric cryptographic signature using a 1374 sender provided public key from which the asserted ID can be 1375 at least partially derived), even on an Observer device 1376 lacking Internet connectivity at the time of observation. 1378 GEN-2 Provable Binding: DRIP MUST enable binding all other 1379 [F3411-19] messages from the same actual current sender to 1380 the UAS ID asserted in the Basic ID message. 1382 GEN-3 Provable Registration: DRIP MUST enable verification that the 1383 UAS ID is in a registry and identification of which one, even 1384 on an Observer device lacking Internet connectivity at the 1385 time of observation; with UAS ID Type 3, the same sender may 1386 have multiple IDs, potentially in different registries, but 1387 each ID must clearly indicate in which registry it can be 1388 found. 1390 GEN-4 Readability: DRIP MUST enable information (regulation 1391 required elements, whether sent via UAS RID or looked up in 1392 registries) to be read and utilized by both humans and 1393 software. 1395 GEN-5 Gateway: DRIP MUST enable Broadcast RID to Network RID 1396 application layer gateways to stamp messages with precise 1397 date/time received and receiver location, then relay them to 1398 a network service (e.g., SDSP or distributed ledger). 1400 GEN-6 Finger: DRIP MUST enable dynamically establishing, with AAA, 1401 per policy, end-to-end strongly encrypted communications with 1402 the UAS RID sender and entities looked up from the UAS ID, 1403 including at least the remote pilot and USS. 1405 GEN-7 QoS: DRIP MUST enable policy based specification of 1406 performance and reliability parameters, such as maximum 1407 message transmission intervals and delivery latencies. 1409 GEN-8 Mobility: DRIP MUST support physical and logical mobility of 1410 UA, GCS and Observers. DRIP SHOULD support mobility of 1411 essentially all participating nodes (UA, GCS, Observers, Net- 1412 RID SP, Net-RID DP, Private Registry, SDSP, and potentially 1413 others as RID and UTM evolve). 1415 GEN-9 Multihoming: DRIP MUST support multihoming of UA and GCS, for 1416 make-before-break smooth handoff and resiliency against path/ 1417 link failure. DRIP SHOULD support multihoming of essentially 1418 all participating nodes. 1420 GEN-10 Multicast: DRIP SHOULD support multicast for efficient and 1421 flexible publish-subscribe notifications, e.g., of UAS 1422 reporting positions in designated airspace volumes. 1424 GEN-11 Management: DRIP SHOULD support monitoring of the health and 1425 coverage of Broadcast and Network RID services. 1427 Requirements imposed either by regulation or [F3411-19] are not 1428 reiterated here, but drive many of the numbered requirements listed 1429 here. The [FRUR] regulatory QoS requirement currently would be 1430 satisfied by ensuring information refresh rates of at least 1 Hertz, 1431 with latencies no greater than 1 second, at least 80% of the time, 1432 but these numbers may vary between jurisdictions and over time. So 1433 instead the DRIP QoS requirement is that performance, reliability, 1434 etc. parameters be user policy specifiable, which does not imply 1435 satisfiable in all cases, but (especially together with the 1436 management requirement) implies that when specifications are not met, 1437 appropriate parties are notified. 1439 The "provable ownership" requirement addresses the possibility that 1440 the actual sender is not the claimed sender (i.e., is a spoofer). 1441 The "provable binding" requirement addresses the MAC address 1442 correlation problem of [F3411-19] noted above. The "provable 1443 registration" requirement may impose burdens not only on the UAS 1444 sender and the Observer's receiver, but also on the registry; yet it 1445 cannot depend upon the Observer being able to contact the registry at 1446 the time of observing the UA. The "readability" requirement may 1447 involve machine assisted format conversions, e.g., from binary 1448 encodings. 1450 The "gateway" requirement is in pursuit of three objectives: (1) mark 1451 up a RID message with where and when it was actually received, which 1452 may agree or disagree with the self-report in the set of messages; 1453 (2) defend against replay attacks; and (3) support optional SDSP 1454 services such as multilateration, to complement UAS position self- 1455 reports with independent measurements. This is the only instance in 1456 which DRIP transports [F3411-19] messages; most of DRIP pertains to 1457 the authentication of such messages and identifiers carried in them. 1459 4.2. Identifier 1461 ID-1 Length: The DRIP entity identifier MUST NOT be longer than 20 1462 bytes, to fit in the UAS ID field of the Basic ID message of 1463 [F3411-19]. 1465 ID-2 Registry ID: The DRIP identifier MUST be sufficient to identify 1466 a registry in which the entity identified therewith is listed. 1468 ID-3 Entity ID: The DRIP identifier MUST be sufficient to enable 1469 lookups of other data associated with the entity identified 1470 therewith in that registry. 1472 ID-4 Uniqueness: The DRIP identifier MUST be unique within the 1473 applicable global identifier space from when it is first 1474 registered therein until it is explicitly de-registered 1475 therefrom (due to, e.g., expiration after a specified lifetime, 1476 revocation by the registry, or surrender by the operator). 1478 ID-5 Non-spoofability: The DRIP identifier MUST NOT be spoofable 1479 within the context of a minimal Remote ID broadcast message set 1480 (to be specified within DRIP to be sufficient collectively to 1481 prove sender ownership of the claimed identifier). 1483 ID-6 Unlinkability: The DRIP identifier MUST NOT facilitate 1484 adversarial correlation over multiple operations. If this is 1485 accomplished by limiting each identifier to a single use or 1486 brief period of usage, the DRIP identifier MUST support well- 1487 defined, scalable, timely registration methods. 1489 The DRIP identifier can refer to various entities. In the primary 1490 initial use case, the entity to be identified is the UA. Entities to 1491 be identified in other likely use cases include but are not limited 1492 to the operator, USS, and Observer. In all cases, the entity 1493 identified must own (have the exclusive capability to use, such that 1494 receivers can verify its ownership of) the identifier. 1496 The DRIP identifier can be used at various layers. In Broadcast RID, 1497 it would be used by the application running directly over the data 1498 link. In Network RID, it would be used by the application running 1499 over HTTPS (and possibly other protocols). In RID initiated V2X 1500 applications such as DAA and C2, it could be used between the network 1501 and transport layers (e.g., with HIP or DTLS). 1503 Registry ID (which registry the entity is in) and Entity ID (which 1504 entity it is, within that registry) are requirements on a single DRIP 1505 entity identifier, not separate (types of) ID. In the most common 1506 use case, the entity will be the UA, and the DRIP identifier will be 1507 the UAS ID; however, other entities may also benefit from having DRIP 1508 identifiers, so the entity type is not prescribed here. 1510 Whether a UAS ID is generated by the operator, GCS, UA, USS, 1511 registry, or some collaboration thereamong, is unspecified; however, 1512 there must be agreement on the UAS ID among these entities. 1514 4.3. Privacy 1516 PRIV-1 Confidential Handling: DRIP MUST enable confidential handling 1517 of private information (i.e., any and all information 1518 designated by neither cognizant authority nor the information 1519 owner as public, e.g., personal data). 1521 PRIV-2 Encrypted Transport: DRIP MUST enable selective strong 1522 encryption of private data in motion in such a manner that 1523 only authorized actors can recover it. If transport is via 1524 IP, then encryption MUST be end-to-end, at or above the IP 1525 layer. DRIP MUST NOT encrypt safety critical data to be 1526 transmitted over Broadcast RID in any situation where it is 1527 unlikely that local Observers authorized to access the 1528 plaintext will be able to decrypt it or obtain it from a 1529 service able to decrypt it. DRIP MUST NOT encrypt data when/ 1530 where doing so would conflict with applicable regulations or 1531 CAA policies/procedures, i.e., DRIP MUST support configurable 1532 disabling of encryption. 1534 PRIV-3 Encrypted Storage: DRIP SHOULD facilitate selective strong 1535 encryption of private data at rest in such a manner that only 1536 authorized actors can recover it. 1538 PRIV-4 Public/Private Designation: DRIP SHOULD facilitate 1539 designation, by cognizant authorities and information owners, 1540 which information is public and which private. By default, 1541 all information required to be transmitted via Broadcast RID, 1542 even when actually sent via Network RID, is assumed to be 1543 public; all other information contained in registries for 1544 lookup using the UAS ID is assumed to be private. 1546 PRIV-5 Pseudonymous Rendezvous: DRIP MAY enable mutual discovery of 1547 and communications among participating UAS operators whose UA 1548 are in 4-D proximity, using the UAS ID without revealing 1549 pilot/operator identity or physical location. 1551 In some jurisdictions, the configurable enabling and disabling of 1552 encryption may need to be outside the control of the operator. 1553 [FRUR] mandates manufacturers design RID equipment with some degree 1554 of tamper resistance; the preamble and other FAA commentary suggest 1555 this is to reduce the likelihood that an operator, intentionally or 1556 unintentionally, might alter the values of the required data elements 1557 or disable their transmission in the required manner (e.g., as 1558 cleartext). 1560 How information is stored on end systems is out of scope for DRIP. 1561 Encouraging privacy best practices, including end system storage 1562 encryption, by facilitating it with protocol design reflecting such 1563 considerations, is in scope. Similar logic applies to methods for 1564 designating information as public or private. 1566 The privacy requirements above are for DRIP, neither for [F3411-19] 1567 (which requires obfuscation of location to any Network RID subscriber 1568 engaging in wide area surveillance, limits data retention periods, 1569 etc., in the interests of privacy), nor for UAS RID in any specific 1570 jurisdiction (which may have its own regulatory requirements). The 1571 requirements above are also in a sense parameterized: who are the 1572 "authorized actors", how are they designated, how are they 1573 authenticated, etc.? 1575 4.4. Registries 1577 REG-1 Public Lookup: DRIP MUST enable lookup, from the UAS ID, of 1578 information designated by cognizant authority as public, and 1579 MUST NOT restrict access to this information based on identity 1580 or role of the party submitting the query. 1582 REG-2 Private Lookup: DRIP MUST enable lookup of private information 1583 (i.e., any and all information in a registry, associated with 1584 the UAS ID, that is designated by neither cognizant authority 1585 nor the information owner as public), and MUST, according to 1586 applicable policy, enforce AAA, including restriction of 1587 access to this information based on identity or role of the 1588 party submitting the query. 1590 REG-3 Provisioning: DRIP MUST enable provisioning registries with 1591 static information on the UAS and its operator, dynamic 1592 information on its current operation within the U-space/UTM 1593 (including means by which the USS under which the UAS is 1594 operating may be contacted for further, typically even more 1595 dynamic, information), and Internet direct contact information 1596 for services related to the foregoing. 1598 REG-4 AAA Policy: DRIP AAA MUST be specifiable by policies; the 1599 definitive copies of those policies must be accessible in 1600 registries; administration of those policies and all DRIP 1601 registries must be protected by AAA. 1603 Registries are fundamental to RID. Only very limited information can 1604 be Broadcast, but extended information is sometimes needed. The most 1605 essential element of information sent is the UAS ID itself, the 1606 unique key for lookup of extended information in registries. Beyond 1607 designating the UAS ID as that unique key, the registry information 1608 model is not specified herein, in part because regulatory 1609 requirements for different registries (UAS operators and their UA, 1610 each narrowly for UAS RID and broadly for U-space/UTM) and business 1611 models for meeting those requirements are in flux. However those may 1612 evolve, the essential registry functions remain the same, so are 1613 specified herein. 1615 5. IANA Considerations 1617 This document does not make any IANA request. 1619 6. Security Considerations 1621 DRIP is all about safety and security, so content pertaining to such 1622 is not limited to this section. This document does not define any 1623 protocols, so security considerations of such are speculative. 1624 Potential vulnerabilities of DRIP solutions to these requirements 1625 include but are not limited to: 1627 * Sybil attacks 1629 * confusion created by many spoofed unsigned messages 1631 * processing overload induced by attempting to verify many spoofed 1632 signed messages (where verification will fail but still consume 1633 cycles) 1635 * malicious or malfunctioning registries 1637 * interception by on-path attacker of (i.e., Man In The Middle 1638 attacks on) registration messages 1640 * UA impersonation through private key extraction, improper key 1641 sharing, or carriage of a small (presumably harmless) UA, i.e., as 1642 a "false flag", by a larger (malicious) UA 1644 It may be inferred from the general requirements (Section 4.1) for 1645 provable ownership, provable binding, and provable registration, 1646 together with the identifier requirements (Section 4.2), that DRIP 1647 must provide: 1649 * message integrity 1651 * non-repudiation 1653 * defense against replay attacks 1655 * defense against spoofing 1657 One approach to so doing involves verifiably binding the DRIP 1658 identifier to a public key. Providing these security features, 1659 whether via this approach or another, is likely to be especially 1660 challenging for Observers without Internet connectivity at the time 1661 of observation. For example, checking the signature of a registry on 1662 a public key certificate received via Broadcast RID in a remote area 1663 presumably would require that the registry's public key had been 1664 previously installed on the Observer's device, yet there may be many 1665 registries and the Observer's device may be storage constrained, and 1666 new registries may come on-line subsequent to installation of DRIP 1667 software on the Observer's device. Thus there may be caveats on the 1668 extent to which requirements can be satisfied in such cases, yet 1669 strenuous effort should be made to satisfy them, as such cases, e.g., 1670 firefighting in a national forest, are important. 1672 7. Privacy and Transparency Considerations 1674 Privacy and transparency are important for legal reasons including 1675 regulatory consistency. [EU2018] states "harmonised and 1676 interoperable national registration systems... should comply with the 1677 applicable Union and national law on privacy and processing of 1678 personal data, and the information stored in those registration 1679 systems should be easily accessible." 1681 Privacy and transparency (where essential to security or safety) are 1682 also ethical and moral imperatives. Even in cases where old 1683 practices (e.g., automobile registration plates) could be imitated, 1684 when new applications involving PII (such as UAS RID) are addressed 1685 and newer technologies could enable improving privacy, such 1686 opportunities should not be squandered. Thus it is recommended that 1687 all DRIP work give due regard to [RFC6973] and more broadly 1688 [RFC8280]. 1690 However, privacy and transparency are often conflicting goals, 1691 demanding careful attention to their balance. 1693 DRIP information falls into two classes: that which, to achieve the 1694 purpose, must be published openly as cleartext, for the benefit of 1695 any Observer (e.g., the basic UAS ID itself); and that which must be 1696 protected (e.g., PII of pilots) but made available to properly 1697 authorized parties (e.g., public safety personnel who urgently need 1698 to contact pilots in emergencies). 1700 How properly authorized parties are authorized, authenticated, etc. 1701 are questions that extend beyond the scope of DRIP, but DRIP may be 1702 able to provide support for such processes. Classification of 1703 information as public or private must be made explicit and reflected 1704 with markings, design, etc. Classifying the information will be 1705 addressed primarily in external standards; herein it will be regarded 1706 as a matter for CAA, registry, and operator policies, for which 1707 enforcement mechanisms will be defined within the scope of DRIP WG 1708 and offered. Details of the protection mechanisms will be provided 1709 in other DRIP documents. Mitigation of adversarial correlation will 1710 also be addressed. 1712 8. References 1714 8.1. Normative References 1716 [F3411-19] ASTM International, "Standard Specification for Remote ID 1717 and Tracking", February 2020, 1718 . 1720 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1721 Requirement Levels", BCP 14, RFC 2119, 1722 DOI 10.17487/RFC2119, March 1997, 1723 . 1725 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1726 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1727 May 2017, . 1729 8.2. Informative References 1731 [Amended] European Union Aviation Safety Agency (EASA), "Commission 1732 Delegated Regulation (EU) 2020/1058 of 27 April 2020 1733 amending Delegated Regulation (EU) 2019/945", April 2020, 1734 . 1737 [ASDRI] ASD-STAN, "Introduction to the European UAS Digital Remote 1738 ID Technical Standard", January 2021, . 1742 [CPDLC] Gurtov, A., Polishchuk, T., and M. Wernberg, "Controller- 1743 Pilot Data Link Communication Security", MDPI 1744 Sensors 18(5), 1636, 2018, 1745 . 1747 [CTA2063A] ANSI, "Small Unmanned Aerial Systems Serial Numbers", 1748 September 2019, . 1751 [Delegated] 1752 European Union Aviation Safety Agency (EASA), "Commission 1753 Delegated Regulation (EU) 2019/945 of 12 March 2019 on 1754 unmanned aircraft systems and on third-country operators 1755 of unmanned aircraft systems", March 2019, 1756 . 1758 [drip-architecture] 1759 Card, S., Wiethuechter, A., Moskowitz, R., Zhao, S., and 1760 A. Gurtov, "Drone Remote Identification Protocol (DRIP) 1761 Architecture", Work in Progress, Internet-Draft, draft- 1762 ietf-drip-arch-11, 23 February 2021, 1763 . 1765 [ENISACSIRT] 1766 European Union Agency for Cybersecurity (ENISA), 1767 "Actionable information for Security Incident Response", 1768 November 2014, . 1772 [EU2018] European Parliament and Council, "2015/0277 (COD) PE-CONS 1773 2/18", February 2018, 1774 . 1777 [FAACONOPS] 1778 FAA Office of NextGen, "UTM Concept of Operations v2.0", 1779 March 2020, . 1782 [FRUR] Federal Aviation Administration, "Remote Identification of 1783 Unmanned Aircraft", January 2021, 1784 . 1788 [GDPR] European Parliament and Council, "General Data Protection 1789 Regulation", April 2016, 1790 . 1792 [I-D.maeurer-raw-ldacs] 1793 Maeurer, N., Graeupl, T., and C. Schmitt, "L-band Digital 1794 Aeronautical Communications System (LDACS)", Work in 1795 Progress, Internet-Draft, draft-maeurer-raw-ldacs-06, 2 1796 October 2020, 1797 . 1799 [ICAOATM] International Civil Aviation Organization, "Doc 4444: 1800 Procedures for Air Navigation Services: Air Traffic 1801 Management", November 2016, . 1805 [ICAODEFS] International Civil Aviation Organization, "Defined terms 1806 from the Annexes to the Chicago Convention and ICAO 1807 guidance material", July 2017, 1808 . 1811 [ICAOUAS] International Civil Aviation Organization, "Circular 328: 1812 Unmanned Aircraft Systems", February 2011, 1813 . 1816 [ICAOUTM] International Civil Aviation Organization, "Unmanned 1817 Aircraft Systems Traffic Management (UTM) - A Common 1818 Framework with Core Principles for Global Harmonization, 1819 Edition 3", October 2020, 1820 . 1823 [Implementing] 1824 European Union Aviation Safety Agency (EASA), "Commission 1825 Implementing Regulation (EU) 2019/947 of 24 May 2019 on 1826 the rules and procedures for the operation of unmanned 1827 aircraft", May 2019, 1828 . 1830 [InitialView] 1831 SESAR Joint Undertaking, "Initial view on Principles for 1832 the U-space architecture", July 2019, 1833 . 1837 [NPRM] United States Federal Aviation Administration (FAA), 1838 "Notice of Proposed Rule Making on Remote Identification 1839 of Unmanned Aircraft Systems", December 2019, 1840 . 1844 [OpenDroneID] 1845 Intel Corp., "Open Drone ID", March 2019, 1846 . 1848 [Opinion1] European Union Aviation Safety Agency (EASA), "Opinion No 1849 01/2020: High-level regulatory framework for the U-space", 1850 March 2020, . 1853 [Part107] United States Federal Aviation Administration, "Code of 1854 Federal Regulations Part 107", June 2016, 1855 . 1857 [Recommendations] 1858 FAA UAS Identification and Tracking Aviation Rulemaking 1859 Committee, "UAS ID and Tracking ARC Recommendations Final 1860 Report", September 2017, . 1864 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1865 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1866 DOI 10.17487/RFC4122, July 2005, 1867 . 1869 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1870 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1871 . 1873 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1874 Morris, J., Hansen, M., and R. Smith, "Privacy 1875 Considerations for Internet Protocols", RFC 6973, 1876 DOI 10.17487/RFC6973, July 2013, 1877 . 1879 [RFC8280] ten Oever, N. and C. Cath, "Research into Human Rights 1880 Protocol Considerations", RFC 8280, DOI 10.17487/RFC8280, 1881 October 2017, . 1883 [Roadmap] American National Standards Institute (ANSI) Unmanned 1884 Aircraft Systems Standardization Collaborative (UASSC), 1885 "Standardization Roadmap for Unmanned Aircraft Systems 1886 draft v2.0", April 2020, . 1890 [Stranger] Heinlein, R.A., "Stranger in a Strange Land", June 1961. 1892 [WG105] EUROCAE, "WG-105 draft ED-282 Minimum Operational 1893 Performance Standards (MOPS) for Unmanned Aircraft System 1894 (UAS) Electronic Identification", June 2020. 1896 [WiFiNAN] Wi-Fi Alliance, "Wi-Fi Aware™ Specification Version 3.2", 1897 October 2020, . 1900 Appendix A. Discussion and Limitations 1902 This document is largely based on the process of one SDO, ASTM. 1903 Therefore, it is tailored to specific needs and data formats of this 1904 standard. Other organizations, for example in EU, do not necessary 1905 follow the same architecture. 1907 The need for drone ID and operator privacy is an open discussion 1908 topic. For instance, in the ground vehicular domain each car carries 1909 a publicly visible plate number. In some countries, for nominal cost 1910 or even for free, anyone can resolve the identity and contact 1911 information of the owner. Civil commercial aviation and maritime 1912 industries also have a tradition of broadcasting plane or ship ID, 1913 coordinates, and even flight plans in plain text. Community networks 1914 such as OpenSky and Flightradar use this open information through 1915 ADS-B to deploy public services of flight tracking. Many researchers 1916 also use these data to perform optimization of routes and airport 1917 operations. Such ID information should be integrity protected, but 1918 not necessarily confidential. 1920 In civil aviation, aircraft identity is broadcast by a device known 1921 as transponder. It transmits a four octal digit squawk code, which 1922 is assigned by a traffic controller to an airplane after approving a 1923 flight plan. There are several reserved codes such as 7600 which 1924 indicate radio communication failure. The codes are unique in each 1925 traffic area and can be re-assigned when entering another control 1926 area. The code is transmitted in plain text by the transponder and 1927 also used for collision avoidance by a system known as Traffic alert 1928 and Collision Avoidance System (TCAS). The system could be used for 1929 UAS as well initially, but the code space is quite limited and likely 1930 to be exhausted soon. The number of UAS far exceeds the number of 1931 civil airplanes in operation. 1933 The ADS-B system is utilized in civil aviation for each "ADS-B Out" 1934 equipped airplane to broadcast its ID, coordinates, and altitude for 1935 other airplanes and ground control stations. If this system is 1936 adopted for drone IDs, it has additional benefit with backward 1937 compatibility with civil aviation infrastructure; then, pilots and 1938 dispatchers will be able to see UA on their control screens and take 1939 those into account. If not, a gateway translation system between the 1940 proposed drone ID and civil aviation system should be implemented. 1941 Again, system saturation due to large numbers of UAS is a concern. 1943 The Mode S transponders used in all TCAS and most ADS-B Out 1944 installations are assigned an ICAO 24 bit "address" (arguably really 1945 an identifier rather than a locator) that is associated with the 1946 aircraft as part of its registration. In the US alone, well over 1947 2^20 UAS are already flying; thus, a 24 bit space likely would be 1948 rapidly exhausted if used for UAS (other than large UAS flying in 1949 controlled airspace, especially internationally, under rules other 1950 than those governing small UAS at low altitudes). 1952 Wi-Fi and Bluetooth are two wireless technologies currently 1953 recommended by ASTM specifications due to their widespread use and 1954 broadcast nature. However, those have limited range (max 100s of 1955 meters) and may not reliably deliver UAS ID at high altitude or 1956 distance. Therefore, a study should be made of alternative 1957 technologies from the telecom domain (WiMAX / IEEE 802.16, 5G) or 1958 sensor networks (Sigfox, LoRa). Such transmission technologies can 1959 impose additional restrictions on packet sizes and frequency of 1960 transmissions, but could provide better energy efficiency and range. 1962 In civil aviation, Controller-Pilot Data Link Communications (CPDLC) 1963 is used to transmit command and control between the pilots and ATC. 1964 It could be considered for UAS as well due to long range and proven 1965 use despite its lack of security [CPDLC]. 1967 L-band Digital Aeronautical Communications System (LDACS) is being 1968 standardized by ICAO and IETF for use in future civil aviation 1969 [I-D.maeurer-raw-ldacs]. It provides secure communication, 1970 positioning, and control for aircraft using a dedicated radio band. 1971 It should be analyzed as a potential provider for UAS RID as well. 1972 This will bring the benefit of a global integrated system creating a 1973 global airspace use awareness. 1975 Acknowledgments 1977 The work of the FAA's UAS Identification and Tracking (UAS ID) 1978 Aviation Rulemaking Committee (ARC) is the foundation of later ASTM 1979 [F3411-19] and IETF DRIP efforts. The work of Gabriel Cox, Intel 1980 Corp., and their Open Drone ID collaborators opened UAS RID to a 1981 wider community. The work of ASTM F38.02 in balancing the interests 1982 of diverse stakeholders is essential to the necessary rapid and 1983 widespread deployment of UAS RID. IETF volunteers who have 1984 extensively reviewed or otherwise contributed to this document 1985 include Amelia Andersdotter, Carsten Bormann, Mohamed Boucadair, 1986 Toerless Eckert, Susan Hares, Mika Jarvenpaa, Daniel Migault, 1987 Alexandre Petrescu, Saulo Da Silva and Shuai Zhao. 1989 Authors' Addresses 1990 Stuart W. Card (editor) 1991 AX Enterprize 1992 4947 Commercial Drive 1993 Yorkville, NY 13495 1994 United States of America 1996 Email: stu.card@axenterprize.com 1998 Adam Wiethuechter 1999 AX Enterprize 2000 4947 Commercial Drive 2001 Yorkville, NY 13495 2002 United States of America 2004 Email: adam.wiethuechter@axenterprize.com 2006 Robert Moskowitz 2007 HTT Consulting 2008 Oak Park, MI 48237 2009 United States of America 2011 Email: rgm@labs.htt-consult.com 2013 Andrei Gurtov 2014 Linköping University 2015 IDA 2016 SE-58183 Linköping 2017 Sweden 2019 Email: gurtov@acm.org