Re: [Drip] New Version Notification for draft-ietf-drip-arch-07.txt(Internet mail)
"shuaiizhao(Shuai Zhao)" <shuaiizhao@tencent.com> Mon, 18 January 2021 07:10 UTC
Return-Path: <shuaiizhao@tencent.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 BB2D43A10E4 for <tm-rid@ietfa.amsl.com>; Sun, 17 Jan 2021 23:10:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tencent.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brhhbq3bPot7 for <tm-rid@ietfa.amsl.com>; Sun, 17 Jan 2021 23:10:28 -0800 (PST)
Received: from mail3.tencent.com (mail3.tencent.com [203.205.248.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27D983A10E3 for <tm-rid@ietf.org>; Sun, 17 Jan 2021 23:10:26 -0800 (PST)
Received: from EX-SZ021.tencent.com (unknown [10.28.6.73]) by mail3.tencent.com (Postfix) with ESMTP id 0C76194246; Mon, 18 Jan 2021 15:10:25 +0800 (CST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tencent.com; s=s202002; t=1610953825; bh=ex5qPsk8Aq8dt6d+hC5+VV8UORVlU1OseMD1LN9osj8=; h=From:To:Subject:Date:References:In-Reply-To; b=UWBj5h3MGM0H/8uLHexNU3e0RS9v5THSnmOiwWdBpvTruqslo29IEkjN1ZDaBV+1u zIwJKNpSX9D2QOIm6Ck2QPo9GqMKU99PL8aa22MbIytooNk95a9PRfZZxkNTC47gNe WZk8T5lMGlKcWd+KQaY0upY2niDS7tfRS9Ev97zA=
Received: from EX-US02.tencent.com (10.93.1.208) by EX-SZ021.tencent.com (10.28.6.73) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Mon, 18 Jan 2021 15:10:22 +0800
Received: from EX-US01.tencent.com (10.93.1.207) by EX-US02.tencent.com (10.93.1.208) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Mon, 18 Jan 2021 15:10:21 +0800
Received: from EX-US01.tencent.com ([fe80::dd89:24b4:594b:5bbe]) by EX-US01.tencent.com ([fe80::dd89:24b4:594b:5bbe%4]) with mapi id 15.01.2106.002; Mon, 18 Jan 2021 15:10:21 +0800
From: "shuaiizhao(Shuai Zhao)" <shuaiizhao@tencent.com>
To: Daniel Migault <mglt.ietf@gmail.com>, "tm-rid@ietf.org" <tm-rid@ietf.org>, Robert Moskowitz <rgm@labs.htt-consult.com>
Thread-Topic: [Drip] New Version Notification for draft-ietf-drip-arch-07.txt(Internet mail)
Thread-Index: AQHW3xkOFUUJ6joGKkmyHS7a5j04d6oXlkYAgBRxQwA=
Date: Mon, 18 Jan 2021 07:10:21 +0000
Message-ID: <C952FE67-BBB1-41FE-A76A-90258C1F13F9@tencent.com>
References: <160937949290.8187.14924925221817784025@ietfa.amsl.com> <A9AF86E0-565D-4A2A-B5ED-BD86AF7787F8@ieee.org> <CADZyTkn7b155d_pOtsONf9fxMywtLsWn3z4yi1u9TSacTMmTCg@mail.gmail.com>
In-Reply-To: <CADZyTkn7b155d_pOtsONf9fxMywtLsWn3z4yi1u9TSacTMmTCg@mail.gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.44.20121301
x-originating-ip: [9.19.161.93]
Content-Type: multipart/alternative; boundary="_000_C952FE67BBB141FEA76A90258C1F13F9tencentcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tm-rid/57txXrHy0pSJizb_zQA8AsNw5jE>
Subject: Re: [Drip] New Version Notification for draft-ietf-drip-arch-07.txt(Internet mail)
X-BeenThere: tm-rid@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 18 Jan 2021 07:10:37 -0000
Hi Daniel, Sorry for getting back to you late. You have made many great comments. Best comments I have seen so far. IMHO, It is better to address them in couple of revisions... So, for things I don’t have clear response yet, I put “NOTED” as a placeholder which will be addressed in future revisions. Meanwhile, hopefully co-author can weigh in their comments. Please see my reply inline. Let’s fix the small things first. I can then summary changes needed in future. Agree? Best, Shuai Zhao From: Tm-rid <tm-rid-bounces@ietf.org> on behalf of Daniel Migault <mglt.ietf@gmail.com> Date: Monday, January 4, 2021 at 15:00 To: shuai zhao <shuai.zhao@ieee.org> Cc: "tm-rid@ietf.org" <tm-rid@ietf.org> Subject: Re: [Drip] New Version Notification for draft-ietf-drip-arch-07.txt(Internet mail) Hi Shuai, Happy new year 2021!. I have shortly reviewed the current version. I believe the document is heading in the right direction, but I believe interactions between the elements ( in a DRIP context) could be described in a simpler and easiest way. The way I see an architecture document is mostly exposing which boxes are involved and which box talks to which box. This includes the purpose of the communication as well as the protocol being used. I think a high level description could well fit in the architecture overview. The complex part is that here there are at least two main use cases, and many boxes - some more active than the others. Currently we do have some additional description around RID, and the registries. I believe that is appropriated but I believe these sections could be clarified and simplified. I have included below some comments I had while reading the document - I hope this input will be helpful! Yours, Daniel Drone Remote Identification Protocol (DRIP) Architecture draft-ietf-drip-arch-07 [...] 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]. <mglt> It is unclear to me the reason, if there is any, to have "natural" being mentioned. I think the idea is to mention that there is the possibility that the UAS communicate directly to the provider using IP communications - which sounds natural. As L2 and L3 communications are happening at different layers, it also seems to me that saying "Internet and MAC-layer" might not clearly indicate there are two communications that are envisioned. So maybe that could be emphasized. I am not having a strong opinion on how to handle these comments. My main purpose is to avoid to have the reader being sent off track. I have the impression we could mention the UAS needs to enable different communications depending on its use case. I think that the purpose of the architecture description is not necessarily to match the requirements. It seems to me the document is mostly describing the entity involved. I think here, given that the requirement document has a huge description of the use cases, we can state we assume the reader is familiar with that document for the description of the use cases. The idea here would be to tell the reader "the architecture document may not be the one you should start with" maybe have a look at the requirements for the use cases. [Shuai] I agree Architecture should be made simple and easy to read, not involving lots of the technical details. I proposed to replace the first sentence to the following: This document describes an architecture for protocols and services to support Unmanned Aircraft System Remote Identification and tracking (UAS RID), plus RID-related communications, conforming to proposed regulations and external technical standards, satisfying the requirements listed in the companion requirements document {{-drip-requirements}}. </mglt> Many considerations (especially safety) dictate that UAS be remotely identifiable. Civil Aviation Authorities (CAAs) worldwide are mandating Unmanned Aircraft Systems (UAS) Remote Identification (RID). CAAs currently (2020) promulgate performance-based regulations that do not specify techniques, but rather cite industry consensus technical standards as acceptable means of compliance. [...] 1.2.1. Network RID A RID data dictionary and data flow for Network RID are defined in [F3411-19]. This data 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 <mglt> I believe that "this information" refers to the data. If so I am wondering if using the same terminology may be clearer. I also expect that the information refers to the data being processed, so eventually, we may clarify what this information is. [Shuai] indeed. In -08, I replace “this information” with “RID data information”. if there are requests for more detailed data description from further comments, we can then address it. </mglt> Network Remote ID Display Providers (Net-RID DP). It is the Net-RID DP that respond to queries from Network Remote ID clients (expected <mglt> I am wondering if the client are not here designated or represented on the figure as Observers. If so, we may clarify this. Note that I think keeping client is fine, but we may simply mention that in the context of the figure it is being represented as an Observer. [Shuai] I replaced “clients” with “observers”. Observers may be a client or others third parties. </mglt> 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: x x UA xxxxx ******************** | \ * ------*---+------------+ | \ * / * | NET_RID_SP | | \ * ------------/ +---*--+------------+ | RF \ */ | * | * INTERNET | * +------------+ | /* +---*--| NET_RID_DP | | / * +---*--+------------+ + / * | * 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 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. <mglt> If correct, it might be worth mentioning that the RF communication is not part of the RID architecture. [Shuai] I added an informative note for that matter. “Informative note: The RF link between UA and GCS is not in scope of the Network RID. “ </mglt> Card, et al. Expires 3 July 2021 [Page 4] Internet-Draft drip-arch December 2020 1.2.2. Broadcast RID 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. <mglt> Though I understand that Broadcast RID do not require Internet connectivity. I also have the impression that this interface will be always on - even if there is internet connectivity and a reliable communication to the display provider. The reason is - to me - that the display provider can only provide information that has been received from a service provider. I can imagine a UAS not providing its information to a SP and being in the range of other UAS. If such situation may happen, Broadcast is the backup communication and probably closer to what is happening on the ground. Of course a UAS not broadcasting is another case and needs to be "detected". I am wondering if that makes sense, and it should probably be detailed in the security consideration section. [Shuai] The FAA RID final rule is requiring broadcast RID all standard RID. So your comment about BRID should be always on is correct. I think the current text in this section may be sufficient to give a basic intro about what is a broadcast ID, and I did not see detect and avoid as one of the requirements for broadcast ID. If we would like to address this security concern, maybe we should add that to requirement draft? </mglt> The Broadcast RID is illustrated in Figure 2 below. 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 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.4. Overview of DRIP Architecture The requirements document [I-D.ietf-drip-reqs] 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. <mglt> There is always the question whether something should be repeated or referenced. I think it makes sense here to repeat. [shuai] Good, Thanks, </mglt> Card, et al. Expires 3 July 2021 [Page 6] Internet-Draft drip-arch December 2020 General x x Public Public xxxxx xxxxx Safety Observer x x Observer x x x x ---------+ +---------- x x x x | | x x | | UA1 x x | | +------------ x x UA2 xxxxx | | | xxxxx | + + + | | xxxxxxxxxx | | x x | +----------+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 1: the architecture may need more clarification, and address the following: * 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 presenting the gaps between the CAAs' Concepts of Operations and [F3411-19] as it relates to use of Internet technologies and UA direct RF communications. Issues include, but are not limited to: <mglt> To me the complex part is that DRIP defines an identifier, some frames to communicate that RID over L2 as well as session establishment protocols for internet connectivity, DNS update protocols,.... I tend to agree that one may have to point on each interface what the focus of the DRIP architecture is. But maybe there will be a more straight forward way to do. I think that this section should provide a high level description on how each element works between each other as well as their relation to DRIP. This section should also clarify: how the UAS interact with the various registries, USS. This includes the protocol being used as well as the expected provisioning and authentication. Does RID is even used between the UAS and USS ? how the observer observe the RID and proceed to the request to the various registries. Currently it seems to me the document is mostly describing RID and interactions with the registries. I think we need more to provide a comprehensive architecture document. If the represented DNS does not contain any DRIP information, and is only used for standard DNS resolution, then, it seems not necessary. [Shuai] Noted </mglt> Card, et al. Expires 3 July 2021 [Page 7] Internet-Draft drip-arch December 2020 * Mechanisms to leverage Domain Name System (DNS: [RFC1034]) and Extensible Provisioning Protocol (EPP [RFC5731]) technology to provide for private (Section 5.2) and public (Section 5.1) Information Registry. * Trustworthy Remote ID and trust in RID messages (Section 4) * Privacy in RID messages (PII protection) (Section 8) Editor's Note 2 : The following aspects are not covered in this draft, yet. We may consider add sections for each of them if necessary. * UA -> Ground communications including Broadcast RID * Broadcast RID 'harvesting' and secure forwarding into the UTM * Secure UAS -> Net-RID SP communications * Secure Observer -> Pilot communications [...] 3.3. Claims, Assertions, Attestations, and Certificates This section introduces the meaning of "Claims", "Assertions", "Attestations", and "Certificates" in the context of DRIP. This is due, in part, to the term "certificate" having significant technologic and legal baggage associated with it, specifically around X.509 certificates. These type of certificates and Public Key Infrastructure invokes more legal and public policy considerations than probably any other electronic communication sector. It emerged as a governmental platform for trusted identity management and was pursued in intergovernmental bodies with links into treaty instruments. As such the following terms are being used in DRIP. <mglt> I believe this section should mention the rats architecture document and align to its definitions. I have the impression we slightly differ from their definitions and would like as much as possible to avoid having our owned definitions. https://www.ietf.org/archive/id/draft-ietf-rats-architecture-08.html#name-artifacts [shuai] From what I can understood, the claims here gives more details what Claims/attestation/certificates means to DRIP. Not sure if align with rats is appropriate. </mglt> Claims: For DRIP claims are used in the form of a predicate (X is Y, X has property Y, and most importantly X owns Y). The basic form of a claim is an entity using a HHIT as an identifier in the DRIP UAS system. Assertions: Assertions, under DRIP, are defined as being a set of one or more claims. This definition is borrowed from JWT/CWT. An HHIT in of itself can be seen as a set of assertions. First that the Card, et al. Expires 3 July 2021 [Page 9] Internet-Draft drip-arch December 2020 identifier is a handle to an asymmetric keypair owned by the entity and that it also is part of the given registry (specified by the HID). Attestations: An attestation is a signed claim. The signee may be the claimant themselves or a third party. Under DRIP this is normally used when a set of entities asserts a relationship between them along with other information. Certificates: Certificates in DRIP have a narrow definition of being signed exclusively by a third party and are only over identities. 4. HHIT for UAS Remote ID This section describes the basic requirements of a DRIP UAS remote ID per regulation constrains from ASTM [F3411-19] and explains 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. UAS Remote Identifiers Problem Space A DRIP UAS ID needs to be "Trustworthy". This means that within the framework of the RID messages, an observer can establish that the RID used does uniquely belong to the UA. That the only way for any other UA to assert this RID would be to steal something from within the UA. <mglt> As in some cases I have the impression the RID is owned by the GCS. I have the impression UA should be the UAS. I would maybe avoid to have the sentence That the only way for other... but that is a personal suggestion, so please feel free to do what you believe is best to do. [Shuai] I think the sentence here is important “The RID is self-generated by the UAS (either UA or GCS)”, there is no requirement saying that which part of the UAS should generate or own the RID, at least I have not seen such requirement. </mglt> The RID is self-generated by the UAS (either UA or GCS) and registered with the USS. <mglt> I am wondering if that will be always the case, and if manufacturer or user will not at some point provision the UAS. It seems to me safer to consider his description assumes or consider the RID will be self generated. Having read further down I think the document contradict itself as both scenario are being envisioned. </mglt> Within the limitations of Broadcast RID, this is extremely challenging as: * An RID can at most be 20 characters. * 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. <mglt> It is unclear to me what is the relation between the first and second item and believe that it should be clarified. I have the impression that - if correct - the following may be clearer to the reader. The communication of the RID to be trustworthy needs to be associated with some authentication. The ASTM defines the Basic RID message that is expected to contained the RID and the Authentication message that is expected to contain the necessary authentication information. The Basic RID message has a maximum payload of 25 bytes and the maximum size allocated by ASTM for the RID is 20 bytes - as 3 bytes are left unused. The authentication maximum payload is defined to be 224 bytes. [Shuai] the following is proposed new text based on your comments: “The data communication of using Broadcast RID faces extreme challenging due to the limitation set by regulations. The ASTM [F3411-19] defines the Basic RID message which is expected to contained certain RID data and the authentication message. The Basic RID message has a maximum payload of 25 bytes and the maximum size allocated by ASTM for a RID is 20 bytes and only 3 bytes are left unused. Currently, the authentication maximum payload is defined to be 224 bytes.” </mglt> Standard approaches like X.509 and PKI will not fit these constraints, even using the new EdDSA [RFC8032] algorithm. <mglt> If the document mentions that X.509 is not possible, I believe that more details should be provided. I do not know the minimum X509 certificate but EdDSA keys are 32 (57) bytes, and signatures are 64 (114) bytes. This seems to long for the RID to use the key directly, but on the other hand public_key and signature could be 32+64 = 98 (57+114=171) bytes which could fit in 224. As there are also some other work on certificate for IoT, I would rather not say this is not possible and instead mention that HIT is an example that address this. To me, but I might be wrong, it seems that the main driver for HIT is that we could use the RID to establish session between the RID owner and some other parties. [Shuai] I am not an security expert for that matter. But I agree with your suggestions. We need to address this part in a bit more depth </mglt> An example of a technology that will fit within these limitations is an Card, et al. Expires 3 July 2021 [Page 10] Internet-Draft drip-arch December 2020 enhancement of the Host Identity Tag (HIT) of HIPv2 [RFC7401] introducing 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. <mglt> I think that only apply with Ed25519, that is 20 + 64 with a spacial relation between the RID and the public key. If so it might be worth specifying that the example considers a specific use case here Ed25519. I believe also that a short description of the HHIT may be clarifying. [Shuai] This is a good suggestion. I think we should add a bit more details about HHIT to address two of your comments about 1) why HHIT is a good fit and 2) why X.509 and others may not be an good option for RID. </mglt> 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 small credential cache in a disconnected environment. This third- party assertion is possible when the third-party also uses HHITs for its identity and the UA has the public key for that HHIT 4.2. HIT as A Trustworthy UAS 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. <mglt> I think the evidence is composed of 2 claims, the RID and the signature. The attestation seems to be the process of retrieving the public key and checking the key, rid and signature. That said I am not entirely sure I got it right either. [Shuai] Noted. </mglt> 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 (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. 4.3. HHIT for Remote ID Registration and Lookup 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 <mglt> It might be clearer here to replace key by input as to make sure the key mentioned has no cryptographic properties. [Shuai] agree. The following is the proposed text: “The ID itself needs to be the inquiry input into the lookup given the constraints imposed by some of the broadcast media. “ </mglt> imposed by some of the broadcast media. This can best be achieved by an ID registration hierarchy cryptographically embedded within the ID. Card, et al. Expires 3 July 2021 [Page 11] Internet-Draft drip-arch December 2020 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. <mglt> It is not so clear to me why CGA is mentioned here. I do not see this as necessary - unless I am missing something. [Shuai] that’s some old text. I think we can safely remove it. No need for more background here. I will remove it in -08 </mglt> 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]). <mglt> The paragraph above does not appear to me very clear. The term "registration hierarchy" may require some additional explanation. I have the impression that it lists the information that may be associated/registered to the RID. If that is correct, I believe this may be clearly stated. We may also clearly state what are the mandatory information, at least the public key and the nature of the RID - HHIT here. [Shuai] I agree Section 4 need more edits </mglt> A DRIP UAS ID SHOULD be a HHIT. <mglt> It seems to me that this is one assumption of this document. That said, I have the impression the DRIP itself is simply used as an input to retrieve some information so the nature of the RID - in our case that it is HHIT must be provided. It seems to me an information as important as the public key. </mglt> It SHOULD be self-generated by the UAS (either UA or GCS) <mglt> I believe that the RID is not itself self-generated, but instead the keys. I am not entirely convinced this is the right place for having the information. Typically, I am wondering how this would help impact the registration or lookup based on the RID. I think this is an important recommendation though. Maybe section 4.2 is more appropriated for such comment. [Shuai] Noted. More discussion need for section 4.2 and 4.3 </mglt> and MUST be registered with the Private Information Registry identified in its hierarchy fields. Each UAS ID HHIT MUST NOT be used more than once, with one exception as follows. <mglt> Maybe the Private Information Registry needs to be better defined. I might have missed it, but so far it seems that is the first time it has been introduced in the document. More specifically, I would expect that a clear distinction between what is private and public is made. [Shuai] we can add a bit more text to explain the difference between public and private registry in “Section 5. DRIP HHIT RID Registration and Registries” I also have the impression that the architecture should enable a HHIT to be updated for every flight, but I am not sure that is something that is necessarily mandatory. I think a MUST NOT statement is here a bit too strong. Probably such statement is more privacy consideration statement. Similarly to my previous statement, I have the impression that this consideration is a bit out of scope of the lookup section. I am wondering if having a HHIT for RID section ( without lookup, encryption,... ) should not be part of section 4.2. [Shuai] Noted </mglt> Each UA MAY be assigned, by its manufacturer, a single HI and derived HHIT encoded as a hardware serial number per [CTA2063A]. Such a static HHIT SHOULD be used only to bind one-time use UAS IDs (other HHITs) to the unique UA. <mglt> It seems this section can be simplified. It seems the text exposes how a UA provisioned with one "static* or long term key can generate ephemeral RIDs. I do not find necessary to introduce HI for a long term private key. In addition, HHIT derived from that key do not seem to be the RID an observer can observe, as only one-time RIDs are used. As a result, it seems confusing to me to use HHIT for long term secrets. I am wondering if the text is willing to say that ephemeral HHIT (not based on the long term public key) are redirected to the long term RID or if any salt mechanism is used to enable to generate multiple HHIT from one public key. I think the mechanism should be further described, but it seems to me that this is a mechanisms that could also be reserved to the privacy consideration section. In fact it may not deeply affect the architecture itself as opposed to use the architecture in place to provide privacy. [shuai] Noted </mglt> Depending upon implementation, this may leave a HI private key in the possession of the manufacturer (see Security Considerations). Each UA equipped for Broadcast RID MUST be provisioned not only with its HHIT but also with the HI public key from which the HHIT was derived and the corresponding private key, to enable message signature. Each UAS equipped for Network RID MUST be provisioned likewise; the private key SHOULD reside only in the ultimate source of Network RID messages (i.e. on the UA itself if the GCS is merely relaying rather than sourcing Network RID messages). Each observer device MUST be provisioned with public keys of the UAS RID root registries and MAY be provisioned with public keys or certificates for subordinate registries. Operators and Private Information Registries MUST possess and other UTM entities MAY possess UAS ID style HHITs. When present, such HHITs SHOULD be used with HIP to strongly mutually authenticate and optionally encrypt communications. Card, et al. Expires 3 July 2021 [Page 12] Internet-Draft drip-arch December 2020 4.4. HHIT for Remote ID Encryption 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). <mglt> I am not convinced this section is needed. [Shuai] do you think the content here is repeated? Do you strongly propose to remove it? </mglt> 5. DRIP HHIT RID Registration and Registries The DRIP HHIT RID registration goes beyond what is currently envisioned in UTM for the UAS to USS registration/subscription process. UAS registries hold both public and private UAS information resulting from the UAS RID registration. Given these different uses, and to improve scalability, security and simplicity of administration, the public and private information can be stored in different registries, indeed different types of registry. 5.1. Public Information Registry [...] 5.1.2. Proposed Approach A DRIP public information registry MUST respond to standard DNS <mglt> It does not look to me appropriated to use MUST. The architecture defines public information being host in DNS seems to me sufficient. It might be worth specifying if DNSSEC is expected to be supported or not. I do not also believe that having a proposed approach is appropriated. It suggests that the DRIP architecture has other alternatives. I would simply describe what the DRIP architecture considers. </mglt> [Shuai] does “MAY” sound appropriate? Or is it too loose… queries, 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. <mglt> It seems this goes a bit too far into the specification. I do not see listing the RRtypes being supported as necessary to be mentioned in an architecture document. I also question the relation to DRIP of NS or MX RRtypes. [Shuai] should we just simply say the DRIP public information registry SHOULD support the HHIT DNS types, without specifying the details? </mglt> 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]. These public information registries SHOULD use secure DNS transport (e.g. DNS over TLS) to deliver public information that is not inherently trustable (e.g. everything other than attestations). <mglt> If DNS over TLS is used, this also means that the DNS infrastructure - resolvers cannot be used. I potentially this this causing some issues when no connectivity is provided. I suspect that DNSSEC may be more appropriated to re-use the DNS architecture and ease adaptation to off line use cases. [Shuai] I think we can relax the language from “should” to “may”. Agreeable? </mglt> 5.2. Private Information Registry 5.2.1. Background The private information required for DRIP RID is similar to that required for Internet domain name registration. This information SHOULD be available for ALL UAS, including those that only use Network RID. <mglt> I think it might worth clarifying how an information accessible to ALL UAS is private. [shuai] Noted </mglt> A DRIP RID solution can leverage existing Internet resources: registration protocols, infrastructure and business models, by fitting into an ID structure compatible with DNS names. This implies some sort of hierarchy, for scalability, and management of this hierarchy. It is expected that the private registry function will be provided by the same organizations that run USS, and likely integrated with USS. 5.2.2. Proposed Approach A DRIP RID MUST be amenable to handling as an Internet domain name (at an arbitrary level in the hierarchy), MUST be registered in at least a pseudo-domain (e.g. .ip6.arpa for reverse lookup), and MAY be registered as a sub-domain (for forward lookup). This DNS information MAY be protected with DNSSEC. Its access SHOULD be protected with a secure DNS transport (e.g. DNS over TLS). <mglt> It may not be very clear to me if private informations are expected to be hosted. If so, TLS might be mandatory and we me also clarify how this information is expected to remained cached in resolvers for example. [shuai] Noted </mglt> Card, et al. Expires 3 July 2021 [Page 14] Internet-Draft drip-arch December 2020 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. <mglt> I am not convinced that specifying the format for access rules are necessary here, nor EPP. It is unclear to me at that stage if the registry is a DNS server or something else. I have the impression the text should express better the function of the Public and Private registries. [shuai] Noted </mglt> The DRIP private information registry in which a given UAS is registered MUST be findable, starting from the UAS ID, using the methods specified in [RFC7484]. A DRIP private information registry MAY support WebFinger as specified in [RFC7033]. [...] 8. Privacy for Broadcast PII Broadcast RID messages may contain PII. This may be information about the UA such as its destination or Operator information such as GCS location. There is no absolute "right" in hiding PII, as there will be times (e.g., disasters) and places (buffer zones around airports and sensitive facilities) where policy may mandate all information be sent as cleartext. <mglt> I do not believe cleartext is recommendable in any way as it is subject to spoofing. The minimum must be authenticated-only. [shuai] I think it is reasonable to remove the first sentence. </mglt> Otherwise, the modern general position (consistent with, e.g., the EU General Data Protection Regulation) is to hide PII unless otherwise instructed. While some have argued that a system like that of automobile registration plates should suffice for UAS, others have argued persuasively that each generation of new identifiers should take advantage of advancing technology to protect privacy, to the extent compatible with the transparency needed to protect safety. Card, et al. Expires 3 July 2021 [Page 17] Internet-Draft drip-arch December 2020 A viable architecture for PII protection would be symmetric encryption of the PII using a key known to the UAS and its USS. An authorized Observer may send the encrypted PII along with the Remote ID (to their UTM Service Provider) to get the plaintext. Alternatively, the authorized Observer may receive the key to directly decrypt all future PII content from the UA. <mglt> I do have serious doubts this is viable, but maybe I am missing the way it works. Currently, it seems to me that an Observer will get the key(s) used for the encryption the communication between the UAS and its USS, so it can decrypt the communication. If my understanding is correct, I am wondering how one can prevent the observer to inject traffic to the USS on the behalf of the UA. [Shuai] Noted </mglt> On Wed, Dec 30, 2020 at 9:02 PM shuai zhao <shuai.zhao@ieee.org<mailto:shuai.zhao@ieee.org>> wrote: Dear DRIP, We have just uploaded a new revision for DRIP architecture, which has a lots of good update: · Added section 3.3 to explain what claims, assertion, attestations, and certification means in DRIP · New section 4.1, which is old section 6, for a clean text organization · Move crowd-sourced concept to a separated sec 6 · Lots of other details update across the draft. For those of you who know the recent FAA final rules about RID, we will be addressing the necessary changes in the next revision. Wish you all have a happy new year! See you in 2021... -BR, Shuai On Dec 30, 2020, at 17:51, internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> wrote: A new version of I-D, draft-ietf-drip-arch-07.txt has been successfully submitted by Shuai Zhao and posted to the IETF repository. Name: draft-ietf-drip-arch Revision: 07 Title: Drone Remote Identification Protocol (DRIP) Architecture Document date: 2020-12-30 Group: drip Pages: 24 URL: https://www.ietf.org/archive/id/draft-ietf-drip-arch-07.txt Status: https://datatracker.ietf.org/doc/draft-ietf-drip-arch/ Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-drip-arch Htmlized: https://tools.ietf.org/html/draft-ietf-drip-arch-07 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-drip-arch-07 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. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>. The IETF Secretariat -- Tm-rid mailing list Tm-rid@ietf.org<mailto:Tm-rid@ietf.org> https://www.ietf.org/mailman/listinfo/tm-rid -- Daniel Migault Ericsson
- Re: [Drip] New Version Notification for draft-iet… shuai zhao
- Re: [Drip] New Version Notification for draft-iet… Daniel Migault
- Re: [Drip] New Version Notification for draft-iet… shuaiizhao(Shuai Zhao)
- Re: [Drip] New Version Notification for draft-iet… Daniel Migault
- Re: [Drip] New Version Notification for draft-iet… shuaiizhao(Shuai Zhao)
- Re: [Drip] New Version Notification for draft-iet… Eric Vyncke (evyncke)
- Re: [Drip] New Version Notification for draft-iet… shuai zhao