[Git][NTPsec/ntpsec][master] 2 commits: Remove broadcastclient and multicastclient directives
Daniel Fox Franke
gitlab at mg.gitlab.com
Thu Nov 24 01:45:57 UTC 2016
Daniel Fox Franke pushed to branch master at NTPsec / ntpsec
Commits:
05e79c87 by Daniel Fox Franke at 2016-11-23T17:22:26-05:00
Remove broadcastclient and multicastclient directives
- - - - -
a1a4caf1 by Daniel Fox Franke at 2016-11-23T20:45:46-05:00
Documentation updates for broadcast client removal
- - - - -
7 changed files:
- docs/assoc.txt
- docs/discover.txt
- docs/includes/assoc-auxcommands.txt
- docs/includes/assoc-commands.txt
- docs/includes/confopt.txt
- ntpd/keyword-gen.c
- ntpd/ntp_parser.y
Changes:
=====================================
docs/assoc.txt
=====================================
--- a/docs/assoc.txt
+++ b/docs/assoc.txt
@@ -107,16 +107,14 @@ message. Since an intruder can impersonate a symmetric active peer and
cause a spurious symmetric passive association to be mobilized,
symmetric passive mode should always be cryptographically validated.
-A peer is configured in symmetric active mode using the +peer+ command
-and specifying the other peer DNS name or IPv4 or IPv6 address. The
-+burst+ and +iburst+ options should not be used in symmetric modes, as
-this can upset the intended symmetry of the protocol and result in
-spurious duplicate or dropped messages.
-
-As symmetric modes are most often used as root servers for moderate to
-large subnets where rapid response is required, it is generally best to
-set the minimum and maximum poll intervals of each root server to the
-same value using the +minpoll+ and +maxpoll+ options.
+Due to unresolvable security issues with symmetric mode, NTPsec
+includes only partial support for it. The deprecated +peer+ directive
+which formerly set up a symmetric active association is now a synonym
+for +server+. Servers which receive symmetric active messages will
+immediately reply with symmetric passive responses without setting up
+any new association; essientially they treat such messages exactly
+like client-mode messages aside from putting a different mode number
+into the response.
[[broad]]
== Broadcast/Multicast Modes ==
@@ -129,15 +127,11 @@ do not extend beyond a level-3 router. Where service is intended beyond
a level-3 router, multicast mode can be used. Additional information is
on the link:discover.html[Automatic NTP Configuration Options] page.
-A server is configured to send broadcast or multicast messages using the
-+broadcast+ command and specifying the subnet address for broadcast or
-the multicast group address for multicast. A broadcast client is enabled
-using the link:confopt.html#broadcastclient[+broadcastclient+] command,
-while a multicast client is enabled using the
-link:confopt.html#multicastclient[+multicastclient+] command and
-specifying the multicast group address. Multiple commands of either type
-can be used. However, the association is not mobilized until the first
-broadcast or multicast message is actually received.
+A server is configured to send broadcast or multicast messages using
+the +broadcast+ command and specifying the subnet address for
+broadcast or the multicast group address for multicast. Due to
+unresolvable security issues, NTPsec no longer supports functioning as
+a broadcast or multicast client.
[[many]]
== Manycast and Pool Modes ==
=====================================
docs/discover.txt
=====================================
--- a/docs/discover.txt
+++ b/docs/discover.txt
@@ -85,6 +85,11 @@ Options] page. See that page for applicability and defaults.
[[bcst]]
== Broadcast/Multicast Scheme ==
+The broadcast/multicast scheme is deprecated in NTPsec due to
+irreparable security flaws. Client-side support has been removed.
+Server-side support remains present but may be removed in a future
+version, and its use is strongly discouraged.
+
A broadcast server generates messages continuously at intervals by
default 64 s and time-to-live by default 127. These defaults can be
overridden by the +minpoll+ and +ttl+ options, respectively. Not all
@@ -108,8 +113,7 @@ A server is configured in broadcast mode using the +broadcast+ command
and specifying the broadcast address of a local interface. If two or
more local interfaces are installed with different broadcast addresses,
a +broadcast+ command is needed for each address. This provides a way to
-limit exposure in a firewall, for example. A broadcast client is
-configured using the +broadcastclient+ command.
+limit exposure in a firewall, for example.
NTP multicast mode can be used to extend the scope using IPv4 multicast
or IPv6 broadcast with defined span. The IANA has assigned IPv4
@@ -121,34 +125,20 @@ described in RFC-2365, or GLOP group addresses, as described in
RFC-2770.
A multicast server is configured using the +broadcast+ command, but
-specifying a multicast address instead of a broadcast address. A
-multicast client is configured using the +multicastclient+ command
-specifying a list of one or more multicast addresses. Note that there is
-a subtle distinction between the IPv4 and IPv6 address families. The
-IPv4 broadcast or mulitcast mode is determined by the IPv4 class. For
-IPv6 the same distinction can be made using the link-local prefix FF02
-for each interface and site-local prefix FF05 for all interfaces.
-
-It is possible and frequently useful to configure a host as both
-broadcast client and broadcast server. A number of hosts configured this
-way and sharing a common broadcast address will automatically organize
-themselves in an optimum configuration based on stratum and
-synchronization distance.
-
-Since an intruder can impersonate a broadcast server and inject false
-time values, broadcast mode should always be cryptographically
-authenticated. By default, a broadcast association will not be mobilized
-unless cryptographically authenticated. If necessary, the +auth+ option
-of the +disable+ command will disable this feature. The feature can be
-selectively enabled using the +notrust+ option of the +restrict+
-command.
-
-With symmetric key cryptography each broadcast server can use the same
-or different keys. In one scenario on a broadcast LAN, a set of
-broadcast clients and servers share the same key along with another set
-that share a different key. Only the clients with matching key will
-respond to a server broadcast. Further information is on the
-link:authentic.html[Authentication Support] page.
+specifying a multicast address instead of a broadcast address. Note
+that there is a subtle distinction between the IPv4 and IPv6 address
+families. The IPv4 broadcast or mulitcast mode is determined by the
+IPv4 class. For IPv6 the same distinction can be made using the
+link-local prefix FF02 for each interface and site-local prefix FF05
+for all interfaces.
+
+NTPsec permits the use of symmetric authentication with broadcast mode
+the same way as any other mode; however, it is not effective at
+providing security because the sessionless, one-way nature of the
+protocol makes detection of replayed or delayed packets
+impossible. Regardless of whether authentication is employed,
+broadcast mode must be used only on physically-secure networks where
+all systems on the subnet are fully trusted.
[[mcst]]
== Manycast Scheme ==
=====================================
docs/includes/assoc-auxcommands.txt
=====================================
--- a/docs/includes/assoc-auxcommands.txt
+++ b/docs/includes/assoc-auxcommands.txt
@@ -1,16 +1,5 @@
// Auxilary association commands - included twice
-+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 authentication as described on 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
@@ -21,17 +10,6 @@
disruption in this mode, both the server and client should operate
using authentication as described on 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 authentication as described on the
- "Authentication Options" page.
-
+mdnstries+ _number_::
If we are participating in mDNS, after we have synched for the first
time we attempt to register with the mDNS system. If that registration
=====================================
docs/includes/assoc-commands.txt
=====================================
--- a/docs/includes/assoc-commands.txt
+++ b/docs/includes/assoc-commands.txt
@@ -47,9 +47,6 @@ link-local IPV6 address with an interface specified in
assigned the multicast group address IPv4 224.0.1.1 and IPv6 ff05::101
(site local) exclusively to NTP, but other nonconflicting addresses
can be used to contain the messages within administrative boundaries.
- Ordinarily, this specification applies only to the local server
- operating as a sender; for operation as a broadcast client, see the
- _broadcastclient_ or _multicastclient_ commands below.
+manycastclient+::
For multicast addresses (only), this command mobilizes a manycast client
=====================================
docs/includes/confopt.txt
=====================================
--- a/docs/includes/confopt.txt
+++ b/docs/includes/confopt.txt
@@ -5,8 +5,6 @@
* link:confopt.html#manycastclient[manycastclient - configure manycast client association]
* link:confopt.html#pool[pool - configure pool association]
* link:confopt.html#unpeer[unpeer - remove association]
-* link:confopt.html#broadcastclient[broadcastclient - enable broadcast client]
* link:confopt.html#manycastserver[manycastserver - enable manycast server]
-* link:confopt.html#multicastclient[multicastclient - enable multicast client]
* link:comdex.html[Command Index]
=====================================
ntpd/keyword-gen.c
=====================================
--- a/ntpd/keyword-gen.c
+++ b/ntpd/keyword-gen.c
@@ -25,7 +25,6 @@ struct key_tok ntp_keywords[] = {
{ "...", T_Ellipsis, FOLLBY_TOKEN },
{ "allpeers", T_Allpeers, FOLLBY_TOKEN },
{ "broadcast", T_Broadcast, FOLLBY_STRING },
-{ "broadcastclient", T_Broadcastclient, FOLLBY_TOKEN },
{ "broadcastdelay", T_Broadcastdelay, FOLLBY_TOKEN },
{ "baud", T_Baud, FOLLBY_TOKEN },
{ "ctl", T_Ctl, FOLLBY_TOKEN },
@@ -46,7 +45,6 @@ struct key_tok ntp_keywords[] = {
{ "manycastclient", T_Manycastclient, FOLLBY_STRING },
{ "manycastserver", T_Manycastserver, FOLLBY_STRINGS_TO_EOC },
{ "mem", T_Mem, FOLLBY_TOKEN },
-{ "multicastclient", T_Multicastclient, FOLLBY_STRINGS_TO_EOC },
{ "path", T_Path, FOLLBY_STRING },
{ "peer", T_Peer, FOLLBY_STRING },
{ "phone", T_Phone, FOLLBY_STRINGS_TO_EOC },
=====================================
ntpd/ntp_parser.y
=====================================
--- a/ntpd/ntp_parser.y
+++ b/ntpd/ntp_parser.y
@@ -61,7 +61,6 @@
%token <Integer> T_Bclient
%token <Integer> T_Beacon
%token <Integer> T_Broadcast
-%token <Integer> T_Broadcastclient
%token <Integer> T_Broadcastdelay
%token <Integer> T_Burst
%token <Integer> T_Calibrate
@@ -152,7 +151,6 @@
%token <Integer> T_Monitor
%token <Integer> T_Month
%token <Integer> T_Mru
-%token <Integer> T_Multicastclient
%token <Integer> T_Nic
%token <Integer> T_Nolink
%token <Integer> T_Nomodify
@@ -511,17 +509,13 @@ unpeer_keyword
/* Other Modes
- * (broadcastclient manycastserver multicastclient)
+ * (manycastserver)
* ------------------------------------------------
*/
other_mode_command
- : T_Broadcastclient
- { cfgt.broadcastclient = 1; }
- | T_Manycastserver address_list
+ : T_Manycastserver address_list
{ CONCAT_G_FIFOS(cfgt.manycastserver, $2); }
- | T_Multicastclient address_list
- { CONCAT_G_FIFOS(cfgt.multicastclient, $2); }
| T_Mdnstries T_Integer
{ cfgt.mdnstries = $2; }
;
View it on GitLab: https://gitlab.com/NTPsec/ntpsec/compare/4911e2df0c54414a539685545780168757879434...a1a4caf147ece7c242fbb7cf654f26d4975b76ad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/vc/attachments/20161124/81a44638/attachment.html>
More information about the vc
mailing list