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). They did not define how it interacts with MOBIKE, and changing of the IP-addresses, or and so on. There are also other newer extensiosns like IKEv2 message fragmentation and those were not considered in the 3gpp specification. To get better answer what was missing, it would be better to ask from the implementors who are implementing these things, my reading was just as an IANA expert, as they needed some IKE notify and configuration payload numbers. > 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. I think the current draft mostly already answers to the questions, and I do not think there are that many open issues with it. > > Am 31.08.2016 um 13:57 schrieb Tero Kivinen <[email protected]>: > > > > 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] > > > -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
