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