FW: Re: Is there a line of defense against Distributed Reflective attacks?

[Stewart_William_C_Bi]

attacks?

Many of these attacks can be mitigated by ISPs that do
anti-spoofing filtering on input - only accepting packets from user ports
that have IP addresses that are registered for that port,
and not accepting incoming packets from outside their network
that claim to be from inside (except maybe from registered dual-homed hosts.)
This cuts down on many opportunities for forgery,
and means that SYN Flood attacks have a much more limited set of
addresses they can forge (e.g. an attacker or zombie can only
impersonate other ips sharing its /24 or /29,
so it can't pretend to be its victim in a reflection or smurf attack.)

That doesn't stop all reflection attacks; a zombie on a network
that doesn't do anti-spoofing can send SYNs to a big server on a
network that also doesn't anti-spoof, so the server will still SYN-ACK
to the victim. This cuts out a lot of potential zombie/server pairs.
If the server that's being used for reflection is someone the
victim would often talk to, that's a problem
(you'd rather not block connections to Yahoo),
but if it's someone the victim doesn't care about talking to
(like router23.example.net) you don't mind blocking it.
(Also, why is router23.example.net SYNACKing somebody it doesn't know?)

But there are probably 20 million web servers or Kazaa or IM clients out there,
and probably half of them are on networks that don't spoof-proof,
so blocking those is much tougher than blocking the big ones.
And next stop - reflection attacks using big domain servers...

[Christopher_L_Morrow]

From: Stewart, William C (Bill), RTLSL
Sent: Friday, January 17, 2003 5:35 PM
To: 'nanog-post@trapdoor.merit.edu'
Subject: Re: Is there a line of defense against Distributed Reflective
attacks?

Many of these attacks can be mitigated by ISPs that do
anti-spoofing filtering on input - only accepting packets from user ports

Sure, but this is a proven non-scalable solution. HOWEVER, filtering as
close to the end host is scalable and feasible... do it there, it makes
MUCH more sense to do it there.

that have IP addresses that are registered for that port,
and not accepting incoming packets from outside their network
that claim to be from inside (except maybe from registered dual-homed hosts.)
This cuts down on many opportunities for forgery,
and means that SYN Flood attacks have a much more limited set of
addresses they can forge (e.g. an attacker or zombie can only
impersonate other ips sharing its /24 or /29,
so it can't pretend to be its victim in a reflection or smurf attack.)

That doesn't stop all reflection attacks; a zombie on a network
that doesn't do anti-spoofing can send SYNs to a big server on a
network that also doesn't anti-spoof, so the server will still SYN-ACK

its not the 'server' that needs 'anti-spoof' its the end host, the machine
in your livingroom that is on a cable modem for instance... the server in
this instance is a simple, innocent, machine doing its business.

to the victim. This cuts out a lot of potential zombie/server pairs.
If the server that's being used for reflection is someone the
victim would often talk to, that's a problem
(you'd rather not block connections to Yahoo),
but if it's someone the victim doesn't care about talking to
(like router23.example.net) you don't mind blocking it.
(Also, why is router23.example.net SYNACKing somebody it doesn't know?)

This is an interesting point. The routers shouldn't really syn-ack (in
this example) bgp from 'unknown' places... unless you are a neighbor you
get squat, or that would be a nice feature, eh? For some folks, the
problems aren't confined to just bgp, telnet or ssh on routers are also
problemmatic, vty acl's are important

But there are probably 20 million web servers or Kazaa or IM clients out there,
and probably half of them are on networks that don't spoof-proof,
so blocking those is much tougher than blocking the big ones.
And next stop - reflection attacks using big domain servers...

Hmm, I'm not sure, again, that the spoof proof needs to be on the kazaa
server network, it needs to be on the network where the originating
attacke is, preferrably as close to that host as possible, like it's
default router... Now, the problems with 60million kazaa clients openning
the floodgates on you are a whole nother problem

[Daniel_Senie2]

Well, let's see... on dialup circuits it should be done and should be a no-brainer. After all, ISPs are required (by UUNet at least) to push in filters to ensure dialup users can only reach port 25 of that ISPs mail servers and be blocked from all other spots. How hard is it to push in one more filter that checks the source IP address of the dialup user to ensure the address coming from the user is the one assigned?

Sure, dialups are not the only problem, but it's an example of blocking close (very close) to the edge.

Each time an ISP sells a T1 with a router and assigns a block of addresses, there's an opportunity to configure that router with filters (ingress/egress depending on which side you look at it from) and at least simple firewalling rules. Is this an expense to the installing ISP, or a cost savings in not having to deal with attacks that came from that network later? Even when a customer provides the CPE, providing sample configurations really costs little and would help. In many cases, the vendor supplying that T1 is one of the same companies which also handles the "core" so it's REALLY in their best interest to take little steps to protect their edges (hard to point fingers from the core and say "it's the edge vendor's problem" when you're also the edge vendor in some cases).

While it's nice that router vendors implemented unicast RPF to make configuration in some cases easier, using simple ACLs isn't necessarily hard at the edges either.

The stumbling block for ingress filtering has always been pretty simple: By implementing ingress, the network you save will be someone else's. You have to trust that other network operators will implement ingress filtering and in so doing save your network. Sadly, folks tend to avoid doing things that might help others, and so I continue to wait for a negligence lawsuit to wake folks up on this issue.

Eliminating spoofed addresses from the backbone, even if it were possible to do 100%, would not eliminate denial of service attacks. The DDoS attacks using coordinated "owned" machines demonstrates this. As spoofing becomes more difficult, tracing back the source of attacks becomes easier. Network operators will still find machines on their networks performing attacks, but when that phone call comes from another network with attack details, the chances of finding the offending host are much greater.

[John_Kristoff]

It might be nice if all router vendors were able to associate the
interface configured address(es)/nets as a variable for ingress
filters. So for in the Cisco world, a simple example would be:

  interface Serial0
    ip address 192.0.2.1 255.255.255.128
    ip access-group 100 in
  !
  interface Serial1
    ip address 192.0.2.129 255.255.255.128
    ip access-group 100 in
  !
  access-list 100 permit ip $interface-routes any
  access-list 100 deny ip any any

Those sorts of features could make the scaling issue much easier
for large providers and environments where routers may have lots
of interfaces. An operator could also essentially build tools to
automatically configure/verify configurations this way, but I
think it would be better for the router vendors to do this for us.

John

[Christopher_L_Morrow]

>
> >
> >
> >
> > From: Stewart, William C (Bill), RTLSL
> > Sent: Friday, January 17, 2003 5:35 PM
> > To: 'nanog-post@trapdoor.merit.edu'
> > Subject: Re: Is there a line of defense against Distributed Reflective
> > attacks?
> >
> >
> > Many of these attacks can be mitigated by ISPs that do
> > anti-spoofing filtering on input - only accepting packets from user ports
>
>Sure, but this is a proven non-scalable solution. HOWEVER, filtering as
>close to the end host is scalable and feasible... do it there, it makes
>MUCH more sense to do it there.

Well, let's see... on dialup circuits it should be done and should be a
no-brainer. After all, ISPs are required (by UUNet at least) to push in
filters to ensure dialup users can only reach port 25 of that ISPs mail
servers and be blocked from all other spots. How hard is it to push in one
more filter that checks the source IP address of the dialup user to ensure
the address coming from the user is the one assigned?

Sure, dialups are a fixable problem, and mostly they are fixed... and....
most dialups are platforms that can't readily spoof so the threat level is
low. I'd point out one thing though, for larger dial platform providers
the decision to put filters on the radius users isn't under their direct
control... They may mandate to the people that lease the service from them
the requirement for radius profile filters, but the implementation is
solely up to the leasee. Most times its also not implemented until the
next contract cycle ;(

Anyway, you are correct, this is a fairly easy win, provided the dial
platform can support the filtering on hundreds of ppp connections. (I
don't have any good or bad data on this so I know not the scaling issues
here)

Sure, dialups are not the only problem, but it's an example of blocking
close (very close) to the edge.

Each time an ISP sells a T1 with a router and assigns a block of addresses,
there's an opportunity to configure that router with filters
(ingress/egress depending on which side you look at it from) and at least
simple firewalling rules. Is this an expense to the installing ISP, or a
cost savings in not having to deal with attacks that came from that network

This is certainly true, UUNET has been doing this for some time now...
(+1.5 years I believe?) Unfortunately, many of the larger providers only
manage a small number of their customer's CPE, this means the config is
subject to change immediately on arrival at customer site

I'd note that UUNET also went through some pain to push CPE configs with
'good' passwds for telnet and enable, now there are tens (perhaps
hundreds) of CPE routers with 'cisco' as the vty passwd... Don't
customers' care about security? This is the issue, there aren't enough
people with 'constant vigilance' about security, Convenience is always
more important Never mind that their CPE device is now being used to
DoS several hosts on the internet and their link charges are showing that
each month... that cost isn't enough for them to change their ways.

later? Even when a customer provides the CPE, providing sample
configurations really costs little and would help. In many cases, the
vendor supplying that T1 is one of the same companies which also handles
the "core" so it's REALLY in their best interest to take little steps to
protect their edges (hard to point fingers from the core and say "it's the
edge vendor's problem" when you're also the edge vendor in some cases).

Ok, so here we get to the meat of my arguement. The end user needs to
filter, they know best what/where/how their network is used. The 'core'
provider simply knows that there are 6 /24's and a /23 routed to the T1 in
question. The filtering can be MUCH more effective at the end user site,
where each ether interface can include a simple 1 line acl that fixes the
problems of spoofing.

There was some chatter at NANOG in Oregon last October about some
'default' settings on interfaces for 'small' routers that would accomplish
this task. I believe it was 'turn on uRPF strict for all small platform
routers' and make it a simple 'no uRPF' to turn it off. Barry Greene or
the other Cisco fellow in the back of the room should recall more
precisely, eh? This seems like a great first step, keeping in mind that
its a year or more to roll that out, atleast its a start

While it's nice that router vendors implemented unicast RPF to make
configuration in some cases easier, using simple ACLs isn't necessarily
hard at the edges either.

This completely depends on the part of the edge you run... ask Ebay how it
is to filter on their Gig ports facing their servers, or Microsoft on
their 10Gig interfaces... acls suck when packet rates increase, uRPF is a
win here since it is just a FIB lookup, not a acl processing task. (Yes,
10Gig ints likely have acls in asics, but point is fib lookups win.)

The stumbling block for ingress filtering has always been pretty simple: By
implementing ingress, the network you save will be someone else's. You have
to trust that other network operators will implement ingress filtering and
in so doing save your network. Sadly, folks tend to avoid doing things that
might help others, and so I continue to wait for a negligence lawsuit to
wake folks up on this issue.

Actually, the stumbling block has been getting end users to do it... the
core is just not the place to do this, too complex to do and not enough
granularity at that level.

Eliminating spoofed addresses from the backbone, even if it were possible
to do 100%, would not eliminate denial of service attacks. The DDoS attacks

This was precisely the point of Mr. Gill from AOL at the aforementioned
NANOG meeting, I believe his quote goes something like: "The ip address
used for the attack is orthogonal to the problem..." To me this makes
perfect sense... People really do get stuck on the red herring of
'stopping all spoofing'. That isn't the problem, as you say below here its
trivial to use owned hosts by the thousands to attack with unspoofed
addresses... Rob Thomas has some good data on attacks against IRC
servers and other hosts on the internet, his data last I recall was
something like 80% of attacks use spoofed addresses, though more and more
his tracked attacks are showing from non-spoofed hosts. He can certainly
jump in and correct me though I can speak authoritatively from the
network I work on's perspective on this issue, more and more we have seen
non-spoofed attacks. There are still plenty of spoofed attacks, but
frankly we prefer that as its MUCH easier to track and stop.

For those that wonder 'how would you track that? It's spoofed!' please
visit: http://www.secsup.org and read the provided links... its simple,
free, proven, tested and used everyday by atleast UUNET and I believe
Sprint? If you have an upstream you should push them to implement these
things also so you can be protected and get resolution faster... or like I
said, switch to a provider that DOES these things and HAS a security crew
on staff 24/7. Its in your best interest if you think you might be a
target.

[Rabbi_Rob_Thomas]

Hi, NANOGers.

You just knew I couldn't stay out of this thread for long.

] I'd note that UUNET also went through some pain to push CPE configs with
] 'good' passwds for telnet and enable, now there are tens (perhaps
] hundreds) of CPE routers with 'cisco' as the vty passwd... Don't

During the year 2002 I added at least 17683 compromised Cisco routers
to my hacked device database. One bot included a list of 2827
compromised Cisco routers for use as bounces. Most of these are CPE
routers, not ISP-managed routers. All of them had cisco/cisco as the
login and password. This isn't limited to Cisco routers, however. I
collected an impressive list of broadband and other vendor routers as
well, for a total of just over 30K compromised routers in 2002. As
Chris points out, this is an issue that requires vigilance beyond
teams at ISPs.

] addresses... Rob Thomas has some good data on attacks against IRC
] servers and other hosts on the internet, his data last I recall was
] something like 80% of attacks use spoofed addresses, though more and more

In 2002 I logged several thousand DDoS attacks. Approximately 70%
used bogon source addresses or spoofing, but that trend was changing
by the end of the year. In 2003 I have logged approximately 267 DDoS
attacks, NONE of which used spoofing. Does anti-spoofing help?
Absolutely! Is it a cure-all? No.

The combination of very large (circa 94K) botnets and DoSnets and the
failure of many providers to respond to abuse alerts means that the
miscreants don't generally need to spoof.

A study I performed of an often-attacked site showed that a bit over
60% of all the naughty packets were from _obvious_ bogon addresses.
The total amount of spoofing is difficult to deduce. You can view
the data included in a presentation here:

http://www.cymru.com/Presentations/60Days.ppt
http://www.cymru.com/Presentations/60Days.zip

Blocking spoofing and bogons (remember, uRPF works best if the RIB is
free from garbage) is worth the time. Building a strong and
motivated security team is even more valuable.

] For those that wonder 'how would you track that? It's spoofed!' please
] visit: http://www.secsup.org and read the provided links... its simple,

