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

tglassey tglassey at glassey.com
Wed Sep 23 16:54:20 UTC 2009

Dave Hart wrote:
> On Tue, Sep 22, 2009 at 9:42 AM, Harlan Stenn wrote:
>> 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?
> My first choice would be no, keep -I and -L functionality essentially
> the same (with both implementing ignore).  Anyone who prefers
> listen-read-drop can start their rules in ntp.conf with an alternative
> catchall rule:
> nic drop all
> That will prevent the implicit "nic ignore all" rule from ever coming
> into play.
Steve K no doubt you and Vix will love this commentary - and since I am 
anti-ISC (but only from a political standpoint),  its very odd for me to 
be saying this but... Aren't these same issues pertinent to DNS, DHCP 
and Syslog too? i.e. we need to be able to have multiple interfaces on a 
system which we uniformly control the access to the data from. So then 
if that is true, and we are building these on the ISC's custom I/O 
libraries which are already a part of those other tools, then why 
shouldn't we now go the next step and that create common use model 
across all four of them as long as all of this work is going to be 
hosted at the ISC?

Again, don't get me wrong - I still have political issues with the ISC, 
but from a technical standpoint it probably makes sense that all of 
these key protocols (which will all be operated under a common or 
similar security profile) have the same setup and same configuration 
guidelines for each so that uniform controls for services can be put in 

Anyone seeing a unified services interface for all of these???

BTW check the archives - I suggested this some months ago and was 
slammed for it then but hey... times change right


>> If not, what about completely removing the -I and -L options instead?
> I think the folks who care about having ntpd listen on a subset of
> available addresses are largely going to be usinig ntp.conf already,
> and that is now the best place to manage listen/ignore/drop behavior.
> The command-line switch approach is more relevant when all
> configuration can be done via the command line, with no ntp.conf used,
> as is the case for some broadcastclient configurations.  So I would
> actually like to see -I and -L deprecated in the documentation now in
> favor of using the configuration file rules, with an eye towards
> reclaiming the -I and -L short option names for something else
> someday.
>> 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
> In my opinion we shouldn't fiddle with deciding if the first explicit
> rule is restrictive, but should simply always insert a default first
> rule just before inserting the first explicit rule.  I don't see any
> benefit to doing differently depending on the first rule's effect.
>> 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.
> As I mentioned in a bug 1315 comment a few minutes ago, anyone who
> doesn't like the default rule doesn't have to use it.  They simply
> need to effectively replace it with their own first "drop all" or
> "listen all" rule.  As the last matching rule wins, any "all" rule
> stops all searches from testing earlier rules such as the implicit
> "nic ignore all".  There is an exception from "all" rules for loopback
> addresses, which are excluded so that "ignore all" doesn't imply not
> listening on the and ::1 addresses used by local ntpq and
> ntpdc.  Also, is always listened on despite any rules to the
> contrary, as ntp_intres depends on it for returning addresses resolved
> from DNS names.  ::1 can be explicitly managed with "nic ignore ::1",
> and the same will be true for one ntp_intres is improved.
>> 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.
> I would really be disappointed if we require people to understand the
> two flavors of "don't listen" before we allow them to configure ntpd
> listen behavior using the preferred mechanism.  We should have a
> single default rule, preferably "ignore all", but "drop all" would be
> far better than requiring prior configuration of the default before
> any other listen configuration.
> Cheers,
> Dave Hart
> _______________________________________________
> hackers mailing list
> hackers at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/hackers
> ------------------------------------------------------------------------
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.5.409 / Virus Database: 270.13.112/2388 - Release Date: 09/22/09 05:51:00

More information about the hackers mailing list