On Sat, 5 Mar 2016, Valery Smyslov wrote:
I agree that puzzles is a controversal thing. However currently we have no
better idea how at least to try to defend against powerful botnets. If you
can come up with such an idea, you are very welcome.
If there is no consensus about puzzles, perhaps we should leave that
part out of the document?
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.
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.
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, 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. 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.
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
