Hi. See responses below
> On 23 Sep 2016, at 10:11 PM, Mirja Kuehlewind <i...@kuehlewind.net> wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 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 7.2.1.1 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 IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
