On Fri, Oct 1, 2010 at 9:07 AM, <bmanning@vacation.karoshi.com> wrote: \> I -think- what you are really after is the (fairly) new rPKI
pilot - where there are crypto-keys tied to each delegated prefix. If the keys are valid, then ARIN (or other RIR) has "sanctioned" thier use. No or Bad crypto, then the RIR has
'or anyone else in the heirarchy of certificates' (nominally: IANA -> ARIN -> LIR (uunet/701) -> bmanning-inc -> bait&sushi (endsite) )
some concerns about the resource.
or someone in the chain forgot to re-gen their cert, do the dance with resigning and such. (there are a few failure modes, but in general sure)
the downside to this is that the RIR can effectivey cut off someone who would otherwise be in good standing. Sort of
this depends entirely on the model that the network operators choose to use when accepting routes. Presuming they can, on-router, decide with policy what to do if a route origin (later hopefully route-path as well as origin) is seen as invalid/non-validated/uncool/etc, there could be many outcomes (local-pref change, community marking, route-reject...) chosen.
removes a level of independence in network operations. Think of what happens when (due to backhoe-fade, for instance) you -can't- get to the RIR CA to validate your prefix crypto? Do you drop the routes? Or would you prefer a more resilient and robust solution? YMMV here, depending on whom you are willing to trust as both a reputation broker -AND- as the prefix police.
hopefully the cache's you run are redundant (or the cache service you pay for is redundant enough), as well the cache view is not necessarily consistent (timing issues with updates and such), so some flexibility is required in the end system policy. (end-system here is the router, hopefully it is similar across an asn) I think so far the models proposed in SIDR-wg include: o more than one cert tree (trust anchor) o the provision of the main cert heirarchy NOT necessarily be the one I outlined above (iana->rir->lir->you) o operators have the ability to influence route marking based on certificate validation outcomes o low on-router crypto work o local and supportable systems to do the crypto heavy lifting, kept in sync with what seems like a reasonably well understood methodology o publication of the certification information for objects (asn's, netblocks, subnets) via existing processes (plus some crypto marking of course)
The idea is that the crypto is harder to forge. DNS forging is almost as easy as prefix "borrowing".
and that the crypto/certificates will help us all better automate validation of the routing information... sort of adding certificate checking to rpsl? or, for whatever process you use to generate prefix-lists today for customers, add some openssl certificate validation as well. The end state I hope is NOT just prefix-lists, but certificate checking essentially in realtime with route acceptance in to Adj-RIB-in... I believe Randy Bush has presented some of this fodder at a previous nanog meeting actually? -chris