DRIP R. Moskowitz
Internet-Draft HTT Consulting
Intended status: Standards Track S. Card
Expires: 2 November 2022 A. Wiethuechter
AX Enterprize
S. Zhao
Intel
H. Birkholz
Fraunhofer SIT
1 May 2022
Crowd Sourced Remote ID
draft-moskowitz-drip-crowd-sourced-rid-07
Abstract
This document describes using the ASTM Broadcast Remote ID (B-RID)
specification in a "crowd sourced" smart phone environment to provide
much of the ASTM and FAA envisioned Network Remote ID (N-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.
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 2 November 2022.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
Moskowitz, et al. Expires 2 November 2022 [Page 1]
Internet-Draft CS-RID May 2022
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Role of Supplemental Data Service Provider (SDSP) . . . . 4
1.2. Draft Status . . . . . . . . . . . . . . . . . . . . . . 4
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Terminology . . . . . . . . . . . . . . . . 4
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
3. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Meeting the needs of Network Remote ID . . . . . . . . . 7
3.2. Advantages of Broadcast Remote ID . . . . . . . . . . . . 7
3.3. Trustworthiness of Proxied Data . . . . . . . . . . . . . 7
3.4. Defense against fraudulent RID Messages . . . . . . . . . 8
4. The Finder - SDSP Security Relationship . . . . . . . . . . . 8
4.1. SDSP Heartbeats . . . . . . . . . . . . . . . . . . . . . 8
4.2. The Finder Map . . . . . . . . . . . . . . . . . . . . . 9
4.3. Managing Finders . . . . . . . . . . . . . . . . . . . . 9
5. UA location via multilateration . . . . . . . . . . . . . . . 9
5.1. GPS Inaccuracy . . . . . . . . . . . . . . . . . . . . . 10
6. The CS-RID Messages . . . . . . . . . . . . . . . . . . . . . 10
6.1. CS-RID MESSAGE TYPE . . . . . . . . . . . . . . . . . . . 11
6.1.1. CDDL description for CS-RID message type . . . . . . 11
6.2. The CS-RID B-RID Proxy Message . . . . . . . . . . . . . 12
6.2.1. CS-RID ID . . . . . . . . . . . . . . . . . . . . . . 13
6.2.2. CDDL description for CS-RID B-RID Proxy Message . . . 13
6.3. CS-RID Finder Registration . . . . . . . . . . . . . . . 14
6.3.1. CDDL description for Finder Registration . . . . . . 15
6.4. CS-RID SDSP Response . . . . . . . . . . . . . . . . . . 15
6.4.1. CDDL description for SDSP Response . . . . . . . . . 16
6.5. CS-RID Location Update . . . . . . . . . . . . . . . . . 16
6.5.1. CDDL description for Location Update . . . . . . . . 16
6.6. SDSP Heartbeat . . . . . . . . . . . . . . . . . . . . . 17
7. The Full CS-RID CDDL specification . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9.1. Privacy Concerns . . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . 20
Moskowitz, et al. Expires 2 November 2022 [Page 2]
Internet-Draft CS-RID May 2022
Appendix A. Using LIDAR for UA location . . . . . . . . . . . . 22
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction
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 SDSP(s)
(Supplemental Data Service Provider) 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 CAAs
(Civil Aviation Authority) 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 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 (UAS Traffic Management).
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 Key to use ECIES (Elliptic Curve Integrated
Encryption Scheme), 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 Section 4.1.
Moskowitz, et al. Expires 2 November 2022 [Page 3]
Internet-Draft CS-RID May 2022
1.1. Role of Supplemental Data Service Provider (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 [drip-authentication] to the UTM(s). Further, the SDSP
SHOULD validate the Remote ID (RID) and the Authentication signature
before forwarding anything from the UA. 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.
1.2. Draft Status
This draft is still incomplete. New features are being added as
capabilities are researched. The actual message formats also still
need work.
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.
Moskowitz, et al. Expires 2 November 2022 [Page 4]
Internet-Draft CS-RID May 2022
2.2. 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.
CAA:
Civil Aeronautics Administration. An example is the Federal
Aviation Administration (FAA) in the United States of America.
DAA:
Detect and Avoid. The process of a UA detecting obstacles, like
other UAs and taking the necessary evasive action.
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.
GCS:
Ground Control Station. The part of the UAS that the remote pilot
uses to exercise C2 over the UA, whether by remotely exercising UA
flight controls to fly the UA, by setting GPS waypoints, or
otherwise directing its flight.
Finder:
In Internet connected device that can receive B-RID messages and
forward them to a UTM.
Observer:
Referred to in other UAS documents as a "user", but there are also
other classes of RID users, so we prefer "observer" to denote an
individual who has observed an UA and wishes to know something
about it, starting with its RID.
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.
NETSP:
Network RID Service Provider. USS receiving Network RID messages
from UAS (UA or GCS), storing for a short specified time, making
available to NETDP.
NETDP:
Moskowitz, et al. Expires 2 November 2022 [Page 5]
Internet-Draft CS-RID May 2022
Network RID Display Provider. Entity (might be USS) aggregating
data from multiple NETSPs to answer query from observer (or other
party) desiring Situational Awareness of UAS operating in a
specific airspace volume.
N-RID:
Network Remote ID. A method of sending RID messages via the
Internet connection of the UAS directly to the UTM.
RID:
Remote ID. A unique identifier found on all UA to be used in
communication and in regulation of UA operation.
SDSP:
Supplemental Data Service Provider. Entity providing information
that is allowed, but not required to be present in the UTM system.
UA:
Unmanned Aircraft. In this document UA's are typically though of
as drones of commercial or military variety. This is a very
strict definition which can be relaxed to include any and all
aircraft that are unmanned.
UAS:
Unmanned Aircraft System. Composed of Unmanned Aircraft and all
required on-board subsystems, payload, control station, other
required off-board subsystems, any required launch and recovery
equipment, all required crew members, and C2 links between UA and
the control station.
UTM:
UAS Traffic Management. A "traffic management" ecosystem for
uncontrolled operations that is separate from, but complementary
to, the FAA's Air Traffic Management (ATM) system.
USS:
UAS Service Supplier. Provide UTM services to support the UAS
community, to connect Operators and other entities to enable
information flow across the USS network, and to promote shared
situational awareness among UTM participants. (From FAA UTM
ConOps V1, May 2018).
3. Problem Space
Moskowitz, et al. Expires 2 November 2022 [Page 6]
Internet-Draft CS-RID May 2022
3.1. 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 (N-RID) and
focused on Broadcast Remote ID. This was in response to the UAS
vendors comments that N-RID places considerable demands on then
currently used UAS.
However, N-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 N-RID and continue as a adjunct to
N-RID.
3.2. Advantages of Broadcast Remote ID
B-RID has its advantages over N-RID.
* B-RID can more readily be implemented directly in the UA. N-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.
3.3. 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 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-authentication].
The SPDP can manage the number of Finders in an area (see
Section 4.3) to limit DOS attacks from a group of clustered Finders.
Moskowitz, et al. Expires 2 November 2022 [Page 7]
Internet-Draft CS-RID May 2022
3.4. Defense against fraudulent RID Messages
The strongest defense against fraudulent RID messages is to focus on
[drip-authentication] conforming messages. Unless this behavior is
mandated, SPDPs will have to use assorted algorithms to isolate
messages of questionable content.
4. The Finder - SDSP Security Relationship
The SDSP(s) and Finders SHOULD use EDDSA [RFC8032] keys as their
trusted Identities. The public keys SHOULD be registered
Hierarchical HITS, [I-D.ietf-drip-rid] and
[I-D.ietf-drip-registries]. 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. ECIES can be used with a unique nonce to authenticate each
message sent from a Finder to the SDSP.
2. 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.
3. 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.
4. 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. 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 their is a receiver of their
transmissions.
Moskowitz, et al. Expires 2 November 2022 [Page 8]
Internet-Draft CS-RID May 2022
A simple (see Section 6.6) 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.
4.2. 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.
4.3. 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.
5. 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
around a high value site like an airport or large public venue.
Moskowitz, et al. Expires 2 November 2022 [Page 9]
Internet-Draft CS-RID May 2022
5.1. 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 [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 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.
6. 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 [RFC7049]. The CDDL
[RFC8610] specification is used for CS-RID message description.
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.
Moskowitz, et al. Expires 2 November 2022 [Page 10]
Internet-Draft CS-RID May 2022
6.1. CS-RID MESSAGE TYPE
The CS-RID MESSAGE TYPE is defined in Figure 1:
Number CS-RID Message Type
------ -----------------
0 Reserved
1 B-RID Forwarding
2 Finder Registration
3 SDSP Response
4 Finder Location
5 SDSP Heartbeat
Figure 1
6.1.1. CDDL description for CS-RID message type
The overall CS-RID CDDL description is structured in Figure 2.
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,
}
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,
)
Figure 2
Moskowitz, et al. Expires 2 November 2022 [Page 11]
Internet-Draft CS-RID May 2022
The application context rule is defined in Figure 3 for CS-RID
application identification and version negotiation.
application-context = (
application => "DRIP-CSRID",
? version => uint .size(1..2),
)
Figure 3
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 Figure 4.
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"
Figure 4
6.2. 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.
Moskowitz, et al. Expires 2 November 2022 [Page 12]
Internet-Draft CS-RID May 2022
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 MESSAGE TYPE,
CS-RID ID,
RECEIVE TIMESTAMP,
RECEIVE GPS,
RECEIVE RADIO TYPE,
B-RID MAC ADDRESS,
B-RID MESSAGE,
CS-RID MAC
)
6.2.1. CS-RID ID
The CS-RID ID is the ID recognized by the SDSP. This may be an HHIT
Hierarchical HITs [hierarchical-hit], or any ID used by the SDSP.
6.2.2. CDDL description for CS-RID B-RID Proxy Message
The broadcast CS-RID proxy CDDL is defined in Figure 5
Moskowitz, et al. Expires 2 November 2022 [Page 13]
Internet-Draft CS-RID May 2022
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),
}
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,
]
Figure 5
6.3. CS-RID Finder Registration
The CS-RID Finder MAY use [RFC7401](#RFC7401) 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 [RFC4303][RFC4303] 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:
Moskowitz, et al. Expires 2 November 2022 [Page 14]
Internet-Draft CS-RID May 2022
(
CS-RID MESSAGE TYPE,
CS-RID ID,
CS-RID TIMESTAMP,
CS-RID GPS,
CS-RID MAC
)
6.3.1. CDDL description for Finder Registration
The CDDL for CS-RID Finder Registration is defined in Figure 6
finder_registration_message = {
common_message_members,
rid => tstr,
timestamp => tdate,
gps => gps-coordinates,
}
gps-coordinates = [
latitude : float,
longitude: float,
]
Figure 6
6.4. CS-RID SDSP Response
The SDSP MAY respond to any Finder messages to instruct the Finder on
its behavior.
(
CS-RID MESSAGE TYPE,
SDSP ID,
CS-RID ID,
CS-RID PROXY STATUS,
CS-RID UPDATE INTERVAL,
CS-RID MAC
)
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.
Moskowitz, et al. Expires 2 November 2022 [Page 15]
Internet-Draft CS-RID May 2022
6.4.1. CDDL description for SDSP Response
The CDDL for CS-RID SDSP response is defined in Figure 7
sdsp_response_message = {
common_message_members,
sdsp_id => tstr,
rid => tstr,
proxy_status_type => proxy_status_types,
update_interval => uint,
}
gps-coordinates = [
latitude : float,
longitude: float,
]
proxy_status_types = &(
0: "forward",
1: "reverse",
2: "bi-directional",
)
Figure 7
6.5. CS-RID Location Update
The Finder SHOULD provide regular location updates to the SDSP. The
interval is based on the Update Interval from Section 6.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 SDSP 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
)
6.5.1. CDDL description for Location Update
The CDDL for CS-RID Location update is defined in Figure 8
Moskowitz, et al. Expires 2 November 2022 [Page 16]
Internet-Draft CS-RID May 2022
location_update_message = {
common_message_members,
rid => tstr,
timestamp => tdate,
gps => gps-coordinates,
}
gps-coordinates = [
latitude : float,
longitude: float,
]
Figure 8
6.6. SDSP Heartbeat
TBD
7. The Full CS-RID CDDL specification
<CODE BEGINS>
; 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,
Moskowitz, et al. Expires 2 November 2022 [Page 17]
Internet-Draft CS-RID May 2022
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,
Moskowitz, et al. Expires 2 November 2022 [Page 18]
Internet-Draft CS-RID May 2022
BRD : 1,
Finder-Registration : 2,
SDSP-Response : 3,
Finder-Location : 4,
)
gps-coordinates = [
lat: float,
long: 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"
Moskowitz, et al. Expires 2 November 2022 [Page 19]
Internet-Draft CS-RID May 2022
broadcast_mac_address = "broadcast_mac_address"
broadcast_message = "broadcast_message"
sdsp_id = "sdsp_id"
proxy_status_type = "proxy_status_type"
update_interval = "update_interval"
<CODE ENDS>
8. IANA Considerations
TBD
9. Security Considerations
TBD
9.1. Privacy Concerns
TBD
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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, <https://www.rfc-editor.org/info/rfc8610>.
10.2. Informative References
[drip-authentication]
Wiethuechter, A., Card, S., and R. Moskowitz, "DRIP
Authentication Formats & Protocols for Broadcast Remote
ID", Work in Progress, Internet-Draft, draft-ietf-drip-
auth-09, 30 April 2022, <https://www.ietf.org/archive/id/
draft-ietf-drip-auth-09.txt>.
Moskowitz, et al. Expires 2 November 2022 [Page 20]
Internet-Draft CS-RID May 2022
[F3411-19] ASTM International, "Standard Specification for Remote ID
and Tracking", February 2020,
<http://www.astm.org/cgi-bin/resolver.cgi?F3411>.
[FAA-FR] United States Federal Aviation Administration (FAA), "FAA
Remote Identification of Unmanned Aircraft", January 2021,
<https://www.govinfo.gov/content/pkg/FR-2021-01-15/
pdf/2020-28948.pdf>.
[gps-ionosphere]
"Ionospheric response to the 2015 St. Patrick's Day storm
A global multi-instrumental overview", September 2015,
<https://doi.org/10.1002/2015JA021629>.
[hhit-registries]
Moskowitz, R., Card, S. W., and A. Wiethuechter,
"Hierarchical HIT Registries", Work in Progress, Internet-
Draft, draft-moskowitz-hip-hhit-registries-02, 9 March
2020, <https://www.ietf.org/archive/id/draft-moskowitz-
hip-hhit-registries-02.txt>.
[hierarchical-hit]
Moskowitz, R., Card, S. W., and A. Wiethuechter,
"Hierarchical HITs for HIPv2", Work in Progress, Internet-
Draft, draft-moskowitz-hip-hierarchical-hit-05, 13 May
2020, <https://www.ietf.org/archive/id/draft-moskowitz-
hip-hierarchical-hit-05.txt>.
[I-D.ietf-drip-registries]
Wiethuechter, A., Card, S., Moskowitz, R., and J. Reid,
"DRIP Entity Tag Registration & Lookup", Work in Progress,
Internet-Draft, draft-ietf-drip-registries-02, 30 April
2022, <https://www.ietf.org/archive/id/draft-ietf-drip-
registries-02.txt>.
[I-D.ietf-drip-rid]
Moskowitz, R., Card, S. W., Wiethuechter, A., and A.
Gurtov, "DRIP Entity Tag (DET) for Unmanned Aircraft
System Remote ID (UAS RID)", Work in Progress, Internet-
Draft, draft-ietf-drip-rid-24, 24 April 2022,
<https://www.ietf.org/archive/id/draft-ietf-drip-rid-
24.txt>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
Moskowitz, et al. Expires 2 November 2022 [Page 21]
Internet-Draft CS-RID May 2022
[RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over
the Datagram Congestion Control Protocol (DCCP)",
RFC 5238, DOI 10.17487/RFC5238, May 2008,
<https://www.rfc-editor.org/info/rfc5238>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.
[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,
<https://www.rfc-editor.org/info/rfc7401>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
Appendix A. 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.
Moskowitz, et al. Expires 2 November 2022 [Page 22]
Internet-Draft CS-RID May 2022
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.
Authors' Addresses
Robert Moskowitz
HTT Consulting
Oak Park, MI 48237
United States of America
Email: rgm@labs.htt-consult.com
Stuart W. Card
AX Enterprize
4947 Commercial Drive
Yorkville, NY 13495
United States of America
Email: stu.card@axenterprize.com
Adam Wiethuechter
AX Enterprize
4947 Commercial Drive
Yorkville, NY 13495
United States of America
Email: adam.wiethuechter@axenterprize.com
Shuai Zhao
Intel
2200 Mission College Blvd
Santa Clara, CA 95054
United States of America
Email: shuai.zhao@ieee.org
Moskowitz, et al. Expires 2 November 2022 [Page 23]
Internet-Draft CS-RID May 2022
Henk Birkholz
Fraunhofer SIT
Rheinstrasse 75
64295 Darmstadt
Germany
Email: henk.birkholz@sit.fraunhofer.de
Moskowitz, et al. Expires 2 November 2022 [Page 24]