Vadim Antonov <avg@sprint.net> writes:
e-mail is fine when you file one change a week. When you have to keep a full-time person just to process NACRs (as we are) things are different.
Again: Do not confuse the transport with the update mechanism. We get quite a few messages updating multiple objects, or quite simply dumping a locally stored database onto us. We detect and ignore noop updates. To give you an impression of the update load I cite from our 1994 annual report: "The RIPE NCC maintains the RIPE network management database containing information about IP networks, DNS domains, Routing Policies and the appropriate contact persons. At the end of 1994 the database contained 63490 objects. During the year the Database answered slightly more than 2.2 million queries and processed 23203 update requests for 227933 objects. During 1994 the database software has been re-designed and re-implemented to support classless IP addressing as well as routing registry functions. The software is now being used by routing registries worldwide." So the average number of objects upodated per update request is aout 9.
RIPE's user community lists improving the user interface as a rather low priority.
Yeah -- but that is exactly what can kill IRR in US.
It is not because our (main) user community is in Europe. It is because turnaround on the mail interface is immediate. Actually people have mentioned to me that they prefer e-mail because it leaves nice local audit trails of who did what at no extra cost.
telnet & web. Also, some formalized interface for direct database interaction is necessary. We configure routers automatically when implementation people create appropriate recodrs in our internal database. We'd like to do that with entering routing data as well.
You mean in real time? Or periodically. The latter can be done. Again: You are looking at a highly distributed database problem.
E-mail is not sufficient because you have to parse replies. I would prefer SMTP-style interface, so when our database program is used to configure routing it can automatically connect the IRR and update it.
Our replies are as easily pareseable as SMTP style stuff.
There should be two different IRR machines for AS owners only (the one which allows updates) and the one which responds on queries from the general public, so we can get reasonable responsiveness, w/o "please try again"s.
The real soloution is to have reasonable responsiveness for everybody. This is not hard to do. We have done it for a number of years.
This is inacceptable. It should be done immediately; or people will simply ignore the whole thing (why should we wait when we simply can establish BGP peering, so it will work immediately?)
Confusion of RR and RS again. What you need in the RR is actually even more than immediately. You need updates coordinated in time between multiple parties. Example: Customer changes provider effective noon tomorrow.
No, there should be some protocol for dynamic updating ISP's copies of the database.
Yes. Currently this is: get the whole thing by ftp. We are working on improvements.
(And it is slow. I would like to be able to establish a connection and do a thousand of queries. Some my nasty scripts call whois several thousand times.)
The RIPE whois server has an option to keep the connection open for multiple queries. The PRIDE tools use that.
It also lacks query functions (what are all networks i'm supposed to hear from peer X?, which networks Lollypop Inc. owns?)
You can do most things in the client. There is a PRIDE tool for the former question. Some things need more query functions and they are coming. Note that complicated query functions are a trade off with response time in a whois server. MERIT has a server with more functionality.
For example, one menu of Sprint's internal database:
Please enter customer ID [type Return if not known]:
You may try to find the customer by:
1) Organization name 2) City name 3) Name of a person 4) Telephone/fax number 5) E-mail address 6) IP network address 7) Dial-in phone number
Your choice?
At the moment you can do that most efficiently with a local copy of the database (which is available). RIPE also supports WAIS lookups on the RIPE RR.
This has lots of aspects. We have implemented PGP for the interface (not yet released), and are working with the CERT to establish that other security concerns are addressed. More specific discussion is welcome on a smaller list.
It should be _very_ secure. It would be very attractive target for hackers.
The RIPE datbase has been operated for five years without authorisation and authentication *but* with extensive audit trailing. We have had no major incidents and three incidents of unauthorised and intentional modifications all of which could be cleared up and fixed quickly. We now have an authorisation framework and some simple authentication methods implemented. Since this is in place no unauthorised modifications have been brought to my attention. The autorisation framework allows for a number of authentication methods and PGP is currently being discussed. The main issue here is the maintenance of the public keys. At the RIPE NCC we currently think they should be stored in the database itself because other methods would create an unacceptable administrative overhead.
PGP is fine; what about security for on-line interfaces;
Exactly that problem is why we have not deployed the working code we have.
and who guarantees security of RS machines?
The operators of those machines. Either you trust them or you don't. Again I am mainly concerned with the RR machines and not the RS machines.
A multimillion corporation cannot put its business at risk of being dependent on a machine controlled by somebody else, w/o contractual obligations on adequate security.
There are multiple levels of dependency, trust, and legal relations. The RIPE NCC and maintenance of the European RR is funded by the European ISPs. They have no legal guarantees on its security at the moment but I am quite sure I would hear if that left to be desired. If we would not fix problems I am sure the NCC would experience a reduction in resources available. ;-) Daniel