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,
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
