Re: Has PSI been assigned network 1?
Dale, thanks for the informative response (much better than our regularly scheduled flames). Few remarks:
1) The availability of useful tools (such as prtraceroute) that will only work correctly across you network if your data is registered correctly. (Even if you don't use these tools, your neighbor ISPs may start sending you prtraceroutes across your network that show your routing or your policy description is wrong).
Long time ago i asked our friends at cisco to do the neat thing which in many cases does what prtraceroute would do (note AS tags). Granted, it does not check correspondence with registry data :) SL-DC-1>trace sovcom.kiae.su Translating "SOVCOM.KIAE.SU"...domain server (192.94.207.66) [OK] Type escape sequence to abort. Tracing the route to SOVCOM.KIAE.SU (144.206.136.1) 1 SL-DC-8-F0/0.SPRINTLINK.NET (144.228.20.8) 4 msec 0 msec 4 msec 2 SL-MAE-E-H2/0-T3.SPRINTLINK.NET (144.228.10.42) 8 msec 0 msec 4 msec 3 VIENNA1.VA.ALTER.NET (192.41.177.249) [AS 701] 12 msec 4 msec 4 msec 4 VIENNA3.VA.ALTER.NET (137.39.11.4) [AS 701] 4 msec 96 msec 4 msec 5 AMSTERDAM2.NL.EU.NET (134.222.35.1) [AS 286] 88 msec 204 msec 220 msec 6 AMSTERDAM6.NL.EU.NET (134.222.32.2) [AS 286] 108 msec 104 msec 104 msec 7 HELSINKI1.FI.EU.NET (134.222.27.2) [AS 286] 200 msec 172 msec 128 msec 8 STPETERSBURG.RU.EU.NET (134.222.23.2) [AS 286] 188 msec 196 msec * 9 MOSCOW-M9-2.RELCOM.EU.NET (193.124.254.34) [AS 2118] 204 msec 188 msec 260 msec 10 MOSCOW-KIAE-3.RELCOM.EU.NET (193.124.254.38) [AS 2118] 256 msec 388 msec 424 msec 11 SOVCOM.KIAE.SU (144.206.136.1) [AS 2118] 240 msec 248 msec 188 msec SL-DC-1>
2) The registry is the method by which you specify your policy for the Route Servers (if you use them).
Yes. That's the point -- RSes aren't immediately useful (at least with our particular setup), and registry will not have accurate data if that data is not used to actually do routing.
3) Some other major ISPs will not route nets that are not registered.
My private communications with engineering people of several major ISPs indicate that they're essentially in the same position re. RS as we are.
The email interface to the RADB and IRR is one that has been running at RIPE for a couple of years (also an email/template interface).
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.
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.
Nonetheless, the code is structured in such a way that telnet, web, or other interfaces would be extremely easy to integrate (once authentication was established). What kind of interface would you like to see?
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. 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. 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.
How often ISPs choose to regenerate their config files is a separate question. (I think everyone is planning updates more frequently than twice per week now).
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?)
If you want to add a net to the IRR and then have that change immediately reflected in the configuration files of all ISPs who do full net-based filtering, you may have to have some discussions with them. (But the data will be there and waiting in the registry).
No, there should be some protocol for dynamic updating ISP's copies of the database.
There should be well-defined and useful interface to service providers databases.
I'm not sure what you mean by this. If you issue the command: "whois -h whois.ra.net <net>"
It is retrieval. It is not interactive modification. (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.) It also lacks query functions (what are all networks i'm supposed to hear from peer X?, which networks Lollypop Inc. owns?) 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?
It should be secure.
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. PGP is fine; what about security for on-line interfaces; and who guarantees security of 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. [I understand that i want too much, but then...]
Yes, we were listening in Boulder. Some enhancements (to support AS-path expressions) have all ready been coded, and Cengiz Alaettinoglu and Daniel Karrenberg have all ready set up an IETF working group with an aggressive schedule for implementing for an enhanced language. (An early version of the implementation is started, I believe).
Glad to hear that :) --vadim
On Wed, 19 Apr 1995 20:09:22 -0400 Vadim Antonov wrote:
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.
A lonely, old SUN ELC did the RIPE RR for a long time. We only replaced it recently with a 5 because of the load indexing causes, not because of the load the database queries caused. That ELC did a lot more (it was {ns, ftp, info, www, wais, gopher}.ripe.net) and was not even close to resource starvation. Aren't you mixing things up with some problems at the Internic some time ago? As to the speed of the database, there might be some other weird problem because when I connect to the FTP port of tiny.sprintlink.net, it usually takes more than 30 seconds to get the initial FTP banner. The TCP setup is immediate, data flows much later. Testing port 7 finds that for that port too, TCP setup is immediate but (first) data echo is delayed. I don't see this with most other sites, something to investigate?
(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.)
That is certainly possible, though not documented at this time: - COnnect to the whois port - Send the first search string with -k (keep) - Receive objects, separated by empty lines: inetnum: 234.567.789.0 .... route: 234.567.789.0/40 .... The end of the query is shown by two empty lines, after which the whois server doesn't close but waits for further queries. Send in the next line and the protocol repeats - After 30 secs of inactivity, you get kicked out; no stragglers allowed prtraceroute uses this internally to obtain reasonable performance. (it does a *lot* of whois queries too) Does this address that concern? I do agree that this does not include updates, though. Think of the security requirements and how to implement them. For mail at least, we are able to keep an audit trail (which we do).
It also lacks query functions (what are all networks i'm supposed to hear from peer X?, which networks Lollypop Inc. owns?)
That is provided via WAIS.
PGP is fine; what about security for on-line interfaces; and who guarantees security of RS machines?
I am open for suggestions on how to implement this.. Geert Jan
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
(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.)
It also lacks query functions (what are all networks i'm supposed to hear from peer X?, which networks Lollypop Inc. owns?)
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?
The RPS folks are chartered to work on these types of tools as well as some "what-if" extentions, so that you can check what will happen if you change your policy, before committing the update.
PGP is fine; what about security for on-line interfaces; and who guarantees security of RS machines?
The RS security is, by nessesity, host based. There are filtering MAC bridges in place, single use passwords, and we are working on end2end encryption. I expect that the encryption will be inplace within the quarter.
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.
[I understand that i want too much, but then...]
Not any more than other multimillion dollar entities... :) --bill
participants (4)
-
bmanning＠ISI.EDU -
Daniel Karrenberg -
Geert Jan de Groot -
Vadim Antonov