Re: [rtcweb] PeerConnection Data Channel

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.

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.

>
> > >> - For encryption, it simply uses the underlying encryption of the
> > >> 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?
>

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.

>
> > > Absolutely correct. Possibly needs masking for the "none" case
> > > however... need to discuss.
>
> [BA] Right.  That's why it's there, not to provide a generic security
> framework.
>

See above.

>
> >
> > 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.
>
> [BA] Right.  That's what trying to force RTP security on non-media data
> isn't appropriate.
>

See above.

>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>