Russ White wrote (on Wed 06-Jul-2011 at 12:11 +0100): .... > I don't see how this is true. For instance: > > +--3--+ > 1--2 5 > +--4--+ > > Where 1 is originating a route towards 2, and 2 towards 3 and 4. If > the link between 2 and 3 fails, or 2 changes its policy, it must > wait the duration of 1's timer before being assured 3 cannot > continue to advertise the route. From 2's perspective, it has no > ability to control the speed at which it can effectively implement > policy or prevent replay attacks. > > This is unacceptable. The timer must be per hop.
How short would the timers have to be to cope with link failures ? In any case, it seems to me that problems only arise if 3 turns out to be a Bad Person. In which case, no matter what any validity timers say, the objective should be to allow routes to be rapidly withdrawn ? Each AS announcing routes to 3 gets to make up their own minds about 3's bona fides which will have its own latency, but having made a decision, having to wait for some timer to expire before being able to act will seem like a failure ? If 2 changes which IPs it has allocated to customers, then the RPKI implements that by creating new and revoking old EE(s). If 2 changes which ASes it announces routes to, presumably it revokes the EE(s) associated with the path signatures it now repudiates. And the back-channel through the RPKI will update all interested routers, and any stale routes will be swept away ? Of course, 2 must first re-announce everything that currently uses the to-be-updated-keys to every other peer, and wait for those announcements to be propagated. Can this be right ? Mind you, what if: +--3--+ 1--2 | 5 +--4--+ In which case, if 4 does not agree with 2's assessment of 3's character, then 2 is estuffe if 4 announces its routes to 3, and 5 thinks that 3's price for transit is just wonderful, and 3 is a customer of 4 (which might affect its judgement, of course). On the other hand, if all parties suddenly realise that 3 is Wicked, then there will be a sudden rush of new EEs and every route including 3 will be withdrawn, *and* every related route *not* including 3 will have to be re-announced and have propagated across the BGP mesh, *before* EEs are updated ? Or, of course, everybody could do it the old fashioned way, and filter out routes with AS 3 in the path :-) Chris _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
