draft-ietf-drip-reqs-11.txt   draft-ietf-drip-reqs-12.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: 12 November 2021 R. Moskowitz Expires: 24 November 2021 R. Moskowitz
HTT Consulting HTT Consulting
A. Gurtov A. Gurtov
Linköping University Linköping University
11 May 2021 23 May 2021
Drone Remote Identification Protocol (DRIP) Requirements Drone Remote Identification Protocol (DRIP) Requirements
draft-ietf-drip-reqs-11 draft-ietf-drip-reqs-12
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).
Complementing external technical standards as regulator-accepted Complementing external technical standards as regulator-accepted
means of compliance with UAS RID regulations, DRIP will facilitate means of compliance with UAS RID regulations, DRIP will facilitate
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 12 November 2021. This Internet-Draft will expire on 24 November 2021.
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 36 skipping to change at page 2, line 36
3.2. Broadcast RID . . . . . . . . . . . . . . . . . . . . . . 25 3.2. Broadcast RID . . . . . . . . . . . . . . . . . . . . . . 25
3.3. USS in UTM and RID . . . . . . . . . . . . . . . . . . . 28 3.3. USS in UTM and RID . . . . . . . . . . . . . . . . . . . 28
3.4. DRIP Focus . . . . . . . . . . . . . . . . . . . . . . . 29 3.4. DRIP Focus . . . . . . . . . . . . . . . . . . . . . . . 29
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 30 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1.1. Normative Requirements . . . . . . . . . . . . . . . 30 4.1.1. Normative Requirements . . . . . . . . . . . . . . . 30
4.1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 31 4.1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 31
4.2. Identifier . . . . . . . . . . . . . . . . . . . . . . . 32 4.2. Identifier . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.1. Normative Requirements . . . . . . . . . . . . . . . 32 4.2.1. Normative Requirements . . . . . . . . . . . . . . . 32
4.2.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 33 4.2.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 33
4.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3.1. Normative Requirements . . . . . . . . . . . . . . . 33 4.3.1. Normative Requirements . . . . . . . . . . . . . . . 34
4.3.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 34 4.3.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 35
4.4. Registries . . . . . . . . . . . . . . . . . . . . . . . 35 4.4. Registries . . . . . . . . . . . . . . . . . . . . . . . 35
4.4.1. Normative Requirements . . . . . . . . . . . . . . . 35 4.4.1. Normative Requirements . . . . . . . . . . . . . . . 35
4.4.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 36 4.4.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 36
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
6. Security Considerations . . . . . . . . . . . . . . . . . . . 36 6. Security Considerations . . . . . . . . . . . . . . . . . . . 37
7. Privacy and Transparency Considerations . . . . . . . . . . . 37 7. Privacy and Transparency Considerations . . . . . . . . . . . 38
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.1. Normative References . . . . . . . . . . . . . . . . . . 38 8.1. Normative References . . . . . . . . . . . . . . . . . . 39
8.2. Informative References . . . . . . . . . . . . . . . . . 38 8.2. Informative References . . . . . . . . . . . . . . . . . 39
Appendix A. Discussion and Limitations . . . . . . . . . . . . . 43 Appendix A. Discussion and Limitations . . . . . . . . . . . . . 43
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 44 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
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 4, line 16 skipping to change at page 4, line 16
Internet protocols typically start out with at least one entity Internet protocols typically start out with at least one entity
already knowing an identifier or locator of another; but an entity already knowing an identifier or locator of another; but an entity
(e.g., UAS or Observer device) encountering an _a priori_ unknown UA (e.g., UAS or Observer device) encountering an _a priori_ unknown UA
in physical space has no identifier or logical space locator for that in physical space has no identifier or logical space locator for that
UA, unless and until one is provided somehow. RID provides an UA, unless and until one is provided somehow. RID provides an
identifier, which, if well chosen, can facilitate use of a variety of identifier, which, if well chosen, can facilitate use of a variety of
Internet family protocols and services to support arbitrary Internet family protocols and services to support arbitrary
applications, beyond the basic security functions of RID. For most applications, beyond the basic security functions of RID. For most
of these, some type of identifier is essential, e.g., Network Access of these, some type of identifier is essential, e.g., Network Access
Identifier (NAI), Digital Object Identifier (DOI), Uniform Resource Identifier (NAI), Digital Object Identifier (DOI), Uniform Resource
Identifier (URI), domain mame, or public key. DRIP motivations Identifier (URI), domain name, or public key. DRIP motivations
include both the basic security and the broader application support include both the basic security and the broader application support
functions of RID. functions of RID.
The general UAS RID usage scenario is illustrated in Figure 1. The general UAS RID usage scenario is illustrated in Figure 1.
UA1 UA2 UA1 UA2
x x x x x x x x
xxxxx xxxxx xxxxx xxxxx
General x x Public General x x Public
skipping to change at page 31, line 6 skipping to change at page 31, line 6
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).
GEN-6 Finger: DRIP MUST enable dynamically establishing, with AAA, GEN-6 Finger: DRIP MUST enable dynamically establishing, with AAA,
per policy, strongly mutually authnenticated, end-to-end per policy, strongly mutually authenticated, end-to-end
strongly encrypted communications with the UAS RID sender and strongly encrypted communications with the UAS RID sender and
entities looked up from the UAS ID, including at least the entities looked up from the UAS ID, including at least the
remote pilot and USS. remote pilot and USS.
GEN-7 QoS: DRIP MUST enable policy based specification of GEN-7 QoS: DRIP MUST enable policy based specification of
performance and reliability parameters, such as maximum performance and reliability parameters.
message transmission intervals and delivery latencies.
GEN-8 Mobility: DRIP MUST support physical and logical mobility of GEN-8 Mobility: DRIP MUST support physical and logical mobility of
UA, GCS and Observers. DRIP SHOULD support mobility of UA, GCS and Observers. DRIP SHOULD support mobility of
essentially all participating nodes (UA, GCS, Observers, Net- essentially all participating nodes (UA, GCS, Observers, Net-
RID SP, Net-RID DP, Private Registry, SDSP, and potentially RID SP, Net-RID DP, Private Registry, SDSP, and potentially
others as RID and UTM evolve). others as RID and UTM evolve).
GEN-9 Multihoming: DRIP MUST support multihoming of UA and GCS, for GEN-9 Multihoming: DRIP MUST support multihoming of UA and GCS, for
make-before-break smooth handoff and resiliency against path/ make-before-break smooth handoff and resiliency against path/
link failure. DRIP SHOULD support multihoming of essentially link failure. DRIP SHOULD support multihoming of essentially
skipping to change at page 32, line 9 skipping to change at page 32, line 8
the actual sender is not the claimed sender (i.e., is a spoofer). the actual sender is not the claimed sender (i.e., is a spoofer).
The "provable binding" requirement addresses the MAC address The "provable binding" requirement addresses the MAC address
correlation problem of [F3411-19] noted above. The "provable correlation problem of [F3411-19] noted above. The "provable
registration" requirement may impose burdens not only on the UAS registration" requirement may impose burdens not only on the UAS
sender and the Observer's receiver, but also on the registry; yet it sender and the Observer's receiver, but also on the registry; yet it
cannot depend upon the Observer being able to contact the registry at cannot depend upon the Observer being able to contact the registry at
the time of observing the UA. The "readability" requirement pertains the time of observing the UA. The "readability" requirement pertains
to the structure and format of information at endpoints rather than to the structure and format of information at endpoints rather than
its encoding in transit, so may involve machine assisted format its encoding in transit, so may involve machine assisted format
conversions, e.g., from binary encodings, and/or decryption (see conversions, e.g., from binary encodings, and/or decryption (see
Section 4.3). The "mobility" requirement refers to rapid geographic Section 4.3).
mobility of nodes, changes of their points of attachment to networks,
and changes to their IP addresses; it is not limited to micro-
mobility within a small geographic area or single Internet access
provider.
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 "QoS" requirement is only that performance and reliability
parameters can be _specified_ by policy, not that any such
specifications must be guaranteed to be met; any failure to meet such
would be reported under the "management" requirement. Examples of
such parameters are the maximum time interval at which messages
carrying required data elements may be transmitted, the maximum
tolerable rate of loss of such messages, and the maximum tolerable
latency between a dynamic data element (e.g., GNSS position of UA)
being provided to the DRIP sender and that element being delivered by
the DRIP receiver to an application.
The "mobility" requirement refers to rapid geographic mobility of
nodes, changes of their points of attachment to networks, and changes
to their IP addresses; it is not limited to micro-mobility within a
small geographic area or single Internet access provider.
4.2. Identifier 4.2. Identifier
4.2.1. Normative Requirements 4.2.1. Normative Requirements
ID-1 Length: The DRIP entity identifier MUST NOT be longer than 20 ID-1 Length: The DRIP entity identifier MUST NOT be longer than 20
bytes, to fit in the UAS ID field of the Basic ID message of bytes, to fit in the UAS ID field of the Basic ID message of
[F3411-19]. [F3411-19].
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 entity identified therewith is listed. a registry in which the entity identified therewith is listed.
skipping to change at page 33, line 41 skipping to change at page 34, line 5
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, Whether a UAS ID is generated by the operator, GCS, UA, USS,
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.
While "uniqueness" might be considered an implicit requirement for
any identifier, here the point of the explicit requirement is not
just that it should be unique, but also where and when it should be
unique: global scope within a specified space, from registration to
deregistration.
While "non-spoofability" imposes requirements for and on a DRIP
authentication protocol, it also imposes requirements on the
properties of the identifier itself. An example of how the nature of
the identifier can support non-spoofability is embedding a hash of
both the registry ID and a public key of the entity in the entity
identifier, thus making it self-authenticating any time the entity's
corresponding private key is used to sign a message.
While "unlinkability" is a privacy desideratum (see next section), it
imposes requirements on the DRIP identifier itself, as distinct from
other currently permitted choices for the UAS ID (including primarily
the static serial number of the UA or RID module).
4.3. Privacy 4.3. Privacy
4.3.1. Normative Requirements 4.3.1. Normative Requirements
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).
PRIV-2 Encrypted Transport: DRIP MUST enable selective strong PRIV-2 Encrypted Transport: DRIP MUST enable selective strong
 End of changes. 13 change blocks. 
24 lines changed or deleted 54 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/