ICANN ICANN Email List Archives

[gnso-ff-pdp-may08]


<<< Chronological Index >>>    <<< Thread Index >>>

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

  • To: "gnso-ff-pdp-May08@xxxxxxxxx" <gnso-ff-pdp-May08@xxxxxxxxx>
  • Subject: [gnso-ff-pdp-may08] DTeam - framework for proposal
  • From: Dave Piscitello <dave.piscitello@xxxxxxxxx>
  • Date: Thu, 7 Aug 2008 08:38:02 -0700

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


 *   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?"


 *   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?"


 *   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?"


 *   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.


<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy