Subject: [rtcweb] Same location media

From: Roman Shpount <[email-masked]>
Date: Thu, 20 Oct 2011 12:27:29 -0400

Changing the topic from "A plea for simplicity, marketability..."

On Thu, Oct 20, 2011 at 11:57 AM, Iñaki Baz Castillo <[email-masked]> wrote:

> Also you are asuming that the media is sent to the same IP of the web
> server (in case a RTCweb scenario does not include user2user calls).
> This is a too much simplified scenario, and you miss that a DNS A
> record can point to N IP's, and you also miss the case in which the
> webserver has an IP different than the media server (regardless they
> both are located within the same provider infrastucture). The browser
> cannot determine it by itself, so security is always a need, and IMHO
> it's a bad idea to allow a very corner case in which such security
> could be relaxed.
>
>
I am not missing the DNS issues. I wanted to bring this up in my previous
email, but did not want to confuse the issue. I don't advocate for this case
at all, I just wanted to clarify that "same origin media" does not
necessarily mean two phones in the same location and means media going to
the same location as JavaScript origination.

Few additional points related to this:

1. This is what Flash is doing now for streaming media. It does not need
consent to send media to the same server that sent the flash app.

2. I am not sure we standardized that only IP addresses are allowed in media
description.DNS names might still be allowed then this issue will become the
issue of doing a literal match.

3. There is still a security issue with ICE: we validate that STUN request
can be processed, but not that the media actually should be accepted from
this application. In some sense, current Flash cross domain polices are
stricter, since they not only validate that media is acceptable at this IP
but that it is acceptable from the app served from particular server.

In general, I think this is a good thing if I can get readily available
hardware components and connect RTC clients to my existing infrastructure (I
do have an JavaScript/HTTP to SIP proxy solution already). If we are not
breaking anything by doing this, there might be some benefit for allowing
this. But on the other hand, I already got ICE/SRTP to non-ICE/RTP media
proxy as well, so if this is not supported I will not suffer much :).

_____________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 20 Oct 2011 09:30:22 -0700

> but that it is acceptable from the app served from particular server.

Unless I'm confused, you get a similar check with ICE because the target
needs not only to respond to STUN in general but also to STUN with
particular credentials, which means that the target can enforce that only
specific sites get those credentials.

-Ekr

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 20 Oct 2011 09:41:47 -0700

Roman said: 

"Few additional points related to this:

1. This is what Flash is doing now for streaming media. It does not need consent to send media to the same server that sent the flash app.

2. I am not sure we standardized that only IP addresses are allowed in media description. DNS names might still be allowed then this issue will become the issue of doing a literal match.

3. There is still a security issue with ICE: we validate that STUN request can be processed, but not that the media actually should be accepted from this application. In some sense, current Flash cross domain polices are stricter, since they not only validate that media is acceptable at this IP but that it is acceptable from the app served from particular server.

In general, I think this is a good thing if I can get readily available hardware components and connect RTC clients to my existing infrastructure (I do have an JavaScript/HTTP to SIP proxy solution already). If we are not breaking anything by doing this, there might be some benefit for allowing this. But on the other hand, I already got ICE/SRTP to non-ICE/RTP media proxy as well, so if this is not supported I will not suffer much :)."

[BA]  Good points.  

One of the requirements in the use case document is the ability to work across firewalls that do not permit UDP.  In practice, this constraint is encountered surprisingly often (as much as 15-25% of the time, in enterprise scenarios).   The implication is that ICE will require a fallback, such as sending media over HTTP.   In a fallback situation, requiring ICE would be silly, since it has typically failed in order for fallback to be considered.

---

From: Roman Shpount <[email-masked]>
Date: Thu, 20 Oct 2011 12:45:23 -0400

On Thu, Oct 20, 2011 at 12:41 PM, Bernard Aboba
<[email-masked]>wrote:

> One of the requirements in the use case document is the ability to work
> across firewalls that do not permit UDP.  In practice, this constraint is
> encountered surprisingly often (as much as 15-25% of the time, in enterprise
> scenarios).   The implication is that ICE will require a fallback, such as
> sending media over HTTP.   In a fallback situation, requiring ICE would be
> silly, since it has typically failed in order for fallback to be
> considered.
>

