Hi Valery, Responses inline.
Thanks! Tommy > On Mar 5, 2016, at 2:00 AM, Valery Smyslov <sva...@gmail.com> wrote: > > Hi Tommy, > > thank you for your comments. > >>>> 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? > > Sections 4 - 6 describe measures other than puzzles that the responder can > use to defend itself against DDoS attack. > Do you think it is not enough? Puzzles are a new thing, that's why more text > is needed to explain how they are fit > into the protocol. However the draft is not solely about puzzles, and I think > it covers other defending techniques in sufficient details. Perhaps it would be useful to rearrange the sections to highlight this more clearly. The first section about a solution is Puzzles (section 3), followed by sections 4-6 which cover other aspects of DDoS avoidance strategies, which is then followed by an in-depth explanation of the Puzzles in the protocol (sections 7-9). Since the other aspects and sandwiched in between sections purely focused on puzzles, the draft really feels like it is about puzzles. What if the other approaches were moved before the first puzzles section, so the entire section on puzzles can be contiguous? > >>>> 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. > > You are right that the Initiator should wait for the retransission timer to > expire before resending message. > I agree that the wording is ambiguous about that. How about the following? > > 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 MUST ignore > the received message and continue to wait until either the valid one > is received or the retransmission timer fires. If it fails to receive the > valid > message after several retransmissions of IKE_SA_INIT request, then > it means that something is wrong and the IKE SA cannot be established. I think that is more clear, thanks! > > Regards, > Valery. > >> Thanks, >> Tommy > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
