Re: [sidr] Last Call: <draft-ietf-sidr-origin-ops-21.txt> (RPKI-Based Origin Validation Operation) to Best Current Practice

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]