| <<<
Chronological Index
>>>    <<<
Thread Index
>>>
 
 [gnso-ff-pdp-may08] Things learned thus far
To: "gnso-ff-pdp-May08@xxxxxxxxx" <gnso-ff-pdp-May08@xxxxxxxxx>Subject: [gnso-ff-pdp-may08] Things learned thus farFrom: Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>Date: Mon, 04 Aug 2008 13:51:03 -0400 
 
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
 
 <<<
Chronological Index
>>>    <<<
Thread Index
>>>
 
 |