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

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

wow.  a fella goes and goofs off for a few days 
in Paris and comes back to a rockin' email discussion.
way to go people.

i'm going to peck away on our shared wiki space 
and would like to post some snippets out of this 
conversation to up there (once i've figured out a 
structure).   i'm presuming that (since this 
conversation is taking place on our public list) 
folks wouldn't mind if i steal some of your words 
-- but let me know if you'd rather that i 
didn't.   i probably won't get to this wholesale 
plagiarism until tomorrow, but i thought i'd give 
you some time to say "leave my stuff out".
great job.  keep at it, i'll catch up with ya.

m

At 07:26 AM 7/2/2008, 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,
>    * Is the new address one that falls within 
> any of the assigned blocks for this 
> organization or its DNS operator? (YES = not an anomaly)
>    * Has this address been used by this 
> organization for name servers in the past? (YES = not an anomaly)
>    * 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).
> >
> >
> >
> >
> >
>
>
>
> No virus found in this incoming message.
> Checked by AVG.
> Version: 8.0.101 / Virus Database: 270.4.3/1529 
> - Release Date: 7/1/2008 7:23 PM