--- 1/draft-ietf-drip-arch-21.txt 2022-03-21 13:13:11.116460171 -0700 +++ 2/draft-ietf-drip-arch-22.txt 2022-03-21 13:13:11.172461576 -0700 @@ -1,24 +1,24 @@ drip S. Card Internet-Draft A. Wiethuechter Intended status: Informational AX Enterprize -Expires: 8 September 2022 R. Moskowitz +Expires: 22 September 2022 R. Moskowitz HTT Consulting S. Zhao (Editor) Tencent A. Gurtov Linköping University - 7 March 2022 + 21 March 2022 Drone Remote Identification Protocol (DRIP) Architecture - draft-ietf-drip-arch-21 + draft-ietf-drip-arch-22 Abstract This document describes an architecture for protocols and services to support Unmanned Aircraft System (UAS) Remote Identification (RID) and tracking, plus UAS RID-related communications. This architecture adheres to the requirements listed in the DRIP Requirements document (RFC9153). Status of This Memo @@ -29,21 +29,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. @@ -85,21 +85,21 @@ 6.1. The CS-RID Finder . . . . . . . . . . . . . . . . . . . . 18 6.2. The CS-RID SDSP . . . . . . . . . . . . . . . . . . . . . 18 7. DRIP Contact . . . . . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 10. Privacy & Transparency Considerations . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . 20 Appendix A. Overview of Unmanned Aircraft Systems (UAS) Traffic - Management (UTM) . . . . . . . . . . . . . . . . . . . . 23 + Management (UTM) . . . . . . . . . . . . . . . . . . . . 24 A.1. Operation Concept . . . . . . . . . . . . . . . . . . . . 24 A.2. UAS Service Supplier (USS) . . . . . . . . . . . . . . . 24 A.3. UTM Use Cases for UAS Operations . . . . . . . . . . . . 25 Appendix B. Automatic Dependent Surveillance Broadcast (ADS-B) . . . . . . . . . . . . . . . . . . . . . . . . . 25 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction @@ -732,23 +732,23 @@ ASTM anticipated that regulators would require both Broadcast RID and Network RID for large UAS, but allow UAS RID requirements for small UAS to be satisfied with the operator's choice of either Broadcast RID or Network RID. The EASA initially specified Broadcast RID for essentially all UAS, and is now also considering Network RID. The FAA UAS RID Final Rules [FAA_RID] permit only Broadcast RID for rule compliance, but still encourage Network RID for complementary functionality, especially in support of UTM. - One obvious opportunity is to enhance the architecture with gateways - from Broadcast RID to Network RID. This provides the best of both - and gives regulators and operators flexibility. It offers advantages + One opportunity is to enhance the architecture with gateways from + Broadcast RID to Network RID. This provides the best of both and + gives regulators and operators flexibility. It offers advantages over either form of UAS RID alone: greater fidelity than Network RID reporting of planned area operations; surveillance of areas too large for local direct visual observation and direct RF-LOS link based Broadcast RID (e.g., a city or a national forest). These gateways could be pre-positioned (e.g., around airports, public gatherings, and other sensitive areas) and/or crowd-sourced (as nothing more than a smartphone with a suitable app is needed). As Broadcast RID media have limited range, gateways receiving messages claiming locations far from the gateway can alert authorities or a @@ -761,35 +761,35 @@ misconfiguration or intentional deception. Multilateration technologies use physical layer information, such as precise Time Of Arrival (TOA) of transmissions from mobile transmitters at receivers with a priori precisely known locations, to estimate the locations of the mobile transmitters. Further, gateways with additional sensors (e.g., smartphones with cameras) can provide independent information on the UA type and size, 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 - adds two more entity types. + + Section 6.1 and Section 6.2 define two additional entities that are + required to provide this Crowd Sourced Remote ID (CS-RID). This approach satisfies the following DRIP requirements defined in [RFC9153]: GEN-5, GEN-11, and REG-1. 6.1. The CS-RID Finder 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 Finder could implement, integrate, or accept outputs from a Broadcast 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 - 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. 6.2. The CS-RID SDSP A CS-RID SDSP aggregates and processes (e.g., estimates UA location using multilateration when possible) information collected by CS-RID Finders. A CS-RID SDSP should appear (i.e., present the same interface) to a Net-RID SP as a Net-RID DP. 7. DRIP Contact @@ -839,31 +839,40 @@ satisfaction of requirements [RFC9153] GEN-8, GEN-9, PRIV-2, PRIV-5 and REG-3, and is compatible with all other DRIP requirements. 8. IANA Considerations This document does not make any IANA request. 9. Security Considerations The security provided by asymmetric cryptographic techniques depends - upon protection of the private keys. A manufacturer that embeds a - private key in an UA may have retained a copy. A manufacturer whose - UA are configured by a closed source application on the GCS that - communicates over the Internet with the factory may be sending a copy - of a UA or GCS self-generated key back to the factory. Keys may be - extracted from a GCS or UA. 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. + upon protection of the private keys. It may be necessary for the GCS + to have the key pair to register the HHIT to the USS. Thus it may be + the GCS that generates the key pair and delivers it to the UA, making + the GCS a part of the key security boundary. Leakage of the private + key either from the UA or GCS to the component manufacturer is a + valid concern and steps need to be in place to ensure safe keeping of + the private key. + + The size of the public key hash in the HHIT is also of concern. It + is well within current server array technology to compute another key + 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 Broadcast RID messages can contain Personally Identifiable Information (PII). A viable architecture for PII protection would be symmetric encryption of the PII using a session key known to the UAS 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 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