]> HTT Consulting

Oak Park MI 48237 USA rgm@labs.htt-consult.com

AX Enterprize

4947 Commercial Drive Yorkville NY 13495 USA stu.card@axenterprize.com

AX Enterprize

4947 Commercial Drive Yorkville NY 13495 USA adam.wiethuechter@axenterprize.com

Intel

2200 Mission College Blvd Santa Clara CA 95054 USA shuai.zhao@ieee.org

Fraunhofer SIT

Rheinstrasse 75 Darmstadt 64295 Germany henk.birkholz@sit.fraunhofer.de

Internet DRIP RFC This document describes using the ASTM Broadcast Remote ID (B-RID) specification in a "crowd sourced" smart phone or fixed receiver asset environment to provide much of the ASTM and FAA envisioned Network Remote ID (Net-RID) functionality. This crowd sourced B-RID (CS-RID) data will use multilateration to add a level of reliability in the location data on the Unmanned Aircraft (UA). The crowd sourced environment will also provide a monitoring coverage map to authorized observers.

Introduction This document defines a mechanism to capture the ASTM Broadcast Remote ID messages (B-RID) on any Internet connected device that receives them and can forward them to the Supplemental Data Service Providers (SDSPs) responsible for the geographic area the UA and receivers are in. This will create a ecosystem that will meet most if not all data collection requirements that Civil Aviation Authorities (CAA) are placing on Network Remote ID (Net-RID). These Internet connected devices are herein called "Finders", as they find UAs by listening for B-RID messages. The Finders are B-RID forwarding proxies. Their potentially limited spacial view of RID messages could result in bad decisions on what messages to send to the SDSP and which to drop. Thus they will send all received messages and the SDSP will make any filtering decisions in what it forwards into the UAS Traffic Management (UTM). Finders can be smartphones, tablets, connected cars, or any computing platform with Internet connectivity that can meet the requirements defined in this document. It is not expected, nor necessary, that Finders have any information about a UAS beyond the content in the B-RID messages. Finders MAY only need a loose association with the SDSP(s). They may only have the SDSP's Public Key and FQDN. It would use these, along with the Finder's Public Keypair to use Elliptic Curve Integrated Encryption Scheme (ECIES), or other security methods, to send the messages in a secure manner to the SDSP. The SDSP MAY require a stronger relationship to the Finders. This may range from the Finder's Public Key being registered to the SDSP with other information so that the SDSP has some level of trust in the Finders to requiring transmissions be sent over long-lived transport connections like ESP or DTLS. If a 1-way only secure packet forwarding method is used (e.g., not a TCP connection), the Finder SHOULD receive periodic "heartbeats" from the SDSP to inform it that its transmissions are being received. The SDSP sets the rules on when to send these heartbeats as discuss below in .

Role of Supplemental Data Service Provider (SDSP) The DRIP Architecture introduces the basic CS-RID entities including CS-RID Finder and CS-RID SDSP. This document has minimal information about the actions of SDSPs. In general the SDSP is out of scope of this document. That said, the SDSPs should not simply proxy B-RID messages to the UTM(s). They should perform some minimal level of filtering and content checking before forwarding those messages that pass these tests in a secure manner to the UTM(s). The SDSPs are also capable of maintaining a monitoring map, based on location of active Finders. UTMs may use this information to notify authorized observers of where there is and there is not monitoring coverage. They may also use this information of where to place pro-active monitoring coverage. An SDSP should only forward Authenticated B-RID messages like those defined in to the UTM(s). Further, the SDSP SHOULD validate the Remote ID (RID) and the Authentication signature before forwarding anything from the UA, and flagging those RIDs that were not validated. The SDSP MAY forward all B-RID messages to the UTM, leaving all decision making on B-RID messages veracity to the UTM. When 3 or more Finders are reporting to an SDSP on a specific UA, the SDSP is in a unique position to perform multilateration on these messages and compute the Finder's view of the UA location to compare with the UA Location/Vector messages. This check against the UA's location claims is both a validation on the UA's reliability as well as the trustworthiness of the Finders. Other than providing data to allow for multilateration, this SDSP feature is out of scope of this document. This function is limited by the location accuracy for both the Finders and UA.

Draft Status This draft is still incomplete. New features are being added as capabilities are researched. The actual message formats also still need work.

Terms and Definitions

Requirements Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document uses terms defined in and .

Definitions

B-RID:

Broadcast Remote ID. A method of sending RID messages as 1-way transmissions from the UA to any Observers within radio range.

