idnits 2.17.1 draft-ietf-drip-reqs-00.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 (18 May 2020) is 1429 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'UAS' is mentioned on line 706, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 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: 19 November 2020 R. Moskowitz 6 HTT Consulting 7 18 May 2020 9 Drone Remote Identification Protocol (DRIP) Requirements 10 draft-ietf-drip-reqs-00 12 Abstract 14 This document defines the requirements for Drone Remote 15 Identification Protocol (DRIP) Working Group protocols and services 16 to support Unmanned Aircraft System Remote Identification (UAS RID). 18 Objectives include: complementing external technical standards as 19 regulator-accepted means of compliance with UAS RID regulations; 20 facilitating use of existing Internet resources to support UAS RID 21 and to enable enhanced related services; and enabling verification 22 that UAS RID information is trustworthy (to some extent, even in the 23 absence of Internet connectivity at the receiving node). 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 19 November 2020. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 5 60 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 5 61 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. UAS RID Problem Space . . . . . . . . . . . . . . . . . . . . 10 63 3.1. Network RID . . . . . . . . . . . . . . . . . . . . . . . 11 64 3.2. Broadcast RID . . . . . . . . . . . . . . . . . . . . . . 12 65 3.3. DRIP Focus . . . . . . . . . . . . . . . . . . . . . . . 12 66 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 13 67 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 4.2. Identifier . . . . . . . . . . . . . . . . . . . . . . . 15 69 4.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 16 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 72 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 75 8.2. Informative References . . . . . . . . . . . . . . . . . 17 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 78 1. Introduction 80 Many safety and other considerations dictate that UAS be remotely 81 identifiable. Civil Aviation Authorities (CAAs) worldwide are 82 mandating UAS RID. The European Union Aviation Safety Agency (EASA) 83 has published [Delegated] and [Implementing] Regulations. The United 84 States (US) Federal Aviation Administration (FAA) has published a 85 Notice of Proposed Rule Making ([NPRM]). CAAs currently promulgate 86 performance-based regulations that do not specify techniques, but 87 rather cite industry consensus technical standards as acceptable 88 means of compliance. 90 ASTM International, Technical Committee F38 (UAS), Subcommittee 91 F38.02 (Aircraft Operations), Work Item WK65041, developed ASTM 92 F3411-19 [F3411-19] Standard Specification for Remote ID and 93 Tracking. It defines 2 means of UAS RID. Network RID defines a set 94 of information for UAS to make available globally indirectly via the 95 Internet. Broadcast RID defines a set of messages for Unmanned 96 Aircraft (UA) to transmit locally directly one-way over Bluetooth or 97 Wi-Fi. Network RID depends upon Internet connectivity, in several 98 segments, from the UAS to the observer. Broadcast RID should need 99 Internet (or other Wide Area Network) connectivity only for UAS 100 registry information lookup using the directly locally received UAS 101 ID as a key. It is expected that the same information will be 102 provided via Broadcast and Network RID; in the US, the FAA NPRM so 103 specifies. 105 [F3411-19] specifies 3 UAS ID types. Type 1 is a static, 106 manufacturer assigned, hardware serial number per ANSI/CTA-2063-A 107 "Small Unmanned Aerial System Serial Numbers" [CTA2063A]. Type 2 is 108 a CAA assigned (presumably static) ID. Type 3 is a UAS Traffic 109 Management (UTM) system assigned UUID [RFC4122], which can but need 110 not be dynamic. The EU allows only Type 1; the US allows Types 1 and 111 3, but requires Type 3 IDs (if used) each to be used only once (for a 112 single UAS flight, which in the context of UTM is called an 113 "operation"). [F3411-19] Broadcast RID transmits all information in 114 the clear as plaintext (ASCII or binary), so static IDs enable 115 trivial correlation of patterns of use, unacceptable in many 116 applications, e.g. package delivery routes of competitors. 118 An ID is not an end in itself; it exists to enable lookups and 119 provision of services complementing mere identification. 121 Minimal specified information must be made available to the public; 122 access to other data, e.g. UAS operator Personally Identifiable 123 Information (PII), must be limited to strongly authenticated 124 personnel, properly authorized per policy. The balance between 125 privacy and transparency remains a subject for public debate and 126 regulatory action; DRIP can only offer tools to expand the achievable 127 trade space and enable trade-offs within that space. [F3411-19] 128 specifies only how to get the UAS ID to the observer; how the 129 observer can perform these lookups, and how the registries first can 130 be populated with information, is unspecified. 132 Using UAS RID to facilitate vehicular (V2X) communications and 133 applications such as Detect And Avoid (DAA, which would impose 134 tighter latency bounds than RID itself) is an obvious possibility, 135 explicitly contemplated in the FAA NPRM. However, applications of 136 RID beyond RID itself have been omitted from [F3411-19]; DAA has been 137 explicitly declared out of scope in ASTM working group discussions, 138 based on a distinction between RID as a security standard vs DAA as a 139 safety application. Although dynamic establishment of secure 140 communications between the observer and the UAS pilot seems to have 141 been contemplated by the FAA UAS ID and Tracking Aviation Rulemaking 142 Committee (ARC) in their [Recommendations], it is not addressed in 143 any of the subsequent proposed regulations or technical 144 specifications. 146 The need for near-universal deployment of UAS RID is pressing. This 147 implies the need to support use by observers of already ubiquitous 148 mobile devices (smartphones and tablets). Anticipating likely CAA 149 requirements to support legacy devices, especially in light of 150 [Recommendations], [F3411-19] specifies that any UAS sending 151 Broadcast RID over Bluetooth must do so over Bluetooth 4, regardless 152 of whether it also does so over newer versions; as UAS sender devices 153 and observer receiver devices are unpaired, this implies extremely 154 short "advertisement" (beacon) frames. 156 UA onboard RID devices are severely constrained in Size, Weight and 157 Power (SWaP). Cost is a significant impediment to the necessary 158 near-universal adoption of UAS send and observer receive RID 159 capabilities. To accommodate the most severely constrained cases, 160 all these conspire to motivate system design decisions, especially 161 for the Broadcast RID data link, which complicate the protocol design 162 problem: one-way links; extremely short packets; and Internet- 163 disconnected operation of UA onboard devices. Internet-disconnected 164 operation of observer devices has been deemed by ASTM F38.02 too 165 infrequent to address, but for some users is important and presents 166 further challenges. 168 Given not only packet payload length and bandwidth, but also 169 processing and storage within the SWaP constraints of very small 170 (e.g. consumer toy) UA, heavyweight cryptographic security protocols 171 are infeasible, yet trustworthiness of UAS RID information is 172 essential. Under [F3411-19], even the most basic datum, the UAS ID 173 string (typically number) itself can be merely an unsubstantiated 174 claim. Observer devices being ubiquitous, thus popular targets for 175 malware or other compromise, cannot be generally trusted (although 176 the user of each device is compelled to trust that device, to some 177 extent); a "fair witness" functionality (inspired by [Stranger]) may 178 be desirable. 180 DRIP's goal is to make RID immediately actionable, in both Internet 181 and local-only connected scenarios (especially emergencies), in 182 severely constrained UAS environments, balancing legitimate (e.g. 183 public safety) authorities' Need To Know trustworthy information with 184 UAS operators' privacy. DRIP (originally called Trustworthy 185 Multipurpose Remote Identification, TM-RID) potentially could be 186 applied to verifiably identify other types of registered things 187 reported to be in specified physical locations, but the urgent 188 motivation and clear initial focus is UAS. Existing Internet 189 resources (protocol standards, services, infrastructure, and business 190 models) should be leveraged. A natural Internet architecture for UAS 191 RID conforming to proposed regulations and external technical 192 standards will be described in a companion DRIP Architecture 193 document; this document describes only requirements. 195 2. Terms and Definitions 197 2.1. Requirements Terminology 199 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 200 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 201 "OPTIONAL" in this document are to be interpreted as described in BCP 202 14 [RFC2119] [RFC8174] when, and only when, they appear in all 203 capitals, as shown here. 205 2.2. Definitions 207 $SWaP 208 Cost, Size, Weight and Power. 210 AAA 211 Attestation, Authentication, Authorization, Access Control, 212 Accounting, Attribution, Audit. 214 ABDAA 215 AirBorne DAA. Also known as "self-separation". 217 AGL 218 Above Ground Level. Relative altitude, above the variously 219 defined local ground level, typically of an UA, typically measured 220 in feet. 222 ATC 223 Air Traffic Control. Explicit flight direction to pilots from 224 ground controllers. Contrast with ATM. 226 ATM 227 Air Traffic Management. All systems that assist aircraft from 228 departure to landing. A broader functional and geographic scope 229 and/or a higher layer of abstraction than ATC. 231 Authentication Message 232 F3411 Message Type 2. Provides framing for authentication data, 233 only. 235 Basic ID Message 236 F3411 Message Type 0. Provides UA Type, UAS ID Type and UAS ID, 237 only. 239 CAA 240 Civil Aviation Authority. An example is the Federal Aviation 241 Administration (FAA) in the United States of America. 243 C2 244 Command and Control. A set of organizational and technical 245 attributes and processes that employs human, physical, and 246 information resources to solve problems and accomplish missions. 247 Mainly used in military contexts. In the UAS context, typically 248 refers to the link between GCS and UA over which the former 249 controls the latter. Out of scope for DRIP, even when this link 250 is used to provide UA location to the GCS or vice-versa, for 251 subsequent RID transmission. 253 DAA 254 Detect And Avoid, formerly Sense And Avoid (SAA). A means of 255 keeping aircraft "well clear" of each other for safety. 257 Direct RID 258 Direct Remote Identification. Per [Delegated], "a system that 259 ensures the local broadcast of information about a UA in 260 operation, including the marking of the UA, so that this 261 information can be obtained without physical access to the UA". 262 Requirement could be met with ASTM Broadcast RID: Basic ID message 263 with UAS ID Type 1; Location/Vector message; Operator ID message; 264 System Message. Corresponds roughly to the Broadcast RID portion 265 of FAA NPRM Standard RID. 267 E2E 268 End to End. 270 GBDAA 271 Ground Based DAA. 273 GCS 274 Ground Control Station. The part of the UAS that the remote pilot 275 uses to exercise C2 over the UA, whether by remotely exercising UA 276 flight controls to fly the UA, by setting GPS waypoints, or 277 otherwise directing its flight. 279 GPS 280 Global Positioning System. In this context, misused in place of 281 Global Navigation Satellite System (GNSS) or more generally SATNAV 282 to refer generically to satellite based timing and/or positioning. 284 GRAIN 285 Global Resilient Aviation Information Network. An effort to 286 develop an international IPv6 overlay network with end-to-end 287 security supporting all aspects of aviation. 289 IATF 290 International Aviation Trust Framework. ICAO effort to develop a 291 resilient and secure by design framework for networking in support 292 of all aspects of aviation. 294 ICAO 295 International Civil Aviation Organization. A United Nations 296 specialized agency that develops and harmonizes international 297 standards relating to aviation. 299 LAANC 300 Low Altitude Authorization and Notification Capability. Supports 301 ATC authorization requirements for UAS operations: remote pilots 302 can apply to receive a near real-time authorization for operations 303 under 400 feet in controlled airspace near airports. US partial 304 stopgap until UTM comes. 306 Limited RID 307 Per the FAA NPRM, a mode of operation that must use Network RID, 308 must not use Broadcast RID, and must provide pilot/GCS location 309 only (not UA location). This mode is only allowed for UA that 310 neither require (due to e.g. size) nor are equipped for Standard 311 RID, operated within V-LOS and within 400 feet of the pilot, below 312 400 feet AGL, etc. 314 Location/Vector Message 315 F3411 Message Type 1. Provides UA location, altitude, heading and 316 speed, only. 318 LOS 319 Line Of Sight. An adjectival phrase describing any information 320 transfer that travels in a nearly straight line (e.g. 321 electromagnetic energy, whether in the visual light, RF or other 322 frequency range) and is subject to blockage. A term to be avoided 323 due to ambiguity, in this context, between RF-LOS and V-LOS. 325 MSL 326 Mean Sea Level. Relative altitude, above the variously defined 327 mean sea level, typically of an UA (but in FAA NPRM for a GCS), 328 typically measured in feet. 330 Net-RID DP 331 Network RID Display Provider. Logical entity that aggregates data 332 from Net-RID SPs as needed in response to user queries regarding 333 UAS operating within specified airspace volumes, to enable display 334 by a user application on a user device. Under the FAA NPRM, not 335 recognized as a distinct entity, but a service provided by USS, 336 including Public Safety USS that may exist primarily for this 337 purpose rather than to manage any subscribed UAS. 339 Net-RID SP 340 Network RID Service Provider. Logical entity that participates in 341 Network RID and provides to NetRID-DPs information on UAS it 342 manages. Under the FAA NPRM, the USS to which the UAS is 343 subscribed ("Remote ID USS"). 345 Network Identification Service 346 EU regulatory requirement for Network RID. Requirement could be 347 met with ASTM Network RID: Basic ID message with UAS ID Type 1; 348 Location/Vector message; Operator ID message; System Message. 349 Corresponds roughly to the Network RID portion of FAA NPRM 350 Standard RID. 352 Observer 353 Referred to in other UAS RID documents as a "user", but there are 354 also other classes of UAS RID users, so we prefer "observer" to 355 denote an individual who has observed an UA and wishes to know 356 something about it, starting with its ID. 358 Operator ID Message 359 F3411 Message Type 5. Provides CAA issued Operator ID, only. 361 PII 362 Personally Identifiable Information. In this context, typically 363 of the UAS operator, Pilot In Command (PIC) or remote pilot, but 364 possibly of an observer or other party. 366 RF 367 Radio Frequency. May be used as an adjective or as a noun; in the 368 latter case, typically means Radio Frequency energy. 370 RF-LOS 371 RF LOS. Typically used in describing operation of a direct radio 372 link between a GCS and the UA under its control, potentially 373 subject to blockage by foliage, structures, terrain or other 374 vehicles, but less so than V-LOS. 376 Self-ID Message 377 F3411 Message Type 3. Provides a 1 byte descriptor and 23 byte 378 ASCII free text field, only. 380 Standard RID 381 Per the FAA NPRM, a mode of operation that must use both Network 382 RID (if Internet connectivity is available at the time in the 383 operating area) and Broadcast RID (always and everywhere), and 384 must provide both pilot/GCS location and UA location. This mode 385 is required for UAS that exceed the allowed envelope (e.g. size, 386 range) of Limited RID and for all UAS equipped for Standard RID 387 (even if operated within parameters that would otherwise permit 388 Limited RID). The Broadcast RID portion corresponds roughly to EU 389 Direct RID; the Network RID portion corresponds roughly to EU 390 Network Identification Service. 392 SDSP 393 Supplemental Data Service Provider. An entity that participates 394 in the UTM system, but provides services beyond those specified as 395 basic UTM system functions. 397 System Message 398 F3411 Message Type 4. Provides general UAS information, including 399 remote pilot location, multiple UA group operational area, etc. 401 U-space 402 EU concept and emerging framework for integration of UAS into all 403 classes of airspace, specifically including high density urban 404 areas, sharing airspace with manned aircraft. 406 UA 407 Unmanned Aircraft. An aircraft which is intended to operate with 408 no pilot on board. In popular parlance, "drone". 410 UAS 411 Unmanned Aircraft System. Composed of UA, all required on-board 412 subsystems, payload, control station, other required off-board 413 subsystems, any required launch and recovery equipment, all 414 required crew members, and C2 links between UA and control 415 station. 417 UAS ID 418 UAS identifier. Although called "UAS ID", unique to the UA: 419 neither to the operator (as previous registration numbers have 420 been assigned), nor to the combination of GCS and UA that comprise 421 the UAS. Per [F3411-19], maximum length of 20 bytes. 423 UAS ID Type 424 Identifier type index. Per [F3411-19], 4 bits, values 0-3 already 425 specified. 427 UAS RID 428 UAS Remote Identification. System for identifying UA during 429 flight by other parties. 431 UAS RID Verification Service 432 System component designed to handle the authentication 433 requirements of RID by offloading verification to a web hosted 434 service. 436 USS 437 UAS Service Supplier. Provide UTM services to support the UAS 438 community, to connect Operators and other entities to enable 439 information flow across the USS network, and to promote shared 440 situational awareness among UTM participants. (From FAA UTM 441 ConOps V1, May 2018). 443 UTM 444 UAS Traffic Management. Per ICAO, "A specific aspect of air 445 traffic management which manages UAS operations safely, 446 economically and efficiently through the provision of facilities 447 and a seamless set of services in collaboration with all parties 448 and involving airborne and ground-based functions." In the US, 449 per FAA, a "traffic management" ecosystem for "uncontrolled" low 450 altitude UAS operations, separate from, but complementary to, the 451 FAA's ATC system for "controlled" operations of manned aircraft. 453 V-LOS 454 Visual LOS. Typically used in describing operation of an UA by a 455 "remote" pilot who can clearly directly (without video cameras or 456 any other aids other than glasses or under some rules binoculars) 457 see the UA and its immediate flight environment. Potentially 458 subject to blockage by foliage, structures, terrain or other 459 vehicles, more so than RF-LOS. 461 3. UAS RID Problem Space 463 UA may be fixed wing Short Take-Off and Landing (STOL), rotary wing 464 (e.g. helicopter) Vertical Take-Off and Landing (VTOL), or hybrid. 465 They may be single engine or multi engine. The most common today are 466 multicopters: rotary wing, multi engine. The explosion in UAS was 467 enabled by hobbyist development, for multicopters, of advanced flight 468 stability algorithms, enabling even inexperienced pilots to take off, 469 fly to a location of interest, hover, and return to the take-off 470 location or land at a distance. UAS can be remotely piloted by a 471 human (e.g. with a joystick) or programmed to proceed from Global 472 Positioning System (GPS) waypoint to waypoint in a weak form of 473 autonomy; stronger autonomy is coming. UA are "low observable": they 474 typically have a small radar cross section; they make noise quite 475 noticeable at short range but difficult to detect at distances they 476 can quickly close (500 meters in under 17 seconds at 60 knots); they 477 typically fly at low altitudes (for the small UAS to which RID 478 applies in the US, under 400 feet AGL); they are highly maneuverable 479 so can fly under trees and between buildings. 481 UA can carry payloads including sensors, cyber and kinetic weapons, 482 or can be used themselves as weapons by flying them into targets. 483 They can be flown by clueless, careless or criminal operators. Thus 484 the most basic function of UAS RID is "Identification Friend or Foe" 485 (IFF) to mitigate the significant threat they present. Numerous 486 other applications can be enabled or facilitated by RID: consider the 487 importance of identifiers in many Internet protocols and services. 489 Network RID from the UA itself (rather than from its GCS) and 490 Broadcast RID require one or more wireless data links from the UA, 491 but such communications are challenging due to $SWaP constraints and 492 low altitude flight amidst structures and foliage over terrain. 493 Disambiguation of multiple UA flying in close proximity may be very 494 challenging, even if each is reporting its identity, position and 495 velocity as accurately as it can. 497 3.1. Network RID 499 Network RID has several variants. The UA may have persistent onboard 500 Internet connectivity, in which case it can consistently source RID 501 information directly over the Internet. The UA may have intermittent 502 onboard Internet connectivity, in which case the GCS must source RID 503 information whenever the UA itself is offline. The UA may not have 504 Internet connectivity of its own, but have instead some other form of 505 communications to another node that can relay RID information to the 506 Internet; this would typically be the GCS (which to perform its 507 function must know where the UA is). The UA may have no means of 508 sourcing RID information, in which case the GCS must source it; this 509 is typical under FAA NPRM Limited RID proposed rules, which require 510 providing the location of the GCS (not that of the UA). In the 511 extreme case, this could be the pilot using a web browser to 512 designate, to an UAS Service Supplier (USS) or other UTM entity, a 513 time-bounded airspace volume in which an operation will be conducted; 514 this may impede disambiguation of ID if multiple UAS operate in the 515 same or overlapping spatio-temporal volumes. 517 In most cases in the near term, if the RID information is fed to the 518 Internet directly by the UA or GCS, the first hop data links will be 519 cellular Long Term Evolution (LTE) or WiFi, but provided the data 520 link can support at least IP and ideally TCP, its type is generally 521 immaterial to the higher layer protocols. An UAS or other ultimate 522 source of Network RID information feeds an USS acting as a Network 523 RID Service Provider (Net-RID SP), which essentially proxies for that 524 and other sources; an observer or other ultimate consumer of Network 525 RID information obtains it from a Network RID Display Provider (Net- 526 RID DP), which aggregates information from multiple Net-RID SPs to 527 offer coverage of an airspace volume of interest. Network RID 528 Service and Display providers are expected to be implemented as 529 servers in well-connected infrastructure, accessible via typical 530 means such as web APIs/browsers. 532 Network RID is the more flexible and less constrained of the defined 533 UAS RID means, but is only partially specified in [F3411-19]. It is 534 presumed that IETF efforts supporting Broadcast RID (see next 535 section) can be easily generalized for Network RID. 537 3.2. Broadcast RID 539 [F3411-19] specifies 3 Broadcast RID data links: Bluetooth 4.X; 540 Bluetooth 5.X Long Range; and WiFi with Neighbor Awareness Networking 541 (NAN). For compliance with this standard, an UA must broadcast 542 (using advertisement mechanisms where no other option supports 543 broadcast) on at least one of these; if broadcasting on Bluetooth 544 5.x, it is also required concurrently to do so on 4.x (referred to in 545 [F3411-19] as Bluetooth Legacy). 547 The selection of the Broadcast media was driven by research into what 548 is commonly available on 'ground' units (smartphones and tablets) and 549 what was found as prevalent or 'affordable' in UA. Further, there 550 must be an Application Programming Interface (API) for the observer's 551 receiving application to have access to these messages. As yet only 552 Bluetooth 4.X support is readily available, thus the current focus is 553 on working within the 26 byte limit of the Bluetooth 4.X "Broadcast 554 Frame" transmitted on beacon channels. After nominal overheads, this 555 limits the UAS ID string to a maximum length of 20 bytes, and 556 precludes the same frame carrying position, velocity and other 557 information that should be bound to the UAS ID, much less strong 558 authentication data. This requires segmentation ("paging") of longer 559 messages or message bundles ("Message Pack"), and/or correlation of 560 short messages (anticipated by ASTM to be done on the basis of 561 Bluetooth 4 MAC address, which is weak and unverifiable). 563 3.3. DRIP Focus 565 DRIP WG will focus on making information obtained via UAS RID 566 immediately usable (for the observer to determine whether the UAS is 567 trusted to fly in the airspace volume where and when observed, to 568 establish communications whereby the observer can inquire of the 569 pilot as to intent and/or direct the pilot to exit from the volume, 570 etc.): 572 1. first by making it trustworthy (despite the severe constraints of 573 Broadcast RID); 575 2. second by enabling verification that an UAS is registered, and if 576 so, in which registry (for classification of trusted operators on 577 the basis of known registry vetting, even by observers lacking 578 Internet connectivity at observation time); 580 3. third by enabling instant establishment, by authorized parties, 581 of secure communications with the remote pilot. 583 Any UA can assert any ID using the [F3411-19] required Basic ID 584 message, which lacks any provisions for verification. The Position/ 585 Vector message likewise lacks provisions for verification, and does 586 not contain the ID, so must be correlated somehow with a Basic ID 587 message: the developers of [F3411-19] have suggested using the MAC 588 addresses, but these may be randomized by the operating system stack 589 to avoid the adversarial correlation problems of static identifiers. 590 The [F3411-19] optional Authentication Message specifies framing for 591 authentication data, but does not specify any authentication method, 592 and the maximum length of the specified framing is too short for 593 conventional digital signatures and far too short for conventional 594 certificates. The one-way nature of Broadcast RID precludes 595 challenge-response security protocols (e.g. observers sending nonces 596 to UA, to be returned in signed messages). An observer would be 597 seriously challenged to validate the asserted UAS ID or any other 598 information about the UAS or its operator looked up therefrom. 600 Further, [F3411-19] provides very limited choices for an observer to 601 communicate with the pilot, e.g. to request further information on 602 the UAS operation or exit from an airspace volume in an emergency. 603 The System Message provides the location of the pilot/GCS, so an 604 observer could physically go to the asserted GCS location to look for 605 the remote pilot. An observer with Internet connectivity could look 606 up operator PII in a registry, then call a phone number in hopes 607 someone who can immediately influence the UAS operation will answer 608 promptly during that operation. 610 Thus complementing [F3411-19] with protocols enabling strong 611 authentication, preserving operator privacy while enabling immediate 612 use of information by authorized parties, is critical to achieve 613 widespread adoption of a RID system supporting safe and secure 614 operation of UAS. 616 4. Requirements 618 4.1. General 620 GEN-1 Provable Ownership: DRIP MUST enable verification that the 621 UAS ID asserted in the Basic ID message is that of the actual 622 current sender of the message (i.e. the message is not a 623 replay attack or other spoof, authenticating e.g. by 624 verifying an asymmetric cryptographic signature using a 625 sender provided public key from which the asserted ID can be 626 at least partially derived). 628 GEN-2 Provable Binding: DRIP MUST enable binding all other F3411 629 messages from the same actual current sender to the UAS ID 630 asserted in the Basic ID message. 632 GEN-3 Provable Registration: DRIP MUST enable verification that the 633 UAS ID is in a registry and identification of which one (with 634 UAS ID Type 3, the same sender may have multiple IDs, 635 potentially in different registries, but each ID should 636 clearly indicate in which registry it can be found). 638 GEN-4 Public Lookup: DRIP MUST enable lookup, from the UAS ID, of 639 information designated by cognizant authority as public. 641 GEN-5 Private Lookup: DRIP MUST enable lookup, with AAA, per 642 policy, of private information (i.e. any and all information 643 in a registry, associated with the UAS ID, that is designated 644 by neither cognizant authority nor the information owner as 645 public). 647 GEN-6 Readability: DRIP MUST enable information to be read and 648 utilized by both humans and software. 650 GEN-7 Provisioning: DRIP MUST enable provisioning registries with 651 static information on the UAS and its operator, dynamic 652 information on its current operation within the UTM 653 (including means by which the USS under which the UAS is 654 operating may be contacted for further, typically even more 655 dynamic, information), and Internet direct contact 656 information for services related to the foregoing. 658 GEN-8 AAA Policy: DRIP MUST enable closing the AAA-policy registry 659 loop by governing AAA per registered policies and 660 administering policies only via AAA. 662 GEN-9 Finger (placeholder name): DRIP MUST enable dynamically 663 establishing, with AAA, per policy, E2E strongly encrypted 664 communications with the UAS RID sender and entities looked up 665 from the UAS ID, including at least the remote pilot and USS. 667 GEN-10 QoS: DRIP MUST enable policy based specification of 668 performance and reliability parameters, such as maximum 669 message transmission intervals and delivery latencies. 671 GEN-11 Mobility: DRIP MUST support physical and logical mobility of 672 UA, GCS and Observers. DRIP SHOULD support mobility of all 673 participating nodes. 675 GEN-12 Multihoming: DRIP MUST support multihoming of UA, for make- 676 before-break smooth handoff and resiliency against path/link 677 failure. DRIP SHOULD support multihoming of all 678 participating nodes. 680 GEN-13 Multicast: DRIP SHOULD support multicast for efficient and 681 flexible publish-subscribe notifications, e.g. of UAS 682 reporting positions in designated sensitive airspace volumes. 684 GEN-14 Management: DRIP SHOULD support monitoring of the health and 685 coverage of Broadcast and Network RID services. 687 It is highly desirable that Broadcast RID receivers be able to stamp 688 messages with accurate date/time received and receiver location, then 689 relay them to a network service (e.g. SDSP or distributed ledger). 690 This supports 3 objectives: mark up a RID message with where and when 691 it was actually received (which may agree or disagree with the self- 692 report in the set of messages); defend against reply attacks; and 693 support optional SDSP services such as multilateration (to complement 694 UAS position self-reports with independent measurements). 696 4.2. Identifier 698 ID-1 Length: The DRIP [UAS] entity [remote] identifier must be no 699 longer than 20 bytes. 701 ID-2 Registry ID: The DRIP identifier MUST be sufficient to identify 702 a registry in which the [UAS] entity identified therewith is 703 listed. 705 ID-3 Entity ID: The DRIP identifier MUST be sufficient to enable 706 lookup of other data associated with the [UAS] entity 707 identified therewith in that registry. 709 ID-4 Uniqueness: The DRIP identifier MUST be unique within a to-be- 710 defined scope. 712 ID-5 Non-spoofability: The DRIP identifier MUST be non-spoofable 713 within the context of Remote ID broadcast messages (some 714 collection of messages provides proof of UA ownership of ID). 716 A DRIP UAS ID MUST NOT facilitate adversarial correlation of UAS 717 operational patterns; this may be accomplished e.g. by limiting each 718 identifier to a single use, but if so, the UAS ID MUST support 719 defined scalable timely registration methods. 721 Mechanisms standardized in DRIP WG MUST be capable of proving 722 ownership of a claimed UAS ID, and SHOULD be capable of doing so 723 immediately on an observer device lacking Internet connectivity at 724 the time of observation. 726 Mechanisms standardized in DRIP WG MUST be capable of verifying that 727 messages claiming to have been sent from a UAS with a given UAS ID 728 indeed came from the claimed sender. 730 Whether a UAS ID is generated by the operator, GCS, UA, USS or 731 registry, or some collaboration thereamong, is unspecified; however, 732 there must be agreement on the UAS ID among these entities. 734 4.3. Privacy 736 PRIV-1 Confidential Handling: DRIP MUST enable confidential handling 737 of private information (i.e. any and all information 738 designated by neither cognizant authority nor the information 739 owner as public, e.g. personal data). 741 PRIV-2 Encrypted Transport: DRIP MUST enable selective strong 742 encryption of private data in motion in such a manner that 743 only authorized actors can recover it. If transport is via 744 IP, then encryption MUST be end-to-end, at or above the IP 745 layer. 747 PRIV-3 Encrypted Storage: DRIP SHOULD enable selective strong 748 encryption of private data at rest in such a manner that only 749 authorized actors can recover it. 751 As satisfying these requirements may require that authorized actors 752 have e.g. Internet connectivity to a Remote ID USS to enable 753 decryption, and such connectivity cannot be assured, DRIP SHOULD 754 provide automatic fallback to plaintext transmission of safety- 755 critical information when necessary. 757 5. IANA Considerations 759 It is likely that an IPv6 prefix or other namespace will be needed; 760 this will be specified in other documents. 762 6. Security Considerations 764 DRIP is all about safety and security, so content pertaining to such 765 is not limited to this section. DRIP information must be divided 766 into 2 classes: that which, to achieve the purpose, must be published 767 openly in clear plaintext, for the benefit of any observer; and that 768 which must be protected (e.g. PII of pilots) but made available to 769 properly authorized parties (e.g. public safety personnel who 770 urgently need to contact pilots in emergencies). Details of the 771 protection mechanisms will be provided in other documents. 772 Classifying the information will be addressed primarily in external 773 standards; herein it will be regarded as a matter for CAA, registry 774 and operator policies, for which enforcement mechanisms will be 775 defined within the scope of DRIP WG and offered. Mitigation of 776 adversarial correlation will also be addressed. 778 7. Acknowledgments 780 The work of the FAA's UAS Identification and Tracking (UAS ID) 781 Aviation Rulemaking Committee (ARC) is the foundation of later ASTM 782 [F3411-19] and IETF DRIP WG efforts. The work of ASTM F38.02 in 783 balancing the interests of diverse stakeholders is essential to the 784 necessary rapid and widespread deployment of UAS RID. 786 8. References 788 8.1. Normative References 790 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 791 Requirement Levels", BCP 14, RFC 2119, 792 DOI 10.17487/RFC2119, March 1997, 793 . 795 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 796 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 797 May 2017, . 799 8.2. Informative References 801 [CTA2063A] ANSI, "Small Unmanned Aerial Systems Serial Numbers", 802 September 2019. 804 [Delegated] 805 European Union Aviation Safety Agency (EASA), "Commission 806 Delegated Regulation (EU) 2019/945 of 12 March 2019 on 807 unmanned aircraft systems and on third-country operators 808 of unmanned aircraft systems", March 2019. 810 [F3411-19] ASTM, "Standard Specification for Remote ID and Tracking", 811 December 2019. 813 [Implementing] 814 European Union Aviation Safety Agency (EASA), "Commission 815 Implementing Regulation (EU) 2019/947 of 24 May 2019 on 816 the rules and procedures for the operation of unmanned 817 aircraft", May 2019. 819 [NPRM] United States Federal Aviation Administration (FAA), 820 "Notice of Proposed Rule Making on Remote Identification 821 of Unmanned Aircraft Systems", December 2019. 823 [Recommendations] 824 FAA UAS Identification and Tracking Aviation Rulemaking 825 Committee, "UAS ID and Tracking ARC Recommendations Final 826 Report", September 2017. 828 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 829 Unique IDentifier (UUID) URN Namespace", RFC 4122, 830 DOI 10.17487/RFC4122, July 2005, 831 . 833 [Stranger] Heinlein, R.A., "Stranger in a Strange Land", June 1961. 835 Authors' Addresses 837 Stuart W. Card (editor) 838 AX Enterprize 839 4947 Commercial Drive 840 Yorkville, NY 13495 841 United States of America 843 Email: stu.card@axenterprize.com 845 Adam Wiethuechter 846 AX Enterprize 847 4947 Commercial Drive 848 Yorkville, NY 13495 849 United States of America 851 Email: adam.wiethuechter@axenterprize.com 853 Robert Moskowitz 854 HTT Consulting 855 Oak Park, MI 48237 856 United States of America 858 Email: rgm@labs.htt-consult.com