Grand Strategy

towards a Denial of Service Resistant Internet

Denial of Service Resistant Internet working group
Communications Research Network / Communications Futures Programme

Goal of the working group: To galvanise co-ordinated actions to make the Internet more resistant to denial of services attacks, without unduly blocking the emergence of innovative new applications of the Internet.

Goal of this document: To lay out the space of possible activity across the technical, economic, contractual and regulatory fields in order to prioritise activity. In particular:

to identify approaches that require less co-ordination between companies, between industries, between disciplines or between jurisdictions
to identify gaps where such co-ordination is unavoidably necessary
to identify approaches that are not worth pursuing.

1. Introduction

It is hard to offer access to an Internet-based service (including the service offered by the network itself), intending it to be openly used, but at the same time being able to protect against its intentional over-use. It is also hard to try to foster innovative new uses of the generic Internet infrastructure but at the same time prevent malicious new uses, given it takes a while to characterise how benign a new use will be. put these two fundamental reasons together, and the above goal is really hard.

2. Technical measures

Various dimensions:

Improved operational practices (not requiring changes to equipment) --- largely refer out to Max's BCP
Improved equipment design (not requiring changes to architecture)
Improved Internet architecture (hopefully, incrementally deployable)

Attacks through infrastructure vs attacks on infrastructure

Mitigating the vectors through which attacks are launched (OS vulnerabilities to viruses/worms, unnecessarily generic communication channels (client-client, server-server), 'certified' software, machines and networks, and re-certification issues with roaming)
Mitigating the force of attacks (traffic filtering/scrubbing, enforcable congestion control (re-feedback))
Mitigating the channels through which DDoS attacks are co-ordinated (IRC etc).

Providing hooks to trace attackers' identities
by path symmetry
by ingress interface: (traceback, re-feedback)
By e2e connection address: (cookies, capabilities)

Payload inspection vs cryptography.
Route anonymisers vs. traffic analysis.

Incremental deployment models

4. Economic & incentive-based measures

Pricing to increase the cost of attacks

Limits of economic approaches: value of attack >> cost?, irrational attackers

Incentivising the clean up of zombie hosts

Using pricing internal to a network to manage engineering mechanisms like throttles and policers, in order to trade off costs and benefits of particular customers.

3. Contractual measures

Types of contract

End customer acceptable use policies (AUPs) & inter-provider contracts
Pairwise (contracts between neighbours including via peering intermediaries) vs. overlay models (contracts between neighbours at a higher layer, eg. edge to edge) vs. star-wise contractual relationships (contracts with an overseeing body)

Deterrent sanctions after the fact vs. rights to prevent attacks

Financial vs service-impairment sanctions vs reputation-impairment sanctions (and legitimising vigilante defence - fighting fire with fire)

Defining attacks by behaviour vs. intent

Liability

Paymasters, attack co-ordinators, attack vectors (zombies, carrier networks, software vulnerabilities (OS, e-mail etc).

Attacker identification

Anonymous access: making the party that allows it responsible for the actions of anonymous users? Radio access issues

Strength levels of identification

6. Regulatory

Regulatory requirements for contractual commitments between operators.

Enforcability across borders
Liability (if network hides user, is user responsible?; if country cannot sanction a party, can country be made responsible???)

What law(s) are available in each jurisdiction? generic legal coverage extensible to new forms of attack?

5. Commercial realities

This section is a placeholder in case commentary is needed on the commercial practicality of any of the above. For instance, how valuable preserving an architecture that fosters innovation is relative to the cost of fostering malice. Or how realistic it is to expect ISPs to disconnect customers or peer networks when they are both a source of value and malice. This discussion may end up being sprinkled throughout the rest of the document.

Retail vs. wholesale/interconnect approaches and virtualisation.

Insurance

6. Conclusions

None yet.

Draft 00a

Bob Briscoe

21 Oct 2005