AW: [council] Fast Flux Hosting

["Thomas Keller" <tom@xxxxxxxx>]

Mike,

I do not share your view that conducting more research is not as meaningful
as a full fletched PDP. I could even imagine that it might be helpful in
terms of effective participation to go forward without a stick called
policy.

tom

> -----Ursprüngliche Nachricht-----
> Von: owner-council@xxxxxxxxxxxxxx
> [mailto:owner-council@xxxxxxxxxxxxxx] Im Auftrag von Mike Rodenbaugh
> Gesendet: Freitag, 11. April 2008 16:47
> An: 'Council GNSO'
> Betreff: RE: [council] Fast Flux Hosting
>
>
> Tim and Tom,
>
> I appreciate your thoughts on this.  You seem to raise only
> procedural objections.  We ought to start the process of
> policy development ASAP, because this is a serious problem
> causing lots of harm.  So let's get the procedural issues out
> of the way, and move forward.
>
> It seems we agree that the first step in the process is to
> put together a more complete factual record, in response to
> the questions posed by Staff in the Issues Report.  In order
> to do that most comprehensively and effectively, we will need
> broad participation from GNSO constituencies and from other
> interests (private and public law enforcement, in particular).
> In order to best secure that participation, there ought to be
> a formal PDP underway so that people know their work is more
> likely to be meaningful and therefore they are more likely to
> participate.
>
> The terms of reference for this PDP have been narrowly
> tailored to remain in scope of the GNSO.  Any suggested
> recommendations of the Task Force can then be reviewed to
> ensure they are in scope, before they are debated or
> deliberated by the Council in the next phase of the PDP.
>
> While it would be wonderful to have unanimous consensus to
> kick off a PDP, it is not necessary and is unrealistic with
> this issue as with so many others.  Registrars nevertheless
> ought to participate in a Task Force, and hopefully they will
> come to understand that nobody aims to impose undue burdens
> on them with respect to this issue.
>
> Rather, the PDP would get a broad and knowledgeable group
> together to discuss the factual realities, and brainstorm
> about what reasonably might be done to potentially address
> the problem at the registry and registrar levels of the DNS.
> It may turn out that there is nothing that ought to be done,
> but at least GNSO will have taken a formal look at this (at
> SSAC's request), and come to that reasonable conclusion as
> quickly as it reasonably could.
>
> I fear that your alternative proposal would only amount in
> excessive delay with little or no upside benefit.  We tried
> that approach with domain tasting.  That was not necessary as
> the 'ad hoc' factfinding could have been the first step in a
> formal PDP.  Had it been, the issue most likely would have
> resolved the same way in the Council, but several months more quickly.
>
>
> Thanks,
> Mike
>
>
> -----Original Message-----
> From: owner-council@xxxxxxxxxxxxxx
> [mailto:owner-council@xxxxxxxxxxxxxx] On Behalf Of Thomas Keller
> Sent: Friday, April 11, 2008 4:33 AM
> To: 'Tim Ruiz'; 'Council GNSO'
> Subject: AW: [council] Fast Flux Hosting
>
>
> 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.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>
>