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

[Joe St Sauver <joe@xxxxxxxxxxxxxxxxxx>]

Marc commented on some of the stuff I'd sent along:

#> -- 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. 
#
#I agree in general but we also need to migrate or mirror whois data to a 
#DNS based system so that it can be queried through automation rather 
#than manually. Whois is a manual protocol and not suitable for real time 
#queries by spam filtering systems. Thus the information in Whois is 
#useless to me unless I'm doing it by hand.

I concur that machine readable access to data is crucial.

The most commonly heard objections to offering that sort of access are:

-- the data will be scraped and abused by spammers (but that's already
   happening via existing channels, so I don't see providing machine
   readable data as making that worse)

-- this is a new service, and will errode already razor thin registrar
   profit margins (I don't think this would necessarily be a show stopper
   since CAPEX requirements would be modest, and automation would 
   limit ongoing OPEX requirements)

#> -- 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.
#>   
#I'm generally opposed to using fees as an anti-spam solution. 

The fees I suggest aren't an anti-spam solution, they're designed to 
insure that a sustainable business model is in place to address abuse/
security issues. Without a sustainable business model, the first thing
that happens in any budget crunch is, "Oh heck, let's just cut the abuse
handlers, they're not making us any money"

Fastflux is a specific example of a generalized problem: domain name
abuse. If you want to lay the foundation for fixing the generalized
problem, you need a sustainable funding model.

#Spammers have/make a lot of money and can afford it. Fees tend to 
#discourage use by poor people. A small fee to us is a day's wages in 
#parts of Africa. 

And yet, a person in Africa *with the Internet* has access to world
populations and the same online income generating opportunities as 
anyone else. For example, if they have a popular web site that 
generates advertising revenue, what might be money for pizza to you 
or me might be effectively a major source of supplemental income for 
someone in an economy where annual wages might be measured in hundreds 
of euros/year. As a member of the world Internet economy, a user 
ANYWHERE may have income opportunities that may dwarf the opportunities 
offered by their otherwise strictly local economies. 

And then there's the fact that the Gini curve for Africa isn't exactly 
linear. At the same time there are people living in utter poverty, 
there are those living quite comfortably, easily to a North American 
or western European standard. What of equity when it comes to them? 
Merely being from the AFNIC region (or any other segment of the 
world's population) isn't 1:1 synonymous with a financially tenuous 
existence. Unless we're talking about some sort of income-based
progressive/sliding scale fee structure (which I'm not), I think
the answer is that economic burden simply can't be factored into
the fee structure (for example, .com's aren't less in the world's
poorest countries than they are in the richest ones). 

And finally, recall that we're talking about fees for services
that the vast majority of users will NEVER experience (heck, I'd
even be fine with the notion of comp'ing one change to static
name servers for free).

#Alternatively we should require capcha to eliminate automation, and 
#if automation is required by legit services then charge a fee for 
#automation access.

Captcha are proving unfortunately less resistant to attack (human or
automated) than service providers might like. See, for example:

"Breaking a Visual CAPTCHA" 
http://www.cs.sfu.ca/~mori/research/gimpy/

I quote in part:

"This is the homepage of the Shape Contexts based approach to break 
Gimpy, the CAPTCHA test used at Yahoo! to screen out bots. Our method 
can successfully pass that test 92% of the time"

Or see http://www.botmaster.net/pictocod/

Without at least a nominal fee, the system will be gamed, just like
"unlimited free refills" at a fast food restaurant beverage bar. (charge
a small but non-zero fee, like maybe fifty cents, and wastage and abuse 
problems largely disappear)

#> -- 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.
#>   
#I'm totally with you on this. I think there are a lot of things the ISPs 
#can do to eliminate spambots. I think consumer modems should, be 
#default, provide NAT or the ISP should just give consumers fake net 
#addresses (10.x.x.x) so that the web can't surf them. The idea being 
#that the average person is not a technical wizard and needs to be 
#protected from the internet. Thus if they got hacked and became a web 
#server or DNS server no one could reach it.

And there's the real (largely unspoken) risk/cost of NOT dealing with 
fastflux: loss of end-to-end connectivity and Internet transparency. 
(That was the problem I was describing in "Cyberinfrastructure 
Architectures, Security and Advanced Applications," 
http://www.uoregon.edu/~joe/architectures/architecture.pdf ), BTW.

In the good old days, every node was not just a passive consumer of
Internet "stuff" provided by others, every node was also a potential
content provider, with access to all ports. 

As we become increasingly firewalled and NAT'd, that sort of model
disappears, and suddenly legitimate, cool, innovative applications
become tricky, or perform poorly, or fixing security issues becomes
convoluted (if you don't believe me on this last point, talk to 
heavily firewalled sites who trying to figure out how to deal with
DNS port randomization, which at least some firewalls did not handle
well at all).

#I could go on forever about ISP policy but I'll say one more thing. If 
#there were an open source project to create tools for ISPs to manage 
#spambots I think ISPs would use them. So if such a project were created 
#then I think it would take a big bite out of the spambot world.

I used to think that too, then I began to ask providers, "Why do you
buy commercial anti-spam product <foo> instead of running the excellent
free/open source anti-spam product <bar>?" and I learned that for most
of these guys, their purchasing criteria are:

-- scalability,
-- availability, and
-- effectiveness

and usually in that order. 

It has to handle what's thrown at it, and it simply always, always,
has to be there and working, and it should work well.

Acquisition cost (the key differentiator between commercial and open
source solutions) isn't even on the radar, and I've ever heard some
people say (and note that this is NOT something I personally believe),
"If the open source product was any good, someone would be selling
it and making lots of money from it." [obviously that comment reflects
a lack of underststanding of what motivates open source authors, and
the value of open source solutions, but there you go]

#> -- Fix the WDPRS process, so that fastflux domains with bogus contact
#>    information can be efficiently reported.
#>   
#I agree that reporting is key. Especially automated reporting so that if 
#an ISP gets reports from several sources about one customer then by 
#using automation that IP could be closed on the offending port. I think 
#this can be solved with an open source project to provide ISPs with tools.

And yet fastflux provides little motivation for Jane Average Use or John
Typical Person to take the time to report. Unlike spam, most people don't
know that fastflux exists, nor would they know to whom they should report
it.

#>    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.
#>   
#Yes - even fake domain owners can be classified by being the same fake 
#owner. Thus if someone had 150 domains and multiple domains were 
#receiving complaints action can be taken against all of them.

I may not have stated my point here clearly: even if domains aren't
being abused, if bad whois data has been detected, it should be flagged
for correction as soon as it may be detected and reported.

If whois data is inherently bogus (as the example shown above), when it
is reported for one domain, domains that have identical wrong data should
also be flagged for correction (imagine a tick box marked, "And any other
domain with the same correct data" besides the name field, the address 
field, the phone/fax number field, and the email address field).

#>    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. 
#>   
#I don't quite understand this. Joe - you could build a wiki outlining 
#all these ideas.

I believe the vast majority of registrars have de minimus levels of abuse,
and work hard to deal with the stuff that slips in. On the other hand,
there are some registrars who take a much more laissez faire approach.
This would become immediately apparent if there were monthly reports that
showed relevant numbers, like the number of complaints received in 
conjunction with that registrar (you also need the total number of domains
they have, so you can normalize the raw complaint count):

Registrar                                 Domains   Complaints This Month
-------------------------------------------------------------------------
Joe's Bait Shop and Discount Domains      650,000   40,821
Too Cool Registrations                   1,720,000  14,177
[etc]

Similarly, some TLDs experience disporportionate levels of abuse, and 
likewise some private domain registration/whois privacy service providers. 

The much-storied Knujon registrar study is an example of this sort of thing,
but it shouldn't need to be teased out by 3rd parties, it should be done
in house as an audit/compliance issue.

Regards,

Joe