<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [gnso-ff-pdp-may08] Definition V4.2
- To: gnso-ff-pdp-May08@xxxxxxxxx
- Subject: Re: [gnso-ff-pdp-may08] Definition V4.2
- From: RLVaughn <RL_Vaughn@xxxxxxxxxx>
- Date: Wed, 30 Jul 2008 10:36:22 -0500
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
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|