UAS Remote ID
AX Enterprize
4947 Commercial Drive
Yorkville
NY
13495
USA
stu.card@axenterprize.com
AX Enterprize
4947 Commercial Drive
Yorkville
NY
13495
USA
adam.wiethuechter@axenterprize.com
HTT Consulting
Oak Park
MI
48237
USA
rgm@labs.htt-consult.com
Internet
TMRID
RFC
Request for Comments
I-D
Internet-Draft
HIP
TMRID
This document is an Applicability Statement for various IETF
Technical Specifications, including the Host Identity Protocol
(HIPv2) and the Domain Name System (DNS), complementing emerging
external standards for Unmanned Aircraft System (UAS) remote
identification (RID). The objectives are: to facilitate use of
existing Internet services to support UAS RID and to enable
enhanced RID related services; and to enable verification that
UAS RID information is trustworthy (to some extent, even in the
absence of Internet connectivity at the receiving node).
Emerging Civil Aviation Authority (CAA) regulations worldwide,
exemplified by current United States (US) Federal Aviation
Administration (FAA) rulemaking, will soon mandate, and many safety
and other considerations dictate (even absent regulations), that
Unmanned Aircraft Systems (UAS) be remotely identifiable. CAAs are
expected and FAA has stated its intent to require compliance with
industry consensus standards.
ASTM International, Technical Committee F38 (UAS), Subcommittee
F38.02 (Aircraft Operations), Work Item WK65041 (UAS Remote ID and
Tracking), is a Proposed New Standard . It
defines 2 means of UAS remote identification (RID): Network RID via
the Internet; and Broadcast RID via a one-way data link direct from
the Unmanned Aircraft (UA) to the observer's device. Network RID
depends upon Internet connectivity between the observer and either
the UA itself or any of various proxies. Broadcast RID should need
Internet (or other Wide Area Network) connectivity only for UAS
registry information lookup using the directly locally received UAS
ID as a key.
The need for near-universal deployment of UAS RID is pressing. This
implies the need to support use by observers of already ubiquitous
mobile devices (smartphones and tablets). UA onboard RID devices are
severely constrained in Size, Weight and Power (SWaP). Cost is a
significant impediment to the necessary near-universal adoption of
UAS send and observer receive RID capabilities. To accomodate the
most severely constrained cases, all these conspire to motivate
system design decisions, especially for the Broadcast RID data link,
which complicate the protocol design problem: one-way links;
extremely short packets; and Internet-disconnected operation of UA
onboard devices. Internet-disconnected operation of observer devices
has been deemed by ASTM F38.02 too infrequent to address, but for
some users is important and presents further challenges.
Heavyweight security protocols are infeasible, yet trustworthiness
of UAS RID information is essential. Even the most basic datum, the
UAS ID string (typically number) itself, under
, can be merely an unsubstantiated claim.
Further, an ID is not an end in itself; it exists to enable lookups
and provision of services complementing mere identification, e.g.
dynamic establishment of secure communications between the observer
and the UAS pilot. neither fully specifies
nor appears to facilitate these functions, especially in the case
where the observer lacks real time Internet access.
Finally, proposes the use of plaintext and
mostly static UAS ID strings. Even if lookup from these to operator
Personally Identifiable Information (PII) is successfully limited to
strongly authenticated personnel, properly authorized per policy:
static IDs enable trivial correlation of patterns of use,
unacceptable in many applications, e.g. package delivery routes of
competitors.
IETF can help by providing expertise as well as mature and evolving
standards. Host Identity Protocol (HIPv2)
and the Domain Name System (DNS) can
complement emerging external standards for UAS RID, to facilitate
utilization of existing and provision of enhanced network services,
and to enable verification that UAS RID information is trustworthy
(to some extent, even in the absence of Internet connectivity at the
receiving node).
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.
Civil Aviation Authority. An example is the Federal Aviation Administration (FAA) in the United States of America.
Command and Control. A set of organizational and technical attributes and processes that employs human, physical, and information resources to solve problems and accomplish missions. Mainly used in military contexts.
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.
Host Identity. The public key portion of an asymmetric keypair from HIP. In this document it is assumed that the HI is based on a EdDSA25519 keypair. This is supported by new crypto defined in .
Host Identity Tag. A 128 bit handle on the HI. Defined in HIPv2 .
Hierarchical Host Identity Tag. A HIT with extra information not found in a standard HIT. Defined in .
Unmanned Aircraft. Typically a military or commercial "drone" but can include any and all aircraft that are unmanned.
Unmanned Aircraft System. Composed of UA, 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 control station.
UAS Traffic Management. A "traffic management" ecosystem for "uncontrolled" UAS operations separate from, but complementary to, the FAA's Air Traffic Management (ATM) system for "controlled" operations of manned aircraft.
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).
Remote ID. System for identifying UA during flight by other parties.
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 ID.
Unique UAS identifier. Per , maximum length of 20 bytes.
Identifier type index. Per , 4 bits, values 0-3 already specified.
UAS RID Service Provider. System component that compiles information from various sources (and methods) in its given service area.
UAS RID Display Provider. System component that requests data from one or more RID SP and aggregates them to display to a user application on a device.
System component designed to handle the authentication requirements of RID by offloading verification to a web hosted service.
UA may be fixed wing Short Take-Off and Landing (STOL), rotary wing
(e.g. helicopter) Vertical Take-Off and Landing (VTOL), or hybrid.
They may be single engine or multi engine. The most common today are
multicopters: rotary wing, multi engine. The explosion in UAS was
enabled by hobbyist development, for multicopters, of advanced
flight stability algorithms, enabling even inexperienced pilots tp
take off, fly to a location of interest, hover, and return to the
take-off location or land at a distance. UAS can be remotely piloted
by a human (e.g. with a joystick) or programmed to proceed from
Global Positioning System (GPS) waypoint to waypoint in a weak form
of autonomy; stronger autonomy is coming. UA are "low observable":
they typically have a small radar cross section; they make noise
quite noticeable at short range but difficult to detect at distances
they can quickly close (500 meters in under 17 seconds at 60 knots);
they typically fly at low altitudes (for the small UAS to which RID
applies, under 400 feet Above Ground Level in the US); they are
highly maneuverable so can fly under trees and between buildings.
UA can carry payloads including sensors, cyber and kinetic weapons
or can be used themselves as weapons by flying them into targets.
They can be flown by clueless, careless or criminal operators. Thus
the most basic function of UAS RID is "Identification Friend or Foe"
to mitigate the significant threat they present. Numerous other
applications can be enabled or facilitated by RID: consider the
importance of identifiers in many Internet protocols and services.
Network RID from the UA itself (rather than from a proxy) and
Broadcast RID require one or more wireless data links from the UA,
but such communications are challenging due to $SWaP constraints and
low altitude flight amidst structures and foliage over terrain.
Network RID has several variants. The UA may have persistent onboard
Internet connectivity, in which case it can consistently source RID
information directly over the Internet. The UA may have intermittent
onboard Internet connectivity, in which case a proxy must source RID
information whenever the UA itself is offline. The UA may not have
Internet connectivity of its own, but have instead some other form
of communications to a (typically ground) node that can relay RID
information to the Internet; this would typically be the GCS (which
to perform its function must know where the UA is) or USS (which in
the UTM system is required to be kept informed by the UAS operator).
The UA may have no means of sourcing RID information, in which case
the GCS, USS or other proxy may source it. In the extreme case, this
would be the pilot using a web browser to designate, to a USS or
other UTM entity, a time-bounded airspace volume in which an
operation will be conducted; this may impede disambiguation of ID if
multiple UAS operate in the same or overlapping spatio-temporal
volumes.
In most cases in the near term, if the RID information is
fed to the Internet directly by the UA or remote pilot, the first
hop data links will be cellular Long Term Evolution (LTE) or WiFi,
but provided the data link can support at least IP and ideally TCP,
its type is generally immaterial to the higher layer protocols. The
ultimate source of Network RID information feeds a RID Service
Provider (SP), which essentially proxies for that and other sources;
the ultimate consumer of Network RID information obtains it from a
RID Display Provider (DP). Each DP aggregates information from all
SPs that have UA currently operating in the airspace for which that
DP is cognizant.
Network RID is the more flexible and less constrained of the UAS RID
means specified in . Any IETF work needed
to support or leverage it is left for later efforts; it is not
further addressed herein or in other initial tm-rid documents.
specifies 3 Broadcast RID data links:
Bluetooth 4.X; Bluetooth 5.X Long Range; and Wifi with Neighbor
Awareness Networking (NAN). For compliance with this standard, an UA
must broadcast (using advertisement mechanisms where no other option
supports broadcast) on at least one of these; if broadcasting on
Bluetooth 5.x, it is also required concurrently to do so on 4.x
(referred to in as Bluetooth Legacy).
The selection of the Broadcast medium was driven by research into
what is commonly available on 'ground' units (smartphones and
tablets) and what was found as prevalent or 'affordable' in UA.
Further, there must be an API for the UAS receiving application to
have access to these messages. At this time, only Bluetooth 4.X
support is readily available, thus the current focus is on working
within the 26 byte limit of the Bluetooth 4.X "Broadcast Frame" that
goes out on the beacon channels.
Finally, the 26 byte limit of the Bluetooth 4.1 "Broadcast Frame"
strictly enforces the RID maximum length of 20 bytes.
TM-RID will focus on adding immediate usability, thus trust to,
Broadcast RID. The one-way nature of Broadcast RID precludes any
stateful security protocol. Under , any UA
can announce a RID and an observer would be seriously challenged to
validate it or any other information about the UA looked up from it.
Thus providing trust in the RID and related trust for all Broadcast
messages is critical for the safe and secure operation of UAs.
Three levels of functionality will be considered:
1 verify that HHIT is duly registered with a known registry AND
that any messages signed with its key came from it;
2 look up not only static UAS registry and dynamic UTM information
but also Intenet direct contact information for services relating to
the UA, its current mission, etc., including communications with the
remote pilot (or proxy) and USS;
3 dynamically establish strongly mutually authenticated, E2E
strongly encrypted communications with the UAS RID sender and
entities looked up via (2) above.
Just a couple of requirements:
The ID MUST be 20 bytes or smaller.
It MUST be non-spoofable within the context of Remote ID
broadcast messages (some collection of messages provides proof
of UA ownership of ID).
In context (that is in a Remote ID Broadcast message), just the
ID provides enough information on how at least the observer's
USS (UAS Service Provider / Display Provider) can provide both public and private
information on the UAS.
Now a little 'context' setting. ASTM has already defined a set of
textual Remote IDs:
Serial Number
CAA Assigned ID
UTM Assigned ID
The work here MUST surpass these in terms of Trustworthiness.
The options found are:
X.509 certs where something like the cert sequenceNumber is the
Remote ID.
Naming Things with Hashes, Section 8.2 of
SSH keyID
HIT (Host Identity Tag)
Option 1 is no better than what ASTM/FAA is considering for any of
the current proposed types. Somehow, there will be a PKI and from
that knowledge of the UAS is gained. This REQUIRES Internet Access
(think disaster or other non-Internet situations) and a GLOBAL PKI
(the UA flew from Canada to the US or UK to France post Brexit).
Option 2 meets requirements 1 and 2, but needs to be augmented so
that the Hash provides context for 3. Is it supported for IPsec
and/or QUIC for UAS/observer secure communications (NetworkID).
It is likely that an IPv6 prefix will be needed for the HHIT (or
other identifier) space; this will be specified in other drafts.
UAS RID is all about safety and security, so content pertaining to
such is not limited to this section. UAS RID information must be
divided into 2 classes: that which, to achieve the purpose, must be
published openly in plaintext, for the benefit of any observer; and
that which must be protected (e.g. PII of pilots) but made available
to properly authorized parties (e.g. public safety personnel who
urgently need to contact pilots in emergencies). Details of the
protection mechanisms will be provided in other drafts. Classifying
the information will be addressed primarily in external standards
but also herein as needed.
The work of the FAA's UAS Identification and Tracking (UAS ID)
Aviation Rulemaking Committee (ARC) is the foundation of later ASTM
and proposed IETF efforts. The work of ASTM F38.02 in balancing the
interests of diverse stakeholders is essential to the necessary
rapid and widespread deployment of UAS RID.
Small Unmanned Aerial Systems Serial Numbers
ANSI
Standard Specification for Remote ID and Tracking
ASTM