[ntp:hackers] Cool new stuff
kardel at ntp.org
Mon Jul 24 16:14:38 UTC 2006
David L. Mills wrote:
> I see your point, but I really don't want to see a refclock address or
> loopback address for that matter change,
if you mean refclock address being from 127.127.0.0/16 - it definitely
won't and can't. This is hardcoded in the daemon and artificial - we
both know that.
The peer->srcadr is completely unchanged - for all peers (refclocks and
The interface structure denoting loopback address is referenced in
peer->dstadr. It is configured only for true refclock
(127.127.0.0/16) peers. These never send or receive via the loopback
link (also an old story) not change here either.
> since lots and lots of bad things would happen if they did.
There is nothing to worry about - old semantics have not been changed.
If the interface setup is static so will
the interface bindings be. The scan code is build around the concept of
tracking only changes.
Dave, you may have seen a message like: set_peerdstadr(127.127.x.y):
change interface from <null> to 127.0.0.1
This message is generated very early in the newpeer configuration
process and just documents that the
refclock picked up the correct localhost address. As long as
nobody(root) messes with the localhost
interface configuration in a non standard way the binding will stay
fixed. This could have been the line
worrying you. Now you will see those initialization messages at debug
Differences wrt/ localhost come in when administrators start to
massively fiddle with the system. But even these
effects would hit old ntpd if it was restarted on such an insanely
configured system (like loopback being 22.214.171.124).
Why? Because the dynamic interface code enforces the invariant that it
sets up the interfaces like it would
set them up when started - with the same interface scan algorithm that
was used before. So
an ntpd with dynamic interface code behaves interface wise at any time
just like a *freshly* started non-dynamic
ntpd. So all assumptions/rules that were valid before dynamic interfaces
are still valid after but without losing
all other state that a re-start would lose when the interface
> Is it the intended result of the scan to bring up a new address when
> the ISP changes it? Doing so by default is a serious security
> vunerability. The capability should not be provided by default and the
> user should understand and accept the risk.
discussing client via dial-in mechanism (dynamic IP address assignment
for the client):
1) no ISP can remotely change your IP address after set up (or you would
have a security hole right there already)
2) an ISP could disconnect you forcing you to re-connect (and that might
give you a new IP address -
this is the famous "Zwangstrennung").
After re-connect the system may or may not get a different IP address.
If it stays the same:
The old daemon is likely to function (subject to OS strategies
wrt/ socket and interfaces being up/down).
If the IP address has changed:
The non dynamic ntpd has its peers still connected to a socket
bearing the old (now invalid, possibly re-assigned) address.
At best the OS would not send these pakets from ntpd:transmit() at
all because they are not matching a local interface address,
BUT usually these pakets are sent with the old invalid local
address provoking a server reply to the old (now invalid and
possibly assigned to another host) address. Some OS would even
terminate the socket with an error - old ntpd has no
provision for such a case but to ignore it.
This looks more like a DOS scenario against the old daemon and if
these pakets are sent out it looks like forged IP source addresses
to others outside. Sending these pakets from an old socket might
be considered an OS bug - different story. These pakets may therefore
be blocked at some other point in the IP infrastructure (ingress
In any case the non-dynamic daemon will not get any replys (maybe
errors on sendto if it is lucky). This situation is unlikely to
heal by itself unless the previous address is set again. Is this
security by paket-filter/forged-IP-source address ?
When the non-dynamic daemon is restarted after re-connecting the
initialization code will pick up the correct local addresses
during startup. This is at the expense of losing all other state (except
for the drift value), but connectivity is re-stored because
the correct local addresses are picked up. So the failure modes are:
old daemon: lose connectivity and possibly pollute the net with
'forged' src ip address pakets (if the OS/network allows that)
new daemon: implicitly re-bind *local* address associations - keeps
connectivity, sends correctly generated pakets and
hopefully restarts the autokey dance. This host is a new
citizen on the block after all.
Given that - I wonder why an (automatic) restart would be safer security
Secondly the old (and new) daemon tries very hard to get hold of all
interfaces so only one daemon can fiddle with the
clock and the port 123. Not re-scanning would defeat this purpose and
leave new interfaces ignored.
So if changing the IP address and tracking that by default would be
risky security wise, why is letting ntpd sit there in the dark
and possibly sending wrong pakets out to the network not (counting DOS,
pollution as security risk)?
What is the security risk you refer to exactly and why would a restart
of the old daemon not have that problem?
> It would seem the scan interval, apparently fixed at a few minutes,
> could be refined.
-U <seconds> switch.
> It doesn't make sense to scan every few minutes if the poll interval
> is 1024 seconds or even 36 hours.
On systems where interface change notification exists (*BSD, Windows,
Solaris AFAIK) this can be made
completely on demand (currently timeout based scans run as a
fallback). On other systems the re-scan costs
some cpu cycles but does not change anything if it is not needed. The
re-scan time could be derived from
the lowest next poll time stamp - 1 of all peers if cycles are
completely at premium - I doubt that that is the case.
> How about a per-association configuration bit that operates only when
> the server becomes unreacnable and does a scan initiated by the poll
Why would a peer be unreachable? Network partition? Server down?
Unreachable can have many causes. The interface scan code is in the
perfect position to
find solid reasons for a network disconnect from the ntpd point of view
and is able to rectify that if allowed to, even proactively.
Also several peers bind to a single interface. Would we process peer
re-binding one by one - would some peers be stuck
on the old address if they are not allowed to pick up new local
addresses? That looks pretty strange to me.
perr grouping on interfaces is a function of the routing table and thus
dependent on network topology.
What differentiates peers bound to the same local interface to be
allowed to pick up new addresses and to be
forbidden to. What would the configuration rules be?
To me if an interface (= local address) is gone - it's gone - it doesn't
belong to the host any more using the old
address does not achieve anything. After losing a local address the
pakets need to find a new way to their destination
- this is usually via another interface (=local address) thus a
re-binding of the peer to the correct interface is needed.
> As for the debug display, I am only concerned about the -d level.
> Informally, I have used the -d -d level for things that happen once or
> at relatively long intervals. The stuff at the -d -d -d level and
> above are there only for emergencies and until the stuff is eventually
The debug topic should be a story from the past unless I get a new
message from you. I seem to have picked the right level to
get those messages out of your way.
More information about the hackers