Has PSI been assigned network 1?

Thu Apr 20 11:24:10 UTC 1995

  > Vadim Antonov <avg at 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