- Test - lists.nanog.org

Re: IP renumbering timeframe
by David R Huberman 09 May '02

09 May '02

DS writes: > Nonetheless, ARIN is in the business of requiring compliance with its > policies as a condition of IP address allocations. In the real world ARIN only looks at existing assignments to judge the worthiness of an additional address space request. It doesn't look at nor care about non-existent assignments. DS writes: > Third parties can make reasonable arguments that they have standing to > litigate these requirements on the grounds that the requirements were > intended to benefit the public in general and hence they are intended > beneficiaries. ARIN plays, at most, an advisory role to upstream/downstreams vis-a-vis appropriate assignments. It does not get involved with legal disputes nor does it ever directly instruct businesses how to conduct their affairs Sure: organizations have successfully gotten more appropriate assignments from upstreams by thrusting ARIN policies in front of an obstinate upstream's face. Good. But those policies in no way preclude an upstream from taking away downstream assignments - especially in the case of this thread, where the customer/upstream relationship was terminated. Can we please stop this non-argument now? I agree with what you've said: ARIN policies are good for those trying to obtain appropriate assignments. But the more basic argument of "will I make an assignment to my downstream" or "will I allow this assignment to remain in effect" has nothing to do with what you're talking about.

2 2

ratios
by Scott Granados 09 May '02

09 May '02

Just a note here I think needs to be said. In my case at least my experiences with peering and working with other networks has been extremely positive. I had the pleasure of for example having a loop in to Paix Pao1 and that was a very positive thing for my network and frankly business. Most of the carriers I spoke to were great and very responsive with the exception of the one I mentioned before and no it wasn't uunet or cnw. I have peered obviously in other facilities as well but I mentioned the Paix because in my case the impression was they went out of their way to be helpful and it was very positive. I think that its perhaps the sign of a larger problem that the public internet is basically help by one or two large companies ie UU and CW who don't wish to play with the rest of the net but not much can be done about that and no I'm not going to equate this ti Microsoft:). In the end let's hope market forces and economics win out and we'll see.

1 0

Re: IP renumbering timeframe
by David R Huberman 09 May '02

09 May '02

Just because policies are in place that suggest an assignment may or may not be justified is wholly irrelevant to whether or not that assignment takes place (or in the case of the original thread, stays in place). ARIN is not in the business of saying "do" or "do not". Ralph wrote: > >>Is that true? I thought the space belongs to ARIN, and they loan it to > >>certain parties. Those parties can use the IPs in accordance with ARIN > >>rules. I responded: > >The way you've written the above statements makes them true. However, such > >a relationship does not extend to the issue you're dealing with. ARIN > >cannot dictate the business practices of its constituents. DS retorted: > Actually, ARIN can dictate how its constituents allocate IP space > because conforming to ARIN's policies is one of the conditions of an IP > allocation and no ownership rights to the IP space are transferred in > the assignment process. This argument has worked successfully for myself > and others when negotiations with an address space provider turned > hostile. (To my knowledge, it's never been tested in court.)

2 1

RE: ratios
by Dean S Moran 09 May '02

09 May '02

Chris Parker wrote: >At 01:05 PM 5/9/2002 -0400, Daniel Golding wrote: >>You can publicly denounce them on a forum like this, which has doubtful >>effect. > >It informs other networks of the actions taken by said carrier. Od carrier. Other >networks may in turn change *their* business decisions based on that >information. Right! With the (mostly) unregulated nature of the internet as it stands right now, sometimes this is the only recourse we have when a provider does something stupid. Hopefully it'll cause said provider to wake up and smell the roses, but with C&W I doubt it. They're too egotistical to cave in to public pressure. >>Additionally, punishing folks for enforcing rational peering >>requirements is counterproductive. What's so rational about asking for 5000 routes? >Rational is a pretty subjective concept. :) Overly restrictive >covenants wrt housing have been struck down in the past. One could >make an analogy to overly restrive peering agreements if one wanted >to go down that particular rat hole... I actually hope it happens, real soon. >>I guess the best thing you can do is not take peering matters personally, >>and to remember that peering decisions are business decisions, and they by >>personalizing them, it creates unnecessary animosity. > How can I not take it personally when this person's business decision directly and immediately affected mine? Not to mention my quality of life, which is still recovering. Dean _____________________________________________ Free email with personality! Over 200 domains! http://www.MyOwnEmail.com

2 1

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