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

From: Thierry Moreau <[email-masked]>
Date: Tue, 27 Nov 2012 00:03:45 -0500

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,

-- 
- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1

Tel. +1-514-385-5691

---

From: Miika Komu <[email-masked]>
Date: Wed, 28 Nov 2012 17:56:27 +0200

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?

---

From: Thierry Moreau <[email-masked]>
Date: Wed, 28 Nov 2012 12:21:55 -0500

> control plane with e.g. CoAP (since you're talking about URIs)?

These are "implementation details" at this point, and anyway someone 
else contribution is just as relevant as mine. A third party appears not 
essential.

> any time value for waiting (unless the rendezvous sends NOTIFY).

That may qualify as "someone else contribution" and could be relevant.

> connectivity for the sensors, so this may change in the future. Any 

As I understand it, the DOS protection benefits the responder, but the 
CPU energy cost is allocated to the legitimate initiators 
indiscriminately (hence the sensor end-point concern).

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

Not aware of anything from third party in this respect. I disclosed the 
proposal to the HIP mailing list assuming this would be a public 
disclosure (through the mail archive) and I did not file any patent 
application on this proposal.

Regards,

-- 
- Thierry Moreau