Thanks everyone for chiming in. I want to highlight that the point of the draft is to nail down the IKE-specific concerns of encapsulating the tunnel in streams. As mentioned by Tero, this includes how to specify the boundaries of messages within the stream; and how to interact with MOBIKE, redirection, fragmentation, and so on.
The protocol really could be summarized as "how to encapsulate IKE and IPSec in any stream-like protocol", and it specifically mentions that this applies beyond direct TCP streams. If we want to have work in other groups to change how the outer TCP works, that's great. Any work that would be done in that area could benefit such tunnels without requiring changes to the IPSec aspect. The practice of putting tunnels over TCP when absolutely necessitated by the restrictions of a network is common practice. If we do not specify this here, devices will still do it, just without a standard. As Yoav mentioned, this is common practice across essentially every non-IKE VPN tunnel protocol, and leads to a splintering of protocols to do the same thing. Please do read the draft (current version https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-02); it specifically calls out why TCP-in-TCP (which can happen in this scenario) is problematic, and so it specifies several times that this is only to be used as a fallback from UDP. We've done fairly extensive testing around the implications of this protocol, and made sure we were satisfied with the results before we proposed the draft. Thanks, Tommy > On Aug 31, 2016, at 6:17 AM, Yoav Nir <[email protected]> wrote: > > >> On 31 Aug 2016, at 3:21 PM, Tero Kivinen <[email protected]> wrote: >> >> Mirja Kuehlewind (IETF) writes: >>> thanks for the reply. Very helpful background info. Maybe even put >>> more information in the charter text. >> >> I think it belongs to the actual draft, not to the charter, perhaps we >> should put the draft-ietf-ipsecme-tcp-encaps in the charter, as >> a working draft. >> >>> When you say "the 3gpp specification did not consider or specify all >>> needed things for the protocol“, can you be more specific here? >> >> 3GPP just said that we make TCP tunnel, put 16-bit length header in >> front telling the length of the IKE or ESP packet coming after that, >> and then we put either ESP packet directly, or 4-bytes of zeros >> (Non-ESP marker we use in UDP encapsulation) and IKE packet. >> >> There is also keepalive timer sending packets over TCP to keep it >> alive (again similar what we have in UDP). > > One more bit of information: some vendors have had a non-standardized version > of this or something similar for years. My employer has had it since 2003, > except that the header is a bit different. The pretty ubiquitous SSL VPNs do > pretty much the same except that they encrypt IP packets plus headers into > TLS records rather than ESP packets before streaming them over TCP. > > Perhaps “TCP tunnel” is a misleading term because the TCP does not tunnel. > That is part of the function of ESP. Perhaps we should be saying “TCP > streaming of ESP and IKE packets” > > Yoav > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
