From albrecht.schwarz@alcatel-lucent.com Mon Feb 25 00:14:27 2013 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C2821F91EB; Mon, 25 Feb 2013 00:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAHAfJu8nKrq; Mon, 25 Feb 2013 00:14:26 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id ACEC121F923C; Mon, 25 Feb 2013 00:14:22 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1P8CP1N028498 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 25 Feb 2013 09:14:20 +0100 Received: from FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com ([135.120.45.52]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 25 Feb 2013 09:14:13 +0100 From: "Schwarz, Albrecht (Albrecht)" To: Hannes Tschofenig Date: Mon, 25 Feb 2013 09:14:12 +0100 Thread-Topic: [TLS] draft-tschofenig-lwig-tls-minimal = TLS profile proposal Thread-Index: Ac4R8Wip+rPWHA0PR9umXEmxNComLABPJqgg Message-ID: <5F7BCCF5541B7444830A2288ABBEBC9625FBE0154B@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> References: <5F7BCCF5541B7444830A2288ABBEBC9623DF010287@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> <512906A1.5060903@gmx.net> In-Reply-To: <512906A1.5060903@gmx.net> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "megaco@ietf.org" , "TLS@ietf.org" Subject: Re: [Megaco] [TLS] draft-tschofenig-lwig-tls-minimal = TLS profile proposal X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 08:14:27 -0000 [Cc'd Megaco =3D H.248] Hi Hannes, with regards to: > " such a simple protocol like Megaco " Hm, looks like that you missed a main point: there are two aspects a) Transport security for Diameter/Megaco/... protocol itself =3D RFC 3588 (clause 13.2. TLS Usage) for Diameter =3D H.248.67 for H.248 b) Transport security for Diamter/Megaco/... control IP transport connectio= ns ("called IP bearer connections in context of H.248") =3D ??? for Diameter =3D H.248.TLS (& H.248.TCP) for H.248 Any "TLS profile" concept would be valuable for both (a) and (b), but being= aware that present "TLS protocol profiling" for (a) is fairly minimal (per= haps still too high level). However, more challenging is "TLS protocol profiling" for (b), - for specif= ic applications (not web/http, but IMS/SIP controlled). Regards, Albrecht PS - MMUSIC related: E.g., the negotiation of TLS client/server roles is presently not yet suppo= rted by SDP offer/answer. RFC 4145 does only define the semantics for TCP c= lient/server roles, and RFC 4572 just provides the "fingerprint" capability= . PSS "simple protocol like Megaco": Not sure whether you are up to date :-) =3D> http://www.itu.int/rec/T-REC-H/e=20 See list of H.248.x-series of Recommendations ... -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 Sent: Samstag, 23. Februar 2013 19:13 To: Schwarz, Albrecht (Albrecht) Cc: TLS@ietf.org; hannes.tschofenig@gmx.net Subject: Re: [TLS] draft-tschofenig-lwig-tls-minimal =3D TLS profile propos= al Hi Albrecht, sorry that I missed your review comments. The term "TLS profile" could be a bit misleading. In your context (based on= the documents listed below) profile means (if I understood it correctly) a description of how to use TLS to secure a selected protocol (M= egaco in your case). Since TLS is a fairly widely used protocol there are m= any such descriptions available for TLS. For example, the Diameter base spe= cification says how to use TLS to secure Diameter peer-to-peer exchanges. When someone tries to use TLS (or DTLS) to secure protocols on a smart obje= ct or constraint node network then the initial reaction is that TLS is too = heavy to do that. Based on several implementations we do, however, know tha= t that's not true. The answer is of course more complex since TLS has many = features and even more extensions and the security requirements (as well as= non-security related requirements) may dictate which of these extensions a= re reasonable to use. That's what draft-tschofenig-lwig-tls-minimal tries to explain. Of course, = there is still work to provide better guidance (as you noticed). Ideally, I would like to provide a rough estimate of main memory, code size= , bandwidth requirements, and energy consumption for commonly used features= for these types of devices. In draft-tschofenig-lwig-tls-minimal we do not want to introduce new functi= onality that is in conflict with TLS/DTLS specifications. Regarding the mentioned TLS documents in your mail below I think you went a= bit too far in terms of describing TLS usage for such a simple protocol li= ke Megaco. I had intentionally mentioned Diameter since it provides similar= functionality and IMHO TLS with client and server certificates + a referen= ce to RFC 6125 would have been enough already. Ciao Hannes On 11/08/2012 11:47 AM, Schwarz, Albrecht (Albrecht) wrote: > Dear All, > like to raise a general comment to the group, driven by the "TLS=20 > minimal" draft: > Do agree to the message of this doc, guess that the subject as such is=20 > out of question in the TLS community. > Actually I've expected more concrete specification guidelines from the=20 > conclusion section. > Notions such as "TLS can be customized ...", "... required TLS=20 > functionality" or "It can be tailored to fit the needs of a specific=20 > deployment environment." point out that TLS related parameters and=20 > procedures could and should be specified in detail for a particular=20 > communication (and security) environment. > The answer could be the explicit introduction of a profile concept, -=20 > which is very well known already for some protocols. > Profiles could be more high level (like the "RTP profiles" (e.g. RFC > 3551 as a "minimum" ...) or fairly detailed (such as the 3GPP "SIP Gm=20 > profile" or H.248 profiles). > And there are already concepts for "TLS profiles" around, see e.g. > - "3GPP TLS Protocol Profile" (Annex E/33.310) > - "OMA TLS Profile" (OMA-TS-TLS-V1_...) or > - "Operating system xyz TLS Profile" ('xyz' as a placeholder for some=20 > well known OSs) However, all these TLS profile concepts are not really=20 > identical, sharing some common capabilities, but also adding some=20 > specifics. > The rational behind is the fact that an explicit TLS profile concept=20 > is not (yet?) introduced in the IETF TLS core RFCs in my understanding. > We faced the same situation in ITU-T SG16 in work items for=20 > H.248-controlled TLS services. > Thus, we made a definition proposal as a working assumption. > Interested parties may have a look in: > a) *H.248.TLS "H.248 packages for control of transport security"*=20 > _http://wftp3.itu.int/av-arch/avc-site/2009-2012/1209_Bri/TD-23.zip_ > *3.2.6 TLS-profile*: A selection of options from a set of TLS related > parameters and procedures. > and a concrete example may be found in: > *8.7 Example for the TLS profile concept* > b) *H.248.TLSPROF* "Guidelines on the use of H.248 capabilities for=20 > transport security in TLS networks in H.248 Profiles" > _http://wftp3.itu.int/av-arch/avc-site/2009-2012/1209_Bri/TD-2__4__.zi > p_=20 > > Would be interested whether the TLS WG experts > a) thought already about the definition of a profile for TLS (and DTLS)? > [Which would be a terminology definition and could be additionally a=20 > template for protocol profiling] > b) got any comments on our proposed TLS terms in above ITU-T work items? > Thanks, > Albrecht > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From albrecht.schwarz@alcatel-lucent.com Thu Feb 28 00:10:16 2013 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE03F21F85CE for ; Thu, 28 Feb 2013 00:10:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.799 X-Spam-Level: X-Spam-Status: No, score=-7.799 tagged_above=-999 required=5 tests=[AWL=-2.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhkD3Y818xbH for ; Thu, 28 Feb 2013 00:10:15 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id 46E5821F85B8 for ; Thu, 28 Feb 2013 00:10:09 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1S87j2g031492 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 28 Feb 2013 09:10:06 +0100 Received: from FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com ([135.120.45.52]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 28 Feb 2013 09:09:54 +0100 From: "Schwarz, Albrecht (Albrecht)" To: Christian Groves Date: Thu, 28 Feb 2013 09:09:52 +0100 Thread-Topic: Draft H.248.80; FW: [MMUSIC] RFC 6871 on Session Description Protocol (SDP) Media Capabilities Negotiation Thread-Index: Ac4VIfegqZg3g9HiQOan2bcKiW10UwAaMeSA Message-ID: <5F7BCCF5541B7444830A2288ABBEBC9625FBE01A42@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "megaco@ietf.org" Subject: [Megaco] Draft H.248.80; FW: [MMUSIC] RFC 6871 on Session Description Protocol (SDP) Media Capabilities Negotiation X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 08:10:16 -0000 Hello Chrisitian, guess you noted as well the publication of RFC 6871, which allows to finali= ze draft H.248.80. Regards, Albrecht -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= rfc-editor@rfc-editor.org Sent: Mittwoch, 27. Februar 2013 20:35 To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org Cc: mmusic@ietf.org; rfc-editor@rfc-editor.org Subject: [MMUSIC] RFC 6871 on Session Description Protocol (SDP) Media Capa= bilities Negotiation A new Request for Comments is now available in online RFC libraries. =20 RFC 6871 Title: Session Description Protocol (SDP) Media=20 Capabilities Negotiation=20 Author: R. Gilman, R. Even, F. Andreasen Status: Standards Track Stream: IETF Date: February 2013 Mailbox: bob_gilman@comcast.net,=20 roni.even@mail01.huawei.com,=20 fandreas@cisco.com Pages: 55 Characters: 124829 Updates: RFC5939 I-D Tag: draft-ietf-mmusic-sdp-media-capabilities-17.txt URL: http://www.rfc-editor.org/rfc/rfc6871.txt Session Description Protocol (SDP) capability negotiation provides a genera= l framework for indicating and negotiating capabilities in SDP. The base framework defines only capabilities for negotiating transport prot= ocols and attributes. This documents extends the framework by defining med= ia capabilities that can be used to negotiate media types and their associa= ted parameters. This document updates the IANA Considerations of RFC 5939. This document is a product of the Multiparty Multimedia Session Control Wor= king Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protoc= ol for the Internet community,and requests discussion and suggestions for i= mprovements. Please refer to the current edition of the Internet Official = Protocol Standards (STD 1) for the standardization state and status of this= protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author = of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifical= ly noted otherwise on the RFC itself, all RFCs are for unlimited distributi= on. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From Christian.Groves@nteczone.com Thu Feb 28 17:06:02 2013 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2424D21F886E for ; Thu, 28 Feb 2013 17:06:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1++XEuqLRKSu for ; Thu, 28 Feb 2013 17:06:01 -0800 (PST) Received: from ipmail06.adl6.internode.on.net (unknown [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id 4618E21F886D for ; Thu, 28 Feb 2013 17:06:00 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAN/9L1F20U5n/2dsb2JhbAANOMI0gRSDEgEBAQMBAQEBNRYFGwoBBQcECxEDAQEBAQkDEwQEBwkDAgECARUKFQgBCAYNAQUCAQEFCwcCBIdgAwkSrjKJRAiJRo1SgTcLBwaDOgOXX5EegUqBXg Received: from ppp118-209-78-103.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.78.103]) by ipmail06.adl6.internode.on.net with ESMTP; 01 Mar 2013 11:35:59 +1030 Message-ID: <512FFEF2.7090509@nteczone.com> Date: Fri, 01 Mar 2013 12:05:54 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Schwarz, Albrecht (Albrecht)" References: <5F7BCCF5541B7444830A2288ABBEBC9625FBE01A42@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> In-Reply-To: <5F7BCCF5541B7444830A2288ABBEBC9625FBE01A42@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "megaco@ietf.org" Subject: Re: [Megaco] Draft H.248.80; FW: [MMUSIC] RFC 6871 on Session Description Protocol (SDP) Media Capabilities Negotiation X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 01:06:02 -0000 Hello Albrecht, Yes I saw this was finalised. Good to be able to finalise H.248.80. I see also draft-westerlund-avtcore-rtp-topologies-update-02.txt has been updated to better describe middlebox/translator topologies that would be applicable for H.248.RTPTOPO. Regards, Christian On 28/02/2013 7:09 PM, Schwarz, Albrecht (Albrecht) wrote: > Hello Chrisitian, > guess you noted as well the publication of RFC 6871, which allows to finalize draft H.248.80. > Regards, > Albrecht > > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of rfc-editor@rfc-editor.org > Sent: Mittwoch, 27. Februar 2013 20:35 > To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org > Cc: mmusic@ietf.org; rfc-editor@rfc-editor.org > Subject: [MMUSIC] RFC 6871 on Session Description Protocol (SDP) Media Capabilities Negotiation > > > A new Request for Comments is now available in online RFC libraries. > > > RFC 6871 > > Title: Session Description Protocol (SDP) Media > Capabilities Negotiation > Author: R. Gilman, R. Even, > F. Andreasen > Status: Standards Track > Stream: IETF > Date: February 2013 > Mailbox: bob_gilman@comcast.net, > roni.even@mail01.huawei.com, > fandreas@cisco.com > Pages: 55 > Characters: 124829 > Updates: RFC5939 > > I-D Tag: draft-ietf-mmusic-sdp-media-capabilities-17.txt > > URL: http://www.rfc-editor.org/rfc/rfc6871.txt > > Session Description Protocol (SDP) capability negotiation provides a general framework for indicating and negotiating capabilities in SDP. > The base framework defines only capabilities for negotiating transport protocols and attributes. This documents extends the framework by defining media capabilities that can be used to negotiate media types and their associated parameters. > > This document updates the IANA Considerations of RFC 5939. > > This document is a product of the Multiparty Multimedia Session Control Working Group of the IETF. > > This is now a Proposed Standard. > > STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >