Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00
"Paul E. Jones" <paulej@packetizer.com> Tue, 03 September 2013 00:01 UTC
Return-Path: <paulej@packetizer.com>
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 266F221F8F2E for <mmusic@ietfa.amsl.com>; Mon, 2 Sep 2013 17:01:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.968
X-Spam-Level:
X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[AWL=-0.570, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_OEM_S_DOL=1.2]
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 9r7Kobkt6RUw for <mmusic@ietfa.amsl.com>; Mon, 2 Sep 2013 17:01:15 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id E036521F8E3D for <mmusic@ietf.org>; Mon, 2 Sep 2013 17:01:14 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r83014uW020045 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 2 Sep 2013 20:01:05 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1378166466; bh=oD28aeITaBoiwo+ttEZQI6CWwl1IuEs0qwlzwIywgn0=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=LTbmiginY7U2rxHsD2Xe5YlrHhdH9KI28TFGkDWH98MTp621fHZi6CCvXCgeJoyBC PVRM2swr4JxpgA0eQmGbOY+avbi2ADA5ERVeYo4uPAJOstnrcluhl70vEWX+KXHDyD mAy9rSP5PwvMoYm1Oo1zKhdQ7OZTYbELESIIHV10=
From: "Paul E. Jones" <paulej@packetizer.com>
To: "'Schwarz, Albrecht (Albrecht)'" <albrecht.schwarz@alcatel-lucent.com>, 'Christer Holmberg' <christer.holmberg@ericsson.com>
References: <7594FB04B1934943A5C02806D1A2204B1C46787F@ESESSMB209.ericsson.se> <E158A6F0-2A84-4B81-AFDE-CFF5E1EDE295@cisco.com> <7594FB04B1934943A5C02806D1A2204B1C4754A3@ESESSMB209.ericsson.se> <361F2B18-D0B3-487B-A534-8E8D4604561D@cisco.com> <7594FB04B1934943A5C02806D1A2204B1C47F98F@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC09654E@FR711WXCHMBA03.zeu.alcatel-lucent.com>
In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC09654E@FR711WXCHMBA03.zeu.alcatel-lucent.com>
Date: Mon, 02 Sep 2013 20:01:06 -0400
Message-ID: <016501cea838$b0e0cac0$12a26040$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0166_01CEA817.29D23800"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQGsxVthY13Zm+7ABUksXNfX2jZGbAKFXizuAeMYdV8BQt3G3QE62dBDAtHgJ1+ZqR77cA==
Content-Language: en-us
Cc: 'mmusic WG' <mmusic@ietf.org>, t13sg16q15@lists.itu.int
Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00
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: Tue, 03 Sep 2013 00:01:24 -0000
Folks, RTP was introduced primarily for use with SRTP, but it was not specified for use with SRTP since there was contention with respect to how keying material would be exchanged (e.g., SDES or something else). The more important part was just defining how to replace UDPTL as a transport. During that time, we were also exploring why T.38 fax failed so often, an area of work that seems to never end. The biggest challenge with FoIP has been timer expiry, corruption, and collisions on TDM links. Fax machines are sometimes slow to reply, there is delay end-to-end, and there are sometimes gateways in the path that introduce a lot of delay. All of those have been contributors to timer expiry and failed fax calls. In some testing we did, we even saw T.38 converted to audio and then carried via G.729. As you can imagine, the end result was not very desirable. So, T.38/RTP and Voice Band Data (VBD) (V.152) work was done to try to address some of the transport issues we were seeing, not only with fax, but also with other kinds of modulated signals. Use of RTP would have been better than UDPTL for security reasons, of course. DTLS is certainly a possible candidate today, though not having RTCP means that there is still some opportunity for packet loss to go undetected. We wanted those properties of RTP to help troubleshoot the network - properties completely lacking in UDPTL. (Yes, missing information can be detected, but missing information might be a TDM-link issue or an IP packet loss issue. UDPTL cannot differentiate.) Paul PS - I fully support the use of PDF over SMTP, BTW. It really gives customers a lot fewer headaches. From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.com] Sent: Monday, September 02, 2013 5:05 AM To: Christer Holmberg Cc: mmusic WG; t13sg16q15@lists.itu.int; Paul E. Jones Subject: RE: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00 Hello Christer, I did follow the T.38 development in ITU-T a couple of years, but I have to admit that I'm also missing the origins and history of T.4, T.30 and T.38 in the 1990 decade. The original requirement for secure fax transport was subject of the application protocol itself (e.g. T.30) AFAIK. That's why T.38 is silent on that aspect. The indication of RTP/SAVP in T.38 (2004) was listed just for completeness, but not really motivated by T.38 security requirements (Paul may correct me). Further, we should only refer to T.38 2010 (due to the well known issue with V.34G3 fax). That said, like to suggest following revision proposal to clause 1 and references, see below. Regards, Albrecht PS Cc'd ITU-T Q.15 SG16, which is technology owner of T.38 in current Study Period. 1. Introduction There are three transport options for T.38 fax-over-IP, called "T.38 transport modes" [ITU.T38.2010]. T.38 transport mode "UDPTL/UDP" [ITU.T38.1998] is the predominant protocol for fax transport in IP networks. The protocol stack for fax transport using UDPTL is shown in Table 1. +-----------------------------+ | Protocol | +-----------------------------+ | Internet facsimile protocol | +-----------------------------+ | UDPTL | +-----------------------------+ | UDP | +-----------------------------+ | IP | +-----------------------------+ Table 1: Protocol stack for UDPTL over UDP T.38 itself does not support integrity and confidentiality protection, because supposed to be subject of the application layer. NOTE 1: Encryption of end-to-end facsimile transfer between fax devices was/is historically part of the application layer, such as [ITU.T.30] in case of group 3 facsimile equipment (G3FE). See e.g., T.30 "Annex H - Security in facsimile G3 based on the RSA algorithm" Hence, none of the three T.38 transport modes was required to support additional security. NOTE 2: Keeping in mind that T.38 communication was/is normally limited between T.38 endpoints located in IP-PSTN gateways (due to G3FE) besides Internet-Aware Fax (IAF) devices). UDPTL does not offer integrity and confidentiality protection. To enable integrity and confidentiality protection, [ITU.T38.2004] specifies fax transport over RTP/SAVP. However, fax transport over RTP/SAVP is not widely supported. The 3rd Generation Partnership Project (3GPP) has performed a study on how to provide secure fax in the IP Multimedia Subsystem (IMS), which concluded that secure fax shall be transported using UDPTL over DTLS. NOTE 3: Because, 1st limited end-to-end scope ("IMS domain only") and 2nd support of transport security due to the assumption of unsecured facsimile data at application layer. . [ITU.T38.1998] International Telecommunications Union, "Procedures for real time Group 3 facsimile communication between terminals using IP Networks", ITU-T Recommendation T.38, 1998. [ITU.T38.2004] International Telecommunications Union, "Procedures for real-time Group 3 facsimile communication over IP networks", ITU-T Recommendation T.38, 2004. [ITU.T38.2010] International Telecommunications Union, "Procedures for real time Group 3 facsimile communication between terminals using IP Networks", ITU-T Recommendation T.38, 2010. https://www.itu.int/rec/dologin_pub.asp?lang=e <https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-T.38-201009-I!!PDF- E&type=items> &id=T-REC-T.38-201009-I!!PDF-E&type=items -----Original Message----- From: mmusic-bounces@ietf.org <mailto:mmusic-bounces@ietf.org> [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Donnerstag, 29. August 2013 10:17 To: Dan Wing Cc: mmusic WG Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00 Hi Dan, The protocols listed in draft-ietf-tls-applayerprotoneg-01 are used without SIP/SDP, so using such mechanism makes sense for those protocols. In SIP, SDP is used to negotiate the media (including nonsecure fax), and I see no reason why we should introduce a new mechanism for secure fax. Regards, Christer -----Original Message----- From: Dan Wing [ <mailto:dwing@cisco.com> mailto:dwing@cisco.com] Sent: 28. elokuuta 2013 20:41 To: Christer Holmberg Cc: mmusic WG Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00 On Aug 22, 2013, at 2:37 AM, Christer Holmberg < <mailto:christer.holmberg@ericsson.com> christer.holmberg@ericsson.com> wrote: > Hi Dan, > > Regarding the 3GPP SA3 study, the information I gave was a little misleading. From a security perspective SRTP would be fine. > > The focus of the SA3 study was on how to provide security for the existing fax transmission mechanism, which uses UDPTL/UDP. > > 3GPP already mandates IMS terminals to support UDPTL/UDP for unsecure fax. And, new terminals (supporting secure fax) are still required to also support unsecure fax, in order to communicate with legacy terminals when unsecure fax is sufficient. > > So, using UDPTL/DTLS/UDP for secure fax makes more sense, as it avoids implementing different mechanisms for secure and unsecure fax - UDPTL/DTLS/UDP only requires a new layer between UDPTL and UDP, it does not require changing the upper layers (UDPTL and above). > > Hopefully this clarifies :) (Sorry for my delay. I was on vacation.) Thanks for the clarification. Back to your document, it says: Since the DTLS record layer "application_data" packet does not indicate whether it carries UDPTL, or some other protocol, the usage of a dedicated DTLS association for transport of UDPTL needs to be negotiated, e.g. using the Session Description Protocol (SDP) [RFC4566] and the SDP offer/answer mechanism [RFC3264]. Therefore, this document specifies a new <proto> value [RFC4566] for the SDP "m=" line [RFC3264], in order to indicate UDPTL over DTLS in SDP messages [RFC4566]. Have you considered doing UDPTL negotiation in the DTLS handshake itself, using <http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg> http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg? That seems ideally suited for indicating the application layer protocol, perhaps in addition to the SDP signaling described in your I-D. -d > > Regards, > > Christer > > > > > > -----Original Message----- > From: Dan Wing [ <mailto:dwing@cisco.com> mailto:dwing@cisco.com] > Sent: 19. elokuuta 2013 20:43 > To: Christer Holmberg > Cc: mmusic; <mailto:mmusic-chairs@tools.ietf.org> mmusic-chairs@tools.ietf.org > Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00 > > > On Aug 19, 2013, at 6:03 AM, Christer Holmberg < <mailto:christer.holmberg@ericsson.com> christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> We have submitted a new draft, draft-holmberg-mmusic-udptl-dtls-00, which defines usage of UDPTL over DTLS, in order to provide secure fax. >> >> The draft was previously submitted to DISPATCH. Based on discussions with the ADs and chairs, it was decided that it shall be submitted to MMUSIC (note that no DTLS extensions are needed). >> >> As is indicated in the draft, 3GPP has performed a study on how to >> provide secure fax in the IMS, and the outcome was that secure fax shall be transported using UDPTL over DTLS. > > Got a pointer to that study? Seems easier to carry UDPTL over RTP, which would allow the RTP to be secured using SRTP (and thus the UDPTL would be secured using SRTP). There is a spec floating around to do exactly that (carry fax over RTP so that SRTP can secure it). Advantage of using SRTP to secure fax is it separates the keying mechanism from security, so that Security Descriptions / MIKEY / DTLS-SRTP / whatever-is-invented-in-2020 will work just as effectively for voice as for fax. And also that upgrading from a voice call to a "fax" call has no additional complexities due to security ("please press START to begin the fax transmission"). > > -d > > >> However, there is nothing "3GPP/IMS specific" about the mechanism, as UDPTL is commonly used for fax also elsewhere. >> >> Regards, >> >> Christer >> _______________________________________________ >> mmusic mailing list >> <mailto:mmusic@ietf.org> mmusic@ietf.org >> <https://www.ietf.org/mailman/listinfo/mmusic> https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list <mailto:mmusic@ietf.org> mmusic@ietf.org <https://www.ietf.org/mailman/listinfo/mmusic> https://www.ietf.org/mailman/listinfo/mmusic
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udp… Dan Wing
- [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-d… Christer Holmberg
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udp… Christer Holmberg
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udp… Dan Wing
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udp… Christer Holmberg
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udp… Christer Holmberg
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udp… Dan Wing
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udp… Christer Holmberg
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udp… Schwarz, Albrecht (Albrecht)
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udp… Paul E. Jones
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udp… Christer Holmberg
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udp… Paul E. Jones
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udp… Christer Holmberg
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udp… Christer Holmberg
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udp… Christer Holmberg
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udp… Schwarz, Albrecht (Albrecht)
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udp… Christer Holmberg
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udp… Schwarz, Albrecht (Albrecht)
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udp… Christer Holmberg
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udp… Schwarz, Albrecht (Albrecht)
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udp… Christer Holmberg