a=setup value

[mparis]

Hello, there is an opened discussion in discuss-webrtc [1] in relation to which values should be used in "a=setup" attribute.

The main problem came from:

1. the text in RFC 5763 section-5 (Establishing a Secure Channel): The endpoint MUST use the setup attribute defined in [RFC4145]. The endpoint that is the offerer MUST use the setup attribute value of setup:actpass and be prepared to receive a client_hello before it receives the answer. The answerer MUST use either a setup attribute value of setup:active or setup:passive. Note that if the answerer uses setup:passive, then the DTLS handshake will not begin until the answerer is received, which adds additional latency. setup:active allows the answer and the DTLS handshake to occur in parallel. Thus, setup:active is RECOMMENDED. Whichever party is active MUST initiate a DTLS handshake by sending a ClientHello over each flow (host/port quartet).
2. and referred in JSEP: An "a=setup" line, as specified in [RFC4145], Section 4, and clarified for use in DTLS-SRTP scenarios in [RFC5763], Section 5. The role value in the offer MUST be "actpass".

(1) explains how to establish the channel, but what happen if the channel is already established (which is related to SDP renegotiations)? At this point and from my understanding, in relation to "a=setup" attr, and so to the DTLS-SRTP transport using ORTC notation [2], we should take into account the next points in subsequences of O/A negotiations (renegotiations):

• m-lines in Nth negotiation are related to the same m-lines in (N-1)th negotiation.
• New added m-lines belonging to the same BUNDLE group share the same transport.

In these cases, I wouldn't agree that the Nth offer MUST use setup:actpass, because this can cause a new DTLS handshake wasting resources,. Even more, some User Agents may not support it.

Moreover, I neither wouldn't agree that the first offer MUST use setup:actpass. In this way we are restricting the interoperability for limited User Agents that only support DTLS client role. Why they cannot announce setup:active from the beginning?

I might have missed some detail behind the decision made in RFC5763 section-5, but I think that these points are reasonable.

Refs [1] https://groups.google.com/forum/#!msg/discuss-webrtc/DfpIMwvUfeM/VgCtnJ0cEgAJ [2] http://publications.ortc.org/2016/20161202/#rtcdtlstransport*

[nils-ohlmeier]

I think regarding the setup attribute in renegotiations the reference is actually here https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-15#section-5.5 Which clearly specifies that you need to stay in the roles form the initial negotiation (except if both sides support 'dtls-id' and use that to negotiated new roles on purposes).

My interpretation of ietf-mmusic-dtls-sdp is that if a renegotiation adds another m-line it needs to start with setup:actpass on that new section. But that is not 100% clear to me.

I guess your reference to the ORTC spec clarifies my open concern whether I need to have setup attributes present in bundled m-lines. It makes sense to me that only the bundle master need to have these attributes. But I don't think that is clearly spelled out anywhere yet.

Opening the initial offer to setup:active or setup:passive is a bad idea, because that is only going to result in complete failure to establish the connection if the remote peer happens to have the same limitation as the offerer. So I think it makes sense to require from all JSEP implementations to be able to be in both roles and start flexible with setup:actpass.

[taylor-b]

I guess your reference to the ORTC spec clarifies my open concern whether I need to have setup attributes present in bundled m-lines. It makes sense to me that only the bundle master need to have these attributes. But I don't think that is clearly spelled out anywhere yet.

It's a "TRANSPORT" category attribute according to the current version of draft-ietf-mmusic-sdp-mux-attributes. Which means that only the value in the "bundle master" m= section is chosen. And in answers (or subsequent offers), "a=setup" should only go in the "bundle master" m= section (see section 8.1 of BUNDLE draft).

[juberti]

Recapping, I think that it's clear that 1) the first offer must use actpass, as stated in 5763 and 2) any bundled m= lines must use the same attribute, because of type "transport" 3) any new m= lines must also use actpass (per 5763).

However one could argue that subsequent offers for existing m= lines should use the existing type, rather than actpass. This has been mentioned before, but we haven't yet taken any action on this, since there hasn't been a clear rationale for doing so.

[ekr]

I agree with Juberti here. My sense is that at this point if you want to change this you should take it to the list.

[juberti]

@ekr: https://groups.google.com/forum/#!msg/discuss-webrtc/DfpIMwvUfeM/VgCtnJ0cEgAJ

[taylor-b]

However one could argue that subsequent offers for existing m= lines should use the existing type, rather than actpass.

Is this covered by DTLS SDP section 5.5?

When the offerer sends a subsequent offer, and the offerer does not want to establish a new DTLS association ... the offerer MUST insert an SDP 'setup' attribute with a value that does not change the previously negotiated DTLS roles

Or is that still too ambiguous? "does not change" could be interpreted as "actpass or the selected role".

[nils-ohlmeier]

Is this covered by DTLS SDP section 5.5?

I think so. That's why I mentioned that in my previous comment.

Or is that still too ambiguous? "does not change" could be interpreted as "actpass or the selected role".

