From root@core3.amsl.com Mon Jan 4 00:15:02 2010 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0D9873A698E; Mon, 4 Jan 2010 00:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100104081502.0D9873A698E@core3.amsl.com> Date: Mon, 4 Jan 2010 00:15:02 -0800 (PST) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-extended-naptr-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 04 Jan 2010 08:15:02 -0000 --NextPart 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 Extended NAPTR Author(s) : M. Jones, J. Korhonen Filename : draft-ietf-dime-extended-naptr-00.txt Pages : 8 Date : 2009-12-28 This document describes an extended format for the NAPTR service fields used in dynamic Diameter agent discovery. The extended format allows NAPTR queries to contain Diameter Application-Id information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-extended-naptr-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-extended-naptr-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-04000506.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Wed Jan 6 00:15:01 2010 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 832CB3A6810; Wed, 6 Jan 2010 00:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100106081501.832CB3A6810@core3.amsl.com> Date: Wed, 6 Jan 2010 00:15:01 -0800 (PST) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-ikev2-psk-diameter-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 06 Jan 2010 08:15:01 -0000 --NextPart 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 IKEv2: Support for Interaction between IKEv2 Server and Diameter Server Author(s) : V. Cakulev, A. Lior Filename : draft-ietf-dime-ikev2-psk-diameter-00.txt Pages : 19 Date : 2010-01-04 Internet Key Exchange is a component of IPsec used for performing mutual authentication as well as establishing and maintaining security associations (SAs) between two parties such as a user and a network entity. Internet Key Exchange v2 (IKEv2) protocol allows several different mechanisms for authenticating a user, namely the Extensible Authentication Protocol, certificates, and pre-shared secrets. To authenticate and/or authorize the user, the network element such as the Access Gateway may need to dynamically bootstrap a security association based on interaction with the Diameter server. This document specifies the interaction between the Access Gateway and Diameter server for the IKEv2 based on pre-shared secrets. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 8, 2010.Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-ikev2-psk-diameter-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-ikev2-psk-diameter-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-06000920.I-D@ietf.org> --NextPart-- From sdecugis@nict.go.jp Wed Jan 6 23:14:48 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB03228C0E9 for ; Wed, 6 Jan 2010 23:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.844 X-Spam-Level: X-Spam-Status: No, score=0.844 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_SOMA2=2.199, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nbi4QbeSvZKz for ; Wed, 6 Jan 2010 23:14:47 -0800 (PST) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id 28BAA28C0E0 for ; Wed, 6 Jan 2010 23:14:46 -0800 (PST) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id o077Ehek022976 for ; Thu, 7 Jan 2010 16:14:43 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id o077EhXP010723 for ; Thu, 7 Jan 2010 16:14:43 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id o077EhV1010720 for ; Thu, 7 Jan 2010 16:14:43 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 899F816863 for ; Thu, 7 Jan 2010 16:14:43 +0900 (JST) Received: from [133.243.146.170] (5gou2f-dhcp10.nict.go.jp [133.243.146.170]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 848F116854 for ; Thu, 7 Jan 2010 16:14:43 +0900 (JST) Message-ID: <4B4589D6.1050100@nict.go.jp> Date: Thu, 07 Jan 2010 16:14:30 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: dime@ietf.org References: <3D3C75174CB95F42AD6BCC56E5555B4501FDFA1F@FIESEXC015.nsn-intra.net> <005201ca7e9c$8c94cb40$a5be61c0$@net> In-Reply-To: <005201ca7e9c$8c94cb40$a5be61c0$@net> X-Enigmail-Version: 1.0 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [Dime] Status of draft-ietf-dime-capablities-update? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 07 Jan 2010 07:14:49 -0000 Hi Hannes, Glen, and all, Sorry to reply only now. I actually don't see how the latest comments ([1], [2]) were addressed in the new version... Can someone clarify? Thank you, Best regards, Sebastien. [1] http://www.ietf.org/mail-archive/web/dime/current/msg03827.html [2] http://www.ietf.org/mail-archive/web/dime/current/msg03829.html Le 17/12/2009 07:10, Glen Zorn a écrit : > Tschofenig, Hannes (NSN - FI/Espoo) [mailto://hannes.tschofenig@nsn.com] > writes: > > >> Hi all, >> >> Glen has updated draft-ietf-dime-capablities-update as promised during >> the IETF meeting. >> Sebastien has provided some feedback on security aspects earlier. >> Sebastien, have you looked at the most recent draft version? >> >> Glen, could you post a status update? >> > Sorry, I don't track the status of drafts, preferring to leave that to WG > Chairs ;-). > > >> Are there open issues with the document? >> > Can't think of any, no. > > ... > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sdecugis@nict.go.jp Wed Jan 6 23:32:56 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF4563A6954 for ; Wed, 6 Jan 2010 23:32:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.39 X-Spam-Level: X-Spam-Status: No, score=0.39 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_00=-2.599, HELO_EQ_JP=1.244, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgM6s2m3hIVi for ; Wed, 6 Jan 2010 23:32:55 -0800 (PST) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id 023243A67F4 for ; Wed, 6 Jan 2010 23:32:54 -0800 (PST) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id o077WqEN028473 for ; Thu, 7 Jan 2010 16:32:52 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id o077WqWE023930 for ; Thu, 7 Jan 2010 16:32:52 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id o077WqK3023924 for ; Thu, 7 Jan 2010 16:32:52 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 2BEF01686D for ; Thu, 7 Jan 2010 16:32:52 +0900 (JST) Received: from [133.243.146.170] (5gou2f-dhcp10.nict.go.jp [133.243.146.170]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 2778616854 for ; Thu, 7 Jan 2010 16:32:52 +0900 (JST) Message-ID: <4B458E16.1080308@nict.go.jp> Date: Thu, 07 Jan 2010 16:32:38 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 CC: dime@ietf.org References: <01ce01ca7842$352c49b0$9f84dd10$@net> <4B1F0642.2090604@nict.go.jp> <02a301ca7881$73bf1f60$420ca40a@china.huawei.com> <4B1F2A20.9060407@nict.go.jp> <030901ca789b$bb071cf0$420ca40a@china.huawei.com> In-Reply-To: <030901ca789b$bb071cf0$420ca40a@china.huawei.com> X-Enigmail-Version: 1.0 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Dime] New version of draft-wu-dime-local-keytran X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 07 Jan 2010 07:32:56 -0000 Hi Qin, all, Sorry for the late reply. > [Qin]: According to draft-ietf-hokey-key-mgm-13, USRK and DSUSRK can be used in > Key Distribution Exchange Scenarios, that is to say EAP based key transportation is not limited for ERP > specific usage. Also I am not saying using of USRK and DSUSRK in the ERP scenario. I am wondering > whether USRK and DSUSRK transportation can be used for other non ERP specific cases like Key Distribution > Exchange Scenarios. > As far as I undertand : - The draft you cite defines a framework for (EAP-based) key distribution. It is to be used by any application that needs to transport a key. - USRK (resp DSUSRK) is a generic algorithm to derive some key material from the EMSK. It is merely a template, and applications are free to use it or not (by defining the "usage"). Therefore, in my understanding, there can be no instance of a "USRK", only application keys derived following the algorithm given by USRK (where the application specifies the parameters of the algorithm). My point was only that having "USRK" and "DSUSRK" in the enumerated field makes no sense at all. It will only confuse people who read the draft. Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From hannes.tschofenig@nsn.com Thu Jan 7 00:57:37 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E22B28C11F for ; Thu, 7 Jan 2010 00:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_SOMA2=2.199] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKlg1hl8iP7J for ; Thu, 7 Jan 2010 00:57:36 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id E4F923A6808 for ; Thu, 7 Jan 2010 00:57:35 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o078vW8U020825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 7 Jan 2010 09:57:32 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o078vUOC003807; Thu, 7 Jan 2010 09:57:32 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Jan 2010 09:57:32 +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, 7 Jan 2010 11:00:36 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B450208A2D4@FIESEXC015.nsn-intra.net> In-Reply-To: <4B4589D6.1050100@nict.go.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Status of draft-ietf-dime-capablities-update? Thread-Index: AcqPaR5EjQmLCH8qTFypO+jbAt4OGQADrhAA References: <3D3C75174CB95F42AD6BCC56E5555B4501FDFA1F@FIESEXC015.nsn-intra.net><005201ca7e9c$8c94cb40$a5be61c0$@net> <4B4589D6.1050100@nict.go.jp> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Sebastien Decugis" , X-OriginalArrivalTime: 07 Jan 2010 08:57:32.0150 (UTC) FILETIME=[72B00960:01CA8F77] Subject: Re: [Dime] Status of draft-ietf-dime-capablities-update? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 07 Jan 2010 08:57:37 -0000 Glen will explain how these comments have been incorporated.=20 >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On=20 >Behalf Of ext Sebastien Decugis >Sent: 07 January, 2010 09:15 >To: dime@ietf.org >Subject: Re: [Dime] Status of draft-ietf-dime-capablities-update? > >Hi Hannes, Glen, and all, > >Sorry to reply only now. I actually don't see how the latest=20 >comments ([1], [2]) were addressed in the new version... Can=20 >someone clarify? > >Thank you, >Best regards, >Sebastien. >[1] http://www.ietf.org/mail-archive/web/dime/current/msg03827.html >[2] http://www.ietf.org/mail-archive/web/dime/current/msg03829.html > > >Le 17/12/2009 07:10, Glen Zorn a =E9crit : >> Tschofenig, Hannes (NSN - FI/Espoo)=20 >> [mailto://hannes.tschofenig@nsn.com] >> writes: >> >> =20 >>> Hi all, >>> >>> Glen has updated draft-ietf-dime-capablities-update as promised=20 >>> during the IETF meeting. >>> Sebastien has provided some feedback on security aspects earlier. >>> Sebastien, have you looked at the most recent draft version? >>> >>> Glen, could you post a status update?=20 >>> =20 >> Sorry, I don't track the status of drafts, preferring to=20 >leave that to=20 >> WG Chairs ;-). >> >> =20 >>> Are there open issues with the document? >>> =20 >> Can't think of any, no. >> >> ... >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> >> =20 > >-- >Sebastien Decugis >Research fellow >Network Architecture Group >NICT (nict.go.jp) > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime > From gwz@net-zen.net Thu Jan 7 02:30:51 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 426F33A6833 for ; Thu, 7 Jan 2010 02:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_SOMA2=2.199] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRF5S2ZeszTy for ; Thu, 7 Jan 2010 02:30:50 -0800 (PST) Received: from smtpout05.prod.mesa1.secureserver.net (smtpout05-01.prod.mesa1.secureserver.net [64.202.165.218]) by core3.amsl.com (Postfix) with SMTP id 2713C3A67DF for ; Thu, 7 Jan 2010 02:30:50 -0800 (PST) Received: (qmail 16690 invoked from network); 7 Jan 2010 10:30:47 -0000 Received: from unknown (124.121.211.99) by smtpout05.prod.mesa1.secureserver.net (64.202.165.218) with ESMTP; 07 Jan 2010 10:30:46 -0000 From: "Glen Zorn" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ext Sebastien Decugis'" References: <3D3C75174CB95F42AD6BCC56E5555B4501FDFA1F@FIESEXC015.nsn-intra.net><005201ca7e9c$8c94cb40$a5be61c0$@net> <4B4589D6.1050100@nict.go.jp> <3D3C75174CB95F42AD6BCC56E5555B450208A2D4@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B450208A2D4@FIESEXC015.nsn-intra.net> Date: Thu, 7 Jan 2010 17:30:41 +0700 Organization: Network Zen Message-ID: <044e01ca8f84$7850b290$68f217b0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqPaR5EjQmLCH8qTFypO+jbAt4OGQADrhAAAAD4edA= Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Status of draft-ietf-dime-capablities-update? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 07 Jan 2010 10:30:51 -0000 Tschofenig, Hannes (NSN - FI/Espoo) [mailto://hannes.tschofenig@nsn.com] writes: > Glen will explain how these comments have been incorporated. They haven't been. I cannot understand how [1] makes any sense (how can = you change the IP address on a running IPsec SA and have it continue to = run?). [2] says =93Now if during operation the Diameter server "retracts" one = of its applications the draft says that the client should disconnect the = transport layer connections. Unfortunately from the point of view of the = application it is not clear what to do because such a behavior was not anticipated before the capabilities-update app.=94 However, neither of these = statements is accurate, AFAICT. The draft says that the transport connection = should be disconnected if two peers no longer share _any_ applications in common, = not if _one_ application disappears; furthermore, IIRC, Diameter was = designed precisely with the possibility that servers could disappear without = warning in mind. If an application can=92t handle that, there seems to me to be = a much bigger problem with the implementation. I have no problem = modifying the draft in conformance with WG consensus, but these comments make no = sense to me so I=92m not willing to make any changes unilaterally. . If they = make sense to the chairs, then they can instruct me to modify the text as = they see fit. >=20 > >-----Original Message----- > >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > >Behalf Of ext Sebastien Decugis > >Sent: 07 January, 2010 09:15 > >To: dime@ietf.org > >Subject: Re: [Dime] Status of draft-ietf-dime-capablities-update? > > > >Hi Hannes, Glen, and all, > > > >Sorry to reply only now. I actually don't see how the latest > >comments ([1], [2]) were addressed in the new version... Can > >someone clarify? > > > >Thank you, > >Best regards, > >Sebastien. > >[1] http://www.ietf.org/mail-archive/web/dime/current/msg03827.html > >[2] http://www.ietf.org/mail-archive/web/dime/current/msg03829.html > > > > > >Le 17/12/2009 07:10, Glen Zorn a =E9crit : > >> Tschofenig, Hannes (NSN - FI/Espoo) > >> [mailto://hannes.tschofenig@nsn.com] > >> writes: > >> > >> > >>> Hi all, > >>> > >>> Glen has updated draft-ietf-dime-capablities-update as promised > >>> during the IETF meeting. > >>> Sebastien has provided some feedback on security aspects earlier. > >>> Sebastien, have you looked at the most recent draft version? > >>> > >>> Glen, could you post a status update? > >>> > >> Sorry, I don't track the status of drafts, preferring to > >leave that to > >> WG Chairs ;-). > >> > >> > >>> Are there open issues with the document? > >>> > >> Can't think of any, no. > >> > >> ... > >> > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www.ietf.org/mailman/listinfo/dime > >> > >> > > > >-- > >Sebastien Decugis > >Research fellow > >Network Architecture Group > >NICT (nict.go.jp) > > > >_______________________________________________ > >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 sdecugis@nict.go.jp Thu Jan 7 02:53:38 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 095D33A684E for ; Thu, 7 Jan 2010 02:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.263 X-Spam-Level: * X-Spam-Status: No, score=1.263 tagged_above=-999 required=5 tests=[AWL=-0.873, BAYES_00=-2.599, FRT_SOMA2=2.199, HELO_EQ_JP=1.244, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBgh3FY6Kg-h for ; Thu, 7 Jan 2010 02:53:37 -0800 (PST) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id 8198F3A67B2 for ; Thu, 7 Jan 2010 02:53:36 -0800 (PST) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id o07ArX15005582 for ; Thu, 7 Jan 2010 19:53:33 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id o07ArXe3021824 for ; Thu, 7 Jan 2010 19:53:33 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id o07ArXg2021821 for ; Thu, 7 Jan 2010 19:53:33 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id B0D3816945 for ; Thu, 7 Jan 2010 19:53:33 +0900 (JST) Received: from [133.243.146.170] (5gou2f-dhcp10.nict.go.jp [133.243.146.170]) by mail2.nict.go.jp (NICT Mail) with ESMTP id AB873168C2 for ; Thu, 7 Jan 2010 19:53:33 +0900 (JST) Message-ID: <4B45BD1E.5010402@nict.go.jp> Date: Thu, 07 Jan 2010 19:53:18 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 CC: dime@ietf.org References: <3D3C75174CB95F42AD6BCC56E5555B4501FDFA1F@FIESEXC015.nsn-intra.net><005201ca7e9c$8c94cb40$a5be61c0$@net> <4B4589D6.1050100@nict.go.jp> <3D3C75174CB95F42AD6BCC56E5555B450208A2D4@FIESEXC015.nsn-intra.net> <044e01ca8f84$7850b290$68f217b0$@net> In-Reply-To: <044e01ca8f84$7850b290$68f217b0$@net> X-Enigmail-Version: 1.0 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [Dime] [SPAM] RE: Status of draft-ietf-dime-capablities-update? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 07 Jan 2010 10:53:38 -0000 Hi, Le 07/01/2010 19:30, Glen Zorn a écrit : > I cannot understand how [1] makes any sense (how can you > change the IP address on a running IPsec SA and have it continue to run?). > [1] also talks about the concerns with changing the Diameter Id (i.e. content of the Origin-Host or Origin-Realm) in the CUR/CUA. I don't see where it is explained in the new revision. Please point me to the appropriate text if I am missing it. (Not related to the discussion, but it is perfectly possible to change the IP endpoints of a running SA... It is even mandatory in case of mobile IPv6 for example...) Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From rfc-editor@rfc-editor.org Thu Jan 7 16:55:56 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E792028C1A3; Thu, 7 Jan 2010 16:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.19 X-Spam-Level: X-Spam-Status: No, score=-17.19 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkOZ8I4L0Mlo; Thu, 7 Jan 2010 16:55:56 -0800 (PST) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 81E5828C19E; Thu, 7 Jan 2010 16:55:51 -0800 (PST) Received: by bosco.isi.edu (Postfix, from userid 70) id 18DCC39B49C; Thu, 7 Jan 2010 16:53:27 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20100108005327.18DCC39B49C@bosco.isi.edu> Date: Thu, 7 Jan 2010 16:53:27 -0800 (PST) Cc: dime@ietf.org, rfc-editor@rfc-editor.org Subject: [Dime] RFC 5719 on Updated IANA Considerations for Diameter Command Code Allocations X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 08 Jan 2010 00:55:57 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5719 Title: Updated IANA Considerations for Diameter Command Code Allocations Author: D. Romascanu, H. Tschofenig Status: Standards Track Date: January 2010 Mailbox: dromasca@avaya.com, Hannes.Tschofenig@gmx.net Pages: 5 Characters: 11268 Updates: RFC3588 I-D Tag: draft-ietf-dime-diameter-cmd-iana-01.txt URL: http://www.rfc-editor.org/rfc/rfc5719.txt The Diameter base specification, described in RFC 3588, provides a number of ways to extend Diameter, with new Diameter commands (i.e., messages used by Diameter applications) and applications as the most extensive enhancements. RFC 3588 illustrates the conditions that lead to the need to define a new Diameter application or a new command code. Depending on the scope of the Diameter extension, IETF actions are necessary. Although defining new Diameter applications does not require IETF consensus, defining new Diameter commands requires IETF consensus per RFC 3588. This has led to questionable design decisions by other Standards Development Organizations, which chose to define new applications on existing commands -- rather than asking for assignment of new command codes -- for the pure purpose of avoiding bringing their specifications to the IETF. In some cases, interoperability problems were an effect of the poor design caused by overloading existing commands. This document aligns the extensibility rules of the Diameter application with the Diameter commands, offering ways to delegate work on Diameter to other SDOs to extend Diameter in a way that does not lead to poor design choices. [STANDARDS TRACK] This document is a product of the Diameter Maintanence and Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From sunseawq@huawei.com Thu Jan 7 18:23:20 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 563E83A681A for ; Thu, 7 Jan 2010 18:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dc5S2sHIXf7N for ; Thu, 7 Jan 2010 18:23:19 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 274583A67E3 for ; Thu, 7 Jan 2010 18:23:19 -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 <0KVW00DTCPAIJ2@szxga03-in.huawei.com> for dime@ietf.org; Fri, 08 Jan 2010 10:23:07 +0800 (CST) Received: from 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 <0KVW00K26PAIAR@szxga03-in.huawei.com> for dime@ietf.org; Fri, 08 Jan 2010 10:23:06 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KVW00KFBPAHLT@szxml04-in.huawei.com> for dime@ietf.org; Fri, 08 Jan 2010 10:23:05 +0800 (CST) Date: Fri, 08 Jan 2010 10:23:05 +0800 From: Qin Wu To: Sebastien Decugis Message-id: <00a501ca9009$82fc7910$260ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <01ce01ca7842$352c49b0$9f84dd10$@net> <4B1F0642.2090604@nict.go.jp> <02a301ca7881$73bf1f60$420ca40a@china.huawei.com> <4B1F2A20.9060407@nict.go.jp> <030901ca789b$bb071cf0$420ca40a@china.huawei.com> <4B458E16.1080308@nict.go.jp> Cc: dime@ietf.org Subject: Re: [Dime] New version of draft-wu-dime-local-keytran X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 08 Jan 2010 02:23:20 -0000 Hi, In my understanding, In ERP specific case, rRK is directly derived from USRK and DS-rRK is directly derived from DSUSRK. wherein USRK is one instance of EMSK and DSUSRK is one instance of DSRK. In Non-ERP specific case, I would like to refer to scenario 1 and scenario 3 described in section 4.2 of draft-ietf-hokey-key-mgm-13 as follows: Scenario 1: EAP/AAA server to USR-KH: In this scenario, the EAP/AAA server delivers a USRK to a USR-KH. Scenario 3: DSR-KH to DSUSR-KH: In this scenario, a DSR-KH in a specific domain delivers keying material DSUSRK to a DSUSR-KH in the same domain. In both scenarios mentioned above, the USRK or DSUSRK should firstly be delivered to DSR-KH and DSUSR-KH respectively. Do this clarify? Regards! -Qin ----- Original Message ----- From: "Sebastien Decugis" Cc: Sent: Thursday, January 07, 2010 3:32 PM Subject: Re: [Dime] New version of draft-wu-dime-local-keytran > Hi Qin, all, > > Sorry for the late reply. > >> [Qin]: According to draft-ietf-hokey-key-mgm-13, USRK and DSUSRK can be used in >> Key Distribution Exchange Scenarios, that is to say EAP based key transportation is not limited for ERP >> specific usage. Also I am not saying using of USRK and DSUSRK in the ERP scenario. I am wondering >> whether USRK and DSUSRK transportation can be used for other non ERP specific cases like Key Distribution >> Exchange Scenarios. >> > > As far as I undertand : > - The draft you cite defines a framework for (EAP-based) key > distribution. It is to be used by any application that needs to > transport a key. > - USRK (resp DSUSRK) is a generic algorithm to derive some key material > from the EMSK. It is merely a template, and applications are free to use > it or not (by defining the "usage"). > > Therefore, in my understanding, there can be no instance of a "USRK", > only application keys derived following the algorithm given by USRK > (where the application specifies the parameters of the algorithm). > > My point was only that having "USRK" and "DSUSRK" in the enumerated > field makes no sense at all. It will only confuse people who read the draft. > > Best regards, > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From root@core3.amsl.com Fri Jan 8 11:15:08 2010 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 301323A6886; Fri, 8 Jan 2010 11:15:06 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100108191507.301323A6886@core3.amsl.com> Date: Fri, 8 Jan 2010 11:15:06 -0800 (PST) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-local-keytran-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 08 Jan 2010 19:15:08 -0000 --NextPart 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 Attribute-Value Pairs for Cryptographic Key Transport Author(s) : W. Wu, G. Zorn Filename : draft-ietf-dime-local-keytran-00.txt Pages : 8 Date : 2010-01-07 Some Authentication, Authorization, and Accounting (AAA) applications require the transport of cryptographic keying material; this document specifies a set of Attribute-Value Pairs (AVPs) providing native Diameter support of cryptographic key delivery. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 12, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-local-keytran-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-local-keytran-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-08110512.I-D@ietf.org> --NextPart-- From moise@ulticom.com Fri Jan 8 12:46:58 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6236F3A6835 for ; Fri, 8 Jan 2010 12:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_SOMA2=2.199] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIUsHv7kYQwt for ; Fri, 8 Jan 2010 12:46:57 -0800 (PST) Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.38]) by core3.amsl.com (Postfix) with ESMTP id 62EF73A67C0 for ; Fri, 8 Jan 2010 12:46:57 -0800 (PST) Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 96367AA78F for ; Fri, 8 Jan 2010 15:46:55 -0500 (EST) Received: from MTLEXVS01.ulticom.com (mtlex01.ulticom.com [172.16.40.5]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id o08KkseT004810 for ; Fri, 8 Jan 2010 15:46:54 -0500 (EST) 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: Fri, 8 Jan 2010 15:46:54 -0500 Message-ID: In-Reply-To: <4B45BD1E.5010402@nict.go.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Status of draft-ietf-dime-capabilities-update? Thread-Index: AcqPh7IXp0CHLb8pSdeGnjRTjj/KLQBFJKnw References: <3D3C75174CB95F42AD6BCC56E5555B4501FDFA1F@FIESEXC015.nsn-intra.net><005201ca7e9c$8c94cb40$a5be61c0$@net> <4B4589D6.1050100@nict.go.jp><3D3C75174CB95F42AD6BCC56E5555B450208A2D4@FIESEXC015.nsn-intra.net><044e01ca8f84$7850b290$68f217b0$@net> <4B45BD1E.5010402@nict.go.jp> From: "Andrea Moise" To: Received-SPF: none Subject: Re: [Dime] Status of draft-ietf-dime-capabilities-update? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 08 Jan 2010 20:46:58 -0000 Hi Glen, Sebastien, and all, I have been a silent reader of dime mailing list for a long time and = would like to mingle on the discussion about = http://tools.ietf.org/html/draft-ietf-dime-capablities-update-01.=20 It would be interesting to know exactly what capabilities can be = modified by a CUR message. The document says: "This message allows the update of a peer's capabilities (protocol = version number, supported Diameter applications, etc.)." Yet, the only update that is described in detail mentions application = id. Is an update of protocol version number really in the scope of the = document? If protocol version number is the "version" field in the = message header, it seems unlikely to me that an application can support = a new protocol version without restarting connections. Also, the previous draft mentioned an update of peer identity. The = statement was removed. Does this mean that a CUR message does NOT allow = updating the Origin-Host, Origin-Realm AVP, and Host-IP-Address? =3D=3D> What do you think about listing AVPs whose content MUST/MAY/MUST = NOT be analyzed by the application to see what has changed? This would = help applications know that to do in order to support Diameter = Capabilities Updates. Best regards, Andrea -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of = Sebastien Decugis Sent: Thursday, January 07, 2010 5:53 AM Cc: dime@ietf.org Subject: Re: [Dime] [SPAM] RE: Status of = draft-ietf-dime-capablities-update? Hi, Le 07/01/2010 19:30, Glen Zorn a =E9crit : > I cannot understand how [1] makes any sense (how can you > change the IP address on a running IPsec SA and have it continue to = run?). > =20 [1] also talks about the concerns with changing the Diameter Id (i.e. content of the Origin-Host or Origin-Realm) in the CUR/CUA. I don't see where it is explained in the new revision. Please point me to the appropriate text if I am missing it. (Not related to the discussion, but it is perfectly possible to change the IP endpoints of a running SA... It is even mandatory in case of mobile IPv6 for example...) Best regards, Sebastien. --=20 Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From gwz@net-zen.net Sat Jan 9 20:22:54 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F32DC3A659C for ; Sat, 9 Jan 2010 20:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3WpMKXFkEiu for ; Sat, 9 Jan 2010 20:22:52 -0800 (PST) Received: from p3plsmtpa01-03.prod.phx3.secureserver.net (p3plsmtpa01-03.prod.phx3.secureserver.net [72.167.82.83]) by core3.amsl.com (Postfix) with SMTP id 5AD6E3A6407 for ; Sat, 9 Jan 2010 20:22:52 -0800 (PST) Received: (qmail 20160 invoked from network); 10 Jan 2010 04:22:48 -0000 Received: from unknown (124.120.228.231) by p3plsmtpa01-03.prod.phx3.secureserver.net (72.167.82.83) with ESMTP; 10 Jan 2010 04:22:47 -0000 From: "Glen Zorn" To: "'Andrea Moise'" References: <3D3C75174CB95F42AD6BCC56E5555B4501FDFA1F@FIESEXC015.nsn-intra.net><005201ca7e9c$8c94cb40$a5be61c0$@net> <4B4589D6.1050100@nict.go.jp><3D3C75174CB95F42AD6BCC56E5555B450208A2D4@FIESEXC015.nsn-intra.net><044e01ca8f84$7850b290$68f217b0$@net> <4B45BD1E.5010402@nict.go.jp> In-Reply-To: Date: Sun, 10 Jan 2010 11:22:29 +0700 Organization: Network Zen Message-ID: <000001ca91ac$88422880$98c67980$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqPh7IXp0CHLb8pSdeGnjRTjj/KLQBFJKnwAEMY1SA= Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Status of draft-ietf-dime-capabilities-update? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 10 Jan 2010 04:22:54 -0000 Andrea Moise [mailto://moise@ulticom.com] writes: > Hi Glen, Sebastien, and all, > > I have been a silent reader of dime mailing list for a long time and > would like to mingle on the discussion about > http://tools.ietf.org/html/draft-ietf-dime-capablities-update-01. > > It would be interesting to know exactly what capabilities can be > modified by a CUR message. The document says: > > "This message allows the update of a peer's capabilities (protocol > version number, supported Diameter applications, etc.)." > > Yet, the only update that is described in detail mentions application > id. Is an update of protocol version number really in the scope of the > document? If protocol version number is the "version" field in the > message header, it seems unlikely to me that an application can support > a new protocol version without restarting connections. True; that should probably be removed. > > Also, the previous draft mentioned an update of peer identity. The > statement was removed. Does this mean that a CUR message does NOT allow > updating the Origin-Host, Origin-Realm AVP, and Host-IP-Address? Yes, though, it might be useful to be able to advertise changes in IP address if SCTP is used as the transport. > > ==> What do you think about listing AVPs whose content MUST/MAY/MUST NOT > be analyzed by the application to see what has changed? This would help > applications know that to do in order to support Diameter Capabilities > Updates. I think that the problem is that the set of AVPs is malleable: it can change over time, so making this kind of list seems problematic. ... From hannes.tschofenig@nsn.com Mon Jan 11 05:21:25 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE4B93A69FD for ; Mon, 11 Jan 2010 05:21:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RdnkMxRmPsT for ; Mon, 11 Jan 2010 05:21:24 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 6EABB3A6930 for ; Mon, 11 Jan 2010 05:21:23 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o0BDLJBA007137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 11 Jan 2010 14:21:19 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o0BDLIHX032766 for ; Mon, 11 Jan 2010 14:21:18 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Jan 2010 14:21:18 +0100 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, 11 Jan 2010 15:25:13 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45020B8289@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Quick look at draft-ietf-dime-local-keytran-00.txt Thread-Index: AcqSwYGwXq8uKAvPTV2ZOoQkSOPjGA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 11 Jan 2010 13:21:18.0828 (UTC) FILETIME=[F5C672C0:01CA92C0] Subject: [Dime] Quick look at draft-ietf-dime-local-keytran-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 11 Jan 2010 13:21:25 -0000 Hi Glen,=20 I thought I should take a look at the document to see where we are.=20 I have a few comments: 1) I don't think you need to introduce so many terms in the terminology section but rather expand their first occurrence in the intro section.=20 Example: " The Diameter EAP application [RFC4072] defines the EAP-Master- Session-Key and EAP-Key-Name AVPs for the purpose of transporting cryptographic keying material derived during the execution of certain EAP [RFC3748] methods (for example, EAP-TLS [RFC5216]). At most one instance of either of these AVPs is allowed in any Diameter message. However, recent work [RFC5295] has specified methods to derive other keys from the keying material created during EAP method execution that may require transport in addition to the MSK. In addition, ERP [RFC5296] specifies new keys that may need to be transported between Diameter nodes. This note specifies a set of AVPs allowing the transport of multiple cryptographic keys in a single Diameter message. " I would just expend the terms "ERP", "MSK", and "EAP" in this section and avoid listing them in the terminology section. Also other terms do not appear too often in the document other than in Section 3.1.1.=20 Example: rRK=20 Just a matter of style -- not terribly important.=20 2) I think you only define some AVPs and hence you don't need to say anything about the usage of these AVPs in certain Diameter messages.=20 Example: I would remove the following sentence from Section 3.1.1:=20 " The Key-Type AVP MAY be included in a DER command as a signal that a certain type of key is required in the response (e.g., to support ERP).=20 " 3) Key-Lifetime You made a note that I did not quite understand: " NOTE: Applications using this value SHOULD consider the beginning of the lifetime to be the point in time when the keying material is first used. " What is the reasoning behind this statement? Wouldn't you leave such decisions to the specific document that describes how these AVPs are used?=20 4) I believe that the AVP occurrence table is not useful for this document. I suggest to delete it.=20 You would want to put one in a document describing how these AVPs are, for example, used with ERP.=20 5) Security Considerations Even though the security considerations are not dramatically different to Diameter EAP I would suggest to discuss the topics. I suggest to copy text.=20 6) Section 6.2 - IANA Registry for AVP values The text is a bit incomplete as you might want to tell IANA that you want to create a new registry here. You have indicated the policy for adding new values but you might want to also state whether you allow values from the registry to be deleted, replaced, modified or depicated. Do you think that FCFS is a good policy here? Everyone can come along and put some really bogus stuff into this registry. Would Expert Review be too much here?=20 Otherwise I have no other comments and I believe we should start a WGLC very soon.=20 Ciao Hannes From hannes.tschofenig@nsn.com Mon Jan 11 06:55:15 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7476228C116 for ; Mon, 11 Jan 2010 06:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.324 X-Spam-Level: X-Spam-Status: No, score=-2.324 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0h+OfJewB-u6 for ; Mon, 11 Jan 2010 06:55:14 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 1EBDC3A6805 for ; Mon, 11 Jan 2010 06:55:13 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o0BEt8xE009587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 11 Jan 2010 15:55:09 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o0BEt4kX018859 for ; Mon, 11 Jan 2010 15:55:07 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Jan 2010 15:54:50 +0100 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, 11 Jan 2010 16:58:45 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45020DF0CB@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Quick look at draft-ietf-dime-nat-control-01.txt Thread-Index: AcqSzpLNY+gIIulVRWyinLW1Mxwr7A== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 11 Jan 2010 14:54:50.0773 (UTC) FILETIME=[06C14C50:01CA92CE] Subject: [Dime] Quick look at draft-ietf-dime-nat-control-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 11 Jan 2010 14:55:15 -0000 Hi Frank, et al.,=20 I had a brief look at your document and I noticed two things:=20 A) The document is a bit long with a lot of duplication in there. I suggest to shorten it to make it easier to read. I have a proposals for the first few sections and you can find them below.=20 B) Section 4.1 says that the "pull mode" will be provided in a future version of the document. So, when are you going to add the description?=20 Ciao Hannes ----------- -- Document heading: Diameter NAT Control Application --> Expand the term "NAT" and call it Diameter Network Address and Port Translation (NAPT) Application You describe more than just a NAT control application but rather a the NAPT functionality. Hence the change in title. Other suggestions are welcome! -- Change Victor's mail address to vf0213@gmail.com and ask him for updated information about his affiliation.=20 -- Abstract=20 FROM: Abstract This document describes the framework, messages, and procedures for the Diameter NAT Control Application (DNCA), allowing for per- endpoint control of large scale NAT devices, which are put in place to cope with IPv4-address space completion. The Diameter NAT Control Application allows external devices to configure and manage a Large Scale NAT (LSN) device - expanding the existing Diameter-based AAA and policy control capabilities with a NAT control component. These external devices can be network elements in the data plane such as a Network Access Server (NAS), or can be more centralized control plane devices such as AAA-servers. DNCA establishes a context to commonly identify and manage endpoints on a gateway or server, and a large scale NAT device. This includes, for example, the control of the total number of NAT-bindings allowed or the allocation of a specific NAT-binding for a particular endpoint. In addition, it allows large scale NAT devices to provide information relevant to accounting purposes. Do you think that the reference to "large scale NAT devices" is useful given that these types of NATs have been deployed already before the term was coined. Cannot we just call them NATs? Is the term Large Scale NAT (LSN) the "official" term used in the BEHAVE working group?=20 --- Introduction Avoid mentioning the term "National Regulatory Authority (NRA)" anywhere in draft.=20 Terminology: Typically, we just call the two parties of a Diameter application client and server. You use the term manager and agent. Any reason for the terminology?=20 I personally would combine parts of Section 1 with Section 3. Then, Section 3.2 "LSN Control Deployment Framework" would become a separate "Framework" section.=20 Here is my text proposal: -------- 1. Introduction Internet service providers have started to deploy Network Address Translators (NATs)=20 and Network Address and Port Translators (NAPTs) at the edge of their networks=20 (in addition to NAT boxes typically being deployed at customer premises) to deal=20 with the foreseeable depletion of available IPv4 addresses.=20 This document defines a Diameter application for providers=20 deploying such NATs and NAPT devices. The use of a Diameter application=20 allows for simple integration into the existing AAA environment of=20 a provider. The Diameter NAPT application offers the following capabilities:=20 =20 1. Limit the number of NAT-bindings made available to an individual=20 subscriber or end point.=20 =20 2. Support the allocation of specific NAT-bindings. This approach is useful for provider-controlled services.=20 =20 3. Define the external address-pool(s) to be used for allocating an external IP-address. External address-pools can either be pre- assigned at the NAT, or specified within a request. If pre- assigned address-pools are used, a request needs to include a reference to identify the pool. Otherwise, the request will=20 contain a description of the IP- address pool(s) to be used (e.g. list of IP-subnets). 4. Accounting/Reporting: Report established bindings for a particular user. The collected information is used by accounting=20 systems and for statistical purposes.=20 5. Query functionality to retrieve details about bindings on demand. This feature complements the previously mentioned push-functionality mentioned under item (4).=20 This document is structured as follows: Section 2 lists terminology, Section=20 3 provides a description of deployment options as part of the overall framework,=20 ....=20 2. Terminology 3. Framework -------- A few editorial things:=20 s/DIAMETER/Diameter=20 All subject headings are written with capitals. Example:=20 s/5.2. Accounting functionality/5.2. Accounting Functionality From dromasca@avaya.com Thu Jan 14 08:15:43 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50B923A681D for ; Thu, 14 Jan 2010 08:15:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AzkcGLqtzy5 for ; Thu, 14 Jan 2010 08:15:42 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 7DC993A67B7 for ; Thu, 14 Jan 2010 08:15:41 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,275,1262581200"; d="scan'208";a="172162442" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 14 Jan 2010 11:15:36 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 14 Jan 2010 11:15:24 -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, 14 Jan 2010 17:15:19 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WRONG allocations for DIME MIB modules Thread-Index: AcqVNMQD5s9Ykli7QDiva0RIwCdGQw== From: "Romascanu, Dan (Dan)" To: Subject: [Dime] WRONG allocations for DIME MIB modules X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 14 Jan 2010 16:15:43 -0000 While performing the AD reviews for the two MIB documents I fell upon the fact that the two MIB modules use the same root {mib-2 119} This is probably done in order to pass compilation, but without any explanation it can misguide early implementers.=20 This is wrong for at least three reasons:=20 1. RFC 4181 recommends that allocation of the OIDs for the MIB module be made only by IANA after the document is approved.=20 2. {mib-2 119} is already allocated and used by another IETF standard MIB. If the authors wanted to use the experimental tree the OID should have been {experimental 119} 3. Both diameterBaseProtocolMIB and diameterCCAMIB use the same OID If anybody plans to implement the MIB modules prior to I-D publication they MUST NOT use the OIDs in the current document. This is the principal reason for which I am sending this warning prior to the full AD review.=20 I strongly recommend to follow the recommendations in RFC 4181 section 3.5.2 - like:=20 diameterBaseProtocolMIB { mib-2 XXX } Editor's Note (to be removed prior to publication): the IANA is requested to assign a value for "XXX" under the 'mib-2' subtree and to record the assignment in the SMI Numbers registry. When the assignment has been made, the RFC Editor is asked to replace "XXX" (here and in the MIB module) with the assigned value and to remove this note. The IANA Considerations sections must include the requests to allocate two - different - values for the two MIB modules.=20 Thanks and Regards, Dan From hannes.tschofenig@nsn.com Thu Jan 14 14:11:33 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62B4D3A6840 for ; Thu, 14 Jan 2010 14:11:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Y4X7FFI2k3b for ; Thu, 14 Jan 2010 14:11:31 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 3CD0C3A6828 for ; Thu, 14 Jan 2010 14:11:27 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o0EMBMr3015989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 14 Jan 2010 23:11:22 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o0EMBMXR006905 for ; Thu, 14 Jan 2010 23:11:22 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 23:11:22 +0100 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_01CA9566.810FCB46" Date: Fri, 15 Jan 2010 00:15:09 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B450210C0BB@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Quick look at draft-ietf-dime-ikev2-psk-diameter-00.txt Thread-Index: AcqUdmFKOAfqDestS2GOefFpSpYJMg== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 14 Jan 2010 22:11:22.0654 (UTC) FILETIME=[81926BE0:01CA9566] Subject: [Dime] Quick look at draft-ietf-dime-ikev2-psk-diameter-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 14 Jan 2010 22:11:33 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA9566.810FCB46 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Avi,=20 I have three comments at this point in time: 1) Editorial=20 There is some room for improvement on the editorial side. An example:=20 FROM: Abstract Internet Key Exchange is a component of IPsec used for performing mutual authentication as well as establishing and maintaining security associations (SAs) between two parties such as a user and a network entity. Internet Key Exchange v2 (IKEv2) protocol allows several different mechanisms for authenticating a user, namely the Extensible Authentication Protocol, certificates, and pre-shared secrets. To authenticate and/or authorize the user, the network element such as the Access Gateway may need to dynamically bootstrap a security association based on interaction with the Diameter server. This document specifies the interaction between the Access Gateway and Diameter server for the IKEv2 based on pre-shared secrets. TO: " Abstract The Internet Key Exchange protocol version 2 (IKEv2) is a component of=20 the IPsec architecture and used to perform mutual authentication as well=20 as to establish and to maintain IPsec security associations (SAs) between=20 the respective parties. IKEv2 supports several different authentication=20 mechanisms, such as the Extensible Authentication Protocol (EAP),=20 certificates, and pre-shared secrets.=20 With TBD-RFC the Diameter interworking for Mobile IPv6 between the Home=20 Agent, as a Diameter client, and the Diameter server has been specified.=20 However, that specification focused on the usage of EAP and did not=20 include support for pre-shared secret based authentication available=20 with IKEv2. This document therefore extends the functionality offered by TBD-RFC with pre-shared key based authentication offered by IKEv2=20 when no EAP is used. " 2) Reuse of draft-ietf-dime-local-keytran-00.txt Instead of defining your own key related AVP wouldn't it make sense to reuse what has been defined in http://www.ietf.org/id/draft-ietf-dime-local-keytran-00.txt ?=20 3) Security The security in the document is a bit fuzzy to me. I believe what you are saying is essentially that the pre-shared key isn't really the user's long-term shared key but rather something that has been dynamically established (and thus short lived) based on a previous network access authentication run (or something like that). Is my understanding correct? In any case, I believe it would be helpful to go through the Housley criteria as a guide for the text that one might want to find in the security consideration sections of such a document. This helps to point out some security threats in a more structured fashion. Does this make sense to you?=20 Ciao Hannes ------_=_NextPart_001_01CA9566.810FCB46 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Quick look at draft-ietf-dime-ikev2-psk-diameter-00.txt

Hi Avi,

I have three comments at this point in = time:

1) Editorial

There is some room for improvement on = the editorial side. An example:

FROM:

Abstract

   Internet Key Exchange is a component of IPsec used for = performing
   mutual authentication as well as establishing and = maintaining
   security associations (SAs) between two parties such as a = user and a
   network entity.  Internet Key Exchange v2 (IKEv2) = protocol allows
   several different mechanisms for authenticating a user, = namely the
   Extensible Authentication Protocol, certificates, and = pre-shared
   secrets.  To authenticate and/or authorize the user, = the network
   element such as the Access Gateway may need to dynamically = bootstrap
   a security association based on interaction with the = Diameter server.
   This document specifies the interaction between the Access = Gateway
   and Diameter server for the IKEv2 based on pre-shared = secrets.


TO:

"
Abstract

   The Internet Key Exchange protocol version 2 (IKEv2) is a component of
   the IPsec architecture and 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 secrets.

   With TBD-RFC the = 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 secret based authentication available
   with IKEv2. This = document therefore extends the functionality offered
   by TBD-RFC with = pre-shared key based authentication offered by IKEv2
   when no EAP is = used.
"

2) Reuse of = draft-ietf-dime-local-keytran-00.txt

Instead of defining your own key = related AVP wouldn't it make sense to reuse what has been defined in = <= FONT COLOR=3D"#0000FF" SIZE=3D4 = FACE=3D"Arial">http://www.ietf.org/id/draft-ietf-dime-local-keytran-00.tx= t ?

