idnits 2.17.1 draft-moskowitz-drip-crowd-sourced-rid-03.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 (20 March 2020) is 1492 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: 21 September 2020 A. Wiethuechter 6 AX Enterprize 7 20 March 2020 9 Crowd Sourced Remote ID 10 draft-moskowitz-drip-crowd-sourced-rid-03 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 21 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. Advantages of Broadcast Remote ID . . . . . . . . . . . . 6 63 3.3. Trustworthiness of Proxied Data . . . . . . . . . . . . . 7 64 3.4. Defense against fraudulent RID Messages . . . . . . . . . 7 65 4. The Finder - SDSP Security Relationship . . . . . . . . . . . 7 66 4.1. The Finder Map . . . . . . . . . . . . . . . . . . . . . 8 67 4.2. Managing Finders . . . . . . . . . . . . . . . . . . . . 8 68 5. The CS-RID Messages . . . . . . . . . . . . . . . . . . . . . 8 69 5.1. CS-RID MESSAGE TYPE . . . . . . . . . . . . . . . . . . . 8 70 5.2. The CS-RID B-RID Proxy Message . . . . . . . . . . . . . 9 71 5.2.1. CS-RID ID . . . . . . . . . . . . . . . . . . . . . . 9 72 5.3. CS-RID Finder Registration . . . . . . . . . . . . . . . 9 73 5.4. CS-RID SDSP Response . . . . . . . . . . . . . . . . . . 10 74 5.5. CS-RID Location Update . . . . . . . . . . . . . . . . . 10 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 7.1. Privacy Concerns . . . . . . . . . . . . . . . . . . . . 11 78 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 79 9. Normative References . . . . . . . . . . . . . . . . . . . . 11 80 10. Informative References . . . . . . . . . . . . . . . . . . . 11 81 Appendix A. Using LIDAR for UA location . . . . . . . . . . . . 13 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 84 1. Introduction 86 This document defines a mechanism to capture the ASTM Broadcast 87 Remote ID messages (B-RID) [F3411-19] on any Internet connected 88 device that receives them and can forward them to the SDSP(s) 89 responsible for the geographic area the UA and receivers are in. 90 This will create a ecosystem that will meet most if not all data 91 collection requriments that CAAs are placing on Network Remote ID 92 (N-RID). 94 These Internet connected devices are herein called "Finders", as they 95 find UAs by listening for B-RID messages. The Finders are B-RID 96 forwarding proxies. Their potentially limited spacial view of RID 97 messages could result in bad decisions on what messages to send to 98 the SDSP and which to drop. The SDSP will make any filtering 99 decisions in what it forwards to the UTM(s). 101 Finders can be smartphones, tablets, connected cars, or any computing 102 platform with Internet connectivity that can meet the requirements 103 defined in this document. It is not expected, nor necessary, that 104 Finders have any information about a UAS beyond the content in the 105 B-RID messages. 107 Finders MAY only need a loose association with the SDSP(s). They may 108 only have the SDSP's Public Key and FQDN. It would use these, along 109 with the Finder's Public Key to use ECIES, or other security methods, 110 to send the messages in a secure manner to the SDSP. The SDSP MAY 111 require a stronger relationship to the Finders. This may range from 112 the Finder's Public Key being registered to the SDSP with other 113 information so that the SDSP has some level of trust in the Finders 114 to requiring transmissions be sent over long-lived transport 115 connections like ESP or DTLS. 117 This document has minimal information about the actions of SDSPs. In 118 general the SDSP is out of scope of this document. That said, the 119 SDSPs should not simply proxy B-RID messages to the UTM(s). They 120 should perform some minimal level of filtering and content checking 121 before forwarding those messages that pass these tests in a secure 122 manner to the UTM(s). 124 The SDSPs are also capable of maintaining a monitoring map, based on 125 location of active Finders. UTMs may use this information to notify 126 authorized observers of where this is and there is not monitoring 127 coverage. They may also use there information of where to place pro- 128 active monitoring coverage. 130 An SDSP SHOULD only forward Authenticated B-RID messages like those 131 defined in [tmrid-auth] to the UTM(s). Further, the SDSP SHOULD 132 validate the Remote ID (RID) and the Authentication signature before 133 forwarding anything from the UA. 135 When 3 or more Finders are reporting to an SDSP on a specific UA, the 136 SDSP is in a unique position to perform multilateration on these 137 messages and compute the Finder's view of the UA location to compare 138 with the UA Location/Vector messages. This check against the UA's 139 location claims is both a validation on the UA's reliability as well 140 as the trustworthiness of the Finders. Other than providing data to 141 allow for multilateration, this SDSP feature is out of scope of this 142 document. 144 1.1. Draft Status 146 This draft is still incomplete. New features are being added as 147 capabilities are researched. The actual message formats also still 148 need work. 150 2. Terms and Definitions 152 2.1. Requirements Terminology 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 156 "OPTIONAL" in this document are to be interpreted as described in BCP 157 14 [RFC2119] [RFC8174] when, and only when, they appear in all 158 capitals, as shown here. 160 2.2. Definitions 162 B-RID 163 Broadcast Remote ID. A method of sending RID messages as 1-way 164 transmissions from the UA to any Observers within radio range. 166 CAA 167 Civil Aeronautics Administration. An example is the Federal 168 Aviation Administration (FAA) in the United States of America. 170 DAA 171 Detect and Avoid. The process of a UA detecting obstacles, like 172 other UAs and taking the necessary evasive action. 174 ECIES 175 Elliptic Curve Integrated Encryption Scheme. A hybrid encryption 176 scheme which provides semantic security against an adversary who 177 is allowed to use chosen-plaintext and chosen-ciphertext attacks. 179 GCS 180 Ground Control Station. The part of the UAS that the remote pilot 181 uses to exercise C2 over the UA, whether by remotely exercising UA 182 flight controls to fly the UA, by setting GPS waypoints, or 183 otherwise directing its flight. 185 Finder 186 In Internet connected device that can receive B-RID messages and 187 forward them to a UTM. 189 Observer 190 Referred to in other UAS documents as a "user", but there are also 191 other classes of RID users, so we prefer "observer" to denote an 192 individual who has observed an UA and wishes to know something 193 about it, starting with its RID. 195 Multilateration 196 Multilateration (more completely, pseudo range multilateration) is 197 a navigation and surveillance technique based on measurement of 198 the times of arrival (TOAs) of energy waves (radio, acoustic, 199 seismic, etc.) having a known propagation speed. 201 NETSP 202 Network RID Service Provider. USS receiving Network RID messages 203 from UAS (UA or GCS), storing for a short specified time, making 204 available to NETDP. 206 NETDP 207 Network RID Display Provider. Entity (might be USS) aggregating 208 data from multiple NETSPs to answer query from observer (or other 209 party) desiring Situational Awareness of UAS operating in a 210 specific airspace volume. 212 N-RID 213 Network Remote ID. A method of sending RID messages via the 214 Internet connection of the UAS directly to the UTM. 216 RID 217 Remote ID. A unique identifier found on all UA to be used in 218 communication and in regulation of UA operation. 220 SDSP 221 Supplemental Data Service Provider. Entity providing information 222 that is allowed, but not required to be present in the UTM system. 224 UA 225 Unmanned Aircraft. In this document UA's are typically though of 226 as drones of commerical or military variety. This is a very 227 strict definition which can be relaxed to include any and all 228 aircraft that are unmanned. 230 UAS 231 Unmanned Aircraft System. Composed of Unmanned Aircraft and all 232 required on-board subsystems, payload, control station, other 233 required off-board subsystems, any required launch and recovery 234 equipment, all required crew members, and C2 links between UA and 235 the control station. 237 UTM 238 UAS Traffic Management. A "traffic management" ecosystem for 239 uncontrolled operations that is separate from, but complementary 240 to, the FAA's Air Traffic Management (ATM) system. 242 USS 243 UAS Service Supplier. Provide UTM services to support the UAS 244 community, to connect Operators and other entities to enable 245 information flow across the USS network, and to promote shared 246 situational awareness among UTM participants. (From FAA UTM 247 ConOps V1, May 2018). 249 3. Problem Space 251 3.1. Meeting the needs of Network ID 253 The Federal (US) Aviation Authority (FAA), in the December 31, 2019 254 Remote ID Notice of Proposed Rulemaking [FAA-NPRM], is requiring 255 "Standard" and "Limited" Remote ID. Standard is when the UAS 256 provides both Network and Broadcast RID. Limited is when the UAS 257 provides only Network RID. The FAA has dropped their previous 258 position on allowing for only Broadcast RID. We can guess as to 259 their reasons; they are not spelled out in the NPRM. It may be that 260 just B-RID does not meet the FAA's statutory UA tracking 261 responsibility. 263 The UAS vendors have commented that N-RID places considerable demands 264 on currently used UAS. For some UAS like RC planes, meaningful N-RID 265 (via the Pilot's smartphone) are of limited value. A mechanism that 266 can augment B-RID to provide N-RID would help all members of the UAS 267 environment to provide safe operation and allow for new applications. 269 3.2. Advantages of Broadcast Remote ID 271 B-RID has its advantages over N-RID. 273 * B-RID can more readily be implemented directly in the UA. N-RID 274 will more frequently be provided by the GCS or a pilot's Internet 275 connected device. 277 - If Command and Control (C2) is bi-directional over a direct 278 radio connection, B-RID could be a straight-forward addition. 280 - Small IoT devices can be mounted on UA to provide B-RID. 282 * B-RID can also be used by the UA to assist in Detect and Avoid 283 (DAA). 285 * B-RID is available to observers even in situations with no 286 Internet like natural disaster situations. 288 3.3. Trustworthiness of Proxied Data 290 When a proxy is introduced in any communication protocol, there is a 291 risk of corrupted data and DOS attacks. 293 The Finders, in their role as proxies for B-RID, are authenticated to 294 the SDSP (see Section 4). The SDSP can compare the information from 295 multiple Finders to isolate a Finder sending fraudulent information. 296 SDSPs can additionally verify authenticated messages that follow 297 [tmrid-auth]. 299 The SPDP can manage the number of Finders in an area (see 300 Section 4.2) to limit DOS attacks from a group of clustered Finders. 302 3.4. Defense against fraudulent RID Messages 304 The strongest defense against fraudulent RID messages is to focus on 305 [tmrid-auth] conforming messages. Unless this behaviour is mandated, 306 SPDPs will have to use assorted algorithms to isolate messages of 307 questionable content. 309 4. The Finder - SDSP Security Relationship 311 The SDSP(s) and Finders SHOULD use EDDSA [RFC8032] keys as their 312 trusted Identities. The public keys SHOULD be registered 313 Hierarchical HITS, [hierarchical-hit] and [hhit-registries]. 315 The SDSP uses some process (out of scope here) to register the 316 Finders and their EDDSA Public Key. During this registration, the 317 Finder gets the SDSP's EDDSA Public Key. These Public Keys allow for 318 the following options for authenticated messaging from the Finder to 319 the SDSP. 321 1. ECIES can be used with a unique nonce to authenticate each 322 message sent from a Finder to the SDSP. 324 2. ECIES can be used at the start of some period (e.g. day) to 325 establish a shared secret that is then used to authenticate each 326 message sent from a Finder to the SDSP sent during that period. 328 3. HIPv2 [RFC7401] can be used to establish a session secret that is 329 then used with ESP [RFC4303] to authenticate each message sent 330 from a Finder to the SDSP. 332 4. DTLS [RFC5238] can be used to establish a secure connection that 333 is then used to authenticate each message sent from a Finder to 334 the SDSP. 336 4.1. The Finder Map 338 The Finders are regularly providing their SDSP with their location. 339 This is through the B-RID Proxy Messages and Finder Location Update 340 Messages. With this information, the SDSP can maintain a monitoring 341 map. That is a map of where there Finder coverage. 343 4.2. Managing Finders 345 Finder density will vary over time and space. For example, sidewalks 346 outside an urban train station can be packed with pedestrians at rush 347 hour, either coming or going to their commute trains. An SDSP may 348 want to proactively limit the number of active Finders in such 349 situations. 351 Using the Finder mapping feature, the SDSP can instruct Finders to 352 NOT proxy B-RID messages. These Finders will continue to report 353 their location and through that reporting, the SDSP can instruct them 354 to again take on the proxying role. For example a Finder moving 355 slowly along with dozens of other slow-moving Finders may be 356 instructed to suspend proxying. Whereas a fast-moving Finder at the 357 same location (perhaps a connected car or a pedestrian on a bus) 358 would not be asked to suspend proxying as it will soon be out of the 359 congested area. 361 5. The CS-RID Messages 363 The CS-RID messages between the Finders and the SDSPs primarily 364 support the proxy role of the Finders in forwarding the B-RID 365 messages. There are also Finder registration and status messages. 367 CS-RID information is represented in CBOR [RFC7049]. COSE [RFC8152] 368 may be used for CS-RID MAC and COAP [RFC7252] for the CS-RID 369 protocol. 371 The following is a general representation of the content in the CS- 372 RID messages. 374 ( CS-RID MESSAGE TYPE, 375 CS-RID MESSAGE CONTENT, 376 CS-RID MAC) 378 The CS-RID MESSAGE CONTENT varies by MESSAGE TYPE. 380 5.1. CS-RID MESSAGE TYPE 382 The CS-RID MESSAGE TYPE is: 384 Number CS-RID Message Type 385 ------ ----------------- 386 0 Reserved 387 1 B-RID Forwarding 388 2 Finder Registration 389 3 SDSP Response 390 4 Finder Location 392 5.2. The CS-RID B-RID Proxy Message 394 The Finders add their own information to the B-RID messages, 395 permitting the SDSP(s) to gain additional knowledge about the UA(s). 396 The RID information is the B-RID message content plus the MAC 397 address. The MAC address is critical, as it is the only field that 398 links a UA's B-RID messages together. Only the ASTM Basic ID Message 399 and possibly the Authentication Message contain the UAS ID field. 401 The Finders add an SDSP assigned ID, a 64 bit timestamp, GPS 402 information, and type of B-RID media to the B-RID message. Both the 403 timestamp and GPS information are for when the B-RID message(s) were 404 received, not forwarded to the SDSP. All this content is MACed using 405 a key shared between the Finder and SDSP. 407 The following is a representation of the content in the CS-RID 408 messages. 410 ( CS-RID MESSAGE TYPE, 411 CS-RID ID, 412 RECEIVE TIMESTAMP, 413 RECEIVE GPS, 414 RECEIVE RADIO TYPE, 415 B-RID MAC ADDRESS, 416 B-RID MESSAGE, 417 CS-RID MAC) 419 5.2.1. CS-RID ID 421 The CS-RID ID is the ID recognized by the SDSP. This may be an HHIT 422 Hierarchical HITs [hierarchical-hit], or any ID used by the SDSP. 424 5.3. CS-RID Finder Registration 426 The CS-RID Finder MAY use HIPv2 [RFC7401] with the SDSP to establish 427 a Security Association and a shared secret to use for the CS-RID MAC 428 generation. In this approach, the HIPv2 mobility functionality and 429 ESP [RFC4303] support are not used. 431 When HIPv2 is used as above, the Finder Registration is a SDSP "wake 432 up". It is sent prior to the Finder sending any proxied B-RID 433 messages to ensure that the SDSP is able to receive and process the 434 messages. 436 In this usage, the CS-RID is the Finder HIT. If the SDSP has lost 437 state with the Finder, it initiates the HIP exchange with the Finder 438 to reestablish HIP state and a new shared secret for the CS-RID B-RID 439 Proxy Messages. In this case the Finder Registration Message is: 441 ( CS-RID MESSAGE TYPE, 442 CS-RID ID, 443 CS-RID TIMESTAMP, 444 CS-RID GPS, 445 CS-RID MAC) 447 5.4. CS-RID SDSP Response 449 The SDSP MAY respond to any Finder messages to instruct the Finder on 450 its behavior. 452 ( CS-RID MESSAGE TYPE, 453 SDSP ID, 454 CS-RID ID, 455 CS-RID PROXY STATUS, 456 CS-RID UPDATE INTERVAL, 457 CS-RID MAC) 459 The Proxy Status instructs the Finder if it should actively proxy 460 B-RID messages, or suspend proxying and only report its location. 462 The Update Interval is the frequency that the Finder SHOULD notify 463 the SDSP of its current location using the Location Update message. 465 5.5. CS-RID Location Update 467 The Finder SHOULD provide regular location updates to the SDSP. The 468 interval is based on the Update Interval from Section 5.4 plus a 469 random slew less than 1 second. The Location Update message is only 470 sent when no other CS-RID messages, containing the Finder's GPS 471 location, have been sent since the Update Interval. 473 If the Finder has not recieved a SDSP Registration Response, a 474 default of 5 minutes is used for the Update Interval. 476 ( CS-RID MESSAGE TYPE, 477 CS-RID ID, 478 CS-RID TIMESTAMP, 479 CS-RID GPS, 480 CS-RID MAC) 482 6. IANA Considerations 484 TBD 486 7. Security Considerations 488 TBD 490 7.1. Privacy Concerns 492 TBD 494 8. Acknowledgments 496 The Crowd Sourcing idea in this document came from the Apple "Find My 497 Device" presentation at the International Association for 498 Cryptographic Research's Real World Crypto 2020 conference. 500 9. Normative References 502 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 503 Requirement Levels", BCP 14, RFC 2119, 504 DOI 10.17487/RFC2119, March 1997, 505 . 507 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 508 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 509 May 2017, . 511 10. Informative References 513 [F3411-19] ASTM International, "Standard Specification for Remote ID 514 and Tracking", February 2020, 515 . 517 [FAA-NPRM] Federal (US) Aviation Authority, "FAA Remote ID Notice of 518 Proposed Rule Making", December 2019, 519 . 521 [hhit-registries] 522 Moskowitz, R., Card, S., and A. Wiethuechter, 523 "Hierarchical HIT Registries", Work in Progress, Internet- 524 Draft, draft-moskowitz-hip-hhit-registries-02, 9 March 525 2020, . 528 [hierarchical-hit] 529 Moskowitz, R., Card, S., and A. Wiethuechter, 530 "Hierarchical HITs for HIPv2", Work in Progress, Internet- 531 Draft, draft-moskowitz-hip-hierarchical-hit-04, 3 March 532 2020, . 535 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 536 RFC 4303, DOI 10.17487/RFC4303, December 2005, 537 . 539 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 540 the Datagram Congestion Control Protocol (DCCP)", 541 RFC 5238, DOI 10.17487/RFC5238, May 2008, 542 . 544 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 545 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 546 October 2013, . 548 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 549 Application Protocol (CoAP)", RFC 7252, 550 DOI 10.17487/RFC7252, June 2014, 551 . 553 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 554 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 555 RFC 7401, DOI 10.17487/RFC7401, April 2015, 556 . 558 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 559 Signature Algorithm (EdDSA)", RFC 8032, 560 DOI 10.17487/RFC8032, January 2017, 561 . 563 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 564 RFC 8152, DOI 10.17487/RFC8152, July 2017, 565 . 567 [tmrid-auth] 568 Wiethuechter, A., Card, S., and R. Moskowitz, "TM-RID 569 Authentication Formats", Work in Progress, Internet-Draft, 570 draft-wiethuechter-tmrid-auth-05, 18 February 2020, 571 . 574 Appendix A. Using LIDAR for UA location 576 If the Finder has LIDAR or similar detection equipment (e.g. on a 577 connected car) that has full sky coverage, the Finder can use this 578 equipment to locate UAs in its airspace. The Finder would then be 579 able to detect non-participating UAs. A non-participating UA is one 580 that the Finder can "see" with the LIDAR, but not "hear" any B-RID 581 messages. 583 These Finders would then take the LIDAR data, construct appropriate 584 B-RID messages, and forward them to the SPDP as any real B-RID 585 messages. There is an open issue as what to use for the actual 586 RemoteID and MAC address. 588 The SDSP would do the work of linking information on a non- 589 participating UA that it has received from multiple Finders with 590 LIDAR detection. In doing so, it would have to select a RemoteID to 591 use. 593 A seemingly non-participating UA may actually be a UA that is beyond 594 range for its B-RID but in the LIDAR range. 596 This would provide valuable information to SDSPs to forward to UTMs 597 on potential at-risk situations. 599 At this time, research on LIDAR and other detection technology is 600 needed. there are full-sky LIDAR for automotive use with ranges 601 varying from 20M to 250M. Would more than UA location information be 602 available? What information can be sent in a CS-RID message for such 603 "unmarked" UAs? 605 Authors' Addresses 607 Robert Moskowitz 608 HTT Consulting 609 Oak Park, MI 48237 610 United States of America 612 Email: rgm@labs.htt-consult.com 614 Stuart W. Card 615 AX Enterprize 616 4947 Commercial Drive 617 Yorkville, NY 13495 618 United States of America 620 Email: stu.card@axenterprize.com 622 Adam Wiethuechter 623 AX Enterprize 624 4947 Commercial Drive 625 Yorkville, NY 13495 626 United States of America 628 Email: adam.wiethuechter@axenterprize.com