March 2004 - Test - lists.nanog.org

BellNexxia to C&W problems in NY ? (AS577 - AS3561)
by Mike Tancsa 09 Mar '04

09 Mar '04

I have a few users exchanging data with sites inside Bell Canada call in to complain today with various symptoms (eg. VPNs timing out, transfers taking a long time). After a bit of narrowing down, it would seem that when the traffic comes at me via C&W from Bell (2 of my 3 transit providers 852 and 6539 talk to parts of Bell this way) the problems are acute. Looking at traceroutes between C&W and Bell IP space, there does indeed seem to be some issue between their exchange point in NY The 2 snippets being From bell to cw 6 bx2-newyork83-pos3-0.in.bellnexxia.net (206.108.103.194) 20 msec 20 msec 16 msec 7 iar4-so-2-3-0.NewYork.cw.net (208.173.135.185) [AS 3561] 172 msec 176 msec 176 msec From cw to bell 6 iar4-loopback.NewYork.cw.net (206.24.194.39) 68 msec 68 msec 72 msec 7 teleglobe.NewYork.cw.net (208.173.135.186) 208 msec 208 msec 208 msec At one point in the day, it was adding about 400 to 500ms of latency Type escape sequence to abort. Tracing the route to route-server.cw.net (209.1.220.234) 1 dis40-toronto63-fe5-0-0.in.bellnexxia.net (205.207.238.210) 32 msec 0 msec 232 msec 2 core2-toronto63-pos11-5.in.bellnexxia.net (206.108.98.141) 0 msec 0 msec 0 msec 3 core3-toronto63-pos6-0.in.bellnexxia.net (64.230.242.101) 0 msec 0 msec 0 msec 4 core4-montreal02-pos13-1.in.bellnexxia.net (64.230.243.237) 28 msec 204 msec 208 msec 5 core1-newyork83-pos0-0.in.bellnexxia.net (206.108.99.190) 20 msec 20 msec 16 msec 6 bx2-newyork83-pos3-0.in.bellnexxia.net (206.108.103.194) 20 msec 20 msec 16 msec 7 iar4-so-2-3-0.NewYork.cw.net (208.173.135.185) [AS 3561] 172 msec 176 msec 176 msec 8 agr2-loopback.NewYork.cw.net (206.24.194.102) [AS 3561] 184 msec 176 msec 180 msec 9 dcr1-so-6-1-0.NewYork.cw.net (206.24.207.53) [AS 3561] 184 msec 180 msec 184 msec 10 dcr2-loopback.SantaClara.cw.net (208.172.146.100) [AS 3561] 248 msec 248 msec 248 msec 11 bhr1-pos-0-0.SantaClarasc8.cw.net (208.172.156.198) [AS 3561] 256 msec 244 msec 244 msec 12 bhr2-ge-2-0.SantaClarasc8.cw.net (208.172.147.54) [AS 3561] 252 msec 248 msec 248 msec 13 209.1.169.177 [AS 3561] 172 msec 184 msec * route-server.cw.net>traceroute looking-glass.in.bellnexxia.net Translating "looking-glass.in.bellnexxia.net"...domain server (64.41.189.214) [OK] Type escape sequence to abort. Tracing the route to looking-glass.in.bellnexxia.net (205.207.237.50) 1 209.1.169.178 0 msec 0 msec 0 msec 2 bhr1-ge-2-0.SantaClarasc8.cw.net (208.172.147.53) 0 msec 0 msec 0 msec 3 dcr2-so-3-0-0.SantaClara.cw.net (208.172.156.197) 0 msec 4 msec 0 msec 4 dcr1-loopback.NewYork.cw.net (206.24.194.99) 76 msec dcr2-loopback.NewYork.cw.net (206.24.194.100) 72 msec dcr1-loopback.NewYork.cw.net (206.24.194.99) 68 msec 5 agr1-so-0-0-0.NewYork.cw.net (206.24.207.50) 68 msec 72 msec 68 msec 6 iar4-loopback.NewYork.cw.net (206.24.194.39) 68 msec 68 msec 72 msec 7 teleglobe.NewYork.cw.net (208.173.135.186) 208 msec 208 msec 208 msec 8 core1-newyork83-pos1-1.in.bellnexxia.net (206.108.103.193) 260 msec 332 msec 216 msec 9 core4-montreal02-pos6-3.in.bellnexxia.net (206.108.99.189) 196 msec 204 msec 200 msec 10 64.230.243.238 208 msec 296 msec 460 msec 11 core2-torontodc-pos3-1.in.bellnexxia.net (206.108.104.2) [AS 577] 432 msec 404 msec 404 msec 12 dis4-torontodc-Vlan82.in.bellnexxia.net (206.108.104.30) [AS 577] 400 msec 240 msec 440 msec 13 looking-glass.in.bellnexxia.net (205.207.237.50) [AS 577] 452 msec 236 msec 244 msec route-server.cw.net> Anyone know whats up ? ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike(a)sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike

2 2

[IP] VeriSign prepares to relaunch "Site Finder" -- calls technologists "biased"
by Gregory Hicks 09 Mar '04

09 Mar '04

From Dave Farber's IP list... --------------------------- http://www.washingtonpost.com/wp-dyn/articles/A25819-2004Feb9_2.html VeriSign Reconsiders Search Service "Site Finder was not controversial with users, 84 percent of whom said they liked it as a helpful navigation service," said Tom Galvin, VeriSign's vice president of government relations. "We continue to look at ways we can offer the service while addressing the concerns that were raised by a segment of the technical community." Galvin said that the continued opposition stems from "an ideological belief by a narrow section of the technological community who don't believe you should innovate the core infrastructure of the Internet." Critics also claim that VeriSign must run the domains as a public trust, not a profit-making opportunity. VeriSign is the sole operator of the dot-com and dot-net registries under a contract with ICANN. "I don't begrudge them their profit, but someone in an effectively regulated monopoly position shouldn't use their power for their own profit, beyond the terms under which the community gave it to them," said Steven Bellovin, co-director of the Internet Engineering Task Force's Security Area. Paul Rothstein a law professor at Georgetown University and a paid VeriSign consultant, said that the critics have some legitimate objections but others are motivated by the scientific and technology communities' "bias on policy." Still, he added, it would be tough for VeriSign to win the public relations war because its opponents are highly regarded technologists. ICANN will reserve judgment until VeriSign decides to relaunch Site Finder, said General Counsel John Jeffrey. VeriSign assured ICANN that it would give 60 to 90 days' warning to resolve any remaining technological problems, Jeffrey said. In the meantime, ICANN is waiting for a final report on Site Finder from its Security and Stability Advisory Committee. Committee Chairman Steve Crocker said he doubts that Site Finder can be changed enough that it won't threaten the Internet's underlying infrastructure. "I thought people were relieved that they took it down and it's hard to believe that there would be any quietness if they brought it back," Crocker said. <SNIP> _____Related Coverage_____ <http://www.washingtonpost.com/wp-dyn/articles//wp-dyn/articles/A57670-2003O…> VeriSign Service Spawns More Criticism (washingtonpost.com, Oct 7, 2003) <http://www.washingtonpost.com/wp-dyn/articles//wp-dyn/articles/A42107-2003O…> VeriSign Agrees To Shut Down Search Service (The Washington Post, Oct 4, 2003) <http://www.washingtonpost.com/wp-dyn/articles//wp-dyn/articles/A64437-2003S…> With Site Finder, VeriSign Sparks Internet-wide Criticism (washingtonpost.com, Sep 25, 2003) _____ICANN Headlines_____ <http://www.washingtonpost.com/wp-dyn/articles//wp-dyn/articles/A13538-2004F…> Congress Eyes Internet Fraud Crackdown (washingtonpost.com, Feb 4, 2004) <http://www.washingtonpost.com/wp-dyn/articles//wp-dyn/articles/A23641-2004J…> XO Owner Again Bids For Telecom (The Washington Post, Jan 17, 2004) <http://www.washingtonpost.com/wp-dyn/articles//wp-dyn/articles/A47327-2003D…> U.N. Sets Aside Debate Over Control of Internet (The Washington Post,Dec 9, 2003) <http://www.washingtonpost.com/wp-dyn/technology/techpolicy> Tech Policy Section ------------------------------------- Archives at: http://www.interesting-people.org/archives/interesting-people/ ------------- End Forwarded Message ------------- ------------------------------------------------------------------- Gregory Hicks | Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 555 River Oaks Pkwy M/S 6B1 | Fax: 408.894.3400 San Jose, CA 95134 | Internet: ghicks(a)cadence.com "The trouble with doing anything right the first time is that nobody appreciates how difficult it was." When a team of dedicated individuals makes a commitment to act as one... the sky's the limit. Just because "We've always done it that way" is not necessarily a good reason to continue to do so... Grace Hopper, Rear Admiral, United States Navy

