Markdown formatting and link updates for hspow-spec/motivation

1 files changed, 54 insertions, 75 deletions

diff --git a/spec/hspow-spec/motivation.md b/spec/hspow-spec/motivation.md
index 1c77f58..a79bac7 100644
--- a/spec/hspow-spec/motivation.md
+++ b/spec/hspow-spec/motivation.md
@@ -1,106 +1,85 @@
-```text
+# Motivation
 
-0. Abstract
+See the [denial-of-service overview](../dos-spec/overview.md) for the big-picture view.
+Here we are focusing on a mitigation for attacks on one specific resource: onion service introductions.
 
-  This proposal aims to thwart introduction flooding DoS attacks by introducing
-  a dynamic Proof-Of-Work protocol that occurs over introduction circuits.
+Attackers can generate low-effort floods of introductions which cause the onion service and all involved relays to perform a disproportionate amount of work, leading to a denial-of-service opportunity.
+This proof-of-work scheme intends to make introduction floods unattractive to attackers, reducing the network-wide impact of this activity.
 
-1. Motivation
+Previous to this work, our attempts at limiting the impact of introduction flooding DoS attacks on onion services has been focused on horizontal scaling with Onionbalance, optimizing the CPU usage of Tor and applying rate limiting.
+While these measures move the goalpost forward, a core problem with onion service DoS is that building rendezvous circuits is a costly procedure both for the service and for the network.
 
-  So far our attempts at limiting the impact of introduction flooding DoS
-  attacks on onion services has been focused on horizontal scaling with
-  Onionbalance, optimizing the CPU usage of Tor and applying rate limiting.
-  While these measures move the goalpost forward, a core problem with onion
-  service DoS is that building rendezvous circuits is a costly procedure both
-  for the service and for the network. For more information on the limitations
-  of rate-limiting when defending against DDoS, see [REF_TLS_1].
+For more information on the limitations of rate-limiting when defending against DDoS, see [`draft-nygren-tls-client-puzzles-02`](https://www.ietf.org/archive/id/draft-nygren-tls-client-puzzles-02.txt).
 
-  If we ever hope to have truly reachable global onion services, we need to
-  make it harder for attackers to overload the service with introduction
-  requests. This proposal achieves this by allowing onion services to specify
-  an optional dynamic proof-of-work scheme that its clients need to participate
-  in if they want to get served.
+If we ever hope to have truly reachable global onion services, we need to make it harder for attackers to overload the service with introduction requests.
+This proposal achieves this by allowing onion services to specify an optional dynamic proof-of-work scheme that its clients need to participate in if they want to get served.
 
-  With the right parameters, this proof-of-work scheme acts as a gatekeeper to
-  block amplification attacks by attackers while letting legitimate clients
-  through.
+With the right parameters, this proof-of-work scheme acts as a gatekeeper to block amplification attacks by attackers while letting legitimate clients through.
 
-1.1. Related work
+## Related work {#related-work}
 
-  For a similar concept, see the three internet drafts that have been proposed
-  for defending against TLS-based DDoS attacks using client puzzles [REF_TLS].
+For a similar concept, see the three internet drafts that have been proposed for defending against TLS-based DDoS attacks using client puzzles:
 
-1.2. Threat model [THREAT_MODEL]
+- [`draft-nygren-tls-client-puzzles-02`](https://www.ietf.org/archive/id/draft-nygren-tls-client-puzzles-02.txt)
+- [`draft-nir-tls-puzzles-00`](https://tools.ietf.org/id/draft-nir-tls-puzzles-00.html)
+- [`draft-ietf-ipsecme-ddos-protection-10`](https://tools.ietf.org/html/draft-ietf-ipsecme-ddos-protection-10)
 
-1.2.1. Attacker profiles [ATTACKER_MODEL]
+## Threat model
 
-  This proposal is written to thwart specific attackers. A simple PoW proposal
-  cannot defend against all and every DoS attack on the Internet, but there are
-  adversary models we can defend against.
+### Attacker profiles {#attacker-profiles}
 
-  Let's start with some adversary profiles:
+This mitigation is written to thwart specific attackers. The current protocol is not intended to defend against all and every DoS attack on the Internet, but there are adversary models we can defend against.
 
-  "The script-kiddie"
+Let's start with some adversary profiles:
 
-    The script-kiddie has a single computer and pushes it to its
-    limits. Perhaps it also has a VPS and a pwned server. We are talking about
-    an attacker with total access to 10 GHz of CPU and 10 GB of RAM. We
-    consider the total cost for this attacker to be zero $.
+- "The script-kiddie"
 
-  "The small botnet"
+  The script-kiddie has a single computer and pushes it to its limits.
+  Perhaps it also has a VPS and a pwned server.
+  We are talking about an attacker with total access to 10 GHz of CPU and 10 GB of RAM.
+  We consider the total cost for this attacker to be zero $.
 
-    The small botnet is a bunch of computers lined up to do an introduction
-    flooding attack. Assuming 500 medium-range computers, we are talking about
-    an attacker with total access to 10 THz of CPU and 10 TB of RAM. We
-    consider the upfront cost for this attacker to be about $400.
+- "The small botnet"
 
-  "The large botnet"
+  The small botnet is a bunch of computers lined up to do an introduction flooding attack.
+  Assuming 500 medium-range computers, we are talking about an attacker with total access to 10 THz of CPU and 10 TB of RAM.
+  We consider the upfront cost for this attacker to be about $400.
 
-    The large botnet is a serious operation with many thousands of computers
-    organized to do this attack. Assuming 100k medium-range computers, we are
-    talking about an attacker with total access to 200 THz of CPU and 200 TB of
-    RAM. The upfront cost for this attacker is about $36k.
+- "The large botnet"
 
-  We hope that this proposal can help us defend against the script-kiddie
-  attacker and small botnets. To defend against a large botnet we would need
-  more tools at our disposal (see [FUTURE_DESIGNS]).
+  The large botnet is a serious operation with many thousands of computers organized to do this attack.
+  Assuming 100k medium-range computers, we are talking about an attacker with total access to 200 THz of CPU and 200 TB of RAM.
+  The upfront cost for this attacker is about $36k.
 
-1.2.2. User profiles [USER_MODEL]
+We hope that this proposal can help us defend against the script-kiddie attacker and small botnets.
+To defend against a large botnet we would need more tools at our disposal (see the [discussion on future designs](./analysis-discussion.md#FUTURE_DESIGNS)).
 
-  We have attackers and we have users. Here are a few user profiles:
+### User profiles {#user-profiles}
 
-  "The standard web user"
+We have attackers and we have users. Here are a few user profiles:
 
-    This is a standard laptop/desktop user who is trying to browse the
-    web. They don't know how these defences work and they don't care to
-    configure or tweak them. If the site doesn't load, they are gonna close
-    their browser and be sad at Tor. They run a 2GHz computer with 4GB of RAM.
+- "The standard web user"
 
-  "The motivated user"
+  This is a standard laptop/desktop user who is trying to browse the web.
+  They don't know how these defences work and they don't care to configure or tweak them.
+  If the site doesn't load, they are gonna close their browser and be sad at Tor.
+  They run a 2GHz computer with 4GB of RAM.
 
-    This is a user that really wants to reach their destination. They don't
-    care about the journey; they just want to get there. They know what's going
-    on; they are willing to make their computer do expensive multi-minute PoW
-    computations to get where they want to be.
+- "The motivated user"
 
-  "The mobile user"
+  This is a user that really wants to reach their destination.
+  They don't care about the journey; they just want to get there.
+  They know what's going on; they are willing to make their computer do expensive multi-minute PoW computations to get where they want to be.
 
-    This is a motivated user on a mobile phone. Even tho they want to read the
-    news article, they don't have much leeway on stressing their machine to do
-    more computation.
+- "The mobile user"
 
-  We hope that this proposal will allow the motivated user to always connect
-  where they want to connect to, and also give more chances to the other user
-  groups to reach the destination.
+  This is a motivated user on a mobile phone.
+  Even tho they want to read the news article, they don't have much leeway on stressing their machine to do more computation.
 
-1.2.3. The DoS Catch-22 [CATCH22]
+We hope that this proposal will allow the motivated user to always connect where they want to connect to, and also give more chances to the other user groups to reach the destination.
 
-  This proposal is not perfect and it does not cover all the use cases. Still,
-  we think that by covering some use cases and giving reachability to the
-  people who really need it, we will severely demotivate the attackers from
-  continuing the DoS attacks and hence stop the DoS threat all together.
-  Furthermore, by increasing the cost to launch a DoS attack, a big
-  class of DoS attackers will disappear from the map, since the expected ROI
-  will decrease.
+### The DoS Catch-22 {#catch22}
 
-```
\ No newline at end of file
+This proposal is not perfect and it does not cover all the use cases.
+Still, we think that by covering some use cases and giving reachability to the people who really need it, we will severely demotivate the attackers from continuing the DoS attacks and hence stop the DoS threat all together.
+Furthermore, by increasing the cost to launch a DoS attack, a big class of DoS attackers will disappear from the map, since the expected ROI will decrease.