>>    As a router must evaluate certificates and ROAs which are time
>>    dependent, routers' clocks MUST be correct to a tolerance of
>>    approximately an hour.
> 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.

>>    Severs SHOULD provide time service, such as NTP [RFC5905], to client
>>    routers.
> 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

   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 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
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Reply via email to