r20 - 2016-03-22 - 05:43:41 - HarlanStennYou are here: NTP >  Dev Web > DevelopmentIssues > NtpProtocolResponseMatrix
NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38.

ntp-4.2.8p10 was released on 21 March 2017. It addresses 6 medium- and 5 low-severity security issues, 4 informational security topics, 15 bugfixes, and contains other improvements over 4.2.8p9.

Please see the NTP Security Notice for vulnerability and mitigation details.

Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.

NTP Protocol Response Matrix

Related Topics: bug_small.png Bug #2263, bug_small.png Bug #2367, bug_small.png Bug #2559, NtpBroadcastIssues, KoDResponses

Client/Server

From assoc.html:

Client/server mode is the most common configuration in the Internet today. It operates in the classic remote-procedure-call (RPC) paradigm with stateless servers and stateful clients. In this mode a host sends a client (mode 3) request to the specified server and expects a server (mode 4) reply at some future time. In some contexts this would be described as a "pull" operation, in that the host pulls the time and related values from the server.

A host is configured in client mode using the server (sic) command and specifying the server DNS name or IPv4 or IPv6 address; the server requires no prior configuration. The iburst option described later on this page is recommended for clients, as this speeds up initial synchronization from several minutes to several seconds. The burst option described later on this page can be useful to reduce jitter on very noisy dial-up or ISDN network links.

Ordinarily, the program automatically manages the poll interval between the default minimum and maximum values. The minpoll and maxpoll options can be used to bracket the range. Unless noted otherwise, these options should not be used with reference clock drivers.

 

Symmetric Active/Passive

From assoc.html:

Symmetric active/passive mode is intended for configurations where a clique of low-stratum peers operate as mutual backups for each other. Each peer operates with one or more primary reference sources, such as a reference clock, or a set of secondary (stratum, 2) servers known to be reliable and authentic. Should one of the peers lose all reference sources or simply cease operation, the other peers will automatically reconfigure so that time and related values can flow from the surviving peers to all hosts in the subnet. In some contexts this would be described as a "push-pull" operation, in that the peer either pulls or pushes the time and related values depending on the particular configuration.

A symmetric active peer sends a symmetric active (mode 1) message to a designated peer. If a matching configured symmetric active association is found, the designated peer returns a symmetric active message. If no matching association is found, the designated peer mobilizes a ephemeral symmetric passive association and returns a symmetric passive (mode 2) message. Since an intruder can impersonate a symmetric active peer and cause a spurious symmetric passive association to be mobilized, symmetric passive mode should always be cryptographically validated.

A peer is configured in symmetric active mode using the peer command and specifying the other peer DNS name or IPv4 or IPv6 address. The burst and iburst options should not be used in symmetric modes, as this can upset the intended symmetry of the protocol and result in spurious duplicate or dropped messages.

As symmetric modes are most often used as root servers for moderate to large subnets where rapid response is required, it is generally best to set the minimum and maximum poll intervals of each root server to the same value using the minpoll and maxpoll options.

From "The Book":

Symmetric active/passive mode is intended for configurations in which a clique of low-stratum peers operates as mutual backups for each other. Each peer normally operates with one or more sources, such as a reference clock, or a subset of primary and secondary servers known to be reliable and authentic. Should one of these peers lose all reference clocks or simply cease operation, the other peers will automatically reconfigure so that time values can flow from the surviving peers to all the others in the subnet. In some contexts, this would be described as a push-pull operation, in that each peer either pushes or pulls the time values depending on the particular configuration and stratum.

What if the passive side does not want this association? How do we specify this case?

  • Per the quote from The Book, this is not a valid configuration.

If we're the passive side and we don't want this association, there are several options available:

  • ignore it and do not respond.

  • respond as above, but we ignore "time" from the active side.

  • respond with a server (mode 4) message.

How many passive associations should we spin up?

How many should we "listen" to? What about the others?

 

Broadcast/Multicast Modes

From assoc.html:

NTP broadcast and multicast modes are intended for configurations involving one or a few servers and a possibly very large client population. Broadcast mode can be used with Ethernet, FDDI and WiFi spans interconnected by hubs or switches. Ordinarily, broadcast packets do not extend beyond a level-3 router. Where service is intended beyond a level-3 router, multicast mode can be used. Additional information is on the Automatic NTP Configuration Options page.

A server is configured to send broadcast or multicast messages using the broadcast command and specifying the subnet address for broadcast or the multicast group address for multicast. A broadcast client is enabled using the broadcastclient command, while a multicast client is enabled using the multicastclient command and specifying the multicast group address. Multiple commands of either type can be used. However, the association is not mobilized until the first broadcast or multicast message is actually received.

 

