[gnso-ff-pdp-may08] Eric's suggested change to Annex 2

[Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>]

Existing text:

None

Suggested text:

Steve Bellovin wrote this recently in a note to NANOG, in the context of 
discussion of the cache poisoning exploit:
  /This is important.  Kaminsky took a known concept and did the hard
  engineering work to make it feasible.  To slightly misuse a quote
  that's more often applied to crypto, "amateurs worry about algorithms;
  pros worry about economics".  The economics of the attack have now
  changed.  (And we need to get DNSSEC deployed before they change even
  further.)/


This is in two parts. The first is a revised version of the post of 
8/04/08 "Things learned thus far", written to for the RC members, the 
second is a synthesis of several prior notes, and concludes with my 
perspective as the CTO of CORE, a registrar and the registry services 
provider for several registries, and the operator of USAWebhost. The 
demark is the word "Intermission". The pronoun "we" is used in the first 
part, as this has been reviewed by three other registrars. The pronoun 
"I" is used in the second part. Together they amount to about 1,600 words.
Begin.

We know that discussion of this subject is complicated by the assumption 
by some that "fast flux" is a technical term, or a term for a criminal 
activity, or both.
In this note we adopt the convention that what is called "fast flux" has 
a "bad use" and a "good use". This should not be understood to mean that 
we think either use is "bad" or "good", only that we observe a social 
convention that amounts to an abuse of notation.
Part I:

We know that "fast flux" is just one technique used, and that it is used 
together with other techniques, from overt email to covert instant 
messaging, for good and bad purposes. We also know that "the bad use" of 
the technique uses a domain name in the message payload (via email or 
htttp or ... instant messaging or ...), in the past one (or more of a 
set of) fixed ip address was used, and if domain names and a fixed 
payload weren't more economic than a set of ip addresses in a set of 
payloads, that "the bad use" would still be using address sets rather 
than "fluxed" domains, and will return to using address sets and sets of 
payloads if domains become less economic for their business model(s).
We can get the "bad use" out of the DNS, in theory (ignoring cost, the 
risk to "good use", and who pays it all), but that won't get the "bad 
use" out of the net.
What is more, as ipv6 transition continues, and router vendors, and 
network service providers adapt to the physical fundamentals, which 
affects the business fundamentals of network service providers, whatever 
the "bad use" can exploit it will to retain and expand its business 
model(s).
Part II:

There is no data that "fast flux" is affecting the operations of the 
IANA root, or any gTLD, or ccTLD registry.
There is data that "bad use" exploits some of the gTLDs, COM, NET, ORG 
and some others, but not all, and also exploits some ccTLDs, CN, and 
some others. The "bad use" is proportional to volume, no other 
relationship is yet supported by data. The same applies for "good use" 
(load balancing, censorship evasion, etc.).
Government is not involved in the Working Group.

Part III:

While decreased TTL values for nameservers could increase load on the 
root and registry servers by a factor of 5, the number of NS records 
being "fluxed" is sufficiently small that actual load induced is not 
detectable. We're also unable to find any damage to registries, 
registrars, or registrants, directly and uniquely produced by "bad use", 
to those roles and their standing in the ICANN gTLD system, and suspect 
the same is true for the IANA ccTLD system as well.
Part IV:

We've got an improvement over the original definition, and in the course 
of doing so have developed an understanding that discerning "bad use" 
from "good use" requires human intervention, and even so may fail.
There is no consensus about the scope of the Working Group, some think 
it is a debating exercise, some think it is an exercise whiteboarding 
solutions, etc.
Part V:

We don't know if this is a real problem, or even a solvable problem. If 
it is a real problem, it appears that the cost is intended to be paid by 
registrars. Arguing against this being a real problem is the fact that 
the network operations community (with or without the ICANN ASO and/or 
GNSO ISPC, as presently constituted) is uninvolved. Similarly, 
Government is uninvolved.
Intermission

This isn't our problem. It isn't our problem because we can't fix it. It 
isn't our problem because it doesn't affect us.
It isn't our problem because we can't fix it.

