[4370] in North American Network Operators' Group
Re: SYN floods (was: does history repeat itself?)
daemon@ATHENA.MIT.EDU (Mr. Jeremy Hall)
Fri Sep 13 23:19:30 1996
From: "Mr. Jeremy Hall" <jhall@rex.isdn.net>
To: amb@xara.net (Alex.Bligh)
Date: Fri, 13 Sep 1996 22:17:33 -0500 (CDT)
Cc: justin@erols.com, alexis@panix.com, amb@xara.net, freedman@netaxs.com,
stpeters@netheaven.com, nanog@merit.edu
In-Reply-To: <199609131859.TAA23362@diamond.xara.net> from "Alex.Bligh" at Sep 13, 96 07:59:54 pm
-->... and the broken case I was talking about was (e.g.) where you announce
-->your AS-MACRO or whatever to peer routers A, B, C accross a NAP but
-->also annouce full routing (for say backup transit) to D. Let's say
-->for simplicity 192.1.1.0 is your only announcement to peers (small
-->network :-) ). So you would have to filter outgoing packets to A-C
-->differently than those to D (as they might legitimately have source
-->addresses from within the internet at large and be destined for D).
-->You could do this on (say) IP address of next hop. But let's say D
-->transits B, and doesn't have next-hop-self switched on. Then packets from
-->source addresses from internet at large which were destined for B, which
-->would legitimately be passing out of your i/f towards B would get filtered.
-->Fine, so you could force them to use next-hop-self, or use the IP
-->address of the BGP peer concerned to do the filtering on. But this
-->wouldn't work with the RAs.
-->
-->This is a problem whenever you are providing customer facing services
-->(in the broadest sense, i.e. transit) out of the same i/f as peer
-->services. OK, so you decide that *either* the source
-->or the destination address has to be within your 'peer' announcement
-->(i.e. the packet has to either be going to one of your networks
-->(in this case including D's who you are transitting) or coming
-->from one of your networks (also incl. D)). Well fine, but if
-->you blur the transit / peer distinction further we get down
-->to a situation where you are essentially routing on source address
-->as well as destination address. Not really very maintainable.
-->
-->Alex Bligh
-->Xara Networks
-->
-->
What about the case where a customer knows your topology, and knowsof a
valid address that isn't alive, and possibly never would be. In order to
really squelch this problem, you'd have to filter at the point of the
network where the customer connects to you, at your termination device,
otherwise a customer could successfully attack another network on the
assumption that you aren't filtering down to the nose. From what I've
read, these type attacks could be spotted because the source port changes
sequentially, although this wouldn't be hard to change. If you
constructed a device to detect and correct these type situations, if it
were between your backbone and your customers, this might work. If your
router logs via syslog bgp updates debugging, then the device could
dynamically decide to forward or deny packets based on source or
destination or whatever you like. With a fast enough machine, this
shouldn't be a performance hit, and it takes a heavy load off the
borders from doing packet filtering. But if you filter at your
termination point, you do not need to worry about generating attacks,
and with the makeshift box acting as a router, you are protected from
inbound attacks. Does this sound too impractical?
--
-------------------------------------------
| 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 |
-------------------------------------------
