ICANN ICANN Email List Archives

[fast-flux-initial-report]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: ICANN seeks public comments on Fast Flux

  • To: fast-flux-initial-report@xxxxxxxxx
  • Subject: Re: ICANN seeks public comments on Fast Flux
  • From: Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>
  • Date: Fri, 06 Feb 2009 20:02:40 -0500

When I wrote one in a series of notes during my period of participation in the gnso-ff-pdp-may08 mailing list (from its inception at the Paris meeting until 9/29, the day following Mike O'Connor's resignation as chair), I attempted a general observation [1]:

   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.

The response this drew, in particular, the fourth point, was that there is no relation between the techniques exploited for evasion or resiliency and the consequences of v4 address exhaustion, and the non-adoption of v6 addressing. I didn't think the response was intended to be particularly useful, and I suggest that a survey of (very) recent events in the operation and deployment of IPv4 and IPv6, and what they mean for the "Internet Architecture" presented at NANOG 45, is worth reading. When Mike gave up on useful work I did also. The list volume was excessive, and the tone was not collegial.

The point raised by Bill Woodcock, that frequent updates flood low-bandwidth and/or high-latency links and constitute a denial of service to (low default TTL for EPP mod commands) had not occurred to me, or to anyone I discussed the circa 2004 UltraDNS marketing ploy (unqualified rapid update), followed by VGRS, and costing differentiating adds from modify/delete in zonefile TTL templates, among some registrars, and some registries, but off the gnso-ff-pdp-may08 list. I'm grateful to Bill for making this observation, as despite the time I spend on the wrong side of the digital divide (off-grid and a low-bandwidth and high-latency drop-prone VSAT hop from everywhere), I was oblivious to this aspect of zone update propagation.

Randal Atkinson's mail too is a valuable contribution to the understanding of what must "go fast" and what need not. Prior to October, the "permissible" use case was really limited to simplistic assertions about load balancers and CDNs. Ran's concluding para is unfortunate in the expectation that a GNSO PDP Working Group pursuing a topic framed by the Business Constituency (or any Constituency pursuing a rather narrow goal of short-term interest advocacy) would be reviewed by the DNSEXT (to which I occasionally contribute quite marginally) or a mobility-related IETF WG (and I've occasionally contributed just as marginally to MANET). Not only do such things not happen, but ICANN has not had a "Protocol Supporting Organization (PSO)", originally proposed[3] by Scott Bradner on behalf of the POISSON WG (to which I've also contributed), as one of the triad of Supporting Organizations (SOs), since the By-Laws[4] of December 15th, 2002, were adopted.

Michael Holder makes a reasonable point, that value and risk exposure is not uniform, and that methods required for consumer banking and finance related applications are distinct from those required for bounded micro-payment schemes or transactions which do not allow scalable capture of value. I'm also gratified to see Bonnie Chun's contribution on behalf of the .hk ccTLD registry.

My process concerns, communicated to the GNSO Chair and Vice Chair, remain. My concerns regarding the SSAC and this GNSO PDP WG, communicated to the former Chair and now ICANN BoD member (NomCom appointee) also remain. Finally, my concerns regarding the lack of technical participation, due to the By-Laws change of 2002, in the BoD and also the GNSO, communicated during the "Improving Institutional Confidence Consultation" also remain.

Eric Brunner-Williams
CTO, CORE


[1] http://forum.icann.org/lists/gnso-ff-pdp-may08/msg00381.html
[2] http://www.nanog.org/meetings/nanog45/presentations/Monday/Meyer_iteotwawki_N45.pdf
[3] http://www.icann.org/pso/pso-mou.htm
[4] http://www.icann.org/general/archive-bylaws/bylaws-12feb02.htm#VI-C


<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy