ARIN and the RPKI (was Re: AltDB?)

Sorry for the subject change, it seems now we're talking about
something perhaps more relevant to me (security and routing stuff)

i have a rumor that arin is delaying and possibly not doing rpki that
seems to have been announced on the ppml list (to which i do not

I have heard this as well ... the message in the archive is:
(arin-announce actually, not ppml)
<http://lists.arin.net/pipermail/arin-announce/2010-December/001107.html&gt;

Essentially the note says that Kosters & crew are delaying until
Q2-2011 the deployment of RPKI services (nebulous 'other features need
to be implemented due to security concerns' is the stated reason)

subscribe). as it has impact on routing, not address policy, across
north america and, in fact the globe, one would think it would be
announced and discussed a bit more openly and widely.

I agree... so, what is the RPKI for and why should ops/security folks
care? (and should we care enough to poke our local ARIN constabulary
in the eye with a sharp stick?)

I'm of the belief that if we (ops/security folks) feel the need to
have a more secure routing infrastructure so we can hope to avoid
incidents like: (quick examples, there are many others like these)
  o AS7007 full-table re-announce + re-originate
  o ConEdison "hijack" + re-originate
  o Pakistan/YT hijack + re-originate
  o "Pilosov/Kapela" hijacks/manipulations
  o Christmas TurkTelecom leak/hijack
  o PRC network leakages/hijacks/etc of April 2010

(Note: let's not debate if the above incidents are one/the-other
hijack/mistake/etc, the simple fact is traffic was diverted and some
better filtering/control would have avoided these failures in our
system)

We need at least these things to exist:
  o an accurate mapping of resource (netblock/asn) to
authorized-entity (RIR/NIR/LIR/Customer/...)
  o a system to manage this data for our routing equipment
  o protocol enhancements that can be used to help propagate the
mapping information
      or at the least help a router programmaticly understand if a
resource is being used by the authorized
      entity
  o routing software that can digest the enhanced data
  o routing hardware that won't crumple under the weight of (what
seems like) heavier weight routing
     protocol requirements

I believe the lynch-pin in this is the accurate mapping of resources
to authorized users, I believe that is supposed to be the RPKI system.
I believe that the RPKI will tell me, an end-operator, that 63.0.0.0/9
was handed from IANA to ARIN to UUNET/VerizonBusiness and that this is
being properly announced with an Origin-AS of 701. Having the service
run by these organizations seems reasonable to me... IANA signs down
to the RIR (ARIN in my example) and ARIN signs to VZB who can choose
to sign down to their customers if necessary.

Today there is a very loose, in all regions not just ARIN's,
association with lots of cruft and inaccuracies. The RPKI, operated by
RIR's, would provide some solid linkage and authority between
resources and owners, it should help to enforce cruft management as
well as provide mechanical (and relatively simple) management of the
data and associated filtering/etc on devices.

There is, of course, some risk with this model and we should take the
time to accept/discuss that as well.
Danny has had lots of good input on this topic, I'd hope that other
folks who've been through longer term ops battles with filtering
(jared, shane, charles gucker, rs, ras, ...) and the like can take
some time to think about this problem. I'd love it if we could have
some reasoned discussion here as well. Finally, everyone should go
poke their ARIN corporate representative(s) (or email the BoT or AC
folks directly even?) with their thoughts on whether or not the RPKI
system and Routing Security are important items for ARIN (as one RIR)
to pursue for the health of the Internet and Ops Sanity.

The BoT folks are listed at:
  <https://www.arin.net/about_us/bot.html&gt;
  (with email addresses even!)
The AC folks are listed at:
  <https://www.arin.net/about_us/ac.html&gt;

-Chris

We need at least these things to exist:
  o an accurate mapping of resource (netblock/asn) to
    authorized-entity (RIR/NIR/LIR/Customer/...)
  o a system to manage this data for our routing equipment

