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

There are a few mechanisms that could be used to address temporary DtlsTransport overlap on the same IceTransport due to latency/reordering. RFC5763 optionally enables addition of the MKI field in SRTP to clarify which key is used. However the RTCWEB security and security-arch docs don't require this (is it implemented?). An alternative is to have an implicit .stop() once a new negotiation starts and when the new keys are derived for them to be installed and for packets failing validation to be discarded.

There appears to be situations where a stalled DtlsTransport can get going again after an ICE restart or an interface state change. No new negotiation, just restoration of connectivity.

Since calling DtlsTransport.start() again is illegal, a new DtlsTransport is needed to change parameters like the fingerprint. If DtlsTransport.stop() was called, it is possible to bring up a new DtlsTransport on the same IceTtansport. The potential scenario might be a desire to change the cert/fingerprint without a new IceTransport or ICE restart.
________________________________
From: Roman Shpount<mailto:rshpount@turbobridge.com>
Sent: ‎1/‎13/‎2015 9:27 AM
To: Robin Raymond<mailto:robin@hookflash.com>
Cc: public-ortc@w3.org<mailto:public-ortc@w3.org>; Bernard Aboba<mailto:Bernard.Aboba@microsoft.com>
Subject: 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<mailto: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<mailto: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.