okay. I guess some of the reasoning you gave could go into the draft…
> Am 23.09.2016 um 22:06 schrieb Yoav Nir <ynir.i...@gmail.com>:
> See responses below
>> On 23 Sep 2016, at 10:11 PM, Mirja Kuehlewind <i...@kuehlewind.net> wrote:
>> Some questions:
>> 1) sec 7.1.2: If there is a puzzle but no cookie, maybe the initiator
>> should ignore it and try to send reply without the puzzle solution, as
>> there might be still a change to get served…? If it then received another
>> packet with puzzle it can still solve it and reply.
> A response that contains neither COOKIE nor INVALID_KE_PAYLOAD nor the
> regular payloads like SA is invalid according to RFC 7296. That is one reason
> why we chose to keep the COOKIE notification and add a PUZZLE notification
> rather than put both pieces of data in the new notification. A response with
> only PUZZLE and no COOKIE is invalid and should be treated as such. So after
> some (not specified anywhere) time, the Initiator should start a new
> IKE_SA_INIT exchange, hoping that this time the Responder returns a valid
>> 2) sec 7.1.4: Does „the Responder MUST verify the puzzle solution“? Maybe
>> there are cases where the burden for the initiator is high enough by
>> requesting the solution that there is already an effect even if the
>> responder decides to not verify it…?
> There was a suggestion discussed that the Responder MAY choose not to check
> the solution or randomly check just one of the four solutions. The WG didn’t
> like that as it makes the protocol non-deterministic and makes things harder
> to test. So consensus was to make the verification mandatory. Of course, this
> doesn’t affect interoperability, so we can’t force a responder to check
>> 3) also sec 7.1.4: Does the following sentence really makes sense? How
>> doe the responser know? Maybe just remove it?
>> „The more time the Initiator spent solving the puzzles, the higher
>> priority it should receive.“
> The Responder cannot know. It can only assume based on the expected number of
> steps in finding a solution with a certain number of trailing zero bits.
>> 4) sec 126.96.36.199 says „the Responder would be able to estimate the
>> computational power of the Initiator and select the difficulty level
>> accordingly.“ How would it estimate the computational power? Based on the
>> reply time? Wouldn’t it also need to know the RTT and current congestion
>> level then?
> The only estimate that the responder has is based on what the initiator
> solved during the IKE_SA_INIT exchange. If the Initiator solved a level-15
> puzzle (15 trailing zeros in each of the four solutions) then it stands to
> reason that it *can* solve a level-15 puzzle. Maybe the word “estimate” is
> misleading here.
>> 5) sec 7.2.2 says „If the IKE_SA_INIT response message contains the
>> PUZZLE notification and the Initiator supports puzzles, it MUST solve the
>> Should this be „IKE_SA_AUTH“ here instead of „IKE_SA_INIT“?
>> Otherwise it contradicts sec 7.1.2 („The Initiator MAY ignore the PUZZLE
> Sure. Seems to be a typo.
>> Two general comments/questions:
>> 1) What’s about the additional cpu load of the responder to calculate the
>> puzzle. Can that be a problem? Are there any strategies to keep that low
>> (recalculation/caching/reuse)? How long should things be cached/used?
>> Maybe add a few sentences in the Operational Considerations section!
> Verifying a puzzle solution involves 4 invocation of a MAC function on a few
> tens of bytes. This is very low considering that (1) IKE initiation involves
> at least one and typically two PK operations, and (2) IKE is for generating
> key material which is then used to MAC millions or billions of packets.
>> 2) Would it make sense to also give a field to change the number of
>> requested keys to scale load? Or why was it decided to use a fixed number
>> of 4 here?
> You scale the load by changing the difficulty (number of requested trailing
> zero bits). The reason we are asking for 4 solutions rather than 1 is to
> make the amount of work more predictable. We could make it even more
> predictable with 16 solutions, but that makes the packet bigger and runs the
> risk of requiring packet fragmentation. So we chose 4 as a reasonable
> compromise. See this mail about it:
IPsec mailing list