SINGLESOCK - How much to strip away?

[Eric S. Raymond]

Mark Atwood via devel <devel at ntpsec.org>:
> I still want to strip it all and delegate it to iptables, case OMEGA.
> 
> But I do understand the pushback against that from GEM, and have been
> thinking about it for the past few days.
> 
> As I type and think: one of the fundamental problems with having longrunner
> daemons try to keep track of addresses, address masks, and interface names
> is that interfaces can go down, come up, get renamed, and have address
> masks added and removed from each, and trying to keep track of that in
> userspace is a nightmare.   Sysadmins are used to having to bounce a
> database server when listener interface has an address event, but bouncing
> ntpd is much less okay.

That - "bouncing ntpd is much less okay" - is a telling point that
hadn't occurred to me.  I'm not much of an admin and am not used to
having to handle these large-site problems.  Please everyone bear that
ignorance in mind; it may mean you need to beat me over the head with
facts you think are obvious.

> As I type and think more, I ask, "What does Chrony do?", and I look at [
> https://chrony.tuxfamily.org/doc/3.3/chrony.conf.html].  It has a
> "bindaddress" directive, which uses IP address, not interface name.  And
> only one bind address can be specified.  It freely admits that that means
> Chrony is not the correct solution for serving down multiple controlled
> interfaces at once.   Very simplifying, but not what we want.
> 
> This reinforces my decision.  Rip it.  Maybe in the future we can carefully
> build back up to case Gamma.

I thank you *very much*, Mark. This kind of firm leadership on the
product-strategy level makes it easier for me to do my job, and I
appreciate that a lot.

I'm hearing assent to this direction from Hal and me, and a slightly
qualified assent from Gary.  I hope we hear from Matt, too.

I'm going to take this as direction to start by ripping out the
interface directive in ntp.conf; that's orthogonal to the rest of this
mess because it's restrictive and default behavior without it won't
change.

We can deal with -I and -L and multi-binding behavior in a later step.
I'm inclined to think we ought to scrap -I and -L and support a
bindaddr directive (to make the chrony fans happy) allowing multiple
IP addresses (to make Gary happy :-)).  But we don't need to commit to
that decision yet, and I need to understand virtual IPs (that is, why
-L differs from -I) better before we do.

There's an implementation issue with SINGLESOCK.  We can't
actually go to single socket unless we can get the source address of a
packet, so we know where the other end of the association
is. IP_PKTINFO turns out not to be fully portable.  (It is disturbing
that some BSD man pages falsely claim to support it.)

I've turned up the following, at

https://k5wiki.kerberos.org/wiki/Portability_research

This table combines their table with the footnotes.

Platform	IPV6_PKTINFO 	IPV6_RECVPKTINFO	IP_PKTINFO
Linux 2.6.32	yes		yes			yes
Solaris 10	yes		yes			no
Solaris 11	yes		yes			yes
FreeBSD 8.1-1	yes		yes			no*
Hurd-0.3	yes		no			no
OSX 10.9	yes		yes			yes
AIX 6.1		yes		yes			no
HP-UX B.11.11	yes		yes			no
NetBSD		?		?			yes (2013)

* FreeBSD still does not implement IP_PKTINFO, but implements an
  alternative using IP_RECVDSTADDR.

It looks like we're OK (wrapper code that uses the FreeBSD alternative
should be trivial) but I think testing on our target platforms is
indicated before we commit to this.

Hal, can you check the assertion about FreeBSD?  Do we have a NetBSD
system to test on?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.