Re: [tram] Mirja Kühlewind's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT)

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

Hi Mirja,

I have updated the draft to address your Discuss and comments (see https://github.com/tireddy2/TURNbis/blob/master/Diff%20%20draft-ietf-tram-turnbis-27.txt%20-%20draft-ietf-tram-turnbis-28.pdf). 
Please have a look.

Cheers,
-Tiru

> -----Original Message-----
> From: Konda, Tirumaleswar Reddy
> Sent: Monday, July 15, 2019 12:01 PM
> To: Mirja Kühlewind <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: RE: [tram] Mirja Kühlewind's Discuss on draft-ietf-tram-turnbis-27:
> (with DISCUSS and COMMENT)
> 
> Hi Mirja,
> 
> Thanks for the review. Please see inline
> 
> > -----Original Message-----
> > From: tram <[e-mail]> On Behalf Of Mirja Kühlewind via
> > Datatracker
> > Sent: Wednesday, July 10, 2019 9:25 PM
> > To: The IESG <[e-mail]>
> > Cc: [e-mail]; [e-mail];
> > [e-mail]; [e-mail]
> > Subject: [tram] Mirja Kühlewind's Discuss on
> > draft-ietf-tram-turnbis-27: (with DISCUSS and 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.
> >
> > Mirja Kühlewind has entered the following ballot position for
> > draft-ietf-tram-turnbis-27: Discuss
> >
> > 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/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > One quick discussion which probably is only an oversight and therefore
> > should be easy got fix:
> >
> > I'm bit confused about the requirement on using authentication. This
> > draft says in section 5 (as RFC5766 does):
> >
> > "The server MUST demand that all requests
> >    from the client be authenticated using this mechanism, or that a
> >    equally strong or stronger mechanism for client authentication is
> >    used."
> >
> > However, RFC 8155 which is even now cited in this draft, updates
> > RFC5766 and relaxes this requirement. Later in the section 7.2. this draft
> says:
> >
> > "The server SHOULD require that the request be authenticated."
> >
> > I assume the requirement in section 5 is an oversight?
> 
> Yes, removed the requirement in Section 5.
> 
> >
> > I also recommend to only specify this requirement normatively in one place.
> 
> Done, updated step 1 in Section 5 to address the comment from Ben as
> follows:
> 
>    1.   The TURN server provided by the local or access network MAY
>         allow unauthenticated request in order to accept Allocation
>         requests from new and/or guest users in the network who do not
>         necessarily possess long term credentials for STUN
>         authentication and its security implications are discussed in
>         [RFC8155].  Otherwise, the server MUST require that the request
>         be authenticated.  If the request is authenticated, the
>         authentication MUST be done either using the long-term
>         credential mechanism of [I-D.ietf-tram-stunbis] or the STUN
>         Extension for Third-Party Authorization [RFC7635] unless the
>         client and server agree to use another mechanism through some
>         procedure outside the scope of this document.
> 
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Some other technical comments/questions:
> >
> > 1) Sec 3.7:
> > "or use UDP fragmentation [I-D.ietf-tsvwg-udp-options]."
> > I believe the possibility to use UDP fragmentation was brought up by
> > the TSV-ART review (Thanks Joe!). However, I would like to mention
> > that this can only be used if supported by both endpoints and that
> > should probably also be remarked here. The next sentence in the draft
> > indicated this by saying "until UDP fragmentation support is
> > available", however, this actually seem to be editorially a bit
> > misplaced there and could explain more. See also this text in
> > draft-ietf-tsvwg-udp-options:
> >
> > "FRAG needs to be used with extreme care because it will present
> >    incorrect datagram boundaries to a legacy receiver, unless encoded
> >    as LITE data (see Section 5.8)."
> >
> > Also note that draft-ietf-tsvwg-udp-options is still under development
> > and we don't have much deployment experience with it yet.
> 
> Yes, Joe suggest the above change. I have added the following line:
> Note that the UDP fragmentation option needs to be supported by both
> endpoints, and at the time of writing of this document, UDP fragmentation
> support is under discussion and is not deployed.
> 
> >
> > And further, in the same section. There is also
> > draft-ietf-tsvwg-datagram- plpmtud on "Packetization Layer Path MTU
> > Discovery for Datagram Transports". Please also be aware that there is
> > an extensive TSV-ART for draft-ietf-tram-stun-pmtud. Both might impact
> > the final content of this section.
> 
> The draft does not refer to draft-ietf-tsvwg-datagram- plpmtud.
> 
> >
> > 2) sec 11.5:
> > "When the server receives an ICMP packet, the server verifies that the
> >    type is either 3 or 11 for an ICMPv4 [RFC0792] packet or either 1, 2,
> >    or 3 for an ICMPv6 [RFC4443] packet."
> > Restricting to a set of known types, doesn't seem to support future
> > extensibility very well...
> 
> Good point, added the following lines:
> New ICMP types or codes can be defined in future specifications. If the
> server receives an ICMP error packet, and the new type or code field can
> help the client to make use of the ICMP error notification and generate
> feedback to the application layer, the server sends the Data indication with
> an ICMP attribute conveying the new ICMP type or code.
> 
> >
> > 3) sec 12.5:
> > "Over TCP and TLS-over-TCP, the ChannelData message MUST be padded
> to
> >    a multiple of four bytes in order to ensure the alignment of
> >    subsequent messages."
> > Not exactly sure why this is useful...? Is this to align with STUN and
> > therefore make processing somehow easier? Is that really needed. And
> > exception should be easy to implement and should save some bytes which
> > is the as I understood it the whole purpose of channels, no?
> 
> This behavior is not new, it is defined and deployed in TURN
> https://tools.ietf.org/html/rfc5766#section-11.5
> 
> >
> > 4) 12.6:
> > "Note that if
> >    the Length field in the ChannelData message is 0, then there will be
> >    no data in the UDP datagram, but the UDP datagram is still formed and
> >    sent."
> > Can you maybe add some more text and explain why this is useful?
> 
> Sure, added reference to Section 4.1 in https://tools.ietf.org/html/rfc6263
> 
> >
> > 5) sec 15:
> > RFC6824 will soon be obsoleted by draft-ietf-mptcp-rfc6824bis and
> > please s/TCP multi-path/Multipath TCP/.
> 
> Thanks, updated.
> 
> >
> > 6) Just a thought looking at section 14 and 16: It could have been
> > nice to provide an ECN feedback field from the server to the client in
> > case a ECN marked packet is received from the peer... however, I guess
> > that future work at this point in the process...
> >
> > 7) sec 18.13: Maybe I missed this because I reviewed this doc over 3
> > days, but is only the ICMP Attribute send to the client or is the
> > actual ICMP packets or as much as possible of that packet includes as well?
> 
> Yes, only the ICMP attribute is sent to the client.
> 
> >
> > 8) sec 23:
> > "Response: TURN will no longer be needed once there are no longer any
> >    NATs.  Unfortunately, as of the date of publication of this document,
> >    it no longer seems very likely that NATs will go away any time soon.
> >    However, the need for TURN will also decrease as the number of NATs
> >    with the mapping property of Endpoint-Independent Mapping [RFC4787]
> >    increases."
> > Yes... so you don't think that IPv6 will be any help here?
> 
> Yes, IPv6 will not help in some scenarios, updated Introduction to list them.
> 
>    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]).  In
>    addition, in a SIP or WebRTC call, if the user wants IP location
>    privacy from the peer then the client can select a relay server
>    offering IP location privacy and only convey the relayed candidates
>    to the peer for ICE connectivity checks (see Section 4.2.4 in
>    [I-D.ietf-rtcweb-security]).
> 
> >
> > Editorial comments:
> >
> > 1) Sec 6:
> > "The relayed transport address MUST be unique across all
> >    allocations, so it can be used to uniquely identify the allocation.
> >
> >    Both the relayed transport address and the 5-tuple MUST be unique
> >    across all allocations, so either one can be used to uniquely
> >    identify the allocation, [...]"
> > These two sentences seem quite redundant. The first one was added in
> > this draft. The second one was already there in RFC5766.
> 
> Thanks, removed the second sentence.
> 
> >
> > 2) sec 7.1:
> > "Since this specification only
> >    allows UDP between the server and the peers, it is RECOMMENDED that
> > [...]"
> > Wordings ("only allows") seems weird to me given use of other
> > proposals is at least to some extend discussed.
> 
> The specification does not allow any other protocol other than UDP between
> the server and peers (As you know, UDP is the preferred transport for media
> streams).
> 
> >
> > Nits:
> > sec 7.1.: s/the client pick a currently unused transport address/the
> > client picks a currently unused transport address/
> 
> Fixed.
> 
> Cheers,
> -Tiru
> >
> >
> > _______________________________________________
> > tram mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tram