idnits 2.17.1 draft-ietf-drip-reqs-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (25 May 2020) is 1425 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'UAS' is mentioned on line 793, but not defined == Outdated reference: A later version (-31) exists of draft-ietf-drip-arch-00 == Outdated reference: A later version (-06) exists of draft-maeurer-raw-ldacs-02 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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: 26 November 2020 R. Moskowitz 6 HTT Consulting 7 A. Gurtov 8 Linköping University 9 25 May 2020 11 Drone Remote Identification Protocol (DRIP) Requirements 12 draft-ietf-drip-reqs-01 14 Abstract 16 This document defines the 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 safety, regulatory compliance and other purposes. 21 Complementing external technical standards as regulator-accepted 22 means of compliance with UAS RID regulations, DRIP will: 24 facilitate use of existing Internet resources to support UAS RID 25 and to enable enhanced related services; 27 enable on-line and off-line verification that UAS RID information 28 is trustworthy. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 26 November 2020. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 6 65 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 6 66 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 67 3. UAS RID Problem Space . . . . . . . . . . . . . . . . . . . . 12 68 3.1. Network RID . . . . . . . . . . . . . . . . . . . . . . . 13 69 3.2. Broadcast RID . . . . . . . . . . . . . . . . . . . . . . 14 70 3.3. DRIP Focus . . . . . . . . . . . . . . . . . . . . . . . 14 71 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 15 72 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 4.2. Identifier . . . . . . . . . . . . . . . . . . . . . . . 17 74 4.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 18 75 4.4. Registries . . . . . . . . . . . . . . . . . . . . . . . 18 76 5. Discussion and Limitations . . . . . . . . . . . . . . . . . 19 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 79 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21 80 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 81 Normative References . . . . . . . . . . . . . . . . . . . . . 21 82 Informative References . . . . . . . . . . . . . . . . . . . . 21 83 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 86 1. Introduction 88 Many considerations (especially safety) dictate that UAS be remotely 89 identifiable. Any observer with responsibilities involving aircraft 90 inherently must classify them situationally according to basic 91 considerations, as illustrated notionally in Figure 1 below. 93 xxxxxxx +--------------+ 94 x x No | | 95 x ID? x+---->| UNIDENTIFIED | 96 x x | | 97 xxxxxxx +--------------+ 98 + 99 | Yes 100 v 101 xxxxxxx 102 x x 103 +---------+x TYPE? x+----------+ 104 | x x | 105 | xxxxxxx | 106 | + | 107 v v v 108 +--------------+ +--------------+ +--------------+ 109 | | | | | | 110 | TASKABLE | | LOW CONCERN | | HIGH CONCERN | 111 | | | | | | 112 +--------------+ +--------------+ +--------------+ 114 Figure 1 116 Civil Aviation Authorities (CAAs) worldwide are mandating Unmanned 117 Aircraft System Remote Identification and tracking (UAS RID). The 118 European Union Aviation Safety Agency (EASA) has published 119 [Delegated] and [Implementing] Regulations. The United States (US) 120 Federal Aviation Administration (FAA) has published a Notice of 121 Proposed Rule Making ([NPRM]) and has described the key role that UAS 122 RID plays in UAS Traffic Management (UTM [CONOPS] especially 123 Section 2.6). CAAs currently (2020) promulgate performance-based 124 regulations that do not specify techniques, but rather cite industry 125 consensus technical standards as acceptable means of compliance. 127 ASTM International, Technical Committee F38 (UAS), Subcommittee 128 F38.02 (Aircraft Operations), Work Item WK65041, developed ASTM 129 F3411-19 [F3411-19] Standard Specification for Remote ID and 130 Tracking. It defines two means of UAS RID: 132 Network RID defines a set of information for UAS to make available 133 globally indirectly via the Internet. 135 Broadcast RID defines a set of messages for Unmanned Aircraft (UA) 136 to transmit locally directly one-way over Bluetooth or Wi-Fi. 138 Generally the same information must provided via both means. Network 139 RID depends upon Internet connectivity in several segments from the 140 UAS to the observer. Broadcast RID should need Internet (or other 141 Wide Area Network) connectivity only for UAS registry information 142 lookup using the directly locally received UAS ID as a key. 144 [F3411-19] specifies 3 UAS ID types: 146 TYPE-1 A static, manufacturer assigned, hardware serial number per 147 ANSI/CTA-2063-A "Small Unmanned Aerial System Serial Numbers" 148 [CTA2063A]. 150 TYPE-2 A CAA assigned (presumably static) ID. 152 TYPE-3 A UTM system assigned UUID [RFC4122], which can but need not 153 be dynamic. 155 The EU allows only Type 1; the US allows Types 1 and 3, but requires 156 Type 3 IDs (if used) each to be used only once (for a single UAS 157 flight, which in the context of UTM is called an "operation"). 158 [F3411-19] Broadcast RID transmits all information in the clear as 159 plaintext (ASCII or binary), so static IDs enable trivial correlation 160 of patterns of use, unacceptable in many applications, e.g., package 161 delivery routes of competitors. 163 An ID is not an end in itself; it exists to enable lookups and 164 provision of services complementing mere identification. 166 Minimal specified information must be made available to the public; 167 access to other data, e.g., UAS operator Personally Identifiable 168 Information (PII), must be limited to strongly authenticated 169 personnel, properly authorized per policy. The balance between 170 privacy and transparency remains a subject for public debate and 171 regulatory action; DRIP can only offer tools to expand the achievable 172 trade space and enable trade-offs within that space. [F3411-19] 173 specifies only how to get the UAS ID to the observer; how the 174 observer can perform these lookups, and how the registries first can 175 be populated with information, is unspecified. 177 Using UAS RID to facilitate vehicular (V2X) communications and 178 applications such as Detect And Avoid (DAA, which would impose 179 tighter latency bounds than RID itself) is an obvious possibility, 180 explicitly contemplated in the FAA NPRM. However, applications of 181 RID beyond RID itself have been omitted from [F3411-19]; DAA has been 182 explicitly declared out of scope in ASTM working group discussions, 183 based on a distinction between RID as a security standard vs DAA as a 184 safety application. Although dynamic establishment of secure 185 communications between the observer and the UAS pilot seems to have 186 been contemplated by the FAA UAS ID and Tracking Aviation Rulemaking 187 Committee (ARC) in their [Recommendations], it is not addressed in 188 any of the subsequent proposed regulations or technical 189 specifications. 191 The need for near-universal deployment of UAS RID is pressing. This 192 implies the need to support use by observers of already ubiquitous 193 mobile devices (typically smartphones and tablets). Anticipating 194 likely CAA requirements to support legacy devices, especially in 195 light of [Recommendations], [F3411-19] specifies that any UAS sending 196 Broadcast RID over Bluetooth must do so over Bluetooth 4, regardless 197 of whether it also does so over newer versions; as UAS sender devices 198 and observer receiver devices are unpaired, this implies extremely 199 short "advertisement" (beacon) frames. 201 UA onboard RID devices are severely constrained in Cost, Size, Weight 202 and Power ($SWaP). Cost is a significant impediment to the necessary 203 near-universal adoption of UAS send and observer receive RID 204 capabilities. $SWaP is a burden not only on the designers of new UA 205 for production and sale, but also on owners of existing UA that must 206 be retrofit. Radio Controlled (RC) aircraft modelers, "hams" who use 207 licensed amateur radio frequencies to control UAS, drone hobbyists 208 and others who custom build UAS all need means of participating in 209 UAS RID sensitive to both generic $SWaP and application-specific 210 considerations. 212 To accommodate the most severely constrained cases, all these 213 conspire to motivate system design decisions, especially for the 214 Broadcast RID data link, which complicate the protocol design 215 problem: one-way links; extremely short packets; and Internet- 216 disconnected operation of UA onboard devices. Internet-disconnected 217 operation of observer devices has been deemed by ASTM F38.02 too 218 infrequent to address, but for some users is important and presents 219 further challenges. 221 Despite work by regulators and Standards Development Organizations 222 (SDOs), there are substantial gaps in UAS standards generally and UAS 223 RID specifically. [Roadmap] especially Section 7.8 catalogs UAS RID 224 standards, ongoing standardization activities and gaps. 226 Given not only packet payload length and bandwidth, but also 227 processing and storage within the $SWaP constraints of very small 228 (e.g. consumer toy) UA, heavyweight cryptographic security protocols 229 are infeasible, yet trustworthiness of UAS RID information is 230 essential. Under [F3411-19], even the most basic datum, the UAS ID 231 string (typically number) itself can be merely an unsubstantiated 232 claim. Observer devices being ubiquitous, thus popular targets for 233 malware or other compromise, cannot be generally trusted (although 234 the user of each device is compelled to trust that device, to some 235 extent); a "fair witness" functionality (inspired by [Stranger]) may 236 be desirable. 238 DRIP's initial goal is to make RID immediately actionable, in both 239 Internet and local-only connected scenarios (especially emergencies), 240 in severely constrained UAS environments, balancing legitimate (e.g., 241 public safety) authorities' Need To Know trustworthy information with 242 UAS operators' privacy. By "immediately actionable" is meant 243 information of sufficient precision, accuracy, timeliness, etc. for 244 an observer to use it as the basis for immediate decisive action, 245 whether that be to trigger a defensive counter-UAS system, to attempt 246 to initiate communications with the UAS operator, to accept the 247 presence of the UAS in the airspace where/when observed as not 248 requiring further action, or whatever, with potentially severe 249 consequences of any action or inaction chosen based on that 250 information. Potential follow-on goals may extend beyond providing 251 timely and trustworthy identification data, to using it to enable 252 identity-oriented networking of UAS. 254 DRIP (originally Trustworthy Multipurpose Remote Identification, TM- 255 RID) potentially could be applied to verifiably identify other types 256 of registered things reported to be in specified physical locations, 257 but the urgent motivation and clear initial focus is UAS. Existing 258 Internet resources (protocol standards, services, infrastructure, and 259 business models) should be leveraged. A natural Internet based 260 architecture for UAS RID conforming to proposed regulations and 261 external technical standards is described in a companion architecture 262 document [I-D.ietf-drip-arch]; this document describes only relevant 263 requirements. 265 2. Terms and Definitions 267 2.1. Requirements Terminology 269 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 270 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 271 "OPTIONAL" in this document are to be interpreted as described in BCP 272 14 [RFC2119] [RFC8174] when, and only when, they appear in all 273 capitals, as shown here. 275 2.2. Definitions 277 This section defines a set of terms that are used in DRIP documents. 278 This list is meant to be the DRIP terminology reference. Some of the 279 terms listed below are not used in this document. 281 $SWaP 282 Cost, Size, Weight and Power. 284 AAA 285 Attestation, Authentication, Authorization, Access Control, 286 Accounting, Attribution, Audit. 288 ABDAA 289 AirBorne DAA. Also known as "self-separation". 291 ADS-B 292 Automatic Dependent Surveillance - Broadcast. "ADS-B Out" 293 equipment obtains aircraft position from other on-board systems 294 (typically GPS) and periodically broadcasts it to "ADS-B In" 295 equipped entities, including other aircraft, ground stations and 296 satellite based monitoring systems. 298 AGL 299 Above Ground Level. Relative altitude, above the variously 300 defined local ground level, typically of an UA, typically measured 301 in feet. 303 ATC 304 Air Traffic Control. Explicit flight direction to pilots from 305 ground controllers. Contrast with ATM. 307 ATM 308 Air Traffic Management. All systems that assist aircraft from 309 departure to landing. A broader functional and geographic scope 310 and/or a higher layer of abstraction than ATC. 312 Authentication Message 313 F3411 Message Type 2. Provides framing for authentication data, 314 only. 316 Basic ID Message 317 F3411 Message Type 0. Provides UA Type, UAS ID Type and UAS ID, 318 only. 320 BLOS 321 Beyond Line Of Sight (LOS). Term to be avoided due to ambiguity. 322 See LOS. 324 BVLOS 325 Beyond Visual Line Of Sight (V-LOS). See V-LOS. 327 CAA 328 Civil Aviation Authority. Two examples are the United States 329 Federal Aviation Administration (FAA) and the European Union 330 Aviation Safety Agency (EASA). 332 C2 333 Command and Control. A set of organizational and technical 334 attributes and processes that employs human, physical, and 335 information resources to solve problems and accomplish missions. 336 Previously primarily used in military contexts. In the UAS 337 context, typically refers to the link between GCS and UA over 338 which the former controls the latter. 340 DAA 341 Detect And Avoid, formerly Sense And Avoid (SAA). A means of 342 keeping aircraft "well clear" of each other for safety. 344 Direct RID 345 Direct Remote Identification. Per [Delegated], "a system that 346 ensures the local broadcast of information about a UA in 347 operation, including the marking of the UA, so that this 348 information can be obtained without physical access to the UA". 349 Requirement could be met with ASTM Broadcast RID: Basic ID message 350 with UAS ID Type 1; Location/Vector message; Operator ID message; 351 System Message. Corresponds roughly to the Broadcast RID portion 352 of FAA NPRM Standard RID. 354 E2E 355 End to End. 357 GBDAA 358 Ground Based DAA. 360 GCS 361 Ground Control Station. The part of the UAS that the remote pilot 362 uses to exercise C2 over the UA, whether by remotely exercising UA 363 flight controls to fly the UA, by setting GPS waypoints, or 364 otherwise directing its flight. 366 GPS 367 Global Positioning System. In this context, misused in place of 368 Global Navigation Satellite System (GNSS) or more generally SATNAV 369 to refer generically to satellite based timing and/or positioning. 371 GRAIN 372 Global Resilient Aviation Information Network. An effort to 373 develop an international IPv6 overlay network with end-to-end 374 security supporting all aspects of aviation. 376 IATF 377 International Aviation Trust Framework. ICAO effort to develop a 378 resilient and secure by design framework for networking in support 379 of all aspects of aviation. 381 ICAO 382 International Civil Aviation Organization. A United Nations 383 specialized agency that develops and harmonizes international 384 standards relating to aviation. 386 LAANC 387 Low Altitude Authorization and Notification Capability. Supports 388 ATC authorization requirements for UAS operations: remote pilots 389 can apply to receive a near real-time authorization for operations 390 under 400 feet in controlled airspace near airports. US partial 391 stopgap until UTM comes. 393 Limited RID 394 Per the FAA NPRM, a mode of operation that must use Network RID, 395 must not use Broadcast RID, and must provide pilot/GCS location 396 only (not UA location). This mode is only allowed for UA that 397 neither require (due to e.g. size) nor are equipped for Standard 398 RID, operated within V-LOS and within 400 feet of the pilot, below 399 400 feet AGL, etc. 401 Location/Vector Message 402 F3411 Message Type 1. Provides UA location, altitude, heading and 403 speed, only. 405 LOS 406 Line Of Sight. An adjectival phrase describing any information 407 transfer that travels in a nearly straight line (e.g. 408 electromagnetic energy, whether in the visual light, RF or other 409 frequency range) and is subject to blockage. A term to be avoided 410 due to ambiguity, in this context, between RF-LOS and V-LOS. 412 MSL 413 Mean Sea Level. Relative altitude, above the variously defined 414 mean sea level, typically of an UA (but in FAA NPRM for a GCS), 415 typically measured in feet. 417 Net-RID DP 418 Network RID Display Provider. Logical entity that aggregates data 419 from Net-RID SPs as needed in response to user queries regarding 420 UAS operating within specified airspace volumes, to enable display 421 by a user application on a user device. Under the FAA NPRM, not 422 recognized as a distinct entity, but a service provided by USS, 423 including Public Safety USS that may exist primarily for this 424 purpose rather than to manage any subscribed UAS. 426 Net-RID SP 427 Network RID Service Provider. Logical entity that participates in 428 Network RID and provides to NetRID-DPs information on UAS it 429 manages. Under the FAA NPRM, the USS to which the UAS is 430 subscribed ("Remote ID USS"). 432 Network Identification Service 433 EU regulatory requirement for Network RID. Requirement could be 434 met with ASTM Network RID: Basic ID message with UAS ID Type 1; 435 Location/Vector message; Operator ID message; System Message. 436 Corresponds roughly to the Network RID portion of FAA NPRM 437 Standard RID. 439 Observer 440 Referred to in other UAS RID documents as a "user", but there are 441 also other classes of UAS RID users, so here "observer" is 442 preferred to denote specifically an individual who has observed an 443 UA and wishes to know something about it, starting with its ID. 445 Operator 446 UAS operator. Typically an organization that owns or leases the 447 UAS. 449 Operator ID Message 450 F3411 Message Type 5. Provides CAA issued Operator ID, only. 452 PII 453 Personally Identifiable Information. In this context, typically 454 of the UAS operator, Pilot In Command (PIC) or remote pilot, but 455 possibly of an observer or other party. 457 RF 458 Radio Frequency. May be used as an adjective or as a noun; in the 459 latter case, typically means Radio Frequency energy. 461 RF-LOS 462 RF LOS. Typically used in describing operation of a direct radio 463 link between a GCS and the UA under its control, potentially 464 subject to blockage by foliage, structures, terrain or other 465 vehicles, but less so than V-LOS. 467 Self-ID Message 468 F3411 Message Type 3. Provides a 1 byte descriptor and 23 byte 469 ASCII free text field, only. 471 Standard RID 472 Per the FAA NPRM, a mode of operation that must use both Network 473 RID (if Internet connectivity is available at the time in the 474 operating area) and Broadcast RID (always and everywhere), and 475 must provide both pilot/GCS location and UA location. This mode 476 is required for UAS that exceed the allowed envelope (e.g. size, 477 range) of Limited RID and for all UAS equipped for Standard RID 478 (even if operated within parameters that would otherwise permit 479 Limited RID). The Broadcast RID portion corresponds roughly to EU 480 Direct RID; the Network RID portion corresponds roughly to EU 481 Network Identification Service. 483 SDO 484 Standards Development Organization. ASTM, IETF, et al. 486 SDSP 487 Supplemental Data Service Provider. An entity that participates 488 in the UTM system, but provides services beyond those specified as 489 basic UTM system functions. 491 System Message 492 F3411 Message Type 4. Provides general UAS information, including 493 remote pilot location, multiple UA group operational area, etc. 495 U-space 496 EU concept and emerging framework for integration of UAS into all 497 classes of airspace, specifically including high density urban 498 areas, sharing airspace with manned aircraft. 500 UA 501 Unmanned Aircraft. An aircraft which is intended to operate with 502 no pilot on board. In popular parlance, "drone". Plural form of 503 UA is UA. 505 UAS 506 Unmanned Aircraft System. Composed of UA, all required on-board 507 subsystems, payload, control station, other required off-board 508 subsystems, any required launch and recovery equipment, all 509 required crew members, and C2 links between UA and control 510 station. Plural form of UAS is UAS. 512 UAS ID 513 UAS identifier. Although called "UAS ID", unique to the UA: 514 neither to the operator (as previous registration numbers have 515 been assigned), nor to the combination of GCS and UA that comprise 516 the UAS. Per [F3411-19], maximum length of 20 bytes. 518 UAS ID Type 519 Identifier type index. Per [F3411-19], 4 bits, values 0-3 already 520 specified. 522 UAS RID 523 UAS Remote Identification. System for identifying UA during 524 flight by other parties. 526 UAS RID Verification Service 527 System component designed to handle the authentication 528 requirements of RID by offloading verification to a web hosted 529 service. 531 USS 532 UAS Service Supplier. "A USS is an entity that assists UAS 533 Operators with meeting UTM operational requirements that enable 534 safe and efficient use of airspace" and "... provide services to 535 support the UAS community, to connect Operators and other entities 536 to enable information flow across the USS Network,and to promote 537 shared situational awareness among UTM participants." per 538 [CONOPS]. 540 UTM 541 UAS Traffic Management. Per ICAO, "A specific aspect of air 542 traffic management which manages UAS operations safely, 543 economically and efficiently through the provision of facilities 544 and a seamless set of services in collaboration with all parties 545 and involving airborne and ground-based functions." In the US, 546 per FAA, a "traffic management" ecosystem for "uncontrolled" low 547 altitude UAS operations, separate from, but complementary to, the 548 FAA's ATC system for "controlled" operations of manned aircraft. 550 V-LOS 551 Visual LOS. Typically used in describing operation of an UA by a 552 "remote" pilot who can clearly directly (without video cameras or 553 any other aids other than glasses or under some rules binoculars) 554 see the UA and its immediate flight environment. Potentially 555 subject to blockage by foliage, structures, terrain or other 556 vehicles, more so than RF-LOS. 558 3. UAS RID Problem Space 560 UA may be fixed wing Short Take-Off and Landing (STOL), rotary wing 561 (e.g., helicopter) Vertical Take-Off and Landing (VTOL), or hybrid. 562 They may be single engine or multi engine. The most common today are 563 multicopters: rotary wing, multi engine. The explosion in UAS was 564 enabled by hobbyist development, for multicopters, of advanced flight 565 stability algorithms, enabling even inexperienced pilots to take off, 566 fly to a location of interest, hover, and return to the take-off 567 location or land at a distance. UAS can be remotely piloted by a 568 human (e.g., with a joystick) or programmed to proceed from Global 569 Positioning System (GPS) waypoint to waypoint in a weak form of 570 autonomy; stronger autonomy is coming. UA are "low observable": they 571 typically have a small radar cross section; they make noise quite 572 noticeable at short range but difficult to detect at distances they 573 can quickly close (500 meters in under 17 seconds at 60 knots); they 574 typically fly at low altitudes (for the small UAS to which RID 575 applies in the US, under 400 feet AGL); they are highly maneuverable 576 so can fly under trees and between buildings. 578 UA can carry payloads including sensors, cyber and kinetic weapons, 579 or can be used themselves as weapons by flying them into targets. 580 They can be flown by clueless, careless or criminal operators. Thus 581 the most basic function of UAS RID is "Identification Friend or Foe" 582 (IFF) to mitigate the significant threat they present. Numerous 583 other applications can be enabled or facilitated by RID: consider the 584 importance of identifiers in many Internet protocols and services. 586 Network RID from the UA itself (rather than from its GCS) and 587 Broadcast RID require one or more wireless data links from the UA, 588 but such communications are challenging due to $SWaP constraints and 589 low altitude flight amidst structures and foliage over terrain. 591 Disambiguation of multiple UA flying in close proximity may be very 592 challenging, even if each is reporting its identity, position and 593 velocity as accurately as it can. 595 3.1. Network RID 597 Network RID has several variants. The UA may have persistent onboard 598 Internet connectivity, in which case it can consistently source RID 599 information directly over the Internet. The UA may have intermittent 600 onboard Internet connectivity, in which case the GCS must source RID 601 information whenever the UA itself is offline. The UA may not have 602 Internet connectivity of its own, but have instead some other form of 603 communications to another node that can relay RID information to the 604 Internet; this would typically be the GCS (which to perform its 605 function must know where the UA is). 607 The UA may have no means of sourcing RID information, in which case 608 the GCS must source it; this is typical under FAA NPRM Limited RID 609 proposed rules, which require providing the location of the GCS (not 610 that of the UA). In the extreme case, this could be the pilot using 611 a web browser to designate, to an UAS Service Supplier (USS) or other 612 UTM entity, a time-bounded airspace volume in which an operation will 613 be conducted; this may impede disambiguation of ID if multiple UAS 614 operate in the same or overlapping spatio-temporal volumes. 616 In most cases in the near term, if the RID information is fed to the 617 Internet directly by the UA or GCS, the first hop data links will be 618 cellular Long Term Evolution (LTE) or Wi-Fi, but provided the data 619 link can support at least UDP/IP and ideally also TCP/IP, its type is 620 generally immaterial to the higher layer protocols. An UAS as the 621 ultimate source of Network RID information feeds an USS acting as a 622 Network RID Service Provider (Net-RID SP), which essentially proxies 623 for that and other sources; an observer or other ultimate consumer of 624 Network RID information obtains it from a Network RID Display 625 Provider (Net-RID DP), which aggregates information from multiple 626 Net-RID SPs to offer coverage of an airspace volume of interest. 627 Network RID Service and Display providers are expected to be 628 implemented as servers in well-connected infrastructure, accessible 629 via typical means such as web APIs/browsers. 631 Network RID is the more flexible and less constrained of the defined 632 UAS RID means, but is only partially specified in [F3411-19]. It is 633 presumed that IETF efforts supporting Broadcast RID (see next 634 section) can be easily generalized for Network RID. 636 3.2. Broadcast RID 638 [F3411-19] specifies three Broadcast RID data links: Bluetooth 4.X; 639 Bluetooth 5.X Long Range; and Wi-Fi with Neighbor Awareness 640 Networking (NAN). For compliance with this standard, an UA must 641 broadcast (using advertisement mechanisms where no other option 642 supports broadcast) on at least one of these; if broadcasting on 643 Bluetooth 5.x, it is also required concurrently to do so on 4.x 644 (referred to in [F3411-19] as Bluetooth Legacy). 646 The selection of the Broadcast media was driven by research into what 647 is commonly available on 'ground' units (smartphones and tablets) and 648 what was found as prevalent or 'affordable' in UA. Further, there 649 must be an Application Programming Interface (API) for the observer's 650 receiving application to have access to these messages. As yet only 651 Bluetooth 4.X support is readily available, thus the current focus is 652 on working within the 26 byte limit of the Bluetooth 4.X "Broadcast 653 Frame" transmitted on beacon channels. After nominal overheads, this 654 limits the UAS ID string to a maximum length of 20 bytes, and 655 precludes the same frame carrying position, velocity and other 656 information that should be bound to the UAS ID, much less strong 657 authentication data. This requires segmentation ("paging") of longer 658 messages or message bundles ("Message Pack"), and/or correlation of 659 short messages (anticipated by ASTM to be done on the basis of 660 Bluetooth 4 MAC address, which is weak and unverifiable). 662 3.3. DRIP Focus 664 DRIP will focus on making information obtained via UAS RID 665 immediately usable: 667 1. by making it trustworthy (despite the severe constraints of 668 Broadcast RID); 670 2. by enabling verification that an UAS is registered, and if so, in 671 which registry (for classification of trusted operators on the 672 basis of known registry vetting, even by observers lacking 673 Internet connectivity at observation time); 675 3. by facilitating independent reports of UA location to confirm or 676 refute the operator self-reports upon which UAS RID and UTM 677 tracking are based; 679 4. by enabling instant establishment, by authorized parties, of 680 secure communications with the remote pilot. 682 Any UA can assert any ID using the [F3411-19] required Basic ID 683 message, which lacks any provisions for verification. The Position/ 684 Vector message likewise lacks provisions for verification, and does 685 not contain the ID, so must be correlated somehow with a Basic ID 686 message: the developers of [F3411-19] have suggested using the MAC 687 addresses, but these may be randomized by the operating system stack 688 to avoid the adversarial correlation problems of static identifiers. 690 The [F3411-19] optional Authentication Message specifies framing for 691 authentication data, but does not specify any authentication method, 692 and the maximum length of the specified framing is too short for 693 conventional digital signatures and far too short for conventional 694 certificates. The one-way nature of Broadcast RID precludes 695 challenge-response security protocols (e.g., observers sending nonces 696 to UA, to be returned in signed messages). An observer would be 697 seriously challenged to validate the asserted UAS ID or any other 698 information about the UAS or its operator looked up therefrom. 700 Further, [F3411-19] provides very limited choices for an observer to 701 communicate with the pilot, e.g., to request further information on 702 the UAS operation or exit from an airspace volume in an emergency. 703 The System Message provides the location of the pilot/GCS, so an 704 observer could physically go to the asserted GCS location to look for 705 the remote pilot. An observer with Internet connectivity could look 706 up operator PII in a registry, then call a phone number in hopes 707 someone who can immediately influence the UAS operation will answer 708 promptly during that operation. 710 Thus complementing [F3411-19] with protocols enabling strong 711 authentication, preserving operator privacy while enabling immediate 712 use of information by authorized parties, is critical to achieve 713 widespread adoption of a RID system supporting safe and secure 714 operation of UAS. 716 4. Requirements 717 4.1. General 719 GEN-1 Provable Ownership: DRIP MUST enable verification that the 720 UAS ID asserted in the Basic ID message is that of the actual 721 current sender of the message (i.e. the message is not a 722 replay attack or other spoof, authenticating e.g. by 723 verifying an asymmetric cryptographic signature using a 724 sender provided public key from which the asserted ID can be 725 at least partially derived), even on an observer device 726 lacking Internet connectivity at the time of observation. 728 GEN-2 Provable Binding: DRIP MUST enable binding all other F3411 729 messages from the same actual current sender to the UAS ID 730 asserted in the Basic ID message. 732 GEN-3 Provable Registration: DRIP MUST enable verification that the 733 UAS ID is in a registry and identification of which one, even 734 on an observer device lacking Internet connectivity at the 735 time of observation; with UAS ID Type 3, the same sender may 736 have multiple IDs, potentially in different registries, but 737 each ID must clearly indicate in which registry it can be 738 found. 740 GEN-4 Readability: DRIP MUST enable information (regulation 741 required elements, whether sent via UAS RID or looked up in 742 registries) to be read and utilized by both humans and 743 software. 745 GEN-5 Gateway: DRIP MUST enable Broadcast RID -> Network RID 746 gateways to stamp messages with precise date/time received 747 and receiver location, then relay them to a network service 748 (e.g. SDSP or distributed ledger), to support three 749 objectives: mark up a RID message with where and when it was 750 actually received (which may agree or disagree with the self- 751 report in the set of messages); defend against reply attacks; 752 and support optional SDSP services such as multilateration 753 (to complement UAS position self-reports with independent 754 measurements). 756 GEN-6 Finger (placeholder name): DRIP MUST enable dynamically 757 establishing, with AAA, per policy, E2E strongly encrypted 758 communications with the UAS RID sender and entities looked up 759 from the UAS ID, including at least the remote pilot and USS. 761 GEN-7 QoS: DRIP MUST enable policy based specification of 762 performance and reliability parameters, such as maximum 763 message transmission intervals and delivery latencies. 765 GEN-8 Mobility: DRIP MUST support physical and logical mobility of 766 UA, GCS and Observers. DRIP SHOULD support mobility of 767 essentially all participating nodes (UA, GCS, Observers, Net- 768 RID SP, Net-RID DP, Private Registry, SDSP). 770 GEN-9 Multihoming: DRIP MUST support multihoming of UA and GCS, for 771 make-before-break smooth handoff and resiliency against path/ 772 link failure. DRIP SHOULD support multihoming of essentially 773 all participating nodes. 775 GEN-10 Multicast: DRIP SHOULD support multicast for efficient and 776 flexible publish-subscribe notifications, e.g., of UAS 777 reporting positions in designated sensitive airspace volumes. 779 GEN-11 Management: DRIP SHOULD support monitoring of the health and 780 coverage of Broadcast and Network RID services. 782 4.2. Identifier 784 ID-1 Length: The DRIP [UAS] entity [remote] identifier must be no 785 longer than 20 bytes (per [F3411-19] to fit in a Bluetooth 4 786 advertisement payload). 788 ID-2 Registry ID: The DRIP identifier MUST be sufficient to identify 789 a registry in which the [UAS] entity identified therewith is 790 listed. 792 ID-3 Entity ID: The DRIP identifier MUST be sufficient to enable 793 lookup of other data associated with the [UAS] entity 794 identified therewith in that registry. 796 ID-4 Uniqueness: The DRIP identifier MUST be unique within a to-be- 797 defined scope. 799 ID-5 Non-spoofability: The DRIP identifier MUST be non-spoofable 800 within the context of Remote ID broadcast messages (some 801 collection of messages provides proof of UA ownership of ID). 803 ID-6 Unlinkability: A DRIP UAS ID MUST NOT facilitate adversarial 804 correlation over multiple UAS operations; this may be 805 accomplished e.g. by limiting each identifier to a single use, 806 but if so, the UAS ID MUST support well-defined scalable timely 807 registration methods. 809 Whether a UAS ID is generated by the operator, GCS, UA, USS or 810 registry, or some collaboration thereamong, is unspecified; however, 811 there must be agreement on the UAS ID among these entities. 813 4.3. Privacy 815 PRIV-1 Confidential Handling: DRIP MUST enable confidential handling 816 of private information (i.e., any and all information 817 designated by neither cognizant authority nor the information 818 owner as public, e.g., personal data). 820 PRIV-2 Encrypted Transport: DRIP MUST enable selective strong 821 encryption of private data in motion in such a manner that 822 only authorized actors can recover it. If transport is via 823 IP, then encryption MUST be end-to-end, at or above the IP 824 layer. 826 PRIV-3 Encrypted Storage: DRIP SHOULD enable selective strong 827 encryption of private data at rest in such a manner that only 828 authorized actors can recover it. 830 As satisfying these requirements may require that authorized actors 831 have connectivity to third parties, e.g., Internet to a Remote ID 832 USS, to enable decryption, and such connectivity cannot be assured, 833 DRIP SHOULD provide automatic fallback to plaintext transmission of 834 safety-critical information when necessary. 836 4.4. Registries 838 REG-1 Public Lookup: DRIP MUST enable lookup, from the UAS ID, of 839 information designated by cognizant authority as public. 841 REG-2 Private Lookup: DRIP MUST enable lookup, with AAA, per policy, 842 of private information (i.e., any and all information in a 843 registry, associated with the UAS ID, that is designated by 844 neither cognizant authority nor the information owner as 845 public). 847 REG-3 Provisioning: DRIP MUST enable provisioning registries with 848 static information on the UAS and its operator, dynamic 849 information on its current operation within the UTM (including 850 means by which the USS under which the UAS is operating may be 851 contacted for further, typically even more dynamic, 852 information), and Internet direct contact information for 853 services related to the foregoing. 855 REG-4 AAA Policy: DRIP MUST enable closing the AAA-policy registry 856 loop by governing AAA per registered policies and 857 administering policies only via AAA. 859 5. Discussion and Limitations 861 This document is largely based on the process of one SDO, ASTM. 862 Therefore, it is tailored to specific needs and data formats of this 863 standard. Other organizations, for example in EU, do not necessary 864 follow the same architecture. IETF traditionally operates assuming 865 the source material for the standardization process is publicly 866 available. However, ASTM standards require a fee for download. 867 Therefore a double-liaison program at IETF might need to be 868 activated, providing free access to ASTM specifications for 869 contributors to IETF documents. 871 The need for drone ID and operator privacy is an open discussion 872 topic. For instance, in the ground vehicular domain each car carries 873 a publicly visible plate number. In some countries, for nominal cost 874 or even for free, anyone can resolve the identity and contact 875 information of the owner. Civil commercial aviation and maritime 876 industries also have a tradition of broadcasting plane or ship ID, 877 coordinates and even flight plans in plain text. Community networks 878 such as OpenSky and Flightradar use this open information through 879 ADS-B to deploy public services of flight tracking. Many researchers 880 also use these data to perform optimization of routes and airport 881 operations. Such ID information should be integrity protected, but 882 not necessarily confidential. 884 In civil aviation, aircraft identity is broadcast by a device known 885 as transponder. It transmits a four-digit squawk code, which is 886 assigned by a traffic controller to an airplane after approving a 887 flight plan. There are several reserved codes such as 7600 which 888 indicate radio communication failure. The codes are unique in each 889 traffic area and can be re-assigned when entering another control 890 area. The code is transmitted in plain text by the transponder and 891 also used for collision avoidance by a system known as Traffic alert 892 and Collision Avoidance System (TCAS). The system could be used for 893 UAS as well initially, but the code space is quite limited and likely 894 to be exhausted soon. The number of UAS far exceeds the number of 895 civil airplanes in operation. 897 The ADS-B system is utilized in civil aviation for each "ADS-B Out" 898 equipped airplane to broadcast its ID, coordinates and altitude for 899 other airplanes and ground control stations. If this system is 900 adopted for drone IDs, it has additional benefit with backward 901 compatibility with civil aviation infrastructure; then, pilots and 902 dispatchers will be able to see UA on their control screens and take 903 those into account. If not, a gateway translation system between the 904 proposed drone ID and civil aviation system should be implemented. 905 Again, system saturation due to large numbers of UAS is a concern. 907 Wi-Fi and Bluetooth are two wireless technologies currently 908 recommended by ASTM specifications due to their widespread use and 909 broadcast nature. However, those have limited range (max 100s of 910 meters) and may not reliably deliver UAS ID at high altitude or 911 distance. Therefore, a study should be made of alternative 912 technologies from the telecom domain (WiMax, 5G) or sensor networks 913 (Sigfox, LORA). Such transmission technologies can impose additional 914 restrictions on packet sizes and frequency of transmissions, but 915 could provide better energy efficiency and range. In civil aviation, 916 Controller-Pilot Data Link Communications (CPDLC) is used to transmit 917 command and control between the pilots and ATC. It could be 918 considered for UAS as well due to long range and proven use despite 919 its lack of security [cpdlc]. 921 L-band Digital Aeronautical Communications System (LDACS) is being 922 standardized by ICAO and IETF for use in future civil aviation 923 [I-D.maeurer-raw-ldacs]. It provides secure communication, 924 positioning and control for aircraft using a dedicated radio band. 925 It should be analyzed as a potential provider for UAS RID as well. 926 This will bring the benefit of a global integrated system creating a 927 global airspace use awareness. 929 6. IANA Considerations 931 This document does not make any IANA request. 933 7. Security Considerations 935 DRIP is all about safety and security, so content pertaining to such 936 is not limited to this section. DRIP information falls into two 937 classes: that which, to achieve the purpose, must be published openly 938 in clear plaintext, for the benefit of any observer; and that which 939 must be protected (e.g., PII of pilots) but made available to 940 properly authorized parties (e.g., public safety personnel who 941 urgently need to contact pilots in emergencies). This classification 942 must be made explicit and reflected with markings, design, etc. 943 Classifying the information will be addressed primarily in external 944 standards; herein it will be regarded as a matter for CAA, registry 945 and operator policies, for which enforcement mechanisms will be 946 defined within the scope of DRIP WG and offered. Details of the 947 protection mechanisms will be provided in other DRIP documents. 948 Mitigation of adversarial correlation will also be addressed. 950 Acknowledgments 952 The work of the FAA's UAS Identification and Tracking (UAS ID) 953 Aviation Rulemaking Committee (ARC) is the foundation of later ASTM 954 [F3411-19] and IETF DRIP WG efforts. The work of ASTM F38.02 in 955 balancing the interests of diverse stakeholders is essential to the 956 necessary rapid and widespread deployment of UAS RID. 958 References 960 Normative References 962 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 963 Requirement Levels", BCP 14, RFC 2119, 964 DOI 10.17487/RFC2119, March 1997, 965 . 967 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 968 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 969 May 2017, . 971 Informative References 973 [CONOPS] FAA Office of NextGen, "UTM Concept of Operations v2.0", 974 March 2020. 976 [cpdlc] Gurtov, A., Polishchuk, T., and M. Wernberg, "Controller- 977 Pilot Data Link Communication Security", MDPI 978 Sensors 18(5), 1636, 2018, 979 . 981 [CTA2063A] ANSI, "Small Unmanned Aerial Systems Serial Numbers", 982 September 2019. 984 [Delegated] 985 European Union Aviation Safety Agency (EASA), "Commission 986 Delegated Regulation (EU) 2019/945 of 12 March 2019 on 987 unmanned aircraft systems and on third-country operators 988 of unmanned aircraft systems", March 2019. 990 [F3411-19] ASTM, "Standard Specification for Remote ID and Tracking", 991 December 2019. 993 [I-D.ietf-drip-arch] 994 Card, S., Wiethuechter, A., Moskowitz, R., and S. Zhao, 995 "Drone Remote Identification Protocol (DRIP) 996 Architecture", Work in Progress, Internet-Draft, draft- 997 ietf-drip-arch-00, 18 May 2020, 998 . 1000 [I-D.maeurer-raw-ldacs] 1001 Maeurer, N., Graeupl, T., and C. Schmitt, "L-band Digital 1002 Aeronautical Communications System (LDACS)", Work in 1003 Progress, Internet-Draft, draft-maeurer-raw-ldacs-02, 1 1004 April 2020, 1005 . 1007 [Implementing] 1008 European Union Aviation Safety Agency (EASA), "Commission 1009 Implementing Regulation (EU) 2019/947 of 24 May 2019 on 1010 the rules and procedures for the operation of unmanned 1011 aircraft", May 2019. 1013 [NPRM] United States Federal Aviation Administration (FAA), 1014 "Notice of Proposed Rule Making on Remote Identification 1015 of Unmanned Aircraft Systems", December 2019. 1017 [Recommendations] 1018 FAA UAS Identification and Tracking Aviation Rulemaking 1019 Committee, "UAS ID and Tracking ARC Recommendations Final 1020 Report", September 2017. 1022 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1023 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1024 DOI 10.17487/RFC4122, July 2005, 1025 . 1027 [Roadmap] American National Standards Institute (ANSI) Unmanned 1028 Aircraft Systems Standardization Collaborative (UASSC), 1029 "Standardization Roadmap for Unmanned Aircraft Systems 1030 draft v2.0", April 2020. 1032 [Stranger] Heinlein, R.A., "Stranger in a Strange Land", June 1961. 1034 Acknowledgments 1036 The work of the FAA's UAS Identification and Tracking (UAS ID) 1037 Aviation Rulemaking Committee (ARC) is the foundation of later ASTM 1038 [F3411-19] and IETF DRIP efforts. The work of ASTM F38.02 in 1039 balancing the interests of diverse stakeholders is essential to the 1040 necessary rapid and widespread deployment of UAS RID. IETF 1041 volunteers who have contributed to this draft include Amelia 1042 Andersdotter, Mohamed Boucadair, Toerless Eckert, Susan Hares, Mika 1043 Järvenpää, Daniel Migault, Saulo Da Silva and Shuai 1044 Zhao. 1046 Authors' Addresses 1048 Stuart W. Card (editor) 1049 AX Enterprize 1050 4947 Commercial Drive 1051 Yorkville, NY 13495 1052 United States of America 1054 Email: stu.card@axenterprize.com 1056 Adam Wiethuechter 1057 AX Enterprize 1058 4947 Commercial Drive 1059 Yorkville, NY 13495 1060 United States of America 1062 Email: adam.wiethuechter@axenterprize.com 1064 Robert Moskowitz 1065 HTT Consulting 1066 Oak Park, MI 48237 1067 United States of America 1069 Email: rgm@labs.htt-consult.com 1071 Andrei Gurtov 1072 Linköping University 1073 IDA 1074 SE-58183 Linköping 1075 Sweden 1077 Email: gurtov@acm.org