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

Also related:

New DTLS transport can be receiving packets associated with the previous
DTLS transport (due to packet re-order, not having old DTLS properly
shutdown on the remote side, or other network artifacts). Once again, there
is no easy way to demux the packets that belong to the old DTLS session
from the packets that belong to the new DTLS session. How is this suppose
to work?

More importantly, what is the use case when new DTLS session is started on
the same underlying transport? Why would you ever want to create a new DTLS
session without setting up a new underlying transport connection? This is
something definitely not supported by any of the existing browsers or major
DTLS implementations.

The only related use case that I know of is the re-key, but this is a
renegotiation on the existing DTLS session, not the new DTLS session.

_____________
Roman Shpount

On Tue, Jan 13, 2015 at 12:13 PM, Robin Raymond <robin@hookflash.com> wrote:

>
> 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.
>
>
>