Doodle poll: Call to discuss DTLS-SDP issue on whether an SDP answerer can trigger a new DTLS association

Hi,

I am planning to set up a call to discuss the issue with draft-dtls-sdp on whether an SDP answerer is allowed to trigger a new DTLS association.

In case you are not familiar with the issue, below is a description (provided by Roman) in a nutshell, followed by a doodle poll for a phone call to discuss the issue.

What do we want to discuss?

If an SDP answerer can request a new DTLS association if the SDP offerer end point did not request it.

When and why can this happen?

This happens during third party call control (3PCC). Imagine a call being setup between end points A and B through the third party call control agent 3PCC. 3PCC requests end point A for a new offer. This offer will always initiate ICE restart (https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-13#section-8.5) and it currently is not required to have a new tls-id. If offer from end point A is generated with the current tls-id and sent by 3PCC as a new offer to an end point C, a new DTLS association must be established between A and C. This will be detected by end point A, when it gets the answer from end point C which will contain a new tls-id, or, in legacy RFC 5763 case, new fingerprints.

How can this be implemented?

Current draft allows an answerer to establish a new DTLS association in the answer to any offer without ICE or any offer with ICE restart. The only way I have managed to get the current specification to work is by monitoring packets which are received over new ICE candidate pairs discovered after ICE restart. If DTLS ClientHello packet is received, it is assumed that remote end point initiated a new DTLS association and received packets are queued until answer is received. If other DTLS packets or non-DTLS (SRTP) packets are received, they are processed as if they were part of the previous DTLS association or SRTP flow established using a previous DTLS association.

What are the arguments for allowing answering end point to establish new DTLS associations?

1. This allows support for common 3PCC and B2BUA scenarios. Without 3PCC call scenario support, SIP end points could not be DTLS enabled

2. This is already allowed by RFC 5763 and is required for legacy interop

3. If DTLS extension is ever developed that allows de-mux multiple DTLS associations over the same underlying transport, then new DTLS associations can be established and torn down independently of the underlying transport, so that it would be natural for either party to initiate it.

How this can cause problems?

1. Any packets received from the time the offier is sent until the answer is received over a new transport 5-tuple are ambiguous in the sense that they can belong to the existing DTLS association or the new DTLS association established by the answering end point. There is no way to resolve this without an "ugly" solution that mixes several different protocol levels (DTLS Client Hello detector). This also requires buffering that is not ideal.

2. It is unclear if new DTLS association and new data channels (which need to be re-established if DTLS association is re-established) would be created as a result of an offer/answer exchange when the offer is sent. This complicates API design

3. 3PCC is evil and confusing and should be avoided. There is no way to generate o= lines, allocate payloads, etc across multiple end points in a way that is consistent and compliant with JSEP. Because of this 3PCC agent can never be a JSEP compliant end point. Implementations will be a lot simpler if 3PCC scenarios were not supported and communications were always between two fixed end points.

P.S. What do we agree upon and not discussing?

ICE restart does not establish a new DTLS association on its own. ICE restart is required when new DTLS association is established, but new DTLS association MUST be explicitly requested by one of the parties.

Doodle poll: https://doodle.com/poll/y9szwrn57a5b4k7h

Regards,

Christer

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