- Test - lists.nanog.org

Re: Has PSI been assigned network 1?
by Curtis Villamizar 20 Apr '95

20 Apr '95

In message <199504180716.AA12431(a)interlock.ans.net>, Hank Nussbacher writes: > On Mon, 17 Apr 1995 12:00:24 -0400 you said: > >Curtis > > > >BTW- You might try a traceroute to an address in 140.222/16. That's > >the ANS backbone. For example, traceroute 140.222.32.62 would verify > >that you could reach ANS NY POP. Traceroute 140.222.1.1 would give > >you a !H as soon as you reach an ANS interface (look for t3.ans.net in > >the DNS if the response is not from a 140.222 address). > > Will 140.222.0.0 continue to work? We 'ip default-network 140.222.0.0' > and will have to change if this NSFnet backbone net ceases to exist. > I would bet lots of smaller ISPs have this net out there in their > routing tables as gateway of last resort. > > Thanks, > +---------------------------------------------------------------+ > | Hank Nussbacher | > | Inter-University Computer Center IBM | > | Tel-Aviv University Rechov Weizmann 2 > | Ramat Aviv ISRAEL Tel Aviv ISRAEL | > | | > | Work phone: +972-3-6408309 Work phone: +972-3-6978852 | > | Work fax: +972-3-6409118 | > | Home phone: +972-9-920165 | > | Home fax: +972-9-920166 | > | | > | Internet: hank(a)vm.tau.ac.il or hankn(a)vnet.ibm.com | > | | > | Crash dummy of the Israeli Information Highway | > +---------------------------------------------------------------+ The network number 140.222/16 will continue to be the address of the ANS backbone. This network is not going away any time soon. The only conceivable reason (long term maybe - no plan at this point) we might get rid of 140.222 would be if we could compress all our routers and interface numbers into a smaller prefix and wanted to be really good CIDR citizens and renumber our backbone. (very unlikely unless the number allocation problem becomes critical in the years to come). You might be better off directing a default route at your primary provider, though aiming at 140.222 won't make much difference from a distance in the topology. We are aware of the widespread use of 140.222 among smaller providers. Unlike 129.40 (the former T1 backbone, later reassigned to IBM Kingston), 140.222 is not being shutdown. The one practice ANS is trying to stop is our immediate peers pointing a default route at us for the purpose of gaining free transit connectivity to other providers pointing default at other interchanges. To my knowledge, though we are unhappy with the practice, no shutdown ultimatims have been issued. Curtis PS - I don't think any provider will be losing connectivity to 140.222 in the upcoming transition, but would stand corrected if anyone has better information. PPS - Nice .sig "Crash dummy of the Israeli Information Highway". :-)

2 1

Re: Has PSI been assigned network 1?
by jgs＠aads.net 20 Apr '95

20 Apr '95

At 8:50 PM 4/18/95, Vadim Antonov wrote: >> We don't trust our peers. We only accept routes which they are >> registered as providing transit for in the PRDB. When the RADB is in >> use, unless PSI has a route object for 1.0.0.0/8 in the RADB, we still >> won't trust them when they try to pass us 1/8. > >Curtis, you are able to do that only because all others were >legally bound to fill your database. > >I'm not sure people will be spending their resources on >populating database for somebody else's benefit. Then again, I'm not sure that people will be spending their resources exchanging routing information with people who allow junk into their routing. (To put it another way, spending resources troubleshooting other people's brain damage.) What AS690 does is not just bureaucratic silliness. It's also enlightened self-interest (as Curtis keeps saying). If enough people have the sense to want to protect themselves, the Routing Registry will fly. --John

3 2

Re: Has PSI been assigned network 1?
by Dale S. Johnson 20 Apr '95

20 Apr '95

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

1 0

Re: Has PSI been assigned network 1?
by Dale S. Johnson 20 Apr '95

20 Apr '95

> AS 690 has about as complex a set of policies as anyone I can imagine. > RIPE-181 can handle our import policy just fine. We've suggested some > minor syntax changes that would substantially reduce the number of > lines required to express this (without defining a few thousand macros > to accomplish this), but the current syntax does provide the needed > flexibility. Our export policy cannot be expressed in RIPE-181 > because some of our export policy is AS path based. An AS path > extension has already been proposed (or at least batted around on the > rps mailing list). Limited AS path expressions (policy with respect to your neighbors) has been coded and deployed, though not yet announced or generally documented. (Let me know if you're interested in using it). General AS path expressions are in the works. --Dale

