--- 1/draft-ietf-drip-arch-03.txt 2020-10-28 01:13:34.653089999 -0700 +++ 2/draft-ietf-drip-arch-04.txt 2020-10-28 01:13:34.701091230 -0700 @@ -1,24 +1,24 @@ DRIP S. Card, Ed. Internet-Draft A. Wiethuechter Intended status: Informational AX Enterprize -Expires: 14 January 2021 R. Moskowitz +Expires: 1 May 2021 R. Moskowitz HTT Consulting S. Zhao Tencent A. Gurtov Linköping University - 13 July 2020 + 28 October 2020 Drone Remote Identification Protocol (DRIP) Architecture - draft-ietf-drip-arch-03 + draft-ietf-drip-arch-04 Abstract This document defines an architecture for protocols and services to support Unmanned Aircraft System Remote Identification and tracking (UAS RID), plus RID-related communications, including required architectural building blocks and their interfaces. Status of This Memo @@ -28,71 +28,71 @@ 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 14 January 2021. + This Internet-Draft will expire on 1 May 2021. Copyright Notice Copyright (c) 2020 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. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 5 - 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 5 + 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 6 + 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 6 2.2. Additional Definitions . . . . . . . . . . . . . . . . . 6 3. Entities and their Interfaces . . . . . . . . . . . . . . . . 6 3.1. Private Information Registry . . . . . . . . . . . . . . 6 - 3.1.1. Background . . . . . . . . . . . . . . . . . . . . . 6 - 3.1.2. Proposed Approach . . . . . . . . . . . . . . . . . . 6 + 3.1.1. Background . . . . . . . . . . . . . . . . . . . . . 7 + 3.1.2. Proposed Approach . . . . . . . . . . . . . . . . . . 7 3.2. Public Information Registry . . . . . . . . . . . . . . . 7 3.2.1. Background . . . . . . . . . . . . . . . . . . . . . 7 - 3.2.2. Proposed Approach . . . . . . . . . . . . . . . . . . 7 - 3.3. CS-RID concept . . . . . . . . . . . . . . . . . . . . . 7 + 3.2.2. Proposed Approach . . . . . . . . . . . . . . . . . . 8 + 3.3. CS-RID concept . . . . . . . . . . . . . . . . . . . . . 8 3.3.1. Proposed optional CS-RID SDSP . . . . . . . . . . . . 8 - 3.3.2. Proposed optional CS-RID Finder . . . . . . . . . . . 8 - 4. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 8 - 4.2. Proposed Approach . . . . . . . . . . . . . . . . . . . . 9 + 3.3.2. Proposed optional CS-RID Finder . . . . . . . . . . . 9 + 4. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 9 + 4.2. Proposed Approach . . . . . . . . . . . . . . . . . . . . 10 5. DRIP Transactions enabling Trustworthy UAS RID . . . . . . . 10 - 6. Privacy for Broadcast PII . . . . . . . . . . . . . . . . . . 10 - 7. Architectural implications of EASA requirements . . . . . . . 11 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 - 10.2. Informative References . . . . . . . . . . . . . . . . . 12 + 6. Privacy for Broadcast PII . . . . . . . . . . . . . . . . . . 11 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 + 9.2. Informative References . . . . . . . . . . . . . . . . . 13 Appendix A. Overview of Unmanned Aircraft Systems (UAS) Traffic - Management (UTM) . . . . . . . . . . . . . . . . . . . . 15 + Management (UTM) . . . . . . . . . . . . . . . . . . . . 16 A.1. Operation Concept . . . . . . . . . . . . . . . . . . . . 16 - A.2. UAS Service Supplier (USS) . . . . . . . . . . . . . . . 16 + A.2. UAS Service Supplier (USS) . . . . . . . . . . . . . . . 17 A.3. UTM Use Cases for UAS Operations . . . . . . . . . . . . 17 - A.4. Overview UAS Remote ID (RID) and RID Standardization . . 17 - Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 + A.4. Overview UAS Remote ID (RID) and RID Standardization . . 18 + Appendix B. Architectural implications of EASA requirements . . 18 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction This document describes a natural Internet based architecture for Unmanned Aircraft System Remote Identification and tracking (UAS RID), conforming to proposed regulations and external technical standards, satisfying the requirements listed in the companion requirements document [drip-requirements]. The requirements document also provides an extended introduction to the problem space, use cases, etc. Only a brief summary of that introduction will be @@ -186,21 +186,42 @@ 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 the simplest hobby aircraft, position and status flow from the UA to the GCS. Via the Internet, through three distinct segments, Network RID information flows from the UAS (comprising the UA and its GCS) to the Observer. Other Standards Development Organizations (SDOs, e.g., 3GPP, Appendix A.4) may define their own communication methods for both Network and Broadcast RID. The CAAs expect any additional methods to - maintain consistency of the RID messages. + maintain consistency of the RID messages. Encapsulation of Broadcast + RID messages in IP packets is infeasible over data links that support + only very small transmission frames, such as the [F3411-19] specified + Bluetooth 4 one-way advertisements, which cannot fit IP much less + transport layer overhead (even with header compression); but emerging + data links such as [I-D.maeurer-raw-ldacs] should not suffer such + severe limitations. + + For sharing location information, manned aviation uses a technology + known as Automatic Dependent Surveillance Broadcast (ADS-B), which is + a ground and satellite based system designed in the early 2000s. + Broadcast RID is conceptually similar to ADS-B. However, for + numerous technical and regulatory reasons, ADS-B itself is not + suitable for low-flying small UA. Technical reasons include: needing + RF-LOS to large, expensive (hence scarce) ground stations; needing + both a satellite receiver and 1090 MHz transceiver onboard CSWaP + constrained UA; the limited bandwidth of both uplink and downlink, + which are adequate for the current manned aviation traffic volume, + but would likely be saturated by large numbers of UAS, endangering + manned aviation; etc. Understanding these technical shortcomings, + regulators world-wide have ruled out use of ADS-B for the small UAS + for which UAS RID and DRIP are intended. DRIP will enable leveraging existing Internet resources (standard protocols, services, infrastructure and business models) to meet UAS RID and closely related needs. DRIP will specify how to apply IETF standards, complementing [F3411-19] and other external standards, to satisfy UAS RID requirements. DRIP will update existing and develop new protocol standards as needed to accomplish the foregoing. This document will outline the UAS RID architecture into which DRIP must fit, and an architecture for DRIP itself. This includes @@ -274,59 +293,71 @@ A DRIP private information registry MUST support essential Internet domain name registry operations (e.g. add, delete, update, query) using interoperable open standard protocols. It SHOULD support the Extensible Provisioning Protocol (EPP) and the Registry Data Access Protocol (RDAP) with access controls. It MAY use XACML to specify those access controls. It MUST be listed in a DNS: that DNS MAY be private; but absent any compelling reasons for use of private DNS, SHOULD be the definitive public Internet DNS hierarchy. The DRIP private information registry in which a given UAS is registered MUST be locatable, starting from the UAS ID, using the methods specified - in [RFC7484]. + in [RFC7484]. A DRIP private information registry MAY support + WebFinger as specified in [RFC7033]. 3.2. Public Information Registry 3.2.1. Background The public information required to be made available by UAS RID is transmitted as cleartext to local observers in Broadcast RID and is served to a client by a Net-RID DP in Network RID. Therefore, while IETF can offer e.g. [RFC6280] as one way to implement Network RID, the only public information required to support essential DRIP functions for UAS RID is that required to look up Internet domain hosts, services, etc. 3.2.2. Proposed Approach A DRIP public information registry MUST be a standard DNS server, in the definitive public Internet DNS hierarchy. It MUST support NS, MX, SRV, TXT, AAAA, PTR, CNAME and HIP RR (the last per [RFC8005]) - types. + types. If a DRIP public information registry lists, in a HIP RR, any + HIP RVS servers for a given DRIP UAS ID, those RVS servers MUST + restrict relay services per AAA policy; this may require extensions + to [RFC8004] 3.3. CS-RID concept ASTM anticipated that regulators would require both Broadcast RID and Network RID for large UAS, but allow 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 UAS of essentially all UAS and is now considering Network RID also. The FAA - NPRM requires both for Standard RID and specifies Broadcast RID only + NPRM requires both for Standard RID and specifies Network RID only for Limited RID. 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. Such gateways could be pre-positioned (e.g. around airports and other sensitive areas) and/or crowdsourced (as nothing - more than a smartphone with a suitable app is needed). Gateways can - also perform multilateration to provide independent measurements of - UA position, which is otherwise entirely operator self-reported in - UAS RID and UTM. CS-RID would be an option, beyond baseline DRIP - functionality; if implemented, it adds two more entity types. + 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 SDSP to the + failed sanity check possibly indicating intent to deceive. + Surveillance SDSPs can use messages with precise date/time/position + stamps from the gateways to multilaterate UA location, independent of + the locations claimed in the messages, which are entirely operator + self-reported in UAS RID and UTM. 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 RID messages. CS-RID would be an option, beyond + baseline DRIP functionality; if implemented, it adds two more entity + types. 3.3.1. Proposed optional CS-RID SDSP 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 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 a standard client-facing interface as if it were a Net-RID DP. A CS- RID SDSP MUST present a TBD interface to a CS-RID Finder; this interface SHOULD be based upon but readily distinguishable from that @@ -476,91 +506,61 @@ PII is protected unless the UAS is informed otherwise. This may come from operational instructions to even permit flying in a space/time. It may be special instructions at the start or during an operation. PII protection should not be used if the UAS loses connectivity to the USS. The USS always has the option to abort the operation if PII protection is disallowed. An authorized Observer may instruct a UAS via the USS that conditions have changed mandating no PII protection or land the UA. -7. Architectural implications of EASA requirements - - According to EASA, in EU broadcasting drone identification will be - mandatory from July 2020. Following info should be sent in cleartext - over Wifi or Bluetooth. In real time during the whole duration of - the flight, the direct periodic broadcast from the UA using an open - and documented transmission protocol, of the following data, in a way - that they can be received directly by existing mobile devices within - the broadcasting range: - - i) the UAS operator registration number; - - ii) the unique physical serial number of the UA compliant with - standard ANSI/CTA2063; - - iii) the geographical position of the UA and its height above the - surface or take-off point; - - iv) the route course measured clockwise from true north and ground - speed of the UA; and - - v) the geographical position of the remote pilot or, if not - available, the take-off point; - - The architecture proposed in this document partially satisfies EASA - requirements. In particular, i) is included to Operator-ID Message - as optional. ii) cannot be directly supported due to its heavy - privacy implications. A cryptographic identifier that needs to be - resolved is proposed instead. iii) and iv) are included into - Location/Vector Message. v) is included into a System Message - (optional). - -8. IANA Considerations +7. IANA Considerations This document does not make any request to IANA. -9. Security Considerations +8. Security Considerations DRIP is all about safety and security, so content pertaining to such is not limited to this section. 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 which communicates over the Internet with the factory may be sending a copy of a UA or GCS self-generated key back - to the factory. 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. + to the factory. Keys may be extracted from a GCS or UA; the 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. References +9. References -10.1. Normative References +9.1. Normative References [drip-requirements] Card, S., Wiethuechter, A., Moskowitz, R., and A. Gurtov, "Drone Remote Identification Protocol (DRIP) Requirements", Work in Progress, Internet-Draft, draft- - ietf-drip-reqs-01, 25 May 2020, - . + ietf-drip-reqs-05, 16 October 2020, + . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . -10.2. Informative References +9.2. Informative References [ATIS-I-0000074] ATIS, "Report on UAS in 3GPP", . [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, @@ -572,79 +572,87 @@ [Delegated] European Union Aviation Safety Agency (EASA), "EU Commission Delegated Regulation 2019/945 of 12 March 2019 on unmanned aircraft systems and on third-country operators of unmanned aircraft systems", March 2019. [drip-auth] Wiethuechter, A., Card, S., and R. Moskowitz, "DRIP Authentication Formats", Work in Progress, Internet-Draft, - draft-wiethuechter-drip-auth-01, 10 July 2020, + draft-wiethuechter-drip-auth-04, 21 September 2020, . + 04>. [drip-identity-claims] Wiethuechter, A., Card, S., and R. Moskowitz, "DRIP Identity Claims", Work in Progress, Internet-Draft, draft- - wiethuechter-drip-identity-claims-00, 23 March 2020, + wiethuechter-drip-identity-claims-02, 26 October 2020, . + identity-claims-02>. [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-00, 6 April 2020, . + nrid-c2-01, 27 September 2020, + . [drip-uas-rid] Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov, "UAS Remote ID", Work in Progress, Internet-Draft, draft- - moskowitz-drip-uas-rid-02, 28 May 2020, + moskowitz-drip-uas-rid-06, 17 August 2020, . + 06>. [F3411-19] ASTM, "Standard Specification for Remote ID and Tracking", December 2019. [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, . [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, . + [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, + . + [Implementing] European Union Aviation Safety Agency (EASA), "EU Commission Implementing Regulation 2019/947 of 24 May 2019 on the rules and procedures for the operation of unmanned aircraft", May 2019. [LAANC] United States Federal Aviation Administration (FAA), "Low Altitude Authorization and Notification Capability", . [new-hip-crypto] Moskowitz, R., Card, S., and A. Wiethuechter, "New Cryptographic Algorithms for HIP", Work in Progress, - Internet-Draft, draft-moskowitz-hip-new-crypto-04, 23 - January 2020, . + Internet-Draft, draft-moskowitz-hip-new-crypto-05, 26 July + 2020, . [new-orchid] Moskowitz, R., Card, S., and A. Wiethuechter, "Using cSHAKE in ORCHIDs", Work in Progress, Internet-Draft, draft-moskowitz-orchid-cshake-01, 21 May 2020, . [NPRM] United States Federal Aviation Administration (FAA), "Notice of Proposed Rule Making on Remote Identification @@ -654,29 +662,37 @@ Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, . [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, DOI 10.17487/RFC6280, July 2011, . + [RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr, + "WebFinger", RFC 7033, DOI 10.17487/RFC7033, September + 2013, . + [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, DOI 10.17487/RFC7401, April 2015, . [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March 2015, . + [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) + Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, + October 2016, . + [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, October 2016, . [TS-22.825] 3GPP, "UAS RID requirement study", . [TS-36.777] @@ -780,20 +796,51 @@ release 16, it completed the UAS RID requirement study in [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 specification works on enhanced UAS service requirement and provides the protocol and application architecture support which is applicable for both 4G and 5G network. ATIS's recent report [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]. +Appendix B. Architectural implications of EASA requirements + + According to EASA, in EU broadcasting drone identification will be + mandatory from July 2020. Following info should be sent in cleartext + over Wifi or Bluetooth. In real time during the whole duration of + the flight, the direct periodic broadcast from the UA using an open + and documented transmission protocol, of the following data, in a way + that they can be received directly by existing mobile devices within + the broadcasting range: + + i) the UAS operator registration number; + + ii) the unique physical serial number of the UA compliant with + standard ANSI/CTA2063; + + iii) the geographical position of the UA and its height above the + surface or take-off point; + + iv) the route course measured clockwise from true north and ground + speed of the UA; and + + v) the geographical position of the remote pilot or, if not + available, the take-off point; + The architecture proposed in this document partially satisfies EASA + requirements. In particular, i) is included to Operator-ID Message + as optional. ii) cannot be directly supported due to its heavy + privacy implications. A cryptographic identifier that needs to be + resolved is proposed instead. iii) and iv) are included into + Location/Vector Message. v) is included into a System Message + (optional). + Acknowledgments The work of the FAA's UAS Identification and Tracking (UAS ID) Aviation Rulemaking Committee (ARC) is the foundation of later ASTM and proposed IETF DRIP WG efforts. The work of ASTM F38.02 in balancing the interests of diverse stakeholders is essential to the necessary rapid and widespread deployment of UAS RID. IETF volunteers who have contributed to this draft include Amelia Andersdotter and Mohamed Boucadair.