ICANN ICANN Email List Archives

[gnso-ff-pdp-may08]


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

[gnso-ff-pdp-may08] Wording for Possible Next Steps data collection

  • To: gnso-ff-pdp-May08@xxxxxxxxx
  • Subject: [gnso-ff-pdp-may08] Wording for Possible Next Steps data collection
  • From: Joe St Sauver <joe@xxxxxxxxxxxxxxxxxx>
  • Date: Fri, 14 Nov 2008 10:17:00 -0800

The following is draft language for one possible next step:

FFDRS (Fast Flux Data Reporting System)
---------------------------------------

Collection of data about fast flux is an integral part of the
work of this group, and the foundation for future analysis of
the fast flux issue.

Currently there is no publicly available formal mechanism for 
members of the community to submit potential fast flux domains 
for consideration by the working group.

The Whois Data Problem Reporting Service (WDPRS), see
http://wdprs.internic.net/ , is an excellent example of a
existing public domain name-related data submission
mechanism similar to what we have in mind, albeit one that's 
focussed on whois data problems rather than the fast flux problem. 

Another example of a public cyber-security-related domain name 
problem submission portal is Phishtank, http://www.phishtank.com/

A recommended next step from this working group is the 
creation of a similar web submission form focussed on fast flux
domains. Such a site would allow individuals to "send in" or 
"submit" potential fast flux domains they've encountered.

The minimum required information for a submisison would simply 
be a fully qualified domain name which the submitter believes to 
be "fast flux." 

Each such submission should receive a unique "reference number" 
or "submission number."

For each submission, the FFDRS should:

-- Automatically compute a Mannheim score for each domain based 
   on at least one resolution of the domain name [sample working 
   implementation temporarily available at 
   http://www.uoregon.edu/~joe/fastflux/simple.cgi as an example
   of how this can be done; Marika, please remove this note from
   the text included in the report, it is meant just for discussion
   by the working group members since I may disable or remove that 
   demonstration/proof of concept cgi at any time]

   The one-pass Mannheim score and associated data should be compiled 
   as part of the record associated with that domain name. 

   Other fast flux scoring methods which may be proposed by the 
   working group should also be considered for future integration
   into the FFDRS.

-- The FFDRS should also automatically compute a Mannheim score for 
   each associated name server, thereby screening for potential 
   double flux domains

   Caching should be used where appropriate throughout the system.

-- If a fully qualified domain name meets or exceeds the threshold
   of the Mannheim method, the registrar (and registration service
   provider, if applicable) should be added to the data set
   associated with that domain name

-- Various mechanisms could be used to avoid abuse/frivilous
   reports. For example, email confirmation could be used
   (as it currently is with WDPRS), or a service specific 
   username and password facility could be used (as Phishtank
   does), or dataset filtering prior to distribution could be
   offered as an option to allow researchers and staff to avoid 
   frivilous submissions (e.g., allow researchers requesting data 
   to specify that only records meeting a particular Mannheim
   score threshold be included in the extract they receive). 

-- Users should also be given the opportunity to explain why
   they believe the domain or domains they're nominating are
   fast flux, the ability to explain if they believe a 
   domain has some characteristics of fast flux while being
   non-malicious/legitimate in nature, and any other relevant
   explanatory information they'd like to submit. Freeform 
   text of this sort should be limited in length, and suppressable
   on request by researchers requesting access to the data.

-- For submitter convenience, the submission form should allow
   multiple domain names to be submitted in bulk by cutting 
   and pasting multiple domain names into the form, one fully
   qualified domain name per line. Reasonable limits may be
   established on the number of lines submitted and the format
   of those submissions (e.g., submitted FQDNs shall be plain
   text only)

-- Data submitted via the portal, with the exception of 
   submitter identification information which could be suppressed
   from public disclosure on request, would be made available to
   the working group, researchers and other interested members of 
   the public and should also be publicly summarized on a monthly
   basis by staff, provided at least one hundred unique domain 
   name submissions have been received over the course of any given 
   month.

Data collected this way would serve multiple purposes:

-- it would provide raw data for analysis by the working group
   and interested researchers

-- it would be a first step toward documenting the magnitude
   of the fast flux problem

-- it would help us to refine our collective definition of fast 
   flux,

-- it would create a framework potentially allowing us to test 
   various candidate operational fast flux scoring rules

-- it would allow members of the public to submit examples of
   legtimate/non-malicious domains that exhibit some fast
   flux-related characteristics, helping us to better understand
   that aspect of the issue

-- it would help us to understand if there is any discernable 
   pattern to the distribution of fast flux domains across the
   population of registrars

-- it would be a tangible way of helping to assess interest
   in the fast flux problem (how many people submit data? how
   many total submissions are received?)

-- it will help us to understand if the issue is getting better
   or worse over time, as the volume of submissions or the nature
   of the domain's characteristics change




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

Privacy Policy | Terms of Service | Cookies Policy