--- 1/draft-ietf-drip-arch-05.txt 2020-12-14 09:13:25.677805777 -0800 +++ 2/draft-ietf-drip-arch-06.txt 2020-12-14 09:13:25.725807002 -0800 @@ -1,24 +1,24 @@ drip S. Card Internet-Draft A. Wiethuechter Intended status: Informational AX Enterprize -Expires: 6 May 2021 R. Moskowitz +Expires: 17 June 2021 R. Moskowitz HTT Consulting S. Zhao (Editor) Tencent A. Gurtov - Linköping University - 2 November 2020 + Linkoeping University + 14 December 2020 Drone Remote Identification Protocol (DRIP) Architecture - draft-ietf-drip-arch-05 + draft-ietf-drip-arch-06 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,21 +28,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 6 May 2021. + This Internet-Draft will expire on 17 June 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 @@ -57,49 +57,52 @@ 1.1. Overview UAS Remote ID (RID) and RID Standardization . . 3 1.2. Overview of Types of UAS Remote ID . . . . . . . . . . . 4 1.2.1. Network RID . . . . . . . . . . . . . . . . . . . . . 4 1.2.2. Broadcast RID . . . . . . . . . . . . . . . . . . . . 5 1.3. Overview of USS Interoperability . . . . . . . . . . . . 5 1.4. Overview of DRIP Archicture . . . . . . . . . . . . . . . 6 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Definitions and Abbreviations . . . . . . . . . . . . . . . . 8 3.1. Additional Definitions . . . . . . . . . . . . . . . . . 8 3.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 8 - 4. HHIT for UAS RID . . . . . . . . . . . . . . . . . . . . . . 9 - 5. DRIP RID Entities (WAS Entities and their interfaces) . . . . 10 - 5.1. Private Information Registry . . . . . . . . . . . . . . 10 - 5.1.1. Background . . . . . . . . . . . . . . . . . . . . . 10 + 4. HHIT for UAS Remote ID . . . . . . . . . . . . . . . . . . . 9 + 4.1. HIT as a Trustworthy Remote ID . . . . . . . . . . . . . 9 + 4.2. HHIT for Remote ID Registration and Lookup . . . . . . . 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.2. Public Information Registry . . . . . . . . . . . . . . . 11 - 5.2.1. Background . . . . . . . . . . . . . . . . . . . . . 11 - 5.2.2. Proposed Approach . . . . . . . . . . . . . . . . . . 11 - 5.3. CS-RID concept . . . . . . . . . . . . . . . . . . . . . 11 - 5.3.1. Proposed optional CS-RID SDSP . . . . . . . . . . . . 12 - 5.3.2. Proposed optional CS-RID Finder . . . . . . . . . . . 12 + 5.2. Public Information Registry . . . . . . . . . . . . . . . 12 + 5.2.1. Background . . . . . . . . . . . . . . . . . . . . . 12 + 5.2.2. Proposed Approach . . . . . . . . . . . . . . . . . . 12 + 5.3. CS-RID concept . . . . . . . . . . . . . . . . . . . . . 12 + 5.3.1. Proposed optional CS-RID SDSP . . . . . . . . . . . . 13 + 5.3.2. Proposed optional CS-RID Finder . . . . . . . . . . . 13 6. UAS Remote Identifiers . . . . . . . . . . . . . . . . . . . 13 6.1. Background . . . . . . . . . . . . . . . . . . . . . . . 13 - 6.2. Proposed Approach . . . . . . . . . . . . . . . . . . . . 13 - 7. DRIP Transactions enabling Trustworthy . . . . . . . . . . . 14 - 8. Privacy for Broadcast PII . . . . . . . . . . . . . . . . . . 15 + 6.2. Proposed Approach . . . . . . . . . . . . . . . . . . . . 14 + 7. DRIP Transactions enabling Trustworthy . . . . . . . . . . . 15 + 8. Privacy for Broadcast PII . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 - 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 + 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 12.2. Informative References . . . . . . . . . . . . . . . . . 17 Appendix A. Overview of Unmanned Aircraft Systems (UAS) - Traffic . . . . . . . . . . . . . . . . . . . . . . . . . 20 + Traffic . . . . . . . . . . . . . . . . . . . . . . . . . 19 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.4. Automatic Dependent Surveillance Broadcast (ADS-B) . . . 22 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 + A.4. Automatic Dependent Surveillance Broadcast (ADS-B) . . . 21 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction This document describes a natural Internet and MAC-layer broadcast- 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 [I-D.ietf-drip-reqs]. Many considerations (especially safety) dictate that UAS be remotely @@ -123,179 +126,188 @@ ASTM ASTM International, Technical Committee F38 (UAS), Subcommittee F38.02 (Aircraft Operations), Work Item WK65041, developed the new ASTM [F3411-19] Standard Specification for Remote ID and Tracking. ASTM defines one set of RID information and two means, MAC-layer broadcast and IP-layer network, of communicating it. If a UAS 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 ID rule. 3GPP - 3GPP provides UA service in the LTE network since release 15 in - published technical specification [TS-36.777]. Start from its - release 16, it completed the UAS RID requirement study in + With release 16, 3GPP completed the UAS RID requirement study [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 + services that can be offered based on RID. Release 17 + specification works on enhanced UAS service requirements 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]. + is applicable for both 4G and 5G network. 1.2. Overview of Types of UAS Remote ID 1.2.1. Network RID - Network RID defines a RID data dictionary and data flow: from a UAS - via unspecified means to a Network Remote ID Service Provider (Net- - RID SP); from the Net-RID SP to an integrated, or over the Internet - to a separate, Network Remote ID Display Provider (Net- RID DP); from - the Net-RID DP via the Internet to Network Remote ID clients in - response to their queries (expected typically, but not specified - exclusively, to be web based) specifying airspace volumes of - interest. Network RID depends upon connectivity, in several - segments, via the Internet, from the UAS to the Observer. + A RID data dictionary and data flow for Network RID are defined in + [F3411-19]. This flow is from a UAS via unspecified means (but at + least in part over the Internet) to a Network Remote ID Service + Provider (Net-RID SP). These Net-RID SPs provide this information to + Network Remote ID Display Providers (Net-RID DP). It is the Net-RID + DP that respond to queries from Network Remote ID clients (expected + typically, but not specified exclusively, to be web based) specifying + airspace volumes of interest. Network RID depends upon connectivity, + 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 xxxxx ******************** - | * ------*---+------------+ - | * / * | NET_Rid_SP | - | * ------------/ +---*--+------------+ - | RF */ | * + | \ * ------*---+------------+ + | \ * / * | NET_RID_SP | + | \ * ------------/ +---*--+------------+ + | RF \ */ | * | * INTERNET | * +------------+ - | /* +---*--| NET_Rid_DP | - | / * +----*--+------------+ + | /* +---*--| NET_RID_DP | + | / * +---*--+------------+ + / * | * - x / ****************|*** x + x / *****************|*** x xxxxx | xxxxx x +------- x x x x x Operator (GCS) Observer x x x x x x Figure 1 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. + Command and Control (C2) flows between the GCS to the UA such that + either can communicate with the Net-RID SP. For all but the simplest + hobby aircraft, position and status flow from the UA to the GCS and + on to the Net-RID SP. Thus via the Internet, through three distinct + segments, Network RID information flows from the UAS to the Observer. 1.2.2. Broadcast RID - Broadcast RID defines a set of RID messages and how the UA transmits - them locally directly one-way, over Bluetooth or Wi-Fi. Broadcast - RID should need Internet (or other Wide Area Network) connectivity - only for UAS registry information lookup using the locally directly - received UAS ID as a key. Broadcast RID should be functionally - usable in situations with no Internet connectivity. + A set of RID messages are defined for direct, one-way, broadcast + transmissions from the UA over Bluetooth or Wi-Fi. These are + currently defined as MAC-Layer messages. Internet (or other Wide + Area Network) connectivity is only needed for UAS registry + information lookup by Observers using the locally directly received + 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. - Editor's note: Is there a need to add interconnections between - B-RID and N-RID in the drawing - x x UA xxxxx | | | app messages directly over | one-way RF data link (no IP) | | + x xxxxx x x x x Observer's device (e.g. smartphone) x x Figure 2 - Editor's note: the following may more clarification: - - * what Broadcast RID can do w/ & w/o Observer Internet connectivity - - * How Broadcast RID transmits public info (obviating some registry - lookups) - - * how Network RID is "less constrained" than Broadcast RID + With Broadcast RID, an Observer is limited to their radio "visible" + airspace for UAS awareness and information. With Internet queries + using harvested RID, the Observer may gain more information about + those visible UAS. 1.3. Overview of USS Interoperability - Editor's Note: Show how DRIP RID is an enabler of USS - Interoperability Figure 3 - +-------+ - | DSS | - +-------+ + Each UAS is registered to at least one USS. With Net-RID, there is + direct communication between the UAS and its USS. With Broadcast- + RID, the UAS Operator has either pre-filed a 4D space volume for USS + 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. + + +----------+ + | Observer | + +----------+ + / \ / \ + +-----+ +-----+ + | UA1 | | UA2 | + +-----+ +-----+ + \ / + \ / + +----------+ + | Internet | + +----------+ / \ / \ +-------+ +-------+ - | USS-1 | <----------> | USS-2 | + | USS-1 | <-------> | USS-2 | +-------+ +-------+ + \ / + \ / + +------+ + | DSS | + +------+ Figure 3 1.4. Overview of DRIP Archicture The requirements document also provides an extended introduction to the problem space, use cases, etc. Only a brief summary of that introduction will be restated here as context, with reference to the general architecture shown in Figure 4 below. General x x Public Public xxxxx xxxxx Safety Observer x x Observer x x x x ---------+ +---------- x x x x | | x x | | - + + - xxxxxxxxxx - x x - +----------+x Internet x+------------+ + UA1 x x | | +------------ x x UA2 + xxxxx | | | xxxxx + | + + + | + | xxxxxxxxxx | | x x | - UA1 x | xxxxxxxxxx | x UA2 - Pilot xxxxx + + + xxxxx Pilot - Operator x | | | x Operator + +----------+x Internet x+------------+ + UA1 | x x | UA1 + Pilot x | xxxxxxxxxx | x Pilot + Operator xxxxx + + + xxxxx Operator + GCS1 x | | | x GCS2 x | | | x x x | | | x x x x | | | x x | | | +----------+ | | | +----------+ | |------+ | +-------| | | Public | | | Private | | Registry | +-----+ | Registry | | | | DNS | | | +----------+ +-----+ +----------+ Figure 4 Editor's note: the archteture may need more clarification, and address the following: - * add network RID and broadcast RID in the picture (since those are - the focus points) - - * connectivity requirements among UA, GCS, SP, DP (if necessary) ... + * connectivity requirements among UA, GCS, SP, DP (if necessary) 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 @@ -333,23 +345,20 @@ capitals, as shown above. 3. Definitions and Abbreviations 3.1. Additional Definitions Editor's Note: to be updated. 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 Editor's Note: to be updated. ADS-B: Automatic Dependent Surveillance Broadcast DSS: Discovery & Synchronization Service EdDSA: Edwards-Curve Digital Signature Algorithm @@ -365,74 +373,91 @@ Net-RID SP: Network RID Service Provider Net-RID DP: Network RID Display Provider. PII: Personally Identifiable Information RF: Radio Frequency SDSP: Supplemental Data Service Provider + UA: Unmanned Aircraft UAS: Unmanned Aircraft System USS: UAS Service Supplier UTM: UAS Traffic Management -4. HHIT for UAS RID - - 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. +4. HHIT for UAS Remote ID - 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 Identifier for use as the UAS Remote ID. HHITs self-attest to the included explicit hierarchy that provides Registrar discovery for 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 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 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. - other pointers: (mostly list how HHIT satisfy the reqs-) - - * 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?) +4.2. HHIT for Remote ID Registration and Lookup - - expand on different uses of & relationship between optional - manufacturer-assigned HI & subsequent single-use HIs + Remote IDs need a deterministic lookup mechanism that rapidly + 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 - justify why it won't work here + The HHIT needs to consist of a registration hierarchy, the hashing + 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 - Editors' note: this is also one of the Michael's comment, we - can address it here +4.3. HHIT for Remote ID Encryption - * 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) Editor: This section descrips the DRIP RID ecosystem such as RID design philosophy, PII registration, Still not sure this is a good title since here mainly talks about regiter, maybe use this seciton focus on HHIT RID registration?? I also have suggestion to move the CS-RID to a seperated section Any DRIP solutions for UAS RID must fit into the UTM (or U-space) @@ -578,22 +603,22 @@ * The ASTM Basic RID message (the message containing the RID) is 25 characters; only 3 characters are currently unused * The ASTM Authentication message, with some changes from [F3411-19] can carry 224 bytes of payload. Standard approaches like X.509 and PKI will not fit these constraints, even using the new EdDSA algorithm. An example of a technology that will fit within these limitations is an enhancement of the Host Identity Tag (HIT) of HIPv2 [RFC7401] introducing - hierarchy as defined in HHIT [I-D.moskowitz-hip-hierarchical-hit]; - using Hierarchical HITs for UAS RID is outlined in HHIT based UAS RID + hierarchy as defined in HHIT [I-D.ietf-drip-rid]; using Hierarchical + 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 systems with which UAS RID must interoperate (e.g. the UTM Discovery and Synchronization Service and the UTM InterUSS protocol) mappings between the more flexible but larger X.509 certificates and the HHIT based structures must be devised. 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 bytes. An observer would need Internet access to validate a self- assertion claim. A third-party assertion can be validated via a @@ -747,146 +772,85 @@ 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, . 12.2. Informative References - [ATIS-I-0000074] - ATIS, "Report on UAS in 3GPP", n.d., - . - [CTA2063A] ANSI, "Small Unmanned Aerial Systems Serial Numbers", 2019. [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", 2019. [F3411-19] ASTM, "Standard Specification for Remote ID and Tracking", 2019. [I-D.ietf-drip-rid] Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov, "UAS Remote ID", Work in Progress, Internet-Draft, draft- ietf-drip-rid-04, 1 November 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, . - - [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, . - - [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, . - - [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, . - - [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, . - - [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, . - - [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, - . - - [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, - . - - [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, - . - [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", 2019. [LAANC] United States Federal Aviation Administration (FAA), "Low Altitude Authorization and Notification Capability", n.d., . [NPRM] United States Federal Aviation Administration (FAA), "Notice of Proposed Rule Making on Remote Identification of Unmanned Aircraft Systems", 2019. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . - [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally - Unique IDentifier (UUID) URN Namespace", RFC 4122, - DOI 10.17487/RFC4122, July 2005, - . + [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", + RFC 3972, DOI 10.17487/RFC3972, March 2005, + . + + [RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash + Algorithms in Cryptographically Generated Addresses + (CGAs)", RFC 4982, DOI 10.17487/RFC4982, July 2007, + . [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, . [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", STD 69, RFC 5731, DOI 10.17487/RFC5731, August 2009, . [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, . + [RFC6537] Ahrenholz, J., "Host Identity Protocol Distributed Hash + Table Interface", RFC 6537, DOI 10.17487/RFC6537, February + 2012, . + [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 @@ -899,32 +863,26 @@ [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", n.d., . - [TS-36.777] - 3GPP, "UAV service in the LTE network", n.d., - . - [U-Space] European Organization for the Safety of Air Navigation (EUROCONTROL), "U-space Concept of Operations", 2019, . Appendix A. Overview of Unmanned Aircraft Systems (UAS) Traffic - A.1. Operation Concept The National Aeronautics and Space Administration (NASA) and FAAs' effort of integrating UAS's operation into the national airspace system (NAS) leads to the development of the concept of UTM and the ecosystem around it. The UTM concept was initially presented in 2013. The eventual development and implementation are conducted by the UTM research transition team which is the joint workforce by FAA and NASA. World efforts took place afterward. The Single European Sky ATM Research (SESAR) started the CORUS project to research its @@ -1017,31 +975,30 @@ Adam Wiethuechter AX Enterprize 4947 Commercial Drive Yorkville, NY, 13495 United States of America Email: adam.wiethuechter@axenterprize.com Robert Moskowitz HTT Consulting - na Oak Park, MI, 48237 United States of America Email: rgm@labs.htt-consult.com Shuai Zhao Tencent 2747 Park Blvd Palo Alto, 94588 United States of America Email: shuai.zhao@ieee.org Andrei Gurtov - Linköping University + Linkoeping University IDA - SE-58183 Linköping Linköping + SE-58183 Linkoeping Linkoeping Sweden Email: gurtov@acm.org