RE: [gnso-ff-pdp-may08] Suggestion: Stopping fast flux doesn't cure the common cold

[Joe St Sauver <joe@xxxxxxxxxxxxxxxxxx>]

Wendy mentioned:

#Many of the harms listed under "who is harmed by fast flux" (398 and
#following) appear to be generic harms, that may be perpetrated on the
#Internet or off, via fast flux or by other techniques. I would suggest
#distinguishing betweens those that are unique to fast flux attacks (if
#there are any, such as particular aspects of the harm to hosts
#compromised into herds, or to network providers), versus those that may
#be facilitated by using fast-flux techniques or networks as a substrate
#(e.g., fraudulent transactions) but would continue to be a problem even
#if fast flux were ended tomorrow.

1) In the anti-spam community, there is a sardonic concept known as "FUSSP."

"FUSSP" stands for the "Final Ultimate Solution to the Spam Problem" and
is meant to capture the regretable reality that, in fact, there *isn't* any
final ultimate solution to the spam problem. See, for example
http://www.rhyolite.com/anti-spam/you-might-be.html

At the same time, demonstrably, there is much which can (and has) been done
to make spamming signficantly more difficult for spammers, although 
there's obviously still much additional work yet to be done. 

The relevance of FUSSP to this discussion is this: if we are only willing 
to work on the "Final Ultimate Solution to the Problems Enabled By Fast Flux"
(FUSPEFF), we have set an (intentionally?) impossible bar to surmount.

There is no FUSPEFF. Fixing the fast flux problem will not completely 
eliminate the online distribution of child pornography, nor the online 
sale of addictive drugs, nor the problem of phishing, etc. But, if we work 
to successfully attack the problem of fast flux at the same time other 
entities work on other aspects of cyber crime, we can and will make it 
materially harder for many cyber criminals to operate with impunity.

Remember that most cyber criminals have a business model that relies on
driving "customers" to a web site, where that web site may be selling
Oxycodone w/o a prescription or asking users to "update" their credit 
card information, or whatever. If you can deny cyber criminals bullet 
proof hosting, suddenly their online world becomes substantially less
operationally friendly. 

2) Moreover, let us look once more at our charge/charter (see 
https://st.icann.org/gnso-council/index.cgi?fast_flux ). What does it 
ask of us? 

The questions we are asked to address include:

-- Who benefits from fast flux, and who is HARMED?

-- Who would benefit from cessation of the practice and who would be 
   HARMED?

-- How are registrants AFFECTED by fast flux hosting?

-- How are Internet users AFFECTED by fast flux hosting?

-- What technical, e.g. changes to the way in which DNS updates 
   operate, and policy, e.g. changes to registry/registrar agreements or 
   rules governing permissible registrant behavior measures could be 
   implemented by registries and registrars to mitigate the NEGATIVE
   EFFECTS of fast flux?

-- What would be the IMPACT (positive or NEGATIVE) of establishing 
   limitations, guidelines, or restrictions on registrants, registrars 
   and/or registries with respect to practices that enable or facilitate 
   fast flux hosting? What would be the IMPACT of these limitations, 
   guidelines, or restrictions to product and service innovation?

[emphasis added above as capitalized words]

So note:

-- The vast majority of the questions we were taksed to address ask us to 
   consider HARMS, or how constituencies are AFFECTED, or to think 
   critically about IMPACTS. I know that some members of the group may 
   not want to talk about HARM or EFFECTS or IMPACTS but that's what
   our charter asks us to do.

-- I also recognize that by fully describing the harms that fast flux 
   enables, we make it clear that fast flux is being used for some truely
   apalling purposes. I understand that undescoring that badness 
   doesn't help the position of those who'd prefer ICANN ignore fast 
   flux. Sorry, but I believe that ICANN *should* work on fast flux,
   in part because the problems it enables ARE so bad.

#We do not want to imply that stopping fast flux would eliminate the need
#for other anti-abuse or law enforcement work, nor to exaggerate the
#benefits of this attack technique to would-be malefactors.

I think it is hard to overexaggerate the benefits of fast flux web hosting
to miscreants. Just to mention a few examples:

-- Suddenly, once you're using fast flux, it becomes very difficult to
   take down an unlawful web site unless you can get the fast flux 
   domain killed; that, truly, is about as close as you can get to 
   absolutely "bulletproof" web hosting

-- Using fast flux web hosting makes identification of the owner and 
   operator of a FF domain all the more difficult since there's no
   longer IP whois information which can be investigated

-- Fast flux techniques faciliate the distribution of volumnious online
   objects (such as pirated software) because the miscreant no longer
   needs to worry about disk storage or network bandwidth -- they'll
   just happily use as much of yours as they want. 

-- Fast flux hosting "complicates the conversation" and "distracts" LE, 
   judges and other parties when working a cyber crime incident. 

   That is, rather than being able to focus exclusively on the phishing
   (or whatever) substantive ill that's going on, singificant time and
   effort often needs to be expended explaining what fast flux is, how 
   it was used in a particular case, why you can't just "turn that
   server off," etc., instead.

-- Fast flux provides a way for miscreants to monetize the waves of
   still-compromised PCs which can no longer be used for spamming due
   to things like block listings or provider filtering of customer 
   port 25 traffic (except to the provider's mail server(s)). 

-- Fast flux provides a business foundation for a range of other
   online miscreant services, such as bullet proof domain name
   registrations, bullet proof name servers, etc. 

For the reasons mentioned above, I oppose Wendy's proposed approach.

Regards,

Joe