From owner-freebsd-hackers Thu Sep 12 17:43:19 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA16221 for hackers-outgoing; Thu, 12 Sep 1996 17:43:19 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA16216 for ; Thu, 12 Sep 1996 17:43:17 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id AAA27149; Fri, 13 Sep 1996 00:42:44 GMT Date: Fri, 13 Sep 1996 09:42:44 +0900 (JST) From: Michael Hancock To: Darren Reed cc: Terry Lambert , fenner@parc.xerox.com, karl@mcs.net, freebsd-hackers@freebsd.org, koshy@india.hp.com Subject: Re: SYN Resisting (fwd) In-Reply-To: <199609122320.QAA11411@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 13 Sep 1996, Darren Reed wrote: > > Other than that, I was a little peeved at blaming the US with the blanket > > statement that the loss was on the US end of things. Ignoring perfectly > > valid source quench requests (from *non*-ICMP ATM routers) is only one > > of the possibilites that could be considered before calling everyone > > managing NSP in the US incompetent. > > I think that some people are unaware of congestion at/in points such as > their West Coast (i.e. LA/Bay Area) where multiple, full, pipes start > for international destinations. IIJ has a T3 into Mae-west and another one into NY-NAP. > On the other hand, our local telco is probably no better than Sprint/MCI. > > I suspect that most NSP's in the USA don't provide international access. MCI and ATT WorldNet each have a T3 link to Japan. > The point being, when your network is all peachy from end to end, having > low timeouts is (maybe) acceptable, but when your endpoints are in > diverse locations and throughput is not 100%, who is really winning ? The ones that can throw money at it. > If the attacker is trying to cause denial of service, then it may be > achieved by the other end when they make it harder for real users to > connect quick enough. > > To my thinking, this is a silly solution (but a reasonable patch for the > sysctl :) to the SYN problem. The problem must and can only be fixed > with correct filtering by all ISPs so long as we use the current IP. I'm not sure what's easier, to get all ISP's to do correct filtering or to get everyone to move to a new IP. Regards, Mike Hancock