-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 31/05/2011 09:54, Sander Steffann wrote:
It's not about agreeing at this point in time, it's about moving forward: at the last RIPE meeting you said that RPKI has risks what we shouldn't take without thinking about them and without looking for alternatives. In the hallway after the discussion you promised me to do research. As far as I can remember you would: 1) study the discussions in the IETF and other places to see why RPKI design decisions were made the way they are 2) see if there is a better way to secure routing that provides (90%-100%) the same benefits without the major risks as you see them 3) of course taking 1 into account while doing 2
Can you give us a status update on this?
You make it sound like I agreed to single-handedly solve the problem in all its various aspects. Not so. The only pointer anyone has given me to explain why 2008-08 incorporates the RPKI architecture that it does is "Go read the SIDR mailing list archive". So I had a look at that, but as far as I can understand they took the RPKI architecture as an input from previous work. So the reasons why this was picked seem to lie elsewhere, although I'm not sure where that is. Any better pointers to the actual discussion and decision-making would be welcome. What worries me about the questions you set me above is that it reads as though you expect me to single-handedly design an alternative solution that meets 2008-08's goals while also satisfying the criticisms. As I said in the hallway, the technical work on producing an alternative approach would have to be led by someone expert in that area, which I am not. If such work is done, I believe I can contribute usefully by helping to identify whether an alternative does indeed reduce the risk of the foreseeable consequences I've identified with 2008-08. For example, in the hallway we discussed a couple of ideas for variations on 2008-08 (distributed certification and decentralised CAs). These did seem to tackle the problems of centralisation with 2008-08, and so seem to me to be worthy of investigation, but developing the idea into an approvable policy proposal should be done by someone else. To reiterate: I am happy to contribute. However, if the design of this is in the hands of the IETF not RIPE, then I have to ask whether there any point in us designing an alternative? Or is the only decision for this WG a simple YES/NO on whether the community wants RIPE NCC to implement the IETF work? If the latter, what I have already said is probably sufficient. I must confess my ignorance on the scope available to us, and ask for your guidance. In any case, my own core relevant expertise lies in correcting some of the misinformation propagated here about "black helicopters" and so forth, by providing concrete information on public policy developments in progress, and filling in the information gap left by the RIPE NCC's legal advice, which disclaims advising upon the likelihood and likely consequences of future changes in the law (I'm not criticising the lawyer for leaving this gap: that area is essentially Public Affairs advice not legal advice). I suggest that this is important input to this WG's decision as to whether it believes 2008-08 (or any successor proposal) is in fact useful, i.e. whether it is likely to do more good than harm. Malcolm. - -- 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/ iEYEARECAAYFAk3kxDQACgkQJiK3ugcyKhS9uwCgrl/fYP62Y/tMwCGfOy9h1Xh5 CVoAoMmztYz0XGVIyW6XXRK5RDa6dciR =Thdg -----END PGP SIGNATURE-----