idnits 2.17.1 draft-moskowitz-drip-crowd-sourced-rid-02.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 (19 March 2020) is 1497 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) -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) -- Obsolete informational reference (is this intentional?): RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DRIP R. Moskowitz 3 Internet-Draft HTT Consulting 4 Intended status: Standards Track S. Card 5 Expires: 20 September 2020 A. Wiethuechter 6 AX Enterprize 7 19 March 2020 9 Crowd Sourced Remote ID 10 draft-moskowitz-drip-crowd-sourced-rid-02 12 Abstract 14 This document describes using the ASTM Broadcast Remote ID (B-RID) 15 specification in a "crowd sourced" smart phone environment to provide 16 much of the FAA mandated Network Remote ID (N-RID) functionality. 17 This crowd sourced B-RID data will use multi-lateration to add a 18 level of reliability in the location data on the Unmanned Aircraft 19 (UA). The crowd sourced environment will also provide a monitoring 20 coverage map to authorized observers. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 20 September 2020. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Draft Status . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4 58 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 4 59 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3.1. Meeting the needs of Network ID . . . . . . . . . . . . . 6 62 3.2. Trustworthiness of Proxied Data . . . . . . . . . . . . . 6 63 3.3. Defense against fraudulent RID Messages . . . . . . . . . 6 64 4. The Finder - SDSP Security Relationship . . . . . . . . . . . 6 65 4.1. The Finder Map . . . . . . . . . . . . . . . . . . . . . 7 66 4.2. Managing Finders . . . . . . . . . . . . . . . . . . . . 7 67 5. The CS-RID Messages . . . . . . . . . . . . . . . . . . . . . 7 68 5.1. CS-RID MESSAGE TYPE . . . . . . . . . . . . . . . . . . . 8 69 5.2. The CS-RID B-RID Proxy Message . . . . . . . . . . . . . 8 70 5.2.1. CS-RID ID . . . . . . . . . . . . . . . . . . . . . . 9 71 5.3. CS-RID Finder Registration . . . . . . . . . . . . . . . 9 72 5.4. CS-RID SDSP Response . . . . . . . . . . . . . . . . . . 9 73 5.5. CS-RID Location Update . . . . . . . . . . . . . . . . . 10 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 7.1. Privacy Concerns . . . . . . . . . . . . . . . . . . . . 10 77 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 78 9. Normative References . . . . . . . . . . . . . . . . . . . . 11 79 10. Informative References . . . . . . . . . . . . . . . . . . . 11 80 Appendix A. Using LIDAR for UA location . . . . . . . . . . . . 12 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 83 1. Introduction 85 This document defines a mechanism to capture the ASTM Broadcast 86 Remote ID messages (B-RID) [F3411-19] on any Internet connected 87 device that receives them and can forward them to the SDSP(s) 88 responsible for the geographic area the UA and receivers are in. 89 This will create a ecosystem that will meet most if not all data 90 collection requriments that CAAs are placing on Network Remote ID 91 (N-RID). 93 These Internet connected devices are herein called "Finders", as they 94 find UAs by listening for B-RID messages. The Finders are B-RID 95 forwarding proxies. Their potentially limited spacial view of RID 96 messages could result in bad decisions on what messages to send to 97 the SDSP and which to drop. The SDSP will make any filtering 98 decisions in what it forwards to the UTM(s). 100 Finders can be smartphones, tablets, connected cars, or any computing 101 platform with Internet connectivity that can meet the requirements 102 defined in this document. It is not expected, nor necessary, that 103 Finders have any information about a UAS beyond the content in the 104 B-RID messages. 106 Finders MAY only need a loose association with the SDSP(s). They may 107 only have the SDSP's Public Key and FQDN. It would use these, along 108 with the Finder's Public Key to use ECIES, or other security methods, 109 to send the messages in a secure manner to the SDSP. The SDSP MAY 110 require a stronger relationship to the Finders. This may range from 111 the Finder's Public Key being registered to the SDSP with other 112 information so that the SDSP has some level of trust in the Finders 113 to requiring transmissions be sent over long-lived transport 114 connections like ESP or DTLS. 116 This document has minimal information about the actions of SDSPs. In 117 general the SDSP is out of scope of this document. That said, the 118 SDSPs should not simply proxy B-RID messages to the UTM(s). They 119 should perform some minimal level of filtering and content checking 120 before forwarding those messages that pass these tests in a secure 121 manner to the UTM(s). 123 The SDSPs are also capable of maintaining a monitoring map, based on 124 location of active Finders. UTMs may use this information to notify 125 authorized observers of where this is and there is not monitoring 126 coverage. They may also use there information of where to place pro- 127 active monitoring coverage. 129 An SDSP SHOULD only forward Authenticated B-RID messages like those 130 defined in [tmrid-auth] to the UTM(s). Further, the SDSP SHOULD 131 validate the Remote ID (RID) and the Authentication signature before 132 forwarding anything from the UA. 134 When 3 or more Finders are reporting to an SDSP on a specific UA, the 135 SDSP is in a unique position to perform multilateration on these 136 messages and compute the Finder's view of the UA location to compare 137 with the UA Location/Vector messages. This check against the UA's 138 location claims is both a validation on the UA's reliability as well 139 as the trustworthiness of the Finders. Other than providing data to 140 allow for multilateration, this SDSP feature is out of scope of this 141 document. 143 1.1. Draft Status 145 This draft is still incomplete. New features are being added as 146 capabilities are researched. The actual message formats also still 147 need work. 149 2. Terms and Definitions 151 2.1. Requirements Terminology 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 155 "OPTIONAL" in this document are to be interpreted as described in BCP 156 14 [RFC2119] [RFC8174] when, and only when, they appear in all 157 capitals, as shown here. 159 2.2. Definitions 161 B-RID 162 Broadcast Remote ID. A method of sending RID messages as 1-way 163 transmissions from the UA to any Observers within radio range. 165 CAA 166 Civil Aeronautics Administration. An example is the Federal 167 Aviation Administration (FAA) in the United States of America. 169 ECIES 170 Elliptic Curve Integrated Encryption Scheme. A hybrid encryption 171 scheme which provides semantic security against an adversary who 172 is allowed to use chosen-plaintext and chosen-ciphertext attacks. 174 GCS 175 Ground Control Station. The part of the UAS that the remote pilot 176 uses to exercise C2 over the UA, whether by remotely exercising UA 177 flight controls to fly the UA, by setting GPS waypoints, or 178 otherwise directing its flight. 180 Finder 181 In Internet connected device that can receive B-RID messages and 182 forward them to a UTM. 184 Observer 185 Referred to in other UAS documents as a "user", but there are also 186 other classes of RID users, so we prefer "observer" to denote an 187 individual who has observed an UA and wishes to know something 188 about it, starting with its RID. 190 Multilateration 191 Multilateration (more completely, pseudo range multilateration) is 192 a navigation and surveillance technique based on measurement of 193 the times of arrival (TOAs) of energy waves (radio, acoustic, 194 seismic, etc.) having a known propagation speed. 196 NETSP 197 Network RID Service Provider. USS receiving Network RID messages 198 from UAS (UA or GCS), storing for a short specified time, making 199 available to NETDP. 201 NETDP 202 Network RID Display Provider. Entity (might be USS) aggregating 203 data from multiple NETSPs to answer query from observer (or other 204 party) desiring Situational Awareness of UAS operating in a 205 specific airspace volume. 207 N-RID 208 Network Remote ID. A method of sending RID messages via the 209 Internet connection of the UAS directly to the UTM. 211 RID 212 Remote ID. A unique identifier found on all UA to be used in 213 communication and in regulation of UA operation. 215 SDSP 216 Supplemental Data Service Provider. Entity providing information 217 that is allowed, but not required to be present in the UTM system. 219 UA 220 Unmanned Aircraft. In this document UA's are typically though of 221 as drones of commerical or military variety. This is a very 222 strict definition which can be relaxed to include any and all 223 aircraft that are unmanned. 225 UAS 226 Unmanned Aircraft System. Composed of Unmanned Aircraft and all 227 required on-board subsystems, payload, control station, other 228 required off-board subsystems, any required launch and recovery 229 equipment, all required crew members, and C2 links between UA and 230 the control station. 232 UTM 233 UAS Traffic Management. A "traffic management" ecosystem for 234 uncontrolled operations that is separate from, but complementary 235 to, the FAA's Air Traffic Management (ATM) system. 237 USS 238 UAS Service Supplier. Provide UTM services to support the UAS 239 community, to connect Operators and other entities to enable 240 information flow across the USS network, and to promote shared 241 situational awareness among UTM participants. (From FAA UTM 242 ConOps V1, May 2018). 244 3. Problem Space 246 3.1. Meeting the needs of Network ID 248 The Federal (US) Aviation Authority (FAA), in the December 31, 2019 249 Remote ID Notice of Proposed Rulemaking [FAA-NPRM], is requiring 250 "Standard" and "Limited" Remote ID. Standard is when the UAS 251 provides both Network and Broadcast RID. Limited is when the UAS 252 provides only Network RID. The FAA has dropped their previous 253 position on allowing for only Broadcast RID. We can guess as to 254 their reasons; they are not spelled out in the NPRM. It may be that 255 just B-RID does not meet the FAA's statutory UA tracking 256 responsibility. 258 The UAS vendors have commented that N-RID places considerable demands 259 on currently used UAS. For some UAS like RC planes, meaningful N-RID 260 (via the Pilot's smartphone) are of limited value. A mechanism that 261 can augment B-RID to provide N-RID would help all members of the UAS 262 environment to provide safe operation and allow for new applications. 264 3.2. Trustworthiness of Proxied Data 266 When a proxy is introduced in any communication protocol, there is a 267 risk of corrupted data and DOS attacks. 269 3.3. Defense against fraudulent RID Messages 271 TBD 273 TBD 275 4. The Finder - SDSP Security Relationship 277 The SDSP(s) and Finders SHOULD use EDDSA [RFC8032] keys as their 278 trusted Identities. The public keys SHOULD be registered 279 Hierarchical HITS, [hierarchical-hit] and [hhit-registries]. 281 The SDSP uses some process (out of scope here) to register the 282 Finders and their EDDSA Public Key. During this registration, the 283 Finder gets the SDSP's EDDSA Public Key. These Public Keys allow for 284 the following options for authenticated messaging from the Finder to 285 the SDSP. 287 1. ECIES can be used with a unique nonce to authenticate each 288 message sent from a Finder to the SDSP. 290 2. ECIES can be used at the start of some period (e.g. day) to 291 establish a shared secret that is then used to authenticate each 292 message sent from a Finder to the SDSP sent during that period. 294 3. HIPv2 [RFC7401] can be used to establish a session secret that is 295 then used with ESP [RFC4303] to authenticate each message sent 296 from a Finder to the SDSP. 298 4. DTLS [RFC5238] can be used to establish a secure connection that 299 is then used to authenticate each message sent from a Finder to 300 the SDSP. 302 4.1. The Finder Map 304 The Finders are regularly providing their SDSP with their location. 305 This is through the B-RID Proxy Messages and Finder Location Update 306 Messages. With this information, the SDSP can maintain a monitoring 307 map. That is a map of where there Finder coverage. 309 4.2. Managing Finders 311 Finder density will vary over time and space. For example, sidewalks 312 outside an urban train station can be packed with pedestrians at rush 313 hour, either coming or going to their commute trains. An SDSP may 314 want to proactively limit the number of active Finders in such 315 situations. 317 Using the Finder mapping feature, the SDSP can instruct Finders to 318 NOT proxy B-RID messages. These Finders will continue to report 319 their location and through that reporting, the SDSP can instruct them 320 to again take on the proxying role. For example a Finder moving 321 slowly along with dozens of other slow-moving Finders may be 322 instructed to suspend proxying. Whereas a fast-moving Finder at the 323 same location (perhaps a connected car or a pedestrian on a bus) 324 would not be asked to suspend proxying as it will soon be out of the 325 congested area. 327 5. The CS-RID Messages 329 The CS-RID messages between the Finders and the SDSPs primarily 330 support the proxy role of the Finders in forwarding the B-RID 331 messages. There are also Finder registration and status messages. 333 CS-RID information is represented in CBOR [RFC7049]. COSE [RFC8152] 334 may be used for CS-RID MAC and COAP [RFC7252] for the CS-RID 335 protocol. 337 The following is a general representation of the content in the CS- 338 RID messages. 340 ( CS-RID MESSAGE TYPE, 341 CS-RID MESSAGE CONTENT, 342 CS-RID MAC) 344 The CS-RID MESSAGE CONTENT varies by MESSAGE TYPE. 346 5.1. CS-RID MESSAGE TYPE 348 The CS-RID MESSAGE TYPE is: 350 Number CS-RID Message Type 351 ------ ----------------- 352 0 Reserved 353 1 B-RID Forwarding 354 2 Finder Registration 355 3 SDSP Response 356 4 Finder Location 358 5.2. The CS-RID B-RID Proxy Message 360 The Finders add their own information to the B-RID messages, 361 permitting the SDSP(s) to gain additional knowledge about the UA(s). 362 The RID information is the B-RID message content plus the MAC 363 address. The MAC address is critical, as it is the only field that 364 links a UA's B-RID messages together. Only the ASTM Basic ID Message 365 and possibly the Authentication Message contain the UAS ID field. 367 The Finders add an SDSP assigned ID, a 64 bit timestamp, GPS 368 information, and type of B-RID media to the B-RID message. Both the 369 timestamp and GPS information are for when the B-RID message(s) were 370 received, not forwarded to the SDSP. All this content is MACed using 371 a key shared between the Finder and SDSP. 373 The following is a representation of the content in the CS-RID 374 messages. 376 ( CS-RID MESSAGE TYPE, 377 CS-RID ID, 378 RECEIVE TIMESTAMP, 379 RECEIVE GPS, 380 RECEIVE RADIO TYPE, 381 B-RID MAC ADDRESS, 382 B-RID MESSAGE, 383 CS-RID MAC) 385 5.2.1. CS-RID ID 387 The CS-RID ID is the ID recognized by the SDSP. This may be an HHIT 388 Hierarchical HITs [hierarchical-hit], or any ID used by the SDSP. 390 5.3. CS-RID Finder Registration 392 The CS-RID Finder MAY use HIPv2 [RFC7401] with the SDSP to establish 393 a Security Association and a shared secret to use for the CS-RID MAC 394 generation. In this approach, the HIPv2 mobility functionality and 395 ESP [RFC4303] support are not used. 397 When HIPv2 is used as above, the Finder Registration is a SDSP "wake 398 up". It is sent prior to the Finder sending any proxied B-RID 399 messages to ensure that the SDSP is able to receive and process the 400 messages. 402 In this usage, the CS-RID is the Finder HIT. If the SDSP has lost 403 state with the Finder, it initiates the HIP exchange with the Finder 404 to reestablish HIP state and a new shared secret for the CS-RID B-RID 405 Proxy Messages. In this case the Finder Registration Message is: 407 ( CS-RID MESSAGE TYPE, 408 CS-RID ID, 409 CS-RID TIMESTAMP, 410 CS-RID GPS, 411 CS-RID MAC) 413 5.4. CS-RID SDSP Response 415 The SDSP MAY respond to any Finder messages to instruct the Finder on 416 its behavior. 418 ( CS-RID MESSAGE TYPE, 419 SDSP ID, 420 CS-RID ID, 421 CS-RID PROXY STATUS, 422 CS-RID UPDATE INTERVAL, 423 CS-RID MAC) 425 The Proxy Status instructs the Finder if it should actively proxy 426 B-RID messages, or suspend proxying and only report its location. 428 The Update Interval is the frequency that the Finder SHOULD notify 429 the SDSP of its current location using the Location Update message. 431 5.5. CS-RID Location Update 433 The Finder SHOULD provide regular location updates to the SDSP. The 434 interval is based on the Update Interval from Section 5.4 plus a 435 random slew less than 1 second. The Location Update message is only 436 sent when no other CS-RID messages, containing the Finder's GPS 437 location, have been sent since the Update Interval. 439 If the Finder has not recieved a SDSP Registration Response, a 440 default of 5 minutes is used for the Update Interval. 442 ( CS-RID MESSAGE TYPE, 443 CS-RID ID, 444 CS-RID TIMESTAMP, 445 CS-RID GPS, 446 CS-RID MAC) 448 6. IANA Considerations 450 TBD 452 7. Security Considerations 454 TBD 456 7.1. Privacy Concerns 458 TBD 460 8. Acknowledgments 462 The Crowd Sourcing idea in this document came from the Apple "Find My 463 Device" presentation at the International Association for 464 Cryptographic Research's Real World Crypto 2020 conference. 466 9. Normative References 468 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 469 Requirement Levels", BCP 14, RFC 2119, 470 DOI 10.17487/RFC2119, March 1997, 471 . 473 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 474 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 475 May 2017, . 477 10. Informative References 479 [F3411-19] ASTM International, "Standard Specification for Remote ID 480 and Tracking", February 2020, 481 . 483 [FAA-NPRM] Federal (US) Aviation Authority, "FAA Remote ID Notice of 484 Proposed Rule Making", December 2019, 485 . 487 [hhit-registries] 488 Moskowitz, R., Card, S., and A. Wiethuechter, 489 "Hierarchical HIT Registries", Work in Progress, Internet- 490 Draft, draft-moskowitz-hip-hhit-registries-02, 9 March 491 2020, . 494 [hierarchical-hit] 495 Moskowitz, R., Card, S., and A. Wiethuechter, 496 "Hierarchical HITs for HIPv2", Work in Progress, Internet- 497 Draft, draft-moskowitz-hip-hierarchical-hit-04, 3 March 498 2020, . 501 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 502 RFC 4303, DOI 10.17487/RFC4303, December 2005, 503 . 505 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 506 the Datagram Congestion Control Protocol (DCCP)", 507 RFC 5238, DOI 10.17487/RFC5238, May 2008, 508 . 510 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 511 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 512 October 2013, . 514 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 515 Application Protocol (CoAP)", RFC 7252, 516 DOI 10.17487/RFC7252, June 2014, 517 . 519 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 520 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 521 RFC 7401, DOI 10.17487/RFC7401, April 2015, 522 . 524 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 525 Signature Algorithm (EdDSA)", RFC 8032, 526 DOI 10.17487/RFC8032, January 2017, 527 . 529 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 530 RFC 8152, DOI 10.17487/RFC8152, July 2017, 531 . 533 [tmrid-auth] 534 Wiethuechter, A., Card, S., and R. Moskowitz, "TM-RID 535 Authentication Formats", Work in Progress, Internet-Draft, 536 draft-wiethuechter-tmrid-auth-05, 18 February 2020, 537 . 540 Appendix A. Using LIDAR for UA location 542 If the Finder has LIDAR or similar detection equipment (e.g. on a 543 connected car) that has full sky coverage, the Finder can use this 544 equipment to locate UAs in its airspace. The Finder would then be 545 able to detect non-participating UAs. 547 This would provide valuable information to SDSPs to forward to UTMs 548 on potential at-risk situations. 550 At this time, research on LIDAR and other detection technology is 551 needed. Would more than UA location information be available? What 552 information can be sent in a CS-RID message for such "unmarked" UAs? 554 Authors' Addresses 556 Robert Moskowitz 557 HTT Consulting 558 Oak Park, MI 48237 559 United States of America 561 Email: rgm@labs.htt-consult.com 562 Stuart W. Card 563 AX Enterprize 564 4947 Commercial Drive 565 Yorkville, NY 13495 566 United States of America 568 Email: stu.card@axenterprize.com 570 Adam Wiethuechter 571 AX Enterprize 572 4947 Commercial Drive 573 Yorkville, NY 13495 574 United States of America 576 Email: adam.wiethuechter@axenterprize.com