[ntp:questions] zeroconf for ntpd?
ibuprofin at painkiller.example.tld
Thu May 24 01:00:35 UTC 2007
On Tue, 22 May 2007, in the Usenet newsgroup comp.protocols.time.ntp, in
article <87646kvmaa.fsf at ancho.wsrcc.com>, Wolfgang S. Rupprecht wrote:
>I just watched a Google Talk series video about Bonjour, their
The Apple Rendezvous (renamed 'Bonjour' as a result of trademark
violation), and the Microsoft copy were intentionally designed with NO
security functions. The concept was based on the earlier AppleTalk and
NETBEUI protocols for isolated networks. Rendezvous (officially
introduced in OSX 10.2) is based on ZeroConf work that goes back to
1998. Microsoft actually included this security hole in Win98, after
discovering that people were screwing up the DHCP services. Rather than
fix the problem, we'll just grab an IP address out of our ass and "make
it work". Were you to look at the draft RFCs (start with
draft-ietf-zeroconf-ipv4-linklocal-01.txt from 11/24/2000) it glosses
over any security issues until the fourth revision (07/19/2001) when
the most generic warning was included. By the time the last draft was
released (draft-ietf-zeroconf-ipv4-linklocal-17.txt in July 2004), the
security section (Section 5) was over a page long. It got even longer
in the official version (RFC3927).
>Basically they use link-level multicasts to figure out who is out on
>the local net and who can do what. They even go so far as assigning
>IP addresses and hostnames via this cloud of participating hosts.
except that the Apple and Microsoft versions of the name/service
resolution protocols are not compatible (see Apple's
draft-cheshire-dnsext-multicastdns-06.txt verses Microsoft's
draft-ietf-dnsext-mdns-47.txt which appears to have been adopted
after only 47 revisions as RFC4795 - an "Informational" document, not
any form of standard). Both services have monstrous security holes
that they suggest using external authentication to reduce the risk.
The Apple document specifically warns not to include a 'search'
directive in /etc/resolv.conf, while the Microsoft document suggests
only allowing unqualified hostnames (without a '.' in the name) but
intentionally avoids actually testing for this hole - the "make it
work" principle trumps security every time.
I'm sure the users who can't get DHCP working (never mind using a
static address) will have no difficulty setting up the certificates
on all participating systems.
>Getting away from having users edit config files (after reading a
>half dozen man pages) seems like a good thing.
Why are you allowing your users to screw with system configuration
files? Actually, I'll admit ZeroConf makes my job easier. If any of
the network switches or routers detects a 169.254.x.x packet, a script
sends an alarm to the NOC and Security Office, identifying an intruder.
This brings out the thundering herd of "People Who Do Not Smile". As we
know where each switch port terminates, we can usually have people asking
the intruder WTF in under three minutes.
More information about the questions