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

[Joe Touch <[e-mail]>]

Hi, Tiru,

> On Jun 13, 2019, at 1:42 AM, Konda, Tirumaleswar Reddy <[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

….
>>> 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 <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.”).

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

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

Joe