What is evil: IP spoofing or Distributed attacks? (was Re: DDOS anecdotes)

Sun Jun 24 04:58:18 UTC 2001

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 at merit.edu [mailto:owner-nanog at merit.edu]On Behalf Of
Eric Oosting
Sent: Saturday, June 23, 2001 9:41 PM
To: Paul Vixie
Cc: nanog at 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 at 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.
>