Subject: [Ntp] New rev of the NTP port randomization I-D (Fwd: New Version Notification for draft-gont-ntp-port-randomization-01.txt)

From: Fernando Gont <[email-masked]>
Date: Tue, 21 May 2019 02:21:22 -0400

Folks,

We have published a rev of our I-D on NTP port randomization, based on
the feedback we've received so far:
https://www.ietf.org/internet-drafts/draft-gont-ntp-port-randomization-01.txt

At this point we'd like the wg to consider our document for wg adoption.

Thanks!

Cheers,
Guillermo & Fernando

-------- Forwarded Message --------
Subject: New Version Notification for
draft-gont-ntp-port-randomization-01.txt
Date: Mon, 20 May 2019 23:10:47 -0700
From: [email-masked]
To: Fernando Gont <[email-masked]>, Guillermo Gont
<[email-masked]>

A new version of I-D, draft-gont-ntp-port-randomization-01.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:		draft-gont-ntp-port-randomization
Revision:	01
Title:		Port Randomization in the Network Time Protocol Version 4
Document date:	2019-05-20
Group:		Individual Submission
Pages:		7
URL:
https://www.ietf.org/internet-drafts/draft-gont-ntp-port-randomization-01.txt
Status:
https://datatracker.ietf.org/doc/draft-gont-ntp-port-randomization/
Htmlized:
https://tools.ietf.org/html/draft-gont-ntp-port-randomization-01
Htmlized:
https://datatracker.ietf.org/doc/html/draft-gont-ntp-port-randomization
Diff:
https://www.ietf.org/rfcdiff?url2=draft-gont-ntp-port-randomization-01

Abstract:
   The Network Time Protocol can operate in several modes.  Some of
   these modes are based on the receipt of unsolicited packets, and
   therefore require the use of a service/well-known port as the local
   port number.  However, in the case of NTP modes where the use of a
   service/well-known port is not required, employing such well-known/
   service port unnecessarily increases the ability of attackers to
   perform blind/off-path attacks, since knowledge of such port number
   is typically required for such attacks.  This document formally
   updates RFC5905, recommending the use of port randomization for those
   modes where use of the NTP service port is not required.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Danny Mayer <[email-masked]>
Date: Tue, 28 May 2019 15:41:08 -0400

I'm formally objecting to adopting this draft since it accomplishes
nothing. RFC5905 specifically states in Section 8 paragraph 5 that the
origin timestamp should be checked with what was sent from the NTP
Client: "A packet is bogus if the origin timestamp t1 in the packet does
not match the xmt state variable T1. "

The origin timestamp is a 64-bit quantity that must be returned by the
server that is providing timestamps for the NTP Client to process. An
offpath attacker would have a hard time guessing even the correct number
of seconds never mind the other 32 bits of the timestamp. Randomizing
the port number adds another 16 bits which is overkill when you cannot
even guess the first 64 bits.

Furthermore you should try and have more than one source which would add
a minimum of another 64 bits of nonce.

While we are at it the CERT specified in the draft is similarly invalid
because of the above.

Danny

On 5/21/19 2:21 AM, Fernando Gont wrote:
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
>
>

---

From: Fernando Gont <[email-masked]>
Date: Tue, 28 May 2019 19:08:05 -0400

Hi, Danny,

On 28/5/19 15:41, Danny Mayer wrote:
> nothing. 

The claim is, of course, incorrect. You might make your own assessment
regarding you think the existing ___ is already good enough. That
doesn't mean port randomization accomplishes nothing.

In fact, port randomization is a best current practice (RFC6056 / BCP
156). So I'd argue that you should actually make a case for predictable
port numbers, rather than the other way around.

We have had plenty of evidence that employing predictable numeric ids is
a bad idea. It is quite interesting that in 2019 (after dealing with
predictable TCP ISNs, predictable DNS TxIDs, predictable IPv{4,6} frag
ids, etc.), there are still folks arguing in favor of employing
predictable numeric identifiers...

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Gary E. Miller" <[email-masked]>
Date: Tue, 28 May 2019 17:42:08 -0700

Yo Fernando!

On Tue, 28 May 2019 19:08:05 -0400

> doesn't mean port randomization accomplishes nothing.

I guess you missed this discussion recently on time-nuts:

http://lists.febo.com/pipermail/time-nuts_lists.febo.com/2019-May/096536.html

Different NTP source ports yield varying quality results.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	[email-masked]  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin

---

From: Fernando Gont <[email-masked]>
Date: Tue, 28 May 2019 22:56:39 -0400

Hi, Gary,

> Different NTP source ports yield varying quality results.

So... this would be an argument for "randomize the source port on a
per-session basis, but not on a per-request basis", right?

Thanks a lot!

Cheers,

---

From: "Majdi S. Abbas" <[email-masked]>
Date: Tue, 28 May 2019 20:20:24 -0700

Fernando,

    Randomizing the source port is pointless.  As Danny has noted, t1 already acts as a 2^64 nonce on each client mode chime request.  This sufficiently hardens the unauthenticated case to an off path attacker.  If additional security is required, authentication (via classic PSK, or NTS modes) should be used.

    Per session randomization doesn't resolve these issues -- the stated rationale for both the draft and filed CVE is hardening to off path attacks, which we've just covered.

    "Because it's best practice" isn't a reason -- it's a crutch to save a draft that was filed due to an insufficient understanding of RFC 5905 and current implementations of NTPv4.  The true best practice here is authentication, and it does not seem to be a worthwhile effort
to restructure existing implementations to add 16 bits to
the existing nonce with work like NTS
pending to cover the client/server use case.

     Cheers,

     --msa

---

From: Fernando Gont <[email-masked]>
Date: Wed, 29 May 2019 00:18:28 -0400

On 28/5/19 23:20, Majdi S. Abbas wrote:
> 
> Randomizing the source port is pointless.  As Danny has noted, t1
> already acts as a 2^64 nonce on each client mode chime request.  This
> sufficiently hardens the unauthenticated case to an off path
> attacker.  If additional security is required, authentication (via
> classic PSK, or NTS modes) should be used.

Using predictable numeric identifiers is a bad habit. We have plenty of
history in this area and, as noted, it's quite interesting to see folks
pushing in this direction in 2019, when the tendency has been to
actually move away from predictable numeric IDs (TCP ISNs, transport
protocol numbers, DNS TxIDs, Frag IDs, etc.).

Using predictable port numbers makes it easy for an attacker to infer
the "session id". You are just considering one possible attack scenario.

> Per session randomization doesn't resolve these issues -- the stated
> rationale for both the draft and filed CVE is hardening to off path
> attacks, which we've just covered.

If tomorrow a flaw were found in an NTP implementation, that happened
e.g. prior to the validation of the origin timestamp, I guess you are
going to argue that "that was out of scope"?

> "Because it's best practice" isn't a reason -- it's a crutch to save
> a draft that was filed due to an insufficient understanding of RFC
> 5905  and current implementations of NTPv4. 

Please enlighten me:
Could you please explain why NTP needs a well-known transport protocol
number when operating in client/server mode?

> The true best
practice here is authentication, and it does not seem to be a worthwhile
effort
> to restructure existing implementations to add 16 bits to the
> existing nonce with work like NTS pending to cover the client/server
> use case.

Of the implementations I've checked, there's only one that doesn't do it.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 29 May 2019 00:37:17 -0400

On 28/5/19 23:20, Majdi S. Abbas wrote:
>     "Because it's best practice" isn't a reason -- it's a crutch to save a draft that was filed due to an insufficient understanding of RFC 5905 and current implementations of NTPv4.  

Oh, by the way. While you enlighten me why you need a fixed well-known
port number for the client, and how necessary this is, please also
elaborate on how I'm running multiple NTP clients behind a NAT box.

Thanks,

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 28 May 2019 22:20:27 -0700

> elaborate on how I'm running multiple NTP clients behind a NAT box.

Nobody seems to be saying there is benefit to *only* using the
well-known port number when sending a client request.  People are saying
that requiring this in all cases doesn't buy any significant benefit.

Of course it's fine if NTP client goes thru a NAT gateway.

So here's a related question for you:

Is there benefit to knowing if you are being attacked?

-- 
Harlan Stenn, Network Time Foundation
http://nwtime.org - be a Member!

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 28 May 2019 22:21:54 -0700

> that requiring this in all cases doesn't buy any significant benefit.

I was unclear above - "this" refers to always requiring a random port
for sending client requests.

H
--

---

From: Fernando Gont <[email-masked]>
Date: Wed, 29 May 2019 02:59:22 -0400

> for sending client requests.

The draft says "SHOULD" -- i.e., do it unless you have a very good
reason not to.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 29 May 2019 03:17:46 -0400

> that requiring this in all cases doesn't buy any significant benefit.

