Re: [Drip] ADSB

[Alexandre Petrescu <[e-mail]>]

Le 05/08/2020 à 16:34, Card, Stu a écrit :
> 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 

Yes 85USD is small compared to other things.

At IETF there was an innovation last meeting, in that non-paying the 
attending money was somehow an option.  Its results are still to be 
understood but the option was there.  I hope others could replicate.

There are many things.

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

Yes yes, please add the openly available document to the reference list 
in the appropriate draft.

Alex

  Thanks again for your
> interest and help with this!
> 
> 
> On Wed, Aug 5, 2020 at 10:23 AM Alexandre Petrescu 
> <[e-mail] <mailto:[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]>
>     <mailto:[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]>
>      >     <mailto:[e-mail]
>     <mailto:[e-mail]>>> on behalf of
>      >      >>>>>>> "Stuart W. Card" <[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail]
>     <mailto:[e-mail]>>> *Date:
>      >      >>>>>>> *Wednesday, July 29, 2020 at 19:46 *To:
>      >      >>>>>>> *"[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>"
>      >     <[e-mail] <mailto:[e-mail]>
>     <mailto:[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>
>      >     <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]>
>      >     <mailto:[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]>
>      >     <mailto:[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]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      > https://www.ietf.org/mailman/listinfo/tm-rid
>      >
>