The NTP design is such that accidental or malicious data
modification (tampering) or destruction (jamming) at a time server should not in general result in timekeeping errors elsewhere in the
synchronization subnet. However, the success of this approach depends on redundant time servers and diverse network paths, together
with the assumption that tampering or jamming will not occur at many time servers throughout the synchronization subnet at the same
time. In principle, the subnet vulnerability can be engineered through the selection of time servers known to be trusted and allowing
only those time servers to become the synchronization source. The authentication procedures described in Appendix C represent one mechanism to enforce this; however, the encryption algorithms can be quite CPU-intensive
and can seriously degrade accuracy, unless precautions such as mentioned in the description of the transmit procedure are taken.
While not a required feature of NTP itself, some implementations may include an access-control feature that prevents unauthorized
access and controls which peers are allowed to update the local clock. For this purpose it is useful to distinguish between three
categories of access: those that are preauthorized as trusted, preauthorized as friendly and all other (non-preauthorized) accesses.
Presumably, preauthorization is accomplished by entries in the configuration file or some kind of ticket-management system such as
Kerberos [STE88]. In this model only trusted accesses can result in the peer becoming the synchronization source. While friendly
accesses cannot result in the peer becoming the synchronization source, NTP messages and timestamps are returned as specified.
It does not seem useful to maintain a secret clock, as would result from restricting non-preauthorized accesses, unless the intent is
to hide the existence of the time server itself. Well-behaved Internet hosts are expected to return an ICMP service-unavailable error
message if a service is not implemented or resources are not available; however, in the case of NTP the resources required are
minimal, so there is little need to restrict requests intended only to read the clock. A simple but effective access-control mechanism
is then to consider all associations preconfigured in a symmetric mode or client mode (modes 1, 2 and 3) as trusted and all other
associations, preconfigured or not, as friendly.
If a more comprehensive trust model is required, the design can be based on an access-control list with each entry consisting of a
32-bit Internet address, 32-bit mask and three-bit mode. If the logical AND of the source address (pkt.peeraddr) and the mask in an
entry matches the corresponding address in the entry and the mode (pkt.mode) matches the mode in the entry, the access is allowed;
otherwise an ICMP error message is returned to the requestor. Through appropriate choice of mask, it is possible to restrict requests
by mode to individual addresses, a particular subnet or net addresses, or have no restriction at all. The access-control list would
then serve as a filter controlling which peers could create associations.
|
|