[ntp:hackers] -I, -L, and the new nic/interface config stuff

Todd Glassey tglassey at earthlink.net
Tue Sep 22 16:21:16 UTC 2009

Harlan Stenn wrote:
> Folks,
> Once upon a time folks wanted a way to "not listen" to certain IPs
> and/or interfaces.
This is to allow systems to have multiple interfaces and only provide 
service on some of them rather than ALL of them as the only option which 
is a good idea. It will allow for more controls of the addresses and the 
interfaces used.

Restricting Applications as a part of Security Design
Since its possible today to restrict certain apps to specific interfaces 
and addresses used, the ability to better tune the operations models for 
NTP deployments is a good addition. The question is where to control 
those aspects and features from - i.e. is it NTP? or the Host OS 
Firewall settings? or is it both and if so what portions of the controls 
are relegated to NTP and what to the Host OS FW.

By comparison most of the port restrictions and the IP address 
restrictions can be done in the platform's firewall settings which are 
becoming a common and key part of commercial OS's so a larger question 
has to be answered as to whether any of those control features are 
needed or whether the platform's FW will handle them.

If the intent is to create a reference port of NTP which replaces the OS 
as a stand-alone instance then it makes total sense to have all those 
controls in the NTP instance, but today I dont know of a single instance 
of an NTP appliance which operates in a manner which could take 
advantage of those features and the question becomes one of whether 
adding those will complicate managing systems NTP is one because of the 
potential for policy control loops between the Application (NTP in this 
case) and the policy interfaces on the Hosting OS platform.

Use Case
As to use cases we should be aware that there are instances where a NTP 
service would want to be run on an external port during 'scheduled 
synchronization' instances only - i.e. time windows where a policy to 
test or set that client-NTP instance's TOD. The problem is that NTP has 
to be kept HOT to run properly meaning it needs to be running to keep 
its proper accuracy especially without a reference source and as such to 
periodically reach out and touch its reference server.

So the question is how to allow a security model which supports that - 
do you open the address and port 123 permanently? do you only bind and 
open the address and port when the daemon reaches out to the reference 
source? Why this is the question to ask is that the same Client NTP 
instance may in fact also be a permanent internal NTP instance which 
allows connections from systems on the approved-for-use (internal) 
network as well so this would appear as a NTP instance which was only 
available on one side for the external cal procedures and always 
available internally for sync's of the internal systems.

A typical implementation of this would be a corporate time service 
gateway which was not a posted member of the NTP Pool or public servers 
list as most NTP instances are today. This would allow that NTP instance 
to only be 'visible' when the external sync was happening and no other 

Likewise port scanners which are used by the Evil Masses to detect open 
ports could be dealt with as well. One of the possible solutions (and 
BLU you will get a kick out of this) would be to use the Sun SunScreen 
'invisibility' model for NTP as a possibility too.

Any thoughts?

Todd Glassey
> As I recall (and corrections are welcome)...
> We knew this was gonna be difficult to get right in the config file and
> we knew it was gonna take a while before we had a useful plan.
> In the interim we came up with two partial workarounds.
> One was -L, that said "do not listen to virtual IPs".  The definition of
> a virtual IP was one that had a ':' in the name, which meant it only
> worked on Linux and Solaris boxes.
> The other was -I, that said "listen on the <arg>".
> For better or worse, with -L under this scheme we would ignore any of
> the IPs that "matched", and for -I (in ntp-stable only *one* -I flag is
> allowed) anything that doesn't match is open-read-dropped.
> Now that we are about to release code in 4.2.6 that appears to offer a
> complete mechanism to offer what seems to be adequate to implement all
> of the policy choices of listen|open-read-drop|ignore for interfaces
> and/or IPs, we find there are some corner cases that need to be
> addressed.  To see the scenarios and some discussion, please visit
> https://support.ntp.org/bin/view/Dev/NtpdAndNetworkSockets (and if you
> think you have a use-case that is not covered, please add it).
> First, given that -L only worked for 2 OSes and implemented "ignore"
> policy and -I only supported one instance and implemented "drop" policy,
> is there any reason we should let folks specify the complete interface
> control mechanism on the command line?
> If not, what about completely removing the -I and -L options instead?
> Second, we need to decide what to about interfaces and IPs that are
> *not* covered by any stated directives.  I see the following choices in
> the case where the first "interface" ntp.conf file contans a
> "restrictive" listen directive:
> - use 'nic drop all' before the specified 'listen' directive
> - use 'nic ignore all' before the specified 'listen' directive
> - signal an error
> My belief is that if we use either of the first two we will find vocal
> opponents of whatever choice we make and if we decide our initial
> choicee wass wrong it will be Difficult to change that default later.
> If we use the 3rd choice, we are requiring people to (try to) understand
> the issues well enough to make a good decision.  Granted, we can do our
> best to document this, but hey, documentation can always be better and
> sysadmins may or may not decide to read it.
> So let's discuss...
> ------------------------------------------------------------------------
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.5.409 / Virus Database: 270.13.111/2386 - Release Date: 09/21/09 05:51:00

More information about the hackers mailing list