Windows Time with NTPv4 - NTP

This is a discussion on Windows Time with NTPv4 - NTP ; 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 ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 30 of 30

Thread: Windows Time with NTPv4

  1. Re: Windows Time with NTPv4

    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 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:

    --- -----
    [...] With the authentication bits set as suggested, only properly
    authenticated peers can become the synchronization source.
    --- -----

    [...]
    >> 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.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  2. Re: Windows Time with NTPv4

    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 didn't allow one to create
    peers without authentication, but rather treated such an attempt as
    actually creating a simple client relationship.

  3. Re: Windows Time with NTPv4

    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 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.


    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.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  4. Re: Windows Time with NTPv4

    On Mar 17, 5:17 am, David Woolley
    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).

  5. Re: Windows Time with NTPv4

    On Mar 16, 1:00*pm, ma...@ntp.isc.org (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 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?

  6. Re: Windows Time with NTPv4

    Ryan Malayter wrote:
    > On Mar 16, 1:00 pm, ma...@ntp.isc.org (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 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.

    Danny

  7. Re: Windows Time with NTPv4

    On Mar 22, 10:38*pm, ma...@ntp.isc.org (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-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?

  8. Re: Windows Time with NTPv4

    Ryan Malayter wrote:
    > On Mar 22, 10:38 pm, ma...@ntp.isc.org (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-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?


    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

  9. Re: Windows Time with NTPv4

    On 2008-03-16, Danny Mayer 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 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
    NTP Public Services Project - http://support.ntp.org/

  10. Re: Windows Time with NTPv4

    >> 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 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.

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2