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

["David L. Mills" <[e-mail]>]

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.
>
> 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 <[e-mail] 
> <mailto:[e-mail]>> 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
>     [e-mail] <mailto:[e-mail]> mailing lists by
>     2021-04-14. Exceptionally, comments may
>     be sent to [e-mail] <mailto:[e-mail]> 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
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/ntp
>
>------------------------------------------------------------------------
>
>_______________________________________________
>ntp mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ntp
>  
>
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