Subject: [MMUSIC] DTLS-O/A: DTLS fingerprint and setup role MUST NOT change unless underlying transport also changes

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 Feb 2015 11:37:36 +0000

Hi,

We've had a discussion in RTCWEB, regarding DTLS and Offer/Answer.

Currently, if the setup role (active/passive) or fingerprint is changed, a new DTLS connection must be re-established. But, if the underlying transport doesn't change, there is a risk of receiving packets associated both with the new and old DTLS connection, and there is no procedures on how to handle that (or how to have two simultaneous DTLS connections).

The suggestion would be to define the following restriction when negotiation DTLS using SDP Offer/Answer:

"DTLS fingerprint and setup role MUST NOT change unless underlying transport did not change as well."

This means that we would not, as part of a mid-session O/A exchange, allow to change the DTLS fingerprint, or the setup role (active/passive), unless the underlying transport also changes. I guess it also means that, in a mid-session O/A exchange, and endpoint would not offer "actpass", but rather whatever role was assigned previously.

Note that the suggestion does not impact DTLS re-keying. Re-keying (which doesn't require an O/A exchange) is still allowed, even if the transport doesn't change.

Does anyone have a problem with this suggested restriction?

Then, as far as documenting this is concerned, the first step would be to document it for SCTP in the SCTP-SDP draft.

But, long-term, it would probably be good to have a generic DTLS-O/A spec, which other specs (DTLS-SRTP, BFCP, etc) could reference.

Regards,

Christer

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Wed, 25 Feb 2015 13:00:39 +0000

Hi,

<Raju>
Transport parameters could change in SDP answer (e.g. connecting to a conference bridge). To allow this any new offer should always send "actpass". The answerer should return the previously negotiated role.

I have no objections for such a text in general. But I think we need to consider the following scenarios and add clarifications as needed.

Scenario1: If a DTLS association is aborted due to an error, is a new SDP offer/answer required to restart the association? I guess not. But I do not find any clarification on this, so implementations may depend on new SDP O/A. If a new SDP offer/answer is sent then it may negotiate the same fingerprint and transport params but in this case a new association must be established (even probably without role changes).

To allow this change the text need to include allowing of re-establishment of a closed DTLS association (new text is marked between '**'):

"DTLS fingerprint and setup role MUST NOT change unless underlying transport did change as well **or a new DTLS association needs to be established after losing previous one**."

The main issue is with multiple DTLS associations, so IMO adding the above extra clause is ok in general.

Or we need to add text to indicate DTLS associations should be re-established automatically after a failure.

Scenario2: The following scenario which may be reestablishing a new DTLS association currently, but works, becomes an invalid SDP O/A and need to change its behavior:

1.       A (passive) to B (active) are in an active DTLS session directly.

2.       B has to send a new offer now for some service. B has to send 'actpass' as SDP answer may result in A talking to other than B (like a conf resource).

3.       If it turns out A gets the SDP offer and in SDP answer it may include 'active' (due to, for example being the answerer now), which now reverses the roles.

So, after the above change, the expectation here is for A to return previously negotiated 'passive' role to avoid SDP O/A violation.

Any clarification text needed for this scenario? I know this could simply be attributed to a buggy implementation, but adding a note may help avoid such common mistake.

</Raju>

BR
Raju

Regards,

Christer