From jouni.nospam@gmail.com Sun Jan 1 23:31:24 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A722621F8F19 for ; Sun, 1 Jan 2012 23:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 svaZUZN8unxp for ; Sun, 1 Jan 2012 23:31:24 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id D8FB121F84DD for ; Sun, 1 Jan 2012 23:31:23 -0800 (PST) Received: by wibhj6 with SMTP id hj6so10265560wib.31 for ; Sun, 01 Jan 2012 23:31:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=YiYbFRQlIrM9Z9M00xJp6lXBk0onM00qXFRJcXa4fZ0=; b=dTwTSFt3RHc/oHXwASGik20B3TEF/C/NLfvyYb5qA5miFJBK++iaF80WDteC6RjBiz xLimB6v6UDqKHklIbaGzHRHZzDrcTHTMWhMpaGDR4rcuCvtnF+1e/VcHcUfE6z+0XEJf WbcdQ8M0mX7VxD7vR8fTC3yQz78WsatA8arfY= Received: by 10.180.90.40 with SMTP id bt8mr104577354wib.4.1325489483071; Sun, 01 Jan 2012 23:31:23 -0800 (PST) Received: from [10.255.134.110] ([192.100.123.77]) by mx.google.com with ESMTPS id g26sm23208527wbo.16.2012.01.01.23.31.20 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 01 Jan 2012 23:31:21 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4EF5B372.208@gmail.com> Date: Mon, 2 Jan 2012 09:31:16 +0200 Content-Transfer-Encoding: 7bit Message-Id: <0FC3FFC7-00A4-48DD-90FD-E6C408AE621F@gmail.com> References: <4FCEC779-A1AD-4A21-97B8-8AD1C99472C4@gmail.com> <4EF40D36.70400@gmail.com> <9FB03157-E7EE-4C3C-82E4-E699700BE200@gmail.com> <4EF5B372.208@gmail.com> To: Glen Zorn X-Mailer: Apple Mail (2.1084) Cc: dime@ietf.org Subject: Re: [Dime] re-chartering X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 07:31:24 -0000 Fine with me. Thanks for the input. - Jouni On Dec 24, 2011, at 1:11 PM, Glen Zorn wrote: > On 12/23/2011 6:54 PM, Romascanu, Dan (Dan) wrote: >> Should we also replace signaling by session management in the >> Description of the Working Group? > > Good idea; it might be good to be more specific that this is _Diameter_ > management as well, since "session" means lots of different things to > different people, many of those things having nothing to do w/AAA. > >> >> The Diameter Maintenance and Extensions WG will focus on maintenance >> and extensions to the Diameter protocol required to enable its use for >> authentication, authorization, accounting, charging in network access, >> provisioning of configuration information within the network, and for >> new session management uses within the extensibility rules of the >> Diameter base protocol. >> >> Dan >> >> >>> -----Original Message----- >>> From: Jouni [mailto:jouni.nospam@gmail.com] >>> Sent: Friday, December 23, 2011 10:25 AM >>> To: Glen Zorn >>> Cc: Romascanu, Dan (Dan); dime@ietf.org >>> Subject: Re: [Dime] re-chartering >>> >>> >>> >>>>> - Protocol extension for bulk and group signaling. The aim of this >>>>> work is to study and standardize a solution for handling groups of >>>>> sessions within the Diameter base protocol context. The solution >>> would >>>>> define how to identify and handle grouped sessions in commands and >>>>> operations. >>>> >>>> If you insist upon ignoring such important applications as state >>>> synchronization between agents, at least please change "signalling" >>> to >>>> "session management" since that at least comes within spitting >>> distance >>>> of actual AAA while generic "signalling" does not. >>>> >>>> ... >>> >>> - Protocol extension for bulk and group session management. The aim >> of >>> this work is to study and standardize a solution for handling >> groups >>> of sessions within the Diameter base protocol context. The solution >>> would define how to identify and handle grouped sessions in >> commands >>> and operations. >>> >>> Ok with me. >>> >>> >>> - Jouni > From jouni.nospam@gmail.com Mon Jan 2 02:40:22 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C06321F8EEC for ; Mon, 2 Jan 2012 02:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 tEet5otG1IuK for ; Mon, 2 Jan 2012 02:40:21 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 357C721F8EEB for ; Mon, 2 Jan 2012 02:40:21 -0800 (PST) Received: by werb14 with SMTP id b14so8709347wer.31 for ; Mon, 02 Jan 2012 02:40:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ft+sHpfjaS1vjHellK9/UQ5GcLLdq74G0TiZ31dVVM8=; b=Xs2pYb5PAOksddzXi9P7Fi/7RaeyZ7lzMCVbZWUCsk/p8Yn8q5xDjWb3WTww2tP75K Vh9MV88KvDfq8R+rbuVyOfOPZVYT1ZhuMtTF2l3E8IhDiVgSA3Bb+vR9o4Z7FOJNtKuJ 5c2bOvvZ2M9MsNjuLRZfSKPCPSFH9pULQEIDQ= Received: by 10.216.137.97 with SMTP id x75mr31630528wei.57.1325500820003; Mon, 02 Jan 2012 02:40:20 -0800 (PST) Received: from [10.255.134.110] ([192.100.123.77]) by mx.google.com with ESMTPS id v28sm8629519wbo.18.2012.01.02.02.40.18 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Jan 2012 02:40:19 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Mon, 2 Jan 2012 12:40:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FCEC779-A1AD-4A21-97B8-8AD1C99472C4@gmail.com> <4EF40D36.70400@gmail.com> <9FB03157-E7EE-4C3C-82E4-E699700BE200@gmail.com> To: dime@ietf.org X-Mailer: Apple Mail (2.1084) Cc: "lionel.morand@orange-ftgroup.com> Morand" Subject: Re: [Dime] re-chartering X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 10:40:22 -0000 Just to make a clean post to the list. The below is the revision = submitted for the next IESG meeting regarding DIME rechartering. - Jouni ----------------- Diameter Maintenance and Extensions (dime) ----------------------------------------- Current Status: Active Last Modified: 2011-12-27 Chairs: Lionel Morand Jouni Korhonen Operations and Management Area Directors: Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion: dime@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dime Archive: = http://www.ietf.org/mail-archive/web/dime/current/maillist.html Description of Working Group: The Diameter Maintenance and Extensions WG will focus on maintenance and extensions to the Diameter protocol required to enable its use for authentication, authorization, accounting, charging in network access, provisioning of configuration information within the network, and for new session management uses within the extensibility rules of the Diameter base protocol. The DIME working group plans to address the following items: - Maintaining and/or progressing, along the standards track, the Diameter Base protocol and Diameter Applications. This includes extensions to Diameter Base protocol that can be considered as = enhanced features or bug fixes. - Diameter application design guideline. This document will provide guidelines for design of Diameter extensions. It will detail when to consider reusing an existing application and when to develop a new application. - Protocol extensions for the management of Diameter entities. This = work focuses on the standardization of Management Information Bases (MIBs) to configure Diameter entities (such as the Diameter Base protocol or Diameter Credit Control nodes). The usage of other management = protocols for configuring Diameter entities may be future work within the group. - Protocol extension for bulk and group session management. The aim of this work is to study and standardize a solution for handling groups = of sessions within the Diameter base protocol context. The solution would define how to identify and handle grouped sessions in commands and operations. Additionally, Diameter-based systems require interoperability in order to work. The working group, along with the AD, will need to evaluate any potential extensions and require verification that the proposed extension is needed. Coordination with other IETF working groups and other SDOs will be used to ensure this. Goals and Milestones: Done - Submit the following two Diameter Mobility documents to the = IESG for consideration as a Proposed Standards:* 'Diameter Mobile IPv6: = Support for Home Agent to Diameter Server Interaction' * 'Diameter = Mobile IPv6: Support for Network Access Server to Diameter Server = Interaction' Done - Submit 'Diameter API' to the IESG for consideration as an = Informational RFC Done - Submit 'Quality of Service Parameters for Usage with = Diameter' to the IESG for consideration as a Proposed Standard. Done - Submit 'Diameter QoS Application' to the IESG for = consideration as a Proposed Standard Done - Submit 'Diameter Support for EAP Re-authentication = Protocol' as DIME working group item Done - Submit 'Diameter User-Name and Realm Based Request Routing = Clarifications' as DIME working group item Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working group = item Done - Submit 'Quality of Service Attributes for Diameter' to the = IESG for consideration as a Proposed Standard Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for = consideration as a Proposed Standard Done - Submit 'Diameter User-Name and Realm Based Request Routing = Clarifications' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter NAT Control Application' as DIME working = group item Done - Submit 'Diameter Capabilities Update' as DIME working group = item Done - Submit 'Diameter Credit Control Application MIB' to the = IESG for consideration as an Informational RFC Done - Submit 'Diameter Base Protocol MIB' to the IESG for = consideration as an Informational RFC Done - Submit 'Diameter Capabilities Update' to the IESG for = consideration as a Proposed Standard Done - Submit 'Diameter Extended NAPTR' as DIME working group item Done - Submit 'Realm-Based Redirection In Diameter' as DIME = working group item Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized = Routing' as DIME working group item Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic = Key Transport' as DIME working group item Done - Submit 'Diameter Priority Attribute Value Pairs' as DIME = working group item Done - Submit 'Diameter IKEv2 PSK' as DIME working group item Done - Submit Revision of 'Diameter Base Protocol' to the IESG for = consideration as a Proposed Standard Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic = Key Transport' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Priority Attribute Value Pairs' to the = IESG for consideration as a Proposed Standard Done - Submit Revision of 'Diameter Network Access Server = Application - RFC 4005bis' as DIME working group item Done - Submit 'Diameter NAT Control Application' to the IESG for = consideration as a Proposed Standard Done - Submit 'Diameter IKEv2 PSK' to the IESG for consideration = as a Proposed Standard Done - Submit 'Diameter Extended NAPTR' to the IESG for = consideration as a Proposed Standard Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized = Routing' to the IESG for consideration as a Proposed=20 Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the IESG = for consideration as a Proposed Standard Mar 2012 - Submit Revision of 'Diameter Network Access Server = Application - RFC 4005bis' to the IESG for consideration as a Proposed = Standard May 2012 - Submit 'Diameter Application Design Guidelines' to the IESG = for consideration as a BCP document Standard Jul 2012 - Submit 'Diameter Support for EAP Re-authentication = Protocol' to the IESG for consideration as a Proposed Standard Aug 2012 - Submit a document on 'Protocol extension for bulk and group = signaling' as a working group item Aug 2013 - Submit a document on 'Protocol extension for bulk and group = signaling' to the IESG for consideration as a Proposed Standard From internet-drafts@ietf.org Tue Jan 3 00:36:03 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE5421F851E; Tue, 3 Jan 2012 00:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 AeKssIiajgI7; Tue, 3 Jan 2012 00:36:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D888921F850C; Tue, 3 Jan 2012 00:36:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120103083602.12320.3345.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2012 00:36:02 -0800 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-rfc4005bis-06.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 08:36:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions W= orking Group of the IETF. Title : Diameter Network Access Server Application Author(s) : Glen Zorn Filename : draft-ietf-dime-rfc4005bis-06.txt Pages : 64 Date : 2012-01-03 This document describes the Diameter protocol application used for Authentication, Authorization, and Accounting (AAA) services in the Network Access Server (NAS) environment; it obsoletes RFC 4005. When combined with the Diameter Base protocol, Transport Profile, and Extensible Authentication Protocol specifications, this application specification satisfies typical network access services requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc4005bis-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-rfc4005bis-06.txt From lionel.morand@orange.com Tue Jan 3 09:24:47 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAE9921F84AC for ; Tue, 3 Jan 2012 09:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 SuVIP13MZy+j for ; Tue, 3 Jan 2012 09:24:47 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id C6DF121F8498 for ; Tue, 3 Jan 2012 09:24:46 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E7280A44183; Tue, 3 Jan 2012 18:26:10 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id DBDA5A44182; Tue, 3 Jan 2012 18:26:10 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Jan 2012 18:24:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Jan 2012 18:24:42 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] On RFC3588bis security.. Stephen Farrell's DISCUSS Thread-Index: AQHMqCj2+wJ4gdqW806UlxHEKgNa9ZW3A/QggEQhb/A= References: <9A2E9984-EA8E-41D7-9834-916F73DCF432@gmail.com> From: To: , , X-OriginalArrivalTime: 03 Jan 2012 17:24:44.0065 (UTC) FILETIME=[956C4110:01CCCA3C] Subject: Re: [Dime] On RFC3588bis security.. Stephen Farrell's DISCUSS X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 17:24:47 -0000 OK with the direction of the proposal. Just too questions for clarification: - do we keep a priority order between 1/(D)TLS and 2/IPsec as currently = documented in draft or is it also challenged by the Stephen's comment? - Is it clear that mandating the possible use of IPsec to secure the = connection does not mandate the peers to support of Diameter by the = peers (e.g. use of IPsec GWs btw peers)? Regards, Lionel=20 -----Message d'origine----- De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de Tina TSOU Envoy=E9=A0: lundi 21 novembre 2011 09:49 =C0=A0: jouni korhonen; dime@ietf.org Objet=A0: Re: [Dime] On RFC3588bis security.. Stephen Farrell's DISCUSS This solution works for me, though I think TLS is closer to what most of = the vendors currently implement. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of = jouni korhonen Sent: Monday, November 21, 2011 12:38 AM To: dime@ietf.org Subject: [Dime] On RFC3588bis security.. Stephen Farrell's DISCUSS Folks, During the meeting we had a discussion on Stephen Farrell's discuss: = https://datatracker.ietf.org/doc/draft-ietf-dime-rfc3588bis/ballot/#steph= en-farrell Glen had a solution proposal that we follow what Stephen suggested i.e. = mandate use of either IPsec or (D)TLS within the spec and leave out the = "some security mechanism". This of course has some impact on product & = deployment level as from now on either IPsec or (D)TLS must be used.. Any feedback? - Jouni _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From lionel.morand@orange.com Tue Jan 3 12:32:21 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04BC311E80FC for ; Tue, 3 Jan 2012 12:32:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 sYApHuGEcwmX for ; Tue, 3 Jan 2012 12:32:20 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id E75D711E80C7 for ; Tue, 3 Jan 2012 12:32:19 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id F0B465D8956; Tue, 3 Jan 2012 21:32:18 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id E53E25D888A; Tue, 3 Jan 2012 21:32:18 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Jan 2012 21:32:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Jan 2012 21:32:17 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] On RFC3588bis security.. Stephen Farrell's DISCUSS Thread-Index: AQHMqCj2+wJ4gdqW806UlxHEKgNa9ZW3A/QggEQhb/CAAEQFAP//8mNA References: From: To: , , , X-OriginalArrivalTime: 03 Jan 2012 20:32:19.0083 (UTC) FILETIME=[C9EFB5B0:01CCCA56] Subject: Re: [Dime] On RFC3588bis security.. Stephen Farrell's DISCUSS X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 20:32:21 -0000 Within 3GPP, the NDS relies on the use of IPsec GWs to secure IP = connections between nodes. And I was actually referring to that point in = my mail. Lionel -----Message d'origine----- De=A0: Avi Lior [mailto:avi@amdocs.com]=20 Envoy=E9=A0: mardi 3 janvier 2012 21:16 =C0=A0: MORAND Lionel RD-CORE-ISS; Tina.Tsou.Zouting@huawei.com; = jouni.nospam@gmail.com; dime@ietf.org Objet=A0: Re: [Dime] On RFC3588bis security.. Stephen Farrell's DISCUSS Leaving out "some other security mechanism" is a problem for example to 3GPP where they rely on Network Domain Security - (a closed secure environment). I think we can address the concern by stating that other security mechanisms can be used where they provide the same or better security mechanisms such as those provided by DTLS, TLS, or Ipsec. As we can see we can by the email thread we can debate about TLS vs = Ipsec vs. DTLS and in some cases neither of those would work or be desirable. For interoperability purposes we need to mandate that Diameter implementation SHALL support DTLS and TLS or DTLS and IPSEC or DTLS and IPSEC and TLS but we should also allow for the case where something else can be used. On 12-01-03 12:24 , "lionel.morand@orange.com" wrote: >OK with the direction of the proposal. >Just too questions for clarification: >- do we keep a priority order between 1/(D)TLS and 2/IPsec as currently >documented in draft or is it also challenged by the Stephen's comment? >- Is it clear that mandating the possible use of IPsec to secure the >connection does not mandate the peers to support of Diameter by the = peers >(e.g. use of IPsec GWs btw peers)? > >Regards, > >Lionel=20 > >-----Message d'origine----- >De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de >Tina TSOU >Envoy=E9 : lundi 21 novembre 2011 09:49 >=C0 : jouni korhonen; dime@ietf.org >Objet : Re: [Dime] On RFC3588bis security.. Stephen Farrell's DISCUSS > >This solution works for me, though I think TLS is closer to what most = of >the vendors currently implement. > > >Best Regards, >Tina TSOU >http://tinatsou.weebly.com/contact.html > >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of >jouni korhonen >Sent: Monday, November 21, 2011 12:38 AM >To: dime@ietf.org >Subject: [Dime] On RFC3588bis security.. Stephen Farrell's DISCUSS > >Folks, > >During the meeting we had a discussion on Stephen Farrell's discuss: >https://datatracker.ietf.org/doc/draft-ietf-dime-rfc3588bis/ballot/#step= he >n-farrell > >Glen had a solution proposal that we follow what Stephen suggested i.e. >mandate use of either IPsec or (D)TLS within the spec and leave out the >"some security mechanism". This of course has some impact on product & >deployment level as from now on either IPsec or (D)TLS must be used.. > >Any feedback? > >- Jouni >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime This message and the information contained herein is proprietary and = confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp From jouni.nospam@gmail.com Wed Jan 4 00:28:03 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2263621F86C8 for ; Wed, 4 Jan 2012 00:28:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 eGKD1aSnKuRt for ; Wed, 4 Jan 2012 00:28:02 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id EFC0D21F860C for ; Wed, 4 Jan 2012 00:28:01 -0800 (PST) Received: by laah2 with SMTP id h2so7102218laa.31 for ; Wed, 04 Jan 2012 00:28:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=FmwrQkqWiZCE6sG/g3x3gG0j1DZcpq+1jLwtMwN6YHg=; b=ITfIylOjfX/d1a/A2hcCQvPKOOQzf2seRZAjcDW4KXjSmFmmful8BYY8I+QCmS0Auv T92KRsnrnFSDBfUMTqBta4nZLIT/nJmeZP3dp5wm/ux3DmaSwAST9RIvKPDwm69SwBWE g65Qi0qG2qO5uCVsvB5hyduhEhn83g4RBbycc= Received: by 10.152.136.39 with SMTP id px7mr44022692lab.2.1325665680857; Wed, 04 Jan 2012 00:28:00 -0800 (PST) Received: from a83-245-210-48.elisa-laajakaista.fi (a83-245-210-48.elisa-laajakaista.fi. [83.245.210.48]) by mx.google.com with ESMTPS id is1sm12452321lab.1.2012.01.04.00.27.58 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Jan 2012 00:27:59 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: jouni korhonen In-Reply-To: Date: Wed, 4 Jan 2012 10:27:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9A2E9984-EA8E-41D7-9834-916F73DCF432@gmail.com> To: X-Mailer: Apple Mail (2.1084) Cc: dime@ietf.org Subject: Re: [Dime] On RFC3588bis security.. Stephen Farrell's DISCUSS X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 08:28:03 -0000 Hi, On Jan 3, 2012, at 7:24 PM, = wrote: > OK with the direction of the proposal. > Just too questions for clarification: > - do we keep a priority order between 1/(D)TLS and 2/IPsec as = currently documented in draft or is it also challenged by the Stephen's = comment? Stephen does not challenge the priority order. I would personally have a = slight preference for IPsec as it is already there for other purposes = but I am definitely OK having the current priority order the WG came up = with. > - Is it clear that mandating the possible use of IPsec to secure the = connection does not mandate the peers to support of Diameter by the = peers (e.g. use of IPsec GWs btw peers)? This is a good point to emphasize. One known deployment that will rely = on IPsec is 3GPP Rel-8. For example, GSMA recently put references to NDS = into LTE roaming guideline IR.88 for securing Diameter connections. In addition to Stephen's Section 13 change proposal also Section 2.2 = sentence "If desired, alternative security mechanisms that are = independent of Diameter, such as IPsec [RFC4301], can be deployed to = secure connections between peers." needs to be changed to make it = explicit that the alternative security mechanism is IPsec based. - Jouni >=20 > Regards, >=20 > Lionel=20 >=20 > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de Tina TSOU > Envoy=E9 : lundi 21 novembre 2011 09:49 > =C0 : jouni korhonen; dime@ietf.org > Objet : Re: [Dime] On RFC3588bis security.. Stephen Farrell's DISCUSS >=20 > This solution works for me, though I think TLS is closer to what most = of the vendors currently implement. >=20 >=20 > Best Regards, > Tina TSOU > http://tinatsou.weebly.com/contact.html >=20 > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf = Of jouni korhonen > Sent: Monday, November 21, 2011 12:38 AM > To: dime@ietf.org > Subject: [Dime] On RFC3588bis security.. Stephen Farrell's DISCUSS >=20 > Folks, >=20 > During the meeting we had a discussion on Stephen Farrell's discuss: = https://datatracker.ietf.org/doc/draft-ietf-dime-rfc3588bis/ballot/#stephe= n-farrell >=20 > Glen had a solution proposal that we follow what Stephen suggested = i.e. mandate use of either IPsec or (D)TLS within the spec and leave out = the "some security mechanism". This of course has some impact on product = & deployment level as from now on either IPsec or (D)TLS must be used.. >=20 > Any feedback? >=20 > - Jouni > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From iesg-secretary@ietf.org Wed Jan 4 07:52:34 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD76E21F85CD; Wed, 4 Jan 2012 07:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 DopZya24goDU; Wed, 4 Jan 2012 07:52:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F080E21F85D6; Wed, 4 Jan 2012 07:52:33 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120104155233.30398.17979.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2012 07:52:33 -0800 Cc: dime mailing list , dime chair , RFC Editor Subject: [Dime] Protocol Action: 'Diameter IKEv2 SK: Shared Key-based Support for IKEv2 Server to Diameter Server Interaction' to Proposed Standard (draft-ietf-dime-ikev2-psk-diameter-11.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 15:52:35 -0000 The IESG has approved the following document: - 'Diameter IKEv2 SK: Shared Key-based Support for IKEv2 Server to Diameter Server Interaction' (draft-ietf-dime-ikev2-psk-diameter-11.txt) as a Proposed Standard This document is the product of the Diameter Maintenance and Extensions Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dime-ikev2-psk-diameter/ Technical Summary The Internet Key Exchange protocol version 2 (IKEv2) is a component of the IPsec architecture and is used to perform mutual authentication as well as to establish and to maintain IPsec security associations (SAs) between the respective parties. IKEv2 supports several different authentication mechanisms, such as the Extensible Authentication Protocol (EAP), certificates, and pre-shared keys. Diameter interworking for Mobile IPv6 between the Home Agent, as a Diameter client, and the Diameter server has been specified. However, that specification focused on the usage of EAP and did not include support for pre-shared key based authentication available with IKEv2. This document specifies IKEv2 server, as a Diameter client, to the Diameter server communication for IKEv2 with pre- shared key based authentication. Working Group Summary There is Dime WG consensus behind the document. The document was discussed for more than one year in the WG and the document captures the results of the collaborative WG work. Document Quality The document is complete, straightforward, simple and well-written. Personnel Lionel Morand is the Document Shepherd for this document. Dan Romascanu is the Responsible Area Director. IESG Note Please change all occurances of TBD(x) with the IANA assignment throughout the entire document. Since these are scattered throughout the doc, the intent may not be obvious to them. From glenzorn@gmail.com Thu Jan 5 01:11:24 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 400C121F86B2 for ; Thu, 5 Jan 2012 01:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 FAWwkFGALyDx for ; Thu, 5 Jan 2012 01:11:23 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 483AF21F85E8 for ; Thu, 5 Jan 2012 01:11:23 -0800 (PST) Received: by iabz21 with SMTP id z21so699259iab.31 for ; Thu, 05 Jan 2012 01:11:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=bbmvRHW44DH4qfeCzo5i1OyC4gyRuykvpzejZBCWj04=; b=gyXFo7Q6TpnqThljhgQ0MdRdZyUXPPVyEb1P8Zl8FEMAYUYXzXtDJaJNMrb5fnyr0Z m+qmQmaJO8PkBfnIIEhAEtv3p/isjwQcvMnxlSJx95AsxUxwYwxlR0SDGpJU7xXXKYvh F+FSdZ+h9OWPl/yszP/dObP03n8XdKufgv7Uc= Received: by 10.50.182.199 with SMTP id eg7mr1806237igc.22.1325754682840; Thu, 05 Jan 2012 01:11:22 -0800 (PST) Received: from [192.168.1.98] (ppp-124-122-171-104.revip2.asianet.co.th. [124.122.171.104]) by mx.google.com with ESMTPS id j3sm199286393ibj.1.2012.01.05.01.11.17 (version=SSLv3 cipher=OTHER); Thu, 05 Jan 2012 01:11:20 -0800 (PST) Message-ID: <4F056933.9050907@gmail.com> Date: Thu, 05 Jan 2012 16:11:15 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: jouni korhonen References: <4FCEC779-A1AD-4A21-97B8-8AD1C99472C4@gmail.com> <4EF40D36.70400@gmail.com> <9FB03157-E7EE-4C3C-82E4-E699700BE200@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "lionel.morand@orange-ftgroup.com> Morand" , dime@ietf.org Subject: Re: [Dime] re-chartering X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 09:11:24 -0000 On 1/2/2012 5:40 PM, jouni korhonen wrote: > Just to make a clean post to the list. The below is the revision submitted for the next IESG meeting regarding DIME rechartering. > > - Jouni > > > ----------------- > > Diameter Maintenance and Extensions (dime) > ----------------------------------------- > > Current Status: Active > > Last Modified: 2011-12-27 > > Chairs: > Lionel Morand > Jouni Korhonen > > Operations and Management Area Directors: > Dan Romascanu > Ronald Bonica > > Operations and Management Area Advisor: > Dan Romascanu > > Mailing Lists: > General Discussion: dime@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/dime > Archive: http://www.ietf.org/mail-archive/web/dime/current/maillist.html > > > Description of Working Group: > > The Diameter Maintenance and Extensions WG will focus on maintenance > and extensions to the Diameter protocol required to enable its use for > authentication, authorization, accounting, charging in network access, > provisioning of configuration information within the network, and for > new session management uses within the extensibility rules of the > Diameter base protocol. > > The DIME working group plans to address the following items: > > - Maintaining and/or progressing, along the standards track, the > Diameter Base protocol and Diameter Applications. This includes > extensions to Diameter Base protocol that can be considered as enhanced > features or bug fixes. > > - Diameter application design guideline. s/guideline/guidelines > This document will provide > guidelines for design of Diameter extensions. It will detail when to > consider reusing an existing application and when to develop a new > application. About a month ago there was a brief thread about this draft, in part containing a promise from one of the authors to "initiate a mail with at least the points that I would like to see clarified with this document. And we can use it to set-up after that a confcall. Is it OK?". Apparently this _was_ OK, but a month has passed and nothing has happened. In addition, it has now been nine months since anybody considered this draft important enough to change the rev number and resubmit it w/o any other changes (a 2 minute task at worst). Since there is clearly zero interest in this work, why is it still in the charter? > > - Protocol extensions for the management of Diameter entities. This work > focuses on the standardization of Management Information Bases (MIBs) > to configure Diameter entities (such as the Diameter Base protocol or > Diameter Credit Control nodes). The usage of other management protocols > for configuring Diameter entities may be future work within the group. > > - Protocol extension for bulk and group session management. The aim of > this work is to study and standardize a solution for handling groups of > sessions within the Diameter base protocol context. The solution would > define how to identify and handle grouped sessions in commands and > operations. > > Additionally, Diameter-based systems require interoperability in order > to work. The working group, along with the AD, will need to evaluate > any potential extensions and require verification that the proposed > extension is needed. Coordination with other IETF working groups and > other SDOs will be used to ensure this. > > > Goals and Milestones: > Done - Submit the following two Diameter Mobility documents to the IESG for consideration as a Proposed Standards:* 'Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction' * 'Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction' > Done - Submit 'Diameter API' to the IESG for consideration as an Informational RFC > Done - Submit 'Quality of Service Parameters for Usage with Diameter' to the IESG for consideration as a Proposed Standard. > Done - Submit 'Diameter QoS Application' to the IESG for consideration as a Proposed Standard > Done - Submit 'Diameter Support for EAP Re-authentication Protocol' as DIME working group item > Done - Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' as DIME working group item > Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working group item > Done - Submit 'Quality of Service Attributes for Diameter' to the IESG for consideration as a Proposed Standard > Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for consideration as a Proposed Standard > Done - Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' to the IESG for consideration as a Proposed Standard > Done - Submit 'Diameter NAT Control Application' as DIME working group item > Done - Submit 'Diameter Capabilities Update' as DIME working group item > Done - Submit 'Diameter Credit Control Application MIB' to the IESG for consideration as an Informational RFC > Done - Submit 'Diameter Base Protocol MIB' to the IESG for consideration as an Informational RFC > Done - Submit 'Diameter Capabilities Update' to the IESG for consideration as a Proposed Standard > Done - Submit 'Diameter Extended NAPTR' as DIME working group item > Done - Submit 'Realm-Based Redirection In Diameter' as DIME working group item > Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized Routing' as DIME working group item > Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic Key Transport' as DIME working group item > Done - Submit 'Diameter Priority Attribute Value Pairs' as DIME working group item > Done - Submit 'Diameter IKEv2 PSK' as DIME working group item > Done - Submit Revision of 'Diameter Base Protocol' to the IESG for consideration as a Proposed Standard > Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic Key Transport' to the IESG for consideration as a Proposed Standard > Done - Submit 'Diameter Priority Attribute Value Pairs' to the IESG for consideration as a Proposed Standard > Done - Submit Revision of 'Diameter Network Access Server Application - RFC 4005bis' as DIME working group item > Done - Submit 'Diameter NAT Control Application' to the IESG for consideration as a Proposed Standard > Done - Submit 'Diameter IKEv2 PSK' to the IESG for consideration as a Proposed Standard > Done - Submit 'Diameter Extended NAPTR' to the IESG for consideration as a Proposed Standard > Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized Routing' to the IESG for consideration as a Proposed > Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the IESG for consideration as a Proposed Standard > Mar 2012 - Submit Revision of 'Diameter Network Access Server Application - RFC 4005bis' to the IESG for consideration as a Proposed Standard > May 2012 - Submit 'Diameter Application Design Guidelines' to the IESG for consideration as a BCP document Standard > Jul 2012 - Submit 'Diameter Support for EAP Re-authentication Protocol' to the IESG for consideration as a Proposed Standard > Aug 2012 - Submit a document on 'Protocol extension for bulk and group signaling' as a working group item > Aug 2013 - Submit a document on 'Protocol extension for bulk and group signaling' to the IESG for consideration as a Proposed Standard > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From dromasca@avaya.com Thu Jan 5 01:39:20 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE4821F86E3 for ; Thu, 5 Jan 2012 01:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.338 X-Spam-Level: X-Spam-Status: No, score=-103.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 Az+C45X1SnKa for ; Thu, 5 Jan 2012 01:39:19 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 40BAD21F8688 for ; Thu, 5 Jan 2012 01:39:19 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANNuBU/GmAcF/2dsb2JhbABDrHuBBYFyAQEBAQMSHgo/DAQCAQgNCA0GDAsBBgFFEQEBBAESCBqheZsUiy5jBJp1jEc X-IronPort-AV: E=Sophos;i="4.71,461,1320642000"; d="scan'208";a="322846442" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 05 Jan 2012 04:39:17 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 05 Jan 2012 04:35:15 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Jan 2012 10:39:14 +0100 Message-ID: In-Reply-To: <4F056933.9050907@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] re-chartering Thread-Index: AczLihBrNoJ7/O9LQl2qWWpxAGa8nQAAu5sQ References: <4FCEC779-A1AD-4A21-97B8-8AD1C99472C4@gmail.com><4EF40D36.70400@gmail.com><9FB03157-E7EE-4C3C-82E4-E699700BE200@gmail.com> <4F056933.9050907@gmail.com> From: "Romascanu, Dan (Dan)" To: "Glen Zorn" , "jouni korhonen" Cc: lionel.morand@orange-ftgroup.com, dime@ietf.org Subject: Re: [Dime] re-chartering X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 09:39:20 -0000 > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > Glen Zorn > > > > - Diameter application design guideline. >=20 > s/guideline/guidelines >=20 > > This document will provide > > guidelines for design of Diameter extensions. It will detail when > to > > consider reusing an existing application and when to develop a new > > application. >=20 > About a month ago there was a brief thread about this draft, in part > containing a promise from one of the authors to "initiate a mail with > at > least the points that I would like to see clarified with this document. > And we can use it to set-up after that a confcall. Is it OK?". > Apparently this _was_ OK, but a month has passed and nothing has > happened. In addition, it has now been nine months since anybody > considered this draft important enough to change the rev number and > resubmit it w/o any other changes (a 2 minute task at worst). Since > there is clearly zero interest in this work, why is it still in the > charter? >=20 [[DR]] I believe that this work is needed for people out of the IETF (other SDOs, vendors) or people in the IETF with less experience in Diameter design extensions. Do we care how these extensions are designed? I believe the answer is yes or should be yes in this WG. Also, in the OPS area SNMP (SMI), YANG, RADIUS have each similar documents which provide guidelines for those who design extensions and data models.=20 Dan From avi@amdocs.com Thu Jan 5 06:51:56 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E62B21F87F6 for ; Thu, 5 Jan 2012 06:51:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 q56DjPQtKbz7 for ; Thu, 5 Jan 2012 06:51:54 -0800 (PST) Received: from stlint3.amdocs.com (stlint3.amdocs.com [69.150.27.49]) by ietfa.amsl.com (Postfix) with ESMTP id CE66421F87B5 for ; Thu, 5 Jan 2012 06:51:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by stlint3.amdocs.com (Postfix) with SMTP id 8262CD01B8; Thu, 5 Jan 2012 08:51:53 -0600 (CST) Received: from USSTLMAILFE2.corp.amdocs.com (unknown [10.26.48.179]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by stlint3.amdocs.com (Postfix) with ESMTPS id 533C1D01B8; Thu, 5 Jan 2012 08:51:47 -0600 (CST) Received: from USSTLDAGFE3.corp.amdocs.com (10.26.49.38) by USSTLMAILFE2.corp.amdocs.com (10.26.48.179) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 5 Jan 2012 08:51:47 -0600 Received: from USSTLDAGBE2.corp.amdocs.com ([fe80::f917:3c49:9698:e24a]) by USSTLDAGFE3.corp.amdocs.com ([fe80::48a1:c495:2ce:f697%10]) with mapi id 14.01.0355.002; Thu, 5 Jan 2012 08:51:47 -0600 From: Avi Lior To: jouni korhonen , "lionel.morand@orange.com" Thread-Topic: [Dime] On RFC3588bis security.. Stephen Farrell's DISCUSS Thread-Index: AQHMqCj2+wJ4gdqW806UlxHEKgNa9ZW3A/QggEQhb/CAAWRmgIABqcIA Date: Thu, 5 Jan 2012 14:51:45 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.25.27.94] Content-Type: text/plain; charset="Windows-1252" Content-ID: <55EC68CFA0E2E7449FA62E5005952F48@amdocs.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 05 Jan 2012 08:09:42 -0800 Cc: "dime@ietf.org" Subject: Re: [Dime] On RFC3588bis security.. Stephen Farrell's DISCUSS X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 15:59:31 -0000 Hi On 12-01-04 3:27 , "jouni korhonen" wrote: >This is a good point to emphasize. One known deployment that will rely o= n >IPsec is 3GPP Rel-8. For example, GSMA recently put references to NDS >into LTE roaming guideline IR.88 for securing Diameter connections. > >In addition to Stephen's Section 13 change proposal also Section 2.2 >sentence "If desired, alternative security mechanisms that are >independent of Diameter, such as IPsec [RFC4301], can be deployed to >secure connections between peers." needs to be changed to make it >explicit that the alternative security mechanism is IPsec based. I agree with this sort of. Alternative security mechanism is IPSec based really should be: as good as or better then the mechanisms provided by Ipsec/DTLS/TLS etc=8A This will allow some future proofing in the case where we have better schemes. But also why Ipsec? > This message and the information contained herein is proprietary and conf= idential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp From avi@amdocs.com Thu Jan 5 06:48:05 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A54F21F85CD for ; Thu, 5 Jan 2012 06:48:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 iZ7UEiclf4Nd for ; Thu, 5 Jan 2012 06:48:04 -0800 (PST) Received: from stlint3.amdocs.com (stlint3.amdocs.com [69.150.27.49]) by ietfa.amsl.com (Postfix) with ESMTP id A7E8D21F85C4 for ; Thu, 5 Jan 2012 06:48:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by stlint3.amdocs.com (Postfix) with SMTP id 628B0D01DA; Thu, 5 Jan 2012 08:48:01 -0600 (CST) Received: from USSTLMAILFE1.corp.amdocs.com (unknown [10.26.48.178]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by stlint3.amdocs.com (Postfix) with ESMTPS id 22975D01DA; Thu, 5 Jan 2012 08:47:55 -0600 (CST) Received: from USSTLDAGFE3.corp.amdocs.com (10.26.49.38) by USSTLMAILFE1.corp.amdocs.com (10.26.48.178) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 5 Jan 2012 08:47:54 -0600 Received: from USSTLDAGBE2.corp.amdocs.com ([fe80::f917:3c49:9698:e24a]) by USSTLDAGFE3.corp.amdocs.com ([fe80::48a1:c495:2ce:f697%10]) with mapi id 14.01.0355.002; Thu, 5 Jan 2012 08:47:54 -0600 From: Avi Lior To: "lionel.morand@orange.com" , "Tina.Tsou.Zouting@huawei.com" , "jouni.nospam@gmail.com" , "dime@ietf.org" Thread-Topic: [Dime] On RFC3588bis security.. Stephen Farrell's DISCUSS Thread-Index: AQHMqCj2+wJ4gdqW806UlxHEKgNa9ZW3A/QggEQhb/CAAEQFAP//8mNAgALWqoA= Date: Thu, 5 Jan 2012 14:47:54 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.25.27.94] Content-Type: text/plain; charset="Windows-1252" Content-ID: <42ACE5AC2809194297EAF20D6508EE87@amdocs.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 05 Jan 2012 08:09:42 -0800 Subject: Re: [Dime] On RFC3588bis security.. Stephen Farrell's DISCUSS X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 15:59:39 -0000 On 12-01-03 15:32 , "lionel.morand@orange.com" wrote: >Within 3GPP, the NDS relies on the use of IPsec GWs to secure IP >connections between nodes. And I was actually referring to that point in >my mail. Yes indeed. The point I am trying to make is that Ipsec is outside the scope of the Diameter Implementation. We have to be clear about that. The Diameter box/blade does not have to implement any security mechanisms but it has to operate within a secure environment that provides the same or better security as Ipsec/DTLS/TLS etc=8A. > This message and the information contained herein is proprietary and conf= idential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp From glenzorn@gmail.com Fri Jan 6 00:24:12 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8635321F8493 for ; Fri, 6 Jan 2012 00:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 zO4+DcH5lOpU for ; Fri, 6 Jan 2012 00:24:12 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id E5D7A21F848F for ; Fri, 6 Jan 2012 00:24:11 -0800 (PST) Received: by qcsf15 with SMTP id f15so886583qcs.31 for ; Fri, 06 Jan 2012 00:24:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=U8MR3aqsB1cWUBiEyTe92Ehc+/WGqY1P0dLWQpLHFOg=; b=Lg3dgcZrk1CGcznG2IwuRdgAhuCyVgKn3eIyalor1owsCxXtlf8x0dqoXVk9t1jPa6 SoJSHFKxrH32HYw/Sb0g+AGJBanz+7zMrTqd+vrBkADfs+vJs3IDRrj1r6JGfznV5neo 18xGAfby18WSgLg53t9F3r9hpBgm9lYoEA670= Received: by 10.229.78.82 with SMTP id j18mr1845724qck.62.1325838251405; Fri, 06 Jan 2012 00:24:11 -0800 (PST) Received: from [192.168.1.98] (ppp-110-168-89-95.revip5.asianet.co.th. [110.168.89.95]) by mx.google.com with ESMTPS id m20sm120910494qaj.14.2012.01.06.00.24.07 (version=SSLv3 cipher=OTHER); Fri, 06 Jan 2012 00:24:10 -0800 (PST) Message-ID: <4F06AFA5.7050209@gmail.com> Date: Fri, 06 Jan 2012 15:24:05 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4FCEC779-A1AD-4A21-97B8-8AD1C99472C4@gmail.com><4EF40D36.70400@gmail.com><9FB03157-E7EE-4C3C-82E4-E699700BE200@gmail.com> <4F056933.9050907@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: lionel.morand@orange-ftgroup.com, dime@ietf.org Subject: Re: [Dime] re-chartering X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 08:24:12 -0000 On 1/5/2012 4:39 PM, Romascanu, Dan (Dan) wrote: ... >>> - Diameter application design guideline. >> >> s/guideline/guidelines >> >>> This document will provide >>> guidelines for design of Diameter extensions. It will detail when >> to >>> consider reusing an existing application and when to develop a new >>> application. >> >> About a month ago there was a brief thread about this draft, in part >> containing a promise from one of the authors to "initiate a mail with >> at >> least the points that I would like to see clarified with this > document. >> And we can use it to set-up after that a confcall. Is it OK?". >> Apparently this _was_ OK, but a month has passed and nothing has >> happened. In addition, it has now been nine months since anybody >> considered this draft important enough to change the rev number and >> resubmit it w/o any other changes (a 2 minute task at worst). Since >> there is clearly zero interest in this work, why is it still in the >> charter? >> > > [[DR]] I believe that this work is needed for people out of the IETF > (other SDOs, vendors) Other SDOs have made it painfully clear that they will do precisely as they like with Diameter, regardless of any input from the IETF. How is the existence of this document going to change that? > or people in the IETF with less experience in > Diameter design extensions. Do we care how these extensions are > designed? I believe the answer is yes or should be yes in this WG. Also, > in the OPS area SNMP (SMI), YANG, RADIUS have each similar documents > which provide guidelines for those who design extensions and data > models. I will not presume to comment upon the others, but the RADIUS "guidelines" are an abomination, the major purpose of which seems to be to cripple RADIUS implementers while protecting a single vendor's extremely limited view of how things should be done > > Dan > From jouni.nospam@gmail.com Fri Jan 6 00:28:10 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B1821F88A7 for ; Fri, 6 Jan 2012 00:28:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 NECoplQzkIZu for ; Fri, 6 Jan 2012 00:28:09 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 61CB221F88AD for ; Fri, 6 Jan 2012 00:28:09 -0800 (PST) Received: by laah2 with SMTP id h2so485179laa.31 for ; Fri, 06 Jan 2012 00:28:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=low18TXafQb3YdRLKFOGft+oVniDENaMmIcqyoL32gE=; b=BJAx/vd6XihqM3yVuv7o9ppPhmof4Oy1pRzZzDSJ4m8UhAgRl24Wro1uRs5Fz7hcbr LVSMQOz3LTJYu9qrNESR/ND2UtovOLj8lTp5X49Xz+hC89C0nJKAiXgBy/FwnUrkRL6p yCw9yA/XiJ06qXSAFEy9rL/tC1JHjQxvKC1u8= Received: by 10.152.146.42 with SMTP id sz10mr1960125lab.33.1325838487087; Fri, 06 Jan 2012 00:28:07 -0800 (PST) Received: from a88-112-207-191.elisa-laajakaista.fi (a88-112-207-191.elisa-laajakaista.fi. [88.112.207.191]) by mx.google.com with ESMTPS id pg16sm4082319lab.9.2012.01.06.00.28.05 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 Jan 2012 00:28:06 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4F06AFA5.7050209@gmail.com> Date: Fri, 6 Jan 2012 10:28:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <16305DEE-A8DF-430A-82FD-5BA12A96D0F0@gmail.com> References: <4FCEC779-A1AD-4A21-97B8-8AD1C99472C4@gmail.com><4EF40D36.70400@gmail.com><9FB03157-E7EE-4C3C-82E4-E699700BE200@gmail.com> <4F056933.9050907@gmail.com> <4F06AFA5.7050209@gmail.com> To: Glen Zorn X-Mailer: Apple Mail (2.1084) Cc: lionel.morand@orange-ftgroup.com, dime@ietf.org Subject: Re: [Dime] re-chartering X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 08:28:10 -0000 Glen,=20 On Jan 6, 2012, at 10:24 AM, Glen Zorn wrote: >> [[DR]] I believe that this work is needed for people out of the IETF >> (other SDOs, vendors)=20 >=20 > Other SDOs have made it painfully clear that they will do precisely as > they like with Diameter, regardless of any input from the IETF. How = is > the existence of this document going to change that? And a lot of this originates from their "own interpretations" of = RFC3588. Every measure to fix this is for common good.. I hope :) But I = sort of agree the train left in some cases. - Jouni >> or people in the IETF with less experience in >> Diameter design extensions. Do we care how these extensions are >> designed? I believe the answer is yes or should be yes in this WG. = Also, >> in the OPS area SNMP (SMI), YANG, RADIUS have each similar documents >> which provide guidelines for those who design extensions and data >> models.=20 >=20 > I will not presume to comment upon the others, but the RADIUS > "guidelines" are an abomination, the major purpose of which seems to = be > to cripple RADIUS implementers while protecting a single vendor's > extremely limited view of how things should be done >=20 >>=20 >> Dan >>=20 >=20 From glenzorn@gmail.com Fri Jan 6 23:18:12 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7B311E8079 for ; Fri, 6 Jan 2012 23:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 XijuqYIlOOPi for ; Fri, 6 Jan 2012 23:18:11 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id C5BD211E8072 for ; Fri, 6 Jan 2012 23:18:08 -0800 (PST) Received: by qadz3 with SMTP id z3so1348526qad.10 for ; Fri, 06 Jan 2012 23:18:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=omFO92fMvdaw3Q5tUU+sFE1IvbjBoAhk5J0jWXmG4uM=; b=pJCH+KFo0FV72MuOBMXAG4VUMWQmqjteD4S4hb7itLYR/qTIzl9AzwnPx9Dbqi10Yw ent/kF2mwQscDHtBgsK/vefljuNnw/9CJGj0ZUol9z2ncnkzbl9fpHz9ID+0zO8uUMlv tFy0nBjcgmAcBv9Zie0LSM7P+3QCwsRNfxz3g= Received: by 10.224.177.5 with SMTP id bg5mr11041223qab.87.1325920687285; Fri, 06 Jan 2012 23:18:07 -0800 (PST) Received: from [192.168.1.98] (ppp-58-11-255-151.revip2.asianet.co.th. [58.11.255.151]) by mx.google.com with ESMTPS id dk2sm58904778qab.12.2012.01.06.23.18.03 (version=SSLv3 cipher=OTHER); Fri, 06 Jan 2012 23:18:05 -0800 (PST) Message-ID: <4F07F1A7.7050508@gmail.com> Date: Sat, 07 Jan 2012 14:17:59 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: jouni korhonen References: <4FCEC779-A1AD-4A21-97B8-8AD1C99472C4@gmail.com><4EF40D36.70400@gmail.com><9FB03157-E7EE-4C3C-82E4-E699700BE200@gmail.com> <4F056933.9050907@gmail.com> <4F06AFA5.7050209@gmail.com> <16305DEE-A8DF-430A-82FD-5BA12A96D0F0@gmail.com> In-Reply-To: <16305DEE-A8DF-430A-82FD-5BA12A96D0F0@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: lionel.morand@orange-ftgroup.com, dime@ietf.org Subject: Re: [Dime] re-chartering X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 07:18:12 -0000 On 1/6/2012 3:28 PM, jouni korhonen wrote: > Glen, > > On Jan 6, 2012, at 10:24 AM, Glen Zorn wrote: > > >>> [[DR]] I believe that this work is needed for people out of the IETF >>> (other SDOs, vendors) >> >> Other SDOs have made it painfully clear that they will do precisely as >> they like with Diameter, regardless of any input from the IETF. How is >> the existence of this document going to change that? > > And a lot of this originates from their "own interpretations" of RFC3588. OK, I'll bite: which part of 3588 can be interpreted to say that Diameter is a general-purpose signaling protocol? Every measure to fix this is for common good.. How can any amount of "guidance" fix willful misuse? I hope :) But I sort of agree the train left in some cases. > > - Jouni > > > > >>> or people in the IETF with less experience in >>> Diameter design extensions. Do we care how these extensions are >>> designed? I believe the answer is yes or should be yes in this WG. Also, >>> in the OPS area SNMP (SMI), YANG, RADIUS have each similar documents >>> which provide guidelines for those who design extensions and data >>> models. >> >> I will not presume to comment upon the others, but the RADIUS >> "guidelines" are an abomination, the major purpose of which seems to be >> to cripple RADIUS implementers while protecting a single vendor's >> extremely limited view of how things should be done >> >>> >>> Dan >>> >> > From tom.taylor.stds@gmail.com Sun Jan 8 12:20:10 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0DA121F85F2 for ; Sun, 8 Jan 2012 12:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 CGDN+WlB+utP for ; Sun, 8 Jan 2012 12:20:09 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2203E21F85FA for ; Sun, 8 Jan 2012 12:20:09 -0800 (PST) Received: by yenl8 with SMTP id l8so850420yen.31 for ; Sun, 08 Jan 2012 12:20:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=+KW6Nqm9Zs5lvPMCa20XVo7e4FFCbh9XVu1R9tIIcRw=; b=eTeMPjnK0cSaeqAdvMB7CaNt9vYyrMjTPjtlG23t7+xfsk5oZM4aGvQ2isbl+8v1G1 ZXD7cKeEGO8xTO12xXIOL/fSU8kOfKATG3PSQ7p6Iuqs+UWzRGKJkl/eqQg0x2dC6YDI vI3/W/uYx5IXqv9bVbU85KTm0xc8Di2w/x0ec= Received: by 10.236.78.228 with SMTP id g64mr17123051yhe.81.1326054008615; Sun, 08 Jan 2012 12:20:08 -0800 (PST) Received: from [192.168.2.17] ([64.228.211.26]) by mx.google.com with ESMTPS id b36sm62345216yhj.22.2012.01.08.12.20.07 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 Jan 2012 12:20:08 -0800 (PST) Message-ID: <4F09FA77.5020301@gmail.com> Date: Sun, 08 Jan 2012 15:20:07 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Dime] Would realm-based redirection be a protocol error or an application error? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2012 20:20:10 -0000 I'm finally updating draft-ietf-dime-realm-based-redirect. Given that realm-based redirection is defined at an application level, maybe the answer is obvious. What I am concerned with is whether the redirect server should clear the 'R' bit in the header to ensure that the response goes all the way back to the original requesting host (i.e., following on Figure 8 in section 7 of RFC 3588). The reason for doing this is the issue identified in the Security Considerations section of the realm-based-redirection I-D: a change of realm implies a change of business relationship that should be noted by the requesting host before the request is rerouted. Tom Taylor From glenzorn@gmail.com Sun Jan 8 23:00:49 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DFB621F864A for ; Sun, 8 Jan 2012 23:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 gbZ2nFs0W56L for ; Sun, 8 Jan 2012 23:00:48 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id AB3A821F8476 for ; Sun, 8 Jan 2012 23:00:48 -0800 (PST) Received: by qcsf15 with SMTP id f15so2178863qcs.31 for ; Sun, 08 Jan 2012 23:00:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=KzdV48q1v31oaDYO9u224BR5Pbwxb+5CYrVqMIB29P8=; b=NCTq+PKzr8V5R5EysGgiwFObYw7xdiX0HkPPGY8Tyrc7Rmb7PNEXRdcvJtZbE3+FyU LNcgoyFySV85AOd6E74ajmxifDE4M092yx6NKB8H7TD4F8XduAyfmZhTDl/G9aAqpwAq ClqaaZg8RkOmYipUvYF1YCm1hBi8+KOmFjTUo= Received: by 10.224.177.203 with SMTP id bj11mr17463491qab.37.1326092448095; Sun, 08 Jan 2012 23:00:48 -0800 (PST) Received: from [192.168.1.98] (ppp-110-168-72-2.revip5.asianet.co.th. [110.168.72.2]) by mx.google.com with ESMTPS id dx7sm121970958qab.3.2012.01.08.23.00.45 (version=SSLv3 cipher=OTHER); Sun, 08 Jan 2012 23:00:46 -0800 (PST) Message-ID: <4F0A909A.2030705@gmail.com> Date: Mon, 09 Jan 2012 14:00:42 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Tom Taylor References: <4F09FA77.5020301@gmail.com> In-Reply-To: <4F09FA77.5020301@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dime@ietf.org" Subject: Re: [Dime] Would realm-based redirection be a protocol error or an application error? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 07:00:49 -0000 On 1/9/2012 3:20 AM, Tom Taylor wrote: > I'm finally updating draft-ietf-dime-realm-based-redirect. > > Given that realm-based redirection is defined at an application level, > maybe the answer is obvious. Section 7 of RFC 3588 says There are two different types of errors in Diameter; protocol and application errors. A protocol error is one that occurs at the base protocol level, and MAY require per hop attention (e.g., message routing error). Application errors, on the other hand, generally occur due to a problem with a function specified in a Diameter application (e.g., user authentication, Missing AVP). > What I am concerned with is whether the > redirect server should clear the 'R' bit in the header to ensure that > the response goes all the way back to the original requesting host > (i.e., following on Figure 8 in section 7 of RFC 3588). I don't understand: as I understand it, the 'R' bit has nothing to do with error type; if it is cleared that just signifies that the message is an answer, rather than a request (which would presumably be true of any error response). > The reason for > doing this is the issue identified in the Security Considerations > section of the realm-based-redirection I-D: a change of realm implies a > change of business relationship I think that this is not necessarily true. For example, consider a large ISP with international operations; such an entity might have multiple Diameter realms (europe.bigisp.com, asia.bigisp.com, etc.), no? > that should be noted by the requesting > host before the request is rerouted. > > Tom Taylor > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Mon Jan 9 03:19:25 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4CB621F8471 for ; Mon, 9 Jan 2012 03:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Sf-lieSHVRtc for ; Mon, 9 Jan 2012 03:19:25 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C6CE621F846E for ; Mon, 9 Jan 2012 03:19:24 -0800 (PST) Received: by laah2 with SMTP id h2so1546762laa.31 for ; Mon, 09 Jan 2012 03:19:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=PeHntTdXJEm3K4KEK+s9w3XjEDyaUbSoUGk+Gddc0+k=; b=R5Xcdx9bTUE6XQe0zjS6kQAaJWyGzNuURUXC9xcKPkxbwW2qmwPpgnLiOH5zBFDJGp OORlaXWizI+QGt7tPxjMsQaAZLCnjEdopukM39twuPxocRbIJUb8dqFiUkncS/tGd7fO 7WNk5fIE3tbsuuAT6VyOCoJoToD8elWmJOzw8= Received: by 10.112.100.34 with SMTP id ev2mr3385513lbb.13.1326107963815; Mon, 09 Jan 2012 03:19:23 -0800 (PST) Received: from a88-112-207-191.elisa-laajakaista.fi (a88-112-207-191.elisa-laajakaista.fi. [88.112.207.191]) by mx.google.com with ESMTPS id lr15sm4030582lab.13.2012.01.09.03.19.20 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 Jan 2012 03:19:21 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4F07F1A7.7050508@gmail.com> Date: Mon, 9 Jan 2012 13:19:19 +0200 Content-Transfer-Encoding: 7bit Message-Id: <2452DC32-1E83-4AD4-BF8D-EB72E3E3C9D2@gmail.com> References: <4FCEC779-A1AD-4A21-97B8-8AD1C99472C4@gmail.com><4EF40D36.70400@gmail.com><9FB03157-E7EE-4C3C-82E4-E699700BE200@gmail.com> <4F056933.9050907@gmail.com> <4F06AFA5.7050209@gmail.com> <16305DEE-A8DF-430A-82FD-5BA12A96D0F0@gmail.com> <4F07F1A7.7050508@gmail.com> To: Glen Zorn X-Mailer: Apple Mail (2.1084) Cc: lionel.morand@orange-ftgroup.com, dime@ietf.org Subject: Re: [Dime] re-chartering X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 11:19:25 -0000 Glen, On Jan 7, 2012, at 9:17 AM, Glen Zorn wrote: > On 1/6/2012 3:28 PM, jouni korhonen wrote: > >> Glen, >> >> On Jan 6, 2012, at 10:24 AM, Glen Zorn wrote: >> >> >>>> [[DR]] I believe that this work is needed for people out of the IETF >>>> (other SDOs, vendors) >>> >>> Other SDOs have made it painfully clear that they will do precisely as >>> they like with Diameter, regardless of any input from the IETF. How is >>> the existence of this document going to change that? >> >> And a lot of this originates from their "own interpretations" of RFC3588. > > OK, I'll bite: which part of 3588 can be interpreted to say that > Diameter is a general-purpose signaling protocol? It does not either specifically prohibit that and also gives excellent tools for such usage. One can easily create a new command that has no concept of session, does not maintain any auth-session state etc. > Every measure to fix this is for common good.. > > How can any amount of "guidance" fix willful misuse? My sincere hope is that education could fix stuff and new breed of developers could do things better ;) Might be wishful thinking though. - Jouni > I hope :) But I sort of agree the train left in some cases. >> >> - Jouni >> >> >> >> >>>> or people in the IETF with less experience in >>>> Diameter design extensions. Do we care how these extensions are >>>> designed? I believe the answer is yes or should be yes in this WG. Also, >>>> in the OPS area SNMP (SMI), YANG, RADIUS have each similar documents >>>> which provide guidelines for those who design extensions and data >>>> models. >>> >>> I will not presume to comment upon the others, but the RADIUS >>> "guidelines" are an abomination, the major purpose of which seems to be >>> to cripple RADIUS implementers while protecting a single vendor's >>> extremely limited view of how things should be done >>> >>>> >>>> Dan >>>> >>> >> > From dromasca@avaya.com Mon Jan 9 05:25:46 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9696021F875D for ; Mon, 9 Jan 2012 05:25:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.287 X-Spam-Level: X-Spam-Status: No, score=-103.287 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 msMtuDGo32-P for ; Mon, 9 Jan 2012 05:25:46 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id A902021F8750 for ; Mon, 9 Jan 2012 05:25:40 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAJ7pCk+HCzI1/2dsb2JhbABErFGBBYFyAQEBAQIBEh4KRA0BFRUDAwwMB1cBBBsah1iWPIQXmzWId4I3YwSaeoxJ X-IronPort-AV: E=Sophos;i="4.71,480,1320642000"; d="scan'208";a="285327826" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 09 Jan 2012 08:25:37 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 09 Jan 2012 08:11:19 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Jan 2012 14:24:25 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-dime-pmip6-lr-06 Thread-Index: AczO0gGdLM3R5+FyRKCPyqt2CF+4/A== From: "Romascanu, Dan (Dan)" To: Subject: [Dime] AD review of draft-ietf-dime-pmip6-lr-06 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 13:25:46 -0000 This is the AD review of draft-ietf-dime-pmip6-lr-06. In general the document is in good share. I have a few comments listed below, but these do not prevent sending the document to IETF Last Call. Please consider the comments together with the other comments that you may receive during the last call.=20 The Comments are divided in T-Technical and E-Editorial T1. Section 3.1: > The MIP6-Agent-Info grouped AVP (AVP Code 486) is defined in [RFC5779]. This AVP is used to carry LMA addressing in AAA response. Actually the MIP6-Agent-Info grouped AVP is defined in [RFC5447] and extended in [RFC5779]. T2. In Section 3.4:=20 > The LMA SHOULD support this policy feature on a per-MN and per-subscription basis. First, this is the only usage of a capitalized keyword, and it treggers an id-nits error because there is no 2119 boilerplate and reference. You need to decide whether to take it out, or leave it but in this case add the boilerplate and referance to [RFC2119] Second, is this really a SHOULD? When would the LMA not support this feature?=20 E1. Section 3.4: > This document defines new capability flag bits according to the IANA rules in RFC 5447. s/new capability flag bits/one new capability flag bit/ E2. Also in Section 3.4: s/it indicate that both MN and CN/it indicates that both MN and CN/ E3. Section 4.2:=20 > In the case where MNs belong to the different LMAs, MAG1 or LMA1 should has already known the recipient of localized routing is LMA2. This sentence is broken, needs to be fixed. E4. In the IANA Considerations section it would be useful to add that the new value in the Mobility Capability registry corresponds to the new capability flag bit defined in section 3.4 E5. Add a note to the Change Log section to be taken out at publication. From tom.taylor.stds@gmail.com Mon Jan 9 15:57:00 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82BD1F0C3D for ; Mon, 9 Jan 2012 15:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 mCNU+d78lraw for ; Mon, 9 Jan 2012 15:57:00 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 114C01F0C36 for ; Mon, 9 Jan 2012 15:57:00 -0800 (PST) Received: by obcuz6 with SMTP id uz6so5361344obc.31 for ; Mon, 09 Jan 2012 15:56:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=mlOdFoTpONLl1s57AvFwdw4dG+RGRiq0tri/RnGtcvE=; b=OamllyNa+osw0GMRc1pUxU0hmTCjfrHTy6VvsgezXRqNJPHqCsWq1+O5qzZnDQI5ow jkxLEUpB3lvU6GjwFJGhnE8iVP2RRzDJLDboHXQB+AT9MlgnM7Ufd/VnNhW54MA+wyPg uf02y8vzJat2W4SslzAIb0SuM59jzf1avvuD8= Received: by 10.182.113.3 with SMTP id iu3mr16888297obb.78.1326153419708; Mon, 09 Jan 2012 15:56:59 -0800 (PST) Received: from [192.168.2.17] ([64.228.211.26]) by mx.google.com with ESMTPS id y6sm78919112obs.0.2012.01.09.15.56.58 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 Jan 2012 15:56:59 -0800 (PST) Message-ID: <4F0B7ECB.5040006@gmail.com> Date: Mon, 09 Jan 2012 18:56:59 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Glen Zorn References: <4F09FA77.5020301@gmail.com> <4F0A909A.2030705@gmail.com> In-Reply-To: <4F0A909A.2030705@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dime@ietf.org" Subject: Re: [Dime] Would realm-based redirection be a protocol error or an application error? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 23:57:01 -0000 See below. On 09/01/2012 2:00 AM, Glen Zorn wrote: > On 1/9/2012 3:20 AM, Tom Taylor wrote: > >> I'm finally updating draft-ietf-dime-realm-based-redirect. >> >> Given that realm-based redirection is defined at an application level, >> maybe the answer is obvious. > > Section 7 of RFC 3588 says > > There are two different types of errors in Diameter; protocol and > application errors. A protocol error is one that occurs at the base > protocol level, and MAY require per hop attention (e.g., message > routing error). Application errors, on the other hand, generally > occur due to a problem with a function specified in a Diameter > application (e.g., user authentication, Missing AVP). > >> What I am concerned with is whether the >> redirect server should clear the 'R' bit in the header to ensure that >> the response goes all the way back to the original requesting host >> (i.e., following on Figure 8 in section 7 of RFC 3588). > > I don't understand: as I understand it, the 'R' bit has nothing to do > with error type; if it is cleared that just signifies that the message > is an answer, rather than a request (which would presumably be true of > any error response). [PTT] I don't think so. Section 7 makes a clear distinction between the routing for protocol error responses and application error responses (Figures 7 and 8 rtespectively) and ascribes the difference to the setting of the 'R' bit (text following Figure 8). > >> The reason for >> doing this is the issue identified in the Security Considerations >> section of the realm-based-redirection I-D: a change of realm implies a >> change of business relationship > > I think that this is not necessarily true. For example, consider a > large ISP with international operations; such an entity might have > multiple Diameter realms (europe.bigisp.com, asia.bigisp.com, etc.), no? > >> that should be noted by the requesting >> host before the request is rerouted. [PTT] I think I've decided not to mention the 'R' bit. The result fits within the recommendations in the Security Considerations section. >> >> Tom Taylor >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > > From bill.wu@huawei.com Mon Jan 9 19:21:04 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE0B11E80A1 for ; Mon, 9 Jan 2012 19:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.102 X-Spam-Level: X-Spam-Status: No, score=-6.102 tagged_above=-999 required=5 tests=[AWL=0.497, BAYES_00=-2.599, 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 bih77PU0hXw2 for ; Mon, 9 Jan 2012 19:21:03 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFC511E809B for ; Mon, 9 Jan 2012 19:21:03 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXK00HQ1BXXPJ@szxga05-in.huawei.com> for dime@ietf.org; Tue, 10 Jan 2012 11:20:21 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXK00EOCBXJFT@szxga05-in.huawei.com> for dime@ietf.org; Tue, 10 Jan 2012 11:20:21 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGI21047; Tue, 10 Jan 2012 11:20:20 +0800 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Jan 2012 11:20:13 +0800 Received: from w53375q (10.138.41.130) by szxeml409-hub.china.huawei.com (10.82.67.136) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Jan 2012 11:20:10 +0800 Date: Tue, 10 Jan 2012 11:20:09 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: "Romascanu, Dan (Dan)" , dime@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: Subject: Re: [Dime] AD review of draft-ietf-dime-pmip6-lr-06 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 03:21:04 -0000 Hi, Dan: Thank for your careful detailed review, please see my comments inline. Regards! -Qin ----- Original Message ----- From: "Romascanu, Dan (Dan)" To: Sent: Monday, January 09, 2012 9:24 PM Subject: [Dime] AD review of draft-ietf-dime-pmip6-lr-06 > This is the AD review of draft-ietf-dime-pmip6-lr-06. In general the > document is in good share. I have a few comments listed below, but these > do not prevent sending the document to IETF Last Call. Please consider > the comments together with the other comments that you may receive > during the last call. > > The Comments are divided in T-Technical and E-Editorial > > > T1. Section 3.1: > >> The MIP6-Agent-Info grouped AVP (AVP Code 486) is defined in > [RFC5779]. This AVP is used to carry LMA addressing in AAA response. > > Actually the MIP6-Agent-Info grouped AVP is defined in [RFC5447] and > extended in [RFC5779]. [Qin]: You are right, AVP Code 486 is defined in RFC5447 rather than RFC5779, I will fix this in the new version. > T2. In Section 3.4: > >> The LMA SHOULD support > this policy feature on a per-MN and per-subscription basis. > > First, this is the only usage of a capitalized keyword, and it treggers > an id-nits error because there is no 2119 boilerplate and reference. You > need to decide whether to take it out, or leave it but in this case add > the boilerplate and referance to [RFC2119] [Qin]: Okay, I can add the boilerplate and reference to RFC2119. But it seems only this place needs RFC2119 language. Nowhere else. > Second, is this really a SHOULD? When would the LMA not support this > feature? [Qin]: My understanding is yes. In the case of Direct routing of IP packets between MNs anchored to the same MAG , LMA would not support this feature. > > E1. Section 3.4: > >> This > document defines new capability flag bits according to the IANA rules > in RFC 5447. > > > s/new capability flag bits/one new capability flag bit/ [Qin]: Okay. > E2. Also in Section 3.4: > > s/it indicate that both MN and CN/it indicates that both MN and CN/ [Qin]: Okay. > E3. Section 4.2: > >> In the case where MNs belong to the different LMAs, > MAG1 or LMA1 should has already known the recipient of localized > routing is LMA2. > > This sentence is broken, needs to be fixed. [Qin]: Yes, I think this can be fixed by removing should. Thanks. > E4. In the IANA Considerations section it would be useful to add that > the new value in the Mobility Capability registry corresponds to the new > capability flag bit defined in section 3.4 [Qin]: This was discussed before the WGLC. In the early version we added the new value 0x0000080000000000 to the the new capability flag bit. One suggestion from Jouni I remembered is the new value should be decided by IANA folks. So in the version 06, I change the value 0x0000080000000000 to TBD. I am okay to put the new value back if you think it necessary we should do that. > > E5. Add a note to the Change Log section to be taken out at publication. [Qin]: Okay. Thanks. > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Tue Jan 10 00:08:46 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA4221F87FF for ; Tue, 10 Jan 2012 00:08:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.813 X-Spam-Level: X-Spam-Status: No, score=-3.813 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 cvQl3ZEdsRCt for ; Tue, 10 Jan 2012 00:08:46 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A1E2621F8621 for ; Tue, 10 Jan 2012 00:08:45 -0800 (PST) Received: by laah2 with SMTP id h2so2124647laa.31 for ; Tue, 10 Jan 2012 00:08:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Kssze0iLmOjwT9Z6QrGl5EiMMMW/EWWvG7TfdFGjFSc=; b=w4YqnbAqgDh/SN+Y0alxB0RcHohq6KTzGw9V2d11uEcTMfU5vX8eOd7zkdL7dTRBE4 BC8+rFzSZCwuihSD+UWe1b9DgkvfDiaGuTL4gCP2DOjC4BZ/lOjVWGuM4zZRbEUhJnT3 k5u9TyWofRJgYBOJP+lXeqfmQjuI8Hvzf/cd4= Received: by 10.152.114.169 with SMTP id jh9mr8226953lab.20.1326182923368; Tue, 10 Jan 2012 00:08:43 -0800 (PST) Received: from a88-112-207-191.elisa-laajakaista.fi (a88-112-207-191.elisa-laajakaista.fi. [88.112.207.191]) by mx.google.com with ESMTPS id on4sm74639048lab.7.2012.01.10.00.08.41 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Jan 2012 00:08:42 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4F09FA77.5020301@gmail.com> Date: Tue, 10 Jan 2012 10:08:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F09FA77.5020301@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1084) Cc: "dime@ietf.org" Subject: Re: [Dime] Would realm-based redirection be a protocol error or an application error? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 08:08:47 -0000 Tom, On Jan 8, 2012, at 10:20 PM, Tom Taylor wrote: > I'm finally updating draft-ietf-dime-realm-based-redirect. >=20 > Given that realm-based redirection is defined at an application level, = maybe the answer is obvious. What I am concerned with is whether the = redirect server should clear the 'R' bit in the header to ensure that = the response goes all the way Clearing 'R' is normal behavior when sending any answer message. In the = answer message the content of your Result-Code AVP then identifies what = went wrong. However, in your draft you define a new Result-Code value = DIAMETER_REALM_REDIRECT_INDICATION (3xxx TBD), which is a protocol error = and therefore would require 'E' bit to be set and the specific error = answer command ABNF to be used (see Sections 7.1.3 and 7.2 of RFC3588). = As the error answer is sent back towards the originator of the request, = each agent may take action on the message. Since the error is specific = to redirection it is very unlikely any intermediate agent would take any = action to the answer message. - Jouni > back to the original requesting host (i.e., following on Figure 8 in = section 7 of RFC 3588). The reason for doing this is the issue = identified in the Security Considerations section of the = realm-based-redirection I-D: a change of realm implies a change of = business relationship that should be noted by the requesting host before = the request is rerouted. >=20 > Tom Taylor > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From dromasca@avaya.com Tue Jan 10 02:12:27 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32BE721F8528 for ; Tue, 10 Jan 2012 02:12:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.796 X-Spam-Level: X-Spam-Status: No, score=-102.796 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 CRGelmmsQGZ0 for ; Tue, 10 Jan 2012 02:12:26 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 57F6721F851E for ; Tue, 10 Jan 2012 02:12:25 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKEODE+HCzI1/2dsb2JhbABDrFeBBYFyAQEBAQIBAQEBDx4KNBcEAgEIDQEDBAEBCwMDDAsBBgEmHwkIAQEEARIIGodYCJpsm1MEiy5jBJp7jEo X-IronPort-AV: E=Sophos;i="4.71,486,1320642000"; d="scan'208";a="226004502" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 10 Jan 2012 05:12:20 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 10 Jan 2012 04:59:11 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Jan 2012 11:12:18 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] AD review of draft-ietf-dime-pmip6-lr-06 Thread-Index: AczPRuwP2C2kx3yAS2O83UN7fXOh1wAOCEJA References: From: "Romascanu, Dan (Dan)" To: "Qin Wu" , Subject: Re: [Dime] AD review of draft-ietf-dime-pmip6-lr-06 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 10:12:27 -0000 Hi Qin, Thank you for your quick response.=20 No need to issue a revised version now. I am sending the document to IETF Last Call, and you can implement the changes that address my comments together with other comments that you may receive during the IETF Last Call.=20 See in-line a few notes.=20 Regards, Dan > -----Original Message----- > From: Qin Wu [mailto:bill.wu@huawei.com] > Sent: Tuesday, January 10, 2012 5:20 AM > To: Romascanu, Dan (Dan); dime@ietf.org > Subject: Re: [Dime] AD review of draft-ietf-dime-pmip6-lr-06 >=20 > Hi, Dan: > Thank for your careful detailed review, please see my comments inline. >=20 > Regards! > -Qin > ----- Original Message ----- > From: "Romascanu, Dan (Dan)" > To: > Sent: Monday, January 09, 2012 9:24 PM > Subject: [Dime] AD review of draft-ietf-dime-pmip6-lr-06 >=20 >=20 > > This is the AD review of draft-ietf-dime-pmip6-lr-06. In general the > > document is in good share. I have a few comments listed below, but > these > > do not prevent sending the document to IETF Last Call. Please > consider > > the comments together with the other comments that you may receive > > during the last call. > > > > The Comments are divided in T-Technical and E-Editorial > > > > > > T1. Section 3.1: > > > >> The MIP6-Agent-Info grouped AVP (AVP Code 486) is defined in > > [RFC5779]. This AVP is used to carry LMA addressing in AAA > response. > > > > Actually the MIP6-Agent-Info grouped AVP is defined in [RFC5447] and > > extended in [RFC5779]. >=20 > [Qin]: You are right, AVP Code 486 is defined in RFC5447 rather than > RFC5779, > I will fix this in the new version. >=20 > > T2. In Section 3.4: > > > >> The LMA SHOULD support > > this policy feature on a per-MN and per-subscription basis. > > > > First, this is the only usage of a capitalized keyword, and it > treggers > > an id-nits error because there is no 2119 boilerplate and reference. > You > > need to decide whether to take it out, or leave it but in this case > add > > the boilerplate and referance to [RFC2119] >=20 > [Qin]: Okay, I can add the boilerplate and reference to RFC2119. But it > seems only > this place needs RFC2119 language. Nowhere else. >=20 [[DR]] One is enough to justify the need for the boilerplate and reference. So either you add these or you renounce to using capitalized SHOULD.=20 > > Second, is this really a SHOULD? When would the LMA not support this > > feature? >=20 > [Qin]: My understanding is yes. In the case of Direct routing of IP > packets between MNs anchored to the same MAG > , LMA would not support this feature. [[DR]] Is this not a determined by the topology in deployment? It seems to me that an LMA implementation MUST support the feature, but it will not be activated in the cases of Direct routing.=20 >=20 > > > > E1. Section 3.4: > > > >> This > > document defines new capability flag bits according to the IANA > rules > > in RFC 5447. > > > > > > s/new capability flag bits/one new capability flag bit/ >=20 > [Qin]: Okay. >=20 > > E2. Also in Section 3.4: > > > > s/it indicate that both MN and CN/it indicates that both MN and CN/ >=20 > [Qin]: Okay. >=20 > > E3. Section 4.2: > > > >> In the case where MNs belong to the different LMAs, > > MAG1 or LMA1 should has already known the recipient of localized > > routing is LMA2. > > > > This sentence is broken, needs to be fixed. >=20 > [Qin]: Yes, I think this can be fixed by removing should. Thanks. >=20 > > E4. In the IANA Considerations section it would be useful to add that > > the new value in the Mobility Capability registry corresponds to the > new > > capability flag bit defined in section 3.4 >=20 > [Qin]: This was discussed before the WGLC. In the early version we > added the new value > 0x0000080000000000 to the the new capability flag bit. One suggestion > from Jouni I remembered > is the new value should be decided by IANA folks. So in the version 06, > I change the value > 0x0000080000000000 to TBD. > I am okay to put the new value back if you think it necessary we should > do that. >=20 [[DR]] It's OK to let IANA decide what bit to allocate for the new capability. What I am missing is the text linking the allocation to the new capability flag bit mentioned in section 3.4. > > > > E5. Add a note to the Change Log section to be taken out at > publication. >=20 > [Qin]: Okay. Thanks. > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime From iesg-secretary@ietf.org Tue Jan 10 06:52:07 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C74B121F8616; Tue, 10 Jan 2012 06:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.372 X-Spam-Level: X-Spam-Status: No, score=-102.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 N664uTaOLMzi; Tue, 10 Jan 2012 06:52:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F61B21F851E; Tue, 10 Jan 2012 06:52:07 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120110145207.25744.94140.idtracker@ietfa.amsl.com> Date: Tue, 10 Jan 2012 06:52:07 -0800 Cc: dime@ietf.org Subject: [Dime] Last Call: (Diameter Support for Proxy Mobile IPv6 Localized Routing) to Proposed Standard X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 14:52:07 -0000 The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'Diameter Support for Proxy Mobile IPv6 Localized Routing' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-01-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by the Mobile Access Gateway (MAG) to which it is attached are typically tunneled to a Local Mobility Anchor (LMA) for routing. The term "localized routing" refers to a method by which packets are routed directly between an MN's MAG and the MAG of its Correspondent Node (CN) without involving any LMA. In order to establish a localized routing session between two Mobile Access Gateways in a Proxy Mobile IPv6 domain, two tasks must be accomplished: The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dime-pmip6-lr/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dime-pmip6-lr/ No IPR declarations have been submitted directly on this I-D. From Tina.Tsou.Zouting@huawei.com Tue Jan 10 07:12:24 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61CA821F85FD for ; Tue, 10 Jan 2012 07:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, 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 keoE0OAPe9we for ; Tue, 10 Jan 2012 07:12:23 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id CC63D21F85F8 for ; Tue, 10 Jan 2012 07:12:18 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXL00FRW8VD5J@szxga05-in.huawei.com> for dime@ietf.org; Tue, 10 Jan 2012 23:11:37 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXL00LWE8VDFG@szxga05-in.huawei.com> for dime@ietf.org; Tue, 10 Jan 2012 23:11:37 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGF72535; Tue, 10 Jan 2012 23:11:31 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Jan 2012 23:11:27 +0800 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.37]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Tue, 10 Jan 2012 23:11:10 +0800 Date: Tue, 10 Jan 2012 15:11:10 +0000 From: Tina TSOU In-reply-to: <4F0B7ECB.5040006@gmail.com> To: Tom Taylor Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [Dime] Would realm-based redirection be a protocol error or an application error? Thread-index: AQHMzkMKHo1R45LVnEGXlFhXo140npYDFisAgAEb8oCAAYWIRQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4F09FA77.5020301@gmail.com> <4F0A909A.2030705@gmail.com> <4F0B7ECB.5040006@gmail.com> Cc: "dime@ietf.org" Subject: Re: [Dime] Would realm-based redirection be a protocol error or an application error? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 15:12:24 -0000 DIAMETER_REALM_REDIRECT_INDICATION should be defined as an Application error. I think the 5XXX class is appropriate. The R-bit should be cleared (default for all Diameter answer messages) and E-bit should not be set. Sent from my iPad On Jan 9, 2012, at 5:57 PM, "Tom Taylor" wrote: > See below. > > On 09/01/2012 2:00 AM, Glen Zorn wrote: >> On 1/9/2012 3:20 AM, Tom Taylor wrote: >> >>> I'm finally updating draft-ietf-dime-realm-based-redirect. >>> >>> Given that realm-based redirection is defined at an application level, >>> maybe the answer is obvious. >> >> Section 7 of RFC 3588 says >> >> There are two different types of errors in Diameter; protocol and >> application errors. A protocol error is one that occurs at the base >> protocol level, and MAY require per hop attention (e.g., message >> routing error). Application errors, on the other hand, generally >> occur due to a problem with a function specified in a Diameter >> application (e.g., user authentication, Missing AVP). >> >>> What I am concerned with is whether the >>> redirect server should clear the 'R' bit in the header to ensure that >>> the response goes all the way back to the original requesting host >>> (i.e., following on Figure 8 in section 7 of RFC 3588). >> >> I don't understand: as I understand it, the 'R' bit has nothing to do >> with error type; if it is cleared that just signifies that the message >> is an answer, rather than a request (which would presumably be true of >> any error response). > > [PTT] I don't think so. Section 7 makes a clear distinction between the routing for protocol error responses and application error responses (Figures 7 and 8 rtespectively) and ascribes the difference to the setting of the 'R' bit (text following Figure 8). >> >>> The reason for >>> doing this is the issue identified in the Security Considerations >>> section of the realm-based-redirection I-D: a change of realm implies a >>> change of business relationship >> >> I think that this is not necessarily true. For example, consider a >> large ISP with international operations; such an entity might have >> multiple Diameter realms (europe.bigisp.com, asia.bigisp.com, etc.), no? >> >>> that should be noted by the requesting >>> host before the request is rerouted. > > [PTT] I think I've decided not to mention the 'R' bit. The result fits within the recommendations in the Security Considerations section. > >>> >>> Tom Taylor >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >> >> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Tue Jan 10 13:01:01 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D555811E8071 for ; Tue, 10 Jan 2012 13:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.787 X-Spam-Level: X-Spam-Status: No, score=-3.787 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 GQCFXpAQ9asj for ; Tue, 10 Jan 2012 13:01:01 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2BD1F0C38 for ; Tue, 10 Jan 2012 13:00:51 -0800 (PST) Received: by laah2 with SMTP id h2so2230laa.31 for ; Tue, 10 Jan 2012 13:00:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=T3HFAbhOQ3Yvmb3dgsmgtWJYTt6SMuU99k1QoWAsMGs=; b=nOiGF0MxFPvi2XqG2dzR2qfZfcqZxCqlGSlisCP96OxIfbjWgXzWJOUH51qOKacCq9 P2A1kLkGzOsB/+IyLalhNo67NxaPtDo2CuNjMj/zPNPSHqGdfygjEo0LqkyJx7djXOfG bKLgsVIOr8b05W0GIvHkf2lm9GaD/iiO45UkA= Received: by 10.112.84.163 with SMTP id a3mr4815116lbz.53.1326229250158; Tue, 10 Jan 2012 13:00:50 -0800 (PST) Received: from a88-112-207-191.elisa-laajakaista.fi (a88-112-207-191.elisa-laajakaista.fi. [88.112.207.191]) by mx.google.com with ESMTPS id pg16sm24747660lab.9.2012.01.10.13.00.48 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Jan 2012 13:00:49 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Tue, 10 Jan 2012 23:00:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F09FA77.5020301@gmail.com> <4F0A909A.2030705@gmail.com> <4F0B7ECB.5040006@gmail.com> To: Tina TSOU X-Mailer: Apple Mail (2.1084) Cc: "dime@ietf.org" Subject: Re: [Dime] Would realm-based redirection be a protocol error or an application error? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 21:01:01 -0000 A question. Taken that existing direct stuff uses protocol errors (3xxx) = why should realm-based redirection behave differently?=20 - Jouni On Jan 10, 2012, at 5:11 PM, Tina TSOU wrote: > DIAMETER_REALM_REDIRECT_INDICATION should be defined as an Application = error. > I think the 5XXX class is appropriate. > The R-bit should be cleared (default for all Diameter answer messages) = and E-bit should not be set. >=20 > Sent from my iPad >=20 > On Jan 9, 2012, at 5:57 PM, "Tom Taylor" = wrote: >=20 >> See below. >>=20 >> On 09/01/2012 2:00 AM, Glen Zorn wrote: >>> On 1/9/2012 3:20 AM, Tom Taylor wrote: >>>=20 >>>> I'm finally updating draft-ietf-dime-realm-based-redirect. >>>>=20 >>>> Given that realm-based redirection is defined at an application = level, >>>> maybe the answer is obvious. >>>=20 >>> Section 7 of RFC 3588 says >>>=20 >>> There are two different types of errors in Diameter; protocol and >>> application errors. A protocol error is one that occurs at the = base >>> protocol level, and MAY require per hop attention (e.g., message >>> routing error). Application errors, on the other hand, generally >>> occur due to a problem with a function specified in a Diameter >>> application (e.g., user authentication, Missing AVP). >>>=20 >>>> What I am concerned with is whether the >>>> redirect server should clear the 'R' bit in the header to ensure = that >>>> the response goes all the way back to the original requesting host >>>> (i.e., following on Figure 8 in section 7 of RFC 3588). >>>=20 >>> I don't understand: as I understand it, the 'R' bit has nothing to = do >>> with error type; if it is cleared that just signifies that the = message >>> is an answer, rather than a request (which would presumably be true = of >>> any error response). >>=20 >> [PTT] I don't think so. Section 7 makes a clear distinction between = the routing for protocol error responses and application error responses = (Figures 7 and 8 rtespectively) and ascribes the difference to the = setting of the 'R' bit (text following Figure 8). >>>=20 >>>> The reason for >>>> doing this is the issue identified in the Security Considerations >>>> section of the realm-based-redirection I-D: a change of realm = implies a >>>> change of business relationship >>>=20 >>> I think that this is not necessarily true. For example, consider a >>> large ISP with international operations; such an entity might have >>> multiple Diameter realms (europe.bigisp.com, asia.bigisp.com, etc.), = no? >>>=20 >>>> that should be noted by the requesting >>>> host before the request is rerouted. >>=20 >> [PTT] I think I've decided not to mention the 'R' bit. The result = fits within the recommendations in the Security Considerations section. >>=20 >>>>=20 >>>> Tom Taylor >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>=20 >>>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From internet-drafts@ietf.org Tue Jan 10 16:05:24 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 106B921F880E; Tue, 10 Jan 2012 16:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 LNbLXp16I4pD; Tue, 10 Jan 2012 16:05:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA01E21F877A; Tue, 10 Jan 2012 16:05:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120111000516.20781.38451.idtracker@ietfa.amsl.com> Date: Tue, 10 Jan 2012 16:05:16 -0800 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-nat-control-13.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 00:05:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions W= orking Group of the IETF. Title : Diameter Network Address and Port Translation Control Ap= plication Author(s) : Frank Brockners Shwetha Bhandari Vaneeta Singh Victor Fajardo Filename : draft-ietf-dime-nat-control-13.txt Pages : 59 Date : 2012-01-10 This document describes the framework, messages, and procedures for the Diameter Network address and port translation Control Application. This Diameter application allows per endpoint control of Network Address Translators and Network Address and Port Translators, which are added to networks to cope with IPv4-address space depletion. This Diameter application allows external devices to configure and manage a Network Address Translator device - expanding the existing Diameter-based AAA and policy control capabilities with a Network Address Translators and Network Address and Port Translators control component. These external devices can be network elements in the data plane such as a Network Access Server, or can be more centralized control plane devices such as AAA- servers. This Diameter application establishes a context to commonly identify and manage endpoints on a gateway or server, and a Network Address Translator and Network Address and Port Translator device. This includes, for example, the control of the total number of Network Address Translator bindings allowed or the allocation of a specific Network Address Translator binding for a particular endpoint. In addition, it allows Network Address Translator devices to provide information relevant to accounting purposes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-nat-control-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-nat-control-13.txt From bill.wu@huawei.com Tue Jan 10 18:04:40 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A118D21F8458 for ; Tue, 10 Jan 2012 18:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.164 X-Spam-Level: X-Spam-Status: No, score=-6.164 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599, 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 5wZ6K-fiXXju for ; Tue, 10 Jan 2012 18:04:39 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 5307621F8483 for ; Tue, 10 Jan 2012 18:04:38 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXM001GF2ZYUT@szxga04-in.huawei.com> for dime@ietf.org; Wed, 11 Jan 2012 10:02:22 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXM003OV2ZWBZ@szxga04-in.huawei.com> for dime@ietf.org; Wed, 11 Jan 2012 10:02:22 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGF81382; Wed, 11 Jan 2012 10:02:22 +0800 Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 11 Jan 2012 10:02:16 +0800 Received: from w53375q (10.138.41.130) by SZXEML414-HUB.china.huawei.com (10.82.67.153) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 11 Jan 2012 09:59:16 +0800 Date: Wed, 11 Jan 2012 09:59:13 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: "Romascanu, Dan (Dan)" , dime@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: Subject: Re: [Dime] AD review of draft-ietf-dime-pmip6-lr-06 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 02:04:40 -0000 I see and also agree with your notes, thanks. Regards! -Qin ----- Original Message ----- From: "Romascanu, Dan (Dan)" To: "Qin Wu" ; Sent: Tuesday, January 10, 2012 6:12 PM Subject: RE: [Dime] AD review of draft-ietf-dime-pmip6-lr-06 Hi Qin, Thank you for your quick response. No need to issue a revised version now. I am sending the document to IETF Last Call, and you can implement the changes that address my comments together with other comments that you may receive during the IETF Last Call. See in-line a few notes. Regards, Dan > -----Original Message----- > From: Qin Wu [mailto:bill.wu@huawei.com] > Sent: Tuesday, January 10, 2012 5:20 AM > To: Romascanu, Dan (Dan); dime@ietf.org > Subject: Re: [Dime] AD review of draft-ietf-dime-pmip6-lr-06 > > Hi, Dan: > Thank for your careful detailed review, please see my comments inline. > > Regards! > -Qin > ----- Original Message ----- > From: "Romascanu, Dan (Dan)" > To: > Sent: Monday, January 09, 2012 9:24 PM > Subject: [Dime] AD review of draft-ietf-dime-pmip6-lr-06 > > > > This is the AD review of draft-ietf-dime-pmip6-lr-06. In general the > > document is in good share. I have a few comments listed below, but > these > > do not prevent sending the document to IETF Last Call. Please > consider > > the comments together with the other comments that you may receive > > during the last call. > > > > The Comments are divided in T-Technical and E-Editorial > > > > > > T1. Section 3.1: > > > >> The MIP6-Agent-Info grouped AVP (AVP Code 486) is defined in > > [RFC5779]. This AVP is used to carry LMA addressing in AAA > response. > > > > Actually the MIP6-Agent-Info grouped AVP is defined in [RFC5447] and > > extended in [RFC5779]. > > [Qin]: You are right, AVP Code 486 is defined in RFC5447 rather than > RFC5779, > I will fix this in the new version. > > > T2. In Section 3.4: > > > >> The LMA SHOULD support > > this policy feature on a per-MN and per-subscription basis. > > > > First, this is the only usage of a capitalized keyword, and it > treggers > > an id-nits error because there is no 2119 boilerplate and reference. > You > > need to decide whether to take it out, or leave it but in this case > add > > the boilerplate and referance to [RFC2119] > > [Qin]: Okay, I can add the boilerplate and reference to RFC2119. But it > seems only > this place needs RFC2119 language. Nowhere else. > [[DR]] One is enough to justify the need for the boilerplate and reference. So either you add these or you renounce to using capitalized SHOULD. > > Second, is this really a SHOULD? When would the LMA not support this > > feature? > > [Qin]: My understanding is yes. In the case of Direct routing of IP > packets between MNs anchored to the same MAG > , LMA would not support this feature. [[DR]] Is this not a determined by the topology in deployment? It seems to me that an LMA implementation MUST support the feature, but it will not be activated in the cases of Direct routing. > > > > > E1. Section 3.4: > > > >> This > > document defines new capability flag bits according to the IANA > rules > > in RFC 5447. > > > > > > s/new capability flag bits/one new capability flag bit/ > > [Qin]: Okay. > > > E2. Also in Section 3.4: > > > > s/it indicate that both MN and CN/it indicates that both MN and CN/ > > [Qin]: Okay. > > > E3. Section 4.2: > > > >> In the case where MNs belong to the different LMAs, > > MAG1 or LMA1 should has already known the recipient of localized > > routing is LMA2. > > > > This sentence is broken, needs to be fixed. > > [Qin]: Yes, I think this can be fixed by removing should. Thanks. > > > E4. In the IANA Considerations section it would be useful to add that > > the new value in the Mobility Capability registry corresponds to the > new > > capability flag bit defined in section 3.4 > > [Qin]: This was discussed before the WGLC. In the early version we > added the new value > 0x0000080000000000 to the the new capability flag bit. One suggestion > from Jouni I remembered > is the new value should be decided by IANA folks. So in the version 06, > I change the value > 0x0000080000000000 to TBD. > I am okay to put the new value back if you think it necessary we should > do that. > [[DR]] It's OK to let IANA decide what bit to allocate for the new capability. What I am missing is the text linking the allocation to the new capability flag bit mentioned in section 3.4. > > > > E5. Add a note to the Change Log section to be taken out at > publication. > > [Qin]: Okay. Thanks. > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime From internet-drafts@ietf.org Tue Jan 10 20:04:35 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204DF21F850F; Tue, 10 Jan 2012 20:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 5xqmKkkXZNcu; Tue, 10 Jan 2012 20:04:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8565521F84F0; Tue, 10 Jan 2012 20:04:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120111040434.14796.89368.idtracker@ietfa.amsl.com> Date: Tue, 10 Jan 2012 20:04:34 -0800 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-realm-based-redirect-04.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 04:04:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions W= orking Group of the IETF. Title : Realm-Based Redirection In Diameter Author(s) : Tina Tsou Tom Taylor Filename : draft-ietf-dime-realm-based-redirect-04.txt Pages : 7 Date : 2012-01-10 RFC 3588 allows a Diameter redirect agent to specify one or more individual hosts to which a Diameter message may be redirected by an upstream Diameter node. However, in some circumstances an operator may wish to redirect messages to an alternate domain without specifying individual hosts. This document specifies a mechanism by which this can be achieved. New applications may incorporate this capability by reference to the present document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-realm-based-redirect-04= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-realm-based-redirect-04.= txt From tom.taylor.stds@gmail.com Tue Jan 10 20:08:21 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C93D21F85D4 for ; Tue, 10 Jan 2012 20:08:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 mSaASXZqAwxK for ; Tue, 10 Jan 2012 20:08:20 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4722321F84F1 for ; Tue, 10 Jan 2012 20:08:20 -0800 (PST) Received: by obcuz6 with SMTP id uz6so444637obc.31 for ; Tue, 10 Jan 2012 20:08:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=DM5V93xEoBFdhCHM5vZKoiW/7t8CCgnTKkVeGL25rE8=; b=hgIw/9M4jlWlgdos6+l3MWACwHcQfNg1REBYEd5oRrZVNSwSrkGmKputbX6nReXY3O rfAM7fUQx4OwM0au1GV9DzfhzdyuF+d7XeZ8Kdp3enls/NkgAa029jq7eDQEObl4aKJu bp+FINx6KvPikUuf5Sm5X8wQ9Qenmro9pZtWU= Received: by 10.182.49.66 with SMTP id s2mr20834657obn.58.1326254899962; Tue, 10 Jan 2012 20:08:19 -0800 (PST) Received: from [192.168.2.17] ([64.228.211.26]) by mx.google.com with ESMTPS id l1sm190977obv.1.2012.01.10.20.08.18 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Jan 2012 20:08:19 -0800 (PST) Message-ID: <4F0D0B34.9090202@gmail.com> Date: Tue, 10 Jan 2012 23:08:20 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Dime] draft-ietf-dime-realm-based-redirect-04 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 04:08:21 -0000 I have awakened from my long sleep and updated draft-ietf-dime-realm-based-redirect in response to the various WGLC comments. These were recorded in tickets 1, 4, 5, 6, and 11, which can be retrieved using the query http://trac.tools.ietf.org/wg/dime/trac/query?status=new&status=assigned&status=reopened&component=realm-based-redirect The update has been submitted, but obviously is subject to change if people don't agree with my responses. The behaviour sections were extensively rewritten. Ticket #1 ========= Comment: Add a more direct pointer to the "normal discovery procedures" mentioned in Section 3.1.2. Response: Added a reference to Section 5.2 of RFC 3588. Ticket # 4 ========== Comment: (3.1.1) Missing word: Furthermore, the redirect agent MUST ^ a Redirect-Realm AVP Response: added "include" Comment: (3.1.1) If the the other peer advertised the Relay application, should the redirect agent consider that it supports the Redirect-Realm application? Response: text modified to talk about application support rather than peer capabilities (as suggested by Ticket #11). Comment: (3.1.1) "the message MUST include the Error-Reporting-Host AVP if the host setting the Result-Code AVP is different from the identity encoded in the Origin-Host AVP," ==> IIUC this is an impossible situation, since the Redirect Agent did not forward the Request. I believe this text could be removed for clarity. Response: text removed. Comment: (3.1.2) ==> What if the original request contains a Destination-Host AVP? In that case, should a UNABLE_TO_DELIVER error be returned? There is probably no point in sending to the alternate realm with a Destination-Host in the previous realm, right? Unless maybe if the Destination-Realm of the request message does not match the Origin-Realm of the Redirect indication (change of broker for example). Any opinion? Response: the reasonable action is to strip out the original Destination-Host and Destination-Realm AVPs and add a new Destination-Realm AVP with the realm identifier taken from the Redirect-Realm AVP. Of course, this is going to cause a glitch if the request was part of a stateful session. Text added to indicate the action and note the consequence as an operational matter. Comment: (3.2) ==> This section does not give the value of the M flag for the new AVP. By the semantics of the application, I believe the M flag should be set, right? Response: text added to indicate the setting of the M flag. Ticket #5 ========= Comment: Section 2: o I really want to see RFC2119 language here. Preferable a MUST saying what the application developer has to do. Response: rewritten to say that support for realm-based redirection MUST be embedded in particular applications. Comment: Section 3.1.1 o I would use some other wording than "home server".. just use "server" Response: done. Comments: Section 3.1.1 o second bullet: "..redirect agent MUST a Redirect-Realm AVP containing.." I assume a verb is missing here. o second bullet: the proposed use of Error-Reporting-Host AVP does not make sense to me. At least it is different from what RFC3588 Section 7.1 describes and I don't see a reason why it should do so. My understanding is that DIAMETER_REALM_REDIRECT_IDENTICATION works in the same way as DIAMETER_REDIRECT_IDENTICATION. Response: also on ticket #4. Fixed. Comment: Section 3.1.2 o What are the cases when SHOULD does not apply here? I mean, why these SHOULDs are not MUSTs ? Response: section rewritten, new actions are all MUST. Comment: Section 3.2 o s/Redirect- Max-/Redirect-Max Response: fixed. Comment: Section 3.1.1 again [some prologue omitted] ... Based on this, the enhanced realm-based redirection functionality can be added to _some_ redirect agent that then need to peek into request content to find out that the application supports redirection.. This might be an issue since now the realm-based redirection enhanced redirect agent may or may not be aware of all applications that support the mechanism described in this specification. o I would like to see some more text around the expected behavior _within_ the redirect agent. o I would also like to see some more text around the limitations on the application based "recognition" of the realm-based redirect functionality. Defining a new application does not imply all realm-based redirect agents would automatically know about it. o This brings realm-based redirect agent to same application updating issues as proxies have. Add some text around this. Response: I don't see this as a serious issue because the typical scenario for deployment of a realm-based redirect agent is on an ad hoc basis for specific applications that are being diverted. Hence the agent will be configured with the necessary applications, and will take more conventional actions for any other applications. Some text added in section 2 to make your point. Ticket #6 ========= Comment: [text omitted] ... This new redirect agent has to differentiate between applications that do support realm base redirection vs non-realmbased redirection. This is new base behavior and thus should be done in Diameter V2 There is an alternative - which i thought was the approach taken when i started to read the draft and that is: -let the Application itself perform the redirection. To use the example provided, if the operator does not want to host the application anymore, it can let the Application respond back with the realm and/host redirection attributes. Response: presumably you are saying that the redirection should be done by the server or possibly a proxy. This doesn't seem to be a problem, if the WG prefers to go this way. No action taken pending WG consensus. Ticket #11 ========== Comment: (3.1.1) "If the peer from which the request was received did not advertise an application incorporating the realm-based routing capability in the CER/CEA exchange, the redirect agent SHOULD set the 'E' bit in the answer and set the Result Code to DIAMETER_UNABLE_TO_DELIVER. As an alternative, the redirect agent MAY if so configured provide a host-based redirect as described in Section 6.1.7 of [RFC3588]." ==> This last sentence assumes both types of redirection information can be provisioned in the Redirect Agent. Should we allow such a configuration? If so, how does the Redirect Agent know what information should be used when the originator of the request support both redirection indication mechanisms (i.e. priority, order, etc.)? Response: deleted the alternative. Comment: (3.1.1) "Otherwise, if an application supporting the use of realm-based redirection was negotiated with the peer..." Otherwise, if the request is for an application supporting realm-based redirection, Response: modified text as suggested. Comment: (3.1.1) missing "include", incorrect addition of Error-Reporting -Host (covered by other tickets) Response: fixed. Comment: (3.1.1) "All other aspects of Section 6.1.7 remain the same as for host-based redirection." ==> the use of Redirect-Host-usage AVP and Redirect-Max-Cache-Time AVP is not exactly the same; Both are related to the Redirect-Host AVP that can be found in the answer. In the Realm-based redirection, these AVPs have to be associated with the peer resulting of the realm-based discovery mechanism, as described in section 3.2. This should be also clarified at this stage. Response: text added to this effect. Comment: (3.1.2) "The receiving Diameter node SHOULD update its cache of routing entries according to the direction provided by the Redirect-Max- Cache-Time AVP, if present. The cache entry SHOULD be associated with a redirect usage of REALM_AND_APPLICATION." ==> RFC3588 says that the Redirect-Max-Cache-Time AVP and Redirect-Host-Usage AVP is associated with the redirect-host AVP. Here, the use of this AVP are modified/enhanced to be associated with the peer discovered based on the Realm-based redirection. Response: new text makes this clear. Comment: (3.2) "Section 6.14 of [RFC3588] is modified to permit the Redirect- Max- Cache-Time AVP to be used also to specify the persistence of cache entries created by the Redirect-Realm AVP." ==> the same kind of information should be present for the use of Redirect-Host-Usage AVP. Response: text moved to an earlier section where it seemed more appropriate. Text added to cover Redirect-Host-Usage. From glenzorn@gmail.com Wed Jan 11 02:51:44 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C927621F8675 for ; Wed, 11 Jan 2012 02:51:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 YESNPgIlwqaL for ; Wed, 11 Jan 2012 02:51:44 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4585921F8663 for ; Wed, 11 Jan 2012 02:51:44 -0800 (PST) Received: by obcuz6 with SMTP id uz6so905024obc.31 for ; Wed, 11 Jan 2012 02:51:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=FcekEXxjRO0yQnhYc66IO7EWPeipUXQqFisep7Ee+uA=; b=LOJihSaUYoC6RCoQCFg2Jc+bJUqMOsEdS5TZaKgMC/qiCVTKFK2XO+a4vmbP4Fz0Wt 7JqZHPKi86NCP8QttR2NY1fvWO9sQLdpiZYUNeYwtbI4NUMKh6eOoflf8bb8JT17BLAp toH43bxyUaju5ve5fZ8B619OLOdfu9FoWXGJw= Received: by 10.50.170.73 with SMTP id ak9mr6207584igc.17.1326279103817; Wed, 11 Jan 2012 02:51:43 -0800 (PST) Received: from [192.168.1.98] (ppp-115-87-126-215.revip4.asianet.co.th. [115.87.126.215]) by mx.google.com with ESMTPS id 36sm4027640ibc.6.2012.01.11.02.51.40 (version=SSLv3 cipher=OTHER); Wed, 11 Jan 2012 02:51:42 -0800 (PST) Message-ID: <4F0D69BA.7070907@gmail.com> Date: Wed, 11 Jan 2012 17:51:38 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Tom Taylor References: <4F09FA77.5020301@gmail.com> <4F0A909A.2030705@gmail.com> <4F0B7ECB.5040006@gmail.com> In-Reply-To: <4F0B7ECB.5040006@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dime@ietf.org" Subject: Re: [Dime] Would realm-based redirection be a protocol error or an application error? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 10:51:44 -0000 On 1/10/2012 6:56 AM, Tom Taylor wrote: ... >>> What I am concerned with is whether the >>> redirect server should clear the 'R' bit in the header to ensure that >>> the response goes all the way back to the original requesting host >>> (i.e., following on Figure 8 in section 7 of RFC 3588). >> >> I don't understand: as I understand it, the 'R' bit has nothing to do >> with error type; if it is cleared that just signifies that the message >> is an answer, rather than a request (which would presumably be true of >> any error response). > > [PTT] I don't think so. Section 7 makes a clear distinction between the > routing for protocol error responses and application error responses > (Figures 7 and 8 rtespectively) and ascribes the difference to the > setting of the 'R' bit (text following Figure 8). I think that there is a serious problem here, with my thinking, yours, or with the RFC. Figures 7 and 8 appear to me to diagram two entirely different networks and both the figures and the accompanying text are descriptive of the two cases, not comparative. In other words, I not only don't agree with you but can't understand where you get the idea from. For example, why do you think that the 'R' bit is set in one response and cleared in the other? ... From tom.taylor.stds@gmail.com Wed Jan 11 05:45:49 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732CB21F86AA for ; Wed, 11 Jan 2012 05:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.117 X-Spam-Level: X-Spam-Status: No, score=-3.117 tagged_above=-999 required=5 tests=[AWL=0.482, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 uENmX2DdDPhE for ; Wed, 11 Jan 2012 05:45:49 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E4A8221F854E for ; Wed, 11 Jan 2012 05:45:43 -0800 (PST) Received: by obcuz6 with SMTP id uz6so1159658obc.31 for ; Wed, 11 Jan 2012 05:45:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=CqHnr2S7MEjFa13boMI8GZOssnvya4JMCFTOlYIxh6k=; b=trkXJZb29bzYnYvVMGGuM3PdCg3ZSuS8ENPPOhX0pD86U49hGwfY7HcMxt1iWEFbbD 10tHg6VADx20IU4/FaSOMC645d2WrOvp87kFxrncKOLFCjIXcQTjsFNV/GyYFpTwgjpi YDIIjTAE7pb0XiVpugSww+mjzEMX03DszumWE= Received: by 10.182.202.69 with SMTP id kg5mr18167683obc.35.1326289543597; Wed, 11 Jan 2012 05:45:43 -0800 (PST) Received: from [192.168.2.17] ([64.228.211.26]) by mx.google.com with ESMTPS id f7sm1444128obx.11.2012.01.11.05.45.42 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Jan 2012 05:45:43 -0800 (PST) Message-ID: <4F0D9284.2050502@gmail.com> Date: Wed, 11 Jan 2012 08:45:40 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: DIME WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Dime] Realm-based redirection X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 13:45:49 -0000 Having wrestled with what I found to be difficult questions for three days, then having had a night to reflect further, I've come to the conclusion that Avi Lior was right in his review (Ticket #6). The redirection should be performed by the application at a server or proxy that has been configured to do this instead of whatever else the application calls for. If other people agree, I'll rewrite the draft accordingly. Tom Taylor From tom.taylor.stds@gmail.com Wed Jan 11 08:18:10 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85EE321F8734 for ; Wed, 11 Jan 2012 08:18:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.197 X-Spam-Level: X-Spam-Status: No, score=-3.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 6zmUzW3koQei for ; Wed, 11 Jan 2012 08:18:10 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id EF0EB21F8667 for ; Wed, 11 Jan 2012 08:18:09 -0800 (PST) Received: by ggnr5 with SMTP id r5so484406ggn.31 for ; Wed, 11 Jan 2012 08:18:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=glUB9IXzpVMm4u+KlQsnsX8KPPn9hbCf+bVN2IH3ODc=; b=ja5bP1DmyH+D++PqJosDKF4L8D0TT3labi9BRPsCCrrDYLReKL5ycHtTcAGqPhgW9c ApC0I7Px6Gbyd8qJ8MhI3oNEIzW2YuV5ZXzk3JBsgksXUj2c05mBEj17cwbmyGbJbBHK rQUzs/wnIrdFFN+Uz/OYsKuPS87QrB0ur1lZ0= Received: by 10.182.116.38 with SMTP id jt6mr12975263obb.52.1326298689218; Wed, 11 Jan 2012 08:18:09 -0800 (PST) Received: from [192.168.2.17] ([64.228.211.26]) by mx.google.com with ESMTPS id y6sm2020222obs.0.2012.01.11.08.18.07 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Jan 2012 08:18:08 -0800 (PST) Message-ID: <4F0DB63E.3010800@gmail.com> Date: Wed, 11 Jan 2012 11:18:06 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Glen Zorn References: <4F09FA77.5020301@gmail.com> <4F0A909A.2030705@gmail.com> <4F0B7ECB.5040006@gmail.com> <4F0D69BA.7070907@gmail.com> In-Reply-To: <4F0D69BA.7070907@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dime@ietf.org" Subject: Re: [Dime] Would realm-based redirection be a protocol error or an application error? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 16:18:10 -0000 I won't argue the point further. Section 7 is undoubtedly not the most authoritative section of the RFC, and I probably misinterpreted the text. It's just that when I saw it I thought there were subtleties to Diameter that I wasn't aware of, and I'd better take them into account. On 11/01/2012 5:51 AM, Glen Zorn wrote: > On 1/10/2012 6:56 AM, Tom Taylor wrote: > > ... > >>>> What I am concerned with is whether the >>>> redirect server should clear the 'R' bit in the header to ensure that >>>> the response goes all the way back to the original requesting host >>>> (i.e., following on Figure 8 in section 7 of RFC 3588). >>> >>> I don't understand: as I understand it, the 'R' bit has nothing to do >>> with error type; if it is cleared that just signifies that the message >>> is an answer, rather than a request (which would presumably be true of >>> any error response). >> >> [PTT] I don't think so. Section 7 makes a clear distinction between the >> routing for protocol error responses and application error responses >> (Figures 7 and 8 rtespectively) and ascribes the difference to the >> setting of the 'R' bit (text following Figure 8). > > I think that there is a serious problem here, with my thinking, yours, > or with the RFC. Figures 7 and 8 appear to me to diagram two entirely > different networks and both the figures and the accompanying text are > descriptive of the two cases, not comparative. In other words, I not > only don't agree with you but can't understand where you get the idea > from. For example, why do you think that the 'R' bit is set in one > response and cleared in the other? > > ... > From wwwrun@ietfa.amsl.com Wed Jan 11 08:37:17 2012 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 591B021F87EF; Wed, 11 Jan 2012 08:37:17 -0800 (PST) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20120111163717.591B021F87EF@ietfa.amsl.com> Date: Wed, 11 Jan 2012 08:37:17 -0800 (PST) Cc: jouni.korhonen@nsn.com, lionel.morand@orange-ftgroup.com, dime@ietf.org Subject: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions (dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: iesg@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 16:37:17 -0000 A modified charter has been submitted for the Diameter Maintenance and Extensions (dime) working group in the Operations and Management Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Wednesday, January 18, 2012. Diameter Maintenance and Extensions (dime) ----------------------------------------- Current Status: Active Last Modified: 2012-01-10 Chairs: Lionel Morand Jouni Korhonen Operations and Management Area Directors: Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion: dime@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dime Archive: http://www.ietf.org/mail-archive/web/dime/current/maillist.html Description of Working Group: The Diameter Maintenance and Extensions WG will focus on maintenance and extensions to the Diameter protocol required to enable its use for authentication, authorization, accounting, charging in network access, provisioning of configuration information within the network, and for new AAA session management uses within the extensibility rules of the Diameter base protocol. The DIME working group plans to address the following items: - Maintaining and/or progressing, along the standards track, the Diameter Base protocol and Diameter Applications. This includes extensions to Diameter Base protocol that can be considered as enhanced features or bug fixes. - Diameter application design guideline. This document will provide guidelines for design of Diameter extensions. It will detail when to consider reusing an existing application and when to develop a new application. - Protocol extensions for the management of Diameter entities. This work focuses on the standardization of Management Information Bases (MIBs) to configure Diameter entities (such as the Diameter Base protocol or Diameter Credit Control nodes). The usage of other management protocols for configuring Diameter entities may be future work within the group. - Protocol extensions for bulk and grouped AAA session management. The aim of this work is to study and standardize a solution for handling groups of AAA sessions within the Diameter base protocol context. The solution would define how to identify and handle grouped AAA sessions in commands and operations. Additionally, Diameter-based systems require interoperability in order to work. The working group, along with the AD, will need to evaluate any potential extensions and require verification that the proposed extension is needed, and is within the extensibility rules of Diameter and AAA scope. Coordination with other IETF working groups and other SDOs (e.g. 3GPP) will be used to ensure this. Goals and Milestones: Done - Submit the following two Diameter Mobility documents to the IESG for consideration as a Proposed Standards:* 'Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction' * 'Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction' Done - Submit 'Diameter API' to the IESG for consideration as an Informational RFC Done - Submit 'Quality of Service Parameters for Usage with Diameter' to the IESG for consideration as a Proposed Standard. Done - Submit 'Diameter QoS Application' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Support for EAP Re-authentication Protocol' as DIME working group item Done - Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' as DIME working group item Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working group item Done - Submit 'Quality of Service Attributes for Diameter' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter NAT Control Application' as DIME working group item Done - Submit 'Diameter Capabilities Update' as DIME working group item Done - Submit 'Diameter Credit Control Application MIB' to the IESG for consideration as an Informational RFC Done - Submit 'Diameter Base Protocol MIB' to the IESG for consideration as an Informational RFC Done - Submit 'Diameter Capabilities Update' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Extended NAPTR' as DIME working group item Done - Submit 'Realm-Based Redirection In Diameter' as DIME working group item Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized Routing' as DIME working group item Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic Key Transport' as DIME working group item Done - Submit 'Diameter Priority Attribute Value Pairs' as DIME working group item Done - Submit 'Diameter IKEv2 PSK' as DIME working group item Done - Submit Revision of 'Diameter Base Protocol' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic Key Transport' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Priority Attribute Value Pairs' to the IESG for consideration as a Proposed Standard Done - Submit Revision of 'Diameter Network Access Server Application - RFC 4005bis' as DIME working group item Done - Submit 'Diameter NAT Control Application' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter IKEv2 PSK' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Extended NAPTR' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized Routing' to the IESG for consideration as a Proposed Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the IESG for consideration as a Proposed Standard Mar 2012 - Submit Revision of 'Diameter Network Access Server Application - RFC 4005bis' to the IESG for consideration as a Proposed Standard May 2012 - Submit 'Diameter Application Design Guidelines' to the IESG for consideration as a BCP document Standard Jul 2012 - Submit 'Diameter Support for EAP Re-authentication Protocol' to the IESG for consideration as a Proposed Standard Aug 2012 - Submit a document on 'Protocol extension for bulk and group signaling' as a working group item Aug 2013 - Submit a document on 'Protocol extension for bulk and group signaling' to the IESG for consideration as a Proposed Standard From Tina.Tsou.Zouting@huawei.com Wed Jan 11 09:36:46 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7238621F8859 for ; Wed, 11 Jan 2012 09:36:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.571 X-Spam-Level: X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, 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 MMUVVY+uYFaW for ; Wed, 11 Jan 2012 09:36:45 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id B4C9621F884B for ; Wed, 11 Jan 2012 09:36:45 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXN00JUIA93KN@szxga04-in.huawei.com> for dime@ietf.org; Thu, 12 Jan 2012 01:36:39 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXN0044VA93DZ@szxga04-in.huawei.com> for dime@ietf.org; Thu, 12 Jan 2012 01:36:39 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGJ65311; Thu, 12 Jan 2012 01:36:39 +0800 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 12 Jan 2012 01:36:34 +0800 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.37]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Thu, 12 Jan 2012 01:36:21 +0800 Date: Wed, 11 Jan 2012 17:36:20 +0000 From: Tina TSOU In-reply-to: <4F0DB63E.3010800@gmail.com> X-Originating-IP: [10.212.244.185] To: Tom Taylor , Glen Zorn Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [Dime] Would realm-based redirection be a protocol error or an application error? Thread-index: AQHMzkMKHo1R45LVnEGXlFhXo140npYDFisAgAEb8oCAAkk9AIAAWzcAgACagJA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4F09FA77.5020301@gmail.com> <4F0A909A.2030705@gmail.com> <4F0B7ECB.5040006@gmail.com> <4F0D69BA.7070907@gmail.com> <4F0DB63E.3010800@gmail.com> Cc: "dime@ietf.org" Subject: Re: [Dime] Would realm-based redirection be a protocol error or an application error? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 17:36:46 -0000 IMHO, Diameter base protocol mainly specifies routing procedure. In the base protocol, Redirect Agent currently returns the error on protocol layer. So it should be 3XX errors processed in Diameter protocol layer. Tina > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > Tom Taylor > Sent: Wednesday, January 11, 2012 10:18 AM > To: Glen Zorn > Cc: dime@ietf.org > Subject: Re: [Dime] Would realm-based redirection be a protocol error or > an application error? > > I won't argue the point further. Section 7 is undoubtedly not the most > authoritative section of the RFC, and I probably misinterpreted the > text. It's just that when I saw it I thought there were subtleties to > Diameter that I wasn't aware of, and I'd better take them into account. > > On 11/01/2012 5:51 AM, Glen Zorn wrote: > > On 1/10/2012 6:56 AM, Tom Taylor wrote: > > > > ... > > > >>>> What I am concerned with is whether the > >>>> redirect server should clear the 'R' bit in the header to ensure that > >>>> the response goes all the way back to the original requesting host > >>>> (i.e., following on Figure 8 in section 7 of RFC 3588). > >>> > >>> I don't understand: as I understand it, the 'R' bit has nothing to do > >>> with error type; if it is cleared that just signifies that the message > >>> is an answer, rather than a request (which would presumably be true of > >>> any error response). > >> > >> [PTT] I don't think so. Section 7 makes a clear distinction between the > >> routing for protocol error responses and application error responses > >> (Figures 7 and 8 rtespectively) and ascribes the difference to the > >> setting of the 'R' bit (text following Figure 8). > > > > I think that there is a serious problem here, with my thinking, yours, > > or with the RFC. Figures 7 and 8 appear to me to diagram two entirely > > different networks and both the figures and the accompanying text are > > descriptive of the two cases, not comparative. In other words, I not > > only don't agree with you but can't understand where you get the idea > > from. For example, why do you think that the 'R' bit is set in one > > response and cleared in the other? > > > > ... > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From internet-drafts@ietf.org Wed Jan 11 09:41:05 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B66E21F889A; Wed, 11 Jan 2012 09:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 PcUaWF2dGnJk; Wed, 11 Jan 2012 09:41:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF71921F863F; Wed, 11 Jan 2012 09:40:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120111174045.8974.62914.idtracker@ietfa.amsl.com> Date: Wed, 11 Jan 2012 09:40:45 -0800 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-app-design-guide-13.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 17:41:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions W= orking Group of the IETF. Title : Diameter Applications Design Guidelines Author(s) : Victor Fajardo Hannes Tschofenig Lionel Morand Filename : draft-ietf-dime-app-design-guide-13.txt Pages : 27 Date : 2012-01-11 The Diameter Base protocol provides facilities for protocol extensibility enabling to define new Diameter applications or modify existing applications. This document is a companion document to the Diameter Base protocol that further explains and clarifies the rules to extend the Diameter Base protocol. It is meant as a guidelines document and therefore it does not add, remove or change existing rules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-app-design-guide-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-app-design-guide-13.txt From stephen.farrell@cs.tcd.ie Wed Jan 11 09:32:01 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA7F21F8760; Wed, 11 Jan 2012 09:32:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 wwZzdVolBZXV; Wed, 11 Jan 2012 09:32:00 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 29ECA21F8751; Wed, 11 Jan 2012 09:31:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 3FDB8153FAB; Wed, 11 Jan 2012 17:31:59 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1326303118; bh=zOKPkls++v2o1A EJPOPjuwbYuJRtTAOe6ASgTAkbXAI=; b=RRLeG/IOKc/ED2+eILiQ0R9gQQ5XXF 2WkbU+buwUsIVNMT4fadDNKWNMxaYHQzVKI+COQ3SQvOisfNV4azRNmNrOpzny91 To86r6fjv6iAKblfuZC7vgv1y4XsmRcaWIkRGDy/z35klCIb4Crsb3cJ9N3W1s10 OhPXbJNB0tExp9FO6jEeKMoriXl0WRWY1Lc8orX/Jbyvve9OzGY6HKWDBLYHz9uG TAONHmozk/2vPsIdCUasoQvA6hQsjG4idOojy0RtvuXv+EYGch5tB1mjLEgZlthV 73mDQFGP8ayc0T6uxS+U2U+/h69q5Qw6dZD1JHR46xjyXLrExPv5DWaw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id ePos7JxZj4G0; Wed, 11 Jan 2012 17:31:58 +0000 (GMT) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 0C6A1171C7D; Wed, 11 Jan 2012 17:31:57 +0000 (GMT) Message-ID: <4F0DC78D.2010809@cs.tcd.ie> Date: Wed, 11 Jan 2012 17:31:57 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: IETF-Discussion References: <20120111163717.591B021F87EF@ietfa.amsl.com> In-Reply-To: <20120111163717.591B021F87EF@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 11 Jan 2012 13:33:12 -0800 Cc: jouni.korhonen@nsn.com, lionel.morand@orange-ftgroup.com, dime@ietf.org, iesg@ietf.org Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions (dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 17:32:01 -0000 Hi, During the IESG internal review of this I asked whether or not there was interest in trying to tackle end to end security for AVPs. I do know there is at least some interest in that but its not clear there's enough to warrant including it in the re-charter so I said I'd ask when the recharter went out for review... So - anyone interested in DIME solving that problem? (And willing and able to help do the work of course.) As of now, Diameter really only has hop-by-hop security which is ok in many cases but far from ideal (wearing my security hat) in some. Thanks, Stephen. On 01/11/2012 04:37 PM, IESG Secretary wrote: > A modified charter has been submitted for the Diameter Maintenance and > Extensions (dime) working group in the Operations and Management Area of > the IETF. The IESG has not made any determination as yet. The modified > charter is provided below for informational purposes only. Please send > your comments to the IESG mailing list (iesg@ietf.org) by Wednesday, > January 18, 2012. > > Diameter Maintenance and Extensions (dime) > ----------------------------------------- > Current Status: Active > > Last Modified: 2012-01-10 > > Chairs: > Lionel Morand > Jouni Korhonen > > Operations and Management Area Directors: > Dan Romascanu > Ronald Bonica > > Operations and Management Area Advisor: > Dan Romascanu > > Mailing Lists: > General Discussion: dime@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/dime > Archive: > http://www.ietf.org/mail-archive/web/dime/current/maillist.html > > Description of Working Group: > > The Diameter Maintenance and Extensions WG will focus on maintenance and > extensions to the Diameter protocol required to enable its use for > authentication, authorization, accounting, charging in network access, > provisioning of configuration information within the network, and for > new AAA session management uses within the extensibility rules of the > Diameter base protocol. > > The DIME working group plans to address the following items: > > - Maintaining and/or progressing, along the standards track, the > Diameter Base protocol and Diameter Applications. This includes > extensions to Diameter Base protocol that can be considered as enhanced > features or bug fixes. > > - Diameter application design guideline. This document will provide > guidelines for design of Diameter extensions. It will detail when to > consider reusing an existing application and when to develop a new > application. > > - Protocol extensions for the management of Diameter entities. This work > focuses on the standardization of Management Information Bases (MIBs) to > configure Diameter entities (such as the Diameter Base protocol or > Diameter Credit Control nodes). The usage of other management protocols > for configuring Diameter entities may be future work within the group. > > - Protocol extensions for bulk and grouped AAA session management. The > aim of this work is to study and standardize a solution for handling > groups of AAA sessions within the Diameter base protocol context. The > solution would define how to identify and handle grouped AAA sessions in > commands and operations. > > Additionally, Diameter-based systems require interoperability in order > to work. The working group, along with the AD, will need to evaluate any > potential extensions and require verification that the proposed > extension is needed, and is within the extensibility rules of Diameter > and AAA scope. Coordination with other IETF working groups and other > SDOs (e.g. 3GPP) will be used to ensure this. > > Goals and Milestones: > > Done - Submit the following two Diameter Mobility documents to the > IESG for consideration as a Proposed Standards:* 'Diameter > Mobile IPv6: Support for Home Agent to Diameter Server > Interaction' * 'Diameter Mobile IPv6: Support for Network > Access Server to Diameter Server Interaction' > Done - Submit 'Diameter API' to the IESG for consideration as an > Informational RFC > Done - Submit 'Quality of Service Parameters for Usage with > Diameter' to the IESG for consideration as a Proposed > Standard. > Done - Submit 'Diameter QoS Application' to the IESG for > consideration as a Proposed Standard > Done - Submit 'Diameter Support for EAP Re-authentication > Protocol' as DIME working group item > Done - Submit 'Diameter User-Name and Realm Based Request Routing > Clarifications' as DIME working group item > Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working group > item > Done - Submit 'Quality of Service Attributes for Diameter' to the > IESG for consideration as a Proposed Standard > Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for > consideration as a Proposed Standard > Done - Submit 'Diameter User-Name and Realm Based Request Routing > Clarifications' to the IESG for consideration as a Proposed > Standard > Done - Submit 'Diameter NAT Control Application' as DIME working > group item > Done - Submit 'Diameter Capabilities Update' as DIME working group > item > Done - Submit 'Diameter Credit Control Application MIB' to the > IESG for consideration as an Informational RFC > Done - Submit 'Diameter Base Protocol MIB' to the IESG for > consideration as an Informational RFC > Done - Submit 'Diameter Capabilities Update' to the IESG for > consideration as a Proposed Standard > Done - Submit 'Diameter Extended NAPTR' as DIME working group item > Done - Submit 'Realm-Based Redirection In Diameter' as DIME > working group item > Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized > Routing' as DIME working group item > Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic > Key Transport' as DIME working group item > Done - Submit 'Diameter Priority Attribute Value Pairs' as DIME > working group item > Done - Submit 'Diameter IKEv2 PSK' as DIME working group item > Done - Submit Revision of 'Diameter Base Protocol' to the IESG for > consideration as a Proposed Standard > Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic > Key Transport' to the IESG for consideration as a Proposed > Standard > Done - Submit 'Diameter Priority Attribute Value Pairs' to the > IESG for consideration as a Proposed Standard > Done - Submit Revision of 'Diameter Network Access Server > Application - RFC 4005bis' as DIME working group item > Done - Submit 'Diameter NAT Control Application' to the IESG for > consideration as a Proposed Standard > Done - Submit 'Diameter IKEv2 PSK' to the IESG for consideration > as a Proposed Standard > Done - Submit 'Diameter Extended NAPTR' to the IESG for > consideration as a Proposed Standard > Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized > Routing' to the IESG for consideration as a Proposed > Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the IESG > for consideration as a Proposed Standard > Mar 2012 - Submit Revision of 'Diameter Network Access Server > Application - RFC 4005bis' to the IESG for consideration as a > Proposed Standard > May 2012 - Submit 'Diameter Application Design Guidelines' to the IESG > for consideration as a BCP document Standard > Jul 2012 - Submit 'Diameter Support for EAP Re-authentication > Protocol' to the IESG for consideration as a Proposed > Standard > Aug 2012 - Submit a document on 'Protocol extension for bulk and group > signaling' as a working group item > Aug 2013 - Submit a document on 'Protocol extension for bulk and group > signaling' to the IESG for consideration as a Proposed > Standard > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > From glenzorn@gmail.com Wed Jan 11 22:32:58 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E55021F8508 for ; Wed, 11 Jan 2012 22:32:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 SmydhVl4IY14 for ; Wed, 11 Jan 2012 22:32:57 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD6C21F8505 for ; Wed, 11 Jan 2012 22:32:57 -0800 (PST) Received: by iaae16 with SMTP id e16so2143269iaa.31 for ; Wed, 11 Jan 2012 22:32:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=LJyBi1+Ef2MvSy2m9cUhfjIlf7W6+FRyhGKxx3RHDSI=; b=KGKkorSoW1UAdWBN5QCijIYeWp7odX+goQJT0V8W+oXH4BMG1de0iScv6nyH1gYSBq GlEa/HLgQ+zMVpTo40Zpx3YeMa34ZWEHcKlnvXNPqmaBkNidc4/JuhJN3+qxsn0rwa7Q DF535Ht34gb1k8/4Z2xR8cs+m8JG+MTCzBxOY= Received: by 10.50.195.227 with SMTP id ih3mr2350264igc.19.1326349977008; Wed, 11 Jan 2012 22:32:57 -0800 (PST) Received: from [192.168.1.98] (ppp-115-87-126-215.revip4.asianet.co.th. [115.87.126.215]) by mx.google.com with ESMTPS id 36sm13797699ibc.6.2012.01.11.22.32.54 (version=SSLv3 cipher=OTHER); Wed, 11 Jan 2012 22:32:55 -0800 (PST) Message-ID: <4F0E7E94.7060503@gmail.com> Date: Thu, 12 Jan 2012 13:32:52 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Tom Taylor References: <4F09FA77.5020301@gmail.com> <4F0A909A.2030705@gmail.com> <4F0B7ECB.5040006@gmail.com> <4F0D69BA.7070907@gmail.com> <4F0DB63E.3010800@gmail.com> In-Reply-To: <4F0DB63E.3010800@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dime@ietf.org" Subject: Re: [Dime] Would realm-based redirection be a protocol error or an application error? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 06:32:58 -0000 On 1/11/2012 11:18 PM, Tom Taylor wrote: > I won't argue the point further. Section 7 is undoubtedly not the most > authoritative section of the RFC, and I probably misinterpreted the > text. It's just that when I saw it I thought there were subtleties to > Diameter that I wasn't aware of, and I'd better take them into account. That's fine; nevertheless, it seems to me that a section that can give rise to two such wildly disparate interpretations to at least require clarification, no? ... From lionel.morand@orange.com Thu Jan 12 01:26:34 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0FAB21F84D4; Thu, 12 Jan 2012 01:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.174 X-Spam-Level: X-Spam-Status: No, score=-6.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 ayau2eQSdqlQ; Thu, 12 Jan 2012 01:26:34 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 722AD21F84D6; Thu, 12 Jan 2012 01:26:33 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BC4E4A441AB; Thu, 12 Jan 2012 10:27:57 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id AE07AA441AA; Thu, 12 Jan 2012 10:27:57 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Jan 2012 10:26:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Jan 2012 10:25:16 +0100 Message-ID: In-Reply-To: <4F0DC78D.2010809@cs.tcd.ie> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] WG Review: Recharter of Diameter Maintenance andExtensions (dime) Thread-Index: AczQqKKC8/aVVhX8RdOvAsOHSUKYDwAYwcMA References: <20120111163717.591B021F87EF@ietfa.amsl.com> <4F0DC78D.2010809@cs.tcd.ie> From: To: , X-OriginalArrivalTime: 12 Jan 2012 09:26:30.0875 (UTC) FILETIME=[44AAAAB0:01CCD10C] Cc: jouni.korhonen@nsn.com, dime@ietf.org, iesg@ietf.org Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance andExtensions (dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 09:26:34 -0000 Hi Stephen, I confirm that there is an interest and this interest is increasing. Now, not sure that I'm the best candidate to lead this work even if I = can help. We will see if there is more support that would motivate to put it right = now in the charter. Regards, Lionel -----Message d'origine----- De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de Stephen Farrell Envoy=E9=A0: mercredi 11 janvier 2012 18:32 =C0=A0: IETF-Discussion Cc=A0: jouni.korhonen@nsn.com; MORAND Lionel RD-CORE-ISS; dime@ietf.org; = iesg@ietf.org Objet=A0: Re: [Dime] WG Review: Recharter of Diameter Maintenance = andExtensions (dime) Hi, During the IESG internal review of this I asked whether or not there was interest in trying to tackle end to end security for AVPs. I do know there is at least some interest in that but its not clear there's enough to warrant including it in the re-charter so I said I'd ask when the recharter went out for review... So - anyone interested in DIME solving that problem? (And willing and able to help do the work of course.) As of now, Diameter really only has hop-by-hop security which is ok in many cases but far from ideal (wearing my security hat) in some. Thanks, Stephen. On 01/11/2012 04:37 PM, IESG Secretary wrote: > A modified charter has been submitted for the Diameter Maintenance and > Extensions (dime) working group in the Operations and Management Area = of > the IETF. The IESG has not made any determination as yet. The = modified > charter is provided below for informational purposes only. Please = send > your comments to the IESG mailing list (iesg@ietf.org) by Wednesday, > January 18, 2012. > > Diameter Maintenance and Extensions (dime) > ----------------------------------------- > Current Status: Active > > Last Modified: 2012-01-10 > > Chairs: > Lionel Morand > Jouni Korhonen > > Operations and Management Area Directors: > Dan Romascanu > Ronald Bonica > > Operations and Management Area Advisor: > Dan Romascanu > > Mailing Lists: > General Discussion: dime@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/dime > Archive: > http://www.ietf.org/mail-archive/web/dime/current/maillist.html > > Description of Working Group: > > The Diameter Maintenance and Extensions WG will focus on maintenance = and > extensions to the Diameter protocol required to enable its use for > authentication, authorization, accounting, charging in network access, > provisioning of configuration information within the network, and for > new AAA session management uses within the extensibility rules of the > Diameter base protocol. > > The DIME working group plans to address the following items: > > - Maintaining and/or progressing, along the standards track, the > Diameter Base protocol and Diameter Applications. This includes > extensions to Diameter Base protocol that can be considered as = enhanced > features or bug fixes. > > - Diameter application design guideline. This document will provide > guidelines for design of Diameter extensions. It will detail when to > consider reusing an existing application and when to develop a new > application. > > - Protocol extensions for the management of Diameter entities. This = work > focuses on the standardization of Management Information Bases (MIBs) = to > configure Diameter entities (such as the Diameter Base protocol or > Diameter Credit Control nodes). The usage of other management = protocols > for configuring Diameter entities may be future work within the group. > > - Protocol extensions for bulk and grouped AAA session management. The > aim of this work is to study and standardize a solution for handling > groups of AAA sessions within the Diameter base protocol context. The > solution would define how to identify and handle grouped AAA sessions = in > commands and operations. > > Additionally, Diameter-based systems require interoperability in order > to work. The working group, along with the AD, will need to evaluate = any > potential extensions and require verification that the proposed > extension is needed, and is within the extensibility rules of Diameter > and AAA scope. Coordination with other IETF working groups and other > SDOs (e.g. 3GPP) will be used to ensure this. > > Goals and Milestones: > > Done - Submit the following two Diameter Mobility documents to the > IESG for consideration as a Proposed Standards:* 'Diameter > Mobile IPv6: Support for Home Agent to Diameter Server > Interaction' * 'Diameter Mobile IPv6: Support for Network > Access Server to Diameter Server Interaction' > Done - Submit 'Diameter API' to the IESG for consideration as an > Informational RFC > Done - Submit 'Quality of Service Parameters for Usage with > Diameter' to the IESG for consideration as a Proposed > Standard. > Done - Submit 'Diameter QoS Application' to the IESG for > consideration as a Proposed Standard > Done - Submit 'Diameter Support for EAP Re-authentication > Protocol' as DIME working group item > Done - Submit 'Diameter User-Name and Realm Based Request Routing > Clarifications' as DIME working group item > Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working group > item > Done - Submit 'Quality of Service Attributes for Diameter' to the > IESG for consideration as a Proposed Standard > Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for > consideration as a Proposed Standard > Done - Submit 'Diameter User-Name and Realm Based Request Routing > Clarifications' to the IESG for consideration as a = Proposed > Standard > Done - Submit 'Diameter NAT Control Application' as DIME working > group item > Done - Submit 'Diameter Capabilities Update' as DIME working group > item > Done - Submit 'Diameter Credit Control Application MIB' to the > IESG for consideration as an Informational RFC > Done - Submit 'Diameter Base Protocol MIB' to the IESG for > consideration as an Informational RFC > Done - Submit 'Diameter Capabilities Update' to the IESG for > consideration as a Proposed Standard > Done - Submit 'Diameter Extended NAPTR' as DIME working group item > Done - Submit 'Realm-Based Redirection In Diameter' as DIME > working group item > Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized > Routing' as DIME working group item > Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic > Key Transport' as DIME working group item > Done - Submit 'Diameter Priority Attribute Value Pairs' as DIME > working group item > Done - Submit 'Diameter IKEv2 PSK' as DIME working group item > Done - Submit Revision of 'Diameter Base Protocol' to the IESG for > consideration as a Proposed Standard > Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic > Key Transport' to the IESG for consideration as a Proposed > Standard > Done - Submit 'Diameter Priority Attribute Value Pairs' to the > IESG for consideration as a Proposed Standard > Done - Submit Revision of 'Diameter Network Access Server > Application - RFC 4005bis' as DIME working group item > Done - Submit 'Diameter NAT Control Application' to the IESG for > consideration as a Proposed Standard > Done - Submit 'Diameter IKEv2 PSK' to the IESG for consideration > as a Proposed Standard > Done - Submit 'Diameter Extended NAPTR' to the IESG for > consideration as a Proposed Standard > Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized > Routing' to the IESG for consideration as a Proposed > Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the IESG > for consideration as a Proposed Standard > Mar 2012 - Submit Revision of 'Diameter Network Access Server > Application - RFC 4005bis' to the IESG for consideration = as a > Proposed Standard > May 2012 - Submit 'Diameter Application Design Guidelines' to the IESG > for consideration as a BCP document Standard > Jul 2012 - Submit 'Diameter Support for EAP Re-authentication > Protocol' to the IESG for consideration as a Proposed > Standard > Aug 2012 - Submit a document on 'Protocol extension for bulk and group > signaling' as a working group item > Aug 2013 - Submit a document on 'Protocol extension for bulk and group > signaling' to the IESG for consideration as a Proposed > Standard > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Thu Jan 12 04:08:17 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E68C21F85C6; Thu, 12 Jan 2012 04:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 7F0p7xcyJMKG; Thu, 12 Jan 2012 04:08:16 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id CB3DF21F84B2; Thu, 12 Jan 2012 04:08:15 -0800 (PST) Received: by wibhj6 with SMTP id hj6so1445113wib.31 for ; Thu, 12 Jan 2012 04:08:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=EnBnRiaOfXA8RWsKwUn9oFklN8M9OqgjabcvTdPe7Uw=; b=qGEQXAGUunpJmVkvUMt8JI/+IZcoFLc6UP4JoxU4dEbn3atlrgGCcgWIRj6IHf11z6 073ERBCDiwj7pxQF5whFDiWDUrpOdXw649/eRuPxzgS/sq4dj3LsG8dWtGBhehyC8+Of cbcaW185fHwTATmb75/aiq+RIh7rMhuAohavI= Received: by 10.180.99.225 with SMTP id et1mr938552wib.2.1326370093913; Thu, 12 Jan 2012 04:08:13 -0800 (PST) Received: from [10.255.133.241] ([192.100.123.77]) by mx.google.com with ESMTPS id 1sm8591897wiz.11.2012.01.12.04.08.11 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Jan 2012 04:08:12 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4F0DC78D.2010809@cs.tcd.ie> Date: Thu, 12 Jan 2012 14:08:08 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <20120111163717.591B021F87EF@ietfa.amsl.com> <4F0DC78D.2010809@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1084) Cc: jouni.korhonen@nsn.com, lionel.morand@orange-ftgroup.com, dime@ietf.org, IETF-Discussion , iesg@ietf.org Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions (dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 12:08:17 -0000 Stephen, This topic raises its head every now and then when a Dime document arrives at IESG ;) Apart from that there has been very little serious public discussion about it recently, for some unknown reason to me. A detail worth pointing out is that the support for the End-to-End security framework (E2E-Sequence AVP and 'P'-bit in the AVP header) has been deprecated in RFC3588bis (now in IESG). So we are "free" to start from scratch. If there is enough serious energy and vision for pursuing end-to-end security, I do not see current proposed charter text prohibiting it: "- Maintaining and/or progressing, along the standards track, the Diameter Base protocol and Diameter Applications. This includes extensions to Diameter Base protocol that can be considered as enhanced features or bug fixes." I would argue the end-to-end security is an enhanced feature for Diameter base protocol that fixes a serious bug/flaw in security. On the other hand, if an explicit note is needed about this topic in the charter, I might hesitate to include such in this round. I would first like to see some concrete movement & work around this topic. - Jouni On Jan 11, 2012, at 7:31 PM, Stephen Farrell wrote: > > Hi, > > During the IESG internal review of this I asked whether > or not there was interest in trying to tackle end to > end security for AVPs. I do know there is at least some > interest in that but its not clear there's enough to > warrant including it in the re-charter so I said I'd > ask when the recharter went out for review... > > So - anyone interested in DIME solving that problem? > (And willing and able to help do the work of course.) > > As of now, Diameter really only has hop-by-hop security > which is ok in many cases but far from ideal (wearing > my security hat) in some. > > Thanks, > Stephen. > > On 01/11/2012 04:37 PM, IESG Secretary wrote: >> A modified charter has been submitted for the Diameter Maintenance and >> Extensions (dime) working group in the Operations and Management Area of >> the IETF. The IESG has not made any determination as yet. The modified >> charter is provided below for informational purposes only. Please send >> your comments to the IESG mailing list (iesg@ietf.org) by Wednesday, >> January 18, 2012. >> >> Diameter Maintenance and Extensions (dime) >> ----------------------------------------- >> Current Status: Active >> >> Last Modified: 2012-01-10 >> >> Chairs: >> Lionel Morand >> Jouni Korhonen >> >> Operations and Management Area Directors: >> Dan Romascanu >> Ronald Bonica >> >> Operations and Management Area Advisor: >> Dan Romascanu >> >> Mailing Lists: >> General Discussion: dime@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/dime >> Archive: >> http://www.ietf.org/mail-archive/web/dime/current/maillist.html >> >> Description of Working Group: >> >> The Diameter Maintenance and Extensions WG will focus on maintenance and >> extensions to the Diameter protocol required to enable its use for >> authentication, authorization, accounting, charging in network access, >> provisioning of configuration information within the network, and for >> new AAA session management uses within the extensibility rules of the >> Diameter base protocol. >> >> The DIME working group plans to address the following items: >> >> - Maintaining and/or progressing, along the standards track, the >> Diameter Base protocol and Diameter Applications. This includes >> extensions to Diameter Base protocol that can be considered as enhanced >> features or bug fixes. >> >> - Diameter application design guideline. This document will provide >> guidelines for design of Diameter extensions. It will detail when to >> consider reusing an existing application and when to develop a new >> application. >> >> - Protocol extensions for the management of Diameter entities. This work >> focuses on the standardization of Management Information Bases (MIBs) to >> configure Diameter entities (such as the Diameter Base protocol or >> Diameter Credit Control nodes). The usage of other management protocols >> for configuring Diameter entities may be future work within the group. >> >> - Protocol extensions for bulk and grouped AAA session management. The >> aim of this work is to study and standardize a solution for handling >> groups of AAA sessions within the Diameter base protocol context. The >> solution would define how to identify and handle grouped AAA sessions in >> commands and operations. >> >> Additionally, Diameter-based systems require interoperability in order >> to work. The working group, along with the AD, will need to evaluate any >> potential extensions and require verification that the proposed >> extension is needed, and is within the extensibility rules of Diameter >> and AAA scope. Coordination with other IETF working groups and other >> SDOs (e.g. 3GPP) will be used to ensure this. >> >> Goals and Milestones: >> >> Done - Submit the following two Diameter Mobility documents to the >> IESG for consideration as a Proposed Standards:* 'Diameter >> Mobile IPv6: Support for Home Agent to Diameter Server >> Interaction' * 'Diameter Mobile IPv6: Support for Network >> Access Server to Diameter Server Interaction' >> Done - Submit 'Diameter API' to the IESG for consideration as an >> Informational RFC >> Done - Submit 'Quality of Service Parameters for Usage with >> Diameter' to the IESG for consideration as a Proposed >> Standard. >> Done - Submit 'Diameter QoS Application' to the IESG for >> consideration as a Proposed Standard >> Done - Submit 'Diameter Support for EAP Re-authentication >> Protocol' as DIME working group item >> Done - Submit 'Diameter User-Name and Realm Based Request Routing >> Clarifications' as DIME working group item >> Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working group >> item >> Done - Submit 'Quality of Service Attributes for Diameter' to the >> IESG for consideration as a Proposed Standard >> Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for >> consideration as a Proposed Standard >> Done - Submit 'Diameter User-Name and Realm Based Request Routing >> Clarifications' to the IESG for consideration as a Proposed >> Standard >> Done - Submit 'Diameter NAT Control Application' as DIME working >> group item >> Done - Submit 'Diameter Capabilities Update' as DIME working group >> item >> Done - Submit 'Diameter Credit Control Application MIB' to the >> IESG for consideration as an Informational RFC >> Done - Submit 'Diameter Base Protocol MIB' to the IESG for >> consideration as an Informational RFC >> Done - Submit 'Diameter Capabilities Update' to the IESG for >> consideration as a Proposed Standard >> Done - Submit 'Diameter Extended NAPTR' as DIME working group item >> Done - Submit 'Realm-Based Redirection In Diameter' as DIME >> working group item >> Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized >> Routing' as DIME working group item >> Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic >> Key Transport' as DIME working group item >> Done - Submit 'Diameter Priority Attribute Value Pairs' as DIME >> working group item >> Done - Submit 'Diameter IKEv2 PSK' as DIME working group item >> Done - Submit Revision of 'Diameter Base Protocol' to the IESG for >> consideration as a Proposed Standard >> Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic >> Key Transport' to the IESG for consideration as a Proposed >> Standard >> Done - Submit 'Diameter Priority Attribute Value Pairs' to the >> IESG for consideration as a Proposed Standard >> Done - Submit Revision of 'Diameter Network Access Server >> Application - RFC 4005bis' as DIME working group item >> Done - Submit 'Diameter NAT Control Application' to the IESG for >> consideration as a Proposed Standard >> Done - Submit 'Diameter IKEv2 PSK' to the IESG for consideration >> as a Proposed Standard >> Done - Submit 'Diameter Extended NAPTR' to the IESG for >> consideration as a Proposed Standard >> Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized >> Routing' to the IESG for consideration as a Proposed >> Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the IESG >> for consideration as a Proposed Standard >> Mar 2012 - Submit Revision of 'Diameter Network Access Server >> Application - RFC 4005bis' to the IESG for consideration as a >> Proposed Standard >> May 2012 - Submit 'Diameter Application Design Guidelines' to the IESG >> for consideration as a BCP document Standard >> Jul 2012 - Submit 'Diameter Support for EAP Re-authentication >> Protocol' to the IESG for consideration as a Proposed >> Standard >> Aug 2012 - Submit a document on 'Protocol extension for bulk and group >> signaling' as a working group item >> Aug 2013 - Submit a document on 'Protocol extension for bulk and group >> signaling' to the IESG for consideration as a Proposed >> Standard >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce >> > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From dromasca@avaya.com Thu Jan 12 04:16:02 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAFCB21F8528; Thu, 12 Jan 2012 04:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.763 X-Spam-Level: X-Spam-Status: No, score=-102.763 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Jcyv4sZsXhSZ; Thu, 12 Jan 2012 04:16:01 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 60A7921F8545; Thu, 12 Jan 2012 04:16:01 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHzNDk/GmAcF/2dsb2JhbAA5Cq0GgQWBcgEBAQECAQEBAQ8eCjQLDAQCAQgNBAQBAQEKAgQMCwEGASYfCQgBAQQBEggBEgeHWAicNJsdiGCCWmMEmn+MSw X-IronPort-AV: E=Sophos;i="4.71,497,1320642000"; d="scan'208";a="226393410" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 12 Jan 2012 07:16:00 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 12 Jan 2012 07:11:34 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Jan 2012 13:15:57 +0100 Message-ID: In-Reply-To: <4F0ECE57.3020900@cs.tcd.ie> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Recharter of Diameter Maintenance and Extensions (dime) Thread-Index: AczRI5OWhvhx1Pj+R2SNnGslpuoTlwAACHUQ References: <20120111163717.591B021F87EF@ietfa.amsl.com><4F0DC78D.2010809@cs.tcd.ie> <4F0ECE57.3020900@cs.tcd.ie> From: "Romascanu, Dan (Dan)" To: "Stephen Farrell" , "jouni korhonen" Cc: jouni.korhonen@nsn.com, lionel.morand@orange-ftgroup.com, dime@ietf.org, IETF-Discussion , iesg@ietf.org Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions (dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 12:16:02 -0000 Hi, If a number of hands were raised now and the folks commanding them say 'we are ready to work on this NOW' I would support including explicit wording in the charter. If this does not happen until the telechat next week the current text is good enough to allow interested people to start working on contributions that can be individual submissions. If these submissions are consistent enough the WG can add the milestone later in the charter and adopt the submissions as WG items.=20 Dan > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of > Stephen Farrell > Sent: Thursday, January 12, 2012 2:13 PM > To: jouni korhonen > Cc: jouni.korhonen@nsn.com; lionel.morand@orange-ftgroup.com; > dime@ietf.org; IETF-Discussion; iesg@ietf.org > Subject: Re: WG Review: Recharter of Diameter Maintenance and > Extensions (dime) >=20 >=20 > Hi Jouni, >=20 > Right, I'm trying to encourage this - I'm not trying > to make it a gating function for the recharter. Its > still worth doing though if we can find some victims > with enough energy:-) >=20 > I agree that the current charter text might not need > to be modified, OTOH, if there were folks who wanted to > do the work, a milestone might be good. I also agree > that as of now, that addition is not warranted. >=20 > Cheers, > S >=20 > On 01/12/2012 12:08 PM, jouni korhonen wrote: > > > > Stephen, > > > > This topic raises its head every now and then when a Dime > > document arrives at IESG ;) Apart from that there has been > > very little serious public discussion about it recently, > > for some unknown reason to me. A detail worth pointing out > > is that the support for the End-to-End security framework > > (E2E-Sequence AVP and 'P'-bit in the AVP header) has been > > deprecated in RFC3588bis (now in IESG). So we are "free" > > to start from scratch. > > > > If there is enough serious energy and vision for pursuing > > end-to-end security, I do not see current proposed charter > > text prohibiting it: > > > > "- Maintaining and/or progressing, along the standards track, the > > Diameter Base protocol and Diameter Applications. This includes > > extensions to Diameter Base protocol that can be considered as > > enhanced features or bug fixes." > > > > I would argue the end-to-end security is an enhanced feature for > > Diameter base protocol that fixes a serious bug/flaw in security. > > On the other hand, if an explicit note is needed about this topic > > in the charter, I might hesitate to include such in this round. > > I would first like to see some concrete movement& work around > > this topic. > > > > - Jouni > > > > > > > > On Jan 11, 2012, at 7:31 PM, Stephen Farrell wrote: > > > >> > >> Hi, > >> > >> During the IESG internal review of this I asked whether > >> or not there was interest in trying to tackle end to > >> end security for AVPs. I do know there is at least some > >> interest in that but its not clear there's enough to > >> warrant including it in the re-charter so I said I'd > >> ask when the recharter went out for review... > >> > >> So - anyone interested in DIME solving that problem? > >> (And willing and able to help do the work of course.) > >> > >> As of now, Diameter really only has hop-by-hop security > >> which is ok in many cases but far from ideal (wearing > >> my security hat) in some. > >> > >> Thanks, > >> Stephen. > >> > >> On 01/11/2012 04:37 PM, IESG Secretary wrote: > >>> A modified charter has been submitted for the Diameter Maintenance > and > >>> Extensions (dime) working group in the Operations and Management > Area of > >>> the IETF. The IESG has not made any determination as yet. The > modified > >>> charter is provided below for informational purposes only. Please > send > >>> your comments to the IESG mailing list (iesg@ietf.org) by > Wednesday, > >>> January 18, 2012. > >>> > >>> Diameter Maintenance and Extensions (dime) > >>> ----------------------------------------- > >>> Current Status: Active > >>> > >>> Last Modified: 2012-01-10 > >>> > >>> Chairs: > >>> Lionel Morand > >>> Jouni Korhonen > >>> > >>> Operations and Management Area Directors: > >>> Dan Romascanu > >>> Ronald Bonica > >>> > >>> Operations and Management Area Advisor: > >>> Dan Romascanu > >>> > >>> Mailing Lists: > >>> General Discussion: dime@ietf.org > >>> To Subscribe: https://www.ietf.org/mailman/listinfo/dime > >>> Archive: > >>> http://www.ietf.org/mail-archive/web/dime/current/maillist.html > >>> > >>> Description of Working Group: > >>> > >>> The Diameter Maintenance and Extensions WG will focus on > maintenance and > >>> extensions to the Diameter protocol required to enable its use for > >>> authentication, authorization, accounting, charging in network > access, > >>> provisioning of configuration information within the network, and > for > >>> new AAA session management uses within the extensibility rules of > the > >>> Diameter base protocol. > >>> > >>> The DIME working group plans to address the following items: > >>> > >>> - Maintaining and/or progressing, along the standards track, the > >>> Diameter Base protocol and Diameter Applications. This includes > >>> extensions to Diameter Base protocol that can be considered as > enhanced > >>> features or bug fixes. > >>> > >>> - Diameter application design guideline. This document will provide > >>> guidelines for design of Diameter extensions. It will detail when > to > >>> consider reusing an existing application and when to develop a new > >>> application. > >>> > >>> - Protocol extensions for the management of Diameter entities. This > work > >>> focuses on the standardization of Management Information Bases > (MIBs) to > >>> configure Diameter entities (such as the Diameter Base protocol or > >>> Diameter Credit Control nodes). The usage of other management > protocols > >>> for configuring Diameter entities may be future work within the > group. > >>> > >>> - Protocol extensions for bulk and grouped AAA session management. > The > >>> aim of this work is to study and standardize a solution for > handling > >>> groups of AAA sessions within the Diameter base protocol context. > The > >>> solution would define how to identify and handle grouped AAA > sessions in > >>> commands and operations. > >>> > >>> Additionally, Diameter-based systems require interoperability in > order > >>> to work. The working group, along with the AD, will need to > evaluate any > >>> potential extensions and require verification that the proposed > >>> extension is needed, and is within the extensibility rules of > Diameter > >>> and AAA scope. Coordination with other IETF working groups and > other > >>> SDOs (e.g. 3GPP) will be used to ensure this. > >>> > >>> Goals and Milestones: > >>> > >>> Done - Submit the following two Diameter Mobility documents to > the > >>> IESG for consideration as a Proposed Standards:* > 'Diameter > >>> Mobile IPv6: Support for Home Agent to Diameter Server > >>> Interaction' * 'Diameter Mobile IPv6: Support for > Network > >>> Access Server to Diameter Server Interaction' > >>> Done - Submit 'Diameter API' to the IESG for consideration as > an > >>> Informational RFC > >>> Done - Submit 'Quality of Service Parameters for Usage with > >>> Diameter' to the IESG for consideration as a Proposed > >>> Standard. > >>> Done - Submit 'Diameter QoS Application' to the IESG for > >>> consideration as a Proposed Standard > >>> Done - Submit 'Diameter Support for EAP Re-authentication > >>> Protocol' as DIME working group item > >>> Done - Submit 'Diameter User-Name and Realm Based Request > Routing > >>> Clarifications' as DIME working group item > >>> Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working > group > >>> item > >>> Done - Submit 'Quality of Service Attributes for Diameter' to > the > >>> IESG for consideration as a Proposed Standard > >>> Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for > >>> consideration as a Proposed Standard > >>> Done - Submit 'Diameter User-Name and Realm Based Request > Routing > >>> Clarifications' to the IESG for consideration as a > Proposed > >>> Standard > >>> Done - Submit 'Diameter NAT Control Application' as DIME > working > >>> group item > >>> Done - Submit 'Diameter Capabilities Update' as DIME working > group > >>> item > >>> Done - Submit 'Diameter Credit Control Application MIB' to the > >>> IESG for consideration as an Informational RFC > >>> Done - Submit 'Diameter Base Protocol MIB' to the IESG for > >>> consideration as an Informational RFC > >>> Done - Submit 'Diameter Capabilities Update' to the IESG for > >>> consideration as a Proposed Standard > >>> Done - Submit 'Diameter Extended NAPTR' as DIME working group > item > >>> Done - Submit 'Realm-Based Redirection In Diameter' as DIME > >>> working group item > >>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized > >>> Routing' as DIME working group item > >>> Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic > >>> Key Transport' as DIME working group item > >>> Done - Submit 'Diameter Priority Attribute Value Pairs' as DIME > >>> working group item > >>> Done - Submit 'Diameter IKEv2 PSK' as DIME working group item > >>> Done - Submit Revision of 'Diameter Base Protocol' to the IESG > for > >>> consideration as a Proposed Standard > >>> Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic > >>> Key Transport' to the IESG for consideration as a > Proposed > >>> Standard > >>> Done - Submit 'Diameter Priority Attribute Value Pairs' to the > >>> IESG for consideration as a Proposed Standard > >>> Done - Submit Revision of 'Diameter Network Access Server > >>> Application - RFC 4005bis' as DIME working group item > >>> Done - Submit 'Diameter NAT Control Application' to the IESG > for > >>> consideration as a Proposed Standard > >>> Done - Submit 'Diameter IKEv2 PSK' to the IESG for > consideration > >>> as a Proposed Standard > >>> Done - Submit 'Diameter Extended NAPTR' to the IESG for > >>> consideration as a Proposed Standard > >>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized > >>> Routing' to the IESG for consideration as a Proposed > >>> Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the IESG > >>> for consideration as a Proposed Standard > >>> Mar 2012 - Submit Revision of 'Diameter Network Access Server > >>> Application - RFC 4005bis' to the IESG for > consideration as a > >>> Proposed Standard > >>> May 2012 - Submit 'Diameter Application Design Guidelines' to the > IESG > >>> for consideration as a BCP document Standard > >>> Jul 2012 - Submit 'Diameter Support for EAP Re-authentication > >>> Protocol' to the IESG for consideration as a Proposed > >>> Standard > >>> Aug 2012 - Submit a document on 'Protocol extension for bulk and > group > >>> signaling' as a working group item > >>> Aug 2013 - Submit a document on 'Protocol extension for bulk and > group > >>> signaling' to the IESG for consideration as a Proposed > >>> Standard > >>> _______________________________________________ > >>> IETF-Announce mailing list > >>> IETF-Announce@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ietf-announce > >>> > >> _______________________________________________ > >> Ietf mailing list > >> Ietf@ietf.org > >> https://www.ietf.org/mailman/listinfo/ietf > > From stephen.farrell@cs.tcd.ie Thu Jan 12 04:13:15 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E62321F8475; Thu, 12 Jan 2012 04:13:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.359 X-Spam-Level: X-Spam-Status: No, score=-102.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 yFUf-ualDbKv; Thu, 12 Jan 2012 04:13:14 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 1254F21F8528; Thu, 12 Jan 2012 04:13:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 1B4BC153FA1; Thu, 12 Jan 2012 12:13:13 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1326370392; bh=xh94EXIvsgItnn pCxpOlIq5yKLBujlOrxbc2QQ7dVF4=; b=php450/7S0YxqHUcWEwMi3whXwjjUN XNEC5oLJClGzzQajw4Wnpf9MzInmAEWxZ839NFG9gwRCf8gaQPOQvW0kagtR/LkI wbkGyeVXCPCRtwQbkJMmWluCHmTlvUOuDIbCE61/I6NdokNPogZT8z2hfq/y71al G/HDA8hOYJPYxwCLpQPyH3jTOPgQsPH8nGL/+lbTtK/ESSMxX/1YkrBHnmC9ARL1 eP6M5fjVsRiBU/+p7M86IpMLpPtwFYWUwNNtmhXCI5HLsGRObULhPxX1sxj2WgdB AYt7KnyMBvK3y3j5Grnsagp0yqQSzhydaMV60mfQMFA8eGQ48QJH1OBw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id JeOKSlkNCVNn; Thu, 12 Jan 2012 12:13:12 +0000 (GMT) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 10E8F171C77; Thu, 12 Jan 2012 12:13:12 +0000 (GMT) Message-ID: <4F0ECE57.3020900@cs.tcd.ie> Date: Thu, 12 Jan 2012 12:13:11 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: jouni korhonen References: <20120111163717.591B021F87EF@ietfa.amsl.com> <4F0DC78D.2010809@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 12 Jan 2012 04:33:31 -0800 Cc: jouni.korhonen@nsn.com, lionel.morand@orange-ftgroup.com, dime@ietf.org, IETF-Discussion , iesg@ietf.org Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions (dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 12:13:15 -0000 Hi Jouni, Right, I'm trying to encourage this - I'm not trying to make it a gating function for the recharter. Its still worth doing though if we can find some victims with enough energy:-) I agree that the current charter text might not need to be modified, OTOH, if there were folks who wanted to do the work, a milestone might be good. I also agree that as of now, that addition is not warranted. Cheers, S On 01/12/2012 12:08 PM, jouni korhonen wrote: > > Stephen, > > This topic raises its head every now and then when a Dime > document arrives at IESG ;) Apart from that there has been > very little serious public discussion about it recently, > for some unknown reason to me. A detail worth pointing out > is that the support for the End-to-End security framework > (E2E-Sequence AVP and 'P'-bit in the AVP header) has been > deprecated in RFC3588bis (now in IESG). So we are "free" > to start from scratch. > > If there is enough serious energy and vision for pursuing > end-to-end security, I do not see current proposed charter > text prohibiting it: > > "- Maintaining and/or progressing, along the standards track, the > Diameter Base protocol and Diameter Applications. This includes > extensions to Diameter Base protocol that can be considered as > enhanced features or bug fixes." > > I would argue the end-to-end security is an enhanced feature for > Diameter base protocol that fixes a serious bug/flaw in security. > On the other hand, if an explicit note is needed about this topic > in the charter, I might hesitate to include such in this round. > I would first like to see some concrete movement& work around > this topic. > > - Jouni > > > > On Jan 11, 2012, at 7:31 PM, Stephen Farrell wrote: > >> >> Hi, >> >> During the IESG internal review of this I asked whether >> or not there was interest in trying to tackle end to >> end security for AVPs. I do know there is at least some >> interest in that but its not clear there's enough to >> warrant including it in the re-charter so I said I'd >> ask when the recharter went out for review... >> >> So - anyone interested in DIME solving that problem? >> (And willing and able to help do the work of course.) >> >> As of now, Diameter really only has hop-by-hop security >> which is ok in many cases but far from ideal (wearing >> my security hat) in some. >> >> Thanks, >> Stephen. >> >> On 01/11/2012 04:37 PM, IESG Secretary wrote: >>> A modified charter has been submitted for the Diameter Maintenance and >>> Extensions (dime) working group in the Operations and Management Area of >>> the IETF. The IESG has not made any determination as yet. The modified >>> charter is provided below for informational purposes only. Please send >>> your comments to the IESG mailing list (iesg@ietf.org) by Wednesday, >>> January 18, 2012. >>> >>> Diameter Maintenance and Extensions (dime) >>> ----------------------------------------- >>> Current Status: Active >>> >>> Last Modified: 2012-01-10 >>> >>> Chairs: >>> Lionel Morand >>> Jouni Korhonen >>> >>> Operations and Management Area Directors: >>> Dan Romascanu >>> Ronald Bonica >>> >>> Operations and Management Area Advisor: >>> Dan Romascanu >>> >>> Mailing Lists: >>> General Discussion: dime@ietf.org >>> To Subscribe: https://www.ietf.org/mailman/listinfo/dime >>> Archive: >>> http://www.ietf.org/mail-archive/web/dime/current/maillist.html >>> >>> Description of Working Group: >>> >>> The Diameter Maintenance and Extensions WG will focus on maintenance and >>> extensions to the Diameter protocol required to enable its use for >>> authentication, authorization, accounting, charging in network access, >>> provisioning of configuration information within the network, and for >>> new AAA session management uses within the extensibility rules of the >>> Diameter base protocol. >>> >>> The DIME working group plans to address the following items: >>> >>> - Maintaining and/or progressing, along the standards track, the >>> Diameter Base protocol and Diameter Applications. This includes >>> extensions to Diameter Base protocol that can be considered as enhanced >>> features or bug fixes. >>> >>> - Diameter application design guideline. This document will provide >>> guidelines for design of Diameter extensions. It will detail when to >>> consider reusing an existing application and when to develop a new >>> application. >>> >>> - Protocol extensions for the management of Diameter entities. This work >>> focuses on the standardization of Management Information Bases (MIBs) to >>> configure Diameter entities (such as the Diameter Base protocol or >>> Diameter Credit Control nodes). The usage of other management protocols >>> for configuring Diameter entities may be future work within the group. >>> >>> - Protocol extensions for bulk and grouped AAA session management. The >>> aim of this work is to study and standardize a solution for handling >>> groups of AAA sessions within the Diameter base protocol context. The >>> solution would define how to identify and handle grouped AAA sessions in >>> commands and operations. >>> >>> Additionally, Diameter-based systems require interoperability in order >>> to work. The working group, along with the AD, will need to evaluate any >>> potential extensions and require verification that the proposed >>> extension is needed, and is within the extensibility rules of Diameter >>> and AAA scope. Coordination with other IETF working groups and other >>> SDOs (e.g. 3GPP) will be used to ensure this. >>> >>> Goals and Milestones: >>> >>> Done - Submit the following two Diameter Mobility documents to the >>> IESG for consideration as a Proposed Standards:* 'Diameter >>> Mobile IPv6: Support for Home Agent to Diameter Server >>> Interaction' * 'Diameter Mobile IPv6: Support for Network >>> Access Server to Diameter Server Interaction' >>> Done - Submit 'Diameter API' to the IESG for consideration as an >>> Informational RFC >>> Done - Submit 'Quality of Service Parameters for Usage with >>> Diameter' to the IESG for consideration as a Proposed >>> Standard. >>> Done - Submit 'Diameter QoS Application' to the IESG for >>> consideration as a Proposed Standard >>> Done - Submit 'Diameter Support for EAP Re-authentication >>> Protocol' as DIME working group item >>> Done - Submit 'Diameter User-Name and Realm Based Request Routing >>> Clarifications' as DIME working group item >>> Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working group >>> item >>> Done - Submit 'Quality of Service Attributes for Diameter' to the >>> IESG for consideration as a Proposed Standard >>> Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for >>> consideration as a Proposed Standard >>> Done - Submit 'Diameter User-Name and Realm Based Request Routing >>> Clarifications' to the IESG for consideration as a Proposed >>> Standard >>> Done - Submit 'Diameter NAT Control Application' as DIME working >>> group item >>> Done - Submit 'Diameter Capabilities Update' as DIME working group >>> item >>> Done - Submit 'Diameter Credit Control Application MIB' to the >>> IESG for consideration as an Informational RFC >>> Done - Submit 'Diameter Base Protocol MIB' to the IESG for >>> consideration as an Informational RFC >>> Done - Submit 'Diameter Capabilities Update' to the IESG for >>> consideration as a Proposed Standard >>> Done - Submit 'Diameter Extended NAPTR' as DIME working group item >>> Done - Submit 'Realm-Based Redirection In Diameter' as DIME >>> working group item >>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized >>> Routing' as DIME working group item >>> Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic >>> Key Transport' as DIME working group item >>> Done - Submit 'Diameter Priority Attribute Value Pairs' as DIME >>> working group item >>> Done - Submit 'Diameter IKEv2 PSK' as DIME working group item >>> Done - Submit Revision of 'Diameter Base Protocol' to the IESG for >>> consideration as a Proposed Standard >>> Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic >>> Key Transport' to the IESG for consideration as a Proposed >>> Standard >>> Done - Submit 'Diameter Priority Attribute Value Pairs' to the >>> IESG for consideration as a Proposed Standard >>> Done - Submit Revision of 'Diameter Network Access Server >>> Application - RFC 4005bis' as DIME working group item >>> Done - Submit 'Diameter NAT Control Application' to the IESG for >>> consideration as a Proposed Standard >>> Done - Submit 'Diameter IKEv2 PSK' to the IESG for consideration >>> as a Proposed Standard >>> Done - Submit 'Diameter Extended NAPTR' to the IESG for >>> consideration as a Proposed Standard >>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized >>> Routing' to the IESG for consideration as a Proposed >>> Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the IESG >>> for consideration as a Proposed Standard >>> Mar 2012 - Submit Revision of 'Diameter Network Access Server >>> Application - RFC 4005bis' to the IESG for consideration as a >>> Proposed Standard >>> May 2012 - Submit 'Diameter Application Design Guidelines' to the IESG >>> for consideration as a BCP document Standard >>> Jul 2012 - Submit 'Diameter Support for EAP Re-authentication >>> Protocol' to the IESG for consideration as a Proposed >>> Standard >>> Aug 2012 - Submit a document on 'Protocol extension for bulk and group >>> signaling' as a working group item >>> Aug 2013 - Submit a document on 'Protocol extension for bulk and group >>> signaling' to the IESG for consideration as a Proposed >>> Standard >>> _______________________________________________ >>> IETF-Announce mailing list >>> IETF-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf-announce >>> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf > From glenzorn@gmail.com Thu Jan 12 19:34:17 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5828521F859E; Thu, 12 Jan 2012 19:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 sqNhPfrep1dC; Thu, 12 Jan 2012 19:34:16 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id DF0AA21F859B; Thu, 12 Jan 2012 19:34:15 -0800 (PST) Received: by iaae16 with SMTP id e16so3753435iaa.31 for ; Thu, 12 Jan 2012 19:34:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=yapoY1WTAXLQYgPnCvtrT4mQLxCYG4XI8uyVSPCDp6A=; b=qXJffjI2sp//fowFfPRBOrTCrENukU4enRrYYCvqgxUsDHcnsEC7+i++3HfsMWfQ5q 2KszR+OzmCcgLi/MkOrkJhKMKJTQ2WiiHIJuKIvqdunNc1SPv5ucTkYzhd8xpPDWlvMM nrJ+C/m+75TEdOZ/1CLlFjiuoPtpK2U/E/cfs= Received: by 10.42.243.2 with SMTP id lk2mr1091229icb.8.1326425655372; Thu, 12 Jan 2012 19:34:15 -0800 (PST) Received: from [192.168.1.98] (ppp-124-122-159-242.revip2.asianet.co.th. [124.122.159.242]) by mx.google.com with ESMTPS id yg2sm4390880igb.1.2012.01.12.19.34.09 (version=SSLv3 cipher=OTHER); Thu, 12 Jan 2012 19:34:13 -0800 (PST) Message-ID: <4F0FA62D.4090808@gmail.com> Date: Fri, 13 Jan 2012 10:34:05 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <20120111163717.591B021F87EF@ietfa.amsl.com><4F0DC78D.2010809@cs.tcd.ie> <4F0ECE57.3020900@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF-Discussion , jouni.korhonen@nsn.com, lionel.morand@orange-ftgroup.com, dime@ietf.org, iesg@ietf.org, Stephen Farrell Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions (dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 03:34:17 -0000 On 1/12/2012 7:15 PM, Romascanu, Dan (Dan) wrote: > Hi, > > If a number of hands were raised now and the folks commanding them say > 'we are ready to work on this NOW' I would support including explicit > wording in the charter. Consider my hand raised. If this does not happen until the telechat next > week the current text is good enough to allow interested people to start > working on contributions that can be individual submissions. If these > submissions are consistent enough the WG can add the milestone later in > the charter and adopt the submissions as WG items. > > Dan > > > > > >> -----Original Message----- >> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf > Of >> Stephen Farrell >> Sent: Thursday, January 12, 2012 2:13 PM >> To: jouni korhonen >> Cc: jouni.korhonen@nsn.com; lionel.morand@orange-ftgroup.com; >> dime@ietf.org; IETF-Discussion; iesg@ietf.org >> Subject: Re: WG Review: Recharter of Diameter Maintenance and >> Extensions (dime) >> >> >> Hi Jouni, >> >> Right, I'm trying to encourage this - I'm not trying >> to make it a gating function for the recharter. Its >> still worth doing though if we can find some victims >> with enough energy:-) >> >> I agree that the current charter text might not need >> to be modified, OTOH, if there were folks who wanted to >> do the work, a milestone might be good. I also agree >> that as of now, that addition is not warranted. >> >> Cheers, >> S >> >> On 01/12/2012 12:08 PM, jouni korhonen wrote: >>> >>> Stephen, >>> >>> This topic raises its head every now and then when a Dime >>> document arrives at IESG ;) Apart from that there has been >>> very little serious public discussion about it recently, >>> for some unknown reason to me. A detail worth pointing out >>> is that the support for the End-to-End security framework >>> (E2E-Sequence AVP and 'P'-bit in the AVP header) has been >>> deprecated in RFC3588bis (now in IESG). So we are "free" >>> to start from scratch. >>> >>> If there is enough serious energy and vision for pursuing >>> end-to-end security, I do not see current proposed charter >>> text prohibiting it: >>> >>> "- Maintaining and/or progressing, along the standards track, the >>> Diameter Base protocol and Diameter Applications. This includes >>> extensions to Diameter Base protocol that can be considered as >>> enhanced features or bug fixes." >>> >>> I would argue the end-to-end security is an enhanced feature for >>> Diameter base protocol that fixes a serious bug/flaw in security. >>> On the other hand, if an explicit note is needed about this topic >>> in the charter, I might hesitate to include such in this round. >>> I would first like to see some concrete movement& work around >>> this topic. >>> >>> - Jouni >>> >>> >>> >>> On Jan 11, 2012, at 7:31 PM, Stephen Farrell wrote: >>> >>>> >>>> Hi, >>>> >>>> During the IESG internal review of this I asked whether >>>> or not there was interest in trying to tackle end to >>>> end security for AVPs. I do know there is at least some >>>> interest in that but its not clear there's enough to >>>> warrant including it in the re-charter so I said I'd >>>> ask when the recharter went out for review... >>>> >>>> So - anyone interested in DIME solving that problem? >>>> (And willing and able to help do the work of course.) >>>> >>>> As of now, Diameter really only has hop-by-hop security >>>> which is ok in many cases but far from ideal (wearing >>>> my security hat) in some. >>>> >>>> Thanks, >>>> Stephen. >>>> >>>> On 01/11/2012 04:37 PM, IESG Secretary wrote: >>>>> A modified charter has been submitted for the Diameter Maintenance >> and >>>>> Extensions (dime) working group in the Operations and Management >> Area of >>>>> the IETF. The IESG has not made any determination as yet. The >> modified >>>>> charter is provided below for informational purposes only. Please >> send >>>>> your comments to the IESG mailing list (iesg@ietf.org) by >> Wednesday, >>>>> January 18, 2012. >>>>> >>>>> Diameter Maintenance and Extensions (dime) >>>>> ----------------------------------------- >>>>> Current Status: Active >>>>> >>>>> Last Modified: 2012-01-10 >>>>> >>>>> Chairs: >>>>> Lionel Morand >>>>> Jouni Korhonen >>>>> >>>>> Operations and Management Area Directors: >>>>> Dan Romascanu >>>>> Ronald Bonica >>>>> >>>>> Operations and Management Area Advisor: >>>>> Dan Romascanu >>>>> >>>>> Mailing Lists: >>>>> General Discussion: dime@ietf.org >>>>> To Subscribe: > https://www.ietf.org/mailman/listinfo/dime >>>>> Archive: >>>>> http://www.ietf.org/mail-archive/web/dime/current/maillist.html >>>>> >>>>> Description of Working Group: >>>>> >>>>> The Diameter Maintenance and Extensions WG will focus on >> maintenance and >>>>> extensions to the Diameter protocol required to enable its use for >>>>> authentication, authorization, accounting, charging in network >> access, >>>>> provisioning of configuration information within the network, and >> for >>>>> new AAA session management uses within the extensibility rules of >> the >>>>> Diameter base protocol. >>>>> >>>>> The DIME working group plans to address the following items: >>>>> >>>>> - Maintaining and/or progressing, along the standards track, the >>>>> Diameter Base protocol and Diameter Applications. This includes >>>>> extensions to Diameter Base protocol that can be considered as >> enhanced >>>>> features or bug fixes. >>>>> >>>>> - Diameter application design guideline. This document will > provide >>>>> guidelines for design of Diameter extensions. It will detail when >> to >>>>> consider reusing an existing application and when to develop a new >>>>> application. >>>>> >>>>> - Protocol extensions for the management of Diameter entities. > This >> work >>>>> focuses on the standardization of Management Information Bases >> (MIBs) to >>>>> configure Diameter entities (such as the Diameter Base protocol or >>>>> Diameter Credit Control nodes). The usage of other management >> protocols >>>>> for configuring Diameter entities may be future work within the >> group. >>>>> >>>>> - Protocol extensions for bulk and grouped AAA session management. >> The >>>>> aim of this work is to study and standardize a solution for >> handling >>>>> groups of AAA sessions within the Diameter base protocol context. >> The >>>>> solution would define how to identify and handle grouped AAA >> sessions in >>>>> commands and operations. >>>>> >>>>> Additionally, Diameter-based systems require interoperability in >> order >>>>> to work. The working group, along with the AD, will need to >> evaluate any >>>>> potential extensions and require verification that the proposed >>>>> extension is needed, and is within the extensibility rules of >> Diameter >>>>> and AAA scope. Coordination with other IETF working groups and >> other >>>>> SDOs (e.g. 3GPP) will be used to ensure this. >>>>> >>>>> Goals and Milestones: >>>>> >>>>> Done - Submit the following two Diameter Mobility documents to >> the >>>>> IESG for consideration as a Proposed Standards:* >> 'Diameter >>>>> Mobile IPv6: Support for Home Agent to Diameter Server >>>>> Interaction' * 'Diameter Mobile IPv6: Support for >> Network >>>>> Access Server to Diameter Server Interaction' >>>>> Done - Submit 'Diameter API' to the IESG for consideration as >> an >>>>> Informational RFC >>>>> Done - Submit 'Quality of Service Parameters for Usage with >>>>> Diameter' to the IESG for consideration as a Proposed >>>>> Standard. >>>>> Done - Submit 'Diameter QoS Application' to the IESG for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Support for EAP Re-authentication >>>>> Protocol' as DIME working group item >>>>> Done - Submit 'Diameter User-Name and Realm Based Request >> Routing >>>>> Clarifications' as DIME working group item >>>>> Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working >> group >>>>> item >>>>> Done - Submit 'Quality of Service Attributes for Diameter' to >> the >>>>> IESG for consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter User-Name and Realm Based Request >> Routing >>>>> Clarifications' to the IESG for consideration as a >> Proposed >>>>> Standard >>>>> Done - Submit 'Diameter NAT Control Application' as DIME >> working >>>>> group item >>>>> Done - Submit 'Diameter Capabilities Update' as DIME working >> group >>>>> item >>>>> Done - Submit 'Diameter Credit Control Application MIB' to the >>>>> IESG for consideration as an Informational RFC >>>>> Done - Submit 'Diameter Base Protocol MIB' to the IESG for >>>>> consideration as an Informational RFC >>>>> Done - Submit 'Diameter Capabilities Update' to the IESG for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Extended NAPTR' as DIME working group >> item >>>>> Done - Submit 'Realm-Based Redirection In Diameter' as DIME >>>>> working group item >>>>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 > Localized >>>>> Routing' as DIME working group item >>>>> Done - Submit 'Diameter Attribute-Value Pairs for > Cryptographic >>>>> Key Transport' as DIME working group item >>>>> Done - Submit 'Diameter Priority Attribute Value Pairs' as > DIME >>>>> working group item >>>>> Done - Submit 'Diameter IKEv2 PSK' as DIME working group item >>>>> Done - Submit Revision of 'Diameter Base Protocol' to the IESG >> for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Attribute-Value Pairs for > Cryptographic >>>>> Key Transport' to the IESG for consideration as a >> Proposed >>>>> Standard >>>>> Done - Submit 'Diameter Priority Attribute Value Pairs' to the >>>>> IESG for consideration as a Proposed Standard >>>>> Done - Submit Revision of 'Diameter Network Access Server >>>>> Application - RFC 4005bis' as DIME working group item >>>>> Done - Submit 'Diameter NAT Control Application' to the IESG >> for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter IKEv2 PSK' to the IESG for >> consideration >>>>> as a Proposed Standard >>>>> Done - Submit 'Diameter Extended NAPTR' to the IESG for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 > Localized >>>>> Routing' to the IESG for consideration as a Proposed >>>>> Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the > IESG >>>>> for consideration as a Proposed Standard >>>>> Mar 2012 - Submit Revision of 'Diameter Network Access Server >>>>> Application - RFC 4005bis' to the IESG for >> consideration as a >>>>> Proposed Standard >>>>> May 2012 - Submit 'Diameter Application Design Guidelines' to the >> IESG >>>>> for consideration as a BCP document Standard >>>>> Jul 2012 - Submit 'Diameter Support for EAP Re-authentication >>>>> Protocol' to the IESG for consideration as a Proposed >>>>> Standard >>>>> Aug 2012 - Submit a document on 'Protocol extension for bulk and >> group >>>>> signaling' as a working group item >>>>> Aug 2013 - Submit a document on 'Protocol extension for bulk and >> group >>>>> signaling' to the IESG for consideration as a Proposed >>>>> Standard >>>>> _______________________________________________ >>>>> IETF-Announce mailing list >>>>> IETF-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>>>> >>>> _______________________________________________ >>>> Ietf mailing list >>>> Ietf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ietf >>> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From Tina.Tsou.Zouting@huawei.com Thu Jan 12 20:15:06 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB2A21F846B for ; Thu, 12 Jan 2012 20:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, 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 hM2ixRNdfWmV for ; Thu, 12 Jan 2012 20:15:06 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id C833B21F843A for ; Thu, 12 Jan 2012 20:15:05 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXP007QOYH3CQ@szxga03-in.huawei.com> for dime@ietf.org; Fri, 13 Jan 2012 12:15:03 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXP00K6FYH3X0@szxga03-in.huawei.com> for dime@ietf.org; Fri, 13 Jan 2012 12:15:03 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGH17482; Fri, 13 Jan 2012 12:13:38 +0800 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 13 Jan 2012 12:13:31 +0800 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.37]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.003; Fri, 13 Jan 2012 12:13:17 +0800 Date: Fri, 13 Jan 2012 04:13:17 +0000 From: Tina TSOU In-reply-to: To: jouni korhonen Message-id: <0389ACBC-8BDD-49E5-96D1-47F78521D7CE@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [Dime] Would realm-based redirection be a protocol error or an application error? Thread-index: AQHMzkMKHo1R45LVnEGXlFhXo140npYDFisAgAEb8oCAAYWIRf//25KAgAQjnas= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4F09FA77.5020301@gmail.com> <4F0A909A.2030705@gmail.com> <4F0B7ECB.5040006@gmail.com> Cc: "dime@ietf.org" Subject: Re: [Dime] Would realm-based redirection be a protocol error or an application error? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 04:15:07 -0000 Existing DIAMETER_REDIRECT_INDICATION is at host level; so the forwarding decision can be taken at hop level; any node in the path of Diameter original request may forward it to the host specified by 3XXX response with DIAMETER_REDIRECT_INDICATION. However DIAMETER_REALM_REDIRECT_INDICATION is at realm level (and need use the realm routing table of the request originator); hence to avoid per hop handling of this error, I have suggested 5XXX. Sent from my iPad On Jan 10, 2012, at 1:01 PM, "jouni korhonen" wrote: > > A question. Taken that existing direct stuff uses protocol errors (3xxx) why should realm-based redirection behave differently? > > - Jouni > > > On Jan 10, 2012, at 5:11 PM, Tina TSOU wrote: > >> DIAMETER_REALM_REDIRECT_INDICATION should be defined as an Application error. >> I think the 5XXX class is appropriate. >> The R-bit should be cleared (default for all Diameter answer messages) and E-bit should not be set. >> >> Sent from my iPad >> >> On Jan 9, 2012, at 5:57 PM, "Tom Taylor" wrote: >> >>> See below. >>> >>> On 09/01/2012 2:00 AM, Glen Zorn wrote: >>>> On 1/9/2012 3:20 AM, Tom Taylor wrote: >>>> >>>>> I'm finally updating draft-ietf-dime-realm-based-redirect. >>>>> >>>>> Given that realm-based redirection is defined at an application level, >>>>> maybe the answer is obvious. >>>> >>>> Section 7 of RFC 3588 says >>>> >>>> There are two different types of errors in Diameter; protocol and >>>> application errors. A protocol error is one that occurs at the base >>>> protocol level, and MAY require per hop attention (e.g., message >>>> routing error). Application errors, on the other hand, generally >>>> occur due to a problem with a function specified in a Diameter >>>> application (e.g., user authentication, Missing AVP). >>>> >>>>> What I am concerned with is whether the >>>>> redirect server should clear the 'R' bit in the header to ensure that >>>>> the response goes all the way back to the original requesting host >>>>> (i.e., following on Figure 8 in section 7 of RFC 3588). >>>> >>>> I don't understand: as I understand it, the 'R' bit has nothing to do >>>> with error type; if it is cleared that just signifies that the message >>>> is an answer, rather than a request (which would presumably be true of >>>> any error response). >>> >>> [PTT] I don't think so. Section 7 makes a clear distinction between the routing for protocol error responses and application error responses (Figures 7 and 8 rtespectively) and ascribes the difference to the setting of the 'R' bit (text following Figure 8). >>>> >>>>> The reason for >>>>> doing this is the issue identified in the Security Considerations >>>>> section of the realm-based-redirection I-D: a change of realm implies a >>>>> change of business relationship >>>> >>>> I think that this is not necessarily true. For example, consider a >>>> large ISP with international operations; such an entity might have >>>> multiple Diameter realms (europe.bigisp.com, asia.bigisp.com, etc.), no? >>>> >>>>> that should be noted by the requesting >>>>> host before the request is rerouted. >>> >>> [PTT] I think I've decided not to mention the 'R' bit. The result fits within the recommendations in the Security Considerations section. >>> >>>>> >>>>> Tom Taylor >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>>> >>>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > From dromasca@avaya.com Thu Jan 12 22:16:06 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25CA21F85FC; Thu, 12 Jan 2012 22:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.263 X-Spam-Level: X-Spam-Status: No, score=-103.263 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 o15cqaSs1rjD; Thu, 12 Jan 2012 22:16:05 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id D9FC021F85F9; Thu, 12 Jan 2012 22:16:03 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsEFABbKD0+HCzI1/2dsb2JhbAA4Cp5ighSMG4EFgXIBAQEBAwEBAQ8IAhEDPgsMBAIBCA0EBAEBAQoCBAwEAQYBBgEgBh8JCAEBBBMIARIHh2CbYJsdiGCCWmMEiAiSeIUEh0c X-IronPort-AV: E=Sophos;i="4.71,502,1320642000"; d="scan'208,217";a="286029901" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 13 Jan 2012 01:16:00 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 13 Jan 2012 01:02:44 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCD1BA.D0A60F87" Date: Fri, 13 Jan 2012 07:14:34 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions (dime) Thread-Index: AczRpDrqi4QXYP6KTl22emwkgS5qzgAFmPVY References: <20120111163717.591B021F87EF@ietfa.amsl.com><4F0DC78D.2010809@cs.tcd.ie> <4F0ECE57.3020900@cs.tcd.ie> <4F0FA62D.4090808@gmail.com> From: "Romascanu, Dan (Dan)" To: "Glen Zorn" Cc: IETF-Discussion , jouni.korhonen@nsn.com, lionel.morand@orange-ftgroup.com, dime@ietf.org, iesg@ietf.org, Stephen Farrell Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions (dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 06:16:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCD1BA.D0A60F87 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks, Glen! Can we see (at least) a couple of more hands from people = willing to participate in the editing of this document?=20 Dan -----Original Message----- From: Glen Zorn [mailto:glenzorn@gmail.com] Sent: Fri 1/13/2012 5:34 AM To: Romascanu, Dan (Dan) Cc: Stephen Farrell; jouni korhonen; jouni.korhonen@nsn.com; = lionel.morand@orange-ftgroup.com; dime@ietf.org; IETF-Discussion; = iesg@ietf.org Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and = Extensions (dime) =20 On 1/12/2012 7:15 PM, Romascanu, Dan (Dan) wrote: > Hi, >=20 > If a number of hands were raised now and the folks commanding them say > 'we are ready to work on this NOW' I would support including explicit > wording in the charter.=20 Consider my hand raised. If this does not happen until the telechat next > week the current text is good enough to allow interested people to = start > working on contributions that can be individual submissions. If these > submissions are consistent enough the WG can add the milestone later = in > the charter and adopt the submissions as WG items.=20 >=20 > Dan >=20 >=20 >=20 >=20 >=20 >> -----Original Message----- >> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf > Of >> Stephen Farrell >> Sent: Thursday, January 12, 2012 2:13 PM >> To: jouni korhonen >> Cc: jouni.korhonen@nsn.com; lionel.morand@orange-ftgroup.com; >> dime@ietf.org; IETF-Discussion; iesg@ietf.org >> Subject: Re: WG Review: Recharter of Diameter Maintenance and >> Extensions (dime) >> >> >> Hi Jouni, >> >> Right, I'm trying to encourage this - I'm not trying >> to make it a gating function for the recharter. Its >> still worth doing though if we can find some victims >> with enough energy:-) >> >> I agree that the current charter text might not need >> to be modified, OTOH, if there were folks who wanted to >> do the work, a milestone might be good. I also agree >> that as of now, that addition is not warranted. >> >> Cheers, >> S >> >> On 01/12/2012 12:08 PM, jouni korhonen wrote: >>> >>> Stephen, >>> >>> This topic raises its head every now and then when a Dime >>> document arrives at IESG ;) Apart from that there has been >>> very little serious public discussion about it recently, >>> for some unknown reason to me. A detail worth pointing out >>> is that the support for the End-to-End security framework >>> (E2E-Sequence AVP and 'P'-bit in the AVP header) has been >>> deprecated in RFC3588bis (now in IESG). So we are "free" >>> to start from scratch. >>> >>> If there is enough serious energy and vision for pursuing >>> end-to-end security, I do not see current proposed charter >>> text prohibiting it: >>> >>> "- Maintaining and/or progressing, along the standards track, the >>> Diameter Base protocol and Diameter Applications. This includes >>> extensions to Diameter Base protocol that can be considered as >>> enhanced features or bug fixes." >>> >>> I would argue the end-to-end security is an enhanced feature for >>> Diameter base protocol that fixes a serious bug/flaw in security. >>> On the other hand, if an explicit note is needed about this topic >>> in the charter, I might hesitate to include such in this round. >>> I would first like to see some concrete movement& work around >>> this topic. >>> >>> - Jouni >>> >>> >>> >>> On Jan 11, 2012, at 7:31 PM, Stephen Farrell wrote: >>> >>>> >>>> Hi, >>>> >>>> During the IESG internal review of this I asked whether >>>> or not there was interest in trying to tackle end to >>>> end security for AVPs. I do know there is at least some >>>> interest in that but its not clear there's enough to >>>> warrant including it in the re-charter so I said I'd >>>> ask when the recharter went out for review... >>>> >>>> So - anyone interested in DIME solving that problem? >>>> (And willing and able to help do the work of course.) >>>> >>>> As of now, Diameter really only has hop-by-hop security >>>> which is ok in many cases but far from ideal (wearing >>>> my security hat) in some. >>>> >>>> Thanks, >>>> Stephen. >>>> >>>> On 01/11/2012 04:37 PM, IESG Secretary wrote: >>>>> A modified charter has been submitted for the Diameter Maintenance >> and >>>>> Extensions (dime) working group in the Operations and Management >> Area of >>>>> the IETF. The IESG has not made any determination as yet. The >> modified >>>>> charter is provided below for informational purposes only. Please >> send >>>>> your comments to the IESG mailing list (iesg@ietf.org) by >> Wednesday, >>>>> January 18, 2012. >>>>> >>>>> Diameter Maintenance and Extensions (dime) >>>>> ----------------------------------------- >>>>> Current Status: Active >>>>> >>>>> Last Modified: 2012-01-10 >>>>> >>>>> Chairs: >>>>> Lionel Morand >>>>> Jouni Korhonen >>>>> >>>>> Operations and Management Area Directors: >>>>> Dan Romascanu >>>>> Ronald Bonica >>>>> >>>>> Operations and Management Area Advisor: >>>>> Dan Romascanu >>>>> >>>>> Mailing Lists: >>>>> General Discussion: dime@ietf.org >>>>> To Subscribe: > https://www.ietf.org/mailman/listinfo/dime >>>>> Archive: >>>>> http://www.ietf.org/mail-archive/web/dime/current/maillist.html >>>>> >>>>> Description of Working Group: >>>>> >>>>> The Diameter Maintenance and Extensions WG will focus on >> maintenance and >>>>> extensions to the Diameter protocol required to enable its use for >>>>> authentication, authorization, accounting, charging in network >> access, >>>>> provisioning of configuration information within the network, and >> for >>>>> new AAA session management uses within the extensibility rules of >> the >>>>> Diameter base protocol. >>>>> >>>>> The DIME working group plans to address the following items: >>>>> >>>>> - Maintaining and/or progressing, along the standards track, the >>>>> Diameter Base protocol and Diameter Applications. This includes >>>>> extensions to Diameter Base protocol that can be considered as >> enhanced >>>>> features or bug fixes. >>>>> >>>>> - Diameter application design guideline. This document will > provide >>>>> guidelines for design of Diameter extensions. It will detail when >> to >>>>> consider reusing an existing application and when to develop a new >>>>> application. >>>>> >>>>> - Protocol extensions for the management of Diameter entities. > This >> work >>>>> focuses on the standardization of Management Information Bases >> (MIBs) to >>>>> configure Diameter entities (such as the Diameter Base protocol or >>>>> Diameter Credit Control nodes). The usage of other management >> protocols >>>>> for configuring Diameter entities may be future work within the >> group. >>>>> >>>>> - Protocol extensions for bulk and grouped AAA session management. >> The >>>>> aim of this work is to study and standardize a solution for >> handling >>>>> groups of AAA sessions within the Diameter base protocol context. >> The >>>>> solution would define how to identify and handle grouped AAA >> sessions in >>>>> commands and operations. >>>>> >>>>> Additionally, Diameter-based systems require interoperability in >> order >>>>> to work. The working group, along with the AD, will need to >> evaluate any >>>>> potential extensions and require verification that the proposed >>>>> extension is needed, and is within the extensibility rules of >> Diameter >>>>> and AAA scope. Coordination with other IETF working groups and >> other >>>>> SDOs (e.g. 3GPP) will be used to ensure this. >>>>> >>>>> Goals and Milestones: >>>>> >>>>> Done - Submit the following two Diameter Mobility documents to >> the >>>>> IESG for consideration as a Proposed Standards:* >> 'Diameter >>>>> Mobile IPv6: Support for Home Agent to Diameter Server >>>>> Interaction' * 'Diameter Mobile IPv6: Support for >> Network >>>>> Access Server to Diameter Server Interaction' >>>>> Done - Submit 'Diameter API' to the IESG for consideration as >> an >>>>> Informational RFC >>>>> Done - Submit 'Quality of Service Parameters for Usage with >>>>> Diameter' to the IESG for consideration as a Proposed >>>>> Standard. >>>>> Done - Submit 'Diameter QoS Application' to the IESG for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Support for EAP Re-authentication >>>>> Protocol' as DIME working group item >>>>> Done - Submit 'Diameter User-Name and Realm Based Request >> Routing >>>>> Clarifications' as DIME working group item >>>>> Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working >> group >>>>> item >>>>> Done - Submit 'Quality of Service Attributes for Diameter' to >> the >>>>> IESG for consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter User-Name and Realm Based Request >> Routing >>>>> Clarifications' to the IESG for consideration as a >> Proposed >>>>> Standard >>>>> Done - Submit 'Diameter NAT Control Application' as DIME >> working >>>>> group item >>>>> Done - Submit 'Diameter Capabilities Update' as DIME working >> group >>>>> item >>>>> Done - Submit 'Diameter Credit Control Application MIB' to the >>>>> IESG for consideration as an Informational RFC >>>>> Done - Submit 'Diameter Base Protocol MIB' to the IESG for >>>>> consideration as an Informational RFC >>>>> Done - Submit 'Diameter Capabilities Update' to the IESG for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Extended NAPTR' as DIME working group >> item >>>>> Done - Submit 'Realm-Based Redirection In Diameter' as DIME >>>>> working group item >>>>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 > Localized >>>>> Routing' as DIME working group item >>>>> Done - Submit 'Diameter Attribute-Value Pairs for > Cryptographic >>>>> Key Transport' as DIME working group item >>>>> Done - Submit 'Diameter Priority Attribute Value Pairs' as > DIME >>>>> working group item >>>>> Done - Submit 'Diameter IKEv2 PSK' as DIME working group item >>>>> Done - Submit Revision of 'Diameter Base Protocol' to the IESG >> for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Attribute-Value Pairs for > Cryptographic >>>>> Key Transport' to the IESG for consideration as a >> Proposed >>>>> Standard >>>>> Done - Submit 'Diameter Priority Attribute Value Pairs' to the >>>>> IESG for consideration as a Proposed Standard >>>>> Done - Submit Revision of 'Diameter Network Access Server >>>>> Application - RFC 4005bis' as DIME working group item >>>>> Done - Submit 'Diameter NAT Control Application' to the IESG >> for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter IKEv2 PSK' to the IESG for >> consideration >>>>> as a Proposed Standard >>>>> Done - Submit 'Diameter Extended NAPTR' to the IESG for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 > Localized >>>>> Routing' to the IESG for consideration as a Proposed >>>>> Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the > IESG >>>>> for consideration as a Proposed Standard >>>>> Mar 2012 - Submit Revision of 'Diameter Network Access Server >>>>> Application - RFC 4005bis' to the IESG for >> consideration as a >>>>> Proposed Standard >>>>> May 2012 - Submit 'Diameter Application Design Guidelines' to the >> IESG >>>>> for consideration as a BCP document Standard >>>>> Jul 2012 - Submit 'Diameter Support for EAP Re-authentication >>>>> Protocol' to the IESG for consideration as a Proposed >>>>> Standard >>>>> Aug 2012 - Submit a document on 'Protocol extension for bulk and >> group >>>>> signaling' as a working group item >>>>> Aug 2013 - Submit a document on 'Protocol extension for bulk and >> group >>>>> signaling' to the IESG for consideration as a Proposed >>>>> Standard >>>>> _______________________________________________ >>>>> IETF-Announce mailing list >>>>> IETF-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>>>> >>>> _______________________________________________ >>>> Ietf mailing list >>>> Ietf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ietf >>> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime ------_=_NextPart_001_01CCD1BA.D0A60F87 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Dime] WG Review: Recharter of Diameter Maintenance and = Extensions (dime)

Thanks, Glen! Can we see (at least) a couple of more = hands from people willing to participate in the editing of this = document?

Dan



-----Original Message-----
From: Glen Zorn [mailto:glenzorn@gmail.com]
Sent: Fri 1/13/2012 5:34 AM
To: Romascanu, Dan (Dan)
Cc: Stephen Farrell; jouni korhonen; jouni.korhonen@nsn.com; = lionel.morand@orange-ftgroup.com; dime@ietf.org; IETF-Discussion; = iesg@ietf.org
Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and = Extensions (dime)

On 1/12/2012 7:15 PM, Romascanu, Dan (Dan) wrote:
> Hi,
>
> If a number of hands were raised now and the folks commanding them = say
> 'we are ready to work on this NOW' I would support including = explicit
> wording in the charter.

Consider my hand raised.

If this does not happen until the telechat next
> week the current text is good enough to allow interested people to = start
> working on contributions that can be individual submissions. If = these
> submissions are consistent enough the WG can add the milestone = later in
> the charter and adopt the submissions as WG items.
>
> Dan
>
>
>
>
>
>> -----Original Message-----
>> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] = On Behalf
> Of
>> Stephen Farrell
>> Sent: Thursday, January 12, 2012 2:13 PM
>> To: jouni korhonen
>> Cc: jouni.korhonen@nsn.com; = lionel.morand@orange-ftgroup.com;
>> dime@ietf.org; IETF-Discussion; iesg@ietf.org
>> Subject: Re: WG Review: Recharter of Diameter Maintenance = and
>> Extensions (dime)
>>
>>
>> Hi Jouni,
>>
>> Right, I'm trying to encourage this - I'm not trying
>> to make it a gating function for the recharter. Its
>> still worth doing though if we can find some victims
>> with enough energy:-)
>>
>> I agree that the current charter text might not need
>> to be modified, OTOH, if there were folks who wanted to
>> do the work, a milestone might be good. I also agree
>> that as of now, that addition is not warranted.
>>
>> Cheers,
>> S
>>
>> On 01/12/2012 12:08 PM, jouni korhonen wrote:
>>>
>>> Stephen,
>>>
>>> This topic raises its head every now and then when a = Dime
>>> document arrives at IESG ;) Apart from that there has = been
>>> very little serious public discussion about it = recently,
>>> for some unknown reason to me. A detail worth pointing = out
>>> is that the support for the End-to-End security = framework
>>> (E2E-Sequence AVP and 'P'-bit in the AVP header) has = been
>>> deprecated in RFC3588bis (now in IESG). So we are = "free"
>>> to start from scratch.
>>>
>>> If there is enough serious energy and vision for = pursuing
>>> end-to-end security, I do not see current proposed = charter
>>> text prohibiting it:
>>>
>>> "- Maintaining and/or progressing, along the standards = track, the
>>>     Diameter Base protocol and Diameter = Applications. This includes
>>>     extensions to Diameter Base = protocol that can be considered as
>>>     enhanced features or bug = fixes."
>>>
>>> I would argue the end-to-end security is an enhanced = feature for
>>> Diameter base protocol that fixes a serious bug/flaw in = security.
>>> On the other hand, if an explicit note is needed about this = topic
>>> in the charter, I might hesitate to include such in this = round.
>>> I would first like to see some concrete movement&  = work around
>>> this topic.
>>>
>>> - Jouni
>>>
>>>
>>>
>>> On Jan 11, 2012, at 7:31 PM, Stephen Farrell wrote:
>>>
>>>>
>>>> Hi,
>>>>
>>>> During the IESG internal review of this I asked = whether
>>>> or not there was interest in trying to tackle end = to
>>>> end security for AVPs. I do know there is at least = some
>>>> interest in that but its not clear there's enough = to
>>>> warrant including it in the re-charter so I said = I'd
>>>> ask when the recharter went out for review...
>>>>
>>>> So - anyone interested in DIME solving that = problem?
>>>> (And willing and able to help do the work of = course.)
>>>>
>>>> As of now, Diameter really only has hop-by-hop = security
>>>> which is ok in many cases but far from ideal = (wearing
>>>> my security hat) in some.
>>>>
>>>> Thanks,
>>>> Stephen.
>>>>
>>>> On 01/11/2012 04:37 PM, IESG Secretary wrote:
>>>>> A modified charter has been submitted for the = Diameter Maintenance
>> and
>>>>> Extensions (dime) working group in the Operations = and Management
>> Area of
>>>>> the IETF.  The IESG has not made any = determination as yet.  The
>> modified
>>>>> charter is provided below for informational = purposes only.  Please
>> send
>>>>> your comments to the IESG mailing list = (iesg@ietf.org) by
>> Wednesday,
>>>>> January 18, 2012.
>>>>>
>>>>> Diameter Maintenance and Extensions (dime)
>>>>> -----------------------------------------
>>>>> Current Status: Active
>>>>>
>>>>> Last Modified: 2012-01-10
>>>>>
>>>>> Chairs:
>>>>>      Lionel = Morand<lionel.morand@orange-ftgroup.com>
>>>>>      Jouni = Korhonen<jouni.korhonen@nsn.com>
>>>>>
>>>>> Operations and Management Area Directors:
>>>>>      Dan = Romascanu<dromasca@avaya.com>
>>>>>      Ronald = Bonica<rbonica@juniper.net>
>>>>>
>>>>> Operations and Management Area Advisor:
>>>>>      Dan = Romascanu<dromasca@avaya.com>
>>>>>
>>>>> Mailing Lists:
>>>>>      General Discussion: = dime@ietf.org
>>>>>      To Subscribe:
> https://www.ietf.org/= mailman/listinfo/dime
>>>>>      Archive:
>>>>> = http://www.ietf.org/mail-archive/web/dime/current/maillist.html
>>>>>
>>>>> Description of Working Group:
>>>>>
>>>>> The Diameter Maintenance and Extensions WG will = focus on
>> maintenance and
>>>>> extensions to the Diameter protocol required to = enable its use for
>>>>> authentication, authorization, accounting, charging = in network
>> access,
>>>>> provisioning of configuration information within = the network, and
>> for
>>>>> new AAA session management uses within the = extensibility rules of
>> the
>>>>> Diameter base protocol.
>>>>>
>>>>> The DIME working group plans to address the = following items:
>>>>>
>>>>> - Maintaining and/or progressing, along the = standards track, the
>>>>> Diameter Base protocol and Diameter Applications. = This includes
>>>>> extensions to Diameter Base protocol that can be = considered as
>> enhanced
>>>>> features or bug fixes.
>>>>>
>>>>> - Diameter application design guideline. This = document will
> provide
>>>>> guidelines for design of Diameter extensions. It = will detail when
>> to
>>>>> consider reusing an existing application and when = to develop a new
>>>>> application.
>>>>>
>>>>> - Protocol extensions for the management of = Diameter entities.
> This
>> work
>>>>> focuses on the standardization of Management = Information Bases
>> (MIBs) to
>>>>> configure Diameter entities (such as the Diameter = Base protocol or
>>>>> Diameter Credit Control nodes). The usage of other = management
>> protocols
>>>>> for configuring Diameter entities may be future = work within the
>> group.
>>>>>
>>>>> - Protocol extensions for bulk and grouped AAA = session management.
>> The
>>>>> aim of this work is to study and standardize a = solution for
>> handling
>>>>> groups of AAA sessions within the Diameter base = protocol context.
>> The
>>>>> solution would define how to identify and handle = grouped AAA
>> sessions in
>>>>> commands and operations.
>>>>>
>>>>> Additionally, Diameter-based systems require = interoperability in
>> order
>>>>> to work. The working group, along with the AD, will = need to
>> evaluate any
>>>>> potential extensions and require verification that = the proposed
>>>>> extension is needed, and is within the = extensibility rules of
>> Diameter
>>>>> and AAA scope. Coordination with other IETF working = groups and
>> other
>>>>> SDOs (e.g. 3GPP) will be used to ensure this.
>>>>>
>>>>> Goals and Milestones:
>>>>>
>>>>> Done     - Submit the following = two Diameter Mobility documents to
>> the
>>>>>         = ;    IESG for consideration as a Proposed Standards:*
>> 'Diameter
>>>>>         = ;    Mobile IPv6: Support for Home Agent to Diameter = Server
>>>>>         = ;    Interaction' * 'Diameter Mobile IPv6: Support = for
>> Network
>>>>>         = ;    Access Server to Diameter Server Interaction'
>>>>> Done     - Submit 'Diameter = API' to the IESG for consideration as
>> an
>>>>>         = ;    Informational RFC
>>>>> Done     - Submit 'Quality of = Service Parameters for Usage with
>>>>>         = ;    Diameter' to the IESG for consideration as a = Proposed
>>>>>         = ;    Standard.
>>>>> Done     - Submit 'Diameter QoS = Application' to the IESG for
>>>>>         = ;    consideration as a Proposed Standard
>>>>> Done     - Submit 'Diameter = Support for EAP Re-authentication
>>>>>         = ;    Protocol' as DIME working group item
>>>>> Done     - Submit 'Diameter = User-Name and Realm Based Request
>> Routing
>>>>>         = ;    Clarifications' as DIME working group item
>>>>> Done     - Submit 'Diameter = Proxy Mobile IPv6' as DIME working
>> group
>>>>>         = ;    item
>>>>> Done     - Submit 'Quality of = Service Attributes for Diameter' to
>> the
>>>>>         = ;    IESG for consideration as a Proposed Standard
>>>>> Done     - Submit 'Diameter = Proxy Mobile IPv6' to the IESG for
>>>>>         = ;    consideration as a Proposed Standard
>>>>> Done     - Submit 'Diameter = User-Name and Realm Based Request
>> Routing
>>>>>         = ;    Clarifications' to the IESG for consideration as = a
>> Proposed
>>>>>         = ;    Standard
>>>>> Done     - Submit 'Diameter NAT = Control Application' as DIME
>> working
>>>>>         = ;    group item
>>>>> Done     - Submit 'Diameter = Capabilities Update' as DIME working
>> group
>>>>>         = ;    item
>>>>> Done     - Submit 'Diameter = Credit Control Application MIB' to the
>>>>>         = ;    IESG for consideration as an Informational RFC
>>>>> Done     - Submit 'Diameter = Base Protocol MIB' to the IESG for
>>>>>         = ;    consideration as an Informational RFC
>>>>> Done     - Submit 'Diameter = Capabilities Update' to the IESG for
>>>>>         = ;    consideration as a Proposed Standard
>>>>> Done     - Submit 'Diameter = Extended NAPTR' as DIME working group
>> item
>>>>> Done     - Submit 'Realm-Based = Redirection In Diameter' as DIME
>>>>>         = ;    working group item
>>>>> Done     - Submit 'Diameter = Support for Proxy Mobile IPv6
> Localized
>>>>>         = ;    Routing' as DIME working group item
>>>>> Done     - Submit 'Diameter = Attribute-Value Pairs for
> Cryptographic
>>>>>         = ;    Key Transport' as DIME working group item
>>>>> Done     - Submit 'Diameter = Priority Attribute Value Pairs' as
> DIME
>>>>>         = ;    working group item
>>>>> Done     - Submit 'Diameter = IKEv2 PSK' as DIME working group item
>>>>> Done     - Submit Revision of = 'Diameter Base Protocol' to the IESG
>> for
>>>>>         = ;    consideration as a Proposed Standard
>>>>> Done     - Submit 'Diameter = Attribute-Value Pairs for
> Cryptographic
>>>>>         = ;    Key Transport' to the IESG for consideration as = a
>> Proposed
>>>>>         = ;    Standard
>>>>> Done     - Submit 'Diameter = Priority Attribute Value Pairs' to the
>>>>>         = ;    IESG for consideration as a Proposed Standard
>>>>> Done     - Submit Revision of = 'Diameter Network Access Server
>>>>>         = ;    Application - RFC 4005bis' as DIME working group = item
>>>>> Done     - Submit 'Diameter NAT = Control Application' to the IESG
>> for
>>>>>         = ;    consideration as a Proposed Standard
>>>>> Done     - Submit 'Diameter = IKEv2 PSK' to the IESG for
>> consideration
>>>>>         = ;    as a Proposed Standard
>>>>> Done     - Submit 'Diameter = Extended NAPTR' to the IESG for
>>>>>         = ;    consideration as a Proposed Standard
>>>>> Done     - Submit 'Diameter = Support for Proxy Mobile IPv6
> Localized
>>>>>         = ;    Routing' to the IESG for consideration as a = Proposed
>>>>> Mar 2012 - Submit 'Realm-Based Redirection In = Diameter' to the
> IESG
>>>>>         = ;    for consideration as a Proposed Standard
>>>>> Mar 2012 - Submit Revision of 'Diameter Network = Access Server
>>>>>         = ;    Application - RFC 4005bis' to the IESG for
>> consideration as a
>>>>>         = ;    Proposed Standard
>>>>> May 2012 - Submit 'Diameter Application Design = Guidelines' to the
>> IESG
>>>>>         = ;    for consideration as a BCP document Standard
>>>>> Jul 2012 - Submit 'Diameter Support for EAP = Re-authentication
>>>>>         = ;    Protocol' to the IESG for consideration as a = Proposed
>>>>>         = ;    Standard
>>>>> Aug 2012 - Submit a document on 'Protocol extension = for bulk and
>> group
>>>>>         = ;    signaling' as a working group item
>>>>> Aug 2013 - Submit a document on 'Protocol extension = for bulk and
>> group
>>>>>         = ;    signaling' to the IESG for consideration as a = Proposed
>>>>>         = ;    Standard
>>>>> _______________________________________________
>>>>> IETF-Announce mailing list
>>>>> IETF-Announce@ietf.org
>>>>> https://www.= ietf.org/mailman/listinfo/ietf-announce
>>>>>
>>>> _______________________________________________
>>>> Ietf mailing list
>>>> Ietf@ietf.org
>>>> https://www.ietf.org/= mailman/listinfo/ietf
>>>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/= mailman/listinfo/dime

------_=_NextPart_001_01CCD1BA.D0A60F87-- From bill.wu@huawei.com Thu Jan 12 22:40:03 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E644D21F84E2; Thu, 12 Jan 2012 22:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.167 X-Spam-Level: X-Spam-Status: No, score=-6.167 tagged_above=-999 required=5 tests=[AWL=0.431, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 khbkF+T5aY8j; Thu, 12 Jan 2012 22:40:01 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 369F321F849B; Thu, 12 Jan 2012 22:40:01 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXQ004HV56EMI@szxga03-in.huawei.com>; Fri, 13 Jan 2012 14:39:51 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXQ0089956ETZ@szxga03-in.huawei.com>; Fri, 13 Jan 2012 14:39:50 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGK56535; Fri, 13 Jan 2012 14:39:49 +0800 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 13 Jan 2012 14:39:38 +0800 Received: from w53375q (10.138.41.130) by szxeml421-hub.china.huawei.com (10.82.67.160) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 13 Jan 2012 14:39:38 +0800 Date: Fri, 13 Jan 2012 14:39:37 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: "Romascanu, Dan (Dan)" , Glen Zorn Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: multipart/alternative; boundary="Boundary_(ID_CJ0OBoOpPYNtfrO0+8V4aQ)" X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <20120111163717.591B021F87EF@ietfa.amsl.com> <4F0DC78D.2010809@cs.tcd.ie> <4F0ECE57.3020900@cs.tcd.ie> <4F0FA62D.4090808@gmail.com> Cc: IETF-Discussion , jouni.korhonen@nsn.com, lionel.morand@orange-ftgroup.com, dime@ietf.org, iesg@ietf.org, Stephen Farrell Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance andExtensions (dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 06:40:04 -0000 --Boundary_(ID_CJ0OBoOpPYNtfrO0+8V4aQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT RE: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions (dime)Count me. I remember there was an initial individual submission from Glen and me regarding end to end security topic. http://tools.ietf.org/html/draft-zorn-dime-n2n-sec-lite-01 unfortunetely not finished due to lacking energy in the last year . This may serve as a good input to this topic although more input are needed. Regards! -Qin ----- Original Message ----- From: Romascanu, Dan (Dan) To: Glen Zorn Cc: IETF-Discussion ; jouni.korhonen@nsn.com ; lionel.morand@orange-ftgroup.com ; dime@ietf.org ; iesg@ietf.org ; Stephen Farrell Sent: Friday, January 13, 2012 2:14 PM Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance andExtensions (dime) Thanks, Glen! Can we see (at least) a couple of more hands from people willing to participate in the editing of this document? Dan -----Original Message----- From: Glen Zorn [mailto:glenzorn@gmail.com] Sent: Fri 1/13/2012 5:34 AM To: Romascanu, Dan (Dan) Cc: Stephen Farrell; jouni korhonen; jouni.korhonen@nsn.com; lionel.morand@orange-ftgroup.com; dime@ietf.org; IETF-Discussion; iesg@ietf.org Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions (dime) On 1/12/2012 7:15 PM, Romascanu, Dan (Dan) wrote: > Hi, > > If a number of hands were raised now and the folks commanding them say > 'we are ready to work on this NOW' I would support including explicit > wording in the charter. Consider my hand raised. If this does not happen until the telechat next > week the current text is good enough to allow interested people to start > working on contributions that can be individual submissions. If these > submissions are consistent enough the WG can add the milestone later in > the charter and adopt the submissions as WG items. > > Dan > > > > > >> -----Original Message----- >> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf > Of >> Stephen Farrell >> Sent: Thursday, January 12, 2012 2:13 PM >> To: jouni korhonen >> Cc: jouni.korhonen@nsn.com; lionel.morand@orange-ftgroup.com; >> dime@ietf.org; IETF-Discussion; iesg@ietf.org >> Subject: Re: WG Review: Recharter of Diameter Maintenance and >> Extensions (dime) >> >> >> Hi Jouni, >> >> Right, I'm trying to encourage this - I'm not trying >> to make it a gating function for the recharter. Its >> still worth doing though if we can find some victims >> with enough energy:-) >> >> I agree that the current charter text might not need >> to be modified, OTOH, if there were folks who wanted to >> do the work, a milestone might be good. I also agree >> that as of now, that addition is not warranted. >> >> Cheers, >> S >> >> On 01/12/2012 12:08 PM, jouni korhonen wrote: >>> >>> Stephen, >>> >>> This topic raises its head every now and then when a Dime >>> document arrives at IESG ;) Apart from that there has been >>> very little serious public discussion about it recently, >>> for some unknown reason to me. A detail worth pointing out >>> is that the support for the End-to-End security framework >>> (E2E-Sequence AVP and 'P'-bit in the AVP header) has been >>> deprecated in RFC3588bis (now in IESG). So we are "free" >>> to start from scratch. >>> >>> If there is enough serious energy and vision for pursuing >>> end-to-end security, I do not see current proposed charter >>> text prohibiting it: >>> >>> "- Maintaining and/or progressing, along the standards track, the >>> Diameter Base protocol and Diameter Applications. This includes >>> extensions to Diameter Base protocol that can be considered as >>> enhanced features or bug fixes." >>> >>> I would argue the end-to-end security is an enhanced feature for >>> Diameter base protocol that fixes a serious bug/flaw in security. >>> On the other hand, if an explicit note is needed about this topic >>> in the charter, I might hesitate to include such in this round. >>> I would first like to see some concrete movement& work around >>> this topic. >>> >>> - Jouni >>> >>> >>> >>> On Jan 11, 2012, at 7:31 PM, Stephen Farrell wrote: >>> >>>> >>>> Hi, >>>> >>>> During the IESG internal review of this I asked whether >>>> or not there was interest in trying to tackle end to >>>> end security for AVPs. I do know there is at least some >>>> interest in that but its not clear there's enough to >>>> warrant including it in the re-charter so I said I'd >>>> ask when the recharter went out for review... >>>> >>>> So - anyone interested in DIME solving that problem? >>>> (And willing and able to help do the work of course.) >>>> >>>> As of now, Diameter really only has hop-by-hop security >>>> which is ok in many cases but far from ideal (wearing >>>> my security hat) in some. >>>> >>>> Thanks, >>>> Stephen. >>>> >>>> On 01/11/2012 04:37 PM, IESG Secretary wrote: >>>>> A modified charter has been submitted for the Diameter Maintenance >> and >>>>> Extensions (dime) working group in the Operations and Management >> Area of >>>>> the IETF. The IESG has not made any determination as yet. The >> modified >>>>> charter is provided below for informational purposes only. Please >> send >>>>> your comments to the IESG mailing list (iesg@ietf.org) by >> Wednesday, >>>>> January 18, 2012. >>>>> >>>>> Diameter Maintenance and Extensions (dime) >>>>> ----------------------------------------- >>>>> Current Status: Active >>>>> >>>>> Last Modified: 2012-01-10 >>>>> >>>>> Chairs: >>>>> Lionel Morand >>>>> Jouni Korhonen >>>>> >>>>> Operations and Management Area Directors: >>>>> Dan Romascanu >>>>> Ronald Bonica >>>>> >>>>> Operations and Management Area Advisor: >>>>> Dan Romascanu >>>>> >>>>> Mailing Lists: >>>>> General Discussion: dime@ietf.org >>>>> To Subscribe: > https://www.ietf.org/mailman/listinfo/dime >>>>> Archive: >>>>> http://www.ietf.org/mail-archive/web/dime/current/maillist.html >>>>> >>>>> Description of Working Group: >>>>> >>>>> The Diameter Maintenance and Extensions WG will focus on >> maintenance and >>>>> extensions to the Diameter protocol required to enable its use for >>>>> authentication, authorization, accounting, charging in network >> access, >>>>> provisioning of configuration information within the network, and >> for >>>>> new AAA session management uses within the extensibility rules of >> the >>>>> Diameter base protocol. >>>>> >>>>> The DIME working group plans to address the following items: >>>>> >>>>> - Maintaining and/or progressing, along the standards track, the >>>>> Diameter Base protocol and Diameter Applications. This includes >>>>> extensions to Diameter Base protocol that can be considered as >> enhanced >>>>> features or bug fixes. >>>>> >>>>> - Diameter application design guideline. This document will > provide >>>>> guidelines for design of Diameter extensions. It will detail when >> to >>>>> consider reusing an existing application and when to develop a new >>>>> application. >>>>> >>>>> - Protocol extensions for the management of Diameter entities. > This >> work >>>>> focuses on the standardization of Management Information Bases >> (MIBs) to >>>>> configure Diameter entities (such as the Diameter Base protocol or >>>>> Diameter Credit Control nodes). The usage of other management >> protocols >>>>> for configuring Diameter entities may be future work within the >> group. >>>>> >>>>> - Protocol extensions for bulk and grouped AAA session management. >> The >>>>> aim of this work is to study and standardize a solution for >> handling >>>>> groups of AAA sessions within the Diameter base protocol context. >> The >>>>> solution would define how to identify and handle grouped AAA >> sessions in >>>>> commands and operations. >>>>> >>>>> Additionally, Diameter-based systems require interoperability in >> order >>>>> to work. The working group, along with the AD, will need to >> evaluate any >>>>> potential extensions and require verification that the proposed >>>>> extension is needed, and is within the extensibility rules of >> Diameter >>>>> and AAA scope. Coordination with other IETF working groups and >> other >>>>> SDOs (e.g. 3GPP) will be used to ensure this. >>>>> >>>>> Goals and Milestones: >>>>> >>>>> Done - Submit the following two Diameter Mobility documents to >> the >>>>> IESG for consideration as a Proposed Standards:* >> 'Diameter >>>>> Mobile IPv6: Support for Home Agent to Diameter Server >>>>> Interaction' * 'Diameter Mobile IPv6: Support for >> Network >>>>> Access Server to Diameter Server Interaction' >>>>> Done - Submit 'Diameter API' to the IESG for consideration as >> an >>>>> Informational RFC >>>>> Done - Submit 'Quality of Service Parameters for Usage with >>>>> Diameter' to the IESG for consideration as a Proposed >>>>> Standard. >>>>> Done - Submit 'Diameter QoS Application' to the IESG for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Support for EAP Re-authentication >>>>> Protocol' as DIME working group item >>>>> Done - Submit 'Diameter User-Name and Realm Based Request >> Routing >>>>> Clarifications' as DIME working group item >>>>> Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working >> group >>>>> item >>>>> Done - Submit 'Quality of Service Attributes for Diameter' to >> the >>>>> IESG for consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter User-Name and Realm Based Request >> Routing >>>>> Clarifications' to the IESG for consideration as a >> Proposed >>>>> Standard >>>>> Done - Submit 'Diameter NAT Control Application' as DIME >> working >>>>> group item >>>>> Done - Submit 'Diameter Capabilities Update' as DIME working >> group >>>>> item >>>>> Done - Submit 'Diameter Credit Control Application MIB' to the >>>>> IESG for consideration as an Informational RFC >>>>> Done - Submit 'Diameter Base Protocol MIB' to the IESG for >>>>> consideration as an Informational RFC >>>>> Done - Submit 'Diameter Capabilities Update' to the IESG for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Extended NAPTR' as DIME working group >> item >>>>> Done - Submit 'Realm-Based Redirection In Diameter' as DIME >>>>> working group item >>>>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 > Localized >>>>> Routing' as DIME working group item >>>>> Done - Submit 'Diameter Attribute-Value Pairs for > Cryptographic >>>>> Key Transport' as DIME working group item >>>>> Done - Submit 'Diameter Priority Attribute Value Pairs' as > DIME >>>>> working group item >>>>> Done - Submit 'Diameter IKEv2 PSK' as DIME working group item >>>>> Done - Submit Revision of 'Diameter Base Protocol' to the IESG >> for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Attribute-Value Pairs for > Cryptographic >>>>> Key Transport' to the IESG for consideration as a >> Proposed >>>>> Standard >>>>> Done - Submit 'Diameter Priority Attribute Value Pairs' to the >>>>> IESG for consideration as a Proposed Standard >>>>> Done - Submit Revision of 'Diameter Network Access Server >>>>> Application - RFC 4005bis' as DIME working group item >>>>> Done - Submit 'Diameter NAT Control Application' to the IESG >> for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter IKEv2 PSK' to the IESG for >> consideration >>>>> as a Proposed Standard >>>>> Done - Submit 'Diameter Extended NAPTR' to the IESG for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 > Localized >>>>> Routing' to the IESG for consideration as a Proposed >>>>> Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the > IESG >>>>> for consideration as a Proposed Standard >>>>> Mar 2012 - Submit Revision of 'Diameter Network Access Server >>>>> Application - RFC 4005bis' to the IESG for >> consideration as a >>>>> Proposed Standard >>>>> May 2012 - Submit 'Diameter Application Design Guidelines' to the >> IESG >>>>> for consideration as a BCP document Standard >>>>> Jul 2012 - Submit 'Diameter Support for EAP Re-authentication >>>>> Protocol' to the IESG for consideration as a Proposed >>>>> Standard >>>>> Aug 2012 - Submit a document on 'Protocol extension for bulk and >> group >>>>> signaling' as a working group item >>>>> Aug 2013 - Submit a document on 'Protocol extension for bulk and >> group >>>>> signaling' to the IESG for consideration as a Proposed >>>>> Standard >>>>> _______________________________________________ >>>>> IETF-Announce mailing list >>>>> IETF-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>>>> >>>> _______________________________________________ >>>> Ietf mailing list >>>> Ietf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ietf >>> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime ------------------------------------------------------------------------------ _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --Boundary_(ID_CJ0OBoOpPYNtfrO0+8V4aQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT RE: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions (dime)
Count me.
I remember there was an initial individual submission from Glen and me regarding end to end security topic.
unfortunetely not finished due to lacking energy in the last year .
This may serve as a good input to this topic although more input are needed.
 
Regards!
-Qin
----- Original Message -----
Sent: Friday, January 13, 2012 2:14 PM
Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance andExtensions (dime)

Thanks, Glen! Can we see (at least) a couple of more hands from people willing to participate in the editing of this document?

Dan



-----Original Message-----
From: Glen Zorn [mailto:glenzorn@gmail.com]
Sent: Fri 1/13/2012 5:34 AM
To: Romascanu, Dan (Dan)
Cc: Stephen Farrell; jouni korhonen; jouni.korhonen@nsn.com; lionel.morand@orange-ftgroup.com; dime@ietf.org; IETF-Discussion; iesg@ietf.org
Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions (dime)

On 1/12/2012 7:15 PM, Romascanu, Dan (Dan) wrote:
> Hi,
>
> If a number of hands were raised now and the folks commanding them say
> 'we are ready to work on this NOW' I would support including explicit
> wording in the charter.

Consider my hand raised.

If this does not happen until the telechat next
> week the current text is good enough to allow interested people to start
> working on contributions that can be individual submissions. If these
> submissions are consistent enough the WG can add the milestone later in
> the charter and adopt the submissions as WG items.
>
> Dan
>
>
>
>
>
>> -----Original Message-----
>> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf
> Of
>> Stephen Farrell
>> Sent: Thursday, January 12, 2012 2:13 PM
>> To: jouni korhonen
>> Cc: jouni.korhonen@nsn.com; lionel.morand@orange-ftgroup.com;
>> dime@ietf.org; IETF-Discussion; iesg@ietf.org
>> Subject: Re: WG Review: Recharter of Diameter Maintenance and
>> Extensions (dime)
>>
>>
>> Hi Jouni,
>>
>> Right, I'm trying to encourage this - I'm not trying
>> to make it a gating function for the recharter. Its
>> still worth doing though if we can find some victims
>> with enough energy:-)
>>
>> I agree that the current charter text might not need
>> to be modified, OTOH, if there were folks who wanted to
>> do the work, a milestone might be good. I also agree
>> that as of now, that addition is not warranted.
>>
>> Cheers,
>> S
>>
>> On 01/12/2012 12:08 PM, jouni korhonen wrote:
>>>
>>> Stephen,
>>>
>>> This topic raises its head every now and then when a Dime
>>> document arrives at IESG ;) Apart from that there has been
>>> very little serious public discussion about it recently,
>>> for some unknown reason to me. A detail worth pointing out
>>> is that the support for the End-to-End security framework
>>> (E2E-Sequence AVP and 'P'-bit in the AVP header) has been
>>> deprecated in RFC3588bis (now in IESG). So we are "free"
>>> to start from scratch.
>>>
>>> If there is enough serious energy and vision for pursuing
>>> end-to-end security, I do not see current proposed charter
>>> text prohibiting it:
>>>
>>> "- Maintaining and/or progressing, along the standards track, the
>>>     Diameter Base protocol and Diameter Applications. This includes
>>>     extensions to Diameter Base protocol that can be considered as
>>>     enhanced features or bug fixes."
>>>
>>> I would argue the end-to-end security is an enhanced feature for
>>> Diameter base protocol that fixes a serious bug/flaw in security.
>>> On the other hand, if an explicit note is needed about this topic
>>> in the charter, I might hesitate to include such in this round.
>>> I would first like to see some concrete movement&  work around
>>> this topic.
>>>
>>> - Jouni
>>>
>>>
>>>
>>> On Jan 11, 2012, at 7:31 PM, Stephen Farrell wrote:
>>>
>>>>
>>>> Hi,
>>>>
>>>> During the IESG internal review of this I asked whether
>>>> or not there was interest in trying to tackle end to
>>>> end security for AVPs. I do know there is at least some
>>>> interest in that but its not clear there's enough to
>>>> warrant including it in the re-charter so I said I'd
>>>> ask when the recharter went out for review...
>>>>
>>>> So - anyone interested in DIME solving that problem?
>>>> (And willing and able to help do the work of course.)
>>>>
>>>> As of now, Diameter really only has hop-by-hop security
>>>> which is ok in many cases but far from ideal (wearing
>>>> my security hat) in some.
>>>>
>>>> Thanks,
>>>> Stephen.
>>>>
>>>> On 01/11/2012 04:37 PM, IESG Secretary wrote:
>>>>> A modified charter has been submitted for the Diameter Maintenance
>> and
>>>>> Extensions (dime) working group in the Operations and Management
>> Area of
>>>>> the IETF.  The IESG has not made any determination as yet.  The
>> modified
>>>>> charter is provided below for informational purposes only.  Please
>> send
>>>>> your comments to the IESG mailing list (iesg@ietf.org) by
>> Wednesday,
>>>>> January 18, 2012.
>>>>>
>>>>> Diameter Maintenance and Extensions (dime)
>>>>> -----------------------------------------
>>>>> Current Status: Active
>>>>>
>>>>> Last Modified: 2012-01-10
>>>>>
>>>>> Chairs:
>>>>>      Lionel Morand<lionel.morand@orange-ftgroup.com>
>>>>>      Jouni Korhonen<jouni.korhonen@nsn.com>
>>>>>
>>>>> Operations and Management Area Directors:
>>>>>      Dan Romascanu<dromasca@avaya.com>
>>>>>      Ronald Bonica<rbonica@juniper.net>
>>>>>
>>>>> Operations and Management Area Advisor:
>>>>>      Dan Romascanu<dromasca@avaya.com>
>>>>>
>>>>> Mailing Lists:
>>>>>      General Discussion: dime@ietf.org
>>>>>      To Subscribe:
> https://www.ietf.org/mailman/listinfo/dime
>>>>>      Archive:
>>>>> http://www.ietf.org/mail-archive/web/dime/current/maillist.html
>>>>>
>>>>> Description of Working Group:
>>>>>
>>>>> The Diameter Maintenance and Extensions WG will focus on
>> maintenance and
>>>>> extensions to the Diameter protocol required to enable its use for
>>>>> authentication, authorization, accounting, charging in network
>> access,
>>>>> provisioning of configuration information within the network, and
>> for
>>>>> new AAA session management uses within the extensibility rules of
>> the
>>>>> Diameter base protocol.
>>>>>
>>>>> The DIME working group plans to address the following items:
>>>>>
>>>>> - Maintaining and/or progressing, along the standards track, the
>>>>> Diameter Base protocol and Diameter Applications. This includes
>>>>> extensions to Diameter Base protocol that can be considered as
>> enhanced
>>>>> features or bug fixes.
>>>>>
>>>>> - Diameter application design guideline. This document will
> provide
>>>>> guidelines for design of Diameter extensions. It will detail when
>> to
>>>>> consider reusing an existing application and when to develop a new
>>>>> application.
>>>>>
>>>>> - Protocol extensions for the management of Diameter entities.
> This
>> work
>>>>> focuses on the standardization of Management Information Bases
>> (MIBs) to
>>>>> configure Diameter entities (such as the Diameter Base protocol or
>>>>> Diameter Credit Control nodes). The usage of other management
>> protocols
>>>>> for configuring Diameter entities may be future work within the
>> group.
>>>>>
>>>>> - Protocol extensions for bulk and grouped AAA session management.
>> The
>>>>> aim of this work is to study and standardize a solution for
>> handling
>>>>> groups of AAA sessions within the Diameter base protocol context.
>> The
>>>>> solution would define how to identify and handle grouped AAA
>> sessions in
>>>>> commands and operations.
>>>>>
>>>>> Additionally, Diameter-based systems require interoperability in
>> order
>>>>> to work. The working group, along with the AD, will need to
>> evaluate any
>>>>> potential extensions and require verification that the proposed
>>>>> extension is needed, and is within the extensibility rules of
>> Diameter
>>>>> and AAA scope. Coordination with other IETF working groups and
>> other
>>>>> SDOs (e.g. 3GPP) will be used to ensure this.
>>>>>
>>>>> Goals and Milestones:
>>>>>
>>>>> Done     - Submit the following two Diameter Mobility documents to
>> the
>>>>>             IESG for consideration as a Proposed Standards:*
>> 'Diameter
>>>>>             Mobile IPv6: Support for Home Agent to Diameter Server
>>>>>             Interaction' * 'Diameter Mobile IPv6: Support for
>> Network
>>>>>             Access Server to Diameter Server Interaction'
>>>>> Done     - Submit 'Diameter API' to the IESG for consideration as
>> an
>>>>>             Informational RFC
>>>>> Done     - Submit 'Quality of Service Parameters for Usage with
>>>>>             Diameter' to the IESG for consideration as a Proposed
>>>>>             Standard.
>>>>> Done     - Submit 'Diameter QoS Application' to the IESG for
>>>>>             consideration as a Proposed Standard
>>>>> Done     - Submit 'Diameter Support for EAP Re-authentication
>>>>>             Protocol' as DIME working group item
>>>>> Done     - Submit 'Diameter User-Name and Realm Based Request
>> Routing
>>>>>             Clarifications' as DIME working group item
>>>>> Done     - Submit 'Diameter Proxy Mobile IPv6' as DIME working
>> group
>>>>>             item
>>>>> Done     - Submit 'Quality of Service Attributes for Diameter' to
>> the
>>>>>             IESG for consideration as a Proposed Standard
>>>>> Done     - Submit 'Diameter Proxy Mobile IPv6' to the IESG for
>>>>>             consideration as a Proposed Standard
>>>>> Done     - Submit 'Diameter User-Name and Realm Based Request
>> Routing
>>>>>             Clarifications' to the IESG for consideration as a
>> Proposed
>>>>>             Standard
>>>>> Done     - Submit 'Diameter NAT Control Application' as DIME
>> working
>>>>>             group item
>>>>> Done     - Submit 'Diameter Capabilities Update' as DIME working
>> group
>>>>>             item
>>>>> Done     - Submit 'Diameter Credit Control Application MIB' to the
>>>>>             IESG for consideration as an Informational RFC
>>>>> Done     - Submit 'Diameter Base Protocol MIB' to the IESG for
>>>>>             consideration as an Informational RFC
>>>>> Done     - Submit 'Diameter Capabilities Update' to the IESG for
>>>>>             consideration as a Proposed Standard
>>>>> Done     - Submit 'Diameter Extended NAPTR' as DIME working group
>> item
>>>>> Done     - Submit 'Realm-Based Redirection In Diameter' as DIME
>>>>>             working group item
>>>>> Done     - Submit 'Diameter Support for Proxy Mobile IPv6
> Localized
>>>>>             Routing' as DIME working group item
>>>>> Done     - Submit 'Diameter Attribute-Value Pairs for
> Cryptographic
>>>>>             Key Transport' as DIME working group item
>>>>> Done     - Submit 'Diameter Priority Attribute Value Pairs' as
> DIME
>>>>>             working group item
>>>>> Done     - Submit 'Diameter IKEv2 PSK' as DIME working group item
>>>>> Done     - Submit Revision of 'Diameter Base Protocol' to the IESG
>> for
>>>>>             consideration as a Proposed Standard
>>>>> Done     - Submit 'Diameter Attribute-Value Pairs for
> Cryptographic
>>>>>             Key Transport' to the IESG for consideration as a
>> Proposed
>>>>>             Standard
>>>>> Done     - Submit 'Diameter Priority Attribute Value Pairs' to the
>>>>>             IESG for consideration as a Proposed Standard
>>>>> Done     - Submit Revision of 'Diameter Network Access Server
>>>>>             Application - RFC 4005bis' as DIME working group item
>>>>> Done     - Submit 'Diameter NAT Control Application' to the IESG
>> for
>>>>>             consideration as a Proposed Standard
>>>>> Done     - Submit 'Diameter IKEv2 PSK' to the IESG for
>> consideration
>>>>>             as a Proposed Standard
>>>>> Done     - Submit 'Diameter Extended NAPTR' to the IESG for
>>>>>             consideration as a Proposed Standard
>>>>> Done     - Submit 'Diameter Support for Proxy Mobile IPv6
> Localized
>>>>>             Routing' to the IESG for consideration as a Proposed
>>>>> Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the
> IESG
>>>>>             for consideration as a Proposed Standard
>>>>> Mar 2012 - Submit Revision of 'Diameter Network Access Server
>>>>>             Application - RFC 4005bis' to the IESG for
>> consideration as a
>>>>>             Proposed Standard
>>>>> May 2012 - Submit 'Diameter Application Design Guidelines' to the
>> IESG
>>>>>             for consideration as a BCP document Standard
>>>>> Jul 2012 - Submit 'Diameter Support for EAP Re-authentication
>>>>>             Protocol' to the IESG for consideration as a Proposed
>>>>>             Standard
>>>>> Aug 2012 - Submit a document on 'Protocol extension for bulk and
>> group
>>>>>             signaling' as a working group item
>>>>> Aug 2013 - Submit a document on 'Protocol extension for bulk and
>> group
>>>>>             signaling' to the IESG for consideration as a Proposed
>>>>>             Standard
>>>>> _______________________________________________
>>>>> IETF-Announce mailing list
>>>>> IETF-Announce@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>>>>
>>>> _______________________________________________
>>>> Ietf mailing list
>>>> Ietf@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ietf
>>>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
--Boundary_(ID_CJ0OBoOpPYNtfrO0+8V4aQ)-- From internet-drafts@ietf.org Fri Jan 13 03:06:57 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C57421F8617; Fri, 13 Jan 2012 03:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 E6s9DOkMDbCV; Fri, 13 Jan 2012 03:06:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D028421F8625; Fri, 13 Jan 2012 03:06:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120113110656.28041.65812.idtracker@ietfa.amsl.com> Date: Fri, 13 Jan 2012 03:06:56 -0800 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-erp-08.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 11:06:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions W= orking Group of the IETF. Title : Diameter support for EAP Re-authentication Protocol (ERP) Author(s) : Julien Bournelle Lionel Morand Sebastien Decugis Qin Wu Glen Zorn Filename : draft-ietf-dime-erp-08.txt Pages : 16 Date : 2012-01-13 The EAP Re-authentication Protocol (ERP) defines extensions to the Extensible Authentication Protocol (EAP) to support efficient re- authentication between the peer and an EAP Re-authentication (ER) server through a compatible authenticator. This document specifies Diameter support for ERP. It defines a new Diameter ERP application to transport ERP messages between an ER authenticator and the ER server, and a set of new AVPs that can be used to transport the cryptographic material needed by the re-authentication server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-erp-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-erp-08.txt From glenzorn@gmail.com Fri Jan 13 03:16:52 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE7221F8625 for ; Fri, 13 Jan 2012 03:16:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] 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 kcmgtZhpwedf for ; Fri, 13 Jan 2012 03:16:51 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D403721F8525 for ; Fri, 13 Jan 2012 03:16:51 -0800 (PST) Received: by obcwo10 with SMTP id wo10so2522534obc.31 for ; Fri, 13 Jan 2012 03:16:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=eabKZ7ZCP8mJJS03uJ7mlWUvmnhy+rVyvTcekaPcYdE=; b=EKfmyJBPPngnsR2ZRWqzYjjj4Kokkn7za+1NxbqeP1Kt3tGQHk5Y4YbWvR+BFosgP6 5XQUh7dooL2PfI4rV04rEte3GQQsAH08uYVrJCqxipQymRhvWOxurp8Ee/1q4sawShPP 424w7tXcYbFsVXP8/G8l+oKWo7R56SRCTePw4= Received: by 10.50.189.194 with SMTP id gk2mr6004271igc.0.1326453411456; Fri, 13 Jan 2012 03:16:51 -0800 (PST) Received: from [192.168.1.98] (ppp-124-122-159-242.revip2.asianet.co.th. [124.122.159.242]) by mx.google.com with ESMTPS id r18sm27941530ibh.4.2012.01.13.03.16.48 (version=SSLv3 cipher=OTHER); Fri, 13 Jan 2012 03:16:50 -0800 (PST) Message-ID: <4F10129C.1040103@gmail.com> Date: Fri, 13 Jan 2012 18:16:44 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: dime-chairs@tools.ietf.org References: <20120113110656.28041.65812.idtracker@ietfa.amsl.com> In-Reply-To: <20120113110656.28041.65812.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] I-D Action: draft-ietf-dime-erp-08.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 11:16:52 -0000 On 1/13/2012 6:06 PM, internet-drafts@ietf.org wrote: I think this draft is ready for WGLC. Any chance we could get that started this month? > > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. > > Title : Diameter support for EAP Re-authentication Protocol (ERP) > Author(s) : Julien Bournelle > Lionel Morand > Sebastien Decugis > Qin Wu > Glen Zorn > Filename : draft-ietf-dime-erp-08.txt > Pages : 16 > Date : 2012-01-13 > > The EAP Re-authentication Protocol (ERP) defines extensions to the > Extensible Authentication Protocol (EAP) to support efficient re- > authentication between the peer and an EAP Re-authentication (ER) > server through a compatible authenticator. This document specifies > Diameter support for ERP. It defines a new Diameter ERP application > to transport ERP messages between an ER authenticator and the ER > server, and a set of new AVPs that can be used to transport the > cryptographic material needed by the re-authentication server. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dime-erp-08.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-erp-08.txt > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From glenzorn@gmail.com Fri Jan 13 04:23:25 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C229B21F8599; Fri, 13 Jan 2012 04:23:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.272 X-Spam-Level: X-Spam-Status: No, score=-3.272 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 qVY-ZvVdPjpK; Fri, 13 Jan 2012 04:23:24 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 608D621F84DE; Fri, 13 Jan 2012 04:23:24 -0800 (PST) Received: by iaae16 with SMTP id e16so4496576iaa.31 for ; Fri, 13 Jan 2012 04:23:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=uQWT4ib+X6+DaX+BHau+6291+W1quzhUPmxF6zk1Mcc=; b=RKmdNMSdiEVM0+TYx4rfpRvBMAvY57tFwJULlnEIjFH9vsb/6HyJJI+A4R5aJyFYUl Z6nNGV5+Y6ByiIpDOKg3MLV7YgEKlR5hK9vsPWPrNH8iDoLl0HzI0RWkYckUW816ZNzK PP+SxO+jt+x6U5VQ0b9KF2B6GA08WfDrpM0v4= Received: by 10.42.73.138 with SMTP id s10mr455913icj.38.1326457401649; Fri, 13 Jan 2012 04:23:21 -0800 (PST) Received: from [192.168.1.98] (ppp-124-122-159-242.revip2.asianet.co.th. [124.122.159.242]) by mx.google.com with ESMTPS id x18sm28514120ibi.2.2012.01.13.04.23.16 (version=SSLv3 cipher=OTHER); Fri, 13 Jan 2012 04:23:20 -0800 (PST) Message-ID: <4F102230.1000905@gmail.com> Date: Fri, 13 Jan 2012 19:23:12 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <20120111163717.591B021F87EF@ietfa.amsl.com><4F0DC78D.2010809@cs.tcd.ie> <4F0ECE57.3020900@cs.tcd.ie> <4F0FA62D.4090808@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF-Discussion , jouni.korhonen@nsn.com, lionel.morand@orange-ftgroup.com, dime@ietf.org, iesg@ietf.org, Stephen Farrell Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions (dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 12:23:25 -0000 On 1/13/2012 1:14 PM, Romascanu, Dan (Dan) wrote: > Thanks, Glen! Can we see (at least) a couple of more hands from people > willing to participate in the editing of this document? Personally, I think that one editor is enough ;-). I think that we could use some people providing technical expertise, though... > > Dan > > > > -----Original Message----- > From: Glen Zorn [mailto:glenzorn@gmail.com] > Sent: Fri 1/13/2012 5:34 AM > To: Romascanu, Dan (Dan) > Cc: Stephen Farrell; jouni korhonen; jouni.korhonen@nsn.com; > lionel.morand@orange-ftgroup.com; dime@ietf.org; IETF-Discussion; > iesg@ietf.org > Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and > Extensions (dime) > > On 1/12/2012 7:15 PM, Romascanu, Dan (Dan) wrote: >> Hi, >> >> If a number of hands were raised now and the folks commanding them say >> 'we are ready to work on this NOW' I would support including explicit >> wording in the charter. > > Consider my hand raised. > > If this does not happen until the telechat next >> week the current text is good enough to allow interested people to start >> working on contributions that can be individual submissions. If these >> submissions are consistent enough the WG can add the milestone later in >> the charter and adopt the submissions as WG items. >> >> Dan >> >> >> >> >> >>> -----Original Message----- >>> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf >> Of >>> Stephen Farrell >>> Sent: Thursday, January 12, 2012 2:13 PM >>> To: jouni korhonen >>> Cc: jouni.korhonen@nsn.com; lionel.morand@orange-ftgroup.com; >>> dime@ietf.org; IETF-Discussion; iesg@ietf.org >>> Subject: Re: WG Review: Recharter of Diameter Maintenance and >>> Extensions (dime) >>> >>> >>> Hi Jouni, >>> >>> Right, I'm trying to encourage this - I'm not trying >>> to make it a gating function for the recharter. Its >>> still worth doing though if we can find some victims >>> with enough energy:-) >>> >>> I agree that the current charter text might not need >>> to be modified, OTOH, if there were folks who wanted to >>> do the work, a milestone might be good. I also agree >>> that as of now, that addition is not warranted. >>> >>> Cheers, >>> S >>> >>> On 01/12/2012 12:08 PM, jouni korhonen wrote: >>>> >>>> Stephen, >>>> >>>> This topic raises its head every now and then when a Dime >>>> document arrives at IESG ;) Apart from that there has been >>>> very little serious public discussion about it recently, >>>> for some unknown reason to me. A detail worth pointing out >>>> is that the support for the End-to-End security framework >>>> (E2E-Sequence AVP and 'P'-bit in the AVP header) has been >>>> deprecated in RFC3588bis (now in IESG). So we are "free" >>>> to start from scratch. >>>> >>>> If there is enough serious energy and vision for pursuing >>>> end-to-end security, I do not see current proposed charter >>>> text prohibiting it: >>>> >>>> "- Maintaining and/or progressing, along the standards track, the >>>> Diameter Base protocol and Diameter Applications. This includes >>>> extensions to Diameter Base protocol that can be considered as >>>> enhanced features or bug fixes." >>>> >>>> I would argue the end-to-end security is an enhanced feature for >>>> Diameter base protocol that fixes a serious bug/flaw in security. >>>> On the other hand, if an explicit note is needed about this topic >>>> in the charter, I might hesitate to include such in this round. >>>> I would first like to see some concrete movement& work around >>>> this topic. >>>> >>>> - Jouni >>>> >>>> >>>> >>>> On Jan 11, 2012, at 7:31 PM, Stephen Farrell wrote: >>>> >>>>> >>>>> Hi, >>>>> >>>>> During the IESG internal review of this I asked whether >>>>> or not there was interest in trying to tackle end to >>>>> end security for AVPs. I do know there is at least some >>>>> interest in that but its not clear there's enough to >>>>> warrant including it in the re-charter so I said I'd >>>>> ask when the recharter went out for review... >>>>> >>>>> So - anyone interested in DIME solving that problem? >>>>> (And willing and able to help do the work of course.) >>>>> >>>>> As of now, Diameter really only has hop-by-hop security >>>>> which is ok in many cases but far from ideal (wearing >>>>> my security hat) in some. >>>>> >>>>> Thanks, >>>>> Stephen. >>>>> >>>>> On 01/11/2012 04:37 PM, IESG Secretary wrote: >>>>>> A modified charter has been submitted for the Diameter Maintenance >>> and >>>>>> Extensions (dime) working group in the Operations and Management >>> Area of >>>>>> the IETF. The IESG has not made any determination as yet. The >>> modified >>>>>> charter is provided below for informational purposes only. Please >>> send >>>>>> your comments to the IESG mailing list (iesg@ietf.org) by >>> Wednesday, >>>>>> January 18, 2012. >>>>>> >>>>>> Diameter Maintenance and Extensions (dime) >>>>>> ----------------------------------------- >>>>>> Current Status: Active >>>>>> >>>>>> Last Modified: 2012-01-10 >>>>>> >>>>>> Chairs: >>>>>> Lionel Morand >>>>>> Jouni Korhonen >>>>>> >>>>>> Operations and Management Area Directors: >>>>>> Dan Romascanu >>>>>> Ronald Bonica >>>>>> >>>>>> Operations and Management Area Advisor: >>>>>> Dan Romascanu >>>>>> >>>>>> Mailing Lists: >>>>>> General Discussion: dime@ietf.org >>>>>> To Subscribe: >> https://www.ietf.org/mailman/listinfo/dime >>>>>> Archive: >>>>>> http://www.ietf.org/mail-archive/web/dime/current/maillist.html >>>>>> >>>>>> Description of Working Group: >>>>>> >>>>>> The Diameter Maintenance and Extensions WG will focus on >>> maintenance and >>>>>> extensions to the Diameter protocol required to enable its use for >>>>>> authentication, authorization, accounting, charging in network >>> access, >>>>>> provisioning of configuration information within the network, and >>> for >>>>>> new AAA session management uses within the extensibility rules of >>> the >>>>>> Diameter base protocol. >>>>>> >>>>>> The DIME working group plans to address the following items: >>>>>> >>>>>> - Maintaining and/or progressing, along the standards track, the >>>>>> Diameter Base protocol and Diameter Applications. This includes >>>>>> extensions to Diameter Base protocol that can be considered as >>> enhanced >>>>>> features or bug fixes. >>>>>> >>>>>> - Diameter application design guideline. This document will >> provide >>>>>> guidelines for design of Diameter extensions. It will detail when >>> to >>>>>> consider reusing an existing application and when to develop a new >>>>>> application. >>>>>> >>>>>> - Protocol extensions for the management of Diameter entities. >> This >>> work >>>>>> focuses on the standardization of Management Information Bases >>> (MIBs) to >>>>>> configure Diameter entities (such as the Diameter Base protocol or >>>>>> Diameter Credit Control nodes). The usage of other management >>> protocols >>>>>> for configuring Diameter entities may be future work within the >>> group. >>>>>> >>>>>> - Protocol extensions for bulk and grouped AAA session management. >>> The >>>>>> aim of this work is to study and standardize a solution for >>> handling >>>>>> groups of AAA sessions within the Diameter base protocol context. >>> The >>>>>> solution would define how to identify and handle grouped AAA >>> sessions in >>>>>> commands and operations. >>>>>> >>>>>> Additionally, Diameter-based systems require interoperability in >>> order >>>>>> to work. The working group, along with the AD, will need to >>> evaluate any >>>>>> potential extensions and require verification that the proposed >>>>>> extension is needed, and is within the extensibility rules of >>> Diameter >>>>>> and AAA scope. Coordination with other IETF working groups and >>> other >>>>>> SDOs (e.g. 3GPP) will be used to ensure this. >>>>>> >>>>>> Goals and Milestones: >>>>>> >>>>>> Done - Submit the following two Diameter Mobility documents to >>> the >>>>>> IESG for consideration as a Proposed Standards:* >>> 'Diameter >>>>>> Mobile IPv6: Support for Home Agent to Diameter Server >>>>>> Interaction' * 'Diameter Mobile IPv6: Support for >>> Network >>>>>> Access Server to Diameter Server Interaction' >>>>>> Done - Submit 'Diameter API' to the IESG for consideration as >>> an >>>>>> Informational RFC >>>>>> Done - Submit 'Quality of Service Parameters for Usage with >>>>>> Diameter' to the IESG for consideration as a Proposed >>>>>> Standard. >>>>>> Done - Submit 'Diameter QoS Application' to the IESG for >>>>>> consideration as a Proposed Standard >>>>>> Done - Submit 'Diameter Support for EAP Re-authentication >>>>>> Protocol' as DIME working group item >>>>>> Done - Submit 'Diameter User-Name and Realm Based Request >>> Routing >>>>>> Clarifications' as DIME working group item >>>>>> Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working >>> group >>>>>> item >>>>>> Done - Submit 'Quality of Service Attributes for Diameter' to >>> the >>>>>> IESG for consideration as a Proposed Standard >>>>>> Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for >>>>>> consideration as a Proposed Standard >>>>>> Done - Submit 'Diameter User-Name and Realm Based Request >>> Routing >>>>>> Clarifications' to the IESG for consideration as a >>> Proposed >>>>>> Standard >>>>>> Done - Submit 'Diameter NAT Control Application' as DIME >>> working >>>>>> group item >>>>>> Done - Submit 'Diameter Capabilities Update' as DIME working >>> group >>>>>> item >>>>>> Done - Submit 'Diameter Credit Control Application MIB' to the >>>>>> IESG for consideration as an Informational RFC >>>>>> Done - Submit 'Diameter Base Protocol MIB' to the IESG for >>>>>> consideration as an Informational RFC >>>>>> Done - Submit 'Diameter Capabilities Update' to the IESG for >>>>>> consideration as a Proposed Standard >>>>>> Done - Submit 'Diameter Extended NAPTR' as DIME working group >>> item >>>>>> Done - Submit 'Realm-Based Redirection In Diameter' as DIME >>>>>> working group item >>>>>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 >> Localized >>>>>> Routing' as DIME working group item >>>>>> Done - Submit 'Diameter Attribute-Value Pairs for >> Cryptographic >>>>>> Key Transport' as DIME working group item >>>>>> Done - Submit 'Diameter Priority Attribute Value Pairs' as >> DIME >>>>>> working group item >>>>>> Done - Submit 'Diameter IKEv2 PSK' as DIME working group item >>>>>> Done - Submit Revision of 'Diameter Base Protocol' to the IESG >>> for >>>>>> consideration as a Proposed Standard >>>>>> Done - Submit 'Diameter Attribute-Value Pairs for >> Cryptographic >>>>>> Key Transport' to the IESG for consideration as a >>> Proposed >>>>>> Standard >>>>>> Done - Submit 'Diameter Priority Attribute Value Pairs' to the >>>>>> IESG for consideration as a Proposed Standard >>>>>> Done - Submit Revision of 'Diameter Network Access Server >>>>>> Application - RFC 4005bis' as DIME working group item >>>>>> Done - Submit 'Diameter NAT Control Application' to the IESG >>> for >>>>>> consideration as a Proposed Standard >>>>>> Done - Submit 'Diameter IKEv2 PSK' to the IESG for >>> consideration >>>>>> as a Proposed Standard >>>>>> Done - Submit 'Diameter Extended NAPTR' to the IESG for >>>>>> consideration as a Proposed Standard >>>>>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 >> Localized >>>>>> Routing' to the IESG for consideration as a Proposed >>>>>> Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the >> IESG >>>>>> for consideration as a Proposed Standard >>>>>> Mar 2012 - Submit Revision of 'Diameter Network Access Server >>>>>> Application - RFC 4005bis' to the IESG for >>> consideration as a >>>>>> Proposed Standard >>>>>> May 2012 - Submit 'Diameter Application Design Guidelines' to the >>> IESG >>>>>> for consideration as a BCP document Standard >>>>>> Jul 2012 - Submit 'Diameter Support for EAP Re-authentication >>>>>> Protocol' to the IESG for consideration as a Proposed >>>>>> Standard >>>>>> Aug 2012 - Submit a document on 'Protocol extension for bulk and >>> group >>>>>> signaling' as a working group item >>>>>> Aug 2013 - Submit a document on 'Protocol extension for bulk and >>> group >>>>>> signaling' to the IESG for consideration as a Proposed >>>>>> Standard >>>>>> _______________________________________________ >>>>>> IETF-Announce mailing list >>>>>> IETF-Announce@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>>>>> >>>>> _______________________________________________ >>>>> Ietf mailing list >>>>> Ietf@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ietf >>>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > > From hannes.tschofenig@gmx.net Fri Jan 13 05:01:31 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCC621F8671 for ; Fri, 13 Jan 2012 05:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 74YKg10X8goK for ; Fri, 13 Jan 2012 05:01:30 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id C0AD521F8665 for ; Fri, 13 Jan 2012 05:01:29 -0800 (PST) Received: (qmail invoked by alias); 13 Jan 2012 13:01:25 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.103]) [88.115.216.191] by mail.gmx.net (mp033) with SMTP; 13 Jan 2012 14:01:25 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18yclsqCNUy/t8c6QVzL8HoqEQC9x4/Y2fjd+Ag9Q +vARF5r8mgc+Ch Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4F102230.1000905@gmail.com> Date: Fri, 13 Jan 2012 15:01:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <03BB1E4C-63F2-407C-B36B-B614E5185739@gmx.net> References: <20120111163717.591B021F87EF@ietfa.amsl.com><4F0DC78D.2010809@cs.tcd.ie> <4F0ECE57.3020900@cs.tcd.ie> <4F0FA62D.4090808@gmail.com> <4F102230.1000905@gmail.com> To: Glen Zorn X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: IETF-Discussion , Jouni Korhonen , Lionel Morand , dime@ietf.org, Stephen Farrell Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions (dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 13:01:31 -0000 Regarding end-to-end security: I believe we should separate the = procedure for establishing the keys from the actual protection.=20 I could imagine a couple of different ways to establish the keys.=20 Does that sound reasonable? On Jan 13, 2012, at 2:23 PM, Glen Zorn wrote: > On 1/13/2012 1:14 PM, Romascanu, Dan (Dan) wrote: >=20 >> Thanks, Glen! Can we see (at least) a couple of more hands from = people >> willing to participate in the editing of this document? >=20 > Personally, I think that one editor is enough ;-). I think that we > could use some people providing technical expertise, though... >=20 >>=20 >> Dan >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Glen Zorn [mailto:glenzorn@gmail.com] >> Sent: Fri 1/13/2012 5:34 AM >> To: Romascanu, Dan (Dan) >> Cc: Stephen Farrell; jouni korhonen; jouni.korhonen@nsn.com; >> lionel.morand@orange-ftgroup.com; dime@ietf.org; IETF-Discussion; >> iesg@ietf.org >> Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and >> Extensions (dime) >>=20 >> On 1/12/2012 7:15 PM, Romascanu, Dan (Dan) wrote: >>> Hi, >>>=20 >>> If a number of hands were raised now and the folks commanding them = say >>> 'we are ready to work on this NOW' I would support including = explicit >>> wording in the charter. >>=20 >> Consider my hand raised. >>=20 >> If this does not happen until the telechat next >>> week the current text is good enough to allow interested people to = start >>> working on contributions that can be individual submissions. If = these >>> submissions are consistent enough the WG can add the milestone later = in >>> the charter and adopt the submissions as WG items. >>>=20 >>> Dan >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On = Behalf >>> Of >>>> Stephen Farrell >>>> Sent: Thursday, January 12, 2012 2:13 PM >>>> To: jouni korhonen >>>> Cc: jouni.korhonen@nsn.com; lionel.morand@orange-ftgroup.com; >>>> dime@ietf.org; IETF-Discussion; iesg@ietf.org >>>> Subject: Re: WG Review: Recharter of Diameter Maintenance and >>>> Extensions (dime) >>>>=20 >>>>=20 >>>> Hi Jouni, >>>>=20 >>>> Right, I'm trying to encourage this - I'm not trying >>>> to make it a gating function for the recharter. Its >>>> still worth doing though if we can find some victims >>>> with enough energy:-) >>>>=20 >>>> I agree that the current charter text might not need >>>> to be modified, OTOH, if there were folks who wanted to >>>> do the work, a milestone might be good. I also agree >>>> that as of now, that addition is not warranted. >>>>=20 >>>> Cheers, >>>> S >>>>=20 >>>> On 01/12/2012 12:08 PM, jouni korhonen wrote: >>>>>=20 >>>>> Stephen, >>>>>=20 >>>>> This topic raises its head every now and then when a Dime >>>>> document arrives at IESG ;) Apart from that there has been >>>>> very little serious public discussion about it recently, >>>>> for some unknown reason to me. A detail worth pointing out >>>>> is that the support for the End-to-End security framework >>>>> (E2E-Sequence AVP and 'P'-bit in the AVP header) has been >>>>> deprecated in RFC3588bis (now in IESG). So we are "free" >>>>> to start from scratch. >>>>>=20 >>>>> If there is enough serious energy and vision for pursuing >>>>> end-to-end security, I do not see current proposed charter >>>>> text prohibiting it: >>>>>=20 >>>>> "- Maintaining and/or progressing, along the standards track, the >>>>> Diameter Base protocol and Diameter Applications. This includes >>>>> extensions to Diameter Base protocol that can be considered as >>>>> enhanced features or bug fixes." >>>>>=20 >>>>> I would argue the end-to-end security is an enhanced feature for >>>>> Diameter base protocol that fixes a serious bug/flaw in security. >>>>> On the other hand, if an explicit note is needed about this topic >>>>> in the charter, I might hesitate to include such in this round. >>>>> I would first like to see some concrete movement& work around >>>>> this topic. >>>>>=20 >>>>> - Jouni >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Jan 11, 2012, at 7:31 PM, Stephen Farrell wrote: >>>>>=20 >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> During the IESG internal review of this I asked whether >>>>>> or not there was interest in trying to tackle end to >>>>>> end security for AVPs. I do know there is at least some >>>>>> interest in that but its not clear there's enough to >>>>>> warrant including it in the re-charter so I said I'd >>>>>> ask when the recharter went out for review... >>>>>>=20 >>>>>> So - anyone interested in DIME solving that problem? >>>>>> (And willing and able to help do the work of course.) >>>>>>=20 >>>>>> As of now, Diameter really only has hop-by-hop security >>>>>> which is ok in many cases but far from ideal (wearing >>>>>> my security hat) in some. >>>>>>=20 >>>>>> Thanks, >>>>>> Stephen. >>>>>>=20 >>>>>> On 01/11/2012 04:37 PM, IESG Secretary wrote: >>>>>>> A modified charter has been submitted for the Diameter = Maintenance >>>> and >>>>>>> Extensions (dime) working group in the Operations and Management >>>> Area of >>>>>>> the IETF. The IESG has not made any determination as yet. The >>>> modified >>>>>>> charter is provided below for informational purposes only. = Please >>>> send >>>>>>> your comments to the IESG mailing list (iesg@ietf.org) by >>>> Wednesday, >>>>>>> January 18, 2012. >>>>>>>=20 >>>>>>> Diameter Maintenance and Extensions (dime) >>>>>>> ----------------------------------------- >>>>>>> Current Status: Active >>>>>>>=20 >>>>>>> Last Modified: 2012-01-10 >>>>>>>=20 >>>>>>> Chairs: >>>>>>> Lionel Morand >>>>>>> Jouni Korhonen >>>>>>>=20 >>>>>>> Operations and Management Area Directors: >>>>>>> Dan Romascanu >>>>>>> Ronald Bonica >>>>>>>=20 >>>>>>> Operations and Management Area Advisor: >>>>>>> Dan Romascanu >>>>>>>=20 >>>>>>> Mailing Lists: >>>>>>> General Discussion: dime@ietf.org >>>>>>> To Subscribe: >>> https://www.ietf.org/mailman/listinfo/dime >>>>>>> Archive: >>>>>>> http://www.ietf.org/mail-archive/web/dime/current/maillist.html >>>>>>>=20 >>>>>>> Description of Working Group: >>>>>>>=20 >>>>>>> The Diameter Maintenance and Extensions WG will focus on >>>> maintenance and >>>>>>> extensions to the Diameter protocol required to enable its use = for >>>>>>> authentication, authorization, accounting, charging in network >>>> access, >>>>>>> provisioning of configuration information within the network, = and >>>> for >>>>>>> new AAA session management uses within the extensibility rules = of >>>> the >>>>>>> Diameter base protocol. >>>>>>>=20 >>>>>>> The DIME working group plans to address the following items: >>>>>>>=20 >>>>>>> - Maintaining and/or progressing, along the standards track, the >>>>>>> Diameter Base protocol and Diameter Applications. This includes >>>>>>> extensions to Diameter Base protocol that can be considered as >>>> enhanced >>>>>>> features or bug fixes. >>>>>>>=20 >>>>>>> - Diameter application design guideline. This document will >>> provide >>>>>>> guidelines for design of Diameter extensions. It will detail = when >>>> to >>>>>>> consider reusing an existing application and when to develop a = new >>>>>>> application. >>>>>>>=20 >>>>>>> - Protocol extensions for the management of Diameter entities. >>> This >>>> work >>>>>>> focuses on the standardization of Management Information Bases >>>> (MIBs) to >>>>>>> configure Diameter entities (such as the Diameter Base protocol = or >>>>>>> Diameter Credit Control nodes). The usage of other management >>>> protocols >>>>>>> for configuring Diameter entities may be future work within the >>>> group. >>>>>>>=20 >>>>>>> - Protocol extensions for bulk and grouped AAA session = management. >>>> The >>>>>>> aim of this work is to study and standardize a solution for >>>> handling >>>>>>> groups of AAA sessions within the Diameter base protocol = context. >>>> The >>>>>>> solution would define how to identify and handle grouped AAA >>>> sessions in >>>>>>> commands and operations. >>>>>>>=20 >>>>>>> Additionally, Diameter-based systems require interoperability in >>>> order >>>>>>> to work. The working group, along with the AD, will need to >>>> evaluate any >>>>>>> potential extensions and require verification that the proposed >>>>>>> extension is needed, and is within the extensibility rules of >>>> Diameter >>>>>>> and AAA scope. Coordination with other IETF working groups and >>>> other >>>>>>> SDOs (e.g. 3GPP) will be used to ensure this. >>>>>>>=20 >>>>>>> Goals and Milestones: >>>>>>>=20 >>>>>>> Done - Submit the following two Diameter Mobility documents = to >>>> the >>>>>>> IESG for consideration as a Proposed Standards:* >>>> 'Diameter >>>>>>> Mobile IPv6: Support for Home Agent to Diameter = Server >>>>>>> Interaction' * 'Diameter Mobile IPv6: Support for >>>> Network >>>>>>> Access Server to Diameter Server Interaction' >>>>>>> Done - Submit 'Diameter API' to the IESG for consideration = as >>>> an >>>>>>> Informational RFC >>>>>>> Done - Submit 'Quality of Service Parameters for Usage with >>>>>>> Diameter' to the IESG for consideration as a Proposed >>>>>>> Standard. >>>>>>> Done - Submit 'Diameter QoS Application' to the IESG for >>>>>>> consideration as a Proposed Standard >>>>>>> Done - Submit 'Diameter Support for EAP Re-authentication >>>>>>> Protocol' as DIME working group item >>>>>>> Done - Submit 'Diameter User-Name and Realm Based Request >>>> Routing >>>>>>> Clarifications' as DIME working group item >>>>>>> Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working >>>> group >>>>>>> item >>>>>>> Done - Submit 'Quality of Service Attributes for Diameter' = to >>>> the >>>>>>> IESG for consideration as a Proposed Standard >>>>>>> Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for >>>>>>> consideration as a Proposed Standard >>>>>>> Done - Submit 'Diameter User-Name and Realm Based Request >>>> Routing >>>>>>> Clarifications' to the IESG for consideration as a >>>> Proposed >>>>>>> Standard >>>>>>> Done - Submit 'Diameter NAT Control Application' as DIME >>>> working >>>>>>> group item >>>>>>> Done - Submit 'Diameter Capabilities Update' as DIME working >>>> group >>>>>>> item >>>>>>> Done - Submit 'Diameter Credit Control Application MIB' to = the >>>>>>> IESG for consideration as an Informational RFC >>>>>>> Done - Submit 'Diameter Base Protocol MIB' to the IESG for >>>>>>> consideration as an Informational RFC >>>>>>> Done - Submit 'Diameter Capabilities Update' to the IESG for >>>>>>> consideration as a Proposed Standard >>>>>>> Done - Submit 'Diameter Extended NAPTR' as DIME working = group >>>> item >>>>>>> Done - Submit 'Realm-Based Redirection In Diameter' as DIME >>>>>>> working group item >>>>>>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 >>> Localized >>>>>>> Routing' as DIME working group item >>>>>>> Done - Submit 'Diameter Attribute-Value Pairs for >>> Cryptographic >>>>>>> Key Transport' as DIME working group item >>>>>>> Done - Submit 'Diameter Priority Attribute Value Pairs' as >>> DIME >>>>>>> working group item >>>>>>> Done - Submit 'Diameter IKEv2 PSK' as DIME working group = item >>>>>>> Done - Submit Revision of 'Diameter Base Protocol' to the = IESG >>>> for >>>>>>> consideration as a Proposed Standard >>>>>>> Done - Submit 'Diameter Attribute-Value Pairs for >>> Cryptographic >>>>>>> Key Transport' to the IESG for consideration as a >>>> Proposed >>>>>>> Standard >>>>>>> Done - Submit 'Diameter Priority Attribute Value Pairs' to = the >>>>>>> IESG for consideration as a Proposed Standard >>>>>>> Done - Submit Revision of 'Diameter Network Access Server >>>>>>> Application - RFC 4005bis' as DIME working group item >>>>>>> Done - Submit 'Diameter NAT Control Application' to the IESG >>>> for >>>>>>> consideration as a Proposed Standard >>>>>>> Done - Submit 'Diameter IKEv2 PSK' to the IESG for >>>> consideration >>>>>>> as a Proposed Standard >>>>>>> Done - Submit 'Diameter Extended NAPTR' to the IESG for >>>>>>> consideration as a Proposed Standard >>>>>>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 >>> Localized >>>>>>> Routing' to the IESG for consideration as a Proposed >>>>>>> Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the >>> IESG >>>>>>> for consideration as a Proposed Standard >>>>>>> Mar 2012 - Submit Revision of 'Diameter Network Access Server >>>>>>> Application - RFC 4005bis' to the IESG for >>>> consideration as a >>>>>>> Proposed Standard >>>>>>> May 2012 - Submit 'Diameter Application Design Guidelines' to = the >>>> IESG >>>>>>> for consideration as a BCP document Standard >>>>>>> Jul 2012 - Submit 'Diameter Support for EAP Re-authentication >>>>>>> Protocol' to the IESG for consideration as a Proposed >>>>>>> Standard >>>>>>> Aug 2012 - Submit a document on 'Protocol extension for bulk and >>>> group >>>>>>> signaling' as a working group item >>>>>>> Aug 2013 - Submit a document on 'Protocol extension for bulk and >>>> group >>>>>>> signaling' to the IESG for consideration as a = Proposed >>>>>>> Standard >>>>>>> _______________________________________________ >>>>>>> IETF-Announce mailing list >>>>>>> IETF-Announce@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>>>>>>=20 >>>>>> _______________________________________________ >>>>>> Ietf mailing list >>>>>> Ietf@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ietf >>>>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >>=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Mon Jan 16 06:50:28 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3541621F8616; Mon, 16 Jan 2012 06:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.631 X-Spam-Level: X-Spam-Status: No, score=-3.631 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 ZKesKvVnhIcj; Mon, 16 Jan 2012 06:50:27 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 20DAD21F860F; Mon, 16 Jan 2012 06:50:25 -0800 (PST) Received: by lagv3 with SMTP id v3so1903415lag.31 for ; Mon, 16 Jan 2012 06:50:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=HwICT3BSl8RsggkgVoSj4J7TlaWAx5ns34NGVXqMmGE=; b=bajDxDmYJLwxGHThJyeO5MCvOIFl828pVu4QxZl6ugzBIyL3fA4TOtKbz4DmMweQOJ k8xX22AkxaW1TcIqsFEhEvksY0TTgQneymhpbzYnd5kKJ8oVEVq/bImcvNy27kc40Xkn yBXG5NfvfV+u4p1v1KQ23fYz1Lt5GA71x5jus= Received: by 10.152.145.71 with SMTP id ss7mr6001031lab.28.1326725425066; Mon, 16 Jan 2012 06:50:25 -0800 (PST) Received: from a88-112-207-191.elisa-laajakaista.fi (a88-112-207-191.elisa-laajakaista.fi. [88.112.207.191]) by mx.google.com with ESMTPS id k4sm17635003lby.1.2012.01.16.06.50.19 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 Jan 2012 06:50:20 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Mon, 16 Jan 2012 16:50:15 +0200 Content-Transfer-Encoding: 7bit Message-Id: <3EF888CD-2843-440B-AF9A-ACE0CEF33180@gmail.com> References: <20120111163717.591B021F87EF@ietfa.amsl.com><4F0DC78D.2010809@cs.tcd.ie> <4F0ECE57.3020900@cs.tcd.ie> To: Stephen Farrell , "Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.1084) Cc: Jouni Korhonen , "lionel.morand@orange-ftgroup.com> Morand" , dime@ietf.org, IETF-Discussion , "iesg@ietf.org IESG" Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions (dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 14:50:28 -0000 Stephen, Dan, What if we just add a milestone to the charter to indicate that end-to-end security is coming to our table? Jul 2012 - Sumbit 'problem statement and requirements for Diameter end-to-end security framework' as Dime working group item. Dec 2012 - Submit 'problem statement and requirements for Diameter end-to-end security framework' to the IESG for consideration as an Informational RFC. I would give some time folks to work this out.. and then when we actually know what we and especially IETF external deployment folks want, we can move to solution part.. Seems like a relaxed milestone plan but I have doubts it would progress any faster in real life even if milestones were tighter ;) - Jouni On Jan 12, 2012, at 2:15 PM, Romascanu, Dan (Dan) wrote: > Hi, > > If a number of hands were raised now and the folks commanding them say > 'we are ready to work on this NOW' I would support including explicit > wording in the charter. If this does not happen until the telechat next > week the current text is good enough to allow interested people to start > working on contributions that can be individual submissions. If these > submissions are consistent enough the WG can add the milestone later in > the charter and adopt the submissions as WG items. > > Dan > > > > > >> -----Original Message----- >> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf > Of >> Stephen Farrell >> Sent: Thursday, January 12, 2012 2:13 PM >> To: jouni korhonen >> Cc: jouni.korhonen@nsn.com; lionel.morand@orange-ftgroup.com; >> dime@ietf.org; IETF-Discussion; iesg@ietf.org >> Subject: Re: WG Review: Recharter of Diameter Maintenance and >> Extensions (dime) >> >> >> Hi Jouni, >> >> Right, I'm trying to encourage this - I'm not trying >> to make it a gating function for the recharter. Its >> still worth doing though if we can find some victims >> with enough energy:-) >> >> I agree that the current charter text might not need >> to be modified, OTOH, if there were folks who wanted to >> do the work, a milestone might be good. I also agree >> that as of now, that addition is not warranted. >> >> Cheers, >> S >> >> On 01/12/2012 12:08 PM, jouni korhonen wrote: >>> >>> Stephen, >>> >>> This topic raises its head every now and then when a Dime >>> document arrives at IESG ;) Apart from that there has been >>> very little serious public discussion about it recently, >>> for some unknown reason to me. A detail worth pointing out >>> is that the support for the End-to-End security framework >>> (E2E-Sequence AVP and 'P'-bit in the AVP header) has been >>> deprecated in RFC3588bis (now in IESG). So we are "free" >>> to start from scratch. >>> >>> If there is enough serious energy and vision for pursuing >>> end-to-end security, I do not see current proposed charter >>> text prohibiting it: >>> >>> "- Maintaining and/or progressing, along the standards track, the >>> Diameter Base protocol and Diameter Applications. This includes >>> extensions to Diameter Base protocol that can be considered as >>> enhanced features or bug fixes." >>> >>> I would argue the end-to-end security is an enhanced feature for >>> Diameter base protocol that fixes a serious bug/flaw in security. >>> On the other hand, if an explicit note is needed about this topic >>> in the charter, I might hesitate to include such in this round. >>> I would first like to see some concrete movement& work around >>> this topic. >>> >>> - Jouni >>> >>> >>> >>> On Jan 11, 2012, at 7:31 PM, Stephen Farrell wrote: >>> >>>> >>>> Hi, >>>> >>>> During the IESG internal review of this I asked whether >>>> or not there was interest in trying to tackle end to >>>> end security for AVPs. I do know there is at least some >>>> interest in that but its not clear there's enough to >>>> warrant including it in the re-charter so I said I'd >>>> ask when the recharter went out for review... >>>> >>>> So - anyone interested in DIME solving that problem? >>>> (And willing and able to help do the work of course.) >>>> >>>> As of now, Diameter really only has hop-by-hop security >>>> which is ok in many cases but far from ideal (wearing >>>> my security hat) in some. >>>> >>>> Thanks, >>>> Stephen. >>>> >>>> On 01/11/2012 04:37 PM, IESG Secretary wrote: >>>>> A modified charter has been submitted for the Diameter Maintenance >> and >>>>> Extensions (dime) working group in the Operations and Management >> Area of >>>>> the IETF. The IESG has not made any determination as yet. The >> modified >>>>> charter is provided below for informational purposes only. Please >> send >>>>> your comments to the IESG mailing list (iesg@ietf.org) by >> Wednesday, >>>>> January 18, 2012. >>>>> >>>>> Diameter Maintenance and Extensions (dime) >>>>> ----------------------------------------- >>>>> Current Status: Active >>>>> >>>>> Last Modified: 2012-01-10 >>>>> >>>>> Chairs: >>>>> Lionel Morand >>>>> Jouni Korhonen >>>>> >>>>> Operations and Management Area Directors: >>>>> Dan Romascanu >>>>> Ronald Bonica >>>>> >>>>> Operations and Management Area Advisor: >>>>> Dan Romascanu >>>>> >>>>> Mailing Lists: >>>>> General Discussion: dime@ietf.org >>>>> To Subscribe: > https://www.ietf.org/mailman/listinfo/dime >>>>> Archive: >>>>> http://www.ietf.org/mail-archive/web/dime/current/maillist.html >>>>> >>>>> Description of Working Group: >>>>> >>>>> The Diameter Maintenance and Extensions WG will focus on >> maintenance and >>>>> extensions to the Diameter protocol required to enable its use for >>>>> authentication, authorization, accounting, charging in network >> access, >>>>> provisioning of configuration information within the network, and >> for >>>>> new AAA session management uses within the extensibility rules of >> the >>>>> Diameter base protocol. >>>>> >>>>> The DIME working group plans to address the following items: >>>>> >>>>> - Maintaining and/or progressing, along the standards track, the >>>>> Diameter Base protocol and Diameter Applications. This includes >>>>> extensions to Diameter Base protocol that can be considered as >> enhanced >>>>> features or bug fixes. >>>>> >>>>> - Diameter application design guideline. This document will > provide >>>>> guidelines for design of Diameter extensions. It will detail when >> to >>>>> consider reusing an existing application and when to develop a new >>>>> application. >>>>> >>>>> - Protocol extensions for the management of Diameter entities. > This >> work >>>>> focuses on the standardization of Management Information Bases >> (MIBs) to >>>>> configure Diameter entities (such as the Diameter Base protocol or >>>>> Diameter Credit Control nodes). The usage of other management >> protocols >>>>> for configuring Diameter entities may be future work within the >> group. >>>>> >>>>> - Protocol extensions for bulk and grouped AAA session management. >> The >>>>> aim of this work is to study and standardize a solution for >> handling >>>>> groups of AAA sessions within the Diameter base protocol context. >> The >>>>> solution would define how to identify and handle grouped AAA >> sessions in >>>>> commands and operations. >>>>> >>>>> Additionally, Diameter-based systems require interoperability in >> order >>>>> to work. The working group, along with the AD, will need to >> evaluate any >>>>> potential extensions and require verification that the proposed >>>>> extension is needed, and is within the extensibility rules of >> Diameter >>>>> and AAA scope. Coordination with other IETF working groups and >> other >>>>> SDOs (e.g. 3GPP) will be used to ensure this. >>>>> >>>>> Goals and Milestones: >>>>> >>>>> Done - Submit the following two Diameter Mobility documents to >> the >>>>> IESG for consideration as a Proposed Standards:* >> 'Diameter >>>>> Mobile IPv6: Support for Home Agent to Diameter Server >>>>> Interaction' * 'Diameter Mobile IPv6: Support for >> Network >>>>> Access Server to Diameter Server Interaction' >>>>> Done - Submit 'Diameter API' to the IESG for consideration as >> an >>>>> Informational RFC >>>>> Done - Submit 'Quality of Service Parameters for Usage with >>>>> Diameter' to the IESG for consideration as a Proposed >>>>> Standard. >>>>> Done - Submit 'Diameter QoS Application' to the IESG for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Support for EAP Re-authentication >>>>> Protocol' as DIME working group item >>>>> Done - Submit 'Diameter User-Name and Realm Based Request >> Routing >>>>> Clarifications' as DIME working group item >>>>> Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working >> group >>>>> item >>>>> Done - Submit 'Quality of Service Attributes for Diameter' to >> the >>>>> IESG for consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter User-Name and Realm Based Request >> Routing >>>>> Clarifications' to the IESG for consideration as a >> Proposed >>>>> Standard >>>>> Done - Submit 'Diameter NAT Control Application' as DIME >> working >>>>> group item >>>>> Done - Submit 'Diameter Capabilities Update' as DIME working >> group >>>>> item >>>>> Done - Submit 'Diameter Credit Control Application MIB' to the >>>>> IESG for consideration as an Informational RFC >>>>> Done - Submit 'Diameter Base Protocol MIB' to the IESG for >>>>> consideration as an Informational RFC >>>>> Done - Submit 'Diameter Capabilities Update' to the IESG for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Extended NAPTR' as DIME working group >> item >>>>> Done - Submit 'Realm-Based Redirection In Diameter' as DIME >>>>> working group item >>>>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 > Localized >>>>> Routing' as DIME working group item >>>>> Done - Submit 'Diameter Attribute-Value Pairs for > Cryptographic >>>>> Key Transport' as DIME working group item >>>>> Done - Submit 'Diameter Priority Attribute Value Pairs' as > DIME >>>>> working group item >>>>> Done - Submit 'Diameter IKEv2 PSK' as DIME working group item >>>>> Done - Submit Revision of 'Diameter Base Protocol' to the IESG >> for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Attribute-Value Pairs for > Cryptographic >>>>> Key Transport' to the IESG for consideration as a >> Proposed >>>>> Standard >>>>> Done - Submit 'Diameter Priority Attribute Value Pairs' to the >>>>> IESG for consideration as a Proposed Standard >>>>> Done - Submit Revision of 'Diameter Network Access Server >>>>> Application - RFC 4005bis' as DIME working group item >>>>> Done - Submit 'Diameter NAT Control Application' to the IESG >> for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter IKEv2 PSK' to the IESG for >> consideration >>>>> as a Proposed Standard >>>>> Done - Submit 'Diameter Extended NAPTR' to the IESG for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 > Localized >>>>> Routing' to the IESG for consideration as a Proposed >>>>> Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the > IESG >>>>> for consideration as a Proposed Standard >>>>> Mar 2012 - Submit Revision of 'Diameter Network Access Server >>>>> Application - RFC 4005bis' to the IESG for >> consideration as a >>>>> Proposed Standard >>>>> May 2012 - Submit 'Diameter Application Design Guidelines' to the >> IESG >>>>> for consideration as a BCP document Standard >>>>> Jul 2012 - Submit 'Diameter Support for EAP Re-authentication >>>>> Protocol' to the IESG for consideration as a Proposed >>>>> Standard >>>>> Aug 2012 - Submit a document on 'Protocol extension for bulk and >> group >>>>> signaling' as a working group item >>>>> Aug 2013 - Submit a document on 'Protocol extension for bulk and >> group >>>>> signaling' to the IESG for consideration as a Proposed >>>>> Standard >>>>> _______________________________________________ >>>>> IETF-Announce mailing list >>>>> IETF-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>>>> >>>> _______________________________________________ >>>> Ietf mailing list >>>> Ietf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ietf >>> From dromasca@avaya.com Mon Jan 16 06:51:54 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB8E21F861C; Mon, 16 Jan 2012 06:51:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.279 X-Spam-Level: X-Spam-Status: No, score=-103.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 y20ec7J3098P; Mon, 16 Jan 2012 06:51:53 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2F921F861A; Mon, 16 Jan 2012 06:51:53 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8FAP82FE+HCzI1/2dsb2JhbAA5CqEdiw+BC4EFgXIBAQEBAwEBAQ8eCjQLDAQCAQgNBAQBAQEKAgQMCwEGASAGHwkIAQEEARIIARACB4dgmkKbGIhaUDYBBVYIAgcCAgEJAQEBKw4cCTcFAYFtVxYBAQECgkdjBJsEhQiHRw X-IronPort-AV: E=Sophos;i="4.71,518,1320642000"; d="scan'208";a="324692901" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 16 Jan 2012 09:51:51 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 16 Jan 2012 09:38:29 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Jan 2012 15:51:47 +0100 Message-ID: In-Reply-To: <3EF888CD-2843-440B-AF9A-ACE0CEF33180@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Recharter of Diameter Maintenance and Extensions (dime) Thread-Index: AczUXjUzcN3PXAR3TBWDL/SWdNVzqAAACFrw References: <20120111163717.591B021F87EF@ietfa.amsl.com><4F0DC78D.2010809@cs.tcd.ie> <4F0ECE57.3020900@cs.tcd.ie> <3EF888CD-2843-440B-AF9A-ACE0CEF33180@gmail.com> From: "Romascanu, Dan (Dan)" To: "jouni korhonen" , "Stephen Farrell" Cc: Jouni Korhonen , lionel.morand@orange-ftgroup.com, dime@ietf.org, IETF-Discussion , iesg@ietf.org Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions (dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 14:51:54 -0000 This would be fine with me. Dan > -----Original Message----- > From: jouni korhonen [mailto:jouni.nospam@gmail.com] > Sent: Monday, January 16, 2012 4:50 PM > To: Stephen Farrell; Romascanu, Dan (Dan) > Cc: Jouni Korhonen; lionel.morand@orange-ftgroup.com> Morand; > dime@ietf.org; IETF-Discussion; iesg@ietf.org IESG > Subject: Re: WG Review: Recharter of Diameter Maintenance and > Extensions (dime) >=20 > Stephen, Dan, >=20 > What if we just add a milestone to the charter to indicate that > end-to-end security is coming to our table? >=20 > Jul 2012 - Sumbit 'problem statement and requirements for Diameter > end-to-end security framework' as Dime working group item. > Dec 2012 - Submit 'problem statement and requirements for Diameter > end-to-end security framework' to the IESG for > consideration > as an Informational RFC. >=20 > I would give some time folks to work this out.. and then when we > actually > know what we and especially IETF external deployment folks want, we can > move to solution part.. Seems like a relaxed milestone plan but I have > doubts it would progress any faster in real life even if milestones > were > tighter ;) >=20 > - Jouni >=20 > On Jan 12, 2012, at 2:15 PM, Romascanu, Dan (Dan) wrote: >=20 > > Hi, > > > > If a number of hands were raised now and the folks commanding them > say > > 'we are ready to work on this NOW' I would support including explicit > > wording in the charter. If this does not happen until the telechat > next > > week the current text is good enough to allow interested people to > start > > working on contributions that can be individual submissions. If these > > submissions are consistent enough the WG can add the milestone later > in > > the charter and adopt the submissions as WG items. > > > > Dan > > > > > > > > > > > >> -----Original Message----- > >> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf > > Of > >> Stephen Farrell > >> Sent: Thursday, January 12, 2012 2:13 PM > >> To: jouni korhonen > >> Cc: jouni.korhonen@nsn.com; lionel.morand@orange-ftgroup.com; > >> dime@ietf.org; IETF-Discussion; iesg@ietf.org > >> Subject: Re: WG Review: Recharter of Diameter Maintenance and > >> Extensions (dime) > >> > >> > >> Hi Jouni, > >> > >> Right, I'm trying to encourage this - I'm not trying > >> to make it a gating function for the recharter. Its > >> still worth doing though if we can find some victims > >> with enough energy:-) > >> > >> I agree that the current charter text might not need > >> to be modified, OTOH, if there were folks who wanted to > >> do the work, a milestone might be good. I also agree > >> that as of now, that addition is not warranted. > >> > >> Cheers, > >> S > >> > >> On 01/12/2012 12:08 PM, jouni korhonen wrote: > >>> > >>> Stephen, > >>> > >>> This topic raises its head every now and then when a Dime > >>> document arrives at IESG ;) Apart from that there has been > >>> very little serious public discussion about it recently, > >>> for some unknown reason to me. A detail worth pointing out > >>> is that the support for the End-to-End security framework > >>> (E2E-Sequence AVP and 'P'-bit in the AVP header) has been > >>> deprecated in RFC3588bis (now in IESG). So we are "free" > >>> to start from scratch. > >>> > >>> If there is enough serious energy and vision for pursuing > >>> end-to-end security, I do not see current proposed charter > >>> text prohibiting it: > >>> > >>> "- Maintaining and/or progressing, along the standards track, the > >>> Diameter Base protocol and Diameter Applications. This includes > >>> extensions to Diameter Base protocol that can be considered as > >>> enhanced features or bug fixes." > >>> > >>> I would argue the end-to-end security is an enhanced feature for > >>> Diameter base protocol that fixes a serious bug/flaw in security. > >>> On the other hand, if an explicit note is needed about this topic > >>> in the charter, I might hesitate to include such in this round. > >>> I would first like to see some concrete movement& work around > >>> this topic. > >>> > >>> - Jouni > >>> > >>> > >>> > >>> On Jan 11, 2012, at 7:31 PM, Stephen Farrell wrote: > >>> > >>>> > >>>> Hi, > >>>> > >>>> During the IESG internal review of this I asked whether > >>>> or not there was interest in trying to tackle end to > >>>> end security for AVPs. I do know there is at least some > >>>> interest in that but its not clear there's enough to > >>>> warrant including it in the re-charter so I said I'd > >>>> ask when the recharter went out for review... > >>>> > >>>> So - anyone interested in DIME solving that problem? > >>>> (And willing and able to help do the work of course.) > >>>> > >>>> As of now, Diameter really only has hop-by-hop security > >>>> which is ok in many cases but far from ideal (wearing > >>>> my security hat) in some. > >>>> > >>>> Thanks, > >>>> Stephen. > >>>> > >>>> On 01/11/2012 04:37 PM, IESG Secretary wrote: > >>>>> A modified charter has been submitted for the Diameter > Maintenance > >> and > >>>>> Extensions (dime) working group in the Operations and Management > >> Area of > >>>>> the IETF. The IESG has not made any determination as yet. The > >> modified > >>>>> charter is provided below for informational purposes only. > Please > >> send > >>>>> your comments to the IESG mailing list (iesg@ietf.org) by > >> Wednesday, > >>>>> January 18, 2012. > >>>>> > >>>>> Diameter Maintenance and Extensions (dime) > >>>>> ----------------------------------------- > >>>>> Current Status: Active > >>>>> > >>>>> Last Modified: 2012-01-10 > >>>>> > >>>>> Chairs: > >>>>> Lionel Morand > >>>>> Jouni Korhonen > >>>>> > >>>>> Operations and Management Area Directors: > >>>>> Dan Romascanu > >>>>> Ronald Bonica > >>>>> > >>>>> Operations and Management Area Advisor: > >>>>> Dan Romascanu > >>>>> > >>>>> Mailing Lists: > >>>>> General Discussion: dime@ietf.org > >>>>> To Subscribe: > > https://www.ietf.org/mailman/listinfo/dime > >>>>> Archive: > >>>>> http://www.ietf.org/mail-archive/web/dime/current/maillist.html > >>>>> > >>>>> Description of Working Group: > >>>>> > >>>>> The Diameter Maintenance and Extensions WG will focus on > >> maintenance and > >>>>> extensions to the Diameter protocol required to enable its use > for > >>>>> authentication, authorization, accounting, charging in network > >> access, > >>>>> provisioning of configuration information within the network, and > >> for > >>>>> new AAA session management uses within the extensibility rules of > >> the > >>>>> Diameter base protocol. > >>>>> > >>>>> The DIME working group plans to address the following items: > >>>>> > >>>>> - Maintaining and/or progressing, along the standards track, the > >>>>> Diameter Base protocol and Diameter Applications. This includes > >>>>> extensions to Diameter Base protocol that can be considered as > >> enhanced > >>>>> features or bug fixes. > >>>>> > >>>>> - Diameter application design guideline. This document will > > provide > >>>>> guidelines for design of Diameter extensions. It will detail when > >> to > >>>>> consider reusing an existing application and when to develop a > new > >>>>> application. > >>>>> > >>>>> - Protocol extensions for the management of Diameter entities. > > This > >> work > >>>>> focuses on the standardization of Management Information Bases > >> (MIBs) to > >>>>> configure Diameter entities (such as the Diameter Base protocol > or > >>>>> Diameter Credit Control nodes). The usage of other management > >> protocols > >>>>> for configuring Diameter entities may be future work within the > >> group. > >>>>> > >>>>> - Protocol extensions for bulk and grouped AAA session > management. > >> The > >>>>> aim of this work is to study and standardize a solution for > >> handling > >>>>> groups of AAA sessions within the Diameter base protocol context. > >> The > >>>>> solution would define how to identify and handle grouped AAA > >> sessions in > >>>>> commands and operations. > >>>>> > >>>>> Additionally, Diameter-based systems require interoperability in > >> order > >>>>> to work. The working group, along with the AD, will need to > >> evaluate any > >>>>> potential extensions and require verification that the proposed > >>>>> extension is needed, and is within the extensibility rules of > >> Diameter > >>>>> and AAA scope. Coordination with other IETF working groups and > >> other > >>>>> SDOs (e.g. 3GPP) will be used to ensure this. > >>>>> > >>>>> Goals and Milestones: > >>>>> > >>>>> Done - Submit the following two Diameter Mobility documents > to > >> the > >>>>> IESG for consideration as a Proposed Standards:* > >> 'Diameter > >>>>> Mobile IPv6: Support for Home Agent to Diameter Server > >>>>> Interaction' * 'Diameter Mobile IPv6: Support for > >> Network > >>>>> Access Server to Diameter Server Interaction' > >>>>> Done - Submit 'Diameter API' to the IESG for consideration as > >> an > >>>>> Informational RFC > >>>>> Done - Submit 'Quality of Service Parameters for Usage with > >>>>> Diameter' to the IESG for consideration as a Proposed > >>>>> Standard. > >>>>> Done - Submit 'Diameter QoS Application' to the IESG for > >>>>> consideration as a Proposed Standard > >>>>> Done - Submit 'Diameter Support for EAP Re-authentication > >>>>> Protocol' as DIME working group item > >>>>> Done - Submit 'Diameter User-Name and Realm Based Request > >> Routing > >>>>> Clarifications' as DIME working group item > >>>>> Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working > >> group > >>>>> item > >>>>> Done - Submit 'Quality of Service Attributes for Diameter' to > >> the > >>>>> IESG for consideration as a Proposed Standard > >>>>> Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for > >>>>> consideration as a Proposed Standard > >>>>> Done - Submit 'Diameter User-Name and Realm Based Request > >> Routing > >>>>> Clarifications' to the IESG for consideration as a > >> Proposed > >>>>> Standard > >>>>> Done - Submit 'Diameter NAT Control Application' as DIME > >> working > >>>>> group item > >>>>> Done - Submit 'Diameter Capabilities Update' as DIME working > >> group > >>>>> item > >>>>> Done - Submit 'Diameter Credit Control Application MIB' to > the > >>>>> IESG for consideration as an Informational RFC > >>>>> Done - Submit 'Diameter Base Protocol MIB' to the IESG for > >>>>> consideration as an Informational RFC > >>>>> Done - Submit 'Diameter Capabilities Update' to the IESG for > >>>>> consideration as a Proposed Standard > >>>>> Done - Submit 'Diameter Extended NAPTR' as DIME working group > >> item > >>>>> Done - Submit 'Realm-Based Redirection In Diameter' as DIME > >>>>> working group item > >>>>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 > > Localized > >>>>> Routing' as DIME working group item > >>>>> Done - Submit 'Diameter Attribute-Value Pairs for > > Cryptographic > >>>>> Key Transport' as DIME working group item > >>>>> Done - Submit 'Diameter Priority Attribute Value Pairs' as > > DIME > >>>>> working group item > >>>>> Done - Submit 'Diameter IKEv2 PSK' as DIME working group item > >>>>> Done - Submit Revision of 'Diameter Base Protocol' to the > IESG > >> for > >>>>> consideration as a Proposed Standard > >>>>> Done - Submit 'Diameter Attribute-Value Pairs for > > Cryptographic > >>>>> Key Transport' to the IESG for consideration as a > >> Proposed > >>>>> Standard > >>>>> Done - Submit 'Diameter Priority Attribute Value Pairs' to > the > >>>>> IESG for consideration as a Proposed Standard > >>>>> Done - Submit Revision of 'Diameter Network Access Server > >>>>> Application - RFC 4005bis' as DIME working group item > >>>>> Done - Submit 'Diameter NAT Control Application' to the IESG > >> for > >>>>> consideration as a Proposed Standard > >>>>> Done - Submit 'Diameter IKEv2 PSK' to the IESG for > >> consideration > >>>>> as a Proposed Standard > >>>>> Done - Submit 'Diameter Extended NAPTR' to the IESG for > >>>>> consideration as a Proposed Standard > >>>>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 > > Localized > >>>>> Routing' to the IESG for consideration as a Proposed > >>>>> Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the > > IESG > >>>>> for consideration as a Proposed Standard > >>>>> Mar 2012 - Submit Revision of 'Diameter Network Access Server > >>>>> Application - RFC 4005bis' to the IESG for > >> consideration as a > >>>>> Proposed Standard > >>>>> May 2012 - Submit 'Diameter Application Design Guidelines' to the > >> IESG > >>>>> for consideration as a BCP document Standard > >>>>> Jul 2012 - Submit 'Diameter Support for EAP Re-authentication > >>>>> Protocol' to the IESG for consideration as a Proposed > >>>>> Standard > >>>>> Aug 2012 - Submit a document on 'Protocol extension for bulk and > >> group > >>>>> signaling' as a working group item > >>>>> Aug 2013 - Submit a document on 'Protocol extension for bulk and > >> group > >>>>> signaling' to the IESG for consideration as a Proposed > >>>>> Standard > >>>>> _______________________________________________ > >>>>> IETF-Announce mailing list > >>>>> IETF-Announce@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/ietf-announce > >>>>> > >>>> _______________________________________________ > >>>> Ietf mailing list > >>>> Ietf@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ietf > >>> From jouni.nospam@gmail.com Mon Jan 16 07:02:05 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E835E21F8606; Mon, 16 Jan 2012 07:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.626 X-Spam-Level: X-Spam-Status: No, score=-3.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 KNlj7Aqwezih; Mon, 16 Jan 2012 07:02:04 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id CCD0921F8605; Mon, 16 Jan 2012 07:02:03 -0800 (PST) Received: by lagv3 with SMTP id v3so1911210lag.31 for ; Mon, 16 Jan 2012 07:02:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=EYs5m9dX9u+ndiQ9AvOaXl4QU3tcxDDkUBsaQdSehTU=; b=b9wLplBvTpUzbp5o1PlaNEHeLqGEIhEQ3E4UxciU3l2O6dbQUMprXWppmQ71nCDQ2n 342djy+dWFAlN/osbzq0mBcYucgAoAsu0Io+5fIU4riLDRPNr6n6WGbKbJt+XWNyis+p Ddpv2o5E1O3Qep4r2MPqMzCQgmNVii2HVf50Q= Received: by 10.112.101.198 with SMTP id fi6mr3144565lbb.18.1326726122814; Mon, 16 Jan 2012 07:02:02 -0800 (PST) Received: from a88-112-207-191.elisa-laajakaista.fi (a88-112-207-191.elisa-laajakaista.fi. [88.112.207.191]) by mx.google.com with ESMTPS id o10sm17635645lbt.12.2012.01.16.07.02.00 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 Jan 2012 07:02:01 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4F1439D5.6010502@cs.tcd.ie> Date: Mon, 16 Jan 2012 17:01:59 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <20120111163717.591B021F87EF@ietfa.amsl.com><4F0DC78D.2010809@cs.tcd.ie> <4F0ECE57.3020900@cs.tcd.ie> <3EF888CD-2843-440B-AF9A-ACE0CEF33180@gmail.com> <4F1439D5.6010502@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1084) Cc: IETF-Discussion , Jouni Korhonen , lionel.morand@orange-ftgroup.com, dime@ietf.org, iesg@ietf.org Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions (dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 15:02:06 -0000 So be it.. from my behalf. - Jouni On Jan 16, 2012, at 4:53 PM, Stephen Farrell wrote: > > And I'd be ecstatic (when it happens:-) > > Thanks, > S > > On 01/16/2012 02:51 PM, Romascanu, Dan (Dan) wrote: >> This would be fine with me. >> >> Dan >> >> >> >> >>> -----Original Message----- >>> From: jouni korhonen [mailto:jouni.nospam@gmail.com] >>> Sent: Monday, January 16, 2012 4:50 PM >>> To: Stephen Farrell; Romascanu, Dan (Dan) >>> Cc: Jouni Korhonen; lionel.morand@orange-ftgroup.com> Morand; >>> dime@ietf.org; IETF-Discussion; iesg@ietf.org IESG >>> Subject: Re: WG Review: Recharter of Diameter Maintenance and >>> Extensions (dime) >>> >>> Stephen, Dan, >>> >>> What if we just add a milestone to the charter to indicate that >>> end-to-end security is coming to our table? >>> >>> Jul 2012 - Sumbit 'problem statement and requirements for Diameter >>> end-to-end security framework' as Dime working group >> item. >>> Dec 2012 - Submit 'problem statement and requirements for Diameter >>> end-to-end security framework' to the IESG for >>> consideration >>> as an Informational RFC. >>> >>> I would give some time folks to work this out.. and then when we >>> actually >>> know what we and especially IETF external deployment folks want, we >> can >>> move to solution part.. Seems like a relaxed milestone plan but I >> have >>> doubts it would progress any faster in real life even if milestones >>> were >>> tighter ;) >>> >>> - Jouni >>> >>> On Jan 12, 2012, at 2:15 PM, Romascanu, Dan (Dan) wrote: >>> >>>> Hi, >>>> >>>> If a number of hands were raised now and the folks commanding them >>> say >>>> 'we are ready to work on this NOW' I would support including >> explicit >>>> wording in the charter. If this does not happen until the telechat >>> next >>>> week the current text is good enough to allow interested people to >>> start >>>> working on contributions that can be individual submissions. If >> these >>>> submissions are consistent enough the WG can add the milestone later >>> in >>>> the charter and adopt the submissions as WG items. >>>> >>>> Dan >>>> >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On >> Behalf >>>> Of >>>>> Stephen Farrell >>>>> Sent: Thursday, January 12, 2012 2:13 PM >>>>> To: jouni korhonen >>>>> Cc: jouni.korhonen@nsn.com; lionel.morand@orange-ftgroup.com; >>>>> dime@ietf.org; IETF-Discussion; iesg@ietf.org >>>>> Subject: Re: WG Review: Recharter of Diameter Maintenance and >>>>> Extensions (dime) >>>>> >>>>> >>>>> Hi Jouni, >>>>> >>>>> Right, I'm trying to encourage this - I'm not trying >>>>> to make it a gating function for the recharter. Its >>>>> still worth doing though if we can find some victims >>>>> with enough energy:-) >>>>> >>>>> I agree that the current charter text might not need >>>>> to be modified, OTOH, if there were folks who wanted to >>>>> do the work, a milestone might be good. I also agree >>>>> that as of now, that addition is not warranted. >>>>> >>>>> Cheers, >>>>> S >>>>> >>>>> On 01/12/2012 12:08 PM, jouni korhonen wrote: >>>>>> >>>>>> Stephen, >>>>>> >>>>>> This topic raises its head every now and then when a Dime >>>>>> document arrives at IESG ;) Apart from that there has been >>>>>> very little serious public discussion about it recently, >>>>>> for some unknown reason to me. A detail worth pointing out >>>>>> is that the support for the End-to-End security framework >>>>>> (E2E-Sequence AVP and 'P'-bit in the AVP header) has been >>>>>> deprecated in RFC3588bis (now in IESG). So we are "free" >>>>>> to start from scratch. >>>>>> >>>>>> If there is enough serious energy and vision for pursuing >>>>>> end-to-end security, I do not see current proposed charter >>>>>> text prohibiting it: >>>>>> >>>>>> "- Maintaining and/or progressing, along the standards track, the >>>>>> Diameter Base protocol and Diameter Applications. This includes >>>>>> extensions to Diameter Base protocol that can be considered as >>>>>> enhanced features or bug fixes." >>>>>> >>>>>> I would argue the end-to-end security is an enhanced feature for >>>>>> Diameter base protocol that fixes a serious bug/flaw in security. >>>>>> On the other hand, if an explicit note is needed about this topic >>>>>> in the charter, I might hesitate to include such in this round. >>>>>> I would first like to see some concrete movement& work around >>>>>> this topic. >>>>>> >>>>>> - Jouni >>>>>> >>>>>> >>>>>> >>>>>> On Jan 11, 2012, at 7:31 PM, Stephen Farrell wrote: >>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> During the IESG internal review of this I asked whether >>>>>>> or not there was interest in trying to tackle end to >>>>>>> end security for AVPs. I do know there is at least some >>>>>>> interest in that but its not clear there's enough to >>>>>>> warrant including it in the re-charter so I said I'd >>>>>>> ask when the recharter went out for review... >>>>>>> >>>>>>> So - anyone interested in DIME solving that problem? >>>>>>> (And willing and able to help do the work of course.) >>>>>>> >>>>>>> As of now, Diameter really only has hop-by-hop security >>>>>>> which is ok in many cases but far from ideal (wearing >>>>>>> my security hat) in some. >>>>>>> >>>>>>> Thanks, >>>>>>> Stephen. >>>>>>> >>>>>>> On 01/11/2012 04:37 PM, IESG Secretary wrote: >>>>>>>> A modified charter has been submitted for the Diameter >>> Maintenance >>>>> and >>>>>>>> Extensions (dime) working group in the Operations and Management >>>>> Area of >>>>>>>> the IETF. The IESG has not made any determination as yet. The >>>>> modified >>>>>>>> charter is provided below for informational purposes only. >>> Please >>>>> send >>>>>>>> your comments to the IESG mailing list (iesg@ietf.org) by >>>>> Wednesday, >>>>>>>> January 18, 2012. >>>>>>>> >>>>>>>> Diameter Maintenance and Extensions (dime) >>>>>>>> ----------------------------------------- >>>>>>>> Current Status: Active >>>>>>>> >>>>>>>> Last Modified: 2012-01-10 >>>>>>>> >>>>>>>> Chairs: >>>>>>>> Lionel Morand >>>>>>>> Jouni Korhonen >>>>>>>> >>>>>>>> Operations and Management Area Directors: >>>>>>>> Dan Romascanu >>>>>>>> Ronald Bonica >>>>>>>> >>>>>>>> Operations and Management Area Advisor: >>>>>>>> Dan Romascanu >>>>>>>> >>>>>>>> Mailing Lists: >>>>>>>> General Discussion: dime@ietf.org >>>>>>>> To Subscribe: >>>> https://www.ietf.org/mailman/listinfo/dime >>>>>>>> Archive: >>>>>>>> http://www.ietf.org/mail-archive/web/dime/current/maillist.html >>>>>>>> >>>>>>>> Description of Working Group: >>>>>>>> >>>>>>>> The Diameter Maintenance and Extensions WG will focus on >>>>> maintenance and >>>>>>>> extensions to the Diameter protocol required to enable its use >>> for >>>>>>>> authentication, authorization, accounting, charging in network >>>>> access, >>>>>>>> provisioning of configuration information within the network, >> and >>>>> for >>>>>>>> new AAA session management uses within the extensibility rules >> of >>>>> the >>>>>>>> Diameter base protocol. >>>>>>>> >>>>>>>> The DIME working group plans to address the following items: >>>>>>>> >>>>>>>> - Maintaining and/or progressing, along the standards track, the >>>>>>>> Diameter Base protocol and Diameter Applications. This includes >>>>>>>> extensions to Diameter Base protocol that can be considered as >>>>> enhanced >>>>>>>> features or bug fixes. >>>>>>>> >>>>>>>> - Diameter application design guideline. This document will >>>> provide >>>>>>>> guidelines for design of Diameter extensions. It will detail >> when >>>>> to >>>>>>>> consider reusing an existing application and when to develop a >>> new >>>>>>>> application. >>>>>>>> >>>>>>>> - Protocol extensions for the management of Diameter entities. >>>> This >>>>> work >>>>>>>> focuses on the standardization of Management Information Bases >>>>> (MIBs) to >>>>>>>> configure Diameter entities (such as the Diameter Base protocol >>> or >>>>>>>> Diameter Credit Control nodes). The usage of other management >>>>> protocols >>>>>>>> for configuring Diameter entities may be future work within the >>>>> group. >>>>>>>> >>>>>>>> - Protocol extensions for bulk and grouped AAA session >>> management. >>>>> The >>>>>>>> aim of this work is to study and standardize a solution for >>>>> handling >>>>>>>> groups of AAA sessions within the Diameter base protocol >> context. >>>>> The >>>>>>>> solution would define how to identify and handle grouped AAA >>>>> sessions in >>>>>>>> commands and operations. >>>>>>>> >>>>>>>> Additionally, Diameter-based systems require interoperability in >>>>> order >>>>>>>> to work. The working group, along with the AD, will need to >>>>> evaluate any >>>>>>>> potential extensions and require verification that the proposed >>>>>>>> extension is needed, and is within the extensibility rules of >>>>> Diameter >>>>>>>> and AAA scope. Coordination with other IETF working groups and >>>>> other >>>>>>>> SDOs (e.g. 3GPP) will be used to ensure this. >>>>>>>> >>>>>>>> Goals and Milestones: >>>>>>>> >>>>>>>> Done - Submit the following two Diameter Mobility documents >>> to >>>>> the >>>>>>>> IESG for consideration as a Proposed Standards:* >>>>> 'Diameter >>>>>>>> Mobile IPv6: Support for Home Agent to Diameter >> Server >>>>>>>> Interaction' * 'Diameter Mobile IPv6: Support for >>>>> Network >>>>>>>> Access Server to Diameter Server Interaction' >>>>>>>> Done - Submit 'Diameter API' to the IESG for consideration >> as >>>>> an >>>>>>>> Informational RFC >>>>>>>> Done - Submit 'Quality of Service Parameters for Usage with >>>>>>>> Diameter' to the IESG for consideration as a Proposed >>>>>>>> Standard. >>>>>>>> Done - Submit 'Diameter QoS Application' to the IESG for >>>>>>>> consideration as a Proposed Standard >>>>>>>> Done - Submit 'Diameter Support for EAP Re-authentication >>>>>>>> Protocol' as DIME working group item >>>>>>>> Done - Submit 'Diameter User-Name and Realm Based Request >>>>> Routing >>>>>>>> Clarifications' as DIME working group item >>>>>>>> Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working >>>>> group >>>>>>>> item >>>>>>>> Done - Submit 'Quality of Service Attributes for Diameter' >> to >>>>> the >>>>>>>> IESG for consideration as a Proposed Standard >>>>>>>> Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for >>>>>>>> consideration as a Proposed Standard >>>>>>>> Done - Submit 'Diameter User-Name and Realm Based Request >>>>> Routing >>>>>>>> Clarifications' to the IESG for consideration as a >>>>> Proposed >>>>>>>> Standard >>>>>>>> Done - Submit 'Diameter NAT Control Application' as DIME >>>>> working >>>>>>>> group item >>>>>>>> Done - Submit 'Diameter Capabilities Update' as DIME working >>>>> group >>>>>>>> item >>>>>>>> Done - Submit 'Diameter Credit Control Application MIB' to >>> the >>>>>>>> IESG for consideration as an Informational RFC >>>>>>>> Done - Submit 'Diameter Base Protocol MIB' to the IESG for >>>>>>>> consideration as an Informational RFC >>>>>>>> Done - Submit 'Diameter Capabilities Update' to the IESG for >>>>>>>> consideration as a Proposed Standard >>>>>>>> Done - Submit 'Diameter Extended NAPTR' as DIME working >> group >>>>> item >>>>>>>> Done - Submit 'Realm-Based Redirection In Diameter' as DIME >>>>>>>> working group item >>>>>>>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 >>>> Localized >>>>>>>> Routing' as DIME working group item >>>>>>>> Done - Submit 'Diameter Attribute-Value Pairs for >>>> Cryptographic >>>>>>>> Key Transport' as DIME working group item >>>>>>>> Done - Submit 'Diameter Priority Attribute Value Pairs' as >>>> DIME >>>>>>>> working group item >>>>>>>> Done - Submit 'Diameter IKEv2 PSK' as DIME working group >> item >>>>>>>> Done - Submit Revision of 'Diameter Base Protocol' to the >>> IESG >>>>> for >>>>>>>> consideration as a Proposed Standard >>>>>>>> Done - Submit 'Diameter Attribute-Value Pairs for >>>> Cryptographic >>>>>>>> Key Transport' to the IESG for consideration as a >>>>> Proposed >>>>>>>> Standard >>>>>>>> Done - Submit 'Diameter Priority Attribute Value Pairs' to >>> the >>>>>>>> IESG for consideration as a Proposed Standard >>>>>>>> Done - Submit Revision of 'Diameter Network Access Server >>>>>>>> Application - RFC 4005bis' as DIME working group item >>>>>>>> Done - Submit 'Diameter NAT Control Application' to the IESG >>>>> for >>>>>>>> consideration as a Proposed Standard >>>>>>>> Done - Submit 'Diameter IKEv2 PSK' to the IESG for >>>>> consideration >>>>>>>> as a Proposed Standard >>>>>>>> Done - Submit 'Diameter Extended NAPTR' to the IESG for >>>>>>>> consideration as a Proposed Standard >>>>>>>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 >>>> Localized >>>>>>>> Routing' to the IESG for consideration as a Proposed >>>>>>>> Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the >>>> IESG >>>>>>>> for consideration as a Proposed Standard >>>>>>>> Mar 2012 - Submit Revision of 'Diameter Network Access Server >>>>>>>> Application - RFC 4005bis' to the IESG for >>>>> consideration as a >>>>>>>> Proposed Standard >>>>>>>> May 2012 - Submit 'Diameter Application Design Guidelines' to >> the >>>>> IESG >>>>>>>> for consideration as a BCP document Standard >>>>>>>> Jul 2012 - Submit 'Diameter Support for EAP Re-authentication >>>>>>>> Protocol' to the IESG for consideration as a Proposed >>>>>>>> Standard >>>>>>>> Aug 2012 - Submit a document on 'Protocol extension for bulk and >>>>> group >>>>>>>> signaling' as a working group item >>>>>>>> Aug 2013 - Submit a document on 'Protocol extension for bulk and >>>>> group >>>>>>>> signaling' to the IESG for consideration as a >> Proposed >>>>>>>> Standard >>>>>>>> _______________________________________________ >>>>>>>> IETF-Announce mailing list >>>>>>>> IETF-Announce@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ietf mailing list >>>>>>> Ietf@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ietf >>>>>> >> From stephen.farrell@cs.tcd.ie Mon Jan 16 06:53:22 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37C121F862A; Mon, 16 Jan 2012 06:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 te5zC8GPI+Cv; Mon, 16 Jan 2012 06:53:20 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 56A4D21F8617; Mon, 16 Jan 2012 06:53:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 9C373171C27; Mon, 16 Jan 2012 14:53:11 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1326725590; bh=iJDKde82yHkZnw wMR8Yb/Gx598Xeriekx1jlmKfNkTI=; b=cCyZ7IuBmK5geiAUh+8tUYEzhiy6e6 H7xA1p8yKDc/y7JH73VY7QlgjtnDPId/FjzeH9ggmbUA0lwJvv+opn1VBFRgBfs7 JEU38NkYIV7pugkNNbD1zv8TboxSFts4dTr4Acww1ukNjroXUGN93jiDF/5VBkx3 dPQnvPGirZR9tpNVLACwcZCMBlblxmbYpkxJ2zVGpXK+dQ/qw9NJWiMI03Ycv/7K 7P1noaHKuNPf6Zu0Z1kEd7kkq5XxDBNeLqxgd6Vplkr4oYS65Hd/Ljd4O3sR1lHu S11AKPw9pTjfvTMD6hLbNf1lChkgOK8yTXEUrJ+VRisr+Tu0S4gN9pbg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id kxi5PIWXDm-x; Mon, 16 Jan 2012 14:53:10 +0000 (GMT) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id F09E1171C29; Mon, 16 Jan 2012 14:53:09 +0000 (GMT) Message-ID: <4F1439D5.6010502@cs.tcd.ie> Date: Mon, 16 Jan 2012 14:53:09 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <20120111163717.591B021F87EF@ietfa.amsl.com><4F0DC78D.2010809@cs.tcd.ie> <4F0ECE57.3020900@cs.tcd.ie> <3EF888CD-2843-440B-AF9A-ACE0CEF33180@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 16 Jan 2012 07:15:27 -0800 Cc: IETF-Discussion , Jouni Korhonen , lionel.morand@orange-ftgroup.com, dime@ietf.org, iesg@ietf.org Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions (dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 14:53:22 -0000 And I'd be ecstatic (when it happens:-) Thanks, S On 01/16/2012 02:51 PM, Romascanu, Dan (Dan) wrote: > This would be fine with me. > > Dan > > > > >> -----Original Message----- >> From: jouni korhonen [mailto:jouni.nospam@gmail.com] >> Sent: Monday, January 16, 2012 4:50 PM >> To: Stephen Farrell; Romascanu, Dan (Dan) >> Cc: Jouni Korhonen; lionel.morand@orange-ftgroup.com> Morand; >> dime@ietf.org; IETF-Discussion; iesg@ietf.org IESG >> Subject: Re: WG Review: Recharter of Diameter Maintenance and >> Extensions (dime) >> >> Stephen, Dan, >> >> What if we just add a milestone to the charter to indicate that >> end-to-end security is coming to our table? >> >> Jul 2012 - Sumbit 'problem statement and requirements for Diameter >> end-to-end security framework' as Dime working group > item. >> Dec 2012 - Submit 'problem statement and requirements for Diameter >> end-to-end security framework' to the IESG for >> consideration >> as an Informational RFC. >> >> I would give some time folks to work this out.. and then when we >> actually >> know what we and especially IETF external deployment folks want, we > can >> move to solution part.. Seems like a relaxed milestone plan but I > have >> doubts it would progress any faster in real life even if milestones >> were >> tighter ;) >> >> - Jouni >> >> On Jan 12, 2012, at 2:15 PM, Romascanu, Dan (Dan) wrote: >> >>> Hi, >>> >>> If a number of hands were raised now and the folks commanding them >> say >>> 'we are ready to work on this NOW' I would support including > explicit >>> wording in the charter. If this does not happen until the telechat >> next >>> week the current text is good enough to allow interested people to >> start >>> working on contributions that can be individual submissions. If > these >>> submissions are consistent enough the WG can add the milestone later >> in >>> the charter and adopt the submissions as WG items. >>> >>> Dan >>> >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On > Behalf >>> Of >>>> Stephen Farrell >>>> Sent: Thursday, January 12, 2012 2:13 PM >>>> To: jouni korhonen >>>> Cc: jouni.korhonen@nsn.com; lionel.morand@orange-ftgroup.com; >>>> dime@ietf.org; IETF-Discussion; iesg@ietf.org >>>> Subject: Re: WG Review: Recharter of Diameter Maintenance and >>>> Extensions (dime) >>>> >>>> >>>> Hi Jouni, >>>> >>>> Right, I'm trying to encourage this - I'm not trying >>>> to make it a gating function for the recharter. Its >>>> still worth doing though if we can find some victims >>>> with enough energy:-) >>>> >>>> I agree that the current charter text might not need >>>> to be modified, OTOH, if there were folks who wanted to >>>> do the work, a milestone might be good. I also agree >>>> that as of now, that addition is not warranted. >>>> >>>> Cheers, >>>> S >>>> >>>> On 01/12/2012 12:08 PM, jouni korhonen wrote: >>>>> >>>>> Stephen, >>>>> >>>>> This topic raises its head every now and then when a Dime >>>>> document arrives at IESG ;) Apart from that there has been >>>>> very little serious public discussion about it recently, >>>>> for some unknown reason to me. A detail worth pointing out >>>>> is that the support for the End-to-End security framework >>>>> (E2E-Sequence AVP and 'P'-bit in the AVP header) has been >>>>> deprecated in RFC3588bis (now in IESG). So we are "free" >>>>> to start from scratch. >>>>> >>>>> If there is enough serious energy and vision for pursuing >>>>> end-to-end security, I do not see current proposed charter >>>>> text prohibiting it: >>>>> >>>>> "- Maintaining and/or progressing, along the standards track, the >>>>> Diameter Base protocol and Diameter Applications. This includes >>>>> extensions to Diameter Base protocol that can be considered as >>>>> enhanced features or bug fixes." >>>>> >>>>> I would argue the end-to-end security is an enhanced feature for >>>>> Diameter base protocol that fixes a serious bug/flaw in security. >>>>> On the other hand, if an explicit note is needed about this topic >>>>> in the charter, I might hesitate to include such in this round. >>>>> I would first like to see some concrete movement& work around >>>>> this topic. >>>>> >>>>> - Jouni >>>>> >>>>> >>>>> >>>>> On Jan 11, 2012, at 7:31 PM, Stephen Farrell wrote: >>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> During the IESG internal review of this I asked whether >>>>>> or not there was interest in trying to tackle end to >>>>>> end security for AVPs. I do know there is at least some >>>>>> interest in that but its not clear there's enough to >>>>>> warrant including it in the re-charter so I said I'd >>>>>> ask when the recharter went out for review... >>>>>> >>>>>> So - anyone interested in DIME solving that problem? >>>>>> (And willing and able to help do the work of course.) >>>>>> >>>>>> As of now, Diameter really only has hop-by-hop security >>>>>> which is ok in many cases but far from ideal (wearing >>>>>> my security hat) in some. >>>>>> >>>>>> Thanks, >>>>>> Stephen. >>>>>> >>>>>> On 01/11/2012 04:37 PM, IESG Secretary wrote: >>>>>>> A modified charter has been submitted for the Diameter >> Maintenance >>>> and >>>>>>> Extensions (dime) working group in the Operations and Management >>>> Area of >>>>>>> the IETF. The IESG has not made any determination as yet. The >>>> modified >>>>>>> charter is provided below for informational purposes only. >> Please >>>> send >>>>>>> your comments to the IESG mailing list (iesg@ietf.org) by >>>> Wednesday, >>>>>>> January 18, 2012. >>>>>>> >>>>>>> Diameter Maintenance and Extensions (dime) >>>>>>> ----------------------------------------- >>>>>>> Current Status: Active >>>>>>> >>>>>>> Last Modified: 2012-01-10 >>>>>>> >>>>>>> Chairs: >>>>>>> Lionel Morand >>>>>>> Jouni Korhonen >>>>>>> >>>>>>> Operations and Management Area Directors: >>>>>>> Dan Romascanu >>>>>>> Ronald Bonica >>>>>>> >>>>>>> Operations and Management Area Advisor: >>>>>>> Dan Romascanu >>>>>>> >>>>>>> Mailing Lists: >>>>>>> General Discussion: dime@ietf.org >>>>>>> To Subscribe: >>> https://www.ietf.org/mailman/listinfo/dime >>>>>>> Archive: >>>>>>> http://www.ietf.org/mail-archive/web/dime/current/maillist.html >>>>>>> >>>>>>> Description of Working Group: >>>>>>> >>>>>>> The Diameter Maintenance and Extensions WG will focus on >>>> maintenance and >>>>>>> extensions to the Diameter protocol required to enable its use >> for >>>>>>> authentication, authorization, accounting, charging in network >>>> access, >>>>>>> provisioning of configuration information within the network, > and >>>> for >>>>>>> new AAA session management uses within the extensibility rules > of >>>> the >>>>>>> Diameter base protocol. >>>>>>> >>>>>>> The DIME working group plans to address the following items: >>>>>>> >>>>>>> - Maintaining and/or progressing, along the standards track, the >>>>>>> Diameter Base protocol and Diameter Applications. This includes >>>>>>> extensions to Diameter Base protocol that can be considered as >>>> enhanced >>>>>>> features or bug fixes. >>>>>>> >>>>>>> - Diameter application design guideline. This document will >>> provide >>>>>>> guidelines for design of Diameter extensions. It will detail > when >>>> to >>>>>>> consider reusing an existing application and when to develop a >> new >>>>>>> application. >>>>>>> >>>>>>> - Protocol extensions for the management of Diameter entities. >>> This >>>> work >>>>>>> focuses on the standardization of Management Information Bases >>>> (MIBs) to >>>>>>> configure Diameter entities (such as the Diameter Base protocol >> or >>>>>>> Diameter Credit Control nodes). The usage of other management >>>> protocols >>>>>>> for configuring Diameter entities may be future work within the >>>> group. >>>>>>> >>>>>>> - Protocol extensions for bulk and grouped AAA session >> management. >>>> The >>>>>>> aim of this work is to study and standardize a solution for >>>> handling >>>>>>> groups of AAA sessions within the Diameter base protocol > context. >>>> The >>>>>>> solution would define how to identify and handle grouped AAA >>>> sessions in >>>>>>> commands and operations. >>>>>>> >>>>>>> Additionally, Diameter-based systems require interoperability in >>>> order >>>>>>> to work. The working group, along with the AD, will need to >>>> evaluate any >>>>>>> potential extensions and require verification that the proposed >>>>>>> extension is needed, and is within the extensibility rules of >>>> Diameter >>>>>>> and AAA scope. Coordination with other IETF working groups and >>>> other >>>>>>> SDOs (e.g. 3GPP) will be used to ensure this. >>>>>>> >>>>>>> Goals and Milestones: >>>>>>> >>>>>>> Done - Submit the following two Diameter Mobility documents >> to >>>> the >>>>>>> IESG for consideration as a Proposed Standards:* >>>> 'Diameter >>>>>>> Mobile IPv6: Support for Home Agent to Diameter > Server >>>>>>> Interaction' * 'Diameter Mobile IPv6: Support for >>>> Network >>>>>>> Access Server to Diameter Server Interaction' >>>>>>> Done - Submit 'Diameter API' to the IESG for consideration > as >>>> an >>>>>>> Informational RFC >>>>>>> Done - Submit 'Quality of Service Parameters for Usage with >>>>>>> Diameter' to the IESG for consideration as a Proposed >>>>>>> Standard. >>>>>>> Done - Submit 'Diameter QoS Application' to the IESG for >>>>>>> consideration as a Proposed Standard >>>>>>> Done - Submit 'Diameter Support for EAP Re-authentication >>>>>>> Protocol' as DIME working group item >>>>>>> Done - Submit 'Diameter User-Name and Realm Based Request >>>> Routing >>>>>>> Clarifications' as DIME working group item >>>>>>> Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working >>>> group >>>>>>> item >>>>>>> Done - Submit 'Quality of Service Attributes for Diameter' > to >>>> the >>>>>>> IESG for consideration as a Proposed Standard >>>>>>> Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for >>>>>>> consideration as a Proposed Standard >>>>>>> Done - Submit 'Diameter User-Name and Realm Based Request >>>> Routing >>>>>>> Clarifications' to the IESG for consideration as a >>>> Proposed >>>>>>> Standard >>>>>>> Done - Submit 'Diameter NAT Control Application' as DIME >>>> working >>>>>>> group item >>>>>>> Done - Submit 'Diameter Capabilities Update' as DIME working >>>> group >>>>>>> item >>>>>>> Done - Submit 'Diameter Credit Control Application MIB' to >> the >>>>>>> IESG for consideration as an Informational RFC >>>>>>> Done - Submit 'Diameter Base Protocol MIB' to the IESG for >>>>>>> consideration as an Informational RFC >>>>>>> Done - Submit 'Diameter Capabilities Update' to the IESG for >>>>>>> consideration as a Proposed Standard >>>>>>> Done - Submit 'Diameter Extended NAPTR' as DIME working > group >>>> item >>>>>>> Done - Submit 'Realm-Based Redirection In Diameter' as DIME >>>>>>> working group item >>>>>>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 >>> Localized >>>>>>> Routing' as DIME working group item >>>>>>> Done - Submit 'Diameter Attribute-Value Pairs for >>> Cryptographic >>>>>>> Key Transport' as DIME working group item >>>>>>> Done - Submit 'Diameter Priority Attribute Value Pairs' as >>> DIME >>>>>>> working group item >>>>>>> Done - Submit 'Diameter IKEv2 PSK' as DIME working group > item >>>>>>> Done - Submit Revision of 'Diameter Base Protocol' to the >> IESG >>>> for >>>>>>> consideration as a Proposed Standard >>>>>>> Done - Submit 'Diameter Attribute-Value Pairs for >>> Cryptographic >>>>>>> Key Transport' to the IESG for consideration as a >>>> Proposed >>>>>>> Standard >>>>>>> Done - Submit 'Diameter Priority Attribute Value Pairs' to >> the >>>>>>> IESG for consideration as a Proposed Standard >>>>>>> Done - Submit Revision of 'Diameter Network Access Server >>>>>>> Application - RFC 4005bis' as DIME working group item >>>>>>> Done - Submit 'Diameter NAT Control Application' to the IESG >>>> for >>>>>>> consideration as a Proposed Standard >>>>>>> Done - Submit 'Diameter IKEv2 PSK' to the IESG for >>>> consideration >>>>>>> as a Proposed Standard >>>>>>> Done - Submit 'Diameter Extended NAPTR' to the IESG for >>>>>>> consideration as a Proposed Standard >>>>>>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 >>> Localized >>>>>>> Routing' to the IESG for consideration as a Proposed >>>>>>> Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the >>> IESG >>>>>>> for consideration as a Proposed Standard >>>>>>> Mar 2012 - Submit Revision of 'Diameter Network Access Server >>>>>>> Application - RFC 4005bis' to the IESG for >>>> consideration as a >>>>>>> Proposed Standard >>>>>>> May 2012 - Submit 'Diameter Application Design Guidelines' to > the >>>> IESG >>>>>>> for consideration as a BCP document Standard >>>>>>> Jul 2012 - Submit 'Diameter Support for EAP Re-authentication >>>>>>> Protocol' to the IESG for consideration as a Proposed >>>>>>> Standard >>>>>>> Aug 2012 - Submit a document on 'Protocol extension for bulk and >>>> group >>>>>>> signaling' as a working group item >>>>>>> Aug 2013 - Submit a document on 'Protocol extension for bulk and >>>> group >>>>>>> signaling' to the IESG for consideration as a > Proposed >>>>>>> Standard >>>>>>> _______________________________________________ >>>>>>> IETF-Announce mailing list >>>>>>> IETF-Announce@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>>>>>> >>>>>> _______________________________________________ >>>>>> Ietf mailing list >>>>>> Ietf@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ietf >>>>> > From dromasca@avaya.com Thu Jan 19 10:46:01 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB3021F869C for ; Thu, 19 Jan 2012 10:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.829 X-Spam-Level: X-Spam-Status: No, score=-102.829 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 yq6Dvtg5a028 for ; Thu, 19 Jan 2012 10:46:01 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED7721F85EA for ; Thu, 19 Jan 2012 10:46:00 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAN9iGE/GmAcF/2dsb2JhbABErF6BAIEFgXQBAQMSHgpRARUVBgwMB1AHAQQbGqEPhBibWok3NgEFVggCBwEBAQEBAQIBAgECAQEBAQIoDhwJNwUBgW0oBAICCwEJO4I5YwSbDoxU X-IronPort-AV: E=Sophos;i="4.71,537,1320642000"; d="scan'208";a="227634403" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 19 Jan 2012 13:46:00 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 19 Jan 2012 13:41:10 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: Areg A8vb BJ+f Dju+ EA7k EJaF Frj8 HfNT IMyt IyZu JEYf JO8e JkiU J8Ug KQ7G KnxA; 1; ZABpAG0AZQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {D893387B-879A-46D8-B4F5-D8D46A7C087A}; ZAByAG8AbQBhAHMAYwBhAEAAYQB2AGEAeQBhAC4AYwBvAG0A; Thu, 19 Jan 2012 18:45:55 GMT; ZABpAG0AZQAgAHIAZQBjAGgAYQByAHQAZQByAGkAbgBnACAAYQBwAHAAcgBvAHYAZQBkAA== MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {D893387B-879A-46D8-B4F5-D8D46A7C087A} Content-class: urn:content-classes:message Date: Thu, 19 Jan 2012 19:45:55 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: dime rechartering approved Thread-Index: AczW2pPJRy5JDCPJTwWjvfM7oR/8Xw== From: "Romascanu, Dan (Dan)" To: Subject: [Dime] dime rechartering approved X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 18:46:01 -0000 The IESG approved today the rechartering of DIME with the proposed charter, including the latest milestones proposed by Jouni for e2e security. Congratulations and good luck.=20 Regards, Dan From wwwrun@ietfa.amsl.com Tue Jan 24 09:18:08 2012 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 9C0F211E8076; Tue, 24 Jan 2012 09:18:08 -0800 (PST) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20120124171808.9C0F211E8076@ietfa.amsl.com> Date: Tue, 24 Jan 2012 09:18:08 -0800 (PST) Cc: jouni.korhonen@nsn.com, lionel.morand@orange-ftgroup.com, dime@ietf.org Subject: [Dime] WG Action: RECHARTER: Diameter Maintenance and Extensions (dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 17:18:08 -0000 The Diameter Maintenance and Extensions (dime) working group in the Operations and Management Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. Diameter Maintenance and Extensions (dime) ----------------------------------------- Current Status: Active Last Modified: 2012-01-19 Chairs: Lionel Morand Jouni Korhonen Operations and Management Area Directors: Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion: dime@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dime Archive: http://www.ietf.org/mail-archive/web/dime/current/maillist.html Description of Working Group: The Diameter Maintenance and Extensions WG will focus on maintenance and extensions to the Diameter protocol required to enable its use for authentication, authorization, accounting, charging in network access, provisioning of configuration information within the network, and for new AAA session management uses within the extensibility rules of the Diameter base protocol. The DIME working group plans to address the following items: - Maintaining and/or progressing, along the standards track, the Diameter Base protocol and Diameter Applications. This includes extensions to Diameter Base protocol that can be considered as enhanced features or bug fixes. - Diameter application design guideline. This document will provide guidelines for design of Diameter extensions. It will detail when to consider reusing an existing application and when to develop a new application. - Protocol extensions for the management of Diameter entities. This work focuses on the standardization of Management Information Bases (MIBs) to configure Diameter entities (such as the Diameter Base protocol or Diameter Credit Control nodes). The usage of other management protocols for configuring Diameter entities may be future work within the group. - Protocol extensions for bulk and grouped AAA session management. The aim of this work is to study and standardize a solution for handling groups of AAA sessions within the Diameter base protocol context. The solution would define how to identify and handle grouped AAA sessions in commands and operations. Additionally, Diameter-based systems require interoperability in order to work. The working group, along with the AD, will need to evaluate any potential extensions and require verification that the proposed extension is needed, and is within the extensibility rules of Diameter and AAA scope. Coordination with other IETF working groups and other SDOs (e.g. 3GPP) will be used to ensure this. Goals and Milestones: Done - Submit the following two Diameter Mobility documents to the IESG for consideration as a Proposed Standards:* 'Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction' * 'Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction' Done - Submit 'Diameter API' to the IESG for consideration as an Informational RFC Done - Submit 'Quality of Service Parameters for Usage with Diameter' to the IESG for consideration as a Proposed Standard. Done - Submit 'Diameter QoS Application' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Support for EAP Re-authentication Protocol' as DIME working group item Done - Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' as DIME working group item Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working group item Done - Submit 'Quality of Service Attributes for Diameter' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter NAT Control Application' as DIME working group item Done - Submit 'Diameter Capabilities Update' as DIME working group item Done - Submit 'Diameter Credit Control Application MIB' to the IESG for consideration as an Informational RFC Done - Submit 'Diameter Base Protocol MIB' to the IESG for consideration as an Informational RFC Done - Submit 'Diameter Capabilities Update' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Extended NAPTR' as DIME working group item Done - Submit 'Realm-Based Redirection In Diameter' as DIME working group item Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized Routing' as DIME working group item Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic Key Transport' as DIME working group item Done - Submit 'Diameter Priority Attribute Value Pairs' as DIME working group item Done - Submit 'Diameter IKEv2 PSK' as DIME working group item Done - Submit Revision of 'Diameter Base Protocol' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic Key Transport' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Priority Attribute Value Pairs' to the IESG for consideration as a Proposed Standard Done - Submit Revision of 'Diameter Network Access Server Application - RFC 4005bis' as DIME working group item Done - Submit 'Diameter NAT Control Application' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter IKEv2 PSK' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Extended NAPTR' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized Routing' to the IESG for consideration as a Proposed Standard Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the IESG for consideration as a Proposed Standard Mar 2012 - Submit Revision of 'Diameter Network Access Server Application - RFC 4005bis' to the IESG for consideration as a Proposed Standard May 2012 - Submit 'Diameter Application Design Guidelines' to the IESG for consideration as a BCP document Standard Jul 2012 - Submit 'Diameter Support for EAP Re-authentication Protocol' to the IESG for consideration as a Proposed Standard Aug 2012 - Submit 'problem statement and requirements for Diameter end-to-end security framework' as Dime working group item. Aug 2012 - Submit a document on 'Protocol extension for bulk and group signaling' as a working group item Dec 2012 - Submit 'problem statement and requirements for Diameter end-to-end security framework' to the IESG for consideration as an Informational RFC. Aug 2013 - Submit a document on 'Protocol extension for bulk and group signaling' to the IESG for consideration as a Proposed Standard From glenzorn@gmail.com Wed Jan 25 02:13:15 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBEE621F8603; Wed, 25 Jan 2012 02:13:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-1] 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 p-lBoRJXpEtK; Wed, 25 Jan 2012 02:13:15 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3E57421F858B; Wed, 25 Jan 2012 02:13:15 -0800 (PST) Received: by qabj34 with SMTP id j34so2924644qab.10 for ; Wed, 25 Jan 2012 02:13:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Umaof8+35a+rRPP2a9mkeVOgF+iIX0CGX+Cy5M9Jkzc=; b=I5n2Kx7K7bBJf6C6USHPgL2576C9w3RHhge4PsIPhIEhsPJPL1817BF+1gVtOJsxWt U6aH8PtOhysUPdt5FAnRKPBgsuMvXEtS7SytPMf4/nSCFzF1+uhCj6GKDSEPrq+9OP3f LBiXycyohh4hMu0EeOjAc4bYk4ddgL1n+NFQY= Received: by 10.224.180.67 with SMTP id bt3mr19607475qab.6.1327486394720; Wed, 25 Jan 2012 02:13:14 -0800 (PST) Received: from [192.168.1.98] (ppp-124-120-221-133.revip2.asianet.co.th. [124.120.221.133]) by mx.google.com with ESMTPS id s18sm1027326qaz.15.2012.01.25.02.13.11 (version=SSLv3 cipher=OTHER); Wed, 25 Jan 2012 02:13:13 -0800 (PST) Message-ID: <4F1FD5B1.6000309@gmail.com> Date: Wed, 25 Jan 2012 17:13:05 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: dime@ietf.org References: <20120124171808.9C0F211E8076@ietfa.amsl.com> In-Reply-To: <20120124171808.9C0F211E8076@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: jouni.korhonen@nsn.com, lionel.morand@orange-ftgroup.com, The IESG Subject: Re: [Dime] WG Action: RECHARTER: Diameter Maintenance and Extensions (dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 10:13:16 -0000 On 1/25/2012 12:18 AM, IESG Secretary wrote: I must say that I'm not really happy with this: > Dec 2012 - Submit 'problem statement and requirements for Diameter > end-to-end security framework' to the IESG for > consideration as an Informational RFC. It seems like a invitation to the same rat hole we went down with the first attempt at e2e security. I assume the problem is well understood since it's been talked to death over at least the last 10 years, first in the context of RADIUS and later Diameter; why not cut to the chase?. From dromasca@avaya.com Wed Jan 25 02:15:30 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7082521F8603; Wed, 25 Jan 2012 02:15:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.345 X-Spam-Level: X-Spam-Status: No, score=-104.345 tagged_above=-999 required=5 tests=[AWL=1.254, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 NlyEgOlSOnS6; Wed, 25 Jan 2012 02:15:29 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD9621F858B; Wed, 25 Jan 2012 02:15:29 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFABrVH0/GmAcF/2dsb2JhbABCrjyBBYFyAQEBAQMBAQEPHgo0CwwEAgEIDQQEAQEBCgYMCwEGASYfCQgBAQQBEggah2KcdJtFBIkuAyMIBYJegQYcglBjBJsWjFk X-IronPort-AV: E=Sophos;i="4.71,567,1320642000"; d="scan'208";a="287951649" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 25 Jan 2012 05:15:27 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 25 Jan 2012 05:10:18 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Jan 2012 11:15:20 +0100 Message-ID: In-Reply-To: <4F1FD5B1.6000309@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] WG Action: RECHARTER: Diameter Maintenance andExtensions (dime) Thread-Index: AczbSfW/1cph7IN5RpOTaTVKGqSgYwAAC+dA References: <20120124171808.9C0F211E8076@ietfa.amsl.com> <4F1FD5B1.6000309@gmail.com> From: "Romascanu, Dan (Dan)" To: "Glen Zorn" , Cc: jouni.korhonen@nsn.com, lionel.morand@orange-ftgroup.com, The IESG Subject: Re: [Dime] WG Action: RECHARTER: Diameter Maintenance andExtensions (dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 10:15:30 -0000 Glen, Can you spell in more details what you propose by 'cut to the chase'?=20 Thanks and Regards, Dan > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > Glen Zorn > Sent: Wednesday, January 25, 2012 12:13 PM > To: dime@ietf.org > Cc: jouni.korhonen@nsn.com; lionel.morand@orange-ftgroup.com; The IESG > Subject: Re: [Dime] WG Action: RECHARTER: Diameter Maintenance > andExtensions (dime) >=20 > On 1/25/2012 12:18 AM, IESG Secretary wrote: >=20 > I must say that I'm not really happy with this: >=20 > > Dec 2012 - Submit 'problem statement and requirements for Diameter > > end-to-end security framework' to the IESG for > > consideration as an Informational RFC. >=20 > It seems like a invitation to the same rat hole we went down with the > first attempt at e2e security. I assume the problem is well understood > since it's been talked to death over at least the last 10 years, first > in the context of RADIUS and later Diameter; why not cut to the chase?. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Wed Jan 25 02:28:13 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 868DA21F85E3; Wed, 25 Jan 2012 02:28:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.621 X-Spam-Level: X-Spam-Status: No, score=-4.621 tagged_above=-999 required=5 tests=[AWL=0.978, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-1] 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 A2iGNshG2qIi; Wed, 25 Jan 2012 02:28:12 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB7821F85D4; Wed, 25 Jan 2012 02:28:06 -0800 (PST) Received: by lahl5 with SMTP id l5so1094164lah.31 for ; Wed, 25 Jan 2012 02:28:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=TFSg1y4XxKwHl1pNPmUdxk5iVmv5j/5MVPt6etl5CyU=; b=OFdt4T1JA9VmXUXljtN+OVhBnXpHMZ7j1x2EoV89wbm3Tdkm9Gl1PS1i7KWaYm8qU4 v2EhOqrCsTBanbr9E7eoxKiWVR0fxDYpZGIpvBwGd+6yAJiYniPLrYqKYtbIVenqcRGF sBFL/6pwCsY/M90UQSd4/B4PzGZ+Ck1/xlZik= Received: by 10.112.8.100 with SMTP id q4mr4152119lba.39.1327487285431; Wed, 25 Jan 2012 02:28:05 -0800 (PST) Received: from a88-112-204-6.elisa-laajakaista.fi (a88-112-204-6.elisa-laajakaista.fi. [88.112.204.6]) by mx.google.com with ESMTPS id oy18sm15804708lab.3.2012.01.25.02.28.03 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Jan 2012 02:28:04 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4F1FD5B1.6000309@gmail.com> Date: Wed, 25 Jan 2012 12:28:02 +0200 Content-Transfer-Encoding: 7bit Message-Id: <556648C5-0C84-4E31-B162-E7D985BDFC1D@gmail.com> References: <20120124171808.9C0F211E8076@ietfa.amsl.com> <4F1FD5B1.6000309@gmail.com> To: Glen Zorn X-Mailer: Apple Mail (2.1084) Cc: jouni.korhonen@nsn.com, lionel.morand@orange-ftgroup.com, dime@ietf.org, The IESG Subject: Re: [Dime] WG Action: RECHARTER: Diameter Maintenance and Extensions (dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 10:28:13 -0000 Glen, Appreciate your views here.. since you were around those days and probably have good recollection why things did not get done. Few points still. You should have come up with arguments while this part of the charter was still under discussion on IETF list. Another point is that the problem statement may well conclude there is no problem to solve or the solution is not worth the hassle (taking e.g. backward compatibility issues into account). - Jouni On Jan 25, 2012, at 12:13 PM, Glen Zorn wrote: > On 1/25/2012 12:18 AM, IESG Secretary wrote: > > I must say that I'm not really happy with this: > >> Dec 2012 - Submit 'problem statement and requirements for Diameter >> end-to-end security framework' to the IESG for >> consideration as an Informational RFC. > > It seems like a invitation to the same rat hole we went down with the > first attempt at e2e security. I assume the problem is well understood > since it's been talked to death over at least the last 10 years, first > in the context of RADIUS and later Diameter; why not cut to the chase?. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From glenzorn@gmail.com Wed Jan 25 03:32:06 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2AB21F8690; Wed, 25 Jan 2012 03:32:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 M4cYAqovvs6v; Wed, 25 Jan 2012 03:32:06 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8153921F867A; Wed, 25 Jan 2012 03:32:02 -0800 (PST) Received: by qcsf16 with SMTP id f16so2035470qcs.31 for ; Wed, 25 Jan 2012 03:32:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=NrGKlpnociPAgraddKGQeyTmd0juFpdFz5JDuNvNCN0=; b=Cn744Ch9kZflo7FyjFGC6qTaM5U1Ttb+hlc2umhjDm9EajhQR5zaSEqVwyNdnmSH2W 3TkXkNih/nQGOYO/l1gAcd/S4zFr3lbxLIiUeTDp2FqHDTjMnSlvZINOWnZ9onTSWWun DeqNHqJUcLLRVxKweuElFnabOar+HJuxzAtOo= Received: by 10.229.137.76 with SMTP id v12mr4551528qct.61.1327491122037; Wed, 25 Jan 2012 03:32:02 -0800 (PST) Received: from [192.168.1.98] (ppp-124-120-221-133.revip2.asianet.co.th. [124.120.221.133]) by mx.google.com with ESMTPS id ft9sm1387857qab.20.2012.01.25.03.31.58 (version=SSLv3 cipher=OTHER); Wed, 25 Jan 2012 03:32:00 -0800 (PST) Message-ID: <4F1FE828.6030605@gmail.com> Date: Wed, 25 Jan 2012 18:31:52 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: jouni korhonen References: <20120124171808.9C0F211E8076@ietfa.amsl.com> <4F1FD5B1.6000309@gmail.com> <556648C5-0C84-4E31-B162-E7D985BDFC1D@gmail.com> In-Reply-To: <556648C5-0C84-4E31-B162-E7D985BDFC1D@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: jouni.korhonen@nsn.com, lionel.morand@orange-ftgroup.com, dime@ietf.org, The IESG Subject: Re: [Dime] WG Action: RECHARTER: Diameter Maintenance and Extensions (dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 11:32:07 -0000 On 1/25/2012 5:28 PM, jouni korhonen wrote: > Glen, > > Appreciate your views here.. since you were around those days and > probably have good recollection why things did not get done. Few > points still. You should have come up with arguments while this > part of the charter was still under discussion on IETF list. I have a "special" folder for the IETF list (as, I'm sure, do many others ;-) that I only open when I know that there is something in it of interest to me; I wonder why this discussion didn't take place on the dime list -- it does seem pertinent to the WG. > Another > point is that the problem statement may well conclude there is no > problem to solve I'm that that is quite possible, given the apparent affection for magical thinking on the part of certain vested interests. > or the solution is not worth the hassle (taking > e.g. backward compatibility issues into account). That would betray a major lack of, well, just about everything on the part of the WG and would be a major argument for dissolution, IMHO. ... From glenzorn@gmail.com Wed Jan 25 03:34:29 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FED321F8603; Wed, 25 Jan 2012 03:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.849 X-Spam-Level: X-Spam-Status: No, score=-3.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 ZMmCbPiJGxVR; Wed, 25 Jan 2012 03:34:28 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAE421F8598; Wed, 25 Jan 2012 03:34:28 -0800 (PST) Received: by qcsf16 with SMTP id f16so2036893qcs.31 for ; Wed, 25 Jan 2012 03:34:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=+EQhkG9jzcGxkibKEqKcHoQd60cKS4VD9cKmz4kDy08=; b=EMWCrW8YjQVIveIYhdmlG4cXJxthMB6rilfSmgOWqcJzoq5b0/F6BdD4jPDx5Ab7G/ JvJiFtKOw2E3aglaqh7JvXJfpYKAmz4NY1N8J/CW5+3/TNml57P8H3XLD0i5PP2PkxWj NLmfK+TZgtfkChiMIMdwaWI3wdg7pEwNMrOs0= Received: by 10.224.173.146 with SMTP id p18mr20192608qaz.8.1327491267846; Wed, 25 Jan 2012 03:34:27 -0800 (PST) Received: from [192.168.1.98] (ppp-124-120-221-133.revip2.asianet.co.th. [124.120.221.133]) by mx.google.com with ESMTPS id dk2sm1425873qab.12.2012.01.25.03.34.24 (version=SSLv3 cipher=OTHER); Wed, 25 Jan 2012 03:34:26 -0800 (PST) Message-ID: <4F1FE8BA.6090406@gmail.com> Date: Wed, 25 Jan 2012 18:34:18 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <20120124171808.9C0F211E8076@ietfa.amsl.com> <4F1FD5B1.6000309@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: jouni.korhonen@nsn.com, lionel.morand@orange-ftgroup.com, dime@ietf.org, The IESG Subject: Re: [Dime] WG Action: RECHARTER: Diameter Maintenance andExtensions (dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 11:34:29 -0000 On 1/25/2012 5:15 PM, Romascanu, Dan (Dan) wrote: > Glen, > > Can you spell in more details what you propose by 'cut to the chase'? Yes, I mean design a solution to the well-understood problem that is simple and relatively easy to implement & requires virtually no changes to Diameter. ... From dromasca@avaya.com Wed Jan 25 04:47:51 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA4121F8653; Wed, 25 Jan 2012 04:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.86 X-Spam-Level: X-Spam-Status: No, score=-103.86 tagged_above=-999 required=5 tests=[AWL=0.739, BAYES_00=-2.599, GB_I_INVITATION=-2, USER_IN_WHITELIST=-100] 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 aABgSEBYIw+u; Wed, 25 Jan 2012 04:47:50 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7461B21F8599; Wed, 25 Jan 2012 04:47:50 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKz4H0/GmAcF/2dsb2JhbABCrj6BBYFyAQEBAQMBAQEPHgo0CwwEAgEIDQQEAQEBCgYFBwsBBgEmHwkIAQEEARIIEweHYpxfm0gEiS4DIwiCY4EGHAuCRWMEmxaMWQ X-IronPort-AV: E=Sophos;i="4.71,568,1320642000"; d="scan'208";a="228468217" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 25 Jan 2012 07:47:36 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 25 Jan 2012 07:42:26 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Jan 2012 13:47:33 +0100 Message-ID: In-Reply-To: <556648C5-0C84-4E31-B162-E7D985BDFC1D@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] WG Action: RECHARTER: Diameter Maintenance and Extensions(dime) Thread-Index: AczbTA6QDaqf65StSoycdPPgB9zQWwAEs1+A References: <20120124171808.9C0F211E8076@ietfa.amsl.com><4F1FD5B1.6000309@gmail.com> <556648C5-0C84-4E31-B162-E7D985BDFC1D@gmail.com> From: "Romascanu, Dan (Dan)" To: "jouni korhonen" , "Glen Zorn" Cc: jouni.korhonen@nsn.com, lionel.morand@orange-ftgroup.com, dime@ietf.org, The IESG Subject: Re: [Dime] WG Action: RECHARTER: Diameter Maintenance and Extensions(dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 12:47:51 -0000 ... or the other way - the WG may actually beat the schedule, and get consensus earlier that the problem is well understood and on the requirements of the solution, while in parallel work is being done on the simple and relatively easy to implement solution hinted by Glen. The wording of the charter is cautious enough not to make presumptions about things going one way or the other, but does not preclude IMO any scenario, including the very optimistic one.=20 Regards, Dan > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of > jouni korhonen > Sent: Wednesday, January 25, 2012 12:28 PM > To: Glen Zorn > Cc: jouni.korhonen@nsn.com; lionel.morand@orange-ftgroup.com; > dime@ietf.org; The IESG > Subject: Re: [Dime] WG Action: RECHARTER: Diameter Maintenance and > Extensions(dime) >=20 > Glen, >=20 > Appreciate your views here.. since you were around those days and > probably have good recollection why things did not get done. Few > points still. You should have come up with arguments while this > part of the charter was still under discussion on IETF list. Another > point is that the problem statement may well conclude there is no > problem to solve or the solution is not worth the hassle (taking > e.g. backward compatibility issues into account). >=20 > - Jouni >=20 >=20 > On Jan 25, 2012, at 12:13 PM, Glen Zorn wrote: >=20 > > On 1/25/2012 12:18 AM, IESG Secretary wrote: > > > > I must say that I'm not really happy with this: > > > >> Dec 2012 - Submit 'problem statement and requirements for Diameter > >> end-to-end security framework' to the IESG for > >> consideration as an Informational RFC. > > > > It seems like a invitation to the same rat hole we went down with the > > first attempt at e2e security. I assume the problem is well > understood > > since it's been talked to death over at least the last 10 years, > first > > in the context of RADIUS and later Diameter; why not cut to the > chase?. > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime From dromasca@avaya.com Wed Jan 25 05:00:21 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5085821F86AA; Wed, 25 Jan 2012 05:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.368 X-Spam-Level: X-Spam-Status: No, score=-103.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 QVrxEV2zFn6B; Wed, 25 Jan 2012 05:00:20 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 6487621F86A9; Wed, 25 Jan 2012 05:00:20 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAMn7H0+HCzI1/2dsb2JhbABDrj6BBYFyAQEBAQMBAQEPHgo0CwwEAgEIDQQEAQEBCgYFBwsBBgEmHwkIAQEEARIIARIHh2KcU5tNiQklAyMIgmOBBhAJAwuCRWMEmxaMWQ X-IronPort-AV: E=Sophos;i="4.71,568,1320642000"; d="scan'208";a="326372261" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 25 Jan 2012 08:00:19 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 25 Jan 2012 07:46:38 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Jan 2012 14:00:17 +0100 Message-ID: In-Reply-To: <4F1FE828.6030605@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] WG Action: RECHARTER: Diameter Maintenance and Extensions (dime) Thread-Index: AczbVPsE38E5Y+5CTnK2DEKNajZBIwAC8uXg References: <20120124171808.9C0F211E8076@ietfa.amsl.com><4F1FD5B1.6000309@gmail.com><556648C5-0C84-4E31-B162-E7D985BDFC1D@gmail.com> <4F1FE828.6030605@gmail.com> From: "Romascanu, Dan (Dan)" To: "Glen Zorn" , "jouni korhonen" Cc: jouni.korhonen@nsn.com, lionel.morand@orange-ftgroup.com, dime@ietf.org, The IESG Subject: Re: [Dime] WG Action: RECHARTER: Diameter Maintenance and Extensions (dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 13:00:21 -0000 > ; I wonder why this discussion didn't take place on the > dime list -- it does seem pertinent to the WG. It did take place on the dime list - see message http://www.ietf.org/mail-archive/web/dime/current/msg05001.html and the following ones.=20 The IETF and IESG mail lists were also copied because the document was in external review.=20 Regards, Dan > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > Glen Zorn > Sent: Wednesday, January 25, 2012 1:32 PM > To: jouni korhonen > Cc: jouni.korhonen@nsn.com; lionel.morand@orange-ftgroup.com; > dime@ietf.org; The IESG > Subject: Re: [Dime] WG Action: RECHARTER: Diameter Maintenance and > Extensions (dime) >=20 > On 1/25/2012 5:28 PM, jouni korhonen wrote: >=20 > > Glen, > > > > Appreciate your views here.. since you were around those days and > > probably have good recollection why things did not get done. Few > > points still. You should have come up with arguments while this > > part of the charter was still under discussion on IETF list. >=20 > I have a "special" folder for the IETF list (as, I'm sure, do many > others ;-) that I only open when I know that there is something in it > of > interest to me; I wonder why this discussion didn't take place on the > dime list -- it does seem pertinent to the WG. >=20 > > Another > > point is that the problem statement may well conclude there is no > > problem to solve >=20 > I'm that that is quite possible, given the apparent affection for > magical thinking on the part of certain vested interests. >=20 > > or the solution is not worth the hassle (taking > > e.g. backward compatibility issues into account). >=20 > That would betray a major lack of, well, just about everything on the > part of the WG and would be a major argument for dissolution, IMHO. >=20 > ... > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Wed Jan 25 05:14:26 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA25D21F8646; Wed, 25 Jan 2012 05:14:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.678 X-Spam-Level: X-Spam-Status: No, score=-4.678 tagged_above=-999 required=5 tests=[AWL=0.921, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-1] 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 9ePr+oOL89DA; Wed, 25 Jan 2012 05:14:26 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 99D8A21F8629; Wed, 25 Jan 2012 05:14:25 -0800 (PST) Received: by lahl5 with SMTP id l5so1213223lah.31 for ; Wed, 25 Jan 2012 05:14:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=8g8dF+8zDfuJfr4+DvO2uVS+9DzRR9tntX1aARyLTIc=; b=Sb6QOfu2KT9IYnT9+3jCmw2ldUjatftVVQM6FEy4Okn8lzNgAq+KZfxePUTGIOAKB8 yHoaLjSo0YoqhEqH/YeISI9RZNnlNeljr8S+dyfOluQ308yalF94s7GhNqzuNozHdurj XFiBHkIGYk7PQHp45ThP2vdo6w8PUexTQHfTs= Received: by 10.112.101.198 with SMTP id fi6mr4444440lbb.18.1327497264592; Wed, 25 Jan 2012 05:14:24 -0800 (PST) Received: from a88-112-204-6.elisa-laajakaista.fi (a88-112-204-6.elisa-laajakaista.fi. [88.112.204.6]) by mx.google.com with ESMTPS id nt7sm294670lab.15.2012.01.25.05.14.22 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Jan 2012 05:14:23 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Wed, 25 Jan 2012 15:14:21 +0200 Content-Transfer-Encoding: 7bit Message-Id: <0AE3C899-9DFD-4398-B71A-301B76847CEC@gmail.com> References: <20120124171808.9C0F211E8076@ietfa.amsl.com><4F1FD5B1.6000309@gmail.com> <556648C5-0C84-4E31-B162-E7D985BDFC1D@gmail.com> To: "Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.1084) Cc: jouni.korhonen@nsn.com, lionel.morand@orange-ftgroup.com, dime@ietf.org, The IESG Subject: Re: [Dime] WG Action: RECHARTER: Diameter Maintenance and Extensions(dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 13:14:27 -0000 Hi, On Jan 25, 2012, at 2:47 PM, Romascanu, Dan (Dan) wrote: > ... or the other way - the WG may actually beat the schedule, and get > consensus earlier that the problem is well understood and on the > requirements of the solution, while in parallel work is being done on > the simple and relatively easy to implement solution hinted by Glen. The I do not quite buy this being something that can be accomplished hands down.. otherwise it would have been done during these 10 years time. Also, it is, at least to me personally, an indication that the lack of Diameter specific e2e security has not been an issue in real life so far. > wording of the charter is cautious enough not to make presumptions about > things going one way or the other, but does not preclude IMO any > scenario, including the very optimistic one. Indeed. - Jouni > > Regards, > > Dan > > > > >> -----Original Message----- >> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf > Of >> jouni korhonen >> Sent: Wednesday, January 25, 2012 12:28 PM >> To: Glen Zorn >> Cc: jouni.korhonen@nsn.com; lionel.morand@orange-ftgroup.com; >> dime@ietf.org; The IESG >> Subject: Re: [Dime] WG Action: RECHARTER: Diameter Maintenance and >> Extensions(dime) >> >> Glen, >> >> Appreciate your views here.. since you were around those days and >> probably have good recollection why things did not get done. Few >> points still. You should have come up with arguments while this >> part of the charter was still under discussion on IETF list. Another >> point is that the problem statement may well conclude there is no >> problem to solve or the solution is not worth the hassle (taking >> e.g. backward compatibility issues into account). >> >> - Jouni >> >> >> On Jan 25, 2012, at 12:13 PM, Glen Zorn wrote: >> >>> On 1/25/2012 12:18 AM, IESG Secretary wrote: >>> >>> I must say that I'm not really happy with this: >>> >>>> Dec 2012 - Submit 'problem statement and requirements for Diameter >>>> end-to-end security framework' to the IESG for >>>> consideration as an Informational RFC. >>> >>> It seems like a invitation to the same rat hole we went down with > the >>> first attempt at e2e security. I assume the problem is well >> understood >>> since it's been talked to death over at least the last 10 years, >> first >>> in the context of RADIUS and later Diameter; why not cut to the >> chase?. >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime > From glenzorn@gmail.com Wed Jan 25 21:43:59 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB3811E80E5; Wed, 25 Jan 2012 21:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 p5DMO7kKhK1d; Wed, 25 Jan 2012 21:43:59 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1946A11E80CD; Wed, 25 Jan 2012 21:43:59 -0800 (PST) Received: by pbbb11 with SMTP id b11so485638pbb.31 for ; Wed, 25 Jan 2012 21:43:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=hgimV6tgqx2AsLbrh4L0XACfQE/Bx9HRXEztukQoNGE=; b=CvNb4egviQhwG7SHmpas2GJXryYoQalHNbViptbsX2kJgFAMxKJqzHKlq8ydomTNFG yzlLaf46308PCFmjp25L5u8yvdMw9NFV5Be3Y8LnsZwWKzfn2fpPwYftNoUQIn+KOQrX +23/c2KpyEH7mWQ+C5I4/SFiP1igfrCfmwnbw= Received: by 10.68.189.6 with SMTP id ge6mr2109458pbc.93.1327556637823; Wed, 25 Jan 2012 21:43:57 -0800 (PST) Received: from [192.168.1.98] (ppp-124-120-18-220.revip2.asianet.co.th. [124.120.18.220]) by mx.google.com with ESMTPS id i1sm8332224pbt.19.2012.01.25.21.43.53 (version=SSLv3 cipher=OTHER); Wed, 25 Jan 2012 21:43:56 -0800 (PST) Message-ID: <4F20E816.9050605@gmail.com> Date: Thu, 26 Jan 2012 12:43:50 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <20120124171808.9C0F211E8076@ietfa.amsl.com><4F1FD5B1.6000309@gmail.com><556648C5-0C84-4E31-B162-E7D985BDFC1D@gmail.com> <4F1FE828.6030605@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: jouni.korhonen@nsn.com, lionel.morand@orange-ftgroup.com, dime@ietf.org, The IESG Subject: Re: [Dime] WG Action: RECHARTER: Diameter Maintenance and Extensions (dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 05:43:59 -0000 On 1/25/2012 8:00 PM, Romascanu, Dan (Dan) wrote: >> ; I wonder why this discussion didn't take place on the >> dime list -- it does seem pertinent to the WG. > > It did take place on the dime list - see message > http://www.ietf.org/mail-archive/web/dime/current/msg05001.html and the > following ones. Interesting: it appears that I received none of those messages. Oh, well. ... From glenzorn@gmail.com Wed Jan 25 22:07:51 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82CF521F85C4; Wed, 25 Jan 2012 22:07:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.766 X-Spam-Level: X-Spam-Status: No, score=-4.766 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-1] 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 zzicMFrd9nvE; Wed, 25 Jan 2012 22:07:50 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8E121F85B9; Wed, 25 Jan 2012 22:07:50 -0800 (PST) Received: by pbbb11 with SMTP id b11so501305pbb.31 for ; Wed, 25 Jan 2012 22:07:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ZiiwVVxNQfmdRrdEOWSfLn3HZ4YfMwvHfOsNFl3GNeU=; b=dgf8T+T2QzR8N2wSo7Ax7aFh43dV89/iN6zOC2B/IV5l9Cla57QsIVokfwXQHL64YU 743ggrqTzShrpW0UHJwL6QOxzAU9OXwbSmHVk3OQaqCw4DIEtOMHCG3GqRI/efrVfZ3a FXoYWxvceSm46ymtcf/ml//VLtxs7HeMhqcnw= Received: by 10.68.229.2 with SMTP id sm2mr2247027pbc.98.1327558070419; Wed, 25 Jan 2012 22:07:50 -0800 (PST) Received: from [192.168.1.98] (ppp-124-120-18-220.revip2.asianet.co.th. [124.120.18.220]) by mx.google.com with ESMTPS id x8sm8506200pbr.11.2012.01.25.22.07.45 (version=SSLv3 cipher=OTHER); Wed, 25 Jan 2012 22:07:48 -0800 (PST) Message-ID: <4F20EDAD.1030804@gmail.com> Date: Thu, 26 Jan 2012 13:07:41 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: jouni korhonen References: <20120124171808.9C0F211E8076@ietfa.amsl.com><4F1FD5B1.6000309@gmail.com> <556648C5-0C84-4E31-B162-E7D985BDFC1D@gmail.com> <0AE3C899-9DFD-4398-B71A-301B76847CEC@gmail.com> In-Reply-To: <0AE3C899-9DFD-4398-B71A-301B76847CEC@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: lionel.morand@orange-ftgroup.com, dime@ietf.org, The IESG , jouni.korhonen@nsn.com Subject: Re: [Dime] WG Action: RECHARTER: Diameter Maintenance and Extensions(dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 06:07:51 -0000 On 1/25/2012 8:14 PM, jouni korhonen wrote: ... >> ... or the other way - the WG may actually beat the schedule, and get >> consensus earlier that the problem is well understood and on the >> requirements of the solution, while in parallel work is being done on >> the simple and relatively easy to implement solution hinted by Glen. The > > I do not quite buy this being something that can be accomplished hands > down.. otherwise it would have been done during these 10 years time. Seems like your next statement explains this one. > Also, > it is, at least to me personally, an indication that the lack of Diameter > specific e2e security has not been an issue in real life so far. If life in which networks are secured by claim alone is "real", then it's certainly not an issue (nor is the use of any security measures like TLS or IPsec). It must be wonderful to live in the land of magic, where do I get a ticket? Not that I'm complaining: I've made quite a bit of money off of organizations that claimed to the outside world (and internally, as much as possible) that there networks were perfectly secure just because they said so... > >> wording of the charter is cautious enough not to make presumptions about >> things going one way or the other, but does not preclude IMO any >> scenario, including the very optimistic one. > > Indeed. > > - Jouni > > >> >> Regards, >> >> Dan >> >> >> >> >>> -----Original Message----- >>> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf >> Of >>> jouni korhonen >>> Sent: Wednesday, January 25, 2012 12:28 PM >>> To: Glen Zorn >>> Cc: jouni.korhonen@nsn.com; lionel.morand@orange-ftgroup.com; >>> dime@ietf.org; The IESG >>> Subject: Re: [Dime] WG Action: RECHARTER: Diameter Maintenance and >>> Extensions(dime) >>> >>> Glen, >>> >>> Appreciate your views here.. since you were around those days and >>> probably have good recollection why things did not get done. Few >>> points still. You should have come up with arguments while this >>> part of the charter was still under discussion on IETF list. Another >>> point is that the problem statement may well conclude there is no >>> problem to solve or the solution is not worth the hassle (taking >>> e.g. backward compatibility issues into account). >>> >>> - Jouni >>> >>> >>> On Jan 25, 2012, at 12:13 PM, Glen Zorn wrote: >>> >>>> On 1/25/2012 12:18 AM, IESG Secretary wrote: >>>> >>>> I must say that I'm not really happy with this: >>>> >>>>> Dec 2012 - Submit 'problem statement and requirements for Diameter >>>>> end-to-end security framework' to the IESG for >>>>> consideration as an Informational RFC. >>>> >>>> It seems like a invitation to the same rat hole we went down with >> the >>>> first attempt at e2e security. I assume the problem is well >>> understood >>>> since it's been talked to death over at least the last 10 years, >>> first >>>> in the context of RADIUS and later Diameter; why not cut to the >>> chase?. >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >> > From glenzorn@gmail.com Wed Jan 25 22:17:18 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC7A21F867B; Wed, 25 Jan 2012 22:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.885 X-Spam-Level: X-Spam-Status: No, score=-3.885 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 E7APiLSdaapl; Wed, 25 Jan 2012 22:17:17 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB4921F8675; Wed, 25 Jan 2012 22:17:16 -0800 (PST) Received: by dado14 with SMTP id o14so246789dad.31 for ; Wed, 25 Jan 2012 22:17:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=CtgiQOthb1PIuN2vId33fLCh8OnQ3F/oBDhQ38hGZ9I=; b=JSWKQmuuPWoYKAab3mun5yJuhE75wPhwtweRsw9GKbMMxHgThKYbPWypzxMYxbWKJf T2w9D5KBURXSBeYjTK9p1mgH17FsTma5FjU/2IPXkyf8kz/Skl1E2X7e78EGIjtwfPTv nIkwjC+8l8Sxqxxze2P0+rE5HoqN2prkARDTQ= Received: by 10.68.135.70 with SMTP id pq6mr2441931pbb.47.1327558636794; Wed, 25 Jan 2012 22:17:16 -0800 (PST) Received: from [192.168.1.98] (ppp-124-120-18-220.revip2.asianet.co.th. [124.120.18.220]) by mx.google.com with ESMTPS id i1sm8533097pbt.19.2012.01.25.22.17.13 (version=SSLv3 cipher=OTHER); Wed, 25 Jan 2012 22:17:15 -0800 (PST) Message-ID: <4F20EFE5.4050005@gmail.com> Date: Thu, 26 Jan 2012 13:17:09 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <20120124171808.9C0F211E8076@ietfa.amsl.com><4F1FD5B1.6000309@gmail.com> <556648C5-0C84-4E31-B162-E7D985BDFC1D@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: jouni.korhonen@nsn.com, lionel.morand@orange-ftgroup.com, dime@ietf.org, The IESG Subject: Re: [Dime] WG Action: RECHARTER: Diameter Maintenance and Extensions(dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 06:17:18 -0000 On 1/25/2012 7:47 PM, Romascanu, Dan (Dan) wrote: > ... or the other way - the WG may actually beat the schedule, and get > consensus earlier that the problem is well understood and on the > requirements of the solution, while in parallel work is being done on > the simple and relatively easy to implement solution hinted by Glen. The > wording of the charter is cautious enough not to make presumptions about > things going one way or the other, but does not preclude IMO any > scenario, including the very optimistic one. Hmm. OK, maybe I just can't read today, but Aug 2012 Submit 'problem statement and requirements for Diameter end-to-end security framework' as Dime working group item and Dec 2012 Submit 'problem statement and requirements for Diameter end-to-end security framework' to the IESG for consideration as an Informational RFC seem pretty specific to me, in particular assuming the creation of not merely a "problem statement" and a requirements document but a "framework" as well. That would be three useless (in that, by themselves, they do _nothing_ to change (let alone improve!) Diameter security) things that we would spend a year creating. Splendid! ... From jouni.nospam@gmail.com Wed Jan 25 23:45:32 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 321F521F8656; Wed, 25 Jan 2012 23:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.73 X-Spam-Level: X-Spam-Status: No, score=-4.73 tagged_above=-999 required=5 tests=[AWL=0.869, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-1] 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 H1qx0jXwjFwJ; Wed, 25 Jan 2012 23:45:31 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0305721F8655; Wed, 25 Jan 2012 23:45:30 -0800 (PST) Received: by lahl5 with SMTP id l5so164878lah.31 for ; Wed, 25 Jan 2012 23:45:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=XXGx7oI5RKnMsG/UQDIc8/f5mXR1aEUiME4N2xAp/Mw=; b=tt/AutYsqRsWVvwHQkLrxucQcySmA5Z+PxGCKH5r2pfv+rbsuL7bSGnU7Nq7MtHPH3 9OADZ4XgZmn6o15ReUG/YjrdfanIsPk5YYi+GiUMrAddgIAaWqPolWErC60qwZNZdQT9 GeFCTldagI6mBtbuBMqF63HBzrEvpxYnOSPWA= Received: by 10.152.147.103 with SMTP id tj7mr529598lab.3.1327563929930; Wed, 25 Jan 2012 23:45:29 -0800 (PST) Received: from a88-112-204-6.elisa-laajakaista.fi (a88-112-204-6.elisa-laajakaista.fi. [88.112.204.6]) by mx.google.com with ESMTPS id k13sm2418790lbu.16.2012.01.25.23.45.27 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Jan 2012 23:45:29 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4F20EDAD.1030804@gmail.com> Date: Thu, 26 Jan 2012 09:45:26 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <20120124171808.9C0F211E8076@ietfa.amsl.com><4F1FD5B1.6000309@gmail.com> <556648C5-0C84-4E31-B162-E7D985BDFC1D@gmail.com> <0AE3C899-9DFD-4398-B71A-301B76847CEC@gmail.com> <4F20EDAD.1030804@gmail.com> To: Glen Zorn X-Mailer: Apple Mail (2.1084) Cc: lionel.morand@orange-ftgroup.com, dime@ietf.org, The IESG , jouni.korhonen@nsn.com Subject: Re: [Dime] WG Action: RECHARTER: Diameter Maintenance and Extensions(dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 07:45:32 -0000 Glen, On Jan 26, 2012, at 8:07 AM, Glen Zorn wrote: > On 1/25/2012 8:14 PM, jouni korhonen wrote: > > ... > >>> ... or the other way - the WG may actually beat the schedule, and get >>> consensus earlier that the problem is well understood and on the >>> requirements of the solution, while in parallel work is being done on >>> the simple and relatively easy to implement solution hinted by Glen. The >> >> I do not quite buy this being something that can be accomplished hands >> down.. otherwise it would have been done during these 10 years time. > > Seems like your next statement explains this one. > >> Also, >> it is, at least to me personally, an indication that the lack of Diameter >> specific e2e security has not been an issue in real life so far. > > If life in which networks are secured by claim alone is "real", then > it's certainly not an issue (nor is the use of any security measures > like TLS or IPsec). It must be wonderful to live in the land of magic, > where do I get a ticket? Not that I'm complaining: I've made quite a ;-) > bit of money off of organizations that claimed to the outside world (and > internally, as much as possible) that there networks were perfectly > secure just because they said so... As you know, this has been the case for quite some time.. and maybe the "so far" part is about the end now. Still I do not see too many requests coming from the field to fix the situation. That gives us some time to work on a solution, though. - Jouni > >> >>> wording of the charter is cautious enough not to make presumptions about >>> things going one way or the other, but does not preclude IMO any >>> scenario, including the very optimistic one. >> >> Indeed. >> >> - Jouni >> >> >>> >>> Regards, >>> >>> Dan >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf >>> Of >>>> jouni korhonen >>>> Sent: Wednesday, January 25, 2012 12:28 PM >>>> To: Glen Zorn >>>> Cc: jouni.korhonen@nsn.com; lionel.morand@orange-ftgroup.com; >>>> dime@ietf.org; The IESG >>>> Subject: Re: [Dime] WG Action: RECHARTER: Diameter Maintenance and >>>> Extensions(dime) >>>> >>>> Glen, >>>> >>>> Appreciate your views here.. since you were around those days and >>>> probably have good recollection why things did not get done. Few >>>> points still. You should have come up with arguments while this >>>> part of the charter was still under discussion on IETF list. Another >>>> point is that the problem statement may well conclude there is no >>>> problem to solve or the solution is not worth the hassle (taking >>>> e.g. backward compatibility issues into account). >>>> >>>> - Jouni >>>> >>>> >>>> On Jan 25, 2012, at 12:13 PM, Glen Zorn wrote: >>>> >>>>> On 1/25/2012 12:18 AM, IESG Secretary wrote: >>>>> >>>>> I must say that I'm not really happy with this: >>>>> >>>>>> Dec 2012 - Submit 'problem statement and requirements for Diameter >>>>>> end-to-end security framework' to the IESG for >>>>>> consideration as an Informational RFC. >>>>> >>>>> It seems like a invitation to the same rat hole we went down with >>> the >>>>> first attempt at e2e security. I assume the problem is well >>>> understood >>>>> since it's been talked to death over at least the last 10 years, >>>> first >>>>> in the context of RADIUS and later Diameter; why not cut to the >>>> chase?. >>>>> >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>> >> > From dromasca@avaya.com Thu Jan 26 00:40:42 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B510521F8681; Thu, 26 Jan 2012 00:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.878 X-Spam-Level: X-Spam-Status: No, score=-102.878 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 IKLaeC3FBdlS; Thu, 26 Jan 2012 00:40:42 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id D337C21F8677; Thu, 26 Jan 2012 00:40:41 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABkRIU/GmAcF/2dsb2JhbABCrkSBBYFyAQEBAQMSHgo/DAQCAQgNBAQBAQEKBgwLAQYBRQkIAQEEEwgTB6Qqm0aJFycGNRQDgm4TDoFJgktjBJsWjFk X-IronPort-AV: E=Sophos;i="4.71,573,1320642000"; d="scan'208";a="228641623" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 26 Jan 2012 03:40:39 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 26 Jan 2012 03:35:27 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Jan 2012 09:40:37 +0100 Message-ID: In-Reply-To: <4F20EFE5.4050005@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] WG Action: RECHARTER: Diameter Maintenance andExtensions(dime) Thread-Index: AczcBIiID/3dziHmRiKCtfpjnV4OoAAAMHqg References: <20120124171808.9C0F211E8076@ietfa.amsl.com><4F1FD5B1.6000309@gmail.com><556648C5-0C84-4E31-B162-E7D985BDFC1D@gmail.com> <4F20EFE5.4050005@gmail.com> From: "Romascanu, Dan (Dan)" To: "Glen Zorn" Cc: jouni.korhonen@nsn.com, lionel.morand@orange-ftgroup.com, dime@ietf.org, The IESG Subject: Re: [Dime] WG Action: RECHARTER: Diameter Maintenance andExtensions(dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 08:40:42 -0000 > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of > Glen Zorn > Sent: Thursday, January 26, 2012 8:17 AM > To: Romascanu, Dan (Dan) > Cc: jouni.korhonen@nsn.com; jouni korhonen; lionel.morand@orange- > ftgroup.com; dime@ietf.org; The IESG > Subject: Re: [Dime] WG Action: RECHARTER: Diameter Maintenance > andExtensions(dime) >=20 > On 1/25/2012 7:47 PM, Romascanu, Dan (Dan) wrote: >=20 > > ... or the other way - the WG may actually beat the schedule, and get > > consensus earlier that the problem is well understood and on the > > requirements of the solution, while in parallel work is being done on > > the simple and relatively easy to implement solution hinted by Glen. > The > > wording of the charter is cautious enough not to make presumptions > about > > things going one way or the other, but does not preclude IMO any > > scenario, including the very optimistic one. >=20 > Hmm. OK, maybe I just can't read today, but >=20 > Aug 2012 > Submit 'problem statement and requirements for Diameter end-to-end > security framework' as Dime working group item >=20 > and >=20 > Dec 2012 > Submit 'problem statement and requirements for Diameter end-to-end > security framework' to the IESG for consideration as an Informational > RFC >=20 > seem pretty specific to me, in particular assuming the creation of not > merely a "problem statement" and a requirements document but a > "framework" as well. That would be three useless (in that, by > themselves, they do _nothing_ to change (let alone improve!) Diameter > security) things that we would spend a year creating. Splendid! >=20 > ... [[DR]] If the WG can reach consensus on the problem statement and requirements in three months instead of eleven, we can add the work item on the solution immediately. Let us just start doing this.=20 Dan =20 From internet-drafts@ietf.org Thu Jan 26 09:16:48 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5F221F86C3; Thu, 26 Jan 2012 09:16:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.251 X-Spam-Level: X-Spam-Status: No, score=-101.251 tagged_above=-999 required=5 tests=[AWL=1.349, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 G9FA1Ur2cg6J; Thu, 26 Jan 2012 09:16:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD98D21F86A8; Thu, 26 Jan 2012 09:16:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120126171647.396.45167.idtracker@ietfa.amsl.com> Date: Thu, 26 Jan 2012 09:16:47 -0800 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-pmip6-lr-07.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 17:16:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions W= orking Group of the IETF. Title : Diameter Support for Proxy Mobile IPv6 Localized Routing Author(s) : Glen Zorn Qin Wu Marco Liebsch Jouni Korhonen Filename : draft-ietf-dime-pmip6-lr-07.txt Pages : 16 Date : 2012-01-26 In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by the Mobile Access Gateway (MAG) to which it is attached are typically tunneled to a Local Mobility Anchor (LMA) for routing. The term "localized routing" refers to a method by which packets are routed directly between an MN's MAG and the MAG of its Correspondent Node (CN) without involving any LMA. In order to establish a localized routing session between two Mobile Access Gateways in a Proxy Mobile IPv6 domain, two tasks must be accomplished: A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-pmip6-lr-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-pmip6-lr-07.txt From glenzorn@gmail.com Sun Jan 29 21:58:35 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F9421F84BF; Sun, 29 Jan 2012 21:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.354 X-Spam-Level: X-Spam-Status: No, score=-3.354 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 XjZ3fOCkF1hV; Sun, 29 Jan 2012 21:58:34 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 68C2C21F84DE; Sun, 29 Jan 2012 21:58:34 -0800 (PST) Received: by qcsf16 with SMTP id f16so2343762qcs.31 for ; Sun, 29 Jan 2012 21:58:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=BVmcnQDM59Ah0ri2l4DEHjJYuOahWjXNjhtbp+VX6W4=; b=jtMkkqicK7md/UnvOjUde0WdvSYqPVi6kp2lxBAUPogxnzna6uDc6B8Pblq4O1bxZw 2XsZWBjqRqpVrA+3Xh+CV7TYi+nJ3xCh6QpcoT53b7p6Ur8sJY4Kw3f3I7KRxSbrCR0r s0VwfmrzOrSQTnfnD33NGk5gKneI3ttdnEGjE= Received: by 10.224.72.207 with SMTP id n15mr9650250qaj.14.1327903113834; Sun, 29 Jan 2012 21:58:33 -0800 (PST) Received: from [192.168.1.98] (ppp-124-122-106-161.revip2.asianet.co.th. [124.122.106.161]) by mx.google.com with ESMTPS id fh6sm32872881qab.22.2012.01.29.21.58.29 (version=SSLv3 cipher=OTHER); Sun, 29 Jan 2012 21:58:32 -0800 (PST) Message-ID: <4F263182.6080709@gmail.com> Date: Mon, 30 Jan 2012 12:58:26 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <20120124171808.9C0F211E8076@ietfa.amsl.com><4F1FD5B1.6000309@gmail.com><556648C5-0C84-4E31-B162-E7D985BDFC1D@gmail.com> <4F20EFE5.4050005@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: jouni.korhonen@nsn.com, lionel.morand@orange-ftgroup.com, dime@ietf.org, The IESG Subject: Re: [Dime] WG Action: RECHARTER: Diameter Maintenance andExtensions(dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 05:58:35 -0000 On 1/26/2012 3:40 PM, Romascanu, Dan (Dan) wrote: ... > [[DR]] If the WG can reach consensus on the problem statement and > requirements in three months instead of eleven, we can add the work item > on the solution immediately. Let us just start doing this. Or not. Problem statement: RFC 2477, Section 4.2.6. Requirements: RFC 2989, Section 2.1. Both seem veritable models of concision & clarity to me; which part of the wheel do you want to re-invent first? > > Dan > > From dromasca@avaya.com Mon Jan 30 02:02:00 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E1E21F8669; Mon, 30 Jan 2012 02:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.38 X-Spam-Level: X-Spam-Status: No, score=-103.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 r5SVd2AcGumC; Mon, 30 Jan 2012 02:01:59 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 940C421F862B; Mon, 30 Jan 2012 02:01:59 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAI5pJk+HCzI1/2dsb2JhbABDoi6MKoEFgXIBAQEBAxIeCj8MBAIBCA0EBAEBAQoGDAsBBgEgJQkIAQEEEwgMBwelDpsTiDwqAwRKgnQJH4N5YwSbEoUNh00 X-IronPort-AV: E=Sophos;i="4.71,591,1320642000"; d="scan'208";a="327155998" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 30 Jan 2012 05:01:58 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 30 Jan 2012 04:48:07 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Jan 2012 11:01:50 +0100 Message-ID: In-Reply-To: <4F263182.6080709@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] WG Action: RECHARTER: Diameter Maintenance andExtensions(dime) Thread-Index: AczfFEEAXY80b0PQQUSofEATpOdFtQAH8hYQ References: <20120124171808.9C0F211E8076@ietfa.amsl.com><4F1FD5B1.6000309@gmail.com><556648C5-0C84-4E31-B162-E7D985BDFC1D@gmail.com> <4F20EFE5.4050005@gmail.com> <4F263182.6080709@gmail.com> From: "Romascanu, Dan (Dan)" To: "Glen Zorn" Cc: jouni.korhonen@nsn.com, lionel.morand@orange-ftgroup.com, dime@ietf.org, The IESG Subject: Re: [Dime] WG Action: RECHARTER: Diameter Maintenance andExtensions(dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 10:02:00 -0000 > -----Original Message----- > From: Glen Zorn [mailto:glenzorn@gmail.com] > Sent: Monday, January 30, 2012 7:58 AM > To: Romascanu, Dan (Dan) > Cc: jouni.korhonen@nsn.com; jouni korhonen; lionel.morand@orange- > ftgroup.com; dime@ietf.org; The IESG; Glen Zorn > Subject: Re: [Dime] WG Action: RECHARTER: Diameter Maintenance > andExtensions(dime) >=20 > On 1/26/2012 3:40 PM, Romascanu, Dan (Dan) wrote: > ... >=20 > > [[DR]] If the WG can reach consensus on the problem statement and > > requirements in three months instead of eleven, we can add the work > item > > on the solution immediately. Let us just start doing this. >=20 > Or not. Problem statement: RFC 2477, Section 4.2.6. Requirements: RFC > 2989, Section 2.1. Both seem veritable models of concision & clarity > to > me; which part of the wheel do you want to re-invent first? >=20 Hi Glen, It is not about what I want but about what the WG and the community gets consensus about. If understand you correctly, you believe that all requirements are already clearly defined and you proposed a solution that answers the requirements, the WG needs to confirm this. If the requirements in 2477 and 2989 apply and are sufficient it's fine to refer them. No wheels need to be re-invented if the existing ones still fit and turn.=20 Regards, Dan From stephen.farrell@cs.tcd.ie Sun Jan 29 10:44:38 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BBA21F8510; Sun, 29 Jan 2012 10:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.32 X-Spam-Level: X-Spam-Status: No, score=-103.32 tagged_above=-999 required=5 tests=[AWL=1.279, BAYES_00=-2.599, GB_I_INVITATION=-2, USER_IN_WHITELIST=-100] 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 1BuXxuwUFMbI; Sun, 29 Jan 2012 10:44:37 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id E782721F84FB; Sun, 29 Jan 2012 10:44:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id DEBC9153AD6; Sun, 29 Jan 2012 18:44:35 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1327862675; bh=Xj5Eb8xGlpqSyL JXhJKkda2i+mPWzeNOjJBiKSqGWWg=; b=KrpJ4+7/nEAq2NmBKxtXBmaXZnll1C qmi5Au1OMfzuM6sXRzEj5ZRluF8/aIahLrO2QcshZPiTZtr0s/+Pidc4IRhgAphg 9VZ3HcDEczLwRfIhoPOULp/zzV3B1bE3b8dSWFqFrO2+oBKcOAodyi9uiw0LmDJt bHOLmn+m6Hft4IaSpvZ0O2w94L0g8GRKCdRu2kxx18G0T72J2iQM9ORk+1M5t702 Fzoa++tUFc8EIJPcyiTIJwtayFDmxPIyqCXvybsubOx4HCNH4TjnOGVJk0wm3sYG TmZ3P9FZQSy81a/hUmcFqBv1AcAW37uuLlKhi5+VLXZZGvTHDtrTe3yA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id ieELRvfRHanH; Sun, 29 Jan 2012 18:44:35 +0000 (GMT) Received: from [10.87.48.8] (unknown [86.46.20.127]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 98B08171CDB; Sun, 29 Jan 2012 18:44:33 +0000 (GMT) Message-ID: <4F259390.2040507@cs.tcd.ie> Date: Sun, 29 Jan 2012 18:44:32 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: jouni korhonen References: <20120124171808.9C0F211E8076@ietfa.amsl.com><4F1FD5B1.6000309@gmail.com> <556648C5-0C84-4E31-B162-E7D985BDFC1D@gmail.com> <0AE3C899-9DFD-4398-B71A-301B76847CEC@gmail.com> <4F20EDAD.1030804@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 30 Jan 2012 23:50:26 -0800 Cc: jouni.korhonen@nsn.com, lionel.morand@orange-ftgroup.com, dime@ietf.org, The IESG Subject: Re: [Dime] WG Action: RECHARTER: Diameter Maintenance and Extensions(dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 18:44:38 -0000 On 01/26/2012 07:45 AM, jouni korhonen wrote: > Glen, > > On Jan 26, 2012, at 8:07 AM, Glen Zorn wrote: > >> On 1/25/2012 8:14 PM, jouni korhonen wrote: >> >> ... >> >>>> ... or the other way - the WG may actually beat the schedule, and get >>>> consensus earlier that the problem is well understood and on the >>>> requirements of the solution, while in parallel work is being done on >>>> the simple and relatively easy to implement solution hinted by Glen. The >>> >>> I do not quite buy this being something that can be accomplished hands >>> down.. otherwise it would have been done during these 10 years time. >> >> Seems like your next statement explains this one. >> >>> Also, >>> it is, at least to me personally, an indication that the lack of Diameter >>> specific e2e security has not been an issue in real life so far. >> >> If life in which networks are secured by claim alone is "real", then >> it's certainly not an issue (nor is the use of any security measures >> like TLS or IPsec). It must be wonderful to live in the land of magic, >> where do I get a ticket? Not that I'm complaining: I've made quite a > > ;-) > >> bit of money off of organizations that claimed to the outside world (and >> internally, as much as possible) that there networks were perfectly >> secure just because they said so... > > As you know, this has been the case for quite some time.. and maybe the > "so far" part is about the end now. Still I do not see too many requests > coming from the field to fix the situation. That gives us some time to > work on a solution, though. Not necessarily. There is a pattern where folks ignore known security problems for as long as possible, and then get caught by some incident. I don't know if that's the case here but I do suspect it might be. S > > - Jouni > > > >> >>> >>>> wording of the charter is cautious enough not to make presumptions about >>>> things going one way or the other, but does not preclude IMO any >>>> scenario, including the very optimistic one. >>> >>> Indeed. >>> >>> - Jouni >>> >>> >>>> >>>> Regards, >>>> >>>> Dan >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf >>>> Of >>>>> jouni korhonen >>>>> Sent: Wednesday, January 25, 2012 12:28 PM >>>>> To: Glen Zorn >>>>> Cc: jouni.korhonen@nsn.com; lionel.morand@orange-ftgroup.com; >>>>> dime@ietf.org; The IESG >>>>> Subject: Re: [Dime] WG Action: RECHARTER: Diameter Maintenance and >>>>> Extensions(dime) >>>>> >>>>> Glen, >>>>> >>>>> Appreciate your views here.. since you were around those days and >>>>> probably have good recollection why things did not get done. Few >>>>> points still. You should have come up with arguments while this >>>>> part of the charter was still under discussion on IETF list. Another >>>>> point is that the problem statement may well conclude there is no >>>>> problem to solve or the solution is not worth the hassle (taking >>>>> e.g. backward compatibility issues into account). >>>>> >>>>> - Jouni >>>>> >>>>> >>>>> On Jan 25, 2012, at 12:13 PM, Glen Zorn wrote: >>>>> >>>>>> On 1/25/2012 12:18 AM, IESG Secretary wrote: >>>>>> >>>>>> I must say that I'm not really happy with this: >>>>>> >>>>>>> Dec 2012 - Submit 'problem statement and requirements for Diameter >>>>>>> end-to-end security framework' to the IESG for >>>>>>> consideration as an Informational RFC. >>>>>> >>>>>> It seems like a invitation to the same rat hole we went down with >>>> the >>>>>> first attempt at e2e security. I assume the problem is well >>>>> understood >>>>>> since it's been talked to death over at least the last 10 years, >>>>> first >>>>>> in the context of RADIUS and later Diameter; why not cut to the >>>>> chase?. >>>>>> >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>> >>> >> >