RE: [gnso-ff-pdp-may08] Back to work...

[Joe St Sauver <joe@xxxxxxxxxxxxxxxxxx>]

#Meanwhile, a picture came into my head this morning over coffee and I 
#thought I'd share it with you.  Here's a link;
#
# https://st.icann.org/pdp-wg-ff/index.cgi?mikes_infoenginev1

You are quite the diagramatic artist, sir!

I'm also impressed that you instinctively sensed that we researchers are, 
as a breed, slow and thick, sort of the Newfoundland dogs of the network
world. :-) Ah, but to be an ectomorphic Saluki hound some day, instead. :-)

#Observations;
#
#- This is purely optional for all parties.  ISPs *can* add a 
#"Verifier" box to their rack if they want.  Registrars/Registries 
#wouldn't have to change anything.
#
#- The cycle of delivering a DNS response to an end user would remain 
#speedy/scaleable
#
#- The ISPs existing DNS server would be untouched (it just wouldn't 
#get quite as many requests)
#
#- The "Researcher" could go anywhere and could be as thick and slow 
#as needed to determine the "fluxiness" of an address

My counter-observations:

-- I wouldn't assume that at least some DNS-based mitigation at the 
   ISP level isn't already happening, nor that if it is, that it would
   fully or even partially eliminate the need for action by other
   parts of the community

-- While this sort of thing may be optional from ISP to ISP, I suspect
   that if you're at an ISP which did implement this filtering, they 
   would NOT be very likely to make it easy for you as a customer to 
   electively opt to participate, or to opt out.

-- Manual research efforts probably don't need to drive the filtering;
   fastfluxing host can easily be identified on an automated basis, and
   that automation will be needed if the fastflux phenomenon becomes
   widespread. 

-- Expect false positives, until the good guys figure out what's needed
   on a technical basis, and white lists get incrementally built to
   prevent accidents or malicious mis-listings of innocent IPs. 

-- Inserting middleboxes in the network data stream (whether these are
   P2P-focussed traffic shapers, hardware anti-spam appliances, 
   antivirus scanners, firewalls/NAT boxes, or your hypothetical DNS 
   appliance) all result in progressive loss of network transparency, 
   increased costs for network buildouts, and non-coherence from site 
   to site as different sites end up rewriting, or blocking (or not 
   blocking) different entities.

   And can you imagine trying to get your DNS *UN*-blocked at a million
   different sites if there was a false positive? Heck, how would you
   even know to ask to be unblocked?

-- Even if nothing else bothers you about this, don't be surprised when 
   front line customer support staff can't figure out what the heck a 
   customer is running into when something doesn't work. 

   And note: one call to customer service is usually assumed to 
   completely destroy all profitability associated with a customer for 
   period of what may be multiple years.

-- Even if 50% (or 90% or 95% or insert your favorite value here)
   of ISPs elect to clean their DNS data stream, just as some large
   fraction of ISPs filter their incoming email stream, this does
   not mean that fastflux abusers will be deter'd, any more than
   spammers are detered by spam filtering. For example, in the case
   of spam, the spammers simply hammer the unprotected ISPs all the 
   more heavily (bummer if you can't afford spam filtering or the
   extra capacity required, folks), compromise additional hosts more
   aggressively in an effort to replace no longer useful hosts that
   have been block listed, etc.

-- We can add this incredible additional complexity with boxes and
   arrows going all over the place, at every ISP everywhere in the 
   world, or the community can deal with its criminal customers whose 
   business model relies on hosting their content on clandestinely 
   bot'd consumer PCs at the one choke point that exists, namely
   the registrars.

Regards,

Joe

Disclaimer: all opinions strictly my own