Employing predictable numeric IDs is bad practice. The current
requirement (which cannot even be complied to in IPv4-NATed networks),
requires a fixed well-known port for clients. i.e., the spec mandates
against a BCP (port randomization) and on the well-known concept that
employing predictable IDs is asking for trouble.

Our document reverses that: It recommends what's is known to be a good
practice, and gives you room (it's a "SHOULD", not a "MUST") if you have
a really good reason not to randomize the client port.

As noted in some other message, the analysis so far has focused on
attack packets that might get tossed if the org timer is not valid.
There might also be implementation bugs (e.g., buffer overflows, or
whatever) that happen before that.

> Of course it's fine if NTP client goes thru a NAT gateway.

That's an indication that the current requirement in the spec is bogus.
In fact, if you actually mandated it (e.g., the server were to require
that the client port be 123), deployed clients would break.

> Is there benefit to knowing if you are being attacked?

That's orthogonal to this. You don't need to leak the session ID in
order to run a NIDS. -- and, no matter what you have in mind, I'll
repeat the above: the requirement is in "SHOULD" level -- you can go
against it if you have a really good reason to.

Thanks,

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 29 May 2019 09:47:16 +0200

> per-session basis, but not on a per-request basis", right?

I think it's actually an argument for randomizing the port on each
request. If there are multiple paths to the server and the selection
depends on the port number, the client needs to be changing its port
to make sure some of its requests take the shortest path. The clock
filter will drop measurements that took a longer path (assuming the
increase in delay is significant when compared to jitter and clock
dispersion).

If you had two clients in your network and they were synchronized to
the same server, there could be a significant offset between their
clocks if they used a fixed port. If they randomized their ports with
each request, the offset should be smaller and not change randomly
when the clients are restarted, etc.

Also, a client using a fixed port is easier to track. That might be
more relevant for the data minimization draft.

-- 
Miroslav Lichvar

---

From: Danny Mayer <[email-masked]>
Date: Wed, 29 May 2019 04:42:11 -0400

> the "session id". You are just considering one possible attack scenario.
You are totally missing the point. The port numbers don't make NTP
vulnerable. The "session id" does not exist here. Instead NTP has an
origin timestamp that an off-path attacker does not have access to. Even
if it did, then the origin timestamp is wildly different each time it's
sent and is not predictable. This is a 64-bit nonce.

RFC6056 was probably developed as a result of the Kaminsky attack on DNS
and the way we fixed that. I noticed a number of people mentioned in
that RFC who were involved in those changes. It doesn't say so but that
RFC addresses shortcomings in those protocols that have small or
non-existent nonces which is not the case for NTP. Since you were one of
the authors I presume you know that. I discussed NTP with Paul Vixie at
the time and we agreed that because of the nonce it would not be
vulnerable like DNS was.

Since you claim that having well-known source ports is a vulnerability,
how does an off-path attacker know the server IP addresses that it is
using to get the timestamps? Accepting that, please provide in detail
how the off-path attacker is able to set up the origin timestamp so that
the client will accept it. You MUST be able to do this for the attack to
succeed. Remember that 64-bit timestamps are wildly different each time
a request goes out. If you cannot do this you have no case. Note that
replay attacks fail too since the client has already processed a given
origin timestamp.

> going to argue that "that was out of scope"?
There is no session validation since this is UDP not TCP. A flaw in an
NTP implementation that did not check that the timestamp matched would
be a bug in that implementation and randomizing the source port is not
going to change that. Furthermore the client needs the origin timestamp
to find the match in its local memory in order to process the incoming
packet. if it cannot find it, it will ignore the packet.

Danny

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 29 May 2019 10:50:56 +0200

Hi!

I think in case of a DDoS attack the extra 14 bit of random port give little
extra protection: The attacker could send to any port (or from virtually any
port) on the attacked machine.

Regards,
Ulrich Windl

>>> Fernando Gont <[email-masked]> schrieb am 29.05.2019 um 06:18 in
Nachricht <[email-masked]>:
>> Per session randomization doesn't resolve these issues ‑‑ the stated
>> "Because it's best practice" isn't a reason ‑‑ it's a crutch to save
> Could you please explain why NTP needs a well‑known transport protocol
> ‑‑ 
> e‑mail: [email-masked]

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 29 May 2019 11:06:24 +0200

>>> Danny Mayer <[email-masked]> schrieb am 29.05.2019 um 10:42 in Nachricht
<[email-masked]>:

> origin timestamp that an off‑path attacker does not have access to. Even
> sent and is not predictable. This is a 64‑bit nonce.

...of which about 30 bits are random (assuming the attacker knows what time it
is and packets take less than one second to travel)...

[...]

Regards,
Ulrich Windl

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 29 May 2019 02:18:08 -0700

> employing predictable IDs is asking for trouble.

By the same token, generally applying rules without fully understanding
the costs/benefits and other trade-offs is bad practice.

The NAT case you mention is a red herring.  That case effectively
randomizes the port already, at least outside the LAN.

> a really good reason not to randomize the client port.

I'll re-read the proposal, and if the proposal doesn't go in to the
pros/cons of the choices then the proposal is, IMO, fatally deficient.

I'm pretty comfortable in my belief that I think I have a good awareness
of these issues.

You believe you have a similar awareness.

But I submit the vast majority of folks who will read this will not have
the level of awareness to make an informed decision.

> attack packets that might get tossed if the org timer is not valid.

When would a packet with an invalid org timer *not* be tossed?  This
sounds like another straw-man to me.

> whatever) that happen before that.

So what?  Really - what difference would the port number make if there
are implementation bugs of the type you now hypothesize?

> that the client port be 123), deployed clients would break.

RFC5905 section 9.1 says:

   srcport: UDP port number of the server or reference clock.  This
   becomes the destination port number in packets sent from this
   association.  When operating in symmetric modes (1 and 2), this field
   must contain the NTP port number PORT (123) assigned by the IANA.  In
   other modes, it can contain any number consistent with local policy.

Where is the "current requirement in the spec", and who is proposing a
"mandate"?  Your points seem to be at least red-herrings, and could be
full-on straw man fallacies.

You are very certain of the number and scope of your use-cases.  I
believe the problem scope and use-cases are more diverse than what you
describe, and your solution, while appropriate for some of these,
*prevents* detection/remediation in other scenarios.

If you know these things, then you're trolling and wasting people's time
and energy.  If you don't know it, then ... I'll stop there.  But maybe
I'm missing something.

> against it if you have a really good reason to.

I'd be a lot more receptive to your points if you showed more awareness
of the tradeoffs and identification of the various problem scenarios and
use-cases, and made proposals that were better rooted in reality.

But I'm not sure anybody besides me cares about my opinion/position on
your proposal.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 29 May 2019 05:12:34 -0400

On 29/5/19 04:42, Danny Mayer wrote:
> vulnerable. The "session id" does not exist here. 

Attackers need to know the four-tuple that was employed by the query.
That's a prerequisite for attacking NTP. When you *unnecessarily* employ
a predictable port on the client side, you are making the attacker's
life easier. Period.

> Instead NTP has an
> origin timestamp that an off-path attacker does not have access to.

That's *not* "instead". Port numbers identify the transport protocol
instance. The org timestamp is an protocol specific value.

What you're saying is the equivalent that we should not randomize TCP
source ports because we also do TCP ISN randomization. And such logic is
very flawed, of course.

> and the way we fixed that.

It wasn't.

> I noticed a number of people mentioned in
> non-existent nonces which is not the case for NTP. 

Huh? You are mixing up transport layer with app layer. Again: using
predictable numeric IDs is a bad idea.

NO matter what you do at upper layers, you shouldn't use predictable
numeric IDs. I can't believe that we are discussing this in 2019.

> packet. if it cannot find it, it will ignore the packet.

You missed my example. I was referring to, e.g. o possible a bug in the
NTP implementation, present *prior* to the validation of the org
timestamp (e.g., processing of malformed packet, etc.).

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 29 May 2019 02:31:12 -0700

> is and packets take less than one second to travel)...

How did you come up with 30 bits?

And remember that:

- the window of time where an attack is possible starts when the client
  sends its request, and ends when a valid response is received.
- a competent client will log bogus responses, at least during this
  window, and if the client is NTP as opposed to SNTP, will log
  *any* bogus received packets.

Further note:

- 30 bits is over a billion choices
- average clients can process maybe 2k packets per second
- the window of time on this attack is likely under a quarter
  to half a second, so 500-1,000 packets out of a billion
- MAC protection adds a *lot* of protection on this
- bogus packets received during the window are likely logged,
  and if MAC protected will generate a CRYPTO-NAK back to the
  real server, which, if reasonably implemented, will also
  be logged.

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 29 May 2019 11:39:16 +0200

>>> Harlan Stenn <[email-masked]> schrieb am 29.05.2019 um 11:31 in
Nachricht
<[email-masked]>:

