Re: [sidr] time

[Randy Bush <[e-mail]>]

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

how about earlier than 2011?

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