Subject: Re: [Ntp] Protocol and Security Enhancements for the Network Time Protocol (NTP)

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 12 Apr 2021 17:48:36 +0200

On Sun, Mar 28, 2021 at 01:36:44PM -0400, David Mills wrote:
> Recent
> discussion in the newsgroup has centered on dramatic security mechanisms and
> exotic services for ntp version 5, but less attention has been on the
> underlying onwire protocols evolved from current NTP version 4.

> URL: https://www.eecis.udel.edu/~mills/Autokey3.txt

I didn't see any comments about this document. Others here would
know better how this works as a replacement of the old Autokey. I'll
just point out few non-crypto things that didn't seem quite right to
me.

The protocol doesn't prevent amplification attacks using the cookie
response. The document claims that rate limiting prevents such
attacks, but I don't think that is true. Rate limiting is not a
security mechanism. It actually creates other security issues. The
server has a limited amount of memory. Attackers can avoid rate
limiting by using more addresses than the server can remember. That's
easy if the victim is using IPv6.

It doesn't have a fully random nonce in addition to the transmit
timestamp. It claims that transmit timestamps are not predictable
while it recommends to not use the data minimization.

The cookie seems to be constructed just from a secret key and client
address, without a nonce.

The handshake in the symmetric mode seems to be still vulnerable to
off-path DoS attacks.

In the broadcast mode the transmit timestamp is used as a sequence
number, which means the server cannot have a backward step. It doesn't
have a mechanism to protect against delay attacks. (That was a goal
in earlier NTS designs.)

The described parser detects legacy MACs by checking whether the
length field of an extension field is zero. I guess that was meant to
be the type of the field? That would work only with key IDs below
65536.

It claims that NTS doesn't support interleaved mode. How could it, are
those two not at different layers? NTS+xleave definitely works for me.

-- 
Miroslav Lichvar

---

From: "David L. Mills" <[email-masked]>
Date: Fri, 16 Apr 2021 15:32:20 -0400

>easy if the victim is using IPv6.
Rate limiting in itself is not the issue.  See the DDoS section .
The effect is to delete packets with a headway less than two seconds.
The LRU list includes up to 700 distinct IP addresses, so the goal is to
 amputate those enemy attacks before generating a response packet.
This scheme has been used at NIST for several years.

>while it recommends to not use the data minimization.
I submit that in this context, the transmit timestamp can be an adequate 
nonce.  It would be possible
to replace this function by an explicit nonce, but this means to be 
overkill.  The data minimization
issue is not relevant.

>address, without a nonce.
I don't see that the cookie requires a nonce.  It is incrypted according 
to the key generated by
a Diffiee-Helman agreement. 

>The handshake in the symmetric mode seems to be still vulnerable to
By handshake I think you mean agreement.  The agreement is vulnerable to 
attack, but the
agreement  is done seldomly  and may represent a relatively minor 
exposure.  The problem
is the requirement that error recovery must be available with no 
preconceived requirement.

