Microsoft Win XP violation RFC 2030 SNTP ?
Johan Fredrik Øhman
with NTP v4 (see
http://groups.google.com/groups?hl=en&selm=9s76fd%242r0%241%40maud.ifi.uio.n
o)
I have done some packet sniffing of the Microsoft client, and the results
are, well, I don't know... Typical Microsoft maybe.
First a quote from the Windows XP help box: "Only time servers that use the
Simple Network Time Protocol will work"
OK, so I enter my NTP v4 server in the "Server field" and press "Update".
This is supposed to synchronize the local computer clock. And so it does,
that is, most of the time.... Especially if you try to resynchronize after
a short time after the first synchronization, you will get what seems as a
timeout error in WinXP.
I found this very strange, and decided to check what XP actually does.
[root@blekkulf /root]# tcpdump port 123
Kernel filter, protocol ALL, TURBO mode (575 frames), datagram packet socket
tcpdump: listening on all devices
23:09:54.126050 eth0 < ves-dhcp.studby.uio.no.ntp > blekkulf.ntp: v3 sym_act
strat 3 poll 10 prec -6
23:10:02.597968 eth0 > blekkulf.ntp > ves-dhcp.studby.uio.no.ntp: v3 sym_pas
strat 3 poll 6 prec -18 (DF) [tos 0x10]
23:10:10.609782 eth0 < ves-dhcp.studby.uio.no.ntp > blekkulf.ntp: v3 sym_act
strat 0 poll 10 prec -6
23:11:05.597875 eth0 > blekkulf.ntp > ves-dhcp.studby.uio.no.ntp: v3 sym_pas
strat 3 poll 6 prec -18 (DF) [tos 0x10]
...
This is a copy of the tcpdump of port 123 on the server.
"Blekkulf" is the NTP v4 server
"ves-dhcp" is the Windows XP
Here comes the strange part.
1) If windows is using the SNTP protocol, why is the "sym_act" mode in use
???
2 Notice that it takes 8 seconds for the NTP server to respond
3) The NTP server keeps retransmitting the packets for some time (entry 2
and 4 in the above list)
In the RFC 2030, it is stated that the Mode should be 3 (client) in SNTP !
Can _anybody_ explain this ? time.nist.gov is one of the servers that is
"default" in Windows XP. If this is a NTP server, shouldn't it also
encounter the same problems ?
--
Johan Fredrik Øhman
David L. Mills
I love it; I just love it! I fired up WinXP, too, and it did discipline
the clock, but I did not notice the details. It's amazing how brutal
Microsoft can be about standards. Comments below.
"Johan Fredrik Řhman" wrote:
>
> I have previously had problems using the Windows XP synchronization feature
> with NTP v4 (see
> http://groups.google.com/groups?hl=en&selm=9s76fd%242r0%241%40maud.ifi.uio.n
> o)
> I have done some packet sniffing of the Microsoft client, and the results
> are, well, I don't know... Typical Microsoft maybe.
>
> First a quote from the Windows XP help box: "Only time servers that use the
> Simple Network Time Protocol will work"
No; SNMP is a proper subset of NTP. My WinXP has joy of either stripe.
> OK, so I enter my NTP v4 server in the "Server field" and press "Update".
> This is supposed to synchronize the local computer clock. And so it does,
> that is, most of the time.... Especially if you try to resynchronize after
> a short time after the first synchronization, you will get what seems as a
> timeout error in WinXP.
>
> I found this very strange, and decided to check what XP actually does.
>
> [root@blekkulf /root]# tcpdump port 123
> Kernel filter, protocol ALL, TURBO mode (575 frames), datagram packet socket
> tcpdump: listening on all devices
> 23:09:54.126050 eth0 < ves-dhcp.studby.uio.no.ntp > blekkulf.ntp: v3 sym_act
> strat 3 poll 10 prec -6
> 23:10:02.597968 eth0 > blekkulf.ntp > ves-dhcp.studby.uio.no.ntp: v3 sym_pas
> strat 3 poll 6 prec -18 (DF) [tos 0x10]
> 23:10:10.609782 eth0 < ves-dhcp.studby.uio.no.ntp > blekkulf.ntp: v3 sym_act
Delightful! You are gonna like this. If I understand your trace, WinXP
sent a symmetric active packet to the server, indicating willingness to
synchronize the server(!). Usually, this happens when a NTP user
mistakenly uses a peer command instead of a server command in the
configuration file. Funny thing; the server sent a symmetric passive
packet back to WinXP indicating it mobilized an ephemeral association.
There are klaxon horns in the documentation that says never to do that
unless the peer is authenticated. As it is, yummy, if you can persuade
WiniXP to send stratum 1 in those packets, the server could wind up
synchronized to WinXP. That would be a first
Oh what a lovely security hole. The server operator has not heeded the
advice in the documentation. That caution was in the NTPv3 documentation
and NTPv4 documentation and in both late NTPv3 and all NTPv4 versions,
authentication defaults <<enabled>>. Remember, this being said many
times here, the only thing the authentication switch does is require
authentication to mobilize broadcast or symmetric associations if
enabled, or do this even without authentication if disabled.
So, I wound up a non-WinXP client here in symmetric active mode and (at
least) windows.microsoft.com did <<not>> reply. At least they got that
right.
> strat 0 poll 10 prec -6
> 23:11:05.597875 eth0 > blekkulf.ntp > ves-dhcp.studby.uio.no.ntp: v3 sym_pas
> strat 3 poll 6 prec -18 (DF) [tos 0x10]
> ...
>
> This is a copy of the tcpdump of port 123 on the server.
> "Blekkulf" is the NTP v4 server
> "ves-dhcp" is the Windows XP
>
> Here comes the strange part.
> 1) If windows is using the SNTP protocol, why is the "sym_act" mode in use
> ???
> 2 Notice that it takes 8 seconds for the NTP server to respond
> 3) The NTP server keeps retransmitting the packets for some time (entry 2
> and 4 in the above list)
>
> In the RFC 2030, it is stated that the Mode should be 3 (client) in SNTP !
Microsoft is being incredibly rude by including time.nist.gov as
selectable. That poor dude is humping over 230 packets per second even
now. Why not use Microsoft's own NIST server attached to its own network
(This is not the same server as windows.microsoft.com)?
> Can _anybody_ explain this ? time.nist.gov is one of the servers that is
> "default" in Windows XP. If this is a NTP server, shouldn't it also
> encounter the same problems ?
The NIST server should not respond to symmetric active messages either,
unless you have the authentication codes.
> --
> Johan Fredrik Řhman
Thanks for the yuk. Bottom line: Why does WinXP send symmetric active
packets? In general, that won'r work. It has to send client packets. Can
you verify your scenario and find out if WinXP ever sends other packet
flavors?
Dave
Johan Fredrik Øhman
> Oh what a lovely security hole. The server operator has not heeded the
> advice in the documentation. That caution was in the NTPv3 documentation
> and NTPv4 documentation and in both late NTPv3 and all NTPv4 versions,
> authentication defaults <<enabled>>. Remember, this being said many
> times here, the only thing the authentication switch does is require
> authentication to mobilize broadcast or symmetric associations if
> enabled, or do this even without authentication if disabled.
Well, it's my server and it is used for experiment purposes mostly. That's why
the security might be "low".
> So, I wound up a non-WinXP client here in symmetric active mode and (at
> least) windows.Microsoft.com did <<not>> reply. At least they got that
> right.
But if their WindowsXP client uses symmetric active mode to synchronize with my
NTP server,
> Thanks for the yuk. Bottom line: Why does WinXP send symmetric active
> packets? In general, that won't work. It has to send client packets. Can
> you verify your scenario and find out if WinXP ever sends other packet
> flavors?
Here follow a verification. Now I did the packet sniffing on my Windows XP
machine, using a windows version of
tcpdump called windump.
Machines:
Matrisen - Windows XP - the client in this case
Blekkulf - Linux RedHat 7.2 - NTP server v4
My setup on the NTP server machine: Blekkulf
-----------------------------------------
[root@blekkulf /root]# rpm -qi ntp
Name : ntp Relocations: (not relocateable)
Version : 4.1.0 Vendor: Red Hat, Inc.
Release : 4 Build Date: Wed 05 Sep 2001 12:54:46
PM CEST
Install date: Mon 05 Nov 2001 10:57:15 PM CET Build Host:
porky.devel.redhat.com
Group : System Environment/Daemons Source RPM: ntp-4.1.0-4.src.rpm
Size : 2063008 License: distributable
Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL : http://www.cis.udel.edu/~ntp
Summary : Synchronizes system time using the Network Time Protocol (NTP).
----------------- Config File of the Blekkulf (NTP v4 Server) ----------
server fartein.ifi.uio.no
server time.alcanet.no
server ntp.uio.no
server benoni.uit.no
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
driftfile /etc/ntp/drift
broadcastdelay 0.008
authenticate no
--------------------
TCPDUMP on the WinXP machine to various timeservers
=======================================
23:11:45.172911 matrisen.uio.no.123 > time.nist.gov.123: [len=48] v3 sym_act
strat 0 poll 10 prec 0
23:11:45.351313 time.nist.gov.123 > matrisen.uio.no.123: [len=48] v3 sym_pas
strat 1 poll 10 prec 0 [tos 0x10]
23:12:04.610875 matrisen.uio.no.123 > time.windows.com.123: [len=48] v3 sym_act
strat 0 poll 10 prec 0
23:12:04.838483 time.windows.com.123 > matrisen.uio.no.123: [len=48] v3 server
strat 2 poll 15 prec 0
23:13:52.696358 matrisen.uio.no.123 > time.windows.com.123: [len=48] v3 sym_act
strat 0 poll 10 prec 0
23:13:52.923303 time.windows.com.123 > matrisen.uio.no.123: [len=48] v3 server
strat 2 poll 15 prec 0
Notice how all these servers (which are the default WinXP servers) respond with
"server", while my NTP v4 machine answered with sym_pas. Do version 3 servers
react differently than version 4 ?
I have tried to rule out potential errors in "tcpdump" so that these strange
happenings are not a result of a bug there, by using other packet sniffers and
by verifying the output of tcpdump with known data. Below is a transcript from a
friends NTP v4 (data.nosyko) server with my server (blekkulf). Here everything
seems fine with
tcpdump !!
=======================================
[root@blekkulf /root]# tcpdump port 123
Kernel filter, protocol ALL, TURBO mode (575 frames), datagram packet socket
tcpdump: listening on all devices
23:27:56.965702 eth0 < data.nosyko.no.ntp > blekkulf.ntp: v4 client strat 0 poll
6 prec -16 [tos 0x10]
23:27:56.966266 eth0 > blekkulf.ntp > data.nosyko.no.ntp: v4 server strat 3 poll
6 prec -18 (DF) [tos 0x10]
I picked some servers from http://www.eecis.udel.edu/~mills/ntp/clock1.htm and
tried them.
Here is the transcript .
=======================================
23:48:57.923758 matrisen.uio.no.123 > tictoc.tip.CSIRO.AU.123: [len=48] v3
sym_act strat 4 poll 10 prec -1
23:50:26.482083 matrisen.uio.no.123 > swisstime.ee.ethz.ch.123: [len=48] v3
sym_act strat 4 poll 10 prec -1
23:50:26.548151 swisstime.ee.ethz.ch.123 > matrisen.uio.no.123: [len=48] v3
sym_pas strat 1 poll 10 prec 0
Notice how matrisen , which is the WinXP machine now suddenly use strat 4(!)
(again violation RFC2030) and sym_act !!! I have no idea why !
Later I discovered this:
00:16:28.968100 matrisen.uio.no.123 > windows.microsoft.com.123: [len=48] v3
sym_act strat 2 poll 10 prec 0
[the windows.microsoft.com server never answered]
Stratum 2 !! If you synch with an unsecured stratum 3 server, Windows XP will
actually synchronize the server ?!
Well, there is a lot of raw data here, but here is the essence of it all:
I have tried to rule out any obvious mistakes from my side. By now, it seems to
me
that the Microsoft implementation of SNTP client in Windows XP is _very_
damaged.
If you want to see for yourself, download windump (or another sniffer)
Windump: http://netgroup-serv.polito.it/windump/install/bin/WinDump.exe
WinPcap (needed by windump):
http://netgroup-serv.polito.it/winpcap/install/default.htm
--
Johan Fredrik Ohman
Johan Fredrik Øhman
> Oh what a lovely security hole. The server operator has not heeded the
> advice in the documentation. That caution was in the NTPv3 documentation
> and NTPv4 documentation and in both late NTPv3 and all NTPv4 versions,
> authentication defaults <<enabled>>. Remember, this being said many
> times here, the only thing the authentication switch does is require
> authentication to mobilize broadcast or symmetric associations if
> enabled, or do this even without authentication if disabled.
Well, it's my server and it is used for experiment purposes mostly. That's why
the security might be "low".
> So, I wound up a non-WinXP client here in symmetric active mode and (at
> least) windows.Microsoft.com did <<not>> reply. At least they got that
> right.
But if their WindowsXP client uses symmetric active mode to synchronize with my
NTP server, then Windows XP can't synchronize with one of Microsofts own
servers. I have tested this, and yes, windows.microsoft.com does not work as a
server entry in "Win XP's Internet time" synchronization dialog.
> Thanks for the yuk. Bottom line: Why does WinXP send symmetric active
> packets? In general, that won't work. It has to send client packets. Can
> you verify your scenario and find out if WinXP ever sends other packet
> flavors?
Here follow a verification. Now I did the packet sniffing on my Windows XP
[root@blekkulf /root]# tcpdump port 123
Kernel filter, protocol ALL, TURBO mode (575 frames), datagram packet socket
tcpdump: listening on all devices
23:27:56.965702 eth0 < data.nosyko.no.ntp > blekkulf.ntp: v4 client strat 0 poll
6 prec -16 [tos 0x10]
23:27:56.966266 eth0 > blekkulf.ntp > data.nosyko.no.ntp: v4 server strat 3 poll
6 prec -18 (DF) [tos 0x10]
I picked some servers from http://www.eecis.udel.edu/~mills/ntp/clock1.htm and