ICANN ICANN Email List Archives


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

[gnso-ff-pdp-may08] Comments on FF report (Final Review)

  • To: Fast Flux Workgroup <gnso-ff-pdp-May08@xxxxxxxxx>
  • Subject: [gnso-ff-pdp-may08] Comments on FF report (Final Review)
  • From: Dave Piscitello <dave.piscitello@xxxxxxxxx>
  • Date: Mon, 20 Jul 2009 07:34:25 -0700

My comments. I did not go through the Annexes. I also sent Marika some
comments about general formatting.

Pg 3 - DNS via 'fast flux' IP or nameserver changesO. - suggest you remove
all the single quotes as none are needed

Pg 4 - change " decided tostart working on answering" to "decided to answer"
     - no hyphen in likely-targets

Pg 6 - should "Charter Questions" be a bullet item or a heading? It looks
strange as a bullet item (168)

Pg 6 - remove quotes around "bad actors" (187)

Pg 8 - we mention physical harm from illegal pharma activities in the
report. Can we reflect this here by changing (203-204) to read:

"may have their identities stolen; suffer financial loss from
credit card, securities, bank or merchant fraud; or suffer physical
harm resulting from the purchase of illegally distributed narcotics
Or scheduled controlled substances without a valid prescription"

Pg 9 - change "this technology" to "fast flux techniques" (234)
    - delete "of this technology" (235)

     - it is probably appropriate to say "The WG finds the RC's
       statement sufficient and accurate for the purposes of this
       report" (242) to justify why we point to an Annex instead
       of answering the question ourselves?

Pg 10 - delete quotes around volatile networks (325)

Pg 11 - the paragraph for item 11 (360-363) leaves the counsel without an
answer to two questions: (1) what pros/cons did the WG argue w/r/t policy
development, and (2) why did the WG not consider the relationship between FF
and registration issues. I am not suggesting we open these questions again,
but think we owe it to the counsel to provide explanations.

Look for example, at pages 13-14. We could say that "The WG does identify
solutions that could result in policy development, but the WG could not
reach a consensus on whether these should be policy, best practices or
industry solutions." This is IMO a more accurate summary. Similarly, we
could explain that during the course of its study, the matter of
registration abuse was taken up by a separate WG and the FF WG deferred any
study of the relationship between FF and registration services to that

Pg 14 - delete single quotes (460)

Also on this page, should 218-222 be a Note rather than a bullet item?

Pg 20 - delete single quotes around 'legitimate use' (685)

Pg 27 - delete all the quotes in this sentence.

Pg 27 - The Internet Draft on doubleflux expired and is not available at any
official site. I think it would be appropriate to use the title rather than
the URL and say "Double flux defense in DNS (May 2008, expired, no successor
draft submitted).

Pg 28 - I don't understand how lines 899-902 are an "alternative viewpoint"
since the comment here complements rather than opposes what is said above. I
suggest we either add it to line 897 as "Members of the WG observed that
artificially limiting TTLs via consensus policies..."

Pg 29 - delete quotes (956), change "poorly-defined" to "overloaded"?

Pg 30 - I really do object to line 1000 - It's unlikely that anyone will
ever provide a better technical definition of fast flux beyond what is
already written in the literature. I don't understand what a "process
definition" is. Since 1001-1005 get to the heart of the matter, I ask
whether we really need line 1000? My suggested change seems consistent with
the proposed deletion from line 1594 page 47.

Pg 36 - change "the use of short TTLs" to "relying solely on the use of
short TTLs"

Pg 37 - As was the case when pointing to the RC Annex, it is probably
appropriate to say "The WG finds the RyC's statement sufficient and
accurate for the purposes of this report" (1236) to justify why we
point to an Annex instead of answering the question ourselves?

Pg 41, 45 - change "spamvertised web sites" to "web sites advertised through

Pg 44 - change "the user finds their" to "the user finds his"
Pg 45 - change "the need to deal with this mess" to the need to detect
and remove infections and malware from compromised PCs"

Pg 46 - I think the context for "Inbound port 53" is missing. I think
this means that ISPs should not allow residential PCs to accept DNS

Pg 48 - is it appropriate to explain what a netflow/sflow is and how this
would help trace back to traffic/flow origins?

Pg 50 - line 1689 should explain that the WG is talking about setting
minimum bounds on TTLs within the scope of ICANN policy and remit.
Generally, any organization or registry (e.g., CCTLD) could set such a

Line 1706 - I have to object to this claim on the basis that SSAC is making
such a recommendation in SAC040, Measures to protect registration services
against exploitation or misuse. The claim here suffers from the same tunnel
vision that caused people to conclude that short TTLs indicate fast flux. If
you couple strong verification measures (non-repudiable) with the rule that
multiple contacts must confirm DNS updates, you would reduce or mitigate the
likely abuse by criminals suggested in line 1707.

Pg 66 - Lack of an agreed upon definition of fast flux and supporting data

While I agree that this is an accurate historical account, I'm disappointed
that we have not acknowledged the considerable progress made in defining and
characterizing fast flux techniques in this report. As it currently reads,
this section suggests that the WG has failed in some way and I don't believe
this is the case at all. I think it would be appropriate to conclude this
section with 

"The WG began with widely differing perspectives regarding fast flux.
Members considered all the applications and characteristics that are
considered fast flux techniques, and developed a conceptual framework within
which productive discussions about fast flux were conducted. The framework,
while not itself a definition, has proven to be useful when discussing a
subject that is quite difficult to define, in no small part due to the
constant input of new information regarding fast flux attacks and the
innovative ways that volatile networking techniques are introduced to
production networks."

Pg 69 - I don't understand what is recommended in 8.1 and how I am supposed
to respond.

On 7/8/09 4:43 AM  Jul 8, 2009, "Marika Konings" <marika.konings@xxxxxxxxx>

> Dear All,
> In order to facilitate the review and finalization of the Fast Flux Hosting
> Final Report, I have created an updated version 

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

Privacy Policy | Terms of Service | Cookies Policy