APWG, I agree completely with what Malcolm says and wholeheartedly share his concerns in this area. We should all think real long and hard about the possible long-term implications of what this proposal sets the foundation for. In its essence this is a philosophical (which often intersects with political views) question that goes to the roots of each and every one of us. Personally, I firmly believe the strength and resilience of the Internet and the communication it enables (a tremendous asset for humanity in itself) lies in its distributed nature; not just in redundant communication links and routing protocols providing resilient routing, but a diverse political control. BGP hijack *is* a concern, but, it is most definitely a secondary or tertiary problem to the system at large IMNSHO. While I'm by no means suggesting we should not improve ourselves, I do believe we've handled these problems pretty well so far. The Internet *will not* fall over and die if we step back and take a deep breath on this topic. We have our RIS/BGPlay/Cyclops and pretty active BGP operators for the most part - I think we can "hold down the fort" while we convince ourselves that we have covered *all* aspects of this issue, and not mistakenly hasten anything through. I have not seen the concerns that Malcolm raises thoroughly debated or researched anywhere. The only debate I've seen has been a few threads on NANOG... I'd appreciate pointers to more of such research/debates if I have missed it (didn't find it on APWG, for instance.) I've personally initiated some early contact with the Tor community, because they are a very good bunch of people in analyzing Internet security from a privacy/freedom standpoint. I think more and similar contacts should be engaged. Rest assured, the people who have these concerns are *not* trying to stall RPKI just for the sake of stalling it! The concerns Malcom bring up, which I share, are very legitimate and I fully recommend we do not adopt this proposal until these issues have been more thoroughly addressed. And for the record, I do not believe surrendering to bureaucrats/lawmakers' pressure by doing their bidding is a positive evolution of our society. I'm far from any anarchist - I strongly believe in democracy with all its flaws, but a free, open and democratic society is not self-preserving by its own momentum as far as I have learned in life (seems to be quite the contrary). There actually has to be people constantly working to keep it this way, else it wither and rust away. We are those people. Or at least should be, IMO. The Internet is far too important for us not to be. Convince me these concerns are not valid, and this proposal has my support. Kind regards, Martin On Tue, May 3, 2011 at 7:31 AM, Malcolm Hutty <malcolm@linx.net> wrote:
-----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-----