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

[Dave Piscitello <dave.piscitello@xxxxxxxxx>]

The fact that ICANN's scope is limited to dealing with matters related to 
assigned names and numbers should not interfere with our attempt to develop as 
full and accurate a definition for FF as possible.

Lots of the elements that comprise a FF network are outside ICANN's scope.

Randy's data points regarding routing are corroborated by data Rod, Greg and I 
received from Nicolas Bourbaki. He has data from a FF network that shows one 
phishing host that resolved to IPs in 375 different ASNs. I think I mentioned 
this in a previous mail.

While the nesting of comments is fast becoming inpenetrable, I am liking where 
we are going. Step back a moment and look at the original definitions we worked 
with. By comparison to the list of markers that we have now accumulated as 
characteristic of FF networks, the original definitions read like politicians' 
10 word sound bites.

What this tells me is that we have learned substantially more about the "thing" 
we labeled fast flux 9-10 months ago.

Can I ask you, Mark, to post a definition v4.3 that includes the item list 
adds/drops/changes so we continue with a fresh look?


On 7/30/08 11:36 AM, "RLVaughn" <RL_Vaughn@xxxxxxxxxx> wrote:



Mike O'Connor wrote:
>
> At 07:45 PM 7/29/2008, RLVaughn wrote:
>
>> Mike O'Connor wrote:
>>> At 02:14 PM 7/29/2008, Joe St Sauver wrote:
>>>> Mike mentioned:
>>>>
>>>> #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.
>>>>
>>>> Yeah, but if you we the stake in the ground just for the sake of doing
>>>> so, and do so wrong, that's not progress.
>>> I think there's a point in any project where you have to say "it's
>>> time to quit tweaking and get on to the next phase."  I think we're
>>> close to having a working definition that will let us get on to other
>>> things, so I'm trying to push us just a little bit.  If we're really
>>> stuck, we can always declare "no consensus" on a given point, but I'm
>>> hoping we can hit a tipping point here...
>>>
>>>> #routing was discussed in previous email, and i find the "discard it"
>>>> #arguments more compelling.
>>>>
>>>> But is there consensus on that point, or is that a unilateral decision
>>>> by the chair?
>>> Unilateral drafting decision by the chair, based on what I read.  I'm
>>> open to new ideas, but let's try to avoid covering the same ground
>>> again.  I lean toward's Dave's opinions because he's got such a long
>>> history with ICANN and understands the boundaries of the organization
>>> so well.
>>
>> routing is important.  Especially in the area of identification of
>> network spread.  Perhaps we need a separate section on methods
>> of identifying such networks?
>
> I'm willing to converse about this more -- but so far here's what I'm
> hearing;
>
> - routing doesn't *distinguish* fast flux networks from other/broader
> attacks.  If it does, forgive me and expand on that -- I'm on the hunt
> for things that we can use to answer the question "what proportion of
> all harm can be laid at the door of Fast Flux?" and exclude things that
> explode our scope.
>
> - routing is outside the scope of ICANN's domain.  Again, help is
> greatly appreciated.  Dave?  I was looking for your post on this and
> have lost it, and I'm reluctant to restate your points from memory.
>
>
>
>>>> #"intent" has been discussed in previous email AND two phone
>>>> #conversations, and i find the "discard it" arguments more compelling.
>>>>
>>>> I would note that due to circumstances beyond my control, namely being
>>>> on a plane during the second call, I was unable to participate. As a
>>>> matter of procedural fairness, and given the importance of this point,
>>>> I would hope that you would reconsider your decision to call this
>>>> issue decided at this point.
>>> Part of what we're doing here is the political "art of the possible."
>>> There are certain topics which have a rich and varied context in the
>>> 10-year ICANN conversation.  These topics can throw a wrench in the
>>> works.  If we can avoid them, we stand a much higher likelihood of
>>> success in moving the ball forward.  I'm persuaded by the arguments
>>> that favor sidestepping the issue of "intent" if we can.
>>>
>>>> #"change in TTL" correction duly noted -- Dave, you want to comment on
>>>> #that?  is it low TTL, or *changing* TTL, or both?
>>>>
>>>> Changing TTLs simply aren't seen (other than TTL's that are just
>>>> normally decrementing the way TTLs always do in caching resolvers).
>>>>
>>>> But don't just trust me -- ask some of the other researchers I've
>>>> steered your way.
>>
>> concur.
>
> Changed in current draft.
>
>         (rapid) modification of IP addresses (low TTLs) for name servers
> and malicious content hosts
>
>
>>>> I'm not trying to be obstinant, I just don't want to see us issue a
>>>> report that begins with a fundamentally incorrect description of the
>>>> problem.
>>>>
>>>> "Measles: a disease characterized by green spots and grey stripes
>>>> of the skin, ..."
>>> One option is to come back with a report that says "We couldn't
>>> arrive a definition of what fast flux is, so the next phase of the
>>> process is to figure that out."  Again, I'm pushing now because I
>>> think we're pretty close to agreement.
>>> I think it will bring us closer to closure if we;
>>> a) suggest incremental new wording in this, and other, areas (not
>>> wholesale replacement, which loses all the meaning we've built up in
>>> all the conversation to date), and
>>> b) argue the pros and cons of the incremental-change proposal
>>> As I said, my sense is that we're close.  Just a little push to get
>>> us over the top.
>>> m
>>
>>
>>
>> I have a call in to Baylor's department of redundant redundancy to
>> check to see
>> if these two bullet items are in their scope of control: *wink*
>>     * operated on one or more compromised hosts
>>     * operated using software that was installed on hosts
>>       without notice or consent to the system operator/owner
>
> As your representative from the Bureau of Interference and Compliance, I
> appreciate your efforts.  :-)
>
> New version;
>
> "operated on one or more compromised hosts (i.e., using software that
> was installed on hosts without notice or consent to the system
> operator/owner) "
>
>
>> [I agree with the problematic nature of interpreting the term,
>> topology.  How about?]
>>     * "volatile" in the sense that the active nodes of the network change
>>       in order to sustain the network's lifetime, facilitate spread of
>> the
>>       network software components, and to conduct other attacks.
>
> Good one.
>
>
>> [The 'using a variety of techniques' phrase might be better in a separate
>>  bullet, such as:]
>>
>>    * Uses a variety of techniques to provide volatility including:
>>           o (rapid) modification of IP addresses for malicious content
>>             hosts, name servers and other network components via DNS
>>             entries with low TTLs.
>>
>> [I changed 'and' to 'or' in the second sub bullet.  The distinction is
>> meaningful to me.]
>>          o monitoring member nodes to determine/conclude that a node has
>>             been identified or shut down **
>>
>> [added some specifics and one mealy-mouthed term to the following}
>>          o time- or other metric-based changes to network nodes, name
>> server,
>>             proxy targets or other components
>
>
>
> I've pushed all of these up to the web page, and I've also revised the
> scope-restriction portion at the bottom to highlight the exclusion of
> WHOIS and "criminal" stuff.
>
> I need better minds than mine to further engage in the Routing Rumpus
> (hopefully culminating in some proposed language, if any is required.
>

Seems to me your mind is pretty darn good.

> It really helps to have proposed language to work with at this stage.
> Thanks Randy!
>
> m

I managed to mess up the address on this message when I sent
it this past Monday but I am resending a modification of what
I originally sent as it demonstrates my view of the importance
of routing.

As luck has it, I received a spam from new Storm worm campaign on
Monday. Even though Storm is old news, it may be useful as ab example
of how routing can be important when identifying fast flux networks.
Storm uses highly volatile name servers. Thus queries to GTLD servers
provide an network-node census while avoiding direct contact with the
storm net.

For discussion purposes, I made two dig runs using F.GTLD-SERVERS.NET
on 28 July 08.  One dig run was made at 1651 CDT, the other at 1656
CDT.

I scrubbed identifying portions of the domains being used and
washed reported IPs to avoid release of specific identifying
information.

The IPs for the NS records revealed in the dig output consisted
of nine unique IPs and three IPs repeated in both dig output.

A total of nine Autonomous systems were present in the
queries.  These are:

  ASN-SPBNIT OJSC North-West Telecom Autonomous System
  CCH-AS7 - Comcast Cable Communications Holdings, Inc
  CHARTER-NET-HKY-NC - Charter Communications
  KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration
  ROADRUNNER-WEST - Road Runner HoldCo LLC
  Telefonica de Argentina
  Terra Networks Chile S.A.
  VTR BANDA ANCHA S.A.
  WEBPLUS-AS WEBplus Ltd.

This wide dispersion of network nodes into a large number of consumer
grade networks is symptomatic of fast flux nets and is the type of
routing to which I refer.  I have not witnessed CDN spread into
consumer-grade autonomous systems.  Even if routing is not in ICANN's
scope, the presence of routing into consumer-networks seems worthy of
a bullet in our symptom list.

[ Perhaps a sub-bullet to:]
    *uses a variety of techniques to achieve volatility including:
[following]
        o (rapid) modification of IP addresses for malicious ...
        o disperses network nodes across a wide number of consumer
          grade autonomous systems.
[I would, in fact, consider this new bullet as a prerequisite for
fast flux]


For the sake of completeness, here is the washed F.GTLD-SERVERS.NET
dig output:
================
2151 Z:
Reply from 192.35.51.30 : 250 bytes recieved [sic]
Direct non-authoritative answer: recursion desired; recursion not
available; result: succesful. [sic] Contains 1 question entries, 0
answer entries, 6 nameserver records and 6 additional records.

 > Questions:
         Good****mes.com       type: A (host address)  class: IN (Internet)
 > Authoritative name servers:
         Goo****mes.com  172800  NS      ns.****gok6.com
         Goo****mes.com  172800  NS      ns2.****gok6.com
         Goo****mes.com  172800  NS      ns3.****gok6.com
         Goo****mes.com  172800  NS      ns4.****gok6.com
         Goo****mes.com  172800  NS      ns5.****gok6.com
         Goo****mes.com  172800  NS      ns6.****gok6.com
 > Additional information:
         ns.****gok6.com         172800  A       89.1*.*.*
         ns2.****gok6.com        172800  A       190.*.*.*
         ns3.****gok6.com        172800  A       200.*.*.*8
         ns4.****gok6.com        172800  A       194.*.*.*
         ns5.****gok6.com        172800  A       76.*.*.*5
         ns6.****gok6.com        172800  A       76.*.*.*7

================
2156 Z
Reply from 192.35.51.30 : 250 bytes recieved [sic]
Direct non-authoritative answer: recursion desired; recursion not
available; result: succesful. [sic] Contains 1 question entries, 0
answer entries, 6 nameserver records and 6 additional records.

 > Questions:
         Goo****mes.com  type: A (host address)  class: IN (Internet)
 > Authoritative name servers:
         Goo****mes.com  172800  NS      ns.****gok6.com
         Goo****mes.com  172800  NS      ns2.****gok6.com
         Goo****mes.com  172800  NS      ns3.****gok6.com
         Goo****mes.com  172800  NS      ns4.****gok6.com
         Goo****mes.com  172800  NS      ns5.****gok6.com
         Goo****mes.com  172800  NS      ns6.****gok6.com
 > Additional information:
         ns.****gok6.com         172800  A       200.*.*.*9
         ns2.****gok6.com        172800  A       200.*.*.*8
         ns3.****gok6.com        172800  A       76.*.*.*5
         ns4.****gok6.com        172800  A       76.*.*.*7
         ns5.****gok6.com        172800  A       89.2*.*.*
         ns6.****gok6.com        172800  A       97.*.*.*



-
Randy