RFC 1165 (rfc1165) - Page 2 of 10

Network Time Protocol (NTP) over the OSI Remote Operations Service

Alternative Format: Original Text Document


RFC 1165                      NTP over OSI                     June 1990


   Service implementation of NTP is fourfold.

      1.  The inclusion of a useful service to an OSI
          environment.

      2.  The feasibility of automatically checking a ROS/ASN.1
          specification, and automatically generating code to
          implement the protocol.

      3.  The feasibility of running NTP on connection oriented
          network services (CONS or X.25), and consequentially,
          the ability to use connection success or failure to
          optimise reachability discovery.

      4.  The generalisation of the last point: the use of ROS
          makes NTP independent of the underlying communications
          architecture.

   The need for time synchronisation is clear, and RFC 1119 indicates a
   few of the necessary uses of this service.  However, it is becoming
   clear that OSI applications are very much in need of this service
   too.  Not just in the local context but across the wide area.  For
   example much of the strong authentication outlined in X.511 is based
   on encrypted packets with time stamps to indicate how long the packet
   is valid for.  If two hosts have clocks that are not closely
   synchronised, the host with the faster clock will be more prone to
   cryptographic attacks from the slower, and the slower host will
   possibly find it is unauthentable.

   A similar problem occurs with the X.500 directory and the service
   control limiting the time allowed for the search.

   Authentication between NTP peers and between clients and servers is
   not addressed here, as the choice of mechanism is still the subject
   of some debate.

2.  Protocol Overview

   The NTP application functions exactly as in RFC 1119.  The use of
   remote operations and the underlying Application support means that
   for NTP daemons to peer with one another, they send an A-
   ASSOCIATE.REQUEST, and receive an A-ASSOCIATE.INDICATION.

   On successful association, they subsequently periodically invoke the
   appropriate Remote Operation with the appropriate parameters at the
   appropriate frequency.

   On failure, they mark the peer as unreachable.



Crowcroft & Onions

Web Standards & Support: