Re: [Tsv-art] [tram] Tsvart last call review of draft-ietf-tram-turnbis-25

["Konda, Tirumaleswar Reddy" <[e-mail]>]

Hi Joe,

Please see inline

> -----Original Message-----
> From: Joe Touch <[e-mail]>
> Sent: Wednesday, June 12, 2019 3:35 AM
> To: Brandon Williams <[e-mail]>
> Cc: Magnus Westerlund <[e-mail]>; tsv-
> [e-mail]; Konda, Tirumaleswar Reddy
> <[e-mail]>; draft-ietf-tram-
> [e-mail]; [e-mail]; [e-mail]
> 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
> <[e-mail]> 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
> >>> <[e-mail]
> >>> <mailto:[e-mail]>> 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 <[e-mail]>
> >>>> *Sent:* Monday, June 10, 2019 7:59 PM
> >>>> *To:* Konda, Tirumaleswar Reddy
> >>>> <[e-mail]>
> >>>> *Cc:* [e-mail]; [e-mail];
> >>>> [e-mail]; [e-mail]
> >>>> *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
> >>>>    <[e-mail]
> >>>>    <mailto:[e-mail]>> wrote:
> >>>>
> >>>>
> >>>>
> >>>>        On Jun 7, 2019, at 4:39 AM, Konda, Tirumaleswar Reddy
> >>>>        <[e-mail]
> >>>>        <mailto:[e-mail]>> 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  [phone]
> >>> Torshamnsgatan 23           | Mobile [phone]
> >>> SE-164 80 Stockholm, Sweden | mailto:
> [e-mail]
> >>> --------------------------------------------------------------------
> >>> -- _______________________________________________
> >>> Tsv-art mailing list
> >>> [e-mail] <mailto:[e-mail]>
> >>> https://www.ietf.org/mailman/listinfo/tsv-art
> >>
> >>
> >> _______________________________________________
> >> tram mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/tram
> >>
> >
> > --
> > Brandon Williams
> > Platform Engineering
> > Akamai Technologies Inc.
> >
> > _______________________________________________
> > Tsv-art mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tsv-art