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

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

On Thu, Oct 05, 2017 at 05:44:36PM -0400, Will Miles wrote:
> Hi,
> 
> Attached is a patch sequence for implementing Harlan Stenn's draft "Extended
> Information" NTPv4 extension as a mechanism to distribute TAI offsets
> between nodes.   This should be considered beta quality at best - it hasn't
> been thoroughly debugged, and there is undoubtedly significant room for
> improvement.

Thanks. This is great stuff. When I want to include some of the
patches, I'll ask for updates :).

> -> It iterates over the extensions twice -- once to look for the MAC, if
> present, and then again later to actually process the extensions.   There's
> probably a way to do this with a single pass, but some extensions may
> require a valid MAC before they can be used, so I took the easy but
> inefficient approach as a starting point.

I think that's ok. From the security point of view it makes sense to
process extension fields only when the packet passed the
authentication test.

> -> It might've been better to add a runtime configuration file option
> instead of a compile time decision to enable the draft extension support.

Yeah, current NTP implementations cannot respond properly to a request
with an (unknown) extension field.

I'm wondering if sources should vote on the TAI offset as with the
leap status. It will be interesting to see how this works around leap
seconds.

> -> I didn't spend a lot of time considering which outbound packets ought to
> have the extension added - the decision there is very likely wrong for the
> general case.

I think server responses should include the field only if the client
requests have it.

Some random comments:

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.

When making an incompatible change in a cmdmon request/response, the
command number should be changed.

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