My interpretation of this is that if the offerer would use 'actpass' again, the answerer could potentially answer with a different role. Therefore the actual role should be used in subsequent offer and not actpass (at least as long as we talk about existing m= lines).

[taylor-b]

Given that there are multiple reasonable interpretations, I think section 5.5 needs some clarification. See the above PR.

[juberti]

One issue here is that regardless of what we say here, all current implementations send (and possibly require) actpass. So actpass will need to be tolerated, at least for the no-dtls-id case, for some time.

[nils-ohlmeier]

My guess is that the majority of the confusion comes from the fact you need to look at least 5 specs (if I'm counting correct) to understand the full picture. The PR for draft-dtls-sdp helps to clarify that even further.

@juberti is right about having to accept actpass for some time. But I guess that is hopefully a temporary implementation interop issue and should not be written into the specs for future implementations to come.

[taylor-b]

It turns out that dtls-sdp actually is meant to allow either "actpass" OR the current negotiated role. See @rshpount's comment on https://github.com/cdh4u/draft-dtls-sdp/pull/21.

So, should JSEP require one or the other, or leave it implementation-dependent?

[ekr]

Currently JSEP requires actpass. My sense is: make sure that dtls-sdp is clear and leave JSEP alone

[nils-ohlmeier]

I still find this confusing. My understanding was that draft-dtls-sdp intention is to limit DTLS restarts to

• ICE restart
• Presenting a new dtls-id Because without new ICE candidates (and in absence of a another DTLS connection identifier like dtls-id) two DTLS connections over the same transport can not be demuxed.

The argument from the PR seems to be that 'actpass' needs to be used for subsequent offers, to allow the answerer to change roles from the previous roles (I assume here that a role change also results in establishing a DTLS connection). But that does not solve the ICE demuxing problem (the answerer could provide new ICE candidates, ufrag etc together with answer and the changed setup attribute, but that would be the equivalent of an ICE restart from the answerer side, which I think is not allowed). Further more I would assume that if the answerer side needs/wishes to establish a new DTLS connection it needs to start a renegotiation where it sends a new offfer with either new ufrag or new dtls-id in it (instead of waiting for an offer from the other side to try to sneak in its desire for a new DTLS connection).

The current JSEP draft states in section 5.3.1 initial Answer 'The role value MUST be consistent with the existing DTLS connection, if one exists and is being continued.' Which is confusing because why would there be an existing DTLS connection in case of the initial answer? (I'm guessing this sentence should be moved into 5.3.2.)

Therefore if draft-dtls-sdp can not clarify this I think JSEP should get a new bullet point in 5.3.2 Subsequent Answers which states that the answerer MUST NOT change the setup role. Still require 'actpass' for subsequent offers if fine by me if the purpose is not to violate draft-dtls-sdp. But since I think JSEP should over-write draft-dtls-sdp in regards to the subsequent answerer side, we might as well require the subsequent offerer to stick to it's current role and not offer 'actpass'.

[taylor-b]

Ah, I see what you're getting at. In order to do demuxing, a new DTLS association must use a new transport (as described in section 5.1 of dtls-sdp). But with ICE, the answerer can not propose a new transport. Thus if using DTLS with ICE, only the offerer can start a new DTLS association.

I'll make a PR to clean up JSEP (moving that bullet from 5.3.1 to 5.3.2).

[rshpount]

First of all, dtls-sdp is supposed to work both with and without ICE. Without ICE, answering party can initiate a new DTLS association at any time. All it needs to do is allocate a new local transport (address/port).

If ICE is used, the correct rule should be to include current setup role if offer does not initiate ICE restart and actpass setup role if offer includes ICE restart. In case of ICE restart, offering party can propose to use existing DTLS association, but answering party can initiate a new DTLS association by allocating new candidates and new dlts-id in the answer, which might require role change.

For some reason people get confused by differences between those three cases (no ICE -- actpass, no ICE restart -- current role, ICE restart -- actpass). This is why I recommend always include actapss in the offer, since it does no harm as long as answer is correctly generated (currently negotiated setup role if new DTLS association is not established).

P.S. I almost wish to reintroduce setup=holdconn for offers without ICE restart, which will mean new DTLS association cannot be established.

[nils-ohlmeier]

Thanks for the clarification @rshpount

So since JSEP requires ICE I think we need to restrict the answerer to not changes roles. On the offerer side I guess we can stay with either 'actpass' or the current role (up to the implementation).

[rshpount]

@nils-ohlmeier We need to restrict the answerer from changing roles if there is no ICE restart and new DTLS association is not started. On the offerer side we should stay with 'actpass' if ICE restart and with 'actpass' or the current role (up to the implementation) if no ICE restart.

[nils-ohlmeier]

@rshpount 100% ACK. That is what I meant to say. Sorry I was focusing on the sub-cases without explicitly mentioning them.

[taylor-b]

The PR to move stuff from "initial answer" to "subsequent answer" is merged. So the remaining question is: should JSEP require "actpass" in offers? This is what's currently specified and seems recommended based on the discussion above.

[nils-ohlmeier]

My understanding is that for initial offers 'actpass' is already required, right? And my interpretation is that right now for subsequent offers an implementation could choose 'actpass' or it's current role. I don't see what we would gain from pinning it only to 'actpass' for subsequent offers, besides making the sanity checking logic on the answerer side a little bit less complex.

[rshpount]

I do not think requiring actpass in the subsequent offers makes the logic more complex. If we say that offer should contain the current role, then answerer still needs to know what current role is and check that the correct value was received in the offer (and fail the offer if unexpected value is there). If offer contains actpass, answerer can include the current role. I think the amount of code stays the same.

[taylor-b]

And my interpretation is that right now for subsequent offers an implementation could choose 'actpass' or it's current role.

Not quite; the subsequent offer rules are "initial offer rules + listed differences", and there's nothing that overrides the "actpass" requirement. So JSEP currently requires "actpass" for all offers. Maybe that could be clarified more somehow.

The motivation for always offering "actpass" is that, if the JSEP endpoint offers an ICE restart and the non-JSEP answerer wants a new DTLS association, it's allowed to choose any role, rather than being locked into the previous role (which may be "passive", which is suboptimal for an answerer).

[mparis]

Hello everyone, first of all thanks for the great work!!

If I have understood properly, your proposals aim to mandate the User Agents to be quite open (in the sense of allowing DTLS roles changes, etc.). From my point of view, this is against interoperability because we are limiting little implementations that would work if we would allow them to specify things like:

• I only support "active" role, so I announce "active" in both initial and subsequent offers and in answers.
• My previous role is "active" and I cannot change it, so I announce "active" in subsequent offers and answers.
• The remote peer aims to change the role, but I cannot change it.
• etc.

So, I see "a=setup" attr as a way of specifying what is supported by an endpoint.

[taylor-b]

I only support "active" role, so I announce "active" in both initial and subsequent offers and in answers.

This isn't even allowed by dtls-sdp though; the initial offer must always be "actpass".

• My previous role is "active" and I cannot change it, so I announce "active" in subsequent offers and answers.
• The remote peer aims to change the role, but I cannot change it.

A non-JSEP endpoint could have these restrictions, but it makes sense (to me) to require a JSEP endpoint to be as flexible/interoperable as possible.

I also don't see how it's difficult from an implementation perspective; if I understand correctly, the JSEP implementation just needs to be prepared to receive either packets for the existing DTLS association, or a ClientHello from a new association. Did you have a specific use case in mind where changing the role causes complications?

[rshpount]

I think the only problem I've seen with DTLS role implementation was actually in implementing "active" role. You need to support re-transmit timers for the active setup. You do not need timers for the "passive" role so some implementations skip support for active. I do not think this justifies not supporting both setup roles since it can cause real interop problems.

[ibc]

However one could argue that subsequent offers for existing m= lines should use the existing type, rather than actpass. This has been mentioned before, but we haven't yet taken any action on this, since there hasn't been a clear rationale for doing so.

Regardless SDP O/A renegotiation rules allow (or not) DTLS role change within the same transport, WebRTC may restrict it by imposing the current behavior, which is:

• re-offer MUST have "actpass".
• re-answer MUST have the corresponding role to keep the already established DTLS direction.

This is:

First SDP O/A:

Alice --> actpass --> Bob
Alice <--  active  <-- Bob

Second SDP O/A:

Bob --> actpass --> Alice
Bob <-- passive <-- Alice [1]

[1] Alice must choose "passive" so she keeps its previous role.

[ekr]

@taylor-b: is anything needed here? Can you summarize and make a PR/close as needed?

[taylor-b]

@ekr Summary:

The PR to move stuff from "initial answer" to "subsequent answer" is merged. So the remaining question is: should JSEP require "actpass" in offers? This is what's currently specified and seems recommended based on the discussion above.

I haven't seen a compelling reason for not requiring "actpass", so I'd recommend leaving JSEP as-is and closing this issue if that's ok with @mparis.

[ekr]

@mparis: this will be closed on Wednesday Jan 18 if we do not hear from you.

[juberti]

Closing accordingly.

[mparis]

Hello, I was offline, so first of all sorry for the delayed response. After your responses, I agree with requiring from all JSEP to support both DTLS roles (setup:actpass).

On the other hand, from my point of view the subsequent offer case should be discussed in https://github.com/cdh4u/draft-dtls-sdp/pull/21, and it should be closed before this one because right now there is an incongruence between jsep and dtls-sdp specs.

What do you think?

[ekr]

• The PR above has been closed, but allows you to send either actpass (SHOULD) or something consistent.

• The current text requires JSEP endpoints to sending actpass (http://rtcweb-wg.github.io/jsep/#rfc.section.5.2.1) for initial offers and is not modified by subsequent offers.

The result is that JSEP is more restrictive. This is consistent with our other practice.

[mparis]

So, I agree, thanks!!