IETF Logo Mail Archive

Re: [Ntp] [EXT] Re: NTPv5 KISS code support

Hal Murray <halmurray+ietf@sonic.net> Fri, 03 November 2023 14:47 UTC

Return-Path: <halmurray+ietf@sonic.net>
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 E8924C17C539 for <ntp@ietfa.amsl.com>; Fri, 3 Nov 2023 07:47:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.908
X-Spam-Level:
X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_B=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 d1p48XS3E8qC for <ntp@ietfa.amsl.com>; Fri, 3 Nov 2023 07:47:24 -0700 (PDT)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6484AC17C535 for <ntp@ietf.org>; Fri, 3 Nov 2023 07:47:24 -0700 (PDT)
Received: from 107-137-68-211.lightspeed.sntcca.sbcglobal.net (104-182-38-69.lightspeed.sntcca.sbcglobal.net [104.182.38.69]) (authenticated bits=0) by c.mail.sonic.net (8.16.1/8.16.1) with ESMTPSA id 3A3ElMAw032158 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 3 Nov 2023 07:47:22 -0700
Received: from hgm (localhost [IPv6:::1]) by 107-137-68-211.lightspeed.sntcca.sbcglobal.net (Postfix) with ESMTP id 40CB928C239; Fri, 3 Nov 2023 07:47:22 -0700 (PDT)
X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8
To: NTP WG <ntp@ietf.org>
cc: Hal Murray <halmurray+ietf@sonic.net>
From: Hal Murray <halmurray+ietf@sonic.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 03 Nov 2023 07:47:22 -0700
Message-Id: <20231103144722.40CB928C239@107-137-68-211.lightspeed.sntcca.sbcglobal.net>
X-Sonic-CAuth: UmFuZG9tSVYOyDXK+/ZNGQHMjhWZlNUh5TexMcH8p1GosYC8BMLlMzI4n5qArbqiKP/d7K+qRXfa/5lbgQ/YePRnb3qACxj6XAASnTYibwU=
X-Sonic-ID: C;7OSB5Vd67hGUni5nR+6Zsg== M;OGKV5Vd67hGUni5nR+6Zsg==
X-Sonic-Spam-Details: -1.5/5.0 by cerberusd
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/NCPqxwS38SWeaJHG-4ZCiOovgh0>
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: Fri, 03 Nov 2023 14:47:25 -0000

Ira McDonald  said:
> +1 to Daniel's comments.  Stateful, Client-by-Client rate limiting is a black
> hole of potential software faults.  Let the Server tell the same thing to
> every Client. 

There are 2 cases.

The first is good guys.  Daniel's proposal is fine.  The question is do we 
need it?  Is it worth the space in the packet, the bits on the wire?  It only 
takes a byte or two, but is there any problem with good guys?

The second case is bad guys or broken software.  Broken software isn't going 
to pay any attention to anything.  Bad guys can use UDP with a forged source 
address to DoS a victim.

We have decided not to allow amplification.  Do we need rate limiting too?

-- 
These are my opinions.  I hate spam.

v2.29.0 | Report a Bug | By Email | System Status