Re: Cloudflare, dirty networks and politricks

[Owen DeLong <owen () delong com>]

> 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-bounces () nanog org on behalf of joquendo () 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.