[Ntp] Antw: Re: NTS IANA request
"Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> Tue, 11 June 2019 06:25 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 09CCF12004A for <ntp@ietfa.amsl.com>; Mon, 10 Jun 2019 23:25:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 DWhh3okUbuoH for <ntp@ietfa.amsl.com>; Mon, 10 Jun 2019 23:25:32 -0700 (PDT)
Received: from mx1.uni-regensburg.de (mx1.uni-regensburg.de [IPv6:2001:638:a05:137:165:0:3:bdf7]) (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 C1C4512000E for <ntp@ietf.org>; Mon, 10 Jun 2019 23:25:31 -0700 (PDT)
Received: from mx1.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0F8266007969 for <ntp@ietf.org>; Tue, 11 Jun 2019 08:25:29 +0200 (CEST)
Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by mx1.uni-regensburg.de (Postfix) with ESMTP id DF9696007967 for <ntp@ietf.org>; Tue, 11 Jun 2019 08:25:28 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Tue, 11 Jun 2019 08:25:28 +0200
Message-Id: <5CFF4956020000A100031D3A@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.1.1
Date: Tue, 11 Jun 2019 08:25:26 +0200
From: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
To: Heiko Gerstung <heiko.gerstung@meinberg.de>
Cc: "ntp@ietf.org" <ntp@ietf.org>, "Gary E.Miller" <gem@rellim.com>
References: <CAN2QdAH9Uh_wYSEizgYTjd4Q6VFQT+tvH8dnbPgKKc59+vEfng@mail.gmail.com> <a123d81b-4994-9e35-58eb-6845cf439f91@nwtime.org> <20190605164753.6e71fcaa@rellim.com> <03055E77-EB42-494E-A231-039C4603E256@akamai.com> <CAJm83bDYZ+vcwkhFEf2YCAVwKcSm7rEgbuB0Wwsvm5XVVAMjuQ@mail.gmail.com> <C8E4189E-E3A1-4926-AF0F-93BE9C7255C8@akamai.com> <CAJm83bBkU91st1CFAsx+JCLpxXyWOQnSTY9sXeuA96R8pqXdCA@mail.gmail.com> <487FBFAD-D082-4CA8-AC14-C2CC8B007DBB@meinberg.de>
In-Reply-To: <487FBFAD-D082-4CA8-AC14-C2CC8B007DBB@meinberg.de>
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/TGySJV7sodJ3VJXcrPv8Ciums8c>
Subject: [Ntp] Antw: Re: NTS IANA request
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: Tue, 11 Jun 2019 06:25:35 -0000
Hi! Actually I think traffic limiting rather than traffic blocking would have been the more correct approach against amplification attacks. Anf of course a more specific blocking rule than just blocking 123/UDP completely. Regards, Ulrich >>> Heiko Gerstung <heiko.gerstung@meinberg.de> schrieb am 07.06.2019 um 09:40 in Nachricht <487FBFAD-D082-4CA8-AC14-C2CC8B007DBB@meinberg.de>: > I initially wanted to have an IANA assigned port for NTP-over-NTS to make it > easier for users to manage their firewall settings. As we know, quite a > number of ISPs and corporate firewall admins created these size-limiting > rules in the wake of the amplification attacks carried out via the monlist > feature a while ago. Now, I do not see the problem that an IANA assigned well > known port will be hit by the same firewall rules, as for the ISPs it > requires most probably to create a new firewall rule (and do not put > stringent packet size limits in it), if they set up a rule at all. > > In order to simplify firewall handling for corporate users/non-ISPs, I would > recommend the well known port but obviously the NTS-KE mechanism to advertise > a different port is still a good option in case some people prefer that. > > My suggestions: register a port (it does not really have to be a system port > IMHO), use that as a default for the NTS-KE port advertising and allow users > to change it. This way, someone can even use 123/udp again if they see fit. > > Regards, > Heiko > > > > -- > Heiko Gerstung > Managing Director > > MEINBERG® Funkuhren GmbH & Co. KG > Lange Wand 9 > D-31812 Bad Pyrmont, Germany > Phone: +49 (0)5281 9309-404 > Fax: +49 (0)5281 9309-9404 > > Amtsgericht Hannover 17HRA 100322 > Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre > Hartmann, Heiko Gerstung > > Email: > heiko.gerstung@meinberg.de > Web: > Deutsch https://www.meinberg.de > English https://www.meinbergglobal.com > > Do not miss our Time Synchronization Blog: > https://blog.meinbergglobal.com > > Connect via LinkedIn: > https://www.linkedin.com/in/heikogerstung > > > > On 06.06.19, 20:29 "ntp im Auftrag von Daniel Franke" <ntp-bounces@ietf.org > im Auftrag von dfoxfranke@gmail.com> wrote: > > As a slight tangent, we never concluded the discussion as to what > we're going to do about the fact that so many ISPs are dropping > 123/udp traffic with payloads larger than 48 bytes. I think we got as > far as concluding: > > 1. We're never going to persuade enough ISPs to change their policy, > making 123/udp basically doomed. > 2. NTS-KE's port negotiation record gives us all the mechanism we need > in order to run NTP-with-NTS over an alternate port. > > But that left an unresolved question: do we allocate a fixed alternate > UDP port, or should servers ask the OS for a dynamic port and then use > NTS-KE to advertise whatever the OS assigns to them? Both choices have > firewall-related drawbacks. If we use a fixed port, we risk landing > ourselves right back in the same situation we're in today with 123. At > minimum, to protect ourselves from this, the NTF would have to commit > to adding some code to ntpd such that it will refuse to ever send mode > 6 or 7 responses over the new port no matter what configuration the > user gives it. (Yes, mode 6 too, because mode 6 still amplifies, just > not as severely as mode 7 does). If we use a dynamic port, then it > becomes much harder for ISPs to block us, but it also becomes harder > for corporate firewalls with a default-deny-all policy to let us > through. > > On Thu, Jun 6, 2019 at 1:06 PM Salz, Rich <rsalz@akamai.com> wrote: > > > > > I'm strongly opposed to modifying NTS-KE to involve sending a > STARTTLS > > as a first step of the handshake. I don't want to make a breaking > > change to a protocol that's passed WGLC and has four interoperating > > implementations in order to accommodate a protocol that has never > been > > implemented and whose specification consists of three vague > sentences > > in an unadopted and expired I-D. > > > > I wasn't strongly advocating either mechanism, just trying to explain > how things could share a port if that's what we wanted to do. > > > > For the record, since I see no definition of NTP/TLS, I am in favor of > assigning 123/TCP to NTS. > > > > > > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp > > > > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp
- [Ntp] NTS IANA request Watson Ladd
- Re: [Ntp] NTS IANA request Harlan Stenn
- Re: [Ntp] NTS IANA request Daniel Franke
- Re: [Ntp] NTS IANA request Gary E. Miller
- Re: [Ntp] NTS IANA request Daniel Franke
- Re: [Ntp] NTS IANA request Hal Murray
- Re: [Ntp] NTS IANA request Heiko Gerstung
- Re: [Ntp] NTS IANA request Miroslav Lichvar
- Re: [Ntp] NTS IANA request Salz, Rich
- Re: [Ntp] NTS IANA request Salz, Rich
- Re: [Ntp] NTS IANA request Daniel Franke
- Re: [Ntp] NTS IANA request Daniel Franke
- Re: [Ntp] NTS IANA request Salz, Rich
- Re: [Ntp] NTS IANA request Daniel Franke
- Re: [Ntp] NTS IANA request Harlan Stenn
- Re: [Ntp] NTS IANA request Harlan Stenn
- Re: [Ntp] NTS IANA request kodonog@pobox.com
- Re: [Ntp] NTS IANA request kodonog@pobox.com
- Re: [Ntp] NTS IANA request Heiko Gerstung
- Re: [Ntp] NTS IANA request Hal Murray
- Re: [Ntp] NTS IANA request Danny Mayer
- Re: [Ntp] NTS IANA request Warner Losh
- Re: [Ntp] NTS IANA request Daniel Franke
- Re: [Ntp] NTS IANA request Watson Ladd
- Re: [Ntp] NTS IANA request Majdi S. Abbas
- Re: [Ntp] NTS IANA request Daniel Franke
- Re: [Ntp] NTS IANA request Majdi S. Abbas
- Re: [Ntp] NTS IANA request Watson Ladd
- Re: [Ntp] NTS IANA request Harlan Stenn
- Re: [Ntp] NTS IANA request Watson Ladd
- Re: [Ntp] NTS IANA request tglassey@earthlink.net
- Re: [Ntp] NTS IANA request tglassey@earthlink.net
- Re: [Ntp] NTS IANA request tglassey@earthlink.net
- [Ntp] Antw: Re: NTS IANA request Ulrich Windl