The list in section 1 does not appear to capture all the requirements as they've been given in discussions on the list. Specifically, what is not covered is:
1. Proving intent to advertise. Showing that the AS advertising a route to a peering AS intended to avertise the reachability information contained in the BGP update. 2. Proving the path of the update. It is not enough to merely show that a path exists; any security system must also show the actual path routing information has taken through the routing system. 3. Providing transitive trust. A network operator must not need to rely on the filters or policies of neighboring autonomous systems to show the path an update takes through the system, nor to prove the intent of prior autonomous systems to advertise reachability through their networks. These have all been clearly discussed on the list as motivations for the scheme adopted. There's a lot of 'we' in this doc, as well --I'm not certain that's good form for a draft? Finally, there doesn't seem to be a lot of justification around the length of the timer in an update (what's the impact on performance system wide, in terms of stability and route update intervals? Are these justifiable?), nor on why intervening AS' should not be allowed to include expiration times (why is a change in the AS path at an intervening AS treated differently than a change in the AS path at the originating AS?). Russ
signature.asc
Description: OpenPGP digital signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
