ICANN ICANN Email List Archives

[gnso-ff-pdp-may08]


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

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

  • To: joe@xxxxxxxxxxxxxxxxxx
  • Subject: Re: [gnso-ff-pdp-may08] Wording for Possible Next Steps data collection
  • From: Martin Hall <martinh@xxxxxxxxxxxxxxx>
  • Date: Wed, 19 Nov 2008 10:44:08 -0800


Joe,

I'm a big believer in collaboration to address many Internet abuse problems and, as you know, aggregation and data sharing is at the heart of the Karmasphere platform.

However, some of the big questions to come up when this kind of thing is raised in an industry group, beyond requirements and design, are:

1. Who implements such a system?
2. Who, if anyone, pays for it (bearing in mind that you do get what you pay for)?
3. What's the relationship of the industry group to such a system?

If we're going to get the document to the next phase real soon now, I support including general language about the benefit of a collaborative approach. Practically, this mean including your draft paragraphs up to and including the one starting "a recommended next step".

Beyond that, however, i wonder if this gets us into detailed and extended requirements and design discussions that we should leave either to the subsequent phase or continue to discuss but without including the specifics in the the doc we're trying to get to public comment?

Martin




On Nov 14, 2008, at 10:17 AM, Joe St Sauver wrote:


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



--
Martin Hall
skype: martin-hall
+1-408-838-2890







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

Privacy Policy | Terms of Service | Cookies Policy