Subject: [tram] Éric Vyncke's No Objection on draft-ietf-tram-turnbis-27: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Sun, 07 Jul 2019 01:18:44 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-tram-turnbis-27: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you all for the work put into this clear and well-written document. I
also appreciate the fact that TURN server can be used to proxy between IPv4 and
IPv6; on this topic, this specific use case could probably be described early
in the document rather then in section 5 (e.g. when discussing the transport
protocol between client and server or even earlier).

For my own curiosity, isn't TURN scope broader than plain NAT: can it also be
useful in the absence of NAT if inbound 'connection' are blocked by security
policy ?

== COMMENTS ==

-- Section 2 --

Please use the new boilerplate RFC 8174 ;-)

-- Section 3.1 --

Is there any reason why MPTCP is not specified for the communication between
TURN client and TURN server? There is a very short explanation in section 15
"TCP multi-path is not used by both SIP and WebRTC protocols [RFC7478] for
media and non-media data" but it does not address the use of MPTCP between TURN
client/server.

-- Section 3.7 --

The 500 bytes guideline to avoid fragmentation, is there any data backing the
sentence "...will generally avoid IP fragmentation." ?

In the same section, the text about 'DF bit' should be clear that it is
obviously for IPv4 (it is indicated 2 paragraphs below).

-- Section 3.9 --

The TCP/UDP/DTLS discussion of 'happy eyeball' is confusing between "use the
first TCP connection that is established" and "if connections are established
on both IP address families..." Which sentence should be used? Why plain RFC
8305 is not enough?

-- Section 7.2 --

What is the expected server behavior when receiving a DONT-FRAGMENT when the
REQUESTED-ADDRESS-FAMILY is IPv6 ? The STUN document appears to use
DONT-FRAGMENT only when receiving traffic from the peers.

-- Section 9 --

About the permission based on the peer IP address, the text is about UDP, but
what about ICMP messages? (obvioulsy their source could be any router on the
path) The text should refer to section 11.5

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 8 Jul 2019 13:55:24 +0000

Hi Eric,

Thanks for the review. Please see inline 

> -----Original Message-----
> From: tram <[email-masked]> On Behalf Of Éric Vyncke via
> Datatracker
> Sent: Sunday, July 7, 2019 1:49 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: [tram] Éric Vyncke's No Objection on draft-ietf-tram-turnbis-27:
> (with COMMENT)
> 
> 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.
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> also appreciate the fact that TURN server can be used to proxy between IPv4
> and IPv6; on this topic, this specific use case could probably be described
> early in the document rather then in section 5 (e.g. when discussing the
> transport protocol between client and server or even earlier).
> 

Interactive Connectivity Establishment (ICE) helps solve the above problem by performing connectivity checks, but direct UDP connection will not be possible even with ICE if both endpoints are behind NATs that perform address and port dependent mapping. In addition, Enterprise firewall may block direct UDP connections but allow UDP traffic relayed through an Enterprise TURN server (please see https://tools.ietf.org/html/rfc7478#section-2.3.5.1). 

> Please use the new boilerplate RFC 8174 ;-)

Fixed. 

> 
> -- Section 3.1 --
> 
> Is there any reason why MPTCP is not specified for the communication
> between TURN client and TURN server? There is a very short explanation in
> section 15 "TCP multi-path is not used by both SIP and WebRTC protocols
> [RFC7478] for media and non-media data" but it does not address the use of
> MPTCP between TURN client/server.

