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

[Valery Smyslov]

Hi Tero,

> [WG chair hat off]
> 
> Valery Smyslov writes:
> > 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 such text should have been added to the RFC8229.
> 
> > 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?
> 
> 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...

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.

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

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.

> --
> kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Valery Smyslov]

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  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
> > IPsec@ietf.org
> > https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Tommy Pauly]

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  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
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Tobias Brunner]

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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec