Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0101C21E81E1 for ; Mon, 7 Oct 2013 04:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.179 X-Spam-Level: X-Spam-Status: No, score=-5.179 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCy1xPWop18y for ; Mon, 7 Oct 2013 04:11:55 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id F178221E817B for ; Mon, 7 Oct 2013 04:11:50 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-f4-525296f5b587 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 9E.72.16099.5F692525; Mon, 7 Oct 2013 13:11:49 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0328.009; Mon, 7 Oct 2013 13:11:05 +0200 From: Christer Holmberg To: "Schwarz, Albrecht (Albrecht)" Thread-Topic: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Thread-Index: AQHOw0vSqs2p+EtM3Ue3aa2C9ZzcDJnpE5VA Date: Mon, 7 Oct 2013 11:11:04 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4B6352@ESESSMB209.ericsson.se> References: <786615F3A85DF44AA2A76164A71FE1AC0BA3EC@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1C4A769E@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC0BC423@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1C4A9A45@ESESSMB209.ericsson.se>, <786615F3A85DF44AA2A76164A71FE1AC0BD395@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1C4AB001@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC0C68BB@FR711WXCHMBA03.zeu.alcatel-lucent.com> In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC0C68BB@FR711WXCHMBA03.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4B6352ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyM2K7t+7XaUFBBl1rTSz+tP5itNi6PtFi 6vLHLA7MHq3P9rJ6LFnykymAKYrLJiU1J7MstUjfLoEr4+dkq4LZNxkrDn26wdrAOGsPYxcj J4eEgInE2f17oWwxiQv31rOB2EIChxglNu+P6WLkArIXM0rMmjsFqIiDg03AQqL7nzZIjYiA h8T9BcfA6pkF0iQmdK5nArGFBbwllnb2MUHU+Ehs6D0IZRtJPHk+HWwXi4CKxJaLt1hBbF4B X4k7aw6wQ+yaziLx6uttsAZOgWiJT40XwBYwAh33/dQaJohl4hIfDl5nhjhaQGLJnvNQtqjE y8f/WCFsJYlFtz9D1edL3Go8yA6xTFDi5MwnLBMYRWchGTULSdksJGUQcT2JG1OnsEHY2hLL Fr6GqteVmPHvEAuy+AJG9lWM7LmJmTnp5YabGIHRdXDLb90djKfOiRxilOZgURLn/fDWOUhI ID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDI3eUVPeFm/cXWb5ieDjpuGWHsYZQulGBCMO2dcd/ /uU4/l/y3pF3Gtq3Dv69k1fgqM7ml33GcMan3vbGrTVN++KuzD4stOV20jLd6eeOrLY5V1qz UL/XUz1vx2ve2NPtkfHTKqYsL71Vv+qB9e/SEw/W3j4jKvPzF3MgS926t5denv/avvngCV8l luKMREMt5qLiRADqUy1YfAIAAA== Cc: "mmusic@ietf.org" , "LANDAIS, BRUNO \(BRUNO\)" Subject: Re: [MMUSIC] [mmusic-udptl-dtls-01] Establishment direction of DTLS session X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 11:12:02 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4B6352ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Albrecht, At this point, the community is making a decision about whether to start wo= rking on this. Once that is done, we will start looking into, and discuss, individual tech= nical issues etc, and your input will be highly appreciated. Regards, Christer L=E4hett=E4j=E4: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alca= tel-lucent.com] L=E4hetetty: 7. lokakuuta 2013 13:56 Vastaanottaja: Christer Holmberg Kopio: 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-dt= ls in order to indicate the issue and that a solution proposal is still pen= ding. 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; 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 a= nything. 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 th= e problem, and how you want to change it, and then we can have a more gener= ic discussion about it. The WG can then decide whether we shall fix somethi= ng, 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; 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 ro= ot 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 n= etwork models, security models or/and communication topology. Consequently, the basic, application independent SDP O/A rules for DTLS ses= sion establishment would need to support that flexibility. The application specific SIP/SDP profile could then still narrow down the r= equired 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-dtl= s" 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 assumpti= on 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; 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 set= up:actpass" ...which we also copied into the udptl-dtls draft. Now, if you want to change that, and allow the Offerer to "force" the direc= tion, 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; 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 t= he 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 "set= up:passive" (besides codepoint "setup:actpass") in my understanding. I'm not sure whether the reference to RFC 5763 helps because I could imagin= e 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: S= DP 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 nece= ssarily the same in case of model (b): "T" as SDP Offerer may not allowed t= o 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 Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Hi Albrecht, The direction of the SIP session establishment and the DTLS session establi= shment are NOT tightly coupled. The draft enables the Answerer to select wh= ether 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 M= UST be prepared to receive a DTLS client_hello message before it receives t= he 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 (hos= t/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 Subject: [mmusic-udptl-dtls-01] Establishment direction of DTLS session The T.38 endpoint could be located in a terminal (=3D T.38 IAF) or in a gat= eway, 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 establishmen= t 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 asso= ciated 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 c= ould influence TLS session establishment direction. However, I guess that N= AT-T is minor for DTLS/UDP. --_000_7594FB04B1934943A5C02806D1A2204B1C4B6352ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Albrech= t,

 = ;

