Re: [gnso-ff-pdp-may08] Things learned thus far

[Dave Piscitello <dave.piscitello@xxxxxxxxx>]

Wow... Is this truly where the majority of WG members believe we stand at this 
juncture?

W/r/t data providers, you and Joe have provided what I consider compelling data 
regarding the financial impact of phishing, fraud, and fast flux. I mentioned 
how even single FF networks are so geographically dispersed as to span 375 ASNs 
.

I don't know what the "killer data" this group needs to see to be convinced 
that FF is a problem.

How about this:

According to the data collected by one investigator who  examined a list of 
distinct hosts monitored in June 2008 and recorded the count of IP changes. Out 
of a total of 12888 domains associated with fast flux attacks:

539 domains were hosted on 1500-1742 unique IP addresses
1395 domains were hosted on  1000-1499 unique IP addresses
6290 domains were hosted on  500- 999 unique IP addresses
965 domains were hosted on 250-499 unique IP addresses

What does this tell us? Well, nearly 13,000 domains were used in fast flux 
attacks in one month. I think that's a formidable number. Someone else may say, 
"gee, there are hundreds of millions of domain names, that is a small number".

What else does this data tell us?


 *   4% of the  attackers have a sufficient pool of compromised hosts to change 
addresses 1500 times or more in a single month
 *   15% of the  attackers have a sufficient pool of compromised hosts to 
change addresses 1000 times or more in a single month
 *   64% of the  attackers have a sufficient pool of compromised hosts to 
change addresses 500 times or more in a single month

Again, I think these are formidable numbers.  Someone else may say, "gee, there 
are hundreds of millions of hosts, how much damage can an attack network of 
500-1500 hosts really do?".

We can draw other conclusions from the data. Please tell me what if anything 
will be "convincing".

On 8/4/08 3:52 PM, "Mike O'Connor" <mike@xxxxxxxxxx> wrote:



Let me try my hand at restating Eric's post in an imaginary "sales
memo" format.

Dear Proposers of Solutions (aka Team Fast Flux),

You haven't made the sale yet.  Here are the objections you're
hearing from prospective customers and partners;

- Some remain unconvinced that Fast Flux a problem (or a subset of a
problem) that needs to be solved at all (providers of data take note,
stronger facts would be useful here)
- Some remain unconvinced that your proposed solution will work
without imposing inordinate burdens on the partners you're trying to
recruit to your cause
- Some are concerned that the proposal lacks sufficient safeguards to
protect registrants and users from the impact of false positives

There are probably more objections, and there's certainly a lot more
detail to be had in the posts on the list -- a veritable gold mine in fact.

These objections are crucial pieces of information -- for they
provide you guidance as to what parts of your proposals need to be
improved.  Do not argue with them, for they are prospective partners
you are trying to win over and, as any sales person will tell you,
arguing with prospects makes them cranky and less inclined to buy
into your solution.  Rather, listen to what they are saying and
address their concerns by improving the underpinnings of your
argument and refining your proposal to meet their needs.

Thus ends the hypothetical sales memo...

Chairman Mikey

At 12:51 PM 8/4/2008, Eric Brunner-Williams wrote:

>In no particular order, and not exhaustive.
>
>PART I:
>
>o the stated problem is only one in a larger space of evasion or
>resiliency techniques, some of which use the DNS,
>
>o the stated problem exists in a larger context of technical
>infrastructure, only some of which are even remotely within the
>largest scope of technical coordination of ICANN's SOs,
>
>o as a specific technique, it is an optimization of a resource
>utilization, and if completely mitigated, the underlying resource
>utilization would not be sufficiently mitigated to end rational
>economic criminal activity presently optimized to exploit resilient
>resources in distributed, public stores,
>
>o the stated problem exists in an unstated relation to technical
>fundamentals, such as the growth in routing state, the transition(s)
>to IPv6 and/or mixed addressing regimes, the identifier/locator
>split, Moore's "Law", the implications for vendors and service
>providers, and the scaling of the shared DNS infrastructure, and is
>therefore mutable over time as these fundamentals curve over time,
>and has mutated over the past two decades.
>
>PART II:
>
>o present data does not support the claim that the technique,
>construed as to-be-deprecated-by-policy-or-practice is either
>limited to the generic registries, nor is present in all of the
>generic registries, and to a first order, approximates volume,
>
>o present data does not support the claim that the technique,
>construed as to-be-deprecated-by-policy-or-practice is either
>limited to the generic registrars, nor is present in all of the
>generic registrars, and to a first order, approximates volume,
>(pending confirmation, eric)
>
>o present data does support the claim that the technique, construed
>as other-than-to-be-deprecated-by-policy-or-practice, is used for
>reasonable engineering purposes unrelated to evasion, and used also
>for reasonable engineering purposes related to evasion,
>
>o present data does support the claim that the technique is
>deprecated by private and public actors, citing suppression of
>"fraud", "crime" and "dissent" theories,
>
>PART III:
>
>o data exists which shows that reduction of the TTL values for NS
>records increases the load on the IANA root and gTLD name servers by
>a factor of about 5 and significantly harms DNS scalability,
>
>o no data has been identified which supports a claim of damage to
>the security and stability of the IANA root or the gTLD name servers
>by the use of the technique, within the context of the stated problem,
>
>o no data has been identified which supports a claim of damage to
>ICANN accreditation of registrars by the use of the technique,
>
>o no data has been identified which supports a claim of damage to
>domain registrations by the use of the technique,
>
>PART IV:
>
>o reasonable progress has been made restating a portion of the stated problem:
>
>Definition: A Compromised Host Service Network (CHSN) is a network
>whose infrastructure depends on the use of one or more plurally purposed hosts.
>
>Definition: A Volatile Network is one which is purposed to
>distribute logically identical services over multiple (perhaps
>virtual) hosts at request time.
>
>Both the round robin DNS (RRDNS) and content delivery network (CDN)
>fall into the definition of volatile networks. Anycast DNS and CDN's
>also meet the definition of volatile networks.
>
>Definition: A Volatile Compromised Host Service Network (VCHSN) is a
>volatile network which is also a CHSN.
>
>The fastflux vernacular refers to a VCHSN.
>
>o the stated scope is not yet restated to the working group's rough consensus.
>
>
>PART V: Things not yet known. (Answers not sought, only other
>significant "things not yet known".)
>
>o is there a real problem here, or just "chicken little"?
>
>o if real, is the problem cost being socialized to third-parties
>(registrants, registrars, registries, and ICANN as a whole)?
>
>o if real, is the internet operations community interested in
>looking at this problem and working on a solution? where could or
>should such work be done?
>
>o if real, are the jurisdictional actors interested in looking at
>this problem and working on a solution? where could or should such
>work be done?
>
>END
>
>As we're in the data gathering phase I'm only listing the things
>learned. If I've missed anything, let me know. Short sentences are
>good. My intent is the next version goes to Paul, James, and Kal for
>edit and then on to the RC member list, with the data on registries
>and registrars mentioned in PART II, bullets 1 and 2, and
>separately, the template du jour with our answers for the RC members
>to confirm, reject, or modify as they each see fit.
>
>Eric