- NANOG - lists.nanog.org

[fwd] Lawyers Forsee Denial Of Service Suits
by Paul Ferguson 12 Feb '00

12 Feb '00

It has begun. Sigh. FYI, - paul http://www.techweb.com/wire/story/TWB20000211S0014

2 1

Re: Internet SYN Flooding, spoofing attacks
by Mark Prior 12 Feb '00

12 Feb '00

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. Maybe not as small as you think when simplex satellite is involved. Mark.

1 0

Re: Internet SYN Flooding, spoofing attacks
by Mark Prior 12 Feb '00

12 Feb '00

We (at least cisco, anyways) already have a knob for this: [no] ip verify unicast reverse-path We call it Unicast RPF. And its well documented... NOT and available on all routers/interfaces... NOT If it was documented and available on things like PRIs then it would be a lot easier to deploy. Also some of the bugs that turn off CEF need to be addressed (or at least also cause "ip verify unicast reverse-path" to be turned off too). Mark.

1 0

POWER OUTAGE: Palo Alto California
by Sean Donelan 12 Feb '00

12 Feb '00

There is a power failure in parts of Palo Alto California. I bring this up because the last time Palo Alto had power problems, several providers had significant outages. So far, it appears major providers are operating normally. Outages are confined to individual customers, which I assume is due to loss of power at the customer location.

1 0

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

12 Feb '00

At 10:44 PM 02/11/2000 -0500, Vijay Gill wrote: >I suspect we are in violent agreement here. Violent agreement. What a concept! ;-) - paul

1 0

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