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

From: "[email-masked]" <[email-masked]>
Date: Wed, 29 May 2019 08:58:31 +0300

Yes Harlen if you know you are being attacked the server can set itself as unavailable or untrustable until it recertifies. Information integrity is key for historical auditing of timestamps 

//tsg

Sent from my HTC, so please excuse any typos.

----- Reply message -----
From: "Harlan Stenn" <[email-masked]>
To: <[email-masked]>
Subject: [Ntp] New rev of the NTP port randomization I-D (Fwd: New Version Notification for draft-gont-ntp-port-randomization-01.txt)
Date: Wed, May 29, 2019 08:20

On 5/28/2019 9:37 PM, Fernando Gont wrote:
> On 28/5/19 23:20, Majdi S. Abbas wrote:
>> 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.  
> 
> 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.

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?

> Thanks,

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

_______________________________________________
ntp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ntp

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 28 May 2019 23:06:30 -0700

On 5/28/2019 10:58 PM, [email-masked] wrote:
> Yes Harlen if you know you are being attacked the server can set itself
> as unavailable or untrustable until it recertifies. Information
> integrity is key for historical auditing of timestamps 

What about attacks against the client?

Is there benefit to the client knowing it is being attacked?

H
--
> 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: Wed, 29 May 2019 03:07:11 -0400

> Is there benefit to the client knowing it is being attacked?

If you want that, you are free to run a NIDS. You get attack detection,
without leaking the "session ID".

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

---

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

> without leaking the "session ID".

Sorry, I'm not buying that.

It cost-shifts too much, and it isn't feasible for a number of
significant use cases.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 29 May 2019 04:41:32 -0400

> It cost-shifts too much, and it isn't feasible for a number of

I don't get why you'd want a known port number. You want attack packets
to hit the session, and count packets for which the org timer fails to
validate?

If so: what's the point?

---

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

> to hit the session, and count packets for which the org timer fails to
What session? There is no session in either UDP or NTP. If you think
there is, please tells us where to find it.

Danny

---

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

Danny