[Ntp] Antw: Re: NTS Hackathon coordination

"Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> Wed, 27 March 2019 10:04 UTC

Return-Path: <Ulrich.Windl@rz.uni-regensburg.de>
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 7BAA41202B2 for <ntp@ietfa.amsl.com>; Wed, 27 Mar 2019 03:04:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 ChcLIVVidnsK for <ntp@ietfa.amsl.com>; Wed, 27 Mar 2019 03:04:05 -0700 (PDT)
Received: from rrzmta1.uni-regensburg.de (rrzmta1.uni-regensburg.de [194.94.155.51]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80051120518 for <ntp@ietf.org>; Wed, 27 Mar 2019 03:04:03 -0700 (PDT)
Received: from rrzmta1.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 48B7F67EB8 for <ntp@ietf.org>; Wed, 27 Mar 2019 11:04:01 +0100 (CET)
Received: from gwsmtp1.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by rrzmta1.uni-regensburg.de (Postfix) with ESMTP id 2742E675B7 for <ntp@ietf.org>; Wed, 27 Mar 2019 11:04:00 +0100 (CET)
Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Wed, 27 Mar 2019 11:04:00 +0100
Message-Id: <5C9B4A8E020000A1000305BE@gwsmtp1.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.1.1
Date: Wed, 27 Mar 2019 11:03:58 +0100
From: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
To: Daniel Franke <dfoxfranke@gmail.com>, mlichvar@redhat.com
Cc: "ntp@ietf.org" <ntp@ietf.org>, Hal Murray <hmurray@megapathdsl.net>
References: <20190322223210.1181540605C@ip-64-139-1-69.sjc.megapath.net> <CAJm83bCkJ+yOe_P=ZefZS8ve1sNft7n6fLK3sRnLfBdME2kwhg@mail.gmail.com> <20190327093142.GH16488@localhost>
In-Reply-To: <20190327093142.GH16488@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/08V0a5jyTUVY3j0puj9xYtCwL0U>
Subject: [Ntp] Antw: Re: NTS Hackathon coordination
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, 27 Mar 2019 10:04:20 -0000

>>> Miroslav Lichvar <mlichvar@redhat.com> schrieb am 27.03.2019 um 10:31 in
Nachricht <20190327093142.GH16488@localhost>:
> On Sat, Mar 23, 2019 at 12:37:55PM +0100, Daniel Franke wrote:
>> We need to get the word out to network operators to stop filtering in this
>> manner (and that if they really must filter, they should limit it to mode
7
>> packets).
> 
> And mode 6 packets, which still seem to be enabled by default in the
> implementations that support it.

As a side-note: Our university also had blocked almost all NTP traffic to the
outside, making NTP pool servers ridiculous: The client gets a long list of
addresses through DNS, but cannot reach any of those. If you compare that to
some multicast/manycast solution, the client wouldn't receive any server. I'd
prefer the second.

In the past I could query various "outside" servers, even with mode 6 packets.
I don't like the state as it is now, but if there's threat (mostly by lawyers
claiming refund for denial of service originating from the universitiy's
network) the security people shut down service. More and more services get shut
down here...

> 
>> As a (hopefully) temporary measure, implementers should make it
>> easy for users to serve NTP on an alternate port in addition to 123, and
>> use Port Negotiation in NTS‑KE to advertise it. There should be no need
for
>> any spec changes or IANA actions to accommodate this behavior; since we
>> have the negotiation mechanism, there is no need for a registered port and
>> administrators can pick anything not in use by another service.
> 
> That won't work with firewalls which have whitelisted UDP ports. This
> is a common practice in some environments. (Stateful firewalls can't
> get the number from the encrypted NTS‑KE.)
> 
> I think we should specify an alternative port for NTP, where modes 6
> and 7 are not allowed. The port 123 is doomed. It's increasingly
> difficult to find an ISP that doesn't block the port. Some large
> network operators seem to limit rate of packets using that port. Two
> of my public servers recently became unusable for this reason. Nobody
> cares.
> 
> Blocking and rate limiting of the port is probably the main reason why
> the number of public servers is still dropping 5 years after the
> amplification attacks started.
> 
> ‑‑ 
> Miroslav Lichvar
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org 
> https://www.ietf.org/mailman/listinfo/ntp