On the back of other 'security' posts....

Matthew Sullivan matthew at sorbs.net
Sun Aug 31 00:06:12 UTC 2003


Owen DeLong wrote:

>> Yet more spoofed traffic aimed at the SORBS nameservers - this time
>> enough to crash a core router of my upstream...  Hopefully the 
>> commercial
>> damage now may insite people getting damaged by these DDoSes to start
>> proceedings against those ISPs whom continue to show a lack of
>> respobsibility and allow unfiltered spoofed DDoS traffic from their
>> networks.  Certainly I have been told to talk to various US authorities
>> about the problem, and will be doing so as soon as I have the nessesary
>> information.
>>
> The ISPs aren't who should be sued.  

Any irresponsible party should be in the firing line.

> The people running vulnerable systems
> generating the DDOS traffic and the company providing the Exploding Pinto
> should be sued.  An ISPs job is to forward IP traffic on a best effort
> basis to the destination address contained in the header of the datagram.

I disagree, they should forward valid traffic

> Any other behavior can be construed as a breach of contract.

The depends squarely on their contract, and do contracts say 'we will 
forward all your traffic including that which is designed to force 
others off the net'?

>   Sure, blocking
> spoofed traffic in the limited cases where it is feasible at the edge 
> would
> be a good thing, but, I don't see failure to do so as negligent.  Where
> exactly do you think that the duty to care in this matter would come from
> for said ISP? 

In the fact that if an ISP has a customer (a single peered ISP or or 
enduser) that is sending traffic from addresses that they are not 
permitted to use publically, they should  be blocked and told not to do 
it again...

I remember a _long_ time ago (1991) when I was signed up with my first 
ISP in the UK a friend and I were experimenting with SYN, UDP and ICMP 
spoofed traffic, flooding each other (on different ISPs) I got a mail 
from ISP security telling me to stop within 24 hours, none of the 
traffic got off their network.  Following that, my friend dialed into 
his account on the same ISP as me, and we continued the tests and next 
thing I know I got booted for having been warned --- security didn't 
care that we were doing it to each other with permission etc.....

Now I know the net has grown a lot since then, however my ISP did have 
more than 17k customers at the time... However if they blocked all 
traffic that didn't originate from the customer back then how come 12 
years later some ISPs still continue to allow spoofed traffic from their 
customers knowing full well that traffic is invalid and likely attacking 
something.

>> In the mean time a plea to people on this list in all countries - watch
>> for the DDoS attacks (particually against 203.15.51.33, 203.15.51.35,
>> 203.15.51.44 & 203.101.254.254) and stop the damn traffic before you are
>> held responsible for your customers actions.  There is still a 10k pps
>> SYN flood occuring 8 hours later - this is being rate limited upstream.
>>
> Again, I just don't see where an ISP can or should be held liable for
> forwarding what appears to be a correctly formatted datagram with a valid
> destination address.

Where the packet is sourced from 1 network and is addressed as from 
another network I do not consider that as 'correctly formatted'

>   This is the desired behavior and without it, the
> internet stops working.

Bull

>   The problem is systems with consistent and
> persistent vulnerabilities.  One software company is responsible for
> most of these, and, that would be the best place to concentrate any
> litigation aimed at fixing the problem through liquidated damages. 

Suing M$ will not solve the problem.  Look at the remidies the DoJ set - 
M$ just completely ignored them and carried on.  M$ is too big now, they 
will continue to do as they see fit and there is noone powerful enough 
in the market to stop them.  This is not about M$ bashing though - its 
about non carriers originating spoofed traffic and not caring.

/ Mat




More information about the NANOG mailing list