April 2004 - NANOG - lists.nanog.org

Re: TCP/BGP vulnerability - easier than you think
by Crist Clark 22 Apr '04

22 Apr '04

David Luyer wrote: [snip] > With ipsec, you have crypto overhead before you have any opportunity > to do the basic sanity check. Minor point, but with IPsec, the 32-bit SPI and the 32-bit replay counter are very low cost ways to drop the majority of traffic from a flood of random junk with no crypto calculations. You actually have more bits with AH or ESP than with TCP. The 32-bit SPI must be an exact match like the two 16-bit port fields, and you have 32-bits of sequence number in both, but the TCP window is much larger than the IPsec window (usually 6-bit by default) leaving you more bits to check. -- Crist J. Clark crist.clark(a)globalstar.com Globalstar Communications (408) 933-4387

1 0

RE: asymmetric/peer RPF [RE: TCP/BGP vulnerability - easier than you think]
by Michel Py 22 Apr '04

22 Apr '04

From: Pekka Savola [mailto:pekkas@netcore.fi] > When discussing RPF towards peers or w/ asymmetric > paths, I'd recommend to read RFC 3704 I have, this is a very good document. > If your prefix filter stops a neighbor from > advertising a prefix, maybe you would have to > revise your prefix filtering policy (e.g., > revise it more often, get notice if the peer > sends you something you're filtering, tell to > peers not to advertise anythnig that's not > properly in the routing DB's, etc.)? This > doesn't seem so bad to me... I agree, but there are many people that think it is very bad. Trouble is, using RPF has a great potential for problems as it will drop traffic (which is the reason it's not being used in the first place). The point I was trying to make is as follows: if you don't use RPF (which is probably the case) then there is no harm in prefix-filtering peers (if you are not a tier-1) even if the prefix-filters are not perfect. Needless to say, there is no point prefix-filtering if your filters are completely messed up. Michel.

1 0

RE: Backbone IP network Economics - peering and transit
by Michel Py 22 Apr '04

22 Apr '04

> Stephen J. Wilcox wrote: > I assume Vijay meant the cost of a port for private > peering, in which case if you private with all your > peers and you have a lot of small peers thats going > to be a lot of cost for a few kbps of traffic I'm having trouble parsing this. You connect your FE or GE port to an ISL/802.11q trunk to the colo's/IX switch. Then either a)everyone is in the same broadcast domain (dumb but no config), or there's a VLAN on that trunk from/to you to your peer(s). Save for the colo's/IX administrative/xconnect fee, where's the "lot of cost"? Michel.

2 1

snmp vuln
by Mikael Abrahamsson 22 Apr '04

22 Apr '04

http://www.cisco.com/warp/public/707/cisco-sa-20040420-snmp.shtml This one seems much worse than the TCP RST problem. -- Mikael Abrahamsson email: swmike(a)swm.pp.se

3 2

RE: tcp bgp vulnerability looking glass and route server issues.
by Smith, Donald 22 Apr '04

22 Apr '04

