-----Original Message----- From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of Randy Bush Sent: Tuesday, April 26, 2011 1:46 AM To: Christopher Morrow Cc: sidr wg list Subject: Re: [sidr] time
>> If a router has reason to believe its clock is seriouly incorrect, >> it > '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] > 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? 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
