Hi all, thanks for providing the reference to the draft. That was very helpful and confirmed my initial assumption that you don’t want to ‚change‘ TCP. So this work seems to be fine in this group, however, the wording in the charter is very misleading. What's about the following?
"There have been middle boxes blocking IKE negotiation over UDP. To make IKE work in these environments, IKE packets need to be encapsulated in ESP over TCP. Therefore the group will define a mechanism to use IKE and IPsec over TCP. Further the group will provide guidance how to detect when IKE cannot be negotiated over UDP and TCP as a fallback should be used.“ I also removed some redundancy and added a point that guidance is needed to detect blocking. We could still at the current draft as a starting point… Mirja > Am 31.08.2016 um 15:17 schrieb Yoav Nir <[email protected]>: > > >> 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
