April 2004 - Test - lists.nanog.org

Ad blocking with squid
by Paul Khavkine 21 Apr '04

21 Apr '04

Hi Folks. Anyone doing ad blocking with Squid cache engine out there ? Is there a comprehensive URL list out there on the net ? Thanx Paul ************************************************ Paul Khavkine Network Administrator DISTRIBUTEL Communications. 740 Notre Dame West, Suite 1135 Montreal, Quebec, Canada, H3C 3X6 1-514-877-5505 x 263 http://www.distributel.net ************************************************

6 7

RE: TCP RST attack (the cause of all that MD5-o-rama)
by Michel Py 21 Apr '04

21 Apr '04

>> James wrote: >> now the question is... would this also affect single-hop >> bgp sessions? my understanding would be no, as single-hops >> require ttl set to 1. > Simon Lockhart wrote: > All it requires is for the TTL to be 1 (or 0, I can't > remember which) when it's received. Just launch your > packets with a TTL of the number of hops between you > and the victim, and that's that bit sorted... That's not the way I read it at all. The way I read it is that the TTL of the packet has to be equal or _greater_ than 254 (or 255). Since you can't set the TTL to a value greater than 255 when sending the forged packet, it means that the spoofer sending a packet from 10 hops away will have a TTL of 245 at most, and will be discarded. As nobody has figured out how to prevent the TTL to be decremented by each of the hops on the way, it works. Michel.

1 0

Re: The Uneducated Enduser (Re: Microsoft XP SP2 (was Re: Lazy network operators - NOT))
by Dr. Jeffrey Race 21 Apr '04

21 Apr '04

On Tue, 20 Apr 2004 09:21:02 -0500 (CDT), Adi Linden wrote: >> Since many gateway service providers will not prevent insufficiently >> skilled users from connecting to the internet and injuring others, the >> only remaining solution, as far as I can see, is cutting connectivity >> with those enablers. That is the proposal I advanced in >> <http://www.camblab.com/misc/univ_std.txt>. >And once again the you're punishing the victim. Let's not forget that the >uneducated end user is tricked into doing things that are not good for >them or the rest of the internet connected world. >Unfortunately the only feasible and readily available computer solution >for the uneducated end user is a single available operating system. >Everyone is at the mercy of this product with all its flaws and downfalls. >Instead of continually blaming the uneducated end user how about providing >tools to the uneducated end user that can be used to connect to the >internet without becoming a liability. A toaster with keyboard an monitor... I beg to clarify that I am not "blaming" anyone; I am describing a system with known input-output properties and internal structures. We know how this system behaves in terms of technology and human behavior, and we know what to do to the inputs to change the outputs. If you choose to smoke, you get cancer. Same with spam. If you don't want to have spam, you have to change some behaviors. Some people will be inconvenienced. Life is full of such choices. As for the specifics of your comments, I could not disagree more, but it is a philosophy of life that distinguishes our views, not the analysis of the problem. I believe (like a lot of other New Englanders and even some from California) that people must assume responsibility for their actions. If responsibility is not enforced, society collapses (into e.g. the kind of chaos we see on the internet.) In 2004 no one is "tricked" into using rubbish software; there are plenty of alternatives, and the rubbishy nature of the leading OS is in almost every day's newspaper. It's a choice people make, like overeating and gaining weight. No one is there with a gun forcing people to gain weight. As for "uneducated", the solution is the same as for bad drivers: training. If you are a threat to the rest of the internet because of your ignorance (or irresponsibility) then you do not qualify for connectivity, just as bad drivers don't get licenses, bad credit risks don't get credit, and drunk airline pilots stop flying. To repeat: the solution to spam is to apply rigorously the same rules to the internet as are used everywhere else in society. It is simple, it pays for itself, it works, and it works immediately. Some people will be upset, like the smokers who have to go outside for a puff or even give up their habit. However the result is better for EVERYONE including "the uneducated". Jeffrey Race

5 4

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

21 Apr '04

> Adam Rothschild wrote: > Which begs the question, what is one to do, shy of > moving (private) peering/transit/customer /31's and > /30's into non-routable IP space, which opens up an > entirely new can of worms? Insist that the peer uses "ip verify unicast reverse-path" on all interfaces, or similar command for other vendors. > Fact of the matter is, MD5 computation/verification > is not cheap, and many Cisco and Juniper platforms > aren't designed to handle a barrage of MD5-hashed > TCP packets. All things considered, I think MD5 > authentication will lower the bar for attackers, not > raise it. I'm sure code optimizations could fix > things to some degree, but that's just not the case > today. Certainly the best reason not to MD5 I have heard so far. > Mikael Abrahamsson wrote: > http://www.cisco.com/warp/public/707/cisco-sa-20040420-snmp.shtml > This one seems much worse than the TCP RST problem. Relatively easy to filter though. Michel.

3 2

RE: Winstar says there is no TCP/BGP vulnerability
by Peering 21 Apr '04

21 Apr '04

> If you have a fully redundant internal BGP, and are running all > 12.2S/12.3/12.2T, then you can rather safely do the internal BGP > passwords without a customer notice, expecting no session drop but > knowing if one did you'd have routes via a second BGP reflector > anyway. Just an FYI, when we changed sessions that had full routing tables on them at 2am CST with barely any traffic, it causes malloc failures on the Cisco 7513. So it's something I would reserve for a maintenance window if you have one.

1 0

RE: Winstar says there is no TCP/BGP vulnerability
by Michel Py 21 Apr '04

21 Apr '04

> David Luyer wrote: > 98 of the first 100 did not reset. Today, > I did another 12 and only one failed. Thanks for the feedback. > If you have a fully redundant internal BGP, and are running > all 12.2S/12.3/12.2T, then you can rather safely do the > internal BGP passwords without a customer notice, expecting > no session drop but knowing if one did you'd have routes via > a second BGP reflector anyway. Ack. >>> Christopher L. Morrow wrote: >>> use a route-map to add/remove metric or localpref? or any >>> other settable thing on your side? or prepend or .... >> Michel Py wrote: >> Based on what criteria? Both the peer and the transit >> announce the same prefix with the same AS-PATH length. I >> agree that in many cases, favoring the route coming from >> the transit provider would work, > Iljitsch van Beijnum wrote: > Huh? You don't pay for peering traffic by the megabit, so > the idea is to always prefer routes from peers. Indeed, but we were talking about what to do with routes coming from the peer that are not supposed to. Legit routes announced by the peer will naturally be preferred, either because the prefix is longer than the one received from transit, or because the AS-PATH is shorter as the prefix is connected directly to the peer. Michel.

1 0

RE: Winstar says there is no TCP/BGP vulnerability
by Michel Py 21 Apr '04

21 Apr '04

Christopher / David, > Christopher L. Morrow wrote: > if you mean resetting sessions to change keys I believe > it's more code dependent than anythingn else. That was my point: I thought that changing keys without resetting the session was tied to a specific version of the "S" train that I have never seen it on anything lower than a 7200. Anyway, given David Luyer's post, it appears that unless you are willing to accept the risk of an unplanned session reset, you'd better have a planned outage for it. > David Luyer wrote: > Have done around 100 of these in the past 24 hours. It's > not related to platform AFAIK - we've successfully done > the changes on a lowly 2651 and 3620 without outages, but > a 7200 with older IOS did have an outage. Given the context, I assume that you have added MD5 to sessions that did not have it previously, I am correct? Then, do you mean by "without outages" that the session was not reset by the password add/change? If I may ask, how many out of 100 did not reset? > Christopher L. Morrow wrote: > For pure: "Don't blow me up with prefixes" just limit the > maximum-prefix to some # over your expected peer's list. Please allow me to try to make my point again: you store the expected peer maximum-prefix somewhere in your management system. I do understand the added complexity, but in the big scheme of things would it be _that_ more difficult to store a comma-delimited string or something that contains the prefixes that could be announced by that peer instead of the maximum-prefix? Yes, it generates more work to update the database, but OTOH it provides the LIII engineer with a lot more to troubleshoot issues. Is it simply not worth the work at your scale? >> - There are cases (such as the peer being a tier-2 customer of >> UUNET and me being a tier-3 customer of UUNET via a different >> tier-2) when the routes seen coming from the peer will have the >> same length AS-PATH than the ones coming from my transit, some >> other BGP tie-breaking criteria favoring the peer over the >> transit, leading to disaster. > use a route-map to add/remove metric or localpref? or any > other settable thing on your side? or prepend or .... Based on what criteria? Both the peer and the transit announce the same prefix with the same AS-PATH length. I agree that in many cases, favoring the route coming from the transit provider would work, but what guarantees it? What we are trying to define is the idiot-proof setup for peers; what if the misconfiguration is with the transit? >> - In theory, I could add a "route-map blah deny 1" that matches >> everything, then manipulate the subsequent seqs at will, then >> remove the "route-map blah deny 1"; in this situation though, >> I do not see a clear advantage over clearing the session. >> What am I missing? > you could tftp in your config change, that doesn't cause the > problems... then just wait for next update time. I don't see much of a difference. AFAIK when you tftp a config into the running-config, it is appended to the existing config same as if you pasted the commands into conf t. What happens when the next update time happens in the middle of tftp merging the old route-map with the new one? Michel.

5 6

RE: Winstar says there is no TCP/BGP vulnerability
by Peering 21 Apr '04

21 Apr '04

We do prefix-filter all our peers, both customer and transit. We also use as-path filters. It does seem to help us avoid insertion of invalid routes and other issues (especially since some people we peer with don't do the same on their side). As far as stability and process problems, we're too busy working on the instability of the Ciscos we're on now to notice, particularly the problem with BGP scanner taking up all the CPU every 60 seconds. We're preparing to move from an ATM core on Alcatel ATM switches with a Cisco edge to an IP-MPLS core on Juniper M-20s with M-20s (and a few Ciscos in smaller cities) on the edge. Hopefully that will improve our stability. We're pretty excited about the Junipers (the network geeks like me here are drooling). Diane Turley Network Engineer Xspedius Communications Co. 636-625-7178 -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Patrick W.Gilmore Sent: Wednesday, April 21, 2004 10:12 AM To: nanog(a)merit.edu Cc: Patrick W.Gilmore Subject: Re: Winstar says there is no TCP/BGP vulnerability On Apr 21, 2004, at 10:38 AM, Jared Mauch wrote: > On Wed, Apr 21, 2004 at 10:19:10AM -0400, Patrick W.Gilmore wrote: >> >>> Yes, it generates more work to update the database, >>> but OTOH it provides the LIII engineer with a lot more to >>> troubleshoot >>> issues. Is it simply not worth the work at your scale? >> >> Exactly. >> >> And you do not have to be at 701's scale for this to not work. > > We've not had these issues and have been using > bgp passwords/md5 for years. We do have a fancy configuration > managment system in place, whereby people put things into the database > first before they configure the router. Sorry, in this particular post, we were (or at least I was) talking about having prefix filters for all your peers. I know I've talked a lot about MD5 lately, just thought it would be a nice change of subject. :) If you do prefix filter all your peers, that is impressive. Do you get out of sync a lot? Does it help keep the network more stable? Or do process problems make it worse than just max-prefixes on a peer? -- TTFN, patrick

1 0

RE: Xspedius / E.Spire as wellRe: Winstar says there is no TCP/BGP vulnerability (fwd)
by Peering 21 Apr '04

21 Apr '04

All, Xspedius (formerly e.spire/ACSI) is in the process of converting BGP connections to MD5. We have already done so with both of our transit providers and we're working on contacting customers that we do BGP with. If anyone is a customer of Xspedius and wants to convert to MD5, please email me or open a ticket with the NOC and request that it be referred to Dwayne Chin in Tier II DMC, who is working with me on this project. Otherwise, we will be contacting you directly. Regards, Diane Turley Network Engineer Xspedius Communications Co. peering(a)xspedius.com ---------- Forwarded message ---------- Date: Tue, 20 Apr 2004 15:30:30 -0600 From: " John Brown (CV)" <jmbrown(a)chagresventures.com> To: Rodney Joffe <rjoffe(a)centergate.com> Cc: NANOG <nanog(a)merit.edu> Subject: Xspedius / E.Spire as wellRe: Winstar says there is no TCP/BGP vulnerability Seems Xspedius aka E.SPire aka ACSI doesn't feel that MD5 is important on their BGP sessions either. Based on the ticket we filed last week, Managment does not feel its warranted to make these changes. On the other hand, SPRINT was willing and able to take MD5 session info right away. WAY TO GO SPRINT. On Tue, Apr 20, 2004 at 01:44:44PM -0700, Rodney Joffe wrote: > > Perhaps we are all making too much of this... > > It appears that Winstar feels that there is no need for MD5 > authentication of peering sessions. One of our customers has just had > the following response from Winstar following a request to implement > MD5 on their OC3 connection to Winstar. My first suggestion is to > locate another upstream provider (they have 3 already). > > However, perhaps someone from Winstar would care to help us all > understand what the alternative solution is to securing the session > via MD5? I would *love* an alternative to the 5 days of work we've > just gone through. > > > -----Original Message----- > > From: Justin Crawford - NMCW Engineer [mailto:jcrawford@winstar.net] > > Sent: Tuesday, April 20, 2004 11:13 AM > > To: xxxxxx > > Subject: Re: *****SPAM***** MD5 implimentation on BGP > > > > xxxxx, > > > > Winstar does not currently run MD5 authentication with our peers. > > > > Thanks > > > > Justin > > > > Thank you for your time and business > > > > Justin Crawford > > Winstar NMCW > > Ph: 206-xxx.xxxx > > Has anyone else run in to this with Winstar? > > -- > Rodney Joffe > CenterGate Research Group, LLC. > http://www.centergate.com > "Technology so advanced, even we don't understand it!"(SM)

1 0

RE: Winstar says there is no TCP/BGP vulnerability
by Michel Py 21 Apr '04

21 Apr '04

> Patrick W.Gilmore wrote: > And when that process involves customers calling to ask > why they can't get to XXX web site (no pun intended - > I'm sure no one would filter a pr0n site :), it is much > more than "a bitch", it is a CLM/CEM. But you're missing something fundamental here: for non-tier-1s, the very purpose of peering is to offload your transit. If you filter the routes you accept from the peer, you don't shoot yourself in the foot, all you do is to send traffic to that prefix to transit, which is what you would have done in the first place if you were not peering. In other words, if your ingress route-map to filter prefixes received from the peer is incomplete, your only loss is that you will not reap the benefits of peering for the omitted prefix(es). I never said that prefix-filtering peering should shoot for perfection; if a few prefixes slip through the cracks and they're worth a modemload of traffic, who cares? Michel.

1 0