AW: [council] Fast Flux Hosting

["Thomas Keller" <tom@xxxxxxxx>]

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@xxxxxxxxxxxxxx
> [mailto:owner-council@xxxxxxxxxxxxxx] 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@xxxxxxxxx>
> Date: Thu, April 10, 2008 7:24 pm
> To: "'Council GNSO'" <council@xxxxxxxxxxxxxx>
>
>
> 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-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.
>
>
>
>
>
>
>
>
>
>
>
>