With my hat off, I like the idea of reorganizing the puzzle oriented content in the draft to after the current section 4-6 content. IMHO, I think this could improve the flow and organization of the document.
Dave > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Saturday, March 05, 2016 8:38 PM > To: Valery Smyslov <[email protected]> > Cc: Yoav Nir <[email protected]>; [email protected]; Paul Wouters > <[email protected]>; Waltermire, David A. (Fed) <[email protected]> > Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 > > Hi Valery, > > Responses inline. > > Thanks! > Tommy > > > On Mar 5, 2016, at 2:00 AM, Valery Smyslov <[email protected]> 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
