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

From: Christer Holmberg <[email-masked]>
Date: Fri, 27 Feb 2015 13:27:58 +0000

Hi,

Based on the discussions, I suggest the following modification to the SCTP-SDP draft:

OLD:

9.3.3.  TLS Role Determination

   If the m- line proto value is 'SCTP/DTLS', 'UDP/DTLS/SCTP' or
   'TCP/DTLS/SCTP', the 'active/passive' status is used to determine the
   (D)TLS roles of the endpoints.  Following the procedures in
   [RFC4572], the 'active' endpoint will take the (D)TLS client role.

   Once a DTLS connection has been established, if the 'active/passive'
   status of the endpoints change (as result of an offer/answer
   exchange) during a session, a new DTLS connection MUST be
   established.  Therefore, endpoints SHOULD NOT change the 'active/
   passive' status during a session, unless they want to establish a new
   DTLS connection.

   If the transport parameters of the underlying transport protocol, or
   the key fingerprints, change the endpoints MUST establish a new DTLS
   connection.  In such case the 'active/passive' status of the
   endpoints will again be determined following the procedures in
   [RFC4145], and the new status will be used to determine the (D)TLS
   roles of the endpoints associated with the new DTLS connection.

   NOTE: The procedure above is identical to the one defined for SRTP-
   DTLS in [RFC5763].

   NOTE: The re-establishment of a DTLS connection as such does not
   affect the underlying transport protocol connection.  However, as
   described above, the reason a new DTLS connection is established
   might be because some transport protocol parameters have changed.

NEW:

9.3.3.  TLS Role Determination

   If the m- line proto value is 'SCTP/DTLS', 'UDP/DTLS/SCTP' or
   'TCP/DTLS/SCTP', the 'active/passive' status is used to determine the
   (D)TLS roles of the endpoints.  Following the procedures in
   [RFC4572], the 'active' endpoint will take the (D)TLS client role.

   Once the DTLS connection has been established, the endpoints MUST NOT
   modify (as result of an offer/answer exchange) the TLS roles, or the
   'active/passive' status, of the endpoints, unless some the
   underlying transport protocol is also modified (e.g. if an IP address- or port
   value associated with the transport protocol is modified).

   If the underlying transport protocol is modified, the endpoints MUST
   establish a new DTLS connection.  In such case the 'active/passive' status
   of the endpoints will again be determined following the procedures in
   [RFC4145], and the new status will be used to determine the (D)TLS
   roles of the endpoints associated with the new DTLS connection.

   NOTE: The procedure above is identical to the one defined for SRTP-
   DTLS in [RFC5763].

Regards,

Christer

From: Makaraju, Maridi Raju (Raju) [mailto:[email-masked]]
Sent: 26. helmikuuta 2015 18:04
To: Roman Shpount
Cc: [email-masked]; Christer Holmberg; Simon Perreault
Subject: RE: DTLS-O/A: DTLS fingerprint and setup role MUST NOT change unless underlying transport also changes

I agree to the point that both endpoints have to be in the same state. IMO, allowing a new SDP O/A in this case with same fingerprint and transport 5-tuple may serve this purpose in addition to re-establishing a failed DTLS association. I am ok if this is added as separate text and also making it optional to send new SDP O/A.

I am thinking that session resumption by the active end point is virtually identical to re-key (please correct me that I am wrong). Because of this, it can be used both to recover the session or to re-key the DTLS connection without any interaction with offer/answer. I do not want to see the need for the optional SDP O/A here since normally SDP O/A with the same transport parameters does not mean DTLS re-negotiation. Unless we add something special in the O/A, it will not help in synchronizing the end point state.
<Raju>
I am not sure what you meant by session resumption as it is ambiguous?! Is it the one specified in https://tools.ietf.org/html/rfc5764#appendix-B using “master context”? or https://tools.ietf.org/html/rfc4507 using SessionTicket? But neither seems to address the issue of reopening a closed DTLS association. Per my understanding, rekey of DTLS session happens within the context of an existing association (yes, with no new SDP O/A).

I understand that desire is to re-establish a failed DTLS without new SDP O/A. But I could not find any reference text which indicates a client should automatically attempt re-establish such a failed association (which may then use SessionTicket for resumption).
Either we need to add such text or allow a new optional SDP O/A. I also prefer the former approach.
</Raju>

---

From: Roman Shpount <[email-masked]>
Date: Fri, 27 Feb 2015 08:31:03 -0500

This looks good to me.

_____________
Roman Shpount