[Ntp] Re: Roman Danyliw's Discuss on draft-ietf-ntp-interleaved-modes-07: (with DISCUSS and COMMENT)

[Miroslav Lichvar <[e-mail]>]

On Tue, Aug 20, 2024 at 09:57:02AM -0700, Roman Danyliw via Datatracker wrote:
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Other ADs have commented on the benefit of providing additional clarifying
> language where guidance is described using “SHOULD”.  On a subset of those
> instances, it appears that these phrases could potentially cause
> interoperability issues or have security implications depending on their
> interpretation.

Thanks for the review.

> ** Per the possibility of interoperability or under-specification of the
> algorithm:
> 
> -- Section 3
>    The peer SHOULD process the requests in the same way as a
>    server which supports the interleaved client/server mode.   It MUST
>    NOT respond in the interleaved mode if the request was not in the
>    interleaved mode.
> 
> Is there any interoperability impact if the peer chooses NOT to process the
> request the same way as the server?  When would one choose this behavior?

There is no impact on interoperability. The server can do different
things in different modes and for different clients, or even for one
client at different times. The SHOULD was used here as a
recommendation for the implementation to keep things simple, but if
some implementation had different code paths for different modes
making different tradeoffs, it would be fine.

> -- Section 3
>    A peer A SHOULD send a peer B a packet in the interleaved mode only
>    when all of the following conditions are met:
> 
> When would a peer ignore the conditions described after this clause? If
> implementations chose different criteria (since this list is not mandatory)
> would this cause interoperability issues?

This does impact interoperability in some configurations. If I
remember correctly the SHOULD here was used to not break conformance
for the original implementation of the interleaved mode, which does
not implement the second and third condition. It doesn't work
correctly when the peers send packets at different rates.

The symmetric mode is typically used only between servers that are
managed by the same entity. It's susceptible to off-path attacks. It
needs authentication, which means the peers need to share a symmetric
key. The implementation and configuration of the association
(including polling intervals) is normally expected to be the same.

> -- Section 3
>    The peers SHOULD compute the offset and delay using one of the two
>    sets of timestamps specified in the client/server section.
> 
> How would this computation be done without one of the two sets of timestamps
> described in this section?

It could use a different set of timestamp, reusing timestamps from an
nth-previous exchange.

> -- Section 6
>    A client which supports the interleaved mode SHOULD check if the
>    origin timestamp is not zero to detect packets in the interleaved
>    mode.  The client SHOULD also compare the origin timestamp with the
>    transmit timestamp from the previous packet to detect lost packets.
>    If the difference is larger than a specified maximum (e.g. 1 second),
>    the packet SHOULD NOT be used for synchronization in the interleaved
>    mode.
> 
> How would interleaved mode be detected without the “not zero” approach above? 
> Perhaps by configuration?

The SHOULD here was meant to allow clients to ignore interleaved mode
when provided by the server (i.e. the origin timestamp is not zero).
They can stick to the basic mode if they prefer it for any reason,
e.g. configuration.

> -- Section 6
>    The client SHOULD compute the offset using the origin timestamp from
>    the received packet and the local receive timestamp of the previous
>    packet.
> 
> What is the alternative to computing the offset if not with the algorithm
> described above?

Yes, that seems like the only choice. The SHOULD should be removed and
just state the fact.

> ** Per the Security implications:
> 
> -- In Section 6.
> 
> Clients using the interleaved mode SHOULD randomize all bits of both
> receive and transmit timestamps
> 
> When is it acceptable use predictable bits in the timestamps?

It's a recommendation improving security. It's not critical. The
original implementation doesn't implement this randomization and would
become nonconformant if it was required.

> ** Section 4.
>    The timestamp cannot be included in the packet itself unless the
>    driver or hardware supports NTP and can modify the packet before or
>    during the actual transmission.
> 
> Is this a common setup for “software NTP implementation running on a   
> general-purpose operating system” to have NIC “driver or hardware support for
> NTP?

I have not seen it, but it is a possibility.

> ** Why does the WG consider draft-ietf-ntp-port-randomization a suitable source
> of normative guidance given that it was an adopted by the WG, but never
> finished (and it expired 5 years ago)?

Good question.

-- 
Miroslav Lichvar