Subject: Re: [rtcweb] Non-media data service consensus and requirements

From: Bernard Aboba <[email-masked]>
Date: Mon, 27 Jun 2011 15:35:10 -0700

I do not support an unreliable datagram service that can be used to send arbitrary data.  

For example, it seems dangerous for a Web browser under the control of an attacker to be able to send RIP, SNMP or DNS packets to arbitrary destinations. 

For these transactional exchanges the overhead of ICE would be excessive and so there will be a very strong temptation to cut corners. 

Assuming that the goal is not to send arbitrary data, then we need to dig into the transport requirements more. 

For example, is the non-media data to be synchronized with media (e.g. real-time text)?

Is there a session associated with the non-media data (e.g. XMPP or MSRP exchanges)? 

Is there a reliability requirement? 

Is it congestion-controlled? 

How long-lived are the flows? 

---------------------------------------------------
From: [email-masked]
To: [email-masked]
Date: Mon, 27 Jun 2011 09:36:30 +0200
Subject: [rtcweb] Non-media data service consensus and requirements

WG,
 
At the interim it was planned to have a bit discussion on the datagram
service for RTCWEB. The first question to try to resolve if there
is consensus for including some form of non real-time media (i.e. not
audio, video) service between peers. This is a bit tangled with the
actual requirements and use cases. But there was views both for it and
against it on the mailing list. So lets continue and try to come to a
conclusion on this discussion.
 
The use cases mentioned on the mailing list are:
 
- Dynamic meta data for Conference and other real-time services
 
- Gaming data with low latency requirements
 
Does anyone like to add additional use cases?
 
Based on my personal understanding this points to primarily have the
RTCWEB provide a unreliable datagram service. This clearly needs
additional requirements to be secure and safe to deploy, but more about
this below. I still like to ask the WG here a question.
 
Are you supporting the inclusion of a unreliable datagram service
directly between peers? Please provide your view and any additional
statements of motivation that you desire to provide.
 
Secondly, there is a question if there needs to have something that
provides reliable message (of arbitrary size) or byte stream oriented
data transport between the peers. I personally foresee that people will
build JS libraries for this on top of a unreliable datagram service. If
you desire reliable data service as part of the standardized solution
please provide motivation and use case and requirements.
 
I also want to take a stab on what I personally see as the requirements
that exist on unreliable datagram service in the context of RTCWEB.
 
- Unreliable data transmission
- Datagram oriented
   * Size limited by MTU
     - Path MTU discovery needed
   * Fragmentation by the application
- Low latency, i.e. Peer to Peer preferable
- Congestion Controlled, to be
   * Network friendly
   * Not become a Denial of Service tool
- Security
  * Confidentiality
  * Integrity Protected
  * Source Authenticated (at least bound to the signalling peer)
  * Ensure consent to receive data
 
Please debate the above. This is an attempt to ensure that we can
establish WG consensus on both data service and any requirements.
 
cheers
 
Magnus Westerlund
 
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Emil Ivov <[email-masked]>
Date: Tue, 28 Jun 2011 00:43:13 +0200

На 28.06.11 00:35, Bernard Aboba написа:
> For example, it seems dangerous for a Web browser under the control of
> an attacker to be able to send RIP, SNMP or DNS packets to arbitrary
> destinations.
> 
> For these transactional exchanges the overhead of ICE would be excessive
> and so there will be a very strong temptation to cut corners.

Well, if ICE is part of the browser we could condition sending such data
on the successful termination of ICE processing with the intended
destination. Same as with RTP. Wouldn't this work?

Emil

> Assuming that the goal is not to send arbitrary data, then we need to
> dig into the transport requirements more.
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
[email-masked]                        PHONE: +33.1.77.62.43.30
http://jitsi.org                       FAX:   +33.1.77.62.47.31

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 27 Jun 2011 15:43:41 -0700

> I do not support an unreliable datagram service that can be used to send arbitrary data.  

Mostly disagree. It should be possible to send arbitrary data from one browser to another.

