> On Mar 5, 2016, at 5:11 AM, Valery Smyslov <sva...@gmail.com> wrote: > >> If there is no consensus about puzzles, perhaps we should leave that >> part out of the document? > > I had an impression that threre was a consensus when > the document was adopted by WG. In any case, I think that it is better to > have an interoperable specification than to leave puzzles at all (and thus > make them a subject > for a proprietary solutions).
I agree that interoperability is key, and having a definition is useful if anyone will be implementing it. > >>> And note, that the way puzzles are used in the draft makes every >>> attempt to not discriminate those initiators that don't support puzzles >>> or cannot afford enough power to solve them. In other words - >>> puzzles mechanism in the draft is not an absolute barrier for >>> unsupported clients, it is just a first-class ticket for those who support >>> and afford. >> >> which is the botnet more than mobile phones. Which is why I don't see I >> would implement this. It seems session resumption would be more >> effective at distinguishing returning clients from a botnet. > > Sure. But before every client becomes a "returning" one it must pass usual > IKE_SA_INIT. And it cannot be a returning client the rest of its > life - it must be fully reauthenticated from time to time. > Thus the resumption cannot make the task of DDoS protection in IKE_SA_INIT > non-existent. Going along with Paul’s point, it does seem that the approach of session resumption would favor the legitimate mobile-device client, where the puzzle approach may unintentionally favor the botnets themselves. But it is also a good point that session resumption alone cannot solve the DDoS problem. Would it be possible, I wonder, to try to combine these approaches to create a solution that has the responder-protecting properties of puzzles, while still favoring legitimate clients? This would require using some property of legitimate clients (who will be able to successfully authenticate later in the negotiation) as part of the puzzle-challenge, or a way to skew the results in their favor. I’m not sure if this is possible from the algorithmic perspective, but it would be interesting to use some pre-known value (a shared secret, an initiator or responder ID, etc) as a key to the puzzle that, if known, would allow a quicker solution. It should be impossible to tell what this original key or salt is from an eavesdropper’s perspective, but it could make the calculation quicker for a client with a weak processor that was correctly provisioned to communicate with the server. Thanks, Tommy > >>> Could you, please, elaborate what scenario do you have in mind? >> >> If you have an IPsec server willing to talk IKE/IPsec to anonymous >> clients. So one-side AUTH_NULL, the other a real authentication. Since >> the server talks to everyone who sends it an IKE_INIT, > > How it is concerned with AUTH_NULL? In IKE_SA_INIT the responder > doesn't yet know that the initiator will use NULL auth or real auth, so any > server usually replies to everyone who sends IKE_SA_INIT request. > >> it is important >> that this IKE_INIT reply is much smaller than the IKE_INIT request, >> so this does not become a new amplification target. > > IKE_SA_INIT reply in most cases is smaller than request. > The responder returns only a subset of initiator's SA transforms, a subset of > initiator's notifications (returning only supported ones), > and usually only a subset of VIDs. > In which real life scenario it is larger than request? > >> Currently, such >> a server could only always require dcookies to accomplish this, but >> that takes an additional round trip. Some kind of padding in the >> IKE_INIT request could easilly prevent this. > > Sorry, I failed to understand how additional padding would work. > Are you going to reject initiators that don't include this additional padding > (i.e. - all usual IKEv2 clients)? Am I missing something? > > Regards, > Valery. > >> Paul > > _______________________________________________ > 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
