May 2002 - Test - lists.nanog.org

RE: ratios
by Scott Granados 09 May '02

09 May '02

I guess one of the concerns it the definition of peer. The policies as I read bhem by cnw and uunet seem to be so overly restrictive that none of the newer carriers will meet them. I've litterllly, not from uunet and or cw but from other carriers received responses to peering requests "Well your to small to peer but we have great transit pricing in the areas you requested." This is after I offered to meet them at the three east, west, and central mae's, a coupee if diverse paix's, and Chicago. If the concern is economics than peering ss much as possible and in a less restrictive manner makes the most sense. The target here is to provide the best possible service to customers which certainly ocould be other carriers, but are most likely more other end users. If performance is better it will in many cases be an easier sell. More than a few times prospective customers were very concerned with peering and interconnection. But then again I was up against uunet in a play to get a customer and uunet promised this customer they could globally route and announce to its peers /30's or longer. :) I certainly couldn't make such claims. I'm mentioning this because it seems in all companies, not just uunet claims are maid but frequently not backed up by technical good sense. I guess its like most things there are many approaches and certainly not everyone will agree to each approach. I just can't see cases when not peering is better assuming the basic requirements are met to insure proper technical performance. On Thu, 9 May 2002, David Barak wrote: > > On Thu, 9 May 2002, Scott Granados wrote: > > > > The only thing I can say is I wish they would just publically > > acknowledge that fact. If uunet and cw don't wish to peer they should > > just not have a peering policy. > > come now, UU and C&W both have a substantive number of peers. Their > policies tend toward equating the routing concept of "peer" with the > english-language concept of "peer" meaning "equal." > > The whole argument is that settlement-free-interconnection is only > worthwhile if both parties benefit more than they would lose if they did > not interconnect. > > The economics of this will tend to encourage smaller providers to be more > liberal with peering agreements, and larger providers to be less > liberal. Does this still seem unfair? > > David Barak > WorldCom > > "Quis custodes ipsos custodiet?" - Juvenal > >

1 0

RE: Effective ways to deal with DDoS attacks?
by LeBlanc, Jason 08 May '02

08 May '02

I guess the 'filter box' can be a number of different things, based on your needs and preferences. At first glance CloudShield seems pretty beefy, am reading more as we speak. Yes, Juniper can be convinced to add things, we've asked for a few. ;) Part of the problem with asking for new things on an ASIC, takes time. Anything they add in their code to help filter will likely not be done in hardware, meaning potential impact. I know some people need to filter on their routers for various reasons, but my thoughts are to minimize this. A router that is working hard at just forwarding packets doesn't need to extra overhead of looking deep into packet headers to figure out what to do with packets. Juniper is better at this, as are some Cisco products, but the GSR is a crappy packet filter if you put enough traffic through it. Yes certain linecards are better than others, but the newer they are the more buggy they are, and we're talking HW here, so bug fixes will be awhile. The caveat to all this is obvious, these are big links and big routers, only applies to high traffic networks..as that is the only place the expense is justified. uRPF, however, works on (almost) any CEF capable Cisco router. Some may have already seen this, worth a look if not. http://www.cisco.com/warp/public/707/newsflash.html There are some limitations as to where uRPF works, SONET only on GSRs for example (thanks Cisco). I believe it will work on 65xx (SUP1A and SUP2 I think) regardless of interface type. Impact should be minimal, as it simply does a lookup in the CEF table, if the route isn't there it discards. Keep in mind this is NOT a filter, so the impact is much less, it is simply a CEF lookup, much more efficient than a filter. This will get rid of a HUGE percentage of spoofed packets that hit your network, and would also work pretty well if you are the source of an attack. There is some debate as to whether you must not have ANY RFC1918 space for this to work. We're trying to find this out (not a priority), if I get info I'll post. -----Original Message----- From: Richard A Steenbergen [mailto:ras@e-gerbil.net] Sent: Thursday, May 02, 2002 9:23 AM To: LeBlanc, Jason Cc: 'Pete Kruckenberg'; nanog(a)merit.edu Subject: Re: Effective ways to deal with DDoS attacks? On Thu, May 02, 2002 at 08:54:05AM -0700, LeBlanc, Jason wrote: > > uRPF and Radware DoShield, one DoShield per link btw edge router and core > router. Use IDS (yes there is a way to capture all your traffic and > anaylyze it, regardless of bandwidth, no it isn't one box) to identify a > signature, build a filter, config filter on DoShield, up to ~200Mb/s per > DoShield of filtering with zero impact to legit traffic. Scale horizontally > (add more links each with a DoShield on it) based on your ingress traffic. > > I've seen many suggestions on this list, this is the only thing that works > for huge (100Mb/s+) attacks. eBay is likely the biggest target on the net, > this works for us 90% of the time. Is the HW expensive? Yes. (~$35k per > DoShield I think) It works, it scales. You might want to take a look at CloudShield (www.cloudshield.com) they have what can only be described as a pretty impressive looking box for this kind of stuff. > There is no way a Cisco router can handle filtering attacks past a > certain point, nor is it capable of even filtering on some patterns in > attack packets. Juniper is better, but still lacks some filtering > capabilities. Your router is a router, not a packet filter, give up > trying to make it do this until someone builds this into an ASIC on the > router. Thats what the IP2 does, match bytes in the headers and come back with a thumbs down or a thumbs up and a destination interface. It's really not that much harder to match the bytes for a dest port against a compiled ruleset and decide yes or no then it is to match the dest address against a forwarding table and decide which nexthop. They CAN filter on anything in the headers, it's just a matter of convincing them that the specific filter you want is something they should add to their software language and microcode. I'm sure as a core router vendor they must hear every feature request imaginable and not know which ones to follow up on. If anyone from Juniper is listening, I can tell you 4 things to add which will stop all existing packet kiddie tools in their tracks. But then again, I'd rather just have a language for bitmatching at any offset. :) -- Richard A Steenbergen <ras(a)e-gerbil.net> 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)

18 45

AT&T outage
by Streiner, Justin 08 May '02

08 May '02

AT&T is reporting an outage on their IP network between Washington DC and Arlington VA. No details yet. jms

2 2

RE: Qwest outage In NY
by Patrick McEvilly 08 May '02

08 May '02

Qwest has confirmed a DOS attach against two of their Juniper routers in the NY POP. I believe they had a UDP attack last week also (maybe on Saturday). This time the DOS was a TCP attack on the 100Mb management interface on the Juniper, leaving the box unable to pass packets, hence BGP stays up and a full routing table but you cannot get anywhere. Patrick We saw the same issue on Saturday morning too (eastern time). BGP sessions to Qwest stayed up, but no data was moving across Qwest links. Kind of ugly. Emails to Qwest seeking information on Saturday went unanswered. Drew Linsalata The Gotham Bus Company Internet Server and Carrier Neutral Co-Location http://www.gothambus.com > From: Eric Gauthier <eric(a)roxanne.org> > Date: Wed, 8 May 2002 10:43:57 -0400 > To: nanog(a)merit.edu > Subject: Qwest outage in NY > > > Heya... > > Just found out that Qwest had an outage in one of their NY pops > (jfk?) that disrupted access out of the Boston area for about > 20 minutes. The master ticket (I believe) is 566548. Does anyone > know what happened? > > Thanks, > > Eric :) >

4 5

Cisco - Cisco Security Advisory: NTP Vulnerability
by Shaun Bryant 08 May '02

08 May '02

FYI.. http://www.cisco.com/warp/public/707/NTP-pub.shtml By sending a crafted NTP query packet it is possible to trigger a buffer overflow in the NTP daemon. This vulnerability can be exploited remotely. The successful exploitation may cause arbitrary code to be executed on the target machine. Such exploitation, if it is possible at all, would require significant engineering skill and a thorough knowledge of the internal operation of Cisco IOS software or SUN Solaris operating system. To the best of our knowledge this vulnerability cannot cause arbitrary code to be executed on Cisco IOS and SUN Solaris. The vulnerability is present regardless of the role played by the device. The device may be an NTP server or client and it will still be vulnerable. For IOS, this vulnerability is documented as Cisco Bug ID CSCdt93866

1 0

ratios
by Scott Granados 08 May '02

08 May '02

I'm not overly familiar with this but I wondered if someone could detail for me the basics of using ratios to determine elegibility to peer? I have heard that some carrers especially the largest require a specific ratio is this in fact true and is the logic as simple as just insuring equal use of the peer? Thanks Scott

3 2

RE: Another reason to not use MAPS
by Mansey, Jon 08 May '02

08 May '02

