Windows Time with NTPv4
David L. Mills
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
Martin Burnicki
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.protocols.time.ntp/msg/51963f1da8a17cbe
http://groups.google.de/group/comp.protocols.time.ntp/msg/199932ca96c5a9a7
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
Ryan Malayter
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/windowsserver/en/library/b43a025f-cce2-4c82-b3ea-3b95d482db3a1033.mspx?mfr=true
I will do some further testing on this point to see what happens when
you do not specify the association mode.
Ryan Malayter
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 /manualpeerlist:pool.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.
David L. Mills
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
Ryan Malayter
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".
Ryan Malayter
> Does the Meinberg workaround appear in Microsoft KB?
The "0x8" option is documented here:
http://technet2.microsoft.com/windowsserver/en/library/b43a025f-cce2-4c82-b3ea-3b95d482db3a1033.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.
Martin Burnicki
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 /manualpeerlist:pool.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 Burnicki
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:
Chan...@1.786, 2002-02-26 22:44:34-05:00, st...@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=qREQ%248lrDHA.2308%40cpmsftngxa06.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
David L. Mills
Maybe so, but when I tried both XP and Vista before the change I
mentioned, both timed out and did not work.
Dave
David L. Mills
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
Evandro Menezes
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.
Martin Burnicki
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.
Ryan Malayter
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...@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 <localsubnet> mask 255.255.252.0 nomodify notrap
restrict <localsubnet> mask 255.255.250.0 nomodify notrap
restrict 127.0.0.1
Ryan Malayter
> 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.
Evandro Menezes
> 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.
Martin Burnicki
> On Mar 13, 3:56 am, Martin Burnicki <martin.burni...@meinberg.de>
> 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...@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...@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...@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....@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.
David L. Mills
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
Danny Mayer
> 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
> ques...@lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/questions
>
Danny Mayer
> 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
Martin Burnicki
> 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.
Hm, I've been pretty sure authentication had been required for proper peer
operation (unless explicitely disabled, of course).
In RFC-1305, section "Initialization-Instantiation Procedure" mentions:
--- <snip> -----
[...] With the authentication bits set as suggested, only properly
authenticated peers can become the synchronization source.
--- <snip> -----
[...]
>> 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.
Of course this would be possible, but the expected behaviour (for me, at
least) would be not to let bad guys doing bad things by default, i.e. not
let them change my time until explicitely given the permission 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.
>>
>
> I think that this is what Dave was talking about where the NTP code was
> allowing it to set the clock.
Even without authentication?
Now the question is whether the behaviour of the current implementation is
by design, or whether it has changed unintentionally in the past, or I've
just misunderstood the RFC.
>> 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.
As long as peering required authentication this should not matter since
those clients would not be authenticated correctly.
David Woolley
> Of course this would be possible, but the expected behaviour (for me, at
> least) would be not to let bad guys doing bad things by default, i.e. not
> let them change my time until explicitely given the permission to do so.
>
My impression was that the Windows workaround didn't allow one to create
peers without authentication, but rather treated such an attempt as
actually creating a simple client relationship.
Martin Burnicki
Maybe I've been to unspecific.
The initial code before August 2002 just dropped peer packets if they were
not authenticated, so those w32time clients did never get synchronized to
the NTP server unless either they were authenticated (which AFAIK is not
possible with w32time) or the w32time service had been configured correctly
to send client requests instead of peer requests.
The workaround was just to send a reply, without mobilizing an association
for that unauthenticated peer (w32time), so that peer was happy to get a
response but ntpd did not treat it like a real, authenticated peer.
That's how I thought things would work, and now I'm pretty surprized that
peering should be possible without well configured authentication. If
that's the original design then NTP daemons before August 2002 would have
mobilized an association for w32time peers instead of simply dropping the
request packet.
If the current versions don't require authentication for peering then, as
already said in my previous post, the question is whether the behaviour of
the current implementation is by design, or whether it has changed
unintentionally in the past, or I'm completely on the wrong rail.
Evandro Menezes
<da...@ex.djwhome.demon.co.uk.invalid> wrote:
>
> My impression was that the Windows workaround didn't allow one to create
> peers without authentication, but rather treated such an attempt as
> actually creating a simple client relationship.
Yes, this seems to be what I've observed in my case (NTP 4.2.0).
Ryan Malayter
> Yes, but the challenge is to identify those systems as sending the wrong
> NTP packet mode.
I've been going under the assumption that anyhthing with NTPv3, mode
1, and precision -6 is a w32time system not configured with the 0x8
client mode identifier.
Couldn't one also assume that any system which sends a mode-1 packet
to an ntpd server and is not explicitly identified with a "peer"
directive should recieve a server-mode reply?
Danny Mayer
No.
Danny
Ryan Malayter
> > I've been going under the assumption that anyhthing with NTPv3, mode
> > 1, and precision -6 is a w32time system not configured with the 0x8
> > client mode identifier.
>
> > Couldn't one also assume that any system which sends a mode-1 packet
> > to an ntpd server and is not explicitly identified with a "peer"
> > directive should recieve a server-mode reply?
>
> No.
I believe what I wrote was unclear; I meant that when ALL of the
conditions I mentioned in both paragraphs are satisfied, we should not
mobilize a symmetric association.
That is, when a packet is received that is:
1) NTPv3
and
2) has precision -6
and
3) is mode 1 (symmetric active)
and
4) and is not from an explicitly configured peer
...we assume it is from a mis-configured w32time system, and mobilize
a transient association and send a server-mode reply instead of a
symmetric passive association.
Is this what the "windows hack" code already does? What criteria does
it use?
Danny Mayer
I just took a look at the SNTP client requirements in the draft and I
believe that we should add a few words on the modes that an SNTP client
should be handling. I'm not up to it tonight to put something together.
I'll tackle that tomorrow.
Danny
Steve Kostecke
> Martin Burnicki wrote:
>
>> 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.
notrust means require packets to be cryptographically signed.
notrust does not mean "do not trust this ... as a time source."
--
Steve Kostecke <kost...@ntp.org>
NTP Public Services Project - http://support.ntp.org/
David Woolley
>>
>>> 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.
NTP is a time pulling protocol. Peers make use of the time on the other
peer as one term in the estimation of their time error, but the other
peer doesn't demand that they use that time, and when it is used, it can
be diluted by other information about the time.
I think you may understand this, but the idea that a server sets the
time on a client is one of the more common NTP misconceptions.