Re: Mitigating DDoS via Proof of Patience

On 06/28/2015 04:27 AM, james anderson wrote:
> good morning;

Good morning :)

>> This document details a new authentication scheme for HTTP that may
>> be used to request and transmit proofs in HTTP headers.
> 
> there are two possible consequential distinctions between this and a
> 503 with a retry time
> 
> - the challenge/retry exchange carries state and could relieve the 
> server of administering it.

Correct, our goal was to try and mitigate DDoS attacks /against the
database/ by making the client carry the state (as an encrypted blob
that only the server can decrypt). Doing that makes the approach have
nice anti-tampering and scalability characteristics.

In our implementation of the Proof of Patience algorithm, the server
only need to track the total number of requests and the number of
requests per IP (just a bunch of integers, which is what TCP-based DDoS
mitigation systems already do). The other information such as the
requesting IP, resource being throttled, and time window where the proof
is usable, is carried in the encrypted token given to the client.

https://github.com/digitalbazaar/authorization.io/blob/master/lib/proofs.js#L76

For an example of what this looks like when attached to an HTTP resource:

https://github.com/digitalbazaar/authorization.io/blob/master/lib/dids.js#L77

> - the protocol could entail a service guarantee. that is, it may be, 
> that a server must not respond to  legitimate challenge response
> with another 401 challenge. is that the case?

That's implementation specific, but yes, you could do that.

Alternatively, the server could always respond with another 401 if the
system finds itself under a DDoS. For example, the default mode of
operation could be a proof of patience until the server detects that
it's under a DDoS. In that case all incoming requests will need to do a
proof of patience (401 response) with something additional (another 401
response), like a proof of humanity (captcha showing a human emotion of
some kind).

> are there other advantages?

The mechanism was intended to solve a general problem: "How do you
determine legitimate requests for a resource without requiring
pre-registration?".

The advantages, as far as we know are:

1. It's simple to understand and implement.
2. Proof of Patience has nice anti-tampering and scalability
   characteristics.
3. It's extensible, covering things like proof of stake, proof of work,
   proof of humanity, and proof of patience.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Web Payments: The Architect, the Sage, and the Moral Voice
https://manu.sporny.org/2015/payments-collaboration/

Received on Sunday, 28 June 2015 11:50:22 UTC