Moral of this story, if you have or even think you have a great idea, do NOT become an employee (they own you), stay a contractor (you own you). Jm > -----Original Message----- > From: Conrad A. Rockenhaus [mailto:conradr@skyphusion.com] > Sent: Tuesday, May 07, 2002 10:17 PM > To: Andy Dills > Cc: Margie Arbon; nanog(a)merit.edu > Subject: Re: Another reason to not use MAPS > > > > On Tue, 7 May 2002, Andy Dills wrote: > > > <snip> > > > > > Now, MAPS has filed a lawsuit against a former employee. Why? > > > > Because he might interfere with their ability to make money by > > > > giving away something for free that they charge for! > > > > <...> > > > Precisely what other course of action could MAPS take? > > > > You could let him do whatever he wants with it. The premise of you > > charging for access to the various databases was based on a need to > > cover cost, not a desire to profit. Now you act with motivations > > specifically based on a desire to protect profit. > > The premise of charging covered costs to MAPS. It could be > easily inferred that one of thoses costs is the providing of > salaries and T&E to employees of MAPS. > > The DUL was expanded, improved, and worked on by both the > former employee and the other employees at MAPS, thereby > making it a product of MAPS, not solely of Gordon Fecyk any longer. > > While working on the DUL, Gordon was being paid by MAPS, was > provided equipment by MAPS, and was supported by other MAPS > employees, to build the DUL to where it is right now. > Therefore, the DUL is legally property of MAPS. > > Take this for example: You are working on a security product > to deal with script kiddies. Security company A likes the > idea, and brings you on, as a full time employee. You're > paid and provided assistance to develop a and improve this > method for dealing with script kiddies by security company a. > You develop the product, and security > company a provides it as a service. You leave security > company a or your > contract expires with security company a. Do you go out and > sell this service because you developed it? > > No, you legally can not. You legally can not because > security company paid you as a full time employee and > assisted you to develop this product, therefore, it is the > intelluctual property of security company a. > > Gordon had an idea. MAPS hired him, provided him with tools, > provided him with industry contacts, provided him with the > assistance of other employees, and provided him with a > paycheck to improve and build on the DUL. Due to MAPS' > assistance, Gordon, with the help of other MAPS employees, > developed a very excellent service. > > Since MAPS provided all of these items to Gordon, he was > developing a service that MAPS and MAPS only could provide, > in that form anyway. > > If Gordon went out, developed another DUL on his own, > developed his own independant documentation, etc., then MAPS > would be invalid in suing Gordon. > > However, that's not what he did. He took data that MAPS paid > him and others to develop. He took documentation that he > wrote while MAPS was paying him to do it. He took a model > that MAPS paid him to develop. He stole from MAPS, pure and > simple, and stealing is dishonorable, stupid, and WRONG, and > he deserves what he gets. > > > > > In other words, you have no cred on this street corner. You have no > > moral high ground. You're just another microsft or network > solutions > > complaining about how unfair it is, the injustice of the world! > > This is not the case; as I said before, he was being paid by > MAPS to develop his idea, to improve upon it, and other > things. Taking something from a third party, even though you > developed it, and selling it as your own when someone else > paid for it is wrong, period. What he's doing meets the true > definition of "theft." > > Lets take it to another level. Xecunet hires someone, and > that person has this great idea on how to make some > webhosting solution better than everyone elses. Xecunet > develops it, provides it as a "free upgrade" but then > realizes that they need to cover some costs, so you start > charging a little extra. Fine and good, right? > > Well, your employee leaves and goes to some big webhosting > company, and implements the idea. You paid him to develop > the idea, and assisted with the research, how do you feel > about that? Is he entitled to do that, to take something he > developed for your company and implement it somewhere else? > I wouldn't think so, then someone would of taken Windows from > Microsoft a while back, and sold it as "Blinds" or something > like that. > > > > > You used to be the vigilante force patrolling the net, > looking to stop > > spam by any means neccessary. You did so because that was > the what the > > net needed. Then you started to charge for it. Seems > reasonable, and > > while it upset a lot of long-time contributors (you're > making me pay > > for a service I helped build?), it made sense from the > point of view > > that "Hey, we're losing our shirts here, we need money." > > > > So, now, instead of fighting spam for free, you're fighting a spam > > fighter, the legal bills of which are paid for with the revenues > > generated based on you selling the intellectual property > contributed > > by many people! > > > > What other course of action could MAPS take? You could > throw out the > > people making decisions with their over-stuffed pocketbooks and > > re-invent yourself. > > Stealing is wrong, and stealing needs to be stopped, period. > MAPS is not fighting a "spam fighter." MAPS is fighting > someone that was a former employee paid to develop a service > to the level its at right now, so MAPS could provide it. Now > he took the data used to provide that service, and everything > related to it and is now marketing it as "his own" when in > fact, its not. > > > > > > > > > > So, you who subscribe to MAPS: When will you be cancelling your > > > > subscriptions? It's no longer about stopping spam with > them, now > > > > it's about money. FWIW, the other blacklists out there > are just as > > > > good. I particularly like njabl.org. > > > > > > For those wishing to actually *read* the filings before passing > > > judgement: > > > > > > http://mail-abuse.org/dul_info/ > > > > For those wishing to actually *think* about what MAPS is > really doing > > here before passing judgement: > > > > http://www.chickenboner.com/lawsuit/ > > I looked. That still doesn't defend the fact that Gordon was > being paid to improve this service by MAPS, that's pure and simple. > > Just to give you some background on that, read this: > http://www.eff.org/CAF/law/multimedia-handbook And to just clarify what I'm pointing out in this: "Naturally, you don't need a copyright license for material which you create yourself. However, you should be aware that the rules regarding ownership of copyright are complex. You should not assume that you own the copyright if you pay an independent contractor to create the work (or part of it). In fact,generally the copyright in a work is owned by the individual who creates the work, except for full-time employees working within the scope of their employment and copyrights which are assigned in writing." Gordon was a full time employee. His work is property of MAPS. MAPS is on the right, and they are on the right with what they are doing, period. --conradr

3 2

re: Qwest outage In NY
by Drew Linsalata 08 May '02

08 May '02

We saw the same issue on Saturday morning too (eastern time). BGP sessions to Qwest stayed up, but no data was moving across Qwest links. Kind of ugly. Emails to Qwest seeking information on Saturday went unanswered. Drew Linsalata The Gotham Bus Company Internet Server and Carrier Neutral Co-Location http://www.gothambus.com > From: Eric Gauthier <eric(a)roxanne.org> > Date: Wed, 8 May 2002 10:43:57 -0400 > To: nanog(a)merit.edu > Subject: Qwest outage in NY > > > Heya... > > Just found out that Qwest had an outage in one of their NY pops > (jfk?) that disrupted access out of the Boston area for about > 20 minutes. The master ticket (I believe) is 566548. Does anyone > know what happened? > > Thanks, > > Eric :) >

2 1

Re: Another reason to not use MAPS
by George William Herbert 08 May '02

08 May '02

1) This message had no operational content. 2) None of /., your posting here, nor any of the varied messages in newsgroups appear to have had enough research to bother looking at the actual complaints and responses and what actual issues are involved in MAPS v Feyck. MAPS is certainly not without its flaws, but the specific nature of the offense alleged has nothing to do with the rabid frothing. -george william herbert gherbert(a)retro.com

4 3

Re: ratios
by PETER JANSEN 08 May '02

08 May '02

Scott: Ratios are normally applied to either direction, since it is not totally understood who benefits from what traffic direction. Who benefits: the eyball or the content provider??? But keep in mind traffic ratios are only one parameter to establish a mutially equal beneit. Peter Jansen C&W Date: Tue, 07 May 2002 15:49 -0400 (EDT) From: Scott Granados <scott(a)graphidelix.net> To: PETER JANSEN <peter.jansen(a)cw.net> CC: nanog(a)merit.edu Sender: owner-nanog(a)merit.edu Delivered-to: nanog-outgoing(a)trapdoor.merit.edu Delivered-to: nanog(a)trapdoor.merit.edu Delivered-to: nanog(a)merit.edu Subject: Re: ratios I read the cw and uu examples. In the case of 1.5 to 1 which seems really close but I'm assuming this means I can send you 1.5 to every one received. Does this also apply in the inverse ie uunet sends back to me only 1.5 to my 1 or is this less critical? On Tue, 7 May 2002, PETER JANSEN wrote: > > Scott: > > Traffic ratios are one of the many parameters that ensure equality and > a mutual benefit between networks in a settlement free peering relationship. > > Have a look at our peering policy at www.cw.com/peering. It will > provide you with some information on peering with large networks. > > Regards > > Peter Jansen > Global Peering > Cable & Wireless > > > > > > Date: Tue, 07 May 2002 13:30 -0400 (EDT) > From: Scott Granados <scott(a)graphidelix.net> > To: nanog(a)merit.edu > Sender: owner-nanog(a)merit.edu > Delivered-to: nanog-outgoing(a)trapdoor.merit.edu > Delivered-to: nanog(a)trapdoor.merit.edu > Delivered-to: nanog(a)merit.edu > Subject: ratios > > > I'm not overly familiar with this but I wondered if someone could detail > for me the basics of using ratios to determine elegibility to peer? I > have heard that some carrers especially the largest require a specific > ratio is this in fact true and is the logic as simple as just insuring > equal use of the peer? > > Thanks > > Scott > >

11 18