- Test - lists.nanog.org

CERT Advisory CA-95:01.IP.spoofing.attacks.and.hijacked.terminal.connections
by cert-advisory＠cert.org 23 Jan '95

23 Jan '95

============================================================================= CA-95:01 CERT Advisory January 23, 1995 IP Spoofing Attacks and Hijacked Terminal Connections ----------------------------------------------------------------------------- The CERT Coordination Center has received reports of attacks in which intruders create packets with spoofed source IP addresses. These attacks exploit applications that use authentication based on IP addresses. This exploitation leads to user and possibly root access on the targeted system. Note that this attack does not involve source routing. Recommended solutions are described in Section III below. In the current attack pattern, intruders may dynamically modify the kernel of a Sun 4.1.X system once root access is attained. In this attack, which is separate from the IP spoofing attack, intruders use a tool to take control of any open terminal or login session from users on the system. Note that although the tool is currently being used primarily on SunOS 4.1.x systems, the system features that make this attack possible are not unique to SunOS. As we receive additional information relating to this advisory, we will place it, along with any clarifications, in a CA-95:01.README file. CERT advisories and their associated README files are available by anonymous FTP from info.cert.org. We encourage you to check the README files regularly for updates on advisories that relate to your site. ----------------------------------------------------------------------------- I. Description This description summarizes both the IP spoofing technique that can lead to root access on a system and the tool that intruders are using to take over open terminal and login connections after they get root access. We are currently seeing attacks in which intruders combine IP spoofing with use of the tool. However, these are two separate actions. Intruders can use IP spoofing to gain root access for any purpose; similarly, they can highjack terminal connections regardless of their method of gaining root access. IP spoofing To gain access, intruders create packets with spoofed source IP addresses. This exploits applications that use authentication based on IP addresses and leads to unauthorized user and possibly root access on the targeted system. It is possible to route packets through filtering-router firewalls if they are not configured to filter incoming packets whose source address is in the local domain. It is important to note that the described attack is possible even if no reply packets can reach the attacker. Examples of configurations that are potentially vulnerable include - routers to external networks that support multiple internal interfaces - routers with two interfaces that support subnetting on the internal network - proxy firewalls where the proxy applications use the source IP address for authentication The IP spoofing attacks we are currently seeing are similar to those described in two papers: 1) "Security Problems in the TCP/IP Protocol Suite" by Steve Bellovin, published in _Computer Communication Review_ vol. 19, no. 2 (April 1989) pages 32-48; 2) "A Weakness in the 4.2BSD Unix TCP/IP Software" by Robert T. Morris. Both papers are available by anonymous FTP from ftp.research.att.com:/dist/internet_security Bellovin paper: ipext.ps.Z Morris paper: 117.ps.Z Services that are vulnerable to the IP spoofing attack include SunRPC & NFS BSD UNIX "r" commands anything wrapped by the tcp daemon wrappers - site dependent; check your configuration X windows other applications that use source IP addresses for authentication Hijacking tool Once the intruders have root access on a system, they can use a tool to dynamically modify the UNIX kernel. This modification allows them to hijack existing terminal and login connections from any user on the system. In taking over the existing connections, intruders can bypass one-time passwords and other strong authentication schemes by tapping the connection after the authentication is complete. For example, a legitimate user connects to a remote site through a login or terminal session; the intruder hijacks the connection after the user has completed the authentication to the remote location; the remote site is now compromised. (See Section I for examples of vulnerable configurations.) Currently, the tool is used primarily on SunOS 4.1.x systems. However, the system features that make this attack possible are not unique to SunOS. II. Impact Current intruder activity in spoofing source IP addresses can lead to unauthorized remote root access to systems behind a filtering-router firewall. After gaining root access and taking over existing terminal and login connections, intruders can gain access to remote hosts. III. Solutions A. Detection IP spoofing If you monitor packets using network-monitoring software such as netlog, look for a packet on your external interface that has both its source and destination IP addresses in your local domain. If you find one, you are currently under attack. Netlog is available by anonymous FTP from net.tamu.edu:/pub/security/TAMU/netlog-1.2.tar.gz MD5 checksum: 1dd62e7e96192456e8c75047c38e994b Another way to detect IP spoofing is to compare the process accounting logs between systems on your internal network. If the IP spoofing attack has succeeded on one of your systems, you may get a log entry on the victim machine showing a remote access; on the apparent source machine, there will be no corresponding entry for initiating that remote access. Hijacking tool When the intruder attaches to an existing terminal or login connection, users may detect unusual activity, such as commands appearing on their terminal that they did not type or a blank window that will no longer respond to their commands. Encourage your users to inform you of any such activity. In addition, pay particular attention to connections that have been idle for a long time. Once the attack is completed, it is difficult to detect. However, the intruders may leave remnants of their tools. For example, you may find a kernel streams module designed to tap into existing TCP connections. B. Prevention IP spoofing The best method of preventing the IP spoofing problem is to install a filtering router that restricts the input to your external interface (known as an input filter) by not allowing a packet through if it has a source address from your internal network. In addition, you should filter outgoing packets that have a source address different from your internal network in order to prevent a source IP spoofing attack originating from your site. The following vendors have reported support for this feature: Bay Networks/Wellfleet routers, version 5 and later Cabletron - LAN Secure Cisco - RIS software all releases of version 9.21 and later Livingston - all versions If you need more information about your router or about firewalls, please contact your vendor directly. If your vendor's router does not support filtering on the inbound side of the interface or if there will be a delay in incorporating the feature into your system, you may filter the spoofed IP packets by using a second router between your external interface and your outside connection. Configure this router to block, on the outgoing interface connected to your original router, all packets that have a source address in your internal network. For this purpose, you can use a filtering router or a UNIX system with two interfaces that supports packet filtering. NOTE: Disabling source routing at the router does not protect you from this attack, but it is still good security practice to do so. Hijacking tool There is no specific way to prevent use of the tool other than preventing intruders from gaining root access in the first place. If you have experienced a root compromise, see Section C for general instructions on how to recover. C. Recovery from a UNIX root compromise 1. Disconnect from the network or operate the system in single-user mode during the recovery. This will keep users and intruders from accessing the system. 2. Verify system binaries and configuration files against the vendor's media (do not rely on timestamp information to provide an indication of modification). Do not trust any verification tool such as cmp(1) located on the compromised system as it, too, may have been modified by the intruder. In addition, do not trust the results of the standard UNIX sum(1) program as we have seen intruders modify system files in such a way that the checksums remain the same. Replace any modified files from the vendor's media, not from backups. -- or -- Reload your system from the vendor's media. 3. Search the system for new or modified setuid root files. find / -user root -perm -4000 -print If you are using NFS or AFS file systems, use ncheck to search the local file systems. ncheck -s /dev/sd0a 4. Change the password on all accounts. 5. Don't trust your backups for reloading any file used by root. You do not want to re-introduce files altered by an intruder. --------------------------------------------------------------------------- The CERT Coordination Center thanks Eric Allman, Steve Bellovin, Keith Bostic, Bill Cheswick, Mike Karels, and Tsutomu Shimomura for contributing to our understanding of these problems and their solutions. --------------------------------------------------------------------------- If you believe that your system has been compromised, contact the CERT Coordination Center or your representative in Forum of Incident Response and Security Teams (FIRST). If you wish to send sensitive incident or vulnerability information to CERT staff by electronic mail, we strongly advise that the e-mail be encrypted. The CERT Coordination Center can support a shared DES key, PGP (public key available via anonymous FTP on info.cert.org) or PEM (contact CERT staff for details). Internet E-mail: cert(a)cert.org Telephone: +1 412-268-7090 (24-hour hotline) CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4), and are on call for emergencies during other hours. Fax: +1 412-268-6989 CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 USA Past advisories, CERT bulletins, information about FIRST representatives, and other information related to computer security are available for anonymous FTP from info.cert.org. CERT is a service mark of Carnegie Mellon University.

