Subject: Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-tcp-guidelines-00.txt

From: Valery Smyslov <[email-masked]>
Date: Fri, 7 Sep 2018 16:23:39 +0300

Hi,

I've posted a draft with clarifications and implementation guidelines
for RFC8229. These clarifications and recommendations are based 
on experience of implementing TCP encapsulation and testing it in 
various IKEv2 scenarios.

Feedback of any sort is highly appreciated.

Regards,
Valery.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, September 07, 2018 3:42 PM
> To: Valery Smyslov
> Subject: New Version Notification for draft-smyslov-ipsecme-tcp-guidelines-00.txt
> 
> 
> A new version of I-D, draft-smyslov-ipsecme-tcp-guidelines-00.txt
> has been successfully submitted by Valery Smyslov and posted to the
> IETF repository.
> 
> Name:		draft-smyslov-ipsecme-tcp-guidelines
> Revision:	00
> Title:		Clarifications and Implementation Guidelines for using TCP Encapsulation in IKEv2
> Document date:	2018-09-07
> Group:		Individual Submission
> Pages:		8
> URL:            https://www.ietf.org/internet-drafts/draft-smyslov-ipsecme-tcp-guidelines-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-tcp-guidelines/
> Htmlized:       https://tools.ietf.org/html/draft-smyslov-ipsecme-tcp-guidelines-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-smyslov-ipsecme-tcp-guidelines
> 
> 
> Abstract:
>    The Internet Key Exchange Protocol version 2 (IKEv2) defined in
>    [RFC7296] uses UDP transport for its messages.  [RFC8229] specifies a
>    way to encapsulate IKEv2 and ESP (Encapsulating Security Payload)
>    messages in TCP, thus making possible to use them in network
>    environments that block UDP traffic.  However, some nuances of using
>    TCP in IKEv2 are not covered by that specification.  This document
>    provides clarifications and implementation guidelines for [RFC8229].
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat

---

From: Paul Wouters <[email-masked]>
Date: Fri, 7 Sep 2018 10:05:57 -0400 (EDT)

> Feedback of any sort is highly appreciated.

I would cut a lot of the introduction / abstract and come straight to
the point. Simiarly, further one not provide as much details and just
come to the point faster.

I don't see any consideration in the document about deployments that
use a TCP proxy in front of the IKE daemon. In those scenarios, the
daemon might not even know TCP is used or the proxy code is written in
a way that only minimal changes to the IKEv2 core are needed. So a lot
of decisions you specify, such as not sending retransmits, might not
be possible for those kind of implementations, and so this document
dictating them for make interop harder, not easier.

As this also touches on message IDs, and I think we might have some
msgid deadlocks even in the UDP only case, perhaps a clarifying
document could add some non-TCP items as well? And the TCP part could
be part of the new clarification draft ?

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 7 Sep 2018 17:18:58 +0300

Hi Paul,

> come to the point faster.

I tried to be pedant :-) 

> a way that only minimal changes to the IKEv2 core are needed. 

Is it ever possible? My experience shows that adding TCP encapsulation
influences IKEv2 code pretty highly.

> So a lot of decisions you specify, such as not sending retransmits, might not

Why? Can you clarify in which cases interop will be harder?

> msgid deadlocks even in the UDP only case, perhaps a clarifying

If you mean MOBIKE, I agree with you that deadlocks seem to be possible.

> be part of the new clarification draft ?

Not sure it's worth to mix them. 

Regards,
Valery.

> 
> Paul
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 07 Sep 2018 08:47:57 -0700

Hi Valery,

Thanks for sharing this!

I agree with the points you bring up for MOBIKE (not changing the message ID, and needing to recalculate NAT detection payloads). Those are useful to clarify.

