September 2008 - Test - lists.nanog.org

InterCage, Inc. (NOT Atrivo)
by InterCage - Russ 08 Sep '08

08 Sep '08

Hello Everyone, Good morning. Seeing the activity in regards to our company here at NANOG, I believe this is the most reasonable and responsible place to respond to the current issues on our network. We hope to obtain non-bias opinion's and good honest and truthful information from the users here. Being that there are much larger operators here then us, what kind of insight can you give to the issues that have arisen? We've near completely removed (completion monday 09/08/08) Hostfresh from our network. 2 of their /24's have been removed: 58.65.238.0/24 dropped 58.65.239.0/24 dropped The machine's they leased from us have been canceled. What do you suggest for the next move? Thank you for your time. Have a great day. --- Russell M. InterCage, Inc.

5 6

Re: InterCage, Inc. (NOT Atrivo)
by Scott Weeks 08 Sep '08

08 Sep '08

My apologies everyone, I shouldn't have said that. I'm done. scott --- surfer(a)mauigateway.com wrote: --- jpleger(a)gmail.com wrote: I am sure if I looked into it more I could find some exploits related to the sites. ------------------------------------- "Why software piracy might actually be good for companies." Folks should clean their own house before pointing fingers at others... --------------------------------------

1 0

Re: InterCage, Inc. (NOT Atrivo)
by Scott Weeks 08 Sep '08

08 Sep '08

--- ge(a)linuxbox.org wrote: Well, perhaps you can share any information with us on a legitimate client you have? ---------------------------------- Now why do you have to go there? Just to fan the flames for fun and profit? :-( scott

3 2

Bandcon (apparently?) no longer providing service to Atrivo / Intercage
by Gadi Evron 08 Sep '08

08 Sep '08

Update, Monday, Sept 8, 12:00 p.m. ET: Todd Braning, vice president of BandCon, just e-mailed me to say that BandCon also has stopped providing connectivity to Atrivo/Intercage. From his e-mail: "Intercage, a new customer, was connected to the BandCon Network for total of about a week. Oncewe recognized and issue with Intercage, BandCon took immediate action and terminated services. We are no longer providing services to AS27595. This can be confirmed here." http://www.cidr-report.org/cgi-bin/as-report?as=27595&view=2.0 >From the Washington Post article again. Added "apparently" in the subject line to avoid BGP surprises again. WV FIBER is cutting them off on Thursday. I am starting a pool to see which of their ready-made ASs they will move to. Gadi.

1 0

NTT/ChinaTelCom troubleshooting
by Andrew Staples 08 Sep '08

08 Sep '08

Our connectivity from the US to ChinaTelCom has been in the toilet for 2 months. The Olympics are over, and I'm assured by my Shanghai contacts that The Great Firewall of China has been relaxed, yet the problem remains. Local loops on each end test fine to other localized ip space. Symptoms include large-email delivery delays/failures, large file transfer failures. Firewalls and VPNs have been reviewed, NOCS have been contacted. Fingerpointing is raging at its finest. US endpoint is AS7358 Transit is AS2914 CN endpoint is AS4134 If there is anyone from those three networks who can help us figure out why large packets are dropping on transmits from the US to CN, I would really appreciate an off-list reply. Heck, I'll take any replies from anyone that might have some inside information or similar experiences, or give me some ideas on the best way to do some external black-hole router/mtu munging detective work on these networks. Thanks, Andrew

1 0

[funsec] Security Fix: Updates on Atrivo/Intercage (fwd)
by Gadi Evron 08 Sep '08

08 Sep '08

---------- Forwarded message ---------- Date: Mon, 8 Sep 2008 04:17:29 GMT From: Paul Ferguson <fergdawg(a)netzero.net> To: funsec(a)linuxbox.org Subject: [funsec] Security Fix: Updates on Atrivo/Intercage -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Krebs add some late updates to his "Security Fix" article from Friday 5 September 2008: [snip] Update, Sunday, Sept. 7, 8:02 p.m.: I spoke today with Randy Epstein, president of WVFiber and co-founder of Host.net, which acquired WVFiber just six weeks ago. Epstein said after reading reports from Security Fix, Hostexploit.com, Spamhaus.org and others about cyber crime activities at Atrivo, WVFiber has decided to drop Atrivo as a customer. WVFiber plans to stop providing upstream connectivity to Atrivo by Wednesday or Thursday at the latest, Epstein said. That would leave Atrivo with just a single upstream provider -- Bandcon. Update, Sunday, Sept. 7, 9:15 p.m.: nLayer Communications, a company that owns a significant slice of the Internet addresses used by Atrivo/Intercage, is demanding that Atrivo vacate the space and return the addresses by Sept 30. "Atrivo/Intercage has not been a direct customer of nLayer Communications since December 2007, but they still have some legacy reallocations from our IP space," wrote nLayer co-founder Richard A. Steenbergen, in an e-mail to Security Fix. "Since they are no longer a customer, we require that they return our non-portable IP space, and have given them a deadline of September 30th to do so. If the IP space is not returned by that point, we will follow standard procedure to reclaim it, including null routing the space, and sending cease and desist letters to any network who still transits it without our permission." According to Steenbergen, Atrivo/Intercage must return roughly 7,400 IP addresses. [snip] Ref: http://voices.washingtonpost.com/securityfix/2008/09/scam-heavy_us_isp_grow s_more_i.html FYI, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFIxKdMq1pz9mNUZTMRAnLcAKCRgGjZrgwr5xCmFFXPV/a0xUAlVwCaAkPL nHo38nvc5azHws2QPhshAvY= =zWoJ -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ _______________________________________________ Fun and Misc security discussion for OT posts. https://linuxbox.org/cgi-bin/mailman/listinfo/funsec Note: funsec is a public and open mailing list.

1 0

RE: 10GE CWDM
by Robert Boyle 07 Sep '08

07 Sep '08

At 12:03 AM 8/31/2008, you wrote: >Currently it is my understanding the 10 Gbps signals are carried on >4 x 2.5 Gbps signals that are compatible with existing CWDM and DWDM >equipment. There are 40 Gbps DWDM systems and 10 Gbps lasers on 100 >Gbps and greater capacity systems. I agree with Alex's comments that >to have 10 Gbps on a CWDM system is to have a CWDM system of at >least 40 to 100 Gbps and that is very expensive today. The only affordable CWDM 10G system I have seen although I haven't used it yet is a single 10G band at 1310 or 1550 with 8 additional 2.5G bands around it. I haven't seen any 4 band 10G CWDM boxes with XFPs for less than $5000 yet, but I would expect them in the next year or two - I'm hoping anyway. I'm out of the country at the moment and access is a bit too slow to look it up easily now. If you need the manufacturer, let me know and I'll look it up when I return. -Robert Tellurian Networks - Global Hosting Solutions Since 1995 http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "Well done is better than well said." - Benjamin Franklin

5 5

RE: Force10 Gear
by hobbit＠avian.org 07 Sep '08

07 Sep '08

This once again quickly reduces to a question of real-life need in my mind. What proportion of useful traffic actually carries IP options these days? Who uses them other than fooling around with the occasional source-routing or RR exercise, if their local infrastructure even permits it to be sent? Many sites just firewall off all that stuff because in real life they never use it or need it. For them it's more trouble than it would be worth trying to process correctly, especially in a security context, so that's their accepted real-life practice. Clearly, those who design the routing iron are well aware of such practice because they optimized the hardware to process the far more typical no-options day to day traffic. While they still accomodate options it's evidently done as kind of an add-on bandaid way outside of the normal path. Now you have to ask yourself where the people making the iron cheaped out -- should they have designed in the ability to handle all these corner cases at their normal wire speed, or should they have dismissed such foolishness and concentrated on what they knew the industry actually requires? How much additional cost does anyone think ASICs to deal with options and other seldom- seen conditions at the same transit rates would incur? I think the most common answer would be "f'geddaboudit". The TTL=1 is an interesting one, but really, under normal conditions shouldn't happen that often. People tracerouting certainly shouldn't expect 100% reliability on getting the "expired" ICMP back, and automatically throttling the rate of errors from routing loops might have certain benefits so why try to handle *every* expired TTL that comes along? It seems like taking anything out of the fast-path should only be done if the slow path is good and ready to accept it, and if someone's trying to hammer the box with stupid stuff then most of it should simply be dropped. Handling it should be near the bottom of the main processor's priority list ... and rather than allow the fast iron to pile way too much crap in its inbox to be dealt with, process-switching should have a VERY short queue and be able to tell the lower levels "not now" and simply increment some obscure counter for "stupid packets dropped" without letting that impinge on the more important tasks at hand. Having the whole box fall over is the *least* acceptable result. _H*

1 0

Re: ingress SMTP
by matthew＠sorbs.net 07 Sep '08

07 Sep '08

----- Original Message ----- From: Michael Thomas <mike(a)mtcc.com> Date: Monday, September 8, 2008 7:31 am Subject: Re: ingress SMTP > > Would that it were so easy :) You also have the more daunting task > of hooking up your auth/aaa infrastructure with your MTA's, and all > of the care and feeding that entails. As a matter of interest, it took but a couple of person hours to sort this out at my last place of work, the largest time chunk in equation was the compiling of TLS and the various SASL modules into Postfix. The second from largest chunk of time was to get the script to get the information required from the various other back end mail servers on campus, including, but not limited to, Lotus Notes, M$ Exchange, and Sun/iPlanet messaging server and it's LDAP server. The only down side to the system was password changed took up to 15 minutes to get to the mail systems as there was no direct connection between the external gateways and the internal auth systems. Of course the above doesn't take into account the several weeks of political badgering and grandstanding that we endured to get the faculties to actually accept that that was the way it was going to be. They couldn't stand that there would only be incoming and outgoing mail via the central gateway. Such is life at Universities. Regards, M

2 1

Re: Force10 Gear
by David Newman 07 Sep '08

07 Sep '08

Paul Wall wrote: > Once upon a time, vendors released products which relied on CPU-based > "flow" setup. Certain vintages of Cisco, Extreme, Foundry, > Riverstone, etc come to mind. These could forward at "line rate" > under normal conditions. Sufficient randomization on the sources > and/or destinations (DDoS, Windows worm, portscans, ...) and they'd > die a spectacular death. Nowadays, this is less of a concern, as the > higher-end boxes can program a full routing table (and then some) > worth of prefixes in CAM. > > Either way, I think it's a good test metric. I'd be interested in > hearing of why you think that's not the case. Back on topic, doing a > couple of gigs of traffic at line rate is a walk in the park for any > modern product billed as a "layer 3 switch". The differentiator > between, say, a Dell and a Cisco, is in the software and profoundly > not the forwarding performance. Without disagreeing with your main point, there are still plenty of ways to bring even very large boxes to near-zero forwarding rates: 1. Set IP options. A pair of Cat 6509Es using VSS can forward packets without options at up to 770 mpps, but when packets have options the maximum is more like 20 kpps. And that's a "high-speed" example; the options forwarding rate is more like 0 pps with some other devices. Silicon that forwards packets very fast is only good when header lengths are fixed. 2. Use weak hashing algorithms. Some switches (names removed to protect the guilty) hash on the low-order three bits of MAC address to decide which of eight ASICs will forward a packet. I have heard of, but have not tested, devices that use only three bits for making OSPF ECMP decisions. Not surprisingly either technique can lead to lots of hash collisions in routed environments. 3. Offer IP multicast. Maximum forwarding rates for multicast are rather different than IP unicast with some vendors' implementations, and may be affected by group count, mroute count and amount of replication. dn

4 4