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

" tglassey@earthlink.net " <tglassey@earthlink.net> Wed, 29 May 2019 11:06 UTC

Return-Path: <tglassey@earthlink.net>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D9C120106 for <ntp@ietfa.amsl.com>; Wed, 29 May 2019 04:06:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.135
X-Spam-Level:
X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.415, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=tglassey@earthlink.net header.d=earthlink.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onfzfkklRJAB for <ntp@ietfa.amsl.com>; Wed, 29 May 2019 04:06:07 -0700 (PDT)
Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAC3012008D for <ntp@ietf.org>; Wed, 29 May 2019 04:06:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1559127967; bh=C3kiRb4ssVK10RqwXaVDSKeq9/0BqgPomKvO 4UukVI8=; h=Received:To:From:Subject:Date:MIME-Version:Content-Type: Message-ID:X-ELNK-Trace:X-Originating-IP; b=YqdDNgd6hylEMYn2OZQgoj iBu0xmkV3AW5fi7lbdMGRLcxTVmhBADqx2S4c0Pm+2dh6/y7gKo8HyDba3ggZjlS/Z9 dXu2cFuT0tjkg0uZ6gqS70VB0YHRQDPuEaae+kgDSveMvMrxJivPGILdr4/Hklc1QSu CRpWiMxqlW5khNZTeEkSU9CNAp9Bsy7TC3EqbZ725Zp/D+czJsmF8Sqd/k9YMfevmVF m4SYkXYgKYzKMIBULWSgofNjHtAt5mOyb16EGbZX7QD8MYG5YhZmarecBqAxET8UzHD csr+U+dx94szsKa9NQlNSQXLMOhcU1DuvJHahc0uhelOTe1VVK4w==
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=nIjWjr3vL2yyKGAtQjGOWN65Zm1jlf92vyfaJtD2UWqS9/pODZ6llpUNpx9d59B65yUoHdqbCJAJBAagWUTzpSHAAV08VQhEisVONG01LjakR5YnRWrJdfF4PSjAQiOOZdLiUTDzANI5ydCqCkASWDYWrBpzFpOEb/+JHbAqhspLyhf+im24xcptxD+gcJebo0YmtLroP7pGtwg56nTySHfOacuarQaPVHo38+2EAOTZRvhHApqNel7l+EmQIBzJUA2gEQV4PCLmhgVm3ZQpz3HvbqAh1hyTcEoSOOXc6PISiGY5idkcUa9IrzCtWtwPUp/O3NKRFY4Uvfdm5UHWvA==; h=Received:To:From:Subject:Date:MIME-Version:Content-Type:Message-ID:X-ELNK-Trace:X-Originating-IP;
Received: from [86.57.143.48] (helo=[100.96.204.22]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from <tglassey@earthlink.net>) id 1hVwPF-000GeU-TQ; Wed, 29 May 2019 07:06:06 -0400
To: "=?utf-8?B?SGFybGFuIFN0ZW5u?=" <stenn@nwtime.org>,ntp@ietf.org
From: "=?utf-8?B?dGdsYXNzZXlAZWFydGhsaW5rLm5ldA==?=" <tglassey@earthlink.net>
Date: Wed, 29 May 2019 14:06:05 +0300
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_0_1559127965619"
Message-ID: <E1hVwPF-000GeU-TQ@elasmtp-kukur.atl.sa.earthlink.net>
X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec7984639b35583f456e0899f7443a4d9a19350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 86.57.143.48
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/4UfdbpOYHn_Lj5oig0JZQMEuKLk>
Subject: Re: [Ntp] =?utf-8?q?New_rev_of_the_NTP_port_randomization_I-D_=28Fwd?= =?utf-8?q?=3A_New_Version_Notification_for_draft-gont-ntp-port-randomizat?= =?utf-8?q?ion-01=2Etxt=29?=
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 May 2019 11:06:11 -0000

Possibly. If the Cliet has a policy interface which can trigger alarms on being attacked, then yes.  If not its possibly just a feature which will get little use. 

Still there are cases where it could be interesting.

Sent from my HTC, so please excuse any typos.

----- Reply message -----
From: "Harlan Stenn" <stenn@nwtime.org>
To: "tglassey@earthlink.net" <tglassey@earthlink.net>et>, <ntp@ietf.org>
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 09:06

On 5/28/2019 10:58 PM, tglassey@earthlink.net 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
--
> //tsg
> 
> Sent from my HTC, so please excuse any typos.
> 
> ----- Reply message -----
> From: "Harlan Stenn" <stenn@nwtime.org>
> To: <ntp@ietf.org>
> 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
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
> 

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