Valery Smyslov writes: > The responder does use an existing TCP connection to reply, but once > it replies with cookie request, it should close this connection. If > it keeps this connection, then it keeps TCP state until the client > resends IKE_SA_INIT request (if ever) and thus thwarts the idea of > being stateless. > > This is probably not so important for cookies, because the client > has already proved during TCP handshake, that its IP is a real IP > address, but it is more important in case of puzzles. But in both > cases I think that keeping responder stateless is a good idea.
I think it is important not to close the TCP immediately after the sending out cookie request, as proper initiator will most likely respond it in one round trip, thus forcing initiator to restart TCP handshake wastes lots of resources. On the other hand it might be useful for puzzles, depending on the expected solving time. Note, that when the responder closes the TCP connection the connection goes to the TCP TIME_WAIT state, where it will still waste resources for a minute or so, thus closing TCP session will NOT free resources immediately, thus closing TCP session too quickly will waste much more resources than keeping it open for 10 seconds or so. If responder keeps the TCP session open for 10 seconds, and initiator comes back during that time with cookie or solved puzzle it can save 6 packets between the peers, and one set of buffers used for TCP send/receive windows. If initiator does not come back after 10 second wait, then it only extends the resource use from 60 seconds to 70 seconds or so... -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
