Subject: [rtcweb] RFC 5763 Section 6.7.1 (was DTLS, DTLS-SRTP, and 5-tuples)

From: Bernard Aboba <[email-masked]>
Date: Thu, 26 Mar 2015 18:41:37 -0500

RFC 5763 Section 6.7.1 explains much of what we've been talking about on
this thread.
6.7.1 <http://tools.ietf.org/html/rfc5763#section-6.7.1>. ICE Interaction
   Interactive Connectivity Establishment (ICE), as specified in
   [RFC5245 <http://tools.ietf.org/html/rfc5245>], provides a methodology
of allowing participants in
   multimedia sessions to verify mutual connectivity.  When ICE is being
   used, the ICE connectivity checks are performed before the DTLS
   handshake begins.  Note that if aggressive nomination mode is used,
   multiple candidate pairs may be marked valid before ICE finally
   converges on a single candidate pair.  Implementations MUST treat all
   ICE candidate pairs associated with a single component as part of the
   same DTLS association.  Thus, there will be only one DTLS handshake
   even if there are multiple valid candidate pairs.  Note that this may
   mean adjusting the endpoint IP addresses if the selected candidate
   pair shifts, just as if the DTLS packets were an ordinary media
   stream.

---

From: Roman Shpount <[email-masked]>
Date: Thu, 26 Mar 2015 20:01:13 -0400

>    pair shifts, just as if the DTLS packets were an ordinary media
There is still a questions that needs to be resolved in relation to this:

What is the transport parameter change that requires a new DTLS handshake?
In particular, would ICE restart require a new DTLS handshake?

One option is that DTLS handshake is triggered by any ufrag changes,
including ICE restart. The problem with this option is that if some ICE
candidates are reused, the same candidate pair can end up into two
different associations at the same time.

Another option is that DTLS handshake is only triggered if fingerprint pair
changes. There is a problem with this, since DTLS Client hello can be
received before the answer with the new fingerprint.
_____________
Roman Shpount

---

From: Simon Perreault <[email-masked]>
Date: Fri, 27 Mar 2015 06:57:52 -0500

Wow. So many emails wasted. Thanks a lot!

</thread>

Simon
Le 2015-03-26 18:42, "Bernard Aboba" <[email-masked]> a écrit :

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 27 Mar 2015 16:39:54 +0000

On Mar 26, 2015, at 6:41 PM, Bernard Aboba <[email-masked]<mailto:[email-masked]>> wrote:

RFC 5763 Section 6.7.1 explains much of what we've been talking about on this thread.
6.7.1<http://tools.ietf.org/html/rfc5763#section-6.7.1>. ICE Interaction

   [RFC5245<http://tools.ietf.org/html/rfc5245>], provides a methodology of allowing participants in
   stream
(Adding MMUSIC.)

The one recommendation I’d make for this problem is that one of the DTLS-SCTP drafts (probably ietf-mmusic-sctp-sdp, I guess?) should repeat this text from 5763.