draft-ietf-drip-reqs-16.txt   draft-ietf-drip-reqs-17.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: 29 December 2021 R. Moskowitz Expires: 8 January 2022 R. Moskowitz
HTT Consulting HTT Consulting
A. Gurtov A. Gurtov
Linköping University Linköping University
27 June 2021 7 July 2021
Drone Remote Identification Protocol (DRIP) Requirements Drone Remote Identification Protocol (DRIP) Requirements
draft-ietf-drip-reqs-16 draft-ietf-drip-reqs-17
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 solutions to support Identification Protocol (DRIP) Working Group solutions 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 (e.g., initiation of for security, safety, and other purposes (e.g., initiation of
identity based network sessions supporting UAS applications). identity based network sessions supporting UAS applications). DRIP
Complementing external technical standards as regulator-accepted will facilitate use of existing Internet resources to support RID and
means of compliance with UAS RID regulations, DRIP will facilitate to enable enhanced related services, and will enable online and
use of existing Internet resources to support RID and to enable offline verification that RID information is trustworthy.
enhanced related services, and will enable online and offline
verification that RID information is trustworthy.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 29 December 2021. This Internet-Draft will expire on 8 January 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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
skipping to change at page 2, line 23 skipping to change at page 2, line 23
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation and External Influences . . . . . . . . . . . 3 1.1. Motivation and External Influences . . . . . . . . . . . 3
1.2. Concerns and Constraints . . . . . . . . . . . . . . . . 8 1.2. Concerns and Constraints . . . . . . . . . . . . . . . . 8
1.3. DRIP Scope . . . . . . . . . . . . . . . . . . . . . . . 10 1.3. DRIP Scope . . . . . . . . . . . . . . . . . . . . . . . 10
1.4. Document Scope . . . . . . . . . . . . . . . . . . . . . 11 1.4. Document Scope . . . . . . . . . . . . . . . . . . . . . 11
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 11 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 11
2.1. Requirements Terminology . . . . . . . . . . . . . . . . 11 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 11
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 12 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 11
3. UAS RID Problem Space . . . . . . . . . . . . . . . . . . . . 20 3. UAS RID Problem Space . . . . . . . . . . . . . . . . . . . . 20
3.1. Network RID . . . . . . . . . . . . . . . . . . . . . . . 22 3.1. Network RID . . . . . . . . . . . . . . . . . . . . . . . 22
3.2. Broadcast RID . . . . . . . . . . . . . . . . . . . . . . 25 3.2. Broadcast RID . . . . . . . . . . . . . . . . . . . . . . 25
3.3. USS in UTM and RID . . . . . . . . . . . . . . . . . . . 29 3.3. USS in UTM and RID . . . . . . . . . . . . . . . . . . . 28
3.4. DRIP Focus . . . . . . . . . . . . . . . . . . . . . . . 30 3.4. DRIP Focus . . . . . . . . . . . . . . . . . . . . . . . 29
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 31 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1.1. Normative Requirements . . . . . . . . . . . . . . . 31 4.1.1. Normative Requirements . . . . . . . . . . . . . . . 30
4.1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 32 4.1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 32
4.2. Identifier . . . . . . . . . . . . . . . . . . . . . . . 33 4.2. Identifier . . . . . . . . . . . . . . . . . . . . . . . 33
4.2.1. Normative Requirements . . . . . . . . . . . . . . . 33 4.2.1. Normative Requirements . . . . . . . . . . . . . . . 33
4.2.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 34 4.2.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 34
4.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3.1. Normative Requirements . . . . . . . . . . . . . . . 35 4.3.1. Normative Requirements . . . . . . . . . . . . . . . 35
4.3.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 36 4.3.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 36
4.4. Registries . . . . . . . . . . . . . . . . . . . . . . . 37 4.4. Registries . . . . . . . . . . . . . . . . . . . . . . . 36
4.4.1. Normative Requirements . . . . . . . . . . . . . . . 37 4.4.1. Normative Requirements . . . . . . . . . . . . . . . 37
4.4.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 37 4.4.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 37
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
6. Security Considerations . . . . . . . . . . . . . . . . . . . 38 6. Security Considerations . . . . . . . . . . . . . . . . . . . 38
7. Privacy and Transparency Considerations . . . . . . . . . . . 39 7. Privacy and Transparency Considerations . . . . . . . . . . . 39
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
8.1. Normative References . . . . . . . . . . . . . . . . . . 40 8.1. Normative References . . . . . . . . . . . . . . . . . . 40
8.2. Informative References . . . . . . . . . . . . . . . . . 40 8.2. Informative References . . . . . . . . . . . . . . . . . 40
Appendix A. Discussion and Limitations . . . . . . . . . . . . . 44 Appendix A. Discussion and Limitations . . . . . . . . . . . . . 45
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 46 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction 1. Introduction
For any unfamiliar or _a priori_ ambiguous terminology herein, see For any unfamiliar or _a priori_ ambiguous terminology herein, see
Section 2. Section 2.
1.1. Motivation and External Influences 1.1. Motivation and External Influences
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
skipping to change at page 5, line 6 skipping to change at page 5, line 6
Figure 1: "General UAS RID Usage Scenario" Figure 1: "General UAS RID Usage Scenario"
Figure 1 illustrates a typical case where there may be: multiple Figure 1 illustrates a typical case where there may be: multiple
Observers, some of them members of the general public, others Observers, some of them members of the general public, others
government officers with public safety/security responsibilities; government officers with public safety/security responsibilities;
multiple UA in flight within observation range, each with its own multiple UA in flight within observation range, each with its own
pilot/operator; at least one registry each for lookup of public and pilot/operator; at least one registry each for lookup of public and
(by authorized parties only) private information regarding the UAS (by authorized parties only) private information regarding the UAS
and their pilots/operators; and in the DRIP vision, DNS resolving and their pilots/operators; and in the DRIP vision, DNS resolving
various identifiers and locators of the entities involved. Note the various identifiers and locators of the entities involved.
absence of any links to/from the UA in the figure; this is because
UAS RID and other connectivity involving the UA varies, as described Note the absence of any links to/from the UA in the figure; this is
subsequently herein under Figure 3. Remote Observer connectivity to because UAS RID and other connectivity involving the UA varies. Some
the Internet may be very intermittent. connectivity paths do or do not exist depending upon the scenario.
Command and Control (C2) from the GCS to the UA via the Internet
(e.g., using LTE cellular) is expected to become much more common as
Beyond Visual Line Of Sight (BVLOS) operations increase; in such a
case, there is typically not also a direct wireless link between the
GCS and UA. Conversely, if C2 is running over a direct wireless
link, then typically the GCS has but the UA lacks Internet
connectivity. Further, paths that nominally exist, such as between
an Observer device and the Internet, may be severely intermittent.
These connectivity constraints are likely to have an impact, e.g., on
how reliably DRIP requirements can be satisfied.
An Observer of UA may need to classify them, as illustrated An Observer of UA may need to classify them, as illustrated
notionally in Figure 2, for basic airspace Situational Awareness notionally in Figure 2, for basic airspace Situational Awareness
(SA). An Observer who classifies a UAS: as Taskable, can ask it to (SA). An Observer who classifies a UAS: as Taskable, can ask it to
do something useful; as Low Concern, can reasonably assume it is not do something useful; as Low Concern, can reasonably assume it is not
malicious and would cooperate with requests to modify its flight malicious and would cooperate with requests to modify its flight
plans for safety concerns that arise; as High Concern or plans for safety concerns that arise; as High Concern or
Unidentified, can focus surveillance on it. Unidentified, can focus surveillance on it.
xxxxxxx xxxxxxx
skipping to change at page 7, line 47 skipping to change at page 8, line 7
broadcast but used by authorities to access regional registration broadcast but used by authorities to access regional registration
databases for verification. databases for verification.
ASD-STAN also contemplates corresponding Network Remote ASD-STAN also contemplates corresponding Network Remote
Identification (NRI) functionality. The ASD-STAN RID target is to Identification (NRI) functionality. The ASD-STAN RID target is to
revise their current standard with additional functionality (e.g., revise their current standard with additional functionality (e.g.,
DRIP) to be published before 2022 [ASDRI]. DRIP) to be published before 2022 [ASDRI].
Security oriented UAS RID essentially has two goals: enable the Security oriented UAS RID essentially has two goals: enable the
general public to obtain and record an opaque ID for any observed UA, general public to obtain and record an opaque ID for any observed UA,
which they can then report to authorities; enable authorities, from which they can then report to authorities; and enable authorities,
such an ID, to look up information about the UAS and its operator. from such an ID, to look up information about the UAS and its
Safety oriented UAS RID has stronger requirements. operator. Safety oriented UAS RID has stronger requirements.
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 [Recommendations], it is not addressed in any of the
subsequent regulations or international SDO technical specifications, subsequent regulations or international SDO technical specifications,
other than DRIP, known to the authors as of early 2021. other than DRIP, known to the authors as of early 2021.
1.2. Concerns and Constraints 1.2. Concerns and Constraints
skipping to change at page 10, line 19 skipping to change at page 10, line 12
by ASTM F38.02 too infrequent to address. However, the preamble to by ASTM F38.02 too infrequent to address. However, the preamble to
[FRUR] cites "remote and rural areas that do not have reliable [FRUR] cites "remote and rural areas that do not have reliable
Internet access" as a major reason for requiring Broadcast rather Internet access" as a major reason for requiring Broadcast rather
than Network RID, and states that "Personal wireless devices that are than Network RID, and states that "Personal wireless devices that are
capable of receiving 47 CFR part 15 frequencies, such as smart capable of receiving 47 CFR part 15 frequencies, such as smart
phones, tablets, or other similar commercially available devices, phones, tablets, or other similar commercially available devices,
will be able to receive broadcast remote identification information will be able to receive broadcast remote identification information
directly without reliance on an Internet connection". Internet- directly without reliance on an Internet connection". Internet-
disconnected operation presents challenges, e.g., for Observers disconnected operation presents challenges, e.g., for Observers
needing access to the [F3411-19] web based Broadcast Authentication needing access to the [F3411-19] web based Broadcast Authentication
Verifier Service or external lookups. Verifier Service or needing to do external lookups.
As RID must often operate within these constraints, heavyweight As RID must often operate within these constraints, heavyweight
cryptographic security protocols or even simple cryptographic cryptographic security protocols or even simple cryptographic
handshakes are infeasible, yet trustworthiness of UAS RID information handshakes are infeasible, yet trustworthiness of UAS RID information
is essential. Under [F3411-19], _even the most basic datum, the UAS is essential. Under [F3411-19], _even the most basic datum, the UAS
ID itself, can be merely an unsubstantiated claim_. ID itself, can be merely an unsubstantiated claim_.
Observer devices being ubiquitous, thus popular targets for malware Observer devices being ubiquitous, thus popular targets for malware
or other compromise, cannot be generally trusted (although the user or other compromise, cannot be generally trusted (although the user
of each device is compelled to trust that device, to some extent); a of each device is compelled to trust that device, to some extent); a
skipping to change at page 23, line 7 skipping to change at page 22, line 34
| | * | * | | * | *
| | * | * +------------+ | | * | * +------------+
+--o-------o--+ * '------*-----o Observer's | +--o-------o--+ * '------*-----o Observer's |
| GCS | * * | Device | | GCS | * * | Device |
+-------------+ ****************** +------------+ +-------------+ ****************** +------------+
Figure 3: "Network RID Information Flow" Figure 3: "Network RID Information Flow"
Figure 3 illustrates Network RID information flows. Only two of the Figure 3 illustrates Network RID information flows. Only two of the
three typically wireless links shown involving the UAS (UA-GCS, UA- three typically wireless links shown involving the UAS (UA-GCS, UA-
Internet, and GCS-Internet) need exist. All three may exist, at the Internet, and GCS-Internet) need exist to support C2 and Network RID.
same or different times, especially in Beyond Visual Line Of Sight All three may exist, at the same or different times, especially in
(BVLOS) operations. There must be some information flow path (direct BVLOS operations. There must be some information flow path (direct
or indirect) between the GCS and the UA, for the former to exercise or indirect) between the GCS and the UA, for the former to exercise
C2 over the latter. If this path is two-way (as increasingly it is, C2 over the latter. If this path is two-way (as increasingly it is,
even for inexpensive small UAS), the UA will also send its status even for inexpensive small UAS), the UA will also send its status
(and position, if suitably equipped, e.g., with GNSS) to the GCS. (and position, if suitably equipped, e.g., with GNSS) to the GCS.
There also must be some path between at least one subsystem of the There also 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 UAS (UA or GCS) and the Internet, for the former to send status and
position updates to its USS (serving _inter alia_ as a Net-RID SP). position updates to its USS (serving _inter alia_ as a Net-RID SP).
Direct UA-Internet wireless links are expected to become more common, Direct UA-Internet wireless links are expected to become more common,
especially on larger UAS, but currently (2021) are rare. Instead, especially on larger UAS, but currently (2021) are rare. Instead,
skipping to change at page 30, line 31 skipping to change at page 29, line 47
registry, then call a phone number in hopes someone who can registry, then call a phone number in hopes someone who can
immediately influence the UAS operation will answer promptly during immediately influence the UAS operation will answer promptly during
that operation; this is at best unreliable and may not be prudent. that operation; this is at best unreliable and may not be prudent.
Should pilots be encouraged to answer phone calls while flying? Should pilots be encouraged to answer phone calls while flying?
Internet technologies can do much better than this. Internet technologies can do much better than this.
Thus complementing [F3411-19] with protocols enabling strong Thus complementing [F3411-19] with protocols enabling strong
authentication, preserving operator privacy while enabling immediate authentication, preserving operator privacy while enabling immediate
use of information by authorized parties, is critical to achieve use of information by authorized parties, is critical to achieve
widespread adoption of a RID system supporting safe and secure widespread adoption of a RID system supporting safe and secure
operation of UAS. operation of UAS. Just as [F3411-19] is expected to be approved by
regulators as a basic means of compliance with UAS RID regulations,
DRIP is expected likewise to be approved to address further issues,
starting with the creation and registration of Session IDs.
DRIP will focus on making information obtained via UAS RID DRIP will focus on making information obtained via UAS RID
immediately usable: immediately usable:
1. by making it trustworthy (despite the severe constraints of 1. by making it trustworthy (despite the severe constraints of
Broadcast RID); Broadcast RID);
2. by enabling verification that a UAS is registered for RID, and if 2. by enabling verification that a UAS is registered for RID, and if
so, in which registry (for classification of trusted operators on so, in which registry (for classification of trusted operators on
the basis of known registry vetting, even by Observers lacking the basis of known registry vetting, even by Observers lacking
skipping to change at page 31, line 31 skipping to change at page 30, line 49
GEN-1 Provable Ownership: DRIP MUST enable verification that the GEN-1 Provable Ownership: DRIP MUST enable verification that the
UAS ID asserted in the Basic ID message is that of the actual UAS ID asserted in the Basic ID message is that of the actual
current sender of the message (i.e., the message is not a current sender of the message (i.e., the message is not a
replay attack or other spoof, authenticating, e.g., by replay attack or other spoof, authenticating, e.g., by
verifying an asymmetric cryptographic signature using a verifying an asymmetric cryptographic signature using a
sender provided public key from which the asserted ID can be sender provided public key from which the asserted ID can be
at least partially derived), even on an Observer device at least partially derived), even on an Observer device
lacking Internet connectivity at the time of observation. lacking Internet connectivity at the time of observation.
GEN-2 Provable Binding: DRIP MUST enable binding all other GEN-2 Provable Binding: DRIP MUST enable the cryptographic binding
[F3411-19] messages from the same actual current sender to of all other [F3411-19] messages from the same actual current
the UAS ID asserted in the Basic ID message. sender to the UAS ID asserted in the Basic ID message.
GEN-3 Provable Registration: DRIP MUST enable verification that the GEN-3 Provable Registration: DRIP MUST enable cryptographically
UAS ID is in a registry and identification of that registry, secure verification that the UAS ID is in a registry and
even on an Observer device lacking Internet connectivity at identification of that registry, even on an Observer device
the time of observation; with UAS ID Type 3, the same sender lacking Internet connectivity at the time of observation;
may have multiple IDs, potentially in different registries, with UAS ID Type 3, the same sender may have multiple IDs,
but each ID must clearly indicate in which registry it can be potentially in different registries, but each ID must clearly
found. indicate in which registry it can be found.
GEN-4 Readability: DRIP MUST enable information (regulation GEN-4 Readability: DRIP MUST enable information (regulation
required elements, whether sent via UAS RID or looked up in required elements, whether sent via UAS RID or looked up in
registries) to be read and utilized by both humans and registries) to be read and utilized by both humans and
software. software.
GEN-5 Gateway: DRIP MUST enable Broadcast RID to Network RID GEN-5 Gateway: DRIP MUST enable Broadcast RID to Network RID
application layer gateways to stamp messages with precise application layer gateways to stamp messages with precise
date/time received and receiver location, then relay them to date/time received and receiver location, then relay them to
a network service (e.g., SDSP or distributed ledger). a network service (e.g., SDSP or distributed ledger).
skipping to change at page 33, line 21 skipping to change at page 32, line 41
The "gateway" requirement is in pursuit of three objectives: (1) mark The "gateway" requirement is in pursuit of three objectives: (1) mark
up a RID message with where and when it was actually received, which up a RID message with where and when it was actually received, which
may agree or disagree with the self-report in the set of messages; may agree or disagree with the self-report in the set of messages;
(2) defend against replay attacks; and (3) support optional SDSP (2) defend against replay attacks; and (3) support optional SDSP
services such as multilateration, to complement UAS position self- services such as multilateration, to complement UAS position self-
reports with independent measurements. This is the only instance in reports with independent measurements. This is the only instance in
which DRIP transports [F3411-19] messages; most of DRIP pertains to which DRIP transports [F3411-19] messages; most of DRIP pertains to
the authentication of such messages and identifiers carried in them. the authentication of such messages and identifiers carried in them.
The "contact" requirement allows any party that learns a UAS ID (that
is a DRIP entity identifier rather than another UAS ID Type) to
request establishment of a communications session with the
corresponding UAS RID sender and certain entities associated with
that UAS, but AAA and policy restrictions, _inter alia_ on resolving
the identifier to any locators (typically IP addresses), should
prevent unauthorized parties from distracting or harassing pilots.
Thus some but not all Observers of UA, receivers of Broadcast RID,
clients of Network RID, and other parties can become successfully
initiating endpoints for these sessions.
The "QoS" requirement is only that performance and reliability The "QoS" requirement is only that performance and reliability
parameters can be _specified_ by policy, not that any such parameters can be _specified_ by policy, not that any such
specifications must be guaranteed to be met; any failure to meet such specifications must be guaranteed to be met; any failure to meet such
would be reported under the "management" requirement. Examples of would be reported under the "management" requirement. Examples of
such parameters are the maximum time interval at which messages such parameters are the maximum time interval at which messages
carrying required data elements may be transmitted, the maximum carrying required data elements may be transmitted, the maximum
tolerable rate of loss of such messages, and the maximum tolerable tolerable rate of loss of such messages, and the maximum tolerable
latency between a dynamic data element (e.g., GNSS position of UA) latency between a dynamic data element (e.g., GNSS position of UA)
being provided to the DRIP sender and that element being delivered by being provided to the DRIP sender and that element being delivered by
the DRIP receiver to an application. the DRIP receiver to an application.
skipping to change at page 34, line 34 skipping to change at page 34, line 17
The DRIP identifier can refer to various entities. In the primary The DRIP identifier can refer to various entities. In the primary
initial use case, the entity to be identified is the UA. Entities to initial use case, the entity to be identified is the UA. Entities to
be identified in other likely use cases include but are not limited be identified in other likely use cases include but are not limited
to the operator, USS, and Observer. In all cases, the entity to the operator, USS, and Observer. In all cases, the entity
identified must own (have the exclusive capability to use, such that identified must own (have the exclusive capability to use, such that
receivers can verify its ownership of) the identifier. receivers can verify its ownership of) the identifier.
The DRIP identifier can be used at various layers. In Broadcast RID, The DRIP identifier can be used at various layers. In Broadcast RID,
it would be used by the application running directly over the data it would be used by the application running directly over the data
link. In Network RID, it would be used by the application running link. In Network RID, it would be used by the application running
over HTTPS (and possibly other protocols). In RID initiated V2X over HTTPS (not required by DRIP but generally used by Network RID
implementations) and possibly other protocols. In RID initiated V2X
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, e.g., with the Host Identity Protocol (HIP, and transport layers, e.g., with the Host Identity Protocol (HIP,
[RFC4423], [RFC7401], etc.), or between the transport and application [RFC4423], [RFC7401], etc.), or between the transport and application
layers, e.g., with Datagram Transport Layer Security (DTLS, layers, e.g., with Datagram Transport Layer Security (DTLS,
[RFC6347]). [RFC6347]).
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
skipping to change at page 36, line 28 skipping to change at page 36, line 10
PRIV-5 Pseudonymous Rendezvous: DRIP MAY enable mutual discovery of PRIV-5 Pseudonymous Rendezvous: DRIP MAY enable mutual discovery of
and communications among participating UAS operators whose UA and communications among participating UAS operators whose UA
are in 4-D proximity, using the UAS ID without revealing are in 4-D proximity, using the UAS ID without revealing
pilot/operator identity or physical location. pilot/operator identity or physical location.
4.3.2. Rationale 4.3.2. Rationale
Most data to be sent via Broadcast RID or Network RID is public, thus Most data to be sent via Broadcast RID or Network RID is public, thus
the "encrypted transport" requirement for private data is selective, the "encrypted transport" requirement for private data is selective,
e.g., for the entire payload of the Operator ID Message, but only the e.g., for the entire payload of the Operator ID Message, but only the
pilot/GCS location fields of the System Message. pilot/GCS location fields of the System Message. Safety critical
data includes at least the UA location. Other data also may be
deemed safety critical, e.g., in some jurisdictions the pilot/GCS
location is implied to be safety critical.
UAS have several potential means of assessing the likelihood that
local Observers authorized to access the plaintext will be able to
decrypt it or obtain it from a service able to decrypt it. If the
UAS is not participating in UTM, an Observer would have no means of
obtaining a decryption key or decryption services from a cognizant
USS. If the UAS is participating in UTM, but has lost connectivity
with its USS, then an Observer within visual LOS of the UA is also
unlikely to be able to communicate with that USS (whether due to the
USS being offline or the UAS and Observer being in an area with poor
Internet connectivity). Either of these conditions (UTM non-
participation or USS unreachability) would be known to the UAS.
In some jurisdictions, the configurable enabling and disabling of In some jurisdictions, the configurable enabling and disabling of
encryption may need to be outside the control of the operator. encryption may need to be outside the control of the operator.
[FRUR] mandates manufacturers design RID equipment with some degree [FRUR] mandates manufacturers design RID equipment with some degree
of tamper resistance; the preamble and other FAA commentary suggest of tamper resistance; the preamble and other FAA commentary suggest
this is to reduce the likelihood that an operator, intentionally or this is to reduce the likelihood that an operator, intentionally or
unintentionally, might alter the values of the required data elements unintentionally, might alter the values of the required data elements
or disable their transmission in the required manner (e.g., as or disable their transmission in the required manner (e.g., as
cleartext). cleartext).
skipping to change at page 38, line 17 skipping to change at page 38, line 13
AAA for registries is essential, not just to ensure that access is AAA for registries is essential, not just to ensure that access is
granted only to strongly authenticated, duly authorized parties, but granted only to strongly authenticated, duly authorized parties, but
also to support subsequent attribution of any leaks, audit of who also to support subsequent attribution of any leaks, audit of who
accessed information when and for what purpose, etc. As specific AAA accessed information when and for what purpose, etc. As specific AAA
requirements will vary by jurisdictional regulation, provider requirements will vary by jurisdictional regulation, provider
philosophy, customer demand, etc., they are left to specification in philosophy, customer demand, etc., they are left to specification in
policies, which should be human readable to facilitate analysis and policies, which should be human readable to facilitate analysis and
discussion, and machine readable to enable automated enforcement, discussion, and machine readable to enable automated enforcement,
using a language amenable to both, e.g., XACML. using a language amenable to both, e.g., XACML.
The intent of the negative and positive access control requirements
on registries is to ensure that no member of the public would be
hindered from accessing public information, while only duly
authorized parties would be enabled to access private information.
Mitigation of Denial of Service attacks and refusal to allow database
mass scraping would be based on those behaviors, not on identity or
role of the party submitting the query _per se_, but querant identity
information might be gathered (by security systems protecting DRIP
implementations) on such misbehavior.
By "Internet direct contact information" is meant a locator (e.g., IP
address), or identifier (e.g., FQDN) that can be resolved to a
locator, which would enable initiation of an end-to-end communication
session using a well known protocol (e.g., SIP).
5. IANA Considerations 5. IANA Considerations
This document does not make any IANA request. This document does not make any IANA request.
6. Security Considerations 6. Security Considerations
DRIP is all about safety and security, so content pertaining to such DRIP is all about safety and security, so content pertaining to such
is not limited to this section. This document does not define any is not limited to this section. This document does not define any
protocols, so security considerations of such are speculative. protocols, so security considerations of such are speculative.
Potential vulnerabilities of DRIP solutions to these requirements Potential vulnerabilities of DRIP solutions to these requirements
skipping to change at page 39, line 20 skipping to change at page 39, line 32
One approach to so doing involves verifiably binding the DRIP One approach to so doing involves verifiably binding the DRIP
identifier to a public key. Providing these security features, identifier to a public key. Providing these security features,
whether via this approach or another, is likely to be especially whether via this approach or another, is likely to be especially
challenging for Observers without Internet connectivity at the time challenging for Observers without Internet connectivity at the time
of observation. For example, checking the signature of a registry on of observation. For example, checking the signature of a registry on
a public key certificate received via Broadcast RID in a remote area a public key certificate received via Broadcast RID in a remote area
presumably would require that the registry's public key had been presumably would require that the registry's public key had been
previously installed on the Observer's device, yet there may be many previously installed on the Observer's device, yet there may be many
registries and the Observer's device may be storage constrained, and registries and the Observer's device may be storage constrained, and
new registries may come on-line subsequent to installation of DRIP new registries may come on-line subsequent to installation of DRIP
software on the Observer's device. Thus there may be caveats on the software on the Observer's device. See also Figure 1 and the
extent to which requirements can be satisfied in such cases, yet associated explanatory text, especially the second paragraph after
strenuous effort should be made to satisfy them, as such cases, e.g., the figure. Thus there may be caveats on the extent to which
firefighting in a national forest, are important. requirements can be satisfied in such cases, yet strenuous effort
should be made to satisfy them, as such cases, e.g., firefighting in
a national forest, are important.
7. Privacy and Transparency Considerations 7. Privacy and Transparency Considerations
Privacy and transparency are important for legal reasons including Privacy and transparency are important for legal reasons including
regulatory consistency. [EU2018] states "harmonised and regulatory consistency. [EU2018] states "harmonised and
interoperable national registration systems... should comply with the interoperable national registration systems... should comply with the
applicable Union and national law on privacy and processing of applicable Union and national law on privacy and processing of
personal data, and the information stored in those registration personal data, and the information stored in those registration
systems should be easily accessible." systems should be easily accessible."
skipping to change at page 46, line 28 skipping to change at page 46, line 41
Acknowledgments Acknowledgments
The work of the FAA's UAS Identification and Tracking (UAS ID) The work of the FAA's UAS Identification and Tracking (UAS ID)
Aviation Rulemaking Committee (ARC) is the foundation of later ASTM Aviation Rulemaking Committee (ARC) is the foundation of later ASTM
[F3411-19] and IETF DRIP efforts. The work of Gabriel Cox, Intel [F3411-19] and IETF DRIP efforts. The work of Gabriel Cox, Intel
Corp., and their Open Drone ID collaborators opened UAS RID to a Corp., and their Open Drone ID collaborators opened UAS RID to a
wider community. The work of ASTM F38.02 in balancing the interests wider community. The work of ASTM F38.02 in balancing the interests
of diverse stakeholders is essential to the necessary rapid and of diverse stakeholders is essential to the necessary rapid and
widespread deployment of UAS RID. IETF volunteers who have widespread deployment of UAS RID. IETF volunteers who have
extensively reviewed or otherwise contributed to this document extensively reviewed or otherwise contributed to this document
include Amelia Andersdotter, Carsten Bormann, Mohamed Boucadair, include Amelia Andersdotter, Carsten Bormann, Toerless Eckert, Susan
Toerless Eckert, Susan Hares, Mika Jarvenpaa, Daniel Migault, Hares, Mika Jarvenpaa, Alexandre Petrescu, Saulo Da Silva and Shuai
Alexandre Petrescu, Saulo Da Silva and Shuai Zhao. Thanks to Linda Zhao. Thanks to Linda Dunbar for the Secdir review, Nagendra Nainar
Dunbar for the Secdir review, Nagendra Nainar for the Opsdir review for the Opsdir review and Suresh Krishnan for the Gen-ART review.
and Suresh Krishnan for the Gen-ART review. Thanks to IESG members Roman Danyliw, Erik Kline, Murray Kucherawy
and Robert Wilton for helpful and positive comments. Thanks to
chairs Daniel Migault and Mohamed Boucadair for direction of our team
of authors and editor, some of whom are newcomers to writing IETF
documents. Thanks especially to Internet Area Director Eric Vyncke
for guidance and support.
Authors' Addresses Authors' Addresses
Stuart W. Card (editor) Stuart W. Card (editor)
AX Enterprize AX Enterprize
4947 Commercial Drive 4947 Commercial Drive
Yorkville, NY 13495 Yorkville, NY 13495
United States of America United States of America
Email: stu.card@axenterprize.com Email: stu.card@axenterprize.com
 End of changes. 23 change blocks. 
53 lines changed or deleted 113 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/