Valery Smyslov writes: > > With a typical setup and typical Child SA lifetimes, there > > are typically no more than a few such exchanges, often less. > > > > I don't agree. People put in 1s liveness probes, so that's a lot of IKE > > packets. > > Liveness check is about 50 bytes. Even if it is performed every > second, it results in 2 packet/sec and 100 bytes/sec traffic per a > client. Is it a lot?
When you pay for all your mobile traffic for 0.62 eur/MB (my roaming charges in Hong Kong) that will 8 eur/day. And I am sure there are better use for the bandwidth than sending liveness checks. > If we respond in 3 seconds, then it will have to wait 3 seconds, > before it can initiate a new exchange (probably sending > retransmissions during that time that we will ignore). That's an > idea. If malicious peer is so impatient, that it'll tear down the > IKE SA if no response is received within 3 seconds, then it'll make > worse for itself - it'll need to create a new IKE SA from scratch > passing all the puzzles barriers. And RFC7296 do suggest that you try for several minutes before you time out: The number of retries and length of timeouts are not covered in this specification because they do not affect interoperability. It is suggested that messages be retransmitted at least a dozen times over a period of at least several minutes before giving up on an SA, but different environments may require different rules. To be a good network citizen, retransmission times MUST increase exponentially to avoid flooding the network and making an existing congestion situation worse. > > Note, that if the Responder > > receives retransmissions of the request message during the delay > > period, the retransmitted messages should be silently discarded. > > > > That also updated RFC-7296 which states that each IKE request should get > > an IKE answer. > > I don't think artificaial delay is a violation of RFC 7296. Each IKE > request will be answered. RFC 7296 doesn't require that it is > answered immediately (or as soon as responder can prepare the > response). That is true. Having delay before responding to the request is completely legal and is perfect way to make sure nobody uses stupid settings like 1 second liveness delay. If you detect such setting it might be good idea to put 60 second delay for liveness check that come more often than once per minute... -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
