> > 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? > > I think it would be best to explain that valid clients usually return > back almost immediately, so responders should keep tcp connection open > for at least 10 seconds to receive the cookie responses, and after > that SHOULD close the connection after some timeout.
I don't think we should advise any concrete values here, following RFC 7296 practice which deliberately avoided specifying concrete timeouts and also because they don't affect interoperability. But I agree that some explanations can be added and we can mention concrete values (say 10 secs) as examples. > And perhaps add some words that depending on the puzzle difficulty > level the timers might be modified (i.e., if you give puzzle that will > require several minutes to solve, there is no point of waiting any > more than the few seconds, but if you expect initiator to solve the > puzzle in 5 seconds, then waiting 20 seconds is good thing). OK, good idea to add some clarifications. Regards, Valery. > -- > kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
