On 17 Apr 2020, at 01:28, Harlan Stenn <stenn@nwtime.org> wrote:
I found this as an unsent draft - I hope I didn't send it before.
On 3/30/2020 2:01 AM, Ragnar Sundblad wrote:
On 30 Mar 2020, at 08:18, Saku Ytti <saku@ytti.fi> wrote:
On Mon, 30 Mar 2020 at 01:58, Ragnar Sundblad <ragge@kth.se> wrote:
A protocol with varying packet size, as the NTS protected NTP is, can easily have the bad property of having responses larger than the requests if not taken care. Don’t you see that?
Why? Why not pad requests to guarantee attenuation vector until authenticity of packets can be verified?
Right, and NTS does that.
There is more to NTP than NTS.
Are y'all seriously recommending that NTP always sends a max-sized packet as a client request so the client/server can send back an identical response? That's just wasting huge amounts of bandwidth to save the possibility of a possibly larger response.
If there is no sender verification, yes. It doesn’t have to be larger than the maximum response size. Another option is to use TCP - the handshake solves the problem.
And just becase a responbse may be larger, that doesn't necessarily translate into an amplification vector.
If there is no sender verification, it generally does. In what case does it not?
The alternative seems to be that the client sends a smaller request and is ready when the response from the server is "Send your request again, but this time pad it to NNN bytes so I can respond with the same sized packet"?
Sure, that is one way! Or - Here are the first N entries, send another request for the next batch, optionally: there are M entries in total. Or - TCP. There likely are many other options. Ragnar