draft-ietf-ntp-mode-6-cmds-05.txt   draft-ietf-ntp-mode-6-cmds-06.txt 
Network Working Group D. Mills Network Working Group B. Haberman, Ed.
Internet-Draft University of Delaware Internet-Draft JHU
Intended status: Informational B. Haberman, Ed. Intended status: Informational September 27, 2018
Expires: September 27, 2018 JHU Expires: March 31, 2019
March 26, 2018
Control Messages Protocol for Use with Network Time Protocol Version 4 Control Messages Protocol for Use with Network Time Protocol Version 4
draft-ietf-ntp-mode-6-cmds-05 draft-ietf-ntp-mode-6-cmds-06
Abstract Abstract
This document describes the structure of the control messages used This document describes the structure of the control messages that
with the Network Time Protocol. These control messages can be used were historically used with the Network Time Protocol before the
to monitor and control the Network Time Protocol application running advent of more modern control and management approaches. These
on any IP network attached computer. The information in this control messages have been used to monitor and control the Network
document was originally described in Appendix B of RFC 1305. The Time Protocol application running on any IP network attached
goal of this document is to provide a historic description of the computer. The information in this document was originally described
control messages as described in RFC 1305 and any additional commands in Appendix B of RFC 1305. The goal of this document is to provide a
implemented in NTP. current, but historic, description of the control messages as
described in RFC 1305 and any additional commands implemented in NTP.
The publication of this document is not meant to encourage the
developement and deployment of these control messages. This document
is only providing a current reference for these control messages
given the current status of RFC 1305.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on September 27, 2018. This Internet-Draft will expire on March 31, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 23 skipping to change at page 2, line 29
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Control Message Overview . . . . . . . . . . . . . . . . 3 1.1. Control Message Overview . . . . . . . . . . . . . . . . 3
1.2. Remote Facility Message Overview . . . . . . . . . . . . 4 1.2. Remote Facility Message Overview . . . . . . . . . . . . 4
2. NTP Control Message Format . . . . . . . . . . . . . . . . . 4 2. NTP Control Message Format . . . . . . . . . . . . . . . . . 5
3. Status Words . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Status Words . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. System Status Word . . . . . . . . . . . . . . . . . . . 8 3.1. System Status Word . . . . . . . . . . . . . . . . . . . 8
3.2. Peer Status Word . . . . . . . . . . . . . . . . . . . . 10 3.2. Peer Status Word . . . . . . . . . . . . . . . . . . . . 10
3.3. Clock Status Word . . . . . . . . . . . . . . . . . . . . 12 3.3. Clock Status Word . . . . . . . . . . . . . . . . . . . . 12
3.4. Error Status Word . . . . . . . . . . . . . . . . . . . . 12 3.4. Error Status Word . . . . . . . . . . . . . . . . . . . . 12
4. Commands . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4. Commands . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Normative References . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
Appendix A. NTP Remote Facility Message Format . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. NTP Remote Facility Message Format . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
RFC 1305 [RFC1305] described a set of control messages for use within RFC 1305 [RFC1305] described a set of control messages for use within
the Network Time Protocol (NTP) when a comprehensive network the Network Time Protocol (NTP) when a comprehensive network
management solution was not available. The definitions of these management solution was not available. The definitions of these
control messages were not promulgated to RFC 5905 [RFC5905] when NTP control messages were not promulgated to RFC 5905 [RFC5905] when NTP
version 4 was documented. These messages were intended for use only version 4 was documented. These messages were intended for use only
in systems where no other management facilities were available or in systems where no other management facilities were available or
appropriate, such as in dedicated-function bus peripherals. Support appropriate, such as in dedicated-function bus peripherals. Support
for these messages is not required in order to conform to RFC 5905 for these messages is not required in order to conform to RFC 5905
[RFC5905]. The control messages are described here as a historical [RFC5905]. The control messages are described here as a historical
record given their use within NTPv4. record given their use within NTPv4.
The publication of this document is not meant to encourage the
developement and deployment of these control messages. This document
is only providing a current reference for these control messages
given the current status of RFC 1305.
1.1. Control Message Overview 1.1. Control Message Overview
The NTP Control Message has the value 6 specified in the mode field The NTP Control Message has the value 6 specified in the mode field
of the first octet of the NTP header and is formatted as shown in of the first octet of the NTP header and is formatted as shown in
Figure 1. The format of the data field is specific to each command Figure 1. The format of the data field is specific to each command
or response; however, in most cases the format is designed to be or response; however, in most cases the format is designed to be
constructed and viewed by humans and so is coded in free-form ASCII. constructed and viewed by humans and so is coded in free-form ASCII.
This facilitates the specification and implementation of simple This facilitates the specification and implementation of simple
management tools in the absence of fully evolved network-management management tools in the absence of fully evolved network-management
facilities. As in ordinary NTP messages, the authenticator field facilities. As in ordinary NTP messages, the authenticator field
follows the data field. If the authenticator is used the data field follows the data field. If the authenticator is used the data field
is zero-padded to a 32-bit boundary, but the padding bits are not is zero-padded to a 32-bit boundary, but the padding bits are not
considered part of the data field and are not included in the field considered part of the data field and are not included in the field
count. count.
IP hosts are not required to reassemble datagrams larger than 576 IP hosts are not required to reassemble datagrams larger than 576
octets; however, some commands or responses may involve more data octets [RFC0791]; however, some commands or responses may involve
than will fit into a single datagram. Accordingly, a simple more data than will fit into a single datagram. Accordingly, a
reassembly feature is included in which each octet of the message simple reassembly feature is included in which each octet of the
data is numbered starting with zero. As each fragment is transmitted message data is numbered starting with zero. As each fragment is
the number of its first octet is inserted in the offset field and the transmitted the number of its first octet is inserted in the offset
number of octets is inserted in the count field. The more-data (M) field and the number of octets is inserted in the count field. The
bit is set in all fragments except the last. more-data (M) bit is set in all fragments except the last.
Most control functions involve sending a command and receiving a Most control functions involve sending a command and receiving a
response, perhaps involving several fragments. The sender chooses a response, perhaps involving several fragments. The sender chooses a
distinct, nonzero sequence number and sets the status field and R and distinct, nonzero sequence number and sets the status field and "R"
E bits to zero. The responder interprets the opcode and additional and "E" bits to zero. The responder interprets the opcode and
information in the data field, updates the status field, sets the R additional information in the data field, updates the status field,
bit to one and returns the three 32-bit words of the header along sets the "R" bit to one and returns the three 32-bit words of the
with additional information in the data field. In case of invalid header along with additional information in the data field. In case
message format or contents the responder inserts a code in the status of invalid message format or contents the responder inserts a code in
field, sets the R and E bits to one and, optionally, inserts a the status field, sets the "R" and "E" bits to one and, optionally,
diagnostic message in the data field. inserts a diagnostic message in the data field.
Some commands read or write system variables and peer variables for Some commands read or write system variables (e.g., s.offset) and
an association identified in the command. Others read or write peer variables (e.g., p.stratum) for an association identified in the
variables associated with a radio clock or other device directly command. Others read or write variables associated with a radio
connected to a source of primary synchronization information. To clock or other device directly connected to a source of primary
identify which type of variable and association a 16-bit association synchronization information. To identify which type of variable and
identifier is used. System variables are indicated by the identifier association the Association ID is used. System variables are
zero. As each association is mobilized a unique, nonzero identifier indicated by the identifier zero. As each association is mobilized a
is created for it. These identifiers are used in a cyclic fashion, unique, nonzero identifier is created for it. These identifiers are
so that the chance of using an old identifier which matches a newly used in a cyclic fashion, so that the chance of using an old
created association is remote. A management entity can request a identifier which matches a newly created association is remote. A
list of current identifiers and subsequently use them to read and management entity can request a list of current identifiers and
write variables for each association. An attempt to use an expired subsequently use them to read and write variables for each
identifier results in an exception response, following which the list association. An attempt to use an expired identifier results in an
can be requested again. exception response, following which the list can be requested again.
Some exception events, such as when a peer becomes reachable or Some exception events, such as when a peer becomes reachable or
unreachable, occur spontaneously and are not necessarily associated unreachable, occur spontaneously and are not necessarily associated
with a command. An implementation may elect to save the event with a command. An implementation may elect to save the event
information for later retrieval or to send an asynchronous response information for later retrieval or to send an asynchronous response
(called a trap) or both. In case of a trap the IP address and port (called a trap) or both. In case of a trap the IP address and port
number is determined by a previous command and the sequence field is number is determined by a previous command and the sequence field is
set as described below. Current status and summary information for set as described below. Current status and summary information for
the latest exception event is returned in all normal responses. Bits the latest exception event is returned in all normal responses. Bits
in the status field indicate whether an exception has occurred since in the status field indicate whether an exception has occurred since
skipping to change at page 13, line 32 skipping to change at page 13, line 32
Figure 2. When present, the data field contains a list of Figure 2. When present, the data field contains a list of
identifiers or assignments in the form identifiers or assignments in the form
<<identifier>>[=<<value>>],<<identifier>>[=<<value>>],... where <<identifier>>[=<<value>>],<<identifier>>[=<<value>>],... where
<<identifier>> is the ASCII name of a system or peer variable <<identifier>> is the ASCII name of a system or peer variable
specified in RFC 5905 and <<value>> is expressed as a decimal, specified in RFC 5905 and <<value>> is expressed as a decimal,
hexadecimal or string constant in the syntax of the C programming hexadecimal or string constant in the syntax of the C programming
language. Where no ambiguity exists, the <169>sys.<170> or language. Where no ambiguity exists, the <169>sys.<170> or
<169>peer.<170> prefixes can be suppressed. Whitespace (ASCII <169>peer.<170> prefixes can be suppressed. Whitespace (ASCII
nonprinting format effectors) can be added to improve readability for nonprinting format effectors) can be added to improve readability for
simple monitoring programs that do not reformat the data field. simple monitoring programs that do not reformat the data field.
Internet addresses are represented as four octets in the form Internet addresses are represented as follows: IPv4 addresses are
[n.n.n.n], where n is in decimal notation and the brackets are written in the form [n.n.n.n], where n is in decimal notation and the
optional. Timestamps, including reference, originate, receive and brackets are optional; IPv6 addresses are formulated based on the
transmit values, as well as the logical clock, are represented in guidelines defined in [RFC5952]. Timestamps, including reference,
units of seconds and fractions, preferably in hexadecimal notation, originate, receive and transmit values, as well as the logical clock,
while delay, offset, dispersion and distance values are represented are represented in units of seconds and fractions, preferably in
in units of milliseconds and fractions, preferably in decimal hexadecimal notation. Delay, offset, dispersion and distance values
notation. All other values are represented as-is, preferably in are represented in units of milliseconds and fractions, preferably in
decimal notation. decimal notation. All other values are represented as-is, preferably
in decimal notation.
Implementations may define variables other than those described in Implementations may define variables other than those described in
RFC 5905. Called extramural variables, these are distinguished by RFC 5905. Called extramural variables, these are distinguished by
the inclusion of some character type other than alphanumeric or the inclusion of some character type other than alphanumeric or
<169>.<170> in the name. For those commands that return a list of <169>.<170> in the name. For those commands that return a list of
assignments in the response data field, if the command data field is assignments in the response data field, if the command data field is
empty, it is expected that all available variables defined in RFC empty, it is expected that all available variables defined in RFC
5905 will be included in the response. For the read commands, if the 5905 will be included in the response. For the read commands, if the
command data field is nonempty, an implementation may choose to command data field is nonempty, an implementation may choose to
process this field to individually select which variables are to be process this field to individually select which variables are to be
skipping to change at page 16, line 11 skipping to change at page 16, line 11
part of the variable name preceding the equals sign and value, where part of the variable name preceding the equals sign and value, where
each index relates information for a single address or network. This each index relates information for a single address or network. This
opcode requires authentication. opcode requires authentication.
Request Nonce (12): Retrieves a 96-bit nonce specific to the Request Nonce (12): Retrieves a 96-bit nonce specific to the
requesting remote address, which is valid for a limited period. requesting remote address, which is valid for a limited period.
Command data is not used in the request. The nonce consists of a Command data is not used in the request. The nonce consists of a
64-bit NTP timestamp and 32 bits of hash derived from that timestamp, 64-bit NTP timestamp and 32 bits of hash derived from that timestamp,
the remote address, and salt known only to the server which varies the remote address, and salt known only to the server which varies
between daemon runs. The reference implementation honors nonces between daemon runs. The reference implementation honors nonces
which were issued less than 16 seconds prior. Regurgitation of the which were issued less than 16 seconds prior. Inclusion of the nonce
nonce by a managment agent demonstrates to the server that the agent by a managment agent demonstrates to the server that the agent can
can receive datagrams sent to the source address of the request, receive datagrams sent to the source address of the request, making
making source address "spoofing" more difficult in a similar way as source address "spoofing" more difficult in a similar way as TCP's
TCP's three-way handshake. three-way handshake.
Unset Trap (31): Removes the requesting remote address and port from Unset Trap (31): Removes the requesting remote address and port from
the list of trap receivers. Command data is not used in the request. the list of trap receivers. Command data is not used in the request.
If the address and port are not in the list of trap receivers, the If the address and port are not in the list of trap receivers, the
error code is 4, bad association. error code is 4, bad association.
5. IANA Considerations 5. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
skipping to change at page 16, line 52 skipping to change at page 16, line 52
access controls are required for the following reasons: access controls are required for the following reasons:
o NTP as a Distributed Denial-of-Service (DDoS) vector. NTP timing o NTP as a Distributed Denial-of-Service (DDoS) vector. NTP timing
query and response packets (modes 1-2, 3-4, 5) are usually short query and response packets (modes 1-2, 3-4, 5) are usually short
in size. However, some NTP control queries generate a very long in size. However, some NTP control queries generate a very long
packet in response to a short query. As such, there is a history packet in response to a short query. As such, there is a history
of use of NTP's control queries, which exhibit such behavior, to of use of NTP's control queries, which exhibit such behavior, to
perform DDoS attacks. These off-path attacks exploit the large perform DDoS attacks. These off-path attacks exploit the large
size of NTP control queries to cause UDP-based amplification size of NTP control queries to cause UDP-based amplification
attacks (e.g., mode 7 monlist command generates a very long packet attacks (e.g., mode 7 monlist command generates a very long packet
in response to a small query (CVE-2013-5211)). These attacks only in response to a small query [CVE-DOS]). These attacks only use
use NTP as a vector for DoS atacks on other protocols, but do not NTP as a vector for DoS atacks on other protocols, but do not
affect the time service on the NTP host itself. To limit the affect the time service on the NTP host itself. To limit the
sources of these malicious commands, NTP server operators are sources of these malicious commands, NTP server operators are
recommended to deploy ingress filtering [RFC2827]. recommended to deploy ingress filtering [RFC2827].
o Time-shifting attacks through information leakage/overwriting. o Time-shifting attacks through information leakage/overwriting.
NTP hosts save important system and peer state variables. An off- NTP hosts save important system and peer state variables. An off-
path attacker who can read these variables remotely can leverage path attacker who can read these variables remotely can leverage
the information leaked by these control queries to perform time- the information leaked by these control queries to perform time-
shifting and DoS attacks on NTP clients. These attacks do affect shifting and DoS attacks on NTP clients. These attacks do affect
time synchronization on the NTP hosts. For instance, time synchronization on the NTP hosts. For instance,
* In the client/server mode, the client stores its local time * In the client/server mode, the client stores its local time
when it sends the query to the server in its xmt peer variable. when it sends the query to the server in its xmt peer variable.
This variable is used to perform TEST2 to non-cryptographically This variable is used to perform TEST2 to non-cryptographically
authenticate the server, i.e., if the origin timestamp field in authenticate the server, i.e., if the origin timestamp field in
the corresponding server response packet matches the xmt peer the corresponding server response packet matches the xmt peer
variable, then the client accepts the packet. An off-path variable, then the client accepts the packet. An off-path
attacker, with the ability to read this variable can easily attacker, with the ability to read this variable can easily
spoof server response packets for the client, which will pass spoof server response packets for the client, which will pass
TEST2, and can deny service or shift time on the NTP client. TEST2, and can deny service or shift time on the NTP client.
CVE-2015-8139 describes the specific attack. The specific attack is described in [CVE-SPOOF].
* The client also stores its local time when the server response * The client also stores its local time when the server response
is received in its rec peer variable. This variable is used is received in its rec peer variable. This variable is used
for authentication in interleaved-pivot mode. An off-path for authentication in interleaved-pivot mode. An off-path
attacker with the ability to read this state variable can attacker with the ability to read this state variable can
easily shift time on the client by passing this test. CVE- easily shift time on the client by passing this test. This
2016-1548 describes the attack. attack is described in [CVE-SHIFT].
o Fast-Scanning. NTP mode 6 control messages are usually small UDP o Fast-Scanning. NTP mode 6 control messages are usually small UDP
packets. Fast-scanning tools like ZMap can be used to spray the packets. Fast-scanning tools like ZMap can be used to spray the
entire (potentially reachable) Internet with these messages within entire (potentially reachable) Internet with these messages within
hours to identify vulnerable hosts. To make things worse, these hours to identify vulnerable hosts. To make things worse, these
attacks can be extremely low-rate, only requiring a control query attacks can be extremely low-rate, only requiring a control query
for reconnaissance and a spoofed response to shift time on for reconnaissance and a spoofed response to shift time on
vulnerable clients. CVE-2016-1548 is one such example. vulnerable clients.
o The mode 6 and 7 messages are vulnerable to replay attacks
[CVE-Replay]. If an attacker observes mode 6/7 packets that
modify the configuration of the server in any way, the attacker
can apply the same change at any time later simply by sending the
packets to the server again.
NTP best practices recommend configuring ntpd with the no-query NTP best practices recommend configuring ntpd with the no-query
parameter. The no-query parameter blocks access to all remote parameter. The no-query parameter blocks access to all remote
control queries. However, sometimes the nosts do not want to block control queries. However, sometimes the hosts do not want to block
all queries and want to give access for certain control queries all queries and want to give access for certain control queries
remotely. This could be for the purpose of remote management and remotely. This could be for the purpose of remote management and
configuration of the hosts in certain scenarios. Such hosts tend to configuration of the hosts in certain scenarios. Such hosts tend to
use firewalls or other middleboxes to blacklist certain queries use firewalls or other middleboxes to blacklist certain queries
within the network. within the network.
Recent work (reference needed) shows that significantly fewer hosts Significantly fewer hosts respond to mode 7 monlist queries as
respond to mode 7 monlist queries as compared to other control compared to other control queries because it is a well-known and
queries because it is a well-known and exploited control query. exploited control query. These queries are likely blocked using
These queries are likely blocked using blacklists on firewalls and blacklists on firewalls and middleboxes rather than the no-query
middleboxes rather than the no-query option on NTP hosts. The option on NTP hosts. The remaining control queries that can be
remaining control queries that can be exploited likely remain out of exploited likely remain out of the blacklist because they are
the blacklist because they are undocumented in the current NTP undocumented in the current NTP specification [RFC5905].
specification [RFC5905].
This document describes all of the mode 6 control queries allowed by This document describes all of the mode 6 control queries allowed by
NTP and can help administrators make informed decisions on security NTP and can help administrators make informed decisions on security
measures to protect NTP devices from harmful queries and likely make measures to protect NTP devices from harmful queries and likely make
those systems less vulnerable. those systems less vulnerable. Regardless of which mode 6 commands
an administrator elect to allow, remote access to this facility needs
to be protected from unauthorized access (e.g., strict ACLs).
7. Acknowledgements 7. Contributors
Dr. David Mills specified the vast majority of the mode 6 commands
during the development of RFC 1305 [RFC1305] and deserves the credit
for their existence and use.
8. Acknowledgements
Tim Plunkett created the original version of this document. Aanchal Tim Plunkett created the original version of this document. Aanchal
Malhotra provided the initial version of the Security Considerations Malhotra provided the initial version of the Security Considerations
section. section.
Karen O'Donoghue, David Hart, Harlan Stenn, and Philip Chimento Karen O'Donoghue, David Hart, Harlan Stenn, and Philip Chimento
deserve credit for portions of this document due to their earlier deserve credit for portions of this document due to their earlier
efforts to document these commands. efforts to document these commands.
8. Normative References Miroshav Lichvar, Ulrich Windl, Dieter Sibold, J Ignacio Alvarez-
Hamelin, and Alex Campbell provided valuable comments on various
versions of this document.
9. References
9.1. Normative References
[RFC1305] Mills, D., "Network Time Protocol (Version 3) [RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation and Analysis", RFC 1305, Specification, Implementation and Analysis", RFC 1305,
DOI 10.17487/RFC1305, March 1992, DOI 10.17487/RFC1305, March 1992,
<https://www.rfc-editor.org/info/rfc1305>. <https://www.rfc-editor.org/info/rfc1305>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/info/rfc2827>. May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010,
<https://www.rfc-editor.org/info/rfc5952>.
9.2. Informative References
[CVE-DOS] NIST National Vulnerability Database, "CVE-2013-5211,
https://nvd.nist.gov/vuln/detail/CVE-2013-5211", January
2014.
[CVE-Replay]
NIST National Vulnerability Database, "CVE-2015-8140,
https://nvd.nist.gov/vuln/detail/CVE-2015-8140", January
2015.
[CVE-SHIFT]
NIST National Vulnerability Database, "CVE-2016-1548,
https://nvd.nist.gov/vuln/detail/CVE-2016-1548", January
2017.
[CVE-SPOOF]
NIST National Vulnerability Database, "CVE-2015-8139,
https://nvd.nist.gov/vuln/detail/CVE-2015-8139", January
2017.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
Appendix A. NTP Remote Facility Message Format Appendix A. NTP Remote Facility Message Format
The format of the NTP Remote Facility Message header, which The format of the NTP Remote Facility Message header, which
immediately follows the UDP header, is shown in Figure 3. Following immediately follows the UDP header, is shown in Figure 3. Following
is a description of its fields. Bit positions marked as zero are is a description of its fields. Bit positions marked as zero are
reserved and should always be transmitted as zero. reserved and should always be transmitted as zero.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 20, line 44 skipping to change at page 21, line 44
Encryption KeyID : A 32-bit unsigned integer used to designate the Encryption KeyID : A 32-bit unsigned integer used to designate the
key used for the Message Authentication Code. This field is included key used for the Message Authentication Code. This field is included
only when the A bit is set to 1. only when the A bit is set to 1.
Message Authentication Code : An optional Message Authentication Code Message Authentication Code : An optional Message Authentication Code
defined by the version of the NTP daemon indicated in the defined by the version of the NTP daemon indicated in the
Implementation field. This field is included only when the A bit is Implementation field. This field is included only when the A bit is
set to 1. set to 1.
Authors' Addresses Author's Address
Dr. David L. Mills
University of Delaware
Email: mills@udel.edu
Brian Haberman (editor) Brian Haberman (editor)
JHU JHU
Email: brian@innovationslab.net Email: brian@innovationslab.net
 End of changes. 25 change blocks. 
87 lines changed or deleted 146 lines changed or added

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