This is an excellent resource, and I encourage everyone to review it.
Tracking spoofed-source attacks is far easier than you may believe.
I have a lesser and rather lame method here:

http://www.cymru.com/Documents/tracking-spoofed.html

The method from UUNET is far superior. The point is that spoofed
source packets can be tracked.

All that aside, the method and ease of tracking makes no difference
if the source of pain is unwilling or unable to respond. I'm certain
everyone now realizes that Internet security is all about "The Other
Guy."

Thanks,
Rob.

[ASV]

you could partly get around this by blocking all 'SYN' packets going to
your customers
Unless/until the kiddies start using UDP... messy.

[Chris_Adams3]

Once upon a time, John Kristoff <jtk@aharp.is-net.depaul.edu> said:

It might be nice if all router vendors were able to associate the
interface configured address(es)/nets as a variable for ingress
filters. So for in the Cisco world, a simple example would be:

  interface Serial0
    ip address 192.0.2.1 255.255.255.128
    ip access-group 100 in
  !
  interface Serial1
    ip address 192.0.2.129 255.255.255.128
    ip access-group 100 in
  !
  access-list 100 permit ip $interface-routes any
  access-list 100 deny ip any any

How is this different than "ip verify unicast reverse-path" (modulo CEF
problems and bugs, which of course NEVER happen )?

Multihomed customers are more interesting, but if all the single homed
customers had uRPF (or $VENDOR's equivalent) enabled it would cut down
on a significant amount of the spoofed traffic.

[Christopher_L_Morrow]

> > Eliminating spoofed addresses from the backbone, even if it were possible
> > to do 100%, would not eliminate denial of service attacks. The DDoS attacks
>
> This was precisely the point of Mr. Gill from AOL at the aforementioned
> NANOG meeting, I believe his quote goes something like: "The ip address
> used for the attack is orthogonal to the problem..." To me this makes
> perfect sense... People really do get stuck on the red herring of
> 'stopping all spoofing'. That isn't the problem, as you say below here its
> trivial to use owned hosts by the thousands to attack with unspoofed
> addresses... Rob Thomas has some good data on attacks against IRC
> servers and other hosts on the internet, his data last I recall was
> something like 80% of attacks use spoofed addresses, though more and more
> his tracked attacks are showing from non-spoofed hosts. He can certainly
> jump in and correct me though I can speak authoritatively from the
> network I work on's perspective on this issue, more and more we have seen
> non-spoofed attacks. There are still plenty of spoofed attacks, but
> frankly we prefer that as its MUCH easier to track and stop.

you could partly get around this by blocking all 'SYN' packets going to
your customers

and we are hoping none are hosting webservers or mail servers or....
right? Oh wait! I'll just make them use my datacenters, right?? or were
you not talking about the attacks?

[Haesu]

Everyone probably knows… But if not – just a reminder that you can also add access-list number after ‘ip verify unicast reverse-path’ to allow any hosts you think that should be able to get allowed through the filter It’s convenient when you are doing some mobileIP+vpn stuff in which some type of setup breaks when there is egress filtering.

Multihomed customers should use uRPF at their Ethernet/local interface as egress filter… Using uRPF as ingress filter at ISP connections (such as Serial3/0, Pos2/0, whatever connects to your ISP’s) when you are doing BGP can be quite a nightmare… So I guess they would have to use plain-old manual access-list at their ISP-connection interfaces for ingress filtering.

i.e…

!
int Gig2/0
des backbone connection, egress
ip add 192.0.2.21 255.255.255.252
ip ver unicas reverse-path 180
!
int Pos3/0
des OC-3 from XXX ISP, ingress
ip add 199.99.99.99 255.255.255.252
ip access 101 i
!
!
acc 101 remark plain-old regular ingress filter for multihomed networks
acc 101 den ip $my_network an
acc 101 den ip 10.0.0.0 0.255.255.255 an
acc 101 den ip 172.16.0.0 0.15.255.255 an
acc 101 den ip 192.168.0.0 0.0.255.255 an
acc 101 per ip an an
acc 180 remark exceptions to egress filtering
acc 180 per ip host 199.59.9.110 an
!
!

-hc

Chris Adams wrote:

[John_Kristoff]

It would be useful for all sorts of things besides verifying a source
address. So in addition to complicated configurations such as multi-
homing/paths that you mention, it could also be useful for standard
filters on protocols, ports, logging and so on.

John

[ASV]

I was refering specifically to end user workstations. For example home
machines on dial up or broadband connections.
A lot of broadband providers already prohibit running servers and block
certain inbound ports (eg 21 and 80).
*shrug* just seems like it would make more sense to block all incoming
'syn' packets.
Wouldn't that be faster than inspecting the destination port against two
seperate rules?

I don't know how these operators do their blocking..

[Johannes_Ullrich]

*shrug* just seems like it would make more sense to block all incoming
'syn' packets.
Wouldn't that be faster than inspecting the destination port against two
seperate rules?

blocking all SYN's will break too much other stuff (Instant Messangers,
games ...). I think we would be much better off if they (consumer ISPs)
would block 135-139 and 445, maybe 21 and 80.

The rest could be handled with a simple IDS (doesn't even need
to match patterns... just count packets going to 27374 and the like)

I keep saying ISPs would be much better off if they implement these
filters. But not all of them agree. IMHO: less 'zombies' -> better
service -> less support phonecalls.

[todd_glassey]

Christopher, IP filtering is something that needs to be legally mandated and
put in place at both ends. Any tier-2/3 provider should be held accountable
for any fraud's that they enable their customers to commit, since there is
no other technical point of responsibility possible. As to spoofed IP's that
also is an issue, and the failure of the ISP's to put in place an
infrastructure where they could enact better controls is part in parcel to
their public denial of responsibility for what their customers do.

But I think that those days are rapidly coming to a close, and the Network
Providers will be called to task. As to TCP/IP and the inherent design flaws
that allow people to spoof it, those to are much the responsibility of the
"networking community" as a whole as well and need to be addressed therein.

You nor any of the ISP's may like this but the facts of the matter are
pretty clean and easily discerned and they all point to the Governance Model
for developing and releasing protocols whole cloth on the Internet, no
matter what they enable people to do. Its time to take a close accounting of
what this "Internet" thing really is and put some stronger legislation in
place.

Todd Glassey

[Rabbi_Rob_Thomas]

Hi, NANOGers.

] The rest could be handled with a simple IDS (doesn't even need
] to match patterns... just count packets going to 27374 and the like)

