 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
To me, it seems that the best way to address this problem is to publish an "operational practices" document of some sort that documents this (and other) operational concerns and recommends practices to mitigate such risks. [That is, Sandy's (b) option].
With regards to the architecture document (which I would very much like to see leave the working group in near future), I believe the best way forward is for the architecture document to be silent on this issue. For example, consider the following text for Section 6 (last paragraph on page 15 of the arch-09):
"Note that since relying parties will perform these operations regularly, it is more efficient for the relying party to request from the repository system only those objects that have changed since the relying party last updated its local cache. A relying party shall choose the frequency with which it downloads and validates updates from the repository system."
- Matt Lepinski Sandra Murphy wrote:
I can understand these concerns. Would you rather see the wg try: (a) concentrated redesign (to what, I have no idea)(b) operational guidance to operators of how to manage this risk - get new certs out <inserttimeframe> before the route that relies on it, etc. (There's already been discussion of an operational use document.)(c) create a way to carry info inband for emergencies (transitively - inducing work even on those who do not yet understand during initial deployment).Which of these (or something else) is the right wg direction, in your mind?--Sandy On Sat, 31 Oct 2009, Jared Mauch wrote:On Oct 31, 2009, at 10:07 AM, Danny McPherson <danny at tcb.net> wrote:One might suspect there are some things we can learn from this: http://tools.ietf.org/html/rfc4641 In particular, when *contrasting* even initial operational practices with preceding recommendations made in theoretical environments, a disparity usually emerges. I share concerns about frequency of publication and fetching functions. In particular, this was one of the larger reasons why folks stopped using IRR-based prefix lists in practice. It's a real PITA when intermediate ASes haven't updated policies for newly announced prefixes in a stateful protocol such as BGP. The originator announces the route, the route is dropped by peers because it's not permitted in the import policy, then the policy is updated eventually after corresponding IRR objects were fetched and the route is now permitted in policy, but stateful BGP doesn't reannounce the route, so the route had to be "bounced" somehow along the path, or at the origin, or a session reset to trigger a new update once the policy has been updated. Of course, we have BGP route refresh today, and implementations arguably should store an "invalid" route in an Adj-RIB-In and denote as such - but that does introduce cost (and a potential attack vector) as well. As Randy pointed out, and Curtis and I have stated (and lived firsthand together :-/) many times, the ripple effects associated with disjoint and autonomous application of policy derived from IRR (or RPKI) like systems are quite an operations nightmare in practice, and should be given heavy consideration here.I certainly echo these comments and concerns. - Jared _______________________________________________ sidr mailing list sidr at ietf.org https://www.ietf.org/mailman/listinfo/sidr_______________________________________________ sidr mailing list sidr at ietf.org https://www.ietf.org/mailman/listinfo/sidr