draft-ietf-drip-reqs-17.txt   draft-ietf-drip-reqs-18.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: 8 January 2022 R. Moskowitz Expires: 12 March 2022 R. Moskowitz
HTT Consulting HTT Consulting
A. Gurtov A. Gurtov
Linköping University Linköping University
7 July 2021 8 September 2021
Drone Remote Identification Protocol (DRIP) Requirements Drone Remote Identification Protocol (DRIP) Requirements
draft-ietf-drip-reqs-17 draft-ietf-drip-reqs-18
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). DRIP identity based network sessions supporting UAS applications). DRIP
will facilitate use of existing Internet resources to support RID and will facilitate use of existing Internet resources to support RID and
to enable enhanced related services, and will enable online and to enable enhanced related services, and will enable online and
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 8 January 2022. This Internet-Draft will expire on 12 March 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 27 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 28 3.3. USS in UTM and RID . . . . . . . . . . . . . . . . . . . 29
3.4. DRIP Focus . . . . . . . . . . . . . . . . . . . . . . . 29 3.4. DRIP Focus . . . . . . . . . . . . . . . . . . . . . . . 29
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 30 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1.1. Normative Requirements . . . . . . . . . . . . . . . 30 4.1.1. Normative Requirements . . . . . . . . . . . . . . . 31
4.1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 32 4.1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 32
4.2. Identifier . . . . . . . . . . . . . . . . . . . . . . . 33 4.2. Identifier . . . . . . . . . . . . . . . . . . . . . . . 34
4.2.1. Normative Requirements . . . . . . . . . . . . . . . 33 4.2.1. Normative Requirements . . . . . . . . . . . . . . . 34
4.2.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 34 4.2.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 35
4.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3.1. Normative Requirements . . . . . . . . . . . . . . . 35 4.3.1. Normative Requirements . . . . . . . . . . . . . . . 36
4.3.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 36 4.3.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 37
4.4. Registries . . . . . . . . . . . . . . . . . . . . . . . 36 4.4. Registries . . . . . . . . . . . . . . . . . . . . . . . 37
4.4.1. Normative Requirements . . . . . . . . . . . . . . . 37 4.4.1. Normative Requirements . . . . . . . . . . . . . . . 38
4.4.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 37 4.4.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 38
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
6. Security Considerations . . . . . . . . . . . . . . . . . . . 38 6. Security Considerations . . . . . . . . . . . . . . . . . . . 39
7. Privacy and Transparency Considerations . . . . . . . . . . . 39 7. Privacy and Transparency Considerations . . . . . . . . . . . 40
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.1. Normative References . . . . . . . . . . . . . . . . . . 40 8.1. Normative References . . . . . . . . . . . . . . . . . . 41
8.2. Informative References . . . . . . . . . . . . . . . . . 40 8.2. Informative References . . . . . . . . . . . . . . . . . 42
Appendix A. Discussion and Limitations . . . . . . . . . . . . . 45 Appendix A. Discussion and Limitations . . . . . . . . . . . . . 46
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 46 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
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 13, line 15 skipping to change at page 13, line 15
provision of facilities and seamless services in collaboration provision of facilities and seamless services in collaboration
with all parties and involving airborne and ground-based with all parties and involving airborne and ground-based
functions" [ICAOATM]. functions" [ICAOATM].
Authentication Message Authentication Message
[F3411-19] Message Type 2. Provides framing for authentication [F3411-19] Message Type 2. Provides framing for authentication
data, only; the only message that can be extended in length by data, only; the only message that can be extended in length by
segmenting it across more than one page. segmenting it across more than one page.
Basic ID Message Basic ID Message
[F3411-19] Message Type 0. Provides UA Type, UAS ID Type, and UAS [F3411-19] Message Type 0. Provides UA Type, UAS ID Type (and
ID, only. Specific Session ID subtype if applicable), and UAS ID, only.
Broadcast Authentication Verifier Service Broadcast Authentication Verifier Service
System component designed to handle any authentication of System component designed to handle any authentication of
Broadcast RID by offloading signature verification to a web Broadcast RID by offloading signature verification to a web
service [F3411-19]. service [F3411-19].
BVLOS BVLOS
Beyond Visual Line Of Sight. See VLOS. Beyond Visual Line Of Sight. See VLOS.
byte byte
skipping to change at page 19, line 7 skipping to change at page 19, line 7
subsystems, any required launch and recovery equipment, all subsystems, any required launch and recovery equipment, all
required crew members, and C2 links between UA and control station required crew members, and C2 links between UA and control station
[F3411-19]. [F3411-19].
UAS ID UAS ID
UAS identifier. Although called "UAS ID", it is actually unique UAS identifier. Although called "UAS ID", it is actually unique
to the UA, neither to the operator (as some UAS registration to the UA, neither to the operator (as some UAS registration
numbers have been and for exclusively recreational purposes are numbers have been and for exclusively recreational purposes are
continuing to be assigned), nor to the combination of GCS and UA continuing to be assigned), nor to the combination of GCS and UA
that comprise the UAS. _Maximum length of 20 bytes_ [F3411-19]. that comprise the UAS. _Maximum length of 20 bytes_ [F3411-19].
If the UAS ID Type is 4, the proposed Specific Session ID, then
the 20 bytes includes the subtype index, leaving only 19 bytes for
the actual identifier.
UAS ID Type UAS ID Type
UAS Identifier type index. 4 bits, see Section 3, Paragraph 6 for UAS Identifier type index. 4 bits, see Section 3, Paragraph 6 for
currently defined values 0-3. [F3411-19] currently defined values 0-3. [F3411-19]
UAS RID UAS RID
UAS Remote Identification and tracking. System to enable UAS Remote Identification and tracking. System to enable
arbitrary Observers to identify UA during flight. arbitrary Observers to identify UA during flight.
USS USS
skipping to change at page 20, line 48 skipping to change at page 20, line 48
Network RID depends upon Internet connectivity in several segments Network RID depends upon Internet connectivity in several segments
from the UAS to each Observer. Broadcast RID should need Internet from the UAS to each Observer. Broadcast RID should need Internet
(or other Wide Area Network) connectivity only to retrieve UAS (or other Wide Area Network) connectivity only to retrieve UAS
registry information using the directly locally received UAS registry information using the directly locally received UAS
Identifier (UAS ID) as the primary unique key for database lookup. Identifier (UAS ID) as the primary unique key for database lookup.
Broadcast RID does not assume IP connectivity of UAS; messages are Broadcast RID does not assume IP connectivity of UAS; messages are
encapsulated by the UA _without IP_, directly in link layer frames encapsulated by the UA _without IP_, directly in link layer frames
(Bluetooth 4, Bluetooth 5, Wi-Fi NAN, IEEE 802.11 Beacon, or in the (Bluetooth 4, Bluetooth 5, Wi-Fi NAN, IEEE 802.11 Beacon, or in the
future perhaps others). future perhaps others).
[F3411-19] specifies three UAS ID Type values: [F3411-19] specifies three UAS ID Type values and its currently
(August 2021) proposed revision adds a fourth:
1 A static, manufacturer assigned, hardware serial number as defined 1 A static, manufacturer assigned, hardware serial number as defined
in ANSI/CTA-2063-A "Small Unmanned Aerial System Serial Numbers" in ANSI/CTA-2063-A "Small Unmanned Aerial System Serial Numbers"
[CTA2063A]. [CTA2063A].
2 A CAA assigned (generally static) ID, like the registration number 2 A CAA assigned (generally static) ID, like the registration number
of a manned aircraft. of a manned aircraft.
3 A UTM system assigned UUID [RFC4122], which can but need not be 3 A UTM system assigned UUID [RFC4122], which can but need not be
dynamic. dynamic.
4 A Specific Session ID, of any of an 8 bit range of subtypes
defined external to ASTM and registered with ICAO, for which
subtype 1 has been reserved by ASTM for the DRIP entity ID.
Per [Delegated], the EU allows only UAS ID Type 1. Under [FRUR], the Per [Delegated], the EU allows only UAS ID Type 1. Under [FRUR], the
US allows types 1 and 3. [NPRM] proposed that a type 3 "Session ID" US allows types 1 and 3. [NPRM] proposed that a type 3 "Session ID"
would be "e.g., a randomly-generated alphanumeric code assigned by a would be "e.g., a randomly-generated alphanumeric code assigned by a
Remote ID UAS Service Supplier (USS) on a per-flight basis designed Remote ID UAS Service Supplier (USS) on a per-flight basis designed
to provide additional privacy to the operator", but given the to provide additional privacy to the operator", but given the
omission of Network RID from [FRUR], how this is to be assigned in omission of Network RID from [FRUR], how this is to be assigned in
the US is still to be determined. the US is still to be determined.
As yet apparently there are no CAA public proposals to use UAS ID As yet apparently there are no CAA public proposals to use UAS ID
Type 2. In the preamble of [FRUR], the FAA argues that registration Type 2. In the preamble of [FRUR], the FAA argues that registration
skipping to change at page 28, line 33 skipping to change at page 28, line 33
certificates (e.g., X.509). Fetching certificates via the Internet certificates (e.g., X.509). Fetching certificates via the Internet
is not always possible (e.g., Observers working in remote areas, such is not always possible (e.g., Observers working in remote areas, such
as national forests), so devising a scheme whereby certificates can as national forests), so devising a scheme whereby certificates can
be transported over Broadcast RID is necessary. The one-way nature be transported over Broadcast RID is necessary. The one-way nature
of Broadcast RID precludes challenge-response security protocols of Broadcast RID precludes challenge-response security protocols
(e.g., Observers sending nonces to UA, to be returned in signed (e.g., Observers sending nonces to UA, to be returned in signed
messages). Without DRIP extensions to [F3411-19], an Observer would messages). Without DRIP extensions to [F3411-19], an Observer would
be seriously challenged to validate the asserted UAS ID or any other be seriously challenged to validate the asserted UAS ID or any other
information about the UAS or its operator looked up therefrom. information about the UAS or its operator looked up therefrom.
In the currently (2021) proposed revision to ASTM [F3411-19], a new
Authentication Type 5 has been defined, "Specific Authentication
Method" (SAM), to enable SDOs other than ASTM to define
authentication payload formats. The first byte of the payload is the
SAM Type, used to demultiplex such variant formats. All formats for
other than private experimental use must be registered with ICAO,
which assigns the SAM Type. Any authentication message payload that
is to be sent in exactly the same form over all currently specified
Broadcast RID media is limited by lower layer constraints to a total
length of 201 bytes. For Authentication Type 5, expected to be used
by DRIP, the SAM Type byte consumes the first of these, limiting DRIP
authentication payload formats to a maximum of 200 bytes.
3.3. USS in UTM and RID 3.3. USS in UTM and RID
UAS RID and UTM are complementary; Network RID is a UTM service. The UAS RID and UTM are complementary; Network RID is a UTM service. The
backbone of the UTM system is comprised of multiple USS: one or backbone of the UTM system is comprised of multiple USS: one or
several per jurisdiction; some limited to a single jurisdiction, several per jurisdiction; some limited to a single jurisdiction,
others spanning multiple jurisdictions. USS also serve as the others spanning multiple jurisdictions. USS also serve as the
principal or perhaps the sole interface for operators and UAS into principal or perhaps the sole interface for operators and UAS into
the UTM environment. Each operator subscribes to at least one USS. the UTM environment. Each operator subscribes to at least one USS.
Each UAS is registered by its operator in at least one USS. Each Each UAS is registered by its operator in at least one USS. Each
operational intent is submitted to one USS; if approved, that UAS and operational intent is submitted to one USS; if approved, that UAS and
skipping to change at page 30, line 34 skipping to change at page 31, line 12
RID standards such as [F3411-19], imply the following requirements RID standards such as [F3411-19], imply the following requirements
for DRIP. for DRIP.
4. Requirements 4. Requirements
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. To satisfy these requirements, Internet
connectivity is required some of the time: e.g., to support DRIP
entity identifier creation/registration; but not all of the time,
e.g., authentication of an asserted DRIP entity identifier can be
achieved by a fully working and provisioned Observer device even when
that device is off-line so is required at all times.
4.1. General 4.1. General
4.1.1. Normative Requirements 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 asserted entity (typically UAS) ID is that of the actual
current sender of the message (i.e., the message is not a current sender (i.e., the entity ID in the DRIP authenticated
replay attack or other spoof, authenticating, e.g., by message set is not a replay attack or other spoof, 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 UAS ID can
at least partially derived), even on an Observer device be 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 the cryptographic binding GEN-2 Provable Binding: DRIP MUST enable the cryptographic binding
of all other [F3411-19] messages from the same actual current of all other [F3411-19] messages from the same actual current
sender to 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 cryptographically GEN-3 Provable Registration: DRIP MUST enable cryptographically
secure verification that the UAS ID is in a registry and secure verification that the UAS ID is in a registry and
identification of that registry, even on an Observer device identification of that registry, even on an Observer device
lacking Internet connectivity at the time of observation; lacking Internet connectivity at the time of observation; the
with UAS ID Type 3, the same sender may have multiple IDs, same sender may have multiple IDs, potentially in different
potentially in different registries, but each ID must clearly registries, but each ID must clearly indicate in which
indicate in which registry it can be found. 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) whenever
the gateway has Internet connectivity.
GEN-6 Contact: DRIP MUST enable dynamically establishing, with AAA, GEN-6 Contact: DRIP MUST enable dynamically establishing, with AAA,
per policy, strongly mutually authenticated, 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
pilot (remote pilot or Pilot In Command), the USS (if any) pilot (remote pilot or Pilot In Command), the USS (if any)
under which the operation is being conducted, and registries under which the operation is being conducted, and registries
in which data on the UA and pilot are held. in which data on the UA and pilot are held, whenever each
party to such desired communications has a currently usable
means of resolving the other party's DRIP entity identifier
to a locator (IP address) and currently usable bidirectional
IP (not necessarily Internet) connectivity with the other
party.
GEN-7 QoS: DRIP MUST enable policy based specification of GEN-7 QoS: DRIP MUST enable policy based specification of
performance and reliability parameters. performance and reliability parameters.
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 33, line 25 skipping to change at page 34, line 25
The "mobility" requirement refers to rapid geographic mobility of The "mobility" requirement refers to rapid geographic mobility of
nodes, changes of their points of attachment to networks, and changes nodes, changes of their points of attachment to networks, and changes
to their IP addresses; it is not limited to micro-mobility within a to their IP addresses; it is not limited to micro-mobility within a
small geographic area or single Internet access provider. 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 19
bytes, to fit in the UAS ID field of the Basic ID message of bytes, to fit in the Specific Session ID subfield of the UAS ID
[F3411-19]. field of the Basic ID message of the currently (August 2021)
proposed revision of [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.
ID-4 Uniqueness: The DRIP identifier MUST be unique within the ID-4 Uniqueness: The DRIP identifier MUST be unique within the
applicable global identifier space from when it is first applicable global identifier space from when it is first
skipping to change at page 34, line 21 skipping to change at page 35, line 21
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 (not required by DRIP but generally used by Network RID over HTTPS (not required by DRIP but generally used by Network RID
implementations) and possibly other protocols. In RID initiated V2X 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 [RFC9063], [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
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.
skipping to change at page 39, line 37 skipping to change at page 40, line 37
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. See also Figure 1 and the software on the Observer's device. See also Figure 1 and the
associated explanatory text, especially the second paragraph after associated explanatory text, especially the second paragraph after
the figure. Thus there may be caveats on the extent to which the figure. Thus there may be caveats on the extent to which
requirements can be satisfied in such cases, yet strenuous effort requirements can be satisfied in such cases, yet strenuous effort
should be made to satisfy them, as such cases, e.g., firefighting in should be made to satisfy them, as such cases, e.g., firefighting in
a national forest, are important. a national forest, are important. Each numbered requirement _a
priori_ expected to suffer from such limitations (General
requirements for Gateway and Contact functionality) contains language
stating when it applies.
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."
Privacy and transparency (where essential to security or safety) are Privacy and transparency (where essential to security or safety) are
also ethical and moral imperatives. Even in cases where old also ethical and moral imperatives. Even in cases where old
practices (e.g., automobile registration plates) could be imitated, practices (e.g., automobile registration plates) could be imitated,
when new applications involving PII (such as UAS RID) are addressed when new applications involving PII (such as UAS RID) are addressed
and newer technologies could enable improving privacy, such and newer technologies could enable improving privacy, such
opportunities should not be squandered. Thus it is recommended that opportunities should not be squandered. Thus it is recommended that
all DRIP work give due regard to [RFC6973] and more broadly all DRIP work give due regard to [RFC6973] and more broadly
[RFC8280]. [RFC8280].
However, privacy and transparency are often conflicting goals, However, privacy and transparency are often conflicting goals,
skipping to change at page 41, line 36 skipping to change at page 42, line 38
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. W., Wiethuechter, A., Moskowitz, R., Zhao, S., Card, S. W., Wiethuechter, A., Moskowitz, R., Zhao, S.,
and A. Gurtov, "Drone Remote Identification Protocol and A. Gurtov, "Drone Remote Identification Protocol
(DRIP) Architecture", Work in Progress, Internet-Draft, (DRIP) Architecture", Work in Progress, Internet-Draft,
draft-ietf-drip-arch-11, 23 February 2021, draft-ietf-drip-arch-15, 25 July 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-drip- <https://datatracker.ietf.org/doc/html/draft-ietf-drip-
arch-11>. arch-15>.
[ENISACSIRT] [ENISACSIRT]
European Union Agency for Cybersecurity (ENISA), European Union Agency for Cybersecurity (ENISA),
"Actionable information for Security Incident Response", "Actionable information for Security Incident Response",
November 2014, <https://www.enisa.europa.eu/topics/csirt- November 2014, <https://www.enisa.europa.eu/topics/csirt-
cert-services/reactive-services/copy_of_actionable- cert-services/reactive-services/copy_of_actionable-
information>. information>.
[EU2018] European Parliament and Council, "2015/0277 (COD) PE-CONS [EU2018] European Parliament and Council, "2015/0277 (COD) PE-CONS
2/18", February 2018, 2/18", February 2018,
skipping to change at page 42, line 23 skipping to change at page 43, line 23
[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>.
[I-D.maeurer-raw-ldacs] [I-D.ietf-raw-ldacs]
Maeurer, N., Graeupl, T., and C. Schmitt, "L-band Digital Maeurer, N., Graeupl, T., and C. Schmitt, "L-band Digital
Aeronautical Communications System (LDACS)", Work in Aeronautical Communications System (LDACS)", Work in
Progress, Internet-Draft, draft-maeurer-raw-ldacs-06, 2 Progress, Internet-Draft, draft-ietf-raw-ldacs-08, 10 May
October 2020, <https://datatracker.ietf.org/doc/html/ 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-
draft-maeurer-raw-ldacs-06>. raw-ldacs-08>.
[ICAOATM] International Civil Aviation Organization, "Doc 4444: [ICAOATM] International Civil Aviation Organization, "Doc 4444:
Procedures for Air Navigation Services: Air Traffic Procedures for Air Navigation Services: Air Traffic
Management", November 2016, <https://store.icao.int/en/ Management", November 2016, <https://store.icao.int/en/
procedures-for-air-navigation-services-air-traffic- procedures-for-air-navigation-services-air-traffic-
management-doc-4444>. management-doc-4444>.
[ICAODEFS] International Civil Aviation Organization, "Defined terms [ICAODEFS] International Civil Aviation Organization, "Defined terms
from the Annexes to the Chicago Convention and ICAO from the Annexes to the Chicago Convention and ICAO
guidance material", July 2017, guidance material", July 2017,
skipping to change at page 44, line 10 skipping to change at page 45, 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 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/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
skipping to change at page 44, line 37 skipping to change at page 45, line 33
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)", Henderson, "Host Identity Protocol Version 2 (HIPv2)",
RFC 7401, DOI 10.17487/RFC7401, April 2015, RFC 7401, DOI 10.17487/RFC7401, April 2015,
<https://www.rfc-editor.org/info/rfc7401>. <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>.
[RFC9063] Moskowitz, R., Ed. and M. Komu, "Host Identity Protocol
Architecture", RFC 9063, DOI 10.17487/RFC9063, July 2021,
<https://www.rfc-editor.org/info/rfc9063>.
[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>.
[Stranger] Heinlein, R.A., "Stranger in a Strange Land", June 1961. [Stranger] Heinlein, R.A., "Stranger in a Strange Land", June 1961.
[WG105] EUROCAE, "WG-105 draft ED-282 Minimum Operational [WG105] EUROCAE, "WG-105 draft ED-282 Minimum Operational
skipping to change at page 46, line 25 skipping to change at page 47, line 25
impose additional restrictions on packet sizes and frequency of impose additional restrictions on packet sizes and frequency of
transmissions, but could provide better energy efficiency and range. transmissions, but could provide better energy efficiency and range.
In civil aviation, Controller-Pilot Data Link Communications (CPDLC) In civil aviation, Controller-Pilot Data Link Communications (CPDLC)
is used to transmit command and control between the pilots and ATC. is used to transmit command and control between the pilots and ATC.
It could be considered for UAS as well due to long range and proven It could be considered for UAS as well due to long range and proven
use despite its lack of security [CPDLC]. use despite its lack of security [CPDLC].
L-band Digital Aeronautical Communications System (LDACS) is being L-band Digital Aeronautical Communications System (LDACS) is being
standardized by ICAO and IETF for use in future civil aviation standardized by ICAO and IETF for use in future civil aviation
[I-D.maeurer-raw-ldacs]. It provides secure communication, [I-D.ietf-raw-ldacs]. It provides secure communication, positioning,
positioning, and control for aircraft using a dedicated radio band. and control for aircraft using a dedicated radio band. It should be
It should be analyzed as a potential provider for UAS RID as well. analyzed as a potential provider for UAS RID as well. This will
This will bring the benefit of a global integrated system creating a bring the benefit of a global integrated system creating a global
global airspace use awareness. airspace use awareness.
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
 End of changes. 29 change blocks. 
62 lines changed or deleted 97 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/