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

Returning to the original question, I still have a number of
situations where I would really like to be able to send some type of
explicit feedback to the client on an error/undesirable situation.
Avoiding the specific deny/rstr/rate discussion, do we want the
specific mechanism for such status messages I suggested above. If not,
then how do we respond when:
 - Cryptographic failure for NTS
 - Cryptographic failure for MAC
 - A client is not being allowed to use a server
For ease of debugging, I want to be able to give at least some reply
so the client can see that it is at least talking to an NTP server in
these situations. Also, I feel that on cryptographically secured
connections a deny-like construct can also be a really good way of
quickly moving clients away from a decommissioning server.


On Wed, Nov 8, 2023 at 2:45 PM Daniel Franke <dfoxfranke@gmail.com> wrote:
>
> Seconding Miroslav, reflectors per se aren't a security problem; they become one if and only if they amplify traffic. Every host on the Internet that has a TCP stack, open ports or no, is already a non-amplifying reflector and nobody thinks this is a problem.
>
> On Wed, Nov 8, 2023, 03:51 Miroslav Lichvar <mlichvar@redhat.com> wrote:
>>
>> On Wed, Nov 08, 2023 at 12:44:34AM -0800, Hal Murray wrote:
>> > > 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.
>>
>> A very poor reflector. The attacker can send the packets directly to
>> the target to avoid losing 75% of the traffic.
>>
>> > The bad guy will just have to find 3 other servers to get the
>> > same amount of traffic through.
>>
>> That doesn't change anything if they reflect only 25% of traffic.
>>
>> --
>> 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