SINGLESOCK - How much to strip away?
Eric S. Raymond
esr at thyrsus.com
Sat Jun 2 14:22:27 UTC 2018
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
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
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.
More information about the devel