< draft-ietf-drip-arch-21.txt   draft-ietf-drip-arch-22.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: 8 September 2022 R. Moskowitz Expires: 22 September 2022 R. Moskowitz
HTT Consulting HTT Consulting
S. Zhao (Editor) S. Zhao (Editor)
Tencent Tencent
A. Gurtov A. Gurtov
Linköping University Linköping University
7 March 2022 21 March 2022
Drone Remote Identification Protocol (DRIP) Architecture Drone Remote Identification Protocol (DRIP) Architecture
draft-ietf-drip-arch-21 draft-ietf-drip-arch-22
Abstract Abstract
This document describes an architecture for protocols and services to This document describes an architecture for protocols and services to
support Unmanned Aircraft System (UAS) Remote Identification (RID) support Unmanned Aircraft System (UAS) Remote Identification (RID)
and tracking, plus UAS RID-related communications. This architecture and tracking, plus UAS RID-related communications. This architecture
adheres to the requirements listed in the DRIP Requirements document adheres to the requirements listed in the DRIP Requirements document
(RFC9153). (RFC9153).
Status of This Memo Status of This Memo
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 September 2022. This Internet-Draft will expire on 22 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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.
skipping to change at page 2, line 50 skipping to change at page 2, line 50
6.1. The CS-RID Finder . . . . . . . . . . . . . . . . . . . . 18 6.1. The CS-RID Finder . . . . . . . . . . . . . . . . . . . . 18
6.2. The CS-RID SDSP . . . . . . . . . . . . . . . . . . . . . 18 6.2. The CS-RID SDSP . . . . . . . . . . . . . . . . . . . . . 18
7. DRIP Contact . . . . . . . . . . . . . . . . . . . . . . . . 18 7. DRIP Contact . . . . . . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. Privacy & Transparency Considerations . . . . . . . . . . . . 20 10. Privacy & Transparency Considerations . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. Overview of Unmanned Aircraft Systems (UAS) Traffic Appendix A. Overview of Unmanned Aircraft Systems (UAS) Traffic
Management (UTM) . . . . . . . . . . . . . . . . . . . . 23 Management (UTM) . . . . . . . . . . . . . . . . . . . . 24
A.1. Operation Concept . . . . . . . . . . . . . . . . . . . . 24 A.1. Operation Concept . . . . . . . . . . . . . . . . . . . . 24
A.2. UAS Service Supplier (USS) . . . . . . . . . . . . . . . 24 A.2. UAS Service Supplier (USS) . . . . . . . . . . . . . . . 24
A.3. UTM Use Cases for UAS Operations . . . . . . . . . . . . 25 A.3. UTM Use Cases for UAS Operations . . . . . . . . . . . . 25
Appendix B. Automatic Dependent Surveillance Broadcast Appendix B. Automatic Dependent Surveillance Broadcast
(ADS-B) . . . . . . . . . . . . . . . . . . . . . . . . . 25 (ADS-B) . . . . . . . . . . . . . . . . . . . . . . . . . 25
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 26 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
skipping to change at page 17, line 26 skipping to change at page 17, line 26
ASTM anticipated that regulators would require both Broadcast RID and ASTM anticipated that regulators would require both Broadcast RID and
Network RID for large UAS, but allow UAS RID requirements for small Network RID for large UAS, but allow UAS RID requirements for small
UAS to be satisfied with the operator's choice of either Broadcast UAS to be satisfied with the operator's choice of either Broadcast
RID or Network RID. The EASA initially specified Broadcast RID for RID or Network RID. The EASA initially specified Broadcast RID for
essentially all UAS, and is now also considering Network RID. The essentially all UAS, and is now also considering Network RID. The
FAA UAS RID Final Rules [FAA_RID] permit only Broadcast RID for rule FAA UAS RID Final Rules [FAA_RID] permit only Broadcast RID for rule
compliance, but still encourage Network RID for complementary compliance, but still encourage Network RID for complementary
functionality, especially in support of UTM. functionality, especially in support of UTM.
One obvious opportunity is to enhance the architecture with gateways One opportunity is to enhance the architecture with gateways from
from Broadcast RID to Network RID. This provides the best of both Broadcast RID to Network RID. This provides the best of both and
and gives regulators and operators flexibility. It offers advantages gives regulators and operators flexibility. It offers advantages
over either form of UAS RID alone: greater fidelity than Network RID over either form of UAS RID alone: greater fidelity than Network RID
reporting of planned area operations; surveillance of areas too large reporting of planned area operations; surveillance of areas too large
for local direct visual observation and direct RF-LOS link based for local direct visual observation and direct RF-LOS link based
Broadcast RID (e.g., a city or a national forest). Broadcast RID (e.g., a city or a national forest).
These gateways could be pre-positioned (e.g., around airports, public These gateways could be pre-positioned (e.g., around airports, public
gatherings, and other sensitive areas) and/or crowd-sourced (as gatherings, and other sensitive areas) and/or crowd-sourced (as
nothing more than a smartphone with a suitable app is needed). As nothing more than a smartphone with a suitable app is needed). As
Broadcast RID media have limited range, gateways receiving messages Broadcast RID media have limited range, gateways receiving messages
claiming locations far from the gateway can alert authorities or a claiming locations far from the gateway can alert authorities or a
skipping to change at page 18, line 8 skipping to change at page 18, line 8
misconfiguration or intentional deception. misconfiguration or intentional deception.
Multilateration technologies use physical layer information, such as Multilateration technologies use physical layer information, such as
precise Time Of Arrival (TOA) of transmissions from mobile precise Time Of Arrival (TOA) of transmissions from mobile
transmitters at receivers with a priori precisely known locations, to transmitters at receivers with a priori precisely known locations, to
estimate the locations of the mobile transmitters. estimate the locations of the mobile transmitters.
Further, gateways with additional sensors (e.g., smartphones with Further, gateways with additional sensors (e.g., smartphones with
cameras) can provide independent information on the UA type and size, cameras) can provide independent information on the UA type and size,
confirming or refuting those claims made in the UAS RID messages. confirming or refuting those claims made in the UAS RID messages.
This Crowd Sourced Remote ID (CS-RID) would be a significant
enhancement, beyond baseline DRIP functionality; if implemented, it Section 6.1 and Section 6.2 define two additional entities that are
adds two more entity types. required to provide this Crowd Sourced Remote ID (CS-RID).
This approach satisfies the following DRIP requirements defined in This approach satisfies the following DRIP requirements defined in
[RFC9153]: GEN-5, GEN-11, and REG-1. [RFC9153]: GEN-5, GEN-11, and REG-1.
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
UTM. It performs this gateway function via a CS-RID SDSP. A CS-RID UTM. It performs this gateway function via a CS-RID SDSP. A CS-RID
Finder could implement, integrate, or accept outputs from a Broadcast Finder could implement, integrate, or accept outputs from a Broadcast
RID receiver. However, it should not depend upon a direct interface RID receiver. However, it should not depend upon a direct interface
with a GCS, Net-RID SP, Net-RID DP or Network RID client. It would with a GCS, Net-RID SP, Net-RID DP or Network RID client. It would
present a TBD interface to a CS-RID SDSP, similar to but readily present a new interface to a CS-RID SDSP, similar to but readily
distinguishable from that between a GCS and a Net-RID SP. 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 aggregates and processes (e.g., estimates UA location A CS-RID SDSP aggregates and processes (e.g., estimates UA location
using multilateration when possible) information collected by CS-RID using multilateration when possible) information collected by CS-RID
Finders. A CS-RID SDSP should appear (i.e., present the same Finders. A CS-RID SDSP should appear (i.e., present the same
interface) to a Net-RID SP as a Net-RID DP. interface) to a Net-RID SP as a Net-RID DP.
7. DRIP Contact 7. DRIP Contact
skipping to change at page 19, line 37 skipping to change at page 19, line 37
satisfaction of requirements [RFC9153] GEN-8, GEN-9, PRIV-2, PRIV-5 satisfaction of requirements [RFC9153] GEN-8, GEN-9, PRIV-2, PRIV-5
and REG-3, and is compatible with all other DRIP requirements. and REG-3, and is compatible with all other DRIP requirements.
8. IANA Considerations 8. IANA Considerations
This document does not make any IANA request. This document does not make any IANA request.
9. Security Considerations 9. Security Considerations
The security provided by asymmetric cryptographic techniques depends The security provided by asymmetric cryptographic techniques depends
upon protection of the private keys. A manufacturer that embeds a upon protection of the private keys. It may be necessary for the GCS
private key in an UA may have retained a copy. A manufacturer whose to have the key pair to register the HHIT to the USS. Thus it may be
UA are configured by a closed source application on the GCS that the GCS that generates the key pair and delivers it to the UA, making
communicates over the Internet with the factory may be sending a copy the GCS a part of the key security boundary. Leakage of the private
of a UA or GCS self-generated key back to the factory. Keys may be key either from the UA or GCS to the component manufacturer is a
extracted from a GCS or UA. The UAS RID sender of a small harmless valid concern and steps need to be in place to ensure safe keeping of
UA (or the entire UA) could be carried by a larger dangerous UA as a the private key.
"false flag." Compromise of a registry private key could do
widespread harm. Key revocation procedures are as yet to be The size of the public key hash in the HHIT is also of concern. It
determined. These risks are in addition to those involving Operator is well within current server array technology to compute another key
key management practices. pair that hashes to the same HHIT. Thus an adversary could
impersonate a validly registered UA. This attack would only be
exposed when the HI in DRIP authentication message is checked back to
the USS and found not to match.
Finally, the UAS RID sender of a small harmless UA (or the entire UA)
could be carried by a larger dangerous UA as a "false flag."
Compromise of a registry private key could do widespread harm. Key
revocation procedures are as yet to be determined. These risks are
in addition to those involving Operator key management practices.
10. Privacy & Transparency Considerations 10. Privacy & Transparency Considerations
Broadcast RID messages can contain Personally Identifiable Broadcast RID messages can contain Personally Identifiable
Information (PII). A viable architecture for PII protection would be Information (PII). A viable architecture for PII protection would be
symmetric encryption of the PII using a session key known to the UAS symmetric encryption of the PII using a session key known to the UAS
and its USS. Authorized Observers could obtain plaintext in either and its USS. Authorized Observers could obtain plaintext in either
of two ways. An Observer can send the UAS ID and the cyphertext to a of two ways. An Observer can send the UAS ID and the cyphertext to a
server that offers decryption as a service. An Observer can send the server that offers decryption as a service. An Observer can send the
UAS ID only to a server that returns the session key, so that UAS ID only to a server that returns the session key, so that
 End of changes. 9 change blocks. 
23 lines changed or deleted 32 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/