Hi Russ, Thanks for your comments/observations. Please see my comments inline.
Sriram >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. >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. These are requirements related questions which pertain to draft-ietf-sidr-bgpsec-reqs. I think Randy may like to respond to these. >There's a lot of 'we' in this doc, as well --I'm not certain that's good >form for a draft? I could use the passive form like “It was decided that …” etc. everywhere in the doc. I’m not sure that is necessarily better. But I will take your suggestion into consideration. >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?), This is an ongoing discussion. But please see Section 3.2.2 (2nd, 3rd, 4th paragraphs). http://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-00#page-10 Also see Section 3.4. http://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-00#section-3.4 Sharon Goldberg and I have begun doing detailed modeling of the BGPSEC route-processor workload to quantify the performance metrics you have mentioned. We hope to report results in the near future. >nor on why intervening AS' >should not be allowed to include expiration times It is simply not needed to reduce the replay attack window. It is sufficient that the origin AS inserts the Expire Time, and all other ASes in the AS path sign that info as they forward the route. Please see Section 3.2.2, 1st paragraph. http://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-00#page-10 > (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?). In what way do you think they are treated differently? If the origin AS announces to a different neighbor, that is just the same as if an AS three hops down makes a different choice. Again the discussion in Section 3.2.2 (1st para) can be helpful here. Sriram _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
