From root@core3.amsl.com Sun Aug 2 12:45:01 2009 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id AD3843A697B; Sun, 2 Aug 2009 12:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090802194501.AD3843A697B@core3.amsl.com> Date: Sun, 2 Aug 2009 12:45:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-diameter-qos-10.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: Sun, 02 Aug 2009 19:45: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 Quality of Service Application Author(s) : D. Sun, et al. Filename : draft-ietf-dime-diameter-qos-10.txt Pages : 58 Date : 2009-08-02 This document describes the framework, messages and procedures for the Diameter Quality of Service (QoS) application. The Diameter QoS application allows network elements to interact with Diameter servers when allocating QoS resources in the network. In particular, two modes of operation -- Pull and Push -- are defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-10.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-qos-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-02123612.I-D@ietf.org> --NextPart-- From pete.mccann@motorola.com Mon Aug 3 11:18:05 2009 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 6EAAE3A6DEE; Mon, 3 Aug 2009 11:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.316 X-Spam-Level: X-Spam-Status: No, score=-6.316 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 uX1ilbga8fEX; Mon, 3 Aug 2009 11:18:04 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id F20C83A6C51; Mon, 3 Aug 2009 11:18:03 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-12.tower-119.messagelabs.com!1249323472!40313055!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 15990 invoked from network); 3 Aug 2009 18:17:52 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Aug 2009 18:17:52 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id n73IHpNc000382; Mon, 3 Aug 2009 11:17:52 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id n73IHpUN022451; Mon, 3 Aug 2009 13:17:51 -0500 (CDT) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id n73IHpHN022447; Mon, 3 Aug 2009 13:17:51 -0500 (CDT) 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, 3 Aug 2009 14:17:29 -0400 Message-ID: <274D46DDEB9F2244B2F1EA66B3FF54BC05685EA8@de01exm70.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gen-ART Review of draft-ietf-dime-nai-routing-02 Thread-Index: AcoUZqmJ+jTO61PNRfiGO66C/WbNZQ== From: "McCann Peter-A001034" To: , X-CFilter-Loop: Reflected Cc: dime@ietf.org Subject: [Dime] Gen-ART Review of draft-ietf-dime-nai-routing-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: Mon, 03 Aug 2009 18:18:05 -0000 I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dime-nai-routing-02 Reviewer: Pete McCann Review Date: 2009-08-03 IETF LC End Date: 2009-08-04 IESG Telechat date: unknown Summary: Two major issues need discussion Major issues: The draft seems to address only routing of Request commands. What about Answers? Are Diameter proxies required to re-write the Origin-Realm and Origin-Host AVPs as the request gets routed? Are they required then to maintain state to map the responses back to the originating realm? The processing rules seem to strip off the decoration from the NAI; there might be a need for the home AAA server to know the path that was taken through the network (routing the Answer commands is only one possible reason). Maybe the solution is to provide a decorated Origin-Realm that is recomputed by each hop. > 4.2. Ensuring Backwards Compatibility > > Implementations compliant to this specification MUST define a new > Diameter application. This requirement is set to guarantee backwards > compatibility with existing Diameter implementations, applications > and deployments. Diameter agents not compliant with this > specification will not advertise support for these new applications > that implement the enhanced routing solution based on Decorated NAIs > and will therefore be bypassed. This requirement troubles me; does this mean that every Diameter application will need to define a whole set of Application-IDs, based on the cross-product of every feature that gets introduced? Maybe this is a general problem with Diameter application versioning, and it's too late to fix it. Is there a=20 better way to somehow indicate support for this feature? Minor issues: Nits/editorial comments: End of Section 3: > [RFC5113] Section 2.3. also discusses NAI decoration related issues > with EAP [RFC3748] in general. Seems there is an extra period after "Section 2.3". Suggest changing the reference pointer to text, i.e., > Section 2.3 of RFC5113 also discusses NAI decoration related issues > with EAP [RFC3748] in general. Section 4.1: > an uniform SHOULD BE: > a uniform Section 6: > In this case the NAS to the Diameter server AAA communication rely on SHOULD BE: > In this case the NAS to Diameter server AAA communication relies on From jouni.nospam@gmail.com Tue Aug 4 10:20:04 2009 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 230673A682A; Tue, 4 Aug 2009 10:20:04 -0700 (PDT) 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 Wund6gBmMDEY; Tue, 4 Aug 2009 10:20:02 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by core3.amsl.com (Postfix) with ESMTP id 445C23A67F8; Tue, 4 Aug 2009 10:20:01 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id e12so649499fga.18 for ; Tue, 04 Aug 2009 10:20:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=SiUsqP45WmEujxdzw0J0oXRhgii7AaxJ51j4ygqU0og=; b=dRjKjBk6cigM1FfCZdURR+9c36xlxUCV//0BiTmwsAk2vzxj2a9151nTmXIJdiFdEn QVrc/gHfOn4qAs2HDLjtxLHbkNqt9ZRffLYIxV5v/4CF15MoLgBRm5LgZsZzJT0WPE5N T+UM2xpmILaP+UIwHWB6hXT4jK5HhV/SzIi1A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=YNuEkMZIJC4H1oqTZ840QZ0SjtuyeBF1IXxfHu6PwgL0b5qNMwwh30ftSnHS433lac xYhtxI8WUdTkjuIsiqxO9SR0asT1NQi+TfJZk/87NpD0r+WWA87c2+anzVXvZ8hg4aop hUJDUWPINIvCE9fePlNOX1LN7jlhdYGeeEVNQ= Received: by 10.86.72.1 with SMTP id u1mr2973676fga.16.1249406402054; Tue, 04 Aug 2009 10:20:02 -0700 (PDT) Received: from a88-114-170-222.elisa-laajakaista.fi (a88-114-170-222.elisa-laajakaista.fi [88.114.170.222]) by mx.google.com with ESMTPS id e11sm4693941fga.6.2009.08.04.10.20.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 04 Aug 2009 10:20:01 -0700 (PDT) Message-Id: <4C124F82-50C8-4520-B3FE-7A4420C4DFDB@gmail.com> From: jouni korhonen To: McCann Peter-A001034 In-Reply-To: <274D46DDEB9F2244B2F1EA66B3FF54BC05685EA8@de01exm70.ds.mot.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 4 Aug 2009 20:19:59 +0300 References: <274D46DDEB9F2244B2F1EA66B3FF54BC05685EA8@de01exm70.ds.mot.com> X-Mailer: Apple Mail (2.935.3) Cc: dime@ietf.org, gen-art@ietf.org, draft-ietf-dime-nai-routing.all@tools.ietf.org Subject: Re: [Dime] Gen-ART Review of draft-ietf-dime-nai-routing-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: Tue, 04 Aug 2009 17:20:04 -0000 Hi Peter, Thanks for the review. See my comments inline. On Aug 3, 2009, at 9:17 PM, McCann Peter-A001034 wrote: > I have been selected as the General Area Review Team (Gen-ART) > reviewer > for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-dime-nai-routing-02 > Reviewer: Pete McCann > Review Date: 2009-08-03 > IETF LC End Date: 2009-08-04 > IESG Telechat date: unknown > > Summary: Two major issues need discussion > > > Major issues: > > The draft seems to address only routing of Request commands. What > about Answers? Are Diameter proxies required to re-write the Answers follow the reverse path the request traversed. The answers are processed according to base RFC3588. > Origin-Realm and Origin-Host AVPs as the request gets routed? No. Both Origin-Realm and Origin-Host correspond to the entity that originated the request. > Are they required then to maintain state to map the responses back > to the originating realm? The processing rules seem to strip off Not really. Intermediating agents only need to maintain a transaction state. This is the same as required for normal RFC3588 request-answer processing. > the decoration from the NAI; there might be a need for the home AAA > server to know the path that was taken through the network (routing > the Answer commands is only one possible reason). Maybe the solution > is to provide a decorated Origin-Realm that is recomputed by each > hop. RFC3588 Route-Record AVP already provides this information. I see no reason to go any further here regarding to changes/enhancements to RFC3588 answer processing. >> >> 4.2. Ensuring Backwards Compatibility >> >> Implementations compliant to this specification MUST define a new >> Diameter application. This requirement is set to guarantee > backwards >> compatibility with existing Diameter implementations, applications >> and deployments. Diameter agents not compliant with this >> specification will not advertise support for these new applications >> that implement the enhanced routing solution based on Decorated NAIs >> and will therefore be bypassed. > > This requirement troubles me; does this mean that every Diameter > application > will need to define a whole set of Application-IDs, based on the > cross-product > of every feature that gets introduced? Maybe this is a general > problem > with > Diameter application versioning, and it's too late to fix it. Is > there > a > better way to somehow indicate support for this feature? It indeed is a general issue with Diameter application versioning (some SDOs have introduced their own versioning schemes to avoid defining new applications for e.g. every new release). There was lengthy discussion of possible choices how to solve it for this I-D. Requiring a new application seemed to be the easiest way to get forward. Generally, one application can/should include several "new features" so the explosion on applications should not become a problem.. > > Minor issues: > > > Nits/editorial comments: > > End of Section 3: > >> [RFC5113] Section 2.3. also discusses NAI decoration related issues >> with EAP [RFC3748] in general. > Seems there is an extra period after "Section 2.3". Suggest changing > the reference pointer to text, i.e., >> Section 2.3 of RFC5113 also discusses NAI decoration related issues >> with EAP [RFC3748] in general. > > Section 4.1: > >> an uniform > SHOULD BE: >> a uniform > > Section 6: >> In this case the NAS to the Diameter server AAA communication rely > on > SHOULD BE: >> In this case the NAS to Diameter server AAA communication relies on Thanks. Will fix these. Cheers, Jouni From pete.mccann@motorola.com Tue Aug 4 10:42:07 2009 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 7540028C43E; Tue, 4 Aug 2009 10:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.222 X-Spam-Level: X-Spam-Status: No, score=-6.222 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 VgqnNz+imCy5; Tue, 4 Aug 2009 10:42:06 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id 9BA0A28C448; Tue, 4 Aug 2009 10:42:05 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-3.tower-119.messagelabs.com!1249407720!44240467!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [136.182.1.12] Received: (qmail 2620 invoked from network); 4 Aug 2009 17:42:01 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (136.182.1.12) by server-3.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Aug 2009 17:42:01 -0000 Received: from il27exr04.cig.mot.com (il27exr04.mot.com [10.17.196.73]) by motgate2.mot.com (8.14.3/8.14.3) with ESMTP id n74Hftd3012557; Tue, 4 Aug 2009 10:42:00 -0700 (MST) Received: from il27vts03 (il27vts03.cig.mot.com [10.17.196.87]) by il27exr04.cig.mot.com (8.13.1/Vontu) with SMTP id n74HfsES017770; Tue, 4 Aug 2009 12:41:54 -0500 (CDT) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by il27exr04.cig.mot.com (8.13.1/8.13.0) with ESMTP id n74HfsJF017766; Tue, 4 Aug 2009 12:41:54 -0500 (CDT) 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, 4 Aug 2009 13:41:34 -0400 Message-ID: <274D46DDEB9F2244B2F1EA66B3FF54BC05686338@de01exm70.ds.mot.com> In-Reply-To: <4C124F82-50C8-4520-B3FE-7A4420C4DFDB@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gen-ART Review of draft-ietf-dime-nai-routing-02 Thread-Index: AcoVJ9ILZHBeAhviT6OVJ+aeZg8c1wAAQ4PA References: <274D46DDEB9F2244B2F1EA66B3FF54BC05685EA8@de01exm70.ds.mot.com> <4C124F82-50C8-4520-B3FE-7A4420C4DFDB@gmail.com> From: "McCann Peter-A001034" To: "jouni korhonen" X-CFilter-Loop: Reflected Cc: dime@ietf.org, gen-art@ietf.org, draft-ietf-dime-nai-routing.all@tools.ietf.org Subject: Re: [Dime] Gen-ART Review of draft-ietf-dime-nai-routing-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: Tue, 04 Aug 2009 17:42:07 -0000 Hi, Jouni, Thanks, I went back and re-read Section 2.8 of RFC 3588 and refreshed my understanding of Diameter Answer routing. You are correct that the reverse path routing is taken care of by the=20 transaction state. Perhaps you could add one sentence about=20 the Answer routing with a reference to Section 2.8 of RFC 3588? I suppose using the Application ID for expressing support for the feature is ok if that is the will of the working group. -Pete jouni korhonen wrote: > Hi Peter, >=20 > Thanks for the review. See my comments inline. >=20 >=20 > On Aug 3, 2009, at 9:17 PM, McCann Peter-A001034 wrote: >=20 >> I have been selected as the General Area Review Team (Gen-ART) >> reviewer for this draft (for background on Gen-ART, please see >> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>=20 >> Please resolve these comments along with any other Last Call >> comments you may receive.=20 >>=20 >> Document: draft-ietf-dime-nai-routing-02 >> Reviewer: Pete McCann >> Review Date: 2009-08-03 >> IETF LC End Date: 2009-08-04 >> IESG Telechat date: unknown >>=20 >> Summary: Two major issues need discussion >>=20 >>=20 >> Major issues: >>=20 >> The draft seems to address only routing of Request commands. What >> about Answers? Are Diameter proxies required to re-write the >=20 > Answers follow the reverse path the request traversed. The answers > are processed according to base RFC3588.=20 >=20 >> Origin-Realm and Origin-Host AVPs as the request gets routed? >=20 > No. Both Origin-Realm and Origin-Host correspond to the entity that > originated the request.=20 >=20 >> Are they required then to maintain state to map the responses back to >> the originating realm? The processing rules seem to strip off >=20 > Not really. Intermediating agents only need to maintain a transaction > state. This is the same as required for normal RFC3588 request-answer > processing. =20 >=20 >> the decoration from the NAI; there might be a need for the home AAA >> server to know the path that was taken through the network (routing >> the Answer commands is only one possible reason). Maybe the solution >> is to provide a decorated Origin-Realm that is recomputed by each >> hop.=20 >=20 > RFC3588 Route-Record AVP already provides this information. I see no > reason to go any further here regarding to changes/enhancements to=20 > RFC3588 answer processing. >=20 >=20 >>>=20 >>> 4.2. Ensuring Backwards Compatibility >>>=20 >>> Implementations compliant to this specification MUST define a new >>> Diameter application. This requirement is set to guarantee >>> backwards compatibility with existing Diameter implementations, >>> applications and deployments. Diameter agents not compliant with >>> this specification will not advertise support for these new >>> applications that implement the enhanced routing solution based on >>> Decorated NAIs and will therefore be bypassed. >>=20 >> This requirement troubles me; does this mean that every Diameter >> application will need to define a whole set of Application-IDs, based >> on the cross-product of every feature that gets introduced? Maybe >> this is a general problem with Diameter application versioning, and >> it's too late to fix it. Is there a better way to somehow indicate >> support for this feature? >=20 > It indeed is a general issue with Diameter application versioning > (some SDOs have introduced their own versioning schemes to avoid > defining new applications for e.g. every new release). There was > lengthy discussion of possible choices how to solve it for this I-D. > Requiring a new application seemed to be the easiest way to get > forward. Generally, one application can/should include several "new > features" so the explosion on applications should not become a > problem.. =20 >=20 >>=20 >> Minor issues: >>=20 >>=20 >> Nits/editorial comments: >>=20 >> End of Section 3: >>=20 >>> [RFC5113] Section 2.3. also discusses NAI decoration related issues >>> with EAP [RFC3748] in general. >> Seems there is an extra period after "Section 2.3". Suggest changing >> the reference pointer to text, i.e., >>> Section 2.3 of RFC5113 also discusses NAI decoration related issues >>> with EAP [RFC3748] in general. >>=20 >> Section 4.1: >>=20 >>> an uniform >> SHOULD BE: >>> a uniform >>=20 >> Section 6: >>> In this case the NAS to the Diameter server AAA communication rely >> on >> SHOULD BE: >>> In this case the NAS to Diameter server AAA communication relies on >=20 > Thanks. Will fix these. >=20 > Cheers, > Jouni From jouni.nospam@gmail.com Tue Aug 4 11:06:54 2009 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 7D0003A67D3; Tue, 4 Aug 2009 11:06:54 -0700 (PDT) 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 9QZaes1DRF24; Tue, 4 Aug 2009 11:06:53 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by core3.amsl.com (Postfix) with ESMTP id 13E5C3A62C1; Tue, 4 Aug 2009 11:06:53 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c37so1911926anc.4 for ; Tue, 04 Aug 2009 11:06:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=n2VpFwzAy4moKEd+GQgmn53bjN49603ra5Ohrwpe6+w=; b=GIwNXoCY1ifqsbGnmxETaBmNwZlAIvJ2U0qAuOm2CWQy8jfkkLB8+IMfrIH126yOay 1G1I3wMxBQ2/IT9TxXSQozWUZfnP9JEKnRaVXvGCWm+iYXP5eoxsVJsguWy+BpYuydAV pUU1Py7VWTZctpRAqyLs2GUaE+TCVwYNdpz54= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=riSPqBR4iNz6h52sgtM9vPPciNdmXRhc6Pab3G1JlOD7EZiNW1j5mw9exkYz3mBIaj bVAJdRbUYX6mCVVaIc9SX43tkWEXuAH7vpDb3u+tVFFBjyvpHvq2O6JqqgyqStmLksth gnxi+8SRGPvOTFVjtX6gjafPx0jFtHT+LtUlc= Received: by 10.100.58.12 with SMTP id g12mr10419645ana.70.1249409213363; Tue, 04 Aug 2009 11:06:53 -0700 (PDT) Received: from a88-114-170-222.elisa-laajakaista.fi ([72.14.241.5]) by mx.google.com with ESMTPS id c14sm143600ana.12.2009.08.04.11.06.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 04 Aug 2009 11:06:52 -0700 (PDT) Message-Id: From: jouni korhonen To: McCann Peter-A001034 In-Reply-To: <274D46DDEB9F2244B2F1EA66B3FF54BC05686338@de01exm70.ds.mot.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 4 Aug 2009 21:06:48 +0300 References: <274D46DDEB9F2244B2F1EA66B3FF54BC05685EA8@de01exm70.ds.mot.com> <4C124F82-50C8-4520-B3FE-7A4420C4DFDB@gmail.com> <274D46DDEB9F2244B2F1EA66B3FF54BC05686338@de01exm70.ds.mot.com> X-Mailer: Apple Mail (2.935.3) Cc: dime@ietf.org, gen-art@ietf.org, draft-ietf-dime-nai-routing.all@tools.ietf.org Subject: Re: [Dime] Gen-ART Review of draft-ietf-dime-nai-routing-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: Tue, 04 Aug 2009 18:06:54 -0000 Hi Peter, On Aug 4, 2009, at 8:41 PM, McCann Peter-A001034 wrote: > Hi, Jouni, > > Thanks, I went back and re-read Section 2.8 of RFC 3588 and > refreshed my understanding of Diameter Answer routing. You are > correct that the reverse path routing is taken care of by the > transaction state. Perhaps you could add one sentence about > the Answer routing with a reference to Section 2.8 of RFC 3588? Will add this. > > I suppose using the Application ID for expressing support for > the feature is ok if that is the will of the working group. I would say it fulfilled the description of a rough consensus. Everybody was equally unhappy ;) Cheers, Jouni > > -Pete > > jouni korhonen wrote: >> Hi Peter, >> >> Thanks for the review. See my comments inline. >> >> >> On Aug 3, 2009, at 9:17 PM, McCann Peter-A001034 wrote: >> >>> I have been selected as the General Area Review Team (Gen-ART) >>> reviewer for this draft (for background on Gen-ART, please see >>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>> >>> Please resolve these comments along with any other Last Call >>> comments you may receive. >>> >>> Document: draft-ietf-dime-nai-routing-02 >>> Reviewer: Pete McCann >>> Review Date: 2009-08-03 >>> IETF LC End Date: 2009-08-04 >>> IESG Telechat date: unknown >>> >>> Summary: Two major issues need discussion >>> >>> >>> Major issues: >>> >>> The draft seems to address only routing of Request commands. What >>> about Answers? Are Diameter proxies required to re-write the >> >> Answers follow the reverse path the request traversed. The answers >> are processed according to base RFC3588. >> >>> Origin-Realm and Origin-Host AVPs as the request gets routed? >> >> No. Both Origin-Realm and Origin-Host correspond to the entity that >> originated the request. >> >>> Are they required then to maintain state to map the responses back >>> to >>> the originating realm? The processing rules seem to strip off >> >> Not really. Intermediating agents only need to maintain a transaction >> state. This is the same as required for normal RFC3588 request-answer >> processing. >> >>> the decoration from the NAI; there might be a need for the home AAA >>> server to know the path that was taken through the network (routing >>> the Answer commands is only one possible reason). Maybe the >>> solution >>> is to provide a decorated Origin-Realm that is recomputed by each >>> hop. >> >> RFC3588 Route-Record AVP already provides this information. I see no >> reason to go any further here regarding to changes/enhancements to >> RFC3588 answer processing. >> >> >>>> >>>> 4.2. Ensuring Backwards Compatibility >>>> >>>> Implementations compliant to this specification MUST define a new >>>> Diameter application. This requirement is set to guarantee >>>> backwards compatibility with existing Diameter implementations, >>>> applications and deployments. Diameter agents not compliant with >>>> this specification will not advertise support for these new >>>> applications that implement the enhanced routing solution based on >>>> Decorated NAIs and will therefore be bypassed. >>> >>> This requirement troubles me; does this mean that every Diameter >>> application will need to define a whole set of Application-IDs, >>> based >>> on the cross-product of every feature that gets introduced? Maybe >>> this is a general problem with Diameter application versioning, and >>> it's too late to fix it. Is there a better way to somehow indicate >>> support for this feature? >> >> It indeed is a general issue with Diameter application versioning >> (some SDOs have introduced their own versioning schemes to avoid >> defining new applications for e.g. every new release). There was >> lengthy discussion of possible choices how to solve it for this I-D. >> Requiring a new application seemed to be the easiest way to get >> forward. Generally, one application can/should include several "new >> features" so the explosion on applications should not become a >> problem.. >> >>> >>> Minor issues: >>> >>> >>> Nits/editorial comments: >>> >>> End of Section 3: >>> >>>> [RFC5113] Section 2.3. also discusses NAI decoration related issues >>>> with EAP [RFC3748] in general. >>> Seems there is an extra period after "Section 2.3". Suggest >>> changing >>> the reference pointer to text, i.e., >>>> Section 2.3 of RFC5113 also discusses NAI decoration related issues >>>> with EAP [RFC3748] in general. >>> >>> Section 4.1: >>> >>>> an uniform >>> SHOULD BE: >>>> a uniform >>> >>> Section 6: >>>> In this case the NAS to the Diameter server AAA communication rely >>> on >>> SHOULD BE: >>>> In this case the NAS to Diameter server AAA communication relies on >> >> Thanks. Will fix these. >> >> Cheers, >> Jouni > From root@core3.amsl.com Wed Aug 5 16:00:01 2009 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id F04AD3A68B6; Wed, 5 Aug 2009 16:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090805230001.F04AD3A68B6@core3.amsl.com> Date: Wed, 5 Aug 2009 16:00:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-diameter-qos-11.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, 05 Aug 2009 23: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 Quality of Service Application Author(s) : D. Sun, et al. Filename : draft-ietf-dime-diameter-qos-11.txt Pages : 57 Date : 2009-08-05 This document describes the framework, messages and procedures for the Diameter Quality of Service (QoS) application. The Diameter QoS application allows network elements to interact with Diameter servers when allocating QoS resources in the network. In particular, two modes of operation -- Pull and Push -- are defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-11.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-qos-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-05155815.I-D@ietf.org> --NextPart-- From sdecugis@nict.go.jp Thu Aug 6 22:40:56 2009 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 E55CC3A6B15 for ; Thu, 6 Aug 2009 22:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.059 X-Spam-Level: * X-Spam-Status: No, score=1.059 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 SjeRxKCR+WWs for ; Thu, 6 Aug 2009 22:40:56 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id 9E2973A6B0B for ; Thu, 6 Aug 2009 22:40:55 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id n775ev2P019544 for ; Fri, 7 Aug 2009 14:40:57 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id n775euuW010378 for ; Fri, 7 Aug 2009 14:40:56 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id n775euCV010375 for ; Fri, 7 Aug 2009 14:40:56 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id D3E85169E9 for ; Fri, 7 Aug 2009 14:40:56 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail3.nict.go.jp (NICT Mail) with ESMTP id CF3E9169E5 for ; Fri, 7 Aug 2009 14:40:56 +0900 (JST) Message-ID: <4A7BBE4F.3000307@nict.go.jp> Date: Fri, 07 Aug 2009 14:40:31 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "dime@ietf.org" X-Enigmail-Version: 0.96.0 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Dime] Very small editorial on rfc3588bis 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, 07 Aug 2009 05:40:57 -0000 Hello, I am not sure if it's already too late, I just found a small editorial problem in draft-ietf-dime-rfc3588bis-18.txt : In section "2.6. Peer Table": Host identity Following the conventions described for the DiameterIdentity derived AVP data format in Section 4.4. This field contains the ^^^ should be 4.3 Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From vfajardo@research.telcordia.com Fri Aug 7 05:06:59 2009 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 C5CCC3A6F13 for ; Fri, 7 Aug 2009 05:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.964 X-Spam-Level: X-Spam-Status: No, score=-1.964 tagged_above=-999 required=5 tests=[AWL=0.635, 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 nbHSDhLhPEzn for ; Fri, 7 Aug 2009 05:06:59 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id EE7BD3A6AA8 for ; Fri, 7 Aug 2009 05:06:58 -0700 (PDT) Received: from fajardov1 (vpntnlB33.research.telcordia.com [128.96.59.33]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id n77C71Ub008099; Fri, 7 Aug 2009 08:07:01 -0400 (EDT) From: "Victor Fajardo" To: "'Sebastien Decugis'" , References: <4A7BBE4F.3000307@nict.go.jp> In-Reply-To: <4A7BBE4F.3000307@nict.go.jp> Date: Fri, 7 Aug 2009 08:07:01 -0400 Organization: Applied Research, Telcordia Technologies Message-ID: <004901ca1757$9255f1a0$b701d4e0$@telcordia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcoXIaj9SKA1Vh+8Qa6Pe5jZbhXYUQANce9w Content-Language: en-us Subject: Re: [Dime] Very small editorial on rfc3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: vfajardo@research.telcordia.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 12:06:59 -0000 Thanks. We'll add the changes. -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Sebastien Decugis Sent: Friday, August 07, 2009 1:41 AM To: dime@ietf.org Subject: [Dime] Very small editorial on rfc3588bis Hello, I am not sure if it's already too late, I just found a small editorial problem in draft-ietf-dime-rfc3588bis-18.txt : In section "2.6. Peer Table": Host identity Following the conventions described for the DiameterIdentity derived AVP data format in Section 4.4. This field contains the ^^^ should be 4.3 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 hannes.tschofenig@nsn.com Thu Aug 13 06:30:53 2009 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 8510C3A6AAD for ; Thu, 13 Aug 2009 06:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.058 X-Spam-Level: X-Spam-Status: No, score=-5.058 tagged_above=-999 required=5 tests=[AWL=1.540, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 2GanfDX7RiPq for ; Thu, 13 Aug 2009 06:30:52 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 95E0D3A69EB for ; Thu, 13 Aug 2009 06:30:52 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n7DDTSAX014955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 13 Aug 2009 15:29:28 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n7DDTS7l026747 for ; Thu, 13 Aug 2009 15:29:28 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Aug 2009 15:29:28 +0200 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_01CA1C1A.14FF5F4C" Date: Thu, 13 Aug 2009 16:32:01 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45019756AF@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Meeting Minutes (IETF#75) Thread-Index: AcocGnCC/Zw8xYTlTAup6e3/3Vmlpw== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 13 Aug 2009 13:29:28.0546 (UTC) FILETIME=[154B3C20:01CA1C1A] Subject: [Dime] Meeting Minutes (IETF#75) 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, 13 Aug 2009 13:30:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA1C1A.14FF5F4C Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Victor uploaded the meeting minutes:=20 http://www.ietf.org/proceedings/75/minutes/dime.txt Comments and corrections appreciated! ------_=_NextPart_001_01CA1C1A.14FF5F4C Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Meeting Minutes (IETF#75)

Victor uploaded the meeting minutes: =
http://www.ietf.org/proceedings/75/minutes/dime.txt=

Comments and corrections = appreciated!

------_=_NextPart_001_01CA1C1A.14FF5F4C-- From gwz@net-zen.net Mon Aug 17 08:25:50 2009 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 BA5FC3A6F21 for ; Mon, 17 Aug 2009 08:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.35 X-Spam-Level: X-Spam-Status: No, score=-0.35 tagged_above=-999 required=5 tests=[AWL=-0.351, BAYES_50=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 pnkhGcGQvvke for ; Mon, 17 Aug 2009 08:25:50 -0700 (PDT) Received: from smtpauth13.prod.mesa1.secureserver.net (smtpauth13.prod.mesa1.secureserver.net [64.202.165.37]) by core3.amsl.com (Postfix) with SMTP id 126283A6E76 for ; Mon, 17 Aug 2009 08:25:50 -0700 (PDT) Received: (qmail 24856 invoked from network); 17 Aug 2009 15:25:55 -0000 Received: from unknown (71.231.55.1) by smtpauth13.prod.mesa1.secureserver.net (64.202.165.37) with ESMTP; 17 Aug 2009 15:25:54 -0000 From: "Glen Zorn" To: Date: Mon, 17 Aug 2009 08:25:37 -0700 Organization: Network Zen Message-ID: <007701ca1f4e$f9a01ad0$ece05070$@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: AcofTvikUXiM85IVQ76SxT288qw5vg== Content-Language: en-us Cc: dime@ietf.org Subject: [Dime] draft-zorn-dime-doc-set-00 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, 17 Aug 2009 15:25:50 -0000 In the Stockholm meeting I got the distinct impression that this document is basically useless, since it doesn't attempt to catalog the various non-IETF documents related to Diameter. I will, therefore, happily let it expire and fade away. From jouni.nospam@gmail.com Wed Aug 19 01:20:47 2009 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 13DAF3A68E6; Wed, 19 Aug 2009 01:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.093 X-Spam-Level: X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[AWL=0.507, 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 OLZXw0Wta+8v; Wed, 19 Aug 2009 01:20:46 -0700 (PDT) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by core3.amsl.com (Postfix) with ESMTP id 4CD103A683D; Wed, 19 Aug 2009 01:20:45 -0700 (PDT) Received: by fxm26 with SMTP id 26so3241304fxm.42 for ; Wed, 19 Aug 2009 01:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=lI8hVawTDvzU95jOAl0A8oC4bxOX3NPu1MKGupBIp2Q=; b=gKJr+Mmuo2m7+oR722uFCMqWhkQU2f0mnGjUkPqtQmrlag2cupQv57JLb/8xqwXST5 FDwqnHySouqM5/UN8vM1RViO/wXgXIDeirKZ6HuKuvY1tDleqKF6yL5Lj1AZZqmhiPZU RAJ6h5+oZsDI2LlyI/HYuAIT503k402kv+tdE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=CNjPa+QITiKZapjo8lY84FrIwiFjazi0o4j9qkWLESckTMZPY2YYGqcaexthf5e8dp vjKXx7so57hgiG5vpdBTGCaYLdzmnCpWW8/OX8FfCQFNLkTz57Qkfe+gvhOpLcgD4am/ 7EOBIdC3q3BuZiSixr+3n6AsPkrqXIxzZC/Ys= Received: by 10.204.24.145 with SMTP id v17mr4700408bkb.3.1250669946088; Wed, 19 Aug 2009 01:19:06 -0700 (PDT) Received: from a88-112-141-111.elisa-laajakaista.fi (a88-112-141-111.elisa-laajakaista.fi [88.112.141.111]) by mx.google.com with ESMTPS id 22sm7856161fkr.30.2009.08.19.01.19.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 19 Aug 2009 01:19:05 -0700 (PDT) Message-Id: <1A12DEAF-C84D-4789-B9DB-F1D2CDA98474@gmail.com> From: jouni korhonen To: McCann Peter-A001034 , "Dan (Dan) Romascanu" In-Reply-To: <274D46DDEB9F2244B2F1EA66B3FF54BC05686338@de01exm70.ds.mot.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 19 Aug 2009 11:19:02 +0300 References: <274D46DDEB9F2244B2F1EA66B3FF54BC05685EA8@de01exm70.ds.mot.com> <4C124F82-50C8-4520-B3FE-7A4420C4DFDB@gmail.com> <274D46DDEB9F2244B2F1EA66B3FF54BC05686338@de01exm70.ds.mot.com> X-Mailer: Apple Mail (2.936) Cc: dime@ietf.org, gen-art@ietf.org, draft-ietf-dime-nai-routing.all@tools.ietf.org Subject: Re: [Dime] Gen-ART Review of draft-ietf-dime-nai-routing-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, 19 Aug 2009 08:20:47 -0000 Hi Pete, I have updated the I-D based on your comments. The -03 version should be available readily in draft repositories. Cheers, Jouni On Aug 4, 2009, at 8:41 PM, McCann Peter-A001034 wrote: > Hi, Jouni, > > Thanks, I went back and re-read Section 2.8 of RFC 3588 and > refreshed my understanding of Diameter Answer routing. You are > correct that the reverse path routing is taken care of by the > transaction state. Perhaps you could add one sentence about > the Answer routing with a reference to Section 2.8 of RFC 3588? > > I suppose using the Application ID for expressing support for > the feature is ok if that is the will of the working group. > > -Pete > > jouni korhonen wrote: >> Hi Peter, >> >> Thanks for the review. See my comments inline. >> >> >> On Aug 3, 2009, at 9:17 PM, McCann Peter-A001034 wrote: >> >>> I have been selected as the General Area Review Team (Gen-ART) >>> reviewer for this draft (for background on Gen-ART, please see >>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>> >>> Please resolve these comments along with any other Last Call >>> comments you may receive. >>> >>> Document: draft-ietf-dime-nai-routing-02 >>> Reviewer: Pete McCann >>> Review Date: 2009-08-03 >>> IETF LC End Date: 2009-08-04 >>> IESG Telechat date: unknown >>> >>> Summary: Two major issues need discussion >>> >>> >>> Major issues: >>> >>> The draft seems to address only routing of Request commands. What >>> about Answers? Are Diameter proxies required to re-write the >> >> Answers follow the reverse path the request traversed. The answers >> are processed according to base RFC3588. >> >>> Origin-Realm and Origin-Host AVPs as the request gets routed? >> >> No. Both Origin-Realm and Origin-Host correspond to the entity that >> originated the request. >> >>> Are they required then to maintain state to map the responses back >>> to >>> the originating realm? The processing rules seem to strip off >> >> Not really. Intermediating agents only need to maintain a transaction >> state. This is the same as required for normal RFC3588 request-answer >> processing. >> >>> the decoration from the NAI; there might be a need for the home AAA >>> server to know the path that was taken through the network (routing >>> the Answer commands is only one possible reason). Maybe the >>> solution >>> is to provide a decorated Origin-Realm that is recomputed by each >>> hop. >> >> RFC3588 Route-Record AVP already provides this information. I see no >> reason to go any further here regarding to changes/enhancements to >> RFC3588 answer processing. >> >> >>>> >>>> 4.2. Ensuring Backwards Compatibility >>>> >>>> Implementations compliant to this specification MUST define a new >>>> Diameter application. This requirement is set to guarantee >>>> backwards compatibility with existing Diameter implementations, >>>> applications and deployments. Diameter agents not compliant with >>>> this specification will not advertise support for these new >>>> applications that implement the enhanced routing solution based on >>>> Decorated NAIs and will therefore be bypassed. >>> >>> This requirement troubles me; does this mean that every Diameter >>> application will need to define a whole set of Application-IDs, >>> based >>> on the cross-product of every feature that gets introduced? Maybe >>> this is a general problem with Diameter application versioning, and >>> it's too late to fix it. Is there a better way to somehow indicate >>> support for this feature? >> >> It indeed is a general issue with Diameter application versioning >> (some SDOs have introduced their own versioning schemes to avoid >> defining new applications for e.g. every new release). There was >> lengthy discussion of possible choices how to solve it for this I-D. >> Requiring a new application seemed to be the easiest way to get >> forward. Generally, one application can/should include several "new >> features" so the explosion on applications should not become a >> problem.. >> >>> >>> Minor issues: >>> >>> >>> Nits/editorial comments: >>> >>> End of Section 3: >>> >>>> [RFC5113] Section 2.3. also discusses NAI decoration related issues >>>> with EAP [RFC3748] in general. >>> Seems there is an extra period after "Section 2.3". Suggest >>> changing >>> the reference pointer to text, i.e., >>>> Section 2.3 of RFC5113 also discusses NAI decoration related issues >>>> with EAP [RFC3748] in general. >>> >>> Section 4.1: >>> >>>> an uniform >>> SHOULD BE: >>>> a uniform >>> >>> Section 6: >>>> In this case the NAS to the Diameter server AAA communication rely >>> on >>> SHOULD BE: >>>> In this case the NAS to Diameter server AAA communication relies on >> >> Thanks. Will fix these. >> >> Cheers, >> Jouni > From root@core3.amsl.com Wed Aug 19 01:30:02 2009 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 042213A6CC6; Wed, 19 Aug 2009 01:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090819083002.042213A6CC6@core3.amsl.com> Date: Wed, 19 Aug 2009 01:30:02 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-nai-routing-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: Wed, 19 Aug 2009 08:30: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 User-Name and Realm Based Request Routing Clarifications Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-nai-routing-03.txt Pages : 10 Date : 2009-08-19 This specification defines the behavior required of Diameter agents to route requests when the User-Name Attribute Value Pair contains a Network Access Identifier formatted with multiple realms. These multi-realm or "Decorated" Network Access Identifiers are used in order to force the routing of request messages through a predefined list of mediating realms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-nai-routing-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-nai-routing-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-19011711.I-D@ietf.org> --NextPart-- From nrs2712@gmail.com Wed Aug 19 10:29:54 2009 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 C47AF3A6BA3 for ; Wed, 19 Aug 2009 10:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 I3Rm7uWr6yo8 for ; Wed, 19 Aug 2009 10:29:53 -0700 (PDT) Received: from mail-px0-f171.google.com (mail-px0-f171.google.com [209.85.216.171]) by core3.amsl.com (Postfix) with ESMTP id D0FFA3A6B75 for ; Wed, 19 Aug 2009 10:29:53 -0700 (PDT) Received: by pxi1 with SMTP id 1so2907839pxi.31 for ; Wed, 19 Aug 2009 10:29:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=uPlq12e0w5T5Ugatt27ADCBUPi0Z/gghTXYpw0gJ5c4=; b=gWZgtpookIx7aOwV6Vfb7DALdovY9Q0ec1xp232JUUWKhe//yFJ+tcSNrH1vXzLgja hHM7IaE3mK8+8o+K1ba/bjVB3SD3HDjkyFtBw+Qb8GXbcwhrW1GbbGANQHI72nLOgw7n EoTc8Ewl+jQQBYOnbv1YfBl27b2gRHZRS+nso= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=irgm9GlPAWY2gi1SOQupAhaIdiN82YmbGPDUVE6/OMWxPfTUfI6v3vRCLNTJyaVBXY 2+ZvIf/4iqngcCobPdCC3uMsB8IN4jHIOaOcQRSuRaplcr86S9y0Iyfkz4KKbgTuULQJ baRkeKtj7Z5+nTtaBVczss50Wu9vNKqZBFNHg= MIME-Version: 1.0 Received: by 10.143.24.40 with SMTP id b40mr1399370wfj.0.1250702997814; Wed, 19 Aug 2009 10:29:57 -0700 (PDT) Date: Wed, 19 Aug 2009 22:59:57 +0530 Message-ID: <1bdcf2860908191029w5f5f528ah1096a75a6ad27a44@mail.gmail.com> From: Ravi To: dime@ietf.org Content-Type: multipart/alternative; boundary=001636e0b6e2e77eaf047181fbdf Subject: [Dime] Comment on draft-ietf-dime-capablities-update-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, 19 Aug 2009 17:29:54 -0000 --001636e0b6e2e77eaf047181fbdf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, I read the draft-ietf-dime-capablities-update-00.txt document and I have a comment regarding defining a new application for the purpose of capability updates. 1) Advertising the capabilities of a diameter node is the function of the diameter base protocol. IMO we need to do this in the scope of the diameter base protocol and not as a separate application 2) By way of defining a new application-id, a diameter node obtains the ability to know that a peer has the capability to receive a capabilities update message in the Open state. This function can be achieved by defining a new AVP in the CER. A new AVP can be defined called "Capabilities-Update-AVP". This can be defined as an optional AVP in the CER message. There is no need to set the "M" flag for this AVP. It takes two enumerated values "Supported", "UnSupported" Peer A sends a CER with "Capabilities-Update-AVP" set as "Supported". When peer B receives this AVP, there can be two possibilities 1) It understands this AVP and it can choose to respond with "Supported"/"UnSupported" depending on its intent to receive/publish a CER to/from the peer 2) It doesnt understand this AVP and hence it is ignored and a CEA is sent back without this AVP Both the peers get to know of each other's intent/capability to receive/publish a CER. Capability update is carried by using CER/CEA messages. To summarize, I feel that capabilities advertisement/update should belong to base protocol and not belong to diameter application scope. Ravi --001636e0b6e2e77eaf047181fbdf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,
=A0=A0I read the=A0draft-ietf-dime-capablities-update-00.txt docume= nt and I have a comment regarding defining a new application for the purpos= e of capability updates.

1) Advertising the capabi= lities of a diameter node is the function of the diameter base protocol. IM= O we need to do this in the scope of the diameter base protocol and not as = a separate application
2) By way of defining a new application-id, a diameter node obtains th= e ability to know that a peer has the capability to receive a capabilities = update message in the Open state. This function can be achieved by defining= a new AVP in the CER. A new AVP can be defined called "Capabilities-U= pdate-AVP". This can be defined as an optional AVP in the CER message.= There is no need to set the "M" flag for this AVP. It takes two = enumerated values "Supported", "UnSupported"

Peer A sends a CER with "Capabilities-Update-AVP&q= uot; set as "Supported". When peer B receives this AVP, there can= be two possibilities

1) It understands this AVP a= nd it can choose to respond with "Supported"/"UnSupported&qu= ot; depending on its intent to receive/publish a CER to/from the peer
2) It doesnt understand this AVP and hence it is ignored and a CEA is = sent back without this AVP

Both the peers get to k= now of each other's intent/capability to receive/publish a CER.
Capability update is carried by using CER/CEA messages.

=
To summarize, I feel that capabilities advertisement/update shou= ld belong to base protocol and not belong to diameter application scope.

Ravi
--001636e0b6e2e77eaf047181fbdf-- From subashtc@cisco.com Wed Aug 19 22:12:01 2009 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 CEAB53A6B25 for ; Wed, 19 Aug 2009 22:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 aw8JQN8PMqEI for ; Wed, 19 Aug 2009 22:11:59 -0700 (PDT) Received: from syd-iport-2.cisco.com (syd-iport-2.cisco.com [64.104.193.197]) by core3.amsl.com (Postfix) with ESMTP id 30E793A69D0 for ; Wed, 19 Aug 2009 22:11:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHd4jEoKS+eh/2dsb2JhbACCJy+5P4gvkUYFhBqCMQ X-IronPort-AV: E=Sophos;i="4.43,412,1246838400"; d="scan'208,217";a="56786029" Received: from hkg-dkim-1.cisco.com ([10.75.231.161]) by syd-iport-2.cisco.com with ESMTP; 20 Aug 2009 05:11:54 +0000 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7K5BrMW017957; Thu, 20 Aug 2009 13:11:53 +0800 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7K5BTfp027056; Thu, 20 Aug 2009 05:11:52 GMT Received: from xmb-bgl-41b.cisco.com ([72.163.129.217]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Aug 2009 10:41:37 +0530 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_01CA2154.B21AABA7" Date: Thu, 20 Aug 2009 10:41:37 +0530 Message-ID: <454A16E4DA86094EB66BB2C1DBBBC018954081@XMB-BGL-41B.cisco.com> In-Reply-To: <1bdcf2860908191029w5f5f528ah1096a75a6ad27a44@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Comment on draft-ietf-dime-capablities-update-00.txt Thread-Index: Acog8rK04cWeihceQdKtMxzYVXz/7wAYPjUQ References: <1bdcf2860908191029w5f5f528ah1096a75a6ad27a44@mail.gmail.com> From: "Subash Comerica (subashtc)" To: "Ravi" , X-OriginalArrivalTime: 20 Aug 2009 05:11:37.0979 (UTC) FILETIME=[B1F0ACB0:01CA2154] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6827; t=1250745113; x=1251609113; c=relaxed/simple; s=hkgdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=subashtc@cisco.com; z=From:=20=22Subash=20Comerica=20(subashtc)=22=20 |Subject:=20RE=3A=20[Dime]=20Comment=20on=20draft-ietf-dime -capablities-update-00.txt |Sender:=20; bh=mhhYweHSiwrDfY8g930C2yvVtwD/oPWtzcXjrhYEU1o=; b=hZxuAT2h8mSm/VhZ0Fx+yAtujn0aMcAWMepJ6Ue+svIH6kjT33xzqlmZIB hWO19F4tDb/BPHCgLvJMaoqFS627zu970MIkZwtrz4sLRs/sYXIxKD9vWLqo I7X/9cncCNkzpQR53TNP7JvOrlZ9ldfcI5WBQQlu2FhLV6owGEVRE=; Authentication-Results: hkg-dkim-1; header.From=subashtc@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim1002 verified; ); Subject: Re: [Dime] Comment on draft-ietf-dime-capablities-update-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, 20 Aug 2009 05:12:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA2154.B21AABA7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ravi, I guess the intent here is to support dynamically changing the capabilities. I believe RFC 3588 also talks about the state machine where if the peer state is I-open(or R-open) and receives a CER, it processes the CER and sends a CEA and still remains in I-open(or R-open) state. So I agree with you that it is doable as an optional AVP in CER itself. =20 Thanks & Regards, Subash Changing the Way We Live, Work, Play and Learn =20 ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Ravi Sent: Wednesday, August 19, 2009 11:00 PM To: dime@ietf.org Subject: [Dime] Comment on draft-ietf-dime-capablities-update-00.txt =09 =09 Hi,=20 I read the draft-ietf-dime-capablities-update-00.txt document and I have a comment regarding defining a new application for the purpose of capability updates. 1) Advertising the capabilities of a diameter node is the function of the diameter base protocol. IMO we need to do this in the scope of the diameter base protocol and not as a separate application 2) By way of defining a new application-id, a diameter node obtains the ability to know that a peer has the capability to receive a capabilities update message in the Open state. This function can be achieved by defining a new AVP in the CER. A new AVP can be defined called "Capabilities-Update-AVP". This can be defined as an optional AVP in the CER message. There is no need to set the "M" flag for this AVP. It takes two enumerated values "Supported", "UnSupported" Peer A sends a CER with "Capabilities-Update-AVP" set as "Supported". When peer B receives this AVP, there can be two possibilities 1) It understands this AVP and it can choose to respond with "Supported"/"UnSupported" depending on its intent to receive/publish a CER to/from the peer 2) It doesnt understand this AVP and hence it is ignored and a CEA is sent back without this AVP Both the peers get to know of each other's intent/capability to receive/publish a CER. Capability update is carried by using CER/CEA messages. To summarize, I feel that capabilities advertisement/update should belong to base protocol and not belong to diameter application scope. Ravi ------_=_NextPart_001_01CA2154.B21AABA7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Ravi,
    I guess the intent here is to = support=20 dynamically changing the capabilities.
    I believe RFC 3588 also talks = about the=20 state machine where if the peer state is I-open(or R-open) and = receives a=20 CER, it processes the CER and sends a CEA and still remains in I-open(or = R-open) state.
    So I agree with you that it is = doable as an=20 optional AVP in CER itself.
 
Thanks = &=20 Regards,
Subash
Changing the Way We Live, Work, Play = and=20 Learn
 

From: dime-bounces@ietf.org=20 [mailto:dime-bounces@ietf.org] On Behalf Of = Ravi
Sent:=20 Wednesday, August 19, 2009 11:00 PM
To:=20 dime@ietf.org
Subject: [Dime] Comment on=20 draft-ietf-dime-capablities-update-00.txt

Hi,
  I read = the draft-ietf-dime-capablities-update-00.txt=20 document and I have a comment regarding defining a new application for = the=20 purpose of capability updates.

1) Advertising the capabilities of a diameter node is the = function of the=20 diameter base protocol. IMO we need to do this in the scope of the = diameter=20 base protocol and not as a separate application
2) By way of defining a new application-id, a diameter node = obtains the=20 ability to know that a peer has the capability to receive a = capabilities=20 update message in the Open state. This function can be achieved by = defining a=20 new AVP in the CER. A new AVP can be defined called = "Capabilities-Update-AVP".=20 This can be defined as an optional AVP in the CER message. There is no = need to=20 set the "M" flag for this AVP. It takes two enumerated values = "Supported",=20 "UnSupported"

Peer A sends a CER with "Capabilities-Update-AVP" set as = "Supported".=20 When peer B receives this AVP, there can be two possibilities

1) It understands this AVP and it can choose to respond with=20 "Supported"/"UnSupported" depending on its intent to receive/publish a = CER=20 to/from the peer
2) It doesnt understand this AVP and hence it is ignored and a = CEA is=20 sent back without this AVP

Both the peers get to know of each other's intent/capability to=20 receive/publish a CER.
Capability update is carried by using CER/CEA messages.

To summarize, I feel that capabilities advertisement/update = should belong=20 to base protocol and not belong to diameter application scope.

Ravi
------_=_NextPart_001_01CA2154.B21AABA7-- From vfajardo@research.telcordia.com Thu Aug 20 05:46:27 2009 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 751773A67B5 for ; Thu, 20 Aug 2009 05:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[AWL=0.577, 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 b6O8kdXe3p2j for ; Thu, 20 Aug 2009 05:46:21 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id 914E83A6E9E for ; Thu, 20 Aug 2009 05:46:20 -0700 (PDT) Received: from fajardov1 (vpntnlB33.research.telcordia.com [128.96.59.33]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id n7KCkN5m001478; Thu, 20 Aug 2009 08:46:23 -0400 (EDT) From: "Victor Fajardo" To: "'Subash Comerica \(subashtc\)'" , "'Ravi'" , References: <1bdcf2860908191029w5f5f528ah1096a75a6ad27a44@mail.gmail.com> <454A16E4DA86094EB66BB2C1DBBBC018954081@XMB-BGL-41B.cisco.com> In-Reply-To: <454A16E4DA86094EB66BB2C1DBBBC018954081@XMB-BGL-41B.cisco.com> Date: Thu, 20 Aug 2009 08:46:23 -0400 Organization: Applied Research, Telcordia Technologies Message-ID: <00e101ca2194$399409c0$acbc1d40$@telcordia.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E2_01CA2172.B28269C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acog8rK04cWeihceQdKtMxzYVXz/7wAYPjUQAA7WfTA= Content-Language: en-us Subject: Re: [Dime] Comment on draft-ietf-dime-capablities-update-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: vfajardo@research.telcordia.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 12:46:27 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00E2_01CA2172.B28269C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Just to give you a background on why this draft exist: 1) We've gone through this discussion several IETF's ago and we realized that we are overloading CER/CEA in terms of context and use. 2) We did not want to introduce a new set of non-backward compatible semantics into CER/CEA just for the sake of updating. Check out the problem statement for this draft and also the thread: http://www.ietf.org/mail-archive/web/dime/current/msg02775.html Regards, victor From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Subash Comerica (subashtc) Sent: Thursday, August 20, 2009 1:12 AM To: Ravi; dime@ietf.org Subject: Re: [Dime] Comment on draft-ietf-dime-capablities-update-00.txt Hi Ravi, I guess the intent here is to support dynamically changing the capabilities. I believe RFC 3588 also talks about the state machine where if the peer state is I-open(or R-open) and receives a CER, it processes the CER and sends a CEA and still remains in I-open(or R-open) state. So I agree with you that it is doable as an optional AVP in CER itself. Thanks & Regards, Subash Changing the Way We Live, Work, Play and Learn _____ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Ravi Sent: Wednesday, August 19, 2009 11:00 PM To: dime@ietf.org Subject: [Dime] Comment on draft-ietf-dime-capablities-update-00.txt Hi, I read the draft-ietf-dime-capablities-update-00.txt document and I have a comment regarding defining a new application for the purpose of capability updates. 1) Advertising the capabilities of a diameter node is the function of the diameter base protocol. IMO we need to do this in the scope of the diameter base protocol and not as a separate application 2) By way of defining a new application-id, a diameter node obtains the ability to know that a peer has the capability to receive a capabilities update message in the Open state. This function can be achieved by defining a new AVP in the CER. A new AVP can be defined called "Capabilities-Update-AVP". This can be defined as an optional AVP in the CER message. There is no need to set the "M" flag for this AVP. It takes two enumerated values "Supported", "UnSupported" Peer A sends a CER with "Capabilities-Update-AVP" set as "Supported". When peer B receives this AVP, there can be two possibilities 1) It understands this AVP and it can choose to respond with "Supported"/"UnSupported" depending on its intent to receive/publish a CER to/from the peer 2) It doesnt understand this AVP and hence it is ignored and a CEA is sent back without this AVP Both the peers get to know of each other's intent/capability to receive/publish a CER. Capability update is carried by using CER/CEA messages. To summarize, I feel that capabilities advertisement/update should belong to base protocol and not belong to diameter application scope. Ravi ------=_NextPart_000_00E2_01CA2172.B28269C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Just to give you a background on why this draft exist: 1) = We’ve gone through this discussion several IETF’s ago and we realized = that we are overloading CER/CEA in terms of context and use. 2) We did not want = to introduce a new set of non-backward compatible semantics into CER/CEA = just for the sake of updating. Check out the problem statement for this draft and = also the thread: = http://www.ietf.org/mail-archive/web/dime/current/msg02775.html

 

Regards,

victor

 

 

From:= dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of = Subash Comerica (subashtc)
Sent: Thursday, August 20, 2009 1:12 AM
To: Ravi; dime@ietf.org
Subject: Re: [Dime] Comment on = draft-ietf-dime-capablities-update-00.txt

 

Hi Ravi,

    I guess the intent here is to support dynamically changing the capabilities.

    I believe RFC 3588 also talks about the = state machine where if the peer state is I-open(or R-open) and receives a = CER, it processes the CER and sends a CEA and still remains in I-open(or R-open) state.

    So I agree with you that it is doable as = an optional AVP in CER itself.

 

Thanks & Regards,

Subash

Changing the Way We Live, Work, Play and = Learn

 

 

From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Ravi
Sent: Wednesday, August 19, 2009 11:00 PM
To: dime@ietf.org
Subject: [Dime] Comment on = draft-ietf-dime-capablities-update-00.txt

Hi,

  I read the draft-ietf-dime-capablities-update-00.txt document and I have a comment regarding defining a new application for the purpose of = capability updates.

 

1) Advertising the capabilities of a diameter node = is the function of the diameter base protocol. IMO we need to do this in the = scope of the diameter base protocol and not as a separate = application

2) By way of defining a new application-id, a = diameter node obtains the ability to know that a peer has the capability to receive a capabilities update message in the Open state. This function can be = achieved by defining a new AVP in the CER. A new AVP can be defined called "Capabilities-Update-AVP". This can be defined as an optional = AVP in the CER message. There is no need to set the "M" flag for this = AVP. It takes two enumerated values "Supported", = "UnSupported"

 

Peer A sends a CER with = "Capabilities-Update-AVP" set as "Supported". When peer B receives this AVP, there can = be two possibilities

 

1) It understands this AVP and it can choose to = respond with "Supported"/"UnSupported" depending on its intent to receive/publish a CER to/from the peer

2) It doesnt understand this AVP and hence it is = ignored and a CEA is sent back without this AVP

 

Both the peers get to know of each other's = intent/capability to receive/publish a CER.

Capability update is carried by using CER/CEA = messages.

 

To summarize, I feel that capabilities = advertisement/update should belong to base protocol and not belong to diameter application = scope.

 

Ravi

------=_NextPart_000_00E2_01CA2172.B28269C0-- From nrs2712@gmail.com Thu Aug 20 10:30:51 2009 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 375C028C118 for ; Thu, 20 Aug 2009 10:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 auAsDnlqyMyV for ; Thu, 20 Aug 2009 10:30:49 -0700 (PDT) Received: from mail-px0-f171.google.com (mail-px0-f171.google.com [209.85.216.171]) by core3.amsl.com (Postfix) with ESMTP id 50C343A6B22 for ; Thu, 20 Aug 2009 10:30:49 -0700 (PDT) Received: by pxi1 with SMTP id 1so3758760pxi.31 for ; Thu, 20 Aug 2009 10:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=/LtUpHf/j2Bx1TT6ZXyZM4W5bms4S/MWTSinRK5WJbE=; b=DfvRTrSM9D3vouVOd9cJkWryUEYMV1hlhJlOQ73AiW8DG7g2tzfL95cQ7Uvs/tWYuv SSQonFrlxxjgKFTgFkHUqRnkZATWB4+FgDTo/73Bw241thgAxREBo2RVVdEXOhkVFNC8 2dK3gIaiG8HsAVxqJF3L7ZPoQ/Ogu6vxf38xY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cUuaK9x9lRhNak5ozr72hyd6pGPV3Zem5HsY1D3SWybJUDGixt12FlOYaXgm38nige LpNEUCjxMJvP5Acz0G1WLeI7XgvX7Is6WXcpZ/9wPJOBF1bi1LxzFFXaU9BTfV7zOZP6 O98HZbYs/KEd1Ibk2oELVbGF8vHYXFwAixRhM= MIME-Version: 1.0 Received: by 10.142.152.1 with SMTP id z1mr1290wfd.322.1250789442845; Thu, 20 Aug 2009 10:30:42 -0700 (PDT) In-Reply-To: <00e101ca2194$399409c0$acbc1d40$@telcordia.com> References: <1bdcf2860908191029w5f5f528ah1096a75a6ad27a44@mail.gmail.com> <454A16E4DA86094EB66BB2C1DBBBC018954081@XMB-BGL-41B.cisco.com> <00e101ca2194$399409c0$acbc1d40$@telcordia.com> Date: Thu, 20 Aug 2009 23:00:42 +0530 Message-ID: <1bdcf2860908201030p2f9f0a5dr80f8a24a93f16299@mail.gmail.com> From: Ravi To: vfajardo@research.telcordia.com Content-Type: multipart/alternative; boundary=000e0cd328a06dfc130471961c9b Cc: dime@ietf.org Subject: Re: [Dime] Comment on draft-ietf-dime-capablities-update-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, 20 Aug 2009 17:30:51 -0000 --000e0cd328a06dfc130471961c9b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, This is my view of the diameter core protocol and applications _________________________ ________________________________ | | | | | IETF Applications | | 3GPP Applications | |(accounting, credit control,...) | | (Rf, Ro, Gx, Cx, Dx ....) | |_________________________| |_______________________________ | ______________________________________________________________________ | | | Core Protoco= l | |______________________________________________________________________| 1) The core protocol is responsible for transport establishment(Peer state machine), connection supervision(watch dog), capabilities exchange, routing= , peer discovery. Capability exchange is one of the main functions of the cor= e protocol. 2) The applications are responsible for functions like NASREQ, credit control, accounting and maintaining their state machines (auth, accounting or credit control). IMO creating an application for the purpose of capability exchange is probably not a very good idea because it moves a core protocol function int= o the application scope. I read the e-mail thread which you have referred regarding previous discussions and this is my opinion The concern seems to be about how the CEA should be handled. Whether the peer receiving the CEA should update the peer capabilities or not upon receiving a result code of DIAMETER_SUCCESS in the CEA. Hence in the draft, the CUA has only few AVPs like Result Code and it does not have the application ids of the peer. The rationale is that both the peers intending to advertise their updated capabilities simultaneously is a rare occurrence= . Now, coming to my view 1) If both the peers advertising their updated capabilities simultaneously is a rare occurrence then actually it does not matter if the peer sends the application-ids in the CEA because there is no change in supported applications. A simple check to verify any change from the previous supported applications of the peer will suffice. 2) Assuming that rarest of the rare instance happens where there is a near simultaneous upgrade of both the peer and a CER/CEA exchange is triggered. Then both the peers need to match each other's capabilities. This does not change for the case we use CUR/CUA. 3) I presume that the backward compatibility issue arises from the fact tha= t RFC 3588 mentions about CER/CEA exchange in open state but does not clearly specify what should be done by the peers in this case. CER/CEA exchange is deprecated in the 3588 bis and this new mechanism of CUR/CUA is being proposed. I feel the same can be achieved using a new AVP in the CER. Am I overlookin= g something? Ravi On Thu, Aug 20, 2009 at 6:16 PM, Victor Fajardo < vfajardo@research.telcordia.com> wrote: > Hi, > > > > Just to give you a background on why this draft exist: 1) We=92ve gone > through this discussion several IETF=92s ago and we realized that we are > overloading CER/CEA in terms of context and use. 2) We did not want to > introduce a new set of non-backward compatible semantics into CER/CEA jus= t > for the sake of updating. Check out the problem statement for this draft = and > also the thread: > http://www.ietf.org/mail-archive/web/dime/current/msg02775.html > > > > Regards, > > victor > > > > > > *From:* dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] *On Behalf O= f > *Subash Comerica (subashtc) > *Sent:* Thursday, August 20, 2009 1:12 AM > *To:* Ravi; dime@ietf.org > *Subject:* Re: [Dime] Comment on draft-ietf-dime-capablities-update-00.tx= t > > > > Hi Ravi, > > I guess the intent here is to support dynamically changing the > capabilities. > > I believe RFC 3588 also talks about the state machine where if the pe= er > state is I-open(or R-open) and receives a CER, it processes the CER and > sends a CEA and still remains in I-open(or R-open) state. > > So I agree with you that it is doable as an optional AVP in CER itsel= f. > > > > Thanks & Regards, > > Subash > > *Changing the Way We Live, Work, Play and Learn* > > > > > ------------------------------ > > *From:* dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] *On Behalf O= f > *Ravi > *Sent:* Wednesday, August 19, 2009 11:00 PM > *To:* dime@ietf.org > *Subject:* [Dime] Comment on draft-ietf-dime-capablities-update-00.txt > > Hi, > > I read the draft-ietf-dime-capablities-update-00.txt document and I hav= e > a comment regarding defining a new application for the purpose of capabil= ity > updates. > > > > 1) Advertising the capabilities of a diameter node is the function of the > diameter base protocol. IMO we need to do this in the scope of the diamet= er > base protocol and not as a separate application > > 2) By way of defining a new application-id, a diameter node obtains the > ability to know that a peer has the capability to receive a capabilities > update message in the Open state. This function can be achieved by defini= ng > a new AVP in the CER. A new AVP can be defined called > "Capabilities-Update-AVP". This can be defined as an optional AVP in the = CER > message. There is no need to set the "M" flag for this AVP. It takes two > enumerated values "Supported", "UnSupported" > > > > Peer A sends a CER with "Capabilities-Update-AVP" set as "Supported". Whe= n > peer B receives this AVP, there can be two possibilities > > > > 1) It understands this AVP and it can choose to respond with > "Supported"/"UnSupported" depending on its intent to receive/publish a CE= R > to/from the peer > > 2) It doesnt understand this AVP and hence it is ignored and a CEA is sen= t > back without this AVP > > > > Both the peers get to know of each other's intent/capability to > receive/publish a CER. > > Capability update is carried by using CER/CEA messages. > > > > To summarize, I feel that capabilities advertisement/update should belong > to base protocol and not belong to diameter application scope. > > > > Ravi > > --000e0cd328a06dfc130471961c9b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi,
=A0This is my view of the diameter core protocol and applications

=A0=A0 =A0 =A0 =A0 =A0 _______________________= __ =A0 =A0 =A0 =A0 =A0 =A0________________________________
=A0=A0= =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 |=A0=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 |
=A0=A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0IETF Applications =A0 =A0 = =A0 =A0| =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A03GPP Applications =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0=A0 =A0 =A0 =A0 =A0|(accounting,= credit control,...) | =A0 =A0 =A0 =A0 =A0 | =A0 =A0(Rf, Ro, Gx, Cx, Dx ...= .) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0=A0 =A0 =A0 =A0 =A0|_________________________| =A0 =A0 =A0 =A0 =A0 = |_______________________________ |

=A0= =A0 =A0 =A0 =A0 =A0 _______________________________________________________= _______________
=A0=A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0=A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Core Protocol =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0|
=A0=A0 =A0 =A0 =A0 =A0|________________________= ______________________________________________|


1) The core protocol is responsible for = transport establishment(Peer state machine), connection supervision(watch d= og), capabilities exchange, routing, peer discovery.=A0Capability exchange = is one of the main functions of the core protocol.

2) The applications are responsible for functions like = NASREQ, credit control, accounting and maintaining their state machines (au= th, accounting or =A0credit control).

IMO creating= an application for the purpose of capability exchange is probably not a ve= ry good idea because it moves a core protocol function into the application= scope.

I read the e-mail thread which you have referred regard= ing previous discussions and this is my opinion

Th= e concern seems to be about how the CEA should be handled.=A0Whether the pe= er receiving the CEA should update the peer capabilities or not upon receiv= ing a result code of DIAMETER_SUCCESS in the CEA.=A0Hence in the draft, the= CUA has only few AVPs like Result Code and it does not have the applicatio= n ids of the peer. The rationale is that both the peers intending to advert= ise their updated capabilities simultaneously is a rare=A0occurrence.

Now, coming to my view

1) If b= oth the peers advertising their updated capabilities simultaneously is a ra= re occurrence then actually it does not matter if the peer sends the applic= ation-ids in the CEA because there is no change in supported applications. = A simple check to verify any change from the previous supported application= s of the peer will suffice.
2) Assuming that rarest of the rare instance happens where there is a = near simultaneous upgrade of both the peer and a CER/CEA exchange is trigge= red. Then both the peers need to match each other's capabilities. This = does not change for the case we use CUR/CUA.
3) I presume that the backward compatibility issue arises from the fac= t that RFC 3588 mentions about CER/CEA exchange in open state but does not = clearly specify what should be done by the peers in this case. CER/CEA exch= ange is deprecated in the 3588 bis and this new mechanism of CUR/CUA is bei= ng proposed.
I feel the same can be achieved using a new AVP in the CER. Am I overl= ooking something?

Ravi

On Thu, Aug 20, 2009 at 6:16 PM, Victor Fajardo <vfajardo@resear= ch.telcordia.com> wrote:

Hi,

=A0

Just to give you a backgr= ound on why this draft exist: 1) We=92ve gone through this discussion several IETF=92s ago and we realized that we are overloading CER/CEA in terms of context and use. 2) We did not want to introduce a new set of non-backward compatible semantics into CER/CEA just = for the sake of updating. Check out the problem statement for this draft and al= so the thread: http://www.ietf.org/mail-archive/web/dime/cu= rrent/msg02775.html

=A0

Regards,

victor

=A0

=A0

From: dime-bounces@iet= f.org [mailto:dime-bounces@ietf.org] On Behalf Of Subash Comerica (subashtc)
Sent: Thursday, August 20, 2009 1:12 AM
To: Ravi; dime@ie= tf.org
Subject: Re: [Dime] Comment on draft-ietf-dime-capablities-update-00= .txt

=A0

Hi Ravi,

=A0=A0=A0 I guess the intent= here is to support dynamically changing the capabilities.

=A0=A0=A0 I believe RFC 3588= also talks about the state machine where if the peer state is I-open(or R-open)=A0and receives a CER, it processes the CER and sends a CEA and still remains in I-open(or R-open)=A0state.

=A0=A0=A0 So I agree with yo= u that it is doable as an optional AVP in CER itself.

=A0

Thanks & Regards,=

Subash

Changing the Way We Live, Work, Play and Learn

=A0

=A0

From:= dime-bounces@ietf.org [mailto:dime-bou= nces@ietf.org] On Behalf Of Ravi
Sent: Wednesday, August 19, 2009 11:00 PM
To: dime@ietf.org=
Subject: [Dime] Comment on draft-ietf-dime-capablities-update-00.txt=

Hi,

=A0=A0I read the=A0draft-ietf-dime-capablities-update-00.txt document and I have a comment regarding defining a new application for the purpose of capability updates.

=A0

1) Advertising the capabilities of a diameter node is the function of the diameter base protocol. IMO we need to do this in the scope= of the diameter base protocol and not as a separate application

2) By way of defining a new application-id, a diameter node obtains the ability to know that a peer has the capability to receive a capabilities update message in the Open state. This function can be achieve= d by defining a new AVP in the CER. A new AVP can be defined called "Capabilities-Update-AVP". This can be defined as an optional AVP= in the CER message. There is no need to set the "M" flag for this AV= P. It takes two enumerated values "Supported", "UnSupported&quo= t;

=A0

Peer A sends a CER with "Capabilities-Update-AVP" set as "Supported". When peer B receives this AVP, there can be t= wo possibilities

=A0

1) It understands this AVP and it can choose to respond with "Supported"/"UnSupported" depending on its intent to receive/publish a CER to/from the peer

2) It doesnt understand this AVP and hence it is ignored and a CEA is sent back without this AVP

=A0

Both the peers get to know of each other's intent/capability to receive/publish a CER.

Capability update is carried by using CER/CEA messages.

=A0

To summarize, I feel that capabilities advertisement/update should belong to base protocol and not belong to diameter application scope= .

=A0

Ravi


--000e0cd328a06dfc130471961c9b-- From rfc-editor@rfc-editor.org Thu Aug 20 17:02:17 2009 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 17D653A6A2E; Thu, 20 Aug 2009 17:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.757 X-Spam-Level: X-Spam-Status: No, score=-16.757 tagged_above=-999 required=5 tests=[AWL=0.242, 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 VEg7Aw7LTpiT; Thu, 20 Aug 2009 17:02:16 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 29A483A6969; Thu, 20 Aug 2009 17:02:16 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 9C33030CE32; Thu, 20 Aug 2009 17:02:11 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090821000211.9C33030CE32@bosco.isi.edu> Date: Thu, 20 Aug 2009 17:02:11 -0700 (PDT) Cc: dime@ietf.org, rfc-editor@rfc-editor.org Subject: [Dime] RFC 5624 on Quality of Service Parameters for Usage with Diameter 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, 21 Aug 2009 00:02:17 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5624 Title: Quality of Service Parameters for Usage with Diameter Author: J. Korhonen, Ed., H. Tschofenig, E. Davies Status: Standards Track Date: August 2009 Mailbox: jouni.korhonen@nsn.com, Hannes.Tschofenig@gmx.net, elwynd@dial.pipex.com Pages: 12 Characters: 23326 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dime-qos-parameters-11.txt URL: http://www.rfc-editor.org/rfc/rfc5624.txt This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within Diameter. The defined QoS information includes data traffic parameters for describing a token bucket filter, a bandwidth parameter, and a per-hop behavior class object. [STANDARDS TRACK] This document is a product of the Diameter Maintenance 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 USC/Information Sciences Institute From vfajardo@research.telcordia.com Fri Aug 21 05:49:32 2009 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 E65343A6DE4 for ; Fri, 21 Aug 2009 05:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.069 X-Spam-Level: X-Spam-Status: No, score=-2.069 tagged_above=-999 required=5 tests=[AWL=0.529, 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 W4v6iRQFfjGw for ; Fri, 21 Aug 2009 05:49:27 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id E395D28C160 for ; Fri, 21 Aug 2009 05:49:26 -0700 (PDT) Received: from fajardov1 (vpntnlB33.research.telcordia.com [128.96.59.33]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id n7LCmuZK026541; Fri, 21 Aug 2009 08:48:57 -0400 (EDT) From: "Victor Fajardo" To: "'Ravi'" References: <1bdcf2860908191029w5f5f528ah1096a75a6ad27a44@mail.gmail.com> <454A16E4DA86094EB66BB2C1DBBBC018954081@XMB-BGL-41B.cisco.com> <00e101ca2194$399409c0$acbc1d40$@telcordia.com> <1bdcf2860908201030p2f9f0a5dr80f8a24a93f16299@mail.gmail.com> In-Reply-To: <1bdcf2860908201030p2f9f0a5dr80f8a24a93f16299@mail.gmail.com> Date: Fri, 21 Aug 2009 08:48:57 -0400 Organization: Applied Research, Telcordia Technologies Message-ID: <010701ca225d$bf5daa10$3e18fe30$@telcordia.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0108_01CA223C.384C0A10" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acohu/LTFV9oeT66To+8Ta//CZmQ7gAn5apg Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Comment on draft-ietf-dime-capablities-update-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: vfajardo@research.telcordia.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 12:49:33 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0108_01CA223C.384C0A10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Ravi, I understand the description you posted below and it is reasonable. But I think we maybe missing a point here. It's not that we cannot do option 1, 2 or 3 below (technically we can do anything we want to and convolute CER/CEA to our hearts content). The point is we want a clean solution that does not violate our own guidelines in overloading a command. For me, your option 3 below is a classic example of command overloading. Your putting a lot of required contextual behavior based on the presence/absence of an AVP . something our guideline says we should avoid doing. Regards, victor Now, coming to my view 1) If both the peers advertising their updated capabilities simultaneously is a rare occurrence then actually it does not matter if the peer sends the application-ids in the CEA because there is no change in supported applications. A simple check to verify any change from the previous supported applications of the peer will suffice. 2) Assuming that rarest of the rare instance happens where there is a near simultaneous upgrade of both the peer and a CER/CEA exchange is triggered. Then both the peers need to match each other's capabilities. This does not change for the case we use CUR/CUA. 3) I presume that the backward compatibility issue arises from the fact that RFC 3588 mentions about CER/CEA exchange in open state but does not clearly specify what should be done by the peers in this case. CER/CEA exchange is deprecated in the 3588 bis and this new mechanism of CUR/CUA is being proposed. I feel the same can be achieved using a new AVP in the CER. Am I overlooking something? Ravi On Thu, Aug 20, 2009 at 6:16 PM, Victor Fajardo wrote: Hi, Just to give you a background on why this draft exist: 1) We've gone through this discussion several IETF's ago and we realized that we are overloading CER/CEA in terms of context and use. 2) We did not want to introduce a new set of non-backward compatible semantics into CER/CEA just for the sake of updating. Check out the problem statement for this draft and also the thread: http://www.ietf.org/mail-archive/web/dime/current/msg02775.html Regards, victor From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Subash Comerica (subashtc) Sent: Thursday, August 20, 2009 1:12 AM To: Ravi; dime@ietf.org Subject: Re: [Dime] Comment on draft-ietf-dime-capablities-update-00.txt Hi Ravi, I guess the intent here is to support dynamically changing the capabilities. I believe RFC 3588 also talks about the state machine where if the peer state is I-open(or R-open) and receives a CER, it processes the CER and sends a CEA and still remains in I-open(or R-open) state. So I agree with you that it is doable as an optional AVP in CER itself. Thanks & Regards, Subash Changing the Way We Live, Work, Play and Learn _____ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Ravi Sent: Wednesday, August 19, 2009 11:00 PM To: dime@ietf.org Subject: [Dime] Comment on draft-ietf-dime-capablities-update-00.txt Hi, I read the draft-ietf-dime-capablities-update-00.txt document and I have a comment regarding defining a new application for the purpose of capability updates. 1) Advertising the capabilities of a diameter node is the function of the diameter base protocol. IMO we need to do this in the scope of the diameter base protocol and not as a separate application 2) By way of defining a new application-id, a diameter node obtains the ability to know that a peer has the capability to receive a capabilities update message in the Open state. This function can be achieved by defining a new AVP in the CER. A new AVP can be defined called "Capabilities-Update-AVP". This can be defined as an optional AVP in the CER message. There is no need to set the "M" flag for this AVP. It takes two enumerated values "Supported", "UnSupported" Peer A sends a CER with "Capabilities-Update-AVP" set as "Supported". When peer B receives this AVP, there can be two possibilities 1) It understands this AVP and it can choose to respond with "Supported"/"UnSupported" depending on its intent to receive/publish a CER to/from the peer 2) It doesnt understand this AVP and hence it is ignored and a CEA is sent back without this AVP Both the peers get to know of each other's intent/capability to receive/publish a CER. Capability update is carried by using CER/CEA messages. To summarize, I feel that capabilities advertisement/update should belong to base protocol and not belong to diameter application scope. Ravi ------=_NextPart_000_0108_01CA223C.384C0A10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ravi,

 

I understand the description you posted below and it is reasonable. But I think we maybe missing a point here. It’s not = that we cannot do option 1, 2 or 3 below (technically we can do anything we want = to and convolute CER/CEA to our hearts content). The point is we want a clean = solution that does not violate our own guidelines in overloading a command. For = me, your option 3 below is a classic example of command overloading. Your putting = a lot of required contextual behavior based on the presence/absence of an AVP = … something our guideline says we should avoid = doing.

 

Regards,

victor

 

Now, coming to my view

 

1) If both the peers advertising their updated = capabilities simultaneously is a rare occurrence then actually it does not matter if = the peer sends the application-ids in the CEA because there is no change in supported applications. A simple check to verify any change from the = previous supported applications of the peer will suffice.

2) Assuming that rarest of the rare instance = happens where there is a near simultaneous upgrade of both the peer and a CER/CEA = exchange is triggered. Then both the peers need to match each other's capabilities. = This does not change for the case we use CUR/CUA.

3) I presume that the backward compatibility issue = arises from the fact that RFC 3588 mentions about CER/CEA exchange in open = state but does not clearly specify what should be done by the peers in this case. = CER/CEA exchange is deprecated in the 3588 bis and this new mechanism of CUR/CUA = is being proposed.

I feel the same can be achieved using a new AVP in = the CER. Am I overlooking something?

 

Ravi

 

On Thu, Aug 20, 2009 at 6:16 PM, Victor Fajardo = <vfajardo@research.telcord= ia.com> wrote:

Hi,

 

Just to give you a = background on why this draft exist: 1) We’ve gone through this discussion = several IETF’s ago and we realized that we are overloading CER/CEA in = terms of context and use. 2) We did not want to introduce a new set of non-backward = compatible semantics into CER/CEA just for the sake of updating. Check out the = problem statement for this draft and also the thread: http://www.ietf.org/mail-archive/web/dime/current/msg02= 775.html

 

Regards,

victor

 

 

From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Subash Comerica (subashtc)
Sent: Thursday, August 20, 2009 1:12 AM
To: Ravi; dime@ietf.org
Subject: Re: [Dime] Comment on = draft-ietf-dime-capablities-update-00.txt

 

Hi = Ravi,

    I = guess the intent here is to support dynamically changing the = capabilities.

    I = believe RFC 3588 also talks about the state machine where if the peer state is = I-open(or R-open) and receives a CER, it processes the CER and sends a CEA = and still remains in I-open(or R-open) state.

    So I = agree with you that it is doable as an optional AVP in CER = itself.

 

Thanks & = Regards,

Subash

Changing the Way We Live, Work, Play and = Learn

 

 

From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Ravi
Sent: Wednesday, August 19, 2009 11:00 PM
To: dime@ietf.org
Subject: [Dime] Comment on = draft-ietf-dime-capablities-update-00.txt

Hi,

  I read the draft-ietf-dime-capablities-update-00.txt document and I have a comment regarding defining a new application for = the purpose of capability updates.

 

1) Advertising the capabilities of a diameter node is the function of = the diameter base protocol. IMO we need to do this in the scope of the = diameter base protocol and not as a separate application

2) By way of defining a new application-id, a diameter node obtains = the ability to know that a peer has the capability to receive a capabilities = update message in the Open state. This function can be achieved by defining a = new AVP in the CER. A new AVP can be defined called "Capabilities-Update-AVP". This can be defined as an optional = AVP in the CER message. There is no need to set the "M" flag for this = AVP. It takes two enumerated values "Supported", = "UnSupported"

 

Peer A sends a CER with "Capabilities-Update-AVP" set as "Supported". When peer B receives this AVP, there can be two = possibilities

 

1) It understands this AVP and it can choose to respond with "Supported"/"UnSupported" depending on its intent to receive/publish a CER to/from the peer

2) It doesnt understand this AVP and hence it is ignored and a CEA is = sent back without this AVP

 

Both the peers get to know of each other's intent/capability to receive/publish a CER.

Capability update is carried by using CER/CEA = messages.

 

To summarize, I feel that capabilities advertisement/update should = belong to base protocol and not belong to diameter application = scope.

 

Ravi

 

------=_NextPart_000_0108_01CA223C.384C0A10-- From nrs2712@gmail.com Sun Aug 23 10:59:56 2009 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 E302128C0E0 for ; Sun, 23 Aug 2009 10:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 nx7986OOmUAF for ; Sun, 23 Aug 2009 10:59:55 -0700 (PDT) Received: from mail-pz0-f174.google.com (mail-pz0-f174.google.com [209.85.222.174]) by core3.amsl.com (Postfix) with ESMTP id 197973A69FD for ; Sun, 23 Aug 2009 10:59:53 -0700 (PDT) Received: by pzk4 with SMTP id 4so595431pzk.29 for ; Sun, 23 Aug 2009 10:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Krigj/1AHMmM4v5XjbfxNj4Gsk+g3Oc54T9wME/pIpo=; b=sZLNmokGlDgehMwaamiP1+3K/AqkdY6iwURweC1MnpEF6etJrxgIh09ZLty+MkuZFh NVJPRrPFDawt55enl6ysdtdDy4g1FP7kV2SScgihC4naZyIZYuABYdxHesI5Vit4bkjf c0Z8LT8riMrlPxnSUq/ivUEIPJ5htVjOkIxr4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bScrciWLqAgsimwQ6+hy/0eNDdceGR0z3/2QwfS1C8fXzYoU7Zh7lSOWSxUMc90c43 zCVVvTiDzltB21alNQPyOwhgHblpOZ3GXPs63rwPrXFT0uHTm0Ubv5G/V6vj19TAtLCV wh6DblgbwoIQpdB9nXmDH3xlZDz7zjiKXWfp8= MIME-Version: 1.0 Received: by 10.142.60.4 with SMTP id i4mr303740wfa.273.1251050395241; Sun, 23 Aug 2009 10:59:55 -0700 (PDT) In-Reply-To: <010701ca225d$bf5daa10$3e18fe30$@telcordia.com> References: <1bdcf2860908191029w5f5f528ah1096a75a6ad27a44@mail.gmail.com> <454A16E4DA86094EB66BB2C1DBBBC018954081@XMB-BGL-41B.cisco.com> <00e101ca2194$399409c0$acbc1d40$@telcordia.com> <1bdcf2860908201030p2f9f0a5dr80f8a24a93f16299@mail.gmail.com> <010701ca225d$bf5daa10$3e18fe30$@telcordia.com> Date: Sun, 23 Aug 2009 23:29:55 +0530 Message-ID: <1bdcf2860908231059i6f6a78a2kd48300c8fa7e72de@mail.gmail.com> From: Ravi To: vfajardo@research.telcordia.com Content-Type: multipart/alternative; boundary=0050450294eb678d010471d2decc Cc: dime@ietf.org Subject: Re: [Dime] Comment on draft-ietf-dime-capablities-update-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: Sun, 23 Aug 2009 17:59:57 -0000 --0050450294eb678d010471d2decc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Victor, Thanks for your response. I agree with your point that we need to have a clean solution and not overload a command. However I am not sure if I really agree with the point that we are overloading the CER command. We are talking about capabilities update here and I feel CER is th= e right command for this. In fact capabilities exchange in the open state was designated to be done using CER/CEA in RFC 3588. This is deprecated now because of various reasons. Having said that, I am not against defining a new command for this purpose. I feel we already have a command to achieve this and its scope is being restricted. We may however go ahead with this approach(defining a new command) if everyone thinks this is the best approach. I am not really convinced that we need to define a new application for the purpose of capabilities update. I feel that capabilities update MUST be don= e in the scope of "Diameter Common Messages" i.e. with appid =3D 0. I agree with you that we need to comply to the guideline while defining extensions to the protocol mechanism but I am not sure if we can ignore the protocol functional architecture altogether.(core protocol functions Vs application functions) If it is really difficult to come up with a clean solution in the current diameter version, we could take up this capabilities update mechanism in th= e Version 2 of Diameter base protocol. (There are some other ways of achievin= g this like defining a request type AVP which says Initial / Update. This can be discussed later) Your opinion is welcome. Ravi On Fri, Aug 21, 2009 at 6:18 PM, Victor Fajardo < vfajardo@research.telcordia.com> wrote: > Hi Ravi, > > > > I understand the description you posted below and it is reasonable. But I > think we maybe missing a point here. It=92s not that we cannot do option = 1, 2 > or 3 below (technically we can do anything we want to and convolute CER/C= EA > to our hearts content). The point is we want a clean solution that does n= ot > violate our own guidelines in overloading a command. For me, your option = 3 > below is a classic example of command overloading. Your putting a lot of > required contextual behavior based on the presence/absence of an AVP =85 > something our guideline says we should avoid doing. > > > > Regards, > > victor > > > > Now, coming to my view > > > > 1) If both the peers advertising their updated capabilities simultaneousl= y > is a rare occurrence then actually it does not matter if the peer sends t= he > application-ids in the CEA because there is no change in supported > applications. A simple check to verify any change from the previous > supported applications of the peer will suffice. > > 2) Assuming that rarest of the rare instance happens where there is a nea= r > simultaneous upgrade of both the peer and a CER/CEA exchange is triggered= . > Then both the peers need to match each other's capabilities. This does no= t > change for the case we use CUR/CUA. > > 3) I presume that the backward compatibility issue arises from the fact > that RFC 3588 mentions about CER/CEA exchange in open state but does not > clearly specify what should be done by the peers in this case. CER/CEA > exchange is deprecated in the 3588 bis and this new mechanism of CUR/CUA = is > being proposed. > > I feel the same can be achieved using a new AVP in the CER. Am I > overlooking something? > > > > Ravi > > > > On Thu, Aug 20, 2009 at 6:16 PM, Victor Fajardo < > vfajardo@research.telcordia.com> wrote: > > Hi, > > > > Just to give you a background on why this draft exist: 1) We=92ve gone > through this discussion several IETF=92s ago and we realized that we are > overloading CER/CEA in terms of context and use. 2) We did not want to > introduce a new set of non-backward compatible semantics into CER/CEA jus= t > for the sake of updating. Check out the problem statement for this draft = and > also the thread: > http://www.ietf.org/mail-archive/web/dime/current/msg02775.html > > > > Regards, > > victor > > > > > > *From:* dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] *On Behalf O= f > *Subash Comerica (subashtc) > *Sent:* Thursday, August 20, 2009 1:12 AM > *To:* Ravi; dime@ietf.org > *Subject:* Re: [Dime] Comment on draft-ietf-dime-capablities-update-00.tx= t > > > > Hi Ravi, > > I guess the intent here is to support dynamically changing the > capabilities. > > I believe RFC 3588 also talks about the state machine where if the pe= er > state is I-open(or R-open) and receives a CER, it processes the CER and > sends a CEA and still remains in I-open(or R-open) state. > > So I agree with you that it is doable as an optional AVP in CER itsel= f. > > > > Thanks & Regards, > > Subash > > *Changing the Way We Live, Work, Play and Learn* > > > > > ------------------------------ > > *From:* dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] *On Behalf O= f > *Ravi > *Sent:* Wednesday, August 19, 2009 11:00 PM > *To:* dime@ietf.org > *Subject:* [Dime] Comment on draft-ietf-dime-capablities-update-00.txt > > Hi, > > I read the draft-ietf-dime-capablities-update-00.txt document and I hav= e > a comment regarding defining a new application for the purpose of capabil= ity > updates. > > > > 1) Advertising the capabilities of a diameter node is the function of the > diameter base protocol. IMO we need to do this in the scope of the diamet= er > base protocol and not as a separate application > > 2) By way of defining a new application-id, a diameter node obtains the > ability to know that a peer has the capability to receive a capabilities > update message in the Open state. This function can be achieved by defini= ng > a new AVP in the CER. A new AVP can be defined called > "Capabilities-Update-AVP". This can be defined as an optional AVP in the = CER > message. There is no need to set the "M" flag for this AVP. It takes two > enumerated values "Supported", "UnSupported" > > > > Peer A sends a CER with "Capabilities-Update-AVP" set as "Supported". Whe= n > peer B receives this AVP, there can be two possibilities > > > > 1) It understands this AVP and it can choose to respond with > "Supported"/"UnSupported" depending on its intent to receive/publish a CE= R > to/from the peer > > 2) It doesnt understand this AVP and hence it is ignored and a CEA is sen= t > back without this AVP > > > > Both the peers get to know of each other's intent/capability to > receive/publish a CER. > > Capability update is carried by using CER/CEA messages. > > > > To summarize, I feel that capabilities advertisement/update should belong > to base protocol and not belong to diameter application scope. > > > > Ravi > > > --0050450294eb678d010471d2decc Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Victor,
=A0=A0 =A0 Thanks for your response. I agree with your point= that we need to have a clean solution and not overload a command. However = I am not sure if I really agree with the point that we are overloading the = CER command. We are talking about capabilities update here and I feel CER i= s the right command for this. In fact capabilities exchange in the open sta= te was designated to be done using CER/CEA=A0in RFC 3588.=A0This is depreca= ted now because of various reasons.

Having said that, I am not against defining a new comma= nd for this purpose. I feel we already have a command to achieve this and i= ts scope is being restricted. We may however go ahead with this approach(de= fining a new command) if everyone thinks this is the best approach.

I am not really convinced that=A0we need to define a ne= w application for the purpose of capabilities update. I feel that capabilit= ies update MUST be done in the scope of "Diameter Common Messages"= ; i.e. with appid =3D 0.

I agree with you that we need to comply to the guidelin= e while defining extensions to the protocol mechanism but I am not sure if = we can ignore the protocol functional architecture altogether.(core protoco= l functions Vs application functions)

If it is really difficult to come up with a clean solut= ion in the current diameter version, we could take up this capabilities upd= ate mechanism in the Version 2 of Diameter base protocol. (There are some o= ther ways of achieving this like defining a request type AVP which says Ini= tial / Update. This can be discussed later)

Your opinion is welcome.

Ravi<= /div>


On Fri, Aug 21, 200= 9 at 6:18 PM, Victor Fajardo <vfajardo@research.telcordia.co= m> wrote:

Hi Ravi,

=A0

I understand the descript= ion you posted below and it is reasonable. But I think we maybe missing a point here. It=92s not that we cannot do option 1, 2 or 3 below (technically we can do anything we want to= and convolute CER/CEA to our hearts content). The point is we want a clean solu= tion that does not violate our own guidelines in overloading a command. For me, = your option 3 below is a classic example of command overloading. Your putting a = lot of required contextual behavior based on the presence/absence of an AVP =85 something our guideline says we should avoid doing.

=A0

Regards,

victor

=A0

Now, coming to my view

=A0

1) If both the peers advertising their updated capabilities simultaneously is a rare occurrence then actually it does not matter if the peer sends the application-ids in the CEA because there is no change in supported applications. A simple check to verify any change from the previo= us supported applications of the peer will suffice.

2) Assuming that rarest of the rare instance happens where there is a near simultaneous upgrade of both the peer and a CER/CEA exchang= e is triggered. Then both the peers need to match each other's capabilities.= This does not change for the case we use CUR/CUA.

3) I presume that the backward compatibility issue arises from the fact that RFC 3588 mentions about CER/CEA exchange in open state b= ut does not clearly specify what should be done by the peers in this case. CER= /CEA exchange is deprecated in the 3588 bis and this new mechanism of CUR/CUA is being proposed.

I feel the same can be achieved using a new AVP in the CER. Am I overlooking something?

=A0

Ravi

=A0

On Thu, Aug 20, 2009 at 6:16 PM, Victor Fajardo <vfajardo@research.telcordi= a.com> wrote:

Hi,

=A0

Just to give you a backgr= ound on why this draft exist: 1) We=92ve gone through this discussion several IETF=92s ago and we realized that we are overloading CER/CEA in terms of co= ntext and use. 2) We did not want to introduce a new set of non-backward compatib= le semantics into CER/CEA just for the sake of updating. Check out the problem statement for this draft and also the thread: http://www= .ietf.org/mail-archive/web/dime/current/msg02775.html

=A0

Regards,

victor

=A0

=A0

From: di= me-bounces@ietf.org [mailto:dime-bou= nces@ietf.org] On Behalf Of Subash Comerica (subashtc)
Sent: Thursday, August 20, 2009 1:12 AM
To: Ravi; dime@ie= tf.org
Subject: Re: [Dime] Comment on draft-ietf-dime-capablities-update-00= .txt

=A0

Hi Ravi,

=A0=A0=A0 I guess the intent here is to support dynamically changing the capabilities.

=A0=A0=A0 I believe RFC 3588 also talks about the state machine where if the peer state is I-open(o= r R-open)=A0and receives a CER, it processes the CER and sends a CEA and stil= l remains in I-open(or R-open)=A0state.

=A0=A0=A0 So I agree with you that it is doable as an optional AVP in CER itself.

=A0

Thanks & Regards,=

Subash

Changing the Way We Live, Work, Play and Learn

=A0

=A0

From:= dime-bounces@ietf.org [mailto:dime-bou= nces@ietf.org] On Behalf Of Ravi
Sent: Wednesday, August 19, 2009 11:00 PM
To: dime@ietf.org=
Subject: [Dime] Comment on draft-ietf-dime-capablities-update-00.txt=

Hi,

=A0=A0I read the=A0draft-ietf-dime-capablities-update-00.txt document and I have a comment regarding defining a new application for the purpose of capability updates.

=A0

1) Advertising the capabilities of a diameter node is the function of th= e diameter base protocol. IMO we need to do this in the scope of the diameter base protocol and not as a separate application

2) By way of defining a new application-id, a diameter node obtains the ability to know that a peer has the capability to receive a capabilities up= date message in the Open state. This function can be achieved by defining a new = AVP in the CER. A new AVP can be defined called "Capabilities-Update-AVP". This can be defined as an optional AVP= in the CER message. There is no need to set the "M" flag for this AV= P. It takes two enumerated values "Supported", "UnSupported&quo= t;

=A0

Peer A sends a CER with "Capabilities-Update-AVP" set as "Supported". When peer B receives this AVP, there can be two poss= ibilities

=A0

1) It understands this AVP and it can choose to respond with "Supported"/"UnSupported" depending on its intent to receive/publish a CER to/from the peer

2) It doesnt understand this AVP and hence it is ignored and a CEA is se= nt back without this AVP

=A0

Both the peers get to know of each other's intent/capability to receive/publish a CER.

Capability update is carried by using CER/CEA messages.

=A0

To summarize, I feel that capabilities advertisement/update should belon= g to base protocol and not belong to diameter application scope.

=A0

Ravi

=A0


--0050450294eb678d010471d2decc-- From vfajardo@research.telcordia.com Mon Aug 24 05:24:36 2009 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 B12EB28B23E for ; Mon, 24 Aug 2009 05:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.81 X-Spam-Level: X-Spam-Status: No, score=-0.81 tagged_above=-999 required=5 tests=[AWL=-0.812, BAYES_50=0.001, 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 fI-ASYcXcp2q for ; Mon, 24 Aug 2009 05:24:33 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id 0325128C150 for ; Mon, 24 Aug 2009 05:24:29 -0700 (PDT) Received: from fajardov1 (vpntnlB33.research.telcordia.com [128.96.59.33]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id n7OCOYSA014651 for ; Mon, 24 Aug 2009 08:24:34 -0400 (EDT) From: "Victor Fajardo" To: Date: Mon, 24 Aug 2009 08:24:34 -0400 Organization: Applied Research, Telcordia Technologies Message-ID: <013c01ca24b5$d71860a0$854921e0$@telcordia.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_013D_01CA2494.5006C0A0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoktdVfkFjNt7r3SQyekWKplEaedw== Content-Language: en-us Subject: [Dime] Diameter API draft. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: vfajardo@research.telcordia.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 12:24:36 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_013D_01CA2494.5006C0A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Folks, During the last IETF, we were trying to gauge if there is leftover interest in continuing work with the Diameter AP (http://tools.ietf.org/html/draft-ietf-dime-diameter-api-08)I. This email is a follow up to solicit a final vote/hum for this draft. If you see value in this draft and wish to see the work continue, make sure you respond to this email as well as address the questions "why and who" would use this API. If you don't see any value in this work pls state so as well. We'll give this hum some time to circulate through peoples mailboxes (a month or so) after which we can decide the fate of the draft. Regards, victor ------=_NextPart_000_013D_01CA2494.5006C0A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Folks,

 

During the last IETF, we were trying to gauge if = there is leftover interest in continuing work with the Diameter AP = (http://tools.ietf.org/html/draft-ietf-dime-diameter-api-08)I. This email is a follow up to solicit a final vote/hum for this draft. If = you see value in this draft and wish to see the work continue,  make sure = you respond to this email as well as address the questions “why and who” = would use this API. If you don’t see any value in this work pls state so = as well. We’ll give this hum some time to circulate through peoples mailboxes (a month or so) after which we can decide the fate of the = draft.

 

Regards,

victor

------=_NextPart_000_013D_01CA2494.5006C0A0-- From vfajardo@research.telcordia.com Mon Aug 24 05:44:01 2009 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 4153728C13E for ; Mon, 24 Aug 2009 05:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.052 X-Spam-Level: X-Spam-Status: No, score=-2.052 tagged_above=-999 required=5 tests=[AWL=0.546, 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 5T8w1RaOA280 for ; Mon, 24 Aug 2009 05:43:51 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id 1E98D3A67F1 for ; Mon, 24 Aug 2009 05:43:51 -0700 (PDT) Received: from fajardov1 (vpntnlB33.research.telcordia.com [128.96.59.33]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id n7OChr6E021212; Mon, 24 Aug 2009 08:43:53 -0400 (EDT) From: "Victor Fajardo" To: "'Ravi'" References: <1bdcf2860908191029w5f5f528ah1096a75a6ad27a44@mail.gmail.com> <454A16E4DA86094EB66BB2C1DBBBC018954081@XMB-BGL-41B.cisco.com> <00e101ca2194$399409c0$acbc1d40$@telcordia.com> <1bdcf2860908201030p2f9f0a5dr80f8a24a93f16299@mail.gmail.com> <010701ca225d$bf5daa10$3e18fe30$@telcordia.com> <1bdcf2860908231059i6f6a78a2kd48300c8fa7e72de@mail.gmail.com> In-Reply-To: <1bdcf2860908231059i6f6a78a2kd48300c8fa7e72de@mail.gmail.com> Date: Mon, 24 Aug 2009 08:43:53 -0400 Organization: Applied Research, Telcordia Technologies Message-ID: <017c01ca24b8$89cdd1b0$9d697510$@telcordia.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_017D_01CA2497.02BC31B0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcokG4ZWrt60U1N1RBuC45KLIDiTWwAm8Lyg Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Comment on draft-ietf-dime-capablities-update-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: vfajardo@research.telcordia.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 12:44:01 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_017D_01CA2497.02BC31B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Comments inline: From: Ravi [mailto:nrs2712@gmail.com] Sent: Sunday, August 23, 2009 2:00 PM To: vfajardo@research.telcordia.com Cc: Subash Comerica (subashtc); dime@ietf.org Subject: Re: [Dime] Comment on draft-ietf-dime-capablities-update-00.txt Hi Victor, Thanks for your response. I agree with your point that we need to have a clean solution and not overload a command. However I am not sure if I really agree with the point that we are overloading the CER command. We are talking about capabilities update here and I feel CER is the right command for this. In fact capabilities exchange in the open state was designated to be done using CER/CEA in RFC 3588. This is deprecated now because of various reasons. Having said that, I am not against defining a new command for this purpose. I feel we already have a command to achieve this and its scope is being restricted. We may however go ahead with this approach(defining a new command) if everyone thinks this is the best approach. I am not really convinced that we need to define a new application for the purpose of capabilities update. I feel that capabilities update MUST be done in the scope of "Diameter Common Messages" i.e. with appid = 0. I agree with you that we need to comply to the guideline while defining extensions to the protocol mechanism but I am not sure if we can ignore the protocol functional architecture altogether.(core protocol functions Vs application functions) [Victor]: As you may already know, the decision you mentioned above is because we want to preserve backward compatibility and not increment the version number for bis. We have a lot of resistance with this and we want to progress bis as quick as possible. If it is really difficult to come up with a clean solution in the current diameter version, we could take up this capabilities update mechanism in the Version 2 of Diameter base protocol. (There are some other ways of achieving this like defining a request type AVP which says Initial / Update. This can be discussed later) [Victor]: This is what other folks have mentioned as well. Regards, Victor Your opinion is welcome. Ravi On Fri, Aug 21, 2009 at 6:18 PM, Victor Fajardo wrote: Hi Ravi, I understand the description you posted below and it is reasonable. But I think we maybe missing a point here. It's not that we cannot do option 1, 2 or 3 below (technically we can do anything we want to and convolute CER/CEA to our hearts content). The point is we want a clean solution that does not violate our own guidelines in overloading a command. For me, your option 3 below is a classic example of command overloading. Your putting a lot of required contextual behavior based on the presence/absence of an AVP . something our guideline says we should avoid doing. Regards, victor Now, coming to my view 1) If both the peers advertising their updated capabilities simultaneously is a rare occurrence then actually it does not matter if the peer sends the application-ids in the CEA because there is no change in supported applications. A simple check to verify any change from the previous supported applications of the peer will suffice. 2) Assuming that rarest of the rare instance happens where there is a near simultaneous upgrade of both the peer and a CER/CEA exchange is triggered. Then both the peers need to match each other's capabilities. This does not change for the case we use CUR/CUA. 3) I presume that the backward compatibility issue arises from the fact that RFC 3588 mentions about CER/CEA exchange in open state but does not clearly specify what should be done by the peers in this case. CER/CEA exchange is deprecated in the 3588 bis and this new mechanism of CUR/CUA is being proposed. I feel the same can be achieved using a new AVP in the CER. Am I overlooking something? Ravi On Thu, Aug 20, 2009 at 6:16 PM, Victor Fajardo wrote: Hi, Just to give you a background on why this draft exist: 1) We've gone through this discussion several IETF's ago and we realized that we are overloading CER/CEA in terms of context and use. 2) We did not want to introduce a new set of non-backward compatible semantics into CER/CEA just for the sake of updating. Check out the problem statement for this draft and also the thread: http://www.ietf.org/mail-archive/web/dime/current/msg02775.html Regards, victor From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Subash Comerica (subashtc) Sent: Thursday, August 20, 2009 1:12 AM To: Ravi; dime@ietf.org Subject: Re: [Dime] Comment on draft-ietf-dime-capablities-update-00.txt Hi Ravi, I guess the intent here is to support dynamically changing the capabilities. I believe RFC 3588 also talks about the state machine where if the peer state is I-open(or R-open) and receives a CER, it processes the CER and sends a CEA and still remains in I-open(or R-open) state. So I agree with you that it is doable as an optional AVP in CER itself. Thanks & Regards, Subash Changing the Way We Live, Work, Play and Learn _____ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Ravi Sent: Wednesday, August 19, 2009 11:00 PM To: dime@ietf.org Subject: [Dime] Comment on draft-ietf-dime-capablities-update-00.txt Hi, I read the draft-ietf-dime-capablities-update-00.txt document and I have a comment regarding defining a new application for the purpose of capability updates. 1) Advertising the capabilities of a diameter node is the function of the diameter base protocol. IMO we need to do this in the scope of the diameter base protocol and not as a separate application 2) By way of defining a new application-id, a diameter node obtains the ability to know that a peer has the capability to receive a capabilities update message in the Open state. This function can be achieved by defining a new AVP in the CER. A new AVP can be defined called "Capabilities-Update-AVP". This can be defined as an optional AVP in the CER message. There is no need to set the "M" flag for this AVP. It takes two enumerated values "Supported", "UnSupported" Peer A sends a CER with "Capabilities-Update-AVP" set as "Supported". When peer B receives this AVP, there can be two possibilities 1) It understands this AVP and it can choose to respond with "Supported"/"UnSupported" depending on its intent to receive/publish a CER to/from the peer 2) It doesnt understand this AVP and hence it is ignored and a CEA is sent back without this AVP Both the peers get to know of each other's intent/capability to receive/publish a CER. Capability update is carried by using CER/CEA messages. To summarize, I feel that capabilities advertisement/update should belong to base protocol and not belong to diameter application scope. Ravi ------=_NextPart_000_017D_01CA2497.02BC31B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Comments inline:

 

From:= Ravi [mailto:nrs2712@gmail.com]
Sent: Sunday, August 23, 2009 2:00 PM
To: vfajardo@research.telcordia.com
Cc: Subash Comerica (subashtc); dime@ietf.org
Subject: Re: [Dime] Comment on = draft-ietf-dime-capablities-update-00.txt

 

Hi Victor,

     Thanks for your response. I = agree with your point that we need to have a clean solution and not overload a = command. However I am not sure if I really agree with the point that we are = overloading the CER command. We are talking about capabilities update here and I = feel CER is the right command for this. In fact capabilities exchange in the open = state was designated to be done using CER/CEA in RFC 3588. This is deprecated now because of various reasons.

 

Having said that, I am not against defining a new = command for this purpose. I feel we already have a command to achieve this and = its scope is being restricted. We may however go ahead with this = approach(defining a new command) if everyone thinks this is the best = approach.

 

I am not really convinced that we need to = define a new application for the purpose of capabilities update. I feel that = capabilities update MUST be done in the scope of "Diameter Common Messages" = i.e. with appid =3D 0.

 

I agree with you that we need to comply to the = guideline while defining extensions to the protocol mechanism but I am not sure if = we can ignore the protocol functional architecture altogether.(core protocol = functions Vs application functions)

 

 

[Victor]: As you may already know,  the decision you mentioned above is because we want to preserve backward compatibility = and not increment the version number for bis. We have a lot of resistance with = this and we want to progress bis as quick as possible.

 

 

If it is really difficult to come up with a clean = solution in the current diameter version, we could take up this capabilities = update mechanism in the Version 2 of Diameter base protocol. (There are some = other ways of achieving this like defining a request type AVP which says = Initial / Update. This can be discussed later)

 

 

[Victor]: This is what other folks have mentioned as = well.

 

Regards,

Victor

 

 

Your opinion is welcome.

 

Ravi

 

 

On Fri, Aug 21, 2009 at 6:18 PM, Victor Fajardo = <vfajardo@research.telcordia.com> wrote:

Hi = Ravi,

 

I understand the = description you posted below and it is reasonable. But I think we maybe missing a = point here. It’s not that we cannot do option 1, 2 or 3 below = (technically we can do anything we want to and convolute CER/CEA to our hearts content). = The point is we want a clean solution that does not violate our own = guidelines in overloading a command. For me, your option 3 below is a classic example = of command overloading. Your putting a lot of required contextual behavior = based on the presence/absence of an AVP … something our guideline says = we should avoid doing.

 

Regards,

victor

 

Now, coming to my view

 

1) If both the peers advertising their updated capabilities = simultaneously is a rare occurrence then actually it does not matter if the peer sends = the application-ids in the CEA because there is no change in supported applications. A simple check to verify any change from the previous = supported applications of the peer will suffice.

2) Assuming that rarest of the rare instance happens where there is a = near simultaneous upgrade of both the peer and a CER/CEA exchange is = triggered. Then both the peers need to match each other's capabilities. This does not = change for the case we use CUR/CUA.

3) I presume that the backward compatibility issue arises from the = fact that RFC 3588 mentions about CER/CEA exchange in open state but does not = clearly specify what should be done by the peers in this case. CER/CEA exchange = is deprecated in the 3588 bis and this new mechanism of CUR/CUA is being = proposed.

I feel the same can be achieved using a new AVP in the CER. Am I = overlooking something?

 

Ravi

 

On Thu, Aug 20, 2009 at 6:16 PM, Victor Fajardo <vfajardo@research.telcordia.com> wrote:

Hi,

 

Just to give you a = background on why this draft exist: 1) We’ve gone through this discussion = several IETF’s ago and we realized that we are overloading CER/CEA in = terms of context and use. 2) We did not want to introduce a new set of = non-backward compatible semantics into CER/CEA just for the sake of updating. Check = out the problem statement for this draft and also the thread: http://www.ietf.org/mail-archive/web/dime/current/msg02= 775.html

 

Regards,

victor

 

 

From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Subash Comerica (subashtc)
Sent: Thursday, August 20, 2009 1:12 AM
To: Ravi; dime@ietf.org
Subject: Re: [Dime] Comment on = draft-ietf-dime-capablities-update-00.txt

 

Hi = Ravi,

    I = guess the intent here is to support dynamically changing the = capabilities.

    I = believe RFC 3588 also talks about the state machine where if the peer state is = I-open(or R-open) and receives a CER, it processes the CER and sends a CEA = and still remains in I-open(or R-open) state.

    So I = agree with you that it is doable as an optional AVP in CER = itself.

 

Thanks & = Regards,

Subash

Changing the Way We Live, Work, Play and = Learn

 

 

From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Ravi
Sent: Wednesday, August 19, 2009 11:00 PM
To: dime@ietf.org
Subject: [Dime] Comment on = draft-ietf-dime-capablities-update-00.txt

Hi,

  I read the draft-ietf-dime-capablities-update-00.txt document and I have a comment regarding defining a new application for = the purpose of capability updates.

 

1) Advertising the capabilities of a diameter node is the function of = the diameter base protocol. IMO we need to do this in the scope of the = diameter base protocol and not as a separate application

2) By way of defining a new application-id, a diameter node obtains = the ability to know that a peer has the capability to receive a capabilities update = message in the Open state. This function can be achieved by defining a new AVP = in the CER. A new AVP can be defined called = "Capabilities-Update-AVP". This can be defined as an optional AVP in the CER message. There is no need = to set the "M" flag for this AVP. It takes two enumerated values "Supported", "UnSupported"

 

Peer A sends a CER with "Capabilities-Update-AVP" set as "Supported". When peer B receives this AVP, there can be two possibilities

 

1) It understands this AVP and it can choose to respond with "Supported"/"UnSupported" depending on its intent to receive/publish a CER to/from the peer

2) It doesnt understand this AVP and hence it is ignored and a CEA is = sent back without this AVP

 

Both the peers get to know of each other's intent/capability to receive/publish a CER.

Capability update is carried by using CER/CEA = messages.

 

To summarize, I feel that capabilities advertisement/update should = belong to base protocol and not belong to diameter application = scope.

 

Ravi

 

 

------=_NextPart_000_017D_01CA2497.02BC31B0-- From niklas.neumann@cs.uni-goettingen.de Mon Aug 24 05:56:26 2009 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 BC00028C198 for ; Mon, 24 Aug 2009 05:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 B0MJDIG7uWm6 for ; Mon, 24 Aug 2009 05:56:25 -0700 (PDT) Received: from tmailer.gwdg.de (tmailer.gwdg.de [134.76.10.23]) by core3.amsl.com (Postfix) with ESMTP id A237528C13E for ; Mon, 24 Aug 2009 05:56:25 -0700 (PDT) Received: from s5.ifi.informatik.uni-goettingen.de ([134.76.81.25] helo=[172.23.0.5]) by mailer.gwdg.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MfZ66-0003nv-87 for dime@ietf.org; Mon, 24 Aug 2009 14:56:30 +0200 Message-ID: <4A928DE4.50302@cs.uni-goettingen.de> Date: Mon, 24 Aug 2009 14:56:04 +0200 From: Niklas Neumann Organization: University of Goettingen User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: (clean) by exiscan+sophie Subject: [Dime] Comments about Webauth application 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, 24 Aug 2009 12:56:26 -0000 Hello everybody, I would like to address the comments we received during the last IETF meeting regarding the Diameter Webauth application. If you have missed the presentation, the slides are available here: http://www.ietf.org/proceedings/75/slides/dime-8.pdf * Diameter SIP application also includes HTTP digest authentication: This is true and WebAuth is actually reusing the AVP specifications made in RFC 4740. I do not suppose the suggestion is that people should just implement 4740 if they just want to use HTTP authentication over Diameter so I do not see any problems with that. * Corresponding RADIUS specification (RFC 5090) is not adopted due to latency issues: I cannot really comment if anybody uses RFC 5090 or not. However, RFC 5090 obsoletes RFC 4590 so there must have been at least some interest to put work into another revision of the original RFC. Regarding the latency I see how this might be an issue if you do the Diameter authentication for every HTTP request. However, I think it is more realistic that HTTP servers will cache Diameter responses or even open some sort of session context which will only be initially authenticated. I really appreciate any of your comments. I think that web environments can benefit from authentication and authorization standards to make life easier for site administrators and to benefit from existing Diameter deployments. If there is anything that would make the draft more adoptable please let us know. Best regards Niklas -- Niklas Neumann - University of Goettingen, Institute of Computer Science http://user.informatik.uni-goettingen.de/~nneuman1/ Tel: +49 551 39-172053 From vfajardo@research.telcordia.com Mon Aug 24 06:19:31 2009 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 6355B3A6DD0 for ; Mon, 24 Aug 2009 06:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.159 X-Spam-Level: X-Spam-Status: No, score=-1.159 tagged_above=-999 required=5 tests=[AWL=-0.420, BAYES_20=-0.74, 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 5eIkTK8bUndk for ; Mon, 24 Aug 2009 06:19:28 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id BB5E33A6C1E for ; Mon, 24 Aug 2009 06:19:02 -0700 (PDT) Received: from fajardov1 (vpntnlB33.research.telcordia.com [128.96.59.33]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id n7ODJ8O1002179 for ; Mon, 24 Aug 2009 09:19:08 -0400 (EDT) From: "Victor Fajardo" To: Date: Mon, 24 Aug 2009 09:19:08 -0400 Organization: Applied Research, Telcordia Technologies Message-ID: <019401ca24bd$76783a10$6368ae30$@telcordia.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0195_01CA249B.EF669A10" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcokvXXygeTgtQ8RQMiqQ02t7oFJ/Q== Content-Language: en-us Subject: [Dime] Capabilities update draft X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: vfajardo@research.telcordia.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 13:19:31 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0195_01CA249B.EF669A10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Folks, We would like to progress the capabilities-update draft (http://tools.ietf.org/html/draft-ietf-dime-capablities-update-00). Ravi and other folks have commented on this work but its best if we get some more feedback especially from folks who work on diameter implementations. It's a short document and fairly easy reading. We plan to let this cook in the WG for about a month or so and then take the next step. If you have concerns, pls state so as well. Regards, victor ------=_NextPart_000_0195_01CA249B.EF669A10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Folks,

 

