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

[Thierry Moreau <[e-mail]>]

Hi!

An update ... no clear solution benefit for HIP denial-of-service 
mitigation. The main point being that artificial latency introduced by 
network-bound puzzles may be hard to control given the kind of 
"acceptable" delays for a legitimate HIP connection.

(in case someone wants to investigate further, I advanced these ideas 
for a different problem statement: 
http://www.connotech.com/time_ticket_sub_prot.html title "Internet 
Public Service Abuse Mitigation with a Time Ticket Sub-Protocol")

Regards,

- Thierry

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