Subject: [ntpwg] KISS codes

From: brad at shub-internet.org (Brad Knowles)
Date: Mon, 9 Jul 2007 11:27:23 -0500

On 7/9/07, <anthony.flavin at bt.com> wrote:

>  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?

You solve that problem 600 clients at a time.  You could make the 
cache bigger, but then that just increases the problem of how much 
data you have to store, and how much impact on the server you can see 
from ntpd, and no matter how big you made the cache it would always 
be possible to exceed its size.

So, you cut the problem into chunks, and you solve them as best and 
as quickly as you can.

-- 
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

---

From: brad at shub-internet.org (Brad Knowles)
Date: Mon, 9 Jul 2007 11:50:35 -0500

>  So, you cut the problem into chunks, and you solve them as best and

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.

---

From: GDowd at symmetricom.com (Greg Dowd)
Date: Mon, 9 Jul 2007 10:11:55 -0700

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

>  So, you cut the problem into chunks, and you solve them as best and  

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

---

From: mills at udel.edu (David L. Mills)
Date: Tue, 10 Jul 2007 03:02:00 +0000

Brad,

I'm not sure you need to say anything about exponential backoff. The 
polling scheme which most implementers would choose is inherently 
exponential.

A sensible server needs to enforce both an average rate limit and a peak 
rate limit. The reference implementation allows an average headway of 5 
s and a peak headway of 1 s, an punishes the exceptions. These 
parameters allow an 8-packet burst every 64 s, but not 32 s and 16 s.

Not every implementation might agree on these parameters, but whats to 
stop somebody from setting them to one hour and on day? Spacecraft links 
maybe?

Dave

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

---

From: mills at udel.edu (David L. Mills)
Date: Tue, 10 Jul 2007 03:25:36 +0000

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

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

---

From: anthony.flavin at bt.com (anthony.flavin at bt.com)
Date: Tue, 10 Jul 2007 08:34:07 +0100

That doesn't work.

For a busy server the client list is being updated all the time, so the
list is not static. So how do you identify which clients are misbehaving?

Tony

-----Original Message-----
From: Brad Knowles [mailto:brad at shub-internet.org] 
Sent: 09 July 2007 17:27
To: Flavin,AJ,Tony,XGH78 R; 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, <anthony.flavin at bt.com> wrote:

> 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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5938 bytes
Desc: not available
Url : https://lists.ntp.org/pipermail/ntpwg/attachments/20070710/1f7ac556/attachment-0001.bin