1 0

Re: Listing of Peering NSPs at every NAP?
by Pushpendra Mohta 23 Jan '95

23 Jan '95

Pushpendra Mohta writes: > > Carlos M. Gutierrez writes: > > > > Hello gentlemen/-ladies, > > > > I was wondering if anybody knows of a listing of National Service > > Providers that peer at each NAP? Something somewhat like the following: > > > > SPRINT-NAP: SprintLink > > UUNET > > NearNet > > Net99 > > SURANet > > etc. > > > > PAC-BELL-NAP: ANS CO-RE/AOL > > Netcom > > etc., etc. > > > > Any place this info exists FTP-friendly? > > > > I suppose I could spend a couple of hours doing traceroutes; I would love > > to...honest...but for the moment I am limited to CompuZerve access... > > > > TIA, > > > > Carlos M. Gutierrez 74453.3064(a)compuserve.com > > San Juan, Puerto Rico > > > > p.s. If possible, also e-mail replies to me directly, as I never received > > confirmation of my subscription to this list. > > > > > > I am having someone drawup a map served by mosaic based on information > provided by Sean Doran of Sprint. > > It will be available over the weekend at > > http://www.cerf.net/cerfnet/interconnects.html > > Some information is available at http://www.ra.net/transition.html > > --pushpendra > > Pushpendra Mohta pushp(a)cerf.net +1 619 455 3908 > Director, CERFnet +1 800 876 2373 > > Ok, the first cut of this map is up, no doubt with some errors. Please let meg(a)cerf.net know of errors. --pushpendra Pushpendra Mohta pushp(a)cerf.net +1 619 455 3908 Director, CERFnet +1 800 876 2373

2 1

Amended NETSTAT Minutes for 7 Dec. 1995
by Gene Hastings 23 Jan '95

23 Jan '95

