Kiss-O'-Death - NTP

This is a discussion on Kiss-O'-Death - NTP ; How exactly do you configure NTP to send a KOD? I'm running Meinberg's port under Win XP. I'm a sever in the pool. I've got two remote clients that are querying at a rate of several times a minute. Sometimes ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: Kiss-O'-Death

  1. Kiss-O'-Death

    How exactly do you configure NTP to send a KOD? I'm running Meinberg's port
    under Win XP. I'm a sever in the pool. I've got two remote clients that are
    querying at a rate of several times a minute. Sometimes their queries are
    spaced wider, but sometimes they hit me spaced at only a few seconds apart.
    I can block them in my router, but they'd still be sending traffic my way.
    I'd like to see if KOD makes them go away. Reading the docs, it appears
    that I need to mod ntp.conf and add restrict x.x.x.x kod, but then I'd need
    to restart the service.

    Thanks for any help.



  2. Re: Kiss-O'-Death

    On 2008-06-25, Bob wrote:
    > How exactly do you configure NTP to send a KOD?


    1. Add the appropriate restrict line to ntp.conf; do this even if you
    don't restart ntpd so that the restriction will survive future restarts.

    2. Either:

    a. restart ntpd

    b. use ntpdc to add the restriction

    To use ntpdc to make on the fly configuration changes you have to either
    (a) set up symmetric keys or (b) disable authentication.

    Then you can:

    $ ntpdc your_server
    ntpdc> keyid N
    ntpdc> passwd
    MD5 Password: *****
    ntpdc> restrict bad.ip.address 255.255.255.255 kod
    done!

    > I'm a se[r]ver in the pool. I've got two remote clients that are
    > querying at a rate of several times a minute. Sometimes their queries
    > are spaced wider, but sometimes they hit me spaced at only a few
    > seconds apart. I can block them in my router, but they'd still be
    > sending traffic my way. I'd like to see if KOD makes them go away.
    > Reading the docs, it appears that I need to mod ntp.conf and add
    > restrict x.x.x.x kod, but then I'd need to restart the service.


    A warm restart of a properly configured ntpd interrupts service for less
    than 30 seconds. That's hardly a show-stopper for a best-effort service
    such as a pool server.

    A properly configured ntpd uses 'iburst' on the server lines and has a
    valid drift file.

    --
    Steve Kostecke
    NTP Public Services Project - http://support.ntp.org/

  3. Re: Kiss-O'-Death

    Bob wrote:
    > How exactly do you configure NTP to send a KOD? I'm running Meinberg's port
    > under Win XP. I'm a sever in the pool. I've got two remote clients that are
    > querying at a rate of several times a minute. Sometimes their queries are
    > spaced wider, but sometimes they hit me spaced at only a few seconds apart.
    > I can block them in my router, but they'd still be sending traffic my way.
    > I'd like to see if KOD makes them go away. Reading the docs, it appears
    > that I need to mod ntp.conf and add restrict x.x.x.x kod, but then I'd need
    > to restart the service.
    >
    > Thanks for any help.


    Let me give you the bad news: If they are hitting your server that
    frequently then they are most probably not running ntpd and only ntpd as
    far as I know, takes notice of KOD packets. There is a newer version in
    ntp-dev which will in a KOD basically return the same timestamp that was
    sent and if the client is obeying the rules it will cause the client
    which is ignoring the KOD signal to misinterpret and reset the clock to
    be further away from the existing time on your ntpd server so that each
    time it tries it gets further and further away in ever increasing
    amounts. When the clock is so far off that someone notices they will
    probably stop using your servers. Meinberg has not released a copy of
    that version since it's still development code. Maybe we can make you a
    binary which you could just drop into the directory where you keep
    ntpd.exe. We will then see if that works for you. I would make an
    excellent test. I assume you do not know whose machines belong to?

    Danny

  4. Re: Kiss-O'-Death

    Bob,

    Unless Meinberg is using a newer version than the release version, I
    doubt it has rate management controls. See the Rate Management and the
    Kiss-o'-Death page in the web documentation for how the scheme works.
    You don't tell the server to send a KoD; you tell it your minimum
    acceptable headway and it does what needs. Note that the recent server
    will send KoD packets as required, only the recent client can respond in
    the intended way.

    Dave

    Bob wrote:
    > How exactly do you configure NTP to send a KOD? I'm running Meinberg's port
    > under Win XP. I'm a sever in the pool. I've got two remote clients that are
    > querying at a rate of several times a minute. Sometimes their queries are
    > spaced wider, but sometimes they hit me spaced at only a few seconds apart.
    > I can block them in my router, but they'd still be sending traffic my way.
    > I'd like to see if KOD makes them go away. Reading the docs, it appears
    > that I need to mod ntp.conf and add restrict x.x.x.x kod, but then I'd need
    > to restart the service.
    >
    > Thanks for any help.
    >
    >


  5. Re: Kiss-O'-Death

    On 2008-06-26, David L. Mills wrote:

    > Unless Meinberg is using a newer version than the release version, I
    > doubt it has rate management controls. See the Rate Management and the
    > Kiss-o'-Death page in the web documentation for how the scheme works.
    > You don't tell the server to send a KoD; you tell it your minimum
    > acceptable headway and it does what needs. Note that the recent server
    > will send KoD packets as required, only the recent client can respond in
    > the intended way.


    FWIW...

    The current NTP-dev documentation is at
    http://www.eecis.udel.edu/~mills/ntp/html/index.html

    The (searchable) NTP Documentation Archive at http://doc.ntp.org/ houses
    documentation for the following stable releases:

    * 4.2.4
    * 4.2.2p4
    * 4.2.2
    * 4.2.0
    * 4.1.2
    * 4.1.1
    * 4.1.0
    * 3-5.93e

    --
    Steve Kostecke
    NTP Public Services Project - http://support.ntp.org/

  6. Re: Kiss-O'-Death

    Bob,

    Bob wrote:
    > How exactly do you configure NTP to send a KOD? I'm running Meinberg's
    > port under Win XP. I'm a sever in the pool. I've got two remote clients
    > that are querying at a rate of several times a minute. Sometimes their
    > queries are spaced wider, but sometimes they hit me spaced at only a few
    > seconds apart.


    I don't know exactly how often or how long this happens. However, please
    take into account that clients may send requests at 2 second intervals at
    startup, if the iburst keyword has been used.

    Also, there may be several clients behind a NAT router, in which case all
    the requests from those clients seem to be coming from a single host with a
    given IP where in fact there are several hosts which are using individual
    private IPs behind the router.

    Depending on how many clients are currently up and running behind the router
    you may see a more or less high number of requests which seem to come from
    a single host.

    Did you also check the source port number of the request packets? The
    numbers should vary if the requests have been sent from several clients
    behind a router. They may or may not vary if they come from a single
    client. I think the conclusion that there is only one "bad boy" can only be
    made if the source port of the request is the same.


    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  7. Re: Kiss-O'-Death

    Bob wrote:
    > How exactly do you configure NTP to send a KOD? I'm running Meinberg's port
    > under Win XP. I'm a sever in the pool. I've got two remote clients that are
    > querying at a rate of several times a minute. Sometimes their queries are
    > spaced wider, but sometimes they hit me spaced at only a few seconds apart.
    > I can block them in my router, but they'd still be sending traffic my way.
    > I'd like to see if KOD makes them go away. Reading the docs, it appears
    > that I need to mod ntp.conf and add restrict x.x.x.x kod, but then I'd need
    > to restart the service.
    >
    > Thanks for any help.
    >
    >


    NTPDC (now deprecated) can make changes to the running configuration.

  8. Re: Kiss-O'-Death


    "Martin Burnicki" wrote in message
    news:i5acj5-96m.ln1@gateway.py.meinberg.de...
    >
    > I don't know exactly how often or how long this happens. However, please
    > take into account that clients may send requests at 2 second intervals at
    > startup, if the iburst keyword has been used.
    >
    > Also, there may be several clients behind a NAT router, in which case all
    > the requests from those clients seem to be coming from a single host with
    > a
    > given IP where in fact there are several hosts which are using individual
    > private IPs behind the router.
    >
    > Depending on how many clients are currently up and running behind the
    > router
    > you may see a more or less high number of requests which seem to come from
    > a single host.
    >
    > Did you also check the source port number of the request packets? The
    > numbers should vary if the requests have been sent from several clients
    > behind a router. They may or may not vary if they come from a single
    > client. I think the conclusion that there is only one "bad boy" can only
    > be
    > made if the source port of the request is the same.
    >
    >
    > Martin
    > --
    > Martin Burnicki
    >
    > Meinberg Funkuhren
    > Bad Pyrmont
    > Germany


    I'll get a bunch of requests with the same port number, then a bunch of
    packets with a different (the port for the bunch is the same) port. Also,
    the time data in the request is random and corrupt.. example below. I've
    contacted the source by email with no response yet. The source - a
    University - lists on their web page what their own machines should be using
    for NTP - their own server.


    No. Time Source Destination Protocol Info
    3 3.908464 128.194.147.44 10.33.90.10 NTP NTP client
    Frame 3 (90 bytes on wire, 90 bytes captured)
    Ethernet II, Src: Cisco-Li_bb:95:dc (00:12:17:bb:95:dc), Dst:
    AsustekC_50:98:6b (00:13:d4:50:98:6b)
    Internet Protocol, Src: 128.194.147.44 (128.194.147.44), Dst: 10.33.90.10
    (10.33.90.10)
    User Datagram Protocol, Src Port: 42536 (42536), Dst Port: ntp (123)
    Network Time Protocol
    Flags: 0x23
    00.. .... = Leap Indicator: no warning (0)
    ...10 0... = Version number: NTP Version 4 (4)
    ..... .011 = Mode: client (3)
    Peer Clock Stratum: unspecified or unavailable (0)
    Peer Polling Interval: invalid (0)
    Peer Clock Precision: 1.000000 sec
    Root Delay: 0.0000 sec
    Root Dispersion: 0.0000 sec
    Reference Clock ID: NULL
    Reference Clock Update Time: NULL
    Originate Time Stamp: NULL
    Receive Time Stamp: NULL
    Transmit Time Stamp: Nov 27, 2018 09:08:52.1230 UTC
    No. Time Source Destination Protocol Info
    4 3.908613 10.33.90.10 128.194.147.44 NTP NTP server
    Frame 4 (90 bytes on wire, 90 bytes captured)
    Ethernet II, Src: AsustekC_50:98:6b (00:13:d4:50:98:6b), Dst:
    Cisco-Li_bb:95:dc (00:12:17:bb:95:dc)
    Internet Protocol, Src: 10.33.90.10 (10.33.90.10), Dst: 128.194.147.44
    (128.194.147.44)
    User Datagram Protocol, Src Port: ntp (123), Dst Port: 42536 (42536)
    Network Time Protocol
    Flags: 0x24
    00.. .... = Leap Indicator: no warning (0)
    ...10 0... = Version number: NTP Version 4 (4)
    ..... .100 = Mode: server (4)
    Peer Clock Stratum: secondary reference (2)
    Peer Polling Interval: invalid (0)
    Peer Clock Precision: 0.000001 sec
    Root Delay: 0.0282 sec
    Root Dispersion: 0.0187 sec
    Reference Clock ID: 68.216.79.113
    Reference Clock Update Time: Jun 26, 2008 02:30:50.0576 UTC
    Originate Time Stamp: Nov 27, 2018 09:08:52.1230 UTC
    Receive Time Stamp: Jun 26, 2008 02:37:43.7211 UTC
    Transmit Time Stamp: Jun 26, 2008 02:37:43.7212 UTC
    No. Time Source Destination Protocol Info
    13 8.204615 128.194.147.44 10.33.90.10 NTP NTP client
    Frame 13 (90 bytes on wire, 90 bytes captured)
    Ethernet II, Src: Cisco-Li_bb:95:dc (00:12:17:bb:95:dc), Dst:
    AsustekC_50:98:6b (00:13:d4:50:98:6b)
    Internet Protocol, Src: 128.194.147.44 (128.194.147.44), Dst: 10.33.90.10
    (10.33.90.10)
    User Datagram Protocol, Src Port: 56540 (56540), Dst Port: ntp (123)
    Network Time Protocol
    Flags: 0x23
    00.. .... = Leap Indicator: no warning (0)
    ...10 0... = Version number: NTP Version 4 (4)
    ..... .011 = Mode: client (3)
    Peer Clock Stratum: unspecified or unavailable (0)
    Peer Polling Interval: invalid (0)
    Peer Clock Precision: 1.000000 sec
    Root Delay: 0.0000 sec
    Root Dispersion: 0.0000 sec
    Reference Clock ID: NULL
    Reference Clock Update Time: NULL
    Originate Time Stamp: NULL
    Receive Time Stamp: NULL
    Transmit Time Stamp: Not representable
    No. Time Source Destination Protocol Info
    14 8.204760 10.33.90.10 128.194.147.44 NTP NTP server
    Frame 14 (90 bytes on wire, 90 bytes captured)
    Ethernet II, Src: AsustekC_50:98:6b (00:13:d4:50:98:6b), Dst:
    Cisco-Li_bb:95:dc (00:12:17:bb:95:dc)
    Internet Protocol, Src: 10.33.90.10 (10.33.90.10), Dst: 128.194.147.44
    (128.194.147.44)
    User Datagram Protocol, Src Port: ntp (123), Dst Port: 56540 (56540)
    Network Time Protocol
    Flags: 0x24
    00.. .... = Leap Indicator: no warning (0)
    ...10 0... = Version number: NTP Version 4 (4)
    ..... .100 = Mode: server (4)
    Peer Clock Stratum: secondary reference (2)
    Peer Polling Interval: invalid (0)
    Peer Clock Precision: 0.000001 sec
    Root Delay: 0.0282 sec
    Root Dispersion: 0.0188 sec
    Reference Clock ID: 68.216.79.113
    Reference Clock Update Time: Jun 26, 2008 02:30:50.0576 UTC
    Originate Time Stamp: Not representable
    Receive Time Stamp: Jun 26, 2008 02:37:48.0167 UTC
    Transmit Time Stamp: Jun 26, 2008 02:37:48.0168 UTC
    No. Time Source Destination Protocol Info
    16 9.304386 128.194.147.44 10.33.90.10 NTP NTP client
    Frame 16 (90 bytes on wire, 90 bytes captured)
    Ethernet II, Src: Cisco-Li_bb:95:dc (00:12:17:bb:95:dc), Dst:
    AsustekC_50:98:6b (00:13:d4:50:98:6b)
    Internet Protocol, Src: 128.194.147.44 (128.194.147.44), Dst: 10.33.90.10
    (10.33.90.10)
    User Datagram Protocol, Src Port: 48143 (48143), Dst Port: ntp (123)
    Network Time Protocol
    Flags: 0x23
    00.. .... = Leap Indicator: no warning (0)
    ...10 0... = Version number: NTP Version 4 (4)
    ..... .011 = Mode: client (3)
    Peer Clock Stratum: unspecified or unavailable (0)
    Peer Polling Interval: invalid (0)
    Peer Clock Precision: 1.000000 sec
    Root Delay: 0.0000 sec
    Root Dispersion: 0.0000 sec
    Reference Clock ID: NULL
    Reference Clock Update Time: NULL
    Originate Time Stamp: NULL
    Receive Time Stamp: NULL
    Transmit Time Stamp: Jul 6, 2020 19:40:23.2793 UTC
    No. Time Source Destination Protocol Info
    17 9.304527 10.33.90.10 128.194.147.44 NTP NTP server
    Frame 17 (90 bytes on wire, 90 bytes captured)
    Ethernet II, Src: AsustekC_50:98:6b (00:13:d4:50:98:6b), Dst:
    Cisco-Li_bb:95:dc (00:12:17:bb:95:dc)
    Internet Protocol, Src: 10.33.90.10 (10.33.90.10), Dst: 128.194.147.44
    (128.194.147.44)
    User Datagram Protocol, Src Port: ntp (123), Dst Port: 48143 (48143)
    Network Time Protocol
    Flags: 0x24
    00.. .... = Leap Indicator: no warning (0)
    ...10 0... = Version number: NTP Version 4 (4)
    ..... .100 = Mode: server (4)
    Peer Clock Stratum: secondary reference (2)
    Peer Polling Interval: invalid (0)
    Peer Clock Precision: 0.000001 sec
    Root Delay: 0.0282 sec
    Root Dispersion: 0.0188 sec
    Reference Clock ID: 68.216.79.113
    Reference Clock Update Time: Jun 26, 2008 02:30:50.0576 UTC
    Originate Time Stamp: Jul 6, 2020 19:40:23.2793 UTC
    Receive Time Stamp: Jun 26, 2008 02:37:49.1164 UTC
    Transmit Time Stamp: Jun 26, 2008 02:37:49.1164 UTC



  9. Re: Kiss-O'-Death

    On 2008-06-26, Bob wrote:

    > I'll get a bunch of requests with the same port number, then a bunch
    > of packets with a different (the port for the bunch is the same)
    > port. Also, the time data in the request is random and corrupt..
    > example below. I've contacted the source by email with no response
    > yet. The source - a University - lists on their web page what their
    > own machines should be using for NTP - their own server.


    KOD only works if the client cooperates. That almost makes as much sense
    as taping a $100 bill to your front door with a "please leave me alone"
    note.

    Might was well just drop packets from those addresses at the router /
    firewall.

    --
    Steve Kostecke
    NTP Public Services Project - http://support.ntp.org/

  10. Re: Kiss-O'-Death

    Martin,

    Good point. In the PTTI paper a few years back, mention was of a
    university that repackaged source addresses for some 2000 campus hosts,
    with result a humungus load on the server. The evolved reference
    implementation would effectively deny service to almost all of them,
    while maintaining fairness to other users. In other words, if the
    minimum average headway was set at 64 s, one packet in 64 s would be
    serviced and the KoD rate would be limited to one packet in 64 s,
    regardless of load.

    Dave

    Martin Burnicki wrote:
    > Bob,
    >
    > Bob wrote:
    >
    >>How exactly do you configure NTP to send a KOD? I'm running Meinberg's
    >>port under Win XP. I'm a sever in the pool. I've got two remote clients
    >>that are querying at a rate of several times a minute. Sometimes their
    >>queries are spaced wider, but sometimes they hit me spaced at only a few
    >>seconds apart.

    >
    >
    > I don't know exactly how often or how long this happens. However, please
    > take into account that clients may send requests at 2 second intervals at
    > startup, if the iburst keyword has been used.
    >
    > Also, there may be several clients behind a NAT router, in which case all
    > the requests from those clients seem to be coming from a single host with a
    > given IP where in fact there are several hosts which are using individual
    > private IPs behind the router.
    >
    > Depending on how many clients are currently up and running behind the router
    > you may see a more or less high number of requests which seem to come from
    > a single host.
    >
    > Did you also check the source port number of the request packets? The
    > numbers should vary if the requests have been sent from several clients
    > behind a router. They may or may not vary if they come from a single
    > client. I think the conclusion that there is only one "bad boy" can only be
    > made if the source port of the request is the same.
    >
    >
    > Martin


  11. Re: Kiss-O'-Death

    The good news: The emails, and a phone call to the source - tamu.edu - got
    it fixed. In the email reply I got, the computer science deparment
    apparently was doing this to more than just me. My IP's blocked in their
    firewall, and they've got some "administrative issues" to deal with.


    "Steve Kostecke" wrote in message
    news:slrng674v6.ggd.kostecke@stasis.kostecke.net.. .
    > On 2008-06-26, Bob wrote:
    >
    >> I'll get a bunch of requests with the same port number, then a bunch
    >> of packets with a different (the port for the bunch is the same)
    >> port. Also, the time data in the request is random and corrupt..
    >> example below. I've contacted the source by email with no response
    >> yet. The source - a University - lists on their web page what their
    >> own machines should be using for NTP - their own server.

    >
    > KOD only works if the client cooperates. That almost makes as much sense
    > as taping a $100 bill to your front door with a "please leave me alone"
    > note.
    >
    > Might was well just drop packets from those addresses at the router /
    > firewall.
    >
    > --
    > Steve Kostecke
    > NTP Public Services Project - http://support.ntp.org/




+ Reply to Thread