Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-00.txt

From: [email-masked]
Date: Mon, 19 Aug 2013 10:15:07 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF.

	Title           : Transports for RTCWEB
	Author(s)       : Harald Alvestrand
	Filename        : draft-ietf-rtcweb-transports-00.txt
	Pages           : 6
	Date            : 2013-08-19

Abstract:
   This document describes the data transport protocols used by RTCWEB,
   including the protocols used for interaction with intermediate boxes
   such as firewalls, relays and NAT boxes.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtcweb-transports-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 19 Aug 2013 23:20:41 +0200

As indicated in the -overview draft, it seemed logical to collect the 
information about the transport
profile for RTCWEB in a separate document.

It is only 6 pages including all boilerplate, and has a couple of open 
issues that the WG needs to address.

I'll emit an updated -overview shortly, with the corresponding appendix 
removed.

Let the reviews begin!

              Harald

On 08/19/2013 07:15 PM, [email-masked] wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Dan Wing <[email-masked]>
Date: Mon, 19 Aug 2013 16:20:58 -0700

On Aug 19, 2013, at 2:20 PM, Harald Alvestrand <[email-masked]> wrote:

> As indicated in the -overview draft, it seemed logical to collect the information about the transport
> It is only 6 pages including all boilerplate, and has a couple of open issues that the WG needs to address.
> 
> I'll emit an updated -overview shortly, with the corresponding appendix removed.
> 
> Let the reviews begin!

If per-*packet* DSCP setting is necessary (such as when bundling is used), both Section 2.1 and 2.2 should clarify that requirement.  For example FreeBSD's IPv4 stack didn't have that capability recently, per http://www.freebsd.org/cgi/query-pr.cgi?pr=165305.  I am sure many, many middleboxes don't have that capability (and might take action based on the first DSCP value they see, under the assumption that the 5-tuple flow will continue to use that same DSCP value).

Section 2.2,
"   In order to deal with symmetric NATs, TURN MUST be supported."

Two comments:  TURN is only necessary if both peers are behind NATs which perform endpoint-dependent mapping.  The "symmetric" term is overloaded and lacks precision, so I would really like it avoided.  I suggest:  "To deal with both peers being behind restrictive NATs, TURN MUST be supported."  Using a less-specific term like "restrictive" avoids a bunch of lengthy sentences of technical detail which aren't interesting, and this new wording explains that TURN is only needed when both endpoints are behind such restrictive NATs.

Section 2.2,
  "In order to deal with firewalls that block all UDP traffic, TURN over
   TCP MUST be supported.  (QUESTION: What about ICE-TCP?)"

ICE-TCP allows direct peer-to-peer communications using TCP, without a TURN server doing TCP-to-UDP interworking.  I would say the industry has less experience with ICE-TCP than with ICE or with TURN-over-TCP, and because of the less experience and because ICE-TCP is arguably an *optimization*, I would say ICE-TCP is a MAY.  It can't be a MUST-level requirement, at least by my threshold for MUST which is that interoperability is harmed or interoperability is impossible.

Section 2.2,
"   o  TURN, including TURN over TCP [[QUESTION: and TURN over TLS]],
      [RFC5766]."

Most -- but not all -- of the security obtained with TURN over TLS is achieved with TURN REST (draft-uberti-behave-turn-rest and draft-uberti-rtcweb-turn-rest).  I think the working group should consider if TURN REST satisfies the requirements, or if TURN over TLS is really, really necessary.

Section 2.3,
  "RTCWEB implementations MUST support multiplexing of SCTP/DTLS and RTP
   over the same port pair, as described in the DTLS_SRTP specification
   [RFC5764], section 5.1.2."

Really, the requirement is more than than what DTLS-SRTP specifies, because it only specifies shows how STUN, DTLS, and SRTP packets are demultiplexed, whereas WebRTC endpoints have to handle those three protocols as well as SCTP.  Somewhere -- perhaps draft-ietf-rtcweb-transports or elsewhere, a diagram of how the layering works would be useful.  Adapting the diagram from Section 5.1.2 of RFC5764, I believe incoming packet processing diagram looks like this:

           +----------------+
           | 127 < B < 192 -+--> forward to RTP
	   |                |
      	   |	      	       |   +------------------+
	   |                |   | DTLS processing  |
	   |                |   |                  |
packet --> |  19 < B < 64  -+-->+ appl. protocol  -+--> SCTP
           |                |   |  	      	      |
      	   |  	      	    |   | other protocols -+--> DTLS
	   |                |   |                  |
	   |                |   +------------------+	
           |                |
           |       B < 2   -+--> forward to STUN/ICE
           +----------------+

-d

---

From: Roman Shpount <[email-masked]>
Date: Mon, 19 Aug 2013 19:54:45 -0400

