> On Jul 28, 2016, at 7:30 PM, Donn Lasher via NANOG <nanog@nanog.org> wrote:
>
> On 7/28/16, 10:17 AM, "NANOG on behalf of J. Oquendo"
> <nanog-boun...@nanog.org on behalf of joque...@e-fensive.net> wrote:
>
>
>> While many are chanting: #NetworkLivesMatter, I have yet
>> to see, read, or hear about any network provider being
>> the first to set precedence by either de-peering, or
>> blocking traffic from Cloudflare. There is a lot of
>> keyboard posturing: "I am mad and I am not going to take
>> it anymore" hooplah but no one is lifting a finger to
>> do anything other than regurgitate "I am mad... This is
>> criminal."
>
> (long discussion, was waiting for a place to jump in..)
>
> If we want to be accurate about it, Cloudflare doesn’t host the DDoS, they
> protect the website of seller of the product. We shouldn’t be de-peering
> Cloud Flare over sites they protect any more than we would de-peer GoDaddy
> over sites they host, some of which, no doubt, sell gray/black market/illegal
> items/services.
>
> If, on the other hand, you can find a specific network actually generating
> the volumes of DDoS, you should have a conversation about de-peering….
>
> $0.02…
On one hand, I agree with you… “We should no more de-peer Cloud Flare over
sites they protect than we would de-peer GoDaddy over sites they host.”
However, if GoDaddy or Cloud Flare consistently refused to take down sites
which specifically sell malicious activities as a service, I see no reason not
to consider de-peering either one of them.
I’m not well enough versed in the exact details of the alleged
actions/non-actions of CF in this scenario, but the idea that we should not
apply rational peer pressure against the accessible indirect party in favor of
playing whack-a-mole with the less accessible directly offending party seems
patently absurd to me.
The actual dDOS is probably not even performed by the company advertising the
service, but rather by one ore more bot-nets that they either directly control
(pwn, but don’t own) or contract (someone else pwned the machines and sells bot
services to them).
It’s one thing if a site is advertising legitimate load or stress testing
abilities and is conducting itself in an ethical manner.
Its an entirely different matter if the site is advertising their ability to
carry out malicious attacks for hire (e.g. “We can take down XYZ for mere
pennies per hour.”, etc.).
In the latter case, I would expect any ethical company that found themselves
hosting such content to take swift action against such a customer for TOS/AUP
violation. In the former, there’s likely nothing wrong there and while you may
not like what they do, it may well be a legitimate service, none-the-less.
Now there is a bit of a grey area which probably merits consideration… What if
company A runs a web-site. They are a transit customer of company B. Company C
is the VPS hosting company which is under contract to company D to provide
machines and bandwidth for their “Security Testing Products.”.
(Quick cheat-diagram to make the rest easier to follow)
[Web Site A] <-> [Transit B] <-> {internet} <-> [VPS Host C] <-> [“Security
Contractor” D]
Suppose company A dramatically overestimates their needed stress level for a
traffic test and contracts company D to send them a stress test which turns out
to overwhelm the peering between B and C.
Clearly, this is problematic to both B and C, but it’s not clear that it’s an
actual violation or that either A or D has actually done anything wrong, per
se. I would expect D to cease and desist promptly upon notification from C or
A. Ideally they would also politely cease and desist upon credible request from
company B, but the definition of credible is somewhat difficult here and may be
subjective (B will generally consider themselves credible whether C does or
not).
The problem may extend further, depending on whether B and C are directly
peered or are connected via some additional set of transit networks in between.
(see footnote [1] for exact definitions of peering and transit intended in
this message. Short version: packet flow, not money).
Obviously the more transit networks impacted, the more complex the issue
becomes.
Owen
[1]
peering: The advertising of routes to and acceptance of packets for ones own
autonomous system(s) and those autonomous systems for which you provide transit.
transit: The advertising of all known routes, default, or some superset of the
above definition of peering and the willingness to accept, carry, and pass
along packets destined to other peers and/or transit providers beyond the
limits set by peering above.
