> On Aug 31, 2016, at 6:41 AM, Mirja Kuehlewind (IETF) <i...@kuehlewind.net> > wrote: > > 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…
"IKE packets need to be encapsulated in ESP over TCP" is not correct, since IKE does not run over ESP. IKE and ESP packets run alongside one another in the stream, as they do when using UDP encapsulation. How about: "There have been middle boxes blocking IKE negotiation over UDP. To make IKE work in these environments, both IKE packets and tunneled ESP packets need to be encapsulated in TCP. Therefore the group will define a mechanism to use IKE and IPsec over TCP, and define the scenarios in which it is appropriate to use this method." The draft covers the applicability of TCP encapsulation, but I strongly believe that specific algorithm for fallback is out of scope. This will be highly context-dependent, and we will have different algorithms for different devices and scenarios. I have planned on writing an informational draft as a follow-on to describe the methods we use, but that should be independent of the protocol to define the IKE/ESP messages in a stream, which is a much more general protocol. Thanks, Tommy > > Mirja > > >> Am 31.08.2016 um 15:17 schrieb Yoav Nir <ynir.i...@gmail.com>: >> >> >>> On 31 Aug 2016, at 3:21 PM, Tero Kivinen <kivi...@iki.fi> 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 > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
