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 protected]> wrote: > > 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 protected] >> <mailto:[email protected]>> wrote: >> >> 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 protected] >>> <mailto:[email protected]>> wrote: >>> >>> 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 >>> _______________________________________________ >>> IPsec mailing list >>> [email protected] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/ipsec >>> <https://www.ietf.org/mailman/listinfo/ipsec> >> >> _______________________________________________ >> IPsec mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/ipsec >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