>> ...of which about 30 bits are random (assuming the attacker knows what time

> it

I assumed: 32 bits integral seconds, and 32 bits fractional seconds. Assume
the packets arrive within 250ms, your at 30 bits uncertainty ("random")

>   sends its request, and ends when a valid response is received.

An attacker will probably "spray" attacking packets.

>   *any* bogus received packets.

The point is whether logging unexpected packets actually opens a DoS windows.

>   to half a second, so 500-1,000 packets out of a billion

I agree, but please don't treat it as 64-bit random value that is to be
guessed.

>   real server, which, if reasonably implemented, will also

My remark was solely on "64-bit" random...

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 29 May 2019 03:02:49 -0700

> the packets arrive within 250ms, your at 30 bits uncertainty ("random")

That's fine, and assuming the attacker is blind then I think we're
really talking about 32 and possibly 33 bits, because there is a
significant chance the window will span the boundary between seconds.

That also assumes the client has the correct time.  If somebody is using
SNTP, this assumption may be wrong, and the client's time could well be
off by much more.  At 33 bits, we're talking about 2 seconds.  If the
client might be off by 4-8 minutes then we're talking about 41 bits.

> An attacker will probably "spray" attacking packets.

OK, so what?  Low end normal machines might handle 2k packets/second,
and low end slow machines are lucky to be able to handle 200 packets per
second.

> The point is whether logging unexpected packets actually opens a DoS windows.

That's something logging systems can reasonably be expected to handle,
and it's also reasonable to assume that if somebody goes to the trouble
to log these events they're also alerting on them.

> I agree, but please don't treat it as 64-bit random value that is to be

Not a problem.  Also note that even 30 bits is huge if you're attacking
a slow processor that can only handle 200 packets/second.  In this case,
the attacker might be able to send back 50-100 packets out of a billion,
so if no MAC protection is used that's still 5-10 chances in 100
million.  I read the odds of drowning while taking a bath are 1 in
840,000, so this would be about 50-100 times more rare.

> My remark was solely on "64-bit" random...

No worries.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 29 May 2019 06:03:15 -0400

>>>> On 28/5/19 23:20, Majdi S. Abbas wrote:
[....]
> the costs/benefits and other trade-offs is bad practice.

I understand that your implementation employs port 123 as the source
port. You mentioned that makes the code simpler. That's probably also
the case when using predictable IDs (e.g. resulting from a counter) vs.
randomized ones.

Protocol-wise: could you state what are the drawbacks of employing
randomized port numbers?

> randomizes the port already, at least outside the LAN.

The point I was trying to make is that if it was so vital protocol-wise
that a specific port were used as the source port, then NTP would not
work across NATs. Of course it does work, because the client port can be
anything.

> are implementation bugs of the type you now hypothesize?

Difficulty in hitting the four-tuple being employed for NTP?

> "mandate"?  

Yes, my bad. This is open, without a recommendation on what to do. The
implementation I was running was indeed using port 123.

> *prevents* detection/remediation in other scenarios.

Not much like that. Actually, I was analyzing traffic, and then going
through the spec, and surprised the client port used by the
implementation I was running was employing port 123. Tried to track why
that was the case.

Having worked on predictable numeric ids for a number of protocols, I
expected this to be an historical artifact, in the area of "yeah,
sure... we should have been randomizing it", do the recommendation and
move on.

> use-cases, and made proposals that were better rooted in reality.

I'm still trying to figure out e.g. what your implementation does or
expects to do when you e.g. receive NTP packets with right four-tuple
and, say, invalid org timer. Anything else other than toss the offending
packets out? And, if that's the case, why are you interested in
processing them instead rather than have them tossed before they get to
the NTP process?

> But I'm not sure anybody besides me cares about my opinion/position on

FWIW, I'm interested in your feedback.

Thanks,

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 29 May 2019 12:06:23 +0200

> is and packets take less than one second to travel)...

I assume this whole discussion is about clients not using fully random
transmit timestamps (as specified in the data minimization draft).

30 bits is not that much. A typical NTP client running on a modern
computer can receive and process few hundred thousands packets per
second. This means it would accept a spoofed response in less than an
hour (assuming most of genuine responses from the server are dropped
in the network or socket). With 14 extra bits of entropy from the
source port it would be a year. That's a significant improvement.

In reality, I think it's quite a bit less than 30 bits. If we assume
the clock is accurate to 1 millisecond, it's only about 22 bits worth
of guessing. Then there are other things that may make this even
easier.