On Mon, Aug 19, 2013 at 7:20 PM, Dan Wing <[email-masked]> wrote:

> Most -- but not all -- of the security obtained with TURN over TLS is
> achieved with TURN REST (draft-uberti-behave-turn-rest and
> draft-uberti-rtcweb-turn-rest).  I think the working group should consider
> if TURN REST satisfies the requirements, or if TURN over TLS is really,
> really necessary.
>

It is useful to support TURN over TLS for two reasons:

1. To hide the remote party IP address in TURN allocations from anybody who
is monitoring the local IP connection
2. To traverse restrictive firewalls that only allow HTTP/HTTPS connections
by placing a TURNS server on port 443

I would think that for those two reasons TURN-TLS should be MUST implement.
_____________
Roman Shpount

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 19 Aug 2013 23:02:25 -0700

> ICE-TCP allows direct peer-to-peer communications using TCP, without a TURN server doing TCP-to-UDP interworking.  I would say the industry has less experience with ICE-TCP than with ICE or with TU…
[BA]  While ICE-TCP will only eliminate the need for TURN over TCP in a fraction of NAT usage cases, the benefits can be substantial in the situations where it does work (and is needed).  The most popular uses of ICE-TCP so far are for things like P2P chat (e.g. MSRP), application sharing and RTP over TCP.  Given that WebRTC  could implement MSRP over the data channel, and could handle screen sharing via RTP over UDP,  the case probably needs to be made based on TURN-less conveyance of RTP over TCP (probably in a consumer scenario only, since for enterprise the TURN server would most likely be needed for firewall traversal reasons).  It's definitely not a MUST, and probably not a SHOULD either for WebRTC.  
> Most -- but not all -- of the security obtained with TURN over TLS is achieved with TURN REST (draft-uberti-behave-turn-rest and draft-uberti-rtcweb-turn-rest).  I think the working group should co…
[BA] Not sure I follow this.   TURN over TLS provides confidentiality for the relay addresses and also some firewall traversal benefits.  TURN REST is trying to solve a different problem entirely (e.g. misuse of TURN credentials).  Personally, I don't think TURN REST really minimizes the risk to the extent necessary, since time limiting the credentials alone won't necessarily stop an ingenious (and greedy) thief.  As an example, when hackers gain control of a PBX they can run up shocking bills in a very short period of time, and even if TURN charges are minimal, you'd be surprised at what Internet miscreants can do with stolen credentials within a 24 hour period.  So to my mind, TURN REST needs some additional bolstering to limit the potential financial liability, such as bandwidth limits.

---

From: Dan Wing <[email-masked]>
Date: Mon, 19 Aug 2013 23:16:09 -0700

On Aug 19, 2013, at 11:02 PM, Bernard Aboba <[email-masked]> wrote:

> [BA] Not sure I follow this.   TURN over TLS provides confidentiality for the relay addresses and also some firewall traversal benefits.  TURN REST is trying to solve a different problem entirely (e.g. misuse of TURN credentials).  

TURN REST solves misuse of credentials and significantly reduces ability to do traffic analysis of the TURN client by someone sniffing between the TURN client and TURN server (username="dwing" sent plaintext between the TURN client and TURN server).

> Personally, I don't think TURN REST really minimizes the risk to the extent necessary, since time limiting the credentials alone won't necessarily stop an ingenious (and greedy) thief.  As an example, when hackers gain control of a PBX they can run up shocking bills in a very short period of time, and even if TURN charges are minimal, you'd be surprised at what Internet miscreants can do with stolen credentials within a 24 hour period.  So to my mind, TURN REST needs some additional bolstering to limit the potential financial liability, such as bandwidth limits. 

I expect something like a bandwidth limit is something that can be encoded into the TURN REST username that is coordinated between the WebRTC server and its cooperative TURN server.  It might be better to encode that properly, rather than by overloading bits of the username.  But perhaps a more elegant solution, rather than bandwidth limits, could be engineered.

-d

---

From: Philipp Hancke <[email-masked]>
Date: Tue, 20 Aug 2013 08:48:31 +0200 (CEST)

> [BA] Not sure I follow this.   TURN over TLS provides confidentiality for the relay addresses and also some firewall traversal benefits.  TURN REST is trying to solve a different problem entirely (e.g. misuse of TURN credentials).  Personally, I don't think TURN REST
> really minimizes the risk to the extent necessary, since time limiting the credentials alone won't necessarily stop an ingenious (and greedy) thief.  As an example, when hackers gain control of a PBX they can run up shocking bills in a very short period of time, and
> even if TURN charges are minimal, you'd be surprised at what Internet miscreants can do with stolen credentials within a 24 hour period.  So to my mind, TURN REST needs some additional bolstering to limit the potential financial liability, such as bandwidth limits. 

