draft-ietf-drip-reqs-05.txt   draft-ietf-drip-reqs-06.txt 
DRIP S. Card, Ed. DRIP S. Card, Ed.
Internet-Draft A. Wiethuechter Internet-Draft A. Wiethuechter
Intended status: Informational AX Enterprize Intended status: Informational AX Enterprize
Expires: 19 April 2021 R. Moskowitz Expires: 5 May 2021 R. Moskowitz
HTT Consulting HTT Consulting
A. Gurtov A. Gurtov
Linköping University Linköping University
16 October 2020 1 November 2020
Drone Remote Identification Protocol (DRIP) Requirements Drone Remote Identification Protocol (DRIP) Requirements
draft-ietf-drip-reqs-05 draft-ietf-drip-reqs-06
Abstract Abstract
This document defines terminology and requirements for Drone Remote This document defines terminology and requirements for Drone Remote
Identification Protocol (DRIP) Working Group protocols to support Identification Protocol (DRIP) Working Group protocols to support
Unmanned Aircraft System Remote Identification and tracking (UAS RID) Unmanned Aircraft System Remote Identification and tracking (UAS RID)
for security, safety and other purposes. Complementing external for security, safety and other purposes. Complementing external
technical standards as regulator-accepted means of compliance with technical standards as regulator-accepted means of compliance with
UAS RID regulations, DRIP will: UAS RID regulations, DRIP will:
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 19 April 2021. This Internet-Draft will expire on 5 May 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as 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 Simplified BSD License.
Table of Contents Table of Contents
1. Introduction (Informative) . . . . . . . . . . . . . . . . . 2 1. Introduction (Informative) . . . . . . . . . . . . . . . . . 2
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Concerns and Constraints . . . . . . . . . . . . . . . . 6 1.2. Concerns and Constraints . . . . . . . . . . . . . . . . 6
1.3. DRIP Scope . . . . . . . . . . . . . . . . . . . . . . . 7 1.3. DRIP Scope . . . . . . . . . . . . . . . . . . . . . . . 8
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 8 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 8
2.1. Requirements Terminology . . . . . . . . . . . . . . . . 8 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 8
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 9
3. UAS RID Problem Space . . . . . . . . . . . . . . . . . . . . 16 3. UAS RID Problem Space . . . . . . . . . . . . . . . . . . . . 16
3.1. Network RID . . . . . . . . . . . . . . . . . . . . . . . 17 3.1. Network RID . . . . . . . . . . . . . . . . . . . . . . . 18
3.2. Broadcast RID . . . . . . . . . . . . . . . . . . . . . . 19 3.2. Broadcast RID . . . . . . . . . . . . . . . . . . . . . . 20
3.3. DRIP Focus . . . . . . . . . . . . . . . . . . . . . . . 22 3.3. USS in UTM and RID . . . . . . . . . . . . . . . . . . . 22
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 22 3.4. DRIP Focus . . . . . . . . . . . . . . . . . . . . . . . 23
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 22 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2. Identifier . . . . . . . . . . . . . . . . . . . . . . . 24 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.2. Identifier . . . . . . . . . . . . . . . . . . . . . . . 26
4.4. Registries . . . . . . . . . . . . . . . . . . . . . . . 26 4.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 27
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 4.4. Registries . . . . . . . . . . . . . . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
7. Privacy and Transparency Considerations . . . . . . . . . . . 29 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 7. Privacy and Transparency Considerations . . . . . . . . . . . 30
8.1. Normative References . . . . . . . . . . . . . . . . . . 29 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
8.2. Informative References . . . . . . . . . . . . . . . . . 30 8.1. Normative References . . . . . . . . . . . . . . . . . . 31
Appendix A. Discussion and Limitations . . . . . . . . . . . . . 32 8.2. Informative References . . . . . . . . . . . . . . . . . 31
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 33 Appendix A. Discussion and Limitations . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction (Informative) 1. Introduction (Informative)
1.1. Motivation 1.1. Motivation
Many considerations (especially safety and security) necessitate Many considerations (especially safety and security) necessitate
Unmanned Aircraft Systems (UAS) Remote Identification and tracking Unmanned Aircraft Systems (UAS) Remote Identification and tracking
(RID). (RID).
Unmanned Aircraft (UA) may be fixed wing Short Take-Off and Landing Unmanned Aircraft (UA) may be fixed wing, rotary wing (e.g.,
(STOL), rotary wing (e.g., helicopter) Vertical Take-Off and Landing helicopter), hybrid, balloon, rocket, etc. Small fixed wing UA
(VTOL), or hybrid. They may be single- or multi-engine. The most typically have Short Take-Off and Landing (STOL) capability; rotary
wing and hybrid UA typically have Vertical Take-Off and Landing
(VTOL) capability. UA may be single- or multi-engine. The most
common today are multicopters: rotary wing, multi engine. The common today are multicopters: rotary wing, multi engine. The
explosion in UAS was enabled by hobbyist development, for explosion in UAS was enabled by hobbyist development, for
multicopters, of advanced flight stability algorithms, enabling even multicopters, of advanced flight stability algorithms, enabling even
inexperienced pilots to take off, fly to a location of interest, inexperienced pilots to take off, fly to a location of interest,
hover, and return to the take-off location or land at a distance. 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 UAS can be remotely piloted by a human (e.g., with a joystick) or
programmed to proceed from GNSS waypoint to waypoint in a weak form programmed to proceed from GNSS waypoint to waypoint in a weak form
of autonomy; stronger autonomy is coming. UA are "low observable": of autonomy; stronger autonomy is coming. UA are "low observable":
they typically have small radar cross sections; they make noise quite they typically have small radar cross sections; they make noise quite
noticeable at short range but difficult to detect at distances they noticeable at short range but difficult to detect at distances they
skipping to change at page 5, line 37 skipping to change at page 5, line 37
An ID is not an end in itself; it exists to enable lookups and An ID is not an end in itself; it exists to enable lookups and
provision of services complementing mere identification. provision of services complementing mere identification.
Using UAS RID to facilitate vehicular (V2X) communications and Using UAS RID to facilitate vehicular (V2X) communications and
applications such as Detect And Avoid (DAA), which would impose applications such as Detect And Avoid (DAA), which would impose
tighter latency bounds than RID itself, is an obvious possibility, tighter latency bounds than RID itself, is an obvious possibility,
explicitly contemplated in the United States (US) Federal Aviation explicitly contemplated in the United States (US) Federal Aviation
Administration (FAA) Notice of Proposed Rule Making [NPRM]. However, Administration (FAA) Notice of Proposed Rule Making [NPRM]. However,
applications of RID beyond RID itself, including DAA, have been applications of RID beyond RID itself, including DAA, have been
explicitly declared out of scope in ASTM International, Technical declared out of scope in ASTM International, Technical Committee F38
Committee F38 (UAS), Subcommittee F38.02 (Aircraft Operations), Work (UAS), Subcommittee F38.02 (Aircraft Operations), Work Item WK65041
Item WK65041, working group discussions, based on a distinction (source of the widely cited [F3411-19]), based on a distinction
between RID as a security standard vs DAA as a safety application. between RID as a security standard vs DAA as a safety application.
Although dynamic establishment of secure communications between the Although dynamic establishment of secure communications between the
Observer and the UAS pilot seems to have been contemplated by the FAA Observer and the UAS pilot seems to have been contemplated by the FAA
UAS ID and Tracking Aviation Rulemaking Committee (ARC) in their UAS ID and Tracking Aviation Rulemaking Committee (ARC) in their
[Recommendations], it is not addressed in any of the subsequent [Recommendations], it is not addressed in any of the subsequent
proposed regulations or technical specifications. proposed regulations or technical specifications.
[Opinion1] and [WG105] cite the Direct Remote Identification [Opinion1] and [WG105] cite the Direct Remote Identification
previously required and specified, explicitly stating that whereas previously required and specified, explicitly stating that whereas
Direct RID is primarily for security purposes, "Electronic Direct RID is primarily for security purposes, "Electronic
skipping to change at page 6, line 25 skipping to change at page 6, line 25
which they can then report to authorities; enable authorities, from which they can then report to authorities; enable authorities, from
such an ID, to look up information about the UAS and its operator. such an ID, to look up information about the UAS and its operator.
Safety oriented UAS RID has stronger requirements. Aviation Safety oriented UAS RID has stronger requirements. Aviation
community SDOs set a higher bar for safety than for security, community SDOs set a higher bar for safety than for security,
especially with respect to reliability. especially with respect to reliability.
1.2. Concerns and Constraints 1.2. Concerns and Constraints
Disambiguation of multiple UA flying in close proximity may be very Disambiguation of multiple UA flying in close proximity may be very
challenging, even if each is reporting its identity, position and challenging, even if each is reporting its identity, position and
velocity as accurately as it can. As the origin of all information velocity as accurately as it can.
in UAS RID is self-reports from operators, there are possibilities
not only of unintentional error, but also of intentional The origin of all information in UAS RID is operator self-reports.
falsification, of this data. Reports may be initiated by the remote pilot at the Ground Control
Station (GCS) console, by a software process on the GCS, or by a
process on the UA. Data in the reports may come from the UA (e.g.
an on-board GNSS receiver), the GCS (e.g. dead reckoning UA location
based on takeoff location and piloting commands given since takeoff)
and/or sensors available to the operator (e.g. radar or cameras).
Whether information comes proximately from the operator, or from
automated systems configured by the operator, there are possibilities
not only of unintentional error in, but also of intentional
falsification of, this data.
Minimal specified information must be made available to the public; Minimal specified information must be made available to the public;
access to other data, e.g., UAS operator Personally Identifiable access to other data, e.g., UAS operator Personally Identifiable
Information (PII), must be limited to strongly authenticated Information (PII), must be limited to strongly authenticated
personnel, properly authorized per policy. The balance between personnel, properly authorized per policy. The balance between
privacy and transparency remains a subject for public debate and privacy and transparency remains a subject for public debate and
regulatory action; DRIP can only offer tools to expand the achievable regulatory action; DRIP can only offer tools to expand the achievable
trade space and enable trade-offs within that space. [F3411-19] trade space and enable trade-offs within that space. [F3411-19], the
basis for most current thinking about and efforts to provide UAS RID,
specifies only how to get the UAS ID to the Observer: how the specifies only how to get the UAS ID to the Observer: how the
Observer can perform these lookups, and how the registries first can Observer can perform these lookups, and how the registries first can
be populated with information, is unspecified. be populated with information, is unspecified therein.
The need for near-universal deployment of UAS RID is pressing. This The need for near-universal deployment of UAS RID is pressing. This
implies the need to support use by Observers of already ubiquitous implies the need to support use by Observers of already ubiquitous
mobile devices (typically smartphones and tablets). Anticipating mobile devices (typically smartphones and tablets). Anticipating
likely CAA requirements to support legacy devices, especially in likely CAA requirements to support legacy devices, especially in
light of [Recommendations], [F3411-19] specifies that any UAS sending light of [Recommendations], [F3411-19] specifies that any UAS sending
Broadcast RID over Bluetooth must do so over Bluetooth 4, regardless Broadcast RID over Bluetooth must do so over Bluetooth 4, regardless
of whether it also does so over newer versions; as UAS sender devices of whether it also does so over newer versions; as UAS sender devices
and Observer receiver devices are unpaired, this implies extremely and Observer receiver devices are unpaired, this implies extremely
short "advertisement" (beacon) frames. short "advertisement" (beacon) frames.
skipping to change at page 9, line 9 skipping to change at page 9, line 23
Aircraft System (singular) and Unmanned Aircraft Systems (plural) are Aircraft System (singular) and Unmanned Aircraft Systems (plural) are
both represented as UAS. On this and other terminological issues, to both represented as UAS. On this and other terminological issues, to
encourage comprehension necessary for adoption of DRIP by the encourage comprehension necessary for adoption of DRIP by the
intended user community, that community's norms are respected herein, intended user community, that community's norms are respected herein,
and definitions are quoted in cases where they have been found in and definitions are quoted in cases where they have been found in
that community's documents. Most of the listed terms are from that that community's documents. Most of the listed terms are from that
community (even if specific source documents are not cited); any that community (even if specific source documents are not cited); any that
are DRIP-specific or invented by the authors of this document are are DRIP-specific or invented by the authors of this document are
marked "(DRIP)". marked "(DRIP)".
4-D
Four-dimensional. Latitude, Longitude, Altitude, Time. Used
especially to delineate an airspace volume in which an operation
is being or will be conducted.
AAA AAA
Attestation, Authentication, Authorization, Access Control, Attestation, Authentication, Authorization, Access Control,
Accounting, Attribution, Audit, or any subset thereof (uses differ Accounting, Attribution, Audit, or any subset thereof (uses differ
by application, author and context). (DRIP) by application, author and context). (DRIP)
ABDAA ABDAA
AirBorne DAA. Accomplished using systems onboard the aircraft AirBorne DAA. Accomplished using systems onboard the aircraft
involved. Supports "self-separation" (remaining "well clear" of involved. Supports "self-separation" (remaining "well clear" of
other aircraft) and collision avoidance. other aircraft) and collision avoidance.
skipping to change at page 10, line 26 skipping to change at page 10, line 45
CAA CAA
Civil Aviation Authority. Two examples are the United States Civil Aviation Authority. Two examples are the United States
Federal Aviation Administration (FAA) and the Japan Civil Aviation Federal Aviation Administration (FAA) and the Japan Civil Aviation
Bureau. Bureau.
CSWaP CSWaP
Cost, Size, Weight and Power. Cost, Size, Weight and Power.
C2 C2
Command and Control. Previously mostly used in military contexts. Command and Control. Previously mostly used in military contexts.
In the UAS context, typically refers to the RF data link over Properly refers to a function, exercisable over arbitrary
which the GCS controls the UA. communications; but in the small UAS context, often refers to the
communications (typically RF data link) over which the GCS
controls the UA.
DAA DAA
Detect And Avoid, formerly Sense And Avoid (SAA). A means of Detect And Avoid, formerly Sense And Avoid (SAA). A means of
keeping aircraft "well clear" of each other and obstacles for keeping aircraft "well clear" of each other and obstacles for
safety. "The capability to see, sense or detect conflicting safety. "The capability to see, sense or detect conflicting
traffic or other hazards and take the appropriate action to comply traffic or other hazards and take the appropriate action to comply
with the applicable rules of flight." [ICAOUAS] with the applicable rules of flight." [ICAOUAS]
Direct RID Direct RID
Direct Remote Identification. "a system that ensures the local Direct Remote Identification. "a system that ensures the local
broadcast of information about a UA in operation, including the broadcast of information about an UA in operation, including the
marking of the UA, so that this information can be obtained marking of the UA, so that this information can be obtained
without physical access to the UA". [Delegated] Corresponds without physical access to the UA". [Delegated] Corresponds
roughly to the Broadcast RID portion of [NPRM] Standard RID. roughly to the Broadcast RID portion of [NPRM] Standard RID.
DSS DSS
Discovery and Synchronization Service. Formerly Inter-USS. The Discovery and Synchronization Service. Formerly Inter-USS. The
UTM system overlay network backbone. Most importantly, it enables UTM system overlay network backbone. Most importantly, it enables
one USS to learn which other USS have UAS operating in a given 4-D one USS to learn which other USS have UAS operating in a given 4-D
airspace volume, for deconfliction of planned and Network RID airspace volume, for deconfliction of planned and Network RID
surveillance of active operations. [F3411-19] surveillance of active operations. [F3411-19]
skipping to change at page 17, line 35 skipping to change at page 18, line 7
used only once as a "Session ID" (for a single UAS flight, which in used only once as a "Session ID" (for a single UAS flight, which in
the context of UTM is called an "operation"). Per [Delegated], the the context of UTM is called an "operation"). Per [Delegated], the
EU also requires an operator registration number (an additional EU also requires an operator registration number (an additional
identifier distinct from the UAS ID) that can be carried in an identifier distinct from the UAS ID) that can be carried in an
[F3411-19] optional Operator ID message. Per [NPRM], the US allows [F3411-19] optional Operator ID message. Per [NPRM], the US allows
but does not require that operator registration numbers be sent. As but does not require that operator registration numbers be sent. As
yet apparently there are no CAA public proposals to use Type 2. yet apparently there are no CAA public proposals to use Type 2.
3.1. Network RID 3.1. Network RID
x x UA x x UA
xxxxx ******************** xxxxxxx
| * ------*---+------------+ | \
| * / * | NET_Rid_SP | | \
| \
| \ ********************
| \* ------*---+------------+
| *\ / * | NET_Rid_SP |
| * ------------/ +---*--+------------+ | * ------------/ +---*--+------------+
| RF */ | * | RF */ | *
| * INTERNET | * +------------+ | / INTERNET | * +------------+
| /* +---*--| NET_Rid_DP | | /* +---*--| NET_Rid_DP |
| / * +----*--+------------+ | / * +----*--+------------+
+ / * | * + / * | *
x / ****************|*** x x / ****************|*** x
xxxxx | xxxxx xxxxx | xxxxx
x +------- x x +------- x
x x x x
x x Operator's GCS Observer x x x x Operator's GCS Observer x x
x x x x x x x x
Figure 3: "Network RID Information Flow" Figure 3: "Network RID Information Flow"
Note the data flow typically originates on or at least passes through Only two of the three links UA-GCS, UA-Internet and GCS-Internet need
the Ground Control Station (GCS), rather than comes direct from the exist, although all three may. There must be some path (direct or
UA as in Broadcast RID (below), and makes up to 3 trips through the indirect) between the GCS and the UA, for the former to exercise C2
Internet, implying use of IP (and other middle layer protocols) on over the latter; if this path is two-way (as increasingly it is, even
those trips, but not necessarily on the UA-GCS link (if indeed the for inexpensive small UAS), the UA will also send its status (and
Network RID data even flows across that link). position, if suitably equipped) information to the GCS. There must
be some path between at least one subsystem of the UAS (UA or GCS)
and the Internet, for the former to send status and position updates
to its USS (serving _inter alia_ as Net-RID SP.
Network RID is essentially publish-subscribe-query. In the typical Currently, the RID data flow typically originates on the UA and
UTM context... First the UAS operator pushes an operation plan to the passes through the GCS, or originates on the GCS, rather than comes
USS that will serve that UAS for that operation, for deconfliction direct from the UA as in Broadcast RID (below), and makes up to three
with other operations. Assuming the plan receives approval and the trips through the Internet, implying use of IP (and other middle
operation commences, that UAS periodically pushes location/status layer protocols) on those trips, but not necessarily on an UA-GCS
updates to that USS (call it USS#1), which serves as the Network RID link (if indeed that direct even exists and further the Network RID
Service Provider (Net-RID SP) for that operation. If users of any data flows across it).
other USS (whether they be other UAS operators or Observers) develop
an interest in any 4-D airspace volume intersecting the 4-D volume Network RID is publish-subscribe-query. In the UTM context:
containing that UAS operation, they query their own USS (call them
USS#2 through USS#n). Their USS query, via the UTM Discovery and 1. The UAS operator pushes an "operational intent" (the current term
Synchronization Service (DSS), all other USS in the UTM system, and in UTM corresponding to a flight plan in manned aviation) to the
learn that USS#1 has such operations. Observers or other interested USS (call it USS#1) that will serve that UAS (call it UAS#1) for
parties can then subscribe to track updates, via their own USS, which that operation, primarily to enable deconfliction with other
serve as Network RID Display Providers (Net-RID DP) for that operations potentially impinging upon that operation's 4-D
surveillance session. The Net-RID SP (USS#1) will then publish airspace volume (call it Volume#1).
updates of the UAS position/status to all subscribed Net-RID DP
(USS#2 through USS#n), which in turn will deliver the information to 2. Assuming the operation is approved and commences, UAS #1
their users via unspecified (but expected to be web browser based) periodically pushes location/status updates to USS#1, which
means. serves _inter alia_ as the Network RID Service Provider (Net-RID
SP) for that operation.
3. When users of any other USS (whether they be other UAS operators
or Observers) develop an interest in any 4-D airspace volume
(e.g. because they wish to submit an operational intent or
because they have observed an UA), they query their own USS on
the volumes in which they are interested.
4. Their USS query, via the UTM Discovery and Synchronization
Service (DSS), all other USS in the UTM system, and learn of any
USS that have operations in those volumes (including any volumes
intersecting them); thus those USS whose query volumes intersect
Volume#1 (call them USS#2 through USS#n) learn that USS#1 has
such operations.
5. Interested parties can then subscribe to track updates on that
operation of UAS#1, via their own USS, which serve as Network RID
Display Providers (Net-RID DP) for that operation.
6. USS#1 (as Net-RID SP) will then publish updates of UAS#1 status
and position to all other subscribed USS in USS#2 through USS#n
(as Net-RID DP).
7. All Net-RID DP subscribed to that operation of UAS#1 will deliver
its track information to their users who subscribed to that
operation of UAS#1, via unspecified (generally presumed to be web
browser based) means.
Network RID has several variants. The UA may have persistent onboard Network RID has several variants. The UA may have persistent onboard
Internet connectivity, in which case it can consistently source RID Internet connectivity, in which case it can consistently source RID
information directly over the Internet. The UA may have intermittent information directly over the Internet. The UA may have intermittent
onboard Internet connectivity, in which case the GCS must source RID onboard Internet connectivity, in which case the GCS must source RID
information whenever the UA itself is offline. The UA may not have information whenever the UA itself is offline. The UA may not have
Internet connectivity of its own, but have instead some other form of Internet connectivity of its own, but have instead some other form of
communications to another node that can relay RID information to the communications to another node that can relay RID information to the
Internet; this would typically be the GCS (which to perform its Internet; this would typically be the GCS (which to perform its
function must know where the UA is, although C2 link outages do function must know where the UA is, although C2 link outages do
occur). occur).
The UA may have no means of sourcing RID information, in which case The UA may have no means of sourcing RID information, in which case
the GCS must source it; this is typical under FAA NPRM Limited RID the GCS must source it; this is typical under FAA NPRM Limited RID
proposed rules, which require providing the location of the GCS (not proposed rules, which require providing the location of the GCS (not
that of the UA). In the extreme case, this could be the pilot using that of the UA). In the extreme case, this could be the pilot using
a web browser/application to designate, to an UAS Service Supplier a web browser/application to designate, to an UAS Service Supplier
(USS) or other UTM entity, a time-bounded airspace volume in which an (USS) or other UTM entity, a time-bounded airspace volume in which an
operation will be conducted; this may impede disambiguation of ID if operation will be conducted; this may impede disambiguation of ID if
multiple UAS operate in the same or overlapping spatio-temporal multiple UAS operate in the same or overlapping 4-D volumes.
volumes.
In most cases in the near term, if the RID information is fed to the In most cases in the near term, if the RID information is fed to the
Internet directly by the UA or GCS, the first hop data links will be Internet directly by the UA or GCS, the first hop data links will be
cellular Long Term Evolution (LTE) or Wi-Fi, but provided the data cellular Long Term Evolution (LTE) or Wi-Fi, but provided the data
link can support at least UDP/IP and ideally also TCP/IP, its type is link can support at least UDP/IP and ideally also TCP/IP, its type is
generally immaterial to the higher layer protocols. An UAS as the generally immaterial to the higher layer protocols. An UAS as the
ultimate source of Network RID information feeds an USS acting as a ultimate source of Network RID information feeds an USS acting as a
Network RID Service Provider (Net-RID SP), which essentially proxies Network RID Service Provider (Net-RID SP), which essentially proxies
for that and other sources; an observer or other ultimate consumer of for that and other sources; an observer or other ultimate consumer of
Network RID information obtains it from a Network RID Display Network RID information obtains it from a Network RID Display
skipping to change at page 19, line 42 skipping to change at page 20, line 41
UAS RID means, but is only partially specified in [F3411-19]. It is UAS RID means, but is only partially specified in [F3411-19]. It is
presumed that IETF efforts supporting Broadcast RID (see next presumed that IETF efforts supporting Broadcast RID (see next
section) can be easily generalized for Network RID. section) can be easily generalized for Network RID.
3.2. Broadcast RID 3.2. Broadcast RID
x x UA x x UA
xxxxx xxxxx
| |
| |
| app messages directly over one-way RF data link (no IP) | app messages directly over one-way RF data link
| |
| |
+ +
x x
xxxxx xxxxx
x x
x x
x x Observer's device (e.g. smartphone) x x Observer's device (e.g. smartphone)
x x x x
Figure 4: "Broadcast RID Information Flow" Figure 4: "Broadcast RID Information Flow"
Note the absence of the Internet from this information flow sketch. Note the absence of the Internet from this information flow sketch.
This is because Broadcast RID is one-way direct transmission of This is because Broadcast RID is one-way direct transmission of
application layer messages over a RF data link (without IP or other application layer messages over a RF data link (without IP or other
middle layer protocols) from the UA to local Observer devices. middle layer protocols) from the UA to local Observer devices.
Internet connectivity is involved only in what the Observer chooses Internet connectivity is involved only in what the Observer chooses
to do with the information received, such as verify signatures using to do with the information received, such as verify signatures using
a web based verifier service and look up information in registries a web based verifier service and look up information in registries
using the UAS ID as the primary unique key. using the UAS ID as the primary unique key.
skipping to change at page 22, line 5 skipping to change at page 22, line 32
The [F3411-19] optional Authentication Message specifies framing for The [F3411-19] optional Authentication Message specifies framing for
authentication data, but does not specify any authentication method, authentication data, but does not specify any authentication method,
and the maximum length of the specified framing is too short for and the maximum length of the specified framing is too short for
conventional digital signatures and far too short for conventional conventional digital signatures and far too short for conventional
certificates. The one-way nature of Broadcast RID precludes certificates. The one-way nature of Broadcast RID precludes
challenge-response security protocols (e.g., observers sending nonces challenge-response security protocols (e.g., observers sending nonces
to UA, to be returned in signed messages). An observer would be to UA, to be returned in signed messages). An observer would be
seriously challenged to validate the asserted UAS ID or any other seriously challenged to validate the asserted UAS ID or any other
information about the UAS or its operator looked up therefrom. information about the UAS or its operator looked up therefrom.
3.3. DRIP Focus 3.3. USS in UTM and RID
UAS RID and UTM are complementary; Network RID is a UTM service. The
backbone of the UTM system is comprised of multiple USS: one or
several per jurisdiction; some limited to a single jurisdiction,
others spanning multiple jurisdictions. USS also serve as the
principal or perhaps the sole interface for operators and UAS into
the UTM environment. Each operator subscribes to at least one USS.
Each UAS is registered by its operator in at least one USS. Each
operational intent is submitted to one USS: if approved, that UAS and
operator can commence that operation; from this point until the end
of the operation, status and location of that UAS must be reported to
that USS, which in turn provides information as needed about that
operator, UAS and operation into the UTM system and to Observers via
Network RID.
USS provide services not limited to Network RID; indeed, the primary
USS function is deconfliction of airspace usage by different UAS and
other (e.g. manned aircraft, rocket launch) operations. Most
deconfliction involving a given operation is hoped to be completed
prior to commencing that operation, and is called "strategic
deconfliction." If that fails, "tactical deconfliction" comes into
play; ABDAA may not involve USS, but GBDAA likely will. Also,
dynamic constraints (formerly UAS Volume Restrictions, UVR) can be
necessitated by local emergencies, extreme weather, etc., specified
by authorities on the ground and propagated in UTM.
No role for USS in Broadcast RID is currently specified by regulators
or [F3411-19]. However, USS are likely to serve as registries (or
perhaps registrars) for UAS (and perhaps operators); if so, USS will
have a role in all forms of RID. Supplemental Data Service Providers
(SDSP) are also likely to find roles, not only in UTM as such but
also in enhancing UAS RID and related services. Whether USS, SDSP,
etc. are involved or not, RID services, narrowly defined, provide
regulator specified identification information; more broadly defined,
RID services may leverage identification to facilitate related
services or functions, likely beginning with V2X.
3.4. DRIP Focus
In addition to the gaps described above, there is a fundamental gap In addition to the gaps described above, there is a fundamental gap
in almost all current or proposed regulations and technical standards in almost all current or proposed regulations and technical standards
for UAS RID. As noted above, ID is not an end in itself, but a for UAS RID. As noted above, ID is not an end in itself, but a
means. [F3411-19] etc. provide very limited choices for an observer means. [F3411-19] etc. provide very limited choices for an observer
to communicate with the pilot, e.g., to request further information to communicate with the pilot, e.g., to request further information
on the UAS operation or exit from an airspace volume in an emergency. on the UAS operation or exit from an airspace volume in an emergency.
The System Message provides the location of the pilot/GCS, so an The System Message provides the location of the pilot/GCS, so an
observer could physically go to the asserted location to look for the observer could physically go to the asserted location to look for the
remote pilot; this is at best slow, and may not be feasible -- what remote pilot; this is at best slow, and may not be feasible -- what
skipping to change at page 24, line 24 skipping to change at page 25, line 37
GEN-10 Multicast: DRIP SHOULD support multicast for efficient and GEN-10 Multicast: DRIP SHOULD support multicast for efficient and
flexible publish-subscribe notifications, e.g., of UAS flexible publish-subscribe notifications, e.g., of UAS
reporting positions in designated airspace volumes. reporting positions in designated airspace volumes.
GEN-11 Management: DRIP SHOULD support monitoring of the health and GEN-11 Management: DRIP SHOULD support monitoring of the health and
coverage of Broadcast and Network RID services. coverage of Broadcast and Network RID services.
Requirements imposed either by regulation or [F3411-19] are not Requirements imposed either by regulation or [F3411-19] are not
reiterated here, but drive many of the numbered requirements listed reiterated here, but drive many of the numbered requirements listed
here. The QoS requirement currently would be satisfied generally by here. The [NPRM] regulatory QoS requirement currently would be
ensuring information refresh rates of at least 1 Hertz, with satisfied by ensuring information refresh rates of at least 1 Hertz,
latencies no greater than 1 second, at least 80% of the time; but with latencies no greater than 1 second, at least 80% of the time,
these numbers may change, so instead the DRIP requirement is that but these numbers may vary between jurisdictions and over time. So
they be user policy specifiable (which does not imply satisfiable in instead the DRIP QoS requirement is that performance, reliability,
all cases, but implies that when the specs are not met, appropriate etc. parameters be user policy specifiable, which does not imply
parties are notified). The "provable ownership" requirement satisfiable in all cases, but (especially together with the
addresses the possibility that the actual sender is not the claimed management requirement) implies that when specifications are not met,
sender (i.e. is a spoofer). The "provable binding" requirement appropriate parties are notified. The "provable ownership"
addresses the MAC address correlation problem of [F3411-19] noted requirement addresses the possibility that the actual sender is not
above. The "provable registration" requirement may impose burdens the claimed sender (i.e. is a spoofer). The "provable binding"
not only on the UAS sender and the Observer's receiver, but also on requirement addresses the MAC address correlation problem of
the registry; yet it cannot depend upon the Observer being able to [F3411-19] noted above. The "provable registration" requirement may
contact the registry at the time of observing the UA. The impose burdens not only on the UAS sender and the Observer's
"readability" requirement may involve machine assisted format receiver, but also on the registry; yet it cannot depend upon the
conversions, e.g. from binary encodings. The "gateway" requirement Observer being able to contact the registry at the time of observing
is the only instance in which DRIP transports [F3411-19] messages; the UA. The "readability" requirement may involve machine assisted
most of DRIP pertains to the authentication of such messages and the format conversions, e.g. from binary encodings. The "gateway"
identifier carried within them. requirement is the only instance in which DRIP transports [F3411-19]
messages; most of DRIP pertains to the authentication of such
messages and the identifier carried within them.
4.2. Identifier 4.2. Identifier
ID-1 Length: The DRIP (UAS) entity (remote) identifier must be no ID-1 Length: The DRIP (UAS) entity (remote) identifier must be no
longer than 20 bytes (per [F3411-19] to fit in a Bluetooth 4 longer than 20 bytes (per [F3411-19] to fit in a Bluetooth 4
advertisement payload). advertisement payload).
ID-2 Registry ID: The DRIP identifier MUST be sufficient to identify ID-2 Registry ID: The DRIP identifier MUST be sufficient to identify
a registry in which the (UAS) entity identified therewith is a registry in which the (UAS) entity identified therewith is
listed. listed.
skipping to change at page 25, line 40 skipping to change at page 27, line 8
applications such as DAA and C2, it could be used between the network applications such as DAA and C2, it could be used between the network
and transport layers (with HIP or DTLS). and transport layers (with HIP or DTLS).
Registry ID (which registry the entity is in) and Entity ID (which Registry ID (which registry the entity is in) and Entity ID (which
entity it is, within that registry) are requirements on a single DRIP entity it is, within that registry) are requirements on a single DRIP
entity Identifier, not separate (types of) ID. In the most common entity Identifier, not separate (types of) ID. In the most common
use case, the Entity will be the UA, and the DRIP Identifier will be use case, the Entity will be the UA, and the DRIP Identifier will be
the UAS ID; however, other entities may also benefit from having DRIP the UAS ID; however, other entities may also benefit from having DRIP
identifiers, so the Entity type is not prescribed here. identifiers, so the Entity type is not prescribed here.
Whether a UAS ID is generated by the operator, GCS, UA, USS or Whether an UAS ID is generated by the operator, GCS, UA, USS or
registry, or some collaboration thereamong, is unspecified; however, registry, or some collaboration thereamong, is unspecified; however,
there must be agreement on the UAS ID among these entities. there must be agreement on the UAS ID among these entities.
4.3. Privacy 4.3. Privacy
PRIV-1 Confidential Handling: DRIP MUST enable confidential handling PRIV-1 Confidential Handling: DRIP MUST enable confidential handling
of private information (i.e., any and all information of private information (i.e., any and all information
designated by neither cognizant authority nor the information designated by neither cognizant authority nor the information
owner as public, e.g., personal data). owner as public, e.g., personal data).
skipping to change at page 30, line 25 skipping to change at page 31, line 35
[Delegated] [Delegated]
European Union Aviation Safety Agency (EASA), "Commission European Union Aviation Safety Agency (EASA), "Commission
Delegated Regulation (EU) 2019/945 of 12 March 2019 on Delegated Regulation (EU) 2019/945 of 12 March 2019 on
unmanned aircraft systems and on third-country operators unmanned aircraft systems and on third-country operators
of unmanned aircraft systems", March 2019. of unmanned aircraft systems", March 2019.
[drip-architecture] [drip-architecture]
Card, S., Wiethuechter, A., Moskowitz, R., Zhao, S., and Card, S., Wiethuechter, A., Moskowitz, R., Zhao, S., and
A. Gurtov, "Drone Remote Identification Protocol (DRIP) A. Gurtov, "Drone Remote Identification Protocol (DRIP)
Architecture", Work in Progress, Internet-Draft, draft- Architecture", Work in Progress, Internet-Draft, draft-
ietf-drip-arch-03, 13 July 2020, ietf-drip-arch-04, 28 October 2020,
<https://tools.ietf.org/html/draft-ietf-drip-arch-03>. <https://tools.ietf.org/html/draft-ietf-drip-arch-04>.
[ENISACSIRT] [ENISACSIRT]
European Union Agency for Cybersecurity (ENISA), European Union Agency for Cybersecurity (ENISA),
"Actionable information for Security Incident Response", "Actionable information for Security Incident Response",
November 2014, <https://www.enisa.europa.eu/topics/csirt- November 2014, <https://www.enisa.europa.eu/topics/csirt-
cert-services/reactive-services/copy_of_actionable- cert-services/reactive-services/copy_of_actionable-
information>. information>.
[EU2018] European Parliament and Council, "2015/0277 (COD) PE-CONS [EU2018] European Parliament and Council, "2015/0277 (COD) PE-CONS
2/18", February 2018. 2/18", February 2018.
skipping to change at page 33, line 27 skipping to change at page 34, line 41
dispatchers will be able to see UA on their control screens and take dispatchers will be able to see UA on their control screens and take
those into account. If not, a gateway translation system between the those into account. If not, a gateway translation system between the
proposed drone ID and civil aviation system should be implemented. proposed drone ID and civil aviation system should be implemented.
Again, system saturation due to large numbers of UAS is a concern. Again, system saturation due to large numbers of UAS is a concern.
Wi-Fi and Bluetooth are two wireless technologies currently Wi-Fi and Bluetooth are two wireless technologies currently
recommended by ASTM specifications due to their widespread use and recommended by ASTM specifications due to their widespread use and
broadcast nature. However, those have limited range (max 100s of broadcast nature. However, those have limited range (max 100s of
meters) and may not reliably deliver UAS ID at high altitude or meters) and may not reliably deliver UAS ID at high altitude or
distance. Therefore, a study should be made of alternative distance. Therefore, a study should be made of alternative
technologies from the telecom domain (WiMAX, 5G) or sensor networks technologies from the telecom domain (WiMAX / IEEE 802.16, 5G) or
(Sigfox, LORA). Such transmission technologies can impose additional sensor networks (Sigfox, LORA). Such transmission technologies can
restrictions on packet sizes and frequency of transmissions, but impose additional restrictions on packet sizes and frequency of
could provide better energy efficiency and range. In civil aviation, transmissions, but could provide better energy efficiency and range.
Controller-Pilot Data Link Communications (CPDLC) is used to transmit In civil aviation, Controller-Pilot Data Link Communications (CPDLC)
command and control between the pilots and ATC. It could be is used to transmit command and control between the pilots and ATC.
considered for UAS as well due to long range and proven use despite It could be considered for UAS as well due to long range and proven
its lack of security [cpdlc]. use despite its lack of security [cpdlc].
L-band Digital Aeronautical Communications System (LDACS) is being L-band Digital Aeronautical Communications System (LDACS) is being
standardized by ICAO and IETF for use in future civil aviation standardized by ICAO and IETF for use in future civil aviation
[I-D.maeurer-raw-ldacs]. It provides secure communication, [I-D.maeurer-raw-ldacs]. It provides secure communication,
positioning and control for aircraft using a dedicated radio band. positioning and control for aircraft using a dedicated radio band.
It should be analyzed as a potential provider for UAS RID as well. It should be analyzed as a potential provider for UAS RID as well.
This will bring the benefit of a global integrated system creating a This will bring the benefit of a global integrated system creating a
global airspace use awareness. global airspace use awareness.
Acknowledgments Acknowledgments
 End of changes. 28 change blocks. 
103 lines changed or deleted 198 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/