[Ntp] Rate limiting/reflection prevention (Was: NTPv5 KISS code support)

[David Venhoek <[e-mail]>]

Added a number of specific comments below, but I do also want to put
up for discussion whether we should even care about the reflection
potential of NTP. The reason I think of this as being a reasonable
question is that it does seem that a lot of other protocols (QUIC, TCP
to name just a few) seem rather unconcerned by this. More
fundamentally, the potential for reflection seems very much inherent
to the design of the internet, and I think that if we really see this
as a massive problem it should be solved in the routing layers.

Note that the above is specifically about reflection (e.g.
bytes/packets in to bytes/packets out ratio is 1). Amplification of
course is and should remain a point of attention.

On Wed, Nov 8, 2023 at 9:44 AM Hal Murray <[e-mail]> wrote:
>
>
> Thanks.
>
> > 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.
>
> > 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.
>
> If we let 25% of the bad traffic through, we have opened up the server for use
> as a reflector.  The bad guy will just have to find 3 other servers to get the
> same amount of traffic through.

I think you are missing an important detail, which is that an attacker
not just needs to find 3 other servers for the same amount of traffic,
but also needs to send 4x as much traffic from the actual attacking
machines.

>
>
> [putting IP Address into cookie]
> > Yes, that would help. The drawback is that the clients would need to restart
> > NTS-KE after moving to a different network.

One of the approaches here I have been toying around with (though
without running code yet) is to not include an ip address in the
cookies, but rather a non-adress-related id. This allows throttling of
problematic traffic without affecting well-behaving nts users
(although that does break down once an attacker starts many nts-ke
sessions, though you could try to rate limit that perhaps).

We should I think be careful with putting ip addresses in the cookies.
Given modern network topologies where quite a few devices may have
multiple routes to the internet and multiple ip addresses to match,
their NTS-KE traffic could just go out on a different interface than
the ntp udp packets, which would break if you start including ips in
cookies.

Though honestly, I think we should keep most of this as implementation
details of servers, giving perhaps guidance to implementers, but I
don't think we should give strict requirements on this.

>
> Maybe that's the price we will have to pay for not letting NTP servers be used
> as reflectors.
>
> Servers and workstations/PCs don't change IP Addresses very frequently.
>
> For laptops, we could reduce the load by making the client store sets of
> cookies per IP Address.  That would cover the common case of a laptop that
> migrates from home to work each day.  I don't know enough about typical use
> cases for portable systems to go much farther than that.
>
> The client could run in no-check-address mode until they lost a string of
> packets, aka appeared to be under attack, then switch to check-address mode.
>
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp