Paul Wouters writes: > If the peer initiates too many exchanges of any kind, > implementations can introduce an artificial delay before > responding to request messages. This delay would decrease the > rate the implementation need to process requests from any > particular peer, making it possible to process requests from the > others. The delay should not be too long to avoid causing the IKE > SA to be deleted on the other end due to timeout. > > I am not sure how useful this advise is. Since people use liveness > timeouts of 1s, a malicious peer can always do 1s of exchanges. So if > you want to introduce delays, they should probably delay only > non-liveness exchanges. And liveness exchanges that are more frequent > that 1s should probably just be dropped or rejected.
If someone is stupid enough to allow anybody to configure liveness timeout of 1 seconds, he gets what he deserves. In normal case having more than 10 exchanges per minute is too much, unless you are using per port SAs or similar special cases. Also having liveness checks more often than 30 seconds should be penalized, especially if implementation is using broken periodic liveness checks. It is fine to have 10 second liveness check timeout for one way traffic, i.e., when the traffic changes to be one-way you ONCE do liveness check after 10 seconds, but then you do NOT do liveness check again until something else happens. It will still take several minutes to notice that the liveness check failed, so there is no point of doing them too often. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
