ICANN ICANN Email List Archives


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

RE: [gnso-ff-pdp-may08] Comment References, Interim Conclusions and Next Steps

  • To: <joe@xxxxxxxxxxxxxxxxxx>
  • Subject: RE: [gnso-ff-pdp-may08] Comment References, Interim Conclusions and Next Steps
  • From: "Greg Aaron" <gaaron@xxxxxxxxxxxx>
  • Date: Wed, 3 Jun 2009 15:30:08 -0400

Dear Joe:

You mistake my meaning on a point; forgive me if I was not clear.  WPDRS is
a compliance tool with segments designed for reporting, investigating, and
following up on contractual obligations.  So when I said that "The FFWG has
never endorsed the idea that ICANN create a WPDRS-like service for
fast-flux," I think that is correct.  The WG thought about asking for a
collection tool for WG research purposes, which is what I reiterated.  The
more I think about it, WPDRS is actually a very poor model for a FF data
collection mechanism.

As far as a tool created by ICANN: the security community already knows how
fast-flux works, and what domains the bad guys are using.  I wonder whether
there is really anything "murky" about our understanding that such an ICANN
tool would help clear up.  So I question the utility, and I question whether
this is a good use of ICANN's money and time, since I believe fast-flux
mitigation is beyond ICANN's mission and ability.  I think it would be more
effective and more properly situated if someone in the security community
created and maintained such a tool.

All best,

-----Original Message-----
From: Joe St Sauver [mailto:joe@xxxxxxxxxxxxxxxxxx] 
Sent: Wednesday, June 03, 2009 2:38 PM
To: gaaron@xxxxxxxxxxxx
Cc: gnso-ff-pdp-may08@xxxxxxxxx
Subject: RE: [gnso-ff-pdp-may08] Comment References, Interim Conclusions and
Next Steps

This feels like the movie "ground hogs day," going over and over the 
same material time after time after time. 

I thought the draft report was it for most of the big arguments, subject
only to the addition of a chapter discussing public comments, but I see
that's not the case, and now we find ourselves re-hashing all those fun
old arguments again. Whee!

Like one of my kid's favorite cartoons says, I guess this is a case 
where whoever has the greatest endurance prevails in some meetings.

Ah well. On to the matter at hand:

Greg mentioned:

#2) Mike's edits at the end of the document change the meaning and purpose
#a manner not agreed to by the WG.  James's draft accurately reflects the
#WG's discussion of how it wanted a way for people to "submit potential fast
#flux domains for consideration by the working group" as part of its
#research.  Mike has changed the draft to state that the WG wants ICANN to
#create a reporting system for "parties that might take action against
#illegitimate or illegal activity."  Those are two very different things.
#Mike's change should be stricken.   The FFWG has never endorsed the idea
#that ICANN create a WPDRS-like service for fast-flux, 

Simply factually incorrect. Grab a copy of 
and grep for WDPRS

On PDF page 53 as part of potential next steps you'll see:

  "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 the Working Group  might consider, albeit one 
  that is focused 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/.";

Greg also commented, with regard to ICANN collecting data on fast flux:

#I wonder if the thing would tell us anything new, and I wonder if any of us
#honestly has the time to verify and sift the data.  There's no reason to
#spend time and money on something that is not needed or might not be used.

And by avoiding the collection of data, we'll insure that the fast flux
problem remains murky, poorly understood, and unremediated. Nothing 
helps fix a problem quite like examining it under a bright light, and 
that requires data.

If ICANN collects the data and makes it available to the network 
research community, I guarantee folks will look at it and analyze it. 

I know that some people don't want the bright light of public scrutiny
put on fast flux methods, but I'd prefer to get the data and let the
rest sort itself out. 

Finally, Greg also commented:

#I think it
#should read: "Successful mitigation of any single technique is not likely
#change the macro environment for Internet fraud and abuse -- every attack
#that is enhanced by the use of fast flux techniques could be pursued
#them, but possibly at higher cost or effort for the attacker." 

By that logic, all attempts at mitigation are pointless or out of scope 
since the nature of cyber crime is persistent agility in the face of hostile

action by the authorities or other good guys. 

There are some techniques, however, that cyber criminals REALLY like, 
and prefer to use when they can. Fast flux is one of them. No cost to 
do your hosting. Robust to any single compromised system going down. 
No pesky financial records subject to backtracking in follow-the-money 
attacks by the authorities. Scales well....

Can miscreants recover from potential loss of fast flux hosting methods?
Yes, but loss of fast flux hosting would still hurt at least some of 
them a LOT. 

It would be a real mistake to back away from action against fast flux.



Disclaimer: all opinions strictly my own

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

Privacy Policy | Terms of Service | Cookies Policy