Subject: Re: [MMUSIC] Symmetry breaking for DTLS-SRTP

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 19 Nov 2007 12:21:14 -0500

I was looking over the dtls set of specs, and didn't see a resolution to 
this issue in any of them.

I think Robert's suggestion is fine. Generally it is the controllers job 
to make sure that the SDP meets the requirements for O/A; there is never 
a blind passing of parameters back and forth. The only thing that is 
needed is to make sure that endpoints signal actpass in initial offers. 
You'd run into problems if the following happend:

INVITE (a=setup:passive) --->
                              INVITE (no SDP)--->

                              <-- 200 (a=setup:passive)

                       uh oh

If we can add a statement to draft-fischl-mmusic-dtls-sdp that basically 
says clients MUST use actpass in initial offers, I think we'd be fine.

Thanks,
Jonathan R.

Robert R. Gilman wrote:
> My example shows the same thing: the Controller has to (at least) turn
> "a=setup: actpass" into "a=setup: active" in one direction and "a=setup:
> passive" in the other.  It could also "harmonize" codec parameters, etc.,
> (possibly the reason the Controller bothered to intervene in the first
> place.)  I don't think anyone would call it "pretty", but I can't say
> someone won't find a good use for it.  The "solution" costs us almost
> nothing if the Controller is absent: the endpoint always responds to an
> offer with "a=setup:active" unless it has a good reason not to  The
> typical endpoint will know how to act as either a client and a server,
> and those that can't (e.g., an answer-only endpoint that demands to
> be "active") must say so in their offers.  As you point out, it's
> the job of the Controller to make sense of what it's created (if it
> can.)
> -Bob
> ----------------------------------------------------
> Bob Gilman       [email-masked]      +1 303 538 3868
> 
> Elwell, John wrote:
>> OK, but to take my example of SDP capability negotiation, the controller
>> would have to resolve it somehow, i.e., for each leg, select a
>> configuration that is compatible with one of the proposed configurations
>> from Alice and with one of the proposed configurations from Bob, and
>> include this in the answers to Alice and Bob respectively. Ugly.
>>
>> John
>>
>>
>>> -----Original Message-----
>>> From: Robert R. Gilman [mailto:[email-masked]] Sent: 26 October 2007 
>>> 21:23
>>> To: Elwell, John; Eric Rescorla
>>> Cc: [email-masked]
>>> Subject: Re: [MMUSIC] Symmetry breaking for DTLS-SRTP
>>>
>>> John-
>>> I think such flows can arise from a case in which one party, rather than
>>> the controller, intiates the call.  But, as you point out, the 
>>> controller
>>> cannot blindly pass one offer through to serve as an answer; it must
>>> modify the SDP in some cases.  For DTLS, in accord with the rules in
>>> section 4.1 of RFC 4145, the offeror, assuming it can act as either a
>>> server or a client, should use
>>>     a=setup-attr: actpass
>>> and should be prepared to receive a client_hello before it receives the
>>> answer.  In the two-party case, the answer would normally include
>>>     a=setup: active
>>> and the answerer would go ahead and send the client_hello in the media
>>> path.  This permits the controller (indeed, it requires the controller)
>>> to break the symmetry by modifying the SDP, hence we don't need any
>>> random numbers (which remind me too much of the H.245 master/slave
>>> resolution scheme).  If, for some reason, an endpoint can only act as
>>> a server, say, then in must send passive, and the controller can adjust
>>> which end it selects to be active - or it can refuse the call (or
>>> terminate the media on a media server) if both endpoints insist on the
>>> same role.  I believe this scheme is compatible with Dan Wing's draft:
>>> draft-wing-sip-identity-media-00.
>>>
>>> The exchange might look something like this:
>>>
>>> Alice                        Controller                        Bob
>>> ------------------------------------------------------------------
>>> INVITE + Offer(actpass) ->
>>>                                     INVITE ->
>>>                                              <- OK + Offer(actpass)
>>>           <- OK + Answer(active)    ACK + Answer(passive) ->
>>>       <- - - - - - - - - - - client_hello - - - - - - - - - -
>>> ACK ->
>>>                               ....
>>> Does this make sense?
>>> -Bob
>>> ----------------------------------------------------
>>> Bob Gilman       [email-masked]      +1 303 538 3868
>>>
>>> Elwell, John wrote:
>>>
>>>> Ekr,
>>>>
>>>> I don't have a problem with the solution, but I am doubtful 
>>>
>>> whether it
>>>
>>>> is a problem we need to solve. The case illustrated is based on the
>>>> assumption that offer and answer are symmetrical, in the 
>>>
>>> sense that an
>>>
>>>> offer can be reused as an answer (and vice versa). In this case the
>>>> offer from A becomes an answer to B and vice versa. There are two
>>>> extensions to SDP that I am aware of that break this, and 
>>>
>>> therefore any
>>>
>>>> controller that misuses SDP in this way will screw things up. One
>>>> example is the key management extension when used to carry MIKEY,
>>>> because a MIKEY request (which always goes in the offer) is very
>>>> different in syntax and semantics from a MIKEY response 
>>>
>>> (which always
>>>
>>>> goes in the answer). Of course, this will not apply when 
>>>
>>> using DTLS-SRTP
>>>
>>>> as the means of key management. The second example is the 
>>>
>>> SDP capability
>>>
>>>> negotiation draft, which certainly will be applicable with 
>>>
>>> DTLS-SRTP.
>>>
>>>> I am not aware of how the particular flow shown would 
>>>
>>> arise. It is not
>>>
>>>> documented in RFC 3725 (3PCC). It has similarities to flow II in RFC
>>>> 3725, which the RFC does not recommend. The other 3PCC 
>>>
>>> flows in RFC 3725
>>>
>>>> do not mix up offers and answers in this way.
>>>>
>>>> I also questioned the need for the solution in ICE, but as it came
>>>> virtually for free, it was not worth arguing about.
>>>>
>>>> If we continue this discussion, I would suggest we stick to 
>>>
>>> the MMUSIC
>>>
>>>> list rather than AVT.
>>>>
>>>> John
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Eric Rescorla [mailto:[email-masked]] Sent: 24 
>>>>> October 2007 17:59
>>>>> To: [email-masked]; [email-masked]
>>>>> Subject: [MMUSIC] Symmetry breaking for DTLS-SRTP
>>>>>
>>>>> TLS (and by extension) DTLS-SRTP requires unambiguity about 
>>>
>>> which side
>>>
>>>>> is to be the client and which is the server. This isn't an issue of
>>>>> credentials--DTLS-SRTP assumes that each side can take either
>>>>> role--it's just that TLS requires that one side initiate the
>>>>> handshake. My original intention had been to make this 
>>>
>>> conditional on
>>>
>>>>> which side was the offerer and which was the answerer, but 
>>>
>>> JDR pointed
>>>
>>>>> out in ORD that there are cases involving 3PCC where it's not
>>>>> unambiguous which is which.
>>>>>
>>>>> Here's the paradigmatic case, transcribed from a phone call with
>>>>> JDR (so any errors are my fault):
>>>>>
>>>>>
>>>>> Alice                        Controller                        Bob
>>>>> ------------------------------------------------------------------
>>>>> INVITE + Offer ->
>>>>>                             INVITE ->
>>>>>                                                    <- OK + Offer
>>>>>                     <- OK + Answer                              
>>>>>                             ACK + Answer ->
>>>>> ACK ->
>>>>>
>>>>> Because the controller sends an INVITE with no offer, Bob is the
>>>>> offererer, and of course Alice is. So, you can't use offerer
>>>>> or answerer to break symmetry.
>>>>> This same problem occurs with ICE, which uses a random tiebreaker
>>>>> value in the ICE messages to determine which side should take
>>>>> which role (controlling vs. controlled). This works because
>>>>> in ICE both sides are trying to transmit so they quickly detect 
>>>>> conflicts. Unfortunately, in DTLS-SRTP, the server just
>>>>> waits so if the rule we adopt allows both sides to think they
>>>>> are the server then we get deadlock. The above exchange shows how 
>>>>> both sides can be offerer so clearly we can't have
>>>>> offerer=server, but it seems that we could make a new exchange
>>>>> where both sides are answerer in which case we can't have
>>>>> offerer=client. JDR tells me that we don't have an actual
>>>>> use case like this yet but I would not want to count on that
>>>>> unless we're very sure.
>>>>>
>>>>> We could use exactly the trick that ICE uses but that requires
>>>>> modifying DTLS to make the server send messages unprompted.
>>>>> I don't think that's necessary here because we can break
>>>>> the tie in the SDP where we announce the DTLS-SRTP capability
>>>>> (however that's done).
>>>>>
>>>>> The basic principle is this:
>>>>> 1. Each side generates a random tiebreaker value T.
>>>>> 2. In the SDP offer/answer, he indicates whether he wishes
>>>>>  to be the TLS client or server (if you're the offerer
>>>>>  you SHOULD ask to be the server since that's faster,  and vice 
>>>>> versa).
>>>>> 3. If each side sees a consistent view (one client, one  server) 
>>>>> then that is what is used.
>>>>> 4. If the views are inconsistent, then the side with the
>>>>>  higher T is be the client.
>>>>>
>>>>> This is basically the same algorithm as used with ICE, just
>>>>> moving the tiebreaker into the SDP.
>>>>>
>>>>> Does anyone see a problem with this?
>>>>>
>>>>> -Ekr
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> mmusic mailing list
>>>>> [email-masked]
>>>>> https://www1.ietf.org/mailman/listinfo/mmusic
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> mmusic mailing list
>>>> [email-masked]
>>>> https://www1.ietf.org/mailman/listinfo/mmusic
>>>
>>>
>>
> 
> 
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic