Re: [Ntp] Robert Wilton's Discuss on draft-ietf-ntp-interleaved-modes-05: (with DISCUSS and COMMENT)

Miroslav Lichvar <> Wed, 30 June 2021 09:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 620BD3A15C3 for <>; Wed, 30 Jun 2021 02:46:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.296
X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.198, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xEcvKX4ZDcjS for <>; Wed, 30 Jun 2021 02:46:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A174D3A15C2 for <>; Wed, 30 Jun 2021 02:46:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mimecast20190719; t=1625046402; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=AQuKSNeO/sUASLCT5qmRDkXH01c1X6DmBRA3WkF2Rq0=; b=Usq1V2onRF9aHzDqA+uuRmlmY3HFRzFNi/1mxYq/NfQuGRd9k6Gfa8dUydSP5liPbwrXqo 09FlpC7/RTYK6r2GV3uNW2Xt3OvNJNRwjJTt1uf1393XNvZjhCzzdPZ0mJF8lIOZAI7RYi JsBt13II0II2oQd98Gb72HCEhyZGGJA=
Received: from ( []) (Using TLS) by with ESMTP id us-mta-342--sXczZWQNGW-58yj71bGmA-1; Wed, 30 Jun 2021 05:46:40 -0400
X-MC-Unique: -sXczZWQNGW-58yj71bGmA-1
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 906205074F; Wed, 30 Jun 2021 09:46:39 +0000 (UTC)
Received: from localhost ( []) by (Postfix) with ESMTPS id 30CD55C232; Wed, 30 Jun 2021 09:46:38 +0000 (UTC)
Date: Wed, 30 Jun 2021 11:46:36 +0200
From: Miroslav Lichvar <>
To: "Rob Wilton (rwilton)" <>
Cc: The IESG <>, "" <>, "" <>, "" <>, "" <>
Message-ID: <YNw9fHMijDFIW9B4@localhost>
References: <> <YNrfb6JIcfEa25pb@localhost> <> <YNrzSy0jtuY65IPn@localhost> <>
MIME-Version: 1.0
In-Reply-To: <>
X-Scanned-By: MIMEDefang 2.79 on
Authentication-Results:; auth=pass smtp.auth=CUSA124A263
X-Mimecast-Spam-Score: 0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Archived-At: <>
Subject: Re: [Ntp] Robert Wilton's Discuss on draft-ietf-ntp-interleaved-modes-05: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Time Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Jun 2021 09:46:48 -0000

On Tue, Jun 29, 2021 at 11:09:27AM +0000, Rob Wilton (rwilton) wrote:
> > A client request is never bogus.
> I'm still confused.
> Section 2 of the draft states:
>    The origin timestamp is a cookie, which is used to detect a packet
>    which is not a response to the last packet sent in the other
>    direction.  Such packets are called bogus packets in RFC 5905.

I can see how this paragraph is confusing. It was a late addition. It
should be improved. Bogus packets are responses, not requests.

> Looking at the t5 -> t6 packet from client to server in figure 1,
> The Org timestamp has been set to the server's previous Rx timestamp, not the Tx timestamp.
> When the server receives this packet from the client then would it not regard it as bogus?

No, servers that don't support the interleaved mode don't look at the
origin timestamp at all. They are stateless, they wouldn't know if it
was their previous TX or RX timestamp and most clients set it to 0

This is different in the symmetric mode where both ends have to check
it and what RFC 5905 is mainly about as a more general case of the
client/server mode.

> And just for clarity, if the server did interpret this as a bogus packet, are you saying that a server (that knows nothing about this extension) would still be expected to respond back to the client with a basic mode packet?


> I was trying to look at definition of receive() in A.5.1 of rfc5905, which seems to sometimes do a short return if it receives a bogus packet (at least under some circumstances), but not being familiar with the protocol or code, I cannot tell what the impact of that is.

The server wouldn't reach that part of the function. It would end in
the FXMIT case.


Miroslav Lichvar