[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