The client may be using a fixed 1-second timer to schedule its
transmissions and it may also be running as a stratum-2 server,
leaking the receive timestamp as the reference timestamp and leaking
the delay as root delay, which make the transmit/origin timestamp even
more predictable.

-- 
Miroslav Lichvar

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 29 May 2019 03:10:37 -0700

> Protocol-wise: could you state what are the drawbacks of employing

I think this point has been covered before, more than once.

> work across NATs. Of course it does work, because the client port can be

This sounds to me like you're admitting you gave a straw-man argument.

> Difficulty in hitting the four-tuple being employed for NTP?

How do implementation bugs play in to this?

The loopback test is one of the *first* checks that must be passed
according to the Standard.

> processing them instead rather than have them tossed before they get to

You're really having trouble finding out the answer to this?

I was told that you are generally diligent and a "deep diver" into these
sort of problems.  I'm not seeing that here.

> FWIW, I'm interested in your feedback.

OK, thanks!

I'm still replying to your posts, if that's an indication.

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 29 May 2019 12:13:45 +0200

>>> Harlan Stenn <[email-masked]> schrieb am 29.05.2019 um 12:02 in Nachricht
<[email-masked]>:

[...]
> client might be off by 4-8 minutes then we're talking about 41 bits.

Do you really think someone planning to attack NTP will start with a clock that is  minutes off the correct time?

> and low end slow machines are lucky to be able to handle 200 packets per

It there a difference between the client being overloaded with attack packets that are "wrong" or attack packets that are "correct"? I was arguing that "enough packets" could easily be created, while you argue the client can't handle them.

> to log these events they're also alerting on them.

Yeah: Filesystem full ;-)

[...]

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 29 May 2019 03:16:08 -0700

> transmit timestamps (as specified in the data minimization draft).

And this may also be a terrible idea.  It prevents the server from
having any idea how accurate the client may be.

> source port it would be a year. That's a significant improvement.

You're seeing different numbers than I am.  I'm seeing typical NTP
clients handle the numbers I quoted, and low-end embedded clients
handling at least an order of magnitude fewer.  I'm talking about
packets that do *not* have MAC protection.  The thruput rate would drop
for MAC protected packets.

> of guessing. Then there are other things that may make this even

This may be true for an NTP client.  I would like to see numbers for an
SNTP client where the clock free-runs for hours to days at a time.

> the delay as root delay, which make the transmit/origin timestamp even

How is an off-path attacker going to see this information?

Why is a stratum 2 server in a hostile environment not using MAC
protection, or using enough upstream servers?

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 29 May 2019 12:16:54 +0200

> >>   sends its request, and ends when a valid response is received.

The attacker can prevent the valid responses from being received or
processed simply by sending the client more packets that it can
handle.

> and low end slow machines are lucky to be able to handle 200 packets per

Your figures are off by several orders of magnitude.

I suspect the attack is practical, at least for clients using only one
server, but nobody has tried it (and published the results) yet.

-- 
Miroslav Lichvar

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 29 May 2019 03:21:20 -0700

> Do you really think someone planning to attack NTP will start with a clock that is  minutes off the correct time?

An SNTP client, certainly.

But even one that is off by seconds still adds random bits.

And if the client doesn't care if the server can see its time, the
origin timestamp could be completely random.

> It there a difference between the client being overloaded with attack packets that are "wrong" or attack packets that are "correct"? I was arguing that "enough packets" could easily be created, whi…

Yes.  A correct packet that is correct will satisfy SNTP, and will close
the loopback test gate for NTP.  In the latter case, any further
received packets will be logged, and if they contain a bad MAC will
cause the transmission of a CRYPTO-NAK.

> Yeah: Filesystem full ;-)

If one does a poor job of managing log files, yes.

"Blessed are those who get what they deserve."

"Live and learn."

These possibilities have been understood for decades, and there are
known ways to address them.

---

From: Hal Murray <[email-masked]>
Date: Wed, 29 May 2019 03:23:25 -0700

> I agree, but please don't treat it as 64-bit random value that is to be

It looks like 64 bits to me.  You don't need to put an actual time in that 
slot.  Save the time, get a random number.  Put it in the packet and save it 
too.  When a reply arrives, compare the "time stamp" in the packet with the 
saved random number.  If they match, process using the saved time.

There was a draft describing that a year or so ago.

-- 
These are my opinions.  I hate spam.

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 29 May 2019 03:28:12 -0700

> processed simply by sending the client more packets that it can

"Can" or "might"?

