-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am afraid I don't believe this policy should be adopted at this time. My reason is that I think it creates a legal and political risk that is substantial and as yet uninvestigated in the PDP, but which may in the long term reduce the overall robustness of Internet infrastructure to an extent that greatly outweigh the security benefits of the policy. 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 don't think we should approve this policy until we are certain that this approach is necessary, worth the risk, that no acceptable alternative solutions (or partial solutions) to the problem exist, and that we've also established all appropriate measures to mitigate the foreseeable risks. The complete argument about why I fear a bad outcome will be too long and complex for a first post on this subject, so let me try to give the briefest summary I can manage instead: I believe that if this policy is adopted, and if it is taken up significantly be operators, it will encourage a dramatic increase in the number of demands from law enforcement and private litigants to the RIPE NCC to revoke both allocation of resources and their certificates, without the consent of the person to whom the resource is delegated. Once legislators realise that the NCC has a more effective power to revoke allocations than previously existed, and has become more capable of making networks appear to "go offline" than it currently is able, legislators will likely respond by creating new powers for law enforcement to oblige the NCC to revoke resource allocations as a tool to address undesired behaviour by network users. In short, in a world where reachability is significantly affected by the ability to produce a valid certificate under this policy, the RIPE NCC will be seen as a "one-stop-shop" for knocking networks offline, to control illicit content and online activity. (Perhaps reachability will not be affected because network operators will ignore these certificates, but if we believe that then isn't this policy a waste of time and effort? And operators may not have a free choice: new legal powers were created by the EU last year that could easily be used to compel adoption). Thus, the RIPE NCC would be gradually transformed into a much more political body; indeed, I think at least as political as ICANN currently is. My concerns are not merely academic, they are immediate and practical. We know that many countries, including the EU, have adopted or are actively considering adopting legal requirements for network operators to block packet transit to/from network addresses outside their network in order to inhibit illicit content or activity (e.g. copyright infringement). LEAs already attend RIPE meetings (Co-operation WG) to ask the community to develop policies to transfer allocations of network blocks to the LEA following an allegation by the LEA that the netblock is being used for illicit purposes, the idea being to seize control of routing. Earlier this year the RIPE NCC attended at least one meeting that I know of to discuss this with EU officials. So far the NCC has fended off such requests, I understand, on the grounds that it doesn't have control over routing. If this policy proceeds, is adopted and successful, that argument will be greatly weakened. Would making RIPE NCC such an attractive single point of failure really make the Internet more secure and robust? I believe that before this policy is adopted the community should consider in depth: i) whether these concerns are at least potentially valid (I am convinced they are); ii) If so, whether the problem that this policy addresses is sufficiently serious to warrant accepting these new risks [1]; and 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). iv) Even if the problem still justifies adopting the approach taken in this policy proposal, what other steps should be taken simultaineously to mitigate these risks. For myself, I am convinced about (i). I have serious doubts about (ii) and (iii) myself, and perhaps more importantly can see no evidence on the list archive that the community has actively assessed whether (ii) is true, and no evidence that other potential architectures or system designs have been considered as a possible alternative that might better mitigate the risks I describe. Nor has there been any visible discussion of (iv). Even if I've missed something, do we really think the community has considered these issues in depth? Or have they been shunted off as a problem to be looked at later, or elsewhere? The presentation at yesterdays RIPE meeting plenary by Randy Bush and the discussion that followed convinced me that there is much more for the community to discuss. I have raised this issue at previous RIPE meetings but only recently become aware that to affect the PDP it was necessary to post on this list, for which my apologies. However I now see such objections are the explicit purpose of the Last Call, so I hope you'll consider this objection carefully. There is much more I could say, but for a first post on the subject I'll leave it at that; I don't want to create a bigger "wall of text" than absolutely necessary. I would be grateful if those who agree with me that this discussion warrants delaying adoption of the proposal would say so now, so that the WG Chair can see whether there is a "serious objection" that prevents a rough consensus being declared at this time. My apologies to those who have worked so long and hard on this, with only the best of motives, on the assumption that there was general support for this approach. But I'm afraid this issue is too important to let this pass without raising my concerns, and asking the community to stand with me. Malcolm. [1] Yes, route hijacking does happen, sometimes by mistake and sometimes by malice. But how often? Are current responses sufficient to deal with it proportionately? Could they be made more effective without any kind of certification scheme? Would something new, that's not a certification scheme suffice? [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? - -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/ London Internet Exchange Ltd Maya House, 134-138 Borough High Street, London SE1 1LB Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2/56YACgkQJiK3ugcyKhTdwgCgp02ZpOj7XhT1TlN5xk7vOF9l ZdAAoIe+LF1Dt70q9Gonk2/CsoLG6N2O =z7io -----END PGP SIGNATURE-----