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