Re: Presentation for a call if DTLS Association be started if not requested in the offer - ehterpad

On Thu, Sep 28, 2017 at 12:53 PM, Eric Rescorla <[email protected]> wrote:

> Summarizing my proposal on today's call:
>
> As an offerer:
> If the answerer changes either {fingerprint, tls-id} then {
>   if (!doing ICE restart) {
>     error
>   } else {
>     do a new DTLS negotiation
>   }
> }
>

Agreed

There is a race condition on the offerer if you are in ICE lite or
> something where you might receive DTLS packets before the Answer. The
> DTLS-SDP spec requires an ICE restart under these conditions, so you will
> not be receiving anything from the old connection on the new 5-tuples.
> Thus, you only need to disambiguate between: {RTP or SCTP on the current
> DTLS association} and {ClientHello from the new association}. This can be
> dealt with by (a) latching on the first thing that looks like it matches
> one or the other pattern, i.e., it's either a ClientHello or it decrypts
> successfully or (b) discarding everything until you get the answer, which
> is something that happens automatically in most ICE scenarios.
>

This all looks good, except for potential fragmented ClientHello message
with fragments received out of order. Another potential failure scenario is
SRTP from the old dead call being sent over the new 5-tuple. My proposal
was not to latch on things that cannot be decoded as current DTLS
association or SRTP.


> As an answerer, JSEP implementations MUST NOT change the TLS-ID or the
> Fingerprint unless the offerer sent a new TLS-ID
>

Agreed
_____________
Roman Shpount

_______________________________________________
mmusic mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic