February 2001 - Test - lists.nanog.org

BGP Question - how do work around pigheaded ISPs
by Roisman, Dani 27 Feb '01

27 Feb '01

Hey there. Due to the pigheadedness of a specific ISP (which I wil *not* allude to in any way, shape, or form, so don't bother asking), and in the interest of conserving IP addresses, I've been faced with quite a challenge. - The Premis: A parent organization has an unused /16 of address space, for arguments sake, let's say it's 172.16.0.0/16. It's out of the old "class B" address range. Two groups within the organization want to bring up independant Internet datacenters, and need /18 of address space, each. Since the parent organization owns an unsed /16, the IP registry refuses to give the child organizations any address space - they insist all address blocks assigned to the parent organization be used, first. ISPph (ph=pigheaded) has a BGP policy that filters out all routes in 128.0.0.0/2 longer than /16. - The network: One group has Internet connectivity to 2 Tier1 ISPs (ISPa and ISPb) in North America. They announce out 172.16.0.0/18 to both ISPs from AS65001. The other group gets Internet connectivity to ISPc and ISPc in South America. They announce 172.16.64.0/18 to their ISPs from AS65002. There is no private network connectivity or backbones between the 2 companies. - The result: ISPph blocks out the /18s at the peering connections to ISPa, ISPb, ISPc, and ISPd. So, customers of ISPph cannot see servers on AS65001 or AS65002. - The workaround: We announce 172.16.0.0/16 as well as 172.16.0.0/18 from AS65001 to ISPa and ISPb. In our preliminary testing, we've found that what happens is that ISPph would route traffic to 172.16.64.0/18 to ISPa (or ISPb, but we'll assume ISPa has a better connection to ISPph), because it learned the 172.16.0.0/16 route from there. ISPa is hearing the *more specific* /18 from ISPc and ISPd, so it transits the traffic over to ISPc, which then delivers it to the South American site. - Questions: 1) is there a reason to announce the /16 from both ASs? Is that "legal?" 2) under normal situations (assume no link failures) would this cause any problem? 3) Is there a link failure scenario that would cause the /16 to create a blackhole for the 172.16.64.0/18 network? 4) Would you recommend this as a fix? Of course, it would make ISPa transit for ISPph, but they're pigheaded enough to make the Internet suck that way. Thanks for your time! ---- Dani Roisman droisman(a)station.sony.com

11 12

RE: 64.0.0.0/8 etc. [was: Re: BGP Question - how do work around.. .]
by Paul Schultz 27 Feb '01

27 Feb '01

I think we're talking about filtering the 64.0.0.0/8 prefix, EXACT prefix. That wouldn't block anyone from reaching anything as long as you only filter the /8 and not any of the more specific advertisements. My company's got a /16, a /17, and a /18 out of 64/8 and I *WANT* people to filter out the annoying 64.0.0.0/8 prefix that much of my traffic may be destined for if something explodes on my end and my routes get withdrawn. Paul -----Original Message----- From: Shawn McMahon [mailto:smcmahon@eiv.com] Sent: Tuesday, February 27, 2001 6:25 PM To: nanog(a)merit.edu Subject: Re: 64.0.0.0/8 etc. [was: Re: BGP Question - how do work around...] On Tue, Feb 27, 2001 at 08:01:46AM -0800, Christian Nielsen wrote: > > > For 64.0.0.0/8 this seems to have happened in the meantime... but now > > there's a route for 62.0.0.0/8 (the RIPE equivalent of 64.0.0.0/8), sigh. > > i dont know why you even allow 64/8 and/or 62/8 into your network. Filter > them... Aren't many Earthlink dialups in 64/8? Filtering that would mean his employees couldn't get Sprint DSL, and prevent millions of potential customers from reaching his web servers. That's not smart business. It's called "cutting off your nose to spite your face."

1 0

Re: Warning: Cisco RW community backdoor.
by SMcGrath＠dhhs.state.nh.us 27 Feb '01

27 Feb '01

Same here Cisco account manager sent us a notification of the bug. Scott Adrian Chadd <adrian(a)creative.net.au>@merit.edu on 02/27/2001 08:11:31 AM Sent by: owner-nanog(a)merit.edu To: Jim Duncan <jnduncan(a)cisco.com> cc: nanog(a)merit.edu Subject: Re: Warning: Cisco RW community backdoor. On Tue, Feb 27, 2001, Jim Duncan wrote: > As a side note, this is a problem with the standards. In particular, > how the standards _require_ a function to be implemented. <TONGUE LOCATION="CHEEK"> Now, if only all other standards were implemented so faithfully by all the vendors .. </TONGUE> :-) (sorry, couldn't resist.) And yes, we received a call at work from our cisco rep outlining the bug a few days ago. That was really nice of them. Well done guys. Adrian -- Adrian Chadd "The fact you can download a 100 megabyte file <adrian(a)creative.net.au> from half way around the world should be viewed as an accident and not a right." -- Adrian Chadd and Bill Fumerola

1 0

Warning: Cisco RW community backdoor.
by Simon Lyall 27 Feb '01

27 Feb '01

It appears that 2500 are not affected. The fix below doesn't work on 11.1 and 11.2 , you have to turn snmp off by the looks. have fun. ----- Forwarded message from "James A. T. Rice" <jamesr(a)rd.bbc.co.uk> ----- Date: Tue, 27 Feb 2001 00:39:38 +0000 (GMT) From: "James A. T. Rice" <jamesr(a)rd.bbc.co.uk> X-Sender: <jamesr@inet15> To: <members(a)lonap.net>, <ops(a)linx.net> Subject: Warning: Cisco RW community backdoor. Precedence: bulk If your router responds to `snmpwalk router.isp.net.uk ILMI`, you probabally will want to do the following to disable it: conf t snmp-server community ILMI RO 99 access-list 99 deny any log (pick another spare access-list if 99 isn't available) If you dont, assuming your ios/hardware combination supports it, (most of the bigger routers do) anyone can do things like: `snmpset router.isp.net.uk ILMI system.sysName.0 s \ "ALL YOUR ROUTER ARE BELONG TO US."` Thats a harmless example. You can do almost anything with RW snmp. Warm Regards James -- James A. T. Rice | Email: jamesr(a)rd.bbc.co.uk Internet Operations Engineer | Phone: 01737 839 737 BBC Internet Services, Kingswood Warren, Tadworth, Surrey, UK. ----- End forwarded message ----- --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

9 12

Re: Warning: Cisco RW community backdoor.
by Sean Donelan 27 Feb '01

27 Feb '01

> ----- Forwarded message from "James A. T. Rice" <jamesr(a)rd.bbc.co.uk> ----- > If your router responds to `snmpwalk router.isp.net.uk ILMI`, you > probabally will want to do the following to disable it: > conf t > snmp-server community ILMI RO 99 > access-list 99 deny any log > (pick another spare access-list if 99 isn't available) should be RW not RO Anyone with a Smartnet contract have a response from Cisco yet? I really need to get my own Smartnet number.

6 5

Re: All your NIC handles are belong to us
by Ukyo Kuonji 27 Feb '01

27 Feb '01

Only if it is setup that way. Majordomo will trigger fitters off of erveral things. It's default it to trigger off on administration commands, but other can be configured. I have configured filters for HTML coded messages and other stuff in the lists I host. --- Opinions in this email are the personal opinions of the author and are not associated with author's employer. This email account is a not the regular email account of the author and is being used for the protection of the employer. -----Original Message----- From: Kai Schlichting To: nanog(a)merit.edu Subject: Re: All your NIC handles are belong to us *knock knock* ALL YOUR NIC HANDLES ARE BELONG TO US. The mystery with posts going to nowhere has re-appeared. No bounces due to NANOG-post. No moderation notice. Nothing. Does Majordomo mind Subjects starting with "OT:" ? _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com

1 0

Re: All your NIC handles are belong to us
by Kai Schlichting 27 Feb '01

27 Feb '01

*knock knock* ALL YOUR NIC HANDLES ARE BELONG TO US. The mystery with posts going to nowhere has re-appeared. No bounces due to NANOG-post. No moderation notice. Nothing. Does Majordomo mind Subjects starting with "OT:" ? Feb 26 18:10:44 sonet sendmail[27445]: SAA27445: from=<kai(a)pac-rim.net>, size=2083, class=0, pri=32083, nrcpts=1, msgid=<6669287802.20010226180952(a)conti.nu>, bodytype=8BITMIME, proto=ESMTP, relay=localhost.conti.nu [127.0.0.1] Feb 26 18:10:45 sonet sendmail[27447]: SAA27445: to=<nanog(a)merit.edu>, ctladdr=<kai(a)pac-rim.net> (100/101), delay=00:00:01, xdelay=00:00:01, mailer=esmtp, relay=mail.merit.edu. [198.108.1.41], stat=Sent (Ok: queued as A13D45DDA4) Original post at: http://www.conti.nu/nanog/nanog-20010226.txt bye,Kai -- "Just say No" to Spam Kai Schlichting New York, Palo Alto, You name it Sophisticated Technical Peon Kai's SpamShield <tm> is FREE! http://www.SpamShield.org | | LeasedLines-FrameRelay-IPLs-ISDN-PPP-Cisco-Consulting-VoiceFax-Data-Muxes WorldWideWebAnything-Intranets-NetAdmin-UnixAdmin-Security-ReallyHardMath

1 0

Re: Warning: Cisco RW community backdoor.
by owen＠dixon.delong.sj.ca.us 27 Feb '01

27 Feb '01

It applies to 12.0 and later, so testing it on an 11.x router doesn't help. Owen > > > It appears that 2500 are not affected. > > The fix below doesn't work on 11.1 and 11.2 , you have to turn snmp off by > the looks. > > have fun. > > ----- Forwarded message from "James A. T. Rice" <jamesr(a)rd.bbc.co.uk> ----- > > Date: Tue, 27 Feb 2001 00:39:38 +0000 (GMT) > From: "James A. T. Rice" <jamesr(a)rd.bbc.co.uk> > X-Sender: <jamesr@inet15> > To: <members(a)lonap.net>, <ops(a)linx.net> > Subject: Warning: Cisco RW community backdoor. > Precedence: bulk > > If your router responds to `snmpwalk router.isp.net.uk ILMI`, you > probabally will want to do the following to disable it: > conf t > snmp-server community ILMI RO 99 > access-list 99 deny any log > (pick another spare access-list if 99 isn't available) > > If you dont, assuming your ios/hardware combination supports it, > (most of the bigger routers do) anyone can do things like: > `snmpset router.isp.net.uk ILMI system.sysName.0 s \ > "ALL YOUR ROUTER ARE BELONG TO US."` > Thats a harmless example. You can do almost anything with RW snmp. > > Warm Regards > James > > -- > James A. T. Rice | Email: jamesr(a)rd.bbc.co.uk > Internet Operations Engineer | Phone: 01737 839 737 > BBC Internet Services, Kingswood Warren, Tadworth, Surrey, UK. > > ----- End forwarded message ----- > --------- > To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz > where the body of your message reads: > unsubscribe nznog > > > > >

1 0

Re: Warning: Cisco RW community backdoor.
by Jim Duncan 27 Feb '01

27 Feb '01

Sean Donelan writes: > > Anyone with a Smartnet contract have a response from Cisco yet? I really > need to get my own Smartnet number. > No need. I'll post the advisory as soon as I can get it ready. It's probably going to be another hour or two. The only reason I've paused to post this response is to ask everyone to wait for the advisory and stop experimenting. This one is really strange in the interactions with various releases, features, and hardware. The real problem is that if you try enough different combinations of config commands to shut off the problem, you'll put your ATM connections in a very poor state (that's the best way I can put it). As a side note, this is a problem with the standards. In particular, how the standards _require_ a function to be implemented. Please wait for the advisory. Thanks! Jim -- Jim Duncan, Product Security Incident Manager, Cisco Systems, Inc. <http://www.cisco.com/warp/public/707/sec_incident_response.shtml> E-mail: <jnduncan(a)cisco.com> Phone(Direct/FAX): +1 919 392 6209

3 2

RE: Warning: Cisco RW community backdoor.
by Martin, Christian 27 Feb '01

27 Feb '01

> And yes, the only tree I could touch was system. Nothing > else, read or > write. Folks, I expect most of the community to know this, but just in case. A walk of the enterprises.cisco tree returns null as well(fortunately). UCD snmpwalk (and others) do not traverse the enterprise tree by default. Regards, chris > > -j > > -- > -Jonathan Disher > -Sr. Systems and Network Engineer, Web Operations > -Internet Pictures Corporation, Palo Alto, CA > -[v] (650) 388-0497 | [p] (877) 446-9311 | [e] jdisher(a)eng.ipix.com > >

1 0