ICANN ICANN Email List Archives


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

RE: [gnso-ff-pdp-may08] The need for facts

  • To: gnso-ff-pdp-May08@xxxxxxxxx
  • Subject: RE: [gnso-ff-pdp-may08] The need for facts
  • From: "Mike O'Connor" <mike@xxxxxxxxxx>
  • Date: Sun, 13 Jul 2008 17:09:38 -0500

At 04:13 PM 7/13/2008, Joe St Sauver wrote:


ah.  thanks for humoring me...

David, i'm kinda responding to your note as well, so you may want to read along...

#1) what facts would we need in order to understand its scale and scope?

1a. How many IP addresses are known to be participating as fastflux nodes?
1b. How many domains names use fastflux?
1c. How many unique name servers support fastflux domains?
1d. What fraction of those unique name servers are themselves served on
    fastflux IPs?
1e. What registrars or registration service providers have been used to
    create fastflux domains?

i like these first four -- they seem to be crucial to understanding what we're dealing with. in order to make the data easier to collect (i'm starting to get the glimmer of an idea), let's rephrase just a bit.

- let's assume we've recruited some partners (some ISPs, some registries, some registrars, some really big data-center shops -- people with Big Routers and Lots of Traffic). a purely voluntary effort, not something laid down in policy.

- let's further assume that we've hammered out a methodology, and maybe even some code, for our partners to use. shared tools, that return consistent data no matter who deploys them. hm. open source... etc. etc...

- let's stay away from tinkering with protocols (WHOIS, DNS, etc.) if we can -- mostly because that's Too Hard, at this stage in the game.

so. we deploy our toolset and our partners use those tools to gather data -- and here comes the rewording...

1a. How many IP addresses do you see that are known to be participating as fastflux nodes?
1b. How many domain names do you see using fastflux?
1c. How many unique name servers do you see supporting fastflux domains?
1d. What fraction of those unique name servers that you see are themselves served on
    fastflux IPs?
1e. What registrars or registration service providers have been used to
    create fastflux domains that you can see?

this is the kind of question that (if i still owned my ISP -- gofast.net) i'd throw at Ralph and Marv and see if they could write some cool code that we could just run locally, maybe on the router, maybe on some kinda packet-inspection box close to the router, i don't know.

it probably wouldn't take long to come up with a pretty good set of statistics that would at least approximate how bad this problem is...

1f. If notified that a customer's domain is fast fluxing, what (if anything)
    will a registrar or registration service provider do? How long does it
    take them to do it? If they do nothing, why? If they *do* do something,
    what do they do?
1g. If notification is made to ISPs, will they pass those notifications
    along to the infected customers? If so, do the customers, once notified,
    appear to be remediated (or at least cease to be seen as fastflux nodes?)

these last two don't excite me as much. partly because we're tiptoeing into a tech/policy "solution" again, and partly because this data would be much much harder to collect. so i'd leave these for now.

#2) where could we get those facts?

2a. Accept a feed of fastflux domain name candidates, and verify the IP
    addresses on which they live.

i like...

2b. From the 2a list, extract name servers and registrars/registration
    service providers

i like...

2c. Contact the registrar/registration service provider with the observed
    data, and note their response (including the time required to make
    those reports, and the time required for the registrar/registration
    service provider to respond/react). Truncating the right tail of the
    response window at some reasonable time period may be desirable.

not so keen on this one -- same reason as a minute ago. we're getting outside the bounds of a "passive" monitoring approach and into policy.

2d. Track individual fastflux IP's over time,

i like...

 including noting time of
    ISP notification.

not so much, see above...

#3) are the statistics being collected now? how well -- is the data credible?

3. I'm a big believer of data replication and validation. I'd encourage folks
   who feel likewise to participate in measuring this phenomena. Replication
   brings validity and trust.

right! that's why i like my notion of building a set of tools so that anybody with a lot of traffic could help out.

#4) if they're being collected, is the person/organization willing to
#share them?

4. In the "everyone a gardner/hunter, everyone a chef" model, that's up
   to each gardner/hunter chef. :-)

could be -- what i was getting at here is that somebody may already be making a business out of collecting some of the data we need, and might not want to give it up without payment. or at all. there's a lot of proprietary stuff out there these days...

#5) if they're not being collected now, what's the best place to get
#them and is it worth it to go after them?

WRT to the "is it worth it to go after them," Am I detecting backsliding
from the earlier "we like facts/data?" :-;

no, although i'm a notorious backslider. in this case, what i'm getting at is the notion of data cost. sometimes we may need to trade off the value of the information against the cost of acquiring/processing it.

Data collection isn't completely painless, but it doesn't need to be
particularly painFUL, either.


#at this stage of the game, i'm yearning more for reliable information
#*sources* than raw data.

Be paranoid. Trust no one. A thousand eyes are better than one (or even
two :-) ). Information you collect yourself is the best information of all.

a lot of my security geek friends would lean into that statement. for example, the only encryption algorithms that they trust are the ones that are public, so that they can be peer-reviewed. i have a feeling that our data-needs are similar. i'm more trusting of "open" data than "proprietary" data in this area.

#reliable/public/published methods of analyzing that data to help us
#understand the breadth and depth of the problems we're looking at.

The nice thing about fastflux is that it is "self-exposing" once you
know where to look. Happy to start suggesting relevant rocks.

let's start building tools to let lots of folks look under those rocks...

which raises another one of Dave's points -- we need to make sure that we don't accidently create unintended consequences (where bad-actors move on to other exploits) with our data-gathering. so another design-criteria would be to make these "watching" tools as nimble as possible so that they could be quickly updated to "watch" for new exploits.

#one of the things that i'm pondering is the need for some sort of
#collaboration between us (ICANN) and some of the other institutions
#that are out there.

Collaboration is very good, as is your list. At the risk of stating the
obvious, I'd also suggest the APWG be formally on that list, and MAAWG.

doh!  sorry about that.  of course.

The Educause Security Task Force is actually the Educause/Internet2
(or Internet2/Educause) Security Task force, and that's yet another
activity I'm involved with as part of my $DAYJOB. :-)

#sorry about the US-centric list, this is just a list that comes to
#mind, left over from the days when i worked for a living.

Terena is one technically oriented possibility from Europe.

Since we're talking about cybercrime, I also wonder about law
enforcement agencies, such as Interpol.

Would vendors also provide a useful source of data?

yea verily. Cisco is very active on SSAC, would probably be a great candidate...

#thanks Joe for the speedy reply, even though it did sorta make my
#eyeballs peel.  :-)

De nada. :-) Happy to peel eyeballs anytime. :-)

great comeback. thanks guys. enjoy the rest of this beautiful Sunday -- we're having incredibly wonderful weather here at the farm.




Disclaimer: all opinions strictly my own.

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

Privacy Policy | Terms of Service | Cookies Policy