Re: [sidr] WGLC: draft-ietf-sidr-origin-ops

[Randy Bush <[e-mail]>]

> 1)  From Section 3:
> ---snip---
>    A local valid cache containing all RPKI data may be gathered from the
>    global distributed database using the rsync protocol, [RFC5781], and
>    a validation tool such as rcynic [rcynic].
> ---snip---
> 
> Would it be possible to mention and/or point to how the above process
> is supposed to be bootstrapped?  IOW, is it expected that,
> eventually?, the RIR's are going to publish to their end-users and
> maintain URI's of RPKI publication points?  Since this is an Ops
> guidelines document, some guidance and/or pointers are likely to save
> [lots of] questions down the road.  I'm not expecting this to be a
> tutorial document, but some idea on the theory of how a new SP
> bootstraps their cache(s) would be helpful.

that is software dependent.  relying party software and how it decides
to deal with the global rpki is very software dependent.  e.g. tim's
varies from rob's, and we have some really wild ideas to deal with the
issues of reliable distributed publication.

it has been suggested that you may be asking how the inter-publication
stuff is to be bootstrapped at the global rpki level.  this is the sia
pointer in the cert.  when i tell arin i want my space and will publish
at uri://randy.foo, they put the cert in their pub point with an sia
pointer to uri://randy.foo

> 2)  Given that, to my knowledge, the RPKI is [very] loosely
>     synchronized in a "pull-only" fashion, shouldn't there be some
>     text added below to that effect that: 
>     a)  It may not be best to go more than, say, 2 levels of RPKI
>     caches deep inside a single organization/ASN to avoid RPKI caches
>     from being out of sync with each other?

considering the timings we are seeing in operation, like a few seconds
to fetch from one cache to another, as compared to minutes to load from
the global rpki (see rob's preso at iepg) and my comment above, this may
be 180 degrees out.  inter-cache fetching may be far better.

but code will vary.

>     b)  Operators should look at running more aggressive
> synchronization intervals _internally_ within their organization/ASN,
> from "children" (2nd-level) RPKI caches to the 'parent' (top-level)
> RPKI cache in their organization/ASN, compared to more "relaxed"
> synchronization intervals to RPKI caches external to their
> organization (top-level RPKI caches in their ASN to RIR's)? 

kind of assumed in current text, but i can add something.

> ---snip---
>    Validated caches may also be created and maintained from other
>    validated caches.  Network operators SHOULD take maximum advantage of
>    this feature to minimize load on the global distributed RPKI
>    database.  Of course, the recipient SHOULD re-validate the data.
> ---snip---
> While I'm here, I don't think the text in Section 6, "Notes",
>    addresses the above concerns, at all.  In fact, I find it extremely
>    unhelpful to just dismiss this concern, out of hand, with the text:
>    "There is no 'fix' for this, it is the nature of distributed data
>    with distributed caches".  We know what the answer is here

for some values of "we."

>    you tune the synchronization intervals to strike the appropriate
>    balance between [very] tight synchronization vs. increased load on
>    the systems being synchronized.

could you reference an example, a paper, an algorithm, ...?  we seem to
think differently about how easy this is.

>    I find it hard to believe a simple suggestion such as this is not
>    proposed in the text, even including the phrase "the suggested
>    values for such synchronization are outside the scope of this
>    document, but will likely be subject to further studies to
>    determine optimal values based on field experience".

ahhhh.  so we don't know.  i say that frequently!

    It is hoped that testing and deployment will produce advice on
    relying party cache loading and timing.

> 3)  Granted, the following text is only a "SHOULD", but the text
> offers no reasoning as to why caches should be placed close to
> routers, i.e.: are there latency concerns (for the RPKI <-> cache
> protocol), or is it that a geographically distributed system is one
> way to avoid a single-point-of-failure, or something else entirely?
> As a start, just defining "close" would help, e.g.: same POP, same
> (U.S.) state, same country, same timezone 

i seem to get in trouble every time i do so.  it's an ietf thing.

> but, then a statement as to any latency or resiliency requirement for
> geographic deployment of RPKI caches wold be useful.

so far, actual timings seem not to be very latency sensitive, probably
because they have been done with freebsd on fat wires.

as i said on this thread on nanog, this is why we get the big bucks.  it
is a multi-dimensional design issue.

>     Furthermore, given the [very] loosely synchronized nature of the
> RPKI, should the text point out that the number of RPKI caches
> (internal to the organization) be balanced against the potential need
> of an organization to maintain a more tightly synchronized view,
> across their entire network, of validated routing information?

i have no idea.  you seem to think inter-cache sync dominates timing far
more than i do.  i suspect that publishing party timing dominates.

so send text.

> A concern might be that if routers in Continent A pull information
> from their RPKI caches that tell them that ROA is not "Invalid", but
> other routers in Continent B are still using 'older' information in
> RPKI caches in Continent B that says the same ROA is either "Not
> Found" or "Valid", then the result might be that BGP Path Selection
> swings all traffic from Continent A to Continent B.  At a minimum,
> this could lead to substantially increased latency or, at worst,
> congestion, packet-loss or a unintended DoS.

yep, that is a concern.

how deeply do we want to get into explaining all the issues surrounding
distributed data?  at this point i am tempted to point to a basic cs
text on the subject.

>     In the short-term, the LOCAL_PREF Attribute may be used to carry
> both the validity state of a prefix along with it's Traffic
> Engineering characteristic(s).  It is likely that the SP will have to
> change their BGP policies such that they can encode these two,
> separate characteristics in the same BGP attribute without negatively
> impacting their existing use or leading to accidental privilege
> escalation attacks.  

thanks for text

> 5)  I have three comments on the below:
>     a)  It's not clear, to me, what is meant by "internal metric"
>     below.  Do you mean MED or IGP metric or something else?  I don't
>     see IGP metric as being practical, so I'm assuming you mean
>     additively altering MED (up|down) based on validity state.
>     Regardless, I would recommend you state more precisely which BGP
>     Path Attribute you're referring to below. 
>     b)  Since MED is passed from one ASN to (only) a second, downstream ASN to influence ingress TE policy, is it "OK" from a security PoV that MED is a *trusted* means to convey ROA validity information from one ASN to a second?  Presumably, the answer should be "heck, no", right?  If that's the case, then wouldn't it be wise to state that:
>         i)  MED's, encoded with any ROA validity information, should get reset on egress from an ASN to remove said validity information and only carry TE information, as appropriate; and,
>         ii) MED's should not be trusted on ingress to convey any meaning with respect to validity information?
>     c)  What is meant by the statement, "might choose to let AS-Path rule"?  Is your intent to state that an SP may choose to just use MED, which follows after LOCAL_PREF & AS_PATH in the BGP Path Selection Algorithm, as a means to determining validity of a particular prefix?  If so, then it would be much more clear if you just stated that, e.g.:
> ====
>     If LOCAL_PREF is not used to convey validity information, then MED
>     is likely the next best candidate BGP Attribute that can be used
>     to influence path selection based on the validity of a particular
>     prefix.  As with LOCAL_PREF, care must be taken to avoid changing
>     the MED attribute and creating privilege escalation attacks.

      Other providers may not want the RPKI validation result to be more
      important than AS-path length -- these providers would need to map
      RPKI validation result to some BGP attribute that is evaluated in
      BGP's path selection process after AS-path is evaluated.  Routers
      implementing RPKI-based origin validation MUST provide such
      options to operators.

> 7) Is this document only intended (scoped?) to cover PE's that can
> (or, eventually, will) speak the RPKI-RTR protocol for validation?

yes

randy