<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>RE: [council] Fast Flux Hosting</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Has an issues report been done?<BR>
<BR>
Chuck<BR>
<BR>
<BR>
Sent from my GoodLink Wireless Handheld (www.good.com)<BR>
<BR>
-----Original Message-----<BR>
From: Mike Rodenbaugh [<A HREF="mailto:mxrodenbaugh@yahoo.com">mailto:mxrodenbaugh@yahoo.com</A>]<BR>
Sent: Thursday, April 10, 2008 08:27 PM Eastern Standard Time<BR>
To: 'Council GNSO'<BR>
Subject: RE: [council] Fast Flux Hosting<BR>
<BR>
<BR>
Tim,<BR>
<BR>
I noted the Staff's recommendation and included it in a 'whereas' clause.<BR>
Yet there appears no reason to delay a PDP for factfinding, since a PDP can<BR>
begin with that work. Of course, this is a very time-sensitive issue as<BR>
hundreds of phish attacks are launched every week, increasingly many of them<BR>
using fast flux techniques.<BR>
<BR>
I also noted the comments apparently from ICANN Counsel with respect to<BR>
scope. It seems that after this next step, Counsel may wish to give an<BR>
opinion as to the outcome up to that date, so that GNSO Council does not<BR>
waste time deliberating potential recommendations that are out of its scope.<BR>
However, I believe my motion does not raise issues outside the scope of the<BR>
GNSO.<BR>
<BR>
The bylaws require us to vote whether to initiate a PDP, within 15 days of<BR>
the Issues Report. Only 1/3 of present Councilors needs to vote in favor of<BR>
initiating a PDP after an Issues Report. <BR>
<BR>
I am curious to hear others' thoughts on my motion, these issues, and any<BR>
reasoning as to why we should delay or forego initiation of a PDP, before<BR>
deciding whether to accept your friendly amendment.<BR>
<BR>
Thanks,<BR>
Mike<BR>
<BR>
-----Original Message-----<BR>
From: owner-council@gnso.icann.org [<A HREF="mailto:owner-council@gnso.icann.org">mailto:owner-council@gnso.icann.org</A>] On<BR>
Behalf Of Tim Ruiz<BR>
Sent: Thursday, April 10, 2008 11:42 AM<BR>
To: 'Council GNSO'<BR>
Subject: RE: [council] Fast Flux Hosting<BR>
<BR>
<BR>
Mike,<BR>
<BR>
Why does a PDP need to be initiated to gather the information you<BR>
suggest? In fact, the Staff report specifically recommends *that the<BR>
GNSO sponsor further fact-finding and research* before considering<BR>
whether or not to initiate a formal PDP.<BR>
<BR>
Also, the GC opinion on whether or not this is in scope says that while<BR>
*some aspects* are within scope, *the overall question of how to<BR>
mitigate the use of fast flux hosting for cybercrime is broader than the<BR>
GNSO policy development process.*<BR>
<BR>
Would you be agreeable to an intended friendly amendment to change the<BR>
opening sentenc after RESOLVES to:<BR>
<BR>
*To initiate a Working Group of interested stakeholders and Constituency<BR>
representatives...*<BR>
<BR>
Failing that amendment, I believe we would then need a Supermajority in<BR>
favor of the motion to initiate a PDP.<BR>
<BR>
<BR>
Tim<BR>
<BR>
<BR>
-------- Original Message --------<BR>
Subject: [council] Fast Flux Hosting<BR>
From: "Mike Rodenbaugh" <mxrodenbaugh@yahoo.com><BR>
Date: Thu, April 10, 2008 12:42 pm<BR>
To: "'Council GNSO'" <council@gnso.icann.org><BR>
<BR>
<BR>
Hello,<BR>
<BR>
I propose the following motion for Council consideration in our next<BR>
meeting<BR>
on April 17th, may I please have a 'second'?<BR>
<BR>
Thanks,<BR>
Mike Rodenbaugh<BR>
<BR>
<BR>
Whereas, "fast flux" DNS changes are increasingly being used to commit<BR>
crime<BR>
and frustrate law enforcement efforts to combat crime, with criminals<BR>
rapidly modifying IP addresses and/or nameservers in effort to evade<BR>
detection and shutdown of their criminal website;<BR>
<BR>
Whereas, the Security and Stability Advisory Committee has reported on<BR>
this<BR>
trend in its Advisory SAC 025, dated January 2008:<BR>
<A HREF="http://www.icann.org/committees/security/sac025.pdf/">http://www.icann.org/committees/security/sac025.pdf/</A><BR>
<BR>
Whereas, the SSAC Advisory describes the technical aspects of fast flux<BR>
hosting, explains how DNS is being exploited to abet criminal<BR>
activities,<BR>
discusses current and possible methods of mitigating this activity, and<BR>
recommends that appropriate bodies consider policies that would make<BR>
practical mitigation methods universally available to all registrants,<BR>
ISPs,<BR>
registrars and registries,<BR>
<BR>
Whereas, the GNSO resolved on March 6, 2008 to request an Issues Report<BR>
from<BR>
ICANN Staff, to consider the SAC Advisory and outline potential next<BR>
steps<BR>
for GNSO policy development designed to mitigate the current ability for<BR>
criminals to exploit the NS via "fast flux" IP and/or nameserver<BR>
changes;<BR>
<BR>
Whereas, the ICANN Staff has prepared an Issues Report dated March 25,<BR>
2008,<BR>
<A HREF="http://gnso.icann.org/issues/fast-flux-hosting/gnso-issues-report-fast-flux-">http://gnso.icann.org/issues/fast-flux-hosting/gnso-issues-report-fast-flux-</A><BR>
25mar08.pdf, recommending that the GNSO sponsor additional fact-finding<BR>
and<BR>
research to develop best practices guidelines concerning fast flux<BR>
`hosting,<BR>
and to provide data to assist policy development and illuminate<BR>
potential<BR>
policy options.;<BR>
<BR>
Whereas, ICANN should consider whether and how it might encourage<BR>
registry<BR>
operators and registrars to take steps that would help to reduce the<BR>
damage<BR>
done by cybercriminals, by curtailing the effectiveness of these fast<BR>
flux<BR>
hosting exploits.<BR>
<BR>
The GNSO Council RESOLVES:<BR>
<BR>
To initiate a Policy Development Process in accord with the ICANN<BR>
Bylaws, by<BR>
forming a Task Force of interested stakeholders and Constituency<BR>
representatives, to collaborate broadly with knowledgeable individuals<BR>
and<BR>
organizations, in order to develop potential policy options to curtail<BR>
the<BR>
criminal use of fast flux hosting.<BR>
<BR>
The Task Force initially shall consider the following questions:<BR>
<BR>
..Who benefits from fast flux, and who is harmed?<BR>
..Who would benefit from cessation of the practice and who would be<BR>
harmed?<BR>
..How are registry operators involved in fast flux hosting activities?<BR>
..How are registrars involved in fast flux hosting activities?<BR>
..How are registrants affected by fast flux hosting?<BR>
..How are Internet users affected by fast flux hosting?<BR>
..What measures could be implemented by registries and registrars to<BR>
mitigate<BR>
the negative effects of fast flux?<BR>
..What would be the impact (positive or negative) of establishing<BR>
limitations, guidelines, or restrictions on registrants, registrars<BR>
and/or<BR>
registries with respect to practices that enable or facilitate fast flux<BR>
hosting?<BR>
<BR>
The Task Force shall report back to Council within 90 days, with a<BR>
report<BR>
discussing these questions and the range of possible answers developed<BR>
by<BR>
the Task Force members. The Task Force report also shall outline<BR>
potential<BR>
next steps for Council deliberation.<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>