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

["Mike Rodenbaugh" <icann@xxxxxxxxxxxxxx>]

It would be even more useful to develop a consensus recommendation that
contracting parties should or must do something in response to fast flux
attacks, since that is what we were chartered to examine.  If we can create
a detailed consenus recommendation, that would be most helpful.  

I see no reason why this group, which has studied this issue for so long,
should stop short of making any recommendations whatsoever that we can agree
on.  It was not the stated intent of the Council for the RAP-WG to supercede
the FF-WG's consideration of anything.

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 1:38 PM
To: Greg Aaron; icann@xxxxxxxxxxxxxx; Fast Flux Workgroup
Subject: Re: [gnso-ff-pdp-may08] 1.h


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_policie
> s_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/registra
> tion_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.
>> 
>> 
> 
>