Re: [chrony-dev] NTP "extended information" draft WIP implementation

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

On Mon, Oct 16, 2017 at 02:19:03PM -0400, Will Miles wrote:
> Further TAI-related thoughts:
> 
> Should the last known TAI offset be recorded with the drift stats?

I'd say no, but I'm not sure in what case would you need it. To allow a
server using the local directive immediately serve correct TAI offset?

> Does tzset() cache the tzdata in memory?   If so, long-running systems may
> need to restart chrony on tzdata update to pick up new table values.

It shouldn't. The chrony.conf man page says it's not necessary to
restart chronyd if the timezone is updated at least 12 hours before
the event.

> Can we query the tzdata for the TAI table expiry time?  I know it's carried
> in the underlying leap-seconds.list file.   With the expiry time on hand, we
> could know when to trust our local information vs remote updates.

No, unfortunately that information is not available. I guess one way
to encode the expiration date in the timezone would be to change the
offset at that point to 0 or some other special value.

> > I'm not sure if it will be generally possible to pad any extension
> > field up to the minimum length as they may be specified to have a
> > variable length. This is one of the unresolved issues that the NTP WG
> > needs to address.
> 
> Fair enough.   Honestly the RFC7822 patch really made me uncomfortable, too
> -- I don't understand the rationale behind the padding rule, it comes off
> like an attempt to be backwards compatible with some shipping but broken
> implementation.

The minimum length of the last extension field in a packet without MAC
is necessary to avoid mistaking a random MAC as an extension field. A
MAC can be up to 24 octets long. If the remaining length of a parsed
packet is longer, it should be an extension field.

The packet parsing code in chronyd was written before RFC 7822 and
some older versions allowed longer MACs in NTPv4 packets (in current
versions they are allowed only in NTPv3 packets). It tries to validate
the remaining part as a MAC before it is accepted as an extension
field. It is a hack at best, which works only when the keys are known
and the MAC is valid.

The NTP specification must allow middleboxes or tcpdump for instance
to correctly parse any NTP packet without access to the keys.
Hopefully, in NTPv5 everything will be in extension fields and the
minimum length can be shorter.

> An alternative would be to insert a specialized "padding"
> extension field, but that has its own issues with the other end maybe
> rejecting it on the grounds it doesn't recognize it.

I've proposed something like that. Two extension fields which could be
used to pack and pad multiple smaller extension fields to satisfy the
requirement on minimum length. Older implementations would see just
one longer extension field with an unknown type.

> > When making an incompatible change in a cmdmon request/response, the
> > command number should be changed.
> > 
> Noted.   I had mistakenly thought that since the change adopted one of the
> reserved fields without changing the length, old servers would zero-fill it
> (which just so happens to be the 'don't know' value) and it could be safely
> treated as backwards compatible.  I will correct this.

Oh, I missed that. If older servers already have a "reserved" zero in
the response, which happens to correctly indicate an unknown offset, I
think that would be a compatible change.

-- 
Miroslav Lichvar

-- 
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.