ECIES:

Elliptic Curve Integrated Encryption Scheme. A hybrid encryption scheme which provides semantic security against an adversary who is allowed to use chosen-plaintext and chosen-ciphertext attacks.

Finder:

In Internet connected device that can receive B-RID messages and forward them to a UTM.

Multilateration:

Multilateration (more completely, pseudo range multilateration) is a navigation and surveillance technique based on measurement of the times of arrival (TOAs) of energy waves (radio, acoustic, seismic, etc.) having a known propagation speed.

Net-RID:

Network Remote ID. A method of sending RID messages via the Internet connection of the UAS directly to the UTM.

Problem Space

Meeting the needs of Network Remote ID The USA Federal Aviation Authority (FAA), in the January 2021 Remote ID Final rule , postponed Network Remote ID (Net-RID) and focused on Broadcast Remote ID. This was in response to the UAS vendors comments that Net-RID places considerable demands on then currently used UAS. However, Net-RID, or equivalent, is necessary for UTM and knowing what soon may be in an airspace. A method that proxies B-RID into UTM can function as an interim approach to Net-RID and continue as a adjunct to Net-RID.

Advantages of Broadcast Remote ID B-RID has its advantages over Net-RID. B-RID can more readily be implemented directly in the UA. Net-RID will more frequently be provided by the GCS or a pilot's Internet connected device. If Command and Control (C2) is bi-directional over a direct radio connection, B-RID could be a straight-forward addition. Small IoT devices can be mounted on UA to provide B-RID. B-RID can also be used by the UA to assist in Detect and Avoid (DAA). B-RID is available to observers even in situations with no Internet like natural disaster situations.

Trustworthiness of Proxied Data When a proxy is introduced in any communication protocol, there is a risk of corrupted data and DOS attacks. The Finders, in their role as proxies for B-RID, are authenticated to the SDSP (see ). The SDSP can compare the information from multiple Finders to isolate a Finder sending fraudulent information. SDSPs can additionally verify authenticated messages that follow . The SPDP can manage the number of Finders in an area (see ) to limit DOS attacks from a group of clustered Finders.

Defense against fraudulent RID Messages The strongest defense against fraudulent RID messages is to focus on conforming messages. Unless this behavior is mandated, SPDPs will have to use assorted algorithms to isolate messages of questionable content.

The Finder - SDSP Security Relationship The SDSP(s) and Finders SHOULD use EdDSA keys as their trusted Identities. The public keys SHOULD be registered DRIP UAS Remote ID and . Other similar methods may be used. During this registration, the Finder gets the SDSP's EdDSA Public Key. These Public Keys allow for the following options for authenticated messaging from the Finder to the SDSP. The SDSP uses some process (out of scope here) to register the Finders and their EdDSA Public Key. During this registration, the Finder gets the SDSP's EdDSA Public Key. These Public Keys allow for the following options for authenticated messaging from the Finder to the SDSP. EdDSA keys are converted to X25519 keys per Curve25519 to use in ECIES. ECIES can be used with a unique nonce to authenticate each message sent from a Finder to the SDSP. ECIES can be used at the start of some period (e.g. day) to establish a shared secret that is then used to authenticate each message sent from a Finder to the SDSP sent during that period. HIP can be used to establish a session secret that is then used with ESP to authenticate each message sent from a Finder to the SDSP. DTLS can be used to establish a secure connection that is then used to authenticate each message sent from a Finder to the SDSP.

SDSP Heartbeats If a 1-way messaging approach is used (e.g. not TCP-based), the SDSP SHOULD send a heartbeat at some periodicity to the Finders so that they get confirmation that there is a receiver of their transmissions. A simple (see ) message that identifies the SDSP is sent to the Finder per some published policy of the SDSP. For example, at the first reception by the SDSP for the day, then the 1st for the hour. It is NOT recommended for the SDSP to send a heartbeat for every message received, as this is a potential DOS attack against the SDSP.

The Finder Map The Finders are regularly providing their SDSP with their location. This is through the B-RID Proxy Messages and Finder Location Update Messages. With this information, the SDSP can maintain a monitoring map. That is a map of where there Finder coverage.

Managing Finders Finder density will vary over time and space. For example, sidewalks outside an urban train station can be packed with pedestrians at rush hour, either coming or going to their commute trains. An SDSP may want to proactively limit the number of active Finders in such situations. Using the Finder mapping feature, the SDSP can instruct Finders to NOT proxy B-RID messages. These Finders will continue to report their location and through that reporting, the SDSP can instruct them to again take on the proxying role. For example a Finder moving slowly along with dozens of other slow-moving Finders may be instructed to suspend proxying. Whereas a fast-moving Finder at the same location (perhaps a connected car or a pedestrian on a bus) would not be asked to suspend proxying as it will soon be out of the congested area.

