ICANN ICANN Email List Archives

[gnso-ff-pdp-may08]


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

Re: [gnso-ff-pdp-may08] Crafting a solution for fast flux

  • To: joe@xxxxxxxxxxxxxxxxxx
  • Subject: Re: [gnso-ff-pdp-may08] Crafting a solution for fast flux
  • From: Marc Perkel <marc@xxxxxxxxxx>
  • Date: Thu, 17 Jul 2008 07:10:32 -0700


Again Joe you have done a wonderful job of clearly presenting your ideas.

Many of your solutions, which I agree with, raises questions about our mission here and the scope of our solution. I personally agree that policy and best practices for ISPs is a big part of the solution. So I have this question. Is that something that ICANN does? Is that part of our mission or is it outside the scope of what we are dealing with. I'm hoing the answer is that it is part of what we (this group) and ICANN does because I'm 100% in agreement with Joe on this.

Also - as to our mission in general, although we are the FF group the real mission is part of stopping fraud. So I'm thinking in terms of "the greater mission" that FF is a part of. Is that a fair assessment?


Joe St Sauver wrote:
Marc asked:

#If I'm not jumping into the solution side to fast, what do you think is #the best solution?

I don't think any single thing will eliminate fastflux, I think a
multipronged strategy will be needed (including improved information
sharing, as you've suggested). A short/very incomplete list:

-- Publicly encourage service providers to have abuse reporting addresses,
and current domain/IP/ASN whois point of contact data (including an explicit abuse contact in those whois records). Flag those who elect NOT to do so.
-- Name servers in domain registrations should be identified as static or
   dynamic by the registrant. If static name servers, the IP's used for
those name servers should be provided. If dynamic, that's fine, but sites electing to use dynamic name servers should expect that their choice will be taken into account when other sites assess their reputation and decide what (if anything) they want to do with their traffic. Charge a premium for dynamic name server domains.

-- Changes to static name server IPs should also incur a nominal fee, split
   between ICANN and the Registry, with the funds received from that fee
should be dedicated to abuse handling/security-related purposes at ICANN and each Registry.

-- Encourage ISPs to document IP address ranges which should NOT be
   hosting web pages or DNS servers, much as the PBL is used to document
   IP address ranges which should not be emitting email.

-- Fix the WDPRS process, so that fastflux domains with bogus contact
   information can be efficiently reported.

   What would such a "fix" entail? Well, I'd start with:

   1) If one domain with a given bit of bad information is reported,
      make it possible for submitters to request equivalent treatment
      for ALL domains that share that same specific information defect.

      Thus, for example, if someone registers 150 domains that all
      have the hypothetical and obviously bogus address:

blah blah blah you can't catch me
      north, pole 99999

do NOT require someone reporting those addresses to report all (or some fraction of all) 150 domains one-by-one.

   2) Publish monthly summaries of unique complaint volumes by registrar,
      by TLD, and by name server. Also provide a report by privacy
protection service associated with complained-of domains. 3) FOLLOW UP on WDPRS complaints and make sure that something is DONE about the issues which get identified.

   4) Provide a channel for Internet users to report illegal domain use
(currently it is rather ironic that ICANN will let me report a domain for having the wrong zip code, but not for hosting a phishing site or child pr0n -- something's wrong there, I think).

5) Allow users to flag domains that appear to be fastfluxing. -- Encourage the creation of national cleanup resources for those whose systems have been infected by bots. These resources may vary from country
   to country, but should include technical experts who can help clean
   and harden infected systems (along the lines of what I proposed in
   http://www.uoregon.edu/~joe/ecrime-summit/ecrime-summit.pdf )

-- Encourage ISPs to instrument their own networks, so they have
visibility into what's being done *with* their resources, and *to* their customers. Fastflux can only survive if networks are blind to upstream hosts.

Regards,

Joe




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

Privacy Policy | Terms of Service | Cookies Policy