> Kerberos does not assume clock synchronization.
> Kerberos requires reasonable clock synchronization.
To be more precise, Kerberos requires those systems
for which it is providing (authentication) services
to agree, within a configured (usually) 5-10 minutes.
There is no requirement that those
On Thu, 20 Sep 2007 14:41:16 -0500
"Brandon Galbraith" <[EMAIL PROTECTED]> wrote:
> On 9/20/07, James R. Cutler <[EMAIL PROTECTED]> wrote:
> >
> > Kerberos does not assume clock synchronization.
> > Kerberos requires reasonable clock synchronization.
> > And, as near as I can tell, clock synchro
On 9/20/07, James R. Cutler <[EMAIL PROTECTED]> wrote:
>
> Kerberos does not assume clock synchronization.
> Kerberos requires reasonable clock synchronization.
> And, as near as I can tell, clock synchronization is not part of the
> Kerberos protocol.
>
> Kick me if I err in this.
>
> Cut
Kerberos does not assume clock synchronization.
Kerberos requires reasonable clock synchronization.
And, as near as I can tell, clock synchronization is not part of the
Kerberos protocol.
Kick me if I err in this.
Cutler
At 9/19/2007 08:14 AM -0400, Jeff McAdams wrote:
Stephen Sprunk
Stephen Sprunk wrote:
>> ... is it reasonable to assume clock synchronization in the rest
>> of our design?
> In general, it is not. I can't think of any existing protocol that
> does, actually.
Kerberos.
--
Jeff McAdams
"They that can give up essential liberty to obtain a
little temporary safe
top posting to keep you alert!
there are folks who syncronize clocks so that logs make sense.
and those that do, tend to pick a common TZ... there is nothing
like syncronizing logs from routers in Nepal, India, China, and LA
UTC can be your friend...
wrt acces to clock source - i'd be h
Thus spake "Xin Liu" <[EMAIL PROTECTED]>
Ideally, yes, a protocol should not rely on clock synchronization
at all. However, to ensure freshness of messages, we don't have
many choices, and clock synchronization seems to be the least
painful one. So we asked about router clocks on the current
In
Thus spake "Xin Liu" <[EMAIL PROTECTED]>
Sorry for the confusion. Let me clarify.
We are interested in a number of questions:
1. Can we assume loosely synchronized router clocks in the
Internet, or we have to make absolutely no assumption about
router clocks at all?
That assumption is _genera
> From [EMAIL PROTECTED] Tue Sep 18 10:57:15 2007
> Date: Tue, 18 Sep 2007 08:55:19 -0700
> From: "Xin Liu" <[EMAIL PROTECTED]>
> To: "Bora Akyol" <[EMAIL PROTECTED]>
> Subject: Re: Question on Loosely Synchronized Router Clocks
> Cc: nanog@m
On 9/18/07, Xin Liu <[EMAIL PROTECTED]> wrote:
> Ideally, yes, a protocol should not rely on clock synchronization at
> all. However, to ensure freshness of messages, we don't have many
> choices, and clock synchronization seems to be the least painful one.
Xin,
Depending on the character of the
On Tue, 18 Sep 2007 13:51:55 -0400
[EMAIL PROTECTED] wrote:
> On Tue, 18 Sep 2007 09:27:32 PDT, Bora Akyol said:
> >
> > It is not dependent on time. You'd like a protocol to be self
> > sufficient if at all possible.
> >
> > Moving the vulnerability of one protocol to another is not highly
> >
On Tue, 18 Sep 2007 09:27:32 PDT, Bora Akyol said:
>
> It is not dependent on time. You'd like a protocol to be self sufficient if
> at all possible.
>
> Moving the vulnerability of one protocol to another is not highly desirable
> in general.
The interesting failure mode is, of course, what hap
It is not dependent on time. You'd like a protocol to be self sufficient if
at all possible.
Moving the vulnerability of one protocol to another is not highly desirable
in general.
Looking forward to reading your research results when available.
Regards
Bora
On 9/18/07 9:25 AM, "Xin Liu" <[
Sequence number has its own problems. Message sources have to remember
sequence numbers even when it reboots or crashes. Message verifiers
have to keep states too, and whenever the states go wrong due to
attack or random errors, it's hard to detect and fix them.
Best
Regards,
Xin Liu
On 9/18/07
On Tue, Sep 18, 2007, Xin Liu wrote:
>
> Ideally, yes, a protocol should not rely on clock synchronization at
> all. However, to ensure freshness of messages, we don't have many
> choices, and clock synchronization seems to be the least painful one.
> So we asked about router clocks on the curren
You can check freshness of a message by means of sequence numbers, no?
Bora
On 9/18/07 8:55 AM, "Xin Liu" <[EMAIL PROTECTED]> wrote:
> Ideally, yes, a protocol should not rely on clock synchronization at
> all. However, to ensure freshness of messages, we don't have many
> choices, and clock
Ideally, yes, a protocol should not rely on clock synchronization at
all. However, to ensure freshness of messages, we don't have many
choices, and clock synchronization seems to be the least painful one.
So we asked about router clocks on the current Internet. If normally
router clocks are synchr
"Xin Liu" <[EMAIL PROTECTED]> writes:
> Sorry for the confusion. Let me clarify.
>
> We are interested in a number of questions:
> 1. Can we assume loosely synchronized router clocks in the Internet,
> or we have to make absolutely no assumption about router clocks at
> all?
Make no assumption.
Xin Liu wrote:
1. Can we assume loosely synchronized router clocks in the Internet,
or we have to make absolutely no assumption about router clocks at
all?
Make no assumption. I've seen plenty of routers who aren't even on the
correct year. Routers can work just fine while thinking its 1999
IMHO:
What ever solution you end up proposing should able to handle (3) and should
work with arbitrary boundaries for (1) & (2).
We don't want to add another failure mode to the network that depends on
time synchronization.
You don't want to shift the problem from BGP to NTP.
Regards
Bora
Sorry for the confusion. Let me clarify.
We are interested in a number of questions:
1. Can we assume loosely synchronized router clocks in the Internet,
or we have to make absolutely no assumption about router clocks at
all?
2. If the router clocks are indeed loosely synchronized, what is the
gr
> Date: Mon, 17 Sep 2007 18:22:12 -0400
> From: Deepak Jain <[EMAIL PROTECTED]>
>
>
>
> [EMAIL PROTECTED] wrote:
> > On Mon, 17 Sep 2007 14:28:45 PDT, Kevin Oberman said:
> >> I had a router that lost it's NTP servers and was off by about 20
> >> minutes. The only obvious problem was the timesta
[EMAIL PROTECTED] wrote:
On Mon, 17 Sep 2007 14:28:45 PDT, Kevin Oberman said:
I had a router that lost it's NTP servers and was off by about 20
minutes. The only obvious problem was the timestamps in syslog. (That's
what alarmed to cause us to notice and fix it.)
Trying to correlate logfil
i conversed offline with the OP. he was reading a sigcomm research
paper and confusing it with the internet.
randy
On Mon, 17 Sep 2007 14:28:45 PDT, Kevin Oberman said:
> I had a router that lost it's NTP servers and was off by about 20
> minutes. The only obvious problem was the timestamps in syslog. (That's
> what alarmed to cause us to notice and fix it.)
Trying to correlate logfiles with more than a severa
> Date: Mon, 17 Sep 2007 14:03:33 -0700
> From: "Xin Liu" <[EMAIL PROTECTED]>
> Sender: [EMAIL PROTECTED]
>
>
> Dear Nanogers,
>
> We are a bunch of academic researchers interested in Internet
> security. We notice that some research papers require that BGP router
> clocks be globally synchroniz
Agreed.
That does seem strange..
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Randy Bush
Sent: Monday, September 17, 2007 2:11 PM
To: Xin Liu
Cc: nanog@merit.edu
Subject: Re: Question on Loosely Synchronized Router Clocks
Xin Liu wrote:
> I
Dear Nanogers,
We are a bunch of academic researchers interested in Internet
security. We notice that some research papers require that BGP router
clocks be globally synchronized to a 5-minute granularity. If a
router's clock is off by more than 5 minutes, it cannot forward
packets, but there's n
Xin Liu wrote:
> If a router's clock is off by more than 5 minutes, it cannot forward
> packets
this is false. i suggest you do more reading.
randy
29 matches
Mail list logo
