This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call
- Previous message (by thread): [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call
- Next message (by thread): [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Martin Millnert
millnert at gmail.com
Thu May 5 12:19:49 CEST 2011
Hi John, On Thu, May 5, 2011 at 5:50 AM, John Curran <jcurran at arin.net> wrote: > On May 4, 2011, at 8:48 PM, Martin Millnert wrote: > >> ... >> Network C and D are transit customers of tier-1 network E. >> ... >> Network D announces prefix 1 to E. >> >> Transit provider E, being a very large company, has after some >> government pressure decided to enable strict RPKI filtering >> ... >> Only a single network, E, implemented strict filtering of RPKI, yet A, >> not being a customer of E, lost access to 1, and all involved hardware >> is still functional. > > Prefix 1 is for customer D (of network E); ergo, A lost access to D > because D's choice of service provider. D voluntarily choose its > service provider, and can always choose another. Can it always choose one which is not using this new "route assurance technology"? > There is no party > that was impacted without a choice; D choose A because of their much > discussed "route assurance" technology, and that turned out (in your > example) to be a bad choice. Another example might have it be a wise > choice, but there's still no one impacted who didn't get any choice. > > How is this different than network D deciding to build a network with > with an innovative routing technology, which may serve to distinguish > it in a positive (or negative) manner based on actual performance? Are you suggesting that the more ways we have to break the internet, the better? You would probably argue that RPKI can improve performance by removing intentional and un-intentional route hijacking. But to this I must ask: Can we quantify how often this happen? It would be a very useful data point going forward. We could also quantify how many jurisdictions have some form of internet filtering legislation in place today. And take a look at what's in the legal pipeline. A well known block list (the existence of it, not its content) was tested at one point: 98% false-positives. (the remaining 2% was permanently fixed via simple email, and a ~3h response time...) Using this metric as the track record for gov internet filtering, and extending it to our discussion, mistakes will frequently happen, and the entire endeavor is flawed to its very bones. But this is not the debate of the specifics of the legal processes in various jurisdictions, I'm merely showing (and #include Malcom's posts) a real big risk of having a larger stream of failures coming from the abuse of a highly proliferated RPKI than the failures it was designed to fix. As Sascha put it earlier in the discussion: "the cure is infinitely worse than the disease" Key in my example is otherwise what was not written out: If you scale the example up, and use of RPKI with strict filtering has proliferated, X has a good vector to negatively and widely affect internet routing via Z, which is a completely new thing on the Internet from today. > Back to my original question: "I understand how it would impact the > network which has decided to make use of strict RPKI-based route > validation (and therefore the network's customers by extension), but > can you explain how it would otherwise effect that network's peers?" I thought I did explain this in my example: B lost access to D, B *is a peer* of E, who uses strict RPKI-based route validation. This is a technicality in the bigger scheme as described above and by Malcom, however. Kind Regards, Martin
- Previous message (by thread): [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call
- Next message (by thread): [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]