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

[Heiko Gerstung <[e-mail]>]

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

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. You can protect V5 NTP clients/servers but not (for example) a V4 client trying to use an (incompatible) V5 server. 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. 

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

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!