>> 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 ?
My argument isn't over the length of the timer, just that the timer needs to exist per hop, not just for the originator. > If 2 changes which IPs it has allocated to customers, then the RPKI > implements that by creating new and revoking old EE(s). So you would argue that each time you change connections, you should issue a new EE? Then why have the timer at all? > Or, of course, everybody could do it the old fashioned way, and filter > out routes with AS 3 in the path :-) Then what's the point of the signatures in the first place? Russ _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
