idnits 2.17.1 draft-card-tmrid-uas-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 (29 January 2020) is 1547 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-moskowitz-hip-hierarchical-hit-03 == Outdated reference: A later version (-10) exists of draft-moskowitz-hip-new-crypto-04 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TMRID S. Card 3 Internet-Draft A. Wiethuechter 4 Intended status: Informational AX Enterprize 5 Expires: 1 August 2020 R. Moskowitz 6 HTT Consulting 7 29 January 2020 9 UAS Remote ID 10 draft-card-tmrid-uas-01 12 Abstract 14 This document is an Applicability Statement for various IETF 15 Technical Specifications, complementing emerging external standards 16 and regulations to meet needs for Unmanned Aircraft System (UAS) 17 remote identification (RID). The objectives are: to facilitate use 18 of existing Internet services to support UAS RID and to enable 19 enhanced RID related services; and to enable verification that UAS 20 RID information is trustworthy (to some extent, even in the absence 21 of Internet connectivity at the receiving node). 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 1 August 2020. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 4 59 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. UAS RID Problem Space . . . . . . . . . . . . . . . . . . . . 6 61 3.1. Network RID . . . . . . . . . . . . . . . . . . . . . . . 6 62 3.2. Broadcast RID . . . . . . . . . . . . . . . . . . . . . . 7 63 3.3. TM-RID Focus Problem Space . . . . . . . . . . . . . . . 8 64 4. Alternatives for IETF work on Trustworthy IDs . . . . . . . . 8 65 4.1. Requirements of Trustworthy IDs . . . . . . . . . . . . . 8 66 4.2. Currently selected IDs by ASTM . . . . . . . . . . . . . 8 67 4.3. Options for Trustworthy IDs . . . . . . . . . . . . . . . 9 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 73 8.2. Informative References . . . . . . . . . . . . . . . . . 10 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 76 1. Introduction 78 Emerging Civil Aviation Authority (CAA) regulations worldwide, 79 exemplified by current United States (US) Federal Aviation 80 Administration (FAA) rulemaking, will soon mandate, and many safety 81 and other considerations dictate (even absent regulations), that 82 Unmanned Aircraft Systems (UAS) be remotely identifiable. CAAs are 83 expected and FAA has stated its intent to require compliance with 84 industry consensus standards. 86 ASTM International, Technical Committee F38 (UAS), Subcommittee 87 F38.02 (Aircraft Operations), Work Item WK65041 (UAS Remote ID and 88 Tracking), is a Proposed New Standard [WK65041]. It defines 2 means 89 of UAS remote identification (RID): Network RID via the Internet; and 90 Broadcast RID via a one-way data link direct from the Unmanned 91 Aircraft (UA) to the observer's device. Network RID depends upon 92 Internet connectivity between the observer and either the UA itself 93 or any of various proxies. Broadcast RID should need Internet (or 94 other Wide Area Network) connectivity only for UAS registry 95 information lookup using the directly locally received UAS ID as a 96 key. 98 The need for near-universal deployment of UAS RID is pressing. This 99 implies the need to support use by observers of already ubiquitous 100 mobile devices (smartphones and tablets). UA onboard RID devices are 101 severely constrained in Size, Weight and Power (SWaP). Cost is a 102 significant impediment to the necessary near-universal adoption of 103 UAS send and observer receive RID capabilities. To accomodate the 104 most severely constrained cases, all these conspire to motivate 105 system design decisions, especially for the Broadcast RID data link, 106 which complicate the protocol design problem: one-way links; 107 extremely short packets; and Internet-disconnected operation of UA 108 onboard devices. Internet-disconnected operation of observer devices 109 has been deemed by ASTM F38.02 too infrequent to address, but for 110 some users is important and presents further challenges. 112 Heavyweight security protocols are infeasible, yet trustworthiness of 113 UAS RID information is essential. Even the most basic datum, the UAS 114 ID string (typically number) itself, under [WK65041], can be merely 115 an unsubstantiated claim. 117 Further, an ID is not an end in itself; it exists to enable lookups 118 and provision of services complementing mere identification, e.g. 119 dynamic establishment of secure communications between the observer 120 and the UAS pilot. [WK65041] neither fully specifies nor appears to 121 facilitate these functions, especially in the case where the observer 122 lacks real time Internet access. 124 Finally, [WK65041] proposes the use of plaintext and mostly static 125 UAS ID strings. Even if lookup from these to operator Personally 126 Identifiable Information (PII) is successfully limited to strongly 127 authenticated personnel, properly authorized per policy: static IDs 128 enable trivial correlation of patterns of use, unacceptable in many 129 applications, e.g. package delivery routes of competitors. 131 IETF can help by providing expertise as well as mature and evolving 132 standards. Host Identity Protocol (HIPv2) [RFC7401] and its Domain 133 Name System (DNS) extensions [RFC8005] can complement emerging 134 external standards for UAS RID, to facilitate utilization of existing 135 and provision of enhanced network services, and to enable 136 verification that UAS RID information is trustworthy (to some extent, 137 even in the absence of Internet connectivity at the receiving node). 139 2. Terms and Definitions 140 2.1. Requirements Terminology 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described in BCP 145 14 [RFC2119] [RFC8174] when, and only when, they appear in all 146 capitals, as shown here. 148 2.2. Definitions 150 CAA 151 Civil Aviation Authority. An example is the Federal Aviation 152 Administration (FAA) in the United States of America. 154 C2 155 Command and Control. A set of organizational and technical 156 attributes and processes that employs human, physical, and 157 information resources to solve problems and accomplish missions. 158 Mainly used in military contexts. 160 GCS 161 Ground Control Station. The part of the UAS that the remote pilot 162 uses to exercise C2 over the UA, whether by remotely exercising UA 163 flight controls to fly the UA, by setting GPS waypoints, or 164 otherwise directing its flight. 166 HI 167 Host Identity. The public key portion of an asymmetric keypair 168 from HIP. In this document it is assumed that the HI is based on 169 a EdDSA25519 keypair. This is supported by new crypto defined in 170 [I-D.moskowitz-hip-new-crypto]. 172 HIT 173 Host Identity Tag. A 128 bit handle on the HI. Defined in HIPv2 174 [RFC7401]. 176 HHIT 177 Hierarchical Host Identity Tag. A HIT with extra information not 178 found in a standard HIT. Defined in 179 [I-D.moskowitz-hip-hierarchical-hit]. 181 UA 182 Unmanned Aircraft. Typically a military or commercial "drone" but 183 can include any and all aircraft that are unmanned. 185 UAS 186 Unmanned Aircraft System. Composed of UA, all required on-board 187 subsystems, payload, control station, other required off-board 188 subsystems, any required launch and recovery equipment, all 189 required crew members, and C2 links between UA and control 190 station. 192 UTM 193 UAS Traffic Management. A "traffic management" ecosystem for 194 "uncontrolled" UAS operations separate from, but complementary to, 195 the FAA's Air Traffic Management (ATM) system for "controlled" 196 operations of manned aircraft. 198 USS 199 UAS Service Supplier. Provide UTM services to support the UAS 200 community, to connect Operators and other entities to enable 201 information flow across the USS network, and to promote shared 202 situational awareness among UTM participants. (From FAA UTM 203 ConOps V1, May 2018). 205 RID 206 Remote ID. System for identifying UA during flight by other 207 parties. 209 Observer 210 Referred to in other UAS documents as a "user", but there are also 211 other classes of RID users, so we prefer "observer" to denote an 212 individual who has observed an UA and wishes to know something 213 about it, starting with its ID. 215 UAS ID 216 Unique UAS identifier. Per [WK65041], maximum length of 20 bytes. 218 UAS ID Type 219 Identifier type index. Per [WK65041], 4 bits, values 0-3 already 220 specified. 222 RID SP 223 UAS RID Service Provider. System component that compiles 224 information from various sources (and methods) in its given 225 service area. 227 RID DP 228 UAS RID Display Provider. System component that requests data 229 from one or more RID SP and aggregates them to display to a user 230 application on a device. 232 UAS RID Verification Service 233 System component designed to handle the authentication 234 requirements of RID by offloading verification to a web hosted 235 service. 237 3. UAS RID Problem Space 239 UA may be fixed wing Short Take-Off and Landing (STOL), rotary wing 240 (e.g. helicopter) Vertical Take-Off and Landing (VTOL), or hybrid. 241 They may be single engine or multi engine. The most common today are 242 multicopters: rotary wing, multi engine. The explosion in UAS was 243 enabled by hobbyist development, for multicopters, of advanced flight 244 stability algorithms, enabling even inexperienced pilots tp take off, 245 fly to a location of interest, hover, and return to the take-off 246 location or land at a distance. UAS can be remotely piloted by a 247 human (e.g. with a joystick) or programmed to proceed from Global 248 Positioning System (GPS) waypoint to waypoint in a weak form of 249 autonomy; stronger autonomy is coming. UA are "low observable": they 250 typically have a small radar cross section; they make noise quite 251 noticeable at short range but difficult to detect at distances they 252 can quickly close (500 meters in under 17 seconds at 60 knots); they 253 typically fly at low altitudes (for the small UAS to which RID 254 applies, under 400 feet Above Ground Level in the US); they are 255 highly maneuverable so can fly under trees and between buildings. 257 UA can carry payloads including sensors, cyber and kinetic weapons or 258 can be used themselves as weapons by flying them into targets. They 259 can be flown by clueless, careless or criminal operators. Thus the 260 most basic function of UAS RID is "Identification Friend or Foe" to 261 mitigate the significant threat they present. Numerous other 262 applications can be enabled or facilitated by RID: consider the 263 importance of identifiers in many Internet protocols and services. 265 Network RID from the UA itself (rather than from a proxy) and 266 Broadcast RID require one or more wireless data links from the UA, 267 but such communications are challenging due to $SWaP constraints and 268 low altitude flight amidst structures and foliage over terrain. 270 3.1. Network RID 272 Network RID has several variants. The UA may have persistent onboard 273 Internet connectivity, in which case it can consistently source RID 274 information directly over the Internet. The UA may have intermittent 275 onboard Internet connectivity, in which case a proxy must source RID 276 information whenever the UA itself is offline. The UA may not have 277 Internet connectivity of its own, but have instead some other form of 278 communications to a (typically ground) node that can relay RID 279 information to the Internet; this would typically be the GCS (which 280 to perform its function must know where the UA is) or USS (which in 281 the UTM system is required to be kept informed by the UAS operator). 282 The UA may have no means of sourcing RID information, in which case 283 the GCS, USS or other proxy may source it. In the extreme case, this 284 would be the pilot using a web browser to designate, to a USS or 285 other UTM entity, a time-bounded airspace volume in which an 286 operation will be conducted; this may impede disambiguation of ID if 287 multiple UAS operate in the same or overlapping spatio-temporal 288 volumes. 290 In most cases in the near term, if the RID information is fed to the 291 Internet directly by the UA or remote pilot, the first hop data links 292 will be cellular Long Term Evolution (LTE) or WiFi, but provided the 293 data link can support at least IP and ideally TCP, its type is 294 generally immaterial to the higher layer protocols. The ultimate 295 source of Network RID information feeds a RID Service Provider (SP), 296 which essentially proxies for that and other sources; the ultimate 297 consumer of Network RID information obtains it from a RID Display 298 Provider (DP). Each DP aggregates information from all SPs that have 299 UA currently operating in the airspace for which that DP is 300 cognizant. 302 Network RID is the more flexible and less constrained of the UAS RID 303 means specified in [WK65041]. Any IETF work needed to support or 304 leverage it is left for later efforts; it is not further addressed 305 herein or in other initial tm-rid documents. 307 3.2. Broadcast RID 309 [WK65041] specifies 3 Broadcast RID data links: Bluetooth 4.X; 310 Bluetooth 5.X Long Range; and Wifi with Neighbor Awareness Networking 311 (NAN). For compliance with this standard, an UA must broadcast 312 (using advertisement mechanisms where no other option supports 313 broadcast) on at least one of these; if broadcasting on Bluetooth 314 5.x, it is also required concurrently to do so on 4.x (referred to in 315 [WK65041] as Bluetooth Legacy). 317 The selection of the Broadcast medium was driven by research into 318 what is commonly available on 'ground' units (smartphones and 319 tablets) and what was found as prevalent or 'affordable' in UA. 320 Further, there must be an API for the UAS receiving application to 321 have access to these messages. At this time, only Bluetooth 4.X 322 support is readily available, thus the current focus is on working 323 within the 26 byte limit of the Bluetooth 4.X "Broadcast Frame" that 324 goes out on the beacon channels. 326 Finally, the 26 byte limit of the Bluetooth 4.1 "Broadcast Frame" 327 strictly enforces the RID maximum length of 20 bytes. 329 3.3. TM-RID Focus Problem Space 331 TM-RID will focus on adding immediate usability, thus trust to, 332 Broadcast RID. The one-way nature of Broadcast RID precludes any 333 stateful security protocol. Under [WK65041], any UA can announce a 334 RID and an observer would be seriously challenged to validate it or 335 any other information about the UA looked up from it. Thus providing 336 trust in the RID and related trust for all Broadcast messages is 337 critical for the safe and secure operation of UAs. 339 Three levels of functionality will be considered: 341 1. verify that HHIT is duly registered with a known registry AND 342 that any messages signed with its key came from it; 344 2. look up not only static UAS registry and dynamic UTM information 345 but also Intenet direct contact information for services relating 346 to the UA, its current mission, etc., including communications 347 with the remote pilot (or proxy) and USS; 349 3. dynamically establish strongly mutually authenticated, E2E 350 strongly encrypted communications with the UAS RID sender and 351 entities looked up via (2) above. 353 4. Alternatives for IETF work on Trustworthy IDs 355 4.1. Requirements of Trustworthy IDs 357 Just a couple of requirements: 359 1. The ID MUST be 20 bytes or smaller. 361 2. It MUST be non-spoofable within the context of Remote ID 362 broadcast messages (some collection of messages provides proof of 363 UA ownership of ID). 365 3. In context (that is in a Remote ID Broadcast message), just the 366 ID provides enough information on how at least the observer's USS 367 (UAS Service Provider / Display Provider) can provide both public 368 and private information on the UAS. 370 4.2. Currently selected IDs by ASTM 372 Now a little 'context' setting. ASTM has already defined a set of 373 textual Remote IDs: 375 1 Serial Number [CTA2063A] 376 2 CAA Assigned ID 378 3 UTM Assigned ID [RFC4122] 380 The work here MUST surpass these in terms of Trustworthiness. 382 4.3. Options for Trustworthy IDs 384 The options found are: 386 1. X.509 certs where something like the cert sequenceNumber is the 387 Remote ID. 389 2. Naming Things with Hashes, Section 8.2 of [RFC6920] 391 3. SSH keyID 393 4. HIT (Host Identity Tag) [RFC7401] 395 Option 1 is no better than what ASTM/FAA is considering for any of 396 the current proposed types. Somehow, there will be a PKI and from 397 that knowledge of the UAS is gained. This REQUIRES Internet Access 398 (think disaster or other non-Internet situations) and a GLOBAL PKI 399 (the UA flew from Canada to the US or UK to France post Brexit). 401 Option 2 meets requirements 1 and 2, but needs to be augmented so 402 that the Hash provides context for 3. Is it supported for IPsec and/ 403 or QUIC for UAS/observer secure communications (NetworkID). 405 5. IANA Considerations 407 It is likely that an IPv6 prefix will be needed for the HHIT (or 408 other identifier) space; this will be specified in other drafts. 410 6. Security Considerations 412 UAS RID is all about safety and security, so content pertaining to 413 such is not limited to this section. UAS RID information must be 414 divided into 2 classes: that which, to achieve the purpose, must be 415 published openly in plaintext, for the benefit of any observer; and 416 that which must be protected (e.g. PII of pilots) but made available 417 to properly authorized parties (e.g. public safety personnel who 418 urgently need to contact pilots in emergencies). Details of the 419 protection mechanisms will be provided in other drafts. Classifying 420 the information will be addressed primarily in external standards but 421 also herein as needed. 423 7. Acknowledgments 425 The work of the FAA's UAS Identification and Tracking (UAS ID) 426 Aviation Rulemaking Committee (ARC) is the foundation of later ASTM 427 and proposed IETF efforts. The work of ASTM F38.02 in balancing the 428 interests of diverse stakeholders is essential to the necessary rapid 429 and widespread deployment of UAS RID. 431 8. References 433 8.1. Normative References 435 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 436 Requirement Levels", BCP 14, RFC 2119, 437 DOI 10.17487/RFC2119, March 1997, 438 . 440 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 441 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 442 RFC 7401, DOI 10.17487/RFC7401, April 2015, 443 . 445 [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name 446 System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, 447 October 2016, . 449 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 450 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 451 May 2017, . 453 8.2. Informative References 455 [CTA2063A] ANSI, "Small Unmanned Aerial Systems Serial Numbers", 456 September 2019. 458 [I-D.moskowitz-hip-hierarchical-hit] 459 Moskowitz, R., Card, S., and A. Wiethuechter, 460 "Hierarchical HITs for HIPv2", Work in Progress, Internet- 461 Draft, draft-moskowitz-hip-hierarchical-hit-03, 16 462 December 2019, . 465 [I-D.moskowitz-hip-new-crypto] 466 Moskowitz, R., Card, S., and A. Wiethuechter, "New 467 Cryptographic Algorithms for HIP", Work in Progress, 468 Internet-Draft, draft-moskowitz-hip-new-crypto-04, 23 469 January 2020, . 472 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 473 Unique IDentifier (UUID) URN Namespace", RFC 4122, 474 DOI 10.17487/RFC4122, July 2005, 475 . 477 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 478 Keranen, A., and P. Hallam-Baker, "Naming Things with 479 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 480 . 482 [WK65041] ASTM, "Standard Specification for Remote ID and Tracking", 483 September 2019. 485 Authors' Addresses 487 Stuart W. Card 488 AX Enterprize 489 4947 Commercial Drive 490 Yorkville, NY 13495 491 United States of America 493 Email: stu.card@axenterprize.com 495 Adam Wiethuechter 496 AX Enterprize 497 4947 Commercial Drive 498 Yorkville, NY 13495 499 United States of America 501 Email: adam.wiethuechter@axenterprize.com 503 Robert Moskowitz 504 HTT Consulting 505 Oak Park, MI 48237 506 United States of America 508 Email: rgm@labs.htt-consult.com