r17 - 2015-08-27 - 23:07:07 - 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.8p14 was released on 03 March 2020. It addresses 2 medium-severity security issues in ntpd, and provides 47 non-security bugfixes and 4 other improvements over 4.2.8p13.

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

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)

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

    control= na

    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?




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-2020 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