Hi Yoav,
did you consider the following initial exchange:
Initiator Responder
-------------------------------------------------------------------
HDR(A,0), SAi1, KEi, Ni -->
<-- HDR(A,0), N(COOKIE), N(PUZZLE)
(supported initiator)
HDR(A,0), N(SOLVED_PUZZLE), SAi1,
KEi, Ni -->
-- or --
(unsupported or unwilling initiator)
HDR(A,0), N(COOKIE), SAi1,
KEi, Ni -->
The idea is that responder sends both the COOKIE and the PUZZLE
notifications (of course, the cookie for PUZZLE must be generated
differently from the cookie for COOKIE, probably using different secret
or different algorithm).
In this case if the initiator doesn't support puzzles, it would
ignore the PUZZLE notification as unknown status notification
and return the COOKIE. On the other hand, if initiator supports
puzzles, then it have a choice - whether to return COOKIE
and have lower chance to establish SA or make some work
and return SOLVED_PUZZLE (that is identical to COOKIE
apart from the type of notification) and have a better chance.
The responder in this case would give more priority to
the SOLVED_PUZZLE requests and leave the remaining resources
to the COOKIE and initial IKE_SA_INIT requests.
I think this approach would:
1) increase interoperability
2) give more flexibility to initiator depending on
the CPU resources it has
3) allows responder to separate solved puzzles
from COOKIEs and to give them more priority
Regards,
Valery Smyslov.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
