Windows Time with NTPv4 - NTP

This is a discussion on Windows Time with NTPv4 - NTP ; Folks, I just poked around and discovered something interesting that affects Windows clients, both XP and Vista. Microsoft has broken the NTP specification in that the client sends a request in symmetric active mode instead of client mode. According to ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 30

Thread: Windows Time with NTPv4

  1. Windows Time with NTPv4

    Folks,

    I just poked around and discovered something interesting that affects
    Windows clients, both XP and Vista.

    Microsoft has broken the NTP specification in that the client sends a
    request in symmetric active mode instead of client mode. According to
    the NTP spec, both ancient and modern, this causes the server to launch
    a symmetric passive association, which would be a serious security
    vulnerability.

    The NTPv4 servers, including those at USNO and NIST, have specific means
    to protect against this vulnerability, so as you might have noticed,
    synchronizing XP or Vista clients to those servers fails.

    However, I jimmied the code so that, while it will not launch an
    association if denied, it will reply in symmetric passive mode. In other
    words, the server behaves in the same way as with an ordinary
    client/server mode. With this change, now in the development branch,
    Windows XP and Vista now work correctly.

    I'm not happy about this. I thought Microsoft had fixed this long ago in
    a service pack. Now at least folks with 400 PCs don't all have to light
    up Windows NTP.

    Dave


  2. Re: Windows Time with NTPv4

    Dave,

    David L. Mills wrote:
    > Folks,
    >
    > I just poked around and discovered something interesting that affects
    > Windows clients, both XP and Vista.
    >
    > Microsoft has broken the NTP specification in that the client sends a
    > request in symmetric active mode instead of client mode. According to
    > the NTP spec, both ancient and modern, this causes the server to launch
    > a symmetric passive association, which would be a serious security
    > vulnerability.
    >
    > The NTPv4 servers, including those at USNO and NIST, have specific means
    > to protect against this vulnerability, so as you might have noticed,
    > synchronizing XP or Vista clients to those servers fails.
    >
    > However, I jimmied the code so that, while it will not launch an
    > association if denied, it will reply in symmetric passive mode. In other
    > words, the server behaves in the same way as with an ordinary
    > client/server mode. With this change, now in the development branch,
    > Windows XP and Vista now work correctly.
    >
    > I'm not happy about this. I thought Microsoft had fixed this long ago in
    > a service pack. Now at least folks with 400 PCs don't all have to light
    > up Windows NTP.


    Huh? This has already been discussed back in 2002, and you had already
    introduced a workaround which should (and obviously did) work similar to
    what you write now.

    See your own posts from August 4, 2002:
    http://groups.google.de/group/comp.p...963f1da8a17cbe
    http://groups.google.de/group/comp.p...9932ca96c5a9a7

    Had this workaround been removed intentionally or unintentionally in the
    mean time, or why should the current -dev version refuse to respond to the
    requests of those broken clients?

    BTW, there's a Meinberg FAQ which tells how to fix those brokeen Windows
    clients and let them send normal peer requests instead of symmetric active
    requests:

    "Why does my Windows Time Service (w32time) not synchronize with my NTP
    Server?"
    http://www.meinberg.de/english/faq/faq_28.htm


    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  3. Re: Windows Time with NTPv4

    I haven't observed this behavior since Windows 2000. But then again, I
    am explicitly telling w32time to use a client-mode association on my
    wondows boxes.

    w32tm /configure /manualpeerlist:"pool.ntp.org,0x8" /
    syncfromflags:MANUAL /update

    The 0x8 part tells it to use a client-mode association. The default is
    time.windows.com,0x1, which is "specail poll interval".

    This is documented here:
    http://technet2.microsoft.com/window....mspx?mfr=true

    I will do some further testing on this point to see what happens when
    you do not specify the association mode.



  4. Re: Windows Time with NTPv4

    Okay, I just did some packet captures. It appears that Vista, when
    configured *only* with a time server host name or IP address, will
    first issue an NTP client mode request, and then an NTP symmetric
    active requirest a few miliseconds later.

    I imagine this default behavior is there to make w32time work in the
    same "broken" fashion that was used in Windows 2000. Backwards
    compatability is a bitch. Do Windows 2000 domain controllers ignore
    client-mode packets or someting? I don't have one to test with.

    When a Vista machine is explicitly configured to use a client mode
    association, like so:
    w32tm /config /manualpeerlistool.ntp.org,0x8
    it issues only client-mode queries, as you would expect.

    I will do some further captures with XP clients, but I expect the
    results to be the same.


  5. Re: Windows Time with NTPv4

    Martin,

    Thanks for the reminder. In the six years hence the code has gone
    through a number of securiy audits and defensive adjustments, one or
    more of which might have plugged the hole. The code at time.nist.gov is
    4.1.1b, which must be before 4.1.1c, dated 10 June 2003, and has the
    hole plugged, so the hole got plugged before that.

    There is talk about the code being audited by someone other than me, in
    which case the hole might get plugged again.

    Does the Meinberg workaround appear in Microsoft KB?

    Dave

    Martin Burnicki wrote:

    > Dave,
    >
    > David L. Mills wrote:
    >
    >>Folks,
    >>
    >>I just poked around and discovered something interesting that affects
    >>Windows clients, both XP and Vista.
    >>
    >>Microsoft has broken the NTP specification in that the client sends a
    >>request in symmetric active mode instead of client mode. According to
    >>the NTP spec, both ancient and modern, this causes the server to launch
    >>a symmetric passive association, which would be a serious security
    >>vulnerability.
    >>
    >>The NTPv4 servers, including those at USNO and NIST, have specific means
    >>to protect against this vulnerability, so as you might have noticed,
    >>synchronizing XP or Vista clients to those servers fails.
    >>
    >>However, I jimmied the code so that, while it will not launch an
    >>association if denied, it will reply in symmetric passive mode. In other
    >>words, the server behaves in the same way as with an ordinary
    >>client/server mode. With this change, now in the development branch,
    >>Windows XP and Vista now work correctly.
    >>
    >>I'm not happy about this. I thought Microsoft had fixed this long ago in
    >>a service pack. Now at least folks with 400 PCs don't all have to light
    >>up Windows NTP.

    >
    >
    > Huh? This has already been discussed back in 2002, and you had already
    > introduced a workaround which should (and obviously did) work similar to
    > what you write now.
    >
    > See your own posts from August 4, 2002:
    > http://groups.google.de/group/comp.p...963f1da8a17cbe
    > http://groups.google.de/group/comp.p...9932ca96c5a9a7
    >
    > Had this workaround been removed intentionally or unintentionally in the
    > mean time, or why should the current -dev version refuse to respond to the
    > requests of those broken clients?
    >
    > BTW, there's a Meinberg FAQ which tells how to fix those brokeen Windows
    > clients and let them send normal peer requests instead of symmetric active
    > requests:
    >
    > "Why does my Windows Time Service (w32time) not synchronize with my NTP
    > Server?"
    > http://www.meinberg.de/english/faq/faq_28.htm
    >
    >
    > Martin


  6. Re: Windows Time with NTPv4

    I let the trace run a bit longer. When configured with only an IP
    address (and not the 0x8 client-mode identifier), here is the Vista
    behavior. It appears to stick with symmetric-active mode, and
    immediately goes to a poll interval of 1024 seconds:

    Configured with IP address or hostname only:
    Time (s) behavior
    -------- --------
    0 w32tm /configure /manualpeerlist:10.140.84.147 /
    syncfromflags:MANUAL /update
    0 restart w32time
    0.1 NTPv3 client-mode query
    0.1 NTPv3 server-mode reply
    1.5 NTPv3 symmetric-active mode query
    1.5 NTPv3 symmetric-active mode reply
    1025.5 NTPv3 symmetric-active mode query
    1025.5 NTPv3 symmetric-active mode reply

    The weird thing is that I get a monlist entry for the client in
    symmetric active mode, even though I have this restrict configuration
    in my ntpd config:
    restrict default kod nomodify notrap nopeer
    restrict 127.0.0.1

    When w32time is explicitly configured to use a client-mode
    association, I see similar behavior, but no symmetric mode
    associations:
    Time (s) behavior
    -------- --------
    0 net start w32time
    0.1 NTPv3 client-mode query
    0.1 NTPv3 server-mode reply
    1.5 NTPv3 client-mode query
    1.5 NTPv3 server-mode reply
    1025.5 NTPv3 client-mode query
    1025.5 NTPv3 server-mode query

    ntpdc monlist reports a mode 3 association with the Vista client in
    this case.

    So it appears the Windows Time Service behavior on Vista is "try
    symmetric mode if I'm not told otherwise, and stick with that if it
    works".


  7. Re: Windows Time with NTPv4

    On Mar 10, 10:53*am, "David L. Mills" wrote:
    > Does the Meinberg workaround appear in Microsoft KB?


    The "0x8" option is documented here:
    http://technet2.microsoft.com/window....mspx?mfr=true

    But it is certainly hard to find. If you did a search for "w32time
    will not sync" or something like that on Microsoft's site it would
    likely not come up.


  8. Re: Windows Time with NTPv4

    Ryan,

    Ryan Malayter wrote:
    > Okay, I just did some packet captures. It appears that Vista, when
    > configured *only* with a time server host name or IP address, will
    > first issue an NTP client mode request, and then an NTP symmetric
    > active requirest a few miliseconds later.
    >
    > I imagine this default behavior is there to make w32time work in the
    > same "broken" fashion that was used in Windows 2000. Backwards
    > compatability is a bitch.


    Yep.

    > Do Windows 2000 domain controllers ignore
    > client-mode packets or someting? I don't have one to test with.


    I don't have, either, and I've never tried to find out to which type of NTP
    packets w32time responds.

    > When a Vista machine is explicitly configured to use a client mode
    > association, like so:
    > w32tm /config /manualpeerlistool.ntp.org,0x8
    > it issues only client-mode queries, as you would expect.


    That's what we suggest in our FAQ article mentioned in my earlier post.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  9. Re: Windows Time with NTPv4

    Dave,

    David L. Mills wrote:
    > Martin,
    >
    > Thanks for the reminder. In the six years hence the code has gone
    > through a number of securiy audits and defensive adjustments, one or
    > more of which might have plugged the hole. The code at time.nist.gov is
    > 4.1.1b, which must be before 4.1.1c, dated 10 June 2003, and has the
    > hole plugged, so the hole got plugged before that.


    Hm, a search in the bitkeeper changelogs yields:

    2002-08-04 (6 years) stenn 1.892
    Attempt to compensate for Microsoft's protocol violations.
    From: Dave Mills.

    However, the most recent entry in the Changelog file from the v4.1.1b
    tarball is:

    ChangeSet@1.786, 2002-02-26 22:44:34-05:00, stenn@whimsy.udel.edu
    ntp-4.1.1
    TAG: NTP_4_1_1

    Yes, the changlog still had a date stamp those days, and this one seems to
    indicate that 4.1.1b has been release *before* the workaround for MS had
    been introduced.

    Anyway, those days the 4.1.1 versions were from the -stable branch whereas
    the ntp-dev versions were 4.1.7x.

    Since the workaround was added to ntp-dev it appeared (at least in the
    changelog file) in the v4.1.73 tarball, which was released 2003-01-22.
    So that workaround for w32time clients has never been in v4.1.1x versions,
    however, it is in v4.2.0.

    Looking through the changesets reveals that the workaround was modified and
    finally removed in March/April 2005.

    > There is talk about the code being audited by someone other than me, in
    > which case the hole might get plugged again.


    Maybe a comment in the code saying *why* this specific handling has been
    added would prevent it from being removed.

    > Does the Meinberg workaround appear in Microsoft KB?


    We've been searching for the reason of this problem with one of our
    customers, and the first hint was in this news article at
    microsoft.public.windows.server.migration:
    http://groups.google.com/groups?selm...ngxa06.phx.gbl

    This was forwarded to the German MS support who had been unable to help our
    customer earlier. So finally a KB article was written on this topic. The KB
    article was first used by MS internally only and then published, AFAIR in
    2004:
    http://support.microsoft.com/?scid=kb;en;875424

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  10. Re: Windows Time with NTPv4

    Martin,

    Maybe so, but when I tried both XP and Vista before the change I
    mentioned, both timed out and did not work.

    Dave

    Martin Burnicki wrote:
    > Ryan,
    >
    > Ryan Malayter wrote:
    >
    >>Okay, I just did some packet captures. It appears that Vista, when
    >>configured *only* with a time server host name or IP address, will
    >>first issue an NTP client mode request, and then an NTP symmetric
    >>active requirest a few miliseconds later.
    >>
    >>I imagine this default behavior is there to make w32time work in the
    >>same "broken" fashion that was used in Windows 2000. Backwards
    >>compatability is a bitch.

    >
    >
    > Yep.
    >
    >
    >>Do Windows 2000 domain controllers ignore
    >>client-mode packets or someting? I don't have one to test with.

    >
    >
    > I don't have, either, and I've never tried to find out to which type of NTP
    > packets w32time responds.
    >
    >
    >>When a Vista machine is explicitly configured to use a client mode
    >>association, like so:
    >> w32tm /config /manualpeerlistool.ntp.org,0x8
    >>it issues only client-mode queries, as you would expect.

    >
    >
    > That's what we suggest in our FAQ article mentioned in my earlier post.
    >
    > Martin


  11. Re: Windows Time with NTPv4

    Martin,

    Thanks for the link. What astonishes me is that, while Microsoft clearly
    understands the issue, they refuse to change the default. I cling to my
    conclusion this is a purposeful attempt to enhance product differentiation.

    The workaround is clearly dangerous for the general application and can
    lead to serious misconceptions with respect to the stated model defined
    in the specification. Symmetric modes are designed to provide push-pull
    synchronization with cryptographically secure configurations. When such
    is not the intent, client/server mode is specified.

    The workaround should be under control of a build define, normally
    disabled, and with a note in the code pointing to the KB article.

    Dave

    Martin Burnicki wrote:

    > Dave,
    >
    > David L. Mills wrote:
    >
    >>Martin,
    >>
    >>Thanks for the reminder. In the six years hence the code has gone
    >>through a number of securiy audits and defensive adjustments, one or
    >>more of which might have plugged the hole. The code at time.nist.gov is
    >>4.1.1b, which must be before 4.1.1c, dated 10 June 2003, and has the
    >>hole plugged, so the hole got plugged before that.

    >
    >
    > Hm, a search in the bitkeeper changelogs yields:
    >
    > 2002-08-04 (6 years) stenn 1.892
    > Attempt to compensate for Microsoft's protocol violations.
    > From: Dave Mills.
    >
    > However, the most recent entry in the Changelog file from the v4.1.1b
    > tarball is:
    >
    > ChangeSet@1.786, 2002-02-26 22:44:34-05:00, stenn@whimsy.udel.edu
    > ntp-4.1.1
    > TAG: NTP_4_1_1
    >
    > Yes, the changlog still had a date stamp those days, and this one seems to
    > indicate that 4.1.1b has been release *before* the workaround for MS had
    > been introduced.
    >
    > Anyway, those days the 4.1.1 versions were from the -stable branch whereas
    > the ntp-dev versions were 4.1.7x.
    >
    > Since the workaround was added to ntp-dev it appeared (at least in the
    > changelog file) in the v4.1.73 tarball, which was released 2003-01-22.
    > So that workaround for w32time clients has never been in v4.1.1x versions,
    > however, it is in v4.2.0.
    >
    > Looking through the changesets reveals that the workaround was modified and
    > finally removed in March/April 2005.
    >
    >
    >>There is talk about the code being audited by someone other than me, in
    >>which case the hole might get plugged again.

    >
    >
    > Maybe a comment in the code saying *why* this specific handling has been
    > added would prevent it from being removed.
    >
    >
    >>Does the Meinberg workaround appear in Microsoft KB?

    >
    >
    > We've been searching for the reason of this problem with one of our
    > customers, and the first hint was in this news article at
    > microsoft.public.windows.server.migration:
    > http://groups.google.com/groups?selm...ngxa06.phx.gbl
    >
    > This was forwarded to the German MS support who had been unable to help our
    > customer earlier. So finally a KB article was written on this topic. The KB
    > article was first used by MS internally only and then published, AFAIR in
    > 2004:
    > http://support.microsoft.com/?scid=kb;en;875424
    >
    > Martin


  12. Re: Windows Time with NTPv4

    But doesn't symmetric association require authorization or is it only
    true when there's a keys file?

    I ask because after following this thread, I noticed that NTP running
    on our NAS had three Windows XP systems as peers. Luckily, their
    jitter sucked and being themselves synchronized to the NAS they were
    never selected as references. Anyways, I removed the line disabling
    authorization and NTP didn't accept those systems as peers anymore,
    even though they still connect to the NAS using mode 1.

    Thanks.

  13. Re: Windows Time with NTPv4

    Evandro,

    Evandro Menezes wrote:
    > But doesn't symmetric association require authorization or is it only
    > true when there's a keys file?


    AFAIK peer associations do require authentication configured correctly.

    > I ask because after following this thread, I noticed that NTP running
    > on our NAS had three Windows XP systems as peers.


    Do the Windows system run ntpd or w32time? If they run ntpd then
    authentication could be configured correctly. I don't know how any version
    of w32time could be configured to support NTP's symmetric keys or even
    autokey.

    > Luckily, their
    > jitter sucked and being themselves synchronized to the NAS they were
    > never selected as references. Anyways, I removed the line disabling
    > authorization and NTP didn't accept those systems as peers anymore,
    > even though they still connect to the NAS using mode 1.


    This seems to indicate that ntpd is running on the XP machines and has been
    configured correctly with authentication.

    Setting up peers requires that the admins of the involved machines are
    willing to do so, since peers can ask the other peers to change their time.

    Of course the admin of a NTP server does not want his NTP server's time be
    changed just because some dumb client sends some packet asking to do so.

    This is what happens with w32time which under certain conditions sends
    "peer" requests instead of "client" requests. Since those w32time clients
    have neither been configured nor authenticated as peers, the question is
    how they should be handled by ntpd.

    The default was that ntpd just dropped those requests, i.e. didn't send a
    response at all, in which case the w32time clients were unable to
    synchronize to the NTP server, unless they were reconfigured correctly to
    send "client" requests.

    The workaround in ntpd was to send normal "server" responses as it would do
    for normal "client" requests, so those w32time clients are happy.


    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  14. Re: Windows Time with NTPv4

    On Mar 13, 3:56*am, Martin Burnicki
    wrote:
    > The default was that ntpd just dropped those requests, i.e. didn't send a
    > response at all, in which case the w32time clients were unable to
    > synchronize to the NTP server, unless they were reconfigured correctly to
    > send "client" requests.


    Hmm... I've notice lots of Windows machines that connect to my pool
    server, which runs ntpd 4.2.4p4@1.520-modena (Meinberg). Wireshark
    indicates that the ntp srever does reply with Symmetric Active packets
    to thse Windows clients (mode 1), even though no peers or
    authentication are configured. I even have a "restrict default nopeer"
    in there.

    (I say "Windows clients" as I am guessing anything that is NTPv3,
    clock precision of -6, and requests symmetric active is a Windows
    client.)

    I've also never had any trouble syncing to any pool.ntp.org servers
    using w32time, even without the 0x8 client mode identifier.

    My pool ntp.conf:
    # Use specific NTP servers
    server ntpmaster1.sys.cogentco.com iburst
    server ntpmaster2.sys.cogentco.com
    server ntp-2.cso.uiuc.edu
    server ntp3.cs.wisc.edu

    #Local network Peers
    peer ntp1.bai.org
    peer ntp2.bai.org

    restrict default kod nomodify notrap nopeer
    restrict mask 255.255.252.0 nomodify notrap
    restrict mask 255.255.250.0 nomodify notrap
    restrict 127.0.0.1


  15. Re: Windows Time with NTPv4

    On Mar 12, 9:23*am, "David L. Mills" wrote:
    > Thanks for the link. What astonishes me is that, while Microsoft clearly
    > understands the issue, they refuse to change the default. I cling to my
    > conclusion this is a purposeful attempt to enhance product differentiation..


    Hanlon's Razor: "Never attribute to malice that which can be
    adequately explained by stupidity"... or something like that.

    I don't see NTP compatability or incompatibility as anything that
    would drive Windows sales or Windows lock-in, do you?

    I suspect they're just trying to maintain compatabilty with a previous
    stupid mistake, namely the broken Windows 2000 w32time. There are
    still millions of Windows 2000 servers out there, and many of them are
    still domain controllers. Backward compatability is a really big deal
    for MSFT. When new stuff from MSFT doesn't work almost perfectly with
    the old stuff (e.g. Vista), it is a total PR and financial disaster.
    This prevents MSFT from correcting a lot of previous design mistakes
    and bugs.

    I suppose they should try client mode first, and if it works stick
    with it. Only use Symmetric Active mode if the server doesn't respond
    properly to the client mode requests. I think that would solve the
    backwards-compatability thing with Windows 2000 domain controllers,
    and not harm real, RFC-compliant NTP servers.

    I think I will actually file a bug report with MSFT on this, and see
    if it goes anywhere.

  16. Re: Windows Time with NTPv4

    On Mar 13, 3:56 am, Martin Burnicki
    wrote:
    >
    > Do the Windows system run ntpd or w32time? If they run ntpd then
    > authentication could be configured correctly. I don't know how any version
    > of w32time could be configured to support NTP's symmetric keys or even
    > autokey.


    They run w32time.

    > This seems to indicate that ntpd is running on the XP machines and has been
    > configured correctly with authentication.


    Actually not. I had this in ntp.conf:

    restrict default kod limited nopeer
    tos orphan 4
    enable bclient
    disable auth

    Then, the w32time systems appeared as servers in the output of "ntpq -
    p" and "ntpdc -c listpeers" confirmed their status as peers.

    When I removed the last line above, as w32time doesn't support
    authentication keys, the w32time systems stopped showing up as
    servers, even though their association mode remained 1. So w32time
    was happy, believing it was a peer (if it indeed behaves as a peer is
    left to be demonstrated), and NTP kept on working without the
    interference of w32time in its choice of servers.

    > Of course the admin of a NTP server does not want his NTP server's time be
    > changed just because some dumb client sends some packet asking to do so.


    But I think that with the proper restrictions NTP will do the right
    thing.

    > This is what happens with w32time which under certain conditions sends
    > "peer" requests instead of "client" requests. Since those w32time clients
    > have neither been configured nor authenticated as peers, the question is
    > how they should be handled by ntpd.


    I think that they're being handled just fine by NTP. NTP does what
    ntp.conf tells it to do and it can handle w32time stupidity just fine
    as in my case above.

    Thanks.

  17. Re: Windows Time with NTPv4

    Ryan Malayter wrote:
    > On Mar 13, 3:56*am, Martin Burnicki
    > wrote:
    >> The default was that ntpd just dropped those requests, i.e. didn't send a
    >> response at all, in which case the w32time clients were unable to
    >> synchronize to the NTP server, unless they were reconfigured correctly to
    >> send "client" requests.

    >
    > Hmm... I've notice lots of Windows machines that connect to my pool
    > server, which runs ntpd 4.2.4p4@1.520-modena (Meinberg). Wireshark
    > indicates that the ntp srever does reply with Symmetric Active packets
    > to thse Windows clients (mode 1), even though no peers or
    > authentication are configured. I even have a "restrict default nopeer"
    > in there.
    >
    > (I say "Windows clients" as I am guessing anything that is NTPv3,
    > clock precision of -6, and requests symmetric active is a Windows
    > client.)
    >
    > I've also never had any trouble syncing to any pool.ntp.org servers
    > using w32time, even without the 0x8 client mode identifier.


    Hm, I actually had just a very quick look on the NTP code changes where this
    kind of packets is handled (search vor "case AM_NEWPASS:" in ntp_proto.c).

    As I've already mentioned in an earlier post the original workaround was
    introduced in v4.1.73, dated around 2002-08-04, which was a -dev version
    before the next stable version 4.2.0.

    Also as already mentioned, that piece of code modified around March/April
    2005, but it looks like the workaround has not been removed but only
    changed.

    I've got a little program here which can send request packets to an NTP
    server and display the contents of both the request and reply packet. I've
    run that program against different Linux machines here running different
    NTP versions:

    Before the original workaround ntpd did not reply at all to unauthenticated
    mode 1 requests:

    ntpd 4.0.99f Sat Jul 29 13:00:13 GMT 2000 (1)
    mode 3 req -> mode 4 resp
    mode 1 req -> timeout

    With the original workaround it sends a mode 2 response:

    ntpd 4.2.0a@1.1190-r Sat Mar 19 19:20:10 UTC 2005 (1)
    mode 3 req -> mode 4 resp
    mode 1 req -> mode 2 resp

    With the modified workaround as in current ntp-stable it sends a mode 1
    response:

    ntpd 4.2.4p3@1.1502-o Fri Sep 21 21:36:25 UTC 2007 (1)
    mode 3 req -> mode 4 resp
    mode 1 req -> mode 1 resp

    And finally the current ntp-dev version again does not reply at all to
    unauthenticated mode 1 requests:

    ntpd 4.2.5p113@1.1720-o Thu Mar 13 16:03:23 UTC 2008 (1)
    mode 3 req -> mode 4 resp
    mode 1 req -> timeout

    So, Dave, the older workaround has been removed after the 4.2.4 release.
    Please note that your latest patch which introduced the workaround again is
    not yet available in the BK repos or an ntp-dev tarball.

    Ryan, that should also explain why we havn't heard much in the last years
    about w32time clients not sync'ing to NTP servers.


    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  18. Re: Windows Time with NTPv4

    Evandro,

    Remember, enable/disable auth has nothing to do with authentication
    itself, just whether new associations can be mobilized if no
    authentication is used. In your case a symmetric passive association was
    apparently mobilized and began sending mode-2 packets just as if a
    legitimate peer was involved.

    Windows was apparently happy with the reply, even if it was up to 64
    seconds delayed, and apparently successfully ignored subsequent mode-2
    packets sent from the association until it timed out.

    These are probably unintended consequences, so disable auth is probably
    not an optimum workaround. Better to use the Windows workaround. I have
    included a link to the Microsoft KB in the latest documentation and will
    provide some way to selectively activate the workaround mentioned
    previously.

    Dave

    Evandro Menezes wrote:
    > On Mar 13, 3:56 am, Martin Burnicki
    > wrote:
    >
    >>Do the Windows system run ntpd or w32time? If they run ntpd then
    >>authentication could be configured correctly. I don't know how any version
    >>of w32time could be configured to support NTP's symmetric keys or even
    >>autokey.

    >
    >
    > They run w32time.
    >
    >
    >>This seems to indicate that ntpd is running on the XP machines and has been
    >>configured correctly with authentication.

    >
    >
    > Actually not. I had this in ntp.conf:
    >
    > restrict default kod limited nopeer
    > tos orphan 4
    > enable bclient
    > disable auth
    >
    > Then, the w32time systems appeared as servers in the output of "ntpq -
    > p" and "ntpdc -c listpeers" confirmed their status as peers.
    >
    > When I removed the last line above, as w32time doesn't support
    > authentication keys, the w32time systems stopped showing up as
    > servers, even though their association mode remained 1. So w32time
    > was happy, believing it was a peer (if it indeed behaves as a peer is
    > left to be demonstrated), and NTP kept on working without the
    > interference of w32time in its choice of servers.
    >
    >
    >>Of course the admin of a NTP server does not want his NTP server's time be
    >>changed just because some dumb client sends some packet asking to do so.

    >
    >
    > But I think that with the proper restrictions NTP will do the right
    > thing.
    >
    >
    >>This is what happens with w32time which under certain conditions sends
    >>"peer" requests instead of "client" requests. Since those w32time clients
    >>have neither been configured nor authenticated as peers, the question is
    >>how they should be handled by ntpd.

    >
    >
    > I think that they're being handled just fine by NTP. NTP does what
    > ntp.conf tells it to do and it can handle w32time stupidity just fine
    > as in my case above.
    >
    > Thanks.


  19. Re: Windows Time with NTPv4

    Evandro Menezes wrote:
    > But doesn't symmetric association require authorization or is it only
    > true when there's a keys file?
    >


    No, you cannot *require* authorization which doesn't exist anyway, but
    you can require authentication and I strongly recommend it for peers,
    but it's not required by default.

    > I ask because after following this thread, I noticed that NTP running
    > on our NAS had three Windows XP systems as peers. Luckily, their
    > jitter sucked and being themselves synchronized to the NAS they were
    > never selected as references. Anyways, I removed the line disabling
    > authorization and NTP didn't accept those systems as peers anymore,
    > even though they still connect to the NAS using mode 1.
    >


    Yes, standard Windows implementations suck, but you never know. I
    recommend that anyone using standard Windows time but pointing to an NTP
    server make sure that it's running in the proper client-server mode.

    Danny

    > Thanks.
    >
    > _______________________________________________
    > questions mailing list
    > questions@lists.ntp.org
    > https://lists.ntp.org/mailman/listinfo/questions
    >


  20. Re: Windows Time with NTPv4

    Martin Burnicki wrote:
    > Evandro,
    >
    > Evandro Menezes wrote:
    >> But doesn't symmetric association require authorization or is it only
    >> true when there's a keys file?

    >
    > AFAIK peer associations do require authentication configured correctly.
    >


    No, that's not required. It should be required and you can specify key
    on the peer directive line.

    >> Luckily, their
    >> jitter sucked and being themselves synchronized to the NAS they were
    >> never selected as references. Anyways, I removed the line disabling
    >> authorization and NTP didn't accept those systems as peers anymore,
    >> even though they still connect to the NAS using mode 1.

    >
    > This seems to indicate that ntpd is running on the XP machines and has been
    > configured correctly with authentication.
    >


    No, it sounds like 3w32time is being run on these machines otherwise the
    jitter would not be so bad.

    > Setting up peers requires that the admins of the involved machines are
    > willing to do so, since peers can ask the other peers to change their time.
    >
    > Of course the admin of a NTP server does not want his NTP server's time be
    > changed just because some dumb client sends some packet asking to do so.
    >


    Set up restrict with notrust on the LAN network addresses.

    > This is what happens with w32time which under certain conditions sends
    > "peer" requests instead of "client" requests. Since those w32time clients
    > have neither been configured nor authenticated as peers, the question is
    > how they should be handled by ntpd.
    >
    > The default was that ntpd just dropped those requests, i.e. didn't send a
    > response at all, in which case the w32time clients were unable to
    > synchronize to the NTP server, unless they were reconfigured correctly to
    > send "client" requests.
    >


    I think that this is what Dave was talking about where the NTP code was
    allowing it to set the clock.

    > The workaround in ntpd was to send normal "server" responses as it would do
    > for normal "client" requests, so those w32time clients are happy.
    >


    Yes, but the challenge is to identify those systems as sending the wrong
    NTP packet mode.

    Danny
    >
    > Martin


+ Reply to Thread
Page 1 of 2 1 2 LastLast