[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