DRIP R. Moskowitz Internet-Draft HTT Consulting Intended status: Standards Track A. Wiethuechter Expires: 11 January 2024 AX Enterprize 10 July 2023 Crowd Sourced Remote ID draft-wiethuechter-drip-csrid-00 Abstract This document describes a way for an Internet connected device to forward/proxy received Broadcast Remote ID to Network Remote ID using UAS Traffic Management (UTM) Supplemental Data Service Providers (SDSPs). This enables more comprehensive situational awareness and reporting of Unmanned Aircraft (UA) in a “crowd sourced” manner. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 11 January 2024. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Moskowitz & Wiethuechter Expires 11 January 2024 [Page 1] Internet-Draft CS-RID July 2023 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Role of Supplemental Data Service Provider (SDSP) . . . . 3 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 4 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Advantages of Broadcast Remote ID . . . . . . . . . . . . 5 3.2. Meeting the needs of Network Remote ID . . . . . . . . . 5 3.3. Trustworthiness of Proxy Data . . . . . . . . . . . . . . 5 3.4. Defense against fraudulent RID Messages . . . . . . . . . 6 4. SDSP Security Relationship . . . . . . . . . . . . . . . . . 6 4.1. Finder Map . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Managing Finders . . . . . . . . . . . . . . . . . . . . 7 5. Crowd Sourced RID Protocol . . . . . . . . . . . . . . . . . 7 5.1. Detection & Report Structure . . . . . . . . . . . . . . 7 5.2. Unidirectional . . . . . . . . . . . . . . . . . . . . . 8 5.2.1. HTTPS . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. Bidirectional . . . . . . . . . . . . . . . . . . . . . . 8 5.3.1. Messages . . . . . . . . . . . . . . . . . . . . . . 9 5.3.2. HIP . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.3.3. DTLS . . . . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7.1. Privacy Concerns . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. GPS Inaccuracy . . . . . . . . . . . . . . . . . . . 12 Appendix B. Using LIDAR for UA location . . . . . . . . . . . . 13 Appendix C. UA location via multilateration . . . . . . . . . . 13 Appendix D. CS-RID Report Examples . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction Note: This document is directly related and builds from [moskowitz-csrid]. That draft is a "top, down" approach to understand the concept and high level design. This document is a "bottom, up" implementation of the CS-RID concept. The content of this draft is subject to change and adapt as further development continues. Moskowitz & Wiethuechter Expires 11 January 2024 [Page 2] Internet-Draft CS-RID July 2023 This document defines a mechanism to capture Broadcast Remote ID (RID) [F3411] messages 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 data can be aggregated and further decimated to other entities in Unmanned Aircraft Systems (UAS) Traffic Management (UTM) using Network RID [F3411]. These Internet connected devices are herein called “Finders”, as they find UAs by listening for Broadcast RID. The Finders are Broadcast 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 UTM. Finders can be smartphones, tablets, connected cars, CS-RID special purpose devices 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 found in Broadcast RID. Finders MAY only need a loose association with SDSPs. The SDSP MAY require a stronger relationship to the Finders. The relationship MAY be completely open, but still authenticated to requiring encryption. The transport MAY be client-server based (using things like HIP or DTLS) to client push (using things like UDP or HTTPS). 1.1. Role of Supplemental Data Service Provider (SDSP) The DRIP Architecture [drip-arch] introduces the basic CS-RID entities including CS-RID Finder and 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 cast RID messages to their 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 messages like those defined in [drip-auth] to the UTM(s). Further, the SDSP SHOULD validate the RID and the Authentication signature before forwarding anything from Moskowitz & Wiethuechter Expires 11 January 2024 [Page 3] Internet-Draft CS-RID July 2023 the UA, and flagging those RIDs that were not validated. The SDSP MAY forward all Broadcast RID messages to the UTM, leaving all decision making on Broadcast messages veracity to the receiving UTM entity. 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. 2. Terms and Definitions 2.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses terms defined in [RFC9153] and [drip-arch]. 2.2. Definitions 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 Broadcast RID messages and forward them to a SDSP. 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. 3. Problem Space Broadcast and Network RID formats are both defined in [F3411] using the same data dictionary. Network RID is specified in JSON sent over HTTPS while Broadcast RID is byte structures sent over wireless links. Moskowitz & Wiethuechter Expires 11 January 2024 [Page 4] Internet-Draft CS-RID July 2023 3.1. Advantages of Broadcast Remote ID Advantages over Network RID include: * more readily be implemented directly in the UA. Network 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, Broadcast RID could be a straight-forward addition. - Small IoT devices can be mounted on UA to provide Broadcast RID. * also be used by the UA to assist in Detect and Avoid (DAA). * is available to observers even in situations with no Internet like natural disaster situations. 3.2. Meeting the needs of Network Remote ID The USA Federal Aviation Authority (FAA), in the January 2021 Remote ID Final rule [FAA-FR], postponed Network Remote ID and focused on Broadcast Remote ID. This was in response to the UAS vendors comments that Network RID places considerable demands on then currently used UAS. However, Network RID, or equivalent, is necessary for UTM knowing what soon may be in an airspace and is mandated as required in the EU. A method that proxies Broadcast RID into UTM can function as an interim approach to Network RID and continue adjacent to Network RID. 3.3. Trustworthiness of Proxy 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 Broadcast RID, SHOULD be authenticated to the SDSP (see Section 4). The SDSP can compare the information from multiple Finders to isolate a Finder sending fraudulent information. SDSPs can additionally verify authenticated messages that follow [drip-auth]. The SPDP can manage the number of Finders in an area (see Section 4.2) to limit DOS attacks from a group of clustered Finders. Moskowitz & Wiethuechter Expires 11 January 2024 [Page 5] Internet-Draft CS-RID July 2023 3.4. Defense against fraudulent RID Messages The strongest defense against fraudulent RID messages is to focus on [drip-auth] conforming messages. Unless this behavior is mandated, an SDSP will have to use assorted algorithms to isolate messages of questionable content. 4. SDSP Security Relationship SDSPs and Finders SHOULD use EdDSA [RFC8032] keys as their trusted Identities. The public keys SHOULD be registered DRIP UAS Remote ID (DETs) [RFC9374] and [drip-reg]. 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. 1. EdDSA keys are converted to X25519 keys per Curve25519 [RFC7748] to use in ECIES. 2. ECIES can be used with a unique nonce to authenticate each message sent from a Finder to the SDSP. 3. 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. 4. HIP [RFC7401] can be used to establish a session secret that is then used with ESP [RFC4303] to authenticate each message sent from a Finder to the SDSP. 5. DTLS [RFC5238] can be used to establish a secure connection that is then used to authenticate each message sent from a Finder to the SDSP. 4.1. Finder Map The Finders are regularly providing their SDSP with their location. This is through the Broadcast 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. Moskowitz & Wiethuechter Expires 11 January 2024 [Page 6] Internet-Draft CS-RID July 2023 4.2. 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 Broadcast 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. 5. Crowd Sourced RID Protocol The CS-RID model is for Finders to send “batch reports” (Section 5.1) to one or more SDSPs they have a relationship with. This relationship can be highly anonymous with little prior knowledge of the Finder (({unidirectional})) to very well defined and pre- established (Section 5.3). 5.1. Detection & Report Structure Figure 2 is the report object, defined in CDDL, that is translated and adapted depending on the specific transport. It carries a batch of detections (up to a max of 10), the CDDL definition of which is shown in Figure 1. csrid_detection = ( timestamp: uint, ; UTC timestamp ? latitude: uint, ; scaled by 10^7 ? longitude: uint, ; scaled by 10^7 ? altitude: float, ; wgs84 meters rid_mac: hexdig .size 12, rid_message: hexdig .size(26..255) ) Figure 1: Detection CDDL Moskowitz & Wiethuechter Expires 11 January 2024 [Page 7] Internet-Draft CS-RID July 2023 csrid_report = { finder_id: hexdig .size 32 / tstr, finder_mac: hexdig .size 12, detection_count: int .size(1..10), detections: [+ csrid_detection], signature: tstr } Figure 2: Report CDDL Examples of various translations can be found in Appendix D. 5.2. Unidirectional Author Note: Section Title is WIP, suggestions welcome The unidirectional variant can allow for anonymous (non-strongly- authenticated) Finders to make reports to a publicly known SDSP endpoint. This is attractive for implementation to be lightweight, easy to deploy and use, such as over an open HTTPS API. Many clients (who run Finders in their software) may not be worried of being tracked for sending such reports. It is recommended to use bare EdDSA25519 keypairs during the interactions as keys are expected to change frequently and DETs would allow for long term tracking of Finders. 5.2.1. HTTPS Use Section 5.1 as CBOR/JSON. 5.2.2. UDP Use Section 5.1 as CBOR. 5.3. Bidirectional Author Note: Section Title is WIP, suggestions welcome The bidirectional variant imposes a strong authentication and Finder onboarding process. It is attractive for well defined deployments of CS-RID, such as being used for area security. Implementations are RECOMMENDED to use HIP [RFC7401] or DTLS with a DET [RFC9374] as their primary identity. A CS-RID SDSP SHOULD allow for any valid registered DET to report to it. Moskowitz & Wiethuechter Expires 11 January 2024 [Page 8] Internet-Draft CS-RID July 2023 Send Section 5.1 as CBOR. Bidirectionally also gives an added benefit of sending various commands to Finders to alter their behavior with the relationship. Unlike Section 5.2 where there is no control of the Finder behavior. 5.3.1. Messages Defined all in CDDL. Adapted accordingly to given transport. 5.3.1.1. Batch Report Same as Section 5.1 but removes the lat/lon/alt from detections as stored and updated separately. 5.3.1.2. Location Update Provides the lat/lon/alt of the Finder. 5.3.1.3. Parameter Update Enables SDSP to negotiate changes to Finder parameters such as detection_count maximum. 5.3.1.4. Filter Conditions Enabled SDSP to give “smarter” Finders filtering conditions of detections to be sent back to the SDSP. 5.3.2. HIP TODO 5.3.3. DTLS TODO 6. IANA Considerations TBD 7. Security Considerations TBD Moskowitz & Wiethuechter Expires 11 January 2024 [Page 9] Internet-Draft CS-RID July 2023 7.1. Privacy Concerns TBD 8. 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. 9. References 9.1. Normative References [moskowitz-csrid] Moskowitz, R., Card, S. W., Wiethuechter, A., Zhao, S., and H. Birkholz, "Crowd Sourced Remote ID", Work in Progress, Internet-Draft, draft-moskowitz-drip-crowd- sourced-rid-10, 8 May 2023, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . [RFC9153] Card, S., Ed., Wiethuechter, A., Moskowitz, R., and A. Gurtov, "Drone Remote Identification Protocol (DRIP) Requirements and Terminology", RFC 9153, DOI 10.17487/RFC9153, February 2022, . 9.2. Informative References Moskowitz & Wiethuechter Expires 11 January 2024 [Page 10] Internet-Draft CS-RID July 2023 [drip-arch] Card, S. W., Wiethuechter, A., Moskowitz, R., Zhao, S., and A. Gurtov, "Drone Remote Identification Protocol (DRIP) Architecture", Work in Progress, Internet-Draft, draft-ietf-drip-arch-31, 6 March 2023, . [drip-auth] Wiethuechter, A., Card, S. W., and R. Moskowitz, "DRIP Entity Tag Authentication Formats & Protocols for Broadcast Remote ID", Work in Progress, Internet-Draft, draft-ietf-drip-auth-30, 27 March 2023, . [drip-reg] Wiethuechter, A. and J. Reid, "DRIP Entity Tag (DET) Identity Management Architecture", Work in Progress, Internet-Draft, draft-ietf-drip-registries-12, 10 July 2023, . [F3411] ASTM International, "Standard Specification for Remote ID and Tracking", July 2022, . [FAA-FR] United States Federal Aviation Administration (FAA), "FAA Remote Identification of Unmanned Aircraft", January 2021, . [gps-ionosphere] Unknown, "Ionospheric response to the 2015 St. Patrick's Day storm A global multi-instrumental overview", September 2015, . [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, . [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)", RFC 5238, DOI 10.17487/RFC5238, May 2008, . [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, . Moskowitz & Wiethuechter Expires 11 January 2024 [Page 11] Internet-Draft CS-RID July 2023 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, DOI 10.17487/RFC7401, April 2015, . [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [RFC9374] Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov, "DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID)", RFC 9374, DOI 10.17487/RFC9374, March 2023, . Appendix A. 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 position 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 [gps-ionosphere]) 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 particularly 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. Moskowitz & Wiethuechter Expires 11 January 2024 [Page 12] Internet-Draft CS-RID July 2023 Appendix B. 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 Broadcast RID messages. These Finders would then take the LIDAR data, construct appropriate Broadcast RID messages, and forward them to the SDSP as any real Broadcast 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 Broadcast 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? Appendix C. 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 Broadcast 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. Appendix D. CS-RID Report Examples Moskowitz & Wiethuechter Expires 11 January 2024 [Page 13] Internet-Draft CS-RID July 2023 { finder_id: "20010030000000050000000000000000", finder_mac: "001122334455", detection_count: 1, detections: [ { timestamp: 0.0, latitude: 0.0, longitude: 0.0, altitude: 0.0, rid_mac: "667788990011", rid_message: "0002000000000000000000000000000000000000000000000000" } ], signature: "base64" } Figure 3: Example JSON Report Authors' Addresses Robert Moskowitz HTT Consulting Oak Park, MI 48237 United States of America Email: rgm@labs.htt-consult.com Adam Wiethuechter AX Enterprize 4947 Commercial Drive Yorkville, NY 13495 United States of America Email: adam.wiethuechter@axenterprize.com Moskowitz & Wiethuechter Expires 11 January 2024 [Page 14]