see all the sidr documents in last call to go from i-ds to rfcs. oh,
you co-chair sidr :slight_smile:

  o protocol enhancements that can be used to help propagate the
    mapping information or at the least help a router programmaticly
    understand if a resource is being used by the authorized entity

see draft-ietf-sidr-rpki-rtr-07

  o routing software that can digest the enhanced data

in test. rumors of going normal release from at least one vendor in q2

  o routing hardware that won't crumple under the weight of (what
    seems like) heavier weight routing protocol requirements

actually, the formal rpki-based origin-validation stuff is measured to
take *less* cpu, a lot less, than ACLs

There is, of course, some risk with this model and we should take the
time to accept/discuss that as well.

some guidance toward ameliorating the risks are in
<draft-ietf-sidr-rpki-origin-ops-00.txt>.

input from ops into all this stuff would be most welcome.

randy

We need at least these things to exist:
o an accurate mapping of resource (netblock/asn) to
authorized-entity (RIR/NIR/LIR/Customer/...)
o a system to manage this data for our routing equipment

see all the sidr documents in last call to go from i-ds to rfcs. oh,
you co-chair sidr :slight_smile:

yes, sorry I should have been more open ... i do co-chair (with sandy
murphy) the sidr-wg at the IETF.

o protocol enhancements that can be used to help propagate the
mapping information or at the least help a router programmaticly
understand if a resource is being used by the authorized entity

see draft-ietf-sidr-rpki-rtr-07

o routing software that can digest the enhanced data

in test. rumors of going normal release from at least one vendor in q2

o routing hardware that won't crumple under the weight of (what
seems like) heavier weight routing protocol requirements

actually, the formal rpki-based origin-validation stuff is measured to
take *less* cpu, a lot less, than ACLs

CPU + RAM both parts of the vector matter. (but you knew this)
Some of the interesting data would, I think, be good for ops folks to
see more openly, things that may actually affect their purchasing and
design decisions even! Danny's had some good presentation material
about changes in spec/implementations that have altered drastically
the update load on devices in actual networks.

There is, of course, some risk with this model and we should take the
time to accept/discuss that as well.

some guidance toward ameliorating the risks are in
<draft-ietf-sidr-rpki-origin-ops-00.txt>.

input from ops into all this stuff would be most welcome.

yes (as the co-chair)
yes (as the OP... more input/thought/discussion)

and looking at the:
  <https://www.arin.net/about_us/bot/index.html&gt;
it looks like the BoT is due to have a meeting either this week or
next? (they seem to always have one in the first week or two of the
year?) so again speak up here AND perhaps send a note the BoT or your
ARIN Rep's way "now".

-Chris

On the platforms which really matter in terms of rPKI, ACLs are handled in hardware, so this is pretty much a wash.

Concur on all the other points, however.

actually, the formal rpki-based origin-validation stuff is measured to take *less* cpu, a lot less, than ACLs

On the platforms which really matter in terms of rPKI, ACLs are handled in hardware, so this is pretty much a wash.

I think ACLs here means prefix-lists ... or I hope that's what Randy
meant? (prefix-lists are still, I believe, handled in the router CPU,
and the normal router OS not in hardware)

Concur on all the other points, however.

cool, thanks!
-chris

actually, the formal rpki-based origin-validation stuff is measured
to take *less* cpu, a lot less, than ACLs

On the platforms which really matter in terms of rPKI, ACLs are
handled in hardware, so this is pretty much a wash.

really? it was measured on a GSR. full check on a prefix, 10usec.
that's microseconds.

as chris pointed out, though, one pays for having the data in the trie,
i.e. in ram. but not a lot.

randy

I think ACLs here means prefix-lists ... or I hope that's what Randy
meant?

sorry. yes, irr based prefix lists. and, sad to say, data which have
sucked for 15+ years. i was the poster child for the irr, and it just
never took off.

[ irr data are pretty bad except for some islands where there is culture
  of maintining them. and, as it is a global internet, islands don't
  help much. europe and japan are two islands with better than the
  average irr data quality. and they have rpki rolling to varied
  degrees. ]

randy