- Test - lists.nanog.org

Re: Which pipe dream should we be smoking? (was Re: Possible topic?)
by Joseph Kucic 21 Oct '97

21 Oct '97

Hi, You can get info at: http://www.networks.digital.com/html/products_guide/hp-swch3.html The Gigaswitch/FDDI is a different product than the Gigaswitch/ATM. You can insert ATM uplinks into the Gigaswitch/FDDI. I won't discount Gigabit Ethernet to quickly (yet there are no router interface available). I believe Ether Channel has an opportunity depending on what happens with the GSR but there is no switch to take advantage of it (except maybe the Cat 5500). But I do agree that traffic shaping technology is critical to any long term design. I guess the ideal solution will be Gigabit Ether Channel (8Gbps) or Terrabit Ethernet with traffic shaping if its not ATM at OC-192. Thanks, Joe Kucic At 10:31 PM 10/21/97 -0700, Vadim Antonov wrote: >>Aren't all the Gigaswitches from DEC ATM backed anyway? (FDDI is an >>emulation on an OC3/12 card slot?) That's what the DEC literature seemed >>to say when I perused it last. > >Not. Gigaswitch is a crossbar-based _packet_ switch. I recall reading >fairly comprehensive article on its internals. Most likely it is still >available from somewhere on Internet. > >If i understand correctly, its ATM interfaces do packet shredding/reassembly. > >--vadim > >

1 0

Looking for "National" NAPs
by Sean Donelan 21 Oct '97

21 Oct '97

I'm updating my list of who is connected to what public exchange point. Here is my current list Exchange IP Network CIX 149.20 Sprint/NY NAP 192.157.69 AADS/Chicago NAP 198.32.130 PACBELL/SF NAP 198.32.128 MAE-East 192.41.177 MAE-West 198.32.136 http://dranet.dra.com/peeringpoints.html After last time I had requests to list several additional exchange points. To keep things manageble for myself, I'm limiting myself to "National" NAPs which meet the following three criteria: - Located in North America (USA, Canada, Mexico, Caribbean), my French and Spanish language abilities are limited - At least five different providers attached and operating - At least one attached provider with their headquarters in a non-adjacent state, province, island (Alaska and Hawaii can count any other state as non-adjacent, Rhode Island can't) I'm trying to automate this, so next time I'll try to get Europe and Asia exchange points; but for now this is the NANOG list. If you operate such an exchange point I'd like to add it to my exchange point connection cross-matrix. Please send me 1) a brief name for the exchange point, 2) IP network used for the exchange point, 3) the in-addr name server for the exchange point *OR* if you don't allow AXFR access a copy of the in-addr BIND file for the IP addresses. If you are attached *BUT DO NOT OPERATE* an exchange point, please let the exchange point operate contact me. Important: I must be able to independently verify that the connections exist at the exchange point. I normally do this by sending a few (10-20) PINGs at the ip addresses several times over 24 hours. If your router is down for more than 24 hours, I may not count it. Press releases do not count. Last time I got fooled by some old IP address being re-assigned to new providers; I've flushed my data so this will be based on fresh data. I want to complete this before the NANOG meeting, so I request you let me know before Wednesday, Oct 22, 1997. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

3 2

CNN - Justice seeks $1 million a day contempt fine against Microsoft - October 20, 1997
by Hagai Yardeny 20 Oct '97

20 Oct '97

http://www.cnn.com/TECH/9710/20/microsoft.ap/index.html

2 1

Re: Syn flooding attacks
by Vern Paxson 20 Oct '97

20 Oct '97

> The router could discard the SYN, remembering it, and let pass the retry SYN > that usually occurs with valid connections and does not with invalid ones. This is no good - all the crackers have to do is modify their programs to send two bogus SYNs, spaced apart, instead of just one. Vern

3 2

Re: CNN - Justice seeks $1 million a day contempt fine against Microsoft - October 20, 1997
by Dennis Simpson 20 Oct '97

20 Oct '97

> On Mon, Oct 20, 1997 at 12:11:00PM -0800, Randy Bush wrote: > > > http://www.cnn.com/TECH/9710/20/microsoft.ap/index.html > > > > mae-west1#conf t > > Enter configuration commands, one per line. End with CNTL/Z. > > mae-west1(config)#http://www.cnn.com/TECH/9710/20/microsoft.ap/index.html > > ^ > > % Invalid input detected at '^' marker. Yeah, but the GRF can do it blazingly fast ... :-)

1 0

