- Test - lists.nanog.org

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

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

07 Oct '96

| There have been several (many?) products attempting to solve the TCP | SYN attack through timeouts. They watch the SYN packets, and flush | ones, by doing a RESET on the connection if the third packet isn't | received in time. Or letting conenctions fail by flushing the infant | connection table when full. I believe this is wrong! [...] | I propose a solution where the initial sequence number is calculated | (not random), and is based on a cryptographic calculation of the | senders Initial Sequence Number, the ports, and a "per boot" | secret number. In this way the initial packet can be discarded, | and on receipt of the third SYN packet can be recalculated. cool idea! look at: ftp.op.net:/pub/src/syn-prophylactica/ for an implementation. --jeff

1 0

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

07 Oct '96

> > The foreman commented, "We'd be sued for $100,000 for every 10 minutes > > the line was cut." Correction: $100,000 per minute. I was quite sure of the $6,000,000 per hour figure. -- Eric Ziegast

1 0