Hi Kathleen, > On Aug 31, 2016, at 6:53 PM, Kathleen Moriarty > <kathleen.moriarty.i...@gmail.com> wrote: > > Tommy, > > On Wed, Aug 31, 2016 at 10:30 AM, Tommy Pauly <tpa...@apple.com > <mailto:tpa...@apple.com>> wrote: >> >>> 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." > > Are you okay with Tero's proposed wording since Mirja has agreed to > it. The suggested wording is: > > There have been middle boxes blocking IKE negotiation over UDP. To > make IKE work in these environments, IKE and ESP packets need to be > transmitted 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.
The final sentence seems like it's missing a word after "guidance": "Further the group will provide guidance how to detect when IKE cannot be negotiated over UDP and TCP as a fallback should be used." How about: "The group will also provide guidance on how to detect when IKE cannot be negotiated over UDP, and TCP should be used as a fallback". From a content perspective, I am fine with this as long as the primary draft leaves the algorithm as a fairly open-ended suggestion. I think it is appropriate to say that the IKE_SA_INIT should be sent over UDP several times, after which point a fallback to TCP is appropriate if so configured on the device (and that this fallback may be sooner if there is historical reason to believe it is necessary). Any more specifics about timing and how to measure expected response times, etc, would be out of scope. Does that work? Thanks, Tommy > > Sorry for my delayed response to make sure this was addressed, I was > off today and driving for a good portion of the day. > > Thanks, > Kathleen > >> >> 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 >> > > > > -- > > Best regards, > Kathleen
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
