> On 4 Mar 2016, at 7:02 PM, Tommy Pauly <[email protected]> wrote: > > Hello Dave, > > I tend to agree with Paul that I find it unlikely, from an implementor’s > standpoint, that many Initiators will choose to implement the puzzle logic, > especially ones that are running on mobile devices. It is unlikely that the > phones will be able to solve the puzzles quickly enough to beat out botnets, > and it would be hard to justify the battery consumption necessary. That being > said, the document does a very good job of explaining the problem space, and > the other parts of its solution (rate-limiting and suggesting session > resumption) make good sense. Perhaps there can be more focus on how a > responder can best protect itself if indeed the majority of its clients do > not support puzzles? > > One question on section 7.1.2: > > If the received message contains a PUZZLE notification and doesn't > contain a COOKIE notification, then this message is malformed because > it requests to solve the puzzle, but doesn't provide enough > information to do it. In this case the Initiator SHOULD resend > IKE_SA_INIT request. If this situation repeats several times, then > it means that something is wrong and the IKE SA cannot be > established. > > I am concerned that the suggestion for the initiator reacting to malformed > IKE_SA_INIT packets is to send more traffic to the responder. The responder > should not legitimately send a PUZZLE notification without a COOKIE > notification, since this would be invalid. If the initiator sees this, it can > either assume that (a) the responder’s implementation is out of spec, or (b) > some malicious third party is deliberately modifying the unencrypted packet. > In the first case, trying to send the IKE_SA_INIT again would be in vain; in > the second case, we have provided a way for a third party to cause initiators > to send more traffic to the responder, thus providing an attack vector. What > are your thoughts on this?
A proper responder would not send a malformed packet. An attacker could send a malformed response immediately after the initiator sends the request. By the time the initiator gets the real responder’s response, it has lost state. That is why it is always a good idea (not just in this context) for the initiator to ignore malformed responses until the timeout is reached. Yoav _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
