SYN floods (was: does history repeat itself?)

Pat Calhoun pcalhoun at usr.com
Fri Sep 13 20:54:47 UTC 1996


     John,
     
        This sort of feature could be easily added into a NAS, but I 
     question your implementation details. If this filter was turned on by 
     default, then this could "break" other types of services which may 
     require source ip addresses other than the one which was negotiated to 
     the user.
     
        This would mean that a customer could perform a flash upgrade and 
     find that their service no longer operates (a technical support 
     nightmare). Would you be willing to consider such a feature where it 
     would have to be enabled (and is disabled by default) and a very well 
     explained document with the release notes to service providers 
     advising them of the risk of not enabling this switch??
     
     Pat R. Calhoun                                e-mail: pcalhoun at usr.com 
     Project Engineer - Lan Access R&D                phone: (847) 933-5181 
     US Robotics Access Corp.

______________________________ Reply Separator _________________________________
Subject: Re: Re[2]: SYN floods (was: does history repeat itself?)
Author:  "John G. Scudder" <jgs at ieng.com> at Internet
Date:    9/12/96 2:33 PM


At 1:44 PM -0400 9/12/96, Curtis Villamizar wrote:
>I agree with you completely -- sort of.  Only problem is there are 
>thought to be some 3,000 dial access providers.  Many of them barely 
>know what a TCP SYN is, let alone why they need to block ones with 
>random source addresses and how.  Unless of course you are
                                   ^^^^^^^^^^^^^^^^^^^^^^^^
>volunteering to explain it and help them.  Thanks in advance.  :-)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     
Curtis, this is a great point.  USR and other NAS vendors are actually in a 
great position to do exactly this, by changing their boxes to block random 
addresses *by default* on dial-up ports.  This is of course exactly the 
point Vadim and others keep making, and of course as they point out there 
ought to be a knob to disable it if desired.
     
Insofar as guys who "barely know what a TCP SYN is" are unlikely to twist 
the knobs, defaulting filtering to "block spoofed addresses" seems like the 
best and maybe only way to get them to do it.
     
How about it, USR &al?
     
--John
     
--
John Scudder                        email:  jgs at ieng.com 
Internet Engineering Group, LLC     phone:  (313) 669-8800 
122 S. Main, Suite 280              fax:    (313) 669-8661
Ann Arbor, MI  41804                www:    http://www.ieng.com
     
     
-------------- next part --------------
Received: from usr.com (mailgate.usr.com) by robogate2.usr.com with SMTP
  (IMA Internet Exchange 2.02 Enterprise) id 23856580; Thu, 12 Sep 96 13:28:40
-0500
Received: from syzygy.ieng.com by usr.com (8.7.5/3.1.090690-US Robotics)
	id NAA19118; Thu, 12 Sep 1996 13:31:59 -0500 (CDT)
Received: from [198.108.88.23] (pm049-22.dialip.mich.net [198.108.88.42]) by
syzygy.ieng.com (8.7.4/8.7.3) with ESMTP id OAA00770; Thu, 12 Sep 1996 14:33:17
-0400 (EDT)
Message-Id: <v03007824ae5e06a40fbb@[198.108.88.23]>
In-Reply-To: <199609121744.NAA13973 at brookfield.ans.net>
References: Your message of "Mon, 09 Sep 1996 13:19:18 CDT."            
 <233128C0.3000 at usr.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 12 Sep 1996 14:33:52 -0400
To: curtis at ans.net
From: "John G. Scudder" <jgs at ieng.com>
Subject: Re: Re[2]: SYN floods (was: does history repeat itself?)
Cc: pcalhoun at usr.com (Pat Calhoun), nanog at merit.edu


More information about the NANOG mailing list