Hi Tommy, thanks for the info. I understand the need for using TCP and also the need for standardization here. It was just not clear to me what exactly need to be done because I didn’t have the reference to the draft.
You as you said below what you need is guidance on "how to encapsulate IKE and IPSec in a stream-like protocol“. Maybe that the wording we could also use in the charter to clarify what the wg will do…? Mirja > Am 31.08.2016 um 16:10 schrieb Tommy Pauly <[email protected]>: > > 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
