Subject: [rtcweb] draft-jesup-rtcweb-data-00 posted

From: Randell Jesup <[email-masked]>
Date: Mon, 24 Oct 2011 18:44:22 -0400

A new version of I-D, draft-jesup-rtcweb-data-00.txt has been 
successfully submitted by Randell Jesup and posted to the IETF repository.

Filename:	 draft-jesup-rtcweb-data
Revision:	 00
Title:		 RTCWeb Datagram Connection
Creation date:	 2011-10-25
WG ID:		 Individual Submission
Number of pages: 11

Abstract:
    This document investigates the possibilities for designing a generic
    transport service that allows Web Browser to exchange generic data in
    a peer to peer way.  Different transport protocols and their
    properties are investigated in order to identify the most appropriate
    one.

URL:  http://www.ietf.org/id/draft-jesup-rtcweb-data-00.txt

-- 
Randell Jesup
[email-masked]

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 25 Oct 2011 08:02:47 +0000

Hi Randell,
What do you think about the following additional requirements:

Req. 7: Data streams MUST provide fragmentation at a layer above UDP, such that IP-layer fragmentation does not occur no matter how large a message/buffer the Javascript application passes down to the Browser to be sent out.

Req. 8: The data stream transport protocol MUST NOT encode IP addresses inside its protocol fields; doing so reveals potentially private information, and leads to failure if the address is depended upon. 

Req. 9: The data stream protocol SHOULD support unbounded-length "messages" (i.e., a virtual socket stream) at the application layer, for such things as image-file-transfer; or else it MUST support at least a maximum application-layer message size of 4GB.

Req. 10: The data stream packet format/encoding MUST be such that it is impossible for a malicious Javascript to generate an application message crafted such that it could be interpreted as a native protocol over UDP - such as UPnP, RTP, SNMP, STUN, etc. 

I believe SCTP can do 7+8+9 the above if its options are chosen right, and of course TCP can.
And I'm guessing DTLS will satisfy 10 above, as would websockets-style masking.

-hadriel

On Oct 24, 2011, at 6:44 PM, Randell Jesup wrote:

> A new version of I-D, draft-jesup-rtcweb-data-00.txt has been successfully submitted by Randell Jesup and posted to the IETF repository.
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 25 Oct 2011 07:20:17 -0700

> Req. 8: The data stream transport protocol MUST NOT encode IP addresses inside its protocol fields; doing so reveals potentially private information, and leads to failure if the address is depended…

I don't really understand what this means. In general, the peer has
access to your IP address
information from ICE.

> Req. 10: The data stream packet format/encoding MUST be such that it is impossible for a malicious Javascript to generate an application message crafted such that it could be interpreted as a nativ…

I'm not sure this is really an issue the way you raise it. It's clear
that you shouldn't be able to
generate messages that appear to be STUN or RTP but that's necessary
for demux to work
right. However, given that the other side has consented, I don't see
that confusion with
other protocols being an issue. The kind of intercepting proxies that
we found for
HTTP don't seem to be a feature of the UDP environment.

-Ekr

---

From: Randell Jesup <[email-masked]>
Date: Tue, 25 Oct 2011 10:42:50 -0400

On 10/25/2011 4:02 AM, Hadriel Kaplan wrote:
> Req. 7: Data streams MUST provide fragmentation at a layer above UDP, such
 > that IP-layer fragmentation does not occur no matter how large a 
message/buffer
 > the Javascript application passes down to the Browser to be sent out.
>
> Req. 8: The data stream transport protocol MUST NOT encode IP addresses
> inside its protocol fields; doing so reveals potentially private information,
 > and leads to failure if the address is depended upon.
>
> Req. 9: The data stream protocol SHOULD support unbounded-length "messages"
> (i.e., a virtual socket stream) at the application layer, for such things as
> image-file-transfer; or else it MUST support at least a maximum
 > application-layer message size of 4GB.
>
> Req. 10: The data stream packet format/encoding MUST be such that it is
 > impossible for a malicious Javascript to generate an application message
 > crafted such that it could be interpreted as a native protocol over UDP -
 > such as UPnP, RTP, SNMP, STUN, etc.

