Re: [gnso-ff-pdp-may08] The Definition of Fast Flux

[RLVaughn <RL_Vaughn@xxxxxxxxxx>]

Mike O'Connor wrote:
> One of my action-items is to kick off an email thread for us to work on 
> the definition of fastflux some more.
> I went through the MP3 this morning, extracted what I thought were the 
> major points made and took a stab at summarizing them on the wiki page 
> (scroll down, my stuff is below Eric's).  Here's the link;
> https://st.icann.org/pdp-wg-ff/index.cgi?initial_draft_definitions
>
> When I was in the call, I felt like there was less agreement than I did 
> after re-listening.
> -- Proposal:  remove references to intent from our definition of 
> Fastflux.  On re-listening to the conversation, I didn't detect a strong 
> demand to include intent in the definition and a lot of good arguments 
> for removing it.  Let's have a discussion about that.  I'm leaning in 
> favor at the moment.
How about we nail down a starting point for our definition?  The one
I am most familiar with agrees with the "Measuring and Detecting Fast-Flux 
Service Networks" paper which I will paraphrase as
Definition Candidate 1:
A fast-flux service network (FFSN) network shows a similar behavior as
RRDNS and CDNs in regards to the network characteristics: A single service
seems to be hosted by many different IP addresses. A FFSN uses rapid
changing DNS entries to build a hosting infrastructure with increased
resilience. The key idea is to construct a distributed proxy network on top
of compromised machines that redirects traffic through these proxies to a
central site, which hosts the actual content.

How about we pick that one apart or will someone please offer Definition
Candidate 2?


> -- Proposal: let the solution drive the definition.  One approach is to 
> let the solution-defining continue for a bit and let that inform the 
> definition.  My instincts tell me that this isn't terrible, but runs the 
> risk of "hammer looking for a nail" or "if we build it they will come."  
> So I'm neutral on this one.
> -- Proposal: let the definition allow for "slow fast flux".  Rod pointed 
> out that some people use all the same techniques, but don't do the 
> constant-IP-changing part and that we shouldn't limit our 
> discussion/proposals just to "fast."  My initial reaction (in Paris) was 
> a scope concern, but now that I've had the benefit of the last couple 
> weeks of email, I think we could handle the scope issue and agree with 
> Rod that we don't want to be so narrow that we exclude solutions that 
> would address this broader case.  So I'm leaning in favor.
> Have at it,
>
> m
>
>
> voice: 651-647-6109
> fax: 866-280-2356
>
> web: www.haven2.com
>
>
>
>