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

From: Daniel Franke <[email-masked]>
Date: Tue, 6 Apr 2021 14:39:00 -0400

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.

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. This change of
semantics is not signaled anywhere else in the packet; both parties
are required to maintain state to keep track of which semantics are
intended.

The means for a client to signal that it wants to enter interleaved
mode is arguably another incompatible change from RFC 5905 semantics,
though there is room for some interpretation on this point. A client
which fully implements and strictly adheres to RFC 5905 will, on its
first request to a given server, set the origin timestamp field in its
request packet to zero; on subsequent requests, it will set it by
copying the transmit timestamp from the server's most recent response.
However, the client's origin timestamp is of no actual significance to
the protocol; RFC 5905's description of how a server is to construct
its reply makes no use of it at all. SNTP clients typically always set
it to zero, and I-D.ietf-ntp-data-minimization recommends that all
clients do this, since the behavior of copying the server's transmit
timestamp enables tracking. RFC 5905 is vague on what's actually
expected of clients here, since there is no RFC 2119 language on the
matter. 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.

In the interleaved-mode draft, a client signals that it wants to enter
interleaved mode by setting its origin timestamp from the server's
last *receive* timestamp instead of from its transmit timestamp. But
in light of the above, I think that such behavior is already allowed
of clients that are ignorant of interleaved mode, and so I think this
signaling mechanism introduces an incompatibility. One can dismiss
this concern as theoretical, saying that no interleaved-mode-ignorant
client would ever actually behave this way, and I might be sympathetic
to this if no cleaner negotiation mechanism were apparent. 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.

A second problem with this draft, one of more immediately practical
concern, involves state management, especially when NATs are
involved. Servers supporting interleaved mode are required to keep
state on their clients, but the means of distinguishing one client
from another is underspecified. It states, "The server MAY separate
the timestamps by IP addresses, but it SHOULD NOT separate them by
port numbers". A server which opts out of the MAY would just keep one
global table mapping every receive timestamp it has produced to a
matching (hardware) transmit timestamp, and make lookups into this
table based on the client's origin timestamp, removing such entries
only when they time out. The draft does not specify what the timeout
period should be, but it needs to be at least a decent multiple of
1024 seconds, since that's the polling interval that most clients use
by default. A server which behaved this way would be easily DoSed,
since a single IP could spam it with requests and quickly exhaust
memory. Authentication wouldn't be enough to prevent this, since an
adversary who captures even a single authenticated packet can then
replay it endlessly.

To avoid such a vulnerability, the server really needs to maintain a
separate table per IP address, and limit how much it's willing to put
into a given table. Actually, that's still not enough: source IPs can
be spoofed, so there's a need for some sort of SYN-cookie-esque
mechanism to make sure that a client is really able to receive traffic
on its purported IP before the server is willing to keep any state for
it. Let's imagine for the moment that this mechanism exists: we're
*still* in trouble on account of NATs. We can't just assume, "one IP,
one client", because there may be multiple, and indeed a very large
number, of clients behind a single NAT address. Therefore these per-IP
tables still need to be allowed to get quite large to prevent such
clients from stepping on each others' state.

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.

On Wed, Mar 31, 2021 at 9:01 AM The IESG <[email-masked]> wrote:

>
> The IESG has received a request from the Network Time Protocol WG (ntp) to
> consider the following document: - 'NTP Interleaved Modes'
>   <draft-ietf-ntp-interleaved-modes-04.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2021-04-14. Exceptionally, comments
> may
> be sent to [email-masked] instead. In either case, please retain the
> beginning
> of the Subject line to allow automated sorting.
>
> Abstract
>
>
>    This document extends the specification of Network Time Protocol
>    (NTP) version 4 in RFC 5905 with special modes called the NTP
>    interleaved modes, that enable NTP servers to provide their clients
>    and peers with more accurate transmit timestamps that are available
>    only after transmitting NTP packets.  More specifically, this
>    document describes three modes: interleaved client/server,
>    interleaved symmetric, and interleaved broadcast.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-ntp-interleaved-modes/
>
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
>
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
>

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 07 Apr 2021 10:51:51 +0200

Reading this I have the feeling that the best way to signal interleaved mode would be using an appropriate extension field.

>>> Daniel Franke <[email-masked]> schrieb am 06.04.2021 um 20:39 in
Nachricht

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 7 Apr 2021 12:13:48 +0200

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

> 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

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

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. 

> 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

---

From: "David L. Mills" <[email-masked]>
Date: Sun, 11 Apr 2021 16:25:08 -0400

Daniel Franke wrote:

> On Wed, Mar 31, 2021 at 9:01 AM The IESG <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     [email-masked] <mailto:[email-masked]> mailing lists by
>     2021-04-14. Exceptionally, comments may
>     be sent to [email-masked] <mailto:[email-masked]> instead. In either
>     case, please retain the beginning
>     [email-masked] <mailto:[email-masked]>
>------------------------------------------------------------------------
>
Folks,

There is a much easier way to do this,  as I proposed in the recent 
document posted for review. See Section 4.3 for explanation.

The way I propose can be used in all protocol modes and does not requre 
any specific configuration or extension fields.  Briefly, the onwire 
protocol operates as usual, except  that the devstamp of the last 
transmitted packet is saved in a state variable.
In the reply packet, the origin timestamp is replaced by the saved 
devstamp.  The offset and delay are computed as usual. However, the full 
interleave function requires two protocol rounds to develop a full 
compliment of timestamps. There's no need to do anything special, 
especially not modify any other header field in the reply.  This change 
is compatible with legacy versions and rfc 5905.

Dave

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 12 Apr 2021 12:49:26 +0200

On Sun, Apr 11, 2021 at 04:25:08PM -0400, David L. Mills wrote:
> There is a much easier way to do this,  as I proposed in the recent document
> posted for review. See Section 4.3 for explanation.

I think you are referring to
https://www.eecis.udel.edu/~mills/Autokey3.txt

> The way I propose can be used in all protocol modes and does not requre any
> specific configuration or extension fields.  Briefly, the onwire protocol
> operates as usual, except  that the devstamp of the last transmitted packet
> is saved in a state variable.
> In the reply packet, the origin timestamp is replaced by the saved devstamp.

If the origin timestamp in a response contained a transmit timestamp
of a previous response to the same client/peer, how could it pass the
loopback test at the client/peer? It needs to be a timestamp copied
from the request. For compatibility with RFC 5905 it needs to be the
transmit timestamp from the request (aka basic mode).

> The offset and delay are computed as usual. However, the full interleave
> function requires two protocol rounds to develop a full compliment of
> timestamps. There's no need to do anything special, especially not modify
> any other header field in the reply.  This change is compatible with legacy
> versions and rfc 5905.

The linked document doesn't describe the on-wire protocol in enough
detail for me to understand it. I'd like to see an example with few
exchanges showing all timestamps in packets.

If the protocol really is supposed to be compatible with the current
ntp.org implementation, I don't think it could be very different from
the ntp-interleaved-modes draft discussed in this last call.

The compatibility was one of the goals. The main difference to the
ntp.org implementation is that it automatically switches between
processing packets in basic and interleaved mode, which is needed in
some corner cases, e.g. when polling intervals of two peers in a
symmetric association don't match.

-- 
Miroslav Lichvar