RE: [gnso-ff-pdp-may08] Fast Flux Definition - V4.1

[Joe St Sauver <joe@xxxxxxxxxxxxxxxxxx>]

Hi Mike,

Sorry that I couldn't make yesterday's call, but I was in the air en route
back from the Internet2 Joint Techs meeting in Lincoln.

Regarding the definition:

# "A volatile compromised host service network, the operators of which 
# are difficult or impossible to contact."

I must admit that if I didn't otherwise know what we were talking about,
I'd have a hard time connecting that definition with the phenomena we're
talking about. That strikes me as a bad thing.

Secondly, from an operational point of view, the addition of the clause
"the operators of which are difficult or impossible to contact" also
troubles me. If that definition is adopted, then an attempt at 
communication with the operators of the fastflux network becomes a
condition precedent which must be satistied before a fastflux host can
be identified as such. I don't think that's a good idea, nor one that's
necessary. And what of a bold fastflux operator who has an email
address that auto-acks emails to a nominal email address, but nothing
beyond that? Does that then exlude those hosts from being fastflux by
definition?

#The "longer version" can be found in the notes from yesterday's call 
#in the Definition of Fastflux part of the Discussion Topics;
#
#  https://st.icann.org/pdp-wg-ff/index.cgi?july_25_call

The longer definition doesn't feel quite gel'd up to me in its current
form. :-;

I will says that with respect to the comment,

    "# Limit the problem to "within the scope of ICANN to address"

    "* Operation of the DNS system
    "* Registration services
    "* Does NOT include; routing, end-point security,"

Routing *is* at least partially within scope, in so far as autonomous
system numbers are involved. 

How is that germane you ask? Well, a growing trend is the reporting of
abuse based upon the ASN of the last hop associated with an IP (in
large part because of (a) the dismal state to which domain whois has 
been allowed to degenerate, and (b) because of a lack of enforcement 
of the NRPM 4.2.2.1.2 requirement that "ISPs must provide reassignment 
information on the entire previously allocated block(s) via SWIP or 
RWHOIS server for /29 or larger blocks.")

Predictably, the bad guys/bad gals have noticed this, and some have
found that having their own ASN gives them insulation and allows 
them to conveniently begin to receive complaints about their own 
misbehaviors, complaints which they can then conveniently ignore. 
At least some supicious ASNs of this sort can be readily identified 
based on things like a lack of acertainable multihoming, nominally 
a basic requirement for obtaining an ASN in the first place per the
NRPM Section 5. (And yes, there are *many* apparently singly-homed 
ASNs out there)

When we run out of two-byte ASNs, and we're all strugling with 
four-byte ASN-related issues, remember those singly homed ASNs, 
folks, and the fact that ICANN "shouldn't pay attention to 
routing" :-;

I would also argue that end point security is, or should also be,
within scope. Why? Well, again, because it directly impacts the 
demand for number resources, namely IP addresses. 

Because reputation accumulates on an IP-by-IP basis, and botted or
compromised misbehaving hosts get blocklisted on an IP-by-IP basis, 
traffic which might otherwise be comingled behind a single IP 
instead ends up spread out over multiple IPs.

Likewise, we've repeatedly seen "snowshoe spammers" hop from one 
block to another, leaving behind a wasteland of impaired IP address 
space from which email (if not light itself) may have a hard time 
leaving. And given the difficulty of "reclaiming" widely blocklisted
space once it has been abused, what do folks do? Why, they then 
request an additional "clean" allocation/assignment, of course. 

<SARCASM>But hey, no problem, we've got an infinite supply of IPv4 
addresses for spammers to squander for us, right?</SARCASM> :-;

Looking at the call notes, a few additional comments/questions...

Under "Roll Call" can the list of those who were on the call be included 
as part of the minutes? (or of those, like me, who weren't on?) Knowing
that information can help with the interpretation of the remainder of 
the items reported.

Under "Data Needs," can you identify the feeds that have been received
so far? Doing so would help me to identify potential data sources that
haven't yet stepped up with data, and then additional outreach can take
place to them.

Under highlights of early data, "fishing" should presumably be rendered 
"phishing"

Under "Legitimate Users" there's an empty bullet -- was there supposed
to be something there from the call that accidentally got omitted or
are we still seaching for an example to list?

Under "Action Items" "Team Camry" should probably be "Team Cymru"

Anything happen under "Other Business?"

Regards,

Joe

Disclaimer: all opinions strictly my own.