> >>> e.g., if 2 signs with a time and 3 signs with a time, 3 can still replay > >>> within 2's window, which one presumes is about as wide as 1's window. > >>> no gain, non-trivial pain. > >> Because 2 would know its local conditions, and may set the timer > >> shorter. > > > > except 2 had already disconnected from 3. way too much noise for too > > little gain. > > No --if 2 knows the situation with 3 is problematic, it can reduce the > timer on that path.
The problem I see with this is as follows. If 2 knows the situation with 3 is problematic, then why would it still send updates to 3? Why would it not disconnect with 3 rather than reduce the timer? Also, it does not make sense for 2 to set a lower timer value (than that of 1) prior to any hunch or knowledge that 3 is bad. Presumably, 2 had already sent some updates to 3 prior to knowing that 3 has gone bad (or is suspicious). There is nothing 2 can do about those previous updates even if it has the ability to adjust its own timer value on subsequent updates. Once that hunch sets in, then why not just disconnect with 3? AS-1 anyway was prepared to live with replay possibility for the period of its timer when it sent an update in the first place. So why should 2 try to be extra helpful with manipulation of timers when it really can't. I think all 2 should do to help is to forward updates only to 4 (and disconnect from 3) from the moment it knows 3 has gone bad or suspicious. We can presume that 1 chose its timer value with some prudence, and knows to accept the consequences of it. Sriram > > What you're saying is that the originator should control the rate at > which connectivity and policy should be allowed to change farther down > the graph, because, well, it's too much trouble to do otherwise. What > I'm saying is this is an unacceptable tradeoff --if the point is to > provide security, then provide security at every hop. > > Russ _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