We could fix it if the second "N" in "ICANN" weren't a fiction. However, 
both the institutional engagement of the NRO {ARIN, RIPE, APNIC, LACNIC, 
AfriNIC} in ICANN is insufficient, and the operational role of the IANA 
is limited to allocation of ASnums and IP address blocks.
We could fix it if the first "N" in "ICANN" were operational. However, 
despite adequate institutional engagement by generic DNS registries and 
their registrars, their operational role in DNS is also limited to 
allocation of some 2LD (and for some, 3LD) DNS resources. And of course 
the whole "fix" fails outside of the g-space.
The authority/delegation models between the name spaces and the address 
spaces are analogous. However, both lack operational means of 
validation. In theory, were validation of each possible, the two could 
share a common trust anchor, and in theory, ICANN could manage the 
common trust anchor. Of course, multiple trust anchors are also possible.
The requirement for what is called an RPKI (routing public key 
infrastructure) arises from real "security and stability" issues. 
AS36561, AS7007, AS27506 and AS9121 are all  events which altered 
routing. Today's "accidents" are tomorrow's exercises in operational art.
Any mechanism which is indifferent to the stability and security of the 
operating systems executing on network attached nodes, that is, which 
accepts socializing the cost of Microsoft's memory protection model to 
third parties, and relies upon some property of the attached network, 
and which attempts to validate some information originating elsewhere, 
to enable some admission control or related mechanism(s), requires a 
mechanism to provide trust, and some anchor for that trust.
A Resource Certificate Trial was conducted by APNIC using X.509 v3 
Public Key Certificates (RFC3280) with IP address and ASN extensions 
(RFC3779), using OpenSSL as the foundational platform (adding resource 
extension (RFC3779) support) with the design of a Certification 
framework anchored on the IP resource distribution function.
We could be fixing, or sharing the trust anchor(s) that enable fixing, 
the authority/delegation predicates for policies which degrade the value 
of the compromised assets which make ancillary use of the DNS. 
Unfortunately, we're not, and we're not likely to be given (a) the 2nd 
"N" problem (at both levels), and (b) the institutional benefits of 
identifying a "security problem" which can only be cured by advancing 
some agenda within ICANN.
It isn't our problem because it doesn't affect us. Not the IANA root. 
Not the gTLD registries. Not the ICANN accredited Registrars. Not the 
Registrants. Registrants loose domains, but not because of this. 
Registrars go out of business or their ICANN chit is yanked, but not 
because of this. Registries, well, no failure data yet, some failure to 
thrive data, but none of it remotely attributable to this.
CORE doesn't process credit cards, and CORE's prices are above the sum 
of the ICANN and registry fees. We don't offer below-price, and we 
simply don't race to the bottom and subordinate our business interests 
to the interests of the credit card industry. We don't have credit card 
fraud, and because we don't have a lot of similar abuse issues, we 
suspect that abuse is more sensitive to price and highly automated 
resource provisioning than any other control. I observe the same in 
another registrar I operate and we observe the same in the registries we 
operate, or have operated, and those we regard as similar to CORE's -- 
.aero, .cat, .museum, and .coop.
Not only are we unwilling to accept the consequences of 
non-registrars-non-registries attempting to socialize their costs to 
registrars and registries, we're unwilling to accept the consequences of 
sub-cost registrars attempting to socialize costs to actual-cost 
registrars. Running with credit card scissors may look exciting, but 
walking with a checkbook and invoices is just as effective a way of 
getting from A to B.
Our contract with ICANN does not require us to share the fate of the 
credit card industry, or to adopt their fraud risk, or place our Members 
or our Secretariat in the position of being likely to be the target of a 
take-down attempt or domain hijacking to benefit businesses which 
elected to share the fate of the credit card industry and adopt their 
fraud risk. We're not unaware of the problem, or indifferent to it, but 
socializing the cost of theft from some victims, who accepted the risk, 
to more victims who did not, and have no share in the benefits from that 
involuntarily shared risk, doesn't solve the problem, it merely repeats 
the theft.
There have been unintended consequences.

We need to reconsider the institutional role of "security". We can 
accept that ICANN's "security" agent may be compromised, and is in the 
present. Do we leave it unminded, pretend it didn't happen, and won't 
happen again, or do we take it as a given and institutionalize 
corruption, parcel out the "security" budget to the constituencies and 
get on with "security" being both subjective and created by compromise? 
The capture of the "security and stability" blob in the org chart by the 
"identity theft" mob is a non-trivial event. The upcoming SSAC Review 
(http://www.icann.org/en/reviews/ssac/wg-draft-tor-13aug08-en.htm) is 
the appropriate venue to pursue the question of the SSAC's performance, 
structure, and institutional responsibilities.
I've written about parts of this in longer notes to the WG mailing list, 
addressing the issue of overstated harms, covert benefits, scope, and 
the distribution of data, as well as the serious problem of non-data for 
evasive use a resiliency technique for economic, and political ends, 
which are criminal in only some jurisdictions. Not that anyone needs to 
read these, I'm not particularly attached to the fancy of constructive 
discourse, which has failed, but for the poor sod combing through the 
list traffic for ideas, these seven were mine.
8/04/08 Things learned thus far
7/20/08 Towards a recommendation
7/20/08 Sunday Benefits
7/19/08 Saturday Harms
7/17/08 The Registrants question (was: Re: [gnso-ff-pdp-may08] Draft - 
How are registrants affected by fast flux hosting?)
7/17/08 The Registries question
7/02/08 Re: [gnso-ff-pdp-may08] Jump start on answering GNSO questions 
regarding fast flux
Two additional posts, one to the chair, and one sent to an ad-hoc 
sublist, I'm also responsible for:
8/08/08 Off-list: rechartering input
7/12/08 Draft for restatement of scope

End

Eric Brunner-Williams