Subject: [ntpwg] New version of BCP

From: Denis Reilly <[email-masked]>
Date: Mon, 22 May 2017 13:04:54 +0000

Hello, everyone. I have uploaded a new version (v04)  of the NTP BCP ahead of our interim meeting later this week, based on the WGLC feedback.

https://datatracker.ietf.org/doc/html/draft-ietf-ntp-bcp-04

There are general changes for readability, as well as more substantial changes to the "sources of time", "leap seconds", "autokey", "avoiding daemon restart attacks", and "anycast".

Best Regards,

--
Denis Reilly  |  Lead Engineer  |  [email-masked] (585)321-5837

_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Sharon Goldberg <[email-masked]>
Date: Fri, 26 May 2017 13:48:26 -0400

Comments on the BCP:

Modification to last paragraph of 6.4.

Starting with ntp-4.2.8p7 the ntp.keys file accepts an optional 4th column,
a comma-separated list of IPs that are allowed to serve time. Use this
feature.  Note, however, that an adversarial client that knows the
symmetric broadcast key could still easily spoof its source IP to an IP
that is allowed to serve time. (This is easy to do because the origin
timestamp on broadcast mode packets is not validated by the client. By
contrast, client/server and symmetric modes do require origin timestamp
validation, making it more difficult to spoof packets [CCR16].)

Modification to Section 7.2 (add the middle paragraph, as below).

   The "Kiss-o'-Death" (KoD) packet is a rate limiting mechanism where a
   server can tell a misbehaving client to "back off" its query rate.
   It is important for all NTP devices to respect these packets and back
   off when asked to do so by a server.  It is even more important for
   an embedded device, which may not have exposed a control interface
   for NTP.

   That said, a client should only accept a KoD packet if it has a valid
   origin timestamp.  Also, clients should be wary of accepting KoD packet
   with large poll values (>10), which can cause a denial-of-service
   attack that causes the client to stop querying its server [NDSS16].
Clients
   should monitor their NTP instance to detect suspicious KoD packets.

   The KoD mechanism relies on clients behaving properly in order to be
   effective.  Some clients ignore the KoD packet entirely, and other
   poorly-implemented clients might unintentionally increase their poll
   rate and simulate a denial of service attack.  Server administrators
   should be prepared for this and take measures outside of the NTP
   protocol to drop packets from misbehaving clients.

On Mon, May 22, 2017 at 9:04 AM, Denis Reilly <denis.reilly@spectracom.
orolia.com> wrote:

> Hello, everyone. I have uploaded a new version (v04)  of the NTP BCP ahead
> of our interim meeting later this week, based on the WGLC feedback.
>
> There are general changes for readability, as well as more substantial
> changes to the "sources of time", "leap seconds", "autokey", "avoiding
> daemon restart attacks", and "anycast".
>
> Best Regards,
>
> --

-- 
---
Sharon Goldberg
Computer Science, Boston University
http://www.cs.bu.edu/~goldbe
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 26 May 2017 17:10:53 -0700

> validation, making it more difficult to spoof packets [CCR16].)

If we're going down this road, then let's add that in a LAN setting
doing this will cause ARP warnings as the IP moves from one MAC to
another.  It also means there is an attacker *on your network*.  If this
isn't the case, then it's highly likely you're not doing proper ingress
filtering.

Perhaps we should say that this is a risk of using broadcast in a WAN
setting?  Oh wait, we already clearly and repeatedly state that
broadcast time is only to be used in trusted networks.

>    protocol to drop packets from misbehaving clients.

So this document is also a BCP for implementors?  Makes sense, I guess,
but I thought this check was already specified in 5905.

-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 29 May 2017 07:33:50 +0200

>>> Sharon Goldberg <[email-masked]> schrieb am 26.05.2017 um 19:48 in
Nachricht
> timestamp on broadcast mode packets is not validated by the client. By

I wonder: What is the benefit over restrict? If the purpose is to restrict the use of a specific key in addition to the restrictions effective, wouldn't the "restrict" keyword the proper place to do it? Also, while autokey is deprecated there is not substitute for it. How would that play with autokey? Not at all, I guess.

>    should monitor their NTP instance to detect suspicious KoD packets.

The above statement and the statement below are somewhat contradicting:

Obove says that "poll > 10" and KoD will cause a denial of service, while the below statement says som porly implemented clients could treat KoD like a denial of service.
At least some explaing words are necessary IMHO. I.e.: Be specific "what "poorly-implemented" means.

Regards,
Ulrich

---

From: Sharon Goldberg <[email-masked]>
Date: Mon, 29 May 2017 11:10:24 -0400

Good point re KoD denial of service. I'll reword this and send something
out tomorrow morning.

On Monday, May 29, 2017, Ulrich Windl <[email-masked]>
wrote:

> >>> Sharon Goldberg <[email-masked] <javascript:;>> schrieb am
> 26.05.2017 um 19:48 in
> Nachricht
> <[email-masked]
> <javascript:;>>:
> > Comments on the BCP:
> >
> >
> I wonder: What is the benefit over restrict? If the purpose is to restrict
> the use of a specific key in addition to the restrictions effective,
> wouldn't the "restrict" keyword the proper place to do it? Also, while
> autokey is deprecated there is not substitute for it. How would that play
> with autokey? Not at all, I guess.
>
> Obove says that "poll > 10" and KoD will cause a denial of service, while
> the below statement says som porly implemented clients could treat KoD like
> a denial of service.
> >> Denis Reilly  |  Lead Engineer  |  [email-masked]
> <javascript:;>
> >> (585)321-5837
> >>
> >> [email-masked] <javascript:;>

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 29 May 2017 15:13:19 -0700

>> with autokey? Not at all, I guess.

It was cumbersome to do this with a 'restrict' entry.  There can be many
trusted keys, and if this protection was done via 'restrict' we'd need
to associate key IDs with trusted time servers in places in the code
where it was needlessly difficult to "make it work".  Doing it in a
restrict line also makes administration more cumbersome.

>> Above says that "poll > 10" and KoD will cause a denial of service, while
>> the below statement says some poorly implemented clients could treat KoD like
>> a denial of service.

Yes, it's a tradeoff, and a bad actor can try and push out the poll
interval.  But a poll interval of 10 is "only" about 17 minutes.  That's
likely not a DoS attempt.  But what about 12, which is about an hour?
Or longer?  Certainly, it doesn't *stop* ca client from querying a
server, but it does delay it.  Even a poll interval of 17 (36 hours)
isn't *stopping* a client from querying a given server.  But it does
provide a large window for other things to happen.

This is why proper monitoring is so important.  Just because "we" don't
see a reason to believe a poll interval of 17 as appropriate doesn't
mean there won't be cases where is *is* appropriate.

H

>> At least some explaining words are necessary IMHO. I.e.: Be specific "what
>> "poorly-implemented" means.
>>
>> Regards,
>> Ulrich
>>
>>>

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 30 May 2017 10:30:21 +0200

>    should monitor their NTP instance to detect suspicious KoD packets.

I think this could go even further and suggest to ignore the poll
value in server mode packets completely. A valid KoD RATE should
temporarily increase the current polling interval up to a maximum, but
it should not increase the minimum interval as an attacker can easily
trigger a KoD response, which would increase the client's minimum
poll, even though it's perfectly acceptable for the server.

There are two issues:
- some clients shorten their polling interval to the value provided by
  the server
- some servers respond with the maximum of the client's poll and its
  rate limiting interval

The second issue can be fixed only when most clients have fixed the
first one, otherwise responding with a KoD RATE may actually increase
the average polling rate. A proper fix will probably need to wait for
NTPv5.

-- 
Miroslav Lichvar

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 30 May 2017 01:39:04 -0700

> the average polling rate. A proper fix will probably need to wait for

I disagree.  There are cases where the client will send a "normal" poll
interval and the server will respond with a different poll interval.  It
is arguably wrong for the client to ignore these recommendations from
the server.  But this goes to the general case, not specifically the KoD
case.

There are other problems as well - we've seen poorly implemented clients
that will poll *faster* when given a KoD response.

Given that proper implementations/configurations won't be doing this
sort of abuse, the only thing we can hope for is that behind an improper
configuration is a proper configuration, because an improper
implementation behind an improper configuration will just misbehave.

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 30 May 2017 11:24:33 +0200

> the server.  But this goes to the general case, not specifically the KoD

At least for the KoD case I think you will agree that a client using
poll 10 should not jump to poll 6 when it receives a KoD RATE with
poll 6, right? It think it would be good if ntpd stopped doing that.

In NTPv5 we can consider to specify the poll value in KoD RATE packets
to be the actual rate limiting interval. If a server requires clients
to not use poll below 3, a client currently using poll 10 and having a
minimum of 6 should not reset the minimum to 10 when it receives a KoD
RATE, right?

> implementation behind an improper configuration will just misbehave.

Right. As an implementer, however, I will probably not support
something that I know can be easily exploited. I think it's better to
have a rate limiting protocol which might be less effective, but is
more secure and more likely to be widely used.

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 30 May 2017 03:03:02 -0700

> poll 6, right? It think it would be good if ntpd stopped doing that.

