The RIPE IRR database contains a systemic means for operators,
responsible for IP address blocks, to exchange PGP-signed messages
amongst each-other in relation to security incidents. It
unfortunately does not see much use: under 1% of allocations in RIPE's
database include any reference to one of only 235 "incident response
teams," which are conceptually similar to a POC.
Other things have been tried but haven't reached "critical mass" also,
such as dial-by-ASN VOIP connectivity.
The real problem with handling serious network abuse is it's pretty
hard to get through the "bozo filter" and actually reach anyone who
might understand your request or complaint (DDoS), let alone have the
power to act. The anti-spam folks have honestly made this problem
far, far worse, by slamming every role mailbox they can find for every
network operator, regardless of whether or not a specific mailbox for
email-related abuse exists or how good (or bad) a network may be at
keeping spam off its network. I hope this remark doesn't steer the
thread far off-topic, but I wish the anti-spam folks would realize how
counter-productive it is to intentionally send the same complaints to
a multitude of different abuse mailboxes.
For this reason, it really is necessary to have an automatic filtering
mechanism in place just to make sure the network abuse people don't
have to sift through messages which are mostly related to email abuse.
If operators would decide to use a system like IRT, supported in RIPE
IRR, then we would not only be able to filter out a lot of the B.S.,
we would also know that signed messages complaining of DDoS coming in
were actually from the security folks at the complaining organization,
people who have authority to make requests on behalf of the org that
"owns" related netblocks.
This pretty much eliminates the "why should I believe your evidence?"
argument, because we shouldn't have to believe anyone's evidence to at
least block traffic towards the netblocks they operate.
For example: if I am an end-user with address 192.0.2.80 and my web
site is being subject to DDoS which I believe is originating from
203.0.113.66, I would contact my ISP, who registers themselves as the
IRT for 192.0.2.0/24. My ISP would probably do a sanity check on my
claim, examine their netflow, etc. and then agree that 203.0.113.66 is
a source of the DDoS. They'd see that an IRT is registered for
203.0.113.0/24 and send over a PGP-signed message to the counter-party
IRT. That IRT would verify the PGP signature and association with the
target of the DoS, 192.0.2.80, and at that point, they would have
absolutely zero excuse for not immediately dropping all traffic from
203.0.113.66 towards me at 192.0.2.80.
It doesn't matter if there are any logs or "evidence," it matters that
the proven security/abuse contact for 192.0.2.0/24 requested that the
counter-party stop sending traffic to 192.0.2.0/24. Whether or not
the ISP for 203.0.113.66 decides to investigate any further is up to
them; maybe they log some traffic, find a compromised host, and shut
it down. Maybe they really don't care.
Now that you know people are capable of doing all that based on data
in RIPE's trusted IRR database, you may also realize that this process
could be streamlined to any point between "human reads email, checks
relationships, and configures network" all the way to "script reads
email, checks relationships, and configures network." Implementing
this could save NOCs time (if they really cared about outgoing DDoS
from their networks) and improve response to network abuse.
So ultimately, there is already a good framework in place to
substantially "fix" this problem. No one uses it. That is unlikely
to change until there is an economic incentive, such as a lawsuit by
someone targeted by DoS which can be proven to be originated from a
negligent network, causing calculable damages. Until some network has
to pay out a million bucks because they sat on their hands, I don't
see anything changing.