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]

 



> From: Randy Bush [mailto:randy@xxxxxxx]
>
> i don't even know what geographic redundancy is, alternate earths?
[WEG] nah, the latency is too high until we sort out IP over Quantum Entanglement. ;-) Geographic redundancy in the context of things that live on servers is that it exists on servers in more than one physical location (e.g. Datacenter East and Datacenter West) so that there isn't a single point of failure. In this case, that'd probably be in the form of two caches backing each other up (router configured to use both).

 if
> you mean redundant network topology, i think it is more than that.  i
> really think physical line length matters.  as i said, the longer the
> circuit the more likely a boat anchor will whack it.  hence close.
[WEG] yes, but ultimately that's dependent on your network topology. If "close" is the only way to mitigate that (vs having a truly redundant backup that doesn't share any topology in its path), then sure, that's what you do. But I don't think it directly translates to "should be close". We clearly disagree, but I'm not going to belabor the point any further.
>
>
> i think i understand what you want made more explicit.  today's try
>
>    To relieve routers of the load of performing certificate validation,
>    cryptographic operations, etc., the RPKI-Router protocol, [RFC6810],
>    does not provide object-based security to the router.  I.e. the
>    router can not validate the data cryptographically from a well-known
>    trust anchor.  The router trusts the cache to provide correct data
>    and relies on transport based security for the data received from the
>    cache.  Therefore the authenticity and integrity of the data from the
>    cache should be well protected, see Section 7 of [RFC6810].
>
>    As RPKI-based origin validation relies on the availability of RPKI
>    data, operators SHOULD locate RPKI caches close to routers that
>    require these data and services in order to minimize the impact of
>    likely failures in local routing, intermediate devices, long
>    circuits, etc.  One should also consider trust boundaries, routing
>    bootstrap reachability, etc.  E.g. a router should bootstrap from a
>    chache which is reachable with minimal reliance on other
>    infrastructure such as DNS or routing protocols.
>
>    For example, if a router needs its BGP and/or IGP to converge for the
>    router to reach a cache, once a cache is reachable, the router will
>    then have to reevaluate prefixes already learned via BGP.  Such
>    configurations should be avoided if possible.

[WEG] close enough, ship it.

Wes

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.





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