[Drip] draft-ietf-drip-registries-14
Daniel Migault <mglt.ietf@gmail.com> Sun, 25 February 2024 03:40 UTC
Return-Path: <mglt.ietf@gmail.com>
X-Original-To: tm-rid@ietfa.amsl.com
Delivered-To: tm-rid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F327C14F6A8 for <tm-rid@ietfa.amsl.com>; Sat, 24 Feb 2024 19:40:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObUSiUrFjcIL for <tm-rid@ietfa.amsl.com>; Sat, 24 Feb 2024 19:40:32 -0800 (PST)
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89281C14F618 for <tm-rid@ietf.org>; Sat, 24 Feb 2024 19:40:31 -0800 (PST)
Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-565a33537b4so925787a12.3 for <tm-rid@ietf.org>; Sat, 24 Feb 2024 19:40:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708832429; x=1709437229; darn=ietf.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=zvwBlkTE37S1Y+Et15RWWYy8huFmtUu8miX/AkGZGYM=; b=fM/7zbphE1sltYtPLpLmnu/GPJB/RzRX3QYqt2t4mbIVdbfHHflfc8j3xqifZuOdlC Y5BUJz8fHSX0UeqMI0UwuOmuPa6pqURCJTcB9pZfxzW7R+pI9QNQtRnOatzuKQZiDWRH WNoX71EY7lOv/PdUSVU5JWjgrpHHD63wNyJ0VGmsGTWQ/23qHF1fLevkUn/v9NKfomOZ a1YPrWwLOSp/cNwSZdLKjfd3NU85xnoKv/vSNtujNSayEELzLLO5JSNZliQJsh5Aa1Ff aM65sDL5XLqU3OcNgP0e9rbtJ9+4fLutN45r4hGJxbXGlgAM/t0OuROqEmBmYgx3Lbid IXug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708832429; x=1709437229; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=zvwBlkTE37S1Y+Et15RWWYy8huFmtUu8miX/AkGZGYM=; b=kO8A8trMyQLtQR2rTsJgzdKzbNaisZ7PDRedKrS+1lmIGyOlY4ZBBjFW422SRSmo13 c3uk41dYkwJDsyEYjcjxCDP7taB6o3eSXjLxZ+KZUKn2d4dhp0Ew88t5LM/HyIYkTcUW qbFzMp8JUEWMiu3BKO9/cd/LEePEgw/nSwgIe4ZvULNj82KNerl3NhALv2WQIk810m/4 tUuevA1e6jnp5jUKc+k+wA0uEcx8BCS1gQ4cYSU/8TtnuwmTeUZ8ldh7BM+DebeovMiW ZA22ZN1v4L2RncIjIHMPQmVAUzFjBHrXEWcRsFNdzvCsK8h99eXk98ROGxLsgxevYoy5 4ygw==
X-Gm-Message-State: AOJu0Yy86f3SlKcpEoYFJCTg4XgYXOzRI/hXyxqEwccX6cQ2VyV4wuNa XHJnVB6EAFUizc14zLUWBIyBliKmGlODxWcXQRBB9PJS9RWNglAuHAWzqUVb+ZmrZR3zPXYwT+o ElHsluKZFCyUa2FCgHfReNkU1KwMbyzi450k=
X-Google-Smtp-Source: AGHT+IEmpArh3FRKVpjBDt6Ry0XBa3JFpQPvy4rTC5F3CHFhN3A06Kps0GQQ9nhYtXVby5vhMkAWKd4ZuKigYdb9re8=
X-Received: by 2002:a17:906:3912:b0:a3e:8b9d:dfea with SMTP id f18-20020a170906391200b00a3e8b9ddfeamr2494347eje.66.1708832428113; Sat, 24 Feb 2024 19:40:28 -0800 (PST)
MIME-Version: 1.0
From: Daniel Migault <mglt.ietf@gmail.com>
Date: Sat, 24 Feb 2024 22:40:16 -0500
Message-ID: <CADZyTk=Qn4Z47fBbv5K5J_xQJh6iGK9LFUdRGvERsX9CCR_yow@mail.gmail.com>
To: tm-rid@ietf.org
Content-Type: multipart/alternative; boundary="000000000000dbc35b06122c8d4e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tm-rid/bRtLFg5vxHGkvViHXS3g-ggGMJw>
Subject: [Drip] draft-ietf-drip-registries-14
X-BeenThere: tm-rid@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Drone Remote Identification Protocol <tm-rid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tm-rid>, <mailto:tm-rid-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tm-rid/>
List-Post: <mailto:tm-rid@ietf.org>
List-Help: <mailto:tm-rid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tm-rid>, <mailto:tm-rid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 25 Feb 2024 03:40:40 -0000
Hi, Please find my review for sections up to 8.1 of draft-ietf-drip-registries-14 For these sections my impression is that the description could be more concise. Most of the comments are nits. I believe these can be addressed directly or discussed without creating an issue per comment ;-) Yours, Daniel drip Working Group A. Wiethuechter, Ed. Internet-Draft AX Enterprize, LLC Intended status: Standards Track J. Reid Expires: 6 June 2024 RTFM llp 4 December 2023 DRIP Entity Tag (DET) Identity Management Architecture draft-ietf-drip-registries-14 Abstract This document describes the high level architecture for the registration and discovery of DRIP Entity Tags (DETs) using DNS. Discovery of DETs and their artifacts are through DRIP specific DNS structures and standard DNS methods. <mglt> I am wondering if "are through" should not be replaced by "is performed via". </mglt> A general overview of the interfaces required between involved components is described in this document with future supporting documents giving technical specifications. <mglt> The sentence above could mean to say the description is based on future documents. The document seems to not provide much information regarding the interfaces so I would not emphasize that aspect here, and probably remove the text. </mglt> Status of This Memo [...] [ ..] 1. Introduction Registries are fundamental to Unmanned Aircraft System (UAS) Remote ID (RID). Only very limited operational information can be Broadcast, but extended information is sometimes needed. The most essential element of information is the UAS ID, the unique key for lookup of extended information in relevant registries (see Figure 4 of [RFC9434]). <mglt> s/Broadcast/broadcast/gc </mglt> While it is expected that DRIP Identity Management Entity (DIME) functions will be integrated with UAS Service Suppliers (USS) (Appendix A.2 of [RFC9434]), who will provide DIME-like functions is not yet determined in most, and is expected to vary between, jurisdictions. However this evolves, the essential DIME-like functions (including the management of identifiers (such as the DRIP Entity Tag (DET))) are expected to remain the same, so are specified herein. <mglt> The long sentences and a factorization of parentheses could be clarified. Essentially, the paragraph is saying that 1) This document assumes DIME is handled by the USS. 2) The architecture does not prevent any other entity from taking that role and 3) whoever takes that role will not affect the functions of the DIME. The use of DIME-like functions versus DIME functions need to be clarified. To link the two paragraphs, it would probably be clarifying to have an articulation between the UAS ID and the DET. I propose something around: Such extended information is retrieved from the UAS ID via the use of a DRIP Entity Tag (DET) which is managed by the DRIP Identity Management Entity (DIME). In this document we assume the DIME belongs to the UAS Service Suppliers (USS) (Appendix A.2 of [RFC9434]) but DIME can be handled by another entity as well. </mglt> Wiethuechter & Reid Expires 6 June 2024 [Page 3] Internet-Draft DETIM Architecture December 2023 While most data to be sent via Broadcast RID (Section 1.2.1 of [RFC9434]) or Network RID (Section 1.2.2 of [RFC9434]) is public, much of the extended information in registries will be private. <mglt> I do not see registry being used in a context of DNS registry. That said the document deals with DNS so this can be confusing. Assuming this is not a DNS registry, I suggest to clarify explicitly that registries are not related to registries/registrars. </mglt> As discussed in Section 7 of [RFC9434], Authentication, Attestation, Authorization, Access Control, Accounting, Attribution, and Audit (AAA) for registries is essential, not just to ensure that access is granted only to strongly authenticated, duly authorized parties, but also to support subsequent attribution of any leaks, audit of who accessed information when and for what purpose. <mglt> Is-it AAA or AAAACAAA ? Is registry the right terminology ? Here registrar seems more appropriated. </mglt> As specific AAA requirements will vary by jurisdictional regulation, provider choices, customer demand, etc., they are left to specification in policies, which should be human readable to facilitate analysis and discussion, and machine readable to enable automated enforcement, using a language amenable to both (e.g., eXtensible Access Control Markup Language (XACML)). <mglt> I am finding the text which "should be ... a bit out of scope. </mglt> The intent of the access control requirements on registries is to ensure that no member of the public would be hindered from accessing public information, while only duly authorized parties would be enabled to access private information. Mitigation of Denial of Service (DoS) attacks and refusal to allow database mass scraping would be based on those behavior, not on identity or role of the party submitting the query per se, but querant identity information might be gathered (by security systems protecting DRIP implementations) on such misbehavior. <mglt> After the mention of public and private information, a lot of text is describing or listing AAA* which is related to private information. Then the paragraph above details how public and private information are handled, followed by what is needed for public information. I do not think we should describe how to handle DDoS attacks... I suggest to rephrase this as follows: <handling of public / private information> The intent of the access control requirements on registries is to ensure that no member of the public would be hindered from accessing public information, while only duly authorized parties would be enabled to access private information. <public information> To ensure public information remains available to the public, the registry is expected to provide a robust and reliable service... Mitigation of Denial of Service (DoS) attacks and refusal to allow database mass scraping <private information> To protect private information, as specific AAA requirements..... </mglt> Registration under DRIP is vital to manage the inevitable collisions in the hash portion of the DET (Section 9.5 of [RFC9374]). Forgery of a DET is still possible, but including it as a part of a public registration mitigates this risk. <mglt> I am not sure "Registration under DRIP" has been defined and will be clearly understood by the reader. Inevitable discussion seems also to contradict 9374 section 9.5 where collisions are mentioned to have a low probability. I think what we want to say here is that Registration is necessary to guarantee the uniqueness of the DET and thus to ensure the extended information is bound to the UAS ID. </mglt> This document creates the DRIP registration and discovery ecosystem <mglt> ecosystem is quite vague. architecture, protocols are more in line with what we specify at the IETF. </mglt> focusing on the DET. This <mglt> It is unclear to me what "This" relates to. I suspect This stands for a registration/discovery protocol as an architecture is not supported by components. </mglt> SHOULD support all components in the ecosystem (e.g., Unmanned Aircraft (UA), Registered Assigning Authority (RAA), Hierarchical HIT Domain Authority (HDA), Ground Control Station (GCS), and USS) that can use a DET. This document uses the Concise Data Definition Language (CDDL) [RFC8610] for describing the registration data. 2. Abstract Process and Reasoning In DRIP each entity (DIME, Operator, UA, etc.) is expected to generate a DET [RFC9374] on the local device their key is expected to be used. <mglt> Just for my understanding, reading this sentence it seems that one UA has multiple DET. I understand it is possible, but it seems to me that the simple case is a UA having a SINGLE UAS ID which is registered as DET. Depending on the situation the UAS ID (DET) can be registered/generated by different entities. If that is correct, I think the paragraph should be rephrased. </mglt> These are registered with a Public Information Registry (e.g. DNS) within the hierarchy along with whatever data is required by the cognizant CAA and the DIME. <mglt> I am not familiar with "Public Information Registry". I understand we may not want to stick to DNS.... but I think given what we have now we should say this is the DNS clearly. The text seems to say registration involves the CAA and the DIME. I tend to think that the UA is registered to the DIME that complies with the CAA. Is that correct ? </mglt> Any Personally Identifiable Information (PII) is stored in a Private Information Registry Wiethuechter & Reid Expires 6 June 2024 [Page 4] Internet-Draft DETIM Architecture December 2023 protected through industry practice AAA or stronger. <mglt> s/industry practice AAA or stronger/AAA/gc industry practice seems to indicate we will stay with whatever exists, but stronger means we will go beyond what exists. This contradicts the first "industry practice". It seems clearer to me to remove that text. </mglt> In response, the entity will obtain an endorsement from the DIME proving such registration. <mglt> I think that when we mentioned the UA registered to the DIME, implicitly we expect a confirmation, so I do not see this as very useful information. </mglt> Manufacturers that wish to participate in DRIP should not only support DRIP as a Session ID <mglt> Probably we should provide a reference to Session ID. Note also that it seems to me this is referenced as Specific Session ID. (UAS type 4). If that is the same entity maybe we should be coherent with the previous docs. </mglt> type for their aircraft but could also generate a DET then encode it as a Serial Number (Section 4.2 of [RFC9374]). <mglt> There are a lot of should /could. As these are not expressed in capital letters, I tend to say these are pure speculation and are here as informative. I tend to think we do not need to be so cautious as long as we clearly mention this is an illustrative example on how we expect this will work. With such an introduction the description can be straight forward. </mglt> This would allow aircraft under CAA mandates to fly only ID Type 1 (Serial Number) could still use DRIP and most of its benefits. <mglt> I do not understand the sentence. I am reading "under CAA mandates to fly only ID Type1" as one groupe so the sentence sounds to me This would allow aircraft [..] could still use DRIP.... I suspect this is a mix between "This would allow aircraft to use DRIP..." or" Aircrafts could still...." As you know I am not native english so that might be correct also. </mglt> Even if DRIP is not supported for Serial Numbers by a Manufacturer it is hoped that they would still run a DIME to store their Serial Numbers and allow look ups for generic model information. This look up could be especially helpful in UTM for Situational Awareness when an aircraft flying with a Serial Number is detected and allow for an aircraft profile to be displayed. <mglt> "It is hoped" is too speculative in my opinion. s/Manufacturer/manufacturer </mglt> Operators are registered with a number of registries or their regional RAA. This acts as a verification check when a user performs other registration operations; such as provisioning an aircraft with a new Session ID. It is an open question if an Operator registers to their CAA (the RAA's direct HDA) or multiple USS's (HDA's). PII of the Operator would vary based on the CAA they are under and the DIME. Finally, aircraft that support using a DET would provision per flight to a USS, proposing a DET to the DIME to generate a binding between the aircraft (Session ID, Serial Number, and Operational Intent), operator and DIME. The aircraft then follows [drip-auth] to meet various requirements from [RFC9153] during a flight. 3. Terminology 3.1. Required Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3.2. Additional Definitions This document makes use of the terms (PII, USS, etc.) defined in [RFC9153]. Other terms (DIME, Endorsement, etc.) are from [RFC9434], while others (RAA, HDA, etc.) are from [RFC9374]. Wiethuechter & Reid Expires 6 June 2024 [Page 5] Internet-Draft DETIM Architecture December 2023 3.3. Text Conventions When talking about a DIME in documents it should be referred to as the role it is serving. For example a CAA level DIME running services both as an RAA (its primary role in the hierarchy) and as an HDA (optionally) would be be referred to "RAA" when performing its RAA duties and "HDA" when performing its HDA duties. The rest of the document will follow this convention unless verbosity or clarity is needed. 4. DIME Roles [RFC9434] defines the DRIP Identity Management Entity (DIME) as an entity that vets Claims and/or Evidence from a registrant and delivers, to successful registrations, Endorsements and/or Certificates in response. The DIME encompasses various logical components and can be classified to serve a number of different roles, which are detailed in the following subsections. The general hierarchy of these initial roles (some highly specialized and predetermined for the UAS use case) are illustrated in Figure 1. +----------+ | Apex o--------. +-o------o-+ | | | | ******************|******|**********|****************** | | | +-----o-+ +-o-----+ +-o-----+ RAAs | MCA | | INN | | RAA | +---o---+ +---o---+ +---o---+ | | | ****************|**********|**********|**************** | | | +---o---+ +---o---+ +---o---+ HDAs | MAA | | HDA | | HDA | +-------+ +-------+ +-------+ Figure 1: DIME Roles and Hierarchy <mglt> I think it would be good to clarify the meaning of the acronyms. We should also explain what RAA/HDA differs from the generic RAAs/HDAs. DET defines RAA and HDA as some bits, and it seems that some sort of delegation exists between RAA and HDAs. However, there are no bits for Apex and as such Figure 1 does not seem to represent that delegation induced by the DET fields but instead as a specific "administrative entity" that uses special bits values for RAA and HDA. Maybe that is clarified after, but the current description is missing to specify that it represents business entities or administrations. All of them will be encoded on the RAA and HDA bits. </mglt> 4.1. Apex The Apex is a special DIME role that holds the values of RAA=0-3 and HDA=0. It serves as the branch point from the larger DNS system in which DETs are defined. The Apex is the owner of the IPv6 prefix portion of the DET associated with it (2001:30/28) which is assigned by IANA from the special IPv6 address space for ORCHIDs. <mglt> I think I am missing the text that explains briefly why we need to have an Apex. If that is the administrative contact of the prefix why do we need to assign a specific RAA/HDA code point. </mglt> Wiethuechter & Reid Expires 6 June 2024 [Page 6] Internet-Draft DETIM Architecture December 2023 The Apex manages all delegations and allocations of the DET's RAA to various parties. Allocations of RAAs SHOULD be done in contiguous groups of 4. +===================+=================+======================+ | RAA Decimal Range | RAA Hex Range | Status | +===================+=================+======================+ | 0 - 3 | 0x0000 - 0x0003 | Apex | +-------------------+-----------------+----------------------+ | 4 - 3999 | 0x0004 - 0x0F9F | ISO 3166-1 Countries | | | | (Section 4.2.1) | +-------------------+-----------------+----------------------+ | 4000 - 16375 | 0x1000 - 0x3FFF | Reserved | +-------------------+-----------------+----------------------+ | 16376 - 16383 | 0x3FF8 - 0x3FFF | DRIP WG Experimental | | | | Use | +-------------------+-----------------+----------------------+ Table 1 Note: that the first column of this table is _decimal_ values *not* _hexadecimal_. RAA values of 0 (0x0000) to 3 (0x0003) are reserved to the Apex exclusively. The Experimental range of 16376 (0x3FF8) to 16383 (0x3FFF), eight (8) RAAs, is allocated to the DRIP working group itself. 16376 to 16379 are setup by DRIP experts to act as RAAs for potential HDA users to test against. RAA 16376 is already "in use" with driptesting.org. The rest of the range (16377 to 16383) are reserved to be allocate by the DRIP experts to agencies that wish to test. <mglt> This should be in the IANA section so a reference to that section is probably better to avoid repeated and contradicting wording. The iANA section needs to have clear instructions on how to register (expert review) with parameters and procedure to follow. See RFC 8126 for more details. </mglt> 4.2. Registered Assigning Authority (RAA) RAA's are the upper hierarchy in DRIP (denoted by a 14-bit field, i.e. 16,384 RAAs, of an DET). An RAA is a business or organization that manages a DIME of HDAs (Section 4.3). Most are contemplated to be Civil Aviation Authorities (CAA), such as the Federal Aviation Authority (FAA), that then delegate HDAs to manage their National Air Space (NAS). This is does not preclude other entities to operate an RAA if the Apex allows it. Wiethuechter & Reid Expires 6 June 2024 [Page 7] Internet-Draft DETIM Architecture December 2023 An RAA must provide a set of services to allocate HDAs to organizations. It must have a public policy on what is necessary to obtain an HDA. It must maintain a DNS zone minimally for discovering HID RVS servers. All RAA's have a single reserved HDA value: 0 (0x0000) for itself to support various functions or services. Other HDA values can be allocated or reserved per RAA policy. <mglt> must is correct but I tend to think we should avoid saying must when we have no authority on it. </mglt> 4.2.1. ISO 3166-1 Numeric Nations (INN) The RAA range of 4 (0x0004) to 3999 (0x0F9F) are reserved for CAAs using the ISO 3166-1 Numeric Nation Code. The RAA can be derived from the ISO 3166-1 numeric code by multiplying the value by 4 (i.e. raa_code = iso_code * 4). Four contiguous values (raa_code + 0, raa_code + 1, raa_code + 2 and raa_code + 3) are used in a single allocation. The inverse (RAA to ISO) works out as: iso_code = floor(raa_code / 4). As an example the United States has an ISO 3166-1 Numeric Code of 840. This derives the following RAAs: 3360, 3361, 3362 and 3363. It should be noted that the range of codes from 900 to 999 are defined as "user assigned code elements" without specific claimant predefined in the RAA space. Withdrawn and other special codes also do not have predetermined claimants. <mglt> I am wondering if we wanted to allocate multiple RAA per country. If that is not the case and we are allocating 4 code points for convenience, we may reserve 2 bits. I know this has been discussed. I am expecting the term "user assigned code element". It is unclear to me what it means, but I suspect we do not want anyone but ISO to assign these code points. If that is the case, maybe that should be clearly stated. </mglt> How a CAA handles their 4 allocations are out of scope of this document. Control of these values are expected to be claimed by their respective owner. How a claim is vetted and validated is out of scope of this document. Protection against fraudulent claims of one of these values is out of scope for this document. Note: A single entity may control more than one NAS (for example LU and BE being covered by Skeyes.be) and would manage two allocation spaces. How this is claimed and handled is out of scope for this document. 4.3. Hierarchial HIT Domain Authority (HDA) An HDA may be an USS, ISP, or any third party that takes on the business to register the actual entities that need DETs. This includes, but is not limited to UA, GCS, UAS Operators and infrastructure (such as Supplemental Data Service Providers). It should also provide needed UAS services including those required for HIP-enabled devices (e.g. RVS). A primary function of HDAs for DRIP, in the context of UAS RID is the binding between a UAS Session ID (for DRIP the DET) and the UA Serial Number. The Serial Number MUST have its access protected to allow Wiethuechter & Reid Expires 6 June 2024 [Page 8] Internet-Draft DETIM Architecture December 2023 only authorized parties to obtain it. The Serial Number MUST be protected in a way only the authorized party can decrypt. As part of the UTM system HDAs can also hold a binding between a UAS ID (Serial Number or Session ID) and an Operational Intent. They may either be a direct logical part of a UAS Service Supplier (USS) or be a UTM wide service to USS's. The HDA is a 14-bit field (16,384 HDAs per RAA) of a DET assigned by an RAA. An HDA should maintain a set of RVS servers for UAS clients <mglt> is it should or MUST with the currently defined DRIP ? </mglt> that may use HIP. How this is done and scales to the potentially millions of customers are outside the scope of this document. This service should be discoverable through the DNS zone maintained by the HDA's RAA. An RAA may assign a block of values to an individual organization. This is completely up to the individual RAA's published policy for delegation. Such policy is out of scope. <mglt> out of scope of this document. </mglt> 5. DIME Architecture The DIME, in any of its roles (Section 4), is comprised of a number of logical components that are depicted in Figure 2. Any of these components could be delegated to other entities as a service both co- located or remote. For example: * The Name Server component could be handled by a well-established DNS registrar/registry with the DRIP Provisioning Agent (DPA) (Section 5.1) interfacing to them - Either the DPA or the Registry/Name Server interfaces to the DRIP Information Agent (DIA) * The DPA, Registry, and Name Server may all be co-located in one implementation with an interface to a DIA offered by another organization from any one of the co-located components Wiethuechter & Reid Expires 6 June 2024 [Page 9] Internet-Draft DETIM Architecture December 2023 +--------------------+ | Registering Client | +---------o----------+ | **********|****************************************************** * | DRIP Identity Management Entity (DIME) * * | * * +------o-------+ +-------------+ +--------------+ * * | DRIP | | | | | * * | Provisioning o------o | | | * * | Agent (DPA) | | | | | * * +-------o------+ | | | | * * | | | | | * * | | DRIP | | Registration | * * +-------o--+ | Information o------o Data | * * | Registry o----------o Agent (DIA) | | Directory | * * +-------o--+ | | | Service | * * | | | | (RDDS) | * * | | | | | * * +-------o----------+ | | | | * * | Name Server (NS) | | | | | * * +------o-----------+ +-----o-------+ +------o-------+ * * | | | * * | | | * **********|********************|*********************|*********** | | | | +-------o-------+ | '------------o Lookup Client o-------------' +---------------+ Figure 2: DIME Logical Components 5.1. DRIP Provisioning Agent (DPA) The DPA performs the important task of vetting information coming from clients wishing to register and then delegate (internally or externally) various items to other components in the DIME. A standard interface MUST be provided for clients to access. An HTTPS based interface is RECOMMENDED. This interface specification is out of scope for this document. <mglt> I am finding it quite strange to recommend HTTPS though we do not define the interface. I would remove such a recommendation. </mglt> There MUST be an interface from the DPA to a Registry (Section 5.2) component which handles the DNS specific requirements of the DIME as defined by the Registry. There MAY also be interface from the DPA to a DRIP Information Agent (Section 5.4) as defined by the DIA. Wiethuechter & Reid Expires 6 June 2024 [Page 10] Internet-Draft DETIM Architecture December 2023 +-------------+ | Registering | | Client | +------o------+ | | HTTPS | | +--o--+ +-----+ | DPA o-----------o DIA | +--o--+ TBD +-----+ | | | HTTPS or EPP | +------o---+ | Registry | +----------+ Figure 3: DPA Interface Mapping <mglt> The text does not mention EPP, it would be good to specify EPP as an example or typical protocol that can be used. I believe that HTTPS or EPP should be EPP over HTTPS. I do not see what information Figure 3 provides that is not mentioned in Figure 2 and so my preference would be to have a single Figure 2. I suggest removing Figure 3. </mglt> 5.2. Registry The Registry component handles all the required DNS based requirements of the DIME to function for DRIP. This includes the registration and maintenance of various DNS Resource Records. A standardized interface MUST be implemented for interactions with the DPA (Section 5.1). This interface MAY be over HTTPS using JSON/ CBOR encoding or MAY use the Extensional Provisioning Protocol (EPP) [RFC5730]. The detailed specification of either of these interfaces is out of scope for this document. <mglt> I am finding it hard to mandate something we do not specify. In addition, the DIME may use its own proprietary interfaces for its internal components. So I believe these interfaces should only be mentioned as examples. Maybe that would be useful to mention them in the Figure 2 and indicate these are provided as examples. This prevents having to define the interface at two places or picking one place and being told the information is missing at the other place. </mglt> There MAY be interface from the Registry to a DRIP Information Agent (Section 5.4) as defined by the DIA. Wiethuechter & Reid Expires 6 June 2024 [Page 11] Internet-Draft DETIM Architecture December 2023 +-----+ | DPA | +--o--+ | | HTTPS or EPP | | +------o---+ +-----+ | Registry o-----------o DIA | +-----o----+ TBD +-----+ | | | TBD | +---o--+ | NS | +------+ Figure 4: Registry Interface Mapping <mglt> I suggest removing figure 4. </mglt> 5.3. Name Server (NS) The interface of the Name Server to any component (nominally the Registry) in a DIME is out of scope as typically they are implementation specific. <mglt> I suggest replacing The interface of the Name Server to any component (nominally the Registry)." by "The interface of the Name Server to The Registry". </mglt> Author Note: This may be very important here as we should not preclude a USS from running his own Name Server but they are not DNS experts and will need guidance or at least pointers to it to not mess it up. Such as SOA and NS formats to allow delegation if acting as an RAA. <mglt> It seems to be beyond the scope of the architecture document. There is balance between the specific needs and DNS current practice. It also beleive that is reasonable to follow the BCP and that we do not need to go into such details. What seems to me more important is to specify what kind of information teh NS is hosting. </mglt> Wiethuechter & Reid Expires 6 June 2024 [Page 12] Internet-Draft DETIM Architecture December 2023 +----------+ | Registry | +-----o----+ | | | TBD | +---o--+ | NS | +--o---+ | | | DNS Query/Response | +----o----------+ | Lookup Client | +---------------+ Figure 5: Name Server Interface Mapping <mglt> Figure to be removed. </mglt> 5.4. DRIP Information Agent (DIA) The DIA is the main component handling requests for information from entities outside of the DIME. Typically this is when an Observer looks up a Session ID from an UA and gets pointed to the DIA to obtain information not available publicly (i.e. via DNS). The information contained in the DIA is generally more oriented around the Operator of a given UAS and is thus classified as Personally Identifiable Information (PII). To protect the privacy of an Operator of the UAS this information is not publicly accessible and is only available behind policy driven differentiated access mechanisms (see Section 7). <mglt> To protect .... has already been mentioned in the introduction and section 7. This is probably sufficient. </mglt> For DRIP, the Registration Data Access Protocol (RDAP) ([RFC7480], [RFC9082] and [RFC9083]) is the selected protocol to provide policy driven differentiated access for queries of information from clients. <mglt> We need to be more normative here. </mglt> There MUST be a standardized interface for the DPA or Registry to add, update or delete information into the DIA. Specific details for these interfaces are out of scope for this document. An interface defined by the Registration Data Directory Service (RDDS) (Section 5.5) is also required as specified by the RDDS. <mglt> The two paragraphs above do not provide significant information in my opinion, thus I would remove them. I believe that what information is expected from the Registry or DPA is missing and should be added. </mglt> Wiethuechter & Reid Expires 6 June 2024 [Page 13] Internet-Draft DETIM Architecture December 2023 +-----+ | DPA | +--o--+ | | | TBD | +----------+ TBD +--o--+ +------+ | Registry o-----------o DIA o-------------o RDDS | +----------+ +--o--+ TBD +------+ | | RDAP | | +-------o-------+ | Lookup Client | +---------------+ Figure 6: DIA Interface Mapping 5.5. Registration Data Directory Service (RDDS) This is the primary information database for the DIA. An interface MUST be provided to the DIA but its specification is out of scope for this document. +-----+ | DIA | +--o--+ | | | TBD | +---o--+ | RDDS | +--o---+ | | | RDAP | +----o----------+ | Lookup Client | +---------------+ Figure 7: RDDS Interface Mapping Wiethuechter & Reid Expires 6 June 2024 [Page 14] Internet-Draft DETIM Architecture December 2023 6. Registration/Provisioning Process The general process for a registering party is as follows: 1. Verify input Endorsement(s) from registering party 2. Check for collision of DET and HI 3. Populate Registry/Name Server with resource record(s) 4. Populate RDDS via DIA with PII and other info 5. Generate and return Endorsement(s) In the following subsections an abbreviated form of Section 5 using co-located components is used to describe the flow of information. The data elements being transmitted between entities is marked accordingly in each figure for the specific examples. Each section has an associated appendix (Appendix D) containing DNS examples. 6.1. Operator Provided either by USS or CAA run HDAs. <mglt> I suspect something is missing. </mglt> Regulation might require interaction between them. An Operator can request that certain information normally generated and provisioned into DNS be omitted due to privacy concerns. Wiethuechter & Reid Expires 6 June 2024 [Page 15] Internet-Draft DETIM Architecture December 2023 +----------+ | Operator | +--o---o---+ | ^ (a) | | (b) | | *******|***|***************************** * | | DIME:HDA * * | | * * v | +----------+ * * +--o---o--+ | | * * | DPA o--------->o | * * +----o----+ (d) | | * * | | | * * | (c) | DIA/RDDS | * * v | | * * +----o--------+ | | * * | Registry/NS | | | * * +-------------+ | | * * +----------+ * * * ***************************************** (a) Operator Information, Operator Self-Endorsement (b) Success Code, Generic Endorsement: HDA on Operator (c) HIP RR, DET RR, TLSA RR, URI RR, PTR RR (d) Operator Information Note: (c) MAY be requested by the Operator to be omitted due to PII concerns. Figure 8: Example DIME:HDA with Operator (DET) Registration The definition of Operator Information is out of scope of this document and left to local regulations (both in its format and contents). 6.2. Session ID Session IDs are generally handled by HDAs. In Figure 9 the UAS comprises of an unmanned aircraft and a Ground Control Station (GCS). Both parties are involved in the registration process. Wiethuechter & Reid Expires 6 June 2024 [Page 16] Internet-Draft DETIM Architecture December 2023 +---------+ | UAS | +--o---o--+ | ^ (a) | | (b) | | *******|***|***************************** * | | DIME: HDA * * | | * * v | +----------+ * * +--o---o--+ | | * * | DPA o--------->o | * * +----o----+ (d) | | * * | | | * * | (c) | DIA/RDDS | * * v | | * * +----o--------+ | | * * | Registry/NS | | | * * +-------------+ | | * * +----------+ * * * ***************************************** (a) Mutual Endorsement: HDA on GCS, Generic Endorsement: GCS on UA, Session ID Information (b) Success Code, Broadcast Endorsement: HDA on UA, Generic Endorsement: HDA on UAS (c) HIP RR, DET RR, TLSA RR, URI RR, PTR RR (d) Session ID Information Figure 9: Example DIME:HDA with Session ID (DET) Registration Through mechanisms not specified in this document the Operator should have methods (via the GCS) to instruct the unmanned aircraft onboard systems to generate a keypair, DET and Self-Endorsement: UA. The Self-Endorsement: UA is extracted by the Operator onto the GCS. The GCS is already pre-provisioned and registered to the DIME with its own keypair, DET, Self-Endorsement: GCS and Generic Endorsement: HDA on GCS. The GCS creates a new Generic Endorsement: GCS on UA and also creates Mutual Endorsement: HDA on GCS. These new endorsements along with Session ID Information are sent to the DIME via a secure channel. Wiethuechter & Reid Expires 6 June 2024 [Page 17] Internet-Draft DETIM Architecture December 2023 The GCS injects the Broadcast Endorsement: HDA on UA securely into the unmanned aircraft. Endorsement: HDA on GCS is securely stored by the GCS. Note: in Figure 9 the Session ID Information is expected to contain the Serial Number along with other PII specific information (such as UTM data) related to the Session ID. Session ID Information is defined as the current model: sessionid_info = { serial: tstr .size 20, session_id: tstr, operational_intent: tstr, intent_src: tstr, operator_id: tstr, session_context: tstr, * tstr: any } Future standards or implementations MAY add other keys to this list (for local features and/or local regulation). 6.2.1. UA Based Session ID There may be some unmanned aircraft that have their own Internet connectivity allowing them to register a Session ID themselves without outside help from other devices such as a GCS. When such a system is in use its imperative that the Operator has some method to create the Generic Endorsement: Operator on UA to send to the DIME. The process and methods to perform this are out of scope for this document but MUST be done in a secure fashion. <mglt> s/its/it is/ </mglt> 6.2.2. UAS Based Session ID Most unmanned aircraft will not have their own Internet connectivity but will have a connection to a GCS. Typically a GCS is an application on a user device (such as smartphone) that allow the user to fly their aircraft. For the Session ID registration the DIME MUST be provided with an Generic Endorsement: GCS on UA which implies there is some mechanism extracting and inserting information from the unmanned aircraft to the GCS. These methods MUST be secure but are out of scope for this document. With this system it is also possible to have the GCS generate the DET based Session ID and insert it securely into the unmanned aircraft after registration is done. This is NOT RECOMMENDED as this invalidates the objective of the asymmetric cryptography in the Wiethuechter & Reid Expires 6 June 2024 [Page 18] Internet-Draft DETIM Architecture December 2023 underlying DET as the private key MAY get in the possession of another entity other than the unmanned aircraft. See Section 12.2 for more details. 6.3. Child DIME Handled by the Apex and RAA's. This is an endpoint that handles dynamic registration (or key roll-over) of lower-level DIMEs (RAAs to Apex and HDAs to RAAs) in the hierarchy. +---------------+ | DIME: HDA | +--o---o--------+ | ^ (a) | | (b) | | *******|***|***************************** * | | DIME: RAA * * | | * * v | +----------+ * * +--o---o--+ | | * * | DPA o--------->o | * * +----o----+ (d) | | * * | | | * * | (c) | DIA/RDDS | * * v | | * * +----o--------+ | | * * | Registry/NS | | | * * +-------------+ | | * * +----------+ * * * ***************************************** (a) Self-Endorsement: HDA, HDA Information or Generic Endorsement: old HDA, new HDA (b) Success Code, Broadcast Endorsement: RAA on HDA (c) HIP RR, DET RR, TLSA RR, URI RR, PTR RR (d) HDA Information Figure 10: Example DIME:RAA with DIME:HDA Registration Wiethuechter & Reid Expires 6 June 2024 [Page 19] Internet-Draft DETIM Architecture December 2023 It should be noted that this endpoint DOES NOT hand out dynamically <mglt> DOES NOT does not seem to be a standard terminology. **does not** or __does not__ may be used instead if we really need it. That said, you can keep it as is and see if anyone raises an issue. </mglt> RAA/HDA values to systems that hit the endpoint. This is done out- of-band through processes specified by local regulations and performed by cognizant authorities. The endpoint MUST NOT accept queries it is not previously informed of being expected via mechanisms not defined in this document. It is OPTIONAL to implement this endpoint. This MAY be used to handle lower-level DIME key roll-over. 7. Differentiated Access Process Per [RFC9434] all information classified as public is stored in a datastore protected using some form of differentiated access (i.e. AAA) to satisfy REG-2 from [RFC9153]. Differentiated access, as a process, is a requirement for DIMEs as defined in [RFC9153] by the combination of PRIV-1, PRIV-3, PRIV-4, REG-2 and REG-4. [RFC9434] further elaborates on the concept by citing RDAP (from [RFC7480], [RFC9082] and [RFC9083]) as a potential means of fulfilling this requirement. Typically the cognizant authority is the primary querant of private information from a DIME if a Session ID is reported (the case of the owner of the private information is ignored for the moment). This capability MAY be delegated to other parties at the authorities discretion (be it to a single user or many), thus requiring a flexible system to delegate, determine and revoke querent access rights for information. XACML MAY be a good technology choice for this flexibility. It is noted by the authors that as this system scales the problem becomes a, well known and tricky, key management problem. While recommendations for key management are useful they are not necessarily in scope for this document as best common practices around key management should already be mandated and enforced by the cognizant authorities in their existing systems. This document instead focuses on finding a balance for generic wide-spread interoperability between DIMEs with authorities and their existing systems in a Differentiated Access Process (DAP). A system where cognizant authorities would require individual credentials to each HDA is not scalable, nor practical. Any change in policy would require the authority to interact with every single HDA (active or inactive) to grant or revoke access; this would be tedious and prone to mistakes. A single credential for a given authority is also strongly NOT RECOMMENDED due to the security concerns it would entail if it leaked. Wiethuechter & Reid Expires 6 June 2024 [Page 20] Internet-Draft DETIM Architecture December 2023 A zero-trust model would be the most appropriate for a DAP; being highly flexible and robust. Most authorities however use "oracle" based systems with specific user credentials and the oracle knowing the access rights for a given user. This would require the DAP the have some standard mechanism to locate and query a given oracle for information on the querent to determine if access is granted. DRIP has no intention to develop a new "art" of key management, instead hoping to leverage existing systems and be flexible enough to adapt as new ones become popular. 8. DRIP in the Domain Name System Per [RFC9434] all information classified as public is stored in the DNS to satisfy REG-1 from [RFC9153]. The apex for domain names MUST be under the administrative control of ICAO, the international treaty organization providing the critical coordination platform for civil aviation. <mglt> It would be usefull to spell out ICAO. It is probably not appropriated to be normative about ICAO (see below). </mglt> ICAO SHOULD be responsible for the operation of the DNS-related infrastructure for these domain name apexes. It MAY chose to run that infrastructure directly or outsource it to competent third parties or some combination of the two. ICAO SHOULD specify the technical and administrative criteria for the provision of these services: contractual terms (if any), reporting, uptime, SLAs (if any), DNS query handling capacity, response times incident handling, complaints, law enforcement interaction and so on. The delegation of civil aviation authorities to RAAs is already done per Section 4.2.1 using their ISO 3166-1 Numeric Codes. Since these are public, any entity can stand up an RAA with that value. ICAO SHOULD be the root of trust in a Endorsement or certificate chain that provides validation of any of these specific RAAs, in the ISO RAA range, thus protecting against bad actors standing up fraudulent RAAs. This also ensures DRIP complies with national law and regulation since these are matters of national sovereignty. Wiethuechter & Reid Expires 6 June 2024 [Page 21] Internet-Draft DETIM Architecture December 2023 Each national aviation authority SHOULD be responsible for the operation of the DNS-related infrastructure for their delegated subdomains. As with the domain apexes overseen by ICAO, each national aviation authority MAY chose to run that infrastructure directly or outsource it to competent third parties or some combination of the two. <mglt> s/to competent third parties or some combination of the two// </mglt> National aviation authorities SHOULD specify the technical and administrative criteria for the provision of these services: contractual terms (if any), reporting, uptime, SLAs (if any), DNS query handling capacity, response times, incident handling, complaints, law enforcement interaction and so on. These are National Matters where national law/regulation prevail. National policy and regulations will define how long DNS data are stored or archived. DNSSEC is strongly RECOMMENDED (especially for RAA-level and higher zones). <mglt> This is sufficient at the architectural level to simply recommend DNSSEC. So the text below is in my opinion to be removed. </mglt> When a DIME decides to use DNSSEC they SHOULD define a framework for cryptographic algorithms and key management [RFC6841]. This may be influenced by frequency of updates, size of the zone, and policies. 8.1. DRIP Entity Tags The REQUIRED mechanism is to place any information into ip6.arpa when using a DET. Since the DET is an IPv6 address it can be nibble- reversed and used in the zone, per standard conventions. <mglt> I suspect that it might be more exact to say DET has the format of an IPv6 address. It is probably better to indicate the exact reference and remove "per standard conventions". </mglt> The prefix 2001:30/28 is registered with IANA [RFC9374] and 3.0.0.1.0.0.2.ip6.arpa - the corresponding reverse domain - SHOULD be under the administrative control of the Apex. In addition to the DNS infrastructure for 3.0.0.1.0.0.2.ip6.arpa, the Apex SHOULD be responsible for the allocation of IPv6 addresses in this prefix. An addressing plan will need to be developed. <mglt> In my opinion, there is no normative recommendations to be provided here. This is a description of the architecture. </mglt> Distribution of HHIT (IPv6 address) blocks SHOULD be done using the 14-bit RAA space as a framework. The Apex SHOULD allocate blocks to each entity who can then assign them to HDAs in accordance with local law and policy. All HDAs MUST have an IPv6 address in 2001:30/28. A <mglt> I think it is more the HAD that will determine which blocks goes to which HDA. I propose a sentence around the following words: The Apex allocate blocks to each RAA. Each RAA will then assign subblocks to HDAs. </mglt> discrete zone SHOULD be delegated for each HDA. These MUST contain an DET resource record (Section 8.1.1) for itself. <mglt> I have the impression it would be clearer to explicitly indicate "These". </mglt> Reverse lookups of these IPv6 addresses will translate the address into a domain name in the manner defined in [RFC1886]. However, these lookups will query for, depending on what is required: HIP, DET, TLSA, URI, or PTR RRTypes. 8.1.1. DET Resource Record -- Daniel Migault Ericsson
- [Drip] draft-ietf-drip-registries-14 Daniel Migault