On 3 Sep 2011, at 04:46, Justin Uberti wrote: > On Fri, Sep 2, 2011 at 8:13 PM, Bernard Aboba <bernard_aboba@hotmail.com> 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/Received on Tuesday, 6 September 2011 16:13:48 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:21 UTC