From: Larson, Chris (CLarson@usaid.gov)
Date: Fri Jun 27 2003 - 11:23:01 GMT-3
Actually, I found out you can use authentication on any or all NTP servers.
The server will send updates in plain text as well as md5. An authenticating
client will hash the plain text using its own key and compare the result to
the hashed value it received and if they match it is authenticated.
Clients who do not use authentication will recieve the plain text and the
hash and simply discard the hash.
> -----Original Message-----
> From: Elias Udechime [SMTP:euchime@yahoo.com]
> Sent: Friday, June 27, 2003 10:15 AM
> To: ccielab@groupstudy.com
> Cc: Larson, Chris
> Subject: RE: NTP
>
>
> I think you can if you design hierarchical stratum
> level to synchronize the time. Time is distributed
> through a hierarchy with each server adopting a
> stratum which indicates how far away from an external
> source of universal time.
>
> To avoid long-lived synchronization loops the number
> of strata should be limited to 15.
> In this hierarchy, clients are simply servers with no
> dependency, such as your IDS.
>
> Server looks for the datagram over for any special
> requests (some NTP servers exchange and decode
> encrypted "authentication" words, involving checks of
> private keys to "prove" that they are indeed the
> source of time, and not some devious hacker spoofing
> the server's network address).
>
> So you can implement authentication at one level and
> non authentication at another level while the primary
> external source remains the same.
>
> my 2 cents
>
> Elias
>
> --- "Larson, Chris" <CLarson@usaid.gov> wrote:
> > Along the lines of NTP. I am wondering if I can get
> > authenticated as well as
> > unauthenticated time from the same time source. In
> > other words, can I have
> > some client who use authentication against NTP
> > server updates and other
> > client that don't? It seems to me that I remember if
> > the server has a key,
> > all the clients will need the key.
> >
> > I am asking because we have a situation where we do
> > not use NTP
> > authentication for our devices but it appears the
> > IDS sensor (4210) requires
> > authentication if your going to use NTP as a time
> > source. I was thinking
> > either of a configuration that would allow some
> > clients authenticated and
> > some not OR a master that synchs with the current
> > master but provides
> > authentication to those clients who require it (the
> > sensors).
> >
> > Thoughts, comments possabilities?
> >
> >
> >
> > > -----Original Message-----
> > > From: ccie2be [SMTP:ccie2be@nyc.rr.com]
> > > Sent: Thursday, June 26, 2003 2:54 PM
> > > To: Group Study; Jay Hennigan
> > > Subject: Re: NTP
> > >
> > > Hey Jay,
> > >
> > > Thanks for your reply.
> > >
> > > A quick little config change on rtr-2 has proved
> > your suggestion correct.
> > > I'm going to play around with this some more to
> > see how much the
> > > difference
> > > in stratum needs to be for multiple ntp masters to
> > sync up properly, but
> > > thanks for sharing your thoughts with me. It did
> > the trick.
> > >
> > > BTW, in terms of NTP, to count the "hops", I would
> > count the number of NTP
> > > servers daisy chained to one another? For
> > example, given rtrs A, B, C,
> > > D,
> > > and E where E is configured to get ntp from C and
> > C is configured to get
> > > ntp
> > > from A and A is the master, router E considers
> > rtr A to be 2 hops aways?
> > > (Rtrs B and D just provide connectivity and aren't
> > ntp servers). Do have
> > > it
> > > right?
> > >
> > > Thanks again.
> > > ----- Original Message -----
> > > From: "Jay Hennigan" <jay@west.net>
> > > To: "ccie2be" <ccie2be@nyc.rr.com>
> > > Cc: "Group Study" <ccielab@groupstudy.com>
> > > Sent: Thursday, June 26, 2003 2:10 PM
> > > Subject: Re: NTP
> > >
> > >
> > > > On Thu, 26 Jun 2003, ccie2be wrote:
> > > >
> > > > > I have 2 2500's connected via ethernet and
> > they can ping each other's
> > > loopback
> > > > > and ethernet addresses.
> > > > >
> > > > > This is the NTP config of each:
> > > > >
> > > > > RTR-1
> > > > >
> > > > > ntp master 6
> > > > > ntp server 192.168.2.2 source lo0
> > > > >
> > > > >
> > > > > RTR-2
> > > > >
> > > > > ntp master 7
> > > > > ntp server 192.168.1.1 source lo0
> > > > >
> > > > >
> > > > > Both routers have there system clocks set to
> > different dates and
> > > times.
> > > > >
> > > > > When I do a "show ntp asso det" on rtr-2, it
> > shows
> > > > >
> > > > > 192.168.1.1 configured, insane, invalid...
> > > > >
> > > > > Why is this and what should I do about it?
> > > >
> > > > I haven't tested this in the lab, but a
> > thought...
> > > >
> > > > Each "hop" increases the stratum by one. If r2
> > is a master at stratum
> > > > 7 and r1 has a widely varying time and reports
> > itself as stratum 6, then
> > > > r2 has two sources that are effectively stratum
> > 7. As it is itself a
> > > > master, it will reject the data from the peer at
> > the same stratum as
> > > > "insane" if the time is different.
> > > >
> > > > What is the behavior if the strata differ by 2
> > or more? Change r1 to
> > > > master at stratum 5 for example.
> > > >
> > > >
> > > > --
> > > > Jay Hennigan - CCIE #7880 - Network
> > Administration - jay@west.net
> > > > WestNet: Connecting you to the planet. 805
> > 884-6323 WB6RDV
> > > > NetLojix Communications, Inc. -
> > http://www.netlojix.com/
> > >
> > >
> > >
> >
> _______________________________________________________________________
> > > You are subscribed to the GroupStudy.com CCIE R&S
> > Discussion Group.
> > >
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> >
> _______________________________________________________________________
> > You are subscribed to the GroupStudy.com CCIE R&S
> > Discussion Group.
> >
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
>
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
This archive was generated by hypermail 2.1.4 : Fri Jul 04 2003 - 11:11:12 GMT-3