1 0

Re: Has PSI been assigned network 1?
by Vadim Antonov 20 Apr '95

20 Apr '95

> There should be a host accepting telnet sessions for on-line > updates (which have to be installed *immediately*, so whoever > added a network can test connectivity and go ahead). >I'm surprised your trouble ticketing system doesn't support a "next >action timer" that allows you to get notification after some time >period, like when the new circuit is supposed to be turned up, or when >the routing reconfiguration is supposed to have been completed so you >can then check connectivity. Our trouble-ticketing system is a mainframe monster (yes, Virginia, it is 3270 :) and i didn't write a more useful one yet. The problem is that the system has to support not only IP-related stuff but also physical-level crap; and there's a lot of baggage there. Sigh. --vadim

1 0

Re: Has PSI been assigned network 1?
by sob＠academ.com 19 Apr '95

19 Apr '95

Vadim, I don't see where filling the database is exclusively to someone else's benefit. Please explain further how Sprintlink and its customers don't benefit from using the RADB. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: bcm!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

3 2

Re: Has PSI been assigned network 1?
by Dale S. Johnson 19 Apr '95

19 Apr '95

Vadim, > Well, there is a big _if_: if things will work w/o RADB (and they > will, for no sane provider will use RADB as the sole source of > exterior information at peering points, not for at least before > it became the proven and stable service) -- people will forget > to update things, cut the corners, etc. You're right: a database that is not used becomes out of date. There are a few things that will encourage ISPs to maintain up-to-date data in the IRR registries: 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). 2) The registry is the method by which you specify your policy for the Route Servers (if you use them). 3) Some other major ISPs will not route nets that are not registered. (Note: the RADB is one portion of the Internet Routing Registry (IRR), which is composed of the RADB, RIPE, MCI, and CANET so far. Registering in one database will soon be sufficient for all purposes globally). > NACRs were so big headache that our implementation people dance > around when they hear that there won't be any NACRs. > > RADB got to be easy to use to become real. The e-mail interface > of NACRs is close to uselessness, and too big headache to deal with. 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). RIPE's user community lists improving the user interface as a rather low priority. 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? > Waiting time on processing is simply ridiculous. > > There should be a host accepting telnet sessions for on-line > updates (which have to be installed *immediately*, so whoever > added a network can test connectivity and go ahead). Updates to the registries are processed and confirmed within a few seconds, and are immediately verifiable by whois query. 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). 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). > 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>" right now, you get the registrations for that net from the PRDB, the RADB, the RIPE database, MCI's database, and CANET's database. If you register in the RADB (or the PRDB, for the moment), then your data is available at the other registries as well. > 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. > RADB should be able to implement _existing_ routing policies, > not the subset which can be defined in RIPE-81 (it currently > can't, there are places which use a lot of _very_ hairy stuff). 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). > Without that i do not see RADB being successful or useful beyond the > point of filtering updates from particularly obnoxious peers. > > --vadim > > From: Guy Middleton <guy(a)ghost.uunet.ca> > To: avg(a)sprint.net, curtis(a)ans.net, jerry(a)fc.net > Subject: Re: Has PSI been assigned network 1? > Cc: nanog(a)merit.edu, prs(a)isi.edu > Message-Id: <95Apr18.213028edt.53028-1(a)ghost.uunet.ca> > Date: Tue, 18 Apr 1995 21:30:28 -0400 > > > Curtis, you are able to do that only because all others were > > legally bound to fill your database. > > > > I'm not sure people will be spending their resources on > > populating database for somebody else's benefit. > > > > (And RADB already has lots of garbadge in it). > > Once the RADB is in general use, we can expect that networks other than ANS > will use it to generate route-filters. There is an interconnect point already > using the CA*net registry, for example. Any active use of the RADB creates an > incentive to ensure that it is accurate. --Dale

1 0

Internet Security tutorials
by stonem＠farnet.org 19 Apr '95

19 Apr '95

FARNET (the Federation of American Research Networks) and CERT (Computer Emergency Response Team) are sponsoring two tutorials on Internet Security. Both of these events will be held at the Radisson Hotel South and Plaza Tower in Minneapolis, MN 55439. on May 10 and May 11. Send information request to seminars(a)farnet.org. Wednesday, May 10 "Internet Security for Managers" _____________________________________________________________ Description: This tutorial helps managers understand what needs to be done to ensure that their computer systems and networks are as securely managed as possible when operating within the Internet community. Attendees are provided with information that will enable them to formulate realistic security policies, procedures, and programs specific to their operating environment. The tutorial addresses the following issues relevant to computer security in the Internet community. - Understanding and recognizing computer security threats - Designing gateway solutions - Developing security procedures - Establishing security programs - Understanding legal issues. Audience: This seminar is designed for managers of computing centers/facilities, individuals tasked to evaluate/initiate Internet connectivity, senior system administrators, and others interested in computer security within the Internet community. Thursday, May 11 Internet Security for UNIX System Administrators _____________________________________________________________ Description: The information presented in this tutorial is based on incidents reported to the CERT Coordination Center. The topics covered include defensive and offensive strategies for system administration, site-specific security policies, and incident handling. This tutorial addresses the following issues relevant to computer security in the Internet community: - Understanding today's security problems: current Internet threats and trends, review of packet sniffer activity, and overview of the potential for real losses. - System administration strategies for securing systems: systems and service configurations, password management, and system administration tools and techniques - Network administration strategies for securing the perimeter: design considerations for firewalls, understanding and planning for network connectivity - Incident Response: how to prepare for and respond to security incidents when they occur - Site security policy: the glue that holds everything together Audience: This tutorial is designed for users and system administrators of hosts using the UNIX Operating System. It is especially suited for system administrators of systems connected to a wide area network based on TCP/IP such as the Internet. Some system administrator experience is assumed. ************************************************************************* Martha Stone-Martin Program Director FARNET...."The Internet Builders" (617) 273-5423 stonem(a)farnet.org

1 0

Re: Has PSI been assigned network 1?
by jgs＠aads.net 19 Apr '95

19 Apr '95

I assume one of the RA folks will respond to this if they see fit. However: At 1:50 PM 4/19/95, Vadim Antonov wrote: >Well, there is a big _if_: if things will work w/o RADB (and they >will, for no sane provider will use RADB as the sole source of >exterior information at peering points, not for at least before >it became the proven and stable service) -- people will forget >to update things, cut the corners, etc. You appear to be conflating the RADB and the RSes. The two are separable. You can use the RADB (or, more generally, the IRR) w/o having to trust the RSes. I think this is a really important point, and one which a lot of people seem to be confused about. >NACRs were so big headache that our implementation people dance >around when they hear that there won't be any NACRs. No comment. >RADB got to be easy to use to become real. The e-mail interface >of NACRs is close to uselessness, and too big headache to deal with. >Waiting time on processing is simply ridiculous. > >There should be a host accepting telnet sessions for on-line >updates This has long existed for the NACR process. >(which have to be installed *immediately*, so whoever >added a network can test connectivity and go ahead). Point granted. >There should be well-defined and useful interface to service >providers databases. > >It should be secure. Is PGP secure enough for you? >RADB should be able to implement _existing_ routing policies, >not the subset which can be defined in RIPE-81 (it currently ^^^^^^^ RIPE-181; it's different. Some people have complained that RIPE-181 is also incapable of expressing their policies; perhaps someone from the RA team can comment on how they intend to address that. >can't, there are places which use a lot of _very_ hairy stuff). > >Without that i do not see RADB being successful or useful beyond the >point of filtering updates from particularly obnoxious peers. Which is already a big win, seeing as how there are a good number of particularly obnoxious peers out there, some of them quite large. >--vadim I have to ask if you have actually looked at the RADB and surrounding pieces at all. I think it addresses a number of the gripes you have raised. --John

1 0

Re: Has PSI been assigned network 1?
by Vadim Antonov 19 Apr '95

19 Apr '95

> We don't trust our peers. We only accept routes which they are > registered as providing transit for in the PRDB. When the RADB is in > use, unless PSI has a route object for 1.0.0.0/8 in the RADB, we still > won't trust them when they try to pass us 1/8. Curtis, you are able to do that only because all others were legally bound to fill your database. I'm not sure people will be spending their resources on populating database for somebody else's benefit. (And RADB already has lots of garbadge in it). --vadim

3 2