RE: [gnso-ff-pdp-may08] Jump start on answering GNSO questions regarding fast flux

["Mike Rodenbaugh" <icann@xxxxxxxxxxxxxx>]

Thanks Eric.

I agree in particular with a couple of your conclusions and hope we can
explore them, but I think we should do that on the confidential list:

1.  The idea of pre-registering flux, of making private incoherency
conditional, goes towards a policy end worth discussion.

2.  We should inform each other, and the eventual consumers of the PDP (GNSO
and BoD) of what work-arounds appear likely for any fix considered, e.g.,
rate limit -> dispersal, and what each fix considered won't accomplish
globally, even if it has potential locally.

Thanks,
Mike Rodenbaugh

Ps:  I represent the Business Constituency ("BC") on the GNSO Council and in
this Working Group.  Berryhill is not capable of describing a BC view on
this point (but I think that quote actually was not Berryhill's anyway).
The BC has not expressed any views specific to fast flux DNS exploits, other
than to request this PDP to discuss the questions before us.

-----Original Message-----
From: owner-gnso-ff-pdp-may08@xxxxxxxxx
[mailto:owner-gnso-ff-pdp-may08@xxxxxxxxx] On Behalf Of Eric
Brunner-Williams
Sent: Wednesday, July 02, 2008 10:13 AM
To: Dave Piscitello
Cc: gnso-ff-pdp-May08@xxxxxxxxx
Subject: Re: [gnso-ff-pdp-may08] Jump start on answering GNSO questions
regarding fast flux


Howdy Dave,

I'm going to start with a quote from John Barryhill, who's an attorney 
who represents a registrar, just to demonstrate that the first 
principles aren't incomprehensible.

Begin quote:
/
/

>         /> the BC wants to turn all of us into
>         > their private law enforcement squad.
>         /

        /That's fine. Empowering registrars to disable domain resolution
        for/
        /businesses and ISPs which do not employ adequate safeguards
        against botnets/
        /seems like a fine idea. /

        /Simply develop a "profile" which detects servers running
        Microsoft software/
        /on a Verizon IP address, using a yahoo.com admin contact, and
        you can pretty/
        /much tell there's a disaster waiting to happen./

        /Or did I misread the SSAC report?/

End quote.

My starting point is there exist subsets of all Windows licenses which 
are persistently, or intermittently, on-line, which are compromised 
assets. The acquisition cost of these compromised assets is very, very 
low, so they present an inexhaustible supply.

The utility of using Flux, and more generalized, Double Flux, is that 
payloads which contained static pointers to any one of these compromised 
assets may instead contain dynamic pointers to any compromised asset 
under the control of the payload author. As a distributed program, an 
attack (payload write, random select, response read) changes from a 
batch job to an interactive one, which can continue as long as the 
attacker's inventory of assets is replenished faster than the defense 
can eliminate each.

So, if we are successful in eliminating flux via DNS, then the authors 
of such programs may spread the load and risk statically within their 
program payload, rather than dynamically, externally to a single point 
of failure. My point being, we can diminish the utility of DNS lookup to 
the run-time execution of programs exploiting Windows, routing, SMTP 
with HTML, and other common APIs, but phishing in all its forms will 
continue as long as Windows, routing, SMTP with HTML, etc. exist, 
without critical dependency upon DNS.

A goal could be simply that. A non-goal is protecting assets neither 
Microsoft nor many ISPs have sufficient motivation to protect, from 
disconnect or criminal prosecution, your #1 and #2 of yesterday's note 
(users and businesses who's computers are compromised assets), as that 
risk is entirely within the exclusive control of the compromised asset 
manager, who exploits compromised assets until the compromised asset is 
"busy, hung or dead", for any scheme she or he pursues for economic, or 
non-economic goals.


And as you observe, increasing the number of compromised assets 
allocated to being attack program infrastructure, as nameservers, or 
simply increasing the number of domains, are obvious responses to 
rate-limiting.

Its been two or three years ago that I suggested to some registrars that 
within our limited mutual trust (we do compete after all), we could 
reduce the time to live of many named attack assets, but it is worth 
thinking hard about the long-term utility of taking "ICANN" out of the 
blame loop, leaving shared fate to cause users, vendors and government 
to pay the consequences of Microsoft's market monopoly and protection 
model (none) architecture, and leaving cost avoidance to cause users, 
other providers and government to pay for the marginality of ISP "help 
desks" and other first responders.

I want to think out loud about inconsistency. Some actors are creating 
temporal inconsistency (load balancing, redirection, etc, for good and 
bad), others are creating spatial inconsistency (last hop nx rewrite, 
which my VSAT provider generously extends to any lookup not cached which 
is a PITA, unless I grow accustomed to the DNS existing so I can see the 
same Google/Yahoo ad populated landing pages), so while we started with 
a distributed database with unique lookup within temporal and spatial 
guarantees, we're tending towards no temporal or spatial guarantees as 
economic actors exploit the protocol. The idea of pre-registering flux, 
of making private incoherency conditional, goes towards a policy end 
worth discussion.

Assuming we are ICANN, a private-public, bottom-up, multi-stakeholder, 
policy mumble, responsible for the technical coordination of some public 
resources, in particular, the DNS, is criminal fast flux the problem or 
is treating the DNS like a private resource the problem?

I think it is fair to inform each other, and the eventual consumers of 
the PDP (GNSO and BoD) of what work-arounds appear likely for any fix 
considered, e.g., rate limit -> dispersal, and what each fix considered 
won't accomplish globally, even if it has potential locally.

Eric


Dave Piscitello wrote:
> Eric, good morning!
>
> I think there are too many legacy assignment situations in the IPv4 
> assignments to make a general case. I have not done interdomain 
> routing for some time, but my best recollection and what I see when I 
> study traffic origins tells me there are at least these ?outlying? 
> cases to consider. By legacy assignment I mean allocations that were 
> not done on a provider-assigned basis and were not returned to RIRs in 
> exchange for provider assigned space
>
>     * an organization has legacy addressing that is a contiguous
>       space, assigned prior to the establishment of RIRs. The orgs
>       that were originally assigned a class A or multiple, contiguous
>       B and C spaces and still use this assignment exclusively are
>       examples.
>     * an organization has legacy addressing that is a non-contiguous
>       space. Orgs that had a B, needed more and were given other Bs
>       and Cs prior to provider block assignments are examples.
>     * an organization that has gone through several mergers and
>       acquisitions may accumulate non-contiguous address assignments.
>       Think about BBN and how many times it?s been re-branded.
>       (Acquiring a small company with a class A assignment can appear
>       to be a much simpler solution for the near term than investing
>       in IPv6)
>     * an organization that has gone through several mergers and
>       acquisitions may accumulate non-contiguous address assignments
>       from various provider assigned spaces. Imagine a corporation
>       that acquires a company where both the parent and acquired
>       companies are assigned blocks by a provider/RIR that are
>       non-contiguous. If the RIRs and providers do not insist that the
>       parent company re-number (or cannot expand the parent?s block so
>       that only the acquired company must re-number) then this org has
>       non-contiguous space.
>     * I know that at least one client I had while consulting worried
>       over the possibility that a divestiture might be handled
>       improperly and the address block assigned to the divested
>       company would transfer to the divested company, creating a
>       ?hole? in their block and leaving them with a non-contiguous
>       space. I do not know of any ?real world? cases.
>
>
> If there are legitimate uses of low TTLs, then monitoring ?low TTL? 
> alone is not sufficient. To distinguish legitimate name server address 
> changes from possible double flux activity in this scenario you might 
> introduce anomaly detection: for example,
>
>    1. Is the new address one that falls within any of the assigned
>       blocks for this organization or its DNS operator? (YES = not an
>       anomaly)
>    2. Has this address been used by this organization for name servers
>       in the past? (YES = not an anomaly)
>    3. Does this new address lie outside the histogram of previous
>       assignments? For example, were the prior addresses all assigned
>       from an organization?s assigned block and the new address is
>       from a block assigned to a broadband access network? (YES = an
>       anomaly!!!)
>
>
> These are only examples and probably don?t represent the exhaustive 
> set of conditions to monitor.
>
> Anomaly detection isn?t trivial to implement. SSAC also suggested 
> pre-screening as methods to reduce double flux activity: for example, 
> imagine a scenario where an organization provides advance notice that 
> it will use short TTLs. If this organization were to also identify the 
> space from which name servers would be assigned addresses, the TTL 
> value it intends to use (if known), etc., this would simplify monitoring.
>
> SSAC also suggested rate limiting. I?m not crazy about this option. It 
> seems like it could be circumvented by the attackers if they simply 
> used many more domains for name servers.
>
> Lots to consider.
>
> We also need to consider whether any policy that focuses on TTL will 
> simply incent the attackers to adopt a different strategy. Think of 
> urban police officers driving the homeless beyond the city limits. The 
> city is managing the homeless by making them the adjacent suburban 
> community?s problem. Now think of TLDs as urban communities and 2nd 
> level labels as suburbia. You spawn a marketplace for subdomain 
> registration (well, we already have). Worse, domains that allow 
> arbitrary parties to create a subdomain under their domain don?t have 
> to make registration information available (thru WHOIS, at least).
>
> Other radical and I imagine highly controversial approaches to 
> consider are granting registrars and registries broader powers with 
> respect to domain suspension (and sharing the accountability for such 
> actions). For example, suppose the community were to reach a point 
> where they were entirely fed up with domain name abuse and were 
> willing to consider Draconian measures. In this scenario, imagine that 
> registries were able to say, ?80% of the domains sponsored by 
> registrar A have been demonstrated to be associated with phishing and 
> malicious activities. Our registry can no longer trust this registrar. 
> We are therefore suspending our relationship with registrar A. 
> Registrar A can no longer create new registrations in our TLD. We are 
> modifying the sponsoring registrar in all existing registrations 
> sponsored by registrar A to an escrow agent. Registrants may transfer 
> their domains through the escrow agent to a registrar of choice 
> without charge.?
>
> I?m not an attorney. I don?t know much about contract law so what I 
> suggest is entirely speculative, perhaps naïve, narrowly focused on a 
> process/technical solution. It is also entirely my speculative 
> thinking and does not represent ICANN?s thinking on this subject in 
> any way.
>
>
>
> On 7/1/08 11:55 PM, "Eric Brunner-Williams" <ebw@xxxxxxxxxxxxxxxxxxxx> 
> wrote:
>
>     Dave,
>
>     Would it be fair to say that data exists which supports the general
>     characterization of addresses to which domains momentarily resolve to,
>     perhaps many times, and perhaps for more than one domain, are
>     dynamically assigned, from provider assigned blocks?
>
>     Eric
>
>     Dave Piscitello wrote:
>     > I believe one of the questions the GNSO has asked this group to
>     answer is:
>     >
>     >
>     > Who benefits from fast flux, and who is harmed?
>     >
>     > I would like to suggest that this question is slightly misleading
>     and would
>     > suggest that we break it down into "Who benefits from the use of
>     short
>     > TTLs?" and "Who is harmed by fast flux activities?"
>     >
>     > I will defer to folks who are exposed to legitimate uses of short
>     TTLs and
>     > offer the following answers to "Who is harmed by fast flux
>     activities?"
>     >
>     > 1. Individuals whose computers are infected by attackers and
>     subsequently
>     > used to host name servers or web sites for a fast flux phishing
>     attack. The
>     > individual may have his Internet connection blocked. In the
>     extreme, should
>     > the computer be suspected of hosting illegal material, the
>     computer may be
>     > seized by law enforcement agents (LEAs) and the individual may be
>     subjected
>     > to a criminal investigation.
>     >
>     > 2. Businesses and organizations whose computers are infected may
have
>     > Internet connections blocked, which may result in loss of
>     connectivity for
>     > all users as well as the possible loss of connectivity for any
>     Internet
>     > services also hosted via the blocked connection (e.g., mail, web,
>     e-merchant
>     > or ecommerce sites). Again, in the extreme, should the computer
>     be suspected
>     > to host illegal material, the computer may be seized by LEAs and the
>     > individual may be subjected to a criminal investigation. If this
>     computer
>     > were hosting web and other services for the
>     business/organization, the
>     > seizure could also result in an interruption of service, loss of
>     income or
>     > "web presence".
>     >
>     > 3. Individuals who receive phishing emails and are lured to a
>     phishing site
>     > hosted on a bot used by the miscreants/criminals who run the
>     phishing attack
>     > may have their identities stolen or suffer financial loss from
>     credit card,
>     > securities or bank fraud. They may unwittingly disclose medical
>     or personal
>     > information that could be used for blackmail or coersion. They
>     may infect
>     > their computers with malicious software that would "enlist" their
>     computers
>     > into a bot herd. Individuals who purchase bogus products, especially
>     > pharmaceuticals, may be physically harmed from using such products.
>     >
>     > 4. Internet access operators are harmed when their IP address
>     blocks are
>     > associated with bot nets and phishing attacks that are linked to
>     fast flux
>     > activities. These operators also bear the burden of switching the
>     > unauthorized traffic that phishing attacks generate and they may
>     also incur
>     > the cost of diverting staff and resources to respond to abuse
>     reports or
>     > legal inquiries.
>     >
>     > 5. Registrars are harmed when their registration and DNS hosting
>     services
>     > are used to abet "double flux" attacks. Like Internet access
>     providers, they
>     > may also incur the cost of diverting staff and resources to
>     monitor abuse,
>     > or to respond to abuse reports or legal inquiries.
>     >
>     > 6. Businesses and organizations who are "phished" from bogus web
>     sites
>     > hosted on fast fluxing networks may experience financial or
>     material loss,
>     > tarnish to brand, or loss of customer/consumer confidence. They
>     also incur
>     > the cost associated with brand abuse monitoring, detection and
>     mitigation.
>     >
>     > 7. Registries may incur the cost of diverting staff and resources
>     to monitor
>     > abuse or to respond to abuse reports or legal inquiries.
>     >
>     > These are my top 7. I can think of other parties who are affected
>     indirectly
>     > through phishing (consumers, in the form of fees and higher
>     interest rates
>     > financials use to compensate from losses resulting from identity
>     theft and
>     > credit card fraud).
>     >
>     >
>     >
>     >
>     >
>
>