draft-ietf-drip-reqs-10.txt   draft-ietf-drip-reqs-11.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 October 2021 R. Moskowitz Expires: 12 November 2021 R. Moskowitz
HTT Consulting HTT Consulting
A. Gurtov A. Gurtov
Linköping University Linköping University
27 April 2021 11 May 2021
Drone Remote Identification Protocol (DRIP) Requirements Drone Remote Identification Protocol (DRIP) Requirements
draft-ietf-drip-reqs-10 draft-ietf-drip-reqs-11
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 29 October 2021. This Internet-Draft will expire on 12 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
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . . . . . . . . . . 11 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 11
3. UAS RID Problem Space . . . . . . . . . . . . . . . . . . . . 19 3. UAS RID Problem Space . . . . . . . . . . . . . . . . . . . . 19
3.1. Network RID . . . . . . . . . . . . . . . . . . . . . . . 21 3.1. Network RID . . . . . . . . . . . . . . . . . . . . . . . 21
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.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 31
4.2. Identifier . . . . . . . . . . . . . . . . . . . . . . . 32 4.2. Identifier . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.1. Normative Requirements . . . . . . . . . . . . . . . 32
4.2.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 33
4.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3.1. Normative Requirements . . . . . . . . . . . . . . . 33
4.3.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 34
4.4. Registries . . . . . . . . . . . . . . . . . . . . . . . 35 4.4. Registries . . . . . . . . . . . . . . . . . . . . . . . 35
4.4.1. Normative Requirements . . . . . . . . . . . . . . . 35
4.4.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 36
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
6. Security Considerations . . . . . . . . . . . . . . . . . . . 36 6. Security Considerations . . . . . . . . . . . . . . . . . . . 36
7. Privacy and Transparency Considerations . . . . . . . . . . . 37 7. Privacy and Transparency Considerations . . . . . . . . . . . 37
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.1. Normative References . . . . . . . . . . . . . . . . . . 38 8.1. Normative References . . . . . . . . . . . . . . . . . . 38
8.2. Informative References . . . . . . . . . . . . . . . . . 38 8.2. Informative References . . . . . . . . . . . . . . . . . 38
Appendix A. Discussion and Limitations . . . . . . . . . . . . . 42 Appendix A. Discussion and Limitations . . . . . . . . . . . . . 43
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 43 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
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 30, line 20 skipping to change at page 30, line 20
The following requirements apply to DRIP as a set of related The following requirements apply to DRIP as a set of related
protocols, various subsets of which, in conjunction with other IETF protocols, various subsets of which, in conjunction with other IETF
and external technical standards, may suffice to comply with the and external technical standards, may suffice to comply with the
regulations in any given jurisdiction or meet any given user need. regulations in any given jurisdiction or meet any given user need.
It is not intended that each and every DRIP protocol alone satisfy It is not intended that each and every DRIP protocol alone satisfy
each and every requirement. each and every requirement.
4.1. General 4.1. General
4.1.1. Normative Requirements
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 binding all other
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, end-to-end strongly encrypted communications with per policy, strongly mutually authnenticated, end-to-end
the UAS RID sender and entities looked up from the UAS ID, strongly encrypted communications with the UAS RID sender and
including at least the remote pilot and USS. entities looked up from the UAS ID, including at least the
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, such as maximum
message transmission intervals and delivery latencies. 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).
skipping to change at page 31, line 32 skipping to change at page 31, line 33
link failure. DRIP SHOULD support multihoming of essentially link failure. DRIP SHOULD support multihoming of essentially
all participating nodes. all participating nodes.
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.
4.1.2. Rationale
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 [FRUR] regulatory QoS requirement currently would be here. The [FRUR] regulatory QoS requirement currently would be
satisfied by ensuring information refresh rates of at least 1 Hertz, satisfied by ensuring information refresh rates of at least 1 Hertz,
with latencies no greater than 1 second, at least 80% of the time, with latencies no greater than 1 second, at least 80% of the time,
but these numbers may vary between jurisdictions and over time. So but these numbers may vary between jurisdictions and over time. So
instead the DRIP QoS requirement is that performance, reliability, instead the DRIP QoS requirement is that performance, reliability,
etc. parameters be user policy specifiable, which does not imply etc. parameters be user policy specifiable, which does not imply
satisfiable in all cases, but (especially together with the satisfiable in all cases, but (especially together with the
management requirement) implies that when specifications are not met, management requirement) implies that when specifications are not met,
appropriate parties are notified. appropriate parties are notified.
The "provable ownership" requirement addresses the possibility that The "provable ownership" requirement addresses the possibility that
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 may the time of observing the UA. The "readability" requirement pertains
involve machine assisted format conversions, e.g., from binary to the structure and format of information at endpoints rather than
encodings. its encoding in transit, so may involve machine assisted format
conversions, e.g., from binary encodings, and/or decryption (see
Section 4.3). 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.
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.
4.2. Identifier 4.2. Identifier
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.
ID-3 Entity ID: The DRIP identifier MUST be sufficient to enable ID-3 Entity ID: The DRIP identifier MUST be sufficient to enable
lookups of other data associated with the entity identified lookups of other data associated with the entity identified
therewith in that registry. therewith in that registry.
skipping to change at page 33, line 11 skipping to change at page 33, line 11
within the context of a minimal Remote ID broadcast message set within the context of a minimal Remote ID broadcast message set
(to be specified within DRIP to be sufficient collectively to (to be specified within DRIP to be sufficient collectively to
prove sender ownership of the claimed identifier). prove sender ownership of the claimed identifier).
ID-6 Unlinkability: The DRIP identifier MUST NOT facilitate ID-6 Unlinkability: The DRIP identifier MUST NOT facilitate
adversarial correlation over multiple operations. If this is adversarial correlation over multiple operations. If this is
accomplished by limiting each identifier to a single use or accomplished by limiting each identifier to a single use or
brief period of usage, the DRIP identifier MUST support well- brief period of usage, the DRIP identifier MUST support well-
defined, scalable, timely registration methods. defined, scalable, timely registration methods.
4.2.2. Rationale
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 (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 HIP or DTLS). and transport layers, e.g., with the Host Identity Protocol (HIP,
[RFC4423], [RFC7401], etc.), or between the transport and application
layers, e.g., with Datagram Transport Layer Security (DTLS,
[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
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.
4.3. Privacy 4.3. Privacy
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
encryption of private data in motion in such a manner that encryption of private data in motion in such a manner that
only authorized actors can recover it. If transport is via only authorized actors can recover it. If transport is via
IP, then encryption MUST be end-to-end, at or above the IP IP, then encryption MUST be end-to-end, at or above the IP
layer. DRIP MUST NOT encrypt safety critical data to be layer. DRIP MUST NOT encrypt safety critical data to be
skipping to change at page 34, line 24 skipping to change at page 34, line 20
where doing so would conflict with applicable regulations or where doing so would conflict with applicable regulations or
CAA policies/procedures, i.e., DRIP MUST support configurable CAA policies/procedures, i.e., DRIP MUST support configurable
disabling of encryption. disabling of encryption.
PRIV-3 Encrypted Storage: DRIP SHOULD facilitate selective strong PRIV-3 Encrypted Storage: DRIP SHOULD facilitate selective strong
encryption of private data at rest in such a manner that only encryption of private data at rest in such a manner that only
authorized actors can recover it. authorized actors can recover it.
PRIV-4 Public/Private Designation: DRIP SHOULD facilitate PRIV-4 Public/Private Designation: DRIP SHOULD facilitate
designation, by cognizant authorities and information owners, designation, by cognizant authorities and information owners,
which information is public and which private. By default, of which information is public and which is private. By
all information required to be transmitted via Broadcast RID, default, all information required to be transmitted via
even when actually sent via Network RID, is assumed to be Broadcast RID, even when actually sent via Network RID or
public; all other information contained in registries for stored in registries, is assumed to be public; all other
lookup using the UAS ID is assumed to be private. information held in registries for lookup using the UAS ID is
assumed to be private.
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
Most data to be sent via Broadcast RID or Network RID is public, thus
the "encrypted transport" requirement for private data is selective,
e.g., for the entire payload of the Operator ID Message, but only the
pilot/GCS location fields of the System Message.
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).
How information is stored on end systems is out of scope for DRIP. How information is stored on end systems is out of scope for DRIP.
skipping to change at page 35, line 12 skipping to change at page 35, line 22
(which requires obfuscation of location to any Network RID subscriber (which requires obfuscation of location to any Network RID subscriber
engaging in wide area surveillance, limits data retention periods, engaging in wide area surveillance, limits data retention periods,
etc., in the interests of privacy), nor for UAS RID in any specific etc., in the interests of privacy), nor for UAS RID in any specific
jurisdiction (which may have its own regulatory requirements). The jurisdiction (which may have its own regulatory requirements). The
requirements above are also in a sense parameterized: who are the requirements above are also in a sense parameterized: who are the
"authorized actors", how are they designated, how are they "authorized actors", how are they designated, how are they
authenticated, etc.? authenticated, etc.?
4.4. Registries 4.4. Registries
4.4.1. Normative Requirements
REG-1 Public Lookup: DRIP MUST enable lookup, from the UAS ID, of REG-1 Public Lookup: DRIP MUST enable lookup, from the UAS ID, of
information designated by cognizant authority as public, and information designated by cognizant authority as public, and
MUST NOT restrict access to this information based on identity MUST NOT restrict access to this information based on identity
or role of the party submitting the query. or role of the party submitting the query.
REG-2 Private Lookup: DRIP MUST enable lookup of private information REG-2 Private Lookup: DRIP MUST enable lookup of private information
(i.e., any and all information in a registry, associated with (i.e., any and all information in a registry, associated with
the UAS ID, that is designated by neither cognizant authority the UAS ID, that is designated by neither cognizant authority
nor the information owner as public), and MUST, according to nor the information owner as public), and MUST, according to
applicable policy, enforce AAA, including restriction of applicable policy, enforce AAA, including restriction of
skipping to change at page 35, line 38 skipping to change at page 36, line 5
(including means by which the USS under which the UAS is (including means by which the USS under which the UAS is
operating may be contacted for further, typically even more operating may be contacted for further, typically even more
dynamic, information), and Internet direct contact information dynamic, information), and Internet direct contact information
for services related to the foregoing. for services related to the foregoing.
REG-4 AAA Policy: DRIP AAA MUST be specifiable by policies; the REG-4 AAA Policy: DRIP AAA MUST be specifiable by policies; the
definitive copies of those policies must be accessible in definitive copies of those policies must be accessible in
registries; administration of those policies and all DRIP registries; administration of those policies and all DRIP
registries must be protected by AAA. registries must be protected by AAA.
4.4.2. Rationale
Registries are fundamental to RID. Only very limited information can Registries are fundamental to RID. Only very limited information can
be Broadcast, but extended information is sometimes needed. The most be Broadcast, but extended information is sometimes needed. The most
essential element of information sent is the UAS ID itself, the essential element of information sent is the UAS ID itself, the
unique key for lookup of extended information in registries. Beyond unique key for lookup of extended information in registries. Beyond
designating the UAS ID as that unique key, the registry information designating the UAS ID as that unique key, the registry information
model is not specified herein, in part because regulatory model is not specified herein, in part because regulatory
requirements for different registries (UAS operators and their UA, requirements for different registries (UAS operators and their UA,
each narrowly for UAS RID and broadly for U-space/UTM) and business each narrowly for UAS RID and broadly for U-space/UTM) and business
models for meeting those requirements are in flux. However those may models for meeting those requirements are in flux. However those may
evolve, the essential registry functions remain the same, so are evolve, the essential registry functions remain the same, so are
specified herein. specified herein.
While most data to be sent via Broadcast or Network RID is public,
much of the extended information in registries will be private. Thus
AAA for registries is essential, not just to ensure that access is
granted only to strongly authenticated, duly authorized parties, but
also to support subsequent attribution of any leaks, audit of who
accessed information when and for what purpose, etc. As specific AAA
requirements will vary by jurisdictional regulation, provider
philosophy, customer demand, etc., they are left to specification in
policies, which should be human readable to facilitate analysis and
discussion, and machine readable to enable automated enforcement,
using a language amenable to both, e.g., XACML.
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 6 skipping to change at page 39, line 33
unmanned-aerial-systems-serial-numbers>. unmanned-aerial-systems-serial-numbers>.
[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,
<https://eur-lex.europa.eu/eli/reg_del/2019/945/oj>. <https://eur-lex.europa.eu/eli/reg_del/2019/945/oj>.
[drip-architecture] [drip-architecture]
Card, S., Wiethuechter, A., Moskowitz, R., Zhao, S., and Card, S. W., Wiethuechter, A., Moskowitz, R., Zhao, S.,
A. Gurtov, "Drone Remote Identification Protocol (DRIP) and A. Gurtov, "Drone Remote Identification Protocol
Architecture", Work in Progress, Internet-Draft, draft- (DRIP) Architecture", Work in Progress, Internet-Draft,
ietf-drip-arch-11, 23 February 2021, draft-ietf-drip-arch-11, 23 February 2021,
<https://tools.ietf.org/html/draft-ietf-drip-arch-11>. <https://tools.ietf.org/html/draft-ietf-drip-arch-11>.
[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,
<https://www.consilium.europa.eu/media/35805/easa- <https://www.consilium.europa.eu/media/35805/easa-
regulation-june-2018.pdf>. regulation-june-2018.pdf>.
[FAACONOPS] [FAACONOPS]
FAA Office of NextGen, "UTM Concept of Operations v2.0", FAA Office of NextGen, "UTM Concept of Operations v2.0",
March 2020, <https://www.faa.gov/uas/research_development/ March 2020, <https://www.faa.gov/uas/research_development/
traffic_management/media/UTM_ConOps_v2.pdf>. traffic_management/media/UTM_ConOps_v2.pdf>.
[FR24] Flightradar24 AB, "Flightradar24 Live Air Traffic", May
2021, <https://www.flightradar24.com/about>.
[FRUR] Federal Aviation Administration, "Remote Identification of [FRUR] Federal Aviation Administration, "Remote Identification of
Unmanned Aircraft", January 2021, Unmanned Aircraft", January 2021,
<https://www.federalregister.gov/ <https://www.federalregister.gov/
documents/2021/01/15/2020-28948/remote-identification-of- documents/2021/01/15/2020-28948/remote-identification-of-
unmanned-aircraft>. unmanned-aircraft>.
[GDPR] European Parliament and Council, "General Data Protection [GDPR] European Parliament and Council, "General Data Protection
Regulation", April 2016, Regulation", April 2016,
<https://eur-lex.europa.eu/eli/reg/2016/679/oj>. <https://eur-lex.europa.eu/eli/reg/2016/679/oj>.
skipping to change at page 40, line 48 skipping to change at page 41, line 30
"Notice of Proposed Rule Making on Remote Identification "Notice of Proposed Rule Making on Remote Identification
of Unmanned Aircraft Systems", December 2019, of Unmanned Aircraft Systems", December 2019,
<https://www.federalregister.gov/ <https://www.federalregister.gov/
documents/2019/12/31/2019-28100/remote-identification-of- documents/2019/12/31/2019-28100/remote-identification-of-
unmanned-aircraft-systems>. unmanned-aircraft-systems>.
[OpenDroneID] [OpenDroneID]
Intel Corp., "Open Drone ID", March 2019, Intel Corp., "Open Drone ID", March 2019,
<https://github.com/opendroneid/specs>. <https://github.com/opendroneid/specs>.
[OpenSky] OpenSky Network non-profit association, "The OpenSky
Network", May 2021,
<https://opensky-network.org/about/about-us>.
[Opinion1] European Union Aviation Safety Agency (EASA), "Opinion No [Opinion1] European Union Aviation Safety Agency (EASA), "Opinion No
01/2020: High-level regulatory framework for the U-space", 01/2020: High-level regulatory framework for the U-space",
March 2020, <https://www.easa.europa.eu/document- March 2020, <https://www.easa.europa.eu/document-
library/opinions/opinion-012020>. library/opinions/opinion-012020>.
[Part107] United States Federal Aviation Administration, "Code of [Part107] United States Federal Aviation Administration, "Code of
Federal Regulations Part 107", June 2016, Federal Regulations Part 107", June 2016,
<https://www.ecfr.gov/cgi-bin/text-idx?node=pt14.2.107>. <https://www.ecfr.gov/cgi-bin/text-idx?node=pt14.2.107>.
[Recommendations] [Recommendations]
skipping to change at page 41, line 21 skipping to change at page 42, line 10
Committee, "UAS ID and Tracking ARC Recommendations Final Committee, "UAS ID and Tracking ARC Recommendations Final
Report", September 2017, <https://www.faa.gov/regulations_ Report", September 2017, <https://www.faa.gov/regulations_
policies/rulemaking/committees/documents/media/ policies/rulemaking/committees/documents/media/
UAS%20ID%20ARC%20Final%20Report%20with%20Appendices.pdf>. UAS%20ID%20ARC%20Final%20Report%20with%20Appendices.pdf>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
DOI 10.17487/RFC4122, July 2005, DOI 10.17487/RFC4122, July 2005,
<https://www.rfc-editor.org/info/rfc4122>. <https://www.rfc-editor.org/info/rfc4122>.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, DOI 10.17487/RFC4423, May
2006, <https://www.rfc-editor.org/info/rfc4423>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>. <https://www.rfc-editor.org/info/rfc4949>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013, DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>. <https://www.rfc-editor.org/info/rfc6973>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)",
RFC 7401, DOI 10.17487/RFC7401, April 2015,
<https://www.rfc-editor.org/info/rfc7401>.
[RFC8280] ten Oever, N. and C. Cath, "Research into Human Rights [RFC8280] ten Oever, N. and C. Cath, "Research into Human Rights
Protocol Considerations", RFC 8280, DOI 10.17487/RFC8280, Protocol Considerations", RFC 8280, DOI 10.17487/RFC8280,
October 2017, <https://www.rfc-editor.org/info/rfc8280>. October 2017, <https://www.rfc-editor.org/info/rfc8280>.
[Roadmap] American National Standards Institute (ANSI) Unmanned [Roadmap] American National Standards Institute (ANSI) Unmanned
Aircraft Systems Standardization Collaborative (UASSC), Aircraft Systems Standardization Collaborative (UASSC),
"Standardization Roadmap for Unmanned Aircraft Systems "Standardization Roadmap for Unmanned Aircraft Systems
draft v2.0", April 2020, <https://share.ansi.org/Shared draft v2.0", April 2020, <https://share.ansi.org/Shared
Documents/Standards Activities/UASSC/ Documents/Standards Activities/UASSC/
UASSC_20-001_WORKING_DRAFT_ANSI_UASSC_Roadmap_v2.pdf>. UASSC_20-001_WORKING_DRAFT_ANSI_UASSC_Roadmap_v2.pdf>.
skipping to change at page 42, line 19 skipping to change at page 43, line 19
standard. Other organizations, for example in EU, do not necessary standard. Other organizations, for example in EU, do not necessary
follow the same architecture. follow the same architecture.
The need for drone ID and operator privacy is an open discussion The need for drone ID and operator privacy is an open discussion
topic. For instance, in the ground vehicular domain each car carries topic. For instance, in the ground vehicular domain each car carries
a publicly visible plate number. In some countries, for nominal cost a publicly visible plate number. In some countries, for nominal cost
or even for free, anyone can resolve the identity and contact or even for free, anyone can resolve the identity and contact
information of the owner. Civil commercial aviation and maritime information of the owner. Civil commercial aviation and maritime
industries also have a tradition of broadcasting plane or ship ID, industries also have a tradition of broadcasting plane or ship ID,
coordinates, and even flight plans in plain text. Community networks coordinates, and even flight plans in plain text. Community networks
such as OpenSky and Flightradar use this open information through such as OpenSky [OpenSky] and Flightradar24 [FR24] use this open
ADS-B to deploy public services of flight tracking. Many researchers information through ADS-B to deploy public services of flight
also use these data to perform optimization of routes and airport tracking. Many researchers also use these data to perform
operations. Such ID information should be integrity protected, but optimization of routes and airport operations. Such ID information
not necessarily confidential. should be integrity protected, but not necessarily confidential.
In civil aviation, aircraft identity is broadcast by a device known In civil aviation, aircraft identity is broadcast by a device known
as transponder. It transmits a four octal digit squawk code, which as transponder. It transmits a four octal digit squawk code, which
is assigned by a traffic controller to an airplane after approving a is assigned by a traffic controller to an airplane after approving a
flight plan. There are several reserved codes such as 7600 which flight plan. There are several reserved codes such as 7600 which
indicate radio communication failure. The codes are unique in each indicate radio communication failure. The codes are unique in each
traffic area and can be re-assigned when entering another control traffic area and can be re-assigned when entering another control
area. The code is transmitted in plain text by the transponder and area. The code is transmitted in plain text by the transponder and
also used for collision avoidance by a system known as Traffic alert also used for collision avoidance by a system known as Traffic alert
and Collision Avoidance System (TCAS). The system could be used for and Collision Avoidance System (TCAS). The system could be used for
 End of changes. 30 change blocks. 
29 lines changed or deleted 101 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/