Re: [gnso-ff-pdp-may08] DTeam - framework for proposal
- To: "gnso-ff-pdp-May08@xxxxxxxxx" <gnso-ff-pdp-May08@xxxxxxxxx>
- Subject: Re: [gnso-ff-pdp-may08] DTeam - framework for proposal
- From: "Mike O'Connor" <mike@xxxxxxxxxx>
- Date: Thu, 07 Aug 2008 11:07:56 -0500
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
* 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