Re: [gnso-ff-pdp-may08] DRAFT text for Section 5.9

[Rod Rasmussen <rod.rasmussen@xxxxxxxxxxxxxxxxxxxx>]

A couple of practical matter thoughts here.

1) Changing TTLs to short timeframes in order to accommodate systems  
changes, new services, etc. was discussed early-on in the group.   
There are lots of legitimate uses beyond the volatile network services  
that require it to be able to practically limit use of short TTLs.   
Heck, I just used that trick a couple days ago on a server migration!
2) If we actually had the mandate, budget, and proper oversight to  
create the TTL commission or police (or whoever would actually be  
mandated to enforce TTL restrictions on DNS changes across the  
Internet), I think we would be far better served to spend that same  
level of effort/resources on a more general anti-abuse enforcement  
system.  While that may be a long path, the latter would at least be  
more powerful, practical, and perhaps palatable.  I think the  
implications and effort outlined here, while focused on the problem at  
hand, would only distract from the overall effort of fighting on-line  
crime using domain names and the DNS to launch attacks.  At this point  
I'm pretty much convinced that FFLUX is a great red flag indicator of  
potential criminal use/abuse, but not the problem to be attacked.
Rod

On Jun 2, 2009, at 3:00 PM, Greg Aaron wrote:

> Dear Mike:
>
> Please see the two sections about TTLs in the RyC statement, where I
> described the salient technical points.  Registries and registrars  
> do not
> have any practical control over authoritative TTLs.
>
> You'd have to re-engineer the Internet to change that and implement  
> your
> white-list idea.  DNS RFCs 1034 and 1035 are not just any RFCs --  
> they have
> status as Internet Official Protocol Standards.  They describe  
> fundamentals
> of how the DNS works, and are designed into systems.  So if you  
> advocate
> limits on TTLs, you must also advocate that the IETF alter the DNS  
> RFCs.
> The only exception where a registry or registrar has authoritative  
> impact on
> TTLs is where the registrar is also acting as the registrant's hosting
> provider.  However, Web hosting services are outside of the scope of  
> GNSO
> policy-making.
>
> As a practical matter: I think businesses, governments, and the  
> engineering
> community would strongly resist the idea that they would have to  
> obtain
> permission from some body in order to set and change TTLs.
>
> For the above reasons, the FFWG report should not advocate options  
> to limit
> TTLs.
>
> All best,
> --Greg
>
>
>
> -----Original Message-----
> From: Mike Rodenbaugh [mailto:icann@xxxxxxxxxxxxxx]
> Sent: Tuesday, June 02, 2009 2:05 PM
> To: 'Fast Flux Workgroup'
> Subject: RE: [gnso-ff-pdp-may08] DRAFT text for Section 5.9
>
>
> Greg,
>
> It is a conceivable option.  Domain registrants could be notified of
> limitations and opportunity to request permission, by their  
> registrar at
> time of registration, and if they violate rules then could suffer  
> domain
> suspension until they comply.
>
> I am only floating this as a potential option, particularly if abuse  
> of fast
> flux exploits, and resulting harm, continues to grow unabated.  I  
> simply do
> not want our Report to foreclose the possibility, because we have  
> not agreed
> as a WG that it should be eliminated.
>
> Thanks,
> Mike
>
>
>
> -----Original Message-----
> From: James M. Bladel [mailto:jbladel@xxxxxxxxxxx]
> Sent: Tuesday, June 02, 2009 2:00 PM
> To: gaaron@xxxxxxxxxxxx
> Cc: icann@xxxxxxxxxxxxxx; 'fast flux workgroup'
> Subject: RE: [gnso-ff-pdp-may08] DRAFT text for Section 5.9
>
> Greg / Mike:
>
> This is a good topic, but I'm struggling to come up with some common
> language that reconciles both positions.
>
> Greg:  Do some registries / registry sponsors require advanced
> permission before accepting volatile networks into the DNS?  If so,  
> how
> did they come by this authority?  Was it part of an RSEP request?
>
> If so, then this might be a good example of a registry best
> practice.....
>
> Just brainstorming here, so apologies if this takes us off track.
>
> J.
>
> -----Original Message-----
> From: Mike Rodenbaugh [mailto:icann@xxxxxxxxxxxxxx]
> Sent: Tuesday, June 02, 2009 1:15 PM
> To: 'Fast Flux Workgroup'
> Subject: RE: [gnso-ff-pdp-may08] DRAFT text for Section 5.9
>
>
> Hi Greg,
>
> This is an option, particularly if fast flux exploits become a much  
> bigger
> problem than they are today.
>
> ICANN could impose such restrictions authoritatively, in the  
> interest of DNS
> security and stability.
>
> RFC's are not authoritative, are often ignored and sometimes  
> meaningless,
> and can be revised if circumstances warrant.
>
> Thanks,
> Mike
>
>
>   -------- Original Message --------
> Subject: RE: [gnso-ff-pdp-may08] DRAFT text for Section 5.9
> From: "Greg Aaron" <gaaron@xxxxxxxxxxxx>
> Date: Tue, June 02, 2009 12:56 pm
> To: <icann@xxxxxxxxxxxxxx>, "'Fast Flux Workgroup'"
> <gnso-ff-pdp-May08@xxxxxxxxx>
>
>
> Dear Mike:
>
> So you are suggesting that any Internet user in the world who wanted  
> to
> use
> a TTL below a certain threshold would need to go to some authority to
> get
> permission?
>
> All best,
> --Greg
>
>
>
>
> -----Original Message-----
> From: Mike Rodenbaugh [mailto:icann@xxxxxxxxxxxxxx]
> Sent: Tuesday, June 02, 2009 1:10 PM
> To: 'Fast Flux Workgroup'
> Subject: RE: [gnso-ff-pdp-may08] DRAFT text for Section 5.9
>
>
> Again I disagree, as existing legitimate uses could be whitelisted,
> with no
> impediment whatsoever to their existing deployment.
>
> -Mike
>
> -----Original Message-----
> From: Greg Aaron [mailto:gaaron@xxxxxxxxxxxx]
> Sent: Tuesday, June 02, 2009 9:46 AM
> To: icann@xxxxxxxxxxxxxx; 'Diaz, Paul'; 'Fast Flux Workgroup'
> Cc: 'Marika Konings'
> Subject: RE: [gnso-ff-pdp-may08] DRAFT text for Section 5.9
>
> I suggest the statement read:
>
> "Besides their technical or practical limitations, such limitations,
> guidelines, or restrictions would impede current legitimate "volatile
> networks" that use short TTLs and frequent DNS record updates to
> deliver
> their beneficial products and services."
>
> I have removed "likely" because limiting TTLs would definitely impede
> currently deployed legitimate services.
>
> All best,
> --Greg
>
>
>
>
> -----Original Message-----
> From: Mike Rodenbaugh [mailto:icann@xxxxxxxxxxxxxx]
> Sent: Tuesday, June 02, 2009 10:00 AM
> To: 'Diaz, Paul'; 'Fast Flux Workgroup'
> Cc: 'Marika Konings'
> Subject: RE: [gnso-ff-pdp-may08] DRAFT text for Section 5.9
>
>
> Hi,
>
> I disagree that limits on TTL would impede innovation of volatile
> networks.
> We have no indication of that from any source, as far as I recall. I
> think
> it is better to leave the first sentence, and expand upon it, rather
> than
> introduce a red herring argument.
>
> I suggest we delete that last sentence, and instead add a clause up
> front:
> "As explained in section 5.8, none of the possible options..."
>
> Thanks,
> Mike
>
> Mike Rodenbaugh
> Rodenbaugh Law
> 548 Market Street
> San Francisco, CA 94104
> +1.415.738.8087
> www.rodenbaugh.com
>
>
>
> -----Original Message-----
> From: owner-gnso-ff-pdp-may08@xxxxxxxxx
> [mailto:owner-gnso-ff-pdp-may08@xxxxxxxxx] On Behalf Of Diaz, Paul
> Sent: Friday, May 29, 2009 11:07 AM
> To: Fast Flux Workgroup
> Cc: Marika Konings
> Subject: [gnso-ff-pdp-may08] DRAFT text for Section 5.9
>
>
> Here is proposed text for Section 5.9 (which also would appear in the
> Executive Summary re: Charter Question #9. Please share edits/comments
> to
> the list for further discussion/approval at the next FF WG call on  
> June
> 3.
>
>
> Issue
> What would be the impact of these limitations, guidelines, or
> restrictions
> to product and service innovation?
>
>
> Response
> None of the possible options noted above were deemed appropriate or
> viable. Besides their technical or practical limitations, such
> limitations, guidelines or restrictions likely would impede the
> innovation of legitimate "volatile networks" that use short TTLs and
> frequent DNS record updates to deliver their beneficial products and
> services.