but i am not foolish enough to believe that religious ranting on mailing lists is gonna change anyone from doing what makes business sense for their network.
Indeed! And it is not going to change the minds of the majority of network operations folks who are not on the NANOG list nor the majority of telecoms executives who are also not on the NANOG list. Back in the old days, the NANOG list did hold the majority of Internet operations folks so new ideas like flap dampening were able to spread quickly. But those days are long gone. NANOG still has an important educational role but it is no longer based on being part of the old boys club and knowing the secret handshake. In other words, there is no cohesive society of network operators which can be swayed by attempts at social engineering like shaming or cajoling. BCP 38 has had its day. Nowadays, it is more important to look at how to mitigate current DDoS techniques and to describe the larger problem and look for larger solutions. However, any attempt at larger solutions require a large amount of humility because nobody can say for sure, what will work and what won't. The fact remains that there is not a good technical method for mitigating large scale distributed DDoS that results in LARGE TRAFFIC FLOWS ENTERING A NETWORK FROM ALL PEERED ASES SIMULTANEOUSLY. Perhaps if we could find a way to allow the attacked AS to set ACLs automatically in all the source AS networks, that would help mitigate these attacks. For instance, consider a set of ASes which all install an ACL-setter box. These boxes all trust each other to send-receive ACL setting requests through a trusted channel. The owner of a box sets some limits on the ACLs that can be set, for instance n ACLs per AS, max ACL lifetime, etc. And the box owner also decides the subset of their routers which will accept an ACL for a given address range. Then when an attack comes in, the victim AS uses some tool to identify large sources, i.e. a CIDR block that covers some significant percentage of the source addresses in one AS. They then issue an ACL request to that AS to block the flow and the ACL takes effect almost instantaneously with no human intervention. Yes, this can result in some IP addresses being blocked unfairly, but the DDoS traffic levels often have the same impact. In any case, the AS holding the destination address is the one doing the blocking even though the mechanism is an ACL inside the source AS network. On the technical side, it is not a complex problem to put such a system in place. The complexity is largely in getting network operators to come to an agreement on the terms under which operator A will allow operator B to set ACLs in operator A's network. Until network operators see DDoS as a significant business problem, this will not happen. Note that a "business problem" does not refer solely to the direct costs of mitigating a DDoS attack. It also includes the indirect fallout which is harder to measure such as loss of goodwill, missed opportunities, etc. --Michael Dillon