UDP/123 policers & status

Fri Apr 17 09:01:32 UTC 2020

I thought we were talking about control traffic.

If you want to do some NTP time comparison mode with larger responses
than requests, I agree that TCP is likely not a good option.

Ragnar

> On 17 Apr 2020, at 10:44, Harlan Stenn <stenn at nwtime.org> wrote:
> 
> NTP uses UDP for time.
> 
> I'm not sure what you're talking about.
> 
> H
> 
> On 4/17/20 1:32 AM, Ragnar Sundblad wrote:
>> 
>> 
>>> On 17 Apr 2020, at 01:28, Harlan Stenn <stenn at 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 at ytti.fi> wrote:
>>>>> 
>>>>> On Mon, 30 Mar 2020 at 01:58, Ragnar Sundblad <ragge at 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
>> 
>> 
> 
> -- 
> Harlan Stenn <stenn at nwtime.org>
> http://networktimefoundation.org - be a member!