Subject: [IPsec] New revision of TCP Encapsulation draft

From: Tommy Pauly <[email-masked]>
Date: Fri, 20 Nov 2015 13:49:42 -0800

Hello,

Based on the feedback received at our informal meeting in Yokohama, I’ve updated the draft for TCP Encapsulation of IKEv2 and ESP:

https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-01

The revisions include:
- More explanation in the introduction about the motivation, and other work that this draft is trying to standardize (3GPP recommendations, proprietary IKEv1 IPSec over TCP versions, and SSL VPNs).
- Comments about maximum IKE and ESP message size within the TCP stream, which is effective the MTU of the tunnel.
- Specify that if the TCP connection is brought down and re-established, the first message on the stream must be an IKE message.
- Detailed considerations about interactions with middleboxes (thanks Graham Bartlett for input on this).

In the meeting in Yokohama, there was general agreement that this was relevant work that we’d like to keep looking into. Please read the document, and provide any feedback you have!

Thanks,
Tommy

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 21 Nov 2015 01:07:13 +0200

Hi Tommy,

I also think this is very relevant work. Here are some comments to -01:

I think that Yoav's draft, draft-nir-ipsecme-ike-tcp-01, should be cited 
under "prior work", both because it is documented and also because I 
believe it is implemented by a vendor.

In Sec. 1, under the UDP encapsulation, I suggest to add "Often peers 
will use UDP encapsulation even when there is no NAT on the path, for 
example because networks or middleboxes do not support IP protocols 
other than TCP and UDP."

"Although a stream" - this paragraph is not worded very well (streams 
don't send anything) and is hard to understand. In addition, there are 
lots of networks that use jumbo frames and so hardcoding the value 1500 
into the spec may not be a good idea.

I can think of HA cases where several gateways will handle ESP SAs that 
are all associated with the same IKE SA. So I'm wondering why we are 
insisting of all Child SAs being in the same TCP connection, and as a 
result requiring that an IKE message should be the preamble of any new 
connection.

Although it might seem obvious, I think Sec. 3 should say explicitly 
that if the connection is closed midway through a message, the recipient 
MUST silently drop the partial message.

You may want to add to the last paragraph of the Security 
Considerations: This document explicitly does not define a profile for 
TLS when used in this manner, or any relation between identities at the 
IPsec level and those on the TLS level ("channel binding").

Thanks,
	Yaron

On 11/20/2015 11:49 PM, Tommy Pauly wrote:
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 21 Nov 2015 01:10:58 +0200

Hi Tommy,

"Although a stream" - this paragraph is not worded very well (streams 
don't send anything) and is hard to understand. There are lots of 
networks that use jumbo frames and so hardcoding the value 1500 into the 
spec may not be a good idea.

I can think of HA cases where several gateways are handling ESP SAs that 
are all associated with the same IKE SA. So I'm wondering why we are 
insisting on all Child SAs being in the same connection, and as a result 
requiring that an IKE message be the preamble to any new connection.

Although it might seem obvious, I think Sec. 3 should say explicitly 
that if the connection is closed midway through a message, the recipient 
must silently drop the partial message.

You may want to add to the last paragraph of the Security 
Considerations: This document explicitly does not define a profile for 
TLS when used in this manner, or any relation between identities at the 
IPsec level and those at the TLS level ("channel binding").

Thanks,
	Yaron

---

From: Yoav Nir <[email-masked]>
Date: Sat, 21 Nov 2015 09:35:38 +0200

> On 21 Nov 2015, at 1:10 AM, Yaron Sheffer <[email-masked]> wrote:
> 
> Hi Tommy,
> 
> I think that Yoav's draft, draft-nir-ipsecme-ike-tcp-01, should be cited under "prior work”

That’s draft-ietf-ipsecme-ike-tcp-01. It was a working group document for a while.

Yoav