Re: [Drip] ADSB

[Robert Moskowitz <[e-mail]>]

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

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