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

[Miroslav Lichvar <[e-mail]>]

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

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?

Yes.

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

Thanks,

-- 
Miroslav Lichvar