[This incorporates the corrections sent to NANOG. Slides will be available online shortly for BBN, InternetMCI, Sprint NAP and Sprintlink.] Network Status Reports met on 7 December, 1994 from 0930 to 1145. Scheduled presentations were ANS (Rob Lehman), NSFNET Transition (Elise Gerich), InternetMCI (Phill Gross), BBN (John Curran), Sprint NAP (Tim Clifford) and SprintLink (Sean Doran) In addition to the presentations and Q&A, several meta-issues were raised or implied (furished along with my attempt to digest the pulse of the group). Is it appropriate to give what is essentially a marketing presentation at IETF? The consensus seems to be "no" if it is solely and blatantly such, but there is dissention as to where the line is. With the increasing activity of for profit concerns in the Internet, will it be possible to continue the openness of past years' presentations wrt traffic, performance, uptime statistics, etc.? [Despite the fears or predictions of some, there appears to come continuing openness, AND examples of extremely closed practices. I think that collegial backpressure has ceased to be sufficient to maintain the historical levels of disclosure and cooperation. - efh] In the light of these questions, what is the charter of this group? (including what is desirable vs. what is acceptable). [I think this is an ongoing process. Does commercial necessarily mean concealed? I think in the context of an interconnected, interdependent environment, it can't in the long run. - efh] Beyond concerns about openness, there are areas of concern not being addressed at all: What is the forum for operations, engineering and troubleshooting above TCP/UDP? Traditional IP regionals and carriers have been content to (determined to?) focus their energies on transport and routing. What is the forum for general end-to-end problem solving? Presentations: ANS Rob Lehman,<rll(a)ans.net> [See slides - only supplemental notes follow] ANSNET traffic surpassed 100m inbound packets in Nov.! CIDR note: after AUP disappears, there ought to be further aggregation possible ANS' NAP connectivity status: Connection to the Sprint NAP was installed on 9-21-94. At this time (7 Dec. 94) it's only been operational since 2 weeks, but substantial traffic has been exchanged Connection to the PacBell NAP was installed on 10-14-94, but is not in production. Connection to the Ameritech NAP was installed on 11-22-94, but is not in production. A MAE+ FDDI Installation plan has been established. Its exact schedule is contingent on logistics. Real Soon Now. ANS did link optimizations for cross-country trunking, to address an imbalance in the relative utilizations of their northern and southern routes. After testing, they are further considering deployment of Random Early Drop. Transition Elise Gerich <epg(a)merit.edu> [No slides - see contemporaneous presentations to IESG, etc.] NONE of the ENSSen have been retired. The regionals' transition to non-NSF Inter-Regional Connectivity has been slow. Target dates of Nov. 1 and Dec. 1 have been missed, Merit is hoping for ~ Jan. 1 terminations + 60 days... THEnet and MOREnet have made the transition to SprintLink. SURAnet has moved traffic to MCInet, but has not formally notified Merit of the ability to terminate the ENSS connection. (THEnet was previously sharing Inter-Regional Connectivity with Sesquinet ) CA*NET is close to transition to MCI Interconnection point status: The Sprint NAP has connections from Sprint, MCI, and NSFNET. In DC, at MFS facilities, everyone is on MAE and is committed to connecting to MAE+. At the Ameritech NAP, MCI and NSFNET are about to start peering, with Sprint to connect soon. PacBell has MCI and ANS are peering, and Sprint will connect soon. Route servers are present at MAE, the PacBell NAP, the Ameritech and the Sprint NAP. Routing DB deployment and transition. The applications are moving from PRDB (@merit) to RA (db-admin(a)radb.ra.net) At some point, Merit will do dual use of NACR and RADB forms, followed by retirement of NACR (transition ca. Jan. 15.) Merit has recommended to NSF that during transition (Jan.-Jun., there should be no need to specify AUP. If anyone is still relying on PRDB reports they should contact Dale!!! InternetMCI Phill Gross <0006423401(a)mcimail.com> [see pretty slides. In color. Phill apologized.] Problems were experienced transitioning SURAnet, thus delaying the CoREN schedule. "DS3 networking is not yet a commodity service." - experienced some problems in the routers. Questions from the floor: What management platform does InternetMCI use? Phill: Hewlett- Packard OpenView, plus homegrown tools and extensions. What Other nets beside CoREN is MCI serving? Phill: CA*NET is partially transitioned...(at 3Mb), WIDE (at T1) and BTnet (at E1) InternetMCI NAP connectivity status: Chicago (Ameritech) was connected a the end of last week, MCI is connected and peering at Sprint, MAE and CIX. ANS and MCI are interconnected at FDDI at Hayward CA. common PoP (Phill: Thanks for the cooperation, ANS!) Q: When will MCI be connected to FIX-W? Phill: I don't know. It's underway, maybe by the end of year, approximately the same as CIX- SMDS, MAE+. Q: What's the status of the vBNS? Phill: we're deploying a testnet, and full rollout 1Q95 at OC-3. The testnet should be operational before Christmas. BBN John Curran <curran(a)bbn.com> [Admittedly marketing slides.] BBN is upgrading the NEARNET spine in the Boston area, migrating from microwave Ethernet to fiber (MFS 10Mb over NYNEX T3). Currently BBN has almost 2000 SNMP managed items... Operations/NOC/NIC tip: you can head off phone calls by giving seminars! BBN is now offering "Turnkey Internet Server" (Pentium/BSDi) Internet Site Patrol - managed firewall (BBN CONTROLS it), with remote management done by BBN ISC over a secure channel. It's derived from TIS products, and supports telnet, ftp, smtp, nntp, www, x BBN strenuously wants to know how to pursue end-to-end problem solving (they still subscribe to 'the router is BBN's, we control the horizontal, we control the vertical). Sprint NAP, Tim Clifford <tcliff(a)sprint.net>(New PI) Report on the Sprint "NY" NAP (in Southern NJ). It is now (Dec. 94) a dual FDDI ring, and in Jan. will be converted to a DEC Gigaswitch. [See before and after diagrams]. Connected, parties include MCI, NSFNET, Sprint and Cerfnet. A Route Server is present and running. Aside: Sprint has "always thought about ATM" [the implication being that they felt is wasn't ready - efh] Question: the DEC GigaSwitch has DS3 cards. Have you considered access this way? Tim: not really. [It's my understanding that a GS ATM interface can only talk to other GS. - efh] Q: being already co-located, can folks try alternate interconnect technologies? Tim: likely. Try us. SprintLink, Sean Doran <smd(a)sprint.net> Sprintlink's T1 backbone was melting down, and was supplanted by a parallel T1 net. The parallel T1 links are being converted to DS-3s in the next few weeks.[see diagram]. T3 customers feed directly into BB routers to avoid saturating local FDDI rings For trans-US international connectivity, ICM has 2 T3 between Stockton, CA and DC. The design goal in separation of SprintLink and ICM was the assurance of symmetry of routing. [Context?] preservation of next hop in routing is critical feature (could not wait for IDRP) Q: What about fears of an ASpath explosion in routing tables? Sean: Too late. Already here! Although a wise man might urge that one suffer fools gladly, this should not be construed as license for any fool to demand that one do so. -Frederick William Kantor

1 0

Re: Draft NETSTAT Minutes for 7 Dec. 1995
by Sean Doran 20 Jan '95

20 Jan '95

| Is this the GIX-like proposal which suggests a layer-two bridge between | the East and West Coasts? It is more of a last-resort IP-layer glue for the world's R&E communities, and just one of the various ideas floating around about how to ensure Asia-Pacific (mostly but not exclusively PACCOM/NSI)/European and African (mostly but not exclusively ICM) interconnectivity among R&E nets. | (Who should pay to connect, for example, Asia-Pacific and Europe? | Asia, Pacific and Europe? NSF? Donation by Sprint?) Interesting question, however, I think that there is ample room for cooperation within the bounds of the ICM cooperative agreement between NSF and Sprint. This really is something that has to be answered by people higher up than me, though. The general idea is that this would last no longer than the remaining year of the cooperative agreement, and that this would be a way of allowing non-US R&E networks to buy some time as they work through the long process of dealing with adjusting international connectivity. Sean.

1 0

Re: Draft NETSTAT Minutes for 7 Dec. 1995
by salo＠msc.edu 20 Jan '95

20 Jan '95

> Date: Fri, 20 Jan 1995 00:37:54 -0500 > From: Sean Doran <smd(a)sprint.net> > To: hastings(a)psc.edu, smd(a)sprint.net > Subject: Re: Draft NETSTAT Minutes for 7 Dec. 1995 > Cc: nanog(a)merit.edu > > Below is another bit of postscript I have thrown together. > > It's a map of a backbone that Peter L. and I have been > telling people is a good idea for ICMnet, especially in > light of the possible disconnection of Asia-Pacific, > European, Latin American, African, and Carribbean > R&E networks from each other as a result of the > NSFNET transition. In such a situation, ICMnet could > potentially act as glue between the various R&E networks > around the world. > [...] Is this the GIX-like proposal which suggests a layer-two bridge between the East and West Coasts? (Who should pay to connect, for example, Asia-Pacific and Europe? Asia, Pacific and Europe? NSF? Donation by Sprint?) -tjs

