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

["Waltermire, David A. (Fed)" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]]
> Sent: Saturday, March 05, 2016 8:38 PM
> To: Valery Smyslov <[e-mail]>
> Cc: Yoav Nir <[e-mail]>; [e-mail]; Paul Wouters
> <[e-mail]>; Waltermire, David A. (Fed) <[e-mail]>
> 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 <[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ipsec