Hi Paul, > > This change will require both client and server to be updated to take an > > effect. > > IMHO in this case a better option would be as follows: negotiate an > > extension > > that will change AUTH payload input by zeroing out content of cookie. > > What would this actually achieve? > > We have a server that is under a serious DDoS attack. It is sending back > COOKIES and soon might have too many half open SA's to even accept any > new connections with COOKIES.
I fail to understand why server might have too many half open SA's with the proposed extension. Note, that it remains stateless until the client returns COOKIE, exactly as it happens now. > Those problems are much more severe than > the legitimate client needing to once retry the overloaded server > because the server changed a cookie secret that should be a rare event > to begin with - in our implementation 1 hour. So the client, which can > do 1 exchange attempt per 10 seconds? Would have a 0.277 % change of > hitting that slot and having another 10s delay for the next keying > attempt to succeed. Is the chance of the DDoS attack plus the chance > of the secret reloading worth a new IKE extension at all? The problem is not the delay. The problem is that sometime it caused failed authentication, that definitely must not happen as a result of bad network. If client receives fails due to exchange timeout, it's clear for him/her that this is transient error and an attempt should be retried. If it receives response AUTHENTICATION_FAILED it might suspect that something is wrong with his/her credentials and probably won't retry until figuring this out. Even if this happens rarely, it means that the protocol is flawed. Regards, Valery. > Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
