[4328] in North American Network Operators' Group
Re: SYN floods (was: does history repeat itself?)
daemon@ATHENA.MIT.EDU (Perry E. Metzger)
Thu Sep 12 14:44:11 1996
To: curtis@ans.net
cc: nanog@merit.edu
In-reply-to: Your message of "Thu, 12 Sep 1996 13:07:59 EDT."
<199609121707.NAA13886@brookfield.ans.net>
Reply-To: perry@piermont.com
Date: Thu, 12 Sep 1996 14:41:09 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Curtis Villamizar writes:
> > I think its time for the larger providers to start filtering packets
> > coming from customers so that they only accept packets with the
> > customer's network number on it.
> >
> > Yes, its a load on routers. Yes, its nasty for the mobile IP weenies.
> > Unfortunately, the only known way to stop this.
[...]
> I'm not arguing against your point. There are some feasibility issues
> right now that mean we can't just "turn this on".
>
> Packet filtering on prefixes is only feasible as slower speeds with
> current routers and even then it can give smaller routers a tough
> time.
Fully agreed. This can't be done overnight. However, it has to be done
eventually. I'd say one to two years would be a reasonable
implementation timeframe, with a good fraction of the tail circuits
getting filtered in less than a year.
BTW, I would suggest that for a variety of applications, hardware
assisted filtering boxes that simply take in IP one end and put out
processed IP on the other end would be of use -- not just for this,
but also for helping in doing packet traces through high traffic
areas, for implementing firewalls, and for all sorts of other
things. Vendors, are you listening?
> There is also a problem with packet filtering due to assymetric
> routing. You can legitimately end up with packets coming from
> addresses other than those that you route towards and should not black
> hole that traffic.
Yes, but this shouldn't be happening at the site of the customer tail
circuit, so thats not too bad a problem there.
> At the single homed connection a router option to reverse the sense of
> the forwarding table on a specific interface (look up the source in
> the forwarding table and only accept if the source is reachable
> through that next hop) seems to be a effective preventative that could
> be easily just "switched on".
A very good idea.
Perry
