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

From: Christer Holmberg <[email-masked]>
Date: Thu, 28 Sep 2017 15:00:50 +0000

Etherpad for the meeting:

https://etherpad.tools.ietf.org/p/dtls-sdp

Everyone just volunteered to take notes :)

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 28 Sep 2017 18:53:47 +0200

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

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.

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

-Ekr

---

From: Roman Shpount <[email-masked]>
Date: Thu, 28 Sep 2017 13:27:04 -0400

>     do a new DTLS negotiation

Agreed

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

> Fingerprint unless the offerer sent a new TLS-ID

Agreed
_____________
Roman Shpount