- Test - lists.nanog.org

possibly operationally relevant tutorials at sigcomm (ATT research)
by k claffy 09 May '01

09 May '01

even if not, strongly recommend being in same room with folks below for a day mon 27/28 aug 01, all day, UC, San Diego campus k http://www.acm.org/sigs/sigcomm/sigcomm2001/conference_program.html#M2 M2 Traffic Measurement for IP Operations Monday, August 27, 2001 9:00-5:00 Matt Grossglausner and Jennifer Rexford AT&T Labs -- Research; Florham Park, NJ, USA Content: You manage a large IP network. You notice that your connectivity to several peers is degrading rapidly. Is it due to an underprovisioned peering links? Distributed denial-of-service attack? A new peer-to-peer network? A bad routing advertisement? A flash crowd? What are you are going to do about it? Traffic measurement is an essential tool to guide operators of large IP networks in key engineering decisions. This tutorial focuses on measurement techniques and traffic models that provide a comprehensive view of large IP networks, over which the operator has full administrative control. The first part of the tutorial describes the basic tasks involved in operating a large IP network and derives requirements for network measurement. We argue that the very properties responsible for the Internet's success also make it difficult to control and manage. We provide a variety of "real world" anecdotes that illustrate the role of measurements in network operations. In the second part, we give a comprehensive survey of measurement data currently available in IP networks. We present an overview of SNMP/RMON, flow-level measurement, packet monitoring, active measurement, and techniques for collecting routing, configuration, and topology data. We classify these measurements according to their temporal and spatial granularity, their means of collection, and their overhead, and present case studies of how to exploit the measurement data in important operational tasks. The third part of the tutorial discusses complex operational tasks that require combining multiple types of measurement data. First, we describe network tomography, a technique for inferring a traffic matrix from link utilization statistics. Second, we describe how to compute point-to-multipoint traffic demands by combining flow-level measurements with routing table data. Third, we describe a hash-based packet sampling technique for direct observation of the path matrix. We discuss the pros and cons of each technique in detail. Intended audience: Researchers, network architects, and protocol implementors from academia and industry looking for an applied introduction to IP traffic measurement from the viewpoint of a network operator. Speaker's biographies: Matt Grossglauser received his diploma from the Swiss Federal Institute of Technology (EPFL) and his M.Sc. degree from the Georgia Institute of Technology, both in 1994, and his Ph.D. from the University of Paris 6, in 1998. He did most of his thesis work at INRIA Sophia Antipolis, France. He is currently a member of the IP Network Management and Performance Department at AT&T Labs -- Research in Florham Park, New Jersey. His research interests are in network traffic modeling and measurement, resource allocation, network management, and mobile communications. Jennifer Rexford received her B.S.E. degree in electrical engineering at Princeton University in 1991 and her M.S.E. and PhD degrees in electrical engineering and computer science at the University of Michigan in 1993 and 1996, respectively. She is currently a member of technical staff in the IP Network Management and Performance Department at AT&T Labs -- Research in Florham Park, New Jersey. Her research focuses on routing protocols, traffic engineering, and network measurement. Jennifer is co-author (with Balachander Krishnamurthy) of the book "Web Protocols and Practice: HTTP/1.1, Network Protocols, Caching, and Traffic Measurement", published by Addison-Wesley in May 2001. T1 Interdomain Routing and BGP Tuesday, August 28, 2001 9:00-12:30 Timothy G. Griffin AT&T Labs-Research, Florham Park, NJ, USA Content How is IP connectivity maintained on the global Internet? How do Internet Service Providers (ISPs) exchange routing information? How well is the current routing system working? Can the routing infrastructure continue to scale as the Internet grows? The tutorial will survey the basics of interdomain routing. It will cover what an autonomous system is, how IP addresses are assigned and aggregated, and why metric-based routing protocols, such as RIP and OSPF, do not meet the demands of scale and policy flexibility required for interdomain routing. Today, interdomain routing is accomplished with the Border Gateway Protocol (BGP). The core of the tutorial will be an in-depth look at what BGP is, how it works, and how it is configured by ISPs. The tutorial will also survey some of the significant challenges currently arising in interdomain routing. These include rapid growth in BGP routing information, delay in BGP convergence times, and complexity of analyzing the interaction of autonomously defined routing policies. Intended audience: Anyone who wants to know how connectivity is maintained in the global Internet. Attendees are expected to have some familiarity with basic IP addressing and forwarding. Some understanding of routing with interior gateway protocols, such as RIP or OSPF, will be helpful but not required. Speaker's biography: Tim Griffin is a member of the IP Network Management and Performance Department at AT&T Labs in Florham Park, New Jersey. He received his undergraduate degree in mathematics from the University of Wisconsin, Madison, his MS and Ph.D. degrees in Computer Science from Cornell University. Before joining AT&T Labs he was a member of technical staff at Bell Laboratories. His current research interests iinterdomain routing and the analysis and modeling of BGP.

1 0

Re: Network Simulation and Measurement Software
by Richard A. Steenbergen 09 May '01

09 May '01

On Wed, May 09, 2001 at 05:18:20PM -0400, Nathan Stratton wrote: > > On 9 May 2001, Sean Donelan wrote: > > > I hate html mail. > > > > 18 months ago, I asked about network modeling software and everyone > > pointed me to WANDL. It is an interesting package. Everyone had > > their set of gripes with it, but it seemed to be the best available. > > I changed jobs shortly afterwards, and didn't get to do much with it. > > Just use pine, text is always safe. Unless that text is exploiting one of the dozens of ways to own pine. Next. -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

1 0

Re: Network Simulation and Measurement Software
by Sean Donelan 09 May '01

09 May '01

I hate html mail. 18 months ago, I asked about network modeling software and everyone pointed me to WANDL. It is an interesting package. Everyone had their set of gripes with it, but it seemed to be the best available. I changed jobs shortly afterwards, and didn't get to do much with it. On Wed, 09 May 2001, "Wojtek Zlobicki" wrote: I need to evaluate what is out there in regards to > network simulation and modeling software.  I am especially interested in > freeware that will run on Linux.  However, just about any application will > do.   I will compile a list of all the responses I get and will be > publishing a web page with this info (part of a larger research project I am > doing).  I need software that will allow me to see how different > applications react to different network/protocols conditions.  I would like > to create a system that would allow any application to be tested in a controlled > environment

3 2

RE: Instant chats and central servers
by Richard A. Steenbergen 09 May '01

09 May '01

On Wed, May 09, 2001 at 10:35:17AM -0700, David Schwartz wrote: > > I don't see how that can be. A P3-600 can RC4 encrypt over > 60MB/sec in 64 byte blocks. That figure drops to only 45MB/sec in 8 > byte blocks. This is a slight overstatement because cache > effectiveness is increased by repeatedly encrypting the same stream. What crack are you smoking? RC4 is a stream cipher, it does not get applied to block sizes of any kind. Perhaps this shows the performance of the surrounding components feeding data to be encrypted in someone's benchmark, but it does not relate to the algorithm itself. Stream ciphers are just stateful pseudo random number generator, with the results being XOR'd into the plaintext on a byte by byte basis. This makes them extremely fast and light weight, but as WEP has recently demonstrated for us very vulnerable to "attack of the poorly implemented crypto". Don't get me wrong I rather like RC4, I can write it off the top of my head in 30 seconds, encrypt data at very high speeds, and it provides a good level of security IF implemented correctly. The problem is I don't trust it in other people's implementations unless I've double-checked it myself, because it's real easy to mess up. > If a chat server with a P3-733 has a throughput of, say, 8MB/sec > out and 3MB/sec in, encryption on all that traffic would eat less than > 15% of the CPU. There would be some memory usage to store all the > encryption/decryption state information but memory is cheap. That's a lot of chat! But the issue isn't really encryption of the bulk data, even after you throw in good IV's, message authentication codes, etc. The real issue is key exchange. > If you used a dual processor machine and separated the actual > chat layer from the I/O layer, you could put the encryption in the I/O > layer. This is actually not that terribly hard to hack into Ircd. Terribly hard to hack, no. Terrible hack, yes. > PS: If you use public-key encryption to do the initial key > exchange, that can be significant if you have a high rate of > connection establishment. But if you assume that everybody has a > password already known to both them and the chat server, it's not a > problem. And so unbelievably easy to defeat you might as well not have bothered. Bad crypto is almost worse then no crypto because it gives you a false sense of security. First think about what you're actually wanting to protect with crypto. Is it the communication between the server and user, so that noone can intercept (OR inject!) data? It certainly isn't a good thing when someone can compromise a machine local to you and intercept/inject commands into your irc session, as many efnet opers seem to have found out. It also isn't a good thing when you can compromise a machine local to a server, and intercept/inject commands which can destroy the entire structure of the chat network. For example, it is easy enough to capture the SJOIN flood of a server synchronizing to the network (which itself is an archiac design, but irc is good at those), then hijack the tcp session and play back that list with slight modifications so that you blast the entire state database on all servers and do things like deop every channel on the network, etc. Obviously this is an area where real crypto provides many benefits. Is it for end-to-end users across the network, so people can talk privately without the fear of an unethical server admin (or admins) snooping on their conversations? Sure it's possible to establish a direct client to client tcp connection, but that doesn't scale very well for things like meetings, which IRC would be rather well suited for. If you do not have good key exchange mechanisms in place, none of this can be accomplished, and as we all know public-key type exchanges suck CPU left and right. It may work reasonably well for your company's internal server with 100 people, but it probably wouldn't scale to many thousands or hundreds of thousands of users on public chat networks very well. If you'd like a suggestion on how to give it a shot though, I'd say your best bet is Diffie-Hellman where you can pre-generate your primes on the server, re-use them, and shift the work of random number generation to the individual client. It's not a perfect mutual-exchange, but it puts the ball of security back in the court of the connecting client. -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

2 2

Abuse notification in Chinese (was:black hat .cn networks)
by Daryl G. Jurbala 09 May '01

09 May '01

For what it's worth, here are two pretty generic messages that you can send, translated into Chinese (In Chinese Simplified -HZ encoding). ----- Dear <Abusive Autonomous System>, The following unsolicited email appears either to have originated on and/or traversed your network, or to have come from a client of yours. If you simply have an open mail relay, please fix it. Please look into this. Regards, 親愛的不知名的系統﹐ 　以下不明信件顯示出它來自于或發送到貴網絡﹐或是來源于貴網絡的某一客客'簟Ｈ缛裟阌? open email relay﹐誢OE⑺拚? 謝謝! ------ Dear <Abusive Autonomous System>, A system on my network was attacked or compromised by a system appearing to originate from your network. Below you will find relevant log entries and other information I have on this issue. Your immediate attention in resolving this matter is necessary and appreciated. Regards, 親愛的不知名的系統﹐ 我蘘網絡系統被貴網絡系統侵入或是兼容。我已OE⑾嚓P的log entries 和其它信息列放在下面。若貴網能盡快解>Q此一?-題﹐我'fOE⑷f分感謝。 ------ Daryl G. Jurbala Infrastrucutre Manager Silverchair Science + Commuications 215.823.5077 http://www.silverchair.com

3 2

RE: Instant chats and central servers
by Roeland Meyer 09 May '01

09 May '01

Can you require access via SSH tunnel? > -----Original Message----- > From: Jason Slagle [mailto:raistlin@tacorp.net] > Sent: Tuesday, May 08, 2001 6:39 PM > To: Christopher A. Woodfield > Cc: nanog(a)merit.edu > Subject: Re: Instant chats and central servers > > > > Newer versions of bahamut will do encrypted links. Just rc4. > > http://bahamut.dal.net > > Scalability while compressing to clients is a severly limiting factor > unless you only plan on using it locally. > > Jason > > -- > Jason Slagle - CCNP - CCDP > Network Administrator - Toledo Internet Access - Toledo Ohio > - raistlin(a)tacorp.net - jslagle(a)toledolink.com - WHOIS JS10172 > /"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . > . . . . . . > \ / ASCII Ribbon Campaign . If dreams are like movies then memories > X - NO HTML/RTF in e-mail . are films about ghosts.. > / \ - NO Word docs in e-mail . - Adam Duritz - Counting Crows > > > On Tue, 8 May 2001, Christopher A. Woodfield wrote: > > > > > This begs a question - does anyone have good experience > with SSL-enabled > > IRC servers? I'm testing UnrealIRCd right now, but I've run > into some > > showstopper bugs when trying to link servers over SSL. Any other > > suggestions? > > > > -Chris > > > > On Tue, May 08, 2001 at 08:50:29PM +0200, Peter van Dijk wrote: > > > > > > On Tue, May 08, 2001 at 11:35:27AM -0700, Sean Donelan wrote: > > > [snip] > > > > If folks are using this these services for real-time > communications, > > > > should we be trying to improve their reliability? Or > is this just a > > > > "feature" of how presence services work. > > > > > > We use IRC for internal communication, and for communication with > > > techies of several other Dutch ISPs. Works like a charm, > and the irc > > > server is local to us. If it's down, you pick another > irc-server on > > > the same network. > > > > > > Works for us, works for lot of people. > > > > > > Greetz, Peter. > > > > > >

3 3

Political Correctness Strikes a Blow for free speech....
by David Lesher 09 May '01

09 May '01

I just love the bounce message I just got back... > Trend SMEX Content Filter has detected sensitive content. > > Place = nanog(a)merit.edu; ; ; wb8foz(a)nrk.com > Sender = David Lesher > Subject = Re: [Fwd: Re: HR 1542 [OT, anti-BS attempt, US]] > Delivery Time = May 07, 2001 (Monday) 14:09:15 > Policy = Sexual Discrimination > Action on this mail = Quarantine message > > Warning message from administrator: > Sender, Content filter has detected a sensitive e-mail. What a great way to limit my audience to those adult enough to be willing to risk "sensitive content..." -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

7 6

Network Simulation and Measurement Software
by Wojtek Zlobicki 09 May '01

09 May '01

I need to evaluate what is out there in regards to network simulation and modeling software. I am especially interested in freeware that will run on Linux. However, just about any application will do. I will compile a list of all the responses I get and will be publishing a web page with this info (part of a larger research project I am doing). I need software that will allow me to see how different applications react to different network/protocols conditions. I would like to create a system that would allow any application to be tested in a controlled environment. Any links to such software or already established network simulation projects would be greatly appreciated. Wojtek Zlobicki

1 0

Re: Northern VA CATV systems
by RJ Atkinson 09 May '01

09 May '01

At 11:34 09/05/01, Curtis Maurand wrote: >It was my understanding (several years ago) from a 60 Minutes special done >on Fairfax, VA that they had built an all fiber system (Fiber to the >house). They had built it on a Video on demand system and a pay as you go >(That was experimental). I'm not sure whatever happened to that. I do >know that it was largely experimental, but was supposed to be state of the >art. Maybe I'm wrong, but I don't think so. > >Curtis I live in Fairfax County and have for most of the past decade at least. If there was any fibre-to-the-home system, it was not done by the CATV folks. Media General owned the CATV system several years ago; Cox bought MG's Fairfax system, perhaps ~18-24 months back. While some surrounding areas (e.g. Alexandria, Arlington) have real HFC, they don't have FTTH from their cable company. No one I can find here has ever heard of an FTTH that went to any of their neighborhoods and there certainly isn't one now to my neighborhood. So if an experiment was here, it was never county-wide and hasn't gone production. If it was production and county-wide, it was someplace else. I do know of places with fibre-to-the-curb, mostly in Sweden, but also including Palo Alto CA and a few other US places. This is pretty far off topic for NANOG folks, lets please have followups be private rather than on-list. Thanks, Ran

1 0

China says we started it.
by Shawn McMahon 09 May '01

09 May '01

According to Reuters, Chinese hackers are calling a truce. And also, they say we started it. http://dailynews.yahoo.com/h/nm/20010509/wr/internet_china_hackers_dc_1.html Enjoy.

2 2