Subject: [ntpwg] KISS codes

From: stenn at ntp1.ntp.isc.org (Harlan Stenn)
Date: Mon, 09 Jul 2007 04:14:44 +0000

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

---

From: karen.odonoghue at navy.mil (Odonoghue, Karen F CIV NSWCDD, W13)
Date: Mon, 9 Jul 2007 02:59:15 -0500

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

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.
> 
> _______________________________________________
> ntpwg mailing list
> ntpwg at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/ntpwg
>

---

From: stenn at ntp1.ntp.isc.org (Harlan Stenn)
Date: Mon, 09 Jul 2007 08:28:21 +0000

Karen,

> current practice.

I believe Danny's change does not represent current practice.

The problem is that current practice is ... lame (at best) in this
regard and there needs to be, IMO, a way for a server to tell clients to
"go away" where there is better instruction that the clients really
should listen and do what it is told.

> Along that vein, would it make sense to change

SHOULD could be arguably better, and if that's the way we go I expect
that RSN we'll want to upgrade that word to a MUST.

And I would love to hear back from more folks on this one, as I suspect
that MUST really is the right way to go.

But if we're gonna make a change here, I can see the reason for taking
the conservative approach first.

H
--

---

From: mayer at gis.net (Danny Mayer)
Date: Mon, 09 Jul 2007 10:57:25 -0400

> 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

---

From: mayer at gis.net (Danny Mayer)
Date: Mon, 09 Jul 2007 11:03:39 -0400

> I believe Danny's change does not represent current practice.

Correct. Certainly the reference implementation doesn't implement it but
that shouldn't prevent us adding it to the RFC and we really should
implement this no matter what happens to the standard.

> that RSN we'll want to upgrade that word to a MUST.

Revisiting RFC's is hard and takes a long time. Put it into the
standards now as a MUST and we have a chance of getting people to
implement it. Make it a SHOULD means that it will never happen as it is
after all extra code that needs to be written.

> the conservative approach first.

I don't know which approach you consider to be conservative here.

Danny

---

From: anthony.flavin at bt.com (anthony.flavin at bt.com)
Date: Mon, 9 Jul 2007 16:37:00 +0100

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

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
>> ntpwg at lists.ntp.org https://lists.ntp.org/mailman/listinfo/ntpwg
>>
>

-------------- 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/20070709/86963699/attachment.bin

---

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

>  I believe Danny's change does not represent current practice.

If our sole purpose is to document current practice in the code, then 
Danny's proposal may not reflect what is done in the code today. 
However, in that case, we can quickly fix the code.  ;-)

If our purpose is to document what the current practice SHOULD be in 
the code, then IMO Danny's proposal most definitely reflects what 
should go into the standard.

As far as I'm concerned, the choice is yours.  But if you choose to 
document exclusively that which is done today in the code, don't be 
surprised if the code changes tomorrow to reflect what Danny has 
proposed.

-- 
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: mayer at gis.net (Danny Mayer)
Date: Mon, 09 Jul 2007 14:04:08 -0400

> requests, how are you going to determine who to send the codes to?

I disagree. If the code already knows enough to send out any of these
KISS codes then you have the right to expect the clients to examine the
KISS codes. The fact that the reference implementation may only keep 600
past client addresses is a red herring. The fact that you get back KISS
codes in the first place says that it's doable. One such use might be to
set up an address blacklist which doesn't require existing client
information.

However, I'm not referring to the implementation, I'm referring to the
protocol. If you receive a KISS code, you should examine it to see what
it says and take action based on what it tells you.

Danny

---

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

Guys,

For record, the ntp-dev stops sending packets under conditions where 
resending is guaranteed to be unsuccessful; in particular with kisscode 
DENY. A client kissed with that code should go on-hook immediately.

It doesn't make a lot of sense for the program to do anything for RATE, 
as the program cannot send at rates likely to set off such a code. It 
does back off eventually to 1024 s. But, the real monster can be a 
misguided implementation in 750,000 routers. See: 
http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti04.pdf.

I will guarantee this situation will occur soon in a router designed and 
built in China by a Mandarin speaker that has read neither RFC 4330 nor 
the forthcoming NTPv4 specification. RFC 4330 had a lot of stuff 
intended as best practices for a NTP client. I fear much of this will be 
lost should that document be deprecated by the spec.

Dave

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

---

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

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:

> ------------------------------------------------------------------------
>

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

---

From: mayer at ntp.isc.org (Danny Mayer)
Date: Tue, 10 Jul 2007 08:36:27 -0400

> DENY. A client kissed with that code should go on-hook immediately.

That means that at least the server is sending them. The client side of
the reference implementation does not do anything with the codes as yet
as far as I recall. It's well worth implementing.

> does back off eventually to 1024 s.

The reference implementation does, but this is meant to address other
implementations. This reminds me that I should go back and take a look
at what the draft says about the frequency of sending NTP request
(client) packets and make sure that's a strong statement.

> But, the real monster can be a

And that's what these recommendations are designed to start addressing.
It will never fix the problem and the only thing we can do about it is
yell "non-RFC compliant" as the network compliance police is always on
coffee break. What it DOES do is to give any victim ammunition to sue
the pants off the errant manufacturer and that is a much more viable goal.

> lost should that document be deprecated by the spec.

In that case we should not deprecate RFC 4330. or incorporate parts of
it in this draft or provide a BCP document to replace it.

Danny

---

From: mayer at ntp.isc.org (Danny Mayer)
Date: Tue, 10 Jul 2007 08:41:37 -0400

Dave,

That PDF mentions something called a Call-Gap scheme. What is that? Is
it documented and is it implemented in the reference implementation?

Danny

---

From: mills at udel.edu (David L. Mills)
Date: Tue, 10 Jul 2007 14:43:20 +0000

Danny,

I beg to differ. The client side does respond to DENY; but, as I said in 
a previous message, it doesn't make sense to respond to RATE, as the 
server side is so conservative. On the other hand, it is in principle 
possible to evoke RATE in the present implementation if the client 
configures burst mode with a poll interval of 16 or 32 s. Is that what 
you had in mind? That's easy to fix by putting limits in the 
configuration' I set the parameters so that it would be possible to test 
the server response.

Dave

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

---

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

Danny,

I explained call-gap in another message on this thread which you will 
see. For reasons explained in another message, a random early drop (RED) 
scheme like call-gap is inappropriate as the mission is to shoot the 
elephans until the forest is aafe for mice.

Dave