[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ntp-hackers
Subject:    Re: [ntp:hackers] Minor twitches and flakes
From:       "David L. Mills" <mills () udel ! edu>
Date:       2008-04-13 20:58:49
Message-ID: 48027409.7060901 () udel ! edu
[Download RAW message or body]

Todd,

You don't want 500 broadcast clients to crank through the entire 
protocol setup just because a stray AUTO packet was lost on the wire. It 
is not a breach of security to regenerate the key list with signature 
and that happens all the time. In the current implmentation the client 
remembers the last key ID used. So, if a single ASSOC packet is lost 
there is no need to bother the server. If an AUTO message is lost, the 
client exhausts the most recent key list and then sends an AUTO request 
to the server, just as when first coming up. There is no need to restart 
the protocol

On another issue, the client keeps track of the association ID used in 
the AUTO request. If it sees the ID change, then the server has 
restarted ntpd. At the moment, the client responds as when an AUTO 
message is lost. Probably, it should restart the protocol.

Dave

TS Glassey wrote:

>
> ----- Original Message ----- From: "David L. Mills" <mills@udel.edu>
> To: <hackers@ntp.org>
> Sent: Saturday, April 12, 2008 10:08 PM
> Subject: Re: [ntp:hackers] Minor twitches and flakes
>
>
>> Danny,
>>
>> Very incisive comment. The problem is that, when the AUTO message is
>> lost, the autokey sequence is broken. The only way to recover is either
>> a general reset and crank through the protocol from the beginning or to
>> resume the protocol from the point before the autokey values were
>> fetched.
>
>
> True - so there are two policy control models here - one that says 
> "Recover if Possible" and another that says "Force a restart of the 
> token exchange process".
>
>> The fix I implemented is to revert to the server/client mode
>> and resume the protocol at that point. With a little care this is
>> completely slick and works even if the broadcast server is restarted
>> from scratch.
>
>
> Yes but it ignores that other's may want to force that restart from 
> ground-zero to insure the overall integrity of the process. I think 
> you need to allow for both methods.
>
>>
>> The test scenario is to stabilize a pair of broadcast servers and a
>> single client and then systematically restart first the client and then
>> each server in turn and then verify the client correctly recovers. Fun
>> to watch, but it works.
>>
>> 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
>>
>>
>>
>> _______________________________________________
>> hackers mailing list
>> hackers@lists.ntp.org
>> https://lists.ntp.org/mailman/listinfo/hackers 
>
>

_______________________________________________
hackers mailing list
hackers@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/hackers
[prev in list] [next in list] [prev in thread] [next in thread]