Re: [gnso-ff-pdp-may08] Definition V4.2

[Joe St Sauver <joe@xxxxxxxxxxxxxxxxxx>]

Good Morning!

#I'm willing to converse about this more -- but so far here's what I'm hearing;
#
#- routing doesn't *distinguish* fast flux networks from other/broader 
#attacks.  

Let me explain why I think it does.

Contrast two scenarios:

Scenario A: Spamvertised website is serviced by half a dozen compromised 
hosts, with those hosts using address space routed by a single provider 
(such as Verizon). Getting that site down requires action by a single
provider, Verizon, the party routing those addresses. You do NOT see
fastflux hosting occur in this fashion.

Scenario B: Spamvertised website is serviced by half a dozen compromised
hosts, with those hosts using address space routed by hald a dozen different
providers. Getting that site down requires action by ALL of the providers
routing that address space. *THIS* is what you *DO* see for fastflux.

This working group might want to ignore routing, but the bad guys have
absolutely got routing NAILED as one of the key things they need to 
exploit in order to stay up. 

That's a fundamentally important characteristic of fastflux methods: the
bad guys use addresses routed by as many different ASNs as they can.

Is this a matter of "routing" in the sense of "the bad guys are hijacking
routing"? No, it is not. If it would help to say that this phenomena does
NOT involve route HIJACKING, that's a more narrow exclusion that I could 
accept. 

#If it does, forgive me and expand on that -- I'm on the 
#hunt for things that we can use to answer the question "what 
#proportion of all harm can be laid at the door of Fast Flux?" and 
#exclude things that explode our scope.

I've yet to hear anyone come up with a good value for the denominator
of that fraction. What is the total harm?

#- routing is outside the scope of ICANN's domain.  

As I've previously mentioned, autonomous system numbers ARE a resource 
that ICANN manages. Does anyone dispute that point? If so, I don't see
how given that the ICANN bylaws (http://www.icann.org/en/general/bylaws.htm)
state at Article I, Section I, paragraph 1 that ICANN

   "1. Coordinates the allocation and assignment of the three sets of 
    unique identifiers for the Internet, which are

    [snip]

    b. Internet protocol ("IP") addresses and autonomous system ("AS") numbers

    [snip]"

ASNs are a *key* resource when it comes to how spammers choose which 
nodes to use at any given time, and they also now are the key to 
understanding how abuse reporting is now practically done, and how 
spammers attempt to avoid effective abuse reporting. 

This issue, like inaccurate whois, is key to understanding not just
what fastflux is, but how it can be *dealt with* by ICANN and its
constituencies. 

If the workgroup succeeds in fencing off virtually everything related to 
fastflux, then you have a priori determined that there will be nothing 
that ICANN can do to impact this issue. Unless that is a for-ordained
objective and this effort is just a matter of going through the motions 
before shrugging and doing nothing, I would urge the working group to NOT
arbitrarily exclude potentially crucial aspects of the problem such as
routing-related issues and whois-related issues which ARE within ICANN's
responsibilities.

#>[added some specifics and one mealy-mouthed term to the following}
#>          o time- or other metric-based changes to network nodes, name server,
#>             proxy targets or other components

I understand changes to network nodes and name servers, but whta are
"proxy targets"?

#I've pushed all of these up to the web page, and I've also revised 
#the scope-restriction portion at the bottom to highlight the 
#exclusion of WHOIS and "criminal" stuff.

Again, this arbitrarily attempts to exclude a key element about what 
fastflux is all about: the miscreants use fastflux because they HAVE TO
by the vary nature of their enterprise, and the reason we care about 
fastflux is because of what it enables.

If fastflux were to be used for some innocuous purpose, and did not
inherently rely on unlawfully compromised sytsems, would I care about
it? No. I know that I care about fastflux BECAUSE it itself is 
fundamentally based on CRIMINALLY obtained infrastructure (e.g., 
botted hosts), and BECAUSE it enables CRIMINAL objectives (phishing, 
child pr0n, malware distribution, etc.)

#I need better minds than mine to further engage in the Routing Rumpus 
#(hopefully culminating in some proposed language, if any is required.

What's needed is not more language, but the deletion of the arbitrary
and unnecessary scope limits which really shouldn't be part of a 
"definition" in the first place. 

Those unnecessary scope restrictions pre-ordain what options can then
be considered by the group in making recommendations for dealing with
the fastflux problem, and should be removed, allowing the definition
of fastflux to be truly just that.

Regards,

Joe

Disclaimer: all opinions strictly my own.