1 0

Re: Finally, a small commentary
by Tired of the Information Superhype 20 Jan '95

20 Jan '95

Thanks for the maps. Your proposal is very interesting to this soon-to-be-SprintLink site. Currently we plan to bring up 3xT1 to Stockton in a few weeks, and I wonder why exactly you chose Cheyenne rather than Salt Lake or Ogden? I assume your ROW follows the Union Pacific tracks, but there is little local traffic in Cheyenne. I would very much like to see a major ISP put a POP in this area with a T3 to the Bay Area NAP, so that the University of Utah could maintain a T3 link to the world (which we currently have from ANS). The Salt Lake area has considerable local traffic (as does Denver of course, but that's not on the UP main line). -- Walt-------

1 0

Finally, a small commentary
by Sean Doran 20 Jan '95

20 Jan '95

I shall try to bring a Sprint fibre-map on a slide to NANOG as that will clarify why we changed our current engineering plan from this: SEA-------CHI------PEN | | | STK-------K.C.-----D.C | | | ANA-------FT.W.----ATL to this SEA-------CHI------PEN | / \ | STK---CHE< >NAS--D.C. | \ / | ANA------FT.W.-----ORL (SEAttle WA, CHIcago IL, PENnsauken NJ STocKton CA, Kansas City MO, CHEyenne WY, NAShville TN, ANAheim CA, ForT Worth TX, ORLando FL) The idea was not to make a backbone which looks like the Sprint logo in a box. :) Most of the new design evolved out of a plan to build a POP in Cheyenne WY to save on back-haul costs bettween SprintLink and customers in places like Denver and Salt Lake City. The fibre paths support either model fairly well, but the general impression is that we can save on DS3 and backhaul mileage (both of which are expensive) under the newer plan, assuming we are running forward with Cheyenne. Also, the new plan better matches east-west traffic flow to the current fibre plant, something we are keen on doing so we can avoid longer-than-necessary north-south detours. Finally the switching delay in a series of nominally working Cisco routers in either of the paths above is in many cases less than the added speed-of-light delay through Kansas City. (There is a phone company HQ in Kansas City that tends to slow down passing photons...) Ideally we will settle finally on a plan that strikes a good balance between delays through our POPs vs. delays between our POPs. Provisioning and build-out will start towards the end of this quarter. Sean. P.S.: Oh, I should reiterate that this is a purely defensive backbone design that is based on the assumption that we will scale upwards from DS3 quickly (we anticipate OC3 or 4xDS3 by the end of the year; which depends on whether we have multiple OC3 customers or not), that we have no real idea where inter-carrier touchdown points will evolve beyond the NAPs, MAEs and so forth (we see a need for one in the Texas area already, for example), that we have no concrete idea of what our aggregate egress/ingress bandwidths will be ("big") or how much of a bias we will see towards the D.C. and San Francisco areas as opposed to elsewhere, and finally, we are not fully certain where we will see a big need to build local POPs. All of this means we need to remain flexible and adaptable first and foremost. I am not terribly fond of the model for reasons I explained at IETF, however, given what we know and what we can anticipate and what we *can't* anticipate, the current designs are, imho, fairly reasonable compromises.

1 0

Re: Draft NETSTAT Minutes for 7 Dec. 1995
by Sean Doran 20 Jan '95

20 Jan '95

