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 <ynir.i...@gmail.com> 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 <tpa...@apple.com >> <mailto:tpa...@apple.com>> 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 >> IPsec@ietf.org <mailto:IPsec@ietf.org> >> https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > 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
