Re: Internet SYN Flooding, spoofing attacks
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
On Fri, 11 Feb 2000, Paul Ferguson wrote:
Unicast RPF where appropriate and filters where appropriate, life would become better. -- exhibit [a]
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.
I suspect we are in violent agreement here. See exhibit [a] /vijay
participants (2)
-
Paul Ferguson
-
Vijay Gill