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

"Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com> Wed, 18 September 2013 15:28 UTC

Return-Path: <albrecht.schwarz@alcatel-lucent.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 438FB11E8254 for <mmusic@ietfa.amsl.com>; Wed, 18 Sep 2013 08:28:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.289
X-Spam-Status: No, score=-10.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Uv1D7inKHuGD for <mmusic@ietfa.amsl.com>; Wed, 18 Sep 2013 08:28:20 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com []) by ietfa.amsl.com (Postfix) with ESMTP id A3FDB11E81AD for <mmusic@ietf.org>; Wed, 18 Sep 2013 08:28:19 -0700 (PDT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com []) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r8IFSF8r007079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 18 Sep 2013 10:28:16 -0500 (CDT)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com []) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r8IFSDbG022993 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Sep 2013 17:28:13 +0200
Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([]) with mapi id 14.02.0247.003; Wed, 18 Sep 2013 17:28:13 +0200
From: "Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com>
To: "christer.holmberg@ericsson.com" <christer.holmberg@ericsson.com>
Thread-Topic: [mmusic-udptl-dtls-01] Establishment direction of DTLS session
Thread-Index: Ac60g62jSxVm2TCNSGW1wolV+AvE6A==
Date: Wed, 18 Sep 2013 15:28:12 +0000
Message-ID: <786615F3A85DF44AA2A76164A71FE1AC0BA3EC@FR711WXCHMBA03.zeu.alcatel-lucent.com>
Accept-Language: de-DE, 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-Scanned-By: MIMEDefang 2.57 on
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: [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 <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Sep 2013 15:28:27 -0000

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.