> For example, it seems dangerous for a Web browser under the control of an attacker to be able to send RIP, SNMP or DNS packets to arbitrary destinations. 

Agreed, so the encapsulation must prevent this.

> For these transactional exchanges the overhead of ICE would be excessive and so there will be a very strong temptation to cut corners. 

Disagree. Browser vendors will have a strong incentive to not cut corners.

> For example, is the non-media data to be synchronized with media (e.g. real-time text)?

Maybe.

> Is there a session associated with the non-media data (e.g. XMPP or MSRP exchanges)? 

Maybe.

> Is there a reliability requirement? 

Maybe.

> Is it congestion-controlled? 

This must be enforced.

> How long-lived are the flows? 

Totally depends on the application.

Matthew Kaufman

---

From: Christopher Blizzard <[email-masked]>
Date: Mon, 27 Jun 2011 16:02:35 -0700

> destination. Same as with RTP. Wouldn't this work?

Yes, assuming that we have an established session I wouldn't support 
APIs that would allow sending of data until that session was 
established, and only to the other browser(s) in the session.

--Chris

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 27 Jun 2011 16:14:26 -0700

> destination. Same as with RTP. Wouldn't this work?

It depends on the exact requirements. 

There has already been discussion of relaxing the ICE requirement so as to better enable backward compatibility with legacy implementations (e.g. using RTCP instead).  
There is also a potential backward compatibility requirement for non-media data, which will be even more difficult, since ICE (or Jingle or SDP) is not routinely used today (think online gaming), and the volume is potentially quite heavy so that gateways may represent a significant burden.

So before saying that ICE would "solve the problem", it's important to understand what exactly the problem is. 

Are we talking about sending arbitrary data-grams in transactional exchanges?   Or perhaps text encoded in RTP?  Or maybe data in a specified encoding (e.g. not RTP or arbitrary datagrams) so as to prevent spoofing?

Are there multiple use cases here, each with slightly different requirements?

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 27 Jun 2011 16:26:13 -0700

> Are there multiple use cases here, each with slightly different requirements?   

There's quite a few possible use cases... what we're looking for is the lowest common denominator use case so we can build solutions for the rest on top of that, rather than trying to build a dozen different special-purpose protocols into the browser.

Matthew Kaufman

---

From: Emil Ivov <[email-masked]>
Date: Tue, 28 Jun 2011 08:38:06 +0200

На 28.06.11 01:14, Bernard Aboba написа:
> There has already been discussion of relaxing the ICE requirement so as
> to better enable backward compatibility with legacy implementations

I supposed I missed the discussion on dropping ICE. However, I don't
quite understand the issue with legacy implementations. If they are not
using ICE then they are most probably relying on server-side relaying
techniques such as latching. If that's the case then rtcweb clients
would establish sessions with a server which would be the one required
to do ICE (or ICE lite) rather than talking directly to the remote party.

This does indeed require the server to support ICE (lite) but is this
really an issue?

> (e.g. using RTCP instead). 

Not sure I understand. Is someone using RTCP for NAT traversal and
connectivity establishment?

> There is also a potential backward compatibility requirement for
> non-media data, which will be even more difficult, since ICE (or Jingle
> or SDP) is not routinely used today (think online gaming), and the
> volume is potentially quite heavy so that gateways may represent a
> significant burden.

Same as above. If they weren't using ICE before then they were either
relaying through a server that can now take care of ICE (lite), or they
were using a home-grown ICE variant which wouldn't be compatible anyway.
Am I missing something?

> Are we talking about sending arbitrary data-grams in transactional
> exchanges?   Or perhaps text encoded in RTP?  Or maybe data in a
> specified encoding (e.g. not RTP or arbitrary datagrams) so as to
> prevent spoofing?
> 

Right. Can we then agree that most use cases would be similar to a
regular VoIP session without the limitation of putting RTP inside packets?

Emil

-- 
http://jitsi.org

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 28 Jun 2011 08:52:31 -0400

