Paul Wouters writes: > > 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?
I think it is good thing to have puzzles in there, even if we do not enable them now. > > 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. I think it is good idea to have the puzzles already defined, so if this really comes a problem and puzzles are needed, we already have solution for that in the specification, we simply need to roll on the new implementations :-) I would hope server side gatways would implement those, but most likely they would only be enabled when someone is really under big attack. Also modern mobile phones do have more power than home area switches, adsl routers, coffee pots and other internet of target devices. Those very low end devices have so little cpu power that people do not even care if they are protected or not, and generating huge botnets of them might be way to make DDoS attacks. Also even the desktop and laptops do not have that much more raw cpu power than modern mobile phones. Yes, doing puzzles do consume also energy on phones, but you simply need to do it once, and then you are through. Botnets need to use cpu power all the time to beat you. I.e. phone should be willing to use few seconds of full cpu power to create the VPN tunnel and then keep it up and running for the whole day. > >> 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. IKI_SA_INIT response and IKE_SA_INIT request are almost the same size, I do not think there is need for padding. The SAr1 will always be subset of SAi1, i.e., it is either same size or smaller. The KEr is same size as KEr. Nr can be selected so that it is same size as Ni, so there is no difference. Only thing that is in the response which is not in the request is the CERTREQ if you are using certificate based authentication, and that is few tens of bytes (unless you have large number of CAs). On the other hand request also usually have different notifications indicating features etc, and in most cases those notifications are only included in response only if they were also in the request. You do might want to limit of sending lots of different vendor IDs in the server, as those might make the packet bigger... IKEv1 is much different in this case, as if client sends one packet to server, the server will then reply back and will most likely retransmit its response back until it gets next packet from client, or until request times out, thus in IKEv1 it is easy to get amplification factor of ten (if servers retry limit is for example 10). -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
