Re: [gnso-ff-pdp-may08] Saturday Harms

[Dave Piscitello <dave.piscitello@xxxxxxxxx>]

If I understand the definitions we are now using then fast flux is but one kind 
of volatile compromised host service network. Rod's mentioned "slow flux" and 
has recently posted an article describing how content is distributed as well.

So I would speculate that bad actors will continue to adapt in the face of 
effective countermeasures and that tomorrow's VCHSN will be different from what 
we see today.

I don't think we can eradicate volatile networks or the use and adaptation by 
bad actors. We have no good sense of how long it might before commercial 
operating systems installed on a consumer/commodity scale are sufficiently 
resistant to malicious code, if ever.

Simply put, I can't see that we can reasonably discuss eradicating "harms" in 
some holistic or curative sense. What we may be able to do is provide methods 
for identifying and disabling specific instances of VCHSNs quickly and 
minimizing the harm in each case.


On 7/23/08 1:06 PM, "Mike O'Connor" <mike@xxxxxxxxxx> wrote:



At the risk of driving some of you crazy, I'm going to relaunch this
thread.  I'm in "re-read email and extract" mode today.

My first comment is that my replies to the thread completely missed
Eric's point.  Sorry about that.

I want to pose a question or two, based on our discussion around the
definition of fastflux (using Randy's terminology).

- What "harms" would be eradicated by the elimination of volatile
compromised host service networks?

- For those that wouldn't be completely eradicated, for which harms
would "eliminating volatile compromised host service networks" be
your first choice among all mitigation options?

For inspiration, I give you the first four photographs in Marcie's
latest farm-blog journal entry -- Mike causing mayhem with the chain saw.

http://aprairiehaven.com/modules/AMS/article.php?storyid=616


At 10:53 AM 7/19/2008, Eric Brunner-Williams wrote:
>All,
>
>Dave's note "Jump start on answering GNSO questions regarding fast
>flux" of July 1st restated the "benefits/harms from/by fast flux"
>question as "benefits from short TTLs" and "harmed by fast flux",
>which kicked off our still-incomplete attempt to correct the
>language of our point of departure.
>
>
>In the list of "harmed by", Dave listed several cases. I commented
>on several, in particular these two:
>
>1. Individuals whose computers are infected ...
>
>2. Businesses and organizations whose computers are infected ...
>
>In a nutshell, Dave pointed out that the consequences for
>individuals, business and organizations who's computers are infected
>and subsequently used by (and I'll leave this as "fast flux" even
>though we've no consensus on terminology) "fast flux" are
>non-trivial. Denial of service by their local access ISP. Far too
>much service by their local law enforcement.
>
>In a nutshell, my comment was that the consequences are immanent*
>when these computers are infected, and the infected computers are a
>commodity, and used until "busy, hung or dead" by the author(s) of
>the infection(s). They don't get particularly more "busy, hung or
>dead" if used for "fast flux".
>
>A few days ago** I wrote that Registrants (capitalized, because I'm
>addressing a specific, contract-created role in a set of
>contract-defined relationships between gTLD parties, bounded above
>by 100 million) are not harmed by "fast flux". I looked at the
>probability of harm, and found that it is, as we say in Maine, "wicked small".
>
>I should have also pointed out then that while it is true that
>Registrants are harmed by the taking of domains by non-Registrants
>(or Other Registrants), but they are no more harmed by "fast flux"
>than by any other non-Registrant taking that is not permitted by
>ICANN Consensus Policies. Like repurposed (infected and exploited)
>PCs, domains don't get particularly more "busy, hung or dead" if
>used for "fast flux".
>
>Today, while Mike is out killing living things with a mower and a
>chain saw, I'm going to offer the following:
>
>A. Registrants are not harmed by "fast flux". Hijacking and so forth
>do harm Registrants, but very little is known to Registrars (and no
>other party within ICANN is in a position to have better information
>than Registrars) that is specific to "fast flux", so "fast flux"
>adds no known additional harm to Registrants beyond the set of harms
>we already know about, and have previously developed PDPs to address
>(or are still dickering over).
>
>B. Registrars are not harmed by "fast flux". Credit card fraud is a
>given, its why we have the Add Grace Period, and take-down requests
>from a variety of sources are a given, and dispute claims and their
>resolution processes are a given, as well as system loading for
>dynamic update are given, so "fast flux" adds no known additional
>harm to Registrars beyond the set of harms we already know about,
>and have previously developed PDPs to address (or are still dickering over).
>
>C. Registries are not harmed by "fast flux". Transfer interventions,
>Registrar support costs, and system loading for dynamic update are
>all givens, so "fast flux" adds no known additional harm to
>Registries beyond the set of harms we already know about, and have
>previously developed PDPs to address (or are still dickering over).
>
>While its been most of a decade since I last operated an access ISP
>(a dialup operation serving Maine), and its been about that long
>since I've seen any interest in ICANN by the operational side of
>transit or access network providers, I'm going to offer my
>experience for that Constituency (left somewhere behind), that --
>
>D. ISPs are not harmed by "fast flux". A whole bunch of bad things
>are givens for ISPs, so "fast flux" adds no known additional harm to
>ISPs beyond the set of harms they already know about. A
>counter-proof would be something of the form "X lost block Y because
>Y[i,j,k] were used in a FF".
>
>I don't play a lawyer on the net or on TV, let alone an IP
>practitioner, but given A, above --
>
>E. Intellectual Property holders are not harmed by "fast flux". A
>counter-proof would be something of the form "X lost mark M in
>jurisdiction Y(s) because M was used in a FF conducted or prosecuted
>in jurisdiction Z(s)".
>
>Because the BC brought this (I'm sure Mike R. will correct me even
>if I'm right), I'm assuming that some businesses are harmed by "fast
>flux", and their harm is distinct from the harms they experience
>from other causes.
>
>I'm not "At Large" either , but my guess is that --
>
>F. ALC interests are not harmed by "fast flux". A whole bunch of bad
>things are givens for the interests represented by the ALC, and
>"fast flux" adds no known additional harm to those interests beyond
>the set of harms they already know about and have previously
>developed PDPs to address (or are still dickering over).
>
>My goal is to try and get a better understanding, even if just for
>my self, of what the harms are, and what they are not. I'm not
>trying to change anyone's mind that has already come to some other
>conclusions I haven't learned to share.
>
>I don't know what harm to the environment Mike will wreak tomorrow,
>but I'll try "benefits" on Sunday.
>
>Eric
>---------
>* In popular Indian culture we say "Coyote waits" (or Raven or
>Racoon or ...), meaning that a trick, or adverse outcome, is waiting
>for those without foresight or common sense. It is latent malice.
>
>** message id:
><mailto:487F214F.5030402@xxxxxxxxxxxxxxxxxxxx><mailto:487F214F.5030402@xxxxxxxxxxxxxxxxxxxx><487F214F.5030402@xxxxxxxxxxxxxxxxxxxx>