ICANN ICANN Email List Archives

[gnso-ff-pdp-may08]


<<< Chronological Index >>>    <<< Thread Index >>>

RE: [gnso-ff-pdp-may08] 1.h

  • To: <icann@xxxxxxxxxxxxxx>, "'Fast Flux Workgroup'" <gnso-ff-pdp-May08@xxxxxxxxx>
  • Subject: RE: [gnso-ff-pdp-may08] 1.h
  • From: "Greg Aaron" <gaaron@xxxxxxxxxxxx>
  • Date: Wed, 22 Apr 2009 16:09:59 -0400

The RAPWG was formed to explore the central topic of policies that allow (or
require) registrars and registries to respond to abuse issues (See charter
at:
https://st.icann.org/reg-abuse-wg/index.cgi?registration_abuse_policies_work
ing_group )

One reason the RAPWG came into being was because the FFWG effort pointed to
a need to examine fundamental scope and legal issues associated with abuses
and takedowns, and in a more "across the board" way.  (Fast-flux shares some
common issues with other problems.  For example, takedowns are also used to
combat phishing.)

The RAP charter and the preceding GNSO Registration Abuse Policies Issues
Report contain very relevant questions and material, such as questions about
the relevant scope of ICANN policy-making.  The RAPWG will be digging into
them.  I think that work should come first, and then suggestions like Mike
Rodenbaugh's below should be examined in light of it. 

So, should the FFWG wrestle with those thorny issues and duplicate the work
of the RAPWG, or should the FFWG hand them off to the RAPWG, which was
constituted specifically to deal with that kind of thing?

The RAPWG does have fast-flux on its list of topics for work:
https://st.icann.org/data/workspaces/reg-abuse-wg/attachments/registration_a
buse_policies_working 

All best,
--Greg



-----Original Message-----
From: Mike Rodenbaugh [mailto:icann@xxxxxxxxxxxxxx] 
Sent: Wednesday, April 22, 2009 1:34 PM
To: 'Fast Flux Workgroup'
Subject: RE: [gnso-ff-pdp-may08] 1.h


I agree that we could make such a recommendation, and further would argue
that we "should" make such a recommendation.  Further still, I would like to
examine the option to require certain action of contracting parties, rather
than merely "allowing" them to take action.  At least they should
acknowledge receipt of the information almost immediately, and should
provide follow-up status reports at reasonable intervals wrt their action in
response to the information.

Thanks,
Mike 


Mike Rodenbaugh
Rodenbaugh Law
548 Market Street
San Francisco, CA  94104
+1.415.738.8087
www.rodenbaugh.com


-----Original Message-----
From: owner-gnso-ff-pdp-may08@xxxxxxxxx
[mailto:owner-gnso-ff-pdp-may08@xxxxxxxxx] On Behalf Of Dave Piscitello
Sent: Wednesday, April 22, 2009 9:25 AM
To: avri@xxxxxxx; Fast Flux Workgroup
Subject: Re: [gnso-ff-pdp-may08] 1.h


I think your interpretation of the comment is correct.

I would add that we should make certain to acknowledge that technical
measurements, methods and criteria for distinguishing beneficial uses of
volatile/adaptive networking from fast flux attack networking may change
over time, since attackers will adjust their behavior in response to
countermeasures deployed to thwart them.

There exist today several methods to identify fast flux attack networks and
some have extremely low false positive rates. I think the folks who develop
and use these today perhaps represent a valuable if not best resource for
identifying domain and DNS abuse. I don't see as much value in suggesting
that the ICANN community duplicate their efforts as I see in finding ways
that we can effectively use what their results in a timely fashion so that
the goals of fast flux are thwarted: taking Avri's suggestion a bit further,
this WG could recommend a division of roles, where parties ICANN, registries
and registrars trust provide the proof of malicious use/abuse, and policies
allow registrars and registries to quickly respond when provided with proof.


On 4/21/09 11:55 PM  Apr 21, 2009, "Avri Doria" <avri@xxxxxxx> wrote:

> 
> 
> On Mon, 2009-04-20 at 18:07 -0700, Marika Konings wrote:
>> be helpful if those assigned to review the public comments in 
>> category
>> 1 and provide recommendations on how to deal with the comment(s)
> 
> On 1.h, the way i read the comment is that there is a strong 
> indication that for the most part it would be possible to come up with 
> technical measurements, methods and criteria that can differentiate 
> between legitimate and illegitimate behavior.
> 
> The real problem that is expressed is knowing what to do when you 
> identify illegitimate behavior and figuring out who is going to take 
> the responsibility for figuring out such policies and then for 
> following up with action.  Of course this dilemma was well explored in the
report.
> 
> 
> The question becomes, do  we want to strengthen the statementds in the 
> report on the possibility of technical differentiation.  One 
> possibility is to add the technical research into methods of 
> differentiation to the possible next steps.  We talk about it some, 
> but it could be further emphasised.
> 
> If we do this though it is worth including the reference to the fact 
> that once this differentiation has been done, some organization needs 
> to take responsibility for doing something about the positives.
> 
> KC does bring out the questions of whether this is something that 
> ICANN is the right place for.  this seems to be an issue that might be 
> worth discussing in a broader context within ICANN. It would, to me, 
> seem reasonable that the technical determination of exactly what was 
> possible would be a useful exercise to have done first.  Perhaps CAIDA 
> and some of the organizations already involved in the technical 
> aspects of the problem could undertake a proper evaluation.
> 
> Note I do not have sufficient technical background myself to say I 
> believe it is possible, though I do have sufficient belief in KC's 
> ability to believe it is worth exploring further.
> 
> a.
> 
> 





<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy