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