UA location via multilateration The SDSP can confirm/correct the UA location provided in the Location/Vector message by using multilateration on data provided by at least 3 Finders that reported a specific Location/Vector message (Note that 4 Finders are needed to get altitude sign correctly). In fact, the SDSP can calculate the UA location from 3 observations of any B-RID message. This is of particular value if the UA is only within reception range of the Finders for messages other than the Location/Vector message. This feature is of particular value when the Finders are fixed assets with highly reliable GPS location, around a high value site like an airport or large public venue.

GPS Inaccuracy Single-band, consumer grade, GPS on small platforms is not accurate, particularly for altitude. Longitude/latitude measurements can easily be off by 3M based on satellite postion and clock accuracy. Altitude accuracy is reported in product spec sheets and actual tests to be 3x less accurate. Altitude accuracy is hindered by ionosphere activity. In fact, there are studies of ionospheric events (e.g. 2015 St. Patrick's day ) as measured by GPS devices at known locations. Thus where a UA reports it is rarely accurate, but may be accurate enough to map to visual sightings of single UA. Smartphones and particulary smartwatches are plagued with the same challenge, though some of these can combine other information like cell tower data to improve location accuracy. FCC E911 accuracy, by FCC rules is NOT available to non-E911 applications due to privacy concerns, but general higher accuracy is found on some smart devices than reported for consumer UA. The SDSP MAY have information on the Finder location accuracy that it can use in calculating the accuracy of a multilaterated location value. When the Finders are fixed assets, the SDSP may have very high trust in their location for trusting the multilateration calculation over the UA reported location.

The CS-RID Messages The CS-RID messages between the Finders and the SDSPs primarily support the proxy role of the Finders in forwarding the B-RID messages. There are also Finder registration and status messages. CS-RID information is represented in CBOR . COSE MAY be used for CS-RID MAC and COAP for the CS-RID protocol. The CDDL specification is used for CS-RID message description. The following is a general representation of the content in the CS-RID messages.

The CS-RID MESSAGE CONTENT varies by MESSAGE TYPE.

CS-RID MESSAGE TYPE The CS-RID MESSAGE TYPE is defined in :

CDDL description for CS-RID message type The overall CS-RID CDDL description is structured in .

info_message, proxy_message => broadcast_rid_proxy_message, finder_registration => finder_registration_message, sdsp_response => sdsp_response_message, location_update => location_update_message, sdsp_heartbeat => sdsp_heartbeat_message, } info_message = { common_message_members, message_content => tstr, } common_message_members = ( message_type => message_types, mac_address => #6.37(bstr), ) message_types = &( Reserved : 0, BRD : 1, Finder-Registration : 2, SDSP-Response : 3, Finder-Location : 4, ) ]]>

The application context rule is defined in for CS-RID application identification and version negotiation.

"DRIP-CSRID", ? version => uint .size(1..2), ) ]]>

The predefined CDDL text string labels (author note: for JSON currently, will move to CBOR uint keys in upcoming versions) used in the specification is listed in .

The CS-RID B-RID Proxy Message The Finders add their own information to the B-RID messages, permitting the SDSP(s) to gain additional knowledge about the UA(s). The RID information is the B-RID message content plus the MAC address. The MAC address is critical, as it is the only field that links a UA's B-RID messages together. Only the ASTM Basic ID Message and possibly the Authentication Message contain the UAS ID field. The Finders add an SDSP assigned ID, a 64 bit timestamp, GPS information, and type of B-RID media to the B-RID message. Both the timestamp and GPS information are for when the B-RID message(s) were received, not forwarded to the SDSP. All this content is MACed using a key shared between the Finder and SDSP. The following is a representation of the content in the CS-RID messages.

CS-RID ID The CS-RID ID is the ID recognized by the SDSP. This may be an HHIT , or any ID used by the SDSP.

CDDL description for CS-RID B-RID Proxy Message The broadcast CS-RID proxy CDDL is defined in

tstr, timestamp => tdate, gps => gps-coordinates, radio_type => radio_types, broadcast_mac_address => #6.37(bstr), broadcast_message => #6.37(bstr), } radio_types = &( EFL : 0, VLF : 1, LF : 2, MF : 3, HF : 4, HF : 5, VHF : 6, UHF : 7, SHF : 8, EHF : 9, ) gps-coordinates = [ latitude : float, longitude: float, altitude : float, ] ]]>

