Re: [Tm-rid] Review of draft-drip-arch-02 w.r.t. RFC6973, RFC8280 and other

Robert Moskowitz <rgm@labs.htt-consult.com> Thu, 09 July 2020 11:45 UTC

Return-Path: <rgm@labs.htt-consult.com>
X-Original-To: tm-rid@ietfa.amsl.com
Delivered-To: tm-rid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB723A084A for <tm-rid@ietfa.amsl.com>; Thu, 9 Jul 2020 04:45:22 -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, RCVD_IN_DNSWL_BLOCKED=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 RpboZjawxKGp for <tm-rid@ietfa.amsl.com>; Thu, 9 Jul 2020 04:45:19 -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 168E33A084C for <tm-rid@ietf.org>; Thu, 9 Jul 2020 04:45:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 5C9AC62221; Thu, 9 Jul 2020 07:45:17 -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 jWDVmy9bl4GC; Thu, 9 Jul 2020 07:45: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 56FA3621B8; Thu, 9 Jul 2020 07:45:10 -0400 (EDT)
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
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> <b88975b0-ecfd-3091-4314-304c36d51e8f@gmail.com> <3c632ce9-115d-11f5-ee33-bfabd4973522@labs.htt-consult.com> <f5dc0567-c9a1-a26f-b240-aead0d85c11f@gmail.com> <c9cc2ff4-c24f-f575-150b-8b978a4c2ac5@labs.htt-consult.com> <7ddd9a2f-23ba-dd82-8cfb-1d2974969e67@gmail.com> <d8cf3a43-910a-db2f-4408-184b52446c97@labs.htt-consult.com> <a288966d-d22a-d0fa-c544-ae2db7d1533e@gmail.com>
From: Robert Moskowitz <rgm@labs.htt-consult.com>
Message-ID: <74297fa5-990c-b832-b9cb-277adc329301@labs.htt-consult.com>
Date: Thu, 09 Jul 2020 07:45:02 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <a288966d-d22a-d0fa-c544-ae2db7d1533e@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tm-rid/cf84zv4_4KZ7G8o65dLkf-k67sU>
Subject: Re: [Tm-rid] Review of draft-drip-arch-02 w.r.t. RFC6973, RFC8280 and other
X-BeenThere: tm-rid@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Trustworthy Multipurpose RemoteID <tm-rid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tm-rid>, <mailto:tm-rid-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tm-rid/>
List-Post: <mailto:tm-rid@ietf.org>
List-Help: <mailto:tm-rid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tm-rid>, <mailto:tm-rid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jul 2020 11:45:22 -0000


On 7/9/20 3:02 AM, Alexandre Petrescu wrote:
> Hi, Bob,
>
> Le 08/07/2020 à 17:39, Robert Moskowitz a écrit :
> [...]
>> So you either have LTE/5G, perhaps a private addressing/slice.
>
> Interesting.
>
> Loon did put, apparently, 4G base stations in high altitude balloons, in
> South America.  These could be used to talk to flying devices including
> UAM vehicles and such multicopters.
>
> ESA (European Space Agency) does pursue actively 5G plans.
>
> However, there could be doubts about the whole concept of using 5G in a
> UAM vehicle (flying taxi) for simple reaons such as antenna placement,
> orientation and coverage.
>
>> Or something down-frequency like 500 - 900 MHz like IEEE 802.16
>> (note the work being done on the PHYs there in TG 802.15.16t).
>
> Interesting.
>
> An 802.15.* PAN (Personal) proposed at UHF and VHF hundred km ranges
> sounds so.

This was a bit of 802 exec committee procedure...

802.16 is in hibernation.  802ec did not want to reactivate it with all 
the admin costs for this PAR, so they stuffed it on the 802.15 workgroup 
to run it.  It is still an addendum to 802.16, just being done under 
802.15 administration.

:)

>
> In such a frequency range, one could also think about DVB-T
> modifications (Digital Video Broadcast - Terrestrial).  The
> flightradar24.com tracks regular airline flights also by proposing a
> DVB-T USB key that enthusiasts could help with.
>
> These dongles receive presence data from these planes.
> https://www.flightradar24.com/build-your-own
>
> 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.

Over in EU, ask AirBus.  Or our IETF Boeing colleagues.  Thing is there 
are LOTs of different datastreams from aircraft.  One of the goals in 
the move to IPv6 is to comminize the communications and simplify the 
ground (and plane) costs.

>
> Maybe this 802.15.16t Licensed narrowband for mission critical entities
> would compete with that ADS-B concept.
>
> At that point, one could think about using IP-over-ADS, or
> IP-over-802-15-16t, and so there could be a resolution.


There are a number of recognized problems with ADS-B.  I am not 
connected at all to see how thes may be addressed.  I don't even have a 
clear list, I only hear complaints.  Definitely the lack of security is 
critical.  Maybe they need MLS?

>
>> So I see more of a money fight between the 3GPP cellular companies 
>> and the private spectrum companies.
>>
>> The private spectrum companies have a very strong case for managing 
>> who uses their spectrum and maintaining the 'mission critical' 
>> communication.  Do check out:
>>
>> http://www.ieee802.org/15/pub/TG16t.html
>>
>> Some of these frequencies have very good characteristics for this 
>> application.
>>
>> For UAM, it SHOULD be an IP link, but if they go Sat, all bets are 
>> off, depending on the Sat company.
>
> Sattelite communications for UAM vehicles such as flying taxis could
> indeed be useful, even though it might increase their cost.
>
> But, if it is an IP link, I suspect I must look closer at the DRIP
> message formats and see whether they could be transmitted on these IP 
> links.

DRIP message formats, as such are based on ASTM F3411-19 which is 
designed to work over BT4 beacons (27 bytes).  The Auth message is 10 of 
these, or 256 bytes of payload.

Most C2 messaging is also small data payloads.


>
> Finally, as you might notice, I might have an interest for UAM
> vehicles such as manned-but-not-in-control air taxis (VoloCopter, Geely,
> Lilium, Kitty Hawk, Ehang, Link&Fly, Kitty Hawk Cora, Cezeri, Hyundai
> Uber flying taxi at CES 2020), and for broadcasting over IP their
> presence information.  This is a little bit different than DNS and
> presence advertisement over the Internet, even though it is on IP.  I
> will have to read the drafts of DRIP.

F3411-19 has the Location/Vector message.  It has a couple flaws that 
will be addressed in the next? release.  One is they left out altitude.  
FAA wants this in barometric to match manned aircraft, not GPS 
altitude.  This could cause problems dodging buildings (though probably 
internally the UA would have both).  I remember reading of an incident 
during WWII in the DC3 supply flights to China over the Himalayas.  One 
DC3 crew that crashed because barometric altitude does not match 
mountain elevation (hidden in the clouds), managed to remove their cargo 
door and tobogganed down the mountain on it...

My drip-operator-privacy draft addresses the privacy concerns with these 
messages.

Any UA could be sending these messages via broadcast.  The carrier RF 
options currently are:  BT4&5 and 802.11NAN.  I see the 802.11bc as 
another, future, option.  Thus any ground system can receive them and 
'know' what is overhead.  See my crowd-sourced draft.

Bob