At this po= int, the community is making a decision about whether to start working on t= his.

 = ;

Once that = is done, we will start looking into, and discuss, individual technical issu= es etc, and your input will be highly appreciated.

 = ;

Regards,

 = ;

Christer

 = ;

L=E4hett=E4j=E4: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.com= ]
L=E4hetetty: 7. lokakuuta 2013 13:56
Vastaanottaja: Christer Holmberg
Kopio: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO)
Aihe: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS ses= sion

 

Hello Chri= ster,

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 i= n 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; LANDAIS,= BRUNO (BRUNO)
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS = session

 

Hi Albrecht,

 

I don't think putting a note some= where 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 ch= ange 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; LANDAIS,= BRUNO (BRUNO)
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS = session

Hello Christe= r,

the "copy & paste" action (across at least three "RFCs&q= uot;) 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 n= etwork models, security models or/and communication topology.

Consequently, the basic, application independent SDP O/A rules for DTLS ses= sion establishment would need to support that flexibility.
The application specific SIP/SDP profile could then still narrow down the r= equired SDP O/A rules.

What we got so far: SDP O/A rules in three application specific "RFCs&= quot; (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 assumpti= on 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; 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 o= f 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. Beca= use, it is not specific to fax, in my opinion.

Regards,

Christer

-----Original Message-----
From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.co= m]
Sent: 23. syyskuuta 2013 12:31
To: Christer Holmberg
Cc: 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 ALWA= YS 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 imagin= e 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) onl= y: 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 "G= W" are not necessarily the same in case of model (b): "T" as= SDP Offerer may not allowed to decide the DTLS session establishment direc= tion, but "GW" as SDP offerer may need to enforce the DTLS sessio= n 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
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session=

Hi Albrecht,

The direction of the SIP session establishment and the DTLS session establi= shment are NOT tightly coupled. The draft enables the Answerer to select wh= ether 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 M= UST be prepared to receive a DTLS client_hello message before it receives t= he 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:a= ctive value. Whichever party is active MUST initiate a DTLS handshake by se= nding 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.co= m]
Sent: 18. syyskuuta 2013 18:28
To: Christer Holmberg
Cc: mmusic@ietf.org
Subject: [mmusic-udptl-dtls-01] Establishment direction of DTLS session

The T.38 endpoint could be located in a terminal (=3D T.38 IAF) or in a gat= eway, 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)?<= br> The ietf draft should offer the flexibility in decoupling both establishmen= t 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 asso= ciated 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 c= ould influence TLS session establishment direction. However, I guess that N= AT-T is minor for DTLS/UDP.

--_000_7594FB04B1934943A5C02806D1A2204B1C4B6352ESESSMB209erics_--