Sorry for the subject change, it seems now we're talking about something perhaps more relevant to me (security and routing stuff) On Wed, Jan 5, 2011 at 5:32 PM, Randy Bush <randy@psg.com> wrote:
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> 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> (with email addresses even!) The AC folks are listed at: <https://www.arin.net/about_us/ac.html> -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 :)
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
On Wed, Jan 5, 2011 at 11:16 PM, Randy Bush <randy@psg.com> wrote:
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 :)
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> 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 Jan 6, 2011, at 11:16 AM, Randy Bush wrote:
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. Concur on all the other points, however. ------------------------------------------------------------------------ Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay
On Wed, Jan 5, 2011 at 11:30 PM, Dobbins, Roland <rdobbins@arbor.net> wrote:
On Jan 6, 2011, at 11:16 AM, Randy Bush wrote:
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
------------------------------------------------------------------------ Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves.
-- Alan Kay
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
Date: Thu, 06 Jan 2011 14:24:01 +0900 From: Randy Bush <randy@psg.com>
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. ]
The day of reasonable accuracy of the IRR ended when UUnet bought ANI. Since ANI actually used the IRR to generate there router configs and ANI was pretty big, people were really forced to register. Curtis had a lot of excellent software that did all sorts of impressive stuff with the IRR, but I guess that all went into the bit bucket when UUnet took over. Very, very sad! -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
On Thu, Jan 6, 2011 at 2:03 PM, Kevin Oberman <oberman@es.net> wrote:
Date: Thu, 06 Jan 2011 14:24:01 +0900 From: Randy Bush <randy@psg.com>
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. ]
The day of reasonable accuracy of the IRR ended when UUnet bought ANI. Since ANI actually used the IRR to generate there router configs
s/NI/NS/g
and ANI was pretty big, people were really forced to register. Curtis
s/NI/NS/
had a lot of excellent software that did all sorts of impressive stuff with the IRR, but I guess that all went into the bit bucket when UUnet took over.
we did require you to email nacr-list@ :) that didn't help? All sed jokes aside, would having attestations that the route you see is part of a block assigned by IANA to ARIN and from ARIN to UUNET and from UUNET to JoesCrabShuckers make sense to you? (and to your router policy provided the router policy engine and code worked) The efficacy of the IRR isn't at question, the ability to assure with some level of reasonableness that the thing you see (and eventually it's path to get to you) is "valid" is what the RPKI system is building toward. -Chris
Very, very sad!
(tears were shed)
-- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
had a lot of excellent software that did all sorts of impressive stuff with the IRR, but I guess that all went into the bit bucket when UUnet took over. we did require you to email nacr-list@ :) that didn't help?
and he processed on wednesday, not exactly optimal for ops. if we are listing those who gave good blood for the irr, joe lawrence and roy alcala, of mci and later level(3), would be at the top of my list. randy
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
participants (4)
-
Christopher Morrow -
Dobbins, Roland -
Kevin Oberman -
Randy Bush