On Sun, Jan 9, 2011 at 7:33 PM, John Curran <jcurran@arin.net> wrote:
My reason for responding is simply to make sure that ARIN is doing what the community wants. I won't deny that this may take some time depending on exactly what is involved, but in my mind that is far better than not fixing the situation.
How will ARIN respond to operational security matters with regard to RPKI infrastructure in the future? What experience does ARIN have with operational security in the past? When faced with DNS server vulnerabilities, did ARIN solicit community feedback before patching the servers responsible for IN-ADDR.ARPA zones administered by ARIN? Or did ARIN treat this matter as a legitimate, operational security concern, and apply whatever technical solution was available and generally accepted by other organizations administering DNS servers? Why should an operational security issue with the ARIN IRR be handled as a policy issue? Do you know that I have emailed ARIN about this both recently and in years past? Am I the only person who has ever tried to bring this to ARIN's attention? I doubt that. Are the personnel managing the ARIN IRR oblivious to the fact that every other IRR database except ARIN supports at least some form of password authentication? Are these personnel qualified to handle services with operational impact? Do you, or they, know that ARIN's IRR technical infrastructure actually does support password security, and that records exist in the ARIN IRR database with MD5 authentication, but that email to ARIN about this are answered with replies that only MAIL-FROM is possible? Why does the ARIN web site make no mention of anything besides MAIL-FROM?
Thanks; I'm aware of the ARIN IRR and how operators in the community make use of it, and have run ISPs which have made use of the data for route filtering.
When you ran ISPs that made use of IRR data for route filtering, did you use any kind of authentication when publishing and maintaining your own records, or advise customers to use such? Did the possibility of malicious data corruption or erasure ever enter your mind?
Agreed; dropping me an email is a fine process for operational security matters. Consider this one so reported.
What will the process be for handling operational security issues regarding future RPKI infrastructure? It is conceivable that there may be no alternative to ARIN, in the ARIN region, for trusted routing information data in the future. Today, we can choose not to use ARIN IRR, and the huge majority of networks who publish IRR data use their ISP databases or MERIT RADB. Are we faced with the possibility that ARIN simply doesn't have personnel capable of handling operational services, yet are forcing ARIN down a road that may make them a sole source of something we all need? If so, perhaps this is a very bad idea in need of further debate. I think the mentality at ARIN is one of paper-pushers and policy guys. That's perfectly fine for an organization whose main function is ... processing paperwork and allocating IP addresses. It is perhaps a very bad idea to ask ARIN to do operational things which they are very clearly unprepared to handle, to such an extent that they may need additional or different personnel, and really need to change their mentality. I understand that the technical side of the RPKI implementation at ARIN is most likely entrusted to Paul Vixie and ISC, which is a good thing. I never read an email from Paul saying, "I think we need to solicit feedback before we patch this BIND issue." DNSSEC progress has taken a very long time, but that hasn't stopped ISC from continuing to provide quick technical solutions to immediate technical problems. What really worries me is ... if there is some serious issue with RPKI infrastructure in the future, will ARIN be able to solve it in an operational time-frame, or won't they? -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts