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
Tue May 3 19:22:39 CEST 2011
Hi Immo, On Tue, May 3, 2011 at 1:05 PM, Immo 'FaUl' Wehrenberg <immo.ripe at be.free.de> wrote: > Malcolm wrote: >> I am afraid I don't believe this policy should be adopted at this time. > > I agree with that. > >> This is not a minor, administrative policy. It is (even if not intended >> as such) the first step in a process the end result of which would be a >> major change to the Internet architecture. I am afraid that the ultimate >> outcome could be that the Internet becomes more fragile as a >> consequence. True, it's only the first step. But if it's a step in the >> wrong direction, let's not do it. > > I'd like to add to the ones argueing that you are not forced to implement > a policy based on the rpki: > What point does this have if noone implements that? None, right, so > all arguing in favour of this policy are convinced that one will imlement > something based on that. So concider that: > Once a serious amount of ASes (and exspecially carriers) have implemented > policies based on RPKI, we will never get rid of that, at least not > easyly. Just look at how good IPv6 is beeing adapted and how good > we are getting rid of v4. ;) > > So before we push that huge responsability that comes along with that > RPKI certificates (and especially with the power of revocation either > by not renewing an expired certificate or by CRL or something like that) > into the RIRs, we should double and tripple think wether we are > really willing to do that and wether the RIRs are stable and resistable > enough to the political preassure that no matter will fall upon them > really soon after gouvernments (and lobby groups, ...) notice. > > [stuff where I pretty much agree with Malcolm deleted] > >> iii) Even if the problem is serious enough, whether alternative means to >> address it could be found that would mitigate these risks [2]. (For >> example, if the problem could be 80% solved using a model that does not >> give RIRs a power to revoke and expire certificates "needed" for >> routing, is the residual 20% of the problem really serious enough to >> warrant creating the risks I describe). > > In order to respond to [2] here (and following a short discussion i had > with Geoff after his talk yesterday): > as the ressources are given out by the by IANA and the RIRs and the LIRs, so introducing an hirarchial approach that shadows the real assigning is a logical and the only usefull approach IMO. Here I'd like to raise a minor, quite theoretical, objection. The primary purpose of IANA, RIRs and LIRs, when it comes to IPv4/v6 and AS numbers, is to organize resources globally so that there are no collisions (uniqueness). WIth IPv4 and to some extent AS numbers, there's an additional point of rationing them out, but that is mainly a side-effect of them being varying degrees of finite resources. IPv6 however, while not infinite, is certainly sufficient for every person on the planet. And so it is conceivable that another, distributed, system for uniqueness verification could exist. Whether or not any change like what I'm describing has any chance to fly or not, is a slightly different question. That, and what routing it would require. Returning to present day reality, address assignment policy and routing policy has rather successfully been kept apart so far, I think. Joining them up with a glue of censorship, which is what RPKI is (dropping prefix announcements, right?), is not very appealing to me. And what censorship it could become -- internetwide nearly instant censorship. > In general, both approaches works poorly to say > the least and giving away the power to some "trusted third partys" get > us the mess we today have with traditional ssl certificates (where > we have a system that is seriously broken beyond all repair). However, > I'd like to take Randys point from his talk that the validatity of > certificates should be long, but would even say that thay should not > be only two to five years, but instead at least 20 years and > no possible revocation in order to protect the RIRs from being smashed > by political preassure. The really-long-term validity is appealing, but nevertheless falls short from personal preference since I don't see the actual need for RPKI to begin with. Thanks, Kind Regards, Martin > > From the security point of view, lang validity times are indeed just > a question of chosing reasonable security parameters and there is a > good consenseous about that in the security and crypto research about > what that should be and these are (with a large safety margin) available > in various recommendadiots (for example by NIST[1]). > > [even more stuff from Malcolm where i generally agree deleted] > > regards, > > Immo > > [1] http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf > Page 66 > > I'd just keep Malcolms [2] here >> [2] For example, could we creates "webs of trust" rather than a single >> hierarchy? Would that be "good enough" or is a hierarchy essential? >> Could a PKI for address allocations work sufficiently well without >> investing the hierarchy with authority to revoke certificates? Should we >> consider an architecture with a distributed issuer/revoker, spread >> across multiple jurisdictions? What other models exist? >
- 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 ]