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