Subject: [IPsec] DDoS draft next steps

From: Yaron Sheffer <[email-masked]>
Date: Fri, 14 Aug 2015 14:47:52 +0300

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

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 14 Aug 2015 15:42:24 +0300

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.

> 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.

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 14 Aug 2015 15:52:57 +0300

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. It is assumed that
the difference in RAM size between modern smartphones and desktops
is not as great, as the difference in CPU power.

Probably Erik could explain his idea in more details.

Regards,
Valery.

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 14 Aug 2015 09:45:26 -0400

> The idea is a bit crazy, so it is interesting to know what folks think about

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 images didn't prevent
expected and authorized users from connecting.

Thanks,
Kathleen

>> 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"?
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

-- 

Best regards,
Kathleen

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 14 Aug 2015 17:29:05 +0300

> expected and authorized users from connecting.

To be frank I hate them also as a user in real life.
But any kind of puzzle solution (be it captca or
cryptographic puzzle) would annoy users 
(additional delays, battery power consumption etc.).

Valery.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 14 Aug 2015 11:12:47 -0400

> some other resource, that is available for weak clients to solve puzzles.

Sure, there could also be some interface to OAUTH2.

    > 1. CAPTCHA is usually rather big, so we could run into fragmentation
    > problem in IKE_SA_INIT.

I would think that reference by value is the wrong approach, it should be a
URL.

    > that could be some SOHO devices, like sensors, home appliance,

It seems to me there can not be a one-size-fits all approach.
Focus on a smaller scope of problem.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Paul Wouters <[email-masked]>
Date: Fri, 14 Aug 2015 12:01:30 -0400 (EDT)

On Fri, 14 Aug 2015, Valery Smyslov wrote:

> cryptographic puzzle) would annoy users (additional delays, battery power 
> consumption etc.).

captcha's also assume there is a user to talk to, which might not always
(or even mostly) be the case.

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 14 Aug 2015 19:08:52 +0300

> (or even mostly) be the case.

Yes, I wrote in my original e-mail that this is not appropriate
for "unattended" devices. For those cryptographic puzzles are left.
This is appropriate mostly for smartphones.

---

From: Yoav Nir <[email-masked]>
Date: Fri, 14 Aug 2015 19:36:14 +0300

> On Aug 14, 2015, at 7:08 PM, Valery Smyslov <[email-masked]> wrote:
> 
>>> cryptographic puzzle) would annoy users (additional delays, battery power consumption etc.).

And IoT devices are left out in the cole by both approaches. They can’t do millions of SHA-2 fast enough, and they don’t have a user or a user interface capable of displaying the captcha.

I’m trying to imagine this as a conversation between the user and their phone:

  User: Connect
  Phone: VPN gateway is overloaded. Wait 48 seconds while I solve the puzzle or type in the numbers from this picture
  User: I guess I didn’t really want to read my work email this badly

Yoav