More on time sync.
On 7/12/22 13:33, Robert Moskowitz wrote:
On 6/28/22 20:51, Dave Thaler via Datatracker wrote:
Reviewer: Dave Thaler
Review result: Ready with Issues
Overall I found the document very well-written.
I have the following comments/questions for the authors/WG that I
feel SHOULD
be addressed:
1. I found the discussion of time to be a bit lacking and would like
to see it
clarified. Specifically, section 3.2 talks about attestation
including a
timestamp, though it is unclear to me what requirements this places
on the UA
for having a trusted source of time, such as a local clock. Section
8.2 says
"UAs and Broadcast Remote ID communications are so constrained that
current
post quantum computing cryptography is not applicable" so if UAs are
that
constrained, can you really rely on them having a trusted source of
time? For
example, I know in many TEEs, a trusted source of relative time (e.g.,
monotonic counter) is not even available, and I could imagine that
there are
many uses (e.g., defense) whereby a UA might want/need a TEE for
attestation.
The level of trust in time gets to the issue about how robust the
architecture
is against replay attacks.
GPS is generally used for the trusted time on a UA.
But overall, and we discussed this a LOT on ASTM calls, the time from
the UA is always slewed. There is some natural lag between reading
the time from the internal source (kept correct via GPS) and the time
the packet was sent, let alone when the Observer received it. This is
one of the points I make in draft-moskowitz-drip-crowd-sourced-rid.
And this ties into the whole trust authentication now added to
draft-ietf-auth, sec 1.1. If all the authentication proves out, now
verify it via a local source. (eyes, multilateration, etc.)
I just received notification on a 30-day 2nd round ballot on:
Specification for Positioning Assurance, Navigation, and Time
Synchronization (PNT) for Unmanned Aircraft Systems (UAS) WK75923
This is to allow options for the FAA rule against continuing an
operation if you do not have GPS:
“Operations subject to this waiver must cease if, at any time: GPS
signal is
lost, or GPS location information is degraded.”
“The PIC may not begin or continue a flight if any global positioning
system
(GPS) outage, signal fault, integrity issue, Notice to Airmen in effect
for any
part of the planned operational area, or any other condition that
affects or
could affect the functionality or validity of the GPS signal.”
“Geo fencing relies on GPS accuracy. For this software to be effective as a
mitigation, the PIC must know the GPS location certitude of its UAS system
and factor that into his or her planning. For example, if the GPS location
certitude of the UAS is ± 10 feet, then add 10 feet to the buffers
between the
UA and filming personnel.”
“Prior to each flight, the operator must consult advisory and warning
publications or programs for any GPS availability or quality issues and
confirm that GPS is expected to be available throughout the intended
operation with acceptable performance. Additionally, the operator must
consider the effect of degraded GPS inputs induced by adjacent structures
and implement appropriate mitigations.”
So time accuracy and GPS is not our concern. It is a much bigger
concern in UAS and we ride that wagon.
And FAA does not, currently, permit using someone elses global
positioning sats. We argued this and lost as they said it is really not
their call...
Makes a mess (and FAA recognizes this) for any manufacturer selling into
other markets.
I expect to be reviewing this doc in some quite corner at IETF before
casting my vote...
Bob
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
