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
some other resource, that is available for weak clients to solve puzzles.
Many weak clients are smartphones, so they have an owner, a human
who is usually initiating the communication. So, why not ask human to solve
puzzle? Then CAPTCHA was the first that came to my mind.
The idea is that initiator indicates what kind of puzzle it wants to solve -
computational puzzle or CAPTCHA. In the latter case the responder returns
some kind of CAPTCHA, cryptographically linked with cookie, so that
it could later verify in a stateless manner that initiator didn't cheat.
The initiator would present CAPTCHA to user and then return back
the solution along with cookie.
This approach has some potential drawbacks.
1. CAPTCHA is usually rather big, so we could run into fragmentation problem
in IKE_SA_INIT.
2. Th difficulty of CAPTCHA is somewhat unclear, the progress
in OCR technology could make this kind of puzzles too weak
and attackers would indicate their preference to get this kind of puzzles.
3. This solution is sutable for smartphones, however there are
many weak clients that are not smartphones (besides IoT world
that could be some SOHO devices, like sensors, home appliance,
SOHO routers etc.).
The idea is a bit crazy, so it is interesting to know what folks think about it.
Regards,
Valery.
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 see if the working group would be interested in a more focused draft. Some
options:
- Make the draft more attractive by solving the problem of mobile clients (did I hear
"memory-intensive puzzles"?
someone even mentioned Captcha), then try again to get consensus around it.
- Publish only the protocol part of the document, basically Sec. 3 and 8, as an
Experimental RFC.
There are probably other options.
Ideas?
Thanks,
Yaron
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
