Hello Eric, Automagicness, you are asking for, is a beautiful thing, but in a reality, sometimes, assumption that Internet traffic is symmetrical, and a destination address of all your IP packets is 100% coherent with your BGP advertisements, can be false. Nearly all of our satellite connected POPs fall into this category. We are sending traffic up through the terrestial fiber links on which we don't (want to) BGP advertise it, and we expect to receive traffic from the sky, from our sattelite providers, so in such (over)simplyfied automagic algorithm for building "huger" ACL config lists we would be simply rejected. -- Besides -- The whole NANOG-mail-thread about "DDOS anecdotes", and grc.com, and DDoS somehow drifted into anti-spoofing disputes. But - unfortunately -- even in a perfect, "IP-unspoofable" ISP-land "(if that were a word" :-), somebody "0wning 1000 windoze boxen with customized IRC bots" will do the very same damage as some devil IP spoofer. Regardless of their (XP) IP stack vulnerability to IP spoofing or not. Those concerted DDoS attacks __don't require__ spoofing at all. The keyword there is "Distributed" -- they are dangerous and disturbing, but not because of lack of cooperation between ISPs in fight against IP spoofing, but because there are not known techniques and methods to fight against somebody stealth-ing his/her attack behind so many <really> distributed hosts that we don't know how to ACL them. You asked for thoughts -- here are my $.002 Przemek (IFXer always complainig about good (too)strict Netrail? BGP policies) -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Eric Oosting Sent: Saturday, June 23, 2001 9:41 PM To: Paul Vixie Cc: nanog@merit.edu Subject: Re: peering requirements (Re: DDOS anecdotes) Has there been any work done, or is it even a good idea to implement something kinda like the RPF check in Multicast, but for unicast, that could be used on interfaces at AS boundaries. As each packet is accepted on an interface, the source address of the packet could be checked as being in a prefix that is advertised by the bgp peer that sent you the packet. This could be done by the router, with only a config statement on the interface to turn it on. The idea being that if another AS sends you a packet with a particular source address, they better have a way back to the source. Packets that did not meet this criteria could either be denied or logged. (If dumping them is too harsh, atleast logging them could help track attacks) This could be useful at peering boundaries for both parties, where full views are not exchanged. This could also be used by ISPs on customer interfaces, as long as all potential source addresses are advertised over the bgp session, which is not necessarily the case with customer sessions. (Note: Most peering agreements require the same routes advertised at all points ... not the case with customers) I know that this could be automated by creating access lists from bgp advertisements using auto-magic scripts, but it wouldn't be in real time, making it useless IMHO. It would also make the configs huge. (well, huger, if that were a word.) There are the obvious hardware considerations... Can todays hardware support access lists of this size at line rate? Will they for be able to for long? Under what circumstances would the assumption (that an AS should always advertise a route to the source address of packets it transmits) not be a good one? Of course this could be turned around and the capability made to deny or log packets with a source address that you are not advertising a route to. Thoughts? Eric Eric Oosting eric@netrail.net office:404.739.4385 Sr. Network Engineer Network Eng and Operations NetRail, Inc On 23 Jun 2001, Paul Vixie wrote:
... but I do not blame their IP stack for this like Mr Gibson does
though.
Same here.
... From spoofed sources because ISPs do not source address filter? Gah. Basically untraceable.
This is the problem.
What should we do?
Recommendation: upgrade your peering requirements to include language
like:
Each peer agrees to emit only IP packets with accurate source addresses, to require their customers to do likewise, and to extend this requirement to all other peers by $DATE.
Where DATE = (now() + '6 months') or some other negotiated value.
I've been saying this since 1993. Is anybody ready to believe me yet? We solve this, or our industry stops growing because we're spending too much time dealing with this problem and new customers see diminished returns.