Hi Joe, Please see inline > -----Original Message----- > From: Joe Touch <touch@xxxxxxxxxxxxxx> > Sent: Wednesday, June 12, 2019 3:35 AM > To: Brandon Williams <brandon.williams@xxxxxxxxxx> > Cc: Magnus Westerlund <magnus.westerlund@xxxxxxxxxxxx>; tsv- > art@xxxxxxxx; Konda, Tirumaleswar Reddy > <TirumaleswarReddy_Konda@xxxxxxxxxx>; draft-ietf-tram- > turnbis.all@xxxxxxxx; tram@xxxxxxxx; ietf@xxxxxxxx > Subject: Re: [Tsv-art] [tram] Tsvart last call review of draft-ietf-tram-turnbis- > 25 > > This email originated from outside of the organization. Do not click links or > open attachments unless you recognize the sender and know the content is > safe. > > 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 TURN specification only discusses packet-to-packet translation for UDP-to-UDP relay and not for TCP-to-UDP relay. > > 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). No, TURN server does not establish TCP connection to the peer. TURN only supports UDP between the server and the peer. Please see https://tools.ietf.org/html/draft-ietf-tram-turnbis-25#section-2.1. > > 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) You are right will remove TTL text for TCP-to-UDP relay but not for UDP-to-UDP relay. RFC1122 says, the intent is that TTL expiration will cause a datagram to be discarded by a gateway but not by the destination host; however, hosts that act as gateways by forwarding datagrams must follow the gateway rules for TTL. > > - address how your endpoint deals with TCP options that might have impact, > including TCP multiparty, AO, ENO, MD5, fastopen, and user timeout The TURN server is not acting as a TCP-to-TCP relay and I don't understand the need to discuss these options. > > > > > 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. The proposed text looks good, will update draft. Cheers, -Tiru > > > > > 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_gsk3fo6Hsa > HNmDwE&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_gsk3fo6Hsa > HNmDwE&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
