[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ntp-bugs
Subject:    Re: [ntp:bugs] Mark Knight: ntpd receive port validation
From:       "David L. Mills" <mills () udel ! edu>
Date:       2002-01-09 20:53:49
[Download RAW message or body]

Harlan,

The rfc1305 literally took a working year from my life. Amending that
spec to agree with current v4 would take just as long, and piecewise
amendments are not in the cards. That rfc was the result of careful
testing the actual implementation against the spec and formally
modelling it in pseudocode. I wrote a special purpose simulator to
verify its behavior, but the simulator code was not exactly the code
used in the implementation.

You should also understand my attitude when the IAB refused to allow
PostScript, even though the document was written before the ASCII-only
edict. This is why NTP is STILL in draft standard status after ten
years, since I refused to provide it in anything other than Postscript
and ASCII publisher source. I have since forged a gentleman's agreement
with the IETF that would provide actual Postscript documentation with
ASCII pointer documents. My plan is PDF and damn the torpedoes.

But, ten years ago a definitive specification was possible and
noncontroversial. I don't think so today; witness the present
discussion. There is a book, largely completed, which is ahead of the
spec on my queue anyway.

One of my grads has completed a first cut for an interesting test
article. He dropped the NTPv4 code on a descrete event simulator, which
makes it possible to test things that take days to test and debug in
reality, especially wierd combinations of poll interval and initial
frequency and time errors. He uses the NTP distribution code intact,
except for some I/O fiddling and systime.c intrusion. He models the
clock warble as per my Trans. Comm. paper a few years back. Modelling
the network will be an adventure, especially for things like huffpuff. I
might be asking for rawstats from folks who report malapprop behavior,
so I can feed the simulator to verify.

When the thing reaches maturity, I'll put it on the web. Then I can say
whatever folks want to change, verify it works in the simulator. I have
in mind things like huffpuff, clock selection and clustering, etc. and
etc.

Dave

Harlan Stenn wrote:
> 
> How is this for a summary:
> 
> - The behavior in question deals with ntp4.
> - There is no ntp4 protocol RFC (near as I can remember).
> - rfc1305 talks about ntp3 protocol.
> - Once upon a time, machines were expensive and behavior was less
>   hostile so it was understandable to trust/expect protocols that
>   relied/enforced source port restrictions.
> - Some People may still want this behavior (restricted source ports).
> - Some People do not want this behavior (restricted source ports).
> - we are free to do what we want in ntpv4 because there is no RFC
>   (right?)
> - the problem is that while it may be "local" policy on what source
>   ports to allow, it's remote policy on what gets sent, and a PAT
>   firewall may spontaneously get in the way of things
> - There is no "cause of action" if a remote site says "Hey, you accepted
>   a packet from me that came from the wrong source port!".
> 
> and this for a plan:
> 
> - anybody who feels like it can do the work to amend rfc1305 to change
>   the wording of the relevant source port restriction (ie, not Dave).
> 
> - I implement a new configure option, say:
> 
>   --enable-rfc1305-port-restriction
> 
>   defaulted to "disabled" because as we've now seen Dave's patch to
>   enforce this was only recently installed and, after all, there is no
>   ntp4 protocol RFC that requires this, it's part of the ntp3 protocol
>   spec (right?).
> 
> Does this seem to be a good plan?
> 
> Harlan
[prev in list] [next in list] [prev in thread] [next in thread]