draft-ietf-drip-arch-05.txt   draft-ietf-drip-arch-06.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: 6 May 2021 R. Moskowitz Expires: 17 June 2021 R. Moskowitz
HTT Consulting HTT Consulting
S. Zhao (Editor) S. Zhao (Editor)
Tencent Tencent
A. Gurtov A. Gurtov
Linköping University Linkoeping University
2 November 2020 14 December 2020
Drone Remote Identification Protocol (DRIP) Architecture Drone Remote Identification Protocol (DRIP) Architecture
draft-ietf-drip-arch-05 draft-ietf-drip-arch-06
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 6 May 2021. This Internet-Draft will expire on 17 June 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 22 skipping to change at page 2, line 22
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. Network RID . . . . . . . . . . . . . . . . . . . . . 4
1.2.2. Broadcast RID . . . . . . . . . . . . . . . . . . . . 5 1.2.2. Broadcast RID . . . . . . . . . . . . . . . . . . . . 5
1.3. Overview of USS Interoperability . . . . . . . . . . . . 5 1.3. Overview of USS Interoperability . . . . . . . . . . . . 5
1.4. Overview of DRIP Archicture . . . . . . . . . . . . . . . 6 1.4. Overview of DRIP Archicture . . . . . . . . . . . . . . . 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
4. HHIT for UAS RID . . . . . . . . . . . . . . . . . . . . . . 9 4. HHIT for UAS Remote ID . . . . . . . . . . . . . . . . . . . 9
5. DRIP RID Entities (WAS Entities and their interfaces) . . . . 10 4.1. HIT as a Trustworthy Remote ID . . . . . . . . . . . . . 9
5.1. Private Information Registry . . . . . . . . . . . . . . 10 4.2. HHIT for Remote ID Registration and Lookup . . . . . . . 10
5.1.1. Background . . . . . . . . . . . . . . . . . . . . . 10 4.3. HHIT for Remote ID Encryption . . . . . . . . . . . . . . 10
5. DRIP RID Entities (WAS Entities and their interfaces) . . . . 11
5.1. Private Information Registry . . . . . . . . . . . . . . 11
5.1.1. Background . . . . . . . . . . . . . . . . . . . . . 11
5.1.2. Proposed Approach . . . . . . . . . . . . . . . . . . 11 5.1.2. Proposed Approach . . . . . . . . . . . . . . . . . . 11
5.2. Public Information Registry . . . . . . . . . . . . . . . 11 5.2. Public Information Registry . . . . . . . . . . . . . . . 12
5.2.1. Background . . . . . . . . . . . . . . . . . . . . . 11 5.2.1. Background . . . . . . . . . . . . . . . . . . . . . 12
5.2.2. Proposed Approach . . . . . . . . . . . . . . . . . . 11 5.2.2. Proposed Approach . . . . . . . . . . . . . . . . . . 12
5.3. CS-RID concept . . . . . . . . . . . . . . . . . . . . . 11 5.3. CS-RID concept . . . . . . . . . . . . . . . . . . . . . 12
5.3.1. Proposed optional CS-RID SDSP . . . . . . . . . . . . 12 5.3.1. Proposed optional CS-RID SDSP . . . . . . . . . . . . 13
5.3.2. Proposed optional CS-RID Finder . . . . . . . . . . . 12 5.3.2. Proposed optional CS-RID Finder . . . . . . . . . . . 13
6. UAS Remote Identifiers . . . . . . . . . . . . . . . . . . . 13 6. UAS Remote Identifiers . . . . . . . . . . . . . . . . . . . 13
6.1. Background . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Background . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Proposed Approach . . . . . . . . . . . . . . . . . . . . 13 6.2. Proposed Approach . . . . . . . . . . . . . . . . . . . . 14
7. DRIP Transactions enabling Trustworthy . . . . . . . . . . . 14 7. DRIP Transactions enabling Trustworthy . . . . . . . . . . . 15
8. Privacy for Broadcast PII . . . . . . . . . . . . . . . . . . 15 8. Privacy for Broadcast PII . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . 16 12.1. Normative References . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . 17 12.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Overview of Unmanned Aircraft Systems (UAS) Appendix A. Overview of Unmanned Aircraft Systems (UAS)
Traffic . . . . . . . . . . . . . . . . . . . . . . . . . 20 Traffic . . . . . . . . . . . . . . . . . . . . . . . . . 19
A.1. Operation Concept . . . . . . . . . . . . . . . . . . . . 20 A.1. Operation Concept . . . . . . . . . . . . . . . . . . . . 20
A.2. UAS Service Supplier (USS) . . . . . . . . . . . . . . . 21 A.2. UAS Service Supplier (USS) . . . . . . . . . . . . . . . 20
A.3. UTM Use Cases for UAS Operations . . . . . . . . . . . . 21 A.3. UTM Use Cases for UAS Operations . . . . . . . . . . . . 21
A.4. Automatic Dependent Surveillance Broadcast (ADS-B) . . . 22 A.4. Automatic Dependent Surveillance Broadcast (ADS-B) . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
This document describes a natural Internet and MAC-layer broadcast- This document describes a natural Internet and MAC-layer broadcast-
based architecture for Unmanned Aircraft System Remote Identification based architecture for Unmanned Aircraft System Remote Identification
and tracking (UAS RID), conforming to proposed regulations and and tracking (UAS RID), conforming to proposed regulations and
external technical standards, satisfying the requirements listed in external technical standards, satisfying the requirements listed in
the companion requirements document [I-D.ietf-drip-reqs]. 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
skipping to change at page 3, line 41 skipping to change at page 3, line 43
ASTM ASTM
ASTM International, Technical Committee F38 (UAS), Subcommittee ASTM International, Technical Committee F38 (UAS), Subcommittee
F38.02 (Aircraft Operations), Work Item WK65041, developed the new F38.02 (Aircraft Operations), Work Item WK65041, developed the new
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 sighted 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
3GPP provides UA service in the LTE network since release 15 in With release 16, 3GPP completed the UAS RID requirement study
published technical specification [TS-36.777]. Start from its
release 16, it completed the UAS RID requirement study in
[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 and ongoing release 17 services that can be offered based on RID. Release 17
specification works on enhanced UAS service requirement 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. ATIS's recent report is applicable for both 4G and 5G network.
[ATIS-I-0000074] proposes architecture approaches for the 3GPP
network to support UAS and one of which is put RID in higher 3GPP
protocol stack such as using ASTM remote ID [F3411-19].
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. Network RID
Network RID defines a RID data dictionary and data flow: from a UAS A RID data dictionary and data flow for Network RID are defined in
via unspecified means to a Network Remote ID Service Provider (Net- [F3411-19]. This flow is from a UAS via unspecified means (but at
RID SP); from the Net-RID SP to an integrated, or over the Internet least in part over the Internet) to a Network Remote ID Service
to a separate, Network Remote ID Display Provider (Net- RID DP); from Provider (Net-RID SP). These Net-RID SPs provide this information to
the Net-RID DP via the Internet to Network Remote ID clients in Network Remote ID Display Providers (Net-RID DP). It is the Net-RID
response to their queries (expected typically, but not specified DP that respond to queries from Network Remote ID clients (expected
exclusively, to be web based) specifying airspace volumes of typically, but not specified exclusively, to be web based) specifying
interest. Network RID depends upon connectivity, in several airspace volumes of interest. Network RID depends upon connectivity,
segments, via the Internet, from the UAS to the Observer. 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 1 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 1
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 from the GCS to the UA; for all but Command and Control (C2) flows between the GCS to the UA such that
the simplest hobby aircraft, position and status flow from the UA to either can communicate with the Net-RID SP. For all but the simplest
the GCS. Via the Internet, through three distinct segments, Network hobby aircraft, position and status flow from the UA to the GCS and
RID information flows from the UAS (comprising the UA and its GCS) to on to the Net-RID SP. Thus via the Internet, through three distinct
the Observer. segments, Network RID information flows from the UAS to the Observer.
1.2.2. Broadcast RID 1.2.2. Broadcast RID
Broadcast RID defines a set of RID messages and how the UA transmits A set of RID messages are defined for direct, one-way, broadcast
them locally directly one-way, over Bluetooth or Wi-Fi. Broadcast transmissions from the UA over Bluetooth or Wi-Fi. These are
RID should need Internet (or other Wide Area Network) connectivity currently defined as MAC-Layer messages. Internet (or other Wide
only for UAS registry information lookup using the locally directly Area Network) connectivity is only needed for UAS registry
received UAS ID as a key. Broadcast RID should be functionally information lookup by Observers using the locally directly received
usable in situations with no Internet connectivity. 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. The Broadcast RID is illustrated in Figure 2 below.
Editor's note: Is there a need to add interconnections between
B-RID and N-RID in the drawing
x x UA x x UA
xxxxx xxxxx
| |
| |
| app messages directly over | app messages directly over
| one-way RF data link (no IP) | one-way RF data link (no IP)
| |
| |
+ +
x x
xxxxx xxxxx
x x
x x
x x Observer's device (e.g. smartphone) x x Observer's device (e.g. smartphone)
x x x x
Figure 2 Figure 2
Editor's note: the following may more clarification: With Broadcast RID, an Observer is limited to their radio "visible"
airspace for UAS awareness and information. With Internet queries
* what Broadcast RID can do w/ & w/o Observer Internet connectivity using harvested RID, the Observer may gain more information about
those visible UAS.
* How Broadcast RID transmits public info (obviating some registry
lookups)
* how Network RID is "less constrained" than Broadcast RID
1.3. Overview of USS Interoperability 1.3. Overview of USS Interoperability
Editor's Note: Show how DRIP RID is an enabler of USS Each UAS is registered to at least one USS. With Net-RID, there is
Interoperability Figure 3 direct communication between the UAS and its USS. With Broadcast-
+-------+ RID, the UAS Operator has either pre-filed a 4D space volume for USS
| DSS | operational knowledge and/or Observers can be providing information
+-------+ about observed UA to a USS. USS exchange information via a Discovery
/ \ and Synchronization Service (DSS) so all USS have knowledge about all
/ \ activities in a 4D airspace. The interactions among observer, UA and
/ \ USS is shown in Figure 3.
+-------+ +-------+
| USS-1 | <----------> | USS-2 | +----------+
+-------+ +-------+ | Observer |
+----------+
/ \
/ \
+-----+ +-----+
| UA1 | | UA2 |
+-----+ +-----+
\ /
\ /
+----------+
| Internet |
+----------+
/ \
/ \
+-------+ +-------+
| USS-1 | <-------> | USS-2 |
+-------+ +-------+
\ /
\ /
+------+
| DSS |
+------+
Figure 3 Figure 3
1.4. Overview of DRIP Archicture 1.4. Overview of DRIP Archicture
The requirements document also provides an extended introduction to The requirements document also provides an extended introduction to
the problem space, use cases, etc. Only a brief summary of that the problem space, use cases, etc. Only a brief summary of that
introduction will be restated here as context, with reference to the introduction will be restated here as context, with reference to the
general architecture shown in Figure 4 below. general architecture shown in Figure 4 below.
General x x Public General x x Public
Public xxxxx xxxxx Safety Public xxxxx xxxxx Safety
Observer x x Observer Observer x x Observer
x x x x
x x ---------+ +---------- x x x x ---------+ +---------- x x
x x | | x x x x | | x x
| | | |
+ + UA1 x x | | +------------ x x UA2
xxxxxxxxxx xxxxx | | | xxxxx
x x | + + + |
+----------+x Internet x+------------+ | xxxxxxxxxx |
| x x | | x x |
UA1 x | xxxxxxxxxx | x UA2 +----------+x Internet x+------------+
Pilot xxxxx + + + xxxxx Pilot UA1 | x x | UA1
Operator x | | | x Operator Pilot x | xxxxxxxxxx | x Pilot
Operator xxxxx + + + xxxxx Operator
GCS1 x | | | x GCS2
x | | | x x | | | x
x x | | | x x x x | | | x x
x x | | | x x x x | | | x x
| | | | | |
+----------+ | | | +----------+ +----------+ | | | +----------+
| |------+ | +-------| | | |------+ | +-------| |
| Public | | | Private | | Public | | | Private |
| Registry | +-----+ | Registry | | Registry | +-----+ | Registry |
| | | DNS | | | | | | DNS | | |
+----------+ +-----+ +----------+ +----------+ +-----+ +----------+
Figure 4 Figure 4
Editor's note: the archteture may need more clarification, and Editor's note: the archteture may need more clarification, and
address the following: address the following:
* add network RID and broadcast RID in the picture (since those are * connectivity requirements among UA, GCS, SP, DP (if necessary)
the focus points)
* connectivity requirements among UA, GCS, SP, DP (if necessary) ...
DRIP will enable leveraging existing Internet resources (standard DRIP will enable leveraging existing Internet resources (standard
protocols, services, infrastructure and business models) to meet UAS protocols, services, infrastructure and business models) to meet UAS
RID and closely related needs. DRIP will specify how to apply IETF RID and closely related needs. DRIP will specify how to apply IETF
standards, complementing [F3411-19] and other external standards, to standards, complementing [F3411-19] and other external standards, to
satisfy UAS RID requirements. DRIP will update existing and develop satisfy UAS RID requirements. DRIP will update existing and develop
new protocol standards as needed to accomplish the foregoing. new protocol standards as needed to accomplish the foregoing.
This document will outline the UAS RID architecture into which DRIP This document will outline the UAS RID architecture into which DRIP
must fit, and an architecture for DRIP itself. This includes must fit, and an architecture for DRIP itself. This includes
skipping to change at page 8, line 21 skipping to change at page 8, line 42
capitals, as shown above. capitals, as shown above.
3. Definitions and Abbreviations 3. Definitions and Abbreviations
3.1. Additional Definitions 3.1. Additional Definitions
Editor's Note: to be updated. Editor's Note: to be updated.
This document uses terms defined in [I-D.ietf-drip-reqs]. This document uses terms defined in [I-D.ietf-drip-reqs].
Editor's note: in order to make it self-contain, listing terms
used in this draft should be okie, comments?
3.2. Abbreviations 3.2. Abbreviations
Editor's Note: to be updated. Editor's Note: to be updated.
ADS-B: Automatic Dependent Surveillance Broadcast ADS-B: Automatic Dependent Surveillance Broadcast
DSS: Discovery & Synchronization Service DSS: Discovery & Synchronization Service
EdDSA: Edwards-Curve Digital Signature Algorithm EdDSA: Edwards-Curve Digital Signature Algorithm
skipping to change at page 9, line 4 skipping to change at page 9, line 21
Net-RID SP: Network RID Service Provider Net-RID SP: Network RID Service Provider
Net-RID DP: Network RID Display Provider. Net-RID DP: Network RID Display Provider.
PII: Personally Identifiable Information PII: Personally Identifiable Information
RF: Radio Frequency RF: Radio Frequency
SDSP: Supplemental Data Service Provider SDSP: Supplemental Data Service Provider
UA: Unmanned Aircraft UA: Unmanned Aircraft
UAS: Unmanned Aircraft System UAS: Unmanned Aircraft System
USS: UAS Service Supplier USS: UAS Service Supplier
UTM: UAS Traffic Management UTM: UAS Traffic Management
4. HHIT for UAS RID 4. HHIT for UAS Remote ID
Editor's note: I think we should explain HHIT designs for UAS RID
first and give readers a direct imporession what this draft is
offering. This is one of Daniel's comment, we shall focus on
solutions, without repeating too much of details from a sepecifc
draft.
This document describes the use of Hierarchical Host Identity Tags This section describes the use of Hierarchical Host Identity Tags
(HHITs) as self-asserting IPv6 addresses and thereby a trustable (HHITs) as self-asserting IPv6 addresses and thereby a trustable
Identifier for use as the UAS Remote ID. HHITs self-attest to the Identifier for use as the UAS Remote ID. HHITs self-attest to the
included explicit hierarchy that provides Registrar discovery for included explicit hierarchy that provides Registrar discovery for
3rd-party ID attestation. 3rd-party ID attestation.
4.1. HIT as a Trustworthy Remote ID
For a Remote ID to be trustworthy in the Broadcast mode, there MUST
be an asymmetric keypair for proof of ID ownership. The common
method of using a key signing operation to assert ownership of an ID,
does not guarantee name uniqueness. Any entity can sign an ID,
claiming ownership. To mitigate spoofing risks, the ID needs to be
cryptographically generated from the public key, in such a manner
that it is statistically hard for an entity to create a public key
that would generate (spoof) the ID. Thus the signing of such an ID
becomes an attestation (compared to claim) of ownership.
HITs are statistically unique through the cryptographic hash feature HITs are statistically unique through the cryptographic hash feature
of second-preimage resistance. The cryptographically-bound addition of second-preimage resistance. The cryptographically-bound addition
of the Hierarchy and a HHIT registration process (TBD; 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.
other pointers: (mostly list how HHIT satisfy the reqs-) 4.2. HHIT for Remote ID Registration and Lookup
* Why DRIP RID should/MUST/May be a HHIT?
* HHIT RID format, metadate, and other useful info
* HHIT RID registar workflow
* HHIT Users (operator/USS/NETRID-SP?)
- expand on different uses of & relationship between optional Remote IDs need a deterministic lookup mechanism that rapidly
manufacturer-assigned HI & subsequent single-use HIs provides actionable information about the identified UA. The ID
itself needs to be the key into the lookup given the constraints
imposed by some of the broadcast media. This can best be achieved by
an ID registration hierarchy cryptographically embedded within the
ID.
* how security is guaranteed 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.
- call X.509 PKI not "standard" but "classical", describe it to The HHIT needs to consist of a registration hierarchy, the hashing
justify why it won't work here crypto suite information, and the hash of these items along with the
underlying public key. Additional information, e.g. an IPv6 prefix,
may enhance the HHITs use beyond the basic Remote ID function (e.g.
use in HIP, [RFC7401]).
- explain continuing role of some kind of CA even w/o X.509 PKI 4.3. HHIT for Remote ID Encryption
Editors' note: this is also one of the Michael's comment, we
can address it here
* how DNS lookup may happen (Reverse DNS?) The only (at time of Trustworthy Remote ID design) extant fixed
length ID cryptographically derived from a public key are the Host
Identity Tag [RFC7401], HITs, and Cryptographically Generated
Addresses [RFC3972], CGAs. Both lack a registration/retrieval
capability and CGAs have only a limited crypto agility [RFC4982].
Distributed Hash Tables have been tried for HITs [RFC6537]; this is
really not workable for a globally deployed UAS Remote ID scheme.
* .... The security of HHITs is achieved first through the cryptographic
hashing function of the above information, along with a registration
process to mitigate the probability of a hash collision (first
registered, first allowed).
5. DRIP RID Entities (WAS Entities and their interfaces) 5. DRIP RID Entities (WAS Entities and their interfaces)
Editor: This section descrips the DRIP RID ecosystem such as RID Editor: This section descrips the DRIP RID ecosystem such as RID
design philosophy, PII registration, Still not sure this is a good design philosophy, PII registration, Still not sure this is a good
title since here mainly talks about regiter, maybe use this seciton title since here mainly talks about regiter, maybe use this seciton
focus on HHIT RID registration?? I also have suggestion to move the focus on HHIT RID registration?? I also have suggestion to move the
CS-RID to a seperated section CS-RID to a seperated section
Any DRIP solutions for UAS RID must fit into the UTM (or U-space) Any DRIP solutions for UAS RID must fit into the UTM (or U-space)
skipping to change at page 13, line 31 skipping to change at page 14, line 20
* The ASTM Basic RID message (the message containing the RID) is 25 * The ASTM Basic RID message (the message containing the RID) is 25
characters; only 3 characters are currently unused characters; only 3 characters are currently unused
* The ASTM Authentication message, with some changes from [F3411-19] * The ASTM Authentication message, with some changes from [F3411-19]
can carry 224 bytes of payload. 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 algorithm. An example of a constraints, even using the new EdDSA algorithm. An example of a
technology that will fit within these limitations is an enhancement technology that will fit within these limitations is an enhancement
of the Host Identity Tag (HIT) of HIPv2 [RFC7401] introducing of the Host Identity Tag (HIT) of HIPv2 [RFC7401] introducing
hierarchy as defined in HHIT [I-D.moskowitz-hip-hierarchical-hit]; hierarchy as defined in HHIT [I-D.ietf-drip-rid]; using Hierarchical
using Hierarchical HITs for UAS RID is outlined in HHIT based UAS RID HITs for UAS RID is outlined in HHIT based UAS 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
skipping to change at page 17, line 11 skipping to change at page 17, line 44
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12.2. Informative References 12.2. Informative References
[ATIS-I-0000074]
ATIS, "Report on UAS in 3GPP", n.d.,
<https://access.atis.org/apps/group_public/
download.php/48760/ATIS-I-0000074.pdf>.
[CTA2063A] ANSI, "Small Unmanned Aerial Systems Serial Numbers", [CTA2063A] ANSI, "Small Unmanned Aerial Systems Serial Numbers",
2019. 2019.
[Delegated] [Delegated]
European Union Aviation Safety Agency (EASA), "EU European Union Aviation Safety Agency (EASA), "EU
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-04, 1 November 2020, <http://www.ietf.org/ ietf-drip-rid-04, 1 November 2020, <http://www.ietf.org/
internet-drafts/draft-ietf-drip-rid-04.txt>. internet-drafts/draft-ietf-drip-rid-04.txt>.
[I-D.maeurer-raw-ldacs]
Maeurer, N., Graeupl, T., and C. Schmitt, "L-band Digital
Aeronautical Communications System (LDACS)", Work in
Progress, Internet-Draft, draft-maeurer-raw-ldacs-06, 2
October 2020, <http://www.ietf.org/internet-drafts/draft-
maeurer-raw-ldacs-06.txt>.
[I-D.moskowitz-drip-crowd-sourced-rid]
Moskowitz, R., Card, S., Wiethuechter, A., Zhao, S., and
H. Birkholz, "Crowd Sourced Remote ID", Work in Progress,
Internet-Draft, draft-moskowitz-drip-crowd-sourced-rid-04,
20 May 2020, <http://www.ietf.org/internet-drafts/draft-
moskowitz-drip-crowd-sourced-rid-04.txt>.
[I-D.moskowitz-drip-secure-nrid-c2]
Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov,
"Secure UAS Network RID and C2 Transport", Work in
Progress, Internet-Draft, draft-moskowitz-drip-secure-
nrid-c2-01, 27 September 2020, <http://www.ietf.org/
internet-drafts/draft-moskowitz-drip-secure-nrid-
c2-01.txt>.
[I-D.moskowitz-hip-hhit-registries]
Moskowitz, R., Card, S., and A. Wiethuechter,
"Hierarchical HIT Registries", Work in Progress, Internet-
Draft, draft-moskowitz-hip-hhit-registries-02, 9 March
2020, <http://www.ietf.org/internet-drafts/draft-
moskowitz-hip-hhit-registries-02.txt>.
[I-D.moskowitz-hip-hierarchical-hit]
Moskowitz, R., Card, S., and A. Wiethuechter,
"Hierarchical HITs for HIPv2", Work in Progress, Internet-
Draft, draft-moskowitz-hip-hierarchical-hit-05, 13 May
2020, <http://www.ietf.org/internet-drafts/draft-
moskowitz-hip-hierarchical-hit-05.txt>.
[I-D.moskowitz-hip-new-crypto]
Moskowitz, R., Card, S., and A. Wiethuechter, "New
Cryptographic Algorithms for HIP", Work in Progress,
Internet-Draft, draft-moskowitz-hip-new-crypto-05, 26 July
2020, <http://www.ietf.org/internet-drafts/draft-
moskowitz-hip-new-crypto-05.txt>.
[I-D.moskowitz-orchid-cshake]
Moskowitz, R., Card, S., and A. Wiethuechter, "Using
cSHAKE in ORCHIDs", Work in Progress, Internet-Draft,
draft-moskowitz-orchid-cshake-01, 21 May 2020,
<http://www.ietf.org/internet-drafts/draft-moskowitz-
orchid-cshake-01.txt>.
[I-D.wiethuechter-drip-auth]
Wiethuechter, A., Card, S., and R. Moskowitz, "DRIP
Authentication Formats", Work in Progress, Internet-Draft,
draft-wiethuechter-drip-auth-04, 21 September 2020,
<http://www.ietf.org/internet-drafts/draft-wiethuechter-
drip-auth-04.txt>.
[I-D.wiethuechter-drip-identity-claims]
Wiethuechter, A., Card, S., and R. Moskowitz, "DRIP
Identity Claims", Work in Progress, Internet-Draft, draft-
wiethuechter-drip-identity-claims-02, 26 October 2020,
<http://www.ietf.org/internet-drafts/draft-wiethuechter-
drip-identity-claims-02.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/
data_exchange/>. data_exchange/>.
[NPRM] United States Federal Aviation Administration (FAA), [NPRM] United States Federal Aviation Administration (FAA),
"Notice of Proposed Rule Making on Remote Identification "Notice of Proposed Rule Making on Remote Identification
of Unmanned Aircraft Systems", 2019. of Unmanned Aircraft Systems", 2019.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
Unique IDentifier (UUID) URN Namespace", RFC 4122, RFC 3972, DOI 10.17487/RFC3972, March 2005,
DOI 10.17487/RFC4122, July 2005, <https://www.rfc-editor.org/info/rfc3972>.
<https://www.rfc-editor.org/info/rfc4122>.
[RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash
Algorithms in Cryptographically Generated Addresses
(CGAs)", RFC 4982, DOI 10.17487/RFC4982, July 2007,
<https://www.rfc-editor.org/info/rfc4982>.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
<https://www.rfc-editor.org/info/rfc5730>. <https://www.rfc-editor.org/info/rfc5730>.
[RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Domain Name Mapping", STD 69, RFC 5731, Domain Name Mapping", STD 69, RFC 5731,
DOI 10.17487/RFC5731, August 2009, DOI 10.17487/RFC5731, August 2009,
<https://www.rfc-editor.org/info/rfc5731>. <https://www.rfc-editor.org/info/rfc5731>.
[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Tschofenig, H., and H. Schulzrinne, "An Architecture for Tschofenig, H., and H. Schulzrinne, "An Architecture for
Location and Location Privacy in Internet Applications", Location and Location Privacy in Internet Applications",
BCP 160, RFC 6280, DOI 10.17487/RFC6280, July 2011, BCP 160, RFC 6280, DOI 10.17487/RFC6280, July 2011,
<https://www.rfc-editor.org/info/rfc6280>. <https://www.rfc-editor.org/info/rfc6280>.
[RFC6537] Ahrenholz, J., "Host Identity Protocol Distributed Hash
Table Interface", RFC 6537, DOI 10.17487/RFC6537, February
2012, <https://www.rfc-editor.org/info/rfc6537>.
[RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr, [RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr,
"WebFinger", RFC 7033, DOI 10.17487/RFC7033, September "WebFinger", RFC 7033, DOI 10.17487/RFC7033, September
2013, <https://www.rfc-editor.org/info/rfc7033>. 2013, <https://www.rfc-editor.org/info/rfc7033>.
[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>.
[RFC7484] Blanchet, M., "Finding the Authoritative Registration Data [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data
skipping to change at page 20, line 31 skipping to change at page 19, line 41
[RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name
System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005,
October 2016, <https://www.rfc-editor.org/info/rfc8005>. October 2016, <https://www.rfc-editor.org/info/rfc8005>.
[TS-22.825] [TS-22.825]
3GPP, "UAS RID requirement study", n.d., 3GPP, "UAS RID requirement study", n.d.,
<https://portal.3gpp.org/desktopmodules/Specifications/ <https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3527>. SpecificationDetails.aspx?specificationId=3527>.
[TS-36.777]
3GPP, "UAV service in the LTE network", n.d.,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3231>.
[U-Space] European Organization for the Safety of Air Navigation [U-Space] European Organization for the Safety of Air Navigation
(EUROCONTROL), "U-space Concept of Operations", 2019, (EUROCONTROL), "U-space Concept of Operations", 2019,
<https://www.sesarju.eu/sites/default/files/documents/u- <https://www.sesarju.eu/sites/default/files/documents/u-
space/CORUS%20ConOps%20vol2.pdf>. space/CORUS%20ConOps%20vol2.pdf>.
Appendix A. Overview of Unmanned Aircraft Systems (UAS) Traffic Appendix A. Overview of Unmanned Aircraft Systems (UAS) Traffic
A.1. Operation Concept A.1. Operation Concept
The National Aeronautics and Space Administration (NASA) and FAAs' The National Aeronautics and Space Administration (NASA) and FAAs'
effort of integrating UAS's operation into the national airspace effort of integrating UAS's operation into the national airspace
system (NAS) leads to the development of the concept of UTM and the system (NAS) leads to the development of the concept of UTM and the
ecosystem around it. The UTM concept was initially presented in ecosystem around it. The UTM concept was initially presented in
2013. The eventual development and implementation are conducted by 2013. The eventual development and implementation are conducted by
the UTM research transition team which is the joint workforce by FAA the UTM research transition team which is the joint workforce by FAA
and NASA. World efforts took place afterward. The Single European and NASA. World efforts took place afterward. The Single European
Sky ATM Research (SESAR) started the CORUS project to research its Sky ATM Research (SESAR) started the CORUS project to research its
skipping to change at page 23, line 14 skipping to change at page 22, line 22
Adam Wiethuechter Adam Wiethuechter
AX Enterprize AX Enterprize
4947 Commercial Drive 4947 Commercial Drive
Yorkville, NY, 13495 Yorkville, NY, 13495
United States of America United States of America
Email: adam.wiethuechter@axenterprize.com Email: adam.wiethuechter@axenterprize.com
Robert Moskowitz Robert Moskowitz
HTT Consulting HTT Consulting
na
Oak Park, MI, 48237 Oak Park, MI, 48237
United States of America United States of America
Email: rgm@labs.htt-consult.com Email: rgm@labs.htt-consult.com
Shuai Zhao Shuai Zhao
Tencent Tencent
2747 Park Blvd 2747 Park Blvd
Palo Alto, 94588 Palo Alto, 94588
United States of America United States of America
Email: shuai.zhao@ieee.org Email: shuai.zhao@ieee.org
Andrei Gurtov Andrei Gurtov
Linköping University Linkoeping University
IDA IDA
SE-58183 Linköping Linköping SE-58183 Linkoeping Linkoeping
Sweden Sweden
Email: gurtov@acm.org Email: gurtov@acm.org
 End of changes. 50 change blocks. 
217 lines changed or deleted 175 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/