idnits 2.17.1 draft-ietf-drip-reqs-05.txt: -(8): 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 3 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 139 has weird spacing: '... Pilot xxxxx...' == Line 140 has weird spacing: '...perator x ...' == Line 777 has weird spacing: '...bserver x x...' -- The document date (16 October 2020) is 1287 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 5 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: 19 April 2021 R. Moskowitz 6 HTT Consulting 7 A. Gurtov 8 Linköping University 9 16 October 2020 11 Drone Remote Identification Protocol (DRIP) Requirements 12 draft-ietf-drip-reqs-05 14 Abstract 16 This document defines terminology and requirements for Drone Remote 17 Identification Protocol (DRIP) Working Group protocols to support 18 Unmanned Aircraft System Remote Identification and tracking (UAS RID) 19 for security, safety and other purposes. Complementing external 20 technical standards as regulator-accepted means of compliance with 21 UAS RID regulations, DRIP will: 23 facilitate use of existing Internet resources to support UAS RID 24 and to enable enhanced related services; 26 enable online and offline verification that UAS RID information is 27 trustworthy. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 19 April 2021. 46 Copyright Notice 48 Copyright (c) 2020 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Simplified BSD License text 57 as described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction (Informative) . . . . . . . . . . . . . . . . . 2 63 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.2. Concerns and Constraints . . . . . . . . . . . . . . . . 6 65 1.3. DRIP Scope . . . . . . . . . . . . . . . . . . . . . . . 7 66 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 8 67 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 8 68 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8 69 3. UAS RID Problem Space . . . . . . . . . . . . . . . . . . . . 16 70 3.1. Network RID . . . . . . . . . . . . . . . . . . . . . . . 17 71 3.2. Broadcast RID . . . . . . . . . . . . . . . . . . . . . . 19 72 3.3. DRIP Focus . . . . . . . . . . . . . . . . . . . . . . . 22 73 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 22 74 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 22 75 4.2. Identifier . . . . . . . . . . . . . . . . . . . . . . . 24 76 4.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 25 77 4.4. Registries . . . . . . . . . . . . . . . . . . . . . . . 26 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 80 7. Privacy and Transparency Considerations . . . . . . . . . . . 29 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 29 83 8.2. Informative References . . . . . . . . . . . . . . . . . 30 84 Appendix A. Discussion and Limitations . . . . . . . . . . . . . 32 85 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 33 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 88 1. Introduction (Informative) 89 1.1. Motivation 91 Many considerations (especially safety and security) necessitate 92 Unmanned Aircraft Systems (UAS) Remote Identification and tracking 93 (RID). 95 Unmanned Aircraft (UA) may be fixed wing Short Take-Off and Landing 96 (STOL), rotary wing (e.g., helicopter) Vertical Take-Off and Landing 97 (VTOL), or hybrid. They may be single- or multi-engine. The most 98 common today are multicopters: rotary wing, multi engine. The 99 explosion in UAS was enabled by hobbyist development, for 100 multicopters, of advanced flight stability algorithms, enabling even 101 inexperienced pilots to take off, fly to a location of interest, 102 hover, and return to the take-off location or land at a distance. 103 UAS can be remotely piloted by a human (e.g., with a joystick) or 104 programmed to proceed from GNSS waypoint to waypoint in a weak form 105 of autonomy; stronger autonomy is coming. UA are "low observable": 106 they typically have small radar cross sections; they make noise quite 107 noticeable at short range but difficult to detect at distances they 108 can quickly close (500 meters in under 17 seconds at 60 knots); they 109 typically fly at low altitudes (for the small UAS to which RID 110 applies in the US, under 400 feet AGL); they are highly maneuverable 111 so can fly under trees and between buildings. 113 UA can carry payloads including sensors, cyber and kinetic weapons, 114 or can be used themselves as weapons by flying them into targets. 115 They can be flown by clueless, careless or criminal operators. Thus 116 the most basic function of UAS RID is "Identification Friend or Foe" 117 (IFF) to mitigate the significant threat they present. Numerous 118 other applications can be enabled or facilitated by RID: consider the 119 importance of identifiers in many Internet protocols and services. 120 The general scenario is illustrated in Figure 1. 122 UA1 UA2 123 x x x x 124 xxxxx xxxxx 126 General x x Public 127 Public xxxxx xxxxx Safety 128 Observer x x Observer 129 x x 130 x x ---------+ +---------- x x 131 x x | | x x 132 | | 133 + + 134 xxxxxxxxxx 135 x x 136 +----------+x Internet x+------------+ 137 | x x | 138 UA1 x | xxxxxxxxxx | x UA2 139 Pilot xxxxx + + + xxxxx Pilot 140 Operator x | | | x Operator 141 x | | | x 142 x x | | | x x 143 x x | | | x x 144 | | | 145 +----------+ | | | +----------+ 146 | |------+ | +-------| | 147 | Public | | | Private | 148 | Registry | +-----+ | Registry | 149 | | | DNS | | | 150 +----------+ +-----+ +----------+ 152 Figure 1: "General UAS RID Scenario" 154 Note the absence of any links to/from the UA in Figure 1. This is 155 because UAS RID and other connectivity involving the UA varies as 156 described below. 158 Inherently, any responsible Observer of UA must classify them, as 159 illustrated notionally in Figure 2. For basic airspace Situational 160 Awareness (SA), an Observer who classifies an UAS: as Taskable, can 161 ask it to do something useful; as Low Concern, can reasonably assume 162 it is not malicious, and would cooperate with requests to modify its 163 flight plans for safety concerns that arise; as High Concern or 164 Unidentified, can focus surveillance on it. These classes are not 165 standard, but derive from first principles. 167 xxxxxxx +--------------+ 168 x x No | | 169 x ID? x+---->| UNIDENTIFIED | 170 x x | | 171 xxxxxxx +--------------+ 172 + 173 | Yes 174 v 175 xxxxxxx 176 x x 177 +---------+x TYPE? x+----------+ 178 | x x | 179 | xxxxxxx | 180 | + | 181 v v v 182 +--------------+ +--------------+ +--------------+ 183 | | | | | | 184 | TASKABLE | | LOW CONCERN | | HIGH CONCERN | 185 | | | | | | 186 +--------------+ +--------------+ +--------------+ 188 Figure 2: "Notional UAS Classification" 190 An ID is not an end in itself; it exists to enable lookups and 191 provision of services complementing mere identification. 193 Using UAS RID to facilitate vehicular (V2X) communications and 194 applications such as Detect And Avoid (DAA), which would impose 195 tighter latency bounds than RID itself, is an obvious possibility, 196 explicitly contemplated in the United States (US) Federal Aviation 197 Administration (FAA) Notice of Proposed Rule Making [NPRM]. However, 198 applications of RID beyond RID itself, including DAA, have been 199 explicitly declared out of scope in ASTM International, Technical 200 Committee F38 (UAS), Subcommittee F38.02 (Aircraft Operations), Work 201 Item WK65041, working group discussions, based on a distinction 202 between RID as a security standard vs DAA as a safety application. 203 Although dynamic establishment of secure communications between the 204 Observer and the UAS pilot seems to have been contemplated by the FAA 205 UAS ID and Tracking Aviation Rulemaking Committee (ARC) in their 206 [Recommendations], it is not addressed in any of the subsequent 207 proposed regulations or technical specifications. 209 [Opinion1] and [WG105] cite the Direct Remote Identification 210 previously required and specified, explicitly stating that whereas 211 Direct RID is primarily for security purposes, "Electronic 212 Identification" (or the "Network Identification Service" in the 213 context of U-space) is primarily for safety purposes (e.g. air 214 traffic management, especially hazards deconfliction) and also is 215 allowed to be used for other purposes such as support of efficient 216 operations. These emerging standards allow the security and safety 217 oriented systems to be separate or merged. In addition to mandating 218 both Broadcast and Network one-way to Observers, they will use V2V to 219 other UAS (also likely to and/or from some manned aircraft). These 220 reflect the broad scope of the EU U-space concept, as being developed 221 in the Single European Sky ATM Research (SESAR) Joint Undertaking, 222 whose U-space architectural principles are outlined in [InitialView]. 224 Security oriented UAS RID essentially has two goals: enable the 225 general public to obtain and record an opaque ID for any observed UA, 226 which they can then report to authorities; enable authorities, from 227 such an ID, to look up information about the UAS and its operator. 228 Safety oriented UAS RID has stronger requirements. Aviation 229 community SDOs set a higher bar for safety than for security, 230 especially with respect to reliability. 232 1.2. Concerns and Constraints 234 Disambiguation of multiple UA flying in close proximity may be very 235 challenging, even if each is reporting its identity, position and 236 velocity as accurately as it can. As the origin of all information 237 in UAS RID is self-reports from operators, there are possibilities 238 not only of unintentional error, but also of intentional 239 falsification, of this data. 241 Minimal specified information must be made available to the public; 242 access to other data, e.g., UAS operator Personally Identifiable 243 Information (PII), must be limited to strongly authenticated 244 personnel, properly authorized per policy. The balance between 245 privacy and transparency remains a subject for public debate and 246 regulatory action; DRIP can only offer tools to expand the achievable 247 trade space and enable trade-offs within that space. [F3411-19] 248 specifies only how to get the UAS ID to the Observer: how the 249 Observer can perform these lookups, and how the registries first can 250 be populated with information, is unspecified. 252 The need for near-universal deployment of UAS RID is pressing. This 253 implies the need to support use by Observers of already ubiquitous 254 mobile devices (typically smartphones and tablets). Anticipating 255 likely CAA requirements to support legacy devices, especially in 256 light of [Recommendations], [F3411-19] specifies that any UAS sending 257 Broadcast RID over Bluetooth must do so over Bluetooth 4, regardless 258 of whether it also does so over newer versions; as UAS sender devices 259 and Observer receiver devices are unpaired, this implies extremely 260 short "advertisement" (beacon) frames. 262 Wireless data links on the UA are challenging due to low altitude 263 flight amidst structures and foliage over terrain, as well as the 264 severe Cost, Size, Weight and Power (CSWaP) constraints of devices 265 onboard UA. CSWaP is a burden not only on the designers of new UA 266 for production and sale, but also on owners of existing UA that must 267 be retrofit. Radio Controlled (RC) aircraft modelers, "hams" who use 268 licensed amateur radio frequencies to control UAS, drone hobbyists, 269 and others who custom build UAS, all need means of participating in 270 UAS RID, sensitive to both generic CSWaP and application-specific 271 considerations. 273 To accommodate the most severely constrained cases, all these 274 conspire to motivate system design decisions, especially for the 275 Broadcast RID data link, which complicate the protocol design 276 problem: one-way links; extremely short packets; and Internet- 277 disconnected operation of UA onboard devices. Internet-disconnected 278 operation of Observer devices has been deemed by ASTM F38.02 too 279 infrequent to address, but for some users is important and presents 280 further challenges. 282 As RID must often operate with limited bandwidth, short packet 283 payload length limits, and one-way links, heavyweight cryptographic 284 security protocols or even simple cryptographic handshakes are 285 infeasible, yet trustworthiness of UAS RID information is essential. 286 Under [F3411-19], even the most basic datum, the UAS ID string 287 (typically number) itself can be merely an unsubstantiated claim. 289 Observer devices being ubiquitous, thus popular targets for malware 290 or other compromise, cannot be generally trusted (although the user 291 of each device is compelled to trust that device, to some extent); a 292 "fair witness" functionality (inspired by [Stranger]) is desirable. 294 Despite work by regulators and Standards Development Organizations 295 (SDOs), there are substantial gaps in UAS standards generally and UAS 296 RID specifically. [Roadmap] catalogs UAS related standards, ongoing 297 standardization activities and gaps (as of early 2020); Section 7.8 298 catalogs those related specifically to UAS RID. DRIP will address 299 the most fundamental of these gaps, as foreshadowed above. 301 1.3. DRIP Scope 303 DRIP's initial goal is to make RID immediately actionable, in both 304 Internet and local-only connected scenarios (especially emergencies), 305 in severely constrained UAS environments, balancing legitimate (e.g., 306 public safety) authorities' Need To Know trustworthy information with 307 UAS operators' privacy. By "immediately actionable" is meant 308 information of sufficient precision, accuracy, timeliness, etc. for 309 an Observer to use it as the basis for immediate decisive action, 310 whether that be to trigger a defensive counter-UAS system, to attempt 311 to initiate communications with the UAS operator, to accept the 312 presence of the UAS in the airspace where/when observed as not 313 requiring further action, or whatever, with potentially severe 314 consequences of any action or inaction chosen based on that 315 information. For further explanation of the concept of immediate 316 actionability, see [ENISACSIRT]. Note that UAS RID must achieve near 317 universal adoption, but DRIP can add value even if only selectively 318 deployed, as those with jurisdiction over more sensitive airspace 319 volumes may set a higher than generally mandated RID bar for flight 320 in those volumes. Providing timely trustworthy identification data 321 is also prerequisite to identity-oriented networking. 323 DRIP (originally Trustworthy Multipurpose Remote Identification, TM- 324 RID) potentially could be applied to verifiably identify other types 325 of registered things reported to be in specified physical locations, 326 but the urgent motivation and clear initial focus is UAS. Existing 327 Internet resources (protocol standards, services, infrastructure, and 328 business models) should be leveraged. A natural Internet based 329 architecture for UAS RID conforming to proposed regulations and 330 external technical standards is described in a companion architecture 331 document [drip-architecture] and elaborated in other DRIP documents; 332 this document describes only relevant requirements and defines 333 terminology for the set of DRIP documents. 335 2. Terms and Definitions 337 2.1. Requirements Terminology 339 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 340 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 341 "OPTIONAL" in this document are to be interpreted as described in BCP 342 14 [RFC2119] [RFC8174] when, and only when, they appear in all 343 capitals, as shown here. 345 2.2. Definitions 347 This section defines a set of terms expected to be used in DRIP 348 documents. This list is meant to be the DRIP terminology reference. 349 Some of the terms listed below are not used in this document. 350 [RFC4949] provides a glossary of Internet security terms that should 351 be used where applicable. In the UAS community, the plural form of 352 acronyms generally is the same as the singular form, e.g. Unmanned 353 Aircraft System (singular) and Unmanned Aircraft Systems (plural) are 354 both represented as UAS. On this and other terminological issues, to 355 encourage comprehension necessary for adoption of DRIP by the 356 intended user community, that community's norms are respected herein, 357 and definitions are quoted in cases where they have been found in 358 that community's documents. Most of the listed terms are from that 359 community (even if specific source documents are not cited); any that 360 are DRIP-specific or invented by the authors of this document are 361 marked "(DRIP)". 363 AAA 364 Attestation, Authentication, Authorization, Access Control, 365 Accounting, Attribution, Audit, or any subset thereof (uses differ 366 by application, author and context). (DRIP) 368 ABDAA 369 AirBorne DAA. Accomplished using systems onboard the aircraft 370 involved. Supports "self-separation" (remaining "well clear" of 371 other aircraft) and collision avoidance. 373 ADS-B 374 Automatic Dependent Surveillance - Broadcast. "ADS-B Out" 375 equipment obtains aircraft position from other on-board systems 376 (typically GNSS) and periodically broadcasts it to "ADS-B In" 377 equipped entities, including other aircraft, ground stations and 378 satellite based monitoring systems. 380 AGL 381 Above Ground Level. Relative altitude, above the variously 382 defined local ground level, typically of an UA, measured in feet 383 or meters. Should be explicitly specified as either barometric 384 (pressure) or geodetic (GNSS). 386 ATC 387 Air Traffic Control. Explicit flight direction to pilots from 388 ground controllers. Contrast with ATM. 390 ATM 391 Air Traffic Management. A broader functional and geographic scope 392 and/or a higher layer of abstraction than ATC. "The dynamic, 393 integrated management of air traffic and airspace including air 394 traffic services, airspace management and air traffic flow 395 management - safely, economically and efficiently - through the 396 provision of facilities and seamless services in collaboration 397 with all parties and involving airborne and ground-based 398 functions." [ICAOATM] 400 Authentication Message 401 [F3411-19] Message Type 2. Provides framing for authentication 402 data, only. Optional per [F3411-19] but may be required by 403 regulations. 405 Basic ID Message 406 [F3411-19] Message Type 0. Provides UA Type, UAS ID Type and UAS 407 ID, only. Mandatory per [F3411-19]. 409 B-LOS 410 Beyond Line Of Sight (LOS). Term to be avoided due to ambiguity. 411 See LOS. 413 BV-LOS 414 Beyond Visual Line Of Sight (V-LOS). See V-LOS. 416 CAA 417 Civil Aviation Authority. Two examples are the United States 418 Federal Aviation Administration (FAA) and the Japan Civil Aviation 419 Bureau. 421 CSWaP 422 Cost, Size, Weight and Power. 424 C2 425 Command and Control. Previously mostly used in military contexts. 426 In the UAS context, typically refers to the RF data link over 427 which the GCS controls the UA. 429 DAA 430 Detect And Avoid, formerly Sense And Avoid (SAA). A means of 431 keeping aircraft "well clear" of each other and obstacles for 432 safety. "The capability to see, sense or detect conflicting 433 traffic or other hazards and take the appropriate action to comply 434 with the applicable rules of flight." [ICAOUAS] 436 Direct RID 437 Direct Remote Identification. "a system that ensures the local 438 broadcast of information about a UA in operation, including the 439 marking of the UA, so that this information can be obtained 440 without physical access to the UA". [Delegated] Corresponds 441 roughly to the Broadcast RID portion of [NPRM] Standard RID. 443 DSS 444 Discovery and Synchronization Service. Formerly Inter-USS. The 445 UTM system overlay network backbone. Most importantly, it enables 446 one USS to learn which other USS have UAS operating in a given 4-D 447 airspace volume, for deconfliction of planned and Network RID 448 surveillance of active operations. [F3411-19] 450 EUROCAE 451 European Organisation for Civil Aviation Equipment. Aviation SDO, 452 originally European, now with broader membership. Cooperates 453 extensively with RTCA. 455 GBDAA 456 Ground Based DAA. Accomplished with the aid of ground based 457 functions. 459 GCS 460 Ground Control Station. The part of the UAS that the remote pilot 461 uses to exercise C2 over the UA, whether by remotely exercising UA 462 flight controls to fly the UA, by setting GPS waypoints, or 463 otherwise directing its flight. 465 GNSS 466 Global Navigation Satellite System. Satellite based timing and/or 467 positioning with global coverage, often used to support 468 navigation. 470 GPS 471 Global Positioning System. A specific GNSS, but in the UAS 472 context, the term is typically misused in place of the more 473 generic term GNSS. 475 GRAIN 476 Global Resilient Aviation Interoperable Network. ICAO managed 477 IPv6 overlay internetwork per IATF, dedicated to aviation (but not 478 just aircraft). Currently in design. 480 IATF 481 International Aviation Trust Framework. ICAO effort to develop a 482 resilient and secure by design framework for networking in support 483 of all aspects of aviation. 485 ICAO 486 International Civil Aviation Organization. A United Nations 487 specialized agency that develops and harmonizes international 488 standards relating to aviation. 490 LAANC 491 Low Altitude Authorization and Notification Capability. Supports 492 ATC authorization requirements for UAS operations: remote pilots 493 can apply to receive a near real-time authorization for operations 494 under 400 feet in controlled airspace near airports. US partial 495 stopgap until UTM comes. 497 Limited RID 498 A mode of operation that must use Network RID, must not use 499 Broadcast RID, and must provide pilot/GCS location only (not UA 500 location). This mode is only allowed for UA that neither require 501 (due to e.g. size) nor are equipped for Standard RID, operated 502 within V-LOS and within 400 feet of the pilot, below 400 feet AGL, 503 etc. [NPRM] 505 Location/Vector Message 506 [F3411-19] Message Type 1. Provides UA location, altitude, 507 heading, speed and status. Mandatory per [F3411-19]. 509 LOS 510 Line Of Sight. An adjectival phrase describing any information 511 transfer that travels in a nearly straight line (e.g. 512 electromagnetic energy, whether in the visual light, RF or other 513 frequency range) and is subject to blockage. A term to be avoided 514 due to ambiguity, in this context, between RF-LOS and V-LOS. 516 MSL 517 Mean Sea Level. Relative altitude, above the variously defined 518 mean sea level, typically of an UA (but in [NPRM] also for a GCS), 519 measured in feet or meters. Should be explicitly specified as 520 either barometric (pressure) or geodetic (GNSS). 522 Net-RID DP 523 Network RID Display Provider. [F3411-19] logical entity that 524 aggregates data from Net-RID SPs as needed in response to user 525 queries regarding UAS operating within specified airspace volumes, 526 to enable display by a user application on a user device. 527 Potentially could provide not only information sent via UAS RID 528 but also information retrieved from UAS RID registries, or 529 information beyond UAS RID. Under [NPRM], not recognized as a 530 distinct entity, but a service provided by USS, including Public 531 Safety USS that may exist primarily for this purpose rather than 532 to manage any subscribed UAS. 534 Net-RID SP 535 Network RID Service Provider. [F3411-19] logical entity that 536 collects RID messages from UAS and responds to NetRID-DP queries 537 for information on UAS of which it is aware. Under [NPRM], the 538 USS to which the UAS is subscribed ("Remote ID USS"). 540 Network Identification Service 541 EU regulatory requirement for Network RID. [Opinion1] and [WG105] 542 Corresponds roughly to the Network RID portion of [NPRM] Standard 543 RID. 545 Observer 546 An entity (typically but not necessarily an individual human) who 547 has directly or indirectly observed an UA and wishes to know 548 something about it, starting with its ID. An observer typically 549 is on the ground and local (within V-LOS of an observed UA), but 550 could be remote (observing via Network RID or other surveillance), 551 operating another UA, aboard another aircraft, etc. (DRIP) 553 Operation 554 A flight, or series of flights of the same mission, by the same 555 UAS, separated by at most brief ground intervals. (inferred from 556 UTM usage, no formal definition found) 558 Operator 559 "A person, organization or enterprise engaged in or offering to 560 engage in an aircraft operation." [ICAOUAS] 562 Operator ID Message 563 [F3411-19] Message Type 5. Provides CAA issued Operator ID, only. 564 Operator ID is distinct from UAS ID. Optional per [F3411-19] but 565 may be required by regulations. 567 PIC 568 Pilot In Command. "The pilot designated by the operator, or in 569 the case of general aviation, the owner, as being in command and 570 charged with the safe conduct of a flight." [ICAOUAS] 572 PII 573 Personally Identifiable Information. In this context, typically 574 of the UAS Operator, Pilot In Command (PIC) or Remote Pilot, but 575 possibly of an Observer or other party. 577 Remote Pilot 578 A pilot using a GCS to exercise proximate control of an UA. 579 Either the PIC or under the supervision of the PIC. "The person 580 who manipulates the flight controls of a remotely-piloted aircraft 581 during flight time." [ICAOUAS] 583 RF 584 Radio Frequency. Noun or adjective, e.g. "RF link." 586 RF-LOS 587 RF LOS. Typically used in describing a direct radio link between 588 a GCS and the UA under its control, potentially subject to 589 blockage by foliage, structures, terrain or other vehicles, but 590 less so than V-LOS. 592 RTCA 593 Radio Technical Commission for Aeronautics. US aviation SDO. 594 Cooperates extensively with EUROCAE. 596 Self-ID Message 597 [F3411-19] Message Type 3. Provides a 1 byte descriptor and 23 598 byte ASCII free text field, only. Expected to be used to provide 599 context on the operation, e.g. mission intent. Optional per 600 [F3411-19] but may be required by regulations. 602 Standard RID 603 A mode of operation that must use both Network RID (if Internet 604 connectivity is available at the time in the operating area) and 605 Broadcast RID (always and everywhere), and must provide both 606 pilot/GCS location and UA location. This mode is required for UAS 607 that exceed the allowed envelope (e.g. size, range) of Limited RID 608 and for all UAS equipped for Standard RID (even if operated within 609 parameters that would otherwise permit Limited RID). [NPRM] The 610 Broadcast RID portion corresponds roughly to EU Direct RID; the 611 Network RID portion corresponds roughly to EU Network 612 Identification Service. 614 SDO 615 Standards Development Organization. ASTM, IETF, et al. 617 SDSP 618 Supplemental Data Service Provider. An entity that participates 619 in the UTM system, but provides services beyond those specified as 620 basic UTM system functions. E.g., provides weather data. 621 [FAACONOPS] 623 System Message 624 [F3411-19] Message Type 4. Provides general UAS information, 625 including remote pilot location, multiple UA group operational 626 area, etc. Optional per [F3411-19] but may be required by 627 regulations. 629 U-space 630 EU concept and emerging framework for integration of UAS into all 631 classes of airspace, specifically including high density urban 632 areas, sharing airspace with manned aircraft. [InitialView] 634 UA 635 Unmanned Aircraft. In popular parlance, "drone". "An aircraft 636 which is intended to operate with no pilot on board." [ICAOUAS] 638 UAS 639 Unmanned Aircraft System. Composed of UA, all required on-board 640 subsystems, payload, control station, other required off-board 641 subsystems, any required launch and recovery equipment, all 642 required crew members, and C2 links between UA and control 643 station. [F3411-19] 645 UAS ID 646 UAS identifier. Although called "UAS ID", unique to the UA, 647 neither to the operator (as some UAS registration numbers have 648 been and for exclusively recreational purposes are continuing to 649 be assigned), nor to the combination of GCS and UA that comprise 650 the UAS. Maximum length of 20 bytes. [F3411-19] 652 UAS ID Type 653 UAS Identifier type index. 4 bits, see Section 3, Paragraph 5 for 654 currently defined values 0-3. [F3411-19] 656 UAS RID 657 UAS Remote Identification and tracking. System to enable 658 arbitrary Observers to identify UA during flight. 660 UAS RID Verifier Service 661 System component designed to handle the authentication 662 requirements of RID by offloading verification to a web hosted 663 service. [F3411-19] 665 USS 666 UAS Service Supplier. "A USS is an entity that assists UAS 667 Operators with meeting UTM operational requirements that enable 668 safe and efficient use of airspace" and "... provide services to 669 support the UAS community, to connect Operators and other entities 670 to enable information flow across the USS Network, and to promote 671 shared situational awareness among UTM participants" per 672 [FAACONOPS]. 674 UTM 675 UAS Traffic Management. "A specific aspect of air traffic 676 management which manages UAS operations safely, economically and 677 efficiently through the provision of facilities and a seamless set 678 of services in collaboration with all parties and involving 679 airborne and ground-based functions." [ICAOUTM] In the US, per 680 FAA, a "traffic management" ecosystem for "uncontrolled" low 681 altitude UAS operations, separate from, but complementary to, the 682 FAA's ATC system for "controlled" operations of manned aircraft. 684 V2V 685 Vehicle-to-Vehicle. Originally communications between 686 automobiles, now extended to apply to communications between 687 vehicles generally. Often, together with Vehicle-to- 688 Infrastructure (V2I) etc., generalized to V2X. 690 V-LOS 691 Visual LOS. Typically used in describing operation of an UA by a 692 "remote" pilot who can clearly directly (without video cameras or 693 any other aids other than glasses or under some rules binoculars) 694 see the UA and its immediate flight environment. Potentially 695 subject to blockage by foliage, structures, terrain or other 696 vehicles, more so than RF-LOS. 698 3. UAS RID Problem Space 700 Civil Aviation Authorities (CAAs) worldwide are mandating UAS RID. 701 The European Union Aviation Safety Agency (EASA) has published 702 [Delegated] and [Implementing] Regulations. The US FAA has described 703 the key role that UAS RID plays in UAS Traffic Management (UTM) in 704 [NPRM] and [FAACONOPS] (especially Section 2.6 of the latter). CAAs 705 currently (2020) promulgate performance-based regulations that do not 706 specify techniques, but rather cite industry consensus technical 707 standards as acceptable means of compliance. 709 ASTM developed a widely cited Standard Specification for Remote ID 710 and Tracking [F3411-19] (early drafts are freely available as 711 [OpenDroneID] specifications). It defines two means of UAS RID: 713 Network RID defines a set of information for UAS to make available 714 globally indirectly via the Internet, through servers that can be 715 queried by Observers. 717 Broadcast RID defines a set of messages for UA to transmit locally 718 directly one-way over Bluetooth or Wi-Fi (without IP or any other 719 protocols between the data link and application layer), to be 720 received in real time by local Observers. 722 UAS using both means must send the same UAS RID application layer 723 information via each per [F3411-19] and [NPRM]. The presentation may 724 differ, as Network RID defines a data dictionary, whereas Broadcast 725 RID defines message formats (which carry items from that same data 726 dictionary). The interval (or rate) at which it is sent may differ, 727 as Network RID can accommodate Observer queries asynchronous to UAS 728 updates (which generally need be sent only when information, such as 729 location, changes), whereas Broadcast RID depends upon Observers 730 receiving UA messages at the time they are transmitted. Network RID 731 depends upon Internet connectivity in several segments from the UAS 732 to each Observer. Broadcast RID should need Internet (or other Wide 733 Area Network) connectivity only for UAS registry information lookup 734 using the directly locally received UAS Identifier (UAS ID) as a key. 735 Broadcast RID does not assume IP connectivity of UAS; messages are 736 encapsulated by the UA without IP, directly in Bluetooth or WiFi link 737 layer frames. 739 [F3411-19] specifies three UAS ID types: 741 TYPE-1 A static, manufacturer assigned, hardware serial number per 742 ANSI/CTA-2063-A "Small Unmanned Aerial System Serial Numbers" 743 [CTA2063A]. 745 TYPE-2 A CAA assigned (generally static) ID, like the registration 746 number of a manned aircraft. 748 TYPE-3 A UTM system assigned UUID [RFC4122], which can but need not 749 be dynamic. 751 Per [Delegated], the EU allows only Type 1. Per [NPRM], the US 752 allows Types 1 and 3, but requires Type 3 IDs (if used) each to be 753 used only once as a "Session ID" (for a single UAS flight, which in 754 the context of UTM is called an "operation"). Per [Delegated], the 755 EU also requires an operator registration number (an additional 756 identifier distinct from the UAS ID) that can be carried in an 757 [F3411-19] optional Operator ID message. Per [NPRM], the US allows 758 but does not require that operator registration numbers be sent. As 759 yet apparently there are no CAA public proposals to use Type 2. 761 3.1. Network RID 763 x x UA 764 xxxxx ******************** 765 | * ------*---+------------+ 766 | * / * | NET_Rid_SP | 767 | * ------------/ +---*--+------------+ 768 | RF */ | * 769 | * INTERNET | * +------------+ 770 | /* +---*--| NET_Rid_DP | 771 | / * +----*--+------------+ 772 + / * | * 773 x / ****************|*** x 774 xxxxx | xxxxx 775 x +------- x 776 x x 777 x x Operator's GCS Observer x x 778 x x x x 779 Figure 3: "Network RID Information Flow" 781 Note the data flow typically originates on or at least passes through 782 the Ground Control Station (GCS), rather than comes direct from the 783 UA as in Broadcast RID (below), and makes up to 3 trips through the 784 Internet, implying use of IP (and other middle layer protocols) on 785 those trips, but not necessarily on the UA-GCS link (if indeed the 786 Network RID data even flows across that link). 788 Network RID is essentially publish-subscribe-query. In the typical 789 UTM context... First the UAS operator pushes an operation plan to the 790 USS that will serve that UAS for that operation, for deconfliction 791 with other operations. Assuming the plan receives approval and the 792 operation commences, that UAS periodically pushes location/status 793 updates to that USS (call it USS#1), which serves as the Network RID 794 Service Provider (Net-RID SP) for that operation. If users of any 795 other USS (whether they be other UAS operators or Observers) develop 796 an interest in any 4-D airspace volume intersecting the 4-D volume 797 containing that UAS operation, they query their own USS (call them 798 USS#2 through USS#n). Their USS query, via the UTM Discovery and 799 Synchronization Service (DSS), all other USS in the UTM system, and 800 learn that USS#1 has such operations. Observers or other interested 801 parties can then subscribe to track updates, via their own USS, which 802 serve as Network RID Display Providers (Net-RID DP) for that 803 surveillance session. The Net-RID SP (USS#1) will then publish 804 updates of the UAS position/status to all subscribed Net-RID DP 805 (USS#2 through USS#n), which in turn will deliver the information to 806 their users via unspecified (but expected to be web browser based) 807 means. 809 Network RID has several variants. The UA may have persistent onboard 810 Internet connectivity, in which case it can consistently source RID 811 information directly over the Internet. The UA may have intermittent 812 onboard Internet connectivity, in which case the GCS must source RID 813 information whenever the UA itself is offline. The UA may not have 814 Internet connectivity of its own, but have instead some other form of 815 communications to another node that can relay RID information to the 816 Internet; this would typically be the GCS (which to perform its 817 function must know where the UA is, although C2 link outages do 818 occur). 820 The UA may have no means of sourcing RID information, in which case 821 the GCS must source it; this is typical under FAA NPRM Limited RID 822 proposed rules, which require providing the location of the GCS (not 823 that of the UA). In the extreme case, this could be the pilot using 824 a web browser/application to designate, to an UAS Service Supplier 825 (USS) or other UTM entity, a time-bounded airspace volume in which an 826 operation will be conducted; this may impede disambiguation of ID if 827 multiple UAS operate in the same or overlapping spatio-temporal 828 volumes. 830 In most cases in the near term, if the RID information is fed to the 831 Internet directly by the UA or GCS, the first hop data links will be 832 cellular Long Term Evolution (LTE) or Wi-Fi, but provided the data 833 link can support at least UDP/IP and ideally also TCP/IP, its type is 834 generally immaterial to the higher layer protocols. An UAS as the 835 ultimate source of Network RID information feeds an USS acting as a 836 Network RID Service Provider (Net-RID SP), which essentially proxies 837 for that and other sources; an observer or other ultimate consumer of 838 Network RID information obtains it from a Network RID Display 839 Provider (Net-RID DP), which aggregates information from multiple 840 Net-RID SPs to offer airspace Situational Awareness (SA) coverage of 841 a volume of interest. Network RID Service and Display providers are 842 expected to be implemented as servers in well-connected 843 infrastructure, accessible via typical means such as web APIs/ 844 browsers. 846 Network RID is the more flexible and less constrained of the defined 847 UAS RID means, but is only partially specified in [F3411-19]. It is 848 presumed that IETF efforts supporting Broadcast RID (see next 849 section) can be easily generalized for Network RID. 851 3.2. Broadcast RID 853 x x UA 854 xxxxx 855 | 856 | 857 | app messages directly over one-way RF data link (no IP) 858 | 859 | 860 + 861 x 862 xxxxx 863 x 864 x 865 x x Observer's device (e.g. smartphone) 866 x x 867 Figure 4: "Broadcast RID Information Flow" 869 Note the absence of the Internet from this information flow sketch. 870 This is because Broadcast RID is one-way direct transmission of 871 application layer messages over a RF data link (without IP or other 872 middle layer protocols) from the UA to local Observer devices. 873 Internet connectivity is involved only in what the Observer chooses 874 to do with the information received, such as verify signatures using 875 a web based verifier service and look up information in registries 876 using the UAS ID as the primary unique key. 878 Broadcast RID is conceptually similar to Automatic Dependent 879 Surveillance - Broadcast (ADS-B). However, for various technical and 880 other reasons, regulators including the EASA and FAA have not 881 indicated intent to allow, and FAA has proposed explicitly to 882 prohibit, use of ADS-B for UAS RID. 884 [F3411-19] specifies three Broadcast RID data links: Bluetooth 4.X; 885 Bluetooth 5.X Long Range; and Wi-Fi with Neighbor Awareness 886 Networking (NAN). For compliance with [F3411-19], an UA must 887 broadcast (using advertisement mechanisms where no other option 888 supports broadcast) on at least one of these; if broadcasting on 889 Bluetooth 5.x, it is also required concurrently to do so on 4.x 890 (referred to in [F3411-19] as Bluetooth Legacy). Future revisions 891 may allow other data links. 893 The selection of the Broadcast media was driven by research into what 894 is commonly available on 'ground' units (smartphones and tablets) and 895 what was found as prevalent or 'affordable' in UA. Further, there 896 must be an Application Programming Interface (API) for the observer's 897 receiving application to have access to these messages. As yet only 898 Bluetooth 4.X support is readily available, thus the current focus is 899 on working within the 26 byte limit of the Bluetooth 4.X "Broadcast 900 Frame" transmitted on beacon channels. After nominal overheads, this 901 limits the UAS ID string to a maximum length of 20 bytes, and 902 precludes the same frame carrying position, velocity and other 903 information that should be bound to the UAS ID, much less strong 904 authentication data. This requires segmentation ("paging") of longer 905 messages or message bundles ("Message Pack"), and/or correlation of 906 short messages (anticipated by ASTM to be done on the basis of 907 Bluetooth 4 MAC address, which is weak and unverifiable). 909 [F3411-19] Broadcast RID specifies several message types: Basic, 910 Location, Authentication, Self-ID, System and Operator ID. To 911 satisfy EASA and FAA proposed rules, all types are needed, except 912 Authentication and Self-ID. 914 [F3411-19] Broadcast RID specifies very few quantitative performance 915 requirements: static information must be transmitted at least once 916 per 3 seconds; dynamic information (the Location message) must be 917 transmitted at least once per second and be no older than one second 918 when sent. [NPRM] proposes all information be sent at least once per 919 second. 921 [F3411-19] Broadcast RID transmits all information as cleartext 922 (ASCII or binary), so static IDs enable trivial correlation of 923 patterns of use, unacceptable in many applications, e.g., package 924 delivery routes of competitors. 926 Any UA can assert any ID using the [F3411-19] required Basic ID 927 message, which lacks any provisions for verification. The Position/ 928 Vector message likewise lacks provisions for verification, and does 929 not contain the ID, so must be correlated somehow with a Basic ID 930 message: the developers of [F3411-19] have suggested using the MAC 931 addresses on the Broadcast RID data link, but these may be randomized 932 by the operating system stack to avoid the adversarial correlation 933 problems of static identifiers. 935 The [F3411-19] optional Authentication Message specifies framing for 936 authentication data, but does not specify any authentication method, 937 and the maximum length of the specified framing is too short for 938 conventional digital signatures and far too short for conventional 939 certificates. The one-way nature of Broadcast RID precludes 940 challenge-response security protocols (e.g., observers sending nonces 941 to UA, to be returned in signed messages). An observer would be 942 seriously challenged to validate the asserted UAS ID or any other 943 information about the UAS or its operator looked up therefrom. 945 3.3. DRIP Focus 947 In addition to the gaps described above, there is a fundamental gap 948 in almost all current or proposed regulations and technical standards 949 for UAS RID. As noted above, ID is not an end in itself, but a 950 means. [F3411-19] etc. provide very limited choices for an observer 951 to communicate with the pilot, e.g., to request further information 952 on the UAS operation or exit from an airspace volume in an emergency. 953 The System Message provides the location of the pilot/GCS, so an 954 observer could physically go to the asserted location to look for the 955 remote pilot; this is at best slow, and may not be feasible -- what 956 if the pilot is on the opposite rim of a canyon, or there are 957 multiple UAS operators to be contacted whose GCS all lie in different 958 directions from the Observer? An observer with Internet connectivity 959 and access privileges could look up operator PII in a registry, then 960 call a phone number in hopes someone who can immediately influence 961 the UAS operation will answer promptly during that operation; this is 962 unreliable. Internet technologies can do much better than this. 964 Thus complementing [F3411-19] with protocols enabling strong 965 authentication, preserving operator privacy while enabling immediate 966 use of information by authorized parties, is critical to achieve 967 widespread adoption of a RID system supporting safe and secure 968 operation of UAS. 970 DRIP will focus on making information obtained via UAS RID 971 immediately usable: 973 1. by making it trustworthy (despite the severe constraints of 974 Broadcast RID); 976 2. by enabling verification that an UAS is registered for RID, and 977 if so, in which registry (for classification of trusted operators 978 on the basis of known registry vetting, even by observers lacking 979 Internet connectivity at observation time); 981 3. by facilitating independent reports of UA aeronautical data 982 (location, velocity, etc.) to confirm or refute the operator 983 self-reports upon which UAS RID and UTM tracking are based; 985 4. by enabling instant establishment, by authorized parties, of 986 secure communications with the remote pilot. 988 4. Requirements 990 4.1. General 991 GEN-1 Provable Ownership: DRIP MUST enable verification that the 992 UAS ID asserted in the Basic ID message is that of the actual 993 current sender of the message (i.e. the message is not a 994 replay attack or other spoof, authenticating e.g. by 995 verifying an asymmetric cryptographic signature using a 996 sender provided public key from which the asserted ID can be 997 at least partially derived), even on an observer device 998 lacking Internet connectivity at the time of observation. 1000 GEN-2 Provable Binding: DRIP MUST enable binding all other 1001 [F3411-19] messages from the same actual current sender to 1002 the UAS ID asserted in the Basic ID message. 1004 GEN-3 Provable Registration: DRIP MUST enable verification that the 1005 UAS ID is in a registry and identification of which one, even 1006 on an observer device lacking Internet connectivity at the 1007 time of observation; with UAS ID Type 3, the same sender may 1008 have multiple IDs, potentially in different registries, but 1009 each ID must clearly indicate in which registry it can be 1010 found. 1012 GEN-4 Readability: DRIP MUST enable information (regulation 1013 required elements, whether sent via UAS RID or looked up in 1014 registries) to be read and utilized by both humans and 1015 software. 1017 GEN-5 Gateway: DRIP MUST enable Broadcast RID to Network RID 1018 application layer gateways to stamp messages with precise 1019 date/time received and receiver location, then relay them to 1020 a network service (e.g. SDSP or distributed ledger), to 1021 support three objectives: mark up a RID message with where 1022 and when it was actually received (which may agree or 1023 disagree with the self-report in the set of messages); defend 1024 against replay attacks; and support optional SDSP services 1025 such as multilateration (to complement UAS position self- 1026 reports with independent measurements). 1028 GEN-6 Finger: DRIP MUST enable dynamically establishing, with AAA, 1029 per policy, end to end strongly encrypted communications with 1030 the UAS RID sender and entities looked up from the UAS ID, 1031 including at least the remote pilot and USS. 1033 GEN-7 QoS: DRIP MUST enable policy based specification of 1034 performance and reliability parameters, such as maximum 1035 message transmission intervals and delivery latencies. 1037 GEN-8 Mobility: DRIP MUST support physical and logical mobility of 1038 UA, GCS and Observers. DRIP SHOULD support mobility of 1039 essentially all participating nodes (UA, GCS, Observers, Net- 1040 RID SP, Net-RID DP, Private Registry, SDSP). 1042 GEN-9 Multihoming: DRIP MUST support multihoming of UA and GCS, for 1043 make-before-break smooth handoff and resiliency against path/ 1044 link failure. DRIP SHOULD support multihoming of essentially 1045 all participating nodes. 1047 GEN-10 Multicast: DRIP SHOULD support multicast for efficient and 1048 flexible publish-subscribe notifications, e.g., of UAS 1049 reporting positions in designated airspace volumes. 1051 GEN-11 Management: DRIP SHOULD support monitoring of the health and 1052 coverage of Broadcast and Network RID services. 1054 Requirements imposed either by regulation or [F3411-19] are not 1055 reiterated here, but drive many of the numbered requirements listed 1056 here. The QoS requirement currently would be satisfied generally by 1057 ensuring information refresh rates of at least 1 Hertz, with 1058 latencies no greater than 1 second, at least 80% of the time; but 1059 these numbers may change, so instead the DRIP requirement is that 1060 they be user policy specifiable (which does not imply satisfiable in 1061 all cases, but implies that when the specs are not met, appropriate 1062 parties are notified). The "provable ownership" requirement 1063 addresses the possibility that the actual sender is not the claimed 1064 sender (i.e. is a spoofer). The "provable binding" requirement 1065 addresses the MAC address correlation problem of [F3411-19] noted 1066 above. The "provable registration" requirement may impose burdens 1067 not only on the UAS sender and the Observer's receiver, but also on 1068 the registry; yet it cannot depend upon the Observer being able to 1069 contact the registry at the time of observing the UA. The 1070 "readability" requirement may involve machine assisted format 1071 conversions, e.g. from binary encodings. The "gateway" requirement 1072 is the only instance in which DRIP transports [F3411-19] messages; 1073 most of DRIP pertains to the authentication of such messages and the 1074 identifier carried within them. 1076 4.2. Identifier 1078 ID-1 Length: The DRIP (UAS) entity (remote) identifier must be no 1079 longer than 20 bytes (per [F3411-19] to fit in a Bluetooth 4 1080 advertisement payload). 1082 ID-2 Registry ID: The DRIP identifier MUST be sufficient to identify 1083 a registry in which the (UAS) entity identified therewith is 1084 listed. 1086 ID-3 Entity ID: The DRIP identifier MUST be sufficient to enable 1087 lookup of other data associated with the (UAS) entity 1088 identified therewith in that registry. 1090 ID-4 Uniqueness: The DRIP identifier MUST be unique within the 1091 global UAS RID identifier space from when it is first 1092 registered therein until it is explicitly de-registered 1093 therefrom (due to e.g. expiration after a specified lifetime 1094 such as the FAA's proposed 6 months RID data retention period, 1095 revocation by the registry, or surrender by the operator). 1097 ID-5 Non-spoofability: The DRIP identifier MUST be non-spoofable 1098 within the context of Remote ID broadcast messages (some 1099 collection of messages provides proof of UA ownership of ID). 1101 ID-6 Unlinkability: A DRIP UAS ID MUST NOT facilitate adversarial 1102 correlation over multiple UAS operations; this may be 1103 accomplished e.g. by limiting each identifier to a single use, 1104 but if so, the UAS ID MUST support well-defined scalable timely 1105 registration methods. 1107 The DRIP identifier can be used at various layers: in Broadcast RID, 1108 it would be used by the application running directly over the data 1109 link; in Network RID, it would be used by the application running 1110 over HTTPS (and possibly other protocols); and in RID initiated V2X 1111 applications such as DAA and C2, it could be used between the network 1112 and transport layers (with HIP or DTLS). 1114 Registry ID (which registry the entity is in) and Entity ID (which 1115 entity it is, within that registry) are requirements on a single DRIP 1116 entity Identifier, not separate (types of) ID. In the most common 1117 use case, the Entity will be the UA, and the DRIP Identifier will be 1118 the UAS ID; however, other entities may also benefit from having DRIP 1119 identifiers, so the Entity type is not prescribed here. 1121 Whether a UAS ID is generated by the operator, GCS, UA, USS or 1122 registry, or some collaboration thereamong, is unspecified; however, 1123 there must be agreement on the UAS ID among these entities. 1125 4.3. Privacy 1127 PRIV-1 Confidential Handling: DRIP MUST enable confidential handling 1128 of private information (i.e., any and all information 1129 designated by neither cognizant authority nor the information 1130 owner as public, e.g., personal data). 1132 PRIV-2 Encrypted Transport: DRIP MUST enable selective strong 1133 encryption of private data in motion in such a manner that 1134 only authorized actors can recover it. If transport is via 1135 IP, then encryption MUST be end-to-end, at or above the IP 1136 layer. DRIP MUST NOT encrypt safety critical data to be 1137 transmitted over Broadcast RID in any situation where it is 1138 unlikely that local observers authorized to access the 1139 plaintext will be able to decrypt it or obtain it from a 1140 service able to decrypt it. DRIP MUST NOT encrypt data when/ 1141 where doing so would conflict with applicable regulations or 1142 CAA policies/procedures, i.e. DRIP MUST support configurable 1143 disabling of encryption. 1145 PRIV-3 Encrypted Storage: DRIP SHOULD facilitate selective strong 1146 encryption of private data at rest in such a manner that only 1147 authorized actors can recover it. 1149 PRIV-4 Public/Private Designation: DRIP SHOULD facilitate 1150 designation, by cognizant authorities and information owners, 1151 which information is public and which private. By default, 1152 all information required to be transmitted via Broadcast RID, 1153 even when actually sent via Network RID, is assumed to be 1154 public; all other information contained in registries for 1155 lookup using the UAS ID is assumed to be private. 1157 PRIV-5 Pseudonymous Rendezvous: DRIP MAY enable mutual discovery of 1158 and communications among participating UAS operators whose UA 1159 are in 4-D proximity, using the UAS ID without revealing 1160 pilot/operator identity or physical location. 1162 How information is stored on end systems is out of scope for DRIP. 1163 Encouraging privacy best practices, including end system storage 1164 encryption, by facilitating it with protocol design reflecting such 1165 considerations, is in scope. Similar logic applies to methods for 1166 designating information as public or private. 1168 The privacy requirements above are for DRIP, neither for [F3411-19] 1169 (which requires obfuscation of location to any Network RID subscriber 1170 engaging in wide area surveillance, limits data retention periods, 1171 etc. in the interests of privacy), nor for UAS RID in any specific 1172 jurisdiction (which may have its own regulatory requirements). The 1173 requirements above are also in a sense parameterized: who are the 1174 "authorized actors", how are they designated, how are they 1175 authenticated, etc.? 1177 4.4. Registries 1178 REG-1 Public Lookup: DRIP MUST enable lookup, from the UAS ID, of 1179 information designated by cognizant authority as public, and 1180 MUST NOT restrict access to this information based on identity 1181 or role of the party submitting the query. 1183 REG-2 Private Lookup: DRIP MUST enable lookup of private information 1184 (i.e., any and all information in a registry, associated with 1185 the UAS ID, that is designated by neither cognizant authority 1186 nor the information owner as public), and MUST, per policy, 1187 enforce AAA, including restriction of access to this 1188 information based on identity or role of the party submitting 1189 the query. 1191 REG-3 Provisioning: DRIP MUST enable provisioning registries with 1192 static information on the UAS and its operator, dynamic 1193 information on its current operation within the U-space / UTM 1194 (including means by which the USS under which the UAS is 1195 operating may be contacted for further, typically even more 1196 dynamic, information), and Internet direct contact information 1197 for services related to the foregoing. 1199 REG-4 AAA Policy: DRIP MUST enable closing the AAA-policy registry 1200 loop by governing AAA per registered policies and 1201 administering policies only via AAA. 1203 Registries are fundamental to RID. Only very limited information can 1204 be Broadcast, but extended information is sometimes needed. The most 1205 essential element of information sent is the UAS ID itself, the 1206 unique key for lookup of extended information in registries. Beyond 1207 designating the UAS ID as that unique key, the registry information 1208 model is not specified herein, in part because regulatory 1209 requirements for different registries (UAS operators and their UA, 1210 each narrowly for UAS RID and broadly for U-space / UTM) and business 1211 models for meeting those requirements are in flux. However those may 1212 evolve, the essential registry functions remain the same, so are 1213 specified herein. 1215 5. IANA Considerations 1217 This document does not make any IANA request. 1219 6. Security Considerations 1221 DRIP is all about safety and security, so content pertaining to such 1222 is not limited to this section. Potential vulnerabilities of DRIP 1223 include but are not limited to: 1225 * Sybil attacks 1226 * Confusion created by many spoofed unsigned messages 1228 * Processing overload induced by attempting to verify many spoofed 1229 signed messages (where verification will fail but still consume 1230 cycles) 1232 * Malicious or malfunctioning registries 1234 * Interception of (e.g. Man In The Middle attacks on) registration 1235 messages 1237 * UA impersonation through private key extraction, improper key 1238 sharing or carriage of a small (presumably harmless) UA, e.g. as a 1239 "false flag", by a larger (malicious) UA 1241 It may be inferred from the Section 4.1 General requirements for 1242 Provable Ownership, Provable Binding and Provable Registration, 1243 together with the Section 4.2 Identifier requirements, that DRIP must 1244 provide: 1246 * message integrity / non-repudiation 1248 * defense against replay attacks 1250 * defense against spoofing 1252 One approach to so doing involves verifiably binding the DRIP 1253 identifier to a public key. Providing these security features, 1254 whether via this approach or another, is likely to be especially 1255 challenging for Observers without Internet connectivity at the time 1256 of observation. E.g. checking the signature of a registry on a 1257 public key certificate received via Broadcast RID in a remote area 1258 presumably would require that the registry's public key had been 1259 previously installed on the Observer's device, yet there may be many 1260 registries and the Observer's device may be storage constrained, and 1261 new registries may come on-line subsequent to installation of DRIP 1262 software on the Observer's device. Thus there may be caveats on the 1263 extent to which requirements can be satisfied in such cases, yet 1264 strenuous effort should be made to satisfy them, as such cases, e.g. 1265 firefighting in a national forest, are important. 1267 7. Privacy and Transparency Considerations 1269 Privacy is closely related to but not synonymous with security, and 1270 conflicts with transparency. Privacy and transparency are important 1271 for legal reasons including regulatory consistency. [EU2018] 1272 [EU2018] states "harmonised and interoperable national registration 1273 systems... should comply with the applicable Union and national law 1274 on privacy and processing of personal data, and the information 1275 stored in those registration systems should be easily accessible." 1277 Privacy and transparency (where essential to security or safety) are 1278 also ethical and moral imperatives. Even in cases where old 1279 practices (e.g. automobile registration plates) could be imitated, 1280 when new applications involving PII (such as UAS RID) are addressed 1281 and newer technologies could enable improving privacy, such 1282 opportunities should not be squandered. Thus it is recommended that 1283 all DRIP documents give due regard to [RFC6973] and more broadly 1284 [RFC8280]. 1286 DRIP information falls into two classes: that which, to achieve the 1287 purpose, must be published openly as cleartext, for the benefit of 1288 any Observer (e.g., the basic UAS ID itself); and that which must be 1289 protected (e.g., PII of pilots) but made available to properly 1290 authorized parties (e.g., public safety personnel who urgently need 1291 to contact pilots in emergencies). How properly authorized parties 1292 are authorized, authenticated, etc. are questions that extend beyond 1293 the scope of DRIP, but DRIP may be able to provide support for such 1294 processes. Classification of information as public or private must 1295 be made explicit and reflected with markings, design, etc. 1296 Classifying the information will be addressed primarily in external 1297 standards; herein it will be regarded as a matter for CAA, registry 1298 and operator policies, for which enforcement mechanisms will be 1299 defined within the scope of DRIP WG and offered. Details of the 1300 protection mechanisms will be provided in other DRIP documents. 1301 Mitigation of adversarial correlation will also be addressed. 1303 8. References 1305 8.1. Normative References 1307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1308 Requirement Levels", BCP 14, RFC 2119, 1309 DOI 10.17487/RFC2119, March 1997, 1310 . 1312 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1313 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1314 May 2017, . 1316 8.2. Informative References 1318 [cpdlc] Gurtov, A., Polishchuk, T., and M. Wernberg, "Controller- 1319 Pilot Data Link Communication Security", MDPI 1320 Sensors 18(5), 1636, 2018, 1321 . 1323 [CTA2063A] ANSI, "Small Unmanned Aerial Systems Serial Numbers", 1324 September 2019. 1326 [Delegated] 1327 European Union Aviation Safety Agency (EASA), "Commission 1328 Delegated Regulation (EU) 2019/945 of 12 March 2019 on 1329 unmanned aircraft systems and on third-country operators 1330 of unmanned aircraft systems", March 2019. 1332 [drip-architecture] 1333 Card, S., Wiethuechter, A., Moskowitz, R., Zhao, S., and 1334 A. Gurtov, "Drone Remote Identification Protocol (DRIP) 1335 Architecture", Work in Progress, Internet-Draft, draft- 1336 ietf-drip-arch-03, 13 July 2020, 1337 . 1339 [ENISACSIRT] 1340 European Union Agency for Cybersecurity (ENISA), 1341 "Actionable information for Security Incident Response", 1342 November 2014, . 1346 [EU2018] European Parliament and Council, "2015/0277 (COD) PE-CONS 1347 2/18", February 2018. 1349 [F3411-19] ASTM International, "Standard Specification for Remote ID 1350 and Tracking", February 2020, 1351 . 1353 [FAACONOPS] 1354 FAA Office of NextGen, "UTM Concept of Operations v2.0", 1355 March 2020. 1357 [I-D.maeurer-raw-ldacs] 1358 Maeurer, N., Graeupl, T., and C. Schmitt, "L-band Digital 1359 Aeronautical Communications System (LDACS)", Work in 1360 Progress, Internet-Draft, draft-maeurer-raw-ldacs-06, 2 1361 October 2020, 1362 . 1364 [ICAOATM] International Civil Aviation Organization, "Doc 4444: 1365 Procedures for Air Navigation Services: Air Traffic 1366 Management", November 2016. 1368 [ICAOUAS] International Civil Aviation Organization, "Circular 328: 1369 Unmanned Aircraft Systems", February 2011. 1371 [ICAOUTM] International Civil Aviation Organization, "Unmanned 1372 Aircraft Systems Traffic Management (UTM) - A Common 1373 Framework with Core Principles for Global Harmonization, 1374 Edition 2", November 2019. 1376 [Implementing] 1377 European Union Aviation Safety Agency (EASA), "Commission 1378 Implementing Regulation (EU) 2019/947 of 24 May 2019 on 1379 the rules and procedures for the operation of unmanned 1380 aircraft", May 2019. 1382 [InitialView] 1383 SESAR Joint Undertaking, "Initial view on Principles for 1384 the U-space architecture", July 2019. 1386 [NPRM] United States Federal Aviation Administration (FAA), 1387 "Notice of Proposed Rule Making on Remote Identification 1388 of Unmanned Aircraft Systems", December 2019. 1390 [OpenDroneID] 1391 Intel Corp., "Open Drone ID", March 2019, 1392 . 1394 [Opinion1] European Union Aviation Safety Agency (EASA), "Opinion No 1395 01/2020: High-level regulatory framework for the U-space", 1396 March 2020. 1398 [Recommendations] 1399 FAA UAS Identification and Tracking Aviation Rulemaking 1400 Committee, "UAS ID and Tracking ARC Recommendations Final 1401 Report", September 2017. 1403 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1404 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1405 DOI 10.17487/RFC4122, July 2005, 1406 . 1408 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1409 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1410 . 1412 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1413 Morris, J., Hansen, M., and R. Smith, "Privacy 1414 Considerations for Internet Protocols", RFC 6973, 1415 DOI 10.17487/RFC6973, July 2013, 1416 . 1418 [RFC8280] ten Oever, N. and C. Cath, "Research into Human Rights 1419 Protocol Considerations", RFC 8280, DOI 10.17487/RFC8280, 1420 October 2017, . 1422 [Roadmap] American National Standards Institute (ANSI) Unmanned 1423 Aircraft Systems Standardization Collaborative (UASSC), 1424 "Standardization Roadmap for Unmanned Aircraft Systems 1425 draft v2.0", April 2020, . 1429 [Stranger] Heinlein, R.A., "Stranger in a Strange Land", June 1961. 1431 [WG105] EUROCAE, "WG-105 draft Minimum Operational Performance 1432 Standards (MOPS) for Unmanned Aircraft System (UAS) 1433 Electronic Identification", June 2020. 1435 Appendix A. Discussion and Limitations 1437 This document is largely based on the process of one SDO, ASTM. 1438 Therefore, it is tailored to specific needs and data formats of this 1439 standard. Other organizations, for example in EU, do not necessary 1440 follow the same architecture. 1442 The need for drone ID and operator privacy is an open discussion 1443 topic. For instance, in the ground vehicular domain each car carries 1444 a publicly visible plate number. In some countries, for nominal cost 1445 or even for free, anyone can resolve the identity and contact 1446 information of the owner. Civil commercial aviation and maritime 1447 industries also have a tradition of broadcasting plane or ship ID, 1448 coordinates and even flight plans in plain text. Community networks 1449 such as OpenSky and Flightradar use this open information through 1450 ADS-B to deploy public services of flight tracking. Many researchers 1451 also use these data to perform optimization of routes and airport 1452 operations. Such ID information should be integrity protected, but 1453 not necessarily confidential. 1455 In civil aviation, aircraft identity is broadcast by a device known 1456 as transponder. It transmits a four-digit squawk code, which is 1457 assigned by a traffic controller to an airplane after approving a 1458 flight plan. There are several reserved codes such as 7600 which 1459 indicate radio communication failure. The codes are unique in each 1460 traffic area and can be re-assigned when entering another control 1461 area. The code is transmitted in plain text by the transponder and 1462 also used for collision avoidance by a system known as Traffic alert 1463 and Collision Avoidance System (TCAS). The system could be used for 1464 UAS as well initially, but the code space is quite limited and likely 1465 to be exhausted soon. The number of UAS far exceeds the number of 1466 civil airplanes in operation. 1468 The ADS-B system is utilized in civil aviation for each "ADS-B Out" 1469 equipped airplane to broadcast its ID, coordinates and altitude for 1470 other airplanes and ground control stations. If this system is 1471 adopted for drone IDs, it has additional benefit with backward 1472 compatibility with civil aviation infrastructure; then, pilots and 1473 dispatchers will be able to see UA on their control screens and take 1474 those into account. If not, a gateway translation system between the 1475 proposed drone ID and civil aviation system should be implemented. 1476 Again, system saturation due to large numbers of UAS is a concern. 1478 Wi-Fi and Bluetooth are two wireless technologies currently 1479 recommended by ASTM specifications due to their widespread use and 1480 broadcast nature. However, those have limited range (max 100s of 1481 meters) and may not reliably deliver UAS ID at high altitude or 1482 distance. Therefore, a study should be made of alternative 1483 technologies from the telecom domain (WiMAX, 5G) or sensor networks 1484 (Sigfox, LORA). Such transmission technologies can impose additional 1485 restrictions on packet sizes and frequency of transmissions, but 1486 could provide better energy efficiency and range. In civil aviation, 1487 Controller-Pilot Data Link Communications (CPDLC) is used to transmit 1488 command and control between the pilots and ATC. It could be 1489 considered for UAS as well due to long range and proven use despite 1490 its lack of security [cpdlc]. 1492 L-band Digital Aeronautical Communications System (LDACS) is being 1493 standardized by ICAO and IETF for use in future civil aviation 1494 [I-D.maeurer-raw-ldacs]. It provides secure communication, 1495 positioning and control for aircraft using a dedicated radio band. 1496 It should be analyzed as a potential provider for UAS RID as well. 1497 This will bring the benefit of a global integrated system creating a 1498 global airspace use awareness. 1500 Acknowledgments 1502 The work of the FAA's UAS Identification and Tracking (UAS ID) 1503 Aviation Rulemaking Committee (ARC) is the foundation of later ASTM 1504 [F3411-19] and IETF DRIP efforts. The work of Gabriel Cox, Intel 1505 Corp. and their Open Drone ID collaborators opened UAS RID to a wider 1506 community. The work of ASTM F38.02 in balancing the interests of 1507 diverse stakeholders is essential to the necessary rapid and 1508 widespread deployment of UAS RID. IETF volunteers who have 1509 extensively reviewed or otherwise contributed to this document 1510 include Amelia Andersdotter, Carsten Bormann, Mohamed Boucadair, 1511 Toerless Eckert, Susan Hares, Mika Jarvenpaa, Daniel Migault, 1512 Alexandre Petrescu, Saulo Da Silva and Shuai Zhao. 1514 Authors' Addresses 1516 Stuart W. Card (editor) 1517 AX Enterprize 1518 4947 Commercial Drive 1519 Yorkville, NY 13495 1520 United States of America 1522 Email: stu.card@axenterprize.com 1524 Adam Wiethuechter 1525 AX Enterprize 1526 4947 Commercial Drive 1527 Yorkville, NY 13495 1528 United States of America 1530 Email: adam.wiethuechter@axenterprize.com 1532 Robert Moskowitz 1533 HTT Consulting 1534 Oak Park, MI 48237 1535 United States of America 1537 Email: rgm@labs.htt-consult.com 1539 Andrei Gurtov 1540 Linköping University 1541 IDA 1542 SE-58183 Linköping 1543 Sweden 1545 Email: gurtov@acm.org