If a client is both dumb about this and isn't using MAC protection, then
how can the user claim they want to put any trust in the time on the
target box?

> server, but nobody has tried it (and published the results) yet.

I checked my numbers a week or so ago.

Even if I'm wrong by as much as you claim, anybody who cares can easily:

- report the incoming bogus transmit timestamp packets
- report the incoming bogus MAC packets

and if time is that important, if they're running unprotected SNTP
clients on their edge then maybe they should be getting time from a
trusted source at their edge and not going to the internet for time.

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 29 May 2019 03:29:31 -0700

> There was a draft describing that a year or so ago.

It's certainly a choice.

One that would prevent a friendly server from knowing how far off the
client's time really is.

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 29 May 2019 13:03:18 +0200

> how can the user claim they want to put any trust in the time on the

There is a difference between off-path attacks and MITM attacks. I
think it's not unreasonable to expect the unauthenticated
client/server mode (unlike the symmetric mode) to be resilient against
off-path attacks.

> - report the incoming bogus MAC packets

That opens a possibility for a DoS attack on the logging mechanism or
the admin/user.

-- 
Miroslav Lichvar

---

From: Hal Murray <[email-masked]>
Date: Wed, 29 May 2019 05:20:00 -0700

> One that would prevent a friendly server from knowing how far off the

Why does a server care about the time on a client?

---

From: Danny Mayer <[email-masked]>
Date: Wed, 29 May 2019 11:23:26 -0400

> the case when using predictable IDs (e.g. resulting from a counter) vs.
what predictable ID's? NTP doesn't have a counter.

attackers can send any packets that they want to a port, that's at the
UDP layer. Whether or not the packet is valid is something that the
receiving client is supposed to be checking. Malformed packets are
instantly discarded and invalid origin timestamps are similarly tossed.

Your draft should be stating a useful purpose and the contents needs to
actually fulfill that purpose. All we have so far is some claim about
what port to use without showing how that is better than all of the
other safeguards already built into the NTP protocol.

Danny

---

From: Fernando Gont <[email-masked]>
Date: Wed, 29 May 2019 12:31:30 -0400

> what predictable ID's? NTP doesn't have a counter.

The client port is a numeric identifier. So the NTP does use a numerical
identifier. As noted, you essentially have three options:

1) Use a fixed value (123)
2) Use an ephemeral port resulting in a predictable port
3) Use a randomized source port

So.. there's one implementation that does #1, and folks seem to argue to
stick with it. #2 would require even more work, because most modern
kernel just don't generate predictable port numbers. And we are arguing
in favour of #3.

(#2 could be implemented as a counter. In fact, that's how most stacks
selected ephemeral port numbers prior to the port randomization work).

> receiving client is supposed to be checking. 

The four-tuple {src addr, src port, dst addr, dst port} is layer-4
stuff. If you conceal this info, you reduce the chances of an attacker
of sneaking a packet into the association/"connection".

Any checks you perform in NTP are app layer stuff. The two are orthogonal.

> Malformed packets are

That's the point: the two don't compete with each other. They are
orthogonal.

I'm not arguing that we should remove the others. Rather, I'm arguing
that using predictable client port numbers eases the task of an
attacker, unnecessarily.

Using randomized port numbers requires yet additional effort on the side
of the attacker. And means that the attacker now needs to guess the
client port, or otherwise his packets will not even make it to the ntp
process.

The transport area produced a BCP over the course of about 7 years, when
discussing similar topics. The BCP is RFC6056.

I would expect that an implementation that means to select a port
number, and does not want to follow, should make a technical argument
against that.

Thanks,

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 29 May 2019 10:15:04 -0700

> 2) Use an ephemeral port resulting in a predictable port

I'm not seeing that ephemeral UDP ports are predictable in general.  Got
a reference?

> selected ephemeral port numbers prior to the port randomization work).

So what?  An off-path attacker won't know these ports, an on-path
attacker won't(?) see them either, and a MITM won't care because the
MITM will see the port selected by the victim.

> of sneaking a packet into the association/"connection".

If the implementation is so poor that it would be victim to this attack
then this specific attack is very late to the party.

> Any checks you perform in NTP are app layer stuff. The two are orthogonal.

I'm not sure about this argument.

Stuff should be addressed at the appropriate API layer.

There are good reasons why one doesn't only put the smallest grain
filter at the entrance point.

> that using predictable client port numbers eases the task of an

Sorry, I'm still not seeing/buying this point.

