Mike, I have to agree with Tim, we do not need a PDP to do the fact finding you suggest in your motion. I personally would like to follow the staff recommendation for further research. Once we have a better picture of what the actual scope of the PDP could be we are still free to start one. Starting it now with only a few people supporting it might not be very productive in terms of ever getting by a 2/3rd majority and hence consensus policy. Best, tom
-----Ursprüngliche Nachricht----- Von: owner-council@gnso.icann.org [mailto:owner-council@gnso.icann.org] Im Auftrag von Tim Ruiz Gesendet: Freitag, 11. April 2008 13:09 An: 'Council GNSO' Betreff: RE: [council] Fast Flux Hosting
Mike,
The requirement to vote within 15 days can be dealt with by adding something like *whereas based on the Staff's recommendation the GNSO Council has chosen not to initiate a PDP at this time* or something like that.
To initiate a PDP would be ignoring the Staff's recommendations that we specifically asked for. The motion said:
*ICANN Staff shall prepare an Issues Report with respect to 'fast flux' DNS changes, for deliberation by the GNSO Council. Specifically the Staff shall consider the SAC Advisory [SAC 025], and shall outline potential next steps for GNSO policy development designed to mitigate the current ability for criminals to exploit the DNS via 'fast flux' IP or nameserver changes.*
In the report, over and over again, the Staff recommends further study. And the GC specifically states that *the overall question of how to mitigate the use of fast flux hosting for cybercrime is broader than the GNSO policy development process.* So the very issue the motion requested the report on is not within scope.
Philip suggests we make the PDP about those *some aspects relating to the subject of fast flux hosting* that are within scope. What are they? The report does not make it clear what they are. The furter research and study that the report recommends is what is needed in order to identify them.
When we initiate a PDP we start a clock ticking. If we initiate a PDP on yet unknown *aspects* with the idea that identifying them is the first step, we are guaranteeing that we won't stay within the PDP timeline. I don't see the point in that.
Tim
-------- Original Message -------- Subject: RE: [council] Fast Flux Hosting From: "Mike Rodenbaugh" <mxrodenbaugh@yahoo.com> Date: Thu, April 10, 2008 7:24 pm To: "'Council GNSO'" <council@gnso.icann.org>
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@gnso.icann.org [mailto:owner-council@gnso.icann.org] 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@yahoo.com> Date: Thu, April 10, 2008 12:42 pm To: "'Council GNSO'" <council@gnso.icann.org>
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-rep ort-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.