Crowd Sourced Remote IDHTT ConsultingOak ParkMI48237USArgm@labs.htt-consult.comAX Enterprize4947 Commercial DriveYorkvilleNY13495USAstu.card@axenterprize.comAX Enterprize4947 Commercial DriveYorkvilleNY13495USAadam.wiethuechter@axenterprize.comTencent2747 Park BlvdPalo AltoCA94306USAshuai.zhao@ieee.orgFraunhofer SITRheinstrasse 75Darmstadt64295Germanyhenk.birkholz@sit.fraunhofer.de
Internet
DRIPRFCThis 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
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.This document defines a mechanism to capture the ASTM Broadcast
Remote ID messages (B-RID) on any
Internet connected device that receives
them and can forward them to the SDSP(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
requirements 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 SDSP and which to drop. The SDSP will make any
filtering decisions in what it forwards to the UTM(s).Finders can be smartphones, tablets, connected cars, or any
computing platform with Internet connectivity that can meet the
requirements defined in this document. It is not expected, nor
necessary, that Finders have any information about a UAS beyond the
content in the B-RID messages.Finders MAY only need a loose association with the 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, 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.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 this 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 to the UTM(s). Further, the SDSP 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 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 draft is still incomplete. New features are being added as
capabilities are researched. The actual message formats also still
need work.The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL
NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”,
“MAY”, and “OPTIONAL” in this document are to be interpreted as
described in BCP 14 when, and only when, they
appear in all capitals, as shown here.
Broadcast Remote ID. A method of sending RID messages as
1-way transmissions from the UA to any Observers within
radio range.
Civil Aeronautics Administration. An example is the Federal
Aviation Administration (FAA) in the United States of
America.
Detect and Avoid. The process of a UA detecting obstacles,
like other UAs and taking the necessary evasive action.
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.
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.
In Internet connected device that can receive B-RID
messages and forward them to a UTM.
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 (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.
Network RID Service Provider. USS receiving Network RID
messages from UAS (UA or GCS), storing for a short
specified time, making available to 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.
Network Remote ID. A method of sending RID messages via the
Internet connection of the UAS directly to the UTM.
Remote ID. A unique identifier found on all UA to be used
in communication and in regulation of UA operation.
Supplemental Data Service Provider. Entity providing
information that is allowed, but not required to be present
in the UTM system.
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.
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.
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.
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).The Federal (US) Aviation Authority (FAA), in the December 31, 2019
Remote ID Notice of Proposed Rulemaking , is requiring
“Standard” and “Limited” Remote
ID. Standard is when the UAS provides both Network and Broadcast
RID. Limited is when the UAS provides only Network RID. The FAA
has dropped their previous position on allowing for only Broadcast
RID. We can guess as to their reasons; they are not spelled out in
the NPRM. It may be that just B-RID does not meet the FAA’s
statutory UA tracking responsibility.The UAS vendors have commented that N-RID places considerable
demands on currently used UAS. For some UAS like RC planes,
meaningful N-RID (via the Pilot’s smartphone) are of limited value.
A mechanism that can augment B-RID to provide N-RID would help all
members of the UAS environment to provide safe operation and allow
for new applications.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.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 ). The
SDSP can compare the information from multiple Finders to isolate a
Finder sending fraudulent information. SDSPs can additionally
verify authenticated messages that follow .The SPDP can manage the number of Finders in an area (see
) to limit DOS attacks
from a group of clustered Finders.The strongest defense against fraudulent RID messages is to focus
on conforming messages. Unless this behavior is
mandated, SPDPs will have to use assorted algorithms to isolate
messages of questionable content.The SDSP(s) and Finders SHOULD use EDDSA keys as their
trusted Identities.
The public keys SHOULD be registered Hierarchical HITS,
and .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.ECIES can be used with a unique nonce to authenticate each
message sent from a Finder to the SDSP.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.HIPv2 can be used to
establish a session secret that is then used with ESP
to authenticate each message sent from a Finder to the SDSP.DTLS can be used to establish
a secure connection that is then used to authenticate each
message sent from a Finder to the SDSP.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.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.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 .
The CDDL specification is used for CS-RID message descriptionCS-RID MAC and COAP for the CS-RID protocol.The following is a general representation of the content in the
CS-RID messages.The CS-RID MESSAGE CONTENT varies by MESSAGE TYPE.The CS-RID MESSAGE TYPE is defined in :The overall CS-RID CDDL description is structured in . 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,
)
]]>The application context rule is defined in for
CS-RID application identification and version negotiation. "DRIP-CSRID",
? version => uint .size(1..2),
)
]]>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 .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.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.The CS-RID ID is the ID recognized by the SDSP. This may be an
HHIT Hierarchical HITs, or any ID used by the SDSP.The broadcast CS-RID proxy CDDL is defined in 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,
]
]]>The CS-RID Finder MAY use HIPv2 with
the SDSP 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 support are not used.When HIPv2 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 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:The CDDL for CS-RID Finder Registration is defined in tstr,
timestamp => tdate,
gps => gps-coordinates,
}
gps-coordinates = [
latitude : float,
longitude: float,
]
]]>The SDSP MAY respond to any Finder messages to instruct the Finder on its
behavior.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.The CDDL for CS-RID SDSP response is defined in 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",
)
]]>The Finder SHOULD provide regular location updates to the SDSP. The
interval is based on the Update Interval from 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.The CDDL for CS-RID Location update is defined in tstr,
timestamp => tdate,
gps => gps-coordinates,
}
gps-coordinates = [
latitude : float,
longitude: float,
]
]]>
; 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,
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,
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"
broadcast_mac_address = "broadcast_mac_address"
broadcast_message = "broadcast_message"
sdsp_id = "sdsp_id"
proxy_status_type = "proxy_status_type"
update_interval = "update_interval"
]]>TBDTBDTBDConcise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data StructuresThis document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Standard Specification for Remote ID and TrackingASTM InternationalFAA Remote ID Notice of Proposed Rule MakingFederal (US) Aviation AuthorityTM-RID Authentication FormatsThis document describes how to include trust into the proposed ASTM Remote ID specification defined in WK65041 by the F38 Committee under a Broadcast Remote ID (RID) scenario. It defines a few different message schemes (based on the authentication message) that can be used to assure past messages sent by a UA and also act as an assurance for UA trustworthiness in the absence of Internet connectivity at the receiving node.Hierarchical HITs for HIPv2This document describes using a hierarchical HIT to facilitate large deployments of managed devices. Hierarchical HITs differ from HIPv2 flat HITs by only using 64 bits for mapping the Host Identity, freeing 32 bits to bind in a hierarchy of Registering Entities that provide services to the consumers of hierarchical HITs.Hierarchical HIT RegistriesThis document describes using the registration protocol and registries to support hierarchical HITs (HHITs). New and existing HIP parameters are used to communicate Registry Policies and data about the HHIT device and the Registries. Further Registries are expected to provide RVS services for registered HHIT devices.The Constrained Application Protocol (CoAP)The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)This document specifies the use of Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP). DTLS provides communications privacy for applications that use datagram transport protocols and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. DCCP is a transport protocol that provides a congestion-controlled unreliable datagram service. [STANDARDS-TRACK]IP Encapsulating Security Payload (ESP)This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document obsoletes RFC 2406 (November 1998). [STANDARDS-TRACK]Host Identity Protocol Version 2 (HIPv2)This document specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Diffie-Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the-middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulating Security Payload (ESP), it provides integrity protection and optional encryption for upper-layer protocols, such as TCP and UDP.This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201.Concise Binary Object Representation (CBOR)The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.Edwards-Curve Digital Signature Algorithm (EdDSA)This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided.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.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?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.