Internet DRAFT - draft-moskowitz-tmrid-crowd-sourced-rid
draft-moskowitz-tmrid-crowd-sourced-rid
TMRID R. Moskowitz
Internet-Draft HTT Consulting
Intended status: Standards Track S. Card
Expires: 3 September 2020 A. Wiethuechter
AX Enterprize
2 March 2020
Crowd Sourced Remote ID
draft-moskowitz-tmrid-crowd-sourced-rid-01
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 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).
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 3 September 2020.
Copyright Notice
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
Moskowitz, et al. Expires 3 September 2020 [Page 1]
Internet-Draft CS-RID March 2020
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Draft Status . . . . . . . . . . . . . . . . . . . . . . 3
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Meeting the needs of Network ID . . . . . . . . . . . . . 5
3.2. Trustworthiness of Proxied Data . . . . . . . . . . . . . 6
3.3. Defense against fraudulent RID Messages . . . . . . . . . 6
4. The Finder - SPDP Security Relationship . . . . . . . . . . . 6
5. The CS-RID Messages . . . . . . . . . . . . . . . . . . . . . 7
5.1. CS-RID MESSAGE TYPE . . . . . . . . . . . . . . . . . . . 7
5.2. The CS-RID B-RID Proxy Message . . . . . . . . . . . . . 7
5.2.1. CS-RID ID . . . . . . . . . . . . . . . . . . . . . . 8
5.3. CS-RID Finder Registration . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7.1. Privacy Concerns . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
9. Normative References . . . . . . . . . . . . . . . . . . . . 9
10. Informative References . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
This document defines a mechanism to capture the ASTM Broadcast
Remote ID messages (B-RID) [WK65041] 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, 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.
Moskowitz, et al. Expires 3 September 2020 [Page 2]
Internet-Draft CS-RID March 2020
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).
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.
1.1. Draft Status
This draft was pushed out, in a largely raw state to meet the FAA's
NPRM for "Remote Identification of Unmanned Aircraft Systems" comment
filing deadline of March 2, 2020.
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 3 September 2020 [Page 3]
Internet-Draft CS-RID March 2020
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.
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
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.
Moskowitz, et al. Expires 3 September 2020 [Page 4]
Internet-Draft CS-RID March 2020
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 commerical 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
3.1. Meeting the needs of Network ID
The Federal (US) Aviation Authority (FAA), in the December 31, 2019
Remote ID Notice of Proposed Rulemaking (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
Moskowitz, et al. Expires 3 September 2020 [Page 5]
Internet-Draft CS-RID March 2020
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.
3.2. Trustworthiness of Proxied Data
When a proxy is introduced in any communication protocol, there is a
risk of corrupted data and DOS attacks.
3.3. Defense against fraudulent RID Messages
TBD
TBD
4. The Finder - SPDP Security Relationship
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 there 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.
1. ECIES can be used with a unique nonce to authenticate each
message sent from a Finder to the SPDP.
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 SPDP sent during that period.
3. HIPv2 [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 SPDP.
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 SPDP.
Moskowitz, et al. Expires 3 September 2020 [Page 6]
Internet-Draft CS-RID March 2020
5. The CS-RID Messages
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.
5.1. CS-RID MESSAGE TYPE
The CS-RID MESSAGE TYPE is:
Number CS-RID Message Type
------ -----------------
0 Reserved
1 B-RID Forwarding
2 Finder Registration
5.2. The CS-RID B-RID Proxy Message
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.
Moskowitz, et al. Expires 3 September 2020 [Page 7]
Internet-Draft CS-RID March 2020
( CS-RID MESSAGE TYPE,
CS-RID ID,
RECEIVE TIMESTAMP,
RECEIVE GPS,
RECEIVE RADIO TYPE,
B-RID MAC ADDRESS,
B-RID MESSAGE,
CS-RID MAC)
TBD
5.2.1. CS-RID ID
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.
5.3. CS-RID Finder Registration
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 MAC)
6. IANA Considerations
TBD
7. Security Considerations
TBD
Moskowitz, et al. Expires 3 September 2020 [Page 8]
Internet-Draft CS-RID March 2020
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. 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>.
10. Informative References
[hhit-registries]
Moskowitz, R., Card, S., and A. Wiethuechter,
"Hierarchical HIT Registries", Work in Progress, Internet-
Draft, draft-moskowitz-hip-hhit-registries-01, 17 October
2019, <https://tools.ietf.org/html/draft-moskowitz-hip-
hhit-registries-01>.
[hierarchical-hit]
Moskowitz, R., Card, S., and A. Wiethuechter,
"Hierarchical HITs for HIPv2", Work in Progress, Internet-
Draft, draft-moskowitz-hip-hierarchical-hit-03, 16
December 2019, <https://tools.ietf.org/html/draft-
moskowitz-hip-hierarchical-hit-03>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[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
Moskowitz, et al. Expires 3 September 2020 [Page 9]
Internet-Draft CS-RID March 2020
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>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>.
[tmrid-auth]
Wiethuechter, A., Card, S., and R. Moskowitz, "TM-RID
Authentication Formats", Work in Progress, Internet-Draft,
draft-wiethuechter-tmrid-auth-05, 18 February 2020,
<https://tools.ietf.org/html/draft-wiethuechter-tmrid-
auth-05>.
[WK65041] ASTM, "Standard Specification for Remote ID and Tracking",
September 2019.
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
Moskowitz, et al. Expires 3 September 2020 [Page 10]
Internet-Draft CS-RID March 2020
4947 Commercial Drive
Yorkville, NY 13495
United States of America
Email: adam.wiethuechter@axenterprize.com
Moskowitz, et al. Expires 3 September 2020 [Page 11]