Regarding retransmissions/puzzles/error handling, I agree with Paul that the recommendations being provided in your draft are potentially harmful to interoperability. We specifically did not include those in RFC8229 because it is not only possible, but likely, that some deployments will use TCP as a proxying layer that’s not directly implemented on the IKE endpoint, and that the IKE messages may be sometimes transmitted over both UDP and TCP (UDP behind TCP). This is, in fact, how we did our initial testing and bringup of the functionality.

Not retransmitting (or the other examples) assumes that the reliable link is end-to-end, even though that is not guaranteed or required by the spec. Can you clarify why an implementation would require modification of the protocol such that TCP encapsulation could not occur in a proxy? The one case I see is client-side MOBIKE, but I don’t think the server needs to do anything special (and clients that don’t want to do fancy MOBIKE fallback between UDP and TCP don’t need to change).

Thanks,
Tommy

> On Sep 7, 2018, at 7:18 AM, Valery Smyslov <[email-masked]> wrote:
> 
> Hi Paul,
>

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 10 Sep 2018 15:14:52 +0300

Hi Tommy,

> I agree with the points you bring up for MOBIKE (not changing the message ID, and needing to recalculate
> NAT detection payloads). Those are useful to clarify.
> 
> Regarding retransmissions/puzzles/error handling, I agree with Paul that the recommendations being
> provided in your draft are potentially harmful to interoperability. We specifically did not include those in
> RFC8229 because it is not only possible, but likely, that some deployments will use TCP as a proxying layer
> that’s not directly implemented on the IKE endpoint, and that the IKE messages may be sometimes
> transmitted over both UDP and TCP (UDP behind TCP). This is, in fact, how we did our initial testing and
> bringup of the functionality.

Yes, I assumed that TCP is end-to-end. 

> Not retransmitting (or the other examples) assumes that the reliable link is end-to-end, even though that is
> not guaranteed or required by the spec. Can you clarify why an implementation would require modification of
> the protocol such that TCP encapsulation could not occur in a proxy? The one case I see is client-side MOBIKE,
> but I don’t think the server needs to do anything special (and clients that don’t want to do fancy MOBIKE
> fallback between UDP and TCP don’t need to change).

Let's first clarify what TCP proxy is. I can imagine a four different scenarios 
( <-> means UDP traffic, <=> means TCP traffic):

1. UDP IKEv2 Initiator <-> TCP Proxy 1 <=> TCP Proxy 2 <-> UDP IKEv2 Responder

In this case both IKEv2 implementations see only UDP traffic, so recommendations
given in the draft are not applicable.

2. TCP IKEv2 Initiator <=> TCP IKEv2 Responder

In this case there are no TCP proxies at all, this is the case that is assumed in the draft.

3. TCP IKEv2 Initiator <=> TCP Proxy <-> UDP IKEv2 Responder
4. UDP IKEv2 Initiator <-> TCP Proxy <=> TCP IKEv2 Responder

These are the cases where problems might arise. In particular:
a. NAT_DETECTION_*_IP content won't match, so there will always
    be "false positive" detection of NAT. 
b. In case 4 if TCP session is broken for any reason, then it is the 
    Initiator's responsibility to restore it. However, in this case 
    Initiator is not aware of the presence of TCP, so if it has no traffic
    to send, the TCP connection will remain broken. If the responder
    during that period needs to send something to the Initiator
    (say, to rekey SA), it will fail and the SA will be deleted, causing
    de-synchronization between the peers.
c. Multihomed MOBIKE scenarios won't work (unless proxy is co-located
    on the same host with IKEv2).
d. There may be some issues with transport mode, because it is 
     assumed that the IPsec SA is between IKE peers, and the "peers"
     will be different in case of TCP and UDP (unless proxy is co-located
    on the same host with IKEv2).

Am I missing something?

BTW, if you assume that the TCP proxy is always co-located on the same host
with UDP IKEv2 implementation, then we can assume that the UDP link 
proxy <-> IKEv2 is reliable (the packets don't leave the host), 
so recommendations given in the draft (no retransmissions etc.) won't harm.

Regards,
Valery.