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.
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
last-call@xxxxxxxx
mailing lists by 2021-04-14. Exceptionally, comments may
be sent to iesg@xxxxxxxx
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
ntp@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ntp
_______________________________________________
ntp mailing list
ntp@xxxxxxxx
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
|
