Subject: [Hipsec] Memory-bound puzzles in BEX

From: Tobias Heer <[email-masked]>
Date: Thu, 27 May 2010 14:18:00 +0200

Hi everyone, 

RFC5201 states that memory bound puzzles should be reconsidered for future versions of the document. The exact text is here:

NOTE: The protocol developers explicitly considered whether
a memory bound function should be used for the puzzle
instead of a CPU-bound function.  The decision was not to
use memory-bound functions.  At the time of the decision, the
idea of memory-bound functions was relatively new and their
IPR status were unknown.  Once there is more experience
about memory-bound functions and once their IPR status is
better known, it may be reasonable to reconsider this
decision.

I am asking the list if the time for reconsideration has come. Should we delve deeper into non CPU-bound puzzles for RFC5201-bis or should we keep this note for future revisions.
Is there anyone with a background on memory-bound puzzles interested in having them in RFC5201-bis?

Best regards, 

Tobias

-- 
Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group 
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://ds.cs.rwth-aachen.de/members/heer
blog: http://dtobi.wordpress.com/
card: http://card.ly/dtobi

---

From: Miika Komu <[email-masked]>
Date: Thu, 27 May 2010 18:33:09 +0300

On 27/05/10 15:18, Tobias Heer wrote:

Hi Tobias,

I'd be leaning a bit towards CPU-bound puzzles but perhaps just because 
we've been just using them earlier. Big puzzles of both types can be 
problematic for e.g. sensor devices with limited memory and CPU 
capabilities, so in that sense it's a tie. Perhaps it's actually battery 
life (drained by CPU usage) time that seems to suffer from technological 
advances, so perhaps that could used to promote either of the types.

The current CPU-based puzzles are parallelizable which means that a bot 
net could be used for solving a puzzle in a distributed way. As an 
alternative, we could also switch to serialized puzzles. Anyway, I don't 
think this has big impact - I guess it's ok to distribute the solving in 
the end.

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 27 May 2010 11:45:47 -0400

On 05/27/2010 11:33 AM, Miika Komu wrote:
> I'd be leaning a bit towards CPU-bound puzzles but perhaps just 
> because we've been just using them earlier. Big puzzles of both types 
> can be problematic for e.g. sensor devices with limited memory and CPU 
> capabilities, so in that sense it's a tie. Perhaps it's actually 
> battery life (drained by CPU usage) time that seems to suffer from 
> technological advances, so perhaps that could used to promote either 
> of the types.

Some good points. What is memory bound mean to a 8Gb notebook compared 
to a 64K sensor? How do you design a memory bound puzzle that fits each? 
Or does BEX have one and DEX have another?

Battery drain is a dangerous path to go down. Granted that CPU bound 
SHOULD be harder on a battery than memory bound.

>
> The current CPU-based puzzles are parallelizable which means that a 
> bot net could be used for solving a puzzle in a distributed way.

Does this lead to memory bound puzzles as a way to mitigate botnet 
attacks against a puzzle?

> As an alternative, we could also switch to serialized puzzles.

I am not getting what a serialized puzzle is.

> Anyway, I don't think this has big impact - I guess it's ok to 
> distribute the solving in the end.
>
>> Hi everyone,
>>
>> RFC5201 states that memory bound puzzles should be reconsidered for 
>> future versions of the document. The exact text is here:
>>
>> I am asking the list if the time for reconsideration has come. Should 
>> we delve deeper into non CPU-bound puzzles for RFC5201-bis or should 
>> we keep this note for future revisions.
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec
>

---

From: Miika Komu <[email-masked]>
Date: Fri, 28 May 2010 09:28:53 +0300

On 27/05/10 18:45, Robert Moskowitz wrote:

Hi,

> Or does BEX have one and DEX have another?

I think BEX and DEX should have the same puzzle. Maybe you could 
artificially limit the puzzle difficulty in DEX and recommend a smaller 
size (independently of what puzzle technology will be used).

> I am not getting what a serialized puzzle is.

Brent Waters, Ari Juels, J. Alex Halderman, and Edward W. Felten.
New Client Puzzle Outsourcing Techniques for DoS Resistance. In Pro-
ceedings of the 11th ACM conference on Computer and communications
security CCS ’04, 2004.

R.L. Rivest, A. Shamir, and D. Wagner. Time-lock puzzles and timed-
release crypto. Technical Report MIT/LCS/TR-684, MIT, 1996.

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 28 May 2010 08:21:02 -0400

On 05/28/2010 02:28 AM, Miika Komu wrote:
> artificially limit the puzzle difficulty in DEX and recommend a 
> smaller size (independently of what puzzle technology will be used).

Can't entirely.  DEX does not have a hash primative, nor the HMAC 
function.   Dave McGrew has told me he was looking for a good compress 
function for HIT generation from a small ECC key, but this will not be 
good to use for the puzzle as the underlying hash.  My plan is to build 
the puzzle around CMAC.  I am not sure about how appropriate CMAC is for 
this.  Another option is to use ECC encrypt function:  find a keypair 
that encrypts a value to generate the puzzle.  It would be very short 
keypairs....

> ceedings of the 11th ACM conference on Computer and communications

URL?

> release crypto. Technical Report MIT/LCS/TR-684, MIT, 1996.

Oh, time based.  I THINK I get it.

---

From: "HU Zhangfeng" <[email-masked]>
Date: Sun, 30 May 2010 16:43:38 +0800

hi all,
As you know, 1) the scenario of simultaneous end-host mobility maybe actually exist in real world, while it still has not been specified in HIP.  2) RVS servers in HIP functioning as HAs in MIP play very important roles for the management of mobile nodes. If a RVS server stops working, then all the mobile nodes managed by it should be lost in the network and cannot be re-managed any more before the mobile nodes re-register to a new RVS server.

So I'm considering doing some work on both or either of the two above-mentioned topics, and I'm wondering if some ones have completed some work or got some achievement on both of them. Thank you.

2010-05-30 

Zhangfeng HU, phD candidate of
Broadband Network Research Center,
State Key Laboratory of Networking and Switching Technology, 
Beijing University of Posts and Telecommunications, Beijing, China

Email:[email-masked]
Tel:86+13811892137