I think doing this would cause clients to calculate the puzzle solution,
when in fact they don’t have to, and sending back the COOKIE would be
enough.
What I envision is for the IKE gateway to measure its load (probably based
on amount of half-open IKE SAs). As long as the load level is low, the
gateway
sends neither COOKIE nor PUZZLE. If the load gets higher, the gateway
begins sending COOKIEs, and every implementation of RFC 5996 works.
If the load gets even higher (to the extent that it jeopardizes the
gateway’s
ability to provide its services), then it sends PUZZLEs instead of
COOKIEs,
and initiators that don’t support this specification are left out.
I understand the idea. I only suggest a small modification,
that would make the overall process more flexible and interoperable.
The modification is: instead of sending only PUZZLE in case of high load,
the SG would send both COOKIE and PUZZLE, calculated with
different secrets. Those initiators, that don't support puzzles, would
ignore it and return COOKIE. The others would have a choice -
whether to spend some CPU power, solve the puzzle and return it
or just ignore puzzle and send COOKIE (as unsupported initiators).
The SG would give more priority to requests containing SOLVED_PUZZLE
than to requests containing COOKIE or initial IKE_SA_INIT.
I can see the following benefits with this modification:
1. Old initiators that don't support puzzles would still have a chance
to establish SA (although their chances will be lower comparing
to initiators, supported puzzles)
2. Every single initiator supported puzzles will have a choice - try to
solve
puzzle or try to continue with COOKIE. This is important,
as SG sets an equal level of difficulty for all initiators,
but, as you have mentioned in the draft, CPU power
may differ drastically between small mobile devices and high-end
desktops.
For the former it is sometimes easier to ignore puzzles
and hope that resending COOKIE would eventually work.
3. SG would be able to separate requests with solved puzzles from
those with just returned cookies and would give the former
higher priority.
I don't see any drawback with this modification, do you?
Regards,
Valery.
Yoav
On Jul 11, 2014, at 9:21 AM, Valery Smyslov <[email protected]> wrote:
> 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