Thanks, those look useful.  I'm not sure if Req 8 should be reworded to 
be more explicit (local IP address?)  For Req 7, I think that when 
applied to unreliable data channels, entire fragmented messages must be 
delivered or none of the fragments delivered to the application.

> I believe SCTP can do 7+8+9 the above if its options are chosen right, and of course TCP can.

Yes, I believe so - for Req 9, SOCK_STREAM can be used to provide a 
TCP-like interface to SCTP.

Do any of the above only apply to reliable data channels, in particular 
Req 9?

> And I'm guessing DTLS will satisfy 10 above, as would websockets-style masking.

Yes.

-- 
Randell Jesup
[email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Tue, 25 Oct 2011 07:56:49 -0700

Hi Hadriel,

I'm finding this requirement to be oddly worded:

> message/buffer the Javascript application passes down to the Browser to be
> sent out.
>
>
Isn't the issue that the data stream must understand the path MTU and must
chunk the data so as to avoid IP fragmentation?  If it did not, it could run
into IP-layer fragmentation even with a relatively small amount of traffic
to send.  Why tie that requirement either to a "layer above UDP" (since
running this over UDP is not decided) or to the size of the data to be
passed?

I'm guessing that at the back of this is a requirement like "Please, don't
make the downloaded javascript application figure out how to chop up the
data to make it pass unmolested over the path".  I heartily agree with that,
but if I'm understanding you right, that would be:

Req. 7:  Data streams must avoid IP-layer fragmentation without requiring
the Javascript application to restrict the size of messages to be passed
over the channel.

Does that make sense?

regards,

Ted

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 25 Oct 2011 15:31:30 +0000

>From a privacy perspective: if a person uses a Web-site designed with privacy/anonymity in mind (e.g., battered-spouse forum), then the site would relay your media-plane stuff through a type of TURN server that does ICE itself both ways.  But if the SCTP layer on top of UDP encodes your local IP using one of the optional SCTP fields in RFC 4960 or 5061, then you lose that anonymity.  Since the SCTP layer is built into the Browser and not under control of the Javascript, a site can't prevent it from revealing that info.

>From a failure perspective: if the SCTP layer on top of UDP encodes local or remote IP addresses using an SCTP field, presumably it does so for some purpose.  Since history has shown that relying on embedded IP Addresses for anything is prone to failure due to the proliferation of NATs, double-NATs, v4-v6 NATs, etc., then we shouldn't want SCTP to rely on such being useful.  The best way to make sure it can't rely on them, is not to use any to begin with. :)

> right.

Yes I didn't mean to imply it would be hard to satisfy the requirement, or not necessary for other reasons.  I suggested it because some people wanted to do raw UDP a while ago and this requirement's there to show we can't do raw UDP.

> However, given that the other side has consented, I don't see
> that confusion with

I don't know that intercepting middleboxes don't exist for any/all random UDP-based protocol.  I wouldn't be surprised to find there are for DNS, for example.  But you're talking about for ever, not just now.  I don't have a crystal ball.  Regardless, I would expect this requirement to be achieved easily, no?

-hadriel

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 25 Oct 2011 08:38:19 -0700

On Tue, Oct 25, 2011 at 8:31 AM, Hadriel Kaplan <[email-masked]> wrote:
>=
OK. Sold.

> Yes I didn't mean to imply it would be hard to satisfy the requirement, or not necessary for other reasons.  I suggested it because some people wanted to do raw UDP a while ago and this requirement…

OK.

> I don't know that intercepting middleboxes don't exist for any/all random UDP-based protocol.  I wouldn't be surprised to find there are for DNS, for example.  But you're talking about for ever, no…

So, I was thinking no, but now that I think about it harder, the
answer is yes. :) [*]

-Ekr

[*] The technical reason here is that it's not easy for TLS < 1.1, but
it is easy for
DTLS, due to the way CBC mode is used in the different protocols.

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 25 Oct 2011 15:50:47 +0000

Actually that is also a requirement, but not the one I was worried about. :)

My concern is that there will be IP-layer fragmentation - even if the IP fragments successfully get delivered to the far end.  Consumer NATs, Corp Firewalls, and CGNs have a really hard time with IP-layer fragmentation; in some cases they will block it altogether, in other cases they'll handle a small restricted volume of it.  Some IP routers and CGNs, for example, play tricks with the MSS in TCP to prevent IP-layer fragmentation of TCP segments.

Since UDP has no MSS-equivalent, and no UDP-layer segmentation/chunking, we need it at a layer above UDP so that every IP+UDP packet coming out of the Browser's OS is a whole UDP packet and no IP-layer fragmentation occurs.

In fact, I wonder if we shouldn't add an MSS-type thing for this data channel, in STUN/ICE since it's now a virtual connection "handshake".

-hadriel

On Oct 25, 2011, at 10:56 AM, Ted Hardie wrote:

Hi Hadriel,

Isn't the issue that the data stream must understand the path MTU and must chunk the data so as to avoid IP fragmentation?  If it did not, it could run into IP-layer fragmentation even with a relatively small amount of traffic to send.  Why tie that requirement either to a "layer above UDP" (since running this over UDP is not decided) or to the size of the data to be passed?

I'm guessing that at the back of this is a requirement like "Please, don't make the downloaded javascript application figure out how to chop up the data to make it pass unmolested over the path".  I heartily agree with that, but if I'm understanding you right, that would be:

Req. 7:  Data streams must avoid IP-layer fragmentation without requiring the Javascript application to restrict the size of messages to be passed over the channel.

Does that make sense?

regards,

Ted

---

From: Randell Jesup <[email-masked]>
Date: Thu, 27 Oct 2011 15:06:41 -0400

On 10/25/2011 11:31 AM, Hadriel Kaplan wrote:
>> On Tue, Oct 25, 2011 at 1:02 AM, Hadriel Kaplan<[email-masked]>  wrote:

There's a corollary: a user should be able to set their browser and/or 
App to force all incoming calls (and maybe outgoing) through a TURN 
server.  (There may be other uses for this ability, like corporate 
firewall traversal, but the case you mention is one of them).  Witness 
the recent attack on identity info on Skype using call-setup protocols, 
without even decoding them:

http://www.theregister.co.uk/2011/10/21/skype_bittorrent_stalking/print.html
and
http://cis.poly.edu/~ross/papers/skypeIMC2011.pdf

In theory it could be more nuanced - direct connections for people in 
your phonebook, or listed as friends, etc.  But that may be too 
confusing for generic users, and too likely to mess up.

This is more likely a W3C issue, so CC-ing that list

-- 
Randell Jesup
[email-masked]

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Oct 2011 04:05:47 +0000

Yeah I've kept meaning to email that draft-ietf-rtcweb-security-00 is great but misses a class of issues around privacy we've had to deal with in SIP.  For example if a session-request is received by the Browser and ICE procedures are allowed to start before the human user issues consent, then the far-end peer learns your local IP or your Firewall pinhole.  One of the things they can do with that, for example, is learn roughly where you are, given current IP-geo databases.

For example if I use Facebook to call Domino's for pizza, Domino's learns the town I live in.  They would consider that a feature. :)
But if the delivery guy in Domino's can someday later make a call back to me through Domino's Facebook account and using wireshark see if my ICE-learned IP isn't in my town or even State, without me even accepting the session request, that's not good.  Heck, I'm not even sure it's good to do if I do accept the session request.

The problem is I'm not sure there's any way to explain these types of things and warn Web-app domain admins or JS developers to think about, let alone normal users, without causing WebRTC to get a bad reputation or scare people.

-hadriel

On Oct 27, 2011, at 3:06 PM, Randell Jesup wrote:

> There's a corollary: a user should be able to set their browser and/or App to force all incoming calls (and maybe outgoing) through a TURN server.  (There may be other uses for this ability, like corporate firewall traversal, but the case you mention is one of them).  Witness the recent attack on identity info on Skype using call-setup protocols, without even decoding them:
> 
> In theory it could be more nuanced - direct connections for people in your phonebook, or listed as friends, etc.  But that may be too confusing for generic users, and too likely to mess up.
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 27 Oct 2011 21:08:52 -0700

Thanks for pointing this out. I'll amend the document to mention this issue...

-Ekr

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 30 Oct 2011 14:51:05 -0600

+1