>have a mechanism to protect against delay attacks. (That was a goal
The hazzard is mitigated by the rules explained in section 4.3.  An old 
duplicate
is recognized by a check on the apparent  poll interval.

>be the type of the field? That would work only with key IDs below
The proposed scheme does not work with legecy autokey.  Fancy that . 

>those two not at different layers? NTS+xleave definitely works for me.
The proposed onwire protocol combines basic and interleave modes in a 
single protocol where
the transmit devstamp is used  for all protocol rounds.  The detailed 
design is described in section 4.3.

Please forgive my ackward sentences.  It is hard to deal with technical 
issues using a screen-reader
and my wife as editor .

Dave

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 19 Apr 2021 13:09:20 +0200

> This scheme has been used at NIST for several years.

If the server's LRU list is limited to 700 addresses, the attackers
will simply use 701 or more addresses to prevent any address from
accumulating requests and effectively disable the rate limiting.
Generally, it cannot prevent an amplification attack.

What is worse, it can be exploited for a DoS attack on real NTP
clients if it doesn't randomly let some packets through. An attacker
can send requests to the server with spoofed source address frequently
enough to keep the rate limiting constantly enabled in order to
prevent the real client from getting any responses to its own
requests. This was reported years ago, but it is still not fixed in
the ntp.org implementation.

It is a widespread issue. A third of public servers included in the
pool.ntp.org project seems to be affected.

> overkill.  The data minimization

The data minimization draft requires clients to use fully random
transmit timestamps. That's a good nonce, but it can be used only in
the client-server mode, not the symmetric mode.

> is recognized by a check on the apparent  poll interval.

That is not always sufficient. An attacker who can prevent packets
sent by the genuine server from reaching the client, can replay old
packets at a consistent rate with a constant delay (arbitrarily
large). The client will not see anything suspicious, except that the
time is in past. If it accepts the backward step, it will be
susceptible to the attack.

> The proposed scheme does not work with legecy autokey.  Fancy that .

The trouble is that it will fail to parse messages of implementations
implementing RFC 5905 but not RFC 5906, using MACs with key IDs larger
than 65535.

> The proposed onwire protocol combines basic and interleave modes in a single
> protocol where
> the transmit devstamp is used  for all protocol rounds.  The detailed design
> is described in section 4.3.

The document doesn't have enough details for me to fully understand
the new combined protocol.

Is a server or peer supposed to send responses with transmit timestamp
of a previous response whenever it has this timestamp saved, meaning
interleaved mode constantly enabled, except it is not indicated by the
origin timestamp as it used to?

How would an older client or peer not implementing this new protocol
be able to process received responses? I suspect it would be
dropping all measurements due to a large delay.

Another issue is that the symmetric mode cannot always work in
interleaved mode. When the polling intervals of the peers don't match,
there are multiple responses per request, using the same origin
timestamp. This means there is an ambiguity for the interleaved
transmit timestamp. The peer doesn't know if it actually received the
response to which the transmit timestamp corresponds to. In such a
case the symmetric mode needs to switch to basic mode. This is how it
works in the ntp-interleaved-modes draft.

-- 
Miroslav Lichvar

---

From: Hal Murray <[email-masked]>
Date: Mon, 19 Apr 2021 10:38:23 -0700

[email-masked] said:
> What is worse, it can be exploited for a DoS attack on real NTP clients if it
> doesn't randomly let some packets through. 

How many is "some"?  What fraction of the responses does a client need?

Is this a solvable problem?  If I let 1/N through, is there a value of N that 
lets through enough real replies without also letting through enough bogus 
traffic to make traditional DDoS practical?

There is a horrible complication in this area: NAT.  If there are X clients 
behind a NAT box, then that IP Address needs X times as much legitimate 
traffic.

--------

One tool in this area is to have the NTS cookies tied to an IP Address.  We 
discussed this a long time ago.  Nobody was interested, but I've forgotten 
why.  Maybe it was more important to allow laptops to keep using their cookies 
across migrations that change IP Addresses.

We could make it an option.  Then people with fixed addresses could turn it on 
and servers could have 2 modes of rate limiting.  That doesn't help if the bad 
guy can capture traffic from the client.  The server can't tell a replay from 
normal traffic.

--------

Is there any group within IETF where DDoS discussions would be appropriate?

-- 
These are my opinions.  I hate spam.

---

From: Daniel Franke <[email-masked]>
Date: Mon, 19 Apr 2021 14:04:41 -0400

> traffic to make traditional DDoS practical?

No. A client will treat a server as unreachable after 8 dropped replies, so
an attacker can DoS a client by sending spoofed packets at the rate limit
plus eight times the client's burst interval, which at conventional rate
limits is an absolutely trivial amount of traffic. Trying to rate-limit NTP
is just absolutely counterproductive no matter how you approach it. The way
to make NTP DDoS-resilient is to spec your server with enough CPU to keep
up with requests coming in at the full capacity of your network link. Do
this, and attackers will achieve no more by hammering you with NTP requests
than by hammering you with random garbage.

---

From: Hal Murray <[email-masked]>
Date: Mon, 19 Apr 2021 12:12:26 -0700

[email-masked] said:
> to make NTP DDoS-resilient is to spec your server with enough CPU to keep up
> with requests coming in at the full capacity of your network link. Do this,
> and attackers will achieve no more by hammering you with NTP requests than by
> hammering you with random garbage. 

If I don't rate limit, then a bad guy can use my server as a reflector to DDoS 
any target.  Making my server run at full line rate just makes things worse 
for victims.

---

From: Daniel Franke <[email-masked]>
Date: Mon, 19 Apr 2021 15:39:02 -0400

> any target.  Making my server run at full line rate just makes things

If your server is correctly configured, then you never amplify any traffic
so adversaries gain no benefit from doing this. They can hammer the
ultimate victim just as hard on their own as they can by using your server
as a reflector.

---

From: Danny Mayer <[email-masked]>
Date: Mon, 19 Apr 2021 18:33:48 -0400

> guy can capture traffic from the client.  The server can't tell a replay from

This doesn't work at all. You should never be tying cookies to an IP 
address. Which address would that be? An IPv4 address, an IPV6 address, 
a VPN IP address, all of which can be active at the same time and being 
used at the same time. This is just as bad as the ReferenceID being used 
as the IP address from which it got it's preferred truechimer clock.

Danny

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 20 Apr 2021 09:00:54 +0200

>>> Daniel Franke <[email-masked]> schrieb am 19.04.2021 um 21:39 in
Nachricht
> ultimate victim just as hard on their own as they can by using your server

But the point is: Will they realize (or just continue the mis-use)?

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 20 Apr 2021 09:23:18 +0200

> traffic to make traditional DDoS practical?

Address-specific rate limiting in NTP can be circumvented. I think its
only purpose can be saving network traffic on broken and misconfigured
clients. That's all.

As for the highest usable N, it depends on the client implementation.
For a public server, N=4 (a leak rate of 25%) seems to be about the
highest value where most clients still appear to do something useful.
This can save up to 37.5% of network traffic (TX+RX).

-- 
Miroslav Lichvar

---

From: Daniel Franke <[email-masked]>
Date: Tue, 20 Apr 2021 05:06:26 -0400

> But the point is: Will they realize (or just continue the mis-use)?

Regardless, mitigating non-amplifying reflection is impractical and
pointless. Literally every server on the internet is "vulnerable" to this.
You can spam TCP SYNs to any server with a TCP stack and flood the victim
with SYN/ACKs (if the port is open) or RSTs (if it's closed). Or send UDP
traffic to a closed port and hit the victim with ICMP port-unreachable
messages. Or ICMP echo-request and hit with echo-replies.

---

From: James Browning <[email-masked]>
Date: Tue, 27 Apr 2021 08:00:00 -0700

Many weeks late and totally lacking funds here are some comments I made
while reading through the autokey3 document  and mostly not understanding
it. Also, I am clear as mud.

= begin dump =

pre didn't I hear some apocryphal thing about Asimov actually hating the
three laws a going out of his way to try and prove they were flawed and got
annoyed that people associated them with him.

2.1 Is fragmentation and consequences eeevil or just annoying...
    reserve type/length? zero for legacy crap mac please not. shove into an
extension.
    Ah, no critical bits no errors...
    a type 3 instead of just request/response the dogleg...

2.2 no server persistent state you say...
    it does not shove persistent bits of the state info into the keys
list...

2.3 interesting choices using RSA and SHA[23] in 256-bit modes isn't RSA256
kind of weak sauce though.

3.2 usually DNS and PKI are available.
    what onwire proto tests? association keys?

3.6 root nodes not singular, or ntp-tree not network initially
    topology changes due to hosts getting their act together (only early?

4.  re-order 'format, private key, and onwire' to 'format, onwire, private
key'
    Ah, checking the signing before checking the contents.

4.1 see 2.1 remarks for snark about legacy MAC crap

4.2 thought it was 1-65535? I thought key 0 was reserved as a not a key?
    invasion from foreign nationals?
    append to 4
    expire autokeys after N time unused >35minutes probably
    expire autokeys after O longer time even if used >1week
    I don't think there is a SHA160

4.3 should it be earlier than the current outstanding packet unless P-random

433 totally unrelated top NTS I am sure

4.4 ensure? Yes, I am sure I noticed that thing from autokey in your notes
I never read.

4.5 it is so easy to create and set new variables in compiled code.
    Also not well explained to me, but I are dum

451 what is skew again? expressed differently, please

452 compiled code, not script
453 sigh "

461 wordy and clear as mud to me

462 protected by mac not 'NAC', and I think annoyingly many rounds.

463 gethostname, not gethostbyaddr which is so wrong and deprecated. not
even partially qualified, pool unfriendly?

465 reject anything more than panic in the future and less than 2**(poll-1)
in the future.

5.3 the rub is that the lack of saved state really means the state is
pushed to mismanaged global state space

5.4 memory resources are scarce? maybe associate bloom filters for each
step and reset them periodically

5.5 no mention of people using the IERS leap file?

a.1 not just the globe random() function I suppose a Mersenne twister prng
is too hard. urban dogfights?

a.7 so much wrong... MRU by default starts at 37 entries and increases by
37/38 entries to a maximum of 9532ish. which can/should be adjusted in the
config file. furthermore, at 3000 distinct peers per second, the MRU list
starts growing in about a quarter of a second (not tens of seconds) and a
reasonable MRU size will be at least 3,072,000 which would chew up a
whopping 300MB of ram.

b3 shitting on NTS will not make autokey3 grow and may well have to
opposite influence.