Where are you seeing this?  The code says:

       xpkt.ppoll = max(rpkt->ppoll, ntp_minpoll);
       ...
       memcpy(&xpkt.refid, "RATE", 4);

I'm also curious how polling more often than once every 1024 seconds is
a rate violation, but that must be a local policy choice?

> minimum of 6 should not reset the minimum to 10 when it receives a KoD

I'm not understanding you here.  If there's a minpoll value of 3, that's
every 8 seconds.  If the client is polling at 10, that's 1024 seconds.

The default value for minpkt is a poll interval of 2.

> more secure and more likely to be widely used.

I'm still missing something.

What can be easily exploited?

What is "more secure"?

I think the "more likely to be widely used" is a nice thought.

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 30 May 2017 12:33:28 +0200

>        memcpy(&xpkt.refid, "RATE", 4);

That's the server issue, which can be fixed only when clients don't
shorten their poll anymore. The client issue is in

	peer->ppoll = max(peer->minpoll, pkt->ppoll);

It was reported here: http://bugs.ntp.org/show_bug.cgi?id=3055

> a rate violation, but that must be a local policy choice?

The client is not violating the maximum rate. It's the attacker who is
sending spoofed requests at a higher rate.

> every 8 seconds.  If the client is polling at 10, that's 1024 seconds.

Yes, but the attacker may be sending spoofed requests at any rate and
when the client sends a genuine request, the server may respond with
a KoD RATE packet using poll 10 (the client's current poll), which
would increase the client's minimum poll from 6 to 10.

> The default value for minpkt is a poll interval of 2.

Yes, and the default value of ntp_minpoll, which is the minimum value
in KoD rate packets, is 3.

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 30 May 2017 03:55:50 -0700

> It was reported here: http://bugs.ntp.org/show_bug.cgi?id=3055

Thanks - I'll look at this, after I get some sleep.

> sending spoofed requests at a higher rate.

As I recall:

- we don't pay attention to KoD packets that don't pass packet timestamp
checks.

- if an attacker is forging packets claiming to be from us, we log the
"unexpected" replies.

- if there's an association, I thought we were also looking at the poll
interval and if packets come in too quickly we log that, too.

> would increase the client's minimum poll from 6 to 10.

If the real client is polling with 6, the abused server that is ready to
KoD/RATE will respond with 6.  If the abuser is sending 10, the client
would be rejecting those packets because they fail the origin timestamp
check.

> in KoD rate packets, is 3.

Is it useful to discuss this here, or should we trim the recipient list?

I have to be up in 6 hours' time, more later.

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 30 May 2017 13:31:07 +0200

> would be rejecting those packets because they fail the origin timestamp

Right. It doesn't matter what the attacker is sending as long as it
triggers rate limiting on the server. The problem is in the KoD RATE
response corresponding to the client's request, which increases the
client's minimum poll to its current poll.

> Is it useful to discuss this here, or should we trim the recipient list?

Implementation-specific details probably don't belong here. The
discussion was about the BCP and what should it say about poll in KoD
RATE packets.

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 31 May 2017 08:19:01 +0200

>>> Miroslav Lichvar <[email-masked]> schrieb am 30.05.2017 um 11:24 in
> poll 6, right? It think it would be good if ntpd stopped doing that.

I think it depends: A KoD response is no valid timestamp, and the client (when not having many better choices) might try to reduce the polling interval to keep the dispersion low. Reading section 7.4 of RFC 5905 I find that the whole semantics is mostly unspecified (poll is nowhere mentioned), so why be surprised?

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 31 May 2017 11:08:15 +0200

On Wed, May 31, 2017 at 08:19:01AM +0200, Ulrich Windl wrote:
> I think it depends: A KoD response is no valid timestamp, and the client (when not having many better choices) might try to reduce the polling interval to keep the dispersion low.

Yes, some clients do that. A well-behaved client slowly increases its
polling interval when it's not getting useful data. The server or the
network may be overloaded. If all clients reduced their polling
interval when that happens, it would basically be a DDOS attack.

> Reading section 7.4 of RFC 5905 I find that the whole semantics is mostly unspecified (poll is nowhere mentioned), so why be surprised?

It doesn't explain the poll value in the packet, which is not even
specified for non-KoD packets, but I think it clearly says (with the
errata 3007) that the client's interval should go up, not down:

  b.  For kiss code RATE, the client MUST immediately increase its
      polling interval to that server and continue to increase it each time
      it receives a RATE kiss code.

Other parts of the section 7.4 might need an update. For instance, it
says clients MUST implement the DENY and RSTR codes, but if I remember
correctly, the only client that does that is the sntp client from ntp.