- Test - lists.nanog.org

Re: Internet SYN Flooding, spoofing attacks
by Paul Ferguson 12 Feb '00

12 Feb '00

At 09:27 PM 02/11/2000 -0500, Vijay Gill wrote: >IETF removed from the distribution list. Thank goodness. More: >I think you're solving something else. I submit that almost _all_ isp's >offer transit for their customers. Thats where the I part of the SP comes >in. For _peering_ links (peering being defined elsewhere), yes, this is a >hard problem, but on the edges of the _peers_, this is not. If everyone >filtered their T1/DSx/OCx/E1/E3/STMx customers at their edges, using >Unicast RPF where appropriate and filters where appropriate, life would >become better. Okay. Let's look at this simplistic situation. Perhaps I'm missing something. A B \ / C | D ISP C might be carrying traffic for B which might destined via ISP A (or traverse C). In some cases, for packets coming through C from B, C may not have a reverse path back through B for that packet. It might have a better path elsewhere. D is a "Joe's Bait'n'Sushi Shop" ISP. C might have some problems doing Unicast RPF, but it certainly wouldn't have problems doing RFC2267-style filtering on it's access link to D; likewise ther might be many "mini" connections from C to other smaller downstream customers. THAT is where this filtering needs to occur. - paul

2 1

RE: Yahoo offline because of attack (was: Yahoo network outage)
by Sykes, Phil 12 Feb '00

12 Feb '00

> Okay, but you've still missed the point. Even if I stipulate everything you > said here, that's still 50 largish systems that are compromised. I would > almost wager that the perpetrators didn't use all of their assets either. > That's a shit-load of large compromised systems on the Internet. Doesn't > that thought worry you in the slightest? It worries everyone! Dave Dittrich in his analyses of DDOS tools (available from http://www.washington.edu/People/dad/) suggests: "Trinoo networks are probably being set up on hundreds, perhaps thousands, of systems on the Internet that are being compromised by remote buffer overrun exploitation. Access to these systems is probably being perpetuated by the installation of multiple "back doors" along with the trinoo daemons." CERT suggests (http://www.cert.org/incident_notes/IN-99-07.html) Prevent installation of distributed attack tools on your systems Prevent origination of IP packets with spoofed source addresses Monitor your network for signatures of distributed attack tools Should we as network operators be taking a pro-active role to police our users for DDOS running boxen? It seems to me that educating end-users is the problem here, just as educating people to use 'no ip directed-broadcast' was back in 1997. Phil Sykes, Network Engineer Cable & Wireless Europe p: +49 89 92699 204 m: +49 172 89 79 727

6 5

Re: Internet SYN Flooding, spoofing attacks
by Vijay Gill 12 Feb '00

12 Feb '00

IETF removed from the distribution list. On Fri, 11 Feb 2000, Paul Ferguson wrote: > >unicast RPF, but the best compromise is the built-in access filter. The > >solution must be general enough to work for multihomed, defaulting out > >customers with blocks from n providers, > > No, that is a common misconception, or rather, an overstatement of > a pretty easily described situation. It only breaks things in transit > situations, and only in transit situations where you might not have > the same forwarding path back to the source as you would via the same > interface a packet came in on. This is more common than you might believe. For Dialup and single homed, yes, this is not a problem in most cases. For a very large customer base, this problem does not scale all that well, especially for the large backbone carriers who are transiting a lot of traffic. As the internet grows more important to business, more and more people multihome. > This is a small percentage, I would thing, since the percentage of > ISP's offering transit pales in comparison to all other "access" > ISP's that do not. And in cases where ISP's _do_ offer transit, or > have transit agreements, will they really do this on their transit > interfaces? I think not. I think you're solving something else. I submit that almost _all_ isp's offer transit for their customers. Thats where the I part of the SP comes in. For _peering_ links (peering being defined elsewhere), yes, this is a hard problem, but on the edges of the _peers_, this is not. If everyone filtered their T1/DSx/OCx/E1/E3/STMx customers at their edges, using Unicast RPF where appropriate and filters where appropriate, life would become better. /vijay

1 0

laptop AC cord lost at NANOG
by Joe McGuckin 11 Feb '00

11 Feb '00

AC power cord for IBM laptop was left plugged into a power strip on front row, right side of conference room. If anyone fould it, please contact me. It's a wierd little cord with a triangular plug... -joe -- Joe McGuckin ViaNet Communications 994 San Antonio Road Palo Alto, CA 94303 Phone: 650-969-2203 Cell: 650-207-0372 Fax: 650-969-2124

1 0

The Cidr Report
by Tony Bates 11 Feb '00

11 Feb '00

This is an auto-generated mail on Fri Feb 11 12:00:00 PST 2000 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 11Feb00 0) General Status Table History ------------- Date Prefixes 040200 71335 050200 71195 060200 71192 070200 71282 080200 71554 090200 71729 100200 71823 110200 71788 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 219.91.160.0/22 from AS7742 *** Bogus 219.91.164.0/23 from AS7742 AS Summary ---------- Number of ASes in routing system: 6639 Number of ASes announcing only one prefix: 3604 (1959 cidr, 1645 classful) Largest number of cidr routes: 704 announced by AS701 Largest number of classful routes: 980 announced by AS701 1) Gains by aggregating at the origin AS level --- 11Feb00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 439 153 286 65.1% BCnet Backbone AS7046 426 283 143 33.6% UUNET-CUSTOMER AS1221 663 527 136 20.5% TELSTRA-AS AS9269 141 25 116 82.3% Hong Kong CTI AS9706 139 32 107 77.0% Pusan Metropolitan City Office of AS2609 124 18 106 85.5% EUnet-TN AS7657 286 187 99 34.6% The Internet Group Limited AS4293 272 175 97 35.7% Internal ASN for C&W AS2715 157 62 95 60.5% REDERIO-AS AS7545 154 61 93 60.4% TPG Internet Pty Ltd AS6429 205 118 87 42.4% RDC-INTERNET AS7496 124 38 86 69.4% Power Up AS174 559 476 83 14.8% Performance Systems International AS705 301 220 81 26.9% ALTERNET-AS AS816 379 302 77 20.3% UUNET Canada (ASN-UUNETCA-AS4) AS3749 137 61 76 55.5% TECNET AS9304 99 24 75 75.8% Hutchcity AS577 248 175 73 29.4% Bell Backbone AS3602 316 247 69 21.8% Sprint Canada Inc. AS7029 113 48 65 57.5% ALLTELNET AS4200 170 105 65 38.2% AGIS (Apex Global Information Ser AS4740 333 275 58 17.4% Ozemail Pty Ltd (ASN-OZEMAIL) AS1727 139 81 58 41.7% MRMS-WEST AS7260 103 46 57 55.3% NORLIGHT AS209 385 333 52 13.5% Qwest Communications AS4151 97 50 47 48.5% USDA Internet Access Network AS9557 66 21 45 68.2% Pakistan Telecommunication Compan AS4000 96 51 45 46.9% Global IP AS7568 59 15 44 74.6% C.S. Communications Co., Ltd. AS684 87 45 42 48.3% Manitoba Regional Network Backbon For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

Found Cell Phone at NANOG 18
by Pam Ciesla 11 Feb '00

11 Feb '00

We found a cell phone at NANOG 18. Please contact me if it's yours. Thanks Pam Pam Ciesla Events Coordinator Merit Network,Inc. 734-936-0172 - phone 4251 Plymouth Road 734-647-3185 - fax Bldg.I, Suite 2000 pam(a)merit.edu Ann Arbor, MI 48105

1 0

marketing consultants to the rescue
by Faisal Jawdat 11 Feb '00

11 Feb '00

http://gt.clickz.com/cgi-bin/gt/cz/cz.html?article=1311 "The solution, if you haven't heard, is before the Internet Engineering Task Force as one of the proposals for the IPv6 specification, which will replace the current IPv4. That is, support the tracing and tapping of IP calls." *sigh* Who let the marketing consultants out of the cage? -faisal

1 0

Re: Does Anyone Care?
by Brian Dickson 11 Feb '00

11 Feb '00

> But why would the interface always transmit broadcasts to the FDDI > interface in Spokane and show excessive latency at anytime of the day > that you try to connect/send an echo reply at it. A) Because *multicast*, when sent on a *broadcast* media like FDDI, is sent as *broadcast* packets (to avoid replication); B) Because multicast is very VIP2 CPU-intensive, doing all kinds of funky things - we see that on very low utilization, there is high CPU. This in turn shows up as latency *to* the router, but not *through* the router (different switching paths). Basically, this is normal, and ~5Mbps is about right for this traffic. > On Fri, 11 Feb 2000, Bjorn Carlsson wrote: > > > Hi, > > > > Not sure I follow. schnell.ebone.net is actually an interface of Sprint > > icm-bb1-pen which connects to a FDDI ring in Pennsauken built for multicast. > > The name/address (schnell.ebone.net) is there for historial reasons and > > should be changed to something-else.icp.net. > > > > As for directed broadcast it is long since turned off on all EBONE > > routers. > > > > --BC > > -- Brian Dickson, Email: briand(a)teleglobe.net Director, Backbone Engineering Tel : +1 703 755 2056 Teleglobe Communications Corp., Fax : +1 703 755 2648 Rm 3214, 11480 Commerce Park Drive, Cell : +1 703 851 9053 Reston, Virginia, USA, 20191 http://www.teleglobe.com

1 0

Re: [RE: Make Inggress Filtering the LAW for all ISPs!]
by Toplez Razer 11 Feb '00

11 Feb '00

Just educate the customers about Inggress Filtering, then they will demand for it to be implemented. To those ISPs who do not (or slow) to comply, they will receive BAD PR Rap!!! Knowledge and Market Rule! Audie Onibala ************************************************* jlixfeld(a)idirect.com wrote: Who's going to regulate it? How do you check to see if ISP A has implemented it? -----Original Message----- From: Toplez Razer To: nanog(a)merit.edu Sent: 11/02/00 8:07 AM Subject: Make Inggress Filtering the LAW for all ISPs! It should eliminate 99.9% of DOS attacks! Audie Onibala ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1

1 0

Re: Fair Queuing combats DDoS? [was Re: Yahoo! Lessons Learned ]
by michael.dillon＠gtsip.net 11 Feb '00

11 Feb '00

On Thu, 10 February 2000, Alex Bligh wrote: > In the words of Mr Bush, I want something for clueful people to > be able to type after "conf t". Asking people who probably aren't on this > mailing list and almost certainly don't understand the problem to > fix *their* network does not cut the mustard. We need the ability to ask the routers to reverse traceroute a flow. This doesn't have anything to do with the way in which the traceroute utility uses UDP and ICMP packets to trace a route. Instead, it requires router vendors to add the ability to do one of these two things. Either identify the ingress interface of packets with a specific source IP address or identify the ingress interfaces and short term packet counts given a specific destination IP address. In this case, short term refers to a few seconds. If this capability is made available remotely in the same way that ICMP echo is available to anyone, then we can build tools which will track a packet stream back to the true source. In the case of using the destination address, this tool will need some heuristics to deal with multiple possible upstreams which could be caused by a DDoS or simply by making a bad guess about which traffic stream is the DoS stream. And in some circumstances it just won't be able to track it to the source. But, if we had a tool to track back DoS streams to an ingress router on the edge of a backbone operator's network, then we have some hard data to use to get the flow blocked. I know that right now, calling another operator's NOC to ask them to cooperate in damping an attack is not always effective. But the hard data is the first step. --- Michael Dillon Phone: +44 (20) 7769 8489 Mobile: +44 (79) 7099 2658 Director of Product Engineering, GTS IP Services 151 Shaftesbury Ave. London WC2H 8AL UK

1 0