AltDB?

Jeff Wheeler jsw at inconcepts.biz
Mon Jan 10 02:53:31 UTC 2011


On Sun, Jan 9, 2011 at 7:33 PM, John Curran <jcurran at 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 at inconcepts.biz>
Sr Network Operator  /  Innovative Network Concepts




More information about the NANOG mailing list