Miroslav Lichvar writes: > 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.
How is that significantly different from having lots of NTS connections starting up at the same time? Regardless, this is a pretty easy situation to address. I'm not worried about it at all. > > > 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. Same as above. This is something that's pretty easy to address. > > > 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. Again, that's a local policy choice. If you choose that approach and the crypto work is "expensive" you've just traded one attack vector for another. H _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
