RE: [gnso-ff-pdp-may08] Definition V4.2

["Mike O'Connor" <mike@xxxxxxxxxx>]

at this point my plea is for converging definitions rather than 
diverging.  i'm feeling the need to get a stake in the ground and move ON.
i'm meh on the "compromised vs plurally-purposed" debate and can go either way.

routing was discussed in previous email, and i find the "discard it" 
arguments more compelling.
"intent" has been discussed in previous email AND two phone 
conversations, and i find the "discard it" arguments more compelling.
"change in TTL" correction duly noted -- Dave, you want to comment on 
that?  is it low TTL, or *changing* TTL, or both?
m

At 01:44 PM 7/29/2008, Joe St Sauver wrote:
> #A Fast Flux network is, for purposes of this working group:
> #
> #     * operated on one or more compromised {"plurally-purposed?"} hosts
>
> "Plurally-purposed" strikes me as a phrase that will distract rather than
> inform readers of this definition. Everyone knows what a compromised machine
> is, but I've never ever heard someone refer to a "plurally-purposed" host.
>
> #     * operated for the purpose of hosting unauthorized, malicious or
> #criminal content
> #       {delete? - "illegal vs political" issue}
>
> Do not delete. This is a key attribute.
>
> #     * operated using software that was installed {on hosts} without
> #notice or consent to the
> #         system operator/owner
> #     * "volatile" in the sense that the network changes its topology
> #for the specific
> #         purpose of sustaining the lifetime of the network and the
> #attack(s) the network supports, using:
>
> As I've previously mentioned, the topology of the network actually doesn't
> change, only its instantiation on specific hosts.
>
> #           o (rapid) modification of TTLs for name servers and
> #malicious content hosts
>
> Also as previously noted, the TTLs themselves do NOT change; if you see
> a fastflux host with a TTL of 120 seconds, it will NOT later have a TTL
> of 7200 seconds.
>
> #             {threshold? 1700 changes a month is avg TTL of 1525}
>
> That assumes you catch all changes, and that a given dotted quad is never
> used for more than one TTL's worth of time. In reality, a particular dotted
> quad hosting a fastflux host may have a TTL of 120, but may be used for
> an hour or more if there's no need to change it.
>
> #           o monitoring to determine/conclude that a host has been identified
> #             and shut down {by its owner? how do we identify?}
>
> Also as previously mentioned, if the fastflux host is being used in classic
> reverse proxy mode, the backend host has intrinsic monitoring capabilities
> since it can see where the traffic it receives is coming from
>
> #           o time- or other metric-based topology change {how do we 
> identify?}
> I don't know what this means.
>
> #     * {Limit the problem to "within the scope of ICANN to address"
> #           o Operation of the DNS system
> #           o Registration services
> #           o System-operators can't be reached/contacted
> #           o Does NOT include; routing, end-point security, etc.}
>
> Again reiterating points that have been previously made, but apparently
> not selected for inclusion by our gentle scribe, :-), routing (at least to
> the extent that ASN's are being manipulated by miscreants) is or should
> be in scope, and if you don't deal with end-point security, you've
> basically determined that fastflux is out of scope, because fastflux is
> all about a phenomena that is hosted on, and relies upon, insecure
> end points.
>
> To emphasize the routing component, one of the easiest ways to quickly
> identify fastflux hosts is by watching for a diversity of ASNs associated
> with the IPs mapping to a domain name. If you exclude that approach, you
> significantly weaken your ability to readily and mechanically identify
> fastflux hosting.
>
> Ignoring the role of routing also discounts the way many abuse complaints
> get routed these days ("if you route it, you're responsible for what
> comes out of it").
>
> Regards,
>
> Joe
>
> Disclaimer: all opinions strictly my own
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.138 / Virus Database: 270.5.6/1579 - Release Date: 
> 7/29/2008 6:43 AM