Sent from my iPhone
> On Sep 1, 2016, at 5:35 AM, Mirja Kuehlewind (IETF) <i...@kuehlewind.net> > wrote: > > Yes, that’s fine for me. I would say that providing guidance means that you > make one suggestion what to do but don’t specify a mandatory behavior. Ok, I'll update the text before our call today. This section does read better now. Thank you, Kathleen > > Mirja > > >> Am 01.09.2016 um 05:13 schrieb Tommy Pauly <tpa...@apple.com>: >> >> 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> 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
