Re: [Drip] ADSB

[Robert Moskowitz <[e-mail]>]

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