With regards to the frequency with which relying parties fetch data from
the repository system (be that authoritative publication points or
caches operated by ISPs or RIRs), there appears to be a trade-off
between "max time to fix a problem" vs "work required by the repository
system and the relying parties". From this thread, it seems that there
isn't an obvious right answer with regards to how often relying parties
should query the repository system, but that there are risks associated
with queries that are too frequent or too infrequent.
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 <da...@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@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
