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

["Konda, Tirumaleswar Reddy" <[e-mail]>]

Hi Eric,

Thanks for the review. Please see inline 

> -----Original Message-----
> From: tram <[e-mail]> On Behalf Of Éric Vyncke via
> Datatracker
> Sent: Sunday, July 7, 2019 1:49 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> 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.
> 
> É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 ?

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

> 
> == COMMENTS ==
> 
> -- Section 2 --
> 
> 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).

> 
> -- Section 3.7 --
> 
> The 500 bytes guideline to avoid fragmentation, is there any data backing the
> 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
> path) The text should refer to section 11.5

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

Cheers,
-Tiru

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