zeroconf for ntpd? - comp.protocols.time.ntp

I just watched a Google Talk series video about Bonjour, their zero-configuration hack. 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. Getting away from having users edit config files (after reading a half dozen man pages) seems like a good thing. It looks like quite a bit of work went into making ntpd do some of the same things. Now that multicast no longer binds to only the first interface it finds, it looks like it may almost be possible to deliver an ntp config file that "just works" yet doesn't beat up the pool servers too much. Can folks help me flesh this out? Will this work? /etc/ntp.conf: restrict default nomodify notrap nopeer restrict 127.0.0.1 restrict -6 ::1 broadcast ff02::101 # ipv6 link-local multicast broadcast ff05::101 # ipv6 site-local multicast broadcast 224.0.1.1 ttl 1 # ipv4 multicast orphan 5 multicastclient ff02::101 # ipv6 link-local multicast driftfile /var/lib/ntp/drift plus on the first 2 hosts only: server 0.fedora.pool.ntp.org dynamic server 1.fedora.pool.ntp.org dynamic server 2.fedora.pool.ntp.org dynamic Any bright ideas of figuring out quickly if the cloud needs to grow a few external connections? The big hammer seems to be to parse the 'ntpq -pn' output with a shell script and then add the pools servers at runtime if nobody in the cloud has any external pool links yet. Ideas? Comments? -wolfgang -- Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/ Hints for IPv6 on FC6 http://www.wsrcc.com/wolfgang/fedora/ipv6-tunnel.html

Wolfgang, "Will this work?" It does work. It's called manycast and has been working with some refinements for several years. Dave Wolfgang S. Rupprecht wrote: > I just watched a Google Talk series video about Bonjour, their > zero-configuration hack. 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. Getting away from having users edit config files > (after reading a half dozen man pages) seems like a good thing. > > It looks like quite a bit of work went into making ntpd do some of the > same things. Now that multicast no longer binds to only the first > interface it finds, it looks like it may almost be possible to deliver > an ntp config file that "just works" yet doesn't beat up the pool > servers too much. > > Can folks help me flesh this out? Will this work? > > /etc/ntp.conf: > > restrict default nomodify notrap nopeer > restrict 127.0.0.1 > restrict -6 ::1 > broadcast ff02::101 # ipv6 link-local multicast > broadcast ff05::101 # ipv6 site-local multicast > broadcast 224.0.1.1 ttl 1 # ipv4 multicast > orphan 5 > multicastclient ff02::101 # ipv6 link-local multicast > driftfile /var/lib/ntp/drift > > plus on the first 2 hosts only: > > server 0.fedora.pool.ntp.org dynamic > server 1.fedora.pool.ntp.org dynamic > server 2.fedora.pool.ntp.org dynamic > > Any bright ideas of figuring out quickly if the cloud needs to grow a > few external connections? The big hammer seems to be to parse the > 'ntpq -pn' output with a shell script and then add the pools servers > at runtime if nobody in the cloud has any external pool links yet. > > Ideas? Comments? > > -wolfgang

"David L. Mills" <mills@udel.edu> writes: > "Will this work?" It does work. It's called manycast and has been > working with some refinements for several years. Dave, Thanks. I did notice it again on your html pages. Last time I tried to play with it the instructions were too confusing for me to figure out how to get it to work. Any chance you could point me at a golden set of config files I could try to get the various distributions to include? My hope is to have a set of config files that some group like Fedora could distribute in lieu of their current one which sets up 3 unicast associations between each client system and some poor overloaded pools server. -wolfgang -- Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/ Hints for IPv6 on FC6 http://www.wsrcc.com/wolfgang/fedora/ipv6-tunnel.html

