Re: [Drip] how you can help (was: ADSB)

[Robert Moskowitz <[e-mail]>]

But I should point out that there is constant talk coming from DAA that 
perhaps security is not needed, as there are other "proofs" like visual 
and radar.

It never ends.

On 7/12/23 14:34, Stu Card wrote:
> I agree w/Bob that PQC requires blobs (keys, certs, sigs) too big for 
> F3411 link layer frames (which, rather than the bit rate, constrain DRIP).
>
> However, I agree w/Alexey that we can't ignore the threat of quantum 
> cryptanalysis.
>
> I believe PQC can play a role in DRIP. Not all keys, certs or sigs 
> need be sent frequently (if at all) over our constrained Broadcast RID 
> links. Hybrid architectures can use compact crypto over wireless links 
> during flight operations and PQC for long lived keys used only in 
> wireline transactions before or after flight ops.
>
> So please, while we can't use PQC everywhere in DRIP, do look for 
> places where it might be both feasible and beneficial.
>
>
> Get Outlook for Android <https://aka.ms/AAb9ysg>
> ------------------------------------------------------------------------
> *From:* Alexandre Petrescu <[e-mail]>
> *Sent:* Wednesday, July 12, 2023 2:13:10 PM
> *To:* Robert Moskowitz <[e-mail]>; Stu Card 
> <[e-mail]>
> *Cc:* [e-mail] <[e-mail]>
> *Subject:* Re: [Drip] how you can help (was: ADSB)
>
>
> Le 12/07/2023 à 19:52, Robert Moskowitz a écrit :
> >
> >
> > On 7/12/23 13:15, Alexandre Petrescu wrote:
> >> Stu,
> >> I agree with focusing on the work of the WG.
> >>
> >> I will look at the two documents you proposed later.
> >> draft-ietf-drip-auth and "*DRIP Entity Tag (DET) Identity Management
> >> Architecture *draft".
> >>
> >> When I look at them I will look from a few perspectives:
> >>
> >> - do the proposed auth mechanism also use new 'post-quantum' (i.e.
> >> quantum-resistant algos) and if yes how.
> >
> > No.  Read rfc9374 Security Considerations on this.
> >
> > Basically no bandwidth for those monsters.
>
> True, you told me so earlier, I remmeber.  But recently someone
> published some measures over in PQUIP, and in the text they do mention a
> parameter of bandwidth like 10mbit/s.  I do not know what the results
> are, but 10mbit/s is, I think, what a version of bluetooth can do, and I
> think (I might be wrong) DRIP uses exclusively bluetooth.
>
> If still the bandwidth criterion holds, despite what that pdf says, then
> it's fine.
>
> https://wggrs.nl/post/tls-measurements/handout-tls.pdf
>
> Alex
>
> >
> >
> >> - is the identification mechanism compatible more universally on a
> >> vertical ladder to cover not only FNAC drones (drones one can buy from
> >> FNAC for large public and have bluetooth and wifi) but more towards
> >> high, like higher altitude platforms, and also more towards below, like
> >> in tunnels or under water.  If conversions are needed then I will
> >> recommend against conversions because conversions are difficult, 
> despite
> >> you seeming to assume all people think they are easy.  I do not
> >> disagree with you assuming so, and I do not disagree with all people
> >> thinking that conversions are straightforward.
> >
> > That is the plan and part of the reason for my activity in ICAO.
> >
> >> - I will try to see where the implementations of these two drafts can
> >> be, open source or not, how can I consult as a lambda user, how can a
> >> programmer feel these drafts.
> >
> > Dr. Gurtov has open code.  Join in.
> >
> >> - I might want to check whether 3GPP, ETSI or ISO refer to these two
> >> documents, or whether these two documents describe mechanisms under a
> >> different name that is described also at other SDO among these 3.
> >
> > Nope.  3GPP is pushing IEEE 1609.2 so that UAS is part of ground
> > vehicles, not NAS.  IMO.
> >
> > Best I can find is ETSI and ISO not doing anything for securing 
> "Direct ID".
> >
> >> - I might want to check what the R&D strategy in Europe and future 
> calls
> >> for R&D projects tell about drone identification technologies.
> >
> > Check with Dr. Gurtov.
> >
> >> - I might want to check - maybe not the last thing - whether 
> suggestions
> >> of breaks in DRIP technologies exist (like 'a break in AI', 'a break
> >> in 6G') whether proposals exist and how to address them. Just to make
> >> sure.
> >
> > Please do.
> >
> >
> >> - I might want to ask chatbots what they think about these two
> >> documents, just to see.
> >
> > Will be interested.
> >
> >> But only later can I do all that.   I suspect that only a few remarks
> >> coming from such an analysis might be interesting to a focused work in
> >> WG on these two documents, so I will have to trim accordingly.
> >>
> >> Until then I can only thank you for the clarifications.
> >>
> >> Alex
> >>
> >>
> >>
> >> Le 12/07/2023 à 18:04, Stu Card a écrit :
> >>> Alexey --
> >>>
> >>> I greatly appreciate your efforts to contribute to DRIP work.
> >>>
> >>> I only ask that you try to stay on topic, within the scope of what
> >>> our WG is chartered to and could feasibly do.
> >>>
> >>> Many things are broken in this world, we cannot fix them all. Just
> >>> within aviation related instrumentation and communication, there are
> >>>  many problems, some of them long-standing, that the DRIP WG cannot
> >>> even address. You have mentioned some of them, like what is really
> >>> meant by AGL, for which there are competing definitions, which one
> >>> hardworking smart knowledgeable friend of ours has dedicated much
> >>> effort to trying to reconcile. But those are mostly _aviation_
> >>> issues, not UAS RID specific, much less in DRIP scope.
> >>>
> >>> We need to refer, in DRIP,  to much external context. We must not be
> >>>  distracted by constantly caveating those references with our own
> >>> opinions about them, changing their terminology to something we like
> >>>  better, translating their units (when readers can easily do their
> >>> own unit conversions if needed), etc.
> >>>
> >>> We must focus our efforts on what we uniquely can contribute to
> >>> making UAS RID more useful: _trustworthy_ & _immediately actionable_
> >>> to benefit safety & security of participating & nonparticipating
> >>> people, property, and the environment.
> >>>
> >>> To contribute to this important work, keeping the above in mind,
> >>> please review our *DRIP Entity Tag Authentication Formats & Protocols
> >>> for Broadcast Remote ID *draft at
> >>> https://datatracker.ietf.org/doc/draft-ietf-drip-auth/
> >>> <https://datatracker.ietf.org/doc/draft-ietf-drip-auth/>
> >>>
> >>> Then please review the *DRIP Entity Tag (DET) Identity Management
> >>> Architecture *draft. If you really want to dig in, volunteer to
> >>> co-author some of the registry related drafts.
> >>>
> >>> Thanks!
> >>>
> >>> -- Stu
> >>>
> >>> Get Outlook for Android <https://aka.ms/AAb9ysg>
> >>> 
> ------------------------------------------------------------------------
> >>>
> >>>
> >> *From:* Alexandre Petrescu <[e-mail]>
> >>> *Sent:* Wednesday, July 12, 2023 11:13:50 AM *To:* Stu Card
> >>> <[e-mail]> *Cc:* [e-mail] <[e-mail]>
> >>> *Subject:* Re: [Drip] ADSB thanks for the clarification I must have
> >>> endeavoured in unchartered lands...
> >>>
> >>> Just to clarify: I am not disputing.
> >>>
> >>> I came with this thread to say that I saw ADS-B drones on
> >>> flightradar.
> >>>
> >>> That's about it.
> >>>
> >>> Alex
> >>>
> >>> Le 12/07/2023 à 16:56, Stu Card a écrit :
> >>>> The UAS RID rules are _not_ defined in this WG!
> >>>>
> >>>> They are defined by Civil Aviation Authorities (CAAs) in each
> >>>> jurisdiction, with coordination via the International Civil
> >>>> Aviation Organization (ICAO).
> >>>>
> >>>> Disputing the rules should be taken up with them, not with the DRIP
> >>>> WG or any part of IETF.
> >>>>
> >>>> Such rules are mentioned in DRIP docs only as background:
> >>>> motivation, context & constraints.
> >>>>
> >>>> Standard Means of Compliance with UAS RID rules, in turn, is mostly
> >>>> the province of SDOs other than IETF, primarily ASTM International.
> >>>> Again, disputing those standards should be taken up with those
> >>>> SDOs, not us.
> >>>>
> >>>> Only if some reference, in DRIP docs, to the rules or external
> >>>> standards, is factually incorrect or unclear in expression for
> >>>> understanding by DRIP protocol implementors, is it something we
> >>>> should be debating here.
> >>>>
> >>>>
> >>>> Get Outlook for Android <https://aka.ms/AAb9ysg
> >>>> <https://aka.ms/AAb9ysg>>
> >>>>
> >>>> 
> ------------------------------------------------------------------------
> >>>>
> >>>>
> >> *From:* Alexandre Petrescu <[e-mail]>
> >>>> *Sent:* Wednesday, July 12, 2023, 10:43 *To:* Stu Card
> >>>> <[e-mail]>; Robert Moskowitz
> >>>> <[e-mail]>; Carsten Bormann <[e-mail]> *Cc:*
> >>>> [e-mail] <[e-mail]> *Subject:* Re: [Drip] ADSB
> >>>>
> >>>>
> >>>>
> >>>> Le 12/07/2023 à 16:00, Stu Card a écrit :
> >>>>> Very short answers (all for which I have time):
> >>>>>
> >>>>> The rules for RID are based not primarily on RF considerations,
> >>>>> but on aviation considerations.
> >>>>
> >>>> hmmm... it's a principle that is reasonable and that could be
> >>>> debated.
> >>>>
> >>>> One will excuse me for not knowing precisely what are the RID
> >>>> rules. The RID rules are defined in this WG and I will need to look
> >>>> at them.
> >>>>
> >>>> If I look at them, one day, I will look at them from this
> >>>> perspective:
> >>>>
> >>>> For example, when RID rules say 'altitude' they should say
> >>>> 'altitude expressed in meters and not in feet as is currently the
> >>>> inherited case from WWII development of aviation'.
> >>>>
> >>>> This kind of text could be of enormous help to implementers: they
> >>>> simply would need to call less functions(), because less need of
> >>>> conversions.
> >>>>
> >>>> It is the same when RID rules say 'heading' or 'speed', or when we
> >>>> talk about airport track orientation.  It should be made easy to
> >>>> implementer to compare a heading value in a 'heading' of a UAS to
> >>>> that of a track. One should come up with a single common way of
> >>>> expressing track orientation, compatible to that of RID rules,
> >>>> instead of several and incompatible, as is the case in current air
> >>>> flight industry.  It is because if one does that (interoperable
> >>>> defs of headings) then the programmer has an easier task.
> >>>>
> >>>> Also, about RID rules: they should say that when ASTM wants to
> >>>> send position and heading they should send the NMEA statements,
> >>>> without conversion.
> >>>>
> >>>> Until then, if we can not do that, we can also have a human
> >>>> listening to the radio airport and maneouvering locally or from a
> >>>> distance, using an innombrable number of calculators and
> >>>> conversions, after having learned tomes of manuals about how to fly
> >>>> things.  It is basically easier.
> >>>>
> >>>>>
> >>>>> Crewed aircraft _mostly_ fly above 500 feet, except during
> >>>>> takeoff and landing.
> >>>>
> >>>> I always had problems with this term 'crewed' aircraft.  I noticed
> >>>> it also in the TVR WG, in its reverse form 'uncrewed' aircraft.
> >>>>
> >>>> But in reality there can be uncrewed crewed aircrafts too (Unmanned
> >>>> Air Mobility device, a flying taxi, does carry a couple of persons
> >>>> on board - 'crew?', yet none of them actually drives the UAM - they
> >>>> just signed the insurance agreement).  An uncrewed aircraft is
> >>>> still crewed by the fact that a (group of) persons on the ground is
> >>>> its crew (drone Reaper is such).  There can also be these devices
> >>>> that are not crewed, are not continuously driven from a ground by a
> >>>> crew, yet there are very many eyes of people loooking at where it
> >>>> is going to - they're pre-programmed. These would be the true
> >>>> 'uncrew' aircraft even though there are many crews simply looking
> >>>> at them.  They fly at more altitudes than 500 feet.
> >>>>
> >>>> This is why I am not sure how to use this term 'crewed aircraft'.
> >>>>
> >>>> But I think you meant a 200 passenger aircraft like a regular
> >>>> airline flight from a city to another. Even that can be automated
> >>>> (crewless?) soon.
> >>>>
> >>>>> Small uncrewed aircraft _mostly_ fly at much lower altitudes, as
> >>>>> they are flown largely not to get from one place to another, but
> >>>>> for photographing or otherwise sensing things on the ground (or
> >>>>> for recreation).
> >>>>
> >>>> BEcause of this term 'crew' I can not say whether I agree or not
> >>>> with you.
> >>>>
> >>>> Instinctively, I'd say that there are so many other flying aircraft
> >>>> that it is hard to say so easily at which altitudes are they
> >>>> allowed or not, simply based on that 'crewed' qualifier.
> >>>>
> >>>> I think the point of view of 'crewed' vs 'uncrewed' is limited in
> >>>> itself, leading to potentially missing some aspects.
> >>>>
> >>>>> The FAA has established an upper limit of 400 feet AGL for small
> >>>>> uncrewed aircraft flying under their rule appropriate for most
> >>>>> such, to provide 100 feet of vertical separation from these small
> >>>>> UAS and where the crewed aircraft _mostly_ fly.
> >>>>
> >>>> I will not oppose - maybe it is sufficient for them.
> >>>>
> >>>> If I were to be picky, I'd say that the notion of 'AGL' itself can
> >>>> be subject to debate (there are several sea levels in this world
> >>>> and moreover they change as we speak) and if one asks why then I
> >>>> reply that if one would like to put NMEA statements in ASTM
> >>>> messages for the goal of avoiding conversions then one might be
> >>>> facing such aspects of precisely what is a sea level.
> >>>>
> >>>> But I will not go to the respective SDO, so I leave it there. I
> >>>> agree they set limits where they need them.
> >>>>
> >>>>> WRT units: yes it is a mess; no the EU does not use precisely the
> >>>>>  metric equivalents of feet etc. in their rules; note my original
> >>>>>  message said "EU rules are similar" not "EU rules are the same
> >>>>> except for translation of metric units".
> >>>>
> >>>> I agree, you did not say that.
> >>>>
> >>>>> IETF does not get to write rules for aviation, therefore neither
> >>>>> does IETF get to write rules for aviation communications; we can
> >>>>> only provide technical standards for interoperable network
> >>>>> protocols that _enhance_ those communications.
> >>>>
> >>>> It's a good thing, because enhancing communications is always
> >>>> good.
> >>>>
> >>>> Alex
> >>>>
> >>>>>
> >>>>> -----Original Message----- From: Alexandre Petrescu
> >>>>> <[e-mail]> Sent: Wednesday, July 12, 2023
> >>>>> 9:45 AM To: Robert Moskowitz <[e-mail]>; Carsten
> >>>>> Bormann <[e-mail]> Cc: Stu Card <[e-mail]>;
> >>>>> [e-mail] Subject: Re: [Drip] ADSB
> >>>>>
> >>>>>
> >>>>>
> >>>>> Le 12/07/2023 à 13:56, Robert Moskowitz a écrit :
> >>>>>>
> >>>>>>
> >>>>>> On 7/12/23 06:45, Carsten Bormann wrote:
> >>>>>>> On 2023-07-12, at 11:52, Alexandre Petrescu
> >>>>>>> <[e-mail]> wrote:
> >>>>>>>> why not 400m
> >>>>>>> This is not a domain where we get to invent boundaries.
> >>>>>>>
> >>>>>>> (Also, generally speaking, of course we should have a strong bias
> >>>>>>> to using SI units, but in a domain where regulation is widely
> >>>>>>> based on furlongs per fortnight, we’ll have to
> >>>>>>> adapt.)
> >>>>>>
> >>>>>> And anyway it would be 125M to be a bit more than the Imperial
> >>>>>>  400'.
> >>>>>
> >>>>> True.
> >>>>>
> >>>>> And it obviously begs the question whether in Europe they also
> >>>>> have the same limit of 400' equivalent in meters.  I strongly
> >>>>> doubt that an EU document would talk about a limit of precisely
> >>>>> 121.92 meters just because of being converted to the easy to
> >>>>> grasp 400 feet.
> >>>>>
> >>>>> At that point we talk about devices that might be different in an
> >>>>> EU market than in an US market.
> >>>>>
> >>>>> What is the EU altitude limit for numerous drone aircraft to be
> >>>>> considered flying very low, so numerous and so low such as to be
> >>>>>  forbidden to carry ADS-B equipment (or turn it off at lower
> >>>>> than that altitude if it carries one)?
> >>>>>
> >>>>>> Why 400'?
> >>>>>>
> >>>>>> I think it was to keep general aviation some reasonable
> >>>>>> distance above people on the ground.  As the ceiling for UA
> >>>>>> that is a consequence.
> >>>>>
> >>>>> You see, I think there is an error.
> >>>>>
> >>>>> 400 feet might be a good limit in terms of separation of people
> >>>>> and objects above their heads, but it is certainly not any limit
> >>>>> in terms of radio communication.
> >>>>>
> >>>>> If there is to be a radio communication limit (use or not use
> >>>>> ADS-B) it should be based on the power levels it uses and the
> >>>>> guarantees of range. In WiFi, bluetooth and 2G..5G that's how
> >>>>> they separate.
> >>>>>
> >>>>> For example, an 5G-carrying UAS would be limited to 450meter
> >>>>> altitude because that is how high the ground 5G oriented towards
> >>>>> ground reaches high.
> >>>>>
> >>>>> A bluetooth-carrying UAS (and not carrying ADS-B) would be
> >>>>> limited to 100 meter altitude because that is how high a
> >>>>> bluetooth device is allowed to emit, by bluetooth regulation.
> >>>>>
> >>>>>> "They can't go any lower, you can't go any higher."
> >>>>>
> >>>>> Strange.  Many devices, especially those who plane or glide like
> >>>>>  these UAS drones, and helicopters too, will stay stable at very
> >>>>> many low altitudes.  Their power systems - more and more
> >>>>> performing, allows for that.
> >>>>>
> >>>>> I very well see a helicopter stable 100meter above the ground,
> >>>>> and surely it carries an ADS-B device, if not several of them.
> >>>>>
> >>>>>>
> >>>>>> It is called boundaries to keep unequal players apart.
> >>>>>>
> >>>>>> One of the interesting debates in this is that the 400' floor
> >>>>>> is to ground obstacles like radio towers.  Thus since big birds
> >>>>>> have to stay 400' from that 700' radio tower down the block,
> >>>>>> you can take your UA up to 1100' right next to it...  Or so
> >>>>>> some claim.
> >>>>>
> >>>>> Right!
> >>>>>
> >>>>> RAdio towers, or radio towers with even higher anti-flash
> >>>>> ('paratonnerre', fr.) on them?  That adds some 10 meter to the
> >>>>> picture, to which an UAS drone would need to pay attention, just
> >>>>> like helicopters need to care about power lines above ground
> >>>>> too.
> >>>>>
> >>>>>>
> >>>>>> And speaking of Imperial vs Metric...
> >>>>>>
> >>>>>> Civil aviation separation is 1000'.
> >>>>>>
> >>>>>> This has already caused incidents where a lesser  Metric
> >>>>>> distance was used by one aircraft against one using the greater
> >>>>>> separation of Imperial.
> >>>>>>
> >>>>>> Fun!
> >>>>>>
> >>>>>> Not.
> >>>>>
> >>>>> I agree.
> >>>>>
> >>>>> Alex
> >>>>>
> >>>>>>
> >>>>>> Bob
> >>>>>>
> >>>>
> >>
> >
> > --
> > 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