There is no "simple IDS" for OC48+ links. Counters are possible,
though adding that many ACLs can be more than burdensome on certain
code and hardware releases. Don't even mention logging. While
some ports are more obvious than others, there is still the question
of what is in the payload of a packet that increments a counter. It
may be quite benign, e.g. a SYN packet to port 80 from source port
27374.

At the edge some of these things are quite possible. At aggregation
and transit points, however, such suggestions don't scale.

] I keep saying ISPs would be much better off if they implement these
] filters. But not all of them agree. IMHO: less 'zombies' -> better
] service -> less support phonecalls.

I agree.

Thanks,
Rob.

[Christopher_L_Morrow]

> > you could partly get around this by blocking all 'SYN' packets going to
> > your customers
>
> and we are hoping none are hosting webservers or mail servers or....
> right? Oh wait! I'll just make them use my datacenters, right?? or were
> you not talking about the attacks?

I was refering specifically to end user workstations. For example home
machines on dial up or broadband connections.
A lot of broadband providers already prohibit running servers and block
certain inbound ports (eg 21 and 80).
*shrug* just seems like it would make more sense to block all incoming
'syn' packets.

Doesn't this stop kazaa/morpheus/gnutella/FTP/<some aim stuff like private

? This is a problematic setup, and woudl require the cable modem

provider to maintain a quickly changing 'firewall' I understand the
want to do it, but I'm not sure its practical to see it happen based
solely on the hassle factor Hmm, security, "you gotta pay to play"
(Some famous man once said that I believe)

[ASV]

Indeed it does break that. P2P clients: Mostly transfer illegal content.
As much as a lot of people love using these, I'm sure most realise they're
on borrowed time in their current state.
And I'm sure that if they were gone tomorrow, I'm sure they'd be back in
another fashion soon.
Ftp/HTTP etc I believe most cable providers currently block these anyway

There's a chance it'd break things like file transfers on IM clients but
I'm sure they'd be altered too.

[Jeff_Workman]

Stoned koalas drooled eucalyptus spit in awe as Avleen Vig exclaimed:

Doesn't this stop kazaa/morpheus/gnutella/FTP/<some aim stuff like
private chats>? This is a problematic setup, and woudl require the cable
modem provider to maintain a quickly changing 'firewall' I understand
the want to do it, but I'm not sure its practical to see it happen based
solely on the hassle factor Hmm, security, "you gotta pay to play"
(Some famous man once said that I believe)

Indeed it does break that. P2P clients: Mostly transfer illegal content.
As much as a lot of people love using these, I'm sure most realise they're
on borrowed time in their current state.

And it's your job as a network provider to determine the legality of your users' activities? Plus, you said the magic word "mostly" What about legit uses of P2P networks? Do you also stop your users from using NNTP as well, since it's "mostly" used for porn and warez? How about email? since, from the looks of my mail logs, SMTP traffic is "mostly" spam and sircam.

I'm sure your users would certainly pack up and take their business elsewhere if you placed these restrictions on them. Why not just put them all behind a firewall on RFC-1918 addresses, if you are going to block all incoming SYNs?

And I'm sure that if they were gone tomorrow, I'm sure they'd be back in
another fashion soon.

Any true P2P system is going to need at least one end user to receive a SYN.

Ftp/HTTP etc I believe most cable providers currently block these anyway

I also believe this is usually stated in their TOS that they're not allowed to run services on their home computers. If I'm on IRC and I initiate an outgoing DCC chat, the open port on my box awaiting the connection is hardly a "service."

There's a chance it'd break things like file transfers on IM clients but
I'm sure they'd be altered too.

Unless I'm missing something, wouldn't it be necessary to modify both the clients and the servers to pass all FT traffic through the servers? I'm sure those who sell bandwidth to AOL and Yahoo would love it if they did that, but I don't see it happening.

-Jeff

[Christopher_L_Morrow]

> Doesn't this stop kazaa/morpheus/gnutella/FTP/<some aim stuff like private
> >? This is a problematic setup, and woudl require the cable modem
> provider to maintain a quickly changing 'firewall' I understand the
> want to do it, but I'm not sure its practical to see it happen based
> solely on the hassle factor Hmm, security, "you gotta pay to play"
> (Some famous man once said that I believe)

Indeed it does break that. P2P clients: Mostly transfer illegal content.
As much as a lot of people love using these, I'm sure most realise they're
on borrowed time in their current state.
And I'm sure that if they were gone tomorrow, I'm sure they'd be back in
another fashion soon.

That may be, but its still a problem... I believe http and ftp also
transfer illegal content, should we shut them down? Email too? Often there
is illegal content in email.

Ftp/HTTP etc I believe most cable providers currently block these anyway

for FTP I was talking about non-passive data traffic.

[ASV]

Ok before this gets out of hand
I wasn't talking about ISP's policing their customers in any way.
I was merely stating that the blocking of inbound SYN packets would put a
dent in the number of usable zombie DoS clients while at th same time
having the side effect of breaking other server-type software such as P2P
clients.

I also went on to state that if the functionality of such clients really
did break as a result of this, the majority of people wouldn't have (too
much) of a right to complain as the clients are (mostly) used for illegal
traffic. Yes this would probably cause a large loss of business in *some*
areas where multiple broadband providers are availible. In other places
where a broadband monopoly exists, you would either see a switch to
business level contracts or a slight dip in business or people just living
with it.

For the record I'm not in favour of ISP's (or anyone else for that matter)
policing the internet.