fastflux challenges: measurement, data sharing, "enforcement"

[k claffy <kc@xxxxxxxxx>]

The comments on the web site, as well as ICANN's report,
already cover the issues pretty well, but i want to emphasize
a point others are making more subtly:

The notion that we cannot distinguish legitimate from 'aiding
and abetting malware' fastflux behavior only holds on paper.
On the Internet, there are so many measurable differences
distinguishing the two is not the problem.  Of course humans
must create the instrumentation and interpret the measurements,
as with all science. But even the one case mentioned as "hard to
categorize" (ultrashort) had consensus on the list, and that
was with what everyone admitted was incomplete data being used
hypothetically. I am not aware of a case that multiple people
acknowledge is a tricky false positive, but even if there were,
procedural safeguards (whitelists, rapid review of suspected 
false positives) can render the risk of damage negigible.

My understanding is that fastflux false positives is not the
problem here -- we can solve that with measurement technology 
and rigorous analysis and transparent policies.  Implementing
the measurements and sharing the data and regulating against
/ responding to the illict behavior at the required time
granularity are the problems (Will the registrar in China or
Ukraine even pick up the phone?).  The report suggests ICANN 
does not want to take on these challenges without a broad community
mandate, whatever that looks like. I agree that's going to be
uncharted territory for ICANN -- and for the rest of us --
even with a "community mandate."  This preliminary report and
public cataloguing of concerns are excellent steps forward.

k