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/address-policy-wg@ripe.net/
[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
Wed May 4 23:33:22 CEST 2011
On Wed, May 4, 2011 at 2:10 PM, John Curran <jcurran at arin.net> wrote: > Martin - > > Given the validation that some operators already perform based on > information in RIPE Database (including whois and rpsl), doesn't the > same potential for network disruption due to misplaced governmental > action exist today? > > I am trying to discern if your concern is regarding the theoretical > existence of such risks, or the specifically the addition of RPKI > because your view it as a more accessible mechanism for abuse? > > Thanks! > /John Hi John, I'm concerned of a proliferation of a hierarchical routing policy structure on the Internet. I believe the RPKI scheme runs a much greater risk of proliferation than traditional RPSL, and this concerns me greatly. At the same time, I think the data already existing in for example RIPE's whois database and present technology is sufficient for the validation of customer and peer route announcements. However, I would much prefer if the power to change the holder of a prefix by design stayed with the current holder of the prefix only. This means of course that there would be no method to enforce a change of status externally. This of course becomes a bit problematic since it depends on the definition of what is a holder of a prefix. A good solution, I believe, to this question lies not in an external party declaring who's the holder or not of a prefix, but the holder of the prefix itself. In the case of the current RIR model, the RIR would transfer the rights of a prefix (by some cryptologic solution, I imagine) to the holder-now-owner of the prefix. An analogy: I pick up a very unique stone from a beach full of very individually unique stones -- I am the holder of this stone, not some other stone, and nobody else holds this stone but me. Or, I trade to myself a stone from another party, in a place where there are no unclaimed stones to be found. Only by holding a stone you have the power to speak. Nobody is able to say, certainly not prove, that I do not have the stone, that I have. Following the analogy, no central authority would be able to take my stone away from me - that would be theft. Also, no central authority is able to take the power to speak away from individuals in a room full of stone-holding people. Similarly, my peer's decision in determining whether or not I am the holder of a resource, and their decision of whether or not they accept my route announcement of said resource (or others) are *separate* issues. Acceptance of my origin route announcements, to me, seems like a decision that can be based on a number of factors, where the fact that I am the holder of the resource is one of them. A direct peer may have more reasons to accept my origin routes or not, such as whether or not I have paid my bill, and more. Another factor in accepting a route from a peer, origin or not, may be the path a route takes: Imagine the AS path contains "_64512 64513_", and for any number of reasons this specific AS hop (perhaps specific to the prefix itself, as well) becomes unfavorable to send your traffic over. It's imaginable that some kind of voting system can exist for AS paths, in addition to origin announcements (fool-proof proof of ownership could suffice here). Similarly, a voting system for AS:es themselves could exist. All this information (and more) could be used by a network to construct a multi-source based policy on what routes to accept, key being that it is the network that makes the decision itself, same as today, but with some key differences as well. Something along the lines of what I described above seems like the natural approach to this issue, to me. Many subsystems of what I mention have already been employed on the Internet to service various needs, and some of the ideas have similarities with RPKI/SIDR. And some of the things I mention are a bit different from what we do today. But an important point is that we *can* manage a system without central points of authority, which is highly desirable and preferable. Thanks, 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 ]