Subject: [IPsec] RFC8229 (IKE over TCP) and retransmissions

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 5 Apr 2018 15:00:30 +0300

Hi,

after re-reading RFC8229 several times I cannot find any language about
retransmitting IKE messages in case of TCP. Clearly, the behavior described
in Section 2.1 is wrong in case of TCP, since TCP provides a reliable transport.
Blindly following these recommendations would only make things worse,
in case of network congestion, since it increases the amount of data TCP
would try to resend, and thus increasing congestion even more.
Ideally, some text should have been added, similar to the text clarifying
using IKE fragmentation in case of TCP. Something like that:

    TCP provides reliable transport, so there is no need for application to 
    deal with retransmissions. Moreover, performing retransmissions by IKE 
    in case of TCP on congested networks could further increase congestion 
    and degrade performance. For this reason IKE initiator SHOULD NOT
    retransmit requests if they are sent over TCP. However, IKE responder MUST 
    correctly handle retransmitted request messages received over TCP, but 
    it SHOULD NOT resend response messages in this case.

I think not having such a recommendation in RFC8229 is an oversight.
I'm not sure though it's worth filling in errata... What the WG thinks?

Regards,
Valery.

---

From: Tobias Brunner <[email-masked]>
Date: Thu, 5 Apr 2018 14:26:20 +0200

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
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).

Regards,
Tobias

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 5 Apr 2018 16:10:50 +0300

Hi Tobias,

> sent message (otherwise the server might not know which TCP connection

That's why I suggested SHOULD :-)

> because a NAT device is rebooted or the client device roams between

Yes, there may be situations which are difficult to recover from...

Regards,
Valery.

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 05 Apr 2018 08:59:21 -0700

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-masked]> wrote:
> 
> Hi Tobias,
> 
>> Hi Valery,
>> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 6 Apr 2018 02:47:43 +0300

[WG chair hat off]

>     it SHOULD NOT resend response messages in this case.

I think such text should have been added to the RFC8229. 

> I'm not sure though it's worth filling in errata... What the WG thinks?

I am not sure if it would be enough to make errata, I would actually
think it might be better to make RFC8229bis to fix this issue. The
problem with errata is that there are lots of people who do not notice
it...

So I think you should make errata of it, and we most likely should
make new version of 8229 and add that text, but that is just my
personal view of the issue.
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 6 Apr 2018 09:49:42 +0300

Hi Tommy,

> 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.

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 6 Apr 2018 09:57:58 +0300

Hi Tero,

> problem with errata is that there are lots of people who do not notice

I don't disagree with making RFC8229bis, however I'd rather not to do it right now,
but instead wait some time to gain more experience with IKE over TCP.
My gut feeling is that changing TCP connections on a live IKE SA 
will probably need more clarifications based on real life scenarios.

> personal view of the issue.

So, I'll submit errata unless someone disagree and have better proposal.
I think the errata can then be marked as "Hold for document update".

Regards,
Valery.