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

[Dave Piscitello <dave.piscitello@xxxxxxxxx>]

Whatever helps  us move ON.

On 7/29/08 2:56 PM, "Mike O'Connor" <mike@xxxxxxxxxx> wrote:



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