Hi Joe,
Please see inline [TR1]
From: Joe Touch <touch@xxxxxxxxxxxxxx>
Sent: Sunday, June 16, 2019 12:22 AM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@xxxxxxxxxx>
Cc: Brandon Williams <brandon.williams@xxxxxxxxxx>; Magnus Westerlund <magnus.westerlund@xxxxxxxxxxxx>; draft-ietf-tram-turnbis.all@xxxxxxxx; ietf@xxxxxxxx; tram@xxxxxxxx; tsv-art@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.
|
On 6/14/2019 12:49 AM, Konda, Tirumaleswar Reddy wrote:
Hi Jon,
Please see inline [TR]
|
CAUTION:
External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.
|
Hi, Tiru,
...
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.
[TR1] Section 15 discusses both IP fragmentation and IP options, 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
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.
[TR1] Okay, will add the following lines:
TCP multi-path [RFC6824] is not supported by this version of TURN because TCP multi-path is not used by both SIP and WebRTC protocols [RFC7478] for media and non-media data. If the TCP connection between the TURN client and server uses TCP-AO [RFC5925],
the client must secure application data (e.g. using SRTP) to provide confidentially, message authentication and replay protection to protect the application data relayed from the server to the peer using UDP. Note that TCP-AO option obsoletes TCP MD5 option.
Unlike UDP, TCP without the TCP Fast Open extension [RFC7413] does not support 0-RTT session resumption. The TCP user timeout [RFC5482] equivalent for application data relayed by TURN is the use of RTP control protocol (RTCP). As a reminder, RTCP is a fundamental
and integral part of RTP.
-Tiru
Joe
|
