Re: Issue 168: Potential interop issue: Constructing a DtlsTransport from an existing IceTransport

Related:

My $0.02 - if .start() is called on a new DTLS transport where there was a previous DTLS transport associated to the same underlying ICE transport, if .stop() was not called on the previous DTLS transport an implicit .stop() should be called rather than throwing an error. There's no way to demux two DTLS transports so let's not pester with needless errors where there's no recovery and we can understand what is the intention anyway…

-Robin


On January 12, 2015 at 8:26:43 PM, Bernard Aboba (bernard.aboba@microsoft.com) wrote:

[BA] We can indicate that only one DtlsTransport can run over an IceTransport. So DtlsTransport.stop() MUST be called prior to calling DtlsTransport.start() on an DtlsTransport constructed from the same iceTransport. We can also indicate that an onerror event is fired in the case where two DTLS connections are attempting to be multiplexed over a single ICE connection.  

However, this does not cover all corner cases.  

Justin said: "Also, if DTLSTransport A is talking to DTLSTransport B, and then A goes away, this should tear down the DTLS association"  

[BA] If A calls DtlsTransport.stop(), then the DTLS association will be torn down on both A and B. However, if there is a connectivity failure, there may be a period before B tears down the association. Although there has been previous discussion of DTLS Heartbeat [RFC6520] (see http://www.ietf.org/mail-archive/web/rtcweb/current/msg10224.html), this document is not referenced in any RTCWEB drafts, including draft-ietf-rtcweb-security, draft-ietf-rtcweb-security-arch, data channel drafts, etc. So if there is no data channel in use, B may not detect that DtlsTransport A has "gone away" until STUN consent freshness fails.  

At that point, doesn't B need to construct a new ICE transport, rather than just calling iceTransport.start() with a newly constructed iceGatherer?  

=================  
>From Roman Shpount (see http://lists.w3.org/Archives/Public/public-ortc/2014Dec/0028.html):  

All the tools needed to shoot oneself in the foot with the current WebRTC implementation are ready and provided to the ORTI API user.  

A developer could construct a new RTCDtlsTransport based on an existing RTCIceTransport and then call RTCDtlsTransport.start(). This would cause a new DTLS negotiation to occur and the DTLS role, fingerprints, etc. could change with a new DTLS/SRTP key being derived.  

Existing implementations will only expect a new DTLS session negotiation if transport parameters have changed. They will not handle a new DTLS session over the existing ICE transport connection and they have no way to demultiplex two DTLS sessions over the same ICE connection.  

I do not think this needs to be specifically disabled since there are valid use cases when such functionality is needed to interwork with valid DTLS and DTLS-SRTP implementations.