[ntpwg] KISS codes

[David L. Mills]

Tony,

The KoD filter is actually better than you think. In the abuses cited in 
http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti04.pdf, only 
the last few tens of seconds was captured in the NIST and USNO servers. 
That was enough to catch the most abusive clients and punish them. 
Furthermore, as in other massive DoS attacks, the behavior when things 
get really nasty is to rely on probabilistic defenses. In the KoD filter 
a decision is made on a probabilistic basis whether to drop the most 
recent entry or prune the end of the list. This allows in effect new 
blood and prevents freezout of new abusers.

Dave

anthony.flavin at bt.com wrote:

> Danny,
>
> I don't see how this would work. Especially in the case of SNTP. The
> problem you site is where the sheer number of devices polling the server
> swamped it. I believe that at the moment an NTP server only stores the
> past 600 which is unlikely to be enough to determine who the trouble
> makers are, so unless you are proposing to store the last several thousand
> requests, how are you going to determine who to send the codes to?
>
> Regards,
>
> Tony Flavin
> Core Networks Engineering Manager
>
> e-mail: anthony.flavin at bt.com
> tel: +44(0) 1473 609570
> mobile: +44(0) 7801 759596
> fax: +44(0) 1908 862752
>
> Orion 5, pp11 , Adastral Park, Martlesham, Ipswich IP5 3RE, UK
>
>
>
> -----Original Message-----
> From: ntpwg-bounces+anthony.flavin=bt.com at lists.ntp.org
> [mailto:ntpwg-bounces+anthony.flavin=bt.com at lists.ntp.org] On Behalf Of
> Danny Mayer
> Sent: 09 July 2007 15:57
> To: Odonoghue, Karen F CIV NSWCDD, W13
> Cc: NTP Working Group; Harlan Stenn
> Subject: Re: [ntpwg] KISS codes
>
>
> Odonoghue, Karen F CIV NSWCDD, W13 wrote:
>
>> Danny and Harlan,
>>
>> I was wondering about this issue earlier today as I was working
>> through
>> all the comments received. My question is based on other discussions on
>> this mailing list related to whether or not we are representing
>> current practice. Along that vein, would it make sense to change
>> "MUST" to "SHOULD" in Danny's proposed text? I can go either way
>> but I was struggling with identifying the consensus...
>>
>
> My preference here is MUST since revisiting this in a later RFC is much
> harder. It's actually easier to change it to SHOULD later. My desire to
> see this implemented as a MUST for both NTP and SNTP is the experience
> that a number of clock providers have been through where they have been
> swamped with unwanted and heavy traffic. If we don't put it in the
> standard not only will noone implement it but we will never give the
> providers any control over who is querying their servers and how
> frequently.
>
> Right now there is no consensus about this either way since it never seems
> to have been discussed.
>
> Danny
>
>> Karen
>>
>>> -----Original Message-----
>>> From: ntpwg-bounces+karen.odonoghue=navy.mil at lists.ntp.org
>>> [mailto:ntpwg-bounces+karen.odonoghue=navy.mil at lists.ntp.org]
>>> On Behalf Of Harlan Stenn
>>> Sent: Monday, July 09, 2007 0:15
>>> To: mayer at gis.net
>>> Cc: NTP Working Group
>>> Subject: Re: [ntpwg] KISS codes
>>>
>>> Danny,
>>>
>>> In general, I really like your proposal. I haven't said
>>> anything about it because I'm not aware of any reasons it's a
>>> bad idea and that concerns me. I figure there *has* to be
>>> some cases where what you describe inappropriate.
>>>
>>> For how long must a server stop sending packets to the server in this
>>> case:
>>>
>>> a) For kiss codes: DENY, RSTR the client MUST demobilize any
>>> associations to that server and stop sending packets to that
>>> server;
>>>
>>> Is it a good idea to better define the "reduction" mentioned here:
>>>
>>> b) For kiss code: RATE the client MUST immediately reduce its polling
>>> interval to that server and continue to reduce it each time it
>>> receives a RATE kiss code.
>>>
>>> H
>>> _______________________________________________
>>> ntpwg mailing list
>>> ntpwg at lists.ntp.org https://lists.ntp.org/mailman/listinfo/ntpwg
>>>
>
> _______________________________________________
> ntpwg mailing list
> ntpwg at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/ntpwg
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> ntpwg mailing list
> ntpwg at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/ntpwg


-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ntp.org/pipermail/ntpwg/attachments/20070710/bc4bf712/attachment-0001.html