On Fri, Nov 06, 2015 at 01:38:02PM -0500, Danny Mayer wrote: > On 11/6/2015 3:05 AM, Miroslav Lichvar wrote: > > there is still a case in which the check is not performed at all. > > What case would that be?
The case where one of the checks performed before this one fails, but doesn't reject the packet. I thought I explained it in the private discussion we had couple weeks ago about this. The fix I think is to either always perform TEST2 for KoD packets or drop them when any of the other tests failed assuming TEST2 was not performed. > > It's not a big deal and the fix is simple. Unfortunately, it will > > probably need to wait until ntpd as a client is fixed to not violate > > the RFC (increasing the polling rate when the received KoD poll is > > small) and this fixed version is widely used. > > It does NOT violate the RFC. I think it does. The description of the RATE code in the section 7.4., to which you were referring before, currently says: For kiss code RATE, the client MUST immediately increase its polling interval to that server and continue to increase it each time it receives a RATE kiss code. It doesn't explain how exactly should be the polling interval increased, but I think it's clear it doesn't allow the client to immediatelly reduce its interval as ntpd does when the KoD RATE poll and the configured minpoll are both smaller than the current host poll. > > Right. But look at it from the client's point of view. It's still > > getting good replies to a fraction of its queries and this fraction > > doesn't change with the attacker's sending rate (until the network is > > overloaded). > > It would likely be days before a real reply to the target systems > request would come through with valid timestamps and that's not likely > to help the situation. That only depends on the rate limiting configuration. It the server responded on average once per eight request (to match the maximum number of consecutive measurements that can be dropped in the ntpd clock filter), with the default maximum polling interval of 1024 seconds the average server response interval would be about 2 hours. > > Yes, but there is probably nothing that could be done about it. The > > server could try to track all NTP clients (not SNTP) by saving the tx > > timestamps and comparing them to the client's org timestamps, but that > > would basically turn it into something like TCP and bring all the > > problems it has. > > Huh? When the server gets the packet there's only one timestamp in the > packet and that's the senders "origin" timestamp (spoofed or otherwise). > So what does it have to compare it against? NTP (but not necessarily SNTP) clients set the origin timestamp in their requests to the transmit timestamp from the previous server reply. If the server saved its transmit timestamps it could check if the client received the previous reply and therefore know the request is not from a spoofed IP address. -- Miroslav Lichvar _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
