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 <st...@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 <st...@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 <s...@ytti.fi> wrote: >>>>> >>>>> On Mon, 30 Mar 2020 at 01:58, Ragnar Sundblad <ra...@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 <st...@nwtime.org> > http://networktimefoundation.org - be a member!
