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

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Wed, 10 Jul 2019 08:55:14 -0700

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?

I also recommend to only specify this requirement normatively in one place.

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

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.

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

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?

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?

5) sec 15:
RFC6824 will soon be obsoleted by draft-ietf-mptcp-rfc6824bis and please s/TCP
multi-path/Multipath TCP/.

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?

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?

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.

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.

Nits:
sec 7.1.: s/the client pick a currently unused transport address/the client
picks a currently unused transport address/

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 15 Jul 2019 06:31:00 +0000

Hi Mirja,

Thanks for the review. Please see inline

> -----Original Message-----
> From: tram <[email-masked]> On Behalf Of Mirja Kühlewind via
> Datatracker
> Sent: Wednesday, July 10, 2019 9:25 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> 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.
> 
> 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.)
> 
> 
> 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):
> 
> 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:
> 

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.

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

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

> 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

This behavior is not new, it is defined and deployed in TURN https://tools.ietf.org/html/rfc5766#section-11.5 

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

> marked packet is received from the peer... however, I guess that future
> work at this point in the process...
> 

Yes, only the ICMP attribute is sent to the client.

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

> draft. The second one was already there in RFC5766.

Thanks, removed the second sentence. 

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

> picks a currently unused transport address/

Fixed.

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

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 17 Jul 2019 12:35:42 +0000

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

> From: Konda, Tirumaleswar Reddy
> Sent: Monday, July 15, 2019 12:01 PM
> To: Mirja Kühlewind <[email-masked]>; The IESG <[email-masked]>
> Subject: RE: [tram] Mirja Kühlewind's Discuss on draft-ietf-tram-turnbis-27:
> (with DISCUSS and COMMENT)
> 
> Hi Mirja,
> 
> > Cc: [email-masked]; [email-masked];
> > [email-masked]; [email-masked]
> > 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.
> >
> > 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
> > I'm bit confused about the requirement on using authentication. This
> > draft says in section 5 (as RFC5766 does):
> >
> > 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:
> >
> > 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
> > Also note that draft-ietf-tsvwg-udp-options is still under development
> > and we don't have much deployment experience with it yet.
> 
> 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.
> 
> >
> > 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.
> 
> 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:
> > 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
> > 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?
> 
> > These two sentences seem quite redundant. The first one was added in
> > this draft. The second one was already there in RFC5766.
> 
> > 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
> >
> >

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 24 Jul 2019 05:46:05 +0000

Hi Mirja,

We have updated the draft to address your Discuss and comments (https://tools.ietf.org/rfcdiff?url2=draft-ietf-tram-turnbis-28.txt).  Please have a look.

Cheers,
-Tiru

> Sent: Wednesday, July 17, 2019 6:06 PM
> 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
> 
> > > 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.)
> > >
> > >
> > > Please refer to
> > > One quick discussion which probably is only an oversight and
> > > therefore should be easy got fix:
> > >
> > > should probably also be remarked here. The next sentence in the
> > > draft indicated this by saying "until UDP fragmentation support is
> > > Also note that draft-ietf-tsvwg-udp-options is still under
> > > development and we don't have much deployment experience with it
> yet.
> >
> > endpoints, and at the time of writing of this document, UDP
> > fragmentation support is under discussion and is not deployed.
> >
> > >
> > > 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.
> >
> > 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:
> > > 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?
> >
> > > 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...
> > >
> > 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:

---

From: Mirja Kuehlewind <[email-masked]>
Date: Sat, 27 Jul 2019 03:07:11 -0400

Hi Tiru,

Thanks for your quick reply and update and sorry for my delay! I’ve just cleared my discuss but see two quick comments in line below.

> On 15. Jul 2019, at 02:31, Konda, Tirumaleswar Reddy <[email-masked]> wrote:
> 
> Hi Mirja,
> 

Yes, but I though you maybe should cite it as well :-)

> Yes, only the ICMP attribute is sent to the client.

Here also, I can imagine that sending as much of the ICMP packet as possible could be useful as well. Was that considered?

Mirja

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sat, 27 Jul 2019 15:12:58 +0000

Hi Mirja,

Please see inline

> From: Mirja Kuehlewind <[email-masked]>
> Sent: Saturday, July 27, 2019 12:37 PM
> To: Konda, Tirumaleswar Reddy <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked]; draft-ietf-tram-
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [tram] Mirja Kühlewind's Discuss on draft-ietf-tram-turnbis-27:
> Thanks for your quick reply and update and sorry for my delay! I’ve just
> cleared my discuss but see two quick comments in line below.
> 
> > On 15. Jul 2019, at 02:31, Konda, Tirumaleswar Reddy
> <[email-masked]> wrote:
> >
> > Hi Mirja,
> >
> >> "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."
> >>
> >> development and we don't have much deployment experience with it yet.
> >

Sure, updated text as follows:
The Packetized Path  MTU Discovery algorithm defined in [RFC4821] is one such algorithm and a set of algorithms are defined in [I-D.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."
> Here also, I can imagine that sending as much of the ICMP packet as possible
> could be useful as well. Was that considered?

Yes, the decision was not send the ICMP packet (Please see https://mailarchive.ietf.org/arch/msg/tram/dk5PzVhBzzCUSAftYVoSpYQl0o4) 

Cheers,
-Tiru

> between the server and peers (As you know, UDP is the preferred transport
> for media streams).
> >
> >>
> >> Nits: