From nobody Mon Aug 3 01:39:36 2020 Return-Path: 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 0ABFA3A0C79; Mon, 3 Aug 2020 01:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 6Hr6owAF2P0U; Mon, 3 Aug 2020 01:39:32 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 804FF3A0C7D; Mon, 3 Aug 2020 01:39:32 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 4BKrsb1knhzBtc2; Mon, 3 Aug 2020 10:39:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1596443971; bh=AIxtmz9pdUEQtrJfnOQQj7WufZsF+biwfcowveZjMQI=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=qg13ezT3D3w+xwR4GhdsFTiNZ6PDLrVB3oAu09IYbMR+PepGgiLI/1m5TjAZ0NDO0 A3oj3bDhKsykF9t3O7F6eTD/tEATdOorWaH8UhSYdKj/Z84DK8AyMXTVuaZif6LcNv 2R7chBlxje+CjJrSrodwkOwTC5Yy17Rj8PZ6PnocuuD50MAZ1H4VldzugFfb3ZMdop FTmn0jKdQbLrG50VYO++bU20LhZsuCDRhWIS1fFJPqBF5XTbUAiYqpewMx+SBo11kB XMixQmgpbNHBIlsyd1S42cOTSrseIRhSTFLj8hJXC/KUBBzzg9PTVQ5J1mBTxSPX1e MKi1cbe0UsCWQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.82]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 4BKrsb0rthzCqkY; Mon, 3 Aug 2020 10:39:31 +0200 (CEST) From: To: "tm-rid@ietf.org" CC: "drip-chairs@ietf.org" Thread-Topic: IETF108: Minutes Thread-Index: AdZpcW29lNcZYa38Rz6d3cPxahaUeg== Date: Mon, 3 Aug 2020 08:39:30 +0000 Message-ID: <1098_1596443971_5F27CD43_1098_246_1_787AE7BB302AE849A7480A190F8B93303150C662@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93303150C662OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: [Drip] IETF108: Minutes X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 08:39:34 -0000 --_000_787AE7BB302AE849A7480A190F8B93303150C662OPEXCAUBMA2corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, The minutes are available at: https://www.ietf.org/proceedings/108/minutes/= minutes-108-drip-01. If you have modifications, please send them to drip-chairs@ietf.org within the next 7 days Many thanks to Shuai for taking the notes. Cheers, Daniel & Med ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_787AE7BB302AE849A7480A190F8B93303150C662OPEXCAUBMA2corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

The minutes are available at: https://www.ietf.org/proceedings/108/minutes/minutes-108-drip-01.

 

If you have modifications, please send them to drip-chairs@ietf.org within the= next 7 days

 

Many thanks to Shuai for taking the notes.

 

Cheers,

Daniel & Med

 

 

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_787AE7BB302AE849A7480A190F8B93303150C662OPEXCAUBMA2corp_-- From nobody Tue Aug 4 06:44:11 2020 Return-Path: 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 F3DC23A0B75 for ; Tue, 4 Aug 2020 06:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.62 X-Spam-Level: * X-Spam-Status: No, score=1.62 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.949, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 y4FPhwq225JJ for ; Tue, 4 Aug 2020 06:44:08 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 777B33A0A5F for ; Tue, 4 Aug 2020 06:44:08 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 074Di644018806 for ; Tue, 4 Aug 2020 15:44:06 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C5FC5203C00 for ; Tue, 4 Aug 2020 15:44:06 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id BB3072015AA for ; Tue, 4 Aug 2020 15:44:06 +0200 (CEST) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 074Di6GQ017504 for ; Tue, 4 Aug 2020 15:44:06 +0200 To: tm-rid@ietf.org References: <1bebf5b1-1fa5-6902-5bb7-9ec3582e6d9a@andersdotter.cc> <2990FBF0-FCB0-49CE-8F4B-BF5111CE5D57@tzi.org> <01a21161-aa8d-6d4b-b384-3129fe6d799b@gmail.com> <973223fd-0119-376d-12cd-21559a14ce87@labs.htt-consult.com> <3c632ce9-115d-11f5-ee33-bfabd4973522@labs.htt-consult.com> <7ddd9a2f-23ba-dd82-8cfb-1d2974969e67@gmail.com> From: Alexandre Petrescu Message-ID: <989f5780-dbba-db03-3271-abd29158745e@gmail.com> Date: Tue, 4 Aug 2020 15:44:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Drip] ADSB X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 13:44:10 -0000 Le 30/07/2020 à 04:45, Stuart W. Card a écrit : > Sorry for the slow reply. > > ADS-B is gradually being mandated for essentially all manned > aircraft. > > ADSB-In and ADSB-Out are mandated for airliners: -In gives their > pilots some Situational Awareness (SA) of other aircraft; -Out gives > other pilots SA of the airliners. > > "ADSB-Out" is mandated even for small general aviation aircraft: it > does not directly benefit the pilots of those aircraft; but by > providing SA to others, it indirectly benefits all. > > ADSB is _not_ going to be deployed on large numbers of small UAS as > it would overwhelm the limited bandwidth available at those lower > radio frequencies (which propagate long ranges). Thanks for the clarification of what is ADSB-In and -Out. It makes think that ADSB-Out might be a good candidate link layer technology, on which one might put IP Router Advertisements. About the risk of overwhelming a bandwidth: true, drones are smaller than planes, and as such they might be much more numerous in a same given volume and so, intuititvely, they might be too many and so create a bottleneck. However, that might happen at a layer below IP (PHY or MAC), that is not an IETF layer. At the IETF layers there are some mechanisms to allow for avoiding of these bottlenecks. There are many computers on the Internet overall and they dont interfere with each other. Drones could also be part of it if IETF layers were used. > In fact, it is expected to be explicitly prohibited in the US per > the FAA NPRM; I suspect most of the rest of the world will do > likewise. > > ADSB is also altogether insecure. Noted the insecurity of ADS-B. And noted the potential prohibition of ADS-B in drones, by FAA NPRM and potentially others. Alex > > On 7/9/2020 3:02 AM, Alexandre Petrescu wrote: >> ... They call it "ADS-B Receivers" (Automatic Dependent >> Surveillance - Broadcast). >> >> I wouuld like to ask if there is a packet dump available showing >> such presence data form planes? Maybe wireshark already supports >> it, maybe it even dissects it... > > From nobody Tue Aug 4 06:53:00 2020 Return-Path: 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 8960A3A07E8 for ; Tue, 4 Aug 2020 06:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.278 X-Spam-Level: X-Spam-Status: No, score=-0.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.949, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 6s9nw3GIuKUl for ; Tue, 4 Aug 2020 06:52:58 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 1EA5E3A07E7 for ; Tue, 4 Aug 2020 06:52:57 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 074DquBl012376 for ; Tue, 4 Aug 2020 15:52:56 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 172F6203C23 for ; Tue, 4 Aug 2020 15:52:56 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0DA39201BD3 for ; Tue, 4 Aug 2020 15:52:56 +0200 (CEST) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 074Dqtp5021353 for ; Tue, 4 Aug 2020 15:52:56 +0200 To: tm-rid@ietf.org References: <1bebf5b1-1fa5-6902-5bb7-9ec3582e6d9a@andersdotter.cc> <2990FBF0-FCB0-49CE-8F4B-BF5111CE5D57@tzi.org> <01a21161-aa8d-6d4b-b384-3129fe6d799b@gmail.com> <973223fd-0119-376d-12cd-21559a14ce87@labs.htt-consult.com> <3c632ce9-115d-11f5-ee33-bfabd4973522@labs.htt-consult.com> <7ddd9a2f-23ba-dd82-8cfb-1d2974969e67@gmail.com> From: Alexandre Petrescu Message-ID: Date: Tue, 4 Aug 2020 15:52:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Drip] ADSB X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 13:53:00 -0000 architectural layers discussion... Le 30/07/2020 à 11:49, shuaiizhao(Shuai Zhao) a écrit : > Just to echo Stu on the ADSB, AFAIK, ADSB will not be feasible for > most of the drones mostly due to SwaP, commercial drones might be > exception. It might be that ADS-B might be forbidden in drones on Earth, but how about the drones on Mars? ('NASA Mars helicopters', or ESA too). On Mars there would be much less such drones, so less risk of interference. With such a system (ADS-B under IP) one could re-use DTN (Delay Tolerant Networking) between planets, and so identify drones even on Mars. But if we have reluctance about the use of ADS-B, and thus of IP, and we recommend Bluetooth-without-IP to identify drones, then we might become too dependent on it? (do not get me wrong, I do like Bluetooth, but I like many other things together with Bluetooth). Alex > > Best, > > Shuai Zhao > > *From: *Tm-rid on behalf of "Stuart W. > Card" *Date: *Wednesday, July 29, 2020 at > 19:46 *To: *"tm-rid@ietf.org" *Subject: *[Drip] > ADSB (was: Review of draft-drip-arch-02 w.r.t. RFC6973, RFC8280 and > other)(Internet mail) > > Sorry for the slow reply. > > ADS-B is gradually being mandated for essentially all manned > aircraft. > > ADSB-In and ADSB-Out are mandated for airliners: -In gives their > pilots > > some Situational Awareness (SA) of other aircraft; -Out gives other > > pilots SA of the airliners. > > "ADSB-Out" is mandated even for small general aviation aircraft: it > does > > not directly benefit the pilots of those aircraft; but by providing > SA > > to others, it indirectly benefits all. > > ADSB is _not_ going to be deployed on large numbers of small UAS as > it > > would overwhelm the limited bandwidth available at those lower radio > > frequencies (which propagate long ranges). In fact, it is expected to > be > > explicitly prohibited in the US per the FAA NPRM; I suspect most of > the > > rest of the world will do likewise. > > ADSB is also altogether insecure. > > On 7/9/2020 3:02 AM, Alexandre Petrescu wrote: > > ... > > They call it "ADS-B Receivers" (Automatic Dependent Surveillance - > > Broadcast). > > I wouuld like to ask if there is a packet dump available showing > such > > presence data form planes? Maybe wireshark already supports it, > maybe > > it even dissects it... > > -- > > ----------------------------------------- > > Stuart W. Card, PhD, Principal Engineer > > AX Enterprize, LLC www.axenterprize.com > > 4947 Commercial Drive, Yorkville NY 13495 > > From nobody Tue Aug 4 08:16:42 2020 Return-Path: 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 D37623A07C8 for ; Tue, 4 Aug 2020 08:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-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=steweorg.onmicrosoft.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 vZ-JlbMBpOIK for ; Tue, 4 Aug 2020 08:16:39 -0700 (PDT) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2112.outbound.protection.outlook.com [40.107.244.112]) (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 EBB0E3A07C5 for ; Tue, 4 Aug 2020 08:16:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XJXq//4rHJM1PaWEkfx61N2ei22/56gJVBH+lqixOF4p6XSmNM+1M4CYmlfLHjNKEWY535AMGa4LU1QbF6/8hYmuPPza84zkXEQ1+51oN6APFPjValnXkz7PEUWwe7Wi9nlDTAmSg8pLbLsw+bH5++Fdn2DV6yKvjEIDF4yIkapE7QOZ8YSe+Hd9p9YIQOE2PtWR74rx8szcaYVrAfAjFYQWIEElf+xtmCaQdW2loTtoGd0gHXTVXBXElYVOcA7A2OwmjOtkAYsKsivau0gUeg+feB65tkIDOwbWGQdRbcb49a6/X49IadigmiLRg0kS82CEmslce56JPaBod3rcEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q/yTRA1aEfZbULztkz4dCW1hSqALKE+oN0f7ypMAiJE=; b=aFHs+SHNrDkkoMlE5G3H83FOGEaE3Dy4ZuTk8WGAw2XvjrUsQJE2gWaHq30XluaybwWsKwSFlLCsAfL6L+n1+fLzPt5IgKYXwGOPgzat4b2XccXfAiTj2VzaWhVGOZjFzacw5oxW6c7wtKRMH/RmfEzza0UqZTblt+gf+8WAcsdieHdJbB1wPjbpB5mNwhsXWZaeorSYPeXk1IUKx5KTFdBomIpxS8/EH+P/c2MiTeiBt2QkfZs26sGOjNMgxjqsRgcSOVFoXdBr1TbxZQogBCkPQ2HCkOCuwdcgG/IFIVKoVgq1kC8o84BcNsO6dQ0G6N+krzfSvyPtB1V+H+toZg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=stewe.org; dmarc=pass action=none header.from=stewe.org; dkim=pass header.d=stewe.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=steweorg.onmicrosoft.com; s=selector2-steweorg-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q/yTRA1aEfZbULztkz4dCW1hSqALKE+oN0f7ypMAiJE=; b=ahQwS/JJGwOD0a4CE+pPqdnIYBlcLmqkcKOnZ4aXgP63ICJ+SRWcglZJ16RuMhtAVpZp2wv07DNNeXFmvVXgJanZ8ebbP2w+ALu+fP0nZvCAF1BHqNWBgWLBo5pWcSC18jFWiDA0f2WDVqOdPiTnljySmlbaSeisASwSNHTD+z0= Received: from DM6PR17MB3036.namprd17.prod.outlook.com (2603:10b6:5:12e::14) by DM6PR17MB2825.namprd17.prod.outlook.com (2603:10b6:5:12a::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.15; Tue, 4 Aug 2020 15:16:36 +0000 Received: from DM6PR17MB3036.namprd17.prod.outlook.com ([fe80::88a:598:450b:a4c4]) by DM6PR17MB3036.namprd17.prod.outlook.com ([fe80::88a:598:450b:a4c4%5]) with mapi id 15.20.3239.022; Tue, 4 Aug 2020 15:16:36 +0000 From: Stephan Wenger To: Alexandre Petrescu , "tm-rid@ietf.org" Thread-Topic: [Drip] ADSB Thread-Index: AQHWamaTKX8D7WRcqU6X/URQrOkY7KknmlWA Date: Tue, 4 Aug 2020 15:16:36 +0000 Message-ID: References: <1bebf5b1-1fa5-6902-5bb7-9ec3582e6d9a@andersdotter.cc> <2990FBF0-FCB0-49CE-8F4B-BF5111CE5D57@tzi.org> <01a21161-aa8d-6d4b-b384-3129fe6d799b@gmail.com> <973223fd-0119-376d-12cd-21559a14ce87@labs.htt-consult.com> <3c632ce9-115d-11f5-ee33-bfabd4973522@labs.htt-consult.com> <7ddd9a2f-23ba-dd82-8cfb-1d2974969e67@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.39.20071300 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=stewe.org; x-originating-ip: [2601:640:8300:f930:51f8:3264:b727:8d95] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d3857e18-e91f-4cf0-2d23-08d838896109 x-ms-traffictypediagnostic: DM6PR17MB2825: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: IPC2l1acLp8jxisxwWQ7NKOBNO2+5jgrjLdzA0SaPAfxN5BauAEj3GIgUHbfxYlbTIacP86JVMYTazpmcpoX2mN/g4d44/KWClQVfPYl91xvFa6GW3wcwhqiRpahyVm5zTlYMsLCENFWbhvdr0EMBFq7jTYYyhMASrj9as5MwngNSH/Onta4kon1S4HkuGeJpFIHgHJ4DAPG1QtqlpKl+8Kfsscc6n+emZpILu3+ojfFL7TKRKW7Hz6QYW1ONOtbxFAoRSagxG0x6OW1r7kFPf7KFJaJj1WU/UXQo5hZXxfbhKkF+zWZs/jorzRZnu2vY4EaOXto664twzzQxNZGI+z5w7ArB788M8CT8qazES2+0n9TQxuA1wWLLuj7rU0sc0QfG5REhN6PJHzVfo5MaA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR17MB3036.namprd17.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(366004)(136003)(396003)(39830400003)(376002)(346002)(966005)(316002)(2616005)(110136005)(6512007)(5660300002)(15974865002)(2906002)(508600001)(66446008)(6486002)(66574015)(86362001)(6506007)(53546011)(36756003)(33656002)(8936002)(66946007)(186003)(66476007)(66556008)(76116006)(91956017)(71200400001)(64756008)(83380400001)(8676002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: MTWMwfokPDZ79Gj/CQMD4gxxnMH8PDzC9MZeXGXKMbZq3dMve81KV2+UWmVRdw2tMacmgYjF/zsl5QkANYV9y2ahymdvr8KOZpcK7SOCHy7rZz2aznqkl4rR0MTk8zGRYdKAHhCaRd1boyIUL5j6duvJBR07o8ZxRkJj4OlB/SCA4x73Ve3loKxe/xHmIkyo7I4fpmz5R5rlLHpCmE8goK/So4FzB1AosNodnFFFlW1UAW5LER/rnxWz6711cDy4N4ZZCzVT/baQDBBPFO+hvoQKKF4n74iOolpkSgDen4X1navIk8uumsihcVIoU9JWOJBoByz0yjAR1p6UlCQEsRho17UvQ4i7t8w+sZZ0InFH5ADSU0xH4x2ce+/LyjaaThMJMK+cy2OY25e7qljcpiTuGYX+a9RfkW6/qai8ZV5Uaei0dAFvk7x4JqqWCFH8nAmw8mOZju2bOaUawlzVSkehMXiOaqzVMUxTq4+h6ir37qombK9kZp8YOZ5syS0uUo2rs4d7Rs4AJpKtEWCN6gUwVs+7eHGXUDeEsgOuA6GwrES680NIeakqCv1PEt7jFiipV+GlqsEQYvPKwdOTOaf836COgEORGPzgNpBKwq+trodeBQ+Ltz3H5capDyz4p0GvO9qPlC4oU61L8yeMeY7dC86aayOJD9yf9wIkrhTPEFFAlkuVHQuTctBjVEwuqR3n0r2HqMYj9yjEKybycw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: stewe.org X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR17MB3036.namprd17.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d3857e18-e91f-4cf0-2d23-08d838896109 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2020 15:16:36.1242 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: YZwr5nu/S3jrJLs90YOn/idGo5zVZbLOPxFdgQlvJj61u+0CEJIs0DQodhzjsfsh X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR17MB2825 Archived-At: Subject: Re: [Drip] ADSB X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 15:16:41 -0000 QWxleGFuZHJlLA0KDQpBRFMtQiBpcyBhIDIwKyB5ZWFyIG9sZCB0ZWNobm9sb2d5IGFuZCBvZmZl cnMgcHJvcGVydGllcyAoYmFuZHdpZHRoLCBzZWN1cml0eSwgY29zdCkgb2YgYSAyMCB5ZWFyIG9s ZCB0ZWNobm9sb2d5LiAgVGhhdCBpdCBqdXN0IHJlY2VudGx5IHNlZXMgd2lkZXNwcmVhZCBhZG9w dGlvbiBpcyBhIHJlc3VsdCBvZiBpbmNyZWRpYmx5IHNsb3cgKGV2ZW4gYnkgSUVURiBzdGFuZGFy ZHMpIGRlcGxveW1lbnQgcHJvY2VzcywgYW5kIHRoYXQgaW4gdHVybiBpcyB0aGUgcmVzdWx0IG9m IHRoZSB2ZXJ5IGNvbnNlcnZhdGl2ZSBhbmQgc2FmZXR5IGNvbnNjaW91cyBhdmlhdGlvbiBjb21t dW5pdHkgYW5kIHJlZ3VsYXRvcnMsIGFzIHdlbGwgYXMgdGhlIGhpZ2ggY29zdCByZWxhdGVkIHRv IGFueXRoaW5nIG1hbm1hZGUgdGhhdCBmbGllcy4gIEJ5IHNwZWN1bGF0aW5nIHRvIHVzZSBBRFMt QiBhcyBhbiB1bmRlcmx5aW5nIHRlY2hub2xvZ3kgZm9yIElQLCBJIGZlYXIgeW91IGRlbW9uc3Ry YXRlIGEgY2VydGFpbiBsYWNrIG9mIGJhY2tncm91bmQuICBUaGUgV2lraXBlZGlhIGFydGljbGUg b24gQURTLUIgKGh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0F1dG9tYXRpY19kZXBlbmRl bnRfc3VydmVpbGxhbmNlX+KAk19icm9hZGNhc3QpIGlzIG1vc3RseSBjb3JyZWN0LCBhbmQgSSBy ZWNvbW1lbmQgaW4gcGFydGljdWxhciB0aGUgc2VjdGlvbnMgb24gIlRoZW9yeSBvZiBvcGVyYXRp b24iIGFuZCAiU3lzdGVtIERlc2lnbiBDb25zaWRlcmF0aW9ucyIuDQoNCkEgZmV3IChvZiBtYW55 KSByZWFzb25zIHdoeSBBRFMtQiBpcyB1bnN1aXRhYmxlIGZvciBsaWdodCBkcm9uZXMgKGFueXRo aW5nIHNpZ25pZmljYW50bHkgc21hbGxlciB0aGFuIGEgbWFuLWNhcnJ5aW5nIGFpcmNyYWZ0KToN Ci0yNCBiaXQgSUNBTyB0cmFuc3BvbmRlciBjb2RlLCBsaW1pdGluZyB0aGUgbnVtYmVyIG9mIChh Y3RpdmUgb3IgaW5hY3RpdmUpIEFEUy1CIGVxdWlwbWVudC4gIEVhY2ggbW9kZXJuIGFpcmNyYWZ0 IG92ZXIgYSBjZXJ0YWluIHNpemUgKGV4Y2VwdCB0aGUgc21hbGxlc3QgdHdvLXNlYXRlcnMsIHBv d2VyZWQgcGFyYWNodXRlcywgYW5kIGFpcmNyYWZ0IHdpdGhvdXQgZWxlY3RyaWNhbCBzeXN0ZW1z IHN1Y2ggYXMgYW50aXF1ZXMpIGhhcyBhIHVuaXF1ZSBjb2RlIGFzc2lnbmVkIGZvciBpdHMgbGlm ZXRpbWUuDQotbGluZS1vZi1zaWdodCB3aXJlbGVzcyBjb25uZWN0aW9uIGZvciB0aGUgInVwbGlu ayIgd2l0aCBvbmx5IGEgZmV3IGh1bmRyZWQgZ3JvdW5kIHN0YXRpb25zIGZvciB0aGUgd2hvbGUg VVMgKG9yIDcwIGZvciB0aGUgd2hvbGUgQXVzdHJhbGlhKS4gIFRoYXQgbWVhbnMgQURTLUIgY292 ZXJhZ2UgaXMgYWxtb3N0IGV2ZXJ5d2hlcmUgb25seSBhdmFpbGFibGUgYXQgYWx0aXR1ZGVzIGlu IHdoaWNoIHNtYWxsIGRyb25lcyBhcmUgbmVpdGhlciBsZWdhbCBub3IsIGluIG1vc3QgY2FzZXMs IHBoeXNpY2FsbHkgY2FwYWJsZSB0byBmbHkgKGEgZmV3IHRob3VzYW5kIGZlZXQgaW4gdGhlIFVT IGV4Y2VwdCBuZWFyIG1ham9yIGFpcnBvcnRzIHdoZXJlIHlvdSBkb24ndCB3YW50IGRyb25lcywg MzAwMDAgZnQgaW4gQXVzdHJhbGlhKS4gIEFpcmNyYWZ0IHNlbmQgb3ZlciB0aGUgdXBsaW5rIGlu Zm9ybWF0aW9uIHN1Y2ggYXMgYWlyY3JhZnQgSUNBTyBjb2RlLCBhaXJjcmFmdCB0eXBlLCBzcGVl ZCwgZGlyZWN0aW9uIG9mIGZsaWdodCwgYWx0aXR1ZGUsIGV0Yy4pLiAgSW5mb3JtYXRpb24gaXMg c2VudCBpbiB0aGUgY2xlYXIsIGJ5IGRlc2lnbi4gIFlvdSBjYW4gYnV5IGEgYm94IHJlY2Vpdmlu ZyB0aGlzIGluZm8sIGhvb2sgaXQgdXAgdG8gYW4gUmFzcGJlcnJ5IFBJIG9yIHNvbWV0aGluZywg YW5kIGxvb2sgYXQgdGhlIHRyYWZmaWMgbmVhciB5b3VyIGhvdXNlIGFuZCBzZW5kIGl0IG9uIHRv IHlvdXIgZnJpZW5kcy0taW4gZmFjdCwgdGhpcyB0eXBlIG9mIGNyb3dkc291cmNlZCBBVEMgaW5m byBpcyB3aGF0IG1ha2VzIGZsaWdodHJhZGFyMjQgYW5kIHNpbWlsYXIgc2l0ZXMgd29yay4NCi10 aGUgZG93bmxpbmsgKHN5c3RlbSB0byBhaXJjcmFmdCkgaXMgYmFuZHdpZHRoLWxpbWl0ZWQgdG8g YSBmZXcgaHVuZHJlZCBrYml0L3MgZm9yIGFsbCBhaXJjcmFmdCBjb21iaW5lZCBpbiB0aGUgY292 ZXJhZ2Ugb2YgdGhlIHNhdGVsbGl0ZSB0cmFuc3BvbmRlci4gIChUaGlzIGlzIHNvbWV3aGF0IG92 ZXItc2ltcGxpZmllZCwgYXMgdGhlIHVwbGluayBpcyBpbnRlbnRpb25hbGx5IHNlbnQgaW4gdGhl IGNsZWFyLCBhbmQgbWFueSBBRFMtQiByZWNlaXZlcnMgbW9uaXRvciB0aGUgdXBsaW5rIG9mIG90 aGVyIGFpcmNyYWZ0IGZvciByZWR1bmRhbmN5IGFuZCBtb3JlIHVwLXRvLWRhdGUgaW5mb3JtYXRp b24gYWJvdXQgdHJhZmZpYzsgc2VlIGFiaXZlLikgIEFGQUlLLCB0aGUgd2hvbGUgY29udGluZW50 YWwgVVMgaXMgY292ZXJlZCBieSBsZXNzIHRoYW4gMjAgdHJhbnNwb25kZXJzLiBOIFRoZSBkb3du bGluayBjYXJyaWVzIG5vdCBvbmx5IHRyYWZmaWMgaW5mb3JtYXRpb24gYnV0IGFsc28gY3J1aXNl IGFuZCBhaXJwb3J0IHdlYXRoZXIsIGNlcnRhaW4gYWlyc3BhY2UgcmVzdHJpY3Rpb25zLCBhbmQg c28gZm9ydGguICBBbGwgdGhpcyBpcyBicm9hZGNhc3RlZCBhbmQgdGhlIEFEUy1CIHJlY2VpdmVy cyBpbiB0aGUgYWlyY3JhZnQgbmVlZCB0byBmaWx0ZXIgb3V0IHRoZSBpbmZvcm1hdGlvbiByZWxl dmFudCBmb3IgaXRzIHBvc2l0aW9uLCBjb3Vyc2UsIGFuZCBpbnRlbnRpb25zLiAgQWxyZWFkeSwg dGhlIGJhbmR3aWR0aCBhdmFpbGFibGUgaXMgYWxtb3N0IGZ1bGx5IHV0aWxpemVkIHRvIHRoZSBw b2ludCB0aGF0IHRoZSBicm9hZGNhc3Qgb2NjYXNpb25hbGx5IG5lZWRzIHRvIG9taXQgY2VydGFp biBsZXNzLWNyaXRpY2FsIGluZm9ybWF0aW9uIHRvIG1ha2Ugc3BhY2UgZm9yIG1vcmUgY3JpdGlj YWwgb25lLiAgVGhlIHN5c3RlbSBzY2FsZXMgb25seSBieSBhZGRpbmcgc2F0ZWxsaXRlIHRyYW5z cG9uZGVycywgd2hpY2ggaXMgZXhwZW5zaXZlIGFuZCBub3QgYSBmaW5lIGdyYW51bGFyaXR5Lg0K DQpBcyBmb3IgTWFycywgQURTLUIgaXMgdW5zdWl0YWJsZSB1bnRpbCBzb21lb25lIGJ1aWxkcyBh IGdyb3VuZC1zdGF0aW9uIG5ldHdvcmsgYW5kIGhhcyBzdWl0YWJsZSBzYXRlbGxpdGVzIGluIG9y Yml0LiAgQSBiaXQgY2xvc2VyIHRvIGVhcnRoLCBmb3Igb3Zlci13YXRlciBhbmQgdHJhbnMtcG9s ZSBvcGVyYXRpb25zIHRoZXJlIGlzIEFEUy1DLCB3aGljaCBpcyBjb21wbGV0ZWx5IHNhdGVsbGl0 ZSBiYXNlZCBhbmQsIEFGQUlLLCBldmVuIG1vcmUgYmFuZHdpZHRoIGxpbWl0ZWQgdGhhbiBBRFMt Qi4gIFlldCBhbm90aGVyIGV4YW1wbGUgZm9yIGEgbmV0d29yayB1bnN1aXRhYmxlIHRvIGNhcnJ5 IElQIHRyYWZmaWMsIGJ1dCBJIGRpZ3Jlc3MuDQoNCkluIHNob3J0LCBmb3JnZXQgQURTLUIgZm9y IHRoZSBEUklQIHdvcmsuLg0KDQpTdGVwaGFuDQoNCg0K77u/T24gOC80LzIwLCA2OjUzIEFNLCAi VG0tcmlkIG9uIGJlaGFsZiBvZiBBbGV4YW5kcmUgUGV0cmVzY3UiIDx0bS1yaWQtYm91bmNlc0Bp ZXRmLm9yZyBvbiBiZWhhbGYgb2YgYWxleGFuZHJlLnBldHJlc2N1QGdtYWlsLmNvbT4gd3JvdGU6 DQoNCiAgICBhcmNoaXRlY3R1cmFsIGxheWVycyBkaXNjdXNzaW9uLi4uDQoNCiAgICBMZSAzMC8w Ny8yMDIwIMOgIDExOjQ5LCBzaHVhaWl6aGFvKFNodWFpIFpoYW8pIGEgw6ljcml0IDoNCiAgICA+ IEp1c3QgdG8gZWNobyBTdHUgb24gdGhlIEFEU0IsIEFGQUlLLCBBRFNCIHdpbGwgIG5vdCBiZSBm ZWFzaWJsZSBmb3INCiAgICA+IG1vc3Qgb2YgdGhlIGRyb25lcyBtb3N0bHkgZHVlIHRvIFN3YVAs IGNvbW1lcmNpYWwgZHJvbmVzIG1pZ2h0IGJlDQogICAgPiBleGNlcHRpb24uDQoNCiAgICBJdCBt aWdodCBiZSB0aGF0IEFEUy1CIG1pZ2h0IGJlIGZvcmJpZGRlbiBpbiBkcm9uZXMgb24gRWFydGgs IGJ1dCBob3cNCiAgICBhYm91dCB0aGUgZHJvbmVzIG9uIE1hcnM/ICgnTkFTQSBNYXJzIGhlbGlj b3B0ZXJzJywgb3IgRVNBIHRvbykuICBPbg0KICAgIE1hcnMgdGhlcmUgd291bGQgYmUgbXVjaCBs ZXNzIHN1Y2ggZHJvbmVzLCBzbyBsZXNzIHJpc2sgb2YgaW50ZXJmZXJlbmNlLg0KDQogICAgV2l0 aCBzdWNoIGEgc3lzdGVtIChBRFMtQiB1bmRlciBJUCkgb25lIGNvdWxkIHJlLXVzZSBEVE4gKERl bGF5IFRvbGVyYW50DQogICAgTmV0d29ya2luZykgYmV0d2VlbiBwbGFuZXRzLCBhbmQgc28gaWRl bnRpZnkgZHJvbmVzIGV2ZW4gb24gTWFycy4NCg0KICAgIEJ1dCBpZiB3ZSBoYXZlIHJlbHVjdGFu Y2UgYWJvdXQgdGhlIHVzZSBvZiBBRFMtQiwgYW5kIHRodXMgb2YgSVAsIGFuZCB3ZQ0KICAgIHJl Y29tbWVuZCBCbHVldG9vdGgtd2l0aG91dC1JUCB0byBpZGVudGlmeSBkcm9uZXMsIHRoZW4gd2Ug bWlnaHQgYmVjb21lDQogICAgdG9vIGRlcGVuZGVudCBvbiBpdD8NCg0KICAgIChkbyBub3QgZ2V0 IG1lIHdyb25nLCBJIGRvIGxpa2UgQmx1ZXRvb3RoLCBidXQgSSBsaWtlIG1hbnkgb3RoZXIgdGhp bmdzDQogICAgdG9nZXRoZXIgd2l0aCBCbHVldG9vdGgpLg0KDQogICAgQWxleA0KDQogICAgPiAN CiAgICA+IEJlc3QsDQogICAgPiANCiAgICA+IFNodWFpIFpoYW8NCiAgICA+IA0KICAgID4gKkZy b206ICpUbS1yaWQgPHRtLXJpZC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgIlN0dWFy dCBXLg0KICAgID4gQ2FyZCIgPHN0dS5jYXJkQGF4ZW50ZXJwcml6ZS5jb20+ICpEYXRlOiAqV2Vk bmVzZGF5LCBKdWx5IDI5LCAyMDIwIGF0DQogICAgPiAxOTo0NiAqVG86ICoidG0tcmlkQGlldGYu b3JnIiA8dG0tcmlkQGlldGYub3JnPiAqU3ViamVjdDogKltEcmlwXQ0KICAgID4gQURTQiAod2Fz OiBSZXZpZXcgb2YgZHJhZnQtZHJpcC1hcmNoLTAyIHcuci50LiBSRkM2OTczLCBSRkM4MjgwIGFu ZA0KICAgID4gb3RoZXIpKEludGVybmV0IG1haWwpDQogICAgPiANCiAgICA+IFNvcnJ5IGZvciB0 aGUgc2xvdyByZXBseS4NCiAgICA+IA0KICAgID4gQURTLUIgaXMgZ3JhZHVhbGx5IGJlaW5nIG1h bmRhdGVkIGZvciBlc3NlbnRpYWxseSBhbGwgbWFubmVkDQogICAgPiBhaXJjcmFmdC4NCiAgICA+ IA0KICAgID4gQURTQi1JbiBhbmQgQURTQi1PdXQgYXJlIG1hbmRhdGVkIGZvciBhaXJsaW5lcnM6 IC1JbiBnaXZlcyB0aGVpcg0KICAgID4gcGlsb3RzDQogICAgPiANCiAgICA+IHNvbWUgU2l0dWF0 aW9uYWwgQXdhcmVuZXNzIChTQSkgb2Ygb3RoZXIgYWlyY3JhZnQ7IC1PdXQgZ2l2ZXMgb3RoZXIN CiAgICA+IA0KICAgID4gcGlsb3RzIFNBIG9mIHRoZSBhaXJsaW5lcnMuDQogICAgPiANCiAgICA+ ICJBRFNCLU91dCIgaXMgbWFuZGF0ZWQgZXZlbiBmb3Igc21hbGwgZ2VuZXJhbCBhdmlhdGlvbiBh aXJjcmFmdDogaXQNCiAgICA+IGRvZXMNCiAgICA+IA0KICAgID4gbm90IGRpcmVjdGx5IGJlbmVm aXQgdGhlIHBpbG90cyBvZiB0aG9zZSBhaXJjcmFmdDsgYnV0IGJ5IHByb3ZpZGluZw0KICAgID4g U0ENCiAgICA+IA0KICAgID4gdG8gb3RoZXJzLCBpdCBpbmRpcmVjdGx5IGJlbmVmaXRzIGFsbC4N CiAgICA+IA0KICAgID4gQURTQiBpcyBfbm90XyBnb2luZyB0byBiZSBkZXBsb3llZCBvbiBsYXJn ZSBudW1iZXJzIG9mIHNtYWxsIFVBUyBhcw0KICAgID4gaXQNCiAgICA+IA0KICAgID4gd291bGQg b3ZlcndoZWxtIHRoZSBsaW1pdGVkIGJhbmR3aWR0aCBhdmFpbGFibGUgYXQgdGhvc2UgbG93ZXIg cmFkaW8NCiAgICA+IA0KICAgID4gZnJlcXVlbmNpZXMgKHdoaWNoIHByb3BhZ2F0ZSBsb25nIHJh bmdlcykuIEluIGZhY3QsIGl0IGlzIGV4cGVjdGVkIHRvDQogICAgPiBiZQ0KICAgID4gDQogICAg PiBleHBsaWNpdGx5IHByb2hpYml0ZWQgaW4gdGhlIFVTIHBlciB0aGUgRkFBIE5QUk07IEkgc3Vz cGVjdCBtb3N0IG9mDQogICAgPiB0aGUNCiAgICA+IA0KICAgID4gcmVzdCBvZiB0aGUgd29ybGQg d2lsbCBkbyBsaWtld2lzZS4NCiAgICA+IA0KICAgID4gQURTQiBpcyBhbHNvIGFsdG9nZXRoZXIg aW5zZWN1cmUuDQogICAgPiANCiAgICA+IE9uIDcvOS8yMDIwIDM6MDIgQU0sIEFsZXhhbmRyZSBQ ZXRyZXNjdSB3cm90ZToNCiAgICA+IA0KICAgID4gLi4uDQogICAgPiANCiAgICA+IFRoZXkgY2Fs bCBpdCAiQURTLUIgUmVjZWl2ZXJzIiAoQXV0b21hdGljIERlcGVuZGVudCBTdXJ2ZWlsbGFuY2Ug LQ0KICAgID4gDQogICAgPiBCcm9hZGNhc3QpLg0KICAgID4gDQogICAgPiBJIHdvdXVsZCBsaWtl IHRvIGFzayBpZiB0aGVyZSBpcyBhIHBhY2tldCBkdW1wIGF2YWlsYWJsZSBzaG93aW5nDQogICAg PiBzdWNoDQogICAgPiANCiAgICA+IHByZXNlbmNlIGRhdGEgZm9ybSBwbGFuZXM/ICBNYXliZSB3 aXJlc2hhcmsgYWxyZWFkeSBzdXBwb3J0cyBpdCwNCiAgICA+IG1heWJlDQogICAgPiANCiAgICA+ IGl0IGV2ZW4gZGlzc2VjdHMgaXQuLi4NCiAgICA+IA0KICAgID4gLS0NCiAgICA+IA0KICAgID4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICA+IA0KICAgID4g U3R1YXJ0IFcuIENhcmQsIFBoRCwgUHJpbmNpcGFsIEVuZ2luZWVyDQogICAgPiANCiAgICA+IEFY IEVudGVycHJpemUsIExMQyAgd3d3LmF4ZW50ZXJwcml6ZS5jb20NCiAgICA+IA0KICAgID4gNDk0 NyBDb21tZXJjaWFsIERyaXZlLCBZb3JrdmlsbGUgTlkgMTM0OTUNCiAgICA+IA0KICAgID4gDQoN CiAgICAtLSANCiAgICBUbS1yaWQgbWFpbGluZyBsaXN0DQogICAgVG0tcmlkQGlldGYub3JnDQog ICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bS1yaWQNCg0K From nobody Tue Aug 4 08:17:28 2020 Return-Path: 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 B55303A07C8 for ; Tue, 4 Aug 2020 08:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 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, NICE_REPLY_A=-0.949, 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=axenterprize.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 WpXV8O0KkfwG for ; Tue, 4 Aug 2020 08:17:25 -0700 (PDT) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AB4F3A07C5 for ; Tue, 4 Aug 2020 08:17:24 -0700 (PDT) Received: by mail-qk1-x734.google.com with SMTP id q128so6338838qkd.2 for ; Tue, 04 Aug 2020 08:17:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axenterprize.com; s=google; h=to:references:from:autocrypt:subject:message-id:date:user-agent :mime-version:in-reply-to; bh=vOEYz0uJLDppvF/K+mrK7UehRgtZgZlmqYQ2BMhLZQU=; b=IPcgSgFoBKBbIiT713aLJleMaFE4Bff/8+bclxR5eL4nktGrtNMdBH6ieCfYCAOF8z GiVJec29vz5F45OBpTa38DpUyq1+O5OWqlh2dJiR849WHmMJLY8ZY8JVeh3K53iTrI7U PiNmSgE/6KsPrAoEnXUI6GSNGbhYX/Do55+RE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:references:from:autocrypt:subject:message-id :date:user-agent:mime-version:in-reply-to; bh=vOEYz0uJLDppvF/K+mrK7UehRgtZgZlmqYQ2BMhLZQU=; b=Yo9YPuaM4d5eUkZSyZhbWfkmfe1eqwu2l/4srVt6Dwkx7Dn/2YqBG5kj6HBB8YP9BF ssLhYep+/CPi5wWaTSxLOWpbOXCkGRn1/jUj96k89SbJgHs3XxV+iBPLpYxVUBNzvF0x iIhAGdb3fmwhb08E0KiThXxG2K/Sy+sFF6qlMM5qjStD0twdt4ajVUDQ+Rrj43SOcuJP VhUvkDz3M6e/s6VvpjSKugTmx50qCGqkJZHNVeEIJdDTM8U56dGwod5LXl/K5R5yS8N/ CNHfSxCpTCmv7hTrbA04UrzCDoJpmRz2FuNNQsVXwW2pxurPlAcb+znJwJJrA+oidOgS dI/A== X-Gm-Message-State: AOAM531z0zoiGF9rN3KR7Nhq2eO7zly/bmMXA46esOkn0tQX1AmN7gah W5ihaXbXAMMd6wfmZ5TxDGqPLTqHlSj5uQ== X-Google-Smtp-Source: ABdhPJytrjRH9R6rDv4uvupoadURd9aOGVbcAmG/ybUbj7gG9jnhMWK+N5Nh3rqucpIdyNVtRwz+xA== X-Received: by 2002:a37:a291:: with SMTP id l139mr20043600qke.117.1596554243493; Tue, 04 Aug 2020 08:17:23 -0700 (PDT) Received: from [192.168.1.107] (ip-72-10-210-250.nwptny.ntcnet.net. [72.10.210.250]) by smtp.gmail.com with ESMTPSA id i66sm21827259qke.124.2020.08.04.08.17.22 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 Aug 2020 08:17:22 -0700 (PDT) To: tm-rid@ietf.org References: <1bebf5b1-1fa5-6902-5bb7-9ec3582e6d9a@andersdotter.cc> <2990FBF0-FCB0-49CE-8F4B-BF5111CE5D57@tzi.org> <01a21161-aa8d-6d4b-b384-3129fe6d799b@gmail.com> <973223fd-0119-376d-12cd-21559a14ce87@labs.htt-consult.com> <3c632ce9-115d-11f5-ee33-bfabd4973522@labs.htt-consult.com> <7ddd9a2f-23ba-dd82-8cfb-1d2974969e67@gmail.com> From: "Stuart W. Card" Autocrypt: addr=stu.card@axenterprize.com; prefer-encrypt=mutual; keydata= mQGiBDpARp4RBADNQipCkPP9uNjzow8Fyltan7Fsc1obeYCZsHmKB3J9GkjAOISXeg5ce7PG NxugbgU1pAkhU6bARdTYFllKGz7WP8cwRVzQvwNbDLowPImeaRFsSOSU3T1RSzAC4vIRv7Q2 amQkSZLSh105f4whqkR1QqFUPqamhxHy2itg+zUSowCg/13xoiFRCbhzEq3MaiKrHd/wyM0D /3fHb4CyuIe5c5iz+Jh4h9MSLvKnWeGzRaokBSrJj3sJf2foSWFrx8lmib0Sgzrpb1/s5c+f eE6N444bAEnGEnCwmHaFdCebTif/8t4ZPVZqGEHIye4fpegcsQwkzcIyKp7mM1KjpcfsBOg+ AKhiuBUKCkYdzg1DQiKfyiJRgXcvA/4tb35LGbLOLgRWOO78hy293tAeE+bQKa9GYKaOCk8L Gadddjh4oTrW+KUnyas/jbl6V5ZArXLgS9qwniVT8VD8f/w0C4opJGyNMmMRWGGR139STrLy dxK5uMdqSufP3ppCrZaBhMxw9e93GuuDzxftVw1N0mBpjSidsqnQoLJiN7QvU3R1YXJ0IFdp bGxpYW0gQ2FyZCA8c3R1LmNhcmRAYXhlbnRlcnByaXplLmNvbT6IeAQTEQIAOBYhBDbKqfE+ xHVTMRc+Kkuz0NGtsHi+BQJfA2S+AhsjBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEEuz 0NGtsHi+lhsAoJqGqvLU5IEt1nahjQ8Gdtmk6NtFAKCKkEpLa3gyKUxJtpjq/TfPk11YLrkE DQQ6QEaeEBAA+RigfloGYXpDkJXcBWyHhuxh7M1FHw7Y4KN5xsncegus5D/jRpS2MEpT13wC FkiAtRXlKZmpnwd00//jocWWIE6YZbjYDe4QXau2FxxR2FDKIldDKb6V6FYrOHhcC9v4TE3V 46pGzPvOF+gqnRRh44SpT9GDhKh5tu+Pp0NGCMbMHXdXJDhK4sTw6I4TZ5dOkhNh9tvrJQ4X /faY98h8ebByHTh1+/bBc8SDESYrQ2DD4+jWCv2hKCYLrqmus2UPogBTAaB81qujEh76DyrO H3SET8rzF/OkQOnX0ne2Qi0CNsEmy2henXyYCQqNfi3t5F159dSST5sYjvwqp0t8MvZCV7cI fwgXcqK61qlC8wXo+VMROU+28W65Szgg2gGnVqMU6Y9AVfPQB8bLQ6mUrfdMZIZJ+AyDvWXp F9Sh01D49Vlf3HZSTz09jdvOmeFXklnN/biudE/F/Ha8g8VHMGHOfMlm/xX5u/2RXscBqtNb no2gpXI61Brwv0YAWCvl9Ij9WE5J280gtJ3kkQc2azNsOA1FHQ98iLMcfFstjvbzySPAQ/Cl WxiNjrtVjLhdONM0/XwXV0OjHRhs3jMhLLUq/zzhsSlAGBGNfISnCnLWhsQDGcgHKXrKlQzZ lp+r0ApQmwJG0wg9ZqRdQZ+cfL2JSyIZJrqrol7DVes91hcAAgIQAMNvvhEBqOLNS6qAtj+V xdIJR3zWR/ocrre94V8TZWrdiblN8tbJWBsVAUVjhQB04ygXO5RbpyDpMCMimnzLQ95immw5 vyoL+iqbCHGmlr/BBvJUUc3BvbERona1MZ7Bt+fe9n6Tc1ipyDNzkguk0mEAgsoRHtLb7TsT eUU7TrWbmutBjxmjUBad9yVNV0QAlnYQBS1t01OkeYqRMS3YxRLAF097VTOR+WHw3e8m9zMh ZQAuC3Delii8QT4vzVqIiLdW8wwHgHz1qM5hhZVU4La5jnvtrUbFvxc5cLvREAGuAjW4JXgN h1OD6zWlXXTwiyfrHDWEIMMAXIYVYgYWgT83FB0ddsCDD7H5+8sGjuqZ/J+XF8l2BQDnQGK2 9Ht6jBRH8CfG0uwG9yVTNc+LgewR9/Ub8/UudxWyuK0pbFWQr1bAeJ3hwnGYIedvcAdFXcQo rVbCd5ayhBVht8wyCK2JlgNa2Zq+30ymyZJKb8zBhwNtrNczegjn3EgIRBRCxZdh7uCRyZFL Sdz2QJ6Q8RqldorNWGUnB2Jhbkiq3/0P99F0CwlhSLmHiJAOodCB6oIYfU3WqAqrHtutSccd 7V6t+D3slaOptqXcJb0Q06xuccwzYmEIu6mqxBuawjPoAZNGcx3kSJab6cd5TayXR586ik5q HOJmlZ8e43TbCjSpiEYEGBECAAYFAjpARp4ACgkQS7PQ0a2weL65HgCePHJT7ryvg2LwPGgK 0yVFIpzmWa0AnjgpvFwf0EHDFhjEr8y2AnKzNN2X Message-ID: Date: Tue, 4 Aug 2020 11:17:06 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sUEkSrbnfqkdWP6u5xyAwqY27YDkMBVaj" Archived-At: Subject: Re: [Drip] ADSB X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 15:17:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sUEkSrbnfqkdWP6u5xyAwqY27YDkMBVaj Content-Type: multipart/mixed; boundary="uRr8Sq1xCkSBx4RGQYHjJIMhd9b02KP04"; protected-headers="v1" From: "Stuart W. Card" To: tm-rid@ietf.org Message-ID: Subject: Re: [Drip] ADSB References: <1bebf5b1-1fa5-6902-5bb7-9ec3582e6d9a@andersdotter.cc> <2990FBF0-FCB0-49CE-8F4B-BF5111CE5D57@tzi.org> <01a21161-aa8d-6d4b-b384-3129fe6d799b@gmail.com> <973223fd-0119-376d-12cd-21559a14ce87@labs.htt-consult.com> <3c632ce9-115d-11f5-ee33-bfabd4973522@labs.htt-consult.com> <7ddd9a2f-23ba-dd82-8cfb-1d2974969e67@gmail.com> In-Reply-To: --uRr8Sq1xCkSBx4RGQYHjJIMhd9b02KP04 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable I just want to respond to one line that I think comes from confusion: > But if we have reluctance about the use of ADS-B, and thus of IP,=20 > and we recommend Bluetooth-without-IP to identify drones We aren't recommending Bluetooth-without-IP, we are _supporting_ it, as it is specified in ASTM F3411, which most of the regulators are dubbing as an approved technical means of regulatory compliance. AFAIK, no one runs IP over ADS-B, which was designed as a narrowband application specific communications stovepipe, not a data link supporting higher layer network protocols, so not great for IP. More importantly, we have no "reluctance about the use of... IP", which is an entirely separate issue from ADS-B. On 8/4/2020 9:52 AM, Alexandre Petrescu wrote: > architectural layers discussion... >=20 > Le 30/07/2020 =C3=A0 11:49, shuaiizhao(Shuai Zhao) a =C3=A9crit : >> Just to echo Stu on the ADSB, AFAIK, ADSB will=C2=A0 not be feasible f= or >> most of the drones mostly due to SwaP, commercial drones might be >> exception. >=20 > It might be that ADS-B might be forbidden in drones on Earth, but how > about the drones on Mars? ('NASA Mars helicopters', or ESA too).=C2=A0 = On > Mars there would be much less such drones, so less risk of interference= =2E >=20 > With such a system (ADS-B under IP) one could re-use DTN (Delay Toleran= t > Networking) between planets, and so identify drones even on Mars. >=20 > But if we have reluctance about the use of ADS-B, and thus of IP, and w= e > recommend Bluetooth-without-IP to identify drones, then we might become= > too dependent on it? >=20 > (do not get me wrong, I do like Bluetooth, but I like many other things= > together with Bluetooth). >=20 > Alex >=20 >> >> Best, >> >> Shuai Zhao >> >> *From: *Tm-rid on behalf of "Stuart W. >> Card" *Date: *Wednesday, July 29, 2020 at >> 19:46 *To: *"tm-rid@ietf.org" *Subject: *[Drip] >> ADSB (was: Review of draft-drip-arch-02 w.r.t. RFC6973, RFC8280 and >> other)(Internet mail) >> >> Sorry for the slow reply. >> >> ADS-B is gradually being mandated for essentially all manned >> aircraft. >> >> ADSB-In and ADSB-Out are mandated for airliners: -In gives their >> pilots >> >> some Situational Awareness (SA) of other aircraft; -Out gives other >> >> pilots SA of the airliners. >> >> "ADSB-Out" is mandated even for small general aviation aircraft: it >> does >> >> not directly benefit the pilots of those aircraft; but by providing >> SA >> >> to others, it indirectly benefits all. >> >> ADSB is _not_ going to be deployed on large numbers of small UAS as >> it >> >> would overwhelm the limited bandwidth available at those lower radio >> >> frequencies (which propagate long ranges). In fact, it is expected to >> be >> >> explicitly prohibited in the US per the FAA NPRM; I suspect most of >> the >> >> rest of the world will do likewise. >> >> ADSB is also altogether insecure. >> >> On 7/9/2020 3:02 AM, Alexandre Petrescu wrote: >> >> ... >> >> They call it "ADS-B Receivers" (Automatic Dependent Surveillance - >> >> Broadcast). >> >> I wouuld like to ask if there is a packet dump available showing >> such >> >> presence data form planes?=C2=A0 Maybe wireshark already supports it, >> maybe >> >> it even dissects it... >> >> --=20 >> >> ----------------------------------------- >> >> Stuart W. Card, PhD, Principal Engineer >> >> AX Enterprize, LLC=C2=A0 www.axenterprize.com >> >> 4947 Commercial Drive, Yorkville NY 13495 >> >> >=20 --=20 ----------------------------------------- Stuart W. Card, PhD, Principal Engineer AX Enterprize, LLC www.axenterprize.com 4947 Commercial Drive, Yorkville NY 13495 --uRr8Sq1xCkSBx4RGQYHjJIMhd9b02KP04-- --sUEkSrbnfqkdWP6u5xyAwqY27YDkMBVaj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQ2yqnxPsR1UzEXPipLs9DRrbB4vgUCXyl78gAKCRBLs9DRrbB4 vkSFAJ9Dg2VahoSYiAl2giLvdNASOJxrqQCg/RXC5traeOysYHrbGvRgdun9ZFo= =d9WN -----END PGP SIGNATURE----- --sUEkSrbnfqkdWP6u5xyAwqY27YDkMBVaj-- From nobody Tue Aug 4 08:27:56 2020 Return-Path: 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 3C49C3A0ABE for ; Tue, 4 Aug 2020 08:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.278 X-Spam-Level: X-Spam-Status: No, score=-0.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.949, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 TFGd6qhqC8e7 for ; Tue, 4 Aug 2020 08:27:47 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 9C95D3A0AD8 for ; Tue, 4 Aug 2020 08:27:46 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 074FRiTh024976 for ; Tue, 4 Aug 2020 17:27:44 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id EA6812058E0 for ; Tue, 4 Aug 2020 17:27:44 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E01FF201359 for ; Tue, 4 Aug 2020 17:27:44 +0200 (CEST) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 074FRiRY022333 for ; Tue, 4 Aug 2020 17:27:44 +0200 To: tm-rid@ietf.org References: <1bebf5b1-1fa5-6902-5bb7-9ec3582e6d9a@andersdotter.cc> <2990FBF0-FCB0-49CE-8F4B-BF5111CE5D57@tzi.org> <01a21161-aa8d-6d4b-b384-3129fe6d799b@gmail.com> <973223fd-0119-376d-12cd-21559a14ce87@labs.htt-consult.com> <3c632ce9-115d-11f5-ee33-bfabd4973522@labs.htt-consult.com> <7ddd9a2f-23ba-dd82-8cfb-1d2974969e67@gmail.com> From: Alexandre Petrescu Message-ID: <61511ef6-5b9b-5b62-f922-d32b994a35b9@gmail.com> Date: Tue, 4 Aug 2020 17:27:44 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Drip] ADSB X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 15:27:55 -0000 Thanks for the clarification. Le 04/08/2020 à 17:17, Stuart W. Card a écrit : > I just want to respond to one line that I think comes from confusion: > >> But if we have reluctance about the use of ADS-B, and thus of IP, >> and we recommend Bluetooth-without-IP to identify drones > > We aren't recommending Bluetooth-without-IP, we are _supporting_ it, But, the security manifest that I have seen on slides during the presentation of the DRIP WG meeting - is something below IP, right? Alex as > it is specified in ASTM F3411, which most of the regulators are dubbing > as an approved technical means of regulatory compliance. > > AFAIK, no one runs IP over ADS-B, which was designed as a narrowband > application specific communications stovepipe, not a data link > supporting higher layer network protocols, so not great for IP. > > More importantly, we have no "reluctance about the use of... IP", which > is an entirely separate issue from ADS-B. > > On 8/4/2020 9:52 AM, Alexandre Petrescu wrote: >> architectural layers discussion... >> >> Le 30/07/2020 à 11:49, shuaiizhao(Shuai Zhao) a écrit : >>> Just to echo Stu on the ADSB, AFAIK, ADSB will  not be feasible for >>> most of the drones mostly due to SwaP, commercial drones might be >>> exception. >> >> It might be that ADS-B might be forbidden in drones on Earth, but how >> about the drones on Mars? ('NASA Mars helicopters', or ESA too).  On >> Mars there would be much less such drones, so less risk of interference. >> >> With such a system (ADS-B under IP) one could re-use DTN (Delay Tolerant >> Networking) between planets, and so identify drones even on Mars. >> >> But if we have reluctance about the use of ADS-B, and thus of IP, and we >> recommend Bluetooth-without-IP to identify drones, then we might become >> too dependent on it? >> >> (do not get me wrong, I do like Bluetooth, but I like many other things >> together with Bluetooth). >> >> Alex >> >>> >>> Best, >>> >>> Shuai Zhao >>> >>> *From: *Tm-rid on behalf of "Stuart W. >>> Card" *Date: *Wednesday, July 29, 2020 at >>> 19:46 *To: *"tm-rid@ietf.org" *Subject: *[Drip] >>> ADSB (was: Review of draft-drip-arch-02 w.r.t. RFC6973, RFC8280 and >>> other)(Internet mail) >>> >>> Sorry for the slow reply. >>> >>> ADS-B is gradually being mandated for essentially all manned >>> aircraft. >>> >>> ADSB-In and ADSB-Out are mandated for airliners: -In gives their >>> pilots >>> >>> some Situational Awareness (SA) of other aircraft; -Out gives other >>> >>> pilots SA of the airliners. >>> >>> "ADSB-Out" is mandated even for small general aviation aircraft: it >>> does >>> >>> not directly benefit the pilots of those aircraft; but by providing >>> SA >>> >>> to others, it indirectly benefits all. >>> >>> ADSB is _not_ going to be deployed on large numbers of small UAS as >>> it >>> >>> would overwhelm the limited bandwidth available at those lower radio >>> >>> frequencies (which propagate long ranges). In fact, it is expected to >>> be >>> >>> explicitly prohibited in the US per the FAA NPRM; I suspect most of >>> the >>> >>> rest of the world will do likewise. >>> >>> ADSB is also altogether insecure. >>> >>> On 7/9/2020 3:02 AM, Alexandre Petrescu wrote: >>> >>> ... >>> >>> They call it "ADS-B Receivers" (Automatic Dependent Surveillance - >>> >>> Broadcast). >>> >>> I wouuld like to ask if there is a packet dump available showing >>> such >>> >>> presence data form planes?  Maybe wireshark already supports it, >>> maybe >>> >>> it even dissects it... >>> >>> -- >>> >>> ----------------------------------------- >>> >>> Stuart W. Card, PhD, Principal Engineer >>> >>> AX Enterprize, LLC  www.axenterprize.com >>> >>> 4947 Commercial Drive, Yorkville NY 13495 >>> >>> >> > > > From nobody Tue Aug 4 08:51:20 2020 Return-Path: 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 B652B3A0B89 for ; Tue, 4 Aug 2020 08:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, 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 TX2xM-9L_DlY for ; Tue, 4 Aug 2020 08:51:16 -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 BD1033A0B63 for ; Tue, 4 Aug 2020 08:51:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id E073F62422; Tue, 4 Aug 2020 11:51:14 -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 kUgPSZhU5KRM; Tue, 4 Aug 2020 11:51:06 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (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 9C14862415; Tue, 4 Aug 2020 11:51:06 -0400 (EDT) To: Alexandre Petrescu , tm-rid@ietf.org References: <1bebf5b1-1fa5-6902-5bb7-9ec3582e6d9a@andersdotter.cc> <2990FBF0-FCB0-49CE-8F4B-BF5111CE5D57@tzi.org> <01a21161-aa8d-6d4b-b384-3129fe6d799b@gmail.com> <973223fd-0119-376d-12cd-21559a14ce87@labs.htt-consult.com> <3c632ce9-115d-11f5-ee33-bfabd4973522@labs.htt-consult.com> <7ddd9a2f-23ba-dd82-8cfb-1d2974969e67@gmail.com> <61511ef6-5b9b-5b62-f922-d32b994a35b9@gmail.com> From: Robert Moskowitz Message-ID: Date: Tue, 4 Aug 2020 11:51:03 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <61511ef6-5b9b-5b62-f922-d32b994a35b9@gmail.com> Content-Type: multipart/alternative; boundary="------------730F1DEBFF6E87651AF0643F" Content-Language: en-US Archived-At: Subject: Re: [Drip] ADSB X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 15:51:20 -0000 This is a multi-part message in MIME format. --------------730F1DEBFF6E87651AF0643F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 8/4/20 11:27 AM, Alexandre Petrescu wrote: > Thanks for the clarification. > > Le 04/08/2020 à 17:17, Stuart W. Card a écrit : >> I just want to respond to one line that I think comes from confusion: >> >>> But if we have reluctance about the use of ADS-B, and thus of IP, >>> and we recommend Bluetooth-without-IP to identify drones >> >> We aren't recommending Bluetooth-without-IP, we are _supporting_ it, > > But, the security manifest that I have seen on slides during the > presentation of the DRIP WG meeting - is something below IP, right? For now, we are dealing with broadcast messages.  Either over Bluetooth or WiFI (NAN).  There is NO security for the messages below the message package.  Just not enough payload size for anything that would work in a broadcast environment like a National Airspace.  All of the security we are specifying is inside the messages where appropriate. That security manifest is a payload of the ASTM F3411-19 Authentication Message.  These messages are broadcasted as Adam mentioned in his 'flying DRIP' comments at the beginning. Now later I expect us to move on to Network Remote ID and Command and Control (C2). Most C2 (e.g. Mavlink) is directly over the MAC, but there is a method to run it over UDP (I forget the UDP port commonly used...). AX Enterprize has done this using HIP so the UA starts with WiFi over the launch point, transitions to LTE, and on return back to WiFi. Network Remote ID can work either directly from the UA, or via C2 information to the GCS, from the GCS.  In either case, IP is assumed.  This will probably be done via UDP.  From the UA, mobility will be important; from the GCS nice to have (most GCS will be stable location).  As UDP to a fixed Net-SP, DTLS 1.3 is a viable alternative to HIP. > > Alex > >  as >> it is specified in ASTM F3411, which most of the regulators are dubbing >> as an approved technical means of regulatory compliance. >> >> AFAIK, no one runs IP over ADS-B, which was designed as a narrowband >> application specific communications stovepipe, not a data link >> supporting higher layer network protocols, so not great for IP. >> >> More importantly, we have no "reluctance about the use of... IP", which >> is an entirely separate issue from ADS-B. >> >> On 8/4/2020 9:52 AM, Alexandre Petrescu wrote: >>> architectural layers discussion... >>> >>> Le 30/07/2020 à 11:49, shuaiizhao(Shuai Zhao) a écrit : >>>> Just to echo Stu on the ADSB, AFAIK, ADSB will  not be feasible for >>>> most of the drones mostly due to SwaP, commercial drones might be >>>> exception. >>> >>> It might be that ADS-B might be forbidden in drones on Earth, but how >>> about the drones on Mars? ('NASA Mars helicopters', or ESA too).  On >>> Mars there would be much less such drones, so less risk of >>> interference. >>> >>> With such a system (ADS-B under IP) one could re-use DTN (Delay >>> Tolerant >>> Networking) between planets, and so identify drones even on Mars. >>> >>> But if we have reluctance about the use of ADS-B, and thus of IP, >>> and we >>> recommend Bluetooth-without-IP to identify drones, then we might become >>> too dependent on it? >>> >>> (do not get me wrong, I do like Bluetooth, but I like many other things >>> together with Bluetooth). >>> >>> Alex >>> >>>> >>>> Best, >>>> >>>> Shuai Zhao >>>> >>>> *From: *Tm-rid on behalf of "Stuart W. >>>> Card" *Date: *Wednesday, July 29, 2020 at >>>> 19:46 *To: *"tm-rid@ietf.org" *Subject: *[Drip] >>>> ADSB (was: Review of draft-drip-arch-02 w.r.t. RFC6973, RFC8280 and >>>> other)(Internet mail) >>>> >>>> Sorry for the slow reply. >>>> >>>> ADS-B is gradually being mandated for essentially all manned >>>> aircraft. >>>> >>>> ADSB-In and ADSB-Out are mandated for airliners: -In gives their >>>> pilots >>>> >>>> some Situational Awareness (SA) of other aircraft; -Out gives other >>>> >>>> pilots SA of the airliners. >>>> >>>> "ADSB-Out" is mandated even for small general aviation aircraft: it >>>> does >>>> >>>> not directly benefit the pilots of those aircraft; but by providing >>>> SA >>>> >>>> to others, it indirectly benefits all. >>>> >>>> ADSB is _not_ going to be deployed on large numbers of small UAS as >>>> it >>>> >>>> would overwhelm the limited bandwidth available at those lower radio >>>> >>>> frequencies (which propagate long ranges). In fact, it is expected to >>>> be >>>> >>>> explicitly prohibited in the US per the FAA NPRM; I suspect most of >>>> the >>>> >>>> rest of the world will do likewise. >>>> >>>> ADSB is also altogether insecure. >>>> >>>> On 7/9/2020 3:02 AM, Alexandre Petrescu wrote: >>>> >>>> ... >>>> >>>> They call it "ADS-B Receivers" (Automatic Dependent Surveillance - >>>> >>>> Broadcast). >>>> >>>> I wouuld like to ask if there is a packet dump available showing >>>> such >>>> >>>> presence data form planes?  Maybe wireshark already supports it, >>>> maybe >>>> >>>> it even dissects it... >>>> >>>> -- >>>> >>>> ----------------------------------------- >>>> >>>> Stuart W. Card, PhD, Principal Engineer >>>> >>>> AX Enterprize, LLC  www.axenterprize.com >>>> >>>> 4947 Commercial Drive, Yorkville NY 13495 >>>> >>>> >>> >> >> >> > -- 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 --------------730F1DEBFF6E87651AF0643F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 8/4/20 11:27 AM, Alexandre Petrescu wrote:
Thanks for the clarification.

Le 04/08/2020 à 17:17, Stuart W. Card a écrit :
I just want to respond to one line that I think comes from confusion:

But if we have reluctance about the use of ADS-B, and thus of IP,
and we recommend Bluetooth-without-IP to identify drones

We aren't recommending Bluetooth-without-IP, we are _supporting_ it,

But, the security manifest that I have seen on slides during the presentation of the DRIP WG meeting - is something below IP, right?

For now, we are dealing with broadcast messages.  Either over Bluetooth or WiFI (NAN).  There is NO security for the messages below the message package.  Just not enough payload size for anything that would work in a broadcast environment like a National Airspace.  All of the security we are specifying is inside the messages where appropriate.

That security manifest is a payload of the ASTM F3411-19 Authentication Message.  These messages are broadcasted as Adam mentioned in his 'flying DRIP' comments at the beginning.

Now later I expect us to move on to Network Remote ID and Command and Control (C2).

Most C2 (e.g. Mavlink) is directly over the MAC, but there is a method to run it over UDP (I forget the UDP port commonly used...).  AX Enterprize has done this using HIP so the UA starts with WiFi over the launch point, transitions to LTE, and on return back to WiFi.

Network Remote ID can work either directly from the UA, or via C2 information to the GCS, from the GCS.  In either case, IP is assumed.  This will probably be done via UDP.  From the UA, mobility will be important; from the GCS nice to have (most GCS will be stable location).  As UDP to a fixed Net-SP, DTLS 1.3 is a viable alternative to HIP.





Alex

 as
it is specified in ASTM F3411, which most of the regulators are dubbing
as an approved technical means of regulatory compliance.

AFAIK, no one runs IP over ADS-B, which was designed as a narrowband
application specific communications stovepipe, not a data link
supporting higher layer network protocols, so not great for IP.

More importantly, we have no "reluctance about the use of... IP", which
is an entirely separate issue from ADS-B.

On 8/4/2020 9:52 AM, Alexandre Petrescu wrote:
architectural layers discussion...

Le 30/07/2020 à 11:49, shuaiizhao(Shuai Zhao) a écrit :
Just to echo Stu on the ADSB, AFAIK, ADSB will  not be feasible for
most of the drones mostly due to SwaP, commercial drones might be
exception.

It might be that ADS-B might be forbidden in drones on Earth, but how
about the drones on Mars? ('NASA Mars helicopters', or ESA too).  On
Mars there would be much less such drones, so less risk of interference.

With such a system (ADS-B under IP) one could re-use DTN (Delay Tolerant
Networking) between planets, and so identify drones even on Mars.

But if we have reluctance about the use of ADS-B, and thus of IP, and we
recommend Bluetooth-without-IP to identify drones, then we might become
too dependent on it?

(do not get me wrong, I do like Bluetooth, but I like many other things
together with Bluetooth).

Alex


Best,

Shuai Zhao

*From: *Tm-rid <tm-rid-bounces@ietf.org> on behalf of "Stuart W.
Card" <stu.card@axenterprize.com> *Date: *Wednesday, July 29, 2020 at
19:46 *To: *"tm-rid@ietf.org" <tm-rid@ietf.org> *Subject: *[Drip]
ADSB (was: Review of draft-drip-arch-02 w.r.t. RFC6973, RFC8280 and
other)(Internet mail)

Sorry for the slow reply.

ADS-B is gradually being mandated for essentially all manned
aircraft.

ADSB-In and ADSB-Out are mandated for airliners: -In gives their
pilots

some Situational Awareness (SA) of other aircraft; -Out gives other

pilots SA of the airliners.

"ADSB-Out" is mandated even for small general aviation aircraft: it
does

not directly benefit the pilots of those aircraft; but by providing
SA

to others, it indirectly benefits all.

ADSB is _not_ going to be deployed on large numbers of small UAS as
it

would overwhelm the limited bandwidth available at those lower radio

frequencies (which propagate long ranges). In fact, it is expected to
be

explicitly prohibited in the US per the FAA NPRM; I suspect most of
the

rest of the world will do likewise.

ADSB is also altogether insecure.

On 7/9/2020 3:02 AM, Alexandre Petrescu wrote:

...

They call it "ADS-B Receivers" (Automatic Dependent Surveillance -

Broadcast).

I wouuld like to ask if there is a packet dump available showing
such

presence data form planes?  Maybe wireshark already supports it,
maybe

it even dissects it...

-- 

-----------------------------------------

Stuart W. Card, PhD, Principal Engineer

AX Enterprize, LLC  www.axenterprize.com

4947 Commercial Drive, Yorkville NY 13495








--
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
--------------730F1DEBFF6E87651AF0643F-- From nobody Tue Aug 4 08:53:35 2020 Return-Path: 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 9F1333A0A3B for ; Tue, 4 Aug 2020 08:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, 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 fqY7_iMaLTFx for ; Tue, 4 Aug 2020 08:53:31 -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 ADBDB3A0A12 for ; Tue, 4 Aug 2020 08:53:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 5B9BA62434; Tue, 4 Aug 2020 11:53:30 -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 6HDxluGQb5p2; Tue, 4 Aug 2020 11:53:20 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (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 B978362415; Tue, 4 Aug 2020 11:53:19 -0400 (EDT) To: Alexandre Petrescu , tm-rid@ietf.org References: <1bebf5b1-1fa5-6902-5bb7-9ec3582e6d9a@andersdotter.cc> <2990FBF0-FCB0-49CE-8F4B-BF5111CE5D57@tzi.org> <01a21161-aa8d-6d4b-b384-3129fe6d799b@gmail.com> <973223fd-0119-376d-12cd-21559a14ce87@labs.htt-consult.com> <3c632ce9-115d-11f5-ee33-bfabd4973522@labs.htt-consult.com> <7ddd9a2f-23ba-dd82-8cfb-1d2974969e67@gmail.com> <61511ef6-5b9b-5b62-f922-d32b994a35b9@gmail.com> From: Robert Moskowitz Message-ID: <34a78f0e-46ed-584e-492e-f729d2f01ef4@labs.htt-consult.com> Date: Tue, 4 Aug 2020 11:53:19 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <61511ef6-5b9b-5b62-f922-d32b994a35b9@gmail.com> Content-Type: multipart/alternative; boundary="------------AC7C4273E38D797F448F4D75" Content-Language: en-US Archived-At: Subject: Re: [Drip] ADSB X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 15:53:35 -0000 This is a multi-part message in MIME format. --------------AC7C4273E38D797F448F4D75 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 8/4/20 11:27 AM, Alexandre Petrescu wrote: > Thanks for the clarification. > > Le 04/08/2020 à 17:17, Stuart W. Card a écrit : >> I just want to respond to one line that I think comes from confusion: >> >>> But if we have reluctance about the use of ADS-B, and thus of IP, >>> and we recommend Bluetooth-without-IP to identify drones >> >> We aren't recommending Bluetooth-without-IP, we are _supporting_ it, > > But, the security manifest that I have seen on slides during the > presentation of the DRIP WG meeting - is something below IP, right? > Oh, and for Network Remote ID and C2 see my draft: draft-moskowitz-drip-secure-nrid-c2 > Alex > >  as >> it is specified in ASTM F3411, which most of the regulators are dubbing >> as an approved technical means of regulatory compliance. >> >> AFAIK, no one runs IP over ADS-B, which was designed as a narrowband >> application specific communications stovepipe, not a data link >> supporting higher layer network protocols, so not great for IP. >> >> More importantly, we have no "reluctance about the use of... IP", which >> is an entirely separate issue from ADS-B. >> >> On 8/4/2020 9:52 AM, Alexandre Petrescu wrote: >>> architectural layers discussion... >>> >>> Le 30/07/2020 à 11:49, shuaiizhao(Shuai Zhao) a écrit : >>>> Just to echo Stu on the ADSB, AFAIK, ADSB will  not be feasible for >>>> most of the drones mostly due to SwaP, commercial drones might be >>>> exception. >>> >>> It might be that ADS-B might be forbidden in drones on Earth, but how >>> about the drones on Mars? ('NASA Mars helicopters', or ESA too).  On >>> Mars there would be much less such drones, so less risk of >>> interference. >>> >>> With such a system (ADS-B under IP) one could re-use DTN (Delay >>> Tolerant >>> Networking) between planets, and so identify drones even on Mars. >>> >>> But if we have reluctance about the use of ADS-B, and thus of IP, >>> and we >>> recommend Bluetooth-without-IP to identify drones, then we might become >>> too dependent on it? >>> >>> (do not get me wrong, I do like Bluetooth, but I like many other things >>> together with Bluetooth). >>> >>> Alex >>> >>>> >>>> Best, >>>> >>>> Shuai Zhao >>>> >>>> *From: *Tm-rid on behalf of "Stuart W. >>>> Card" *Date: *Wednesday, July 29, 2020 at >>>> 19:46 *To: *"tm-rid@ietf.org" *Subject: *[Drip] >>>> ADSB (was: Review of draft-drip-arch-02 w.r.t. RFC6973, RFC8280 and >>>> other)(Internet mail) >>>> >>>> Sorry for the slow reply. >>>> >>>> ADS-B is gradually being mandated for essentially all manned >>>> aircraft. >>>> >>>> ADSB-In and ADSB-Out are mandated for airliners: -In gives their >>>> pilots >>>> >>>> some Situational Awareness (SA) of other aircraft; -Out gives other >>>> >>>> pilots SA of the airliners. >>>> >>>> "ADSB-Out" is mandated even for small general aviation aircraft: it >>>> does >>>> >>>> not directly benefit the pilots of those aircraft; but by providing >>>> SA >>>> >>>> to others, it indirectly benefits all. >>>> >>>> ADSB is _not_ going to be deployed on large numbers of small UAS as >>>> it >>>> >>>> would overwhelm the limited bandwidth available at those lower radio >>>> >>>> frequencies (which propagate long ranges). In fact, it is expected to >>>> be >>>> >>>> explicitly prohibited in the US per the FAA NPRM; I suspect most of >>>> the >>>> >>>> rest of the world will do likewise. >>>> >>>> ADSB is also altogether insecure. >>>> >>>> On 7/9/2020 3:02 AM, Alexandre Petrescu wrote: >>>> >>>> ... >>>> >>>> They call it "ADS-B Receivers" (Automatic Dependent Surveillance - >>>> >>>> Broadcast). >>>> >>>> I wouuld like to ask if there is a packet dump available showing >>>> such >>>> >>>> presence data form planes?  Maybe wireshark already supports it, >>>> maybe >>>> >>>> it even dissects it... >>>> >>>> -- >>>> >>>> ----------------------------------------- >>>> >>>> Stuart W. Card, PhD, Principal Engineer >>>> >>>> AX Enterprize, LLC  www.axenterprize.com >>>> >>>> 4947 Commercial Drive, Yorkville NY 13495 >>>> >>>> >>> >> >> >> > -- 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 --------------AC7C4273E38D797F448F4D75 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 8/4/20 11:27 AM, Alexandre Petrescu wrote:
Thanks for the clarification.

Le 04/08/2020 à 17:17, Stuart W. Card a écrit :
I just want to respond to one line that I think comes from confusion:

But if we have reluctance about the use of ADS-B, and thus of IP,
and we recommend Bluetooth-without-IP to identify drones

We aren't recommending Bluetooth-without-IP, we are _supporting_ it,

But, the security manifest that I have seen on slides during the presentation of the DRIP WG meeting - is something below IP, right?


Oh, and for Network Remote ID and C2 see my draft:

draft-moskowitz-drip-secure-nrid-c2

Alex

 as
it is specified in ASTM F3411, which most of the regulators are dubbing
as an approved technical means of regulatory compliance.

AFAIK, no one runs IP over ADS-B, which was designed as a narrowband
application specific communications stovepipe, not a data link
supporting higher layer network protocols, so not great for IP.

More importantly, we have no "reluctance about the use of... IP", which
is an entirely separate issue from ADS-B.

On 8/4/2020 9:52 AM, Alexandre Petrescu wrote:
architectural layers discussion...

Le 30/07/2020 à 11:49, shuaiizhao(Shuai Zhao) a écrit :
Just to echo Stu on the ADSB, AFAIK, ADSB will  not be feasible for
most of the drones mostly due to SwaP, commercial drones might be
exception.

It might be that ADS-B might be forbidden in drones on Earth, but how
about the drones on Mars? ('NASA Mars helicopters', or ESA too).  On
Mars there would be much less such drones, so less risk of interference.

With such a system (ADS-B under IP) one could re-use DTN (Delay Tolerant
Networking) between planets, and so identify drones even on Mars.

But if we have reluctance about the use of ADS-B, and thus of IP, and we
recommend Bluetooth-without-IP to identify drones, then we might become
too dependent on it?

(do not get me wrong, I do like Bluetooth, but I like many other things
together with Bluetooth).

Alex


Best,

Shuai Zhao

*From: *Tm-rid <tm-rid-bounces@ietf.org> on behalf of "Stuart W.
Card" <stu.card@axenterprize.com> *Date: *Wednesday, July 29, 2020 at
19:46 *To: *"tm-rid@ietf.org" <tm-rid@ietf.org> *Subject: *[Drip]
ADSB (was: Review of draft-drip-arch-02 w.r.t. RFC6973, RFC8280 and
other)(Internet mail)

Sorry for the slow reply.

ADS-B is gradually being mandated for essentially all manned
aircraft.

ADSB-In and ADSB-Out are mandated for airliners: -In gives their
pilots

some Situational Awareness (SA) of other aircraft; -Out gives other

pilots SA of the airliners.

"ADSB-Out" is mandated even for small general aviation aircraft: it
does

not directly benefit the pilots of those aircraft; but by providing
SA

to others, it indirectly benefits all.

ADSB is _not_ going to be deployed on large numbers of small UAS as
it

would overwhelm the limited bandwidth available at those lower radio

frequencies (which propagate long ranges). In fact, it is expected to
be

explicitly prohibited in the US per the FAA NPRM; I suspect most of
the

rest of the world will do likewise.

ADSB is also altogether insecure.

On 7/9/2020 3:02 AM, Alexandre Petrescu wrote:

...

They call it "ADS-B Receivers" (Automatic Dependent Surveillance -

Broadcast).

I wouuld like to ask if there is a packet dump available showing
such

presence data form planes?  Maybe wireshark already supports it,
maybe

it even dissects it...

-- 

-----------------------------------------

Stuart W. Card, PhD, Principal Engineer

AX Enterprize, LLC  www.axenterprize.com

4947 Commercial Drive, Yorkville NY 13495








--
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
--------------AC7C4273E38D797F448F4D75-- From nobody Tue Aug 4 10:12:13 2020 Return-Path: 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 E8A0B3A0D7A for ; Tue, 4 Aug 2020 10:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 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, NICE_REPLY_A=-0.949, 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=axenterprize.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 bnu91b1dUAbx for ; Tue, 4 Aug 2020 10:12:10 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 200FF3A0D78 for ; Tue, 4 Aug 2020 10:12:09 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id g26so39119094qka.3 for ; Tue, 04 Aug 2020 10:12:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axenterprize.com; s=google; h=to:references:from:autocrypt:subject:message-id:date:user-agent :mime-version:in-reply-to; bh=k4aXaMVtCA+F3Q7yXlZVG6qRIBsPB8Tp+Dv1yHRNEEQ=; b=RoW2aYNJN2TC7X5li/0i2Q3VN6QnUk9Ca3jk4qLBIsEVQmWceyHTJ9qfKPlIMdpRrz 6i+e7pkA9AEULMeRE81lHGpv/iqpUB0kGYKc2DdmFNXu4BpFyRu2UJaS1gi6sf+4IlPt wMQXajbHZl8nV1YUyi4cMaEBqzx9Wo0LF7LYQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:references:from:autocrypt:subject:message-id :date:user-agent:mime-version:in-reply-to; bh=k4aXaMVtCA+F3Q7yXlZVG6qRIBsPB8Tp+Dv1yHRNEEQ=; b=L1xe30xpKZAXUrj99L46TR3ATfOkY9tYMaFSlvGf5w834yMsftrxYWUNqTPe/U+MbK eIyFOzsXWjO61o3wRFzZoMlaZEkzQU/MVlGw9BExYZnJt5iD1taKdcL62lWcm34SN1io 1SyQqeBxZifNNio+5lxyfjmijMkHeP8DujOuo3DuHVdhf9zM/vnP75hG68Qcl72pxqqS EeZDA1P7RbPeUz0MGkGZUrHx/DXR4nShQSKWQgMWpaThfpT14ThQfjZTHDE9dJlVfNpZ RL/hxLyIfCEY0dqQ7QItzINa26enmPBqppWsMQumu+ZR68K83yQMFyTmwC0ANMb+iBP0 pAnQ== X-Gm-Message-State: AOAM531juTAyw2XMl3vxUafTRFRwXNEGysrmoMrG9K3+g2owYolICX9k DE3QJ3zIG4zY0sPselixKcSLQOTpbmKMUg== X-Google-Smtp-Source: ABdhPJwVFPcgacSDoviwNFKpRyCWqxcgRNemGv/yDD+/k15L38NRSbOJ5N3u2BVrpn2YjCYOYo9Mhg== X-Received: by 2002:ae9:e407:: with SMTP id q7mr21963547qkc.451.1596561128456; Tue, 04 Aug 2020 10:12:08 -0700 (PDT) Received: from [192.168.1.107] (ip-72-10-210-250.nwptny.ntcnet.net. [72.10.210.250]) by smtp.gmail.com with ESMTPSA id q2sm25768837qtl.64.2020.08.04.10.12.07 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 Aug 2020 10:12:07 -0700 (PDT) To: tm-rid@ietf.org References: <1bebf5b1-1fa5-6902-5bb7-9ec3582e6d9a@andersdotter.cc> <2990FBF0-FCB0-49CE-8F4B-BF5111CE5D57@tzi.org> <01a21161-aa8d-6d4b-b384-3129fe6d799b@gmail.com> <973223fd-0119-376d-12cd-21559a14ce87@labs.htt-consult.com> <3c632ce9-115d-11f5-ee33-bfabd4973522@labs.htt-consult.com> <7ddd9a2f-23ba-dd82-8cfb-1d2974969e67@gmail.com> <61511ef6-5b9b-5b62-f922-d32b994a35b9@gmail.com> From: "Stuart W. Card" Autocrypt: addr=stu.card@axenterprize.com; prefer-encrypt=mutual; keydata= mQGiBDpARp4RBADNQipCkPP9uNjzow8Fyltan7Fsc1obeYCZsHmKB3J9GkjAOISXeg5ce7PG NxugbgU1pAkhU6bARdTYFllKGz7WP8cwRVzQvwNbDLowPImeaRFsSOSU3T1RSzAC4vIRv7Q2 amQkSZLSh105f4whqkR1QqFUPqamhxHy2itg+zUSowCg/13xoiFRCbhzEq3MaiKrHd/wyM0D /3fHb4CyuIe5c5iz+Jh4h9MSLvKnWeGzRaokBSrJj3sJf2foSWFrx8lmib0Sgzrpb1/s5c+f eE6N444bAEnGEnCwmHaFdCebTif/8t4ZPVZqGEHIye4fpegcsQwkzcIyKp7mM1KjpcfsBOg+ AKhiuBUKCkYdzg1DQiKfyiJRgXcvA/4tb35LGbLOLgRWOO78hy293tAeE+bQKa9GYKaOCk8L Gadddjh4oTrW+KUnyas/jbl6V5ZArXLgS9qwniVT8VD8f/w0C4opJGyNMmMRWGGR139STrLy dxK5uMdqSufP3ppCrZaBhMxw9e93GuuDzxftVw1N0mBpjSidsqnQoLJiN7QvU3R1YXJ0IFdp bGxpYW0gQ2FyZCA8c3R1LmNhcmRAYXhlbnRlcnByaXplLmNvbT6IeAQTEQIAOBYhBDbKqfE+ xHVTMRc+Kkuz0NGtsHi+BQJfA2S+AhsjBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEEuz 0NGtsHi+lhsAoJqGqvLU5IEt1nahjQ8Gdtmk6NtFAKCKkEpLa3gyKUxJtpjq/TfPk11YLrkE DQQ6QEaeEBAA+RigfloGYXpDkJXcBWyHhuxh7M1FHw7Y4KN5xsncegus5D/jRpS2MEpT13wC FkiAtRXlKZmpnwd00//jocWWIE6YZbjYDe4QXau2FxxR2FDKIldDKb6V6FYrOHhcC9v4TE3V 46pGzPvOF+gqnRRh44SpT9GDhKh5tu+Pp0NGCMbMHXdXJDhK4sTw6I4TZ5dOkhNh9tvrJQ4X /faY98h8ebByHTh1+/bBc8SDESYrQ2DD4+jWCv2hKCYLrqmus2UPogBTAaB81qujEh76DyrO H3SET8rzF/OkQOnX0ne2Qi0CNsEmy2henXyYCQqNfi3t5F159dSST5sYjvwqp0t8MvZCV7cI fwgXcqK61qlC8wXo+VMROU+28W65Szgg2gGnVqMU6Y9AVfPQB8bLQ6mUrfdMZIZJ+AyDvWXp F9Sh01D49Vlf3HZSTz09jdvOmeFXklnN/biudE/F/Ha8g8VHMGHOfMlm/xX5u/2RXscBqtNb no2gpXI61Brwv0YAWCvl9Ij9WE5J280gtJ3kkQc2azNsOA1FHQ98iLMcfFstjvbzySPAQ/Cl WxiNjrtVjLhdONM0/XwXV0OjHRhs3jMhLLUq/zzhsSlAGBGNfISnCnLWhsQDGcgHKXrKlQzZ lp+r0ApQmwJG0wg9ZqRdQZ+cfL2JSyIZJrqrol7DVes91hcAAgIQAMNvvhEBqOLNS6qAtj+V xdIJR3zWR/ocrre94V8TZWrdiblN8tbJWBsVAUVjhQB04ygXO5RbpyDpMCMimnzLQ95immw5 vyoL+iqbCHGmlr/BBvJUUc3BvbERona1MZ7Bt+fe9n6Tc1ipyDNzkguk0mEAgsoRHtLb7TsT eUU7TrWbmutBjxmjUBad9yVNV0QAlnYQBS1t01OkeYqRMS3YxRLAF097VTOR+WHw3e8m9zMh ZQAuC3Delii8QT4vzVqIiLdW8wwHgHz1qM5hhZVU4La5jnvtrUbFvxc5cLvREAGuAjW4JXgN h1OD6zWlXXTwiyfrHDWEIMMAXIYVYgYWgT83FB0ddsCDD7H5+8sGjuqZ/J+XF8l2BQDnQGK2 9Ht6jBRH8CfG0uwG9yVTNc+LgewR9/Ub8/UudxWyuK0pbFWQr1bAeJ3hwnGYIedvcAdFXcQo rVbCd5ayhBVht8wyCK2JlgNa2Zq+30ymyZJKb8zBhwNtrNczegjn3EgIRBRCxZdh7uCRyZFL Sdz2QJ6Q8RqldorNWGUnB2Jhbkiq3/0P99F0CwlhSLmHiJAOodCB6oIYfU3WqAqrHtutSccd 7V6t+D3slaOptqXcJb0Q06xuccwzYmEIu6mqxBuawjPoAZNGcx3kSJab6cd5TayXR586ik5q HOJmlZ8e43TbCjSpiEYEGBECAAYFAjpARp4ACgkQS7PQ0a2weL65HgCePHJT7ryvg2LwPGgK 0yVFIpzmWa0AnjgpvFwf0EHDFhjEr8y2AnKzNN2X Message-ID: Date: Tue, 4 Aug 2020 13:11:52 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <61511ef6-5b9b-5b62-f922-d32b994a35b9@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hxDcdLwJfMnOhwQiV0dAbxjSOI49o7CEy" Archived-At: Subject: Re: [Drip] ADSB X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 17:12:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hxDcdLwJfMnOhwQiV0dAbxjSOI49o7CEy Content-Type: multipart/mixed; boundary="TRNJJ8tqwOtw8mQnw4eI8wbwYr0KZCohn"; protected-headers="v1" From: "Stuart W. Card" To: tm-rid@ietf.org Message-ID: Subject: Re: [Drip] ADSB References: <1bebf5b1-1fa5-6902-5bb7-9ec3582e6d9a@andersdotter.cc> <2990FBF0-FCB0-49CE-8F4B-BF5111CE5D57@tzi.org> <01a21161-aa8d-6d4b-b384-3129fe6d799b@gmail.com> <973223fd-0119-376d-12cd-21559a14ce87@labs.htt-consult.com> <3c632ce9-115d-11f5-ee33-bfabd4973522@labs.htt-consult.com> <7ddd9a2f-23ba-dd82-8cfb-1d2974969e67@gmail.com> <61511ef6-5b9b-5b62-f922-d32b994a35b9@gmail.com> In-Reply-To: <61511ef6-5b9b-5b62-f922-d32b994a35b9@gmail.com> --TRNJJ8tqwOtw8mQnw4eI8wbwYr0KZCohn Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable The proposed manifest and other DRIP authentication related structures are all independent of transport, but designed to work with the most constraining transport thus specified by regulators and/or other SDOs, that being ASTM F3411 Broadcast RID over Bluetooth 4. So, for Broadcast RID, they would be encapsulated in ASTM F3411 messages over Bluetooth 4, Bluetooth 5 or WiFi Neighbor Awareness Networking (without IP). For Network RID, they could be carried in any IP based transport, HTTPS/TCP/IP initially (although, for Network RID, some of them are superfluous). On 8/4/2020 11:27 AM, Alexandre Petrescu wrote: > Thanks for the clarification. >=20 > Le 04/08/2020 =C3=A0 17:17, Stuart W. Card a =C3=A9crit=C2=A0: >> I just want to respond to one line that I think comes from confusion: >> >>> But if we have reluctance about the use of ADS-B, and thus of IP, >>> and we recommend Bluetooth-without-IP to identify drones >> >> We aren't recommending Bluetooth-without-IP, we are _supporting_ it, >=20 > But, the security manifest that I have seen on slides during the > presentation of the DRIP WG meeting - is something below IP, right? --=20 ----------------------------------------- Stuart W. Card, PhD, Principal Engineer AX Enterprize, LLC www.axenterprize.com 4947 Commercial Drive, Yorkville NY 13495 --TRNJJ8tqwOtw8mQnw4eI8wbwYr0KZCohn-- --hxDcdLwJfMnOhwQiV0dAbxjSOI49o7CEy Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQ2yqnxPsR1UzEXPipLs9DRrbB4vgUCXymW2AAKCRBLs9DRrbB4 volLAKCLvNsyVoOOv7LSZsIga7vIuFkZFwCgwywrBkZxiOhnO9goWSQfrHB1fsE= =88w/ -----END PGP SIGNATURE----- --hxDcdLwJfMnOhwQiV0dAbxjSOI49o7CEy-- From nobody Wed Aug 5 02:14:07 2020 Return-Path: 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 789093A15E4 for ; Wed, 5 Aug 2020 02:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 FG2qHNPyk8-w for ; Wed, 5 Aug 2020 02:13:59 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BAAE3A145B for ; Wed, 5 Aug 2020 02:13:31 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by opfedar27.francetelecom.fr (ESMTP service) with ESMTPS id 4BM5Ws6KK5z2xFs; Wed, 5 Aug 2020 11:13:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1596618809; bh=lH2OVyuOa7Ws0Fy+rib9/1hTIMJxpMPDUGWenkvh4cE=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=kINeGmndiwLD7GyFW0bIJ5FDO3uOxH3tLmPa4DiAlUWcy5k2kolpMzUCPlVw58CQh 5Zn7fCPYWKeVQjK5am6fogSBbW2gNUltG1KT1+H/JfnypdWpUScRzjDswBYFG8mmcR TuqwmwI+12kshBZz1enOaWwDzHBGIZCD7uHOFPNqScLn6aOy0tLRgImc5+/el0A5pG uMGx9YyJFLwooQ9bjidVo8JYI8KdOiFwTKpkIxStBeUuuNsPm85nJnQOY/X6d22yd2 exCcbhBJdYMCrmziQSMGzplyVd8PfwEBYu9A0ptINl1AkhBXn+ymBztK/I3pYdQoiO VtoHhYmKhvmaw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by opfedar00.francetelecom.fr (ESMTP service) with ESMTPS id 4BM5Ws5Q1TzCqkC; Wed, 5 Aug 2020 11:13:29 +0200 (CEST) From: To: "Stuart W. Card" CC: "tm-rid@ietf.org" Thread-Topic: [Drip] ADSB Thread-Index: AQHWanJQKX8D7WRcqU6X/URQrOkY7Kkn8S0AgAAdGACAASwQIA== Date: Wed, 5 Aug 2020 09:13:29 +0000 Message-ID: <18020_1596618809_5F2A7839_18020_102_1_787AE7BB302AE849A7480A190F8B9330315183A1@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <1bebf5b1-1fa5-6902-5bb7-9ec3582e6d9a@andersdotter.cc> <2990FBF0-FCB0-49CE-8F4B-BF5111CE5D57@tzi.org> <01a21161-aa8d-6d4b-b384-3129fe6d799b@gmail.com> <973223fd-0119-376d-12cd-21559a14ce87@labs.htt-consult.com> <3c632ce9-115d-11f5-ee33-bfabd4973522@labs.htt-consult.com> <7ddd9a2f-23ba-dd82-8cfb-1d2974969e67@gmail.com> <61511ef6-5b9b-5b62-f922-d32b994a35b9@gmail.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Drip] ADSB X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 09:14:06 -0000 SGkgU3R1LCANCg0KSSByZW1lbWJlciB0aGF0IEFuZHJlaSByYWlzZWQgaW4gdGhlIHBhc3QgYSBx dWVzdGlvbiBhYm91dCB0aGUgdXNlIG9mIEFEQi1TLiBJIHN1c3BlY3QgdGhhdCBvdGhlcnMgbWF5 IG1ha2UgYSBzaW1pbGFyIGNvbW1lbnQgaW4gdGhlIGZ1dHVyZS4NCkhhdmluZyBzb21lIHRleHQg aW4gZHJhZnQtaWV0Zi1kcmlwLWFyY2ggcmVmbGVjdGluZyB0aGUgbWFpbiBhcmd1bWVudHMgc2hh cmVkIGluIHRoaXMgdGhyZWFkIChieSBTaHVhaSwgQm9iLCBTdGVwaGFuLCB5b3UpIHdpbGwgYmUg dXNlZnVsLiANCg0KQ2FuIHlvdSBwbGVhc2UgY29uc2lkZXIgYWRkaW5nIHN1Y2ggdGV4dCB0byB0 aGUgZHJhZnQ/IA0KDQpUaGFuayB5b3UuIA0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1lc3Nh Z2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogVG0tcmlkIFttYWlsdG86dG0tcmlkLWJvdW5jZXNA aWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgU3R1YXJ0IFcuDQo+IENhcmQNCj4gRW52b3nDqcKgOiBt YXJkaSA0IGFvw7t0IDIwMjAgMTk6MTINCj4gw4DCoDogdG0tcmlkQGlldGYub3JnDQo+IE9iamV0 wqA6IFJlOiBbRHJpcF0gQURTQg0KPiANCj4gVGhlIHByb3Bvc2VkIG1hbmlmZXN0IGFuZCBvdGhl ciBEUklQIGF1dGhlbnRpY2F0aW9uIHJlbGF0ZWQgc3RydWN0dXJlcw0KPiBhcmUgYWxsIGluZGVw ZW5kZW50IG9mIHRyYW5zcG9ydCwgYnV0IGRlc2lnbmVkIHRvIHdvcmsgd2l0aCB0aGUgbW9zdA0K PiBjb25zdHJhaW5pbmcgdHJhbnNwb3J0IHRodXMgc3BlY2lmaWVkIGJ5IHJlZ3VsYXRvcnMgYW5k L29yIG90aGVyIFNET3MsDQo+IHRoYXQgYmVpbmcgQVNUTSBGMzQxMSBCcm9hZGNhc3QgUklEIG92 ZXIgQmx1ZXRvb3RoIDQuDQo+IA0KPiBTbywgZm9yIEJyb2FkY2FzdCBSSUQsIHRoZXkgd291bGQg YmUgZW5jYXBzdWxhdGVkIGluIEFTVE0gRjM0MTENCj4gbWVzc2FnZXMgb3ZlciBCbHVldG9vdGgg NCwgQmx1ZXRvb3RoIDUgb3IgV2lGaSBOZWlnaGJvciBBd2FyZW5lc3MNCj4gTmV0d29ya2luZyAo d2l0aG91dCBJUCkuDQo+IA0KPiBGb3IgTmV0d29yayBSSUQsIHRoZXkgY291bGQgYmUgY2Fycmll ZCBpbiBhbnkgSVAgYmFzZWQgdHJhbnNwb3J0LA0KPiBIVFRQUy9UQ1AvSVAgaW5pdGlhbGx5IChh bHRob3VnaCwgZm9yIE5ldHdvcmsgUklELCBzb21lIG9mIHRoZW0gYXJlDQo+IHN1cGVyZmx1b3Vz KS4NCj4gDQo+IE9uIDgvNC8yMDIwIDExOjI3IEFNLCBBbGV4YW5kcmUgUGV0cmVzY3Ugd3JvdGU6 DQo+ID4gVGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbi4NCj4gPg0KPiA+IExlIDA0LzA4LzIw MjAgw6AgMTc6MTcsIFN0dWFydCBXLiBDYXJkIGEgw6ljcml0wqA6DQo+ID4+IEkganVzdCB3YW50 IHRvIHJlc3BvbmQgdG8gb25lIGxpbmUgdGhhdCBJIHRoaW5rIGNvbWVzIGZyb20NCj4gY29uZnVz aW9uOg0KPiA+Pg0KPiA+Pj4gQnV0IGlmIHdlIGhhdmUgcmVsdWN0YW5jZSBhYm91dCB0aGUgdXNl IG9mIEFEUy1CLCBhbmQgdGh1cyBvZiBJUCwNCj4gPj4+IGFuZCB3ZSByZWNvbW1lbmQgQmx1ZXRv b3RoLXdpdGhvdXQtSVAgdG8gaWRlbnRpZnkgZHJvbmVzDQo+ID4+DQo+ID4+IFdlIGFyZW4ndCBy ZWNvbW1lbmRpbmcgQmx1ZXRvb3RoLXdpdGhvdXQtSVAsIHdlIGFyZSBfc3VwcG9ydGluZ18NCj4g aXQsDQo+ID4NCj4gPiBCdXQsIHRoZSBzZWN1cml0eSBtYW5pZmVzdCB0aGF0IEkgaGF2ZSBzZWVu IG9uIHNsaWRlcyBkdXJpbmcgdGhlDQo+ID4gcHJlc2VudGF0aW9uIG9mIHRoZSBEUklQIFdHIG1l ZXRpbmcgLSBpcyBzb21ldGhpbmcgYmVsb3cgSVAsIHJpZ2h0Pw0KPiANCj4gDQo+IC0tDQo+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFN0dWFydCBXLiBDYXJk LCBQaEQsIFByaW5jaXBhbCBFbmdpbmVlcg0KPiBBWCBFbnRlcnByaXplLCBMTEMgIHd3dy5heGVu dGVycHJpemUuY29tDQo+IDQ5NDcgQ29tbWVyY2lhbCBEcml2ZSwgWW9ya3ZpbGxlIE5ZIDEzNDk1 DQoNCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNv bnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBl dCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMg c2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1 ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWlu c2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRh bnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9u c2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUu IE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29u ZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVk IGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3 aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4g ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBh bmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBu b3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBv ciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Wed Aug 5 02:40:10 2020 Return-Path: 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 88A353A13E3; Wed, 5 Aug 2020 02:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 vYYgExzuNnEX; Wed, 5 Aug 2020 02:40:07 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 169763A13E1; Wed, 5 Aug 2020 02:40:07 -0700 (PDT) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 4BM66Y5nn9z3099; Wed, 5 Aug 2020 11:40:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1596620405; bh=aiogjrmU9fiPdHJRjDgi/OXNjeKdXI9+SzMOLYwMCxk=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=TAb9T+LDKKWDtBETmvPxlSKM+r6THWo/+6bJ5aMUrjhQlXHw9kCX5Z4ADfs7XMLIh dsC5E2XPVvNL09Z56wHtiIy9D/3xDDLyCU50pHiFeWNHQ4msb1UlPlH0ytJ3lsXVVq 1LD8rvvyyxRN5nx6CjYEdaz3RbHXOa8VJtggzjKhoQU28UmcSD3qE8mj0wpA3Duo/9 +F4ybrGhDJL/2d0Hd8rE99gR8tuJ5RV44gUfp6phzWY5l90ASkl9F4E8c647tuDS6m I5OXYRy+PpRrsenff6BkOjqq179l6Ec1AztdHVWJqSbwMASzwNrtlFpv56JCxDoiBq cpiTBAvKUOLUQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.95]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 4BM66Y4mhqzCqkS; Wed, 5 Aug 2020 11:40:05 +0200 (CEST) From: To: "tm-rid@ietf.org" CC: "drip-chairs@ietf.org" Thread-Topic: Future Interims Thread-Index: AdZrC6xE7v3wZ49TT7ics0NBxR/hNw== Date: Wed, 5 Aug 2020 09:40:04 +0000 Message-ID: <9621_1596620405_5F2A7E75_9621_329_19_787AE7BB302AE849A7480A190F8B93303151840F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93303151840FOPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: [Drip] Future Interims X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 09:40:09 -0000 --_000_787AE7BB302AE849A7480A190F8B93303151840FOPEXCAUBMA2corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Future WG interims are scheduled in the following dates: * 2020-08-26 * 2020-09-23 * 2020-10-28 More details can be found at: https://datatracker.ietf.org/wg/drip/meetings/ If you need a slot in one of these meetings, please send your request to dr= ip-chairs@ietf.org. Cheers, Daniel & Med ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_787AE7BB302AE849A7480A190F8B93303151840FOPEXCAUBMA2corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi all,

=  

Future WG interims are scheduled in the following dates:

 

·         2020-08-26

·         2020-09-23

·         2020-10-28

=  

More details can be found at: https://datatrac= ker.ietf.org/wg/drip/meetings/  

 

If you need a slot in one of these meetings, please send you= r request to drip-chairs@ietf.org.

 

Cheers,

Daniel & Med

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_787AE7BB302AE849A7480A190F8B93303151840FOPEXCAUBMA2corp_-- From nobody Wed Aug 5 02:53:32 2020 Return-Path: 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 C4C2F3A140B for ; Wed, 5 Aug 2020 02:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.278 X-Spam-Level: X-Spam-Status: No, score=-0.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.949, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 hCnt_CsfsfgU for ; Wed, 5 Aug 2020 02:53:29 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 83A6A3A13CE for ; Wed, 5 Aug 2020 02:53:29 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0759rRw8002790; Wed, 5 Aug 2020 11:53:27 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0CD15203D01; Wed, 5 Aug 2020 11:53:27 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id F2E65203BFB; Wed, 5 Aug 2020 11:53:26 +0200 (CEST) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0759rQXg004086; Wed, 5 Aug 2020 11:53:26 +0200 From: Alexandre Petrescu To: Stephan Wenger References: <1bebf5b1-1fa5-6902-5bb7-9ec3582e6d9a@andersdotter.cc> <2990FBF0-FCB0-49CE-8F4B-BF5111CE5D57@tzi.org> <01a21161-aa8d-6d4b-b384-3129fe6d799b@gmail.com> <973223fd-0119-376d-12cd-21559a14ce87@labs.htt-consult.com> <3c632ce9-115d-11f5-ee33-bfabd4973522@labs.htt-consult.com> <7ddd9a2f-23ba-dd82-8cfb-1d2974969e67@gmail.com> Cc: "tm-rid@ietf.org" Message-ID: <079a0a22-f46b-b0a7-de41-63cfb2d1574e@gmail.com> Date: Wed, 5 Aug 2020 11:53:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Drip] ADSB X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 09:53:32 -0000 Stephan, Le 04/08/2020 à 17:16, Stephan Wenger a écrit : > Alexandre, > > ADS-B is a 20+ year old technology and offers properties (bandwidth, > security, cost) of a 20 year old technology. That it just recently > sees widespread adoption is a result of incredibly slow (even by > IETF standards) deployment process, and that in turn is the result of > the very conservative and safety conscious aviation community and > regulators, as well as the high cost related to anything manmade > that flies. By speculating to use ADS-B as an underlying technology > for IP, I fear you demonstrate a certain lack of background. The > Wikipedia article on ADS-B > (https://en.wikipedia.org/wiki/Automatic_dependent_surveillance_–_broadcast) > > > > is mostly correct, and I recommend in particular the sections on > "Theory of operation" and "System Design Considerations". There is no worry to fear I demonstrate lack of background in this field. It is true. I still need to learn many things here. I continue to look for a wireless link layer that is well adapted for communication between flying devices (drones, flying taxis) and ground. And that would support very well IP. Maybe ADS-B is not that link, but Bluetooth isnt it either because too low power. Maybe WiFi at 5.4GHz, which also used for remote control. That aside, let me try to answer some of the points below. > A few (of many) reasons why ADS-B is unsuitable for light drones > (anything significantly smaller than a man-carrying aircraft): -24 > bit ICAO transponder code, limiting the number of (active or > inactive) ADS-B equipment. Each modern aircraft over a certain size > (except the smallest two-seaters, powered parachutes, and aircraft > without electrical systems such as antiques) has a unique code > assigned for its lifetime. Ok. But MAC addresses of Bluetooth also are limited. They have 48bit which is more than 24bit of ADS-B, but it is still limited. > -line-of-sight wireless connection for the "uplink" with only a few > hundred ground stations for the whole US (or 70 for the whole > Australia). That means ADS-B coverage is almost everywhere only > available at altitudes in which small drones are neither legal nor, > in most cases, physically capable to fly (a few thousand feet in the > US except near major airports where you don't want drones, 30000 ft > in Australia). Aircraft send over the uplink information such as > aircraft ICAO code, aircraft type, speed, direction of flight, > altitude, etc.). Information is sent in the clear, by design. You > can buy a box receiving this info, hook it up to an Raspberry PI or > something, and look at the traffic near your house and send it on to > your friends--in fact, this type of crowdsourced ATC info is what > makes flightradar24 and similar sites work. This sounds like an argument in favor of using ADS-B for identification, not against. Or maybe I dont understand. Only a few ground stations: I suspect this is around airport areas, which is good. ADS-B messages sent by the ground stations only to altitudes where drones are forbidden (I suspect above 150m or so): I dont think it is possible to restrict the altitude at which a message is sent to. It would be impossible for an ADS-B message sent by a ground station to not be heard at 100meters and only be heard at 200meters. Or I do not udnertsand. Planes that send ADS-B messages over the 'uplink'. I think I have to understand this better. Until now I thought 'uplink' means a direction from ground to up in the sky. It is a distinct meaning than networking. In networking, a smartphone has an uplink, but the base-station also has an uplink. One's uplink is the other's downlink. Compared to that, I thought that in ADS-B the 'uplink' is only from ground up, but it seems to not be so. > -the downlink (system to aircraft) Again, I thought the 'downlink' is from the plane down to ground. You seem to say it reversely. I think the notion of 'uplink' and 'downlink' are with respect to a device. A device's uplink is the other device's downlink, when they communicate with each other. > is bandwidth-limited to a few hundred kbit/s for all aircraft > combined in the coverage of the satellite transponder. (This is > somewhat over-simplified, as the uplink is intentionally sent in the > clear, and many ADS-B receivers monitor the uplink of other aircraft > for redundancy and more up-to-date information about traffic; see > abive.) AFAIK, the whole continental US is covered by less than 20 > transponders. N The downlink carries not only traffic information > but also cruise and airport weather, certain airspace restrictions, > and so forth. All this is broadcasted and the ADS-B receivers in > the aircraft need to filter out the information relevant for its > position, course, and intentions. Already, the bandwidth available > is almost fully utilized to the point that the broadcast > occasionally needs to omit certain less-critical information to make > space for more critical one. The system scales only by adding > satellite transponders, which is expensive and not a fine > granularity. I agree there might be bandwidth limitation that needs to be respected. It still is that putting an IP message on it can still work. > As for Mars, ADS-B is unsuitable until someone builds a > ground-station network and has suitable satellites in orbit. YEs, the ground station would be on the rover and the satellite would be on one of the stations (I dont know their names) that currently hover above Mars routinely. > A bit closer to earth, for over-water and trans-pole operations > there is ADS-C, which is completely satellite based and, AFAIK, even > more bandwidth limited than ADS-B. Yet another example for a network > unsuitable to carry IP traffic, but I digress. > > In short, forget ADS-B for the DRIP work.. Ok, if no ADS-B for DRIP work, then Bluetooth? Is it more appropriate? Knowing that Bluetooth has a typical range of 10meter (I mean distance range), is it reasonable to rely on it for identifying drones at several hundred meters away? Knowing that Bluetooth is lower power than WiFi at 5.4Ghz, and that that 5.4GHz is already used to control drone flight, video, etc, is it preferrable to use Bluetooth instead of that WiFi at 5.4GHz? Alex > > Stephan > > > On 8/4/20, 6:53 AM, "Tm-rid on behalf of Alexandre Petrescu" > > wrote: > > architectural layers discussion... > > Le 30/07/2020 à 11:49, shuaiizhao(Shuai Zhao) a écrit : >> Just to echo Stu on the ADSB, AFAIK, ADSB will not be feasible >> for most of the drones mostly due to SwaP, commercial drones might >> be exception. > > It might be that ADS-B might be forbidden in drones on Earth, but > how about the drones on Mars? ('NASA Mars helicopters', or ESA too). > On Mars there would be much less such drones, so less risk of > interference. > > With such a system (ADS-B under IP) one could re-use DTN (Delay > Tolerant Networking) between planets, and so identify drones even on > Mars. > > But if we have reluctance about the use of ADS-B, and thus of IP, and > we recommend Bluetooth-without-IP to identify drones, then we might > become too dependent on it? > > (do not get me wrong, I do like Bluetooth, but I like many other > things together with Bluetooth). > > Alex > >> >> Best, >> >> Shuai Zhao >> >> *From: *Tm-rid on behalf of "Stuart W. >> Card" *Date: *Wednesday, July 29, 2020 >> at 19:46 *To: *"tm-rid@ietf.org" *Subject: >> *[Drip] ADSB (was: Review of draft-drip-arch-02 w.r.t. RFC6973, >> RFC8280 and other)(Internet mail) >> >> Sorry for the slow reply. >> >> ADS-B is gradually being mandated for essentially all manned >> aircraft. >> >> ADSB-In and ADSB-Out are mandated for airliners: -In gives their >> pilots >> >> some Situational Awareness (SA) of other aircraft; -Out gives >> other >> >> pilots SA of the airliners. >> >> "ADSB-Out" is mandated even for small general aviation aircraft: >> it does >> >> not directly benefit the pilots of those aircraft; but by >> providing SA >> >> to others, it indirectly benefits all. >> >> ADSB is _not_ going to be deployed on large numbers of small UAS >> as it >> >> would overwhelm the limited bandwidth available at those lower >> radio >> >> frequencies (which propagate long ranges). In fact, it is expected >> to be >> >> explicitly prohibited in the US per the FAA NPRM; I suspect most >> of the >> >> rest of the world will do likewise. >> >> ADSB is also altogether insecure. >> >> On 7/9/2020 3:02 AM, Alexandre Petrescu wrote: >> >> ... >> >> They call it "ADS-B Receivers" (Automatic Dependent Surveillance - >> >> Broadcast). >> >> I wouuld like to ask if there is a packet dump available showing >> such >> >> presence data form planes? Maybe wireshark already supports it, >> maybe >> >> it even dissects it... >> >> -- >> >> ----------------------------------------- >> >> Stuart W. Card, PhD, Principal Engineer >> >> AX Enterprize, LLC www.axenterprize.com >> >> 4947 Commercial Drive, Yorkville NY 13495 >> >> > > -- Tm-rid mailing list Tm-rid@ietf.org > https://www.ietf.org/mailman/listinfo/tm-rid > From nobody Wed Aug 5 03:11:38 2020 Return-Path: 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 A767B3A1411 for ; Wed, 5 Aug 2020 03:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.278 X-Spam-Level: X-Spam-Status: No, score=-0.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.949, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 xFIs_1stfv2E for ; Wed, 5 Aug 2020 03:11:35 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 D4AA03A0C76 for ; Wed, 5 Aug 2020 03:11:34 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 075ABWqw039271; Wed, 5 Aug 2020 12:11:32 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BB71C203D01; Wed, 5 Aug 2020 12:11:32 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id AD34C203915; Wed, 5 Aug 2020 12:11:32 +0200 (CEST) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 075ABWrT012130; Wed, 5 Aug 2020 12:11:32 +0200 To: Robert Moskowitz , tm-rid@ietf.org References: <1bebf5b1-1fa5-6902-5bb7-9ec3582e6d9a@andersdotter.cc> <2990FBF0-FCB0-49CE-8F4B-BF5111CE5D57@tzi.org> <01a21161-aa8d-6d4b-b384-3129fe6d799b@gmail.com> <973223fd-0119-376d-12cd-21559a14ce87@labs.htt-consult.com> <3c632ce9-115d-11f5-ee33-bfabd4973522@labs.htt-consult.com> <7ddd9a2f-23ba-dd82-8cfb-1d2974969e67@gmail.com> <61511ef6-5b9b-5b62-f922-d32b994a35b9@gmail.com> From: Alexandre Petrescu Message-ID: Date: Wed, 5 Aug 2020 12:11:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Drip] ADSB X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 10:11:38 -0000 Le 04/08/2020 à 17:51, Robert Moskowitz a écrit : > > > On 8/4/20 11:27 AM, Alexandre Petrescu wrote: >> Thanks for the clarification. >> >> Le 04/08/2020 à 17:17, Stuart W. Card a écrit : >>> I just want to respond to one line that I think comes from >>> confusion: >>> >>>> But if we have reluctance about the use of ADS-B, and thus of >>>> IP, and we recommend Bluetooth-without-IP to identify drones >>> >>> We aren't recommending Bluetooth-without-IP, we are _supporting_ >>> it, >> >> But, the security manifest that I have seen on slides during the >> presentation of the DRIP WG meeting - is something below IP, >> right? > > For now, we are dealing with broadcast messages. Either over > Bluetooth or WiFI (NAN). If it is a broadcast message and it is over Bluetooth or over WiFi then it certainly is IP multicast, cant be anything else. If it is IP multicast over Bluetooth or over WiFi then I wonder what is the value in the Next Header field of the IP header format (RFC8200 "IPv6", section 3 "Header format"). Basically - what is the payload? If one asks me, I would dare to think that payload might be an ICMPv6 Router Advertisement. > There is NO security for the messages below the message package. Noted. > Just not enough payload size for anything that would work in a > broadcast environment like a National Airspace. All of the security > we are specifying is inside the messages where appropriate. > > That security manifest is a payload of the ASTM F3411-19 > Authentication Message. It costs 85USD I wont pay to see it. It is security. There will always be someone smarter to break that security and ask for more money. I would not oppose if that Authentication MEssage had a specification in clear. > These messages are broadcasted as Adam mentioned in his 'flying DRIP' > comments at the beginning. Thank you for the reminder. I looked again at the 'flying DRIP' presentation during the WG meeting, and at the related draft. https://datatracker.ietf.org/meeting/108/materials/slides-108-drip-authentication-formats and draft-wiethuechter-drip-auth-01 During the presentation, the slide clearly shows on slide 8 that a Bluetooth header immediately precedes an Open Drone ID message. There is no IP header in that slide. In the draft, there is similar discussion tightly related to Bluetooth and without IP. But if we are to have an independence of Bluetooth, and use a networking layer such as IP, then the question of the use of an authentication header is made differently. The authentication header would be an IP Authentication Header. This AH would be somehow re-used and extended where necessary for DRIP purposes. > Now later I expect us to move on to Network Remote ID and Command > and Control (C2). > > Most C2 (e.g. Mavlink) is directly over the MAC, but there is a > method to run it over UDP (I forget the UDP port commonly used...). > AX Enterprize has done this using HIP so the UA starts with WiFi > over the launch point, transitions to LTE, and on return back to > WiFi. > > Network Remote ID can work either directly from the UA, or via C2 > information to the GCS, from the GCS. In either case, IP is > assumed. This will probably be done via UDP. From the UA, mobility > will be important; from the GCS nice to have (most GCS will be stable > location). As UDP to a fixed Net-SP, DTLS 1.3 is a viable > alternative to HIP. I will have to look closer at HIP again :-) and see how it could be made to work with DRIP and IP. Alex > > > > >> >> Alex >> >> as >>> it is specified in ASTM F3411, which most of the regulators are >>> dubbing as an approved technical means of regulatory compliance. >>> >>> AFAIK, no one runs IP over ADS-B, which was designed as a >>> narrowband application specific communications stovepipe, not a >>> data link supporting higher layer network protocols, so not >>> great for IP. >>> >>> More importantly, we have no "reluctance about the use of... >>> IP", which is an entirely separate issue from ADS-B. >>> >>> On 8/4/2020 9:52 AM, Alexandre Petrescu wrote: >>>> architectural layers discussion... >>>> >>>> Le 30/07/2020 à 11:49, shuaiizhao(Shuai Zhao) a écrit : >>>>> Just to echo Stu on the ADSB, AFAIK, ADSB will not be >>>>> feasible for most of the drones mostly due to SwaP, >>>>> commercial drones might be exception. >>>> >>>> It might be that ADS-B might be forbidden in drones on Earth, >>>> but how about the drones on Mars? ('NASA Mars helicopters', or >>>> ESA too). On Mars there would be much less such drones, so >>>> less risk of interference. >>>> >>>> With such a system (ADS-B under IP) one could re-use DTN >>>> (Delay Tolerant Networking) between planets, and so identify >>>> drones even on Mars. >>>> >>>> But if we have reluctance about the use of ADS-B, and thus of >>>> IP, and we recommend Bluetooth-without-IP to identify drones, >>>> then we might become too dependent on it? >>>> >>>> (do not get me wrong, I do like Bluetooth, but I like many >>>> other things together with Bluetooth). >>>> >>>> Alex >>>> >>>>> >>>>> Best, >>>>> >>>>> Shuai Zhao >>>>> >>>>> *From: *Tm-rid on behalf of >>>>> "Stuart W. Card" *Date: >>>>> *Wednesday, July 29, 2020 at 19:46 *To: *"tm-rid@ietf.org" >>>>> *Subject: *[Drip] ADSB (was: Review of >>>>> draft-drip-arch-02 w.r.t. RFC6973, RFC8280 and >>>>> other)(Internet mail) >>>>> >>>>> Sorry for the slow reply. >>>>> >>>>> ADS-B is gradually being mandated for essentially all manned >>>>> aircraft. >>>>> >>>>> ADSB-In and ADSB-Out are mandated for airliners: -In gives >>>>> their pilots >>>>> >>>>> some Situational Awareness (SA) of other aircraft; -Out >>>>> gives other >>>>> >>>>> pilots SA of the airliners. >>>>> >>>>> "ADSB-Out" is mandated even for small general aviation >>>>> aircraft: it does >>>>> >>>>> not directly benefit the pilots of those aircraft; but by >>>>> providing SA >>>>> >>>>> to others, it indirectly benefits all. >>>>> >>>>> ADSB is _not_ going to be deployed on large numbers of small >>>>> UAS as it >>>>> >>>>> would overwhelm the limited bandwidth available at those >>>>> lower radio >>>>> >>>>> frequencies (which propagate long ranges). In fact, it is >>>>> expected to be >>>>> >>>>> explicitly prohibited in the US per the FAA NPRM; I suspect >>>>> most of the >>>>> >>>>> rest of the world will do likewise. >>>>> >>>>> ADSB is also altogether insecure. >>>>> >>>>> On 7/9/2020 3:02 AM, Alexandre Petrescu wrote: >>>>> >>>>> ... >>>>> >>>>> They call it "ADS-B Receivers" (Automatic Dependent >>>>> Surveillance - >>>>> >>>>> Broadcast). >>>>> >>>>> I wouuld like to ask if there is a packet dump available >>>>> showing such >>>>> >>>>> presence data form planes? Maybe wireshark already supports >>>>> it, maybe >>>>> >>>>> it even dissects it... >>>>> >>>>> -- >>>>> >>>>> ----------------------------------------- >>>>> >>>>> Stuart W. Card, PhD, Principal Engineer >>>>> >>>>> AX Enterprize, LLC www.axenterprize.com >>>>> >>>>> 4947 Commercial Drive, Yorkville NY 13495 >>>>> >>>>> >>>> >>> >>> >>> >> > > -- 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 From nobody Wed Aug 5 04:42:20 2020 Return-Path: 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 6009B3A1459 for ; Wed, 5 Aug 2020 04:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, 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 rnPSHJbHTNbz for ; Wed, 5 Aug 2020 04:42:16 -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 062543A1447 for ; Wed, 5 Aug 2020 04:42:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id CBA2762422; Wed, 5 Aug 2020 07:42:13 -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 E8Hmh5bMyJvh; Wed, 5 Aug 2020 07:41:58 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (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 4907062416; Wed, 5 Aug 2020 07:41:58 -0400 (EDT) To: Alexandre Petrescu , Stephan Wenger Cc: "tm-rid@ietf.org" References: <1bebf5b1-1fa5-6902-5bb7-9ec3582e6d9a@andersdotter.cc> <2990FBF0-FCB0-49CE-8F4B-BF5111CE5D57@tzi.org> <01a21161-aa8d-6d4b-b384-3129fe6d799b@gmail.com> <973223fd-0119-376d-12cd-21559a14ce87@labs.htt-consult.com> <3c632ce9-115d-11f5-ee33-bfabd4973522@labs.htt-consult.com> <7ddd9a2f-23ba-dd82-8cfb-1d2974969e67@gmail.com> <079a0a22-f46b-b0a7-de41-63cfb2d1574e@gmail.com> From: Robert Moskowitz Message-ID: Date: Wed, 5 Aug 2020 07:41:54 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <079a0a22-f46b-b0a7-de41-63cfb2d1574e@gmail.com> Content-Type: multipart/alternative; boundary="------------F464D4751F994CCFC9843FFF" Content-Language: en-US Archived-At: Subject: Re: [Drip] ADSB X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 11:42:19 -0000 This is a multi-part message in MIME format. --------------F464D4751F994CCFC9843FFF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 8/5/20 5:53 AM, Alexandre Petrescu wrote: > Stephan, > > Le 04/08/2020 à 17:16, Stephan Wenger a écrit : >> Alexandre, >> >> ADS-B is a 20+ year old technology and offers properties (bandwidth, >>  security, cost) of a 20 year old technology.  That it just recently >>  sees widespread adoption is a result of incredibly slow (even by >> IETF standards) deployment process, and that in turn is the result of >> the very conservative and safety conscious aviation community and >> regulators, as well as the high cost related to anything manmade >> that flies.  By speculating to use ADS-B as an underlying technology >> for IP, I fear you demonstrate a certain lack of background. The >> Wikipedia article on ADS-B >> (https://en.wikipedia.org/wiki/Automatic_dependent_surveillance_–_broadcast) >> >> >> >> > is mostly correct, and I recommend in particular the sections on >> "Theory of operation" and "System Design Considerations". > > There is no worry to fear I demonstrate lack of background in this > field.  It is true.  I still need to learn many things here. > > I continue to look for a wireless link layer that is well adapted > for communication between flying devices (drones, flying taxis) and > ground.  And that would support very well IP. > > Maybe ADS-B is not that link, but Bluetooth isnt it either because too > low power. > > Maybe WiFi at 5.4GHz, which also used for remote control. I recommend you look at IEEE 802.15.16t: http://www.ieee802.org/15/pub/TG16t.html This is actually an addendum to 802.16.  A bit of 802 politics. 802.16 is in hibernation.  802 EC did not want to go through the process and risks of reactivating it for this work.  So they turned over management of the work to the 802.15 leadership. This is licensed spectrum.  The current use cases: https://mentor.ieee.org/802.15/documents?is_dcn=DCN%2C%20Title%2C%20Author%20or%20Affiliation&is_group=016t Does not include aviation, but so what?  Get one of the RF license holders in this business model and you are in business. Some of these frequencies have the bandwidth and range for practical use here. > > That aside, let me try to answer some of the points below. > >> A few (of many) reasons why ADS-B is unsuitable for light drones >> (anything significantly smaller than a man-carrying aircraft): -24 >> bit ICAO transponder code, limiting the number of (active or >> inactive) ADS-B equipment. Each modern aircraft over a certain size >>  (except the smallest two-seaters, powered parachutes, and aircraft >> without electrical systems such as antiques) has a unique code >> assigned for its lifetime. > > Ok.  But MAC addresses of Bluetooth also are limited.  They have 48bit > which is more than 24bit of ADS-B, but it is still limited. > >> -line-of-sight wireless connection for the "uplink" with only a few >> hundred ground stations for the whole US (or 70 for the whole >> Australia).  That means ADS-B coverage is almost everywhere only >> available at altitudes in which small drones are neither legal nor, >> in most cases, physically capable to fly (a few thousand feet in the >> US except near major airports where you don't want drones, 30000 ft >> in Australia).  Aircraft send over the uplink information such as >> aircraft ICAO code, aircraft type, speed, direction of flight, >> altitude, etc.). Information is sent in the clear, by design.  You >> can buy a box receiving this info, hook it up to an Raspberry PI or >> something, and look at the traffic near your house and send it on to >> your friends--in fact, this type of crowdsourced ATC info is what >> makes flightradar24 and similar sites work. > > This sounds like an argument in favor of using ADS-B for identification, > not against.  Or maybe I dont understand. > > Only a few ground stations: I suspect this is around airport areas, > which is good. > > ADS-B messages sent by the ground stations only to altitudes where > drones are forbidden (I suspect above 150m or so): I dont think it is > possible to restrict the altitude at which a message is sent to. It > would be impossible for an ADS-B message sent by a ground station to not > be heard at 100meters and only be heard at 200meters.  Or I do not > udnertsand. > > Planes that send ADS-B messages over the 'uplink'.  I think I have to > understand this better.  Until now I thought 'uplink' means a direction > from ground to up in the sky.  It is a distinct meaning than networking. > > In networking, a smartphone has an uplink, but the base-station also has > an uplink.  One's uplink is the other's downlink.  Compared to that, I > thought that in ADS-B the 'uplink' is only from ground up, but it seems > to not be so. > > >> -the downlink (system to aircraft) > > Again, I thought the 'downlink' is from the plane down to ground.   You > seem to say it reversely. > > I think the notion of 'uplink' and 'downlink' are with respect to a > device.  A device's uplink  is the other device's downlink, when they > communicate with each other. > >> is bandwidth-limited to a few hundred kbit/s for all aircraft >> combined in the coverage of the satellite transponder.  (This is >> somewhat over-simplified, as the uplink is intentionally sent in the >> clear, and many ADS-B receivers monitor the uplink of other aircraft >> for redundancy and more up-to-date information about traffic; see >> abive.) AFAIK, the whole continental US is covered by less than 20 >> transponders. N The downlink carries not only traffic information >> but also cruise and airport weather, certain airspace restrictions, >> and so forth.  All this is broadcasted and the ADS-B receivers in >> the aircraft need to filter out the information relevant for its >> position, course, and intentions.  Already, the bandwidth available >> is almost fully utilized to the point that the broadcast >> occasionally needs to omit certain less-critical information to make >> space for more critical one.  The system scales only by adding >> satellite transponders, which is expensive and not a fine >> granularity. > > I agree there might be bandwidth limitation that needs to be respected. > > It still is that putting an IP message on it can still work. > >> As for Mars, ADS-B is unsuitable until someone builds a >> ground-station network and has suitable satellites in orbit. > > YEs, the ground station would be on the rover and the satellite would > be on one of the stations (I dont know their names) that currently hover > above Mars routinely. > >> A bit closer to earth, for over-water and trans-pole operations >> there is ADS-C, which is completely satellite based and, AFAIK, even >> more bandwidth limited than ADS-B.  Yet another example for a network >>  unsuitable to carry IP traffic, but I digress. >> >> In short, forget ADS-B for the DRIP work.. > > Ok, if no ADS-B for DRIP work, then Bluetooth?  Is it more appropriate? > > Knowing that Bluetooth has a typical range of 10meter (I mean distance > range), is it reasonable to rely on it for identifying drones at > several hundred meters away? > > Knowing that Bluetooth is lower power than WiFi at 5.4Ghz, and that that > 5.4GHz is already used to control drone flight, video, etc, is it > preferrable to use Bluetooth instead of that WiFi at 5.4GHz? > > Alex > >> >> Stephan >> >> >> On 8/4/20, 6:53 AM, "Tm-rid on behalf of Alexandre Petrescu" >> >> wrote: >> >> architectural layers discussion... >> >> Le 30/07/2020 à 11:49, shuaiizhao(Shuai Zhao) a écrit : >>> Just to echo Stu on the ADSB, AFAIK, ADSB will  not be feasible >>> for most of the drones mostly due to SwaP, commercial drones might >>> be exception. >> >> It might be that ADS-B might be forbidden in drones on Earth, but >> how about the drones on Mars? ('NASA Mars helicopters', or ESA too). >> On Mars there would be much less such drones, so less risk of >> interference. >> >> With such a system (ADS-B under IP) one could re-use DTN (Delay >> Tolerant Networking) between planets, and so identify drones even on >>  Mars. >> >> But if we have reluctance about the use of ADS-B, and thus of IP, and >> we recommend Bluetooth-without-IP to identify drones, then we might >> become too dependent on it? >> >> (do not get me wrong, I do like Bluetooth, but I like many other >> things together with Bluetooth). >> >> Alex >> >>> >>> Best, >>> >>> Shuai Zhao >>> >>> *From: *Tm-rid on behalf of "Stuart W. >>> Card" *Date: *Wednesday, July 29, 2020 >>>  at 19:46 *To: *"tm-rid@ietf.org" *Subject: >>> *[Drip] ADSB (was: Review of draft-drip-arch-02 w.r.t. RFC6973, >>> RFC8280 and other)(Internet mail) >>> >>> Sorry for the slow reply. >>> >>> ADS-B is gradually being mandated for essentially all manned aircraft. >>> >>> ADSB-In and ADSB-Out are mandated for airliners: -In gives their pilots >>> >>> some Situational Awareness (SA) of other aircraft; -Out gives other >>> >>> pilots SA of the airliners. >>> >>> "ADSB-Out" is mandated even for small general aviation aircraft: >>> it does >>> >>> not directly benefit the pilots of those aircraft; but by >>> providing SA >>> >>> to others, it indirectly benefits all. >>> >>> ADSB is _not_ going to be deployed on large numbers of small UAS >>> as it >>> >>> would overwhelm the limited bandwidth available at those lower radio >>> >>> frequencies (which propagate long ranges). In fact, it is expected >>>  to be >>> >>> explicitly prohibited in the US per the FAA NPRM; I suspect most >>> of the >>> >>> rest of the world will do likewise. >>> >>> ADSB is also altogether insecure. >>> >>> On 7/9/2020 3:02 AM, Alexandre Petrescu wrote: >>> >>> ... >>> >>> They call it "ADS-B Receivers" (Automatic Dependent Surveillance - >>> >>> Broadcast). >>> >>> I wouuld like to ask if there is a packet dump available showing such >>> >>> presence data form planes?  Maybe wireshark already supports it, maybe >>> >>> it even dissects it... >>> >>> -- >>> >>> ----------------------------------------- >>> >>> Stuart W. Card, PhD, Principal Engineer >>> >>> AX Enterprize, LLC  www.axenterprize.com >>> >>> 4947 Commercial Drive, Yorkville NY 13495 >>> >>> >> >> -- Tm-rid mailing list Tm-rid@ietf.org >> https://www.ietf.org/mailman/listinfo/tm-rid >> > -- 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 --------------F464D4751F994CCFC9843FFF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 8/5/20 5:53 AM, Alexandre Petrescu wrote:
Stephan,

Le 04/08/2020 à 17:16, Stephan Wenger a écrit :
Alexandre,

ADS-B is a 20+ year old technology and offers properties (bandwidth,
 security, cost) of a 20 year old technology.  That it just recently
 sees widespread adoption is a result of incredibly slow (even by
IETF standards) deployment process, and that in turn is the result of
the very conservative and safety conscious aviation community and regulators, as well as the high cost related to anything manmade
that flies.  By speculating to use ADS-B as an underlying technology
for IP, I fear you demonstrate a certain lack of background.  The Wikipedia article on ADS-B (https://en.wikipedia.org/wiki/Automatic_dependent_surveillance_–_broadcast)




is mostly correct, and I recommend in particular the sections on
"Theory of operation" and "System Design Considerations".

There is no worry to fear I demonstrate lack of background in this
field.  It is true.  I still need to learn many things here.

I continue to look for a wireless link layer that is well adapted
for communication between flying devices (drones, flying taxis) and
ground.  And that would support very well IP.

Maybe ADS-B is not that link, but Bluetooth isnt it either because too
low power.

Maybe WiFi at 5.4GHz, which also used for remote control.

I recommend you look at IEEE 802.15.16t:

http://www.ieee802.org/15/pub/TG16t.html

This is actually an addendum to 802.16.  A bit of 802 politics.  802.16 is in hibernation.  802 EC did not want to go through the process and risks of reactivating it for this work.  So they turned over management of the work to the 802.15 leadership.

This is licensed spectrum.  The current use cases:

https://mentor.ieee.org/802.15/documents?is_dcn=DCN%2C%20Title%2C%20Author%20or%20Affiliation&is_group=016t

Does not include aviation, but so what?  Get one of the RF license holders in this business model and you are in business.

Some of these frequencies have the bandwidth and range for practical use here.


That aside, let me try to answer some of the points below.

A few (of many) reasons why ADS-B is unsuitable for light drones (anything significantly smaller than a man-carrying aircraft): -24 bit ICAO transponder code, limiting the number of (active or inactive) ADS-B equipment.  Each modern aircraft over a certain size
 (except the smallest two-seaters, powered parachutes, and aircraft without electrical systems such as antiques) has a unique code assigned for its lifetime.

Ok.  But MAC addresses of Bluetooth also are limited.  They have 48bit
which is more than 24bit of ADS-B, but it is still limited.

-line-of-sight wireless connection for the "uplink" with only a few hundred ground stations for the whole US (or 70 for the whole Australia).  That means ADS-B coverage is almost everywhere only available at altitudes in which small drones are neither legal nor, in most cases, physically capable to fly (a few thousand feet in the US except near major airports where you don't want drones, 30000 ft in Australia).  Aircraft send over the uplink information such as aircraft ICAO code, aircraft type, speed, direction of flight, altitude, etc.).  Information is sent in the clear, by design.  You can buy a box receiving this info, hook it up to an Raspberry PI or something, and look at the traffic near your house and send it on to your friends--in fact, this type of crowdsourced ATC info is what makes flightradar24 and similar sites work.

This sounds like an argument in favor of using ADS-B for identification,
not against.  Or maybe I dont understand.

Only a few ground stations: I suspect this is around airport areas,
which is good.

ADS-B messages sent by the ground stations only to altitudes where
drones are forbidden (I suspect above 150m or so): I dont think it is
possible to restrict the altitude at which a message is sent to.  It
would be impossible for an ADS-B message sent by a ground station to not
be heard at 100meters and only be heard at 200meters.  Or I do not
udnertsand.

Planes that send ADS-B messages over the 'uplink'.  I think I have to
understand this better.  Until now I thought 'uplink' means a direction
from ground to up in the sky.  It is a distinct meaning than networking.

In networking, a smartphone has an uplink, but the base-station also has
an uplink.  One's uplink is the other's downlink.  Compared to that, I
thought that in ADS-B the 'uplink' is only from ground up, but it seems
to not be so.


-the downlink (system to aircraft)

Again, I thought the 'downlink' is from the plane down to ground.   You
seem to say it reversely.

I think the notion of 'uplink' and 'downlink' are with respect to a
device.  A device's uplink  is the other device's downlink, when they
communicate with each other.

is bandwidth-limited to a few hundred kbit/s for all aircraft combined in the coverage of the satellite transponder.  (This is somewhat over-simplified, as the uplink is intentionally sent in the clear, and many ADS-B receivers monitor the uplink of other aircraft for redundancy and more up-to-date information about traffic; see abive.)  AFAIK, the whole continental US is covered by less than 20 transponders. N The downlink carries not only traffic information
but also cruise and airport weather, certain airspace restrictions,
and so forth.  All this is broadcasted and the ADS-B receivers in
the aircraft need to filter out the information relevant for its position, course, and intentions.  Already, the bandwidth available is almost fully utilized to the point that the broadcast
occasionally needs to omit certain less-critical information to make
space for more critical one.  The system scales only by adding
satellite transponders, which is expensive and not a fine
granularity.

I agree there might be bandwidth limitation that needs to be respected.

It still is that putting an IP message on it can still work.

As for Mars, ADS-B is unsuitable until someone builds a ground-station network and has suitable satellites in orbit.

YEs, the ground station would be on the rover and the satellite would
be on one of the stations (I dont know their names) that currently hover
above Mars routinely.

A bit closer to earth, for over-water and trans-pole operations
there is ADS-C, which is completely satellite based and, AFAIK, even
more bandwidth limited than ADS-B.  Yet another example for a network
 unsuitable to carry IP traffic, but I digress.

In short, forget ADS-B for the DRIP work..

Ok, if no ADS-B for DRIP work, then Bluetooth?  Is it more appropriate?

Knowing that Bluetooth has a typical range of 10meter (I mean distance
range), is it reasonable to rely on it for identifying drones at
several hundred meters away?

Knowing that Bluetooth is lower power than WiFi at 5.4Ghz, and that that
5.4GHz is already used to control drone flight, video, etc, is it
preferrable to use Bluetooth instead of that WiFi at 5.4GHz?

Alex


Stephan


On 8/4/20, 6:53 AM, "Tm-rid on behalf of Alexandre Petrescu" <tm-rid-bounces@ietf.org on behalf of alexandre.petrescu@gmail.com> wrote:

architectural layers discussion...

Le 30/07/2020 à 11:49, shuaiizhao(Shuai Zhao) a écrit :
Just to echo Stu on the ADSB, AFAIK, ADSB will  not be feasible
for most of the drones mostly due to SwaP, commercial drones might
be exception.

It might be that ADS-B might be forbidden in drones on Earth, but
how about the drones on Mars? ('NASA Mars helicopters', or ESA too).
On Mars there would be much less such drones, so less risk of interference.

With such a system (ADS-B under IP) one could re-use DTN (Delay Tolerant Networking) between planets, and so identify drones even on
 Mars.

But if we have reluctance about the use of ADS-B, and thus of IP, and
we recommend Bluetooth-without-IP to identify drones, then we might
become too dependent on it?

(do not get me wrong, I do like Bluetooth, but I like many other things together with Bluetooth).

Alex


Best,

Shuai Zhao

*From: *Tm-rid <tm-rid-bounces@ietf.org> on behalf of "Stuart W. Card" <stu.card@axenterprize.com> *Date: *Wednesday, July 29, 2020
 at 19:46 *To: *"tm-rid@ietf.org" <tm-rid@ietf.org> *Subject: *[Drip] ADSB (was: Review of draft-drip-arch-02 w.r.t. RFC6973, RFC8280 and other)(Internet mail)

Sorry for the slow reply.

ADS-B is gradually being mandated for essentially all manned aircraft.

ADSB-In and ADSB-Out are mandated for airliners: -In gives their pilots

some Situational Awareness (SA) of other aircraft; -Out gives other

pilots SA of the airliners.

"ADSB-Out" is mandated even for small general aviation aircraft:
it does

not directly benefit the pilots of those aircraft; but by
providing SA

to others, it indirectly benefits all.

ADSB is _not_ going to be deployed on large numbers of small UAS
as it

would overwhelm the limited bandwidth available at those lower radio

frequencies (which propagate long ranges). In fact, it is expected
 to be

explicitly prohibited in the US per the FAA NPRM; I suspect most
of the

rest of the world will do likewise.

ADSB is also altogether insecure.

On 7/9/2020 3:02 AM, Alexandre Petrescu wrote:

...

They call it "ADS-B Receivers" (Automatic Dependent Surveillance -

Broadcast).

I wouuld like to ask if there is a packet dump available showing such

presence data form planes?  Maybe wireshark already supports it, maybe

it even dissects it...

--

-----------------------------------------

Stuart W. Card, PhD, Principal Engineer

AX Enterprize, LLC  www.axenterprize.com

4947 Commercial Drive, Yorkville NY 13495



-- Tm-rid mailing list Tm-rid@ietf.org https://www.ietf.org/mailman/listinfo/tm-rid



--
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
--------------F464D4751F994CCFC9843FFF-- From nobody Wed Aug 5 04:53:40 2020 Return-Path: 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 F34D33A041B for ; Wed, 5 Aug 2020 04:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, 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 dMNQO5Dkjsye for ; Wed, 5 Aug 2020 04:53:34 -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 C02843A1360 for ; Wed, 5 Aug 2020 04:53:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 4DFAD62422; Wed, 5 Aug 2020 07:53:32 -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 zRzMQPizf8uP; Wed, 5 Aug 2020 07:53:16 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (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 9482162416; Wed, 5 Aug 2020 07:53:16 -0400 (EDT) To: Alexandre Petrescu , tm-rid@ietf.org References: <1bebf5b1-1fa5-6902-5bb7-9ec3582e6d9a@andersdotter.cc> <2990FBF0-FCB0-49CE-8F4B-BF5111CE5D57@tzi.org> <01a21161-aa8d-6d4b-b384-3129fe6d799b@gmail.com> <973223fd-0119-376d-12cd-21559a14ce87@labs.htt-consult.com> <3c632ce9-115d-11f5-ee33-bfabd4973522@labs.htt-consult.com> <7ddd9a2f-23ba-dd82-8cfb-1d2974969e67@gmail.com> <61511ef6-5b9b-5b62-f922-d32b994a35b9@gmail.com> From: Robert Moskowitz Message-ID: Date: Wed, 5 Aug 2020 07:53:02 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------91637C856E744C2A351D8604" Content-Language: en-US Archived-At: Subject: Re: [Drip] ADSB X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 11:53:38 -0000 This is a multi-part message in MIME format. --------------91637C856E744C2A351D8604 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 8/5/20 6:11 AM, Alexandre Petrescu wrote: > > > Le 04/08/2020 à 17:51, Robert Moskowitz a écrit : >> >> >> On 8/4/20 11:27 AM, Alexandre Petrescu wrote: >>> Thanks for the clarification. >>> >>> Le 04/08/2020 à 17:17, Stuart W. Card a écrit : >>>> I just want to respond to one line that I think comes from confusion: >>>> >>>>> But if we have reluctance about the use of ADS-B, and thus of IP, >>>>> and we recommend Bluetooth-without-IP to identify drones >>>> >>>> We aren't recommending Bluetooth-without-IP, we are _supporting_ it, >>> >>> But, the security manifest that I have seen on slides during the >>> presentation of the DRIP WG meeting - is something below IP, right? >> >> For now, we are dealing with broadcast messages.  Either over >> Bluetooth or WiFI (NAN). > > If it is a broadcast message and it is over Bluetooth or over WiFi > then it certainly is IP multicast, cant be anything else. Wrong for BT4.  There are only 25 bytes available.  We can do most of the messaging in a single frame.  To do anything with IP will force this to a multiframe design. Even BT5 it is wrong for the Authentication Message.  We need the full frame for our content.  We would have to go with multiframe design for BT5 as a result. So this leaves WiFi NAN.  Sure you can do it, but why?  What does it add?  In My Not So Humble Opinion (IMNSOHO) nothing but cost and processing overhead. > > If it is IP multicast over Bluetooth or over WiFi then I wonder what is > the value  in the Next Header field of the IP header format (RFC8200 > "IPv6", section 3 "Header format").  Basically - what is the payload? > > If one asks me, I would dare to think that payload might be an ICMPv6 > Router Advertisement. > >> There is NO security for the messages below the message package. > > Noted. > >> Just not enough payload size for anything that would work in a >> broadcast environment like a National Airspace.  All of the security >> we are specifying is inside the messages where appropriate. >> >> That security manifest is a payload of the ASTM F3411-19 >> Authentication Message. > > It costs 85USD I wont pay to see it.  It is security.  There will > always be someone smarter to break that security and ask for more money. Look at: https://github.com/opendroneid/specs/blob/master/OpenDroneID_Bluetooth_0.64.3.pdf It is close enough. > I would not oppose if that Authentication MEssage had a specification in > clear. The above plus Adam's draft will get you there. > >> These messages are broadcasted as Adam mentioned in his 'flying DRIP' >> comments at the beginning. > > Thank you for the reminder.  I looked again at the 'flying DRIP' > presentation during the WG meeting, and at the related draft. > https://datatracker.ietf.org/meeting/108/materials/slides-108-drip-authentication-formats > > and > draft-wiethuechter-drip-auth-01 > > During the presentation, the slide clearly shows on slide 8 that a > Bluetooth header immediately precedes an Open Drone ID message. There > is no IP header in that slide. That is right.  No IP.  No room for it.  No justification for it. It is all RLOS only. > > In the draft, there is similar discussion tightly related to Bluetooth > and without IP. > > But if we are to have an independence of Bluetooth, and use a > networking layer such as IP, then the question of the use of an > authentication header is made differently. Again what is the justification for adding IP multicast?  Where do you see these messages going beyond the RF Line Of Sight? > > The authentication header would be an IP Authentication Header. This > AH would be somehow re-used and extended where necessary for DRIP > purposes. > >> Now later I expect us to move on to Network Remote ID and Command >> and Control (C2). >> >> Most C2 (e.g. Mavlink) is directly over the MAC, but there is a >> method to run it over UDP (I forget the UDP port commonly used...). >> AX Enterprize has done this using HIP so the UA starts with WiFi >> over the launch point, transitions to LTE, and on return back to >> WiFi. >> >> Network Remote ID can work either directly from the UA, or via C2 >> information to the GCS, from the GCS.  In either case, IP is >> assumed. This will probably be done via UDP.  From the UA, mobility >> will be important; from the GCS nice to have (most GCS will be stable >>  location).  As UDP to a fixed Net-SP, DTLS 1.3 is a viable >> alternative to HIP. > > I will have to look closer at HIP again :-) and see how it could be > made to work with DRIP and IP. Stu, Adam, Andrei, and I see HIP for where there is pairwise communication with potentially both ends mobile and using multiple interfaces.  Once you have that use case, be consistent and use it for simpler situations. > > Alex > >> >> >> >> >>> >>> Alex >>> >>> as >>>> it is specified in ASTM F3411, which most of the regulators are >>>> dubbing as an approved technical means of regulatory compliance. >>>> >>>> AFAIK, no one runs IP over ADS-B, which was designed as a >>>> narrowband application specific communications stovepipe, not a >>>> data link supporting higher layer network protocols, so not >>>> great for IP. >>>> >>>> More importantly, we have no "reluctance about the use of... >>>> IP", which is an entirely separate issue from ADS-B. >>>> >>>> On 8/4/2020 9:52 AM, Alexandre Petrescu wrote: >>>>> architectural layers discussion... >>>>> >>>>> Le 30/07/2020 à 11:49, shuaiizhao(Shuai Zhao) a écrit : >>>>>> Just to echo Stu on the ADSB, AFAIK, ADSB will  not be feasible >>>>>> for most of the drones mostly due to SwaP, commercial drones >>>>>> might be exception. >>>>> >>>>> It might be that ADS-B might be forbidden in drones on Earth, but >>>>> how about the drones on Mars? ('NASA Mars helicopters', or ESA >>>>> too).  On Mars there would be much less such drones, so less risk >>>>> of interference. >>>>> >>>>> With such a system (ADS-B under IP) one could re-use DTN >>>>> (Delay Tolerant Networking) between planets, and so identify >>>>> drones even on Mars. >>>>> >>>>> But if we have reluctance about the use of ADS-B, and thus of IP, >>>>> and we recommend Bluetooth-without-IP to identify drones, then we >>>>> might become too dependent on it? >>>>> >>>>> (do not get me wrong, I do like Bluetooth, but I like many other >>>>> things together with Bluetooth). >>>>> >>>>> Alex >>>>> >>>>>> >>>>>> Best, >>>>>> >>>>>> Shuai Zhao >>>>>> >>>>>> *From: *Tm-rid on behalf of >>>>>> "Stuart W. Card" *Date: >>>>>> *Wednesday, July 29, 2020 at 19:46 *To: *"tm-rid@ietf.org" >>>>>> *Subject: *[Drip] ADSB (was: Review of >>>>>> draft-drip-arch-02 w.r.t. RFC6973, RFC8280 and >>>>>> other)(Internet mail) >>>>>> >>>>>> Sorry for the slow reply. >>>>>> >>>>>> ADS-B is gradually being mandated for essentially all manned >>>>>>  aircraft. >>>>>> >>>>>> ADSB-In and ADSB-Out are mandated for airliners: -In gives their >>>>>> pilots >>>>>> >>>>>> some Situational Awareness (SA) of other aircraft; -Out >>>>>> gives other >>>>>> >>>>>> pilots SA of the airliners. >>>>>> >>>>>> "ADSB-Out" is mandated even for small general aviation aircraft: >>>>>> it does >>>>>> >>>>>> not directly benefit the pilots of those aircraft; but by >>>>>> providing SA >>>>>> >>>>>> to others, it indirectly benefits all. >>>>>> >>>>>> ADSB is _not_ going to be deployed on large numbers of small UAS >>>>>> as it >>>>>> >>>>>> would overwhelm the limited bandwidth available at those lower radio >>>>>> >>>>>> frequencies (which propagate long ranges). In fact, it is >>>>>> expected to be >>>>>> >>>>>> explicitly prohibited in the US per the FAA NPRM; I suspect most >>>>>> of the >>>>>> >>>>>> rest of the world will do likewise. >>>>>> >>>>>> ADSB is also altogether insecure. >>>>>> >>>>>> On 7/9/2020 3:02 AM, Alexandre Petrescu wrote: >>>>>> >>>>>> ... >>>>>> >>>>>> They call it "ADS-B Receivers" (Automatic Dependent Surveillance - >>>>>> >>>>>> Broadcast). >>>>>> >>>>>> I wouuld like to ask if there is a packet dump available showing >>>>>> such >>>>>> >>>>>> presence data form planes?  Maybe wireshark already supports it, >>>>>> maybe >>>>>> >>>>>> it even dissects it... >>>>>> >>>>>> -- >>>>>> >>>>>> ----------------------------------------- >>>>>> >>>>>> Stuart W. Card, PhD, Principal Engineer >>>>>> >>>>>> AX Enterprize, LLC www.axenterprize.com >>>>>> >>>>>> 4947 Commercial Drive, Yorkville NY 13495 >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> >> >> -- 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 -- 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 --------------91637C856E744C2A351D8604 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 8/5/20 6:11 AM, Alexandre Petrescu wrote:


Le 04/08/2020 à 17:51, Robert Moskowitz a écrit :


On 8/4/20 11:27 AM, Alexandre Petrescu wrote:
Thanks for the clarification.

Le 04/08/2020 à 17:17, Stuart W. Card a écrit :
I just want to respond to one line that I think comes from confusion:

But if we have reluctance about the use of ADS-B, and thus of IP, and we recommend Bluetooth-without-IP to identify drones

We aren't recommending Bluetooth-without-IP, we are _supporting_ it,

But, the security manifest that I have seen on slides during the presentation of the DRIP WG meeting - is something below IP, right?

For now, we are dealing with broadcast messages.  Either over Bluetooth or WiFI (NAN).

If it is a broadcast message and it is over Bluetooth or over WiFi then it certainly is IP multicast, cant be anything else.

Wrong for BT4.  There are only 25 bytes available.  We can do most of the messaging in a single frame.  To do anything with IP will force this to a multiframe design.

Even BT5 it is wrong for the Authentication Message.  We need the full frame for our content.  We would have to go with multiframe design for BT5 as a result.

So this leaves WiFi NAN.  Sure you can do it, but why?  What does it add?  In My Not So Humble Opinion (IMNSOHO) nothing but cost and processing overhead.


If it is IP multicast over Bluetooth or over WiFi then I wonder what is
the value  in the Next Header field of the IP header format (RFC8200
"IPv6", section 3 "Header format").  Basically - what is the payload?

If one asks me, I would dare to think that payload might be an ICMPv6
Router Advertisement.

There is NO security for the messages below the message package.

Noted.

Just not enough payload size for anything that would work in a broadcast environment like a National Airspace.  All of the security we are specifying is inside the messages where appropriate.

That security manifest is a payload of the ASTM F3411-19 Authentication Message.

It costs 85USD I wont pay to see it.  It is security.  There will always be someone smarter to break that security and ask for more money.

Look at:

https://github.com/opendroneid/specs/blob/master/OpenDroneID_Bluetooth_0.64.3.pdf

It is close enough.

I would not oppose if that Authentication MEssage had a specification in
clear.

The above plus Adam's draft will get you there.


These messages are broadcasted as Adam mentioned in his 'flying DRIP'
comments at the beginning.

Thank you for the reminder.  I looked again at the 'flying DRIP' presentation during the WG meeting, and at the related draft.
https://datatracker.ietf.org/meeting/108/materials/slides-108-drip-authentication-formats
and
draft-wiethuechter-drip-auth-01

During the presentation, the slide clearly shows on slide 8 that a Bluetooth header immediately precedes an Open Drone ID message.  There is no IP header in that slide.

That is right.  No IP.  No room for it.  No justification for it.  It is all RLOS only.



In the draft, there is similar discussion tightly related to Bluetooth and without IP.

But if we are to have an independence of Bluetooth, and use a networking layer such as IP, then the question of the use of an authentication header is made differently.

Again what is the justification for adding IP multicast?  Where do you see these messages going beyond the RF Line Of Sight?


The authentication header would be an IP Authentication Header.  This AH would be somehow re-used and extended where necessary for DRIP purposes.

Now later I expect us to move on to Network Remote ID and Command
and Control (C2).

Most C2 (e.g. Mavlink) is directly over the MAC, but there is a method to run it over UDP (I forget the UDP port commonly used...). AX Enterprize has done this using HIP so the UA starts with WiFi
over the launch point, transitions to LTE, and on return back to
WiFi.

Network Remote ID can work either directly from the UA, or via C2 information to the GCS, from the GCS.  In either case, IP is
assumed. This will probably be done via UDP.  From the UA, mobility
will be important; from the GCS nice to have (most GCS will be stable
 location).  As UDP to a fixed Net-SP, DTLS 1.3 is a viable alternative to HIP.

I will have to look closer at HIP again :-) and see how it could be made to work with DRIP and IP.

Stu, Adam, Andrei, and I see HIP for where there is pairwise communication with potentially both ends mobile and using multiple interfaces.  Once you have that use case, be consistent and use it for simpler situations.


Alex






Alex

as
it is specified in ASTM F3411, which most of the regulators are dubbing as an approved technical means of regulatory compliance.

AFAIK, no one runs IP over ADS-B, which was designed as a narrowband application specific communications stovepipe, not a data link supporting higher layer network protocols, so not
great for IP.

More importantly, we have no "reluctance about the use of...
IP", which is an entirely separate issue from ADS-B.

On 8/4/2020 9:52 AM, Alexandre Petrescu wrote:
architectural layers discussion...

Le 30/07/2020 à 11:49, shuaiizhao(Shuai Zhao) a écrit :
Just to echo Stu on the ADSB, AFAIK, ADSB will  not be feasible for most of the drones mostly due to SwaP, commercial drones might be exception.

It might be that ADS-B might be forbidden in drones on Earth, but how about the drones on Mars? ('NASA Mars helicopters', or ESA too).  On Mars there would be much less such drones, so less risk of interference.

With such a system (ADS-B under IP) one could re-use DTN
(Delay Tolerant Networking) between planets, and so identify
drones even on Mars.

But if we have reluctance about the use of ADS-B, and thus of IP, and we recommend Bluetooth-without-IP to identify drones, then we might become too dependent on it?

(do not get me wrong, I do like Bluetooth, but I like many other things together with Bluetooth).

Alex


Best,

Shuai Zhao

*From: *Tm-rid <tm-rid-bounces@ietf.org> on behalf of
"Stuart W. Card" <stu.card@axenterprize.com> *Date:
*Wednesday, July 29, 2020 at 19:46 *To: *"tm-rid@ietf.org"
<tm-rid@ietf.org> *Subject: *[Drip] ADSB (was: Review of
draft-drip-arch-02 w.r.t. RFC6973, RFC8280 and
other)(Internet mail)

Sorry for the slow reply.

ADS-B is gradually being mandated for essentially all manned
 aircraft.

ADSB-In and ADSB-Out are mandated for airliners: -In gives their pilots

some Situational Awareness (SA) of other aircraft; -Out
gives other

pilots SA of the airliners.

"ADSB-Out" is mandated even for small general aviation aircraft: it does

not directly benefit the pilots of those aircraft; but by providing SA

to others, it indirectly benefits all.

ADSB is _not_ going to be deployed on large numbers of small UAS as it

would overwhelm the limited bandwidth available at those lower radio

frequencies (which propagate long ranges). In fact, it is expected to be

explicitly prohibited in the US per the FAA NPRM; I suspect most of the

rest of the world will do likewise.

ADSB is also altogether insecure.

On 7/9/2020 3:02 AM, Alexandre Petrescu wrote:

...

They call it "ADS-B Receivers" (Automatic Dependent Surveillance -

Broadcast).

I wouuld like to ask if there is a packet dump available showing such

presence data form planes?  Maybe wireshark already supports it, maybe

it even dissects it...

--

-----------------------------------------

Stuart W. Card, PhD, Principal Engineer

AX Enterprize, LLC www.axenterprize.com

4947 Commercial Drive, Yorkville NY 13495








-- 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

--
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
--------------91637C856E744C2A351D8604-- From nobody Wed Aug 5 05:13:19 2020 Return-Path: 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 E65E93A0143 for ; Wed, 5 Aug 2020 05:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.278 X-Spam-Level: X-Spam-Status: No, score=-0.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.949, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 Iu3Wvmx4inSy for ; Wed, 5 Aug 2020 05:13:15 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 6DE983A003F for ; Wed, 5 Aug 2020 05:13:15 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 075CDCiS035991; Wed, 5 Aug 2020 14:13:12 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9E8B0203D6E; Wed, 5 Aug 2020 14:13:12 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 8D26C201E9A; Wed, 5 Aug 2020 14:13:12 +0200 (CEST) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 075CDCdA015438; Wed, 5 Aug 2020 14:13:12 +0200 To: Robert Moskowitz Cc: Stephan Wenger , "tm-rid@ietf.org" References: <1bebf5b1-1fa5-6902-5bb7-9ec3582e6d9a@andersdotter.cc> <2990FBF0-FCB0-49CE-8F4B-BF5111CE5D57@tzi.org> <01a21161-aa8d-6d4b-b384-3129fe6d799b@gmail.com> <973223fd-0119-376d-12cd-21559a14ce87@labs.htt-consult.com> <3c632ce9-115d-11f5-ee33-bfabd4973522@labs.htt-consult.com> <7ddd9a2f-23ba-dd82-8cfb-1d2974969e67@gmail.com> <079a0a22-f46b-b0a7-de41-63cfb2d1574e@gmail.com> From: Alexandre Petrescu Message-ID: <0cf59fbe-68dc-aacd-eb92-5df8f55c9247@gmail.com> Date: Wed, 5 Aug 2020 14:13:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Drip] ADSB X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 12:13:18 -0000 Le 05/08/2020 à 13:41, Robert Moskowitz a écrit : > > > On 8/5/20 5:53 AM, Alexandre Petrescu wrote: >> Stephan, >> >> Le 04/08/2020 à 17:16, Stephan Wenger a écrit : >>> Alexandre, >>> >>> ADS-B is a 20+ year old technology and offers properties (bandwidth, >>>  security, cost) of a 20 year old technology.  That it just recently >>>  sees widespread adoption is a result of incredibly slow (even by >>> IETF standards) deployment process, and that in turn is the result of >>> the very conservative and safety conscious aviation community and >>> regulators, as well as the high cost related to anything manmade >>> that flies.  By speculating to use ADS-B as an underlying technology >>> for IP, I fear you demonstrate a certain lack of background. The >>> Wikipedia article on ADS-B >>> (https://en.wikipedia.org/wiki/Automatic_dependent_surveillance_–_broadcast) >>> >>> >>> >>> >> is mostly correct, and I recommend in particular the sections on >>> "Theory of operation" and "System Design Considerations". >> >> There is no worry to fear I demonstrate lack of background in this >> field.  It is true.  I still need to learn many things here. >> >> I continue to look for a wireless link layer that is well adapted >> for communication between flying devices (drones, flying taxis) and >> ground.  And that would support very well IP. >> >> Maybe ADS-B is not that link, but Bluetooth isnt it either because too >> low power. >> >> Maybe WiFi at 5.4GHz, which also used for remote control. > > I recommend you look at IEEE 802.15.16t: > > http://www.ieee802.org/15/pub/TG16t.html I looked at some of the slides of 802.15.16th of presentations in July, 2020. The best I could understand is this: "The IEEE 802.15.16t Task Group is developing an amendment to 802.16-2017. Project 802.16t “Amendment - Fixed and Mobile Wireless Access in Narrowband Channels” This project specifies operation in licensed spectrum with channel bandwidths greater than or equal to 5 kHz and less than 100 kHz. A new PHY will be specified, with changes to the MAC as necessary. The amendment is frequency independent but focuses on spectrum less than 2 GHz. Aggregated operation in adjacent and non-adjacent channels will be supported." > This is actually an addendum to 802.16.  A bit of 802 politics. 802.16 > is in hibernation.  802 EC did not want to go through the process and > risks of reactivating it for this work.  So they turned over management > of the work to the 802.15 leadership. I see, that's why. So, the question that could be made to 802.15.16t is: would the new 802.16 (the one including 802.15.16t) consider drones and their identification as a potential use-case? If yes, would the new 802.16 like to use IP to carry the drone identification? Or would the new 802.16 rather carry the drone identification in a new 802.16 header that sits below IP? > This is licensed spectrum.  The current use cases: > > https://mentor.ieee.org/802.15/documents?is_dcn=DCN%2C%20Title%2C%20Author%20or%20Affiliation&is_group=016t > > Does not include aviation, but so what?  Get one of the RF license > holders in this business model and you are in business. > > Some of these frequencies have the bandwidth and range for practical use > here. Fair enough. There would be however some differences between carrying drone identification numbers by Bluetooth headers or by 802.16 headers. IEEE and Bluetooth SIG made different formats. If one wanted a unique format for drone identification to be transmitted on all these link layers similarly, one would need to use IP. IP sits ok on both 802.16 and on Bluetooth. Alex > >> >> That aside, let me try to answer some of the points below. >> >>> A few (of many) reasons why ADS-B is unsuitable for light drones >>> (anything significantly smaller than a man-carrying aircraft): -24 >>> bit ICAO transponder code, limiting the number of (active or >>> inactive) ADS-B equipment. Each modern aircraft over a certain size >>>  (except the smallest two-seaters, powered parachutes, and aircraft >>> without electrical systems such as antiques) has a unique code >>> assigned for its lifetime. >> >> Ok.  But MAC addresses of Bluetooth also are limited.  They have 48bit >> which is more than 24bit of ADS-B, but it is still limited. >> >>> -line-of-sight wireless connection for the "uplink" with only a few >>> hundred ground stations for the whole US (or 70 for the whole >>> Australia).  That means ADS-B coverage is almost everywhere only >>> available at altitudes in which small drones are neither legal nor, >>> in most cases, physically capable to fly (a few thousand feet in the >>> US except near major airports where you don't want drones, 30000 ft >>> in Australia).  Aircraft send over the uplink information such as >>> aircraft ICAO code, aircraft type, speed, direction of flight, >>> altitude, etc.). Information is sent in the clear, by design.  You >>> can buy a box receiving this info, hook it up to an Raspberry PI or >>> something, and look at the traffic near your house and send it on to >>> your friends--in fact, this type of crowdsourced ATC info is what >>> makes flightradar24 and similar sites work. >> >> This sounds like an argument in favor of using ADS-B for identification, >> not against.  Or maybe I dont understand. >> >> Only a few ground stations: I suspect this is around airport areas, >> which is good. >> >> ADS-B messages sent by the ground stations only to altitudes where >> drones are forbidden (I suspect above 150m or so): I dont think it is >> possible to restrict the altitude at which a message is sent to. It >> would be impossible for an ADS-B message sent by a ground station to not >> be heard at 100meters and only be heard at 200meters.  Or I do not >> udnertsand. >> >> Planes that send ADS-B messages over the 'uplink'.  I think I have to >> understand this better.  Until now I thought 'uplink' means a direction >> from ground to up in the sky.  It is a distinct meaning than networking. >> >> In networking, a smartphone has an uplink, but the base-station also has >> an uplink.  One's uplink is the other's downlink.  Compared to that, I >> thought that in ADS-B the 'uplink' is only from ground up, but it seems >> to not be so. >> >> >>> -the downlink (system to aircraft) >> >> Again, I thought the 'downlink' is from the plane down to ground.   You >> seem to say it reversely. >> >> I think the notion of 'uplink' and 'downlink' are with respect to a >> device.  A device's uplink  is the other device's downlink, when they >> communicate with each other. >> >>> is bandwidth-limited to a few hundred kbit/s for all aircraft >>> combined in the coverage of the satellite transponder.  (This is >>> somewhat over-simplified, as the uplink is intentionally sent in the >>> clear, and many ADS-B receivers monitor the uplink of other aircraft >>> for redundancy and more up-to-date information about traffic; see >>> abive.) AFAIK, the whole continental US is covered by less than 20 >>> transponders. N The downlink carries not only traffic information >>> but also cruise and airport weather, certain airspace restrictions, >>> and so forth.  All this is broadcasted and the ADS-B receivers in >>> the aircraft need to filter out the information relevant for its >>> position, course, and intentions.  Already, the bandwidth available >>> is almost fully utilized to the point that the broadcast >>> occasionally needs to omit certain less-critical information to make >>> space for more critical one.  The system scales only by adding >>> satellite transponders, which is expensive and not a fine >>> granularity. >> >> I agree there might be bandwidth limitation that needs to be respected. >> >> It still is that putting an IP message on it can still work. >> >>> As for Mars, ADS-B is unsuitable until someone builds a >>> ground-station network and has suitable satellites in orbit. >> >> YEs, the ground station would be on the rover and the satellite would >> be on one of the stations (I dont know their names) that currently hover >> above Mars routinely. >> >>> A bit closer to earth, for over-water and trans-pole operations >>> there is ADS-C, which is completely satellite based and, AFAIK, even >>> more bandwidth limited than ADS-B.  Yet another example for a network >>>  unsuitable to carry IP traffic, but I digress. >>> >>> In short, forget ADS-B for the DRIP work.. >> >> Ok, if no ADS-B for DRIP work, then Bluetooth?  Is it more appropriate? >> >> Knowing that Bluetooth has a typical range of 10meter (I mean distance >> range), is it reasonable to rely on it for identifying drones at >> several hundred meters away? >> >> Knowing that Bluetooth is lower power than WiFi at 5.4Ghz, and that that >> 5.4GHz is already used to control drone flight, video, etc, is it >> preferrable to use Bluetooth instead of that WiFi at 5.4GHz? >> >> Alex >> >>> >>> Stephan >>> >>> >>> On 8/4/20, 6:53 AM, "Tm-rid on behalf of Alexandre Petrescu" >>> >>> wrote: >>> >>> architectural layers discussion... >>> >>> Le 30/07/2020 à 11:49, shuaiizhao(Shuai Zhao) a écrit : >>>> Just to echo Stu on the ADSB, AFAIK, ADSB will  not be feasible >>>> for most of the drones mostly due to SwaP, commercial drones might >>>> be exception. >>> >>> It might be that ADS-B might be forbidden in drones on Earth, but >>> how about the drones on Mars? ('NASA Mars helicopters', or ESA too). >>> On Mars there would be much less such drones, so less risk of >>> interference. >>> >>> With such a system (ADS-B under IP) one could re-use DTN (Delay >>> Tolerant Networking) between planets, and so identify drones even on >>>  Mars. >>> >>> But if we have reluctance about the use of ADS-B, and thus of IP, and >>> we recommend Bluetooth-without-IP to identify drones, then we might >>> become too dependent on it? >>> >>> (do not get me wrong, I do like Bluetooth, but I like many other >>> things together with Bluetooth). >>> >>> Alex >>> >>>> >>>> Best, >>>> >>>> Shuai Zhao >>>> >>>> *From: *Tm-rid on behalf of "Stuart W. >>>> Card" *Date: *Wednesday, July 29, 2020 >>>>  at 19:46 *To: *"tm-rid@ietf.org" *Subject: >>>> *[Drip] ADSB (was: Review of draft-drip-arch-02 w.r.t. RFC6973, >>>> RFC8280 and other)(Internet mail) >>>> >>>> Sorry for the slow reply. >>>> >>>> ADS-B is gradually being mandated for essentially all manned aircraft. >>>> >>>> ADSB-In and ADSB-Out are mandated for airliners: -In gives their pilots >>>> >>>> some Situational Awareness (SA) of other aircraft; -Out gives other >>>> >>>> pilots SA of the airliners. >>>> >>>> "ADSB-Out" is mandated even for small general aviation aircraft: >>>> it does >>>> >>>> not directly benefit the pilots of those aircraft; but by >>>> providing SA >>>> >>>> to others, it indirectly benefits all. >>>> >>>> ADSB is _not_ going to be deployed on large numbers of small UAS >>>> as it >>>> >>>> would overwhelm the limited bandwidth available at those lower radio >>>> >>>> frequencies (which propagate long ranges). In fact, it is expected >>>>  to be >>>> >>>> explicitly prohibited in the US per the FAA NPRM; I suspect most >>>> of the >>>> >>>> rest of the world will do likewise. >>>> >>>> ADSB is also altogether insecure. >>>> >>>> On 7/9/2020 3:02 AM, Alexandre Petrescu wrote: >>>> >>>> ... >>>> >>>> They call it "ADS-B Receivers" (Automatic Dependent Surveillance - >>>> >>>> Broadcast). >>>> >>>> I wouuld like to ask if there is a packet dump available showing such >>>> >>>> presence data form planes?  Maybe wireshark already supports it, maybe >>>> >>>> it even dissects it... >>>> >>>> -- >>>> >>>> ----------------------------------------- >>>> >>>> Stuart W. Card, PhD, Principal Engineer >>>> >>>> AX Enterprize, LLC www.axenterprize.com >>>> >>>> 4947 Commercial Drive, Yorkville NY 13495 >>>> >>>> >>> >>> -- Tm-rid mailing list Tm-rid@ietf.org >>> https://www.ietf.org/mailman/listinfo/tm-rid >>> >> > > -- > 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 From nobody Wed Aug 5 05:34:06 2020 Return-Path: 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 413C53A0486 for ; Wed, 5 Aug 2020 05:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, 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 pyiDpPRzkJI6 for ; Wed, 5 Aug 2020 05:34:00 -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 9C6213A02F9 for ; Wed, 5 Aug 2020 05:34:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id A012662422; Wed, 5 Aug 2020 08:33:16 -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 VlQRl3USiJpT; Wed, 5 Aug 2020 08:32:37 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (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 A768D62416; Wed, 5 Aug 2020 08:32:37 -0400 (EDT) To: Alexandre Petrescu Cc: "tm-rid@ietf.org" , Stephan Wenger References: <1bebf5b1-1fa5-6902-5bb7-9ec3582e6d9a@andersdotter.cc> <2990FBF0-FCB0-49CE-8F4B-BF5111CE5D57@tzi.org> <01a21161-aa8d-6d4b-b384-3129fe6d799b@gmail.com> <973223fd-0119-376d-12cd-21559a14ce87@labs.htt-consult.com> <3c632ce9-115d-11f5-ee33-bfabd4973522@labs.htt-consult.com> <7ddd9a2f-23ba-dd82-8cfb-1d2974969e67@gmail.com> <079a0a22-f46b-b0a7-de41-63cfb2d1574e@gmail.com> <0cf59fbe-68dc-aacd-eb92-5df8f55c9247@gmail.com> From: Robert Moskowitz Message-ID: <0386819e-a770-0339-4f99-570a3f4635ad@labs.htt-consult.com> Date: Wed, 5 Aug 2020 08:32:28 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <0cf59fbe-68dc-aacd-eb92-5df8f55c9247@gmail.com> Content-Type: multipart/alternative; boundary="------------0F8D5EC686BAC30398E52D8D" Content-Language: en-US Archived-At: Subject: Re: [Drip] ADSB X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 12:34:04 -0000 This is a multi-part message in MIME format. --------------0F8D5EC686BAC30398E52D8D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 8/5/20 8:13 AM, Alexandre Petrescu wrote: > > > Le 05/08/2020 à 13:41, Robert Moskowitz a écrit : >> >> >> On 8/5/20 5:53 AM, Alexandre Petrescu wrote: >>> Stephan, >>> >>> Le 04/08/2020 à 17:16, Stephan Wenger a écrit : >>>> Alexandre, >>>> >>>> ADS-B is a 20+ year old technology and offers properties (bandwidth, >>>>  security, cost) of a 20 year old technology.  That it just recently >>>>  sees widespread adoption is a result of incredibly slow (even by >>>> IETF standards) deployment process, and that in turn is the result of >>>> the very conservative and safety conscious aviation community and >>>> regulators, as well as the high cost related to anything manmade >>>> that flies.  By speculating to use ADS-B as an underlying technology >>>> for IP, I fear you demonstrate a certain lack of background. The >>>> Wikipedia article on ADS-B >>>> (https://en.wikipedia.org/wiki/Automatic_dependent_surveillance_–_broadcast) >>>> >>>> >>>> >>>> >>> is mostly correct, and I recommend in particular the sections on >>>> "Theory of operation" and "System Design Considerations". >>> >>> There is no worry to fear I demonstrate lack of background in this >>> field.  It is true.  I still need to learn many things here. >>> >>> I continue to look for a wireless link layer that is well adapted >>> for communication between flying devices (drones, flying taxis) and >>> ground.  And that would support very well IP. >>> >>> Maybe ADS-B is not that link, but Bluetooth isnt it either because too >>> low power. >>> >>> Maybe WiFi at 5.4GHz, which also used for remote control. >> >> I recommend you look at IEEE 802.15.16t: >> >> http://www.ieee802.org/15/pub/TG16t.html > > I looked at some of the slides of 802.15.16th of presentations in > July, 2020. > > The best I could understand is this: >   "The IEEE 802.15.16t Task Group is developing an amendment to >    802.16-2017. Project 802.16t “Amendment - Fixed and Mobile Wireless >    Access in Narrowband Channels” This project specifies operation in >    licensed spectrum with channel bandwidths greater than or equal to 5 >    kHz and less than 100 kHz. A new PHY will be specified, with changes >    to the MAC as necessary. The amendment is frequency independent but >    focuses on spectrum less than 2 GHz. Aggregated operation in adjacent >    and non-adjacent channels will be supported." > >> This is actually an addendum to 802.16.  A bit of 802 politics. >> 802.16 is in hibernation.  802 EC did not want to go through the >> process and risks of reactivating it for this work.  So they turned >> over management of the work to the 802.15 leadership. > > I see, that's why. > > So, the question that could be made to 802.15.16t is: would the new > 802.16 (the one including 802.15.16t) consider drones and their > identification as a potential use-case?  If yes, would the new 802.16 > like to use IP to carry the drone identification?  Or would the new > 802.16 rather carry the drone identification in a new 802.16 header > that sits below IP? > >> This is licensed spectrum.  The current use cases: >> >> https://mentor.ieee.org/802.15/documents?is_dcn=DCN%2C%20Title%2C%20Author%20or%20Affiliation&is_group=016t >> >> >> Does not include aviation, but so what?  Get one of the RF license >> holders in this business model and you are in business. >> >> Some of these frequencies have the bandwidth and range for practical >> use here. > > Fair enough. > > There would be however some differences between carrying drone > identification numbers by Bluetooth headers or by 802.16 headers.   > IEEE and Bluetooth SIG made different formats. Where do you see in any of the DRIP documents that the proposed Remote ID numbers are carried in the Bluetooth headers? In the Basic ID Message, the Remote ID IS the payload.  Look at Adam's slide 8 where he lays out the BT frame content for ASTM. There are 19 bytes of BT header and 25 bytes for ASTM content.  In the Basic ID Message, 20 of those 25 bytes are the Remote ID. Now where the BT header (4, 5, and even WiFi) comes in to play is that the RID is ONLY in the Basic ID message and some Authentication Message payloads.  So to determine which messages are from which UA, the MAC address is used as the value to link all messages from a UA to its RID. This is spelled out in the ASTM standard, and perhaps it should be restated in the drip-arch and drip-uas-rid drafts (actually I do think it is in there somewhere). > If one wanted a unique format for drone identification to be > transmitted on all these link layers similarly, one would need to use > IP.  IP sits ok on both 802.16 and on Bluetooth. No, you don't need IP.  Or you have to pay the cost of IP on media where it is very expensive. > > Alex > >> >>> >>> That aside, let me try to answer some of the points below. >>> >>>> A few (of many) reasons why ADS-B is unsuitable for light drones >>>> (anything significantly smaller than a man-carrying aircraft): -24 >>>> bit ICAO transponder code, limiting the number of (active or >>>> inactive) ADS-B equipment. Each modern aircraft over a certain size >>>>  (except the smallest two-seaters, powered parachutes, and aircraft >>>> without electrical systems such as antiques) has a unique code >>>> assigned for its lifetime. >>> >>> Ok.  But MAC addresses of Bluetooth also are limited.  They have 48bit >>> which is more than 24bit of ADS-B, but it is still limited. >>> >>>> -line-of-sight wireless connection for the "uplink" with only a few >>>> hundred ground stations for the whole US (or 70 for the whole >>>> Australia).  That means ADS-B coverage is almost everywhere only >>>> available at altitudes in which small drones are neither legal nor, >>>> in most cases, physically capable to fly (a few thousand feet in >>>> the US except near major airports where you don't want drones, >>>> 30000 ft in Australia).  Aircraft send over the uplink information >>>> such as aircraft ICAO code, aircraft type, speed, direction of >>>> flight, altitude, etc.). Information is sent in the clear, by >>>> design.  You can buy a box receiving this info, hook it up to an >>>> Raspberry PI or something, and look at the traffic near your house >>>> and send it on to your friends--in fact, this type of crowdsourced >>>> ATC info is what makes flightradar24 and similar sites work. >>> >>> This sounds like an argument in favor of using ADS-B for >>> identification, >>> not against.  Or maybe I dont understand. >>> >>> Only a few ground stations: I suspect this is around airport areas, >>> which is good. >>> >>> ADS-B messages sent by the ground stations only to altitudes where >>> drones are forbidden (I suspect above 150m or so): I dont think it is >>> possible to restrict the altitude at which a message is sent to. It >>> would be impossible for an ADS-B message sent by a ground station to >>> not >>> be heard at 100meters and only be heard at 200meters.  Or I do not >>> udnertsand. >>> >>> Planes that send ADS-B messages over the 'uplink'.  I think I have to >>> understand this better.  Until now I thought 'uplink' means a direction >>> from ground to up in the sky.  It is a distinct meaning than >>> networking. >>> >>> In networking, a smartphone has an uplink, but the base-station also >>> has >>> an uplink.  One's uplink is the other's downlink.  Compared to that, I >>> thought that in ADS-B the 'uplink' is only from ground up, but it seems >>> to not be so. >>> >>> >>>> -the downlink (system to aircraft) >>> >>> Again, I thought the 'downlink' is from the plane down to ground.   You >>> seem to say it reversely. >>> >>> I think the notion of 'uplink' and 'downlink' are with respect to a >>> device.  A device's uplink  is the other device's downlink, when they >>> communicate with each other. >>> >>>> is bandwidth-limited to a few hundred kbit/s for all aircraft >>>> combined in the coverage of the satellite transponder.  (This is >>>> somewhat over-simplified, as the uplink is intentionally sent in >>>> the clear, and many ADS-B receivers monitor the uplink of other >>>> aircraft for redundancy and more up-to-date information about >>>> traffic; see abive.) AFAIK, the whole continental US is covered by >>>> less than 20 transponders. N The downlink carries not only traffic >>>> information >>>> but also cruise and airport weather, certain airspace restrictions, >>>> and so forth.  All this is broadcasted and the ADS-B receivers in >>>> the aircraft need to filter out the information relevant for its >>>> position, course, and intentions.  Already, the bandwidth available >>>> is almost fully utilized to the point that the broadcast >>>> occasionally needs to omit certain less-critical information to make >>>> space for more critical one.  The system scales only by adding >>>> satellite transponders, which is expensive and not a fine >>>> granularity. >>> >>> I agree there might be bandwidth limitation that needs to be respected. >>> >>> It still is that putting an IP message on it can still work. >>> >>>> As for Mars, ADS-B is unsuitable until someone builds a >>>> ground-station network and has suitable satellites in orbit. >>> >>> YEs, the ground station would be on the rover and the satellite would >>> be on one of the stations (I dont know their names) that currently >>> hover >>> above Mars routinely. >>> >>>> A bit closer to earth, for over-water and trans-pole operations >>>> there is ADS-C, which is completely satellite based and, AFAIK, even >>>> more bandwidth limited than ADS-B.  Yet another example for a network >>>>  unsuitable to carry IP traffic, but I digress. >>>> >>>> In short, forget ADS-B for the DRIP work.. >>> >>> Ok, if no ADS-B for DRIP work, then Bluetooth?  Is it more appropriate? >>> >>> Knowing that Bluetooth has a typical range of 10meter (I mean distance >>> range), is it reasonable to rely on it for identifying drones at >>> several hundred meters away? >>> >>> Knowing that Bluetooth is lower power than WiFi at 5.4Ghz, and that >>> that >>> 5.4GHz is already used to control drone flight, video, etc, is it >>> preferrable to use Bluetooth instead of that WiFi at 5.4GHz? >>> >>> Alex >>> >>>> >>>> Stephan >>>> >>>> >>>> On 8/4/20, 6:53 AM, "Tm-rid on behalf of Alexandre Petrescu" >>>> >>>> wrote: >>>> >>>> architectural layers discussion... >>>> >>>> Le 30/07/2020 à 11:49, shuaiizhao(Shuai Zhao) a écrit : >>>>> Just to echo Stu on the ADSB, AFAIK, ADSB will  not be feasible >>>>> for most of the drones mostly due to SwaP, commercial drones might >>>>> be exception. >>>> >>>> It might be that ADS-B might be forbidden in drones on Earth, but >>>> how about the drones on Mars? ('NASA Mars helicopters', or ESA too). >>>> On Mars there would be much less such drones, so less risk of >>>> interference. >>>> >>>> With such a system (ADS-B under IP) one could re-use DTN (Delay >>>> Tolerant Networking) between planets, and so identify drones even on >>>>  Mars. >>>> >>>> But if we have reluctance about the use of ADS-B, and thus of IP, and >>>> we recommend Bluetooth-without-IP to identify drones, then we might >>>> become too dependent on it? >>>> >>>> (do not get me wrong, I do like Bluetooth, but I like many other >>>> things together with Bluetooth). >>>> >>>> Alex >>>> >>>>> >>>>> Best, >>>>> >>>>> Shuai Zhao >>>>> >>>>> *From: *Tm-rid on behalf of "Stuart W. >>>>> Card" *Date: *Wednesday, July 29, 2020 >>>>>  at 19:46 *To: *"tm-rid@ietf.org" *Subject: >>>>> *[Drip] ADSB (was: Review of draft-drip-arch-02 w.r.t. RFC6973, >>>>> RFC8280 and other)(Internet mail) >>>>> >>>>> Sorry for the slow reply. >>>>> >>>>> ADS-B is gradually being mandated for essentially all manned >>>>> aircraft. >>>>> >>>>> ADSB-In and ADSB-Out are mandated for airliners: -In gives their >>>>> pilots >>>>> >>>>> some Situational Awareness (SA) of other aircraft; -Out gives other >>>>> >>>>> pilots SA of the airliners. >>>>> >>>>> "ADSB-Out" is mandated even for small general aviation aircraft: >>>>> it does >>>>> >>>>> not directly benefit the pilots of those aircraft; but by >>>>> providing SA >>>>> >>>>> to others, it indirectly benefits all. >>>>> >>>>> ADSB is _not_ going to be deployed on large numbers of small UAS >>>>> as it >>>>> >>>>> would overwhelm the limited bandwidth available at those lower radio >>>>> >>>>> frequencies (which propagate long ranges). In fact, it is expected >>>>>  to be >>>>> >>>>> explicitly prohibited in the US per the FAA NPRM; I suspect most >>>>> of the >>>>> >>>>> rest of the world will do likewise. >>>>> >>>>> ADSB is also altogether insecure. >>>>> >>>>> On 7/9/2020 3:02 AM, Alexandre Petrescu wrote: >>>>> >>>>> ... >>>>> >>>>> They call it "ADS-B Receivers" (Automatic Dependent Surveillance - >>>>> >>>>> Broadcast). >>>>> >>>>> I wouuld like to ask if there is a packet dump available showing such >>>>> >>>>> presence data form planes?  Maybe wireshark already supports it, >>>>> maybe >>>>> >>>>> it even dissects it... >>>>> >>>>> -- >>>>> >>>>> ----------------------------------------- >>>>> >>>>> Stuart W. Card, PhD, Principal Engineer >>>>> >>>>> AX Enterprize, LLC www.axenterprize.com >>>>> >>>>> 4947 Commercial Drive, Yorkville NY 13495 >>>>> >>>>> >>>> >>>> -- Tm-rid mailing list Tm-rid@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tm-rid >>>> >>> >> >> -- >> 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 > -- 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 --------------0F8D5EC686BAC30398E52D8D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 8/5/20 8:13 AM, Alexandre Petrescu wrote:


Le 05/08/2020 à 13:41, Robert Moskowitz a écrit :


On 8/5/20 5:53 AM, Alexandre Petrescu wrote:
Stephan,

Le 04/08/2020 à 17:16, Stephan Wenger a écrit :
Alexandre,

ADS-B is a 20+ year old technology and offers properties (bandwidth,
 security, cost) of a 20 year old technology.  That it just recently
 sees widespread adoption is a result of incredibly slow (even by
IETF standards) deployment process, and that in turn is the result of
the very conservative and safety conscious aviation community and regulators, as well as the high cost related to anything manmade
that flies.  By speculating to use ADS-B as an underlying technology
for IP, I fear you demonstrate a certain lack of background. The Wikipedia article on ADS-B (https://en.wikipedia.org/wiki/Automatic_dependent_surveillance_–_broadcast)




is mostly correct, and I recommend in particular the sections on
"Theory of operation" and "System Design Considerations".

There is no worry to fear I demonstrate lack of background in this
field.  It is true.  I still need to learn many things here.

I continue to look for a wireless link layer that is well adapted
for communication between flying devices (drones, flying taxis) and
ground.  And that would support very well IP.

Maybe ADS-B is not that link, but Bluetooth isnt it either because too
low power.

Maybe WiFi at 5.4GHz, which also used for remote control.

I recommend you look at IEEE 802.15.16t:

http://www.ieee802.org/15/pub/TG16t.html

I looked at some of the slides of 802.15.16th of presentations in July, 2020.

The best I could understand is this:
  "The IEEE 802.15.16t Task Group is developing an amendment to
   802.16-2017. Project 802.16t “Amendment - Fixed and Mobile Wireless
   Access in Narrowband Channels” This project specifies operation in
   licensed spectrum with channel bandwidths greater than or equal to 5
   kHz and less than 100 kHz. A new PHY will be specified, with changes
   to the MAC as necessary. The amendment is frequency independent but
   focuses on spectrum less than 2 GHz. Aggregated operation in adjacent
   and non-adjacent channels will be supported."

This is actually an addendum to 802.16.  A bit of 802 politics. 802.16 is in hibernation.  802 EC did not want to go through the process and risks of reactivating it for this work.  So they turned over management of the work to the 802.15 leadership.

I see, that's why.

So, the question that could be made to 802.15.16t is: would the new 802.16 (the one including 802.15.16t) consider drones and their identification as a potential use-case?  If yes, would the new 802.16 like to use IP to carry the drone identification?  Or would the new 802.16 rather carry the drone identification in a new 802.16 header that sits below IP?

This is licensed spectrum.  The current use cases:

https://mentor.ieee.org/802.15/documents?is_dcn=DCN%2C%20Title%2C%20Author%20or%20Affiliation&is_group=016t

Does not include aviation, but so what?  Get one of the RF license holders in this business model and you are in business.

Some of these frequencies have the bandwidth and range for practical use here.

Fair enough.

There would be however some differences between carrying drone identification numbers by Bluetooth headers or by 802.16 headers.   IEEE and Bluetooth SIG made different formats.

Where do you see in any of the DRIP documents that the proposed Remote ID numbers are carried in the Bluetooth headers?

In the Basic ID Message, the Remote ID IS the payload.  Look at Adam's slide 8 where he lays out the BT frame content for ASTM.  There are 19 bytes of BT header and 25 bytes for ASTM content.  In the Basic ID Message, 20 of those 25 bytes are the Remote ID.

Now where the BT header (4, 5, and even WiFi) comes in to play is that the RID is ONLY in the Basic ID message and some Authentication Message payloads.  So to determine which messages are from which UA, the MAC address is used as the value to link all messages from a UA to its RID.

This is spelled out in the ASTM standard, and perhaps it should be restated in the drip-arch and drip-uas-rid drafts (actually I do think it is in there somewhere).

If one wanted a unique format for drone identification to be transmitted on all these link layers similarly, one would need to use IP.  IP sits ok on both 802.16 and on Bluetooth.

No, you don't need IP.  Or you have to pay the cost of IP on media where it is very expensive.


Alex



That aside, let me try to answer some of the points below.

A few (of many) reasons why ADS-B is unsuitable for light drones (anything significantly smaller than a man-carrying aircraft): -24 bit ICAO transponder code, limiting the number of (active or inactive) ADS-B equipment. Each modern aircraft over a certain size
 (except the smallest two-seaters, powered parachutes, and aircraft without electrical systems such as antiques) has a unique code assigned for its lifetime.

Ok.  But MAC addresses of Bluetooth also are limited.  They have 48bit
which is more than 24bit of ADS-B, but it is still limited.

-line-of-sight wireless connection for the "uplink" with only a few hundred ground stations for the whole US (or 70 for the whole Australia).  That means ADS-B coverage is almost everywhere only available at altitudes in which small drones are neither legal nor, in most cases, physically capable to fly (a few thousand feet in the US except near major airports where you don't want drones, 30000 ft in Australia).  Aircraft send over the uplink information such as aircraft ICAO code, aircraft type, speed, direction of flight, altitude, etc.). Information is sent in the clear, by design.  You can buy a box receiving this info, hook it up to an Raspberry PI or something, and look at the traffic near your house and send it on to your friends--in fact, this type of crowdsourced ATC info is what makes flightradar24 and similar sites work.

This sounds like an argument in favor of using ADS-B for identification,
not against.  Or maybe I dont understand.

Only a few ground stations: I suspect this is around airport areas,
which is good.

ADS-B messages sent by the ground stations only to altitudes where
drones are forbidden (I suspect above 150m or so): I dont think it is
possible to restrict the altitude at which a message is sent to. It
would be impossible for an ADS-B message sent by a ground station to not
be heard at 100meters and only be heard at 200meters.  Or I do not
udnertsand.

Planes that send ADS-B messages over the 'uplink'.  I think I have to
understand this better.  Until now I thought 'uplink' means a direction
from ground to up in the sky.  It is a distinct meaning than networking.

In networking, a smartphone has an uplink, but the base-station also has
an uplink.  One's uplink is the other's downlink.  Compared to that, I
thought that in ADS-B the 'uplink' is only from ground up, but it seems
to not be so.


-the downlink (system to aircraft)

Again, I thought the 'downlink' is from the plane down to ground.   You
seem to say it reversely.

I think the notion of 'uplink' and 'downlink' are with respect to a
device.  A device's uplink  is the other device's downlink, when they
communicate with each other.

is bandwidth-limited to a few hundred kbit/s for all aircraft combined in the coverage of the satellite transponder.  (This is somewhat over-simplified, as the uplink is intentionally sent in the clear, and many ADS-B receivers monitor the uplink of other aircraft for redundancy and more up-to-date information about traffic; see abive.) AFAIK, the whole continental US is covered by less than 20 transponders. N The downlink carries not only traffic information
but also cruise and airport weather, certain airspace restrictions,
and so forth.  All this is broadcasted and the ADS-B receivers in
the aircraft need to filter out the information relevant for its position, course, and intentions.  Already, the bandwidth available is almost fully utilized to the point that the broadcast
occasionally needs to omit certain less-critical information to make
space for more critical one.  The system scales only by adding
satellite transponders, which is expensive and not a fine
granularity.

I agree there might be bandwidth limitation that needs to be respected.

It still is that putting an IP message on it can still work.

As for Mars, ADS-B is unsuitable until someone builds a ground-station network and has suitable satellites in orbit.

YEs, the ground station would be on the rover and the satellite would
be on one of the stations (I dont know their names) that currently hover
above Mars routinely.

A bit closer to earth, for over-water and trans-pole operations
there is ADS-C, which is completely satellite based and, AFAIK, even
more bandwidth limited than ADS-B.  Yet another example for a network
 unsuitable to carry IP traffic, but I digress.

In short, forget ADS-B for the DRIP work..

Ok, if no ADS-B for DRIP work, then Bluetooth?  Is it more appropriate?

Knowing that Bluetooth has a typical range of 10meter (I mean distance
range), is it reasonable to rely on it for identifying drones at
several hundred meters away?

Knowing that Bluetooth is lower power than WiFi at 5.4Ghz, and that that
5.4GHz is already used to control drone flight, video, etc, is it
preferrable to use Bluetooth instead of that WiFi at 5.4GHz?

Alex


Stephan


On 8/4/20, 6:53 AM, "Tm-rid on behalf of Alexandre Petrescu" <tm-rid-bounces@ietf.org on behalf of alexandre.petrescu@gmail.com> wrote:

architectural layers discussion...

Le 30/07/2020 à 11:49, shuaiizhao(Shuai Zhao) a écrit :
Just to echo Stu on the ADSB, AFAIK, ADSB will  not be feasible
for most of the drones mostly due to SwaP, commercial drones might
be exception.

It might be that ADS-B might be forbidden in drones on Earth, but
how about the drones on Mars? ('NASA Mars helicopters', or ESA too).
On Mars there would be much less such drones, so less risk of interference.

With such a system (ADS-B under IP) one could re-use DTN (Delay Tolerant Networking) between planets, and so identify drones even on
 Mars.

But if we have reluctance about the use of ADS-B, and thus of IP, and
we recommend Bluetooth-without-IP to identify drones, then we might
become too dependent on it?

(do not get me wrong, I do like Bluetooth, but I like many other things together with Bluetooth).

Alex


Best,

Shuai Zhao

*From: *Tm-rid <tm-rid-bounces@ietf.org> on behalf of "Stuart W. Card" <stu.card@axenterprize.com> *Date: *Wednesday, July 29, 2020
 at 19:46 *To: *"tm-rid@ietf.org" <tm-rid@ietf.org> *Subject: *[Drip] ADSB (was: Review of draft-drip-arch-02 w.r.t. RFC6973, RFC8280 and other)(Internet mail)

Sorry for the slow reply.

ADS-B is gradually being mandated for essentially all manned aircraft.

ADSB-In and ADSB-Out are mandated for airliners: -In gives their pilots

some Situational Awareness (SA) of other aircraft; -Out gives other

pilots SA of the airliners.

"ADSB-Out" is mandated even for small general aviation aircraft:
it does

not directly benefit the pilots of those aircraft; but by
providing SA

to others, it indirectly benefits all.

ADSB is _not_ going to be deployed on large numbers of small UAS
as it

would overwhelm the limited bandwidth available at those lower radio

frequencies (which propagate long ranges). In fact, it is expected
 to be

explicitly prohibited in the US per the FAA NPRM; I suspect most
of the

rest of the world will do likewise.

ADSB is also altogether insecure.

On 7/9/2020 3:02 AM, Alexandre Petrescu wrote:

...

They call it "ADS-B Receivers" (Automatic Dependent Surveillance -

Broadcast).

I wouuld like to ask if there is a packet dump available showing such

presence data form planes?  Maybe wireshark already supports it, maybe

it even dissects it...

-- 

-----------------------------------------

Stuart W. Card, PhD, Principal Engineer

AX Enterprize, LLC www.axenterprize.com

4947 Commercial Drive, Yorkville NY 13495



-- Tm-rid mailing list Tm-rid@ietf.org https://www.ietf.org/mailman/listinfo/tm-rid



-- 
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


--
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
--------------0F8D5EC686BAC30398E52D8D-- From nobody Wed Aug 5 05:37:15 2020 Return-Path: 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 C70B13A05A7 for ; Wed, 5 Aug 2020 05:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_NONE=0.001, SPF_PASS=-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 Adnw3-S3oLlD for ; Wed, 5 Aug 2020 05:37:12 -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 C6AA33A0598 for ; Wed, 5 Aug 2020 05:37:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 8EDFC62454 for ; Wed, 5 Aug 2020 08:37:11 -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 Tchm1Db8X826 for ; Wed, 5 Aug 2020 08:37:09 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (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 64C4B62434 for ; Wed, 5 Aug 2020 08:37:08 -0400 (EDT) To: "tm-rid@ietf.org" From: Robert Moskowitz Message-ID: Date: Wed, 5 Aug 2020 08:37:04 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Drip] lpwan for DRIP? X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 12:37:14 -0000 Perhaps anyone interested in defining how DRIP broadcast would look over IP multicast could write a draft following lpwan IP header compression, so that the IP and transport headers are compressed to zero bytes by using content in the media header.  This is what has been done for other lpwan media. I welcome anyone interested to look at lpwan and then propose such an approach here. I have other items demanding my attention. From nobody Wed Aug 5 05:50:20 2020 Return-Path: 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 E6AA23A081C for ; Wed, 5 Aug 2020 05:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.278 X-Spam-Level: X-Spam-Status: No, score=-0.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.949, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 GtBW-TL9AoXg for ; Wed, 5 Aug 2020 05:50:15 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 9BA2C3A07F7 for ; Wed, 5 Aug 2020 05:50:15 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 075CoD9T045632; Wed, 5 Aug 2020 14:50:13 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E17DC203D01; Wed, 5 Aug 2020 14:50:13 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D249B2019FD; Wed, 5 Aug 2020 14:50:13 +0200 (CEST) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 075CoDOb007143; Wed, 5 Aug 2020 14:50:13 +0200 To: Robert Moskowitz , tm-rid@ietf.org References: <1bebf5b1-1fa5-6902-5bb7-9ec3582e6d9a@andersdotter.cc> <01a21161-aa8d-6d4b-b384-3129fe6d799b@gmail.com> <973223fd-0119-376d-12cd-21559a14ce87@labs.htt-consult.com> <3c632ce9-115d-11f5-ee33-bfabd4973522@labs.htt-consult.com> <7ddd9a2f-23ba-dd82-8cfb-1d2974969e67@gmail.com> <61511ef6-5b9b-5b62-f922-d32b994a35b9@gmail.com> From: Alexandre Petrescu Message-ID: Date: Wed, 5 Aug 2020 14:50:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Drip] ADSB X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 12:50:18 -0000 Le 05/08/2020 à 13:53, Robert Moskowitz a écrit : > > > On 8/5/20 6:11 AM, Alexandre Petrescu wrote: >> >> >> Le 04/08/2020 à 17:51, Robert Moskowitz a écrit : >>> >>> >>> On 8/4/20 11:27 AM, Alexandre Petrescu wrote: >>>> Thanks for the clarification. >>>> >>>> Le 04/08/2020 à 17:17, Stuart W. Card a écrit : >>>>> I just want to respond to one line that I think comes from >>>>> confusion: >>>>> >>>>>> But if we have reluctance about the use of ADS-B, and thus >>>>>> of IP, and we recommend Bluetooth-without-IP to identify >>>>>> drones >>>>> >>>>> We aren't recommending Bluetooth-without-IP, we are >>>>> _supporting_ it, >>>> >>>> But, the security manifest that I have seen on slides during >>>> the presentation of the DRIP WG meeting - is something below >>>> IP, right? >>> >>> For now, we are dealing with broadcast messages. Either over >>> Bluetooth or WiFI (NAN). >> >> If it is a broadcast message and it is over Bluetooth or over WiFi >> then it certainly is IP multicast, cant be anything else. > > Wrong for BT4. There are only 25 bytes available. We can do most > of the messaging in a single frame. To do anything with IP will > force this to a multiframe design. I might say something stupid if I am allowed, maybe things that are already known. Sorry, I did not check the BoF archive discussion. But here goes anyways. If one wants to do something with Bluetooth4 below IP and finds it to be too small packets, then there could be several possibilities: - do it at Bluetooth SIG instead of IETF; - do it in 6lo WG; - use a header compression scheme at IETF (6lowpan HC at 6lo WG, SCHC at LP-WAN WG, ROHC and why not CBOR); - implement packet fragmentation and reassembly and multiframe design below IP; - use the already available data in the 25 bytes in order to realize that identification (there must be MAC addresses in there, and they're likely to be useful). > Even BT5 it is wrong for the Authentication Message. We need the > full frame for our content. We would have to go with multiframe > design for BT5 as a result. So, I do not understand: does DRIP want the entire packet to stay of size 25bytes? Or does DRIP want the packet to be more than 25bytes? Would a multiframe design in which an IP packet of length 1280bytes is chopped into 25bytes BT5 packets be advantageous for DRIP? Do the BT5 packets have a notion of interlinking between sub-packets that make a bigger packet? (such a mechanism exists at the IP layer; it uses Identification to identify a chain and an Offset to say where in the chain is that sub-packet to be found). > So this leaves WiFi NAN. Sure you can do it, but why? What does it > add? In My Not So Humble Opinion (IMNSOHO) nothing but cost and > processing overhead. I think WiFi 5.4 GHz is already used extensively to remotely control drones. These consoles with joysticks are WiFi 5.4GHz, if I am not mistaken. >> If it is IP multicast over Bluetooth or over WiFi then I wonder >> what is the value in the Next Header field of the IP header >> format (RFC8200 "IPv6", section 3 "Header format"). Basically - >> what is the payload? >> >> If one asks me, I would dare to think that payload might be an >> ICMPv6 Router Advertisement. >> >>> There is NO security for the messages below the message package. >> >> Noted. >> >>> Just not enough payload size for anything that would work in a >>> broadcast environment like a National Airspace. All of the >>> security we are specifying is inside the messages where >>> appropriate. >>> >>> That security manifest is a payload of the ASTM F3411-19 >>> Authentication Message. >> >> It costs 85USD I wont pay to see it. It is security. There will >> always be someone smarter to break that security and ask for more >> money. > > Look at: > > https://github.com/opendroneid/specs/blob/master/OpenDroneID_Bluetooth_0.64.3.pdf > > > It is close enough. Thanks for the pointer. Noted. It is about Bluetooth. Should be submitted to Bluetooth SIG. I might stay something stupid here again... si I wont say it :-) >> I would not oppose if that Authentication MEssage had a >> specification in clear. > > The above plus Adam's draft will get you there. > >> >>> These messages are broadcasted as Adam mentioned in his 'flying >>> DRIP' comments at the beginning. >> >> Thank you for the reminder. I looked again at the 'flying DRIP' >> presentation during the WG meeting, and at the related draft. >> https://datatracker.ietf.org/meeting/108/materials/slides-108-drip-authentication-formats >> >> >> >> and draft-wiethuechter-drip-auth-01 >> >> During the presentation, the slide clearly shows on slide 8 that a >> Bluetooth header immediately precedes an Open Drone ID message. >> There is no IP header in that slide. > > That is right. No IP. No room for it. No justification for it. It > is all RLOS only. I might say something stupid here: no IP? No IETF. >> In the draft, there is similar discussion tightly related to >> Bluetooth and without IP. >> >> But if we are to have an independence of Bluetooth, and use a >> networking layer such as IP, then the question of the use of an >> authentication header is made differently. > > Again what is the justification for adding IP multicast? I would not be afraid of IP multicast like the multicast we know for video delivery. It is IP multicast because IP is IPv6 and IPv6 has no broadcast. _If_ there is agreement that DRIP should be with IP (Internet Protocol). We know that the drone identification should be broadcasted (like in TV broadcast). In IPv4 there is a mechanism to implement such TV-broadcast concept. It is called IPv4 broadcast. That broadcast is sent to a dedicated address (like 255.255.255.255 which is all Internet, or like 195.212.142.255 which is all computers in a particular subnet). In IPv6 such broadcast concept does not exist. Rather, it's called 'multicast' and, as opposed to IPv4, it has a mandatory and voluntary join/leave mechanism. I name that IPv6 multicast simply IP multicast, because IPv4 should not be used as basis for any new work at IETF. On such an IP multicast perspective for DRIP, one would have to come up with an architecture for joining and leaving that makes it easy to use by authorities, mandatory to implement, is secure enough (security and multicast is not that easy), etc. > Where do you see these messages going beyond the RF Line Of Sight? True. But one would not want all BT5 devices (like my watch or earphones) around a drone's sight to be awaken by its identification beacons, right? Only those devices who have voluntarily subscribed to that multicast group would be awaken. >> The authentication header would be an IP Authentication Header. >> This AH would be somehow re-used and extended where necessary for >> DRIP purposes. >> >>> Now later I expect us to move on to Network Remote ID and Command >>> and Control (C2). >>> >>> Most C2 (e.g. Mavlink) is directly over the MAC, but there is a >>> method to run it over UDP (I forget the UDP port commonly >>> used...). AX Enterprize has done this using HIP so the UA starts >>> with WiFi over the launch point, transitions to LTE, and on >>> return back to WiFi. >>> >>> Network Remote ID can work either directly from the UA, or via >>> C2 information to the GCS, from the GCS. In either case, IP is >>> assumed. This will probably be done via UDP. From the UA, >>> mobility will be important; from the GCS nice to have (most GCS >>> will be stable location). As UDP to a fixed Net-SP, DTLS 1.3 is >>> a viable alternative to HIP. >> >> I will have to look closer at HIP again :-) and see how it could >> be made to work with DRIP and IP. > > Stu, Adam, Andrei, and I see HIP for where there is pairwise > communication with potentially both ends mobile and using multiple > interfaces. Once you have that use case, be consistent and use it > for simpler situations. I wanted to ask whether using a Host Identity that is cryptographically generated is sufficient for authorities to trust a drone upon reception of one DRIP identification packet, or maybe am additional roundrip (a ping, a request-response) would still be needed from ground officer to drone to make sure it's the right drone who replies? Or maybe a full Diffie-Hellman exchange is needed? Alex > >> >> Alex >> >>> >>> >>> >>> >>>> >>>> Alex >>>> >>>> as >>>>> it is specified in ASTM F3411, which most of the regulators >>>>> are dubbing as an approved technical means of regulatory >>>>> compliance. >>>>> >>>>> AFAIK, no one runs IP over ADS-B, which was designed as a >>>>> narrowband application specific communications stovepipe, >>>>> not a data link supporting higher layer network protocols, >>>>> so not great for IP. >>>>> >>>>> More importantly, we have no "reluctance about the use of... >>>>> IP", which is an entirely separate issue from ADS-B. >>>>> >>>>> On 8/4/2020 9:52 AM, Alexandre Petrescu wrote: >>>>>> architectural layers discussion... >>>>>> >>>>>> Le 30/07/2020 à 11:49, shuaiizhao(Shuai Zhao) a écrit : >>>>>>> Just to echo Stu on the ADSB, AFAIK, ADSB will not be >>>>>>> feasible for most of the drones mostly due to SwaP, >>>>>>> commercial drones might be exception. >>>>>> >>>>>> It might be that ADS-B might be forbidden in drones on >>>>>> Earth, but how about the drones on Mars? ('NASA Mars >>>>>> helicopters', or ESA too). On Mars there would be much >>>>>> less such drones, so less risk of interference. >>>>>> >>>>>> With such a system (ADS-B under IP) one could re-use DTN >>>>>> (Delay Tolerant Networking) between planets, and so >>>>>> identify drones even on Mars. >>>>>> >>>>>> But if we have reluctance about the use of ADS-B, and thus >>>>>> of IP, and we recommend Bluetooth-without-IP to identify >>>>>> drones, then we might become too dependent on it? >>>>>> >>>>>> (do not get me wrong, I do like Bluetooth, but I like many >>>>>> other things together with Bluetooth). >>>>>> >>>>>> Alex >>>>>> >>>>>>> >>>>>>> Best, >>>>>>> >>>>>>> Shuai Zhao >>>>>>> >>>>>>> *From: *Tm-rid on behalf of >>>>>>> "Stuart W. Card" *Date: >>>>>>> *Wednesday, July 29, 2020 at 19:46 *To: >>>>>>> *"tm-rid@ietf.org" *Subject: *[Drip] >>>>>>> ADSB (was: Review of draft-drip-arch-02 w.r.t. RFC6973, >>>>>>> RFC8280 and other)(Internet mail) >>>>>>> >>>>>>> Sorry for the slow reply. >>>>>>> >>>>>>> ADS-B is gradually being mandated for essentially all >>>>>>> manned aircraft. >>>>>>> >>>>>>> ADSB-In and ADSB-Out are mandated for airliners: -In >>>>>>> gives their pilots >>>>>>> >>>>>>> some Situational Awareness (SA) of other aircraft; -Out >>>>>>> gives other >>>>>>> >>>>>>> pilots SA of the airliners. >>>>>>> >>>>>>> "ADSB-Out" is mandated even for small general aviation >>>>>>> aircraft: it does >>>>>>> >>>>>>> not directly benefit the pilots of those aircraft; but >>>>>>> by providing SA >>>>>>> >>>>>>> to others, it indirectly benefits all. >>>>>>> >>>>>>> ADSB is _not_ going to be deployed on large numbers of >>>>>>> small UAS as it >>>>>>> >>>>>>> would overwhelm the limited bandwidth available at those >>>>>>> lower radio >>>>>>> >>>>>>> frequencies (which propagate long ranges). In fact, it >>>>>>> is expected to be >>>>>>> >>>>>>> explicitly prohibited in the US per the FAA NPRM; I >>>>>>> suspect most of the >>>>>>> >>>>>>> rest of the world will do likewise. >>>>>>> >>>>>>> ADSB is also altogether insecure. >>>>>>> >>>>>>> On 7/9/2020 3:02 AM, Alexandre Petrescu wrote: >>>>>>> >>>>>>> ... >>>>>>> >>>>>>> They call it "ADS-B Receivers" (Automatic Dependent >>>>>>> Surveillance - >>>>>>> >>>>>>> Broadcast). >>>>>>> >>>>>>> I wouuld like to ask if there is a packet dump available >>>>>>> showing such >>>>>>> >>>>>>> presence data form planes? Maybe wireshark already >>>>>>> supports it, maybe >>>>>>> >>>>>>> it even dissects it... >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> ----------------------------------------- >>>>>>> >>>>>>> Stuart W. Card, PhD, Principal Engineer >>>>>>> >>>>>>> AX Enterprize, LLC www.axenterprize.com >>>>>>> >>>>>>> 4947 Commercial Drive, Yorkville NY 13495 >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> -- 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 > > -- 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 From nobody Wed Aug 5 06:20:42 2020 Return-Path: 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 CCAB13A064A for ; Wed, 5 Aug 2020 06:20:41 -0700 (PDT) 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=axenterprize.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 22PRs37hUr-K for ; Wed, 5 Aug 2020 06:20:40 -0700 (PDT) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC95B3A073E for ; Wed, 5 Aug 2020 06:20:39 -0700 (PDT) Received: by mail-ej1-x62c.google.com with SMTP id l4so46306412ejd.13 for ; Wed, 05 Aug 2020 06:20:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axenterprize.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AW+4k1qA8/Hc5vb5eJEmeYoC88tqgvzgc5mEXUBA718=; b=LIOCL3UWSY76P7nP/VfCLnLWetnO0FuNR6e8V9dz3Yr5zsa53wdVeyYx5OaKdOmTme /QT50ePuUCMT5d61PlKsyvAyrFvXjcaRu38sBgCEunaoVyyk4UtWkjiSxJbE08hjJ+/l E2Y1o4l1Pg6VEELT0VRDpPz7U5fIacZLbOhZw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AW+4k1qA8/Hc5vb5eJEmeYoC88tqgvzgc5mEXUBA718=; b=hTBESxB6tlLFx/RWBN5dn+9K9O9GOJluWoq1qX9bEf4Dl/cv6Of0rt4iZX+Mr03Vdg xN9QHvAk9Kqwm1weP7Qy/n3Lwc73AfZfMFRxre8u1O5SoiH/aLSLbstmBIZEgbr6ME+4 tkVhKUXj3DIpHb248s4PHHZTiwJmF13lDspRmxqwK4zjEdVFCu48vXusCvpv4ACuge3u DbdTC4/KGtz7AhJQYXuzFsVFWKg4vlh4yCto9vzBkjhBYjjXRz6XK1vtZyirCA29ZSCT qSionVVAlZCJ/mFxXOO+tN3CbHBJXi8Ky2RXcS9J52nnSQkJo75gvZS/aCbFmoPKwyhp DsTw== X-Gm-Message-State: AOAM5338aeRlnOJAhHwQ1tTZIx8YHh48TacAopHiQPKGq8hjjrJMazl8 f5HwuTEt5oFtbmXsvamlBGh4s0RJpwvYBcVzoB25tA== X-Google-Smtp-Source: ABdhPJxJTKR4vZnSXvyebqWXY7KLIWYseKUIssatRXFxHPFsO6tTqhBSH2oMjXBZFapry/w8hrsUrc8yLDo9enLf0e8= X-Received: by 2002:a17:906:c7d4:: with SMTP id dc20mr3302127ejb.283.1596633637878; Wed, 05 Aug 2020 06:20:37 -0700 (PDT) MIME-Version: 1.0 References: <1bebf5b1-1fa5-6902-5bb7-9ec3582e6d9a@andersdotter.cc> <2990FBF0-FCB0-49CE-8F4B-BF5111CE5D57@tzi.org> <01a21161-aa8d-6d4b-b384-3129fe6d799b@gmail.com> <973223fd-0119-376d-12cd-21559a14ce87@labs.htt-consult.com> <3c632ce9-115d-11f5-ee33-bfabd4973522@labs.htt-consult.com> <7ddd9a2f-23ba-dd82-8cfb-1d2974969e67@gmail.com> <61511ef6-5b9b-5b62-f922-d32b994a35b9@gmail.com> <18020_1596618809_5F2A7839_18020_102_1_787AE7BB302AE849A7480A190F8B9330315183A1@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <18020_1596618809_5F2A7839_18020_102_1_787AE7BB302AE849A7480A190F8B9330315183A1@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: "Card, Stu" Date: Wed, 5 Aug 2020 09:20:26 -0400 Message-ID: To: mohamed.boucadair@orange.com Cc: tm-rid@ietf.org Content-Type: multipart/alternative; boundary="000000000000d2934a05ac213c51" Archived-At: Subject: Re: [Drip] ADSB X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 13:20:42 -0000 --000000000000d2934a05ac213c51 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Will do. On Wed, Aug 5, 2020, 5:13 AM wrote: > Hi Stu, > > I remember that Andrei raised in the past a question about the use of > ADB-S. I suspect that others may make a similar comment in the future. > Having some text in draft-ietf-drip-arch reflecting the main arguments > shared in this thread (by Shuai, Bob, Stephan, you) will be useful. > > Can you please consider adding such text to the draft? > > Thank you. > > Cheers, > Med > > > -----Message d'origine----- > > De : Tm-rid [mailto:tm-rid-bounces@ietf.org] De la part de Stuart W. > > Card > > Envoy=C3=A9 : mardi 4 ao=C3=BBt 2020 19:12 > > =C3=80 : tm-rid@ietf.org > > Objet : Re: [Drip] ADSB > > > > The proposed manifest and other DRIP authentication related structures > > are all independent of transport, but designed to work with the most > > constraining transport thus specified by regulators and/or other SDOs, > > that being ASTM F3411 Broadcast RID over Bluetooth 4. > > > > So, for Broadcast RID, they would be encapsulated in ASTM F3411 > > messages over Bluetooth 4, Bluetooth 5 or WiFi Neighbor Awareness > > Networking (without IP). > > > > For Network RID, they could be carried in any IP based transport, > > HTTPS/TCP/IP initially (although, for Network RID, some of them are > > superfluous). > > > > On 8/4/2020 11:27 AM, Alexandre Petrescu wrote: > > > Thanks for the clarification. > > > > > > Le 04/08/2020 =C3=A0 17:17, Stuart W. Card a =C3=A9crit : > > >> I just want to respond to one line that I think comes from > > confusion: > > >> > > >>> But if we have reluctance about the use of ADS-B, and thus of IP, > > >>> and we recommend Bluetooth-without-IP to identify drones > > >> > > >> We aren't recommending Bluetooth-without-IP, we are _supporting_ > > it, > > > > > > But, the security manifest that I have seen on slides during the > > > presentation of the DRIP WG meeting - is something below IP, right? > > > > > > -- > > ----------------------------------------- > > Stuart W. Card, PhD, Principal Engineer > > AX Enterprize, LLC www.axenterprize.com > > 4947 Commercial Drive, Yorkville NY 13495 > > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. > > --000000000000d2934a05ac213c51 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Will do.

On Wed, Aug 5, 2020, 5:13 AM <mohamed.boucadair@orange.com> wrote= :
Hi Stu,

I remember that Andrei raised in the past a question about the use of ADB-S= . I suspect that others may make a similar comment in the future.
Having some text in draft-ietf-drip-arch reflecting the main arguments shar= ed in this thread (by Shuai, Bob, Stephan, you) will be useful.

Can you please consider adding such text to the draft?

Thank you.

Cheers,
Med

> -----Message d'origine-----
> De=C2=A0: Tm-rid [mailto:tm-rid-bounces@ietf.org] De la part = de Stuart W.
> Card
> Envoy=C3=A9=C2=A0: mardi 4 ao=C3=BBt 2020 19:12
> =C3=80=C2=A0: tm-rid@ietf.org
> Objet=C2=A0: Re: [Drip] ADSB
>
> The proposed manifest and other DRIP authentication related structures=
> are all independent of transport, but designed to work with the most > constraining transport thus specified by regulators and/or other SDOs,=
> that being ASTM F3411 Broadcast RID over Bluetooth 4.
>
> So, for Broadcast RID, they would be encapsulated in ASTM F3411
> messages over Bluetooth 4, Bluetooth 5 or WiFi Neighbor Awareness
> Networking (without IP).
>
> For Network RID, they could be carried in any IP based transport,
> HTTPS/TCP/IP initially (although, for Network RID, some of them are > superfluous).
>
> On 8/4/2020 11:27 AM, Alexandre Petrescu wrote:
> > Thanks for the clarification.
> >
> > Le 04/08/2020 =C3=A0 17:17, Stuart W. Card a =C3=A9crit=C2=A0: > >> I just want to respond to one line that I think comes from > confusion:
> >>
> >>> But if we have reluctance about the use of ADS-B, and thu= s of IP,
> >>> and we recommend Bluetooth-without-IP to identify drones<= br> > >>
> >> We aren't recommending Bluetooth-without-IP, we are _supp= orting_
> it,
> >
> > But, the security manifest that I have seen on slides during the<= br> > > presentation of the DRIP WG meeting - is something below IP, righ= t?
>
>
> --
> -----------------------------------------
> Stuart W. Card, PhD, Principal Engineer
> AX Enterprize, LLC=C2=A0 www.axenterprize.com
> 4947 Commercial Drive, Yorkville NY 13495


___________________________________________________________________________= ______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified.
Thank you.

--000000000000d2934a05ac213c51-- From nobody Wed Aug 5 06:38:38 2020 Return-Path: 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 6D9113A00F7 for ; Wed, 5 Aug 2020 06:38:36 -0700 (PDT) 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=axenterprize.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 DT_tI943iOhq for ; Wed, 5 Aug 2020 06:38:33 -0700 (PDT) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84B823A0645 for ; Wed, 5 Aug 2020 06:38:33 -0700 (PDT) Received: by mail-ej1-x636.google.com with SMTP id a26so20647620ejc.2 for ; Wed, 05 Aug 2020 06:38:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axenterprize.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AXEw8BNKOTa4R3zRhFR6NjIIqWZ6ttj6oj4+9dB+OBg=; b=Tf6W4RINI9LKbRd+avqkiotGHakPQQSKhlqAmfeQQVjL9t6JawnU0rbbHcb+dTGCl5 maiByWyQq/K7QHf+kGbaBUp+yQiIpjumrgYEAwC/mgtBqJx4MQ11oHO70u5HKdgCC8kX DOY8gTl1iAkDFhayTrGlkAyFhTKGDWZcGdGj0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AXEw8BNKOTa4R3zRhFR6NjIIqWZ6ttj6oj4+9dB+OBg=; b=f7/cipuzN6xhbqLi6r6dRe/ctFH5oBrM6qLzsU+vwB2tZPXlXOM+12LOGMCCugUE4u R3N4qKyKz0dhL2gmr+ZsU/cS1v1U0eLKB5gCHz0MiHJ2JI5LilPHQVXF2iosKgkdLqV8 R+WByXIopeAVV8gG4NoFAYtRhMyI80hmj5NzjigZ0hwJiLY9k3s0qL06WZg47N9O/2Nq DTbZCwqEqiNIJNpcTtb5qdN4+9Rvve0pn9r0tHlQJfLdEaNsb0qXqMCg28E13olXuzhd QKnv3XpOWs/KhZh/rsUfxAeu+Hl9ye/abV7gZ6yE1dgQRIVSG/FOt2uCIjE6uVcqYgcr AYYQ== X-Gm-Message-State: AOAM532mu4eti8KicpxBcBp3g24wb1NA/IWL7vrX2W4kiSVgs/ZLYcIk qRErOieFwOm6jIRlmT89vot93LeCt+lBElmSCWL4Dg== X-Google-Smtp-Source: ABdhPJxJZSKP4YNA6oHDz5Bzi7JFyZYoS1DtMILAnU6IyKdnX/Z+/8goslPn8a+Af4rQ010Rcro5Fnnt9IUgOV+fhcs= X-Received: by 2002:a17:906:68b:: with SMTP id u11mr3430269ejb.143.1596634711798; Wed, 05 Aug 2020 06:38:31 -0700 (PDT) MIME-Version: 1.0 References: <1bebf5b1-1fa5-6902-5bb7-9ec3582e6d9a@andersdotter.cc> <2990FBF0-FCB0-49CE-8F4B-BF5111CE5D57@tzi.org> <01a21161-aa8d-6d4b-b384-3129fe6d799b@gmail.com> <973223fd-0119-376d-12cd-21559a14ce87@labs.htt-consult.com> <3c632ce9-115d-11f5-ee33-bfabd4973522@labs.htt-consult.com> <7ddd9a2f-23ba-dd82-8cfb-1d2974969e67@gmail.com> <61511ef6-5b9b-5b62-f922-d32b994a35b9@gmail.com> In-Reply-To: From: "Card, Stu" Date: Wed, 5 Aug 2020 09:38:13 -0400 Message-ID: To: Alexandre Petrescu Cc: Robert Moskowitz , tm-rid@ietf.org Content-Type: multipart/alternative; boundary="000000000000d5494705ac217cef" Archived-At: Subject: Re: [Drip] ADSB X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 13:38:36 -0000 --000000000000d5494705ac217cef Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Again, I wish to respond primarily to one line that again I believe results from some confusion. > If it is a broadcast message and it is over Bluetooth or over WiFi > then it certainly is IP multicast, cant be anything else. There is nothing preventing application layer protocols from being layered directly over link layer protocols. This is exactly what is typically done with Bluetooth, not only for UAS RID, but other applications as well. It can even be done with WiFi, Ethernet, etc., although this is less commonly done. This certainly limits flexibility and internetworking. Again, however, this is not up to us: the regulators are citing ASTM F3411 for UAS RID; that standard defines how to put UAS RID application specific message formats directly into Bluetooth link layer frames, without any intervening headers (such as would be required for IP encapsulation of the app layer messages). While I think their specifying Bluetooth generally was a bad idea (for many reasons, including range as you mention, as has been confirmed marginal in our testing), and supporting legacy Bluetooth 4 specifically was an even worse idea (for even lower range and its incredibly short 25 byte payloads), this decision was not made by, and cannot be reversed by, the DRIP WG. We can only hope to mitigate its security deficiencies, address the issues it fails to address (such as how registries work and how communications between an Observer and a Remote Pilot can be initiated), and improve its interoperability with the Internet once we get beyond the Broadcast RID data link. On Wed, Aug 5, 2020 at 6:11 AM Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > > > Le 04/08/2020 =C3=A0 17:51, Robert Moskowitz a =C3=A9crit : > > > > > > On 8/4/20 11:27 AM, Alexandre Petrescu wrote: > >> Thanks for the clarification. > >> > >> Le 04/08/2020 =C3=A0 17:17, Stuart W. Card a =C3=A9crit : > >>> I just want to respond to one line that I think comes from > >>> confusion: > >>> > >>>> But if we have reluctance about the use of ADS-B, and thus of > >>>> IP, and we recommend Bluetooth-without-IP to identify drones > >>> > >>> We aren't recommending Bluetooth-without-IP, we are _supporting_ > >>> it, > >> > >> But, the security manifest that I have seen on slides during the > >> presentation of the DRIP WG meeting - is something below IP, > >> right? > > > > For now, we are dealing with broadcast messages. Either over > > Bluetooth or WiFI (NAN). > > If it is a broadcast message and it is over Bluetooth or over WiFi then > it certainly is IP multicast, cant be anything else. > > If it is IP multicast over Bluetooth or over WiFi then I wonder what is > the value in the Next Header field of the IP header format (RFC8200 > "IPv6", section 3 "Header format"). Basically - what is the payload? > > If one asks me, I would dare to think that payload might be an ICMPv6 > Router Advertisement. > > > There is NO security for the messages below the message package. > > Noted. > > > Just not enough payload size for anything that would work in a > > broadcast environment like a National Airspace. All of the security > > we are specifying is inside the messages where appropriate. > > > > That security manifest is a payload of the ASTM F3411-19 > > Authentication Message. > > It costs 85USD I wont pay to see it. It is security. There will always > be someone smarter to break that security and ask for more money. > > I would not oppose if that Authentication MEssage had a specification in > clear. > > > These messages are broadcasted as Adam mentioned in his 'flying DRIP' > > comments at the beginning. > > Thank you for the reminder. I looked again at the 'flying DRIP' > presentation during the WG meeting, and at the related draft. > > https://datatracker.ietf.org/meeting/108/materials/slides-108-drip-authen= tication-formats > and > draft-wiethuechter-drip-auth-01 > > During the presentation, the slide clearly shows on slide 8 that a > Bluetooth header immediately precedes an Open Drone ID message. There > is no IP header in that slide. > > In the draft, there is similar discussion tightly related to Bluetooth > and without IP. > > But if we are to have an independence of Bluetooth, and use a networking > layer such as IP, then the question of the use of an authentication > header is made differently. > > The authentication header would be an IP Authentication Header. This AH > would be somehow re-used and extended where necessary for DRIP purposes. > > > Now later I expect us to move on to Network Remote ID and Command > > and Control (C2). > > > > Most C2 (e.g. Mavlink) is directly over the MAC, but there is a > > method to run it over UDP (I forget the UDP port commonly used...). > > AX Enterprize has done this using HIP so the UA starts with WiFi > > over the launch point, transitions to LTE, and on return back to > > WiFi. > > > > Network Remote ID can work either directly from the UA, or via C2 > > information to the GCS, from the GCS. In either case, IP is > > assumed. This will probably be done via UDP. From the UA, mobility > > will be important; from the GCS nice to have (most GCS will be stable > > location). As UDP to a fixed Net-SP, DTLS 1.3 is a viable > > alternative to HIP. > > I will have to look closer at HIP again :-) and see how it could be made > to work with DRIP and IP. > > Alex > > > > > > > > > > >> > >> Alex > >> > >> as > >>> it is specified in ASTM F3411, which most of the regulators are > >>> dubbing as an approved technical means of regulatory compliance. > >>> > >>> AFAIK, no one runs IP over ADS-B, which was designed as a > >>> narrowband application specific communications stovepipe, not a > >>> data link supporting higher layer network protocols, so not > >>> great for IP. > >>> > >>> More importantly, we have no "reluctance about the use of... > >>> IP", which is an entirely separate issue from ADS-B. > >>> > >>> On 8/4/2020 9:52 AM, Alexandre Petrescu wrote: > >>>> architectural layers discussion... > >>>> > >>>> Le 30/07/2020 =C3=A0 11:49, shuaiizhao(Shuai Zhao) a =C3=A9crit : > >>>>> Just to echo Stu on the ADSB, AFAIK, ADSB will not be > >>>>> feasible for most of the drones mostly due to SwaP, > >>>>> commercial drones might be exception. > >>>> > >>>> It might be that ADS-B might be forbidden in drones on Earth, > >>>> but how about the drones on Mars? ('NASA Mars helicopters', or > >>>> ESA too). On Mars there would be much less such drones, so > >>>> less risk of interference. > >>>> > >>>> With such a system (ADS-B under IP) one could re-use DTN > >>>> (Delay Tolerant Networking) between planets, and so identify > >>>> drones even on Mars. > >>>> > >>>> But if we have reluctance about the use of ADS-B, and thus of > >>>> IP, and we recommend Bluetooth-without-IP to identify drones, > >>>> then we might become too dependent on it? > >>>> > >>>> (do not get me wrong, I do like Bluetooth, but I like many > >>>> other things together with Bluetooth). > >>>> > >>>> Alex > >>>> > >>>>> > >>>>> Best, > >>>>> > >>>>> Shuai Zhao > >>>>> > >>>>> *From: *Tm-rid on behalf of > >>>>> "Stuart W. Card" *Date: > >>>>> *Wednesday, July 29, 2020 at 19:46 *To: *"tm-rid@ietf.org" > >>>>> *Subject: *[Drip] ADSB (was: Review of > >>>>> draft-drip-arch-02 w.r.t. RFC6973, RFC8280 and > >>>>> other)(Internet mail) > >>>>> > >>>>> Sorry for the slow reply. > >>>>> > >>>>> ADS-B is gradually being mandated for essentially all manned > >>>>> aircraft. > >>>>> > >>>>> ADSB-In and ADSB-Out are mandated for airliners: -In gives > >>>>> their pilots > >>>>> > >>>>> some Situational Awareness (SA) of other aircraft; -Out > >>>>> gives other > >>>>> > >>>>> pilots SA of the airliners. > >>>>> > >>>>> "ADSB-Out" is mandated even for small general aviation > >>>>> aircraft: it does > >>>>> > >>>>> not directly benefit the pilots of those aircraft; but by > >>>>> providing SA > >>>>> > >>>>> to others, it indirectly benefits all. > >>>>> > >>>>> ADSB is _not_ going to be deployed on large numbers of small > >>>>> UAS as it > >>>>> > >>>>> would overwhelm the limited bandwidth available at those > >>>>> lower radio > >>>>> > >>>>> frequencies (which propagate long ranges). In fact, it is > >>>>> expected to be > >>>>> > >>>>> explicitly prohibited in the US per the FAA NPRM; I suspect > >>>>> most of the > >>>>> > >>>>> rest of the world will do likewise. > >>>>> > >>>>> ADSB is also altogether insecure. > >>>>> > >>>>> On 7/9/2020 3:02 AM, Alexandre Petrescu wrote: > >>>>> > >>>>> ... > >>>>> > >>>>> They call it "ADS-B Receivers" (Automatic Dependent > >>>>> Surveillance - > >>>>> > >>>>> Broadcast). > >>>>> > >>>>> I wouuld like to ask if there is a packet dump available > >>>>> showing such > >>>>> > >>>>> presence data form planes? Maybe wireshark already supports > >>>>> it, maybe > >>>>> > >>>>> it even dissects it... > >>>>> > >>>>> -- > >>>>> > >>>>> ----------------------------------------- > >>>>> > >>>>> Stuart W. Card, PhD, Principal Engineer > >>>>> > >>>>> AX Enterprize, LLC www.axenterprize.com > >>>>> > >>>>> 4947 Commercial Drive, Yorkville NY 13495 > >>>>> > >>>>> > >>>> > >>> > >>> > >>> > >> > > > > -- 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 > > -- > Tm-rid mailing list > Tm-rid@ietf.org > https://www.ietf.org/mailman/listinfo/tm-rid > --000000000000d5494705ac217cef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Again, I wish to respond primarily to one= line that again I believe results=C2=A0from some confusion.

> If it is a broadcast message and i= t is over Bluetooth or over WiFi
> then it certain= ly is IP multicast, cant be anything else.

=
There is nothing preventing application layer protocols from being lay= ered directly over link layer protocols. This is exactly what is typically = done with Bluetooth, not only for UAS RID, but other applications as well. = It can even be done with WiFi, Ethernet, etc., although this is less common= ly done. This certainly limits flexibility and internetworking. Again, howe= ver, this is not up to us: the regulators are citing ASTM F3411 for UAS RID= ; that standard defines how to put UAS RID application specific message for= mats directly into Bluetooth link layer frames, without any intervening hea= ders (such as would be required for IP encapsulation of the app layer messa= ges). While I think their specifying Bluetooth generally was a bad idea (fo= r many reasons, including range as you mention, as has been confirmed margi= nal in our testing), and supporting legacy Bluetooth 4 specifically was an = even worse idea (for even lower range and its incredibly short 25 byte payl= oads), this decision was not made by, and cannot be reversed by, the DRIP W= G. We can only hope to mitigate its security deficiencies, address the issu= es it fails to address (such as how registries work and how communications = between an Observer and a Remote Pilot can be initiated), and improve its i= nteroperability with the Internet once we get beyond the Broadcast RID data= link.

On Wed, Aug 5, 2020 at 6:11 AM Alexandre Petr= escu <alexandre.petrescu= @gmail.com> wrote:


Le 04/08/2020 =C3=A0 17:51, Robert Moskowitz a =C3=A9crit :
>
>
> On 8/4/20 11:27 AM, Alexandre Petrescu wrote:
>> Thanks for the clarification.
>>
>> Le 04/08/2020 =C3=A0 17:17, Stuart W. Card a =C3=A9crit :
>>> I just want to respond to one line that I think comes from >>> confusion:
>>>
>>>> But if we have reluctance about the use of ADS-B, and thus= of
>>>> IP, and we recommend Bluetooth-without-IP to identify dron= es
>>>
>>> We aren't recommending Bluetooth-without-IP, we are _suppo= rting_
>>> it,
>>
>> But, the security manifest that I have seen on slides during the <= br> >> presentation of the DRIP WG meeting - is something below IP,
>> right?
>
> For now, we are dealing with broadcast messages.=C2=A0 Either over > Bluetooth or WiFI (NAN).

If it is a broadcast message and it is over Bluetooth or over WiFi then it certainly is IP multicast, cant be anything else.

If it is IP multicast over Bluetooth or over WiFi then I wonder what is
the value=C2=A0 in the Next Header field of the IP header format (RFC8200 "IPv6", section 3 "Header format").=C2=A0 Basically - w= hat is the payload?

If one asks me, I would dare to think that payload might be an ICMPv6
Router Advertisement.

> There is NO security for the messages below the message package.

Noted.

> Just not enough payload size for anything that would work in a
> broadcast environment like a National Airspace.=C2=A0 All of the secur= ity
> we are specifying is inside the messages where appropriate.
>
> That security manifest is a payload of the ASTM F3411-19
> Authentication Message.

It costs 85USD I wont pay to see it.=C2=A0 It is security.=C2=A0 There will= always
be someone smarter to break that security and ask for more money.

I would not oppose if that Authentication MEssage had a specification in clear.

> These messages are broadcasted as Adam mentioned in his 'flying DR= IP'
> comments at the beginning.

Thank you for the reminder.=C2=A0 I looked again at the 'flying DRIP= 9;
presentation during the WG meeting, and at the related draft.
https://dat= atracker.ietf.org/meeting/108/materials/slides-108-drip-authentication-form= ats
and
draft-wiethuechter-drip-auth-01

During the presentation, the slide clearly shows on slide 8 that a
Bluetooth header immediately precedes an Open Drone ID message.=C2=A0 There=
is no IP header in that slide.

In the draft, there is similar discussion tightly related to Bluetooth
and without IP.

But if we are to have an independence of Bluetooth, and use a networking layer such as IP, then the question of the use of an authentication
header is made differently.

The authentication header would be an IP Authentication Header.=C2=A0 This = AH
would be somehow re-used and extended where necessary for DRIP purposes.
> Now later I expect us to move on to Network Remote ID and Command
> and Control (C2).
>
> Most C2 (e.g. Mavlink) is directly over the MAC, but there is a
> method to run it over UDP (I forget the UDP port commonly used...). > AX Enterprize has done this using HIP so the UA starts with WiFi
> over the launch point, transitions to LTE, and on return back to
> WiFi.
>
> Network Remote ID can work either directly from the UA, or via C2
> information to the GCS, from the GCS.=C2=A0 In either case, IP is
> assumed. This will probably be done via UDP.=C2=A0 From the UA, mobili= ty
> will be important; from the GCS nice to have (most GCS will be stable<= br> >=C2=A0 location).=C2=A0 As UDP to a fixed Net-SP, DTLS 1.3 is a viable =
> alternative to HIP.

I will have to look closer at HIP again :-) and see how it could be made to work with DRIP and IP.

Alex

>
>
>
>
>>
>> Alex
>>
>> as
>>> it is specified in ASTM F3411, which most of the regulators ar= e
>>> dubbing as an approved technical means of regulatory complianc= e.
>>>
>>> AFAIK, no one runs IP over ADS-B, which was designed as a
>>> narrowband application specific communications stovepipe, not = a
>>> data link supporting higher layer network protocols, so not >>> great for IP.
>>>
>>> More importantly, we have no "reluctance about the use of= ...
>>> IP", which is an entirely separate issue from ADS-B.
>>>
>>> On 8/4/2020 9:52 AM, Alexandre Petrescu wrote:
>>>> architectural layers discussion...
>>>>
>>>> Le 30/07/2020 =C3=A0 11:49, shuaiizhao(Shuai Zhao) a =C3= =A9crit :
>>>>> Just to echo Stu on the ADSB, AFAIK, ADSB will=C2=A0 n= ot be
>>>>> feasible for most of the drones mostly due to SwaP, >>>>> commercial drones might be exception.
>>>>
>>>> It might be that ADS-B might be forbidden in drones on Ear= th,
>>>> but how about the drones on Mars? ('NASA Mars helicopt= ers', or
>>>> ESA too).=C2=A0 On Mars there would be much less such dron= es, so
>>>> less risk of interference.
>>>>
>>>> With such a system (ADS-B under IP) one could re-use DTN >>>> (Delay Tolerant Networking) between planets, and so identi= fy
>>>> drones even on Mars.
>>>>
>>>> But if we have reluctance about the use of ADS-B, and thus= of
>>>> IP, and we recommend Bluetooth-without-IP to identify dron= es,
>>>> then we might become too dependent on it?
>>>>
>>>> (do not get me wrong, I do like Bluetooth, but I like many=
>>>> other things together with Bluetooth).
>>>>
>>>> Alex
>>>>
>>>>>
>>>>> Best,
>>>>>
>>>>> Shuai Zhao
>>>>>
>>>>> *From: *Tm-rid <tm-rid-bounces@ietf.org> on behalf of
>>>>> "Stuart W. Card" <stu.card@axenterprize.com> *= Date:
>>>>> *Wednesday, July 29, 2020 at 19:46 *To: *"tm-rid@ietf.org"
>>>>> <tm-rid@ietf.org> *Subject: *[Drip] ADSB (was: Review of
>>>>> draft-drip-arch-02 w.r.t. RFC6973, RFC8280 and
>>>>> other)(Internet mail)
>>>>>
>>>>> Sorry for the slow reply.
>>>>>
>>>>> ADS-B is gradually being mandated for essentially all = manned
>>>>>=C2=A0 aircraft.
>>>>>
>>>>> ADSB-In and ADSB-Out are mandated for airliners: -In g= ives
>>>>> their pilots
>>>>>
>>>>> some Situational Awareness (SA) of other aircraft; -Ou= t
>>>>> gives other
>>>>>
>>>>> pilots SA of the airliners.
>>>>>
>>>>> "ADSB-Out" is mandated even for small genera= l aviation
>>>>> aircraft: it does
>>>>>
>>>>> not directly benefit the pilots of those aircraft; but= by
>>>>> providing SA
>>>>>
>>>>> to others, it indirectly benefits all.
>>>>>
>>>>> ADSB is _not_ going to be deployed on large numbers of= small
>>>>> UAS as it
>>>>>
>>>>> would overwhelm the limited bandwidth available at tho= se
>>>>> lower radio
>>>>>
>>>>> frequencies (which propagate long ranges). In fact, it= is
>>>>> expected to be
>>>>>
>>>>> explicitly prohibited in the US per the FAA NPRM; I su= spect
>>>>> most of the
>>>>>
>>>>> rest of the world will do likewise.
>>>>>
>>>>> ADSB is also altogether insecure.
>>>>>
>>>>> On 7/9/2020 3:02 AM, Alexandre Petrescu wrote:
>>>>>
>>>>> ...
>>>>>
>>>>> They call it "ADS-B Receivers" (Automatic De= pendent
>>>>> Surveillance -
>>>>>
>>>>> Broadcast).
>>>>>
>>>>> I wouuld like to ask if there is a packet dump availab= le
>>>>> showing such
>>>>>
>>>>> presence data form planes?=C2=A0 Maybe wireshark alrea= dy supports
>>>>> it, maybe
>>>>>
>>>>> it even dissects it...
>>>>>
>>>>> --
>>>>>
>>>>> -----------------------------------------
>>>>>
>>>>> Stuart W. Card, PhD, Principal Engineer
>>>>>
>>>>> AX Enterprize, LLC www.axenterprize.com
>>>>>
>>>>> 4947 Commercial Drive, Yorkville NY 13495
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
> -- 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 mat= ter
> who gets the credit

--
Tm-rid mailing list
Tm-rid@ietf.org https://www.ietf.org/mailman/listinfo/tm-rid
--000000000000d5494705ac217cef-- From nobody Wed Aug 5 06:51:14 2020 Return-Path: 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 C2E3E3A07F3 for ; Wed, 5 Aug 2020 06:51:12 -0700 (PDT) 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=axenterprize.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 Mtp2u8qMsb_L for ; Wed, 5 Aug 2020 06:51:09 -0700 (PDT) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 124313A07F0 for ; Wed, 5 Aug 2020 06:51:08 -0700 (PDT) Received: by mail-ej1-x630.google.com with SMTP id m22so3387871eje.10 for ; Wed, 05 Aug 2020 06:51:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axenterprize.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dVYxsbakLF1XMWWOAR8eSvrfFXz3hBG1kFTexJQalz8=; b=tMdd4TzkwqgJjdY7YJbOxliT+1zsVEngfeANmXmiJ+zVABIwU/BxUptJVTdXKrC5JE lcPN4tRh3t8JjQ7HQkdtB6hXJL9mIpdLxm8BnL5TUKl4L9KqxHtiHzAG+CX+hG8fFG3V C4yOREkdjqX9Fl4FLl8zaoZeSkeTwpwOMak+4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dVYxsbakLF1XMWWOAR8eSvrfFXz3hBG1kFTexJQalz8=; b=QcoYqSAczMCu1rFoKNdBNqb/0jteZJ/GMX+9SxqFgvixxe9uEfCr6L+VII02hV26Wf NQiS+zyOPm8YRou5bdL5qmvi4hiq4e4+aPDgtseZgHX014yytEXjpWqxewbBV/9dyCwl Gc/dhVxNfpF3+TsdXJmtzqiszx/Q6QGwHg3LoPPQAKiaT2EWsc/l+L+aWaHexny6aSBO H5YQETv/ZtyDxp58815mlOXoSXJnTVAAZ+KG4OnlV0sMZaO8YoTaAvJEabnAA+KwcKb0 YCXBi6/bYcDb9AEumvhtTNQD5pDaX60KHyCl1l6/EBZ75/xBlFxSnmB7aotcbBzcu+xj UiwA== X-Gm-Message-State: AOAM532K4eO+80qEqg553J/sNW2fLYSC/IwSs66Wb/jOD9s6SePGXar8 5zF6bb6fSK7283WN+o3tjPyRMiTBnkD1eZKRtTeWZQ== X-Google-Smtp-Source: ABdhPJxYcdU8MHPccOn5zlyDBbSqqfUvkQsVamI3FjYQ2CfKcVBWdcYe97PejfQQl8L2NBU8ppxjDZzP2wi6A7QR0NE= X-Received: by 2002:a17:906:68b:: with SMTP id u11mr3482785ejb.143.1596635467116; Wed, 05 Aug 2020 06:51:07 -0700 (PDT) MIME-Version: 1.0 References: <1bebf5b1-1fa5-6902-5bb7-9ec3582e6d9a@andersdotter.cc> <01a21161-aa8d-6d4b-b384-3129fe6d799b@gmail.com> <973223fd-0119-376d-12cd-21559a14ce87@labs.htt-consult.com> <3c632ce9-115d-11f5-ee33-bfabd4973522@labs.htt-consult.com> <7ddd9a2f-23ba-dd82-8cfb-1d2974969e67@gmail.com> <61511ef6-5b9b-5b62-f922-d32b994a35b9@gmail.com> In-Reply-To: From: "Card, Stu" Date: Wed, 5 Aug 2020 09:50:49 -0400 Message-ID: To: Alexandre Petrescu Cc: Robert Moskowitz , tm-rid@ietf.org Content-Type: multipart/alternative; boundary="000000000000da80a805ac21a947" Archived-At: Subject: Re: [Drip] ADSB X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 13:51:13 -0000 --000000000000da80a805ac21a947 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Again, a single point response. The reason this work is appropriate for IETF rather than the Bluetooth SIG is that ASTM F3411 specifies Bluetooth _only_ as one transport for Broadcast RID (WiFi NaN is also specified and other alternatives could be added later, as you, Bob and others are discussing, also consider RTCA SC-228 DO-362 UAS C2 Data Link at ~1 and ~5 GHz), but there is also Network RID where ASTM F3411 specifies use of the Internet, and a lot more to the overall UAS RID architecture/problem than just the initial streaming of messages from the UAS. Please look at the openly published early draft of ASTM F3411 to which Bob pointed you, and perhaps some of the other external docs cited in the DRIP requirements draft, for essential context on the UAS RID problem and what others have already done to address it, which we hope to complement (not replace) with DRIP. Thanks! On Wed, Aug 5, 2020 at 8:50 AM Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > > > Le 05/08/2020 =C3=A0 13:53, Robert Moskowitz a =C3=A9crit : > > > > > > On 8/5/20 6:11 AM, Alexandre Petrescu wrote: > >> > >> > >> Le 04/08/2020 =C3=A0 17:51, Robert Moskowitz a =C3=A9crit : > >>> > >>> > >>> On 8/4/20 11:27 AM, Alexandre Petrescu wrote: > >>>> Thanks for the clarification. > >>>> > >>>> Le 04/08/2020 =C3=A0 17:17, Stuart W. Card a =C3=A9crit : > >>>>> I just want to respond to one line that I think comes from > >>>>> confusion: > >>>>> > >>>>>> But if we have reluctance about the use of ADS-B, and thus > >>>>>> of IP, and we recommend Bluetooth-without-IP to identify > >>>>>> drones > >>>>> > >>>>> We aren't recommending Bluetooth-without-IP, we are > >>>>> _supporting_ it, > >>>> > >>>> But, the security manifest that I have seen on slides during > >>>> the presentation of the DRIP WG meeting - is something below > >>>> IP, right? > >>> > >>> For now, we are dealing with broadcast messages. Either over > >>> Bluetooth or WiFI (NAN). > >> > >> If it is a broadcast message and it is over Bluetooth or over WiFi > >> then it certainly is IP multicast, cant be anything else. > > > > Wrong for BT4. There are only 25 bytes available. We can do most > > of the messaging in a single frame. To do anything with IP will > > force this to a multiframe design. > > I might say something stupid if I am allowed, maybe things that are > already known. Sorry, I did not check the BoF archive discussion. But > here goes anyways. If one wants to do something with Bluetooth4 below > IP and finds it to be too small packets, then there could be several > possibilities: > - do it at Bluetooth SIG instead of IETF; > - do it in 6lo WG; > - use a header compression scheme at IETF (6lowpan HC at 6lo WG, SCHC at > LP-WAN WG, ROHC and why not CBOR); > - implement packet fragmentation and reassembly and multiframe design > below IP; > - use the already available data in the 25 bytes in order to realize > that identification (there must be MAC addresses in there, and they're > likely to be useful). > > > Even BT5 it is wrong for the Authentication Message. We need the > > full frame for our content. We would have to go with multiframe > > design for BT5 as a result. > > So, I do not understand: does DRIP want the entire packet to stay of > size 25bytes? Or does DRIP want the packet to be more than 25bytes? > > Would a multiframe design in which an IP packet of length 1280bytes is > chopped into 25bytes BT5 packets be advantageous for DRIP? > > Do the BT5 packets have a notion of interlinking between sub-packets > that make a bigger packet? (such a mechanism exists at the IP layer; it > uses Identification to identify a chain and an Offset to say where in > the chain is that sub-packet to be found). > > > So this leaves WiFi NAN. Sure you can do it, but why? What does it > > add? In My Not So Humble Opinion (IMNSOHO) nothing but cost and > > processing overhead. > > I think WiFi 5.4 GHz is already used extensively to remotely control > drones. These consoles with joysticks are WiFi 5.4GHz, if I am not > mistaken. > > >> If it is IP multicast over Bluetooth or over WiFi then I wonder > >> what is the value in the Next Header field of the IP header > >> format (RFC8200 "IPv6", section 3 "Header format"). Basically - > >> what is the payload? > >> > >> If one asks me, I would dare to think that payload might be an > >> ICMPv6 Router Advertisement. > >> > >>> There is NO security for the messages below the message package. > >> > >> Noted. > >> > >>> Just not enough payload size for anything that would work in a > >>> broadcast environment like a National Airspace. All of the > >>> security we are specifying is inside the messages where > >>> appropriate. > >>> > >>> That security manifest is a payload of the ASTM F3411-19 > >>> Authentication Message. > >> > >> It costs 85USD I wont pay to see it. It is security. There will > >> always be someone smarter to break that security and ask for more > >> money. > > > > Look at: > > > > > https://github.com/opendroneid/specs/blob/master/OpenDroneID_Bluetooth_0.= 64.3.pdf > > > > > > > It is close enough. > > Thanks for the pointer. Noted. > > It is about Bluetooth. Should be submitted to Bluetooth SIG. > > I might stay something stupid here again... si I wont say it :-) > > >> I would not oppose if that Authentication MEssage had a > >> specification in clear. > > > > The above plus Adam's draft will get you there. > > > >> > >>> These messages are broadcasted as Adam mentioned in his 'flying > >>> DRIP' comments at the beginning. > >> > >> Thank you for the reminder. I looked again at the 'flying DRIP' > >> presentation during the WG meeting, and at the related draft. > >> > https://datatracker.ietf.org/meeting/108/materials/slides-108-drip-authen= tication-formats > >> > >> > >> > >> and draft-wiethuechter-drip-auth-01 > >> > >> During the presentation, the slide clearly shows on slide 8 that a > >> Bluetooth header immediately precedes an Open Drone ID message. > >> There is no IP header in that slide. > > > > That is right. No IP. No room for it. No justification for it. It > > is all RLOS only. > > I might say something stupid here: no IP? No IETF. > > >> In the draft, there is similar discussion tightly related to > >> Bluetooth and without IP. > >> > >> But if we are to have an independence of Bluetooth, and use a > >> networking layer such as IP, then the question of the use of an > >> authentication header is made differently. > > > > Again what is the justification for adding IP multicast? > > I would not be afraid of IP multicast like the multicast we know for > video delivery. It is IP multicast because IP is IPv6 and IPv6 has no > broadcast. > > _If_ there is agreement that DRIP should be with IP (Internet Protocol). > > We know that the drone identification should be broadcasted (like in TV > broadcast). In IPv4 there is a mechanism to implement such TV-broadcast > concept. It is called IPv4 broadcast. That broadcast is sent to a > dedicated address (like 255.255.255.255 which is all Internet, or like > 195.212.142.255 which is all computers in a particular subnet). In IPv6 > such broadcast concept does not exist. Rather, it's called 'multicast' > and, as opposed to IPv4, it has a mandatory and voluntary join/leave > mechanism. > > I name that IPv6 multicast simply IP multicast, because IPv4 should not > be used as basis for any new work at IETF. > > On such an IP multicast perspective for DRIP, one would have to come up > with an architecture for joining and leaving that makes it easy to use > by authorities, mandatory to implement, is secure enough (security and > multicast is not that easy), etc. > > > Where do you see these messages going beyond the RF Line Of Sight? > > True. > > But one would not want all BT5 devices (like my watch or earphones) > around a drone's sight to be awaken by its identification beacons, > right? Only those devices who have voluntarily subscribed to that > multicast group would be awaken. > > > >> The authentication header would be an IP Authentication Header. > >> This AH would be somehow re-used and extended where necessary for > >> DRIP purposes. > >> > >>> Now later I expect us to move on to Network Remote ID and Command > >>> and Control (C2). > >>> > >>> Most C2 (e.g. Mavlink) is directly over the MAC, but there is a > >>> method to run it over UDP (I forget the UDP port commonly > >>> used...). AX Enterprize has done this using HIP so the UA starts > >>> with WiFi over the launch point, transitions to LTE, and on > >>> return back to WiFi. > >>> > >>> Network Remote ID can work either directly from the UA, or via > >>> C2 information to the GCS, from the GCS. In either case, IP is > >>> assumed. This will probably be done via UDP. From the UA, > >>> mobility will be important; from the GCS nice to have (most GCS > >>> will be stable location). As UDP to a fixed Net-SP, DTLS 1.3 is > >>> a viable alternative to HIP. > >> > >> I will have to look closer at HIP again :-) and see how it could > >> be made to work with DRIP and IP. > > > > Stu, Adam, Andrei, and I see HIP for where there is pairwise > > communication with potentially both ends mobile and using multiple > > interfaces. Once you have that use case, be consistent and use it > > for simpler situations. > > I wanted to ask whether using a Host Identity that is cryptographically > generated is sufficient for authorities to trust a drone upon reception > of one DRIP identification packet, or maybe am additional roundrip (a > ping, a request-response) would still be needed from ground officer to > drone to make sure it's the right drone who replies? Or maybe a full > Diffie-Hellman exchange is needed? > > Alex > > > > >> > >> Alex > >> > >>> > >>> > >>> > >>> > >>>> > >>>> Alex > >>>> > >>>> as > >>>>> it is specified in ASTM F3411, which most of the regulators > >>>>> are dubbing as an approved technical means of regulatory > >>>>> compliance. > >>>>> > >>>>> AFAIK, no one runs IP over ADS-B, which was designed as a > >>>>> narrowband application specific communications stovepipe, > >>>>> not a data link supporting higher layer network protocols, > >>>>> so not great for IP. > >>>>> > >>>>> More importantly, we have no "reluctance about the use of... > >>>>> IP", which is an entirely separate issue from ADS-B. > >>>>> > >>>>> On 8/4/2020 9:52 AM, Alexandre Petrescu wrote: > >>>>>> architectural layers discussion... > >>>>>> > >>>>>> Le 30/07/2020 =C3=A0 11:49, shuaiizhao(Shuai Zhao) a =C3=A9crit : > >>>>>>> Just to echo Stu on the ADSB, AFAIK, ADSB will not be > >>>>>>> feasible for most of the drones mostly due to SwaP, > >>>>>>> commercial drones might be exception. > >>>>>> > >>>>>> It might be that ADS-B might be forbidden in drones on > >>>>>> Earth, but how about the drones on Mars? ('NASA Mars > >>>>>> helicopters', or ESA too). On Mars there would be much > >>>>>> less such drones, so less risk of interference. > >>>>>> > >>>>>> With such a system (ADS-B under IP) one could re-use DTN > >>>>>> (Delay Tolerant Networking) between planets, and so > >>>>>> identify drones even on Mars. > >>>>>> > >>>>>> But if we have reluctance about the use of ADS-B, and thus > >>>>>> of IP, and we recommend Bluetooth-without-IP to identify > >>>>>> drones, then we might become too dependent on it? > >>>>>> > >>>>>> (do not get me wrong, I do like Bluetooth, but I like many > >>>>>> other things together with Bluetooth). > >>>>>> > >>>>>> Alex > >>>>>> > >>>>>>> > >>>>>>> Best, > >>>>>>> > >>>>>>> Shuai Zhao > >>>>>>> > >>>>>>> *From: *Tm-rid on behalf of > >>>>>>> "Stuart W. Card" *Date: > >>>>>>> *Wednesday, July 29, 2020 at 19:46 *To: > >>>>>>> *"tm-rid@ietf.org" *Subject: *[Drip] > >>>>>>> ADSB (was: Review of draft-drip-arch-02 w.r.t. RFC6973, > >>>>>>> RFC8280 and other)(Internet mail) > >>>>>>> > >>>>>>> Sorry for the slow reply. > >>>>>>> > >>>>>>> ADS-B is gradually being mandated for essentially all > >>>>>>> manned aircraft. > >>>>>>> > >>>>>>> ADSB-In and ADSB-Out are mandated for airliners: -In > >>>>>>> gives their pilots > >>>>>>> > >>>>>>> some Situational Awareness (SA) of other aircraft; -Out > >>>>>>> gives other > >>>>>>> > >>>>>>> pilots SA of the airliners. > >>>>>>> > >>>>>>> "ADSB-Out" is mandated even for small general aviation > >>>>>>> aircraft: it does > >>>>>>> > >>>>>>> not directly benefit the pilots of those aircraft; but > >>>>>>> by providing SA > >>>>>>> > >>>>>>> to others, it indirectly benefits all. > >>>>>>> > >>>>>>> ADSB is _not_ going to be deployed on large numbers of > >>>>>>> small UAS as it > >>>>>>> > >>>>>>> would overwhelm the limited bandwidth available at those > >>>>>>> lower radio > >>>>>>> > >>>>>>> frequencies (which propagate long ranges). In fact, it > >>>>>>> is expected to be > >>>>>>> > >>>>>>> explicitly prohibited in the US per the FAA NPRM; I > >>>>>>> suspect most of the > >>>>>>> > >>>>>>> rest of the world will do likewise. > >>>>>>> > >>>>>>> ADSB is also altogether insecure. > >>>>>>> > >>>>>>> On 7/9/2020 3:02 AM, Alexandre Petrescu wrote: > >>>>>>> > >>>>>>> ... > >>>>>>> > >>>>>>> They call it "ADS-B Receivers" (Automatic Dependent > >>>>>>> Surveillance - > >>>>>>> > >>>>>>> Broadcast). > >>>>>>> > >>>>>>> I wouuld like to ask if there is a packet dump available > >>>>>>> showing such > >>>>>>> > >>>>>>> presence data form planes? Maybe wireshark already > >>>>>>> supports it, maybe > >>>>>>> > >>>>>>> it even dissects it... > >>>>>>> > >>>>>>> -- > >>>>>>> > >>>>>>> ----------------------------------------- > >>>>>>> > >>>>>>> Stuart W. Card, PhD, Principal Engineer > >>>>>>> > >>>>>>> AX Enterprize, LLC www.axenterprize.com > >>>>>>> > >>>>>>> 4947 Commercial Drive, Yorkville NY 13495 > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>> > >>> -- 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 > > > > -- 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 > > -- > Tm-rid mailing list > Tm-rid@ietf.org > https://www.ietf.org/mailman/listinfo/tm-rid > --000000000000da80a805ac21a947 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Again, a single point response. The reason this work is ap= propriate for IETF rather than the Bluetooth SIG is that ASTM F3411 specifi= es Bluetooth _only_ as one transport for Broadcast RID (WiFi NaN is also sp= ecified and other alternatives could be added later, as you, Bob and others= are discussing, also consider RTCA SC-228 DO-362 UAS C2 Data Link at ~1 an= d ~5 GHz), but there is also Network RID where ASTM F3411 specifies use of = the Internet, and a lot more to the overall UAS RID architecture/problem th= an just the initial streaming of messages from the UAS.

= Please look at the openly published early draft of ASTM F3411 to which Bob = pointed you, and perhaps some of the other external docs cited in the DRIP = requirements draft, for=C2=A0 essential context on the UAS RID problem and = what others have already done to address it, which we hope to complement (n= ot replace) with DRIP. Thanks!


On Wed, Aug 5, 2020 at 8= :50 AM Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:


Le 05/08/2020 =C3=A0 13:53, Robert Moskowitz a =C3=A9crit :
>
>
> On 8/5/20 6:11 AM, Alexandre Petrescu wrote:
>>
>>
>> Le 04/08/2020 =C3=A0 17:51, Robert Moskowitz a =C3=A9crit :
>>>
>>>
>>> On 8/4/20 11:27 AM, Alexandre Petrescu wrote:
>>>> Thanks for the clarification.
>>>>
>>>> Le 04/08/2020 =C3=A0 17:17, Stuart W. Card a =C3=A9crit :<= br> >>>>> I just want to respond to one line that I think comes = from
>>>>> confusion:
>>>>>
>>>>>> But if we have reluctance about the use of ADS-B, = and thus
>>>>>> of IP, and we recommend Bluetooth-without-IP to id= entify
>>>>>> drones
>>>>>
>>>>> We aren't recommending Bluetooth-without-IP, we ar= e
>>>>> _supporting_ it,
>>>>
>>>> But, the security manifest that I have seen on slides duri= ng
>>>> the presentation of the DRIP WG meeting - is something bel= ow
>>>> IP, right?
>>>
>>> For now, we are dealing with broadcast messages.=C2=A0 Either = over
>>> Bluetooth or WiFI (NAN).
>>
>> If it is a broadcast message and it is over Bluetooth or over WiFi=
>> then it certainly is IP multicast, cant be anything else.
>
> Wrong for BT4.=C2=A0 There are only 25 bytes available.=C2=A0 We can d= o most
> of the messaging in a single frame.=C2=A0 To do anything with IP will<= br> > force this to a multiframe design.

I might say something stupid if I am allowed, maybe things that are
already known.=C2=A0 Sorry, I did not check the BoF archive discussion.=C2= =A0 But
here goes anyways.=C2=A0 If one wants to do something with Bluetooth4 below=
IP and finds it to be too small packets, then there could be several
possibilities:
- do it at Bluetooth SIG instead of IETF;
- do it in 6lo WG;
- use a header compression scheme at IETF (6lowpan HC at 6lo WG, SCHC at =C2=A0 =C2=A0LP-WAN WG, ROHC and why not CBOR);
- implement packet fragmentation and reassembly and multiframe design
=C2=A0 =C2=A0below IP;
- use the already available data in the 25 bytes in order to realize
=C2=A0 =C2=A0that identification (there must be MAC addresses in there, and= they're
=C2=A0 =C2=A0likely to be useful).

> Even BT5 it is wrong for the Authentication Message.=C2=A0 We need the=
> full frame for our content.=C2=A0 We would have to go with multiframe =
> design for BT5 as a result.

So, I do not understand: does DRIP want the entire packet to stay of
size 25bytes?=C2=A0 Or does DRIP want the packet to be more than 25bytes?
Would a multiframe design in which an IP packet of length 1280bytes is
chopped into 25bytes BT5 packets be advantageous for DRIP?

Do the BT5 packets have a notion of interlinking between sub-packets
that make a bigger packet?=C2=A0 (such a mechanism exists at the IP layer; = it
uses Identification to identify a chain and an Offset to say where in
the chain is that sub-packet to be found).

> So this leaves WiFi NAN.=C2=A0 Sure you can do it, but why?=C2=A0 What= does it
> add?=C2=A0 In My Not So Humble Opinion (IMNSOHO) nothing but cost and =
> processing overhead.

I think WiFi 5.4 GHz is already used extensively to remotely control
drones.=C2=A0 These consoles with joysticks are WiFi 5.4GHz, if I am not mistaken.

>> If it is IP multicast over Bluetooth or over WiFi then I wonder >> what is the value=C2=A0 in the Next Header field of the IP header<= br> >> format (RFC8200 "IPv6", section 3 "Header format&qu= ot;).=C2=A0 Basically -
>> what is the payload?
>>
>> If one asks me, I would dare to think that payload might be an >> ICMPv6 Router Advertisement.
>>
>>> There is NO security for the messages below the message packag= e.
>>
>> Noted.
>>
>>> Just not enough payload size for anything that would work in a=
>>> broadcast environment like a National Airspace.=C2=A0 All of t= he
>>> security we are specifying is inside the messages where
>>> appropriate.
>>>
>>> That security manifest is a payload of the ASTM F3411-19
>>> Authentication Message.
>>
>> It costs 85USD I wont pay to see it.=C2=A0 It is security.=C2=A0 T= here will
>> always be someone smarter to break that security and ask for more =
>> money.
>
> Look at:
>
> https://github= .com/opendroneid/specs/blob/master/OpenDroneID_Bluetooth_0.64.3.pdf
>
>
>
It is close enough.

Thanks for the pointer.=C2=A0 Noted.

It is about Bluetooth.=C2=A0 Should be submitted to Bluetooth SIG.

I might stay something stupid here again... si I wont say it :-)

>> I would not oppose if that Authentication MEssage had a
>> specification in clear.
>
> The above plus Adam's draft will get you there.
>
>>
>>> These messages are broadcasted as Adam mentioned in his 'f= lying
>>> DRIP' comments at the beginning.
>>
>> Thank you for the reminder.=C2=A0 I looked again at the 'flyin= g DRIP'
>> presentation during the WG meeting, and at the related draft.
>> ht= tps://datatracker.ietf.org/meeting/108/materials/slides-108-drip-authentica= tion-formats
>>
>>
>>
>> and draft-wiethuechter-drip-auth-01
>>
>> During the presentation, the slide clearly shows on slide 8 that a=
>> Bluetooth header immediately precedes an Open Drone ID message. >> There is no IP header in that slide.
>
> That is right.=C2=A0 No IP.=C2=A0 No room for it.=C2=A0 No justificati= on for it. It
> is all RLOS only.

I might say something stupid here: no IP?=C2=A0 No IETF.

>> In the draft, there is similar discussion tightly related to
>> Bluetooth and without IP.
>>
>> But if we are to have an independence of Bluetooth, and use a
>> networking layer such as IP, then the question of the use of an >> authentication header is made differently.
>
> Again what is the justification for adding IP multicast?

I would not be afraid of IP multicast like the multicast we know for
video delivery.=C2=A0 It is IP multicast because IP is IPv6 and IPv6 has no=
broadcast.

_If_ there is agreement that DRIP should be with IP (Internet Protocol).
We know that the drone identification should be broadcasted (like in TV
broadcast).=C2=A0 In IPv4 there is a mechanism to implement such TV-broadca= st
concept.=C2=A0 It is called IPv4 broadcast.=C2=A0 That broadcast is sent to= a
dedicated address (like 255.255.255.255 which is all Internet, or like
195.212.142.255 which is all computers in a particular subnet).=C2=A0 In IP= v6
such broadcast concept does not exist.=C2=A0 Rather, it's called 'm= ulticast'
and, as opposed to IPv4, it has a mandatory and voluntary join/leave
mechanism.

I name that IPv6 multicast simply IP multicast, because IPv4 should not
be used as basis for any new work at IETF.

On such an IP multicast perspective for DRIP, one would have to come up
with an architecture for joining and leaving that makes it easy to use
by authorities, mandatory to implement, is secure enough (security and
multicast is not that easy), etc.

> Where do you see these messages going beyond the RF Line Of Sight?

True.

But one would not want all BT5 devices (like my watch or earphones)
around a drone's sight to be awaken by its identification beacons,
right?=C2=A0 Only those devices who have voluntarily subscribed to that
multicast group would be awaken.


>> The authentication header would be an IP Authentication Header. >> This AH would be somehow re-used and extended where necessary for =
>> DRIP purposes.
>>
>>> Now later I expect us to move on to Network Remote ID and Comm= and
>>> and Control (C2).
>>>
>>> Most C2 (e.g. Mavlink) is directly over the MAC, but there is = a
>>> method to run it over UDP (I forget the UDP port commonly
>>> used...). AX Enterprize has done this using HIP so the UA star= ts
>>> with WiFi over the launch point, transitions to LTE, and on >>> return back to WiFi.
>>>
>>> Network Remote ID can work either directly from the UA, or via=
>>> C2 information to the GCS, from the GCS.=C2=A0 In either case,= IP is
>>> assumed. This will probably be done via UDP.=C2=A0 From the UA= ,
>>> mobility will be important; from the GCS nice to have (most GC= S
>>> will be stable location).=C2=A0 As UDP to a fixed Net-SP, DTLS= 1.3 is
>>> a viable alternative to HIP.
>>
>> I will have to look closer at HIP again :-) and see how it could >> be made to work with DRIP and IP.
>
> Stu, Adam, Andrei, and I see HIP for where there is pairwise
> communication with potentially both ends mobile and using multiple > interfaces.=C2=A0 Once you have that use case, be consistent and use i= t
> for simpler situations.

I wanted to ask whether using a Host Identity that is cryptographically
generated is sufficient for authorities to trust a drone upon reception
of one DRIP identification packet, or maybe am additional roundrip (a
ping, a request-response) would still be needed from ground officer to
drone to make sure it's the right drone who replies?=C2=A0 Or maybe a f= ull
Diffie-Hellman exchange is needed?

Alex

>
>>
>> Alex
>>
>>>
>>>
>>>
>>>
>>>>
>>>> Alex
>>>>
>>>> as
>>>>> it is specified in ASTM F3411, which most of the regul= ators
>>>>> are dubbing as an approved technical means of regulato= ry
>>>>> compliance.
>>>>>
>>>>> AFAIK, no one runs IP over ADS-B, which was designed a= s a
>>>>> narrowband application specific communications stovepi= pe,
>>>>> not a data link supporting higher layer network protoc= ols,
>>>>> so not great for IP.
>>>>>
>>>>> More importantly, we have no "reluctance about th= e use of...
>>>>>=C2=A0 IP", which is an entirely separate issue fr= om ADS-B.
>>>>>
>>>>> On 8/4/2020 9:52 AM, Alexandre Petrescu wrote:
>>>>>> architectural layers discussion...
>>>>>>
>>>>>> Le 30/07/2020 =C3=A0 11:49, shuaiizhao(Shuai Zhao)= a =C3=A9crit :
>>>>>>> Just to echo Stu on the ADSB, AFAIK, ADSB will= =C2=A0 not be
>>>>>>> feasible for most of the drones mostly due to = SwaP,
>>>>>>> commercial drones might be exception.
>>>>>>
>>>>>> It might be that ADS-B might be forbidden in drone= s on
>>>>>> Earth, but how about the drones on Mars? ('NAS= A Mars
>>>>>> helicopters', or ESA too).=C2=A0 On Mars there= would be much
>>>>>> less such drones, so less risk of interference. >>>>>>
>>>>>> With such a system (ADS-B under IP) one could re-u= se DTN
>>>>>> (Delay Tolerant Networking) between planets, and s= o
>>>>>> identify drones even on Mars.
>>>>>>
>>>>>> But if we have reluctance about the use of ADS-B, = and thus
>>>>>> of IP, and we recommend Bluetooth-without-IP to id= entify
>>>>>> drones, then we might become too dependent on it?<= br> >>>>>>
>>>>>> (do not get me wrong, I do like Bluetooth, but I l= ike many
>>>>>> other things together with Bluetooth).
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>>>
>>>>>>> Best,
>>>>>>>
>>>>>>> Shuai Zhao
>>>>>>>
>>>>>>> *From: *Tm-rid <tm-rid-bounces@ietf.org> on behalf= of
>>>>>>> "Stuart W. Card" <stu.card@axenterprize.com> *Date:
>>>>>>> *Wednesday, July 29, 2020 at 19:46 *To:
>>>>>>> *"
tm-rid@ietf.org" <tm-rid@ietf.org> *Subject: *[Drip]
>>>>>>> ADSB (was: Review of draft-drip-arch-02 w.r.t.= RFC6973,
>>>>>>> RFC8280 and other)(Internet mail)
>>>>>>>
>>>>>>> Sorry for the slow reply.
>>>>>>>
>>>>>>> ADS-B is gradually being mandated for essentia= lly all
>>>>>>> manned aircraft.
>>>>>>>
>>>>>>> ADSB-In and ADSB-Out are mandated for airliner= s: -In
>>>>>>> gives their pilots
>>>>>>>
>>>>>>> some Situational Awareness (SA) of other aircr= aft; -Out
>>>>>>> gives other
>>>>>>>
>>>>>>> pilots SA of the airliners.
>>>>>>>
>>>>>>> "ADSB-Out" is mandated even for smal= l general aviation
>>>>>>> aircraft: it does
>>>>>>>
>>>>>>> not directly benefit the pilots of those aircr= aft; but
>>>>>>> by providing SA
>>>>>>>
>>>>>>> to others, it indirectly benefits all.
>>>>>>>
>>>>>>> ADSB is _not_ going to be deployed on large nu= mbers of
>>>>>>> small UAS as it
>>>>>>>
>>>>>>> would overwhelm the limited bandwidth availabl= e at those
>>>>>>> lower radio
>>>>>>>
>>>>>>> frequencies (which propagate long ranges). In = fact, it
>>>>>>> is expected to be
>>>>>>>
>>>>>>> explicitly prohibited in the US per the FAA NP= RM; I
>>>>>>> suspect most of the
>>>>>>>
>>>>>>> rest of the world will do likewise.
>>>>>>>
>>>>>>> ADSB is also altogether insecure.
>>>>>>>
>>>>>>> On 7/9/2020 3:02 AM, Alexandre Petrescu wrote:=
>>>>>>>
>>>>>>> ...
>>>>>>>
>>>>>>> They call it "ADS-B Receivers" (Auto= matic Dependent
>>>>>>> Surveillance -
>>>>>>>
>>>>>>> Broadcast).
>>>>>>>
>>>>>>> I wouuld like to ask if there is a packet dump= available
>>>>>>> showing such
>>>>>>>
>>>>>>> presence data form planes?=C2=A0 Maybe wiresha= rk already
>>>>>>> supports it, maybe
>>>>>>>
>>>>>>> it even dissects it...
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> -----------------------------------------
>>>>>>>
>>>>>>> Stuart W. Card, PhD, Principal Engineer
>>>>>>>
>>>>>>> AX Enterprize, LLC www.axenterprize.com<= br> >>>>>>>
>>>>>>> 4947 Commercial Drive, Yorkville NY 13495
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>> -- Standard Robert Moskowitz Owner HTT Consulting C:248-219-20= 59
>>> F:248-968-2824 E:rgm@labs.htt-consult.com
>>>
>>> There's no limit to what can be accomplished if it doesn&#= 39;t matter
>>> who gets the credit
>
> -- 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 mat= ter
> who gets the credit

--
Tm-rid mailing list
Tm-rid@ietf.org https://www.ietf.org/mailman/listinfo/tm-rid
--000000000000da80a805ac21a947-- From nobody Wed Aug 5 07:08:22 2020 Return-Path: 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 7B9493A08EC for ; Wed, 5 Aug 2020 07:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, 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 1i7fPjGdgYpS for ; Wed, 5 Aug 2020 07:08:17 -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 CA9563A08D7 for ; Wed, 5 Aug 2020 07:08:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id EF90E62416; Wed, 5 Aug 2020 10:08:14 -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 QLC9zEYAYGOB; Wed, 5 Aug 2020 10:07:57 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (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 C343062422; Wed, 5 Aug 2020 10:07:56 -0400 (EDT) To: Alexandre Petrescu , tm-rid@ietf.org References: <1bebf5b1-1fa5-6902-5bb7-9ec3582e6d9a@andersdotter.cc> <973223fd-0119-376d-12cd-21559a14ce87@labs.htt-consult.com> <3c632ce9-115d-11f5-ee33-bfabd4973522@labs.htt-consult.com> <7ddd9a2f-23ba-dd82-8cfb-1d2974969e67@gmail.com> <61511ef6-5b9b-5b62-f922-d32b994a35b9@gmail.com> From: Robert Moskowitz Message-ID: <6b217b3b-7d06-ffbd-2de1-62e78a3cbf60@labs.htt-consult.com> Date: Wed, 5 Aug 2020 10:07:49 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C7854BC3FF341CE91B7DA983" Content-Language: en-US Archived-At: Subject: Re: [Drip] ADSB X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 14:08:21 -0000 This is a multi-part message in MIME format. --------------C7854BC3FF341CE91B7DA983 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 8/5/20 8:50 AM, Alexandre Petrescu wrote: > > > Le 05/08/2020 à 13:53, Robert Moskowitz a écrit : >> >> >> On 8/5/20 6:11 AM, Alexandre Petrescu wrote: >>> >>> >>> Le 04/08/2020 à 17:51, Robert Moskowitz a écrit : >>>> >>>> >>>> On 8/4/20 11:27 AM, Alexandre Petrescu wrote: >>>>> Thanks for the clarification. >>>>> >>>>> Le 04/08/2020 à 17:17, Stuart W. Card a écrit : >>>>>> I just want to respond to one line that I think comes from >>>>>> confusion: >>>>>> >>>>>>> But if we have reluctance about the use of ADS-B, and thus of >>>>>>> IP, and we recommend Bluetooth-without-IP to identify drones >>>>>> >>>>>> We aren't recommending Bluetooth-without-IP, we are _supporting_ it, >>>>> >>>>> But, the security manifest that I have seen on slides during the >>>>> presentation of the DRIP WG meeting - is something below IP, right? >>>> >>>> For now, we are dealing with broadcast messages.  Either over >>>> Bluetooth or WiFI (NAN). >>> >>> If it is a broadcast message and it is over Bluetooth or over WiFi >>> then it certainly is IP multicast, cant be anything else. >> >> Wrong for BT4.  There are only 25 bytes available.  We can do most >> of the messaging in a single frame.  To do anything with IP will >> force this to a multiframe design. > > I might say something stupid if I am allowed, maybe things that are > already known.  Sorry, I did not check the BoF archive discussion.  But > here goes anyways.  If one wants to do something with Bluetooth4 below > IP and finds it to be too small packets, then there could be several > possibilities: > - do it at Bluetooth SIG instead of IETF; > - do it in 6lo WG; > - use a header compression scheme at IETF (6lowpan HC at 6lo WG, SCHC at >   LP-WAN WG, ROHC and why not CBOR); > - implement packet fragmentation and reassembly and multiframe design >   below IP; > - use the already available data in the 25 bytes in order to realize >   that identification (there must be MAC addresses in there, and they're >   likely to be useful). The reason for DRIP is to leverage IETF technologies to work with existing and planned UAS communications.  The definition of much of these communications are outside of IETF.  We MUST work with the ASTM messages that work within a single BT4 frame.  We CANNOT change this. So what are we doing? First define a stronger RemoteID than has been done and fit this within the defined messages. We are proposing modifying HIP's HIT for this. (drip-uas-rid and drip-auth).  We can't add CBOR as much as I would like to do that... Then once we have strong RemoteID that works on the most constrained communications (BT4) we add functionality.  Like using EPP for registering operators and pilots and UAS.  Using RDAP for Observer authenticated retrieval of said registered info and active operation data from USS/UTM. Adding crowd-sourced collection of the Broadcast messages and using CBOR and CoAP is another area were IETF will add value.  Other organizations (like USAF) are realizing they need better affordable methods for discovering UA and they are talking about what we are defining in my crowd-source-rid draft! But as Stu just said, we deal with the hand dealt.  We cannot change the ASTM messages from the outside, only work within them and then add other communications to the UAS ecosystem. Also if we do this well, it will fit into ALL aviation.  In fact much of my time right now is doing items that will impact all aviation.  Why I really want things to move forward here, as we are getting attention focused on our work. > >> Even BT5 it is wrong for the Authentication Message.  We need the >> full frame for our content.  We would have to go with multiframe >> design for BT5 as a result. > > So, I do not understand: does DRIP want the entire packet to stay of > size 25bytes?  Or does DRIP want the packet to be more than 25bytes? > > Would a multiframe design in which an IP packet of length 1280bytes is > chopped into 25bytes BT5 packets be advantageous for DRIP? > > Do the BT5 packets have a notion of interlinking between sub-packets > that make a bigger packet?  (such a mechanism exists at the IP layer; it > uses Identification to identify a chain and an Offset to say where in > the chain is that sub-packet to be found). > >> So this leaves WiFi NAN.  Sure you can do it, but why?  What does it >> add?  In My Not So Humble Opinion (IMNSOHO) nothing but cost and >> processing overhead. > > I think WiFi 5.4 GHz is already used extensively to remotely control > drones.  These consoles with joysticks are WiFi 5.4GHz, if I am not > mistaken. > >>> If it is IP multicast over Bluetooth or over WiFi then I wonder what >>> is the value  in the Next Header field of the IP header >>> format (RFC8200 "IPv6", section 3 "Header format").  Basically - >>> what is the payload? >>> >>> If one asks me, I would dare to think that payload might be an >>> ICMPv6 Router Advertisement. >>> >>>> There is NO security for the messages below the message package. >>> >>> Noted. >>> >>>> Just not enough payload size for anything that would work in a >>>> broadcast environment like a National Airspace.  All of the >>>> security we are specifying is inside the messages where appropriate. >>>> >>>> That security manifest is a payload of the ASTM F3411-19 >>>> Authentication Message. >>> >>> It costs 85USD I wont pay to see it.  It is security.  There will >>> always be someone smarter to break that security and ask for more >>> money. >> >> Look at: >> >> https://github.com/opendroneid/specs/blob/master/OpenDroneID_Bluetooth_0.64.3.pdf >> >> >> >> > It is close enough. > > Thanks for the pointer.  Noted. > > It is about Bluetooth.  Should be submitted to Bluetooth SIG. > > I might stay something stupid here again... si I wont say it :-) > >>> I would not oppose if that Authentication MEssage had a >>> specification in clear. >> >> The above plus Adam's draft will get you there. >> >>> >>>> These messages are broadcasted as Adam mentioned in his 'flying >>>> DRIP' comments at the beginning. >>> >>> Thank you for the reminder.  I looked again at the 'flying DRIP' >>> presentation during the WG meeting, and at the related draft. >>> https://datatracker.ietf.org/meeting/108/materials/slides-108-drip-authentication-formats >>> >>> >>> >>> and draft-wiethuechter-drip-auth-01 >>> >>> During the presentation, the slide clearly shows on slide 8 that a >>> Bluetooth header immediately precedes an Open Drone ID message. >>> There is no IP header in that slide. >> >> That is right.  No IP.  No room for it.  No justification for it. It >> is all RLOS only. > > I might say something stupid here: no IP?  No IETF. > >>> In the draft, there is similar discussion tightly related to >>> Bluetooth and without IP. >>> >>> But if we are to have an independence of Bluetooth, and use a >>> networking layer such as IP, then the question of the use of an >>> authentication header is made differently. >> >> Again what is the justification for adding IP multicast? > > I would not be afraid of IP multicast like the multicast we know for > video delivery.  It is IP multicast because IP is IPv6 and IPv6 has no > broadcast. > > _If_ there is agreement that DRIP should be with IP (Internet Protocol). > > We know that the drone identification should be broadcasted (like in TV > broadcast).  In IPv4 there is a mechanism to implement such TV-broadcast > concept.  It is called IPv4 broadcast.  That broadcast is sent to a > dedicated address (like 255.255.255.255 which is all Internet, or like > 195.212.142.255 which is all computers in a particular subnet). In IPv6 > such broadcast concept does not exist.  Rather, it's called 'multicast' > and, as opposed to IPv4, it has a mandatory and voluntary join/leave > mechanism. > > I name that IPv6 multicast simply IP multicast, because IPv4 should not > be used as basis for any new work at IETF. > > On such an IP multicast perspective for DRIP, one would have to come up > with an architecture for joining and leaving that makes it easy to use > by authorities, mandatory to implement, is secure enough (security and > multicast is not that easy), etc. > >> Where do you see these messages going beyond the RF Line Of Sight? > > True. > > But one would not want all BT5 devices (like my watch or earphones) > around a drone's sight to be awaken by its identification beacons, > right?  Only those devices who have voluntarily subscribed to that > multicast group would be awaken. > > >>> The authentication header would be an IP Authentication Header. This >>> AH would be somehow re-used and extended where necessary for DRIP >>> purposes. >>> >>>> Now later I expect us to move on to Network Remote ID and Command >>>> and Control (C2). >>>> >>>> Most C2 (e.g. Mavlink) is directly over the MAC, but there is a >>>> method to run it over UDP (I forget the UDP port commonly used...). >>>> AX Enterprize has done this using HIP so the UA starts with WiFi >>>> over the launch point, transitions to LTE, and on return back to WiFi. >>>> >>>> Network Remote ID can work either directly from the UA, or via >>>> C2 information to the GCS, from the GCS.  In either case, IP is >>>> assumed. This will probably be done via UDP.  From the UA, mobility >>>> will be important; from the GCS nice to have (most GCS will be >>>> stable location).  As UDP to a fixed Net-SP, DTLS 1.3 is a viable >>>> alternative to HIP. >>> >>> I will have to look closer at HIP again :-) and see how it could >>> be made to work with DRIP and IP. >> >> Stu, Adam, Andrei, and I see HIP for where there is pairwise >> communication with potentially both ends mobile and using multiple >> interfaces.  Once you have that use case, be consistent and use it >> for simpler situations. > > I wanted to ask whether using a Host Identity that is cryptographically > generated is sufficient for authorities to trust a drone upon reception > of one DRIP identification packet, or maybe am additional roundrip (a > ping, a request-response) would still be needed from ground officer to > drone to make sure it's the right drone who replies?  Or maybe a full > Diffie-Hellman exchange is needed? > > Alex > >> >>> >>> Alex >>> >>>> >>>> >>>> >>>> >>>>> >>>>> Alex >>>>> >>>>> as >>>>>> it is specified in ASTM F3411, which most of the regulators are >>>>>> dubbing as an approved technical means of regulatory compliance. >>>>>> >>>>>> AFAIK, no one runs IP over ADS-B, which was designed as a >>>>>> narrowband application specific communications stovepipe, >>>>>> not a data link supporting higher layer network protocols, >>>>>> so not great for IP. >>>>>> >>>>>> More importantly, we have no "reluctance about the use of... >>>>>>  IP", which is an entirely separate issue from ADS-B. >>>>>> >>>>>> On 8/4/2020 9:52 AM, Alexandre Petrescu wrote: >>>>>>> architectural layers discussion... >>>>>>> >>>>>>> Le 30/07/2020 à 11:49, shuaiizhao(Shuai Zhao) a écrit : >>>>>>>> Just to echo Stu on the ADSB, AFAIK, ADSB will  not be feasible >>>>>>>> for most of the drones mostly due to SwaP, commercial drones >>>>>>>> might be exception. >>>>>>> >>>>>>> It might be that ADS-B might be forbidden in drones on Earth, >>>>>>> but how about the drones on Mars? ('NASA Mars helicopters', or >>>>>>> ESA too).  On Mars there would be much less such drones, so less >>>>>>> risk of interference. >>>>>>> >>>>>>> With such a system (ADS-B under IP) one could re-use DTN (Delay >>>>>>> Tolerant Networking) between planets, and so identify drones >>>>>>> even on Mars. >>>>>>> >>>>>>> But if we have reluctance about the use of ADS-B, and thus of >>>>>>> IP, and we recommend Bluetooth-without-IP to identify drones, >>>>>>> then we might become too dependent on it? >>>>>>> >>>>>>> (do not get me wrong, I do like Bluetooth, but I like many other >>>>>>> things together with Bluetooth). >>>>>>> >>>>>>> Alex >>>>>>> >>>>>>>> >>>>>>>> Best, >>>>>>>> >>>>>>>> Shuai Zhao >>>>>>>> >>>>>>>> *From: *Tm-rid on behalf of "Stuart >>>>>>>> W. Card" *Date: *Wednesday, July >>>>>>>> 29, 2020 at 19:46 *To: *"tm-rid@ietf.org" >>>>>>>> *Subject: *[Drip] ADSB (was: Review of draft-drip-arch-02 >>>>>>>> w.r.t. RFC6973, RFC8280 and other)(Internet mail) >>>>>>>> >>>>>>>> Sorry for the slow reply. >>>>>>>> >>>>>>>> ADS-B is gradually being mandated for essentially all manned >>>>>>>> aircraft. >>>>>>>> >>>>>>>> ADSB-In and ADSB-Out are mandated for airliners: -In gives >>>>>>>> their pilots >>>>>>>> >>>>>>>> some Situational Awareness (SA) of other aircraft; -Out gives >>>>>>>> other >>>>>>>> >>>>>>>> pilots SA of the airliners. >>>>>>>> >>>>>>>> "ADSB-Out" is mandated even for small general aviation >>>>>>>> aircraft: it does >>>>>>>> >>>>>>>> not directly benefit the pilots of those aircraft; but >>>>>>>> by providing SA >>>>>>>> >>>>>>>> to others, it indirectly benefits all. >>>>>>>> >>>>>>>> ADSB is _not_ going to be deployed on large numbers of small >>>>>>>> UAS as it >>>>>>>> >>>>>>>> would overwhelm the limited bandwidth available at those lower >>>>>>>> radio >>>>>>>> >>>>>>>> frequencies (which propagate long ranges). In fact, it >>>>>>>> is expected to be >>>>>>>> >>>>>>>> explicitly prohibited in the US per the FAA NPRM; I suspect >>>>>>>> most of the >>>>>>>> >>>>>>>> rest of the world will do likewise. >>>>>>>> >>>>>>>> ADSB is also altogether insecure. >>>>>>>> >>>>>>>> On 7/9/2020 3:02 AM, Alexandre Petrescu wrote: >>>>>>>> >>>>>>>> ... >>>>>>>> >>>>>>>> They call it "ADS-B Receivers" (Automatic Dependent Surveillance - >>>>>>>> >>>>>>>> Broadcast). >>>>>>>> >>>>>>>> I wouuld like to ask if there is a packet dump available >>>>>>>> showing such >>>>>>>> >>>>>>>> presence data form planes?  Maybe wireshark already supports >>>>>>>> it, maybe >>>>>>>> >>>>>>>> it even dissects it... >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> ----------------------------------------- >>>>>>>> >>>>>>>> Stuart W. Card, PhD, Principal Engineer >>>>>>>> >>>>>>>> AX Enterprize, LLC www.axenterprize.com >>>>>>>> >>>>>>>> 4947 Commercial Drive, Yorkville NY 13495 >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> -- 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 >> >> -- 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 > -- 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 --------------C7854BC3FF341CE91B7DA983 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 8/5/20 8:50 AM, Alexandre Petrescu wrote:


Le 05/08/2020 à 13:53, Robert Moskowitz a écrit :


On 8/5/20 6:11 AM, Alexandre Petrescu wrote:


Le 04/08/2020 à 17:51, Robert Moskowitz a écrit :


On 8/4/20 11:27 AM, Alexandre Petrescu wrote:
Thanks for the clarification.

Le 04/08/2020 à 17:17, Stuart W. Card a écrit :
I just want to respond to one line that I think comes from confusion:

But if we have reluctance about the use of ADS-B, and thus of IP, and we recommend Bluetooth-without-IP to identify drones

We aren't recommending Bluetooth-without-IP, we are _supporting_ it,

But, the security manifest that I have seen on slides during the presentation of the DRIP WG meeting - is something below IP, right?

For now, we are dealing with broadcast messages.  Either over Bluetooth or WiFI (NAN).

If it is a broadcast message and it is over Bluetooth or over WiFi then it certainly is IP multicast, cant be anything else.

Wrong for BT4.  There are only 25 bytes available.  We can do most
of the messaging in a single frame.  To do anything with IP will
force this to a multiframe design.

I might say something stupid if I am allowed, maybe things that are
already known.  Sorry, I did not check the BoF archive discussion.  But
here goes anyways.  If one wants to do something with Bluetooth4 below
IP and finds it to be too small packets, then there could be several
possibilities:
- do it at Bluetooth SIG instead of IETF;
- do it in 6lo WG;
- use a header compression scheme at IETF (6lowpan HC at 6lo WG, SCHC at
  LP-WAN WG, ROHC and why not CBOR);
- implement packet fragmentation and reassembly and multiframe design
  below IP;
- use the already available data in the 25 bytes in order to realize
  that identification (there must be MAC addresses in there, and they're
  likely to be useful).

The reason for DRIP is to leverage IETF technologies to work with existing and planned UAS communications.  The definition of much of these communications are outside of IETF.  We MUST work with the ASTM messages that work within a single BT4 frame.  We CANNOT change this.

So what are we doing?

First define a stronger RemoteID than has been done and fit this within the defined messages.

We are proposing modifying HIP's HIT for this. (drip-uas-rid and drip-auth).  We can't add CBOR as much as I would like to do that...

Then once we have strong RemoteID that works on the most constrained communications (BT4) we add functionality.  Like using EPP for registering operators and pilots and UAS.  Using RDAP for Observer authenticated retrieval of said registered info and active operation data from USS/UTM.

Adding crowd-sourced collection of the Broadcast messages and using CBOR and CoAP is another area were IETF will add value.  Other organizations (like USAF) are realizing they need better affordable methods for discovering UA and they are talking about what we are defining in my crowd-source-rid draft!

But as Stu just said, we deal with the hand dealt.  We cannot change the ASTM messages from the outside, only work within them and then add other communications to the UAS ecosystem.

Also if we do this well, it will fit into ALL aviation.  In fact much of my time right now is doing items that will impact all aviation.  Why I really want things to move forward here, as we are getting attention focused on our work.


Even BT5 it is wrong for the Authentication Message.  We need the full frame for our content.  We would have to go with multiframe design for BT5 as a result.

So, I do not understand: does DRIP want the entire packet to stay of
size 25bytes?  Or does DRIP want the packet to be more than 25bytes?

Would a multiframe design in which an IP packet of length 1280bytes is
chopped into 25bytes BT5 packets be advantageous for DRIP?

Do the BT5 packets have a notion of interlinking between sub-packets
that make a bigger packet?  (such a mechanism exists at the IP layer; it
uses Identification to identify a chain and an Offset to say where in
the chain is that sub-packet to be found).

So this leaves WiFi NAN.  Sure you can do it, but why?  What does it add?  In My Not So Humble Opinion (IMNSOHO) nothing but cost and processing overhead.

I think WiFi 5.4 GHz is already used extensively to remotely control
drones.  These consoles with joysticks are WiFi 5.4GHz, if I am not
mistaken.

If it is IP multicast over Bluetooth or over WiFi then I wonder what is the value  in the Next Header field of the IP header
format (RFC8200 "IPv6", section 3 "Header format").  Basically -
what is the payload?

If one asks me, I would dare to think that payload might be an ICMPv6 Router Advertisement.

There is NO security for the messages below the message package.

Noted.

Just not enough payload size for anything that would work in a broadcast environment like a National Airspace.  All of the security we are specifying is inside the messages where appropriate.

That security manifest is a payload of the ASTM F3411-19 Authentication Message.

It costs 85USD I wont pay to see it.  It is security.  There will always be someone smarter to break that security and ask for more money.

Look at:

https://github.com/opendroneid/specs/blob/master/OpenDroneID_Bluetooth_0.64.3.pdf



It is close enough.

Thanks for the pointer.  Noted.

It is about Bluetooth.  Should be submitted to Bluetooth SIG.

I might stay something stupid here again... si I wont say it :-)

I would not oppose if that Authentication MEssage had a specification in clear.

The above plus Adam's draft will get you there.


These messages are broadcasted as Adam mentioned in his 'flying DRIP' comments at the beginning.

Thank you for the reminder.  I looked again at the 'flying DRIP' presentation during the WG meeting, and at the related draft. https://datatracker.ietf.org/meeting/108/materials/slides-108-drip-authentication-formats



and draft-wiethuechter-drip-auth-01

During the presentation, the slide clearly shows on slide 8 that a Bluetooth header immediately precedes an Open Drone ID message. There is no IP header in that slide.

That is right.  No IP.  No room for it.  No justification for it. It is all RLOS only.

I might say something stupid here: no IP?  No IETF.

In the draft, there is similar discussion tightly related to Bluetooth and without IP.

But if we are to have an independence of Bluetooth, and use a networking layer such as IP, then the question of the use of an authentication header is made differently.

Again what is the justification for adding IP multicast?

I would not be afraid of IP multicast like the multicast we know for
video delivery.  It is IP multicast because IP is IPv6 and IPv6 has no
broadcast.

_If_ there is agreement that DRIP should be with IP (Internet Protocol).

We know that the drone identification should be broadcasted (like in TV
broadcast).  In IPv4 there is a mechanism to implement such TV-broadcast
concept.  It is called IPv4 broadcast.  That broadcast is sent to a
dedicated address (like 255.255.255.255 which is all Internet, or like
195.212.142.255 which is all computers in a particular subnet).  In IPv6
such broadcast concept does not exist.  Rather, it's called 'multicast'
and, as opposed to IPv4, it has a mandatory and voluntary join/leave
mechanism.

I name that IPv6 multicast simply IP multicast, because IPv4 should not
be used as basis for any new work at IETF.

On such an IP multicast perspective for DRIP, one would have to come up
with an architecture for joining and leaving that makes it easy to use
by authorities, mandatory to implement, is secure enough (security and
multicast is not that easy), etc.

Where do you see these messages going beyond the RF Line Of Sight?

True.

But one would not want all BT5 devices (like my watch or earphones)
around a drone's sight to be awaken by its identification beacons,
right?  Only those devices who have voluntarily subscribed to that
multicast group would be awaken.


The authentication header would be an IP Authentication Header. This AH would be somehow re-used and extended where necessary for DRIP purposes.

Now later I expect us to move on to Network Remote ID and Command
and Control (C2).

Most C2 (e.g. Mavlink) is directly over the MAC, but there is a method to run it over UDP (I forget the UDP port commonly used...). AX Enterprize has done this using HIP so the UA starts with WiFi over the launch point, transitions to LTE, and on return back to WiFi.

Network Remote ID can work either directly from the UA, or via
C2 information to the GCS, from the GCS.  In either case, IP is assumed. This will probably be done via UDP.  From the UA, mobility will be important; from the GCS nice to have (most GCS will be stable location).  As UDP to a fixed Net-SP, DTLS 1.3 is a viable alternative to HIP.

I will have to look closer at HIP again :-) and see how it could
be made to work with DRIP and IP.

Stu, Adam, Andrei, and I see HIP for where there is pairwise communication with potentially both ends mobile and using multiple interfaces.  Once you have that use case, be consistent and use it for simpler situations.

I wanted to ask whether using a Host Identity that is cryptographically
generated is sufficient for authorities to trust a drone upon reception
of one DRIP identification packet, or maybe am additional roundrip (a
ping, a request-response) would still be needed from ground officer to
drone to make sure it's the right drone who replies?  Or maybe a full
Diffie-Hellman exchange is needed?

Alex



Alex






Alex

as
it is specified in ASTM F3411, which most of the regulators are dubbing as an approved technical means of regulatory compliance.

AFAIK, no one runs IP over ADS-B, which was designed as a narrowband application specific communications stovepipe,
not a data link supporting higher layer network protocols,
so not great for IP.

More importantly, we have no "reluctance about the use of...
 IP", which is an entirely separate issue from ADS-B.

On 8/4/2020 9:52 AM, Alexandre Petrescu wrote:
architectural layers discussion...

Le 30/07/2020 à 11:49, shuaiizhao(Shuai Zhao) a écrit :
Just to echo Stu on the ADSB, AFAIK, ADSB will  not be feasible for most of the drones mostly due to SwaP, commercial drones might be exception.

It might be that ADS-B might be forbidden in drones on Earth, but how about the drones on Mars? ('NASA Mars helicopters', or ESA too).  On Mars there would be much less such drones, so less risk of interference.

With such a system (ADS-B under IP) one could re-use DTN (Delay Tolerant Networking) between planets, and so identify drones even on Mars.

But if we have reluctance about the use of ADS-B, and thus of IP, and we recommend Bluetooth-without-IP to identify drones, then we might become too dependent on it?

(do not get me wrong, I do like Bluetooth, but I like many other things together with Bluetooth).

Alex


Best,

Shuai Zhao

*From: *Tm-rid <tm-rid-bounces@ietf.org> on behalf of "Stuart W. Card" <stu.card@axenterprize.com> *Date: *Wednesday, July 29, 2020 at 19:46 *To: *"tm-rid@ietf.org" <tm-rid@ietf.org> *Subject: *[Drip] ADSB (was: Review of draft-drip-arch-02 w.r.t. RFC6973, RFC8280 and other)(Internet mail)

Sorry for the slow reply.

ADS-B is gradually being mandated for essentially all manned aircraft.

ADSB-In and ADSB-Out are mandated for airliners: -In gives their pilots

some Situational Awareness (SA) of other aircraft; -Out gives other

pilots SA of the airliners.

"ADSB-Out" is mandated even for small general aviation aircraft: it does

not directly benefit the pilots of those aircraft; but
by providing SA

to others, it indirectly benefits all.

ADSB is _not_ going to be deployed on large numbers of small UAS as it

would overwhelm the limited bandwidth available at those lower radio

frequencies (which propagate long ranges). In fact, it
is expected to be

explicitly prohibited in the US per the FAA NPRM; I suspect most of the

rest of the world will do likewise.

ADSB is also altogether insecure.

On 7/9/2020 3:02 AM, Alexandre Petrescu wrote:

...

They call it "ADS-B Receivers" (Automatic Dependent Surveillance -

Broadcast).

I wouuld like to ask if there is a packet dump available showing such

presence data form planes?  Maybe wireshark already supports it, maybe

it even dissects it...

--

-----------------------------------------

Stuart W. Card, PhD, Principal Engineer

AX Enterprize, LLC www.axenterprize.com

4947 Commercial Drive, Yorkville NY 13495








-- 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

-- 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


--
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
--------------C7854BC3FF341CE91B7DA983-- From nobody Wed Aug 5 07:22:15 2020 Return-Path: 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 C61263A091B for ; Wed, 5 Aug 2020 07:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.278 X-Spam-Level: X-Spam-Status: No, score=-0.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.949, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 5OIcBhH_tnHw for ; Wed, 5 Aug 2020 07:22:10 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 59EA83A090E for ; Wed, 5 Aug 2020 07:22:10 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 075EM8Hg024858; Wed, 5 Aug 2020 16:22:08 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 55041203F09; Wed, 5 Aug 2020 16:22:08 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 44F02203E7D; Wed, 5 Aug 2020 16:22:08 +0200 (CEST) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 075EM8FR002522; Wed, 5 Aug 2020 16:22:08 +0200 To: "Card, Stu" Cc: Robert Moskowitz , tm-rid@ietf.org References: <1bebf5b1-1fa5-6902-5bb7-9ec3582e6d9a@andersdotter.cc> <01a21161-aa8d-6d4b-b384-3129fe6d799b@gmail.com> <973223fd-0119-376d-12cd-21559a14ce87@labs.htt-consult.com> <3c632ce9-115d-11f5-ee33-bfabd4973522@labs.htt-consult.com> <7ddd9a2f-23ba-dd82-8cfb-1d2974969e67@gmail.com> <61511ef6-5b9b-5b62-f922-d32b994a35b9@gmail.com> From: Alexandre Petrescu Message-ID: Date: Wed, 5 Aug 2020 16:22:09 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Drip] ADSB X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 14:22:15 -0000 Hi, Thank you for the reply. Le 05/08/2020 à 15:38, Card, Stu a écrit : > Again, I wish to respond primarily to one line that again I believe > results from some confusion. > >> If it is a broadcast message and it is over Bluetooth or over WiFi >> then it certainly is IP multicast, cant be anything else. > > There is nothing preventing application layer protocols from being > layered directly over link layer protocols. This is exactly what is > typically done with Bluetooth, not only for UAS RID, but other > applications as well. It can even be done with WiFi, Ethernet, etc., > although this is less commonly done. This certainly limits > flexibility and internetworking. Again, however, this is not up to > us: the regulators are citing ASTM F3411 for UAS RID; that standard > defines how to put UAS RID application specific message formats > directly into Bluetooth link layer frames, without any intervening > headers (such as would be required for IP encapsulation of the app > layer messages). While I think their specifying Bluetooth generally > was a bad idea (for many reasons, including range as you mention, as > has been confirmed marginal in our testing), and supporting legacy > Bluetooth 4 specifically was an even worse idea (for even lower range > and its incredibly short 25 byte payloads), this decision was not > made by, and cannot be reversed by, the DRIP WG. We can only hope to > mitigate its security deficiencies, address the issues it fails to > address (such as how registries work and how communications between > an Observer and a Remote Pilot can be initiated), and improve its > interoperability with the Internet once we get beyond the Broadcast > RID data link. It does clarify the point of view. I will try to get along with the described view. The best part that I could follow is the part of DRIP developments that improve the interoperability with the Internet. In 6lo there was a perspective of a Gateway, or a 'backbone router', that would link many small Bluetooth devices to the Internet. But unfortunately it is a smart network, instead of a 'smart end dumb network'. lpwan directions too are distanced from the 'smart end dumb network', because they dont use IP headers either: SCHC removes them. I also struggle via IPWAVE WG for the use of IP networking layer for automobiles, as opposed to IEEE P1609.3 Networking layer, and that too is far from being a win. Overall, there seems to be an agreement on tendency to act more and more that way that you describe. There is a draft that presents that in a advantageous light; it's titled "Limited Domains", in which one could do many things precisely as one wishes, and not as being Internet as IP is. I will try to follow the developments along these lines. Alex > > On Wed, Aug 5, 2020 at 6:11 AM Alexandre Petrescu > > > wrote: > > > > Le 04/08/2020 à 17:51, Robert Moskowitz a écrit : >> >> >> On 8/4/20 11:27 AM, Alexandre Petrescu wrote: >>> Thanks for the clarification. >>> >>> Le 04/08/2020 à 17:17, Stuart W. Card a écrit : >>>> I just want to respond to one line that I think comes from >>>> confusion: >>>> >>>>> But if we have reluctance about the use of ADS-B, and thus >>>>> of IP, and we recommend Bluetooth-without-IP to identify >>>>> drones >>>> >>>> We aren't recommending Bluetooth-without-IP, we are >>>> _supporting_ it, >>> >>> But, the security manifest that I have seen on slides during the >>> presentation of the DRIP WG meeting - is something below IP, >>> right? >> >> For now, we are dealing with broadcast messages. Either over >> Bluetooth or WiFI (NAN). > > If it is a broadcast message and it is over Bluetooth or over WiFi > then it certainly is IP multicast, cant be anything else. > > If it is IP multicast over Bluetooth or over WiFi then I wonder what > is the value in the Next Header field of the IP header format > (RFC8200 "IPv6", section 3 "Header format"). Basically - what is the > payload? > > If one asks me, I would dare to think that payload might be an > ICMPv6 Router Advertisement. > >> There is NO security for the messages below the message package. > > Noted. > >> Just not enough payload size for anything that would work in a >> broadcast environment like a National Airspace. All of the >> security we are specifying is inside the messages where >> appropriate. >> >> That security manifest is a payload of the ASTM F3411-19 >> Authentication Message. > > It costs 85USD I wont pay to see it. It is security. There will > always be someone smarter to break that security and ask for more > money. > > I would not oppose if that Authentication MEssage had a specification > in clear. > >> These messages are broadcasted as Adam mentioned in his 'flying >> DRIP' comments at the beginning. > > Thank you for the reminder. I looked again at the 'flying DRIP' > presentation during the WG meeting, and at the related draft. > https://datatracker.ietf.org/meeting/108/materials/slides-108-drip-authentication-formats > > and > draft-wiethuechter-drip-auth-01 > > During the presentation, the slide clearly shows on slide 8 that a > Bluetooth header immediately precedes an Open Drone ID message. > There is no IP header in that slide. > > In the draft, there is similar discussion tightly related to > Bluetooth and without IP. > > But if we are to have an independence of Bluetooth, and use a > networking layer such as IP, then the question of the use of an > authentication header is made differently. > > The authentication header would be an IP Authentication Header. This > AH would be somehow re-used and extended where necessary for DRIP > purposes. > >> Now later I expect us to move on to Network Remote ID and Command >> and Control (C2). >> >> Most C2 (e.g. Mavlink) is directly over the MAC, but there is a >> method to run it over UDP (I forget the UDP port commonly >> used...). AX Enterprize has done this using HIP so the UA starts >> with WiFi over the launch point, transitions to LTE, and on return >> back to WiFi. >> >> Network Remote ID can work either directly from the UA, or via C2 >> information to the GCS, from the GCS. In either case, IP is >> assumed. This will probably be done via UDP. From the UA, >> mobility will be important; from the GCS nice to have (most GCS >> will be stable location). As UDP to a fixed Net-SP, DTLS 1.3 is a >> viable alternative to HIP. > > I will have to look closer at HIP again :-) and see how it could be > made to work with DRIP and IP. > > Alex > >> >> >> >> >>> >>> Alex >>> >>> as >>>> it is specified in ASTM F3411, which most of the regulators >>>> are dubbing as an approved technical means of regulatory >>>> compliance. >>>> >>>> AFAIK, no one runs IP over ADS-B, which was designed as a >>>> narrowband application specific communications stovepipe, not >>>> a data link supporting higher layer network protocols, so not >>>> great for IP. >>>> >>>> More importantly, we have no "reluctance about the use of... >>>> IP", which is an entirely separate issue from ADS-B. >>>> >>>> On 8/4/2020 9:52 AM, Alexandre Petrescu wrote: >>>>> architectural layers discussion... >>>>> >>>>> Le 30/07/2020 à 11:49, shuaiizhao(Shuai Zhao) a écrit : >>>>>> Just to echo Stu on the ADSB, AFAIK, ADSB will not be >>>>>> feasible for most of the drones mostly due to SwaP, >>>>>> commercial drones might be exception. >>>>> >>>>> It might be that ADS-B might be forbidden in drones on >>>>> Earth, but how about the drones on Mars? ('NASA Mars >>>>> helicopters', or ESA too). On Mars there would be much less >>>>> such drones, so less risk of interference. >>>>> >>>>> With such a system (ADS-B under IP) one could re-use DTN >>>>> (Delay Tolerant Networking) between planets, and so identify >>>>> drones even on Mars. >>>>> >>>>> But if we have reluctance about the use of ADS-B, and thus >>>>> of IP, and we recommend Bluetooth-without-IP to identify >>>>> drones, then we might become too dependent on it? >>>>> >>>>> (do not get me wrong, I do like Bluetooth, but I like many >>>>> other things together with Bluetooth). >>>>> >>>>> Alex >>>>> >>>>>> >>>>>> Best, >>>>>> >>>>>> Shuai Zhao >>>>>> >>>>>> *From: *Tm-rid > on behalf of >>>>>> "Stuart W. Card" > *Date: >>>>>> *Wednesday, July 29, 2020 at 19:46 *To: *"tm-rid@ietf.org > " >>>>>> > *Subject: >>>>>> *[Drip] > ADSB (was: Review of >>>>>> draft-drip-arch-02 w.r.t. RFC6973, RFC8280 and >>>>>> other)(Internet mail) >>>>>> >>>>>> Sorry for the slow reply. >>>>>> >>>>>> ADS-B is gradually being mandated for essentially all >>>>>> manned aircraft. >>>>>> >>>>>> ADSB-In and ADSB-Out are mandated for airliners: -In gives >>>>>> their pilots >>>>>> >>>>>> some Situational Awareness (SA) of other aircraft; -Out >>>>>> gives other >>>>>> >>>>>> pilots SA of the airliners. >>>>>> >>>>>> "ADSB-Out" is mandated even for small general aviation >>>>>> aircraft: it does >>>>>> >>>>>> not directly benefit the pilots of those aircraft; but by >>>>>> providing SA >>>>>> >>>>>> to others, it indirectly benefits all. >>>>>> >>>>>> ADSB is _not_ going to be deployed on large numbers of >>>>>> small UAS as it >>>>>> >>>>>> would overwhelm the limited bandwidth available at those >>>>>> lower radio >>>>>> >>>>>> frequencies (which propagate long ranges). In fact, it is >>>>>> expected to be >>>>>> >>>>>> explicitly prohibited in the US per the FAA NPRM; I >>>>>> suspect most of the >>>>>> >>>>>> rest of the world will do likewise. >>>>>> >>>>>> ADSB is also altogether insecure. >>>>>> >>>>>> On 7/9/2020 3:02 AM, Alexandre Petrescu wrote: >>>>>> >>>>>> ... >>>>>> >>>>>> They call it "ADS-B Receivers" (Automatic Dependent >>>>>> Surveillance - >>>>>> >>>>>> Broadcast). >>>>>> >>>>>> I wouuld like to ask if there is a packet dump available >>>>>> showing such >>>>>> >>>>>> presence data form planes? Maybe wireshark already >>>>>> supports it, maybe >>>>>> >>>>>> it even dissects it... >>>>>> >>>>>> -- >>>>>> >>>>>> ----------------------------------------- >>>>>> >>>>>> Stuart W. Card, PhD, Principal Engineer >>>>>> >>>>>> AX Enterprize, LLC www.axenterprize.com > >>>>>> >>>>>> 4947 Commercial Drive, Yorkville NY 13495 >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> >> >> -- 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 > > -- Tm-rid mailing list Tm-rid@ietf.org > https://www.ietf.org/mailman/listinfo/tm-rid > From nobody Wed Aug 5 07:23:31 2020 Return-Path: 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 0EDF13A0985 for ; Wed, 5 Aug 2020 07:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.278 X-Spam-Level: X-Spam-Status: No, score=-0.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.949, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 oGy8gRZ89qks for ; Wed, 5 Aug 2020 07:23:27 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 885743A094F for ; Wed, 5 Aug 2020 07:23:27 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 075ENPlk025178; Wed, 5 Aug 2020 16:23:25 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B2943203F91; Wed, 5 Aug 2020 16:23:25 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A1AB7203E7D; Wed, 5 Aug 2020 16:23:25 +0200 (CEST) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 075ENPML003204; Wed, 5 Aug 2020 16:23:25 +0200 To: "Card, Stu" Cc: Robert Moskowitz , tm-rid@ietf.org References: <1bebf5b1-1fa5-6902-5bb7-9ec3582e6d9a@andersdotter.cc> <3c632ce9-115d-11f5-ee33-bfabd4973522@labs.htt-consult.com> <7ddd9a2f-23ba-dd82-8cfb-1d2974969e67@gmail.com> <61511ef6-5b9b-5b62-f922-d32b994a35b9@gmail.com> From: Alexandre Petrescu Message-ID: <2e1cbffc-8554-222b-d558-43e048194104@gmail.com> Date: Wed, 5 Aug 2020 16:23:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Drip] ADSB X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 14:23:30 -0000 Le 05/08/2020 à 15:50, Card, Stu a écrit : > Again, a single point response. The reason this work is appropriate for > IETF rather than the Bluetooth SIG is that ASTM F3411 specifies > Bluetooth _only_ as one transport for Broadcast RID (WiFi NaN is also > specified and other alternatives could be added later, as you, Bob and > others are discussing, also consider RTCA SC-228 DO-362 UAS C2 Data Link > at ~1 and ~5 GHz), but there is also Network RID where ASTM F3411 > specifies use of the Internet, and a lot more to the overall UAS RID > architecture/problem than just the initial streaming of messages from > the UAS. > > Please look at the openly published early draft of ASTM F3411 to which > Bob pointed you, I looked and I will keep it aside for reference when needed. It's an Intel document. https://github.com/opendroneid/specs/blob/master/OpenDroneID_Bluetooth_0.64.3.pdf Alex and perhaps some of the other external docs cited in > the DRIP requirements draft, for  essential context on the UAS RID > problem and what others have already done to address it, which we hope > to complement (not replace) with DRIP. Thanks! > > > On Wed, Aug 5, 2020 at 8:50 AM Alexandre Petrescu > > wrote: > > > > Le 05/08/2020 à 13:53, Robert Moskowitz a écrit : > > > > > > On 8/5/20 6:11 AM, Alexandre Petrescu wrote: > >> > >> > >> Le 04/08/2020 à 17:51, Robert Moskowitz a écrit : > >>> > >>> > >>> On 8/4/20 11:27 AM, Alexandre Petrescu wrote: > >>>> Thanks for the clarification. > >>>> > >>>> Le 04/08/2020 à 17:17, Stuart W. Card a écrit : > >>>>> I just want to respond to one line that I think comes from > >>>>> confusion: > >>>>> > >>>>>> But if we have reluctance about the use of ADS-B, and thus > >>>>>> of IP, and we recommend Bluetooth-without-IP to identify > >>>>>> drones > >>>>> > >>>>> We aren't recommending Bluetooth-without-IP, we are > >>>>> _supporting_ it, > >>>> > >>>> But, the security manifest that I have seen on slides during > >>>> the presentation of the DRIP WG meeting - is something below > >>>> IP, right? > >>> > >>> For now, we are dealing with broadcast messages.  Either over > >>> Bluetooth or WiFI (NAN). > >> > >> If it is a broadcast message and it is over Bluetooth or over WiFi > >> then it certainly is IP multicast, cant be anything else. > > > > Wrong for BT4.  There are only 25 bytes available.  We can do most > > of the messaging in a single frame.  To do anything with IP will > > force this to a multiframe design. > > I might say something stupid if I am allowed, maybe things that are > already known.  Sorry, I did not check the BoF archive discussion.  But > here goes anyways.  If one wants to do something with Bluetooth4 below > IP and finds it to be too small packets, then there could be several > possibilities: > - do it at Bluetooth SIG instead of IETF; > - do it in 6lo WG; > - use a header compression scheme at IETF (6lowpan HC at 6lo WG, SCHC at >    LP-WAN WG, ROHC and why not CBOR); > - implement packet fragmentation and reassembly and multiframe design >    below IP; > - use the already available data in the 25 bytes in order to realize >    that identification (there must be MAC addresses in there, and > they're >    likely to be useful). > > > Even BT5 it is wrong for the Authentication Message.  We need the > > full frame for our content.  We would have to go with multiframe > > design for BT5 as a result. > > So, I do not understand: does DRIP want the entire packet to stay of > size 25bytes?  Or does DRIP want the packet to be more than 25bytes? > > Would a multiframe design in which an IP packet of length 1280bytes is > chopped into 25bytes BT5 packets be advantageous for DRIP? > > Do the BT5 packets have a notion of interlinking between sub-packets > that make a bigger packet?  (such a mechanism exists at the IP layer; it > uses Identification to identify a chain and an Offset to say where in > the chain is that sub-packet to be found). > > > So this leaves WiFi NAN.  Sure you can do it, but why?  What does it > > add?  In My Not So Humble Opinion (IMNSOHO) nothing but cost and > > processing overhead. > > I think WiFi 5.4 GHz is already used extensively to remotely control > drones.  These consoles with joysticks are WiFi 5.4GHz, if I am not > mistaken. > > >> If it is IP multicast over Bluetooth or over WiFi then I wonder > >> what is the value  in the Next Header field of the IP header > >> format (RFC8200 "IPv6", section 3 "Header format").  Basically - > >> what is the payload? > >> > >> If one asks me, I would dare to think that payload might be an > >> ICMPv6 Router Advertisement. > >> > >>> There is NO security for the messages below the message package. > >> > >> Noted. > >> > >>> Just not enough payload size for anything that would work in a > >>> broadcast environment like a National Airspace.  All of the > >>> security we are specifying is inside the messages where > >>> appropriate. > >>> > >>> That security manifest is a payload of the ASTM F3411-19 > >>> Authentication Message. > >> > >> It costs 85USD I wont pay to see it.  It is security.  There will > >> always be someone smarter to break that security and ask for more > >> money. > > > > Look at: > > > > > https://github.com/opendroneid/specs/blob/master/OpenDroneID_Bluetooth_0.64.3.pdf > > > > > > > It is close enough. > > Thanks for the pointer.  Noted. > > It is about Bluetooth.  Should be submitted to Bluetooth SIG. > > I might stay something stupid here again... si I wont say it :-) > > >> I would not oppose if that Authentication MEssage had a > >> specification in clear. > > > > The above plus Adam's draft will get you there. > > > >> > >>> These messages are broadcasted as Adam mentioned in his 'flying > >>> DRIP' comments at the beginning. > >> > >> Thank you for the reminder.  I looked again at the 'flying DRIP' > >> presentation during the WG meeting, and at the related draft. > >> > https://datatracker.ietf.org/meeting/108/materials/slides-108-drip-authentication-formats > >> > >> > >> > >> and draft-wiethuechter-drip-auth-01 > >> > >> During the presentation, the slide clearly shows on slide 8 that a > >> Bluetooth header immediately precedes an Open Drone ID message. > >> There is no IP header in that slide. > > > > That is right.  No IP.  No room for it.  No justification for it. It > > is all RLOS only. > > I might say something stupid here: no IP?  No IETF. > > >> In the draft, there is similar discussion tightly related to > >> Bluetooth and without IP. > >> > >> But if we are to have an independence of Bluetooth, and use a > >> networking layer such as IP, then the question of the use of an > >> authentication header is made differently. > > > > Again what is the justification for adding IP multicast? > > I would not be afraid of IP multicast like the multicast we know for > video delivery.  It is IP multicast because IP is IPv6 and IPv6 has no > broadcast. > > _If_ there is agreement that DRIP should be with IP (Internet Protocol). > > We know that the drone identification should be broadcasted (like in TV > broadcast).  In IPv4 there is a mechanism to implement such TV-broadcast > concept.  It is called IPv4 broadcast.  That broadcast is sent to a > dedicated address (like 255.255.255.255 which is all Internet, or like > 195.212.142.255 which is all computers in a particular subnet).  In IPv6 > such broadcast concept does not exist.  Rather, it's called 'multicast' > and, as opposed to IPv4, it has a mandatory and voluntary join/leave > mechanism. > > I name that IPv6 multicast simply IP multicast, because IPv4 should not > be used as basis for any new work at IETF. > > On such an IP multicast perspective for DRIP, one would have to come up > with an architecture for joining and leaving that makes it easy to use > by authorities, mandatory to implement, is secure enough (security and > multicast is not that easy), etc. > > > Where do you see these messages going beyond the RF Line Of Sight? > > True. > > But one would not want all BT5 devices (like my watch or earphones) > around a drone's sight to be awaken by its identification beacons, > right?  Only those devices who have voluntarily subscribed to that > multicast group would be awaken. > > > >> The authentication header would be an IP Authentication Header. > >> This AH would be somehow re-used and extended where necessary for > >> DRIP purposes. > >> > >>> Now later I expect us to move on to Network Remote ID and Command > >>> and Control (C2). > >>> > >>> Most C2 (e.g. Mavlink) is directly over the MAC, but there is a > >>> method to run it over UDP (I forget the UDP port commonly > >>> used...). AX Enterprize has done this using HIP so the UA starts > >>> with WiFi over the launch point, transitions to LTE, and on > >>> return back to WiFi. > >>> > >>> Network Remote ID can work either directly from the UA, or via > >>> C2 information to the GCS, from the GCS.  In either case, IP is > >>> assumed. This will probably be done via UDP.  From the UA, > >>> mobility will be important; from the GCS nice to have (most GCS > >>> will be stable location).  As UDP to a fixed Net-SP, DTLS 1.3 is > >>> a viable alternative to HIP. > >> > >> I will have to look closer at HIP again :-) and see how it could > >> be made to work with DRIP and IP. > > > > Stu, Adam, Andrei, and I see HIP for where there is pairwise > > communication with potentially both ends mobile and using multiple > > interfaces.  Once you have that use case, be consistent and use it > > for simpler situations. > > I wanted to ask whether using a Host Identity that is cryptographically > generated is sufficient for authorities to trust a drone upon reception > of one DRIP identification packet, or maybe am additional roundrip (a > ping, a request-response) would still be needed from ground officer to > drone to make sure it's the right drone who replies?  Or maybe a full > Diffie-Hellman exchange is needed? > > Alex > > > > >> > >> Alex > >> > >>> > >>> > >>> > >>> > >>>> > >>>> Alex > >>>> > >>>> as > >>>>> it is specified in ASTM F3411, which most of the regulators > >>>>> are dubbing as an approved technical means of regulatory > >>>>> compliance. > >>>>> > >>>>> AFAIK, no one runs IP over ADS-B, which was designed as a > >>>>> narrowband application specific communications stovepipe, > >>>>> not a data link supporting higher layer network protocols, > >>>>> so not great for IP. > >>>>> > >>>>> More importantly, we have no "reluctance about the use of... > >>>>>  IP", which is an entirely separate issue from ADS-B. > >>>>> > >>>>> On 8/4/2020 9:52 AM, Alexandre Petrescu wrote: > >>>>>> architectural layers discussion... > >>>>>> > >>>>>> Le 30/07/2020 à 11:49, shuaiizhao(Shuai Zhao) a écrit : > >>>>>>> Just to echo Stu on the ADSB, AFAIK, ADSB will  not be > >>>>>>> feasible for most of the drones mostly due to SwaP, > >>>>>>> commercial drones might be exception. > >>>>>> > >>>>>> It might be that ADS-B might be forbidden in drones on > >>>>>> Earth, but how about the drones on Mars? ('NASA Mars > >>>>>> helicopters', or ESA too).  On Mars there would be much > >>>>>> less such drones, so less risk of interference. > >>>>>> > >>>>>> With such a system (ADS-B under IP) one could re-use DTN > >>>>>> (Delay Tolerant Networking) between planets, and so > >>>>>> identify drones even on Mars. > >>>>>> > >>>>>> But if we have reluctance about the use of ADS-B, and thus > >>>>>> of IP, and we recommend Bluetooth-without-IP to identify > >>>>>> drones, then we might become too dependent on it? > >>>>>> > >>>>>> (do not get me wrong, I do like Bluetooth, but I like many > >>>>>> other things together with Bluetooth). > >>>>>> > >>>>>> Alex > >>>>>> > >>>>>>> > >>>>>>> Best, > >>>>>>> > >>>>>>> Shuai Zhao > >>>>>>> > >>>>>>> *From: *Tm-rid > on behalf of > >>>>>>> "Stuart W. Card" > *Date: > >>>>>>> *Wednesday, July 29, 2020 at 19:46 *To: > >>>>>>> *"tm-rid@ietf.org " > > *Subject: *[Drip] > >>>>>>> ADSB (was: Review of draft-drip-arch-02 w.r.t. RFC6973, > >>>>>>> RFC8280 and other)(Internet mail) > >>>>>>> > >>>>>>> Sorry for the slow reply. > >>>>>>> > >>>>>>> ADS-B is gradually being mandated for essentially all > >>>>>>> manned aircraft. > >>>>>>> > >>>>>>> ADSB-In and ADSB-Out are mandated for airliners: -In > >>>>>>> gives their pilots > >>>>>>> > >>>>>>> some Situational Awareness (SA) of other aircraft; -Out > >>>>>>> gives other > >>>>>>> > >>>>>>> pilots SA of the airliners. > >>>>>>> > >>>>>>> "ADSB-Out" is mandated even for small general aviation > >>>>>>> aircraft: it does > >>>>>>> > >>>>>>> not directly benefit the pilots of those aircraft; but > >>>>>>> by providing SA > >>>>>>> > >>>>>>> to others, it indirectly benefits all. > >>>>>>> > >>>>>>> ADSB is _not_ going to be deployed on large numbers of > >>>>>>> small UAS as it > >>>>>>> > >>>>>>> would overwhelm the limited bandwidth available at those > >>>>>>> lower radio > >>>>>>> > >>>>>>> frequencies (which propagate long ranges). In fact, it > >>>>>>> is expected to be > >>>>>>> > >>>>>>> explicitly prohibited in the US per the FAA NPRM; I > >>>>>>> suspect most of the > >>>>>>> > >>>>>>> rest of the world will do likewise. > >>>>>>> > >>>>>>> ADSB is also altogether insecure. > >>>>>>> > >>>>>>> On 7/9/2020 3:02 AM, Alexandre Petrescu wrote: > >>>>>>> > >>>>>>> ... > >>>>>>> > >>>>>>> They call it "ADS-B Receivers" (Automatic Dependent > >>>>>>> Surveillance - > >>>>>>> > >>>>>>> Broadcast). > >>>>>>> > >>>>>>> I wouuld like to ask if there is a packet dump available > >>>>>>> showing such > >>>>>>> > >>>>>>> presence data form planes?  Maybe wireshark already > >>>>>>> supports it, maybe > >>>>>>> > >>>>>>> it even dissects it... > >>>>>>> > >>>>>>> -- > >>>>>>> > >>>>>>> ----------------------------------------- > >>>>>>> > >>>>>>> Stuart W. Card, PhD, Principal Engineer > >>>>>>> > >>>>>>> AX Enterprize, LLC www.axenterprize.com > > >>>>>>> > >>>>>>> 4947 Commercial Drive, Yorkville NY 13495 > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>> > >>> -- 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 > > > > -- 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 > > -- > Tm-rid mailing list > Tm-rid@ietf.org > https://www.ietf.org/mailman/listinfo/tm-rid > From nobody Wed Aug 5 07:26:40 2020 Return-Path: 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 3F02E3A09FB for ; Wed, 5 Aug 2020 07:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, 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 X5NdkW88uveC for ; Wed, 5 Aug 2020 07:26:37 -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 C669C3A09D9 for ; Wed, 5 Aug 2020 07:26:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 077AE62422; Wed, 5 Aug 2020 10:26:35 -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 yxdlg2uhGkmE; Wed, 5 Aug 2020 10:26:13 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (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 C563A62416; Wed, 5 Aug 2020 10:26:12 -0400 (EDT) To: Alexandre Petrescu , "Card, Stu" Cc: tm-rid@ietf.org References: <1bebf5b1-1fa5-6902-5bb7-9ec3582e6d9a@andersdotter.cc> <3c632ce9-115d-11f5-ee33-bfabd4973522@labs.htt-consult.com> <7ddd9a2f-23ba-dd82-8cfb-1d2974969e67@gmail.com> <61511ef6-5b9b-5b62-f922-d32b994a35b9@gmail.com> <2e1cbffc-8554-222b-d558-43e048194104@gmail.com> From: Robert Moskowitz Message-ID: <83f3e6e3-dab6-211d-aa69-c4e43fb59e8f@labs.htt-consult.com> Date: Wed, 5 Aug 2020 10:26:04 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <2e1cbffc-8554-222b-d558-43e048194104@gmail.com> Content-Type: multipart/alternative; boundary="------------3CB62F4F260D2A5D5E072EEA" Content-Language: en-US Archived-At: Subject: Re: [Drip] ADSB X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 14:26:40 -0000 This is a multi-part message in MIME format. --------------3CB62F4F260D2A5D5E072EEA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 8/5/20 10:23 AM, Alexandre Petrescu wrote: > > > Le 05/08/2020 à 15:50, Card, Stu a écrit : >> Again, a single point response. The reason this work is appropriate >> for IETF rather than the Bluetooth SIG is that ASTM F3411 specifies >> Bluetooth _only_ as one transport for Broadcast RID (WiFi NaN is also >> specified and other alternatives could be added later, as you, Bob >> and others are discussing, also consider RTCA SC-228 DO-362 UAS C2 >> Data Link at ~1 and ~5 GHz), but there is also Network RID where ASTM >> F3411 specifies use of the Internet, and a lot more to the overall >> UAS RID architecture/problem than just the initial streaming of >> messages from the UAS. >> >> Please look at the openly published early draft of ASTM F3411 to >> which Bob pointed you, > > I looked and I will keep it aside for reference when needed. > > It's an Intel document. > > https://github.com/opendroneid/specs/blob/master/OpenDroneID_Bluetooth_0.64.3.pdf > yes, Intel got ASTM's approval to do the OpenDrone ID work for PoC. So there is code there for implementing this on github.  Adam used that as his starting point. > > Alex > >  and perhaps some of the other external docs cited in >> the DRIP requirements draft, for essential context on the UAS RID >> problem and what others have already done to address it, which we >> hope to complement (not replace) with DRIP. Thanks! >> >> >> On Wed, Aug 5, 2020 at 8:50 AM Alexandre Petrescu >> > >> wrote: >> >> >> >>     Le 05/08/2020 à 13:53, Robert Moskowitz a écrit : >>      > >>      > >>      > On 8/5/20 6:11 AM, Alexandre Petrescu wrote: >>      >> >>      >> >>      >> Le 04/08/2020 à 17:51, Robert Moskowitz a écrit : >>      >>> >>      >>> >>      >>> On 8/4/20 11:27 AM, Alexandre Petrescu wrote: >>      >>>> Thanks for the clarification. >>      >>>> >>      >>>> Le 04/08/2020 à 17:17, Stuart W. Card a écrit : >>      >>>>> I just want to respond to one line that I think comes from >>      >>>>> confusion: >>      >>>>> >>      >>>>>> But if we have reluctance about the use of ADS-B, and thus >>      >>>>>> of IP, and we recommend Bluetooth-without-IP to identify >>      >>>>>> drones >>      >>>>> >>      >>>>> We aren't recommending Bluetooth-without-IP, we are >>      >>>>> _supporting_ it, >>      >>>> >>      >>>> But, the security manifest that I have seen on slides during >>      >>>> the presentation of the DRIP WG meeting - is something below >>      >>>> IP, right? >>      >>> >>      >>> For now, we are dealing with broadcast messages.  Either over >>      >>> Bluetooth or WiFI (NAN). >>      >> >>      >> If it is a broadcast message and it is over Bluetooth or over >> WiFi >>      >> then it certainly is IP multicast, cant be anything else. >>      > >>      > Wrong for BT4.  There are only 25 bytes available.  We can do >> most >>      > of the messaging in a single frame.  To do anything with IP will >>      > force this to a multiframe design. >> >>     I might say something stupid if I am allowed, maybe things that are >>     already known.  Sorry, I did not check the BoF archive >> discussion.  But >>     here goes anyways.  If one wants to do something with Bluetooth4 >> below >>     IP and finds it to be too small packets, then there could be several >>     possibilities: >>     - do it at Bluetooth SIG instead of IETF; >>     - do it in 6lo WG; >>     - use a header compression scheme at IETF (6lowpan HC at 6lo WG, >> SCHC at >>         LP-WAN WG, ROHC and why not CBOR); >>     - implement packet fragmentation and reassembly and multiframe >> design >>         below IP; >>     - use the already available data in the 25 bytes in order to realize >>         that identification (there must be MAC addresses in there, and >>     they're >>         likely to be useful). >> >>      > Even BT5 it is wrong for the Authentication Message. We need the >>      > full frame for our content.  We would have to go with multiframe >>      > design for BT5 as a result. >> >>     So, I do not understand: does DRIP want the entire packet to stay of >>     size 25bytes?  Or does DRIP want the packet to be more than 25bytes? >> >>     Would a multiframe design in which an IP packet of length >> 1280bytes is >>     chopped into 25bytes BT5 packets be advantageous for DRIP? >> >>     Do the BT5 packets have a notion of interlinking between sub-packets >>     that make a bigger packet?  (such a mechanism exists at the IP >> layer; it >>     uses Identification to identify a chain and an Offset to say >> where in >>     the chain is that sub-packet to be found). >> >>      > So this leaves WiFi NAN.  Sure you can do it, but why?  What >> does it >>      > add?  In My Not So Humble Opinion (IMNSOHO) nothing but cost and >>      > processing overhead. >> >>     I think WiFi 5.4 GHz is already used extensively to remotely control >>     drones.  These consoles with joysticks are WiFi 5.4GHz, if I am not >>     mistaken. >> >>      >> If it is IP multicast over Bluetooth or over WiFi then I wonder >>      >> what is the value  in the Next Header field of the IP header >>      >> format (RFC8200 "IPv6", section 3 "Header format").  Basically - >>      >> what is the payload? >>      >> >>      >> If one asks me, I would dare to think that payload might be an >>      >> ICMPv6 Router Advertisement. >>      >> >>      >>> There is NO security for the messages below the message >> package. >>      >> >>      >> Noted. >>      >> >>      >>> Just not enough payload size for anything that would work in a >>      >>> broadcast environment like a National Airspace.  All of the >>      >>> security we are specifying is inside the messages where >>      >>> appropriate. >>      >>> >>      >>> That security manifest is a payload of the ASTM F3411-19 >>      >>> Authentication Message. >>      >> >>      >> It costs 85USD I wont pay to see it.  It is security.  There >> will >>      >> always be someone smarter to break that security and ask for >> more >>      >> money. >>      > >>      > Look at: >>      > >>      > >> https://github.com/opendroneid/specs/blob/master/OpenDroneID_Bluetooth_0.64.3.pdf >>      > >>      > >>      > >>     It is close enough. >> >>     Thanks for the pointer.  Noted. >> >>     It is about Bluetooth.  Should be submitted to Bluetooth SIG. >> >>     I might stay something stupid here again... si I wont say it :-) >> >>      >> I would not oppose if that Authentication MEssage had a >>      >> specification in clear. >>      > >>      > The above plus Adam's draft will get you there. >>      > >>      >> >>      >>> These messages are broadcasted as Adam mentioned in his 'flying >>      >>> DRIP' comments at the beginning. >>      >> >>      >> Thank you for the reminder.  I looked again at the 'flying DRIP' >>      >> presentation during the WG meeting, and at the related draft. >>      >> >> https://datatracker.ietf.org/meeting/108/materials/slides-108-drip-authentication-formats >>      >> >>      >> >>      >> >>      >> and draft-wiethuechter-drip-auth-01 >>      >> >>      >> During the presentation, the slide clearly shows on slide 8 >> that a >>      >> Bluetooth header immediately precedes an Open Drone ID message. >>      >> There is no IP header in that slide. >>      > >>      > That is right.  No IP.  No room for it.  No justification for >> it. It >>      > is all RLOS only. >> >>     I might say something stupid here: no IP?  No IETF. >> >>      >> In the draft, there is similar discussion tightly related to >>      >> Bluetooth and without IP. >>      >> >>      >> But if we are to have an independence of Bluetooth, and use a >>      >> networking layer such as IP, then the question of the use of an >>      >> authentication header is made differently. >>      > >>      > Again what is the justification for adding IP multicast? >> >>     I would not be afraid of IP multicast like the multicast we know for >>     video delivery.  It is IP multicast because IP is IPv6 and IPv6 >> has no >>     broadcast. >> >>     _If_ there is agreement that DRIP should be with IP (Internet >> Protocol). >> >>     We know that the drone identification should be broadcasted (like >> in TV >>     broadcast).  In IPv4 there is a mechanism to implement such >> TV-broadcast >>     concept.  It is called IPv4 broadcast.  That broadcast is sent to a >>     dedicated address (like 255.255.255.255 which is all Internet, or >> like >>     195.212.142.255 which is all computers in a particular subnet).  >> In IPv6 >>     such broadcast concept does not exist.  Rather, it's called >> 'multicast' >>     and, as opposed to IPv4, it has a mandatory and voluntary join/leave >>     mechanism. >> >>     I name that IPv6 multicast simply IP multicast, because IPv4 >> should not >>     be used as basis for any new work at IETF. >> >>     On such an IP multicast perspective for DRIP, one would have to >> come up >>     with an architecture for joining and leaving that makes it easy >> to use >>     by authorities, mandatory to implement, is secure enough >> (security and >>     multicast is not that easy), etc. >> >>      > Where do you see these messages going beyond the RF Line Of >> Sight? >> >>     True. >> >>     But one would not want all BT5 devices (like my watch or earphones) >>     around a drone's sight to be awaken by its identification beacons, >>     right?  Only those devices who have voluntarily subscribed to that >>     multicast group would be awaken. >> >> >>      >> The authentication header would be an IP Authentication Header. >>      >> This AH would be somehow re-used and extended where necessary >> for >>      >> DRIP purposes. >>      >> >>      >>> Now later I expect us to move on to Network Remote ID and >> Command >>      >>> and Control (C2). >>      >>> >>      >>> Most C2 (e.g. Mavlink) is directly over the MAC, but there is a >>      >>> method to run it over UDP (I forget the UDP port commonly >>      >>> used...). AX Enterprize has done this using HIP so the UA >> starts >>      >>> with WiFi over the launch point, transitions to LTE, and on >>      >>> return back to WiFi. >>      >>> >>      >>> Network Remote ID can work either directly from the UA, or via >>      >>> C2 information to the GCS, from the GCS.  In either case, IP is >>      >>> assumed. This will probably be done via UDP. From the UA, >>      >>> mobility will be important; from the GCS nice to have (most GCS >>      >>> will be stable location).  As UDP to a fixed Net-SP, DTLS >> 1.3 is >>      >>> a viable alternative to HIP. >>      >> >>      >> I will have to look closer at HIP again :-) and see how it could >>      >> be made to work with DRIP and IP. >>      > >>      > Stu, Adam, Andrei, and I see HIP for where there is pairwise >>      > communication with potentially both ends mobile and using >> multiple >>      > interfaces.  Once you have that use case, be consistent and >> use it >>      > for simpler situations. >> >>     I wanted to ask whether using a Host Identity that is >> cryptographically >>     generated is sufficient for authorities to trust a drone upon >> reception >>     of one DRIP identification packet, or maybe am additional >> roundrip (a >>     ping, a request-response) would still be needed from ground >> officer to >>     drone to make sure it's the right drone who replies?  Or maybe a >> full >>     Diffie-Hellman exchange is needed? >> >>     Alex >> >>      > >>      >> >>      >> Alex >>      >> >>      >>> >>      >>> >>      >>> >>      >>> >>      >>>> >>      >>>> Alex >>      >>>> >>      >>>> as >>      >>>>> it is specified in ASTM F3411, which most of the regulators >>      >>>>> are dubbing as an approved technical means of regulatory >>      >>>>> compliance. >>      >>>>> >>      >>>>> AFAIK, no one runs IP over ADS-B, which was designed as a >>      >>>>> narrowband application specific communications stovepipe, >>      >>>>> not a data link supporting higher layer network protocols, >>      >>>>> so not great for IP. >>      >>>>> >>      >>>>> More importantly, we have no "reluctance about the use of... >>      >>>>>  IP", which is an entirely separate issue from ADS-B. >>      >>>>> >>      >>>>> On 8/4/2020 9:52 AM, Alexandre Petrescu wrote: >>      >>>>>> architectural layers discussion... >>      >>>>>> >>      >>>>>> Le 30/07/2020 à 11:49, shuaiizhao(Shuai Zhao) a écrit : >>      >>>>>>> Just to echo Stu on the ADSB, AFAIK, ADSB will  not be >>      >>>>>>> feasible for most of the drones mostly due to SwaP, >>      >>>>>>> commercial drones might be exception. >>      >>>>>> >>      >>>>>> It might be that ADS-B might be forbidden in drones on >>      >>>>>> Earth, but how about the drones on Mars? ('NASA Mars >>      >>>>>> helicopters', or ESA too).  On Mars there would be much >>      >>>>>> less such drones, so less risk of interference. >>      >>>>>> >>      >>>>>> With such a system (ADS-B under IP) one could re-use DTN >>      >>>>>> (Delay Tolerant Networking) between planets, and so >>      >>>>>> identify drones even on Mars. >>      >>>>>> >>      >>>>>> But if we have reluctance about the use of ADS-B, and thus >>      >>>>>> of IP, and we recommend Bluetooth-without-IP to identify >>      >>>>>> drones, then we might become too dependent on it? >>      >>>>>> >>      >>>>>> (do not get me wrong, I do like Bluetooth, but I like many >>      >>>>>> other things together with Bluetooth). >>      >>>>>> >>      >>>>>> Alex >>      >>>>>> >>      >>>>>>> >>      >>>>>>> Best, >>      >>>>>>> >>      >>>>>>> Shuai Zhao >>      >>>>>>> >>      >>>>>>> *From: *Tm-rid >     > on behalf of >>      >>>>>>> "Stuart W. Card" >     > *Date: >>      >>>>>>> *Wednesday, July 29, 2020 at 19:46 *To: >>      >>>>>>> *"tm-rid@ietf.org " >>     > *Subject: *[Drip] >>      >>>>>>> ADSB (was: Review of draft-drip-arch-02 w.r.t. RFC6973, >>      >>>>>>> RFC8280 and other)(Internet mail) >>      >>>>>>> >>      >>>>>>> Sorry for the slow reply. >>      >>>>>>> >>      >>>>>>> ADS-B is gradually being mandated for essentially all >>      >>>>>>> manned aircraft. >>      >>>>>>> >>      >>>>>>> ADSB-In and ADSB-Out are mandated for airliners: -In >>      >>>>>>> gives their pilots >>      >>>>>>> >>      >>>>>>> some Situational Awareness (SA) of other aircraft; -Out >>      >>>>>>> gives other >>      >>>>>>> >>      >>>>>>> pilots SA of the airliners. >>      >>>>>>> >>      >>>>>>> "ADSB-Out" is mandated even for small general aviation >>      >>>>>>> aircraft: it does >>      >>>>>>> >>      >>>>>>> not directly benefit the pilots of those aircraft; but >>      >>>>>>> by providing SA >>      >>>>>>> >>      >>>>>>> to others, it indirectly benefits all. >>      >>>>>>> >>      >>>>>>> ADSB is _not_ going to be deployed on large numbers of >>      >>>>>>> small UAS as it >>      >>>>>>> >>      >>>>>>> would overwhelm the limited bandwidth available at those >>      >>>>>>> lower radio >>      >>>>>>> >>      >>>>>>> frequencies (which propagate long ranges). In fact, it >>      >>>>>>> is expected to be >>      >>>>>>> >>      >>>>>>> explicitly prohibited in the US per the FAA NPRM; I >>      >>>>>>> suspect most of the >>      >>>>>>> >>      >>>>>>> rest of the world will do likewise. >>      >>>>>>> >>      >>>>>>> ADSB is also altogether insecure. >>      >>>>>>> >>      >>>>>>> On 7/9/2020 3:02 AM, Alexandre Petrescu wrote: >>      >>>>>>> >>      >>>>>>> ... >>      >>>>>>> >>      >>>>>>> They call it "ADS-B Receivers" (Automatic Dependent >>      >>>>>>> Surveillance - >>      >>>>>>> >>      >>>>>>> Broadcast). >>      >>>>>>> >>      >>>>>>> I wouuld like to ask if there is a packet dump available >>      >>>>>>> showing such >>      >>>>>>> >>      >>>>>>> presence data form planes? Maybe wireshark already >>      >>>>>>> supports it, maybe >>      >>>>>>> >>      >>>>>>> it even dissects it... >>      >>>>>>> >>      >>>>>>> -- >>      >>>>>>> >>      >>>>>>> ----------------------------------------- >>      >>>>>>> >>      >>>>>>> Stuart W. Card, PhD, Principal Engineer >>      >>>>>>> >>      >>>>>>> AX Enterprize, LLC www.axenterprize.com >>     >>      >>>>>>> >>      >>>>>>> 4947 Commercial Drive, Yorkville NY 13495 >>      >>>>>>> >>      >>>>>>> >>      >>>>>> >>      >>>>> >>      >>>>> >>      >>>>> >>      >>>> >>      >>> >>      >>> -- 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 >>      > >>      > -- 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 >> >>     --     Tm-rid mailing list >>     Tm-rid@ietf.org >>     https://www.ietf.org/mailman/listinfo/tm-rid >> > -- 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 --------------3CB62F4F260D2A5D5E072EEA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 8/5/20 10:23 AM, Alexandre Petrescu wrote:


Le 05/08/2020 à 15:50, Card, Stu a écrit :
Again, a single point response. The reason this work is appropriate for IETF rather than the Bluetooth SIG is that ASTM F3411 specifies Bluetooth _only_ as one transport for Broadcast RID (WiFi NaN is also specified and other alternatives could be added later, as you, Bob and others are discussing, also consider RTCA SC-228 DO-362 UAS C2 Data Link at ~1 and ~5 GHz), but there is also Network RID where ASTM F3411 specifies use of the Internet, and a lot more to the overall UAS RID architecture/problem than just the initial streaming of messages from the UAS.

Please look at the openly published early draft of ASTM F3411 to which Bob pointed you,

I looked and I will keep it aside for reference when needed.

It's an Intel document.

https://github.com/opendroneid/specs/blob/master/OpenDroneID_Bluetooth_0.64.3.pdf

yes, Intel got ASTM's approval to do the OpenDrone ID work for PoC.  So there is code there for implementing this on github.  Adam used that as his starting point.


Alex

 and perhaps some of the other external docs cited in
the DRIP requirements draft, for  essential context on the UAS RID problem and what others have already done to address it, which we hope to complement (not replace) with DRIP. Thanks!


On Wed, Aug 5, 2020 at 8:50 AM Alexandre Petrescu <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>> wrote:



    Le 05/08/2020 à 13:53, Robert Moskowitz a écrit :
     >
     >
     > On 8/5/20 6:11 AM, Alexandre Petrescu wrote:
     >>
     >>
     >> Le 04/08/2020 à 17:51, Robert Moskowitz a écrit :
     >>>
     >>>
     >>> On 8/4/20 11:27 AM, Alexandre Petrescu wrote:
     >>>> Thanks for the clarification.
     >>>>
     >>>> Le 04/08/2020 à 17:17, Stuart W. Card a écrit :
     >>>>> I just want to respond to one line that I think comes from
     >>>>> confusion:
     >>>>>
     >>>>>> But if we have reluctance about the use of ADS-B, and thus
     >>>>>> of IP, and we recommend Bluetooth-without-IP to identify
     >>>>>> drones
     >>>>>
     >>>>> We aren't recommending Bluetooth-without-IP, we are
     >>>>> _supporting_ it,
     >>>>
     >>>> But, the security manifest that I have seen on slides during
     >>>> the presentation of the DRIP WG meeting - is something below
     >>>> IP, right?
     >>>
     >>> For now, we are dealing with broadcast messages.  Either over
     >>> Bluetooth or WiFI (NAN).
     >>
     >> If it is a broadcast message and it is over Bluetooth or over WiFi
     >> then it certainly is IP multicast, cant be anything else.
     >
     > Wrong for BT4.  There are only 25 bytes available.  We can do most
     > of the messaging in a single frame.  To do anything with IP will
     > force this to a multiframe design.

    I might say something stupid if I am allowed, maybe things that are
    already known.  Sorry, I did not check the BoF archive discussion.  But
    here goes anyways.  If one wants to do something with Bluetooth4 below
    IP and finds it to be too small packets, then there could be several
    possibilities:
    - do it at Bluetooth SIG instead of IETF;
    - do it in 6lo WG;
    - use a header compression scheme at IETF (6lowpan HC at 6lo WG, SCHC at
        LP-WAN WG, ROHC and why not CBOR);
    - implement packet fragmentation and reassembly and multiframe design
        below IP;
    - use the already available data in the 25 bytes in order to realize
        that identification (there must be MAC addresses in there, and
    they're
        likely to be useful).

     > Even BT5 it is wrong for the Authentication Message.  We need the
     > full frame for our content.  We would have to go with multiframe
     > design for BT5 as a result.

    So, I do not understand: does DRIP want the entire packet to stay of
    size 25bytes?  Or does DRIP want the packet to be more than 25bytes?

    Would a multiframe design in which an IP packet of length 1280bytes is
    chopped into 25bytes BT5 packets be advantageous for DRIP?

    Do the BT5 packets have a notion of interlinking between sub-packets
    that make a bigger packet?  (such a mechanism exists at the IP layer; it
    uses Identification to identify a chain and an Offset to say where in
    the chain is that sub-packet to be found).

     > So this leaves WiFi NAN.  Sure you can do it, but why?  What does it
     > add?  In My Not So Humble Opinion (IMNSOHO) nothing but cost and
     > processing overhead.

    I think WiFi 5.4 GHz is already used extensively to remotely control
    drones.  These consoles with joysticks are WiFi 5.4GHz, if I am not
    mistaken.

     >> If it is IP multicast over Bluetooth or over WiFi then I wonder
     >> what is the value  in the Next Header field of the IP header
     >> format (RFC8200 "IPv6", section 3 "Header format").  Basically -
     >> what is the payload?
     >>
     >> If one asks me, I would dare to think that payload might be an
     >> ICMPv6 Router Advertisement.
     >>
     >>> There is NO security for the messages below the message package.
     >>
     >> Noted.
     >>
     >>> Just not enough payload size for anything that would work in a
     >>> broadcast environment like a National Airspace.  All of the
     >>> security we are specifying is inside the messages where
     >>> appropriate.
     >>>
     >>> That security manifest is a payload of the ASTM F3411-19
     >>> Authentication Message.
     >>
     >> It costs 85USD I wont pay to see it.  It is security.  There will
     >> always be someone smarter to break that security and ask for more
     >> money.
     >
     > Look at:
     >
     >
    https://github.com/opendroneid/specs/blob/master/OpenDroneID_Bluetooth_0.64.3.pdf
     >
     >
     >
    It is close enough.

    Thanks for the pointer.  Noted.

    It is about Bluetooth.  Should be submitted to Bluetooth SIG.

    I might stay something stupid here again... si I wont say it :-)

     >> I would not oppose if that Authentication MEssage had a
     >> specification in clear.
     >
     > The above plus Adam's draft will get you there.
     >
     >>
     >>> These messages are broadcasted as Adam mentioned in his 'flying
     >>> DRIP' comments at the beginning.
     >>
     >> Thank you for the reminder.  I looked again at the 'flying DRIP'
     >> presentation during the WG meeting, and at the related draft.
     >>
    https://datatracker.ietf.org/meeting/108/materials/slides-108-drip-authentication-formats
     >>
     >>
     >>
     >> and draft-wiethuechter-drip-auth-01
     >>
     >> During the presentation, the slide clearly shows on slide 8 that a
     >> Bluetooth header immediately precedes an Open Drone ID message.
     >> There is no IP header in that slide.
     >
     > That is right.  No IP.  No room for it.  No justification for it. It
     > is all RLOS only.

    I might say something stupid here: no IP?  No IETF.

     >> In the draft, there is similar discussion tightly related to
     >> Bluetooth and without IP.
     >>
     >> But if we are to have an independence of Bluetooth, and use a
     >> networking layer such as IP, then the question of the use of an
     >> authentication header is made differently.
     >
     > Again what is the justification for adding IP multicast?

    I would not be afraid of IP multicast like the multicast we know for
    video delivery.  It is IP multicast because IP is IPv6 and IPv6 has no
    broadcast.

    _If_ there is agreement that DRIP should be with IP (Internet Protocol).

    We know that the drone identification should be broadcasted (like in TV
    broadcast).  In IPv4 there is a mechanism to implement such TV-broadcast
    concept.  It is called IPv4 broadcast.  That broadcast is sent to a
    dedicated address (like 255.255.255.255 which is all Internet, or like
    195.212.142.255 which is all computers in a particular subnet).  In IPv6
    such broadcast concept does not exist.  Rather, it's called 'multicast'
    and, as opposed to IPv4, it has a mandatory and voluntary join/leave
    mechanism.

    I name that IPv6 multicast simply IP multicast, because IPv4 should not
    be used as basis for any new work at IETF.

    On such an IP multicast perspective for DRIP, one would have to come up
    with an architecture for joining and leaving that makes it easy to use
    by authorities, mandatory to implement, is secure enough (security and
    multicast is not that easy), etc.

     > Where do you see these messages going beyond the RF Line Of Sight?

    True.

    But one would not want all BT5 devices (like my watch or earphones)
    around a drone's sight to be awaken by its identification beacons,
    right?  Only those devices who have voluntarily subscribed to that
    multicast group would be awaken.


     >> The authentication header would be an IP Authentication Header.
     >> This AH would be somehow re-used and extended where necessary for
     >> DRIP purposes.
     >>
     >>> Now later I expect us to move on to Network Remote ID and Command
     >>> and Control (C2).
     >>>
     >>> Most C2 (e.g. Mavlink) is directly over the MAC, but there is a
     >>> method to run it over UDP (I forget the UDP port commonly
     >>> used...). AX Enterprize has done this using HIP so the UA starts
     >>> with WiFi over the launch point, transitions to LTE, and on
     >>> return back to WiFi.
     >>>
     >>> Network Remote ID can work either directly from the UA, or via
     >>> C2 information to the GCS, from the GCS.  In either case, IP is
     >>> assumed. This will probably be done via UDP.  From the UA,
     >>> mobility will be important; from the GCS nice to have (most GCS
     >>> will be stable location).  As UDP to a fixed Net-SP, DTLS 1.3 is
     >>> a viable alternative to HIP.
     >>
     >> I will have to look closer at HIP again :-) and see how it could
     >> be made to work with DRIP and IP.
     >
     > Stu, Adam, Andrei, and I see HIP for where there is pairwise
     > communication with potentially both ends mobile and using multiple
     > interfaces.  Once you have that use case, be consistent and use it
     > for simpler situations.

    I wanted to ask whether using a Host Identity that is cryptographically
    generated is sufficient for authorities to trust a drone upon reception
    of one DRIP identification packet, or maybe am additional roundrip (a
    ping, a request-response) would still be needed from ground officer to
    drone to make sure it's the right drone who replies?  Or maybe a full
    Diffie-Hellman exchange is needed?

    Alex

     >
     >>
     >> Alex
     >>
     >>>
     >>>
     >>>
     >>>
     >>>>
     >>>> Alex
     >>>>
     >>>> as
     >>>>> it is specified in ASTM F3411, which most of the regulators
     >>>>> are dubbing as an approved technical means of regulatory
     >>>>> compliance.
     >>>>>
     >>>>> AFAIK, no one runs IP over ADS-B, which was designed as a
     >>>>> narrowband application specific communications stovepipe,
     >>>>> not a data link supporting higher layer network protocols,
     >>>>> so not great for IP.
     >>>>>
     >>>>> More importantly, we have no "reluctance about the use of...
     >>>>>  IP", which is an entirely separate issue from ADS-B.
     >>>>>
     >>>>> On 8/4/2020 9:52 AM, Alexandre Petrescu wrote:
     >>>>>> architectural layers discussion...
     >>>>>>
     >>>>>> Le 30/07/2020 à 11:49, shuaiizhao(Shuai Zhao) a écrit :
     >>>>>>> Just to echo Stu on the ADSB, AFAIK, ADSB will  not be
     >>>>>>> feasible for most of the drones mostly due to SwaP,
     >>>>>>> commercial drones might be exception.
     >>>>>>
     >>>>>> It might be that ADS-B might be forbidden in drones on
     >>>>>> Earth, but how about the drones on Mars? ('NASA Mars
     >>>>>> helicopters', or ESA too).  On Mars there would be much
     >>>>>> less such drones, so less risk of interference.
     >>>>>>
     >>>>>> With such a system (ADS-B under IP) one could re-use DTN
     >>>>>> (Delay Tolerant Networking) between planets, and so
     >>>>>> identify drones even on Mars.
     >>>>>>
     >>>>>> But if we have reluctance about the use of ADS-B, and thus
     >>>>>> of IP, and we recommend Bluetooth-without-IP to identify
     >>>>>> drones, then we might become too dependent on it?
     >>>>>>
     >>>>>> (do not get me wrong, I do like Bluetooth, but I like many
     >>>>>> other things together with Bluetooth).
     >>>>>>
     >>>>>> Alex
     >>>>>>
     >>>>>>>
     >>>>>>> Best,
     >>>>>>>
     >>>>>>> Shuai Zhao
     >>>>>>>
     >>>>>>> *From: *Tm-rid <tm-rid-bounces@ietf.org
    <mailto:tm-rid-bounces@ietf.org>> on behalf of
     >>>>>>> "Stuart W. Card" <stu.card@axenterprize.com
    <mailto:stu.card@axenterprize.com>> *Date:
     >>>>>>> *Wednesday, July 29, 2020 at 19:46 *To:
     >>>>>>> *"tm-rid@ietf.org <mailto:tm-rid@ietf.org>"
    <tm-rid@ietf.org <mailto:tm-rid@ietf.org>> *Subject: *[Drip]
     >>>>>>> ADSB (was: Review of draft-drip-arch-02 w.r.t. RFC6973,
     >>>>>>> RFC8280 and other)(Internet mail)
     >>>>>>>
     >>>>>>> Sorry for the slow reply.
     >>>>>>>
     >>>>>>> ADS-B is gradually being mandated for essentially all
     >>>>>>> manned aircraft.
     >>>>>>>
     >>>>>>> ADSB-In and ADSB-Out are mandated for airliners: -In
     >>>>>>> gives their pilots
     >>>>>>>
     >>>>>>> some Situational Awareness (SA) of other aircraft; -Out
     >>>>>>> gives other
     >>>>>>>
     >>>>>>> pilots SA of the airliners.
     >>>>>>>
     >>>>>>> "ADSB-Out" is mandated even for small general aviation
     >>>>>>> aircraft: it does
     >>>>>>>
     >>>>>>> not directly benefit the pilots of those aircraft; but
     >>>>>>> by providing SA
     >>>>>>>
     >>>>>>> to others, it indirectly benefits all.
     >>>>>>>
     >>>>>>> ADSB is _not_ going to be deployed on large numbers of
     >>>>>>> small UAS as it
     >>>>>>>
     >>>>>>> would overwhelm the limited bandwidth available at those
     >>>>>>> lower radio
     >>>>>>>
     >>>>>>> frequencies (which propagate long ranges). In fact, it
     >>>>>>> is expected to be
     >>>>>>>
     >>>>>>> explicitly prohibited in the US per the FAA NPRM; I
     >>>>>>> suspect most of the
     >>>>>>>
     >>>>>>> rest of the world will do likewise.
     >>>>>>>
     >>>>>>> ADSB is also altogether insecure.
     >>>>>>>
     >>>>>>> On 7/9/2020 3:02 AM, Alexandre Petrescu wrote:
     >>>>>>>
     >>>>>>> ...
     >>>>>>>
     >>>>>>> They call it "ADS-B Receivers" (Automatic Dependent
     >>>>>>> Surveillance -
     >>>>>>>
     >>>>>>> Broadcast).
     >>>>>>>
     >>>>>>> I wouuld like to ask if there is a packet dump available
     >>>>>>> showing such
     >>>>>>>
     >>>>>>> presence data form planes?  Maybe wireshark already
     >>>>>>> supports it, maybe
     >>>>>>>
     >>>>>>> it even dissects it...
     >>>>>>>
     >>>>>>> --
     >>>>>>>
     >>>>>>> -----------------------------------------
     >>>>>>>
     >>>>>>> Stuart W. Card, PhD, Principal Engineer
     >>>>>>>
     >>>>>>> AX Enterprize, LLC www.axenterprize.com
    <http://www.axenterprize.com>
     >>>>>>>
     >>>>>>> 4947 Commercial Drive, Yorkville NY 13495
     >>>>>>>
     >>>>>>>
     >>>>>>
     >>>>>
     >>>>>
     >>>>>
     >>>>
     >>>
     >>> -- Standard Robert Moskowitz Owner HTT Consulting C:248-219-2059
     >>> F:248-968-2824 E:rgm@labs.htt-consult.com
    <mailto:E%3Argm@labs.htt-consult.com>
     >>>
     >>> There's no limit to what can be accomplished if it doesn't matter
     >>> who gets the credit
     >
     > -- Standard Robert Moskowitz Owner HTT Consulting C:248-219-2059
     > F:248-968-2824 E:rgm@labs.htt-consult.com
    <mailto:E%3Argm@labs.htt-consult.com>
     >
     > There's no limit to what can be accomplished if it doesn't matter
     > who gets the credit

    --     Tm-rid mailing list
    Tm-rid@ietf.org <mailto:Tm-rid@ietf.org>
    https://www.ietf.org/mailman/listinfo/tm-rid



--
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
--------------3CB62F4F260D2A5D5E072EEA-- From nobody Wed Aug 5 07:31:05 2020 Return-Path: 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 7E6983A07E2 for ; Wed, 5 Aug 2020 07:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, 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 onrgLwf9NVhA for ; Wed, 5 Aug 2020 07:30:59 -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 3C09C3A090F for ; Wed, 5 Aug 2020 07:30:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 9ABAD62422; Wed, 5 Aug 2020 10:30:57 -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 TYwBLm7ip+iJ; Wed, 5 Aug 2020 10:30:40 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (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 E902962416; Wed, 5 Aug 2020 10:30:39 -0400 (EDT) To: Alexandre Petrescu , "Card, Stu" Cc: tm-rid@ietf.org References: <1bebf5b1-1fa5-6902-5bb7-9ec3582e6d9a@andersdotter.cc> <973223fd-0119-376d-12cd-21559a14ce87@labs.htt-consult.com> <3c632ce9-115d-11f5-ee33-bfabd4973522@labs.htt-consult.com> <7ddd9a2f-23ba-dd82-8cfb-1d2974969e67@gmail.com> <61511ef6-5b9b-5b62-f922-d32b994a35b9@gmail.com> From: Robert Moskowitz Message-ID: Date: Wed, 5 Aug 2020 10:30:36 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7006A62525E187E848FDF274" Content-Language: en-US Archived-At: Subject: Re: [Drip] ADSB X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 14:31:03 -0000 This is a multi-part message in MIME format. --------------7006A62525E187E848FDF274 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 8/5/20 10:22 AM, Alexandre Petrescu wrote: > Hi, > > Thank you for the reply. > > Le 05/08/2020 à 15:38, Card, Stu a écrit : >> Again, I wish to respond primarily to one line that again I believe >> results from some confusion. >> >>> If it is a broadcast message and it is over Bluetooth or over WiFi >>> then it certainly is IP multicast, cant be anything else. >> >> There is nothing preventing application layer protocols from being >> layered directly over link layer protocols. This is exactly what is >> typically done with Bluetooth, not only for UAS RID, but other >> applications as well. It can even be done with WiFi, Ethernet, etc., >>  although this is less commonly done. This certainly limits >> flexibility and internetworking. Again, however, this is not up to >> us: the regulators are citing ASTM F3411 for UAS RID; that standard >> defines how to put UAS RID application specific message formats >> directly into Bluetooth link layer frames, without any intervening >> headers (such as would be required for IP encapsulation of the app >> layer messages). While I think their specifying Bluetooth generally >> was a bad idea (for many reasons, including range as you mention, as >> has been confirmed marginal in our testing), and supporting legacy >> Bluetooth 4 specifically was an even worse idea (for even lower range >> and its incredibly short 25 byte payloads), this decision was not >> made by, and cannot be reversed by, the DRIP WG. We can only hope to >> mitigate its security deficiencies, address the issues it fails to >> address (such as how registries work and how communications between >> an Observer and a Remote Pilot can be initiated), and improve its >> interoperability with the Internet once we get beyond the Broadcast >> RID data link. > > It does clarify the point of view. > > I will try to get along with the described view.  The best part that I > could follow is the part of DRIP developments that improve the > interoperability with the Internet. > > In 6lo there was a perspective of a Gateway, or a 'backbone router', > that would link many small Bluetooth devices to the Internet.  But > unfortunately it is a smart network, instead of a 'smart end dumb > network'. See: draft-moskowitz-drip-crowd-sourced-rid > > lpwan directions too are distanced from the 'smart end dumb network', > because they dont use IP headers either: SCHC removes them. > > I also struggle via IPWAVE WG for the use of IP networking layer for > automobiles, as opposed to IEEE P1609.3 Networking layer, and that too > is far from being a win. Part of the reason I stepped away from IPWAVE work.  I have 19 years automotive, so I 'know' the players at Ford and other OEMs, and while at Verizon we replied to the PKI RFI with an approach that would allow for good support of cellphone participation and were basically told to go away... > > Overall, there seems to be an agreement on tendency to act more and more > that way that you describe.  There is a draft that presents that in a > advantageous light; it's titled "Limited Domains", in which one could do > many things precisely as one wishes, and not as being Internet as IP is. > > I will try to follow the developments along these lines. > > Alex > >> >> On Wed, Aug 5, 2020 at 6:11 AM Alexandre Petrescu >> > >> wrote: >> >> >> >> Le 04/08/2020 à 17:51, Robert Moskowitz a écrit : >>> >>> >>> On 8/4/20 11:27 AM, Alexandre Petrescu wrote: >>>> Thanks for the clarification. >>>> >>>> Le 04/08/2020 à 17:17, Stuart W. Card a écrit : >>>>> I just want to respond to one line that I think comes from confusion: >>>>> >>>>>> But if we have reluctance about the use of ADS-B, and thus >>>>>> of IP, and we recommend Bluetooth-without-IP to identify >>>>>> drones >>>>> >>>>> We aren't recommending Bluetooth-without-IP, we are >>>>> _supporting_ it, >>>> >>>> But, the security manifest that I have seen on slides during the >>>> presentation of the DRIP WG meeting - is something below IP, right? >>> >>> For now, we are dealing with broadcast messages.  Either over >>> Bluetooth or WiFI (NAN). >> >> If it is a broadcast message and it is over Bluetooth or over WiFi >> then it certainly is IP multicast, cant be anything else. >> >> If it is IP multicast over Bluetooth or over WiFi then I wonder what >> is the value  in the Next Header field of the IP header format >> (RFC8200 "IPv6", section 3 "Header format").  Basically - what is the >> payload? >> >> If one asks me, I would dare to think that payload might be an >> ICMPv6 Router Advertisement. >> >>> There is NO security for the messages below the message package. >> >> Noted. >> >>> Just not enough payload size for anything that would work in a >>> broadcast environment like a National Airspace.  All of the >>> security we are specifying is inside the messages where >>> appropriate. >>> >>> That security manifest is a payload of the ASTM F3411-19 >>> Authentication Message. >> >> It costs 85USD I wont pay to see it.  It is security.  There will >> always be someone smarter to break that security and ask for more >> money. >> >> I would not oppose if that Authentication MEssage had a specification >> in clear. >> >>> These messages are broadcasted as Adam mentioned in his 'flying >>> DRIP' comments at the beginning. >> >> Thank you for the reminder.  I looked again at the 'flying DRIP' >> presentation during the WG meeting, and at the related draft. >> https://datatracker.ietf.org/meeting/108/materials/slides-108-drip-authentication-formats >> >> > and >> draft-wiethuechter-drip-auth-01 >> >> During the presentation, the slide clearly shows on slide 8 that a >> Bluetooth header immediately precedes an Open Drone ID message. >> There is no IP header in that slide. >> >> In the draft, there is similar discussion tightly related to >> Bluetooth and without IP. >> >> But if we are to have an independence of Bluetooth, and use a >> networking layer such as IP, then the question of the use of an >> authentication header is made differently. >> >> The authentication header would be an IP Authentication Header. This >> AH would be somehow re-used and extended where necessary for DRIP >> purposes. >> >>> Now later I expect us to move on to Network Remote ID and Command >>> and Control (C2). >>> >>> Most C2 (e.g. Mavlink) is directly over the MAC, but there is a >>> method to run it over UDP (I forget the UDP port commonly >>> used...). AX Enterprize has done this using HIP so the UA starts >>> with WiFi over the launch point, transitions to LTE, and on return >>> back to WiFi. >>> >>> Network Remote ID can work either directly from the UA, or via C2 >>> information to the GCS, from the GCS.  In either case, IP is >>> assumed. This will probably be done via UDP.  From the UA, >>> mobility will be important; from the GCS nice to have (most GCS >>> will be stable location).  As UDP to a fixed Net-SP, DTLS 1.3 is a >>> viable alternative to HIP. >> >> I will have to look closer at HIP again :-) and see how it could be >> made to work with DRIP and IP. >> >> Alex >> >>> >>> >>> >>> >>>> >>>> Alex >>>> >>>> as >>>>> it is specified in ASTM F3411, which most of the regulators >>>>> are dubbing as an approved technical means of regulatory >>>>> compliance. >>>>> >>>>> AFAIK, no one runs IP over ADS-B, which was designed as a >>>>> narrowband application specific communications stovepipe, not >>>>> a data link supporting higher layer network protocols, so not >>>>> great for IP. >>>>> >>>>> More importantly, we have no "reluctance about the use of... IP", >>>>> which is an entirely separate issue from ADS-B. >>>>> >>>>> On 8/4/2020 9:52 AM, Alexandre Petrescu wrote: >>>>>> architectural layers discussion... >>>>>> >>>>>> Le 30/07/2020 à 11:49, shuaiizhao(Shuai Zhao) a écrit : >>>>>>> Just to echo Stu on the ADSB, AFAIK, ADSB will  not be feasible >>>>>>> for most of the drones mostly due to SwaP, commercial drones >>>>>>> might be exception. >>>>>> >>>>>> It might be that ADS-B might be forbidden in drones on >>>>>> Earth, but how about the drones on Mars? ('NASA Mars >>>>>> helicopters', or ESA too).  On Mars there would be much less >>>>>> such drones, so less risk of interference. >>>>>> >>>>>> With such a system (ADS-B under IP) one could re-use DTN (Delay >>>>>> Tolerant Networking) between planets, and so identify drones even >>>>>> on Mars. >>>>>> >>>>>> But if we have reluctance about the use of ADS-B, and thus >>>>>> of IP, and we recommend Bluetooth-without-IP to identify >>>>>> drones, then we might become too dependent on it? >>>>>> >>>>>> (do not get me wrong, I do like Bluetooth, but I like many other >>>>>> things together with Bluetooth). >>>>>> >>>>>> Alex >>>>>> >>>>>>> >>>>>>> Best, >>>>>>> >>>>>>> Shuai Zhao >>>>>>> >>>>>>> *From: *Tm-rid > > on behalf of >>>>>>> "Stuart W. Card" > > *Date: >>>>>>> *Wednesday, July 29, 2020 at 19:46 *To: *"tm-rid@ietf.org >> " >>>>>>> > *Subject: >>>>>>> *[Drip] >> ADSB (was: Review of >>>>>>> draft-drip-arch-02 w.r.t. RFC6973, RFC8280 and other)(Internet >>>>>>> mail) >>>>>>> >>>>>>> Sorry for the slow reply. >>>>>>> >>>>>>> ADS-B is gradually being mandated for essentially all >>>>>>> manned aircraft. >>>>>>> >>>>>>> ADSB-In and ADSB-Out are mandated for airliners: -In gives their >>>>>>> pilots >>>>>>> >>>>>>> some Situational Awareness (SA) of other aircraft; -Out gives other >>>>>>> >>>>>>> pilots SA of the airliners. >>>>>>> >>>>>>> "ADSB-Out" is mandated even for small general aviation aircraft: >>>>>>> it does >>>>>>> >>>>>>> not directly benefit the pilots of those aircraft; but by >>>>>>> providing SA >>>>>>> >>>>>>> to others, it indirectly benefits all. >>>>>>> >>>>>>> ADSB is _not_ going to be deployed on large numbers of >>>>>>> small UAS as it >>>>>>> >>>>>>> would overwhelm the limited bandwidth available at those lower >>>>>>> radio >>>>>>> >>>>>>> frequencies (which propagate long ranges). In fact, it is >>>>>>> expected to be >>>>>>> >>>>>>> explicitly prohibited in the US per the FAA NPRM; I >>>>>>> suspect most of the >>>>>>> >>>>>>> rest of the world will do likewise. >>>>>>> >>>>>>> ADSB is also altogether insecure. >>>>>>> >>>>>>> On 7/9/2020 3:02 AM, Alexandre Petrescu wrote: >>>>>>> >>>>>>> ... >>>>>>> >>>>>>> They call it "ADS-B Receivers" (Automatic Dependent Surveillance - >>>>>>> >>>>>>> Broadcast). >>>>>>> >>>>>>> I wouuld like to ask if there is a packet dump available showing >>>>>>> such >>>>>>> >>>>>>> presence data form planes?  Maybe wireshark already >>>>>>> supports it, maybe >>>>>>> >>>>>>> it even dissects it... >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> ----------------------------------------- >>>>>>> >>>>>>> Stuart W. Card, PhD, Principal Engineer >>>>>>> >>>>>>> AX Enterprize, LLC www.axenterprize.com >> >>>>>>> >>>>>>> 4947 Commercial Drive, Yorkville NY 13495 >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> -- 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 >> >> -- Tm-rid mailing list Tm-rid@ietf.org >> https://www.ietf.org/mailman/listinfo/tm-rid >> > -- 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 --------------7006A62525E187E848FDF274 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 8/5/20 10:22 AM, Alexandre Petrescu wrote:
Hi,

Thank you for the reply.

Le 05/08/2020 à 15:38, Card, Stu a écrit :
Again, I wish to respond primarily to one line that again I believe results from some confusion.

If it is a broadcast message and it is over Bluetooth or over WiFi then it certainly is IP multicast, cant be anything else.

There is nothing preventing application layer protocols from being layered directly over link layer protocols. This is exactly what is typically done with Bluetooth, not only for UAS RID, but other applications as well. It can even be done with WiFi, Ethernet, etc.,
 although this is less commonly done. This certainly limits
flexibility and internetworking. Again, however, this is not up to
us: the regulators are citing ASTM F3411 for UAS RID; that standard
defines how to put UAS RID application specific message formats
directly into Bluetooth link layer frames, without any intervening
headers (such as would be required for IP encapsulation of the app
layer messages). While I think their specifying Bluetooth generally
was a bad idea (for many reasons, including range as you mention, as
has been confirmed marginal in our testing), and supporting legacy
Bluetooth 4 specifically was an even worse idea (for even lower range
and its incredibly short 25 byte payloads), this decision was not
made by, and cannot be reversed by, the DRIP WG. We can only hope to
mitigate its security deficiencies, address the issues it fails to
address (such as how registries work and how communications between
an Observer and a Remote Pilot can be initiated), and improve its
interoperability with the Internet once we get beyond the Broadcast
RID data link.

It does clarify the point of view.

I will try to get along with the described view.  The best part that I
could follow is the part of DRIP developments that improve the
interoperability with the Internet.

In 6lo there was a perspective of a Gateway, or a 'backbone router',
that would link many small Bluetooth devices to the Internet.  But
unfortunately it is a smart network, instead of a 'smart end dumb network'.

See:

draft-moskowitz-drip-crowd-sourced-rid


lpwan directions too are distanced from the 'smart end dumb network',
because they dont use IP headers either: SCHC removes them.

I also struggle via IPWAVE WG for the use of IP networking layer for
automobiles, as opposed to IEEE P1609.3 Networking layer, and that too
is far from being a win.

Part of the reason I stepped away from IPWAVE work.  I have 19 years automotive, so I 'know' the players at Ford and other OEMs, and while at Verizon we replied to the PKI RFI with an approach that would allow for good support of cellphone participation and were basically told to go away...


Overall, there seems to be an agreement on tendency to act more and more
that way that you describe.  There is a draft that presents that in a
advantageous light; it's titled "Limited Domains", in which one could do
many things precisely as one wishes, and not as being Internet as IP is.

I will try to follow the developments along these lines.

Alex


On Wed, Aug 5, 2020 at 6:11 AM Alexandre Petrescu <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>>
wrote:



Le 04/08/2020 à 17:51, Robert Moskowitz a écrit :


On 8/4/20 11:27 AM, Alexandre Petrescu wrote:
Thanks for the clarification.

Le 04/08/2020 à 17:17, Stuart W. Card a écrit :
I just want to respond to one line that I think comes from confusion:

But if we have reluctance about the use of ADS-B, and thus
of IP, and we recommend Bluetooth-without-IP to identify
drones

We aren't recommending Bluetooth-without-IP, we are
_supporting_ it,

But, the security manifest that I have seen on slides during the presentation of the DRIP WG meeting - is something below IP, right?

For now, we are dealing with broadcast messages.  Either over Bluetooth or WiFI (NAN).

If it is a broadcast message and it is over Bluetooth or over WiFi
then it certainly is IP multicast, cant be anything else.

If it is IP multicast over Bluetooth or over WiFi then I wonder what
is the value  in the Next Header field of the IP header format
(RFC8200 "IPv6", section 3 "Header format").  Basically - what is the
payload?

If one asks me, I would dare to think that payload might be an
ICMPv6 Router Advertisement.

There is NO security for the messages below the message package.

Noted.

Just not enough payload size for anything that would work in a broadcast environment like a National Airspace.  All of the
security we are specifying is inside the messages where
appropriate.

That security manifest is a payload of the ASTM F3411-19 Authentication Message.

It costs 85USD I wont pay to see it.  It is security.  There will always be someone smarter to break that security and ask for more
money.

I would not oppose if that Authentication MEssage had a specification
in clear.

These messages are broadcasted as Adam mentioned in his 'flying
DRIP' comments at the beginning.

Thank you for the reminder.  I looked again at the 'flying DRIP' presentation during the WG meeting, and at the related draft. https://datatracker.ietf.org/meeting/108/materials/slides-108-drip-authentication-formats


and
draft-wiethuechter-drip-auth-01

During the presentation, the slide clearly shows on slide 8 that a Bluetooth header immediately precedes an Open Drone ID message.
There is no IP header in that slide.

In the draft, there is similar discussion tightly related to
Bluetooth and without IP.

But if we are to have an independence of Bluetooth, and use a networking layer such as IP, then the question of the use of an
authentication header is made differently.

The authentication header would be an IP Authentication Header. This
AH would be somehow re-used and extended where necessary for DRIP
purposes.

Now later I expect us to move on to Network Remote ID and Command and Control (C2).

Most C2 (e.g. Mavlink) is directly over the MAC, but there is a method to run it over UDP (I forget the UDP port commonly
used...). AX Enterprize has done this using HIP so the UA starts
with WiFi over the launch point, transitions to LTE, and on return
back to WiFi.

Network Remote ID can work either directly from the UA, or via C2 information to the GCS, from the GCS.  In either case, IP is assumed. This will probably be done via UDP.  From the UA,
mobility will be important; from the GCS nice to have (most GCS
will be stable location).  As UDP to a fixed Net-SP, DTLS 1.3 is a
viable alternative to HIP.

I will have to look closer at HIP again :-) and see how it could be made to work with DRIP and IP.

Alex






Alex

as
it is specified in ASTM F3411, which most of the regulators
are dubbing as an approved technical means of regulatory
compliance.

AFAIK, no one runs IP over ADS-B, which was designed as a narrowband application specific communications stovepipe, not
a data link supporting higher layer network protocols, so not great for IP.

More importantly, we have no "reluctance about the use of... IP", which is an entirely separate issue from ADS-B.

On 8/4/2020 9:52 AM, Alexandre Petrescu wrote:
architectural layers discussion...

Le 30/07/2020 à 11:49, shuaiizhao(Shuai Zhao) a écrit :
Just to echo Stu on the ADSB, AFAIK, ADSB will  not be feasible for most of the drones mostly due to SwaP, commercial drones might be exception.

It might be that ADS-B might be forbidden in drones on
Earth, but how about the drones on Mars? ('NASA Mars
helicopters', or ESA too).  On Mars there would be much less
such drones, so less risk of interference.

With such a system (ADS-B under IP) one could re-use DTN (Delay Tolerant Networking) between planets, and so identify drones even on Mars.

But if we have reluctance about the use of ADS-B, and thus
of IP, and we recommend Bluetooth-without-IP to identify
drones, then we might become too dependent on it?

(do not get me wrong, I do like Bluetooth, but I like many other things together with Bluetooth).

Alex


Best,

Shuai Zhao

*From: *Tm-rid <tm-rid-bounces@ietf.org
<mailto:tm-rid-bounces@ietf.org>> on behalf of
"Stuart W. Card" <stu.card@axenterprize.com
<mailto:stu.card@axenterprize.com>> *Date:
*Wednesday, July 29, 2020 at 19:46 *To: *"tm-rid@ietf.org
<mailto:tm-rid@ietf.org>"
<tm-rid@ietf.org <mailto:tm-rid@ietf.org>> *Subject:
*[Drip]
ADSB (was: Review of
draft-drip-arch-02 w.r.t. RFC6973, RFC8280 and other)(Internet mail)

Sorry for the slow reply.

ADS-B is gradually being mandated for essentially all
manned aircraft.

ADSB-In and ADSB-Out are mandated for airliners: -In gives their pilots

some Situational Awareness (SA) of other aircraft; -Out gives other

pilots SA of the airliners.

"ADSB-Out" is mandated even for small general aviation aircraft: it does

not directly benefit the pilots of those aircraft; but by providing SA

to others, it indirectly benefits all.

ADSB is _not_ going to be deployed on large numbers of
small UAS as it

would overwhelm the limited bandwidth available at those lower radio

frequencies (which propagate long ranges). In fact, it is expected to be

explicitly prohibited in the US per the FAA NPRM; I
suspect most of the

rest of the world will do likewise.

ADSB is also altogether insecure.

On 7/9/2020 3:02 AM, Alexandre Petrescu wrote:

...

They call it "ADS-B Receivers" (Automatic Dependent Surveillance -

Broadcast).

I wouuld like to ask if there is a packet dump available showing such

presence data form planes?  Maybe wireshark already
supports it, maybe

it even dissects it...

--

-----------------------------------------

Stuart W. Card, PhD, Principal Engineer

AX Enterprize, LLC www.axenterprize.com
<http://www.axenterprize.com>

4947 Commercial Drive, Yorkville NY 13495








-- Standard Robert Moskowitz Owner HTT Consulting C:248-219-2059 F:248-968-2824 E:rgm@labs.htt-consult.com
<mailto:E%3Argm@labs.htt-consult.com>

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

-- Tm-rid mailing list Tm-rid@ietf.org <mailto:Tm-rid@ietf.org> https://www.ietf.org/mailman/listinfo/tm-rid



--
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
--------------7006A62525E187E848FDF274-- From nobody Wed Aug 5 07:34:42 2020 Return-Path: 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 BB83F3A0918 for ; Wed, 5 Aug 2020 07:34:40 -0700 (PDT) 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=axenterprize.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 pPFrd_hiORtb for ; Wed, 5 Aug 2020 07:34:36 -0700 (PDT) Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 487EF3A0A62 for ; Wed, 5 Aug 2020 07:34:34 -0700 (PDT) Received: by mail-ej1-x631.google.com with SMTP id m22so3555618eje.10 for ; Wed, 05 Aug 2020 07:34:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axenterprize.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=albF01xIS8IWUq0nbfsNsNyu2XDeQwI12sfNKrdLNIk=; b=MHQfWWeIHfEvr5ln1HWcrPenkjbbCahqxZ057t8uI2gjK3dFFQ9Odla647ESO14GOf JuvaEEV1Z07+V7VfZk0z1n8vJcifZbXXP2Rb9DVlskqR+VT4Y4J6/yA1AVmB/mVCgMwb id1pFdkqVHe8V3TrFQXWctVx7GGknPZQn7udY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=albF01xIS8IWUq0nbfsNsNyu2XDeQwI12sfNKrdLNIk=; b=aPbodrmqIPZV+Bbk8qLqhFV08hmg3aZy56w5M9b3qQXMxHjz8PZFxD7rjLAs5rWFuK 4pK4Kt6Oa4zqO3DU6OVyygf2YPWxeO+iPqKma0KlyLNwb3KmwyLjxL+mRYoth5zW7cP9 ZrIu0UFdOjja9H8LkRX1wyX4on+Gyg61PaJ+3g322v2G0ThQBY+cQN8glEXlnI8sQukE zGTfuy8aQG7WjPFsHEkwZYSzZrHpL65fqreTolIY6M+kYUs2X+8ES89JkrQe0cgVhAry g5ZlHuMwRkpAuM2WYuAO9s5F3kWTChvt9XXNkqQxBNfmqbvWCQrGxA3NGmLGqu5vczaJ rBJA== X-Gm-Message-State: AOAM5319tK96Xh4sUBiZSVcRqVVYc1UXML2tCtDC12FeIURe8YuY0EDY 0HAWgHPb7adaR/7QhRATkUJxK7AdyxJ/iPiHhOxBH4+hO/8= X-Google-Smtp-Source: ABdhPJwDlPgbbrFygNQ9XbMgrXJdLrRjpR1dQCRivt7xpvMsp4xZ74u3ei/z9LRI+ZsESLnqqVwwmcpkLln28rKDOTM= X-Received: by 2002:a17:906:c04d:: with SMTP id bm13mr3342084ejb.321.1596638072491; Wed, 05 Aug 2020 07:34:32 -0700 (PDT) MIME-Version: 1.0 References: <1bebf5b1-1fa5-6902-5bb7-9ec3582e6d9a@andersdotter.cc> <3c632ce9-115d-11f5-ee33-bfabd4973522@labs.htt-consult.com> <7ddd9a2f-23ba-dd82-8cfb-1d2974969e67@gmail.com> <61511ef6-5b9b-5b62-f922-d32b994a35b9@gmail.com> <2e1cbffc-8554-222b-d558-43e048194104@gmail.com> In-Reply-To: <2e1cbffc-8554-222b-d558-43e048194104@gmail.com> From: "Card, Stu" Date: Wed, 5 Aug 2020 10:34:14 -0400 Message-ID: To: Alexandre Petrescu Cc: Robert Moskowitz , tm-rid@ietf.org Content-Type: multipart/alternative; boundary="00000000000025686c05ac2245f5" Archived-At: Subject: Re: [Drip] ADSB X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 14:34:41 -0000 --00000000000025686c05ac2245f5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, the openly published early draft of ASTM F3411 was developed largely by Gabriel Cox of Intel and his group there. While we all are generally suspicious of the motivations of large companies, I have spoken often with Gabriel: his heart is pure; he says Intel hopes to increase sales by simply helping mature a standard that enables a market to grow. Development and publication of the standard within ASTM then attracted many other large and small players, so Intel could not force anything upon the world that benefited primarily Intel. While I do not agree with all the decisions made (and neither does Gabriel), they are the decisions that SDO working group made, in response to the concerns of many different stakeholders (especially regulators, manufacturers and would-be UTM network service providers). Alas, ASTM supports themselves by sales of standards documents, so F3411-19 is not openly published. OTOH $85 is small compared to the value of most contributor's time working on the problem, and better still one can join ASTM as an individual for only $75 and get this standard as part of the one free "volume" of standards that a member may select (from a large library) upon joining. As a fallback, we point people to the openly published early draft, which provides pretty good context; perhaps I should add it to the reference list in the requirements draft? Thanks again for your interest and help with this! On Wed, Aug 5, 2020 at 10:23 AM Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > > > Le 05/08/2020 =C3=A0 15:50, Card, Stu a =C3=A9crit : > > Again, a single point response. The reason this work is appropriate for > > IETF rather than the Bluetooth SIG is that ASTM F3411 specifies > > Bluetooth _only_ as one transport for Broadcast RID (WiFi NaN is also > > specified and other alternatives could be added later, as you, Bob and > > others are discussing, also consider RTCA SC-228 DO-362 UAS C2 Data Lin= k > > at ~1 and ~5 GHz), but there is also Network RID where ASTM F3411 > > specifies use of the Internet, and a lot more to the overall UAS RID > > architecture/problem than just the initial streaming of messages from > > the UAS. > > > > Please look at the openly published early draft of ASTM F3411 to which > > Bob pointed you, > > I looked and I will keep it aside for reference when needed. > > It's an Intel document. > > > https://github.com/opendroneid/specs/blob/master/OpenDroneID_Bluetooth_0.= 64.3.pdf > > Alex > > and perhaps some of the other external docs cited in > > the DRIP requirements draft, for essential context on the UAS RID > > problem and what others have already done to address it, which we hope > > to complement (not replace) with DRIP. Thanks! > > > > > > On Wed, Aug 5, 2020 at 8:50 AM Alexandre Petrescu > > > > wrote: > > > > > > > > Le 05/08/2020 =C3=A0 13:53, Robert Moskowitz a =C3=A9crit : > > > > > > > > > On 8/5/20 6:11 AM, Alexandre Petrescu wrote: > > >> > > >> > > >> Le 04/08/2020 =C3=A0 17:51, Robert Moskowitz a =C3=A9crit : > > >>> > > >>> > > >>> On 8/4/20 11:27 AM, Alexandre Petrescu wrote: > > >>>> Thanks for the clarification. > > >>>> > > >>>> Le 04/08/2020 =C3=A0 17:17, Stuart W. Card a =C3=A9crit : > > >>>>> I just want to respond to one line that I think comes from > > >>>>> confusion: > > >>>>> > > >>>>>> But if we have reluctance about the use of ADS-B, and thus > > >>>>>> of IP, and we recommend Bluetooth-without-IP to identify > > >>>>>> drones > > >>>>> > > >>>>> We aren't recommending Bluetooth-without-IP, we are > > >>>>> _supporting_ it, > > >>>> > > >>>> But, the security manifest that I have seen on slides during > > >>>> the presentation of the DRIP WG meeting - is something below > > >>>> IP, right? > > >>> > > >>> For now, we are dealing with broadcast messages. Either over > > >>> Bluetooth or WiFI (NAN). > > >> > > >> If it is a broadcast message and it is over Bluetooth or over > WiFi > > >> then it certainly is IP multicast, cant be anything else. > > > > > > Wrong for BT4. There are only 25 bytes available. We can do mo= st > > > of the messaging in a single frame. To do anything with IP will > > > force this to a multiframe design. > > > > I might say something stupid if I am allowed, maybe things that are > > already known. Sorry, I did not check the BoF archive discussion. > But > > here goes anyways. If one wants to do something with Bluetooth4 > below > > IP and finds it to be too small packets, then there could be severa= l > > possibilities: > > - do it at Bluetooth SIG instead of IETF; > > - do it in 6lo WG; > > - use a header compression scheme at IETF (6lowpan HC at 6lo WG, > SCHC at > > LP-WAN WG, ROHC and why not CBOR); > > - implement packet fragmentation and reassembly and multiframe desi= gn > > below IP; > > - use the already available data in the 25 bytes in order to realiz= e > > that identification (there must be MAC addresses in there, and > > they're > > likely to be useful). > > > > > Even BT5 it is wrong for the Authentication Message. We need th= e > > > full frame for our content. We would have to go with multiframe > > > design for BT5 as a result. > > > > So, I do not understand: does DRIP want the entire packet to stay o= f > > size 25bytes? Or does DRIP want the packet to be more than 25bytes= ? > > > > Would a multiframe design in which an IP packet of length 1280bytes > is > > chopped into 25bytes BT5 packets be advantageous for DRIP? > > > > Do the BT5 packets have a notion of interlinking between sub-packet= s > > that make a bigger packet? (such a mechanism exists at the IP > layer; it > > uses Identification to identify a chain and an Offset to say where = in > > the chain is that sub-packet to be found). > > > > > So this leaves WiFi NAN. Sure you can do it, but why? What doe= s > it > > > add? In My Not So Humble Opinion (IMNSOHO) nothing but cost and > > > processing overhead. > > > > I think WiFi 5.4 GHz is already used extensively to remotely contro= l > > drones. These consoles with joysticks are WiFi 5.4GHz, if I am not > > mistaken. > > > > >> If it is IP multicast over Bluetooth or over WiFi then I wonder > > >> what is the value in the Next Header field of the IP header > > >> format (RFC8200 "IPv6", section 3 "Header format"). Basically = - > > >> what is the payload? > > >> > > >> If one asks me, I would dare to think that payload might be an > > >> ICMPv6 Router Advertisement. > > >> > > >>> There is NO security for the messages below the message packag= e. > > >> > > >> Noted. > > >> > > >>> Just not enough payload size for anything that would work in a > > >>> broadcast environment like a National Airspace. All of the > > >>> security we are specifying is inside the messages where > > >>> appropriate. > > >>> > > >>> That security manifest is a payload of the ASTM F3411-19 > > >>> Authentication Message. > > >> > > >> It costs 85USD I wont pay to see it. It is security. There wi= ll > > >> always be someone smarter to break that security and ask for mo= re > > >> money. > > > > > > Look at: > > > > > > > > > https://github.com/opendroneid/specs/blob/master/OpenDroneID_Bluetooth_0.= 64.3.pdf > > > > > > > > > > > It is close enough. > > > > Thanks for the pointer. Noted. > > > > It is about Bluetooth. Should be submitted to Bluetooth SIG. > > > > I might stay something stupid here again... si I wont say it :-) > > > > >> I would not oppose if that Authentication MEssage had a > > >> specification in clear. > > > > > > The above plus Adam's draft will get you there. > > > > > >> > > >>> These messages are broadcasted as Adam mentioned in his 'flyin= g > > >>> DRIP' comments at the beginning. > > >> > > >> Thank you for the reminder. I looked again at the 'flying DRIP= ' > > >> presentation during the WG meeting, and at the related draft. > > >> > > > https://datatracker.ietf.org/meeting/108/materials/slides-108-drip-authen= tication-formats > > >> > > >> > > >> > > >> and draft-wiethuechter-drip-auth-01 > > >> > > >> During the presentation, the slide clearly shows on slide 8 tha= t > a > > >> Bluetooth header immediately precedes an Open Drone ID message. > > >> There is no IP header in that slide. > > > > > > That is right. No IP. No room for it. No justification for it= . > It > > > is all RLOS only. > > > > I might say something stupid here: no IP? No IETF. > > > > >> In the draft, there is similar discussion tightly related to > > >> Bluetooth and without IP. > > >> > > >> But if we are to have an independence of Bluetooth, and use a > > >> networking layer such as IP, then the question of the use of an > > >> authentication header is made differently. > > > > > > Again what is the justification for adding IP multicast? > > > > I would not be afraid of IP multicast like the multicast we know fo= r > > video delivery. It is IP multicast because IP is IPv6 and IPv6 has > no > > broadcast. > > > > _If_ there is agreement that DRIP should be with IP (Internet > Protocol). > > > > We know that the drone identification should be broadcasted (like i= n > TV > > broadcast). In IPv4 there is a mechanism to implement such > TV-broadcast > > concept. It is called IPv4 broadcast. That broadcast is sent to a > > dedicated address (like 255.255.255.255 which is all Internet, or > like > > 195.212.142.255 which is all computers in a particular subnet). In > IPv6 > > such broadcast concept does not exist. Rather, it's called > 'multicast' > > and, as opposed to IPv4, it has a mandatory and voluntary join/leav= e > > mechanism. > > > > I name that IPv6 multicast simply IP multicast, because IPv4 should > not > > be used as basis for any new work at IETF. > > > > On such an IP multicast perspective for DRIP, one would have to com= e > up > > with an architecture for joining and leaving that makes it easy to > use > > by authorities, mandatory to implement, is secure enough (security > and > > multicast is not that easy), etc. > > > > > Where do you see these messages going beyond the RF Line Of Sigh= t? > > > > True. > > > > But one would not want all BT5 devices (like my watch or earphones) > > around a drone's sight to be awaken by its identification beacons, > > right? Only those devices who have voluntarily subscribed to that > > multicast group would be awaken. > > > > > > >> The authentication header would be an IP Authentication Header. > > >> This AH would be somehow re-used and extended where necessary f= or > > >> DRIP purposes. > > >> > > >>> Now later I expect us to move on to Network Remote ID and > Command > > >>> and Control (C2). > > >>> > > >>> Most C2 (e.g. Mavlink) is directly over the MAC, but there is = a > > >>> method to run it over UDP (I forget the UDP port commonly > > >>> used...). AX Enterprize has done this using HIP so the UA star= ts > > >>> with WiFi over the launch point, transitions to LTE, and on > > >>> return back to WiFi. > > >>> > > >>> Network Remote ID can work either directly from the UA, or via > > >>> C2 information to the GCS, from the GCS. In either case, IP i= s > > >>> assumed. This will probably be done via UDP. From the UA, > > >>> mobility will be important; from the GCS nice to have (most GC= S > > >>> will be stable location). As UDP to a fixed Net-SP, DTLS 1.3 = is > > >>> a viable alternative to HIP. > > >> > > >> I will have to look closer at HIP again :-) and see how it coul= d > > >> be made to work with DRIP and IP. > > > > > > Stu, Adam, Andrei, and I see HIP for where there is pairwise > > > communication with potentially both ends mobile and using multip= le > > > interfaces. Once you have that use case, be consistent and use = it > > > for simpler situations. > > > > I wanted to ask whether using a Host Identity that is > cryptographically > > generated is sufficient for authorities to trust a drone upon > reception > > of one DRIP identification packet, or maybe am additional roundrip = (a > > ping, a request-response) would still be needed from ground officer > to > > drone to make sure it's the right drone who replies? Or maybe a fu= ll > > Diffie-Hellman exchange is needed? > > > > Alex > > > > > > > >> > > >> Alex > > >> > > >>> > > >>> > > >>> > > >>> > > >>>> > > >>>> Alex > > >>>> > > >>>> as > > >>>>> it is specified in ASTM F3411, which most of the regulators > > >>>>> are dubbing as an approved technical means of regulatory > > >>>>> compliance. > > >>>>> > > >>>>> AFAIK, no one runs IP over ADS-B, which was designed as a > > >>>>> narrowband application specific communications stovepipe, > > >>>>> not a data link supporting higher layer network protocols, > > >>>>> so not great for IP. > > >>>>> > > >>>>> More importantly, we have no "reluctance about the use of... > > >>>>> IP", which is an entirely separate issue from ADS-B. > > >>>>> > > >>>>> On 8/4/2020 9:52 AM, Alexandre Petrescu wrote: > > >>>>>> architectural layers discussion... > > >>>>>> > > >>>>>> Le 30/07/2020 =C3=A0 11:49, shuaiizhao(Shuai Zhao) a =C3=A9= crit : > > >>>>>>> Just to echo Stu on the ADSB, AFAIK, ADSB will not be > > >>>>>>> feasible for most of the drones mostly due to SwaP, > > >>>>>>> commercial drones might be exception. > > >>>>>> > > >>>>>> It might be that ADS-B might be forbidden in drones on > > >>>>>> Earth, but how about the drones on Mars? ('NASA Mars > > >>>>>> helicopters', or ESA too). On Mars there would be much > > >>>>>> less such drones, so less risk of interference. > > >>>>>> > > >>>>>> With such a system (ADS-B under IP) one could re-use DTN > > >>>>>> (Delay Tolerant Networking) between planets, and so > > >>>>>> identify drones even on Mars. > > >>>>>> > > >>>>>> But if we have reluctance about the use of ADS-B, and thus > > >>>>>> of IP, and we recommend Bluetooth-without-IP to identify > > >>>>>> drones, then we might become too dependent on it? > > >>>>>> > > >>>>>> (do not get me wrong, I do like Bluetooth, but I like many > > >>>>>> other things together with Bluetooth). > > >>>>>> > > >>>>>> Alex > > >>>>>> > > >>>>>>> > > >>>>>>> Best, > > >>>>>>> > > >>>>>>> Shuai Zhao > > >>>>>>> > > >>>>>>> *From: *Tm-rid > > on behalf of > > >>>>>>> "Stuart W. Card" > > *Date: > > >>>>>>> *Wednesday, July 29, 2020 at 19:46 *To: > > >>>>>>> *"tm-rid@ietf.org " > > > *Subject: *[Drip] > > >>>>>>> ADSB (was: Review of draft-drip-arch-02 w.r.t. RFC6973, > > >>>>>>> RFC8280 and other)(Internet mail) > > >>>>>>> > > >>>>>>> Sorry for the slow reply. > > >>>>>>> > > >>>>>>> ADS-B is gradually being mandated for essentially all > > >>>>>>> manned aircraft. > > >>>>>>> > > >>>>>>> ADSB-In and ADSB-Out are mandated for airliners: -In > > >>>>>>> gives their pilots > > >>>>>>> > > >>>>>>> some Situational Awareness (SA) of other aircraft; -Out > > >>>>>>> gives other > > >>>>>>> > > >>>>>>> pilots SA of the airliners. > > >>>>>>> > > >>>>>>> "ADSB-Out" is mandated even for small general aviation > > >>>>>>> aircraft: it does > > >>>>>>> > > >>>>>>> not directly benefit the pilots of those aircraft; but > > >>>>>>> by providing SA > > >>>>>>> > > >>>>>>> to others, it indirectly benefits all. > > >>>>>>> > > >>>>>>> ADSB is _not_ going to be deployed on large numbers of > > >>>>>>> small UAS as it > > >>>>>>> > > >>>>>>> would overwhelm the limited bandwidth available at those > > >>>>>>> lower radio > > >>>>>>> > > >>>>>>> frequencies (which propagate long ranges). In fact, it > > >>>>>>> is expected to be > > >>>>>>> > > >>>>>>> explicitly prohibited in the US per the FAA NPRM; I > > >>>>>>> suspect most of the > > >>>>>>> > > >>>>>>> rest of the world will do likewise. > > >>>>>>> > > >>>>>>> ADSB is also altogether insecure. > > >>>>>>> > > >>>>>>> On 7/9/2020 3:02 AM, Alexandre Petrescu wrote: > > >>>>>>> > > >>>>>>> ... > > >>>>>>> > > >>>>>>> They call it "ADS-B Receivers" (Automatic Dependent > > >>>>>>> Surveillance - > > >>>>>>> > > >>>>>>> Broadcast). > > >>>>>>> > > >>>>>>> I wouuld like to ask if there is a packet dump available > > >>>>>>> showing such > > >>>>>>> > > >>>>>>> presence data form planes? Maybe wireshark already > > >>>>>>> supports it, maybe > > >>>>>>> > > >>>>>>> it even dissects it... > > >>>>>>> > > >>>>>>> -- > > >>>>>>> > > >>>>>>> ----------------------------------------- > > >>>>>>> > > >>>>>>> Stuart W. Card, PhD, Principal Engineer > > >>>>>>> > > >>>>>>> AX Enterprize, LLC www.axenterprize.com > > > > >>>>>>> > > >>>>>>> 4947 Commercial Drive, Yorkville NY 13495 > > >>>>>>> > > >>>>>>> > > >>>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>> > > >>> > > >>> -- Standard Robert Moskowitz Owner HTT Consulting C:248-219-20= 59 > > >>> 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 > > > > > > -- 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 matte= r > > > who gets the credit > > > > -- > > Tm-rid mailing list > > Tm-rid@ietf.org > > https://www.ietf.org/mailman/listinfo/tm-rid > > > --00000000000025686c05ac2245f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, the openly published early draft of ASTM F3411 was de= veloped largely by Gabriel Cox of Intel and his group there. While we all a= re generally suspicious of the motivations of large companies, I have spoke= n often with Gabriel: his heart is pure; he says Intel hopes to increase sa= les by simply helping mature a standard that enables a market to grow. Deve= lopment and publication of the standard within ASTM then attracted many oth= er large and small players, so Intel could not force anything upon the worl= d that benefited primarily Intel. While I do not agree with all the decisio= ns made (and neither does Gabriel), they are the decisions that SDO working= group made, in response to the concerns of many different stakeholders (es= pecially regulators, manufacturers and would-be UTM network service provide= rs). Alas, ASTM supports themselves by sales of standards documents, so F34= 11-19 is not openly published. OTOH $85 is small compared to the value of m= ost contributor's time working on the problem, and better still one can= join ASTM as an individual for only $75 and get this standard as part of t= he one free "volume" of standards that a member may select (from = a large library) upon joining. As a fallback, we point people to the openly= published early draft, which provides pretty good context; perhaps I shoul= d add it to the reference list in the requirements draft? Thanks again for = your interest and help with this!


On Wed, Aug 5, 2020 at 10:2= 3 AM Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:


Le 05/08/2020 =C3=A0 15:50, Card, Stu a =C3=A9crit=C2=A0:
> Again, a single point response. The reason this work is appropriate fo= r
> IETF rather than the Bluetooth SIG is that ASTM F3411 specifies
> Bluetooth _only_ as one transport for Broadcast RID (WiFi NaN is also =
> specified and other alternatives could be added later, as you, Bob and=
> others are discussing, also consider RTCA SC-228 DO-362 UAS C2 Data Li= nk
> at ~1 and ~5 GHz), but there is also Network RID where ASTM F3411
> specifies use of the Internet, and a lot more to the overall UAS RID <= br> > architecture/problem than just the initial streaming of messages from =
> the UAS.
>
> Please look at the openly published early draft of ASTM F3411 to which=
> Bob pointed you,

I looked and I will keep it aside for reference when needed.

It's an Intel document.

https://github.com/= opendroneid/specs/blob/master/OpenDroneID_Bluetooth_0.64.3.pdf

Alex

=C2=A0 and perhaps some of the other external docs cited in
> the DRIP requirements draft, for=C2=A0 essential context on the UAS RI= D
> problem and what others have already done to address it, which we hope=
> to complement (not replace) with DRIP. Thanks!
>
>
> On Wed, Aug 5, 2020 at 8:50 AM Alexandre Petrescu
> <= alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>>= wrote:
>
>
>
>=C2=A0 =C2=A0 =C2=A0Le 05/08/2020 =C3=A0 13:53, Robert Moskowitz a =C3= =A9crit :
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > On 8/5/20 6:11 AM, Alexandre Petrescu wrote:<= br> >=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> Le 04/08/2020 =C3=A0 17:51, Robert Moskow= itz a =C3=A9crit :
>=C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 >>> On 8/4/20 11:27 AM, Alexandre Petresc= u wrote:
>=C2=A0 =C2=A0 =C2=A0 >>>> Thanks for the clarification.
>=C2=A0 =C2=A0 =C2=A0 >>>>
>=C2=A0 =C2=A0 =C2=A0 >>>> Le 04/08/2020 =C3=A0 17:17, Stuar= t W. Card a =C3=A9crit :
>=C2=A0 =C2=A0 =C2=A0 >>>>> I just want to respond to one= line that I think comes from
>=C2=A0 =C2=A0 =C2=A0 >>>>> confusion:
>=C2=A0 =C2=A0 =C2=A0 >>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>> But if we have reluctance= about the use of ADS-B, and thus
>=C2=A0 =C2=A0 =C2=A0 >>>>>> of IP, and we recommend B= luetooth-without-IP to identify
>=C2=A0 =C2=A0 =C2=A0 >>>>>> drones
>=C2=A0 =C2=A0 =C2=A0 >>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>> We aren't recommending Bl= uetooth-without-IP, we are
>=C2=A0 =C2=A0 =C2=A0 >>>>> _supporting_ it,
>=C2=A0 =C2=A0 =C2=A0 >>>>
>=C2=A0 =C2=A0 =C2=A0 >>>> But, the security manifest that I= have seen on slides during
>=C2=A0 =C2=A0 =C2=A0 >>>> the presentation of the DRIP WG m= eeting - is something below
>=C2=A0 =C2=A0 =C2=A0 >>>> IP, right?
>=C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 >>> For now, we are dealing with broadcas= t messages.=C2=A0 Either over
>=C2=A0 =C2=A0 =C2=A0 >>> Bluetooth or WiFI (NAN).
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> If it is a broadcast message and it is ov= er Bluetooth or over WiFi
>=C2=A0 =C2=A0 =C2=A0 >> then it certainly is IP multicast, cant b= e anything else.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Wrong for BT4.=C2=A0 There are only 25 bytes = available.=C2=A0 We can do most
>=C2=A0 =C2=A0 =C2=A0 > of the messaging in a single frame.=C2=A0 To = do anything with IP will
>=C2=A0 =C2=A0 =C2=A0 > force this to a multiframe design.
>
>=C2=A0 =C2=A0 =C2=A0I might say something stupid if I am allowed, maybe= things that are
>=C2=A0 =C2=A0 =C2=A0already known.=C2=A0 Sorry, I did not check the BoF= archive discussion.=C2=A0 But
>=C2=A0 =C2=A0 =C2=A0here goes anyways.=C2=A0 If one wants to do somethi= ng with Bluetooth4 below
>=C2=A0 =C2=A0 =C2=A0IP and finds it to be too small packets, then there= could be several
>=C2=A0 =C2=A0 =C2=A0possibilities:
>=C2=A0 =C2=A0 =C2=A0- do it at Bluetooth SIG instead of IETF;
>=C2=A0 =C2=A0 =C2=A0- do it in 6lo WG;
>=C2=A0 =C2=A0 =C2=A0- use a header compression scheme at IETF (6lowpan = HC at 6lo WG, SCHC at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0LP-WAN WG, ROHC and why not CBOR); >=C2=A0 =C2=A0 =C2=A0- implement packet fragmentation and reassembly and= multiframe design
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0below IP;
>=C2=A0 =C2=A0 =C2=A0- use the already available data in the 25 bytes in= order to realize
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that identification (there must be MA= C addresses in there, and
>=C2=A0 =C2=A0 =C2=A0they're
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0likely to be useful).
>
>=C2=A0 =C2=A0 =C2=A0 > Even BT5 it is wrong for the Authentication M= essage.=C2=A0 We need the
>=C2=A0 =C2=A0 =C2=A0 > full frame for our content.=C2=A0 We would ha= ve to go with multiframe
>=C2=A0 =C2=A0 =C2=A0 > design for BT5 as a result.
>
>=C2=A0 =C2=A0 =C2=A0So, I do not understand: does DRIP want the entire = packet to stay of
>=C2=A0 =C2=A0 =C2=A0size 25bytes?=C2=A0 Or does DRIP want the packet to= be more than 25bytes?
>
>=C2=A0 =C2=A0 =C2=A0Would a multiframe design in which an IP packet of = length 1280bytes is
>=C2=A0 =C2=A0 =C2=A0chopped into 25bytes BT5 packets be advantageous fo= r DRIP?
>
>=C2=A0 =C2=A0 =C2=A0Do the BT5 packets have a notion of interlinking be= tween sub-packets
>=C2=A0 =C2=A0 =C2=A0that make a bigger packet?=C2=A0 (such a mechanism = exists at the IP layer; it
>=C2=A0 =C2=A0 =C2=A0uses Identification to identify a chain and an Offs= et to say where in
>=C2=A0 =C2=A0 =C2=A0the chain is that sub-packet to be found).
>
>=C2=A0 =C2=A0 =C2=A0 > So this leaves WiFi NAN.=C2=A0 Sure you can d= o it, but why?=C2=A0 What does it
>=C2=A0 =C2=A0 =C2=A0 > add?=C2=A0 In My Not So Humble Opinion (IMNSO= HO) nothing but cost and
>=C2=A0 =C2=A0 =C2=A0 > processing overhead.
>
>=C2=A0 =C2=A0 =C2=A0I think WiFi 5.4 GHz is already used extensively to= remotely control
>=C2=A0 =C2=A0 =C2=A0drones.=C2=A0 These consoles with joysticks are WiF= i 5.4GHz, if I am not
>=C2=A0 =C2=A0 =C2=A0mistaken.
>
>=C2=A0 =C2=A0 =C2=A0 >> If it is IP multicast over Bluetooth or o= ver WiFi then I wonder
>=C2=A0 =C2=A0 =C2=A0 >> what is the value=C2=A0 in the Next Heade= r field of the IP header
>=C2=A0 =C2=A0 =C2=A0 >> format (RFC8200 "IPv6", section= 3 "Header format").=C2=A0 Basically -
>=C2=A0 =C2=A0 =C2=A0 >> what is the payload?
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> If one asks me, I would dare to think tha= t payload might be an
>=C2=A0 =C2=A0 =C2=A0 >> ICMPv6 Router Advertisement.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>> There is NO security for the messages= below the message package.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> Noted.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>> Just not enough payload size for anyt= hing that would work in a
>=C2=A0 =C2=A0 =C2=A0 >>> broadcast environment like a National= Airspace.=C2=A0 All of the
>=C2=A0 =C2=A0 =C2=A0 >>> security we are specifying is inside = the messages where
>=C2=A0 =C2=A0 =C2=A0 >>> appropriate.
>=C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 >>> That security manifest is a payload o= f the ASTM F3411-19
>=C2=A0 =C2=A0 =C2=A0 >>> Authentication Message.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> It costs 85USD I wont pay to see it.=C2= =A0 It is security.=C2=A0 There will
>=C2=A0 =C2=A0 =C2=A0 >> always be someone smarter to break that s= ecurity and ask for more
>=C2=A0 =C2=A0 =C2=A0 >> money.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Look at:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0https://github.com/opendroneid/specs/blob/master/OpenDroneID_Bluetooth= _0.64.3.pdf
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0It is close enough.
>
>=C2=A0 =C2=A0 =C2=A0Thanks for the pointer.=C2=A0 Noted.
>
>=C2=A0 =C2=A0 =C2=A0It is about Bluetooth.=C2=A0 Should be submitted to= Bluetooth SIG.
>
>=C2=A0 =C2=A0 =C2=A0I might stay something stupid here again... si I wo= nt say it :-)
>
>=C2=A0 =C2=A0 =C2=A0 >> I would not oppose if that Authentication= MEssage had a
>=C2=A0 =C2=A0 =C2=A0 >> specification in clear.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > The above plus Adam's draft will get you = there.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>> These messages are broadcasted as Ada= m mentioned in his 'flying
>=C2=A0 =C2=A0 =C2=A0 >>> DRIP' comments at the beginning.<= br> >=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> Thank you for the reminder.=C2=A0 I looke= d again at the 'flying DRIP'
>=C2=A0 =C2=A0 =C2=A0 >> presentation during the WG meeting, and a= t the related draft.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/meeting/108/materials/slides-108-= drip-authentication-formats
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> and draft-wiethuechter-drip-auth-01
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> During the presentation, the slide clearl= y shows on slide 8 that a
>=C2=A0 =C2=A0 =C2=A0 >> Bluetooth header immediately precedes an = Open Drone ID message.
>=C2=A0 =C2=A0 =C2=A0 >> There is no IP header in that slide.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > That is right.=C2=A0 No IP.=C2=A0 No room for= it.=C2=A0 No justification for it. It
>=C2=A0 =C2=A0 =C2=A0 > is all RLOS only.
>
>=C2=A0 =C2=A0 =C2=A0I might say something stupid here: no IP?=C2=A0 No = IETF.
>
>=C2=A0 =C2=A0 =C2=A0 >> In the draft, there is similar discussion= tightly related to
>=C2=A0 =C2=A0 =C2=A0 >> Bluetooth and without IP.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> But if we are to have an independence of = Bluetooth, and use a
>=C2=A0 =C2=A0 =C2=A0 >> networking layer such as IP, then the que= stion of the use of an
>=C2=A0 =C2=A0 =C2=A0 >> authentication header is made differently= .
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Again what is the justification for adding IP= multicast?
>
>=C2=A0 =C2=A0 =C2=A0I would not be afraid of IP multicast like the mult= icast we know for
>=C2=A0 =C2=A0 =C2=A0video delivery.=C2=A0 It is IP multicast because IP= is IPv6 and IPv6 has no
>=C2=A0 =C2=A0 =C2=A0broadcast.
>
>=C2=A0 =C2=A0 =C2=A0_If_ there is agreement that DRIP should be with IP= (Internet Protocol).
>
>=C2=A0 =C2=A0 =C2=A0We know that the drone identification should be bro= adcasted (like in TV
>=C2=A0 =C2=A0 =C2=A0broadcast).=C2=A0 In IPv4 there is a mechanism to i= mplement such TV-broadcast
>=C2=A0 =C2=A0 =C2=A0concept.=C2=A0 It is called IPv4 broadcast.=C2=A0 T= hat broadcast is sent to a
>=C2=A0 =C2=A0 =C2=A0dedicated address (like 255.255.255.255 which is al= l Internet, or like
>=C2=A0 =C2=A0 =C2=A0195.212.142.255 which is all computers in a particu= lar subnet).=C2=A0 In IPv6
>=C2=A0 =C2=A0 =C2=A0such broadcast concept does not exist.=C2=A0 Rather= , it's called 'multicast'
>=C2=A0 =C2=A0 =C2=A0and, as opposed to IPv4, it has a mandatory and vol= untary join/leave
>=C2=A0 =C2=A0 =C2=A0mechanism.
>
>=C2=A0 =C2=A0 =C2=A0I name that IPv6 multicast simply IP multicast, bec= ause IPv4 should not
>=C2=A0 =C2=A0 =C2=A0be used as basis for any new work at IETF.
>
>=C2=A0 =C2=A0 =C2=A0On such an IP multicast perspective for DRIP, one w= ould have to come up
>=C2=A0 =C2=A0 =C2=A0with an architecture for joining and leaving that m= akes it easy to use
>=C2=A0 =C2=A0 =C2=A0by authorities, mandatory to implement, is secure e= nough (security and
>=C2=A0 =C2=A0 =C2=A0multicast is not that easy), etc.
>
>=C2=A0 =C2=A0 =C2=A0 > Where do you see these messages going beyond = the RF Line Of Sight?
>
>=C2=A0 =C2=A0 =C2=A0True.
>
>=C2=A0 =C2=A0 =C2=A0But one would not want all BT5 devices (like my wat= ch or earphones)
>=C2=A0 =C2=A0 =C2=A0around a drone's sight to be awaken by its iden= tification beacons,
>=C2=A0 =C2=A0 =C2=A0right?=C2=A0 Only those devices who have voluntaril= y subscribed to that
>=C2=A0 =C2=A0 =C2=A0multicast group would be awaken.
>
>
>=C2=A0 =C2=A0 =C2=A0 >> The authentication header would be an IP = Authentication Header.
>=C2=A0 =C2=A0 =C2=A0 >> This AH would be somehow re-used and exte= nded where necessary for
>=C2=A0 =C2=A0 =C2=A0 >> DRIP purposes.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>> Now later I expect us to move on to N= etwork Remote ID and Command
>=C2=A0 =C2=A0 =C2=A0 >>> and Control (C2).
>=C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 >>> Most C2 (e.g. Mavlink) is directly ov= er the MAC, but there is a
>=C2=A0 =C2=A0 =C2=A0 >>> method to run it over UDP (I forget t= he UDP port commonly
>=C2=A0 =C2=A0 =C2=A0 >>> used...). AX Enterprize has done this= using HIP so the UA starts
>=C2=A0 =C2=A0 =C2=A0 >>> with WiFi over the launch point, tran= sitions to LTE, and on
>=C2=A0 =C2=A0 =C2=A0 >>> return back to WiFi.
>=C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 >>> Network Remote ID can work either dir= ectly from the UA, or via
>=C2=A0 =C2=A0 =C2=A0 >>> C2 information to the GCS, from the G= CS.=C2=A0 In either case, IP is
>=C2=A0 =C2=A0 =C2=A0 >>> assumed. This will probably be done v= ia UDP.=C2=A0 From the UA,
>=C2=A0 =C2=A0 =C2=A0 >>> mobility will be important; from the = GCS nice to have (most GCS
>=C2=A0 =C2=A0 =C2=A0 >>> will be stable location).=C2=A0 As UD= P to a fixed Net-SP, DTLS 1.3 is
>=C2=A0 =C2=A0 =C2=A0 >>> a viable alternative to HIP.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> I will have to look closer at HIP again := -) and see how it could
>=C2=A0 =C2=A0 =C2=A0 >> be made to work with DRIP and IP.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Stu, Adam, Andrei, and I see HIP for where th= ere is pairwise
>=C2=A0 =C2=A0 =C2=A0 > communication with potentially both ends mobi= le and using multiple
>=C2=A0 =C2=A0 =C2=A0 > interfaces.=C2=A0 Once you have that use case= , be consistent and use it
>=C2=A0 =C2=A0 =C2=A0 > for simpler situations.
>
>=C2=A0 =C2=A0 =C2=A0I wanted to ask whether using a Host Identity that = is cryptographically
>=C2=A0 =C2=A0 =C2=A0generated is sufficient for authorities to trust a = drone upon reception
>=C2=A0 =C2=A0 =C2=A0of one DRIP identification packet, or maybe am addi= tional roundrip (a
>=C2=A0 =C2=A0 =C2=A0ping, a request-response) would still be needed fro= m ground officer to
>=C2=A0 =C2=A0 =C2=A0drone to make sure it's the right drone who rep= lies?=C2=A0 Or maybe a full
>=C2=A0 =C2=A0 =C2=A0Diffie-Hellman exchange is needed?
>
>=C2=A0 =C2=A0 =C2=A0Alex
>
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> Alex
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 >>>>
>=C2=A0 =C2=A0 =C2=A0 >>>> Alex
>=C2=A0 =C2=A0 =C2=A0 >>>>
>=C2=A0 =C2=A0 =C2=A0 >>>> as
>=C2=A0 =C2=A0 =C2=A0 >>>>> it is specified in ASTM F3411= , which most of the regulators
>=C2=A0 =C2=A0 =C2=A0 >>>>> are dubbing as an approved te= chnical means of regulatory
>=C2=A0 =C2=A0 =C2=A0 >>>>> compliance.
>=C2=A0 =C2=A0 =C2=A0 >>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>> AFAIK, no one runs IP over AD= S-B, which was designed as a
>=C2=A0 =C2=A0 =C2=A0 >>>>> narrowband application specif= ic communications stovepipe,
>=C2=A0 =C2=A0 =C2=A0 >>>>> not a data link supporting hi= gher layer network protocols,
>=C2=A0 =C2=A0 =C2=A0 >>>>> so not great for IP.
>=C2=A0 =C2=A0 =C2=A0 >>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>> More importantly, we have no = "reluctance about the use of...
>=C2=A0 =C2=A0 =C2=A0 >>>>>=C2=A0 IP", which is an e= ntirely separate issue from ADS-B.
>=C2=A0 =C2=A0 =C2=A0 >>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>> On 8/4/2020 9:52 AM, Alexandr= e Petrescu wrote:
>=C2=A0 =C2=A0 =C2=A0 >>>>>> architectural layers disc= ussion...
>=C2=A0 =C2=A0 =C2=A0 >>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>> Le 30/07/2020 =C3=A0 11:4= 9, shuaiizhao(Shuai Zhao) a =C3=A9crit :
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> Just to echo Stu on t= he ADSB, AFAIK, ADSB will=C2=A0 not be
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> feasible for most of = the drones mostly due to SwaP,
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> commercial drones mig= ht be exception.
>=C2=A0 =C2=A0 =C2=A0 >>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>> It might be that ADS-B mi= ght be forbidden in drones on
>=C2=A0 =C2=A0 =C2=A0 >>>>>> Earth, but how about the = drones on Mars? ('NASA Mars
>=C2=A0 =C2=A0 =C2=A0 >>>>>> helicopters', or ESA = too).=C2=A0 On Mars there would be much
>=C2=A0 =C2=A0 =C2=A0 >>>>>> less such drones, so less= risk of interference.
>=C2=A0 =C2=A0 =C2=A0 >>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>> With such a system (ADS-B= under IP) one could re-use DTN
>=C2=A0 =C2=A0 =C2=A0 >>>>>> (Delay Tolerant Networkin= g) between planets, and so
>=C2=A0 =C2=A0 =C2=A0 >>>>>> identify drones even on M= ars.
>=C2=A0 =C2=A0 =C2=A0 >>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>> But if we have reluctance= about the use of ADS-B, and thus
>=C2=A0 =C2=A0 =C2=A0 >>>>>> of IP, and we recommend B= luetooth-without-IP to identify
>=C2=A0 =C2=A0 =C2=A0 >>>>>> drones, then we might bec= ome too dependent on it?
>=C2=A0 =C2=A0 =C2=A0 >>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>> (do not get me wrong, I d= o like Bluetooth, but I like many
>=C2=A0 =C2=A0 =C2=A0 >>>>>> other things together wit= h Bluetooth).
>=C2=A0 =C2=A0 =C2=A0 >>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>> Alex
>=C2=A0 =C2=A0 =C2=A0 >>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> Best,
>=C2=A0 =C2=A0 =C2=A0 >>>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> Shuai Zhao
>=C2=A0 =C2=A0 =C2=A0 >>>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> *From: *Tm-rid <tm-rid-bounces@i= etf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:tm-rid-bounces@ietf.org>> on behalf of
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> "Stuart W. Card&= quot; <st= u.card@axenterprize.com
>=C2=A0 =C2=A0 =C2=A0<mailto:stu.card@axenterprize.com>> *Date:
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> *Wednesday, July 29, = 2020 at 19:46 *To:
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> *"tm-rid@ietf.org <mailto:tm-rid@ietf.org>&quo= t;
>=C2=A0 =C2=A0 =C2=A0<tm-rid@ietf.org <mailto:tm-rid@ietf.org>> *Subject: *[Drip]
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> ADSB (was: Review of = draft-drip-arch-02 w.r.t. RFC6973,
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> RFC8280 and other)(In= ternet mail)
>=C2=A0 =C2=A0 =C2=A0 >>>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> Sorry for the slow re= ply.
>=C2=A0 =C2=A0 =C2=A0 >>>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> ADS-B is gradually be= ing mandated for essentially all
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> manned aircraft.
>=C2=A0 =C2=A0 =C2=A0 >>>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> ADSB-In and ADSB-Out = are mandated for airliners: -In
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> gives their pilots >=C2=A0 =C2=A0 =C2=A0 >>>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> some Situational Awar= eness (SA) of other aircraft; -Out
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> gives other
>=C2=A0 =C2=A0 =C2=A0 >>>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> pilots SA of the airl= iners.
>=C2=A0 =C2=A0 =C2=A0 >>>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> "ADSB-Out" = is mandated even for small general aviation
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> aircraft: it does
>=C2=A0 =C2=A0 =C2=A0 >>>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> not directly benefit = the pilots of those aircraft; but
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> by providing SA
>=C2=A0 =C2=A0 =C2=A0 >>>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> to others, it indirec= tly benefits all.
>=C2=A0 =C2=A0 =C2=A0 >>>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> ADSB is _not_ going t= o be deployed on large numbers of
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> small UAS as it
>=C2=A0 =C2=A0 =C2=A0 >>>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> would overwhelm the l= imited bandwidth available at those
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> lower radio
>=C2=A0 =C2=A0 =C2=A0 >>>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> frequencies (which pr= opagate long ranges). In fact, it
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> is expected to be
>=C2=A0 =C2=A0 =C2=A0 >>>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> explicitly prohibited= in the US per the FAA NPRM; I
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> suspect most of the >=C2=A0 =C2=A0 =C2=A0 >>>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> rest of the world wil= l do likewise.
>=C2=A0 =C2=A0 =C2=A0 >>>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> ADSB is also altogeth= er insecure.
>=C2=A0 =C2=A0 =C2=A0 >>>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> On 7/9/2020 3:02 AM, = Alexandre Petrescu wrote:
>=C2=A0 =C2=A0 =C2=A0 >>>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> ...
>=C2=A0 =C2=A0 =C2=A0 >>>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> They call it "AD= S-B Receivers" (Automatic Dependent
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> Surveillance -
>=C2=A0 =C2=A0 =C2=A0 >>>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> Broadcast).
>=C2=A0 =C2=A0 =C2=A0 >>>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> I wouuld like to ask = if there is a packet dump available
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> showing such
>=C2=A0 =C2=A0 =C2=A0 >>>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> presence data form pl= anes?=C2=A0 Maybe wireshark already
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> supports it, maybe >=C2=A0 =C2=A0 =C2=A0 >>>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> it even dissects it..= .
>=C2=A0 =C2=A0 =C2=A0 >>>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> --
>=C2=A0 =C2=A0 =C2=A0 >>>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> ---------------------= --------------------
>=C2=A0 =C2=A0 =C2=A0 >>>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> Stuart W. Card, PhD, = Principal Engineer
>=C2=A0 =C2=A0 =C2=A0 >>>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> AX Enterprize, LLC = www.axenterprize.com
>=C2=A0 =C2=A0 =C2=A0<http://www.axenterprize.com>
>=C2=A0 =C2=A0 =C2=A0 >>>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> 4947 Commercial Drive= , Yorkville NY 13495
>=C2=A0 =C2=A0 =C2=A0 >>>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>
>=C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 >>> -- Standard Robert Moskowitz Owner HT= T Consulting C:248-219-2059
>=C2=A0 =C2=A0 =C2=A0 >>> F:248-968-2824 E:rgm@labs.htt-consult.com<= br> >=C2=A0 =C2=A0 =C2=A0<mailto:E%3Argm@labs.htt-consult.com>
>=C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 >>> There's no limit to what can be a= ccomplished if it doesn't matter
>=C2=A0 =C2=A0 =C2=A0 >>> who gets the credit
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > -- Standard Robert Moskowitz Owner HTT Consul= ting C:248-219-2059
>=C2=A0 =C2=A0 =C2=A0 > F:248-968-2824 E:rgm@labs.htt-consult.com
>=C2=A0 =C2=A0 =C2=A0<mailto:E%3Argm@labs.htt-consult.com>
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > There's no limit to what can be accomplis= hed if it doesn't matter
>=C2=A0 =C2=A0 =C2=A0 > who gets the credit
>
>=C2=A0 =C2=A0 =C2=A0--
>=C2=A0 =C2=A0 =C2=A0Tm-rid mailing list
>=C2=A0 =C2=A0 =C2=A0Tm-rid@ietf.org <mailto:Tm-rid@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/lis= tinfo/tm-rid
>
--00000000000025686c05ac2245f5-- From nobody Wed Aug 5 07:36:32 2020 Return-Path: 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 18C7B3A0A2E for ; Wed, 5 Aug 2020 07:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.671 X-Spam-Level: X-Spam-Status: No, score=0.671 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 H__kYAhnqySl for ; Wed, 5 Aug 2020 07:36:29 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 ACDCD3A077C for ; Wed, 5 Aug 2020 07:36:28 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 075EaRmV028871; Wed, 5 Aug 2020 16:36:27 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 29E16200BB7; Wed, 5 Aug 2020 16:36:27 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1B176200B42; Wed, 5 Aug 2020 16:36:27 +0200 (CEST) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 075EaR9e010937; Wed, 5 Aug 2020 16:36:27 +0200 To: Robert Moskowitz , tm-rid@ietf.org References: <1bebf5b1-1fa5-6902-5bb7-9ec3582e6d9a@andersdotter.cc> <3c632ce9-115d-11f5-ee33-bfabd4973522@labs.htt-consult.com> <7ddd9a2f-23ba-dd82-8cfb-1d2974969e67@gmail.com> <61511ef6-5b9b-5b62-f922-d32b994a35b9@gmail.com> <6b217b3b-7d06-ffbd-2de1-62e78a3cbf60@labs.htt-consult.com> From: Alexandre Petrescu Message-ID: <14243cb2-cb10-effd-e46a-29a83a20580d@gmail.com> Date: Wed, 5 Aug 2020 16:36:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <6b217b3b-7d06-ffbd-2de1-62e78a3cbf60@labs.htt-consult.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: [Drip] ASTM on UDP/IP - an (im)possibility X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 14:36:30 -0000 Le 05/08/2020 à 16:07, Robert Moskowitz a écrit : [...] > But as Stu just said, we deal with the hand dealt.  We cannot change the > ASTM messages from the outside, only work within them and then add other > communications to the UAS ecosystem. Maybe the UAS ecosystem also looks at the use of IP in the future. Or maybe not. Maybe UAS ecosystem would consider to carry ASTM messages as UDP payload on IP? Maybe request new port number from IANA for DRIP, let's say next in sequence from https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml An ASTM message on UDP/IP could look like below. If carried over Bluetooth it would add a preceding header different than when carried over 802.15.16t (the 802.16 for NB-IoT). IPv6 Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP Header 0 7 8 15 16 23 24 31 +--------+--------+--------+--------+ | Source | Destination | | Port | Port | +--------+--------+--------+--------+ | | | | Length | Checksum | +--------+--------+--------+--------+ ASTM message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+-----------------------------------------------+ | Auth Header | | +---------------+ ASTM Authentication Headers +---------------+ | | | +-----------------------------------------------+ | | | | | | | | Authentication Data / Signature | | | | | | | +---------------------------------------------------------------+ Alex From nobody Wed Aug 5 07:42:02 2020 Return-Path: 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 BEB563A0A80 for ; Wed, 5 Aug 2020 07:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, 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 DCD1FX6_3U3Y for ; Wed, 5 Aug 2020 07:41:58 -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 D0AB13A0A74 for ; Wed, 5 Aug 2020 07:41:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 01D3D62422; Wed, 5 Aug 2020 10:41:57 -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 VKt1NTke7sFj; Wed, 5 Aug 2020 10:41:49 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (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 87C5A62416; Wed, 5 Aug 2020 10:41:49 -0400 (EDT) To: Alexandre Petrescu , tm-rid@ietf.org References: <1bebf5b1-1fa5-6902-5bb7-9ec3582e6d9a@andersdotter.cc> <3c632ce9-115d-11f5-ee33-bfabd4973522@labs.htt-consult.com> <7ddd9a2f-23ba-dd82-8cfb-1d2974969e67@gmail.com> <61511ef6-5b9b-5b62-f922-d32b994a35b9@gmail.com> <6b217b3b-7d06-ffbd-2de1-62e78a3cbf60@labs.htt-consult.com> <14243cb2-cb10-effd-e46a-29a83a20580d@gmail.com> From: Robert Moskowitz Message-ID: Date: Wed, 5 Aug 2020 10:41:42 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <14243cb2-cb10-effd-e46a-29a83a20580d@gmail.com> Content-Type: multipart/alternative; boundary="------------9D997F43AB7D9D9E18C63196" Content-Language: en-US Archived-At: Subject: Re: [Drip] ASTM on UDP/IP - an (im)possibility X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 14:42:01 -0000 This is a multi-part message in MIME format. --------------9D997F43AB7D9D9E18C63196 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 8/5/20 10:36 AM, Alexandre Petrescu wrote: > > > > Le 05/08/2020 à 16:07, Robert Moskowitz a écrit : > [...] >> But as Stu just said, we deal with the hand dealt.  We cannot change >> the ASTM messages from the outside, only work within them and then >> add other communications to the UAS ecosystem. > > Maybe the UAS ecosystem also looks at the use of IP in the future.  Or > maybe not. Please see: draft-moskowitz-drip-secure-nrid-c2 this is Network Remote ID.  ASTM F3411 assumes that only the data model of the messages will be used for Network Remote ID, but there is madness and proprietary products.  I leverage the Broadcast message formats for the nrid portion of this draft. I would be interested in working with others on expanding the draft and getting testing going... > > Maybe UAS ecosystem would consider to carry ASTM messages as UDP payload > on IP?  Maybe request new port number from IANA for DRIP, let's say next > in sequence from > https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml > > > An ASTM message on UDP/IP could look like below. > If carried over Bluetooth it would add a preceding header different > than when carried over 802.15.16t (the 802.16 for NB-IoT). > > >    IPv6 Header > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >    |Version| Traffic Class |           Flow Label | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >    |         Payload Length        |  Next Header  |   Hop Limit | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >    | | >    + + >    | | >    +                         Source Address + >    | | >    + + >    | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >    | | >    + + >    | | >    +                      Destination Address + >    | | >    + + >    | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >    UDP Header >                 0      7 8     15 16    23 24    31 >                  +--------+--------+--------+--------+ >                  |     Source      |   Destination   | >                  |      Port       |      Port       | >                  +--------+--------+--------+--------+ >                  |                 |                 | >                  |     Length      |    Checksum     | >                  +--------+--------+--------+--------+ > >    ASTM message >    0                   1                   2                   3 >    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +---------------+-----------------------------------------------+ >    |  Auth Header  | | >    +---------------+  ASTM Authentication Headers +---------------+ >    |                                               | | >    +-----------------------------------------------+ | >    | | >    | | >    | | >    |                Authentication Data / Signature | >    | | >    | | >    | | > +---------------------------------------------------------------+ > > Alex > -- 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 --------------9D997F43AB7D9D9E18C63196 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 8/5/20 10:36 AM, Alexandre Petrescu wrote:



Le 05/08/2020 à 16:07, Robert Moskowitz a écrit :
[...]
But as Stu just said, we deal with the hand dealt.  We cannot change the ASTM messages from the outside, only work within them and then add other communications to the UAS ecosystem.

Maybe the UAS ecosystem also looks at the use of IP in the future.  Or
maybe not.

Please see:

draft-moskowitz-drip-secure-nrid-c2

this is Network Remote ID.  ASTM F3411 assumes that only the data model of the messages will be used for Network Remote ID, but there is madness and proprietary products.  I leverage the Broadcast message formats for the nrid portion of this draft.

I would be interested in working with others on expanding the draft and getting testing going...


Maybe UAS ecosystem would consider to carry ASTM messages as UDP payload
on IP?  Maybe request new port number from IANA for DRIP, let's say next
in sequence from
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

An ASTM message on UDP/IP could look like below.
If carried over Bluetooth it would add a preceding header different than when carried over 802.15.16t (the 802.16 for NB-IoT).


   IPv6 Header
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version| Traffic Class |           Flow Label                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Payload Length        |  Next Header  |   Hop Limit   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                         Source Address                        +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                      Destination Address                      +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   UDP Header
                0      7 8     15 16    23 24    31
                 +--------+--------+--------+--------+
                 |     Source      |   Destination   |
                 |      Port       |      Port       |
                 +--------+--------+--------+--------+
                 |                 |                 |
                 |     Length      |    Checksum     |
                 +--------+--------+--------+--------+

   ASTM message
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +---------------+-----------------------------------------------+
   |  Auth Header  |                                               |
   +---------------+  ASTM Authentication Headers  +---------------+
   |                                               |               |
   +-----------------------------------------------+               |
   |                                                               |
   |                                                               |
   |                                                               |
   |                Authentication Data / Signature                |
   |                                                               |
   |                                                               |
   |                                                               |
   +---------------------------------------------------------------+

Alex


--
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
--------------9D997F43AB7D9D9E18C63196-- From nobody Wed Aug 5 07:49:10 2020 Return-Path: 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 1ABB13A0982 for ; Wed, 5 Aug 2020 07:49:08 -0700 (PDT) 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=axenterprize.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 twKqpUuxIprM for ; Wed, 5 Aug 2020 07:49:06 -0700 (PDT) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFFB23A0A81 for ; Wed, 5 Aug 2020 07:49:05 -0700 (PDT) Received: by mail-ej1-x62f.google.com with SMTP id d6so32863638ejr.5 for ; Wed, 05 Aug 2020 07:49:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axenterprize.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=830zbeunJ6zHx7PkdxvFHjP0cXcLmQEhBfB0GUjfJms=; b=Oarb6pQD+H7pkPORwaNLM/punYNGXyG8xVTgRGBizF0Zr/kdgCFUD2hfhTxr74V3hT cw1b5crsvyTVapp9y0rjxyolG016OaHHnwMlHUzgwpvBb+EWjj1EtTrUmJne399fh8xR rtfPsMm7dx8YsWeENtaUB8D/d0T0bicfp5bBU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=830zbeunJ6zHx7PkdxvFHjP0cXcLmQEhBfB0GUjfJms=; b=KpJRDXgvR0VAB/5CO7vVXoSDfhrfbwqtsqdje38va5X0qq1qmjVBrwp/334POrbU1M o0CNSb+kVydu+lH9A+VWAGgumpbZH08U0CGAXg9Fyz1LN8IaqrT1VeQmDzwfPYE83FGY EKJrch8XhBVw4Kb/L9NBL34I8ZSBdArve+K06MR+BMXzE8D6VAgnkb4eque4b42jHSWK Bwkuvb8JpL2ii2R4weDFjQx9W+/ryfIm4Rb9P+qtCkGDghK8tOnHxGzYJp4HucbfkSS7 jY/0NH3X6D2imBeagfMGPUaLC2UH+tIgJxBNS3VAGzrAMbDVIX5FwDajydKBpxep3wcs zmKw== X-Gm-Message-State: AOAM532VnHugWPLsI84K0uaS8H4a8/9sMsZ+69EDpp3kyUzKxesQlxMJ kmHDusx+byswBJ6zsvje8csBdoko2NQOJ1Bk7rSuvw== X-Google-Smtp-Source: ABdhPJwNOmL10g/mEpB4ppYSwbasJeRSusoBKZDZa1wjRXQ6cyFTok4pv43Q4EbU1M5+bKj2ha3DOgkVFMpTf77gvvk= X-Received: by 2002:a17:906:fa0b:: with SMTP id lo11mr3680720ejb.235.1596638944155; Wed, 05 Aug 2020 07:49:04 -0700 (PDT) MIME-Version: 1.0 References: <1bebf5b1-1fa5-6902-5bb7-9ec3582e6d9a@andersdotter.cc> <3c632ce9-115d-11f5-ee33-bfabd4973522@labs.htt-consult.com> <7ddd9a2f-23ba-dd82-8cfb-1d2974969e67@gmail.com> <61511ef6-5b9b-5b62-f922-d32b994a35b9@gmail.com> <6b217b3b-7d06-ffbd-2de1-62e78a3cbf60@labs.htt-consult.com> <14243cb2-cb10-effd-e46a-29a83a20580d@gmail.com> In-Reply-To: <14243cb2-cb10-effd-e46a-29a83a20580d@gmail.com> From: "Card, Stu" Date: Wed, 5 Aug 2020 10:48:46 -0400 Message-ID: To: Alexandre Petrescu Cc: Robert Moskowitz , tm-rid@ietf.org Content-Type: multipart/alternative; boundary="00000000000019f4e405ac227980" Archived-At: Subject: Re: [Drip] ASTM on UDP/IP - an (im)possibility X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 14:49:08 -0000 --00000000000019f4e405ac227980 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Now you're talking! :-) Yes, UDP/IP encapsulation of Broadcast RID messages, over media other than Bluetooth, is an attractive possibility, which goes beyond but does not conflict with ASTM F3411. Also, UDP/IP, TCP/IP, HTTPS/TCP/IP, etc. encapsulations of Broadcast RID message structures (not merely data dictionary elements) as a means of transporting Network RID, comprise another attractive possibility, which probably conflicts with the initial ASTM F3411-19 version but there will be future revisions that we may be able to influence. On Wed, Aug 5, 2020 at 10:36 AM Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > > > > Le 05/08/2020 =C3=A0 16:07, Robert Moskowitz a =C3=A9crit : > [...] > > But as Stu just said, we deal with the hand dealt. We cannot change th= e > > ASTM messages from the outside, only work within them and then add othe= r > > communications to the UAS ecosystem. > > Maybe the UAS ecosystem also looks at the use of IP in the future. Or > maybe not. > > Maybe UAS ecosystem would consider to carry ASTM messages as UDP payload > on IP? Maybe request new port number from IANA for DRIP, let's say next > in sequence from > > https://www.iana.org/assignments/service-names-port-numbers/service-names= -port-numbers.xhtml > > An ASTM message on UDP/IP could look like below. > If carried over Bluetooth it would add a preceding header different than > when carried over 802.15.16t (the 802.16 for NB-IoT). > > > IPv6 Header > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Version| Traffic Class | Flow Label | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload Length | Next Header | Hop Limit | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Source Address + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Destination Address + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > UDP Header > 0 7 8 15 16 23 24 31 > +--------+--------+--------+--------+ > | Source | Destination | > | Port | Port | > +--------+--------+--------+--------+ > | | | > | Length | Checksum | > +--------+--------+--------+--------+ > > ASTM message > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +---------------+-----------------------------------------------+ > | Auth Header | | > +---------------+ ASTM Authentication Headers +---------------+ > | | | > +-----------------------------------------------+ | > | | > | | > | | > | Authentication Data / Signature | > | | > | | > | | > +---------------------------------------------------------------+ > > Alex > > -- > Tm-rid mailing list > Tm-rid@ietf.org > https://www.ietf.org/mailman/listinfo/tm-rid > --00000000000019f4e405ac227980 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+Tm93IHlvdSYjMzk7cmUgdGFsa2luZyEgOi0pPGRpdj48YnI+PGRpdj5Z ZXMsIFVEUC9JUCBlbmNhcHN1bGF0aW9uIG9mIEJyb2FkY2FzdCBSSUQgbWVzc2FnZXMsIG92ZXIg bWVkaWEgb3RoZXIgdGhhbiBCbHVldG9vdGgsIGlzIGFuIGF0dHJhY3RpdmUgcG9zc2liaWxpdHks IHdoaWNoIGdvZXMgYmV5b25kIGJ1dCBkb2VzIG5vdCBjb25mbGljdCB3aXRoIEFTVE0gRjM0MTEu PC9kaXY+PGRpdj48YnI+PC9kaXY+PC9kaXY+PGRpdj5BbHNvLCBVRFAvSVAsIFRDUC9JUCwgSFRU UFMvVENQL0lQLCBldGMuIGVuY2Fwc3VsYXRpb25zIG9mIEJyb2FkY2FzdCBSSUQgbWVzc2FnZSBz dHJ1Y3R1cmVzIChub3QgbWVyZWx5IGRhdGEgZGljdGlvbmFyeSBlbGVtZW50cykgYXMgYSBtZWFu cyBvZiB0cmFuc3BvcnRpbmcgTmV0d29yayBSSUQsIGNvbXByaXNlIGFub3RoZXIgYXR0cmFjdGl2 ZSBwb3NzaWJpbGl0eSwgd2hpY2ggcHJvYmFibHkgY29uZmxpY3RzIHdpdGggdGhlIGluaXRpYWwg QVNUTSBGMzQxMS0xOSB2ZXJzaW9uIGJ1dCB0aGVyZSB3aWxsIGJlIGZ1dHVyZSByZXZpc2lvbnMg dGhhdCB3ZSBtYXkgYmUgYWJsZSB0byBpbmZsdWVuY2UuPC9kaXY+PGRpdj48YnI+PC9kaXY+PC9k aXY+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj48ZGl2IGRpcj0ibHRyIiBjbGFzcz0iZ21h aWxfYXR0ciI+T24gV2VkLCBBdWcgNSwgMjAyMCBhdCAxMDozNiBBTSBBbGV4YW5kcmUgUGV0cmVz Y3UgJmx0OzxhIGhyZWY9Im1haWx0bzphbGV4YW5kcmUucGV0cmVzY3VAZ21haWwuY29tIj5hbGV4 YW5kcmUucGV0cmVzY3VAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPjwvZGl2PjxibG9ja3F1 b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDti b3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij48 YnI+DQo8YnI+DQo8YnI+DQpMZSAwNS8wOC8yMDIwIMOgIDE2OjA3LCBSb2JlcnQgTW9za293aXR6 IGEgw6ljcml0wqA6PGJyPg0KWy4uLl08YnI+DQomZ3Q7IEJ1dCBhcyBTdHUganVzdCBzYWlkLCB3 ZSBkZWFsIHdpdGggdGhlIGhhbmQgZGVhbHQuwqAgV2UgY2Fubm90IGNoYW5nZSB0aGUgPGJyPg0K Jmd0OyBBU1RNIG1lc3NhZ2VzIGZyb20gdGhlIG91dHNpZGUsIG9ubHkgd29yayB3aXRoaW4gdGhl bSBhbmQgdGhlbiBhZGQgb3RoZXIgPGJyPg0KJmd0OyBjb21tdW5pY2F0aW9ucyB0byB0aGUgVUFT IGVjb3N5c3RlbS48YnI+DQo8YnI+DQpNYXliZSB0aGUgVUFTIGVjb3N5c3RlbSBhbHNvIGxvb2tz IGF0IHRoZSB1c2Ugb2YgSVAgaW4gdGhlIGZ1dHVyZS7CoCBPcjxicj4NCm1heWJlIG5vdC48YnI+ DQo8YnI+DQpNYXliZSBVQVMgZWNvc3lzdGVtIHdvdWxkIGNvbnNpZGVyIHRvIGNhcnJ5IEFTVE0g bWVzc2FnZXMgYXMgVURQIHBheWxvYWQ8YnI+DQpvbiBJUD/CoCBNYXliZSByZXF1ZXN0IG5ldyBw b3J0IG51bWJlciBmcm9tIElBTkEgZm9yIERSSVAsIGxldCYjMzk7cyBzYXkgbmV4dDxicj4NCmlu IHNlcXVlbmNlIGZyb208YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25t ZW50cy9zZXJ2aWNlLW5hbWVzLXBvcnQtbnVtYmVycy9zZXJ2aWNlLW5hbWVzLXBvcnQtbnVtYmVy cy54aHRtbCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWFu YS5vcmcvYXNzaWdubWVudHMvc2VydmljZS1uYW1lcy1wb3J0LW51bWJlcnMvc2VydmljZS1uYW1l cy1wb3J0LW51bWJlcnMueGh0bWw8L2E+PGJyPg0KPGJyPg0KQW4gQVNUTSBtZXNzYWdlIG9uIFVE UC9JUCBjb3VsZCBsb29rIGxpa2UgYmVsb3cuPGJyPg0KSWYgY2FycmllZCBvdmVyIEJsdWV0b290 aCBpdCB3b3VsZCBhZGQgYSBwcmVjZWRpbmcgaGVhZGVyIGRpZmZlcmVudCB0aGFuIDxicj4NCndo ZW4gY2FycmllZCBvdmVyIDgwMi4xNS4xNnQgKHRoZSA4MDIuMTYgZm9yIE5CLUlvVCkuPGJyPg0K PGJyPg0KPGJyPg0KwqAgwqAgSVB2NiBIZWFkZXI8YnI+DQrCoCDCoCArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzxicj4NCsKg IMKgIHxWZXJzaW9ufCBUcmFmZmljIENsYXNzIHzCoCDCoCDCoCDCoCDCoCDCoEZsb3cgTGFiZWzC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAgwqAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8YnI+DQrCoCDC oCB8wqAgwqAgwqAgwqAgwqBQYXlsb2FkIExlbmd0aMKgIMKgIMKgIMKgIHzCoCBOZXh0IEhlYWRl csKgIHzCoCDCoEhvcCBMaW1pdMKgIMKgfDxicj4NCsKgIMKgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPGJyPg0KwqAgwqAg fMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfDxicj4NCsKgIMKgICvCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCs8YnI+DQrCoCDCoCB8wqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgK8KgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgU291cmNlIEFkZHJlc3PCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCArPGJyPg0KwqAgwqAgfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgfDxicj4NCsKgIMKgICvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCs8YnI+DQrCoCDCoCB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqB8PGJyPg0KwqAgwqAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSs8YnI+DQrCoCDCoCB8wqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgK8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgKzxicj4NCsKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoHw8YnI+DQrCoCDCoCArwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgRGVz dGluYXRpb24gQWRkcmVzc8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICs8YnI+DQrC oCDCoCB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAg K8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKzxicj4NCsKgIMKgIHzCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzxi cj4NCjxicj4NCsKgIMKgIFVEUCBIZWFkZXI8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oDDCoCDCoCDCoCA3IDjCoCDCoCDCoDE1IDE2wqAgwqAgMjMgMjTCoCDCoCAzMTxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgICstLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tLSstLS0tLS0t LSs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8wqAgwqAgwqBTb3VyY2XCoCDCoCDC oCB8wqAgwqBEZXN0aW5hdGlvbsKgIMKgfDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IHzCoCDCoCDCoCBQb3J0wqAgwqAgwqAgwqB8wqAgwqAgwqAgUG9ydMKgIMKgIMKgIMKgfDxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICstLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tLSst LS0tLS0tLSs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgfMKgIMKgIMKgTGVuZ3RowqAgwqAgwqAgfMKgIMKgIENoZWNrc3VtwqAg wqAgwqB8PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKy0tLS0tLS0tKy0tLS0tLS0t Ky0tLS0tLS0tKy0tLS0tLS0tKzxicj4NCjxicj4NCsKgIMKgIEFTVE0gbWVzc2FnZTxicj4NCsKg IMKgIDDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoDHCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoDLCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoDM8YnI+DQrCoCDCoCAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDE8 YnI+DQrCoCDCoCArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKzxicj4NCsKgIMKgIHzCoCBBdXRoIEhlYWRlcsKgIHzCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoHw8YnI+DQrCoCDCoCArLS0tLS0tLS0tLS0tLS0tK8KgIEFTVE0gQXV0aGVudGljYXRp b24gSGVhZGVyc8KgICstLS0tLS0tLS0tLS0tLS0rPGJyPg0KwqAgwqAgfMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg fMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfDxicj4NCsKgIMKgICstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHw8YnI+ DQrCoCDCoCB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAg wqAgfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfDxicj4NCsKgIMKgIHzC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCB8wqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgQXV0aGVudGljYXRpb24gRGF0YSAvIFNpZ25hdHVyZcKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHw8YnI+DQrCoCDCoCB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgfDxicj4NCsKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oHw8YnI+DQrCoCDCoCArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tKzxicj4NCjxicj4NCkFsZXg8YnI+DQo8YnI+DQotLSA8YnI+ DQpUbS1yaWQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRtLXJpZEBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPlRtLXJpZEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RtLXJpZCIgcmVsPSJub3JlZmVycmVy IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90 bS1yaWQ8L2E+PGJyPg0KPC9ibG9ja3F1b3RlPjwvZGl2Pg0K --00000000000019f4e405ac227980-- From nobody Wed Aug 5 09:53:46 2020 Return-Path: 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 624BC3A0D39 for ; Wed, 5 Aug 2020 09:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, 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 (2048-bit key) header.d=gmail.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 98u70Vqm_khv for ; Wed, 5 Aug 2020 09:53:42 -0700 (PDT) Received: from mail-vk1-xa2b.google.com (mail-vk1-xa2b.google.com [IPv6:2607:f8b0:4864:20::a2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 680B23A0DAC for ; Wed, 5 Aug 2020 09:53:32 -0700 (PDT) Received: by mail-vk1-xa2b.google.com with SMTP id m18so9981826vkk.7 for ; Wed, 05 Aug 2020 09:53:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=mhMusRkqUOjW487rbQihD4DSY6IIqUE45TxyOhvoddk=; b=r4VUJK9HL2V49UExRTiiaenFQDtpO4nvcwMY35wHJREkbot2Mb7IvEO1aAYDzOA2CT Sx66M7xqc59KXt65Dxg16tPJEValVUkqYdSzVk4V5ky87Do1VQWs6nK2dN9CF+epIH2y 2K6+2Us46QB3Vypfz1/SfXTAsOgklImsCGCl7NSFMfT02RBx6WRzv43/ZU3VCx0avESb 4qRWvEAHd+poXQ6zcsNpX0AGwLvOnNH1xsYqTZUtnncv669tDR5mvsmYWNJJvCcRDmF8 2v98yObKEMMAJSN6DzOPOuk2qzL0Nr5SVeripezNsoSq6RHR6N0h89VkM2Jxr+V+1YKZ gdLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=mhMusRkqUOjW487rbQihD4DSY6IIqUE45TxyOhvoddk=; b=i/hH681l8jQ3WW6agLJRh3Hf3rPNknzxE14D0Z9NHL7sU4DDsI1h4+K3W2MgUVeDl3 Mq3k41d1jyWYrRLPdjML9mMbAWZDd2XWLSdTnNwH2W61vAu5wkfWBnS62IMLkZCgwAfj JHPAensencE5uDCbZkx99x1aKbBM211HqFvQax2rR7PKwLy0tu1/bejxi+SN5X8enU8p 56QVDA9Z+wBT2UusXrq+Im02nvMsDZw+3ZitmxQSlUqyFr4ZJhmpdbKwjVgWxMFCRQvb wML066gIHLg4ovclNX+2iFROrWs2s1xdafOGWEcfQGfyWB6gctPzLDsCrpOFbMu/3VH8 VVSw== X-Gm-Message-State: AOAM531U7x4NRuiGDY1g/4bUENM/tKGUPyPafq3ndTXUpBlnwccgm07u j9xeUHyk1hAMzKlFJf8Vi+7pUTrXEtZhzDGmH4yPVg== X-Google-Smtp-Source: ABdhPJyJwwAm5GwFD45tHaJvcjqRW3y8Kk+P37l6jd4DAyBvRlx+D0ed/vfUtUJL5rTJrTRPoCJVwwv+Lgft+jsjeAU= X-Received: by 2002:a1f:d642:: with SMTP id n63mr3358729vkg.77.1596646411237; Wed, 05 Aug 2020 09:53:31 -0700 (PDT) MIME-Version: 1.0 References: <39C59343-D873-4282-8BD2-A5B6A659B3A0@ietf.org> In-Reply-To: From: Daniel Migault Date: Wed, 5 Aug 2020 12:53:20 -0400 Message-ID: To: tm-rid@ietf.org Content-Type: multipart/alternative; boundary="0000000000002c7ca705ac243622" Archived-At: Subject: [Drip] Fwd: [108all] Final reminder: IETF 108 meeting survey X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 16:53:44 -0000 --0000000000002c7ca705ac243622 Content-Type: text/plain; charset="UTF-8" Hi, Please consider - if not already done - to fill the IETf108 survey below. Yours, Daniel ---------- Forwarded message --------- From: IETF Executive Director Date: Wed, Aug 5, 2020 at 6:30 AM Subject: [108all] Final reminder: IETF 108 meeting survey To: <108all@ietf.org> Thank you very much to the ~230 people who have filled in the IETF 108 meeting survey as this data is crucial to helping us plan future meetings. We could still use another 70 or so responses and so this is a final reminder to please help us by taking a few minutes to complete the survey: https://www.surveymonkey.com/r/T3SL7JF Thanks in advance -- Jay Daley IETF Executive Director exec-director@ietf.org -- 108all mailing list 108all@ietf.org https://www.ietf.org/mailman/listinfo/108all -- Daniel Migault Ericsson -- Daniel Migault Ericsson --0000000000002c7ca705ac243622 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0
=
Please consider - if not already done - to fill the IETf108 = survey below.=C2=A0

Yours,=C2=A0
Daniel

---= ------- Forwarded message ---------
From: IETF Executive Director <<= a href=3D"mailto:exec-director@ietf.org" target=3D"_blank">exec-director@ie= tf.org>
Date: Wed, Aug 5, 2020 at 6:30 AM
Subject: [108= all] Final reminder: IETF 108 meeting survey
To: <108all@ietf.org>

Thank you very much to the ~230 people who have filled in the IETF 108 mee= ting survey as this data is crucial to helping us plan future meetings.=C2= =A0 We could still use another 70 or so responses and so this is a final re= minder to please help us by taking a few minutes to complete the survey:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https:= //www.surveymonkey.com/r/T3SL7JF

Thanks in advance

--
Jay Daley
IETF Executive Director
exec-director@i= etf.org

--
108all mailing list
108all@ietf.org https://www.ietf.org/mailman/listinfo/108all


--
Daniel Migault
E= ricsson


--
Dani= el Migault
Ericsson
--0000000000002c7ca705ac243622-- From nobody Wed Aug 5 15:37:18 2020 Return-Path: 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 2A2573A07E3 for ; Wed, 5 Aug 2020 15:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qNLBQ9o3xo-B for ; Wed, 5 Aug 2020 15:37:15 -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 D61E33A07E7 for ; Wed, 5 Aug 2020 15:37:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 1A6B962434 for ; Wed, 5 Aug 2020 18:37:14 -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 eIR9cmI-QMmG for ; Wed, 5 Aug 2020 18:37:10 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (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 4A2FC62416 for ; Wed, 5 Aug 2020 18:37:10 -0400 (EDT) To: "tm-rid@ietf.org" From: Robert Moskowitz Message-ID: <59b79ec5-8023-85d2-2037-0df100c9e9b4@labs.htt-consult.com> Date: Wed, 5 Aug 2020 18:37:02 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Drip] =?utf-8?q?DRIP_is_mentioned_-_Today=E2=80=99s_Internet_St?= =?utf-8?q?ill_Relies_on_an_ARPANET-Era_Protocol=3A_The_Request_for_Commen?= =?utf-8?q?ts?= X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 22:37:17 -0000 https://spectrum.ieee.org/tech-history/cyberspace/todays-internet-still-relies-on-an-arpanetera-protocol-the-request-for-comments By Steve Crocker.  Author of RFC 1 and a member of this list. From nobody Wed Aug 5 16:11:17 2020 Return-Path: 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 523393A08C7 for ; Wed, 5 Aug 2020 16:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=shinkuro-com.20150623.gappssmtp.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 l9XDJUKOIMZK for ; Wed, 5 Aug 2020 16:11:13 -0700 (PDT) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3AE63A08C1 for ; Wed, 5 Aug 2020 16:11:13 -0700 (PDT) Received: by mail-ej1-x62f.google.com with SMTP id c16so27836585ejx.12 for ; Wed, 05 Aug 2020 16:11:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shinkuro-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=60t7gf+0wDtB+xiaUI6qeffyKDjq0kUM3VjL6JQ4xdk=; b=y/2r821FDAW+RXFpX3jrqFX8CQfCcphGWDIWE+j7RsL//DUOZfhVCXuLb3YVkCbfh5 WDJne/WaW+FWLPY+803ULg13VqjDzxJYGfs13iyeTF9kCEa8HK54Z0GtI6LnXkilMIko 46yMTlQmVUGwjYUf5P9IVdpJZTF1VBObAiBZCBzgtNMvXnBFZ7zUvC/jolbhHEdmw8Qv QsHlKtpTfc5jTs07OrcOOyRk+be6EBY67LSjeJds0eVzS5eCjbeGEsWmY3vPdVZh1tLS MaXORVxS7Mt1riaEDnFVw+JEcrJdXsxlYC4kYBvs5IkKvxUDjLkSGQ5Fz8TvHPjL5MNy O/Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=60t7gf+0wDtB+xiaUI6qeffyKDjq0kUM3VjL6JQ4xdk=; b=dI8wf04c0fiLt7O+K11qt4fQgwlyw93JLPfHoA7M7DSuqugNFX9HZWa8l/Crul8PhC W3V2XhOsShrYZTptp4wadzNUz/TCEIHMqYqvJ0XoY7RwzSJ5ko8rKLlkc80LRv7bEqRX qtyf7adWY879v3HoyZXk6cABJCmcvGc/yQztLJxgi+2MLxC45M6NnglxhzCRm7Z0BGj8 C1TmyQibj3FsqpcfBKthGEfVQU2NdzvnK6s5Md0ZylgfPibCQvSGxVpuMubNBpmhhZYU koSF/IouQt0oX6w3Q0SkrozHziwnnP010SYalTXJJC6mu9Il9+6Hs4bJ25tJ5MCyOQwA aprA== X-Gm-Message-State: AOAM531CYQG9YGd1anrIKChtkxbrUFWGt00lEcngZfQ1NBIPf+RxkHEU ZI4k2JbxSJTjWaOV3LUU69xbqOl5y1XlhBMHF0SrhyBirck= X-Google-Smtp-Source: ABdhPJwbjRzp1Oaj6PCCSko4aTv/if4MyXH9K84In+efpz5vI+H4XHfeVJgW+3K6Ft49v6HJ+/+4l9utlxiAdZihB3c= X-Received: by 2002:a17:906:4dd4:: with SMTP id f20mr1727376ejw.170.1596669072011; Wed, 05 Aug 2020 16:11:12 -0700 (PDT) MIME-Version: 1.0 References: <59b79ec5-8023-85d2-2037-0df100c9e9b4@labs.htt-consult.com> In-Reply-To: <59b79ec5-8023-85d2-2037-0df100c9e9b4@labs.htt-consult.com> From: Steve Crocker Date: Wed, 5 Aug 2020 19:11:01 -0400 Message-ID: To: Robert Moskowitz Cc: "tm-rid@ietf.org" Content-Type: multipart/alternative; boundary="000000000000dc8a9205ac297caf" Archived-At: Subject: Re: [Drip] =?utf-8?q?DRIP_is_mentioned_-_Today=E2=80=99s_Internet_St?= =?utf-8?q?ill_Relies_on_an_ARPANET-Era_Protocol=3A_The_Request_for_Commen?= =?utf-8?q?ts?= X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 23:11:15 -0000 --000000000000dc8a9205ac297caf Content-Type: text/plain; charset="UTF-8" :) Yes, I thought you'd enjoy the mention of drones. Steve On Wed, Aug 5, 2020 at 6:37 PM Robert Moskowitz wrote: > > https://spectrum.ieee.org/tech-history/cyberspace/todays-internet-still-relies-on-an-arpanetera-protocol-the-request-for-comments > > By Steve Crocker. Author of RFC 1 and a member of this list. > > > -- > Tm-rid mailing list > Tm-rid@ietf.org > https://www.ietf.org/mailman/listinfo/tm-rid > --000000000000dc8a9205ac297caf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
:) Yes, I thought you'd enjoy the mention of drones.
Steve


On Wed, Aug 5, 2020 at 6:37 PM = Robert Moskowitz <rgm@labs.h= tt-consult.com> wrote:
https://spectrum.ieee.org/tech-h= istory/cyberspace/todays-internet-still-relies-on-an-arpanetera-protocol-th= e-request-for-comments

By Steve Crocker.=C2=A0 Author of RFC 1 and a member of this list.


--
Tm-rid mailing list
Tm-rid@ietf.org https://www.ietf.org/mailman/listinfo/tm-rid
--000000000000dc8a9205ac297caf-- From nobody Thu Aug 6 05:31:46 2020 Return-Path: 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 4DE843A0AC6 for ; Thu, 6 Aug 2020 05:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=JzMAdMNW; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=tIz0UVxr 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 KR9Rka60Wy7c for ; Thu, 6 Aug 2020 05:31:43 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB15C3A0ABC for ; Thu, 6 Aug 2020 05:31:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6509; q=dns/txt; s=iport; t=1596717103; x=1597926703; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=J76ozzWudvyznRmRG/fmoR5//AOZqwceCpl8uBNcTiI=; b=JzMAdMNWrtl+wLFsoG1hH/sa7yrC0rowEbVgV+LgO3MJCWlqZ91C3DoF 1+ZOQ/9FHYljm85IbRN3aSxuJEDmBore2N8flug4xl9qELYfb9eyyu3qF UUd8B6B1kiriLCfFIHfnkXKKpxENCKCWVde5+4CN7Lz74ni3r8WkAJ3oE g=; IronPort-PHdr: =?us-ascii?q?9a23=3ArkNR7hRkAm6wgZbax0yj4gQsHdpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQB92J8PJFjenLqaemUmsFst6Ns3EHJZpLUR?= =?us-ascii?q?JNycAbhBcpD8PND0rnZOXrYCo3EIUnNhdl8ni3PFITFJP4YFvf8Way7DgRBw?= =?us-ascii?q?/4cwFyI7e9Fovblc/i0ee09tXaaBlJgzzoZ7R0IV22oAzdu9NQj5FlL/M6yw?= =?us-ascii?q?DCpT1DfOEFyA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DACwDq9ytf/5xdJa1gHQEBAQEJARI?= =?us-ascii?q?BBQUBggqBIy9RB29YLyyENoNGA40oJZN2hGyCUwNVCwEBAQwBARgBDgYCBAE?= =?us-ascii?q?BhEwCF4IVAiQ4EwIDAQELAQEFAQEBAgEGBG2FXAyFcQEBAQEDAQEQER0BASw?= =?us-ascii?q?LAQ8CAQgRAwECJAQDAgICJQsUBgMIAgQBDQUigwQBgX5NAy4BDqkYAoE5iGF?= =?us-ascii?q?2gTKDAQEBBYFKAQ4JgzsYgg4DBoE4gnCDX4IfhCAagUE/gREnDBCCHy4+axk?= =?us-ascii?q?BgVcBAYF/DQmCYTOCLZARgmuGX5xECoJiiGGRLQMeoAFDg3CBHoxYijaUdQI?= =?us-ascii?q?EAgQFAg4BAQWBaiOBV3AVOyoBgj5QFwINjh8MDAsUgzqFFIVCdDcCBgEHAQE?= =?us-ascii?q?DCQF7jx8BAQ?= X-IronPort-AV: E=Sophos;i="5.75,441,1589241600"; d="scan'208,217";a="523063062" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Aug 2020 12:31:17 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 076CVH2K017005 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 6 Aug 2020 12:31:17 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 6 Aug 2020 07:31:17 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 6 Aug 2020 07:31:16 -0500 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 6 Aug 2020 07:31:17 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HVQcsSCwdf99tnZHOxu24umn/Jvj/QRG/MPa5nm3zeSrdC4KeO0EiL/ZTSpnD2XkKLqkKEEfNLDTffEoP5zSSckePAO8SYgeXSMthNxPRK2sZWJqNL9XNb7+BPUl5errXAmZae9uhut6qaNyBwWztoIDNDS9slfBiVdttCLG5CIsVbjFMWu9u6e52J82Mx0vp1Eg63yteLdSdq+alb8RJQh05nSHZQkQVdK/0vcJ/KjkIUAZFhTEAdS3w0ud5C7417VNZ/ZbJL+vi5YiKlgc/541x57EFM64vZC9f9cmlxtARZcLT4aQDL4LXm+5Up22fmpfm5XGsA7KnClTBK3rQw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=J76ozzWudvyznRmRG/fmoR5//AOZqwceCpl8uBNcTiI=; b=N60zUqW9Hlk4sEvJHXF2PXgkbFO1fo4jHvEOHbGASrE3Gfl3yk3GBtC2UBTko9gBMXZYw5uoIRcLKej4K2MXLpHPT1vin2J6ti+T18EK+9d+7w+PPCwSzWO0aTHmhpzS2jNO0xx5didsI6ukXspe/fE+iDaB5Kk5f53e4CFRySbgRpwcGwI4yn7Vxq3fsLprSdH6ZrzWcK3jU+fpTcNm5OHbU5VsSMyyJet0j4qbEX6MztDDY+GZYBQR499Jgm/ICpZfWRA4bAOA71ozrx8A/D/8qz1JeLm2uMvnIBSghAXYIZkTkWQtbHKpvMOvvIHtUa2oIhU7n9ZS/gGir7pygQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=J76ozzWudvyznRmRG/fmoR5//AOZqwceCpl8uBNcTiI=; b=tIz0UVxr6GnIFWAAosXWXAvSOCrOGOtnlwELTxyQjKyPjq8UGRKwThQhhozvl8zyvvbsm/kSy+968ATPRvXQsHIvEcEEx63yC7H/FZ62ZS9ktjyVxUWXcoS5t48uEyFmF7YXYh0Cy7pWNg3Vn0PfY0dIdN9pwTlYuvuBFPAgv7g= Received: from BN6PR11MB1844.namprd11.prod.outlook.com (2603:10b6:404:103::20) by BN8PR11MB3633.namprd11.prod.outlook.com (2603:10b6:408:8a::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.19; Thu, 6 Aug 2020 12:31:14 +0000 Received: from BN6PR11MB1844.namprd11.prod.outlook.com ([fe80::91d2:982a:905b:e502]) by BN6PR11MB1844.namprd11.prod.outlook.com ([fe80::91d2:982a:905b:e502%3]) with mapi id 15.20.3239.023; Thu, 6 Aug 2020 12:31:14 +0000 From: "Eric Vyncke (evyncke)" To: Steve Crocker , Robert Moskowitz CC: "tm-rid@ietf.org" Thread-Topic: =?utf-8?B?W0RyaXBdICBEUklQIGlzIG1lbnRpb25lZCAtIFRvZGF54oCZcyBJbnRlcm5l?= =?utf-8?B?dCBTdGlsbCBSZWxpZXMgb24gYW4gQVJQQU5FVC1FcmEgUHJvdG9jb2w6IFRo?= =?utf-8?Q?e_Request_for_Comments?= Thread-Index: AQHWa33DypdZdbgNMkSLP46wcE7NpKkrJX4A Date: Thu, 6 Aug 2020 12:31:14 +0000 Message-ID: <75FFBA2A-CBB5-4D34-8537-5D53DCE6850C@cisco.com> References: <59b79ec5-8023-85d2-2037-0df100c9e9b4@labs.htt-consult.com> In-Reply-To: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.39.20071300 authentication-results: shinkuro.com; dkim=none (message not signed) header.d=none;shinkuro.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:591f:4906:2004:a15f] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f1b9527e-5dc7-41fb-0807-08d83a049c47 x-ms-traffictypediagnostic: BN8PR11MB3633: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: SmIrR1Ld1tbqVI8kcQpx3VTcXjkJDcfo7wPVnMBQFQatPMlTDe8U9Fvy/8ojSVDlnKWWOLQ+5ou9BFFDSWXbFXy6UGiajJpOcboj5JeIu/KbgEKsj1aa09QfIhYPuz8yVRALfDZUzu0HtAgZkktcrCtPdS9ouLac61zPayW2pNkG1tLCM0A/LTUUtpDEzcEX7xv/DCA11rLPMwpcnJA4i+IFfPtIHCsyqbYmgVD/r6JzHnIWeicvZW9ynt2QyB73Maj/raVPrj46YzAAywqIPSVHG/4dCHVRsIaM3x5uN+3083Lw+jvsHmfnbFKa69V8gq1U4OXMoSFduKQf/hnkDsUsd9xstqEIAv/8rsgdavS+I0V9/ouQhrz8MxOY8d1n6JGRdSGc8bo3hYIMdzm2sQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR11MB1844.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(346002)(39860400002)(376002)(396003)(366004)(91956017)(2906002)(66556008)(66476007)(64756008)(66446008)(8936002)(66574015)(83380400001)(166002)(76116006)(66946007)(5660300002)(6486002)(4326008)(2616005)(110136005)(71200400001)(33656002)(6512007)(478600001)(4744005)(316002)(966005)(53546011)(86362001)(186003)(36756003)(6506007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: TftAfoLjnFWV5XpdrkccYE3b+e1H/7tIpC37ZDrknViswTvkaJtRemaajmNsljRkuzHm6qNdqmTt2cbA1qOqEJ/gmOTK/PHcqJV6r49wRPIGB+MkwXiFqkBWYNDFi3Vf/tet0G9fVx/9mXfTDPyUtIKgLyvb1voXmIY9WqlxmIr2nfYyKGT/HsCZ8tNTWQj3icu/a3kKtELtM5h9g4sTnfaAYf34U57ZpsMycFBe9QA57jEGVhVaQloOh+itKnoT7g9omBtYte5Far7FJO/wLxcUdqKfE+cKAlMDIfRPTRtFr70ey65dSIimF7YtS0+aHKI0h/lz6Iby5hlhtEcJ9IkKnrxClWG/nNH7p12/AxIKTkjXISA1ImCMvjrv0cgbW7KAkCa8Cl1ZDAhHdT4qm/HVQ1KyRL4wC6YLbR534QZgBLUYjkhkmIGd/YXLHV354HAJrBjqTE92C1ZtInkpWzmYCZiQRUebGTUR8QBJweuPWNlJwT4ijG6Jyum7tRzfr1JfU1pKuf5xOvWoZBBTYDiUVhvfkGEyU7X2FdqDMMtalun8B6azHQ3qaU9q8E9DIvtZa7PgR/ibZ/Xo4cSdQZ10UYeW2rli67yadXQLEm/caQcmlDdNP/MRoeBax/63+Cb0PlHEYuStK6MepyVcF6D63YygZHef7963D/4chPZiGj+ZoYGnbYyxKOsfikiX+OZLqQbQIaDqKe0qIlr9bQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_75FFBA2ACBB54D3485375D53DCE6850Cciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN6PR11MB1844.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f1b9527e-5dc7-41fb-0807-08d83a049c47 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Aug 2020 12:31:14.8406 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: a92NwSq3jSCxIG5gG9UeYQ6kWFbuFBlJxoJmyv+qf8hLgTSH+Y2+thb1JdJWcuds4sTXz4bmjY0dddhE8R+tug== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3633 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [Drip] =?utf-8?q?DRIP_is_mentioned_-_Today=E2=80=99s_Internet_St?= =?utf-8?q?ill_Relies_on_an_ARPANET-Era_Protocol=3A_The_Request_for_Commen?= =?utf-8?q?ts?= X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2020 12:31:45 -0000 --_000_75FFBA2ACBB54D3485375D53DCE6850Cciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2UgZG8gb2YgY291cnNlIDotKQ0KDQpGcm9tOiBUbS1yaWQgPHRtLXJpZC1ib3VuY2VzQGlldGYu b3JnPiBvbiBiZWhhbGYgb2YgU3RldmUgQ3JvY2tlciA8c3RldmVAc2hpbmt1cm8uY29tPg0KRGF0 ZTogVGh1cnNkYXksIDYgQXVndXN0IDIwMjAgYXQgMDE6MTENClRvOiBSb2JlcnQgTW9za293aXR6 IDxyZ21AbGFicy5odHQtY29uc3VsdC5jb20+DQpDYzogInRtLXJpZEBpZXRmLm9yZyIgPHRtLXJp ZEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbRHJpcF0gRFJJUCBpcyBtZW50aW9uZWQgLSBUb2Rh eeKAmXMgSW50ZXJuZXQgU3RpbGwgUmVsaWVzIG9uIGFuIEFSUEFORVQtRXJhIFByb3RvY29sOiBU aGUgUmVxdWVzdCBmb3IgQ29tbWVudHMNCg0KOikgWWVzLCBJIHRob3VnaHQgeW91J2QgZW5qb3kg dGhlIG1lbnRpb24gb2YgZHJvbmVzLg0KDQpTdGV2ZQ0KDQoNCk9uIFdlZCwgQXVnIDUsIDIwMjAg YXQgNjozNyBQTSBSb2JlcnQgTW9za293aXR6IDxyZ21AbGFicy5odHQtY29uc3VsdC5jb208bWFp bHRvOnJnbUBsYWJzLmh0dC1jb25zdWx0LmNvbT4+IHdyb3RlOg0KaHR0cHM6Ly9zcGVjdHJ1bS5p ZWVlLm9yZy90ZWNoLWhpc3RvcnkvY3liZXJzcGFjZS90b2RheXMtaW50ZXJuZXQtc3RpbGwtcmVs aWVzLW9uLWFuLWFycGFuZXRlcmEtcHJvdG9jb2wtdGhlLXJlcXVlc3QtZm9yLWNvbW1lbnRzDQoN CkJ5IFN0ZXZlIENyb2NrZXIuICBBdXRob3Igb2YgUkZDIDEgYW5kIGEgbWVtYmVyIG9mIHRoaXMg bGlzdC4NCg0KDQotLQ0KVG0tcmlkIG1haWxpbmcgbGlzdA0KVG0tcmlkQGlldGYub3JnPG1haWx0 bzpUbS1yaWRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3RtLXJpZA0K --_000_75FFBA2ACBB54D3485375D53DCE6850Cciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <21F69D0F5498F944AB43CD196EA05B58@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJlbi1CRSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRlIiPldlIGRvIG9mIGNvdXJzZSZuYnNwOzotKTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZy b206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr Ij5UbS1yaWQgJmx0O3RtLXJpZC1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgU3Rl dmUgQ3JvY2tlciAmbHQ7c3RldmVAc2hpbmt1cm8uY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5U aHVyc2RheSwgNiBBdWd1c3QgMjAyMCBhdCAwMToxMTxicj4NCjxiPlRvOiA8L2I+Um9iZXJ0IE1v c2tvd2l0eiAmbHQ7cmdtQGxhYnMuaHR0LWNvbnN1bHQuY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+ JnF1b3Q7dG0tcmlkQGlldGYub3JnJnF1b3Q7ICZsdDt0bS1yaWRAaWV0Zi5vcmcmZ3Q7PGJyPg0K PGI+U3ViamVjdDogPC9iPlJlOiBbRHJpcF0gRFJJUCBpcyBtZW50aW9uZWQgLSBUb2RheeKAmXMg SW50ZXJuZXQgU3RpbGwgUmVsaWVzIG9uIGFuIEFSUEFORVQtRXJhIFByb3RvY29sOiBUaGUgUmVx dWVzdCBmb3IgQ29tbWVudHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjopIFllcywgSSB0aG91Z2h0IHlvdSdkIGVuam95IHRoZSBtZW50 aW9uIG9mIGRyb25lcy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PlN0ZXZlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gV2VkLCBBdWcgNSwgMjAyMCBhdCA2OjM3 IFBNIFJvYmVydCBNb3Nrb3dpdHogJmx0OzxhIGhyZWY9Im1haWx0bzpyZ21AbGFicy5odHQtY29u c3VsdC5jb20iPnJnbUBsYWJzLmh0dC1jb25zdWx0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGEgaHJlZj0iaHR0cHM6Ly9zcGVjdHJ1bS5pZWVlLm9yZy90 ZWNoLWhpc3RvcnkvY3liZXJzcGFjZS90b2RheXMtaW50ZXJuZXQtc3RpbGwtcmVsaWVzLW9uLWFu LWFycGFuZXRlcmEtcHJvdG9jb2wtdGhlLXJlcXVlc3QtZm9yLWNvbW1lbnRzIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly9zcGVjdHJ1bS5pZWVlLm9yZy90ZWNoLWhpc3RvcnkvY3liZXJzcGFjZS90 b2RheXMtaW50ZXJuZXQtc3RpbGwtcmVsaWVzLW9uLWFuLWFycGFuZXRlcmEtcHJvdG9jb2wtdGhl LXJlcXVlc3QtZm9yLWNvbW1lbnRzPC9hPjxicj4NCjxicj4NCkJ5IFN0ZXZlIENyb2NrZXIuJm5i c3A7IEF1dGhvciBvZiBSRkMgMSBhbmQgYSBtZW1iZXIgb2YgdGhpcyBsaXN0Ljxicj4NCjxicj4N Cjxicj4NCi0tIDxicj4NClRtLXJpZCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 VG0tcmlkQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+VG0tcmlkQGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdG0tcmlkIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bS1y aWQ8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_75FFBA2ACBB54D3485375D53DCE6850Cciscocom_-- From nobody Thu Aug 6 05:43:04 2020 Return-Path: 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 9BDBD3A0AD8 for ; Thu, 6 Aug 2020 05:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 MVt54FjZTjc5 for ; Thu, 6 Aug 2020 05:43:00 -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 3D2453A0AD6 for ; Thu, 6 Aug 2020 05:42:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 4A20362422; Thu, 6 Aug 2020 08:42:58 -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 LPGVOpYJHLFA; Thu, 6 Aug 2020 08:42:51 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (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 A376D62415; Thu, 6 Aug 2020 08:42:51 -0400 (EDT) To: "Eric Vyncke (evyncke)" , Steve Crocker Cc: "tm-rid@ietf.org" References: <59b79ec5-8023-85d2-2037-0df100c9e9b4@labs.htt-consult.com> <75FFBA2A-CBB5-4D34-8537-5D53DCE6850C@cisco.com> From: Robert Moskowitz Message-ID: <4a562550-fdff-ef60-6d11-19b728693c51@labs.htt-consult.com> Date: Thu, 6 Aug 2020 08:42:46 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <75FFBA2A-CBB5-4D34-8537-5D53DCE6850C@cisco.com> Content-Type: multipart/alternative; boundary="------------09DB7D9C58D8BFF14ABBE91B" Content-Language: en-US Archived-At: Subject: Re: [Drip] =?utf-8?q?DRIP_is_mentioned_-_Today=E2=80=99s_Internet_St?= =?utf-8?q?ill_Relies_on_an_ARPANET-Era_Protocol=3A_The_Request_for_Commen?= =?utf-8?q?ts?= X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2020 12:43:03 -0000 This is a multi-part message in MIME format. --------------09DB7D9C58D8BFF14ABBE91B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit And a great article. In fall of '68, I was just starting out at Michigan State University.  A few years later my roommate programmed a Cascade mini computer as the MSU frontend for our CDC 6500 to MERIT network (UofM wanted nothing to do with US gov funding due to Vietnam era issues; it would be sometime before the networks merged).  Steve has been at this a bit longer than I have. Now back to draft rewriting (and writing for ICAO IATF). On 8/6/20 8:31 AM, Eric Vyncke (evyncke) wrote: > > We do of course :-) > > *From: *Tm-rid on behalf of Steve Crocker > > *Date: *Thursday, 6 August 2020 at 01:11 > *To: *Robert Moskowitz > *Cc: *"tm-rid@ietf.org" > *Subject: *Re: [Drip] DRIP is mentioned - Today’s Internet Still > Relies on an ARPANET-Era Protocol: The Request for Comments > > :) Yes, I thought you'd enjoy the mention of drones. > > Steve > > On Wed, Aug 5, 2020 at 6:37 PM Robert Moskowitz > > wrote: > > https://spectrum.ieee.org/tech-history/cyberspace/todays-internet-still-relies-on-an-arpanetera-protocol-the-request-for-comments > > By Steve Crocker.  Author of RFC 1 and a member of this list. > > > -- > Tm-rid mailing list > Tm-rid@ietf.org > https://www.ietf.org/mailman/listinfo/tm-rid > > -- 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 --------------09DB7D9C58D8BFF14ABBE91B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit And a great article.

In fall of '68, I was just starting out at Michigan State University.  A few years later my roommate programmed a Cascade mini computer as the MSU frontend for our CDC 6500 to MERIT network (UofM wanted nothing to do with US gov funding due to Vietnam era issues; it would be sometime before the networks merged).  Steve has been at this a bit longer than I have.

Now back to draft rewriting (and writing for ICAO IATF).

On 8/6/20 8:31 AM, Eric Vyncke (evyncke) wrote:

We do of course :-)

 

From: Tm-rid <tm-rid-bounces@ietf.org> on behalf of Steve Crocker <steve@shinkuro.com>
Date: Thursday, 6 August 2020 at 01:11
To: Robert Moskowitz <rgm@labs.htt-consult.com>
Cc: "tm-rid@ietf.org" <tm-rid@ietf.org>
Subject: Re: [Drip] DRIP is mentioned - Today’s Internet Still Relies on an ARPANET-Era Protocol: The Request for Comments

 

:) Yes, I thought you'd enjoy the mention of drones.

 

Steve

 

 

On Wed, Aug 5, 2020 at 6:37 PM Robert Moskowitz <rgm@labs.htt-consult.com> wrote:

https://spectrum.ieee.org/tech-history/cyberspace/todays-internet-still-relies-on-an-arpanetera-protocol-the-request-for-comments

By Steve Crocker.  Author of RFC 1 and a member of this list.


--
Tm-rid mailing list
Tm-rid@ietf.org
https://www.ietf.org/mailman/listinfo/tm-rid



--
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
--------------09DB7D9C58D8BFF14ABBE91B-- From nobody Fri Aug 7 05:51:59 2020 Return-Path: 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 EC3813A0C3A for ; Fri, 7 Aug 2020 05:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.278 X-Spam-Level: X-Spam-Status: No, score=-0.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.949, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 fqmKFCh7HbhJ for ; Fri, 7 Aug 2020 05:51:55 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 E67E93A0C43 for ; Fri, 7 Aug 2020 05:51:54 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 077Cpq3n045587; Fri, 7 Aug 2020 14:51:52 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 610E7204313; Fri, 7 Aug 2020 14:51:52 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4FEB0204139; Fri, 7 Aug 2020 14:51:52 +0200 (CEST) Received: from [10.11.240.76] ([10.11.240.76]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 077Cpol5017479; Fri, 7 Aug 2020 14:51:50 +0200 To: "Card, Stu" Cc: Robert Moskowitz , tm-rid@ietf.org References: <1bebf5b1-1fa5-6902-5bb7-9ec3582e6d9a@andersdotter.cc> <7ddd9a2f-23ba-dd82-8cfb-1d2974969e67@gmail.com> <61511ef6-5b9b-5b62-f922-d32b994a35b9@gmail.com> <2e1cbffc-8554-222b-d558-43e048194104@gmail.com> From: Alexandre Petrescu Message-ID: Date: Fri, 7 Aug 2020 14:51:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Drip] ADSB X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2020 12:51:58 -0000 Le 05/08/2020 à 16:34, Card, Stu a écrit : > Yes, the openly published early draft of ASTM F3411 was developed > largely by Gabriel Cox of Intel and his group there. While we all are > generally suspicious of the motivations of large companies, I have > spoken often with Gabriel: his heart is pure; he says Intel hopes to > increase sales by simply helping mature a standard that enables a market > to grow. Development and publication of the standard within ASTM then > attracted many other large and small players, so Intel could not force > anything upon the world that benefited primarily Intel. While I do not > agree with all the decisions made (and neither does Gabriel), they are > the decisions that SDO working group made, in response to the concerns > of many different stakeholders (especially regulators, manufacturers and > would-be UTM network service providers). Alas, ASTM supports themselves > by sales of standards documents, so F3411-19 is not openly published. > OTOH $85 is small compared to the value of most contributor's time Yes 85USD is small compared to other things. At IETF there was an innovation last meeting, in that non-paying the attending money was somehow an option. Its results are still to be understood but the option was there. I hope others could replicate. There are many things. > working on the problem, and better still one can join ASTM as an > individual for only $75 and get this standard as part of the one free > "volume" of standards that a member may select (from a large library) > upon joining. As a fallback, we point people to the openly published > early draft, which provides pretty good context; perhaps I should add it > to the reference list in the requirements draft? Yes yes, please add the openly available document to the reference list in the appropriate draft. Alex Thanks again for your > interest and help with this! > > > On Wed, Aug 5, 2020 at 10:23 AM Alexandre Petrescu > > wrote: > > > > Le 05/08/2020 à 15:50, Card, Stu a écrit : > > Again, a single point response. The reason this work is > appropriate for > > IETF rather than the Bluetooth SIG is that ASTM F3411 specifies > > Bluetooth _only_ as one transport for Broadcast RID (WiFi NaN is > also > > specified and other alternatives could be added later, as you, > Bob and > > others are discussing, also consider RTCA SC-228 DO-362 UAS C2 > Data Link > > at ~1 and ~5 GHz), but there is also Network RID where ASTM F3411 > > specifies use of the Internet, and a lot more to the overall UAS RID > > architecture/problem than just the initial streaming of messages > from > > the UAS. > > > > Please look at the openly published early draft of ASTM F3411 to > which > > Bob pointed you, > > I looked and I will keep it aside for reference when needed. > > It's an Intel document. > > https://github.com/opendroneid/specs/blob/master/OpenDroneID_Bluetooth_0.64.3.pdf > > Alex > >   and perhaps some of the other external docs cited in > > the DRIP requirements draft, for  essential context on the UAS RID > > problem and what others have already done to address it, which we > hope > > to complement (not replace) with DRIP. Thanks! > > > > > > On Wed, Aug 5, 2020 at 8:50 AM Alexandre Petrescu > > > >> wrote: > > > > > > > >     Le 05/08/2020 à 13:53, Robert Moskowitz a écrit : > >      > > >      > > >      > On 8/5/20 6:11 AM, Alexandre Petrescu wrote: > >      >> > >      >> > >      >> Le 04/08/2020 à 17:51, Robert Moskowitz a écrit : > >      >>> > >      >>> > >      >>> On 8/4/20 11:27 AM, Alexandre Petrescu wrote: > >      >>>> Thanks for the clarification. > >      >>>> > >      >>>> Le 04/08/2020 à 17:17, Stuart W. Card a écrit : > >      >>>>> I just want to respond to one line that I think comes from > >      >>>>> confusion: > >      >>>>> > >      >>>>>> But if we have reluctance about the use of ADS-B, and > thus > >      >>>>>> of IP, and we recommend Bluetooth-without-IP to identify > >      >>>>>> drones > >      >>>>> > >      >>>>> We aren't recommending Bluetooth-without-IP, we are > >      >>>>> _supporting_ it, > >      >>>> > >      >>>> But, the security manifest that I have seen on slides > during > >      >>>> the presentation of the DRIP WG meeting - is something > below > >      >>>> IP, right? > >      >>> > >      >>> For now, we are dealing with broadcast messages.  Either > over > >      >>> Bluetooth or WiFI (NAN). > >      >> > >      >> If it is a broadcast message and it is over Bluetooth or > over WiFi > >      >> then it certainly is IP multicast, cant be anything else. > >      > > >      > Wrong for BT4.  There are only 25 bytes available.  We can > do most > >      > of the messaging in a single frame.  To do anything with > IP will > >      > force this to a multiframe design. > > > >     I might say something stupid if I am allowed, maybe things > that are > >     already known.  Sorry, I did not check the BoF archive > discussion.  But > >     here goes anyways.  If one wants to do something with > Bluetooth4 below > >     IP and finds it to be too small packets, then there could be > several > >     possibilities: > >     - do it at Bluetooth SIG instead of IETF; > >     - do it in 6lo WG; > >     - use a header compression scheme at IETF (6lowpan HC at 6lo > WG, SCHC at > >         LP-WAN WG, ROHC and why not CBOR); > >     - implement packet fragmentation and reassembly and > multiframe design > >         below IP; > >     - use the already available data in the 25 bytes in order to > realize > >         that identification (there must be MAC addresses in > there, and > >     they're > >         likely to be useful). > > > >      > Even BT5 it is wrong for the Authentication Message.  We > need the > >      > full frame for our content.  We would have to go with > multiframe > >      > design for BT5 as a result. > > > >     So, I do not understand: does DRIP want the entire packet to > stay of > >     size 25bytes?  Or does DRIP want the packet to be more than > 25bytes? > > > >     Would a multiframe design in which an IP packet of length > 1280bytes is > >     chopped into 25bytes BT5 packets be advantageous for DRIP? > > > >     Do the BT5 packets have a notion of interlinking between > sub-packets > >     that make a bigger packet?  (such a mechanism exists at the > IP layer; it > >     uses Identification to identify a chain and an Offset to say > where in > >     the chain is that sub-packet to be found). > > > >      > So this leaves WiFi NAN.  Sure you can do it, but why? > What does it > >      > add?  In My Not So Humble Opinion (IMNSOHO) nothing but > cost and > >      > processing overhead. > > > >     I think WiFi 5.4 GHz is already used extensively to remotely > control > >     drones.  These consoles with joysticks are WiFi 5.4GHz, if I > am not > >     mistaken. > > > >      >> If it is IP multicast over Bluetooth or over WiFi then I > wonder > >      >> what is the value  in the Next Header field of the IP header > >      >> format (RFC8200 "IPv6", section 3 "Header format"). > Basically - > >      >> what is the payload? > >      >> > >      >> If one asks me, I would dare to think that payload might > be an > >      >> ICMPv6 Router Advertisement. > >      >> > >      >>> There is NO security for the messages below the message > package. > >      >> > >      >> Noted. > >      >> > >      >>> Just not enough payload size for anything that would > work in a > >      >>> broadcast environment like a National Airspace.  All of the > >      >>> security we are specifying is inside the messages where > >      >>> appropriate. > >      >>> > >      >>> That security manifest is a payload of the ASTM F3411-19 > >      >>> Authentication Message. > >      >> > >      >> It costs 85USD I wont pay to see it.  It is security. > There will > >      >> always be someone smarter to break that security and ask > for more > >      >> money. > >      > > >      > Look at: > >      > > >      > > > > https://github.com/opendroneid/specs/blob/master/OpenDroneID_Bluetooth_0.64.3.pdf > >      > > >      > > >      > > >     It is close enough. > > > >     Thanks for the pointer.  Noted. > > > >     It is about Bluetooth.  Should be submitted to Bluetooth SIG. > > > >     I might stay something stupid here again... si I wont say it :-) > > > >      >> I would not oppose if that Authentication MEssage had a > >      >> specification in clear. > >      > > >      > The above plus Adam's draft will get you there. > >      > > >      >> > >      >>> These messages are broadcasted as Adam mentioned in his > 'flying > >      >>> DRIP' comments at the beginning. > >      >> > >      >> Thank you for the reminder.  I looked again at the > 'flying DRIP' > >      >> presentation during the WG meeting, and at the related draft. > >      >> > > > https://datatracker.ietf.org/meeting/108/materials/slides-108-drip-authentication-formats > >      >> > >      >> > >      >> > >      >> and draft-wiethuechter-drip-auth-01 > >      >> > >      >> During the presentation, the slide clearly shows on slide > 8 that a > >      >> Bluetooth header immediately precedes an Open Drone ID > message. > >      >> There is no IP header in that slide. > >      > > >      > That is right.  No IP.  No room for it.  No justification > for it. It > >      > is all RLOS only. > > > >     I might say something stupid here: no IP?  No IETF. > > > >      >> In the draft, there is similar discussion tightly related to > >      >> Bluetooth and without IP. > >      >> > >      >> But if we are to have an independence of Bluetooth, and use a > >      >> networking layer such as IP, then the question of the use > of an > >      >> authentication header is made differently. > >      > > >      > Again what is the justification for adding IP multicast? > > > >     I would not be afraid of IP multicast like the multicast we > know for > >     video delivery.  It is IP multicast because IP is IPv6 and > IPv6 has no > >     broadcast. > > > >     _If_ there is agreement that DRIP should be with IP (Internet > Protocol). > > > >     We know that the drone identification should be broadcasted > (like in TV > >     broadcast).  In IPv4 there is a mechanism to implement such > TV-broadcast > >     concept.  It is called IPv4 broadcast.  That broadcast is > sent to a > >     dedicated address (like 255.255.255.255 which is all > Internet, or like > >     195.212.142.255 which is all computers in a particular > subnet).  In IPv6 > >     such broadcast concept does not exist.  Rather, it's called > 'multicast' > >     and, as opposed to IPv4, it has a mandatory and voluntary > join/leave > >     mechanism. > > > >     I name that IPv6 multicast simply IP multicast, because IPv4 > should not > >     be used as basis for any new work at IETF. > > > >     On such an IP multicast perspective for DRIP, one would have > to come up > >     with an architecture for joining and leaving that makes it > easy to use > >     by authorities, mandatory to implement, is secure enough > (security and > >     multicast is not that easy), etc. > > > >      > Where do you see these messages going beyond the RF Line > Of Sight? > > > >     True. > > > >     But one would not want all BT5 devices (like my watch or > earphones) > >     around a drone's sight to be awaken by its identification > beacons, > >     right?  Only those devices who have voluntarily subscribed to > that > >     multicast group would be awaken. > > > > > >      >> The authentication header would be an IP Authentication > Header. > >      >> This AH would be somehow re-used and extended where > necessary for > >      >> DRIP purposes. > >      >> > >      >>> Now later I expect us to move on to Network Remote ID > and Command > >      >>> and Control (C2). > >      >>> > >      >>> Most C2 (e.g. Mavlink) is directly over the MAC, but > there is a > >      >>> method to run it over UDP (I forget the UDP port commonly > >      >>> used...). AX Enterprize has done this using HIP so the > UA starts > >      >>> with WiFi over the launch point, transitions to LTE, and on > >      >>> return back to WiFi. > >      >>> > >      >>> Network Remote ID can work either directly from the UA, > or via > >      >>> C2 information to the GCS, from the GCS.  In either > case, IP is > >      >>> assumed. This will probably be done via UDP.  From the UA, > >      >>> mobility will be important; from the GCS nice to have > (most GCS > >      >>> will be stable location).  As UDP to a fixed Net-SP, > DTLS 1.3 is > >      >>> a viable alternative to HIP. > >      >> > >      >> I will have to look closer at HIP again :-) and see how > it could > >      >> be made to work with DRIP and IP. > >      > > >      > Stu, Adam, Andrei, and I see HIP for where there is pairwise > >      > communication with potentially both ends mobile and using > multiple > >      > interfaces.  Once you have that use case, be consistent > and use it > >      > for simpler situations. > > > >     I wanted to ask whether using a Host Identity that is > cryptographically > >     generated is sufficient for authorities to trust a drone upon > reception > >     of one DRIP identification packet, or maybe am additional > roundrip (a > >     ping, a request-response) would still be needed from ground > officer to > >     drone to make sure it's the right drone who replies?  Or > maybe a full > >     Diffie-Hellman exchange is needed? > > > >     Alex > > > >      > > >      >> > >      >> Alex > >      >> > >      >>> > >      >>> > >      >>> > >      >>> > >      >>>> > >      >>>> Alex > >      >>>> > >      >>>> as > >      >>>>> it is specified in ASTM F3411, which most of the > regulators > >      >>>>> are dubbing as an approved technical means of regulatory > >      >>>>> compliance. > >      >>>>> > >      >>>>> AFAIK, no one runs IP over ADS-B, which was designed as a > >      >>>>> narrowband application specific communications stovepipe, > >      >>>>> not a data link supporting higher layer network protocols, > >      >>>>> so not great for IP. > >      >>>>> > >      >>>>> More importantly, we have no "reluctance about the use > of... > >      >>>>>  IP", which is an entirely separate issue from ADS-B. > >      >>>>> > >      >>>>> On 8/4/2020 9:52 AM, Alexandre Petrescu wrote: > >      >>>>>> architectural layers discussion... > >      >>>>>> > >      >>>>>> Le 30/07/2020 à 11:49, shuaiizhao(Shuai Zhao) a écrit : > >      >>>>>>> Just to echo Stu on the ADSB, AFAIK, ADSB will  not be > >      >>>>>>> feasible for most of the drones mostly due to SwaP, > >      >>>>>>> commercial drones might be exception. > >      >>>>>> > >      >>>>>> It might be that ADS-B might be forbidden in drones on > >      >>>>>> Earth, but how about the drones on Mars? ('NASA Mars > >      >>>>>> helicopters', or ESA too).  On Mars there would be much > >      >>>>>> less such drones, so less risk of interference. > >      >>>>>> > >      >>>>>> With such a system (ADS-B under IP) one could re-use DTN > >      >>>>>> (Delay Tolerant Networking) between planets, and so > >      >>>>>> identify drones even on Mars. > >      >>>>>> > >      >>>>>> But if we have reluctance about the use of ADS-B, and > thus > >      >>>>>> of IP, and we recommend Bluetooth-without-IP to identify > >      >>>>>> drones, then we might become too dependent on it? > >      >>>>>> > >      >>>>>> (do not get me wrong, I do like Bluetooth, but I like > many > >      >>>>>> other things together with Bluetooth). > >      >>>>>> > >      >>>>>> Alex > >      >>>>>> > >      >>>>>>> > >      >>>>>>> Best, > >      >>>>>>> > >      >>>>>>> Shuai Zhao > >      >>>>>>> > >      >>>>>>> *From: *Tm-rid > >      >> on behalf of > >      >>>>>>> "Stuart W. Card" > >      >> *Date: > >      >>>>>>> *Wednesday, July 29, 2020 at 19:46 *To: > >      >>>>>>> *"tm-rid@ietf.org > >" > >      > >> *Subject: *[Drip] > >      >>>>>>> ADSB (was: Review of draft-drip-arch-02 w.r.t. RFC6973, > >      >>>>>>> RFC8280 and other)(Internet mail) > >      >>>>>>> > >      >>>>>>> Sorry for the slow reply. > >      >>>>>>> > >      >>>>>>> ADS-B is gradually being mandated for essentially all > >      >>>>>>> manned aircraft. > >      >>>>>>> > >      >>>>>>> ADSB-In and ADSB-Out are mandated for airliners: -In > >      >>>>>>> gives their pilots > >      >>>>>>> > >      >>>>>>> some Situational Awareness (SA) of other aircraft; -Out > >      >>>>>>> gives other > >      >>>>>>> > >      >>>>>>> pilots SA of the airliners. > >      >>>>>>> > >      >>>>>>> "ADSB-Out" is mandated even for small general aviation > >      >>>>>>> aircraft: it does > >      >>>>>>> > >      >>>>>>> not directly benefit the pilots of those aircraft; but > >      >>>>>>> by providing SA > >      >>>>>>> > >      >>>>>>> to others, it indirectly benefits all. > >      >>>>>>> > >      >>>>>>> ADSB is _not_ going to be deployed on large numbers of > >      >>>>>>> small UAS as it > >      >>>>>>> > >      >>>>>>> would overwhelm the limited bandwidth available at those > >      >>>>>>> lower radio > >      >>>>>>> > >      >>>>>>> frequencies (which propagate long ranges). In fact, it > >      >>>>>>> is expected to be > >      >>>>>>> > >      >>>>>>> explicitly prohibited in the US per the FAA NPRM; I > >      >>>>>>> suspect most of the > >      >>>>>>> > >      >>>>>>> rest of the world will do likewise. > >      >>>>>>> > >      >>>>>>> ADSB is also altogether insecure. > >      >>>>>>> > >      >>>>>>> On 7/9/2020 3:02 AM, Alexandre Petrescu wrote: > >      >>>>>>> > >      >>>>>>> ... > >      >>>>>>> > >      >>>>>>> They call it "ADS-B Receivers" (Automatic Dependent > >      >>>>>>> Surveillance - > >      >>>>>>> > >      >>>>>>> Broadcast). > >      >>>>>>> > >      >>>>>>> I wouuld like to ask if there is a packet dump available > >      >>>>>>> showing such > >      >>>>>>> > >      >>>>>>> presence data form planes?  Maybe wireshark already > >      >>>>>>> supports it, maybe > >      >>>>>>> > >      >>>>>>> it even dissects it... > >      >>>>>>> > >      >>>>>>> -- > >      >>>>>>> > >      >>>>>>> ----------------------------------------- > >      >>>>>>> > >      >>>>>>> Stuart W. Card, PhD, Principal Engineer > >      >>>>>>> > >      >>>>>>> AX Enterprize, LLC www.axenterprize.com > > >      > >      >>>>>>> > >      >>>>>>> 4947 Commercial Drive, Yorkville NY 13495 > >      >>>>>>> > >      >>>>>>> > >      >>>>>> > >      >>>>> > >      >>>>> > >      >>>>> > >      >>>> > >      >>> > >      >>> -- 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 > >      > > >      > -- 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 > > > >     -- > >     Tm-rid mailing list > > Tm-rid@ietf.org > > > https://www.ietf.org/mailman/listinfo/tm-rid > > > From nobody Tue Aug 11 12:23:45 2020 Return-Path: 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 714343A07FF for ; Tue, 11 Aug 2020 12:23:44 -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, 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 wpvSroF8KQGj for ; Tue, 11 Aug 2020 12:23:42 -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 2A9F03A076C for ; Tue, 11 Aug 2020 12:23:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id C355462415 for ; Tue, 11 Aug 2020 15:23:40 -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 mm8Dygizjf6O for ; Tue, 11 Aug 2020 15:23:33 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (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 28218622C2 for ; Tue, 11 Aug 2020 15:23:33 -0400 (EDT) References: <159717351793.27599.15158252127680658538@ietfa.amsl.com> To: "tm-rid@ietf.org" From: Robert Moskowitz X-Forwarded-Message-Id: <159717351793.27599.15158252127680658538@ietfa.amsl.com> Message-ID: Date: Tue, 11 Aug 2020 15:23:24 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <159717351793.27599.15158252127680658538@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------D2D952299DD2016590875BCB" Content-Language: en-US Archived-At: Subject: [Drip] Fwd: New Version Notification for draft-moskowitz-drip-uas-rid-04.txt X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 19:23:45 -0000 This is a multi-part message in MIME format. --------------D2D952299DD2016590875BCB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Edits suggested by Med. Med also recommends that I make this more of a self-standing draft. That is not to need the Normative reverences to new HIP drafts. This is a reversal of what some asked me to do back in November.  So I published this version as a 'clean' point before rolling up the drafts into this one (and probably replacing the HIT-Registry draft with EPP). So please start reviewing this draft and I will be working on more edits shortly. Bob -------- Forwarded Message -------- Subject: New Version Notification for draft-moskowitz-drip-uas-rid-04.txt Date: Tue, 11 Aug 2020 12:18:37 -0700 From: internet-drafts@ietf.org To: Adam Wiethuechter , Andrei Gurtov , Stuart Card , Robert Moskowitz , Stuart W. Card A new version of I-D, draft-moskowitz-drip-uas-rid-04.txt has been successfully submitted by Robert Moskowitz and posted to the IETF repository. Name: draft-moskowitz-drip-uas-rid Revision: 04 Title: UAS Remote ID Document date: 2020-08-11 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-moskowitz-drip-uas-rid-04.txt Status: https://datatracker.ietf.org/doc/draft-moskowitz-drip-uas-rid/ Htmlized: https://tools.ietf.org/html/draft-moskowitz-drip-uas-rid-04 Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-drip-uas-rid Diff: https://www.ietf.org/rfcdiff?url2=draft-moskowitz-drip-uas-rid-04 Abstract: This document describes the use of Hierarchical Host Identity Tags (HHITs) as a self-asserting and thereby trustable Identifier for use as the UAS Remote ID. HHITs include explicit hierarchy to provide Registrar discovery for 3rd-party ID attestation. 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. The IETF Secretariat --------------D2D952299DD2016590875BCB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Edits suggested by Med.

Med also recommends that I make this more of a self-standing draft.  That is not to need the Normative reverences to new HIP drafts.  This is a reversal of what some asked me to do back in November.  So I published this version as a 'clean' point before rolling up the drafts into this one (and probably replacing the HIT-Registry draft with EPP).

So please start reviewing this draft and I will be working on more edits shortly.

Bob


-------- Forwarded Message --------
Subject: New Version Notification for draft-moskowitz-drip-uas-rid-04.txt
Date: Tue, 11 Aug 2020 12:18:37 -0700
From: internet-drafts@ietf.org
To: Adam Wiethuechter <adam.wiethuechter@axenterprize.com>, Andrei Gurtov <gurtov@acm.org>, Stuart Card <stu.card@axenterprize.com>, Robert Moskowitz <rgm@labs.htt-consult.com>, Stuart W. Card <stu.card@axenterprize.com>



A new version of I-D, draft-moskowitz-drip-uas-rid-04.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-drip-uas-rid
Revision: 04
Title: UAS Remote ID
Document date: 2020-08-11
Group: Individual Submission
Pages: 11
URL: https://www.ietf.org/internet-drafts/draft-moskowitz-drip-uas-rid-04.txt
Status: https://datatracker.ietf.org/doc/draft-moskowitz-drip-uas-rid/
Htmlized: https://tools.ietf.org/html/draft-moskowitz-drip-uas-rid-04
Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-drip-uas-rid
Diff: https://www.ietf.org/rfcdiff?url2=draft-moskowitz-drip-uas-rid-04

Abstract:
This document describes the use of Hierarchical Host Identity Tags
(HHITs) as a self-asserting and thereby trustable Identifier for use
as the UAS Remote ID. HHITs include explicit hierarchy to provide
Registrar discovery for 3rd-party ID attestation.



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.

The IETF Secretariat


--------------D2D952299DD2016590875BCB-- From nobody Wed Aug 12 04:49:36 2020 Return-Path: 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 F3A1A3A0F94 for ; Wed, 12 Aug 2020 04:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.836 X-Spam-Level: X-Spam-Status: No, score=-2.836 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, 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 DfpF__v7kbab for ; Wed, 12 Aug 2020 04:49:28 -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 E4B563A0F80 for ; Wed, 12 Aug 2020 04:49:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 7E620624C7 for ; Wed, 12 Aug 2020 07:49:26 -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 yFXW5xno9KCj for ; Wed, 12 Aug 2020 07:49:21 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (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 3AAD862415 for ; Wed, 12 Aug 2020 07:49:19 -0400 (EDT) From: Robert Moskowitz To: "tm-rid@ietf.org" References: <159717351793.27599.15158252127680658538@ietfa.amsl.com> Message-ID: Date: Wed, 12 Aug 2020 07:49:11 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------669AFCAB94B738A1D0A2BD5D" Content-Language: en-US Archived-At: Subject: Re: [Drip] Fwd: New Version Notification for draft-moskowitz-drip-uas-rid-04.txt X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 11:49:35 -0000 This is a multi-part message in MIME format. --------------669AFCAB94B738A1D0A2BD5D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I have been reviewing the various drafts and am figuring that the easiest way to merge the documents is by adding appendices.  One will be for Hierarchical HITs, and the other for ORCHIDs. Comments before I start all the writing/cutting/pasting? thanks On 8/11/20 3:23 PM, Robert Moskowitz wrote: > Edits suggested by Med. > > Med also recommends that I make this more of a self-standing draft.  > That is not to need the Normative reverences to new HIP drafts.  This > is a reversal of what some asked me to do back in November.  So I > published this version as a 'clean' point before rolling up the drafts > into this one (and probably replacing the HIT-Registry draft with EPP). > > So please start reviewing this draft and I will be working on more > edits shortly. > > Bob > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-moskowitz-drip-uas-rid-04.txt > Date: Tue, 11 Aug 2020 12:18:37 -0700 > From: internet-drafts@ietf.org > To: Adam Wiethuechter , Andrei > Gurtov , Stuart Card , > Robert Moskowitz , Stuart W. Card > > > > > > A new version of I-D, draft-moskowitz-drip-uas-rid-04.txt > has been successfully submitted by Robert Moskowitz and posted to the > IETF repository. > > Name: draft-moskowitz-drip-uas-rid > Revision: 04 > Title: UAS Remote ID > Document date: 2020-08-11 > Group: Individual Submission > Pages: 11 > URL: > https://www.ietf.org/internet-drafts/draft-moskowitz-drip-uas-rid-04.txt > Status: https://datatracker.ietf.org/doc/draft-moskowitz-drip-uas-rid/ > Htmlized: https://tools.ietf.org/html/draft-moskowitz-drip-uas-rid-04 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-moskowitz-drip-uas-rid > Diff: https://www.ietf.org/rfcdiff?url2=draft-moskowitz-drip-uas-rid-04 > > Abstract: > This document describes the use of Hierarchical Host Identity Tags > (HHITs) as a self-asserting and thereby trustable Identifier for use > as the UAS Remote ID. HHITs include explicit hierarchy to provide > Registrar discovery for 3rd-party ID attestation. > > > > 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. > > The IETF Secretariat > > > -- 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 --------------669AFCAB94B738A1D0A2BD5D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I have been reviewing the various drafts and am figuring that the easiest way to merge the documents is by adding appendices.  One will be for Hierarchical HITs, and the other for ORCHIDs.

Comments before I start all the writing/cutting/pasting?

thanks


On 8/11/20 3:23 PM, Robert Moskowitz wrote:
Edits suggested by Med.

Med also recommends that I make this more of a self-standing draft.  That is not to need the Normative reverences to new HIP drafts.  This is a reversal of what some asked me to do back in November.  So I published this version as a 'clean' point before rolling up the drafts into this one (and probably replacing the HIT-Registry draft with EPP).

So please start reviewing this draft and I will be working on more edits shortly.

Bob


-------- Forwarded Message --------
Subject: New Version Notification for draft-moskowitz-drip-uas-rid-04.txt
Date: Tue, 11 Aug 2020 12:18:37 -0700
From: internet-drafts@ietf.org
To: Adam Wiethuechter <adam.wiethuechter@axenterprize.com>, Andrei Gurtov <gurtov@acm.org>, Stuart Card <stu.card@axenterprize.com>, Robert Moskowitz <rgm@labs.htt-consult.com>, Stuart W. Card <stu.card@axenterprize.com>



A new version of I-D, draft-moskowitz-drip-uas-rid-04.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-drip-uas-rid
Revision: 04
Title: UAS Remote ID
Document date: 2020-08-11
Group: Individual Submission
Pages: 11
URL: https://www.ietf.org/internet-drafts/draft-moskowitz-drip-uas-rid-04.txt
Status: https://datatracker.ietf.org/doc/draft-moskowitz-drip-uas-rid/
Htmlized: https://tools.ietf.org/html/draft-moskowitz-drip-uas-rid-04
Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-drip-uas-rid
Diff: https://www.ietf.org/rfcdiff?url2=draft-moskowitz-drip-uas-rid-04

Abstract:
This document describes the use of Hierarchical Host Identity Tags
(HHITs) as a self-asserting and thereby trustable Identifier for use
as the UAS Remote ID. HHITs include explicit hierarchy to provide
Registrar discovery for 3rd-party ID attestation.



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.

The IETF Secretariat




--
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
--------------669AFCAB94B738A1D0A2BD5D-- From nobody Thu Aug 13 08:08:56 2020 Return-Path: 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 C7DE33A0CB2 for ; Thu, 13 Aug 2020 08:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, 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 (2048-bit key) header.d=gmail.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 PysvPGTdNj5g for ; Thu, 13 Aug 2020 08:08:50 -0700 (PDT) Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 586203A0CB3 for ; Thu, 13 Aug 2020 08:08:50 -0700 (PDT) Received: by mail-vk1-xa2f.google.com with SMTP id k1so1337594vkb.7 for ; Thu, 13 Aug 2020 08:08:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9tm9Q8zRFmpHp9aU14ecLD7yIyLbiQDKlytH3c+HcSk=; b=XCA9ex17381r2SFYYvX9x+ul4CaiYQdBeJNga5Qy9ejxMSXLWnEpEskAo04Im6PeUm J0gTDy6xvNw2mAKHXDZUSckjyKt2pm5ck4XJ1Pcm17N/ODZPKqDToUf5oGfCyCh13AqB fCusHK3HexC0K2DV5sWDQIvlxzohgUP2qLna/DrD2J0ddoF5Dy4wrk3bE3zrA+nyTPTF s9XxuIfOnyceZsghObtvL1tFAfeyaUdfpVBD+BbpEVoA8qmcZoMwtFYQDc+u1+G6mQiV zxgmOrfzvKuTyf9fgYKCS3E2tTDGVZkWF2sY4qczUETqwVHK4BDL8RlL00ducrjovipF H0Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9tm9Q8zRFmpHp9aU14ecLD7yIyLbiQDKlytH3c+HcSk=; b=QJ+mQxJiKNwN9NxR68rfkFvWDmhnrVGVC5bvVqY/DHElGUeHP3ImhZ09ctuWylnM3G gHRt6JaJ427c2G1q9mqEntO2oiVRzfuUkE8sxNB8JfDnzegUCd4pYbyyvLhbP8nvokvE hJQw12WgZEGOJYq+7ECl8apc4RnI1jjVPUjhQHZ4NWmnB3kuAyPOyJR2hlDLSeLDOD5L 3CCpq9T4KT++bo7Sq7oHXkZvjCxtJ33BHYwl7bPIEjM45xKqKe66jfWSZzdhoroPEYHU jBMl3RC/uZgnRsovC68FVGcMAdzJoHQfJuHgP9oVtKO2qw5go9iycX11HyvoymZVh9QL kBEw== X-Gm-Message-State: AOAM533/hFZfPfAQYJJnQpIi5LLI/U707j3ANAVMCsLLK27tTuJlA+1c +ZUyTRMi+bp5wzLtFxS+gz5E13oiBHg+lcrPcbhM6A== X-Google-Smtp-Source: ABdhPJzFufjSdmhLPjp5siDk/YBO6ShHdCblITZHGfnll6eYeExlrQmsUzCGtgXM5sp43Mpnh7ZoYLnqxBpJ9ZGWDPo= X-Received: by 2002:a1f:734a:: with SMTP id o71mr3695948vkc.89.1597331329341; Thu, 13 Aug 2020 08:08:49 -0700 (PDT) MIME-Version: 1.0 References: <159717351793.27599.15158252127680658538@ietfa.amsl.com> In-Reply-To: From: Daniel Migault Date: Thu, 13 Aug 2020 11:08:38 -0400 Message-ID: To: Robert Moskowitz Cc: "tm-rid@ietf.org" Content-Type: multipart/alternative; boundary="000000000000795d9805acc3ae7d" Archived-At: Subject: Re: [Drip] Fwd: New Version Notification for draft-moskowitz-drip-uas-rid-04.txt X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 15:08:55 -0000 --000000000000795d9805acc3ae7d Content-Type: text/plain; charset="UTF-8" I do not mind having appendices. I see these as sections anyway which may be moved up in the document if needed. In any case, I think that merging these draft will be helpful to move the work forward. Yours, Daniel On Wed, Aug 12, 2020 at 7:49 AM Robert Moskowitz wrote: > I have been reviewing the various drafts and am figuring that the easiest > way to merge the documents is by adding appendices. One will be for > Hierarchical HITs, and the other for ORCHIDs. > > Comments before I start all the writing/cutting/pasting? > > thanks > > > On 8/11/20 3:23 PM, Robert Moskowitz wrote: > > Edits suggested by Med. > > Med also recommends that I make this more of a self-standing draft. That > is not to need the Normative reverences to new HIP drafts. This is a > reversal of what some asked me to do back in November. So I published this > version as a 'clean' point before rolling up the drafts into this one (and > probably replacing the HIT-Registry draft with EPP). > > So please start reviewing this draft and I will be working on more edits > shortly. > > Bob > > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-moskowitz-drip-uas-rid-04.txt > Date: Tue, 11 Aug 2020 12:18:37 -0700 > From: internet-drafts@ietf.org > To: Adam Wiethuechter > , Andrei Gurtov > , Stuart Card > , Robert Moskowitz > , Stuart W. Card > > > > A new version of I-D, draft-moskowitz-drip-uas-rid-04.txt > has been successfully submitted by Robert Moskowitz and posted to the > IETF repository. > > Name: draft-moskowitz-drip-uas-rid > Revision: 04 > Title: UAS Remote ID > Document date: 2020-08-11 > Group: Individual Submission > Pages: 11 > URL: > https://www.ietf.org/internet-drafts/draft-moskowitz-drip-uas-rid-04.txt > Status: https://datatracker.ietf.org/doc/draft-moskowitz-drip-uas-rid/ > Htmlized: https://tools.ietf.org/html/draft-moskowitz-drip-uas-rid-04 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-moskowitz-drip-uas-rid > Diff: https://www.ietf.org/rfcdiff?url2=draft-moskowitz-drip-uas-rid-04 > > Abstract: > This document describes the use of Hierarchical Host Identity Tags > (HHITs) as a self-asserting and thereby trustable Identifier for use > as the UAS Remote ID. HHITs include explicit hierarchy to provide > Registrar discovery for 3rd-party ID attestation. > > > > 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. > > The IETF Secretariat > > > > > -- > 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 > -- > Tm-rid mailing list > Tm-rid@ietf.org > https://www.ietf.org/mailman/listinfo/tm-rid > -- Daniel Migault Ericsson --000000000000795d9805acc3ae7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I do not mind having appendices. I see these as sections a= nyway which may be moved up in the document if needed. In any case, I think= that merging these draft will be helpful to move the work forward.=C2=A0
Yours,=C2=A0
Daniel

On Wed, Aug 12, 2020 at 7:49 = AM Robert Moskowitz <rgm@lab= s.htt-consult.com> wrote:
=20 =20 =20
I have been reviewing the various drafts and am figuring that the easiest way to merge the documents is by adding appendices.=C2=A0 One will be for Hierarchical HITs, and the other for ORCHIDs.

Comments before I start all the writing/cutting/pasting?

thanks


On 8/11/20 3:23 PM, Robert Moskowitz wrote:
=20 Edits suggested by Med.

Med also recommends that I make this more of a self-standing draft.=C2=A0 That is not to need the Normative reverences to new HIP drafts.=C2=A0 This is a reversal of what some asked me to do back in November.=C2=A0 So I published this version as a 'clean' poin= t before rolling up the drafts into this one (and probably replacing the HIT-Registry draft with EPP).

So please start reviewing this draft and I will be working on more edits shortly.

Bob


-------- Forwarded Message --------
Subject: New Version Notification for draft-moskowitz-drip-uas-rid-04.txt
Date: Tue, 11 Aug 2020 12:18:37 -0700
From: internet-drafts@ietf.org
To: Adam Wiethuechter <adam.wiethuechter@axenterprize.com>= , Andrei Gurtov <gurtov@acm.org>, Stuart Card <stu.card@axenterprize.com>, Robert Moskowitz <rgm@labs.htt-consult.com>, Stuart W. Card <stu.card@axenterprize.com>



A new version of I-D, draft-moskowitz-drip-uas-rid-04.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-drip-uas-rid
Revision: 04
Title: UAS Remote ID
Document date: 2020-08-11
Group: Individual Submission
Pages: 11
URL: https://www.ietf.org/internet-draf= ts/draft-moskowitz-drip-uas-rid-04.txt
Status: https://datatracker.ietf.org/doc/draft-mo= skowitz-drip-uas-rid/
Htmlized: https://tools.ietf.org/html/draft-moskowit= z-drip-uas-rid-04
Htmlized: https://datatracker.ietf.org/doc/ht= ml/draft-moskowitz-drip-uas-rid
Diff: https://www.ietf.org/rfcdiff?url2=3Ddr= aft-moskowitz-drip-uas-rid-04

Abstract:
This document describes the use of Hierarchical Host Identity Tags
(HHITs) as a self-asserting and thereby trustable Identifier for use
as the UAS Remote ID. HHITs include explicit hierarchy to provide
Registrar discovery for 3rd-party ID attestation.



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<= /a>.

The IETF Secretariat




--
Tm-rid mailing list
Tm-rid@ietf.org https://www.ietf.org/mailman/listinfo/tm-rid


--
Daniel Migault
Ericsson
--000000000000795d9805acc3ae7d-- From nobody Thu Aug 13 12:55:48 2020 Return-Path: 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 6348A3A10E5 for ; Thu, 13 Aug 2020 12:55:40 -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, 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 5mX2YYkqAWIK for ; Thu, 13 Aug 2020 12:55:38 -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 705CE3A10DB for ; Thu, 13 Aug 2020 12:55:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id F39FF624D4 for ; Thu, 13 Aug 2020 15:55:36 -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 IS1zabE1Lbrp for ; Thu, 13 Aug 2020 15:55:29 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (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 A5F70622C2 for ; Thu, 13 Aug 2020 15:55:29 -0400 (EDT) References: <159734822583.20335.8184851686013037599@ietfa.amsl.com> To: "tm-rid@ietf.org" From: Robert Moskowitz X-Forwarded-Message-Id: <159734822583.20335.8184851686013037599@ietfa.amsl.com> Message-ID: Date: Thu, 13 Aug 2020 15:55:21 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <159734822583.20335.8184851686013037599@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------907F3EC26A40D9D5937DF15B" Content-Language: en-US Archived-At: Subject: [Drip] Fwd: New Version Notification for draft-moskowitz-drip-uas-rid-05.txt X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 19:55:48 -0000 This is a multi-part message in MIME format. --------------907F3EC26A40D9D5937DF15B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Well I did it.  At least the first pass and now a call for review. I had to add major sections of: draft-moskowitz-hip-hierarchical-hit draft-moskowitz-orchid-cshake draft-moskowitz-hip-new-crypto Plus clean up references to these drafts.  I don'gt claim that I got all I needed from them (or too much), nor that the new single document 'flows', so I am asking for review. I still want to add to the reqs met section per Med to summarize how this draft meets them. So please take a read and provide comments.  Interim is next week and I want this moving toward wg adoption. thanks -------- Forwarded Message -------- Subject: New Version Notification for draft-moskowitz-drip-uas-rid-05.txt Date: Thu, 13 Aug 2020 12:50:25 -0700 From: internet-drafts@ietf.org To: Robert Moskowitz , Stuart W. Card , Adam Wiethuechter , Andrei Gurtov , Stuart Card A new version of I-D, draft-moskowitz-drip-uas-rid-05.txt has been successfully submitted by Robert Moskowitz and posted to the IETF repository. Name: draft-moskowitz-drip-uas-rid Revision: 05 Title: UAS Remote ID Document date: 2020-08-13 Group: Individual Submission Pages: 18 URL: https://www.ietf.org/internet-drafts/draft-moskowitz-drip-uas-rid-05.txt Status: https://datatracker.ietf.org/doc/draft-moskowitz-drip-uas-rid/ Htmlized: https://tools.ietf.org/html/draft-moskowitz-drip-uas-rid-05 Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-drip-uas-rid Diff: https://www.ietf.org/rfcdiff?url2=draft-moskowitz-drip-uas-rid-05 Abstract: This document describes the use of Hierarchical Host Identity Tags (HHITs) as a self-asserting and thereby trustable Identifier for use as the UAS Remote ID. HHITs include explicit hierarchy to provide Registrar discovery for 3rd-party ID attestation. 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. The IETF Secretariat --------------907F3EC26A40D9D5937DF15B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Well I did it.  At least the first pass and now a call for review.

I had to add major sections of:

draft-moskowitz-hip-hierarchical-hit
draft-moskowitz-orchid-cshake
draft-moskowitz-hip-new-crypto

Plus clean up references to these drafts.  I don'gt claim that I got all I needed from them (or too much), nor that the new single document 'flows', so I am asking for review.

I still want to add to the reqs met section per Med to summarize how this draft meets them.

So please take a read and provide comments.  Interim is next week and I want this moving toward wg adoption.

thanks


-------- Forwarded Message --------
Subject: New Version Notification for draft-moskowitz-drip-uas-rid-05.txt
Date: Thu, 13 Aug 2020 12:50:25 -0700
From: internet-drafts@ietf.org
To: Robert Moskowitz <rgm@labs.htt-consult.com>, Stuart W. Card <stu.card@axenterprize.com>, Adam Wiethuechter <adam.wiethuechter@axenterprize.com>, Andrei Gurtov <gurtov@acm.org>, Stuart Card <stu.card@axenterprize.com>



A new version of I-D, draft-moskowitz-drip-uas-rid-05.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-drip-uas-rid
Revision: 05
Title: UAS Remote ID
Document date: 2020-08-13
Group: Individual Submission
Pages: 18
URL: https://www.ietf.org/internet-drafts/draft-moskowitz-drip-uas-rid-05.txt
Status: https://datatracker.ietf.org/doc/draft-moskowitz-drip-uas-rid/
Htmlized: https://tools.ietf.org/html/draft-moskowitz-drip-uas-rid-05
Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-drip-uas-rid
Diff: https://www.ietf.org/rfcdiff?url2=draft-moskowitz-drip-uas-rid-05

Abstract:
This document describes the use of Hierarchical Host Identity Tags
(HHITs) as a self-asserting and thereby trustable Identifier for use
as the UAS Remote ID. HHITs include explicit hierarchy to provide
Registrar discovery for 3rd-party ID attestation.



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.

The IETF Secretariat


--------------907F3EC26A40D9D5937DF15B-- From nobody Thu Aug 13 13:17:11 2020 Return-Path: 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 8837A3A10CB for ; Thu, 13 Aug 2020 13:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, 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 RzPbwo1SHo2K for ; Thu, 13 Aug 2020 13:17:07 -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 C24383A10C7 for ; Thu, 13 Aug 2020 13:17:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 9190E624D4 for ; Thu, 13 Aug 2020 16:17:06 -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 UxL75S73uum2 for ; Thu, 13 Aug 2020 16:16:58 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (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 1D83C622C2 for ; Thu, 13 Aug 2020 16:16:58 -0400 (EDT) From: Robert Moskowitz To: "tm-rid@ietf.org" References: <159734822583.20335.8184851686013037599@ietfa.amsl.com> Message-ID: <5236f08b-1452-e8e7-636e-b42624095dfe@labs.htt-consult.com> Date: Thu, 13 Aug 2020 16:16:35 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------33E5C713FB71A4C284290787" Content-Language: en-US Archived-At: Subject: Re: [Drip] Fwd: New Version Notification for draft-moskowitz-drip-uas-rid-05.txt X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 20:17:11 -0000 This is a multi-part message in MIME format. --------------33E5C713FB71A4C284290787 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Oh, I also need to update sec 3.2 to reference EPP rather than my hip-registry draft. Michael and/or Amelia...  Help?  Or any other EPP experts.  Thanks. On 8/13/20 3:55 PM, Robert Moskowitz wrote: > Well I did it.  At least the first pass and now a call for review. > > I had to add major sections of: > > draft-moskowitz-hip-hierarchical-hit > draft-moskowitz-orchid-cshake > draft-moskowitz-hip-new-crypto > > Plus clean up references to these drafts.  I don'gt claim that I got > all I needed from them (or too much), nor that the new single document > 'flows', so I am asking for review. > > I still want to add to the reqs met section per Med to summarize how > this draft meets them. > > So please take a read and provide comments.  Interim is next week and > I want this moving toward wg adoption. > > thanks > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-moskowitz-drip-uas-rid-05.txt > Date: Thu, 13 Aug 2020 12:50:25 -0700 > From: internet-drafts@ietf.org > To: Robert Moskowitz , Stuart W. Card > , Adam Wiethuechter > , Andrei Gurtov , > Stuart Card > > > > > A new version of I-D, draft-moskowitz-drip-uas-rid-05.txt > has been successfully submitted by Robert Moskowitz and posted to the > IETF repository. > > Name: draft-moskowitz-drip-uas-rid > Revision: 05 > Title: UAS Remote ID > Document date: 2020-08-13 > Group: Individual Submission > Pages: 18 > URL: > https://www.ietf.org/internet-drafts/draft-moskowitz-drip-uas-rid-05.txt > Status: https://datatracker.ietf.org/doc/draft-moskowitz-drip-uas-rid/ > Htmlized: https://tools.ietf.org/html/draft-moskowitz-drip-uas-rid-05 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-moskowitz-drip-uas-rid > Diff: https://www.ietf.org/rfcdiff?url2=draft-moskowitz-drip-uas-rid-05 > > Abstract: > This document describes the use of Hierarchical Host Identity Tags > (HHITs) as a self-asserting and thereby trustable Identifier for use > as the UAS Remote ID. HHITs include explicit hierarchy to provide > Registrar discovery for 3rd-party ID attestation. > > > > 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. > > The IETF Secretariat > > > -- 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 --------------33E5C713FB71A4C284290787 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Oh,

I also need to update sec 3.2 to reference EPP rather than my hip-registry draft.

Michael and/or Amelia...  Help?  Or any other EPP experts.  Thanks.

On 8/13/20 3:55 PM, Robert Moskowitz wrote:
Well I did it.  At least the first pass and now a call for review.

I had to add major sections of:

draft-moskowitz-hip-hierarchical-hit
draft-moskowitz-orchid-cshake
draft-moskowitz-hip-new-crypto

Plus clean up references to these drafts.  I don'gt claim that I got all I needed from them (or too much), nor that the new single document 'flows', so I am asking for review.

I still want to add to the reqs met section per Med to summarize how this draft meets them.

So please take a read and provide comments.  Interim is next week and I want this moving toward wg adoption.

thanks


-------- Forwarded Message --------
Subject: New Version Notification for draft-moskowitz-drip-uas-rid-05.txt
Date: Thu, 13 Aug 2020 12:50:25 -0700
From: internet-drafts@ietf.org
To: Robert Moskowitz <rgm@labs.htt-consult.com>, Stuart W. Card <stu.card@axenterprize.com>, Adam Wiethuechter <adam.wiethuechter@axenterprize.com>, Andrei Gurtov <gurtov@acm.org>, Stuart Card <stu.card@axenterprize.com>



A new version of I-D, draft-moskowitz-drip-uas-rid-05.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-drip-uas-rid
Revision: 05
Title: UAS Remote ID
Document date: 2020-08-13
Group: Individual Submission
Pages: 18
URL: https://www.ietf.org/internet-drafts/draft-moskowitz-drip-uas-rid-05.txt
Status: https://datatracker.ietf.org/doc/draft-moskowitz-drip-uas-rid/
Htmlized: https://tools.ietf.org/html/draft-moskowitz-drip-uas-rid-05
Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-drip-uas-rid
Diff: https://www.ietf.org/rfcdiff?url2=draft-moskowitz-drip-uas-rid-05

Abstract:
This document describes the use of Hierarchical Host Identity Tags
(HHITs) as a self-asserting and thereby trustable Identifier for use
as the UAS Remote ID. HHITs include explicit hierarchy to provide
Registrar discovery for 3rd-party ID attestation.



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.

The IETF Secretariat




--
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
--------------33E5C713FB71A4C284290787-- From nobody Thu Aug 13 15:13:03 2020 Return-Path: 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 5A63B3A0853 for ; Thu, 13 Aug 2020 15:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fNHiag81Hhij for ; Thu, 13 Aug 2020 15:13:00 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E1663A084D for ; Thu, 13 Aug 2020 15:12:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 7E226389AA; Thu, 13 Aug 2020 17:52:10 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id VA_m4Ug1uduG; Thu, 13 Aug 2020 17:52:09 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4520E389A6; Thu, 13 Aug 2020 17:52:09 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CA43A319; Thu, 13 Aug 2020 18:12:55 -0400 (EDT) From: Michael Richardson To: Robert Moskowitz , tm-rid@ietf.org In-Reply-To: <42e3a4a7-12df-91d9-922d-8c75cb01fca4@labs.htt-consult.com> References: <42e3a4a7-12df-91d9-922d-8c75cb01fca4@labs.htt-consult.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Drip] Authentication Formats Follow-Up X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 22:13:02 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Robert Moskowitz wrote: > First a UA moving at 60MPH =3D ~42FPS.=C2=A0 So you have 7s warning w= ith BT4 and > ~42s with BT5. I couldn't figure your weird provincial units out. :-) FPS =3D> (BT) Frames per second ??? [naturally, at first, I'm thinkin= g video] Ah, FPS =3D feet per second. So, with BT4 you can't get anything until it's 300 feet away, but BT5, mean= s it can be 1764 feet away. Did I get that right? > Now this is bad in his worst timing of 45s and even 2s eats up critic= al time > to respond, but things are really not so bleak. Adam's code is in Pyt= hon and > quite removed from the actual radio driver.=C2=A0 Let's look over at: > See: https://www.bluetooth.com/blog/exploring-bluetooth-5-how-fast-ca= n-it-be/ > One BT 4 packet takes 80 + 150 + 328 + 150 =C2=B5s =3D 708=C2=B5s > I do not think BT has an cts/rts like wifi.=C2=A0 So the UA COULD str= eam the 10 > auth frames and: > So 10 take 7.08ms.=C2=A0 Closer to radio coding will greatly reduce t= iming.. How often will it (re)transmit? =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl81uucACgkQgItw+93Q 3WVoUQf/Yrn6aaHwMqC1EDV8HPcYQBtJwwvB97Y9L6siDYpv78g86IOixBLxX5vk NfP49RtlX+bald/+8c0eexubVknPdUWVCMknm7Yp4L8b/U/d6uNAWW1Q/yP91I39 FqDevyFfECPtyz3tm78EiUGCF2uljVpkfAr6mKFIa4lkW9LnQ9afyz3JXoU6Blex rlIoRDx/IyKtAV0WGKqZuFpTS0nTUSJGXOXN3PdSJHVs4+ez9ZQsDhqV3J6IOStP SPTUKkeybYQo4iOm1/EhbVVfS6PucaPGer/gb/17zBBljtTE8vDaeBKGghAqfLbg BjthbvMr1cHCEgTVmTxUowRMpmWBYQ== =lm3B -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 13 15:41:51 2020 Return-Path: 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 F1FB03A09B8 for ; Thu, 13 Aug 2020 15:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-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 gRIWZHFKkegH for ; Thu, 13 Aug 2020 15:41:49 -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 339EA3A09B4 for ; Thu, 13 Aug 2020 15:41:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id E4B56624D4; Thu, 13 Aug 2020 18:41:46 -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 EaHOIGPIYCrk; Thu, 13 Aug 2020 18:41:38 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (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 B2A85622C2; Thu, 13 Aug 2020 18:41:35 -0400 (EDT) To: Michael Richardson , tm-rid@ietf.org References: <42e3a4a7-12df-91d9-922d-8c75cb01fca4@labs.htt-consult.com> <2702.1597356775@localhost> From: Robert Moskowitz Message-ID: <2189d58b-7728-ad89-ecd3-4662e24ce7b7@labs.htt-consult.com> Date: Thu, 13 Aug 2020 18:41:31 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <2702.1597356775@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Drip] Authentication Formats Follow-Up X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 22:41:51 -0000 On 8/13/20 6:12 PM, Michael Richardson wrote: > Robert Moskowitz wrote: > > First a UA moving at 60MPH = ~42FPS.  So you have 7s warning with BT4 and > > ~42s with BT5. > > I couldn't figure your weird provincial units out. :-) > FPS => (BT) Frames per second ??? [naturally, at first, I'm thinking video] > > Ah, FPS = feet per second. > So, with BT4 you can't get anything until it's 300 feet away, but BT5, means it > can be 1764 feet away. Did I get that right? See Adam's slides as to the distances he was picking up BT4 and BT5 in an open airport. I just used a web calculator of Miles per Hour to Feet per Second and 60 MPH = 88FPS.  Ugh. So that is like only a 4sec time until that UA hits you with BT4 range.  But ~20sec with BT5.  Not good at all... > > Now this is bad in his worst timing of 45s and even 2s eats up critical time > > to respond, but things are really not so bleak. Adam's code is in Python and > > quite removed from the actual radio driver.  Let's look over at: > > > See: https://www.bluetooth.com/blog/exploring-bluetooth-5-how-fast-can-it-be/ > > > One BT 4 packet takes 80 + 150 + 328 + 150 µs = 708µs > > > I do not think BT has an cts/rts like wifi.  So the UA COULD stream the 10 > > auth frames and: > > > So 10 take 7.08ms.  Closer to radio coding will greatly reduce timing.. > > How often will it (re)transmit? It is still unclear what FAA will require.  I think the proposed rules is at least once per sec. Of course, the vendors will want to do this as seldom as possible as it interferes with their UA control.  If the UA only has one radio that it needs for both C2 and Broadcast RID, C2 wins in priority. From nobody Thu Aug 13 18:08:40 2020 Return-Path: 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 25C913A0BAA for ; Thu, 13 Aug 2020 18:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1E1n_xDLFT7q for ; Thu, 13 Aug 2020 18:08:37 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C6093A0B6E for ; Thu, 13 Aug 2020 18:08:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 94E89389AA for ; Thu, 13 Aug 2020 20:47:48 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 00qSliNjAPEt for ; Thu, 13 Aug 2020 20:47:47 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 496C8389A9 for ; Thu, 13 Aug 2020 20:47:47 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id EB1A963E for ; Thu, 13 Aug 2020 21:08:33 -0400 (EDT) From: Michael Richardson To: "tm-rid\@ietf.org" In-Reply-To: <21b0bbc3-6582-45a5-f13f-1f1fb06885b4@labs.htt-consult.com> References: <21b0bbc3-6582-45a5-f13f-1f1fb06885b4@labs.htt-consult.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Drip] some comments on ietf-drip-reqs-03 X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 01:08:39 -0000 --=-=-= Content-Type: text/plain I am reading these documents for the first time since the site meetings last summer. I have not read the architecture yet. So far, I do not think the documents should be merged, but there is content that I think is superfluous, and may be in the wrong place. > [F3411-19] specifies three UAS ID types: > > TYPE-1 A static, manufacturer assigned, hardware serial number per > ANSI/CTA-2063-A "Small Unmanned Aerial System Serial Numbers" > [CTA2063A]. > > TYPE-2 A CAA assigned (presumably static) ID. > > TYPE-3 A UTM system assigned UUID [RFC4122], which can but need not > be dynamic. > > The EU allows only Type 1; the US allows Types 1 and 3, but requires > Type 3 IDs (if used) each to be used only once (for a single UAS Who allows/requires Type-2? (Some AD will ask that question ...) > specifies only how to get the UAS ID to the Observer; how the > Observer can perform these lookups, and how the registries first can > be populated with information, is unspecified. Given that this is a requirements document in the IETF, the question about how the lookups are performed/secured, and populated needs to clarified. The possible answers are, I think: a) this work will occur within body XYZ (not the IETF) b) the fora for this work has not been determined, and the determination will be done by ABC (not the IETF) c) this is potential future work for the IETF, but is beyond this architecture > applications such as Detect And Avoid (DAA, which would impose > tighter latency bounds than RID itself) is an obvious possibility, please avoid additional comments when (TLA). I suggest: } applications such as Detect And Avoid (DAA) is an obvious possibility, } Use of RID for DAA would impose tighter latency bounds than UAS RID } needs alone. > UA onboard RID devices are severely constrained in Cost, Size, Weight > and Power ($SWaP). Cost is a significant impediment to the necessary Since CSWP does not seem to spell $SWAP, the parenthical does not seem to fit quite. Until one realizes that Cost => $. I suggest: } UA onboard RID devices are severely constrained in cost($), Size, Weight } and Power, known as: $SWaP. Cost is a significant impediment to the necessary I think that section 1 is pretty good. If the requirements stopped there, that would be fine. Terminology usually goes into Architecture document. The terminology is rather extensive, and I doubt we need it all. Maybe some of the less common aviation things could go into an appendix. For instance: we probably don't need "SDO". Meanwhile, "IFF" is not in the list. Section 3 suggests multiple possible threats. I wasn't sure why this section was here at atll. I would explicitely identify as your list of threats, rather than calling it a problem space. I think that 3.1 is architecture. I think you might want a summary of existing work. I think that 3.2 goes into that. 3.3 does not follow from 3.2. Maybe 3.3 is requirements. So rather than: DRIP will focus on making information obtained via UAS RID immediately usable: 1. by making it trustworthy (despite the severe constraints of Broadcast RID); say: A DRIP solution will focus on making the UAS RID trustworthy. REQ01. A DRIP solution will enable an Observer to verify if a UAS registered, even if the Observer has no active Internet connectivity. ... Any UA can assert any ID using the [F3411-19] required Basic ID message, which lacks any provisions for verification. The Position/ Vector message likewise lacks provisions for verification, and does not contain the ID, so must be correlated somehow with a Basic ID message: the developers of [F3411-19] have suggested using the MAC addresses, but these may be randomized by the operating system stack to avoid the adversarial correlation problems of static identifiers. becomes something like: REQ0x: the DRIP solution will suggest a mechanism to correlate Position/Vector messages with UAS RID messages that does is tolerant of per Operation randomization of MAC addresses. {Yes, operating systems random MAC addresses, but usually not within 2 hours. It seems like a regulator could demand a single Operation use the same MAC addr} Further, [F3411-19] provides very limited choices for an observer to communicate with the pilot, e.g., to request further information on the UAS operation or exit from an airspace volume in an emergency. The System Message provides the location of the pilot/GCS, so an observer could physically go to the asserted GCS location to look for this seems to suggest something like: REQ0n: the UAS RID will provide an identifier that can be used to securely index into a directory, in real time, that would provide for ... GCS/phonenumber/etc. to authorized entities. {It seems like there could also be some kind of pseudonymous rendezvous, that would allow friendly operators to discover each other} Then you get into actual requirements, which I think you already got into. GEN-1 contains at least four things. *message integrity/non-repudiation*, *defense against replay attacks*, *defense against spoof*, *connected to a sender public key* (GEN-3?), *Observer without Internet* GEN-7 says nothing to me. I don't know who the parties are for this QoS, and I don't think BT4 supports any things like "delivery latencies", so maybe you are talking about Network-RID? Section 5. IETF traditionally operates assuming the source material for the standardization process is publicly available. However, ASTM standards require a fee for download. This doesn't belong in the document here, but it is important. It should go into a charter revision, or some other WG plan. I suggest that the process here is that the reqs and architecture are going to quote and/or paraphrase as much as the ASTM specifications as required in order to be stand-alone. Or, ASTM can post the documents publically already. I don't think section 5 is requirements. I don't quite get why the discussion of ADS-B, etc. I think that this has already been ruled out by ATSM, so that's really all that matters. If it needs to be covered, put it into an appendix. The Security Considerations for a requirements document does not need to list vulnerabilities like this, in my opinion. Rather, it needs to simply repeat which requirements are hard security requirements, and which ones may be less important. Privacy section is great. The privacy section should point at a requirement somewhere, about how "public safety personnel" are identified. This document should not solve that question, but say whether or not it (or some part of it) is in scope for the architecture. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl815BEACgkQgItw+93Q 3WVvjQf+K/22NEXJxOGWSsCLTeWA2DzDpPPV8r2AV2WEkI/qLD2/xRHbLbb6LWNW UT+6Q9xAoLKiYaIE7WhZfLfldc31HnHIw7u2xwCW/USwFQrv/UYKB8ZqKNASI/iD jLq07u7+WSBGLe5OUu0uIOjcp6Nw8RPuTs6gsT/WC6N1Z+nBnOD+7gi8uK9Jyqj5 I3OX0h+vl7iIv9CSrxemGQnUMbmN+4gy0gYkij4Eb0exB5Qe6czhQgCYJjHgBzIW MY7pdXYy9Xb2m7bcAmY+6TGFFWAvCLMJb64cd9zVvZmuxHHQso4UOca89rJ8wbVY fxebXZ0JEUzfM6DbC5eCqcz/XtMTkQ== =W59o -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 13 19:10:13 2020 Return-Path: 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 5B3FD3A0C08 for ; Thu, 13 Aug 2020 19:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 QyJ69R-sRESa for ; Thu, 13 Aug 2020 19:10:08 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EC393A0C04 for ; Thu, 13 Aug 2020 19:10:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id B699B389A9 for ; Thu, 13 Aug 2020 21:49:17 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DuWWYydsFYX2 for ; Thu, 13 Aug 2020 21:49:16 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4E4DC389A5 for ; Thu, 13 Aug 2020 21:49:16 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0476E2B3 for ; Thu, 13 Aug 2020 22:10:03 -0400 (EDT) From: Michael Richardson To: "tm-rid\@ietf.org" X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Drip] comments on drip-arch-03 X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 02:10:11 -0000 --=-=-= Content-Type: text/plain These comments are on arch-03. I was watching the video, and got to "Stu's own Questions/concerns" slide, and felt that this was a good point to move from "have not read drafts" to "have read drafts" state. First, I don't like the stick-people ade of x. One can't see their smiling faces! "There are all dead" / "Everybody's Dead" (so many memes beyond Red Dwarf) Removing those x and just using a small box would let you include a Network RID (direct from the UA and also relayed via GCS), and Broadcast RID. Also: https://metacpan.org/pod/App::Asciio (apt-get install asciio) Expand ASTM first time please. [F3411-19] ASTM, "Standard Specification for Remote ID and Tracking", December 2019. I know it costs money to buy, but URL for the entire effort? Surely, the F38.02 subcmte has a web site somewhere, or at least a wikipedia entry? --- If a UAS uses both communication methods, generally the same information must provided via both means. While hybrids are possible (and indeed one is proposed as an optional DRIP service), the two basic methods are defined as follows: Could you tell us about the hybrid after you've told us about the two options? Or just make that a third option. I suggest Network RID be a subsection with a diagram. Emphasis that this is ASTM content that you are repeating/paraphrasing. I think that jumping into Network RID/Broadcast RID in section 1.0 is too soon, and there are many TLAs that, while in the reqs document, the reader does not yet really know that they come from there. 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: I would move this up to just after: ASTM [F3411-19] Standard Specification for Remote ID and Tracking. and I'd move all the rest of the details further down. Where I don't know yet. CHANGE: Issues include, but are not limited to: * Trustworthy Remote ID and trust in RID messages * Privacy in RID messages (PII protection) * 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 To: Design aspects covered in this document include: * mechanisms to leverage Domain Name System (DNS: RFC1034) and Extensible Provisioning Protocol (EPP: RFCxxx) technology to provide for an Information Registry. (section 3.1, 3.2) * Trustworthy Remote ID and trust in RID messages (section 5) * Privacy in RID messages (PII protection) [section 6] ** Architectural accomodation for differences between FCC and EASA Requirements [section 7] * 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 {I expected to come back and edit section numbers into the last few stars, but I didn't really find the right places. That's a bug. The goal here is foreshadowing to set expectations, but also, for some readers, the point is establish what is *NOT* in this document, so that they go to the next google hit...} I think that it would be nice if the various abstractions like CAA could be turned into a story, perhaps set in some fantasy land like Lilliput, where all the involved actors have silly company names, rather than TLAs. Section 3.1/3.2 needs to get rewritten. We don't need to say "MUST support X,Y" we need to how we intend to use DNS, and there probably should be a document that is the implementation document for how to use EPP and DNS. section 3.3 CS-RID seems come out of the blue here. section 3.3.1 has too many TLAs. Net-RID DP is a poor TLA too. Maybe nrDP, but I'd rather remove "Provider" from the TLA. People get bent out of shape dealing with "DNS" not being "Domain Name Server", (but, System), so having a DNS Server makes sense, but... So I suggest nRID-Serv and nRID-Aggr (rather than Display). Does CS-RID significant alter the architecture that it needs to be discussed so early? Could it go into a separate document as an extension? It seems like it is designed to drop into between the NetRID-DS[nRID-Aggr] and NetRID-SP[nRID-Serv] interfaces without either caring. > HITs for UAS RID is outlined in HHIT based UAS RID [drip-uas-rid]. This is a document which is not yet adopted, right? That's fine. I think that the salient properties of HHITs need to be explained in two paragraphs. Why not PKI should not be the point *HERE*, but rather to explain what you are doing, rather than what you are not. > and the UTM InterUSS protocol) mappings between the more flexible but > larger X.509 certificates and the HHIT based structures must be > devised. readings like a requirement, move it to reqs. here, it should be explained how they *can* be mapped. The simplest I think of is with DTLS RRs in the DNS used by HHITs, and with a X.509 SAN that contains the HHIT. > A DRIP UAS ID MUST be a HHIT. It SHOULD be self-generated by the UAS > (either UA or GCS) and MUST be registered with the Private > Information Registry identified in its hierarchy fields. Each UAS ID Architectures are usually informational, so generally BCP14 language is not used. (I don't entirely agree with this myself) I would write instead: The DRIP UAS architecture defines the UAS ID to be a HHIT. The UAS self-generates the HHIT (see section Foo of [BAR]), and using the EPP protocol as describe in section Baz of [BAR], it registers its public and private information. This results in a HHIT being published into DNS in ... >Insert example< 4.2.2 Static HHIT. 4.2.3 Use with Broadcast RID Section 5. This is one sentence: To add an UA, an Operator MUST generate a Host Identity of the Aircraft (HIa) and derived Hierarchical HIT of the Aircraft (HHITa), create a Certificate from the Operator on the Aircraft (Coa) signed with the Host Identity of the Operator private key (HIo(priv)) to associate the UA with its Operator, register them with a Private Information Registry along with whatever UAS data is required by the cognizant CAA and the registry, obtain a Certificate from the Registry on the Operator and Aircraft ("Croa") signed with the HIr(priv) proving such registration, and obtain a Certificate from the Registry on the Aircraft (Cra) signed with HIr(priv) proving UA registration in that specific registry while preserving Operator privacy. I would expect either a narrative, or section numbers. 6. Privacy. 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. Otherwise, the modern general It seems to me that places like buffer zones around airports ought to broadcast some kind of signed statement saying that there is a policy about privacy. And places where they shoot first and ask after. I suspect that this is not in the ASTM model, so can't be added. There are probably installations which do not want drones, yet don't want reveal that they are present. It seems that this section should explain this more. A viable architecture for PII protection would be symmetric encryption of the PII using a key known to the UAS and a USS service. yes, that might be viable... is it in the architecture or not :-) section 7 seems to provide for compliance. This belongs in an appendix, possibly in another document. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl818noACgkQgItw+93Q 3WUfEQf/TkEAyWVzgR61YihRrfChwfFOicrJVl2TBK1reURJEzxsNJWt5v8vpzxD rRRiortWhVaavNvQYfsLcli0grG8i6fjwzJRwz8OsaOCI3A/JcLwbIn9v5Idzgge J9npi2jBzofyzJJe20djPdJg00/KtgmSzza3zkGOGrTUN6nURo1+ZrDfE5qxnbUj SOKVMKJ9/PnaaZdB9jnJCWjuan3P7qKq37JQNk+rm9wiqHvfKCSN9xKL5X9zkEZ3 rNfolNRQfIxuThKvA3nov2nJ1ULpQUeJh2pUW3Q1qfwzogsgmpd/BOBjQXAS6ni0 R8OFcSU8twg+Up5C+GNWmYUpCGLe/Q== =jNUi -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 13 20:26:17 2020 Return-Path: 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 CC5793A0C7E for ; Thu, 13 Aug 2020 20:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 X8Gkji-qkXaa for ; Thu, 13 Aug 2020 20:26:14 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F67C3A0C7B for ; Thu, 13 Aug 2020 20:26:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 68D88389B1; Thu, 13 Aug 2020 23:05:24 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rwT5Y9tRz8vg; Thu, 13 Aug 2020 23:05:23 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 9B0AA389B0; Thu, 13 Aug 2020 23:05:22 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 604712B3; Thu, 13 Aug 2020 23:26:09 -0400 (EDT) From: Michael Richardson To: Robert Moskowitz , "tm-rid\@ietf.org" In-Reply-To: <21b0bbc3-6582-45a5-f13f-1f1fb06885b4@labs.htt-consult.com> References: <21b0bbc3-6582-45a5-f13f-1f1fb06885b4@labs.htt-consult.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Drip] DRIP UAS RID X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 03:26:16 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Robert Moskowitz wrote: > Please review and comment on: > =C2=A0=C2=A0=C2=A0 draft-moskowitz-drip-uas-rid-03 I found section 5 to be too nebulous. I guess this is discussion about possibilities... but which one do your favour? I found the DNSSEC comment odd. yes, 63M is a bit zone. But, .com has 359M names, and it seems like the pieces under hhit.arpa could be sharded quite easily. > This draft references: > The actual format of HHIT in: > =C2=A0=C2=A0=C2=A0 draft-moskowitz-hip-hierarchical-hit-05 > Please comment on the division of the 96 bits allocation and 2 levels= of > hierarchy. okay. I had to read through things a bit, including into RFC6890 to understand the allocation rules for 2001::/23. I was thinking, if there are 182 authoriti= es (if I heard that right, i.e. less than 2^8) in the world, maybe they could all just ask IANA directly, leaving us with 16 more bits for the hash. But our process won't allow that. I'm also a bit unclear about how much space they actually have here, since ORCHID got a /28 here under 2001:00_00::/23, while 2001:db8::/32 is not actually inside 2001:00_00::/23, if I'm doing my math right :-) If you want more bits for the hash, then I would go for: * 28 bit IANA prefix * 12 bit Registered Assigning Authority (RAA) * 16 bit Hierarchical HIT Domain Authority (HDA) * 4 bit HIT Suite ID * 68 bit ORCHID hash > Suite ID can be used for HHITs, provided that the prefix for HHITs is > different from flat space HITs. Without a unique prefix, > Section 4.1, additional HIT Suite IDs would be needed for HHITs. > This would risk exhausting the limited Suite ID space of only 15 IDs. Either I don't understand, or this text is confusing. I think the point is that if we don't have SuiteID, as we didn't for ORCHID= v1 (?) then we'd have to go back to IANA for a new prefix every time we wanted a n= ew set of algorihms. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl82BFAACgkQgItw+93Q 3WUnwggAnqBvkc2bXmG8N1lGMGfWLv2SoDzcn0ZBq4VNWyR4GRbUxyfgqQUgGmXj Bd95xPJoselBEt9E13Hs2chAMHkosOBlHAr79hDox0T0RNFv4ez5rqrUaE4P8hEp sHabY1bg5bxZQEQSTIaJLt6SXj1gfgyv22npEJJXtiA4apdpkzSoD3DIDxu4I5YD yzrDdQares1S+26MbWMFg3ln1lxJ1Zv4RojNuJzQByRTzI3Qnl2q/zpVorbV2F3+ tC3Cc4ZXRNRnsGbNZYEILOkHhtJTUG4029mtYxRAmVg6WMFAONUbnE2nbHHJD1Ol NZkXHP9j77gKQ9SM7kFVfvFREH3bNg== =CCZG -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 13 20:27:07 2020 Return-Path: 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 A191E3A0C7E for ; Thu, 13 Aug 2020 20:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 gZaMhIbJGAVD for ; Thu, 13 Aug 2020 20:27:04 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C33EE3A0C7A for ; Thu, 13 Aug 2020 20:27:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id E8D71389B1; Thu, 13 Aug 2020 23:06:15 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 43oEd2Ro5ftk; Thu, 13 Aug 2020 23:06:14 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9270E389B0; Thu, 13 Aug 2020 23:06:14 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 58F072B3; Thu, 13 Aug 2020 23:27:01 -0400 (EDT) From: Michael Richardson To: "Wiethuechter\, Adam" , tm-rid@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Drip] Authentication Framing Structs & DRIP Header X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 03:27:06 -0000 --=-=-= Content-Type: text/plain Wiethuechter, Adam wrote: > At yesterday's session I quickly reviewed our new framing structures for > Authentication Messages along with the 1 byte DRIP Header. > On slide 13 I posed the question; "Is this the best way to carve up this > single byte?" I think that I don't understand the stressors involved :-) > I will further extend this question here to ask if the entire method for > formatting seems reasonable. I will be happy to clarify anything that does > not currently make sense and explain the reasoning behind the structures if > required. > Does anyone have any questions, comments or concerns on this? > -- > 73's, > Adam T. Wiethuechter > AX Enterprize, LLC > ---------------------------------------------------- > Alternatives: > ---------------------------------------------------- > -- > Tm-rid mailing list > Tm-rid@ietf.org > https://www.ietf.org/mailman/listinfo/tm-rid -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl82BIUACgkQgItw+93Q 3WUmUwf/ZFxGVMS7+3Ca3wcrtCRhQp0ZA5bf4RK7pNB282633u6FD4gwVbmPV3x0 lpNkzISf0TUd2HMOQax5zKvK3Ju15scrsRw50LrY5a2OyvYiqGB9QRoyP1FgiHlz xRD47Py5CWzerYHkLRBRBtj+O0beka+Asw1hNEL5MCM43Suiu9L4av7RS6QcLRu9 bbavCCYeCJVJ3pBFVESCLmrjxWC57HaGOYOo+XK43dlrNZVac1mHdM1v9gmMW8Gg t6RWSNe84GJX8Kq3ZBPkDT3UPtsyTxegLIDQ5T971U8kRHAzrDJO5dolxBzWSDX4 ZUwnQ2c9YBx7F9SfL4BEcg7JNSDqWA== =XzgS -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 13 20:35:35 2020 Return-Path: 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 1C0173A0C87 for ; Thu, 13 Aug 2020 20:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 PtGJ-_aIE9f9 for ; Thu, 13 Aug 2020 20:35:32 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6872B3A0C84 for ; Thu, 13 Aug 2020 20:35:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id F363A389B0; Thu, 13 Aug 2020 23:14:42 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4fjMWbgVn_VF; Thu, 13 Aug 2020 23:14:42 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1EED1389B1; Thu, 13 Aug 2020 23:14:42 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D956E2B3; Thu, 13 Aug 2020 23:35:28 -0400 (EDT) From: Michael Richardson To: "Wiethuechter\, Adam" cc: tm-rid@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Drip] Timestamps for DRIP ecosystem X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 03:35:34 -0000 --=-=-= Content-Type: text/plain Wiethuechter, Adam wrote: > At yesterday's meeting I very very quickly went over a slide with a > question I wanted to ask of the WG with regards to timestamps. > On slide 16 of the Authentication Formats presentation I bring up the issue > of multiple different timestamps in the UAS ecosystem as a whole. At this > point in time there are 3 different formats in use that I am aware of. > ASTM Authentication Timestamp; this is a timestamp that uses a UNIX > timestamp offset from 01/01/2019 00:00:00. Its defined in ASTM F3411-19 I assume you mean 2019-01-01 (ISO8601), that other format you show is ambiguous for me :-) > with encoding and decoding defined back and forth between standard UNIX. I > currently use this format for the Trust Timestamp field in the DRIP > Authentication Wrapper Framing. So basically Unix signed 32-bit epoch with the Y2038BUG deferred until 2087 (if signed)? or 2155 (if unsigned). I think that's probably okay. > Standard UNIX; a 4 byte timestamp that probably everyone is familiar with. > For DRIP this is used in our Certificates defined here [1] for all > timestamps. We sadly can't go beyond 4 bytes with this in our certificates. > X.509/ASN.1; primarily used in the greater UTM ecosystem. This is due to > X.509 certificates being used extensively in this area between various > parties. X.509 started with YYMMDD, quickly redefined YY to be >2000 if YY < 50, and then replaced that with a four digit timestamp in ASCII. Generally, you can't do math on it directly without converting to something useable, so I would just ignore that kind of timestamp. > So the question for the WG is; what should DRIP be using w.r.t timestamps? > All the formats can be "easily" encoded and decoded back to a standard UNIX > timestamp so perhaps this is null question I am raising. My naive opinion > on the situation is that we should harmonize the the best option, but which > one? The ASTM time stamp is sufficiently odd that it will surprise, but if everything needs to know it anyway, use that, I guess. Otherwise, use RFC7049 Tag Number 1, which is Unix time in unsigned, and use 64 bits all the time :-) Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl82BoAACgkQgItw+93Q 3WXJ8AgAvo0BZYn4DwPsDQN4GaLKGUy36mOu44fxv1f1VGXRgeNKM/zy2VOl+Ikp dxaF/CSISp8WtZmc55+Qj3KZAvfBzzcYIl5J3u0cmOK2DLhsSTYoDp+4zPoYCSFG iopG+x1lzH1oD6GWyzAZ53tfwsLOjcrLC1nEBiaHSv+lsqxgahRLlFNDqp3kBN1W Y3O+rTkd7523WnUMprHoDS9/s3jpz9h+8Mhc4IPRCLXvkYzxiMXrpimd0duFp1EB BBj4wvMMDUnn5FONYs7R4zKHBmqj+jm9cUog0WnRqDd8Ur2UHL2HHUzb0DQWBLgk U8f+XK3sgjCOIeYLGeWMMwSKUkehyw== =0o02 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 13 20:57:03 2020 Return-Path: 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 BF9503A0C99 for ; Thu, 13 Aug 2020 20:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 LY_1BG9pgr6D for ; Thu, 13 Aug 2020 20:56:59 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA5253A0C98 for ; Thu, 13 Aug 2020 20:56:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id EFAA1389B1 for ; Thu, 13 Aug 2020 23:36:10 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id t4OmU6V9dOJe for ; Thu, 13 Aug 2020 23:36:10 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id F2FFC389B0 for ; Thu, 13 Aug 2020 23:36:09 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B9DE22B3 for ; Thu, 13 Aug 2020 23:56:56 -0400 (EDT) From: Michael Richardson To: tm-rid@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Drip] UA and GSC IDevID requirements X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 03:57:02 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable okay, many of you will have guessed I watched the IETF108 meeting recording and commented on a number of things. The private-key exfiltration discussion was interesting, trumped, I think by Stu's comment that the bigger (weaponised) UAs probably can carry the toy UA inside it. I was thinking just now, it probably could even have the toy UA operating normally, with the bigger UA having some tether sensor so that as the toy UA moves, the bigger one moves in the same direction without actually being carried. That would mean that the entire toy UA+GSC could be completely stock. No amount of PUFs will help that. PUFs, btw, are: https://en.wikipedia.org/wiki/Physical_unclonable_function and while there are quite a number of proponents of PUFs and they are very attractive in many ways (being almost free being one of them), there are ma= ny doubts about them. Rather than saying yes/no, I suggest that they are just one part of a multivariable evaluation of the security of the root of trust= involved. (In attestation speak: "root of trust" <=3D more or less private key. "trust anchor" <=3D public key ) As was mentioned in the IETF108 session, pretty much every single M-class (= or A-class!) CPU you might find in an UA is capable of the crypto, and likely = is available with some secure-enclave way to store a private key in a almost impossible to extrafiltrate way. We can do attestations and the like, and IETF WGs like RATS are standardizing this. Carrying those attestatons from the UA over BT would be hard, but carrying them through the control channel to the GSC and out to the network would be easy. In any case, what we want are not attestations from the UAS itself, but attestations from other observers. This is a whole problem in itself. I am trying to start work on: A Toxonomy of operational security of manufacturer installed keys and anchors currently known as: draft-richardson-secdispatch-idevid-considerations-02 but getting a new name soon. I believe that some entity, probably an association of Hierarchical HIT Dom= ain Authorities will need to write a document like draft-richardson-anima-masa-consideratio= ns to provide some guidance on how the manufacturers should manage the PKI for the IDevID certificates that go into the UAS. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl82C4gACgkQgItw+93Q 3WXD4wf/aqc2VPIC7xXvshhSUAwRooiY3I/fHBl1fksBRi2vYIIlNMJFLgZfYd/d 6xcjBQSgUGGCcaiAz0DPE9br7vbFi5HpGIY5ad8bs4jL8Wri+8hXEfsI4Pi0xAK+ Qf2H1mgxega3q2Vj337c693nUjztVU1TWsXOLsYYWUG7AMuXCRZgRW8RWX4JnmVP rr9la511IRR4VyDvDpsbEymmAX5va/NQX31ktaaEDJPFovfH8qOtZ81Myyul15mu I3i7i4oOf+ZZNEumwJec7RaT1gZ2Lv+dsfuayV8+NwQkPPq/ySa9ZGiNvzQXYOLt +A7AHXcqIchiWSfjECezWn6ylbMrDA== =4p5C -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 13 23:31:30 2020 Return-Path: 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 11B033A0D76 for ; Thu, 13 Aug 2020 23:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 q8nRi-hca-kM for ; Thu, 13 Aug 2020 23:31:25 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 307E43A0D75 for ; Thu, 13 Aug 2020 23:31:24 -0700 (PDT) Received: from [192.168.217.102] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BSYVf6MVVzygj; Fri, 14 Aug 2020 08:31:22 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <8563.1597376128@localhost> Date: Fri, 14 Aug 2020 08:31:22 +0200 Cc: "Wiethuechter, Adam" , tm-rid@ietf.org X-Mao-Original-Outgoing-Id: 619079482.350172-68b4169b032bea909be9df99de8b9149 Content-Transfer-Encoding: quoted-printable Message-Id: <010D56BD-AB34-4943-B0F7-AD90644B9138@tzi.org> References: <8563.1597376128@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Drip] Timestamps for DRIP ecosystem X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 06:31:28 -0000 > On 2020-08-14, at 05:35, Michael Richardson = wrote: >=20 > Signed PGP part >=20 > Wiethuechter, Adam wrote: >> At yesterday's meeting I very very quickly went over a slide with a >> question I wanted to ask of the WG with regards to timestamps. >=20 >> On slide 16 of the Authentication Formats presentation I bring up the = issue >> of multiple different timestamps in the UAS ecosystem as a whole. At = this >> point in time there are 3 different formats in use that I am aware = of. >=20 >> ASTM Authentication Timestamp; this is a timestamp that uses a UNIX >> timestamp offset from 01/01/2019 00:00:00. Its defined in ASTM = F3411-19 >=20 > I assume you mean 2019-01-01 (ISO8601), that other format you show is > ambiguous for me :-) This. >> with encoding and decoding defined back and forth between standard = UNIX. I >> currently use this format for the Trust Timestamp field in the DRIP >> Authentication Wrapper Framing. >=20 > So basically Unix signed 32-bit epoch with the Y2038BUG deferred until = 2087 > (if signed)? or 2155 (if unsigned). I think that's probably okay. Unsigned. Easily processable with a POSIX-based library by adding = 1546300800 (with varying expiration dates based on the number system = that library is based on). The disadvantage is that you cannot talk about anything that happened = before 2019-01-01. If that is OK, go for 2019-01-01; otherwise go for = 1970-01-01 (still unsigned). >> Standard UNIX; a 4 byte timestamp that probably everyone is familiar = with. >> For DRIP this is used in our Certificates defined here [1] for all >> timestamps. We sadly can't go beyond 4 bytes with this in our = certificates. =E2=80=9CStandard UNIX=E2=80=9D is signed; that doesn=E2=80=99t make = sense. >> X.509/ASN.1; primarily used in the greater UTM ecosystem. This is due = to >> X.509 certificates being used extensively in this area between = various >> parties. >=20 > X.509 started with YYMMDD, quickly redefined YY to be >2000 if YY < = 50, and > then replaced that with a four digit timestamp in ASCII. Generally, = you > can't do math on it directly without converting to something useable, = so I > would just ignore that kind of timestamp. The POSIX timescale (counting seconds since 1970-01-01 except for leap = seconds) is the right one here; there is no point in turning this into = some varying-base, internally decimal number processing mess. >> So the question for the WG is; what should DRIP be using w.r.t = timestamps? >> All the formats can be "easily" encoded and decoded back to a = standard UNIX >> timestamp so perhaps this is null question I am raising. My naive = opinion >> on the situation is that we should harmonize the the best option, but = which >> one? >=20 > The ASTM time stamp is sufficiently odd that it will surprise, but if > everything needs to know it anyway, use that, I guess. >=20 > Otherwise, use RFC7049 Tag Number 1, which is Unix time in unsigned, > and use 64 bits all the time :-) (Actually, RFC 7049 Tag 1 does allow negative numbers. Which is not = needed here. And, being CBOR, it allows you to stay with 32 bits until = 2106 because it has a sign bit separate from the 32 bits. Which may = come in handy.) But if you need to make a special, constant size cookie here for DRIP, = adding/subtracting 1546300800 (49 years, including 12 leap years) to the = standard time value/from the DRIP time value is very small overhead for = an implementation, and being able to use these until 2155 is a = reasonably comfortable margin. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Aug 14 05:21:08 2020 Return-Path: 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 0A0003A106D for ; Fri, 14 Aug 2020 05:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, 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 SW8one5lq3gA for ; Fri, 14 Aug 2020 05:21:05 -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 0E1A63A106C for ; Fri, 14 Aug 2020 05:21:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 54CBE624D4; Fri, 14 Aug 2020 08:21:03 -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 BIMsy6yNql9U; Fri, 14 Aug 2020 08:20:58 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (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 6DFF7624C7; Fri, 14 Aug 2020 08:20:56 -0400 (EDT) To: Michael Richardson , tm-rid@ietf.org References: <13083.1597377416@localhost> From: Robert Moskowitz Message-ID: Date: Fri, 14 Aug 2020 08:20:47 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <13083.1597377416@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Drip] UA and GSC IDevID requirements X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 12:21:07 -0000 On 8/13/20 11:56 PM, Michael Richardson wrote: > okay, many of you will have guessed I watched the IETF108 meeting recording > and commented on a number of things. > > The private-key exfiltration discussion was interesting, trumped, I think by > Stu's comment that the bigger (weaponised) UAs probably can carry the toy UA > inside it. I was thinking just now, it probably could even have the toy UA > operating normally, with the bigger UA having some tether sensor so that > as the toy UA moves, the bigger one moves in the same direction without > actually being carried. > That would mean that the entire toy UA+GSC could be completely stock. > > No amount of PUFs will help that. PUFs, btw, are: > https://en.wikipedia.org/wiki/Physical_unclonable_function > and while there are quite a number of proponents of PUFs and they are very > attractive in many ways (being almost free being one of them), there are many > doubts about them. Rather than saying yes/no, I suggest that they are just > one part of a multivariable evaluation of the security of the root of trust involved. > (In attestation speak: "root of trust" <= more or less private key. > "trust anchor" <= public key ) > > As was mentioned in the IETF108 session, pretty much every single M-class (or > A-class!) CPU you might find in an UA is capable of the crypto, and likely is > available with some secure-enclave way to store a private key in a almost > impossible to extrafiltrate way. We can do attestations and the like, and > IETF WGs like RATS are standardizing this. Carrying those attestatons > from the UA over BT would be hard, but carrying them through the control > channel to the GSC and out to the network would be easy. > > In any case, what we want are not attestations from the UAS itself, but > attestations from other observers. This is a whole problem in itself. Different classes of Observers and many already have their Identities (US police in a PKI that uses TRUSTMARK; this will have bearing on RDAP). But look at both: draft-moskowitz-drip-crowd-sourced-rid draft-moskowitz-drip-secure-nrid-c2 For other Identity pieces (and potential other uses of HHITs). > I am trying to start work on: > A Toxonomy of operational security of manufacturer > installed keys and anchors > > currently known as: > draft-richardson-secdispatch-idevid-considerations-02 > but getting a new name soon. > > I believe that some entity, probably an association of Hierarchical HIT Domain Authorities > will need to write a document like draft-richardson-anima-masa-considerations > to provide some guidance on how the manufacturers should manage the PKI for > the IDevID certificates that go into the UAS. ICAO IATF TRON and DIWG are probably moving in this direction.  For manned aircraft, the serial number is a plate on the airframe and the owner of the airframe registers this with appropriate CAA (and we WON'T get into the rat hole about leasing companies vs airlines and regional policies that were in the last TRON call and emails!) The manufacturer has no direct involvement.  I have pointed out this won't scale well with UAS/UAM/... and I gave 3 approaches, one of which is IDevID (I wonder why, as I was there at 802.1 in the first discussions). Oh, this plate is suppose to be non-removable.  Except when you make major airframe/wing changes and you have to change it.  One call participate recalls when he had to do this...  :) I think it will come down to a debate in DIWG/TRON is the Identity that of the airframe or some computing guts (and what happens when said computing guts are gutted {e.g. DJL airframes with different brains used by US Gov}).  Fun. From nobody Sun Aug 16 16:17:39 2020 Return-Path: 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 F337F3A1245 for ; Sun, 16 Aug 2020 16:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.021 X-Spam-Level: X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.212, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 v_z9QupA14eU for ; Sun, 16 Aug 2020 16:17:36 -0700 (PDT) Received: from relay.sandelman.ca (minerva.sandelman.ca [IPv6:2a01:7e00::3d:b000]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B64313A1244 for ; Sun, 16 Aug 2020 16:17:35 -0700 (PDT) Received: from dooku.sandelman.ca (CPE788a207f397a-CMbc4dfb96bb50.cpe.net.cable.rogers.com [174.116.121.43]) by relay.sandelman.ca (Postfix) with ESMTPS id 8B7831F455; Sun, 16 Aug 2020 23:17:33 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id A319A1A0291; Sun, 16 Aug 2020 19:17:31 -0400 (EDT) To: Robert Moskowitz cc: tm-rid@ietf.org In-Reply-To: References: <13083.1597377416@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m X-Attribution: mcr MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Date: Sun, 16 Aug 2020 19:17:31 -0400 Message-ID: <4024.1597619851@dooku> Archived-At: Subject: [Drip] some comments on drip-crowd-sourced-rid X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2020 23:17:38 -0000 --=-=-= Content-Type: text/plain Robert Moskowitz wrote: >> In any case, what we want are not attestations from the UAS itself, but >> attestations from other observers. This is a whole problem in itself. > Different classes of Observers and many already have their Identities (US > police in a PKI that uses TRUSTMARK; this will have bearing on RDAP). > But look at both: > draft-moskowitz-drip-crowd-sourced-rid > draft-moskowitz-drip-secure-nrid-c2 I started reading them yesterday, ran into too many TLAs I didn't know, and realized I should finish reading the other documents. I have now read crowd-sourced-rid. I would sure like to have an example of an SDSP, particularly in the introduction of this document. Who would operate such a thing? What's their business model? I think that's pretty important, because it would determine what kind of things they would want to do, and what things they would find too expensive. The mention of the Finder's public key and ECIES in the introduction suggests that the forwarding of the B-RID messages might be done in an unconnected fashion (UDP, no three-way TCP handshake, or TLS setup). Finders clearly need to disclose their location to the SDSP. There is therefore a tension between the SDSP knowing that the Finders are real, and the SDSP knowing way too much about the location of the Finders. You may find https://datatracker.ietf.org/doc/rfc7416/ to have a set of terminology which might be useful. RPL is subject to a variety of attacks that can be made without breaking the crypto, that basically involve various kinds of repeaters, the point being to change where (physically) a device appears to be. } When 3 or more Finders are reporting to an SDSP on a specific UA, the } SDSP is in a unique position to perform multilateration on these } messages and compute the Finder's view of the UA location to compare } with the UA Location/Vector messages. This check against the UA's } location claims is both a validation on the UA's reliability as well } as the trustworthiness of the Finders. Other than providing data to } allow for multilateration, this SDSP feature is out of scope of this } document. Sorry, which "SDSP feature" are you speaking off? NETSP/NETDP term is inconsistent with reqs document. SDSP is just a terrible term. } provides only Network RID. The FAA has dropped their previous } position on allowing for only Broadcast RID. We can guess as to } their reasons; they are not spelled out in the NPRM. It may be that } just B-RID does not meet the FAA's statutory UA tracking } responsibility. -> We can only guess? Are you guessing here? You need to connect "Broadcast RID" with "B-RID" more often, or use only one. Wish you would use "C&C" rather than "C2" I don't think that a small device mounted on a UA that provided B-RID, over BT4/BT5, is an "IoT"... It's just a device. No Internet or IP involved. Section 4: having the Finder register to the SDSP seems a bit unreasonable. I think that for Finders that are other GCS, that they should register to their manufacturer. I think you'll need federation. I think that four methods to authenticate is probably a bad idea. TLS or HIPv2 in my opinion. Using raw ECIES seems too much. Also maybe, OSCORE/CoAP over HIPv2? }4.2. Managing Finders } } Finder density will vary over time and space. For example, sidewalks } outside an urban train station can be packed with pedestrians at rush } hour, either coming or going to their commute trains. An SDSP may } want to proactively limit the number of active Finders in such } situations. It seems like the SDSP should simply thank every Finder, and then ask them to report again after they have moved at least X meters or Y seconds. First, being told not to report indicates that there are other Finders. Being asked to report, tells the Finder how many other Finders are around. One should assume the Finders are collaborating with some UA that wishes to provide false data about it's location. At this point, it jumps into CDDL, and I found that very jarring, and I really didn't get much from it. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl85vooACgkQlUzhVv38 QpAa5Qf/f+j+AFFnUF8HzV2JapmcG91Njl3iMZ4FfTsR2UR8vL+hD23Jai/zVG+U qxVo88LgFqYiJps8BxN4qKbSUiMAYgSKGm0ZRKp7h3S0jM/zkKG7La8pyfyNXESO mpz5ulL07fQnaE4CwHepr7mGv47dQPCsdylFtg7LZZ+c8urk3VM+V6oIWP0gHKf8 671Fpk46COw1SXH2M60nj8j0t2aLjhfXCdjDGpYbO5E+lA1RjNtScLqdElEZ/H3b qpsH0xFBOFZ924x+5TwORU7aAtn+iYF05dgvAFdQj65uAEsc3hEPJPK6feCq9oV0 eMiM3caV3n4Gx8WPiJvucyOBNpDXWA== =Q2gV -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Aug 16 16:22:05 2020 Return-Path: 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 C01663A1250 for ; Sun, 16 Aug 2020 16:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 FUkhwhtWjnE8 for ; Sun, 16 Aug 2020 16:22:02 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C5743A124F for ; Sun, 16 Aug 2020 16:22:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 75663389B3; Sun, 16 Aug 2020 19:01:11 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id KLfXvJTTIPdL; Sun, 16 Aug 2020 19:01:10 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B9831389AF; Sun, 16 Aug 2020 19:01:10 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 16D2C373; Sun, 16 Aug 2020 19:22:00 -0400 (EDT) To: Robert Moskowitz cc: tm-rid@ietf.org In-Reply-To: References: <13083.1597377416@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Attribution: mcr From: Michael Richardson MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Date: Sun, 16 Aug 2020 19:22:00 -0400 Message-ID: <13496.1597620120@localhost> Archived-At: Subject: [Drip] idevid considerations for UAS X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2020 23:22:04 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable >> I believe that some entity, probably an association of Hierarchical = HIT Domain Authorities >> will need to write a document like draft-richardson-anima-masa-consi= derations >> to provide some guidance on how the manufacturers should manage the = PKI for >> the IDevID certificates that go into the UAS. > ICAO IATF TRON and DIWG are probably moving in this direction.=C2=A0 = For manned > aircraft, the serial number is a plate on the airframe and the owner = of the > airframe registers this with appropriate CAA (and we WON'T get into t= he rat > hole about leasing companies vs airlines and regional policies that w= ere in > the last TRON call and emails!) The manufacturer has no direct involv= ement.=C2=A0 > I have pointed out this won't scale well with UAS/UAM/... and I gave 3 > approaches, one of which is IDevID (I wonder why, as I was there at 8= 02.1 in > the first discussions). okay, that's fine, and with a manned aircraft, I don't see IDevID managemen= t as being particularly expensive or relevant. > I think it will come down to a debate in DIWG/TRON is the Identity th= at of > the airframe or some computing guts (and what happens when said compu= ting > guts are gutted {e.g. DJL airframes with different brains used by US = Gov}).=C2=A0 okay, but the thing is that this IDevID has to be get into the assembly lin= e of the devices being sold at Walmart. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl85v5cACgkQgItw+93Q 3WWjHggAn7AJYcejoZEQ1zaQPjgzVySwrVmiu8GnOzqg6BisHkx3cZwklY+1Avrv /Lf/vMv5hD9mnnISfs9SG555LUcTRktgRuot4HS5aa/ArpfIbmj+RjpKCTNbsZ85 voIHnJupGYq8lcgnyxup3nPsHTyhU0fFEcm1hoEHtIyA/lpuyFCM6ZeJ1QVLaAwn oyMGBexM93SmJDZ0Hn//fV5imRJViU1JLMbEfaXmVlmEzN7+2WTOcXxUZVkybaA0 QG9q5ydxEceizlYiF76bSQ6C/x9ITmUwNwUPJ9nNHhzROlS8+koXYvMV09o/F7bw +o8WzaNtaeC8/7dwrOp5FD+ucNVNFg== =TBPu -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Aug 16 16:39:22 2020 Return-Path: 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 9A4DB3A0A8F for ; Sun, 16 Aug 2020 16:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 XFXaVx_58iod for ; Sun, 16 Aug 2020 16:39:20 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8E573A0A86 for ; Sun, 16 Aug 2020 16:39:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id A0C88389C1; Sun, 16 Aug 2020 19:18:28 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id u4wY-htfMPvP; Sun, 16 Aug 2020 19:18:28 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D3F69389C0; Sun, 16 Aug 2020 19:18:27 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3424F373; Sun, 16 Aug 2020 19:39:17 -0400 (EDT) From: Michael Richardson to: Robert Moskowitz , tm-rid@ietf.org In-Reply-To: <4024.1597619851@dooku> References: <13083.1597377416@localhost> <4024.1597619851@dooku> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Drip] some comments on drip-secure-nrid-c2 X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2020 23:39:22 -0000 --=-=-= Content-Type: text/plain So, again, I don't like "C2", I'd rather C&C. I don't like "USS".. as it winds up in "USS Network Secure Provider" (along with the USS Enterprise, you see) So that's Unmapped Aircraft System Service Supplier Network Secure Provider. Does that make any sense? Not to me. I understand that maybe it comes from an FAA UTM document? What's the business model for these things? I think that sections 3 and 4 need to reworked. I think things should start with: Command and Control (C2) connection is between the UA and GCS. and then explain the various ways in which this can be accomplished, introducing the various NETSP,etc. along the way. I find the document is way to nebulous. It seems like the document should establish the required security and multihop/rendezvous and multihoming requirements. The requirements should indicate how rendezvous will be used. Those that do not require a rendezvous (STUN), i.e. that use IPv6, would be preferred for latency reasons. Establish the basis for trust (who sets it it up, how many parties are involved). Then, somewhere near the end, establish how to do with DTLS in a section, and how to do it with HIPv2 in another section. Maybe even in two documents. I didn't quite figure out what the USS is in this C2 model. I understood that the Operator files a Mission (Operation?) with the USS. Does the GCS need to get something from the UA to attest that it is authoritative for the UA? confused. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl85w6QACgkQgItw+93Q 3WUd6Qf/Q9qpsYcOyF0gJgOwwro/cvWVsXa06KFlYBkN8LcxL/vgeglHAatG/XVB f6Tfl4FuPBLqmnfXKeBfFhMghI/e8V1FkcLuTyEieNGWJZf2uzEa+uVwBdI/i45o ixDireyVdEGXGkqWZHeqXBmqBlvtL3mxLW9gYRPZUFnTtQoVgpwa9TJ0PcEV5NHM vkaZgZG2gfSaeEqiSdk2JirxtEIlyEmuwbuGyP9RLX7aToRds9TLbY3No7h+9i3z FISCby4LFWx07Oli4YDZ+NPJ/iT6BZROMd69aMoO9BPNICT7royabfS5ZEEZzV1x FodUODwf3sYgZD7I/Lha1c5mR/v5Yw== =G2RA -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Aug 16 17:15:58 2020 Return-Path: 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 13ABD3A1285 for ; Sun, 16 Aug 2020 17:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, 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 JnT6dHvQdP4I for ; Sun, 16 Aug 2020 17:15:55 -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 0A75E3A1284 for ; Sun, 16 Aug 2020 17:15:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 3DB4F6247F; Sun, 16 Aug 2020 20:15:53 -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 2HrwZYusip4z; Sun, 16 Aug 2020 20:15:46 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (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 8AA5D622C2; Sun, 16 Aug 2020 20:15:44 -0400 (EDT) To: Michael Richardson , tm-rid@ietf.org References: <13083.1597377416@localhost> <4024.1597619851@dooku> <17436.1597621157@localhost> From: Robert Moskowitz Message-ID: <66b18e96-dcb4-9504-14ae-fe98854d919a@labs.htt-consult.com> Date: Sun, 16 Aug 2020 20:15:35 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <17436.1597621157@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Drip] some comments on drip-secure-nrid-c2 X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 00:15:57 -0000 On 8/16/20 7:39 PM, Michael Richardson wrote: > So, again, I don't like "C2", I'd rather C&C. C2 is the accepted industry term.  We really can't come up with our own. > I don't like "USS".. as it winds up in "USS Network Secure Provider" > (along with the USS Enterprise, you see) Talk to the FAA and Candian and EU aviation people.  They all pretty much agree on the term.  We have to work in their TLA field. But Canada does not like UAS; they Remote Piloted Aircraft (RPA). > So that's Unmapped Aircraft System Service Supplier Network Secure Provider. > Does that make any sense? Not to me. > I understand that maybe it comes from an FAA UTM document? https://www.faa.gov/uas/research_development/traffic_management/media/UTM_ConOps_v2.pdf > What's the business model for these things? Much is still unknown.  Stu is active in the study group on this. > I think that sections 3 and 4 need to reworked. > I think things should start with: > Command and Control (C2) connection is between the UA and GCS. > > and then explain the various ways in which this can be accomplished, > introducing the various NETSP,etc. along the way. > > I find the document is way to nebulous. > It seems like the document should establish the required security and > multihop/rendezvous and multihoming requirements. > The requirements should indicate how rendezvous will be used. > Those that do not require a rendezvous (STUN), i.e. that use IPv6, would be > preferred for latency reasons. > > Establish the basis for trust (who sets it it up, how many parties are involved). > Then, somewhere near the end, establish how to do with DTLS in a section, > and how to do it with HIPv2 in another section. Maybe even in two documents. > > I didn't quite figure out what the USS is in this C2 model. > I understood that the Operator files a Mission (Operation?) with the USS. > Does the GCS need to get something from the UA to attest that it is > authoritative for the UA? > > confused. That is ok.  It needs work, but how much of point to appropriate info. From nobody Sun Aug 16 17:55:08 2020 Return-Path: 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 3E7A73A0B5F for ; Sun, 16 Aug 2020 17:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, 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 qydw07o46Kva for ; Sun, 16 Aug 2020 17:55:03 -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 A44E03A12B0 for ; Sun, 16 Aug 2020 17:55:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id CE1D46247F; Sun, 16 Aug 2020 20:55:01 -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 I8tai8TPaF8U; Sun, 16 Aug 2020 20:54:55 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (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 5A86A622C2; Sun, 16 Aug 2020 20:54:54 -0400 (EDT) From: Robert Moskowitz To: Michael Richardson , tm-rid@ietf.org References: <13083.1597377416@localhost> <4024.1597619851@dooku> <17436.1597621157@localhost> <66b18e96-dcb4-9504-14ae-fe98854d919a@labs.htt-consult.com> Message-ID: Date: Sun, 16 Aug 2020 20:54:45 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <66b18e96-dcb4-9504-14ae-fe98854d919a@labs.htt-consult.com> Content-Type: multipart/alternative; boundary="------------9CCF55A6B4A8B5C5EE5F46CA" Content-Language: en-US Archived-At: Subject: Re: [Drip] some comments on drip-secure-nrid-c2 X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 00:55:06 -0000 This is a multi-part message in MIME format. --------------9CCF55A6B4A8B5C5EE5F46CA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 8/16/20 8:15 PM, Robert Moskowitz wrote: > > > On 8/16/20 7:39 PM, Michael Richardson wrote: >> So, again, I don't like "C2", I'd rather C&C. > > C2 is the accepted industry term.  We really can't come up with our own. Oh, there is a 'C3' term, but right now I can't remember what the 3rd 'C' is... > >> I don't like "USS".. as it winds up in "USS Network Secure Provider" >> (along with the USS Enterprise, you see) > > Talk to the FAA and Candian and EU aviation people.  They all pretty > much agree on the term.  We have to work in their TLA field. > > But Canada does not like UAS; they Remote Piloted Aircraft (RPA). > >> So that's Unmapped Aircraft System Service Supplier Network Secure >> Provider. >> Does that make any sense?  Not to me. >> I understand that maybe it comes from an FAA UTM document? > > https://www.faa.gov/uas/research_development/traffic_management/media/UTM_ConOps_v2.pdf > > >> What's the business model for these things? > > Much is still unknown.  Stu is active in the study group on this. > >> I think that sections 3 and 4 need to reworked. >> I think things should start with: >>     Command and Control (C2) connection is between the UA and GCS. >> >> and then explain the various ways in which this can be accomplished, >> introducing the various NETSP,etc. along the way. >> >> I find the document is way to nebulous. >> It seems like the document should establish the required security and >> multihop/rendezvous and multihoming requirements. >> The requirements should indicate how rendezvous will be used. >> Those that do not require a rendezvous (STUN), i.e. that use IPv6, >> would be >> preferred for latency reasons. >> >> Establish the basis for trust (who sets it it up, how many parties >> are involved). >> Then, somewhere near the end, establish how to do with DTLS in a >> section, >> and how to do it with HIPv2 in another section.  Maybe even in two >> documents. >> >> I didn't quite figure out what the USS is in this C2 model. >> I understood that the Operator files a Mission (Operation?) with the >> USS. >> Does the GCS need to get something from the UA to attest that it is >> authoritative for the UA? >> >> confused. > > That is ok.  It needs work, but how much of point to appropriate info. > > -- 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 --------------9CCF55A6B4A8B5C5EE5F46CA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 8/16/20 8:15 PM, Robert Moskowitz wrote:


On 8/16/20 7:39 PM, Michael Richardson wrote:
So, again, I don't like "C2", I'd rather C&C.

C2 is the accepted industry term.  We really can't come up with our own.

Oh, there is a 'C3' term, but right now I can't remember what the 3rd 'C' is...


I don't like "USS".. as it winds up in "USS Network Secure Provider"
(along with the USS Enterprise, you see)

Talk to the FAA and Candian and EU aviation people.  They all pretty much agree on the term.  We have to work in their TLA field.

But Canada does not like UAS; they Remote Piloted Aircraft (RPA).

So that's Unmapped Aircraft System Service Supplier Network Secure Provider.
Does that make any sense?  Not to me.
I understand that maybe it comes from an FAA UTM document?

https://www.faa.gov/uas/research_development/traffic_management/media/UTM_ConOps_v2.pdf

What's the business model for these things?

Much is still unknown.  Stu is active in the study group on this.

I think that sections 3 and 4 need to reworked.
I think things should start with:
    Command and Control (C2) connection is between the UA and GCS.

and then explain the various ways in which this can be accomplished,
introducing the various NETSP,etc. along the way.

I find the document is way to nebulous.
It seems like the document should establish the required security and
multihop/rendezvous and multihoming requirements.
The requirements should indicate how rendezvous will be used.
Those that do not require a rendezvous (STUN), i.e. that use IPv6, would be
preferred for latency reasons.

Establish the basis for trust (who sets it it up, how many parties are involved).
Then, somewhere near the end, establish how to do with DTLS in a section,
and how to do it with HIPv2 in another section.  Maybe even in two documents.

I didn't quite figure out what the USS is in this C2 model.
I understood that the Operator files a Mission (Operation?) with the USS.
Does the GCS need to get something from the UA to attest that it is
authoritative for the UA?

confused.

That is ok.  It needs work, but how much of point to appropriate info.



--
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
--------------9CCF55A6B4A8B5C5EE5F46CA-- From nobody Sun Aug 16 18:48:55 2020 Return-Path: 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 29F5B3A0BA4 for ; Sun, 16 Aug 2020 18:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, 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 dVfnNkWdQWeK for ; Sun, 16 Aug 2020 18:48:52 -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 DFD933A0B68 for ; Sun, 16 Aug 2020 18:48:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 10D876247F; Sun, 16 Aug 2020 21:48:35 -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 svYMFgH30AyR; Sun, 16 Aug 2020 21:48:26 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (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 DA86B622C2; Sun, 16 Aug 2020 21:48:23 -0400 (EDT) From: Robert Moskowitz To: Michael Richardson , tm-rid@ietf.org References: <13083.1597377416@localhost> <4024.1597619851@dooku> <17436.1597621157@localhost> <66b18e96-dcb4-9504-14ae-fe98854d919a@labs.htt-consult.com> Message-ID: Date: Sun, 16 Aug 2020 21:48:14 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <66b18e96-dcb4-9504-14ae-fe98854d919a@labs.htt-consult.com> Content-Type: multipart/alternative; boundary="------------7865EA5E82B6A76B77B9670D" Content-Language: en-US Archived-At: Subject: Re: [Drip] some comments on drip-secure-nrid-c2 X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 01:48:54 -0000 This is a multi-part message in MIME format. --------------7865EA5E82B6A76B77B9670D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 8/16/20 8:15 PM, Robert Moskowitz wrote: > > > On 8/16/20 7:39 PM, Michael Richardson wrote: >> So, again, I don't like "C2", I'd rather C&C. > > C2 is the accepted industry term.  We really can't come up with our own. > >> I don't like "USS".. as it winds up in "USS Network Secure Provider" >> (along with the USS Enterprise, you see) > > Talk to the FAA and Candian and EU aviation people.  They all pretty > much agree on the term.  We have to work in their TLA field. > > But Canada does not like UAS; they Remote Piloted Aircraft (RPA). > >> So that's Unmapped Aircraft System Service Supplier Network Secure >> Provider. >> Does that make any sense?  Not to me. >> I understand that maybe it comes from an FAA UTM document? > > https://www.faa.gov/uas/research_development/traffic_management/media/UTM_ConOps_v2.pdf > Another important document to get aviation Unmanned Aircraft terms and TLAs: https://www.icao.int/Meetings/UAS/Documents/Circular%20328_en.pdf You Canadians can call this work RPAS, rather than UAS...  :) > >> What's the business model for these things? > > Much is still unknown.  Stu is active in the study group on this. > >> I think that sections 3 and 4 need to reworked. >> I think things should start with: >>     Command and Control (C2) connection is between the UA and GCS. >> >> and then explain the various ways in which this can be accomplished, >> introducing the various NETSP,etc. along the way. >> >> I find the document is way to nebulous. >> It seems like the document should establish the required security and >> multihop/rendezvous and multihoming requirements. >> The requirements should indicate how rendezvous will be used. >> Those that do not require a rendezvous (STUN), i.e. that use IPv6, >> would be >> preferred for latency reasons. >> >> Establish the basis for trust (who sets it it up, how many parties >> are involved). >> Then, somewhere near the end, establish how to do with DTLS in a >> section, >> and how to do it with HIPv2 in another section.  Maybe even in two >> documents. >> >> I didn't quite figure out what the USS is in this C2 model. >> I understood that the Operator files a Mission (Operation?) with the >> USS. >> Does the GCS need to get something from the UA to attest that it is >> authoritative for the UA? >> >> confused. > > That is ok.  It needs work, but how much of point to appropriate info. > > -- 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 --------------7865EA5E82B6A76B77B9670D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 8/16/20 8:15 PM, Robert Moskowitz wrote:


On 8/16/20 7:39 PM, Michael Richardson wrote:
So, again, I don't like "C2", I'd rather C&C.

C2 is the accepted industry term.  We really can't come up with our own.

I don't like "USS".. as it winds up in "USS Network Secure Provider"
(along with the USS Enterprise, you see)

Talk to the FAA and Candian and EU aviation people.  They all pretty much agree on the term.  We have to work in their TLA field.

But Canada does not like UAS; they Remote Piloted Aircraft (RPA).

So that's Unmapped Aircraft System Service Supplier Network Secure Provider.
Does that make any sense?  Not to me.
I understand that maybe it comes from an FAA UTM document?

https://www.faa.gov/uas/research_development/traffic_management/media/UTM_ConOps_v2.pdf


Another important document to get aviation Unmanned Aircraft terms and TLAs:

https://www.icao.int/Meetings/UAS/Documents/Circular%20328_en.pdf

You Canadians can call this work RPAS, rather than UAS...  :)


What's the business model for these things?

Much is still unknown.  Stu is active in the study group on this.

I think that sections 3 and 4 need to reworked.
I think things should start with:
    Command and Control (C2) connection is between the UA and GCS.

and then explain the various ways in which this can be accomplished,
introducing the various NETSP,etc. along the way.

I find the document is way to nebulous.
It seems like the document should establish the required security and
multihop/rendezvous and multihoming requirements.
The requirements should indicate how rendezvous will be used.
Those that do not require a rendezvous (STUN), i.e. that use IPv6, would be
preferred for latency reasons.

Establish the basis for trust (who sets it it up, how many parties are involved).
Then, somewhere near the end, establish how to do with DTLS in a section,
and how to do it with HIPv2 in another section.  Maybe even in two documents.

I didn't quite figure out what the USS is in this C2 model.
I understood that the Operator files a Mission (Operation?) with the USS.
Does the GCS need to get something from the UA to attest that it is
authoritative for the UA?

confused.

That is ok.  It needs work, but how much of point to appropriate info.



--
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
--------------7865EA5E82B6A76B77B9670D-- From nobody Mon Aug 17 13:18:07 2020 Return-Path: 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 61DF43A1062 for ; Mon, 17 Aug 2020 13:18:05 -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, 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 da4SutKrFLh1 for ; Mon, 17 Aug 2020 13:18:03 -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 84F813A105E for ; Mon, 17 Aug 2020 13:18:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 32E0F6247F for ; Mon, 17 Aug 2020 16:18:02 -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 sdx2mmoCWiXC for ; Mon, 17 Aug 2020 16:17:52 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (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 A24A4623CC for ; Mon, 17 Aug 2020 16:17:50 -0400 (EDT) References: <159769484419.361.16829006324553040183@ietfa.amsl.com> To: "tm-rid@ietf.org" From: Robert Moskowitz X-Forwarded-Message-Id: <159769484419.361.16829006324553040183@ietfa.amsl.com> Message-ID: <9d759774-a4ef-2a31-f300-37ab8378be8d@labs.htt-consult.com> Date: Mon, 17 Aug 2020 16:17:41 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <159769484419.361.16829006324553040183@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------84CAE4ED76C71F69A0AA6C58" Content-Language: en-US Archived-At: Subject: [Drip] Fwd: New Version Notification for draft-moskowitz-drip-uas-rid-06.txt X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 20:18:05 -0000 This is a multi-part message in MIME format. --------------84CAE4ED76C71F69A0AA6C58 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Some clean ups in the merger of the other drafts into drip-uas-rid. Added text to hopefully address MOST of MCR's points.  I did not alter sec 5; that will wait until I get some EPP/RDAP content. Also added text that RID is not the only use for HHITs (I have been in discussions about other potential uses).  Two ways to manage this is in considered allocation of the RAA space or separate Prefixes for different usage domains. Anyway, this is the draft version for the Interim meeting and for the call to adopt. thanks Bob -------- Forwarded Message -------- Subject: New Version Notification for draft-moskowitz-drip-uas-rid-06.txt Date: Mon, 17 Aug 2020 13:07:24 -0700 From: internet-drafts@ietf.org To: Andrei Gurtov , Adam Wiethuechter , Stuart Card , Robert Moskowitz , Stuart W. Card A new version of I-D, draft-moskowitz-drip-uas-rid-06.txt has been successfully submitted by Robert Moskowitz and posted to the IETF repository. Name: draft-moskowitz-drip-uas-rid Revision: 06 Title: UAS Remote ID Document date: 2020-08-17 Group: Individual Submission Pages: 19 URL: https://www.ietf.org/internet-drafts/draft-moskowitz-drip-uas-rid-06.txt Status: https://datatracker.ietf.org/doc/draft-moskowitz-drip-uas-rid/ Htmlized: https://tools.ietf.org/html/draft-moskowitz-drip-uas-rid-06 Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-drip-uas-rid Diff: https://www.ietf.org/rfcdiff?url2=draft-moskowitz-drip-uas-rid-06 Abstract: This document describes the use of Hierarchical Host Identity Tags (HHITs) as a self-asserting and thereby trustable Identifier for use as the UAS Remote ID. HHITs include explicit hierarchy to provide Registrar discovery for 3rd-party ID attestation. 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. The IETF Secretariat --------------84CAE4ED76C71F69A0AA6C58 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Some clean ups in the merger of the other drafts into drip-uas-rid.

Added text to hopefully address MOST of MCR's points.  I did not alter sec 5; that will wait until I get some EPP/RDAP content.

Also added text that RID is not the only use for HHITs (I have been in discussions about other potential uses).  Two ways to manage this is in considered allocation of the RAA space or separate Prefixes for different usage domains.

Anyway, this is the draft version for the Interim meeting and for the call to adopt.

thanks

Bob


-------- Forwarded Message --------
Subject: New Version Notification for draft-moskowitz-drip-uas-rid-06.txt
Date: Mon, 17 Aug 2020 13:07:24 -0700
From: internet-drafts@ietf.org
To: Andrei Gurtov <gurtov@acm.org>, Adam Wiethuechter <adam.wiethuechter@axenterprize.com>, Stuart Card <stu.card@axenterprize.com>, Robert Moskowitz <rgm@labs.htt-consult.com>, Stuart W. Card <stu.card@axenterprize.com>



A new version of I-D, draft-moskowitz-drip-uas-rid-06.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-drip-uas-rid
Revision: 06
Title: UAS Remote ID
Document date: 2020-08-17
Group: Individual Submission
Pages: 19
URL: https://www.ietf.org/internet-drafts/draft-moskowitz-drip-uas-rid-06.txt
Status: https://datatracker.ietf.org/doc/draft-moskowitz-drip-uas-rid/
Htmlized: https://tools.ietf.org/html/draft-moskowitz-drip-uas-rid-06
Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-drip-uas-rid
Diff: https://www.ietf.org/rfcdiff?url2=draft-moskowitz-drip-uas-rid-06

Abstract:
This document describes the use of Hierarchical Host Identity Tags
(HHITs) as a self-asserting and thereby trustable Identifier for use
as the UAS Remote ID. HHITs include explicit hierarchy to provide
Registrar discovery for 3rd-party ID attestation.



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.

The IETF Secretariat


--------------84CAE4ED76C71F69A0AA6C58-- From nobody Tue Aug 18 08:23:59 2020 Return-Path: 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 859083A0CEC for ; Tue, 18 Aug 2020 08:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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=axenterprize.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 q5P1CIUFlzro for ; Tue, 18 Aug 2020 08:23:54 -0700 (PDT) Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA6CE3A0CE7 for ; Tue, 18 Aug 2020 08:23:54 -0700 (PDT) Received: by mail-qv1-xf2c.google.com with SMTP id cs12so9720726qvb.2 for ; Tue, 18 Aug 2020 08:23:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axenterprize.com; s=google; h=subject:references:to:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to; bh=yFGRTrJM+r7DChE2RhWkOHsUbRCKw2zmI9NSIervlBw=; b=AN3dtUCcExc63qqDEmZTVNyOrv/VU1fg7lZ2NBOZqizwcRmtc4ZCTJNzmjZD0TwJdK Th6jY3r8RUZPE2wbL97zMPJEg/fjtsEkg/4mx2Hm6Tp6Dp9SBIdcOQHfvdRZpv1dpvU5 ONVvT+gOseQiU6eEKrdzECP33cJchWI1SCU+k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:autocrypt:message-id :date:user-agent:mime-version:in-reply-to; bh=yFGRTrJM+r7DChE2RhWkOHsUbRCKw2zmI9NSIervlBw=; b=J5FbM6iyGX7boUldEzJZ3QzFLlrpZSbO4JfZT0mfRe8Izj62nbQ0jc2M07mRi5MpAN eBn9cUFr6kxQvofVKeMjso+fSVojmh5lAGSK0SZ7uuBVd+B/h1Cl9YiklOC5WUxcdWEq QE4PfADoShar6uIl8JOCqPpncvKbl5lh3ioc3kuxxUD5XbnOmXghNgFs3B0Xi9YkY/Ei U8xyrZAbNXl8sEXd3kYSO0aqdH0xavWmXumSSQDd/2SsrEUZ8pMMX7ulvbkfBEtxe3GM mlb1sl/8kw45brUjqLKV/JpyNpwwaavTwrwl1aRLdrzAoRXyUfVryYZXSafJCAjn4dCs ockA== X-Gm-Message-State: AOAM533+vDr9cJE+ZmbSjr8KUZylCYJDfrd/B6gmLufXGxr5qChP1Cv2 2safP5xmkgFHfH4hN6uV6EM2cINknxJMrPL9 X-Google-Smtp-Source: ABdhPJwAzPf+O0dXUpk29/0zqxEWstmf/ra84DrIMeW68Ic1usuLtB0SK0XSMN6No2N7kkP2vQKlag== X-Received: by 2002:a05:6214:554:: with SMTP id ci20mr19719574qvb.108.1597764233140; Tue, 18 Aug 2020 08:23:53 -0700 (PDT) Received: from [192.168.1.107] (ip-72-10-210-250.nwptny.ntcnet.net. [72.10.210.250]) by smtp.gmail.com with ESMTPSA id e4sm24185580qts.57.2020.08.18.08.23.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Aug 2020 08:23:52 -0700 (PDT) References: <0.0.46.863.1D6749DCC4B1CA0.0@drone113.ral.icpbounce.com> To: "tm-rid@ietf.org" From: "Stuart W. Card" Autocrypt: addr=stu.card@axenterprize.com; prefer-encrypt=mutual; keydata= mQGiBDpARp4RBADNQipCkPP9uNjzow8Fyltan7Fsc1obeYCZsHmKB3J9GkjAOISXeg5ce7PG NxugbgU1pAkhU6bARdTYFllKGz7WP8cwRVzQvwNbDLowPImeaRFsSOSU3T1RSzAC4vIRv7Q2 amQkSZLSh105f4whqkR1QqFUPqamhxHy2itg+zUSowCg/13xoiFRCbhzEq3MaiKrHd/wyM0D /3fHb4CyuIe5c5iz+Jh4h9MSLvKnWeGzRaokBSrJj3sJf2foSWFrx8lmib0Sgzrpb1/s5c+f eE6N444bAEnGEnCwmHaFdCebTif/8t4ZPVZqGEHIye4fpegcsQwkzcIyKp7mM1KjpcfsBOg+ AKhiuBUKCkYdzg1DQiKfyiJRgXcvA/4tb35LGbLOLgRWOO78hy293tAeE+bQKa9GYKaOCk8L Gadddjh4oTrW+KUnyas/jbl6V5ZArXLgS9qwniVT8VD8f/w0C4opJGyNMmMRWGGR139STrLy dxK5uMdqSufP3ppCrZaBhMxw9e93GuuDzxftVw1N0mBpjSidsqnQoLJiN7QvU3R1YXJ0IFdp bGxpYW0gQ2FyZCA8c3R1LmNhcmRAYXhlbnRlcnByaXplLmNvbT6IeAQTEQIAOBYhBDbKqfE+ xHVTMRc+Kkuz0NGtsHi+BQJfA2S+AhsjBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEEuz 0NGtsHi+lhsAoJqGqvLU5IEt1nahjQ8Gdtmk6NtFAKCKkEpLa3gyKUxJtpjq/TfPk11YLrkE DQQ6QEaeEBAA+RigfloGYXpDkJXcBWyHhuxh7M1FHw7Y4KN5xsncegus5D/jRpS2MEpT13wC FkiAtRXlKZmpnwd00//jocWWIE6YZbjYDe4QXau2FxxR2FDKIldDKb6V6FYrOHhcC9v4TE3V 46pGzPvOF+gqnRRh44SpT9GDhKh5tu+Pp0NGCMbMHXdXJDhK4sTw6I4TZ5dOkhNh9tvrJQ4X /faY98h8ebByHTh1+/bBc8SDESYrQ2DD4+jWCv2hKCYLrqmus2UPogBTAaB81qujEh76DyrO H3SET8rzF/OkQOnX0ne2Qi0CNsEmy2henXyYCQqNfi3t5F159dSST5sYjvwqp0t8MvZCV7cI fwgXcqK61qlC8wXo+VMROU+28W65Szgg2gGnVqMU6Y9AVfPQB8bLQ6mUrfdMZIZJ+AyDvWXp F9Sh01D49Vlf3HZSTz09jdvOmeFXklnN/biudE/F/Ha8g8VHMGHOfMlm/xX5u/2RXscBqtNb no2gpXI61Brwv0YAWCvl9Ij9WE5J280gtJ3kkQc2azNsOA1FHQ98iLMcfFstjvbzySPAQ/Cl WxiNjrtVjLhdONM0/XwXV0OjHRhs3jMhLLUq/zzhsSlAGBGNfISnCnLWhsQDGcgHKXrKlQzZ lp+r0ApQmwJG0wg9ZqRdQZ+cfL2JSyIZJrqrol7DVes91hcAAgIQAMNvvhEBqOLNS6qAtj+V xdIJR3zWR/ocrre94V8TZWrdiblN8tbJWBsVAUVjhQB04ygXO5RbpyDpMCMimnzLQ95immw5 vyoL+iqbCHGmlr/BBvJUUc3BvbERona1MZ7Bt+fe9n6Tc1ipyDNzkguk0mEAgsoRHtLb7TsT eUU7TrWbmutBjxmjUBad9yVNV0QAlnYQBS1t01OkeYqRMS3YxRLAF097VTOR+WHw3e8m9zMh ZQAuC3Delii8QT4vzVqIiLdW8wwHgHz1qM5hhZVU4La5jnvtrUbFvxc5cLvREAGuAjW4JXgN h1OD6zWlXXTwiyfrHDWEIMMAXIYVYgYWgT83FB0ddsCDD7H5+8sGjuqZ/J+XF8l2BQDnQGK2 9Ht6jBRH8CfG0uwG9yVTNc+LgewR9/Ub8/UudxWyuK0pbFWQr1bAeJ3hwnGYIedvcAdFXcQo rVbCd5ayhBVht8wyCK2JlgNa2Zq+30ymyZJKb8zBhwNtrNczegjn3EgIRBRCxZdh7uCRyZFL Sdz2QJ6Q8RqldorNWGUnB2Jhbkiq3/0P99F0CwlhSLmHiJAOodCB6oIYfU3WqAqrHtutSccd 7V6t+D3slaOptqXcJb0Q06xuccwzYmEIu6mqxBuawjPoAZNGcx3kSJab6cd5TayXR586ik5q HOJmlZ8e43TbCjSpiEYEGBECAAYFAjpARp4ACgkQS7PQ0a2weL65HgCePHJT7ryvg2LwPGgK 0yVFIpzmWa0AnjgpvFwf0EHDFhjEr8y2AnKzNN2X X-Forwarded-Message-Id: <0.0.46.863.1D6749DCC4B1CA0.0@drone113.ral.icpbounce.com> Message-ID: <0c36d486-e6ff-e3a8-b958-d48f4e2d9cbb@axenterprize.com> Date: Tue, 18 Aug 2020 11:23:57 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <0.0.46.863.1D6749DCC4B1CA0.0@drone113.ral.icpbounce.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LCvnXnAPFeAQb2nZV7WS7DSZkeyJIKjP2" Archived-At: Subject: [Drip] Fwd: Free Webcast: IoT, MUD, and Enterprises: August 20 X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 15:23:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LCvnXnAPFeAQb2nZV7WS7DSZkeyJIKjP2 Content-Type: multipart/mixed; boundary="wkRuXFdsigC4rCPdtLH7ucM1RwNdxSIsE"; protected-headers="v1" From: "Stuart W. Card" To: "tm-rid@ietf.org" Message-ID: <0c36d486-e6ff-e3a8-b958-d48f4e2d9cbb@axenterprize.com> Subject: Fwd: Free Webcast: IoT, MUD, and Enterprises: August 20 References: <0.0.46.863.1D6749DCC4B1CA0.0@drone113.ral.icpbounce.com> In-Reply-To: <0.0.46.863.1D6749DCC4B1CA0.0@drone113.ral.icpbounce.com> --wkRuXFdsigC4rCPdtLH7ucM1RwNdxSIsE Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable This may be of interest to DRIP participants and co-stars our friend Michael Richardson. I consider UAS increasingly to be IoT "things". UAS certainly have potential for physical space harm, privacy invasion (both by and against their operators), administrative scale challenges, etc., which will be discussed in this webcast. -------- Forwarded Message -------- Subject: Free Webcast: IoT, MUD, and Enterprises: August 20 Date: Mon, 17 Aug 2020 09:57:09 -0400 From: Nalini Elkins Reply-To: nalini.elkins@insidethestack.com To: stu.card@axenterprize.com =C2=A0 =09 *Free Webcast: IoT, MUD and Enterprises* =C2=A0 Date: August 20, 2020 Time: 8:00am pacific (11:00am eastern) Registration: HERE This webinar will be taught by Michael Richardson=C2=A0and Dr. Anna Maria= Mandalari. Between the number and type of IoT=C2=A0devices that may=C2=A0be=C2=A0use= d by enterprises, in short order there will not be enough people on the earth to administer them. =C2=A0New means of scale are required. =C2=A0Do old assumptions hold? Standards such as Manufacturer Usage Descriptions and CoAP are emerging. *Anna Maria's talk:* The emerging complicated Internet of Things (IoT) ecosystem will not only rely on collection and processing of personal data, but also performs actuations in the real world and thus, have physical consequences. The potential harms to individuals and society are=C2=A0significantly more serious than privacy alone. This greatly increases the challenge in delivering public safety, acceptability and trust as identified in the large number of government and independent reviews and research findings. We have been developing the opensource Databox Platform. Beyond its research impact, Databox is currently turning into a popular opensource platform for privacy-preserving data analysis. In this talk, I will explore what we are invisible trading in exchange for these devices, and discuss potential future mitigation through Databox.=C2=A0 *Biography:* Dr. Anna Maria Mandalari works as research associate in the Dyson School of Design Engineering at the Faculty of Engineering at Imperial College London. She was a Marie Curie Early Stage Researcher affiliated with the University Carlos III of Madrid, within the European project ITN METRICS. During her PhD she was research visitor at Telefonica I+D (Spain) and Simula Research Laboratory (Norway). Her research interests are related to IoT, privacy, large-scale Internet measurements, Internet measurement platforms, middleboxes and new Internet protocols. *Michael Richardson's talk:=C2=A0* A critical part of managing privacy and authorization in enterprise networks involves managing identity. =C2=A0There is a rich field of ident= ity management offerings from big and small. There are multiple identity management conferences one can attend (now going virtual). There are no dominant identity management mechanisms, and no dominant onboarding systems for IoT devices. * What kinds of devices should enterprises expect to deal with? * What should enterprises look for in feature sets of devices that they expect to acquire? This is a interactive discussion dealing with the question of how enterprises can navigate managing identities for IoT, BYOD, and remote workers. *Biography:* Michael Richardson is an open source and open standards consultant. An autodidact, he wrote mail transfer agents as a teenager, and in the 1990s, found his calling designing and building embedded networking products, in the security sector. =C2=A0Michael has built multiple IPsec systems, joining the FreeS/WAN team in 2001, and founding Xelerance in 2003. Since 2008 Michael has worked in and chaired the IETF ROLL working group, doing routing protocols for IoT mesh systems. =C2=A0Michael has authored a number of IoT related RFCs including RFC8366 and RFC7416. Michael currently works on IoT security systems in the 6tisch, ANIMA and ACE WG, specializing in the problem of initial bootstrap trust. =C2=A0 Nalini Elkins Inside Products, Inc.=C2=A0=C2=A0 www.insidethestack.com =C2=A0=C2=A0 =C2=A0 =09 =C2=A0 =09 *Inside Products* =C2=A0 Inside Products offers innovative solutions for managing TCP/IP networks. Our focus is to improve the productivity of the systems programming staff who maintain the data processing infrastructure for large corporations, educational institutions, and government agencies. We are technical people who write products for other technical people. For more information, please go to: =C2=A0 http://www.insidethestack.com =C2=A0 =C2=A0 =C2=A0 Manage Your Subscription This message was sent to *stu.card@axenterprize.com* from *nalini.elkins@insidethestack.com* Nalini Elkins Inside Products 36A Upper Circle Carmel Valley, CA 93924 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - iContact - Try it for FREE --wkRuXFdsigC4rCPdtLH7ucM1RwNdxSIsE-- --LCvnXnAPFeAQb2nZV7WS7DSZkeyJIKjP2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQ2yqnxPsR1UzEXPipLs9DRrbB4vgUCXzvyjQAKCRBLs9DRrbB4 vvWtAKCXFZVC/OvsJ30cTpPOn9qAssrbzQCfSx7nixCSuFOFzlfkRCTVySn8W4g= =igco -----END PGP SIGNATURE----- --LCvnXnAPFeAQb2nZV7WS7DSZkeyJIKjP2-- From nobody Tue Aug 18 14:07:34 2020 Return-Path: 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 4A1AB3A0C89 for ; Tue, 18 Aug 2020 14:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 DrJEt_RDIspa for ; Tue, 18 Aug 2020 14:07:30 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BE743A0C82 for ; Tue, 18 Aug 2020 14:07:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 0CE46389BB; Tue, 18 Aug 2020 16:46:37 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ns8xsT5gjYKM; Tue, 18 Aug 2020 16:46:34 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 08AD6389BD; Tue, 18 Aug 2020 16:46:34 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 478CD65A; Tue, 18 Aug 2020 17:07:24 -0400 (EDT) From: Michael Richardson To: Robert Moskowitz cc: tm-rid@ietf.org In-Reply-To: <66b18e96-dcb4-9504-14ae-fe98854d919a@labs.htt-consult.com> References: <13083.1597377416@localhost> <4024.1597619851@dooku> <17436.1597621157@localhost> <66b18e96-dcb4-9504-14ae-fe98854d919a@labs.htt-consult.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Drip] some comments on drip-secure-nrid-c2 X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 21:07:32 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Robert Moskowitz wrote: > On 8/16/20 7:39 PM, Michael Richardson wrote: >> So, again, I don't like "C2", I'd rather C&C. > C2 is the accepted industry term.=C2=A0 We really can't come up with = our own. In that industry, yes :-) >> So that's Unmanned Aircraft System Service Supplier Network Secure P= rovider. >> Does that make any sense? Not to me. >> I understand that maybe it comes from an FAA UTM document? > https://www.faa.gov/uas/research_development/traffic_management/media= /UTM_ConOps_v2.pdf can we mark which terms are imported (and from where)? I think that this will help reviewers make better peace with the difficult = terminological choices. >> What's the business model for these things? > Much is still unknown.=C2=A0 Stu is active in the study group on this. okay. While we think that we don't do business models, we *do* risk and threat analysis, and if an entity has a financial disincentive to do something well, then it won't get done. Robert Moskowitz wrote: >>> I understand that maybe it comes from an FAA UTM document? >> >> https://www.faa.gov/uas/research_development/traffic_management/medi= a/UTM_ConOps_v2.pdf >> > Another important document to get aviation Unmanned Aircraft terms an= d TLAs: > https://www.icao.int/Meetings/UAS/Documents/Circular%20328_en.pdf > You Canadians can call this work RPAS, rather than UAS...=C2=A0 :) I'm sure it translates to francais in some way that neither of us understan= d. https://www.youtube.com/watch?v=3DxrLghyJ_uQA =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl88QwwACgkQgItw+93Q 3WV2xwgAs0mirG1p7lntcIMHKXrUQWM7DBisd0d5mf1zE8Oo3ieZoievcZmxGj/p Fue/VMWVU0ZJXE5T8MI3NuXyqc4dmFns3fi3NbsLPJilRB1iUruci/DEurS6hNHv uTRI6b/Y9zlRUuYeh+znDlpVgHzhUstz0u4FHol35PygXcIcsjGLMg5Y10UoBtKV YJrrVb2rmqTank/xmjD13WREURhPBU01INjOCHRWK9HmV2RM4IXH5scnLnwyQYnk Bd2z2TJuO8VqM5aHZWcey42i0k8GN2Vwz6C+U9qzZ+3d6JqkVwrrHxHyQCrvBXoR hM2RIHkK6ch0toRPjUrxEI/S8ljNcQ== =2Ye/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 21 14:22:14 2020 Return-Path: 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 A48EE3A12A3 for ; Fri, 21 Aug 2020 14:22:12 -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, 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 fmAzc2ETWMqX for ; Fri, 21 Aug 2020 14:22:10 -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 1C18D3A129F for ; Fri, 21 Aug 2020 14:22:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id A26C262494 for ; Fri, 21 Aug 2020 17:22:08 -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 XX1XJCUCioVi for ; Fri, 21 Aug 2020 17:22:03 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (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 687DB623CC for ; Fri, 21 Aug 2020 17:22:02 -0400 (EDT) References: <159804470880.15422.15123232567634257837@ietfa.amsl.com> To: "tm-rid@ietf.org" From: Robert Moskowitz X-Forwarded-Message-Id: <159804470880.15422.15123232567634257837@ietfa.amsl.com> Message-ID: <6ac19e17-a8de-d693-541c-947d026b9c37@labs.htt-consult.com> Date: Fri, 21 Aug 2020 17:21:53 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <159804470880.15422.15123232567634257837@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------13CC4BA64EFAC48BD6731066" Content-Language: en-US Archived-At: Subject: [Drip] Fwd: New Version Notification for draft-moskowitz-drip-operator-privacy-05.txt X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2020 21:22:13 -0000 This is a multi-part message in MIME format. --------------13CC4BA64EFAC48BD6731066 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit In this new version, I have directly included the ECIES shared secret generation using KMAC.  Now the only draft referenced is the drip-reqs draft. Please review, this will be presented at next weeks interim meeting. (note I will probably make one change in the definitions section of the uas-rid draft for the interim meeting) -------- Forwarded Message -------- Subject: New Version Notification for draft-moskowitz-drip-operator-privacy-05.txt Date: Fri, 21 Aug 2020 14:18:28 -0700 From: internet-drafts@ietf.org To: Stuart W. Card , Adam Wiethuechter , Robert Moskowitz , Stuart Card A new version of I-D, draft-moskowitz-drip-operator-privacy-05.txt has been successfully submitted by Robert Moskowitz and posted to the IETF repository. Name: draft-moskowitz-drip-operator-privacy Revision: 05 Title: UAS Operator Privacy for RemoteID Messages Document date: 2020-08-21 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/internet-drafts/draft-moskowitz-drip-operator-privacy-05.txt Status: https://datatracker.ietf.org/doc/draft-moskowitz-drip-operator-privacy/ Htmlized: https://tools.ietf.org/html/draft-moskowitz-drip-operator-privacy-05 Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-drip-operator-privacy Diff: https://www.ietf.org/rfcdiff?url2=draft-moskowitz-drip-operator-privacy-05 Abstract: This document describes a method of providing privacy for UAS Operator/Pilot information specified in the ASTM UAS Remote ID and Tracking messages. This is achieved by encrypting, in place, those fields containing Operator sensitive data using a hybrid ECIES. 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. The IETF Secretariat --------------13CC4BA64EFAC48BD6731066 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit In this new version, I have directly included the ECIES shared secret generation using KMAC.  Now the only draft referenced is the drip-reqs draft.

Please review, this will be presented at next weeks interim meeting.

(note I will probably make one change in the definitions section of the uas-rid draft for the interim meeting)


-------- Forwarded Message --------
Subject: New Version Notification for draft-moskowitz-drip-operator-privacy-05.txt
Date: Fri, 21 Aug 2020 14:18:28 -0700
From: internet-drafts@ietf.org
To: Stuart W. Card <stu.card@axenterprize.com>, Adam Wiethuechter <adam.wiethuechter@axenterprize.com>, Robert Moskowitz <rgm@labs.htt-consult.com>, Stuart Card <stu.card@axenterprize.com>



A new version of I-D, draft-moskowitz-drip-operator-privacy-05.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-drip-operator-privacy
Revision: 05
Title: UAS Operator Privacy for RemoteID Messages
Document date: 2020-08-21
Group: Individual Submission
Pages: 13
URL: https://www.ietf.org/internet-drafts/draft-moskowitz-drip-operator-privacy-05.txt
Status: https://datatracker.ietf.org/doc/draft-moskowitz-drip-operator-privacy/
Htmlized: https://tools.ietf.org/html/draft-moskowitz-drip-operator-privacy-05
Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-drip-operator-privacy
Diff: https://www.ietf.org/rfcdiff?url2=draft-moskowitz-drip-operator-privacy-05

Abstract:
This document describes a method of providing privacy for UAS
Operator/Pilot information specified in the ASTM UAS Remote ID and
Tracking messages. This is achieved by encrypting, in place, those
fields containing Operator sensitive data using a hybrid ECIES.



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.

The IETF Secretariat


--------------13CC4BA64EFAC48BD6731066-- From nobody Sun Aug 23 11:02:10 2020 Return-Path: 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 9BAF43A0C4E for ; Sun, 23 Aug 2020 11:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[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=axenterprize.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 yRUHO4mjUoTp for ; Sun, 23 Aug 2020 11:02:06 -0700 (PDT) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D62DE3A0C4A for ; Sun, 23 Aug 2020 11:02:05 -0700 (PDT) Received: by mail-ej1-x635.google.com with SMTP id d11so8838185ejt.13 for ; Sun, 23 Aug 2020 11:02:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axenterprize.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=F2IB+zBteT7ZHFPINgkP8nTIBfbBrcOlZQu/NCyvnik=; b=qaaWB5hZ77B2BxRBpomEKVwhO/XiluykfOHFw+ugD4I6tvxfGsE7AL1iKx44H3e76/ JVJezm3WN/F6nhEiXqgX3U6mBrcckN82LLfndBeI2+F+1ezwexLs5AXtaSkZWIu0CwXK 8b3JUNfQKflpdZahdb6cI7JPX6j5swHSS64q4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=F2IB+zBteT7ZHFPINgkP8nTIBfbBrcOlZQu/NCyvnik=; b=aP0rB2eDMak5N/aPZqcZpKoVn58LLb1YozmMbzP757XRF/UarKiaT6PPuuMJR4v4Ss nAZ1khokyJ6rRiHwimc2WglJmAWTF+QbP7CjRvET8TuEgHWnOXcqa5eEGLBryasM+1bA oE+hfPoH9Weh//f5zbe2HPYjo7xbuCyZtsjYU4nDIaw6wmgC9JJOI7y7EJSokHKFwIuF SWNj3j2iqTryloQHaA2DaqM+w1f1YKJkskrZ3sF0fuGbQ5rz+YJVwJ4bG76PneHNSX62 Stq9ztmIEhjHlsdlxZzLfroljTdym5SMfzaioNzqN1YI4f2otLoQJmH0cinORMGsTshr JVTw== X-Gm-Message-State: AOAM530boRneTdMrn9dk7GkFfspZ5Wl2J8KcjDc7Zn3wVVs1s+ai2NSz IU96CHJQ+JV1YkPbpDHin6fenBaMl3yXbPuSGxl9P8dMH36M5Iag X-Google-Smtp-Source: ABdhPJyj0AERV6YzSfw3mLKBsBw1mrFo7xqQdwIE0GssK+xr0A24HebkMWr/ZSLOEDt6hAFiv7/tm8uZC4Q6UGdW8U0= X-Received: by 2002:a17:906:a43:: with SMTP id x3mr2243703ejf.321.1598205723839; Sun, 23 Aug 2020 11:02:03 -0700 (PDT) MIME-Version: 1.0 From: "Card, Stu" Date: Sun, 23 Aug 2020 14:01:53 -0400 Message-ID: To: tm-rid@ietf.org Content-Type: multipart/alternative; boundary="00000000000072a50805ad8f4471" Archived-At: Subject: [Drip] auto license plates X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Aug 2020 18:02:08 -0000 --00000000000072a50805ad8f4471 Content-Type: text/plain; charset="UTF-8" There have been numerous references to automobile license plates in our discussions. Lest anyone think these are globally uniform or have always been as they are now, see https://en.wikipedia.org/wiki/Vehicle_registration_plate https://magazine.northeast.aaa.com/daily/life/cars-trucks/license-plate-history/ esp. the 1977 entry. --00000000000072a50805ad8f4471 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There have been numerous references to automobile license = plates in our discussions. Lest anyone think these are globally uniform or = have always been as they are now, see


esp. the 1977 entry.
=C2=A0
--00000000000072a50805ad8f4471-- From nobody Sun Aug 23 11:55:47 2020 Return-Path: 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 031E53A09FC for ; Sun, 23 Aug 2020 11:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=axenterprize.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 AoerL7QJ9SXl for ; Sun, 23 Aug 2020 11:55:44 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A236C3A09FA for ; Sun, 23 Aug 2020 11:55:44 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id o12so1013579qki.13 for ; Sun, 23 Aug 2020 11:55:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axenterprize.com; s=google; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to; bh=BiyTlF+hOpogBWATjWbU+MfShEv0XFC7NExRoGgrF0I=; b=F9rvYWESKfGtU3t0Y/oSR/LgqVh5NGQGUsFJReHyLIfGqB1XfpbNCkoPWrJsJRFJgV MWKd9wYCcCwBHBabPfPu1n/0hOzDsNuTxI8pr2hDCgEYHGYN13Ungk8M5uFnyo0u0MX1 lf3A/ec0x9DuDoG4DyM4x7xvN3c7OZFY1fc2s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:autocrypt:message-id :date:user-agent:mime-version:in-reply-to; bh=BiyTlF+hOpogBWATjWbU+MfShEv0XFC7NExRoGgrF0I=; b=bjy4qEGMB6g5lfw5raD6/54bqHcOMgwBHKk2lRP+j9Lx7wfGAPdVOMDz/BJH6YAO+c TpgCVKGykigjRTP3Po5adIBSP6xENfM3Dfxfb+/oYFQhNwYzjp3r6sTUNLn4NiZB84Gr 8eCNY0WOXDbyKQiDggPME04/x5Y7ystf/YllXOSXGrzcdDplD0afrfcNCMwVLQptW01b yXZnRv+BA8MnDHcMAiIFXBbnVHcIEEdaVF9YKY9J+nYgI+o8nMDBQUvjbXY3p7LU6iSG JzO3xi5LcNdJmYRvyDBd+jFmBAyQoooItVK4K4jqMLFQYdiVaC6pZZL771wVHCudbkK7 ppzA== X-Gm-Message-State: AOAM533VZvVs1rdwuMdvWK605odx0hiroAaNArDmElTfIJKAljh2Z+/N BfrQC3Dv3+ra7CNmHczto3aKxIZGkHqST3yg X-Google-Smtp-Source: ABdhPJwZ4TjGCU42LOIjs79nAkXnDZ0GIZpfiQN44O5wtdqSi7yifnOqjuveBVg6VV6T+RIr8+VsWg== X-Received: by 2002:a05:620a:5c:: with SMTP id t28mr1993635qkt.348.1598208942942; Sun, 23 Aug 2020 11:55:42 -0700 (PDT) Received: from [192.168.1.146] (ip-72-10-210-250.nwptny.ntcnet.net. [72.10.210.250]) by smtp.gmail.com with ESMTPSA id g13sm2143308qki.62.2020.08.23.11.55.41 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 23 Aug 2020 11:55:42 -0700 (PDT) To: tm-rid@ietf.org References: <13083.1597377416@localhost> <4024.1597619851@dooku> From: "Stuart W. Card" Autocrypt: addr=stu.card@axenterprize.com; prefer-encrypt=mutual; keydata= mQGiBDpARp4RBADNQipCkPP9uNjzow8Fyltan7Fsc1obeYCZsHmKB3J9GkjAOISXeg5ce7PG NxugbgU1pAkhU6bARdTYFllKGz7WP8cwRVzQvwNbDLowPImeaRFsSOSU3T1RSzAC4vIRv7Q2 amQkSZLSh105f4whqkR1QqFUPqamhxHy2itg+zUSowCg/13xoiFRCbhzEq3MaiKrHd/wyM0D /3fHb4CyuIe5c5iz+Jh4h9MSLvKnWeGzRaokBSrJj3sJf2foSWFrx8lmib0Sgzrpb1/s5c+f eE6N444bAEnGEnCwmHaFdCebTif/8t4ZPVZqGEHIye4fpegcsQwkzcIyKp7mM1KjpcfsBOg+ AKhiuBUKCkYdzg1DQiKfyiJRgXcvA/4tb35LGbLOLgRWOO78hy293tAeE+bQKa9GYKaOCk8L Gadddjh4oTrW+KUnyas/jbl6V5ZArXLgS9qwniVT8VD8f/w0C4opJGyNMmMRWGGR139STrLy dxK5uMdqSufP3ppCrZaBhMxw9e93GuuDzxftVw1N0mBpjSidsqnQoLJiN7QvU3R1YXJ0IFdp bGxpYW0gQ2FyZCA8c3R1LmNhcmRAYXhlbnRlcnByaXplLmNvbT6IeAQTEQIAOBYhBDbKqfE+ xHVTMRc+Kkuz0NGtsHi+BQJfA2S+AhsjBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEEuz 0NGtsHi+lhsAoJqGqvLU5IEt1nahjQ8Gdtmk6NtFAKCKkEpLa3gyKUxJtpjq/TfPk11YLrkE DQQ6QEaeEBAA+RigfloGYXpDkJXcBWyHhuxh7M1FHw7Y4KN5xsncegus5D/jRpS2MEpT13wC FkiAtRXlKZmpnwd00//jocWWIE6YZbjYDe4QXau2FxxR2FDKIldDKb6V6FYrOHhcC9v4TE3V 46pGzPvOF+gqnRRh44SpT9GDhKh5tu+Pp0NGCMbMHXdXJDhK4sTw6I4TZ5dOkhNh9tvrJQ4X /faY98h8ebByHTh1+/bBc8SDESYrQ2DD4+jWCv2hKCYLrqmus2UPogBTAaB81qujEh76DyrO H3SET8rzF/OkQOnX0ne2Qi0CNsEmy2henXyYCQqNfi3t5F159dSST5sYjvwqp0t8MvZCV7cI fwgXcqK61qlC8wXo+VMROU+28W65Szgg2gGnVqMU6Y9AVfPQB8bLQ6mUrfdMZIZJ+AyDvWXp F9Sh01D49Vlf3HZSTz09jdvOmeFXklnN/biudE/F/Ha8g8VHMGHOfMlm/xX5u/2RXscBqtNb no2gpXI61Brwv0YAWCvl9Ij9WE5J280gtJ3kkQc2azNsOA1FHQ98iLMcfFstjvbzySPAQ/Cl WxiNjrtVjLhdONM0/XwXV0OjHRhs3jMhLLUq/zzhsSlAGBGNfISnCnLWhsQDGcgHKXrKlQzZ lp+r0ApQmwJG0wg9ZqRdQZ+cfL2JSyIZJrqrol7DVes91hcAAgIQAMNvvhEBqOLNS6qAtj+V xdIJR3zWR/ocrre94V8TZWrdiblN8tbJWBsVAUVjhQB04ygXO5RbpyDpMCMimnzLQ95immw5 vyoL+iqbCHGmlr/BBvJUUc3BvbERona1MZ7Bt+fe9n6Tc1ipyDNzkguk0mEAgsoRHtLb7TsT eUU7TrWbmutBjxmjUBad9yVNV0QAlnYQBS1t01OkeYqRMS3YxRLAF097VTOR+WHw3e8m9zMh ZQAuC3Delii8QT4vzVqIiLdW8wwHgHz1qM5hhZVU4La5jnvtrUbFvxc5cLvREAGuAjW4JXgN h1OD6zWlXXTwiyfrHDWEIMMAXIYVYgYWgT83FB0ddsCDD7H5+8sGjuqZ/J+XF8l2BQDnQGK2 9Ht6jBRH8CfG0uwG9yVTNc+LgewR9/Ub8/UudxWyuK0pbFWQr1bAeJ3hwnGYIedvcAdFXcQo rVbCd5ayhBVht8wyCK2JlgNa2Zq+30ymyZJKb8zBhwNtrNczegjn3EgIRBRCxZdh7uCRyZFL Sdz2QJ6Q8RqldorNWGUnB2Jhbkiq3/0P99F0CwlhSLmHiJAOodCB6oIYfU3WqAqrHtutSccd 7V6t+D3slaOptqXcJb0Q06xuccwzYmEIu6mqxBuawjPoAZNGcx3kSJab6cd5TayXR586ik5q HOJmlZ8e43TbCjSpiEYEGBECAAYFAjpARp4ACgkQS7PQ0a2weL65HgCePHJT7ryvg2LwPGgK 0yVFIpzmWa0AnjgpvFwf0EHDFhjEr8y2AnKzNN2X Message-ID: <4702dd5e-e397-c846-626d-796ae91336bb@axenterprize.com> Date: Sun, 23 Aug 2020 14:55:29 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <4024.1597619851@dooku> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jjHlxVPonGpVHOv76SIMXqWHmmZYvIdfp" Archived-At: Subject: [Drip] SDSP example (was: some comments on drip-crowd-sourced-rid) X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Aug 2020 18:55:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jjHlxVPonGpVHOv76SIMXqWHmmZYvIdfp Content-Type: multipart/mixed; boundary="g69WKEQIANGFzwT3FekBQR9SWno0uLxG5"; protected-headers="v1" From: "Stuart W. Card" To: tm-rid@ietf.org Message-ID: <4702dd5e-e397-c846-626d-796ae91336bb@axenterprize.com> Subject: SDSP example (was: some comments on drip-crowd-sourced-rid) References: <13083.1597377416@localhost> <4024.1597619851@dooku> In-Reply-To: <4024.1597619851@dooku> --g69WKEQIANGFzwT3FekBQR9SWno0uLxG5 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Weather information. Paid subscription service. Why that would be part of the UTM network, vs external, I don't know, but it is the standard cited example in the UTM world. On 8/16/2020 7:17 PM, Michael Richardson wrote: > ... > I would sure like to have an example of an SDSP, particularly in the > introduction of this document. Who would operate such a thing? > What's their business model? ... --=20 ----------------------------------------- Stuart W. Card, PhD, Principal Engineer AX Enterprize, LLC www.axenterprize.com 4947 Commercial Drive, Yorkville NY 13495 --g69WKEQIANGFzwT3FekBQR9SWno0uLxG5-- --jjHlxVPonGpVHOv76SIMXqWHmmZYvIdfp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQ2yqnxPsR1UzEXPipLs9DRrbB4vgUCX0K7oQAKCRBLs9DRrbB4 vu9CAJ9Hc/LjXdJdmG1t7cNf1ulP08f+WACg/hoVEY9eYtIHJz1JwakoEp+Cscw= =93tG -----END PGP SIGNATURE----- --jjHlxVPonGpVHOv76SIMXqWHmmZYvIdfp-- From nobody Mon Aug 24 01:33:13 2020 Return-Path: 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 E7DE03A08EB for ; Mon, 24 Aug 2020 01:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.23 X-Spam-Level: ** X-Spam-Status: No, score=2.23 tagged_above=-999 required=5 tests=[DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.948, NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.972, URIBL_BLOCKED=0.001] autolearn=no 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 Xwi74ozdYX1Y for ; Mon, 24 Aug 2020 01:33:09 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 3C57A3A08EE for ; Mon, 24 Aug 2020 01:33:08 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 07O8X7gb010065 for ; Mon, 24 Aug 2020 10:33:07 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0ECC7203DD1 for ; Mon, 24 Aug 2020 10:33:07 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 05192203DD0 for ; Mon, 24 Aug 2020 10:33:07 +0200 (CEST) Received: from [10.11.240.62] ([10.11.240.62]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 07O8X6xp020434 for ; Mon, 24 Aug 2020 10:33:06 +0200 To: tm-rid@ietf.org References: From: Alexandre Petrescu Message-ID: Date: Mon, 24 Aug 2020 10:33:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Drip] auto license plates X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2020 08:33:11 -0000 Stuart, Thanks for pointing to this. Le 23/08/2020 à 20:01, Card, Stu a écrit : > There have been numerous references to automobile license plates in our > discussions. Lest anyone think these are globally uniform or have always > been as they are now, see I agree, they are not globally uniform. They are not globally unique either. I could spot some similarities in format, and a potential duplicate between two countries in Europe. And, within each country there are many exceptions. For example, a classical exception is the license plate of diplomatic cars. Finally, the formats change regularly (every few decades or so) for reasons that include: run out of space, new strategy of allocation per person or per car, new uniformisation along geopolitical strategy, new privacy requirements, and others. > https://en.wikipedia.org/wiki/Vehicle_registration_plate Thanks for the pointer to Wikipedia. I do not agree with it because it does not list the country where I live. > https://magazine.northeast.aaa.com/daily/life/cars-trucks/license-plate-history/ > esp. the 1977 entry. I wonder what happened in year 1977 with respect to license plates and why do they talk about it? I can not see that web page. The page is simply blocked. The reason invoked is "Block reason: Access from your Country was disabled by the administrator." This is the full message displayed in the browser: > Website Firewall > Back to sucuri.net > Access Denied - Sucuri Website Firewall > > If you are the site owner (or you manage this site), please whitelist your IP or if you think this block is an error please open a support ticket and make sure to include the block details (displayed in the box below), so we can assist you in troubleshooting the issue. > Block details: > Your IP: [my publicly routable IP address of the enteprise IT NAT facing the Internet] > URL: magazine.northeast.aaa.com/daily/life/cars-trucks/license-plate-history/ > Your Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:79.0) Gecko/20100101 Firefox/79.0 > Block ID: GEO02 > Block reason: Access from your Country was disabled by the administrator. > Time: 2020-08-24 04:19:02 > Server ID: 13006 > © 2019 Sucuri Inc. All rights reserved. Privacy Alex > > From nobody Mon Aug 24 09:16:24 2020 Return-Path: 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 042D73A1094 for ; Mon, 24 Aug 2020 09:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.147 X-Spam-Level: X-Spam-Status: No, score=-1.147 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.948, 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=axenterprize.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 92LjibaUEsMc for ; Mon, 24 Aug 2020 09:16:20 -0700 (PDT) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 370A13A1091 for ; Mon, 24 Aug 2020 09:16:19 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id t23so6567306qto.3 for ; Mon, 24 Aug 2020 09:16:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axenterprize.com; s=google; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to; bh=0QmfuQrbFHHMToR+S7NmvcA4TGGD2P9tXU6wi95BYPg=; b=sk6hgd/l8bE+i8NbEoWdjePXj2Gnrle2xiyAmuwFp3QVbDsuIHTxxknyDhz6LcuQly CUW2mq5Kh/lcuvKMHUF7MB6W59qo4fdSjXqk4ysKdg1lPEp94ur6FcuPSl+TbElaF2Tn ShEWknCnKUDiQQI0mphIH8KOTpg7MtSb73EZo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:autocrypt:message-id :date:user-agent:mime-version:in-reply-to; bh=0QmfuQrbFHHMToR+S7NmvcA4TGGD2P9tXU6wi95BYPg=; b=UePUiLrqRZGoNsPl0SFvzuF1evQln0fyGQXWlBS/Rq3Vl/e4LdMXVZWa88Cf9Er9pU DLnR2Qhf8T/+Kj6vHSbE6sb9eEred/gozFj7zSY86TaP/Msaerl4dH/FBL3wgiCWXaEx YjX8MbnoYy3e1jGCupqKItpKdkdPgctyHuyNnATpcC5934mrbExdMHS5nzhQv9WoLVrJ 7iLHsZEabHcJnFkQo3SSGss/CLFgooCad2VwbAOzq7H/hBHNVsdDsKv2cksupQTAShvg AyOg+mU6Yu5Utdw84Tl+MMPS0LHSFtSh+SamWqeGTidzDMIaBiF4gfYM6befXQoOu5QF J2Mw== X-Gm-Message-State: AOAM533gpirNn7LuJidAOu5wHRvznAoD02BaLzIkyBQlRWzRTCa52ZQI sVg2UMHEXrfC33P+MxkvcxICkJpECYPBCVzL X-Google-Smtp-Source: ABdhPJygV4Kf/xy/yof1AuN2tTdFkSZB8pfthI+kswPsXxldT/hUSR5a3P1+jsE+ipYg9M+B4eXXlw== X-Received: by 2002:aed:3ac7:: with SMTP id o65mr5517666qte.11.1598285778702; Mon, 24 Aug 2020 09:16:18 -0700 (PDT) Received: from [192.168.1.107] (ip-72-10-210-250.nwptny.ntcnet.net. [72.10.210.250]) by smtp.gmail.com with ESMTPSA id q7sm9655500qkf.35.2020.08.24.09.16.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 24 Aug 2020 09:16:18 -0700 (PDT) To: tm-rid@ietf.org References: From: "Stuart W. Card" Autocrypt: addr=stu.card@axenterprize.com; prefer-encrypt=mutual; keydata= mQGiBDpARp4RBADNQipCkPP9uNjzow8Fyltan7Fsc1obeYCZsHmKB3J9GkjAOISXeg5ce7PG NxugbgU1pAkhU6bARdTYFllKGz7WP8cwRVzQvwNbDLowPImeaRFsSOSU3T1RSzAC4vIRv7Q2 amQkSZLSh105f4whqkR1QqFUPqamhxHy2itg+zUSowCg/13xoiFRCbhzEq3MaiKrHd/wyM0D /3fHb4CyuIe5c5iz+Jh4h9MSLvKnWeGzRaokBSrJj3sJf2foSWFrx8lmib0Sgzrpb1/s5c+f eE6N444bAEnGEnCwmHaFdCebTif/8t4ZPVZqGEHIye4fpegcsQwkzcIyKp7mM1KjpcfsBOg+ AKhiuBUKCkYdzg1DQiKfyiJRgXcvA/4tb35LGbLOLgRWOO78hy293tAeE+bQKa9GYKaOCk8L Gadddjh4oTrW+KUnyas/jbl6V5ZArXLgS9qwniVT8VD8f/w0C4opJGyNMmMRWGGR139STrLy dxK5uMdqSufP3ppCrZaBhMxw9e93GuuDzxftVw1N0mBpjSidsqnQoLJiN7QvU3R1YXJ0IFdp bGxpYW0gQ2FyZCA8c3R1LmNhcmRAYXhlbnRlcnByaXplLmNvbT6IeAQTEQIAOBYhBDbKqfE+ xHVTMRc+Kkuz0NGtsHi+BQJfA2S+AhsjBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEEuz 0NGtsHi+lhsAoJqGqvLU5IEt1nahjQ8Gdtmk6NtFAKCKkEpLa3gyKUxJtpjq/TfPk11YLrkE DQQ6QEaeEBAA+RigfloGYXpDkJXcBWyHhuxh7M1FHw7Y4KN5xsncegus5D/jRpS2MEpT13wC FkiAtRXlKZmpnwd00//jocWWIE6YZbjYDe4QXau2FxxR2FDKIldDKb6V6FYrOHhcC9v4TE3V 46pGzPvOF+gqnRRh44SpT9GDhKh5tu+Pp0NGCMbMHXdXJDhK4sTw6I4TZ5dOkhNh9tvrJQ4X /faY98h8ebByHTh1+/bBc8SDESYrQ2DD4+jWCv2hKCYLrqmus2UPogBTAaB81qujEh76DyrO H3SET8rzF/OkQOnX0ne2Qi0CNsEmy2henXyYCQqNfi3t5F159dSST5sYjvwqp0t8MvZCV7cI fwgXcqK61qlC8wXo+VMROU+28W65Szgg2gGnVqMU6Y9AVfPQB8bLQ6mUrfdMZIZJ+AyDvWXp F9Sh01D49Vlf3HZSTz09jdvOmeFXklnN/biudE/F/Ha8g8VHMGHOfMlm/xX5u/2RXscBqtNb no2gpXI61Brwv0YAWCvl9Ij9WE5J280gtJ3kkQc2azNsOA1FHQ98iLMcfFstjvbzySPAQ/Cl WxiNjrtVjLhdONM0/XwXV0OjHRhs3jMhLLUq/zzhsSlAGBGNfISnCnLWhsQDGcgHKXrKlQzZ lp+r0ApQmwJG0wg9ZqRdQZ+cfL2JSyIZJrqrol7DVes91hcAAgIQAMNvvhEBqOLNS6qAtj+V xdIJR3zWR/ocrre94V8TZWrdiblN8tbJWBsVAUVjhQB04ygXO5RbpyDpMCMimnzLQ95immw5 vyoL+iqbCHGmlr/BBvJUUc3BvbERona1MZ7Bt+fe9n6Tc1ipyDNzkguk0mEAgsoRHtLb7TsT eUU7TrWbmutBjxmjUBad9yVNV0QAlnYQBS1t01OkeYqRMS3YxRLAF097VTOR+WHw3e8m9zMh ZQAuC3Delii8QT4vzVqIiLdW8wwHgHz1qM5hhZVU4La5jnvtrUbFvxc5cLvREAGuAjW4JXgN h1OD6zWlXXTwiyfrHDWEIMMAXIYVYgYWgT83FB0ddsCDD7H5+8sGjuqZ/J+XF8l2BQDnQGK2 9Ht6jBRH8CfG0uwG9yVTNc+LgewR9/Ub8/UudxWyuK0pbFWQr1bAeJ3hwnGYIedvcAdFXcQo rVbCd5ayhBVht8wyCK2JlgNa2Zq+30ymyZJKb8zBhwNtrNczegjn3EgIRBRCxZdh7uCRyZFL Sdz2QJ6Q8RqldorNWGUnB2Jhbkiq3/0P99F0CwlhSLmHiJAOodCB6oIYfU3WqAqrHtutSccd 7V6t+D3slaOptqXcJb0Q06xuccwzYmEIu6mqxBuawjPoAZNGcx3kSJab6cd5TayXR586ik5q HOJmlZ8e43TbCjSpiEYEGBECAAYFAjpARp4ACgkQS7PQ0a2weL65HgCePHJT7ryvg2LwPGgK 0yVFIpzmWa0AnjgpvFwf0EHDFhjEr8y2AnKzNN2X Message-ID: <21d84f26-c0e2-2707-45ca-bd7896d3c074@axenterprize.com> Date: Mon, 24 Aug 2020 12:16:01 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bK0I71GWMyUdsZ7w1aGgJKlMAkkeGIOsf" Archived-At: Subject: Re: [Drip] auto license plates X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2020 16:16:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bK0I71GWMyUdsZ7w1aGgJKlMAkkeGIOsf Content-Type: multipart/mixed; boundary="PEruHD18INLDJqR6jhB9wsBzJJgwO3UIH"; protected-headers="v1" From: "Stuart W. Card" To: tm-rid@ietf.org Message-ID: <21d84f26-c0e2-2707-45ca-bd7896d3c074@axenterprize.com> Subject: Re: [Drip] auto license plates References: In-Reply-To: --PEruHD18INLDJqR6jhB9wsBzJJgwO3UIH Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Sorry about the blocked site, I can't imagine why it is blocked, but here is the 1977 entry I found interesting & potentially semi-relevant: > 1977 =E2=80=93 License Plates Reach the Supreme Court >=20 > The land=E2=80=99s highest court gives their decision on the case of Wo= oley v. Maynard. Up until that point, the state of New Hampshire required= all noncommercial vehicles to have license plates containing the state m= otto =E2=80=9CLive Free or Die.=E2=80=9D Resident George Maynard cut off = the words =E2=80=9Cor Die,=E2=80=9D believing they went against his relig= ious beliefs. He was cited for violating the state law, fined, and after = refusing to pay, jailed for 15 days. >=20 > Maynard sued and the case eventually made its way to the Supreme Court.= In a 6-3 decision, the court ruled that New Hampshire could not require = citizens to display the state motto, stating =E2=80=9CNew Hampshire=E2=80= =99s statute in effect requires that appellees use their private property= as a =E2=80=98mobile billboard=E2=80=99 for the State=E2=80=99s ideologi= cal message=E2=80=A6The First Amendment protects the right of individuals= to hold a point of view different from the majority, and to refuse to fo= ster, in the way New Hampshire commands, an idea they find morally object= ionable.=E2=80=9D On 8/24/2020 4:33 AM, Alexandre Petrescu wrote: > ... >> https://magazine.northeast.aaa.com/daily/life/cars-trucks/license-plat= e-history/ >> >> esp. the 1977 entry. >=20 > I wonder what happened in year 1977 with respect to license plates and > why do they talk about it? >=20 > I can not see that web page.=C2=A0 The page is simply blocked.=C2=A0 Th= e reason > invoked is "Block reason: Access from your Country was disabled by the > administrator." ... --=20 ----------------------------------------- Stuart W. Card, PhD, Principal Engineer AX Enterprize, LLC www.axenterprize.com 4947 Commercial Drive, Yorkville NY 13495 --PEruHD18INLDJqR6jhB9wsBzJJgwO3UIH-- --bK0I71GWMyUdsZ7w1aGgJKlMAkkeGIOsf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQ2yqnxPsR1UzEXPipLs9DRrbB4vgUCX0PnwQAKCRBLs9DRrbB4 vojxAKCLn1ZlXsDOP9+Lfbxlhfu90mfZDACcDMaiOJYROauG162xLlbhSdoYvT8= =DxQQ -----END PGP SIGNATURE----- --bK0I71GWMyUdsZ7w1aGgJKlMAkkeGIOsf-- From nobody Mon Aug 24 09:34:45 2020 Return-Path: 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 C94F43A0DEF for ; Mon, 24 Aug 2020 09:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.23 X-Spam-Level: ** X-Spam-Status: No, score=2.23 tagged_above=-999 required=5 tests=[DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.948, NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.972, URIBL_BLOCKED=0.001] autolearn=no 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 NZTEGLye1NYH for ; Mon, 24 Aug 2020 09:34:42 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 2D0CA3A0C6D for ; Mon, 24 Aug 2020 09:34:41 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 07OGYbTa033698; Mon, 24 Aug 2020 18:34:37 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D2E37204FBA; Mon, 24 Aug 2020 18:34:37 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C38512013F6; Mon, 24 Aug 2020 18:34:37 +0200 (CEST) Received: from [10.11.240.51] ([10.11.240.51]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 07OGYbbR010713; Mon, 24 Aug 2020 18:34:37 +0200 To: "Stuart W. Card" References: <21d84f26-c0e2-2707-45ca-bd7896d3c074@axenterprize.com> From: Alexandre Petrescu Cc: tm-rid@ietf.org Message-ID: Date: Mon, 24 Aug 2020 18:34:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <21d84f26-c0e2-2707-45ca-bd7896d3c074@axenterprize.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Drip] auto license plates X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2020 16:34:44 -0000 Le 24/08/2020 à 18:16, Stuart W. Card a écrit : > Sorry about the blocked site, I can't imagine why it is blocked, I could explain why I think it is so. It has to do with privacy concepts being different in US than Europe. Europe started first by telling incomers from everywhere else that they should accept EU privacy policy. Then some servers in California found that unacceptable and started blocking outright, until they implement the local California features. This kind of behaviour is now growing. I speculate it leads again to seggregation in the Internet. One would not like to create a new identification mechanism that risks leading to such seggregation (between drones, or whatever else). > but here is the 1977 entry I found interesting & potentially > semi-relevant: Thanks, I learn. > >> 1977 – License Plates Reach the Supreme Court >> >> The land’s highest court gives their decision on the case of >> Wooley v. Maynard. Up until that point, the state of New Hampshire >> required all noncommercial vehicles to have license plates >> containing the state motto “Live Free or Die.” Resident George >> Maynard cut off the words “or Die,” believing they went against >> his religious beliefs. He was cited for violating the state law, >> fined, and after refusing to pay, jailed for 15 days. >> >> Maynard sued and the case eventually made its way to the Supreme >> Court. In a 6-3 decision, the court ruled that New Hampshire could >> not require citizens to display the state motto, stating “New >> Hampshire’s statute in effect requires that appellees use their >> private property as a ‘mobile billboard’ for the State’s >> ideological message…The First Amendment protects the right of >> individuals to hold a point of view different from the majority, >> and to refuse to foster, in the way New Hampshire commands, an >> idea they find morally objectionable.” I did not know it. I can tell another side effect, that was unplanned for, in the country where I live. First, the license plates were mandated to tell the Region where the car is registered. E.g. 75 means it is from Paris. But then privacy issues were raised, so now one is allowed to put whatever number one wants to on her license plate, at the place typically allocated to region. Some people put the code of the region where they are born, or that they like the landscape of. But nowadays, something strange happened. In the news they said that region X has more COVID cases than any other. It amounted to 'name and shame'. If you had a license plate with the code of that region, people would look at you like at a 'pestiphéré'. So people started changing their license plate to put there something else, just because of that reason. There are more stories like: if you have a beautiful car then rather put a license plate with a region code from Corsica island, because that is known to be biting back if one tries to steal that car (a little bit like 'Dont Mess with Corsica' instead of Texas :-). The privacy question is very important. I am not sure how that is dealt with with drones. But side effects of privacy are also important. Finally, in this discussion a little bit off topic, I would like to add about the story of a few days ago about the Air Force One approaching too close to a drone, or vice versa. In this thing one would like both identifications to work properly. Alex > > On 8/24/2020 4:33 AM, Alexandre Petrescu wrote: >> ... >>> https://magazine.northeast.aaa.com/daily/life/cars-trucks/license-plate-history/ >>> >>> >>> >>> >>> >>> esp. the 1977 entry. >> >> I wonder what happened in year 1977 with respect to license plates >> and why do they talk about it? >> >> I can not see that web page. The page is simply blocked. The >> reason invoked is "Block reason: Access from your Country was >> disabled by the administrator." ... > From nobody Mon Aug 24 10:03:02 2020 Return-Path: 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 E36823A11E1 for ; Mon, 24 Aug 2020 10:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.946 X-Spam-Level: X-Spam-Status: No, score=-0.946 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, NICE_REPLY_A=-0.948, 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 1VbFawJqutf1 for ; Mon, 24 Aug 2020 10:02:58 -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 37B273A1280 for ; Mon, 24 Aug 2020 10:02:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id E73D16253B; Mon, 24 Aug 2020 13:02:39 -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 kxJSliftONxv; Mon, 24 Aug 2020 13:02:26 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (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 0B8596250B; Mon, 24 Aug 2020 13:02:23 -0400 (EDT) To: Alexandre Petrescu , "Stuart W. Card" Cc: tm-rid@ietf.org References: <21d84f26-c0e2-2707-45ca-bd7896d3c074@axenterprize.com> From: Robert Moskowitz Message-ID: Date: Mon, 24 Aug 2020 13:02:03 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8245203C2D7CC1F301E099B6" Content-Language: en-US Archived-At: Subject: Re: [Drip] auto license plates X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2020 17:03:01 -0000 This is a multi-part message in MIME format. --------------8245203C2D7CC1F301E099B6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 8/24/20 12:34 PM, Alexandre Petrescu wrote: > > > Le 24/08/2020 à 18:16, Stuart W. Card a écrit : >> Sorry about the blocked site, I can't imagine why it is blocked, > > I could explain why I think it is so.  It has to do with privacy > concepts being different in US than Europe.  Europe started first by > telling incomers from everywhere else that they should accept EU privacy > policy.  Then some servers in California found that unacceptable and > started blocking outright, until they implement the local California > features.  This kind of behaviour is now growing. > > I speculate it leads again to seggregation in the Internet. > > One would not like to create a new identification mechanism that risks > leading to such seggregation (between drones, or whatever else). Drones fall within a region's civil airspace regulatory agency so it will be balkanized without work in open standards and organizations like ICAO's involvement. There is too much at risk for allowing to let the playground stay open. > >> but here is the 1977 entry I found interesting & potentially >> semi-relevant: > > Thanks, I learn. > >> >>> 1977 – License Plates Reach the Supreme Court >>> >>> The land’s highest court gives their decision on the case of >>> Wooley v. Maynard. Up until that point, the state of New Hampshire >>>  required all noncommercial vehicles to have license plates >>> containing the state motto “Live Free or Die.” Resident George >>> Maynard cut off the words “or Die,” believing they went against >>> his religious beliefs. He was cited for violating the state law, >>> fined, and after refusing to pay, jailed for 15 days. >>> >>> Maynard sued and the case eventually made its way to the Supreme >>> Court. In a 6-3 decision, the court ruled that New Hampshire could >>> not require citizens to display the state motto, stating “New >>> Hampshire’s statute in effect requires that appellees use their >>> private property as a ‘mobile billboard’ for the State’s ideological >>> message…The First Amendment protects the right of individuals to >>> hold a point of view different from the majority, and to refuse to >>> foster, in the way New Hampshire commands, an >>> idea they find morally objectionable.” > > I did not know it. > > I can tell another side effect, that was unplanned for, in the country > where I live. > > First, the license plates were mandated to tell the Region where the car > is registered.  E.g. 75 means it is from Paris.  But then privacy issues > were raised, so now one is allowed to put whatever number one wants to > on her license plate, at the place typically allocated to region. Some > people put the code of the region where they are born, or that they like > the landscape of. > > But nowadays, something strange happened.  In the news they said that > region X has more COVID cases than any other.  It amounted to 'name and > shame'.  If you had a license plate with the code of that region, people > would look at you like at a 'pestiphéré'.   So people started changing > their license plate to put there something else, just because of that > reason.  There are more stories like: if you have a beautiful car then > rather put a license plate with a region code from Corsica island, > because that is  known to be biting back if one tries to steal that car > (a little bit like 'Dont Mess with Corsica' instead of Texas :-). > > The privacy question is very important.  I am not sure how that is dealt > with with drones. ASTM's UUID is suppose to provide a level of privacy.  But with no trust or ownship proof.  Too much 'privacy'. HHITs CAN provide privacy and discovery through proper procedures. This is, in part, through RAA/HDA that has a mix of clientele so that information is not informative. > > But side effects of privacy are also important. > > Finally, in this discussion a little bit off topic, I would like to add > about the story of a few days ago about the Air Force One approaching > too close to a drone, or vice versa.  In this thing one would like both > identifications to work properly. RID only will show 'good' players.  A news service that got too close.  A DHS drone that belongs there.  I youth's drone that was blown out of RF range of the controller (but this one was clearly under ground control based on comments). But eliminate the good players then use cs-rid to locate all else. And non-good players do not belong in over an airport.  Send in the hawks! > > Alex > >> >> On 8/24/2020 4:33 AM, Alexandre Petrescu wrote: >>> ... >>>> https://magazine.northeast.aaa.com/daily/life/cars-trucks/license-plate-history/ >>>> >>>> >>>> >>>> >>>> >>>> >>>> > esp. the 1977 entry. >>> >>> I wonder what happened in year 1977 with respect to license plates >>> and why do they talk about it? >>> >>> I can not see that web page.  The page is simply blocked.  The >>> reason invoked is "Block reason: Access from your Country was >>> disabled by the administrator." ... >> > -- 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 --------------8245203C2D7CC1F301E099B6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 8/24/20 12:34 PM, Alexandre Petrescu wrote:


Le 24/08/2020 à 18:16, Stuart W. Card a écrit :
Sorry about the blocked site, I can't imagine why it is blocked,

I could explain why I think it is so.  It has to do with privacy
concepts being different in US than Europe.  Europe started first by
telling incomers from everywhere else that they should accept EU privacy
policy.  Then some servers in California found that unacceptable and
started blocking outright, until they implement the local California
features.  This kind of behaviour is now growing.

I speculate it leads again to seggregation in the Internet.

One would not like to create a new identification mechanism that risks
leading to such seggregation (between drones, or whatever else).

Drones fall within a region's civil airspace regulatory agency so it will be balkanized without work in open standards and organizations like ICAO's involvement.

There is too much at risk for allowing to let the playground stay open.


but here is the 1977 entry I found interesting & potentially semi-relevant:

Thanks, I learn.


1977 – License Plates Reach the Supreme Court

The land’s highest court gives their decision on the case of
Wooley v. Maynard. Up until that point, the state of New Hampshire
 required all noncommercial vehicles to have license plates containing the state motto “Live Free or Die.” Resident George Maynard cut off the words “or Die,” believing they went against
his religious beliefs. He was cited for violating the state law,
fined, and after refusing to pay, jailed for 15 days.

Maynard sued and the case eventually made its way to the Supreme Court. In a 6-3 decision, the court ruled that New Hampshire could not require citizens to display the state motto, stating “New Hampshire’s statute in effect requires that appellees use their private property as a ‘mobile billboard’ for the State’s ideological message…The First Amendment protects the right of individuals to hold a point of view different from the majority, and to refuse to foster, in the way New Hampshire commands, an
idea they find morally objectionable.”

I did not know it.

I can tell another side effect, that was unplanned for, in the country
where I live.

First, the license plates were mandated to tell the Region where the car
is registered.  E.g. 75 means it is from Paris.  But then privacy issues
were raised, so now one is allowed to put whatever number one wants to
on her license plate, at the place typically allocated to region.  Some
people put the code of the region where they are born, or that they like
the landscape of.

But nowadays, something strange happened.  In the news they said that
region X has more COVID cases than any other.  It amounted to 'name and
shame'.  If you had a license plate with the code of that region, people
would look at you like at a 'pestiphéré'.   So people started changing
their license plate to put there something else, just because of that
reason.  There are more stories like: if you have a beautiful car then
rather put a license plate with a region code from Corsica island,
because that is  known to be biting back if one tries to steal that car
(a little bit like 'Dont Mess with Corsica' instead of Texas :-).

The privacy question is very important.  I am not sure how that is dealt
with with drones.

ASTM's UUID is suppose to provide a level of privacy.  But with no trust or ownship proof.  Too much 'privacy'.

HHITs CAN provide privacy and discovery through proper procedures.  This is, in part, through RAA/HDA that has a mix of clientele so that information is not informative.


But side effects of privacy are also important.

Finally, in this discussion a little bit off topic, I would like to add
about the story of a few days ago about the Air Force One approaching
too close to a drone, or vice versa.  In this thing one would like both
identifications to work properly.

RID only will show 'good' players.  A news service that got too close.  A DHS drone that belongs there.  I youth's drone that was blown out of RF range of the controller (but this one was clearly under ground control based on comments).

But eliminate the good players then use cs-rid to locate all else.  And non-good players do not belong in over an airport.  Send in the hawks!



Alex


On 8/24/2020 4:33 AM, Alexandre Petrescu wrote:
...
https://magazine.northeast.aaa.com/daily/life/cars-trucks/license-plate-history/






esp. the 1977 entry.

I wonder what happened in year 1977 with respect to license plates and why do they talk about it?

I can not see that web page.  The page is simply blocked.  The reason invoked is "Block reason: Access from your Country was disabled by the administrator." ...



--
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
--------------8245203C2D7CC1F301E099B6-- From nobody Tue Aug 25 11:48:51 2020 Return-Path: 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 349653A0826 for ; Tue, 25 Aug 2020 11:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-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 xxjIDGMuv23C for ; Tue, 25 Aug 2020 11:48:46 -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 AD2933A0825 for ; Tue, 25 Aug 2020 11:48:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 0E9D3625FC for ; Tue, 25 Aug 2020 14:48:43 -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 SXxv9+qQfUX3 for ; Tue, 25 Aug 2020 14:48:40 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (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 1790D624FD for ; Tue, 25 Aug 2020 14:48:39 -0400 (EDT) To: "tm-rid@ietf.org" From: Robert Moskowitz Message-ID: <56c28e16-e16d-9f01-f344-42b5cf0d23ac@labs.htt-consult.com> Date: Tue, 25 Aug 2020 14:48:36 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Drip] Aug 26 Interim Meeting preparation X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2020 18:48:49 -0000 Please review the following drafts in preparation of tomorrow's meeting: draft-moskowitz-drip-uas-rid draft-moskowitz-drip-operator-privacy MCR raised a question about all the TLAs in the DRIP drafts. Please review draft-ietf-drip-reqs For all the aviation specific terms.  We are trying to keep all such terms in one place and other drafts (like the 2 above) only define IETF specific terms and leave the aviation terms to the requirements draft. If you find a aviation TLA in either of these drafts NOT in the req draft, let me know! Looking forward to 'seeing' you it the August interim meeting! Bob From nobody Tue Aug 25 19:50:03 2020 Return-Path: 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 C4CBD3A0BEB for ; Tue, 25 Aug 2020 19:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, 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 (2048-bit key) header.d=gmail.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 uHmapZTfUd-P for ; Tue, 25 Aug 2020 19:49:59 -0700 (PDT) Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4AD23A0BEA for ; Tue, 25 Aug 2020 19:49:59 -0700 (PDT) Received: by mail-ua1-x931.google.com with SMTP id z12so103862uam.12 for ; Tue, 25 Aug 2020 19:49:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5MHez8s/boqYRxS9qJzoOMEPRlZkg2WQ/ED2Lz0RUGU=; b=UkvoP8gTTqMkDM1FYv4PEGOTTHeVhO5932umGm3GecD6CRigM4et4Q4SPm/AYOiVIV uy0Tu1ZT2EAKJ8z5cjw2YvLpATendJsOOt/Npn3X9QV1hZ+tNe+V7Qdgx7+JkJjMpm1W zNnN0qd83/rFbObox55HbN3IcgI8c0ilk5wyyGsjcCuvmngSe4SWnreTmlpy4d3aNevY QAN4+BzAxaCmPG8gthn632DOOurfuyY2Gk4UQ5c5mrzat7vQVpNB8pcmelzxixS4B1k/ MuZmQtH/ZBKS/SuxJ7FI4thplrNqgb/JWLNedbBGkx9IEI5kUohQYE4jlTlSkQVExvLY ZLKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5MHez8s/boqYRxS9qJzoOMEPRlZkg2WQ/ED2Lz0RUGU=; b=q3HkdM0liBHQZIFdU3FxEy/5F2dZGCIi8PN0Kb0CcOnmvRNCOxaDlNyIFbUjYEtj4j 8nz3Dzq7Tt2nn49ijLm3gsn+IpTI7aNdtIaRcindp78RPaisQUuYZFaYIR6CDyj6It2g 7iBA+3juVrXM6x7ViRySPYGztHr6iFHMAIJ2w9RoGjlqVoJKty2C/ntTNnturaIwiRFr oCtvj7YCQ97uyOODR0M5BYnmR23qQWvfzrSE+6NyTGVh4v9m6vieHDhPAAIpipa1ZSE8 kuhQujvs/8ZLV33/Z7eE/80Da3dAbJNgfnrLDulsQaYwG4T4rZWsezLhHnygqV1ZX+El 04mQ== X-Gm-Message-State: AOAM532l3YlKPhGrM/bksZVE1elnhx0xjmmwPXaI7riT8AexjBdYP3wb AYZudY6BdFNjIZbX2DxsaJpxDrDayGf+VL5lSXY= X-Google-Smtp-Source: ABdhPJzR53AvkT1g7KcoMg/YEiYbdMIBCFI9JQxPFc/Gt5461Kh4TA+8hP+HFUnoGP/9+JF9LT2brPeMnJ34VApRbwI= X-Received: by 2002:ab0:63cb:: with SMTP id i11mr6167436uap.66.1598410198807; Tue, 25 Aug 2020 19:49:58 -0700 (PDT) MIME-Version: 1.0 References: <56c28e16-e16d-9f01-f344-42b5cf0d23ac@labs.htt-consult.com> In-Reply-To: <56c28e16-e16d-9f01-f344-42b5cf0d23ac@labs.htt-consult.com> From: Daniel Migault Date: Tue, 25 Aug 2020 22:49:48 -0400 Message-ID: To: Robert Moskowitz Cc: "tm-rid@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001af99205adbee0c4" Archived-At: Subject: Re: [Drip] Aug 26 Interim Meeting preparation X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 02:50:02 -0000 --0000000000001af99205adbee0c4 Content-Type: text/plain; charset="UTF-8" Hi, Please find the agenda [1] for tomorrow's meeting. For those of you that have not yet uploaded your slides, please do so at: https://datatracker.ietf.org/meeting/interim-2020-drip-05/session/drip See you tomorrow! Yours Daniel [1] https://codimd.ietf.org/notes-ietf-interim-2020-drip-05-drip On Tue, Aug 25, 2020 at 2:48 PM Robert Moskowitz wrote: > Please review the following drafts in preparation of tomorrow's meeting: > > draft-moskowitz-drip-uas-rid > draft-moskowitz-drip-operator-privacy > > MCR raised a question about all the TLAs in the DRIP drafts. > > Please review > > draft-ietf-drip-reqs > > For all the aviation specific terms. We are trying to keep all such > terms in one place and other drafts (like the 2 above) only define IETF > specific terms and leave the aviation terms to the requirements draft. > > If you find a aviation TLA in either of these drafts NOT in the req > draft, let me know! > > Looking forward to 'seeing' you it the August interim meeting! > > Bob > > > -- > Tm-rid mailing list > Tm-rid@ietf.org > https://www.ietf.org/mailman/listinfo/tm-rid > -- Daniel Migault Ericsson --0000000000001af99205adbee0c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Please find the agenda [1] fo= r tomorrow's meeting. For those of you that have not yet uploaded your = slides, please do so at:

S= ee you tomorrow!
Yours
Daniel=C2=A0



--
Daniel Migault
Ericsson
--0000000000001af99205adbee0c4-- From nobody Tue Aug 25 20:06:20 2020 Return-Path: X-Original-To: tm-rid@ietf.org Delivered-To: tm-rid@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D89193A0BF9; Tue, 25 Aug 2020 20:06:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tm-rid@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tm-rid@ietf.org Message-ID: <159841117784.23859.1959555160770691180@ietfa.amsl.com> Date: Tue, 25 Aug 2020 20:06:17 -0700 Archived-At: Subject: [Drip] I-D Action: draft-ietf-drip-reqs-04.txt X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 03:06:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Drone Remote ID Protocol WG of the IETF. Title : Drone Remote Identification Protocol (DRIP) Requirements Authors : Stuart W. Card Adam Wiethuechter Robert Moskowitz Andrei Gurtov Filename : draft-ietf-drip-reqs-04.txt Pages : 30 Date : 2020-08-25 Abstract: This document defines the requirements for Drone Remote Identification Protocol (DRIP) Working Group protocols to support Unmanned Aircraft System Remote Identification and tracking (UAS RID) for security, safety and other purposes. Complementing external technical standards as regulator-accepted means of compliance with UAS RID regulations, DRIP will: facilitate use of existing Internet resources to support UAS RID and to enable enhanced related services; enable online and offline verification that UAS RID information is trustworthy. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-drip-reqs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-drip-reqs-04 https://datatracker.ietf.org/doc/html/draft-ietf-drip-reqs-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-drip-reqs-04 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 25 20:16:02 2020 Return-Path: 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 CEC523A0C16 for ; Tue, 25 Aug 2020 20:16:00 -0700 (PDT) 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=axenterprize.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 Pm7DHdxfsF9M for ; Tue, 25 Aug 2020 20:15:59 -0700 (PDT) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3DF73A0C15 for ; Tue, 25 Aug 2020 20:15:58 -0700 (PDT) Received: by mail-ej1-x635.google.com with SMTP id oz20so850275ejb.5 for ; Tue, 25 Aug 2020 20:15:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axenterprize.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=FlvYqanIk/Nao0095BhRYPFzNwIZsNnblQqnuXKWOTM=; b=eyEGMvkdpnGrJHBFlasT/H+/tK1ov0fo6IDoopdyJjFO8VlxlxnR8FfVDPIqBS1MCf wqt8gueYUAx3uwPK1iTNPtrwyfUyRwbycScYnkkEG/sPRtYWIg6okp8F1ZRBH3KHUUYS UKjlbGP44F5/2iVtNkA+nPoYJv/3YQdtpqtos= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=FlvYqanIk/Nao0095BhRYPFzNwIZsNnblQqnuXKWOTM=; b=We6yQCR7sN4gbvfdrGck+IF1LTnT7y/e2mEBTqp7KTFvmvsJoruszCzF+zt2ubXCdm TJ2wdbeEWozZwoceYhhCVJqiCNfgPtEgvIUJ/2I20nwmKfrNf3tqInydgWTwO0u2z+YA f+XjoCPAy3LqNeSayxYQZ8SwpKx/VGQm6XyREtKZ4KddB8DMx0092vK7SQpZSfwzPUWz eLtLLsjPeW48xPWKZUCGlLHE7eyOnvcJlO+8BJlZ0d/MOz1VTLS5Ym6My4ZtnbeQ6/aN iD0QQJ4RRU39POxA6eywc2NR060eAl3F0IRXcUih9YNCBModJP/CguvmBE0eAU5tWRqN PAGQ== X-Gm-Message-State: AOAM53279hE18PVXjojm6vgYMurZEusOadWVW5ebKrzaMkSUwHv9NyLM 1h3fhuOjkRiXnFW6mdy7ZZNHoKVRZrnBrcXVCb6r3TjfaVDzjMpq X-Google-Smtp-Source: ABdhPJw5bgvrt9RZtCnpZRnYPD9IzSrN7LHWJWl8eooXyg0d+jFteIvlKCdVepe6T7nCkIXSSym32tGXBAZxwOQMlOA= X-Received: by 2002:a17:906:6c8b:: with SMTP id s11mr13219074ejr.310.1598411756864; Tue, 25 Aug 2020 20:15:56 -0700 (PDT) MIME-Version: 1.0 References: <159841117784.23859.1959555160770691180@ietfa.amsl.com> In-Reply-To: <159841117784.23859.1959555160770691180@ietfa.amsl.com> From: "Card, Stu" Date: Tue, 25 Aug 2020 23:15:44 -0400 Message-ID: To: tm-rid@ietf.org Content-Type: multipart/alternative; boundary="000000000000f920f305adbf3c67" Archived-At: Subject: Re: [Drip] I-D Action: draft-ietf-drip-reqs-04.txt X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 03:16:01 -0000 --000000000000f920f305adbf3c67 Content-Type: text/plain; charset="UTF-8" My apologies to everyone for the 11th hour (literally) submission and to Daniel for my failure to understand thus address as yet several of the points in his extensive review. what I did & didn't do: (0) did attempt to address every point raised by reviewers (to the extent I thought I understood them); (1) didn't take suggestions apparently due to reviewer lacking UAS context, instead added missing context; (2) didn't take suggestions apparently lacking consensus (but will if raised again & WG expresses consensus); (3) didn't remove definitions of terms likely to be used in other DRIP documents (but will if the WG prefers); (4) didn't substantially restructure the document (but will if the WG prefers); (5) didn't do all the minor corrections & final proofreading (yet). review question from Michael R.: Should GEN-1 be exploded into multiple numbered requirements? (a) message integrity / non-repudiation (b) defense against replay attacks (c) defense against spoofing (d) connected to a sender public key (related to GEN-3) (e) Observer w/o Internet at time of observation My slides will be limited to the points above and the actual numbered requirements text, focusing on the previously debated PRIV-2 and PRIV-3 plus the newly added (based on reviewers' comments) PRIV-4 and PRIV-5. Thanks. Good night! On Tue, Aug 25, 2020 at 11:06 PM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Drone Remote ID Protocol WG of the IETF. > > Title : Drone Remote Identification Protocol (DRIP) > Requirements > Authors : Stuart W. Card > Adam Wiethuechter > Robert Moskowitz > Andrei Gurtov > Filename : draft-ietf-drip-reqs-04.txt > Pages : 30 > Date : 2020-08-25 > > Abstract: > This document defines the requirements for Drone Remote > Identification Protocol (DRIP) Working Group protocols to support > Unmanned Aircraft System Remote Identification and tracking (UAS RID) > for security, safety and other purposes. Complementing external > technical standards as regulator-accepted means of compliance with > UAS RID regulations, DRIP will: > > facilitate use of existing Internet resources to support UAS RID > and to enable enhanced related services; > > enable online and offline verification that UAS RID information is > trustworthy. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-drip-reqs/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-drip-reqs-04 > https://datatracker.ietf.org/doc/html/draft-ietf-drip-reqs-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-drip-reqs-04 > > > 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. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > -- > Tm-rid mailing list > Tm-rid@ietf.org > https://www.ietf.org/mailman/listinfo/tm-rid > --000000000000f920f305adbf3c67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My apologies to everyone for the 11th hour (literally) sub= mission and to Daniel for my failure to understand thus address=C2=A0as=C2= =A0yet several of the points in his extensive review.

wh= at I did & didn't do:
(0) did attempt to address every point rai= sed by reviewers (to the extent I thought I understood them);
(1) didn&#= 39;t take suggestions apparently due to reviewer lacking UAS context, inste= ad added missing context;
(2) didn't take suggestions apparently lac= king consensus (but will if raised again & WG expresses consensus);
= (3) didn't remove definitions of terms likely to be used in other DRIP = documents (but will if the WG prefers);
(4) didn't substantially res= tructure the document (but will if the WG prefers);
(5) didn't do al= l the minor corrections & final proofreading (yet).

review quest= ion from Michael R.: Should GEN-1 be exploded into multiple numbered requir= ements?
(a) message integrity / non-repudiation
(b) defense against r= eplay attacks
(c) defense against spoofing
(d) connected to a sender = public key (related to GEN-3)
(e) Observer w/o Internet at time of obser= vation

My slides will be limited to the points= above and the actual numbered requirements text, focusing on the previousl= y debated PRIV-2 and PRIV-3 plus the newly added (based on reviewers' c= omments) PRIV-4 and PRIV-5.

Thanks. Good night!


On Tue, Aug 25, 2020 at 11:06 PM <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Drone Remote ID Protocol WG of the IETF.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Drone Remote Identification Protocol (DRIP) Requirements
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Stua= rt W. Card
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Adam Wiethuechter
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Robert Moskowitz
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Andrei Gurtov
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-drip-reqs-04.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 30
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2020-08-25

Abstract:
=C2=A0 =C2=A0This document defines the requirements for Drone Remote
=C2=A0 =C2=A0Identification Protocol (DRIP) Working Group protocols to supp= ort
=C2=A0 =C2=A0Unmanned Aircraft System Remote Identification and tracking (U= AS RID)
=C2=A0 =C2=A0for security, safety and other purposes.=C2=A0 Complementing e= xternal
=C2=A0 =C2=A0technical standards as regulator-accepted means of compliance = with
=C2=A0 =C2=A0UAS RID regulations, DRIP will:

=C2=A0 =C2=A0 =C2=A0 facilitate use of existing Internet resources to suppo= rt UAS RID
=C2=A0 =C2=A0 =C2=A0 and to enable enhanced related services;

=C2=A0 =C2=A0 =C2=A0 enable online and offline verification that UAS RID in= formation is
=C2=A0 =C2=A0 =C2=A0 trustworthy.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dr= ip-reqs/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-drip-reqs-= 04
https://datatracker.ietf.org/doc/html/d= raft-ietf-drip-reqs-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft= -ietf-drip-reqs-04


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


--
Tm-rid mailing list
Tm-rid@ietf.org https://www.ietf.org/mailman/listinfo/tm-rid
--000000000000f920f305adbf3c67-- From nobody Wed Aug 26 04:55:44 2020 Return-Path: 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 C70F43A119B for ; Wed, 26 Aug 2020 04:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.846 X-Spam-Level: X-Spam-Status: No, score=-2.846 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.948, 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 jO-3kb2nkQwe for ; Wed, 26 Aug 2020 04:55:39 -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 A656D3A1199 for ; Wed, 26 Aug 2020 04:55:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id F078162651; Wed, 26 Aug 2020 07:55:37 -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 YH+JT6lkslWf; Wed, 26 Aug 2020 07:55:30 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (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 886EE62620; Wed, 26 Aug 2020 07:55:28 -0400 (EDT) To: "Card, Stu" , tm-rid@ietf.org References: <159841117784.23859.1959555160770691180@ietfa.amsl.com> From: Robert Moskowitz Message-ID: <41b642d9-3b92-c5db-d093-6a083e021d5d@labs.htt-consult.com> Date: Wed, 26 Aug 2020 07:55:27 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C5A68283BF36DC2D44132609" Content-Language: en-US Archived-At: Subject: Re: [Drip] I-D Action: draft-ietf-drip-reqs-04.txt X-BeenThere: tm-rid@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Drone Remote Identification Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 11:55:43 -0000 This is a multi-part message in MIME format. --------------C5A68283BF36DC2D44132609 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 8/25/20 11:15 PM, Card, Stu wrote: > My apologies to everyone for the 11th hour (literally) submission and > to Daniel for my failure to understand thus address as yet several of > the points in his extensive review. > > what I did & didn't do: > (0) did attempt to address every point raised by reviewers (to the > extent I thought I understood them); > (1) didn't take suggestions apparently due to reviewer lacking UAS > context, instead added missing context; Normal.  If the reviewer suggests something that indicates that enough context is not provided, provide the context.  Or references to context. > (2) didn't take suggestions apparently lacking consensus (but will if > raised again & WG expresses consensus); > (3) didn't remove definitions of terms likely to be used in other DRIP > documents (but will if the WG prefers); Agree.  I actually was ready to change the definitions in uas-rid and operator-privacy and wow, no aviation definitions.  And I thought about it and agree that ALL aviation definitions SHOULD be in reqs and/or arch.  Of course if new ones come up after those are published, new drafts will have to deal with it. > (4) didn't substantially restructure the document (but will if the WG > prefers); > (5) didn't do all the minor corrections & final proofreading (yet). > > review question from Michael R.: Should GEN-1 be exploded into > multiple numbered requirements? > (a) message integrity / non-repudiation Sounds nice but the PHYs selected, for the most part do not allow for this, and we cannot say, "tough, you have to only use PHYs that can support this, or operate in such a way this works." So no. But Adam's auth DOES provide for this.  So maybe to have it and then show what little can support it. > (b) defense against replay attacks Only Adam's auth provides this and we did consider it in the design... > (c) defense against spoofing Same. > (d) connected to a sender public key (related to GEN-3) This is nice, but it SHOULD be a solution for other requirements. IMHO, we do not req public key.  We show how reqs are met with public key tech. So, no. > (e) Observer w/o Internet at time of observation This may be worthwhile.  It is in the FAA ConOps.  I think.  And we do design for it. > My slides will be limited to the points above and the actual numbered > requirements text, focusing on the previously debated PRIV-2 and > PRIV-3 plus the newly added (based on reviewers' comments) PRIV-4 and > PRIV-5. Looks like my operator-privacy again is not getting on the agenda for PRIV-2.  :) I will look at 4 & 5, then comment. > Thanks. Good night! > > > On Tue, Aug 25, 2020 at 11:06 PM > wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Drone Remote ID Protocol WG of > the IETF. > >         Title           : Drone Remote Identification Protocol > (DRIP) Requirements >         Authors         : Stuart W. Card >                           Adam Wiethuechter >                           Robert Moskowitz >                           Andrei Gurtov >         Filename        : draft-ietf-drip-reqs-04.txt >         Pages           : 30 >         Date            : 2020-08-25 > > Abstract: >    This document defines the requirements for Drone Remote >    Identification Protocol (DRIP) Working Group protocols to support >    Unmanned Aircraft System Remote Identification and tracking > (UAS RID) >    for security, safety and other purposes.  Complementing external >    technical standards as regulator-accepted means of compliance with >    UAS RID regulations, DRIP will: > >       facilitate use of existing Internet resources to support UAS RID >       and to enable enhanced related services; > >       enable online and offline verification that UAS RID > information is >       trustworthy. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-drip-reqs/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-drip-reqs-04 > https://datatracker.ietf.org/doc/html/draft-ietf-drip-reqs-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-drip-reqs-04 > > > 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 . > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > -- > Tm-rid mailing list > Tm-rid@ietf.org > https://www.ietf.org/mailman/listinfo/tm-rid > > -- 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 --------------C5A68283BF36DC2D44132609 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 8/25/20 11:15 PM, Card, Stu wrote:
My apologies to everyone for the 11th hour (literally) submission and to Daniel for my failure to understand thus address as yet several of the points in his extensive review.

what I did & didn't do:
(0) did attempt to address every point raised by reviewers (to the extent I thought I understood them);
(1) didn't take suggestions apparently due to reviewer lacking UAS context, instead added missing context;

Normal.  If the reviewer suggests something that indicates that enough context is not provided, provide the context.  Or references to context.

(2) didn't take suggestions apparently lacking consensus (but will if raised again & WG expresses consensus);
(3) didn't remove definitions of terms likely to be used in other DRIP documents (but will if the WG prefers);

Agree.  I actually was ready to change the definitions in uas-rid and operator-privacy and wow, no aviation definitions.  And I thought about it and agree that ALL aviation definitions SHOULD be in reqs and/or arch.  Of course if new ones come up after those are published, new drafts will have to deal with it.

(4) didn't substantially restructure the document (but will if the WG prefers);
(5) didn't do all the minor corrections & final proofreading (yet).

review question from Michael R.: Should GEN-1 be exploded into multiple numbered requirements?
(a) message integrity / non-repudiation

Sounds nice but the PHYs selected, for the most part do not allow for this, and we cannot say, "tough, you have to only use PHYs that can support this, or operate in such a way this works."

So no.

But Adam's auth DOES provide for this.  So maybe to have it and then show what little can support it.
(b) defense against replay attacks

Only Adam's auth provides this and we did consider it in the design...

(c) defense against spoofing

Same.

(d) connected to a sender public key (related to GEN-3)

This is nice, but it SHOULD be a solution for other requirements.  IMHO, we do not req public key.  We show how reqs are met with public key tech.

So, no.

(e) Observer w/o Internet at time of observation

This may be worthwhile.  It is in the FAA ConOps.  I think.  And we do design for it.

My slides will be limited to the points above and the actual numbered requirements text, focusing on the previously debated PRIV-2 and PRIV-3 plus the newly added (based on reviewers' comments) PRIV-4 and PRIV-5.

Looks like my operator-privacy again is not getting on the agenda for PRIV-2.  :)

I will look at 4 & 5, then comment.

Thanks. Good night!


On Tue, Aug 25, 2020 at 11:06 PM <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Drone Remote ID Protocol WG of the IETF.

        Title           : Drone Remote Identification Protocol (DRIP) Requirements
        Authors         : Stuart W. Card
                          Adam Wiethuechter
                          Robert Moskowitz
                          Andrei Gurtov
        Filename        : draft-ietf-drip-reqs-04.txt
        Pages           : 30
        Date            : 2020-08-25

Abstract:
   This document defines the requirements for Drone Remote
   Identification Protocol (DRIP) Working Group protocols to support
   Unmanned Aircraft System Remote Identification and tracking (UAS RID)
   for security, safety and other purposes.  Complementing external
   technical standards as regulator-accepted means of compliance with
   UAS RID regulations, DRIP will:

      facilitate use of existing Internet resources to support UAS RID
      and to enable enhanced related services;

      enable online and offline verification that UAS RID information is
      trustworthy.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-drip-reqs/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-drip-reqs-04
https://datatracker.ietf.org/doc/html/draft-ietf-drip-reqs-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-drip-reqs-04


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


--
Tm-rid mailing list
Tm-rid@ietf.org
https://www.ietf.org/mailman/listinfo/tm-rid


--
Standard Robert Moskowitz
Owner
HTT Consulting
C:      248-219-2059
F:      248-968-2824
E: