mailing list archives
Re: On the back of other 'security' posts....
From: Matthew Sullivan <matthew () sorbs net>
Date: Sun, 31 Aug 2003 10:06:12 +1000
Owen DeLong wrote:
The ISPs aren't who should be sued.
Yet more spoofed traffic aimed at the SORBS nameservers - this time
enough to crash a core router of my upstream... Hopefully the
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
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'?
spoofed traffic in the limited cases where it is feasible at the edge
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
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
In the mean time a plea to people on this list in all countries - watch
for the DDoS attacks (particually against 18.104.22.168, 22.214.171.124,
126.96.36.199 & 188.8.131.52) 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
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.
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.
Re: On the back of other 'security' posts.... Matthew Sullivan (Aug 31)
Re: On the back of other 'security' posts.... Paul Vixie (Aug 30)
RE: On the back of other 'security' posts.... Greenhalgh, John (Aug 31)