Hi, Brandon, > On Jun 11, 2019, at 12:47 PM, Brandon Williams <brandon.williams@xxxxxxxxxx> wrote: > > Hi Joe, > > First, some clarification ... You stated. > >> Finally, I’m quite bothered by the glib idea that transport packets >> simply be translated into each other either between two TCP >> connections or between TCP and UDP. The notion is simply false; TCP >> doesn’t preserve message boundaries and TCP segments are not >> guaranteed to match application message boundaries. > > There is no TCP-to-TCP relay case here. The side opposite the TURN > client is always UDP, even if the remote client is also connected to a > TURN server. The two TURN servers would use UDP in between, and the two > TURN servers would not even know that the other one is there. > > Also, the spec does not relay "packets" between TCP and UDP. TURN does > not rely on TCP to maintain message boundaries. Instead, a TURN TCP > connection frames messages within the stream and that message framing > allows the TURN server to maintain message boundaries when sending the > messages within UDP datagrams. The description in the document implies packet-to-packet translation, which seems dangerous (even as a description). This is especially true for the notion that each UDP packet is translated into exactly one TCP frame directly. The description above in this email implies you’re just receiving “application” messages on one transport and emitting them on another. That makes a lot more sense, but it’s inconsistent with the description in this doc. > >> Overall, the point is that simply ignoring this issue is insufficient >> - at a minimum, this doc needs to clearly state that this issue is >> being ignored and why, as well as addressing that issue in the >> security sections. > > Acknowledging that TCP options are being ignored when messages are > relayed could be OK. I'm not entirely certain what you're suggesting > relative to the security considerations though. Are you just pointing to > the fact that security built into TCP (e.g., tcp-ao, tcp-eno, tcp-crypt) > cannot be used to provide end-to-end security? In the same way that > (D)TLS cannot be used for this purpose either? If not that, what else do > you have in mind? OK, so given you’re just terminating the connection, you need to talk about the implications of doing so, and yes, the kinds of issues above are relevant. If you were opening your own TCP connection, it would be relevant to discuss how you decide what options to enable as well and whether those options are determined based on the options of the other TCP connection (but you’re not doing that). I.e., my suggestion would be to make the description of the conversion process match this email’s explanation, i.e., as an application relay rather than as direct packet-to-packet conversion, including: - adjust your description of how you relay messages to talk about things at the “application” layer when you talk about IPv4 or IPv6 properties, the issue is about how you configure those as endpoints on the translator, not how *each packet* is translated NOTE - your document is incorrect regarding TTL; only routers drop packets with hopcounts/TTLs of zero. A host MUST NOT (per RFC 1122/8200) - address how your endpoint deals with TCP options that might have impact, including TCP multiparty, AO, ENO, MD5, fastopen, and user timeout > > Regarding UDP options, I agree with Magnus that it's probably better to > rely on tsvwg to state something about UDP option relay makes more > sense, considering that the UDP options draft isn't published yet. It's > unclear what could be said meaningfully in the TURN draft. If you have a > suggestion that might help. The intro to Sec 2.7 could be as follows (clarifying the way in which the IP frag avoidance is introduced as well): For reasons described in [Frag-Harmful], applications, especially those sending large volumes of data, should try hard to avoid having their packets fragmented. Applications using TCP can more or less ignore this issue because fragmentation avoidance is now a standard part of TCP, but applications using UDP (and thus any application using this version of TURN) need to avoid IP fragmentation by sending sufficiently small messages or use UDP fragmentation [draft-ietf-tsvwg-udp-options]. The application running on the client and the peer can take one of two approaches to avoid IP fragmentation until UDP fragmentation support is available. The first uses messages that are limited to a predetermined fixed maximum and the second relies on network feedback to adapt that maximum. > > Thanks, > --Brandon > > > On 6/11/19 2:03 PM, Joe Touch wrote: >> Hi, all, >> >> Here are my key points: >> >> - whether you deal with TCP options or simply ignore those on incoming >> connections and use defaults on outgoing, the issue needs to be >> addressed - as well as its impact on your use. >> - UDP options are not experimental; they’re standards-track; it could be >> mentioned here non-normatively as a possible workaround to the IP >> fragmentation issue. >> >> Finally, IMO, assuming that RTP/RTCP can or should provide extended >> functions that might already be provided by existing TCP options or >> emerging UDP options seems like both wasted effort and a failed >> opportunity to tune the transport as it was intended. >> >> Overall, the point is that simply ignoring this issue is insufficient - >> at a minimum, this doc needs to clearly state that this issue is being >> ignored and why, as well as addressing that issue in the security sections. >> >> Finally, I’m quite bothered by the glib idea that transport packets can >> simply be translated into each other either between two TCP connections >> or between TCP and UDP. The notion is simply false; TCP doesn’t preserve >> message boundaries and TCP segments are not guaranteed to match >> application message boundaries. >> >> I.e., the transport implications of this “hack” are inadequately addressed. >> >> Joe >> >>> On Jun 11, 2019, at 1:28 AM, Magnus Westerlund >>> <magnus.westerlund@xxxxxxxxxxxx >>> <mailto:magnus.westerlund@xxxxxxxxxxxx>> wrote: >>> >>> Hi Joe and Tiru, >>> >>> May I hazard a guess why this have not arisen is that there are no >>> transport protocol options that makes sense to use end-to-end and are >>> not protocol specific. Thus, in UDP <-> TCP translations by TURN >>> server there has so far not been a need to carry any of them over. >>> Joe, can you think of any that would make sense? >>> >>> For UDP <-> UDP the experimental proposal for UDP options I don't see >>> that we can require this specification to have to specify that. I do >>> think it is an interesting question for >>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ if that >>> should write more about what to do with the options when performing >>> translation operations? >>> >>> When it comes to RTP and RTCP that is widely used over TURN relays >>> when those applications need extended functionality they have gone >>> ahead and extended RTP/RTCP rather than attempting to affect lower >>> layers where other entities than the end-points are required to be >>> upgraded. >>> >>> Cheers >>> >>> Magnus >>> >>> >>> >>> >>> On 2019-06-11 07:20, Konda, Tirumaleswar Reddy wrote: >>>> >>>> Hi Joe, >>>> >>>> >>>> >>>> I meant the specifications that use TURN (ICE, SIP and WebRTC) do not >>>> discuss setting any TCP option for application data (RTP, RTCP and >>>> WebRTC data channels). Please note TCP is only used as fallback >>>> transport only if UDP traffic is blocked to the TURN server. >>>> >>>> TURN has been widely deployed in the field, and there was no >>>> discussion in the WG to explicitly handle TCP options. >>>> >>>> >>>> >>>> Cheers, >>>> >>>> -Tiru >>>> >>>> >>>> >>>> *From:* Joe Touch <touch@xxxxxxxxxxxxxx> >>>> *Sent:* Monday, June 10, 2019 7:59 PM >>>> *To:* Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@xxxxxxxxxx> >>>> *Cc:* tsv-art@xxxxxxxx; draft-ietf-tram-turnbis.all@xxxxxxxx; >>>> ietf@xxxxxxxx; tram@xxxxxxxx >>>> *Subject:* Re: [Tsv-art] [tram] Tsvart last call review of >>>> draft-ietf-tram-turnbis-25 >>>> >>>> >>>> >>>> *CAUTION*:External email. Do not click links or open attachments >>>> unless you recognize the sender and know the content is safe. >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> Hi, Tiru, >>>> >>>> >>>> >>>> On Jun 9, 2019, at 11:43 PM, Konda, Tirumaleswar Reddy >>>> <TirumaleswarReddy_Konda@xxxxxxxxxx >>>> <mailto:TirumaleswarReddy_Konda@xxxxxxxxxx>> wrote: >>>> >>>> >>>> >>>> On Jun 7, 2019, at 4:39 AM, Konda, Tirumaleswar Reddy >>>> <TirumaleswarReddy_Konda@xxxxxxxxxx >>>> <mailto:TirumaleswarReddy_Konda@xxxxxxxxxx>> wrote: >>>> >>>> >>>> The specification has two sections 14 and 15 (IP >>>> Header Fields for >>>> UDP-to- >>>> >>>> UDP translation and IP Header Fields for TCP-to-UDP >>>> translation) to >>>> discuss direct translations. >>>> https://tools.ietf.org/html/rfc5766 >>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5766&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=wlJBA0wCj1jIz4f3RegWs8USi6_gsk3fo6HsaHNmDwE&s=zpNv5YDpI2-wPNhWSnCb1VsidyMEg7LYQdn6IeLqdg4&e=> >>>> only >>>> covered UDP-to- UDP translation in Section 12. >>>> >>>> Yes, but both sections ignore the impact of transport >>>> options - both >>>> current for TCP and pending for UDP. These are >>>> ignored both when >>>> packets with such transport options are received (the >>>> input packet to >>>> the translation) and whether / how they are used on >>>> transmit (the >>>> output packet) >>>> >>>> >>>> TURN is used to relay real-time data (e.g. audio and >>>> video streams) >>>> and the approach taken by VOIP related specifications is >>>> to avoid >>>> fragmentation for RTP packets >>>> >>>> >>>> Sec 2.8 mentions RTP as one use case envisioned (at this >>>> point, it’d be fair to >>>> ask this revision to clarify whether that turned out to be >>>> true). But it isn’t >>>> indicated as the only use case. >>>> >>>> >>>> The draft says TURN is invented to support multimedia sessions >>>> signaled using SIP and is typically used with ICE. TURN is also >>>> used with WebRTC, and WebRTC data channels also >>>> avoid IP fragmentation >>>> (see https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Drtcweb-2Ddata-2Dchannel-2D13&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=wlJBA0wCj1jIz4f3RegWs8USi6_gsk3fo6HsaHNmDwE&s=II1OEcj0VllH4yVwB5IyIB0KKiXf42ScemFtYoXUQts&e=>). >>>> >>>> >>>> >>>> The application protocols TURN is designed for or typically used for >>>> is not relevant to my point above, unless you’re claiming that these >>>> uses never use transport options (which is doubtful for TCP, for >>>> which some transport options are pervasively used by default). >>>> >>>> >>>> >>>> >>>> >>>> >>>> Regardless, though, this doesn’t impact the concern raised >>>> above. RTP could >>>> still employ transport options. >>>> >>>> >>>> I checked again and don't see any RTP, Back-to-Back User Agents >>>> (B2BUAs), SIP proxies and WebRTC gateway specifications >>>> discussing transport options for translations. >>>> >>>> >>>> >>>> The fact that others have this gap does not justify continuing to >>>> fail to address it in this document. If anything, it makes it that >>>> much more important to address. >>>> >>>> >>>> >>>> Joe >>>> >>> >>> -- >>> >>> Magnus Westerlund >>> >>> ---------------------------------------------------------------------- >>> Network Architecture & Protocols, Ericsson Research >>> ---------------------------------------------------------------------- >>> Ericsson AB | Phone +46 10 7148287 >>> Torshamnsgatan 23 | Mobile +46 73 0949079 >>> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx >>> ---------------------------------------------------------------------- >>> _______________________________________________ >>> Tsv-art mailing list >>> Tsv-art@xxxxxxxx <mailto:Tsv-art@xxxxxxxx> >>> https://www.ietf.org/mailman/listinfo/tsv-art >> >> >> _______________________________________________ >> tram mailing list >> tram@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/tram >> > > -- > Brandon Williams > Platform Engineering > Akamai Technologies Inc. > > _______________________________________________ > Tsv-art mailing list > Tsv-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/tsv-art