Finally, here is a bit of postscript which details how we have constructed all our POPs. The notes on the right hand side are some of the issues Peter L. and I raised at the San Jose IETF netstat meeting. Also, what's not there is a discussion about how having most customers be behind per-POP ASes allows our various peers to route towards us geographically based on AS path. This may prove useful for the other IRCs and NSPs who peer with us in multiple locations, as a tool for load balancing and working on symmetrical routing. Other than customer counts, current bandwidth issues and thoughts on scaling upwards from our Phase I (page 1) and Ia (page 2) T3 backbone to a network with faster pipes or a bigger aggregate of bandwidth, this is the last bit of doodling I raised during my talk at the IETF netstat. (I can talk more about those at NANOG and about our perceived need and rationale for yet more peering points for use by the big IP carriers, how we would like to do address allocation and so forth). Sean. - -- # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # pop.ps # echo x - pop.ps sed 's/^X//' >pop.ps << 'END-of-pop.ps' X%!PS-Adobe-2.0 X%%Title: /tmp/xfig-fig029087 X%%Creator: fig2dev X%%CreationDate: Fri Jan 20 01:28:57 1995 X%%For: smd(a)isis.sprintlink.net (Sean Doran) X%%Orientation: Landscape X%%BoundingBox: 97 57 514 735 X%%Pages: 1 X%%EndComments X/$F2psDict 200 dict def X$F2psDict begin X$F2psDict /mtrx matrix put X/l {lineto} bind def X/m {moveto} bind def X/s {stroke} bind def X/n {newpath} bind def X/gs {gsave} bind def X/gr {grestore} bind def X/clp {closepath} bind def X/graycol {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul X4 -2 roll mul setrgbcolor} bind def X/col-1 {} def X/col0 {0 0 0 setrgbcolor} bind def X/col1 {0 0 1 setrgbcolor} bind def X/col2 {0 1 0 setrgbcolor} bind def X/col3 {0 1 1 setrgbcolor} bind def X/col4 {1 0 0 setrgbcolor} bind def X/col5 {1 0 1 setrgbcolor} bind def X/col6 {1 1 0 setrgbcolor} bind def X/col7 {1 1 1 setrgbcolor} bind def X /DrawEllipse { X /endangle exch def X /startangle exch def X /yrad exch def X /xrad exch def X /y exch def X /x exch def X /savematrix mtrx currentmatrix def X x y translate xrad yrad scale 0 0 1 startangle endangle arc X savematrix setmatrix X } def X X end X/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def X/$F2psEnd {$F2psEnteredState restore end} def X%%EndProlog X X$F2psBegin X0 setlinecap 0 setlinejoin X68.5 54.0 translate 90 rotate 0.720 -0.720 scale X0.500 setlinewidth X% Ellipse Xn 339 299 60 20 0 360 DrawEllipse gs col-1 s gr X% Polyline Xn 279 239 m 279 159 l 199 159 l 199 239 l clp gs col-1 s gr X% Polyline Xn 479 239 m 479 159 l 399 159 l 399 239 l clp gs col-1 s gr X% Polyline Xn 239 239 m 319 279 l gs col-1 s gr X% Polyline Xn 439 239 m 359 279 l gs col-1 s gr X2.000 setlinewidth X% Polyline Xn 239 159 m 199 119 l 119 119 l gs col-1 s gr Xn 143.000 125.000 m 119.000 119.000 l 143.000 113.000 l gs 2 setlinejoin col-1 s gr X% Polyline Xn 439 159 m 479 119 l 559 119 l gs col-1 s gr Xn 535.000 113.000 m 559.000 119.000 l 535.000 125.000 l gs 2 setlinejoin col-1 s gr X0.500 setlinewidth X% Polyline Xn 239 439 m 239 359 l 159 359 l 159 439 l clp gs col-1 s gr X% Polyline Xn 359 439 m 359 359 l 279 359 l 279 439 l clp gs col-1 s gr X% Polyline Xn 479 439 m 479 359 l 399 359 l 399 439 l clp gs col-1 s gr X% Polyline Xn 599 439 m 599 359 l 519 359 l 519 439 l clp gs col-1 s gr X% Polyline Xn 199 359 m 319 319 l gs col-1 s gr X% Polyline Xn 319 359 m 319 319 l gs col-1 s gr X% Polyline Xn 439 359 m 359 319 l gs col-1 s gr X% Polyline Xn 559 359 m 359 319 l gs col-1 s gr X% Polyline Xn 179 439 m 179 484 l 179 479 l gs col-1 s gr X% Polyline Xn 199 439 m 199 484 l gs col-1 s gr X% Polyline Xn 219 439 m 219 479 l gs col-1 s gr X% Polyline Xn 299 439 m 299 479 l gs col-1 s gr X% Polyline Xn 319 439 m 319 484 l gs col-1 s gr X% Polyline Xn 339 439 m 339 484 l gs col-1 s gr X% Polyline Xn 414 439 m 414 479 l 414 474 l gs col-1 s gr X% Polyline Xn 439 439 m 439 479 l gs col-1 s gr X% Polyline Xn 459 439 m 459 479 l gs col-1 s gr X% Polyline Xn 539 439 m 539 479 l gs col-1 s gr X% Polyline Xn 554 439 m 554 494 l 554 489 l gs col-1 s gr Xn 579 484 m 579 484 l gs col-1 s gr Xn 574 494 m 574 494 l gs col-1 s gr X% Polyline Xn 574 439 m 574 479 l gs col-1 s gr X4.000 setlinewidth X% Polyline Xn 459 239 m 459 279 l gs col-1 s gr X% Polyline Xn 219 239 m 219 279 l gs col-1 s gr X 1 setlinecap [1 9.000000] 9.000000 setdash X% Polyline Xn 259 159 m 259 79 l 539 79 l gs col-1 s gr X [] 0 setdash 0 setlinecap Xn 499.000 69.000 m 539.000 79.000 l 499.000 89.000 l gs 2 setlinejoin col-1 s gr X [12.000000] 0 setdash X% Polyline Xn 419 159 m 419 39 l 159 39 l gs col-1 s gr X [] 0 setdash Xn 199.000 49.000 m 159.000 39.000 l 199.000 29.000 l gs 2 setlinejoin col-1 s gr X1.000 setlinewidth X% Polyline Xn 199 199 m 119 199 l gs col-1 s gr X/Times-Roman findfont 12.00 scalefont setfont X249 514 m Xgs 1 -1 scale (Customer connections) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X169 379 m Xgs 1 -1 scale (Customer) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X169 397 m Xgs 1 -1 scale (Attach) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X169 415 m Xgs 1 -1 scale (Router) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X414 192 m Xgs 1 -1 scale (Backbone) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X414 210 m Xgs 1 -1 scale (Router) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X214 214 m Xgs 1 -1 scale (Router) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X214 194 m Xgs 1 -1 scale (Backbone) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X484 104 m Xgs 1 -1 scale (DS3) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X594 124 m Xgs 1 -1 scale (To next POP) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X34 114 m Xgs 1 -1 scale (To next POP) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X164 104 m Xgs 1 -1 scale (DS3) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X319 299 m Xgs 1 -1 scale (FDDI) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X159 289 m Xgs 1 -1 scale (High speed customer) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X159 307 m Xgs 1 -1 scale (link) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X444 294 m Xgs 1 -1 scale (High speed customer) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X444 312 m Xgs 1 -1 scale (link) col-1 show gr X/Times-Roman findfont 24.00 scalefont setfont X679 199 m Xgs 1 -1 scale (Current POP architecture) col-1 show gr X/Times-Roman findfont 24.00 scalefont setfont X679 232 m Xgs 1 -1 scale (SprintLink) col-1 show gr X/Times-Roman findfont 8.00 scalefont setfont X209 229 m Xgs 1 -1 scale (AS 1239) col-1 show gr X/Times-Roman findfont 8.00 scalefont setfont X409 229 m Xgs 1 -1 scale (AS 1239) col-1 show gr X/Times-Roman findfont 8.00 scalefont setfont X174 429 m Xgs 1 -1 scale (AS 1790) col-1 show gr X/Times-Roman findfont 8.00 scalefont setfont X419 424 m Xgs 1 -1 scale (AS 1790 ) col-1 show gr X/Times-Roman findfont 8.00 scalefont setfont X539 424 m Xgs 1 -1 scale (AS 1790) col-1 show gr X/Times-Roman findfont 8.00 scalefont setfont X299 424 m Xgs 1 -1 scale (AS 1790) col-1 show gr X/Times-Roman findfont 6.00 scalefont setfont X39 579 m Xgs 1 -1 scale (Sean Doran <smd(a)sprint.net>) col-1 show gr X/Times-Roman findfont 6.00 scalefont setfont X39 591 m Xgs 1 -1 scale (Vadim Antonov <avg(a)sprint.net>) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X159 194 m Xgs 1 -1 scale (Ethernet for service machines) dup stringwidth pop neg 0 rmoveto col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X159 219 m Xgs 1 -1 scale ($news, nameservers, mbone...$) dup stringwidth pop neg 0 rmoveto col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X679 259 m Xgs 1 -1 scale (Two or more backbone boxes with) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X679 279 m Xgs 1 -1 scale (separate physical paths improve redundancy.) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X679 309 m Xgs 1 -1 scale (Dual FDDI hubs or FDDI switch and backup) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X679 329 m Xgs 1 -1 scale (FDDI hub for redundant inter-router LAN) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X679 359 m Xgs 1 -1 scale (High speed customers attach) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X679 374 m Xgs 1 -1 scale (to backbone boxes to avoid saturating) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X679 389 m Xgs 1 -1 scale (the FDDI fabric.) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X679 419 m Xgs 1 -1 scale (Backbone boxes are in AS 1239) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X679 434 m Xgs 1 -1 scale (Customer attach boxes are in a different) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X679 449 m Xgs 1 -1 scale (AS in each POP) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X679 494 m Xgs 1 -1 scale (which allow e.g. AS 1239 and AS 1790 to behave) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X679 479 m Xgs 1 -1 scale (Cisco and Sprint have developed BGP confederations) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X679 509 m Xgs 1 -1 scale (as if they were in the same AS $i.e., next-hop) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X679 524 m Xgs 1 -1 scale (and metrics are preserved$. All boxes participate) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X679 539 m Xgs 1 -1 scale (in the same IGP $IS-IS for now$. This allows for) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X679 554 m Xgs 1 -1 scale (rapid convergence time without requiring N**2) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X679 574 m Xgs 1 -1 scale (iBGP sessions.) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X679 604 m Xgs 1 -1 scale (Scaling to multiple DS3s is easy -- just add) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X679 619 m Xgs 1 -1 scale (new backbone boxes and/or new DS3s.) col-1 show gr Xshowpage X$F2psEnd END-of-pop.ps exit

1 0

Re: Draft NETSTAT Minutes for 7 Dec. 1995
by Sean Doran 20 Jan '95

20 Jan '95

Below is another bit of postscript I have thrown together. It's a map of a backbone that Peter L. and I have been telling people is a good idea for ICMnet, especially in light of the possible disconnection of Asia-Pacific, European, Latin American, African, and Carribbean R&E networks from each other as a result of the NSFNET transition. In such a situation, ICMnet could potentially act as glue between the various R&E networks around the world. It is also an attempt to deal with the differing routing policies and acceptable use policies applied to ICM vs. SprintLink and allow for different approaches to scale. ICM and SprintLink would peer with each other in D.C., Pennsauken and Stockton. SprintLink would provide transit between ICM and the other two NAPs and various peering points; ICM would provide transit between SprintLink and the FIXes. This is not official at this time, and Vadim doesn't like it. :) (He has advanced a counterproposal which will have SprintLink and ICM merge and share the same routing policy and physical fabric.) The principal differences betwen ICMnet now and this drawing are the connectivity to (and the router at) the Sprint NAP in Pennsauken NJ and the ICM line between Stockton CA and D.C. Sean. - -- # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # icmmap.ps # echo x - icmmap.ps sed 's/^X//' >icmmap.ps << 'END-of-icmmap.ps' X%!PS-Adobe-2.0 X%%Title: /tmp/xfig-fig028325 X%%Creator: fig2dev X%%CreationDate: Fri Jan 20 00:21:10 1995 X%%For: smd(a)isis.sprintlink.net (Sean Doran) X%%Orientation: Landscape X%%BoundingBox: 83 69 529 723 X%%Pages: 1 X%%EndComments X/$F2psDict 200 dict def X$F2psDict begin X$F2psDict /mtrx matrix put X/l {lineto} bind def X/m {moveto} bind def X/s {stroke} bind def X/n {newpath} bind def X/gs {gsave} bind def X/gr {grestore} bind def X/clp {closepath} bind def X/graycol {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul X4 -2 roll mul setrgbcolor} bind def X/col-1 {} def X/col0 {0 0 0 setrgbcolor} bind def X/col1 {0 0 1 setrgbcolor} bind def X/col2 {0 1 0 setrgbcolor} bind def X/col3 {0 1 1 setrgbcolor} bind def X/col4 {1 0 0 setrgbcolor} bind def X/col5 {1 0 1 setrgbcolor} bind def X/col6 {1 1 0 setrgbcolor} bind def X/col7 {1 1 1 setrgbcolor} bind def X /DrawSplineSection { X /y3 exch def X /x3 exch def X /y2 exch def X /x2 exch def X /y1 exch def X /x1 exch def X /xa x1 x2 x1 sub 0.666667 mul add def X /ya y1 y2 y1 sub 0.666667 mul add def X /xb x3 x2 x3 sub 0.666667 mul add def X /yb y3 y2 y3 sub 0.666667 mul add def X x1 y1 lineto X xa ya xb yb x3 y3 curveto X } def X X end X/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def X/$F2psEnd {$F2psEnteredState restore end} def X%%EndProlog X X$F2psBegin X0 setlinecap 0 setlinejoin X52.0 20.0 translate 90 rotate 0.900 -0.900 scale X0.500 setlinewidth X% Polyline Xn 599 279 m 599 239 l 559 239 l 559 279 l clp gs 0.70 setgray fill gr Xgs col-1 s gr X% Polyline Xn 599 419 m 599 379 l 559 379 l 559 419 l clp gs 0.70 setgray fill gr Xgs col-1 s gr X% Polyline Xn 719 279 m 719 239 l 679 239 l 679 279 l clp gs 0.70 setgray fill gr Xgs col-1 s gr X% Polyline Xn 99 279 m 99 239 l 59 239 l 59 279 l clp gs 0.70 setgray fill gr Xgs col-1 s gr X% Polyline Xn 99 379 m 99 339 l 59 339 l 59 379 l clp gs 0.70 setgray fill gr Xgs col-1 s gr X% Polyline Xn 699 79 m 699 39 l 659 39 l 659 79 l clp gs 0.70 setgray fill gr Xgs col-1 s gr X2.000 setlinewidth X% Polyline Xn 99 259 m 559 259 l gs 0.70 setgray fill gr Xgs col-1 s gr X% Polyline Xn 599 259 m 679 259 l gs 0.70 setgray fill gr Xgs col-1 s gr X% Polyline Xn 579 279 m 579 379 l gs 0.70 setgray fill gr Xgs col-1 s gr X1.000 setlinewidth X% Polyline Xn 79 279 m 79 339 l gs 0.70 setgray fill gr Xgs col-1 s gr X2.000 setlinewidth X% Open spline Xn 599.000 239.000 m 639.000 159.000 l X 679.000 79.000 l gs 0.70 setgray fill gr Xgs col-1 s gr X/Times-Roman findfont 6.00 scalefont setfont X634 249 m Xgs 1 -1 scale (DS3) col-1 show gr X/Times-Roman findfont 6.00 scalefont setfont X584 344 m Xgs 1 -1 scale (DS1) col-1 show gr X/Times-Roman findfont 6.00 scalefont setfont X659 134 m Xgs 1 -1 scale (~10MBPS) col-1 show gr X/Times-Roman findfont 6.00 scalefont setfont X259 249 m Xgs 1 -1 scale (~10MBPS) col-1 show gr X/Times-Roman findfont 6.00 scalefont setfont X89 314 m Xgs 1 -1 scale (DS3) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X54 224 m Xgs 1 -1 scale (Stockton CA) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X109 359 m Xgs 1 -1 scale (FIX-WEST) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X609 399 m Xgs 1 -1 scale (PANAMSAT) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X609 417 m Xgs 1 -1 scale (Homestead FL) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X559 224 m Xgs 1 -1 scale (D.C.) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X709 59 m Xgs 1 -1 scale (Pennsauken) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X709 77 m Xgs 1 -1 scale (NAP colocate) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X694 299 m Xgs 1 -1 scale (FIX-EAST) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X694 317 m Xgs 1 -1 scale (College Park MD) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X109 379 m Xgs 1 -1 scale (Mtn. View CA) col-1 show gr X/Times-Roman findfont 48.00 scalefont setfont X139 454 m Xgs 1 -1 scale (ICMnet) col-1 show gr X/Times-Roman findfont 6.00 scalefont setfont X59 79 m Xgs 1 -1 scale (West Coast) col-1 show gr X/Times-Roman findfont 6.00 scalefont setfont X59 103 m Xgs 1 -1 scale (Connectivity to ) col-1 show gr X/Times-Roman findfont 6.00 scalefont setfont X59 115 m Xgs 1 -1 scale (Asia-Pacific ICM customers) col-1 show gr X/Times-Roman findfont 6.00 scalefont setfont X59 127 m Xgs 1 -1 scale (FIX-WEST) col-1 show gr X/Times-Roman findfont 6.00 scalefont setfont X59 139 m Xgs 1 -1 scale (SprintLink) col-1 show gr X/Times-Roman findfont 6.00 scalefont setfont X59 151 m Xgs 1 -1 scale (MAE-WEST) col-1 show gr X/Times-Roman findfont 6.00 scalefont setfont X559 39 m Xgs 1 -1 scale (Pennsauken) col-1 show gr X/Times-Roman findfont 6.00 scalefont setfont X559 51 m Xgs 1 -1 scale (Connectivity to) col-1 show gr X/Times-Roman findfont 6.00 scalefont setfont X559 63 m Xgs 1 -1 scale (Pennsauken NAP $IRCs$) col-1 show gr X/Times-Roman findfont 6.00 scalefont setfont X559 75 m Xgs 1 -1 scale (Some high-speed trans-atlantic) col-1 show gr X/Times-Roman findfont 6.00 scalefont setfont X559 87 m Xgs 1 -1 scale (ICM customers) col-1 show gr X/Times-Roman findfont 6.00 scalefont setfont X499 274 m Xgs 1 -1 scale (D.C.) col-1 show gr X/Times-Roman findfont 6.00 scalefont setfont X499 286 m Xgs 1 -1 scale (Connectivity to) col-1 show gr X/Times-Roman findfont 6.00 scalefont setfont X499 298 m Xgs 1 -1 scale (MAE-EAST) col-1 show gr X/Times-Roman findfont 6.00 scalefont setfont X499 310 m Xgs 1 -1 scale (AlterNet) col-1 show gr X/Times-Roman findfont 6.00 scalefont setfont X499 322 m Xgs 1 -1 scale (European ICM customers) col-1 show gr X/Times-Roman findfont 6.00 scalefont setfont X499 334 m Xgs 1 -1 scale (Carribean ICM customers) col-1 show gr X/Times-Roman findfont 6.00 scalefont setfont X499 399 m Xgs 1 -1 scale (PanAmSat colocate) col-1 show gr X/Times-Roman findfont 6.00 scalefont setfont X499 411 m Xgs 1 -1 scale (Connectivity to) col-1 show gr X/Times-Roman findfont 6.00 scalefont setfont X499 423 m Xgs 1 -1 scale (Latin America) col-1 show gr X/Times-Roman findfont 24.00 scalefont setfont X134 494 m Xgs 1 -1 scale ($Sprint/NSFNET International Connectivity Project$) col-1 show gr X/Times-Roman findfont 6.00 scalefont setfont X644 464 m Xgs 1 -1 scale (Sean Doran <smd(a)icm1.icp.net>) col-1 show gr X/Times-Roman findfont 12.00 scalefont setfont X319 529 m Xgs 1 -1 scale ($engineering proposal Nov 1994$) col-1 show gr X/Times-Roman findfont 6.00 scalefont setfont X499 344 m Xgs 1 -1 scale (African ICM customers) col-1 show gr Xshowpage X$F2psEnd END-of-icmmap.ps exit

