[27319] in North American Network Operators' Group
Re: Internet SYN Flooding, spoofing attacks
daemon@ATHENA.MIT.EDU (Paul Ferguson)
Fri Feb 11 21:40:28 2000
Message-Id: <4.2.2.20000211213043.00a26630@lint.cisco.com>
Date: Fri, 11 Feb 2000 21:36:59 -0500
To: Vijay Gill <wrath@cs.umbc.edu>
From: Paul Ferguson <ferguson@cisco.com>
Cc: nanog@merit.edu
In-Reply-To: <Pine.SOL.3.95.1000211212237.17799I-100000@mailserver-ng.cs
.umbc.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Errors-To: owner-nanog-outgoing@merit.edu
At 09:27 PM 02/11/2000 -0500, Vijay Gill wrote:
>IETF removed from the distribution list.
Thank goodness.
More:
>I think you're solving something else. I submit that almost _all_ isp's
>offer transit for their customers. Thats where the I part of the SP comes
>in. For _peering_ links (peering being defined elsewhere), yes, this is a
>hard problem, but on the edges of the _peers_, this is not. If everyone
>filtered their T1/DSx/OCx/E1/E3/STMx customers at their edges, using
>Unicast RPF where appropriate and filters where appropriate, life would
>become better.
Okay. Let's look at this simplistic situation. Perhaps I'm missing
something.
A B
\ /
C
|
D
ISP C might be carrying traffic for B which might destined via
ISP A (or traverse C). In some cases, for packets coming through
C from B, C may not have a reverse path back through B for that
packet. It might have a better path elsewhere.
D is a "Joe's Bait'n'Sushi Shop" ISP.
C might have some problems doing Unicast RPF, but it certainly
wouldn't have problems doing RFC2267-style filtering on it's
access link to D; likewise ther might be many "mini" connections
from C to other smaller downstream customers. THAT is where this
filtering needs to occur.
- paul
