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

Hi,

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

Cheers,
- Ira

*Ira McDonald (Musician / Software Architect)*

*Chair - SAE Trust Anchors and Authentication TF*
*Co-Chair - TCG Trusted Mobility Solutions WG*

*Co-Chair - TCG Metadata Access Protocol SG*

*Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer
Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF
Designated Expert - IPP & Printer MIBBlue Roof Music / High North
Inchttp://sites.google.com/site/blueroofmusic
<http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/highnorthinc
<http://sites.google.com/site/highnorthinc>mailto: blueroofmusic@gmail.com
<blueroofmusic@gmail.com>(permanent) PO Box 221  Grand Marais, MI 49839
906-494-2434*

On Fri, Nov 3, 2023 at 8:23 AM Daniel Franke <dfoxfranke@gmail.com> wrote:

> 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
>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
>