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

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

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

….
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 ☺


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.

Cheers,
-Tiru


Joe