Mirja Kuehlewind writes: > Similar to Spencer's commet I have problems understanding what the > following really means: > > "To make IKE work in these environments, IKE packets need to be > encapsulated in a TCP tunnel. The group will define a mechanism to > tunnel IKE and IPsec over a TCP-based connection. This method is > intended to be used as a fallback when IKE cannot be negotiated over > UDP. The group will create a method where IKEv2 and IPsec packets can > be encapsulated in the TCP connection." > > Based on Tero's mail I understand how the stack looks like but that's not > clear from the text because there is not really anything like a TCP > tunnel. So the big question is, based on the stack indicated by Tero, do > you have two full TCP connections running with two congestion control > loops and retransmission mechanisms on two different endpoints? That's > nothing I would recommend.
Short answer: Yes. There will be TCP inside TCP. > I fully understand the need for a fallback mechanism to TCP but depending > on what you actually aim for I'm not sure if this is the right wg for it; > therefore my block for now. I hope we can resolve that quickly! This method is already inside the 3GPP TS 24.302 (3rd Generation Partnership Project; Technical Specification Group Core Networks and Terminals; Access to the 3GPP Evolved Packet Core (EPC) via non-3GPP access networks; Stage 3, section F.3) [1]. This caused some problems to some IPsec vendors, as they need to implement it to support EPC, but the 3gpp specification did not consider or specify all needed things for the protocol, thus vendors needed to agree something that could really be used in interoperable way, and they also thought it would be better to do this work on the IETF, than in the 3GPP. IPsecME WG was considered right group to work on this, as this is mostly defining how this extension interacts with the IKE extensions etc (mobike, ike fragmentation, nat detection etc) [2]. The base 3GPP version did already specify how to put that ESP traffic inside the TCP, i.e. had TCP inside TCP already. What do you think would be better working group for this? [1] http://www.3gpp.org/DynaReport/24302.htm [2] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
