ICANN ICANN Email List Archives

[gnso-ff-pdp-may08]


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

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

  • To: "Mike O'Connor" <mike@xxxxxxxxxx>
  • Subject: Re: [gnso-ff-pdp-may08] The Definition of Fast Flux
  • From: RLVaughn <RL_Vaughn@xxxxxxxxxx>
  • Date: Sun, 20 Jul 2008 11:56:53 -0500


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







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

Privacy Policy | Terms of Service | Cookies Policy