Re: Syn flooding attacks
by Jim Shankland 20 Oct '97

20 Oct '97

> I don't know of any routers that have these or other means of dealing with > the SYN attacks. We deal with them; see http://www.flyingfox.com/synflood_ann.html. Jim Shankland Flying Fox Computer Systems, Inc.

2 1

Re: Packet over SONet/SDH (POS) experience?
by William Allen Simpson 20 Oct '97

20 Oct '97

> From: rja(a)corp.home.net (Ran Atkinson) > To: nanog(a)merit.edu, ietf-ppp(a)merit.edu > Cc: wsimpson(a)greendragon.com, pppsdh(a)greendragon.com > On Oct 19 8:12, William Allen Simpson wrote: > % Has anyone (that has deployed) been having incident reports? > > There are known operational incidents where an adversary sent > an IP packet designed to set the SONET scrambling algorithm ["f(x)"] > to all zeros. This caused the SONET device to lose communications > syncronisation and the circuit to go down, requiring a manual reset. > Truly an ugly situation. > Please detail: - what dates? - which circuit paths? - which vendor equipment? - from whence we will derive, which vendor chipset? > I've known about this issue ever since the PPP/SONET spec was > published, but have withheld public comment until someone else > mentioned the issue on a public list. > Too bad you were not involved in the discussion 3-5 years ago.... > PS: I'm not on the PPP or PPPSDH lists, so if folks on those lists > want me to see any followups, those folks will need to Cc: me > directly. > > PPS: The followups list definitely will need trimming. Please > edit appropriately if you followup... > Ran, the original did not have those followups, and I'm kind of annoyed that you added them.... I really did _not_ need 4 copies, and I expect that the other NANOG folks will be less than enthused as well! WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

1 0

Re: Packet over SONet/SDH (POS) experience?
by rja＠corp.home.net 20 Oct '97

20 Oct '97

On Oct 19 8:12, William Allen Simpson wrote: % There has been a recent bit of scare mongering from Lucent about PPP % over SONet/SDH over on the IETF-PPP list. % Has anyone (that has deployed) been having incident reports? >-- End of excerpt from William Allen Simpson Bill, There are known operational incidents where an adversary sent an IP packet designed to set the SONET scrambling algorithm ["f(x)"] to all zeros. This caused the SONET device to lose communications syncronisation and the circuit to go down, requiring a manual reset. Truly an ugly situation. I've known about this issue ever since the PPP/SONET spec was published, but have withheld public comment until someone else mentioned the issue on a public list. Cisco originally was going to implement a scrambler in its PPP/SONET implementation (IOS folks like gmc definitely understood the issue), but the cisco hardware types would not accept free clue and didn't include the scrambler. Basically all the PPP/SONET implementations I know about can be taken out with a single well-known (and easily calculated) IP datagram. Sigh. I have not seen the Lucent proposal myself, so I'm not sure what it looks like. >From time to time I've talked with a couple of folks at a small networking startup in Mountain View about this issue. My suggestions to them have been of the form below: Add a scrambler algorithm to the PPP/SONET spec. A reasonable approach to that scrambler might be something of the general form: X^^A + X^^B + C Where: ^^ is the exponentiation operator A,B are prime numbers with O(10) or larger. (A > B) C is a prime number other than 1. Adding additional exponential terms might generally strengthen the algorithm, but intuitively I believe that the above form is a reasonable tradeoff between implementation complexity and strength. It is crucial that the selected algorithm be checked against the SONET scrambler. An early proposal for ATM-layer scrambling (since fixed) had the property that it fought with the SONET-layer scrambler. At this point, an implementation would want to retain backward compatibility with the deployed systems. Hence, I'd suggest that implementers put in a knob letting administrators select either "no PPP scrambling" or "PPP scrambling". Clearly *I* don't want to buy products that have the vulnerability noted at the top. Ran rja(a)home.net PS: I'm not on the PPP or PPPSDH lists, so if folks on those lists want me to see any followups, those folks will need to Cc: me directly. PPS: The followups list definitely will need trimming. Please edit appropriately if you followup...

1 0

Getting PING bombed...
by dougd＠airmail.net 20 Oct '97

20 Oct '97

Hello all. We are getting ping bombed by the site `donantonio.wb.utwente.nl` the attack is coming thru our uunet connection and is consuming about 20% of our DS3. It is directed at one of our 28.8 dialup ports. Email to the listed site contact fails with "Resource unavailable" Does anyone have a contact address for these folks? Even though we've blocked them at the router, my customers would really like them to stop now so we can have the rest of the DS3. 23:30:52.396533 130.89.29.52 > 206.66.5.134: (frag 35152:576@1480) 23:30:52.398484 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35153:1480@0+) 23:30:52.399460 130.89.29.52 > 206.66.5.134: (frag 35153:576@1480) 23:30:52.402386 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35154:1480@0+) 23:30:52.404337 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35155:1480@0+) 23:30:52.404337 130.89.29.52 > 206.66.5.134: (frag 35155:576@1480) 23:30:52.408240 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35156:1480@0+) 23:30:52.408240 130.89.29.52 > 206.66.5.134: (frag 35156:576@1480) 23:30:52.411166 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35157:1480@0+) 23:30:52.411166 130.89.29.52 > 206.66.5.134: (frag 35157:576@1480) 23:30:52.413118 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35158:1480@0+) 23:30:52.413118 130.89.29.52 > 206.66.5.134: (frag 35158:576@1480) 23:30:52.415069 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35159:1480@0+) 23:30:52.416044 130.89.29.52 > 206.66.5.134: (frag 35159:576@1480) 23:30:52.418971 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35160:1480@0+) 23:30:52.419946 130.89.29.52 > 206.66.5.134: (frag 35160:576@1480) 23:30:52.420922 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35161:1480@0+) 23:30:52.420922 130.89.29.52 > 206.66.5.134: (frag 35161:576@1480) 23:30:52.425800 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35163:1480@0+) 23:30:52.425800 130.89.29.52 > 206.66.5.134: (frag 35163:576@1480) 23:30:52.428727 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35165:1480@0+) 23:30:52.428727 130.89.29.52 > 206.66.5.134: (frag 35165:576@1480) 23:30:52.431653 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35167:1480@0+) 23:30:52.431653 130.89.29.52 > 206.66.5.134: (frag 35167:576@1480) 23:30:52.434580 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35168:1480@0+) 23:30:52.434580 130.89.29.52 > 206.66.5.134: (frag 35168:576@1480) 23:30:52.436531 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35169:1480@0+) 23:30:52.436531 130.89.29.52 > 206.66.5.134: (frag 35169:576@1480) 23:30:52.439458 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35170:1480@0+) 23:30:52.439458 130.89.29.52 > 206.66.5.134: (frag 35170:576@1480) 23:30:52.445311 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35173:1480@0+) 23:30:52.446287 130.89.29.52 > 206.66.5.134: (frag 35173:576@1480) 23:30:52.449213 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35174:1480@0+) 23:30:52.449213 130.89.29.52 > 206.66.5.134: (frag 35174:576@1480) 23:30:52.451164 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35175:1480@0+) 23:30:52.451164 130.89.29.52 > 206.66.5.134: (frag 35175:576@1480) 23:30:52.453116 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35177:1480@0+) 23:30:52.453116 130.89.29.52 > 206.66.5.134: (frag 35177:576@1480) 23:30:52.456042 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35178:1480@0+) 23:30:52.457993 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35179:1480@0+) [...]

6 5

Speakers - 8th Maryland Workshop on High Speed Networks
by Account of Maryland Center for Telecommunications Research 20 Oct '97

20 Oct '97

------------------------------------------------------------------------- TENTATIVE PROGRAM ------------------------------------------------------------------------- 8th Maryland Workshop on Very High Speed Networks November 12-13, 1997 Maryland Center for Telecommunications Research Department of Computer Science and Electrical Engineering University of Maryland Baltimore County Workshop Supported by: Cisco, NASA, and College of Engineering/UMBC. Please Check the Web page for the final program ------------------------------------------------------------------------- DATE NAME/ORGANIZATION TOPIC ------------------------------------------------------------------------- TBD Deepinder Sidhu, Emerging Network Technologies - An MCTR/UMBC Overview TBD Joseph Berthold, Optical Networking: The Next Ciena Generation TBD Magda El Zarki, Video over IP using RSVP and RTP University of Pennsylvania TBD Zygmunt Haas, Routing Protocols for Highly Cornell University Reconfigurable Ad-Hoc Networks TBD Raj Jain, Current Issues in ATM Traffic Ohio State University Management Models and Algorithms for TBD Hui Zhang, Hierarchical Resource Management In Carnegie Mellon University Integrated Services Networks TBD Arvind Krishna, P. Bhagwat, P. Bhattacharya and R.O. LaMaire Proxy-Based Networking for Mobile IBM Watson Research Center Devices TBD Arun Welch and Dave Beering, Experimental Results of Running NASA Lewis TCP/IP over ATM on ACTS HDR Global Optical Undersea Networks TBD Casem Majd, for Transporting Heterogeneous AT&T Submarine Systems Bitrates and Data Formats TBD Doyen, Russel, Sailor II: High Bandwidth Sailor Network Networking in Maryland TBD Robert J. Aiken, Technology Challenges of the NGI U.S. Dept. of Energy TBD <TBD>, <TBD> Fore Systems TBD <Mike Levender and Tom Downey>, <Tag Switching> Cisco IP Switching: Technical TBD Jeffrey Baher, Underpinnings and Practical IPsilon Applications TBD <TBD> <Gigabit Ethernet> TBD <TBD> <Gigabit Ethernet> TBD D. Reininger and D. Raychaudhuri, Soft QoS Control in High-Speed NEC C&C Laroratories Multimedia Networking Scenarios TBD Guru Parulkar and Fred Kuhns, University of Washington, St. Scalable Intergrated Services Louis Router over Cell Switched IPv6 Overview of the Federal Next TBD George Strawn, NSF, and Generation Internet (NGI) Dick desJardins, NSA Initiative The Internet2 Project of the TBD Javad Boroumand, ISI, and University Consortium for Advanced Guy Almes, UCAID Internet Development (UCAID), and its Relationship to NGI TBD John Steedman, NASA, and NASA Earth Science Applications Andy Germain, Swales Aerospace Prototyping over NGI TBD Craig Labovitz, <TBD> MERIT TBD <D.Mitra and ...>, <TBD> Lucent Technologies TBD <Greg Watson>, <TBD> LLNL ------------------------------------------------------------------------ NOTE: <> denotes to be confirmed. ------------------------------------------------------------------------ *************************************************************** 8th Maryland Workshop on Very High Speed Networks November 12-13, 1997 *************************************************************** Maryland Center for Telecommunications Research Department of Computer Science and Electrical Engineering University of Maryland Baltimore County The Maryland Center for Telecommunications Research (MCTR) at the University of Maryland Baltimore County (UMBC) will hold the 8th Maryland Workshop on Very High Speed Networks (VHSN '97) on November 12-13 1997 at the UMBC campus. The Workshop will be held in the Ballroom of the University Center on the UMBC campus. The goal of the workshop is to provide a forum where researchers and developers can meet to exchange ideas and report on leading- edge developments in the area of high speed networks. Each of the previous workshops attracted approximately 150 researchers representing academia, industry and government. The two day meeting will include invited speakers and contributed presentations. Papers on selected presentations will appear in a special issue of the Journal of High Speed Networks. A registration fee of $325 will include two lunches and conference proceeding. For questions regarding the technical content of the workshop or giving a presentation, please contact the workshop organizer: Dr. Deepinder Sidhu, Tel: (410) 455-3028 or 3063, Fax: (410) 455-3969, Email: mctr(a)cs.umbc.edu. Mail checks (payable to University of Maryland Foundation) and registration form to Dr. D. Sidhu, Maryland Center for Telecommunications Research, University of Maryland Baltimore County, 1000 Hilltop Circle, Baltimore, MD 21250. All funds for this event will be managed by the UM foundation. Please DO NOT include hotel accommodation expenses in your payment for the Workshop Registration. Room payment should be made directly to the hotel you selected for stay. The following hotels are closest to UMBC campus. Some hotels may offer reduced rate. To obtain the reduced rate, you must identify yourself as an attendee of this workshop. BWI Airport is approximately five miles from UMBC Campus. * Sheraton International Hotel - BWI Airport. Closest to airport and UMBC campus. Tel: (410) 859-3300 or (800) 638-5858 * Holiday Inn - BWI Airport. Close to airport and UMBC campus. Tel: (410) 859-8400 or (800) HOLIDAY * Omni Inner Harbor Hotel. Close to Downtown Baltimore/Inner Harbor. About 20 minutes drive to UMBC campus. Tel: (410) 752-1100 or (800) 843-6664 For more information on the workshop and directions to UMBC, check our home page on WWW (http://www.mctr.umbc.edu) --------------------------------------------------------------- VHSN '97 REGISTRATION FORM (November 12-13, 1997) Name: Affiliation: Address: Tel: Fax: Email: Dietary Restrictions: Vegetarian ------ Kosher -------- ---------------------------------------------------------------

1 0