Re: DDos syn attack
> wow, break bind in a new and horrid way to accomplish this task :) Nice... > perhaps mr. vixie will add this functionality for us? patches welcomed. -- Paul Vixie
Re: AOL & Cogent
On Mon, 30 Dec 2002, Leo Bicknell wrote: > In a message written on Sun, Dec 29, 2002 at 10:32:25PM +, Paul Vixie wrote: > > there we go again, talking technology and making the technological kind > > of sense. peering isn't a technology decision, it's a business decision. > > This depends on how you define business decision. I view a business > decision as one where a company selling a product gets to make > choices about that product - but, and this is a big part - remains > in business. Having the product work in the first place is a > business requirement. I don't buy into the logic that making a > (known) broken product is a business decision, as no one makes a > business decision with a known, up-front outcome of failure. Which is my thought exactly. Surely a business decision around a technological product must make technological sense before it can make business sense else as you say what you sell is a broken product. Technology says you should make sure you have good connectivity on the major arteries of your network .. if that doesnt make business sense then you're business model is wrong! Looking for sales is fine but if it goes against the founding technological and business model then its not going to happen! Steve > > A business decision is something like choosing to put cheap plastic > trim in a car and sell it cheap, or the best Italian leather and > sell it for a lot of money. Building a car that doesn't break down > every 10 miles and needs to be towed back to the garage isn't a > business decision, it's a requirement to be in the car business at > all. > > Similarly to peering, a base amount is required to make this crazy > thing we all run work. As we've seen with companies like PSI, > those who terminate, or loose significant peering generally end up > dead. So there are really two things to talk about. From a > technological point of view what's the minimum amount of peering > necessary to make things work, and then from a business perspective > what further optimizations can be made to make your customers more > happy, or reduce your costs, or both. > > Trying to make it all a business decision is as wrong as trying to > make it all about technology. Looking at only one side gives you > have the picture. > > In a message written on Sun, Dec 29, 2002 at 09:12:16PM +, Paul Vixie wrote: > > ...at least you know they are paying SOMEBODY, thus supporting the market > > you want to be in. you can then compete in that market. if everybody who > > could peer in N places worldwide could just get peering, then all kinds of > > per-bit revenue for "high tier" network owners would turn into per-port > > revenue for exchange point operators. where's the market in that? how > > could a "high tier" even exist in those conditions? > > Argument #1, don't peer with the little guy because it takes revenue > away from ISP's in general. > > In a message written on Sun, Dec 29, 2002 at 10:32:25PM +, Paul Vixie wrote: > > as a local operator myself (ISC), i know that i should not expect peering > > other than if someone wants their customers to have better access to the > > f-root server or the kernel.org ftp server or whatever. it's actually > > easier for me, as a nonprofit, to attract what mr. bill calls 'content > > peering' relationships, since i don't compete with the folks i peer with. > > Argument #2, it's easy for me, a little guy to get peering because > I don't compete with the ISP's, I just buy from them. > > So which is it? Do you peer with the little guys who don't run > networks because content peering is good, or do you not peer with > them because it forces them to buy from somebody, and if everyone > does that it's good for ISP's in general? It seems to me you want > to have your cake and eat it too. > >
Re: AOL & Cogent
On 30 Dec 2002, Jeff S Wheeler wrote: > > On Mon, 2002-12-30 at 06:37, Basil Kruglov wrote: > > For my not-so-bright customers I simply want traceroutes to look good when > > they run one from Level3-homed site. Obviously a ~5-7 hops to us looks > > really disturbing, try to explain to one of them that there is no problem. > After some off-list discussion I think I understand the issue. You do > not want customers who are doing a traceroute from Level3 or one of > their downstreams to see high latency on some of their traceroute hops > going toward you, because you cannot control the egress path of those > ttl_exceeded packets from cogent's network, even though you can control > your own egress. > > So the obvious solution is to prepend your advertisements toward cogent, > which will cause them to carry less of your inbound traffic. This has a > negative impact for cogent, because they need that inbound traffic to > justify some of their peering agreements (think, ratios). Supposedly > this is the reason they couldn't keep the ATDN peering, eh? If all > their web host-type customers suddenly start prepending advertisements, > it will cause them to bleed inbound traffic. This doesnt work well for two reasons. One is that as path is fairly low down on the path selection and easily overridden by other factors eg localpref The other is that if the network is providing transit then you want to avoid prepending as you will most likely reduce your transit revenue. Steve > > If you want to encourage cogent to build a rich community set so you can > prepend only toward Level3, perhaps you should start prepending toward > cogent and make the point with your cogent rep that this is going to > cause them to lose your inbound traffic, and if they gave you more > control over route advertisements, it would not have such an impact. > > On the other hand, maybe cogent doesn't want web hosts as customers. :-) > > -- > Jeff S Wheeler <[EMAIL PROTECTED]> > > >
Re: DDos syn attack
On Mon, 30 Dec 2002, Chris Wedgwood wrote: > > On Mon, Dec 30, 2002 at 08:09:17AM -0800, Randy Bush wrote: > > > actually, a bunch of research now shows that low ttls on A RRs (that > > are not the A RRs of NS RRs) has little effect. > > maybe this could help find the attacking nwtwork? assuming people are > using local DNS servers? > > under attack you could sporadically 'lie' about the result... and log > to whom you lied to... all the time looking for changes in the DDoS > target > > a fair amount work perhaps... wow, break bind in a new and horrid way to accomplish this task :) Nice... perhaps mr. vixie will add this functionality for us?
Re: AOL & Cogent
JSW> Date: 30 Dec 2002 13:59:40 -0500 JSW> From: Jeff S Wheeler JSW> So the obvious solution is to prepend your advertisements JSW> toward cogent, which will cause them to carry less of your JSW> inbound traffic. ...although the exact effects depend on your particular mix of upstreams. LOCAL_PREF trumps AS_PATH... I severely de-pref long paths, thus [hopefully] giving those who prepend their desired result. A side benefit is this often catches long-pathed improper redistributions. I know I'm not alone in this. And one usually can adjust LOCAL_PREF via community advertised to an upstream. IOW: YMMV (YMWV if using no more than prepends) Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~ 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: AOL & Cogent
On Mon, 2002-12-30 at 06:37, Basil Kruglov wrote: > For my not-so-bright customers I simply want traceroutes to look good when > they run one from Level3-homed site. Obviously a ~5-7 hops to us looks > really disturbing, try to explain to one of them that there is no problem. After some off-list discussion I think I understand the issue. You do not want customers who are doing a traceroute from Level3 or one of their downstreams to see high latency on some of their traceroute hops going toward you, because you cannot control the egress path of those ttl_exceeded packets from cogent's network, even though you can control your own egress. So the obvious solution is to prepend your advertisements toward cogent, which will cause them to carry less of your inbound traffic. This has a negative impact for cogent, because they need that inbound traffic to justify some of their peering agreements (think, ratios). Supposedly this is the reason they couldn't keep the ATDN peering, eh? If all their web host-type customers suddenly start prepending advertisements, it will cause them to bleed inbound traffic. If you want to encourage cogent to build a rich community set so you can prepend only toward Level3, perhaps you should start prepending toward cogent and make the point with your cogent rep that this is going to cause them to lose your inbound traffic, and if they gave you more control over route advertisements, it would not have such an impact. On the other hand, maybe cogent doesn't want web hosts as customers. :-) -- Jeff S Wheeler <[EMAIL PROTECTED]>
Re: DDos syn attack
On Mon, 30 Dec 2002, Christopher L. Morrow wrote: > wouldn't dns lookups be a bit time consuming and introduce a dos on the > dos ?? if you had to look up each time you crafted a packet it'd take alot > more effort to pound out 100kpps, no? Most of the flooders I've seen (I'm > no programmer so I may be wrong on this) actually do a lookup to ip for > the dest and just start making packets, never rechecking the name->ip > mapping once its done the first time. I remember a long time ago I wrote an app to reverse IP's and there definately is a delay looking up addresses. And you're right it would kill performance of the attack if they looked up the addresses each time, so they do cache the entries. But lucky for us none of the coders have thought to do lookups at regular intervals or better yet that with threading they can use one thread for the attack and one thread to monitor the DNS entry. Andrew --- <[EMAIL PROTECTED]> http://www.andrewsworld.net/ ICQ: 2895251 Cisco Certified Network Associate "Learn from the mistakes of others. You won't live long enough to make all of them yourself."
Re: DDos syn attack
On Mon, 30 Dec 2002, Randy Bush wrote: > > This is also a very viable solution, provided the customer has > > provisioned for this with lower ttls on their DNS records, which > > ALOT of people (thankfully) don't do > > actually, a bunch of research now shows that low ttls on A RRs > (that are not the A RRs of NS RRs) has little effect. > > in the case a dns lookup is being done in a ddos, of course one > would prefer if the attacking zombies cached the lookup . wouldn't dns lookups be a bit time consuming and introduce a dos on the dos ?? if you had to look up each time you crafted a packet it'd take alot more effort to pound out 100kpps, no? Most of the flooders I've seen (I'm no programmer so I may be wrong on this) actually do a lookup to ip for the dest and just start making packets, never rechecking the name->ip mapping once its done the first time. On the other hand, writing something for 100,000 codered clients to use is another story, if you have 100,000 hosts you can afford a dns lookup :) though most of them just do: ping -t www.psg.com 65000 or some msdos flavor of this... (I don't actually know the right flags for dos's ping program :( ) > > randy >
Re: AOL & Cogent
> Is it just me or does all this make Internap's Business model look > really good? i think it's just you.
Re: AOL & Cogent
> Similarly to peering, a base amount is required to make this crazy > thing we all run work. As we've seen with companies like PSI, those > who terminate, or loose significant peering generally end up dead. no part of worldcom's failure traces to uunet's decision to restrict their peering back in 1993/1994. in fact, that decision was has been spectacularly successful from a business standpoint. unfortunately, one example does not a trend make. also unfortunately, one example can be terrifically inspiring to others. so while i accept your use of the word "generally", i have to say it doesn't look that way to the business people who have quarterly numbers to make and are willing looking at their fellow network operators as possible meat. oh and while i considered PSI's vision faulty, i do not believe that their peering games had anything to do with their failure. (nor do i believe that winning those games would have saved them.) now, let's resolve a point of confusion: > > ...at least you know they are paying SOMEBODY, thus supporting the > > market you want to be in. you can then compete in that market. if > > everybody who could peer in N places worldwide could just get > > peering, then all kinds of per-bit revenue for "high tier" network > > owners would turn into per-port revenue for exchange point > > operators. where's the market in that? how could a "high tier" > > even exist in those conditions? > > Argument #1, don't peer with the little guy because it takes revenue > away from ISP's in general. > > > as a local operator myself (ISC), i know that i should not expect > > peering other than if someone wants their customers to have better > > access to the f-root server or the kernel.org ftp server or > > whatever. it's actually easier for me, as a nonprofit, to attract > > what mr. bill calls 'content peering' relationships, since i don't > > compete with the folks i peer with. > > Argument #2, it's easy for me, a little guy to get peering because > I don't compete with the ISP's, I just buy from them. > > So which is it? Do you peer with the little guys who don't run > networks because content peering is good, or do you not peer with > them because it forces them to buy from somebody, and if everyone > does that it's good for ISP's in general? as a business decision, peering with someone like ISC is a no-op. it neither costs nor makes any money, doesn't shift cost or revenue toward anybody, etc. the two reasons for this are (a) the potential peer is not going to be selling transit (therefore there's no revenue stream to want a cut of) and (b) the potential peer isn't making any porno or other revenue, and so is an unlikely transit customer for its own traffic. > It seems to me you want to have your cake and eat it too. actually i'm trying to explain rather than defend. my arm is still cramped from signing 500 peering agreements at a time back at AS6461, and when i next run an international IP backbone i hope to sign 10X as many. peering is good for business, but only if one has no natural monopoly or first mover advantage (like uunet had) that makes alternatives viable, and only if one's vision extends beyond the next quarterly SEC filing.
Re: DDos syn attack
> This is also a very viable solution, provided the customer has > provisioned for this with lower ttls on their DNS records, which > ALOT of people (thankfully) don't do actually, a bunch of research now shows that low ttls on A RRs (that are not the A RRs of NS RRs) has little effect. in the case a dns lookup is being done in a ddos, of course one would prefer if the attacking zombies cached the lookup . randy
Re: DC power versus AC power
Thus spake Robert E. Seastrom <[EMAIL PROTECTED]>: > "Stephen Sprunk" <[EMAIL PROTECTED]> writes: > >> Thus spake joe mcguckin <[EMAIL PROTECTED]>: >>> It only takes 30ma to put your heart into atrial fibrillation. In >>> the usa, gfi's are set to trip at 5ma. >> >> Did you mean 5A, or am I misunderstanding GFIs? > > it's 5ma. http://www.national.com/ds/LM/LM1851.pdf Perfect, thanks. I learn so many interesting things on NANOG, it almost makes up for the noise :) S
Re: AOL & Cogent
Thus spake David Diaz <[EMAIL PROTECTED]>: > Is it just me or does all this make Internap's Business model look > really good? http://finance.yahoo.com/q?s=INAP&d=t "EPS (ttm) -1.23" -- triple their current share price -- doesn't make their business model look so hot. S
Re: DC power versus AC power
I deny saying: > But they are there for reason. They are typ. full of power to powDer -- A host is a host from coast to [EMAIL PROTECTED] & no one will talk to a host that's close[v].(301) 56-LINUX Unless the host (that isn't close).pob 1433 is busy, hung or dead20915-1433
Re: DC power versus AC power
"Stephen Sprunk" <[EMAIL PROTECTED]> writes: > Thus spake joe mcguckin <[EMAIL PROTECTED]>: > > It only takes 30ma to put your heart into atrial fibrillation. In the > > usa, gfi's are set to trip at 5ma. > > Did you mean 5A, or am I misunderstanding GFIs? it's 5ma. http://www.national.com/ds/LM/LM1851.pdf ---rob
Re: DC power versus AC power
In message <004f01c2b018$4ac14900$[EMAIL PROTECTED]>, "Stephen Sprunk" wr ites: > >Thus spake joe mcguckin <[EMAIL PROTECTED]>: >> It only takes 30ma to put your heart into atrial fibrillation. In the >> usa, gfi's are set to trip at 5ma. > >Did you mean 5A, or am I misunderstanding GFIs? > No -- 5 ma is correct. (GFIs measure the difference in current between the hot and neutral leads -- if it exceeds 5 ma, it trips.) --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book)
Re: DC power versus AC power
Unnamed Administration sources reported that Stephen Sprunk said: > > > > It only takes 30ma to put your heart into atrial fibrillation. In the > > usa, gfi's are set to trip at 5ma. > > Did you mean 5A, or am I misunderstanding GFIs? 5ma is correct. It takes very little current to cause fibrillation. GFI's compare the current going out the hot lead of a receptacle with that coming back the neutral. If there is more out than back, it makes the assumption the rest is going through Jill Winecooler/ Joe Sixpack to ground, and trips. -- A host is a host from coast to [EMAIL PROTECTED] & no one will talk to a host that's close[v].(301) 56-LINUX Unless the host (that isn't close).pob 1433 is busy, hung or dead20915-1433
Re: AOL & Cogent
Is it just me or does all this make Internap's Business model look really good? At 9:50 -0500 12/30/02, Leo Bicknell wrote: In a message written on Sun, Dec 29, 2002 at 10:32:25PM +, Paul Vixie wrote: there we go again, talking technology and making the technological kind of sense. peering isn't a technology decision, it's a business decision. This depends on how you define business decision. I view a business decision as one where a company selling a product gets to make choices about that product - but, and this is a big part - remains in business. Having the product work in the first place is a business requirement. I don't buy into the logic that making a (known) broken product is a business decision, as no one makes a business decision with a known, up-front outcome of failure. A business decision is something like choosing to put cheap plastic trim in a car and sell it cheap, or the best Italian leather and sell it for a lot of money. Building a car that doesn't break down every 10 miles and needs to be towed back to the garage isn't a business decision, it's a requirement to be in the car business at all. Similarly to peering, a base amount is required to make this crazy thing we all run work. As we've seen with companies like PSI, those who terminate, or loose significant peering generally end up dead. So there are really two things to talk about. From a technological point of view what's the minimum amount of peering necessary to make things work, and then from a business perspective what further optimizations can be made to make your customers more happy, or reduce your costs, or both. Trying to make it all a business decision is as wrong as trying to make it all about technology. Looking at only one side gives you have the picture. In a message written on Sun, Dec 29, 2002 at 09:12:16PM +, Paul Vixie wrote: ...at least you know they are paying SOMEBODY, thus supporting the market you want to be in. you can then compete in that market. if everybody who could peer in N places worldwide could just get peering, then all kinds of per-bit revenue for "high tier" network owners would turn into per-port revenue for exchange point operators. where's the market in that? how could a "high tier" even exist in those conditions? Argument #1, don't peer with the little guy because it takes revenue away from ISP's in general. In a message written on Sun, Dec 29, 2002 at 10:32:25PM +, Paul Vixie wrote: as a local operator myself (ISC), i know that i should not expect peering other than if someone wants their customers to have better access to the f-root server or the kernel.org ftp server or whatever. it's actually easier for me, as a nonprofit, to attract what mr. bill calls 'content peering' relationships, since i don't compete with the folks i peer with. Argument #2, it's easy for me, a little guy to get peering because I don't compete with the ISP's, I just buy from them. So which is it? Do you peer with the little guys who don't run networks because content peering is good, or do you not peer with them because it forces them to buy from somebody, and if everyone does that it's good for ISP's in general? It seems to me you want to have your cake and eat it too. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org Content-Type: application/pgp-signature Content-Disposition: inline Attachment converted: Superbook HD:Untitled 337 (/) (000F0AD7) -- David Diaz [EMAIL PROTECTED] [Email] [EMAIL PROTECTED] [Pager] www.smoton.net [Peering Site under development] Smotons (Smart Photons) trump dumb photons
Re: DC power versus AC power
Unnamed Administration sources reported that Robert E. Seastrom said:
>
> Bottom line is that one should buy breakers and fuses that are
> designed for use in DC powerplants, rather than trying to cheap out
> with something you picked up at Home Depot or Pep Boys. I'm sure I'm
> wasting my breath since _nobody_ who reads NANOG would ever try to cut
> corners to save a few bucks... :)
Gawd yes.
We all know those little 3AG glass fuses, right? They also come
in ceramic. A regular PITA -- you can not look and see they are
blown.
But they are there for reason. They are typ. full of power to
quench the resulting arc. A glass 3AG can and will open, yet the
arc just keeps goingslagging the fuseholder, and whatever was
errr... protected.
There is as much diversity and engineering in fusing as router
design. Voltage to be broken, AC vs DC, time curve to open, other
factors all enter into it. I see two fuses in series on "pole pigs"
primaries around here. Finally had a chance to ask the foreman.
One is {say} 10A and that is sized for overloads. The second is
15A, but its sole function is to open FAST if the primary takes a
lightning hit and the spark-gap on the transformer conducts. Seems
they can't get both qualities right in one fuse so they use two.
And RES is correct; DC circuit breakers are different animals than
AC by a long shot. Fuses have different ratings as well. RTFM.
Please be careful; while you might [now] be easily replaced, the
suffering VC's will not appreciate losing all to a dropped tool.
ps: I've not even mentioned the acid and H2 gas [kaaBOOM] issues...
--
A host is a host from coast to [EMAIL PROTECTED]
& no one will talk to a host that's close[v].(301) 56-LINUX
Unless the host (that isn't close).pob 1433
is busy, hung or dead20915-1433
Re: DDos syn attack
On 30 Dec 2002, Mike Hyde wrote: > > Just wondering how people have delt with DDOS syn attacks on port 80 of > a customers server? We had an attack a couple of days ago, and it 1) acl the traffic (Stop immediate pain) 2) blackhole ip in question 3) track via: http://www.secsup.org/Tracking/ to ingress points on your network 4) acl traffic inbound there 5) remove blackhole and acl toward customer Finish in ~10 mins... customer is back online and happy. > overwelmed both the customers firewall and, when we tried to turn up > filtering on a 7600 cisco router, the router also. We ended up having > the customer change his IP for the site under attack. We were lucky in > that the attack was against an IP and not the DNS name. > -- This is also a very viable solution, provided the customer has provisioned for this with lower ttls on their DNS records, which ALOT of people (thankfully) don't do... also, sometimes customers don't know how to do this, eh? :(
Re: DC power versus AC power
Thus spake joe mcguckin <[EMAIL PROTECTED]>: > It only takes 30ma to put your heart into atrial fibrillation. In the > usa, gfi's are set to trip at 5ma. Did you mean 5A, or am I misunderstanding GFIs? > Normally 48VDC wouldn't be considered a 'lethal' voltage (I've talked > to telephone technicians who said they used to play a game in the CO > by wiring a handle to 90V ring voltage and seeing who could grab it > for the longest time), That explains so many things... S
Re: Public thanks to UUNet security
Mark, I'm sure that Damon will be happy to see this, I know I sure am. Thanks for the note. --Chris ([EMAIL PROTECTED]) ### ## UUNET Technologies, Inc. ## ## Manager ## ## Customer Router Security Engineering Team ## ## (W)703-886-3823 (C)703-338-7319 ## ### On Mon, 30 Dec 2002, Mark Radabaugh wrote: > > Since the good things so rarely get mentioned... > > I would like to publicly thank UUNet's network operations for dealing with a > DOS attack quickly and efficiently yesterday. I am happy to say it only > required one phone call of less than 15 minutes to get the appropriate > filtering in place. > > Mark Radabaugh > Amplex > (419) 720-3635 > >
Re: AOL & Cogent
In a message written on Sun, Dec 29, 2002 at 10:32:25PM +, Paul Vixie wrote: > there we go again, talking technology and making the technological kind > of sense. peering isn't a technology decision, it's a business decision. This depends on how you define business decision. I view a business decision as one where a company selling a product gets to make choices about that product - but, and this is a big part - remains in business. Having the product work in the first place is a business requirement. I don't buy into the logic that making a (known) broken product is a business decision, as no one makes a business decision with a known, up-front outcome of failure. A business decision is something like choosing to put cheap plastic trim in a car and sell it cheap, or the best Italian leather and sell it for a lot of money. Building a car that doesn't break down every 10 miles and needs to be towed back to the garage isn't a business decision, it's a requirement to be in the car business at all. Similarly to peering, a base amount is required to make this crazy thing we all run work. As we've seen with companies like PSI, those who terminate, or loose significant peering generally end up dead. So there are really two things to talk about. From a technological point of view what's the minimum amount of peering necessary to make things work, and then from a business perspective what further optimizations can be made to make your customers more happy, or reduce your costs, or both. Trying to make it all a business decision is as wrong as trying to make it all about technology. Looking at only one side gives you have the picture. In a message written on Sun, Dec 29, 2002 at 09:12:16PM +, Paul Vixie wrote: > ...at least you know they are paying SOMEBODY, thus supporting the market > you want to be in. you can then compete in that market. if everybody who > could peer in N places worldwide could just get peering, then all kinds of > per-bit revenue for "high tier" network owners would turn into per-port > revenue for exchange point operators. where's the market in that? how > could a "high tier" even exist in those conditions? Argument #1, don't peer with the little guy because it takes revenue away from ISP's in general. In a message written on Sun, Dec 29, 2002 at 10:32:25PM +, Paul Vixie wrote: > as a local operator myself (ISC), i know that i should not expect peering > other than if someone wants their customers to have better access to the > f-root server or the kernel.org ftp server or whatever. it's actually > easier for me, as a nonprofit, to attract what mr. bill calls 'content > peering' relationships, since i don't compete with the folks i peer with. Argument #2, it's easy for me, a little guy to get peering because I don't compete with the ISP's, I just buy from them. So which is it? Do you peer with the little guys who don't run networks because content peering is good, or do you not peer with them because it forces them to buy from somebody, and if everyone does that it's good for ISP's in general? It seems to me you want to have your cake and eat it too. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org msg07667/pgp0.pgp Description: PGP signature
DDos syn attack
Just wondering how people have delt with DDOS syn attacks on port 80 of a customers server? We had an attack a couple of days ago, and it overwelmed both the customers firewall and, when we tried to turn up filtering on a 7600 cisco router, the router also. We ended up having the customer change his IP for the site under attack. We were lucky in that the attack was against an IP and not the DNS name. -- Mike Hyde <[EMAIL PROTECTED]>
Re: AOL & Cogent
On Mon, Dec 30, 2002 at 08:14:45AM -0500, Omachonu Ogali wrote: > > For my not-so-bright customers I simply want traceroutes to look good when > > they run one from Level3-homed site. Obviously a ~5-7 hops to us looks > > really disturbing, try to explain to one of them that there is no problem. > > Then make a press release for your not so bright customers, and explain > every single detail rather than asking a company to change their entire > routing policy because you're too lazy to educate your customers on how > traceroute shouldn't be used as a tool to gauge performance. And if you > can't explain it to them, then you should step back and look at who you > really have for customers. "Enough said." Great. Thanks for the PR tip. I never intended them to change "their entire routing policy" just for my laziness, if you insist ;) It's been going on for 2 and 1/2+ weeks with no definitive date/solution/workaround on when it's going to be fixed. Now I've made an attempt trying to show what could be done; perhaps move some butts to actually get something done. Speaking of my customers or perspective customers, I don't get to choose often who they are. Maybe you do, I don't. Happy New Year, -Basil
Public thanks to UUNet security
Since the good things so rarely get mentioned... I would like to publicly thank UUNet's network operations for dealing with a DOS attack quickly and efficiently yesterday. I am happy to say it only required one phone call of less than 15 minutes to get the appropriate filtering in place. Mark Radabaugh Amplex (419) 720-3635
Re: DC power versus AC power
"Barton F Bruce" <[EMAIL PROTECTED]> writes: > Typical 120/208V small branch circuit breakers in small buildings and homes > have an interrupting capacity rated at 10,000 amps, and should not be > deployed where that can be exceeded. It will be on the label. It's worth noting that the interrupting capacity of the aforementioned breakers is 10,000 amps *AC*, and that said circuit breakers should not be used in *DC* applications despite the fact that the voltage is less than half as much and the fact that they're downstream from a 600A fuse (and have smaller wire in the circuit that will naturally limit how many amps can go into a short anyway). I'm hazy on the theory (perhaps someone more knowledgeable can post it), but my understanding is that with AC the arc has a chance to quench 120 times per second (ie, every time there's a zero crossing), and with DC that opportunity (obviously) does not exist. Bottom line is that one should buy breakers and fuses that are designed for use in DC powerplants, rather than trying to cheap out with something you picked up at Home Depot or Pep Boys. I'm sure I'm wasting my breath since _nobody_ who reads NANOG would ever try to cut corners to save a few bucks... :) ---Rob
Re: AOL & Cogent
On Mon, Dec 30, 2002 at 05:37:10AM -0600, Basil Kruglov wrote: > > On Sat, Dec 28, 2002 at 09:45:21PM -0500, Richard A Steenbergen wrote: > > > 2. I think I asked this before, why wouldn't Cogent prepend > > > customer prefixes to Level3 or set BGP4 community for multihomed sites, > > > homed w/ Cogent + someone else. > > > > You got your answer to this before, what part wasn't clear? Cogent isn't > > congested in the inbound direction, only outbound to Level 3. The best > > they could do is lower their localpref for 3356, which I would surely hope > > they have done already. > > I understand very well that there is no problem on the inbound of Cogent > from Level3. > > For my not-so-bright customers I simply want traceroutes to look good when > they run one from Level3-homed site. Obviously a ~5-7 hops to us looks > really disturbing, try to explain to one of them that there is no problem. > > Enough said. > -Basil Then make a press release for your not so bright customers, and explain every single detail rather than asking a company to change their entire routing policy because you're too lazy to educate your customers on how traceroute shouldn't be used as a tool to gauge performance. And if you can't explain it to them, then you should step back and look at who you really have for customers. "Enough said." -- Omachonu Ogali Information Wave Technologies [EMAIL PROTECTED] http://www.informationwave.net
Re: AOL & Cogent
On Sat, Dec 28, 2002 at 09:45:21PM -0500, Richard A Steenbergen wrote: > > 2. I think I asked this before, why wouldn't Cogent prepend > > customer prefixes to Level3 or set BGP4 community for multihomed sites, > > homed w/ Cogent + someone else. > > You got your answer to this before, what part wasn't clear? Cogent isn't > congested in the inbound direction, only outbound to Level 3. The best > they could do is lower their localpref for 3356, which I would surely hope > they have done already. I understand very well that there is no problem on the inbound of Cogent from Level3. For my not-so-bright customers I simply want traceroutes to look good when they run one from Level3-homed site. Obviously a ~5-7 hops to us looks really disturbing, try to explain to one of them that there is no problem. Enough said. -Basil
Re: DC power versus AC power
A few points: Below 50 volts, anyone can do the wiring. No licensed electrician is needed im most jurisdictions. Total fault current available determines the damage that will be done when something like a wrench falls across bus bars. Time, too, counts. If you can't vaporize the whole wrench before the upstream fuse or breaker opens, then you just have scarred metal. For any given load, the AC wiring, running higher voltage than 48VDC CO batteries, will be smaller due to the lower amperage requirements and the larger typically allowed voltage drop. The AC network's source impedance is going to be a lot higher than a local battery string. too. A 600 amp capacity BDFB panel in a COLO room even just a 100' of cable loop length (50' end to end) from the main fuse panel at the batteries may well be wired with excess ampacity just to limit the IR drop. Instead of just a single 535MCM cable (that has adequate ampacity) that might mean up to 3x535MCM or 2x777MCM in parallel for both battery and return for both A and B battery feeds! That is a lot of copper. Look at the current available from a typical 9,000 ampere hour battery through just a single 100' length of 750MCM cable that has a resistance of .00150 ohms, assuming, for simplicity no resistance for the battery. That is 48 / .00150 = 32,000 amps, and that is very comfortable short term for a battery that can deliver 9,000 amps for an hour! The cable between the battery and the main fuse panel is unprotected other than by the ability to vaporise the straps between cells that are often substantially smaller in cross section than the cable. After the main fuse panel, typically there would be a 600 amp fuse protecting the feed to a BDFB Before that fuse goes, there is still plenty of energy to vaporize common hand tools. Typical 120/208V small branch circuit breakers in small buildings and homes have an interrupting capacity rated at 10,000 amps, and should not be deployed where that can be exceeded. It will be on the label. Some carriers have reservations about the small plug in (bullet pins on rear) BDFB panel breakers that in one case size range from a few amps to 100. Apparently there have been fires, and fuses are considered safer. Once you get past dry skin resistance, I have several times seen human body resistance given as 1 ohm. I have no idea how/where that is being measured.
