Re: [rtcweb] PeerConnection Data Channel

[Colin Perkins <[e-mail]>]

On 3 Sep 2011, at 04:46, Justin Uberti wrote:
> On Fri, Sep 2, 2011 at 8:13 PM, Bernard Aboba <[e-mail]> 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. 
> 
> [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."
> 
> > > > 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.
> 
> [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. 
> 
> > >> - It defines its own encryption mechanism, whereas audio/video will 
> > >> 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.  
> 
> That's not my understanding of the spec, as evidenced above.
>  
> 
> 
> > >> - This stream will show up in SDP
> 
> [BA] I believe that's what the current spec already says. 
> 
> > > 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).
> 
> [BA] Agree that RTP semantics aren't necessarily appropriate for non media-stream data. 
> 
> 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/