35 51

sympatico administrator
by Andrew D Kirch 09 Mar '04

09 Mar '04

I need a sympatico administrator to contact me off-list in regard to a DoS attack from one of your customers. -- Andrew D Kirch | Abusive Hosts Blocking List | www.ahbl.org Security Admin | Summit Open Source Development Group | www.sosdg.org Key At http://www.2mbit.com/~trelane/trelane.key Key fingerprint = B4C2 8083 648B 37A2 4CCE 61D3 16D6 995D 026F 20CF

1 1

NANOG31 CFP
by Susan Harris 09 Mar '04

09 Mar '04

* * * * * * * * * * * * * * * * * CALL FOR PRESENTATIONS NANOG 31 GENERAL SESSION TUTORIALS CASE STUDIES OPERATIONS RESEARCH POSTER SESSION May 23-25, 2004 * * * * * * * * * * * * * * * * * The North American Network Operators' Group (NANOG) will hold its 31st meeting May 23-25, 2004, in San Francisco. The meeting will be hosted by CNET Networks and held at at the Westin St. Francis Hotel. Registration opens April 5. NANOG conferences provide a forum for the coordination and dissemination of technical information related to backbone/enterprise networking technologies and operational practices. Meetings are held three times each year, and include two days of short presentations, plus afternoon/evening tutorial sessions. The meetings are informal, with an emphasis on relevance to current backbone engineering practices. NANOG conferences draw over 450 participants, mainly consisting of engineering staff from national service providers, and members of the research and education community. For more information about NANOG meetings, schedules, and logistics, see: http://www.nanog.org ------------------------------------------------------------------------------ CALL FOR PRESENTATIONS NANOG invites presentations on backbone engineering, coordination, and research topics. Presentations should highlight issues relating to technology already deployed or soon to be deployed in core Internet backbones and exchange points. Abstracts should include a concise summary of findings to be presented in the talk. Network operators are invited to present case studies detailing their experiences with network planning and design, protocol implementation, provisioning, automation, useful tools, traffic engineering, troubleshooting, problems solved, and DoS. Vendors are encouraged to work with operators to present deployment experiences with the vendor's products. Researchers are invited to present short (10-minute) summaries of their work for operator feedback. Topics include routing, network performance, statistical measurement and analysis, and protocol development and implementation. Studies presented may be works in progress. Researchers from academia, government, and industry are encouraged to present. Previous NANOG meetings have included presentations on: - Backbone traffic engineering - Freely available configuration, management, and measurement tools - Enterprise network security, management, and route control - Impact of BGP dynamics on backbone traffic patterns - Route processor architecture - Inter-provider security and routing protocol authentication - Large-scale wireless deployment - Routing scalability in backbone infrastructures - Security issues for the Internet core - Routing policy specification and backbone router configuration - Building large-scale measurement infrastructure - Experience with differentiated services - Inter-domain multicast deployment - Backbone network failure analysis Tutorials have covered topics such as: - Troubleshooting BGP - Customer-Triggered Real-Time Blackholes - BGP/MPLS Layer 3 VPNs - MPLS Fast Reroute ------------------------------------------------------------------------------ HOW TO PRESENT Submit a detailed abstract or outline describing the presentation in email to nanog-support(a)nanog.org. The deadline for proposals is April 12, 2004. While the majority of speaking slots will be filled by April 12, a limited number of slots will be available after that date for topics that are exceptionally timely and important. Submissions will be reviewed by the NANOG Program Committee, and presenters will be notified of acceptance by April 26. Final drafts of presentation slides are due by May 12, and final versions May 19. NANOG also welcomes suggestions/recommendations for tutorials, panels, and other presentation topics. ---------------------------------------------------------------------------

1 0

RE: Source address validation
by Lumenello, Jason 09 Mar '04

09 Mar '04

I think the argument taken up for or against uRPF-loose deployment depends largely on the ability of the provider to implement it without 1) performance impact or 2) network upgrades. Argument against it on the grounds of "I can't accurately measure its value" is a smoke screen. We have implemented SAV on our customer edge routers for some time, with no ill effects, and have filtered rfc1918 on our core router interfaces facing our peering routers since early last year. We are currently discussing loose-mode application in the core as the suspenders to these two techniques. It really comes down to performance capability on a given platform, as implementation itself does not cost anything but maybe a nights sleep in a maintenance window. Can you guess what routers I have in my network? :) I fail to see how people can spend all day discussing its measurable or theoretical value, yet claim they are too busy or resource constrained to actually deploy it. So what's my excuse for waiting until now for uRPF-loose in my core? I have been happy (up until now) with just my belt. I am now reaching for the suspenders to deal with those few pieces of hardware in my network not up to the task of uRPF, and that minority percentage of attack traffic that can slip under the radar. :) Just my $.02. Back to our regularly scheduled program. Jason Lumenello IP Engineering XO Communications > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of > Paul Vixie > Sent: Sunday, March 07, 2004 3:22 PM > To: nanog(a)merit.edu > Subject: Re: Source address validation > > > [two responses here] > > -------- 1 of 2 > > fingers(a)fingers.co.za (fingers) writes: > > > why is DDoS the only issue mentioned wrt source address validation? > > > > i'm sure there's other reasons to make sure your customers can't send > > spoofed packets. ... > > yes. for example, most forms of dns cache pollution rely on the ability > to forge a udp source address on a well-timed response. several of you > have pointed out that as long as at least one edge network is free from > uPRF, then something like dnssec will still be vitally necessary -- and > that's true. but, if the places where forged-source were possible could > be enumerated, then the fact of the forgery would be useful to a victim. > right now those places are innumerable, and so, anonymity is complete. > > -------- 2 of 2 > > hackerwacker(a)cybermesa.com (James Edwards) writes: > > > uRPF, strict mode, is how I control 1000+ DSL pvc's from leaking private > > address space via broken NAT. ... > > so what you're saying is, these packets (captured on one of the f-root > servers just now) wasn't from your network? THANKS! (anybody else here > want to claim this slackage?) > > tcpdump: listening on fxp0 > 21:06:42.331994 192.168.15.3.1053 > 192.5.5.241.53: 15396 A? > wustat.windows.com. (36) > 21:06:42.349184 10.1.0.15.1025 > 192.5.5.241.53: 6182 NS? . (17) > 21:06:42.427980 10.10.1.1.1041 > 192.5.5.241.53: 53830 NS? . (17) > 21:06:42.559860 10.19.1.101.1032 > 192.5.5.241.53: 8434 [1au] A? > SPPOLCD01.POL. (42) > 21:06:42.688972 192.168.7.76.1036 > 192.5.5.241.53: 14986 A? > rsthost2.ods.org. (34) > 21:06:43.793914 192.168.160.252.1024 > 192.5.5.241.53: 28233 MX? > jimaz.cz. (26) (DF) > 21:06:44.048702 10.10.10.250.53 > 192.5.5.241.53: 2051 A? > tock.usno.navy.mil. (36) > 21:06:44.123787 10.101.58.16.1120 > 192.5.5.241.53: 9741 PTR? > 169.16.187.208.in-addr.arpa. (45) > 21:06:44.394578 10.8.0.22.1036 > 192.5.5.241.53: 15001 A? > mail.inf101.net. (33) > 21:06:44.578893 10.8.0.22.1036 > 192.5.5.241.53: 15002 MX? ezrs.com. (26) > 2027 packets received by filter > > note that this particular box has dropped a fair amount of this crud since > its last reboot: > > rule# packets octets ----------------rule----------------- > > 00400 27149821 1707500202 deny ip from 10.0.0.0/8 to any in > 00500 1710989 109992242 deny ip from 172.16.0.0/12 to any in > 00600 6144955 392168290 deny ip from 192.168.0.0/16 to any in > > 9:16PM up 37 days, 15:55, 1 user, load averages: 0.04, 0.01, 0.00 > > also note that it's only one of about fifty similar servers. i don't have > an easy way to aggregate the slackage numbers yet, but i sure would like > them to be zero or at least lower. (and, for my part in rfc 1918, i now > beg > forgiveness.) > > > Based on my limited experience with all of this it seems the place for > > uRPF is not at the core (core in the context of the Internet backbone) > > but at the customer edge, where the problem starts. > > that's sort of what http://www.icann.org/committees/security/sac004.txt > says. > -- > Paul Vixie

