Hi Tommy, > 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.
Yeah, but it's quite unusual setting outside test lab, isn't it? > 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. That's why I suggested SHOULD NOT :-) Anyway, it's easy to add recommendation that the initiator MAY retransmit message if no response is received for some (not too short) period of time. Regards, Valery. > 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
