On Jun 15, 2012, at 1:34 PM, Tero Kivinen wrote: >>> 2. Since INIT always happens over UDP, as responder, I can immediately >>> close any TCP connection that doesn't present an IKE header with an SPI >>> I recognize. >> >> I don't agree that IKE_SA_INIT should always be over UDP. The first >> flight of packets from the server in TCP includes at most 2 packets. >> Then the server has to wait for an ACK to continue. Same goes for >> the request. So beginning with the IKE_AUTH exchange for TCP can add >> up to three roundtrips. This is a shame when dealing with a peer >> that we know supports IKE. > > I do not understand your statement above. Especially what does "server > has to wait for an ACK to continue"? If there is space in window there > is no need to wait for ACKs, you can just send next packet to the > other end immediately when you have it.
The application (in this context that is the IKE implementation) does not need to wait, it can send everything immediately. But TCP has slow start. Depending on OS, the first flight can be either 1 or 2 segments. If your IKE_AUTH message takes more than two segments, the third segment will wait for a TCP ack, effectively adding a round-trip. If you do the IKE_SA_INIT over TCP as well, then the ACK for the IKE_SA_INIT (usually delivered in the IKE_SA_INIT response) doubles the receive window, so the next request can be up to four segments. I don't think this is particularly significant, but this issue has come up in proposals for TLS, where the ServerHello-Certificate-[ServerKeyExchange]-ServerHelloDone flight can be very large, and break the 2 segment limit. Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
