Re: [MMUSIC] [mmusic-udptl-dtls-01] Establishment direction of DTLS session

["Charles Eckel (eckelcu)" <[e-mail]>]

Hi Christer,

Yes, I understand and agree with that. As mentioned in the BFCPBIS thread,
indicating "actpass" in the offer is important for B2BUAs that rely on
this in order to be able to match up the two sides of a call. For example,
such a B2BUA would send an INVITE without an offer and expect to receive
back an offer with the capabilities of the remote endpoint. If that
endpoint sends back "actpass" in its offer, the B2BUA is free to answer
with either "active" or "passive" in order to match this up with the
associated call on the other side of the B2BUA. This way the B2BUA can
participate in the SIP/SDP signaling yet not be in the path of the the
BFCP over DTLS channel.

Cheers,
Charles

On 11/23/13 4:39 AM, "Christer Holmberg" <[e-mail]>
wrote:

>Hi Charles,
>
>In the thread you refer to, I don't think you considered the alternative
>we are discussing now :)
>
>The discussion was more about whether the setup attribute shall be used
>to determine the TLS role to begin with, and the outcome was that the
>attribute IS used. We are NOT changing that for UDPTL-DTLS, we are simply
>relaxing the MUST-indicate-actpass-in-the-offer rule.
>
>Regards,
>
>Christer
>
>Sent from my Sony Ericsson Xperia arc S
>
>"Charles Eckel (eckelcu)" <[e-mail]> wrote:
>
>
>Within the BFCPBIS working group, we debated this same point. In the end,
>we decided it was best to align with RFC 5763. Here is the thread for your
>reference:
>http://www.ietf.org/mail-archive/web/bfcpbis/current/msg00167.html
>
>Cheers,
>Charles
>
>
>On 11/15/13 2:56 PM, "Gonzalo Salgueiro (gsalguei)" <[e-mail]>
>wrote:
>
>>TBH I didn't see a compelling reason to make the change in the first
>>place. If it is important to Albrecht, I think this proposal is fine and
>>seems innocuous to the proposed solution.
>>
>>Gonzalo
>>
>>
>>On Nov 14, 2013, at 12:52 AM, Christer Holmberg
>><[e-mail]> wrote:
>>
>>> Hi,
>>>
>>> I guess 'SHOULD use actpass' would work.
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>> Sent from my Sony Ericsson Xperia arc S
>>>
>>> Paul Kyzivat <[e-mail]> wrote:
>>>
>>>
>>> I believe that the a=setup attribute was first defined by rfc 4145, for
>>>TCP.
>>>
>>> There it governs who listens for an incoming connection. And the main
>>> concern was that NATs/FWs might prevent one end or the other from
>>> accepting incoming connections. Even so, it didn't have any normative
>>> behavior about what should be in the offer.
>>>
>>> As this same attribute is used in different contexts, the implications
>>> of using it may vary. In particular, if it is intended that either end
>>> should be able to take either the active or passive role, then the
>>> considerations for use may vary.
>>>
>>> ISTM that actpas SHOULD be used in the offer, except in cases where the
>>> offerer has a particular preference for active or passive, and would
>>> prefer to have the connection fail than use the other mode.
>>>
>>>        Thanks,
>>>        Paul
>>>
>>> On 11/13/13 5:31 PM, Schwarz, Albrecht (Albrecht) wrote:
>>>> Right.
>>>>
>>>>
>>>>-----------------------------------------------------------------------
>>>>-
>>>> *Von:* Christer Holmberg [[e-mail]]
>>>> *Gesendet:* Donnerstag, 14. November 2013 02:21
>>>> *An:* Schwarz, Albrecht (Albrecht)
>>>> *Cc:* [e-mail]; LANDAIS, BRUNO (BRUNO)
>>>> *Betreff:* VS: [mmusic-udptl-dtls-01] Establishment direction of DTLS
>>>> session
>>>>
>>>> Hi Albrecht,
>>>>
>>>> If I understand your proposal correctly, the change would be to relax
>>>> the rule for assigning the SDP setup attribute value in the SDP Offer.
>>>> Instead of mandating actpass, we would also allow active and passive.
>>>>
>>>> Right?
>>>>
>>>> Regards,
>>>>
>>>> Christer
>>>>
>>>> *Lähettäjä:*Schwarz, Albrecht (Albrecht)
>>>> [mailto:[e-mail]]
>>>> *Lähetetty:* 14. marraskuuta 2013 3:11
>>>> *Vastaanottaja:* Christer Holmberg
>>>> *Kopio:* [e-mail]; LANDAIS, BRUNO (BRUNO)
>>>> *Aihe:* AW: [mmusic-udptl-dtls-01] Establishment direction of DTLS
>>>>session
>>>>
>>>> Hello Christer,
>>>> guess it's time to come back on this topic since the WG adopted the
>>>>draft.
>>>>
>>>> In brief ("don't want to repeat again the thread"):
>>>> a) problem statement: existing SDP O/A rules define a tighly coupled
>>>> mode between the establishment direction of the SIP session and the
>>>> establishment direction of the DTLS session, but there's not any
>>>> reasoning for such tightly coupled behaviour.
>>>>
>>>> b) change proposal:
>>>> Revise in clause 3.1 following list item
>>>>
>>>>    o  The endpoint MUST use the SDP setup attribute [RFC4145].  The
>>>>
>>>>       offerer MUST assign the SDP setup attribute with setup:actpass
>>>>
>>>>       value, and MUST be prepared to receive a DTLS client_hello
>>>>message
>>>>
>>>>       before it receives the SDP answer.  The answerer MUST assign the
>>>>
>>>>       SDP setup attribute with either setup:active value or
>>>>
>>>>       setup:passive value.  The answerer SHOULD assign the SDP setup
>>>>
>>>>       attribute with the setup:active value.  Whichever party is
>>>>active
>>>>
>>>>       MUST initiate a DTLS handshake by sending a ClientHello over
>>>>each
>>>>
>>>>       flow (host/port quartet).
>>>>
>>>>
>>>> by
>>>>
>>>>    o  The endpoint MUST use the SDP setup attribute [RFC4145].  The
>>>>
>>>>       offerer MUST assign the SDP setup attribute with a
>>>>setup:actpass,
>>>> setup:active or setup:passive
>>>>
>>>>       value, and, in case of setup:actpass or setup:passive, MUST be
>>>> prepared to receive a DTLS client_hello message
>>>>
>>>>       before it receives the SDP answer.  The answerer MUST assign the
>>>>
>>>>       SDP setup attribute with either setup:active value or
>>>>
>>>>       setup:passive value.  The answerer SHOULD assign the SDP setup
>>>>
>>>>       attribute with the setup:active value, in case of setup:actpass
>>>> or setup:passive.  Whichever party is active
>>>>
>>>>       MUST initiate a DTLS handshake by sending a ClientHello over
>>>>each
>>>>
>>>>       flow (host/port quartet).
>>>>
>>>>
>>>> We would limit ourselves with the existing, restrictive SDP O/A rule.
>>>> And without any justification for such a constraint.
>>>>
>>>> Any comments?
>>>>
>>>> Regards,
>>>> Albrecht
>>>>
>>>>
>>>>
>>>>-----------------------------------------------------------------------
>>>>-
>>>>
>>>> *Von:*Christer Holmberg [[e-mail]]
>>>> *Gesendet:* Montag, 7. Oktober 2013 13:11
>>>> *An:* Schwarz, Albrecht (Albrecht)
>>>> *Cc:* [e-mail] <mailto:[e-mail]>; LANDAIS, BRUNO (BRUNO)
>>>> *Betreff:* VS: [mmusic-udptl-dtls-01] Establishment direction of DTLS
>>>> session
>>>>
>>>> Hi Albrecht,
>>>>
>>>> At this point, the community is making a decision about whether to
>>>>start
>>>> working on this.
>>>>
>>>> Once that is done, we will start looking into, and discuss, individual
>>>> technical issues etc, and your input will be highly appreciated.
>>>>
>>>> Regards,
>>>>
>>>> Christer
>>>>
>>>> *Lähettäjä:*Schwarz, Albrecht (Albrecht)
>>>> [mailto:[e-mail]]
>>>> *Lähetetty:* 7. lokakuuta 2013 13:56
>>>> *Vastaanottaja:* Christer Holmberg
>>>> *Kopio:* [e-mail] <mailto:[e-mail]>; LANDAIS, BRUNO
>>>>(BRUNO)
>>>> *Aihe:* RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS
>>>>session
>>>>
>>>> Hello Christer,
>>>>
>>>> I may not commit to submit a problem statement in the next couple of
>>>> weeks, just due to time reasons.
>>>>
>>>> At least a note (or editor¹s note) should be added to draft
>>>> mmusic-udptl-dtls in order to indicate the issue and that a solution
>>>> proposal is still pending.
>>>>
>>>> Thanks,
>>>>
>>>> Albrecht
>>>>
>>>> *From:*Christer Holmberg [mailto:[e-mail]]
>>>> *Sent:* Dienstag, 24. September 2013 16:01
>>>> *To:* Schwarz, Albrecht (Albrecht)
>>>> *Cc:* [e-mail] <mailto:[e-mail]>; LANDAIS, BRUNO (BRUNO)
>>>> *Subject:* RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS
>>>> session
>>>>
>>>> Hi Albrecht,
>>>>
>>>> I don't think putting a note somewhere in the fax draft is going to
>>>> solve anything.
>>>>
>>>> As you indicate, the issue exists in multiple documents, so it's a
>>>> generic issues.
>>>>
>>>> So, my suggestion is that you put together a short draft which
>>>>describes
>>>> the problem, and how you want to change it, and then we can have a
>>>>more
>>>> generic discussion about it. The WG can then decide whether we shall
>>>>fix
>>>> something, and if so, in which specs.
>>>>
>>>> Regards,
>>>>
>>>> Christer
>>>>
>>>>
>>>>-----------------------------------------------------------------------
>>>>-
>>>>
>>>> *From:*Schwarz, Albrecht (Albrecht)
>>>>[[e-mail]]
>>>> *Sent:* Tuesday, 24 September 2013 4:22 PM
>>>> *To:* Christer Holmberg
>>>> *Cc:* [e-mail] <mailto:[e-mail]>; LANDAIS, BRUNO (BRUNO)
>>>> *Subject:* RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS
>>>> session
>>>>
>>>> Hello Christer,
>>>>
>>>> the "copy & paste" action (across at least three "RFCs") seems to be
>>>>the
>>>> root cause of the issue :-(
>>>>
>>>> SIP session establishment and L4 security session (DTLS, TLS)
>>>> establishment directions should be principally decoupled because
>>>> application specific.
>>>>
>>>> We got here (wrt DTLS) three (different!) applications:
>>>> 1) Key exchange (RFC 5763)
>>>> 2) Conference control (rfc4582bis)
>>>> 3) Document transmission (udptl-dtls)
>>>>
>>>> All three applications are different in terms of number/type of
>>>> supported network models, security models or/and communication
>>>>topology.
>>>>
>>>> Consequently, the basic, application independent SDP O/A rules for
>>>>DTLS
>>>> session establishment would need to support that flexibility.
>>>> The application specific SIP/SDP profile could then still narrow down
>>>> the required SDP O/A rules.
>>>>
>>>> What we got so far: SDP O/A rules in three application specific "RFCs"
>>>> (RFC 5763, rfc4582bis, udptl-dtls), which are all tight to RFC 5773
>>>>:-(
>>>>
>>>> There might be two options to correct that copy & paste issue in
>>>> "udptl-dtls" in my opinion:
>>>> a) expand the SDP O/A rules for more flexibility
>>>> or
>>>> b) add a WARNING / NOTE about the inherent limitations (due to the
>>>> assumption of a network and communication environment according RFC
>>>>5763)
>>>>
>>>> What do you think?
>>>> Best regards,
>>>> Albrecht
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Christer Holmberg [mailto:[e-mail]]
>>>> Sent: Montag, 23. September 2013 11:54
>>>> To: Schwarz, Albrecht (Albrecht)
>>>> Cc: [e-mail] <mailto:[e-mail]>; LANDAIS, BRUNO (BRUNO)
>>>> Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS
>>>>session
>>>>
>>>> Hi Albrecht,
>>>>
>>>> I don't know what model people were focusing on when writing RFC 5763,
>>>> but the RFC does say:
>>>>
>>>> "The endpoint that is the offerer MUST use the setup attribute value
>>>>of
>>>> setup:actpass"
>>>>
>>>> ...which we also copied into the udptl-dtls draft.
>>>>
>>>> Now, if you want to change that, and allow the Offerer to "force" the
>>>> direction, I think you should start a separate thread about that.
>>>> Because, it is not specific to fax, in my opinion.
>>>>
>>>> Regards,
>>>>
>>>> Christer
>>>>
>>>> -----Original Message-----
>>>> From: Schwarz, Albrecht (Albrecht)
>>>> [mailto:[e-mail]]
>>>> Sent: 23. syyskuuta 2013 12:31
>>>> To: Christer Holmberg
>>>> Cc: [e-mail] <mailto:[e-mail]>; LANDAIS, BRUNO (BRUNO)
>>>> Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS
>>>>session
>>>>
>>>> Hello Christer,
>>>>
>>>> the decision about "DTLS session establishment direction" is ALWAYS up
>>>> to the SDP ANSWERER (according present 3.1).
>>>>
>>>> In order to decouple SIP session and DTLS session establishment
>>>> directions, then the SDP OFFERER should also to be able to use
>>>> "setup:active" and "setup:passive" (besides codepoint "setup:actpass")
>>>> in my understanding.
>>>>
>>>> I'm not sure whether the reference to RFC 5763 helps because I could
>>>> imagine that the subject comes down to the indicated network
>>>>scenarios,
>>>> lets look again at:
>>>> a) T - T
>>>> b) T -GW
>>>>
>>>> The existing udptl-dtls & RFC 5763 text seems to focus on model (a)
>>>> only: SDP O/A between two peering, terminal located SIP UAs (there is
>>>> NOT any SIP B2BUA).
>>>> But I could imagine that the SIP/SDP profiles for "T" and "GW" are not
>>>> necessarily the same in case of model (b): "T" as SDP Offerer may not
>>>> allowed to decide the DTLS session establishment direction, but "GW"
>>>>as
>>>> SDP offerer may need to enforce the DTLS session establishment
>>>>direction
>>>> (either way).
>>>>
>>>> Regards,
>>>> Albrecht
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Christer Holmberg [mailto:[e-mail]]
>>>> Sent: Donnerstag, 19. September 2013 10:02
>>>> To: Schwarz, Albrecht (Albrecht)
>>>> Cc: [e-mail] <mailto:[e-mail]>
>>>> Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS
>>>>session
>>>>
>>>> Hi Albrecht,
>>>>
>>>> The direction of the SIP session establishment and the DTLS session
>>>> establishment are NOT tightly coupled. The draft enables the Answerer
>>>>to
>>>> select whether it wants to act as DTLS client or DTLS server.
>>>>
>>>> Section 3.1 states:
>>>>
>>>> .... The
>>>> offerer MUST assign the SDP setup attribute with setup:actpass value,
>>>> and MUST be prepared to receive a DTLS client_hello message before it
>>>> receives the SDP answer. The answerer MUST assign the SDP setup
>>>> attribute with either setup:active value or setup:passive value. The
>>>> answerer SHOULD assign the SDP setup attribute with the setup:active
>>>> value. Whichever party is active MUST initiate a DTLS handshake by
>>>> sending a ClientHello over each flow (host/port quartet).
>>>>
>>>> The same rules apply for DTLS-SRTP (see Section 5 of RFC5763). In
>>>>fact,
>>>> we base the procedure on that RFC.
>>>>
>>>> BFCP-over-DTLS (draft-ietf-bfcpbis-rfc4582bis) also refers to the
>>>> DTLS-SRTP procedures for DTLS server determination.
>>>>
>>>> Regards,
>>>>
>>>> Christer
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Schwarz, Albrecht (Albrecht)
>>>> [mailto:[e-mail]]
>>>> Sent: 18. syyskuuta 2013 18:28
>>>> To: Christer Holmberg
>>>> Cc: [e-mail] <mailto:[e-mail]>
>>>> Subject: [mmusic-udptl-dtls-01] Establishment direction of DTLS
>>>>session
>>>>
>>>> The T.38 endpoint could be located in a terminal (= T.38 IAF) or in a
>>>> gateway, leading to three possible scenarios of
>>>> a) T - T
>>>> b) T -GW
>>>> c) GW-GW
>>>>
>>>> I'd like to scope on scenario (b) due to its asymmetry of user- and
>>>> network-side located T.38 endpoints.
>>>>
>>>> Christer,
>>>> I thought that the two directions of
>>>> 1) SIP session establishment and
>>>> 2) DTLS session establishment
>>>> should be NOT tightly coupled (as currently supposed to be in clause
>>>>3.1)?
>>>> The ietf draft should offer the flexibility in decoupling both
>>>> establishment directions.
>>>>
>>>> E.g., there might be the demand to limit DTLS session establishment in
>>>> T-to-GW direction (and apply rather the reverse direction) due
>>>> ClientHello associated security threats, resource requests in terms of
>>>> memory, ...
>>>>
>>>> In my opinion:
>>>> the IETF should allow the flexibility,
>>>> other SDOs could still profile/limit this capability.
>>>>
>>>> Best regards,
>>>> Albrecht
>>>>
>>>> PS
>>>> We had a similar discussion with TLS, there NAT traversal (NAT-T)
>>>> aspects could influence TLS session establishment direction. However,
>>>>I
>>>> guess that NAT-T is minor for DTLS/UDP.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> mmusic mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>> _______________________________________________
>>> mmusic mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>>_______________________________________________
>>mmusic mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/mmusic
>