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

[Joe Touch <[e-mail]>]

On 6/14/2019 12:49 AM, Konda, Tirumaleswar Reddy wrote:
>
> Hi Jon,
>
>  
>
> Please see inline [TR]
>
>  
>
> *From:* Joe Touch <[e-mail]>
> *Sent:* Thursday, June 13, 2019 7:47 PM
> *To:* Konda, Tirumaleswar Reddy <[e-mail]>
> *Cc:* Brandon Williams <[e-mail]>; Magnus
> Westerlund <[e-mail]>;
> [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 13, 2019, at 1:42 AM, Konda, Tirumaleswar Reddy
>     <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>      
>
>         ...
>         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.
>
>  
>
> Sec 15 talks about setting IP fragmentation based on the received
> messages. If this is not based on packet-to-packet translation, can
> you explain how this can be achieved? TCP sets DF for a connection,
> not on a per packet basis
>
>  
>
> [TR] It is not based on packet-to-packet translation. TURN client can
> set the DON’T-FRAGMENT attribute in the TURN message to tell the TURN
> server to set the DF bit in the resulting UDP datagram sent to the
> peer. Please see
> https://tools.ietf.org/html/draft-ietf-tram-turnbis-25#section-15
>
The section notes that only a single DSCP can be set for a TCP
connection. A similar note should be included in the discussion of IP
fragmentation and IP options  - these too can be set on a per-message
basis for UDP, but not for TCP.



>  
>
> ….
>
>             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.
>      
>
>  
>
> Yes, we agree (as I said, “if you were…” and “b..ut you’re not.”).
>
>  
>
> [TR] Glad to see we are making progress J
>
>
>
>         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.
>
>  
>
> This is correct behavior for IP-to-IP translation (sec 13), but not
> UDP-to-UDP (sec 14). The latter is not the function of a gateway, but
> rather the function of an app-layer proxy.
>
>  
>
> [TR] Got it, will update draft.
>
>
>         - 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.
>
>  
>
> You need to explain the impact of not being able to carry these
> options or their behavior across the UDP part of a TCP-to-UDP relay.
>
>  
>
> [TR] TCP multi-path is not supported by this specification because TCP
> multi-path is not used by both SIP and WebRTC protocols for media and
> non-media data. If the TCP connection uses TCP-AO, the client should
> secure application data (e.g. SRTP) to provide confidentially, message
> authentication and replay protection to protect the application data
> relayed from the server to the peer (Fake data is already discussed in
> Section 20.1.3).  I don’t see a need to discuss TCP fast open (UDP is
> 0-RTT), and MD5 is replaced by TCP-AO. TCP user-timeout equivalent for
> application data (RTP) is RTCP.
>
You need to address these issues - e.g., by a version of the response above.

Joe


>  
>
> Cheers,
>
> -Tiru
>
>  
>
> Joe
>