ICANN ICANN Email List Archives

[gnso-ff-pdp-may08]


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

RE: [gnso-ff-pdp-may08] Comment References, Interim Conclusions and Next Steps

  • To: "'RL Vaughn'" <rl_vaughn@xxxxxxxxxx>, "'Dave Piscitello'" <dave.piscitello@xxxxxxxxx>
  • Subject: RE: [gnso-ff-pdp-may08] Comment References, Interim Conclusions and Next Steps
  • From: "Greg Aaron" <gaaron@xxxxxxxxxxxx>
  • Date: Wed, 3 Jun 2009 10:23:09 -0400

I have seen false-positives come out of two different, expertly created
fast-flux detection systems.  If left unexamined by a human, those systems'
results could have led to the suspension of legitimate Web sites.  As we
have discussed (ad infinitum) in the FFWG, the false-positive rate can get
gotten down quite low, but when it comes to taking down domains, one wants
to be very careful. 

All best,
--Greg




-----Original Message-----
From: RL Vaughn [mailto:rl_vaughn@xxxxxxxxxx] 
Sent: Wednesday, June 03, 2009 9:40 AM
To: Dave Piscitello
Cc: Rod Rasmussen; icann@xxxxxxxxxxxxxx; fast flux fast flux
Subject: Re: [gnso-ff-pdp-may08] Comment References, Interim Conclusions and
Next Steps


Dave Piscitello wrote:
> The only comment I'd make is that "any" is rather open ended and suggests
> that there is a zero probability of automation that would achieve a
> satisfactory false-positive percentage.  In credit card and other fraud
> detection situations, automation does meet the false-positive criteria
that
> are set. Would folks object to saying "known automated techniques require
> human interpretation"?
> 
> 

Actually, no automated detection mechanism, including credit card fraud
detection, achieves a zero false positive percentage and requires human
intervention.  Your mileage may vary, one of my credit-card issuers
is capable of whitelisting a card for brief international sojourns although
this whitelisting does, indeed, require human intervention.

This is the long academic way of saying I don't really object to
the phrase.


> On 6/3/09 4:43 AM  Jun 3, 2009, "Rod Rasmussen"
> <rod.rasmussen@xxxxxxxxxxxxxxxxxxxx> wrote:
> 
>>
>> I think Mike has done a good job of cleaning up some stuff here, but
>> may have some more controversial deletes - nothing I see as a show
>> stopper, but should be discussed.
>>
>> I have a couple of thoughts to add in here.
>>
>> In conclusions, I think we had an important consensus that, "any
>> automated technique for detecting fast flux domains requires human
>> interpretation of the results and examination of the evidence to
>> confirm the presence of malicious or proscribed activities."
>>
>> I would also add this thought to conclusions - perhaps right after
>> Mike's comment about a neutral third party for determination of a
>> malicious FFLUX domain:
>>
>> Such a process could be devised to detect malicious FFLUX domains,
>> however, those domains would still require some form of mitigation in
>> order to end or prevent the undesired activity.  Depending on the
>> nature of the fluxing configuration, many disparate providers could
>> potentially be involved, from a domain registry or registrar, to DNS
>> or hosting service providers.  The working group reached no consensus
>> on which party or parties would be best suited to handle such
>> mitigation work, but notes that in practical terms, such mitigations
>> are already occurring in practice, but in an uncoordinated, uneven, or
>> even arbitrary manner.  Some proposals do exist for creating a
>> balanced process across-the-board for handling malicious domain
>> registrations in general and merit further consideration for potential
>> solutions to this particular issue.  <This last sentence may be better
>> in the recommendations section>.
>>
>> In the recommendations section, I think we should definitely point out
>> that some domain name registries and registrars have already
>> implemented contractual language that addresses the issue, and that is
>> another way to attack the problem.  (no specific text here - just a
>> thought extension that we need to cover, and there are a few places
>> that could be added).
>>
>> Also, please excuse the bit of APWG self-serving here, but I would
>> point out that a specific mitigation framework has been proposed
>> for .ASIA (and now others) in conjunction with the APWG that would
>> allow for quick mitigation of malicious FFLUX domains and could be
>> looked at as a general model for incident handling.
>>
>> OK, please don't shoot me for a "new" thought here, but one role that
>> ICANN could take on is the "best practices facilitator".  The idea
>> being that ICANN (the formal company) keeps a current list of
>> consensus-based best practices that could be used by various
>> contracted parties, ensures that these are evangelized to those
>> parties, and then does audits of if/how they are being used and
>> reports findings based on those audits.  I'm just trying to think of
>> ways to get past the old cliché of "everyone should follow best
>> practices" and put some meaning/incentive to actually doing so.  I'm
>> also trying to think of practical roles for ICANN itself to play in
>> this.
>>
>> Best,
>>
>> Rod Rasmussen
>> President and CTO
>> Internet Identity
>> 1 (253) 590-4088
>>
>> On Jun 2, 2009, at 10:09 AM, Mike Rodenbaugh wrote:
>>
>>> Hi Greg, that may depend on which version of Word you use, and what
>>> view you
>>> are in.  On my copy, my edits are in blue, James' in red.  When I
>>> mouse over
>>> the edits, it clearly shows who made them.
>>>
>>> -Mike
>>>
>>> -----Original Message-----
>>> From: owner-gnso-ff-pdp-may08@xxxxxxxxx
>>> [mailto:owner-gnso-ff-pdp-may08@xxxxxxxxx] On Behalf Of Greg Aaron
>>> Sent: Tuesday, June 02, 2009 9:54 AM
>>> To: icann@xxxxxxxxxxxxxx; 'fast flux fast flux'
>>> Subject: RE: [gnso-ff-pdp-may08] Comment References, Interim
>>> Conclusions and
>>> Next Steps
>>>
>>>
>>> Mike, I am not sure which edits are yours.  Can you give me an
>>> example of
>>> your changes, so I can distinguish them from the others?  I think
>>> this doc
>>> has edits by two or three hands?
>>>
>>> All best,
>>> --Greg
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Mike Rodenbaugh [mailto:icann@xxxxxxxxxxxxxx]
>>> Sent: Tuesday, June 02, 2009 12:38 PM
>>> To: 'fast flux fast flux'
>>> Subject: RE: [gnso-ff-pdp-may08] Comment References, Interim
>>> Conclusions and
>>> Next Steps
>>>
>>> I have suggested edits to James rework of Secs 8/9, on attached.
>>>
>>> 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 James M.
>>> Bladel
>>> Sent: Sunday, May 31, 2009 1:40 PM
>>> To: marika konings; fast flux fast flux
>>> Subject: [gnso-ff-pdp-may08] Comment References, Interim Conclusions
>>> and
>>> Next Steps
>>>
>>> Team:
>>>
>>> Apologies for the delay on these materials.My schedule got away from
>>> me
>>> beginning on Thursday, and so this task was pushed to the weekend.
>>>
>>> In any event, please find attached two separate documents.  The first
>>> (spreadsheet) attaches references for the views of the WG on comments
>>> received in response to the Initial Report.  Please note that these
>>> are in
>>> no way an attempt to re-categorize the comments.  Instead, the goal
>>> is to
>>> find the smallest number of sections / topics that sufficiently
>>> address
>>> -all- comments.  I have included some sample language for each topic
>>> (needs
>>> further word-smithing), which can be used individually or worked
>>> into the
>>> comment analysis summary.
>>>
>>> Next, I have made many changes to section 8 ("Interim Conclusions")
>>> and
>>> section 9 ("Next Steps"). Please note that if you believe the text
>>> does not
>>> accurately characterize the WG findings, or if there are significant
>>> omissions, we can work through these on our call next Wednesday.
>>>
>>> Thank you,
>>>
>>> J.
>>>
>>
> 
> 





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

Privacy Policy | Terms of Service | Cookies Policy