Subject: Re: [rtcweb] PeerConnection Data Channel

From: Randell Jesup <[email-masked]>
Date: Fri, 02 Sep 2011 18:13:25 -0400

CC-ing IETF rtcweb to cover the encryption/SDP/negotiation aspects of 
this proposal.

On 9/2/2011 12:59 PM, Matthew Kaufman wrote:
> On 9/2/11 5:52 PM, Justin Uberti wrote:
>> Section 5 in the WEBRTC spec 
>> (http://dev.w3.org/2011/webrtc/editor/webrtc.html) discusses at 
>> length a mechanism for transmitting and securing datagrams over the 
>> PeerConnection transport. At both an API and a wire level, this 
>> mechanism is quite different from the existing mechanisms that are 
>> used for transmission of audio and video data:
>> - The availability of the data stream is not easily known, whereas 
>> audio/video can be negotiated and stream existence learned from the 
>> *Stream methods/callbacks.
>
> Agree.

True

>> - It defines its own encryption mechanism, whereas audio/video will 
>> use SDES-SRTP, or DTLS-SRTP
>
> Agree.

True, kinda, but that's not a value judgement, just an observation.

>
>> - Only one data stream exists, whereas audio/video can have many streams
>
> Agree.

True

>
>>
>> I would like to propose an approach where we remove the send() 
>> method, and add a createDataStream() method to PeerConnection. This 
>> method creates a DataStream object, a descendant of MediaStream. This 
>> object can then be added/removed from PeerConnection via the existing 
>> add/removeStream APIs, and it will show up in 
>> localStreams/remoteStreams like any other MediaStream. It will also 
>> fire events indicating the stream status.
>
> Great idea.

I agree ways to create and add datastreams are important, as is the 
ability to have multiple ones.  Otherwise people will just 
roll-their-own multistream muxes.  If there can be only one stream, it 
would almost have to be an unreliable-datagram service, so you could 
build more complex stuff on top of it.

>
>>
>> Some specifics:
>> - This stream will show up in SDP
>
> I don't like SDP, but if we do SDP, that's where it'd need to be.
>
>> , and it can be its own RTP session,
>
> Disagree. RTP semantics are inappropriate for sending data. The data 
> should be sent using one of the two methods for muxing data that were 
> proposed (one by me, one by cbran).
>
> There should be a way to demux multiple streams of data using an 
> additional sub-header.

Agreed.  RTP for non media-stream data is not a good choice.

>> or muxed with other RTP sessions, just like any other audio/video 
>> stream. If the remote side doesn't support/want the data stream, it 
>> can signal this via its answer SDP.
>
> Agree.

Agree

>
>> - For encryption, it simply uses the underlying encryption of the 
>> session, i.e. none, SDES-SRTP, or DTLS-SRTP, as appropriate.
>
> Absolutely correct. Possibly needs masking for the "none" case 
> however... need to discuss.

Hmmm....  This (blah-SRTP for encrypting the data streams means full 
un-encrypted RTP headers at a minimum, plus a bunch of those "RTP 
semantics" you disagreed with above.  Unless I mis-understand how this 
would work.

This (RTP encapsulation of the data) is my biggest heartburn with this 
proposal.  I thought that idea had died at the mic, but apparently not.

The strongest arguments in favor of RTP are: simplify code (everything 
ends up RTP), and RTP provides implicit information about loss and 
timing information that can be of use to congestion-control algorithms.  
For example, if both audio and video are currently inactive/muted, you 
still want the congestion control/bandwidth estimation code to continue 
to work for data channels.  That in fact might be the strongest argument 
in favor, though there are other ways to provide that information.

So we should detail out the ramifications of this (and think carefully 
about any security implications to SRTP use here, though it's probably 
ok from a security standpoint).

>
>> - Multiple DataStreams can be created, just like MediaStreams. This 
>> may be of value to certain applications, who want to have multiple 
>> flows, perhaps with their own QoS.
>
> Agree. Prioritization makes sense here, especially if/when we get 
> congestion control.

Agree.  I'll use the ancient example of netrek - it wanted and needed 
both a reliable and unreliable channel.  The QOS characteristics of the 
two would have been different as well (if they'd been settable).  
Prioritization should not just be within data streams, but also it 
should prioritize individual data streams versus media streams.

>> - We can (perhaps later) add different kinds of DataStreams, i.e. 
>> datagram and reliable. When creating a DataStream, you can specify 
>> what kind of stream you want.
>
> Also a good idea.

Agreed.

-- 
Randell Jesup
[email-masked]

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 2 Sep 2011 17:13:08 -0700

> >> PeerConnection transport. 
[BA] The objective here appears to be "masking" (e.g. to prevent sending of arbitrary datagrams) rather than providing a full set of security services. 
> > > At both an API and a wire level, this 
> >> used for transmission of audio and video data:> >> - The availability of the data stream is not easily known, whereas 
[BA] It looked to me that the data channel was negotiated in SDP, no?
> >> use SDES-SRTP, or DTLS-SRTP

[BA] I don't believe that the objective here is to duplicate the security services in SRTP, DTLS, TLS, IPsec or any other comprehensive security framework. It's closer to the "masking" supported by WebSockets.  

> >> - This stream will show up in SDP

[BA] I believe that's what the current spec already says. 
> > proposed (one by me, one by cbran).

[BA] Agree that RTP semantics aren't necessarily appropriate for non media-stream data. 
> >> session, i.e. none, SDES-SRTP, or DTLS-SRTP, as appropriate.

[BA] If the underlying semantics of RTP aren't a good fit, why would that make sense?
> > however... need to discuss.

[BA] Right.  That's why it's there, not to provide a generic security framework. 
> semantics" you disagreed with above.  Unless I mis-understand how this 
[BA] Right.  That's what trying to force RTP security on non-media data isn't appropriate.

---

From: Justin Uberti <[email-masked]>
Date: Fri, 2 Sep 2011 23:46:40 -0400

On Fri, Sep 2, 2011 at 8:13 PM, Bernard Aboba <[email-masked]>wrote:

> [BA] The objective here appears to be "masking" (e.g. to prevent sending of
> arbitrary datagrams) rather than providing a full set of security services.
>

The current spec provides an encryption and authentication mechanism, in
addition to the masking. From the spec: "The data is made to appear
pseudo-random, so that it cannot be used in a cross-protocol attack, even if
somehow the stream were to be directed at an unsuspecting remote host. The
data is hashed in such a way that it cannot be modified in transit. That
data is encrypted so that it cannot be read in transit."

> [BA] It looked to me that the data channel was negotiated in SDP, no?

Yes. But the API doesn't expose whether the data channel was successfully
negotiated.

> [BA] I don't believe that the objective here is to duplicate the security
> services in SRTP, DTLS, TLS, IPsec or any other comprehensive security
> framework.
> It's closer to the "masking" supported by WebSockets.
>

That's not my understanding of the spec, as evidenced above.

> [BA] Agree that RTP semantics aren't necessarily appropriate for non

Yeah, I admit my original opinion on this was that RTP was crazy. But
looking at it more, we're going to end up duplicating much of what RTP
provides - Matthew's proposal adds a 4 byte header to distinguish it from
STUN, and we probably also need a stream id and a sequence number (for
TFRC). At that point we're only a timestamp away from a full RTP header.

I think this is an interesting discussion, so I'll send a new email to the
list to discuss the wire format of this protocol, which I think can be
considered separately from the DataStream proposal I'm putting forth here.

> [BA] If the underlying semantics of RTP aren't a good fit, why would that

True. However, if we use DTLS, we can apply DTLS without the need for RTP
semantics. Or as Matthew says, we could also make SRTP-style encryption work
with whatever datagram protocol we come up with.

> [BA] Right.  That's why it's there, not to provide a generic security

See above.

> [BA] Right.  That's what trying to force RTP security on non-media data

See above.

>
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Justin Uberti <[email-masked]>
Date: Fri, 2 Sep 2011 23:50:49 -0400

On Fri, Sep 2, 2011 at 6:13 PM, Randell Jesup <[email-masked]>wrote:

> CC-ing IETF rtcweb to cover the encryption/SDP/negotiation aspects of this
> proposal.
>
>
>>> Section 5 in the WEBRTC spec (http://dev.w3.org/2011/**
>>> webrtc/editor/webrtc.html<http://dev.w3.org/2011/webrtc/editor/webrtc.html>)
>>> discusses at length a mechanism for transmitting and securing datagrams over
>>> the PeerConnection transport. At both an API and a wire level, this
>>> mechanism is quite different from the existing mechanisms that are used for
>>> transmission of audio and video data:
>>> audio/video can be negotiated and stream existence learned from the *Stream
>>> methods/callbacks.
>>>
>>
>> Agree.
>>
>
> True
>
>
>  - It defines its own encryption mechanism, whereas audio/video will use
>>> SDES-SRTP, or DTLS-SRTP
>>>
>>
>> Agree.
>>
>
>>> I would like to propose an approach where we remove the send() method,
>>> and add a createDataStream() method to PeerConnection. This method creates a
>>> DataStream object, a descendant of MediaStream. This object can then be
>>> added/removed from PeerConnection via the existing add/removeStream APIs,
>>> and it will show up in localStreams/remoteStreams like any other
>>> MediaStream. It will also fire events indicating the stream status.
>>>
>>
>> Great idea.
>>
>
> I agree ways to create and add datastreams are important, as is the ability
> to have multiple ones.  Otherwise people will just roll-their-own
> multistream muxes.  If there can be only one stream, it would almost have to
> be an unreliable-datagram service, so you could build more complex stuff on
> top of it.
>
>
>
>>
>>> Some specifics:
>  or muxed with other RTP sessions, just like any other audio/video stream.
>>> If the remote side doesn't support/want the data stream, it can signal this
>>> via its answer SDP.
>>>
>>
>> Agree.
>>
>
> Agree
>
>
>> Absolutely correct. Possibly needs masking for the "none" case however...
>> need to discuss.
>>
>
> un-encrypted RTP headers at a minimum, plus a bunch of those "RTP semantics"
> you disagreed with above.  Unless I mis-understand how this would work.
>
> The strongest arguments in favor of RTP are: simplify code (everything ends
> up RTP), and RTP provides implicit information about loss and timing
> information that can be of use to congestion-control algorithms.  For
> example, if both audio and video are currently inactive/muted, you still
> want the congestion control/bandwidth estimation code to continue to work
> for data channels.  That in fact might be the strongest argument in favor,
> though there are other ways to provide that information.
>
> about any security implications to SRTP use here, though it's probably ok
> from a security standpoint).

I do think we want common congestion control for audio/video/data. I don't
think this necessarily implies RTP, although it does imply something
RTP-like, so it may just be simplest to go with RTP. As mentioned in my
reply to Bernard, I think this topic merits its own thread.

>
>
>
>>  - Multiple DataStreams can be created, just like MediaStreams. This may
>>> be of value to certain applications, who want to have multiple flows,
>>> perhaps with their own QoS.
>>>
>>
> Agree.  I'll use the ancient example of netrek - it wanted and needed both
> a reliable and unreliable channel.  The QOS characteristics of the two would
> have been different as well (if they'd been settable).  Prioritization
> should not just be within data streams, but also it should prioritize
> individual data streams versus media streams.
>
>
>  - We can (perhaps later) add different kinds of DataStreams, i.e. datagram
>>> and reliable. When creating a DataStream, you can specify what kind of
>>> stream you want.
>>>
>>
>> Also a good idea.
>>
>
> Agreed.
>
> --
> Randell Jesup
> [email-masked]
>
> ______________________________**_________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 3 Sep 2011 08:14:13 -0700

On Fri, Sep 2, 2011 at 8:46 PM, Justin Uberti <[email-masked]> wrote:
>> [BA] The objective here appears to be "masking" (e.g. to prevent sending
>> of arbitrary datagrams) rather than providing a full set of security
>> services.
>

I believe Justin is correct here: the protocol appears to be designed
to provide rather
more than masking.

With that said, in my opinion it is likely not necessary to mask UDP
data. Masking is
designed to prevent cross-protocol attacks on intermediaries, which
are not really
a common feature of UDP data transmission (as opposed to HTTP intercepting
proxies, which are quite common and for which masking was originally designed.

-Ekr

---

From: Colin Perkins <[email-masked]>
Date: Tue, 6 Sep 2011 11:41:10 +0100

On 3 Sep 2011, at 04:46, Justin Uberti wrote:
> On Fri, Sep 2, 2011 at 8:13 PM, Bernard Aboba <[email-masked]> wrote:
> The current spec provides an encryption and authentication mechanism, in addition to the masking. From the spec: "The data is made to appear pseudo-random, so that it cannot be used in a cross-protocol attack, even if somehow the stream were to be directed at an unsuspecting remote host. The data is hashed in such a way that it cannot be modified in transit. That data is encrypted so that it cannot be read in transit."
> 
> Yes. But the API doesn't expose whether the data channel was successfully negotiated. 
> 
> [BA] I don't believe that the objective here is to duplicate the security services in SRTP, DTLS, TLS, IPsec or any other comprehensive security framework. 
> Yeah, I admit my original opinion on this was that RTP was crazy. But looking at it more, we're going to end up duplicating much of what RTP provides - Matthew's proposal adds a 4 byte header to distinguish it from STUN, and we probably also need a stream id and a sequence number (for TFRC). At that point we're only a timestamp away from a full RTP header.

...and a payload type, contributing source list, header extensions, a bunch of semantics relating to timing and media playout, and the whole of RTCP. RTP is not just a data header format.

-- 
Colin Perkins
http://csperkins.org/