Hi Tero,
> 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.
Good point.
> 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...
The latest text I proposed in reply to Paul's comments incorporates this
strategy:
o if the Responder chooses to send Cookie request (possibly along
with Puzzle request), then the TCP connection that the IKE_SA_INIT
request message was received over SHOULD be closed after the Responder
sends its reply
and no repeated requests are received within some short period of time,
so that the
Responder remains stateless. Note that if this TCP connection is
closed, the Responder MUST NOT include the Initiator's TCP port
into the Cookie calculation (*), since the Cookie will be returned
over a new TCP connection with a different port.
The text doesn't specify what "some short period of time" is.
I don't think we should do it (it may be 10 sec as you suggested
or 5 sec or 20 sec).
Is it OK? Or should we probably change SHOULD to MAY here?
Regards,
Valery.
> --
> kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
