Subject: [IPsec] Next steps on TCP Encapsulation for IKEv2

From: Tommy Pauly <[email-masked]>
Date: Tue, 05 Apr 2016 12:27:01 -0300

Hello,

At our meeting yesterday, we agreed that we want one more revision of draft-pauly-ipsecme-tcp-encaps-03 before putting it up for working group adoption to clear up a few concerns.

Here are the changes we’re planning:

1. Reconcile the length field size with 3GPP’s recommendation (sent out by Tero) to promote interoperability if any devices have already implemented 3GPP’s suggestions. This would mean changing the length field from 32 bits to 16 bits.

2. Address the concerns around including too many direct references to use of TLS and port 443 in the body of the standards track document. The current plan here would be to make all direct references to TLS in the body of the document be more generic regarding any protocols over TCP that are added to encapsulate the IKE session, and point to an appendix that explains the caveats regarding TLS. The main point to communicate is that TLS should not influence the framing of IKE or ESP packets on the stream, and that the encryption and authentication properties of TLS do not influence the IKE session at all. Valery, I believe this should address your concerns.

Please reply with your feedback if you think these changes are good ideas, and if there are any other remaining points that should be changed before we move ahead.

After this, the plan would be to ask for working group adoption of the document if there are no other objections, and to in parallel start an informational document (perhaps a draft, perhaps outside of IETF) to describe the practical strategies for using TLS to encapsulate the tunnel, and more detail on proxy interactions.

Thanks,
Tommy Pauly

---

From: Yoav Nir <[email-masked]>
Date: Tue, 5 Apr 2016 13:14:08 -0300

Hi, Tommy.

The changes look fine, although I’m still not convinced we even need the TLS. But that’s for another thread.

We foresee that most TCP encapsulation is likely to be in on port 443. I think TCP encapsulation of IKEv2/IPsec should be easily distinguishable from other types of traffic on the same port.

I propose we add a magic value at the start of a non-TLS TCP stream, something very different from (0x16, 0x03, 0x01, 0x00).

Yoav

> On 5 Apr 2016, at 12:27 PM, Tommy Pauly <[email-masked]> wrote:
> 
> Hello,
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 06 Apr 2016 11:20:08 -0300

Hi Yoav,

Thanks for the feedback. While I see the advantage of adding the magic value at the start of the non-TLS TCP stream, especially over port 443, this seems to require the document to even more explicitly discuss TLS. If implementations do end up using TLS, as I believe many will in practice, then presumably they would not include this magic byte at the beginning of their stream over TLS. This means that the inner protocol diverges depending on which set of protocols are being used for the stream. I would prefer that these be consistent if possible.

Thoughts?

Tommy

> On Apr 5, 2016, at 1:14 PM, Yoav Nir <[email-masked]> wrote:
> 
> Hi, Tommy.
> 
>> On 5 Apr 2016, at 12:27 PM, Tommy Pauly <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hello,
>> 
>> [email-masked] <mailto:[email-masked]>

---

From: Yoav Nir <[email-masked]>
Date: Wed, 6 Apr 2016 16:13:51 -0300

My opinion is colored by my implementation. Our gateway listens in on port 443, and has to distinguish between several kinds of connections:
 - IKE-over-TCP (it’s the old IKEv1 think, but still…)
 - TLS handshake, and that splits further into:
   - SSL-VPN
   - with your draft: IKE
   - HTTPS to some kind of portal served by the gateway.

So the first thing is to distinguish between TLS and non-TLS, and the question is “does it look like ClientHello”. ClientHello looks like 16 03 00/01/02/03 00/01/02. 
In version -03 of the draft you are proposing to begin the a 4-byte length field, so assuming a 1000-bye Initial request, that’s going to be 00 00 03 E8. This looks different enough. There is a proposal to make this field 2-byte, so this would start with 03 E8 00 00.  Is this OK?  Yes, but what if we happened to have an Initial request with size 5635?  Then we get 16 03 00 00.  That looks too much like ClientHello.  Of course I can argue that a 5635-byte Initial request is ludicrously large, but I still think this is worth it.

For the second kind of distinguishing we’d need to tell apart whatever SSL-VPN protocol we support from IKE. I think the magic number would help here as well. HTTP/2 has this really big magic described in section 3.5, but HTTP/1 does not.  So I think a magic will be needed there as well.

Yoav

> On 6 Apr 2016, at 11:20 AM, Tommy Pauly <[email-masked]> wrote:
> 
> Hi Yoav,
> 
>> On Apr 5, 2016, at 1:14 PM, Yoav Nir <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi, Tommy.
>> 
>>> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>
>>