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

[Dave Piscitello <dave.piscitello@xxxxxxxxx>]

Perhaps a recommendation from the FF WG could make the conclusion I
developed from Avri's original comment, observe that RAPWG is addressing
this area and encourage that RAPWG continue and "succeed" the FFWG in this
specific area of ongoing work?


On 4/22/09 4:09 PM  Apr 22, 2009, "Greg Aaron" <gaaron@xxxxxxxxxxxx> wrote:

> 
> 
> 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.
>> 
>> 
> 
>