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 <TirumaleswarReddy_Konda@mcafee.com> wrote:
> 
> Hi Joseph,
> 
> Thanks for the review, Please see inline
> 
>> -----Original Message-----
>> From: tram <tram-bounces@ietf.org> On Behalf Of Joseph Touch via
>> Datatracker
>> Sent: Wednesday, June 5, 2019 11:34 AM
>> To: tsv-art@ietf.org
>> Cc: draft-ietf-tram-turnbis.all@ietf.org; ietf@ietf.org; tram@ietf.org
>> 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
>> 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 tsv-
>> art@ietf.org 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.
>> 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. 

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)

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

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

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

>> 
>> Sec 23 indicates the changes since RFC5766; a similar section addressing
>> changes since RFC6156 would be useful to add.
> 
> Okay, added another Section (updates to RFC6156).
> 
> Cheers,
> -Tiru
> 
>> 
>> 
>> _______________________________________________
>> tram mailing list
>> tram@ietf.org
>> https://www.ietf.org/mailman/listinfo/tram
> _______________________________________________
> Tsv-art mailing list
> Tsv-art@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art