However, the concerns I raised during WGLC in
http://www.ietf.org/mail-archive/web/sidr/current/msg05010.html
regarding the ambiguity of some of the guidance regarding location of
RPKI caches ("close") in section 3 still have not been addressed. IMO
if it is important enough to discuss proximity, it is important enough
to devote some words to explaining the rationale for that
recommendation so that operators can make an informed design decision.
hey, thanks for caring and reviewing
i think the two paragraphs you would like to see improved are
As RPKI-based origin validation relies on the availability of RPKI
data, operators SHOULD locate caches close to routers that require
these data and services. 'Close' is, of course, complex. One should
consider trust boundaries, routing bootstrap reachability, latency,
etc.
If insecure transports are used between an operator's cache and their
router(s), the Transport Security recommendations in [RFC6810] SHOULD
be followed. In particular, operators MUST NOT use insecure
transports between their routers and RPKI caches located in other
Autonomous Systems.
i am not against further explanation, send text. but short text. :)
experiments have shown that latency between cache and router, and
between caches in a cache dag, is not an appreciable issue. as the
reports of these experiments are not peer reviewed, it is not clear that
they are good to reference. one has been accepted at conext, but page
count limit prevented the latency issue from being included :(
i thought bootstrap reachability would be fairly obvious to an operator.
but if simple routing and no dns dependency were not obvious to you,
then a few words are indeed needed. or am i missing your point here?
as the rpki-rtr protocol is beyond the border of object-based security,
the operator only has transport security between the cache(s) and the
router. it would probably be good to add this as it motivates the
"close" and "trust boundary" cautions.
what is missing from the second paragraph? section 7 of rfc6810, as
referenced, was very heavily reviewed and pretty much bludgeons this one
to death. of course if you have specific ideas for improvement, that'd
be great.
"ok, we're going to stick it in a VM on our two national data center
compute infrastructures like the rest of our servers, we can spin up
more instances if you need to scale it"
"but RFC mumble mumble says that we shouldn't do that..."
"ok, why? And where do you want to put it?"
"ummm... 'close' to the routers? Because...reasons"
i am not sure it would be useful to go into the general issue of why
caches should be proximal to the consumer as it is a rather well-
explored area, from akamia and limelight to dns. but if you have a
sentence or two that communicates this, send it over.
randy