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!