Miika Komu wrote:
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)?
These are "implementation details" at this point, and anyway someone
else contribution is just as relevant as mine. A third party appears not
essential.
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).
That may qualify as "someone else contribution" and could be relevant.
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?
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
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
