Re: [Ntp] Antw: Re: Antw: [EXT] Re: WGLC on draft‑ietf‑alternative‑port‑01
Miroslav Lichvar <mlichvar@redhat.com> Thu, 05 August 2021 06:53 UTC
Return-Path: <mlichvar@redhat.com>
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 2DC743A1150 for <ntp@ietfa.amsl.com>; Wed, 4 Aug 2021 23:53:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com
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 4HYC8ps81E7i for <ntp@ietfa.amsl.com>; Wed, 4 Aug 2021 23:53:37 -0700 (PDT)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 56BF63A1151 for <ntp@ietf.org>; Wed, 4 Aug 2021 23:53:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1628146415; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=XBtsfN3Fg+dVjHFRjPJLlFPlmgZ3lfPka7rLYbOs45U=; b=YDAjDuJ645FL+o2w+xg3KZRpAs/tlP7rpiBLRG27BT6dzJJiGVKAGCr4GEJq4oHcwzB6la 9YZnaDbECo+f4/YJYRnerCkkyic1hEoUh5+LSfZZP4mN4cW7Rpiwh0pS5TBciZ53PKVLOC s5DYADZ2fwwQBmyTcA7GlnFaRPnLBMM=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-298-95Vw0PqnNKCIdQBu0v7rWA-1; Thu, 05 Aug 2021 02:53:32 -0400
X-MC-Unique: 95Vw0PqnNKCIdQBu0v7rWA-1
Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3C98E87122E; Thu, 5 Aug 2021 06:53:31 +0000 (UTC)
Received: from localhost (holly.tpb.lab.eng.brq.redhat.com [10.43.134.11]) by smtp.corp.redhat.com (Postfix) with ESMTPS id F1EAB27CA1; Thu, 5 Aug 2021 06:53:27 +0000 (UTC)
Date: Thu, 05 Aug 2021 08:53:26 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Harlan Stenn <stenn@nwtime.org>
Cc: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>, "ntp@ietf.org" <ntp@ietf.org>, halmurray+ietf@sonic.net
Message-ID: <YQuK5gqaxay/xR93@localhost>
References: <9C21DF1F020000EB6A6A8CFC@gwsmtp.uni-regensburg.de> <D9104F8D020000FEAB59E961@gwsmtp.uni-regensburg.de> <610253DA020000A100042C8B@gwsmtp.uni-regensburg.de> <61025C79020000A100042C9B@gwsmtp.uni-regensburg.de> <2FCD5C39020000B9AB59E961@gwsmtp.uni-regensburg.de> <1E89B79A020000F55AEBDC6A@gwsmtp.uni-regensburg.de> <32C7A15902000060FDA5B133@gwsmtp.uni-regensburg.de> <61078A68020000A100042DD7@gwsmtp.uni-regensburg.de> <YQegwC/8qioEWJ/P@localhost> <c8e4130c-cd44-e426-4346-31ffb879e289@nwtime.org>
MIME-Version: 1.0
In-Reply-To: <c8e4130c-cd44-e426-4346-31ffb879e289@nwtime.org>
X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23
Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=mlichvar@redhat.com
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/PLJafltxJOkS659MgzaLGMVkQJw>
Subject: Re: [Ntp] Antw: Re: Antw: [EXT] Re: WGLC on draft‑ietf‑alternative‑port‑01
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Time Protocol <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: Thu, 05 Aug 2021 06:53:42 -0000
On Wed, Aug 04, 2021 at 12:46:21AM -0700, Harlan Stenn wrote: > On 8/2/2021 12:37 AM, Miroslav Lichvar wrote: > > On Mon, Aug 02, 2021 at 08:02:16AM +0200, Ulrich Windl wrote: > >> I just wonder: Wouldn't rate limiting (or bandwidth limiting) be the correct > >> way to do? > > > > I think that's what they currently do. It effectively causes a DoS on > > NTP. > > I don't understand exactly what you mean here by "causes a DoS on NTP." > Clarify, please? Rate limiting of NTP packets can cause a denial of the NTP service for legitimate clients. They don't get a response to their requests and cannot synchronize their clock. It doesn't matter if the rate limiting is happening on the server or some middlebox in the network. > > See the discussions at community.ntppool.org. Large numbers of > > servers are randomly rejected from the pool due to heavy packet loss > > specific to port 123 on the path to the monitoring system. > > If the target system is receiving too many packets and is dropping them > already the monitoring system needs to know this, and rank the target > accordingly. It's not the server dropping packets. It's major ISPs specifically rate limiting packets on the UDP port 123. If you run mtr in the UDP mode on that port, you will see a huge packet loss on the boundary of their network. If you change the port number, the loss immediately disappears. It's not a congested network or overloaded server. We can speculate if this would have happened if ntpd promptly fixed the mode 6 to not amplify traffic, or at least changed the defaults to not allow remote access. We probably won't ever know. The damage is done. The port is no longer usable on the global scale. We need to move to a different port and restrict it to the non-amplifying subset of the protocol, so this doesn't happen again. That's what this draft is trying to do. -- Miroslav Lichvar
- [Ntp] WGLC on draft-ietf-alternative-port-01 Karen O'Donoghue
- Re: [Ntp] WGLC on draft-ietf-alternative-port-01 Miroslav Lichvar
- Re: [Ntp] WGLC on draft-ietf-alternative-port-01 Watson Ladd
- Re: [Ntp] WGLC on draft-ietf-alternative-port-01 Danny Mayer
- Re: [Ntp] WGLC on draft-ietf-alternative-port-01 Erik Kline
- Re: [Ntp] WGLC on draft-ietf-alternative-port-01 Dieter Sibold
- Re: [Ntp] WGLC on draft-ietf-alternative-port-01 Dieter Sibold
- Re: [Ntp] WGLC on draft-ietf-alternative-port-01 Danny Mayer
- Re: [Ntp] WGLC on draft-ietf-alternative-port-01 Miroslav Lichvar
- [Ntp] Antw: [EXT] Re: WGLC on draft‑ietf‑alternat… Ulrich Windl
- Re: [Ntp] Antw: [EXT] Re: WGLC on draft‑ietf‑alte… Miroslav Lichvar
- Re: [Ntp] WGLC on draft-ietf-alternative-port-01 Watson Ladd
- [Ntp] Antw: [EXT] Re: WGLC on draft‑ietf‑alternat… Ulrich Windl
- [Ntp] Antw: Antw: [EXT] Re: WGLC on draft‑ietf‑al… Ulrich Windl
- Re: [Ntp] Antw: [EXT] Re: WGLC on draft‑ietf‑alte… Danny Mayer
- Re: [Ntp] Antw: [EXT] Re: WGLC on draft‑ietf‑alte… Watson Ladd
- Re: [Ntp] Antw: [EXT] Re: WGLC on draft‑ietf‑alte… Danny Mayer
- Re: [Ntp] Antw: [EXT] Re: WGLC on draft‑ietf‑alte… Hal Murray
- Re: [Ntp] Antw: [EXT] Re: WGLC on draft‑ietf‑alte… Watson Ladd
- Re: [Ntp] Antw: [EXT] Re: WGLC on draft‑ietf‑alte… Danny Mayer
- [Ntp] Antw: Re: Antw: [EXT] Re: WGLC on draft‑iet… Ulrich Windl
- Re: [Ntp] Antw: Re: Antw: [EXT] Re: WGLC on draft… Miroslav Lichvar
- Re: [Ntp] Antw: Re: Antw: [EXT] Re: WGLC on draft… Harlan Stenn
- Re: [Ntp] Antw: Re: Antw: [EXT] Re: WGLC on draft… Miroslav Lichvar
- Re: [Ntp] Antw: Re: Antw: [EXT] Re: WGLC on draft… Doug Arnold