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