1 0

RE: Mass de-aggregation?
by Burton, Chris 09 Mar '04

09 Mar '04

I have not seen a major jump in routes (AS8137) I have about 131380 Prefixes for BGP. Chris Burton Network Engineer Walt Disney Internet Group: Network Services The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact Walt Disney Internet Group at 206-664-4000. -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Grant A. Kirkwood Sent: Tuesday, March 09, 2004 9:22 AM To: nanog(a)merit.edu Subject: Mass de-aggregation? Has anybody noticed a dramatic (~10k prefixes) jump in the routing table size? I'm getting about 10k more routes from all of my transits (3549, 2914, 6453) than I was yesterday. Cheers, Grant -- Grant A. Kirkwood - grant(at)tnarg.org Fingerprint = D337 48C4 4D00 232D 3444 1D5D 27F6 055A BF0C 4AED

1 0

netsky issue.
by Jamie Reid 09 Mar '04

09 Mar '04

If you have a look at http://vil.nai.com/vil/content/v_101083.htm There is a list of IP addresses that are nameservers which are hard-coded into the worm. It spreads by e-mail (currently) and thus it can be blocked using anti-virus filters. My concern is that these addrs are all for nameservers, which could be authoritative for other domains, and by blocking these servers any domains they host could be effectively put out of commission. I am not aware of an easy way to find out all the domains registered to a particular nameserver, and the trend of blocking addrs that appear in worm code is starting to concern me a bit. It is not indicated how blocking these servers will have an appreciable effect on the worm propagation (unless it gets a second stage from them), and I wonder if anyone else has similar concerns, or an opinion on whether these IP addresses should actually be blocked. Regards, -j -- Jamie.Reid, CISSP, jamie.reid(a)mbs.gov.on.ca Senior Security Specialist, Information Protection Centre Corporate Security, MBS 416 327 2324

2 1

Mass de-aggregation?
by Grant A. Kirkwood 09 Mar '04

09 Mar '04

Has anybody noticed a dramatic (~10k prefixes) jump in the routing table size? I'm getting about 10k more routes from all of my transits (3549, 2914, 6453) than I was yesterday. Cheers, Grant -- Grant A. Kirkwood - grant(at)tnarg.org Fingerprint = D337 48C4 4D00 232D 3444 1D5D 27F6 055A BF0C 4AED

2 1

Re: Verification required for steve@blueyonder.co.uk, protected by 0Spam.com.
by Michael.Dillon＠radianz.com 09 Mar '04

09 Mar '04

>> This is the future of e-mail, if something better at spam suppression >> doesn't come along. >Pace en requiat email Please! Spare us the fractured Latin. Requiescat in pace - May he/it rest in peace. Requiescat - 3rd person singular subjunctive of "requiescere" in - same as English preposition "in" pace - ablative singular of "pax" indicating that in refers to position rather than movement. Personally I think you should have said Requiescas in pace o email which means "Oh email, may you rest in peace"

3 2

Re: Verification required for steve@blueyonder.co.uk, protected by 0Spam.com.
by James Edwards 09 Mar '04

09 Mar '04

NO ! On Mon, 2004-03-08 at 05:52, verify(a)0spam.com wrote: > ATTENTION! > A message you recently sent to a 0Spam.com user with the subject "Re: Source address validation (was Re: UUNet Offer..." was not delivered because they are using the 0Spam.com anti-spam service. Please click the link below to confirm that this is not spam. When you confirm, this message and all future messages you send will automatically be accepted. > > http://www.0spam.com/verify.cgi?user=1079785893&verify=568107 > > > ======================================== > This is an automated message from 0Spam.com. > Please do not reply to this Email. > > Looking for a free anti-spam service? > Visit us at http://www.0spam.com to find out more.

8 8