TURN is typically used by SIP and WebRTC protocols to relay media streams, but RTP assumes a single path and make decisions based on the measured characteristics of this single path (with the exception of Multipath RTP discussed in https://tools.ietf.org/html/draft-ietf-avtcore-mprtp-03).

> sentence "...will generally avoid IP fragmentation." ?

Yes, If the PMTU is not known, and on legacy or otherwise unusual networks the guideline should work (see https://tools.ietf.org/html/rfc7252#section-4.6 and https://tools.ietf.org/html/draft-ietf-tsvwg-datagram-plpmtud-08).

> 
> In the same section, the text about 'DF bit' should be clear that it is obviously
> for IPv4 (it is indicated 2 paragraphs below).

Done. 

> 
> -- Section 3.9 --
> 
> The TCP/UDP/DTLS discussion of 'happy eyeball' is confusing between "use
> the first TCP connection that is established" and "if connections are
> established on both IP address families..." Which sentence should be used?
> Why plain RFC
> 8305 is not enough?

Good point, modified text as follows:

   o  For TCP or TLS-over-TCP, the results of the Happy Eyeballs
      procedure [RFC8305] are used by the TURN client for sending its
      TURN messages to the server.

> 
> -- Section 7.2 --
> 
> What is the expected server behavior when receiving a DONT-FRAGMENT
> when the REQUESTED-ADDRESS-FAMILY is IPv6 ? The STUN document
> appears to use DONT-FRAGMENT only when receiving traffic from the peers.

It is discussed in Sections 14 and 15.

> 
> -- Section 9 --
> 
> About the permission based on the peer IP address, the text is about UDP,
> but what about ICMP messages? (obvioulsy their source could be any router
> on the

Yes, Please see https://tools.ietf.org/html/draft-ietf-tram-turnbis-27#section-12.7  

Cheers,
-Tiru

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

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 8 Jul 2019 21:19:27 +0000

Tiru

Thank you for your reply and your comments and actions.

Please see remaining points inline for lines starting with EV>

Regards

-éric

On 08/07/2019, 15:55, "Konda, Tirumaleswar Reddy" <[email-masked]> wrote:

    Hi Eric,

    

EV> I am familiar with ICE __ and your last sentence is exactly what my initial comment was about: please goes beyond the NAT typical/common use case of TURN and also cite the firewall blocking inbound UDP. Just to improve understanding by the readers.

   
EV> suggest to add an informative reference to the I-D

    
EV> RFC 7252 is about CoAP and is not "a guideline" per se but a reference to the IPv4 'assumed' MTU of 576. I would prefer a reference to RFC 7252 with 576 for IPv4 and 1280 for IPv6 for MTU. I am afraid that giving the number "500" is kind of misleading the reader. At the bare minimum, I suggest to add the reference to COAP, and use the number from CoAP if you want to specify numbers.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 9 Jul 2019 08:10:01 +0000

Hi,

A comment inline regarding MP-TCP.

On Mon, 2019-07-08 at 21:19 +0000, Eric Vyncke (evyncke) wrote:
> On 08/07/2019, 15:55, "Konda, Tirumaleswar Reddy" <
> [email-masked]> wrote:
> 
> 
>     > 
>     > == COMMENTS ==
> > 
> 
>     > -- Section 3.1 --
>     > 
>     TURN is typically used by SIP and WebRTC protocols to relay media
> streams, but RTP assumes a single path and make decisions based on
> the measured characteristics of this single path (with the exception
> of Multipath RTP discussed in 
> https://tools.ietf.org/html/draft-ietf-avtcore-mprtp-03).
>    

So on the client to server path there is a possibility to use MP-TCP to
potentially improve that specific leg of the communication. It can be
negotiated in the TCP connection if desired. However, to be clear I
don't think there is a reason to recommend and definitely not mandate
MP-TCP support if one supports the TCP transport in the client to
server interface. Also it creates a potentially interesting
interactions between the framework using TURN, like ICE when a mobility
events happen. It may also result in sub-optimal routing in cases where
a client selects to use multiple interfaces to have one MP-TCP
connection to one TURN server, rather than the best TURN server per
interface. 

Also, I think discussing MP-RTP here is missleading. Because with MP-
RTP I would treat the TURN relayed address as one particular point of
presence for the TURN client side implementation, in addition to any
direct from the corresponding interface that may be possible to
establish. There are some discussion of this in the MP-RTP draft. 

So it would be possible to state that an TURN client MAY attempt to
negotiate MP-TCP with the TURN server but support of MP-TCP in TURN
servers are OPTIONAL. In addition TURN clients on hosts with multiple
interfaces and access to multiple TURN servers should consider if there
are certain interfaces and TURN server combinations that results in
shorter paths, and therefore can benefit from using multiple TURN
servers, even if they can be reached from multiple interfaces. 

Cheers

>     Yes, If the PMTU is not known, and on legacy or otherwise unusual
> networks the guideline should work (see 
> https://tools.ietf.org/html/rfc7252#section-4.6 and 
> https://tools.ietf.org/html/draft-ietf-tsvwg-datagram-plpmtud-08).
>     
> EV> RFC 7252 is about CoAP and is not "a guideline" per se but a
> reference to the IPv4 'assumed' MTU of 576. I would prefer a
> reference to RFC 7252 with 576 for IPv4 and 1280 for IPv6 for MTU. I
> am afraid that giving the number "500" is kind of misleading the
> reader. At the bare minimum, I suggest to add the reference to COAP,
> and use the number from CoAP if you want to specify numbers. 

I think I mostly agree with Eric here. So 576 is a recommendation on
the IPv4 minimal required packet size reception capability. Then you
have subtracted the overhead for TURN roughly. And still 576 bytes IPv4
packets may be fragmented, the true minimal size is 68 bytes. And the
use of an assumption of 1280 minus TURN overhead is almost as likely to
not result in fragmentation as 500 bytes. Becasue the networks that
will have issues with your 1200 payload is likely going to have issues
with 500 bytes too. So from my perspective giving that very low
recommendation does not reflect today's network. And the COAP
recommendation of meeting 576 bytes total is for constrained devices
and their link layers. TURN's primary users in media applications are
normally not targeting that type of link layers that has such a limited
MTU. 
 
Cheers

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

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 9 Jul 2019 09:00:21 +0000

Hi Eric,

Please see inline

> From: Eric Vyncke (evyncke) <[email-masked]>
> Sent: Tuesday, July 9, 2019 2:49 AM
> To: Konda, Tirumaleswar Reddy
> <[email-masked]>; The IESG <[email-masked]>
> Subject: Re: [tram] Éric Vyncke's No Objection on draft-ietf-tram-turnbis-27:
> (with COMMENT)
> 
> On 08/07/2019, 15:55, "Konda, Tirumaleswar Reddy"
> <[email-masked]> wrote:
> 
>     Hi Eric,
> 
>     Interactive Connectivity Establishment (ICE) helps solve the above problem
> by performing connectivity checks, but direct UDP connection will not be
> possible even with ICE if both endpoints are behind NATs that perform
> address and port dependent mapping. In addition, Enterprise firewall may
> block direct UDP connections but allow UDP traffic relayed through an
> Enterprise TURN server (please see
> https://tools.ietf.org/html/rfc7478#section-2.3.5.1).
> 
> EV> I am familiar with ICE __ and your last sentence is exactly what my initial
> comment was about: please goes beyond the NAT typical/common use case
> of TURN and also cite the firewall blocking inbound UDP. Just to improve
> understanding by the readers.

Sure, added the following paragraph to the Introduction section :

   In many enterprise networks, direct UDP transmissions are not
   permitted between clients on the internal networks and external IP
   addresses.  To permit media sessions in such a situation to use UDP
   and to avoid forcing the media sessions through TCP, Enterprise
   Firewall can be configured to allow UDP traffic relayed through an
   Enterprise relay server.  This scenario is required to be supported
   by the WebRTC requirements (Section 2.3.5.1 in [RFC7478]).

>     TURN is typically used by SIP and WebRTC protocols to relay media streams,
> but RTP assumes a single path and make decisions based on the measured
> characteristics of this single path (with the exception of Multipath RTP
> discussed in https://tools.ietf.org/html/draft-ietf-avtcore-mprtp-03).
> 

draft-ietf-avtcore-mprtp has expired couple of years back. I don't think a reference to MPRTP is required.

> EV> RFC 7252 is about CoAP and is not "a guideline" per se but a reference to
> the IPv4 'assumed' MTU of 576. I would prefer a reference to RFC 7252 with
> 576 for IPv4 and 1280 for IPv6 for MTU. I am afraid that giving the number
> "500" is kind of misleading the reader. At the bare minimum, I suggest to add
> the reference to COAP, and use the number from CoAP if you want to
> specify numbers.

The above IPv4/IPv6 numbers are used in several other specifications by only referring to [RFC791] and [RFC1122], for example see SIG-002 in https://tools.ietf.org/html/rfc8612 

Cheers,
-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 9 Jul 2019 09:20:36 +0000

Hi Magnus,

Please see inline 

> From: Magnus Westerlund <[email-masked]>
> Sent: Tuesday, July 9, 2019 1:40 PM
> To: [email-masked]; Konda, Tirumaleswar Reddy
> <[email-masked]>; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]

If the host has multiple interfaces and discovers multiple TURN servers, https://tools.ietf.org/html/rfc7982 discusses mechanism to influence the TURN server selection. I can add the following line:
If a host with multiple interfaces discovers a TURN server in each interface, the mechanism described in [RFC7982] can be used by the TURN client to influence the TURN server selection.

-Tiru

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 9 Jul 2019 18:00:34 +0000

Magnus,

Thank you for the added information & comments:

On 09/07/2019, 10:10, "iesg on behalf of Magnus Westerlund" <[email-masked] on behalf of [email-masked]> wrote:

EV> the usual discussion on which layer to provide mobility: layer 2, layer 3, layer 4 or in the application ;-)

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 10 Jul 2019 06:02:21 +0000

> Sent: Tuesday, July 9, 2019 11:31 PM
> To: Magnus Westerlund <[email-masked]>; [email-masked];
> Konda, Tirumaleswar Reddy <[email-masked]>
> On 09/07/2019, 10:10, "iesg on behalf of Magnus Westerlund" <iesg-
> [email-masked] on behalf of [email-masked]> wrote:
> 
> 

IP address mobility using TURN is handled by https://tools.ietf.org/html/rfc8016 

-Tiru