> client port, or otherwise his packets will not even make it to the ntp

If your point is to change the last sentence of RFC590 9.1 where it says:

to:

   ... In other modes, it SHOULD contain any number consistent with
   local policy.

I'm fine with that.

> number, and does not want to follow, should make a technical argument

Deep packet inspection firewalls are Expensive, especially at higher
bandwidths.  Having these packets go out with known port number can be a
significant cost and performance savings.

That's just one point.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 29 May 2019 14:58:28 -0400

Harlan,

Responding this one in a separate email, since it seems we're converging
on something...

On 29/5/19 13:15, Harlan Stenn wrote:
[....]>> Using randomized port numbers requires yet additional effort on
the side
>    ... In other modes, it SHOULD contain any number consistent with

Yes. That's the whole point of this document.

Thanks!

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 29 May 2019 15:00:16 -0400

> I'm not seeing that ephemeral UDP ports are predictable in general.  Got

Appendix A (page 26) of RFC6056 contains a survey. Stacks were employing
the same code. In some cases, it was a counter. In other cases, a value
that was decremented. These algorithms are covered in "TCP/IP
Illustrated, Volume 2" by Rich Stevens, for example.

Nowadays, at least Linux and *BSD do port number randomization. OpenBSD
was first to do it. My co-author implemented the
code in Linux.

> MITM will see the port selected by the victim.

Exactly. Since the attacker doesn't know the randomized port, port
randomization increases the difficulty to successfully perform off-path
attacks.

As noted during today's call, there's plenty of IETF work in this area,
much of which I was involved in. see e.g. RFC5927,

> filter at the entrance point.

The deeper the upper the layer, the deeper the mitigation is in the
code, and the more expensive it is to execute it.

> significant cost and performance savings.

Actually, that reduces the ability of an ACL as a mitigation. Because if
the four-tuple employed for a transaction con be guess by the attacker,
he can always forge the correct values and bypass any kind of filtering.

Having clients use ephemeral ports also allows for easy identification
of NTP client vs server traffic -- if you wanted to distinguish that for
the purpose of packet filtering.

Thanks,

---

From: Watson Ladd <[email-masked]>
Date: Wed, 29 May 2019 14:27:23 -0700

On Wed, May 29, 2019 at 12:01 PM Fernando Gont <[email-masked]> wrote:
....
> the purpose of packet filtering.

As I mentioned on the virtual interim today, client port=server port
has negative implications for DDOS defense. I don't see what the
disadvantage of randomizing client port is that outweighs the
advantages.

---

From: Ask Bjørn Hansen <[email-masked]>
Date: Thu, 30 May 2019 09:04:47 +0800

> On May 29, 2019, at 5:18 PM, Harlan Stenn <[email-masked]> wrote:
> 

I’ve seen “enterprise NAT” devices that deliberately didn’t port randomize source ports below 1024 (so rather than getting them randomized you’d limit the network to one NTP client per server IP per NAT timeout interval).

On IPv4 it basically doesn't work without port randomization (at scale, etc).

Ask

---

From: Fernando Gont <[email-masked]>
Date: Thu, 30 May 2019 14:19:59 -0400

Hello, Miroslav,

> when the clients are restarted, etc.

Agreed. My question is: should one aim at the individual measurements to
be dropped, or at the server to be un-preferred over other (possibly
better) ones? -- I realize that in some scenarios this might happen with
all servers, in which case the former option (have individual
measurements dropped) might be a better option.

Thoughts?

Thanks!

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 30 May 2019 14:29:04 -0400

[....]
> that was decremented. These algorithms are * RFcovered in "TCP/IP

FWIW, compare lines 285-455 of
https://github.com/freebsd/freebsd/blob/4a037b3dd4b704250886ced57a0ab6d97411e694/sys/netinet/in_pcb.c

(15+ years old version of the FreeBSD kernel)

vs lines 602-717 of
https://github.com/freebsd/freebsd/blob/4a037b3dd4b704250886ced57a0ab6d97411e694/sys/netinet/in_pcb.c

current version of the FreeBSD kernel.

Most of the changes in this area happened around year 2004+, when there
was a lot of work in the transport area around off-path attacks, which
lead to:

* RFC6056 (BCP on port randomization)
* RFC5927 (ICMP-based off-path attacks against TCP, which similar
analysis to the one I did in the interim call yesterday)
* RFC4953 (TCP-based attacks against TCP)

and others.

As noted, OpenBSD was doing port randomization before everyone else.

Thanks!

Cheers,