[ntpwg] KISS codes

[David L. Mills]

Greg,

You might guess that there was a lot of discussion on DoS issues that 
led to the publication cited in my previous message. I'm not so worried 
about the NIST and USNO cases, as they have multiple servers scattered 
over the country and something like the pool scheme might cool things 
off. I am more worried about a possibly broken and widely repliated 
Chinese router or cuckoo clock and most of all a determined terrorist.

I suspect better DoS technology in the network and in the servers will 
be the most effective counterthreat. Telling the terrorist to stop 
sending IEDs is probably not a viable tactic.

You mentioned a probabilistic packet drop, which is equivalent to what 
the telcos call call-gap. Call-gap is designed for national emergencies 
like an earthquake in California. The idea is to withold dial tone under 
conditions of severe nework congestion. How this works in NTP might be 
to roll a random value for each arriving packet and discard it if the 
roll exceeds a threshold depending on load. The problem however is my 
observation that only a handful of abusers are causing almost all the 
volume of attack. The tactic is to find the elephants in the forest and 
shoot them until the forest is safe for mice.

Dave

Greg Dowd wrote:

> A subject near and dear to my heart. The server can have a
> configuration for load limit and start sending kiss codes with either a
> random or specified list. Internal hash trees can sort by load in this
> "panic" mode. Either way, we could migrate away from the client based
> mgmt of a server resource. I'm interested in Dave's feedback on the
> consequences of forcing larger populations into an undersampled state,
> although it is debatable whether a slammed server is providing adequate
> service. This should, however, allow the server to provide the best
> service possible under varying loads. Properly configured clients
> should transition to alternate resources.
>
> Another interest of mine is the ability to detect whether a request
> frame, at least in some mode, is coming from a ntp termination point.
> An example is a sntp client which loads 0.0 into tx. A possibility
> would be something like a high stratum number or an unsynchronized li
> field. This would allow the server to better scale ntp resources.
>
>
> Greg Dowd
> gdowd at symmetricom dot com (antispam format)
> Symmetricom, Inc.
> www.symmetricom.com
> "The current implementation is non-obvious and may need to be improved."
>
>
>
>
> -----Original Message-----
> From: ntpwg-bounces+gdowd=symmetricom.com at lists.ntp.org
> [mailto:ntpwg-bounces+gdowd=symmetricom.com at lists.ntp.org] On Behalf Of
> Brad Knowles
> Sent: Monday, July 09, 2007 9:51 AM
> To: Brad Knowles; anthony.flavin at bt.com; mayer at gis.net;
> karen.odonoghue at navy.mil
> Cc: ntpwg at lists.ntp.isc.org; stenn at ntp1.ntp.isc.org
> Subject: Re: [ntpwg] KISS codes
>
> On 7/9/07, Brad Knowles wrote:
>
>> So, you cut the problem into chunks, and you solve them as best and
>> as quickly as you can.
>
>
> I'm assuming that the server has some intelligence so that when it gets
> enough load that it is sending out a lot of RATEs, it can go into a
> "panic" mode and start sending out KoDs to everyone?
>
>
> On that same line of reasoning, do we want to enforce a mandatory
> exponential backoff for all clients during the initial volley, if they
> don't get responses to their queries? This would help the clients
> automatically reduce the load that they present to sites in a UWisc-type
> case, and hopefully reduce the need for the victim site to be sending
> out KoDs to everyone.
>
> Of course, this would have to be built into both the NTP and SNTP
> standards, otherwise most clients that would be likely to be
> misconfigured to cause these sorts of situations would not incorporate
> this feature.
>
> --
> Brad Knowles <brad at shub-internet.org>, Consultant & Author LinkedIn
> Profile: <http://tinyurl.com/y8kpxu> Slides from Invited Talks:
> <http://tinyurl.com/tj6q4>
>
> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
> _______________________________________________
> 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/c8b9b6a2/attachment.html