Re: [Ntp] Last Call: <draft-ietf-ntp-interleaved-modes-04.txt> (NTP Interleaved Modes) to Proposed Standard

[Miroslav Lichvar <[e-mail]>]

On Tue, Apr 06, 2021 at 02:39:00PM -0400, Daniel Franke wrote:
> I think the feature introduced by this draft is fundamentally
> misdesigned. The objections that I'm raising here are ones that I've
> already raised during and prior to WGLC. When it was clear from the
> ensuing discussion that I was coming out in the rough on consensus, I
> asked Karen to go ahead and advance the draft but to note my
> objections in the shepherd write-up. This seems to have been missed,
> but no matter; this email captures my concerns.

This email tries to briefly explain the counterpoints to those
concerns in case people don't want to go through the WG archives.

> Interleaved mode, as specified by this draft, works by conditionally
> altering the semantics of certain NTP packet fields, to mean something
> entirely different from what they mean in RFC 5905.

They are not entirely different in the draft's authors view. The
transmit timestamp is still a transmit timestamp and the origin
timestamp is still a copy of a timestamp from the last received
packet. The only thing that changes is the reference.

> My interpretation, however, is that an SNTP client can put
> whatever it wants into the origin timestamp, because RFC 5905 Section
> 14 allows clients to implement "any subset of the NTP on-wire
> protocol", and phrases all interoperability requirements in terms of
> how a server is expected to construct its response to a given request
> packet.

An analysis of traffic captured on several public NTP servers in
different locations showed that there were no clients doing that,
except those that already supported the interleaved mode.

It should be noted that the first implementation of interleaved mode
using this mechanism was published before RFC 5905, by one of its
authors, so if the description of the origin timestamp seems too vague
to allow this mechanism to exist, it certainly was not intended.

> But a
> cleaner mechanism *is* apparent. NTPv4 supports extension fields, and
> we should use them. Instead of messing with the semantics of existing
> fields in the base packet, leave those alone and put the interleaved
> timestamp into an extension.

An extension field would be problematic for the NTP filter, which
relies on measured delay (shorter delay means a more accurate
measurement). Packets in the interleaved mode would be longer than
packets in the basic mode, i.e. their NTP delay would be larger and
the filtering wouldn't always work as expected.

Detecting server support would be problematic. Some mechanism would
need to be specified, which would need to make assumptions about
existing implementations, outside of what is specified in RFC 5905.
This is an issue that was proposed to be fixed in NTPv5. 

> I think the most tractable solution to the state problem is with a
> different design that avoids state entirely. Don't wait for another
> request from the client: just send one packet, capture the hardware
> timestamp, and immediately send that out in a second packet so that
> related state can be forgotten. The draft already discusses this
> approach, but dismisses it on the basis that it would allow for
> amplification attacks. This would be true of a naive design, but it's
> easy to problem to solve: just do exactly what DTLS does vis a vis
> HelloVerifyRequests, where before the server will send follow-up
> packets to a client, the client must obtain and echo back a
> server-generated, self-authenticated cookie bound to the client's IP
> address. This of course can again be done through extension fields.

This approach has some advantages, but also disadvantages, as
discussed recently wrt NTPv5 design. Some of the issues are:

- It doesn't really change much in the susceptibility to DoS attacks.
  On most current hardware, transmit timestamps can be requested only
  one at a time. The server could send the follow-up messages
  synchronously or asynchronously, but in any case the maximum rate
  would be limited and could be exploited by attackers. IP-specific
  rate limits are not very useful in IPv6, where attackers have
  practically unlimited number of addresses.

- Clients need to have a timeout for the follow-up message and deal
  with reordered messages.

- It is wasting network bandwidth.

- It creates an asymmetric network load, which can lead to an
  asymmetric congestion and asymmetry in NTP measurements.

- It has potential security issues in the cookie implementation due to
  extra complexity and dependency on crypto.

The interleaved mode described in this draft is simpler, inherently
immune to amplification attacks, and it gracefully falls back to the
basic mode.

-- 
Miroslav Lichvar