On Thu, Mar 31, 2016 at 07:50:08AM +0000, Harlan Stenn wrote: > Miroslav Lichvar writes: > > Any state that the protocol would require on the server is a potential > > vector for a DoS attack. How easy is for an attacker to make new > > "connections" and allocate memory on the server? > > While great hunks of this are implementation-dependent, I suspect no > additional memory will be required to answer "now" as opposed to > "later". The difference is "duration" and it's easy enough to deal with > that. There are other steps that can be taken, too.
If you want to respond later, you need to save that response somewhere. And when you have too many reponses saved, you need to drop some of them. > > Can the attacker prevent other clients from fully forming the NTS > > association? > > How? By forcing the server to drop the saved response which the client will need. If the server doesn't save any state, there is nothing for the attacker to play with. > > Ok, but why would you not send the result to the client when the > > operation is finished? Are you expecting it will take longer than some > > minimum expected polling interval of the client (e.g. 1 second)? > > In a client/server situation, how would you propose to do that before > the next poll? Like with any other NTP packet? Respond immediately when the request is processed. The crypto operations should be much faster than the 2s iburst interval, I don't think we need to worry about clients sending new request before they get the reply. If there are more requests than the server can handle, then some of them will be dropped. -- Miroslav Lichvar _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