Wolfgang S. Rupprecht wrote: > "David L. Mills" <mills@udel.edu> writes: > >> "Will this work?" It does work. It's called manycast and has been >> working with some refinements for several years. > Thanks. I did notice it again on your html pages. Last time I tried > to play with it the instructions were too confusing for me to figure > out how to get it to work. Manycast uses Autokey or Symmetric Keys unless authentication is explicitly disabled. In this example Symmetric Keys will be used. # Minimal ntp.conf for Manycasting Client (on 224.0.1.1) driftfile /var/lib/ntp/ntp.drift keys /etc/ntp.keys trustedkey 1 requestkey 1 controlkey 1 manycastclient 224.0.1.1 key 1 # uncomment the following line for a mesh-node # manycastserver 224.0.1.1 # Minimal ntp.conf for Manycasting Server (on 224.0.1.1) driftfile /var/lib/ntp/ntp.drift keys /etc/ntp.keys trustedkey 1 requestkey 1 controlkey 1 manycastserver 224.0.1.1 # server lines for your ref-clock(s) go here # Sample /etc/ntp.keys for above config files 1 M password > My hope is to have a set of config files that some group like Fedora > could distribute in lieu of their current one which sets up 3 unicast > associations between each client system and some poor overloaded pools > server. Manycasting uses network broadcast or multicast addresses for server detection. While this is trivial on a LAN or WAN, manycasting over the Internet will require ubquitous multicast support. -- Steve Kostecke <kostecke@ntp.isc.org> NTP Public Services Project - http://ntp.isc.org/

Steve Kostecke <kostecke@ntp.isc.org> writes: > <config files> Thanks! I'll have a go at setting it up here. > Manycasting uses network broadcast or multicast addresses for server > detection. While this is trivial on a LAN or WAN, manycasting over the > Internet will require ubquitous multicast support. In theory, IPv6 is available to anyone via the free, anycast 192.88.99.1 6to4 tunnel servers. I'm told that multicast is so wired into IPv6 that the ISP's can't screw it up this time. So in theory, it should be possible to do some kind of expanding multicast search now. I notice that ntp.isc.org does have an AAAA record and answers ntp queries on its IPv6 address. I wonder if the powers that be would be willing to allow it to be a IPv6 multicast server. If I understand things correctly that would require transmitting on ff0e::101, the global multicast address with the 0x0101 ntp group id. Anyone know what he rules of the road are for talking on a global multicast? Is it essentially CB radio and one just keys the mike and starts blabbing? -wolfgang -- Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/ Hints for IPv6 on FC6 http://www.wsrcc.com/wolfgang/fedora/ipv6-tunnel.html

"Wolfgang S. Rupprecht" <wolfgang.rupprecht+gnus200705@gmail.com> writes: > I'm told that multicast is so wired into IPv6 that the ISP's can't > screw it up this time. After quite a bit of googling, I'm beginning to realize that this is probably 100% wrong. Nothing of any note seems to have changed with respect to Internet-wide multicast. -wolfgang -- Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/ Hints for IPv6 on FC6 http://www.wsrcc.com/wolfgang/fedora/ipv6-tunnel.html

Wolfgang S. Rupprecht wrote: >"Steve Kostecke" wrote: > >> Manycasting uses network broadcast or multicast addresses for server >> detection. While this is trivial on a LAN or WAN, manycasting over >> the Internet will require ubquitous multicast support. > > I notice that ntp.isc.org does have an AAAA record and answers ntp > queries on its IPv6 address. I wonder if the powers that be would be > willing to allow it to be a IPv6 multicast server. Multicast and Manycast modes are completely different; I believe that you may be confusing the two. Multicast: * A Multicast server sends an NTP packet to the multicast address every 64 seconds. * A Multicast client listens on the multicast address for an NTP packet * Setting up the Multicast association involves a brief unicast phase (during which the authentication is set up and the broadcast delay is calculated). Once the unicast phase is complete the association switches to multicast and the reverts to listening for the NTP packets on the multicast address. Manycast: * A Manycast server waits to be discovered by a Manycast client. * A Manycast client probes the multicast / broadcast address to discover Manycast servers. * Once the Manycast client locates an eligible Manycast server a unicast association is established. -- Steve Kostecke <kostecke@ntp.isc.org> NTP Public Services Project - http://ntp.isc.org/

Steve Kostecke <kostecke@ntp.isc.org> writes: > Multicast and Manycast modes are completely different; I believe that > you may be confusing the two. Yea, I had assumed both modes used multicast for the timekeeping. Thanks for the explanation. Some mode that uses multicast for the timekeeping itself seems to me would be the lowest impact way to serve the millions of home systems. It just seems too tantalizing to pass up. -wolfgang -- Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/ Hints for IPv6 on FC6 http://www.wsrcc.com/wolfgang/fedora/ipv6-tunnel.html

