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

I agree with Miroslav: KISS codes as they exist today are broken to
the point of uselessness as a rate-limiting tool. In my early NTPv5
sketch, I replaced them with a couple of fields in the base packet
which allow the server to inform clients of limits on how often it
wants to be polled, with one field for maximum sustained rate and
another for maximum burst rate. Compliance is still voluntary, but it
avoids any need for state-keeping on the server side because it just
sends the same information to everyone.

On Fri, Nov 3, 2023 at 2:47 AM Windl, Ulrich <u.windl@ukr.de> wrote:
>
> Hi!
>
> So you are saying the KoD (Kiss of Death) as it is specified now is broken by design?
> I see two possibilities:
> 1) Drop the concept for NTPv5
> 2) Improve the concept for NTPv5
> Basically I think KoD is a good idea to inform the client about an issue the server sees, be it technical or political (policy).
>
> Kind Regards,
> Ulrich Windl
>
> -----Original Message-----
> From: ntp <ntp-bounces@ietf.org> On Behalf Of Miroslav Lichvar
> Sent: Thursday, November 2, 2023 10:11 AM
> To: David Venhoek <david@venhoek.nl>
> Cc: NTP WG <ntp@ietf.org>
> Subject: [EXT] Re: [Ntp] NTPv5 KISS code support
>
> On Wed, Nov 01, 2023 at 03:37:44PM +0100, David Venhoek wrote:
> > Hi All,
> >
> > I have made a pull request with suggested wording for including kiss
> > code support in ntpv5. The PR can be found
> > athttps://github.com/mlichvar/draft-ntp-ntpv5/pull/9, the suggested
> > patch is also included below for completeness. Please do share any
> > feedback regarding the chosen design, this looked good to me but there
> > may be better approaches.
>
> This looks similar to the description of DENY, RSTR, RATE codes in RFC
> 5905.
>
> One problem is that it's a security issue, a denial of service for the
> client. A single spoofed response shouldn't be able to completely break
> synchronization with a server. There needs to be some maximum poll
> value specificied for RATE and some interval specified for RSTR and
> DENY. With that, I would ask how is it better than what we already
> have with the suggested poll interval returned in a normal server
> response.
>
> The other issue is the most buggy clients that would need this
> handling are least likely to implement it, at least that's what
> we have seen with (S)NTPv4 implementations. With the most severe bugs
> that lead to flooding of servers (e.g. in systemd-timesyncd and
> Fortigate firewalls for example), handling of these codes wouldn't
> make a difference anyway. By the time the client receives a response
> from the server, it has already sent another request, so it couldn't
> accept it as valid even if it had this functionality implemented.
>
> --
> Miroslav Lichvar
>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp