- Test - lists.nanog.org

RE: Cisco - ip verify unicast reverse-path
by Paul Ferguson 13 Feb '00

13 Feb '00

At 09:18 PM 02/12/2000 -0500, jlixfeld(a)idirect.com wrote: >Correct me if I'm wrong, but it has the potential to cause more damage than >anything else if you network routes asynchronously. I turned it on a while >ago and noticed my in and outbound traffic dropped by about 60%. I'm sure >that the 60% drop in traffic had to do with traffic coming into the network >on one interface and being local pref'd out a different interface. > >Because of the asynchronous routing, it's useless in my environment, unless >there is a knob that doesn't cause it to break under these circumstances. > >If not, would this feature not be best suited for ISPs who are not in a BGP >relationship with their upstreams? Like everything else, it depends. There's always RFC2267. - paul

1 0

Make Inggress Filtering the LAW for all ISPs!
by Toplez Razer 12 Feb '00

12 Feb '00

It should eliminate 99.9% of DOS attacks! Audie Onibala ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1

7 7

[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