RE: [council] Fast Flux Hosting - re stated motions

["Mike Rodenbaugh" <mxrodenbaugh@xxxxxxxxx>]

Avri, thanks.  Your reading seems correct to me.  I would add further that,
insofar as fast flux techniques involve rapid change of IP addresses, policy
development is further within scope per 1.b. below.

Tim, the reason to not delay is because this is an urgent issue causing
immediate and dramatic harm to many users.  A formal PDP will help bring
interested parties together, more so than informal fact-finding.  We delayed
the domain tasting PDP in the way you suggest now, only to later run into
procedural objections which caused months of further delay.  We have a bylaw
process so we should use it in substance, to hopefully avoid repeated
procedural objections, even if we can't reasonably meet many of the
timelines the bylaws would require.

Thanks,
Mike

-----Original Message-----
From: owner-council@xxxxxxxxxxxxxx [mailto:owner-council@xxxxxxxxxxxxxx] On
Behalf Of Avri Doria
Sent: Wednesday, April 16, 2008 8:07 AM
To: Council GNSO
Subject: Re: [council] Fast Flux Hosting - re stated motions


Hi,

 From the issues report:

> The ICANN Bylaws state that:
> "The mission of The Internet Corporation for Assigned Names and  
> Numbers ("ICANN") is to coordinate, at
> the overall level, the global Internet's systems of unique  
> identifiers, and in particular to ensure the stable
> and secure operation of the Internet's unique identifier systems. In  
> particular, ICANN:
> 1. Coordinates the allocation and assignment of the three sets of  
> unique identifiers for the Internet, which
> are
> a. domain names (forming a system referred to as "DNS");
> b. Internet protocol ("IP") addresses and autonomous system ("AS")  
> numbers; and,
> c. protocol port and parameter numbers.
> 2. Coordinates the operation and evolution of the DNS root name  
> server system.
> 3. Coordinates policy development reasonably and appropriately  
> related to these technical functions."
>
> Fast flux hosting involves the association of domain names with IP  
> addresses through the operation of
> name servers, including the information about a delegated second- 
> level domain that is maintained by
> registrars and by the registry for the TLD in which that SLD is  
> registered. ICANN has only limited
> responsibility for policy development related to these technical  
> functions. While items 1a and 3 above are
> general subjects that fall within the scope of ICANN's mission  
> statement, some policy options would not
> be within the scope of GNSO policy making.
>


My reading of this is that while it is possible that the PDP could  
arrive at policy recommendations that were out of scope, the  
discussion itself and hence the PDP itself would be within scope and  
thus only subject to the 33% threshold.

I have sent off a message to the general counsel's office seeking  
confirmation, or otherwise, of my reading.

a.


On 16 Apr 2008, at 07:30, Tim Ruiz wrote:
>
>> To initiate a Policy Development Process uniquely on
>> the issues deemed in scope in the Issues report.
>
> What are the issues deemed to be in scope? The report does not  
> elaborate
> on what those are. The report does say the GC's opinion is that *some
> aspects relating to the subject of fast flux hosting are within  
> scope of
> the ICANN policy process* but does detail those aspects except to say
> "as fast flux hosting activities concern gTLDs, the issue is within  
> the
> scope of the GNSO to address.*
>
> What the report is actually recommending is further research. We can  
> do
> that without initiating a PDP on yet unknown *aspects* that might  
> apply
> to gTLDs.
>
> What our resolution asked for was *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.* The report
> specifically states *the overall question of how to mitigate the use  
> of
> fast flux hosting for cybercrime is broader than the GNSO policy
> development process.* So what we asked for is clearly deemed out of
> scope.
>
> Any vote to initiate a valid PDP based on this issues report  
> requires a
> Supermajority.
>
> I don't understand the insistance on a PDP when we can initiate the
> recommended research and fact-finding without one.
>
>
> Tim
>
> -------- Original Message --------
> Subject: [council] Fast Flux Hosting - re stated motions
> From: "Philip Sheppard" <philip.sheppard@xxxxxx>
> Date: Wed, April 16, 2008 2:45 am
> To: "'Council GNSO'" <council@xxxxxxxxxxxxxx>
>
>
>
> Avri,
> you are right and the situation is no different to any PDP. I suggest
> this:
>
> MOTION 1
> 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 uniquely on the issues deemed
> in scope in the
> Issues report.
> (This will require a 33% vote)
>
>
> MOTION 2
> Whereas Council has decided to launch a PDP on fast flux hosting;
>
> The GNSO Council RESOLVES:
> To form 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.
>
> (This will require a 50% vote)
>
>
>
>
>
>