ICANN/GNSO GNSO Email List Archives

[council]


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

RE: [council] Fast Flux Hosting

  • To: "Mike Rodenbaugh" <mxrodenbaugh@xxxxxxxxx>, "Council GNSO" <council@xxxxxxxxxxxxxx>
  • Subject: RE: [council] Fast Flux Hosting
  • From: "Gomes, Chuck" <cgomes@xxxxxxxxxxxx>
  • Date: Thu, 10 Apr 2008 20:46:11 -0400
  • List-id: council@xxxxxxxxxxxxxx
  • Sender: owner-council@xxxxxxxxxxxxxx
  • Thread-index: AcibO7o9WvzUHcM3RHCVj9WzXstqrAAE0kwwAAebJvI=
  • Thread-topic: [council] Fast Flux Hosting

Has an issues report been done?

Chuck


Sent from my GoodLink Wireless Handheld (www.good.com)

 -----Original Message-----
From:   Mike Rodenbaugh [mailto:mxrodenbaugh@xxxxxxxxx]
Sent:   Thursday, April 10, 2008 08:27 PM Eastern Standard Time
To:     'Council GNSO'
Subject:        RE: [council] Fast Flux Hosting


Tim,

I noted the Staff's recommendation and included it in a 'whereas' clause.
Yet there appears no reason to delay a PDP for factfinding, since a PDP can
begin with that work.  Of course, this is a very time-sensitive issue as
hundreds of phish attacks are launched every week, increasingly many of them
using fast flux techniques. 

I also noted the comments apparently from ICANN Counsel with respect to
scope.  It seems that after this next step, Counsel may wish to give an
opinion as to the outcome up to that date, so that GNSO Council does not
waste time deliberating potential recommendations that are out of its scope.
However, I believe my motion does not raise issues outside the scope of the
GNSO.

The bylaws require us to vote whether to initiate a PDP, within 15 days of
the Issues Report.  Only 1/3 of present Councilors needs to vote in favor of
initiating a PDP after an Issues Report.  

I am curious to hear others' thoughts on my motion, these issues, and any
reasoning as to why we should delay or forego initiation of a PDP, before
deciding whether to accept your friendly amendment.

Thanks,
Mike

-----Original Message-----
From: owner-council@xxxxxxxxxxxxxx [mailto:owner-council@xxxxxxxxxxxxxx] On
Behalf Of Tim Ruiz
Sent: Thursday, April 10, 2008 11:42 AM
To: 'Council GNSO'
Subject: RE: [council] Fast Flux Hosting


Mike,

Why does a PDP need to be initiated to gather the information you
suggest? In fact, the Staff report specifically recommends *that the
GNSO sponsor further fact-finding and research* before considering
whether or not to initiate a formal PDP.

Also, the GC opinion on whether or not this is in scope says that while
*some aspects* are within scope, *the overall question of how to
mitigate the use of fast flux hosting for cybercrime is broader than the
GNSO policy development process.* 
 
Would you be agreeable to an intended friendly amendment to change the
opening sentenc after RESOLVES to:

*To initiate a Working Group of interested stakeholders and Constituency
representatives...*

Failing that amendment, I believe we would then need a Supermajority in
favor of the motion to initiate a PDP.


Tim 


-------- Original Message --------
Subject: [council] Fast Flux Hosting
From: "Mike Rodenbaugh" <mxrodenbaugh@xxxxxxxxx>
Date: Thu, April 10, 2008 12:42 pm
To: "'Council GNSO'" <council@xxxxxxxxxxxxxx>


Hello,

I propose the following motion for Council consideration in our next
meeting
on April 17th, may I please have a 'second'?

Thanks,
Mike Rodenbaugh


Whereas, "fast flux" DNS changes are increasingly being used to commit
crime
and frustrate law enforcement efforts to combat crime, with criminals
rapidly modifying IP addresses and/or nameservers in effort to evade
detection and shutdown of their criminal website;

Whereas, the Security and Stability Advisory Committee has reported on
this
trend in its Advisory SAC 025, dated January 2008:
http://www.icann.org/committees/security/sac025.pdf/ 

Whereas, the SSAC Advisory describes the technical aspects of fast flux
hosting, explains how DNS is being exploited to abet criminal
activities,
discusses current and possible methods of mitigating this activity, and
recommends that appropriate bodies consider policies that would make
practical mitigation methods universally available to all registrants,
ISPs,
registrars and registries,

Whereas, the GNSO resolved on March 6, 2008 to request an Issues Report
from
ICANN Staff, to consider the SAC Advisory and outline potential next
steps
for GNSO policy development designed to mitigate the current ability for
criminals to exploit the NS via "fast flux" IP and/or nameserver
changes; 

Whereas, the ICANN Staff has prepared an Issues Report dated March 25,
2008,
http://gnso.icann.org/issues/fast-flux-hosting/gnso-issues-report-fast-flux-
25mar08.pdf, recommending that the GNSO sponsor additional fact-finding
and
research to develop best practices guidelines concerning fast flux
`hosting,
and to provide data to assist policy development and illuminate
potential
policy options.;

Whereas, ICANN should consider whether and how it might encourage
registry
operators and registrars to take steps that would help to reduce the
damage
done by cybercriminals, by curtailing the effectiveness of these fast
flux
hosting exploits.

The GNSO Council RESOLVES:

To initiate a Policy Development Process in accord with the ICANN
Bylaws, by
forming a Task Force of interested stakeholders and Constituency
representatives, to collaborate broadly with knowledgeable individuals
and
organizations, in order to develop potential policy options to curtail
the
criminal use of fast flux hosting.

The Task Force initially shall consider the following questions:

..Who benefits from fast flux, and who is harmed?
..Who would benefit from cessation of the practice and who would be
harmed?
..How are registry operators involved in fast flux hosting activities?
..How are registrars involved in fast flux hosting activities?
..How are registrants affected by fast flux hosting?
..How are Internet users affected by fast flux hosting?
..What measures could be implemented by registries and registrars to
mitigate
the negative effects of fast flux?
..What would be the impact (positive or negative) of establishing
limitations, guidelines, or restrictions on registrants, registrars
and/or
registries with respect to practices that enable or facilitate fast flux
hosting?

The Task Force shall report back to Council within 90 days, with a
report
discussing these questions and the range of possible answers developed
by
the Task Force members. The Task Force report also shall outline
potential
next steps for Council deliberation.









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