Rude rackety customers - NTP

This is a discussion on Rude rackety customers - NTP ; Guys, FYI: In reworking the NTP server flood defenses to more accurately spot the cloggers, I found one perp sending contiuously at 3 s, another at 5 s and a third at 8 s. This results in sending one KoD ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Rude rackety customers

  1. Rude rackety customers

    Guys,

    FYI: In reworking the NTP server flood defenses to more accurately spot
    the cloggers, I found one perp sending contiuously at 3 s, another at 5
    s and a third at 8 s. This results in sending one KoD every two seconds.
    The KoD has been modified to avoid revealing any server timestamps, so
    are useless for time purposes.

    The changes allow increasing the minimum server average headway to one
    packet in 16 s for every client, which is the rate enforced by the
    current NTP client. If the client gets a valid KoD, it stops working.

    Whether this really does work depends on the deployment of the current
    design in the wider user population. A tarball with this stuff should
    roll soon.

    Dave

  2. Re: Rude rackety customers

    On Nov 26, 2:14 pm, "David L. Mills" wrote:
    > Guys,
    >
    > FYI: In reworking the NTP server flood defenses to more accurately spot
    > the cloggers, I found one perp sending contiuously at 3 s, another at 5
    > s and a third at 8 s. This results in sending one KoD every two seconds.
    > The KoD has been modified to avoid revealing any server timestamps, so
    > are useless for time purposes.
    >
    > The changes allow increasing the minimum server average headway to one
    > packet in 16 s for every client, which is the rate enforced by the
    > current NTP client. If the client gets a valid KoD, it stops working.
    >
    > Whether this really does work depends on the deployment of the current
    > design in the wider user population. A tarball with this stuff should
    > roll soon.


    FWIW - pool server operators have anecdotes of not sending replies
    making the bad clients worse and making them go away. There are also
    anecdotes of sending replies making the bad clients "better" and of
    sending replies making them worse.

    The consistent anecdotes regarding KoD replies is that it doesn't
    help.

    Having a server in the pool can be a good way to get a bunch of
    "random clients" connecting and still be able to turn off the server
    again after some time.

    - ask

  3. Re: Rude rackety customers

    ask wrote:
    > On Nov 26, 2:14 pm, "David L. Mills" wrote:
    >> Guys,
    >>
    >> FYI: In reworking the NTP server flood defenses to more accurately spot
    >> the cloggers, I found one perp sending contiuously at 3 s, another at 5
    >> s and a third at 8 s. This results in sending one KoD every two seconds.
    >> The KoD has been modified to avoid revealing any server timestamps, so
    >> are useless for time purposes.
    >>
    >> The changes allow increasing the minimum server average headway to one
    >> packet in 16 s for every client, which is the rate enforced by the
    >> current NTP client. If the client gets a valid KoD, it stops working.
    >>
    >> Whether this really does work depends on the deployment of the current
    >> design in the wider user population. A tarball with this stuff should
    >> roll soon.

    >
    > FWIW - pool server operators have anecdotes of not sending replies
    > making the bad clients worse and making them go away. There are also
    > anecdotes of sending replies making the bad clients "better" and of
    > sending replies making them worse.


    Yes, that was CSIRO's experience too as well as someone else's server
    who's name I don't remember.

    > The consistent anecdotes regarding KoD replies is that it doesn't
    > help.
    >


    If the client is doing the correct basic calculation then the newest
    code on the server will cause those errant clients receiving KoD's to
    move away, faster if they try a lot.

    > Having a server in the pool can be a good way to get a bunch of
    > "random clients" connecting and still be able to turn off the server
    > again after some time.


    I'm in the process of getting started my project to implement DNS
    retries by the NTP client which should stop it if the server is not
    responding and look for another one. This will help the pool as a
    beneficial byproduct but only if the client is using the NTP reference
    implementation or a derivative thereof.

    The hard part has been finding the time to get this done and I'm only in
    the initial design phase.

    Danny

    > - ask


+ Reply to Thread