- Test - lists.nanog.org

Quarantine your infected users spreading malware
by Gadi Evron 02 Mar '06

02 Mar '06

Many ISP's who do care about issues such as worms, infected users "spreading the love", etc. simply do not have the man-power to handle all their infected users' population. It is becoming more and more obvious that the answer may not be at the ISP's doorstep, but the ISP's are indeed a critical part of the solution. What their eventual role in user safety will be I can only guess, but it is clear (to me) that this subject is going to become a lot "hotter" in coming years. Aunty Jane (like Dr. Alan Solomon (drsolly) likes to call your average user) is your biggest risk to the Internet today, and how to fix the user non of us have a good idea quite yet. Especially since it's not quite one as I put in an Heinlein quote below. Some who are user/broadband ISP's (not say, tier-1 and tier-2's who would be against it: "don't be the Internet's Firewall") are blocking ports such as 139 and 445 for a long time now, successfully preventing many of their users from becoming infected. This is also an excellent first step for responding to relevant outbreaks and halting their progress. Philosophy aside, it works. It stops infections. Period. Back to the philosophy, there are some other solutions as well. Plus, should this even be done? One of them has been around for a while, but just now begins to mature: Quarantining your users. Infected users quarantine may sound a bit harsh, but consider; if a user is indeed infected and does "spread the joy" on your network as well as others', and you could simply firewall him (or her) out of the world (VLAN, other solutions which may be far better) letting him (or her) go only to a web page explaining the problem to them, it's pretty nifty. As many of us know, handling such users on tech support is not very cost-effective to ISP's, as if a user makes a call the ISP already losses money on that user. Than again, paying abuse desk personnel just so that they can disconnect your users is losing money too. Which one would you prefer? Jose (Nazario) points to many interesting papers on the subject on his blog: http://www.wormblog.com/papers/ Is it the ISP's place to do this? Should the ISP do this? Does the ISP have a right to do this? If the ISP is nice enough to do it, and users know the ISP might. Why not? This (as well as port blocking) is more true for organizations other than ISP's, but if they are indeed user/broadband ISP's, I see this as both the effective and the ethical thing to do if the users are notified this might happen when they sign their contracts. Then all the "don't be the Internet's firewall" debate goes away. I respect the "don't be the Internet's firewall issue", not only for the sake of the cause but also because friends such as Steven Bellovin and other believe in them a lot more strongly than I do. Bigger issues such as the safety of the Internet exist now. That doesn't mean user rights are to be ignored, but certainly so shouldn't ours, especially if these are mostly unaffected? I believe both are good and necessary solutions, but every organization needs to choose what is best for it, rather than follow some pre-determined blueprint. What's good for one may be horrible for another. "You don't approve? Well too bad, we're in this for the species boys and girls. It's simple numbers, they have more and every day I have to make decisions that send hundreds of people, like you, to their deaths." -- Carl Jenkins, Starship Trooper, the movie. I don't think the second part of the quote is quite right (to say the least), but I felt bad leaving it out, it's Heinlein after all... anyone who claims he is a fascist though will have to deal with me. :) This isn't only about users, it's about the bad guys and how they out-number us, too. They have far better cooperation to boot. There are several such products around and they have been discussed here on NANOG before, but I haven't tried them myself as of yet, so I can't really recommend any of them. Can you? I'll update on these as I find out more on: http://blogs.securiteam.com This write-up can be found here: http://blogs.securiteam.com/index.php/archives/312 Gadi. -- http://blogs.securiteam.com/ "Out of the box is where I live". -- Cara "Starbuck" Thrace, Battlestar Galactica.

23 56

the need for shim6
by Edward B. DREGER 02 Mar '06

02 Mar '06

I hesitate to make an analogy, lest the analogy wars begin... Sometimes I am forced to use a telephone. I periodically get dead air or a fast busy. Sadly, my phone skills are rusted. Can someone please tell me how I select the switches and trunks through which my call is routed? Thanks. Oh, and for those who might suggest "calling card": It doesn't work as often as one might hope. There have, however, been times where PCS to CC to local number gets through when PCS to local does not. It appears that endpoints generally trust networks to... well... run the network. Don't like it? Build your own network. Now we're back to PI space and table size. Moore's Law! (Anyone up for corollary to Godwin's Law in which the trigger is "Moore's Law"?) In the "radical proposal" thread, the bottom line was that providers would rather have big[ger] routing tables than cooperate. Fine. It appears that we're now pitting routing table size against handing over control to endpoints. Detection of sarcasm and hyperbole is left as an exercise to the reader. ;-) Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc(a)brics.com -*- jfconmaapaq(a)intc.net -*- sam(a)everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.

1 1

second v6 multihoming paper
by Lucy E. Lynch 02 Mar '06

02 Mar '06

http://www.ecs.soton.ac.uk/~ajf101/irp-ajf101-multihoming.pdf the money quote: "The lack of a standardised solution to multihoming remains a large issue frustrating wider-scale deployment of IPv6, as many large sites rely on multihoming for connection reliability and optimality. The proposed multihoming solutions presented in this paper can be broadly grouped into two categories: those that support connection survivability, and those that do not. Those that do, however, are invariably more complex, and require significant protocol changes, thus breaking the "simplicity" aim as given in RFC3582 [23]. Therefore, it can be said that no proposed solution yet meets these goals. Having said that, it is difficult to see how such a solution, that is both simple and comprehensive, can be built, working in the new environment that is IPv6. After at least five years of proposals, nothing that solves all goals has yet been suggested." Some of you may already know Alan Ford as a v6ops co-author: http://www.potaroo.net/ietf/all-ids/draft-chown-v6ops-renumber-thinkabout-0… and he also worked on the re-numbering presentation at the paris IETF http://www3.ietf.org/proceedings/05aug/slides/v6ops-7.pdf - lel

1 0

APC NetworkAir FM series
by JB Nanog 01 Mar '06

01 Mar '06

Wanted to know thoughts on the APC Network FM series for cooling datacenters? If this is the wrong place for this topic, I apologize. Thanks

1 0

Re: shim6 @ NANOG (forwarded note from John Payne)
by Brandon Butterworth 01 Mar '06

01 Mar '06

> There is > talk at present of whether the protocol needs to be able to > accommodate a site-policy middlebox function to enforce site policy Certainly, firewalls may be the only point such policy will work when the hosts are hidden behind them on a corporate lan 10 years of host legacy later I don't see managing this being fun. easier to upgrade a few routers that have to stay current anyway > The scope of > that policy mediation function depends strongly on people like you > saying "at a high level, this is the kind of decision I am not happy > with the hosts making". For our web hosting farms I'd rather our hosts host and not route, there's too many of them and they are busy enough we don't want to have to buy more to do the job a C or J box of asics should do better, not accounting for the admin of managing it over 1000s of hosts instead of a few routers. Routing is also the responsiblity of a different team from hosting brandon

1 0

FYI - China To Launch Alternate Country Code Domains
by william(at)elan.net 01 Mar '06

01 Mar '06

---- From: Michael Geist <mgeist(a)pobox.com> Date: February 28, 2006 9:24:09 AM EST To: dave(a)farber.net Subject: China To Launch Alternate Country Code Domains Dave, China is preparing to launch what appears to be an alternate root. Starting tomorrow, they will establish four country-code domains. In addition to the current dot-cn, they will offer Chinese character versions of dot-China, dot-net, and dot-com. As one article puts it, this "means Internet users don't have to surf the Web via the servers under the management of the Internet Corporation for Assigned Names and Numbers (ICANN) of the United States." Coverage from China is at http://english.people.com.cn/200602/28/eng20060228_246712.html I've got some quick commentary at <http://michaelgeist.ca/component/option,com_content/task,view/id,1130/Itemi d,85/nsub,/> which includes: "The alternate root has always lurked in the background as a possibility that would force everyone to rethink their positions since it would enable a single country (or group of countries) to effectively pack up their bags and start a new game. The U.S. control would accordingly prove illusory since a new domain name system situated elsewhere would be subject to its own rules. While the two could theoretically co-exist by having ISPs simply recognize both roots, the system could "break" if both roots contained identical extensions. In other words, one root can have dot-com and other other can have dot-corp, but they can't both have dot-com. It is with that background in mind that people need to think about a press release issued yesterday in China announcing a revamping of its Internet domain name system. Starting tomorrow, China's Ministry of Information Industry plans to begin offering four country-code domains. In addition to the dot-cn country code domain, three new Chinese character domains are on the way: dot-China, dot-net, and dot-com. As the People's Daily Online notes this "means Internet users don't have to surf the Web via the servers under the management of the Internet Corporation for Assigned Names and Numbers (ICANN) of the United States." In other words, the Chinese Internet becomes a reality tomorrow. With it, the rules of the game may change as 110 million Internet users will suddenly have access to a competing dot-com (albeit in a different character set) and will no longer rely exclusively on ICANN for the resolution of Internet domain name queries. This change was probably inevitable regardless of the status of ICANN, however, the U.S. position can't possibly have helped matters. Indeed, some might note that while Congress has been criticizing U.S. companies for cooperating with Chinese law enforcement and thereby harming Internet freedoms, those same Congressional leaders may have done the same by refusing to even consider surrendering some control over the Internet root to the international community and thereby opening the door to an alternate root that could prove even worse from a freedom perspective. This week's announcement certainly doesn't mark the end of a global interoperable Internet. It does move one step further toward that path since in Internet governance terms, the credible threat is now real." MG --********************************************************************** Professor Michael A. Geist Canada Research Chair in Internet and E-commerce Law University of Ottawa, Faculty of Law 57 Louis Pasteur St., Ottawa, Ontario, K1N 6N5 Tel: 613-562-5800, x3319 Fax: 613-562-5124 mgeist(a)pobox.com http://www.michaelgeist.ca

7 6

NZNOG 06 - March 22-24 , Registrations online
by Simon Lyall 01 Mar '06

01 Mar '06

NZNOG 06 - Registrations now online. http://www.nznog.org The next conference of the New Zealand Network Operators' Group is to be held in Wellington, New Zealand between 22-24 March 2006. The conference is on the week before the ICANN meeting in Wellington so people can attend both events. NZNOG meetings provide opportunities for the exchange of technical information and discussion of issues relating to the operation and support of networked services, with particular emphasis on New Zealand. The conference has a strong technical focus with the aim of attracting a strong turnout of technical personnel. The conference fee is affordable to most to encourage greater participation This year we have a strong programme of New Zealand and overseas speakers on a wide range of topics over 3 days. The programme includes talks on VoIP, DNSSEC, IPv6, BGP, 10G Networks, Peering, QoS and Content-delivery. NZNOG 2006 registration fee is $250 for three days See http://www.nznog.org for more details. My apologies if you see multiple copies of this announcement. -- Simon J. Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.

1 0

Identify amount of traffic to special IP address in Radius
by Joe Shen 01 Mar '06

01 Mar '06

Hi, In order to summrize broadband subsciber's traffic data, we need to identify those traffic to our video servers by BRAS which use Radius. Currently, our BRAS could only report total amount of traffic a subscriber transferred. Could we make BRAS genenrate radius accounting data including tags indicating destination IP information ? thanks Joe __________________________________ Do you Yahoo!? Yahoo! Movies - Search movie info and celeb profiles and photos. http://sg.movies.yahoo.com/

2 3

Re: Transit LAN vs. Individual LANs
by Scott Weeks 01 Mar '06

01 Mar '06

----- Original Message Follows ----- From: "Stephen Sprunk" <stephen(a)sprunk.org> > Thus spake "Scott Weeks" <surfer(a)mauigateway.com> > > From: "Stephen Sprunk" <stephen(a)sprunk.org> > >> ITYM two big transit LANs -- one must be prepared for a > >> switch to fail. > > > > These're going to be router-to-router connections (each > > AR is connected to both CRs) and I had thought about > > tying them all into one VLAN vs. PTP Gig-E. I was just > > trying to find out the operational benefits of either > design. > > If your physical topology is going to be PTP links, then > you should go with PTP at the logical level as well. > Making one topology look like another is generally a bad > idea. This is what I decided to do. Thanks everyone, your ideas (and those of a good friend) helped me to find the KISS solution. :-) scott

1 0

Cogent peering issues between San Jose and San Francisco
by Peter Kranz 01 Mar '06

01 Mar '06

Anyone else experiencing this? Paths through Cogent to San Jose are getting 100 ms of latency at p10-0.core01.sjc03.. Its been a daily occurrence for about a week now. Latency is normal during the day until about 3-4pm when it starts to rise to 100 ms and stays there until a little after midnight. traceroute to www.apple.com.akadns.net (17.254.0.91), 30 hops max, 38 byte packets 1 10.Ge1-0-10-Cr01-365m-SFO.unwiredltd.net (204.11.104.4) 0.454 ms 0.487 ms 0.424 ms 2 g0-8.na21.b007352-0.sfo01.atlas.cogentco.com (38.99.206.145) 0.452 ms 0.406 ms 0.393 ms 3 t3-4.mpd01.sfo01.atlas.cogentco.com (154.54.3.129) 0.645 ms 0.505 ms 0.479 ms 4 g3-0-0.core02.sfo01.atlas.cogentco.com (154.54.3.117) 0.480 ms 0.418 ms 0.386 ms *** 5 p10-0.core01.sjc03.atlas.cogentco.com (66.28.4.133) 95.705 ms 89.578 ms 88.039 ms *** 6 verio.sjc03.atlas.cogentco.com (154.54.11.246) 86.466 ms 84.790 ms 85.694 ms 7 xe-0-2-0.r20.snjsca04.us.bb.verio.net (129.250.2.72) 87.477 ms 91.883 ms 112.126 ms MPLS Label=100096 CoS=0 TTL=1 S=1 8 xe-1-1.r02.snjsca04.us.bb.verio.net (129.250.2.29) 254.899 ms 273.583 ms 204.051 ms 9 ge-3.internap.snjsca04.us.bb.verio.net (129.250.12.14) 89.372 ms 85.061 ms 87.248 ms 10 border1.ge0-0-bbnet2.sje.pnap.net (66.151.144.68) 88.441 ms 91.033 ms 93.412 ms traceroute to www.cisco.com (198.133.219.25), 30 hops max, 38 byte packets 1 10.Ge1-0-10-Cr01-365m-SFO.unwiredltd.net (204.11.104.4) 0.468 ms 0.414 ms 0.324 ms 2 g0-8.na21.b007352-0.sfo01.atlas.cogentco.com (38.99.206.145) 0.500 ms 0.553 ms 0.460 ms 3 t3-4.mpd01.sfo01.atlas.cogentco.com (154.54.3.129) 0.640 ms 0.567 ms 0.527 ms 4 g3-0-0.core02.sfo01.atlas.cogentco.com (154.54.3.117) 0.506 ms 0.470 ms 0.449 ms *** 5 p10-0.core01.sjc03.atlas.cogentco.com (66.28.4.133) 93.822 ms 94.459 ms 95.483 ms *** 6 ex1-p1-1.eqsjca.sbcglobal.net (151.164.248.249) 96.902 ms 99.557 ms 101.810 ms 7 bb1-p6-0.crscca.sbcglobal.net (151.164.242.229) 103.717 ms 103.422 ms 100.601 ms 8 bb2-p5-0.pltnca.sbcglobal.net (151.164.43.170) 114.931 ms 92.110 ms 93.101 ms 9 ded1-8-3-0.pltn13.pbi.net (151.164.191.245) 220.898 ms traceroute to www.mci.com (198.4.5.227), 30 hops max, 38 byte packets 1 10.Ge1-0-10-Cr01-365m-SFO.unwiredltd.net (204.11.104.4) 0.923 ms 0.414 ms 0.425 ms 2 g0-8.na21.b007352-0.sfo01.atlas.cogentco.com (38.99.206.145) 0.456 ms 0.431 ms 0.474 ms 3 t3-4.mpd01.sfo01.atlas.cogentco.com (154.54.3.129) 0.594 ms 0.551 ms 0.474 ms 4 g3-0-0.core02.sfo01.atlas.cogentco.com (154.54.3.117) 0.458 ms 0.443 ms 0.377 ms *** 5 p10-0.core01.sjc03.atlas.cogentco.com (66.28.4.133) 95.815 ms 92.236 ms 89.806 ms *** 6 POS4-3.BR5.SAC1.ALTER.NET (204.255.174.209) 91.906 ms 91.998 ms 92.930 ms 7 0.so-2-1-0.XL1.SAC1.ALTER.NET (152.63.52.226) 94.003 ms 96.119 ms 98.381 ms 8 0.so-7-0-0.CL1.IAD5.ALTER.NET (152.63.34.142) 161.592 ms 165.041 ms 165.997 ms 9 500.ATM4-0.GW2.IAD5.ALTER.NET (152.63.34.173) 165.745 ms 163.512 ms Peter Kranz Founder/CEO - Unwired Ltd www.UnwiredLtd.com Desk: 510-868-1614 x100 Mobile: 510-207-0000 pkranz(a)unwiredltd.com

1 0