Hi Yoav, okay. I guess some of the reasoning you gave could go into the draft…
Thanks! Mirja > 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: > >> ---------------------------------------------------------------------- >> 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
