Subject: [sidr] time

From: Randy Bush <[email-masked]>
Date: Tue, 26 Apr 2011 11:55:07 +0900

how about the following in draft-ymbk-bgpsec-ops?

   As a router must evaluate certificates and ROAs which are time
   dependent, routers' clocks MUST be correct to a tolerance of
   approximately an hour.

   If a router believes it has bogus clock, e.g. if it is 1970, 2005, or
   similar, it SHOULD NOT attempt to validate incoming updates.

   Severs SHOULD provide time service, such as NTP [RFC5905], to client
   routers.

randy

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 25 Apr 2011 23:13:02 -0400

It's not clear to me what "1970, 2005, or similar" means?  Numbers with four digits?  Five syllables*?

Maybe it would be clearer to use some heuristic based on the set of dates on certs/ROAs?  Based on the assumption that the ROA issuers of the world will be reasonably well in sync with real time. 

If you're more than a few years off from the latest ROA issuance dates, then you're probably bogus.  Say, take the average issuance of the most recent 100 ROAs and see if you're more than 5 years off.

* "Two thousand *and* five"

On Apr 25, 2011, at 10:55 PM, Randy Bush wrote:

> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Randy Bush <[email-masked]>
Date: Tue, 26 Apr 2011 12:16:56 +0900

> It's not clear to me what "1970, 2005, or similar" means?

you do not write router code.  those are the most common "clock is not
set" years.  even unix hackers know the first.

> If you're more than a few years off from the latest ROA issuance
> dates, then you're probably bogus.  Say, take the average issuance of
> the most recent 100 ROAs and see if you're more than 5 years off.

a good example of how complexity opens attack vectors

randy

---

From: Terry Manderson <[email-masked]>
Date: Mon, 25 Apr 2011 20:31:18 -0700

>    dependent, routers' clocks MUST be correct to a tolerance of

So what you are allowing here is a clock signing/validation drift of +/- 60
minutes. yeah?

>    similar, it SHOULD NOT attempt to validate incoming updates.

My guess here is you mean that the clock hasn't been set, based on your
example. Might be best just to say that if a clock isn't stratum 1 or 2 (or
something) NTP sourced than validation should be postponed.

Otherwise I find it difficult to consume how a router itself will know if
it's clock has a drift of over an hour. especially if its NTP source is
wrong.

>    Severs SHOULD provide time service, such as NTP [RFC5905], to client

Does this need to be said if you are making a MUST statement for NTP?

Terry

---

From: Randy Bush <[email-masked]>
Date: Tue, 26 Apr 2011 14:30:18 +0900

> So what you are allowing here is a clock signing/validation drift of
> +/- 60 minutes. yeah?

good guess :)

>>    If a router believes it has bogus clock, e.g. if it is 1970, 2005,
>>    or similar, it SHOULD NOT attempt to validate incoming updates.
> My guess here is you mean that the clock hasn't been set, based on
> your example. Might be best just to say that if a clock isn't stratum
> 1 or 2 (or something) NTP sourced than validation should be postponed.

few routers are strat 1 or 2, and i do not think it wise to go to such
level of detail.  to stay within one hour, strat 42 would probably be
fine.

> Otherwise I find it difficult to consume how a router itself will know
> if it's clock has a drift of over an hour.

i suggested two well-known ways to detect an unitialized clock

> especially if its NTP source is wrong.

perhaps the router should read the common advice to ntp clients?  like
not relying on a single source, etc.

> Does this need to be said if you are making a MUST statement for NTP?

first, i made no such statement.  second, this statement is about
servers, not about routers.  third, i obviously thought it a good idea
for servers to offer this service in addition to rpki data.  but it is
intentionally a should not a must.

so, i have hacked

   If a router has reason to believe its clock is seriouly incorrect, it
   SHOULD NOT attempt to validate incoming updates.  It SHOULD defer
   validation until it believes it is within reasonable time tolerance.

   Servers SHOULD provide time service, such as NTP [RFC5905], to client
   routers.

randy

---