Note that the 24 hours are something that is currently necessary because 
browsers don't implement updateIce yet (which would be used to add the 
TURN server and the time limited credentials). Once that is solved it is 
possible to to reduce the attackers window to a couple of seconds.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 20 Aug 2013 07:08:10 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: Tuesday, August 20, 2013 5:25 AM
To: Dan Wing (dwing)
Cc: [email-masked]
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-00.txt

On Mon, Aug 19, 2013 at 7:20 PM, Dan Wing <[email-masked]<mailto:[email-masked]>> wrote:

On Aug 19, 2013, at 2:20 PM, Harald Alvestrand <[email-masked]<mailto:[email-masked]>> wrote:
Section 2.2,
"   o  TURN, including TURN over TCP [[QUESTION: and TURN over TLS]],
      [RFC5766]."

It is useful to support TURN over TLS for two reasons:
1. To hide the remote party IP address in TURN allocations from anybody who is monitoring the local IP connection
[TR] To solve the problems explained in http://tools.ietf.org/html/draft-reddy-behave-turn-auth-02, TURN over DTLS is discussed in BEHAVE WG which addresses problems related to privacy etc.

2. To traverse restrictive firewalls that only allow HTTP/HTTPS connections by placing a TURNS server on port 443
[TR] But those restrictive firewall mostly also perform DPI.
--Tiru.
I would think that for those two reasons TURN-TLS should be MUST implement.
_____________
Roman Shpount

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 20 Aug 2013 09:25:35 +0200

> If per-*packet* DSCP setting is necessary (such as when bundling is used), both Section 2.1 and 2.2 should clarify that requirement.  For example FreeBSD's IPv4 stack didn't have that capability re…
Support for per-packet TOS/DSCP information to be received/sent was added in FreeBSD 8.4 and 9.1...

Best regards
Michael

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 20 Aug 2013 09:09:23 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Dan Wing (dwing)
> Sent: Tuesday, August 20, 2013 11:46 AM
> To: Bernard Aboba
> Cc: [email-masked]
> > > ICE-TCP allows direct peer-to-peer communications using TCP, without a
> TURN server doing TCP-to-UDP interworking. I would say the industry has less
> experience with ICE-TCP than with ICE or with TURN-over-TCP, and because of
> the less experience and because ICE-TCP is arguably an *optimization*, I would
> say ICE-TCP is a MAY. It can't be a MUST-level requirement, at least by my
> threshold for MUST which is that interoperability is harmed or
> interoperability is impossible.
> >
> > [BA]  While ICE-TCP will only eliminate the need for TURN over TCP in a
> fraction of NAT usage cases, the benefits can be substantial in the situations
> where it does work (and is needed).  The most popular uses of ICE-TCP so far
> are for things like P2P chat (e.g. MSRP), application sharing and RTP over
> TCP.  Given that WebRTC  could implement MSRP over the data channel, and could
> handle screen sharing via RTP over UDP,  the case probably needs to be made
> based on TURN-less conveyance of RTP over TCP (probably in a consumer scenario
> only, since for enterprise the TURN server would most likely be needed for
> firewall traversal reasons).  It's definitely not a MUST, and probably not a
> SHOULD either for WebRTC.
> >
> achieved with TURN REST (draft-uberti-behave-turn-rest and draft-uberti-
> rtcweb-turn-rest). I think the working group should consider if TURN REST
> satisfies the requirements, or if TURN over TLS is really, really necessary.
> >
> > [BA] Not sure I follow this.   TURN over TLS provides confidentiality for
> the relay addresses and also some firewall traversal benefits.  TURN REST is
> trying to solve a different problem entirely (e.g. misuse of TURN
> credentials).
> 
> TURN REST solves misuse of credentials and significantly reduces ability to do
> traffic analysis of the TURN client by someone sniffing between the TURN
> client and TURN server (username="dwing" sent plaintext between the TURN
> client and TURN server).

TURN REST resolves the problem of third party authorization but does not address other problems like TURN server deployed in Enterprise for auditing purpose (which requires first party authentication - username needs to sent over TURN over TLS).

--Tiru.

> 
> > Personally, I don't think TURN REST really minimizes the risk to the extent
> necessary, since time limiting the credentials alone won't necessarily stop an
> ingenious (and greedy) thief.  As an example, when hackers gain control of a
> PBX they can run up shocking bills in a very short period of time, and even if
> TURN charges are minimal, you'd be surprised at what Internet miscreants can
> do with stolen credentials within a 24 hour period.  So to my mind, TURN REST
> needs some additional bolstering to limit the potential financial liability,
> such as bandwidth limits.
> 
> I expect something like a bandwidth limit is something that can be encoded
> into the TURN REST username that is coordinated between the WebRTC server and
> its cooperative TURN server.  It might be better to encode that properly,
> rather than by overloading bits of the username.  But perhaps a more elegant
> solution, rather than bandwidth limits, could be engineered.
> 
> -d
>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 20 Aug 2013 09:36:01 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Tuesday, August 20, 2013 11:32 AM
To: Dan Wing (dwing); Harald Alvestrand
Cc: [email-masked]
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-00.txt

