[ntp:hackers] Minor twitches and flakes

David L. Mills mills at udel.edu
Mon Apr 7 16:13:55 UTC 2008


Danny,

Very definitely there is something missed. Autokey uses a pseudo-random 
sequence to bind each packet to a previously signed packet with the 
initial sequence values. Ordinarily, if a packet is dropped, the client 
hashes to a previous packet or the initial values. When the key list is 
regenerated and a signed packet with the initial values is lost, the 
client has no choice but to wait an hour for the next signed packet or 
to restart the protocol after timeout, whichever happens first.

This problem doesn't happen in other modes, as the client/peer simply 
asks for the initial values. In principle this could happen in broadcast 
mode, but it is rather awkward and the overhead of restarting the 
protocol is not ordinarily an issue. Having said that, an evil intruder 
might choose to jam the wire as the initial values packet is sent 
causing four thousand clients to restart the protocol at the same time. 
A truly paranoid server should randomize the poll intervalsto make that 
less likely.

Dave

Danny Mayer wrote:

> David L. Mills wrote:
>
>> Guys,
>>
>> The ntpq billboards have been changed in very minor ways to agree 
>> with the names used in the NTPv4 specification. Only the receive 
>> timestamp is reported, as the other timestamps are either clobbered 
>> (to avoid a replay vulnerability) or misleading after the on-wire 
>> checks.
>>
>> There is a new restriction bit called flake. When lit, a fraction (10 
>> percent) of arriving NTP packets are simply dropped. The idea is to 
>> make sure the on-wire and Autokey protocols operate correctly in case 
>> of moderate to high packet losss. The on-wire protocol works just 
>> fine, even in symmetric modes with Autokey, when the packet loss is 
>> as high as 50 percent.
>>
>> However, packet loss is more critical in broadcast mode with Autokey. 
>> If an ordinary packet (ASSOC message) is lost, no problem; however, 
>> if an autokey values packet (AUTO message) is lost, the autokey 
>> sequence is broken. When this happens the client eventually times out 
>> and restarts the protocol. With a packet loss of 10 percent, one AUTO 
>> message in ten can be dropped. With the current default key list 
>> regeneration interval, this happens about once or twice a day. I 
>> don't think this is significant, as broadcast mode would ordinarily 
>> not be used over moderate to high loss networks.
>>
>
> I'm not sure why autokey is more critical in broadcast mode. The 
> autokey is negotiated in client/server mode and when the server is 
> authenticated the client will revert back to accepting the broadcast 
> packets and authenticating the broadcast packet with the autokey 
> obtained. After that it doesn't matter if it drops some of the 
> packets. Is there something I missed?
>
> Danny




More information about the hackers mailing list