[130345] in North American Network Operators' Group
Re: ARIN Fraud Reporting Form ... Don't waste your time
daemon@ATHENA.MIT.EDU (Christopher Morrow)
Fri Oct 1 11:04:28 2010
In-Reply-To: <20101001130750.GB10880@vacation.karoshi.com.>
Date: Fri, 1 Oct 2010 11:04:17 -0400
From: Christopher Morrow <morrowc.lists@gmail.com>
To: bmanning@vacation.karoshi.com
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Fri, Oct 1, 2010 at 9:07 AM, <bmanning@vacation.karoshi.com> wrote:
\> =A0 =A0 =A0 =A0I -think- what you are really after is the (fairly) new r=
PKI
> =A0 =A0 =A0 =A0pilot - where there are crypto-keys tied to each delegated
> =A0 =A0 =A0 =A0prefix. =A0If the keys are valid, then ARIN (or other RIR)=
has
> =A0 =A0 =A0 =A0"sanctioned" thier use. =A0No 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) )
> =A0 =A0 =A0 =A0some 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)
>
> =A0 =A0 =A0 =A0the downside to this is that the RIR can effectivey cut of=
f
> =A0 =A0 =A0 =A0someone who would otherwise be in good standing. =A0Sort o=
f
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.
> =A0 =A0 =A0 =A0removes a level of independence in network operations. =A0=
Think
> =A0 =A0 =A0 =A0of what happens when (due to backhoe-fade, for instance) y=
ou
> =A0 =A0 =A0 =A0-can't- get to the RIR CA to validate your prefix crypto? =
=A0Do
> =A0 =A0 =A0 =A0you drop the routes? =A0Or would you prefer a more resilie=
nt
> =A0 =A0 =A0 =A0and robust solution? =A0YMMV here, depending on whom you a=
re
> =A0 =A0 =A0 =A0willing to trust as both a reputation broker -AND- as the =
prefix
> =A0 =A0 =A0 =A0police.
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)
> =A0 =A0 =A0 =A0The idea is that the crypto is harder to forge. =A0DNS for=
ging
> =A0 =A0 =A0 =A0is 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