I had a couple of extranenous lines in the previous version of these files: # Minimal ntp.conf for Manycasting Client (on 224.0.1.1) driftfile /var/lib/ntp/ntp.drift keys /etc/ntp.keys trustedkey 1 manycastclient 224.0.1.1 key 1 # Minimal ntp.conf for Manycasting Server (on 224.0.1.1) driftfile /var/lib/ntp/ntp.drift keys /etc/ntp.keys trustedkey 1 manycastserver 224.0.1.1 # Add some server lines here # Minimal ntp.conf for a Manycast / Orphan Mesh node driftfile /var/lib/ntp/ntp.drift keys /etc/ntp.keys trustedkey 1 tos orphan 5 manycastclient 224.0.1.1 key 1 manycastserver 224.0.1.1 # Sample /etc/ntp.keys for above config files 1 M password -- Steve Kostecke <kostecke@ntp.isc.org> NTP Public Services Project - http://ntp.isc.org/

Wolfgang S. Rupprecht wrote: > Some mode that uses multicast for the timekeeping itself seems to me > would be the lowest impact way to serve the millions of home systems. > It just seems too tantalizing to pass up. There are a few things to consider about Multicast: 1. Multicast associations can not compensate for changing network conditions at each poll. 2. Muticast clients must use NTP authentication if they wish to control which multicast servers they will accept. This requirement impacts the autonomous configuration aspect of multicast (or manycast, for that matter). -- Steve Kostecke <kostecke@ntp.isc.org> NTP Public Services Project - http://ntp.isc.org/

Steve Kostecke <kostecke@ntp.isc.org> writes: > 1. Multicast associations can not compensate for changing network > conditions at each poll. I'm picturing a second class of home user or small business that would be very happy to have their computers all within a second of the correct time and within milliseconds of each others time. Looking at the usage graphs of the pools, there are only 2-6 million pools users. That probably accounts for most of the ntp users in the world. The current estimates are over 400 million internet-connected computers. It is going to be challenging to pick up all these users using any unicast-based scheme. > 2. Muticast clients must use NTP authentication if they wish to control > which multicast servers they will accept. This requirement impacts > the autonomous configuration aspect of multicast (or manycast, for that > matter). This is the part that might be the easiest. If a few well known stratum 1's (say NIST itself) were to emit signed multicast packets the clients could just pick the servers they trusted. This obviously isn't secure from playback attacks, but would keep misconfigured servers from screwing things up too terribly. (Although the playback attacks could be dealt with by simply discarding any multicast packet from a normally trusted server that was too much older than the time being displayed in packets from other trusted servers.) -wolfgang -- Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/ Hints for IPv6 on FC6 http://www.wsrcc.com/wolfgang/fedora/ipv6-tunnel.html

On 2007-05-23, Wolfgang S. Rupprecht wrote: > Steve Kostecke <kostecke@ntp.isc.org> writes: > > Looking at the usage graphs of the pools, there are only 2-6 million > pools users. That probably accounts for most of the ntp users in the > world. The current estimates are over 400 million internet-connected > computers. It is going to be challenging to pick up all these users > using any unicast-based scheme. One challenge is the fact that it is not uncommon for ISPs or other network operators to block the NTP port. >> 2. Muticast clients must use NTP authentication if they wish to control >> which multicast servers they will accept. This requirement impacts >> the autonomous configuration aspect of multicast (or manycast, for that >> matter). > > This is the part that might be the easiest. If a few well known > stratum 1's (say NIST itself) were to emit signed multicast packets > the clients could just pick the servers they trusted. Assuming that multicast support is added to all of the routers on the Internet and the network providers can be convinced to route multicast packets and the network operators can be convinced to open the NTP port, there's the issue of key management (especially in embedded devices). -- Steve Kostecke <kostecke@ntp.isc.org> NTP Public Services Project - http://ntp.isc.org/

On Tue, 22 May 2007, in the Usenet newsgroup comp.protocols.time.ntp, in article <87646kvmaa.fsf@ancho.wsrcc.com>, Wolfgang S. Rupprecht wrote: >I just watched a Google Talk series video about Bonjour, their >zero-configuration hack. 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. Old guy

ibuprofin@painkiller.example.tld (Moe Trin) writes: >The Apple Rendezvous (renamed 'Bonjour' as a result of trademark Thanks for the scuttlebutt about Rendezvous. > Why are you allowing your users to screw with system configuration > files? Not anytime I call the shots. I'm a strong advocate of using rdist to make sure every file I care about is identical to the golden system. (Usually that is everything but a half dozen /etc files that are symlinked to host-specific files). I assign IP addresses via DHCP based on the MACs. All the internally accessible services are listed on DHCP so that trusted guest systems can find the printers and time servers. Almost-zero-conf(tm) via DHCP works for me (and I assume any organization that has admins). The case I see to zero-conf systems is for home users that don't have any pre-configured DHCP server to point them at all the nice services they might want to use. Setting up a new BSD or linux system in such a situation is going to be quite a learning experience. It would be best to just have the install or runtime system configure things as best it can. The current BSD and linux distributions do a reasonably good enough job with a working ntp out-of-the-box; now that ntp pools is there to soak up the load that is. The problem I see is that the current setup is quite wasteful. If a home user has 3 running systems, it beats up on 3x4 pools servers. That is 3x more load than strictly needed, especially since pools servers are already being hit up for 15 ntp queries per second. It would be good to figure out a way to lower that load and be able to serve the rest of the 99% of the systems that currently aren't using ntp yet. > 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. ;-) -wolfgang -- Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/ Hints for IPv6 on FC6 http://www.wsrcc.com/wolfgang/fedora/ipv6-tunnel.html

On Wed, 23 May 2007, in the Usenet newsgroup comp.protocols.time.ntp, in article <87odkbdjzt.fsf@ancho.wsrcc.com>, Wolfgang S. Rupprecht wrote: >ibuprofin@painkiller.example.tld (Moe Trin) writes: >> Why are you allowing your users to screw with system configuration >> files? >Not anytime I call the shots. I'm a strong advocate of using rdist to >make sure every file I care about is identical to the golden system. >(Usually that is everything but a half dozen /etc files that are >symlinked to host-specific files). Our users can't screw with the files, and those who have root or sudo capabilities _tend_ to know what they're doing. Accidents happen, but not very often. >I assign IP addresses via DHCP based on the MACs. All the internally >accessible services are listed on DHCP so that trusted guest systems >can find the printers and time servers. Almost-zero-conf(tm) via DHCP >works for me (and I assume any organization that has admins). Our systems are not permitted to go 'walkies' without tons of paperwork and are only configured by computer support staff. The tech who installs the software has a sheet of paper listing "the right names and numbers" for this particular box. While a new printer may get installed, a nightly 'rsync' file takes care of updating the printcap. I don't remember the last time a router, NIS or DNS server actually changed IP address - at least 20 years ago. As for "guest" or "temporary" systems, they go through the standard install process. Visitors (heck, even regular employees) are simply not allowed to bring in non-company hardware. The rare visiting company box also has to be vetted before connecting. Who, us paranoid? >The case I see to zero-conf systems is for home users that don't have >any pre-configured DHCP server to point them at all the nice services >they might want to use. Setting up a new BSD or linux system in such >a situation is going to be quite a learning experience. It would be >best to just have the install or runtime system configure things as >best it can. I'd agree that services like NTP, news, mail, and central authentication and file services aren't well supported, but the modern installation programs in the "popular" distribution make a good effort. >The problem I see is that the current setup is quite wasteful. If a >home user has 3 running systems, it beats up on 3x4 pools servers. >That is 3x more load than strictly needed, especially since pools >servers are already being hit up for 15 ntp queries per second. It >would be good to figure out a way to lower that load and be able to >serve the rest of the 99% of the systems that currently aren't using >ntp yet. I may be missing something, but 15 queries a second - that's pretty much a "nothing" load. A hundred times that should still be well within the capabilities of a "T1" connection, never mind that of a Pentium grade based system. Old guy

Wolfgang S. Rupprecht wrote: > I notice that ntp.isc.org does have an AAAA record and answers ntp > queries on its IPv6 address. Yes, it should. They are the PSP's servers. > I wonder if the powers that be would be > willing to allow it to be a IPv6 multicast server. Yes, we can do it on a site basis. > If I understand > things correctly that would require transmitting on ff0e::101, the > global multicast address with the 0x0101 ntp group id. The trouble is that only site-local (ff05::101) is implemented in the network routers. I don't believe that there is any router hardware that supports global multicasting. > > Anyone know what he rules of the road are for talking on a global > multicast? Is it essentially CB radio and one just keys the mike and > starts blabbing? > No, routers MUST support it and I don't think that any do. Danny > -wolfgang _______________________________________________ questions mailing list questions@lists.ntp.isc.org https://lists.ntp.isc.org/mailman/listinfo/questions

mayer@ntp.isc.org (Danny Mayer) writes: > Wolfgang S. Rupprecht wrote: >> If I understand >> things correctly that would require transmitting on ff0e::101, the >> global multicast address with the 0x0101 ntp group id. > > The trouble is that only site-local (ff05::101) is implemented in the > network routers. I don't believe that there is any router hardware that > supports global multicasting. Danny, thanks for the low-down. This is a bit disheartening. I take it site-local is implemented using some simplistic flooding (or similar) that is inappropriate for the global multicast. -wolfgang -- Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/ Hints for IPv6 on FC6 http://www.wsrcc.com/wolfgang/fedora/ipv6-tunnel.html

ibuprofin@painkiller.example.tld (Moe Trin) writes: >>The problem I see is that the current setup is quite wasteful. If a >>home user has 3 running systems, it beats up on 3x4 pools servers. >>That is 3x more load than strictly needed, especially since pools >>servers are already being hit up for 15 ntp queries per second. It >>would be good to figure out a way to lower that load and be able to >>serve the rest of the 99% of the systems that currently aren't using >>ntp yet. > > I may be missing something, but 15 queries a second - that's pretty > much a "nothing" load. A hundred times that should still be well > within the capabilities of a "T1" connection, never mind that of > a Pentium grade based system. The problem is the 15 queries/sec is an average. The peaks appear to be 10x that and cause the consumer ADSL or cable lines to overload. Folks are talking about bailing out of being ntp pool volunteers. I can easily see the ntp pool collapse due to positive feedback effects. (If the load is too high and some folks bail the load will get even higher causing a general run for the door.) Something that is as easy to setup as pools but much lower load is needed. We are still only at 1% ntp penetration (2-6 million pools users out of 400 million internet-connected computers.) The load is going to go up quite a bit as more of the old computers are replaced or have their SW updated. http://fortytwo.ch/mailman/pipermail/timekeepers/2007/002936.html -wolfgang -- Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/ Hints for IPv6 on FC6 http://www.wsrcc.com/wolfgang/fedora/ipv6-tunnel.html

Wolfgang S. Rupprecht wrote: > mayer@ntp.isc.org (Danny Mayer) writes: >> Wolfgang S. Rupprecht wrote: >>> If I understand >>> things correctly that would require transmitting on ff0e::101, the >>> global multicast address with the 0x0101 ntp group id. >> The trouble is that only site-local (ff05::101) is implemented in the >> network routers. I don't believe that there is any router hardware that >> supports global multicasting. > > Danny, thanks for the low-down. This is a bit disheartening. I take > it site-local is implemented using some simplistic flooding (or > similar) that is inappropriate for the global multicast. It's a bit more complicated than that. From my understanding there is no agreement on global multicasting and the router/switch vendors are not going to put something in unless there is a demand for it. At the global level these things need to be agreed upon at an international level and possibly by ICANN, IANA, IETF, etc. I don't think there is any agreement on it. In any case I think there are diminishing returns when you go beyond site. I don't know enough about the routing protocols to talk about how complex it is to implement nor if the vendors have all the information that they would need to make this practical. A much better method might be to go to SRV records which have some advantage over A records in the DNS to find an NTP server. This is basically what zeroconf (at least some implementations do) by having the NTP server add an SRV record to announce it's availability. Of course that requires a dynamic DNS zone. A drawback to that is if the NTP server goes down, or the system it's on goes down the SRV record doesn't get removed. Danny _______________________________________________ questions mailing list questions@lists.ntp.isc.org https://lists.ntp.isc.org/mailman/listinfo/questions