On 4/17/2020 2:01 AM, Ragnar Sundblad wrote: > > I thought we were talking about control traffic.
I expect there will be a TCP control traffic option. I expect there will continue to be a UDP control traffic option. These are "mechanisms", there will be a reasonable default policy (that will change and evolve over time), and there will be a mechanism to allow the local admins to implement their local policy choices. > 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. I still don't see why, in the general case, some here think we must force a smaller request packet to be padded just so a possibly larger response packet will provide no amplification. Basic packets are of a known and identical size. Before the 7822 braindamage (my opinion of 7822), EFs *required* MACs. Post 7822 they don't, but even so, if people implement EFs and don't include (disable?) "protection" they've pretty much made their choice. But we're speaking in generalities here. What new or proposed packet content would trigger a larger response that would not require an authenticated request in the first place? And I just realized this is the NANOG list and not the NTP list, so I'm happy to stop. H -- > 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! > > -- Harlan Stenn <st...@nwtime.org> http://networktimefoundation.org - be a member!
