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

[Ulrich Windl <[e-mail]>]

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

>>> Daniel Franke <[e-mail]> schrieb am 06.04.2021 um 20:39 in
Nachricht
<[e-mail]>:
> 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]> 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] mailing lists by 2021-04-14. Exceptionally, comments
>> may
>> be sent to [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] 
>> https://www.ietf.org/mailman/listinfo/ntp 
>>