Subject: [rtcweb] Spencer Dawkins' Yes on draft-ietf-rtcweb-transports-14: (with COMMENT)

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 02 Aug 2016 10:36:17 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-rtcweb-transports-14: Yes

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-rtcweb-transports/

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

I noted that some comments that I agreed with have appeared during Last
Call, and hope they'll be reflected in a -15. Beyond that, I had a few
comments of my own, but wanted to thank the working group for producing
very clear and helpful transport guidance.

In this text

   If some of the temporary IPv6 addresses, but not all, are marked
   deprecated, the client SHOULD discard the deprecated addresses.
   
I would find some explanation of why this is a SHOULD to be helpful ("if
some of the addresses are deprecated, and you could discard them because
you still have addresses that are not marked deprecated, why would you
not discard the deprecated addresses?").

In this text

   In order to deal with firewalls that block all UDP traffic, the mode
   of TURN that uses TCP between the client and the server MUST be
   supported, and the mode of TURN that uses TLS over TCP between the
   client and the server MUST be supported.  See [RFC5766] section 2.1
   for details.
   
I think MUST for both TCP and TLS over TCP is still a good requirement,
but I note that RFC 5766 significantly predates RFC 7258, and wonder if
it's worth mentioning the tradeoffs in selecting which to use in a
pervasively monitored Internet, with RFC 7258 as a reference (RFC 5766
couldn't do that, of course).

In this text

   For data transport over the WebRTC data channel
   [I-D.ietf-rtcweb-data-channel], WebRTC implementations MUST support
   SCTP over DTLS over ICE.  This encapsulation is specified in
   [I-D.ietf-tsvwg-sctp-dtls-encaps]. 
   
I-D.ietf-tsvwg-sctp-dtls-encaps seems to call this "SCTP over DTLS over
ICE/UDP". That would be clearer to me.

I agree with

   There exist a number of schemes for achieving quality of service that
   do not depend solely on DSCP code points.  Some of these schemes
   depend on classifying the traffic into flows based on 5-tuple (source
   address, source port, protocol, destination address, destination
   port) or 6-tuple (5-tuple + DSCP code point).  Under differing
   conditions, it may therefore make sense for a sending application to
   choose any of the configurations:
   
and the text that follows it, but I'm not understanding how a sending
application would know which configuration to choose, if we're still
talking about downloaded Javascript on an arbitrary browser instance (is
that still accurate? If not, my apologies). 

Is the sending application just guessing/applying heuristics, or is there
any guidance (or a reference to guidance) you can provide?

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 3 Aug 2016 11:43:32 +0200

Thanks for the comments!

Responses inline and on github.

> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/

Thanks!

> not discard the deprecated addresses?").

I'm attaching this comment to
https://github.com/rtcweb-wg/rtcweb-transport/issues/22, since it is the
same block of text.

My memory (always less than trustworthy) says that people raised the
issue of "what if there's an ongoing connection using a deprecated
address, there's no non-deprecated useable address available, shouldn't
we keep the in-use address in the pool?" (otherwise we'd lose the
connection at an ICE restart, even though the address still worked) -
with the response being something like "this is complicated, we'll get
experience to see if this is ever a real case, but let's make it a
SHOULD so that if people figure out that the problem is real, they'll
not be in formal non-conformance".

This is the SHOULD version that means "it's a really good idea to do
this, but we're not sure we've identified all the corner cases where
it's a good idea not to; in case you encounter one, go ahead and be my
guest".

> couldn't do that, of course).

Filed as https://github.com/rtcweb-wg/rtcweb-transport/issues/36

RFC 5766 section 2.1 has this to say about TLS-over-TCP mode:

   TURN supports TLS-over-TCP transport between the client and the
   server because TLS provides additional security properties not
   provided by TURN's default digest authentication; properties that
   some clients may wish to take advantage of.  In particular, TLS
   provides a way for the client to ascertain that it is talking to the
   correct server, and provides for confidentiality of TURN control
   messages.  TURN does not require TLS because the overhead of using
   TLS is higher than that of digest authentication; for example, using
   TLS likely means that most application data will be doubly encrypted
   (once by TLS and once to ensure it is still encrypted in the UDP
   datagram).

I thought this text was clear enough that I didn't want to try to
improve on it.

> ICE/UDP". That would be clearer to me.

I reacted violently to "ICE/UDP" when I first encountered it, and still
do - because the transport might not be UDP after all, given the various
options mentioned above.

Not a big deal, but I feel that "ICE/UDP" is misleading.

> any guidance (or a reference to guidance) you can provide?

Filed as https://github.com/rtcweb-wg/rtcweb-transport/issues/37

I don't think we have the experience that could form the basis for
guidance yet, so my suggestion is "no change".

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 3 Aug 2016 10:57:29 -0500

Hi, Harald,

On Wed, Aug 3, 2016 at 4:43 AM, Harald Alvestrand <[email-masked]>
wrote:

> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html

So, would it be correct to say, "the client SHOULD discard the deprecated
addresses unless they are used in an ongoing connection"?

> I thought this text was clear enough that I didn't want to try to

I thought that text was clear, but wondered if the scales had tipped
between TLS-over-TCP and TCP due to our improved understanding of pervasive
monitoring. If they haven't tipped, there's no need to twiddle with the
guidance.

> Not a big deal, but I feel that "ICE/UDP" is misleading.

I find it awesome that you are reacting to the last three letters in
ICE/UDP, while I'm reacting to the first three ... but I understand your
point. I guess it's even less likely to be using ICE as transport than UDP,
isn't it?

Of course, I also note that I'm the shepherding AD for
ietf-tsvwg-sctp-dtls-encaps, and I could have had this brilliant
realization a couple of years ago ...

I suppose that a right answer is to leave this.

> guidance yet, so my suggestion is "no change".

That's very reasonable. I wonder if it's worth saying that, but I'm fine if
you don't make a change.

Thanks!

Spencer

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 3 Aug 2016 21:56:40 +0200

<snip stuff that we've finished discussing>
On 08/03/2016 05:57 PM, Spencer Dawkins at IETF wrote:
> Hi, Harald,
>
> On Wed, Aug 3, 2016 at 4:43 AM, Harald Alvestrand
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Thanks for the comments!
>
> So, would it be correct to say, "the client SHOULD discard the
> deprecated addresses unless they are used in an ongoing connection"?

That works for me, given that it calls out a specific case I think was
raised, and continues to use SHOULD. I'll add this.