draft-ietf-drip-arch-07.txt   draft-ietf-drip-arch-08.txt 
drip S. Card drip S. Card
Internet-Draft A. Wiethuechter Internet-Draft A. Wiethuechter
Intended status: Informational AX Enterprize Intended status: Informational AX Enterprize
Expires: 3 July 2021 R. Moskowitz Expires: 25 July 2021 R. Moskowitz
HTT Consulting HTT Consulting
S. Zhao (Editor) S. Zhao (Editor)
Tencent Tencent
A. Gurtov A. Gurtov
Linkoeping University Linkoeping University
30 December 2020 21 January 2021
Drone Remote Identification Protocol (DRIP) Architecture Drone Remote Identification Protocol (DRIP) Architecture
draft-ietf-drip-arch-07 draft-ietf-drip-arch-08
Abstract Abstract
This document defines an architecture for protocols and services to This document defines an architecture for protocols and services to
support Unmanned Aircraft System Remote Identification and tracking support Unmanned Aircraft System Remote Identification and tracking
(UAS RID), plus RID-related communications, including required (UAS RID), plus RID-related communications, including required
architectural building blocks and their interfaces. architectural building blocks and their interfaces.
Status of This Memo Status of This Memo
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 3 July 2021. This Internet-Draft will expire on 25 July 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview UAS Remote ID (RID) and RID Standardization . . 3 1.1. Overview UAS Remote ID (RID) and RID Standardization . . 3
1.2. Overview of Types of UAS Remote ID . . . . . . . . . . . 4 1.2. Overview of Types of UAS Remote ID . . . . . . . . . . . 4
1.2.1. Network RID . . . . . . . . . . . . . . . . . . . . . 4 1.2.1. Broadcast RID . . . . . . . . . . . . . . . . . . . . 4
1.2.2. Broadcast RID . . . . . . . . . . . . . . . . . . . . 5 1.2.2. Network RID . . . . . . . . . . . . . . . . . . . . . 5
1.3. Overview of USS Interoperability . . . . . . . . . . . . 5 1.3. Overview of USS Interoperability . . . . . . . . . . . . 6
1.4. Overview of DRIP Architecture . . . . . . . . . . . . . . 6 1.4. Overview of DRIP Architecture . . . . . . . . . . . . . . 6
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Definitions and Abbreviations . . . . . . . . . . . . . . . . 8 3. Definitions and Abbreviations . . . . . . . . . . . . . . . . 8
3.1. Additional Definitions . . . . . . . . . . . . . . . . . 8 3.1. Additional Definitions . . . . . . . . . . . . . . . . . 8
3.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Claims, Assertions, Attestations, and Certificates . . . 9 3.3. Claims, Assertions, Attestations, and Certificates . . . 9
4. HHIT for UAS Remote ID . . . . . . . . . . . . . . . . . . . 10 4. HHIT for UAS Remote ID . . . . . . . . . . . . . . . . . . . 10
4.1. UAS Remote Identifiers Problem Space . . . . . . . . . . 10 4.1. UAS Remote Identifiers Problem Space . . . . . . . . . . 10
4.2. HIT as A Trustworthy UAS Remote ID . . . . . . . . . . . 11 4.2. HIT as A Trustworthy UAS Remote ID . . . . . . . . . . . 11
4.3. HHIT for Remote ID Registration and Lookup . . . . . . . 11 4.3. HHIT for Remote ID Registration and Lookup . . . . . . . 11
4.4. HHIT for Remote ID Encryption . . . . . . . . . . . . . . 13 4.4. HHIT for Remote ID Encryption . . . . . . . . . . . . . . 12
5. DRIP HHIT RID Registration and Registries . . . . . . . . . . 13 5. DRIP HHIT RID Registration and Registries . . . . . . . . . . 13
5.1. Public Information Registry . . . . . . . . . . . . . . . 13 5.1. Public Information Registry . . . . . . . . . . . . . . . 13
5.1.1. Background . . . . . . . . . . . . . . . . . . . . . 13 5.1.1. Background . . . . . . . . . . . . . . . . . . . . . 13
5.1.2. Proposed Approach . . . . . . . . . . . . . . . . . . 14 5.1.2. Proposed Approach . . . . . . . . . . . . . . . . . . 13
5.2. Private Information Registry . . . . . . . . . . . . . . 14 5.2. Private Information Registry . . . . . . . . . . . . . . 13
5.2.1. Background . . . . . . . . . . . . . . . . . . . . . 14 5.2.1. Background . . . . . . . . . . . . . . . . . . . . . 14
5.2.2. Proposed Approach . . . . . . . . . . . . . . . . . . 14 5.2.2. Proposed Approach . . . . . . . . . . . . . . . . . . 14
6. Harvesting Broadcast Remote ID messages for UTM Inclusion . . 15 6. Harvesting Broadcast Remote ID messages for UTM Inclusion . . 14
6.1. The CS-RID Finder . . . . . . . . . . . . . . . . . . . . 16 6.1. The CS-RID Finder . . . . . . . . . . . . . . . . . . . . 15
6.2. The CS-RID SDSP . . . . . . . . . . . . . . . . . . . . . 16 6.2. The CS-RID SDSP . . . . . . . . . . . . . . . . . . . . . 15
7. DRIP Transactions Enabling Trustworthy . . . . . . . . . . . 16 7. DRIP Transactions Enabling Trustworthy . . . . . . . . . . . 16
8. Privacy for Broadcast PII . . . . . . . . . . . . . . . . . . 17 8. Privacy for Broadcast PII . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Overview of Unmanned Aircraft Systems (UAS) Appendix A. Overview of Unmanned Aircraft Systems (UAS)
Traffic . . . . . . . . . . . . . . . . . . . . . . . . . 21 Traffic . . . . . . . . . . . . . . . . . . . . . . . . . 20
A.1. Operation Concept . . . . . . . . . . . . . . . . . . . . 21 A.1. Operation Concept . . . . . . . . . . . . . . . . . . . . 20
A.2. UAS Service Supplier (USS) . . . . . . . . . . . . . . . 22 A.2. UAS Service Supplier (USS) . . . . . . . . . . . . . . . 21
A.3. UTM Use Cases for UAS Operations . . . . . . . . . . . . 22 A.3. UTM Use Cases for UAS Operations . . . . . . . . . . . . 21
A.4. Automatic Dependent Surveillance Broadcast (ADS-B) . . . 23 A.4. Automatic Dependent Surveillance Broadcast (ADS-B) . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
This document describes a natural Internet and MAC-layer broadcast- This document describes an architecture for protocols and services to
based architecture for Unmanned Aircraft System Remote Identification support Unmanned Aircraft System Remote Identification and tracking
and tracking (UAS RID), conforming to proposed regulations and (UAS RID), plus RID-related communications, conforming to proposed
external technical standards, satisfying the requirements listed in regulations and external technical standards, satisfying the
the companion requirements document [I-D.ietf-drip-reqs]. requirements listed in the companion requirements document
[I-D.ietf-drip-reqs].
Many considerations (especially safety) dictate that UAS be remotely Many considerations (especially safety) dictate that UAS be remotely
identifiable. Civil Aviation Authorities (CAAs) worldwide are identifiable. Civil Aviation Authorities (CAAs) worldwide are
mandating Unmanned Aircraft Systems (UAS) Remote Identification mandating Unmanned Aircraft Systems (UAS) Remote Identification
(RID). CAAs currently (2020) promulgate performance-based (RID). CAAs currently (2020) promulgate performance-based
regulations that do not specify techniques, but rather cite industry regulations that do not specify techniques, but rather cite industry
consensus technical standards as acceptable means of compliance. consensus technical standards as acceptable means of compliance.
1.1. Overview UAS Remote ID (RID) and RID Standardization 1.1. Overview UAS Remote ID (RID) and RID Standardization
skipping to change at page 3, line 46 skipping to change at page 4, line 4
ASTM [F3411-19] Standard Specification for Remote ID and Tracking. ASTM [F3411-19] Standard Specification for Remote ID and Tracking.
ASTM defines one set of RID information and two means, MAC-layer ASTM defines one set of RID information and two means, MAC-layer
broadcast and IP-layer network, of communicating it. If a UAS broadcast and IP-layer network, of communicating it. If a UAS
uses both communication methods, generally the same information uses both communication methods, generally the same information
must provided via both means. The [F3411-19] is cited by FAA in must provided via both means. The [F3411-19] is cited by FAA in
its RID [NPRM] as "one potential means of compliance" to a Remote its RID [NPRM] as "one potential means of compliance" to a Remote
ID rule. ID rule.
3GPP 3GPP
With release 16, 3GPP completed the UAS RID requirement study With release 16, 3GPP completed the UAS RID requirement study
[TS-22.825] and proposed use cases in the mobile network and the [TS-22.825] and proposed use cases in the mobile network and the
services that can be offered based on RID. Release 17 services that can be offered based on RID. Release 17
specification works on enhanced UAS service requirements and specification works on enhanced UAS service requirements and
provides the protocol and application architecture support which provides the protocol and application architecture support which
is applicable for both 4G and 5G network. is applicable for both 4G and 5G network.
1.2. Overview of Types of UAS Remote ID 1.2. Overview of Types of UAS Remote ID
1.2.1. Network RID 1.2.1. Broadcast RID
A set of RID messages are defined for direct, one-way, broadcast
transmissions from the UA over Bluetooth or Wi-Fi. These are
currently defined as MAC-Layer messages. Internet (or other Wide
Area Network) connectivity is only needed for UAS registry
information lookup by observers using the locally directly received
UAS RID as a key. Broadcast RID should be functionally usable in
situations with no Internet connectivity.
The Broadcast RID is illustrated in Figure 1 below.
x x UA
xxxxx
|
|
| app messages directly over
| one-way RF data link (no IP)
|
|
+
x
xxxxx
x
x
x x Observer's device (e.g. smartphone)
x x
Figure 1
With Broadcast RID, an Observer is limited to their radio "visible"
airspace for UAS awareness and information. With Internet queries
using harvested RID, the Observer may gain more information about
those visible UAS.
1.2.2. Network RID
A RID data dictionary and data flow for Network RID are defined in A RID data dictionary and data flow for Network RID are defined in
[F3411-19]. This data flow is from a UAS via unspecified means (but [F3411-19]. This data flow is from a UAS via unspecified means (but
at least in part over the Internet) to a Network Remote ID Service at least in part over the Internet) to a Network Remote ID Service
Provider (Net-RID SP). These Net-RID SPs provide this information to Provider (Net-RID SP). These Net-RID SPs provide the RID data
Network Remote ID Display Providers (Net-RID DP). It is the Net-RID information to Network Remote ID Display Providers (Net-RID DP). It
DP that respond to queries from Network Remote ID clients (expected is the Net-RID DP that responds to queries from Network Remote ID
typically, but not specified exclusively, to be web based) specifying observers (expected typically, but not specified exclusively, to be
airspace volumes of interest. Network RID depends upon connectivity, web based) specifying airspace volumes of interest. Network RID
in several segments, via the Internet, from the UAS to the observer. depends upon connectivity, in several segments, via the Internet,
from the UAS to the observer.
The Network RID is illustrated in Figure 1 below: The Network RID is illustrated in Figure 2 below:
x x UA x x UA
xxxxx ******************** xxxxx ********************
| \ * ------*---+------------+ | \ * ------*---+------------+
| \ * / * | NET_RID_SP | | \ * / * | NET_RID_SP |
| \ * ------------/ +---*--+------------+ | \ * ------------/ +---*--+------------+
| RF \ */ | * | RF \ */ | *
| * INTERNET | * +------------+ | * INTERNET | * +------------+
| /* +---*--| NET_RID_DP | | /* +---*--| NET_RID_DP |
| / * +---*--+------------+ | / * +---*--+------------+
+ / * | * + / * | *
x / *****************|*** x x / *****************|*** x
xxxxx | xxxxx xxxxx | xxxxx
x +------- x x +------- x
x x x x
x x Operator (GCS) Observer x x x x Operator (GCS) Observer x x
x x x x x x x x
Figure 1 Figure 2
Via the direct Radio Frequency (RF) link between the UA and GCS, Via the direct Radio Frequency (RF) link between the UA and GCS,
Command and Control (C2) flows between the GCS to the UA such that Command and Control (C2) flows between the GCS to the UA such that
either can communicate with the Net-RID SP. For all but the simplest either can communicate with the Net-RID SP. For all but the simplest
hobby aircraft, position and status flow from the UA to the GCS and hobby aircraft, position and status flow from the UA to the GCS and
on to the Net-RID SP. Thus via the Internet, through three distinct on to the Net-RID SP. Thus via the Internet, through three distinct
segments, Network RID information flows from the UAS to the Observer. segments, Network RID information flows from the UAS to the Observer.
1.2.2. Broadcast RID Informative note: The RF link between UA and GCS is not in
scope of the Network RID.
A set of RID messages are defined for direct, one-way, broadcast
transmissions from the UA over Bluetooth or Wi-Fi. These are
currently defined as MAC-Layer messages. Internet (or other Wide
Area Network) connectivity is only needed for UAS registry
information lookup by Observers using the locally directly received
UAS RID as a key. Broadcast RID should be functionally usable in
situations with no Internet connectivity.
The Broadcast RID is illustrated in Figure 2 below.
x x UA
xxxxx
|
|
| app messages directly over
| one-way RF data link (no IP)
|
|
+
x
xxxxx
x
x
x x Observer's device (e.g. smartphone)
x x
Figure 2
With Broadcast RID, an Observer is limited to their radio "visible"
airspace for UAS awareness and information. With Internet queries
using harvested RID, the Observer may gain more information about
those visible UAS.
1.3. Overview of USS Interoperability 1.3. Overview of USS Interoperability
Each UAS is registered to at least one USS. With Net-RID, there is Each UAS is registered to at least one USS. With Net-RID, there is
direct communication between the UAS and its USS. With Broadcast- direct communication between the UAS and its USS. With Broadcast-
RID, the UAS Operator has either pre-filed a 4D space volume for USS RID, the UAS Operator has either pre-filed a 4D space volume for USS
operational knowledge and/or Observers can be providing information operational knowledge and/or Observers can be providing information
about observed UA to a USS. USS exchange information via a Discovery about observed UA to a USS. USS exchange information via a Discovery
and Synchronization Service (DSS) so all USS have knowledge about all and Synchronization Service (DSS) so all USS have knowledge about all
activities in a 4D airspace. The interactions among observer, UA and activities in a 4D airspace. The interactions among observer, UA and
skipping to change at page 10, line 38 skipping to change at page 10, line 38
4.1. UAS Remote Identifiers Problem Space 4.1. UAS Remote Identifiers Problem Space
A DRIP UAS ID needs to be "Trustworthy". This means that within the A DRIP UAS ID needs to be "Trustworthy". This means that within the
framework of the RID messages, an observer can establish that the RID framework of the RID messages, an observer can establish that the RID
used does uniquely belong to the UA. That the only way for any other used does uniquely belong to the UA. That the only way for any other
UA to assert this RID would be to steal something from within the UA. UA to assert this RID would be to steal something from within the UA.
The RID is self-generated by the UAS (either UA or GCS) and The RID is self-generated by the UAS (either UA or GCS) and
registered with the USS. registered with the USS.
Within the limitations of Broadcast RID, this is extremely The data communication of using Broadcast RID faces extreme
challenging as: challenging due to the limitation set by regulations. The ASTM
[F3411-19] defines the Basic RID message which is expected to
* An RID can at most be 20 characters. contained certain RID data and the Authentication message. The Basic
RID message has a maximum payload of 25 bytes and the maximum size
* The ASTM Basic RID message (the message containing the RID) is 25 allocated by ASTM for the RID is 20 bytes and only 3 bytes are left
characters; only 3 characters are currently unused. unused. currently, the authentication maximum payload is defined to
be 224 bytes.
* The ASTM Authentication message, with some changes from [F3411-19]
can carry 224 bytes of payload.
Standard approaches like X.509 and PKI will not fit these Standard approaches like X.509 and PKI will not fit these
constraints, even using the new EdDSA [RFC8032] algorithm. An constraints, even using the new EdDSA An example of a technology that
example of a technology that will fit within these limitations is an will fit within these limitations is an enhancement of the Host
enhancement of the Host Identity Tag (HIT) of HIPv2 [RFC7401] Identity Tag (HIT) of HIPv2 [RFC8032] algorithm.[RFC7401] using
introducing hierarchy as defined in HHIT [I-D.ietf-drip-rid]; using Hierarchical HITs (HHITs) for UAS RID is outlined in HHIT based UAS
Hierarchical HITs for UAS RID is outlined in HHIT based UAS RID RID [I-D.ietf-drip-rid]. As PKI with X.509 is being used in other
[I-D.ietf-drip-rid]. As PKI with X.509 is being used in other
systems with which UAS RID must interoperate (e.g. the UTM Discovery systems with which UAS RID must interoperate (e.g. the UTM Discovery
and Synchronization Service and the UTM InterUSS protocol) mappings and Synchronization Service and the UTM InterUSS protocol) mappings
between the more flexible but larger X.509 certificates and the HHIT between the more flexible but larger X.509 certificates and the HHIT
based structures must be devised. based structures must be devised.
By using the EdDSA HHIT suite, self-assertions of the RID can be done By using the EdDSA HHIT suite, self-assertions of the RID can be done
in as little as 84 bytes. Third-party assertions can be done in 200 in as little as 84 bytes. Third-party assertions can be done in 200
bytes. An observer would need Internet access to validate a self- bytes. An observer would need Internet access to validate a self-
assertion claim. A third-party assertion can be validated via a assertion claim. A third-party assertion can be validated via a
small credential cache in a disconnected environment. This third- small credential cache in a disconnected environment. This third-
skipping to change at page 11, line 44 skipping to change at page 11, line 41
of second-preimage resistance. The cryptographically-bound addition of second-preimage resistance. The cryptographically-bound addition
of the Hierarchy and a HHIT registration process (e.g. based on of the Hierarchy and a HHIT registration process (e.g. based on
Extensible Provisioning Protocol, [RFC5730]) provide complete, global Extensible Provisioning Protocol, [RFC5730]) provide complete, global
HHIT uniqueness. This is in contrast to general IDs (e.g. a UUID or HHIT uniqueness. This is in contrast to general IDs (e.g. a UUID or
device serial number) as the subject in an X.509 certificate. device serial number) as the subject in an X.509 certificate.
4.3. HHIT for Remote ID Registration and Lookup 4.3. HHIT for Remote ID Registration and Lookup
Remote IDs need a deterministic lookup mechanism that rapidly Remote IDs need a deterministic lookup mechanism that rapidly
provides actionable information about the identified UA. The ID provides actionable information about the identified UA. The ID
itself needs to be the key into the lookup given the constraints itself needs to be the inquiry input into the lookup given the
imposed by some of the broadcast media. This can best be achieved by constraints imposed by some of the broadcast media. This can best be
an ID registration hierarchy cryptographically embedded within the achieved by an ID registration hierarchy cryptographically embedded
ID. within the ID.
The original proposal for HITs included a registration hierarchy
scheme. This was dropped during HIP development for lack of a use
case. No similar mechanism is possible within CGAs. It is a rather
straightforward design update to HITs to Hierarchical HITs (HHITs) to
meet the UAS Remote ID use case.
The HHIT needs to consist of a registration hierarchy, the hashing The HHIT needs to consist of a registration hierarchy, the hashing
crypto suite information, and the hash of these items along with the crypto suite information, and the hash of these items along with the
underlying public key. Additional information, e.g. an IPv6 prefix, underlying public key. Additional information, e.g. an IPv6 prefix,
may enhance the HHITs use beyond the basic Remote ID function (e.g. may enhance the HHITs use beyond the basic Remote ID function (e.g.
use in HIP, [RFC7401]). use in HIP, [RFC7401]).
A DRIP UAS ID SHOULD be a HHIT. It SHOULD be self-generated by the A DRIP UAS ID SHOULD be a HHIT. It SHOULD be self-generated by the
UAS (either UA or GCS) and MUST be registered with the Private UAS (either UA or GCS) and MUST be registered with the Private
Information Registry identified in its hierarchy fields. Each UAS ID Information Registry (More details in Section 5.2) identified in its
HHIT MUST NOT be used more than once, with one exception as follows. hierarchy fields. Each UAS ID HHIT MUST NOT be used more than once,
with one exception as follows.
Each UA MAY be assigned, by its manufacturer, a single HI and derived Each UA MAY be assigned, by its manufacturer, a single HI and derived
HHIT encoded as a hardware serial number per [CTA2063A]. Such a HHIT encoded as a hardware serial number per [CTA2063A]. Such a
static HHIT SHOULD be used only to bind one-time use UAS IDs (other static HHIT SHOULD be used only to bind one-time use UAS IDs (other
HHITs) to the unique UA. Depending upon implementation, this may HHITs) to the unique UA. Depending upon implementation, this may
leave a HI private key in the possession of the manufacturer (see leave a HI private key in the possession of the manufacturer (see
Security Considerations). Security Considerations).
Each UA equipped for Broadcast RID MUST be provisioned not only with Each UA equipped for Broadcast RID MUST be provisioned not only with
its HHIT but also with the HI public key from which the HHIT was its HHIT but also with the HI public key from which the HHIT was
skipping to change at page 16, line 11 skipping to change at page 15, line 36
Crowd Sourced Remote ID (CS-RID) would be a significant enhancement, Crowd Sourced Remote ID (CS-RID) would be a significant enhancement,
beyond baseline DRIP functionality; if implemented, it adds two more beyond baseline DRIP functionality; if implemented, it adds two more
entity types. entity types.
6.1. The CS-RID Finder 6.1. The CS-RID Finder
A CS-RID Finder is the gateway for Broadcast Remote ID Messages into A CS-RID Finder is the gateway for Broadcast Remote ID Messages into
the UTM. It performs this gateway function via a CS-RID SDSP. A CS- the UTM. It performs this gateway function via a CS-RID SDSP. A CS-
RID Finder must implement, integrate, or accept outputs from, a RID Finder must implement, integrate, or accept outputs from, a
Broadcast RID receiver. It MUST NOT interface directly with a GCS, Broadcast RID receiver. It MUST NOT interface directly with a GCS,
Net-RID SP, Net- RID DP or Network RID client. It MUST present a TBD Net-RID SP, Net-RID DP or Network RID client. It MUST present a TBD
interface to a CS-RID SDSP; this interface SHOULD be based upon but interface to a CS-RID SDSP; this interface SHOULD be based upon but
readily distinguishable from that between a GCS and a Net-RID SP. readily distinguishable from that between a GCS and a Net-RID SP.
6.2. The CS-RID SDSP 6.2. The CS-RID SDSP
A CS-RID SDSP MUST appear (i.e. present the same interface) to a Net- A CS-RID SDSP MUST appear (i.e. present the same interface) to a Net-
RID SP as a Net-RID DP. A CS-RID SDSP MUST appear to a Net-RID DP as RID SP as a Net-RID DP. A CS-RID SDSP MUST appear to a Net-RID DP as
a Net-RID SP. A CS-RID SDSP MUST NOT present a standard GCS-facing a Net-RID SP. A CS-RID SDSP MUST NOT present a standard GCS-facing
interface as if it were a Net-RID SP. A CS-RID SDSP MUST NOT present interface as if it were a Net-RID SP. A CS-RID SDSP MUST NOT present
a standard client-facing interface as if it were a Net-RID DP. A CS- a standard client-facing interface as if it were a Net-RID DP. A CS-
skipping to change at page 17, line 39 skipping to change at page 17, line 18
* Observers without Internet connectivity MAY use Cra to identify * Observers without Internet connectivity MAY use Cra to identify
the trust class of the UAS based on known registry vetting. the trust class of the UAS based on known registry vetting.
* Observers with Internet connectivity MAY use HHITa to perform * Observers with Internet connectivity MAY use HHITa to perform
lookups in the Public Information Registry and MAY then query the lookups in the Public Information Registry and MAY then query the
Private Information Registry which MUST enforce AAA policy on Private Information Registry which MUST enforce AAA policy on
Operator PII and other sensitive information Operator PII and other sensitive information
8. Privacy for Broadcast PII 8. Privacy for Broadcast PII
Broadcast RID messages may contain PII. This may be information Broadcast RID messages may contain PII. A viable architecture for
about the UA such as its destination or Operator information such as PII protection would be symmetric encryption of the PII using a key
GCS location. There is no absolute "right" in hiding PII, as there known to the UAS and its USS. An authorized Observer may send the
will be times (e.g., disasters) and places (buffer zones around encrypted PII along with the Remote ID (to their UTM Service
airports and sensitive facilities) where policy may mandate all Provider) to get the plaintext. Alternatively, the authorized
information be sent as cleartext. Otherwise, the modern general Observer may receive the key to directly decrypt all future PII
position (consistent with, e.g., the EU General Data Protection content from the UA.
Regulation) is to hide PII unless otherwise instructed. While some
have argued that a system like that of automobile registration plates
should suffice for UAS, others have argued persuasively that each
generation of new identifiers should take advantage of advancing
technology to protect privacy, to the extent compatible with the
transparency needed to protect safety.
A viable architecture for PII protection would be symmetric
encryption of the PII using a key known to the UAS and its USS. An
authorized Observer may send the encrypted PII along with the Remote
ID (to their UTM Service Provider) to get the plaintext.
Alternatively, the authorized Observer may receive the key to
directly decrypt all future PII content from the UA.
PII SHOULD protected unless the UAS is informed otherwise. This may PII SHOULD protected unless the UAS is informed otherwise. This may
come from operational instructions to even permit flying in a space/ come from operational instructions to even permit flying in a space/
time. It may be special instructions at the start or during an time. It may be special instructions at the start or during an
operation. PII protection should not be used if the UAS loses operation. PII protection should not be used if the UAS loses
connectivity to the USS. The UAS always has the option to abort the connectivity to the USS. The UAS always has the option to abort the
operation if PII protection is disallowed. operation if PII protection is disallowed.
An authorized observer may instruct a UAS via the USS that conditions An authorized observer may instruct a UAS via the USS that conditions
have changed mandating no PII protection or land the UA (abort the have changed mandating no PII protection or land the UA (abort the
skipping to change at page 19, line 43 skipping to change at page 19, line 8
Commission Delegated Regulation 2019/945 of 12 March 2019 Commission Delegated Regulation 2019/945 of 12 March 2019
on unmanned aircraft systems and on third-country on unmanned aircraft systems and on third-country
operators of unmanned aircraft systems", 2019. operators of unmanned aircraft systems", 2019.
[F3411-19] ASTM, "Standard Specification for Remote ID and Tracking", [F3411-19] ASTM, "Standard Specification for Remote ID and Tracking",
2019. 2019.
[I-D.ietf-drip-rid] [I-D.ietf-drip-rid]
Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov, Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov,
"UAS Remote ID", Work in Progress, Internet-Draft, draft- "UAS Remote ID", Work in Progress, Internet-Draft, draft-
ietf-drip-rid-05, 22 December 2020, <http://www.ietf.org/ ietf-drip-rid-06, 31 December 2020, <http://www.ietf.org/
internet-drafts/draft-ietf-drip-rid-05.txt>. internet-drafts/draft-ietf-drip-rid-06.txt>.
[Implementing] [Implementing]
European Union Aviation Safety Agency (EASA), "EU European Union Aviation Safety Agency (EASA), "EU
Commission Implementing Regulation 2019/947 of 24 May 2019 Commission Implementing Regulation 2019/947 of 24 May 2019
on the rules and procedures for the operation of unmanned on the rules and procedures for the operation of unmanned
aircraft", 2019. aircraft", 2019.
[LAANC] United States Federal Aviation Administration (FAA), "Low [LAANC] United States Federal Aviation Administration (FAA), "Low
Altitude Authorization and Notification Capability", n.d., Altitude Authorization and Notification Capability", n.d.,
<https://www.faa.gov/uas/programs_partnerships/ <https://www.faa.gov/uas/programs_partnerships/
 End of changes. 26 change blocks. 
122 lines changed or deleted 105 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/