ICANN ICANN Email List Archives

[gnso-ff-pdp-may08]


<<< Chronological Index >>>    <<< Thread Index >>>

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

  • To: Joe St Sauver <joe@xxxxxxxxxxxxxxxxxx>, "mike@xxxxxxxxxx" <mike@xxxxxxxxxx>
  • Subject: Re: [gnso-ff-pdp-may08] Definition V4.2
  • From: Dave Piscitello <dave.piscitello@xxxxxxxxx>
  • Date: Tue, 29 Jul 2008 11:54:52 -0700

Agree w/r/t "plurally purposed", not only because of the denseness of the term 
"plurally" but because to me, "purpose" suggests intent. As I said earlier, I 
am not comfortable with the notion that people intentionally "purpose" their 
machines to abet malicious activities.

Joe and I also had a side conversation where we discussed whether


 *   inaccurate or intentionally false whois information

Ought to be included in the bullet items that characterize a ff network.

One final comment. I did not intend that every FF network would exhibit every 
characteristic here. I am thinking of approximate matching not perfect 
matching, e.g., if a predetermined or preponderant number of markers are 
present, the likelihood that this network is a FF network is high.



On 7/29/08 2:44 PM, "Joe St Sauver" <joe@xxxxxxxxxxxxxxxxxx> 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




<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy