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

["Mike O'Connor" <mike@xxxxxxxxxx>]

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.
At 10:38 AM 8/7/2008, Dave Piscitello wrote:
> It occurred to me that we have had numerous, valuable threads 
> regarding solutions, and many expressions of concerns of scope, 
> cost, impact. These are all good activities.
> What we may be missing among all these is a framework for what any 
> resulting (set of) solutions we recommend would be 
> deployed/implemented and by whom.
> In an admittedly simplistic fashion, I think the following is a 
> strawman for a multi-organizational approach to "combating fast 
> flux" that could be applied to future attacks and abuses
- Improve our definition of fast flux

- Develop & test algorithms to detect fast flux (somewhat out of 
scope for ICANN)
>    * 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 
(somewhat out of scope for ICANN)
>    * 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.
> If we were to lay out a proposal in this fashion, I think we could 
> then discuss pros/cons more objectively. We might even be able to 
> add clarity to issues that make some folks uncomfortable so that the 
> proposal addresses (or at least offers) sufficient checks and 
> balances to hopefully make everyone comfortable with what we 
> recommend to the GNSO.
> Hope this helps.
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.138 / Virus Database: 270.5.12/1597 - Release Date: 
> 8/7/2008 5:54 AM