Re: UDP/123 policers & status

[Ragnar Sundblad <ragge () kth se>]

> 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