Subject: Tsvart last call review of draft-ietf-tram-turnbis-25

From: Joseph Touch via Datatracker <[email-masked]>
Date: Tue, 04 Jun 2019 23:04:03 -0700

Reviewer: Joseph Touch
Review result: Ready with Issues

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
[email-masked] if you reply to or forward this review.

As a preface, this review is performed focusing on the changes since RFC 5766,
as this document appears to be a fairly direct update of that content.

Transport issues:

Although this document has substantial implications for transport protocols, it
does not significantly alter the content of RFC5766 in this regard. However,
there is a significant gap as follows:

- The direct translation of TCP into UDP or UDP into TCP is arguably a host
endpoint emulation function, which strongly suggests that this document needs
to explicitly address both receiving and transmitting transport options. Even
if all received options are ignored and no options are used on transmission,
that should be more directly stated – as well as the impact of that decision,
both on functionality and security.

Sec 2.7 might also note that the support for UDP fragmentation and reassembly
could be of benefit here in avoiding IP fragmentation, but that would be
contingent on the previous note – i.e., being able to use and react to UDP
options in the translation process.

Non-transport issues:

Like RFC 5766, this doc continues to cite I-D.rosenberg-mmusic-ice-nonsip as
guidance, even using a gentle version of “must”, but this no longer seems
appropriate because that document has expired over a decade ago. Either the
guidance should be summarized in this document or the recommendation should be
removed.

Section 2.7 is incorrect in its claim of 576 for IPv4; it confuses the receiver
reassembly minimum (EMTU_R, 576) for the link MTU (EMTU_S, 68). See
draft-ietf-tunnels for details. If 576 is the focus, at best it could be
claimed that 576 is the “de-facto” EMTU_S for IPv4. Other nits:

Sec 23 indicates the changes since RFC5766; a similar section addressing
changes since RFC6156 would be useful to add.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 6 Jun 2019 13:12:21 +0000

Hi Joseph,

Thanks for the review, Please see inline

> -----Original Message-----
> From: tram <[email-masked]> On Behalf Of Joseph Touch via
> Datatracker
> Sent: Wednesday, June 5, 2019 11:34 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: [tram] Tsvart last call review of draft-ietf-tram-turnbis-25
> 
> This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
> 
> Reviewer: Joseph Touch
> This document has been reviewed as part of the transport area review
> team's ongoing effort to review key IETF documents. These comments were
> written primarily for the transport area directors, but are copied to the
> document's authors and WG to allow them to address any issues raised and
> also to the IETF discussion list for information.
> 
> review as part of the last-call comments they receive. Please always CC tsv-
> [email-masked] if you reply to or forward this review.
> 
> As a preface, this review is performed focusing on the changes since RFC
> 5766, as this document appears to be a fairly direct update of that content.

Yes.

> 
> Transport issues:
> 
> Although this document has substantial implications for transport protocols,
> it does not significantly alter the content of RFC5766 in this regard. However,
> endpoint emulation function, which strongly suggests that this document
> needs to explicitly address both receiving and transmitting transport options.
> Even if all received options are ignored and no options are used on
> transmission, that should be more directly stated – as well as the impact of
> that decision, both on functionality and security.

The specification has two sections 14 and 15 (IP Header Fields for UDP-to-UDP translation and IP Header Fields for TCP-to-UDP translation) to discuss direct translations. https://tools.ietf.org/html/rfc5766 only covered UDP-to-UDP translation in Section 12. 

> 
> Sec 2.7 might also note that the support for UDP fragmentation and
> reassembly could be of benefit here in avoiding IP fragmentation, but that
> would be contingent on the previous note – i.e., being able to use and react
> to UDP options in the translation process.

I don't get the comment, what specific change are you looking in the document ?

> appropriate because that document has expired over a decade ago. Either
> the guidance should be summarized in this document or the
> recommendation should be removed.

Good point, Revised ICE specification (https://tools.ietf.org/html/rfc8445) has been updated to make the procedures independent of the signaling protocol by removing the SIP and SDP procedures.

I have updated the text as follows:

   For example, if TURN and ICE are used as part of a multimedia
   solution using SIP [RFC3261], then SIP serves the role of the
   rendezvous protocol, carrying the ICE candidate information inside
   the body of SIP messages [I-D.ietf-mmusic-ice-sip-sdp].  If TURN and
   ICE are used with some other rendezvous protocol, then ICE provides
   guidance on the services the rendezvous protocol must perform.

> draft-ietf-tunnels for details. If 576 is the focus, at best it could be claimed
> that 576 is the “de-facto” EMTU_S for IPv4. Other nits:

Section 2.7 says IPv4 host must be capable of receiving a packet whose length is equal to 576 bytes (EMTU_R, 576).  
Why do you say the text is incorrect ?

> changes since RFC6156 would be useful to add.

Okay, added another Section (updates to RFC6156).

Cheers,
-Tiru

> 
> 
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: Joe Touch <[email-masked]>
Date: Thu, 6 Jun 2019 09:48:18 -0400

> On Jun 6, 2019, at 9:12 AM, Konda, Tirumaleswar Reddy <[email-masked]> wrote:
> 
> Hi Joseph,
> 

Yes, but both sections ignore the impact of transport options - both current for TCP and pending for UDP. These are ignored both when packets with such transport options are received (the input packet to the translation) and whether / how they are used on transmit (the output packet)

> I don't get the comment, what specific change are you looking in the document ?

The doc currently indicates that UDP relies only on IP fragmentation, but this isn’t the case with UDP options (there is a UDP-level frag and reassembly that preserves port numbers on each fragment and would thus be TURN-compatible).

> Why do you say the text is incorrect ?

576 is the reassembly MTU, but is also referred as the PMTU. The PMTU is EMTU_S and is strictly only 68.

> Tsv-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tsv-art

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 7 Jun 2019 08:39:46 +0000

> From: Joe Touch <[email-masked]>
> Sent: Thursday, June 6, 2019 7:18 PM
> To: Konda, Tirumaleswar Reddy <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [Tsv-art] [tram] Tsvart last call review of draft-ietf-tram-turnbis-
> 25
> 
> > On Jun 6, 2019, at 9:12 AM, Konda, Tirumaleswar Reddy
> <[email-masked]> wrote:
> >
> > Hi Joseph,
> >
> >> This email originated from outside of the organization. Do not click
> >> links or open attachments unless you recognize the sender and know
> >> the content is safe.
> >>
> >> Reviewer: Joseph Touch
> >> team's ongoing effort to review key IETF documents. These comments
> >> were written primarily for the transport area directors, but are
> >> copied to the document's authors and WG to allow them to address any
> >> issues raised and also to the IETF discussion list for information.
> >>
> >> When done at the time of IETF Last Call, the authors should consider
> >> this review as part of the last-call comments they receive. Please
> >> always CC tsv- [email-masked] if you reply to or forward this review.
> >>
> >> As a preface, this review is performed focusing on the changes since
> >> RFC 5766, as this document appears to be a fairly direct update of that
> content.
> >
> > Yes.
> >
> >>
> >> Transport issues:
> >>
> >> Although this document has substantial implications for transport
> >> protocols, it does not significantly alter the content of RFC5766 in
> >> this regard. However, there is a significant gap as follows:
> >>
> >> - The direct translation of TCP into UDP or UDP into TCP is arguably
> >> a host endpoint emulation function, which strongly suggests that this
> >> document needs to explicitly address both receiving and transmitting
> transport options.
> >> transmission, that should be more directly stated – as well as the
> >> impact of that decision, both on functionality and security.
> >
> > The specification has two sections 14 and 15 (IP Header Fields for UDP-to-
> UDP translation and IP Header Fields for TCP-to-UDP translation) to discuss
> direct translations. https://tools.ietf.org/html/rfc5766 only covered UDP-to-
> UDP translation in Section 12.
> 
> Yes, but both sections ignore the impact of transport options - both current
> for TCP and pending for UDP. These are ignored both when packets with
> such transport options are received (the input packet to the translation) and
> whether / how they are used on transmit (the output packet)

TURN is used to relay real-time data (e.g. audio and video streams) and the approach taken by VOIP related specifications 
is to avoid fragmentation for RTP packets. 

> >> reassembly could be of benefit here in avoiding IP fragmentation, but
> >> that would be contingent on the previous note – i.e., being able to
> >> use and react to UDP options in the translation process.
> >
> The doc currently indicates that UDP relies only on IP fragmentation, but this
> isn’t the case with UDP options (there is a UDP-level frag and reassembly
> that preserves port numbers on each fragment and would thus be TURN-
> compatible).

Okay, I will add the following line:
However, Section 5.7 in https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-07 discusses Fragmentation option to support UDP fragmentation and
reassembly to transfer UDP messages larger than the IP receive MTU.

> 
> >
> >>
> >> Non-transport issues:
> >>
> >> Like RFC 5766, this doc continues to cite
> >> I-D.rosenberg-mmusic-ice-nonsip as guidance, even using a gentle
> >> version of “must”, but this no longer seems appropriate because that
> >> document has expired over a decade ago. Either the guidance should be
> >> summarized in this document or the recommendation should be removed.
> >
> > Good point, Revised ICE specification (https://tools.ietf.org/html/rfc8445)
> has been updated to make the procedures independent of the signaling
> protocol by removing the SIP and SDP procedures.
> >
> >> Section 2.7 is incorrect in its claim of 576 for IPv4; it confuses
> >> the receiver reassembly minimum (EMTU_R, 576) for the link MTU
> >> (EMTU_S, 68). See draft-ietf-tunnels for details. If 576 is the
> >> focus, at best it could be claimed that 576 is the “de-facto” EMTU_S for
> IPv4. Other nits:
> >
> > Section 2.7 says IPv4 host must be capable of receiving a packet whose
> length is equal to 576 bytes (EMTU_R, 576).

Got it, I will update the text as follows:

If IPv4 support on legacy or otherwise unusual networks is a
consideration, the application MAY assume on an effective MTU of 576 bytes for
IPv4 datagrams, as every IPv4 host must be capable of receiving a
packet whose length is equal to 576 bytes as discussed in [RFC0791] and [RFC1122].

Cheers,
-Tiru

> 
> >>
> >> Sec 23 indicates the changes since RFC5766; a similar section
> >> addressing changes since RFC6156 would be useful to add.
> >

---

From: Joe Touch <[email-masked]>
Date: Fri, 7 Jun 2019 05:22:15 -0400

On Jun 7, 2019, at 4:39 AM, Konda, Tirumaleswar Reddy <[email-masked]> wrote:

> is to avoid fragmentation for RTP packets

Sec 2.8 mentions RTP as one use case envisioned (at this point, it’d be fair to ask this revision to clarify whether that turned out to be true). But it isn’t indicated as the only use case. 

Regardless, though, this doesn’t impact the concern raised above. RTP could still employ transport options. 

And my concern on this point goes beyond the issue of fragmentation. It applies to any transport option that might be received and any that might be added in the converted transmission.

Joe

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 10 Jun 2019 06:43:27 +0000

Hi Joe,

Please see inline

> Sent: Friday, June 7, 2019 2:52 PM
> On Jun 7, 2019, at 4:39 AM, Konda, Tirumaleswar Reddy
> >> UDP translation and IP Header Fields for TCP-to-UDP translation) to
> >> discuss direct translations. https://tools.ietf.org/html/rfc5766 only
> >> covered UDP-to- UDP translation in Section 12.
> >>
> >> Yes, but both sections ignore the impact of transport options - both
> >> current for TCP and pending for UDP. These are ignored both when
> >> packets with such transport options are received (the input packet to
> >> the translation) and whether / how they are used on transmit (the
> >> output packet)
> >
> > TURN is used to relay real-time data (e.g. audio and video streams)
> > and the approach taken by VOIP related specifications is to avoid
> > fragmentation for RTP packets
> 
> Sec 2.8 mentions RTP as one use case envisioned (at this point, it’d be fair to
> ask this revision to clarify whether that turned out to be true). But it isn’t
> indicated as the only use case.

The draft says TURN is invented to support multimedia sessions signaled using SIP and is typically used with ICE. TURN is also used with WebRTC, and WebRTC data channels also 
avoid IP fragmentation (see https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13). 

> still employ transport options.

I checked again and don't see any RTP, Back-to-Back User Agents (B2BUAs), SIP proxies and WebRTC gateway specifications discussing transport options for translations.

Cheers,
-Tiru

> 
> And my concern on this point goes beyond the issue of fragmentation. It
> applies to any transport option that might be received and any that might be
> added in the converted transmission.
> 
> Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Jun 2019 07:28:54 -0700

Hi, Tiru,

> On Jun 9, 2019, at 11:43 PM, Konda, Tirumaleswar Reddy <[email-masked]> wrote:
> 
> avoid IP fragmentation (see https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13 <https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13>). 

The application protocols TURN is designed for or typically used for is not relevant to my point above, unless you’re claiming that these uses never use transport options (which is doubtful for TCP, for which some transport options are pervasively used by default).

> I checked again and don't see any RTP, Back-to-Back User Agents (B2BUAs), SIP proxies and WebRTC gateway specifications discussing transport options for translations.

The fact that others have this gap does not justify continuing to fail to address it in this document. If anything, it makes it that much more important to address.

Joe

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 11 Jun 2019 05:18:42 +0000

Hi Joe,

I meant the specifications that use TURN (ICE, SIP and WebRTC) do not discuss setting any TCP option for application data (RTP, RTCP and WebRTC data channels).  Please note TCP is only used as fallback transport only if UDP traffic is blocked to the TURN server.
TURN has been widely deployed in the field, and there was no discussion in the WG to explicitly handle TCP options.

Cheers,
-Tiru

From: Joe Touch <[email-masked]>
Sent: Monday, June 10, 2019 7:59 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
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 9, 2019, at 11:43 PM, Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>> wrote:

On Jun 7, 2019, at 4:39 AM, Konda, Tirumaleswar Reddy
<[email-masked]<mailto:[email-masked]>> wrote:

The specification has two sections 14 and 15 (IP Header Fields for
UDP-to-
UDP translation and IP Header Fields for TCP-to-UDP translation) to
discuss direct translations. https://tools.ietf.org/html/rfc5766 only
covered UDP-to- UDP translation in Section 12.

Regardless, though, this doesn’t impact the concern raised above. RTP could
still employ transport options.

Joe

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 11 Jun 2019 08:28:58 +0000

Hi Joe and Tiru,

May I hazard a guess why this have not arisen is that there are no transport protocol options that makes sense to use end-to-end and are not protocol specific. Thus, in UDP <-> TCP translations by TURN server there has so far not been a need to carry any of them over. Joe, can you think of any that would make sense?

For UDP <-> UDP the experimental proposal for UDP options I don't see that we can require this specification to have to specify that. I do think it is an interesting question for https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ if that should write more about what to do with the options when performing translation operations?

When it comes to RTP and RTCP that is widely used over TURN relays when those applications need extended functionality they have gone ahead and extended RTP/RTCP rather than attempting to affect lower layers where other entities than the end-points are required to be upgraded.

Cheers

Magnus

On 2019-06-11 07:20, Konda, Tirumaleswar Reddy wrote:
Hi Joe,

Cheers,
-Tiru

From: Joe Touch <[email-masked]><mailto:[email-masked]>
Sent: Monday, June 10, 2019 7:59 PM
To: Konda, Tirumaleswar Reddy <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Tsv-art] [tram] Tsvart last call review of draft-ietf-tram-turnbis-25

Joe

--

Magnus Westerlund

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]<mailto:[email-masked]>
----------------------------------------------------------------------

