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

Christer Holmberg <> Thu, 19 September 2013 08:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 56ABA21F9AEF for <>; Thu, 19 Sep 2013 01:01:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.184
X-Spam-Status: No, score=-5.184 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rBhhJK5exQqe for <>; Thu, 19 Sep 2013 01:01:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A148A21F9B8A for <>; Thu, 19 Sep 2013 01:01:32 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-5e-523aaf5b5704
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 50.C3.03802.B5FAA325; Thu, 19 Sep 2013 10:01:31 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Thu, 19 Sep 2013 10:01:30 +0200
From: Christer Holmberg <>
To: "Schwarz, Albrecht (Albrecht)" <>
Thread-Topic: [mmusic-udptl-dtls-01] Establishment direction of DTLS session
Thread-Index: Ac60g62jSxVm2TCNSGW1wolV+AvE6AAhc/7w
Date: Thu, 19 Sep 2013 08:01:30 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+JvjW70eqsgg+5NwhZ/Wn8xWkxd/pjF gcmj9dleVo8lS34yBTBFcdmkpOZklqUW6dslcGV8mHKYveC8UMWPicfZGhin8HcxcnJICJhI HPqzkh3CFpO4cG89WxcjF4eQwGFGiYd/r0E5SxglXhy4ytzFyMHBJmAh0f1PG6RBRMBD4v6C Y2wgYWYBdYmri4NAwsIC3hL7T+1jgyjxkdjQe5AJwjaSeN0+iRnEZhFQlei51c4CYvMK+Eo8 /TUFrF5IIEriU28vmM0pEC0x5dEDMJsR6Lbvp9aAzWEWEJe49WQ+E8TNAhJL9pxnhrBFJV4+ /scKco6EgKLE8n45iHIdiQW7P7FB2NoSyxa+ZoZYKyhxcuYTlgmMYrOQTJ2FpGUWkpZZSFoW MLKsYmTPTczMSS832sQIjI+DW36r7mC8c07kEKM0B4uSOO9mvTOBQgLpiSWp2ampBalF8UWl OanFhxiZODilGhid9614NPvMedV6XcGrxQFxj7+tfiIf/0ra5mnN+6m2y2v6V/wqaeOYKHdt knLDXP5fzKc3H5D6XrfYwTpr2eslf5nl5x9569FWGXPfLvDCPc5sw+Llp4873Uqya1ZwrBRg 37HCrPuQSl9URpHLep4t7875/md+kj5v1wnhSapqWzgCXP7N+OGmxFKckWioxVxUnAgA6zAF 310CAAA=
Cc: "" <>
Subject: Re: [MMUSIC] [mmusic-udptl-dtls-01] Establishment direction of DTLS session
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: Thu, 19 Sep 2013 08:01:39 -0000

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.



-----Original Message-----
From: Schwarz, Albrecht (Albrecht) [] 
Sent: 18. syyskuuta 2013 18:28
To: Christer Holmberg
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.

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,

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.