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
…. 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.”).
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 datagramto be discarded by a gateway but not by the destinationhost; however, hosts that act as gateways by forwardingdatagrams 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 |
