April 2008 - council - lists.icann.org

Fast Flux DNS
by Mike Rodenbaugh 11 Apr '08

11 Apr '08

Hello, I propose the following motion for Council consideration in our next meeting on March 7th, 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 is likely an appropriate party to consider such policies The GNSO Council RESOLVES: 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, 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.

4 5

Proposed GNSO Council agenda 17 April 2008
by GNSO.SECRETARIAT＠GNSO.ICANN.ORG 11 Apr '08

11 Apr '08

Dear All, Attached please find the proposed draft Council agenda for Thursday 17 April at 12:00 midday UTC. Please let me know if you have any questions. Thank you. Kind regards, Glen ........................................................................... Proposed GNSO Council Agenda 17 April 2008 This agenda was established according to the Rules of Procedure for the GNSO Council Coordinated Universal Time12:00 UTC - see below for local times (05:00 Los Angeles, 08:00 Washington DC, 13:00 London, 14:00 Brussels, 22:00 Melbourne) Avri Doria will be chairing the GNSO Council meeting Scheduled time for meeting 120 mins. Dial-in numbers sent individually to Council members. Item 0: Roll call of Council members Item 1: Update any statements of interest Item 2: Review/amend agenda Item 3: Approve GNSO Council minutes of March 6, 2008 (5 mins) http://gnso.icann.org/mailing-lists/archives/council/msg04907.html Item 4: Update from Denise Michel on Board activities (10 mins) Item 5: Update from Edmon Chung on IDNC (10 mins) Item 6: GNSO Improvements - update (10 mins) Item 7: New gTLD - follow up (10 mins) Item 8: Discussion on how to complete deliberations on IRTP PDP – Denial Definitions (15 mins) http://gnso.icann.org/drafts/final-report-irt-policy-09apr08.pdf Item 9: Proposed IRTP PDP recommendations (15 mins) http://gnso.icann.org/drafts/transfer-wg-recommendations-pdp-groupings-19ma… Item 10: Domain Tasting PDP discussion/vote (15 mins) http://gnso.icann.org/issues/domain-tasting/gnso-final-report-domain-tastin… Item 11: Fast Flux Issues Report discussion (15 mins) http://gnso.icann.org/issues/fast-flux-hosting/gnso-issues-report-fast-flux… Motion proposed by 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-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 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. Item 12: Single character 2 letter domain names (10 mins) http://gnso.icann.org/drafts/icann-synthesis-on-sldns-27feb08.pdf Item 13: ALAC Letter to Board on "front-running" and Board referral to GNSO council (10 mins) - ALAC letter: <http://gnso.icann.org/mailing-lists/archives/council/msg04857.html > - Board Prelim Minutes Discussion under 11 Other business: <http://www.icann.org/minutes/prelim-report-27mar08.htm > Board's Disposition: "The Chair determined that emergency action is not required today but the matter will be referred to the GNSO for additional information or policy development if necessary, but not an emergency action." 13.1 D o we need an issues report? 13.2 Discussion of SSAC note from Steve Crocker http://gnso.icann.org/mailing-lists/archives/council/msg04920.html Item 14: Action Items (5 mins) http://gnso.icann.org/meetings/pending-action-list.pdf Item 15: AOB (5 mins) (05:00 Los Angeles, 08:00 Washington DC, 13:00 London, 14:00 Brussels, 22:00 Melbourne) ---------------------------------------------------------------------------- Local time between March and October, Summer in the NORTHERN hemisphere ---------------------------------------------------------------------------- Reference (Coordinated Universal Time) UTC 12:00 ---------------------------------------------------------------------------- California, USA (PST) UTC-8-0DST 05:00 New York/Washington DC, USA (EST) UTC-5+0DST 05:00 Buenos Aires, Argentina UTC-3+0DST 09:00 Rio de Janeiro, Brazil UTC-3+0DST 09:00 London, United Kingdom (BST) UTC+1DST 13:00 Brussels, Belgium (CEST) UTC+1+1DST 14:00 Karlsruhe, Germany (CEST) UTC+1+1DST 14:00 Barcelona, Spain (CEST) UTC+1+1DST 14:00 Oslo, Norway (CEST) UTC+1+1DST 14:00 Amman, Jordan UTC+2+1DST 15:00 Phnom Penh, Cambodia UTC+7+0DST 19:00 Hong Kong, China UTC+8+0DST 20:00 Singapore, Singapore UTC+8+0DST 20:00 Melbourne, Australia (EST) UTC+10+1DST 22:00 ---------------------------------------------------------------------------- The DST starts/ends on last Sunday of March 2008, 2:00 or 3:00 local time (with exceptions) ---------------------------------------------------------------------- For other places see http://www.timeanddate.com Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org

1 0

Introductory Slides - New gTLD Discussion in Los Angeles
by Karen Lentz 11 Apr '08

11 Apr '08

Dear All, For your reference, attached is the slide presentation Kurt used for the introductory segment of the meeting. Best regards, Karen = Karen Lentz ICANN +1 310 301 5836 office +1 310 895 3637 mobile

2 1

RE: [council] Fast Flux Hosting
by Gomes, Chuck 11 Apr '08

11 Apr '08

Thanks for clarifying Tim. Chuck Sent from my GoodLink Wireless Handheld (www.good.com) -----Original Message----- From: Tim Ruiz [mailto:tim@godaddy.com] Sent: Thursday, April 10, 2008 06:45 PM Eastern Standard Time To: Gomes, Chuck Cc: Council GNSO Subject: RE: [council] Fast Flux Hosting Chuck, I was referring to Annex A 3.c. of ICANN's bylaws where it says c. Vote of the Council. A vote of more than 33% of the Council members present in favor of initiating the PDP will suffice to initiate the PDP; unless the Staff Recommendation stated that the issue is not properly within the scope of the ICANN policy process or the GNSO, in which case a Supermajority Vote of the Council members present in favor of initiating the PDP will be required to initiate the PDP. Regarding scope the issues report 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.* If the overall question is broader than the GNSO PDP I don't see how we can call that in scope. So I would argue that a Supermajority would be required. Tim -------- Original Message -------- Subject: RE: [council] Fast Flux Hosting From: "Gomes, Chuck" <cgomes(a)verisign.com> Date: Thu, April 10, 2008 4:55 pm To: "Tim Ruiz" <tim(a)godaddy.com>, "Council GNSO" <council(a)gnso.icann.org> I am not for a PDP at this stage but I note that only 33 percent is needed to initiate a PDP. Chuck Sent from my GoodLink Wireless Handheld (www.good.com) -----Original Message----- From: Tim Ruiz [mailto:tim@godaddy.com] Sent: Thursday, April 10, 2008 02:45 PM Eastern Standard Time 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(a)yahoo.com> Date: Thu, April 10, 2008 12:42 pm To: "'Council GNSO'" <council(a)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-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 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.

1 0

RE: [council] Fast Flux Hosting
by Gomes, Chuck 11 Apr '08

11 Apr '08

Has an issues report been done? Chuck Sent from my GoodLink Wireless Handheld (www.good.com) -----Original Message----- From: Mike Rodenbaugh [mailto:mxrodenbaugh@yahoo.com] Sent: Thursday, April 10, 2008 08:27 PM Eastern Standard Time To: 'Council GNSO' Subject: RE: [council] Fast Flux Hosting 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(a)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(a)yahoo.com> Date: Thu, April 10, 2008 12:42 pm To: "'Council GNSO'" <council(a)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-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 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.

1 0

RE: [council] Fast Flux Hosting
by Tim Ruiz 11 Apr '08

11 Apr '08

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(a)yahoo.com> Date: Thu, April 10, 2008 12:42 pm To: "'Council GNSO'" <council(a)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-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 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.

2 1

RE: [council] Fast Flux Hosting
by Tim Ruiz 10 Apr '08

10 Apr '08

Chuck, I was referring to Annex A 3.c. of ICANN's bylaws where it says c. Vote of the Council. A vote of more than 33% of the Council members present in favor of initiating the PDP will suffice to initiate the PDP; unless the Staff Recommendation stated that the issue is not properly within the scope of the ICANN policy process or the GNSO, in which case a Supermajority Vote of the Council members present in favor of initiating the PDP will be required to initiate the PDP. Regarding scope the issues report 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.* If the overall question is broader than the GNSO PDP I don't see how we can call that in scope. So I would argue that a Supermajority would be required. Tim -------- Original Message -------- Subject: RE: [council] Fast Flux Hosting From: "Gomes, Chuck" <cgomes(a)verisign.com> Date: Thu, April 10, 2008 4:55 pm To: "Tim Ruiz" <tim(a)godaddy.com>, "Council GNSO" <council(a)gnso.icann.org> I am not for a PDP at this stage but I note that only 33 percent is needed to initiate a PDP. Chuck Sent from my GoodLink Wireless Handheld (www.good.com) -----Original Message----- From: Tim Ruiz [mailto:tim@godaddy.com] Sent: Thursday, April 10, 2008 02:45 PM Eastern Standard Time 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(a)yahoo.com> Date: Thu, April 10, 2008 12:42 pm To: "'Council GNSO'" <council(a)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-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 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.

1 0

RE: [council] Fast Flux Hosting
by Gomes, Chuck 10 Apr '08

10 Apr '08

I am not for a PDP at this stage but I note that only 33 percent is needed to initiate a PDP. Chuck Sent from my GoodLink Wireless Handheld (www.good.com) -----Original Message----- From: Tim Ruiz [mailto:tim@godaddy.com] Sent: Thursday, April 10, 2008 02:45 PM Eastern Standard Time 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(a)yahoo.com> Date: Thu, April 10, 2008 12:42 pm To: "'Council GNSO'" <council(a)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-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 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.

1 0

request for Staff update re domain tasting
by Mike Rodenbaugh 10 Apr '08

10 Apr '08

Hi, Before our meeting next Thursday, could Staff please update Council with respect to the budget initiative requested by the ICANN Board to address domain tasting? I understand there have been discussions between Staff and the Registrars Constituency, but am not aware of the substance or outcome of those discussions. Thanks, Mike Rodenbaugh

1 0

Final Report, Transfer Policy PDP
by Olof Nordling 09 Apr '08

09 Apr '08

Dear all, Please find attached the Final Report on the PDP for Clarification of Reasons for Denial in the Transfer Policy, for your consideration of further steps to take. Very best regards Olof

1 0