Re: [gnso-ff-pdp-may08] DTeam - framework for proposal

[Dave Piscitello <dave.piscitello@xxxxxxxxx>]

I'm comfortable adding these to my item list for the sake of continuing the 
discussion.

I would like to set the discussion of what is in or out of scope for ICANN or 
any party to this process for the moment, if that's agreeable to all. Can we 
agree to flesh out the task list as fully as possible, walk through it to find 
and correct the flaws, and then go back to discuss what is in/out of scope and 
for whom?

Also, I notice we bury so much of our progress in nested emails and this makes 
it very hard for everyone to keep up. I'm republishing my list with Mike's 
additions:



 *   Develop & test algorithms to detect fast flux


 *   quantify the attack. We are slowly teasing out the characteristics we use 
to identify a fast flux network based in input from Joe, me, Greg, Randy, Eric, 
Mark and others. This effort also helps us identify the data required to 
quantify the attack. This answers the question, "What is it that we want to 
detect?"


 *   develop a methodology/tool that has a very high probability of detecting 
the attack and a very low probability of reporting a false positive (Joe's 
tool, TMF, etc. are examples of detection methods and tools). This answers the 
question, "How can we detect it?"


 *   establish a preliminary false-positives accuracy target (.1%,001%,  
.00001% ?)


 *   Develop detection software based on approved algorithms and targets


 *   identify the data collectors. Marc and others have identified various 
sources of data and perhaps it would be helpful to identify the parties (e.g., 
registrars and registries) who collect it. This answers the question, "Who can 
provide the data we need to detect it?"


 *   Conduct pilot tests of detection software with volunteer domain 
service-providers


 *   identify the approved users of the data. The range of users spans from 
"anyone with an internet connection" to "parties who are trusted to use the 
data". For the sake of this strawman, let's go with the trusted party end of 
this spectrum. This answers the question, "Who is responsible for detecting it?"


 *   Develop suggested/model service-level (and liability) agreements between 
detection service-providers and domain service-providers


 *   identify the "trust model" for approved data users. We want a high 
confidence that the parties will act in the best interests of the community at 
large, for users and registrants. This answers the question, "Why do we entrust 
these individuals to detect it?"


 *   identify the access and reporting model for the approved data users. We 
have proposals ranging from publishing additional information via the DNS using 
TXT records to SSL gateway portals that provide WDPRS reporting like 
capabilities. This answers the questions, "How do the trusted parties acquire 
data they need, and report abuse?", "How do we keep the data from falling into 
the hands of folks who would misuse the data?", and "How do we keep bad actors 
from disrupting the access method?"

identify the responders and the response. In several models, we've discussed 
accelerated suspension of domains by registrars and registries, with processes 
for reinstatement, etc.


On 8/7/08 12:07 PM, "Mike O'Connor" <mike@xxxxxxxxxx> wrote:



really nice work Dave.

i'm going to intersperse a few points amongst yours, based on the
version .01 document i circulated, plus some ideas that came to me
while reading your post.