Technically speaking, if TURN server relay address is used, connectivity
between the RTC client and TURN server can be TCP (or TLS). So, ICE check
would be delivered to the RTC client via TCP tunnel.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Thu, 20 Oct 2011 12:48:13 -0400

> specific sites get those credentials.
You are right. It was me who was confused. With ICE it is even stricter,
since the per call credentials are used. What I am concerned about, is there
a way to game those credentials (which can be sent by a malicious web
server) to allow ICE check to succeed when used against a public STUN server
with known credentials?
_____________
Roman Shpount

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 20 Oct 2011 09:48:21 -0700

Roman said:

"Technically speaking, if TURN server relay address is used, connectivity between the RTC client and TURN server can be TCP (or TLS). So, ICE check would be delivered to the RTC client via TCP tunnel."

[BA] Yes, that can be done.  But often we find that a firewall that does not permit UDP traversal also has strict policies about TCP (e.g. only to a strict set of destination ports).    This is why HTTP traversal is implemented by almost all Web conferencing services.

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 20 Oct 2011 09:48:41 -0700

On 10/20/11 9:27 AM, Roman Shpount wrote:
> On Thu, Oct 20, 2011 at 11:57 AM, Iñaki Baz Castillo <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> I am not missing the DNS issues. I wanted to bring this up in my 
> previous email, but did not want to confuse the issue. I don't 
> advocate for this case at all, I just wanted to clarify that "same 
> origin media" does not necessarily mean two phones in the same 
> location and means media going to the same location as JavaScript 
> origination.
>
> 1. This is what Flash is doing now for streaming media. It does not 
> need consent to send media to the same server that sent the flash app.

Flash can send media to ANY server that accepts the RTMP or RTMFP 
connection. (And obviously it can attempt to open a connection to any 
address using these protocols.)

The server can then examine headers to determine where the SWF file came 
from, etc.

The "consent" model for Flash is that if you speak RTMP or RTMFP, you 
understand what that is... and neither protocol looks like anything else 
on the wire.

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 20 Oct 2011 09:51:12 -0700

On 10/20/11 9:41 AM, Bernard Aboba wrote:
>
> One of the requirements in the use case document is the ability to 
> work across firewalls that do not permit UDP.  In practice, this 
> constraint is encountered surprisingly often (as much as 15-25% of the 
> time, in enterprise scenarios).   The implication is that ICE will 
> require a fallback, such as sending media over HTTP.

The fallback that has been proposed in every document I've ever seen is 
TURN over TCP/TLS. (Not arguing that this is sufficient... the fact is 
that sending media over port 80 may be advantageous, and being able to 
send it through web proxies might be even better.)

>   In a fallback situation, requiring ICE would be silly, since it has 
> typically failed in order for fallback to be considered.

STUN connectivity checks can proceed with the far end of a 
TURN-forwarded connection.

Matthew Kaufman

---

From: Roman Shpount <[email-masked]>
Date: Thu, 20 Oct 2011 12:52:52 -0400

On Thu, Oct 20, 2011 at 12:48 PM, Bernard Aboba
<[email-masked]>wrote:

>  Roman said:
>
> "Technically speaking, if TURN server relay address is used, connectivity
> would be delivered to the RTC client via TCP tunnel."
>
> [BA] Yes, that can be done.  But often we find that a firewall that does
> not permit UDP traversal also has strict policies about TCP (e.g. only to a
> strict set of destination ports).    This is why HTTP traversal is
> implemented by almost all Web conferencing services.
>
>
You can also operate a TURN server on TCP port 80 and TLS port 443. In case
of TLS connection firewall will have no way to distinguish TURN TLS traffic
from HTTPS traffic. Support for HTTP/SOCKS based connections to TURN servers
can be implemented as well. BTW, this is why it is essential to be able to
specify TURN server location via JavaScript to the RTC client.
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 20 Oct 2011 18:55:59 +0200

2011/10/20 Bernard Aboba <[email-masked]>:
> [BA] Yes, that can be done.  But often we find that a firewall that does not
> permit UDP traversal also has strict policies about TCP (e.g. only to a

Well, if the network admin does not want that internet works, then
this is the end. But we cannot follow the "WWW vision" of making
internet just TCP port 80/443.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 20 Oct 2011 10:02:29 -0700

Roman said:

"You can also operate a TURN server on  TCP port 80 and TLS port 443. In case of TLS connection firewall will have no way to distinguish TURN TLS traffic from HTTPS traffic. Support for HTTP/SOCKS based connections to TURN servers can be implemented as well. BTW, this is why it is essential to be able to specify TURN server location via JavaScript to the RTC client."

[BA] With respect to TURN with TCP/TLS we have found some firewalls that actually do deep packet inspection.  So if you're sending to TCP port 80 and aren't using HTTP, or are sending to port 443 and aren't using TLS (or are using TLS extensions the firewall doesn't understand), the firewall can block.   So yes, it is important to support TURN with TCP/TLS, but it should be recognized that even with that, there will still be a significant percentage of failures.

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 20 Oct 2011 17:16:52 +0000

I may be mis-understanding what type of consent you folks are talking about, but RTMP is over TCP.  
For any TCP-based mechanism, you get some "consent" from the TCP SYN/ACK you get back from the far end, as opposed to say an ICMP port error.  Since the TCP layer won't send data until that, it's a natural consent gate.

RTMFP uses UDP but I believe there is in fact a handshake required in the beginning and that's effectively consent.
 
-hadriel

On Oct 20, 2011, at 12:48 PM, Matthew Kaufman wrote:

> Flash can send media to ANY server that accepts the RTMP or RTMFP connection. (And obviously it can attempt to open a connection to any address using these protocols.)
> 
> The server can then examine headers to determine where the SWF file came from, etc.
> 
> The "consent" model for Flash is that if you speak RTMP or RTMFP, you understand what that is... and neither protocol looks like anything else on the wire.
> 
> Matthew Kaufman
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Michael Thornburgh <[email-masked]>
Date: Thu, 20 Oct 2011 10:58:19 -0700

correct. RTMP is over TCP to a server, and has the TCP handshake *plus* the RTMP handshake *plus* any application-level authentication required by the RTMP server.

RTMP can also be tunneled over HTTP.

RTMFP is over UDP and has its own 4-way handshake (see Matthew's presentation to tsv-area at IETF 77 for what that handshake looks like). when communicating with a server, a client must perform the RTMFP handshake plus any application-level authentication required by the server. to communicate with a peer (another client), a client must perform the RTMFP handshake with that peer, which requires knowing that peer's unique cryptographic peer ID. the handshake won't work if the destination doesn't speak RTMFP or if the destination isn't the peer that the initiator is trying to reach.

-mike

---

From: Roman Shpount <[email-masked]>
Date: Thu, 20 Oct 2011 13:58:40 -0400

On Thu, Oct 20, 2011 at 1:02 PM, Bernard Aboba <[email-masked]>wrote:

>  [BA] With respect to TURN with TCP/TLS we have found some firewalls that
> actually do deep packet inspection.  So if you're sending to TCP port 80 and
> aren't using HTTP, or are sending to port 443 and aren't using TLS (or are
> using TLS extensions the firewall doesn't understand), the firewall can
> block.   So yes, it is important to support TURN with TCP/TLS, but it should
> be recognized that even with that, there will still be a significant
> percentage of failures.
>

TURN over TLS is non-distinguishable (unless I am missing something) from
HTTPS connection. It is using the same TLS transport as HTTPS and firewall
cannot inspect the actual data transmitted. Firewall can probably do some
sort of heuristics based on packet sizes, but this will not be reliable
enough to distinguish TURN over TLS from HTTPS (or real time media over
HTTPS). In any case, if people are persistent enough they will find the way
to block RTC connections regardless of the protocol used.
_____________
Roman Shpount

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 20 Oct 2011 11:05:39 -0700

Yes, Turn over TLS is non-distinguishable.  However, we've found deep inspection firewalls that will actually attempt to parse the TLS negotiation.  This creates brittleness to extensions in general.  Anything that is not "vanilla" could potentially fall prey, including TLS extensions, Websockets, etc.  Sad, but true.

Date: Thu, 20 Oct 2011 13:58:40 -0400
Subject: Re: [rtcweb] Same location media
From: [email-masked]
To: [email-masked]
CC: [email-masked]

On Thu, Oct 20, 2011 at 1:02 PM, Bernard Aboba <[email-masked]> wrote:

TURN over TLS is non-distinguishable (unless I am missing something) from HTTPS connection. It is using the same TLS transport as HTTPS and firewall cannot inspect the actual data transmitted. Firewall can probably do some sort of heuristics based on packet sizes, but this will not be reliable enough to distinguish TURN over TLS from HTTPS (or real time media over HTTPS). In any case, if people are persistent enough they will find the way to block RTC connections regardless of the protocol used.

_____________
Roman Shpount

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 21 Oct 2011 12:58:44 +0300

On 10/20/11 9:05 PM, Bernard Aboba wrote:
> Yes, Turn over TLS is non-distinguishable.  However, we've found deep 
> inspection firewalls that will actually attempt to parse the TLS 
> negotiation.  This creates brittleness to extensions in general.  
> Anything that is not "vanilla" could potentially fall prey, including 
> TLS extensions, Websockets, etc.  Sad, but true.
but then also your fallback proposal to send media on WebSocket
can potentially fall, isn't it?
or am I missing something?

/Sal
>
> ------------------------------------------------------------------------
> On Thu, Oct 20, 2011 at 1:02 PM, Bernard Aboba 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     [BA] With respect to TURN with TCP/TLS we have found some
>     firewalls that actually do deep packet inspection.  So if you're
>     sending to TCP port 80 and aren't using HTTP, or are sending to
>     port 443 and aren't using TLS (or are using TLS extensions the
>     firewall doesn't understand), the firewall can block.   So yes, it
>     is important to support TURN with TCP/TLS, but it should be
>     recognized that even with that, there will still be a significant
>     percentage of failures.
>
>
> TURN over TLS is non-distinguishable (unless I am missing something) 
> from HTTPS connection. It is using the same TLS transport as HTTPS and 
> firewall cannot inspect the actual data transmitted. Firewall can 
> probably do some sort of heuristics based on packet sizes, but this 
> will not be reliable enough to distinguish TURN over TLS from HTTPS 
> (or real time media over HTTPS). In any case, if people are persistent 
> enough they will find the way to block RTC connections regardless of 
> the protocol used.
> _____________
> Roman Shpount
>
>

---

From: Jozsef Vass <[email-masked]>
Date: Fri, 21 Oct 2011 13:28:47 -0700

As for Flash, I think your are referring to the same origin policy and not media, which is true for all browsers. That means, that http://www.a.com/a.swf cannot load http://www.b.com/data.txt without an explicit permission by a cross-domain policy file.

Jozsef

From: Roman Shpount [mailto:[email-masked]]
Sent: Thursday, October 20, 2011 9:27 AM
To: Iñaki Baz Castillo
Cc: [email-masked]
Subject: [rtcweb] Same location media

On Thu, Oct 20, 2011 at 11:57 AM, Iñaki Baz Castillo <[email-masked]<mailto:[email-masked]>> wrote:

I am not missing the DNS issues. I wanted to bring this up in my previous email, but did not want to confuse the issue. I don't advocate for this case at all, I just wanted to clarify that "same origin media" does not necessarily mean two phones in the same location and means media going to the same location as JavaScript origination.

2. I am not sure we standardized that only IP addresses are allowed in media description.DNS names might still be allowed then this issue will become the issue of doing a literal match.

In general, I think this is a good thing if I can get readily available hardware components and connect RTC clients to my existing infrastructure (I do have an JavaScript/HTTP to SIP proxy solution already). If we are not breaking anything by doing this, there might be some benefit for allowing this. But on the other hand, I already got ICE/SRTP to non-ICE/RTP media proxy as well, so if this is not supported I will not suffer much :).

_____________
Roman Shpount