Re: [Drip] ADSB

On 8/5/20 10:23 AM, Alexandre Petrescu wrote:
>
>
> Le 05/08/2020 à 15:50, Card, Stu a écrit :
>> Again, a single point response. The reason this work is appropriate 
>> for IETF rather than the Bluetooth SIG is that ASTM F3411 specifies 
>> Bluetooth _only_ as one transport for Broadcast RID (WiFi NaN is also 
>> specified and other alternatives could be added later, as you, Bob 
>> and others are discussing, also consider RTCA SC-228 DO-362 UAS C2 
>> Data Link at ~1 and ~5 GHz), but there is also Network RID where ASTM 
>> F3411 specifies use of the Internet, and a lot more to the overall 
>> UAS RID architecture/problem than just the initial streaming of 
>> messages from the UAS.
>>
>> Please look at the openly published early draft of ASTM F3411 to 
>> which Bob pointed you,
>
> I looked and I will keep it aside for reference when needed.
>
> It's an Intel document.
>
> https://github.com/opendroneid/specs/blob/master/OpenDroneID_Bluetooth_0.64.3.pdf 
>

yes, Intel got ASTM's approval to do the OpenDrone ID work for PoC. So 
there is code there for implementing this on github.  Adam used that as 
his starting point.

>
> Alex
>
>  and perhaps some of the other external docs cited in
>> the DRIP requirements draft, for essential context on the UAS RID 
>> problem and what others have already done to address it, which we 
>> hope to complement (not replace) with DRIP. Thanks!
>>
>>
>> On Wed, Aug 5, 2020 at 8:50 AM Alexandre Petrescu 
>> <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>> 
>> 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).
>>
>>      > 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 <tm-rid-bounces@ietf.org
>>     <mailto:tm-rid-bounces@ietf.org>> on behalf of
>>      >>>>>>> "Stuart W. Card" <stu.card@axenterprize.com
>>     <mailto:stu.card@axenterprize.com>> *Date:
>>      >>>>>>> *Wednesday, July 29, 2020 at 19:46 *To:
>>      >>>>>>> *"tm-rid@ietf.org <mailto:tm-rid@ietf.org>"
>>     <tm-rid@ietf.org <mailto:tm-rid@ietf.org>> *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:rgm@labs.htt-consult.com
>>     <mailto:E%3Argm@labs.htt-consult.com>
>>      >>>
>>      >>> 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:rgm@labs.htt-consult.com
>>     <mailto:E%3Argm@labs.htt-consult.com>
>>      >
>>      > There's no limit to what can be accomplished if it doesn't matter
>>      > who gets the credit
>>
>>     --     Tm-rid mailing list
>>     Tm-rid@ietf.org <mailto:Tm-rid@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/tm-rid
>>
>

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:rgm@labs.htt-consult.com

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit