IETF Logo Mail Archive

Re: [Ntp] Antw: Re: Antw: [EXT] Re: WGLC on draft‑ietf‑alternative‑port‑01

Miroslav Lichvar <mlichvar@redhat.com> Mon, 02 August 2021 07:37 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 BF4893A1162 for <ntp@ietfa.amsl.com>; Mon, 2 Aug 2021 00:37:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Level:
X-Spam-Status: No, score=-2.549 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 U2zAK6OdpuwE for <ntp@ietfa.amsl.com>; Mon, 2 Aug 2021 00:37:45 -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 560C43A1161 for <ntp@ietf.org>; Mon, 2 Aug 2021 00:37:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1627889864; 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=gvCFBCPUdjaGptcxV5r19AEXEa8xvja1LGCz7JchqIo=; b=Ww3pvG/frehs+riAyKzRtWueZtKTvYZiyNpZ6UYLM7fLI8j2Z4NydAoZhgh9WEiPxUUxW6 UEqJGxNOIz9dtnOGIehwiPGdpYPSVgfkCFlA4HZa1PmwqJZOm6/LOoIxQ/kSSvalhqyEnB wPZBJolvnrYF96fo40YmD0SGVIx1h1c=
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-94-BaQjIpmVPPmHcL3hfuDsYw-1; Mon, 02 Aug 2021 03:37:40 -0400
X-MC-Unique: BaQjIpmVPPmHcL3hfuDsYw-1
Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B16A3801AE7; Mon, 2 Aug 2021 07:37:39 +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 0A0F61036D05; Mon, 2 Aug 2021 07:37:37 +0000 (UTC)
Date: Mon, 02 Aug 2021 09:37:36 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
Cc: halmurray+ietf@sonic.net, "ntp@ietf.org" <ntp@ietf.org>
Message-ID: <YQegwC/8qioEWJ/P@localhost>
References: <FAD1C7620200006F824A10E1@gwsmtp.uni-regensburg.de> <31FF6970020000285AEBDC6A@gwsmtp.uni-regensburg.de> <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>
MIME-Version: 1.0
In-Reply-To: <61078A68020000A100042DD7@gwsmtp.uni-regensburg.de>
X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22
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/IO6S6m1wXoQsct40sdIkfqYmkSk>
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: Mon, 02 Aug 2021 07:37:50 -0000

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. 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.

> I don't consider the smart solution to be smart actually.
> Maybe even considering the input/output (request/response) ratio would be even
> better.

That would require tracking each address separately. Good luck doing
that at the network speeds the ISPs work with.

A more practical solution would be to specifically drop only NTP mode
6/7 packets, but even this functionality is missing in (most of?) the
hardware.

-- 
Miroslav Lichvar

v2.23.0 | Report a Bug | By Email