CS-RID Finder Registration The CS-RID Finder MAY use with the SDSP to establish a Security Association and a shared secret to use for the CS-RID MAC generation. In this approach, the HIP mobility functionality and support are not used. When HIP is used as above, the Finder Registration is a SDSP "wake up". It is sent prior to the Finder sending any proxied B-RID messages to ensure that the SDSP is able to receive and process the messages. In this usage, the CS-RID ID is the Finder HIT. If the SDSP has lost state with the Finder, it initiates the HIP exchange with the Finder to reestablish HIP state and a new shared secret for the CS-RID B-RID Proxy Messages. In this case the Finder Registration Message is:

CDDL description for Finder Registration The CDDL for CS-RID Finder Registration is defined in

tstr, timestamp => tdate, gps => gps-coordinates, } gps-coordinates = [ latitude : float, longitude: float, altitude : float, ] ]]>

CS-RID SDSP Response The SDSP MAY respond to any Finder messages to instruct the Finder on its behavior.

The Proxy Status instructs the Finder if it should actively proxy B-RID messages, or suspend proxying and only report its location. The Update Interval is the frequency that the Finder SHOULD notify the SDSP of its current location using the Location Update message.

CDDL description for SDSP Response The CDDL for CS-RID SDSP response is defined in

tstr, rid => tstr, proxy_status_type => proxy_status_types, update_interval => uint, } gps-coordinates = [ latitude : float, longitude: float, altitude : float, ] proxy_status_types = &( 0: "forward", 1: "reverse", 2: "bi-directional", ) ]]>

CS-RID Location Update The Finder SHOULD provide regular location updates to the SDSP. The interval is based on the Update Interval from plus a random slew less than 1 second. The Location Update message is only sent when no other CS-RID messages, containing the Finder's GPS location, have been sent since the Update Interval. If the Finder has not recieved a SDSP Registration Response, a default of 5 minutes is used for the Update Interval.

CDDL description for Location Update The CDDL for CS-RID Location update is defined in .

tstr, timestamp => tdate, gps => gps-coordinates, } gps-coordinates = [ latitude : float, longitude: float, altitude : float, ] ]]>

SDSP Heartbeat The SDSP SHOULD send a heartbeat message at some periodicity to the Finders so that they get confirmation that their is a receiver of their transmissions.

CDDL description for SDSP Heartbeat The CDDL for CS-RID Heartbeat is defined in .

tstr, timestamp => tdate, } ]]>

The Full CS-RID CDDL specification