---

From: Joe Touch <[email-masked]>
Date: Tue, 11 Jun 2019 11:03:22 -0700

Hi, all,

Here are my key points:

- whether you deal with TCP options or simply ignore those on incoming connections and use defaults on outgoing, the issue needs to be addressed - as well as its impact on your use.
- UDP options are not experimental; they’re standards-track; it could be mentioned here non-normatively as a possible workaround to the IP fragmentation issue.

Finally, IMO, assuming that RTP/RTCP can or should provide extended functions that might already be provided by existing TCP options or emerging UDP options seems like both wasted effort and a failed opportunity to tune the transport as it was intended.

Overall, the point is that simply ignoring this issue is insufficient - at a minimum, this doc needs to clearly state that this issue is being ignored and why, as well as addressing that issue in the security sections.

Finally, I’m quite bothered by the glib idea that transport packets can simply be translated into each other either between two TCP connections or between TCP and UDP. The notion is simply false; TCP doesn’t preserve message boundaries and TCP segments are not guaranteed to match application message boundaries. 

I.e., the transport implications of this “hack” are inadequately addressed.

Joe

> On Jun 11, 2019, at 1:28 AM, Magnus Westerlund <[email-masked]> wrote:
> 
> Hi Joe and Tiru, 
> 
> For UDP <-> UDP the experimental proposal for UDP options I don't see that we can require this specification to have to specify that. I do think it is an interesting question for https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/> if that should write more about what to do with the options when performing translation operations? 
> 
>> From: Joe Touch <[email-masked]> <mailto:[email-masked]> 
>> To: Konda, Tirumaleswar Reddy <[email-masked]> <mailto:[email-masked]>
>> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>> On Jun 9, 2019, at 11:43 PM, Konda, Tirumaleswar Reddy <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>> <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> discuss direct translations. https://tools.ietf.org/html/rfc5766 <https://tools.ietf.org/html/rfc5766> only
> SE-164 80 Stockholm, Sweden | mailto: [email-masked] <mailto:[email-masked]>

---

From: Brandon Williams <[email-masked]>
Date: Tue, 11 Jun 2019 15:47:15 -0400

Hi Joe,

First, some clarification ... You stated.

> Finally, I’m quite bothered by the glib idea that transport packets
> simply be translated into each other either between two TCP
> connections or between TCP and UDP. The notion is simply false; TCP
> doesn’t preserve message boundaries and TCP segments are not
> guaranteed to match application message boundaries.

There is no TCP-to-TCP relay case here. The side opposite the TURN
client is always UDP, even if the remote client is also connected to a
TURN server. The two TURN servers would use UDP in between, and the two
TURN servers would not even know that the other one is there.

Also, the spec does not relay "packets" between TCP and UDP. TURN does
not rely on TCP to maintain message boundaries. Instead, a TURN TCP
connection frames messages within the stream and that message framing
allows the TURN server to maintain message boundaries when sending the
messages within UDP datagrams.

> Overall, the point is that simply ignoring this issue is insufficient
> - at a minimum, this doc needs to clearly state that this issue is
> being ignored and why, as well as addressing that issue in the
> security sections.

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?

Regarding UDP options, I agree with Magnus that it's probably better to
rely on tsvwg to state something about UDP option relay makes more
sense, considering that the UDP options draft isn't published yet. It's
unclear what could be said meaningfully in the TURN draft. If you have a
suggestion that might help.

Thanks,
--Brandon

On 6/11/19 2:03 PM, Joe Touch wrote:
> Hi, all,
> 
> Here are my key points:
> 
> - whether you deal with TCP options or simply ignore those on incoming
> connections and use defaults on outgoing, the issue needs to be
> addressed - as well as its impact on your use.
> - UDP options are not experimental; they’re standards-track; it could be
> mentioned here non-normatively as a possible workaround to the IP
> fragmentation issue.
> 
> Finally, IMO, assuming that RTP/RTCP can or should provide extended
> functions that might already be provided by existing TCP options or
> emerging UDP options seems like both wasted effort and a failed
> opportunity to tune the transport as it was intended.
> 
> Overall, the point is that simply ignoring this issue is insufficient -
> at a minimum, this doc needs to clearly state that this issue is being
> ignored and why, as well as addressing that issue in the security sections.
> 
> Finally, I’m quite bothered by the glib idea that transport packets can
> simply be translated into each other either between two TCP connections
> or between TCP and UDP. The notion is simply false; TCP doesn’t preserve
> message boundaries and TCP segments are not guaranteed to match
> application message boundaries. 
> 
>> On Jun 11, 2019, at 1:28 AM, Magnus Westerlund
>> <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> Hi Joe and Tiru,
>>
>> May I hazard a guess why this have not arisen is that there are no
>> transport protocol options that makes sense to use end-to-end and are
>> not protocol specific. Thus, in UDP <-> TCP translations by TURN
>> server there has so far not been a need to carry any of them over.
>> Joe, can you think of any that would make sense?
>>
>> For UDP <-> UDP the experimental proposal for UDP options I don't see
>> that we can require this specification to have to specify that. I do
>> think it is an interesting question for
>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ if that
>> should write more about what to do with the options when performing
>> translation operations?
>>
>> When it comes to RTP and RTCP that is widely used over TURN relays
>> when those applications need extended functionality they have gone
>> ahead and extended RTP/RTCP rather than attempting to affect lower
>> layers where other entities than the end-points are required to be
>> upgraded.
>>
>> Cheers
>>
>> Magnus
>>
>>
>>
>>
>>> I meant the specifications that use TURN (ICE, SIP and WebRTC) do not
>>> discuss setting any TCP option for application data (RTP, RTCP and
>>> WebRTC data channels).  Please note TCP is only used as fallback
>>> transport only if UDP traffic is blocked to the TURN server.
>>>
>>> TURN has been widely deployed in the field, and there was no
>>> discussion in the WG to explicitly handle TCP options.
>>>
>>>  
>>>
>>> Cheers,
>>>
>>> -Tiru
>>>
>>>  
>>>
>>> *From:* Joe Touch <[email-masked]>
>>> *Sent:* Monday, June 10, 2019 7:59 PM
>>> *To:* Konda, Tirumaleswar Reddy <[email-masked]>
>>> *Cc:* [email-masked]; [email-masked];
>>> [email-masked]; [email-masked]
>>> *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 9, 2019, at 11:43 PM, Konda, Tirumaleswar Reddy
>>>     <[email-masked]
>>>     <mailto:[email-masked]>> wrote:
>>>
>>>      
>>>
>>>         <[email-masked]
>>>         <mailto:[email-masked]>> wrote:
>>>
>>>
>>>                 discuss direct translations.
>>>                 https://tools.ietf.org/html/rfc5766
>>>                 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5766&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=wlJBA0wCj1jIz4f3RegWs8USi6_gsk3fo6HsaHNmDwE&s=zpNv5YDpI2-wPNhWSnCb1VsidyMEg7LYQdn6IeLqdg4&e=>
>>>                 only
>>>     The draft says TURN is invented to support multimedia sessions
>>>     signaled using SIP and is typically used with ICE. TURN is also
>>>     used with WebRTC, and WebRTC data channels also 
>>>     avoid IP fragmentation
>>>     (see https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Drtcweb-2Ddata-2Dchannel-2D13&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=wlJBA0wCj1jIz4f3RegWs8USi6_gsk3fo6HsaHNmDwE&s=II1OEcj0VllH4yVwB5IyIB0KKiXf42ScemFtYoXUQts&e=>). 
>>>
>>>  
>>>
>>> The application protocols TURN is designed for or typically used for
>>> is not relevant to my point above, unless you’re claiming that these
>>> uses never use transport options (which is doubtful for TCP, for
>>> which some transport options are pervasively used by default).
>>>
>>>
>>>
>>>
>>>
>>>
>>>     I checked again and don't see any RTP, Back-to-Back User Agents
>>>     (B2BUAs), SIP proxies and WebRTC gateway specifications
>>>     discussing transport options for translations.
>>>
>>>  
>>>
>>> The fact that others have this gap does not justify continuing to
>>> fail to address it in this document. If anything, it makes it that
>>> much more important to address.
>>>
>>>  
>>>
>>> Joe
>>>
>>
>> -- 
>>
>> Magnus Westerlund 
>>
>> SE-164 80 Stockholm, Sweden | mailto: [email-masked]
>> [email-masked] <mailto:[email-masked]>