3) Security

The security in the document is a bit = fuzzy to me. I believe what you are saying is essentially that the = pre-shared key isn't really the user's long-term shared key but rather = something that has been dynamically established (and thus short lived) = based on a previous network access authentication run (or something like = that). Is my understanding correct?

In any case, I believe it would be = helpful to go through the Housley criteria as a guide for the text that = one might want to find in the security consideration sections of such a = document. This helps to point out some security threats in a more = structured fashion. Does this make sense to you?

Ciao
Hannes

------_=_NextPart_001_01CA9566.810FCB46-- From gwz@net-zen.net Thu Jan 14 19:48:32 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82C0F3A68B7 for ; Thu, 14 Jan 2010 19:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=-0.591, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kD-4o3UTtq6r for ; Thu, 14 Jan 2010 19:48:31 -0800 (PST) Received: from p3plsmtpa01-03.prod.phx3.secureserver.net (p3plsmtpa01-03.prod.phx3.secureserver.net [72.167.82.83]) by core3.amsl.com (Postfix) with SMTP id ABBFD3A6A1C for ; Thu, 14 Jan 2010 19:48:31 -0800 (PST) Received: (qmail 27712 invoked from network); 15 Jan 2010 03:48:27 -0000 Received: from unknown (124.120.225.244) by p3plsmtpa01-03.prod.phx3.secureserver.net (72.167.82.83) with ESMTP; 15 Jan 2010 03:48:27 -0000 From: "Glen Zorn" To: "'Romascanu, Dan \(Dan\)'" References: In-Reply-To: Date: Fri, 15 Jan 2010 10:48:16 +0700 Organization: Network Zen Message-ID: <001a01ca9595$9423a470$bc6aed50$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqVNMQD5s9Ykli7QDiva0RIwCdGQwAYLBXQ Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] WRONG allocations for DIME MIB modules X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 15 Jan 2010 03:48:32 -0000 Dan Romascanu [mailto://dromasca@avaya.com] writes: > While performing the AD reviews for the two MIB documents I fell upon > the fact that the two MIB modules use the same root {mib-2 119} > > This is probably done in order to pass compilation, but without any > explanation it can misguide early implementers. > > This is wrong for at least three reasons: > > 1. RFC 4181 recommends that allocation of the OIDs for the MIB module be > made only by IANA after the document is approved. > > 2. {mib-2 119} is already allocated and used by another IETF standard > MIB. If the authors wanted to use the experimental tree the OID should > have been {experimental 119} > > 3. Both diameterBaseProtocolMIB and diameterCCAMIB use the same OID > > If anybody plans to implement the MIB modules prior to I-D publication > they MUST NOT use the OIDs in the current document. This is the > principal reason for which I am sending this warning prior to the full > AD review. > > I strongly recommend to follow the recommendations in RFC 4181 section > 3.5.2 - like: > > diameterBaseProtocolMIB { mib-2 XXX } > > Editor's Note (to be removed prior to publication): the IANA is > requested to assign a value for "XXX" under the 'mib-2' subtree > and to record the assignment in the SMI Numbers registry. When > the assignment has been made, the RFC Editor is asked to replace > "XXX" (here and in the MIB module) with the assigned value and to > remove this note. > > The IANA Considerations sections must include the requests to allocate > two - different - values for the two MIB modules. OK. > > Thanks and Regards, > > Dan > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From root@core3.amsl.com Thu Jan 14 20:00:01 2010 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9A43E3A6A21; Thu, 14 Jan 2010 20:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100115040001.9A43E3A6A21@core3.amsl.com> Date: Thu, 14 Jan 2010 20:00:01 -0800 (PST) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-diameter-base-protocol-mib-04.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 15 Jan 2010 04:00:01 -0000 --NextPart 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 Base Protocol MIB Author(s) : G. Zorn, S. Comerica Filename : draft-ietf-dime-diameter-base-protocol-mib-04.txt Pages : 51 Date : 2010-01-14 Along with providing support for certain basic authentication, authorization and accounting functions, the Diameter protocol is designed to provide a framework for AAA applications. This document defines the Management Information Base (MIB) module which describes the minimum set of objects needed to manage an implementation of the Diameter protocol. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 19, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-base-protocol-mib-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-diameter-base-protocol-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-14194951.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Thu Jan 14 23:00:02 2010 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 059563A68EB; Thu, 14 Jan 2010 23:00:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100115070002.059563A68EB@core3.amsl.com> Date: Thu, 14 Jan 2010 23:00:02 -0800 (PST) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-diameter-cc-appl-mib-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 15 Jan 2010 07:00:02 -0000 --NextPart 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 Credit Control Application MIB Author(s) : G. Zorn, S. Comerica Filename : draft-ietf-dime-diameter-cc-appl-mib-03.txt Pages : 21 Date : 2010-01-14 Along with providing support for certain basic authentication, authorization and accounting functions, the Diameter base protocol is intended to provide a framework for AAA applications. This document defines the Management Information Base (MIB) module which describes the minimum set of objects needed to manage an implementation of the Diameter Credit Control application. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 19, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-cc-appl-mib-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-diameter-cc-appl-mib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-14225159.I-D@ietf.org> --NextPart-- From dromasca@avaya.com Mon Jan 18 11:30:28 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24ADA3A6801 for ; Mon, 18 Jan 2010 11:30:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQ5bYn3TLP2z for ; Mon, 18 Jan 2010 11:30:26 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id A9B0D3A677D for ; Mon, 18 Jan 2010 11:30:26 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,298,1262581200"; d="scan'208";a="200660784" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 18 Jan 2010 14:30:22 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 18 Jan 2010 14:30:22 -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, 18 Jan 2010 20:30:00 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-dime-diameter-base-protocol-mib-04.txt Thread-Index: AcqYdKBzg7NdMBxlQYW67jPvmYY2Nw== From: "Romascanu, Dan (Dan)" To: Subject: [Dime] AD review of draft-ietf-dime-diameter-base-protocol-mib-04.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 18 Jan 2010 19:30:28 -0000 Please find below the AD review of draft-ietf-dime-diameter-base-protocol-mib. This document is in pretty good shape, however, there are a number of issues that need to be clarified and answered before it is sent for IETF Last Call. Please consider the comments below and address them or clarify the questions that I have misunderstood.=20 Regards, Dan Meta Issue: it looks to me (although this is in no place clearly articulated) that this MIB module applies to DIAMETER servers only. If I am wrong, and a subset of the MIB module applies to clients, than this needs to be reflected in the MODULE-COMPLIANCE clauses. If I am correct than the fact it's a server MIB should be explicitly said in the document, and maybe the document and the MIB module renamed to reflect this. Then, what happens with clients. Will the WG develop another MIB module for clients ? Technical Issues:=20 T1. dbpProtocolErrorNotifEnabled has no information about persistency on reboot assigned, and so do a score of other writeable objects. Need to add this information, on a global or per object basis.=20 T2. dbpLocalId - what useful interoperable information provides this object if the id string is implementation-specific?=20 T3. why is dbpLocalIpAddrTable needed instead of using information from the ipAddressTable in RFC 4293? T4. dbpLocalRealm is read-only. How is the information acquired by the agent?=20 T5. what is the discontinuity indicator for dbpLocalStatsTotalMessagesIn and dbpLocalStatsTotalMessagesOut?=20 T6. What is the relation between dbpLocalStatsUpTime and dbpLocalResetTime? Why are not these the same? Does the ResetTime counter restart only on a reset command operation?=20 T7. In the DESCRIPTION of dbpLocalResetTime:=20 -- For software that does not have persistence or does not support a 'reset' operation, this value will be zero. This behavior is not conformant with the semantics of TimeTicks. You must define a different TruthValue object here.=20 T8. The DESCRIPTION clause of dbpLocalCOnfigurationReset speaks about 'when set to reset(2), but there is no such enumerated value.=20 T9. dbpLocalApplicationIndex=20 "A number uniquely identifying a supported Diameter application. Upon reload, dbpLocalApplIndex values may be changed." 'reload' means reset? How does this work? If the unique number which is also an index in the table changes how will a management application working with this agent know that this is the same application?=20 T10. dbpPeerId - is not this information coming from peers? Who ensures uniqueness? Or is this just a local index in this server for peers, created by the management application?=20 T11. When a new entry is created in the dbpPeerTable - how is the read-only information acquired?=20 T12. dbpPeerPortConnect - you cannot have a value zero(0) if the syntax is Unsigned32 (1..65535) - this should rather be Unsigned32(0|1..65535) T13. dbpPeerFirmwareRevision - the SYNTAX of this object should be consistent with the entPhysicalFirmwareRev object in RFC 4133 which is an SnmpAdminString. Actually the DESCRIPTION clause should mention that if the Entity MIB is supported on the peer, than the two objects must have identical contents.=20 T14. I need to understand how you use the StorageType objects. When written with the value permanent the row cannot be modified, only deleted? How would a management application know what to write there?=20 T15. Why does dbpAppAdvToPeerEntry have a PeerVendorId as index. Can a given server run DIAMETER applications originated from more than one vendor?=20 T16. dbbAppAdvToPeerIndex - same question as for T9 T17. Is not information about peers acquired? What does it mean for a manager to create an entry in the dbpPeerVendorTable? What if the peer does not exist?=20 T18. dbpPerPeerStatsTimeoutConnAtmpts - a counter that resets on disconnection can mislead the management application. What would it make if the read is 3 and at the next poll 1? Or 3 and 4 but maybe there was a 0 value in the meantime? You need a correct syntax counter, and another counter for the number of disconnects.=20 T19. I could not figure out what exactly dbpPerPeerStatsDWReqTimer means - how does the agent acquire this value?=20 T20. Security Considerations section - The security problems that can be caused by intentional or incidental misconfiguration of writeable objects must be described. For example 'Misconfiguration of dbpPeerConnectUpNotifyEnable can cause notifications about changes in peers connectivity not to be transmitted to the management application.', etc. =20 E1. RFC 4181 section 3.2 recommends that the narrative sections of MIB documents 'include one or more sections to briefly describe the structure of the MIB modules defined in the specification'. I see no reason for an exception here.=20 E2. Running id-nits results in a comment / question:=20 -- The document has a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. Does it really need the disclaimer? E3. I had a hard time associating the MIB objects with the definitions in RFC 3588. Adding REFERENCE clauses to the MIB objects would be extremely useful for the readability of the document.=20 E4. The DESCRIPTION clause of dbpProtocolErrorNotif and of other notification include the phrase:=20 -- It can be utilized by an NMS to trigger logical/physical entity table maintenance polls. What logical/physical entity table is referred to here? Is this from the Entity MIB. If so please add this information, and the Entity MIB as an informative reference E5. dbpLocalOriginHost - is this the host name?=20 E6. It would be useful to add UNITS clauses for all counters objects E7. dbpPeerProtocol should better be named dbpPeerTransportProtocol E8. Should not the SYNTAX of dbpAppAdvToPeerServices be rather a TC?=20 E9. The table dbpPerPeerStatsTable includes not only statistics but also other status and configuration information. It would be good to rename it in something like dbpPerPeerInfoTable and change the DESCRIPTION clause accordingly.=20 E10. dbpPerPeerStatsStateDuration - does this mean 'time elapsed since the last change in state?=20 E11. dbpPerPeerStatsTimeoutConnAttempts - s/attempts/attempted/ E12. UNITS clauses would be very helpful for all counter objects.=20 E13. The DESCRIPTION clauses of the counters objects refer to DIAMETER PDUs sometimes as 'messages', sometimes as 'packets'. Using a consistent terminology would be nice.=20 E14. DESCRIPTION clause of dbpRealmKnownPeers:=20 -- The index of the peer this realm knows about. This is an ordered list, where the ordering signifies the order in which the peers are tried. Same as the dbpPeerIndex Two questions: what is the 'This' that is referred to in the second phrase? What order means - that the peer with lower index value is tried first?=20 E15. dbpRealmKnownPeerChosen - it is recommended that in such enumerated other get value other(1) so that if new functional values are added later, other stays first and not in the middle.=20 From dromasca@avaya.com Tue Jan 19 06:27:08 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4813C3A67F0 for ; Tue, 19 Jan 2010 06:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.622 X-Spam-Level: X-Spam-Status: No, score=-2.622 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xq0ISYDJ9k34 for ; Tue, 19 Jan 2010 06:27:07 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 446CA3A659B for ; Tue, 19 Jan 2010 06:27:07 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,303,1262581200"; d="scan'208";a="200833485" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 19 Jan 2010 09:26:48 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 19 Jan 2010 09:26:17 -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, 19 Jan 2010 15:26:00 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-dime-diameter-cc-appl-mib-03.txt Thread-Index: AcqZE1Ks17Q8/tOnT7mdBuHxgVghvQ== From: "Romascanu, Dan (Dan)" To: Subject: [Dime] AD review of draft-ietf-dime-diameter-cc-appl-mib-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 19 Jan 2010 14:27:08 -0000 Please find below the AD review of draft-ietf-dime-diameter-cc-appl-mib-03.txt. This document is in pretty good shape, however, there are a number of issues that need to be clarified and answered before it is sent for IETF Last Call. Please consider the comments below and address them or clarify the questions that I have misunderstood.=20 Regards, Dan Technical Issues T1. In Section 3:=20 -- The MIB specification for the Diameter base protocol [I-D.ietf-dime-diameter-base-protocol-mib] SHOULD be implemented prior to the implementation of this MIB. Why is this a SHOULD and not a MUST?=20 Also, as an editorial observation around the same phrase, probably 'prior' is not the right term. What is meant is I think that it is assumed that an agent implementing the CC-application MIB also implements the base DIAMETER MIB.,=20 T2.=20 diameterCcAppMIB OBJECT IDENTIFIER ::=3D { diameterCCAMIB 2 } =20 I do not see the reason for two nested OIDs diameterCcAppMIB and diameterCCAMIB T3. dccaHostID - the definition is similar with dbpLocalId in the DIAMETER-BASE-PROTOCOL-MIB - why duplicate the object?=20 T4. How does dccaHostIpAddrTable differ from dbpLocalIpAddrTable? And if we are already here, the same question that I asked in the base MIB review applies here: why a new table instead of using information from the ipAddressTable in RFC 4293? T5. dccaPeerFirmwareRevision - the SYNTAX of this object should be consistent with the entPhysicalFirmwareRev object in RFC 4133 which is an SnmpAdminString. Actually the DESCRIPTION clause should mention that if the Entity MIB is supported on the peer, than the two objects must have identical contents.=20 T6. dccaPeerStorageType and dccaPeerVendorStorageType - the fact that none of the writeable objects cannot be changed - does this include the RowStatus object itself? This would mean that rows can be created by never deleted.=20 T7. The Security Considerations section does not follow the guidelines listed at http://www.ops.ietf.org/mib-security.html=20 Editorial Issues: E1. RFC 4181 section 3.2 recommends that the narrative sections of MIB documents 'include one or more sections to briefly describe the structure of the MIB modules defined in the specification'. I see no reason for an exception here.=20 E2. Running id-nits results in a comment / question:=20 -- The document has a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. Does it really need the disclaimer? E3. Adding REFERENCE clauses to the definitions in RFC 4006 and other places would be very useful and improve the readability of the document. E4. Even if not used by now it's better to use the name diameterCcAppNotifications rather than diameterCcAppTraps E5. Adding UNITS clauses to the counter objects definitions would be very useful From Hannes.Tschofenig@gmx.net Wed Jan 27 06:26:39 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CD903A6AA3 for ; Wed, 27 Jan 2010 06:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5jbkIC5nKb2 for ; Wed, 27 Jan 2010 06:26:38 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 2509D3A693F for ; Wed, 27 Jan 2010 06:26:37 -0800 (PST) Received: (qmail 5367 invoked by uid 0); 27 Jan 2010 14:26:51 -0000 Received: from 192.100.130.229 by www040.gmx.net with HTTP; Wed, 27 Jan 2010 15:26:48 +0100 (CET) Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Jan 2010 15:26:48 +0100 From: "Hannes Tschofenig" Message-ID: <20100127142648.123940@gmx.net> MIME-Version: 1.0 To: dime@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX19MVzBHJxVMV3jAiZfsGGH+DZbMbSZQSUxtKXDEKd l3AgywRvYXZ2+xWl+gkwJRg25MJJOhI4s5fw== Content-Transfer-Encoding: 7bit X-GMX-UID: TikIBlFRbHIhVYFb+zU0jj0iJihyatAs X-FuHaFi: 0.55 Subject: [Dime] Fwd: Posting of IPR Disclosure related to HUAWEI TECHNOLOGIES CO., LTD 's Statement about IPR related to draft-ietf-dime-realm-based-redirect-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 27 Jan 2010 14:26:39 -0000 FYI: -------- Original-Nachricht -------- Datum: Tue, 26 Jan 2010 12:50:49 -0800 (PST) Von: IETF Secretariat An: tom111.taylor@bell.net, tena@huawei.com CC: dromasca@avaya.com, rbonica@juniper.net, dime@ietf.org, Hannes.Tschofenig@gmx.net, vf0213@gmail.com, ipr-announce@ietf.org Betreff: Posting of IPR Disclosure related to HUAWEI TECHNOLOGIES CO.,LTD \'s Statement about IPR related to draft-ietf-dime-realm-based-redirect-02 Dear Tom Taylor, Tina Tsou (Ting ZOU): An IPR disclosure that pertains to your Internet-Draft entitled "Realm-Based Redirection In Diameter" (draft-ietf-dime-realm-based-redirect) was submitted to the IETF Secretariat on 2010-01-26 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1254/). The title of the IPR disclosure is "HUAWEI TECHNOLOGIES CO.,LTD 's Statement about IPR related to draft-ietf-dime-realm-based-redirect-02." The IETF Secretariat From gwz@net-zen.net Thu Jan 28 00:25:09 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01E253A63D3 for ; Thu, 28 Jan 2010 00:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mys5fqCuTVPu for ; Thu, 28 Jan 2010 00:25:08 -0800 (PST) Received: from p3plsmtpa01-05.prod.phx3.secureserver.net (p3plsmtpa01-05.prod.phx3.secureserver.net [72.167.82.85]) by core3.amsl.com (Postfix) with SMTP id 00BCB3A692E for ; Thu, 28 Jan 2010 00:25:07 -0800 (PST) Received: (qmail 10980 invoked from network); 28 Jan 2010 08:25:25 -0000 Received: from unknown (210.193.17.126) by p3plsmtpa01-05.prod.phx3.secureserver.net (72.167.82.85) with ESMTP; 28 Jan 2010 08:25:24 -0000 From: "Glen Zorn" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" References: <3D3C75174CB95F42AD6BCC56E5555B45020B8289@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45020B8289@FIESEXC015.nsn-intra.net> Date: Thu, 28 Jan 2010 15:24:38 +0700 Organization: Network Zen Message-ID: <00b501ca9ff3$676ff420$364fdc60$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqSwYGwXq8uKAvPTV2ZOoQkSOPjGAAgJH0w Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Quick look at draft-ietf-dime-local-keytran-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 28 Jan 2010 08:25:09 -0000 Tschofenig, Hannes (NSN - FI/Espoo) [mailto://hannes.tschofenig@nsn.com] writes: > Hi Glen, > > I thought I should take a look at the document to see where we are. > > I have a few comments: > > 1) I don't think you need to introduce so many terms in the terminology > section but rather expand their first occurrence in the intro section. > > Example: > > " > The Diameter EAP application [RFC4072] defines the EAP-Master- > Session-Key and EAP-Key-Name AVPs for the purpose of transporting > cryptographic keying material derived during the execution of certain > EAP [RFC3748] methods (for example, EAP-TLS [RFC5216]). At most one > instance of either of these AVPs is allowed in any Diameter message. > > However, recent work [RFC5295] has specified methods to derive other > keys from the keying material created during EAP method execution > that may require transport in addition to the MSK. In addition, ERP > [RFC5296] specifies new keys that may need to be transported between > Diameter nodes. > > This note specifies a set of AVPs allowing the transport of multiple > cryptographic keys in a single Diameter message. > " > > I would just expend the terms "ERP", "MSK", and "EAP" in this section > and avoid listing them in the terminology section. > > Also other terms do not appear too often in the document other than in > Section 3.1.1. > > Example: rRK > > > Just a matter of style -- not terribly important. Glad to hear that -- since this was done purposely just to avoid having to do what you suggest I'm not too thrilled with this idea ;-). > > > > 2) I think you only define some AVPs and hence you don't need to say > anything about the usage of these AVPs in certain Diameter messages. > > Example: I would remove the following sentence from Section 3.1.1: > " > The Key-Type AVP MAY be included in > a DER command as a signal that a certain type of key is required in > the response (e.g., to support ERP). > " OK > 3) Key-Lifetime > > You made a note that I did not quite understand: > > " > NOTE: > Applications using this value SHOULD consider the beginning of the > lifetime to be the point in time when the keying material is first > used. > " > > What is the reasoning behind this statement? Wouldn't you leave such > decisions to the specific document that describes how these AVPs are > used? Do we really want the same AVP to have different semantics in different apps? > > 4) I believe that the AVP occurrence table is not useful for this > document. I suggest to delete it. OK > You would want to put one in a document describing how these AVPs are, > for example, used with ERP. > > 5) Security Considerations > > Even though the security considerations are not dramatically different > to Diameter EAP I would suggest to discuss the topics. I suggest to copy > text. OK > > 6) Section 6.2 - IANA Registry for AVP values > > The text is a bit incomplete as you might want to tell IANA that you > want to create a new registry here. You have indicated the policy for > adding new values but you might want to also state whether you allow > values from the registry to be deleted, replaced, modified or depicated. OK. > > > Do you think that FCFS is a good policy here? Don't really care. > Everyone can come along > and put some really bogus stuff into this registry. How bogus could it be? > Would Expert Review > be too much here? Fine w/me. > > Otherwise I have no other comments and I believe we should start a WGLC > very soon. > > Ciao > Hannes > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From root@core3.amsl.com Thu Jan 28 00:45:03 2010 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EF9053A63D3; Thu, 28 Jan 2010 00:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100128084502.EF9053A63D3@core3.amsl.com> Date: Thu, 28 Jan 2010 00:45:01 -0800 (PST) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-local-keytran-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 28 Jan 2010 08:45:03 -0000 --NextPart 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 Attribute-Value Pairs for Cryptographic Key Transport Author(s) : W. Wu, G. Zorn Filename : draft-ietf-dime-local-keytran-01.txt Pages : 7 Date : 2010-01-28 Some Authentication, Authorization, and Accounting (AAA) applications require the transport of cryptographic keying material; this document specifies a set of Attribute-Value Pairs (AVPs) providing native Diameter support of cryptographic key delivery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-local-keytran-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-local-keytran-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-28004449.I-D@ietf.org> --NextPart--