>> 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.
NTP is a time pulling protocol. Peers make use of the time on the other
peer as one term in the estimation o
On 2008-03-16, Danny Mayer <[EMAIL PROTECTED]> wrote:
> 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 N
Ryan Malayter wrote:
> On Mar 22, 10:38 pm, [EMAIL PROTECTED] (Danny Mayer) wrote:
>>> 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 syste
On Mar 22, 10:38 pm, [EMAIL PROTECTED] (Danny Mayer) wrote:
> > 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-
Ryan Malayter wrote:
> On Mar 16, 1:00 pm, [EMAIL PROTECTED] (Danny Mayer) wrote:
>
>> 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 no
On Mar 16, 1:00 pm, [EMAIL PROTECTED] (Danny Mayer) wrote:
> 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
On Mar 17, 5:17 am, David Woolley
<[EMAIL PROTECTED]> 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
David Woolley wrote:
> Martin Burnicki wrote:
>
>> 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 impressio
Martin Burnicki wrote:
> 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
Danny Mayer wrote:
> 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
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 a
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
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
Ryan Malayter wrote:
> On Mar 13, 3:56 am, Martin Burnicki <[EMAIL PROTECTED]>
> 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 c
On Mar 13, 3:56 am, Martin Burnicki <[EMAIL PROTECTED]>
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
On Mar 13, 3:56 am, Martin Burnicki <[EMAIL PROTECTED]>
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"
On Mar 12, 9:23 am, "David L. Mills" <[EMAIL PROTECTED]> 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
_
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 h
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 th
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 an
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
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
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 d
On Mar 10, 10:53 am, "David L. Mills" <[EMAIL PROTECTED]> wrote:
> 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 fi
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
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 plugg
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
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
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
>
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, th
30 matches
Mail list logo