; CDDL specification for Crowd source RID ; It specifies a collection of CS message types ; ; ; The CSRID overall data structure CSRID_Object = { application-context, info => info_message, proxy_message => broadcast_rid_proxy_message, finder_registration => finder_registration_message, sdsp_response => sdsp_response_message, location_update => location_update_message, } ; ; Application context: general information about CSRID message application-context = ( application => "DRIP-CSRID", ; TBD: consider CBOR tag ? version => uint .size(1..2), ) ; These members are include in every message common_message_members = ( message_type => message_types, mac_address => #6.37(bstr), ) ; ; CSRID message general information info_message = { common_message_members, message_content => tstr, } broadcast_rid_proxy_message = { common_message_members, rid => tstr, timestamp => tdate, gps => gps-coordinates, radio_type => radio_types, broadcast_mac_address => #6.37(bstr) broadcast_message => #6.37(bstr) } finder_registration_message = { common_message_members, rid => tstr, timestamp => tdate, gps => gps-coordinates, } sdsp_response_message = { common_message_members, sdsp_id => tstr, rid => tstr, proxy_status_type => proxy_status_types, update_interval => uint, } location_update_message = { common_message_members, rid => tstr, timestamp => tdate, gps => gps-coordinates, } ; ; Common rule definition message_types = &( Reserved : 0, BRD : 1, Finder-Registration : 2, SDSP-Response : 3, Finder-Location : 4, ) gps-coordinates = [ lat: float, long: float, alt : float, ] ; Radio types, choose from one of radio_types (required) radio_types = &( EFL : 0, VLF : 1, LF : 2, MF : 3, HF : 4, HF : 5, VHF : 6, UHF : 7, SHF : 8, EHF : 9, ) proxy_status_types = &( 0: "forward", 1: "reverse", 2: "bi", ) ; ; JSON label names application = "application" version = "version" info = "message_info" proxy_message = "proxy_message-type" finder_registration = "finder_registration" sdsp_response = "sdsp_response" location_update = "location_update" rid = "id" message_type = "message_type" mac_address = "mac_address" message_content = "message_content" timestamp = "timestamp" gps = "gps" radio_type = "radio_type" broadcast_mac_address = "broadcast_mac_address" broadcast_message = "broadcast_message" sdsp_id = "sdsp_id" proxy_status_type = "proxy_status_type" update_interval = "update_interval" ]]>

IANA Considerations TBD

Security Considerations TBD

Privacy Concerns TBD

This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. This document defines terminology and requirements for solutions produced by the Drone Remote Identification Protocol (DRIP) Working Group. These solutions will support Unmanned Aircraft System Remote Identification and tracking (UAS RID) for security, safety, and other purposes (e.g., initiation of identity-based network sessions supporting UAS applications). DRIP will facilitate use of existing Internet resources to support RID and to enable enhanced related services, and it will enable online and offline verification that RID information is trustworthy. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. ASTM International United States Federal Aviation Administration (FAA) AX Enterprize, LLC AX Enterprize, LLC HTT Consulting This document describes how to add trust into the Broadcast Remote ID (RID) specification discussed in the DRIP Architecture; first trust in the RID ownership and second in the source of the RID messages. It defines message types and associated formats (sent within the Authentication Message) that can be used to authenticate past messages sent by an unmanned aircraft (UA) and provide proof of UA trustworthiness even in the absence of Internet connectivity at the receiving node. HTT Consulting AX Enterprize, LLC AX Enterprize, LLC Linköping University This document describes the use of Hierarchical Host Identity Tags (HHITs) as self-asserting IPv6 addresses and thereby a trustable identifier for use as the Unmanned Aircraft System Remote Identification and tracking (UAS RID). This document updates RFC7401 and RFC7343. Within the context of RID, HHITs will be called DRIP Entity Tags (DETs). HHITs provide claims to the included explicit hierarchy that provides registry (via, e.g., DNS, RDAP) discovery for 3rd-party identifier endorsement. AX Enterprize, LLC RTFM llp This document describes the high level architecture for the registration and discovery of DRIP Entity Tags (DETs) using DNS. Discovery of DETs and their artifacts are through the existing DNS structure and methods by using FQDNs. A general overview of the interfaces required between involved components is described in this document with supporting documents giving technical specifications. AX Enterprize AX Enterprize HTT Consulting Intel Linköping University This document describes an architecture for protocols and services to support Unmanned Aircraft System (UAS) Remote Identification (RID) and tracking, plus UAS RID-related communications. This architecture adheres to the requirements listed in the DRIP Requirements document (RFC9153). The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. This document specifies the use of Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP). DTLS provides communications privacy for applications that use datagram transport protocols and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. DCCP is a transport protocol that provides a congestion-controlled unreliable datagram service. [STANDARDS-TRACK] This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document obsoletes RFC 2406 (November 1998). [STANDARDS-TRACK] This document specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Diffie-Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the-middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulating Security Payload (ESP), it provides integrity protection and optional encryption for upper-layer protocols, such as TCP and UDP.This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.

Using LIDAR for UA location If the Finder has LIDAR or similar detection equipment (e.g. on a connected car) that has full sky coverage, the Finder can use this equipment to locate UAs in its airspace. The Finder would then be able to detect non-participating UAs. A non-participating UA is one that the Finder can "see" with the LIDAR, but not "hear" any B-RID messages. These Finders would then take the LIDAR data, construct appropriate B-RID messages, and forward them to the SPDP as any real B-RID messages. There is an open issue as what to use for the actual RemoteID and MAC address. The SDSP would do the work of linking information on a non-participating UA that it has received from multiple Finders with LIDAR detection. In doing so, it would have to select a RemoteID to use. A seemingly non-participating UA may actually be a UA that is beyond range for its B-RID but in the LIDAR range. This would provide valuable information to SDSPs to forward to UTMs on potential at-risk situations. At this time, research on LIDAR and other detection technology is needed. there are full-sky LIDAR for automotive use with ranges varying from 20M to 250M. Would more than UA location information be available? What information can be sent in a CS-RID message for such "unmarked" UAs?

Acknowledgments The Crowd Sourcing idea in this document came from the Apple "Find My Device" presentation at the International Association for Cryptographic Research's Real World Crypto 2020 conference.