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

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 <christer.holmberg@ericsson.com> wrote:

> Hi,
> 
> I guess 'SHOULD use actpass' would work.
> 
> Regards,
> 
> Christer
> 
> Sent from my Sony Ericsson Xperia arc S
> 
> Paul Kyzivat <pkyzivat@alum.mit.edu> 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 [christer.holmberg@ericsson.com]
>> *Gesendet:* Donnerstag, 14. November 2013 02:21
>> *An:* Schwarz, Albrecht (Albrecht)
>> *Cc:* mmusic@ietf.org; 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:albrecht.schwarz@alcatel-lucent.com]
>> *Lähetetty:* 14. marraskuuta 2013 3:11
>> *Vastaanottaja:* Christer Holmberg
>> *Kopio:* mmusic@ietf.org; 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 [christer.holmberg@ericsson.com]
>> *Gesendet:* Montag, 7. Oktober 2013 13:11
>> *An:* Schwarz, Albrecht (Albrecht)
>> *Cc:* mmusic@ietf.org <mailto:mmusic@ietf.org>; 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:albrecht.schwarz@alcatel-lucent.com]
>> *Lähetetty:* 7. lokakuuta 2013 13:56
>> *Vastaanottaja:* Christer Holmberg
>> *Kopio:* mmusic@ietf.org <mailto:mmusic@ietf.org>; 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:christer.holmberg@ericsson.com]
>> *Sent:* Dienstag, 24. September 2013 16:01
>> *To:* Schwarz, Albrecht (Albrecht)
>> *Cc:* mmusic@ietf.org <mailto:mmusic@ietf.org>; 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) [albrecht.schwarz@alcatel-lucent.com]
>> *Sent:* Tuesday, 24 September 2013 4:22 PM
>> *To:* Christer Holmberg
>> *Cc:* mmusic@ietf.org <mailto:mmusic@ietf.org>; 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:christer.holmberg@ericsson.com]
>> Sent: Montag, 23. September 2013 11:54
>> To: Schwarz, Albrecht (Albrecht)
>> Cc: mmusic@ietf.org <mailto:mmusic@ietf.org>; 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:albrecht.schwarz@alcatel-lucent.com]
>> Sent: 23. syyskuuta 2013 12:31
>> To: Christer Holmberg
>> Cc: mmusic@ietf.org <mailto:mmusic@ietf.org>; 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:christer.holmberg@ericsson.com]
>> Sent: Donnerstag, 19. September 2013 10:02
>> To: Schwarz, Albrecht (Albrecht)
>> Cc: mmusic@ietf.org <mailto:mmusic@ietf.org>
>> 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:albrecht.schwarz@alcatel-lucent.com]
>> Sent: 18. syyskuuta 2013 18:28
>> To: Christer Holmberg
>> Cc: mmusic@ietf.org <mailto:mmusic@ietf.org>
>> 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
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>> 
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic