[ntp:hackers] Cool new stuff

Frank Kardel kardel at ntp.org
Mon Jul 24 16:14:38 UTC 2006

David L. Mills wrote:

> Frank,
> 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 - 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 
true peers).
The interface structure denoting loopback address is referenced in 
peer->dstadr. It is configured only for true refclock
( 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
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 
level 4.

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

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

Why would a peer be unreachable? Network partition? Server down? 
Interface change?
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 
> removed.
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 mailing list