< draft-moskowitz-drip-crowd-sourced-rid-06.txt   draft-moskowitz-drip-crowd-sourced-rid-07.txt >
DRIP R. Moskowitz DRIP R. Moskowitz
Internet-Draft HTT Consulting Internet-Draft HTT Consulting
Intended status: Standards Track S. Card Intended status: Standards Track S. Card
Expires: 27 November 2021 A. Wiethuechter Expires: 2 November 2022 A. Wiethuechter
AX Enterprize AX Enterprize
S. Zhao S. Zhao
Tencent Intel
H. Birkholz H. Birkholz
Fraunhofer SIT Fraunhofer SIT
26 May 2021 1 May 2022
Crowd Sourced Remote ID Crowd Sourced Remote ID
draft-moskowitz-drip-crowd-sourced-rid-06 draft-moskowitz-drip-crowd-sourced-rid-07
Abstract Abstract
This document describes using the ASTM Broadcast Remote ID (B-RID) This document describes using the ASTM Broadcast Remote ID (B-RID)
specification in a "crowd sourced" smart phone environment to provide specification in a "crowd sourced" smart phone environment to provide
much of the ASTM and FAA envisioned Network Remote ID (N-RID) much of the ASTM and FAA envisioned Network Remote ID (N-RID)
functionality. This crowd sourced B-RID data will use functionality. This crowd sourced B-RID (CS-RID) data will use
multilateration to add a level of reliability in the location data on multilateration to add a level of reliability in the location data on
the Unmanned Aircraft (UA). The crowd sourced environment will also the Unmanned Aircraft (UA). The crowd sourced environment will also
provide a monitoring coverage map to authorized observers. provide a monitoring coverage map to authorized observers.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 27 November 2021. This Internet-Draft will expire on 2 November 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Draft Status . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Role of Supplemental Data Service Provider (SDSP) . . . . 4
1.2. Draft Status . . . . . . . . . . . . . . . . . . . . . . 4
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Terminology . . . . . . . . . . . . . . . . 4 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 4
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
3. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Meeting the needs of Network Remote ID . . . . . . . . . 6 3.1. Meeting the needs of Network Remote ID . . . . . . . . . 7
3.2. Advantages of Broadcast Remote ID . . . . . . . . . . . . 6 3.2. Advantages of Broadcast Remote ID . . . . . . . . . . . . 7
3.3. Trustworthiness of Proxied Data . . . . . . . . . . . . . 7 3.3. Trustworthiness of Proxied Data . . . . . . . . . . . . . 7
3.4. Defense against fraudulent RID Messages . . . . . . . . . 7 3.4. Defense against fraudulent RID Messages . . . . . . . . . 8
4. The Finder - SDSP Security Relationship . . . . . . . . . . . 7 4. The Finder - SDSP Security Relationship . . . . . . . . . . . 8
4.1. The Finder Map . . . . . . . . . . . . . . . . . . . . . 8 4.1. SDSP Heartbeats . . . . . . . . . . . . . . . . . . . . . 8
4.2. Managing Finders . . . . . . . . . . . . . . . . . . . . 8 4.2. The Finder Map . . . . . . . . . . . . . . . . . . . . . 9
5. UA location via multilateration . . . . . . . . . . . . . . . 8 4.3. Managing Finders . . . . . . . . . . . . . . . . . . . . 9
5.1. GPS Inaccuracy . . . . . . . . . . . . . . . . . . . . . 9 5. UA location via multilateration . . . . . . . . . . . . . . . 9
6. The CS-RID Messages . . . . . . . . . . . . . . . . . . . . . 9 5.1. GPS Inaccuracy . . . . . . . . . . . . . . . . . . . . . 10
6.1. CS-RID MESSAGE TYPE . . . . . . . . . . . . . . . . . . . 10 6. The CS-RID Messages . . . . . . . . . . . . . . . . . . . . . 10
6.1.1. CDDL description for CS-RID message type . . . . . . 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. The CS-RID B-RID Proxy Message . . . . . . . . . . . . . 12
6.2.1. CS-RID ID . . . . . . . . . . . . . . . . . . . . . . 13 6.2.1. CS-RID ID . . . . . . . . . . . . . . . . . . . . . . 13
6.2.2. CDDL description for CS-RID B-RID Proxy Message . . . 13 6.2.2. CDDL description for CS-RID B-RID Proxy Message . . . 13
6.3. CS-RID Finder Registration . . . . . . . . . . . . . . . 14 6.3. CS-RID Finder Registration . . . . . . . . . . . . . . . 14
6.3.1. CDDL description for Finder Registration . . . . . . 14 6.3.1. CDDL description for Finder Registration . . . . . . 15
6.4. CS-RID SDSP Response . . . . . . . . . . . . . . . . . . 15 6.4. CS-RID SDSP Response . . . . . . . . . . . . . . . . . . 15
6.4.1. CDDL description for SDSP Response . . . . . . . . . 15 6.4.1. CDDL description for SDSP Response . . . . . . . . . 16
6.5. CS-RID Location Update . . . . . . . . . . . . . . . . . 16 6.5. CS-RID Location Update . . . . . . . . . . . . . . . . . 16
6.5.1. CDDL description for Location Update . . . . . . . . 16 6.5.1. CDDL description for Location Update . . . . . . . . 16
7. The Full CS-RID CDDL specification . . . . . . . . . . . . . 16 6.6. SDSP Heartbeat . . . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. The Full CS-RID CDDL specification . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9.1. Privacy Concerns . . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Privacy Concerns . . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . 20 10.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. Using LIDAR for UA location . . . . . . . . . . . . 21
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22 Appendix A. Using LIDAR for UA location . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
This document defines a mechanism to capture the ASTM Broadcast This document defines a mechanism to capture the ASTM Broadcast
Remote ID messages (B-RID) [F3411-19] on any Internet connected Remote ID messages (B-RID) [F3411-19] on any Internet connected
device that receives them and can forward them to the SDSP(s) device that receives them and can forward them to the SDSP(s)
responsible for the geographic area the UA and receivers are in. (Supplemental Data Service Provider) responsible for the geographic
This will create a ecosystem that will meet most if not all data area the UA and receivers are in. This will create a ecosystem that
collection requirements that CAAs are placing on Network Remote ID will meet most if not all data collection requirements that CAAs
(N-RID). (Civil Aviation Authority) are placing on Network Remote ID (N-RID).
These Internet connected devices are herein called "Finders", as they These Internet connected devices are herein called "Finders", as they
find UAs by listening for B-RID messages. The Finders are B-RID find UAs by listening for B-RID messages. The Finders are B-RID
forwarding proxies. Their potentially limited spacial view of RID forwarding proxies. Their potentially limited spacial view of RID
messages could result in bad decisions on what messages to send to messages could result in bad decisions on what messages to send to
the SDSP and which to drop. The SDSP will make any filtering the SDSP and which to drop. Thus they will send all received
decisions in what it forwards to the UTM(s). 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 Finders can be smartphones, tablets, connected cars, or any computing
platform with Internet connectivity that can meet the requirements platform with Internet connectivity that can meet the requirements
defined in this document. It is not expected, nor necessary, that defined in this document. It is not expected, nor necessary, that
Finders have any information about a UAS beyond the content in the Finders have any information about a UAS beyond the content in the
B-RID messages. B-RID messages.
Finders MAY only need a loose association with the SDSP(s). They may 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 only have the SDSP's Public Key and FQDN. It would use these, along
with the Finder's Public Key to use ECIES, or other security methods, with the Finder's Public Key to use ECIES (Elliptic Curve Integrated
to send the messages in a secure manner to the SDSP. The SDSP MAY Encryption Scheme), or other security methods, to send the messages
require a stronger relationship to the Finders. This may range from in a secure manner to the SDSP. The SDSP MAY require a stronger
the Finder's Public Key being registered to the SDSP with other relationship to the Finders. This may range from the Finder's Public
information so that the SDSP has some level of trust in the Finders Key being registered to the SDSP with other information so that the
to requiring transmissions be sent over long-lived transport SDSP has some level of trust in the Finders to requiring
connections like ESP or DTLS. 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.
1.1. Role of Supplemental Data Service Provider (SDSP)
This document has minimal information about the actions of SDSPs. In This document has minimal information about the actions of SDSPs. In
general the SDSP is out of scope of this document. That said, the 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 SDSPs should not simply proxy B-RID messages to the UTM(s). They
should perform some minimal level of filtering and content checking should perform some minimal level of filtering and content checking
before forwarding those messages that pass these tests in a secure before forwarding those messages that pass these tests in a secure
manner to the UTM(s). manner to the UTM(s).
The SDSPs are also capable of maintaining a monitoring map, based on The SDSPs are also capable of maintaining a monitoring map, based on
location of active Finders. UTMs may use this information to notify location of active Finders. UTMs may use this information to notify
authorized observers of where there is and there is not monitoring authorized observers of where there is and there is not monitoring
coverage. They may also use this information of where to place pro- coverage. They may also use this information of where to place pro-
active monitoring coverage. active monitoring coverage.
An SDSP SHOULD only forward Authenticated B-RID messages like those An SDSP SHOULD only forward Authenticated B-RID messages like those
defined in [tmrid-auth] to the UTM(s). Further, the SDSP SHOULD defined in [drip-authentication] to the UTM(s). Further, the SDSP
validate the Remote ID (RID) and the Authentication signature before SHOULD validate the Remote ID (RID) and the Authentication signature
forwarding anything from the UA. The SDSP MAY forward all B-RID before forwarding anything from the UA. The SDSP MAY forward all
messages to the UTM, leaving all decision making on B-RID messages B-RID messages to the UTM, leaving all decision making on B-RID
veracity to the UTM. messages veracity to the UTM.
When 3 or more Finders are reporting to an SDSP on a specific UA, the 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 SDSP is in a unique position to perform multilateration on these
messages and compute the Finder's view of the UA location to compare 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 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 location claims is both a validation on the UA's reliability as well
as the trustworthiness of the Finders. Other than providing data to as the trustworthiness of the Finders. Other than providing data to
allow for multilateration, this SDSP feature is out of scope of this allow for multilateration, this SDSP feature is out of scope of this
document. This function is limited by the location accuracy for both document. This function is limited by the location accuracy for both
the Finders and UA. the Finders and UA.
1.1. Draft Status 1.2. Draft Status
This draft is still incomplete. New features are being added as This draft is still incomplete. New features are being added as
capabilities are researched. The actual message formats also still capabilities are researched. The actual message formats also still
need work. need work.
2. Terms and Definitions 2. Terms and Definitions
2.1. Requirements Terminology 2.1. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 6, line 35 skipping to change at page 7, line 4
to, the FAA's Air Traffic Management (ATM) system. to, the FAA's Air Traffic Management (ATM) system.
USS: USS:
UAS Service Supplier. Provide UTM services to support the UAS UAS Service Supplier. Provide UTM services to support the UAS
community, to connect Operators and other entities to enable community, to connect Operators and other entities to enable
information flow across the USS network, and to promote shared information flow across the USS network, and to promote shared
situational awareness among UTM participants. (From FAA UTM situational awareness among UTM participants. (From FAA UTM
ConOps V1, May 2018). ConOps V1, May 2018).
3. Problem Space 3. Problem Space
3.1. Meeting the needs of Network Remote ID 3.1. Meeting the needs of Network Remote ID
The Federal (US) Aviation Authority (FAA), in the January 2021 Remote The USA Federal Aviation Authority (FAA), in the January 2021 Remote
ID Final rule [FAA-FR], has postponed Network Remote ID (N-RID) and ID Final rule [FAA-FR], postponed Network Remote ID (N-RID) and
focused on Broadcast Remote ID for now. This was in response to the focused on Broadcast Remote ID. This was in response to the UAS
UAS vendors comments that N-RID places considerable demands on vendors comments that N-RID places considerable demands on then
currently used UAS. currently used UAS.
However, N-RID, or equivalent, is necessary for UTM and knowing what 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 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 function as an interim approach to N-RID and continue as a adjunct to
N-RID. N-RID.
3.2. Advantages of Broadcast Remote ID 3.2. Advantages of Broadcast Remote ID
B-RID has its advantages over N-RID. B-RID has its advantages over N-RID.
skipping to change at page 7, line 29 skipping to change at page 7, line 45
3.3. Trustworthiness of Proxied Data 3.3. Trustworthiness of Proxied Data
When a proxy is introduced in any communication protocol, there is a When a proxy is introduced in any communication protocol, there is a
risk of corrupted data and DOS attacks. risk of corrupted data and DOS attacks.
The Finders, in their role as proxies for B-RID, are authenticated to 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 the SDSP (see Section 4). The SDSP can compare the information from
multiple Finders to isolate a Finder sending fraudulent information. multiple Finders to isolate a Finder sending fraudulent information.
SDSPs can additionally verify authenticated messages that follow SDSPs can additionally verify authenticated messages that follow
[tmrid-auth]. [drip-authentication].
The SPDP can manage the number of Finders in an area (see 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. Section 4.3) to limit DOS attacks from a group of clustered Finders.
3.4. Defense against fraudulent RID Messages 3.4. Defense against fraudulent RID Messages
The strongest defense against fraudulent RID messages is to focus on The strongest defense against fraudulent RID messages is to focus on
[tmrid-auth] conforming messages. Unless this behavior is mandated, [drip-authentication] conforming messages. Unless this behavior is
SPDPs will have to use assorted algorithms to isolate messages of mandated, SPDPs will have to use assorted algorithms to isolate
questionable content. messages of questionable content.
4. The Finder - SDSP Security Relationship 4. The Finder - SDSP Security Relationship
The SDSP(s) and Finders SHOULD use EDDSA [RFC8032] keys as their The SDSP(s) and Finders SHOULD use EDDSA [RFC8032] keys as their
trusted Identities. The public keys SHOULD be registered trusted Identities. The public keys SHOULD be registered
Hierarchical HITS, [hierarchical-hit] and [hhit-registries]. 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 The SDSP uses some process (out of scope here) to register the
Finders and their EDDSA Public Key. During this registration, the Finders and their EDDSA Public Key. During this registration, the
Finder gets the SDSP's EDDSA Public Key. These Public Keys allow for Finder gets the SDSP's EDDSA Public Key. These Public Keys allow for
the following options for authenticated messaging from the Finder to the following options for authenticated messaging from the Finder to
the SDSP. the SDSP.
1. ECIES can be used with a unique nonce to authenticate each 1. ECIES can be used with a unique nonce to authenticate each
message sent from a Finder to the SDSP. message sent from a Finder to the SDSP.
2. ECIES can be used at the start of some period (e.g. day) to 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 establish a shared secret that is then used to authenticate each
message sent from a Finder to the SDSP sent during that period. message sent from a Finder to the SDSP sent during that period.
3. HIPv2 [RFC7401] can be used to establish a session secret that is 3. HIP [RFC7401] can be used to establish a session secret that is
then used with ESP [RFC4303] to authenticate each message sent then used with ESP [RFC4303] to authenticate each message sent
from a Finder to the SDSP. from a Finder to the SDSP.
4. DTLS [RFC5238] can be used to establish a secure connection that 4. DTLS [RFC5238] can be used to establish a secure connection that
is then used to authenticate each message sent from a Finder to is then used to authenticate each message sent from a Finder to
the SDSP. the SDSP.
4.1. The Finder Map 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.
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. The Finders are regularly providing their SDSP with their location.
This is through the B-RID Proxy Messages and Finder Location Update This is through the B-RID Proxy Messages and Finder Location Update
Messages. With this information, the SDSP can maintain a monitoring Messages. With this information, the SDSP can maintain a monitoring
map. That is a map of where there Finder coverage. map. That is a map of where there Finder coverage.
4.2. Managing Finders 4.3. Managing Finders
Finder density will vary over time and space. For example, sidewalks Finder density will vary over time and space. For example, sidewalks
outside an urban train station can be packed with pedestrians at rush outside an urban train station can be packed with pedestrians at rush
hour, either coming or going to their commute trains. An SDSP may hour, either coming or going to their commute trains. An SDSP may
want to proactively limit the number of active Finders in such want to proactively limit the number of active Finders in such
situations. situations.
Using the Finder mapping feature, the SDSP can instruct Finders to Using the Finder mapping feature, the SDSP can instruct Finders to
NOT proxy B-RID messages. These Finders will continue to report NOT proxy B-RID messages. These Finders will continue to report
their location and through that reporting, the SDSP can instruct them their location and through that reporting, the SDSP can instruct them
skipping to change at page 9, line 18 skipping to change at page 10, line 13
around a high value site like an airport or large public venue. around a high value site like an airport or large public venue.
5.1. GPS Inaccuracy 5.1. GPS Inaccuracy
Single-band, consumer grade, GPS on small platforms is not accurate, Single-band, consumer grade, GPS on small platforms is not accurate,
particularly for altitude. Longitude/latitude measurements can particularly for altitude. Longitude/latitude measurements can
easily be off by 3M based on satellite postion and clock accuracy. easily be off by 3M based on satellite postion and clock accuracy.
Altitude accuracy is reported in product spec sheets and actual tests Altitude accuracy is reported in product spec sheets and actual tests
to be 3x less accurate. Altitude accuracy is hindered by ionosphere to be 3x less accurate. Altitude accuracy is hindered by ionosphere
activity. In fact, there are studies of ionospheric events (e.g. activity. In fact, there are studies of ionospheric events (e.g.
2015 St. Patrick's day Thus where a UA reports it is rarely accurate, 2015 St. Patrick's day [gps-ionosphere]) as measured by GPS devices
but may be accurate enough to map to visual sightings of single at known locations.
UA.[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 Smartphones and particulary smartwatches are plagued with the same
challenge, though some of these can combine other information like challenge, though some of these can combine other information like
cell tower data to improve location accuracy. FCC E911 accuracy, by cell tower data to improve location accuracy. FCC E911 accuracy, by
FCC rules is NOT available to non-E911 applications due to privacy FCC rules is NOT available to non-E911 applications due to privacy
concerns, but general higher accuracy is found on some smart devices concerns, but general higher accuracy is found on some smart devices
than reported for consumer UA. The SDSP MAY have information on the than reported for consumer UA. The SDSP MAY have information on the
Finder location accuracy that it can use in calculating the accuracy Finder location accuracy that it can use in calculating the accuracy
of a multilaterated location value. When the Finders are fixed of a multilaterated location value. When the Finders are fixed
assets, the SDSP may have very high trust in their location for assets, the SDSP may have very high trust in their location for
trusting the multilateration calculation over the UA reported trusting the multilateration calculation over the UA reported
location. location.
6. The CS-RID Messages 6. The CS-RID Messages
The CS-RID messages between the Finders and the SDSPs primarily The CS-RID messages between the Finders and the SDSPs primarily
support the proxy role of the Finders in forwarding the B-RID support the proxy role of the Finders in forwarding the B-RID
messages. There are also Finder registration and status messages. messages. There are also Finder registration and status messages.
CS-RID information is represented in CBOR [RFC7049]. The CDDL CS-RID information is represented in CBOR [RFC7049]. The CDDL
[RFC8610] specification is used for CS-RID message description [RFC8610] specification is used for CS-RID message description.
CS-RID MAC and COAP [RFC7252] for the CS-RID protocol.
The following is a general representation of the content in the CS- The following is a general representation of the content in the CS-
RID messages. RID messages.
( (
CS-RID MESSAGE TYPE, CS-RID MESSAGE TYPE,
CS-RID MESSAGE CONTENT, CS-RID MESSAGE CONTENT,
CS-RID MAC CS-RID MAC
) )
skipping to change at page 10, line 24 skipping to change at page 11, line 16
The CS-RID MESSAGE TYPE is defined in Figure 1: The CS-RID MESSAGE TYPE is defined in Figure 1:
Number CS-RID Message Type Number CS-RID Message Type
------ ----------------- ------ -----------------
0 Reserved 0 Reserved
1 B-RID Forwarding 1 B-RID Forwarding
2 Finder Registration 2 Finder Registration
3 SDSP Response 3 SDSP Response
4 Finder Location 4 Finder Location
5 SDSP Heartbeat
Figure 1 Figure 1
6.1.1. CDDL description for CS-RID message type 6.1.1. CDDL description for CS-RID message type
The overall CS-RID CDDL description is structured in Figure 2. The overall CS-RID CDDL description is structured in Figure 2.
CSRID_Object = { CSRID_Object = {
application-context, application-context,
info => info_message, info => info_message,
skipping to change at page 14, line 4 skipping to change at page 14, line 31
VHF : 6, VHF : 6,
UHF : 7, UHF : 7,
SHF : 8, SHF : 8,
EHF : 9, EHF : 9,
) )
gps-coordinates = [ gps-coordinates = [
latitude : float, latitude : float,
longitude: float, longitude: float,
] ]
Figure 5 Figure 5
6.3. CS-RID Finder Registration 6.3. CS-RID Finder Registration
The CS-RID Finder MAY use HIPv2 [RFC7401] with the SDSP to establish The CS-RID Finder MAY use [RFC7401](#RFC7401) with the SDSP to
a Security Association and a shared secret to use for the CS-RID MAC establish a Security Association and a shared secret to use for the
generation. In this approach, the HIPv2 mobility functionality and CS-RID MAC generation. In this approach, the HIP mobility
ESP [RFC4303] support are not used. functionality and [RFC4303][RFC4303] support are not used.
When HIPv2 is used as above, the Finder Registration is a SDSP "wake 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 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 to ensure that the SDSP is able to receive and process the
messages. messages.
In this usage, the CS-RID is the Finder HIT. If the SDSP has lost 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 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 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: Proxy Messages. In this case the Finder Registration Message is:
( (
CS-RID MESSAGE TYPE, CS-RID MESSAGE TYPE,
CS-RID ID, CS-RID ID,
CS-RID TIMESTAMP, CS-RID TIMESTAMP,
CS-RID GPS, CS-RID GPS,
CS-RID MAC CS-RID MAC
skipping to change at page 16, line 27 skipping to change at page 17, line 4
CS-RID MESSAGE TYPE, CS-RID MESSAGE TYPE,
CS-RID ID, CS-RID ID,
CS-RID TIMESTAMP, CS-RID TIMESTAMP,
CS-RID GPS, CS-RID GPS,
CS-RID MAC CS-RID MAC
) )
6.5.1. CDDL description for Location Update 6.5.1. CDDL description for Location Update
The CDDL for CS-RID Location update is defined in Figure 8 The CDDL for CS-RID Location update is defined in Figure 8
location_update_message = { location_update_message = {
common_message_members, common_message_members,
rid => tstr, rid => tstr,
timestamp => tdate, timestamp => tdate,
gps => gps-coordinates, gps => gps-coordinates,
} }
gps-coordinates = [ gps-coordinates = [
latitude : float, latitude : float,
longitude: float, longitude: float,
] ]
Figure 8 Figure 8
6.6. SDSP Heartbeat
TBD
7. The Full CS-RID CDDL specification 7. The Full CS-RID CDDL specification
<CODE BEGINS> <CODE BEGINS>
; CDDL specification for Crowd source RID ; CDDL specification for Crowd source RID
; It specifies a collection of CS message types ; It specifies a collection of CS message types
; ;
; ;
; The CSRID overall data structure ; The CSRID overall data structure
skipping to change at page 20, line 17 skipping to change at page 20, line 45
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>. June 2019, <https://www.rfc-editor.org/info/rfc8610>.
10.2. Informative References 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>.
[F3411-19] ASTM International, "Standard Specification for Remote ID [F3411-19] ASTM International, "Standard Specification for Remote ID
and Tracking", February 2020, and Tracking", February 2020,
<http://www.astm.org/cgi-bin/resolver.cgi?F3411>. <http://www.astm.org/cgi-bin/resolver.cgi?F3411>.
[FAA-FR] United States Federal Aviation Administration (FAA), "FAA [FAA-FR] United States Federal Aviation Administration (FAA), "FAA
Remote Identification of Unmanned Aircraft", January 2021, Remote Identification of Unmanned Aircraft", January 2021,
<https://www.govinfo.gov/content/pkg/FR-2021-01-15/ <https://www.govinfo.gov/content/pkg/FR-2021-01-15/
pdf/2020-28948.pdf>. pdf/2020-28948.pdf>.
[gps-ionosphere] [gps-ionosphere]
skipping to change at page 20, line 45 skipping to change at page 21, line 33
2020, <https://www.ietf.org/archive/id/draft-moskowitz- 2020, <https://www.ietf.org/archive/id/draft-moskowitz-
hip-hhit-registries-02.txt>. hip-hhit-registries-02.txt>.
[hierarchical-hit] [hierarchical-hit]
Moskowitz, R., Card, S. W., and A. Wiethuechter, Moskowitz, R., Card, S. W., and A. Wiethuechter,
"Hierarchical HITs for HIPv2", Work in Progress, Internet- "Hierarchical HITs for HIPv2", Work in Progress, Internet-
Draft, draft-moskowitz-hip-hierarchical-hit-05, 13 May Draft, draft-moskowitz-hip-hierarchical-hit-05, 13 May
2020, <https://www.ietf.org/archive/id/draft-moskowitz- 2020, <https://www.ietf.org/archive/id/draft-moskowitz-
hip-hierarchical-hit-05.txt>. 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)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005, RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>. <https://www.rfc-editor.org/info/rfc4303>.
[RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over
the Datagram Congestion Control Protocol (DCCP)", the Datagram Congestion Control Protocol (DCCP)",
RFC 5238, DOI 10.17487/RFC5238, May 2008, RFC 5238, DOI 10.17487/RFC5238, May 2008,
<https://www.rfc-editor.org/info/rfc5238>. <https://www.rfc-editor.org/info/rfc5238>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
skipping to change at page 21, line 24 skipping to change at page 22, line 29
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)", Henderson, "Host Identity Protocol Version 2 (HIPv2)",
RFC 7401, DOI 10.17487/RFC7401, April 2015, RFC 7401, DOI 10.17487/RFC7401, April 2015,
<https://www.rfc-editor.org/info/rfc7401>. <https://www.rfc-editor.org/info/rfc7401>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017, DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>. <https://www.rfc-editor.org/info/rfc8032>.
[tmrid-auth]
Wiethuechter, A., Card, S. W., and R. Moskowitz, "TM-RID
Authentication Formats", Work in Progress, Internet-Draft,
draft-wiethuechter-tmrid-auth-05, 18 February 2020,
<https://www.ietf.org/archive/id/draft-wiethuechter-tmrid-
auth-05.txt>.
Appendix A. Using LIDAR for UA location Appendix A. Using LIDAR for UA location
If the Finder has LIDAR or similar detection equipment (e.g. on a 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 connected car) that has full sky coverage, the Finder can use this
equipment to locate UAs in its airspace. The Finder would then be equipment to locate UAs in its airspace. The Finder would then be
able to detect non-participating UAs. A non-participating UA is one 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 that the Finder can "see" with the LIDAR, but not "hear" any B-RID
messages. messages.
These Finders would then take the LIDAR data, construct appropriate These Finders would then take the LIDAR data, construct appropriate
skipping to change at page 22, line 26 skipping to change at page 23, line 23
The Crowd Sourcing idea in this document came from the Apple "Find My The Crowd Sourcing idea in this document came from the Apple "Find My
Device" presentation at the International Association for Device" presentation at the International Association for
Cryptographic Research's Real World Crypto 2020 conference. Cryptographic Research's Real World Crypto 2020 conference.
Authors' Addresses Authors' Addresses
Robert Moskowitz Robert Moskowitz
HTT Consulting HTT Consulting
Oak Park, MI 48237 Oak Park, MI 48237
United States of America United States of America
Email: rgm@labs.htt-consult.com Email: rgm@labs.htt-consult.com
Stuart W. Card Stuart W. Card
AX Enterprize AX Enterprize
4947 Commercial Drive 4947 Commercial Drive
Yorkville, NY 13495 Yorkville, NY 13495
United States of America United States of America
Email: stu.card@axenterprize.com Email: stu.card@axenterprize.com
Adam Wiethuechter Adam Wiethuechter
AX Enterprize AX Enterprize
4947 Commercial Drive 4947 Commercial Drive
Yorkville, NY 13495 Yorkville, NY 13495
United States of America United States of America
Email: adam.wiethuechter@axenterprize.com Email: adam.wiethuechter@axenterprize.com
Shuai Zhao Shuai Zhao
Tencent Intel
2747 Park Blvd 2200 Mission College Blvd
Palo Alto, CA 94306 Santa Clara, CA 95054
United States of America United States of America
Email: shuai.zhao@ieee.org Email: shuai.zhao@ieee.org
Henk Birkholz Henk Birkholz
Fraunhofer SIT Fraunhofer SIT
Rheinstrasse 75 Rheinstrasse 75
64295 Darmstadt 64295 Darmstadt
Germany Germany
Email: henk.birkholz@sit.fraunhofer.de Email: henk.birkholz@sit.fraunhofer.de
 End of changes. 50 change blocks. 
96 lines changed or deleted 142 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/