Dear authors and WG members,
We clearly do not have enough energy/consensus behind the draft to
move it forward in its current form. My personal opinion is that the
draft is an important piece of work and I don't want to see it go to
waste.
We would like to
Valery Smyslov sva...@gmail.com wrote:
We came to the problem that weak clients cannot solve strong puzzles,
so using puzzles for DDoS protection makes legitimate weak clients
uncapable to establish IKE SA. Then I thought that probably we can use
some other resource, that is
On Aug 14, 2015, at 7:08 PM, Valery Smyslov sva...@gmail.com wrote:
With no hat on, I hate captchas. I sometimes don't see it well enough
depending on the images selected and have not used applications as a
result. It is a clever way to tackle the problem, so it would be up
to the
On Fri, 14 Aug 2015, Valery Smyslov wrote:
With no hat on, I hate captchas. I sometimes don't see it well enough
depending on the images selected and have not used applications as a
result. It is a clever way to tackle the problem, so it would be up
to the deployer to make sure their captcha
Hi Yaron,
that was my idea to use CAPTCHA as a puzzle. My thoughts were the following.
We came to the problem that weak clients cannot solve strong puzzles,
so using puzzles for DDoS protection makes legitimate weak clients
uncapable to establish IKE SA. Then I thought that probably we can use
Hi again,
the idea of memory-intensive puzzle is present in Erik Nygren's draft
TLS Client Puzzles Extension
(http://www.ietf.org/id/draft-nygren-tls-client-puzzles-00.txt).
The idea is to create puzzle in such a way, that the time to solve it
depends rather on available RAM, than on CPU power.