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

[Joe St Sauver <joe@xxxxxxxxxxxxxxxxxx>]

Hi Eric,

For those who just want the one sentence version: I'm having a hard time
understanding how you arrive at some of the conclusions you apparently
arrive at below, and in other cases, I simply find myself unable to parse 
what you're trying to tell me.

For example:

#o as a specific technique, it is an optimization of a resource
#utilization, and if completely mitigated, the underlying resourc
#utilization would not be sufficiently mitigated to end rational economic
#criminal activity presently optimized to exploit resilient resources in
#distributed, public stores,

I've read that a bunch of times, and I still don't think I understand
what you're trying to say. Are you saying, "Try as hard as you want,
even if you succeed in eliminating fastflux, the miscreants will just
try something else that's comparable." 

Is that what you're trying to say in that paragraph?

#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.

Perhaps the reason why the problem has been unrelated to the areas you
mention is that they *are* effectively unrelated? 

For example, let's consider the identifier/locator split you mentioned.
Dave Meyer, here at Oregon, has been very active in this work, including 
co-authoring things like http://tools.ietf.org/html/draft-meyer-lisp-cons-04 
so I've been following at least some of that work and I'm *not* seeing the 
connection between fastflux and that work at all.

If I'm just not getting those connections, I'd genuinely appreciate you
making those connections for me and the others on the working group
who may possibly also not get them (or if I'm the only one who's not
getting those connections, can someone else help me out?)

#PART II:

Can you talk about what the various parts represent? For example, is
Part I an Intro, Part II about Data, Part III about ...? Understanding
how you've carved things up would help me to understand the items you
call out in each part.  

#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,

Does the practice of non-gTLDs bound the frontier of gTLD activity? I'd
hope not. 

Do we *really* need an example from .edu, .gov, .int, .mil or other
2nd tier gTLDs in order to deal with a problem that is clearly present in 
.com, .net, .org, .info? I'd certainly hope not...

Regarding volume, I know that various researchers have been providing the
working group with data, although I don't know if that data is being
summarized and shared back out yet. Can someone who's been taking that
data in speak to that issue? 

#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)

How is this different from the preceding claim? 

#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,

Could you remind me of what that data might be? I recall the potentially
fatally flawed Ultrareach example that's been under discussion, but how 
about the non-evasive case?

#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,

I find it hard to reconcile these two items! First, I hear about a 500%
increase in load, then I hear "no data has been identified which supports
a claim of damage to the security and stability [...]"!

I might accept one or the other of those, but the two in immediate
juxtaposition makes accepting both at the same time difficult if not
impossible!

#o no data has been identified which supports a claim of damage to ICANN
#accreditation of registrars by the use of the technique,

I do not concur. Currently many FF domains are challenged by anti-spam
and anti-phishing folks using the one channel that's readily available to
them: the WDPRS whois data problem process, and approach that's possible
because of the strong correlation between FF and bad whois data. The 
registrar's processing of those complaints, or the lack thereof, has a 
distinct potential for impacting the accreditation of registrars targeted 
by fastflux miscreants. 

#o no data has been identified which supports a claim of damage to domain
#registrations by the use of the technique,

Damage to domain registrations meaning "unauthorized changes to existing
registrations" or something else? 

#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.

This sounds like Randy's suggested definitions, correct?

#Definition: A Volatile Network is one which is purposed to distribute
#logically identical services over multiple (perhaps virtual) hosts at
#request time.

I do not believe that consensus exists around the Randy-suggested definitions.

#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.

And that's one of the reasons why those definitions aren't particularly
helpful, unfortunately. 

#Definition: A Volatile Compromised Host Service Network (VCHSN) is a
#volatile network which is also a CHSN.
#
#The fastflux vernacular refers to a VCHSN.

I've never, ever, anywhere heard anyone refer to a VCHSN except in 
Randy's posting (sorry), and googling for that term, I only see it
in the archives for this working group (there are some other completely
unrelated pages, but that's it for VCHSN and DNS).

#o the stated scope is not yet restated to the working group's rough
#consensus.

I don't understand what that means (unless it means, "The working group
hasn't yet agreed on those proposed definitions," in which case I agree)

#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 =93chicken little=94?

It depends, I guess, on whether you believe spam, phishing, and the
host of other ills enabled by fastflux to be a problem.

#o if real, is the problem cost being socialized to third-parties
#(registrants, registrars, registries, and ICANN as a whole)?

I would phrase this, "If there's no other way to cope with fastflux
domain name related abuse, is there any reason why the domain name
community should not accept their responsibilities in mitigating this
problem?"

#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?

I continue to be extremely concerned about any approach that would require
individual action by every network operator worldwide to fix a problem
that could be dealt with extremely cleanly by ICANN/the registries/the
registrars.

That said, for DNS-related operational issues, the defacto forum for those
sort of issues would be either DNS-OARC ( https://portal.dns-oarc.net/ ),
but note that the Kaminsky vulnerability will have priority over most
other issues there for the forseeable future, in my opinion.

#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?

Isn't that a question that would have been appropriate prior to the
creation of this working group? 

I feel like I'm sitting at mass on Sunday, and the topic of the sermon
is announced as, "Is it time for us to consider formal organized religious
activities, such as Sunday mass?" I'm getting this odd recursive sensation...

Regards,

Joe

Disclaimer: all opinions strictly my own