Re: [Drip] ADSB

["Card, Stu" <[e-mail]>]

Yes, the openly published early draft of ASTM F3411 was developed largely
by Gabriel Cox of Intel and his group there. While we all are generally
suspicious of the motivations of large companies, I have spoken often with
Gabriel: his heart is pure; he says Intel hopes to increase sales by simply
helping mature a standard that enables a market to grow. Development and
publication of the standard within ASTM then attracted many other large and
small players, so Intel could not force anything upon the world that
benefited primarily Intel. While I do not agree with all the decisions made
(and neither does Gabriel), they are the decisions that SDO working group
made, in response to the concerns of many different stakeholders
(especially regulators, manufacturers and would-be UTM network service
providers). Alas, ASTM supports themselves by sales of standards documents,
so F3411-19 is not openly published. OTOH $85 is small compared to the
value of most contributor's time working on the problem, and better still
one can join ASTM as an individual for only $75 and get this standard as
part of the one free "volume" of standards that a member may select (from a
large library) upon joining. As a fallback, we point people to the openly
published early draft, which provides pretty good context; perhaps I should
add it to the reference list in the requirements draft? Thanks again for
your interest and help with this!


On Wed, Aug 5, 2020 at 10:23 AM Alexandre Petrescu <
[e-mail]> 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
>
> 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
> > <[e-mail] <mailto:[e-mail]>>
> 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 <[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
> >      >
> >      > -- 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
> >
>