draft-ietf-ntp-ntpv4-proto-11.txt   draft-ietf-ntp-ntpv4-proto-12.txt 
NTP WG J. Burbank, Ed. NTP WG J. Burbank
Internet-Draft W. Kasch, Ed. Internet-Draft W. Kasch
Obsoletes: RFC 4330, RFC 1305 JHU/APL Obsoletes: RFC 4330, RFC 1305 JHU/APL
(if approved) J. Martin, Ed. (if approved) J. Martin, Ed.
Intended status: Standards Track Woven Intended status: Standards Track Daedelus
Expires: March 9, 2009 D. Mills Expires: April 11, 2010 D. Mills
U. Delaware U. Delaware
September 5, 2008 October 8, 2009
Network Time Protocol Version 4 Protocol And Algorithms Specification Network Time Protocol Version 4 Protocol And Algorithms Specification
draft-ietf-ntp-ntpv4-proto-11 draft-ietf-ntp-ntpv4-proto-12
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 9, 2009. This Internet-Draft will expire on April 11, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
The Network Time Protocol (NTP) is widely used to synchronize The Network Time Protocol (NTP) is widely used to synchronize
computer clocks in the Internet. This document describes NTP Version computer clocks in the Internet. This document describes NTP Version
4 (NTPv4), which is backwards compatible with NTP Version 3 (NTPv3) 4 (NTPv4), which is backwards compatible with NTP Version 3 (NTPv3)
described in RFC 1305, as well as previous versions of the protocol. described in RFC 1305, as well as previous versions of the protocol.
NTPv4 includes a modified protocol header to accommodate the Internet NTPv4 includes a modified protocol header to accommodate the Internet
Protocol Version 6 address family. NTPv4 includes fundamental Protocol Version 6 address family. NTPv4 includes fundamental
improvements in the mitigation and discipline algorithms which extend improvements in the mitigation and discipline algorithms which extend
the potential accuracy to the tens of microseconds with modern the potential accuracy to the tens of microseconds with modern
workstations and fast LANs. It includes a dynamic server discovery workstations and fast LANs. It includes a dynamic server discovery
scheme, so that in many cases specific server configuration is not scheme, so that in many cases specific server configuration is not
required. It corrects certain errors in the NTPv3 design and required. It corrects certain errors in the NTPv3 design and
implementation and includes an optional extension mechanism. implementation and includes an optional extension mechanism.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 6
2. Modes of Operation . . . . . . . . . . . . . . . . . . . . . 5 2. Modes of Operation . . . . . . . . . . . . . . . . . . . . . 6
3. Protocol Modes . . . . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Modes . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Dynamic Server Discovery . . . . . . . . . . . . . . . . 7 3.1. Dynamic Server Discovery . . . . . . . . . . . . . . . . 8
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Implementation Model . . . . . . . . . . . . . . . . . . . . 10 5. Implementation Model . . . . . . . . . . . . . . . . . . . . 11
6. Data Types . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Data Types . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 16 7. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Structure Conventions . . . . . . . . . . . . . . . . . . 16 7.1. Structure Conventions . . . . . . . . . . . . . . . . . . 17
7.2. Global Parameters . . . . . . . . . . . . . . . . . . . . 16 7.2. Global Parameters . . . . . . . . . . . . . . . . . . . . 17
7.3. Packet Header Variables . . . . . . . . . . . . . . . . . 17 7.3. Packet Header Variables . . . . . . . . . . . . . . . . . 18
7.4. The Kiss-o'-Death Packet . . . . . . . . . . . . . . . . 23 7.4. The Kiss-o'-Death Packet . . . . . . . . . . . . . . . . 25
7.5. NTP Extension Field Format . . . . . . . . . . . . . . . 25 7.5. NTP Extension Field Format . . . . . . . . . . . . . . . 26
8. On Wire Protocol . . . . . . . . . . . . . . . . . . . . . . 26 8. On Wire Protocol . . . . . . . . . . . . . . . . . . . . . . 27
9. Peer Process . . . . . . . . . . . . . . . . . . . . . . . . 30 9. Peer Process . . . . . . . . . . . . . . . . . . . . . . . . 31
9.1. Peer Process Variables . . . . . . . . . . . . . . . . . 31 9.1. Peer Process Variables . . . . . . . . . . . . . . . . . 32
9.2. Peer Process Operations . . . . . . . . . . . . . . . . . 33 9.2. Peer Process Operations . . . . . . . . . . . . . . . . . 34
10. Clock Filter Algorithm . . . . . . . . . . . . . . . . . . . 37 10. Clock Filter Algorithm . . . . . . . . . . . . . . . . . . . 38
11. System Process . . . . . . . . . . . . . . . . . . . . . . . 39 11. System Process . . . . . . . . . . . . . . . . . . . . . . . 40
11.1. System Process Variables . . . . . . . . . . . . . . . . 40 11.1. System Process Variables . . . . . . . . . . . . . . . . 41
11.2. System Process Operations . . . . . . . . . . . . . . . . 41 11.2. System Process Operations . . . . . . . . . . . . . . . . 42
11.2.1. Selection Algorithm . . . . . . . . . . . . . . . . 43 11.2.1. Selection Algorithm . . . . . . . . . . . . . . . . 44
11.2.2. Cluster Algorithm . . . . . . . . . . . . . . . . . 44 11.2.2. Cluster Algorithm . . . . . . . . . . . . . . . . . 45
11.2.3. Combine Algorithm . . . . . . . . . . . . . . . . . 45 11.2.3. Combine Algorithm . . . . . . . . . . . . . . . . . 46
11.3. Clock Discipline Algorithm . . . . . . . . . . . . . . . 47 11.3. Clock Discipline Algorithm . . . . . . . . . . . . . . . 48
12. Clock Adjust Process . . . . . . . . . . . . . . . . . . . . 51 12. Clock Adjust Process . . . . . . . . . . . . . . . . . . . . 52
13. Poll Process . . . . . . . . . . . . . . . . . . . . . . . . 51 13. Poll Process . . . . . . . . . . . . . . . . . . . . . . . . 52
13.1. Poll Process Variables . . . . . . . . . . . . . . . . . 51 13.1. Poll Process Variables . . . . . . . . . . . . . . . . . 52
13.2. Poll Process Operations . . . . . . . . . . . . . . . . . 52 13.2. Poll Process Operations . . . . . . . . . . . . . . . . . 53
14. Simple Network Time Protocol (SNTP) . . . . . . . . . . . . . 54 14. Simple Network Time Protocol (SNTP) . . . . . . . . . . . . . 55
15. Security Considerations . . . . . . . . . . . . . . . . . . . 55 15. Security Considerations . . . . . . . . . . . . . . . . . . . 56
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 57 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 60
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 60
18.1. Informative References . . . . . . . . . . . . . . . . . 57 18.1. Normative References . . . . . . . . . . . . . . . . . . 60
18.2. Normative References . . . . . . . . . . . . . . . . . . 58 18.2. Informative References . . . . . . . . . . . . . . . . . 60
Appendix A. Code Skeleton . . . . . . . . . . . . . . . . . . . 58 Appendix A. Code Skeleton . . . . . . . . . . . . . . . . . . . 61
A.1. Global Definitions . . . . . . . . . . . . . . . . . . . 59 A.1. Global Definitions . . . . . . . . . . . . . . . . . . . 62
A.1.1. Definitions, Constants, Parameters . . . . . . . . . 59 A.1.1. Definitions, Constants, Parameters . . . . . . . . . 62
A.1.2. Packet Data Structures . . . . . . . . . . . . . . . 62 A.1.2. Packet Data Structures . . . . . . . . . . . . . . . 65
A.1.3. Association Data Structures . . . . . . . . . . . . 63 A.1.3. Association Data Structures . . . . . . . . . . . . 66
A.1.4. System Data Structures . . . . . . . . . . . . . . . 66 A.1.4. System Data Structures . . . . . . . . . . . . . . . 68
A.1.5. Local Clock Data Structures . . . . . . . . . . . . 67 A.1.5. Local Clock Data Structures . . . . . . . . . . . . 69
A.1.6. Function Prototypes . . . . . . . . . . . . . . . . 67 A.1.6. Function Prototypes . . . . . . . . . . . . . . . . 69
A.2. Main Program and Utility Routines . . . . . . . . . . . . 68 A.2. Main Program and Utility Routines . . . . . . . . . . . . 70
A.3. Kernel Input/Output Interface . . . . . . . . . . . . . . 71 A.3. Kernel Input/Output Interface . . . . . . . . . . . . . . 73
A.4. Kernel System Clock Interface . . . . . . . . . . . . . . 71 A.4. Kernel System Clock Interface . . . . . . . . . . . . . . 73
A.5. Peer Process . . . . . . . . . . . . . . . . . . . . . . 73 A.5. Peer Process . . . . . . . . . . . . . . . . . . . . . . 75
A.5.1. receive() . . . . . . . . . . . . . . . . . . . . . 74 A.5.1. receive() . . . . . . . . . . . . . . . . . . . . . 76
A.5.2. clock_filter() . . . . . . . . . . . . . . . . . . . 81 A.5.2. clock_filter() . . . . . . . . . . . . . . . . . . . 83
A.5.3. fast_xmit() . . . . . . . . . . . . . . . . . . . . 85 A.5.3. fast_xmit() . . . . . . . . . . . . . . . . . . . . 87
A.5.4. access() . . . . . . . . . . . . . . . . . . . . . . 87 A.5.4. access() . . . . . . . . . . . . . . . . . . . . . . 88
A.5.5. System Process . . . . . . . . . . . . . . . . . . . 87 A.5.5. System Process . . . . . . . . . . . . . . . . . . . 88
A.5.6. Clock Adjust Process . . . . . . . . . . . . . . . . 101 A.5.6. Clock Adjust Process . . . . . . . . . . . . . . . . 103
A.5.7. Poll Process . . . . . . . . . . . . . . . . . . . . 102 A.5.7. Poll Process . . . . . . . . . . . . . . . . . . . . 104
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 111
Intellectual Property and Copyright Statements . . . . . . . . . 110
1. Introduction 1. Introduction
This document defines the Network Time Protocol Version 4 (NTPv4), This document defines the Network Time Protocol Version 4 (NTPv4),
which is widely used to synchronize system clocks among a set of which is widely used to synchronize system clocks among a set of
distributed time servers and clients. It describes the core distributed time servers and clients. It describes the core
architecture, protocol, state machines, data structures and architecture, protocol, state machines, data structures and
algorithms. NTPv4 introduces new functionality to NTPv3, as algorithms. NTPv4 introduces new functionality to NTPv3, as
described in [RFC1305], and functionality expanded from SNTPv4 as described in [RFC1305], and functionality expanded from SNTPv4 as
described in [RFC4330] (SNTPv4 is a subset of NTPv4). This document described in [RFC4330] (SNTPv4 is a subset of NTPv4). This document
skipping to change at page 5, line 5 skipping to change at page 6, line 5
structures necessary to interoperate between conforming structures necessary to interoperate between conforming
implementations. Appendix A contains a full featured example in the implementations. Appendix A contains a full featured example in the
form of a skeleton program, including data structures and code form of a skeleton program, including data structures and code
segments for the core algorithms as well as the mitigation algorithms segments for the core algorithms as well as the mitigation algorithms
used to enhance reliability and accuracy. While the skeleton program used to enhance reliability and accuracy. While the skeleton program
and other descriptions in this document apply to a particular and other descriptions in this document apply to a particular
implementation, they are not intended as the only way the required implementation, they are not intended as the only way the required
functions can be implemented. While the NTPv3 symmetric key functions can be implemented. While the NTPv3 symmetric key
authentication scheme described in this document has been carried authentication scheme described in this document has been carried
over from NTPv3, the Autokey public key authentication scheme new to over from NTPv3, the Autokey public key authentication scheme new to
NTPv4 is described in [ref3]. NTPv4 is described in [I-D.ietf-ntp-autokey].
The NTP protocol includes modes of operation described in Section 2 The NTP protocol includes modes of operation described in Section 2
using data types described in Section 6 and data structures described using data types described in Section 6 and data structures described
in Section 7. The implementation model described in Section 5 is in Section 7. The implementation model described in Section 5 is
based on a threaded, multi-process architecture, although other based on a threaded, multi-process architecture, although other
architectures could be used as well. The on-wire protocol described architectures could be used as well. The on-wire protocol described
in Section 8 is based on a returnable-time design which depends only in Section 8 is based on a returnable-time design which depends only
on measured clock offsets, but does not require reliable message on measured clock offsets, but does not require reliable message
delivery. Reliable message delivery such as TCP[RFC0793] can delivery. Reliable message delivery such as TCP[RFC0793] can
actually make the delivered NTP packet less reliable since retries actually make the delivered NTP packet less reliable since retries
skipping to change at page 6, line 18 skipping to change at page 7, line 18
All servers and clients who are fully NTPv4 compliant MUST implement All servers and clients who are fully NTPv4 compliant MUST implement
the entire suite of algorithms described in this document. In order the entire suite of algorithms described in this document. In order
to maintain stability in large NTP subnets, secondary servers SHOULD to maintain stability in large NTP subnets, secondary servers SHOULD
be fully NTPv4 compliant. Alternative algorithms MAY be used, but be fully NTPv4 compliant. Alternative algorithms MAY be used, but
their output MUST be identical to the algorithms described in this their output MUST be identical to the algorithms described in this
specification. specification.
3. Protocol Modes 3. Protocol Modes
There are three NTP protocol variants, symmetric, client/server and There are three NTP protocol variants, symmetric, client/server and
broadcast. Each is associated with an association mode as shown in broadcast. Each is associated with an association mode (a
description of the relationship between two NTP speakers) as shown in
Figure 1. In addition, persistent associations are mobilized upon Figure 1. In addition, persistent associations are mobilized upon
startup and are never demobilized. Ephemeral associations are startup and are never demobilized. Ephemeral associations are
mobilized upon the arrival of a packet and are demobilized upon error mobilized upon the arrival of a packet and are demobilized upon error
or timeout. or timeout.
+-------------------+--------------+-------------+ +-------------------+--------------+-------------+
| Association Mode | Assoc. Mode | Packet Mode | | Association Mode | Assoc. Mode | Packet Mode |
+-------------------+--------------+-------------+ +-------------------+--------------+-------------+
| Symmetric Active | 1 | 1 or 2 | | Symmetric Active | 1 | 1 or 2 |
| Symmetric Passive | 2 | 1 | | Symmetric Passive | 2 | 1 |
| Client | 3 | 4 | | Client | 3 | 4 |
| Server | 4 | 3 | | Server | 4 | 3 |
| Broadcast Server | 5 | 5 | | Broadcast Server | 5 | 5 |
| Broadcast Client | 6 | N/A | | Broadcast Client | 6 | N/A |
+-------------------+--------------+-------------+ +-------------------+--------------+-------------+
Figure 1: Association and Packet Modes Figure 1: Association and Packet Modes
In the client/server variant a persistent client sends client (mode In the client/server variant a persistent client sends packet mode 4
3) packets to a server, which returns server (mode 4) packets. packets to a server, which returns packet mode 3 packets. Servers
Servers provide synchronization to one or more clients, but do not provide synchronization to one or more clients, but do not accept
accept synchronization from them. A server can also be a reference synchronization from them. A server can also be a reference clock
clock driver which obtains time directly from a standard source such driver which obtains time directly from a standard source such as a
as a GPS receiver or telephone modem service. In this variant, GPS receiver or telephone modem service. In this variant, clients
clients pull synchronization from servers. pull synchronization from servers.
In the symmetric variant a peer operates as both a server and client In the symmetric variant a peer operates as both a server and client
using either a symmetric active or symmetric passive association. A using either a symmetric active or symmetric passive association. A
persistent symmetric active association sends symmetric active (mode persistent symmetric active association sends symmetric active (mode
1) packets to a symmetric active peer association. Alternatively, an 1) packets to a symmetric active peer association. Alternatively, an
ephemeral symmetric passive association can be mobilized upon arrival ephemeral symmetric passive association can be mobilized upon arrival
of a symmetric active packet with no matching association. That of a symmetric active packet with no matching association. That
association sends symmetric passive (mode 2) packets and persists association sends symmetric passive (mode 2) packets and persists
until error or timeout. Peers both push and pull synchronization to until error or timeout. Peers both push and pull synchronization to
and from each other. For the purposes of this document, a peer and from each other. For the purposes of this document, a peer
skipping to change at page 17, line 50 skipping to change at page 18, line 50
7.3. Packet Header Variables 7.3. Packet Header Variables
The most important state variables from an external point of view are The most important state variables from an external point of view are
the packet header variables described in Figure 7 and below. The NTP the packet header variables described in Figure 7 and below. The NTP
packet header consists of an integral number of 32-bit (4 octet) packet header consists of an integral number of 32-bit (4 octet)
words in network byte order. The packet format consists of three words in network byte order. The packet format consists of three
components, the header itself, one or more optional extension fields components, the header itself, one or more optional extension fields
and an optional message authentication code (MAC). The header and an optional message authentication code (MAC). The header
component is identical to the NTPv3 header and previous versions. component is identical to the NTPv3 header and previous versions.
The optional extension fields are used by the Autokey public key The optional extension fields are used by the Autokey public key
cryptographic algorithms described in [ref3]. The optional MAC is cryptographic algorithms described in [I-D.ietf-ntp-autokey]. The
used by both Autokey and the symmetric key cryptographic algorithm optional MAC is used by both Autokey and the symmetric key
described in this RFC. cryptographic algorithm described in this RFC.
+-----------+------------+-----------------------+ +-----------+------------+-----------------------+
| Name | Formula | Description | | Name | Formula | Description |
+-----------+------------+-----------------------+ +-----------+------------+-----------------------+
| leap | leap | leap indicator (LI) | | leap | leap | leap indicator (LI) |
| version | version | version number (VN) | | version | version | version number (VN) |
| mode | mode | mode | | mode | mode | mode |
| stratum | stratum | stratum | | stratum | stratum | stratum |
| poll | poll | poll exponent | | poll | poll | poll exponent |
| precision | rho | precision exponent | | precision | rho | precision exponent |
| rootdelay | delta_r | root delay | | rootdelay | delta_r | root delay |
| rootdisp | epsilon_r | root dispersion | | rootdisp | epsilon_r | root dispersion |
| refid | refid | reference ID | | refid | refid | reference ID |
| reftime | reftime | reference timestamp | | reftime | reftime | reference timestamp |
| org | T1 | origin timestamp | | org | T1 | origin timestamp |
| rec | T2 | receive timestamp | | rec | T2 | receive timestamp |
| xmt | T3 | transmit timestamp | | xmt | T3 | transmit timestamp |
| dst | T4 | destination timestamp | | dst | T4 | destination timestamp |
| keyid | keyid | key ID | | keyid | keyid | key ID |
| MAC | MAC | message digest | | dgst | dgst | message digest |
+-----------+------------+-----------------------+ +-----------+------------+-----------------------+
Figure 7: Packet Header Variables Figure 7: Packet Header Variables
The NTP packet is a UDP datagram[RFC0768]. Some fields use multiple The NTP packet is a UDP datagram[RFC0768]. Some fields use multiple
words and others are packed in smaller fields within a word. The NTP words and others are packed in smaller fields within a word. The NTP
packet header shown in Figure 8 has 12 words followed by optional packet header shown in Figure 8 has 12 words followed by optional
extension fields and finally an optional message authentication code extension fields and finally an optional message authentication code
(MAC) consisting of the key identifier field and message digest (MAC) consisting of the key identifier field and message digest
field. field.
skipping to change at page 19, line 47 skipping to change at page 20, line 47
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Extension Field 2 (variable) . . Extension Field 2 (variable) .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Identifier | | Key Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| MAC (128) | | dgst (128) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Packet Header Format Figure 8: Packet Header Format
The extension fields are used to add optional capabilities, for The extension fields are used to add optional capabilities, for
example, the Autokey security protocol [ref3]. The extension field example, the Autokey security protocol [I-D.ietf-ntp-autokey]. The
format is presented in order that the packet can be parsed without extension field format is presented in order that the packet can be
knowledge of the extension field functions. The MAC is used by both parsed without knowledge of the extension field functions. The MAC
Autokey and the symmetric key authentication scheme. is used by both Autokey and the symmetric key authentication scheme.
A list of the packet header variables is shown in Figure 7 and A list of the packet header variables is shown in Figure 7 and
described in detail below. Except for a minor variation when using described in detail below. Except for a minor variation when using
the IPv6 address family, these fields are backwards compatible with the IPv6 address family, these fields are backwards compatible with
NTPv3. The packet header fields apply to both transmitted packets (x NTPv3. The packet header fields apply to both transmitted packets (x
prefix) and received packets (r prefix). In Figure 8 the size of prefix) and received packets (r prefix). In Figure 8 the size of
some multiple-word fields is shown in bits if not the default 32 some multiple-word fields is shown in bits if not the default 32
bits. The basic header extends from the beginning of the packet to bits. The basic header extends from the beginning of the packet to
the end of the Transmit Timestamp field. the end of the Transmit Timestamp field.
The fields and associated packet variables (in parentheses) are The fields and associated packet variables (in parentheses) are
interpreted as follows: interpreted as follows:
LI Leap Indicator (leap): 2-bit integer warning of an impending leap LI Leap Indicator (leap): 2-bit integer warning of an impending leap
second to be inserted or deleted in the last minute of the current second to be inserted or deleted in the last minute of the current
month with values defined in Figure 9. month with values defined in Figure 9.
+-------+-------------------------------------------------+ +-------+----------------------------------------+
| Value | Meaning | | Value | Meaning |
+-------+-------------------------------------------------+ +-------+----------------------------------------+
| 0 | no warning | | 0 | no warning |
| 1 | last minute of the day has 61 seconds | | 1 | last minute of the day has 61 seconds |
| 2 | last minute of the day has 59 seconds | | 2 | last minute of the day has 59 seconds |
| 3 | alarm condition (the clock is not synchronized) | | 3 | unknown (clock unsynchronized) |
+-------+-------------------------------------------------+ +-------+----------------------------------------+
Figure 9: Leap Indicator Figure 9: Leap Indicator
VN Version Number (version): 3-bit integer representing the NTP VN Version Number (version): 3-bit integer representing the NTP
version number, currently 4. version number, currently 4.
Mode (mode): 3-bit integer representing the mode, with values defined Mode (mode): 3-bit integer representing the mode, with values defined
in Figure 10. in Figure 10.
+-------+--------------------------+ +-------+--------------------------+
skipping to change at page 22, line 18 skipping to change at page 23, line 18
Reference ID (refid): 32-bit code identifying the particular server Reference ID (refid): 32-bit code identifying the particular server
or reference clock. The interpretation depends on the value in the or reference clock. The interpretation depends on the value in the
stratum field. For packet stratum 0 (unspecified or invalid) this is stratum field. For packet stratum 0 (unspecified or invalid) this is
a four-character ASCII[RFC1345] string, called the kiss code, used a four-character ASCII[RFC1345] string, called the kiss code, used
for debugging and monitoring purposes. For stratum 1 (reference for debugging and monitoring purposes. For stratum 1 (reference
clock) this is a four-octet, left-justified, zero-padded ASCII string clock) this is a four-octet, left-justified, zero-padded ASCII string
assigned to the reference clock. The authoritative list of Reference assigned to the reference clock. The authoritative list of Reference
Identifiers is maintained by IANA, however any string beginning with Identifiers is maintained by IANA, however any string beginning with
the ASCII character "X" is reserved for unregistered experimentation the ASCII character "X" is reserved for unregistered experimentation
and developent.The identifiers in Figure 12 have been used as ASCII and development. The identifiers in Figure 12 have been used as
identifiers: ASCII identifiers:
+------+----------------------------------------------------------+ +------+----------------------------------------------------------+
| ID | Clock Source | | ID | Clock Source |
+------+----------------------------------------------------------+ +------+----------------------------------------------------------+
| GOES | Geosynchronous Orbit Environment Satellite | | GOES | Geosynchronous Orbit Environment Satellite |
| GPS | Global Position System | | GPS | Global Position System |
| GAL | Galileo Positioning System | | GAL | Galileo Positioning System |
| PPS | Generic pulse-per-second | | PPS | Generic pulse-per-second |
| IRIG | Inter-Range Instrumentation Group | | IRIG | Inter-Range Instrumentation Group |
| WWVB | LF Radio WWVB Ft. Collins, CO 60 kHz | | WWVB | LF Radio WWVB Ft. Collins, CO 60 kHz |
skipping to change at page 23, line 43 skipping to change at page 24, line 43
Digest. The message digest, or cryptosum, is calculated as in Digest. The message digest, or cryptosum, is calculated as in
[RFC1321] over all NTP header and optional extension fields, but not [RFC1321] over all NTP header and optional extension fields, but not
the MAC itself. the MAC itself.
Extension Field n: See Section 7.5 for a description of the format of Extension Field n: See Section 7.5 for a description of the format of
this field. this field.
Key Identifier (keyid): 32-bit unsigned integer used by the client Key Identifier (keyid): 32-bit unsigned integer used by the client
and server to designate a secret 128-bit MD5 key. and server to designate a secret 128-bit MD5 key.
Message Digest (digest): 128-bit bitstring computed by the keyed MD5 Message Digest (digest): 128-bit MD5 hash computed over the key
message digest computed over all the words in the header and followed by the NTP packet header and extensions fieds (but not the
extension fields, but not the MAC itself. Key Identifier or Message Digest fields).
It should be noted that the MAC computation used here differs from
those defined in [RFC1305] and [RFC4330] but is consistent with how
existing implementations generate a MAC.
7.4. The Kiss-o'-Death Packet 7.4. The Kiss-o'-Death Packet
If the Stratum field is 0, which implies unspecified or invalid, the If the Stratum field is 0, which implies unspecified or invalid, the
Reference Identifier field can be used to convey messages useful for Reference Identifier field can be used to convey messages useful for
status reporting and access control. These are called Kiss-o'-Death status reporting and access control. These are called Kiss-o'-Death
(KoD) packets and the ASCII messages they convey are called kiss (KoD) packets and the ASCII messages they convey are called kiss
codes. The KoD packets got their name because an early use was to codes. The KoD packets got their name because an early use was to
tell clients to stop sending packets that violate server access tell clients to stop sending packets that violate server access
controls. The kiss codes can provide useful information for an controls. The kiss codes can provide useful information for an
skipping to change at page 55, line 48 skipping to change at page 56, line 48
A SNTP client implementing the on-wire protocol has a single server A SNTP client implementing the on-wire protocol has a single server
and no dependent clients. It can operate with any subset of the NTP and no dependent clients. It can operate with any subset of the NTP
on-wire protocol, the simplest approach using only the transmit on-wire protocol, the simplest approach using only the transmit
timestamp of the server packet and ignoring all other fields. timestamp of the server packet and ignoring all other fields.
However, the additional complexity to implement the full on-wire However, the additional complexity to implement the full on-wire
protocol is minimal so that a full implementation is encouraged. protocol is minimal so that a full implementation is encouraged.
15. Security Considerations 15. Security Considerations
NTPv4 provides an optional authentication field that utilizes the MD5 NTP security requirements are even more stringent than most other
algorithm. MD5, as the case for SHA-1, is derived from MD4, which distributed services. First, the operation of the authentication
has long been known to be weak. In 2004, techniques for efficiently mechanism and the time synchronization mechanism are inextricably
finding collisions in MD5 were announced. A summary of the intertwined. Reliable time synchronization requires cryptographic
appropriateness of MD5 can be found in [ref8]. keys which are valid only over a designated time interval; but, time
intervals can be enforced only when participating servers and clients
are reliably synchronized to UTC. In addition, the NTP subnet is
hierarchical by nature, so time and trust flow from the primary
servers at the root through secondary servers to the clients at the
leaves.
An NTP client can claim to have authentic time to dependent
applications only if all servers on the path to the primary servers
are authenticated. In NTP each server authenticates the next lower
stratum servers and authenticates by induction the lowest stratum
(primary) servers. It is important to note that authentication in
the context of NTP does not necessarily imply the time is correct. A
NTP client mobilizes a number of concurrent associations with
different servers and uses a crafted agreement algorithm to pluck
truechimers from the population possibly including falsetickers.
The NTP specification assumes the goal of the intruder is to inject
false time values, disrupt the protocol or clog the network, servers
or clients with spurious packets that exhaust resources and deny
service to legitimate applications. There are a number of defense
mechanisms already built in the NTP architecture, protocol and
algorithms. The on-wire timestamp exchange scheme is inherently
resistant to spoofing, packet loss and replay attacks. The
engineered clock filter, selection and clustering algorithms are
designed to defend against evil cliques of Byzantine traitors. While
not necessarily designed to defeat determined intruders, these
algorithms and accompanying sanity checks have functioned well over
the years to deflect improperly operating but presumably friendly
scenarios. However, these mechanisms do not securely identify and
authenticate servers to clients. Without specific further
protection, an intruder can inject any or all of the following
attacks:
1. An intruder can intercept and archive packets forever, as well as
all the public values ever generated and transmitted over the
net.
2. An intruder can generate packets faster than the server, network
or client can process them, especially if they require expensive
cryptographic computations.
3. In a wiretap attack the intruder can intercept, modify and replay
a packet. However, it cannot permanently prevent onward
transmission of the original packet; that is, it cannot break the
wire, only tell lies and congest it. Generally, the modified
packet cannot arrive at the victim before the original packet,
nor does it have the server private keys or identity parameters.
4. In a middleman or masquerade attack the intruder is positioned
between the server and client, so it can intercept, modify and
replay a packet and prevent onward transmission of the original
packet. However, the middleman does not have the server private
keys.
The NTP security model assumes the following possible limitations:
1. The running times for public key algorithms are relatively long
and highly variable. In general, the performance of the time
synchronization function is badly degraded if these algorithms
must be used for every NTP packet.
2. In some modes of operation it is not feasible for a server to
retain state variables for every client. It is however feasible
to regenerated them for a client upon arrival of a packet from
that client.
3. The lifetime of cryptographic values must be enforced, which
requires a reliable system clock. However, the sources that
synchronize the system clock must be trusted. This circular
interdependence of the timekeeping and authentication functions
requires special handling.
4. Client security functions must involve only public values
transmitted over the net. Private values must never be disclosed
beyond the machine on which they were created, except in the case
of a special trusted agent (TA) assigned for this purpose.
Unlike the Secure Shell (SSH) security model, where the client must
be securely authenticated to the server, in NTP the server must be
securely authenticated to the client. In SSH each different
interface address can be bound to a different name, as returned by a
reverse-DNS query. In this design separate public/private key pairs
may be required for each interface address with a distinct name. A
perceived advantage of this design is that the security compartment
can be different for each interface. This allows a firewall, for
instance, to require some interfaces to authenticate the client and
others not.
In the case of NTP as specified herein, NTP broadcast clients are In the case of NTP as specified herein, NTP broadcast clients are
vulnerable to disruption by misbehaving or hostile SNTP or NTP vulnerable to disruption by misbehaving or hostile SNTP or NTP
broadcast servers elsewhere in the Internet. Access controls and/or broadcast servers elsewhere in the Internet. Such disruption can be
cryptographic authentication means should be provided for additional minimized by several approaches. Filtering can be employed to limit
security in such cases. the access of NTP clients to known or trusted NTP broadcast servers.
Such filtering will prevent malicious traffic from reaching the NTP
clients. Cryptographic authentication at the client will only allow
timing information from properly signed NTP messages to be utilized
in synchronzing its clock. Higher levels of authentication may be
gained by the use of the Autokey mechanism[I-D.ietf-ntp-autokey].
Section 8 describes a potential security concern with the replay of Section 8 describes a potential security concern with the replay of
client requests. Following the recommendations in that section client requests. Following the recommendations in that section
provides protection against such attacks. provides protection against such attacks.
It should be noted that this specification is describing an existing
implementation. While the security shortfalls of the MD5 algorithm
are well-known, its use in the NTP specification is consistent with
widescale deployment in the Internet community.
16. IANA Considerations 16. IANA Considerations
UDP/TCP Port 123 was previously assigned by IANA for this protocol. UDP/TCP Port 123 was previously assigned by IANA for this protocol.
The IANA has assigned the IPv4 multicast group address 224.0.1.1 and The IANA has assigned the IPv4 multicast group address 224.0.1.1 and
the IPv6 multicast address ending :101 for NTP. This document the IPv6 multicast address ending :101 for NTP. This document
introduces NTP extension fields allowing for the development of introduces NTP extension fields allowing for the development of
future extensions to the protocol, where a particular extension is to future extensions to the protocol, where a particular extension is to
be identified by the Field Type sub-field within the extension field. be identified by the Field Type sub-field within the extension field.
IANA is requested to establish and maintain a registry for Extension IANA is requested to establish and maintain a registry for Extension
Field Types associated with this protocol, populating this registry Field Types associated with this protocol, populating this registry
with no initial entries. As future needs arise, new Extension Field with no initial entries. As future needs arise, new Extension Field
Types may be defined. Following the policies outlined in [RFC2434], Types may be defined. Following the policies outlined in [RFC5226],
new values are to be defined by IETF consensus. new values are to be defined by IETF Review.
The IANA is requested to create a new registry for NTP Reference The IANA is requested to create a new registry for NTP Reference
Identifier codes. This should include the current codes defined in Identifier codes. This should include the current codes defined in
Section 7.3, and may be extended on a FCFS basis. The format of the Section 7.3, and may be extended on a First-Come-First-Serve (FCFS)
registry is: basis. The format of the registry is:
+------+----------------------------------------------------------+ +------+----------------------------------------------------------+
| ID | Clock Source | | ID | Clock Source |
+------+----------------------------------------------------------+ +------+----------------------------------------------------------+
| GOES | Geosynchronous Orbit Environment Satellite | | GOES | Geosynchronous Orbit Environment Satellite |
| GPS | Global Position System | | GPS | Global Position System |
| ... | ... | | ... | ... |
+------+----------------------------------------------------------+ +------+----------------------------------------------------------+
Figure 32: Reference Identifier Codes Figure 32: Reference Identifier Codes
skipping to change at page 57, line 28 skipping to change at page 60, line 28
17. Acknowledgements 17. Acknowledgements
The editors would like to thank Karen O'Donoghue, Brian Haberman, The editors would like to thank Karen O'Donoghue, Brian Haberman,
Greg Dowd, Mark Elliot, Harlan Stenn, Yaakov Stein, Stewart Bryant, Greg Dowd, Mark Elliot, Harlan Stenn, Yaakov Stein, Stewart Bryant,
and Danny Mayer for technical reviews and specific text contributions and Danny Mayer for technical reviews and specific text contributions
to this document. to this document.
18. References 18. References
18.1. Informative References 18.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
18.2. Informative References
[CGPM] Bureau International des Poids et Mesures, "Comptes Rendus [CGPM] Bureau International des Poids et Mesures, "Comptes Rendus
de la 15e CGPM", 1976. de la 15e CGPM", 1976.
[I-D.ietf-ntp-autokey]
Haberman, B. and D. Mills, "Network Time Protocol Version
4 Autokey Specification", draft-ietf-ntp-autokey-06 (work
in progress), July 2009.
[ITU-R_TF.460] [ITU-R_TF.460]
International Telecommunications Union, "ITU-R TF.460 International Telecommunications Union, "ITU-R TF.460
Standard-frequency and time-signal emissions", Standard-frequency and time-signal emissions",
February 2002. February 2002.
[RFC1305] Mills, D., "Network Time Protocol (Version 3) [RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992. Specification, Implementation", RFC 1305, March 1992.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC1345] Simonsen, K., "Character Mnemonics and Character Sets",
IANA Considerations Section in RFCs", BCP 26, RFC 2434, RFC 1345, June 1992.
October 1998.
[RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 [RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
for IPv4, IPv6 and OSI", RFC 4330, January 2006. for IPv4, IPv6 and OSI", RFC 4330, January 2006.
[ref3] Mills, D.L., "The Autokey security architecture, protocol [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
and algorithms. Electrical and Computer Engineering IANA Considerations Section in RFCs", BCP 26, RFC 5226,
Technical Report 06-1-1", NDSS , January 2006. May 2008.
[ref6] Marzullo and S. Owicki, "Maintaining the time in a [ref6] Marzullo and S. Owicki, "Maintaining the time in a
distributed system.", ACM Operating Systems Review 19 , distributed system.", ACM Operating Systems Review 19 ,
July 1985. July 1985.
[ref7] Mills, D.L., "Computer Network Time Synchronization - the [ref7] Mills, D.L., "Computer Network Time Synchronization - the
Network Time Protocol. CRC Press, 304pp.", 2006. Network Time Protocol. CRC Press, 304pp.", 2006.
[ref8] Bellovin, S. and E. Rescorla, Proceedings of the 13th
annual ISOC Network and Distributed System Security
Symposium, "Deploying a new Hash Algorithm",
February 2006.
[ref9] Mills, D.L., Electrical and Computer Engineering Technical [ref9] Mills, D.L., Electrical and Computer Engineering Technical
Report 06-6-1, NDSS, June 2006., "Network Time Protocol Report 06-6-1, NDSS, June 2006., "Network Time Protocol
Version 4 Reference and Implementation Guide.", 2006. Version 4 Reference and Implementation Guide.", 2006.
18.2. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC1345] Simonsen, K., "Character Mnemonics and Character Sets",
RFC 1345, June 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Appendix A. Code Skeleton Appendix A. Code Skeleton
This appendix is intended to describe the protocol and algorithms of This appendix is intended to describe the protocol and algorithms of
an implementation in a general way using what is called a code an implementation in a general way using what is called a code
skeleton program. This consists of a set of definitions, structures skeleton program. This consists of a set of definitions, structures
and code fragments which illustrate the protocol operations without and code fragments which illustrate the protocol operations without
the complexities of an actual implementation of the protocol. This the complexities of an actual implementation of the protocol. This
program is not an executable and is not designed to run in the program is not an executable and is not designed to run in the
ordinary sense. It is designed to be compiled only in order to ordinary sense.
verify consistent variable and type usage.
Most of the features of the reference implementation are included Most of the features of the reference implementation are included
here, with the following exceptions: There are no provisions for here, with the following exceptions: There are no provisions for
reference clocks or public key (Autokey) cryptography. There is no reference clocks or public key (Autokey) cryptography. There is no
huff-n'-puff filter, anti-clockhop hysteresis or monitoring huff-n'-puff filter, anti-clockhop hysteresis or monitoring
provisions. Many of the values that can be tinkered in the reference provisions. Many of the values that can be tinkered in the reference
implementation are assumed constants here. There are only minimal implementation are assumed constants here. There are only minimal
provisions for the kiss-o'death packet and no responding code. provisions for the kiss-o'death packet and no responding code.
The program is not intended to be fast or compact, just to The program is not intended to be fast or compact, just to
skipping to change at page 59, line 29 skipping to change at page 62, line 24
in order below along with definitions and variables specific to each in order below along with definitions and variables specific to each
process. process.
A.1. Global Definitions A.1. Global Definitions
A.1.1. Definitions, Constants, Parameters A.1.1. Definitions, Constants, Parameters
#include <math.h> /* avoids complaints about sqrt() */ #include <math.h> /* avoids complaints about sqrt() */
#include <sys/time.h> /* for gettimeofday() and friends */ #include <sys/time.h> /* for gettimeofday() and friends */
#include <stdlib.h> /* for malloc() and friends */ #include <stdlib.h> /* for malloc() and friends */
#include <string.h> /* for memset() */
/* /*
* Data types * Data types
* *
* This program assumes the int data type is 32 bits and the long data * This program assumes the int data type is 32 bits and the long data
* type is 64 bits. The native data type used in most calculations is * type is 64 bits. The native data type used in most calculations is
* floating double. The data types used in some packet header fields * floating double. The data types used in some packet header fields
* require conversion to and from this representation. Some header * require conversion to and from this representation. Some header
* fields involve partitioning an octet, here represented by individual * fields involve partitioning an octet, here represented by individual
* octets. * octets.
skipping to change at page 60, line 4 skipping to change at page 62, line 49
* subtraction, yielding a signed 31-bit difference. The 32-bit NTP * subtraction, yielding a signed 31-bit difference. The 32-bit NTP
* short format used in delay and dispersion calculations is seconds and * short format used in delay and dispersion calculations is seconds and
* fraction with the decimal point to the left of bit 16. The only * fraction with the decimal point to the left of bit 16. The only
* operations permitted with these values are addition and * operations permitted with these values are addition and
* multiplication by a constant. * multiplication by a constant.
* *
* The IPv4 address is 32 bits, while the IPv6 address is 128 bits. The * The IPv4 address is 32 bits, while the IPv6 address is 128 bits. The
* message digest field is 128 bits as constructed by the MD5 algorithm. * message digest field is 128 bits as constructed by the MD5 algorithm.
* The precision and poll interval fields are signed log2 seconds. * The precision and poll interval fields are signed log2 seconds.
*/ */
typedef unsigned long long tstamp; /* NTP timestamp format */
typedef unsigned long tstamp; /* NTP timestamp format */
typedef unsigned int tdist; /* NTP short format */ typedef unsigned int tdist; /* NTP short format */
typedef unsigned long ipaddr; /* IPv4 or IPv6 address */ typedef unsigned long ipaddr; /* IPv4 or IPv6 address */
typedef unsigned long digest; /* md5 digest */ typedef unsigned long digest; /* md5 digest */
typedef signed char s_char; /* precision and poll interval (log2) */ typedef signed char s_char; /* precision and poll interval (log2) */
/* /*
* Timestamp conversion macroni * Timestamp conversion macroni
*/ */
#define FRIC 65536. /* 2^16 as a double */ #define FRIC 65536. /* 2^16 as a double */
#define D2FP(r) ((tdist)((r) * FRIC)) /* NTP short */ #define D2FP(r) ((tdist)((r) * FRIC)) /* NTP short */
#define FP2D(r) ((double)(r) / FRIC) #define FP2D(r) ((double)(r) / FRIC)
#define FRAC 4294967296. /* 2^32 as a double */ #define FRAC 4294967296. /* 2^32 as a double */
#define D2LFP(a) ((tstamp)((a) * FRAC)) /* NTP timestamp */ #define D2LFP(a) ((tstamp)((a) * FRAC)) /* NTP timestamp */
#define LFP2D(a) ((double)(a) / FRAC) #define LFP2D(a) ((double)(a) / FRAC)
#define U2LFP(a) ((a).tv_sec + JAN_1970 << 32 + (unsigned long) \ #define U2LFP(a) ((a).tv_sec + JAN_1970 << 32 + (unsigned long long) \
((a).tv_usec / 1e6 * FRAC)) ((a).tv_usec / 1e6 * FRAC))
/* /*
* Arithmetic conversions * Arithmetic conversions
*/ */
#define LOG2D(a) ((a) < 0 ? 1. / (1L << -(a)) : \ #define LOG2D(a) ((a) < 0 ? 1. / (1L << -(a)) : \
1L << (a)) /* poll, etc. */ 1L << (a)) /* poll, etc. */
#define SQUARE(x) (x * x) #define SQUARE(x) (x * x)
#define SQRT(x) (sqrt(x)) #define SQRT(x) (sqrt(x))
/* /*
skipping to change at page 61, line 7 skipping to change at page 64, line 4
#define MINCLOCK 3 /* minimum manycast survivors */ #define MINCLOCK 3 /* minimum manycast survivors */
#define MAXCLOCK 10 /* maximum manycast candidates */ #define MAXCLOCK 10 /* maximum manycast candidates */
#define TTLMAX 8 /* max ttl manycast */ #define TTLMAX 8 /* max ttl manycast */
#define BEACON 15 /* max interval between beacons */ #define BEACON 15 /* max interval between beacons */
#define PHI 15e-6 /* % frequency tolerance (15 PPM) */ #define PHI 15e-6 /* % frequency tolerance (15 PPM) */
#define NSTAGE 8 /* clock register stages */ #define NSTAGE 8 /* clock register stages */
#define NMAX 50 /* maximum number of peers */ #define NMAX 50 /* maximum number of peers */
#define NSANE 1 /* % minimum intersection survivors */ #define NSANE 1 /* % minimum intersection survivors */
#define NMIN 3 /* % minimum cluster survivors */ #define NMIN 3 /* % minimum cluster survivors */
/* /*
* Global return values * Global return values
*/ */
#define TRUE 1 /* boolean true */ #define TRUE 1 /* boolean true */
#define FALSE 0 /* boolean false */ #define FALSE 0 /* boolean false */
#define NULL 0 /* empty pointer */
/* /*
* Local clock process return codes * Local clock process return codes
*/ */
#define IGNORE 0 /* ignore */ #define IGNORE 0 /* ignore */
#define SLEW 1 /* slew adjustment */ #define SLEW 1 /* slew adjustment */
#define STEP 2 /* step adjustment */ #define STEP 2 /* step adjustment */
#define PANIC 3 /* panic - no adjustment */ #define PANIC 3 /* panic - no adjustment */
/* /*
skipping to change at page 62, line 30 skipping to change at page 65, line 24
/* /*
* Clock state definitions * Clock state definitions
*/ */
#define NSET 0 /* clock never set */ #define NSET 0 /* clock never set */
#define FSET 1 /* frequency set from file */ #define FSET 1 /* frequency set from file */
#define SPIK 2 /* spike detected */ #define SPIK 2 /* spike detected */
#define FREQ 3 /* frequency mode */ #define FREQ 3 /* frequency mode */
#define SYNC 4 /* clock synchronized */ #define SYNC 4 /* clock synchronized */
#define min(a, b) ((a) < (b) ? (a) : (b))
#define max(a, b) ((a) < (b) ? (b) : (a))
A.1.2. Packet Data Structures A.1.2. Packet Data Structures
/* /*
* The receive and transmit packets may contain an optional message * The receive and transmit packets may contain an optional message
* authentication code (MAC) consisting of a key identifier (keyid) and * authentication code (MAC) consisting of a key identifier (keyid) and
* message digest (mac). NTPv4 supports optional extension fields which * message digest (mac). NTPv4 supports optional extension fields which
* are inserted after the the header and before the MAC, but these are * are inserted after the the header and before the MAC, but these are
* not described here. * not described here.
* *
* Receive packet * Receive packet
skipping to change at page 63, line 15 skipping to change at page 66, line 12
char poll; /* poll interval */ char poll; /* poll interval */
s_char precision; /* precision */ s_char precision; /* precision */
tdist rootdelay; /* root delay */ tdist rootdelay; /* root delay */
tdist rootdisp; /* root dispersion */ tdist rootdisp; /* root dispersion */
char refid; /* reference ID */ char refid; /* reference ID */
tstamp reftime; /* reference time */ tstamp reftime; /* reference time */
tstamp org; /* origin timestamp */ tstamp org; /* origin timestamp */
tstamp rec; /* receive timestamp */ tstamp rec; /* receive timestamp */
tstamp xmt; /* transmit timestamp */ tstamp xmt; /* transmit timestamp */
int keyid; /* key ID */ int keyid; /* key ID */
digest mac; /* message digest */ digest dgst; /* message digest */
tstamp dst; /* destination timestamp */ tstamp dst; /* destination timestamp */
} r; } r;
/* /*
* Transmit packet * Transmit packet
*/ */
struct x { struct x {
ipaddr dstaddr; /* source (local) address */ ipaddr dstaddr; /* source (local) address */
ipaddr srcaddr; /* destination (remote) address */ ipaddr srcaddr; /* destination (remote) address */
char version; /* version number */ char version; /* version number */
skipping to change at page 63, line 39 skipping to change at page 66, line 36
char poll; /* poll interval */ char poll; /* poll interval */
s_char precision; /* precision */ s_char precision; /* precision */
tdist rootdelay; /* root delay */ tdist rootdelay; /* root delay */
tdist rootdisp; /* root dispersion */ tdist rootdisp; /* root dispersion */
char refid; /* reference ID */ char refid; /* reference ID */
tstamp reftime; /* reference time */ tstamp reftime; /* reference time */
tstamp org; /* origin timestamp */ tstamp org; /* origin timestamp */
tstamp rec; /* receive timestamp */ tstamp rec; /* receive timestamp */
tstamp xmt; /* transmit timestamp */ tstamp xmt; /* transmit timestamp */
int keyid; /* key ID */ int keyid; /* key ID */
digest mac; /* message digest */ digest dgst; /* message digest */
} x; } x;
A.1.3. Association Data Structures A.1.3. Association Data Structures
/* /*
* Filter stage structure. Note the t member in this and other * Filter stage structure. Note the t member in this and other
* structures refers to process time, not real time. Process time * structures refers to process time, not real time. Process time
* increments by one second for every elapsed second of real time. * increments by one second for every elapsed second of real time.
*/ */
struct f { struct f {
skipping to change at page 71, line 7 skipping to change at page 73, line 7
} }
return (NULL); return (NULL);
} }
/* /*
* md5() - compute message digest * md5() - compute message digest
*/ */
digest digest
md5( md5(
int keyid /* key identifier */ int keyid /* key identifier */
) )
{ {
/* /*
* Compute a keyed cryptographic message digest. The key * Compute a keyed cryptographic message digest. The key
* identifier is associated with a key in the local key cache. * identifier is associated with a key in the local key cache.
* The key is prepended to the packet header and extension fields * The key is prepended to the packet header and extension fields
* and the result hashed by the MD5 algorithm as described in * and the result hashed by the MD5 algorithm as described in
* RFC-1321. Return a MAC consisting of the 32-bit key ID * RFC-1321. Return a MAC consisting of the 32-bit key ID
* concatenated with the 128-bit digest. * concatenated with the 128-bit digest.
*/ */
return (/* MD5 digest */ 0); return (/* MD5 digest */ 0);
} }
A.3. Kernel Input/Output Interface A.3. Kernel Input/Output Interface
/* /*
* Kernel interface to transmit and receive packets. Details are * Kernel interface to transmit and receive packets. Details are
* deliberately vague and depend on the operating system. * deliberately vague and depend on the operating system.
* *
* recv_packet - receive packet from network * recv_packet - receive packet from network
*/ */
skipping to change at page 74, line 10 skipping to change at page 76, line 10
#define BDELAY .004 /* broadcast delay (s) */ #define BDELAY .004 /* broadcast delay (s) */
/* /*
* Dispatch codes * Dispatch codes
*/ */
#define ERR -1 /* error */ #define ERR -1 /* error */
#define DSCRD 0 /* discard packet */ #define DSCRD 0 /* discard packet */
#define PROC 1 /* process packet */ #define PROC 1 /* process packet */
#define BCST 2 /* broadcast packet */ #define BCST 2 /* broadcast packet */
#define FXMIT 3 /* client packet */ #define FXMIT 3 /* client packet */
#define NEWPS 4 /* new symmetric passive client */ #define MANY 4 /* manycast packet */
#define NEWBC 5 /* new broadcast client */ #define NEWPS 5 /* new symmetric passive client */
#define NEWBC 6 /* new broadcast client */
/* /*
* Dispatch matrix * Dispatch matrix
* active passv client server bcast */ * active passv client server bcast */
int table[7][5] = { int table[7][5] = {
/* nopeer */ { NEWPS, DSCRD, FXMIT, MANY, NEWBC }, /* nopeer */ { NEWPS, DSCRD, FXMIT, MANY, NEWBC },
/* active */ { PROC, PROC, DSCRD, DSCRD, DSCRD }, /* active */ { PROC, PROC, DSCRD, DSCRD, DSCRD },
/* passv */ { PROC, ERR, DSCRD, DSCRD, DSCRD }, /* passv */ { PROC, ERR, DSCRD, DSCRD, DSCRD },
/* client */ { DSCRD, DSCRD, DSCRD, PROC, DSCRD }, /* client */ { DSCRD, DSCRD, DSCRD, PROC, DSCRD },
/* server */ { DSCRD, DSCRD, DSCRD, DSCRD, DSCRD }, /* server */ { DSCRD, DSCRD, DSCRD, DSCRD, DSCRD },
skipping to change at page 76, line 30 skipping to change at page 78, line 31
/* /*
* Client packet and no association. Send server reply without * Client packet and no association. Send server reply without
* saving state. * saving state.
*/ */
case FXMIT: case FXMIT:
/* /*
* If unicast destination address, send server packet. * If unicast destination address, send server packet.
* If authentication fails, send a crypto-NAK packet. * If authentication fails, send a crypto-NAK packet.
/* */
if (/* not multicast dstaddr */0) {
/* not multicast dstaddr */
if (!IN_MULTICAST(dstaddr)) {
if (AUTH(p->flags & P_NOTRUST, auth)) if (AUTH(p->flags & P_NOTRUST, auth))
fast_xmit(r, M_SERV, auth); fast_xmit(r, M_SERV, auth);
else if (auth == A_ERROR) else if (auth == A_ERROR)
fast_xmit(r, M_SERV, A_CRYPTO); fast_xmit(r, M_SERV, A_CRYPTO);
return; /* M_SERV packet sent */ return; /* M_SERV packet sent */
} }
/* /*
* This must be manycast. Do not respond if we are not * This must be manycast. Do not respond if we are not
* synchronized or if our stratum is above the * synchronized or if our stratum is above the
skipping to change at page 77, line 23 skipping to change at page 79, line 26
* packet is authentic. Details omitted. * packet is authentic. Details omitted.
*/ */
case MANY: case MANY:
if (!AUTH(p->flags & (P_NOTRUST | P_NOPEER), auth)) if (!AUTH(p->flags & (P_NOTRUST | P_NOPEER), auth))
return; /* authentication error */ return; /* authentication error */
p = mobilize(r->srcaddr, r->dstaddr, r->version, M_CLNT, p = mobilize(r->srcaddr, r->dstaddr, r->version, M_CLNT,
r->keyid, P_EPHEM); r->keyid, P_EPHEM);
break; break;
/* /*
* New symmetric passive association. It is mobilized in the same * New symmetric passive association. It is mobilized in the same
* version as in the packet. If authentication fails, send a * version as in the packet. If authentication fails, send a
* crypto-NAK packet. If restrict no-moblize, send a symmetric * crypto-NAK packet. If restrict no-moblize, send a symmetric
* active packet instead. * active packet instead.
*/ */
case NEWPS: case NEWPS:
if (!AUTH(p->flags & P_NOTRUST, auth)) { if (!AUTH(p->flags & P_NOTRUST, auth)) {
if (auth == A_ERROR) if (auth == A_ERROR)
fast_xmit(r, M_SACT, A_CRYPTO); fast_xmit(r, M_SACT, A_CRYPTO);
return; /* crypto-NAK packet sent */ return; /* crypto-NAK packet sent */
} }
if (!AUTH(p->flags & P_NOPEER, auth)) { if (!AUTH(p->flags & P_NOPEER, auth)) {
fast_xmit(r, M_SACT, auth); fast_xmit(r, M_SACT, auth);
return; /* M_SACT packet sent */ return; /* M_SACT packet sent */
} }
skipping to change at page 83, line 19 skipping to change at page 85, line 24
p->t) < 2 * s.poll) p->t) < 2 * s.poll)
return; return;
p->t = f[0].t; p->t = f[0].t;
if (p->burst == 0) if (p->burst == 0)
clock_select(); clock_select();
return; return;
} }
/* /*
* root_dist() - calculate root distance
*/
double
root_dist(
struct p *p /* peer structure pointer */
)
{
/*
* The root synchronization distance is the maximum error due to
* all causes of the local clock relative to the primary server.
* It is defined as half the total delay plus total dispersion
* plus peer jitter.
*/
return (max(MINDISP, p->rootdelay + p->delay) / 2 +
p->rootdisp + p->disp + PHI * (c.t - p->t) + p->jitter);
}
/*
* fit() - test if association p is acceptable for synchronization * fit() - test if association p is acceptable for synchronization
*/ */
int int
fit( fit(
struct p *p /* peer structure pointer */ struct p *p /* peer structure pointer */
) )
{ {
/* /*
* A stratum error occurs if (1) the server has never been * A stratum error occurs if (1) the server has never been
* synchronized, (2) the server stratum is invalid. * synchronized, (2) the server stratum is invalid.
skipping to change at page 86, line 32 skipping to change at page 88, line 19
* If the authentication code is A.NONE, include only the * If the authentication code is A.NONE, include only the
* header; if A.CRYPTO, send a crypto-NAK; if A.OK, send a valid * header; if A.CRYPTO, send a crypto-NAK; if A.OK, send a valid
* MAC. Use the key ID in the received packet and the key in the * MAC. Use the key ID in the received packet and the key in the
* local key cache. * local key cache.
*/ */
if (auth != A_NONE) { if (auth != A_NONE) {
if (auth == A_CRYPTO) { if (auth == A_CRYPTO) {
x.keyid = 0; x.keyid = 0;
} else { } else {
x.keyid = r->keyid; x.keyid = r->keyid;
x.mac = md5(x.keyid); x.dgst = md5(x.keyid);
} }
} }
xmit_packet(&x); xmit_packet(&x);
} }
A.5.4. access() A.5.4. access()
/* /*
* access() - determine access restrictions * access() - determine access restrictions
*/ */
int int
access( access(
struct r *r /* receive packet pointer */ struct r *r /* receive packet pointer */
) )
{ {
skipping to change at page 87, line 31 skipping to change at page 89, line 4
return (/* access bits */ 0); return (/* access bits */ 0);
} }
A.5.5. System Process A.5.5. System Process
A.5.5.1. clock_select() A.5.5.1. clock_select()
/* /*
* clock_select() - find the best clocks * clock_select() - find the best clocks
*/ */
void void
clock_select() { clock_select() {
struct p *p, *osys; /* peer structure pointers */ struct p *p, *osys; /* peer structure pointers */
double low, high; /* correctness interval extents */ double low, high; /* correctness interval extents */
int allow, found, chime; /* used by intersection algorithm */ int allow, found, chime; /* used by intersection algorithm */
int n, i, j; int n, i, j;
/* /*
* We first cull the falsetickers from the server population, * We first cull the falsetickers from the server population,
* leaving only the truechimers. The correctness interval for * leaving only the truechimers. The correctness interval for
* association p is the interval from offset - root_dist() to * association p is the interval from offset - root_dist() to
* offset + root_dist(). The object of the game is to find a * offset + root_dist(). The object of the game is to find a
* majority clique; that is, an intersection of correctness * majority clique; that is, an intersection of correctness
* intervals numbering more than half the server population. * intervals numbering more than half the server population.
* *
* First construct the chime list of tuples (p, type, edge) as * First construct the chime list of tuples (p, type, edge) as
skipping to change at page 93, line 16 skipping to change at page 95, line 16
clock_update( clock_update(
struct p *p /* peer structure pointer */ struct p *p /* peer structure pointer */
) )
{ {
double dtemp; double dtemp;
/* /*
* If this is an old update, for instance as the result of a * If this is an old update, for instance as the result of a
* system peer change, avoid it. We never use an old sample or * system peer change, avoid it. We never use an old sample or
* the same sample twice. * the same sample twice.
* */
if (s.t >= p->t) if (s.t >= p->t)
return; return;
/* /*
* Combine the survivor offsets and update the system clock; the * Combine the survivor offsets and update the system clock; the
* local_clock() routine will tell us the good or bad news. * local_clock() routine will tell us the good or bad news.
*/ */
s.t = p->t; s.t = p->t;
clock_combine(); clock_combine();
switch (local_clock(p, s.offset)) { switch (local_clock(p, s.offset)) {
skipping to change at page 108, line 49 skipping to change at page 110, line 49
* of the association and the key in the local key cache. If * of the association and the key in the local key cache. If
* something breaks, like a missing trusted key, don't send the * something breaks, like a missing trusted key, don't send the
* packet; just reset the association and stop until the problem * packet; just reset the association and stop until the problem
* is fixed. * is fixed.
*/ */
if (p->keyid) if (p->keyid)
if (/* p->keyid invalid */ 0) { if (/* p->keyid invalid */ 0) {
clear(p, X_NKEY); clear(p, X_NKEY);
return; return;
} }
x.mac = md5(p->keyid); x.dgst = md5(p->keyid);
xmit_packet(&x); xmit_packet(&x);
} }
Authors' Addresses Authors' Addresses
Jack Burbank (editor) Jack Burbank
The Johns Hopkins University Applied Physics Laboratory The Johns Hopkins University Applied Physics Laboratory
11100 Johns Hopkins Road 11100 Johns Hopkins Road
Laurel, MD 20723-6099 Laurel, MD 20723-6099
US US
Phone: +1 443 778 7127 Phone: +1 443 778 7127
Email: jack.burbank@jhuapl.edu Email: jack.burbank@jhuapl.edu
William Kasch (editor) William Kasch
The Johns Hopkins University Applied Physics Laboratory The Johns Hopkins University Applied Physics Laboratory
11100 Johns Hopkins Road 11100 Johns Hopkins Road
Laurel, MD 20723-6099 Laurel, MD 20723-6099
US US
Phone: +1 443 778 7463 Phone: +1 443 778 7463
Email: william.kasch@jhuapl.edu Email: william.kasch@jhuapl.edu
Jim Martin (editor) Jim Martin (editor)
Woven Systems Daedelus Group
2455 Augustine Drive, Suite 211 411 Park Avenue, Unit 118
Santa Clara, CA 95054 Santa Jose, CA 95110
US US
Phone: +1 408 654-8900 x131 Email: jim@daedelus.com
Email: jim@wovensystems.com
Dr. David L. Mills Dr. David L. Mills
University of Delaware University of Delaware
Newark, DE 19716 Newark, DE 19716
US US
Phone: +1 302 831 8247 Phone: +1 302 831 8247
Email: mills@udel.edu Email: mills@udel.edu
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 55 change blocks. 
213 lines changed or deleted 314 lines changed or added

This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/