NSPs and filters

Its not feasible to filter packets on customer gateway routers. When you
impose a packet filter on a GW router customer interface, all packets
destined to that customer have to be matched to an access-list and then
forwarded down the pipe or dropped. This increases the load on the
router CPU, because it is used to switching the packets. Now you have to
analyze each packet which takes up CPU time.

This is not a nice thing to do to a router, especially while the router is
trying to keep up with 50 other customers... And if more than 1 customer
wants this type of service, you start really feeling the load.

It isn't, or shouldn't be, an issue of whether the customer wants this
kind of service. This is protection FROM that customer. The principle
reason to not do this is the load it causes on the router.

Should it be discovered that source forged packets are coming from a given
customer, then you could apply this to that customer if they are not going
to just be summarily cut off.

Perhaps, in time, security demands may require doing more of this. Or they
may require more kinds of traceability of where the bad packets are coming
from (also costly).

The trouble is, unless you are silly enough to attack your own provider,
it seems unlikely that they will know you are spoofing. i.e. In my
current situation, I doubt UUNet's ability or willingness to track these
packets to their source. How are the source's provider supposed to find
out? The attack is now into its 3rd day and can be seen in our traffic
graph at http://gnv.fdt.net/~fubar/cgi-bin/uunet.cgi

The attacker seems to be taking short breaks every 30-90 minutes.

I captured a few hundred packets last night for UUNet's security people to
look at (so they will believe me) and of the 225 packets captured, all
were from unique source addresses.

Here's a breif snippit from just a minute ago:

12:19:13.494446 49.0.94.105.666 > 205.229.58.133.7: udp 1450 (ttl 244, id
31674)
12:19:13.504446 12.206.160.94.666 > 205.229.58.133.7: udp 1450 (ttl 244,
id 31675)
12:19:13.524446 11.80.252.52.666 > 205.229.58.133.7: udp 1450 (ttl 244, id
31676)
12:19:13.544446 253.81.121.106.666 > 205.229.58.133.7: udp 1450 (ttl 244,
id 31677)
12:19:13.564446 159.83.60.97.666 > 205.229.58.133.7: udp 1450 (ttl 244, id
31678)
12:19:13.594446 122.164.93.95.666 > 205.229.58.133.7: udp 1450 (ttl 244,
id 31679)
12:19:13.604446 182.2.169.126.666 > 205.229.58.133.7: udp 1450 (ttl 244,
id 31680)
12:19:13.624446 160.95.105.78.666 > 205.229.58.133.7: udp 1450 (ttl 244,
id 31681)
12:19:13.644446 83.18.225.93.666 > 205.229.58.133.7: udp 1450 (ttl 244, id
31682)

The one or two times we have had interactions with UUNet's security
guy/group have been very positive. Norm over there was especially helpful
and in the case of an emergency their security types are on-call
(directly, by pager if necessary).

They are MUCH more likely to contact an offending provider and ask that
the circuit be turned down rather than filter in their own network, which
isn't always the quickest process in the world.

-Deepak.

> It isn't, or shouldn't be, an issue of whether the customer wants this
> kind of service. This is protection FROM that customer. The principle
> reason to not do this is the load it causes on the router.
>
> Should it be discovered that source forged packets are coming from a given
> customer, then you could apply this to that customer if they are not going
> to just be summarily cut off.

The trouble is, unless you are silly enough to attack your own provider,
it seems unlikely that they will know you are spoofing. i.e. In my
current situation, I doubt UUNet's ability or willingness to track these
packets to their source.

Hi, On Friday our network was suffering an identical attack as yours. We
are a UU-NET customer. Once I had traced the exact neture of the attack,
port numbers etc, I contacted UU-NET who *did* trace the source of the
attack to one of their customers - I think inside AS701.

I was pretty impressesed - took them about an hour - I didn't overly think
that they would find the source but they located it down - with some help
from the source customer to the individual machine. I doubt it is the same
person doing the attacks as the source port for us was 13 (?) and the size
of udp packet was 1000 - but both attacks probably from the same program.

Is there any way to put the originating AS into the (options part?)
header of all ip packets as they leave one's border routers? If tcpdump
could then extract this informaton (which could only be forged by a very
small minority of people on the network) tracing such attacks woukd a be
a lot easier... I suppose adding that info into teh ip header would cause
far too much load on the exit routers though?

Regards,

aid