Hi Tero, thanks for the reply. Very helpful background info. Maybe even put more information in the charter text.
When you say "the 3gpp specification did not consider or specify all needed things for the protocol“, can you be more specific here? I’m not saying that this is the wrong working group but it really depends on what you want to do. If you already have a clear view about what needs to be further specified and what the solution is, this might be the right group. If there is an unknown number of open questions to be answers, it might not. Mirja > Am 31.08.2016 um 13:57 schrieb Tero Kivinen <kivi...@iki.fi>: > > 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/ > -- > kivi...@iki.fi > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
