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

["Mike O'Connor" <mike@xxxxxxxxxx>]

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.
It really helps to have proposed language to work with at this 
stage.  Thanks Randy!
m