ICANN ICANN Email List Archives

[gnso-ff-pdp-may08]


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

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

  • To: "'Fast Flux Workgroup'" <gnso-ff-pdp-May08@xxxxxxxxx>
  • Subject: RE: [gnso-ff-pdp-may08] 1.h
  • From: "Mike Rodenbaugh" <icann@xxxxxxxxxxxxxx>
  • Date: Wed, 22 Apr 2009 10:33:58 -0700

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