> ICE-TCP allows direct peer-to-peer communications using TCP, without a TURN server doing TCP-to-UDP interworking. I would say the industry has less experience with ICE-TCP than with ICE or with TUR…

[BA]  While ICE-TCP will only eliminate the need for TURN over TCP in a fraction of NAT usage cases, the benefits can be substantial in the situations where it does work (and is needed).  The most popular uses of ICE-TCP so far are for things like P2P chat (e.g. MSRP), application sharing and RTP over TCP.  Given that WebRTC  could implement MSRP over the data channel, and could handle screen sharing via RTP over UDP,  the case probably needs to be made based on TURN-less conveyance of RTP over TCP (probably in a consumer scenario only, since for enterprise the TURN server would most likely be needed for firewall traversal reasons).  

[TR] Firewall traversal problems in Enterprise can also be resolved by using PCP-controlled Firewall without the need for TURN server and is discussed in sections 3.1, 3.2 of draft http://tools.ietf.org/html/draft-penno-rtcweb-pcp-00 

--Tiru.

It's definitely not a MUST, and probably not a SHOULD either for WebRTC.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 20 Aug 2013 12:43:12 +0200

> TURN REST solves misuse of credentials and significantly reduces ability to do traffic analysis of the TURN client by someone sniffing between the TURN client and TURN server (username="dwing" sent…

Perhaps the -security- drafts might contain a recommendation that 
usernames for use in TURN authentications should be anonymous, 
single/limited use?

I don't want to have the RTCWEB transport stack depend on a specific 
username allocation mechanism like draft-uberti-rtcweb-turn-rest, but a 
generic recommendation to not give traceable tokens in TURN 
authentication might be a good idea.

---

From: Dan Wing <[email-masked]>
Date: Tue, 20 Aug 2013 08:27:25 -0700

> Support for per-packet TOS/DSCP information to be received/sent was added in FreeBSD 8.4 and 9.1...

Yes, that is what the URL I cited says.  But more important than celebrating that FreeBSD was recently updated to get this capability is that the I-D document this as a requirement of the underlying OS.

-d

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 20 Aug 2013 18:28:45 +0200

> Yes, that is what the URL I cited says.  But more important than celebrating that FreeBSD was recently updated to get this capability is that the I-D document this as a requirement of the underlyin…
Understood. Guess why it appeared in FreeBSD... Just wanted to make clear that it
us supported at least now. I missed the statement in the PR that it made it into 8.4...

Best regards
Michael

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 20 Aug 2013 16:31:28 +0000

Section 2.2 "Middle Box Related Functions" should also I assume cover the case of using a HTTP Proxy or an enterprise TURN server and reference http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-01 assuming we can get this adopted.

Regards
Andy

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: 19 August 2013 18:15
> To: [email-masked]
> Cc: [email-masked]
> Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-00.txt
> 
>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 20 Aug 2013 14:44:14 -0700

The NAT/Firewall considerations document does go into detail on the various traversal scenarios, which helps inform the discussion of what should or should not be supported in terms of transport.  Section 5 summarizes the recommendations as follows: 

5.  Requirements for RTCWEB-enabled browsers

   For the purpose of relaying RTCWEB media streams or data channels a
   browser needs to be able to

   o  connect to a TURN server via UDP, TCP and TLS,

   o  connect to a TURN server via a HTTP proxy using the HTTP connect
      method,

   o  connect to a TURN server via the HTTP(s) ports 80/443 instead of
      the default STUN ports 3478/5349,

   o  upgrade the HTTP proxy-relayed connection to the TURN server to
      use TLS,

   o  use the same proxy selection procedure for TURN as currently done
      for HTTP,

   o  switch the usage of the HTTP proxy-relayed connection with the
      TURN server from HTTP to STUN/TURN,

   o  use a preconfigured or standardized port range for UDP-based media
      streams or data channels,

   o  learn from the proxy configuration script about the presence of a
      local TURN server and use it for sending UDP traffic to the
      internet,

   o  support ICE-TCP for TCP-based direct media connection to the
      RTCWEB peer.

> From: [email-masked]
> To: [email-masked]; [email-masked]
> Date: Tue, 20 Aug 2013 16:31:28 +0000

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 23 Aug 2013 17:44:10 +0200

> Section 2.2 "Middle Box Related Functions" should also I assume cover the case of using a HTTP Proxy or an enterprise TURN server and reference http://tools.ietf.org/html/draft-hutton-rtcweb-nat-fi…
Chairs, where are we on the question of whether the WG wants to adopt
-firewall- or not?

       Harald