From: Randy Bush <[email-masked]>
Date: Tue, 26 Apr 2011 14:37:36 +0900

>> So what you are allowing here is a clock signing/validation drift of

actually, rereading and feeling pedantic, +- 120 min.  i.e. the sending
router could be slow 60 minutes and the receiving router fast 60
minutes.

randy

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 26 Apr 2011 01:40:11 -0400

(hate to jump into the fray, but...)

>   dependent, routers' clocks MUST be correct to a tolerance of

does there need to be a 'why' for the 'approximately an hour'? (like:
"since granularity of cert time-to-live's is 30 mins on the minimum
side" ... wordsmith or whatever as appropriate)

>   If a router has reason to believe its clock is seriouly incorrect, it

'has reason to believe' ... seems hard to do, if you are insane, how
do you know? I don't know how a router would know this, or determine
it.. unless some protocol it's speaking gives it time-hints.

Would it be appropriate to hack in a timehack to the rkpi-rtr
protocol? (featurecreeper!)

>   Servers SHOULD provide time service, such as NTP [RFC5905], to client

it seems that 'SHOULD' here may lead into forcing (or appearing to
force) ops to do something they don't already do (or perhaps wouldn't
want to do... jigsaw with logs is fun!), maybe that's what's gotten at
least terry's attention?

-Chris

---

From: Randy Bush <[email-masked]>
Date: Tue, 26 Apr 2011 14:45:56 +0900

> side" ... wordsmith or whatever as appropriate)

because rpki processing cycles are likely to be of that tolerance.  but
do we really want to go down this path?

> 'has reason to believe' ... seems hard to do

i suggested two well-know ways and got nit picked within 42 seconds.  i
would be happy to put the examples, 1970 and 2005, back.  but they are
just lint attractors.

> protocol? (featurecreeper!)

no.  we will not reinvent time synchronization.

> force) 

SHOULD != MUST

randy

---

From: Jac Kloots <[email-masked]>
Date: Tue, 26 Apr 2011 09:25:11 +0200 (CEST)

Randy, Others,

It doesn't seem to be a new problem to me. How is this time problem 
evaluated in the current off-line cache software?

Why think of another approach if the only difference is the device doing the 
validation of certs and ROA's?

Regards,

Jac

-- 
Jac Kloots
Network Services
SURFnet bv

---

From: Randy Bush <[email-masked]>
Date: Tue, 26 Apr 2011 16:42:22 +0900

> evaluated in the current off-line cache software?

from draft-ietf-sidr-rpki-rtr

   As a cache server must evaluate certificates and ROAs which are time
   dependent, servers' clocks MUST be correct to a tolerance of
   approximately an hour.

> Why think of another approach if the only difference is the device
> doing the validation of certs and ROA's?

same approach.  just trying to throw in a bit more detail for two
reasons

  o brian beat me up

  o in bgpsec, the router might not validate but still sign and pass on.
    it is signing to attest to "i saw this" not that it believed it.
    subtle.

randy

---

From: Jac Kloots <[email-masked]>
Date: Tue, 26 Apr 2011 10:53:45 +0200 (CEST)

Randy,

> same approach.  just trying to throw in a bit more detail for two

If it is the same approach, why detail this more? It is a MUST time settings 
are correct, and let router vendors take care of the 'tolerance 
of approximately an hour' implementation.

Beside this, I just read the draft-ymbk-bgpsec-ops draft and the detail 
you're now trying to get into the document seems a bit odd to me.

I think the time-issues should be noted where validation is described and 
that operational considerations aren't the right place for this.

Jac

-- 
Jac Kloots
Network Services
SURFnet bv

---

From: Randy Bush <[email-masked]>
Date: Tue, 26 Apr 2011 19:41:01 +0900

> If it is the same approach, why detail this more? It is a MUST time
> settings are correct, and let router vendors take care of the
> 'tolerance of approximately an hour' implementation.
> 
> Beside this, I just read the draft-ymbk-bgpsec-ops draft and the
> detail you're now trying to get into the document seems a bit odd to
> me.
> 
> I think the time-issues should be noted where validation is described
> and that operational considerations aren't the right place for this.

hi jac,

i am not sure i am really getting your point(s), so i may be way off
here.  but let me give it a go.

we're talking two very different protocol/security/document sets here.

  o draft-ietf-sidr-rpki-rtr is for origin validation, and goes with
    draft-ietf-sidr-origin-ops, and the router never sees certs or
    anything else which requires the router to know anything about time.
    it's all in the cache servers which feed only highly digested data
    to the routers.

  o draft-ymbk-bgpsec-ops goes with draft-lepinski-bgpsec-overview and
    draft-lepinski-bgpsec-protocol, where certs et alia go all the way
    to the routers, and hence the routers need to know time.  and brian
    questioned if and how they might be trusted to know something about
    what time it is.

while i could imagine a doc which covers operational considerations for
anything validating rpki data, this would not cover that bgpsec has
signatures with expiry times in the bgp messages, which are outside of
the rpki.

i guess we could ask matt to go into more detail about validation and
time in draft-lepinski-bgpsec-protocol.  when we designed the bgpsec
docco set, i got the tasks of this level of dregs.  and that would not
cover slack in validation of the rpki data.

if you have the stomach to read the idr list, i doubt you really want to
leave too much leeway for misinterpretation by bgp implementers.  they
have the grand prize for twisty minded nit pickers.  we are amateurs.

randy

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Tue, 26 Apr 2011 13:53:37 +0000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Randy Bush
Sent: Tuesday, April 26, 2011 1:46 AM
To: Christopher Morrow
Cc: sidr wg list
Subject: Re: [sidr] time

> 'has reason to believe' ... seems hard to do

i suggested two well-know ways and got nit picked within 42 seconds.  i would be happy to put the examples, 1970 and 2005, back.
but they are just lint attractors.

[WEG] I think you can make the implementation recommendation for defining "seriously incorrect" without being specific - that is,
"if current clock value is near the known default 'unset clock value' for the particular implementation..." Most people will infer
from that, "if unix && time = 1970, then BORKED()" and it leaves the implementation to the vendor, who will know their own default
time value. All you'd need to do is define what value of near default is considered broken.

[snip from another msg]

[WEG] I'm curious what the attack vector for the proposed solution of using contextual clues to determine that your clock is wrong
would be. If you're saying "look at NNN updates and if your clock is more than $timevalue off from the dates, your clock is wrong"
Shouldn't the risk of someone intentionally sending updates with weird timestamps to trick the router into thinking that its clock
is wrong and cease validation be dramatically reduced with an acceptable sample size?

But beyond that, aren't any of these proposals simply attempts at over-complicating things? I still say we should just require NTP
and be done with it. Then you could say, if you lose connection with an NTP for more than $time, you MUST cease validation until NTP
is restored. You could make the value appropriately generous, and then vendors could allow a knob to reduce the value for people who
are confident in their NTP config and connectivity.

Wes George

---

From: Randy Bush <[email-masked]>
Date: Tue, 26 Apr 2011 23:11:09 +0900

> All you'd need to do is define what value of near default is
> considered broken.

how about earlier than 2011?

> [WEG] I'm curious what the attack vector for the proposed solution of
> using contextual clues to determine that your clock is wrong would
> be. If you're saying "look at NNN updates and if your clock is more
> than $timevalue off from the dates, your clock is wrong" Shouldn't the
> risk of someone intentionally sending updates with weird timestamps to
> trick the router into thinking that its clock is wrong and cease
> validation be dramatically reduced with an acceptable sample size?

more complexity

> But beyond that, aren't any of these proposals simply attempts at
> over-complicating things? I still say we should just require NTP and
> be done with it. Then you could say, if you lose connection with an
> NTP for more than $time, you MUST cease validation until NTP is
> restored. You could make the value appropriately generous, and then
> vendors could allow a knob to reduce the value for people who are
> confident in their NTP config and connectivity.

i am not sure one can assume universal ntp availability.  but your
particular phrasing does not take start-up into account.  not a big
problem, but more word nitpicking to be done.

randy