-- 
Brandon Williams
Platform Engineering
Akamai Technologies Inc.

---

From: Joe Touch <[email-masked]>
Date: Tue, 11 Jun 2019 15:04:52 -0700

Hi, Brandon,

> On Jun 11, 2019, at 12:47 PM, Brandon Williams <[email-masked]> wrote:
> 
> Hi Joe,
> 

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 description above in this email implies you’re just receiving “application” messages on one transport and emitting them on another. That makes a lot more sense, but it’s inconsistent with the description in this doc.

> (D)TLS cannot be used for this purpose either? If not that, what else do

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

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)

- address how your endpoint deals with TCP options that might have impact, including TCP multiparty, AO, ENO, MD5, fastopen, and user timeout

> suggestion that might help.

The intro to Sec 2.7 could be as follows (clarifying the way in which the IP frag avoidance is introduced as well):

   For reasons described in [Frag-Harmful], applications, especially
   those sending large volumes of data, should try hard to avoid having
   their packets fragmented.  Applications using TCP can more or less
   ignore this issue because fragmentation avoidance is now a standard
   part of TCP, but applications using UDP (and thus any application
   using this version of TURN) need to avoid IP fragmentation by sending
   sufficiently small messages or use UDP fragmentation [draft-ietf-tsvwg-udp-options].

   The application running on the client and the peer can take one of
   two approaches to avoid IP fragmentation until UDP fragmentation support is available. The first
   uses messages that are limited to a predetermined fixed maximum and the second
   relies on network feedback to adapt that maximum.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 13 Jun 2019 08:42:56 +0000

Hi Joe,

Please see inline

> Sent: Wednesday, June 12, 2019 3:35 AM
> To: Brandon Williams <[email-masked]>
> Cc: Magnus Westerlund <[email-masked]>; tsv-
> [email-masked]; Konda, Tirumaleswar Reddy
> <[email-masked]>; draft-ietf-tram-
> [email-masked]; [email-masked]; [email-masked]
> > TURN server. The two TURN servers would use UDP in between, and the
> > two TURN servers would not even know that the other one is there.
> >
> 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.

> 
> The description above in this email implies you’re just receiving “application”
> messages on one transport and emitting them on another. That makes a lot
> more sense, but it’s inconsistent with the description in this doc.
> 
> >
> > 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.  

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

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

> 
> >
> > Regarding UDP options, I agree with Magnus that it's probably better
> > to rely on tsvwg to state something about UDP option relay makes more
> > sense, considering that the UDP options draft isn't published yet.
> > It's unclear what could be said meaningfully in the TURN draft. If you
> > have a suggestion that might help.
> 

The proposed text looks good, will update draft.

Cheers,
-Tiru

> >> - whether you deal with TCP options or simply ignore those on
> >> incoming connections and use defaults on outgoing, the issue needs to
> >> be addressed - as well as its impact on your use.
> >> - UDP options are not experimental; they’re standards-track; it could
> >> be mentioned here non-normatively as a possible workaround to the IP
> >> fragmentation issue.
> >>
> >> being ignored and why, as well as addressing that issue in the security
> sections.
> >>
> >> can simply be translated into each other either between two TCP
> >>> transport protocol options that makes sense to use end-to-end and
> >>> are not protocol specific. Thus, in UDP <-> TCP translations by TURN
> >>> For UDP <-> UDP the experimental proposal for UDP options I don't
> >>> see that we can require this specification to have to specify that.
> >>> I do think it is an interesting question for
> >>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ if
> >>> that should write more about what to do with the options when
> >>> performing translation operations?
> >>>
> >>>> I meant the specifications that use TURN (ICE, SIP and WebRTC) do
> >>>> not discuss setting any TCP option for application data (RTP, RTCP
> >>>> and WebRTC data channels).  Please note TCP is only used as
> >>>> fallback transport only if UDP traffic is blocked to the TURN server.
> >>>>
> >>>>                <https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_rfc5766&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg
> &r=bwZ-nnRGWmcGKRIuadq6-
> NSnsgwbBVUJa4mZfmEIBXg&m=wlJBA0wCj1jIz4f3RegWs8USi6_gsk3fo6Hsa
> HNmDwE&s=zpNv5YDpI2-wPNhWSnCb1VsidyMEg7LYQdn6IeLqdg4&e=>
> >>>>                only
> >>>>    (see https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13
> <https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_draft-2Dietf-2Drtcweb-2Ddata-2Dchannel-
> 2D13&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-
> nnRGWmcGKRIuadq6-
> NSnsgwbBVUJa4mZfmEIBXg&m=wlJBA0wCj1jIz4f3RegWs8USi6_gsk3fo6Hsa
> HNmDwE&s=II1OEcj0VllH4yVwB5IyIB0KKiXf42ScemFtYoXUQts&e=>).
> >>>>
> >>>>
> >>>>
> >>>> The application protocols TURN is designed for or typically used
> >>>> for is not relevant to my point above, unless you’re claiming that
> >>>> these uses never use transport options (which is doubtful for TCP,
> >>>> for which some transport options are pervasively used by default).
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>> --------------------------------------------------------------------
> >>> -- Network Architecture & Protocols, Ericsson Research
> >>> --------------------------------------------------------------------
> >>> -- _______________________________________________
> >>> Tsv-art mailing list

---

From: Joe Touch <[email-masked]>
Date: Thu, 13 Jun 2019 07:17:02 -0700

Hi, Tiru,

> On Jun 13, 2019, at 1:42 AM, Konda, Tirumaleswar Reddy <[email-masked]> wrote:
> 
>> ...

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

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

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

> 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

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 14 Jun 2019 07:49:26 +0000

Hi Jon,

Please see inline [TR]

From: Joe Touch <[email-masked]>
Sent: Thursday, June 13, 2019 7:47 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>
Cc: Brandon Williams <[email-masked]>; Magnus Westerlund <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Tsv-art] [tram] Tsvart last call review of draft-ietf-tram-turnbis-25

On Jun 13, 2019, at 1:42 AM, Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>> wrote:

...