By providing the 4tuple ip/port dst/src it makes guessing easier. As for production vs non-production I suspect we have a mix I did not even begin to audit them. I few spot checks is all I had time for. I would welcome any assistence in auditing vulnerable looking glass/route servers and would personally urge any LG/RS owners that were too verbose to lock them down a little. Something I wasn't looking for but found was a full open connect proxy. With that you can connect to any ip on any port nice way to scan someelses network and hide your source. I also found a few that allowed show flash:. Personally the exact image we run on a router isn't something I would want to publish:-) Will locking down looking glass/route servers stop the tcp vulnerablity? NO. Does providing information assist in trouble shooting a bgp issue? NO. I tend to error on the side of caution. Donald.Smith(a)qwest.com GCIA http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xAF00EDCC I reserve the right to be wrong and exercise as required. -----Original Message----- From: Lane Patterson [mailto:lpatterson@equinix.com] Sent: Wednesday, April 21, 2004 5:22 PM To: Smith, Donald; nanog(a)merit.edu Subject: RE: tcp bgp vulnerability looking glass and route server issues. Sensitivity: Private While I agree that publicly open route-views routers should not allow display of "sho ip bgp nei" information, this is only giving away 4-tuple info regarding non-production BGP sessions, right? So folks could potentially flap the route-views sessions, but this will not affect any production routing in the data path. If any folks are allowing "sho ip bgp nei" via looking glass interface to a production router, then yes, that is a problem. I haven't seen any. > -----Original Message----- > From: Smith, Donald [mailto:Donald.Smith@qwest.com] > Sent: Tuesday, April 20, 2004 1:38 PM > To: nanog(a)merit.edu > Subject: tcp bgp vulnerability looking glass and route server issues. > Sensitivity: Private > > > > John Fraizer author of MRLG one of the looking glass implementations > has updated his code to fix a flaw that provided too much information. > > MRLG-4.3.0 is available at: > Available here: ftp://ftp.enterzone.net/looking-glass/CURRENT/ > > Some route servers also provide too much info. > This audit was performed yesterday so if you have already > fixed this issue please ignore:-) > Part of this issue is the fact that some router servers > provide too much information. > Without knowing the source/destination ports and IP's this is > still a difficult vulnerability to exploit. > > From this URL I did a quick audit. > http://www.traceroute.org/#Route%20Servers > I did NOT look at the looking glass URLs just the route servers. > > This is the list of open route servers I did a quick audit on. No > connection means I was unable to connect to it. Not misconfigured > meant sho ip bgp nei did NOT work. Sho ip bgp nei gives full ports/ips > means what you think it means. You have may want to see if any of them > are yours of if you peer / are the upstream for any of them. > > "Route Servers" > > "telnet://ner-routes.bbnplanet.net" BBN Planet NER route monitor > No connection > > "telnet://route-server.belwue.de" BelWue (AS553) > Sho ip bgp nei gives full ports/ips. > > "telnet://route-views.on.bb.telus.com">Telus - East Coast (AS852) Sho > ip bgp nei gives full ports/ips. > > telnet://route-views.ab.bb.telus.com" Telus - West Coast (AS852) Sho > ip bgp nei gives full ports/ips. > > "telnet://route-server.cerf.net">CerfNet Route Server > (AS1838)</A></LI> > Sho ip bgp nei gives full ports/ips. > > "telnet://route-server.ip.tiscali.net">Tiscali (AS3257)</A></LI> Sho > ip bgp nei gives full ports/ips. > > "telnet://route-server.gblx.net">Global Crossing (AS3549)</A></LI> Not > misconfigured:-) > > "telnet://route-server.savvis.net/">SAVVIS Communications > (AS3561)</A></LI> > Sho ip bgp nei gives full ports/ips. > > "telnet://public-route-server.is.co.za" TARGET=NEW>Internet > Solutions (AS3741)</A></LI> > Sho ip bgp nei gives full ports/ips. > > "telnet://route-server-ap.exodus.net">Exodus Communications > Asia (AS4197)</A></LI> > No connection > > "telnet://route-server.as5388.net">Planet Online (AS5388)</A></LI> Sho > ip bgp nei gives full ports/ips. > > "telnet://route-server.opentransit.net">Opentransit (AS5511)</A></LI> > Not misconfigured:-) > > "telnet://tpr-route-server.saix.net">South African Internet > eXchange SAIX (AS5713)</A></LI> > Not misconfigure:-) > > "telnet://route-server.gt.ca">GT Group Telecom (AS6539)</A></LI> Sho > ip bgp nei gives full ports/ips. > > "telnet://route-server.as6667.net">EUNet Finland (AS6667)</A></LI> Sho > ip bgp nei gives full ports/ips. > > "telnet://route-server.he.net">Hurricane Electric (AS6939)</A></LI> > Sho ip bgp nei gives full ports/ips. > > "telnet://route-server.ip.att.net">AT&T (AS7018)</A></LI> > No connection > > "telnet://route-views.optus.net.au">Optus Route Server > Australia (AS7474)</A></LI> > Sho ip bgp nei gives full ports/ips. > > "telnet://route-server.wcg.net">Wiltel (AS7911)</A></LI> > Sho ip bgp nei gives full ports/ips. > > "telnet://route-server.colt.net">Colt Internet (AS8220)</A></LI> Sho > ip bgp nei gives full ports/ips. > > "telnet://route-server-eu.exodus.net">Exodus Communications > Europe (AS8709)</A></LI> > No connection > > "telnet://route-views.bmcag.net">Broadnet mediascape > communications AG (AS9132)</A></LI> > Not misconfigured:-) > > "telnet://route-server-au.exodus.net">Exodus Communications > Australia (AS9328)</A></LI> > No connection > > "telnet://route-server.manilaix.net.ph">Manila Internet > Exchange, Philippines (AS9670)</A></LI> > Sho ip bgp nei gives full ports/ips. > > "telnet://route-server.east.attcanada.com">ATT Canada - East > (AS15290)</A></LI> > Sho ip bgp nei gives full ports/ips. > > "telnet://route-server.west.attcanada.com">ATT Canada - West > (AS15290)</A></LI> > Sho ip bgp nei gives full ports/ips. > > "telnet://route-server.ip.ndsoftware.net">NDSoftware > (AS25358)</A></LI> > Sho ip bgp nei gives full ports/ips. > > "telnet://route-server.loudpacket.net">Loud Packet (AS27276)</A></LI> > No connection. > > "telnet://route-server.as28747.net/">RealROOT (AS28747)</A></LI> No > connection > > "telnet://route-views.oregon-ix.net">Oregon-ix.net Route > Server</A></LI> > Sho ip bgp nei appears it WOULD provide full ports/ips if > they had any? The command executed but came back empty!!?? > This one can be used as a proxy bounce (connect ip port) too:-( > > "telnet://route-server.utah.rep.net">Utah Regional Exchange > Point Route Server</A></LI> > Sho ip bgp nei gives full ports/ips. > > "telnet://www.netlantis.org">The NetLantis Project Route > Server</A></LI> > Not misconfigured. > > > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xAF00EDCC > pgpFingerPrint:9CE4 227B B9B3 601F B500 D076 43F1 0767 AF00 EDCC > Increased trust is received by not violating the trust you have > received. >

1 0

RE: Microsoft XP SP2 (was Re: Lazy network operators - NOT)
by Drew Weaver 22 Apr '04

22 Apr '04

-- Jeff said -- Patches either need to be of a size that a dialup user doesn't have to be dialed in for 24 hours to download and install them. Or .iso's should be available for ISP's to download, turn into CD's and distribute as appropriate. Wouldn't that be nice for a dialup user - getting Windows Update on a CD-ROM from their ISP? To which I reply: It is somewhat unreasonable to think that ISPs should be responsible for the security of its users' systems on a systematic basis. Another reason the idea of a 'CD with updates' most likely wouldn't be effective is because by the time the ISP produced the CD, the user got the CD, and installed it, the patches would most likely not be the most recent available. Also, do you realize how much the 'average technical school graduate type' makes just from acquaintances who complain that their computers are slow, by simply removing whatever "flavor of the month backdoor spam proxy virus" I bet a good number of 'tech service calls' that companies such as PC On Call and people who service residences get could've been avoided by patching in a reasonable time period. However, awhile ago we tried an idea of sending out E-Mail alerts to our customers whenever a critical update of "Remote execution" or worse was released. We found that most of our users were annoyed by this, a different time we used a network sniffing tool to find a few dozen handfuls of your average home Dial-Up users who were infected with various malicious agents (I.e. Nimda, et cetera) and we actually contacted those users, to let them know and again we were met with more hostility. From this interesting pattern I would surmise that users want their ISPs to be hands-off unless the problem that they're causing is effecting them directly. End users on the Internet see their connectivity as a right, and not a privilege. I remember when I was 13 (that was only 11 years ago) and I signed up for my Freenet account at the Columbus Public Library (I believe it was, ? still is? Through OSU), they really made me feel like it was a privilege to be using the Internet, and I honored that. Its just difficult to explain from a professional level what the effects these peoples' behavior (or lack there of) is having on the rest of the community. Think of it like people who drive monster SUV's, they can afford the gas, and the insurance so they don't believe that the harm that these beasts do to our environment matter, because again its their god given right to drive them. -Drew

9 12

Re: Ordering Windows Security Update CD (was Re: Microsoft XP SP2)
by Alexei Roudnev 22 Apr '04

22 Apr '04

It depends... if you use FreeBSD with port system, for example - it is safe enough (esp. if make a pause between 'make' and 'make install' in a few days or a week. and read mail lists about possible problems). > dowloading opensource software is safe? -CP

1 0

RE: TCP/BGP vulnerability - easier than you think
by Michel Py 22 Apr '04

22 Apr '04

> Aditya wrote > I sure hope there are no asymmetric paths on the Internet > that will bite you when you turn on strict RPF on your > peering interfaces </sarcasm> > Seriously, if you do turn RPF on on peering interfaces, > please let your peers know (plea from circa 1999) Ah, I was waiting for someone to say something like this and make my point, thank you. In the topic I was arguing earlier (about prefix filtering peers, underlining the fact that imperfect filtering would not cause traffic loss) it does indeed create asymmetry and prohibits the use of RPF. Michel.

2 1

Re: tcp bgp vulnerability looking glass and route server issues.
by Troy Davis 22 Apr '04

22 Apr '04

On Wed, Apr 21, 2004 at 04:21:51PM -0700, Lane Patterson <lpatterson(a)equinix.com> wrote: > While I agree that publicly open route-views routers should not allow > display of "sho ip bgp nei" information, this is only giving away 4-tuple > info regarding non-production BGP sessions, right? So folks could A few cases where a non-production session source port suggests same for production sessions, assuming the production router opened the connections: - Reachability for a non-production session can depend on the same interface(s) as production session(s), so they may use sequential ports after an interface flap. - When the source port is near the start of the range (ie, 11020), other sessions with that router may have last reset when it reloaded. Troy

1 0

Re: TCP/BGP vulnerability - easier than you think
by John Kristoff 22 Apr '04

22 Apr '04

On Wed, 21 Apr 2004 21:00:55 +0100 (IST) Paul Jakma <paul(a)clubi.ie> wrote: > risk of crypto DoS than compared to the simple BGP TCP MD5 hack. The > risk is due to MD5, not IPSec :). I would say the risk is due to implementation. If the vendor's gear vomits quicker due to a resource consumption issue in handling MD5, is this really a problem with MD5? These issues can usually be fixed by simply improving the scaling properties of the implementation that may be required during adverse conditions. John

2 1