Re: [Hipsec] Network-bound puzzles for HIP?

[Miika Komu <[e-mail]>]

Hi Thierry,

how do you register the network puzzle to the URI? Unlike the current 
HIP puzzle, your solution requires a third party? And it couples HIP 
control plane with e.g. CoAP (since you're talking about URIs)?

A decoupled and more standards-compliant solution with a HIP-specific 
third party could to assume a rendezvous or relay server, which drops 
messages until some time period. This "some" could be defined when a 
host registers to rendezvous or relay server or updates its 
registration. The drawback here is that the initiator will not receive 
any time value for waiting (unless the rendezvous sends NOTIFY).

I am not an expert, I believe current wireless sensor networks 
communicate through sink or gateway, so DoS protection is not really 
necessary for the sensors. However, the IoT vision is to have end-to-end 
connectivity for the sensors, so this may change in the future. Any 
thoughts on this?

P.S. Are you aware of any patents related to network puzzles?

On 11/27/2012 07:03 AM, Thierry Moreau wrote:
> Hi,
>
> I find quite interesting the active development of HIPv2 drafts. From an
> applied cryptography perspective, I appreciate this state-of-the-art
> secure protocol development.
>
> Nonetheless, I am very novice in the design of puzzles for DOS attack
> mitigation. But I have this idea of network-bound puzzle so that the
> battery life of sensor devices is preserved.
>
> Very roughly ...
>
> The network-bound puzzle is a pair <URI,time0,time1>
> If time0>=time1 the solution is zero
> Otherwise, the solution is obtained from the "URI server" (using an
> plain UDP query) at a time no earlier than time1 (which the HIP
> initiator may guesstimate as now+(time1-time0)
> (I use absolute times such that the URI server need not be synchronized
> with the responder).
>
> UDP queries to the URI server simply carry some value timeX (discrete
> resolution)
> The URI server simply answers UDP queries with either
> a) solutX (for timeX>=now), else
> b) delayed UDP response solutX (if timeX in near future and the URI
> server is not currently under heavy load), or else
> c) some "REQUEST TOO EARLY" negative response.
>
> In practice, some secret pseudo-random sequence defines the successive
> solutions. I would guess a timeX resolution of 0.1 second would allow
> DOS attacks mitigation in low to medium throughput HIP responder hosts,
> but this is only from intuition.
>
> The HIP responder may need a special arrangement with the URI server to
> learn the responses in advance (or on a priority basis during a DOS
> attack). I guess the two could be the same system (the URI server needs
> not be "trusted").
>
> ... end of rough idea.
>
> Was this ever envisioned? Were the practicalities ever looked at?
>
> Anyway, just my little suggestion.
>
>
> Yes, I did look at
> http://www.ietf.org/mail-archive/web/hipsec/current/msg03122.html
> (Memory-bound puzzles in BEX)
> and the reference by Rivest et al. (which does not address the DOS
> mitigation as it is understood nowadays but has something along the URI
> server idea for "timed-released crypto").
>
> and
> http://www.ietf.org/mail-archive/web/hipsec/current/msg03565.html
> (New Version Notification for draft-hummen-hip-middle-puzzle-00.txt)
>
>
> Regards,
>