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

There are several mechanisms to deal with multiple SRTP keys being used at
the same time. The most robust is simply use the old key, until the first
SRTP packet fails to verify, try to verify the SRTP packet using new key
and record sequence number for this SSRC as the first sequence for which
new key is used. For all subsequent packets use the new SRTP key. For all
previous -- repeat the above process. This should work in the absence of
MKI (which is not implemented or planned to be implemented anywhere).

The question that I had was about demux of DTLS data. I am not sure there
is a way to demux data packets from multiple DTLS sessions that reuse the
same transport. I am pretty certain nobody actually implements this, but I
might be missing something.

As far as new DtlsTransport is concerned, I understand that you need this
to change the certificate, but I am not sure why would you ever do this
without change of the underlying transport and what use case requires such
a feature.

I think there is value in ability to force DtlsTransport renegotiation
without changing any of its parameters. Restarting the transport after it
stalled would be one use case. Forcing the rekeying of the existing
connection can be another. I am pretty sure that renegotiation can be done
much more efficiently then new connection setup. This alone can warrant a
"restart" method on existing DtlsTransport instead of creating new
DtlsTransport from scratch.
_____________
Roman Shpount

On Tue, Jan 13, 2015 at 2:15 PM, Bernard Aboba <Bernard.Aboba@microsoft.com>
wrote:

>  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 <rshpount@turbobridge.com>
> Sent: ‎1/‎13/‎2015 9:27 AM
> To: Robin Raymond <robin@hookflash.com>
> Cc: public-ortc@w3.org; Bernard Aboba <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>
> 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.
>>
>>
>>
>