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? Thanks, Tommy > On Mar 4, 2016, at 7:29 AM, Paul Wouters <[email protected]> wrote: > >> On Tue, Mar 1, 2016 at 9:03 PM, Waltermire, David A. (Fed) >> <[email protected]> wrote: >> All: >> >> With the draft-ietf-ipsecme-ddos-protection-04 freshly minted, I >> believe the draft is shaping up nicely, >> but needs additional review. To that end, this message starts a Working >> Group Last Call (WGLC) for >> draft-ietf-ipsecme-ddos-protection-04. >> >> The version to be reviewed is >> https://tools.ietf.org/id/draft-ietf-ipsecme-ddos-protection-04.txt. >> >> Please send your comments, questions, and edit proposals to the WG mail >> list until March 18, 2015. If you >> believe that the document is ready to be submitted to the IESG for >> consideration as a Standards Track RFC >> please send a short message stating this. > > I think the document is well written with respect to DDOS. I like > everything except the puzzles. It seems a lot of complexity for > no gain, especially with the problem being that botnets are better > at puzzle solving then mobile phones who want to not drain their > batteries. I would prefer this document to proceed without the > puzzles, but I won't object to it if it remains in the document. > As an implementor, it would be extremely unlikely that I would > implement puzzles. > > Recently, I also thought about amplification attacks, which is not > covered by the document. For instance, legitimate clients could pad > their IKE_INIT Request as a way to tell the responder they are not just > using the responder to amplify a DDOS attack. I am thinking of making > that the default for some Opportunistic IPsec so it cannot be abused for > amplification. I'd like to see that added to the draft if possible. Or > if this document would not proceed, I would be tempted to write a draft > for this idea. > > Paul > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
