Re: [Tm-rid] Draft charter

Robert Moskowitz <rgm@labs.htt-consult.com> Thu, 10 October 2019 16:01 UTC

Return-Path: <rgm@labs.htt-consult.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 D6D991200C1 for <tm-rid@ietfa.amsl.com>; Thu, 10 Oct 2019 09:01:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 T_S0_rOwQrCi for <tm-rid@ietfa.amsl.com>; Thu, 10 Oct 2019 09:01:35 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 8085C12001A for <tm-rid@ietf.org>; Thu, 10 Oct 2019 09:01:35 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id D0A466211F; Thu, 10 Oct 2019 12:01:33 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 53IOnaZwTPvH; Thu, 10 Oct 2019 12:01:23 -0400 (EDT)
Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id EE2026211C; Thu, 10 Oct 2019 12:01:22 -0400 (EDT)
To: "Eric Vyncke (evyncke)" <evyncke@cisco.com>, "tm-rid@ietf.org" <tm-rid@ietf.org>
References: <0fc9d954-a9af-b590-afb2-64ad2594f552@labs.htt-consult.com> <d9b29364-c5ec-0391-6acf-10b15410855c@labs.htt-consult.com> <D9509822-DA8D-4622-BE7E-E1216DE75202@cisco.com>
From: Robert Moskowitz <rgm@labs.htt-consult.com>
Message-ID: <d0927f52-5d71-a095-d2b5-5e6ae7cbd04f@labs.htt-consult.com>
Date: Thu, 10 Oct 2019 12:01:17 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0
MIME-Version: 1.0
In-Reply-To: <D9509822-DA8D-4622-BE7E-E1216DE75202@cisco.com>
Content-Type: multipart/alternative; boundary="------------46CC8C955D12D10D81C62A62"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tm-rid/LSMOqY0g_Ox0XnBWVfzHXyz9xmw>
Subject: Re: [Tm-rid] Draft charter
X-BeenThere: tm-rid@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Trustworthy Multipurpose RemoteID <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: Thu, 10 Oct 2019 16:01:39 -0000

Eric,

In the area of privacy, there are conflicting issues.

In the USofA, NO civil UAV can have privacy of its Identity.  The FAA 
'owns' all airspace at 1' above the ground, if I have that right (and 
Stu will correct me).  Thus according to law, a person does not have any 
claim to privacy flying a UAV over their own property.

Think about it.  Just because it is on their property does not mean it 
is not interacting with others.

So no privacy of ID or basic associated information.

And to proper authorities more information.

This is not to say that the ID is forever.  Some use cases can justify 
an ID per flight/mission.  The delivery services (read UPS, FedEX) have 
already identified and justified the need of ID per mission.  But again, 
for that delivery, the fact that the UAV belongs to delivery service Q 
will be available.

NetworkID takes this farther.  It is not just the UAV in your VLOS 
(Visual Line of Sight), but also those that were there in the last 60s 
or MAY be there in the next 60s.  It could also, for authorized 
personnel, extend out further.

Now when we get to C2 (Command and Control), there are some privacy 
aspects, but again the operator of a UAV (why it is called UAS for 
system) has limited privacy.  To authorized personnel the operators 
location MUST be known.  There is a Self-ID broadcast message part of 
the basic BT messages, but it is informational only (like a Realtor 
saying which property s/he is videoing for a posting).

Bob

On 10/10/19 4:21 AM, Eric Vyncke (evyncke) wrote:
>
> Bob and others,
>
> During the BoF approval call with IESG & IAB, the TM-RID BoF has been 
> approved as a non-WG-forming BoF as the charter is not completely 
> mature (see below).
>
> It was also preferred to have TM-RID as a stand-alone WG: based on 
> experience, a dedicated/focus group is lighter and more efficient. So, 
> HIP is unchanged but all work done around HIP for TM-RID will end up 
> (like now) into HIP WG.
>
> The TM-RID charter will have to be discussed in the BoF meeting in 
> Singapore and must include a privacy statement/work item. The IAB/IESG 
> feedback was also that the current charter is too much on HIP and 
> would like to explore whether other technologies (including layer-2 
> ones) could be applicable.
>
> All the above does not prevent the current work on TM-RID related 
> drafts of course.
>
> So, let’s talk in Singapore at the BoF
>
> -éric
>
> *From: *Tm-rid <tm-rid-bounces@ietf.org> on behalf of Robert Moskowitz 
> <rgm@labs.htt-consult.com>
> *Date: *Friday, 4 October 2019 at 00:48
> *To: *"tm-rid@ietf.org" <tm-rid@ietf.org>
> *Subject: *Re: [Tm-rid] Draft charter
>
>
>
>
>
> Updated charter:
>
> Governmental agencies worldwide, including the United States Federal 
> Aviation Administration (FAA), are embarking on rule making processes 
> to define Remote Identification (RID) requirements for Unmanned 
> Aircraft Systems (UAS). ASTM International (formerly the American 
> Society for Testing and Materials) F38 Committee Work Item WK65041, 
> “Standard Specification for UAS Remote ID and Tracking”, addresses 
> such anticipated requirements. Broadcast RID defines a set of messages 
> for UAS to send one-way over Bluetooth or IEEE 802.11. Network RID 
> defines how the same information (and potentially more) can be made 
> available via the Internet. The ASTM draft does not address how to 
> ensure or at least assess trustworthiness of information communicated 
> via RID.
>
> The Host Identity Protocol (HIP) Host Identity Tag (HIT) is ideally 
> suited to work within this RID effort. For each Unmanned Aircraft 
> (UA), a HIT can consolidate the 4-tuple of (UA ID, UA physical 
> location, UA onboard host ID, UA onboard host logical location [IP 
> address list]) to a 3-tuple (HIT, UA physical location, UA onboard 
> host logical location) and thereby provide significant benefits.
>
> For HIP to be used effectively in this environment, it needs updates.
>
> - Hierarchical HITs (HHIT) enabling scalable and trustable 
> registration: HHIT was part of the original design of HIP, but was 
> dropped for lack of a clear use case. RID messages containing HHITs 
> will enable use of DNS to access information about the UAS.
>
> - expanded HIP Registration for HHITs: This registration process will 
> provide proof of authenticity and prevent duplicate HHITs from 
> occurring. Further, these Registries will provide the UAS DNS 
> information and other services (including support of RVS for Network 
> RID and related applications).
>
> - new cryptographic algorithms: Extremely compact keys and signatures 
> (such as are enabled by EdDSA and Keccak functions) are needed to meet 
> the severely constrained UAS environment.
>
> Additionally, tm-rid will offer specifications for HIP-augmented ASTM 
> RID messages. Initially this will consist of additional RID 
> Authentication Messages that use the HI in public key signing 
> operations: to prove UAS ownership of the HHIT; to authenticate other 
> claims made via RID, such as position and velocity, as having been 
> made by the owner of that HHIT; and to provide observers lacking 
> current Internet connectivity with locally verifiable UAS 
> proof-of-registration objects.
>
> Further work will emerge as experience is gained in using HIP for UAS 
> RID. For example, some UAS Traffic Management (UTM) systems envision 
> using OAuth for Ground Control Systems (GCS) and authorized safety 
> personnel. HIP as an OAuth method may help in merging HIP into these 
> systems.
>
> The goal is to complete these updates to HIP by the end of 2020.
>

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:rgm@labs.htt-consult.com

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit