Re: Effective ways to deal with DDoS attacks?
On Wed, 1 May 2002, Pete Kruckenberg wrote: > > On Thu, 2 May 2002, Richard A Steenbergen wrote: > > >> SYN packet comes in, one of these machines responses with a > >> RST to the "source", which is actually the target of the > > > > You have an interesting situation. I think rate limiting > > outbound RSTs would be the least offensive thing you > > could do, off the top of my head. > > What about just blocking out-going RSTs altogether from our > borders? While this interferes with "proper" TCP > functionality, would it actually interfere enough to cause > noticeable problems? Would certainly be less of a burden on > routers than rate-limiting. Aren't the initial packets in the 'gibson syn amp attack' syn-ack's?
Re: Effective ways to deal with DDoS attacks?
On Thu, 2 May 2002, Richard A Steenbergen wrote: >> SYN packet comes in, one of these machines responses with a >> RST to the "source", which is actually the target of the > > You have an interesting situation. I think rate limiting > outbound RSTs would be the least offensive thing you > could do, off the top of my head. What about just blocking out-going RSTs altogether from our borders? While this interferes with "proper" TCP functionality, would it actually interfere enough to cause noticeable problems? Would certainly be less of a burden on routers than rate-limiting. Pete.
Re: Effective ways to deal with DDoS attacks?
On Thu, 2 May 2002, Christopher L. Morrow wrote: > Funny, you say 'secured' here... > > > These are not zombies. They are secured, uncompromised Web > > servers. The attack spoofs the target address as the source, [snip] > and here you say: "printers and routers" Since when did > they need to be accessible off campus? Additionally, why > does a router need a web interface?? Printers are on the > cusp, but they certainly don't need to be accesible from > out of your LAN. More clarification needed. We are not a campus network. We are a state-wide research/education network, as in we are the service provider to the various K-12 and higher-ed institutions in the state (there is a network, not a purchasing cooperative like many other state "networks"). We are large in the sense that there are some 1,000 end sites (each comparable in size to a mid- to large-size enterprise) and a network that looks like many national networks, but condensed into a single state. We tend to design and operate our network, and experience problems similar to a national-scale network. Like almost every other service provider, we do not have the luxury of simply putting a firewall at the border of our network, since we do not have the ability to enforce security policies any more than other service providers do. We also have the ability to suggest security policy and block hosts or networks that interfere with network operations, but it's not our business whether someone uses a Web interface to their printer or router any more than it's UUNet's business. We do have a fairly aggressive security group that identifies compromised machines and assists customers in properly securing them. We can be fairly certain that the way these hosts are responding to this DoS attack is not as a result of being compromised, but a "normal" IP stack implementation. As such, though we are a state education service provider, it seems that these kinds of attacks are most likely pervasive on all networks, and probably are going on all the time. One advantage we have is a close relationship with our customers, which allows us to use tools such as IDS and Netflow in conjunction with information about the customer implementation to identify what is a bonafide attack. Pete.
Re: Effective ways to deal with DDoS attacks?
On Wed, 1 May 2002, Basil Kruglov wrote: > > On Thu, May 02, 2002 at 04:45:43AM +, Christopher L. Morrow wrote: > > On Wed, 1 May 2002, Wojtek Zlobicki wrote: > > > > > > Where are providers drawing the line ? Anyone have somewhat detailed > > > published policies as to what a provider can do in order to protect their > > > nework as a whole. > > > At what point (strength of the attack) does a customers netblock (assuming a > > > /24 for > > > example) get null routed by whichever party. > > > > Most providers likely have a policy similar to: "I can't sacrafice 1 > > my network for 1 customer". So, if the attack is sufficient to degrade > > service on the ISP network most likely the customer under attack will get > > null routed. > > Are you saying UUnet, assuming for a sec that I am a customer of UUnet (just > for the sake of the argument), UU will not null route my ircd if it > it gets attacked on regular basis, say *daily* ? I did not say that. > > Furthermore you are going to consistently place filters on your routers, > take them out within the 24h (or whatever then-current policy of UUnet is) > and track attacks back to their sources within the boundaries of your > backbone on a daily basis? ;) > uhm... sure, we do this now... or have you not been paying attention? > Will you do that for say a regular T1 customer or do I need more "commitment" > as sales droids like to put it, to even consider such a service ? ;) > read above. > > Hmm, perhaps FIRST customers should insist that their ISP have some 24/7 > > security contact that can actually help in the case of an attack. Today > > there are very few that have this capability. I'd say from personal > > experience that the number is way too small, even in the 'large' ISP arena > > :( > > > > More pressure from customers for real security would be a good start. > > sigh, tried and failed, miserably I might add. > Then become a UUNET customer cause we already do this... Perhaps other providers with 24/7 security teams will pipe up to give potential customers a heads-up on options other than UUNET? If you go with UUNET please tell the sales driod I sent you cause then I get 50 bucks :) (my only raise thanks to bernie)
Re: Effective ways to deal with DDoS attacks?
On Wed, 1 May 2002, Pete Kruckenberg wrote: > > On Wed, 1 May 2002 [EMAIL PROTECTED] wrote: > > > and then again, there has been much discussion on simple > > DoS attacks, where the term DDoS is erroneously used... > > I am very much not trying to imply that this is the case > > here, but it's important that the two be thoroughly > > distinguished from each other - they are totally > > different things to deal with. > > Sorry, I should have been more clear. > > My issue (currently) is not being the target of the DDoS > attack, but being a (unwilling) participant. People outside > our network are launching DDoS attacks (distributed SYN > floods) against destinations outside our network, using > about 8,000 Web server hosts on our network as reflectors. Funny, you say 'secured' here... > > These are not zombies. They are secured, uncompromised Web > servers. The attack spoofs the target address as the source, > and one of our machines as a destination, port 80. Getting > everyone to implement defenses (SYN cookies) on their Web > servers is nearly impossible (most don't even have a > defense--printers and routers with Web interfaces). > and here you say: "printers and routers" Since when did they need to be accessible off campus? Additionally, why does a router need a web interface?? Printers are on the cusp, but they certainly don't need to be accesible from out of your LAN.
Re: Effective ways to deal with DDoS attacks?
On Wed, 1 May 2002, Pete Kruckenberg wrote:
>
> On Wed, 1 May 2002, Richard A Steenbergen wrote:
>
> > "DDoS attacks" is such a generic term. There are a wide
> > variety of attacks which each need to be handled in
> > their own way, the extra "D" is just one possible twist.
> > Can you explain what kind of attack you're interested
> > in?
>
> We experience a lot of types of attacks ("education/research
> network" = "easy hacker target"). With DDoS incidents, it
> seems we are more often an unknowing/unwilling participant
> than the target, partly due to owning big chunks of IP
> address space.
>
> We most frequently are the zombie/reflector participants in
> an attack that originates outside our network, to a target
> outside our network. As many as 8,000 hosts on our network
> are reflecting SYN floods in the current attacks.
Sounds like its time for a firewall on your network :)
>
> Identification doesn't seem to be a problem. Snort is doing
> far too well notifying us. Responding and managing all of
> the defenses is becoming a lot of pain-staking work, and
> error-prone (why can't Cisco make ACLs easier to manage).
>
they aren't tough to 'manage' they are sometimes tough to live with though
:(
> Our approach so far has been temporary blocks (via ACL) of
> the target address. Blocking 8,000 internal addresses, many
> legitimate (secured) Web servers, generates more complaints.
>
> I'm thinking about a scripted Zebra feed where route
> injections are triggered by Snort. Routes for the target
> and/or SYN flood reflector hosts could be injected
> temporarily during the attack to border routers, which would
> route-map those routes to Null0. Script periodically
> withdraws routes to see if the attack is over (some of these
> last weeks, some only last a few seconds), to minimize the
> impact on those otherwise legitimate hosts.
>
This is a nice idea, anything 'scripted' is prone to abuse though ;( all
of a sudden www.your.edu is dead.. on class registration day no less.
> Has anyone tried this kind of an approach or any other type
> of automated/efficient approach to dampen the "zombie" side
> of the DDoS attack?
>
Re: Effective ways to deal with DDoS attacks?
On Thu, May 02, 2002 at 04:45:43AM +, Christopher L. Morrow wrote: > On Wed, 1 May 2002, Wojtek Zlobicki wrote: > > > > Where are providers drawing the line ? Anyone have somewhat detailed > > published policies as to what a provider can do in order to protect their > > nework as a whole. > > At what point (strength of the attack) does a customers netblock (assuming a > > /24 for > > example) get null routed by whichever party. > > Most providers likely have a policy similar to: "I can't sacrafice 1 > my network for 1 customer". So, if the attack is sufficient to degrade > service on the ISP network most likely the customer under attack will get > null routed. Are you saying UUnet, assuming for a sec that I am a customer of UUnet (just for the sake of the argument), UU will not null route my ircd if it it gets attacked on regular basis, say *daily* ? Furthermore you are going to consistently place filters on your routers, take them out within the 24h (or whatever then-current policy of UUnet is) and track attacks back to their sources within the boundaries of your backbone on a daily basis? ;) Will you do that for say a regular T1 customer or do I need more "commitment" as sales droids like to put it, to even consider such a service ? ;) > Hmm, perhaps FIRST customers should insist that their ISP have some 24/7 > security contact that can actually help in the case of an attack. Today > there are very few that have this capability. I'd say from personal > experience that the number is way too small, even in the 'large' ISP arena > :( > > More pressure from customers for real security would be a good start. sigh, tried and failed, miserably I might add. -Basil
Re: Effective ways to deal with DDoS attacks?
On Wed, May 01, 2002 at 08:56:16PM -0600, Pete Kruckenberg wrote: > > Sorry, I should have been more clear. > > My issue (currently) is not being the target of the DDoS > attack, but being a (unwilling) participant. People outside > our network are launching DDoS attacks (distributed SYN > floods) against destinations outside our network, using > about 8,000 Web server hosts on our network as reflectors. Neat, and totally not what people expect when you say "victim of a DDoS attack". > These are not zombies. They are secured, uncompromised Web servers. The > attack spoofs the target address as the source, and one of our machines > as a destination, port 80. Getting everyone to implement defenses (SYN > cookies) on their Web servers is nearly impossible (most don't even have > a defense--printers and routers with Web interfaces). Thats not a defense anyways, SYN cookies still send replies (which is what the attacker wants), they just don't store state information (which is probably not an issue anyways, unless their stack is REALLY bad or old it's probably not going to care that much). > SYN packet comes in, one of these machines responses with a > RST to the "source", which is actually the target of the > attack. Unfortunately, the target is often a site that > people would like to get to, as is the reflector, so > permanent filters on the target or reflector create lots of > complaints. You have an interesting situation. I think rate limiting outbound RSTs would be the least offensive thing you could do, off the top of my head. -- Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
Re: Effective ways to deal with DDoS attacks?
On Wed, 1 May 2002, Richard A Steenbergen wrote: > > I give it 2 months, then they'll start hitting random dst IPs in a target > prefix (say a common /24 going through the same path). > Damn you, don't give them any ideas :)
Re: Effective ways to deal with DDoS attacks?
On Thu, May 02, 2002 at 04:28:44AM +, Christopher L. Morrow wrote: > > Let me say this one more time... "RATE LIMITS DON'T DO SHIT TO STOP > ATTACKS" for the victim atleast, all they do is make the job of the > attacker that much easier. For instance: > > 1) I synflood www.avleen.org > 2) you rate-limit syns to 1MB > 3) I now only flood 1MB and I still win > > So, don't rely on a rate-limit as its not going to help. Thank you, I can't make this point enough and people still say "we'll just rate limit!". Filtering is only as good as your ability to DETERMINE WHAT TO FILTER. The only time you can get anything from this is when you admit defeat on keeping your services responding to new connection but want to keep existing connections and/or the end servers from failing completely. Depending on the service in question this may or may not be a good goal. -- Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
Re: Effective ways to deal with DDoS attacks?
On Wed, 1 May 2002, Wojtek Zlobicki wrote: > > Where are providers drawing the line ? Anyone have somewhat detailed > published policies as to what a provider can do in order to protect their > nework as a whole. > At what point (strength of the attack) does a customers netblock (assuming a > /24 for > example) get null routed by whichever party. Most providers likely have a policy similar to: "I can't sacrafice 1 my network for 1 customer". So, if the attack is sufficient to degrade service on the ISP network most likely the customer under attack will get null routed. > > > Anyways, some providers already allow you to set a community on a route, > > and they will inturn "blackhole" it for you. I believe Teleglobe does > > this for some customers and I know UUNet does this for all customers. > > When the attack is distributed, having one or two providers (even if they > are UUNET > or Teleglobe) is just not enough. Must private routing policy be developed > in order to make my suggestion work. The reason that so many methods likely > fail are the difficulty of implementation and low implementation. Hmm, perhaps FIRST customers should insist that their ISP have some 24/7 security contact that can actually help in the case of an attack. Today there are very few that have this capability. I'd say from personal experience that the number is way too small, even in the 'large' ISP arena :( More pressure from customers for real security would be a good start.
Re: Large ISPs doing NAT?
On Wednesday, May 1, 2002, at 10:33 , Steven J. Sobol wrote: > > On Wed, 1 May 2002, Deepak Jain wrote: > >> I'm more concerned that if the major metropolitan markets deploying >> GPRS >> all use NAT, then the Next Big Thing won't ever happen on GPRS devices. >> Customers won't jump ship if they have no where to jump to. > > The only people who'd be deploying GPRS are GSM cellular providers, no? The concern exists regardless of the specifics of the always-on, cellular packet radio protocols being used, surely? > [GSM coverage is patchy in the US] It's prevalent elsewhere. I'd be surprised if there aren't more GSM subscribers in the world than non-GSM subscribers. Joe
Re: Effective ways to deal with DDoS attacks?
On Wed, 1 May 2002, dies wrote: > > > Then you are pushing out /32's and peers would need to accept them. Then > someone will want to blackhole /30's, /29's, etc. Route bloat. Yum! > Yes. > Additionally you are creating a way to basically destroy the Internet as a > whole. One kiddie gets ahold of a router, say of a large backbone > provider, takes one of their aggregate blocks (/16? /10? /8?) and splits > it into /32 announcements. > Or, blackhole the /16 :) more fun! (assuming no other smaller announcements inside that /16 of course) > Anyways, some providers already allow you to set a community on a route, > and they will inturn "blackhole" it for you. I believe Teleglobe does > this for some customers and I know UUNet does this for all customers. Hmm, Mr. 'dies' is almost correct... if you are a UUNET customer and you would like to do this please call the customer service center and they will help you to configure this 'service'. Thanks though Mr. 'dies' :) > > On Wed, 1 May 2002, Wojtek Zlobicki wrote: > > > > > > > What processes and/or tools are large networks using to > > > > identify and limit the impact of DDoS attacks? > > > > > > A great deal of thought is being expended on this question, I am certain, > > > however, how many of these thought campaings have born significant fruit > > yet, > > > I do not know. > > > > How about the following : > > > > We develop a new community , being fully transitive (666 would be > > appropriate ) and either build into router code or create a route map to > > null route anything that contains this community. The effect of this being > > the distribution of the force of the attack. > > > > This aside, how effective would be using a no export community with ones > > peers (being non transitive, it would still distribute the force of the > > attack). > > > > > > >
Re: Effective ways to deal with DDoS attacks?
On Wed, 1 May 2002, Wojtek Zlobicki wrote: > > > > What processes and/or tools are large networks using to > > > identify and limit the impact of DDoS attacks? > > > > A great deal of thought is being expended on this question, I am certain, > > however, how many of these thought campaings have born significant fruit > yet, > > I do not know. > > How about the following : > > We develop a new community , being fully transitive (666 would be > appropriate ) and either build into router code or create a route map to > null route anything that contains this community. The effect of this being > the distribution of the force of the attack. How about no. How about you do this inside YOUR network, perhaps get an agreement with your peers to accept a /32 route from you and you can do it with your peers also in times of need... There is something ominous about 'automagically propogating' a blackhole route. 1) I hack connected ISP X 2) I inject www.ebay.com /32 blackhole route 3) no more ebay I use ebay as an example of course, I wouldn't want them harmed cause how would I be able to buy all that nice routing gear at bargain basement prices without them? :) > > This aside, how effective would be using a no export community with ones > peers (being non transitive, it would still distribute the force of the > attack). For YOUR PEERS this is a fine idea, provided this fits with your peer's edge policies and doesn't step on his already-used community.
Re: Effective ways to deal with DDoS attacks?
On Wed, 1 May 2002 [EMAIL PROTECTED] wrote: > True DDoS attacks, fortunately, are rarer than most people believe. If they > were not, the Internet as we know it would look a lot more like a telephone > system in USSR-at-it's-worst-days. For example, of the two recent DDoS's I > have been on the receiving end of, the first was generating a little over > 300mbit/sec (steady for a prolonged time), and the second went over that by a > fair bit. In both cases, we had core equipment (M20's and BSN5000's) fall > over and die trying to "work" the events. Additionally, our upstream peers Your M20 tipped over?? What were you doing? We regularly stop large (+100Mb->800Mb) attacks with less horsepower than this. Truthfully, a cisco is even capable of filtering (done right) at +200kpps... > also had core equipment fall over, and we all came the [now obvious] > conclusion that the only way to stop these attacks was to completely null > route ourselves at our upstreams (they tried filter-fishing for specific data > which may have helped our investigation, but when their routers started > wheezing, we gave them the OK to just send us straight into the bit bucket > till it was over... > Hmm, this highlights the need to learn how to use the equipment, learn its boundaries and learn defenses inside these boundaries... -Chris
Re: Effective ways to deal with DDoS attacks?
On Thu, 2 May 2002, Avleen Vig wrote: > > On Wed, 1 May 2002, Pete Kruckenberg wrote: > > > A rather extensive survey of DDoS papers has not resulted in > > much on this topic. > > > > What processes and/or tools are large networks using to > > identify and limit the impact of DDoS attacks? > > Hazaa.. something I know a little about. > > DDoS attacks by their very nature, are distributed. > The primary purpose of more DDoS attacks is to flood the target's upstream > connection to the point of saturation. > > As time goes by, tools are being developed (in fact they're used now) that > completely randomize the TCP or UDP ports attacked, or use a variety of > icmp types in the attack. > So cuurrently the only way you can 'block' such attacks is to block all > packets for the offending protocol as far upstream as you possibly can, > but this is not ideal. > > If you're being attacked by a SYN flood, you can ask try to rate-limit the > flood at your border (possible on Cisco IOS 12.0 and higher, and probably > other routers too?) Let me say this one more time... "RATE LIMITS DON'T DO SHIT TO STOP ATTACKS" for the victim atleast, all they do is make the job of the attacker that much easier. For instance: 1) I synflood www.avleen.org 2) you rate-limit syns to 1MB 3) I now only flood 1MB and I still win So, don't rely on a rate-limit as its not going to help. > > If you're being smurfed, you can block ICMP Echo Reply's inbound to the > target IP. > > It all depends on the TYPE of attack. > This point is very good, depending on the attack your ISP (or you) might have to take different counter measures to stop the attack... You (or your ISP) will need to know as much as possible about the attack, the defenses available on the hardware/software in the network, and actually be available when there is a problem. > Having said that, it's only a matter of time before somebody releases a > tool that saturates a line by spooofing the source, randomizing the > protocol, and ports, and maybe even atacking other hosts on the same > subnet, etc etc. > > The only thing you can try and do is work with your upstream provider and > try to trace the source of the attacks back, but that's incredibly > difficult. > This depends :) Call us, if you are our customer, and I guarantee that someone will be there to resolve your issue, most times in 5 minutes or less. Perhaps other ISP's should start having some folks on staff and available for these tasks? (hint, Hint, HINT!!!) > As a side note, does anyone know the status of the ICMP Traceback > proposal? The ieft draft expired yesterday: > http://www.ietf.org/internet-drafts/draft-ietf-itrace-01.txt This is a wasted effort. It's not feasible, nor is it reasonable. There are tools in place today that perform this function without the required changes to protocols/functionality. Why would you want to make things incrementally more difficult when the technology exists today to do this? -Chris
Re: Effective ways to deal with DDoS attacks?
What we use and we're a 'largeish' network: http://www.secsup.org/Tracking/ (shameless plug #1) Among other things this is a tool we use... there was a great set of slides and presentation given at NANOG23: http://www.nanog.org/mtg-0110/greene.html (shameless plug #2) There is also a set of papers Barry Greene from Cisco has available on the Cisco website... I'm positive he'll respond to this with the link, if he doesn't search the NANOG mailing list archive for the link it should be obvious in posts from Barry. If you want more pointers I'd be glad to chat on the phone with you, numbers included below. --Chris ([EMAIL PROTECTED]) ### ## UUNET Technologies, Inc. ## ## Manager ## ## Customer Router Security Engineering Team ## ## (W)703-886-3823 (C)703-338-7319 ## ### On Wed, 1 May 2002, Pete Kruckenberg wrote: > > There's been plenty of discussion about DDoS attacks, and my > IDS system is darn good at identifying them. But what are > effective methods for large service-provider networks (ie > ones where a firewall at the front would not be possible) to > deal with DDoS attacks? > > Current method of updating ACLs with the source and/or > destination are slow and error-prone and hard to maintain > (especially when the target of the attack is a site that > users would like to access). > > A rather extensive survey of DDoS papers has not resulted in > much on this topic. > > What processes and/or tools are large networks using to > identify and limit the impact of DDoS attacks? > > Thanks. > Pete. > >
Re: Effective ways to deal with DDoS attacks?
On Wed, 1 May 2002 [EMAIL PROTECTED] wrote: > and then again, there has been much discussion on simple > DoS attacks, where the term DDoS is erroneously used... > I am very much not trying to imply that this is the case > here, but it's important that the two be thoroughly > distinguished from each other - they are totally > different things to deal with. Sorry, I should have been more clear. My issue (currently) is not being the target of the DDoS attack, but being a (unwilling) participant. People outside our network are launching DDoS attacks (distributed SYN floods) against destinations outside our network, using about 8,000 Web server hosts on our network as reflectors. These are not zombies. They are secured, uncompromised Web servers. The attack spoofs the target address as the source, and one of our machines as a destination, port 80. Getting everyone to implement defenses (SYN cookies) on their Web servers is nearly impossible (most don't even have a defense--printers and routers with Web interfaces). SYN packet comes in, one of these machines responses with a RST to the "source", which is actually the target of the attack. Unfortunately, the target is often a site that people would like to get to, as is the reflector, so permanent filters on the target or reflector create lots of complaints. > We captured several seconds of the last DDoS and came up > with over 700 participating hosts... Some of them probably appear to be from our network... Pete.
Re: Effective ways to deal with DDoS attacks?
On Wed, 1 May 2002, Pete Kruckenberg wrote:
> We experience a lot of types of attacks ("education/research
> network" = "easy hacker target"). With DDoS incidents, it
> seems we are more often an unknowing/unwilling participant
> than the target, partly due to owning big chunks of IP
> address space.
Universities are hacker training grounds, but also have much
better network security response than most corporate networks.
Whatever problems you have, the rest of us will have soon enough
it may just take us longer to notice it.
> Has anyone tried this kind of an approach or any other type
> of automated/efficient approach to dampen the "zombie" side
> of the DDoS attack?
Has anyone implemented Bellovin's Pushback in a production
network yet?
Re: Effective ways to deal with DDoS attacks?
On Wed, 1 May 2002, Richard A Steenbergen wrote:
> "DDoS attacks" is such a generic term. There are a wide
> variety of attacks which each need to be handled in
> their own way, the extra "D" is just one possible twist.
> Can you explain what kind of attack you're interested
> in?
We experience a lot of types of attacks ("education/research
network" = "easy hacker target"). With DDoS incidents, it
seems we are more often an unknowing/unwilling participant
than the target, partly due to owning big chunks of IP
address space.
We most frequently are the zombie/reflector participants in
an attack that originates outside our network, to a target
outside our network. As many as 8,000 hosts on our network
are reflecting SYN floods in the current attacks.
Identification doesn't seem to be a problem. Snort is doing
far too well notifying us. Responding and managing all of
the defenses is becoming a lot of pain-staking work, and
error-prone (why can't Cisco make ACLs easier to manage).
Our approach so far has been temporary blocks (via ACL) of
the target address. Blocking 8,000 internal addresses, many
legitimate (secured) Web servers, generates more complaints.
I'm thinking about a scripted Zebra feed where route
injections are triggered by Snort. Routes for the target
and/or SYN flood reflector hosts could be injected
temporarily during the attack to border routers, which would
route-map those routes to Null0. Script periodically
withdraws routes to see if the attack is over (some of these
last weeks, some only last a few seconds), to minimize the
impact on those otherwise legitimate hosts.
Has anyone tried this kind of an approach or any other type
of automated/efficient approach to dampen the "zombie" side
of the DDoS attack?
Pete.
RE: Large ISPs doing NAT?
On Wed, 1 May 2002, Deepak Jain wrote: > I'm more concerned that if the major metropolitan markets deploying GPRS > all use NAT, then the Next Big Thing won't ever happen on GPRS devices. > Customers won't jump ship if they have no where to jump to. The only people who'd be deploying GPRS are GSM cellular providers, no? Verizon and Sprint PCS, in particular, are not using GPRS, but migrating to CDMA-based 3G cellular technologies. I don't know that those technologies use CDMA. And of course, there are still markets like my very own hometown (2nd largest city in Ohio) that don't have GSM yet (even though #1 and #3 do). VoiceStream is supposedly launching their GSM network in Cleveland (*snort* I've heard that before). But they're not here yet, AT&T is nowhere near doing GSM here as far as I know, and Cingular's network here (former AmeriBlech Cellular) is TDMA. I could be completely off base, of course. Being a customer of Sprint PCS and Verizon, and a former customer of Alltel and Northcoast PCS, I've not had much reason to follow GSM developments; every one of the companies I've used runs CDMA. Feel free to correct me if I am wrong. -- Steve Sobol, CTO (Server Guru, Network Janitor and Head Geek) JustThe.net LLC, Mentor On The Lake, OH 888.480.4NET http://JustThe.net "The Indians are unfolding into the 2002 season like a lethal lawn chair." (_News-Herald_ Indians Columnist Jim Ingraham, April 11, 2002)
Re: Effective ways to deal with DDoS attacks?
On Wed, May 01, 2002 at 10:15:44PM -0400, Leo Bicknell wrote: > > In a message written on Wed, May 01, 2002 at 08:17:04PM -0500, dies wrote: > > Then you are pushing out /32's and peers would need to accept them. Then > > someone will want to blackhole /30's, /29's, etc. Route bloat. Yum! > > I'm not sure what form this would take, but I have long wished > route processing could be sent into a "programming language". For > this specific example it would be nice to set a maximum number of > route limit for the total number of routes on the session, as well > as /per community/. Agreed wholeheartedly. But then you'd have to have network engineers who could program (and no perl doesn't count). :) > That is, community :666 == blackhole me, and I could limit each > peer to say, 6 of these at a time. More would not take down the > session, but simply be ignored. > > I can carry 6 /32's for every peer I have, and if they only have > 6, they will probably use them for the most abusive target. I give it 2 months, then they'll start hitting random dst IPs in a target prefix (say a common /24 going through the same path). -- Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
Re: Effective ways to deal with DDoS attacks?
On Wed, May 01, 2002 at 09:38:52PM -0400, Wojtek Zlobicki wrote: > > How about the following : > > We develop a new community , being fully transitive (666 would be > appropriate ) and either build into router code or create a route map to > null route anything that contains this community. The effect of this being > the distribution of the force of the attack. This has been proposed a dozen times over, and I agree that there should be a well known community for discarding packets. Go try and get the IETF to add it, let me know how it goes. :) > This aside, how effective would be using a no export community with ones > peers (being non transitive, it would still distribute the force of the > attack). Many people do this already. If you're looking to purchase transit and you think this is something you'll care about, ask for it or vote with your wallet. -- Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
Re: Effective ways to deal with DDoS attacks?
In a message written on Wed, May 01, 2002 at 08:17:04PM -0500, dies wrote: > Then you are pushing out /32's and peers would need to accept them. Then > someone will want to blackhole /30's, /29's, etc. Route bloat. Yum! I'm not sure what form this would take, but I have long wished route processing could be sent into a "programming language". For this specific example it would be nice to set a maximum number of route limit for the total number of routes on the session, as well as /per community/. That is, community :666 == blackhole me, and I could limit each peer to say, 6 of these at a time. More would not take down the session, but simply be ignored. I can carry 6 /32's for every peer I have, and if they only have 6, they will probably use them for the most abusive target. There are, of course, approximately an infinitate number more applications for a more flexible mechanism. Of course, it would require more human smarts, which might be why vendors don't do it. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
Re: Effective ways to deal with DDoS attacks?
> Then you are pushing out /32's and peers would need to accept them. Then > someone will want to blackhole /30's, /29's, etc. Route bloat. Yum! I am in no way proposing discounting current filtering rules. There are alway two different intersts one must consider, one that of the customer and two that of the service provider. If a large block must be filtered so be it. Where are providers drawing the line ? Anyone have somewhat detailed published policies as to what a provider can do in order to protect their nework as a whole. At what point (strength of the attack) does a customers netblock (assuming a /24 for example) get null routed by whichever party. > Anyways, some providers already allow you to set a community on a route, > and they will inturn "blackhole" it for you. I believe Teleglobe does > this for some customers and I know UUNet does this for all customers. When the attack is distributed, having one or two providers (even if they are UUNET or Teleglobe) is just not enough. Must private routing policy be developed in order to make my suggestion work. The reason that so many methods likely fail are the difficulty of implementation and low implementation.
Re: Effective ways to deal with DDoS attacks?
Then you are pushing out /32's and peers would need to accept them. Then someone will want to blackhole /30's, /29's, etc. Route bloat. Yum! Additionally you are creating a way to basically destroy the Internet as a whole. One kiddie gets ahold of a router, say of a large backbone provider, takes one of their aggregate blocks (/16? /10? /8?) and splits it into /32 announcements. Anyways, some providers already allow you to set a community on a route, and they will inturn "blackhole" it for you. I believe Teleglobe does this for some customers and I know UUNet does this for all customers. On Wed, 1 May 2002, Wojtek Zlobicki wrote: > > > > What processes and/or tools are large networks using to > > > identify and limit the impact of DDoS attacks? > > > > A great deal of thought is being expended on this question, I am certain, > > however, how many of these thought campaings have born significant fruit > yet, > > I do not know. > > How about the following : > > We develop a new community , being fully transitive (666 would be > appropriate ) and either build into router code or create a route map to > null route anything that contains this community. The effect of this being > the distribution of the force of the attack. > > This aside, how effective would be using a no export community with ones > peers (being non transitive, it would still distribute the force of the > attack). > > >
Re: Effective ways to deal with DDoS attacks?
> > What processes and/or tools are large networks using to > > identify and limit the impact of DDoS attacks? > > A great deal of thought is being expended on this question, I am certain, > however, how many of these thought campaings have born significant fruit yet, > I do not know. How about the following : We develop a new community , being fully transitive (666 would be appropriate ) and either build into router code or create a route map to null route anything that contains this community. The effect of this being the distribution of the force of the attack. This aside, how effective would be using a no export community with ones peers (being non transitive, it would still distribute the force of the attack).
Re: Effective ways to deal with DDoS attacks?
On Wed, 1 May 2002, Pete Kruckenberg wrote: > There's been plenty of discussion about DDoS attacks, and then again, there has been much discussion on simple DoS attacks, where the term DDoS is erroneously used... I am very much not trying to imply that this is the case here, but it's important that the two be thoroughly distinguished from each other - they are totally different things to deal with. > and my > IDS system is darn good at identifying them. Chances are your IDS is detecting simple DoS, or maybe tiny scale DDoS. Full DDoS attacks do not require and IDS to detect ;-) In fact, if your IDS doesn't tip over under the load of a full blown DDoS, I'd sure like to know what it's using for an engine... > But what are > effective methods for large service-provider networks (ie > ones where a firewall at the front would not be possible) to > deal with DDoS attacks? True DDoS attacks, fortunately, are rarer than most people believe. If they were not, the Internet as we know it would look a lot more like a telephone system in USSR-at-it's-worst-days. For example, of the two recent DDoS's I have been on the receiving end of, the first was generating a little over 300mbit/sec (steady for a prolonged time), and the second went over that by a fair bit. In both cases, we had core equipment (M20's and BSN5000's) fall over and die trying to "work" the events. Additionally, our upstream peers also had core equipment fall over, and we all came the [now obvious] conclusion that the only way to stop these attacks was to completely null route ourselves at our upstreams (they tried filter-fishing for specific data which may have helped our investigation, but when their routers started wheezing, we gave them the OK to just send us straight into the bit bucket till it was over... > Current method of updating ACLs with the source and/or > destination are slow and error-prone and hard to maintain > (especially when the target of the attack is a site that > users would like to access). We captured several seconds of the last DDoS and came up with over 700 participating hosts... > > A rather extensive survey of DDoS papers has not resulted in > much on this topic. > > What processes and/or tools are large networks using to > identify and limit the impact of DDoS attacks? A great deal of thought is being expended on this question, I am certain, however, how many of these thought campaings have born significant fruit yet, I do not know. > Thanks. > Pete. -- Yours, J.A. Terranson [EMAIL PROTECTED] If Governments really want us to behave like civilized human beings, they should give serious consideration towards setting a better example: Ruling by force, rather than consensus; the unrestrained application of unjust laws (which the victim-populations were never allowed input on in the first place); the State policy of justice only for the rich and elected; the intentional abuse and occassionally destruction of entire populations merely to distract an already apathetic and numb electorate... This type of demogoguery must surely wipe out the fascist United States as surely as it wiped out the fascist Union of Soviet Socialist Republics. The views expressed here are mine, and NOT those of my employers, associates, or others. Besides, if it *were* the opinion of all of those people, I doubt there would be a problem to bitch about in the first place...
Re: Effective ways to deal with DDoS attacks?
On Thu, May 02, 2002 at 01:49:40AM +0100, Avleen Vig wrote: > > DDoS attacks by their very nature, are distributed. The primary purpose > of more DDoS attacks is to flood the target's upstream connection to the > point of saturation. Actually the original goal (and probably still the primary benefit) of DDoS attacks was to evade detection by using so many hosts that any specific one either went unnoticed or unreported. Having multiple sources to bypass any potential congestion (since a DoS is only as effective as the weakest link along the path) and filtering is still what I would rank as a secondary effect. -- Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
Re: Effective ways to deal with DDoS attacks?
On Wed, May 01, 2002 at 05:18:24PM -0600, Pete Kruckenberg wrote: > > A rather extensive survey of DDoS papers has not resulted in > much on this topic. > > What processes and/or tools are large networks using to > identify and limit the impact of DDoS attacks? "DDoS attacks" is such a generic term. There are a wide variety of attacks which each need to be handled in their own way, the extra "D" is just one possible twist. Can you explain what kind of attack you're interested in? I've tried to compile a list of the *practical* things everyone needs to know (but usually doesn't) to handle DoS effectively, try reading: http://www.e-gerbil.net/ras/projects/dos/dos.txt -- Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
Re: Effective ways to deal with DDoS attacks?
On Wed, 1 May 2002, Pete Kruckenberg wrote: > A rather extensive survey of DDoS papers has not resulted in > much on this topic. > > What processes and/or tools are large networks using to > identify and limit the impact of DDoS attacks? Hazaa.. something I know a little about. DDoS attacks by their very nature, are distributed. The primary purpose of more DDoS attacks is to flood the target's upstream connection to the point of saturation. As time goes by, tools are being developed (in fact they're used now) that completely randomize the TCP or UDP ports attacked, or use a variety of icmp types in the attack. So cuurrently the only way you can 'block' such attacks is to block all packets for the offending protocol as far upstream as you possibly can, but this is not ideal. If you're being attacked by a SYN flood, you can ask try to rate-limit the flood at your border (possible on Cisco IOS 12.0 and higher, and probably other routers too?) If you're being smurfed, you can block ICMP Echo Reply's inbound to the target IP. It all depends on the TYPE of attack. Having said that, it's only a matter of time before somebody releases a tool that saturates a line by spooofing the source, randomizing the protocol, and ports, and maybe even atacking other hosts on the same subnet, etc etc. The only thing you can try and do is work with your upstream provider and try to trace the source of the attacks back, but that's incredibly difficult. As a side note, does anyone know the status of the ICMP Traceback proposal? The ieft draft expired yesterday: http://www.ietf.org/internet-drafts/draft-ietf-itrace-01.txt
Re: Large ISPs doing NAT?
Roland, I have a static IP w/DirecPC and I haven't noticed any problems running ICS on Win2K. Have things changed? --Michael - Original Message - From: "Roland Dobbins" <[EMAIL PROTECTED]> To: "Peter Bierman" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; "Beckmeyer" <[EMAIL PROTECTED]> Sent: Wednesday, May 01, 2002 1:26 PM Subject: Re: Large ISPs doing NAT? > > I think a lot of the GRPS stuff is heading towards IPv6 w/IPv4 > gatewaying. > > The NAT issue has certainly resulted in a quite a few disgruntled > satellite customers (I'm thinking here primarily of direcpc.com) who're > willing to put up with the large latencies, but get really irate when > their apps won't work via NAT, or who want to run RFC1918 space for a > LAN at home, then find out that lots of stuff can't stand being NATted > twice. > > -- > > Roland Dobbins <[EMAIL PROTECTED]> // 650.776.1024 voice > > "Central databases already exist. Privacy is already gone." > > -- Larry Ellison, CEO of Oracle Corporation > > On Wed, 2002-05-01 at 16:07, Peter Bierman wrote: > > > > At 3:03 PM -0700 5/1/02, Scott Francis wrote: > > >On Wed, May 01, 2002 at 02:55:02PM -0700, [EMAIL PROTECTED] said: > > >> > > >> I don't know if this is an annual argument yet, but the frog is in the > > >> pot, and the flame is on. Guess who's playing the part of the frog? > > >> Answer: ISPs who do this sort of thing. Value added security is a nice > > >> thing. Crippling Internet connections will turn the Internet into the > > >> phone company, where only the ISP gets to say what services are good and > > >> which ones are bad. While an ISP might view it appealing to be a baby > > >> bell, remember from whence we all come: the notion that the middle should > > >> not inhibit the endpoints from doing what they want. You find this to be > > >> a support headache? Offer a deal on Norton Internet Security or some > > >> such. Offer to do rules merges. Even offer a provisioning interface to > > >> some access-lists. Just make sure that when that next really fun game is > > >> delivered on a play station that speaka de IP your customers can play it, > > >> and that you haven't built a business model around them not being able to > > >> play it. > > > > > >As long as it is _clear_ from the get-go that customers behind NAT are > > >getting that service, and not publicly-routable IP space, I don't see the > > >problem. If they don't like it, they don't have to sign up to begin with - as > > >long as there is no doubt as to what kind of service they're getting, there > > >shouldn't be a problem (legally, at any rate). > > > > > > You've got to be kidding. Do you think it's clear to the average consumer > > buying a GPRS phone what NAT is, and why they might or might not want it? > > Do you think the use of NAT will be explained to these customers? Or > > clearly stated in 5pt text on page 17 of the service agreement? > > > > IMHO, as one of the people who will likely be using Cingular's GPRS network > > with a Danger HipTop, I _strongly_ hope they choose to use routable address > > space instead of NAT. I would hate for NAT to be an impediment to some cool > > new app no one has thought of yet because these gizmos aren't in widespread > > use yet. > > > > >This is not to say that if, as Eliot posits, the next Big Thing on the market > > >requires public IPs that your customer base won't all jump ship. That's a > > >risk that providers will have to weigh against the benefits of NAT. > > > > I'm more concerned that if the major metropolitan markets deploying GPRS > > all use NAT, then the Next Big Thing won't ever happen on GPRS devices. > > Customers won't jump ship if they have no where to jump to. That might > > sound attractive to the bean counters, but think of the customers you might > > never get in the first place. Also, I don't see how deploying NAT could be > > a cost savings over requesting real IP space. > > > > -pmb > > > > -- > > Ring around the Internet, | Peter Bierman <[EMAIL PROTECTED]> > > Packet with a bit not set | http://www.sfgoth.com/pmb/ > > SYN ACK SYN ACK, |"Nobody realizes that some people expend > > We all go down. -A. Stern | tremendous energy merely to be normal."-Al Camus > > > >
Re: Large ISPs doing NAT?
Deepak Jain wrote: > MY question is -- How do you know if a justification for _public_ space > handling a large NAT'd pool is the proper size and not an over/under > allocation based on the customer in question? Why is the answer to this question any different than it has been since BCP-12? The answer is that we don't, but we guard against the problem with methods such as slow start allocations. Eliot
Re: Effective ways to deal with DDoS attacks?
http://www.secsup.org/Tracking/ UUNet uses that...others might as well, Shrug. Quick, simple, effective tracking of DDoS attacks. As for identifying attacks, quite honestly large ISP's are typically still relying on customer notification. I know that's how we do it. On Wed, 1 May 2002, Pete Kruckenberg wrote: > > There's been plenty of discussion about DDoS attacks, and my > IDS system is darn good at identifying them. But what are > effective methods for large service-provider networks (ie > ones where a firewall at the front would not be possible) to > deal with DDoS attacks? > > Current method of updating ACLs with the source and/or > destination are slow and error-prone and hard to maintain > (especially when the target of the attack is a site that > users would like to access). > > A rather extensive survey of DDoS papers has not resulted in > much on this topic. > > What processes and/or tools are large networks using to > identify and limit the impact of DDoS attacks? > > Thanks. > Pete. > > >
RE: Large ISPs doing NAT?
I'm more concerned that if the major metropolitan markets deploying GPRS all use NAT, then the Next Big Thing won't ever happen on GPRS devices. Customers won't jump ship if they have no where to jump to. That might sound attractive to the bean counters, but think of the customers you might never get in the first place. Also, I don't see how deploying NAT could be a cost savings over requesting real IP space. -pmb It certainly allows sloppy/generous/obtuse internal delegations. Some may say that saves time/management headache/whatever. MY question is -- How do you know if a justification for _public_ space handling a large NAT'd pool is the proper size and not an over/under allocation based on the customer in question? Deepak Jain AiNET
Lab/testing time
I'm putting together a justication for additional lab equipment and personnel, and would be interested what an average network engineering group spends in terms of budget and personnel on a lab and people to run it, as a percentage of overall budget. This would be primarily for main-stream issues (software testing, configuration testing), as opposed to new-vendor/bleeding-edge lab work. I'm also interested if there are significant variations between these costs with various vendors. Are the lab/testing costs significantly different if I were primarily using vendor X vs. vendor Y, and how would costs for a pure X vendor network compare to a X+Y multivendor network? Thanks. Pete.
Re: Large ISPs doing NAT?
I think a lot of the GRPS stuff is heading towards IPv6 w/IPv4 gatewaying. The NAT issue has certainly resulted in a quite a few disgruntled satellite customers (I'm thinking here primarily of direcpc.com) who're willing to put up with the large latencies, but get really irate when their apps won't work via NAT, or who want to run RFC1918 space for a LAN at home, then find out that lots of stuff can't stand being NATted twice. -- Roland Dobbins <[EMAIL PROTECTED]> // 650.776.1024 voice "Central databases already exist. Privacy is already gone." -- Larry Ellison, CEO of Oracle Corporation On Wed, 2002-05-01 at 16:07, Peter Bierman wrote: > > At 3:03 PM -0700 5/1/02, Scott Francis wrote: > >On Wed, May 01, 2002 at 02:55:02PM -0700, [EMAIL PROTECTED] said: > >> > >> I don't know if this is an annual argument yet, but the frog is in the > >> pot, and the flame is on. Guess who's playing the part of the frog? > >> Answer: ISPs who do this sort of thing. Value added security is a nice > >> thing. Crippling Internet connections will turn the Internet into the > >> phone company, where only the ISP gets to say what services are good and > >> which ones are bad. While an ISP might view it appealing to be a baby > >> bell, remember from whence we all come: the notion that the middle should > >> not inhibit the endpoints from doing what they want. You find this to be > >> a support headache? Offer a deal on Norton Internet Security or some > >> such. Offer to do rules merges. Even offer a provisioning interface to > >> some access-lists. Just make sure that when that next really fun game is > >> delivered on a play station that speaka de IP your customers can play it, > >> and that you haven't built a business model around them not being able to > >> play it. > > > >As long as it is _clear_ from the get-go that customers behind NAT are > >getting that service, and not publicly-routable IP space, I don't see the > >problem. If they don't like it, they don't have to sign up to begin with - as > >long as there is no doubt as to what kind of service they're getting, there > >shouldn't be a problem (legally, at any rate). > > > You've got to be kidding. Do you think it's clear to the average consumer > buying a GPRS phone what NAT is, and why they might or might not want it? > Do you think the use of NAT will be explained to these customers? Or > clearly stated in 5pt text on page 17 of the service agreement? > > IMHO, as one of the people who will likely be using Cingular's GPRS network > with a Danger HipTop, I _strongly_ hope they choose to use routable address > space instead of NAT. I would hate for NAT to be an impediment to some cool > new app no one has thought of yet because these gizmos aren't in widespread > use yet. > > >This is not to say that if, as Eliot posits, the next Big Thing on the market > >requires public IPs that your customer base won't all jump ship. That's a > >risk that providers will have to weigh against the benefits of NAT. > > I'm more concerned that if the major metropolitan markets deploying GPRS > all use NAT, then the Next Big Thing won't ever happen on GPRS devices. > Customers won't jump ship if they have no where to jump to. That might > sound attractive to the bean counters, but think of the customers you might > never get in the first place. Also, I don't see how deploying NAT could be > a cost savings over requesting real IP space. > > -pmb > > -- > Ring around the Internet, | Peter Bierman <[EMAIL PROTECTED]> > Packet with a bit not set | http://www.sfgoth.com/pmb/ > SYN ACK SYN ACK, |"Nobody realizes that some people expend > We all go down. -A. Stern | tremendous energy merely to be normal."-Al Camus >
Effective ways to deal with DDoS attacks?
There's been plenty of discussion about DDoS attacks, and my IDS system is darn good at identifying them. But what are effective methods for large service-provider networks (ie ones where a firewall at the front would not be possible) to deal with DDoS attacks? Current method of updating ACLs with the source and/or destination are slow and error-prone and hard to maintain (especially when the target of the attack is a site that users would like to access). A rather extensive survey of DDoS papers has not resulted in much on this topic. What processes and/or tools are large networks using to identify and limit the impact of DDoS attacks? Thanks. Pete.
Re: Large ISPs doing NAT?
At 3:03 PM -0700 5/1/02, Scott Francis wrote: >On Wed, May 01, 2002 at 02:55:02PM -0700, [EMAIL PROTECTED] said: >> >> I don't know if this is an annual argument yet, but the frog is in the >> pot, and the flame is on. Guess who's playing the part of the frog? >> Answer: ISPs who do this sort of thing. Value added security is a nice >> thing. Crippling Internet connections will turn the Internet into the >> phone company, where only the ISP gets to say what services are good and >> which ones are bad. While an ISP might view it appealing to be a baby >> bell, remember from whence we all come: the notion that the middle should >> not inhibit the endpoints from doing what they want. You find this to be >> a support headache? Offer a deal on Norton Internet Security or some >> such. Offer to do rules merges. Even offer a provisioning interface to >> some access-lists. Just make sure that when that next really fun game is >> delivered on a play station that speaka de IP your customers can play it, >> and that you haven't built a business model around them not being able to >> play it. > >As long as it is _clear_ from the get-go that customers behind NAT are >getting that service, and not publicly-routable IP space, I don't see the >problem. If they don't like it, they don't have to sign up to begin with - as >long as there is no doubt as to what kind of service they're getting, there >shouldn't be a problem (legally, at any rate). You've got to be kidding. Do you think it's clear to the average consumer buying a GPRS phone what NAT is, and why they might or might not want it? Do you think the use of NAT will be explained to these customers? Or clearly stated in 5pt text on page 17 of the service agreement? IMHO, as one of the people who will likely be using Cingular's GPRS network with a Danger HipTop, I _strongly_ hope they choose to use routable address space instead of NAT. I would hate for NAT to be an impediment to some cool new app no one has thought of yet because these gizmos aren't in widespread use yet. >This is not to say that if, as Eliot posits, the next Big Thing on the market >requires public IPs that your customer base won't all jump ship. That's a >risk that providers will have to weigh against the benefits of NAT. I'm more concerned that if the major metropolitan markets deploying GPRS all use NAT, then the Next Big Thing won't ever happen on GPRS devices. Customers won't jump ship if they have no where to jump to. That might sound attractive to the bean counters, but think of the customers you might never get in the first place. Also, I don't see how deploying NAT could be a cost savings over requesting real IP space. -pmb -- Ring around the Internet, | Peter Bierman <[EMAIL PROTECTED]> Packet with a bit not set | http://www.sfgoth.com/pmb/ SYN ACK SYN ACK, |"Nobody realizes that some people expend We all go down. -A. Stern | tremendous energy merely to be normal."-Al Camus
Re: Large ISPs doing NAT?
On Wed, 01 May 2002 14:55:02 PDT, Eliot Lear said: > some access-lists. Just make sure that when that next really fun game is > delivered on a play station that speaka de IP your customers can play it, > and that you haven't built a business model around them not being able to > play it. There was a reason I said *ALMOST*. ;) Thanks, Eliot. msg01308/pgp0.pgp Description: PGP signature
Re: Large ISPs doing NAT?
On Wed, May 01, 2002 at 02:55:02PM -0700, [EMAIL PROTECTED] said: > > I don't know if this is an annual argument yet, but the frog is in the > pot, and the flame is on. Guess who's playing the part of the frog? > Answer: ISPs who do this sort of thing. Value added security is a nice > thing. Crippling Internet connections will turn the Internet into the > phone company, where only the ISP gets to say what services are good and > which ones are bad. While an ISP might view it appealing to be a baby > bell, remember from whence we all come: the notion that the middle should > not inhibit the endpoints from doing what they want. You find this to be > a support headache? Offer a deal on Norton Internet Security or some > such. Offer to do rules merges. Even offer a provisioning interface to > some access-lists. Just make sure that when that next really fun game is > delivered on a play station that speaka de IP your customers can play it, > and that you haven't built a business model around them not being able to > play it. As long as it is _clear_ from the get-go that customers behind NAT are getting that service, and not publicly-routable IP space, I don't see the problem. If they don't like it, they don't have to sign up to begin with - as long as there is no doubt as to what kind of service they're getting, there shouldn't be a problem (legally, at any rate). This is not to say that if, as Eliot posits, the next Big Thing on the market requires public IPs that your customer base won't all jump ship. That's a risk that providers will have to weigh against the benefits of NAT. > Eliot -- Scott Francis darkuncle@ [home:] d a r k u n c l e . n e t Systems/Network Manager sfrancis@ [work:] t o n o s . c o m GPG public key 0xCB33CCA7 illum oportet crescere me autem minui msg01307/pgp0.pgp Description: PGP signature
Re: Large ISPs doing NAT?
I don't know if this is an annual argument yet, but the frog is in the pot, and the flame is on. Guess who's playing the part of the frog? Answer: ISPs who do this sort of thing. Value added security is a nice thing. Crippling Internet connections will turn the Internet into the phone company, where only the ISP gets to say what services are good and which ones are bad. While an ISP might view it appealing to be a baby bell, remember from whence we all come: the notion that the middle should not inhibit the endpoints from doing what they want. You find this to be a support headache? Offer a deal on Norton Internet Security or some such. Offer to do rules merges. Even offer a provisioning interface to some access-lists. Just make sure that when that next really fun game is delivered on a play station that speaka de IP your customers can play it, and that you haven't built a business model around them not being able to play it. Eliot mike harrison wrote: >>On Monday, 2002-04-29 at 08:43 MST, Beckmeyer <[EMAIL PROTECTED]> wrote: >> >>>Is anybody here doing NAT for their customers? >> > > Tony Rall: > >>If you're NATing your customers you're no longer an ISP. You're a >>sort-of-tcp-service-provider (maybe a little udp too). NAT (PAT even more > > > Depends on scale and application. We have lots of customers > that we NAT, one way or another. And a lot more that we don't. > Some customers WANT to 'just see out' and they like all the 'weird stuff > turned off'. Sometimes it's a box at the customers end, sometimes > it's nat'd IP's on the dial-up/ISDN/FracT1/T1/Wireless connection itself. > > Saying we are not an ISP because we do some NAT is a little harsh. > Giving the customer options and making things work (when done right, > and explained properly we have no sales droids) is good business > and I think good for the 'net. It gives the clueless (and sometimes > cluefull) just a little more isolation. > > What is wrong is NAT'ing when you should not. > > > >
RE: Large ISPs doing NAT?
On Wed, 1 May 2002, Deepak Jain wrote: > Almost? I'd say it's hands down an EXCELLENT reason. In some configs > though, the NAT'd people can still see each other and cause problems, > but it still cuts down the exposure. I've received a couple off-list replies about containment within the NAT'ed area, but I don't see this being a significant issue, as in order to make this at all scalable, it would need to be done at a relatively granular level, ie. directly at customer aggregation router, which would limit scope a fair deal. Support-staff debugging may also end up simpler, if for no other reason that it forces them to go to the edge router to reach the customer directly, eliminating ill-concieved 'shortcuts'. The benefits to core engineering teams would be interesting as well, given that public space becomes genuinely dynamic, even at the edge. ...and as has been mentioned, nothing precludes offering non-NAT as a premium service, just as the DSL providers have done already w/ offering /29's or static addresses. ..kg..
RE: Large ISPs doing NAT?
Almost? I'd say it's hands down an EXCELLENT reason. In some configs though, the NAT'd people can still see each other and cause problems, but it still cuts down the exposure. Presumably, the people it would cause problems for would be the customers of someone getting paid to care about them. :) Deepak Jain AiNET
Re: news-peering
On Wed, 1 May 2002, Lyndon Nerenberg wrote: > > > } I'm trolling for newspeers, if there is anyone out there still using > > } NNTP.. > > > > http://www.usenet-se.net/peering/ > > A useless list based on my experience (zero responses to requests > to twelve different sites). Some of the information on there is most likely stale. Several sites we used to peer with when we ran a news server have been borged into other companies or are no longer serving news, but are still on the list. jms
Download estimate tool?
I'm looking for a tool to estimate file download times given a certain set of variables: file size, available bandwidth, latency, receive window and circuit utilization. To explain: Suppose I have a single OC3 serving FTP downloads to individuals all over the globe. If the OC3 is not heavily utilized *and* I know the bandwidth and latency between my FTP server and a client's workstation, I can make a rough estimate of how long it will take for a file of a particular size to download. I could create a matrix in Excel based on latencies and bandwidths (factoring in TCP receive window sizes) and that would give me a quick reference tool for gauging how long something should take to download given a fair number of scenarios. But what if I want to enhance such a matrix to factor in what happens to download times in those various scenarios as the utilization of that OC3 approaches 100%? I could make alot of edits to above mentioned Excel matrixbut that would get tricky and visually unappealing. Can anyone recommend a tool that makes it easy to play with the above variables...a sort of modeling tool not quite so fancy or expensive as Opnet for example? Maybe a webpage with a Java applet ? Or maybe a fancy Excel file? Thanks, BM
Re: news-peering
supernews.com is my news provider and they are pretty good. Todd - Original Message - From: "Lyndon Nerenberg" <[EMAIL PROTECTED]> To: "Katsuhiro Kondou" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, May 01, 2002 9:53 AM Subject: Re: news-peering > > > } I'm trolling for newspeers, if there is anyone out there still using > > } NNTP.. > > > > http://www.usenet-se.net/peering/ > > A useless list based on my experience (zero responses to requests > to twelve different sites). > > --lyndon >
Re: BGP route explosion
Has it been established yet where the extra prefixes came from? -C On Wed, May 01, 2002 at 03:31:26PM -0400, Andrew Herdman wrote: > > We saw at least an extra 10k prefixes, the router is/was configured to stop at 120k >prefixes, little did I know that it would shutdown the BGP session at that point. > > Thanks for the info. > > Andrew > > On Wed, May 01, 2002 at 08:50:55AM -0400, Toan Do wrote: > > How many extra prefixes did u see? We saw about 10k prefixes more than > > normal > > > > Toan > > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of > > [EMAIL PROTECTED] > > Sent: Wednesday, May 01, 2002 8:42 AM > > To: [EMAIL PROTECTED] > > Subject: BGP route explosion > > > > > > > > I had a network outage this morning brought about by a BGP route > > explosion at around 6:30 EST(-4) this morning. Anyone else notice it, > > and who the culprit whats? I got the exact same hit from both my > > providers, AT&T Can, and Telus. > > > > Thanks > > Andrew > > msg01300/pgp0.pgp Description: PGP signature
Re: BGP route explosion
We saw at least an extra 10k prefixes, the router is/was configured to stop at 120k prefixes, little did I know that it would shutdown the BGP session at that point. Thanks for the info. Andrew On Wed, May 01, 2002 at 08:50:55AM -0400, Toan Do wrote: > How many extra prefixes did u see? We saw about 10k prefixes more than > normal > > Toan > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of > [EMAIL PROTECTED] > Sent: Wednesday, May 01, 2002 8:42 AM > To: [EMAIL PROTECTED] > Subject: BGP route explosion > > > > I had a network outage this morning brought about by a BGP route > explosion at around 6:30 EST(-4) this morning. Anyone else notice it, > and who the culprit whats? I got the exact same hit from both my > providers, AT&T Can, and Telus. > > Thanks > Andrew >
Re: Verizon fiber cut in Midtown Manhattan
RS> Date: Wed, 1 May 2002 11:34:21 -0400 RS> From: Rishi Singh [ somewhat snipped ] RS> Verizon spokesman Cliff Lee says a construction crew working RS> on 58th Street between Lexington and Third avenues yesterday RS> cut into a cable underground, causing the disruption. Sounds like a backhoe got jealous of all the recent trains. ;-) -- Eddy Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <[EMAIL PROTECTED]>, or you are likely to be blocked.
Re: news-peering
> } I'm trolling for newspeers, if there is anyone out there still using > } NNTP.. > > http://www.usenet-se.net/peering/ A useless list based on my experience (zero responses to requests to twelve different sites). --lyndon
Re: BGP route explosion
I got this better link from John Elliott: http://www.telstra.net/ops/bgp/bgp-parse.c - Original Message - From: "William F. Maton" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, May 01, 2002 6:09 AM Subject: Re: BGP route explosion > > On Wed, 1 May 2002, Marshall Eubanks wrote: > > [EMAIL PROTECTED] (Andrew Herdman) wrote: > > > > > > I had a network outage this morning brought about by a > > > BGP route explosion at around 6:30 EST(-4) this morning. > > > Anyone else notice it, and who the culprit whats? I got > > > the exact same hit from both my providers, AT&T Can, and > > > Telus. > > > > I did not see this on Sprint, UUNet or vBNS. > > AS818 saw the spike, courtesy Geoff Houston's Table Data Program: > > http://ryouko.dgim.crc.ca/bgp/bgp-all.html > > wfms > >
Verizon fiber cut in Midtown Manhattan
http://1010wins.com/topstories/StoryFolder/story_1199630592_html WINS) May 1, 2002 6:49 am US/Eastern (New York-AP) -- Telephone service in a section of midtown Manhattan has been disrupted by a construction accident. Verizon spokesman Cliff Lee says a construction crew working on 58th Street between Lexington and Third avenues yesterday cut into a cable underground, causing the disruption. It's unclear how many customers have experienced problems. Police say thousands of people have been affected. Lee says Verizon has received about 400 calls from customers having difficulty. Repair crews are working at the scene. The affected area is between Third and Fifth avenues from 57th to 65th streets. (Copyright 2002 by The Associated Press. All Rights Reserved.)
Re: BGP route explosion
actually, it looks more like the sources have been sorted alphabetically by line or something weird.. likewise, anyone have the src for this handy and willing to share? Thanks Steve On Wed, 1 May 2002, matthew zeier wrote: > > > > > AS818 saw the spike, courtesy Geoff Houston's Table Data Program: > > > > http://ryouko.dgim.crc.ca/bgp/bgp-all.html > > Neat tool - I tried to grab the src but the first 1000 or so lines are blank > and uncompilable. Anyone have a good version of the src? > >
Re: BGP route explosion
> > AS818 saw the spike, courtesy Geoff Houston's Table Data Program: > > http://ryouko.dgim.crc.ca/bgp/bgp-all.html Neat tool - I tried to grab the src but the first 1000 or so lines are blank and uncompilable. Anyone have a good version of the src?
Re: Large ISPs doing NAT?
> > of unadministered, always-on boxes that aren't supposed to be running > > inbound services in unrouted space would save all of us headaches. > > That's almost a better justification for NAT than address-space conservation. ;) Almost? I'd say it's hands down an EXCELLENT reason. In some configs though, the NAT'd people can still see each other and cause problems, but it still cuts down the exposure.
Re: Large ISPs doing NAT?
On Tue, 30 Apr 2002 12:13:11 PDT, kevin graham said: > Given the bellowing over some of the allocations in 24/8 that have been > heard here before, it would seem to be welcome. Sticking large numbers > of unadministered, always-on boxes that aren't supposed to be running > inbound services in unrouted space would save all of us headaches. That's almost a better justification for NAT than address-space conservation. ;) msg01291/pgp0.pgp Description: PGP signature
Re: BGP route explosion
On Wed, 1 May 2002, Marshall Eubanks wrote: > [EMAIL PROTECTED] (Andrew Herdman) wrote: > > > > I had a network outage this morning brought about by a > > BGP route explosion at around 6:30 EST(-4) this morning. > > Anyone else notice it, and who the culprit whats? I got > > the exact same hit from both my providers, AT&T Can, and > > Telus. > > I did not see this on Sprint, UUNet or vBNS. AS818 saw the spike, courtesy Geoff Houston's Table Data Program: http://ryouko.dgim.crc.ca/bgp/bgp-all.html wfms
Re: BGP route explosion
On Wed, 1 May 2002 08:42:02 -0400 [EMAIL PROTECTED] (Andrew Herdman) wrote: > > I had a network outage this morning brought about by a > BGP route explosion at around 6:30 EST(-4) this morning. > Anyone else notice it, and who the culprit whats? I got > the exact same hit from both my providers, AT&T Can, and > Telus. > > Thanks > Andrew > I did not see this on Sprint, UUNet or vBNS. Regards Marshall Eubanks
Re: BGP route explosion
> > I had a network outage this morning brought about by a BGP route explosion at around >6:30 EST(-4) this morning. Anyone else notice it, and who the culprit whats? I got >the exact same hit from both my providers, AT&T Can, and Telus. Yeah its been reported a few places - we saw about 130K routes. -- Neil J. McRae - Alive and Kicking [EMAIL PROTECTED]
RE: BGP route explosion
How many extra prefixes did u see? We saw about 10k prefixes more than normal Toan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, May 01, 2002 8:42 AM To: [EMAIL PROTECTED] Subject: BGP route explosion I had a network outage this morning brought about by a BGP route explosion at around 6:30 EST(-4) this morning. Anyone else notice it, and who the culprit whats? I got the exact same hit from both my providers, AT&T Can, and Telus. Thanks Andrew
BGP route explosion
I had a network outage this morning brought about by a BGP route explosion at around 6:30 EST(-4) this morning. Anyone else notice it, and who the culprit whats? I got the exact same hit from both my providers, AT&T Can, and Telus. Thanks Andrew
