Hi Yoav,

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>:
> Hi.
> 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 
> response.
>> 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 
> everything.
>> 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 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
>> puzzle.“
>>      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
>> notification…“)
> 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:
> https://mailarchive.ietf.org/arch/msg/ipsec/v7PFBEWeaT6ZQCjzCmIaxbRnZ8A
> Yoav

IPsec mailing list

Reply via email to