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

[Stu Card <[e-mail]>]

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