At the interim meeting,  there was a strong argument for NOT having ICE 
as part of the browser, and I remember that no one objected.  My reading 
is that it has been the decision.

Igor

On 6/27/2011 6:43 PM, Emil Ivov wrote:
> ...

---

From: Emil Ivov <[email-masked]>
Date: Tue, 28 Jun 2011 15:28:33 +0200

> is that it has been the decision.

Well. I did attend the meeting but I remember no such decision or even
rough consensus. I actually remember people discussing the fact that
properly implementing ICE in javascript might be tricky due to the timer
granularity and the pacing requirements in 5245.

Have I missed something?

Emil

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 28 Jun 2011 16:01:03 +0200

> is that it has been the decision.

Yes, there was no such consensus decision in the interim meeting. We
haven't done a call on the list either at this point.

There was a clear question if one could implement ICE in a reasonable
way in a JS environment and meet the timing needs.

There has also been discussion on the mailing list after the Interim
that questions interoperability implications of the proposal.

So there are open questions. Please continue the various aspects so that
we can can come to a conclusion.

Cheers

Magnus Westerlund

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 28 Jun 2011 12:28:55 -0400

No, most likely it was I who missed something...  Yes, I remember the 
timer questions,  but I thought Jonathan answered this.

(By the way, I do not have a firm opinion on the subject myself, and I 
don't  understand the issues behind the performance model here.)

Surely, it is too early for the consensus to be formed, but I expect our 
esteemed chairmen to declare it at certain point because the matters 
like that ought to be settled as early as possible.

Igor

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Tue, 28 Jun 2011 10:06:36 -0700

> timer questions, but I thought Jonathan answered this.

IIRC, Harald suggested that the best way to decide if this was actually 
feasible was with "running code", at least at the proof-of-concept 
level. This seemed like a very good idea to me. The resolution of JS 
timers is not the only issue. One also has to deal with other pages with 
long-running JS scripts that prevent your timers from firing. Various 
advertisers do this on a semi-regular basis, though I don't have good 
numbers on how frequent this is, or how much of a problem it would 
really pose. Running code could be used to actually measure the 
connectivity success rate, for those that want to know.

I don't think the compatibility concerns have been addressed, either. 
With ICE in the browser, you have four or five implementations total 
that have to interoperate, vs. (potentially) one for each website. 
Updates to browsers can be deployed, at scale, to hundreds of millions 
of users in the span of a few weeks (at least with Firefox and Chrome, 
Safari and IE also have well-established short-term update mechanisms, 
though they're usually for security issues rather than new features), 
vs. trying to get each and every website to update their JS library. An 
individual website may be able to deploy updates more quickly than the 
browser vendors, but interoperability isn't about the individual.

And now there are the security concerns with sending datagrams after 
trying to short-cut the ICE process. I don't know if mandating STUN 
requests before sending data to a remote peer is sufficient to address 
these, but clearly some others see a potential problem. Personally, I 
think having p2p datagram support is a much more important feature to 
end users than being able to change the connection handshake protocol in JS.

Everything above is an argument I've heard someone else raise at some 
point. I haven't heard a lot of good responses to these arguments.

---

From: Dzonatas Sol <[email-masked]>
Date: Tue, 28 Jun 2011 14:09:38 -0700

On 06/28/2011 10:06 AM, Timothy B. Terriberry wrote:
> trying to short-cut the ICE process.
>

What happens is that the application (of ICE systems) creates the 
delusion the previous path is no longer of need. The ICE system itself 
doesn't do that, as newer adapters are unfamiliar with the previous 
path. The security concern is in the question to end the previous path. 
Some defaulted the previous path "off" after application, which made 
related evolution harder... proven human error when that kind of 
security level (prevent evolution?) is not needed. It works best to 
distinguish versions and with things meant-for standardization (towards 
hardware, or towards plasma-stasis in quantum physics).

-- 
--- http://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering
Ag-Biotech, Virtual Reality, Consultant