Hi Valery, Thanks for bringing this up with the WG!
I agree that retransmissions of IKE packets within the TCP stream may be pointless, and add to congestion. We do mention this for ESP packets over the TCP stream (Section 12.2 Added Reliability for Unreliable Protocols), but it doesn’t call out IKE specifically. Depending on how TCP encapsulation is implemented on each peer, it may be safe to assume that the entire end-to-end communication is reliable, but it may not be. In our testing of the protocol, we have placed boxes in front of IKEv2 responders that handle the TCP encapsulation and translate them into UDP packets to pass on to the vanilla IKEv2 responder. In this case, the end-to-end reliability can’t be guaranteed, and the initiator of a message then may still need to retransmit IKE packets. If we did want to add a recommendation here, I’d be tempted to say that an implementation should certainly be less aggressive with retransmissions in IKE, but may still send them if there is a lack of response from the remote peer. I’m not overly concerned with the impact of retransmitting IKE packets on the stream to overall tunnel performance, since these generally only account for a few packets. Thanks, Tommy > On Apr 5, 2018, at 6:10 AM, Valery Smyslov <[email protected]> wrote: > > Hi Tobias, > >> Hi Valery, >> >> I agree that generally retransmits are not useful or needed with TCP >> encapsulation. But as I see it, retransmits might actually be required >> in some situations. If the client sends e.g. a CREATE_CHILD_SA request >> but the TCP connection is closed or gets unusable for some reason before >> the server's response is received, the client has to reestablish the TCP >> connection. And the only way to do this (with window size 1, so no DPD >> or MOBIKE update can be sent) is to send a retransmit of the already >> sent message (otherwise the server might not know which TCP connection > > That's why I suggested SHOULD :-) > >> to use to send the CREATE_CHILD_SA response - I guess ESP packets could >> be used for that too, if there are any and there is a way to get >> notified in userland). On the other hand, RFC 8229 explicitly says that >> a responder should not consider retransmitted messages when deciding >> which TCP connections should be used...so I guess there is no way to >> recover properly if the TCP connection is severed mid-exchange (e.g. >> because a NAT device is rebooted or the client device roams between >> networks). > > Yes, there may be situations which are difficult to recover from... > > Regards, > Valery. > >> Regards, >> Tobias > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