We would like to progress the capabilities-update = draft (http://tools.ietf.org/html/draft-ietf-dime-capablities-update-00). Ravi and other folks have commented on this work but its best if we get = some more feedback especially from folks who work on diameter = implementations. It’s a short document and fairly easy reading. We plan to let this cook in = the WG for about a month or so and then take the next step. If you have = concerns, pls state so as well.

 

Regards,

victor

 

------=_NextPart_000_0195_01CA249B.EF669A10-- From lionel.morand@orange-ftgroup.com Mon Aug 24 07:22:05 2009 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 690FA3A6995 for ; Mon, 24 Aug 2009 07:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.465 X-Spam-Level: X-Spam-Status: No, score=-1.465 tagged_above=-999 required=5 tests=[AWL=0.784, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 yCo90LzyH1Vk for ; Mon, 24 Aug 2009 07:22:04 -0700 (PDT) Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 068CD3A6DB5 for ; Mon, 24 Aug 2009 07:22:03 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 16:22:02 +0200 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: Mon, 24 Aug 2009 16:21:59 +0200 Message-ID: In-Reply-To: <4A928DE4.50302@cs.uni-goettingen.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Comments about Webauth application Thread-Index: AcokunVruk+7yHXsSa+h6z7zEiVtJgAClwaQ References: <4A928DE4.50302@cs.uni-goettingen.de> From: To: , X-OriginalArrivalTime: 24 Aug 2009 14:22:02.0750 (UTC) FILETIME=[3FE3D1E0:01CA24C6] Subject: Re: [Dime] Comments about Webauth application 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, 24 Aug 2009 14:22:05 -0000 Hi Niklas, See below.=20 > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De=20 > la part de Niklas Neumann > Envoy=E9 : lundi 24 ao=FBt 2009 14:56 > =C0 : dime@ietf.org > Objet : [Dime] Comments about Webauth application >=20 > Hello everybody, >=20 > I would like to address the comments we received during the=20 > last IETF meeting regarding the Diameter Webauth application.=20 > If you have missed the presentation, the slides are available here:=20 > http://www.ietf.org/proceedings/75/slides/dime-8.pdf >=20 >=20 > * Diameter SIP application also includes HTTP digest authentication: > This is true and WebAuth is actually reusing the AVP=20 > specifications made in RFC 4740. I do not suppose the=20 > suggestion is that people should just implement 4740 if they=20 > just want to use HTTP authentication over Diameter so I do=20 > not see any problems with that. Maybe the question could be: does the use of the MAR/MAA command pair = with the Application-id "Diameter SIP Application (6)" fulfil your = requirements? If the answer is "yes", you don't have to create a new application. You = can just specify that in the context of Web authentication, MAR/MAA are = used for HTTP Digest authentication. If there is no modification to the = command ABNF description nor new mandatory AVP to support for webauth, = the application-id can be re-used as such. There is no need to implement = the whole RFC 4740 "Diameter SIP application" if you want only to = support the authentication part. Lionel >=20 > * Corresponding RADIUS specification (RFC 5090) is not=20 > adopted due to latency issues: > I cannot really comment if anybody uses RFC 5090 or not.=20 > However, RFC 5090 obsoletes RFC 4590 so there must have been=20 > at least some interest to put work into another revision of=20 > the original RFC. > Regarding the latency I see how this might be an issue if you=20 > do the Diameter authentication for every HTTP request.=20 > However, I think it is more realistic that HTTP servers will=20 > cache Diameter responses or even open some sort of session=20 > context which will only be initially authenticated. >=20 >=20 > I really appreciate any of your comments. I think that web=20 > environments can benefit from authentication and=20 > authorization standards to make life easier for site=20 > administrators and to benefit from existing Diameter=20 > deployments. If there is anything that would make the draft=20 > more adoptable please let us know. >=20 >=20 > Best regards > Niklas >=20 > -- > Niklas Neumann - University of Goettingen, Institute of=20 > Computer Science http://user.informatik.uni-goettingen.de/~nneuman1/ > Tel: +49 551 39-172053 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 From root@core3.amsl.com Mon Aug 24 07:45:01 2009 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B438328C26E; Mon, 24 Aug 2009 07:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090824144501.B438328C26E@core3.amsl.com> Date: Mon, 24 Aug 2009 07:45:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-pmip6-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: Mon, 24 Aug 2009 14:45: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 Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-pmip6-03.txt Pages : 20 Date : 2009-08-24 This specification defines Authentication, Authorization, and Accounting interactions between Proxy Mobile IPv6 entities (both Mobile Access Gateway and Local Mobility Anchor) and an Authentication, Authorization, and Accounting server within a Proxy Mobile IPv6 Domain. These Authentication, Authorization, and Accounting interactions are primarily used to download and update mobile node specific policy profile information between Proxy Mobile IPv6 entities and a remote policy store. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-pmip6-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-pmip6-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-24073552.I-D@ietf.org> --NextPart-- From jouni.nospam@gmail.com Mon Aug 24 07:54:55 2009 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 B911D28C166 for ; Mon, 24 Aug 2009 07:54:55 -0700 (PDT) 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 ponnwgqifjSv for ; Mon, 24 Aug 2009 07:54:54 -0700 (PDT) Received: from mail-ew0-f206.google.com (mail-ew0-f206.google.com [209.85.219.206]) by core3.amsl.com (Postfix) with ESMTP id E6B983A69EF for ; Mon, 24 Aug 2009 07:54:25 -0700 (PDT) Received: by ewy2 with SMTP id 2so2967196ewy.43 for ; Mon, 24 Aug 2009 07:54:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :content-type:content-transfer-encoding:mime-version:subject:date :references:x-mailer; bh=S3jJSmSMTt7QNTGS+a+4G+SDh8y+b+34mTdIxBtoHAM=; b=U0Rhr1DPTh8Cdqe6R7X6ThA9XT67K1ekEj5AYToZH2m+OgAeMdmD28OKW8BFdjnZXl DrGF/aI9ABAnZYaeNnvmSVGdIXye5GZHMOkyAeUBH59ZMTqoLGE0bf9fk4ZEgC5BP3GL ITKID2etLviMdA4dt0KN09qM+Glfb608+hBl8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:references:x-mailer; b=PP/MhUgIz88h05K100YmD1spp7gNRO6sMVKX+4tG18/x5uKrzDAoaMQf4YGkoh03zZ F6fn9mznD2RUSfiCQ9sgaLeRaP3mxsmWiPXzwPP8WQ1ZPtMFp4MgzsiNzXnUnep77fAq 4hqQwpdhJrkf43XyjBTwrMhOQDlmjJsmF3COI= Received: by 10.210.38.2 with SMTP id l2mr274229ebl.59.1251125665952; Mon, 24 Aug 2009 07:54:25 -0700 (PDT) Received: from a88-114-70-117.elisa-laajakaista.fi (a88-114-70-117.elisa-laajakaista.fi [88.114.70.117]) by mx.google.com with ESMTPS id 28sm322901eye.35.2009.08.24.07.54.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 24 Aug 2009 07:54:25 -0700 (PDT) Message-Id: From: jouni korhonen To: dime@ietf.org, Spencer Dawkins , Marco Liebsch , "Dan (Dan) Romascanu" Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 24 Aug 2009 17:54:23 +0300 References: <20090824143552.605CC3A6E07@core3.amsl.com> X-Mailer: Apple Mail (2.936) Cc: Victor Fajardo Subject: [Dime] New Version Notification for draft-ietf-dime-pmip6-03 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, 24 Aug 2009 14:54:55 -0000 Hi All, I recently submitted -03 version of dime-pmip6 I-D. It now captures comments from Spencer (gen-art review), Marco and Dan. Thanks for your time on reviewing. Cheers, Jouni Begin forwarded message: > From: IETF I-D Submission Tool > Date: August 24, 2009 5:35:52 PM GMT+03:00 > To: jouni.nospam@gmail.com > Cc: julien.bournelle@orange- > ftgroup.com,kchowdhury@starentnetworks.com,amuhanna@nortel.com,meyer@umic.rwth-aachen.de > Subject: New Version Notification for draft-ietf-dime-pmip6-03 > > > A new version of I-D, draft-ietf-dime-pmip6-03.txt has been > successfuly submitted by Jouni Korhonen and posted to the IETF > repository. > > Filename: draft-ietf-dime-pmip6 > Revision: 03 > Title: Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local > Mobility Anchor Interaction with Diameter Server > Creation_date: 2009-08-24 > WG ID: dime > Number_of_pages: 20 > > Abstract: > This specification defines Authentication, Authorization, and > Accounting interactions between Proxy Mobile IPv6 entities (both > Mobile Access Gateway and Local Mobility Anchor) and an > Authentication, Authorization, and Accounting server within a Proxy > Mobile IPv6 Domain. These Authentication, Authorization, and > Accounting interactions are primarily used to download and update > mobile node specific policy profile information between Proxy Mobile > IPv6 entities and a remote policy store. > > > > The IETF Secretariat. > > From sdecugis@nict.go.jp Mon Aug 24 21:20:07 2009 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 035513A6D1D for ; Mon, 24 Aug 2009 21:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[AWL=1.253, BAYES_00=-2.599, 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 pWiqqsCfNxLX for ; Mon, 24 Aug 2009 21:20:06 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:2f8:29::3]) by core3.amsl.com (Postfix) with ESMTP id 060E028C340 for ; Mon, 24 Aug 2009 21:20:02 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id n7P4K7JX016279; Tue, 25 Aug 2009 13:20:07 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id n7P4K7kH001658; Tue, 25 Aug 2009 13:20:07 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id n7P4K7qU001652; Tue, 25 Aug 2009 13:20:07 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 0E692162D3; Tue, 25 Aug 2009 13:20:07 +0900 (JST) Received: from [133.243.146.206] (5gou2f-dhcp46.nict.go.jp [133.243.146.206]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 08F8B2329; Tue, 25 Aug 2009 13:20:07 +0900 (JST) Message-ID: <4A936659.9000204@nict.go.jp> Date: Tue, 25 Aug 2009 13:19:37 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: vfajardo@research.telcordia.com References: <019401ca24bd$76783a10$6368ae30$@telcordia.com> In-Reply-To: <019401ca24bd$76783a10$6368ae30$@telcordia.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] Capabilities update draft 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, 25 Aug 2009 04:20:07 -0000 Hello Victor, all, I have a few comments on the document. I have two concerns about the security. The first is : I wonder if the ability to change the DiameterIdentity of the peer during CUR/CUA does not make it possible to "usurpate" another identity. For example, a Diameter peer from realm B connects to a relay from realm A providing proper credentials (CA from realm B), then sends a CUR updating its DiameterIdentity to some identity in realm C. It is now able to receive messages destined to realm C, without having a proper credential from that realm. The second issue is similar. It concerns the ability to update the peer identity as well as its Host-IP-Address(es). If a peer is able to "inject" a CUR inside an open connection, with new DiameterIdentity and Host-IP-Address information, then the traffic gets redirected to an arbitrary peer without going through the security check again. This is probably not usable for TLS-protected channels, but in case of IPsec it would be difficult to detect that the connection is moved to an address without protection. I am not really sure if this attack is possible or not, but I believe it should be described in the Security Considerations section. My conclusion would be that I think we should not allow to change the DiameterIdentity (Origin-Host and/or Origin-Realm) in the CUR. We should mandate that the transport connection is restarted if the peer identity is to be changed. I have also several comments about different parts of the document: "Diameter nodes conforming to this specification MAY advertise support by including..." (section 3, second paragraph) This is not compatible with the requirements of RFC3588 (section 2.4, third paragraph): "Relay and redirect agents MUST advertise the Relay Application Identifier, while all other Diameter nodes MUST advertise locally supported applications." Furthermore, the first paragraph of section 4 is also not consistent with Diameter routing: "When the capabilities of a Diameter node conforming to this specification change, it SHOULD notify all of the nodes with which it has an open transport connection using the Capabilities-Update-..." According to RFC3588, the message with application TBD must not be sent to peers that have not advertised support for this application or support for the relay application (although in this case, since the message is not relayable, I believe it should only be sent to peers that have explicitely advertised the support for the CU application). My recommendation would be to change the requirement levels: the peer MUST advertise the support for application, and the peer should notify all the nodes that have advertised support for Capability Update application (and not those who did not advertise this support). It is not related, but I find that the last paragraph of section 4 (Capabilities Update) very confusing ("Since the CUR/CUA messages cannot be proxied, ...") and I think it could be removed. What do you think? About the use cases for the Capability Update application, I personally believe that few implementations will ever support adding or removing applications without restarting (it seems very difficult to implement this). I believe that the ability to advertise added or removed IP endpoints is more useful, especially in the case of SCTP. Anyway, SCTP is already capable of handling this at its own layer, and provide the information to upper layers through a notification system. I think it would be very useful to have a short text describing how everything interacts if you add a new network interface to a box for example (SCTP notification, CUR/CUA...). I believe my problem is that I don't really understand the role of the Host-IP-Address AVPs, sorry for this. I think that's all I have for the moment :) Sorry for the long mail! Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sunseawq@huawei.com Tue Aug 25 01:30:23 2009 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 1F8653A6903 for ; Tue, 25 Aug 2009 01:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.939 X-Spam-Level: X-Spam-Status: No, score=0.939 tagged_above=-999 required=5 tests=[AWL=0.549, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, 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 SHvI4cF8oIJg for ; Tue, 25 Aug 2009 01:30:22 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 6B9F73A67B7 for ; Tue, 25 Aug 2009 01:30:17 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOX002PYBJWQ3@szxga04-in.huawei.com> for dime@ietf.org; Tue, 25 Aug 2009 16:28:44 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOX00FW1BJWAN@szxga04-in.huawei.com> for dime@ietf.org; Tue, 25 Aug 2009 16:28:44 +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 <0KOX003FDBJWGZ@szxml04-in.huawei.com> for dime@ietf.org; Tue, 25 Aug 2009 16:28:44 +0800 (CST) Date: Tue, 25 Aug 2009 16:28:47 +0800 From: Qin Wu To: dime@ietf.org Message-id: <02f201ca255e$11533620$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.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_bw5YNcar9rTic07QOkGJTA)" X-Priority: 3 X-MSMail-priority: Normal References: <018101ca24ba$01834ea0$0489ebe0$@telcordia.com> Subject: [Dime] [DIME] Comments about AVP for crypto key transport draft 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, 25 Aug 2009 08:30:23 -0000 This is a multi-part message in MIME format. --Boundary_(ID_bw5YNcar9rTic07QOkGJTA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi, folk, During the last IETF meeting, We made a presentation on AVP for crypto key transport and recieved a few comments from some experts. The URL links for our I-D and presentation slides are: http://tools.ietf.org/html/draft-wu-dime-local-keytran-02 http://www.ietf.org/proceedings/75/slides/dime-2.pdf Here I would like to provide an overview of our I-D and address the comments received in the IETF to help people to better understand what we are doing in this I-D. The basic idea of this I-D is to specify a set of AVPs allowing the transport of multiple cryptographic keys in a single Diameter message(e.g, transport rMSK and DSRK in one Diameter message in ERP). All these multiple cryptographic keys are EAP based root keys derived from EMSK exported by EAP(i.e., ERP depends on EAP key mangement) e.g., DSRK, USRK, rRK, DSUSRK, rMSK and are also master keys used in the handover optimization during network access. And each cryptographic key has its own lifetime, type, name. Suppose more than one such cryptographic keys including lifetime, type, name need to be encapsulated in a set of AVPs of one Diameter message, if we don't define one grouped AVP to organize these AVPs, it is hard to use the same AVP to encapsulate the lifetime of one cryptographic key with the lifetime of another cryptographic key in one Diameter message. That's why we define one grouped AVP to accommodate each type of cryptograhic key with its lifetime, name and type. On the other hand, since these cryptographic keys are all EAP based transported key materials and used for handoff, it seems more practical to try to reuse the same AVP to acccomodate the lifetime, name, type of key materials, e.g, define the same AVP to encapsulate the lifetime of rMSK and DSRK. As regarding whether reuse of EAP-Key-Name change the meaning of itself, My answer is no, because as described in the section 5.9 of RFC5247, EAP-Key-Name means EAP Session-Id, So it is not limited to identify MSK. It is also can be used to identify the other EAP based key materials. In the Diameter ERP document, the AVP of ERP keys are also defined. However these transport of ERP keys are specific to the ERP application and can not solve how to transport more than one cryptographic keys in one message. As regarding why we want to make the key transport more generic, the reason is, in some EAP/ERP scenario, transport of multiple cryptographic keys in a single Diameter message is required. E.g., in the implicit bootstrapping for ERP(i.e.,full EAP authentication), the EAP request/response encapsulated in the AAA message is used to carry DSRK and rMSK simultaneously to the local Server. Upon receiving DSRK and rMSK, the local Server further deliver the rMSK to the given authenticator. In this scenario, the rMSK and DSRK need to be transported in the EAP request/Response simutaneously. In contrast with implicit bootstrapping, the explicit bootstrapping will use EAP-Initiate/Finish to carry rMSK and DSRK. If rMSK, DSRK and relevant key information including lifetime, name is transported one AAA message, it will be difficult to distinguish which key information is corresponding to which keying materials. So it is sensible to define one grouped AVP to organize each type of transported keys and make the transport more generic. With respect to whether 3GPP would dump existing stuff in favour of the new transport, if my understanding is correct, 3GPP has its own key generation which depends on authentication Vector to derive key materials. These key materials has nothing to do with EAP based transport key materials. I hope I have addressed all the comments collected in the last meeting. If you have any further comments or good suggestions to make the I-D more concise and adoptable, please let us know. Regards! -Qin --Boundary_(ID_bw5YNcar9rTic07QOkGJTA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi, folk,
During the last IETF meeting, We made a presentation on AVP for crypto key transport and recieved a few comments from some experts. The URL links for our I-D and presentation slides are:
 
Here I would like to provide an overview of  our I-D and address the comments received in the IETF to help people to better understand what we are doing in this I-D.
The basic idea of this I-D is to specify a set of AVPs allowing the transport of multiple cryptographic keys in a single Diameter message(e.g, transport rMSK and DSRK in one Diameter message in ERP). All these multiple cryptographic keys are EAP based root keys derived from EMSK exported by EAP(i.e., ERP depends on EAP key mangement) e.g., DSRK, USRK, rRK, DSUSRK, rMSK  and are also master keys used in the handover optimization during network access. And each cryptographic key has its own lifetime, type, name.
Suppose more than one such cryptographic keys including lifetime, type, name need to be encapsulated in a set of  AVPs of  one Diameter message, if we don't define one grouped AVP to organize these AVPs, it is hard to use the same AVP to encapsulate the lifetime of one cryptographic key with the lifetime of another cryptographic key in one Diameter message. That's why we define one grouped AVP to accommodate each type of cryptograhic key with its lifetime, name and type. On the other hand, since these cryptographic keys are all EAP based transported key materials and used for handoff, it seems more practical to try to reuse
the same AVP to acccomodate the lifetime, name, type of key materials, e.g, define the same AVP to encapsulate the lifetime of rMSK and DSRK.
 
As regarding whether reuse of EAP-Key-Name change the meaning of itself, My answer is no, because as described in the section 5.9 of RFC5247, EAP-Key-Name means EAP Session-Id, So it is not limited to identify MSK. It is also can be used to identify the other EAP based key materials.
 
In the Diameter ERP document, the AVP of ERP keys are also defined. However these transport of ERP keys are specific to the ERP application and can not solve how to transport more than one cryptographic keys in one message.
 
As regarding why we want to make the key transport more generic, the reason is, in some EAP/ERP scenario, transport of multiple cryptographic keys in a single Diameter message is required.

E.g., in the implicit bootstrapping for ERP(i.e.,full EAP authentication), the EAP request/response encapsulated in the AAA message is used to carry DSRK and rMSK simultaneously to the local Server. Upon receiving DSRK and rMSK, the local Server further deliver the rMSK to the given authenticator. In this scenario, the rMSK and DSRK need to be transported in the EAP request/Response simutaneously.

In contrast with implicit bootstrapping, the explicit bootstrapping will use EAP-Initiate/Finish to carry rMSK and DSRK. If rMSK, DSRK and relevant key information including lifetime, name is transported one AAA message, it will be difficult to distinguish which key information is corresponding to which keying materials. So it is sensible to define one grouped AVP to organize each type of transported keys and make the transport more generic.

 

With respect to whether 3GPP would dump existing stuff in favour of the new transport, if my understanding is correct, 3GPP has its own key generation which depends on authentication Vector to derive key materials. These  key materials has nothing to do with EAP based transport key materials.

 

I hope I have addressed all the comments collected in the last meeting. If you have any further comments or good suggestions to make the I-D more concise and  adoptable, please let us know.

 

Regards!

-Qin

--Boundary_(ID_bw5YNcar9rTic07QOkGJTA)-- From niklas.neumann@cs.uni-goettingen.de Tue Aug 25 05:22:20 2009 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 7D0B83A6C03 for ; Tue, 25 Aug 2009 05:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 BF0UhnGT5rsM for ; Tue, 25 Aug 2009 05:22:19 -0700 (PDT) Received: from tmailer.gwdg.de (tmailer.gwdg.de [134.76.10.23]) by core3.amsl.com (Postfix) with ESMTP id 18FC83A6902 for ; Tue, 25 Aug 2009 05:22:18 -0700 (PDT) Received: from s5.ifi.informatik.uni-goettingen.de ([134.76.81.25] helo=[172.23.0.5]) by mailer.gwdg.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Mfv2A-00009Z-OI; Tue, 25 Aug 2009 14:21:54 +0200 Message-ID: <4A93D742.7080402@cs.uni-goettingen.de> Date: Tue, 25 Aug 2009 14:21:22 +0200 From: Niklas Neumann Organization: University of Goettingen User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: vfajardo@research.telcordia.com References: <019401ca24bd$76783a10$6368ae30$@telcordia.com> In-Reply-To: <019401ca24bd$76783a10$6368ae30$@telcordia.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: (clean) by exiscan+sophie Cc: dime@ietf.org Subject: Re: [Dime] Capabilities update draft 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, 25 Aug 2009 12:22:20 -0000 Hello everybody, I was wondering if there should be some implementation considerations included. I see the following problem: A Diameter client has a list of potential Diameter servers. When the client starts it picks a random server from this list and tries to initialize its applications. If there is an error the client picks the next server until a working server is found or the list is exhausted. Now 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. I see a couple of options: a) The client can try to re-initialize the application as if the client was restarted. b) The client can handle this like it would handle a Disconnect-Peer-Request c) The client can signal a Diameter error to the application (e.g. DIAMETER_APPLICATION_UNSUPPORTED) d) The client can ignore the application and hope that it has implemented an error handling which can cope with this. My point is that a capabilities-update can set a Diameter application into a state that might not have been anticipated by the particular application implementation. Therefore it might be a good idea to give implementors some guidelines on what to keep in mind when extending a Diameter client without regarding the applications. Also, I am probably late to the party and missed the initial discussion about the document but the motivation is not clear to me. Maybe some examples or use-cases can help to understand in which scenarios you envision the capability-updates to be used. Best regards Niklas Victor Fajardo wrote: > Hi Folks, > > > > We would like to progress the capabilities-update draft > (http://tools.ietf.org/html/draft-ietf-dime-capablities-update-00). Ravi > and other folks have commented on this work but its best if we get some > more feedback especially from folks who work on diameter > implementations. It’s a short document and fairly easy reading. We plan > to let this cook in the WG for about a month or so and then take the > next step. If you have concerns, pls state so as well. > > > > Regards, > > victor// > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime -- Niklas Neumann - University of Goettingen, Institute of Computer Science http://user.informatik.uni-goettingen.de/~nneuman1/ Tel: +49 551 39-172053 From niklas.neumann@cs.uni-goettingen.de Tue Aug 25 05:26:38 2009 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 1B4B43A6A7D for ; Tue, 25 Aug 2009 05:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 VT91rFUvYoEn for ; Tue, 25 Aug 2009 05:26:37 -0700 (PDT) Received: from tmailer.gwdg.de (tmailer.gwdg.de [134.76.10.23]) by core3.amsl.com (Postfix) with ESMTP id B90933A6E07 for ; Tue, 25 Aug 2009 05:26:36 -0700 (PDT) Received: from s5.ifi.informatik.uni-goettingen.de ([134.76.81.25] helo=[172.23.0.5]) by mailer.gwdg.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MfugI-00070B-6V; Tue, 25 Aug 2009 13:59:18 +0200 Message-ID: <4A93D1F6.4020507@cs.uni-goettingen.de> Date: Tue, 25 Aug 2009 13:58:46 +0200 From: Niklas Neumann Organization: University of Goettingen User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: lionel.morand@orange-ftgroup.com References: <4A928DE4.50302@cs.uni-goettingen.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: (clean) by exiscan+sophie Cc: dime@ietf.org Subject: Re: [Dime] Comments about Webauth application 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, 25 Aug 2009 12:26:38 -0000 Hey Lionel, thank you for your feedback. WebAuth is actually using the AAR/AAA commands from RFC 4005 and just the corresponding AVPs from RFC 4740 (i.e. SIP-Authenticate, SIP-Authorization, SIP-Authentication-Info). This includes the reuse of the particular AVP codes. However, WebAuth also has a number of small additions to RFC 4740 such as the requested URI or the remote user name/address which is why we don't want to just adopt RFC 4740. I am not sure, that I understood you right about reusing the Application-ID. I don't think you are allowed to just implementing a small part of a Diameter application (i.e. just one request/answer pair) but sill announce the original Application-ID. Best regards Niklas lionel.morand@orange-ftgroup.com wrote: > Hi Niklas, > > See below. > >> -----Message d'origine----- >> De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De >> la part de Niklas Neumann >> Envoyé : lundi 24 août 2009 14:56 >> À : dime@ietf.org >> Objet : [Dime] Comments about Webauth application >> >> Hello everybody, >> >> I would like to address the comments we received during the >> last IETF meeting regarding the Diameter Webauth application. >> If you have missed the presentation, the slides are available here: >> http://www.ietf.org/proceedings/75/slides/dime-8.pdf >> >> >> * Diameter SIP application also includes HTTP digest authentication: >> This is true and WebAuth is actually reusing the AVP >> specifications made in RFC 4740. I do not suppose the >> suggestion is that people should just implement 4740 if they >> just want to use HTTP authentication over Diameter so I do >> not see any problems with that. > > Maybe the question could be: does the use of the MAR/MAA command pair with the Application-id "Diameter SIP Application (6)" fulfil your requirements? > If the answer is "yes", you don't have to create a new application. You can just specify that in the context of Web authentication, MAR/MAA are used for HTTP Digest authentication. If there is no modification to the command ABNF description nor new mandatory AVP to support for webauth, the application-id can be re-used as such. There is no need to implement the whole RFC 4740 "Diameter SIP application" if you want only to support the authentication part. > > Lionel > >> * Corresponding RADIUS specification (RFC 5090) is not >> adopted due to latency issues: >> I cannot really comment if anybody uses RFC 5090 or not. >> However, RFC 5090 obsoletes RFC 4590 so there must have been >> at least some interest to put work into another revision of >> the original RFC. >> Regarding the latency I see how this might be an issue if you >> do the Diameter authentication for every HTTP request. >> However, I think it is more realistic that HTTP servers will >> cache Diameter responses or even open some sort of session >> context which will only be initially authenticated. >> >> >> I really appreciate any of your comments. I think that web >> environments can benefit from authentication and >> authorization standards to make life easier for site >> administrators and to benefit from existing Diameter >> deployments. If there is anything that would make the draft >> more adoptable please let us know. >> >> >> Best regards >> Niklas >> >> -- >> Niklas Neumann - University of Goettingen, Institute of >> Computer Science http://user.informatik.uni-goettingen.de/~nneuman1/ >> Tel: +49 551 39-172053 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> -- Niklas Neumann - University of Goettingen, Institute of Computer Science http://user.informatik.uni-goettingen.de/~nneuman1/ Tel: +49 551 39-172053 From sdecugis@nict.go.jp Wed Aug 26 01:23:34 2009 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 3A7C23A6A20 for ; Wed, 26 Aug 2009 01:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.519 X-Spam-Level: X-Spam-Status: No, score=-0.519 tagged_above=-999 required=5 tests=[AWL=0.836, BAYES_00=-2.599, 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 UUMPc15JCQbd for ; Wed, 26 Aug 2009 01:23:33 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id 636843A6F08 for ; Wed, 26 Aug 2009 01:23:30 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id n7Q8NBOG000077; Wed, 26 Aug 2009 17:23:11 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id n7Q8NB9E005138; Wed, 26 Aug 2009 17:23:11 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id n7Q8NB04005133; Wed, 26 Aug 2009 17:23:11 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 5E0AA16BCF; Wed, 26 Aug 2009 17:23:11 +0900 (JST) Received: from [133.243.146.206] (5gou2f-dhcp46.nict.go.jp [133.243.146.206]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 57DC7165CF; Wed, 26 Aug 2009 17:23:11 +0900 (JST) Message-ID: <4A94F0EF.3080102@nict.go.jp> Date: Wed, 26 Aug 2009 17:23:11 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Qin Wu References: <018101ca24ba$01834ea0$0489ebe0$@telcordia.com> <02f201ca255e$11533620$260ca40a@china.huawei.com> In-Reply-To: <02f201ca255e$11533620$260ca40a@china.huawei.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] [DIME] Comments about AVP for crypto key transport draft 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, 26 Aug 2009 08:23:34 -0000 Hello Qin, In general I agree that a grouped AVP is best suited to transport a Key and its related information: name, lifetime, other (depending on the keys). However, for the efficiency of parsing the message, I personally think that having the key "type" *inside* the grouped AVP is not efficient, since it means that the implementation has to parse the message "in depth" to find the key it is interested in. If we define different grouped AVPs for different key types, we have a better parsing efficiency, and save some space in the message (key type AVP is not needed). In addition, this approach allows to have a different ABNF for each key type (for example, making the Key Name mandatory for DSRK keys, but not for rMSK keys). This is the approach I followed in the draft draft-sdecugis-dime-diameter-erp-01, which I plan to reproduce in the upcoming draft-ietf-dime-erp-01. About the transport of the MSK / rMSK, I am not sure if people will be interested in changing the existing commands to use this more generic approach of grouped AVPs. It is probably not a sufficient reason to update the commands definitions (such as DEA for example), even though the current format is quite strange :-D Anyway, once we agree on the format of the suitable AVP to transport the keys (in the case of ERP: DSRK, rMSK), I have no strong opinion as if it is better to have it defined inside the Diameter ERP document or in a separate document, as you know. Best regards, Sebastien. > In the Diameter ERP document, the AVP of ERP keys are also defined. > However these transport of ERP keys are specific to the ERP > application and can not solve how to transport more than one > cryptographic keys in one message. > -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From pete.mccann@motorola.com Thu Aug 27 08:51:04 2009 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 287C83A707D; Thu, 27 Aug 2009 08:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.411 X-Spam-Level: X-Spam-Status: No, score=-6.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 bLIU+4fc-48h; Thu, 27 Aug 2009 08:51:03 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with ESMTP id 0CA4A3A7014; Thu, 27 Aug 2009 08:51:03 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-5.tower-128.messagelabs.com!1251388263!7876443!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 28674 invoked from network); 27 Aug 2009 15:51:04 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-128.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Aug 2009 15:51:04 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id n7RFp3I6011009; Thu, 27 Aug 2009 08:51:03 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id n7RFp3Ms017805; Thu, 27 Aug 2009 10:51:03 -0500 (CDT) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id n7RFp2ec017799; Thu, 27 Aug 2009 10:51:02 -0500 (CDT) 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, 27 Aug 2009 11:50:41 -0400 Message-ID: <274D46DDEB9F2244B2F1EA66B3FF54BC0582E7AC@de01exm70.ds.mot.com> In-Reply-To: <1A12DEAF-C84D-4789-B9DB-F1D2CDA98474@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gen-ART Review of draft-ietf-dime-nai-routing-02 Thread-Index: Acogpb4UXI0SvO6TRfyd7KrEE6AtKQGiFa4w References: <274D46DDEB9F2244B2F1EA66B3FF54BC05685EA8@de01exm70.ds.mot.com> <4C124F82-50C8-4520-B3FE-7A4420C4DFDB@gmail.com> <274D46DDEB9F2244B2F1EA66B3FF54BC05686338@de01exm70.ds.mot.com> <1A12DEAF-C84D-4789-B9DB-F1D2CDA98474@gmail.com> From: "McCann Peter-A001034" To: "jouni korhonen" , "Dan (Dan) Romascanu" X-CFilter-Loop: Reflected Cc: dime@ietf.org, gen-art@ietf.org, draft-ietf-dime-nai-routing.all@tools.ietf.org Subject: Re: [Dime] Gen-ART Review of draft-ietf-dime-nai-routing-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: Thu, 27 Aug 2009 15:51:04 -0000 Thanks, Jouni. This version addresses all my comments. -Pete jouni korhonen wrote: > Hi Pete, >=20 > I have updated the I-D based on your comments. The -03 version should > be available readily in draft repositories.=20 >=20 > Cheers, > Jouni >=20 >=20 >=20 > On Aug 4, 2009, at 8:41 PM, McCann Peter-A001034 wrote: >=20 >> Hi, Jouni, >>=20 >> Thanks, I went back and re-read Section 2.8 of RFC 3588 and refreshed >> my understanding of Diameter Answer routing. You are correct that >> the reverse path routing is taken care of by the transaction state. >> Perhaps you could add one sentence about the Answer routing with a >> reference to Section 2.8 of RFC 3588? >>=20 >> I suppose using the Application ID for expressing support for the >> feature is ok if that is the will of the working group. >>=20 >> -Pete >>=20 >> jouni korhonen wrote: >>> Hi Peter, >>>=20 >>> Thanks for the review. See my comments inline. >>>=20 >>>=20 >>> On Aug 3, 2009, at 9:17 PM, McCann Peter-A001034 wrote: >>>=20 >>>> I have been selected as the General Area Review Team (Gen-ART) >>>> reviewer for this draft (for background on Gen-ART, please see >>>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>>>=20 >>>> Please resolve these comments along with any other Last Call >>>> comments you may receive.=20 >>>>=20 >>>> Document: draft-ietf-dime-nai-routing-02 >>>> Reviewer: Pete McCann >>>> Review Date: 2009-08-03 >>>> IETF LC End Date: 2009-08-04 >>>> IESG Telechat date: unknown >>>>=20 >>>> Summary: Two major issues need discussion >>>>=20 >>>>=20 >>>> Major issues: >>>>=20 >>>> The draft seems to address only routing of Request commands. What >>>> about Answers? Are Diameter proxies required to re-write the >>>=20 >>> Answers follow the reverse path the request traversed. The answers >>> are processed according to base RFC3588. >>>=20 >>>> Origin-Realm and Origin-Host AVPs as the request gets routed? >>>=20 >>> No. Both Origin-Realm and Origin-Host correspond to the entity that >>> originated the request.=20 >>>=20 >>>> Are they required then to maintain state to map the responses back >>>> to the originating realm? The processing rules seem to strip off >>>=20 >>> Not really. Intermediating agents only need to maintain a >>> transaction state. This is the same as required for normal RFC3588 >>> request-answer processing.=20 >>>=20 >>>> the decoration from the NAI; there might be a need for the home AAA >>>> server to know the path that was taken through the network (routing >>>> the Answer commands is only one possible reason). Maybe the >>>> solution is to provide a decorated Origin-Realm that is recomputed >>>> by each hop. >>>=20 >>> RFC3588 Route-Record AVP already provides this information. I see no >>> reason to go any further here regarding to changes/enhancements to >>> RFC3588 answer processing.=20 >>>=20 >>>=20 >>>>>=20 >>>>> 4.2. Ensuring Backwards Compatibility >>>>>=20 >>>>> Implementations compliant to this specification MUST define a new >>>>> Diameter application. This requirement is set to guarantee >>>>> backwards compatibility with existing Diameter implementations, >>>>> applications and deployments. Diameter agents not compliant with >>>>> this specification will not advertise support for these new >>>>> applications that implement the enhanced routing solution based on >>>>> Decorated NAIs and will therefore be bypassed. >>>>=20 >>>> This requirement troubles me; does this mean that every Diameter >>>> application will need to define a whole set of Application-IDs, >>>> based on the cross-product of every feature that gets introduced? >>>> Maybe this is a general problem with Diameter application >>>> versioning, and it's too late to fix it. Is there a better way to >>>> somehow indicate support for this feature? >>>=20 >>> It indeed is a general issue with Diameter application versioning >>> (some SDOs have introduced their own versioning schemes to avoid >>> defining new applications for e.g. every new release). There was >>> lengthy discussion of possible choices how to solve it for this I-D. >>> Requiring a new application seemed to be the easiest way to get >>> forward. Generally, one application can/should include several "new >>> features" so the explosion on applications should not become a >>> problem..=20 >>>=20 >>>>=20 >>>> Minor issues: >>>>=20 >>>>=20 >>>> Nits/editorial comments: >>>>=20 >>>> End of Section 3: >>>>=20 >>>>> [RFC5113] Section 2.3. also discusses NAI decoration related >>>>> issues with EAP [RFC3748] in general. >>>> Seems there is an extra period after "Section 2.3". Suggest >>>> changing the reference pointer to text, i.e., >>>>> Section 2.3 of RFC5113 also discusses NAI decoration related >>>>> issues with EAP [RFC3748] in general. >>>>=20 >>>> Section 4.1: >>>>=20 >>>>> an uniform >>>> SHOULD BE: >>>>> a uniform >>>>=20 >>>> Section 6: >>>>> In this case the NAS to the Diameter server AAA communication rely >>>> on >>>> SHOULD BE: >>>>> In this case the NAS to Diameter server AAA communication relies >>>>> on=20 >>>=20 >>> Thanks. Will fix these. >>>=20 >>> Cheers, >>> Jouni From root@core3.amsl.com Thu Aug 27 12:30:01 2009 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8E11028C2E5; Thu, 27 Aug 2009 12:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090827193001.8E11028C2E5@core3.amsl.com> Date: Thu, 27 Aug 2009 12:30:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-nat-control-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, 27 Aug 2009 19:30: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 NAT Control Application Author(s) : F. Brockners, V. Singh, S. Bhandari, V. Fajardo Filename : draft-ietf-dime-nat-control-00.txt Pages : 41 Date : 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-nat-control-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-nat-control-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-8-27122912.I-D@ietf.org> --NextPart-- From gwz@net-zen.net Thu Aug 27 13:39:26 2009 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 D3F7828C0E5 for ; Thu, 27 Aug 2009 13:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.809 X-Spam-Level: X-Spam-Status: No, score=-1.809 tagged_above=-999 required=5 tests=[AWL=0.790, 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 HFtVYmNNx76p for ; Thu, 27 Aug 2009 13:39:25 -0700 (PDT) Received: from smtpauth13.prod.mesa1.secureserver.net (smtpauth13.prod.mesa1.secureserver.net [64.202.165.37]) by core3.amsl.com (Postfix) with SMTP id C97603A6E96 for ; Thu, 27 Aug 2009 13:39:25 -0700 (PDT) Received: (qmail 30163 invoked from network); 27 Aug 2009 20:39:32 -0000 Received: from unknown (71.231.55.1) by smtpauth13.prod.mesa1.secureserver.net (64.202.165.37) with ESMTP; 27 Aug 2009 20:39:30 -0000 From: "Glen Zorn" To: "'Sebastien Decugis'" References: <018101ca24ba$01834ea0$0489ebe0$@telcordia.com> <02f201ca255e$11533620$260ca40a@china.huawei.com> <4A94F0EF.3080102@nict.go.jp> In-Reply-To: <4A94F0EF.3080102@nict.go.jp> Date: Thu, 27 Aug 2009 13:39:26 -0700 Organization: Network Zen Message-ID: <002301ca2756$78339e80$689adb80$@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: AcomJoqig5U2cAm7Rgab6OOxTmHAkABLJszQ Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] [DIME] Comments about AVP for crypto key transport draft 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, 27 Aug 2009 20:39:26 -0000 Sebastien Decugis [mailto://sdecugis@nict.go.jp] writes: > Hello Qin, > > In general I agree that a grouped AVP is best suited to transport a Key > and its related information: name, lifetime, other (depending on the > keys). > > However, for the efficiency of parsing the message, I personally think > that having the key "type" *inside* the grouped AVP is not efficient, > since it means that the implementation has to parse the message "in > depth" to find the key it is interested in. In theory this sounds good. If, however, an implementation receives _any_ key that it can't use (or isn't interested in) this poses a major security problem. > If we define different > grouped AVPs for different key types, we have a better parsing > efficiency, and save some space in the message (key type AVP is not > needed). In addition, this approach allows to have a different ABNF for > each key type (for example, making the Key Name mandatory for DSRK > keys, > but not for rMSK keys). I'm not really sure why this would be useful... > This is the approach I followed in the draft > draft-sdecugis-dime-diameter-erp-01, which I plan to reproduce in the > upcoming draft-ietf-dime-erp-01. > > About the transport of the MSK / rMSK, I am not sure if people will be > interested in changing the existing commands to use this more generic > approach of grouped AVPs. It is probably not a sufficient reason to > update the commands definitions (such as DEA for example), even though > the current format is quite strange :-D I'm not sure that I understand this: it doesn't appear to me that the definition of the DEA command would need to be changed: the EAP-Master-Session-Key & EAP-Key-Name AVPs are both optional & the new AVP would certainly qualify as [ * AVP ] ;-). > Anyway, once we agree on the format of the suitable AVP to transport > the > keys (in the case of ERP: DSRK, rMSK), I have no strong opinion as if > it > is better to have it defined inside the Diameter ERP document or in a > separate document, as you know. > > Best regards, > Sebastien. > > > In the Diameter ERP document, the AVP of ERP keys are also defined. > > However these transport of ERP keys are specific to the ERP > > application and can not solve how to transport more than one > > cryptographic keys in one message. > > > > -- > 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 sunseawq@huawei.com Thu Aug 27 19:08:33 2009 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 5D97E3A6D39 for ; Thu, 27 Aug 2009 19:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[AWL=1.997, 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 WfXJn+V9t2UU for ; Thu, 27 Aug 2009 19:08:32 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 66D623A6C61 for ; Thu, 27 Aug 2009 19:08:17 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KP200DQXDXYPG@szxga04-in.huawei.com> for dime@ietf.org; Fri, 28 Aug 2009 10:08:22 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KP200MY2DXY10@szxga04-in.huawei.com> for dime@ietf.org; Fri, 28 Aug 2009 10:08:22 +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 <0KP20099KDXYS3@szxml04-in.huawei.com> for dime@ietf.org; Fri, 28 Aug 2009 10:08:22 +0800 (CST) Date: Fri, 28 Aug 2009 10:08:21 +0800 From: Qin Wu To: Sebastien Decugis Message-id: <00e701ca2784$6b664030$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.3138 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <018101ca24ba$01834ea0$0489ebe0$@telcordia.com> <02f201ca255e$11533620$260ca40a@china.huawei.com> <4A94F0EF.3080102@nict.go.jp> Cc: dime@ietf.org Subject: Re: [Dime] [DIME] Comments about AVP for crypto key transport draft 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, 28 Aug 2009 02:08:33 -0000 Hi, Sebastien: ----- Original Message ----- From: "Sebastien Decugis" To: "Qin Wu" Cc: Sent: Wednesday, August 26, 2009 4:23 PM Subject: Re: [Dime] [DIME] Comments about AVP for crypto key transport draft > Hello Qin, > > In general I agree that a grouped AVP is best suited to transport a Key > and its related information: name, lifetime, other (depending on the keys). > However, for the efficiency of parsing the message, I personally think > that having the key "type" *inside* the grouped AVP is not efficient, > since it means that the implementation has to parse the message "in > depth" to find the key it is interested in. [Qin]: I think how many key materials need to be transported is specified in the RFC5296.e.g, In Explicit ERP boostrapping, ,both rMSK and DSRK is mandatory to be derived in the home Server based on local domain name and transported to the local Server, the local server should know this beforehand. Also as decribed in the EAP-key-type, the key type has been sorted in the ascending order. the Local Server need not guess which key type is DSRK and which key type is rMSK. e.g., there are two grouped AVP encapsulated in one Diameter message, the local server can easily know the first grouped AVP as DSRK, the second grouped AVP as rMSK. I am not sure whether this way can be seen an inefficient way? :) On the other hand, when the local server recieve a set of AVP from the home server, AVPs validation is necessary, the parsing can be done with validation together. >If we define different > grouped AVPs for different key types, we have a better parsing > efficiency, and save some space in the message (key type AVP is not > needed). In addition, this approach allows to have a different ABNF for > each key type (for example, making the Key Name mandatory for DSRK keys, > but not for rMSK keys). [Qin]: As described in RFC5296, the rMSK and DSRK are both mandatory to be transported from the home Server to the local server during the ERP bootstrapping. As we know, ERP has no indpendent key derivation mechanism and should depend on EAP key management to derive the Re-authentication Root keys and rMSK. After bootstrapping, the local Sever obtain the DSRK, the ERP with the local server can be applied in the local domain, in this case, only rMSK is mandatory to be transported from the local Server to the authenticator. On the other hand, as you indicated, if we only allow home server derive DSRK and transport it to the local server, and then the local server take responsiblity to derive rMSK and transport it to the authentication, I am afraid it is not efficienty way to do bootstrapping, am I right? >This is the approach I followed in the draft > draft-sdecugis-dime-diameter-erp-01, which I plan to reproduce in the > upcoming draft-ietf-dime-erp-01. > > About the transport of the MSK / rMSK, I am not sure if people will be > interested in changing the existing commands to use this more generic > approach of grouped AVPs. It is probably not a sufficient reason to > update the commands definitions (such as DEA for example), even though > the current format is quite strange :-D [Qin] We don't change the DER/DEA. MSK and rMSK are both EAP based transported key material depend on the same EAP key architecture. Also they have the same parents.:) > Anyway, once we agree on the format of the suitable AVP to transport the > keys (in the case of ERP: DSRK, rMSK), I have no strong opinion as if it > is better to have it defined inside the Diameter ERP document or in a > separate document, as you know. > > Best regards, > Sebastien. > >> In the Diameter ERP document, the AVP of ERP keys are also defined. >> However these transport of ERP keys are specific to the ERP >> application and can not solve how to transport more than one >> cryptographic keys in one message. >> > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > From sdecugis@nict.go.jp Thu Aug 27 19:41:59 2009 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 09C8B3A6B09 for ; Thu, 27 Aug 2009 19:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.371 X-Spam-Level: X-Spam-Status: No, score=0.371 tagged_above=-999 required=5 tests=[AWL=-0.473, 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 Kt4D34caWgPr for ; Thu, 27 Aug 2009 19:41:57 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id 26D4C3A691A for ; Thu, 27 Aug 2009 19:41:56 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id n7S2fwpv017723; Fri, 28 Aug 2009 11:41:58 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id n7S2fwOt025060; Fri, 28 Aug 2009 11:41:58 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id n7S2fw7h025051; Fri, 28 Aug 2009 11:41:58 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 3C85E163F7; Fri, 28 Aug 2009 11:41:58 +0900 (JST) Received: from [133.243.146.206] (5gou2f-dhcp46.nict.go.jp [133.243.146.206]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 29BBC271F; Fri, 28 Aug 2009 11:41:58 +0900 (JST) Message-ID: <4A9743F4.60404@nict.go.jp> Date: Fri, 28 Aug 2009 11:41:56 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Glen Zorn References: <018101ca24ba$01834ea0$0489ebe0$@telcordia.com> <02f201ca255e$11533620$260ca40a@china.huawei.com> <4A94F0EF.3080102@nict.go.jp> <002301ca2756$78339e80$689adb80$@net> In-Reply-To: <002301ca2756$78339e80$689adb80$@net> X-Enigmail-Version: 0.96.0 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: dime@ietf.org Subject: Re: [Dime] [DIME] Comments about AVP for crypto key transport draft 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, 28 Aug 2009 02:41:59 -0000 Hi Glen, Please see my further comments inside. Glen Zorn a écrit : >> However, for the efficiency of parsing the message, I personally think >> that having the key "type" *inside* the grouped AVP is not efficient, >> since it means that the implementation has to parse the message "in >> depth" to find the key it is interested in. >> > > In theory this sounds good. If, however, an implementation receives _any_ > key that it can't use (or isn't interested in) this poses a major security > problem. > I don't understand how this is related to the format for conveying the key. On the contrary, I'd think that with different AVP codes for different types of keys, when the implementation understand the AVP code, we can assume that it fully understand the content of the AVP. If you have a generic "key" container, your implementation is able to extract the key content, even if it does not understand the value inside the Key-Type AVP. I would therefore think that my approach is slightly more secure in that sense. What do you think? >> If we define different >> grouped AVPs for different key types, we have a better parsing >> efficiency, and save some space in the message (key type AVP is not >> needed). In addition, this approach allows to have a different ABNF for >> each key type (for example, making the Key Name mandatory for DSRK >> keys, >> but not for rMSK keys). >> > > I'm not really sure why this would be useful... > I believe it is more generic, which is good since we are trying to define a generic container :) For some key usages TBD, it might be interesting to request for example the Key-Scope or Key-Algorithm (not sure if this means anything) or Key-Strength in the ABNF, when they are really needed by the application using this key. I personally think a good approach for the document is to define all the AVP that contain key data and metadata (key, key-name, key-lifetime, key-scope, key-strengh, ... it can be updated when needed) and propose a "template" for other documents to use these new AVPs, an example grouped AVP. Then, each Diameter application that need to transport some key material define its own grouped AVP with its particular ABNF and semantics (depending on the application requirements) and re-uses these generic AVPs inside the particular grouped AVP. >> About the transport of the MSK / rMSK, I am not sure if people will be >> interested in changing the existing commands to use this more generic >> approach of grouped AVPs. It is probably not a sufficient reason to >> update the commands definitions (such as DEA for example), even though >> the current format is quite strange :-D >> > > I'm not sure that I understand this: it doesn't appear to me that the > definition of the DEA command would need to be changed: the > EAP-Master-Session-Key & EAP-Key-Name AVPs are both optional & the new AVP > would certainly qualify as [ * AVP ] ;-). > You are right, it is my mistake. RFC4072 (Diameter EAP) only say that DEA MAY include this AVP, so it is no problem to have a new container. Anyway, on an implementation point of view, this would be very confusing (again, interoperability is getting worse)... :-( Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sdecugis@nict.go.jp Thu Aug 27 20:10:03 2009 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 EBB463A6BA9 for ; Thu, 27 Aug 2009 20:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.634 X-Spam-Level: X-Spam-Status: No, score=-0.634 tagged_above=-999 required=5 tests=[AWL=0.721, BAYES_00=-2.599, 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 aMXJwBy453f6 for ; Thu, 27 Aug 2009 20:10:03 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:2f8:29::3]) by core3.amsl.com (Postfix) with ESMTP id 7F4EC3A6822 for ; Thu, 27 Aug 2009 20:10:02 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id n7S39ssl014721; Fri, 28 Aug 2009 12:09:54 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id n7S39sjE028700; Fri, 28 Aug 2009 12:09:54 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id n7S39sTN028697; Fri, 28 Aug 2009 12:09:54 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 9957F539B; Fri, 28 Aug 2009 12:09:54 +0900 (JST) Received: from [133.243.146.206] (5gou2f-dhcp46.nict.go.jp [133.243.146.206]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 9239E1EBB; Fri, 28 Aug 2009 12:09:54 +0900 (JST) Message-ID: <4A974A80.8020807@nict.go.jp> Date: Fri, 28 Aug 2009 12:09:52 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Qin Wu References: <018101ca24ba$01834ea0$0489ebe0$@telcordia.com> <02f201ca255e$11533620$260ca40a@china.huawei.com> <4A94F0EF.3080102@nict.go.jp> <00e701ca2784$6b664030$260ca40a@china.huawei.com> In-Reply-To: <00e701ca2784$6b664030$260ca40a@china.huawei.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: dime@ietf.org Subject: Re: [Dime] [DIME] Comments about AVP for crypto key transport draft 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, 28 Aug 2009 03:10:04 -0000 Hi Qin, Thank you for reply. Please see my comments inline. Qin Wu a écrit : > [Qin]: I think how many key materials need to be transported is specified in the RFC5296.e.g, In Explicit ERP boostrapping, ,both rMSK and DSRK is mandatory to be derived in the home Server based on local domain name and transported to the local Server, the local server should know this beforehand. Also as decribed in the EAP-key-type, the key type has been sorted in the ascending order. the Local Server > need not guess which key type is DSRK and which key type is rMSK. e.g., there are two grouped AVP encapsulated in one Diameter message, > the local server can easily know the first grouped AVP as DSRK, the second grouped AVP as rMSK. I am not sure whether this way can be seen > an inefficient way? :) > On the other hand, when the local server recieve a set of AVP from the home server, AVPs validation is necessary, the parsing can be done with validation together. > I had missed the ordering of the AVPs by key types, sorry. What I want to avoid is that the peer who is interested in only one of the keys in the message has to parse all the grouped AVPS. For example the local ERP server which receives a DEA with explicit bootstrapping exchange, i.e. containing both rMSK and DSRK, has to extract the DSRK but can ignore the rMSK. Relying on the order for this purpose may work (as long as no other key is added in the message in the [*AVP] rule) but is seems a little fragile to me. About validation, if you want to check that your message really contains the rMSK and DSRK, you really have to parse the grouped AVPs of type "key" to check they key-types. With a different AVP code for each grouped AVP, you only parse the top-level AVPs, without parsing inside the grouped AVPs. That is what I meant by "efficiency" ;) > On the other hand, as you indicated, if we only allow home server derive DSRK and transport it to the local server, and then the local server take responsiblity to derive rMSK and transport it to the authentication, I am afraid it is not efficienty way to do bootstrapping, am I right? > I am sorry if I implied this at some point. It is not my intent. I don't even think this could work with the current design of ERP explicit bootstrapping. I did not mean to imply any change to the ERP mechanism. >> About the transport of the MSK / rMSK, I am not sure if people will be >> interested in changing the existing commands to use this more generic >> approach of grouped AVPs. It is probably not a sufficient reason to >> update the commands definitions (such as DEA for example), even though >> the current format is quite strange :-D >> > > [Qin] We don't change the DER/DEA. MSK and rMSK are both EAP based transported key material > depend on the same EAP key architecture. Also they have the same parents.:) > If I understand correctly, the intent was to replace the use of EAP-Master-Session-Key AVP by a new generic AVP to transport this MSK or rMSK, right? BTW sorry about my comment on the AVP format, I confounded with the format in RADIUS... The format in Diameter is straightforward. Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sdecugis@nict.go.jp Fri Aug 28 02:44:17 2009 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 2102C3A67EB for ; Fri, 28 Aug 2009 02:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.754 X-Spam-Level: X-Spam-Status: No, score=-0.754 tagged_above=-999 required=5 tests=[AWL=0.601, BAYES_00=-2.599, 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 4qI7zKr2edno for ; Fri, 28 Aug 2009 02:44:16 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:2f8:29::3]) by core3.amsl.com (Postfix) with ESMTP id 9483E28C10D for ; Fri, 28 Aug 2009 02:44:15 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id n7S9iLQU007329 for ; Fri, 28 Aug 2009 18:44:21 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id n7S9iLlp007692 for ; Fri, 28 Aug 2009 18:44:21 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id n7S9iLXC007689 for ; Fri, 28 Aug 2009 18:44:21 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 307621668A for ; Fri, 28 Aug 2009 18:44:21 +0900 (JST) Received: from [133.243.146.206] (5gou2f-dhcp46.nict.go.jp [133.243.146.206]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 2B27416555 for ; Fri, 28 Aug 2009 18:44:21 +0900 (JST) Message-ID: <4A97A6ED.2060101@nict.go.jp> Date: Fri, 28 Aug 2009 18:44:13 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: dime@ietf.org X-Enigmail-Version: 0.96.0 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Dime] draft-ietf-dime-erp-01 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, 28 Aug 2009 09:44:17 -0000 Hello all, A new version of Diameter ERP document has just been submitted. It should appear soon in the draft repository [1]. The main changes from the previous version are: - We define a new Diameter Application for ERP (as decided during last IETF meeting). This allows the routing of Diameter messages containing ERP payload to the appropriate realm and server, and permits more flexibility in the deployment of ERP : with the previous design from version -00, the ER server had to be collocated with the EAP server (note: it was not written clearly in the document, but it was the only working situation), which might result in some deployment and scalability issues. This change has a profound impact on the way Diameter ERP works, and explains why so much content has changed in the document. - The format of the newly defined AVP has also changed: we now define two grouped AVP to transport the key request and key material. Grouped AVP allow a more efficient parsing of the message, and keeps the correlation of related information such as key name, key lifetime... - A section "Open Issues" has been added. It lists the major design challenges remaining on Diameter ERP, to be completed and addressed... Thank you, Best regards, Sebastien. [1] http://tools.ietf.org/html/draft-ietf-dime-erp-01 -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From root@core3.amsl.com Fri Aug 28 15:15:01 2009 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A19993A6FB6; Fri, 28 Aug 2009 15:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090828221501.A19993A6FB6@core3.amsl.com> Date: Fri, 28 Aug 2009 15:15:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-erp-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: Fri, 28 Aug 2009 22: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 Support for EAP Re-authentication Protocol Author(s) : L. Dondeti, J. Bournelle, L. Morand, S. Decugis Filename : draft-ietf-dime-erp-01.txt Pages : 18 Date : 2009-8-28 EAP Re-authentication Protocol (ERP) defines extensions to the Extensible Authentication Protocol (EAP) to support efficient re- authentication between the EAP peer and an EAP re-authentication server through an EAP/ERP authenticator. This document specifies Diameter support for ERP. It defines a new Diameter ERP application to transport ERP messages between authenticator and ERP server, and a set of new AVPs that can be used to transport the cryptographic material needed by ERP server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-erp-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-erp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-8-28150023.I-D@ietf.org> --NextPart-- From sunseawq@huawei.com Sun Aug 30 23:16:04 2009 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 53EE228C129 for ; Sun, 30 Aug 2009 23:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.651 X-Spam-Level: * X-Spam-Status: No, score=1.651 tagged_above=-999 required=5 tests=[AWL=-0.562, BAYES_20=-0.74, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6, MIME_BASE64_TEXT=1.753] 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 R24GaYSswanJ for ; Sun, 30 Aug 2009 23:16:03 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id B5CBE3A6958 for ; Sun, 30 Aug 2009 23:16:02 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KP800GJ49EYW6@szxga01-in.huawei.com> for dime@ietf.org; Mon, 31 Aug 2009 14:16:10 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KP800IN99EYDJ@szxga01-in.huawei.com> for dime@ietf.org; Mon, 31 Aug 2009 14:16:10 +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 <0KP8000LQ9EUTM@szxml04-in.huawei.com> for dime@ietf.org; Mon, 31 Aug 2009 14:16:10 +0800 (CST) Date: Mon, 31 Aug 2009 14:16:17 +0800 From: Qin Wu To: Sebastien Decugis Message-id: <00e901ca2a02$8ceaa6d0$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.3138 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <018101ca24ba$01834ea0$0489ebe0$@telcordia.com> <02f201ca255e$11533620$260ca40a@china.huawei.com> <4A94F0EF.3080102@nict.go.jp> <00e701ca2784$6b664030$260ca40a@china.huawei.com> <4A974A80.8020807@nict.go.jp> Cc: Glen Zorn , dime@ietf.org Subject: Re: [Dime] [DIME] Comments about AVP for crypto key transport draft 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, 31 Aug 2009 06:16:04 -0000 SGksIFNlYmFzdGllbiwgR2xlbjoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9t OiAiU2ViYXN0aWVuIERlY3VnaXMiIDxzZGVjdWdpc0BuaWN0LmdvLmpwPg0KVG86ICJRaW4gV3Ui IDxzdW5zZWF3cUBodWF3ZWkuY29tPg0KQ2M6IDxkaW1lQGlldGYub3JnPg0KU2VudDogRnJpZGF5 LCBBdWd1c3QgMjgsIDIwMDkgMTE6MDkgQU0NClN1YmplY3Q6IFJlOiBbRGltZV0gW0RJTUVdIENv bW1lbnRzIGFib3V0IEFWUCBmb3IgY3J5cHRvIGtleSB0cmFuc3BvcnQgZHJhZnQNCg0KDQo+IEhp IFFpbiwNCj4gDQo+IFRoYW5rIHlvdSBmb3IgcmVwbHkuIFBsZWFzZSBzZWUgbXkgY29tbWVudHMg aW5saW5lLg0KPiANCj4gUWluIFd1IGEg6WNyaXQgOg0KPj4gW1Fpbl06ICBJIHRoaW5rIGhvdyBt YW55IGtleSBtYXRlcmlhbHMgbmVlZCB0byBiZSB0cmFuc3BvcnRlZCBpcyBzcGVjaWZpZWQgaW4g dGhlIFJGQzUyOTYuZS5nLCBJbiBFeHBsaWNpdCBFUlAgYm9vc3RyYXBwaW5nLCAsYm90aCByTVNL IGFuZCBEU1JLIGlzIG1hbmRhdG9yeSB0byBiZSBkZXJpdmVkIGluIHRoZSBob21lIFNlcnZlciBi YXNlZCBvbiBsb2NhbCBkb21haW4gbmFtZSBhbmQgdHJhbnNwb3J0ZWQgdG8gdGhlIGxvY2FsIFNl cnZlciwgdGhlIGxvY2FsIHNlcnZlciBzaG91bGQga25vdyB0aGlzIGJlZm9yZWhhbmQuIEFsc28g YXMgZGVjcmliZWQgaW4gdGhlIEVBUC1rZXktdHlwZSwgdGhlIGtleSB0eXBlIGhhcyBiZWVuIHNv cnRlZCBpbiB0aGUgYXNjZW5kaW5nIG9yZGVyLiB0aGUgTG9jYWwgU2VydmVyDQo+PiBuZWVkIG5v dCBndWVzcyB3aGljaCBrZXkgdHlwZSBpcyBEU1JLIGFuZCB3aGljaCBrZXkgdHlwZSBpcyByTVNL LiBlLmcuLCB0aGVyZSBhcmUgdHdvIGdyb3VwZWQgQVZQIGVuY2Fwc3VsYXRlZCBpbiBvbmUgRGlh bWV0ZXIgbWVzc2FnZSwNCj4+IHRoZSBsb2NhbCBzZXJ2ZXIgY2FuIGVhc2lseSBrbm93IHRoZSBm aXJzdCBncm91cGVkIEFWUCBhcyBEU1JLLCB0aGUgc2Vjb25kIGdyb3VwZWQgQVZQIGFzIHJNU0su IEkgYW0gbm90IHN1cmUgd2hldGhlciB0aGlzIHdheSBjYW4gYmUgc2Vlbg0KPj4gYW4gaW5lZmZp Y2llbnQgd2F5PyA6KQ0KPj4gT24gdGhlIG90aGVyIGhhbmQsIHdoZW4gdGhlIGxvY2FsIHNlcnZl ciByZWNpZXZlIGEgc2V0IG9mIEFWUCBmcm9tIHRoZSBob21lIHNlcnZlciwgQVZQcyB2YWxpZGF0 aW9uIGlzIG5lY2Vzc2FyeSwgdGhlIHBhcnNpbmcgY2FuIGJlIGRvbmUgd2l0aCB2YWxpZGF0aW9u IHRvZ2V0aGVyLg0KPj4gICANCj4gSSBoYWQgbWlzc2VkIHRoZSBvcmRlcmluZyBvZiB0aGUgQVZQ cyBieSBrZXkgdHlwZXMsIHNvcnJ5LiBXaGF0IEkgd2FudA0KPiB0byBhdm9pZCBpcyB0aGF0IHRo ZSBwZWVyIHdobyBpcyBpbnRlcmVzdGVkIGluIG9ubHkgb25lIG9mIHRoZSBrZXlzIGluDQo+IHRo ZSBtZXNzYWdlIGhhcyB0byBwYXJzZSBhbGwgdGhlIGdyb3VwZWQgQVZQUy4gRm9yIGV4YW1wbGUg dGhlIGxvY2FsIEVSUA0KPiBzZXJ2ZXIgd2hpY2ggcmVjZWl2ZXMgYSBERUEgd2l0aCBleHBsaWNp dCBib290c3RyYXBwaW5nIGV4Y2hhbmdlLCBpLmUuDQo+IGNvbnRhaW5pbmcgYm90aCByTVNLIGFu ZCBEU1JLLCBoYXMgdG8gZXh0cmFjdCB0aGUgRFNSSyBidXQgY2FuIGlnbm9yZQ0KPiB0aGUgck1T Sy4NCj4gUmVseWluZyBvbiB0aGUgb3JkZXIgZm9yIHRoaXMgcHVycG9zZSBtYXkgd29yayAoYXMg bG9uZyBhcyBubyBvdGhlciBrZXkNCj4gaXMgYWRkZWQgaW4gdGhlIG1lc3NhZ2UgaW4gdGhlIFsq QVZQXSBydWxlKSBidXQgaXMgc2VlbXMgYSBsaXR0bGUNCj4gZnJhZ2lsZSB0byBtZS4NCj4gDQo+ IEFib3V0IHZhbGlkYXRpb24sIGlmIHlvdSB3YW50IHRvIGNoZWNrIHRoYXQgeW91ciBtZXNzYWdl IHJlYWxseSBjb250YWlucw0KPiB0aGUgck1TSyBhbmQgRFNSSywgeW91IHJlYWxseSBoYXZlIHRv IHBhcnNlIHRoZSBncm91cGVkIEFWUHMgb2YgdHlwZQ0KPiAia2V5IiB0byBjaGVjayB0aGV5IGtl eS10eXBlcy4gV2l0aCBhIGRpZmZlcmVudCBBVlAgY29kZSBmb3IgZWFjaA0KPiBncm91cGVkIEFW UCwgeW91IG9ubHkgcGFyc2UgdGhlIHRvcC1sZXZlbCBBVlBzLCB3aXRob3V0IHBhcnNpbmcgaW5z aWRlDQo+IHRoZSBncm91cGVkIEFWUHMuIFRoYXQgaXMgd2hhdCBJIG1lYW50IGJ5ICJlZmZpY2ll bmN5IiA7KQ0KDQpbUWluXTogSSBhbSBnbGFkIHlvdSBhZ3JlZSB3aXRoIHVzIHRvIGRlZmluZSBn cm91cGVkIEFWUCB0byBjb250YWluIGNvbnRleHQgb2Yga2V5IHVzYWdlLg0KSXQgc2VlbXMgd2Ug aGF2ZSB0d28gY2hvaWNlcyBmb3IgZGVmaW5pbmcgZ3JvdXBlZCBBVlANCmEpLiB0aGUgc2FtZSBB VlAgY29kZSBmb3IgRFNSSyBhbmQgck1TSw0KYikuIHRoZSBkaWZmZXJlbnQgQVZQIGNvZGUgZm9y IERTUksgYW5kIHJNU0sgcmVzcGVjdGl2ZWx5DQpSZWdhcmRpbmcgYSksIGFzIHlvdSBzYWlkLCB0 aGUgZGVlcCBwYXJzaW5nIG9mIGtleSB0eXBlcyBpbiB0aGUgZ3JvdXBlZCBBVlAgaXMgcmVxdWly ZWQuIENvbXBhcmVkIHdpdGggYSksIA0KYikgb25seSBuZWVkcyB0byBwYXJzZSB0aGUgdG9wIGxl dmVsIGdyb3VwZWQgQVZQLiBJdCBpcyB0cnVlLiBXZSBuZWVkIHRvIHRoaW5rIGFib3V0IGl0IGNh cmVmdWxseS4NCkhvd2V2ZXIsIG9uIHRoZSBvdGhlciBoYW5kLCB3aGVuIHRoZSBsb2NhbCBzZXJ2 ZXIgcmVjaWV2ZXMgQUFBIG1lc3NhZ2UgaW5jbHVkaW5nIERTUksgYW5kIHJNU0sgZnJvbSB0aGUg aG9tZSBzZXJ2ZXIsIGl0IGRvZXMgbm90IHNpbXBseSBmb3J3YXJkIHRoZSBBQUEgbWVzc2FnZSB0 byB0aGUgZ2l2ZW4gYXV0aGVudGljYXRvciwgaXQgbmVlZHMgdG8gdGFrZSBvdXQgdGhlIGdyb3Vw ZWQgQVZQIGZvciBEU1JLIGFuZCBjaGVjayB0aGUgZm9ybWF0IHZhbGlkaWNpdHkgb2Ygck1TSywg YW5kIHRoZW4gaW5jbHVkZSByTVNLIGluIHRoZSBBQUEgbWVzc2FnZSBhbmQgc2VuZCBpdCB0byB0 aGUgZ2l2ZW4gYXV0aGVudGljYXRvci4NCkFzIGZvciBiKSwgU3VwcG9zZSB0aGUgbG9jYWwgc2Vy dmVyIG9ubHkgY2hlY2tzIHRoZSB0b3AgbGV2ZWwgZ3JvdXBlZCBBVlAgb2Ygck1TSyBhbmQgZG9u J3QgY2hlY2sgdGhlIGluc2lkZSBBVlAsIGUuZy4sIHRoZSBsaWZldGltZSBvZiByTVNLIGlzIHpl cm8sIHRoZSBsZW5ndGggb2Ygck1TSyBpcyB6ZXJvLCBpdCBzZWVtcyB1c2VsZXNzIGZvciB0aGUg YXV0aGVudGljYXRvciB0byByZWNpZXZlIHN1Y2ggck1TSy4gSWYgdGhlIGluc2lkZSBBVlAgb2Yg IHJNU0sgaXMgbm90IGNoZWNrZWQgYnkgdGhlIGxvY2FsIHNlcnZlciBhbmQgZGlyZWN0bHkgdHJh bnNwb3J0ZWQgdG8gdGhlIGF1dGhlbnRpY2F0b3IsIGl0IGlzIGEgbGl0dGxlIGZyYWdpbGUgdG9v KEkgZ3Vlc3MgdGhpcyBpcyB3aGF0IEdsZW4gd2FudCB0byBwb2ludCBvdXQgYXMgd2VsbCBpbiB0 aGUgcHJldmlvdXMgbWFpbCkuU28gSSB3b25kZXIgaG93IHRoZSBsb2NhbCBTZXJ2ZXIgcHJvY2Vz cyB0aGUgRFNSSyxyTVNLIGFuZCBvdGhlciBrZXlzLCBlc3BlY2lhbGx5IG1vcmUgdGhhbiB0d28g RUFQLWJhc2VkIGtleSBtYXRlcmlhbHMgbmVlZCB0byBiZSB0cmFuc3BvcnRlZCwgZS5nLiwgRFNS SywgRFNVU1JLLCByTVNLIGFyZSB0cmFuc3BvcnRlZCBzaW11dGFuZW91c2x5IHRvIHRoZSBsb2Nh bCBFUi4gU2hhbGwgd2UgIG5lZWQgdG8gZGVmaW5lIGVhY2ggZ3JvdXBlZCBjb250YWluZXIgZm9y IGVhY2gga2V5LCB3aGF0IHRoZSBsb2NhbCBTZXJ2ZXIgc2hvdWxkIGRvPyANCg0KPj4gT24gdGhl IG90aGVyIGhhbmQsIGFzIHlvdSBpbmRpY2F0ZWQsIGlmIHdlIG9ubHkgYWxsb3cgaG9tZSBzZXJ2 ZXIgZGVyaXZlIERTUksgYW5kIHRyYW5zcG9ydCBpdCB0byB0aGUgbG9jYWwgc2VydmVyLCBhbmQg dGhlbiB0aGUgbG9jYWwgc2VydmVyIHRha2UgcmVzcG9uc2libGl0eSB0byBkZXJpdmUgck1TSyBh bmQgdHJhbnNwb3J0IGl0IHRvIHRoZSBhdXRoZW50aWNhdGlvbiwgSSBhbSBhZnJhaWQgaXQgaXMg bm90IGVmZmljaWVudHkgd2F5IHRvIGRvIGJvb3RzdHJhcHBpbmcsIGFtIEkgcmlnaHQ/DQo+PiAg IA0KPiBJIGFtIHNvcnJ5IGlmIEkgaW1wbGllZCB0aGlzIGF0IHNvbWUgcG9pbnQuIEl0IGlzIG5v dCBteSBpbnRlbnQuIEkgZG9uJ3QNCj4gZXZlbiB0aGluayB0aGlzIGNvdWxkIHdvcmsgd2l0aCB0 aGUgY3VycmVudCBkZXNpZ24gb2YgRVJQIGV4cGxpY2l0DQo+IGJvb3RzdHJhcHBpbmcuDQo+IEkg ZGlkIG5vdCBtZWFuIHRvIGltcGx5IGFueSBjaGFuZ2UgdG8gdGhlIEVSUCBtZWNoYW5pc20uDQo+ Pj4gQWJvdXQgdGhlIHRyYW5zcG9ydCBvZiB0aGUgTVNLIC8gck1TSywgSSBhbSBub3Qgc3VyZSBp ZiBwZW9wbGUgd2lsbCBiZQ0KPj4+IGludGVyZXN0ZWQgaW4gY2hhbmdpbmcgdGhlIGV4aXN0aW5n IGNvbW1hbmRzIHRvIHVzZSB0aGlzIG1vcmUgZ2VuZXJpYw0KPj4+IGFwcHJvYWNoIG9mIGdyb3Vw ZWQgQVZQcy4gSXQgaXMgcHJvYmFibHkgbm90IGEgc3VmZmljaWVudCByZWFzb24gdG8NCj4+PiB1 cGRhdGUgdGhlIGNvbW1hbmRzIGRlZmluaXRpb25zIChzdWNoIGFzIERFQSBmb3IgZXhhbXBsZSks IGV2ZW4gdGhvdWdoDQo+Pj4gdGhlIGN1cnJlbnQgZm9ybWF0IGlzIHF1aXRlIHN0cmFuZ2UgOi1E DQo+Pj4gICAgIA0KPj4NCj4+IFtRaW5dIFdlIGRvbid0IGNoYW5nZSB0aGUgREVSL0RFQS4gTVNL IGFuZCByTVNLIGFyZSBib3RoIEVBUCBiYXNlZCB0cmFuc3BvcnRlZCBrZXkgbWF0ZXJpYWwNCj4+ IGRlcGVuZCBvbiB0aGUgc2FtZSBFQVAga2V5IGFyY2hpdGVjdHVyZS4gQWxzbyB0aGV5IGhhdmUg dGhlIHNhbWUgcGFyZW50cy46KQ0KPj4gICANCj4gSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwg dGhlIGludGVudCB3YXMgdG8gcmVwbGFjZSB0aGUgdXNlIG9mDQo+IEVBUC1NYXN0ZXItU2Vzc2lv bi1LZXkgQVZQIGJ5IGEgbmV3IGdlbmVyaWMgQVZQIHRvIHRyYW5zcG9ydCB0aGlzIE1TSyBvcg0K PiByTVNLLCByaWdodD8NCg0KW1Fpbl06IFdlIGRvbid0IGludGVuZCB0byByZXBsYWNlIG9yIGNo YW5nZSBpdC4gRm9yIGJhY2t3YXJkIGNvbXBhdGliaWxpdHksIHdlIGp1c3Qgd2FudCB0byBnaXZl IGFub3RoZXIgY2hvaWNlLCBpLmUuLFNpbmNlIE1TSyBhbmQgck1TSyBib3RoIGJlbG9uZyB0byBF QVAgYmFzZWQga2V5cyBhbmQgZGVwZW5kIG9uIHRoZSBzYW1lIEVNU0sgZm9yIGtleSBkZXJpdmF0 aW9uLCBJIHdvbmRlciB3aGV0aGVyIHdlIGNhbiB1c2UgdGhlIHNhbWUgY29udGFpbmVyIGZvciBi b3RoIG9mIHRoZW0/IElzIGl0IG5lY2Vzc2FyeSB0byBkZWZpbmUgZGlmZmVyZW50IEFWUCBjb2Rl IGZvciBib3RoIG9mIHRoZW0/DQoNCj4gQlRXIHNvcnJ5IGFib3V0IG15IGNvbW1lbnQgb24gdGhl IEFWUCBmb3JtYXQsIEkgY29uZm91bmRlZCB3aXRoIHRoZQ0KPiBmb3JtYXQgaW4gUkFESVVTLi4u IFRoZSBmb3JtYXQgaW4gRGlhbWV0ZXIgaXMgc3RyYWlnaHRmb3J3YXJkLg0KPiBCZXN0IHJlZ2Fy ZHMsDQo+IFNlYmFzdGllbi4NCj4gDQo+IC0tIA0KPiBTZWJhc3RpZW4gRGVjdWdpcw0KPiBSZXNl YXJjaCBmZWxsb3cNCj4gTmV0d29yayBBcmNoaXRlY3R1cmUgR3JvdXANCj4gTklDVCAobmljdC5n by5qcCkNCj4= From sdecugis@nict.go.jp Mon Aug 31 00:15:09 2009 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 B0F213A6BBD for ; Mon, 31 Aug 2009 00:15:09 -0700 (PDT) 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.714, BAYES_20=-0.74, HELO_EQ_JP=1.244, J_CHICKENPOX_44=0.6] 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 gnVFFrNYG6H4 for ; Mon, 31 Aug 2009 00:15:08 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id 126F33A6843 for ; Mon, 31 Aug 2009 00:15:07 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id n7V7FDkp008949; Mon, 31 Aug 2009 16:15:13 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id n7V7FDua004084; Mon, 31 Aug 2009 16:15:13 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id n7V7FD2N004081; Mon, 31 Aug 2009 16:15:13 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 1DD821684A; Mon, 31 Aug 2009 16:15:13 +0900 (JST) Received: from [133.243.146.206] (5gou2f-dhcp46.nict.go.jp [133.243.146.206]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 0867616846; Mon, 31 Aug 2009 16:15:13 +0900 (JST) Message-ID: <4A9B7878.4020001@nict.go.jp> Date: Mon, 31 Aug 2009 16:15:04 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Qin Wu References: <018101ca24ba$01834ea0$0489ebe0$@telcordia.com> <02f201ca255e$11533620$260ca40a@china.huawei.com> <4A94F0EF.3080102@nict.go.jp> <00e701ca2784$6b664030$260ca40a@china.huawei.com> <4A974A80.8020807@nict.go.jp> <00e901ca2a02$8ceaa6d0$260ca40a@china.huawei.com> In-Reply-To: <00e901ca2a02$8ceaa6d0$260ca40a@china.huawei.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: dime@ietf.org Subject: Re: [Dime] [DIME] Comments about AVP for crypto key transport draft 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, 31 Aug 2009 07:15:09 -0000 Hi Qin, Thank you for your answer. Please find my comments inside, as usual. Qin Wu a écrit : > [Qin]: I am glad you agree with us to define grouped AVP to contain context of key usage. > Yes, it seems to me a very good example where the "Grouped AVP" concept of Diameter is useful :) > It seems we have two choices for defining grouped AVP > a). the same AVP code for DSRK and rMSK > b). the different AVP code for DSRK and rMSK respectively > > [skip] > when the local server recieves AAA message including DSRK and rMSK from the home server, it does not simply forward the AAA message to the given authenticator, it needs to take out the grouped AVP for DSRK and check the format validicity of rMSK, and then include rMSK in the AAA message and send it to the given authenticator. > I think this is an implementation issue. Since the local server does not use/modify the rMSK, it might as well totally ignore this AVP. The full validation of the message is not required on each hop, because the transport layer is reliable, and we supposedly trust the (home) server to generate a valid message... Parsing the top-level AVPs is mandatory to find the AVPs we are interested in, but I think further validation should be avoided on intermediary nodes, to accelerate the processing and avoid congestion. > If the inside AVP of rMSK is not checked by the local server and directly transported to the authenticator, it is a little fragile too. It is not clear to me what should be the behavior in such case when an intermediary node detects a problem in an answer message, to avoid breaking application synchronization between the client and the end-server... > So I wonder how the local Server process the DSRK,rMSK and other keys, especially more than two EAP-based key materials need to be transported, e.g., DSRK, DSUSRK, rMSK are transported simutaneously to the local ER. Shall we need to define each grouped container for each key, what the local Server should do? > In my understanding the purpose of defining a "generic" approach is that what we define should be re-usable for transport of other keys in future usages. We don't know yet the semantics of these key, and the meta-data that will be needed along them. That is IMHO a good reason to have a different AVP code for different keys, while the AVPs inside the group can be reused whenever possible (key name, key lifetime, and so on...). But I am not saying that the other approach is not working, I just think it requires a little more work from the implementation. On the other side, it saves AVP codes, but I doubt that we will run out of available codes soon. There might be also other good reasons that I am not familiar with for defining only one AVP code (for example, is the process to get a new AVP code from IANA too difficult and would restrict the use of the generic AVP template in some case ?) but from a pure protocol and implementation point of view, I believe separate AVP codes is a better approach, that's all I am saying here. >> If I understand correctly, the intent was to replace the use of >> EAP-Master-Session-Key AVP by a new generic AVP to transport this MSK or >> rMSK, right? >> > > [Qin]: We don't intend to replace or change it. For backward compatibility, we just want to give another choice, i.e.,Since MSK and rMSK both belong to EAP based keys and depend on the same EMSK for key derivation, I wonder whether we can use the same container for both of them? Is it necessary to define different AVP code for both of them? > No, on the contrary, since MSK and rMSK are meant to be used in the same way, I would rather think we should avoid at all cost to pass the rMSK in a different container than the MSK... I was just pointing that it will be confusing if we define a new alternative container for the same thing in the same message... Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From behcetsarikaya@yahoo.com Mon Aug 31 08:12:18 2009 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 CAB803A6DE4 for ; Mon, 31 Aug 2009 08:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.964 X-Spam-Level: X-Spam-Status: No, score=-0.964 tagged_above=-999 required=5 tests=[AWL=-1.113, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334] 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 JXRF7568N3Jo for ; Mon, 31 Aug 2009 08:12:18 -0700 (PDT) Received: from web111403.mail.gq1.yahoo.com (web111403.mail.gq1.yahoo.com [67.195.15.144]) by core3.amsl.com (Postfix) with SMTP id 2B9C13A6CAB for ; Mon, 31 Aug 2009 08:12:18 -0700 (PDT) Received: (qmail 51284 invoked by uid 60001); 31 Aug 2009 15:12:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1251731547; bh=koqqvHmqwlY4wfCDrIVnEtli1JBEtAtyA+LLArpPeh0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=ghL9OTOROFe4R/SPZtk7Ty8Q4MiZORQQG9PK/0JHsPIFMczarj7kYDDYLMiGodbXmEOm+aF/MSQvjMPFFu/GsVVCotf+bNKfFuPfgjH128BE+Pvfzp1WIJA2GXPQx3ACOZa93A/d6Uh3bEGGM7u8ABePz2IGZFbNyxRB76QdySs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=ywiUtSNPQfcT2Ii0xLQ4gMhlq4R/EZQjCj3+QLh1ioNdircA7uObsUe25x17fHNZL2VcCo9wiVpNh0FPPez8qa7yjhzSdpobhjZcJl7ZovbIpYe54aJMoMifbTIYwb8PJ0ElDAQPdbooTf9o+dl4zMExaGmXEn2l3b4iPwip15Q=; Message-ID: <739801.51275.qm@web111403.mail.gq1.yahoo.com> X-YMail-OSG: IlI.FH8VM1nsieSAVtYu6ofvdhJtvBfJf_87A3FAKR5n2puFlKPlxCUNmE.ehfspYgctIhgrJLCFZXEMwRuwYR5HJtU4KzsZBmvuTqVXb4dcE2m3en6eXRxNcZTDmI8jzekDE5pkbpVtNIgmg_Fn4nlXW.tBxPKMpEyDtMha7iWrPzAe32HPyySF.RkvQAN5DS4qKe7fWVc8GLcHY9KKDTMW6rjHFdU5GE86xVKGQl0pxolm5sDHtNQ..CuKseN7TTcetnLOJh._4nDiwqkeLWPNagLDrLB8uuBEQjgOPps_YFeSsiWBQD4- Received: from [206.16.17.212] by web111403.mail.gq1.yahoo.com via HTTP; Mon, 31 Aug 2009 08:12:27 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.2 References: <4A97A6ED.2060101@nict.go.jp> Date: Mon, 31 Aug 2009 08:12:27 -0700 (PDT) From: Behcet Sarikaya To: Sebastien Decugis , dime@ietf.org In-Reply-To: <4A97A6ED.2060101@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Dime] draft-ietf-dime-erp-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 15:12:18 -0000 ----- Original Message ---- > From: Sebastien Decugis > To: dime@ietf.org > Sent: Friday, August 28, 2009 4:44:13 AM > Subject: [Dime] draft-ietf-dime-erp-01 > > Hello all, > > A new version of Diameter ERP document has just been submitted. It > should appear soon in the draft repository [1]. > > The main changes from the previous version are: Sebastien, I noticed that you included Session-Id into the open issues. I thought we had already discussed this on the list and clarified it. I don't think it should be an open issue. Regards, Behcet From gwz@net-zen.net Mon Aug 31 10:24:58 2009 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 9333728C417 for ; Mon, 31 Aug 2009 10:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 hk3e9xBI5JAs for ; Mon, 31 Aug 2009 10:24:57 -0700 (PDT) Received: from smtpauth14.prod.mesa1.secureserver.net (smtpauth14.prod.mesa1.secureserver.net [64.202.165.39]) by core3.amsl.com (Postfix) with SMTP id 4766728C411 for ; Mon, 31 Aug 2009 10:24:57 -0700 (PDT) Received: (qmail 6031 invoked from network); 31 Aug 2009 17:25:08 -0000 Received: from unknown (63.226.57.199) by smtpauth14.prod.mesa1.secureserver.net (64.202.165.39) with ESMTP; 31 Aug 2009 17:25:06 -0000 From: "Glen Zorn" To: "'Sebastien Decugis'" References: <018101ca24ba$01834ea0$0489ebe0$@telcordia.com> <02f201ca255e$11533620$260ca40a@china.huawei.com> <4A94F0EF.3080102@nict.go.jp> <002301ca2756$78339e80$689adb80$@net> <4A9743F4.60404@nict.go.jp> In-Reply-To: <4A9743F4.60404@nict.go.jp> Date: Mon, 31 Aug 2009 10:24:52 -0700 Organization: Network Zen Message-ID: <008001ca2a5f$f4026da0$dc0748e0$@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: AconiSK4ZlsR7WKxTIWcGwG1kOpXbAC1M04g Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] [DIME] Comments about AVP for crypto key transport draft 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, 31 Aug 2009 17:24:58 -0000 Sebastien Decugis [mailto:sdecugis@nict.go.jp] writes: > >> However, for the efficiency of parsing the message, I personally > think > >> that having the key "type" *inside* the grouped AVP is not > efficient, > >> since it means that the implementation has to parse the message "in > >> depth" to find the key it is interested in. > >> > > > > In theory this sounds good. If, however, an implementation receives > _any_ > > key that it can't use (or isn't interested in) this poses a major > security > > problem. > > > I don't understand how this is related to the format for conveying the > key. As I understand it, you're saying that by putting the key type at the top level of the AVP structure it will be easier for a node to decide if it is interested in the contents of the AVP. Is that correct? If so, I'm saying that if a node receives any key in which it is not interested, that in itself is a security problem. It should never happen & I can't see the point of optimizing for something that should not happen in the first place. > On the contrary, I'd think that with different AVP codes for different > types of keys, when the implementation understand the AVP code, we can > assume that it fully understand the content of the AVP. If you have a > generic "key" container, your implementation is able to extract the key > content, even if it does not understand the value inside the Key-Type > AVP. I would therefore think that my approach is slightly more secure > in > that sense. What do you think? > > >> If we define different > >> grouped AVPs for different key types, we have a better parsing > >> efficiency, and save some space in the message (key type AVP is not > >> needed). In addition, this approach allows to have a different ABNF > for > >> each key type (for example, making the Key Name mandatory for DSRK > >> keys, > >> but not for rMSK keys). > >> > > > > I'm not really sure why this would be useful... > > > I believe it is more generic, which is good since we are trying to > define a generic container :) For some key usages TBD, it might be > interesting to request for example the Key-Scope or Key-Algorithm (not > sure if this means anything) or Key-Strength in the ABNF, when they are > really needed by the application using this key. > > I personally think a good approach for the document is to define all > the > AVP that contain key data and metadata (key, key-name, key-lifetime, > key-scope, key-strengh, ... it can be updated when needed) and propose > a > "template" for other documents to use these new AVPs, an example > grouped > AVP. Then, each Diameter application that need to transport some key > material define its own grouped AVP with its particular ABNF and > semantics (depending on the application requirements) and re-uses these > generic AVPs inside the particular grouped AVP. OK. > > > >> About the transport of the MSK / rMSK, I am not sure if people will > be > >> interested in changing the existing commands to use this more > generic > >> approach of grouped AVPs. It is probably not a sufficient reason to > >> update the commands definitions (such as DEA for example), even > though > >> the current format is quite strange :-D > >> > > > > I'm not sure that I understand this: it doesn't appear to me that the > > definition of the DEA command would need to be changed: the > > EAP-Master-Session-Key & EAP-Key-Name AVPs are both optional & the > new AVP > > would certainly qualify as [ * AVP ] ;-). > > > You are right, it is my mistake. RFC4072 (Diameter EAP) only say that > DEA MAY include this AVP, so it is no problem to have a new container. > Anyway, on an implementation point of view, this would be very > confusing > (again, interoperability is getting worse)... :-( I don't know why... > > Best regards, > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > From sdecugis@nict.go.jp Mon Aug 31 18:58:25 2009 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 A10E028C105 for ; Mon, 31 Aug 2009 18:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.385 X-Spam-Level: X-Spam-Status: No, score=0.385 tagged_above=-999 required=5 tests=[AWL=-0.459, 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 1Cj9JmecJc8W for ; Mon, 31 Aug 2009 18:58:24 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:2f8:29::3]) by core3.amsl.com (Postfix) with ESMTP id 49A803A6C40 for ; Mon, 31 Aug 2009 18:58:24 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id n811wZBn006595; Tue, 1 Sep 2009 10:58:35 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id n811wZff009081; Tue, 1 Sep 2009 10:58:35 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id n811wYWO009078; Tue, 1 Sep 2009 10:58:35 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id E30D51618B; Tue, 1 Sep 2009 10:58:34 +0900 (JST) Received: from [133.243.146.206] (5gou2f-dhcp46.nict.go.jp [133.243.146.206]) by mail3.nict.go.jp (NICT Mail) with ESMTP id DC3C715FBD; Tue, 1 Sep 2009 10:58:34 +0900 (JST) Message-ID: <4A9C7FC4.4030903@nict.go.jp> Date: Tue, 01 Sep 2009 10:58:28 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Glen Zorn References: <018101ca24ba$01834ea0$0489ebe0$@telcordia.com> <02f201ca255e$11533620$260ca40a@china.huawei.com> <4A94F0EF.3080102@nict.go.jp> <002301ca2756$78339e80$689adb80$@net> <4A9743F4.60404@nict.go.jp> <008001ca2a5f$f4026da0$dc0748e0$@net> In-Reply-To: <008001ca2a5f$f4026da0$dc0748e0$@net> X-Enigmail-Version: 0.96.0 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: dime@ietf.org Subject: Re: [Dime] [DIME] Comments about AVP for crypto key transport draft 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, 01 Sep 2009 01:58:25 -0000 Hi Glen, Glen Zorn a écrit : > As I understand it, you're saying that by putting the key type at the top > level of the AVP structure it will be easier for a node to decide if it is > interested in the contents of the AVP. Is that correct? Yes, it is exactly what I am saying. > If so, I'm saying > that if a node receives any key in which it is not interested, that in > itself is a security problem. It should never happen & I can't see the > point of optimizing for something that should not happen in the first place. > Actually, any agent that relays a Diameter message (not only the proxies) receive this kind of information, right ? Do you mean that key material should be protected in an end-to-end maneer (from sender to recipient), instead of having only the hop-by-hop protection of Diameter? I think this is quite contradictory with Diameter trust model (which on the other side I believe is not scalable) For a concrete example, in ERP explicit bootstrapping, the home server generates two keys (rDSRK and rMSK) that are directed to two different nodes (ERP server and NAS). Do you imply that these keys should not be sent in the same Diameter message? >> You are right, it is my mistake. RFC4072 (Diameter EAP) only say that >> DEA MAY include this AVP, so it is no problem to have a new container. >> Anyway, on an implementation point of view, this would be very >> confusing >> (again, interoperability is getting worse)... :-( >> > > I don't know why... > If the NAS does not support the new container and receives a DEA with the MSK key in this container, it will fail to establish the session with the peer. (basically, the new container will have its 'M' flag set, and the NAS will not recognize it). Therefore, the server has to either: - have a configuration parameter for each NAS, telling if the new container can be used or not. - start using the new container only after all NAS (in the world?) have been upgraded to support the new container. Both solutions seems not very convenient to me. My comment of course assumes that some NAS already support RFC4072 as it is defined currently... I don't know if this is true or not. If nobody is "doing" RFC4072 currently, it is not a problem to change the recommanded way of passing the MSK to the NAS... Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sdecugis@nict.go.jp Mon Aug 31 19:14:04 2009 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 E2AC13A6B4A for ; Mon, 31 Aug 2009 19:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.669 X-Spam-Level: X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[AWL=0.686, BAYES_00=-2.599, 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 y8yutCLuN0Si for ; Mon, 31 Aug 2009 19:14:04 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:2f8:29::3]) by core3.amsl.com (Postfix) with ESMTP id 8E6263A6993 for ; Mon, 31 Aug 2009 19:12:46 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id n812CpcA008783; Tue, 1 Sep 2009 11:12:51 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id n812Cpkw013973; Tue, 1 Sep 2009 11:12:51 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id n812CpMv013970; Tue, 1 Sep 2009 11:12:51 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 9A126538D; Tue, 1 Sep 2009 11:12:51 +0900 (JST) Received: from [133.243.146.206] (5gou2f-dhcp46.nict.go.jp [133.243.146.206]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 93CE11EA1; Tue, 1 Sep 2009 11:12:51 +0900 (JST) Message-ID: <4A9C831D.5050309@nict.go.jp> Date: Tue, 01 Sep 2009 11:12:45 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Behcet Sarikaya References: <4A97A6ED.2060101@nict.go.jp> <739801.51275.qm@web111403.mail.gq1.yahoo.com> In-Reply-To: <739801.51275.qm@web111403.mail.gq1.yahoo.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-erp-01 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, 01 Sep 2009 02:14:05 -0000 Hello Behcet, > Sebastien, I noticed that you included Session-Id into the open issues. I thought we had already discussed this on the list and clarified it. > I don't think it should be an open issue. > Are you referring to this mail (and following)? http://www.ietf.org/mail-archive/web/dime/current/msg03678.html If I understood correctly, this thread discussed the session identifier used by EAP during an EAP authentication. AFAIK, this is not related to the Diameter Session-Id AVP. The Diameter Session-Id AVP is described in RFC3588. The open issue of the document concerns the content of the Diameter Session-Id AVP. Does this clarifies? If I am mistaken, please let me know. Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sunseawq@huawei.com Mon Aug 31 20:04:38 2009 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 3A0183A6C2F for ; Mon, 31 Aug 2009 20:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.513 X-Spam-Level: * X-Spam-Status: No, score=1.513 tagged_above=-999 required=5 tests=[AWL=-0.345, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_44=0.6, MIME_BASE64_TEXT=1.753, 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 wuAH5Exhrw9a for ; Mon, 31 Aug 2009 20:04:37 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id AD32A3A682A for ; Mon, 31 Aug 2009 20:04:36 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KP900CAMV7QSY@szxga04-in.huawei.com> for dime@ietf.org; Tue, 01 Sep 2009 11:04:38 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KP900ML1V7Q7N@szxga04-in.huawei.com> for dime@ietf.org; Tue, 01 Sep 2009 11:04:38 +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 <0KP900F3SV7PU2@szxml04-in.huawei.com> for dime@ietf.org; Tue, 01 Sep 2009 11:04:38 +0800 (CST) Date: Tue, 01 Sep 2009 11:04:37 +0800 From: Qin Wu To: Sebastien Decugis Message-id: <013501ca2ab0$f16354f0$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.3138 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <018101ca24ba$01834ea0$0489ebe0$@telcordia.com> <02f201ca255e$11533620$260ca40a@china.huawei.com> <4A94F0EF.3080102@nict.go.jp> <00e701ca2784$6b664030$260ca40a@china.huawei.com> <4A974A80.8020807@nict.go.jp> <00e901ca2a02$8ceaa6d0$260ca40a@china.huawei.com> <4A9B7878.4020001@nict.go.jp> Cc: dime@ietf.org Subject: Re: [Dime] [DIME] Comments about AVP for crypto key transport draft 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, 01 Sep 2009 03:04:38 -0000 SGksIFNlYmFzdGllbjoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiU2Vi YXN0aWVuIERlY3VnaXMiIDxzZGVjdWdpc0BuaWN0LmdvLmpwPg0KVG86ICJRaW4gV3UiIDxzdW5z ZWF3cUBodWF3ZWkuY29tPg0KQ2M6IDxkaW1lQGlldGYub3JnPg0KU2VudDogTW9uZGF5LCBBdWd1 c3QgMzEsIDIwMDkgMzoxNSBQTQ0KU3ViamVjdDogUmU6IFtEaW1lXSBbRElNRV0gQ29tbWVudHMg YWJvdXQgQVZQIGZvciBjcnlwdG8ga2V5IHRyYW5zcG9ydCBkcmFmdA0KPiBIaSBRaW4sDQo+IA0K PiBUaGFuayB5b3UgZm9yIHlvdXIgYW5zd2VyLiBQbGVhc2UgZmluZCBteSBjb21tZW50cyBpbnNp ZGUsIGFzIHVzdWFsLg0KPiANCj4gUWluIFd1IGEg6WNyaXQgOg0KPj4gW1Fpbl06IEkgYW0gZ2xh ZCB5b3UgYWdyZWUgd2l0aCB1cyB0byBkZWZpbmUgZ3JvdXBlZCBBVlAgdG8gY29udGFpbiBjb250 ZXh0IG9mIGtleSB1c2FnZS4NCj4+ICAgDQo+IFllcywgaXQgc2VlbXMgdG8gbWUgYSB2ZXJ5IGdv b2QgZXhhbXBsZSB3aGVyZSB0aGUgIkdyb3VwZWQgQVZQIiBjb25jZXB0DQo+IG9mIERpYW1ldGVy IGlzIHVzZWZ1bCA6KQ0KDQpbUWluXTogWW91IGFyZSByaWdodC46KQ0KDQo+PiBJdCBzZWVtcyB3 ZSBoYXZlIHR3byBjaG9pY2VzIGZvciBkZWZpbmluZyBncm91cGVkIEFWUA0KPj4gYSkuIHRoZSBz YW1lIEFWUCBjb2RlIGZvciBEU1JLIGFuZCByTVNLDQo+PiBiKS4gdGhlIGRpZmZlcmVudCBBVlAg Y29kZSBmb3IgRFNSSyBhbmQgck1TSyByZXNwZWN0aXZlbHkNCj4+IFtza2lwXQ0KPj4gd2hlbiB0 aGUgbG9jYWwgc2VydmVyIHJlY2lldmVzIEFBQSBtZXNzYWdlIGluY2x1ZGluZyBEU1JLIGFuZCBy TVNLDQo+PiBmcm9tIHRoZSBob21lIHNlcnZlciwgaXQgZG9lcyBub3Qgc2ltcGx5IGZvcndhcmQg dGhlIEFBQSBtZXNzYWdlIHRvIHRoZSBnaXZlbiANCj4+YXV0aGVudGljYXRvciwgaXQgbmVlZHMg dG8gdGFrZSBvdXQgdGhlIGdyb3VwZWQgQVZQIGZvciBEU1JLIGFuZCBjaGVjayB0aGUgDQo+PmZv cm1hdCB2YWxpZGljaXR5IG9mIHJNU0ssIGFuZCB0aGVuIGluY2x1ZGUgck1TSyBpbiB0aGUgQUFB IG1lc3NhZ2UgYW5kIHNlbmQNCj4+ICAgaXQgdG8gdGhlIGdpdmVuIGF1dGhlbnRpY2F0b3IuDQoN Cj4gSSB0aGluayB0aGlzIGlzIGFuIGltcGxlbWVudGF0aW9uIGlzc3VlLiBTaW5jZSB0aGUgbG9j YWwgc2VydmVyIGRvZXMgbm90DQo+IHVzZS9tb2RpZnkgdGhlIHJNU0ssIGl0IG1pZ2h0IGFzIHdl bGwgdG90YWxseSBpZ25vcmUgdGhpcyBBVlAuIFRoZSBmdWxsDQo+IHZhbGlkYXRpb24gb2YgdGhl IG1lc3NhZ2UgaXMgbm90IHJlcXVpcmVkIG9uIGVhY2ggaG9wLCBiZWNhdXNlIHRoZQ0KPiB0cmFu c3BvcnQgbGF5ZXIgaXMgcmVsaWFibGUsIGFuZCB3ZSBzdXBwb3NlZGx5IHRydXN0IHRoZSAoaG9t ZSkgc2VydmVyDQo+IHRvIGdlbmVyYXRlIGEgdmFsaWQgbWVzc2FnZS4uLiBQYXJzaW5nIHRoZSB0 b3AtbGV2ZWwgQVZQcyBpcyBtYW5kYXRvcnkNCj4gdG8gZmluZCB0aGUgQVZQcyB3ZSBhcmUgaW50 ZXJlc3RlZCBpbiwgYnV0IEkgdGhpbmsgZnVydGhlciB2YWxpZGF0aW9uDQo+IHNob3VsZCBiZSBh dm9pZGVkIG9uIGludGVybWVkaWFyeSBub2RlcywgdG8gYWNjZWxlcmF0ZSB0aGUgcHJvY2Vzc2lu Zw0KPiBhbmQgYXZvaWQgY29uZ2VzdGlvbi4NCg0KW1Fpbl06IFNpbmNlIHdlIGFzc3VtZSB0aGUg dHJhbnNwb3J0IGxheWVyIGlzIHJlbGlhYmxlLCBpdCBzZWVtcyB0byBtZSBwYXJzaW5nIA0KdGhl IHRvcC1sZXZlbCBBVlAgaXMgbW9yZSBlZmZpY2llbnQgdGhhbiBmdWxsIHBhcnNpbmcgdGhlIHdo b2xlIGdyb3VwZWQgQVZQIGF0IGVhY2ggbGV2ZWxzLiANCkhvd2V2ZXIgd2UgcHV0IHRoZSBrZXkg dHlwZSBhcyB0aGUgZmlyc3QgbmVzdGVkIEFWUCBhbmQgZGVmaW5lIGl0IGFzIGVOdW1lcmF0ZWQg dHlwZSwgIA0KIGl0IGRvZXMgbm90IHRha2UgdGltZSB0byBpbnRlcnByZXQgdGhpcyBmaXJzdCBp bm5lciBBVlAgb2Ygb25lIGdyb3VwZWQgQVZQLCBpLmUuLCBwYXJzaW5nIGlzDQogbm90IHNvIGRl ZXAgYXMgeW91IGNvbmNlcm5lZC4gV2hhdCBkbyB5b3UgdGhpbmsgb2YgaXQ/IDopDQoNCj4+IElm IHRoZSBpbnNpZGUgQVZQIG9mICByTVNLIGlzIG5vdCBjaGVja2VkIGJ5IHRoZSBsb2NhbCBzZXJ2 ZXIgDQo+PmFuZCBkaXJlY3RseSB0cmFuc3BvcnRlZCB0byB0aGUgYXV0aGVudGljYXRvciwgaXQg aXMgYSBsaXR0bGUgZnJhZ2lsZSB0b28uDQo+IEl0IGlzIG5vdCBjbGVhciB0byBtZSB3aGF0IHNo b3VsZCBiZSB0aGUgYmVoYXZpb3IgaW4gc3VjaCBjYXNlIHdoZW4gYW4NCj4gaW50ZXJtZWRpYXJ5 IG5vZGUgZGV0ZWN0cyBhIHByb2JsZW0gaW4gYW4gYW5zd2VyIG1lc3NhZ2UsIHRvIGF2b2lkDQo+ IGJyZWFraW5nIGFwcGxpY2F0aW9uIHN5bmNocm9uaXphdGlvbiBiZXR3ZWVuIHRoZSBjbGllbnQg YW5kIHRoZQ0KPiBlbmQtc2VydmVyLi4uDQoNCltRaW5dOiBJbiBteSB1bmRlcnN0YW5kaW5nLCBp ZiB0aGUgaW50ZXJtZWRpYXJ5IG5vZGUsIGUuZy4sbG9jYWwgc2VydmVyIGRldGVjdHMNCiB0aGUg aW5zaWRlIEFWUCBpcyBub3QgdmFsaWRhdGVkLCB0aGUgaW50ZXJtZWRpYXJ5IG5vZGUgY2FuIHNp bXBseSBub3RpZnkgdGhlDQphdXRoZW50aWNhdG9yIG9mIHRoZSByZXN1bHRzIGJ5IGVuY2Fwc3Vs YXRpbmcgdGhlIEVBUC1GYWlsdXJlIGluIHRoZSBBQUEgbWVzc2FnZQ0KYW5kIHNlbmRpbmcgdG8g dGhlIGF1dGhlbnRpY2F0b3IuIG9yIGFzayB0aGUgaG9tZSBzZXJ2ZXIgdG8gcmUtdHJhbnNwb3J0 IHRoZSByZWxldmFudA0Ka2V5IG1hdGVyaWFscy4NCg0KPj4gU28gSSB3b25kZXIgaG93IHRoZSBs b2NhbCBTZXJ2ZXIgcHJvY2VzcyB0aGUgRFNSSyxyTVNLIGFuZCBvdGhlciBrZXlzLCANCj4+ZXNw ZWNpYWxseSBtb3JlIHRoYW4gdHdvIEVBUC1iYXNlZCBrZXkgbWF0ZXJpYWxzIG5lZWQgdG8gYmUg dHJhbnNwb3J0ZWQsIGUuZy4sIA0KPj5EU1JLLCBEU1VTUkssIHJNU0sgYXJlIHRyYW5zcG9ydGVk IHNpbXV0YW5lb3VzbHkgdG8gdGhlIGxvY2FsIEVSLiBTaGFsbCB3ZSANCj4+IG5lZWQgdG8gZGVm aW5lIGVhY2ggZ3JvdXBlZCBjb250YWluZXIgZm9yIGVhY2gga2V5LCB3aGF0IHRoZSBsb2NhbCBT ZXJ2ZXIgc2hvdWxkIGRvPyANCj4+ICAgDQo+IEluIG15IHVuZGVyc3RhbmRpbmcgdGhlIHB1cnBv c2Ugb2YgZGVmaW5pbmcgYSAiZ2VuZXJpYyIgYXBwcm9hY2ggaXMgdGhhdA0KPiB3aGF0IHdlIGRl ZmluZSBzaG91bGQgYmUgcmUtdXNhYmxlIGZvciB0cmFuc3BvcnQgb2Ygb3RoZXIga2V5cyBpbiBm dXR1cmUNCj4gdXNhZ2VzLiBXZSBkb24ndCBrbm93IHlldCB0aGUgc2VtYW50aWNzIG9mIHRoZXNl IGtleSwgYW5kIHRoZSBtZXRhLWRhdGENCj4gdGhhdCB3aWxsIGJlIG5lZWRlZCBhbG9uZyB0aGVt LiBUaGF0IGlzIElNSE8gYSBnb29kIHJlYXNvbiB0byBoYXZlIGENCj4gZGlmZmVyZW50IEFWUCBj b2RlIGZvciBkaWZmZXJlbnQga2V5cywgd2hpbGUgdGhlIEFWUHMgaW5zaWRlIHRoZSBncm91cA0K PiBjYW4gYmUgcmV1c2VkIHdoZW5ldmVyIHBvc3NpYmxlIChrZXkgbmFtZSwga2V5IGxpZmV0aW1l LCBhbmQgc28gb24uLi4pLg0KDQpbUWluXSBBcyBkZXNjcmliZWQgaW4gdGhlIGRyYWZ0LWlldGYt aG9rZXkta2V5LW1nbS0wOSwgYWN0dWFsbHkgd2UgaGF2ZSBhbHJlYWR5IHNwZWNpZmllZCBzdWNo IGZ1dHVyZSB1c2FnZXMgZm9yIGtleSB0cmFuc3BvcnRhdGlvbiwgaS5lLiwNClNjZW5hcmlvIDE6 IEVBUC9BQUEgc2VydmVyIHRvIFVTUi1LSDogIEluIHRoaXMgc2NlbmFyaW8sIHRoZSBFQVAvQUFB IHNlcnZlciBkZWxpdmVycyBhIFVTUksgdG8gYSBVU1ItS0guDQpTY2VuYXJpbyAyOiBFQVAvQUFB IHNlcnZlciB0byBEU1ItS0g6ICBJbiB0aGlzIHNjZW5hcmlvLCB0aGUgRUFQL0FBQSBzZXJ2ZXIg ZGVsaXZlcnMgYSBEU1JLIHRvIGEgRFNSLUtILg0KU2NlbmFyaW8gMzogRFNSLUtIIHRvIERTVVNS LUtIOiAgSW4gdGhpcyBzY2VuYXJpbywgYSBEU1ItS0ggaW4gYSBzcGVjaWZpYyBkb21haW4gZGVs aXZlcnMga2V5aW5nIG1hdGVyaWFsIHRvIGEgDQpEU1VTUi1LSCBpbiB0aGUgc2FtZSBkb21haW4u DQpJbiB0aGVzZSBzY2VuYXJpb3MsIFVTUkssRFNSSywgRFNVU1JLIGFyZSBhbGwgRUFQIGJhc2Vk IGtleXMgYW5kIHNob3VsZCBiZSBkZWZpbmVkLg0KDQpBbHNvIGFzIGRlc2NyaWJlZCBpbiBSRkM1 Mjk2LCB0aGUgaW1wbGljaXQgYm9vdHN0cmFwcGluZyBmb3IgRVJQIHVzZXMgdGhlIEVBUCByZXF1 ZXN0L3Jlc3BvbnNlIGVuY2Fwc3VsYXRlZCBpbiB0aGUgDQpBQUEgbWVzc2FnZSB0byBjYXJyeSBE U1JLIGFuZCByTVNLIHNpbXVsdGFuZW91c2x5IHRvIHRoZSBsb2NhbCBTZXJ2ZXIuIHdoaWxlIGV4 cGxpY2l0IGJvb3RzdHJhcHBpbmcgDQpmb3IgRVJQIHVzZXMgdGhlIEVBUCBJbml0aWF0ZS9yZXNw b25zZSBlbmNhcHN1bGF0ZWQgaW4gdGhlIEFBQSBtZXNzYWdlIHRvIGNhcnJ5IERTUksgYW5kIHJN U0sgc2ltdWx0YW5lb3VzbHkuIA0KSW4gdHdvIGJvb3RzdHJhcHBpbmcgc2NlbmFyaW9zLCBEU1JL IGFuZCByTVNLIGFyZSBib3RoIEVBUCBiYXNlZCBrZXkgYW5kIHNob3VsZCBiZSBkZWZpbmVkLg0K U2luY2UgYWxsIHRoZXNlIGtleXMgYXJlIGRpcmVjdGx5IG9yIGluZGlyZWN0bHkgZGVyaXZlZCBm cm9tIHRoZSBzYW1lIEVNU0suIEkgd29uZGVyIGlzIGl0IG5lY2Vzc2FyeSBmb3IgdXMgdG8gZGVm aW5lIGVhY2ggZ3JvdXBlZCANCkFWUCBmb3IgVVNSSywgRFNSSywgRFNVU1JLLCByTVNLLg0KDQo+ IEJ1dCBJIGFtIG5vdCBzYXlpbmcgdGhhdCB0aGUgb3RoZXIgYXBwcm9hY2ggaXMgbm90IHdvcmtp bmcsIEkganVzdCB0aGluaw0KPiBpdCByZXF1aXJlcyBhIGxpdHRsZSBtb3JlIHdvcmsgZnJvbSB0 aGUgaW1wbGVtZW50YXRpb24uIE9uIHRoZSBvdGhlcg0KPiBzaWRlLCBpdCBzYXZlcyBBVlAgY29k ZXMsIGJ1dCBJIGRvdWJ0IHRoYXQgd2Ugd2lsbCBydW4gb3V0IG9mIGF2YWlsYWJsZQ0KPiBjb2Rl cyBzb29uLiBUaGVyZSBtaWdodCBiZSBhbHNvIG90aGVyIGdvb2QgcmVhc29ucyB0aGF0IEkgYW0g bm90DQo+IGZhbWlsaWFyIHdpdGggZm9yIGRlZmluaW5nIG9ubHkgb25lIEFWUCBjb2RlIChmb3Ig ZXhhbXBsZSwgaXMgdGhlDQo+IHByb2Nlc3MgdG8gZ2V0IGEgbmV3IEFWUCBjb2RlIGZyb20gSUFO QSB0b28gZGlmZmljdWx0IGFuZCB3b3VsZCByZXN0cmljdA0KPiB0aGUgdXNlIG9mIHRoZSBnZW5l cmljIEFWUCB0ZW1wbGF0ZSBpbiBzb21lIGNhc2UgPykgYnV0IGZyb20gYSBwdXJlDQo+IHByb3Rv Y29sIGFuZCBpbXBsZW1lbnRhdGlvbiBwb2ludCBvZiB2aWV3LCBJIGJlbGlldmUgc2VwYXJhdGUg QVZQIGNvZGVzDQo+IGlzIGEgYmV0dGVyIGFwcHJvYWNoLCB0aGF0J3MgYWxsIEkgYW0gc2F5aW5n IGhlcmUuDQoNCltRaW5dOiBUaGUgcmVhc29ucyB0byBkZWZpbmUgb25seSBvbmUgQVZQIGNvZGUg Zm9yIHRoZXNlIGtleXMgYXJlOg0KMS4gU2F2ZSBBVlAgY29kZQ0KMi4gQWxsIHRoZXNlIHRyYW5z cG9ydGVkIGtleSBtYXRlcmlhbHMgZGVyaXZlIGZyb20gdGhlIHNhbWUgRU1TSyBhbmQgYXJlIHZh cmlhbnRzIG9mIEVBUCBiYXNlZCBrZXkuDQpJcyBpdCBuZWNlc3NhcnkgZm9yIHVzIHRvIGRlZmlu ZSBzZXBhcmF0ZSBBVlAgY29kZXMgZm9yIHRoZW0/DQozLiBBcyBkZXNjcmliZWQgaW4gZHJhZnQt aWV0Zi1ob2tleS1rZXktbWdtLTA5LCBkaXN0cmlidXRpb24gb2YgRUFQIGJhc2VkIGtleXMgZm9y IGhhbmRvdmVyIGFyZSBub3QNCm9ubHkgc3BlY2lmaWMgdG8gdGhlIEVSUCBzY2VuYXJpb3Mgb3Ig UmUtYXV0aGVudGljYXRpb24uIFRoZXJlIGFyZSBvdGhlciBzY2VuYXJpb3Mgd2hpY2ggdGhpcyBn ZW5lcmljIEFWUCANCmNhbiBiZSBhcHBsaWVkIGFzIHdlbGwuDQoNCj4+PiBJZiBJIHVuZGVyc3Rh bmQgY29ycmVjdGx5LCB0aGUgaW50ZW50IHdhcyB0byByZXBsYWNlIHRoZSB1c2Ugb2YNCj4+PiBF QVAtTWFzdGVyLVNlc3Npb24tS2V5IEFWUCBieSBhIG5ldyBnZW5lcmljIEFWUCB0byB0cmFuc3Bv cnQgdGhpcyBNU0sgb3INCj4+PiByTVNLLCByaWdodD8NCj4+PiAgICAgDQo+Pg0KPj4gW1Fpbl06 IFdlIGRvbid0IGludGVuZCB0byByZXBsYWNlIG9yIGNoYW5nZSBpdC4gRm9yIGJhY2t3YXJkIGNv bXBhdGliaWxpdHksIHdlIGp1c3QgDQo+PndhbnQgdG8gZ2l2ZSBhbm90aGVyIGNob2ljZSwgaS5l LixTaW5jZSBNU0sgYW5kIHJNU0sgYm90aCBiZWxvbmcgdG8gRUFQIGJhc2VkIGtleXMNCj4+IGFu ZCBkZXBlbmQgb24gdGhlIHNhbWUgRU1TSyBmb3Iga2V5IGRlcml2YXRpb24sIEkgd29uZGVyIHdo ZXRoZXIgd2UgY2FuIHVzZSB0aGUgDQo+PnNhbWUgY29udGFpbmVyIGZvciBib3RoIG9mIHRoZW0/ IElzIGl0IG5lY2Vzc2FyeSB0byBkZWZpbmUgZGlmZmVyZW50IEFWUCBjb2RlIGZvciBib3RoIA0K Pj5vZiB0aGVtPw0KPj4gICANCj4gTm8sIG9uIHRoZSBjb250cmFyeSwgc2luY2UgTVNLIGFuZCBy TVNLIGFyZSBtZWFudCB0byBiZSB1c2VkIGluIHRoZSBzYW1lDQo+IHdheSwgSSB3b3VsZCByYXRo ZXIgdGhpbmsgd2Ugc2hvdWxkIGF2b2lkIGF0IGFsbCBjb3N0IHRvIHBhc3MgdGhlIHJNU0sNCj4g aW4gYSBkaWZmZXJlbnQgY29udGFpbmVyIHRoYW4gdGhlIE1TSy4uLg0KPiBJIHdhcyBqdXN0IHBv aW50aW5nIHRoYXQgaXQgd2lsbCBiZSBjb25mdXNpbmcgaWYgd2UgZGVmaW5lIGEgbmV3DQo+IGFs dGVybmF0aXZlIGNvbnRhaW5lciBmb3IgdGhlIHNhbWUgdGhpbmcgaW4gdGhlIHNhbWUgbWVzc2Fn ZS4uLg0KDQpbUWluXSBBcmUgeW91IGludGVuZGluZyB0byB1c2UgRUFQLU1hc3Rlci1TZXNzaW9u LUtleSBBVlAgdG8gdHJhbnNwb3J0IHJNU0sgDQpmcm9tIHRoZSBob21lIFNlcnZlciB0byB0aGUg TG9jYWwgU2VydmVyLCBJbiB0aGlzIHNlbnNlLCBJIGFtIGFmcmFpZCB5b3UgY2hhbmdlIHRoZQ0K IG1lYW5pbmcgb2YgRUFQLU1hc3Rlci1TZXNzaW9uLUtleS4gQmVjYXVzZSB0aGUgbG9jYWwgc2Vy dmVyIHdpbGwgY29uZnVzZSB3aGV0aGVyIA0KIHRoZSBob21lIFNlcnZlciBpcyB0cmFuc3BvcnRp bmcgTVNLIG9yIHJNU0sgdG8gaGltLiBiZWNhdXNlIHJNU0sgaXMgZGVyaXZlZCBmcm9tIA0KclJL IHdoaWxlIE1TSyBpcyBFeHBvcnRlZCBieSBFQVAgbWV0aG9kLiBBbHNvIHdoZW4geW91IHVzZSB0 aGUgRUFQLU1hc3Rlci1TZXNzaW9uLUtleSANCnRvIHRyYW5zcG9ydCByTVNLIHRvIHRoZSBhdXRo ZW5jYXRvciwgaXQgd2lsbCBjYXVzZSBjb25mdXNpb24gb2YgYXV0aGVudGljYXRvciBhcyB3ZWxs LiA6KQ0KSW4gdGhpcyB3YXksIGl0IGlzIGJldHRlciB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIHJN U0sgYW5kIE1TSy4NCg0KPiBCZXN0IHJlZ2FyZHMsDQo+IFNlYmFzdGllbi4NCj4gDQo+IC0tIA0K PiBTZWJhc3RpZW4gRGVjdWdpcw0KPiBSZXNlYXJjaCBmZWxsb3cNCj4gTmV0d29yayBBcmNoaXRl Y3R1cmUgR3JvdXANCj4gTklDVCAobmljdC5nby5qcCkNCj4= From sdecugis@nict.go.jp Mon Aug 31 21:27:13 2009 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 DB9C628C5F6 for ; Mon, 31 Aug 2009 21:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.431 X-Spam-Level: X-Spam-Status: No, score=-0.431 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599, HELO_EQ_JP=1.244, J_CHICKENPOX_44=0.6] 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 mLQQvbe9b9B7 for ; Mon, 31 Aug 2009 21:27:12 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:2f8:29::3]) by core3.amsl.com (Postfix) with ESMTP id 352C128C260 for ; Mon, 31 Aug 2009 21:27:11 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id n814RIj2001186; Tue, 1 Sep 2009 13:27:18 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id n814RIfH029926; Tue, 1 Sep 2009 13:27:18 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id n814RIVX029923; Tue, 1 Sep 2009 13:27:18 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by mail1.nict.go.jp (NICT Mail) with ESMTP id AC3CE16500; Tue, 1 Sep 2009 13:27:18 +0900 (JST) Received: from [133.243.146.206] (5gou2f-dhcp46.nict.go.jp [133.243.146.206]) by mail1.nict.go.jp (NICT Mail) with ESMTP id A63D0163DE; Tue, 1 Sep 2009 13:27:18 +0900 (JST) Message-ID: <4A9CA29E.4010801@nict.go.jp> Date: Tue, 01 Sep 2009 13:27:10 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Qin Wu References: <018101ca24ba$01834ea0$0489ebe0$@telcordia.com> <02f201ca255e$11533620$260ca40a@china.huawei.com> <4A94F0EF.3080102@nict.go.jp> <00e701ca2784$6b664030$260ca40a@china.huawei.com> <4A974A80.8020807@nict.go.jp> <00e901ca2a02$8ceaa6d0$260ca40a@china.huawei.com> <4A9B7878.4020001@nict.go.jp> <013501ca2ab0$f16354f0$260ca40a@china.huawei.com> In-Reply-To: <013501ca2ab0$f16354f0$260ca40a@china.huawei.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] [DIME] Comments about AVP for crypto key transport draft 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, 01 Sep 2009 04:27:13 -0000 Hi Qin, > However we put the key type as the first nested AVP and define it as eNumerated type, > it does not take time to interpret this first inner AVP of one grouped AVP, i.e., parsing is > not so deep as you concerned. What do you think of it? :) > Yes, it's right, if the key type is a fixed position AVP, it is not much more work than having the information in the avp header. It just takes a little more space in the message, but if there are good reasons to define only one grouped AVP, I guess the additional space is not really an issue. >> It is not clear to me what should be the behavior in such case when an >> intermediary node detects a problem in an answer message, to avoid >> breaking application synchronization between the client and the >> end-server... >> > > [Qin]: In my understanding, if the intermediary node, e.g.,local server detects > the inside AVP is not validated, the intermediary node can simply notify the > authenticator of the results by encapsulating the EAP-Failure in the AAA message > and sending to the authenticator. or ask the home server to re-transport the relevant > key materials. > I see. In any case, the NAS probably have to validate the key, so I still believe the validation in the intermediary node is not necessary. >> In my understanding the purpose of defining a "generic" approach is that >> what we define should be re-usable for transport of other keys in future >> usages. We don't know yet the semantics of these key, and the meta-data >> that will be needed along them. That is IMHO a good reason to have a >> different AVP code for different keys, while the AVPs inside the group >> can be reused whenever possible (key name, key lifetime, and so on...). >> > > [Qin] As described in the draft-ietf-hokey-key-mgm-09, actually we have already specified such future usages for key transportation, i.e., > In these scenarios, USRK,DSRK, DSUSRK are all EAP based keys and should be defined. > But the usages you are talking of here are not defined yet, right? And we are only talking about keys derived from EAP EMSK, following rfc5295 method. We may also have to transport keys in different contexts. In some future usages of the key material, additional metadata might be needed (a version of the key derivation algorithm for example). Of course new AVPs can be defined inside the [ * AVP ] rule of the grouped AVP ABNF, but I think that having a clear definition of the ABNF for each key usage is easier to understand and more explicit -- and we don't implicitely imply the ABNF for the group from the value of the Key-Type AVP in that case. > In two bootstrapping scenarios, DSRK and rMSK are both EAP based key and should be defined. > Since all these keys are directly or indirectly derived from the same EMSK. I wonder is it necessary for us to define each grouped > AVP for USRK, DSRK, DSUSRK, rMSK. > Because these keys are used differently, it seems to me logical to have different AVP defined. But if other people prefer to define only one container and put all the keys in the same one with an AVP inside to distinguish between different types of keys, it is OK with me, I already argued why I think the other possibility is better... > [Qin]: The reasons to define only one AVP code for these keys are: > 1. Save AVP code > The code space is 2^32, just for IETF... We will not run out of codes ^^. > 2. All these transported key materials derive from the same EMSK and are variants of EAP based key. > Is it necessary for us to define separate AVP codes for them? > As I wrote before, the way these keys are used, as well as the node to which they are destined, differ. That is a good reason IMHO. In addition, if you want to defined a generic AVP, you don't want to restrict to keys following the semantics you are describing here, do you? > 3. As described in draft-ietf-hokey-key-mgm-09, distribution of EAP based keys for handover are not > only specific to the ERP scenarios or Re-authentication. There are other scenarios which this generic AVP > can be applied as well. > Yes, from the beginning I agree that defining a generic way to transport keys is a good idea... It's only the way that it is done that I am discussing :) > [Qin] Are you intending to use EAP-Master-Session-Key AVP to transport rMSK > from the home Server to the Local Server, Yes. > In this sense, I am afraid you change the > meaning of EAP-Master-Session-Key. Well, basically, rMSK is an MSK also, I do not see a contradiction here. > Because the local server will confuse whether > the home Server is transporting MSK or rMSK to him. First of all, it is not important for the local server, since it does not use this key at all. Second, during a full EAP authentication, it is an MSK. During an explicit bootstrapping ERP exchange, it is an rMSK. There is no confusion here. > because rMSK is derived from > rRK while MSK is Exported by EAP method. Also when you use the EAP-Master-Session-Key > to transport rMSK to the authencator, it will cause confusion of authenticator as well. :) > The authenticator uses the rMSK exactly in the same maneer as the MSK, there is no point in distinguishing between them. > In this way, it is better to distinguish between rMSK and MSK. > I don't think so... Why do you need to distinguish? Only the peer need to know what key the authenticator will be using. And the peer always know... Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp)