| Internet-Draft | CS-RID | March 2020 |
| Moskowitz, et al. | Expires 13 September 2020 | [Page] |
This document describes using the ASTM Broadcast Remote ID (B-RID) specification in a "crowd sourced" smart phone environment to provide much of the FAA mandated Network Remote ID (N-RID) functionality. This crowd sourced B-RID data will use multi-lateration 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.¶
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 13 September 2020.¶
Copyright (c) 2020 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
This document defines a mechanism to capture the ASTM Broadcast Remote ID messages (B-RID) [F3411-19] on any Internet connected device that receives them and can forward them to the SPDP(s) 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 requriments that CAAs are placing on Network Remote ID (N-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 SPDP and which to drop. The SPDP will make any filtering decisions in what it forwards to the UTM(s).¶
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 SPDP(s). They may only have the SPDP's Public Key and FQDN. It would use these, along with the Finder's Public Key to use ECIES, or other security methods, to send the messages in a secure manner to the SPDP. The SPDP MAY require a stronger relationship to the Finders. This may range from the Finder's Public Key being registered to the SPDP with other information so that the SPDP has some level of trust in the Finders to requiring transmissions be sent over long-lived transport connections like ESP or DTLS.¶
This document has minimal information about the actions of SPDPs. In general the SPDP is out of scope of this document. That said, the SPDPs 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 SPDPs 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 this is and there is not monitoring coverage. They may also use there information of where to place pro-active monitoring coverage.¶
An SPDP SHOULD only forward Authenticated B-RID messages like those defined in [tmrid-auth] to the UTM(s). Further, the SPDP SHOULD validate the Remote ID (RID) and the Authentication signature before forwarding anything from the UA.¶
When 3 or more Finders are reporting to an SPDP on a specific UA, the SPDP 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 SPDP feature is out of scope of this document.¶
This draft is still incomplete. New features are being added as capabilities are researched. The actual message formats also still need work.¶
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.¶
The Federal (US) Aviation Authority (FAA), in the December 31, 2019 Remote ID Notice of Proposed Rulemaking [FAA-NPRM], is requiring "Standard" and "Limited" Remote ID. Standard is when the UAS provides both Network and Broadcast RID. Limited is when the UAS provides only Network RID. The FAA has dropped their previous position on allowing for only Broadcast RID. We can guess as to their reasons; they are not spelled out in the NPRM. It may be that just B-RID does not meet the FAA's statutory UA tracking responsibility.¶
The UAS vendors have commented that N-RID places considerable demands on currently used UAS. For some UAS like RC planes, meaningful N-RID (via the Pilot's smartphone) are of limited value. A mechanism that can augment B-RID to provide N-RID would help all members of the UAS environment to provide safe operation and allow for new applications.¶
When a proxy is introduced in any communication protocol, there is a risk of corrupted data and DOS attacks.¶
TBD¶
TBD¶
The SPDP(s) and Finders SHOULD use EDDSA keys as their trusted Identities. The public keys SHOULD be registered Hierarchical HITS, [hierarchical-hit] and [hhit-registries].¶
The SPDP uses some process (out of scope here) to register the Finders and their EDDSA Public Key. During this registration, the Finder gets the SPDP's EDDSA Public Key. These Public Keys allow for the following options for authenticated messaging from the Finder to the SPDP.¶
The Finders are regularly providing their SPDP with their location. This is through the B-RID Proxy Messages and Finder Location Update Messages. With this information, the SPDP can maintain a monitoring map. That is a map of where there Finder coverage.¶
The CS-RID messages between the Finders and the SPDPs 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 [RFC7049]. COSE [RFC8152] may be used for CS-RID MAC and COAP [RFC7252] for the CS-RID protocol.¶
The following is a general representation of the content in the CS-RID messages.¶
( CS-RID MESSAGE TYPE,
CS-RID MESSAGE CONTENT,
CS-RID MAC)
¶
The CS-RID MESSAGE CONTENT varies by MESSAGE TYPE.¶
The CS-RID MESSAGE TYPE is:¶
Number CS-RID Message Type ------ ----------------- 0 Reserved 1 B-RID Forwarding 2 Finder Registration 3 SPDP Registration Response 4 Finder Location¶
The Finders add their own information to the B-RID messages, permitting the SPDP(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 SPDP 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 SPDP. All this content is MACed using a key shared between the Finder and SPDP.¶
The following is a representation of the content in the CS-RID messages.¶
( CS-RID MESSAGE TYPE,
CS-RID ID,
RECEIVE TIMESTAMP,
RECEIVE GPS,
RECEIVE RADIO TYPE,
B-RID MAC ADDRESS,
B-RID MESSAGE,
CS-RID MAC)
¶
The CS-RID ID is the ID recognized by the SPDP. This may be an HHIT Hierarchical HITs [hierarchical-hit], or any ID used by the SPDP.¶
The CS-RID Finder MAY use HIPv2 [RFC7401] with the SPDP to establish a Security Association and a shared secret to use for the CS-RID MAC generation. In this approach, the HIPv2 mobility functionality and ESP [RFC4303] support are not used.¶
When HIPv2 is used as above, the Finder Registration is a SPDP "wake up". It is sent prior to the Finder sending any proxied B-RID messages to ensure that the SPDP is able to receive and process the messages.¶
In this usage, the CS-RID is the Finder HIT. If the SPDP 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:¶
( CS-RID MESSAGE TYPE,
CS-RID ID,
CS-RID TIMESTAMP,
CS-RID GPS,
CS-RID MAC)
¶
The SPDP responds to the Finder Registration with a message that includes an update interval. This interval is the frequency that the Finder SHOULD notify the SPDP of its current location.¶
( CS-RID MESSAGE TYPE,
SPDP ID,
CS-RID ID,
CS-RID UPDATE INTERVAL,
CS-RID MAC)
¶
The Finder SHOULD provide regular location updates to the SPDP. The interval is based on the Update Interval from Section 5.4 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 SPDP Registration Response, a default of 5 minutes is used for the Update Interval.¶
( CS-RID MESSAGE TYPE,
CS-RID ID,
CS-RID TIMESTAMP,
CS-RID GPS,
CS-RID MAC)
¶
TBD¶
TBD¶
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.¶
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.¶
This would provide valuable information to SPDPs to forward to UTMs on potential at-risk situations.¶
At this time, research on LIDAR and other detection technology is needed. Would more than UA location information be available? What information can be sent in a CS-RID message for such "unmarked" UAs?¶