Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04

[Tommy Pauly <[e-mail]>]

> On Mar 4, 2016, at 9:32 AM, Yoav Nir <[e-mail]> wrote:
> 
>> 
>> On 4 Mar 2016, at 7:02 PM, Tommy Pauly <[e-mail]> 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.

That makes sense. The wording, however, could imply that the Initiator should resend the request as if in response to the malformed packet. Based on your comment, the Initiator should wait for the usual amount of time before retrying, rather than immediately retrying the packet. It may be useful to clarify this in the text.

Thanks,
Tommy

> 
> Yoav