- Test - lists.nanog.org

re: Process of opening trouble tickets.
by Rob Gutierrez 08 Oct '96

08 Oct '96

>From Mark Boolootian: > So, my meta-question is: Shouldn't there be an informal arrangement that > allows one provider to open a trouble ticket with another provider if the > providers peer with one another? We have always honored trouble tickets from any ISP, and we have opened TT's with MCI. We're a customer of Sprint, so I can't speak of any problems we've had in regards to trouble tickets with Sprint. rob

1 0

Internet II is coming...
by Yakov Rekhter 08 Oct '96

08 Oct '96

fyi - --------------------------------------------------------------------------- >From www.nytimes.com: October 7, 1996 University Internet Proposed By LAWRENCE M. FISHER A group of 34 research universities agreed last week to create a new national network for higher education, to be called Internet II, which will offer higher speeds and more reliable service than the current Internet. As described in the Oct. 11 issue of The Chronicle of Higher Education, the new network is intended to deliver the vastly higher speeds needed to allow the simultaneous transmission of voice, video and data. Internet II would give researchers the bandwidth they need to enable distance learning, digital libraries and on-line collaborative research. The organizers of Internet II say its advanced capabilities will ultimately become available on the existing Internet as commercial service providers find ways to offer more bandwidth -- a bigger pipeline to transmit a high volume of information -- at attractive prices. The research universities have agreed to establish and finance a new organization, with membership fees to help create the network. They also hope to get financing from telecommunications and computer companies, as well as from the federal government. "What we're trying to do is solve a whole bunch of technical problems having to do with making the Internet operate at a higher level of functionality," said Michael Roberts, who has been working on the Internet II proposal and is vice president of Educom, a consortium of nearly 600 colleges and 100 companies that promote computing in higher education. "What everybody needs is something on the order of 10 times more bandwidth." According to The Chronicle of Higher Education, the decision to move forward with the plan was made during a meeting of campus technology officers in Chicago last week. Computer science specialists from Pennsylvania State and Stanford universities and the Universities of California, Chicago, Michigan and North Carolina will play leading roles in the network's development.

1 0

Problems with Spintlink between MAE West & Stockton POP
by booloo＠cats.ucsc.edu 08 Oct '96

08 Oct '96

We've been seeing significant packet loss across the Sprintlink circuit between MAE West and their Stockton POP. I note that there's a big hike in RTT at the Stockton POP: sl-mae-w-F0/0.sprintlink.net (198.32.136.11) 15 ms 39 ms 13 ms sl-stk-6-H3/0-T3.sprintlink.net (144.228.10.45) 224 ms 185 ms 222 ms On Oct 2nd, I heard something along the lines that route damping was in effect (this was from Sprintlink). I presume what was meant was route flapping was eating CPU. Does anyone have any information on what's taking place? There's a heck of a lot of traffic that flows across this path, and the packet loss is killing performance (and making the phone ring). Thanks, mb

1 1

Re: syn attack and source routing
by Vadim Antonov 08 Oct '96

08 Oct '96

Alexis Rosen <alexis(a)panix.com> wrote: > > Or better yet, the ICMP TRACEROUTE message, which would go > > hop by hop and on every hop generates a response message. > > Augmented with PROXY TRACEROUTE which will cause the destination > > box to send out the ICMP TRACEROUTE. >I'm very surprised that noone has mentioned what seems to me to be the >*really* serious drawback to this scheme. Remember how much grief you had >the last time someone did a news sendsys forged to your name? (If it's >never happened to you, be glad...) This sort of attack got so bad that >the default setup these days is to ignore sendsys. Yes, indeed a single traceroute packet with forged address can generate many responses. However, there is at least one technique to eliminate its usefulness as an attack weapon -- namely source address filtering (which is going to be implemented anyway, sooner or later; there are other types of attacks). Another way is to have ICMP TRACEROUTE to return one packet with all information _and_ the IP address of the next hop router (i.e. replace recursive behaviour with iterative) . It is still more useful than UDP kludge; and it will still work in case of load-sharing. Actually, the "multiplication" type of flooding attacks is nothing new, but they are more easily done on application level. For example, connecting to different SNMP speakers and causing them to send a long error reply to the target address. Or subscribing victim to many many mailing lists (including USENET gateways, urgh!). Or using MBONE feeds creatively. --vadim

2 1

European Traffic Study - please comment
by Ariel T. Sobelman 08 Oct '96

08 Oct '96

Enclosed is a draft of a proposed activity on traffic stats and metric. Through many discussions, the idea has evolved and developed around an idea to conduct a large scale effort of stat collection and analysis on a European Scale. Over the past few months, we have collected information on current activities throughout Europe in this area, and this draft reflects many of your thoughts and ideas on how to carry out such a project. This document is a draft and comments are encouraged. Some of the ideas and deliverables are not complete (software suggestions) need further input and insight in order to define/refine them in full and as a first step, it is proposed to proceed on the wg-qmn list. Cheers, Ariel --------------------------- original document --------------------------------- Project name: TERENA Task Force on European Traffic Studies Justification The problem of network traffic growth prediction may be attributed to a plethora of difficulties associated with network operation. There is one common ground, however, that which is the end result: performance. Many TERENA members currently collect basic statistics on their own network's performance and traffic flows. Typically, this includes measurement of throughput, delay and availability. However, the only baseline against which networks evaluate performance is their own past performance metrics. There is no data available for national level comparisons with other networks' performance. It is increasingly vital for both users and providers to provide information on end-to-end performance. Such information is beyond the realm of what is currently undertaken by individual networks. The project objective is to collect and analyze data which will enable focusing on the causes of decreased performance and proposing corrective actions. These activities include the development a mechanism and structure for collecting statistics of traffic loads on an end-to-end international level, measurements of delays, flow capacity and packet loss information. Objectives The vacuum created in national-level statistics/metric collection has significantly complicated planning by member countries and service providers. While details traffic and performance measurements are essential to identifying the causes of network problems and formulating corrective actions, it is trend analysis and accurate network/system monitoring which permit network managers to identify "hot spots", predict problems before they occur and identify ways to avoid them by efficient deployment of resources and optimizing of network configuration. As the explosive growth and dependence on the Information Infrastructure continues, it is critical that mechanisms be established to enable infrastructure planning and analysis. This proposal describes a possible mechanism for undertaking a project to concentrate current efforts. It is proposed to address these problems on two levels of relevance: 1. significance to analysis of network performance 2. relevance to Internet settlements These activities will include cross-European measurements of total traffic through specific links and the mapping of reachable destinations covered by a route, Delay measurements, flow capacity, continental averages of hops, and rate of packet loss monitoring. Deliverables: Software kit for all participating members - for total trafic stats: TCP dump samples, router stats, Network Probe Daemon - for delay measurments: ping-based utilities, Treno , - for packet loss stats: To be discussed - Hope counts: traceroute Report: TF-ETM Guidelines for setting up a Stats-collection operation compatible with the rest of the project - guidelines for peering - topology of participating links Web site concentrating the European statistics collected - General database with all raw data - various "views" of the data - analyzed data, patterns, related papers, ongoing work etc Report: Summery of network patterns and problems identified by the stats collection - Final report on Stats: analyzed results of the metrics and guides for immediate possible corrective steps. Results of traffic model: A predictive report on network patterns and identification of necessary deployment of resources to meet these challenges Resource Requirements: ? Contribution Commitments: ? Ariel T. Sobelman TERENA Singel 466-468 1017 AW Amsterdam The Netherlands +31-20-639-1131 (Tel) +31-20-639-3289 (Fax)

1 0

Re: DoS, ICMP, proxies, SYNDefender
by salo＠msc.edu 08 Oct '96

08 Oct '96

> From: Tim Bass <bass(a)linux.silkroad.com> > Subject: Re: DoS, ICMP, proxies, SYNDefender > To: michael(a)memra.com (Michael Dillon) > Date: Fri, 4 Oct 1996 17:18:25 -0400 (EDT) > Cc: nanog(a)merit.edu, iepg(a)iepg.org > > > This is not the right forum to discuss TCP internals nor is it the right > > forum to discuss building hardened kernels > > That may or may not be true, I'll pass on that one. > > What is the name of the 'right list' for this discussion, BTW? > linux-net is quiet and the linux code fragement for linux > does not work on high speed networks..... > [...] The real TCP people tend to hang out on the end-to-end mail list. They could, and probably would, provide a high-quality critique of a well- written summary of what you propose. On the other hand, the e-2-e mail list probably doesn't have much patience for the sort of chatter that has appeared on this topic on nanog... I suggest you write an internet draft and send it to end-to-end for comments. -tjs

4 3

Re: My First Denial of Service Attack..... (fwd)
by Eric Kozowski 08 Oct '96

08 Oct '96

>Is "Denial Of Service" what "DOS" has stood for all along? Cool. It >all makes sense now after all these years... ROTFL. I normally don't reply with spurious info, but this one was too good to not respond. -- Eric Kozowski Senior Network Engineer eric(a)structured.net Structured Network Systems, Inc. (503)656-3235 FAX Better, Cheaper, Faster -- pick any two. (800)881-0962 Voice http://www.structured.net/ "Providing High Quality, Reliable Internet Service" -- 56k to DS1

1 0

Re: </24 from AS1673
by Bill Nowak 07 Oct '96

07 Oct '96

Howdy... We are looking into this and will have it taken care of shortly... Bill > Date: Mon, 07 Oct 1996 07:51:33 PDT > From: dlr(a)bungi.com (Dave Rand) > To: nanog(a)merit.edu > Subject: </24 from AS1673 > X-Mhl-File: --mhl.format-- > > ans seems to be releasing a bunch of very specific routes carved out > of a class B address. Is anyone else seeing this, or is it just me? > > I see /24's, /26's and /30's in their advertisements... > > Network Next Hop Metric LocPrf Weight Path > *> 140.222.48.192/26 198.32.136.39 0 174 1673 i > *> 140.222.56.64/26 198.32.136.39 0 174 1673 i > *> 140.222.56.192/26 198.32.136.39 0 174 1673 i > *> 140.222.64.192/26 198.32.136.39 0 174 1673 i > *> 140.222.72.192/26 198.32.136.39 0 174 1673 i > *> 140.222.80.192/26 198.32.136.39 0 174 1673 i > *> 140.222.88.192/26 198.32.136.39 0 174 1673 i > *> 140.222.96.192/26 198.32.136.39 0 174 1673 i > *> 140.222.104.192/26 198.32.136.39 0 174 1673 i > *> 140.222.112.192/26 198.32.136.39 0 174 1673 i > ... > > -- > Dave Rand > dlr(a)bungi.com > http://www.bungi.com

1 0

</24 from AS1673
by dlr＠bungi.com 07 Oct '96

07 Oct '96

ans seems to be releasing a bunch of very specific routes carved out of a class B address. Is anyone else seeing this, or is it just me? I see /24's, /26's and /30's in their advertisements... Network Next Hop Metric LocPrf Weight Path *> 140.222.48.192/26 198.32.136.39 0 174 1673 i *> 140.222.56.64/26 198.32.136.39 0 174 1673 i *> 140.222.56.192/26 198.32.136.39 0 174 1673 i *> 140.222.64.192/26 198.32.136.39 0 174 1673 i *> 140.222.72.192/26 198.32.136.39 0 174 1673 i *> 140.222.80.192/26 198.32.136.39 0 174 1673 i *> 140.222.88.192/26 198.32.136.39 0 174 1673 i *> 140.222.96.192/26 198.32.136.39 0 174 1673 i *> 140.222.104.192/26 198.32.136.39 0 174 1673 i *> 140.222.112.192/26 198.32.136.39 0 174 1673 i ... -- Dave Rand dlr(a)bungi.com http://www.bungi.com

1 0

Re: TCP SYN attacks - a simple solution
by Jeff Weisberg 07 Oct '96

07 Oct '96

| Hopefully there will be a working implementation of this by week's end. | Jeff Weisberg has code which runs on sun3s and (soon, I hope) on other | Suns under SunOS. well, it seems to be more subtle than a sun3 vs sun4 thing. the IPC has been up for 15 hours without problem (yet), it seems to only be production level machines that crash... --jeff

2 1