Re: Has PSI been assigned network 1?

["Dale S. Johnson" <dsj () merit edu>]

Vadim,

> 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>

Nice.

prtraceroute also has columns on the right to designate how the current
route compares with the registered policy.  (Is the route slow?  Oh:
its taking a tertiary backup path at the moment on this link).

The RIPE PRIDE tools also include other tools:  prcheck, that checks
your policy against your neighbors', and prpath that analyzes 
your global connectivity (according to data in the IRR).  ISI is
also planning other global topology walker tools.

> >  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.

Lets separate the Route Server and Routing Registry questions.

No one will get connectivity to ANSNet's sites unless they register their
routes somewhere in the IRR (RADB, RIPE, MCI, CANET, etc).  If you have
a customer who wants to get to one of those places, he needs to be
registered.  It is my understanding that one or more other large ISPs
have declared the same policy.  The more of the Internet that you can't
get to without registering, the more people will be willing to register.

Route Servers are optimizations.  You can do without them, but as 
complexity of the interconnects grows they can save cycles for your
routers and possibly time negotiating and keeping up to date on N 
bilateral agreements.


> > 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.

My own preference is for a client on the user machine (and API) for
direct authenticated updating of the database.  

> 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 PRDB server was originally down for two fifteen-minute periods per
week (though that grew to two one-hour periods with table growth).  We've
designed that out of the RADB code.

We have purchased multiple machines for this kind of purpose (as well as for
hot backup of the primary machine).  More work to be done, of course,
but system load is not a problem yet.

> > 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?)

Depends on who you're peering with.  If it is with an AS that does
net-based filtering, you are still going to wait until their config
files get updated.  (Though the time required to run the config generator
itself is very small:  most NSSs config files are generated in a few
seconds;  the FIX NSS confg files take up to six minutes).  Getting
someone to do that generation, and to kick the router to use it, is
a different issue.

> > 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.

Under discussion and experimentation now.

> > 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.)

Telnet to radb.ra.net 5042, and type "-H" for help.  We are supporting
an "RPSLserver" on that port.  Currently, the server is optimized to
support queries useful for config file generation, but we will be
adding to that.  (This interface is cryptic:  it is designed to support
human-friendly clients).

Yes, I know that we haven't done much PR about this yet, but that 
should come soon.

> 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?

RIPE's installation of the IRR provides this kind of query facility via
wais.  We can look at more options here, as well.

The entire database is also up for ftp.  Your nasty scripts can have
all the data we have for the asking.  

> > > 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.

Agreed.

> PGP is fine; what about security for on-line interfaces; and who
> guarantees security of RS machines?

CERT was out here working with us on these issues a couple of weeks ago.

> 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 :)

:-)

--Dale