>> The list in section 1 does not appear to capture all the requirements as >> they've been given in discussions on the list. > > This is a design rationale document. > It merely describes some of the details behind the design decisions. > As you know, requirements are documented in draft-ietf-sidr-bgpsec-reqs.
I would expect it, however, to detail the primary reasons for making such decisions. The ones I've outlined are, based on the list discussions, the primary reasons. >> nor on why intervening AS' >> should not be allowed to include expiration times > > It is simply not needed to reduce the replay attack window. 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. Russ _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
