Re: [Ntp] Quick review of WGLC for status change for draft-ietf-ntp-update-registries

[Harlan Stenn <[e-mail]>]

Hi Heiko,

On 8/15/2022 3:58 AM, Heiko Gerstung wrote:
> Hi Harlan,
> 
> thanks for the quick response. As far as I can see, mode 7 is "reserved" in the current version of the RFC for NTP, or did I miss an errata?

As Miroslav pointed out, mode 7 is "private use", which the code has (as 
I recall) always been documented as "vendor-specific".

> As far as I can see, an implementation that knows nothing about mode 7 packets (the vast majority of "simpler" implementations and also some of the more common implementations would simply drop such a packet - even if VN=5 would have been ignored by such an implementation (which, IMHO, is a bug in itself because an implementation should never assume that a packet with a version number higher than what it knows - and supports - is compatible).

Re the version numbers, the code has long said that the server responds 
with the packet version it speaks, using the version specified in the 
client's request.

So if we're a V4 server and we get a v5 request, we will respond with a 
v4 packet that says v5.

This is consistent with the design.

No one has seen a v1 packet format in a very long time.  The v1 stuff 
folks are seeing now are v[234] packets claiming to be v1.

The format of the base packet saw a slight change going from v2 to v3 
(sync dispersion was replaced by estimated drift rate), and there was 
(TTBOMK) no change to the base packet from v3 to v4.

The change from v2 to v3 caused no problems that I can recall, and even 
so, I'm unaware of ANY surviving v2 servers out there.

v4 added extension fields, and Dave Mills and I wonder if there is a 
compelling reason to change the base packet format for v5, as opposed to 
creating a new EF that contains the additional info that is being 
discussed for v5.  Going this way completely avoids interoperability issues.

> My intention here is that we find a way to extend and expand the NTP packet format for V5 while ensuring that all the NTP stuff out there is not negatively impacted by it (i.e. by assuming that an NTP packet, no matter which version, forever uses the same packet format). Making sure that most/all implementations out there will ignore/drop/reject a V5+ packet should  do the trick here.

What do we get from a recipient ignoring/dropping/rejecting a v5 packet 
that we don't get from the case where the v5 gets a response that is 
from a v4 (or earlier) server that replies with a v4-formatted packet 
that claims v5 (because servers reply with the version from the incoming 
packet)?

> As far as I can see, I-DO is not a solution for this. It depends heavily on the assumption that an implementation is checking the capabilities of a remote device. All existing implementations in the field (I assume this includes all deployed versions of ntpd) are not using this approach today.  Therefore, the protection here can be provided only for new/updated implementations which try to talk to an outdated/older/historic implementation.

 From what I've seen, this is no problem at all.

A "current" v4 server will reply to an I-DO with a crypto NAK.  This 
immediately tells the sender that I DO is not handled.

I recall that Miroslav said chrony will just drop the packet.  This 
implicitly/eventually tells the sender that I-DO is not handled.

I came up with I-DO because there needs to be a quick and clean way for 
arbitrary clients to figure out what feature set is implemented by the 
other side.  This works for both client/server and peer mode stuff. 
Also for broadcast.

This is important because we're talking about UDP with relatively long 
communication intervals.

> You can protect V5 NTP clients/servers but not (for example) a V4 client trying to use an (incompatible) V5 server.

If this is how v5 will be deployed, it sure sounds like it will not be a 
smooth or quick upgrade.

> If that V5 server implementation chooses not to support V4 requests, it can respond with a V5 Mode7 packet which the V4 client will most likely drop/ignore.

And this is a feature?

What happens next, as far as the client is concerned?

> I believe that an interface to the status and configuration of an NTP implementation is very useful and should be mandatory, but for me it makes more sense to set up an interface as an IPC channel (i.e. "locally") and make it easy to use for general purpose management protocols like SNMP or NETCONF etc. instead of allowing to use it over a network connection. That would always requires a lot of security considerations which have been solved already by the general purpose protocols (e.g. SNMPv3 or a REST API using authentication and TLS for example).

Are you talking solely about deciding how to query an ntp server, or are 
you talking about how an arbitrary client would decide what features are 
supported by an arbitrary server?

I-DO used v4 EFs, so it's "in band" with normal NTP traffic.  It 
specifically avoids using mode 6 or mode 7.

The "what features do you support" thing might be useful to add in mode 
6 (people can do whatever they want for mode 7), but I see no benefit to 
having ntpd decide to send a mode 6 query to determine this when I-DO 
has demonstrably worked so well.

> Regards,
>    Heiko
> 
> 
> 
> 
> --
> Heiko Gerstung | Managing Director
> T: [phone] | LinkedIn Profile <https://www.linkedin.com/in/heikogerstung/> | Twitter <https://twitter.com/hgerstung>
> [e-mail]
> 
> MEINBERG® The Synchronization Experts
>   
> Meinberg Funkuhren GmbH & Co. KG
> Lange Wand 9 | 31812 Bad Pyrmont | Germany
> Web: http://www.meinberg.de | http://www.meinbergglobal.com | LinkedIn  <https://www.linkedin.com/company/meinberg-funkuhren-gmbh-&-co--kg>
> 
> Amtsgericht Hannover 17HRA 100322
> Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung
> 
> Do not miss our Time Synchronization Blog:
> http://blog.meinbergglobal.com
>   
>   
> 
> Am 15.08.22, 09:57 schrieb "Harlan Stenn" <[e-mail]>:
> 
>      Hi Heiko,
> 
>      On 8/14/2022 11:59 PM, Heiko Gerstung wrote:
>      > Hi all,
>      >
>      > quick idea (I know! Those are the best ;-) ..
>      > Would it be possible to define mode 7 = version specific? This way all V4 Mode 7 packets would continue to work, and for V5 we could  introduce an additional field in the header that allows for more "modes" (i.e. packet types) in addition to the ones currently defined (and RFC5905 specifies mode 7 = reserved).
> 
>      Mode 7 is already "vendor specific" control packets.
> 
>       From Dave's POV, mode 6 contained ASCII data, and mode 7 contained
>      binary data.
> 
>      We already have a problem with "shifting sands" and both mode 6 and mode 7.
> 
>      I've long had an item on my TODO list that would let us "figure out"
>      what command set (for lack of a better word) was supported by v6 and v7.
> 
>      I believe your intent could also be satisfied with our I-DO EF proposal.
> 
>      I do kinda like that mode 7 is vendor-specific commands.  It leaves a
>      way to do things that stay out of the way of mode 6 commands (which are
>      expected to be "general").
> 
>      I also think we would benefit from put time and effort into fleshing out
>      mode 6 commands, and I believe that is an area where we would also want
>      version-specific commands, which would also imply experimental and
>      vendor-specific values.
> 
>      We have choices here, and it's not clear to me where it's safe to change
>      things up, and where we need to be more careful.
> 
>      It may well be that we would reserve one or more of the current mode 6
>      opcodes to "extend" things, but it's also not yet clear to me that we
>      might need this.  The current opcode list seems pretty complete, and
>      only half of the 32 opcodes are currently assigned.
> 
>      I think draft-ietf-ntp-mode-6-cmds needs additional work, but do enough
>      folks here care enough about it?
> 
>      > Most things in the wild would not try to decode and (mis)understand such a packet. With this approach we could avoid that a V5 request (with a different packet format) is misunderstood by a V4 server for example (because V5 would always use Mode = 7 and distinguish between client requests, server responses etc. etc. by using a new field - this way we could increase the number of potential packet types and more easily introduce new ones without the risk of breaking an older version implementation misunderstanding a packet).
>      >
>      > Best Regards,
>      >    Heiko
>      >
>      >
>      >
>      > _______________________________________________
>      > ntp mailing list
>      > [e-mail]
>      > https://www.ietf.org/mailman/listinfo/ntp
> 
>      --
>      Harlan Stenn <[e-mail]>
>      http://networktimefoundation.org - be a member!
> 

-- 
Harlan Stenn <[e-mail]>
http://networktimefoundation.org - be a member!