Re: [Drip] ADSB

[Alexandre Petrescu <[e-mail]>]

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 <[e-mail]> on behalf of 
>>>>>>> "Stuart W. Card" <[e-mail]> *Date: 
>>>>>>> *Wednesday, July 29, 2020 at 19:46 *To: 
>>>>>>> *"[e-mail]" <[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
>>>>>>> 
>>>>>>> 4947 Commercial Drive, Yorkville NY 13495
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>>> -- Standard Robert Moskowitz Owner HTT Consulting C:248-219-2059 
>>> F:248-968-2824 E:[e-mail]
>>> 
>>> 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:[e-mail]
> 
> There's no limit to what can be accomplished if it doesn't matter
> who gets the credit