1 0

Draft NETSTAT Minutes for 7 Dec. 1995
by Gene Hastings 20 Jan '95

20 Jan '95

Network Status Reports met on 7 December, 1994 from 0930 to 1145. Scheduled presentations were ANS (Rob Lehman), NSFNET Transition (Elise Gerich), InternetMCI (Phill Gross), BBN (John Curran), Sprint NAP (Tim Clifford) and SprintLink (Sean Doran) In addition to the presentations and Q&A, several meta-issues were raised or implied (furished along with my attempt to digest the pulse of the group). Is it appropriate to give what is essentially a marketing presentation at IETF? The consensus seems to be "no" if it is solely and blatantly such, but there is dissention as to where the line is. With the increasing activity of for profit concerns in the Internet, will it be possible to continue the openness of past years' presentations wrt traffic, performance, uptime statistics, etc.? [Despite the fears or predictions of some, there appeared to be some continuing openness, but also examples of extremely closed practices. I think that collegial backpressure has ceased to be sufficient to maintain the historical levels of disclosure and cooperation. - efh] In the light of these questions, what is the charter of this group? (including what is desirable vs. what is acceptable). [I think this is an ongoing process. Does commercial necessarily mean concealed? I think in the context of an interconnected, interdependent environment, it can't in the long run. - efh] Beyond concerns about openness, there are areas of concern not being addressed at all: What is the forum for operations, engineering and troubleshooting above TCP/UDP? Traditional IP regionals and carriers have been content to (determined to?) focus their energies on transport and routing. What is the forum for general end-to-end problem solving? Presentations: ANS Rob Lehman,<rll(a)ans.net> [See slides - only supplemental notes follow] ANSNET traffic surpassed 100m inbound packets in Nov.! CIDR note: after AUP disappears, there ought to be further aggregation possible ANS' NAP connectivity status: Connection to the Sprint NAP was installed on 9-21-94. At this time (7 Dec. 94) it's only been operational since 2 weeks, but substantial traffic has been exchanged Connection to the PacBell NAP was installed on 10-14-94, but is not in production. Connection to the Ameritech NAP was installed on 11-22-94, but is not in production. A MAE+ FDDI Installation plan has been established. Its exact schedule is contingent on logistics. Real Soon Now. ANS did link optimizations for cross-country trunking, to address an imbalance in the relative utilizations of their northern and southern routes. After testing, they are further considering deployment of Random Early Drop. Transition Elise Gerich <epg(a)merit.edu> [No slides - see contemporaneous presentations to IESG, etc.] NONE of the ENSSen have been retired. The regionals' transition to non-NSF Inter-Regional Connectivity has been slow. Target dates of Nov. 1 and Dec. 1 have been missed, Merit is hoping for ~ Jan. 1 terminations + 60 days... THEnet and MOREnet have made the transition to SprintLink. SURAnet has moved traffic to MCInet, but has not formally notified Merit of the ability to terminate the ENSS connection. CA*NET is close to transition to MCI THEnet is sharing Inter-Regional Connectivity with Sesquinet Interconnection point status: The Sprint NAP has connections from Sprint, MCI, and NSFNET. In DC, at MFS facilities, everyone is on MAE and is committed to connecting to MAE+. At the Ameritech NAP, MCI and NSFNET are about to start peering, with Sprint to connect soon. PacBell has MCI and ANS are peering, and Sprint will connect soon. Route servers are present at MAE, the PacBell NAP, the Ameritech and the Sprint NAP. Routing DB deployment and transition. The applications are moving from PRDB (@merit) to RA (db-admin(a)radb.ra.net) At some point, Merit will do dual use of NACR and RADB forms, followed by retirement of NACR (transition ca. Jan. 15.) Merit has recommended to NSF that during transition (Jan.-Jun., there should be no need to specify AUP. If anyone is still relying on PRDB reports they should contact Dale!!! InternetMCI Phill Gross <0006423401(a)mcimail.com> [see pretty slides. In color. Phill apologized.] Problems were experienced transitioning SURAnet, thus delaying the CoREN schedule. "DS3 networking is not yet a commodity service." - experienced some problems in the routers. Questions from the floor: What management platform does InternetMCI use? Phill: Hewlett- Packard OpenView, plus homegrown tools and extensions. What Other nets beside CoREN is MCI serving? Phill: CA*NET is partially transitioned...(at 3Mb), WIDE (at T1) and BTnet (at E1) InternetMCI NAP connectivity status: Chicago (Ameritech) was connected a the end of last week, MCI is connected and peering at Sprint, MAE and CIX. ANS and MCI are interconnected at FDDI at Hayward CA. common PoP (Phill: Thanks for the cooperation, ANS!) Q: When will MCI be connected to FIX-W? Phill: I don't know. It's underway, maybe by the end of year, approximately the same as CIX- SMDS, MAE+. Q: What's the status of the vBNS? Phill: we're deploying a testnet, and full rollout 1Q95 at OC-3. The testnet should be operational before Christmas. BBN John Curran <curran(a)bbn.com> [Admittedly marketing slides.] BBN is upgrading the NEARNET spine in the Boston area, migrating from microwave Ethernet to fiber (MFS 10Mb over NYNEX T3). Currently BBN has almost 2000 SNMP managed items... Operations/NOC/NIC tip: you can head off phone calls by giving seminars! BBN is now offering "Turnkey Internet Server" (Pentium/BSDi) Internet Site Patrol - managed firewall (BBN CONTROLS it), with remote management done by BBN ISC over a secure channel. It's derived from TIS products, and supports telnet, ftp, smtp, nntp, www, x BBN strenuously wants to know how to pursue end-to-end problem solving (they still subscribe to 'the router is BBN's, we control the horizontal, we control the vertical). Sprint NAP, Tim Clifford <tcliff(a)sprint.net>(New PI) Report on the Sprint "NY" NAP (in Southern NJ). It is now (Dec. 94) a dual FDDI ring, and in Jan. will be converted to a DEC Gigaswitch. [See before and after diagrams]. Connected, parties include MCI, NSFNET, Sprint and Cerfnet. A Route Server is present and running. Aside: Sprint has "always thought about ATM" [the implication being that they felt is wasn't ready - efh] Question: the DEC GigaSwitch has DS3 cards. Have you considered access this way? Tim: not really. [It's my understanding that a GS ATM interface can only talk to other GS. - efh] Q: being already co-located, can folks try alternate interconnect technologies? Tim: likely. Try us. SprintLink, Sean Doran <smd(a)sprint.net> Sprintlink's T1 backbone is melting down. They're converting to DS- 3s or parallel T1s in the next few weeks.[see diagram]. T3 customers feed directly into BB routers to avoid saturating local FDDI rings For trans-US international connectivity, ICM has 2 T3 between Stockton, CA and DC. The design goal in separation of SprintLink and ICM was the assurance of symmetry of routing. [Context?] preservation of next hop in routing is critical feature (could not wait for IDRP) Q: What about fears of an ASpath explosion in routing tables? Sean: Too late. Already here!

3 2