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

["Greg Aaron" <gaaron@xxxxxxxxxxxx>]

The proposed text does seem beyond the scope of the current WG product since
it gets into specifications, the question of who funds and sponsors such a
thing, etc.  "Testing various candidate operational fast flux scoring rules"
etc. is beyond the current scope, and we do not know if it will be in-scope
in the future.  Also, I think that a collaborative input site, while a
possibly interesting source of data, is not essential for the WG to perform
its work.  We know parties who do extensive monitoring, some of whom have
already contributed data.   

At line 1008, the report discusses "Information Sharing: Solutions in this
category focus on enhancing the ability of non-ICANN-affiliated parties to
deal with fraud and other abusive or malicious behavior without recruiting
ICANN or its affiliated registries and registrars as active agents of fraud
detection or prevention."  

So instead of the below suggestions, I suggest we insert an additional
bullet at 1032 to read:

"Cooperative, community initiatives designed to facilitate data sharing and
the identification of problematic domain names.  Examples include the
Anti-Phishing Working Group (APWG) and PhishTank for phishing, the Messaging
Anti-Abuse Working Group (MAAWG) and various blacklists for spam,
ShadowServer Foundation for botnets, and StopBadware.org for malware.  Such
community efforts may provide possible models for fast-flux hosting."

All best,
--Greg


-----Original Message-----
From: owner-gnso-ff-pdp-may08@xxxxxxxxx
[mailto:owner-gnso-ff-pdp-may08@xxxxxxxxx] On Behalf Of Martin Hall
Sent: Wednesday, November 19, 2008 1:44 PM
To: joe@xxxxxxxxxxxxxxxxxx
Cc: gnso-ff-pdp-May08@xxxxxxxxx
Subject: Re: [gnso-ff-pdp-may08] Wording for Possible Next Steps data
collection


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