Re: [Drip] ADSB

[Alexandre Petrescu <[e-mail]>]

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 
> <[e-mail] <mailto:[e-mail]>>
> 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 <[e-mail]
> <mailto:[e-mail]>> on behalf of
>>>>>> "Stuart W. Card" <[e-mail]
> <mailto:[e-mail]>> *Date:
>>>>>> *Wednesday, July 29, 2020 at 19:46 *To: *"[e-mail]
> <mailto:[e-mail]>"
>>>>>> <[e-mail] <mailto:[e-mail]>> *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:[e-mail]
> <mailto:[e-mail]>
>> 
>> There's no limit to what can be accomplished if it doesn't matter 
>> who gets the credit
> 
> -- Tm-rid mailing list [e-mail] <mailto:[e-mail]> 
> https://www.ietf.org/mailman/listinfo/tm-rid
>