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