[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

….

[TR] Glad to see we are making progress ☺

- adjust your description of how you relay messages to talk about things at
the “application” layer

[TR] Got it, will update draft.

[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

---

From: Joe Touch <[email-masked]>
Date: Sat, 15 Jun 2019 11:52:11 -0700

On 6/14/2019 12:49 AM, Konda, Tirumaleswar Reddy wrote:
> *Sent:* Thursday, June 13, 2019 7:47 PM
> *Cc:* Brandon Williams <[email-masked]>; Magnus
> Westerlund <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
>     On Jun 13, 2019, at 1:42 AM, Konda, Tirumaleswar Reddy
>     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.

>     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.
>      
>
>  
>
> [TR] Glad to see we are making progress J
>
>
>
>     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
> 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.
>
>  
>
>     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

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 17 Jun 2019 10:30:21 +0000

Hi Joe,

Please see inline [TR1]

Sent: Sunday, June 16, 2019 12:22 AM

Please see inline [TR]

Cc: Brandon Williams <[email-masked]><mailto:[email-masked]>; Magnus Westerlund <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

...

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

….

[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

Cheers,
-Tiru

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 17 Jun 2019 07:18:11 -0700

> On Jun 17, 2019, at 3:30 AM, Konda, Tirumaleswar Reddy <[email-masked]> wrote:
> 
> Hi Joe,
>  
> Please see inline [TR1]
>  …

> On Jun 13, 2019, at 1:42 AM, Konda, Tirumaleswar Reddy <[email-masked] <mailto:[email-masked]>> wrote:
>  
> ...
> [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 seehttps://tools.ietf.org/html/draft-ietf-tram-turnbis-25#section-15 <https://tools.ietf.org/html/draft-ietf-tram-turnbis-25#section-15>
> [TR1] Section 15 discusses both IP fragmentation and IP options, see https://tools.ietf.org/html/draft-ietf-tram-turnbis-25#section-15 <https://tools.ietf.org/html/draft-ietf-tram-turnbis-25#section-15>It does, but incorrectly implies these are per packet decisions. As with that section’s description of DSCP, the descriptions of IP fragmentation and IP options need to indicate these are either not under user control (IP fragmentation) or per-connection (IP options) for TCP.

Again, despite claims of intent, this document’s description of all these translations inappropriately implies they are per-packet decisions throughout. This should further be corrected with some explicit text indicating otherwise - as has been noted throughout this thread.

Joe

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 18 Jun 2019 08:31:10 +0000

Hi Joe,

Please see inline [TR2]

From: tram <[email-masked]<mailto:[email-masked]>> On Behalf Of Joe Touch
Sent: Monday, June 17, 2019 7:48 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>
Cc: Magnus Westerlund <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Brandon Williams <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [tram] [Tsv-art] Tsvart last call review of draft-ietf-tram-turnbis-25

On Jun 17, 2019, at 3:30 AM, Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>> wrote:

Hi Joe,

Please see inline [TR1]
 …

...

[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 seehttps://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
It does, but incorrectly implies these are per packet decisions. As with that section’s description of DSCP, the descriptions of IP fragmentation and IP options need to indicate these are either not under user control (IP fragmentation) or per-connection (IP options) for TCP.

[TR2] No, the section does not say per-packet translations. Please see the below snip from Section 15
<snip>
      Preferred Behavior: When the server sends a packet to a peer in
      response to a Send indication containing the DONT-FRAGMENT
      attribute, then set the DF bit in the outgoing IP header to 1.  In
      all other cases when sending an outgoing packet containing
      application data (e.g., Data indication, ChannelData message, or
      DONT-FRAGMENT attribute not included in the Send indication), set
      the DF bit in the outgoing IP header to 0.
</snip>

[TR2] I will add the following line to avoid confusion:

Note that the server does not preform per-packet translation for TCP-to-UDP translation and vice-versa. The TURN server sets various fields in the IP header based on the DONT-FRAGMENT attribute in the TURN message and on a per-connection basis for the TCP connection.

Cheers,
-Tiru

Joe

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 18 Jun 2019 11:27:13 +0000

On 2019-06-17 12:44, Konda, Tirumaleswar Reddy wrote:

Sorry, I find this very confusing. On the Client to TURN Server leg if that is using a TCP connection, then there are no issues with using either TCP-MP or TCP-AO options on that leg. They will have no impact on the TURN messages carried inside the TCP connection or how its outgoing IP/UDP packet. So from my perspective there are no necessity to discuss these as not supported.

What is discussed in this document are the options for the IP/UDP packet being sent or received by the turn server to the peer. Those IP/UDP Fields that can be controlled and have meaning are discussed here. Like the DSCP, where TCP will force the use of a single one, when UDP to UDP can support many as the field value is taken from the packet on the client to server leg, rather than an internal TURN message field.

I guess the issue here is that there is a lack of requirement making clear that for a number of the fields in the IP/UDP handled on the server to peer leg that needs to handling rules for the client to server transport.

I think what Section 14 and 15 talks about should be labeled relaying and not translation. And thus focus on how one avoid information or intent loss in the relay process. I understand why section 13 is called translation, but when we get down to it, it is the same here, but a focus on how the relay process maintain information of the IP layer, especially in the face of address family differences.

Cheers

Magnus Westerlund

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 18 Jun 2019 13:03:51 +0000

HI Magnus,

Please see inline [TR]

From: tram <[email-masked]> On Behalf Of Magnus Westerlund
Sent: Tuesday, June 18, 2019 4:57 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Joe Touch <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Brandon Williams <[email-masked]>; [email-masked]
Subject: Re: [tram] [Tsv-art] Tsvart last call review of draft-ietf-tram-turnbis-25

[TR] The comment from Joe is : if TCP-AO is used, application data is authenticated in the TCP leg but the data can be faked when relayed from the server to the peer using UDP. I tried to address this comment by saying if secure application data (SRTP) is used message authentication is available at the application layer even if UDP does not support authentication option.

[TR] Agreed, replaced translation with relaying in both sections 14 and 15.

-Tiru

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 18 Jun 2019 13:47:40 +0000

On 2019-06-18 15:11, Konda, Tirumaleswar Reddy wrote:
HI Magnus,

Please see inline [TR]

From: tram <[email-masked]><mailto:[email-masked]> On Behalf Of Magnus Westerlund
Sent: Tuesday, June 18, 2019 4:57 PM
To: Konda, Tirumaleswar Reddy <[email-masked]><mailto:[email-masked]>; Joe Touch <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Brandon Williams <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [tram] [Tsv-art] Tsvart last call review of draft-ietf-tram-turnbis-25

Sure, but this is equivalent to the case of TURN over TCP/TLS that also only have the security model to the middle. So pointing that aspect out is fine, but I think TURN is quite clear on that client to peer security are the responsibility of the end-to-end application using TURN. Like the statement in the Third paragraph of 20.1.4:

   These attacks are more properly mitigated by application-layer
   authentication techniques.  In the case of real-time traffic, usage
   of SRTP [RFC3711] prevents these attacks.

If I understand Joe's comments, I think a core part of this discussion is that the introduction to section 14 and 15 don't make it clear the purpose of these section is to define which information that needs to be preserved in the relay, and which doesn't not and in that case what are appropriate behaviors.

Cheers

Magnus Westerlund

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Jun 2019 07:24:15 -0700

Notes below.

> On Jun 18, 2019, at 6:03 AM, Konda, Tirumaleswar Reddy <[email-masked]> wrote:
> 
> HI Magnus,
>  
> Please see inline [TR]
>  
> From: tram <[email-masked] <mailto:[email-masked]>> On Behalf Of Magnus Westerlund
> To: Konda, Tirumaleswar Reddy <[email-masked] <mailto:[email-masked]>>; Joe Touch <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Brandon Williams <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
I’m not weighing in on whether they’re supported or not, but support needs to be discussed one way or the other.
> [TR] Agreed, replaced translation with relaying in both sections 14 and 15.
That would help, but it’s more than just replacing a single word.

The way in which those sections discuss IP options is misleading. It should talk about them more clearly in terms of individual UDP messages and TCP connections, not in terms of ‘ when you get this TURN message, here’s how to set these values in IP packets” - because the latter (even if not a direct quote) is misleading in implying these settings can change throughout a TCP connection.

I agree that presenting this as relaying would be much more clear, but it affects more than a simple word change.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Jun 2019 07:30:25 -0700

See end...

> On Jun 18, 2019, at 1:31 AM, Konda, Tirumaleswar Reddy <[email-masked]> wrote:
> 
> Hi Joe,
>  
> Please see inline [TR2]
>  
> From: tram <[email-masked] <mailto:[email-masked]>> On Behalf Of Joe Touch
> To: Konda, Tirumaleswar Reddy <[email-masked] <mailto:[email-masked]>>
> Cc: Magnus Westerlund <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Brandon Williams <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> On Jun 17, 2019, at 3:30 AM, Konda, Tirumaleswar Reddy <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Joe,
>  
> Please see inline [TR1]
>  …
> 
> 
> [TR1] Section 15 discusses both IP fragmentation and IP options, see https://tools.ietf.org/html/draft-ietf-tram-turnbis-25#section-15 <https://tools.ietf.org/html/draft-ietf-tram-turnbis-25#section-15>

Loosely restated, this says:
	
	when you get TURN message X, set the IP header as follows

That implies that each TURN message affects a single IP header. That implies packet translation, not content relay - especially because it cannot work for TCP content relay, where IP options cannot be controlled  mid-connection on a per-user-message basis....

> Note that the server does not preform per-packet translation for TCP-to-UDP translation and vice-versa.

That seems reasonable, but….

> The TURN server sets various fields in the IP header based on the DONT-FRAGMENT attribute in the TURN message and on a per-connection basis for the TCP connection.

That’s still confusing.

You’re not setting IP header values; you’re setting TCP or UDP parameters (which you hope will affect IP values).

Is this also based on the DF attribute in the TURN message, or would it be equally valid (and much more clear) to say that it is based on the DF value of a **TURN session***? I.e., what happens if you receive more than one TURN message with different DF parameters (itor if this is strictly prohibited, please cite where that is mandated).

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Jun 2019 07:32:35 -0700

> On Jun 18, 2019, at 6:47 AM, Magnus Westerlund <[email-masked]> wrote:
> 

FWIW, even with this statement, if you’re going to talk about preserving IP options and settings then it’s equally important to discuss how you preserve or interfere with TCP options and settings - and maybe other layers like TLS too - in the same place in the document.

It’s not just whether this is a security issue; it’s that the semantics are broken in half.

Joe

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 19 Jun 2019 13:16:42 +0000

Hi Joe,

Please see inline [TR3]

From: Joe Touch <[email-masked]>
Sent: Tuesday, June 18, 2019 8:00 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>
Cc: Magnus Westerlund <[email-masked]>; [email-masked]; Brandon Williams <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Tsv-art] [tram] Tsvart last call review of draft-ietf-tram-turnbis-25

On Jun 18, 2019, at 1:31 AM, Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>> wrote:

Hi Joe,

Please see inline [TR2]

Hi Joe,

Please see inline [TR1]
 …

...

[TR3] The above text is only for TCP-to-UDP relay, DF bit will be set in the outgoing UDP packet. The specification does not support TCP-to-TCP relay.

That’s still confusing.

[TR3] For TCP-to-UDP relay, the DF attribute in the TURN message will be used to set the DF bit in the outgoing UDP packet to the peer. I will re-phrase the text as follows:

Note that the server does not perform per-packet translation for TCP-to-UDP relay and vice-versa. For TCP-to-UDP relay, the TURN server sets the DF field in the outgoing UDP packet based on the presence of DONT-FRAGMENT attribute in the TURN message. For UDP-to-TCP relay, the TURN server sets various IP header fields in the TCP packets on a per-connection basis for the TCP connection.

Cheers,
-Tiru

Joe

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 19 Jun 2019 13:24:42 +0000

Hi Joe,

I have added the following lines to address your comment:

   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] or TLS, 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.  Attacker attempting to spoof in fake data is discussed in
   Section 20.1.4.  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 the TURN is the use of RTP
   control protocol (RTCP).  As a reminder, RTCP is a fundamental and
   integral part of RTP.

Cheers,
-Tiru

From: Joe Touch <[email-masked]>
Sent: Tuesday, June 18, 2019 8:03 PM
To: Magnus Westerlund <[email-masked]>
Cc: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; Brandon Williams <[email-masked]>; [email-masked]
Subject: Re: [Tsv-art] [tram] Tsvart last call review of draft-ietf-tram-turnbis-25

On Jun 18, 2019, at 6:47 AM, Magnus Westerlund <[email-masked]<mailto:[email-masked]>> wrote:

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Jun 2019 07:20:34 -0700

Hi, Tiru,

You still appear to be ignoring the issue about implying per-packet adjustment of IP options and parameters during a TCP connection, in specific.

Joe

> On Jun 19, 2019, at 6:24 AM, Konda, Tirumaleswar Reddy <[email-masked]> wrote:
> 
> Hi Joe,
>  
> From: Joe Touch <[email-masked] <mailto:[email-masked]>> 
> To: Magnus Westerlund <[email-masked] <mailto:[email-masked]>>
> Cc: Konda, Tirumaleswar Reddy <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Brandon Williams <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> On Jun 18, 2019, at 6:47 AM, Magnus Westerlund <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 19 Jun 2019 14:30:55 +0000

Hi Joe,

I have added the following line to address your other comment:

Note that the server does not perform per-packet translation for TCP-to-UDP relaying and vice-versa. For TCP-to-UDP relaying from client to peer, the TURN server sets the DF field in the outgoing UDP packet based on the presence of DONT-FRAGMENT attribute in the TURN message. For UDP-to-TCP relaying from peer to client, the TURN server sets IP header fields in the TCP packets on a per-connection basis for the TCP connection.

Cheers,
-Tiru

From: Joe Touch <[email-masked]>
Sent: Wednesday, June 19, 2019 7:51 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>
Cc: Magnus Westerlund <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; Brandon Williams <[email-masked]>; [email-masked]
Subject: Re: [Tsv-art] [tram] Tsvart last call review of draft-ietf-tram-turnbis-25

Joe

On Jun 19, 2019, at 6:24 AM, Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>> wrote:

Hi Joe,

Cheers,
-Tiru

From: Joe Touch <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, June 18, 2019 8:03 PM
To: Magnus Westerlund <[email-masked]<mailto:[email-masked]>>
Cc: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Brandon Williams <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Tsv-art] [tram] Tsvart last call review of draft-ietf-tram-turnbis-25

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Jun 2019 07:42:58 -0700

That text remains insufficient, e.g.:

> On Jun 19, 2019, at 7:30 AM, Konda, Tirumaleswar Reddy <[email-masked]> wrote:
> 
> Hi Joe,
>  

Which parameters? Based on what?

In addition, a mere note does not undo the implication of indicating each IP parameter (option, DF) separately as if there are always configurable per-TURN message.

Joe

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 19 Jun 2019 14:48:38 +0000

Hi Joe,

Please see inline

Sent: Wednesday, June 19, 2019 8:13 PM

On Jun 19, 2019, at 7:30 AM, Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>> wrote:

Hi Joe,

[TR] It is already discussed in section 15.

<snip>

   Differentiated Services Code Point (DSCP) field [RFC2474<https://tools.ietf.org/html/rfc2474>]

      Preferred Behavior: Set the outgoing value to the incoming value,
      unless the server includes a differentiated services classifier
      and marker [RFC2474<https://tools.ietf.org/html/rfc2474>].  Note, the TCP connection can only use a
      single DSCP code point so inter flow differentiation is not
      possible, see Section 5.1 of [RFC7657]<https://tools.ietf.org/html/rfc7657#section-5.1>.

   Fragmentation

      Preferred Behavior: Any fragmented packets are reassembled in the

      server and then forwarded to the client over the TCP connection.

      ICMP messages resulting from the UDP datagrams sent to the peer

      MUST be forwarded to the client using TURN's mechanism for

      relevant ICMP types and codes.

   IPv4 Options

      Preferred Behavior: The outgoing packet is sent without any IPv4
      options.

</snip>

-Tiru

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Jun 2019 07:59:24 -0700

That fragmentation text is fine; the text on IPv4 and IPv6 fragmentation that appears earlier in Sec 15 is the issue.

Can you just drop that earlier text?

Joe

> On Jun 19, 2019, at 7:48 AM, Konda, Tirumaleswar Reddy <[email-masked]> wrote:
> 
> Hi Joe,
>  
> Please see inline
>  
> Cc: Magnus Westerlund <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Brandon Williams <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> On Jun 19, 2019, at 7:30 AM, Konda, Tirumaleswar Reddy <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Joe,
>  
>    Differentiated Services Code Point (DSCP) field [RFC2474 <https://tools.ietf.org/html/rfc2474>]
>  
>       and marker [RFC2474 <https://tools.ietf.org/html/rfc2474>].  Note, the TCP connection can only use a
>       possible, see Section 5.1 of [RFC7657] <https://tools.ietf.org/html/rfc7657#section-5.1>.
>  
>    Fragmentation
>  
> https://www.ietf.org/mailman/listinfo/tsv-art <https://www.ietf.org/mailman/listinfo/tsv-art>

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 19 Jun 2019 15:14:02 +0000

Hi Joe,

The IPv4 and IPv6 fragmentation description is specific to TCP-to-UDP relaying between the client and the peer (only for TCP-to-UDP relay, the DF attribute in the TURN message will be used to set the DF bit in the outgoing UDP packet to the peer). To avoid confusion, I have added two new sub-sections:
15.1.  IP Header Fields for TCP-to-UDP relaying and 15.2 IP Header Fields for UDP-to-TCP relaying

Please see the attached updated draft.

Cheers,
-Tiru

From: Joe Touch <[email-masked]>
Sent: Wednesday, June 19, 2019 8:29 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>
Cc: Magnus Westerlund <[email-masked]>; [email-masked]; Brandon Williams <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Tsv-art] [tram] Tsvart last call review of draft-ietf-tram-turnbis-25

Joe

On Jun 19, 2019, at 7:48 AM, Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>> wrote:

Hi Joe,

Please see inline

Cc: Magnus Westerlund <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Brandon Williams <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi Joe,

<snip>

   Fragmentation

   IPv4 Options

</snip>

-Tiru

Joe
_______________________________________________
Tsv-art mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tsv-art

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Jun 2019 17:29:34 -0700

Tiru,

This sort of patch isn’t sufficient. It doesn’t address the confusion throughout section 15 as to what’s actually happening.

Sec 15 shouldn’t talk about “setting” IP header values at all; it should refer to “configuring transport sessions” in the desired ways. Otherwise you’re implying direct packet-level conversion. Even the title of that section is a problem in this regard.

Tthe sections themselves should be revised to similarly refer to transport-level actions, not packet level, e.g.:
15.1 TCP to UDP
	- because DSCP should not vary within a TCP session, there is no packet-level tracking of copying DSCP from TCP to UDP; instead, DSCP would be a property of the TCP session that would be used to configure the UDP socket pair.
	- IP fragmentation control needs to be explained in terms of UDP interactions
	- IPv6 fragmentation has nothing to do with the received packet (which is TCP
	- IP options are *as default*; it’ isn’t correct that you never use IP options (or are you actively disabling them?)
		NOTE: that goes for the direct IPv4 to IPv6 translation in section 4 (which is similarly problematic)

15.2 UDP to TCP
	- the last sentence of the second paragraph seems at odds with the first; the first says “set these once per connection”, it is sufficient IMO.
	-TCP DSCP should be based on the *first* UDP value seen (it could vary)
	- same issue with IP extension headers and options (presumably you use the default

Joe

> On Jun 19, 2019, at 8:14 AM, Konda, Tirumaleswar Reddy <[email-masked]> wrote:
> 
> Hi Joe,
>

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 20 Jun 2019 10:46:08 +0000

Hi Joe,

Please see inline [TR]

Sent: Thursday, June 20, 2019 6:00 AM

[TR] What title do you want me to use for Section 15 ?

[TR] Agreed, but the text looks correct to me. It says “Note, the TCP connection can only use a single DSCP code point so inter flow differentiation is not possible”.

[TR] Yes, DONT-FRAGMENT attribute in the TURN message is used to set the DF bit in the outgoing IP header to 1. What specific change are you expecting ?

[TR] Same as above,  DONT-FRAGMENT attribute in the TURN message is used to set the DF bit in the outgoing IP header to 1.

[TR]   I am not aware of default IPv4 options and extension headers, and I don’t see any default IPv4 options discussed in https://tools.ietf.org/html/rfc6274. What IP4 options and IPv6 extension headers are default ?
          RTP/RTCP do not use any IPv4 options and IPv6 extension headers. What is the loss of functionality if IP options and extension headers are not set by the TURN server for outgoing UDP packets to the peer ?

15.2 UDP to TCP

[TR] Okay, removed the last sentence of the second paragraph.

[TR] No, the client first establishes TCP connection with the server and exchanges TURN messages for allocation and permission, UDP packets can only be sent by the peer after permission is created. Please see https://tools.ietf.org/html/rfc7657#section-5.3

Cheers,
-Tiru

Joe

On Jun 19, 2019, at 8:14 AM, Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>> wrote:

Hi Joe,

Cheers,
-Tiru

---

From: Joe Touch <[email-masked]>
Date: Thu, 20 Jun 2019 23:04:23 -0700

Hi, Tiru,

> On Jun 20, 2019, at 3:46 AM, Konda, Tirumaleswar Reddy <[email-masked]> wrote:
> 
> Hi Joe,
>  
> Please see inline [TR]
> ...

Sec 14 could be “UDP relay”

Sec 15 could be “Mixed transport relay” or “TCP/UDP and UDP/TCP relay”

In both cases, the issue isn’t to focus on the IP header fields.

> [TR] Agreed, but the text looks correct to me. It says “Note, the TCP connection can only use a single DSCP code point so inter flow differentiation is not possible”.   

It’s not a note. It’s the point. You don’t set the outgoing to the incoming per se; you set the *TCP connection* to use the DSCP of the first UDP packet.

> [TR] Yes, DONT-FRAGMENT attribute in the TURN message is used to set the DF bit in the outgoing IP header to 1. What specific change are you expecting ?

Again, you’re talking about building a network layer packet header. The point is that you should be describing this in terms of “setting the UDP packet to not fragment”. That is NOT merely IP DF=1; that would only prevent *in-network* fragmentation. You need to tell UDP not to source fragment too.

And all of this should be described in a way that doesn’t imply that the only approach is to have the user build the packet all the way to the IP headers.

Here’s why it matters - an IPv4 packet can *already be source fragmented* and still have the individual fragments set DF=0. DF=0 just means the *network* should not sub-fragment what it receives, not that the packet is “atomic” (not fragmented a the source AND not fragmentable by the network)

> [TR] Same as above,  DONT-FRAGMENT attribute in the TURN message is used to set the DF bit in the outgoing IP header to 1.

The server doesn’t ignore the the fragment fields of the received packets; it uses them to reassemble (by the IP stack). They are ignored in terms of whether to set the *transport* to avoid UDP using source fragmentation. Again, though, this isn’t about setting IP header fields.

> [TR]   I am not aware of default IPv4 options and extension headers, and I don’t see any default IPv4 options discussed inhttps://tools.ietf.org/html/rfc6274 <https://tools.ietf.org/html/rfc6274>. What IP4 options and IPv6 extension headers are default ?

By “default” I’m referring to system-wide configurations to use particular IP options. Your description appears to prevent their use; are you actively prohibiting all IP options? Even system-wide defaults, if so configured?

>           RTP/RTCP do not use any IPv4 options and IPv6 extension headers. What is the loss of functionality if IP options and extension headers are not set by the TURN server for outgoing UDP pack…

You would be expecting the transport to override a system-wide network default, which may not be possible on some systems.

You can probably just say “use system defaults”.

> [TR] No, the client first establishes TCP connection with the server and exchanges TURN messages for allocation and permission, UDP packets can only be sent by the peer after permission is created. Please seehttps://tools.ietf.org/html/rfc7657#section-5.3 <seehttps://tools.ietf.org/html/rfc7657#section-5.3>
OK, but then you need to say *in this section* how you expect to set the TCP DSCP. The text is confusing - it talks about “server-to-client” matching “client-to-server” - that’s just the other direction of the same TCP connection. If you are referring to other endpoints or transport protocols, be specific and clear. 

> On Jun 19, 2019, at 8:14 AM, Konda, Tirumaleswar Reddy <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Joe,
>

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 21 Jun 2019 09:35:03 +0000

Hi Joe,

Please see inline [TR1]

Sent: Friday, June 21, 2019 11:34 AM

On Jun 20, 2019, at 3:46 AM, Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>> wrote:

Hi Joe,

Please see inline [TR]
...

[TR1] Okay. Updated Section 14 title  to “UDP-to-UDP relay”, Section 15 “TCP-to-UDP relay” and added new Section 16 “UDP-to-TCP relay”

[TR1] Agreed, updated text as follows:

      The TCP connection can only use a single DSCP
      code point so inter flow differentiation is not possible, see
      Section 5.1 of [RFC7657].  The server sets the outgoing value to
      the DSCP code point used by the TCP connection, unless the server
      includes a differentiated services classifier and marker
        [RFC2474].

[TR1] Got it, Thanks for the clarification. Updated text as follows:
When the server sends a packet to a peer in response to a Send indication containing the DONT-FRAGMENT attribute, then set the outgoing UDP packet to not fragment.

[TR1] Okay, fixed as follows:
If the TCP traffic arrives over IPv6, the server relies on the presence of DON’T-FRAGMENT attribute in the send indication to set the outgoing UDP packet to not fragment.

[TR]   I am not aware of default IPv4 options and extension headers, and I don’t see any default IPv4 options discussed inhttps://tools.ietf.org/html/rfc6274. What IP4 options and IPv6 extension headers are default ?

[TR1] No, system defaults are not prohibited.

[TR1] Works for me, updated both IPv4 option and IPv6 extension headers in all sections.

15.2 UDP to TCP

[TR] No, the client first establishes TCP connection with the server and exchanges TURN messages for allocation and permission, UDP packets can only be sent by the peer after permission is created. Please seehttps://tools.ietf.org/html/rfc7657#section-5.3

[TR] I will modify the text as follows:
Ignore the incoming DSCP value. When TCP  is used between the client and the server, a single DSCP should be used for all traffic on that TCP connection. Note, TURN/ICE occurs before application data is exchanged.

-Tiru

Cheers,
-Tiru

Joe

Hi Joe,

Cheers,
-Tiru

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 24 Jun 2019 18:36:38 -0500

Sorry to jump in and hijack the middle of a different thread, but...

>    using UDP.  Attacker attempting to spoof in fake data is discussed in

... this kind of cross-layer security requirement ("if you were using
TCP-layer protection, now you have to impose a requirement on the
application protocol (stack) at a higher layer") has been quite problematic
in the past when attempted for other protocols.  Consider this early
warning that it will get a careful security area review during IESG
evaluation, if not sooner.  Being very specific about which component of
the system has what requirements under which conditions would be helpful,
as a start.

-Ben

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 25 Jun 2019 10:00:06 +0000

> From: Benjamin Kaduk <[email-masked]>
> Sent: Tuesday, June 25, 2019 5:07 AM
> Cc: Joe Touch <[email-masked]>; Magnus Westerlund
> <[email-masked]>; [email-masked]; draft-ietf-tram-
> [email-masked]; [email-masked]; Brandon Williams
> <[email-masked]>; [email-masked]
> ... this kind of cross-layer security requirement ("if you were using TCP-layer
> protection, now you have to impose a requirement on the application
> protocol (stack) at a higher layer") has been quite problematic in the past
> when attempted for other protocols.  Consider this early warning that it will
> get a careful security area review during IESG evaluation, if not sooner.  Being
> very specific about which component of the system has what requirements
> under which conditions would be helpful, as a start.

Good point. I did not think from that angle, will re-phrase the text as follows  :

TCP connection between the TURN client and server can use TCP-AO [RFC5925] but UDP does not provide a similar type of authentication until UDP supports authentication option. Regardless of whether TCP-AO is used or not, In order to defend against various attacks against the application data (attacker attempting to spoof in fake data is discussed Section 20.1.4) , the client must secure application data (e.g. using SRTP). 

Cheers,
-Tiru

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 25 Jun 2019 12:27:50 +0000

Hi,

> Sent: den 25 juni 2019 01:37
> To: Konda, Tirumaleswar Reddy <[email-masked]>
TCP-layer
> under which conditions would be helpful, as a start.

And I think this requirement is backwards. Application of TCP-AO or TLS does
not result in an improved security property for the higher layer that
utilizes TURN. That is still regular IP/UDP datagram payloads in this
version. There is nothing in this specification that gives you anything
better on the server to peer leg. Thus, application of TLS/TCP or TCP-AO on
the client to server leg is only to mitigate some threats on this client to
server leg, potentially making it more robust. 

Thus, I would suggest that this requirement is removed. And instead it is
explained that the actual upper layer security properties are not improved
simply the client server leg is less vulnerable to certain attacks. 

/Magnus

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 26 Jun 2019 10:32:48 +0000

As per the suggestion from Magnus, modified text as follows:

TCP connection between the TURN client and server can use TCP-AO [RFC5925] but UDP does not provide a similar type of authentication until UDP supports
authentication option.  If TCP-AO would be used between TURN client and server, it would not change the end-to-end security properties of
the UDP payload being relayed.  Therefore applications using TURN will need to secure their application data end-to-end appropriately, e.g.  SRTP for RTP applications.  

Cheers,
-Tiru

> From: Magnus Westerlund <[email-masked]>
> Sent: Tuesday, June 25, 2019 5:58 PM
> To: [email-masked]; Konda, Tirumaleswar Reddy
> <[email-masked]>
> Cc: [email-masked]; [email-masked]; draft-ietf-tram-
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: [Tsv-art] [tram] Tsvart last call review of draft-ietf-tram-turnbis-
> 25
> 
> Hi,
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 26 Jun 2019 08:37:36 -0500

> the UDP payload being relayed.  Therefore applications using TURN will need to secure their application data end-to-end appropriately, e.g.  SRTP for RTP applications.  

That looks better; thanks!  (And thanks to Magnus for noticing!)

-Ben

---

From: Joe Touch <[email-masked]>
Date: Wed, 26 Jun 2019 08:25:27 -0700

Minor suggestions:

> On Jun 26, 2019, at 6:37 AM, Benjamin Kaduk <[email-masked]> wrote:
> 
>> authentication option.  

(an equivalent? a similar?) and cite draft-ietf-tsvwg-udp-options

>> If TCP-AO would be used between TURN client and server, it would not change the end-to-end security properties of

Even if both TCP-AO and UDP authentication were both used between...

>> the UDP payload being relayed.
>>  Therefore applications using TURN will need to secure their application data end-to-end appropriately, e.g.  SRTP for RTP applications. 

Joe

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 27 Jun 2019 03:03:09 +0000

Thanks Jon, will update draft.

-Tiru

> Sent: Wednesday, June 26, 2019 8:55 PM
> To: Benjamin Kaduk <[email-masked]>
> Cc: Konda, Tirumaleswar Reddy <[email-masked]>;
> Magnus Westerlund <[email-masked]>; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> >> TCP connection between the TURN client and server can use TCP-AO
> >> [RFC5925] but UDP does not provide a similar type of authentication until
> UDP supports authentication option.
> 
> >> If TCP-AO would be used between TURN client and server, it would not
> >> change the end-to-end security properties of
> 
> >>  Therefore applications using TURN will need to secure their application
> data end-to-end appropriately, e.g.  SRTP for RTP applications.
> 
> Joe

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 27 Jun 2019 07:40:22 +0000

Joe,

Are you satisfied with the changes in version -26 and -27 so that we
can proceed to IESG evaluation? 

cheers

Magnus

---

From: Joe Touch <[email-masked]>
Date: Thu, 27 Jun 2019 06:43:09 -0700

Yes. 

Joe

> On Jun 27, 2019, at 12:40 AM, Magnus Westerlund <[email-masked]> wrote:
> 
> Joe,
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 27 Jun 2019 07:04:39 -0700

Yes. 

Joe