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).
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.
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
