ARIN Fraud Reporting Form ... Don't waste your time

Fri Oct 1 15:04:17 UTC 2010

On Fri, Oct 1, 2010 at 9:07 AM,  <bmanning at 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