[4411] in North American Network Operators' Group
Re: SYN floods (was: does history repeat itself?)
daemon@ATHENA.MIT.EDU (Mr. Jeremy Hall)
Mon Sep 16 10:10:59 1996
From: "Mr. Jeremy Hall" <jhall@rex.isdn.net>
To: alex@relcom.eu.net
Date: Mon, 16 Sep 1996 09:01:19 -0500 (CDT)
Cc: avg@quake.net, curtis@ans.net, nanog@merit.edu, perry@piermont.com,
klf@linseed.jobsoft.com
In-Reply-To: <ACq7LFoK58@arch.relcom.ru> from "alex@relcom.eu.net" at Sep 16, 96 05:11:16 pm
-->
-->> -->(Note that reverse filters i described do _not_ require that the route
-->> -->back must be best. It just have to be present in the RIB corresponding
-->> -->to exterior routing session over the interface in question.)
-->> -->
-->> You may not have said it, but I remember someone said the route had to be
-->> in the routing table. I would agree with you if it looked up the source
-->> in the BGP table and if it considered history or dampened paths valid. If
-->> your asymetry runs over multiple interfaces, then the best path might not
-->> be on the interface the packet is arriving on.
-->This behaviour is USEFULL in any case. If we can filter SRC addresses only in
-->accordance with routing table - we'll prevent attackes from our direct customers.
-->If this filtering will work in acordance with the total routing table (not best
-->routes only) - OR, we'll prevent attack from some small ISP there too. But
-->anyway this mechanism will work if it'll be available for us.
-->
-->I never wrote we can prevent attack via other big ISP if they would not
-->support this filtering. But if Cisco'll incorporate this in _provider_
-->revision - I think most of ISP will use this mechanism in near future.
-->(it depends of extra CPU and memory it'll use certainly).
-->
-->---
-->Aleksei Roudnev, Network Operations Center, Relcom, Moscow
-->(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager)
-->(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
-->
I think we're mixing two issues here. My train of thought was that you
filter direct or dialup customers at the termination device for your
network. This stops attacks from coming from your own customers. My
second thought was this thread. It was my understanding this would be
deployed on border routers to help stop attacks that come from other
"neighbors". I haven't heard a good reason why this type of source
filtering would help a customer during an outage. It has been suggested
that blocking packets could help customers by reducing the load on the
routers that are recalculating their routing tables. Would this really
be beneficial, or would customers see a sudden stop in service every
time a recalculation takes place? Obviously restoring service as
quickly as possible is our main goal. Every morning, Coren reconfigures
their routers on a timely schedule and this does not interrupt service.
If you introduce this "switch", service might get interrupted every day
during reconfig time or whenever somebody clears a BGP session.
--
-------------------------------------------
| Jeremy Hall Network Engineer |
| ISDN-Net, Inc Office +1-615-371-1625 |
| Nashville, TN and the southeast USA |
| jhall@isdn.net Pager +1-615-702-0750 |
-------------------------------------------
