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