From: Harlan Stenn Date: Thu, 18 Dec 2003 04:35:26 +0000 (-0500) Subject: Updates from Dave Mills. X-Git-Tag: NTP_4_2_3~190^2~8 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=666b10a39bca8b0bb07e8ea0f9efd86687b572ec;p=thirdparty%2Fntp.git Updates from Dave Mills. bk: 3fe12e8eP64jnY1M1jS2UVje6LbYog --- diff --git a/html/confopt.html b/html/confopt.html index 110083acb5..874928b514 100644 --- a/html/confopt.html +++ b/html/confopt.html @@ -12,7 +12,7 @@

Server Options

giffrom Pogo, Walt Kelly

The chicken is getting configuration advice.

-

Last update: 03:08 AM UTC Monday, October 13, 2003

+

Last update: 09:18 PM UTC Thursday, December 04, 2003


Related Links

@@ -72,12 +72,11 @@

Auxilliary Commands

-
broadcastclient -
This command enables reception of broadcast server messages to any local interface (type b) address. Upon receiving a message for the first time, the broadcast client measures the nominal server propagation delay using a brief client/server exchange with the server, then enters the broadcast client mode, in which it synchronizes to succeeding broadcast messages. Note that, in order to avoid accidental or malicious disruption in this mode, both the server and client should operate using symmetric-key or public-key authentication as described in the Authentication Options page. -
manycastserver address [...] -
This command enables reception of manycast client messages to the multicast group address(es) (type m) specified. At least one address is required, but The NTP multicast address 224.0.1.1 assigned by the IANA should NOT be used, unless specific means are taken to limit the span of the reply and avoid a possibly massive implosion at the original sender. Note that, in order to avoid accidental or malicious disruption in this mode, both the server and client should operate using symmetric-key or public-key authentication as described in the Authentication Options page. +
broadcastclient [novolley] +
This command enables reception of broadcast server messages to any local interface (type b) address. Ordinarily, upon receiving a message for the first time, the broadcast client measures the nominal server propagation delay using a brief client/server exchange with the server, after which it continues in listen-only mode. If the novolley keyword is present, the exchange is not used and the value specified in the broadcastdelay command is used or, if the broadcastdelay command is not used, the default 4.0 ms. Note that, in order to avoid accidental or malicious disruption in this mode, both the server and client should operate using symmetric-key or public-key authentication as described in the Authentication Options page. Note that the novolley keyword is incompatible with public-key authentication.
manycastserver address [...] +
This command enables reception of manycast client messages to the multicast group address(es) (type m) specified. At least one address is required, but The NTP multicast address 224.0.1.1 assigned by the IANA should NOT be used, unless specific means are taken to limit the span of the reply and avoid a possibly massive implosion at the original sender. Note that, in order to avoid accidental or malicious disruption in this mode, both the server and client should operate using symmetric-key or public-key authentication as described in the Authentication Options page.
multicastclient [address] [...] -
This command enables reception of multicast server messages to the multicast group address(es) (type m) specified. Upon receiving a message for the first time, the multicast client measures the nominal server propagation delay using a brief client/server exchange with the server, then enters the broadcast client mode, in which it synchronizes to succeeding multicast messages. Note that, in order to avoid accidental or malicious disruption in this mode, both the server and client should operate using symmetric-key or public-key authentication as described in the Authentication Options page. +
This command enables reception of multicast server messages to the multicast group address(es) (type m) specified. Upon receiving a message for the first time, the multicast client measures the nominal server propagation delay using a brief client/server exchange with the server, then enters the broadcast client mode, in which it synchronizes to succeeding multicast messages. Note that, in order to avoid accidental or malicious disruption in this mode, both the server and client should operate using symmetric-key or public-key authentication as described in the Authentication Options page.

Bugs

The syntax checking is not picky; some combinations of ridiculous and even hilarious options and modes may not be detected.

diff --git a/html/ntpdc.html b/html/ntpdc.html index c29c0a29be..3eda96491c 100644 --- a/html/ntpdc.html +++ b/html/ntpdc.html @@ -12,7 +12,7 @@

ntpdc - special NTP query program

giffrom Alice's Adventures in Wonderland, Lewis Carroll

This program is a big puppy.

-

Last update: 21:39 UTC Sunday, January 26, 2003

+

Last update: 03:40 PM UTC Friday, December 05, 2003


More Help

@@ -110,7 +110,7 @@
Obtain debugging information for a reference clock driver. This information is provided only by some clock drivers and is mostly undecodable without a copy of the driver source in hand.

Runtime Configuration Requests

-

All requests which cause state changes in the server are authenticated by the server using a configured NTP key (the facility can also be disabled by the server by not configuring a key). The key number and the corresponding key must also be made known to ntpdc<\tt>. This can be done using the keyid and passwd commands, the latter of which will prompt at the terminal for a password to use as the encryption key. You will also be prompted automatically for both the key number and password the first time a command which would result in an authenticated request to the server is given. Authentication not only provides verification that the requester has permission to make such changes, but also gives an extra degree of protection again transmission errors.

+

All requests which cause state changes in the server are authenticated by the server using a configured NTP key (the facility can also be disabled by the server by not configuring a key). The key number and the corresponding key must also be made known to ntpdc. This can be done using the keyid and passwd commands, the latter of which will prompt at the terminal for a password to use as the encryption key. You will also be prompted automatically for both the key number and password the first time a command which would result in an authenticated request to the server is given. Authentication not only provides verification that the requester has permission to make such changes, but also gives an extra degree of protection again transmission errors.

Authenticated requests always include a timestamp in the packet data, which is included in the computation of the authentication code. This timestamp is compared by the server to its receive time stamp. If they differ by more than a small amount the request is rejected. This is done for two reasons. First, it makes simple replay attacks on the server, by someone who might be able to overhear traffic on your LAN, much more difficult. Second, it makes it more difficult to request configuration changes to your server from topologically remote hosts. While the reconfiguration facility will work well with a server on the local host, and may work adequately between time-synchronized hosts on the same LAN, it will work very poorly for more distant hosts. As such, if reasonable passwords are chosen, care is taken in the distribution and protection of keys and appropriate source address restrictions are applied, the run time reconfiguration facility should provide an adequate level of security.

The following commands all make authenticated requests.