where was my white knight....

Nick Hilliard nick at foobar.org
Tue Nov 8 20:51:00 UTC 2011


On 08/11/2011 19:19, Randy Bush wrote:
> what comes to my mind is that NotFound is the default and it is
> recommended to route on it.

I understand what the manual says (actually, i read it).  I'm just curious
as to how this is going to work in real life.  Let's say you have a router
cold boot with a bunch of ibgp peers, a transit or two and an rpki cache
which is located on a non-connected network - e.g. small transit pop / AS
boundary scenario.  The cache is not necessarily going to be reachable
until it sees an update for its connected network.  Until this happens,
there will be no connectivity from the router to the cache, and
consequently prefixes received in from the transit may be subject to an
incorrect and potentially inconsistent routing policy with respect to the
rest of the network.  Ok, they'll be revalidated once the cache comes on
line, but what do you do with them in the interim?  Route traffic to them,
knowing that they might or might not be correct?  Drop until the cache
comes online from the point of view of the router?  Forward potentially
incorrect UPDATEs to your other ibgp peers, and forward validated updates
when the cache comes on-line again?  If so, then what if your incorrect new
policy takes precedence over an existing path in your ibgp mesh?  And what
if your RP is low on memory from storing an unvalidated adj-rib-in?

You could argue to have a local cache in every pop but may not be feasible
either - a cache will require storage with a high write life-cycle (i.e.
forget about using lots of types of flash), and you cannot be guaranteed
that this is going to be available on a router.

Look, i understand that you're designing rpki <-> interactivity such that
things will at least work in some fashion when your routers lose sight of
their rpki caches.  The problem is that this approach weakens rpki's
strengths - e.g. the ability to help stop youtube-like incidents from
recurring by ignoring invalid prefix injection.

Nick




More information about the NANOG mailing list