Re: [MMUSIC] [rtcweb] Tunnelling DTLS in SDP

Hi,

All I'll say at this point is that you cannot assume that forking entities will remove the attribute. You either need to have a fallback procedure in case of forking, or say that the mechanism MUST NOT be used in environments where forking can occur (which makes the mechanism more or less useless in virtually all SIP environments).

Regards,

Christer

Sent from my Windows Phone
________________________________
From: T H Panton<mailto:tim@phonefromhere.com>
Sent: ‎11/‎07/‎2016 19:33
To: Roman Shpount<mailto:roman@telurix.com>
Cc: Cullen Jennings<mailto:fluffy@cisco.com>; RTCWeb IETF<mailto:rtcweb@ietf.org>; mmusic WG<mailto:mmusic@ietf.org>
Subject: Re: [MMUSIC] [rtcweb]   Tunnelling DTLS in SDP

On 11 Jul 2016, at 17:19, Roman Shpount <roman@telurix.com<mailto:roman@telurix.com>> wrote:

I would definitely like to proceed with this. There are certain issues related to forking and new associations being setup by the answering party, but I think they are resolvable. On the other hand, the benefits of reduced call setup up time definitely make this worthwhile.

As I said (remotely) at the last meeting,
I am distinctly _unkeen_ on the aesthetics of this - it ties us to ever uglier and larger SDP, it breaks software layer separation in the stacks,
it will no doubt presume a single DTLS implementation, it will be _fun_ to test, and I anticipate it will open some ugly attack vectors
to the javascript kiddies.

Last I heard EKR was going to experiment with it and come back with a view on how (in)accurate my doom-saying was.
I haven't heard the reply...

- If folks want a corridor conversation about this next week in Berlin, I'll be there.

T.

_____________
Roman Shpount

On Mon, Jul 11, 2016 at 8:22 AM, Cullen Jennings <fluffy@cisco.com<mailto:fluffy@cisco.com>> wrote:

Quick questions for folks …  is an idea that we should explore a bit deeper before making decisions about it? or should we not proceed? or should we proceed? Just looking for feedback on where this should go next

Thanks, Cullen

On Apr 18, 2016, at 7:59 AM, Roman Shpount <roman@telurix.com<mailto:roman@telurix.com>> wrote:

On Mon, Apr 4, 2016 at 9:10 AM, Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>> wrote:
I wanted to call your attention to a draft I just published with a possibly stupid
idea.

https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00

A nontrivial fraction of call setup time in WebRTC is the DTLS handshake.
This document describes how to piggyback the first few handshake messages
in the SDP offer/answer exchange, thus reducing latency.

Comments welcome.

One other issue I thought off was that with DTLS SDP either offerer or answerer can start a new DTLS association. When answerer starts a new session it will have exactly the same problems as forking, since this will create multiple DTLS sessions with the same client random. This can be solved with some sort of fallback mechanism to either regular DTLS setup or to sending a ClientHello in the answer.

Regards,
_____________
Roman Shpount

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

_______________________________________________
mmusic mailing list
mmusic@ietf.org<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic

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