Manycast and Pool Modes

From assoc.html:

Manycast and pool modes are automatic discovery and configuration paradigms new to NTPv4. They are intended as a means for a client to troll the nearby network neighborhood to find cooperating willing servers, validate them using cryptographic means and evaluate their time values with respect to other servers that might be lurking in the vicinity. The intended result is that each client mobilizes ephemeral client associations with some number of the "best" of the nearby servers, yet automatically reconfigures to sustain this number of servers should one or another fail. Additional information is on the Automatic Server Discovery Schemes page.

 

restrict items: kod and limited, noserve and nopeer

Right now, kod only works with the limited keyword. Is there a good reason we should not also do a kod response when asked for the time if noserve is specified?

What about nopeer?

If we allow these, should we do all of them from the kod keyword, or should we use kod-limited, kod-noserve, kod-nopeer, etc?

Also note that some clients will behave worse if they get a kod response. We should consider keeping some state about these, and if we discover an IP where we have previously sent a kod response is still sending requests, we should just ignore them. This begs the question of whether or not we should track the effect ignoring a client has on their behavior. And there is a difference between the single client/IP and a bunch of NAT clients that are coming from a single IP. See bug_small.png Bug #2559 for more information.

What about the point of view that says "KOD means KOD - if the overall restrict wants to limit something, then kod should mean that we should KOD excesses on those."

 

Protocol Response Matrix (server)

MODE_ UNSPEC ACTIVE PASSIVE CLIENT SERVER BROADCAST CONTROL PRIVATE BCLIENT
What Unspecified - old version of NTP Symmetric active mode Symmetric passive mode client mode server mode broadcast mode ntpq ntpdc broadcast client
Normal valid valid valid valid valid valid valid valid valid
noserve no no valid no valid valid - - no
noserve + KOD no KOD valid KOD valid valid - - no
nopeer valid no maybe valid valid valid - - valid
nopeer + KOD valid KOD maybe valid valid valid - - valid
limited maybe maybe maybe maybe maybe maybe maybe maybe maybe
limited + KOD reply reply reply reply reply reply reply reply reply
noquery - - - - - - no no -
noquery + KOD - - - - - - KOD KOD -

The KOD responses are RATE (for limited), DENY, and RSTR. Is DENY sufficient for the other cases, or should we use RSTR for any of them?

Response Meaning
- Not applicable for the flag in question
KOD Provide a KOD response
maybe Provide either a valid response or no response
no Provide no response
reply Provide either a valid response or a KOD response
valid Provide a valid (appropriate) response

If the incoming packet is authenticated in some way, should a KOD response be equivalently authenticated?

 
  • Miroslav, internally ntpd will, in certain cases, change peer->hmode to be MODE_BCLIENT. -- HarlanStenn - 28 Jan 2014
  • What is the bclient column meant for? I think there is no mode for broadcast client packets specified, the client uses normal client packets (mode 3). -- MiroslavLichvar - 28 Jan 2014
  • Thanks Terje! Does the table look OK now? -- HarlanStenn - 28 Jan 2014
  • I believe nopeer should be valid, no, maybe and valid for the rest. Adding KOD change Active from no to kod. -- TerjeMathisen - 22 Jan 2014
  • Thanks Brian - please let me know if I made a mistake transcribing to the table. -- HarlanStenn - 22 Jan 2014
  • noserve

    unspec=no
    active=no
    passive=valid
    client=no
    server=valid
    broadcast=valid
    control= na
    private=na
    bclient=no

    Add KOD to noserve changes Active and Client from no to kod. -- BrianUtterback - 21 Jan 2014

Protocol Response Matrix (client)

Until we have enough data to warrant a table...

If we send authenticated packets to a host, should we ignore non-authenticated KOD responses (apparently) from that host?

Should we have an option to remember the last T1 timestamp we send to a host and if we get a KOD response (apparently) from that host where the T1 timestamp does not match our saved timestamp we would ignore the KOD packet?

 

Comments

 

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r20 < r19 < r18 < r17 < r16 | More topic actions
Dev.NtpProtocolResponseMatrix moved from Dev.NoserveAndProtocolResponseMatrix on 2014-02-02 - 23:56 by HarlanStenn - put it back
 
SSL security by CAcert
Get the CAcert Root Certificate
This site is powered by the TWiki collaboration platform
IPv6 Ready
Copyright & 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding the site? Send feedback