[ntp:hackers] Why are we going down this road? Question on listen-on, query-on, -I

Harlan Stenn stenn at ntp.org
Wed May 27 19:12:56 UTC 2009


Brian wrote:
> Can someone please explain to me why we even thinking about doing
> these features?

The old code uses -I and it has been demonstrated to be "insufficient":

We have been listening on every IP we find since day-0, and the
'restrict' code implements "open-read-drop".

Some people strongly want to add the ability to "don't even open" some IPs.

These are local policy choices.

There are people out there who, with the current model, *cannot* open
all the IPs because there are too many.

Bumping up against this problem requires another local policy choice
(which may be a "default" choice).  The current default choice is "ntpd
exits with an error message of there are too many IPs.

It seems the answer is to provide a mechanism to provide, as simply and
cleanly as possible, a way to implement these policy choices for the IPs
on a machine (open-listen, open-read-drop, do-not-open).

> It appears that we are continually increasing the layer violations for
> no better reason than "we can".

Wait for it...

> I can see having these layer violations for features like interleave
> mode, because it furthers the NTP mission, to provide better time
> synchronization. But all of these other changes do not do that at all.

Which other layering violations are you talking about?

> We should take a deep breath and think about whether or not this trip
> is really necessary. Personally, I don't think it is.

Do you have any suggestions on how we handle the "what do we do with
each IP on the system"?  As I recall, we *cannot* just use a wildcard
socket because the authentication code(?) requires that we know what
address an incoming packet was sent to, and we must also send any
replies to those packets from *the* correct address.  (I suspect I could
have done a better job on this paragraph if I did a day or few of
research, instead of just writing it.)

I agree that this might all get much simpler if we re-wrote the current
ntp.conf "syntax" or "specification".

And I'll point out that http://support.ntp.org/Dev/NewNtpConfFormat has
been available (and open for comments) since 30 Aug 2004, and
support.ntp.org/Dev/NtpdAndNetworkSockets has been available (and open
for comments) since 01 Jan 2008.

These pages were created after there was discussion on this list, and I
wanted a single place to collect the feedback for these issues.  I have
also repeatedly mentioned these pages on this list.

H


More information about the hackers mailing list