| < 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/ | ||||