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