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.
Mirja > Am 01.09.2016 um 05:13 schrieb Tommy Pauly <[email protected]>: > > Hi Kathleen, > >> On Aug 31, 2016, at 6:53 PM, Kathleen Moriarty >> <[email protected]> wrote: >> >> Tommy, >> >> On Wed, Aug 31, 2016 at 10:30 AM, Tommy Pauly <[email protected]> wrote: >>> >>>> On Aug 31, 2016, at 6:41 AM, Mirja Kuehlewind (IETF) <[email protected]> >>>> 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 <[email protected]>: >>>>> >>>>> >>>>>> On 31 Aug 2016, at 3:21 PM, Tero Kivinen <[email protected]> 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 >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/ipsec >>> >> >> >> >> -- >> >> Best regards, >> Kathleen > _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
