Re: [sidr] WGLC for draft-ietf-sidr-rpki-rtr-rfc6810-bis-03

[Rob Austein <[e-mail]>]

[More old WGLC comments]

At Tue, 17 Mar 2015 14:29:34 -0400, George, Wes wrote:
> 
> Section 6 Expire interval - this seems out of step with the way that we've
> done most things in RPKI, i.e. what to do with the information provided is
> usually thought of as a matter of local policy. I realize that there is
> increasing risk to keeping the data beyond the expiry time as it grows
> more stale, but there isn't much justification for why this MUST NOT is
> present. I think that perhaps the tradeoff between staleness and
> everything failing back to unknown status is something that the operator
> needs to weigh themselves. We could provide guidance that [MUST/SHOULD]
> NOT keep data from a certain cache beyond expiry time *if* another cache
> is available, but acknowledge that in some cases stale info may be more
> desirable than nothing at all (unless that's not actually true and I'm
> missing something...) This is discussed in the failover scenarios in the
> bottom of section 10 (only keep data if you don't have a full set from
> another cache) but figured I'd mention it in case we think there's some
> tweaks necessary in the section 6 text.

The basic problem is that the router does not have the data necessary
to make an informed decision.  We've stripped all of the timestamps
off of the public data (certificate expiration, CRL and manifest
nextUpdate, etc), and some of the information (cache's own interval
for polling the global RPKI) is not public.

I could (maybe, sort of) see an argument for downgrading MUST NOT here
to SHOULD NOT, but the intent here is to send a (very) strong signal
to the router that once it's past the expiration time, it would be
better (in the opinion of the cache operator) for the router to let
everything go to unknown than to keep using data this stale.

Keep in mind that the security model for this protocol pretty much
assumes that the router and cache are within the same organization.
So it's your cache telling your router what to do, and if you need a
local policy override, sure, go ahead, configure it -- on your cache.

> Also -
> Since we say in section 10 that it is permissible to hold data from
> multiple caches, the doc appears to be missing guidance on what the router
> side of RPKI-router should do in the case where there are multiple caches
> that disagree with one another. It does say MUST NOT distinguish between
> data sources when validating, but that may not cover this scenario. This
> may be as simple as recommending that in the case where data from multiple
> caches is held and specific entries conflict with one another, there
> SHOULD be an odd number of caches so that there is basis for comparison to
> determine which cache is out of sync or providing incorrect info. (i.e.
> Have 3 so that you can go with the 2/3 that agree)

With respect, you may be over-thinking this.  The whole point of the
protocol is to make the router's job simpler, not harder.  Having the
router try to second guess the caches defeats that purpose.  Pick a
cache and use it; if it breaks, pick another one.

There's is a role for some kind of monitoring tool here, operating in
the router protocol role talking to all of your caches to see what's
up, and perhaps even whacking things (cache server, NOC monkey,
whatever works in your shop) as necessary to fix problems, but this
seems like a job for a NOC tool running on a cheap VM, not code in the
slow path on every one of your expensive routers.