Re: [Ntp] [EXT] Re: NTPv5 KISS code support
Miroslav Lichvar <mlichvar@redhat.com> Wed, 08 November 2023 07:15 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 3389FC16F3F3 for <ntp@ietfa.amsl.com>; Tue, 7 Nov 2023 23:15:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwpdNbpOPHBU for <ntp@ietfa.amsl.com>; Tue, 7 Nov 2023 23:15:25 -0800 (PST)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C60FC151981 for <ntp@ietf.org>; Tue, 7 Nov 2023 23:15:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1699427723; 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=f7lOcTs/7Q6TGfhF824+NKfj4h5HHGE+9Me2xX//JW0=; b=VeL7U2pcCLgnIElGmg4bNW39ZvMANuEBCEx5mm83CwT3VPBbcsKr18W3Ii/pXK3f7BO4lh Jj5bC8oh0DhMoIqAlIpZwG+2rw5z4WhsQEBmGFTBTMnOf/Bs6oROaB8uL44oA7vWcmdQ6p vE/yR7EKNUHIFVIvgv7hEYvIUY1LYFs=
Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-650-KueWgMnJPJiZk_xuOcElow-1; Wed, 08 Nov 2023 02:15:19 -0500
X-MC-Unique: KueWgMnJPJiZk_xuOcElow-1
Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 6FEC62823803; Wed, 8 Nov 2023 07:15:19 +0000 (UTC)
Received: from localhost (unknown [10.43.135.229]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EEAF3492BFA; Wed, 8 Nov 2023 07:15:18 +0000 (UTC)
Date: Wed, 08 Nov 2023 08:15:17 +0100
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Hal Murray <halmurray+ietf@sonic.net>
Cc: NTP WG <ntp@ietf.org>
Message-ID: <ZUs1hQvWMeEm9nby@localhost>
References: <mlichvar@redhat.com> <ZUX/VmCu/3Qoy5av@localhost> <20231107200226.E1C1E28C20C@107-137-68-211.lightspeed.sntcca.sbcglobal.net>
MIME-Version: 1.0
In-Reply-To: <20231107200226.E1C1E28C20C@107-137-68-211.lightspeed.sntcca.sbcglobal.net>
X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.10
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/vz-YODRmH4wV262DcwKLahgDJyE>
Subject: Re: [Ntp] [EXT] Re: NTPv5 KISS code support
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 08 Nov 2023 07:15:29 -0000
On Tue, Nov 07, 2023 at 12:02:26PM -0800, Hal Murray wrote: > Suppose the bad guys are trying to DoS somebody by sending enough forged > requests to trigger rate limiting. > > How did the bad guy figure out which servers the victim is using? Can we > fight that by using a few more? The typical default configuration uses pool.ntp.org. There are only few thousand servers in the pool. The attacker can simply keep sending requests with spoofed source address to all of them. One per second per server, that's no big deal. > Will responding to some requests be good enough? > What fraction of requests need to get answered for NTP to "work"? In my tests responding to 25% of requests seems to be sufficient for clients like ntpd to keep the clock synchronized, although not very well. > Do the numbers work? If the bad guy sends 1 packet per second and the victim > sends 1 packet every 64 seconds and the server responds to 1 packet per > second, the victim gets 1/2 or 1/65 depending on implementation details. The > bad guy can reduce the odds by sending faster. This is an arms race. The server needs to respond to some constant percentage of the requests and select them randomly. The attacker would need to send requests at a much higher rate in order to overload the network or the server to actually reduce the rate of responses that the victim gets. Doing that for a larger number of servers like pool.ntp.org would be impractical. > I think we can fix this by adding an option to NTS to include the client's IP > Address in the cookie. That would let the server split rate limiting into 2 > piles, one for requests with a verified source, and the other for everybody > else. Yes, that would help. The drawback is that the clients would need to restart NTS-KE after moving to a different network. > Note that if an NTS client misses 8 responses in a row and doesn't reuse > cookies, then the NTS-KE server will get increased traffic. Right. NTS-KE can be rate limited too if necessary. -- Miroslav Lichvar
- [Ntp] NTPv5 KISS code support David Venhoek
- Re: [Ntp] [EXT] Re: NTPv5 KISS code support Miroslav Lichvar
- Re: [Ntp] [EXT] Re: NTPv5 KISS code support Hal Murray
- Re: [Ntp] [EXT] Re: NTPv5 KISS code support Miroslav Lichvar
- Re: [Ntp] NTPv5 KISS code support Miroslav Lichvar
- Re: [Ntp] [EXT] Re: NTPv5 KISS code support Windl, Ulrich
- Re: [Ntp] [EXT] KISS => NAT => Rate limiting Windl, Ulrich
- Re: [Ntp] [EXT] Re: NTPv5 KISS code support Daniel Franke
- Re: [Ntp] [EXT] Re: NTPv5 KISS code support Hal Murray
- Re: [Ntp] [EXT] Re: NTPv5 KISS code support Ira McDonald
- Re: [Ntp] [EXT] Re: NTPv5 KISS code support Miroslav Lichvar
- Re: [Ntp] [EXT] Re: NTPv5 KISS code support David Venhoek
- Re: [Ntp] [EXT] Re: NTPv5 KISS code support Hal Murray
- [Ntp] KISS => NAT => Rate limiting Hal Murray
- Re: [Ntp] [EXT] Re: NTPv5 KISS code support Daniel Franke
- Re: [Ntp] [EXT] Re: NTPv5 KISS code support David Venhoek
- [Ntp] Rate limiting/reflection prevention (Was: N… David Venhoek
- Re: [Ntp] [EXT] Re: NTPv5 KISS code support Hal Murray
- Re: [Ntp] [EXT] Re: NTPv5 KISS code support Miroslav Lichvar
- Re: [Ntp] [EXT] Re: NTPv5 KISS code support Danny Mayer
- Re: [Ntp] [EXT] Re: NTPv5 KISS code support Salz, Rich
- Re: [Ntp] [EXT] Re: NTPv5 KISS code support Hal Murray
- Re: [Ntp] [EXT] Re: NTPv5 KISS code support Danny Mayer
- Re: [Ntp] [EXT] Re: Re: NTPv5 KISS code support Windl, Ulrich
- Re: [Ntp] [EXT] Re: Re: NTPv5 KISS code support Danny Mayer
- Re: [Ntp] [EXT] Re: NTPv5 KISS code support Hal Murray
- Re: [Ntp] [EXT] Re: NTPv5 KISS code support Forrest Christian (List Account)