From dime-bounces@ietf.org Tue Jan 6 06:00:12 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DB1A3A685C; Tue, 6 Jan 2009 06:00:12 -0800 (PST) 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 CBA373A685C for ; Tue, 6 Jan 2009 06:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.005 X-Spam-Level: X-Spam-Status: No, score=-1.005 tagged_above=-999 required=5 tests=[AWL=-0.820, BAYES_40=-0.185] 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 AJBMcAiPuQMX for ; Tue, 6 Jan 2009 06:00:10 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id B02923A6358 for ; Tue, 6 Jan 2009 06:00:09 -0800 (PST) Received: (qmail invoked by alias); 06 Jan 2009 13:59:53 -0000 Received: from a91-154-105-43.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.105.43] by mail.gmx.net (mp061) with SMTP; 06 Jan 2009 14:59:53 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+SCDQpTBySyNMbctE4e/CEU8OTJyudlCrvPJhdsJ TGSxYPA1lfKzfF From: "Hannes Tschofenig" To: Date: Tue, 6 Jan 2009 16:01:39 +0200 Message-ID: <027501c97007$4c2d02b0$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclwB0uUWJ5Bv5ACTn+83q1hRbTRzw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.73 Subject: [Dime] HUM regarding draft-tsou-dime-routing-problem-statement-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi all, we would like to hear your feedback regarding the document that is being developed as part of the design team work on Diameter routing, see http://tools.ietf.org/id/draft-tsou-dime-routing-problem-statement-00.txt Please let me us know whether you have objections or whether you are in support of this document becoming a WG item. Deadline: 19th Jan. 2009 Ciao Hannes & Dave _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jan 6 06:34:19 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99AB23A6917; Tue, 6 Jan 2009 06:34:19 -0800 (PST) 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 2FC523A6869 for ; Tue, 6 Jan 2009 06:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[AWL=0.397, 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 SYECLKLGGHhu for ; Tue, 6 Jan 2009 06:34:18 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id DA05728C106 for ; Tue, 6 Jan 2009 06:34:17 -0800 (PST) Received: (qmail invoked by alias); 06 Jan 2009 14:34:04 -0000 Received: from a91-154-105-43.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.105.43] by mail.gmx.net (mp052) with SMTP; 06 Jan 2009 15:34:04 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/w96Yla/rwN8OvkaD1a6GVbDJMvlCX6BJmqQ+zbg M15mVIKsIsZ2iL From: "Hannes Tschofenig" To: Date: Tue, 6 Jan 2009 16:34:41 +0200 Message-ID: <027701c9700b$e9641010$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclwC+jJkBrRAaD+T0qZq2Io717T1A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.59 Subject: [Dime] DIME Status Update (Jan. 2009) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org * Diameter API Waiting for Dave to update the draft. * Diameter Milestone Update Dan and Hannes discussed how to update the milestones of the group, see http://www.ietf.org/mail-archive/web/dime/current/msg03152.html Dan will check with Ron whether the proposal is OK. Feedback from the group expected regarding the milestones and the proposed list of documents. Tina suggested that the Diameter Design Team work should be included as well. Hannes sent a mail, see http://www.ietf.org/mail-archive/web/dime/current/msg03161.html * QoS Diameter Draft Updates Documents got updated, see http://www.ietf.org/mail-archive/web/dime/current/msg03143.html Previous feedback solicited: http://www.ietf.org/mail-archive/web/dime/current/msg03107.html Action item: Hannes to determine how the remaining open issues can be fixed. * Diameter ITU-T Rw Policy Enforcement Interface Application' to Informational RFC Document was approved, see http://www.ietf.org/mail-archive/web/dime/current/msg03111.html * draft-ietf-dime-mip6-split-15.txt Victor submitted PROTO writeup, see http://www.ietf.org/mail-archive/web/dime/current/msg03157.html * draft-jones-dime-3gpp-eps-command-codes-01.txt Hannes submitted PROTO writeup, see http://www.ietf.org/mail-archive/web/dime/current/msg03160.html * Diameter-RADIUS Translation Gateway Hannes sent out a mail to determine the current state of the art, see http://www.ietf.org/mail-archive/web/dime/current/msg03139.html Private feedback received. Action item: Hannes to figure out how to capture the feedback and to make it available for discussions. * RFC3588bis Victor submitted a new version, see http://www.ietf.org/mail-archive/web/dime/current/msg03133.html There are still open issues that need to get discussed. Action item: Hannes to talk to Victor on how to address the open issues. * draft-ietf-dime-mip6-integrated Jouni updated the draft and I hope that it meets Pasi's expectations: http://www.ietf.org/mail-archive/web/aaa-doctors/current/msg00223.html * Diameter Design Guidelines Action item: Hannes to update the document during this week to reflect recent experience in the work on Diameter. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jan 6 10:33:59 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A5533A6830; Tue, 6 Jan 2009 10:33:59 -0800 (PST) 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 DAEC63A63D2 for ; Tue, 6 Jan 2009 10:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=0.388, 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 veL9Y9Zz91ez for ; Tue, 6 Jan 2009 10:33:57 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 13AC93A6892 for ; Tue, 6 Jan 2009 10:33:55 -0800 (PST) Received: (qmail invoked by alias); 06 Jan 2009 18:33:39 -0000 Received: from a91-154-105-43.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.105.43] by mail.gmx.net (mp066) with SMTP; 06 Jan 2009 19:33:39 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19gKHkL/lFgTEu3zORYg9Q4xBGT7mZ8EjXRlSJekM OSRTdWdLWv5G2Z From: "Hannes Tschofenig" To: "'Hannes Tschofenig'" , References: <027501c97007$4c2d02b0$0201a8c0@nsnintra.net> Date: Tue, 6 Jan 2009 20:34:40 +0200 Message-ID: <000d01c9702d$706e8420$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclwB0uUWJ5Bv5ACTn+83q1hRbTRzwAIy1eA In-Reply-To: <027501c97007$4c2d02b0$0201a8c0@nsnintra.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.55 Subject: Re: [Dime] HUM regardingdraft-tsou-dime-routing-problem-statement-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --- as an individual Hi all, There are three problem statements in the document A) Initial Network Selection B) Path Maintenance C) Routing By a Combination of Realm and Application Item (A) has been subject to the work in http://tools.ietf.org/id/draft-korhonen-dime-nai-routing-02.txt. As such, there is no good reason to describe it here again. >From the last meeting I could tell that most folks have not understood item (C). It is a somewhat different problem, I believe (if I have understood it). Item (B) is the one that is core to the discussion and should, IMHO, be the only one described in the document. There are two separate issues: 1) At what granularity do we do routing? -- routing at the level of a realm -- routing at the level of a host 2) Who needs this? Regarding 1) Folks have expressed rather strong concerns that routing at the level of a host could be problematic as it breaks a few Diameter mechanisms. Routing at the level of a realm might be OK, as it seems, but the problem is that currently Diameter deployments are not large enough that this is really a problem. Additionally, the latter solution may not correctely reflect the problem statement -- might need more meat. Regarding 2) It is not clear who actually wants this work. 3GPP and other organizations are mentioned but they have not come to use officially. Why would they actually come to use in the first place given that they have a couple of things alone already. So, what can we do? There are again two parts to that answer: -- The problem statement document A) If the document is good enough and we find enough folks that support it then we can go through the group with it and publish it as an informational RFC. Review comments would be appreciated to make the document better. B) It can be published directly to the RFC Editor as an independent submission. -- The solution A) It depends on the solution we come up with -- it may or may not find excitement in the group and could go through the group (for example as an informational document, as an experimental document or so). B) It was suggested to publish the document as an independent submission again using vendor specific AVPs. C) A further solution is to let another organization do the work, if they like it. I don't know what the best way is and I would certainly appreciate feedback. We also plan to discuss this topic at the next design team conference call. (Next week) For myself I cannot spend too much time on this topic since we still have to finish RFC3588bis. RFC3588bis is far more important for me. My 2 cents. Ciao Hannes >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >Behalf Of Hannes Tschofenig >Sent: 06 January, 2009 16:02 >To: dime@ietf.org >Subject: [Dime] HUM >regardingdraft-tsou-dime-routing-problem-statement-00.txt > >Hi all, > >we would like to hear your feedback regarding the document >that is being developed as part of the design team work on >Diameter routing, see >http://tools.ietf.org/id/draft-tsou-dime-routing-problem-statem >ent-00.txt > >Please let me us know whether you have objections or whether >you are in support of this document becoming a WG item. > >Deadline: 19th Jan. 2009 > >Ciao >Hannes & Dave > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jan 6 10:45:00 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 129E83A6892; Tue, 6 Jan 2009 10:45:00 -0800 (PST) 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 98ACB3A6892 for ; Tue, 6 Jan 2009 10:44:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.373, 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 0lHWXAFQc+Y5 for ; Tue, 6 Jan 2009 10:44:57 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 18BA73A679F for ; Tue, 6 Jan 2009 10:44:56 -0800 (PST) Received: (qmail invoked by alias); 06 Jan 2009 18:44:43 -0000 Received: from a91-154-105-43.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.105.43] by mail.gmx.net (mp019) with SMTP; 06 Jan 2009 19:44:43 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+BKjAxdseBkgcTDkVfEPePXR4Ujsrpo4s3mt4JEv 98ClqJS1VakCtQ From: "Hannes Tschofenig" To: "'ext Tina TSOU'" , , "'Hannes Tschofenig'" References: <011c01c964e8$922f3f50$0201a8c0@nsnintra.net> <00d201c965a9$a9fd2db0$7427460a@china.huawei.com> Date: Tue, 6 Jan 2009 20:46:12 +0200 Message-ID: <000f01c9702f$0c944ff0$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcllqjeeAsWwt8B7R/2JagF1algPcQKflKBg In-Reply-To: <00d201c965a9$a9fd2db0$7427460a@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.75 Subject: Re: [Dime] FW: DIME Milestones Update X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Tina, during the IETF#73 meeting, if I recall it correctly, the group had mixed feelings about the document. Nevertheless, we ask the group. See my other mail. I will comment on it separately. Ciao Hannes ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of ext Tina TSOU Sent: 24 December, 2008 11:26 To: dime@ietf.org; Hannes Tschofenig Subject: Re: [Dime] FW: DIME Milestones Update Hi all, Should the work in http://groups.google.com/group/diameter-routing be considered at the same level as the following? - "Diameter User-Name and Realm Based Request Routing Clarifications" (based on http://tools.ietf.org/id/draft-korhonen-dime-nai-routing-02.txt) Wish you a joyful and peaceful holiday season and a prosperous and healthy New Year:D B. R. Tina ----- Original Message ----- From: Hannes Tschofenig To: dime@ietf.org Sent: Tuesday, December 23, 2008 6:23 PM Subject: [Dime] FW: DIME Milestones Update Hi all, I had a chat with Dan about the adjustments of the milestones and I crafted the following list: -------------------------------- DONE.......Submit "Diameter API" to the IESG for consideration as an Informational RFC DONE.......Submit "Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction" to the IESG for consideration as a Proposed Standard. DONE.......Submit "Quality of Service Parameters for Usage with Diameter" to the IESG for consideration as a Proposed Standard. Dec 2008...Submit "Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction" to the IESG for consideration as a Proposed Standard. Jan 2009...Submit Revision of "Diameter Base Protocol" to the IESG for consideration as a Proposed Standard Jan 2009...Submit "Quality of Service Attributes for Diameter" to the IESG for consideration as a Proposed Standard Jan 2009...Submit "Diameter QoS Application" to the IESG for consideration as a Proposed Standard Jan 2009...Submit "Diameter Support for EAP Re-authentication Protocol" as DIME working group item Jan 2009...Submit "Diameter User-Name and Realm Based Request Routing Clarifications" as DIME working group item Jan 2009...Submit "Diameter Proxy Mobile IPv6" as DIME working group item Mar 2009...Submit "Diameter Application Design Guidelines" to the IESG for consideration as a BCP document Apr 2009...Submit "Diameter User-Name and Realm Based Request Routing Clarifications" to the IESG for consideration as a Proposed Standard Apr 2009...Submit "Diameter Proxy Mobile IPv6" to the IESG for consideration as a Proposed Standard May 2009...Submit "Diameter Support for EAP Re-authentication Protocol" to the IESG for consideration as a Proposed Standard -------------------------------- A few notes regarding the items: * in the current milestones list at http://www.ietf.org/html.charters/dime-charter.html we do not have 'QoS Attributes for Diameter' and 'QoS parameters for Usage w/ Diameter'. Some time back we decided to split the Diameter QoS work into three documents and I believe we should capture this aspect in the updated milestone list. * There are 3 new items in the list, namely - "Diameter Support for EAP Re-authentication Protocol" (based on http://tools.ietf.org/id/draft-dondeti-dime-erp-diameter-02.txt) - "Diameter User-Name and Realm Based Request Routing Clarifications" (based on http://tools.ietf.org/id/draft-korhonen-dime-nai-routing-02.txt) - "Diameter Proxy Mobile IPv6" (based on http://tools.ietf.org/id/draft-korhonen-dime-pmip6-04.txt) * When writing the above list I was wondering whether we actually need to go for Proposed Standard for these three documents. With RFC3588bis we could also use Informational RFCs and then upgrade them once we got implementation and deployment experience. I believe that this would allow us to publish documents faster. I wonder what the group thinks about that idea? * I made a proposal regarding the milestones and I was wondering whether the group considers my suggestion as realistic. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jan 6 14:56:29 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E79FA3A67EE; Tue, 6 Jan 2009 14:56:29 -0800 (PST) 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 06D043A67EE for ; Tue, 6 Jan 2009 14:56:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7Nx7ZRrKUrd for ; Tue, 6 Jan 2009 14:56:28 -0800 (PST) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id 2B8F53A67AD for ; Tue, 6 Jan 2009 14:56:28 -0800 (PST) Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id 0NCd1b00l0x6nqcA9NwFAP; Tue, 06 Jan 2009 22:56:15 +0000 Received: from gwzPC ([67.160.38.190]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id 0NwC1b00N469TLb8YNwD5u; Tue, 06 Jan 2009 22:56:15 +0000 From: "Glen Zorn" To: "'Hannes Tschofenig'" References: <027501c97007$4c2d02b0$0201a8c0@nsnintra.net> In-Reply-To: <027501c97007$4c2d02b0$0201a8c0@nsnintra.net> Date: Tue, 6 Jan 2009 14:55:48 -0800 Message-ID: <00ed01c97051$ec21f4c0$c465de40$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclwB0uUWJ5Bv5ACTn+83q1hRbTRzwASj8Eg Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] HUM regarding draft-tsou-dime-routing-problem-statement-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] writes: > Hi all, > > we would like to hear your feedback regarding the document that is > being > developed as part of the design team work on Diameter routing, see > http://tools.ietf.org/id/draft-tsou-dime-routing-problem-statement- > 00.txt > > Please let me us know whether you have objections or whether you are in > support of this document becoming a WG item. I wasn't aware that even the design team had reached any consensus on this document. If I'm correct, why is it being taken to the WG? ---------------- Today in History 1927 U.S. Marines re-invade Nicaragua after ending a 13-year occupation _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jan 6 16:48:55 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FDEE3A68CE; Tue, 6 Jan 2009 16:48:55 -0800 (PST) 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 D892E3A68E7 for ; Tue, 6 Jan 2009 16:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.802 X-Spam-Level: X-Spam-Status: No, score=-1.802 tagged_above=-999 required=5 tests=[AWL=0.796, 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 qBPSfHlTGmyC for ; Tue, 6 Jan 2009 16:48:54 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id E722C3A68CE for ; Tue, 6 Jan 2009 16:48:53 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KD2004M2SX3MA@szxga04-in.huawei.com> for dime@ietf.org; Wed, 07 Jan 2009 08:48:39 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KD200F5HSX3GD@szxga04-in.huawei.com> for dime@ietf.org; Wed, 07 Jan 2009 08:48:39 +0800 (CST) Received: from z24109b ([10.70.39.116]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KD200M8DSX363@szxml05-in.huawei.com> for dime@ietf.org; Wed, 07 Jan 2009 08:48:39 +0800 (CST) Date: Wed, 07 Jan 2009 08:48:40 +0800 From: Tina TSOU To: 'Hannes Tschofenig' , Glen Zorn Message-id: <005a01c97061$aed8eb40$7427460a@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 X-Priority: 3 X-MSMail-priority: Normal References: <027501c97007$4c2d02b0$0201a8c0@nsnintra.net> <00ed01c97051$ec21f4c0$c465de40$@net> Cc: dime@ietf.org Subject: Re: [Dime] HUM regarding draft-tsou-dime-routing-problem-statement-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: , Content-Type: multipart/mixed; boundary="===============0539752439==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0539752439== Content-type: multipart/alternative; boundary="Boundary_(ID_wAUBC0YG0i4E+J2JBYV3Mw)" This is a multi-part message in MIME format. --Boundary_(ID_wAUBC0YG0i4E+J2JBYV3Mw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Dear all, http://groups.google.com/group/diameter-routing/browse_thread/thread/80456ee8ef720a73 Wish you a prosperous and healthy New Year:D B. R. Tina ----- Original Message ----- From: Glen Zorn To: 'Hannes Tschofenig' Cc: dime@ietf.org Sent: Wednesday, January 07, 2009 6:55 AM Subject: Re: [Dime] HUM regardingdraft-tsou-dime-routing-problem-statement-00.txt Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] writes: > Hi all, > > we would like to hear your feedback regarding the document that is > being > developed as part of the design team work on Diameter routing, see > http://tools.ietf.org/id/draft-tsou-dime-routing-problem-statement- > 00.txt > > Please let me us know whether you have objections or whether you are in > support of this document becoming a WG item. I wasn't aware that even the design team had reached any consensus on this document. If I'm correct, why is it being taken to the WG? ---------------- Today in History 1927 U.S. Marines re-invade Nicaragua after ending a 13-year occupation _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --Boundary_(ID_wAUBC0YG0i4E+J2JBYV3Mw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Dear all,
 
Wish you a prosperous and healthy New Year:D
 
B. R.
Tina
----- Original Message -----
From: Glen Zorn
Sent: Wednesday, January 07, 2009 6:55 AM
Subject: Re: [Dime] HUM regardingdraft-tsou-dime-routing-problem-statement-00.txt

Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] writes:

> Hi all,
>
> we would like to hear your feedback regarding the document that is
> being
> developed as part of the design team work on Diameter routing, see
> http://tools.ietf.org/id/draft-tsou-dime-routing-problem-statement-
> 00.txt
>
> Please let me us know whether you have objections or whether you are in
> support of this document becoming a WG item.

I wasn't aware that even the design team had reached any consensus on this
document.  If I'm correct, why is it being taken to the WG?

----------------
Today in History
1927 U.S. Marines re-invade Nicaragua after ending a 13-year occupation




_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
--Boundary_(ID_wAUBC0YG0i4E+J2JBYV3Mw)-- --===============0539752439== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0539752439==-- From dime-bounces@ietf.org Wed Jan 7 00:15:19 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7234E3A6A04; Wed, 7 Jan 2009 00:15:19 -0800 (PST) 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 CD67A3A6989 for ; Wed, 7 Jan 2009 00:15:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.605 X-Spam-Level: X-Spam-Status: No, score=-3.605 tagged_above=-999 required=5 tests=[AWL=-1.006, 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 y-8z57hXQ9OK for ; Wed, 7 Jan 2009 00:15:18 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id C412D3A6A04 for ; Wed, 7 Jan 2009 00:15:17 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n078Ew0V025842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 7 Jan 2009 09:14:58 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n078EsbJ016475; Wed, 7 Jan 2009 09:14:58 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Jan 2009 09:14:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 7 Jan 2009 10:15:22 +0200 Message-ID: In-Reply-To: <00ed01c97051$ec21f4c0$c465de40$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] HUM regarding draft-tsou-dime-routing-problem-statement-00.txt Thread-Index: AclwB0uUWJ5Bv5ACTn+83q1hRbTRzwASj8EgABLXZiA= References: <027501c97007$4c2d02b0$0201a8c0@nsnintra.net> <00ed01c97051$ec21f4c0$c465de40$@net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "Glen Zorn" X-OriginalArrivalTime: 07 Jan 2009 08:14:53.0203 (UTC) FILETIME=[04A8F630:01C970A0] Cc: dime@ietf.org Subject: Re: [Dime] HUM regarding draft-tsou-dime-routing-problem-statement-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org The design team has not reached consensus on this document. Glen, as you have seen Tina suggested within the DT and also on the DIME mailing list to ask the group whether it can be picked up as a WG item (assuming that it serves as a starting point). Ciao Hannes >-----Original Message----- >From: Glen Zorn [mailto:glenzorn@comcast.net] >Sent: 07 January, 2009 00:56 >To: 'Hannes Tschofenig' >Cc: dime@ietf.org >Subject: RE: [Dime] HUM regarding >draft-tsou-dime-routing-problem-statement-00.txt > >Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] writes: > >> Hi all, >> >> we would like to hear your feedback regarding the document that is >> being developed as part of the design team work on Diameter routing, >> see >> http://tools.ietf.org/id/draft-tsou-dime-routing-problem-statement- >> 00.txt >> >> Please let me us know whether you have objections or whether you are >> in support of this document becoming a WG item. > >I wasn't aware that even the design team had reached any >consensus on this document. If I'm correct, why is it being >taken to the WG? > >---------------- >Today in History >1927 U.S. Marines re-invade Nicaragua after ending a 13-year occupation > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jan 7 03:03:46 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDABD3A68F4; Wed, 7 Jan 2009 03:03:46 -0800 (PST) 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 BED153A6829 for ; Wed, 7 Jan 2009 03:03:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.671 X-Spam-Level: X-Spam-Status: No, score=-4.671 tagged_above=-999 required=5 tests=[AWL=-1.422, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-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 Cp7Rw5ZjA785 for ; Wed, 7 Jan 2009 03:03:43 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 9B6733A6915 for ; Wed, 7 Jan 2009 03:03:42 -0800 (PST) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Jan 2009 12:03:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 7 Jan 2009 12:03:25 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026061E2759@ftrdmel2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of the Diameter ERP draft Thread-Index: Aclv59WtrDSfQEMYSRqhgB28G3b9YwACm5EwAARjTIAAGsZaAAAPM+qQ From: To: X-OriginalArrivalTime: 07 Jan 2009 11:03:28.0542 (UTC) FILETIME=[91DF33E0:01C970B7] Subject: [Dime] Review of the Diameter ERP 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org = Hi, Here is my review for the Diameter ERP draft. General comments: - About alignment with RFC 5296: the draft needs to be updated according to the publication of the RFC 5296.= Some proposals are provided below. - About ER server/AAA agent co-location: In my understanding, it is assumed in this document ER server and AAA proxy= have to be co-located to be able to rely on Diameter to transport ERP spec= ific AVPs. This doesn't maybe preclude other architectural choices but ther= e are outside the scope of this document. It is necessary to clarify this p= oint in this document. - ERP support discovery: As the ERP specific AVPs are introduced with the M-bit cleared, these AVPs= are purely optional for the Diameter EAP application i.e. they can be sile= ntly ignored by Diameter servers that do not understand this new AVPs. Some= text should be provided to describe how the local ER server discovers that= the Home EAP server doesn't support ERP and the behaviour of the local ER = server in that case. Hereafter is the rest of my review with comments and proposals. Best Regards, Lionel *************************************** Abstract An EAP extension, called "EAP Re-authentication Protocol (ERP)", has been specified that supports an EAP method-independent protocol for efficient re-authentication between the peer and the server through an authenticator. This document specifies Diameter support for ERP. The Diameter EAP application is re-used for encapsulating the newly defined EAP Initiate and EAP Finish messages specified in the ERP specification. AVPs for request and delivery of Domain Specific Root Keys from the AAA/EAP server to the ER server are also specified. Additionally, this document also specifies Diameter processing rules relevant to ERP. [LM] some abusive verbiage in the abstract: Proposal for new abstract: "EAP Re-authentication Protocol defines extensions of EAP to support = efficient re-authentication between the peer and an EAP re-authentication server through any authenticator. This document = specifies Diameter support for ERP. The Diameter EAP application is re-used for encapsulating the newly defined EAP messages specified = in the ERP specification. Additionally, this document also defines specific Diameter processing rules relevant to ERP." 1. Introduction RFC 4072 [1] specifies a Diameter application that carries EAP packets between a Diameter client and the Diameter Server/EAP server. [2] defines the EAP Re-authentication Protocol to allow faster re- authentication of a previously authenticated peer. [LM] s/[2] defines the EAP Re-authentication Protocol/RFC 5296 [2] defines = the EAP Re-authentication Protocol (ERP) In ERP, a peer authenticates to the network by proving possession of key material derived during a previous EAP exchange. = [LM] s/a peer authenticate to/a peer is authenticated by For this purpose, an Extended Master Session Key (EMSK) based re-authentication key hierarchy has been defined [5]. ERP may be executed between the ER peer and an ER server in the peer's home domain or the local domain = visited by the peer. In the latter case, a Domain Specific Root Key (DSRK), derived from the EMSK, is provided to the local domain ER server. = [LM] s/is provided to/is provided by the Home ER server to The peer and the local server subsequently use the re- authentication key hierarchy from the DSRK to authenticate and derive authenticator specific keys within that domain. [LM] this information can be found in the RFC 5296. Remove the sentence abo= ve. = To accomplish the reauthentication functionality, ERP defines two new EAP codes - EAP Initiate and EAP Finish. [LM] s/ERP defines two new EAP codes/ERP defines two new EAP messages This document specifies the reuse of Diameter EAP application to carry these new EAP messages. The DSRK can be obtained as part of the regular EAP exchange or as part of an ERP bootstrapping exchange. The local ER server requesting the DSRK needs to be in the path of the EAP or ERP bootstrapping exchange in order to request and obtain the DSRK. This document also specifies how the DSRK is transported to the local ER server using Diameter. [LM] Finally, i would reorganize the last part as follow: ::::::::::: "In ERP, a peer is authenticated by the network thanks to keying material obtained during a previous EAP exchange. This keying material is derived from the Extended Master Session Key (EMSK) defined in the RFC 5295 [5]. = To accomplish the EAP reauthentication functionality, ERP defines two new EAP messages - EAP Initiate and EAP Finish. This document specifies the reuse of Diameter EAP Application to carry these new EAP messages. ERP is executed between the peer and a server located either in the peer= 's home domain or in the local domain visited by the peer. In the latter ca= se, a Domain Specific Root Key (DSRK) is derived from the EMSK, as defined i= n = the RFC 5295 [5], and is provided by the Home EAP server to the local do= main server. For that purpose, this document specifies the transport of the D= SRK using the Diameter EAP Application." :::::::::::::: 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. This document uses terminology defined in [6], [5], [2], and [1]. 3. Assumptions This document defines additional optional AVPs for usage with the Diameter EAP application. Routing of these messages is therefore provided via the Diameter Application Identifier (among other elements), as specified by the Diameter Base protocol [4]. [LM] To avoid any ambiguity I would say: "This document defines only additional optional AVPs for usage with the Diameter EAP application. This document does not defined a new Diameter application and a new Application ID is therefore not required, as described in the Diameter Base protocol [4]." = Based on the deployment of ERP, a local Diameter server (the same entity serves as a Diameter proxy during the full EAP authentication) may play the role of the ER server for future re-authentication attempts. As such, the local Diameter server requesting the DSRK needs to be in the path of the current EAP exchange between the peer and the EAP server and also along in the future. The Diameter client is furthermore assumed to be able to route the re-authentication messages to the ER server. [LM] I think that the assumption all along this document is that the local = ER server and the AAA agent are co-located, to be able to rely on DEA for = the transport of DSRK. In that case, I would say something like: "In this document, when EAP re-authentication is performed in the domain visited by the peer, it is assumed that the local ER server is co-locat= ed with a Diameter agent in the visited domain present in the path of the = full EAP exchange." 4. Diameter Support for ERP 4.1. Protocol Overview Diameter may be used to transport ERP messages between the NAS (authenticator) and an authentication server (ER server). [LM] s/may/is (the use of Diameter is a pre-requisite in this draft) In ERP, the peer sends an EAP Initiate Reauth message to the ER server via the authenticator. [LM] s/"EAP Initiate Reauth message"/"EAP-Initiate/Re-auth message" (same a= ll along the document) Alternatively, the NAS may send an EAP Initiate Reauth-Start message to the peer to trigger the start of ERP; the peer then responds with an EAP Initiate Reauth message to the NAS. [LM] s/"EAP Initiate Reauth-Start message"/"EAP-Initiate/Re-auth-Start mess= age" (same all along the document) The general guidelines for encapsulating EAP messages in Diameter from RFC 4072 [1] apply to the new EAP messages defined for ERP as well. The EAP Initiate Reauth message is encapsulated in an EAP- Payload AVP of a Diameter EAP-Request message by the NAS and sent to the Diameter server. The NAS MUST copy the contents of the value field of the 'rIKName as NAI' TLV or the peer-id TLV (when the former is not present) of the EAP Initiate Reauth message into a User-Name AVP of the Diameter EAP-Request. [LM] I think that we are talking about the 'keyName-NAI' TLV and not anymor= e the 'rIKName as NAI' TLV. Moreover, in which case the peer-id TLV would = not be present for ERP? The ER server processes the EAP Initiate Reauth message in accordance with [2], and if that is successful, it responds with an EAP Finish Reauth message indicating a success ('R' flag set to 0). The Diameter server MUST encapsulate the EAP Finish Reauth message with the R flag set to zero in an EAP-Payload AVP attribute of a Diameter EAP-Answer message. An EAP-Master-Session-Key AVP included in the Diameter EAP-Answer contains the Re-authentication Master Session Key (rMSK). The Diameter Result Code, if any, SHOULD be a success Result Code. If the processing of the EAP Initiate Reauth message resulted in a failure, the Diameter server MUST encapsulate an EAP Finish Reauth message indicating failure ('R' flag set to 1) in an EAP-Payload AVP of a Diameter EAP-Answer message. The Diameter Result Code, if any, SHOULD be a failure Result Code. Whether an EAP Finish Reauth message is sent at all is specified in [2]. [LM] the use of the 'R' flag is not relevant for Diameter EAP. [LM] according to the RFC, the EAP-Finish/Re-auth is sent back in any case,= success or failure. [LM] according to the above comments, I would rephrase the text as follow: = "The ER server processes the EAP Initiate Reauth message in accordance with [2] and responds with an EAP-Finish/Re-auth message. The Diameter server MUST encapsulate the EAP-Finish/Re-auth message within an EAP-Payload AVP of a Diameter EAP-Answer message. In an EAP re-authentication successful case, an EAP-Master-Session-Key AVP is included in the Diameter EAP-Answer message that contains the Re-authentication Master Session Key (rMSK). The Diameter Result-Code SHOULD be a success Result-Code. In an EAP re-authentication failure case, the Diameter Result-Code of the a Diameter EAP-Answer message SHOULD be a failure Result-Code and no EAP-Master-Session-Key AVP is present." [LM] By the way, I don't understand the "SHOULD" for the result-code. Any r= eason not to use "MUST" here? [LM] a figure could be added for illustration here. 4.2. DSRK Request and Delivery A local ER server, collocated with a Diameter proxy in the peer's visited domain, [LM] s/in the peer's visited domain/in the domain visited by the peer may request a DSRK from the EAP server, either in the initial EAP exchange (implicit bootstrapping) or in an ERP bootstrapping exchange (explicit bootstrapping). It does this by including the EAP-DSRK-Request AVP in the Diameter EAP-Response message. The EAP-DSRK-Request AVP contains the domain or server identity required to derive the DSRK. [LM] the EAP-DSRK-Request AVP is included in the Diameter EAP-Request (and = not in the response) An EAP server MAY send the DSRK when it receives a valid Diameter EAP-Request message containing an EAP-DSRK-Request AVP. An ER server MUST send the DSRK (or send a failure result) when it receives a valid Diameter EAP-Request message containing an EAP-DSRK-Request AVP along with a valid EAP Initiate Re-auth packet with the bootstrapping flag turned on. If an EAP-DSRK-Request AVP is included in any other Diameter EAP-Request message, the Diameter server MUST reply with a failure result. An EAP-DSRK AVP MUST be used to send a DSRK; an EAP- DSRK-Name AVP MUST be used to send the DSRK's keyname; and an EAP- DSRK-Lifetime AVP MUST be used to send the DSRK's lifetime. [LM] I don't understand the intention of the above text. Could it be enough= to say: In successful case, the DSRK is carried by the EAP-DSRK AVP in the Diameter EAP response message. Along with the EAP-DSRK AVP, an EAP-DSRK-Name AVP MUST be used to send the DSRK's keyname and an EAP-DSRK-Lifetime AVP MUST be used to send the DSRK's lifetime. [LM] a figure could be added for illustration here. 5. Command Codes [LM] this section is not required as there is nothing specific for ERP. We = should skip it. [SKIP] 6. Attribute Value Pair Definitions 6.1. EAP-DSRK-Request AVP The EAP-DSRK AVP (AVP Code TBD) is of type DiameterIdentity. [LM] s/EAP-DSRK AVP/EAP-DSRK-Request AVP This AVP fulfills two purposes: First, it indicates that a ER server is located in the local domain that is willing to play the role of an ER server for a particular session. Second, it conveys information about the domain and ER server identity to the Diameter/EAP server. [LM] the use of this AVP is explained above. There is no need to explain ag= ain. Moreover, if a DiameterIdentity is used, it is to indicate a server an= d not a domain. Right? = 6.2. EAP-DSRK AVP The EAP-DSRK AVP (AVP Code TBD) is of type OctetString. The Domain Specific Root Key (DSRK) is carried in this payload. 6.3. EAP-DSRK-Name AVP The EAP-DSRK-Name AVP (AVP Code TBD) is of type OctetString. This AVP contains the name of the DSRK key that is later used during the re-authentication exchange to select the correct DSRK. [LM] skip the part starting by "that is..." 6.4. EAP-DSRK-Lifetime AVP The EAP-DSRK-Lifetime AVP (AVP Code TBD) is of type Unsigned64 and contains the DSRK lifetime in seconds. 7. AVP Occurrence Table The following table lists the AVPs that may optionally be present in the DER and DEA commands [1]. +---------------+ | Command-Code | +-+-----+-----+-+ Attribute Name | DER | DEA | -------------------------------|-----+-----+ EAP-DSRK-Request | 0-1 | 0 | EAP-DSRK | 0 | 0-1 | EAP-DSRK-Name | 0 | 0-1 | EAP-DSRK-Lifetime | 0 | 0-1 | +-----+-----+ Figure 4: DER and DEA Commands AVP Table When the EAP-DSRK AVP is present in the DEA then the EAP-DSRK-Name and the EAP-DSRK-Lifetime MUST also be present. 8. AVP Flag Rules The following table describes the Diameter AVPs, their AVP Code values, types, possible flag values, and whether the AVP MAY be encrypted. The Diameter base [4] specifies the AVP Flag rules for AVPs in Section 4.5. +---------------------+ | AVP Flag Rules | +----+-----+----+-----+----+ AVP Section | | |SHLD|MUST | | Attribute Name Code Defined Data Type |MUST| MAY |NOT |NOT |Encr| ------------------------------------------+----+-----+----+-----+----+ EAP-DSRK-Request TBD 4.7.1 DiamIdent | | P | | V,M | Y | EAP-DSRK TBD 4.7.2 OctetString| | P | | V,M | Y | EAP-DSRK-Name TBD 4.7.3 OctetString| | P | | V,M | Y | EAP-DSRK-Lifetime TBD 4.7.4 Unsigned64 | | P | | V,M | Y | ------------------------------------------+----+-----+----+-----+----+ Due to space constraints, the short form DiamIdent is used to represent DiameterIdentity. Figure 5: AVP Flag Rules Table [LM] this table is ok according to the current RFC 3588. I don't know how t= o deal with it regarding the RFC3588bis... 9. Security Considerations The security considerations specified in RFC 4072 [1], and RFC 3588 [4] are applicable to this document. EAP channel bindings may be necessary to ensure that the Diameter client and the server are in sync regarding the key Requesting Entity's Identity. Specifically, the Requesting Entity advertises its identity through the EAP lower layer, and the user or the EAP peer communicates that identity to the EAP server (and the EAP server communicates that identity to the Diameter server) via the EAP method for user/peer to server verification of the Requesting Entity's Identity. 10. IANA Considerations This document requires IANA registration of the following new AVPs to the AVP registry established by RFC 3588 [4]: o EAP-DSRK-Request o EAP-DSRK o EAP-DSRK-Name o EAP-DSRK-Lifetime = > -----Message d'origine----- > De : Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Envoy=E9 : mardi 6 janvier 2009 14:58 > =C0 : BOURNELLE Julien RD-CORE-ISS; sdecugis@nict.go.jp; = > ldondeti@qualcomm.com Cc : MORAND Lionel RD-CORE-ISS Objet : RE: = > Diameter ERP > = > Hi Lionel, > = > No objections. = > = > Please also keep in mind that you have to complete the work on = > http://tools.ietf.org/id/draft-korhonen-dime-nai-routing-02.txt > = > Ciao > Hannes > = > >-----Original Message----- > >From: julien.bournelle@orange-ftgroup.com > >[mailto:julien.bournelle@orange-ftgroup.com] > >Sent: 06 January, 2009 13:33 > >To: Hannes.Tschofenig@gmx.net; sdecugis@nict.go.jp; = > >ldondeti@qualcomm.com > >Cc: lionel.morand@orange-ftgroup.com > >Subject: RE: Diameter ERP > > > >Hi all, > > > > Lionel also whishes to work with us on this document. > > > > First task is to reply to jouni's comment. I'll send you a > draft reply > >in the week. > > > > happy new year ! > > > > Julien > > > >> -----Message d'origine----- > >> De : Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> Envoy=E9 : mardi 6 janvier 2009 11:16 =C0 : sdecugis@nict.go.jp; = > >> BOURNELLE Julien RD-CORE-ISS; ldondeti@qualcomm.com Objet : = > >> Diameter ERP > >> = > >> Hi Julien, Hi Sebastien, Hi Lakshminath, > >> = > >> I would like you three to work together on the document. = > >> Please make some progress. = > >> = > >> The XML version of the draft (-00 and -01) can be found here: = > >> http://www.tschofenig.priv.at/svn/draft-dondeti-dime-erp-diameter/ > >> = > >> Ciao > >> Hannes > >> = > >> = > > > = > = _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 8 02:18:32 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BFFD3A6827; Thu, 8 Jan 2009 02:18:32 -0800 (PST) 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 72CEF3A6858 for ; Thu, 8 Jan 2009 02:18:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rB2VcIY369-F for ; Thu, 8 Jan 2009 02:18:29 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id EAA2A3A6827 for ; Thu, 8 Jan 2009 02:18:28 -0800 (PST) Received: by bwz14 with SMTP id 14so27004604bwz.13 for ; Thu, 08 Jan 2009 02:18:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=pdaeNWVwBI7CkRoE6KibPx9S9BENNFwK9v3SwFe3i8A=; b=a+jvMjRKrW7UvfJyeaS+LtRWbPcxWjEU6rnGZ0wVAOniYdFe2jdxquaqY6KdqRn+J7 l/k0Pm/u+KRCZBkcNK1N/vPee6BL+zjVGCug4BhEJp1e3RFy2lDyN0UBDQ0bh7aNgkHl bAMEN+qJpqTk9jECgtJ6PTsKqP7ezoRUzDNv8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=fULycqGUUnMkAneFMnNzGv5e2ry70Jd++UnNq0HYkWXpWVtuZDuPGJgkOryCpbM6u9 TiNf8GiaxXeyKxmPGFgP1It0L4rbgvVK3b1sgbpq73LMOZiZc/Yg3wGMOTnOsasBn0Ec HYK4PVc42OxUaTHJesh3hQLunW0SwokUt9D5Q= Received: by 10.223.108.15 with SMTP id d15mr8841318fap.105.1231409893750; Thu, 08 Jan 2009 02:18:13 -0800 (PST) Received: by 10.223.108.129 with HTTP; Thu, 8 Jan 2009 02:18:13 -0800 (PST) Message-ID: <5e2406980901080218w746b69a7x320f1501aeb97266@mail.gmail.com> Date: Thu, 8 Jan 2009 11:18:13 +0100 From: "Julien Bournelle" To: lionel.morand@orange-ftgroup.com, "Sebastien Decugis" , dime@ietf.org In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB026061E2759@ftrdmel2> MIME-Version: 1.0 Content-Disposition: inline References: <7DBAFEC6A76F3E42817DF1EBE64CB026061E2759@ftrdmel2> Subject: Re: [Dime] Review of the Diameter ERP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi lionel, some comments inline. On Wed, Jan 7, 2009 at 12:03 PM, wrote: > > Hi, > > Here is my review for the Diameter ERP draft. > > General comments: > > - About alignment with RFC 5296: > the draft needs to be updated according to the publication of the RFC 5296. Some proposals are provided below. > > - About ER server/AAA agent co-location: > In my understanding, it is assumed in this document ER server and AAA proxy have to be co-located to be able to rely on Diameter to transport ERP specific AVPs. This doesn't maybe preclude other architectural choices but there are outside the scope of this document. It is necessary to clarify this point in this document. > > - ERP support discovery: > As the ERP specific AVPs are introduced with the M-bit cleared, these AVPs are purely optional for the Diameter EAP application i.e. they can be silently ignored by Diameter servers that do not understand this new AVPs. Some text should be provided to describe how the local ER server discovers that the Home EAP server doesn't support ERP and the behaviour of the local ER server in that case. I agree with these general comments. > > Hereafter is the rest of my review with comments and proposals. > > Best Regards, > > Lionel > > *************************************** > > Abstract > > An EAP extension, called "EAP Re-authentication Protocol (ERP)", has > been specified that supports an EAP method-independent protocol for > efficient re-authentication between the peer and the server through > an authenticator. This document specifies Diameter support for ERP. > The Diameter EAP application is re-used for encapsulating the newly > defined EAP Initiate and EAP Finish messages specified in the ERP > specification. AVPs for request and delivery of Domain Specific Root > Keys from the AAA/EAP server to the ER server are also specified. > Additionally, this document also specifies Diameter processing rules > relevant to ERP. > > [LM] some abusive verbiage in the abstract: > > Proposal for new abstract: > > "EAP Re-authentication Protocol defines extensions of EAP to support > efficient re-authentication between the peer and an EAP > re-authentication server through any authenticator. I'm wondering if we should note that the authenticator may be ERP-aware. I'm thinking about the case where the authenticator sends the EAP-Initiate/Re-auth-Start (Figure 4 in RFC 5296) > This document > specifies Diameter support for ERP. The Diameter EAP application is > re-used for encapsulating the newly defined EAP messages specified > in the ERP specification. Additionally, this document also defines > specific Diameter processing rules relevant to ERP." ok > > > 1. Introduction > > RFC 4072 [1] specifies a Diameter application that carries EAP > packets between a Diameter client and the Diameter Server/EAP server. > [2] defines the EAP Re-authentication Protocol to allow faster re- > authentication of a previously authenticated peer. > > [LM] s/[2] defines the EAP Re-authentication Protocol/RFC 5296 [2] defines the EAP Re-authentication Protocol (ERP) > > In ERP, a peer > authenticates to the network by proving possession of key material > derived during a previous EAP exchange. > > [LM] s/a peer authenticate to/a peer is authenticated by > > For this purpose, an > Extended Master Session Key (EMSK) based re-authentication key > hierarchy has been defined [5]. ERP may be executed between the ER > peer and an ER server in the peer's home domain or the local domain > visited by the peer. In the latter case, a Domain Specific Root Key > (DSRK), derived from the EMSK, is provided to the local domain ER > server. > > [LM] s/is provided to/is provided by the Home ER server to > > The peer and the local server subsequently use the re- > authentication key hierarchy from the DSRK to authenticate and derive > authenticator specific keys within that domain. > > [LM] this information can be found in the RFC 5296. Remove the sentence above. It may help the reader to understand the purpose of this DRSK. > > To accomplish the > reauthentication functionality, ERP defines two new EAP codes - EAP > Initiate and EAP Finish. > > [LM] s/ERP defines two new EAP codes/ERP defines two new EAP messages I would prefer to say that ERP defines two new EAP Codes here. These newly EAP packets are then carried in messages (dependent of the protocol used). > > This document specifies the reuse of > Diameter EAP application to carry these new EAP messages. > The DSRK can be obtained as part of the regular EAP exchange or as > part of an ERP bootstrapping exchange. The local ER server > requesting the DSRK needs to be in the path of the EAP or ERP > bootstrapping exchange in order to request and obtain the DSRK. This > document also specifies how the DSRK is transported to the local ER > server using Diameter. > > [LM] Finally, i would reorganize the last part as follow: > > ::::::::::: > > "In ERP, a peer is authenticated by the network thanks to keying material > obtained during a previous EAP exchange. This keying material is derived > from the Extended Master Session Key (EMSK) defined in the RFC 5295 [5]. > To accomplish the EAP reauthentication functionality, ERP defines two new > EAP messages - EAP Initiate and EAP Finish. This document specifies the > reuse of Diameter EAP Application to carry these new EAP messages. > > ERP is executed between the peer and a server located either in the peer's > home domain or in the local domain visited by the peer. In the latter case, > a Domain Specific Root Key (DSRK) is derived from the EMSK, as defined in > the RFC 5295 [5], and is provided by the Home EAP server to the local domain > server. For that purpose, this document specifies the transport of the DSRK > using the Diameter EAP Application." First paragraph is the old and second the new ? > > :::::::::::::: > > > > 2. Terminology > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [3]. > > This document uses terminology defined in [6], [5], [2], and [1]. > > > 3. Assumptions > > This document defines additional optional AVPs for usage with the > Diameter EAP application. Routing of these messages is therefore > provided via the Diameter Application Identifier (among other > elements), as specified by the Diameter Base protocol [4]. > > [LM] To avoid any ambiguity I would say: > > "This document defines only additional optional AVPs for usage with > the Diameter EAP application. This document does not defined > a new Diameter application and a new Application ID is therefore not > required, as described in the Diameter Base protocol [4]." ok > > Based on > the deployment of ERP, a local Diameter server (the same entity > serves as a Diameter proxy during the full EAP authentication) may > play the role of the ER server for future re-authentication attempts. > As such, the local Diameter server requesting the DSRK needs to be in > the path of the current EAP exchange between the peer and the EAP > server and also along in the future. The Diameter client is > furthermore assumed to be able to route the re-authentication > messages to the ER server. > > [LM] I think that the assumption all along this document is that the local ER server and the AAA agent are co-located, to be able to rely on DEA for the transport of DSRK. In that case, I would say something like: > > "In this document, when EAP re-authentication is performed in the domain > visited by the peer, it is assumed that the local ER server is co-located > with a Diameter agent in the visited domain present in the path of the full > EAP exchange." ok > > > 4. Diameter Support for ERP > > 4.1. Protocol Overview > > Diameter may be used to transport ERP messages between the NAS > (authenticator) and an authentication server (ER server). > > [LM] s/may/is (the use of Diameter is a pre-requisite in this draft) > > In ERP, the peer sends an EAP Initiate Reauth message to the ER > server via the authenticator. > > [LM] s/"EAP Initiate Reauth message"/"EAP-Initiate/Re-auth message" (same all along the document) > > Alternatively, the NAS may send an EAP > Initiate Reauth-Start message to the peer to trigger the start of > ERP; the peer then responds with an EAP Initiate Reauth message to > the NAS. > > [LM] s/"EAP Initiate Reauth-Start message"/"EAP-Initiate/Re-auth-Start message" (same all along the document) > > The general guidelines for encapsulating EAP messages in Diameter > from RFC 4072 [1] apply to the new EAP messages defined for ERP as > well. The EAP Initiate Reauth message is encapsulated in an EAP- > Payload AVP of a Diameter EAP-Request message by the NAS and sent to > the Diameter server. The NAS MUST copy the contents of the value > field of the 'rIKName as NAI' TLV or the peer-id TLV (when the former > is not present) of the EAP Initiate Reauth message into a User-Name > AVP of the Diameter EAP-Request. > > [LM] I think that we are talking about the 'keyName-NAI' TLV and not anymore the 'rIKName as NAI' TLV. Considering section 5.3.2 of RFC 5296. I agree. >Moreover, in which case the peer-id TLV would not be present for ERP? Privacy ? > > The ER server processes the EAP Initiate Reauth message in accordance > with [2], and if that is successful, it responds with an EAP Finish > Reauth message indicating a success ('R' flag set to 0). The > Diameter server MUST encapsulate the EAP Finish Reauth message with > the R flag set to zero in an EAP-Payload AVP attribute of a Diameter > EAP-Answer message. An EAP-Master-Session-Key AVP included in the > Diameter EAP-Answer contains the Re-authentication Master Session Key > (rMSK). The Diameter Result Code, if any, SHOULD be a success Result > Code. > > If the processing of the EAP Initiate Reauth message resulted in a > failure, the Diameter server MUST encapsulate an EAP Finish Reauth > message indicating failure ('R' flag set to 1) in an EAP-Payload AVP > of a Diameter EAP-Answer message. The Diameter Result Code, if any, > SHOULD be a failure Result Code. Whether an EAP Finish Reauth > message is sent at all is specified in [2]. > > [LM] the use of the 'R' flag is not relevant for Diameter EAP. > [LM] according to the RFC, the EAP-Finish/Re-auth is sent back in any case, success or failure. > [LM] according to the above comments, I would rephrase the text as follow: > > > "The ER server processes the EAP Initiate Reauth message in accordance > with [2] and responds with an EAP-Finish/Re-auth message. The Diameter > server MUST encapsulate the EAP-Finish/Re-auth message within an > EAP-Payload AVP of a Diameter EAP-Answer message. > In an EAP re-authentication successful case, an EAP-Master-Session-Key > AVP is included in the Diameter EAP-Answer message that contains the > Re-authentication Master Session Key (rMSK). The Diameter Result-Code > SHOULD be a success Result-Code. > In an EAP re-authentication failure case, the Diameter Result-Code of > the a Diameter EAP-Answer message SHOULD be a failure Result-Code and > no EAP-Master-Session-Key AVP is present." > > [LM] By the way, I don't understand the "SHOULD" for the result-code. Any reason not to use "MUST" here? I think a MUST would be better. Different views ? > [LM] a figure could be added for illustration here. > > 4.2. DSRK Request and Delivery > > A local ER server, collocated with a Diameter proxy in the peer's > visited domain, > > [LM] s/in the peer's visited domain/in the domain visited by the peer > > may request a DSRK from the EAP server, either in the > initial EAP exchange (implicit bootstrapping) or in an ERP > bootstrapping exchange (explicit bootstrapping). It does this by > including the EAP-DSRK-Request AVP in the Diameter EAP-Response > message. The EAP-DSRK-Request AVP contains the domain or server > identity required to derive the DSRK. > > [LM] the EAP-DSRK-Request AVP is included in the Diameter EAP-Request (and not in the response) yes. > > An EAP server MAY send the DSRK when it receives a valid Diameter > EAP-Request message containing an EAP-DSRK-Request AVP. An ER server > MUST send the DSRK (or send a failure result) when it receives a > valid Diameter EAP-Request message containing an EAP-DSRK-Request AVP > along with a valid EAP Initiate Re-auth packet with the bootstrapping > flag turned on. If an EAP-DSRK-Request AVP is included in any other > Diameter EAP-Request message, the Diameter server MUST reply with a > failure result. An EAP-DSRK AVP MUST be used to send a DSRK; an EAP- > DSRK-Name AVP MUST be used to send the DSRK's keyname; and an EAP- > DSRK-Lifetime AVP MUST be used to send the DSRK's lifetime. > > [LM] I don't understand the intention of the above text. Could it be enough to say: > > In successful case, the DSRK is carried by the EAP-DSRK AVP in the > Diameter EAP response message. Along with the EAP-DSRK AVP, an > EAP-DSRK-Name AVP MUST be used to send the DSRK's keyname and an > EAP-DSRK-Lifetime AVP MUST be used to send the DSRK's lifetime. Agree. > > [LM] a figure could be added for illustration here. > > 5. Command Codes > > [LM] this section is not required as there is nothing specific for ERP. We should skip it. > > [SKIP] > > > 6. Attribute Value Pair Definitions > > 6.1. EAP-DSRK-Request AVP > > The EAP-DSRK AVP (AVP Code TBD) is of type DiameterIdentity. > > [LM] s/EAP-DSRK AVP/EAP-DSRK-Request AVP > > This > AVP fulfills two purposes: First, it indicates that a ER server is > located in the local domain that is willing to play the role of an ER > server for a particular session. Second, it conveys information > about the domain and ER server identity to the Diameter/EAP server. > > [LM] the use of this AVP is explained above. There is no need to explain again. As we are in the AVP Definitions, I think it is better to keep some text explaining it. No ? > Moreover, if a DiameterIdentity is used, it is to indicate a server and not a domain. Right? In my understanding the local ER server only sends the Domain Name which will then be used to compute keys. Maybe the type DiameterIdentity is not appropriated and we should use UTF8String instead. What do you think ? > > 6.2. EAP-DSRK AVP > > The EAP-DSRK AVP (AVP Code TBD) is of type OctetString. The Domain > Specific Root Key (DSRK) is carried in this payload. > > 6.3. EAP-DSRK-Name AVP > > The EAP-DSRK-Name AVP (AVP Code TBD) is of type OctetString. This > AVP contains the name of the DSRK key that is later used during the > re-authentication exchange to select the correct DSRK. > > [LM] skip the part starting by "that is..." ok > > 6.4. EAP-DSRK-Lifetime AVP > > The EAP-DSRK-Lifetime AVP (AVP Code TBD) is of type Unsigned64 and > contains the DSRK lifetime in seconds. > > > 7. AVP Occurrence Table > > The following table lists the AVPs that may optionally be present in > the DER and DEA commands [1]. > > > +---------------+ > | Command-Code | > +-+-----+-----+-+ > Attribute Name | DER | DEA | > -------------------------------|-----+-----+ > EAP-DSRK-Request | 0-1 | 0 | > EAP-DSRK | 0 | 0-1 | > EAP-DSRK-Name | 0 | 0-1 | > EAP-DSRK-Lifetime | 0 | 0-1 | > +-----+-----+ > > Figure 4: DER and DEA Commands AVP Table > > When the EAP-DSRK AVP is present in the DEA then the EAP-DSRK-Name > and the EAP-DSRK-Lifetime MUST also be present. > > > 8. AVP Flag Rules > > The following table describes the Diameter AVPs, their AVP Code > values, types, possible flag values, and whether the AVP MAY be > encrypted. The Diameter base [4] specifies the AVP Flag rules for > AVPs in Section 4.5. > > > +---------------------+ > | AVP Flag Rules | > +----+-----+----+-----+----+ > AVP Section | | |SHLD|MUST | | > Attribute Name Code Defined Data Type |MUST| MAY |NOT |NOT |Encr| > ------------------------------------------+----+-----+----+-----+----+ > EAP-DSRK-Request TBD 4.7.1 DiamIdent | | P | | V,M | Y | > EAP-DSRK TBD 4.7.2 OctetString| | P | | V,M | Y | > EAP-DSRK-Name TBD 4.7.3 OctetString| | P | | V,M | Y | > EAP-DSRK-Lifetime TBD 4.7.4 Unsigned64 | | P | | V,M | Y | > ------------------------------------------+----+-----+----+-----+----+ > > Due to space constraints, the short form DiamIdent is used to > represent DiameterIdentity. > > Figure 5: AVP Flag Rules Table > > [LM] this table is ok according to the current RFC 3588. I don't know how to deal with it regarding the RFC3588bis... That's indeed a good question :). And that's all for my comments of your comments. Regards, --Julien-- _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 8 04:55:20 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B17B28C0F4; Thu, 8 Jan 2009 04:55:20 -0800 (PST) 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 E546428C0F4 for ; Thu, 8 Jan 2009 04:55:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.537 X-Spam-Level: X-Spam-Status: No, score=-5.537 tagged_above=-999 required=5 tests=[AWL=1.062, 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 mBYIZbKTqgfn for ; Thu, 8 Jan 2009 04:55:17 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 2ADDC28C0CF for ; Thu, 8 Jan 2009 04:55:15 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n08Cssgg004790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 8 Jan 2009 13:54:54 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n08CsqY0017213; Thu, 8 Jan 2009 13:54:53 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Jan 2009 13:54:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 8 Jan 2009 14:55:22 +0200 Message-ID: In-Reply-To: <5e2406980901080218w746b69a7x320f1501aeb97266@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Review of the Diameter ERP draft Thread-Index: AclxenKpDp1tiH+tR5acfa7D++IC0QAFZFSQ References: <7DBAFEC6A76F3E42817DF1EBE64CB026061E2759@ftrdmel2> <5e2406980901080218w746b69a7x320f1501aeb97266@mail.gmail.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Julien Bournelle" , , "Sebastien Decugis" , X-OriginalArrivalTime: 08 Jan 2009 12:54:52.0642 (UTC) FILETIME=[4C51AC20:01C97190] Subject: Re: [Dime] Review of the Diameter ERP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org One of the things I was not quite sure with the current protocol design is whether a Diameter application or just a bunch of AVPs are required. Based on the discussions a few of us when some of the HOKEY specs went to the IESG / IETF Last Call I got the impression that one has to define a new Diameter application (which would be based on Diameter EAP) since you assume that the messages are routed via a node in the local network and the support for ERP has to be ensured. Ciao Hannes >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >Behalf Of ext Julien Bournelle >Sent: 08 January, 2009 12:18 >To: lionel.morand@orange-ftgroup.com; Sebastien Decugis; dime@ietf.org >Subject: Re: [Dime] Review of the Diameter ERP draft > >Hi lionel, > > some comments inline. > >On Wed, Jan 7, 2009 at 12:03 PM, > wrote: >> >> Hi, >> >> Here is my review for the Diameter ERP draft. >> >> General comments: >> >> - About alignment with RFC 5296: >> the draft needs to be updated according to the publication >of the RFC 5296. Some proposals are provided below. >> >> - About ER server/AAA agent co-location: >> In my understanding, it is assumed in this document ER >server and AAA proxy have to be co-located to be able to rely >on Diameter to transport ERP specific AVPs. This doesn't maybe >preclude other architectural choices but there are outside the >scope of this document. It is necessary to clarify this point >in this document. >> >> - ERP support discovery: >> As the ERP specific AVPs are introduced with the M-bit >cleared, these AVPs are purely optional for the Diameter EAP >application i.e. they can be silently ignored by Diameter >servers that do not understand this new AVPs. Some text should >be provided to describe how the local ER server discovers that >the Home EAP server doesn't support ERP and the behaviour of >the local ER server in that case. > > > I agree with these general comments. > > >> >> Hereafter is the rest of my review with comments and proposals. >> >> Best Regards, >> >> Lionel >> >> *************************************** >> >> Abstract >> >> An EAP extension, called "EAP Re-authentication Protocol >(ERP)", has >> been specified that supports an EAP method-independent protocol for >> efficient re-authentication between the peer and the server through >> an authenticator. This document specifies Diameter >support for ERP. >> The Diameter EAP application is re-used for encapsulating the newly >> defined EAP Initiate and EAP Finish messages specified in the ERP >> specification. AVPs for request and delivery of Domain >Specific Root >> Keys from the AAA/EAP server to the ER server are also specified. >> Additionally, this document also specifies Diameter >processing rules >> relevant to ERP. >> >> [LM] some abusive verbiage in the abstract: >> >> Proposal for new abstract: >> >> "EAP Re-authentication Protocol defines extensions of EAP >to support >> efficient re-authentication between the peer and an EAP >> re-authentication server through any authenticator. > > I'm wondering if we should note that the authenticator may be >ERP-aware. >I'm thinking about the case where the authenticator sends the >EAP-Initiate/Re-auth-Start (Figure 4 in RFC 5296) > > >> This document >> specifies Diameter support for ERP. The Diameter EAP application is >> re-used for encapsulating the newly defined EAP messages specified >> in the ERP specification. Additionally, this document also defines >> specific Diameter processing rules relevant to ERP." > > ok > >> >> >> 1. Introduction >> >> RFC 4072 [1] specifies a Diameter application that carries EAP >> packets between a Diameter client and the Diameter >Server/EAP server. >> [2] defines the EAP Re-authentication Protocol to allow faster re- >> authentication of a previously authenticated peer. >> >> [LM] s/[2] defines the EAP Re-authentication Protocol/RFC 5296 [2] >> defines the EAP Re-authentication Protocol (ERP) >> >> In ERP, a peer >> authenticates to the network by proving possession of key material >> derived during a previous EAP exchange. >> >> [LM] s/a peer authenticate to/a peer is authenticated by >> >> For this purpose, an >> Extended Master Session Key (EMSK) based re-authentication key >> hierarchy has been defined [5]. ERP may be executed between the ER >> peer and an ER server in the peer's home domain or the local domain >> visited by the peer. In the latter case, a Domain Specific Root Key >> (DSRK), derived from the EMSK, is provided to the local domain ER >> server. >> >> [LM] s/is provided to/is provided by the Home ER server to >> >> The peer and the local server subsequently use the re- >> authentication key hierarchy from the DSRK to authenticate >and derive >> authenticator specific keys within that domain. >> >> [LM] this information can be found in the RFC 5296. Remove >the sentence above. > > It may help the reader to understand the purpose of this DRSK. > >> >> To accomplish the >> reauthentication functionality, ERP defines two new EAP codes - EAP >> Initiate and EAP Finish. >> >> [LM] s/ERP defines two new EAP codes/ERP defines two new EAP messages > > I would prefer to say that ERP defines two new EAP Codes >here. These newly EAP packets are then carried in messages >(dependent of the protocol used). > >> >> This document specifies the reuse of >> Diameter EAP application to carry these new EAP messages. >> The DSRK can be obtained as part of the regular EAP exchange or as >> part of an ERP bootstrapping exchange. The local ER server >> requesting the DSRK needs to be in the path of the EAP or ERP >> bootstrapping exchange in order to request and obtain the >DSRK. This >> document also specifies how the DSRK is transported to the local ER >> server using Diameter. >> >> [LM] Finally, i would reorganize the last part as follow: >> >> ::::::::::: >> >> "In ERP, a peer is authenticated by the network thanks to >keying material >> obtained during a previous EAP exchange. This keying >material is derived >> from the Extended Master Session Key (EMSK) defined in the >RFC 5295 [5]. >> To accomplish the EAP reauthentication functionality, ERP >defines two new >> EAP messages - EAP Initiate and EAP Finish. This document >specifies the >> reuse of Diameter EAP Application to carry these new EAP messages. >> >> ERP is executed between the peer and a server located >either in the peer's >> home domain or in the local domain visited by the peer. In >the latter case, >> a Domain Specific Root Key (DSRK) is derived from the >EMSK, as defined in >> the RFC 5295 [5], and is provided by the Home EAP server >to the local domain >> server. For that purpose, this document specifies the >transport of the DSRK >> using the Diameter EAP Application." > > First paragraph is the old and second the new ? > >> >> :::::::::::::: >> >> >> >> 2. Terminology >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and >"OPTIONAL" in this >> document are to be interpreted as described in RFC 2119 [3]. >> >> This document uses terminology defined in [6], [5], [2], and [1]. >> >> >> 3. Assumptions >> >> This document defines additional optional AVPs for usage with the >> Diameter EAP application. Routing of these messages is therefore >> provided via the Diameter Application Identifier (among other >> elements), as specified by the Diameter Base protocol [4]. >> >> [LM] To avoid any ambiguity I would say: >> >> "This document defines only additional optional AVPs for usage with >> the Diameter EAP application. This document does not defined >> a new Diameter application and a new Application ID is >therefore not >> required, as described in the Diameter Base protocol [4]." > > ok > >> >> Based on >> the deployment of ERP, a local Diameter server (the same entity >> serves as a Diameter proxy during the full EAP authentication) may >> play the role of the ER server for future >re-authentication attempts. >> As such, the local Diameter server requesting the DSRK >needs to be in >> the path of the current EAP exchange between the peer and the EAP >> server and also along in the future. The Diameter client is >> furthermore assumed to be able to route the re-authentication >> messages to the ER server. >> >> [LM] I think that the assumption all along this document is >that the local ER server and the AAA agent are co-located, to >be able to rely on DEA for the transport of DSRK. In that >case, I would say something like: >> >> "In this document, when EAP re-authentication is performed >in the domain >> visited by the peer, it is assumed that the local ER >server is co-located >> with a Diameter agent in the visited domain present in >the path of the full >> EAP exchange." > > ok > >> >> >> 4. Diameter Support for ERP >> >> 4.1. Protocol Overview >> >> Diameter may be used to transport ERP messages between the NAS >> (authenticator) and an authentication server (ER server). >> >> [LM] s/may/is (the use of Diameter is a pre-requisite in this draft) >> >> In ERP, the peer sends an EAP Initiate Reauth message to the ER >> server via the authenticator. >> >> [LM] s/"EAP Initiate Reauth message"/"EAP-Initiate/Re-auth message" >> (same all along the document) >> >> Alternatively, the NAS may send an EAP >> Initiate Reauth-Start message to the peer to trigger the start of >> ERP; the peer then responds with an EAP Initiate Reauth message to >> the NAS. >> >> [LM] s/"EAP Initiate Reauth-Start >message"/"EAP-Initiate/Re-auth-Start >> message" (same all along the document) >> >> The general guidelines for encapsulating EAP messages in Diameter >> from RFC 4072 [1] apply to the new EAP messages defined for ERP as >> well. The EAP Initiate Reauth message is encapsulated in an EAP- >> Payload AVP of a Diameter EAP-Request message by the NAS >and sent to >> the Diameter server. The NAS MUST copy the contents of the value >> field of the 'rIKName as NAI' TLV or the peer-id TLV (when >the former >> is not present) of the EAP Initiate Reauth message into a User-Name >> AVP of the Diameter EAP-Request. >> >> [LM] I think that we are talking about the 'keyName-NAI' TLV >and not anymore the 'rIKName as NAI' TLV. > > Considering section 5.3.2 of RFC 5296. I agree. > >>Moreover, in which case the peer-id TLV would not be present for ERP? > > Privacy ? > >> >> The ER server processes the EAP Initiate Reauth message in >accordance >> with [2], and if that is successful, it responds with an EAP Finish >> Reauth message indicating a success ('R' flag set to 0). The >> Diameter server MUST encapsulate the EAP Finish Reauth message with >> the R flag set to zero in an EAP-Payload AVP attribute of >a Diameter >> EAP-Answer message. An EAP-Master-Session-Key AVP included in the >> Diameter EAP-Answer contains the Re-authentication Master >Session Key >> (rMSK). The Diameter Result Code, if any, SHOULD be a >success Result >> Code. >> >> If the processing of the EAP Initiate Reauth message resulted in a >> failure, the Diameter server MUST encapsulate an EAP Finish Reauth >> message indicating failure ('R' flag set to 1) in an >EAP-Payload AVP >> of a Diameter EAP-Answer message. The Diameter Result >Code, if any, >> SHOULD be a failure Result Code. Whether an EAP Finish Reauth >> message is sent at all is specified in [2]. >> >> [LM] the use of the 'R' flag is not relevant for Diameter EAP. >> [LM] according to the RFC, the EAP-Finish/Re-auth is sent >back in any case, success or failure. >> [LM] according to the above comments, I would rephrase the >text as follow: >> >> >> "The ER server processes the EAP Initiate Reauth message >in accordance >> with [2] and responds with an EAP-Finish/Re-auth message. >The Diameter >> server MUST encapsulate the EAP-Finish/Re-auth message within an >> EAP-Payload AVP of a Diameter EAP-Answer message. >> In an EAP re-authentication successful case, an >EAP-Master-Session-Key >> AVP is included in the Diameter EAP-Answer message that >contains the >> Re-authentication Master Session Key (rMSK). The Diameter >Result-Code >> SHOULD be a success Result-Code. >> In an EAP re-authentication failure case, the Diameter >Result-Code of >> the a Diameter EAP-Answer message SHOULD be a failure >Result-Code and >> no EAP-Master-Session-Key AVP is present." >> >> [LM] By the way, I don't understand the "SHOULD" for the >result-code. Any reason not to use "MUST" here? > > I think a MUST would be better. Different views ? > >> [LM] a figure could be added for illustration here. >> >> 4.2. DSRK Request and Delivery >> >> A local ER server, collocated with a Diameter proxy in the peer's >> visited domain, >> >> [LM] s/in the peer's visited domain/in the domain visited by the peer >> >> may request a DSRK from the EAP server, either in the >> initial EAP exchange (implicit bootstrapping) or in an ERP >> bootstrapping exchange (explicit bootstrapping). It does this by >> including the EAP-DSRK-Request AVP in the Diameter EAP-Response >> message. The EAP-DSRK-Request AVP contains the domain or server >> identity required to derive the DSRK. >> >> [LM] the EAP-DSRK-Request AVP is included in the Diameter >EAP-Request >> (and not in the response) > > yes. > >> >> An EAP server MAY send the DSRK when it receives a valid Diameter >> EAP-Request message containing an EAP-DSRK-Request AVP. >An ER server >> MUST send the DSRK (or send a failure result) when it receives a >> valid Diameter EAP-Request message containing an >EAP-DSRK-Request AVP >> along with a valid EAP Initiate Re-auth packet with the >bootstrapping >> flag turned on. If an EAP-DSRK-Request AVP is included in >any other >> Diameter EAP-Request message, the Diameter server MUST reply with a >> failure result. An EAP-DSRK AVP MUST be used to send a >DSRK; an EAP- >> DSRK-Name AVP MUST be used to send the DSRK's keyname; and an EAP- >> DSRK-Lifetime AVP MUST be used to send the DSRK's lifetime. >> >> [LM] I don't understand the intention of the above text. >Could it be enough to say: >> >> In successful case, the DSRK is carried by the EAP-DSRK AVP in the >> Diameter EAP response message. Along with the EAP-DSRK AVP, an >> EAP-DSRK-Name AVP MUST be used to send the DSRK's keyname and an >> EAP-DSRK-Lifetime AVP MUST be used to send the DSRK's lifetime. > > Agree. > >> >> [LM] a figure could be added for illustration here. >> >> 5. Command Codes >> >> [LM] this section is not required as there is nothing >specific for ERP. We should skip it. >> >> [SKIP] >> >> >> 6. Attribute Value Pair Definitions >> >> 6.1. EAP-DSRK-Request AVP >> >> The EAP-DSRK AVP (AVP Code TBD) is of type DiameterIdentity. >> >> [LM] s/EAP-DSRK AVP/EAP-DSRK-Request AVP >> >> This >> AVP fulfills two purposes: First, it indicates that a ER server is >> located in the local domain that is willing to play the >role of an ER >> server for a particular session. Second, it conveys information >> about the domain and ER server identity to the Diameter/EAP server. >> >> [LM] the use of this AVP is explained above. There is no >need to explain again. > > As we are in the AVP Definitions, I think it is better to >keep some text explaining it. No ? > >> Moreover, if a DiameterIdentity is used, it is to indicate a >server and not a domain. Right? > > In my understanding the local ER server only sends the Domain >Name which will then be used to compute keys. Maybe the type >DiameterIdentity is not appropriated and we should use >UTF8String instead. What do you think ? > > >> >> 6.2. EAP-DSRK AVP >> >> The EAP-DSRK AVP (AVP Code TBD) is of type OctetString. The Domain >> Specific Root Key (DSRK) is carried in this payload. >> >> 6.3. EAP-DSRK-Name AVP >> >> The EAP-DSRK-Name AVP (AVP Code TBD) is of type OctetString. This >> AVP contains the name of the DSRK key that is later used during the >> re-authentication exchange to select the correct DSRK. >> >> [LM] skip the part starting by "that is..." > > ok > >> >> 6.4. EAP-DSRK-Lifetime AVP >> >> The EAP-DSRK-Lifetime AVP (AVP Code TBD) is of type Unsigned64 and >> contains the DSRK lifetime in seconds. >> >> >> 7. AVP Occurrence Table >> >> The following table lists the AVPs that may optionally be >present in >> the DER and DEA commands [1]. >> >> >> +---------------+ >> | Command-Code | >> +-+-----+-----+-+ >> Attribute Name | DER | DEA | >> -------------------------------|-----+-----+ >> EAP-DSRK-Request | 0-1 | 0 | >> EAP-DSRK | 0 | 0-1 | >> EAP-DSRK-Name | 0 | 0-1 | >> EAP-DSRK-Lifetime | 0 | 0-1 | >> +-----+-----+ >> >> Figure 4: DER and DEA Commands AVP Table >> >> When the EAP-DSRK AVP is present in the DEA then the EAP-DSRK-Name >> and the EAP-DSRK-Lifetime MUST also be present. >> >> >> 8. AVP Flag Rules >> >> The following table describes the Diameter AVPs, their AVP Code >> values, types, possible flag values, and whether the AVP MAY be >> encrypted. The Diameter base [4] specifies the AVP Flag rules for >> AVPs in Section 4.5. >> >> >> +---------------------+ >> | AVP Flag Rules | >> >+----+-----+----+-----+----+ >> AVP Section | | >|SHLD|MUST | | >> Attribute Name Code Defined Data Type |MUST| MAY |NOT >|NOT |Encr| >> >------------------------------------------+----+-----+----+-----+----+ >> EAP-DSRK-Request TBD 4.7.1 DiamIdent | | P | | >V,M | Y | >> EAP-DSRK TBD 4.7.2 OctetString| | P | | >V,M | Y | >> EAP-DSRK-Name TBD 4.7.3 OctetString| | P | | >V,M | Y | >> EAP-DSRK-Lifetime TBD 4.7.4 Unsigned64 | | P | | >V,M | Y | >> >> >------------------------------------------+----+-----+----+-----+----+ >> >> Due to space constraints, the short form DiamIdent is used to >> represent DiameterIdentity. >> >> Figure 5: AVP Flag Rules Table >> >> [LM] this table is ok according to the current RFC 3588. I >don't know how to deal with it regarding the RFC3588bis... > > > That's indeed a good question :). > > And that's all for my comments of your comments. > > Regards, > > --Julien-- >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 8 12:28:28 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A154C3A6962; Thu, 8 Jan 2009 12:28:28 -0800 (PST) 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 74C953A6937 for ; Thu, 8 Jan 2009 12:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.529 X-Spam-Level: X-Spam-Status: No, score=-4.529 tagged_above=-999 required=5 tests=[AWL=-1.280, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-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 6VRnqPZAfC5i for ; Thu, 8 Jan 2009 12:28:25 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 4BF433A6822 for ; Thu, 8 Jan 2009 12:28:24 -0800 (PST) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Jan 2009 21:28:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 8 Jan 2009 21:26:09 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB0260622C4DE@ftrdmel2> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Review of the Diameter ERP draft Thread-Index: AclxenKpDp1tiH+tR5acfa7D++IC0QAFZFSQAA+E7ZA= References: <7DBAFEC6A76F3E42817DF1EBE64CB026061E2759@ftrdmel2> <5e2406980901080218w746b69a7x320f1501aeb97266@mail.gmail.com> From: To: , , , X-OriginalArrivalTime: 08 Jan 2009 20:28:01.0812 (UTC) FILETIME=[9A53C540:01C971CF] Subject: Re: [Dime] Review of the Diameter ERP 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org According to the RFC 5296, it seems that it is not required to have a speci= fic Appl-ID: "It is plausible that the authenticator does not know whether the peer supports ERP and whether the peer has performed a full EAP authentication through another authenticator. The authenticator MAY initiate the ERP exchange by sending the EAP-Initiate/Re-auth-Start message, and if there is no response, it will send the EAP-Request/ Identity message. Note that this avoids having two EAP messages in flight at the same time [2]. The authenticator may send the EAP- Initiate/Re-auth-Start message and wait for a short, locally configured amount of time. If the peer does not already know, this message indicates to the peer that the authenticator supports ERP. In response to this trigger from the authenticator, the peer can initiate the ERP exchange by sending an EAP-Initiate/Re-auth message. If there is no response from the peer after the necessary retransmissions (see Section 6), the authenticator MUST initiate EAP by sending an EAP-Request message, typically the EAP-Request/Identity message. Note that the authenticator may receive an EAP-Initiate/ Re-auth message after it has sent an EAP-Request/Identity message. If the authenticator supports ERP, it MUST proceed with the ERP exchange. When the EAP-Request/Identity times out, the authenticator MUST NOT close the connection if an ERP exchange is in progress or has already succeeded in establishing a re-authentication MSK. If the authenticator does not support ERP, it drops EAP-Initiate/ Re-auth messages [2] as the EAP code of those packets is greater than 4. An ERP-capable peer will exhaust the EAP-Initiate/Re-auth message retransmissions and fall back to EAP authentication by responding to EAP Request/Identity messages from the authenticator. If the peer does not support ERP or if it does not have unexpired key material from a previous EAP authentication, it drops EAP-Initiate/ Re-auth-Start messages. If there is no response to the EAP-Initiate/ Re-auth-Start message, the authenticator SHALL send an EAP Request message (typically EAP Request/Identity) to start EAP authentication. From this stage onwards, RFC 3748 rules apply. Note that this may introduce some delay in starting EAP. In some lower layers, the delay can be minimized or even avoided by the peer initiating EAP by sending messages such as EAPoL-Start in the IEEE 802.1X specification [10]." Both paragraphs assume (for me) that the ERP "option" may be supported by t= he peer and/or the network. If none of them (or only one of them) support E= RP, the fallback mechanism is full EAP authentication. In that sense, knowing that the network supports ERP is not a pre-requisite= . The minimum is to support EAP and ERP is an option available above EAP. T= hat allows to deploy ERP above existing EAP deployment. Does it make sense? Best Regards, Lionel > -----Message d'origine----- > De : Tschofenig, Hannes (NSN - FI/Espoo) = > [mailto:hannes.tschofenig@nsn.com] = > Envoy=E9 : jeudi 8 janvier 2009 13:55 > =C0 : ext Julien Bournelle; MORAND Lionel RD-CORE-ISS; = > Sebastien Decugis; dime@ietf.org > Objet : RE: [Dime] Review of the Diameter ERP draft > = > One of the things I was not quite sure with the current = > protocol design is whether a Diameter application or just a = > bunch of AVPs are required. > Based on the discussions a few of us when some of the HOKEY = > specs went to the IESG / IETF Last Call I got the impression = > that one has to define a new Diameter application (which = > would be based on Diameter EAP) since you assume that the = > messages are routed via a node in the local network and the = > support for ERP has to be ensured. = > = > Ciao > Hannes > = > >-----Original Message----- > >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] = > On Behalf Of = > >ext Julien Bournelle > >Sent: 08 January, 2009 12:18 > >To: lionel.morand@orange-ftgroup.com; Sebastien Decugis; = > dime@ietf.org > >Subject: Re: [Dime] Review of the Diameter ERP draft > > > >Hi lionel, > > > > some comments inline. > > > >On Wed, Jan 7, 2009 at 12:03 PM, > > wrote: > >> > >> Hi, > >> > >> Here is my review for the Diameter ERP draft. > >> > >> General comments: > >> > >> - About alignment with RFC 5296: > >> the draft needs to be updated according to the publication > >of the RFC 5296. Some proposals are provided below. > >> > >> - About ER server/AAA agent co-location: > >> In my understanding, it is assumed in this document ER > >server and AAA proxy have to be co-located to be able to rely on = > >Diameter to transport ERP specific AVPs. This doesn't maybe preclude = > >other architectural choices but there are outside the scope of this = > >document. It is necessary to clarify this point in this document. > >> > >> - ERP support discovery: > >> As the ERP specific AVPs are introduced with the M-bit > >cleared, these AVPs are purely optional for the Diameter EAP = > >application i.e. they can be silently ignored by Diameter = > servers that = > >do not understand this new AVPs. Some text should be provided to = > >describe how the local ER server discovers that the Home EAP server = > >doesn't support ERP and the behaviour of the local ER server in that = > >case. > > > > > > I agree with these general comments. > > > > > >> > >> Hereafter is the rest of my review with comments and proposals. > >> > >> Best Regards, > >> > >> Lionel > >> > >> *************************************** > >> > >> Abstract > >> > >> An EAP extension, called "EAP Re-authentication Protocol > >(ERP)", has > >> been specified that supports an EAP method-independent = > protocol for > >> efficient re-authentication between the peer and the = > server through > >> an authenticator. This document specifies Diameter > >support for ERP. > >> The Diameter EAP application is re-used for = > encapsulating the newly > >> defined EAP Initiate and EAP Finish messages specified in the ERP > >> specification. AVPs for request and delivery of Domain > >Specific Root > >> Keys from the AAA/EAP server to the ER server are also specified. > >> Additionally, this document also specifies Diameter > >processing rules > >> relevant to ERP. > >> > >> [LM] some abusive verbiage in the abstract: > >> > >> Proposal for new abstract: > >> > >> "EAP Re-authentication Protocol defines extensions of EAP > >to support > >> efficient re-authentication between the peer and an EAP > >> re-authentication server through any authenticator. > > > > I'm wondering if we should note that the authenticator may be = > >ERP-aware. > >I'm thinking about the case where the authenticator sends the = > >EAP-Initiate/Re-auth-Start (Figure 4 in RFC 5296) > > > > > >> This document > >> specifies Diameter support for ERP. The Diameter EAP = > application is > >> re-used for encapsulating the newly defined EAP messages = > specified > >> in the ERP specification. Additionally, this document = > also defines > >> specific Diameter processing rules relevant to ERP." > > > > ok > > > >> > >> > >> 1. Introduction > >> > >> RFC 4072 [1] specifies a Diameter application that carries EAP > >> packets between a Diameter client and the Diameter > >Server/EAP server. > >> [2] defines the EAP Re-authentication Protocol to allow = > faster re- > >> authentication of a previously authenticated peer. > >> > >> [LM] s/[2] defines the EAP Re-authentication Protocol/RFC 5296 [2] = > >> defines the EAP Re-authentication Protocol (ERP) > >> > >> In ERP, a peer > >> authenticates to the network by proving possession of = > key material > >> derived during a previous EAP exchange. > >> > >> [LM] s/a peer authenticate to/a peer is authenticated by > >> > >> For this purpose, an > >> Extended Master Session Key (EMSK) based re-authentication key > >> hierarchy has been defined [5]. ERP may be executed = > between the ER > >> peer and an ER server in the peer's home domain or the = > local domain > >> visited by the peer. In the latter case, a Domain = > Specific Root Key > >> (DSRK), derived from the EMSK, is provided to the local domain ER > >> server. > >> > >> [LM] s/is provided to/is provided by the Home ER server to > >> > >> The peer and the local server subsequently use the re- > >> authentication key hierarchy from the DSRK to authenticate > >and derive > >> authenticator specific keys within that domain. > >> > >> [LM] this information can be found in the RFC 5296. Remove > >the sentence above. > > > > It may help the reader to understand the purpose of this DRSK. > > > >> > >> To accomplish the > >> reauthentication functionality, ERP defines two new EAP = > codes - EAP > >> Initiate and EAP Finish. > >> > >> [LM] s/ERP defines two new EAP codes/ERP defines two new = > EAP messages > > > > I would prefer to say that ERP defines two new EAP Codes = > here. These = > >newly EAP packets are then carried in messages (dependent of the = > >protocol used). > > > >> > >> This document specifies the reuse of > >> Diameter EAP application to carry these new EAP messages. > >> The DSRK can be obtained as part of the regular EAP = > exchange or as > >> part of an ERP bootstrapping exchange. The local ER server > >> requesting the DSRK needs to be in the path of the EAP or ERP > >> bootstrapping exchange in order to request and obtain the > >DSRK. This > >> document also specifies how the DSRK is transported to = > the local ER > >> server using Diameter. > >> > >> [LM] Finally, i would reorganize the last part as follow: > >> > >> ::::::::::: > >> > >> "In ERP, a peer is authenticated by the network thanks to > >keying material > >> obtained during a previous EAP exchange. This keying > >material is derived > >> from the Extended Master Session Key (EMSK) defined in the > >RFC 5295 [5]. > >> To accomplish the EAP reauthentication functionality, ERP > >defines two new > >> EAP messages - EAP Initiate and EAP Finish. This document > >specifies the > >> reuse of Diameter EAP Application to carry these new EAP = > messages. > >> > >> ERP is executed between the peer and a server located > >either in the peer's > >> home domain or in the local domain visited by the peer. In > >the latter case, > >> a Domain Specific Root Key (DSRK) is derived from the > >EMSK, as defined in > >> the RFC 5295 [5], and is provided by the Home EAP server > >to the local domain > >> server. For that purpose, this document specifies the > >transport of the DSRK > >> using the Diameter EAP Application." > > > > First paragraph is the old and second the new ? > > > >> > >> :::::::::::::: > >> > >> > >> > >> 2. Terminology > >> > >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", = > "SHALL NOT", > >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > >"OPTIONAL" in this > >> document are to be interpreted as described in RFC 2119 [3]. > >> > >> This document uses terminology defined in [6], [5], [2], and [1]. > >> > >> > >> 3. Assumptions > >> > >> This document defines additional optional AVPs for usage with the > >> Diameter EAP application. Routing of these messages is therefore > >> provided via the Diameter Application Identifier (among other > >> elements), as specified by the Diameter Base protocol [4]. > >> > >> [LM] To avoid any ambiguity I would say: > >> > >> "This document defines only additional optional AVPs for = > usage with > >> the Diameter EAP application. This document does not defined > >> a new Diameter application and a new Application ID is > >therefore not > >> required, as described in the Diameter Base protocol [4]." > > > > ok > > > >> > >> Based on > >> the deployment of ERP, a local Diameter server (the same entity > >> serves as a Diameter proxy during the full EAP = > authentication) may > >> play the role of the ER server for future > >re-authentication attempts. > >> As such, the local Diameter server requesting the DSRK > >needs to be in > >> the path of the current EAP exchange between the peer and the EAP > >> server and also along in the future. The Diameter client is > >> furthermore assumed to be able to route the re-authentication > >> messages to the ER server. > >> > >> [LM] I think that the assumption all along this document is > >that the local ER server and the AAA agent are co-located, = > to be able = > >to rely on DEA for the transport of DSRK. In that case, I would say = > >something like: > >> > >> "In this document, when EAP re-authentication is performed > >in the domain > >> visited by the peer, it is assumed that the local ER > >server is co-located > >> with a Diameter agent in the visited domain present in > >the path of the full > >> EAP exchange." > > > > ok > > > >> > >> > >> 4. Diameter Support for ERP > >> > >> 4.1. Protocol Overview > >> > >> Diameter may be used to transport ERP messages between the NAS > >> (authenticator) and an authentication server (ER server). > >> > >> [LM] s/may/is (the use of Diameter is a pre-requisite in = > this draft) > >> > >> In ERP, the peer sends an EAP Initiate Reauth message to the ER > >> server via the authenticator. > >> > >> [LM] s/"EAP Initiate Reauth message"/"EAP-Initiate/Re-auth = > message" = > >> (same all along the document) > >> > >> Alternatively, the NAS may send an EAP > >> Initiate Reauth-Start message to the peer to trigger the start of > >> ERP; the peer then responds with an EAP Initiate Reauth = > message to > >> the NAS. > >> > >> [LM] s/"EAP Initiate Reauth-Start > >message"/"EAP-Initiate/Re-auth-Start > >> message" (same all along the document) > >> > >> The general guidelines for encapsulating EAP messages in Diameter > >> from RFC 4072 [1] apply to the new EAP messages defined = > for ERP as > >> well. The EAP Initiate Reauth message is encapsulated in an EAP- > >> Payload AVP of a Diameter EAP-Request message by the NAS > >and sent to > >> the Diameter server. The NAS MUST copy the contents of the value > >> field of the 'rIKName as NAI' TLV or the peer-id TLV (when > >the former > >> is not present) of the EAP Initiate Reauth message into = > a User-Name > >> AVP of the Diameter EAP-Request. > >> > >> [LM] I think that we are talking about the 'keyName-NAI' TLV > >and not anymore the 'rIKName as NAI' TLV. > > > > Considering section 5.3.2 of RFC 5296. I agree. > > > >>Moreover, in which case the peer-id TLV would not be = > present for ERP? > > > > Privacy ? > > > >> > >> The ER server processes the EAP Initiate Reauth message in > >accordance > >> with [2], and if that is successful, it responds with an = > EAP Finish > >> Reauth message indicating a success ('R' flag set to 0). The > >> Diameter server MUST encapsulate the EAP Finish Reauth = > message with > >> the R flag set to zero in an EAP-Payload AVP attribute of > >a Diameter > >> EAP-Answer message. An EAP-Master-Session-Key AVP = > included in the > >> Diameter EAP-Answer contains the Re-authentication Master > >Session Key > >> (rMSK). The Diameter Result Code, if any, SHOULD be a > >success Result > >> Code. > >> > >> If the processing of the EAP Initiate Reauth message = > resulted in a > >> failure, the Diameter server MUST encapsulate an EAP = > Finish Reauth > >> message indicating failure ('R' flag set to 1) in an > >EAP-Payload AVP > >> of a Diameter EAP-Answer message. The Diameter Result > >Code, if any, > >> SHOULD be a failure Result Code. Whether an EAP Finish Reauth > >> message is sent at all is specified in [2]. > >> > >> [LM] the use of the 'R' flag is not relevant for Diameter EAP. > >> [LM] according to the RFC, the EAP-Finish/Re-auth is sent > >back in any case, success or failure. > >> [LM] according to the above comments, I would rephrase the > >text as follow: > >> > >> > >> "The ER server processes the EAP Initiate Reauth message > >in accordance > >> with [2] and responds with an EAP-Finish/Re-auth message. = > >The Diameter > >> server MUST encapsulate the EAP-Finish/Re-auth message within an > >> EAP-Payload AVP of a Diameter EAP-Answer message. > >> In an EAP re-authentication successful case, an > >EAP-Master-Session-Key > >> AVP is included in the Diameter EAP-Answer message that > >contains the > >> Re-authentication Master Session Key (rMSK). The Diameter > >Result-Code > >> SHOULD be a success Result-Code. > >> In an EAP re-authentication failure case, the Diameter > >Result-Code of > >> the a Diameter EAP-Answer message SHOULD be a failure > >Result-Code and > >> no EAP-Master-Session-Key AVP is present." > >> > >> [LM] By the way, I don't understand the "SHOULD" for the > >result-code. Any reason not to use "MUST" here? > > > > I think a MUST would be better. Different views ? > > > >> [LM] a figure could be added for illustration here. > >> > >> 4.2. DSRK Request and Delivery > >> > >> A local ER server, collocated with a Diameter proxy in the peer's > >> visited domain, > >> > >> [LM] s/in the peer's visited domain/in the domain visited = > by the peer > >> > >> may request a DSRK from the EAP server, either in the > >> initial EAP exchange (implicit bootstrapping) or in an ERP > >> bootstrapping exchange (explicit bootstrapping). It does this by > >> including the EAP-DSRK-Request AVP in the Diameter EAP-Response > >> message. The EAP-DSRK-Request AVP contains the domain or server > >> identity required to derive the DSRK. > >> > >> [LM] the EAP-DSRK-Request AVP is included in the Diameter > >EAP-Request > >> (and not in the response) > > > > yes. > > > >> > >> An EAP server MAY send the DSRK when it receives a valid Diameter > >> EAP-Request message containing an EAP-DSRK-Request AVP. = > >An ER server > >> MUST send the DSRK (or send a failure result) when it receives a > >> valid Diameter EAP-Request message containing an > >EAP-DSRK-Request AVP > >> along with a valid EAP Initiate Re-auth packet with the > >bootstrapping > >> flag turned on. If an EAP-DSRK-Request AVP is included in > >any other > >> Diameter EAP-Request message, the Diameter server MUST = > reply with a > >> failure result. An EAP-DSRK AVP MUST be used to send a > >DSRK; an EAP- > >> DSRK-Name AVP MUST be used to send the DSRK's keyname; = > and an EAP- > >> DSRK-Lifetime AVP MUST be used to send the DSRK's lifetime. > >> > >> [LM] I don't understand the intention of the above text. = > >Could it be enough to say: > >> > >> In successful case, the DSRK is carried by the EAP-DSRK = > AVP in the > >> Diameter EAP response message. Along with the EAP-DSRK AVP, an > >> EAP-DSRK-Name AVP MUST be used to send the DSRK's keyname and an > >> EAP-DSRK-Lifetime AVP MUST be used to send the DSRK's lifetime. > > > > Agree. > > > >> > >> [LM] a figure could be added for illustration here. > >> > >> 5. Command Codes > >> > >> [LM] this section is not required as there is nothing > >specific for ERP. We should skip it. > >> > >> [SKIP] > >> > >> > >> 6. Attribute Value Pair Definitions > >> > >> 6.1. EAP-DSRK-Request AVP > >> > >> The EAP-DSRK AVP (AVP Code TBD) is of type DiameterIdentity. > >> > >> [LM] s/EAP-DSRK AVP/EAP-DSRK-Request AVP > >> > >> This > >> AVP fulfills two purposes: First, it indicates that a ER = > server is > >> located in the local domain that is willing to play the > >role of an ER > >> server for a particular session. Second, it conveys information > >> about the domain and ER server identity to the = > Diameter/EAP server. > >> > >> [LM] the use of this AVP is explained above. There is no > >need to explain again. > > > > As we are in the AVP Definitions, I think it is better to keep some = > >text explaining it. No ? > > > >> Moreover, if a DiameterIdentity is used, it is to indicate a > >server and not a domain. Right? > > > > In my understanding the local ER server only sends the Domain Name = > >which will then be used to compute keys. Maybe the type = > >DiameterIdentity is not appropriated and we should use UTF8String = > >instead. What do you think ? > > > > > >> > >> 6.2. EAP-DSRK AVP > >> > >> The EAP-DSRK AVP (AVP Code TBD) is of type OctetString. = > The Domain > >> Specific Root Key (DSRK) is carried in this payload. > >> > >> 6.3. EAP-DSRK-Name AVP > >> > >> The EAP-DSRK-Name AVP (AVP Code TBD) is of type = > OctetString. This > >> AVP contains the name of the DSRK key that is later used = > during the > >> re-authentication exchange to select the correct DSRK. > >> > >> [LM] skip the part starting by "that is..." > > > > ok > > > >> > >> 6.4. EAP-DSRK-Lifetime AVP > >> > >> The EAP-DSRK-Lifetime AVP (AVP Code TBD) is of type = > Unsigned64 and > >> contains the DSRK lifetime in seconds. > >> > >> > >> 7. AVP Occurrence Table > >> > >> The following table lists the AVPs that may optionally be > >present in > >> the DER and DEA commands [1]. > >> > >> > >> +---------------+ > >> | Command-Code | > >> +-+-----+-----+-+ > >> Attribute Name | DER | DEA | > >> -------------------------------|-----+-----+ > >> EAP-DSRK-Request | 0-1 | 0 | > >> EAP-DSRK | 0 | 0-1 | > >> EAP-DSRK-Name | 0 | 0-1 | > >> EAP-DSRK-Lifetime | 0 | 0-1 | > >> +-----+-----+ > >> > >> Figure 4: DER and DEA Commands AVP Table > >> > >> When the EAP-DSRK AVP is present in the DEA then the = > EAP-DSRK-Name > >> and the EAP-DSRK-Lifetime MUST also be present. > >> > >> > >> 8. AVP Flag Rules > >> > >> The following table describes the Diameter AVPs, their AVP Code > >> values, types, possible flag values, and whether the AVP MAY be > >> encrypted. The Diameter base [4] specifies the AVP Flag = > rules for > >> AVPs in Section 4.5. > >> > >> > >> +---------------------+ > >> | AVP Flag Rules | > >> = > >+----+-----+----+-----+----+ > >> AVP Section | | = > >|SHLD|MUST | | > >> Attribute Name Code Defined Data Type |MUST| MAY |NOT = > >|NOT |Encr| > >> = > >------------------------------------------+----+-----+----+-- > ---+----+ > >> EAP-DSRK-Request TBD 4.7.1 DiamIdent | | P | | = > >V,M | Y | > >> EAP-DSRK TBD 4.7.2 OctetString| | P | | = > >V,M | Y | > >> EAP-DSRK-Name TBD 4.7.3 OctetString| | P | | = > >V,M | Y | > >> EAP-DSRK-Lifetime TBD 4.7.4 Unsigned64 | | P | | = > >V,M | Y | > >> = > >> = > >------------------------------------------+----+-----+----+-- > ---+----+ > >> > >> Due to space constraints, the short form DiamIdent is used to = > >> represent DiameterIdentity. > >> > >> Figure 5: AVP Flag Rules Table > >> > >> [LM] this table is ok according to the current RFC 3588. I > >don't know how to deal with it regarding the RFC3588bis... > > > > > > That's indeed a good question :). > > > > And that's all for my comments of your comments. > > > > Regards, > > > > --Julien-- > >_______________________________________________ > >DiME mailing list > >DiME@ietf.org > >https://www.ietf.org/mailman/listinfo/dime > > > = _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 8 23:58:20 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7A753A67A1; Thu, 8 Jan 2009 23:58:20 -0800 (PST) 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 01CB33A67A1 for ; Thu, 8 Jan 2009 23:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.56 X-Spam-Level: X-Spam-Status: No, score=-3.56 tagged_above=-999 required=5 tests=[AWL=-0.961, 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 zxR0pijBIh8U for ; Thu, 8 Jan 2009 23:58:17 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id E50FA3A65A5 for ; Thu, 8 Jan 2009 23:58:16 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n097vPUY032204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 9 Jan 2009 08:57:25 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n097vOYN030938; Fri, 9 Jan 2009 08:57:25 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Jan 2009 08:57:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 Jan 2009 09:57:53 +0200 Message-ID: In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB0260622C4DE@ftrdmel2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Review of the Diameter ERP draft Thread-Index: AclxenKpDp1tiH+tR5acfa7D++IC0QAFZFSQAA+E7ZAAGGn/YA== References: <7DBAFEC6A76F3E42817DF1EBE64CB026061E2759@ftrdmel2> <5e2406980901080218w746b69a7x320f1501aeb97266@mail.gmail.com> <7DBAFEC6A76F3E42817DF1EBE64CB0260622C4DE@ftrdmel2> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: , , , X-OriginalArrivalTime: 09 Jan 2009 07:57:24.0751 (UTC) FILETIME=[E88F61F0:01C9722F] Subject: Re: [Dime] Review of the Diameter ERP 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org My reading of this text is that there is a way for the peer and the authent= icator to figure out whether to use EAP or ERP. = It, however, says very little about the further routing of AAA messages in = such a way that the messages traverse nodes understanding the additionally = required functionality. If I understood ERP correctly then some key caching= takes place in the AAA proxies and hence one wants to make sure that the m= essages are actually routed via these proxies. Ciao Hannes = >-----Original Message----- >From: ext lionel.morand@orange-ftgroup.com = >[mailto:lionel.morand@orange-ftgroup.com] = >Sent: 08 January, 2009 22:26 >To: Tschofenig, Hannes (NSN - FI/Espoo); = >julien.bournelle@gmail.com; sdecugis@hongo.wide.ad.jp; dime@ietf.org >Subject: RE: [Dime] Review of the Diameter ERP draft > >According to the RFC 5296, it seems that it is not required to = >have a specific Appl-ID: > > "It is plausible that the authenticator does not know = >whether the peer > supports ERP and whether the peer has performed a full EAP > authentication through another authenticator. The authenticator MAY > initiate the ERP exchange by sending the EAP-Initiate/Re-auth-Start > message, and if there is no response, it will send the EAP-Request/ > Identity message. Note that this avoids having two EAP messages in > flight at the same time [2]. The authenticator may send the EAP- > Initiate/Re-auth-Start message and wait for a short, locally > configured amount of time. If the peer does not already know, this > message indicates to the peer that the authenticator supports ERP. > In response to this trigger from the authenticator, the peer can > initiate the ERP exchange by sending an = >EAP-Initiate/Re-auth message. > If there is no response from the peer after the necessary > retransmissions (see Section 6), the authenticator MUST initiate EAP > by sending an EAP-Request message, typically the = >EAP-Request/Identity > message. Note that the authenticator may receive an EAP-Initiate/ > Re-auth message after it has sent an EAP-Request/Identity message. > If the authenticator supports ERP, it MUST proceed with the ERP > exchange. When the EAP-Request/Identity times out, the = >authenticator > MUST NOT close the connection if an ERP exchange is in progress or > has already succeeded in establishing a re-authentication MSK. > > If the authenticator does not support ERP, it drops EAP-Initiate/ > Re-auth messages [2] as the EAP code of those packets is = >greater than > 4. An ERP-capable peer will exhaust the = >EAP-Initiate/Re-auth message > retransmissions and fall back to EAP authentication by responding to > EAP Request/Identity messages from the authenticator. If the peer > does not support ERP or if it does not have unexpired key material > from a previous EAP authentication, it drops EAP-Initiate/ > Re-auth-Start messages. If there is no response to the = >EAP-Initiate/ > Re-auth-Start message, the authenticator SHALL send an EAP Request > message (typically EAP Request/Identity) to start EAP = >authentication. > From this stage onwards, RFC 3748 rules apply. Note that this may > introduce some delay in starting EAP. In some lower layers, the > delay can be minimized or even avoided by the peer initiating EAP by > sending messages such as EAPoL-Start in the IEEE 802.1X = >specification > [10]." > >Both paragraphs assume (for me) that the ERP "option" may be = >supported by the peer and/or the network. If none of them (or = >only one of them) support ERP, the fallback mechanism is full = >EAP authentication. >In that sense, knowing that the network supports ERP is not a = >pre-requisite. The minimum is to support EAP and ERP is an = >option available above EAP. That allows to deploy ERP above = >existing EAP deployment. > >Does it make sense? > >Best Regards, > >Lionel > > >> -----Message d'origine----- >> De : Tschofenig, Hannes (NSN - FI/Espoo) = >> [mailto:hannes.tschofenig@nsn.com] >> Envoy=E9 : jeudi 8 janvier 2009 13:55 >> =C0 : ext Julien Bournelle; MORAND Lionel RD-CORE-ISS; Sebastien = >> Decugis; dime@ietf.org Objet : RE: [Dime] Review of the Diameter ERP = >> draft >> = >> One of the things I was not quite sure with the current protocol = >> design is whether a Diameter application or just a bunch of AVPs are = >> required. >> Based on the discussions a few of us when some of the HOKEY = >specs went = >> to the IESG / IETF Last Call I got the impression that one has to = >> define a new Diameter application (which would be based on Diameter = >> EAP) since you assume that the messages are routed via a node in the = >> local network and the support for ERP has to be ensured. >> = >> Ciao >> Hannes >> = >> >-----Original Message----- >> >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] >> On Behalf Of >> >ext Julien Bournelle >> >Sent: 08 January, 2009 12:18 >> >To: lionel.morand@orange-ftgroup.com; Sebastien Decugis; >> dime@ietf.org >> >Subject: Re: [Dime] Review of the Diameter ERP draft >> > >> >Hi lionel, >> > >> > some comments inline. >> > >> >On Wed, Jan 7, 2009 at 12:03 PM, >> > wrote: >> >> >> >> Hi, >> >> >> >> Here is my review for the Diameter ERP draft. >> >> >> >> General comments: >> >> >> >> - About alignment with RFC 5296: >> >> the draft needs to be updated according to the publication >> >of the RFC 5296. Some proposals are provided below. >> >> >> >> - About ER server/AAA agent co-location: >> >> In my understanding, it is assumed in this document ER >> >server and AAA proxy have to be co-located to be able to rely on = >> >Diameter to transport ERP specific AVPs. This doesn't maybe = >preclude = >> >other architectural choices but there are outside the scope of this = >> >document. It is necessary to clarify this point in this document. >> >> >> >> - ERP support discovery: >> >> As the ERP specific AVPs are introduced with the M-bit >> >cleared, these AVPs are purely optional for the Diameter EAP = >> >application i.e. they can be silently ignored by Diameter >> servers that >> >do not understand this new AVPs. Some text should be provided to = >> >describe how the local ER server discovers that the Home EAP server = >> >doesn't support ERP and the behaviour of the local ER = >server in that = >> >case. >> > >> > >> > I agree with these general comments. >> > >> > >> >> >> >> Hereafter is the rest of my review with comments and proposals. >> >> >> >> Best Regards, >> >> >> >> Lionel >> >> >> >> *************************************** >> >> >> >> Abstract >> >> >> >> An EAP extension, called "EAP Re-authentication Protocol >> >(ERP)", has >> >> been specified that supports an EAP method-independent >> protocol for >> >> efficient re-authentication between the peer and the >> server through >> >> an authenticator. This document specifies Diameter >> >support for ERP. >> >> The Diameter EAP application is re-used for >> encapsulating the newly >> >> defined EAP Initiate and EAP Finish messages specified = >in the ERP >> >> specification. AVPs for request and delivery of Domain >> >Specific Root >> >> Keys from the AAA/EAP server to the ER server are also = >specified. >> >> Additionally, this document also specifies Diameter >> >processing rules >> >> relevant to ERP. >> >> >> >> [LM] some abusive verbiage in the abstract: >> >> >> >> Proposal for new abstract: >> >> >> >> "EAP Re-authentication Protocol defines extensions of EAP >> >to support >> >> efficient re-authentication between the peer and an EAP >> >> re-authentication server through any authenticator. >> > >> > I'm wondering if we should note that the authenticator may be = >> >ERP-aware. >> >I'm thinking about the case where the authenticator sends the = >> >EAP-Initiate/Re-auth-Start (Figure 4 in RFC 5296) >> > >> > >> >> This document >> >> specifies Diameter support for ERP. The Diameter EAP >> application is >> >> re-used for encapsulating the newly defined EAP messages >> specified >> >> in the ERP specification. Additionally, this document >> also defines >> >> specific Diameter processing rules relevant to ERP." >> > >> > ok >> > >> >> >> >> >> >> 1. Introduction >> >> >> >> RFC 4072 [1] specifies a Diameter application that carries EAP >> >> packets between a Diameter client and the Diameter >> >Server/EAP server. >> >> [2] defines the EAP Re-authentication Protocol to allow >> faster re- >> >> authentication of a previously authenticated peer. >> >> >> >> [LM] s/[2] defines the EAP Re-authentication Protocol/RFC = >5296 [2] = >> >> defines the EAP Re-authentication Protocol (ERP) >> >> >> >> In ERP, a peer >> >> authenticates to the network by proving possession of >> key material >> >> derived during a previous EAP exchange. >> >> >> >> [LM] s/a peer authenticate to/a peer is authenticated by >> >> >> >> For this purpose, an >> >> Extended Master Session Key (EMSK) based re-authentication key >> >> hierarchy has been defined [5]. ERP may be executed >> between the ER >> >> peer and an ER server in the peer's home domain or the >> local domain >> >> visited by the peer. In the latter case, a Domain >> Specific Root Key >> >> (DSRK), derived from the EMSK, is provided to the local = >domain ER >> >> server. >> >> >> >> [LM] s/is provided to/is provided by the Home ER server to >> >> >> >> The peer and the local server subsequently use the re- >> >> authentication key hierarchy from the DSRK to authenticate >> >and derive >> >> authenticator specific keys within that domain. >> >> >> >> [LM] this information can be found in the RFC 5296. Remove >> >the sentence above. >> > >> > It may help the reader to understand the purpose of this DRSK. >> > >> >> >> >> To accomplish the >> >> reauthentication functionality, ERP defines two new EAP >> codes - EAP >> >> Initiate and EAP Finish. >> >> >> >> [LM] s/ERP defines two new EAP codes/ERP defines two new >> EAP messages >> > >> > I would prefer to say that ERP defines two new EAP Codes >> here. These >> >newly EAP packets are then carried in messages (dependent of the = >> >protocol used). >> > >> >> >> >> This document specifies the reuse of >> >> Diameter EAP application to carry these new EAP messages. >> >> The DSRK can be obtained as part of the regular EAP >> exchange or as >> >> part of an ERP bootstrapping exchange. The local ER server >> >> requesting the DSRK needs to be in the path of the EAP or ERP >> >> bootstrapping exchange in order to request and obtain the >> >DSRK. This >> >> document also specifies how the DSRK is transported to >> the local ER >> >> server using Diameter. >> >> >> >> [LM] Finally, i would reorganize the last part as follow: >> >> >> >> ::::::::::: >> >> >> >> "In ERP, a peer is authenticated by the network thanks to >> >keying material >> >> obtained during a previous EAP exchange. This keying >> >material is derived >> >> from the Extended Master Session Key (EMSK) defined in the >> >RFC 5295 [5]. >> >> To accomplish the EAP reauthentication functionality, ERP >> >defines two new >> >> EAP messages - EAP Initiate and EAP Finish. This document >> >specifies the >> >> reuse of Diameter EAP Application to carry these new EAP >> messages. >> >> >> >> ERP is executed between the peer and a server located >> >either in the peer's >> >> home domain or in the local domain visited by the peer. In >> >the latter case, >> >> a Domain Specific Root Key (DSRK) is derived from the >> >EMSK, as defined in >> >> the RFC 5295 [5], and is provided by the Home EAP server >> >to the local domain >> >> server. For that purpose, this document specifies the >> >transport of the DSRK >> >> using the Diameter EAP Application." >> > >> > First paragraph is the old and second the new ? >> > >> >> >> >> :::::::::::::: >> >> >> >> >> >> >> >> 2. Terminology >> >> >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", >> "SHALL NOT", >> >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and >> >"OPTIONAL" in this >> >> document are to be interpreted as described in RFC 2119 [3]. >> >> >> >> This document uses terminology defined in [6], [5], = >[2], and [1]. >> >> >> >> >> >> 3. Assumptions >> >> >> >> This document defines additional optional AVPs for = >usage with the >> >> Diameter EAP application. Routing of these messages is = >therefore >> >> provided via the Diameter Application Identifier (among other >> >> elements), as specified by the Diameter Base protocol [4]. >> >> >> >> [LM] To avoid any ambiguity I would say: >> >> >> >> "This document defines only additional optional AVPs for >> usage with >> >> the Diameter EAP application. This document does not defined >> >> a new Diameter application and a new Application ID is >> >therefore not >> >> required, as described in the Diameter Base protocol [4]." >> > >> > ok >> > >> >> >> >> Based on >> >> the deployment of ERP, a local Diameter server (the same entity >> >> serves as a Diameter proxy during the full EAP >> authentication) may >> >> play the role of the ER server for future >> >re-authentication attempts. >> >> As such, the local Diameter server requesting the DSRK >> >needs to be in >> >> the path of the current EAP exchange between the peer = >and the EAP >> >> server and also along in the future. The Diameter client is >> >> furthermore assumed to be able to route the re-authentication >> >> messages to the ER server. >> >> >> >> [LM] I think that the assumption all along this document is >> >that the local ER server and the AAA agent are co-located, >> to be able >> >to rely on DEA for the transport of DSRK. In that case, I = >would say = >> >something like: >> >> >> >> "In this document, when EAP re-authentication is performed >> >in the domain >> >> visited by the peer, it is assumed that the local ER >> >server is co-located >> >> with a Diameter agent in the visited domain present in >> >the path of the full >> >> EAP exchange." >> > >> > ok >> > >> >> >> >> >> >> 4. Diameter Support for ERP >> >> >> >> 4.1. Protocol Overview >> >> >> >> Diameter may be used to transport ERP messages between the NAS >> >> (authenticator) and an authentication server (ER server). >> >> >> >> [LM] s/may/is (the use of Diameter is a pre-requisite in >> this draft) >> >> >> >> In ERP, the peer sends an EAP Initiate Reauth message to the ER >> >> server via the authenticator. >> >> >> >> [LM] s/"EAP Initiate Reauth message"/"EAP-Initiate/Re-auth >> message" = >> >> (same all along the document) >> >> >> >> Alternatively, the NAS may send an EAP >> >> Initiate Reauth-Start message to the peer to trigger = >the start of >> >> ERP; the peer then responds with an EAP Initiate Reauth >> message to >> >> the NAS. >> >> >> >> [LM] s/"EAP Initiate Reauth-Start >> >message"/"EAP-Initiate/Re-auth-Start >> >> message" (same all along the document) >> >> >> >> The general guidelines for encapsulating EAP messages = >in Diameter >> >> from RFC 4072 [1] apply to the new EAP messages defined >> for ERP as >> >> well. The EAP Initiate Reauth message is encapsulated = >in an EAP- >> >> Payload AVP of a Diameter EAP-Request message by the NAS >> >and sent to >> >> the Diameter server. The NAS MUST copy the contents of = >the value >> >> field of the 'rIKName as NAI' TLV or the peer-id TLV (when >> >the former >> >> is not present) of the EAP Initiate Reauth message into >> a User-Name >> >> AVP of the Diameter EAP-Request. >> >> >> >> [LM] I think that we are talking about the 'keyName-NAI' TLV >> >and not anymore the 'rIKName as NAI' TLV. >> > >> > Considering section 5.3.2 of RFC 5296. I agree. >> > >> >>Moreover, in which case the peer-id TLV would not be >> present for ERP? >> > >> > Privacy ? >> > >> >> >> >> The ER server processes the EAP Initiate Reauth message in >> >accordance >> >> with [2], and if that is successful, it responds with an >> EAP Finish >> >> Reauth message indicating a success ('R' flag set to 0). The >> >> Diameter server MUST encapsulate the EAP Finish Reauth >> message with >> >> the R flag set to zero in an EAP-Payload AVP attribute of >> >a Diameter >> >> EAP-Answer message. An EAP-Master-Session-Key AVP >> included in the >> >> Diameter EAP-Answer contains the Re-authentication Master >> >Session Key >> >> (rMSK). The Diameter Result Code, if any, SHOULD be a >> >success Result >> >> Code. >> >> >> >> If the processing of the EAP Initiate Reauth message >> resulted in a >> >> failure, the Diameter server MUST encapsulate an EAP >> Finish Reauth >> >> message indicating failure ('R' flag set to 1) in an >> >EAP-Payload AVP >> >> of a Diameter EAP-Answer message. The Diameter Result >> >Code, if any, >> >> SHOULD be a failure Result Code. Whether an EAP Finish Reauth >> >> message is sent at all is specified in [2]. >> >> >> >> [LM] the use of the 'R' flag is not relevant for Diameter EAP. >> >> [LM] according to the RFC, the EAP-Finish/Re-auth is sent >> >back in any case, success or failure. >> >> [LM] according to the above comments, I would rephrase the >> >text as follow: >> >> >> >> >> >> "The ER server processes the EAP Initiate Reauth message >> >in accordance >> >> with [2] and responds with an EAP-Finish/Re-auth message. = >> >The Diameter >> >> server MUST encapsulate the EAP-Finish/Re-auth message within an >> >> EAP-Payload AVP of a Diameter EAP-Answer message. >> >> In an EAP re-authentication successful case, an >> >EAP-Master-Session-Key >> >> AVP is included in the Diameter EAP-Answer message that >> >contains the >> >> Re-authentication Master Session Key (rMSK). The Diameter >> >Result-Code >> >> SHOULD be a success Result-Code. >> >> In an EAP re-authentication failure case, the Diameter >> >Result-Code of >> >> the a Diameter EAP-Answer message SHOULD be a failure >> >Result-Code and >> >> no EAP-Master-Session-Key AVP is present." >> >> >> >> [LM] By the way, I don't understand the "SHOULD" for the >> >result-code. Any reason not to use "MUST" here? >> > >> > I think a MUST would be better. Different views ? >> > >> >> [LM] a figure could be added for illustration here. >> >> >> >> 4.2. DSRK Request and Delivery >> >> >> >> A local ER server, collocated with a Diameter proxy in = >the peer's >> >> visited domain, >> >> >> >> [LM] s/in the peer's visited domain/in the domain visited >> by the peer >> >> >> >> may request a DSRK from the EAP server, either in the >> >> initial EAP exchange (implicit bootstrapping) or in an ERP >> >> bootstrapping exchange (explicit bootstrapping). It = >does this by >> >> including the EAP-DSRK-Request AVP in the Diameter EAP-Response >> >> message. The EAP-DSRK-Request AVP contains the domain or server >> >> identity required to derive the DSRK. >> >> >> >> [LM] the EAP-DSRK-Request AVP is included in the Diameter >> >EAP-Request >> >> (and not in the response) >> > >> > yes. >> > >> >> >> >> An EAP server MAY send the DSRK when it receives a = >valid Diameter >> >> EAP-Request message containing an EAP-DSRK-Request AVP. = >> >An ER server >> >> MUST send the DSRK (or send a failure result) when it receives a >> >> valid Diameter EAP-Request message containing an >> >EAP-DSRK-Request AVP >> >> along with a valid EAP Initiate Re-auth packet with the >> >bootstrapping >> >> flag turned on. If an EAP-DSRK-Request AVP is included in >> >any other >> >> Diameter EAP-Request message, the Diameter server MUST >> reply with a >> >> failure result. An EAP-DSRK AVP MUST be used to send a >> >DSRK; an EAP- >> >> DSRK-Name AVP MUST be used to send the DSRK's keyname; >> and an EAP- >> >> DSRK-Lifetime AVP MUST be used to send the DSRK's lifetime. >> >> >> >> [LM] I don't understand the intention of the above text. = >> >Could it be enough to say: >> >> >> >> In successful case, the DSRK is carried by the EAP-DSRK >> AVP in the >> >> Diameter EAP response message. Along with the EAP-DSRK AVP, an >> >> EAP-DSRK-Name AVP MUST be used to send the DSRK's keyname and an >> >> EAP-DSRK-Lifetime AVP MUST be used to send the DSRK's lifetime. >> > >> > Agree. >> > >> >> >> >> [LM] a figure could be added for illustration here. >> >> >> >> 5. Command Codes >> >> >> >> [LM] this section is not required as there is nothing >> >specific for ERP. We should skip it. >> >> >> >> [SKIP] >> >> >> >> >> >> 6. Attribute Value Pair Definitions >> >> >> >> 6.1. EAP-DSRK-Request AVP >> >> >> >> The EAP-DSRK AVP (AVP Code TBD) is of type DiameterIdentity. >> >> >> >> [LM] s/EAP-DSRK AVP/EAP-DSRK-Request AVP >> >> >> >> This >> >> AVP fulfills two purposes: First, it indicates that a ER >> server is >> >> located in the local domain that is willing to play the >> >role of an ER >> >> server for a particular session. Second, it conveys information >> >> about the domain and ER server identity to the >> Diameter/EAP server. >> >> >> >> [LM] the use of this AVP is explained above. There is no >> >need to explain again. >> > >> > As we are in the AVP Definitions, I think it is better to = >keep some = >> >text explaining it. No ? >> > >> >> Moreover, if a DiameterIdentity is used, it is to indicate a >> >server and not a domain. Right? >> > >> > In my understanding the local ER server only sends the Domain Name = >> >which will then be used to compute keys. Maybe the type = >> >DiameterIdentity is not appropriated and we should use UTF8String = >> >instead. What do you think ? >> > >> > >> >> >> >> 6.2. EAP-DSRK AVP >> >> >> >> The EAP-DSRK AVP (AVP Code TBD) is of type OctetString. = >> The Domain >> >> Specific Root Key (DSRK) is carried in this payload. >> >> >> >> 6.3. EAP-DSRK-Name AVP >> >> >> >> The EAP-DSRK-Name AVP (AVP Code TBD) is of type >> OctetString. This >> >> AVP contains the name of the DSRK key that is later used >> during the >> >> re-authentication exchange to select the correct DSRK. >> >> >> >> [LM] skip the part starting by "that is..." >> > >> > ok >> > >> >> >> >> 6.4. EAP-DSRK-Lifetime AVP >> >> >> >> The EAP-DSRK-Lifetime AVP (AVP Code TBD) is of type >> Unsigned64 and >> >> contains the DSRK lifetime in seconds. >> >> >> >> >> >> 7. AVP Occurrence Table >> >> >> >> The following table lists the AVPs that may optionally be >> >present in >> >> the DER and DEA commands [1]. >> >> >> >> >> >> +---------------+ >> >> | Command-Code | >> >> +-+-----+-----+-+ >> >> Attribute Name | DER | DEA | >> >> -------------------------------|-----+-----+ >> >> EAP-DSRK-Request | 0-1 | 0 | >> >> EAP-DSRK | 0 | 0-1 | >> >> EAP-DSRK-Name | 0 | 0-1 | >> >> EAP-DSRK-Lifetime | 0 | 0-1 | >> >> +-----+-----+ >> >> >> >> Figure 4: DER and DEA Commands AVP Table >> >> >> >> When the EAP-DSRK AVP is present in the DEA then the >> EAP-DSRK-Name >> >> and the EAP-DSRK-Lifetime MUST also be present. >> >> >> >> >> >> 8. AVP Flag Rules >> >> >> >> The following table describes the Diameter AVPs, their AVP Code >> >> values, types, possible flag values, and whether the AVP MAY be >> >> encrypted. The Diameter base [4] specifies the AVP Flag >> rules for >> >> AVPs in Section 4.5. >> >> >> >> >> >> +---------------------+ >> >> | AVP Flag Rules | >> >> = >> >+----+-----+----+-----+----+ >> >> AVP Section | | = >> >|SHLD|MUST | | >> >> Attribute Name Code Defined Data Type |MUST| MAY |NOT = >> >|NOT |Encr| >> >> = >> >------------------------------------------+----+-----+----+-- >> ---+----+ >> >> EAP-DSRK-Request TBD 4.7.1 DiamIdent | | P | | = >> >V,M | Y | >> >> EAP-DSRK TBD 4.7.2 OctetString| | P | | = >> >V,M | Y | >> >> EAP-DSRK-Name TBD 4.7.3 OctetString| | P | | = >> >V,M | Y | >> >> EAP-DSRK-Lifetime TBD 4.7.4 Unsigned64 | | P | | = >> >V,M | Y | >> >> = >> >> = >> >------------------------------------------+----+-----+----+-- >> ---+----+ >> >> >> >> Due to space constraints, the short form DiamIdent is used to = >> >> represent DiameterIdentity. >> >> >> >> Figure 5: AVP Flag Rules Table >> >> >> >> [LM] this table is ok according to the current RFC 3588. I >> >don't know how to deal with it regarding the RFC3588bis... >> > >> > >> > That's indeed a good question :). >> > >> > And that's all for my comments of your comments. >> > >> > Regards, >> > >> > --Julien-- >> >_______________________________________________ >> >DiME mailing list >> >DiME@ietf.org >> >https://www.ietf.org/mailman/listinfo/dime >> > >> = > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jan 9 01:07:25 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B332D3A6A99; Fri, 9 Jan 2009 01:07:25 -0800 (PST) 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 C80993A6A99 for ; Fri, 9 Jan 2009 01:07:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.413 X-Spam-Level: X-Spam-Status: No, score=-4.413 tagged_above=-999 required=5 tests=[AWL=-1.164, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-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 lkCDPTwJBhXD for ; Fri, 9 Jan 2009 01:07:22 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 631FC3A693E for ; Fri, 9 Jan 2009 01:07:20 -0800 (PST) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Jan 2009 10:07:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 Jan 2009 10:06:58 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB0260622C5AD@ftrdmel2> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Review of the Diameter ERP draft Thread-Index: AclxenKpDp1tiH+tR5acfa7D++IC0QAFZFSQAA+E7ZAAGGn/YAABPrzg References: <7DBAFEC6A76F3E42817DF1EBE64CB026061E2759@ftrdmel2> <5e2406980901080218w746b69a7x320f1501aeb97266@mail.gmail.com> <7DBAFEC6A76F3E42817DF1EBE64CB0260622C4DE@ftrdmel2> From: To: , , , X-OriginalArrivalTime: 09 Jan 2009 09:07:01.0944 (UTC) FILETIME=[A25C7380:01C97239] Subject: Re: [Dime] Review of the Diameter ERP 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I understand. However, I don't see how the use of a new appli-ID will solve this issue if= you have multiple AAA proxies supporting ERP in the same visited domain. I= f you reach a new AAA proxy that has not yet the DSRK, it will have to cont= act anyway the home EAP server to retrieve this key. For me, ERP with a local ER server will be useful for peers connected to th= e same EAP authenticator for a long time or if several EAP authenticators a= re connected to the same AAA proxy. And in the latter case, it is just an a= rchitectural issue. BR, Lionel > -----Message d'origine----- > De : Tschofenig, Hannes (NSN - FI/Espoo) = > [mailto:hannes.tschofenig@nsn.com] = > Envoy=E9 : vendredi 9 janvier 2009 08:58 > =C0 : MORAND Lionel RD-CORE-ISS; julien.bournelle@gmail.com; = > sdecugis@hongo.wide.ad.jp; dime@ietf.org > Objet : RE: [Dime] Review of the Diameter ERP draft > = > My reading of this text is that there is a way for the peer = > and the authenticator to figure out whether to use EAP or ERP. = > It, however, says very little about the further routing of = > AAA messages in such a way that the messages traverse nodes = > understanding the additionally required functionality. If I = > understood ERP correctly then some key caching takes place in = > the AAA proxies and hence one wants to make sure that the = > messages are actually routed via these proxies. > = > Ciao > Hannes > = > = > >-----Original Message----- > >From: ext lionel.morand@orange-ftgroup.com = > >[mailto:lionel.morand@orange-ftgroup.com] > >Sent: 08 January, 2009 22:26 > >To: Tschofenig, Hannes (NSN - FI/Espoo); julien.bournelle@gmail.com; = > >sdecugis@hongo.wide.ad.jp; dime@ietf.org > >Subject: RE: [Dime] Review of the Diameter ERP draft > > > >According to the RFC 5296, it seems that it is not required = > to have a = > >specific Appl-ID: > > > > "It is plausible that the authenticator does not know whether the = > >peer > > supports ERP and whether the peer has performed a full EAP > > authentication through another authenticator. The = > authenticator MAY > > initiate the ERP exchange by sending the = > EAP-Initiate/Re-auth-Start > > message, and if there is no response, it will send the = > EAP-Request/ > > Identity message. Note that this avoids having two EAP = > messages in > > flight at the same time [2]. The authenticator may send the EAP- > > Initiate/Re-auth-Start message and wait for a short, locally > > configured amount of time. If the peer does not already = > know, this > > message indicates to the peer that the authenticator supports ERP. > > In response to this trigger from the authenticator, the peer can > > initiate the ERP exchange by sending an EAP-Initiate/Re-auth = > >message. > > If there is no response from the peer after the necessary > > retransmissions (see Section 6), the authenticator MUST = > initiate EAP > > by sending an EAP-Request message, typically the = > >EAP-Request/Identity > > message. Note that the authenticator may receive an EAP-Initiate/ > > Re-auth message after it has sent an EAP-Request/Identity message. > > If the authenticator supports ERP, it MUST proceed with the ERP > > exchange. When the EAP-Request/Identity times out, the = > >authenticator > > MUST NOT close the connection if an ERP exchange is in progress or > > has already succeeded in establishing a re-authentication MSK. > > > > If the authenticator does not support ERP, it drops EAP-Initiate/ > > Re-auth messages [2] as the EAP code of those packets is greater = > >than > > 4. An ERP-capable peer will exhaust the EAP-Initiate/Re-auth = > >message > > retransmissions and fall back to EAP authentication by = > responding to > > EAP Request/Identity messages from the authenticator. If the peer > > does not support ERP or if it does not have unexpired key material > > from a previous EAP authentication, it drops EAP-Initiate/ > > Re-auth-Start messages. If there is no response to the = > >EAP-Initiate/ > > Re-auth-Start message, the authenticator SHALL send an EAP Request > > message (typically EAP Request/Identity) to start EAP = > >authentication. > > From this stage onwards, RFC 3748 rules apply. Note that this may > > introduce some delay in starting EAP. In some lower layers, the > > delay can be minimized or even avoided by the peer = > initiating EAP by > > sending messages such as EAPoL-Start in the IEEE 802.1X = > >specification > > [10]." > > > >Both paragraphs assume (for me) that the ERP "option" may be = > supported = > >by the peer and/or the network. If none of them (or only one = > of them) = > >support ERP, the fallback mechanism is full EAP authentication. > >In that sense, knowing that the network supports ERP is not a = > >pre-requisite. The minimum is to support EAP and ERP is an option = > >available above EAP. That allows to deploy ERP above existing EAP = > >deployment. > > > >Does it make sense? > > > >Best Regards, > > > >Lionel > > > > > >> -----Message d'origine----- > >> De : Tschofenig, Hannes (NSN - FI/Espoo) = > >> [mailto:hannes.tschofenig@nsn.com] > >> Envoy=E9 : jeudi 8 janvier 2009 13:55 > >> =C0 : ext Julien Bournelle; MORAND Lionel RD-CORE-ISS; Sebastien = > >> Decugis; dime@ietf.org Objet : RE: [Dime] Review of the = > Diameter ERP = > >> draft > >> = > >> One of the things I was not quite sure with the current protocol = > >> design is whether a Diameter application or just a bunch = > of AVPs are = > >> required. > >> Based on the discussions a few of us when some of the HOKEY > >specs went > >> to the IESG / IETF Last Call I got the impression that one has to = > >> define a new Diameter application (which would be based on Diameter > >> EAP) since you assume that the messages are routed via a = > node in the = > >> local network and the support for ERP has to be ensured. > >> = > >> Ciao > >> Hannes > >> = > >> >-----Original Message----- > >> >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] > >> On Behalf Of > >> >ext Julien Bournelle > >> >Sent: 08 January, 2009 12:18 > >> >To: lionel.morand@orange-ftgroup.com; Sebastien Decugis; > >> dime@ietf.org > >> >Subject: Re: [Dime] Review of the Diameter ERP draft > >> > > >> >Hi lionel, > >> > > >> > some comments inline. > >> > > >> >On Wed, Jan 7, 2009 at 12:03 PM, > >> > wrote: > >> >> > >> >> Hi, > >> >> > >> >> Here is my review for the Diameter ERP draft. > >> >> > >> >> General comments: > >> >> > >> >> - About alignment with RFC 5296: > >> >> the draft needs to be updated according to the publication > >> >of the RFC 5296. Some proposals are provided below. > >> >> > >> >> - About ER server/AAA agent co-location: > >> >> In my understanding, it is assumed in this document ER > >> >server and AAA proxy have to be co-located to be able to rely on = > >> >Diameter to transport ERP specific AVPs. This doesn't maybe > >preclude > >> >other architectural choices but there are outside the = > scope of this = > >> >document. It is necessary to clarify this point in this document. > >> >> > >> >> - ERP support discovery: > >> >> As the ERP specific AVPs are introduced with the M-bit > >> >cleared, these AVPs are purely optional for the Diameter EAP = > >> >application i.e. they can be silently ignored by Diameter > >> servers that > >> >do not understand this new AVPs. Some text should be provided to = > >> >describe how the local ER server discovers that the Home = > EAP server = > >> >doesn't support ERP and the behaviour of the local ER > >server in that > >> >case. > >> > > >> > > >> > I agree with these general comments. > >> > > >> > > >> >> > >> >> Hereafter is the rest of my review with comments and proposals. > >> >> > >> >> Best Regards, > >> >> > >> >> Lionel > >> >> > >> >> *************************************** > >> >> > >> >> Abstract > >> >> > >> >> An EAP extension, called "EAP Re-authentication Protocol > >> >(ERP)", has > >> >> been specified that supports an EAP method-independent > >> protocol for > >> >> efficient re-authentication between the peer and the > >> server through > >> >> an authenticator. This document specifies Diameter > >> >support for ERP. > >> >> The Diameter EAP application is re-used for > >> encapsulating the newly > >> >> defined EAP Initiate and EAP Finish messages specified > >in the ERP > >> >> specification. AVPs for request and delivery of Domain > >> >Specific Root > >> >> Keys from the AAA/EAP server to the ER server are also > >specified. > >> >> Additionally, this document also specifies Diameter > >> >processing rules > >> >> relevant to ERP. > >> >> > >> >> [LM] some abusive verbiage in the abstract: > >> >> > >> >> Proposal for new abstract: > >> >> > >> >> "EAP Re-authentication Protocol defines extensions of EAP > >> >to support > >> >> efficient re-authentication between the peer and an EAP > >> >> re-authentication server through any authenticator. > >> > > >> > I'm wondering if we should note that the authenticator may be = > >> >ERP-aware. > >> >I'm thinking about the case where the authenticator sends the = > >> >EAP-Initiate/Re-auth-Start (Figure 4 in RFC 5296) > >> > > >> > > >> >> This document > >> >> specifies Diameter support for ERP. The Diameter EAP > >> application is > >> >> re-used for encapsulating the newly defined EAP messages > >> specified > >> >> in the ERP specification. Additionally, this document > >> also defines > >> >> specific Diameter processing rules relevant to ERP." > >> > > >> > ok > >> > > >> >> > >> >> > >> >> 1. Introduction > >> >> > >> >> RFC 4072 [1] specifies a Diameter application that carries EAP > >> >> packets between a Diameter client and the Diameter > >> >Server/EAP server. > >> >> [2] defines the EAP Re-authentication Protocol to allow > >> faster re- > >> >> authentication of a previously authenticated peer. > >> >> > >> >> [LM] s/[2] defines the EAP Re-authentication Protocol/RFC > >5296 [2] > >> >> defines the EAP Re-authentication Protocol (ERP) > >> >> > >> >> In ERP, a peer > >> >> authenticates to the network by proving possession of > >> key material > >> >> derived during a previous EAP exchange. > >> >> > >> >> [LM] s/a peer authenticate to/a peer is authenticated by > >> >> > >> >> For this purpose, an > >> >> Extended Master Session Key (EMSK) based re-authentication key > >> >> hierarchy has been defined [5]. ERP may be executed > >> between the ER > >> >> peer and an ER server in the peer's home domain or the > >> local domain > >> >> visited by the peer. In the latter case, a Domain > >> Specific Root Key > >> >> (DSRK), derived from the EMSK, is provided to the local > >domain ER > >> >> server. > >> >> > >> >> [LM] s/is provided to/is provided by the Home ER server to > >> >> > >> >> The peer and the local server subsequently use the re- > >> >> authentication key hierarchy from the DSRK to authenticate > >> >and derive > >> >> authenticator specific keys within that domain. > >> >> > >> >> [LM] this information can be found in the RFC 5296. Remove > >> >the sentence above. > >> > > >> > It may help the reader to understand the purpose of this DRSK. > >> > > >> >> > >> >> To accomplish the > >> >> reauthentication functionality, ERP defines two new EAP > >> codes - EAP > >> >> Initiate and EAP Finish. > >> >> > >> >> [LM] s/ERP defines two new EAP codes/ERP defines two new > >> EAP messages > >> > > >> > I would prefer to say that ERP defines two new EAP Codes > >> here. These > >> >newly EAP packets are then carried in messages (dependent of the = > >> >protocol used). > >> > > >> >> > >> >> This document specifies the reuse of > >> >> Diameter EAP application to carry these new EAP messages. > >> >> The DSRK can be obtained as part of the regular EAP > >> exchange or as > >> >> part of an ERP bootstrapping exchange. The local ER server > >> >> requesting the DSRK needs to be in the path of the EAP or ERP > >> >> bootstrapping exchange in order to request and obtain the > >> >DSRK. This > >> >> document also specifies how the DSRK is transported to > >> the local ER > >> >> server using Diameter. > >> >> > >> >> [LM] Finally, i would reorganize the last part as follow: > >> >> > >> >> ::::::::::: > >> >> > >> >> "In ERP, a peer is authenticated by the network thanks to > >> >keying material > >> >> obtained during a previous EAP exchange. This keying > >> >material is derived > >> >> from the Extended Master Session Key (EMSK) defined in the > >> >RFC 5295 [5]. > >> >> To accomplish the EAP reauthentication functionality, ERP > >> >defines two new > >> >> EAP messages - EAP Initiate and EAP Finish. This document > >> >specifies the > >> >> reuse of Diameter EAP Application to carry these new EAP > >> messages. > >> >> > >> >> ERP is executed between the peer and a server located > >> >either in the peer's > >> >> home domain or in the local domain visited by the peer. In > >> >the latter case, > >> >> a Domain Specific Root Key (DSRK) is derived from the > >> >EMSK, as defined in > >> >> the RFC 5295 [5], and is provided by the Home EAP server > >> >to the local domain > >> >> server. For that purpose, this document specifies the > >> >transport of the DSRK > >> >> using the Diameter EAP Application." > >> > > >> > First paragraph is the old and second the new ? > >> > > >> >> > >> >> :::::::::::::: > >> >> > >> >> > >> >> > >> >> 2. Terminology > >> >> > >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", > >> "SHALL NOT", > >> >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > >> >"OPTIONAL" in this > >> >> document are to be interpreted as described in RFC 2119 [3]. > >> >> > >> >> This document uses terminology defined in [6], [5], > >[2], and [1]. > >> >> > >> >> > >> >> 3. Assumptions > >> >> > >> >> This document defines additional optional AVPs for > >usage with the > >> >> Diameter EAP application. Routing of these messages is > >therefore > >> >> provided via the Diameter Application Identifier (among other > >> >> elements), as specified by the Diameter Base protocol [4]. > >> >> > >> >> [LM] To avoid any ambiguity I would say: > >> >> > >> >> "This document defines only additional optional AVPs for > >> usage with > >> >> the Diameter EAP application. This document does not defined > >> >> a new Diameter application and a new Application ID is > >> >therefore not > >> >> required, as described in the Diameter Base protocol [4]." > >> > > >> > ok > >> > > >> >> > >> >> Based on > >> >> the deployment of ERP, a local Diameter server (the = > same entity > >> >> serves as a Diameter proxy during the full EAP > >> authentication) may > >> >> play the role of the ER server for future > >> >re-authentication attempts. > >> >> As such, the local Diameter server requesting the DSRK > >> >needs to be in > >> >> the path of the current EAP exchange between the peer > >and the EAP > >> >> server and also along in the future. The Diameter client is > >> >> furthermore assumed to be able to route the re-authentication > >> >> messages to the ER server. > >> >> > >> >> [LM] I think that the assumption all along this document is > >> >that the local ER server and the AAA agent are co-located, > >> to be able > >> >to rely on DEA for the transport of DSRK. In that case, I > >would say > >> >something like: > >> >> > >> >> "In this document, when EAP re-authentication is performed > >> >in the domain > >> >> visited by the peer, it is assumed that the local ER > >> >server is co-located > >> >> with a Diameter agent in the visited domain present in > >> >the path of the full > >> >> EAP exchange." > >> > > >> > ok > >> > > >> >> > >> >> > >> >> 4. Diameter Support for ERP > >> >> > >> >> 4.1. Protocol Overview > >> >> > >> >> Diameter may be used to transport ERP messages between the NAS > >> >> (authenticator) and an authentication server (ER server). > >> >> > >> >> [LM] s/may/is (the use of Diameter is a pre-requisite in > >> this draft) > >> >> > >> >> In ERP, the peer sends an EAP Initiate Reauth message = > to the ER > >> >> server via the authenticator. > >> >> > >> >> [LM] s/"EAP Initiate Reauth message"/"EAP-Initiate/Re-auth > >> message" = > >> >> (same all along the document) > >> >> > >> >> Alternatively, the NAS may send an EAP > >> >> Initiate Reauth-Start message to the peer to trigger > >the start of > >> >> ERP; the peer then responds with an EAP Initiate Reauth > >> message to > >> >> the NAS. > >> >> > >> >> [LM] s/"EAP Initiate Reauth-Start > >> >message"/"EAP-Initiate/Re-auth-Start > >> >> message" (same all along the document) > >> >> > >> >> The general guidelines for encapsulating EAP messages > >in Diameter > >> >> from RFC 4072 [1] apply to the new EAP messages defined > >> for ERP as > >> >> well. The EAP Initiate Reauth message is encapsulated > >in an EAP- > >> >> Payload AVP of a Diameter EAP-Request message by the NAS > >> >and sent to > >> >> the Diameter server. The NAS MUST copy the contents of > >the value > >> >> field of the 'rIKName as NAI' TLV or the peer-id TLV (when > >> >the former > >> >> is not present) of the EAP Initiate Reauth message into > >> a User-Name > >> >> AVP of the Diameter EAP-Request. > >> >> > >> >> [LM] I think that we are talking about the 'keyName-NAI' TLV > >> >and not anymore the 'rIKName as NAI' TLV. > >> > > >> > Considering section 5.3.2 of RFC 5296. I agree. > >> > > >> >>Moreover, in which case the peer-id TLV would not be > >> present for ERP? > >> > > >> > Privacy ? > >> > > >> >> > >> >> The ER server processes the EAP Initiate Reauth message in > >> >accordance > >> >> with [2], and if that is successful, it responds with an > >> EAP Finish > >> >> Reauth message indicating a success ('R' flag set to 0). The > >> >> Diameter server MUST encapsulate the EAP Finish Reauth > >> message with > >> >> the R flag set to zero in an EAP-Payload AVP attribute of > >> >a Diameter > >> >> EAP-Answer message. An EAP-Master-Session-Key AVP > >> included in the > >> >> Diameter EAP-Answer contains the Re-authentication Master > >> >Session Key > >> >> (rMSK). The Diameter Result Code, if any, SHOULD be a > >> >success Result > >> >> Code. > >> >> > >> >> If the processing of the EAP Initiate Reauth message > >> resulted in a > >> >> failure, the Diameter server MUST encapsulate an EAP > >> Finish Reauth > >> >> message indicating failure ('R' flag set to 1) in an > >> >EAP-Payload AVP > >> >> of a Diameter EAP-Answer message. The Diameter Result > >> >Code, if any, > >> >> SHOULD be a failure Result Code. Whether an EAP Finish Reauth > >> >> message is sent at all is specified in [2]. > >> >> > >> >> [LM] the use of the 'R' flag is not relevant for Diameter EAP. > >> >> [LM] according to the RFC, the EAP-Finish/Re-auth is sent > >> >back in any case, success or failure. > >> >> [LM] according to the above comments, I would rephrase the > >> >text as follow: > >> >> > >> >> > >> >> "The ER server processes the EAP Initiate Reauth message > >> >in accordance > >> >> with [2] and responds with an EAP-Finish/Re-auth message. = > >> >The Diameter > >> >> server MUST encapsulate the EAP-Finish/Re-auth = > message within an > >> >> EAP-Payload AVP of a Diameter EAP-Answer message. > >> >> In an EAP re-authentication successful case, an > >> >EAP-Master-Session-Key > >> >> AVP is included in the Diameter EAP-Answer message that > >> >contains the > >> >> Re-authentication Master Session Key (rMSK). The Diameter > >> >Result-Code > >> >> SHOULD be a success Result-Code. > >> >> In an EAP re-authentication failure case, the Diameter > >> >Result-Code of > >> >> the a Diameter EAP-Answer message SHOULD be a failure > >> >Result-Code and > >> >> no EAP-Master-Session-Key AVP is present." > >> >> > >> >> [LM] By the way, I don't understand the "SHOULD" for the > >> >result-code. Any reason not to use "MUST" here? > >> > > >> > I think a MUST would be better. Different views ? > >> > > >> >> [LM] a figure could be added for illustration here. > >> >> > >> >> 4.2. DSRK Request and Delivery > >> >> > >> >> A local ER server, collocated with a Diameter proxy in > >the peer's > >> >> visited domain, > >> >> > >> >> [LM] s/in the peer's visited domain/in the domain visited > >> by the peer > >> >> > >> >> may request a DSRK from the EAP server, either in the > >> >> initial EAP exchange (implicit bootstrapping) or in an ERP > >> >> bootstrapping exchange (explicit bootstrapping). It > >does this by > >> >> including the EAP-DSRK-Request AVP in the Diameter = > EAP-Response > >> >> message. The EAP-DSRK-Request AVP contains the = > domain or server > >> >> identity required to derive the DSRK. > >> >> > >> >> [LM] the EAP-DSRK-Request AVP is included in the Diameter > >> >EAP-Request > >> >> (and not in the response) > >> > > >> > yes. > >> > > >> >> > >> >> An EAP server MAY send the DSRK when it receives a > >valid Diameter > >> >> EAP-Request message containing an EAP-DSRK-Request AVP. = > >> >An ER server > >> >> MUST send the DSRK (or send a failure result) when it = > receives a > >> >> valid Diameter EAP-Request message containing an > >> >EAP-DSRK-Request AVP > >> >> along with a valid EAP Initiate Re-auth packet with the > >> >bootstrapping > >> >> flag turned on. If an EAP-DSRK-Request AVP is included in > >> >any other > >> >> Diameter EAP-Request message, the Diameter server MUST > >> reply with a > >> >> failure result. An EAP-DSRK AVP MUST be used to send a > >> >DSRK; an EAP- > >> >> DSRK-Name AVP MUST be used to send the DSRK's keyname; > >> and an EAP- > >> >> DSRK-Lifetime AVP MUST be used to send the DSRK's lifetime. > >> >> > >> >> [LM] I don't understand the intention of the above text. = > >> >Could it be enough to say: > >> >> > >> >> In successful case, the DSRK is carried by the EAP-DSRK > >> AVP in the > >> >> Diameter EAP response message. Along with the EAP-DSRK AVP, an > >> >> EAP-DSRK-Name AVP MUST be used to send the DSRK's = > keyname and an > >> >> EAP-DSRK-Lifetime AVP MUST be used to send the DSRK's = > lifetime. > >> > > >> > Agree. > >> > > >> >> > >> >> [LM] a figure could be added for illustration here. > >> >> > >> >> 5. Command Codes > >> >> > >> >> [LM] this section is not required as there is nothing > >> >specific for ERP. We should skip it. > >> >> > >> >> [SKIP] > >> >> > >> >> > >> >> 6. Attribute Value Pair Definitions > >> >> > >> >> 6.1. EAP-DSRK-Request AVP > >> >> > >> >> The EAP-DSRK AVP (AVP Code TBD) is of type DiameterIdentity. > >> >> > >> >> [LM] s/EAP-DSRK AVP/EAP-DSRK-Request AVP > >> >> > >> >> This > >> >> AVP fulfills two purposes: First, it indicates that a ER > >> server is > >> >> located in the local domain that is willing to play the > >> >role of an ER > >> >> server for a particular session. Second, it conveys = > information > >> >> about the domain and ER server identity to the > >> Diameter/EAP server. > >> >> > >> >> [LM] the use of this AVP is explained above. There is no > >> >need to explain again. > >> > > >> > As we are in the AVP Definitions, I think it is better to > >keep some > >> >text explaining it. No ? > >> > > >> >> Moreover, if a DiameterIdentity is used, it is to indicate a > >> >server and not a domain. Right? > >> > > >> > In my understanding the local ER server only sends the = > Domain Name = > >> >which will then be used to compute keys. Maybe the type = > >> >DiameterIdentity is not appropriated and we should use UTF8String = > >> >instead. What do you think ? > >> > > >> > > >> >> > >> >> 6.2. EAP-DSRK AVP > >> >> > >> >> The EAP-DSRK AVP (AVP Code TBD) is of type OctetString. = > >> The Domain > >> >> Specific Root Key (DSRK) is carried in this payload. > >> >> > >> >> 6.3. EAP-DSRK-Name AVP > >> >> > >> >> The EAP-DSRK-Name AVP (AVP Code TBD) is of type > >> OctetString. This > >> >> AVP contains the name of the DSRK key that is later used > >> during the > >> >> re-authentication exchange to select the correct DSRK. > >> >> > >> >> [LM] skip the part starting by "that is..." > >> > > >> > ok > >> > > >> >> > >> >> 6.4. EAP-DSRK-Lifetime AVP > >> >> > >> >> The EAP-DSRK-Lifetime AVP (AVP Code TBD) is of type > >> Unsigned64 and > >> >> contains the DSRK lifetime in seconds. > >> >> > >> >> > >> >> 7. AVP Occurrence Table > >> >> > >> >> The following table lists the AVPs that may optionally be > >> >present in > >> >> the DER and DEA commands [1]. > >> >> > >> >> > >> >> +---------------+ > >> >> | Command-Code | > >> >> +-+-----+-----+-+ > >> >> Attribute Name | DER | DEA | > >> >> -------------------------------|-----+-----+ > >> >> EAP-DSRK-Request | 0-1 | 0 | > >> >> EAP-DSRK | 0 | 0-1 | > >> >> EAP-DSRK-Name | 0 | 0-1 | > >> >> EAP-DSRK-Lifetime | 0 | 0-1 | > >> >> +-----+-----+ > >> >> > >> >> Figure 4: DER and DEA Commands AVP Table > >> >> > >> >> When the EAP-DSRK AVP is present in the DEA then the > >> EAP-DSRK-Name > >> >> and the EAP-DSRK-Lifetime MUST also be present. > >> >> > >> >> > >> >> 8. AVP Flag Rules > >> >> > >> >> The following table describes the Diameter AVPs, = > their AVP Code > >> >> values, types, possible flag values, and whether the = > AVP MAY be > >> >> encrypted. The Diameter base [4] specifies the AVP Flag > >> rules for > >> >> AVPs in Section 4.5. > >> >> > >> >> > >> >> = > +---------------------+ > >> >> | AVP = > Flag Rules | > >> >> = > >> >+----+-----+----+-----+----+ > >> >> AVP Section | | = > >> >|SHLD|MUST | | > >> >> Attribute Name Code Defined Data Type |MUST| MAY |NOT = > >> >|NOT |Encr| > >> >> = > >> >------------------------------------------+----+-----+----+-- > >> ---+----+ > >> >> EAP-DSRK-Request TBD 4.7.1 DiamIdent | | P | | = > >> >V,M | Y | > >> >> EAP-DSRK TBD 4.7.2 OctetString| | P | | = > >> >V,M | Y | > >> >> EAP-DSRK-Name TBD 4.7.3 OctetString| | P | | = > >> >V,M | Y | > >> >> EAP-DSRK-Lifetime TBD 4.7.4 Unsigned64 | | P | | = > >> >V,M | Y | > >> >> = > >> >> = > >> >------------------------------------------+----+-----+----+-- > >> ---+----+ > >> >> > >> >> Due to space constraints, the short form DiamIdent is used to = > >> >> represent DiameterIdentity. > >> >> > >> >> Figure 5: AVP Flag Rules Table > >> >> > >> >> [LM] this table is ok according to the current RFC 3588. I > >> >don't know how to deal with it regarding the RFC3588bis... > >> > > >> > > >> > That's indeed a good question :). > >> > > >> > And that's all for my comments of your comments. > >> > > >> > Regards, > >> > > >> > --Julien-- > >> >_______________________________________________ > >> >DiME mailing list > >> >DiME@ietf.org > >> >https://www.ietf.org/mailman/listinfo/dime > >> > > >> = > > > = _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jan 9 01:15:30 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E93528B797; Fri, 9 Jan 2009 01:15:30 -0800 (PST) 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 10BFC28B797 for ; Fri, 9 Jan 2009 01:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlaBfyIPf6D7 for ; Fri, 9 Jan 2009 01:15:26 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id 0454F3A67BD for ; Fri, 9 Jan 2009 01:15:25 -0800 (PST) Received: by bwz14 with SMTP id 14so28610135bwz.13 for ; Fri, 09 Jan 2009 01:15:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=YgcqXViX2LdL8GyDgxYGjzkpZbW4jPyVtIDXdspku2g=; b=doKx4O/UlaSu9C62kw5PVM2ZmZDG5tMWbkWDKI6EtkABC48iRUh7R+Psm8JYviOVQo B8mlBGK5rBuoR7t9BmQkoK2PrxLpvkWU5B1rRlSEkVdfqJeL4hq2ucO/Zc0caN1xT/Gm sZwhhw7/mR4I7ZcsSF+5WS0nsEPVXYYydwikQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=psgWYUFUPyhO8tph0X2MKvf4j8jpAUPi8C+N4UEyOT5s1Vv7QefCPAQqK9fpn6oG6O CaCkeJEeIkSwK2kQ6P516djvqimLx8T6fBbQTk24TY0Yxqe5w5EVe+AHH/gND/OV/NrG 418Kmvk8je4RCjeQxZOP6Y1LJTJznz22LF0yo= Received: by 10.223.113.200 with SMTP id b8mr18330119faq.84.1231492510674; Fri, 09 Jan 2009 01:15:10 -0800 (PST) Received: by 10.223.108.129 with HTTP; Fri, 9 Jan 2009 01:15:10 -0800 (PST) Message-ID: <5e2406980901090115m2fe2c097nee9854a9ed870127@mail.gmail.com> Date: Fri, 9 Jan 2009 10:15:10 +0100 From: "Julien Bournelle" To: "Tschofenig, Hannes (NSN - FI/Espoo)" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <7DBAFEC6A76F3E42817DF1EBE64CB026061E2759@ftrdmel2> <5e2406980901080218w746b69a7x320f1501aeb97266@mail.gmail.com> <7DBAFEC6A76F3E42817DF1EBE64CB0260622C4DE@ftrdmel2> Cc: dime@ietf.org, sdecugis@hongo.wide.ad.jp Subject: Re: [Dime] Review of the Diameter ERP 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, On Fri, Jan 9, 2009 at 8:57 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > My reading of this text is that there is a way for the peer and the authe= nticator to figure out whether to use EAP or ERP. I don't see how a new App Id will help peer and authenticator to figure out ERP support. I may miss something here. My understanding is that a new Appid would however help AAA entities (authenticator, proxy, server) figure out ERP support. > It, however, says very little about the further routing of AAA messages i= n such a way that the messages traverse nodes understanding the additionall= y required functionality. If I understood ERP correctly then some key cachi= ng takes place in the AAA proxies and hence one wants to make sure that the= messages are actually routed via these proxies. Yes, ideally, for a given peer, the same AAA proxy/local ERP server should be contacted by authenticators. At this point, I don't see how to ensure this. Regards, Julien > > Ciao > Hannes > > >>-----Original Message----- >>From: ext lionel.morand@orange-ftgroup.com >>[mailto:lionel.morand@orange-ftgroup.com] >>Sent: 08 January, 2009 22:26 >>To: Tschofenig, Hannes (NSN - FI/Espoo); >>julien.bournelle@gmail.com; sdecugis@hongo.wide.ad.jp; dime@ietf.org >>Subject: RE: [Dime] Review of the Diameter ERP draft >> >>According to the RFC 5296, it seems that it is not required to >>have a specific Appl-ID: >> >> "It is plausible that the authenticator does not know >>whether the peer >> supports ERP and whether the peer has performed a full EAP >> authentication through another authenticator. The authenticator MAY >> initiate the ERP exchange by sending the EAP-Initiate/Re-auth-Start >> message, and if there is no response, it will send the EAP-Request/ >> Identity message. Note that this avoids having two EAP messages in >> flight at the same time [2]. The authenticator may send the EAP- >> Initiate/Re-auth-Start message and wait for a short, locally >> configured amount of time. If the peer does not already know, this >> message indicates to the peer that the authenticator supports ERP. >> In response to this trigger from the authenticator, the peer can >> initiate the ERP exchange by sending an >>EAP-Initiate/Re-auth message. >> If there is no response from the peer after the necessary >> retransmissions (see Section 6), the authenticator MUST initiate EAP >> by sending an EAP-Request message, typically the >>EAP-Request/Identity >> message. Note that the authenticator may receive an EAP-Initiate/ >> Re-auth message after it has sent an EAP-Request/Identity message. >> If the authenticator supports ERP, it MUST proceed with the ERP >> exchange. When the EAP-Request/Identity times out, the >>authenticator >> MUST NOT close the connection if an ERP exchange is in progress or >> has already succeeded in establishing a re-authentication MSK. >> >> If the authenticator does not support ERP, it drops EAP-Initiate/ >> Re-auth messages [2] as the EAP code of those packets is >>greater than >> 4. An ERP-capable peer will exhaust the >>EAP-Initiate/Re-auth message >> retransmissions and fall back to EAP authentication by responding to >> EAP Request/Identity messages from the authenticator. If the peer >> does not support ERP or if it does not have unexpired key material >> from a previous EAP authentication, it drops EAP-Initiate/ >> Re-auth-Start messages. If there is no response to the >>EAP-Initiate/ >> Re-auth-Start message, the authenticator SHALL send an EAP Request >> message (typically EAP Request/Identity) to start EAP >>authentication. >> From this stage onwards, RFC 3748 rules apply. Note that this may >> introduce some delay in starting EAP. In some lower layers, the >> delay can be minimized or even avoided by the peer initiating EAP by >> sending messages such as EAPoL-Start in the IEEE 802.1X >>specification >> [10]." >> >>Both paragraphs assume (for me) that the ERP "option" may be >>supported by the peer and/or the network. If none of them (or >>only one of them) support ERP, the fallback mechanism is full >>EAP authentication. >>In that sense, knowing that the network supports ERP is not a >>pre-requisite. The minimum is to support EAP and ERP is an >>option available above EAP. That allows to deploy ERP above >>existing EAP deployment. >> >>Does it make sense? >> >>Best Regards, >> >>Lionel >> >> >>> -----Message d'origine----- >>> De : Tschofenig, Hannes (NSN - FI/Espoo) >>> [mailto:hannes.tschofenig@nsn.com] >>> Envoy=E9 : jeudi 8 janvier 2009 13:55 >>> =C0 : ext Julien Bournelle; MORAND Lionel RD-CORE-ISS; Sebastien >>> Decugis; dime@ietf.org Objet : RE: [Dime] Review of the Diameter ERP >>> draft >>> >>> One of the things I was not quite sure with the current protocol >>> design is whether a Diameter application or just a bunch of AVPs are >>> required. >>> Based on the discussions a few of us when some of the HOKEY >>specs went >>> to the IESG / IETF Last Call I got the impression that one has to >>> define a new Diameter application (which would be based on Diameter >>> EAP) since you assume that the messages are routed via a node in the >>> local network and the support for ERP has to be ensured. >>> >>> Ciao >>> Hannes >>> >>> >-----Original Message----- >>> >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] >>> On Behalf Of >>> >ext Julien Bournelle >>> >Sent: 08 January, 2009 12:18 >>> >To: lionel.morand@orange-ftgroup.com; Sebastien Decugis; >>> dime@ietf.org >>> >Subject: Re: [Dime] Review of the Diameter ERP draft >>> > >>> >Hi lionel, >>> > >>> > some comments inline. >>> > >>> >On Wed, Jan 7, 2009 at 12:03 PM, >>> > wrote: >>> >> >>> >> Hi, >>> >> >>> >> Here is my review for the Diameter ERP draft. >>> >> >>> >> General comments: >>> >> >>> >> - About alignment with RFC 5296: >>> >> the draft needs to be updated according to the publication >>> >of the RFC 5296. Some proposals are provided below. >>> >> >>> >> - About ER server/AAA agent co-location: >>> >> In my understanding, it is assumed in this document ER >>> >server and AAA proxy have to be co-located to be able to rely on >>> >Diameter to transport ERP specific AVPs. This doesn't maybe >>preclude >>> >other architectural choices but there are outside the scope of this >>> >document. It is necessary to clarify this point in this document. >>> >> >>> >> - ERP support discovery: >>> >> As the ERP specific AVPs are introduced with the M-bit >>> >cleared, these AVPs are purely optional for the Diameter EAP >>> >application i.e. they can be silently ignored by Diameter >>> servers that >>> >do not understand this new AVPs. Some text should be provided to >>> >describe how the local ER server discovers that the Home EAP server >>> >doesn't support ERP and the behaviour of the local ER >>server in that >>> >case. >>> > >>> > >>> > I agree with these general comments. >>> > >>> > >>> >> >>> >> Hereafter is the rest of my review with comments and proposals. >>> >> >>> >> Best Regards, >>> >> >>> >> Lionel >>> >> >>> >> *************************************** >>> >> >>> >> Abstract >>> >> >>> >> An EAP extension, called "EAP Re-authentication Protocol >>> >(ERP)", has >>> >> been specified that supports an EAP method-independent >>> protocol for >>> >> efficient re-authentication between the peer and the >>> server through >>> >> an authenticator. This document specifies Diameter >>> >support for ERP. >>> >> The Diameter EAP application is re-used for >>> encapsulating the newly >>> >> defined EAP Initiate and EAP Finish messages specified >>in the ERP >>> >> specification. AVPs for request and delivery of Domain >>> >Specific Root >>> >> Keys from the AAA/EAP server to the ER server are also >>specified. >>> >> Additionally, this document also specifies Diameter >>> >processing rules >>> >> relevant to ERP. >>> >> >>> >> [LM] some abusive verbiage in the abstract: >>> >> >>> >> Proposal for new abstract: >>> >> >>> >> "EAP Re-authentication Protocol defines extensions of EAP >>> >to support >>> >> efficient re-authentication between the peer and an EAP >>> >> re-authentication server through any authenticator. >>> > >>> > I'm wondering if we should note that the authenticator may be >>> >ERP-aware. >>> >I'm thinking about the case where the authenticator sends the >>> >EAP-Initiate/Re-auth-Start (Figure 4 in RFC 5296) >>> > >>> > >>> >> This document >>> >> specifies Diameter support for ERP. The Diameter EAP >>> application is >>> >> re-used for encapsulating the newly defined EAP messages >>> specified >>> >> in the ERP specification. Additionally, this document >>> also defines >>> >> specific Diameter processing rules relevant to ERP." >>> > >>> > ok >>> > >>> >> >>> >> >>> >> 1. Introduction >>> >> >>> >> RFC 4072 [1] specifies a Diameter application that carries EAP >>> >> packets between a Diameter client and the Diameter >>> >Server/EAP server. >>> >> [2] defines the EAP Re-authentication Protocol to allow >>> faster re- >>> >> authentication of a previously authenticated peer. >>> >> >>> >> [LM] s/[2] defines the EAP Re-authentication Protocol/RFC >>5296 [2] >>> >> defines the EAP Re-authentication Protocol (ERP) >>> >> >>> >> In ERP, a peer >>> >> authenticates to the network by proving possession of >>> key material >>> >> derived during a previous EAP exchange. >>> >> >>> >> [LM] s/a peer authenticate to/a peer is authenticated by >>> >> >>> >> For this purpose, an >>> >> Extended Master Session Key (EMSK) based re-authentication key >>> >> hierarchy has been defined [5]. ERP may be executed >>> between the ER >>> >> peer and an ER server in the peer's home domain or the >>> local domain >>> >> visited by the peer. In the latter case, a Domain >>> Specific Root Key >>> >> (DSRK), derived from the EMSK, is provided to the local >>domain ER >>> >> server. >>> >> >>> >> [LM] s/is provided to/is provided by the Home ER server to >>> >> >>> >> The peer and the local server subsequently use the re- >>> >> authentication key hierarchy from the DSRK to authenticate >>> >and derive >>> >> authenticator specific keys within that domain. >>> >> >>> >> [LM] this information can be found in the RFC 5296. Remove >>> >the sentence above. >>> > >>> > It may help the reader to understand the purpose of this DRSK. >>> > >>> >> >>> >> To accomplish the >>> >> reauthentication functionality, ERP defines two new EAP >>> codes - EAP >>> >> Initiate and EAP Finish. >>> >> >>> >> [LM] s/ERP defines two new EAP codes/ERP defines two new >>> EAP messages >>> > >>> > I would prefer to say that ERP defines two new EAP Codes >>> here. These >>> >newly EAP packets are then carried in messages (dependent of the >>> >protocol used). >>> > >>> >> >>> >> This document specifies the reuse of >>> >> Diameter EAP application to carry these new EAP messages. >>> >> The DSRK can be obtained as part of the regular EAP >>> exchange or as >>> >> part of an ERP bootstrapping exchange. The local ER server >>> >> requesting the DSRK needs to be in the path of the EAP or ERP >>> >> bootstrapping exchange in order to request and obtain the >>> >DSRK. This >>> >> document also specifies how the DSRK is transported to >>> the local ER >>> >> server using Diameter. >>> >> >>> >> [LM] Finally, i would reorganize the last part as follow: >>> >> >>> >> ::::::::::: >>> >> >>> >> "In ERP, a peer is authenticated by the network thanks to >>> >keying material >>> >> obtained during a previous EAP exchange. This keying >>> >material is derived >>> >> from the Extended Master Session Key (EMSK) defined in the >>> >RFC 5295 [5]. >>> >> To accomplish the EAP reauthentication functionality, ERP >>> >defines two new >>> >> EAP messages - EAP Initiate and EAP Finish. This document >>> >specifies the >>> >> reuse of Diameter EAP Application to carry these new EAP >>> messages. >>> >> >>> >> ERP is executed between the peer and a server located >>> >either in the peer's >>> >> home domain or in the local domain visited by the peer. In >>> >the latter case, >>> >> a Domain Specific Root Key (DSRK) is derived from the >>> >EMSK, as defined in >>> >> the RFC 5295 [5], and is provided by the Home EAP server >>> >to the local domain >>> >> server. For that purpose, this document specifies the >>> >transport of the DSRK >>> >> using the Diameter EAP Application." >>> > >>> > First paragraph is the old and second the new ? >>> > >>> >> >>> >> :::::::::::::: >>> >> >>> >> >>> >> >>> >> 2. Terminology >>> >> >>> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", >>> "SHALL NOT", >>> >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and >>> >"OPTIONAL" in this >>> >> document are to be interpreted as described in RFC 2119 [3]. >>> >> >>> >> This document uses terminology defined in [6], [5], >>[2], and [1]. >>> >> >>> >> >>> >> 3. Assumptions >>> >> >>> >> This document defines additional optional AVPs for >>usage with the >>> >> Diameter EAP application. Routing of these messages is >>therefore >>> >> provided via the Diameter Application Identifier (among other >>> >> elements), as specified by the Diameter Base protocol [4]. >>> >> >>> >> [LM] To avoid any ambiguity I would say: >>> >> >>> >> "This document defines only additional optional AVPs for >>> usage with >>> >> the Diameter EAP application. This document does not defined >>> >> a new Diameter application and a new Application ID is >>> >therefore not >>> >> required, as described in the Diameter Base protocol [4]." >>> > >>> > ok >>> > >>> >> >>> >> Based on >>> >> the deployment of ERP, a local Diameter server (the same entity >>> >> serves as a Diameter proxy during the full EAP >>> authentication) may >>> >> play the role of the ER server for future >>> >re-authentication attempts. >>> >> As such, the local Diameter server requesting the DSRK >>> >needs to be in >>> >> the path of the current EAP exchange between the peer >>and the EAP >>> >> server and also along in the future. The Diameter client is >>> >> furthermore assumed to be able to route the re-authentication >>> >> messages to the ER server. >>> >> >>> >> [LM] I think that the assumption all along this document is >>> >that the local ER server and the AAA agent are co-located, >>> to be able >>> >to rely on DEA for the transport of DSRK. In that case, I >>would say >>> >something like: >>> >> >>> >> "In this document, when EAP re-authentication is performed >>> >in the domain >>> >> visited by the peer, it is assumed that the local ER >>> >server is co-located >>> >> with a Diameter agent in the visited domain present in >>> >the path of the full >>> >> EAP exchange." >>> > >>> > ok >>> > >>> >> >>> >> >>> >> 4. Diameter Support for ERP >>> >> >>> >> 4.1. Protocol Overview >>> >> >>> >> Diameter may be used to transport ERP messages between the NAS >>> >> (authenticator) and an authentication server (ER server). >>> >> >>> >> [LM] s/may/is (the use of Diameter is a pre-requisite in >>> this draft) >>> >> >>> >> In ERP, the peer sends an EAP Initiate Reauth message to the ER >>> >> server via the authenticator. >>> >> >>> >> [LM] s/"EAP Initiate Reauth message"/"EAP-Initiate/Re-auth >>> message" >>> >> (same all along the document) >>> >> >>> >> Alternatively, the NAS may send an EAP >>> >> Initiate Reauth-Start message to the peer to trigger >>the start of >>> >> ERP; the peer then responds with an EAP Initiate Reauth >>> message to >>> >> the NAS. >>> >> >>> >> [LM] s/"EAP Initiate Reauth-Start >>> >message"/"EAP-Initiate/Re-auth-Start >>> >> message" (same all along the document) >>> >> >>> >> The general guidelines for encapsulating EAP messages >>in Diameter >>> >> from RFC 4072 [1] apply to the new EAP messages defined >>> for ERP as >>> >> well. The EAP Initiate Reauth message is encapsulated >>in an EAP- >>> >> Payload AVP of a Diameter EAP-Request message by the NAS >>> >and sent to >>> >> the Diameter server. The NAS MUST copy the contents of >>the value >>> >> field of the 'rIKName as NAI' TLV or the peer-id TLV (when >>> >the former >>> >> is not present) of the EAP Initiate Reauth message into >>> a User-Name >>> >> AVP of the Diameter EAP-Request. >>> >> >>> >> [LM] I think that we are talking about the 'keyName-NAI' TLV >>> >and not anymore the 'rIKName as NAI' TLV. >>> > >>> > Considering section 5.3.2 of RFC 5296. I agree. >>> > >>> >>Moreover, in which case the peer-id TLV would not be >>> present for ERP? >>> > >>> > Privacy ? >>> > >>> >> >>> >> The ER server processes the EAP Initiate Reauth message in >>> >accordance >>> >> with [2], and if that is successful, it responds with an >>> EAP Finish >>> >> Reauth message indicating a success ('R' flag set to 0). The >>> >> Diameter server MUST encapsulate the EAP Finish Reauth >>> message with >>> >> the R flag set to zero in an EAP-Payload AVP attribute of >>> >a Diameter >>> >> EAP-Answer message. An EAP-Master-Session-Key AVP >>> included in the >>> >> Diameter EAP-Answer contains the Re-authentication Master >>> >Session Key >>> >> (rMSK). The Diameter Result Code, if any, SHOULD be a >>> >success Result >>> >> Code. >>> >> >>> >> If the processing of the EAP Initiate Reauth message >>> resulted in a >>> >> failure, the Diameter server MUST encapsulate an EAP >>> Finish Reauth >>> >> message indicating failure ('R' flag set to 1) in an >>> >EAP-Payload AVP >>> >> of a Diameter EAP-Answer message. The Diameter Result >>> >Code, if any, >>> >> SHOULD be a failure Result Code. Whether an EAP Finish Reauth >>> >> message is sent at all is specified in [2]. >>> >> >>> >> [LM] the use of the 'R' flag is not relevant for Diameter EAP. >>> >> [LM] according to the RFC, the EAP-Finish/Re-auth is sent >>> >back in any case, success or failure. >>> >> [LM] according to the above comments, I would rephrase the >>> >text as follow: >>> >> >>> >> >>> >> "The ER server processes the EAP Initiate Reauth message >>> >in accordance >>> >> with [2] and responds with an EAP-Finish/Re-auth message. >>> >The Diameter >>> >> server MUST encapsulate the EAP-Finish/Re-auth message within an >>> >> EAP-Payload AVP of a Diameter EAP-Answer message. >>> >> In an EAP re-authentication successful case, an >>> >EAP-Master-Session-Key >>> >> AVP is included in the Diameter EAP-Answer message that >>> >contains the >>> >> Re-authentication Master Session Key (rMSK). The Diameter >>> >Result-Code >>> >> SHOULD be a success Result-Code. >>> >> In an EAP re-authentication failure case, the Diameter >>> >Result-Code of >>> >> the a Diameter EAP-Answer message SHOULD be a failure >>> >Result-Code and >>> >> no EAP-Master-Session-Key AVP is present." >>> >> >>> >> [LM] By the way, I don't understand the "SHOULD" for the >>> >result-code. Any reason not to use "MUST" here? >>> > >>> > I think a MUST would be better. Different views ? >>> > >>> >> [LM] a figure could be added for illustration here. >>> >> >>> >> 4.2. DSRK Request and Delivery >>> >> >>> >> A local ER server, collocated with a Diameter proxy in >>the peer's >>> >> visited domain, >>> >> >>> >> [LM] s/in the peer's visited domain/in the domain visited >>> by the peer >>> >> >>> >> may request a DSRK from the EAP server, either in the >>> >> initial EAP exchange (implicit bootstrapping) or in an ERP >>> >> bootstrapping exchange (explicit bootstrapping). It >>does this by >>> >> including the EAP-DSRK-Request AVP in the Diameter EAP-Response >>> >> message. The EAP-DSRK-Request AVP contains the domain or server >>> >> identity required to derive the DSRK. >>> >> >>> >> [LM] the EAP-DSRK-Request AVP is included in the Diameter >>> >EAP-Request >>> >> (and not in the response) >>> > >>> > yes. >>> > >>> >> >>> >> An EAP server MAY send the DSRK when it receives a >>valid Diameter >>> >> EAP-Request message containing an EAP-DSRK-Request AVP. >>> >An ER server >>> >> MUST send the DSRK (or send a failure result) when it receives a >>> >> valid Diameter EAP-Request message containing an >>> >EAP-DSRK-Request AVP >>> >> along with a valid EAP Initiate Re-auth packet with the >>> >bootstrapping >>> >> flag turned on. If an EAP-DSRK-Request AVP is included in >>> >any other >>> >> Diameter EAP-Request message, the Diameter server MUST >>> reply with a >>> >> failure result. An EAP-DSRK AVP MUST be used to send a >>> >DSRK; an EAP- >>> >> DSRK-Name AVP MUST be used to send the DSRK's keyname; >>> and an EAP- >>> >> DSRK-Lifetime AVP MUST be used to send the DSRK's lifetime. >>> >> >>> >> [LM] I don't understand the intention of the above text. >>> >Could it be enough to say: >>> >> >>> >> In successful case, the DSRK is carried by the EAP-DSRK >>> AVP in the >>> >> Diameter EAP response message. Along with the EAP-DSRK AVP, an >>> >> EAP-DSRK-Name AVP MUST be used to send the DSRK's keyname and an >>> >> EAP-DSRK-Lifetime AVP MUST be used to send the DSRK's lifetime. >>> > >>> > Agree. >>> > >>> >> >>> >> [LM] a figure could be added for illustration here. >>> >> >>> >> 5. Command Codes >>> >> >>> >> [LM] this section is not required as there is nothing >>> >specific for ERP. We should skip it. >>> >> >>> >> [SKIP] >>> >> >>> >> >>> >> 6. Attribute Value Pair Definitions >>> >> >>> >> 6.1. EAP-DSRK-Request AVP >>> >> >>> >> The EAP-DSRK AVP (AVP Code TBD) is of type DiameterIdentity. >>> >> >>> >> [LM] s/EAP-DSRK AVP/EAP-DSRK-Request AVP >>> >> >>> >> This >>> >> AVP fulfills two purposes: First, it indicates that a ER >>> server is >>> >> located in the local domain that is willing to play the >>> >role of an ER >>> >> server for a particular session. Second, it conveys information >>> >> about the domain and ER server identity to the >>> Diameter/EAP server. >>> >> >>> >> [LM] the use of this AVP is explained above. There is no >>> >need to explain again. >>> > >>> > As we are in the AVP Definitions, I think it is better to >>keep some >>> >text explaining it. No ? >>> > >>> >> Moreover, if a DiameterIdentity is used, it is to indicate a >>> >server and not a domain. Right? >>> > >>> > In my understanding the local ER server only sends the Domain Name >>> >which will then be used to compute keys. Maybe the type >>> >DiameterIdentity is not appropriated and we should use UTF8String >>> >instead. What do you think ? >>> > >>> > >>> >> >>> >> 6.2. EAP-DSRK AVP >>> >> >>> >> The EAP-DSRK AVP (AVP Code TBD) is of type OctetString. >>> The Domain >>> >> Specific Root Key (DSRK) is carried in this payload. >>> >> >>> >> 6.3. EAP-DSRK-Name AVP >>> >> >>> >> The EAP-DSRK-Name AVP (AVP Code TBD) is of type >>> OctetString. This >>> >> AVP contains the name of the DSRK key that is later used >>> during the >>> >> re-authentication exchange to select the correct DSRK. >>> >> >>> >> [LM] skip the part starting by "that is..." >>> > >>> > ok >>> > >>> >> >>> >> 6.4. EAP-DSRK-Lifetime AVP >>> >> >>> >> The EAP-DSRK-Lifetime AVP (AVP Code TBD) is of type >>> Unsigned64 and >>> >> contains the DSRK lifetime in seconds. >>> >> >>> >> >>> >> 7. AVP Occurrence Table >>> >> >>> >> The following table lists the AVPs that may optionally be >>> >present in >>> >> the DER and DEA commands [1]. >>> >> >>> >> >>> >> +---------------+ >>> >> | Command-Code | >>> >> +-+-----+-----+-+ >>> >> Attribute Name | DER | DEA | >>> >> -------------------------------|-----+-----+ >>> >> EAP-DSRK-Request | 0-1 | 0 | >>> >> EAP-DSRK | 0 | 0-1 | >>> >> EAP-DSRK-Name | 0 | 0-1 | >>> >> EAP-DSRK-Lifetime | 0 | 0-1 | >>> >> +-----+-----+ >>> >> >>> >> Figure 4: DER and DEA Commands AVP Table >>> >> >>> >> When the EAP-DSRK AVP is present in the DEA then the >>> EAP-DSRK-Name >>> >> and the EAP-DSRK-Lifetime MUST also be present. >>> >> >>> >> >>> >> 8. AVP Flag Rules >>> >> >>> >> The following table describes the Diameter AVPs, their AVP Code >>> >> values, types, possible flag values, and whether the AVP MAY be >>> >> encrypted. The Diameter base [4] specifies the AVP Flag >>> rules for >>> >> AVPs in Section 4.5. >>> >> >>> >> >>> >> +---------------------+ >>> >> | AVP Flag Rules | >>> >> >>> >+----+-----+----+-----+----+ >>> >> AVP Section | | >>> >|SHLD|MUST | | >>> >> Attribute Name Code Defined Data Type |MUST| MAY |NOT >>> >|NOT |Encr| >>> >> >>> >------------------------------------------+----+-----+----+-- >>> ---+----+ >>> >> EAP-DSRK-Request TBD 4.7.1 DiamIdent | | P | | >>> >V,M | Y | >>> >> EAP-DSRK TBD 4.7.2 OctetString| | P | | >>> >V,M | Y | >>> >> EAP-DSRK-Name TBD 4.7.3 OctetString| | P | | >>> >V,M | Y | >>> >> EAP-DSRK-Lifetime TBD 4.7.4 Unsigned64 | | P | | >>> >V,M | Y | >>> >> >>> >> >>> >------------------------------------------+----+-----+----+-- >>> ---+----+ >>> >> >>> >> Due to space constraints, the short form DiamIdent is used to >>> >> represent DiameterIdentity. >>> >> >>> >> Figure 5: AVP Flag Rules Table >>> >> >>> >> [LM] this table is ok according to the current RFC 3588. I >>> >don't know how to deal with it regarding the RFC3588bis... >>> > >>> > >>> > That's indeed a good question :). >>> > >>> > And that's all for my comments of your comments. >>> > >>> > Regards, >>> > >>> > --Julien-- >>> >_______________________________________________ >>> >DiME mailing list >>> >DiME@ietf.org >>> >https://www.ietf.org/mailman/listinfo/dime >>> > >>> >> > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jan 9 02:30:02 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03E523A693A; Fri, 9 Jan 2009 02:30:02 -0800 (PST) X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2B0803A693A; Fri, 9 Jan 2009 02:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090109103001.2B0803A693A@core3.amsl.com> Date: Fri, 9 Jan 2009 02:30:01 -0800 (PST) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-mip6-integrated-12.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: , Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --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 Mobile IPv6: Support for Network Access Server to Diameter Server Interaction Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-mip6-integrated-12.txt Pages : 18 Date : 2009-01-09 A Mobile IPv6 node requires a home agent address, a home address, and a security association with its home agent before it can start utilizing Mobile IPv6. RFC 3775 requires that some or all of these parameters are statically configured. Mobile IPv6 bootstrapping work aims to make this information dynamically available to the Mobile Node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing authentication, authorization and accounting infrastructure. This document describes MIPv6 bootstrapping using the Diameter Network Access Server to home Authentication, Authorization and Accounting server interface. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-integrated-12.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-mip6-integrated-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-09022234.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Fri Jan 9 02:53:48 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAD113A692C; Fri, 9 Jan 2009 02:53:48 -0800 (PST) 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 D026A3A68C9 for ; Fri, 9 Jan 2009 02:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=-0.940, 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 cxH8NH7omEje for ; Fri, 9 Jan 2009 02:53:45 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id C48843A6994 for ; Fri, 9 Jan 2009 02:53:44 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n09ArN8X026876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 9 Jan 2009 11:53:23 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n09ArIIH005554; Fri, 9 Jan 2009 11:53:23 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Jan 2009 11:53:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 Jan 2009 12:53:50 +0200 Message-ID: In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB0260622C5AD@ftrdmel2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Review of the Diameter ERP draft Thread-Index: AclxenKpDp1tiH+tR5acfa7D++IC0QAFZFSQAA+E7ZAAGGn/YAABPrzgAATsNVA= References: <7DBAFEC6A76F3E42817DF1EBE64CB026061E2759@ftrdmel2> <5e2406980901080218w746b69a7x320f1501aeb97266@mail.gmail.com> <7DBAFEC6A76F3E42817DF1EBE64CB0260622C4DE@ftrdmel2> <7DBAFEC6A76F3E42817DF1EBE64CB0260622C5AD@ftrdmel2> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: , , , X-OriginalArrivalTime: 09 Jan 2009 10:53:21.0922 (UTC) FILETIME=[7D1FD620:01C97248] Subject: Re: [Dime] Review of the Diameter ERP 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Good to have you guys to figure out how all this is going to work. = Ciao Hannes PS: I will have to re-read the ERP spec to come to my own conclusion on thi= s issue. = >-----Original Message----- >From: ext lionel.morand@orange-ftgroup.com = >[mailto:lionel.morand@orange-ftgroup.com] = >Sent: 09 January, 2009 11:07 >To: Tschofenig, Hannes (NSN - FI/Espoo); = >julien.bournelle@gmail.com; sdecugis@hongo.wide.ad.jp; dime@ietf.org >Subject: RE: [Dime] Review of the Diameter ERP draft > >I understand. > >However, I don't see how the use of a new appli-ID will solve = >this issue if you have multiple AAA proxies supporting ERP in = >the same visited domain. If you reach a new AAA proxy that has = >not yet the DSRK, it will have to contact anyway the home EAP = >server to retrieve this key. >For me, ERP with a local ER server will be useful for peers = >connected to the same EAP authenticator for a long time or if = >several EAP authenticators are connected to the same AAA = >proxy. And in the latter case, it is just an architectural issue. > >BR, > >Lionel > > >> -----Message d'origine----- >> De : Tschofenig, Hannes (NSN - FI/Espoo) = >> [mailto:hannes.tschofenig@nsn.com] >> Envoy=E9 : vendredi 9 janvier 2009 08:58 =C0 : MORAND Lionel = >RD-CORE-ISS; = >> julien.bournelle@gmail.com; sdecugis@hongo.wide.ad.jp; dime@ietf.org = >> Objet : RE: [Dime] Review of the Diameter ERP draft >> = >> My reading of this text is that there is a way for the peer and the = >> authenticator to figure out whether to use EAP or ERP. >> It, however, says very little about the further routing of AAA = >> messages in such a way that the messages traverse nodes = >understanding = >> the additionally required functionality. If I understood ERP = >correctly = >> then some key caching takes place in the AAA proxies and hence one = >> wants to make sure that the messages are actually routed via these = >> proxies. >> = >> Ciao >> Hannes >> = >> = >> >-----Original Message----- >> >From: ext lionel.morand@orange-ftgroup.com = >> >[mailto:lionel.morand@orange-ftgroup.com] >> >Sent: 08 January, 2009 22:26 >> >To: Tschofenig, Hannes (NSN - FI/Espoo); = >julien.bournelle@gmail.com; = >> >sdecugis@hongo.wide.ad.jp; dime@ietf.org >> >Subject: RE: [Dime] Review of the Diameter ERP draft >> > >> >According to the RFC 5296, it seems that it is not required >> to have a >> >specific Appl-ID: >> > >> > "It is plausible that the authenticator does not know whether the = >> >peer >> > supports ERP and whether the peer has performed a full EAP >> > authentication through another authenticator. The >> authenticator MAY >> > initiate the ERP exchange by sending the >> EAP-Initiate/Re-auth-Start >> > message, and if there is no response, it will send the >> EAP-Request/ >> > Identity message. Note that this avoids having two EAP >> messages in >> > flight at the same time [2]. The authenticator may send the EAP- >> > Initiate/Re-auth-Start message and wait for a short, locally >> > configured amount of time. If the peer does not already >> know, this >> > message indicates to the peer that the authenticator = >supports ERP. >> > In response to this trigger from the authenticator, the peer can >> > initiate the ERP exchange by sending an EAP-Initiate/Re-auth = >> >message. >> > If there is no response from the peer after the necessary >> > retransmissions (see Section 6), the authenticator MUST >> initiate EAP >> > by sending an EAP-Request message, typically the = >> >EAP-Request/Identity >> > message. Note that the authenticator may receive an = >EAP-Initiate/ >> > Re-auth message after it has sent an = >EAP-Request/Identity message. >> > If the authenticator supports ERP, it MUST proceed with the ERP >> > exchange. When the EAP-Request/Identity times out, the = >> >authenticator >> > MUST NOT close the connection if an ERP exchange is in = >progress or >> > has already succeeded in establishing a re-authentication MSK. >> > >> > If the authenticator does not support ERP, it drops EAP-Initiate/ >> > Re-auth messages [2] as the EAP code of those packets is greater = >> >than >> > 4. An ERP-capable peer will exhaust the EAP-Initiate/Re-auth = >> >message >> > retransmissions and fall back to EAP authentication by >> responding to >> > EAP Request/Identity messages from the authenticator. = >If the peer >> > does not support ERP or if it does not have unexpired = >key material >> > from a previous EAP authentication, it drops EAP-Initiate/ >> > Re-auth-Start messages. If there is no response to the = >> >EAP-Initiate/ >> > Re-auth-Start message, the authenticator SHALL send an = >EAP Request >> > message (typically EAP Request/Identity) to start EAP = >> >authentication. >> > From this stage onwards, RFC 3748 rules apply. Note = >that this may >> > introduce some delay in starting EAP. In some lower layers, the >> > delay can be minimized or even avoided by the peer >> initiating EAP by >> > sending messages such as EAPoL-Start in the IEEE 802.1X = >> >specification >> > [10]." >> > >> >Both paragraphs assume (for me) that the ERP "option" may be >> supported >> >by the peer and/or the network. If none of them (or only one >> of them) >> >support ERP, the fallback mechanism is full EAP authentication. >> >In that sense, knowing that the network supports ERP is not a = >> >pre-requisite. The minimum is to support EAP and ERP is an option = >> >available above EAP. That allows to deploy ERP above existing EAP = >> >deployment. >> > >> >Does it make sense? >> > >> >Best Regards, >> > >> >Lionel >> > >> > >> >> -----Message d'origine----- >> >> De : Tschofenig, Hannes (NSN - FI/Espoo) = >> >> [mailto:hannes.tschofenig@nsn.com] >> >> Envoy=E9 : jeudi 8 janvier 2009 13:55 =C0 : ext Julien Bournelle; = >> >> MORAND Lionel RD-CORE-ISS; Sebastien Decugis; = >dime@ietf.org Objet : = >> >> RE: [Dime] Review of the >> Diameter ERP >> >> draft >> >> = >> >> One of the things I was not quite sure with the current protocol = >> >> design is whether a Diameter application or just a bunch >> of AVPs are >> >> required. >> >> Based on the discussions a few of us when some of the HOKEY >> >specs went >> >> to the IESG / IETF Last Call I got the impression that one has to = >> >> define a new Diameter application (which would be based = >on Diameter >> >> EAP) since you assume that the messages are routed via a >> node in the >> >> local network and the support for ERP has to be ensured. >> >> = >> >> Ciao >> >> Hannes >> >> = >> >> >-----Original Message----- >> >> >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] >> >> On Behalf Of >> >> >ext Julien Bournelle >> >> >Sent: 08 January, 2009 12:18 >> >> >To: lionel.morand@orange-ftgroup.com; Sebastien Decugis; >> >> dime@ietf.org >> >> >Subject: Re: [Dime] Review of the Diameter ERP draft >> >> > >> >> >Hi lionel, >> >> > >> >> > some comments inline. >> >> > >> >> >On Wed, Jan 7, 2009 at 12:03 PM, >> >> > wrote: >> >> >> >> >> >> Hi, >> >> >> >> >> >> Here is my review for the Diameter ERP draft. >> >> >> >> >> >> General comments: >> >> >> >> >> >> - About alignment with RFC 5296: >> >> >> the draft needs to be updated according to the publication >> >> >of the RFC 5296. Some proposals are provided below. >> >> >> >> >> >> - About ER server/AAA agent co-location: >> >> >> In my understanding, it is assumed in this document ER >> >> >server and AAA proxy have to be co-located to be able to rely on = >> >> >Diameter to transport ERP specific AVPs. This doesn't maybe >> >preclude >> >> >other architectural choices but there are outside the >> scope of this >> >> >document. It is necessary to clarify this point in this document. >> >> >> >> >> >> - ERP support discovery: >> >> >> As the ERP specific AVPs are introduced with the M-bit >> >> >cleared, these AVPs are purely optional for the Diameter EAP = >> >> >application i.e. they can be silently ignored by Diameter >> >> servers that >> >> >do not understand this new AVPs. Some text should be provided to = >> >> >describe how the local ER server discovers that the Home >> EAP server >> >> >doesn't support ERP and the behaviour of the local ER >> >server in that >> >> >case. >> >> > >> >> > >> >> > I agree with these general comments. >> >> > >> >> > >> >> >> >> >> >> Hereafter is the rest of my review with comments and proposals. >> >> >> >> >> >> Best Regards, >> >> >> >> >> >> Lionel >> >> >> >> >> >> *************************************** >> >> >> >> >> >> Abstract >> >> >> >> >> >> An EAP extension, called "EAP Re-authentication Protocol >> >> >(ERP)", has >> >> >> been specified that supports an EAP method-independent >> >> protocol for >> >> >> efficient re-authentication between the peer and the >> >> server through >> >> >> an authenticator. This document specifies Diameter >> >> >support for ERP. >> >> >> The Diameter EAP application is re-used for >> >> encapsulating the newly >> >> >> defined EAP Initiate and EAP Finish messages specified >> >in the ERP >> >> >> specification. AVPs for request and delivery of Domain >> >> >Specific Root >> >> >> Keys from the AAA/EAP server to the ER server are also >> >specified. >> >> >> Additionally, this document also specifies Diameter >> >> >processing rules >> >> >> relevant to ERP. >> >> >> >> >> >> [LM] some abusive verbiage in the abstract: >> >> >> >> >> >> Proposal for new abstract: >> >> >> >> >> >> "EAP Re-authentication Protocol defines extensions of EAP >> >> >to support >> >> >> efficient re-authentication between the peer and an EAP >> >> >> re-authentication server through any authenticator. >> >> > >> >> > I'm wondering if we should note that the authenticator may be = >> >> >ERP-aware. >> >> >I'm thinking about the case where the authenticator sends the = >> >> >EAP-Initiate/Re-auth-Start (Figure 4 in RFC 5296) >> >> > >> >> > >> >> >> This document >> >> >> specifies Diameter support for ERP. The Diameter EAP >> >> application is >> >> >> re-used for encapsulating the newly defined EAP messages >> >> specified >> >> >> in the ERP specification. Additionally, this document >> >> also defines >> >> >> specific Diameter processing rules relevant to ERP." >> >> > >> >> > ok >> >> > >> >> >> >> >> >> >> >> >> 1. Introduction >> >> >> >> >> >> RFC 4072 [1] specifies a Diameter application that = >carries EAP >> >> >> packets between a Diameter client and the Diameter >> >> >Server/EAP server. >> >> >> [2] defines the EAP Re-authentication Protocol to allow >> >> faster re- >> >> >> authentication of a previously authenticated peer. >> >> >> >> >> >> [LM] s/[2] defines the EAP Re-authentication Protocol/RFC >> >5296 [2] >> >> >> defines the EAP Re-authentication Protocol (ERP) >> >> >> >> >> >> In ERP, a peer >> >> >> authenticates to the network by proving possession of >> >> key material >> >> >> derived during a previous EAP exchange. >> >> >> >> >> >> [LM] s/a peer authenticate to/a peer is authenticated by >> >> >> >> >> >> For this purpose, an >> >> >> Extended Master Session Key (EMSK) based = >re-authentication key >> >> >> hierarchy has been defined [5]. ERP may be executed >> >> between the ER >> >> >> peer and an ER server in the peer's home domain or the >> >> local domain >> >> >> visited by the peer. In the latter case, a Domain >> >> Specific Root Key >> >> >> (DSRK), derived from the EMSK, is provided to the local >> >domain ER >> >> >> server. >> >> >> >> >> >> [LM] s/is provided to/is provided by the Home ER server to >> >> >> >> >> >> The peer and the local server subsequently use the re- >> >> >> authentication key hierarchy from the DSRK to authenticate >> >> >and derive >> >> >> authenticator specific keys within that domain. >> >> >> >> >> >> [LM] this information can be found in the RFC 5296. Remove >> >> >the sentence above. >> >> > >> >> > It may help the reader to understand the purpose of this DRSK. >> >> > >> >> >> >> >> >> To accomplish the >> >> >> reauthentication functionality, ERP defines two new EAP >> >> codes - EAP >> >> >> Initiate and EAP Finish. >> >> >> >> >> >> [LM] s/ERP defines two new EAP codes/ERP defines two new >> >> EAP messages >> >> > >> >> > I would prefer to say that ERP defines two new EAP Codes >> >> here. These >> >> >newly EAP packets are then carried in messages (dependent of the = >> >> >protocol used). >> >> > >> >> >> >> >> >> This document specifies the reuse of >> >> >> Diameter EAP application to carry these new EAP messages. >> >> >> The DSRK can be obtained as part of the regular EAP >> >> exchange or as >> >> >> part of an ERP bootstrapping exchange. The local ER server >> >> >> requesting the DSRK needs to be in the path of the EAP or ERP >> >> >> bootstrapping exchange in order to request and obtain the >> >> >DSRK. This >> >> >> document also specifies how the DSRK is transported to >> >> the local ER >> >> >> server using Diameter. >> >> >> >> >> >> [LM] Finally, i would reorganize the last part as follow: >> >> >> >> >> >> ::::::::::: >> >> >> >> >> >> "In ERP, a peer is authenticated by the network thanks to >> >> >keying material >> >> >> obtained during a previous EAP exchange. This keying >> >> >material is derived >> >> >> from the Extended Master Session Key (EMSK) defined in the >> >> >RFC 5295 [5]. >> >> >> To accomplish the EAP reauthentication functionality, ERP >> >> >defines two new >> >> >> EAP messages - EAP Initiate and EAP Finish. This document >> >> >specifies the >> >> >> reuse of Diameter EAP Application to carry these new EAP >> >> messages. >> >> >> >> >> >> ERP is executed between the peer and a server located >> >> >either in the peer's >> >> >> home domain or in the local domain visited by the peer. In >> >> >the latter case, >> >> >> a Domain Specific Root Key (DSRK) is derived from the >> >> >EMSK, as defined in >> >> >> the RFC 5295 [5], and is provided by the Home EAP server >> >> >to the local domain >> >> >> server. For that purpose, this document specifies the >> >> >transport of the DSRK >> >> >> using the Diameter EAP Application." >> >> > >> >> > First paragraph is the old and second the new ? >> >> > >> >> >> >> >> >> :::::::::::::: >> >> >> >> >> >> >> >> >> >> >> >> 2. Terminology >> >> >> >> >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", >> >> "SHALL NOT", >> >> >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and >> >> >"OPTIONAL" in this >> >> >> document are to be interpreted as described in RFC 2119 [3]. >> >> >> >> >> >> This document uses terminology defined in [6], [5], >> >[2], and [1]. >> >> >> >> >> >> >> >> >> 3. Assumptions >> >> >> >> >> >> This document defines additional optional AVPs for >> >usage with the >> >> >> Diameter EAP application. Routing of these messages is >> >therefore >> >> >> provided via the Diameter Application Identifier (among other >> >> >> elements), as specified by the Diameter Base protocol [4]. >> >> >> >> >> >> [LM] To avoid any ambiguity I would say: >> >> >> >> >> >> "This document defines only additional optional AVPs for >> >> usage with >> >> >> the Diameter EAP application. This document does not defined >> >> >> a new Diameter application and a new Application ID is >> >> >therefore not >> >> >> required, as described in the Diameter Base protocol [4]." >> >> > >> >> > ok >> >> > >> >> >> >> >> >> Based on >> >> >> the deployment of ERP, a local Diameter server (the >> same entity >> >> >> serves as a Diameter proxy during the full EAP >> >> authentication) may >> >> >> play the role of the ER server for future >> >> >re-authentication attempts. >> >> >> As such, the local Diameter server requesting the DSRK >> >> >needs to be in >> >> >> the path of the current EAP exchange between the peer >> >and the EAP >> >> >> server and also along in the future. The Diameter client is >> >> >> furthermore assumed to be able to route the re-authentication >> >> >> messages to the ER server. >> >> >> >> >> >> [LM] I think that the assumption all along this document is >> >> >that the local ER server and the AAA agent are co-located, >> >> to be able >> >> >to rely on DEA for the transport of DSRK. In that case, I >> >would say >> >> >something like: >> >> >> >> >> >> "In this document, when EAP re-authentication is performed >> >> >in the domain >> >> >> visited by the peer, it is assumed that the local ER >> >> >server is co-located >> >> >> with a Diameter agent in the visited domain present in >> >> >the path of the full >> >> >> EAP exchange." >> >> > >> >> > ok >> >> > >> >> >> >> >> >> >> >> >> 4. Diameter Support for ERP >> >> >> >> >> >> 4.1. Protocol Overview >> >> >> >> >> >> Diameter may be used to transport ERP messages = >between the NAS >> >> >> (authenticator) and an authentication server (ER server). >> >> >> >> >> >> [LM] s/may/is (the use of Diameter is a pre-requisite in >> >> this draft) >> >> >> >> >> >> In ERP, the peer sends an EAP Initiate Reauth message >> to the ER >> >> >> server via the authenticator. >> >> >> >> >> >> [LM] s/"EAP Initiate Reauth message"/"EAP-Initiate/Re-auth >> >> message" = >> >> >> (same all along the document) >> >> >> >> >> >> Alternatively, the NAS may send an EAP >> >> >> Initiate Reauth-Start message to the peer to trigger >> >the start of >> >> >> ERP; the peer then responds with an EAP Initiate Reauth >> >> message to >> >> >> the NAS. >> >> >> >> >> >> [LM] s/"EAP Initiate Reauth-Start >> >> >message"/"EAP-Initiate/Re-auth-Start >> >> >> message" (same all along the document) >> >> >> >> >> >> The general guidelines for encapsulating EAP messages >> >in Diameter >> >> >> from RFC 4072 [1] apply to the new EAP messages defined >> >> for ERP as >> >> >> well. The EAP Initiate Reauth message is encapsulated >> >in an EAP- >> >> >> Payload AVP of a Diameter EAP-Request message by the NAS >> >> >and sent to >> >> >> the Diameter server. The NAS MUST copy the contents of >> >the value >> >> >> field of the 'rIKName as NAI' TLV or the peer-id TLV (when >> >> >the former >> >> >> is not present) of the EAP Initiate Reauth message into >> >> a User-Name >> >> >> AVP of the Diameter EAP-Request. >> >> >> >> >> >> [LM] I think that we are talking about the 'keyName-NAI' TLV >> >> >and not anymore the 'rIKName as NAI' TLV. >> >> > >> >> > Considering section 5.3.2 of RFC 5296. I agree. >> >> > >> >> >>Moreover, in which case the peer-id TLV would not be >> >> present for ERP? >> >> > >> >> > Privacy ? >> >> > >> >> >> >> >> >> The ER server processes the EAP Initiate Reauth message in >> >> >accordance >> >> >> with [2], and if that is successful, it responds with an >> >> EAP Finish >> >> >> Reauth message indicating a success ('R' flag set to 0). The >> >> >> Diameter server MUST encapsulate the EAP Finish Reauth >> >> message with >> >> >> the R flag set to zero in an EAP-Payload AVP attribute of >> >> >a Diameter >> >> >> EAP-Answer message. An EAP-Master-Session-Key AVP >> >> included in the >> >> >> Diameter EAP-Answer contains the Re-authentication Master >> >> >Session Key >> >> >> (rMSK). The Diameter Result Code, if any, SHOULD be a >> >> >success Result >> >> >> Code. >> >> >> >> >> >> If the processing of the EAP Initiate Reauth message >> >> resulted in a >> >> >> failure, the Diameter server MUST encapsulate an EAP >> >> Finish Reauth >> >> >> message indicating failure ('R' flag set to 1) in an >> >> >EAP-Payload AVP >> >> >> of a Diameter EAP-Answer message. The Diameter Result >> >> >Code, if any, >> >> >> SHOULD be a failure Result Code. Whether an EAP = >Finish Reauth >> >> >> message is sent at all is specified in [2]. >> >> >> >> >> >> [LM] the use of the 'R' flag is not relevant for Diameter EAP. >> >> >> [LM] according to the RFC, the EAP-Finish/Re-auth is sent >> >> >back in any case, success or failure. >> >> >> [LM] according to the above comments, I would rephrase the >> >> >text as follow: >> >> >> >> >> >> >> >> >> "The ER server processes the EAP Initiate Reauth message >> >> >in accordance >> >> >> with [2] and responds with an EAP-Finish/Re-auth message. = >> >> >The Diameter >> >> >> server MUST encapsulate the EAP-Finish/Re-auth >> message within an >> >> >> EAP-Payload AVP of a Diameter EAP-Answer message. >> >> >> In an EAP re-authentication successful case, an >> >> >EAP-Master-Session-Key >> >> >> AVP is included in the Diameter EAP-Answer message that >> >> >contains the >> >> >> Re-authentication Master Session Key (rMSK). The Diameter >> >> >Result-Code >> >> >> SHOULD be a success Result-Code. >> >> >> In an EAP re-authentication failure case, the Diameter >> >> >Result-Code of >> >> >> the a Diameter EAP-Answer message SHOULD be a failure >> >> >Result-Code and >> >> >> no EAP-Master-Session-Key AVP is present." >> >> >> >> >> >> [LM] By the way, I don't understand the "SHOULD" for the >> >> >result-code. Any reason not to use "MUST" here? >> >> > >> >> > I think a MUST would be better. Different views ? >> >> > >> >> >> [LM] a figure could be added for illustration here. >> >> >> >> >> >> 4.2. DSRK Request and Delivery >> >> >> >> >> >> A local ER server, collocated with a Diameter proxy in >> >the peer's >> >> >> visited domain, >> >> >> >> >> >> [LM] s/in the peer's visited domain/in the domain visited >> >> by the peer >> >> >> >> >> >> may request a DSRK from the EAP server, either in the >> >> >> initial EAP exchange (implicit bootstrapping) or in an ERP >> >> >> bootstrapping exchange (explicit bootstrapping). It >> >does this by >> >> >> including the EAP-DSRK-Request AVP in the Diameter >> EAP-Response >> >> >> message. The EAP-DSRK-Request AVP contains the >> domain or server >> >> >> identity required to derive the DSRK. >> >> >> >> >> >> [LM] the EAP-DSRK-Request AVP is included in the Diameter >> >> >EAP-Request >> >> >> (and not in the response) >> >> > >> >> > yes. >> >> > >> >> >> >> >> >> An EAP server MAY send the DSRK when it receives a >> >valid Diameter >> >> >> EAP-Request message containing an EAP-DSRK-Request AVP. = >> >> >An ER server >> >> >> MUST send the DSRK (or send a failure result) when it >> receives a >> >> >> valid Diameter EAP-Request message containing an >> >> >EAP-DSRK-Request AVP >> >> >> along with a valid EAP Initiate Re-auth packet with the >> >> >bootstrapping >> >> >> flag turned on. If an EAP-DSRK-Request AVP is included in >> >> >any other >> >> >> Diameter EAP-Request message, the Diameter server MUST >> >> reply with a >> >> >> failure result. An EAP-DSRK AVP MUST be used to send a >> >> >DSRK; an EAP- >> >> >> DSRK-Name AVP MUST be used to send the DSRK's keyname; >> >> and an EAP- >> >> >> DSRK-Lifetime AVP MUST be used to send the DSRK's lifetime. >> >> >> >> >> >> [LM] I don't understand the intention of the above text. = >> >> >Could it be enough to say: >> >> >> >> >> >> In successful case, the DSRK is carried by the EAP-DSRK >> >> AVP in the >> >> >> Diameter EAP response message. Along with the = >EAP-DSRK AVP, an >> >> >> EAP-DSRK-Name AVP MUST be used to send the DSRK's >> keyname and an >> >> >> EAP-DSRK-Lifetime AVP MUST be used to send the DSRK's >> lifetime. >> >> > >> >> > Agree. >> >> > >> >> >> >> >> >> [LM] a figure could be added for illustration here. >> >> >> >> >> >> 5. Command Codes >> >> >> >> >> >> [LM] this section is not required as there is nothing >> >> >specific for ERP. We should skip it. >> >> >> >> >> >> [SKIP] >> >> >> >> >> >> >> >> >> 6. Attribute Value Pair Definitions >> >> >> >> >> >> 6.1. EAP-DSRK-Request AVP >> >> >> >> >> >> The EAP-DSRK AVP (AVP Code TBD) is of type DiameterIdentity. >> >> >> >> >> >> [LM] s/EAP-DSRK AVP/EAP-DSRK-Request AVP >> >> >> >> >> >> This >> >> >> AVP fulfills two purposes: First, it indicates that a ER >> >> server is >> >> >> located in the local domain that is willing to play the >> >> >role of an ER >> >> >> server for a particular session. Second, it conveys >> information >> >> >> about the domain and ER server identity to the >> >> Diameter/EAP server. >> >> >> >> >> >> [LM] the use of this AVP is explained above. There is no >> >> >need to explain again. >> >> > >> >> > As we are in the AVP Definitions, I think it is better to >> >keep some >> >> >text explaining it. No ? >> >> > >> >> >> Moreover, if a DiameterIdentity is used, it is to indicate a >> >> >server and not a domain. Right? >> >> > >> >> > In my understanding the local ER server only sends the >> Domain Name >> >> >which will then be used to compute keys. Maybe the type = >> >> >DiameterIdentity is not appropriated and we should use = >UTF8String = >> >> >instead. What do you think ? >> >> > >> >> > >> >> >> >> >> >> 6.2. EAP-DSRK AVP >> >> >> >> >> >> The EAP-DSRK AVP (AVP Code TBD) is of type OctetString. = >> >> The Domain >> >> >> Specific Root Key (DSRK) is carried in this payload. >> >> >> >> >> >> 6.3. EAP-DSRK-Name AVP >> >> >> >> >> >> The EAP-DSRK-Name AVP (AVP Code TBD) is of type >> >> OctetString. This >> >> >> AVP contains the name of the DSRK key that is later used >> >> during the >> >> >> re-authentication exchange to select the correct DSRK. >> >> >> >> >> >> [LM] skip the part starting by "that is..." >> >> > >> >> > ok >> >> > >> >> >> >> >> >> 6.4. EAP-DSRK-Lifetime AVP >> >> >> >> >> >> The EAP-DSRK-Lifetime AVP (AVP Code TBD) is of type >> >> Unsigned64 and >> >> >> contains the DSRK lifetime in seconds. >> >> >> >> >> >> >> >> >> 7. AVP Occurrence Table >> >> >> >> >> >> The following table lists the AVPs that may optionally be >> >> >present in >> >> >> the DER and DEA commands [1]. >> >> >> >> >> >> >> >> >> +---------------+ >> >> >> | Command-Code | >> >> >> +-+-----+-----+-+ >> >> >> Attribute Name | DER | DEA | >> >> >> -------------------------------|-----+-----+ >> >> >> EAP-DSRK-Request | 0-1 | 0 | >> >> >> EAP-DSRK | 0 | 0-1 | >> >> >> EAP-DSRK-Name | 0 | 0-1 | >> >> >> EAP-DSRK-Lifetime | 0 | 0-1 | >> >> >> +-----+-----+ >> >> >> >> >> >> Figure 4: DER and DEA Commands AVP Table >> >> >> >> >> >> When the EAP-DSRK AVP is present in the DEA then the >> >> EAP-DSRK-Name >> >> >> and the EAP-DSRK-Lifetime MUST also be present. >> >> >> >> >> >> >> >> >> 8. AVP Flag Rules >> >> >> >> >> >> The following table describes the Diameter AVPs, >> their AVP Code >> >> >> values, types, possible flag values, and whether the >> AVP MAY be >> >> >> encrypted. The Diameter base [4] specifies the AVP Flag >> >> rules for >> >> >> AVPs in Section 4.5. >> >> >> >> >> >> >> >> >> = >> +---------------------+ >> >> >> | AVP = >> Flag Rules | >> >> >> = >> >> >+----+-----+----+-----+----+ >> >> >> AVP Section | | = >> >> >|SHLD|MUST | | >> >> >> Attribute Name Code Defined Data Type |MUST| MAY |NOT = >> >> >|NOT |Encr| >> >> >> = >> >> >------------------------------------------+----+-----+----+-- >> >> ---+----+ >> >> >> EAP-DSRK-Request TBD 4.7.1 DiamIdent | | P | | = >> >> >V,M | Y | >> >> >> EAP-DSRK TBD 4.7.2 OctetString| | P | | = >> >> >V,M | Y | >> >> >> EAP-DSRK-Name TBD 4.7.3 OctetString| | P | | = >> >> >V,M | Y | >> >> >> EAP-DSRK-Lifetime TBD 4.7.4 Unsigned64 | | P | | = >> >> >V,M | Y | >> >> >> = >> >> >> = >> >> >------------------------------------------+----+-----+----+-- >> >> ---+----+ >> >> >> >> >> >> Due to space constraints, the short form DiamIdent is used to = >> >> >> represent DiameterIdentity. >> >> >> >> >> >> Figure 5: AVP Flag Rules Table >> >> >> >> >> >> [LM] this table is ok according to the current RFC 3588. I >> >> >don't know how to deal with it regarding the RFC3588bis... >> >> > >> >> > >> >> > That's indeed a good question :). >> >> > >> >> > And that's all for my comments of your comments. >> >> > >> >> > Regards, >> >> > >> >> > --Julien-- >> >> >_______________________________________________ >> >> >DiME mailing list >> >> >DiME@ietf.org >> >> >https://www.ietf.org/mailman/listinfo/dime >> >> > >> >> = >> > >> = > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jan 9 08:26:02 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B40403A6869; Fri, 9 Jan 2009 08:26:02 -0800 (PST) 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 952223A6869 for ; Fri, 9 Jan 2009 08:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=0.238, 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 aqBHGH9k7-v4 for ; Fri, 9 Jan 2009 08:25:59 -0800 (PST) Received: from smtp118.rog.mail.re2.yahoo.com (smtp118.rog.mail.re2.yahoo.com [68.142.225.234]) by core3.amsl.com (Postfix) with SMTP id D8AB63A685E for ; Fri, 9 Jan 2009 08:25:58 -0800 (PST) Received: (qmail 48287 invoked from network); 9 Jan 2009 16:25:44 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=hdtgS7Vyu4kdHcFTTJIZKp1EfZKtyqGNs0GiZ9ktXYMcV/yS+3l2YG77FSMQl6T6l57901qfljrp69WE18RxPMQm36qVoUn8xFeSOcxpbyH1KqAX1tJRpvyH6613dPQizo5Obj6CXY6wB8skDhQsYVP4eu+WfRj1OVZew87A1rw= ; Received: from unknown (HELO ?192.168.0.101?) (tom.taylor@72.140.46.24 with plain) by smtp118.rog.mail.re2.yahoo.com with SMTP; 9 Jan 2009 16:25:44 -0000 X-YMail-OSG: 5O4cBxsVM1mKK93qpFGknqIP0dlFkEf9VXykzWMGfoehu9r.7BcHwJVML_vae1PXSA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49677A85.2030607@rogers.com> Date: Fri, 09 Jan 2009 11:25:41 -0500 From: Tom Taylor User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Julien Bournelle References: <7DBAFEC6A76F3E42817DF1EBE64CB026061E2759@ftrdmel2> <5e2406980901080218w746b69a7x320f1501aeb97266@mail.gmail.com> <7DBAFEC6A76F3E42817DF1EBE64CB0260622C4DE@ftrdmel2> <5e2406980901090115m2fe2c097nee9854a9ed870127@mail.gmail.com> In-Reply-To: <5e2406980901090115m2fe2c097nee9854a9ed870127@mail.gmail.com> Cc: dime@ietf.org Subject: Re: [Dime] Review of the Diameter ERP 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: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org An use case for the second problem talked about in the routing design team! Julien Bournelle wrote: > Hi, > = > On Fri, Jan 9, 2009 at 8:57 AM, Tschofenig, Hannes (NSN - FI/Espoo) > wrote: >> My reading of this text is that there is a way for the peer and the auth= enticator to figure out whether to use EAP or ERP. > = > I don't see how a new App Id will help peer and authenticator to > figure out ERP support. I may miss something here. > = > My understanding is that a new Appid would however help AAA entities > (authenticator, proxy, server) figure out ERP support. > = >> It, however, says very little about the further routing of AAA messages = in such a way that the messages traverse nodes understanding the additional= ly required functionality. If I understood ERP correctly then some key cach= ing takes place in the AAA proxies and hence one wants to make sure that th= e messages are actually routed via these proxies. > = > = > Yes, ideally, for a given peer, the same AAA proxy/local ERP server > should be contacted by authenticators. At this point, I don't see how > to ensure this. > = > Regards, > = > Julien > = >> Ciao >> Hannes >> >> >>> -----Original Message----- >>> From: ext lionel.morand@orange-ftgroup.com >>> [mailto:lionel.morand@orange-ftgroup.com] >>> Sent: 08 January, 2009 22:26 >>> To: Tschofenig, Hannes (NSN - FI/Espoo); >>> julien.bournelle@gmail.com; sdecugis@hongo.wide.ad.jp; dime@ietf.org >>> Subject: RE: [Dime] Review of the Diameter ERP draft >>> >>> According to the RFC 5296, it seems that it is not required to >>> have a specific Appl-ID: >>> >>> "It is plausible that the authenticator does not know >>> whether the peer >>> supports ERP and whether the peer has performed a full EAP >>> authentication through another authenticator. The authenticator MAY >>> initiate the ERP exchange by sending the EAP-Initiate/Re-auth-Start >>> message, and if there is no response, it will send the EAP-Request/ >>> Identity message. Note that this avoids having two EAP messages in >>> flight at the same time [2]. The authenticator may send the EAP- >>> Initiate/Re-auth-Start message and wait for a short, locally >>> configured amount of time. If the peer does not already know, this >>> message indicates to the peer that the authenticator supports ERP. >>> In response to this trigger from the authenticator, the peer can >>> initiate the ERP exchange by sending an >>> EAP-Initiate/Re-auth message. >>> If there is no response from the peer after the necessary >>> retransmissions (see Section 6), the authenticator MUST initiate EAP >>> by sending an EAP-Request message, typically the >>> EAP-Request/Identity >>> message. Note that the authenticator may receive an EAP-Initiate/ >>> Re-auth message after it has sent an EAP-Request/Identity message. >>> If the authenticator supports ERP, it MUST proceed with the ERP >>> exchange. When the EAP-Request/Identity times out, the >>> authenticator >>> MUST NOT close the connection if an ERP exchange is in progress or >>> has already succeeded in establishing a re-authentication MSK. >>> >>> If the authenticator does not support ERP, it drops EAP-Initiate/ >>> Re-auth messages [2] as the EAP code of those packets is >>> greater than >>> 4. An ERP-capable peer will exhaust the >>> EAP-Initiate/Re-auth message >>> retransmissions and fall back to EAP authentication by responding to >>> EAP Request/Identity messages from the authenticator. If the peer >>> does not support ERP or if it does not have unexpired key material >>> from a previous EAP authentication, it drops EAP-Initiate/ >>> Re-auth-Start messages. If there is no response to the >>> EAP-Initiate/ >>> Re-auth-Start message, the authenticator SHALL send an EAP Request >>> message (typically EAP Request/Identity) to start EAP >>> authentication. >>> From this stage onwards, RFC 3748 rules apply. Note that this may >>> introduce some delay in starting EAP. In some lower layers, the >>> delay can be minimized or even avoided by the peer initiating EAP by >>> sending messages such as EAPoL-Start in the IEEE 802.1X >>> specification >>> [10]." >>> >>> Both paragraphs assume (for me) that the ERP "option" may be >>> supported by the peer and/or the network. If none of them (or >>> only one of them) support ERP, the fallback mechanism is full >>> EAP authentication. >>> In that sense, knowing that the network supports ERP is not a >>> pre-requisite. The minimum is to support EAP and ERP is an >>> option available above EAP. That allows to deploy ERP above >>> existing EAP deployment. >>> >>> Does it make sense? >>> >>> Best Regards, >>> >>> Lionel >>> >>> >>>> -----Message d'origine----- >>>> De : Tschofenig, Hannes (NSN - FI/Espoo) >>>> [mailto:hannes.tschofenig@nsn.com] >>>> Envoy=E9 : jeudi 8 janvier 2009 13:55 >>>> =C0 : ext Julien Bournelle; MORAND Lionel RD-CORE-ISS; Sebastien >>>> Decugis; dime@ietf.org Objet : RE: [Dime] Review of the Diameter ERP >>>> draft >>>> >>>> One of the things I was not quite sure with the current protocol >>>> design is whether a Diameter application or just a bunch of AVPs are >>>> required. >>>> Based on the discussions a few of us when some of the HOKEY >>> specs went >>>> to the IESG / IETF Last Call I got the impression that one has to >>>> define a new Diameter application (which would be based on Diameter >>>> EAP) since you assume that the messages are routed via a node in the >>>> local network and the support for ERP has to be ensured. >>>> >>>> Ciao >>>> Hannes >>>> >>>>> -----Original Message----- >>>>> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] >>>> On Behalf Of >>>>> ext Julien Bournelle >>>>> Sent: 08 January, 2009 12:18 >>>>> To: lionel.morand@orange-ftgroup.com; Sebastien Decugis; >>>> dime@ietf.org >>>>> Subject: Re: [Dime] Review of the Diameter ERP draft >>>>> >>>>> Hi lionel, >>>>> >>>>> some comments inline. >>>>> >>>>> On Wed, Jan 7, 2009 at 12:03 PM, >>>>> wrote: >>>>>> Hi, >>>>>> >>>>>> Here is my review for the Diameter ERP draft. >>>>>> >>>>>> General comments: >>>>>> >>>>>> - About alignment with RFC 5296: >>>>>> the draft needs to be updated according to the publication >>>>> of the RFC 5296. Some proposals are provided below. >>>>>> - About ER server/AAA agent co-location: >>>>>> In my understanding, it is assumed in this document ER >>>>> server and AAA proxy have to be co-located to be able to rely on >>>>> Diameter to transport ERP specific AVPs. This doesn't maybe >>> preclude >>>>> other architectural choices but there are outside the scope of this >>>>> document. It is necessary to clarify this point in this document. >>>>>> - ERP support discovery: >>>>>> As the ERP specific AVPs are introduced with the M-bit >>>>> cleared, these AVPs are purely optional for the Diameter EAP >>>>> application i.e. they can be silently ignored by Diameter >>>> servers that >>>>> do not understand this new AVPs. Some text should be provided to >>>>> describe how the local ER server discovers that the Home EAP server >>>>> doesn't support ERP and the behaviour of the local ER >>> server in that >>>>> case. >>>>> >>>>> >>>>> I agree with these general comments. >>>>> >>>>> >>>>>> Hereafter is the rest of my review with comments and proposals. >>>>>> >>>>>> Best Regards, >>>>>> >>>>>> Lionel >>>>>> >>>>>> *************************************** >>>>>> >>>>>> Abstract >>>>>> >>>>>> An EAP extension, called "EAP Re-authentication Protocol >>>>> (ERP)", has >>>>>> been specified that supports an EAP method-independent >>>> protocol for >>>>>> efficient re-authentication between the peer and the >>>> server through >>>>>> an authenticator. This document specifies Diameter >>>>> support for ERP. >>>>>> The Diameter EAP application is re-used for >>>> encapsulating the newly >>>>>> defined EAP Initiate and EAP Finish messages specified >>> in the ERP >>>>>> specification. AVPs for request and delivery of Domain >>>>> Specific Root >>>>>> Keys from the AAA/EAP server to the ER server are also >>> specified. >>>>>> Additionally, this document also specifies Diameter >>>>> processing rules >>>>>> relevant to ERP. >>>>>> >>>>>> [LM] some abusive verbiage in the abstract: >>>>>> >>>>>> Proposal for new abstract: >>>>>> >>>>>> "EAP Re-authentication Protocol defines extensions of EAP >>>>> to support >>>>>> efficient re-authentication between the peer and an EAP >>>>>> re-authentication server through any authenticator. >>>>> I'm wondering if we should note that the authenticator may be >>>>> ERP-aware. >>>>> I'm thinking about the case where the authenticator sends the >>>>> EAP-Initiate/Re-auth-Start (Figure 4 in RFC 5296) >>>>> >>>>> >>>>>> This document >>>>>> specifies Diameter support for ERP. The Diameter EAP >>>> application is >>>>>> re-used for encapsulating the newly defined EAP messages >>>> specified >>>>>> in the ERP specification. Additionally, this document >>>> also defines >>>>>> specific Diameter processing rules relevant to ERP." >>>>> ok >>>>> >>>>>> >>>>>> 1. Introduction >>>>>> >>>>>> RFC 4072 [1] specifies a Diameter application that carries EAP >>>>>> packets between a Diameter client and the Diameter >>>>> Server/EAP server. >>>>>> [2] defines the EAP Re-authentication Protocol to allow >>>> faster re- >>>>>> authentication of a previously authenticated peer. >>>>>> >>>>>> [LM] s/[2] defines the EAP Re-authentication Protocol/RFC >>> 5296 [2] >>>>>> defines the EAP Re-authentication Protocol (ERP) >>>>>> >>>>>> In ERP, a peer >>>>>> authenticates to the network by proving possession of >>>> key material >>>>>> derived during a previous EAP exchange. >>>>>> >>>>>> [LM] s/a peer authenticate to/a peer is authenticated by >>>>>> >>>>>> For this purpose, an >>>>>> Extended Master Session Key (EMSK) based re-authentication key >>>>>> hierarchy has been defined [5]. ERP may be executed >>>> between the ER >>>>>> peer and an ER server in the peer's home domain or the >>>> local domain >>>>>> visited by the peer. In the latter case, a Domain >>>> Specific Root Key >>>>>> (DSRK), derived from the EMSK, is provided to the local >>> domain ER >>>>>> server. >>>>>> >>>>>> [LM] s/is provided to/is provided by the Home ER server to >>>>>> >>>>>> The peer and the local server subsequently use the re- >>>>>> authentication key hierarchy from the DSRK to authenticate >>>>> and derive >>>>>> authenticator specific keys within that domain. >>>>>> >>>>>> [LM] this information can be found in the RFC 5296. Remove >>>>> the sentence above. >>>>> >>>>> It may help the reader to understand the purpose of this DRSK. >>>>> >>>>>> To accomplish the >>>>>> reauthentication functionality, ERP defines two new EAP >>>> codes - EAP >>>>>> Initiate and EAP Finish. >>>>>> >>>>>> [LM] s/ERP defines two new EAP codes/ERP defines two new >>>> EAP messages >>>>> I would prefer to say that ERP defines two new EAP Codes >>>> here. These >>>>> newly EAP packets are then carried in messages (dependent of the >>>>> protocol used). >>>>> >>>>>> This document specifies the reuse of >>>>>> Diameter EAP application to carry these new EAP messages. >>>>>> The DSRK can be obtained as part of the regular EAP >>>> exchange or as >>>>>> part of an ERP bootstrapping exchange. The local ER server >>>>>> requesting the DSRK needs to be in the path of the EAP or ERP >>>>>> bootstrapping exchange in order to request and obtain the >>>>> DSRK. This >>>>>> document also specifies how the DSRK is transported to >>>> the local ER >>>>>> server using Diameter. >>>>>> >>>>>> [LM] Finally, i would reorganize the last part as follow: >>>>>> >>>>>> ::::::::::: >>>>>> >>>>>> "In ERP, a peer is authenticated by the network thanks to >>>>> keying material >>>>>> obtained during a previous EAP exchange. This keying >>>>> material is derived >>>>>> from the Extended Master Session Key (EMSK) defined in the >>>>> RFC 5295 [5]. >>>>>> To accomplish the EAP reauthentication functionality, ERP >>>>> defines two new >>>>>> EAP messages - EAP Initiate and EAP Finish. This document >>>>> specifies the >>>>>> reuse of Diameter EAP Application to carry these new EAP >>>> messages. >>>>>> ERP is executed between the peer and a server located >>>>> either in the peer's >>>>>> home domain or in the local domain visited by the peer. In >>>>> the latter case, >>>>>> a Domain Specific Root Key (DSRK) is derived from the >>>>> EMSK, as defined in >>>>>> the RFC 5295 [5], and is provided by the Home EAP server >>>>> to the local domain >>>>>> server. For that purpose, this document specifies the >>>>> transport of the DSRK >>>>>> using the Diameter EAP Application." >>>>> First paragraph is the old and second the new ? >>>>> >>>>>> :::::::::::::: >>>>>> >>>>>> >>>>>> >>>>>> 2. Terminology >>>>>> >>>>>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", >>>> "SHALL NOT", >>>>>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and >>>>> "OPTIONAL" in this >>>>>> document are to be interpreted as described in RFC 2119 [3]. >>>>>> >>>>>> This document uses terminology defined in [6], [5], >>> [2], and [1]. >>>>>> >>>>>> 3. Assumptions >>>>>> >>>>>> This document defines additional optional AVPs for >>> usage with the >>>>>> Diameter EAP application. Routing of these messages is >>> therefore >>>>>> provided via the Diameter Application Identifier (among other >>>>>> elements), as specified by the Diameter Base protocol [4]. >>>>>> >>>>>> [LM] To avoid any ambiguity I would say: >>>>>> >>>>>> "This document defines only additional optional AVPs for >>>> usage with >>>>>> the Diameter EAP application. This document does not defined >>>>>> a new Diameter application and a new Application ID is >>>>> therefore not >>>>>> required, as described in the Diameter Base protocol [4]." >>>>> ok >>>>> >>>>>> Based on >>>>>> the deployment of ERP, a local Diameter server (the same entity >>>>>> serves as a Diameter proxy during the full EAP >>>> authentication) may >>>>>> play the role of the ER server for future >>>>> re-authentication attempts. >>>>>> As such, the local Diameter server requesting the DSRK >>>>> needs to be in >>>>>> the path of the current EAP exchange between the peer >>> and the EAP >>>>>> server and also along in the future. The Diameter client is >>>>>> furthermore assumed to be able to route the re-authentication >>>>>> messages to the ER server. >>>>>> >>>>>> [LM] I think that the assumption all along this document is >>>>> that the local ER server and the AAA agent are co-located, >>>> to be able >>>>> to rely on DEA for the transport of DSRK. In that case, I >>> would say >>>>> something like: >>>>>> "In this document, when EAP re-authentication is performed >>>>> in the domain >>>>>> visited by the peer, it is assumed that the local ER >>>>> server is co-located >>>>>> with a Diameter agent in the visited domain present in >>>>> the path of the full >>>>>> EAP exchange." >>>>> ok >>>>> >>>>>> >>>>>> 4. Diameter Support for ERP >>>>>> >>>>>> 4.1. Protocol Overview >>>>>> >>>>>> Diameter may be used to transport ERP messages between the NAS >>>>>> (authenticator) and an authentication server (ER server). >>>>>> >>>>>> [LM] s/may/is (the use of Diameter is a pre-requisite in >>>> this draft) >>>>>> In ERP, the peer sends an EAP Initiate Reauth message to the ER >>>>>> server via the authenticator. >>>>>> >>>>>> [LM] s/"EAP Initiate Reauth message"/"EAP-Initiate/Re-auth >>>> message" >>>>>> (same all along the document) >>>>>> >>>>>> Alternatively, the NAS may send an EAP >>>>>> Initiate Reauth-Start message to the peer to trigger >>> the start of >>>>>> ERP; the peer then responds with an EAP Initiate Reauth >>>> message to >>>>>> the NAS. >>>>>> >>>>>> [LM] s/"EAP Initiate Reauth-Start >>>>> message"/"EAP-Initiate/Re-auth-Start >>>>>> message" (same all along the document) >>>>>> >>>>>> The general guidelines for encapsulating EAP messages >>> in Diameter >>>>>> from RFC 4072 [1] apply to the new EAP messages defined >>>> for ERP as >>>>>> well. The EAP Initiate Reauth message is encapsulated >>> in an EAP- >>>>>> Payload AVP of a Diameter EAP-Request message by the NAS >>>>> and sent to >>>>>> the Diameter server. The NAS MUST copy the contents of >>> the value >>>>>> field of the 'rIKName as NAI' TLV or the peer-id TLV (when >>>>> the former >>>>>> is not present) of the EAP Initiate Reauth message into >>>> a User-Name >>>>>> AVP of the Diameter EAP-Request. >>>>>> >>>>>> [LM] I think that we are talking about the 'keyName-NAI' TLV >>>>> and not anymore the 'rIKName as NAI' TLV. >>>>> >>>>> Considering section 5.3.2 of RFC 5296. I agree. >>>>> >>>>>> Moreover, in which case the peer-id TLV would not be >>>> present for ERP? >>>>> Privacy ? >>>>> >>>>>> The ER server processes the EAP Initiate Reauth message in >>>>> accordance >>>>>> with [2], and if that is successful, it responds with an >>>> EAP Finish >>>>>> Reauth message indicating a success ('R' flag set to 0). The >>>>>> Diameter server MUST encapsulate the EAP Finish Reauth >>>> message with >>>>>> the R flag set to zero in an EAP-Payload AVP attribute of >>>>> a Diameter >>>>>> EAP-Answer message. An EAP-Master-Session-Key AVP >>>> included in the >>>>>> Diameter EAP-Answer contains the Re-authentication Master >>>>> Session Key >>>>>> (rMSK). The Diameter Result Code, if any, SHOULD be a >>>>> success Result >>>>>> Code. >>>>>> >>>>>> If the processing of the EAP Initiate Reauth message >>>> resulted in a >>>>>> failure, the Diameter server MUST encapsulate an EAP >>>> Finish Reauth >>>>>> message indicating failure ('R' flag set to 1) in an >>>>> EAP-Payload AVP >>>>>> of a Diameter EAP-Answer message. The Diameter Result >>>>> Code, if any, >>>>>> SHOULD be a failure Result Code. Whether an EAP Finish Reauth >>>>>> message is sent at all is specified in [2]. >>>>>> >>>>>> [LM] the use of the 'R' flag is not relevant for Diameter EAP. >>>>>> [LM] according to the RFC, the EAP-Finish/Re-auth is sent >>>>> back in any case, success or failure. >>>>>> [LM] according to the above comments, I would rephrase the >>>>> text as follow: >>>>>> >>>>>> "The ER server processes the EAP Initiate Reauth message >>>>> in accordance >>>>>> with [2] and responds with an EAP-Finish/Re-auth message. >>>>> The Diameter >>>>>> server MUST encapsulate the EAP-Finish/Re-auth message within an >>>>>> EAP-Payload AVP of a Diameter EAP-Answer message. >>>>>> In an EAP re-authentication successful case, an >>>>> EAP-Master-Session-Key >>>>>> AVP is included in the Diameter EAP-Answer message that >>>>> contains the >>>>>> Re-authentication Master Session Key (rMSK). The Diameter >>>>> Result-Code >>>>>> SHOULD be a success Result-Code. >>>>>> In an EAP re-authentication failure case, the Diameter >>>>> Result-Code of >>>>>> the a Diameter EAP-Answer message SHOULD be a failure >>>>> Result-Code and >>>>>> no EAP-Master-Session-Key AVP is present." >>>>>> >>>>>> [LM] By the way, I don't understand the "SHOULD" for the >>>>> result-code. Any reason not to use "MUST" here? >>>>> >>>>> I think a MUST would be better. Different views ? >>>>> >>>>>> [LM] a figure could be added for illustration here. >>>>>> >>>>>> 4.2. DSRK Request and Delivery >>>>>> >>>>>> A local ER server, collocated with a Diameter proxy in >>> the peer's >>>>>> visited domain, >>>>>> >>>>>> [LM] s/in the peer's visited domain/in the domain visited >>>> by the peer >>>>>> may request a DSRK from the EAP server, either in the >>>>>> initial EAP exchange (implicit bootstrapping) or in an ERP >>>>>> bootstrapping exchange (explicit bootstrapping). It >>> does this by >>>>>> including the EAP-DSRK-Request AVP in the Diameter EAP-Response >>>>>> message. The EAP-DSRK-Request AVP contains the domain or server >>>>>> identity required to derive the DSRK. >>>>>> >>>>>> [LM] the EAP-DSRK-Request AVP is included in the Diameter >>>>> EAP-Request >>>>>> (and not in the response) >>>>> yes. >>>>> >>>>>> An EAP server MAY send the DSRK when it receives a >>> valid Diameter >>>>>> EAP-Request message containing an EAP-DSRK-Request AVP. >>>>> An ER server >>>>>> MUST send the DSRK (or send a failure result) when it receives a >>>>>> valid Diameter EAP-Request message containing an >>>>> EAP-DSRK-Request AVP >>>>>> along with a valid EAP Initiate Re-auth packet with the >>>>> bootstrapping >>>>>> flag turned on. If an EAP-DSRK-Request AVP is included in >>>>> any other >>>>>> Diameter EAP-Request message, the Diameter server MUST >>>> reply with a >>>>>> failure result. An EAP-DSRK AVP MUST be used to send a >>>>> DSRK; an EAP- >>>>>> DSRK-Name AVP MUST be used to send the DSRK's keyname; >>>> and an EAP- >>>>>> DSRK-Lifetime AVP MUST be used to send the DSRK's lifetime. >>>>>> >>>>>> [LM] I don't understand the intention of the above text. >>>>> Could it be enough to say: >>>>>> In successful case, the DSRK is carried by the EAP-DSRK >>>> AVP in the >>>>>> Diameter EAP response message. Along with the EAP-DSRK AVP, an >>>>>> EAP-DSRK-Name AVP MUST be used to send the DSRK's keyname and an >>>>>> EAP-DSRK-Lifetime AVP MUST be used to send the DSRK's lifetime. >>>>> Agree. >>>>> >>>>>> [LM] a figure could be added for illustration here. >>>>>> >>>>>> 5. Command Codes >>>>>> >>>>>> [LM] this section is not required as there is nothing >>>>> specific for ERP. We should skip it. >>>>>> [SKIP] >>>>>> >>>>>> >>>>>> 6. Attribute Value Pair Definitions >>>>>> >>>>>> 6.1. EAP-DSRK-Request AVP >>>>>> >>>>>> The EAP-DSRK AVP (AVP Code TBD) is of type DiameterIdentity. >>>>>> >>>>>> [LM] s/EAP-DSRK AVP/EAP-DSRK-Request AVP >>>>>> >>>>>> This >>>>>> AVP fulfills two purposes: First, it indicates that a ER >>>> server is >>>>>> located in the local domain that is willing to play the >>>>> role of an ER >>>>>> server for a particular session. Second, it conveys information >>>>>> about the domain and ER server identity to the >>>> Diameter/EAP server. >>>>>> [LM] the use of this AVP is explained above. There is no >>>>> need to explain again. >>>>> >>>>> As we are in the AVP Definitions, I think it is better to >>> keep some >>>>> text explaining it. No ? >>>>> >>>>>> Moreover, if a DiameterIdentity is used, it is to indicate a >>>>> server and not a domain. Right? >>>>> >>>>> In my understanding the local ER server only sends the Domain Name >>>>> which will then be used to compute keys. Maybe the type >>>>> DiameterIdentity is not appropriated and we should use UTF8String >>>>> instead. What do you think ? >>>>> >>>>> >>>>>> 6.2. EAP-DSRK AVP >>>>>> >>>>>> The EAP-DSRK AVP (AVP Code TBD) is of type OctetString. >>>> The Domain >>>>>> Specific Root Key (DSRK) is carried in this payload. >>>>>> >>>>>> 6.3. EAP-DSRK-Name AVP >>>>>> >>>>>> The EAP-DSRK-Name AVP (AVP Code TBD) is of type >>>> OctetString. This >>>>>> AVP contains the name of the DSRK key that is later used >>>> during the >>>>>> re-authentication exchange to select the correct DSRK. >>>>>> >>>>>> [LM] skip the part starting by "that is..." >>>>> ok >>>>> >>>>>> 6.4. EAP-DSRK-Lifetime AVP >>>>>> >>>>>> The EAP-DSRK-Lifetime AVP (AVP Code TBD) is of type >>>> Unsigned64 and >>>>>> contains the DSRK lifetime in seconds. >>>>>> >>>>>> >>>>>> 7. AVP Occurrence Table >>>>>> >>>>>> The following table lists the AVPs that may optionally be >>>>> present in >>>>>> the DER and DEA commands [1]. >>>>>> >>>>>> >>>>>> +---------------+ >>>>>> | Command-Code | >>>>>> +-+-----+-----+-+ >>>>>> Attribute Name | DER | DEA | >>>>>> -------------------------------|-----+-----+ >>>>>> EAP-DSRK-Request | 0-1 | 0 | >>>>>> EAP-DSRK | 0 | 0-1 | >>>>>> EAP-DSRK-Name | 0 | 0-1 | >>>>>> EAP-DSRK-Lifetime | 0 | 0-1 | >>>>>> +-----+-----+ >>>>>> >>>>>> Figure 4: DER and DEA Commands AVP Table >>>>>> >>>>>> When the EAP-DSRK AVP is present in the DEA then the >>>> EAP-DSRK-Name >>>>>> and the EAP-DSRK-Lifetime MUST also be present. >>>>>> >>>>>> >>>>>> 8. AVP Flag Rules >>>>>> >>>>>> The following table describes the Diameter AVPs, their AVP Code >>>>>> values, types, possible flag values, and whether the AVP MAY be >>>>>> encrypted. The Diameter base [4] specifies the AVP Flag >>>> rules for >>>>>> AVPs in Section 4.5. >>>>>> >>>>>> >>>>>> +---------------------+ >>>>>> | AVP Flag Rules | >>>>>> >>>>> +----+-----+----+-----+----+ >>>>>> AVP Section | | >>>>> |SHLD|MUST | | >>>>>> Attribute Name Code Defined Data Type |MUST| MAY |NOT >>>>> |NOT |Encr| >>>>> ------------------------------------------+----+-----+----+-- >>>> ---+----+ >>>>>> EAP-DSRK-Request TBD 4.7.1 DiamIdent | | P | | >>>>> V,M | Y | >>>>>> EAP-DSRK TBD 4.7.2 OctetString| | P | | >>>>> V,M | Y | >>>>>> EAP-DSRK-Name TBD 4.7.3 OctetString| | P | | >>>>> V,M | Y | >>>>>> EAP-DSRK-Lifetime TBD 4.7.4 Unsigned64 | | P | | >>>>> V,M | Y | >>>>>> >>>>> ------------------------------------------+----+-----+----+-- >>>> ---+----+ >>>>>> Due to space constraints, the short form DiamIdent is used to >>>>>> represent DiameterIdentity. >>>>>> >>>>>> Figure 5: AVP Flag Rules Table >>>>>> >>>>>> [LM] this table is ok according to the current RFC 3588. I >>>>> don't know how to deal with it regarding the RFC3588bis... >>>>> >>>>> >>>>> That's indeed a good question :). >>>>> >>>>> And that's all for my comments of your comments. >>>>> >>>>> Regards, >>>>> >>>>> --Julien-- >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>>>> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > = > = _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Jan 10 04:47:47 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEB0728C184; Sat, 10 Jan 2009 04:47:47 -0800 (PST) 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 BA25128C184 for ; Sat, 10 Jan 2009 04:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xG9KA4ZM9LsP for ; Sat, 10 Jan 2009 04:47:44 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 64A3428C0D9 for ; Sat, 10 Jan 2009 04:47:43 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KD90099BA721H@szxga03-in.huawei.com> for dime@ietf.org; Sat, 10 Jan 2009 20:47:27 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KD900BATA72C7@szxga03-in.huawei.com> for dime@ietf.org; Sat, 10 Jan 2009 20:47:26 +0800 (CST) Received: from [192.168.1.4] (102.175.60.58.broad.sz.gd.dynamic.163data.com.cn [58.60.175.102]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KD9003N0A708Q@szxml02-in.huawei.com>; Sat, 10 Jan 2009 20:47:26 +0800 (CST) Date: Sat, 10 Jan 2009 20:47:24 +0800 From: Tina TSOU In-reply-to: <49677A85.2030607@rogers.com> To: Tom Taylor Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.929.2) References: <7DBAFEC6A76F3E42817DF1EBE64CB026061E2759@ftrdmel2> <5e2406980901080218w746b69a7x320f1501aeb97266@mail.gmail.com> <7DBAFEC6A76F3E42817DF1EBE64CB0260622C4DE@ftrdmel2> <5e2406980901090115m2fe2c097nee9854a9ed870127@mail.gmail.com> <49677A85.2030607@rogers.com> Cc: dime@ietf.org, diameter-routing@googlegroups.com Subject: Re: [Dime] Review of the Diameter ERP 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: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="yes" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Tom, Thanks for your comments. I will update the draft-tsou-dime-routing-problem-statement-01, adding = this use case for the 2nd problem, hopefully before the design team = meeting next Thursday. The design team discussion could be found in http://groups.google.com/group/diameter-routing?hl=3Den B. R. Tina Messengers: MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU = Jabber: tina@jabber.org Google talk: tinatsou6@gmail.com +86-755-28971872 (Office) +86-13922884380(Mobile) On Jan 10, 2009, at 12:25 AM, Tom Taylor wrote: > An use case for the second problem talked about in the routing = > design team! > > Julien Bournelle wrote: >> Hi, >> On Fri, Jan 9, 2009 at 8:57 AM, Tschofenig, Hannes (NSN - FI/Espoo) >> wrote: >>> My reading of this text is that there is a way for the peer and = >>> the authenticator to figure out whether to use EAP or ERP. >> I don't see how a new App Id will help peer and authenticator to >> figure out ERP support. I may miss something here. >> My understanding is that a new Appid would however help AAA entities >> (authenticator, proxy, server) figure out ERP support. >>> It, however, says very little about the further routing of AAA = >>> messages in such a way that the messages traverse nodes = >>> understanding the additionally required functionality. If I = >>> understood ERP correctly then some key caching takes place in the = >>> AAA proxies and hence one wants to make sure that the messages are = >>> actually routed via these proxies. >> Yes, ideally, for a given peer, the same AAA proxy/local ERP server >> should be contacted by authenticators. At this point, I don't see how >> to ensure this. >> Regards, >> Julien >>> Ciao >>> Hannes >>> >>> >>>> -----Original Message----- >>>> From: ext lionel.morand@orange-ftgroup.com >>>> [mailto:lionel.morand@orange-ftgroup.com] >>>> Sent: 08 January, 2009 22:26 >>>> To: Tschofenig, Hannes (NSN - FI/Espoo); >>>> julien.bournelle@gmail.com; sdecugis@hongo.wide.ad.jp; = >>>> dime@ietf.org >>>> Subject: RE: [Dime] Review of the Diameter ERP draft >>>> >>>> According to the RFC 5296, it seems that it is not required to >>>> have a specific Appl-ID: >>>> >>>> "It is plausible that the authenticator does not know >>>> whether the peer >>>> supports ERP and whether the peer has performed a full EAP >>>> authentication through another authenticator. The authenticator = >>>> MAY >>>> initiate the ERP exchange by sending the EAP-Initiate/Re-auth- = >>>> Start >>>> message, and if there is no response, it will send the EAP- = >>>> Request/ >>>> Identity message. Note that this avoids having two EAP messages = >>>> in >>>> flight at the same time [2]. The authenticator may send the EAP- >>>> Initiate/Re-auth-Start message and wait for a short, locally >>>> configured amount of time. If the peer does not already know, = >>>> this >>>> message indicates to the peer that the authenticator supports ERP. >>>> In response to this trigger from the authenticator, the peer can >>>> initiate the ERP exchange by sending an >>>> EAP-Initiate/Re-auth message. >>>> If there is no response from the peer after the necessary >>>> retransmissions (see Section 6), the authenticator MUST initiate = >>>> EAP >>>> by sending an EAP-Request message, typically the >>>> EAP-Request/Identity >>>> message. Note that the authenticator may receive an EAP-Initiate/ >>>> Re-auth message after it has sent an EAP-Request/Identity message. >>>> If the authenticator supports ERP, it MUST proceed with the ERP >>>> exchange. When the EAP-Request/Identity times out, the >>>> authenticator >>>> MUST NOT close the connection if an ERP exchange is in progress or >>>> has already succeeded in establishing a re-authentication MSK. >>>> >>>> If the authenticator does not support ERP, it drops EAP-Initiate/ >>>> Re-auth messages [2] as the EAP code of those packets is >>>> greater than >>>> 4. An ERP-capable peer will exhaust the >>>> EAP-Initiate/Re-auth message >>>> retransmissions and fall back to EAP authentication by = >>>> responding to >>>> EAP Request/Identity messages from the authenticator. If the peer >>>> does not support ERP or if it does not have unexpired key material >>>> from a previous EAP authentication, it drops EAP-Initiate/ >>>> Re-auth-Start messages. If there is no response to the >>>> EAP-Initiate/ >>>> Re-auth-Start message, the authenticator SHALL send an EAP Request >>>> message (typically EAP Request/Identity) to start EAP >>>> authentication. >>>> From this stage onwards, RFC 3748 rules apply. Note that this may >>>> introduce some delay in starting EAP. In some lower layers, the >>>> delay can be minimized or even avoided by the peer initiating = >>>> EAP by >>>> sending messages such as EAPoL-Start in the IEEE 802.1X >>>> specification >>>> [10]." >>>> >>>> Both paragraphs assume (for me) that the ERP "option" may be >>>> supported by the peer and/or the network. If none of them (or >>>> only one of them) support ERP, the fallback mechanism is full >>>> EAP authentication. >>>> In that sense, knowing that the network supports ERP is not a >>>> pre-requisite. The minimum is to support EAP and ERP is an >>>> option available above EAP. That allows to deploy ERP above >>>> existing EAP deployment. >>>> >>>> Does it make sense? >>>> >>>> Best Regards, >>>> >>>> Lionel >>>> >>>> >>>>> -----Message d'origine----- >>>>> De : Tschofenig, Hannes (NSN - FI/Espoo) >>>>> [mailto:hannes.tschofenig@nsn.com] >>>>> Envoy=E9 : jeudi 8 janvier 2009 13:55 >>>>> =C0 : ext Julien Bournelle; MORAND Lionel RD-CORE-ISS; Sebastien >>>>> Decugis; dime@ietf.org Objet : RE: [Dime] Review of the Diameter = >>>>> ERP >>>>> draft >>>>> >>>>> One of the things I was not quite sure with the current protocol >>>>> design is whether a Diameter application or just a bunch of AVPs = >>>>> are >>>>> required. >>>>> Based on the discussions a few of us when some of the HOKEY >>>> specs went >>>>> to the IESG / IETF Last Call I got the impression that one has to >>>>> define a new Diameter application (which would be based on = >>>>> Diameter >>>>> EAP) since you assume that the messages are routed via a node in = >>>>> the >>>>> local network and the support for ERP has to be ensured. >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>>> -----Original Message----- >>>>>> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] >>>>> On Behalf Of >>>>>> ext Julien Bournelle >>>>>> Sent: 08 January, 2009 12:18 >>>>>> To: lionel.morand@orange-ftgroup.com; Sebastien Decugis; >>>>> dime@ietf.org >>>>>> Subject: Re: [Dime] Review of the Diameter ERP draft >>>>>> >>>>>> Hi lionel, >>>>>> >>>>>> some comments inline. >>>>>> >>>>>> On Wed, Jan 7, 2009 at 12:03 PM, >>>>>> wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Here is my review for the Diameter ERP draft. >>>>>>> >>>>>>> General comments: >>>>>>> >>>>>>> - About alignment with RFC 5296: >>>>>>> the draft needs to be updated according to the publication >>>>>> of the RFC 5296. Some proposals are provided below. >>>>>>> - About ER server/AAA agent co-location: >>>>>>> In my understanding, it is assumed in this document ER >>>>>> server and AAA proxy have to be co-located to be able to rely on >>>>>> Diameter to transport ERP specific AVPs. This doesn't maybe >>>> preclude >>>>>> other architectural choices but there are outside the scope of = >>>>>> this >>>>>> document. It is necessary to clarify this point in this document. >>>>>>> - ERP support discovery: >>>>>>> As the ERP specific AVPs are introduced with the M-bit >>>>>> cleared, these AVPs are purely optional for the Diameter EAP >>>>>> application i.e. they can be silently ignored by Diameter >>>>> servers that >>>>>> do not understand this new AVPs. Some text should be provided to >>>>>> describe how the local ER server discovers that the Home EAP = >>>>>> server >>>>>> doesn't support ERP and the behaviour of the local ER >>>> server in that >>>>>> case. >>>>>> >>>>>> >>>>>> I agree with these general comments. >>>>>> >>>>>> >>>>>>> Hereafter is the rest of my review with comments and proposals. >>>>>>> >>>>>>> Best Regards, >>>>>>> >>>>>>> Lionel >>>>>>> >>>>>>> *************************************** >>>>>>> >>>>>>> Abstract >>>>>>> >>>>>>> An EAP extension, called "EAP Re-authentication Protocol >>>>>> (ERP)", has >>>>>>> been specified that supports an EAP method-independent >>>>> protocol for >>>>>>> efficient re-authentication between the peer and the >>>>> server through >>>>>>> an authenticator. This document specifies Diameter >>>>>> support for ERP. >>>>>>> The Diameter EAP application is re-used for >>>>> encapsulating the newly >>>>>>> defined EAP Initiate and EAP Finish messages specified >>>> in the ERP >>>>>>> specification. AVPs for request and delivery of Domain >>>>>> Specific Root >>>>>>> Keys from the AAA/EAP server to the ER server are also >>>> specified. >>>>>>> Additionally, this document also specifies Diameter >>>>>> processing rules >>>>>>> relevant to ERP. >>>>>>> >>>>>>> [LM] some abusive verbiage in the abstract: >>>>>>> >>>>>>> Proposal for new abstract: >>>>>>> >>>>>>> "EAP Re-authentication Protocol defines extensions of EAP >>>>>> to support >>>>>>> efficient re-authentication between the peer and an EAP >>>>>>> re-authentication server through any authenticator. >>>>>> I'm wondering if we should note that the authenticator may be >>>>>> ERP-aware. >>>>>> I'm thinking about the case where the authenticator sends the >>>>>> EAP-Initiate/Re-auth-Start (Figure 4 in RFC 5296) >>>>>> >>>>>> >>>>>>> This document >>>>>>> specifies Diameter support for ERP. The Diameter EAP >>>>> application is >>>>>>> re-used for encapsulating the newly defined EAP messages >>>>> specified >>>>>>> in the ERP specification. Additionally, this document >>>>> also defines >>>>>>> specific Diameter processing rules relevant to ERP." >>>>>> ok >>>>>> >>>>>>> >>>>>>> 1. Introduction >>>>>>> >>>>>>> RFC 4072 [1] specifies a Diameter application that carries EAP >>>>>>> packets between a Diameter client and the Diameter >>>>>> Server/EAP server. >>>>>>> [2] defines the EAP Re-authentication Protocol to allow >>>>> faster re- >>>>>>> authentication of a previously authenticated peer. >>>>>>> >>>>>>> [LM] s/[2] defines the EAP Re-authentication Protocol/RFC >>>> 5296 [2] >>>>>>> defines the EAP Re-authentication Protocol (ERP) >>>>>>> >>>>>>> In ERP, a peer >>>>>>> authenticates to the network by proving possession of >>>>> key material >>>>>>> derived during a previous EAP exchange. >>>>>>> >>>>>>> [LM] s/a peer authenticate to/a peer is authenticated by >>>>>>> >>>>>>> For this purpose, an >>>>>>> Extended Master Session Key (EMSK) based re-authentication key >>>>>>> hierarchy has been defined [5]. ERP may be executed >>>>> between the ER >>>>>>> peer and an ER server in the peer's home domain or the >>>>> local domain >>>>>>> visited by the peer. In the latter case, a Domain >>>>> Specific Root Key >>>>>>> (DSRK), derived from the EMSK, is provided to the local >>>> domain ER >>>>>>> server. >>>>>>> >>>>>>> [LM] s/is provided to/is provided by the Home ER server to >>>>>>> >>>>>>> The peer and the local server subsequently use the re- >>>>>>> authentication key hierarchy from the DSRK to authenticate >>>>>> and derive >>>>>>> authenticator specific keys within that domain. >>>>>>> >>>>>>> [LM] this information can be found in the RFC 5296. Remove >>>>>> the sentence above. >>>>>> >>>>>> It may help the reader to understand the purpose of this DRSK. >>>>>> >>>>>>> To accomplish the >>>>>>> reauthentication functionality, ERP defines two new EAP >>>>> codes - EAP >>>>>>> Initiate and EAP Finish. >>>>>>> >>>>>>> [LM] s/ERP defines two new EAP codes/ERP defines two new >>>>> EAP messages >>>>>> I would prefer to say that ERP defines two new EAP Codes >>>>> here. These >>>>>> newly EAP packets are then carried in messages (dependent of the >>>>>> protocol used). >>>>>> >>>>>>> This document specifies the reuse of >>>>>>> Diameter EAP application to carry these new EAP messages. >>>>>>> The DSRK can be obtained as part of the regular EAP >>>>> exchange or as >>>>>>> part of an ERP bootstrapping exchange. The local ER server >>>>>>> requesting the DSRK needs to be in the path of the EAP or ERP >>>>>>> bootstrapping exchange in order to request and obtain the >>>>>> DSRK. This >>>>>>> document also specifies how the DSRK is transported to >>>>> the local ER >>>>>>> server using Diameter. >>>>>>> >>>>>>> [LM] Finally, i would reorganize the last part as follow: >>>>>>> >>>>>>> ::::::::::: >>>>>>> >>>>>>> "In ERP, a peer is authenticated by the network thanks to >>>>>> keying material >>>>>>> obtained during a previous EAP exchange. This keying >>>>>> material is derived >>>>>>> from the Extended Master Session Key (EMSK) defined in the >>>>>> RFC 5295 [5]. >>>>>>> To accomplish the EAP reauthentication functionality, ERP >>>>>> defines two new >>>>>>> EAP messages - EAP Initiate and EAP Finish. This document >>>>>> specifies the >>>>>>> reuse of Diameter EAP Application to carry these new EAP >>>>> messages. >>>>>>> ERP is executed between the peer and a server located >>>>>> either in the peer's >>>>>>> home domain or in the local domain visited by the peer. In >>>>>> the latter case, >>>>>>> a Domain Specific Root Key (DSRK) is derived from the >>>>>> EMSK, as defined in >>>>>>> the RFC 5295 [5], and is provided by the Home EAP server >>>>>> to the local domain >>>>>>> server. For that purpose, this document specifies the >>>>>> transport of the DSRK >>>>>>> using the Diameter EAP Application." >>>>>> First paragraph is the old and second the new ? >>>>>> >>>>>>> :::::::::::::: >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2. Terminology >>>>>>> >>>>>>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", >>>>> "SHALL NOT", >>>>>>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and >>>>>> "OPTIONAL" in this >>>>>>> document are to be interpreted as described in RFC 2119 [3]. >>>>>>> >>>>>>> This document uses terminology defined in [6], [5], >>>> [2], and [1]. >>>>>>> >>>>>>> 3. Assumptions >>>>>>> >>>>>>> This document defines additional optional AVPs for >>>> usage with the >>>>>>> Diameter EAP application. Routing of these messages is >>>> therefore >>>>>>> provided via the Diameter Application Identifier (among other >>>>>>> elements), as specified by the Diameter Base protocol [4]. >>>>>>> >>>>>>> [LM] To avoid any ambiguity I would say: >>>>>>> >>>>>>> "This document defines only additional optional AVPs for >>>>> usage with >>>>>>> the Diameter EAP application. This document does not defined >>>>>>> a new Diameter application and a new Application ID is >>>>>> therefore not >>>>>>> required, as described in the Diameter Base protocol [4]." >>>>>> ok >>>>>> >>>>>>> Based on >>>>>>> the deployment of ERP, a local Diameter server (the same entity >>>>>>> serves as a Diameter proxy during the full EAP >>>>> authentication) may >>>>>>> play the role of the ER server for future >>>>>> re-authentication attempts. >>>>>>> As such, the local Diameter server requesting the DSRK >>>>>> needs to be in >>>>>>> the path of the current EAP exchange between the peer >>>> and the EAP >>>>>>> server and also along in the future. The Diameter client is >>>>>>> furthermore assumed to be able to route the re-authentication >>>>>>> messages to the ER server. >>>>>>> >>>>>>> [LM] I think that the assumption all along this document is >>>>>> that the local ER server and the AAA agent are co-located, >>>>> to be able >>>>>> to rely on DEA for the transport of DSRK. In that case, I >>>> would say >>>>>> something like: >>>>>>> "In this document, when EAP re-authentication is performed >>>>>> in the domain >>>>>>> visited by the peer, it is assumed that the local ER >>>>>> server is co-located >>>>>>> with a Diameter agent in the visited domain present in >>>>>> the path of the full >>>>>>> EAP exchange." >>>>>> ok >>>>>> >>>>>>> >>>>>>> 4. Diameter Support for ERP >>>>>>> >>>>>>> 4.1. Protocol Overview >>>>>>> >>>>>>> Diameter may be used to transport ERP messages between the NAS >>>>>>> (authenticator) and an authentication server (ER server). >>>>>>> >>>>>>> [LM] s/may/is (the use of Diameter is a pre-requisite in >>>>> this draft) >>>>>>> In ERP, the peer sends an EAP Initiate Reauth message to the ER >>>>>>> server via the authenticator. >>>>>>> >>>>>>> [LM] s/"EAP Initiate Reauth message"/"EAP-Initiate/Re-auth >>>>> message" >>>>>>> (same all along the document) >>>>>>> >>>>>>> Alternatively, the NAS may send an EAP >>>>>>> Initiate Reauth-Start message to the peer to trigger >>>> the start of >>>>>>> ERP; the peer then responds with an EAP Initiate Reauth >>>>> message to >>>>>>> the NAS. >>>>>>> >>>>>>> [LM] s/"EAP Initiate Reauth-Start >>>>>> message"/"EAP-Initiate/Re-auth-Start >>>>>>> message" (same all along the document) >>>>>>> >>>>>>> The general guidelines for encapsulating EAP messages >>>> in Diameter >>>>>>> from RFC 4072 [1] apply to the new EAP messages defined >>>>> for ERP as >>>>>>> well. The EAP Initiate Reauth message is encapsulated >>>> in an EAP- >>>>>>> Payload AVP of a Diameter EAP-Request message by the NAS >>>>>> and sent to >>>>>>> the Diameter server. The NAS MUST copy the contents of >>>> the value >>>>>>> field of the 'rIKName as NAI' TLV or the peer-id TLV (when >>>>>> the former >>>>>>> is not present) of the EAP Initiate Reauth message into >>>>> a User-Name >>>>>>> AVP of the Diameter EAP-Request. >>>>>>> >>>>>>> [LM] I think that we are talking about the 'keyName-NAI' TLV >>>>>> and not anymore the 'rIKName as NAI' TLV. >>>>>> >>>>>> Considering section 5.3.2 of RFC 5296. I agree. >>>>>> >>>>>>> Moreover, in which case the peer-id TLV would not be >>>>> present for ERP? >>>>>> Privacy ? >>>>>> >>>>>>> The ER server processes the EAP Initiate Reauth message in >>>>>> accordance >>>>>>> with [2], and if that is successful, it responds with an >>>>> EAP Finish >>>>>>> Reauth message indicating a success ('R' flag set to 0). The >>>>>>> Diameter server MUST encapsulate the EAP Finish Reauth >>>>> message with >>>>>>> the R flag set to zero in an EAP-Payload AVP attribute of >>>>>> a Diameter >>>>>>> EAP-Answer message. An EAP-Master-Session-Key AVP >>>>> included in the >>>>>>> Diameter EAP-Answer contains the Re-authentication Master >>>>>> Session Key >>>>>>> (rMSK). The Diameter Result Code, if any, SHOULD be a >>>>>> success Result >>>>>>> Code. >>>>>>> >>>>>>> If the processing of the EAP Initiate Reauth message >>>>> resulted in a >>>>>>> failure, the Diameter server MUST encapsulate an EAP >>>>> Finish Reauth >>>>>>> message indicating failure ('R' flag set to 1) in an >>>>>> EAP-Payload AVP >>>>>>> of a Diameter EAP-Answer message. The Diameter Result >>>>>> Code, if any, >>>>>>> SHOULD be a failure Result Code. Whether an EAP Finish Reauth >>>>>>> message is sent at all is specified in [2]. >>>>>>> >>>>>>> [LM] the use of the 'R' flag is not relevant for Diameter EAP. >>>>>>> [LM] according to the RFC, the EAP-Finish/Re-auth is sent >>>>>> back in any case, success or failure. >>>>>>> [LM] according to the above comments, I would rephrase the >>>>>> text as follow: >>>>>>> >>>>>>> "The ER server processes the EAP Initiate Reauth message >>>>>> in accordance >>>>>>> with [2] and responds with an EAP-Finish/Re-auth message. >>>>>> The Diameter >>>>>>> server MUST encapsulate the EAP-Finish/Re-auth message within = >>>>>>> an >>>>>>> EAP-Payload AVP of a Diameter EAP-Answer message. >>>>>>> In an EAP re-authentication successful case, an >>>>>> EAP-Master-Session-Key >>>>>>> AVP is included in the Diameter EAP-Answer message that >>>>>> contains the >>>>>>> Re-authentication Master Session Key (rMSK). The Diameter >>>>>> Result-Code >>>>>>> SHOULD be a success Result-Code. >>>>>>> In an EAP re-authentication failure case, the Diameter >>>>>> Result-Code of >>>>>>> the a Diameter EAP-Answer message SHOULD be a failure >>>>>> Result-Code and >>>>>>> no EAP-Master-Session-Key AVP is present." >>>>>>> >>>>>>> [LM] By the way, I don't understand the "SHOULD" for the >>>>>> result-code. Any reason not to use "MUST" here? >>>>>> >>>>>> I think a MUST would be better. Different views ? >>>>>> >>>>>>> [LM] a figure could be added for illustration here. >>>>>>> >>>>>>> 4.2. DSRK Request and Delivery >>>>>>> >>>>>>> A local ER server, collocated with a Diameter proxy in >>>> the peer's >>>>>>> visited domain, >>>>>>> >>>>>>> [LM] s/in the peer's visited domain/in the domain visited >>>>> by the peer >>>>>>> may request a DSRK from the EAP server, either in the >>>>>>> initial EAP exchange (implicit bootstrapping) or in an ERP >>>>>>> bootstrapping exchange (explicit bootstrapping). It >>>> does this by >>>>>>> including the EAP-DSRK-Request AVP in the Diameter EAP-Response >>>>>>> message. The EAP-DSRK-Request AVP contains the domain or = >>>>>>> server >>>>>>> identity required to derive the DSRK. >>>>>>> >>>>>>> [LM] the EAP-DSRK-Request AVP is included in the Diameter >>>>>> EAP-Request >>>>>>> (and not in the response) >>>>>> yes. >>>>>> >>>>>>> An EAP server MAY send the DSRK when it receives a >>>> valid Diameter >>>>>>> EAP-Request message containing an EAP-DSRK-Request AVP. >>>>>> An ER server >>>>>>> MUST send the DSRK (or send a failure result) when it = >>>>>>> receives a >>>>>>> valid Diameter EAP-Request message containing an >>>>>> EAP-DSRK-Request AVP >>>>>>> along with a valid EAP Initiate Re-auth packet with the >>>>>> bootstrapping >>>>>>> flag turned on. If an EAP-DSRK-Request AVP is included in >>>>>> any other >>>>>>> Diameter EAP-Request message, the Diameter server MUST >>>>> reply with a >>>>>>> failure result. An EAP-DSRK AVP MUST be used to send a >>>>>> DSRK; an EAP- >>>>>>> DSRK-Name AVP MUST be used to send the DSRK's keyname; >>>>> and an EAP- >>>>>>> DSRK-Lifetime AVP MUST be used to send the DSRK's lifetime. >>>>>>> >>>>>>> [LM] I don't understand the intention of the above text. >>>>>> Could it be enough to say: >>>>>>> In successful case, the DSRK is carried by the EAP-DSRK >>>>> AVP in the >>>>>>> Diameter EAP response message. Along with the EAP-DSRK AVP, an >>>>>>> EAP-DSRK-Name AVP MUST be used to send the DSRK's keyname and = >>>>>>> an >>>>>>> EAP-DSRK-Lifetime AVP MUST be used to send the DSRK's lifetime. >>>>>> Agree. >>>>>> >>>>>>> [LM] a figure could be added for illustration here. >>>>>>> >>>>>>> 5. Command Codes >>>>>>> >>>>>>> [LM] this section is not required as there is nothing >>>>>> specific for ERP. We should skip it. >>>>>>> [SKIP] >>>>>>> >>>>>>> >>>>>>> 6. Attribute Value Pair Definitions >>>>>>> >>>>>>> 6.1. EAP-DSRK-Request AVP >>>>>>> >>>>>>> The EAP-DSRK AVP (AVP Code TBD) is of type DiameterIdentity. >>>>>>> >>>>>>> [LM] s/EAP-DSRK AVP/EAP-DSRK-Request AVP >>>>>>> >>>>>>> This >>>>>>> AVP fulfills two purposes: First, it indicates that a ER >>>>> server is >>>>>>> located in the local domain that is willing to play the >>>>>> role of an ER >>>>>>> server for a particular session. Second, it conveys = >>>>>>> information >>>>>>> about the domain and ER server identity to the >>>>> Diameter/EAP server. >>>>>>> [LM] the use of this AVP is explained above. There is no >>>>>> need to explain again. >>>>>> >>>>>> As we are in the AVP Definitions, I think it is better to >>>> keep some >>>>>> text explaining it. No ? >>>>>> >>>>>>> Moreover, if a DiameterIdentity is used, it is to indicate a >>>>>> server and not a domain. Right? >>>>>> >>>>>> In my understanding the local ER server only sends the Domain = >>>>>> Name >>>>>> which will then be used to compute keys. Maybe the type >>>>>> DiameterIdentity is not appropriated and we should use UTF8String >>>>>> instead. What do you think ? >>>>>> >>>>>> >>>>>>> 6.2. EAP-DSRK AVP >>>>>>> >>>>>>> The EAP-DSRK AVP (AVP Code TBD) is of type OctetString. >>>>> The Domain >>>>>>> Specific Root Key (DSRK) is carried in this payload. >>>>>>> >>>>>>> 6.3. EAP-DSRK-Name AVP >>>>>>> >>>>>>> The EAP-DSRK-Name AVP (AVP Code TBD) is of type >>>>> OctetString. This >>>>>>> AVP contains the name of the DSRK key that is later used >>>>> during the >>>>>>> re-authentication exchange to select the correct DSRK. >>>>>>> >>>>>>> [LM] skip the part starting by "that is..." >>>>>> ok >>>>>> >>>>>>> 6.4. EAP-DSRK-Lifetime AVP >>>>>>> >>>>>>> The EAP-DSRK-Lifetime AVP (AVP Code TBD) is of type >>>>> Unsigned64 and >>>>>>> contains the DSRK lifetime in seconds. >>>>>>> >>>>>>> >>>>>>> 7. AVP Occurrence Table >>>>>>> >>>>>>> The following table lists the AVPs that may optionally be >>>>>> present in >>>>>>> the DER and DEA commands [1]. >>>>>>> >>>>>>> >>>>>>> +---------------+ >>>>>>> | Command-Code | >>>>>>> +-+-----+-----+-+ >>>>>>> Attribute Name | DER | DEA | >>>>>>> -------------------------------|-----+-----+ >>>>>>> EAP-DSRK-Request | 0-1 | 0 | >>>>>>> EAP-DSRK | 0 | 0-1 | >>>>>>> EAP-DSRK-Name | 0 | 0-1 | >>>>>>> EAP-DSRK-Lifetime | 0 | 0-1 | >>>>>>> +-----+-----+ >>>>>>> >>>>>>> Figure 4: DER and DEA Commands AVP Table >>>>>>> >>>>>>> When the EAP-DSRK AVP is present in the DEA then the >>>>> EAP-DSRK-Name >>>>>>> and the EAP-DSRK-Lifetime MUST also be present. >>>>>>> >>>>>>> >>>>>>> 8. AVP Flag Rules >>>>>>> >>>>>>> The following table describes the Diameter AVPs, their AVP Code >>>>>>> values, types, possible flag values, and whether the AVP MAY be >>>>>>> encrypted. The Diameter base [4] specifies the AVP Flag >>>>> rules for >>>>>>> AVPs in Section 4.5. >>>>>>> >>>>>>> >>>>>>> = >>>>>>> +---------------------+ >>>>>>> | AVP Flag = >>>>>>> Rules | >>>>>>> >>>>>> +----+-----+----+-----+----+ >>>>>>> AVP Section | | >>>>>> |SHLD|MUST | | >>>>>>> Attribute Name Code Defined Data Type |MUST| MAY |NOT >>>>>> |NOT |Encr| >>>>>> ------------------------------------------+----+-----+----+-- >>>>> ---+----+ >>>>>>> EAP-DSRK-Request TBD 4.7.1 DiamIdent | | P | | >>>>>> V,M | Y | >>>>>>> EAP-DSRK TBD 4.7.2 OctetString| | P | | >>>>>> V,M | Y | >>>>>>> EAP-DSRK-Name TBD 4.7.3 OctetString| | P | | >>>>>> V,M | Y | >>>>>>> EAP-DSRK-Lifetime TBD 4.7.4 Unsigned64 | | P | | >>>>>> V,M | Y | >>>>>>> >>>>>> ------------------------------------------+----+-----+----+-- >>>>> ---+----+ >>>>>>> Due to space constraints, the short form DiamIdent is used to >>>>>>> represent DiameterIdentity. >>>>>>> >>>>>>> Figure 5: AVP Flag Rules Table >>>>>>> >>>>>>> [LM] this table is ok according to the current RFC 3588. I >>>>>> don't know how to deal with it regarding the RFC3588bis... >>>>>> >>>>>> >>>>>> That's indeed a good question :). >>>>>> >>>>>> And that's all for my comments of your comments. >>>>>> >>>>>> Regards, >>>>>> >>>>>> --Julien-- >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Jan 10 05:14:37 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8313028C19F; Sat, 10 Jan 2009 05:14:37 -0800 (PST) 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 868E128C19F for ; Sat, 10 Jan 2009 05:14:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=0.361, 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 yUmWRQt9f3-4 for ; Sat, 10 Jan 2009 05:14:30 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id F19D328C19B for ; Sat, 10 Jan 2009 05:14:29 -0800 (PST) Received: (qmail invoked by alias); 10 Jan 2009 13:14:14 -0000 Received: from a91-154-105-43.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.105.43] by mail.gmx.net (mp048) with SMTP; 10 Jan 2009 14:14:14 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19qONZ2vZVqGCIcxUljfyeK7dfLCLo5+TMVef2E1r XFnAMqvpH30w4C From: "Hannes Tschofenig" To: , "'Tom Taylor'" References: <7DBAFEC6A76F3E42817DF1EBE64CB026061E2759@ftrdmel2> <5e2406980901080218w746b69a7x320f1501aeb97266@mail.gmail.com> <7DBAFEC6A76F3E42817DF1EBE64CB0260622C4DE@ftrdmel2> <5e2406980901090115m2fe2c097nee9854a9ed870127@mail.gmail.com> <49677A85.2030607@rogers.com> Date: Sat, 10 Jan 2009 15:14:45 +0200 Message-ID: <023801c97325$68712700$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclzIZlPqmOMn8kvTfuqJp9nxAV9xAAA4HHQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Cc: dime@ietf.org Subject: Re: [Dime] Review of the Diameter ERP 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Tom, Hi Tina, = I believe you are misunderstanding the Diameter ERP usage (could also be me). = We are not talking about "route-pinning" AAA routing but rather whether the definition of AVPs is sufficient for the design or whether a Diameter application. = Ciao Hannes >-----Original Message----- >From: diameter-routing@googlegroups.com = >[mailto:diameter-routing@googlegroups.com] On Behalf Of Tina TSOU >Sent: 10 January, 2009 14:47 >To: Tom Taylor >Cc: Julien Bournelle; Tschofenig, Hannes (NSN - FI/Espoo); = >dime@ietf.org; diameter-routing@googlegroups.com >Subject: Re: [Dime] Review of the Diameter ERP draft > > >Hi Tom, >Thanks for your comments. >I will update the = >draft-tsou-dime-routing-problem-statement-01, adding this use = >case for the 2nd problem, hopefully before the design team = >meeting next Thursday. >The design team discussion could be found in = >http://groups.google.com/group/diameter-routing?hl=3Den > > >B. R. >Tina >Messengers: > >MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU = >Jabber: tina@jabber.org Google talk: tinatsou6@gmail.com > >+86-755-28971872 (Office) +86-13922884380(Mobile) > > > > > > > >On Jan 10, 2009, at 12:25 AM, Tom Taylor wrote: > >> An use case for the second problem talked about in the = >routing design = >> team! >> >> Julien Bournelle wrote: >>> Hi, >>> On Fri, Jan 9, 2009 at 8:57 AM, Tschofenig, Hannes (NSN - FI/Espoo) = >>> wrote: >>>> My reading of this text is that there is a way for the = >peer and the = >>>> authenticator to figure out whether to use EAP or ERP. >>> I don't see how a new App Id will help peer and authenticator to = >>> figure out ERP support. I may miss something here. >>> My understanding is that a new Appid would however help AAA = >entities = >>> (authenticator, proxy, server) figure out ERP support. >>>> It, however, says very little about the further routing of AAA = >>>> messages in such a way that the messages traverse nodes = >>>> understanding the additionally required functionality. If I = >>>> understood ERP correctly then some key caching takes place in the = >>>> AAA proxies and hence one wants to make sure that the messages are = >>>> actually routed via these proxies. >>> Yes, ideally, for a given peer, the same AAA proxy/local ERP server = >>> should be contacted by authenticators. At this point, I = >don't see how = >>> to ensure this. >>> Regards, >>> Julien >>>> Ciao >>>> Hannes >>>> >>>> >>>>> -----Original Message----- >>>>> From: ext lionel.morand@orange-ftgroup.com = >>>>> [mailto:lionel.morand@orange-ftgroup.com] >>>>> Sent: 08 January, 2009 22:26 >>>>> To: Tschofenig, Hannes (NSN - FI/Espoo); = >>>>> julien.bournelle@gmail.com; sdecugis@hongo.wide.ad.jp; = >>>>> dime@ietf.org >>>>> Subject: RE: [Dime] Review of the Diameter ERP draft >>>>> >>>>> According to the RFC 5296, it seems that it is not = >required to have = >>>>> a specific Appl-ID: >>>>> >>>>> "It is plausible that the authenticator does not know whether the = >>>>> peer supports ERP and whether the peer has performed a full EAP = >>>>> authentication through another authenticator. The authenticator = >>>>> MAY initiate the ERP exchange by sending the = >EAP-Initiate/Re-auth- = >>>>> Start message, and if there is no response, it will send = >the EAP- = >>>>> Request/ Identity message. Note that this avoids having two EAP = >>>>> messages in flight at the same time [2]. The authenticator may = >>>>> send the EAP- Initiate/Re-auth-Start message and wait = >for a short, = >>>>> locally configured amount of time. If the peer does not already = >>>>> know, this message indicates to the peer that the authenticator = >>>>> supports ERP. >>>>> In response to this trigger from the authenticator, the = >peer can = >>>>> initiate the ERP exchange by sending an EAP-Initiate/Re-auth = >>>>> message. >>>>> If there is no response from the peer after the necessary = >>>>> retransmissions (see Section 6), the authenticator MUST initiate = >>>>> EAP by sending an EAP-Request message, typically the = >>>>> EAP-Request/Identity message. Note that the authenticator may = >>>>> receive an EAP-Initiate/ Re-auth message after it has sent an = >>>>> EAP-Request/Identity message. >>>>> If the authenticator supports ERP, it MUST proceed with the ERP = >>>>> exchange. When the EAP-Request/Identity times out, the = >>>>> authenticator MUST NOT close the connection if an ERP = >exchange is = >>>>> in progress or has already succeeded in establishing a = >>>>> re-authentication MSK. >>>>> >>>>> If the authenticator does not support ERP, it drops = >EAP-Initiate/ = >>>>> Re-auth messages [2] as the EAP code of those packets is greater = >>>>> than 4. An ERP-capable peer will exhaust the = >EAP-Initiate/Re-auth = >>>>> message retransmissions and fall back to EAP authentication by = >>>>> responding to EAP Request/Identity messages from the = >>>>> authenticator. If the peer does not support ERP or if = >it does not = >>>>> have unexpired key material from a previous EAP = >authentication, it = >>>>> drops EAP-Initiate/ Re-auth-Start messages. If there is no = >>>>> response to the EAP-Initiate/ Re-auth-Start message, the = >>>>> authenticator SHALL send an EAP Request message (typically EAP = >>>>> Request/Identity) to start EAP authentication. >>>>> From this stage onwards, RFC 3748 rules apply. Note = >that this may = >>>>> introduce some delay in starting EAP. In some lower layers, the = >>>>> delay can be minimized or even avoided by the peer initiating EAP = >>>>> by sending messages such as EAPoL-Start in the IEEE 802.1X = >>>>> specification [10]." >>>>> >>>>> Both paragraphs assume (for me) that the ERP "option" may be = >>>>> supported by the peer and/or the network. If none of them = >(or only = >>>>> one of them) support ERP, the fallback mechanism is full EAP = >>>>> authentication. >>>>> In that sense, knowing that the network supports ERP is not a = >>>>> pre-requisite. The minimum is to support EAP and ERP is an option = >>>>> available above EAP. That allows to deploy ERP above existing EAP = >>>>> deployment. >>>>> >>>>> Does it make sense? >>>>> >>>>> Best Regards, >>>>> >>>>> Lionel >>>>> >>>>> >>>>>> -----Message d'origine----- >>>>>> De : Tschofenig, Hannes (NSN - FI/Espoo) = >>>>>> [mailto:hannes.tschofenig@nsn.com] >>>>>> Envoy=E9 : jeudi 8 janvier 2009 13:55 =C0 : ext Julien Bournelle; = >>>>>> MORAND Lionel RD-CORE-ISS; Sebastien Decugis; = >dime@ietf.org Objet = >>>>>> : RE: [Dime] Review of the Diameter ERP draft >>>>>> >>>>>> One of the things I was not quite sure with the current protocol = >>>>>> design is whether a Diameter application or just a bunch of AVPs = >>>>>> are required. >>>>>> Based on the discussions a few of us when some of the HOKEY >>>>> specs went >>>>>> to the IESG / IETF Last Call I got the impression that = >one has to = >>>>>> define a new Diameter application (which would be based on = >>>>>> Diameter >>>>>> EAP) since you assume that the messages are routed via a node in = >>>>>> the local network and the support for ERP has to be ensured. >>>>>> >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] >>>>>> On Behalf Of >>>>>>> ext Julien Bournelle >>>>>>> Sent: 08 January, 2009 12:18 >>>>>>> To: lionel.morand@orange-ftgroup.com; Sebastien Decugis; >>>>>> dime@ietf.org >>>>>>> Subject: Re: [Dime] Review of the Diameter ERP draft >>>>>>> >>>>>>> Hi lionel, >>>>>>> >>>>>>> some comments inline. >>>>>>> >>>>>>> On Wed, Jan 7, 2009 at 12:03 PM, >>>>>>> wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Here is my review for the Diameter ERP draft. >>>>>>>> >>>>>>>> General comments: >>>>>>>> >>>>>>>> - About alignment with RFC 5296: >>>>>>>> the draft needs to be updated according to the publication >>>>>>> of the RFC 5296. Some proposals are provided below. >>>>>>>> - About ER server/AAA agent co-location: >>>>>>>> In my understanding, it is assumed in this document ER >>>>>>> server and AAA proxy have to be co-located to be able = >to rely on = >>>>>>> Diameter to transport ERP specific AVPs. This doesn't maybe >>>>> preclude >>>>>>> other architectural choices but there are outside the scope of = >>>>>>> this document. It is necessary to clarify this point in this = >>>>>>> document. >>>>>>>> - ERP support discovery: >>>>>>>> As the ERP specific AVPs are introduced with the M-bit >>>>>>> cleared, these AVPs are purely optional for the Diameter EAP = >>>>>>> application i.e. they can be silently ignored by Diameter >>>>>> servers that >>>>>>> do not understand this new AVPs. Some text should be = >provided to = >>>>>>> describe how the local ER server discovers that the Home EAP = >>>>>>> server doesn't support ERP and the behaviour of the local ER >>>>> server in that >>>>>>> case. >>>>>>> >>>>>>> >>>>>>> I agree with these general comments. >>>>>>> >>>>>>> >>>>>>>> Hereafter is the rest of my review with comments and proposals. >>>>>>>> >>>>>>>> Best Regards, >>>>>>>> >>>>>>>> Lionel >>>>>>>> >>>>>>>> *************************************** >>>>>>>> >>>>>>>> Abstract >>>>>>>> >>>>>>>> An EAP extension, called "EAP Re-authentication Protocol >>>>>>> (ERP)", has >>>>>>>> been specified that supports an EAP method-independent >>>>>> protocol for >>>>>>>> efficient re-authentication between the peer and the >>>>>> server through >>>>>>>> an authenticator. This document specifies Diameter >>>>>>> support for ERP. >>>>>>>> The Diameter EAP application is re-used for >>>>>> encapsulating the newly >>>>>>>> defined EAP Initiate and EAP Finish messages specified >>>>> in the ERP >>>>>>>> specification. AVPs for request and delivery of Domain >>>>>>> Specific Root >>>>>>>> Keys from the AAA/EAP server to the ER server are also >>>>> specified. >>>>>>>> Additionally, this document also specifies Diameter >>>>>>> processing rules >>>>>>>> relevant to ERP. >>>>>>>> >>>>>>>> [LM] some abusive verbiage in the abstract: >>>>>>>> >>>>>>>> Proposal for new abstract: >>>>>>>> >>>>>>>> "EAP Re-authentication Protocol defines extensions of EAP >>>>>>> to support >>>>>>>> efficient re-authentication between the peer and an EAP = >>>>>>>> re-authentication server through any authenticator. >>>>>>> I'm wondering if we should note that the authenticator may be = >>>>>>> ERP-aware. >>>>>>> I'm thinking about the case where the authenticator sends the = >>>>>>> EAP-Initiate/Re-auth-Start (Figure 4 in RFC 5296) >>>>>>> >>>>>>> >>>>>>>> This document >>>>>>>> specifies Diameter support for ERP. The Diameter EAP >>>>>> application is >>>>>>>> re-used for encapsulating the newly defined EAP messages >>>>>> specified >>>>>>>> in the ERP specification. Additionally, this document >>>>>> also defines >>>>>>>> specific Diameter processing rules relevant to ERP." >>>>>>> ok >>>>>>> >>>>>>>> >>>>>>>> 1. Introduction >>>>>>>> >>>>>>>> RFC 4072 [1] specifies a Diameter application that = >carries EAP = >>>>>>>> packets between a Diameter client and the Diameter >>>>>>> Server/EAP server. >>>>>>>> [2] defines the EAP Re-authentication Protocol to allow >>>>>> faster re- >>>>>>>> authentication of a previously authenticated peer. >>>>>>>> >>>>>>>> [LM] s/[2] defines the EAP Re-authentication Protocol/RFC >>>>> 5296 [2] >>>>>>>> defines the EAP Re-authentication Protocol (ERP) >>>>>>>> >>>>>>>> In ERP, a peer >>>>>>>> authenticates to the network by proving possession of >>>>>> key material >>>>>>>> derived during a previous EAP exchange. >>>>>>>> >>>>>>>> [LM] s/a peer authenticate to/a peer is authenticated by >>>>>>>> >>>>>>>> For this purpose, an >>>>>>>> Extended Master Session Key (EMSK) based = >re-authentication key = >>>>>>>> hierarchy has been defined [5]. ERP may be executed >>>>>> between the ER >>>>>>>> peer and an ER server in the peer's home domain or the >>>>>> local domain >>>>>>>> visited by the peer. In the latter case, a Domain >>>>>> Specific Root Key >>>>>>>> (DSRK), derived from the EMSK, is provided to the local >>>>> domain ER >>>>>>>> server. >>>>>>>> >>>>>>>> [LM] s/is provided to/is provided by the Home ER server to >>>>>>>> >>>>>>>> The peer and the local server subsequently use the re- = >>>>>>>> authentication key hierarchy from the DSRK to authenticate >>>>>>> and derive >>>>>>>> authenticator specific keys within that domain. >>>>>>>> >>>>>>>> [LM] this information can be found in the RFC 5296. Remove >>>>>>> the sentence above. >>>>>>> >>>>>>> It may help the reader to understand the purpose of this DRSK. >>>>>>> >>>>>>>> To accomplish the >>>>>>>> reauthentication functionality, ERP defines two new EAP >>>>>> codes - EAP >>>>>>>> Initiate and EAP Finish. >>>>>>>> >>>>>>>> [LM] s/ERP defines two new EAP codes/ERP defines two new >>>>>> EAP messages >>>>>>> I would prefer to say that ERP defines two new EAP Codes >>>>>> here. These >>>>>>> newly EAP packets are then carried in messages = >(dependent of the = >>>>>>> protocol used). >>>>>>> >>>>>>>> This document specifies the reuse of Diameter EAP = >application = >>>>>>>> to carry these new EAP messages. >>>>>>>> The DSRK can be obtained as part of the regular EAP >>>>>> exchange or as >>>>>>>> part of an ERP bootstrapping exchange. The local ER server = >>>>>>>> requesting the DSRK needs to be in the path of the EAP or ERP = >>>>>>>> bootstrapping exchange in order to request and obtain the >>>>>>> DSRK. This >>>>>>>> document also specifies how the DSRK is transported to >>>>>> the local ER >>>>>>>> server using Diameter. >>>>>>>> >>>>>>>> [LM] Finally, i would reorganize the last part as follow: >>>>>>>> >>>>>>>> ::::::::::: >>>>>>>> >>>>>>>> "In ERP, a peer is authenticated by the network thanks to >>>>>>> keying material >>>>>>>> obtained during a previous EAP exchange. This keying >>>>>>> material is derived >>>>>>>> from the Extended Master Session Key (EMSK) defined in the >>>>>>> RFC 5295 [5]. >>>>>>>> To accomplish the EAP reauthentication functionality, ERP >>>>>>> defines two new >>>>>>>> EAP messages - EAP Initiate and EAP Finish. This document >>>>>>> specifies the >>>>>>>> reuse of Diameter EAP Application to carry these new EAP >>>>>> messages. >>>>>>>> ERP is executed between the peer and a server located >>>>>>> either in the peer's >>>>>>>> home domain or in the local domain visited by the peer. In >>>>>>> the latter case, >>>>>>>> a Domain Specific Root Key (DSRK) is derived from the >>>>>>> EMSK, as defined in >>>>>>>> the RFC 5295 [5], and is provided by the Home EAP server >>>>>>> to the local domain >>>>>>>> server. For that purpose, this document specifies the >>>>>>> transport of the DSRK >>>>>>>> using the Diameter EAP Application." >>>>>>> First paragraph is the old and second the new ? >>>>>>> >>>>>>>> :::::::::::::: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2. Terminology >>>>>>>> >>>>>>>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", >>>>>> "SHALL NOT", >>>>>>>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and >>>>>>> "OPTIONAL" in this >>>>>>>> document are to be interpreted as described in RFC 2119 [3]. >>>>>>>> >>>>>>>> This document uses terminology defined in [6], [5], >>>>> [2], and [1]. >>>>>>>> >>>>>>>> 3. Assumptions >>>>>>>> >>>>>>>> This document defines additional optional AVPs for >>>>> usage with the >>>>>>>> Diameter EAP application. Routing of these messages is >>>>> therefore >>>>>>>> provided via the Diameter Application Identifier = >(among other = >>>>>>>> elements), as specified by the Diameter Base protocol [4]. >>>>>>>> >>>>>>>> [LM] To avoid any ambiguity I would say: >>>>>>>> >>>>>>>> "This document defines only additional optional AVPs for >>>>>> usage with >>>>>>>> the Diameter EAP application. This document does not defined >>>>>>>> a new Diameter application and a new Application ID is >>>>>>> therefore not >>>>>>>> required, as described in the Diameter Base protocol [4]." >>>>>>> ok >>>>>>> >>>>>>>> Based on >>>>>>>> the deployment of ERP, a local Diameter server (the = >same entity = >>>>>>>> serves as a Diameter proxy during the full EAP >>>>>> authentication) may >>>>>>>> play the role of the ER server for future >>>>>>> re-authentication attempts. >>>>>>>> As such, the local Diameter server requesting the DSRK >>>>>>> needs to be in >>>>>>>> the path of the current EAP exchange between the peer >>>>> and the EAP >>>>>>>> server and also along in the future. The Diameter client is = >>>>>>>> furthermore assumed to be able to route the re-authentication = >>>>>>>> messages to the ER server. >>>>>>>> >>>>>>>> [LM] I think that the assumption all along this document is >>>>>>> that the local ER server and the AAA agent are co-located, >>>>>> to be able >>>>>>> to rely on DEA for the transport of DSRK. In that case, I >>>>> would say >>>>>>> something like: >>>>>>>> "In this document, when EAP re-authentication is performed >>>>>>> in the domain >>>>>>>> visited by the peer, it is assumed that the local ER >>>>>>> server is co-located >>>>>>>> with a Diameter agent in the visited domain present in >>>>>>> the path of the full >>>>>>>> EAP exchange." >>>>>>> ok >>>>>>> >>>>>>>> >>>>>>>> 4. Diameter Support for ERP >>>>>>>> >>>>>>>> 4.1. Protocol Overview >>>>>>>> >>>>>>>> Diameter may be used to transport ERP messages between the NAS >>>>>>>> (authenticator) and an authentication server (ER server). >>>>>>>> >>>>>>>> [LM] s/may/is (the use of Diameter is a pre-requisite in >>>>>> this draft) >>>>>>>> In ERP, the peer sends an EAP Initiate Reauth message = >to the ER = >>>>>>>> server via the authenticator. >>>>>>>> >>>>>>>> [LM] s/"EAP Initiate Reauth message"/"EAP-Initiate/Re-auth >>>>>> message" >>>>>>>> (same all along the document) >>>>>>>> >>>>>>>> Alternatively, the NAS may send an EAP Initiate Reauth-Start = >>>>>>>> message to the peer to trigger >>>>> the start of >>>>>>>> ERP; the peer then responds with an EAP Initiate Reauth >>>>>> message to >>>>>>>> the NAS. >>>>>>>> >>>>>>>> [LM] s/"EAP Initiate Reauth-Start >>>>>>> message"/"EAP-Initiate/Re-auth-Start >>>>>>>> message" (same all along the document) >>>>>>>> >>>>>>>> The general guidelines for encapsulating EAP messages >>>>> in Diameter >>>>>>>> from RFC 4072 [1] apply to the new EAP messages defined >>>>>> for ERP as >>>>>>>> well. The EAP Initiate Reauth message is encapsulated >>>>> in an EAP- >>>>>>>> Payload AVP of a Diameter EAP-Request message by the NAS >>>>>>> and sent to >>>>>>>> the Diameter server. The NAS MUST copy the contents of >>>>> the value >>>>>>>> field of the 'rIKName as NAI' TLV or the peer-id TLV (when >>>>>>> the former >>>>>>>> is not present) of the EAP Initiate Reauth message into >>>>>> a User-Name >>>>>>>> AVP of the Diameter EAP-Request. >>>>>>>> >>>>>>>> [LM] I think that we are talking about the 'keyName-NAI' TLV >>>>>>> and not anymore the 'rIKName as NAI' TLV. >>>>>>> >>>>>>> Considering section 5.3.2 of RFC 5296. I agree. >>>>>>> >>>>>>>> Moreover, in which case the peer-id TLV would not be >>>>>> present for ERP? >>>>>>> Privacy ? >>>>>>> >>>>>>>> The ER server processes the EAP Initiate Reauth message in >>>>>>> accordance >>>>>>>> with [2], and if that is successful, it responds with an >>>>>> EAP Finish >>>>>>>> Reauth message indicating a success ('R' flag set to = >0). The = >>>>>>>> Diameter server MUST encapsulate the EAP Finish Reauth >>>>>> message with >>>>>>>> the R flag set to zero in an EAP-Payload AVP attribute of >>>>>>> a Diameter >>>>>>>> EAP-Answer message. An EAP-Master-Session-Key AVP >>>>>> included in the >>>>>>>> Diameter EAP-Answer contains the Re-authentication Master >>>>>>> Session Key >>>>>>>> (rMSK). The Diameter Result Code, if any, SHOULD be a >>>>>>> success Result >>>>>>>> Code. >>>>>>>> >>>>>>>> If the processing of the EAP Initiate Reauth message >>>>>> resulted in a >>>>>>>> failure, the Diameter server MUST encapsulate an EAP >>>>>> Finish Reauth >>>>>>>> message indicating failure ('R' flag set to 1) in an >>>>>>> EAP-Payload AVP >>>>>>>> of a Diameter EAP-Answer message. The Diameter Result >>>>>>> Code, if any, >>>>>>>> SHOULD be a failure Result Code. Whether an EAP = >Finish Reauth = >>>>>>>> message is sent at all is specified in [2]. >>>>>>>> >>>>>>>> [LM] the use of the 'R' flag is not relevant for Diameter EAP. >>>>>>>> [LM] according to the RFC, the EAP-Finish/Re-auth is sent >>>>>>> back in any case, success or failure. >>>>>>>> [LM] according to the above comments, I would rephrase the >>>>>>> text as follow: >>>>>>>> >>>>>>>> "The ER server processes the EAP Initiate Reauth message >>>>>>> in accordance >>>>>>>> with [2] and responds with an EAP-Finish/Re-auth message. >>>>>>> The Diameter >>>>>>>> server MUST encapsulate the EAP-Finish/Re-auth message within = >>>>>>>> an EAP-Payload AVP of a Diameter EAP-Answer message. >>>>>>>> In an EAP re-authentication successful case, an >>>>>>> EAP-Master-Session-Key >>>>>>>> AVP is included in the Diameter EAP-Answer message that >>>>>>> contains the >>>>>>>> Re-authentication Master Session Key (rMSK). The Diameter >>>>>>> Result-Code >>>>>>>> SHOULD be a success Result-Code. >>>>>>>> In an EAP re-authentication failure case, the Diameter >>>>>>> Result-Code of >>>>>>>> the a Diameter EAP-Answer message SHOULD be a failure >>>>>>> Result-Code and >>>>>>>> no EAP-Master-Session-Key AVP is present." >>>>>>>> >>>>>>>> [LM] By the way, I don't understand the "SHOULD" for the >>>>>>> result-code. Any reason not to use "MUST" here? >>>>>>> >>>>>>> I think a MUST would be better. Different views ? >>>>>>> >>>>>>>> [LM] a figure could be added for illustration here. >>>>>>>> >>>>>>>> 4.2. DSRK Request and Delivery >>>>>>>> >>>>>>>> A local ER server, collocated with a Diameter proxy in >>>>> the peer's >>>>>>>> visited domain, >>>>>>>> >>>>>>>> [LM] s/in the peer's visited domain/in the domain visited >>>>>> by the peer >>>>>>>> may request a DSRK from the EAP server, either in the = > initial = >>>>>>>> EAP exchange (implicit bootstrapping) or in an ERP = >>>>>>>> bootstrapping exchange (explicit bootstrapping). It >>>>> does this by >>>>>>>> including the EAP-DSRK-Request AVP in the Diameter = >EAP-Response = >>>>>>>> message. The EAP-DSRK-Request AVP contains the domain = >or server = >>>>>>>> identity required to derive the DSRK. >>>>>>>> >>>>>>>> [LM] the EAP-DSRK-Request AVP is included in the Diameter >>>>>>> EAP-Request >>>>>>>> (and not in the response) >>>>>>> yes. >>>>>>> >>>>>>>> An EAP server MAY send the DSRK when it receives a >>>>> valid Diameter >>>>>>>> EAP-Request message containing an EAP-DSRK-Request AVP. >>>>>>> An ER server >>>>>>>> MUST send the DSRK (or send a failure result) when it = >receives = >>>>>>>> a valid Diameter EAP-Request message containing an >>>>>>> EAP-DSRK-Request AVP >>>>>>>> along with a valid EAP Initiate Re-auth packet with the >>>>>>> bootstrapping >>>>>>>> flag turned on. If an EAP-DSRK-Request AVP is included in >>>>>>> any other >>>>>>>> Diameter EAP-Request message, the Diameter server MUST >>>>>> reply with a >>>>>>>> failure result. An EAP-DSRK AVP MUST be used to send a >>>>>>> DSRK; an EAP- >>>>>>>> DSRK-Name AVP MUST be used to send the DSRK's keyname; >>>>>> and an EAP- >>>>>>>> DSRK-Lifetime AVP MUST be used to send the DSRK's lifetime. >>>>>>>> >>>>>>>> [LM] I don't understand the intention of the above text. >>>>>>> Could it be enough to say: >>>>>>>> In successful case, the DSRK is carried by the EAP-DSRK >>>>>> AVP in the >>>>>>>> Diameter EAP response message. Along with the = >EAP-DSRK AVP, an = >>>>>>>> EAP-DSRK-Name AVP MUST be used to send the DSRK's = >keyname and an = >>>>>>>> EAP-DSRK-Lifetime AVP MUST be used to send the DSRK's lifetime. >>>>>>> Agree. >>>>>>> >>>>>>>> [LM] a figure could be added for illustration here. >>>>>>>> >>>>>>>> 5. Command Codes >>>>>>>> >>>>>>>> [LM] this section is not required as there is nothing >>>>>>> specific for ERP. We should skip it. >>>>>>>> [SKIP] >>>>>>>> >>>>>>>> >>>>>>>> 6. Attribute Value Pair Definitions >>>>>>>> >>>>>>>> 6.1. EAP-DSRK-Request AVP >>>>>>>> >>>>>>>> The EAP-DSRK AVP (AVP Code TBD) is of type DiameterIdentity. >>>>>>>> >>>>>>>> [LM] s/EAP-DSRK AVP/EAP-DSRK-Request AVP >>>>>>>> >>>>>>>> This >>>>>>>> AVP fulfills two purposes: First, it indicates that a ER >>>>>> server is >>>>>>>> located in the local domain that is willing to play the >>>>>>> role of an ER >>>>>>>> server for a particular session. Second, it conveys = >>>>>>>> information about the domain and ER server identity to the >>>>>> Diameter/EAP server. >>>>>>>> [LM] the use of this AVP is explained above. There is no >>>>>>> need to explain again. >>>>>>> >>>>>>> As we are in the AVP Definitions, I think it is better to >>>>> keep some >>>>>>> text explaining it. No ? >>>>>>> >>>>>>>> Moreover, if a DiameterIdentity is used, it is to indicate a >>>>>>> server and not a domain. Right? >>>>>>> >>>>>>> In my understanding the local ER server only sends the Domain = >>>>>>> Name which will then be used to compute keys. Maybe the type = >>>>>>> DiameterIdentity is not appropriated and we should use = >UTF8String = >>>>>>> instead. What do you think ? >>>>>>> >>>>>>> >>>>>>>> 6.2. EAP-DSRK AVP >>>>>>>> >>>>>>>> The EAP-DSRK AVP (AVP Code TBD) is of type OctetString. >>>>>> The Domain >>>>>>>> Specific Root Key (DSRK) is carried in this payload. >>>>>>>> >>>>>>>> 6.3. EAP-DSRK-Name AVP >>>>>>>> >>>>>>>> The EAP-DSRK-Name AVP (AVP Code TBD) is of type >>>>>> OctetString. This >>>>>>>> AVP contains the name of the DSRK key that is later used >>>>>> during the >>>>>>>> re-authentication exchange to select the correct DSRK. >>>>>>>> >>>>>>>> [LM] skip the part starting by "that is..." >>>>>>> ok >>>>>>> >>>>>>>> 6.4. EAP-DSRK-Lifetime AVP >>>>>>>> >>>>>>>> The EAP-DSRK-Lifetime AVP (AVP Code TBD) is of type >>>>>> Unsigned64 and >>>>>>>> contains the DSRK lifetime in seconds. >>>>>>>> >>>>>>>> >>>>>>>> 7. AVP Occurrence Table >>>>>>>> >>>>>>>> The following table lists the AVPs that may optionally be >>>>>>> present in >>>>>>>> the DER and DEA commands [1]. >>>>>>>> >>>>>>>> >>>>>>>> +---------------+ >>>>>>>> | Command-Code | >>>>>>>> +-+-----+-----+-+ >>>>>>>> Attribute Name | DER | DEA | >>>>>>>> -------------------------------|-----+-----+ >>>>>>>> EAP-DSRK-Request | 0-1 | 0 | >>>>>>>> EAP-DSRK | 0 | 0-1 | >>>>>>>> EAP-DSRK-Name | 0 | 0-1 | >>>>>>>> EAP-DSRK-Lifetime | 0 | 0-1 | >>>>>>>> +-----+-----+ >>>>>>>> >>>>>>>> Figure 4: DER and DEA Commands AVP Table >>>>>>>> >>>>>>>> When the EAP-DSRK AVP is present in the DEA then the >>>>>> EAP-DSRK-Name >>>>>>>> and the EAP-DSRK-Lifetime MUST also be present. >>>>>>>> >>>>>>>> >>>>>>>> 8. AVP Flag Rules >>>>>>>> >>>>>>>> The following table describes the Diameter AVPs, = >their AVP Code = >>>>>>>> values, types, possible flag values, and whether the = >AVP MAY be = >>>>>>>> encrypted. The Diameter base [4] specifies the AVP Flag >>>>>> rules for >>>>>>>> AVPs in Section 4.5. >>>>>>>> >>>>>>>> >>>>>>>> = >>>>>>>> +---------------------+ >>>>>>>> | AVP Flag = >>>>>>>> Rules | >>>>>>>> >>>>>>> +----+-----+----+-----+----+ >>>>>>>> AVP Section | | >>>>>>> |SHLD|MUST | | >>>>>>>> Attribute Name Code Defined Data Type |MUST| MAY |NOT >>>>>>> |NOT |Encr| >>>>>>> ------------------------------------------+----+-----+----+-- >>>>>> ---+----+ >>>>>>>> EAP-DSRK-Request TBD 4.7.1 DiamIdent | | P | | >>>>>>> V,M | Y | >>>>>>>> EAP-DSRK TBD 4.7.2 OctetString| | P | | >>>>>>> V,M | Y | >>>>>>>> EAP-DSRK-Name TBD 4.7.3 OctetString| | P | | >>>>>>> V,M | Y | >>>>>>>> EAP-DSRK-Lifetime TBD 4.7.4 Unsigned64 | | P | | >>>>>>> V,M | Y | >>>>>>>> >>>>>>> ------------------------------------------+----+-----+----+-- >>>>>> ---+----+ >>>>>>>> Due to space constraints, the short form DiamIdent is used to = >>>>>>>> represent DiameterIdentity. >>>>>>>> >>>>>>>> Figure 5: AVP Flag Rules Table >>>>>>>> >>>>>>>> [LM] this table is ok according to the current RFC 3588. I >>>>>>> don't know how to deal with it regarding the RFC3588bis... >>>>>>> >>>>>>> >>>>>>> That's indeed a good question :). >>>>>>> >>>>>>> And that's all for my comments of your comments. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> --Julien-- >>>>>>> _______________________________________________ >>>>>>> DiME mailing list >>>>>>> DiME@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime > > >--~--~---------~--~----~------------~-------~--~----~ >You received this message because you are subscribed to the = >Google Groups "diameter-routing" group. >To post to this group, send email to = >diameter-routing@googlegroups.com To unsubscribe from this = >group, send email to diameter-routing+unsubscribe@googlegroups.com >For more options, visit this group at = >http://groups.google.com/group/diameter-routing?hl=3Den >-~----------~----~----~----~------~----~------~--~--- > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Jan 10 06:02:30 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 764FC3A6904; Sat, 10 Jan 2009 06:02:30 -0800 (PST) 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 8FFE93A6904 for ; Sat, 10 Jan 2009 06:02:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[AWL=0.347, 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 HnI+aHPyu7F6 for ; Sat, 10 Jan 2009 06:02:28 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 268033A68DF for ; Sat, 10 Jan 2009 06:02:27 -0800 (PST) Received: (qmail invoked by alias); 10 Jan 2009 14:02:13 -0000 Received: from a91-154-105-43.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.105.43] by mail.gmx.net (mp008) with SMTP; 10 Jan 2009 15:02:13 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1930pBJSM13Hh5OkntGjMucufe8dIChKkhC5tbn6P r4jXC+EJ1L+l7W From: "Hannes Tschofenig" To: "'David B. Nelson'" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" References: Date: Sat, 10 Jan 2009 16:02:43 +0200 Message-ID: <023a01c9732c$1c3ec200$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aclxqf2p8QFE/3aeSwOxYd7pwwXjNwBgAV4A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.52 Cc: aaa-doctors@ietf.org, dime@ietf.org Subject: Re: [Dime] [AAA-DOCTORS] RADIUS / Diameter compatibility boilerplate? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Dave, Thanks for the reminder. Based on the discussion we had with Pasi in context of the MIPv6 integrated document I tried to figure out how far we are with the deployment of RADIUS - Diameter translation agents. I got feedback, which I will try to summarize (as mentioned in my recent DIME status update message). Why does that activity relate to the issue of the boilerplate? We are writing something in our documents with a certain model of interworking in mind. For some reason, this interworking does not exist in today's deployment (based on the feedback I received) and so far I haven't received evidence that it will exist in the future. So, here is my thinking: * RADIUS and Diameter are different protocols with different deployment stories. * The data types in RADIUS and Diameter are different. There is overlap but RADIUS offers fewer data types than Diameter. * The design considerations in Diameter are different to the one in RADIUS. A big difference is the fact that Diameter has the concept of applications and RADIUS doesn't have those (ignoring some tiny details). The above-mentioned aspect might lead to different designs in RADIUS and in Diameter when considering the deployment environment and the available protocol mechanisms. This makes translation more complex. Since there is very little translation done (other with legacy systems) this does not really matter that much. This makes me believe that there should not be a requirement to write RADIUS Diameter consideration sections in the document. If document authors want to include Diameter solution aspects into the same document then they can obviously do that. This is a pure document management task. However, they have to consider the entire range of Diameter design considerations and this may lead to the need to define a Diameter application and hence the previously short section might be rather long. In any case, a WGLC should be posted to the DIME mailing list if there are Diameter considerations in the document. Does this make sense? Feedback from the DIME group? Ciao Hannes >-----Original Message----- >From: aaa-doctors-bounces@ietf.org >[mailto:aaa-doctors-bounces@ietf.org] On Behalf Of David B. Nelson >Sent: 08 January, 2009 17:59 >To: 'Tschofenig, Hannes (NSN - FI/Espoo)' >Cc: aaa-doctors@ietf.org >Subject: [AAA-DOCTORS] RADIUS / Diameter compatibility boilerplate? > >Hi Hannes, > >During the AAA Doctors lunch at IETF-73 you volunteered for >the action item of drafting some boilerplate / template text >for the required Diameter Considerations section of RADIUS >I-Ds and RFCs. How is that coming along? > >Regards, > >Dave > >David B. Nelson >Chief Software Architect >Elbrys Networks, Inc. >75 Rochester Ave. Unit 3 >Portsmouth, NH 03801 >Voice: +1 603.570.2636 >FAX: +1 603.766.0934 >Skype: david_b_nelson > > >_______________________________________________ >AAA-DOCTORS mailing list >AAA-DOCTORS@ietf.org >https://www.ietf.org/mailman/listinfo/aaa-doctors > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Jan 10 06:18:05 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E48F28C19E; Sat, 10 Jan 2009 06:18:05 -0800 (PST) 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 C3EBA3A6A19 for ; Sat, 10 Jan 2009 06:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.755 X-Spam-Level: X-Spam-Status: No, score=-1.755 tagged_above=-999 required=5 tests=[AWL=0.844, 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 EoOm8q3PY8eg for ; Sat, 10 Jan 2009 06:18:02 -0800 (PST) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id 831893A6904 for ; Sat, 10 Jan 2009 06:18:02 -0800 (PST) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA01.westchester.pa.mail.comcast.net with comcast id 1oMP1b00A0EZKEL51qHdRN; Sat, 10 Jan 2009 14:17:37 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA01.westchester.pa.mail.comcast.net with comcast id 1qHp1b0034H2mdz3MqHpRC; Sat, 10 Jan 2009 14:17:49 +0000 From: "Dave Nelson" To: , , References: <023a01c9732c$1c3ec200$0201a8c0@nsnintra.net> Date: Sat, 10 Jan 2009 09:17:58 -0500 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <023a01c9732c$1c3ec200$0201a8c0@nsnintra.net> Thread-Index: Aclxqf2p8QFE/3aeSwOxYd7pwwXjNwBgAV4AAACuiOA= Subject: Re: [Dime] [AAA-DOCTORS] RADIUS / Diameter compatibilityboilerplate? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Hannes, I've added RADEXT to the distribution, as well. I agree, based on your summary of the state of the art of translation gateways and the other issues you highlight, that the simple Diameter Considerations text that we've been using, modeled after the assumptions of the Diameter NAS Application (RFC 4005), is a bit misleading. If the recommendation turns out to be that there should not be simplistic RADIUS to Diameter interoperability, then I think there are two follow up issues: (1) Guidance on when Diameter clients and servers can and cannot use (or re-use) RADIUS attributes in the legacy <255 ID space. (2) A prohibition on Diameter documents defining and new AVPs in the legacy <255 ID space. I think there was an assumption that any attributes/AVPs in the legacy ID space would be interchangeable, is a simple fashion. Regards, Dave -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Saturday, January 10, 2009 9:03 AM To: 'David B. Nelson'; Tschofenig, Hannes (NSN - FI/Espoo) Cc: aaa-doctors@ietf.org; dime@ietf.org Subject: Re: [Dime] [AAA-DOCTORS] RADIUS / Diameter compatibilityboilerplate? Hi Dave, Thanks for the reminder. Based on the discussion we had with Pasi in context of the MIPv6 integrated document I tried to figure out how far we are with the deployment of RADIUS - Diameter translation agents. I got feedback, which I will try to summarize (as mentioned in my recent DIME status update message). Why does that activity relate to the issue of the boilerplate? We are writing something in our documents with a certain model of interworking in mind. For some reason, this interworking does not exist in today's deployment (based on the feedback I received) and so far I haven't received evidence that it will exist in the future. So, here is my thinking: * RADIUS and Diameter are different protocols with different deployment stories. * The data types in RADIUS and Diameter are different. There is overlap but RADIUS offers fewer data types than Diameter. * The design considerations in Diameter are different to the one in RADIUS. A big difference is the fact that Diameter has the concept of applications and RADIUS doesn't have those (ignoring some tiny details). The above-mentioned aspect might lead to different designs in RADIUS and in Diameter when considering the deployment environment and the available protocol mechanisms. This makes translation more complex. Since there is very little translation done (other with legacy systems) this does not really matter that much. This makes me believe that there should not be a requirement to write RADIUS Diameter consideration sections in the document. If document authors want to include Diameter solution aspects into the same document then they can obviously do that. This is a pure document management task. However, they have to consider the entire range of Diameter design considerations and this may lead to the need to define a Diameter application and hence the previously short section might be rather long. In any case, a WGLC should be posted to the DIME mailing list if there are Diameter considerations in the document. Does this make sense? Feedback from the DIME group? Ciao Hannes >-----Original Message----- >From: aaa-doctors-bounces@ietf.org >[mailto:aaa-doctors-bounces@ietf.org] On Behalf Of David B. Nelson >Sent: 08 January, 2009 17:59 >To: 'Tschofenig, Hannes (NSN - FI/Espoo)' >Cc: aaa-doctors@ietf.org >Subject: [AAA-DOCTORS] RADIUS / Diameter compatibility boilerplate? > >Hi Hannes, > >During the AAA Doctors lunch at IETF-73 you volunteered for >the action item of drafting some boilerplate / template text >for the required Diameter Considerations section of RADIUS >I-Ds and RFCs. How is that coming along? _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Jan 10 06:29:59 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABD3628C1C1; Sat, 10 Jan 2009 06:29:59 -0800 (PST) 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 E908A28C1C1 for ; Sat, 10 Jan 2009 06:29:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.334, 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 0eAeGh9kChKv for ; Sat, 10 Jan 2009 06:29:57 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 76D9A28C1BE for ; Sat, 10 Jan 2009 06:29:56 -0800 (PST) Received: (qmail invoked by alias); 10 Jan 2009 14:29:42 -0000 Received: from a91-154-105-43.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.105.43] by mail.gmx.net (mp045) with SMTP; 10 Jan 2009 15:29:42 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19kZIYvLVdkyMIoS2lR3eWaheECPb4gyIwX8k6iD5 gZqpnjSwZzV3d4 From: "Hannes Tschofenig" To: "'Dave Nelson'" , , , References: <023a01c9732c$1c3ec200$0201a8c0@nsnintra.net> Date: Sat, 10 Jan 2009 16:30:13 +0200 Message-ID: <023c01c9732f$f3654fd0$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aclxqf2p8QFE/3aeSwOxYd7pwwXjNwBgAV4AAACuiOAAAHxgMA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 Subject: Re: [Dime] [AAA-DOCTORS] RADIUS / Diameter compatibilityboilerplate? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Dave, There isn't too much space left in the <255 ID space and hence that consideration might not be too relevant in the future. I would not restrict the possibility to allocate RADIUS attributes (for example from the extended attribute space) in a Diameter document or todo Diameter AVP code allocation in a RADIUS document. The problem is that a more detailed investigation about this subject will take some time. Do you have that time? Ciao Hannes >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >Behalf Of Dave Nelson >Sent: 10 January, 2009 16:18 >To: aaa-doctors@ietf.org; dime@ietf.org; radiusext@ops.ietf.org >Subject: Re: [Dime] [AAA-DOCTORS] RADIUS / Diameter >compatibilityboilerplate? > >Hi Hannes, > >I've added RADEXT to the distribution, as well. > >I agree, based on your summary of the state of the art of >translation gateways and the other issues you highlight, that >the simple Diameter Considerations text that we've been using, >modeled after the assumptions of the Diameter NAS Application >(RFC 4005), is a bit misleading. > >If the recommendation turns out to be that there should not be >simplistic RADIUS to Diameter interoperability, then I think >there are two follow up >issues: > >(1) Guidance on when Diameter clients and servers can and >cannot use (or >re-use) RADIUS attributes in the legacy <255 ID space. > >(2) A prohibition on Diameter documents defining and new AVPs >in the legacy ><255 ID space. > >I think there was an assumption that any attributes/AVPs in >the legacy ID space would be interchangeable, is a simple fashion. > >Regards, > >Dave > >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >Behalf Of Hannes Tschofenig >Sent: Saturday, January 10, 2009 9:03 AM >To: 'David B. Nelson'; Tschofenig, Hannes (NSN - FI/Espoo) >Cc: aaa-doctors@ietf.org; dime@ietf.org >Subject: Re: [Dime] [AAA-DOCTORS] RADIUS / Diameter >compatibilityboilerplate? > >Hi Dave, > >Thanks for the reminder. > >Based on the discussion we had with Pasi in context of the >MIPv6 integrated document I tried to figure out how far we are >with the deployment of RADIUS >- Diameter translation agents. > >I got feedback, which I will try to summarize (as mentioned in >my recent DIME status update message). > >Why does that activity relate to the issue of the boilerplate? >We are writing something in our documents with a certain model >of interworking in mind. For some reason, this interworking >does not exist in today's deployment (based on the feedback I >received) and so far I haven't received evidence that it will >exist in the future. > >So, here is my thinking: > >* RADIUS and Diameter are different protocols with different >deployment stories. > >* The data types in RADIUS and Diameter are different. There >is overlap but RADIUS offers fewer data types than Diameter. > >* The design considerations in Diameter are different to the >one in RADIUS. >A big difference is the fact that Diameter has the concept of >applications and RADIUS doesn't have those (ignoring some tiny >details). > >The above-mentioned aspect might lead to different designs in >RADIUS and in Diameter when considering the deployment >environment and the available protocol mechanisms. > >This makes translation more complex. Since there is very >little translation done (other with legacy systems) this does >not really matter that much. > >This makes me believe that there should not be a requirement >to write RADIUS Diameter consideration sections in the document. > >If document authors want to include Diameter solution aspects >into the same document then they can obviously do that. This >is a pure document management task. However, they have to >consider the entire range of Diameter design considerations >and this may lead to the need to define a Diameter application >and hence the previously short section might be rather long. > >In any case, a WGLC should be posted to the DIME mailing list >if there are Diameter considerations in the document. > >Does this make sense? Feedback from the DIME group? > >Ciao >Hannes > >>-----Original Message----- >>From: aaa-doctors-bounces@ietf.org >>[mailto:aaa-doctors-bounces@ietf.org] On Behalf Of David B. Nelson >>Sent: 08 January, 2009 17:59 >>To: 'Tschofenig, Hannes (NSN - FI/Espoo)' >>Cc: aaa-doctors@ietf.org >>Subject: [AAA-DOCTORS] RADIUS / Diameter compatibility boilerplate? >> >>Hi Hannes, >> >>During the AAA Doctors lunch at IETF-73 you volunteered for >the action >>item of drafting some boilerplate / template text for the required >>Diameter Considerations section of RADIUS I-Ds and RFCs. How is that >>coming along? > > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Jan 10 06:39:02 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46AE83A67D7; Sat, 10 Jan 2009 06:39:02 -0800 (PST) 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 A0D6A28C1BC for ; Sat, 10 Jan 2009 06:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdLahzmVcUTv for ; Sat, 10 Jan 2009 06:38:58 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 6ED8928C19E for ; Sat, 10 Jan 2009 06:38:57 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KD9008R4FC85U@szxga04-in.huawei.com> for dime@ietf.org; Sat, 10 Jan 2009 22:38:33 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KD900K3KFC8MX@szxga04-in.huawei.com> for dime@ietf.org; Sat, 10 Jan 2009 22:38:32 +0800 (CST) Received: from [192.168.1.4] (102.175.60.58.broad.sz.gd.dynamic.163data.com.cn [58.60.175.102]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KD9003QAFC68Q@szxml02-in.huawei.com>; Sat, 10 Jan 2009 22:38:32 +0800 (CST) Date: Sat, 10 Jan 2009 22:38:30 +0800 From: Tina TSOU In-reply-to: <023801c97325$68712700$0201a8c0@nsnintra.net> To: Hannes Tschofenig Message-id: <35BEB771-94A8-41AF-B28C-B1E25B78FFF9@huawei.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.929.2) References: <7DBAFEC6A76F3E42817DF1EBE64CB026061E2759@ftrdmel2> <5e2406980901080218w746b69a7x320f1501aeb97266@mail.gmail.com> <7DBAFEC6A76F3E42817DF1EBE64CB0260622C4DE@ftrdmel2> <5e2406980901090115m2fe2c097nee9854a9ed870127@mail.gmail.com> <49677A85.2030607@rogers.com> <023801c97325$68712700$0201a8c0@nsnintra.net> Cc: dime@ietf.org, diameter-routing@googlegroups.com Subject: Re: [Dime] Review of the Diameter ERP 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: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="yes" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Hannes, Al right, if Tom does not have clarification to your comments, I will = not add it to draft-tsou-dime-routing-problem-statement-01. Anyway, other technical clarification needs to be added for problem 2. = I will try to fix it before next DT meeting on next Thursday. B. R. Tina Messengers: MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU = Jabber: tina@jabber.org Google talk: tinatsou6@gmail.com +86-755-28971872 (Office) +86-13922884380(Mobile) On Jan 10, 2009, at 9:14 PM, Hannes Tschofenig wrote: > Hi Tom, Hi Tina, > > I believe you are misunderstanding the Diameter ERP usage (could = > also be > me). > > We are not talking about "route-pinning" AAA routing but rather = > whether the > definition of AVPs is sufficient for the design or whether a Diameter > application. > > Ciao > Hannes > >> -----Original Message----- >> From: diameter-routing@googlegroups.com >> [mailto:diameter-routing@googlegroups.com] On Behalf Of Tina TSOU >> Sent: 10 January, 2009 14:47 >> To: Tom Taylor >> Cc: Julien Bournelle; Tschofenig, Hannes (NSN - FI/Espoo); >> dime@ietf.org; diameter-routing@googlegroups.com >> Subject: Re: [Dime] Review of the Diameter ERP draft >> >> >> Hi Tom, >> Thanks for your comments. >> I will update the >> draft-tsou-dime-routing-problem-statement-01, adding this use >> case for the 2nd problem, hopefully before the design team >> meeting next Thursday. >> The design team discussion could be found in >> http://groups.google.com/group/diameter-routing?hl=3Den >> >> >> B. R. >> Tina >> Messengers: >> >> MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU >> Jabber: tina@jabber.org Google talk: tinatsou6@gmail.com >> >> +86-755-28971872 (Office) +86-13922884380(Mobile) >> >> >> >> >> >> >> >> On Jan 10, 2009, at 12:25 AM, Tom Taylor wrote: >> >>> An use case for the second problem talked about in the >> routing design >>> team! >>> >>> Julien Bournelle wrote: >>>> Hi, >>>> On Fri, Jan 9, 2009 at 8:57 AM, Tschofenig, Hannes (NSN - FI/Espoo) >>>> wrote: >>>>> My reading of this text is that there is a way for the >> peer and the >>>>> authenticator to figure out whether to use EAP or ERP. >>>> I don't see how a new App Id will help peer and authenticator to >>>> figure out ERP support. I may miss something here. >>>> My understanding is that a new Appid would however help AAA >> entities >>>> (authenticator, proxy, server) figure out ERP support. >>>>> It, however, says very little about the further routing of AAA >>>>> messages in such a way that the messages traverse nodes >>>>> understanding the additionally required functionality. If I >>>>> understood ERP correctly then some key caching takes place in the >>>>> AAA proxies and hence one wants to make sure that the messages are >>>>> actually routed via these proxies. >>>> Yes, ideally, for a given peer, the same AAA proxy/local ERP server >>>> should be contacted by authenticators. At this point, I >> don't see how >>>> to ensure this. >>>> Regards, >>>> Julien >>>>> Ciao >>>>> Hannes >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: ext lionel.morand@orange-ftgroup.com >>>>>> [mailto:lionel.morand@orange-ftgroup.com] >>>>>> Sent: 08 January, 2009 22:26 >>>>>> To: Tschofenig, Hannes (NSN - FI/Espoo); >>>>>> julien.bournelle@gmail.com; sdecugis@hongo.wide.ad.jp; >>>>>> dime@ietf.org >>>>>> Subject: RE: [Dime] Review of the Diameter ERP draft >>>>>> >>>>>> According to the RFC 5296, it seems that it is not >> required to have >>>>>> a specific Appl-ID: >>>>>> >>>>>> "It is plausible that the authenticator does not know whether the >>>>>> peer supports ERP and whether the peer has performed a full EAP >>>>>> authentication through another authenticator. The authenticator >>>>>> MAY initiate the ERP exchange by sending the >> EAP-Initiate/Re-auth- >>>>>> Start message, and if there is no response, it will send >> the EAP- >>>>>> Request/ Identity message. Note that this avoids having two EAP >>>>>> messages in flight at the same time [2]. The authenticator may >>>>>> send the EAP- Initiate/Re-auth-Start message and wait >> for a short, >>>>>> locally configured amount of time. If the peer does not already >>>>>> know, this message indicates to the peer that the authenticator >>>>>> supports ERP. >>>>>> In response to this trigger from the authenticator, the >> peer can >>>>>> initiate the ERP exchange by sending an EAP-Initiate/Re-auth >>>>>> message. >>>>>> If there is no response from the peer after the necessary >>>>>> retransmissions (see Section 6), the authenticator MUST initiate >>>>>> EAP by sending an EAP-Request message, typically the >>>>>> EAP-Request/Identity message. Note that the authenticator may >>>>>> receive an EAP-Initiate/ Re-auth message after it has sent an >>>>>> EAP-Request/Identity message. >>>>>> If the authenticator supports ERP, it MUST proceed with the ERP >>>>>> exchange. When the EAP-Request/Identity times out, the >>>>>> authenticator MUST NOT close the connection if an ERP >> exchange is >>>>>> in progress or has already succeeded in establishing a >>>>>> re-authentication MSK. >>>>>> >>>>>> If the authenticator does not support ERP, it drops >> EAP-Initiate/ >>>>>> Re-auth messages [2] as the EAP code of those packets is greater >>>>>> than 4. An ERP-capable peer will exhaust the >> EAP-Initiate/Re-auth >>>>>> message retransmissions and fall back to EAP authentication by >>>>>> responding to EAP Request/Identity messages from the >>>>>> authenticator. If the peer does not support ERP or if >> it does not >>>>>> have unexpired key material from a previous EAP >> authentication, it >>>>>> drops EAP-Initiate/ Re-auth-Start messages. If there is no >>>>>> response to the EAP-Initiate/ Re-auth-Start message, the >>>>>> authenticator SHALL send an EAP Request message (typically EAP >>>>>> Request/Identity) to start EAP authentication. >>>>>> From this stage onwards, RFC 3748 rules apply. Note >> that this may >>>>>> introduce some delay in starting EAP. In some lower layers, the >>>>>> delay can be minimized or even avoided by the peer initiating EAP >>>>>> by sending messages such as EAPoL-Start in the IEEE 802.1X >>>>>> specification [10]." >>>>>> >>>>>> Both paragraphs assume (for me) that the ERP "option" may be >>>>>> supported by the peer and/or the network. If none of them >> (or only >>>>>> one of them) support ERP, the fallback mechanism is full EAP >>>>>> authentication. >>>>>> In that sense, knowing that the network supports ERP is not a >>>>>> pre-requisite. The minimum is to support EAP and ERP is an option >>>>>> available above EAP. That allows to deploy ERP above existing EAP >>>>>> deployment. >>>>>> >>>>>> Does it make sense? >>>>>> >>>>>> Best Regards, >>>>>> >>>>>> Lionel >>>>>> >>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : Tschofenig, Hannes (NSN - FI/Espoo) >>>>>>> [mailto:hannes.tschofenig@nsn.com] >>>>>>> Envoy=E9 : jeudi 8 janvier 2009 13:55 =C0 : ext Julien Bournelle; >>>>>>> MORAND Lionel RD-CORE-ISS; Sebastien Decugis; >> dime@ietf.org Objet >>>>>>> : RE: [Dime] Review of the Diameter ERP draft >>>>>>> >>>>>>> One of the things I was not quite sure with the current protocol >>>>>>> design is whether a Diameter application or just a bunch of AVPs >>>>>>> are required. >>>>>>> Based on the discussions a few of us when some of the HOKEY >>>>>> specs went >>>>>>> to the IESG / IETF Last Call I got the impression that >> one has to >>>>>>> define a new Diameter application (which would be based on >>>>>>> Diameter >>>>>>> EAP) since you assume that the messages are routed via a node in >>>>>>> the local network and the support for ERP has to be ensured. >>>>>>> >>>>>>> Ciao >>>>>>> Hannes >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] >>>>>>> On Behalf Of >>>>>>>> ext Julien Bournelle >>>>>>>> Sent: 08 January, 2009 12:18 >>>>>>>> To: lionel.morand@orange-ftgroup.com; Sebastien Decugis; >>>>>>> dime@ietf.org >>>>>>>> Subject: Re: [Dime] Review of the Diameter ERP draft >>>>>>>> >>>>>>>> Hi lionel, >>>>>>>> >>>>>>>> some comments inline. >>>>>>>> >>>>>>>> On Wed, Jan 7, 2009 at 12:03 PM, >>>>>>>> wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Here is my review for the Diameter ERP draft. >>>>>>>>> >>>>>>>>> General comments: >>>>>>>>> >>>>>>>>> - About alignment with RFC 5296: >>>>>>>>> the draft needs to be updated according to the publication >>>>>>>> of the RFC 5296. Some proposals are provided below. >>>>>>>>> - About ER server/AAA agent co-location: >>>>>>>>> In my understanding, it is assumed in this document ER >>>>>>>> server and AAA proxy have to be co-located to be able >> to rely on >>>>>>>> Diameter to transport ERP specific AVPs. This doesn't maybe >>>>>> preclude >>>>>>>> other architectural choices but there are outside the scope of >>>>>>>> this document. It is necessary to clarify this point in this >>>>>>>> document. >>>>>>>>> - ERP support discovery: >>>>>>>>> As the ERP specific AVPs are introduced with the M-bit >>>>>>>> cleared, these AVPs are purely optional for the Diameter EAP >>>>>>>> application i.e. they can be silently ignored by Diameter >>>>>>> servers that >>>>>>>> do not understand this new AVPs. Some text should be >> provided to >>>>>>>> describe how the local ER server discovers that the Home EAP >>>>>>>> server doesn't support ERP and the behaviour of the local ER >>>>>> server in that >>>>>>>> case. >>>>>>>> >>>>>>>> >>>>>>>> I agree with these general comments. >>>>>>>> >>>>>>>> >>>>>>>>> Hereafter is the rest of my review with comments and = >>>>>>>>> proposals. >>>>>>>>> >>>>>>>>> Best Regards, >>>>>>>>> >>>>>>>>> Lionel >>>>>>>>> >>>>>>>>> *************************************** >>>>>>>>> >>>>>>>>> Abstract >>>>>>>>> >>>>>>>>> An EAP extension, called "EAP Re-authentication Protocol >>>>>>>> (ERP)", has >>>>>>>>> been specified that supports an EAP method-independent >>>>>>> protocol for >>>>>>>>> efficient re-authentication between the peer and the >>>>>>> server through >>>>>>>>> an authenticator. This document specifies Diameter >>>>>>>> support for ERP. >>>>>>>>> The Diameter EAP application is re-used for >>>>>>> encapsulating the newly >>>>>>>>> defined EAP Initiate and EAP Finish messages specified >>>>>> in the ERP >>>>>>>>> specification. AVPs for request and delivery of Domain >>>>>>>> Specific Root >>>>>>>>> Keys from the AAA/EAP server to the ER server are also >>>>>> specified. >>>>>>>>> Additionally, this document also specifies Diameter >>>>>>>> processing rules >>>>>>>>> relevant to ERP. >>>>>>>>> >>>>>>>>> [LM] some abusive verbiage in the abstract: >>>>>>>>> >>>>>>>>> Proposal for new abstract: >>>>>>>>> >>>>>>>>> "EAP Re-authentication Protocol defines extensions of EAP >>>>>>>> to support >>>>>>>>> efficient re-authentication between the peer and an EAP >>>>>>>>> re-authentication server through any authenticator. >>>>>>>> I'm wondering if we should note that the authenticator may be >>>>>>>> ERP-aware. >>>>>>>> I'm thinking about the case where the authenticator sends the >>>>>>>> EAP-Initiate/Re-auth-Start (Figure 4 in RFC 5296) >>>>>>>> >>>>>>>> >>>>>>>>> This document >>>>>>>>> specifies Diameter support for ERP. The Diameter EAP >>>>>>> application is >>>>>>>>> re-used for encapsulating the newly defined EAP messages >>>>>>> specified >>>>>>>>> in the ERP specification. Additionally, this document >>>>>>> also defines >>>>>>>>> specific Diameter processing rules relevant to ERP." >>>>>>>> ok >>>>>>>> >>>>>>>>> >>>>>>>>> 1. Introduction >>>>>>>>> >>>>>>>>> RFC 4072 [1] specifies a Diameter application that >> carries EAP >>>>>>>>> packets between a Diameter client and the Diameter >>>>>>>> Server/EAP server. >>>>>>>>> [2] defines the EAP Re-authentication Protocol to allow >>>>>>> faster re- >>>>>>>>> authentication of a previously authenticated peer. >>>>>>>>> >>>>>>>>> [LM] s/[2] defines the EAP Re-authentication Protocol/RFC >>>>>> 5296 [2] >>>>>>>>> defines the EAP Re-authentication Protocol (ERP) >>>>>>>>> >>>>>>>>> In ERP, a peer >>>>>>>>> authenticates to the network by proving possession of >>>>>>> key material >>>>>>>>> derived during a previous EAP exchange. >>>>>>>>> >>>>>>>>> [LM] s/a peer authenticate to/a peer is authenticated by >>>>>>>>> >>>>>>>>> For this purpose, an >>>>>>>>> Extended Master Session Key (EMSK) based >> re-authentication key >>>>>>>>> hierarchy has been defined [5]. ERP may be executed >>>>>>> between the ER >>>>>>>>> peer and an ER server in the peer's home domain or the >>>>>>> local domain >>>>>>>>> visited by the peer. In the latter case, a Domain >>>>>>> Specific Root Key >>>>>>>>> (DSRK), derived from the EMSK, is provided to the local >>>>>> domain ER >>>>>>>>> server. >>>>>>>>> >>>>>>>>> [LM] s/is provided to/is provided by the Home ER server to >>>>>>>>> >>>>>>>>> The peer and the local server subsequently use the re- >>>>>>>>> authentication key hierarchy from the DSRK to authenticate >>>>>>>> and derive >>>>>>>>> authenticator specific keys within that domain. >>>>>>>>> >>>>>>>>> [LM] this information can be found in the RFC 5296. Remove >>>>>>>> the sentence above. >>>>>>>> >>>>>>>> It may help the reader to understand the purpose of this DRSK. >>>>>>>> >>>>>>>>> To accomplish the >>>>>>>>> reauthentication functionality, ERP defines two new EAP >>>>>>> codes - EAP >>>>>>>>> Initiate and EAP Finish. >>>>>>>>> >>>>>>>>> [LM] s/ERP defines two new EAP codes/ERP defines two new >>>>>>> EAP messages >>>>>>>> I would prefer to say that ERP defines two new EAP Codes >>>>>>> here. These >>>>>>>> newly EAP packets are then carried in messages >> (dependent of the >>>>>>>> protocol used). >>>>>>>> >>>>>>>>> This document specifies the reuse of Diameter EAP >> application >>>>>>>>> to carry these new EAP messages. >>>>>>>>> The DSRK can be obtained as part of the regular EAP >>>>>>> exchange or as >>>>>>>>> part of an ERP bootstrapping exchange. The local ER server >>>>>>>>> requesting the DSRK needs to be in the path of the EAP or ERP >>>>>>>>> bootstrapping exchange in order to request and obtain the >>>>>>>> DSRK. This >>>>>>>>> document also specifies how the DSRK is transported to >>>>>>> the local ER >>>>>>>>> server using Diameter. >>>>>>>>> >>>>>>>>> [LM] Finally, i would reorganize the last part as follow: >>>>>>>>> >>>>>>>>> ::::::::::: >>>>>>>>> >>>>>>>>> "In ERP, a peer is authenticated by the network thanks to >>>>>>>> keying material >>>>>>>>> obtained during a previous EAP exchange. This keying >>>>>>>> material is derived >>>>>>>>> from the Extended Master Session Key (EMSK) defined in the >>>>>>>> RFC 5295 [5]. >>>>>>>>> To accomplish the EAP reauthentication functionality, ERP >>>>>>>> defines two new >>>>>>>>> EAP messages - EAP Initiate and EAP Finish. This document >>>>>>>> specifies the >>>>>>>>> reuse of Diameter EAP Application to carry these new EAP >>>>>>> messages. >>>>>>>>> ERP is executed between the peer and a server located >>>>>>>> either in the peer's >>>>>>>>> home domain or in the local domain visited by the peer. In >>>>>>>> the latter case, >>>>>>>>> a Domain Specific Root Key (DSRK) is derived from the >>>>>>>> EMSK, as defined in >>>>>>>>> the RFC 5295 [5], and is provided by the Home EAP server >>>>>>>> to the local domain >>>>>>>>> server. For that purpose, this document specifies the >>>>>>>> transport of the DSRK >>>>>>>>> using the Diameter EAP Application." >>>>>>>> First paragraph is the old and second the new ? >>>>>>>> >>>>>>>>> :::::::::::::: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2. Terminology >>>>>>>>> >>>>>>>>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", >>>>>>> "SHALL NOT", >>>>>>>>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and >>>>>>>> "OPTIONAL" in this >>>>>>>>> document are to be interpreted as described in RFC 2119 [3]. >>>>>>>>> >>>>>>>>> This document uses terminology defined in [6], [5], >>>>>> [2], and [1]. >>>>>>>>> >>>>>>>>> 3. Assumptions >>>>>>>>> >>>>>>>>> This document defines additional optional AVPs for >>>>>> usage with the >>>>>>>>> Diameter EAP application. Routing of these messages is >>>>>> therefore >>>>>>>>> provided via the Diameter Application Identifier >> (among other >>>>>>>>> elements), as specified by the Diameter Base protocol [4]. >>>>>>>>> >>>>>>>>> [LM] To avoid any ambiguity I would say: >>>>>>>>> >>>>>>>>> "This document defines only additional optional AVPs for >>>>>>> usage with >>>>>>>>> the Diameter EAP application. This document does not defined >>>>>>>>> a new Diameter application and a new Application ID is >>>>>>>> therefore not >>>>>>>>> required, as described in the Diameter Base protocol [4]." >>>>>>>> ok >>>>>>>> >>>>>>>>> Based on >>>>>>>>> the deployment of ERP, a local Diameter server (the >> same entity >>>>>>>>> serves as a Diameter proxy during the full EAP >>>>>>> authentication) may >>>>>>>>> play the role of the ER server for future >>>>>>>> re-authentication attempts. >>>>>>>>> As such, the local Diameter server requesting the DSRK >>>>>>>> needs to be in >>>>>>>>> the path of the current EAP exchange between the peer >>>>>> and the EAP >>>>>>>>> server and also along in the future. The Diameter client is >>>>>>>>> furthermore assumed to be able to route the re-authentication >>>>>>>>> messages to the ER server. >>>>>>>>> >>>>>>>>> [LM] I think that the assumption all along this document is >>>>>>>> that the local ER server and the AAA agent are co-located, >>>>>>> to be able >>>>>>>> to rely on DEA for the transport of DSRK. In that case, I >>>>>> would say >>>>>>>> something like: >>>>>>>>> "In this document, when EAP re-authentication is performed >>>>>>>> in the domain >>>>>>>>> visited by the peer, it is assumed that the local ER >>>>>>>> server is co-located >>>>>>>>> with a Diameter agent in the visited domain present in >>>>>>>> the path of the full >>>>>>>>> EAP exchange." >>>>>>>> ok >>>>>>>> >>>>>>>>> >>>>>>>>> 4. Diameter Support for ERP >>>>>>>>> >>>>>>>>> 4.1. Protocol Overview >>>>>>>>> >>>>>>>>> Diameter may be used to transport ERP messages between the NAS >>>>>>>>> (authenticator) and an authentication server (ER server). >>>>>>>>> >>>>>>>>> [LM] s/may/is (the use of Diameter is a pre-requisite in >>>>>>> this draft) >>>>>>>>> In ERP, the peer sends an EAP Initiate Reauth message >> to the ER >>>>>>>>> server via the authenticator. >>>>>>>>> >>>>>>>>> [LM] s/"EAP Initiate Reauth message"/"EAP-Initiate/Re-auth >>>>>>> message" >>>>>>>>> (same all along the document) >>>>>>>>> >>>>>>>>> Alternatively, the NAS may send an EAP Initiate Reauth-Start >>>>>>>>> message to the peer to trigger >>>>>> the start of >>>>>>>>> ERP; the peer then responds with an EAP Initiate Reauth >>>>>>> message to >>>>>>>>> the NAS. >>>>>>>>> >>>>>>>>> [LM] s/"EAP Initiate Reauth-Start >>>>>>>> message"/"EAP-Initiate/Re-auth-Start >>>>>>>>> message" (same all along the document) >>>>>>>>> >>>>>>>>> The general guidelines for encapsulating EAP messages >>>>>> in Diameter >>>>>>>>> from RFC 4072 [1] apply to the new EAP messages defined >>>>>>> for ERP as >>>>>>>>> well. The EAP Initiate Reauth message is encapsulated >>>>>> in an EAP- >>>>>>>>> Payload AVP of a Diameter EAP-Request message by the NAS >>>>>>>> and sent to >>>>>>>>> the Diameter server. The NAS MUST copy the contents of >>>>>> the value >>>>>>>>> field of the 'rIKName as NAI' TLV or the peer-id TLV (when >>>>>>>> the former >>>>>>>>> is not present) of the EAP Initiate Reauth message into >>>>>>> a User-Name >>>>>>>>> AVP of the Diameter EAP-Request. >>>>>>>>> >>>>>>>>> [LM] I think that we are talking about the 'keyName-NAI' TLV >>>>>>>> and not anymore the 'rIKName as NAI' TLV. >>>>>>>> >>>>>>>> Considering section 5.3.2 of RFC 5296. I agree. >>>>>>>> >>>>>>>>> Moreover, in which case the peer-id TLV would not be >>>>>>> present for ERP? >>>>>>>> Privacy ? >>>>>>>> >>>>>>>>> The ER server processes the EAP Initiate Reauth message in >>>>>>>> accordance >>>>>>>>> with [2], and if that is successful, it responds with an >>>>>>> EAP Finish >>>>>>>>> Reauth message indicating a success ('R' flag set to >> 0). The >>>>>>>>> Diameter server MUST encapsulate the EAP Finish Reauth >>>>>>> message with >>>>>>>>> the R flag set to zero in an EAP-Payload AVP attribute of >>>>>>>> a Diameter >>>>>>>>> EAP-Answer message. An EAP-Master-Session-Key AVP >>>>>>> included in the >>>>>>>>> Diameter EAP-Answer contains the Re-authentication Master >>>>>>>> Session Key >>>>>>>>> (rMSK). The Diameter Result Code, if any, SHOULD be a >>>>>>>> success Result >>>>>>>>> Code. >>>>>>>>> >>>>>>>>> If the processing of the EAP Initiate Reauth message >>>>>>> resulted in a >>>>>>>>> failure, the Diameter server MUST encapsulate an EAP >>>>>>> Finish Reauth >>>>>>>>> message indicating failure ('R' flag set to 1) in an >>>>>>>> EAP-Payload AVP >>>>>>>>> of a Diameter EAP-Answer message. The Diameter Result >>>>>>>> Code, if any, >>>>>>>>> SHOULD be a failure Result Code. Whether an EAP >> Finish Reauth >>>>>>>>> message is sent at all is specified in [2]. >>>>>>>>> >>>>>>>>> [LM] the use of the 'R' flag is not relevant for Diameter EAP. >>>>>>>>> [LM] according to the RFC, the EAP-Finish/Re-auth is sent >>>>>>>> back in any case, success or failure. >>>>>>>>> [LM] according to the above comments, I would rephrase the >>>>>>>> text as follow: >>>>>>>>> >>>>>>>>> "The ER server processes the EAP Initiate Reauth message >>>>>>>> in accordance >>>>>>>>> with [2] and responds with an EAP-Finish/Re-auth message. >>>>>>>> The Diameter >>>>>>>>> server MUST encapsulate the EAP-Finish/Re-auth message within >>>>>>>>> an EAP-Payload AVP of a Diameter EAP-Answer message. >>>>>>>>> In an EAP re-authentication successful case, an >>>>>>>> EAP-Master-Session-Key >>>>>>>>> AVP is included in the Diameter EAP-Answer message that >>>>>>>> contains the >>>>>>>>> Re-authentication Master Session Key (rMSK). The Diameter >>>>>>>> Result-Code >>>>>>>>> SHOULD be a success Result-Code. >>>>>>>>> In an EAP re-authentication failure case, the Diameter >>>>>>>> Result-Code of >>>>>>>>> the a Diameter EAP-Answer message SHOULD be a failure >>>>>>>> Result-Code and >>>>>>>>> no EAP-Master-Session-Key AVP is present." >>>>>>>>> >>>>>>>>> [LM] By the way, I don't understand the "SHOULD" for the >>>>>>>> result-code. Any reason not to use "MUST" here? >>>>>>>> >>>>>>>> I think a MUST would be better. Different views ? >>>>>>>> >>>>>>>>> [LM] a figure could be added for illustration here. >>>>>>>>> >>>>>>>>> 4.2. DSRK Request and Delivery >>>>>>>>> >>>>>>>>> A local ER server, collocated with a Diameter proxy in >>>>>> the peer's >>>>>>>>> visited domain, >>>>>>>>> >>>>>>>>> [LM] s/in the peer's visited domain/in the domain visited >>>>>>> by the peer >>>>>>>>> may request a DSRK from the EAP server, either in the >> initial >>>>>>>>> EAP exchange (implicit bootstrapping) or in an ERP >>>>>>>>> bootstrapping exchange (explicit bootstrapping). It >>>>>> does this by >>>>>>>>> including the EAP-DSRK-Request AVP in the Diameter >> EAP-Response >>>>>>>>> message. The EAP-DSRK-Request AVP contains the domain >> or server >>>>>>>>> identity required to derive the DSRK. >>>>>>>>> >>>>>>>>> [LM] the EAP-DSRK-Request AVP is included in the Diameter >>>>>>>> EAP-Request >>>>>>>>> (and not in the response) >>>>>>>> yes. >>>>>>>> >>>>>>>>> An EAP server MAY send the DSRK when it receives a >>>>>> valid Diameter >>>>>>>>> EAP-Request message containing an EAP-DSRK-Request AVP. >>>>>>>> An ER server >>>>>>>>> MUST send the DSRK (or send a failure result) when it >> receives >>>>>>>>> a valid Diameter EAP-Request message containing an >>>>>>>> EAP-DSRK-Request AVP >>>>>>>>> along with a valid EAP Initiate Re-auth packet with the >>>>>>>> bootstrapping >>>>>>>>> flag turned on. If an EAP-DSRK-Request AVP is included in >>>>>>>> any other >>>>>>>>> Diameter EAP-Request message, the Diameter server MUST >>>>>>> reply with a >>>>>>>>> failure result. An EAP-DSRK AVP MUST be used to send a >>>>>>>> DSRK; an EAP- >>>>>>>>> DSRK-Name AVP MUST be used to send the DSRK's keyname; >>>>>>> and an EAP- >>>>>>>>> DSRK-Lifetime AVP MUST be used to send the DSRK's lifetime. >>>>>>>>> >>>>>>>>> [LM] I don't understand the intention of the above text. >>>>>>>> Could it be enough to say: >>>>>>>>> In successful case, the DSRK is carried by the EAP-DSRK >>>>>>> AVP in the >>>>>>>>> Diameter EAP response message. Along with the >> EAP-DSRK AVP, an >>>>>>>>> EAP-DSRK-Name AVP MUST be used to send the DSRK's >> keyname and an >>>>>>>>> EAP-DSRK-Lifetime AVP MUST be used to send the DSRK's = >>>>>>>>> lifetime. >>>>>>>> Agree. >>>>>>>> >>>>>>>>> [LM] a figure could be added for illustration here. >>>>>>>>> >>>>>>>>> 5. Command Codes >>>>>>>>> >>>>>>>>> [LM] this section is not required as there is nothing >>>>>>>> specific for ERP. We should skip it. >>>>>>>>> [SKIP] >>>>>>>>> >>>>>>>>> >>>>>>>>> 6. Attribute Value Pair Definitions >>>>>>>>> >>>>>>>>> 6.1. EAP-DSRK-Request AVP >>>>>>>>> >>>>>>>>> The EAP-DSRK AVP (AVP Code TBD) is of type DiameterIdentity. >>>>>>>>> >>>>>>>>> [LM] s/EAP-DSRK AVP/EAP-DSRK-Request AVP >>>>>>>>> >>>>>>>>> This >>>>>>>>> AVP fulfills two purposes: First, it indicates that a ER >>>>>>> server is >>>>>>>>> located in the local domain that is willing to play the >>>>>>>> role of an ER >>>>>>>>> server for a particular session. Second, it conveys >>>>>>>>> information about the domain and ER server identity to the >>>>>>> Diameter/EAP server. >>>>>>>>> [LM] the use of this AVP is explained above. There is no >>>>>>>> need to explain again. >>>>>>>> >>>>>>>> As we are in the AVP Definitions, I think it is better to >>>>>> keep some >>>>>>>> text explaining it. No ? >>>>>>>> >>>>>>>>> Moreover, if a DiameterIdentity is used, it is to indicate a >>>>>>>> server and not a domain. Right? >>>>>>>> >>>>>>>> In my understanding the local ER server only sends the Domain >>>>>>>> Name which will then be used to compute keys. Maybe the type >>>>>>>> DiameterIdentity is not appropriated and we should use >> UTF8String >>>>>>>> instead. What do you think ? >>>>>>>> >>>>>>>> >>>>>>>>> 6.2. EAP-DSRK AVP >>>>>>>>> >>>>>>>>> The EAP-DSRK AVP (AVP Code TBD) is of type OctetString. >>>>>>> The Domain >>>>>>>>> Specific Root Key (DSRK) is carried in this payload. >>>>>>>>> >>>>>>>>> 6.3. EAP-DSRK-Name AVP >>>>>>>>> >>>>>>>>> The EAP-DSRK-Name AVP (AVP Code TBD) is of type >>>>>>> OctetString. This >>>>>>>>> AVP contains the name of the DSRK key that is later used >>>>>>> during the >>>>>>>>> re-authentication exchange to select the correct DSRK. >>>>>>>>> >>>>>>>>> [LM] skip the part starting by "that is..." >>>>>>>> ok >>>>>>>> >>>>>>>>> 6.4. EAP-DSRK-Lifetime AVP >>>>>>>>> >>>>>>>>> The EAP-DSRK-Lifetime AVP (AVP Code TBD) is of type >>>>>>> Unsigned64 and >>>>>>>>> contains the DSRK lifetime in seconds. >>>>>>>>> >>>>>>>>> >>>>>>>>> 7. AVP Occurrence Table >>>>>>>>> >>>>>>>>> The following table lists the AVPs that may optionally be >>>>>>>> present in >>>>>>>>> the DER and DEA commands [1]. >>>>>>>>> >>>>>>>>> >>>>>>>>> +---------------+ >>>>>>>>> | Command-Code | >>>>>>>>> +-+-----+-----+-+ >>>>>>>>> Attribute Name | DER | DEA | >>>>>>>>> -------------------------------|-----+-----+ >>>>>>>>> EAP-DSRK-Request | 0-1 | 0 | >>>>>>>>> EAP-DSRK | 0 | 0-1 | >>>>>>>>> EAP-DSRK-Name | 0 | 0-1 | >>>>>>>>> EAP-DSRK-Lifetime | 0 | 0-1 | >>>>>>>>> +-----+-----+ >>>>>>>>> >>>>>>>>> Figure 4: DER and DEA Commands AVP Table >>>>>>>>> >>>>>>>>> When the EAP-DSRK AVP is present in the DEA then the >>>>>>> EAP-DSRK-Name >>>>>>>>> and the EAP-DSRK-Lifetime MUST also be present. >>>>>>>>> >>>>>>>>> >>>>>>>>> 8. AVP Flag Rules >>>>>>>>> >>>>>>>>> The following table describes the Diameter AVPs, >> their AVP Code >>>>>>>>> values, types, possible flag values, and whether the >> AVP MAY be >>>>>>>>> encrypted. The Diameter base [4] specifies the AVP Flag >>>>>>> rules for >>>>>>>>> AVPs in Section 4.5. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> +---------------------+ >>>>>>>>> | AVP Flag >>>>>>>>> Rules | >>>>>>>>> >>>>>>>> +----+-----+----+-----+----+ >>>>>>>>> AVP Section | | >>>>>>>> |SHLD|MUST | | >>>>>>>>> Attribute Name Code Defined Data Type |MUST| MAY |NOT >>>>>>>> |NOT |Encr| >>>>>>>> ------------------------------------------+----+-----+----+-- >>>>>>> ---+----+ >>>>>>>>> EAP-DSRK-Request TBD 4.7.1 DiamIdent | | P | | >>>>>>>> V,M | Y | >>>>>>>>> EAP-DSRK TBD 4.7.2 OctetString| | P | | >>>>>>>> V,M | Y | >>>>>>>>> EAP-DSRK-Name TBD 4.7.3 OctetString| | P | | >>>>>>>> V,M | Y | >>>>>>>>> EAP-DSRK-Lifetime TBD 4.7.4 Unsigned64 | | P | | >>>>>>>> V,M | Y | >>>>>>>>> >>>>>>>> ------------------------------------------+----+-----+----+-- >>>>>>> ---+----+ >>>>>>>>> Due to space constraints, the short form DiamIdent is used to >>>>>>>>> represent DiameterIdentity. >>>>>>>>> >>>>>>>>> Figure 5: AVP Flag Rules Table >>>>>>>>> >>>>>>>>> [LM] this table is ok according to the current RFC 3588. I >>>>>>>> don't know how to deal with it regarding the RFC3588bis... >>>>>>>> >>>>>>>> >>>>>>>> That's indeed a good question :). >>>>>>>> >>>>>>>> And that's all for my comments of your comments. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> --Julien-- >>>>>>>> _______________________________________________ >>>>>>>> DiME mailing list >>>>>>>> DiME@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >> >> >> --~--~---------~--~----~------------~-------~--~----~ >> You received this message because you are subscribed to the >> Google Groups "diameter-routing" group. >> To post to this group, send email to >> diameter-routing@googlegroups.com To unsubscribe from this >> group, send email to diameter-routing+unsubscribe@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/diameter-routing?hl=3Den >> -~----------~----~----~----~------~----~------~--~--- >> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Jan 10 06:48:45 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D36D13A6980; Sat, 10 Jan 2009 06:48:45 -0800 (PST) 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 B14043A6A64 for ; Sat, 10 Jan 2009 06:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.77 X-Spam-Level: X-Spam-Status: No, score=-1.77 tagged_above=-999 required=5 tests=[AWL=0.829, 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 It3mm5B10+5F for ; Sat, 10 Jan 2009 06:48:44 -0800 (PST) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id BD0363A689B for ; Sat, 10 Jan 2009 06:48:43 -0800 (PST) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA06.westchester.pa.mail.comcast.net with comcast id 1pmN1b0090EZKEL56qoXnh; Sat, 10 Jan 2009 14:48:31 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA01.westchester.pa.mail.comcast.net with comcast id 1qoV1b00T4H2mdz3MqoV9x; Sat, 10 Jan 2009 14:48:30 +0000 From: "Dave Nelson" To: , , References: <023a01c9732c$1c3ec200$0201a8c0@nsnintra.net> <023c01c9732f$f3654fd0$0201a8c0@nsnintra.net> Date: Sat, 10 Jan 2009 09:48:39 -0500 Message-ID: <281A3B25382A4F96A5204602866D7501@NEWTON603> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <023c01c9732f$f3654fd0$0201a8c0@nsnintra.net> Thread-Index: Aclxqf2p8QFE/3aeSwOxYd7pwwXjNwBgAV4AAACuiOAAAHxgMAAAqDRg Subject: Re: [Dime] [AAA-DOCTORS] RADIUS / Diameter compatibilityboilerplate? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hannes Tschofenig writes... > There isn't too much space left in the <255 ID space and hence > that consideration might not be too relevant in the future. But it's another reason to restrict it right now -- to conserve such space for RADIUS applications. Unless, of course, the issues you've enumerated do not apply in a specific use case, for example when no new Diameter application is required and simple RADIUS data types suffice to the use case. > I would not restrict the possibility to allocate RADIUS attributes > (for example from the extended attribute space) in a Diameter > document or todo Diameter AVP code allocation in a RADIUS document. Well, RADIUS Extended Attributes is a different case to consider. Given the impedance mismatch between the Diameter AVP data model and the more restricted RADIUS Extended Attribute data model, there are some serious design issues. For example, to share these EAs/APVs the Diameter solution must be designed to fit within the RADIUS data model restrictions. > The problem is that a more detailed investigation about this > subject will take some time. Correct. > Do you have that time? Probably not. Nor do I have the required Diameter expertise. That's why I suggested a stop-gap "fix" in the form "just don't do that". :-) _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Jan 10 06:52:08 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B82A3A6980; Sat, 10 Jan 2009 06:52:08 -0800 (PST) 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 A5F8A3A6980 for ; Sat, 10 Jan 2009 06:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.230, 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 T9u1wEIQE3BP for ; Sat, 10 Jan 2009 06:52:07 -0800 (PST) Received: from smtp117.rog.mail.re2.yahoo.com (smtp117.rog.mail.re2.yahoo.com [68.142.225.233]) by core3.amsl.com (Postfix) with SMTP id 15F2B3A689B for ; Sat, 10 Jan 2009 06:52:04 -0800 (PST) Received: (qmail 6131 invoked from network); 10 Jan 2009 14:51:51 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=WTbQwxAbAlYLq8cR/fp3HyiS7IhftiWNyweVWu+3qVaU/AFidKz7KtQj9MtraiCNkZd7X0pneaeuoy/kXQuczN/V+RNT7GYuNO5tkNs46rmthbJr2XnduO9F7ITXfSaRuXwDfU3tA8GbEEDNrAQoC+v78OukdmodYuq014GbWTY= ; Received: from unknown (HELO ?192.168.0.101?) (tom.taylor@72.140.46.24 with plain) by smtp117.rog.mail.re2.yahoo.com with SMTP; 10 Jan 2009 14:51:51 -0000 X-YMail-OSG: 0M3mw3oVM1k4BAsdkuMmUn8CSkGnc3QxfhQl76eeWaCA52KRmtbVj9HHu3lvV5FJoQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4968B604.4010002@rogers.com> Date: Sat, 10 Jan 2009 09:51:48 -0500 From: Tom Taylor User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Hannes Tschofenig References: <7DBAFEC6A76F3E42817DF1EBE64CB026061E2759@ftrdmel2> <5e2406980901080218w746b69a7x320f1501aeb97266@mail.gmail.com> <7DBAFEC6A76F3E42817DF1EBE64CB0260622C4DE@ftrdmel2> <5e2406980901090115m2fe2c097nee9854a9ed870127@mail.gmail.com> <49677A85.2030607@rogers.com> <023801c97325$68712700$0201a8c0@nsnintra.net> In-Reply-To: <023801c97325$68712700$0201a8c0@nsnintra.net> Cc: dime@ietf.org, diameter-routing@googlegroups.com Subject: Re: [Dime] Review of the Diameter ERP 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hannes, you have a specific solution in mind, and you have been trying to convey it to the others in this discussion. However, the problem as Julien states it (in the excerpted text below) can't be solved simply by defining a new application, because there could be more than one Diameter entity in a given netwoprk that supports that application. Hannes Tschofenig wrote: > Hi Tom, Hi Tina, > > I believe you are misunderstanding the Diameter ERP usage (could also be > me). > > We are not talking about "route-pinning" AAA routing but rather whether the > definition of AVPs is sufficient for the design or whether a Diameter > application. > > Ciao > Hannes ... >>>> Yes, ideally, for a given peer, the same AAA proxy/local ERP server >>>> should be contacted by authenticators. At this point, I >> don't see how >>>> to ensure this. >>>> Regards, >>>> Julien ... _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Jan 10 18:18:03 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0F293A684B; Sat, 10 Jan 2009 18:18:03 -0800 (PST) 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 BF4693A684B for ; Sat, 10 Jan 2009 18:18:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.021 X-Spam-Level: X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iH8amlJdwr+H for ; Sat, 10 Jan 2009 18:18:00 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id E4A563A682D for ; Sat, 10 Jan 2009 18:17:59 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDA008CXBPB5U@szxga04-in.huawei.com> for dime@ietf.org; Sun, 11 Jan 2009 10:17:35 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDA00K8KBPBMW@szxga04-in.huawei.com> for dime@ietf.org; Sun, 11 Jan 2009 10:17:35 +0800 (CST) Received: from [192.168.1.4] (102.175.60.58.broad.sz.gd.dynamic.163data.com.cn [58.60.175.102]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KDA000PYBPAZG@szxml01-in.huawei.com>; Sun, 11 Jan 2009 10:17:35 +0800 (CST) Date: Sun, 11 Jan 2009 10:17:33 +0800 From: Tina TSOU In-reply-to: <4968B604.4010002@rogers.com> To: Tom Taylor Message-id: <6A103AA8-29B7-46EB-A65A-933173B66747@huawei.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.929.2) References: <7DBAFEC6A76F3E42817DF1EBE64CB026061E2759@ftrdmel2> <5e2406980901080218w746b69a7x320f1501aeb97266@mail.gmail.com> <7DBAFEC6A76F3E42817DF1EBE64CB0260622C4DE@ftrdmel2> <5e2406980901090115m2fe2c097nee9854a9ed870127@mail.gmail.com> <49677A85.2030607@rogers.com> <023801c97325$68712700$0201a8c0@nsnintra.net> <4968B604.4010002@rogers.com> Cc: dime@ietf.org, diameter-routing@googlegroups.com Subject: Re: [Dime] Review of the Diameter ERP 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi all, Tom's clarification seems reasonable. Should I add "the problem as Julien states it can't be solved simply by defining a new application, because there could be more than one Diameter entity in a given netwoprk that supports that application" to one of the use cases of problem 2 in draft-tsou-dime-routing-problem- statement-01? B. R. Tina Messengers: MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU Jabber: tina@jabber.org Google talk: tinatsou6@gmail.com +86-755-28971872 (Office) +86-13922884380(Mobile) On Jan 10, 2009, at 10:51 PM, Tom Taylor wrote: > Hannes, you have a specific solution in mind, and you have been > trying to convey it to the others in this discussion. However, the > problem as Julien states it (in the excerpted text below) can't be > solved simply by defining a new application, because there could be > more than one Diameter entity in a given netwoprk that supports that > application. > > Hannes Tschofenig wrote: >> Hi Tom, Hi Tina, I believe you are misunderstanding the Diameter >> ERP usage (could also be >> me). We are not talking about "route-pinning" AAA routing but >> rather whether the >> definition of AVPs is sufficient for the design or whether a Diameter >> application. Ciao >> Hannes > > ... > >>>>> Yes, ideally, for a given peer, the same AAA proxy/local ERP >>>>> server should be contacted by authenticators. At this point, I >>> don't see how >>>>> to ensure this. >>>>> Regards, >>>>> Julien > > ... > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Jan 10 18:56:14 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92E113A6834; Sat, 10 Jan 2009 18:56:14 -0800 (PST) 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 125523A6834 for ; Sat, 10 Jan 2009 18:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 3p-gFof66lpX for ; Sat, 10 Jan 2009 18:56:12 -0800 (PST) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by core3.amsl.com (Postfix) with ESMTP id 47EAC3A682D for ; Sat, 10 Jan 2009 18:56:12 -0800 (PST) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id 1rRy1b00n16AWCUA72vzLu; Sun, 11 Jan 2009 02:55:59 +0000 Received: from gwzPC ([67.160.38.190]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id 22vy1b00F469TLb8S2vy3s; Sun, 11 Jan 2009 02:55:59 +0000 From: "Glen Zorn" To: "'Tom Taylor'" , "'Hannes Tschofenig'" References: <7DBAFEC6A76F3E42817DF1EBE64CB026061E2759@ftrdmel2> <5e2406980901080218w746b69a7x320f1501aeb97266@mail.gmail.com> <7DBAFEC6A76F3E42817DF1EBE64CB0260622C4DE@ftrdmel2> <5e2406980901090115m2fe2c097nee9854a9ed870127@mail.gmail.com> <49677A85.2030607@rogers.com> <023801c97325$68712700$0201a8c0@nsnintra.net> <4968B604.4010002@rogers.com> In-Reply-To: <4968B604.4010002@rogers.com> Date: Sat, 10 Jan 2009 18:54:49 -0800 Message-ID: <001501c97397$f8adde90$ea099bb0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclzMvrLa9nI3BAXTIaodrP3VZxXcwAZE5Qw Content-Language: en-us Cc: dime@ietf.org, diameter-routing@googlegroups.com Subject: Re: [Dime] Review of the Diameter ERP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org > Hannes, you have a specific solution in mind, and you have been trying > to convey > it to the others in this discussion. As, apparently, do you ;-). > However, the problem as Julien > states it > (in the excerpted text below) can't be solved simply by defining a new > application, because there could be more than one Diameter entity in a > given > netwoprk that supports that application. ERX & hokey traffic can't just be sent to any random Diameter entity, it needs to go to a hokey server. Whether that entity speaks RADIUS, Diameter or something else is irrelevant from the POV of service discovery & routing. > > Hannes Tschofenig wrote: > > Hi Tom, Hi Tina, > > > > I believe you are misunderstanding the Diameter ERP usage (could also > be > > me). > > > > We are not talking about "route-pinning" AAA routing but rather > whether the > > definition of AVPs is sufficient for the design or whether a Diameter > > application. > > > > Ciao > > Hannes > > ... > > >>>> Yes, ideally, for a given peer, the same AAA proxy/local ERP > server > >>>> should be contacted by authenticators. At this point, I > >> don't see how > >>>> to ensure this. > >>>> Regards, > >>>> Julien > > ... > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Jan 11 09:10:17 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2431A28C1F2; Sun, 11 Jan 2009 09:10:17 -0800 (PST) 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 30CB528C1F1 for ; Sun, 11 Jan 2009 09:10:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.544 X-Spam-Level: X-Spam-Status: No, score=-3.544 tagged_above=-999 required=5 tests=[AWL=-0.945, 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 rf6EIDyzajGl for ; Sun, 11 Jan 2009 09:10:15 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 3070428C1E9 for ; Sun, 11 Jan 2009 09:10:14 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n0BH9jCi026409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 11 Jan 2009 18:09:45 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n0BH9jbU009238; Sun, 11 Jan 2009 18:09:45 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 11 Jan 2009 18:09:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 11 Jan 2009 19:09:41 +0200 Message-ID: In-Reply-To: <4968B604.4010002@rogers.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Review of the Diameter ERP draft Thread-Index: AclzMvocx5nDCafDRlSl/9y6CblRHgAt4UoQ References: <7DBAFEC6A76F3E42817DF1EBE64CB026061E2759@ftrdmel2> <5e2406980901080218w746b69a7x320f1501aeb97266@mail.gmail.com> <7DBAFEC6A76F3E42817DF1EBE64CB0260622C4DE@ftrdmel2> <5e2406980901090115m2fe2c097nee9854a9ed870127@mail.gmail.com> <49677A85.2030607@rogers.com> <023801c97325$68712700$0201a8c0@nsnintra.net> <4968B604.4010002@rogers.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Tom Taylor" , "Hannes Tschofenig" X-OriginalArrivalTime: 11 Jan 2009 17:09:45.0422 (UTC) FILETIME=[66C3F6E0:01C9740F] Cc: dime@ietf.org, diameter-routing@googlegroups.com Subject: Re: [Dime] Review of the Diameter ERP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Tom and Julien, maybe you are right. You might know ERP better than I do. Give me some time to re-read the HOKEY documents to provide a solid analysis. Before doing that I do, however, need to focus my time on finishing the RFC3588bis document. Ciao Hannes >-----Original Message----- >From: ext Tom Taylor [mailto:tom.taylor@rogers.com] >Sent: 10 January, 2009 16:52 >To: Hannes Tschofenig >Cc: diameter-routing@googlegroups.com; 'Julien Bournelle'; >Tschofenig, Hannes (NSN - FI/Espoo); dime@ietf.org >Subject: Re: [Dime] Review of the Diameter ERP draft > >Hannes, you have a specific solution in mind, and you have >been trying to convey it to the others in this discussion. >However, the problem as Julien states it (in the excerpted >text below) can't be solved simply by defining a new >application, because there could be more than one Diameter >entity in a given netwoprk that supports that application. > >Hannes Tschofenig wrote: >> Hi Tom, Hi Tina, >> >> I believe you are misunderstanding the Diameter ERP usage >(could also >> be me). >> >> We are not talking about "route-pinning" AAA routing but rather >> whether the definition of AVPs is sufficient for the design >or whether >> a Diameter application. >> >> Ciao >> Hannes > >... > >>>>> Yes, ideally, for a given peer, the same AAA proxy/local >ERP server >>>>> should be contacted by authenticators. At this point, I >>> don't see how >>>>> to ensure this. >>>>> Regards, >>>>> Julien > >... > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jan 12 09:23:58 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 239CA28C34B; Mon, 12 Jan 2009 09:23:58 -0800 (PST) X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id ABB7528C336; Mon, 12 Jan 2009 09:23:55 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090112172355.ABB7528C336@core3.amsl.com> Date: Mon, 12 Jan 2009 09:23:55 -0800 (PST) Cc: Internet Architecture Board , dime mailing list , dime chair , RFC Editor Subject: [Dime] Protocol Action: 'Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction' to Proposed Standard 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org The IESG has approved the following document: - 'Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction ' as a Proposed Standard This document is the product of the Diameter Maintenance and Extensions Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-integrated-12.txt Technical Summary A Mobile IPv6 node requires a Home Agent address, a home address, and a security association with its Home Agent before it can start utilizing Mobile IPv6. RFC 3775 requires that some or all of these parameters are statically configured. Mobile IPv6 bootstrapping work aims to make this information dynamically available to the Mobile Node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing authentication, authorization and accounting infrastructure. This document describes the MIPv6 bootstrapping using the Diameter Network Access Server (NAS) to home Authentication, Authorization and Accounting server (HAAA) interface. Working Group Summary There is consensus in the WG to publish this document. Document Quality The document has received extensive reviews from DIME and MIP6 working group members. This document is a building block in the Mobile IPv6 bootstrapping architecture. Area review was performed by Dan Romascanu, and GenART review by Vijay Gurbani. Personnel David Frascone is the document shepherd, Dan Romascanu is the responsible Area Director. RFC Editor Note RFC Editor, before publication please make the following change: Section 4.2.1, first line: s/type of Grouped/of type Grouped/ _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jan 13 09:12:17 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E7F428C14D; Tue, 13 Jan 2009 09:12:17 -0800 (PST) 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 D136D3A6989 for ; Tue, 13 Jan 2009 09:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KIll8eITVbx for ; Tue, 13 Jan 2009 09:12:16 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.185]) by core3.amsl.com (Postfix) with ESMTP id 9EBB528C13F for ; Tue, 13 Jan 2009 09:12:15 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id 18so65252fkq.5 for ; Tue, 13 Jan 2009 09:11:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=g00rZssFnpWt4jod5WI0h/iQAKaodzlPuh6uavJhRQk=; b=eBoaSrPwXkSnnYB8AzYn83wXSrY7dq6uBMaAM7XnGFF+Luh1TeEftytGgJ9w71/XHB wjPZ4orx/LAuBkQdU9G2X/Ag+mb9beHmngoNhcjXuUnJUScxrlBw16scaLN9QIhtdBCi Ak4TkYITeaKMXoJKEbxPt318DqfWvPN3NErIM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=RJyjaOZOiFrgehMy/kI1DrcbUElJFjchZ21iqkzqDgdiJcJCu3lv04iAjKyfIM0EcC FBkLw8qz+gNRaz8KsCFql4DpEt66PbC7NzXybmP4pUT5tvV6HdGH+GoBhx7PMUT1QhWs 4QDvvWceYig7CTAs5U5RJeSkIgGM7hePAs6nc= Received: by 10.223.110.211 with SMTP id o19mr3714910fap.57.1231866718222; Tue, 13 Jan 2009 09:11:58 -0800 (PST) Received: by 10.223.108.129 with HTTP; Tue, 13 Jan 2009 09:11:58 -0800 (PST) Message-ID: <5e2406980901130911s4c97b53aj6a6061a78a3a6444@mail.gmail.com> Date: Tue, 13 Jan 2009 18:11:58 +0100 From: "Julien Bournelle" To: dime@ietf.org MIME-Version: 1.0 Content-Disposition: inline Subject: [Dime] [ERP] Summary of current issues based on lionel's comments 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi all, I tried to catch remaining issues of the Diameter ERP document to be solved (not taking into account jouni's comments): 1/ Do we refer to RFC3588 or RFC3588 Bis ? 2/ In case of EAP peer in visited domain, does we mandate the AAA proxy to be on the path ? 3/ In the above paragraph: The ER server processes the EAP-Initiate/Re-auth message in accordance with and responds with an EAP-Finish/Re-auth message. The Diameter server MUST encapsulate the EAP-Finish/Re-auth message within an EAP-Payload AVP of a Diameter EAP Answer message. In an EAP re-authentication successful case, an EAP-Master-Session-Key AVP is included in the Diameter EAP Answer (DEA) message that contains the Re-authentication Master Session Key (rMSK). The Diameter Result-Code SHOULD be a success Result-Code. In an EAP re-authentication failure case, the Diameter Result-Code AVP of the a Diameter EAP Answer (DEA) message SHOULD be a failure Result-Code and no EAP-Master-Session-Key AVP is present. It is not clear if SHOULD must be replaced with MUST. 4/ Current diameter Type of EAP-DSRK-Request is DiameterIdentity whereas it contains a domain name (which is not a FQDN). The proposal is to replace DiameterIdentity by UTF8String 5/ Concerning EAP-DSRK-Lifetime, do we authorize zero as a value ? do we need a value for infinite ? If you have any opinion on one of this issue, do not hesitate to start a new thread with a specific subject. Regards, Julien _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jan 14 00:30:02 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6D2828C1C0; Wed, 14 Jan 2009 00:30:02 -0800 (PST) X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E0CA728C1C0; Wed, 14 Jan 2009 00:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090114083001.E0CA728C1C0@core3.amsl.com> Date: Wed, 14 Jan 2009 00:30:01 -0800 (PST) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-pmip6-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: , Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --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: Support For Mobile Access Gateway and Local Mobility Anchor to Diameter Server Interaction Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-pmip6-00.txt Pages : 21 Date : 2009-01-13 This specification defines the Diameter support for the Proxy Mobile IPv6 and the corresponding mobility service session setup. The policy information needed by the Proxy Mobile IPv6 is defined in mobile node's policy profile, which could be downloaded from the Diameter server to the Mobile Access Gateway once the mobile node roams into a Proxy Mobile IPv6 Domain and performs access authentication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-pmip6-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-pmip6-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-14002325.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Wed Jan 14 01:39:35 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6426C3A687E; Wed, 14 Jan 2009 01:39:35 -0800 (PST) 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 E9AFA3A687E for ; Wed, 14 Jan 2009 01:39:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.547 X-Spam-Level: X-Spam-Status: No, score=-0.547 tagged_above=-999 required=5 tests=[AWL=-0.549, 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 v+aNBUdwVCXJ for ; Wed, 14 Jan 2009 01:39:32 -0800 (PST) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 552873A6819 for ; Wed, 14 Jan 2009 01:39:32 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDG00JLQG5FSL@szxga02-in.huawei.com> for dime@ietf.org; Wed, 14 Jan 2009 17:39:15 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDG00KLKG5FQE@szxga02-in.huawei.com> for dime@ietf.org; Wed, 14 Jan 2009 17:39:15 +0800 (CST) Received: from z24109b ([10.70.39.116]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KDG009WLG5FW3@szxml05-in.huawei.com> for dime@ietf.org; Wed, 14 Jan 2009 17:39:15 +0800 (CST) Date: Wed, 14 Jan 2009 17:39:15 +0800 From: Tina TSOU To: diameter-routing@googlegroups.com Message-id: <027f01c9762b$f6e45440$7427460a@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 X-Priority: 3 X-MSMail-priority: Normal Cc: dime@ietf.org Subject: [Dime] Questions as input to Thursday's diameter routing DT meeting are following. 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: , Content-Type: multipart/mixed; boundary="===============0080674717==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0080674717== Content-type: multipart/alternative; boundary="Boundary_(ID_bEYZmJCL08l16wKUmt7Quw)" This is a multi-part message in MIME format. --Boundary_(ID_bEYZmJCL08l16wKUmt7Quw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi all, Questions as input to Thursday's diameter routing DT meeting are following. Could we make a decision on how to proceed with explicit routing problem, now that the problem seems to be there for ERP as well (see Julien's problem summary mail today)? May I ask the DT how many would like to see this problem being solved in the WG? Wish you a prosperous and healthy New Year:D B. R. Tina --Boundary_(ID_bEYZmJCL08l16wKUmt7Quw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable
Hi all,
 
Questions as input to Thursday's = diameter routing DT=20 meeting are following.
 
Could we make a decision on how to = proceed with=20 explicit routing problem, now that the problem seems to be there for ERP = as well=20 (see Julien's problem summary mail today)?
 
May I ask the DT how many would like to = see this=20 problem being solved in the WG?

 

 
Wish you a prosperous and healthy New=20 Year:D
 
B. = R.
Tina
--Boundary_(ID_bEYZmJCL08l16wKUmt7Quw)-- --===============0080674717== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0080674717==-- From dime-bounces@ietf.org Wed Jan 14 04:45:02 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA71628C101; Wed, 14 Jan 2009 04:45:02 -0800 (PST) X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B3EEA28B797; Wed, 14 Jan 2009 04:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090114124501.B3EEA28B797@core3.amsl.com> Date: Wed, 14 Jan 2009 04:45:01 -0800 (PST) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-nai-routing-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: , Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --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-00.txt Pages : 10 Date : 2009-01-14 This specification clarifies the Diameter realm based request routing. We focus on the case where a Network Access Identifier in the User-Name AVP is used to populate the Destination-Realm AVP and the Network Access Identifier contains more than one realm. This particular case is possible when the Network Access Identifier decoration is used to force a routing of request messages through a predefined list of realms. However, this functionality is not unambiguously specified in the Diameter Base Protocol specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-nai-routing-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-nai-routing-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-14043806.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Wed Jan 14 05:18:54 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8A4D3A6B5C; Wed, 14 Jan 2009 05:18:54 -0800 (PST) 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 40C2828C103 for ; Wed, 14 Jan 2009 05:18:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 ZVvVg7tifvk4 for ; Wed, 14 Jan 2009 05:18:53 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id DC19C3A6B52 for ; Wed, 14 Jan 2009 05:18:52 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,263,1231131600"; d="scan'208";a="134023165" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 14 Jan 2009 08:18:36 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 14 Jan 2009 08:18:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 Jan 2009 14:18:29 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Protocol Action: 'Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction' to Proposed Standard Thread-Index: Acl02po5NREktb8uR1iFzg50WjzxVQBb9/zg From: "Romascanu, Dan (Dan)" To: Subject: [Dime] FW: Protocol Action: 'Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction' to Proposed Standard 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Congratulations to the editors, chairs and the whole working group for the completion of this item. Dan -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG Sent: Monday, January 12, 2009 7:24 PM To: IETF-Announce Cc: Internet Architecture Board; dime mailing list; dime chair; RFC Editor Subject: Protocol Action: 'Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction' to Proposed Standard The IESG has approved the following document: - 'Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction ' as a Proposed Standard This document is the product of the Diameter Maintenance and Extensions Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-integrated-12.t xt Technical Summary A Mobile IPv6 node requires a Home Agent address, a home address, and a security association with its Home Agent before it can start utilizing Mobile IPv6. RFC 3775 requires that some or all of these parameters are statically configured. Mobile IPv6 bootstrapping work aims to make this information dynamically available to the Mobile Node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing authentication, authorization and accounting infrastructure. This document describes the MIPv6 bootstrapping using the Diameter Network Access Server (NAS) to home Authentication, Authorization and Accounting server (HAAA) interface. Working Group Summary There is consensus in the WG to publish this document. Document Quality The document has received extensive reviews from DIME and MIP6 working group members. This document is a building block in the Mobile IPv6 bootstrapping architecture. Area review was performed by Dan Romascanu, and GenART review by Vijay Gurbani. Personnel David Frascone is the document shepherd, Dan Romascanu is the responsible Area Director. RFC Editor Note RFC Editor, before publication please make the following change: Section 4.2.1, first line: s/type of Grouped/of type Grouped/ _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jan 14 06:08:27 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C92A28C119; Wed, 14 Jan 2009 06:08:27 -0800 (PST) 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 425E828C119 for ; Wed, 14 Jan 2009 06:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.525 X-Spam-Level: X-Spam-Status: No, score=-5.525 tagged_above=-999 required=5 tests=[AWL=1.074, 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 z3McNGCpB6CM for ; Wed, 14 Jan 2009 06:08:25 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 5880A3A63EC for ; Wed, 14 Jan 2009 06:08:24 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n0EE3l3Z012949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 14 Jan 2009 15:07:59 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n0EDVu6L011318; Wed, 14 Jan 2009 14:32:10 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Jan 2009 14:19:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 Jan 2009 15:20:17 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] FW: Protocol Action: 'Diameter Mobile IPv6: Support forNetwork Access Server to Diameter Server Interaction' toProposed Standard Thread-Index: Acl02po5NREktb8uR1iFzg50WjzxVQBb9/zgAAAUKIA= References: From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Romascanu, Dan (Dan)" , X-OriginalArrivalTime: 14 Jan 2009 13:19:44.0968 (UTC) FILETIME=[C44B0C80:01C9764A] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::090114150759-066C1BB0-6902F179/0-0/0-0 X-purgate-size: 3266/3048 Subject: Re: [Dime] FW: Protocol Action: 'Diameter Mobile IPv6: Support forNetwork Access Server to Diameter Server Interaction' toProposed Standard 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Thank you Dan for helping us with progressing the document through the IESG. Ciao Hannes >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >Behalf Of ext Romascanu, Dan (Dan) >Sent: 14 January, 2009 15:18 >To: dime@ietf.org >Subject: [Dime] FW: Protocol Action: 'Diameter Mobile IPv6: >Support forNetwork Access Server to Diameter Server >Interaction' toProposed Standard > >Congratulations to the editors, chairs and the whole working >group for the completion of this item. > >Dan > > >-----Original Message----- >From: ietf-announce-bounces@ietf.org >[mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG >Sent: Monday, January 12, 2009 7:24 PM >To: IETF-Announce >Cc: Internet Architecture Board; dime mailing list; dime >chair; RFC Editor >Subject: Protocol Action: 'Diameter Mobile IPv6: Support for >Network Access Server to Diameter Server Interaction' to >Proposed Standard > >The IESG has approved the following document: > >- 'Diameter Mobile IPv6: Support for Network Access Server to Diameter > Server Interaction ' > as a Proposed Standard > >This document is the product of the Diameter Maintenance and >Extensions Working Group. > >The IESG contact persons are Dan Romascanu and Ron Bonica. > >A URL of this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-integr >ated-12.t >xt > >Technical Summary > > A Mobile IPv6 node requires a Home Agent address, a home address, and > a security association with its Home Agent before it can start > utilizing Mobile IPv6. RFC 3775 requires that some or all of these > parameters are statically configured. Mobile IPv6 bootstrapping work > aims to make this information dynamically available to the Mobile > Node. An important aspect of the Mobile IPv6 bootstrapping solution > is to support interworking with existing authentication, > authorization and accounting infrastructure. This document describes > the MIPv6 bootstrapping using the Diameter Network Access Server > (NAS) to home Authentication, Authorization and Accounting server > (HAAA) interface. > >Working Group Summary > > There is consensus in the WG to publish this document. > >Document Quality > > The document has received extensive reviews from DIME and MIP6 > working group members. This document is a building block in the > Mobile IPv6 bootstrapping architecture. Area review was >performed by > > Dan Romascanu, and GenART review by Vijay Gurbani. > >Personnel > > David Frascone is the document shepherd, Dan Romascanu is the > responsible Area Director. > >RFC Editor Note > > RFC Editor, before publication please make the following change: > > Section 4.2.1, first line: > s/type of Grouped/of type Grouped/ > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/ietf-announce >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jan 14 09:15:03 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C4C13A69B8; Wed, 14 Jan 2009 09:15:03 -0800 (PST) X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D26063A69B8; Wed, 14 Jan 2009 09:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090114171501.D26063A69B8@core3.amsl.com> Date: Wed, 14 Jan 2009 09:15:01 -0800 (PST) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-erp-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: , Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --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, et al. Filename : draft-ietf-dime-erp-00.txt Pages : 9 Date : 2009-01-14 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 any EAP/ERP authenticator. This document specifies Diameter support for ERP. The Diameter EAP application is re-used for encapsulating the newly defined EAP codes specified in the ERP specification. Additionally, this document also defines specific Diameter processing rules relevant to ERP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-erp-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-erp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-14090018.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Wed Jan 14 11:11:30 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0DE73A69FE; Wed, 14 Jan 2009 11:11:30 -0800 (PST) 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 BF8DE3A69FE for ; Wed, 14 Jan 2009 11:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.162, 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 A7dzzxxmI6qH for ; Wed, 14 Jan 2009 11:11:27 -0800 (PST) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id 5A1553A686A for ; Wed, 14 Jan 2009 11:11:27 -0800 (PST) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id 3Uyp1b0060b6N64A4XBDWG; Wed, 14 Jan 2009 19:11:13 +0000 Received: from gwzPC ([67.160.38.190]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id 3XBB1b002469TLb8PXBBQ9; Wed, 14 Jan 2009 19:11:12 +0000 From: "Glen Zorn" To: "'Tina TSOU'" References: <027f01c9762b$f6e45440$7427460a@china.huawei.com> In-Reply-To: <027f01c9762b$f6e45440$7427460a@china.huawei.com> Date: Wed, 14 Jan 2009 11:10:41 -0800 Message-ID: <003601c9767b$cbc06b50$634141f0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acl2K/0sS2uPrBG5S0Kbf7X45HehgAATi8+w Content-Language: en-us Cc: dime@ietf.org, diameter-routing@googlegroups.com Subject: Re: [Dime] Questions as input to Thursday's diameter routing DT meeting are following. 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: , Content-Type: multipart/mixed; boundary="===============2102539705==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============2102539705== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0037_01C97638.BD9D2B50" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_0037_01C97638.BD9D2B50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tina TSOU [tena@huawei.com] writes: Hi all, Questions as input to Thursday's diameter routing DT meeting are following. Could we make a decision on how to proceed with explicit routing problem, now that the problem seems to be there for ERP as well (see Julien's problem summary mail today)? Perhaps I wasn't clear in my previous message: there is no need whatsoever for "explicit routing" for Diameter messages containing ERP-related AVPs, nor is there any necessity for AAA agents or servers to be co-located with hokey server. The hokey WG did not design a protocol that requires the fundamental operation of Diameter (or RADIUS, for that matter) to be modified because that would have been, well, stupid (what that says about the 3GPP "architecture" I leave up to you ;-). hokey is a separate & distinct network service that happens to use AAA as a transport, not a Diameter application. It is a requirement that AAA agents/servers & hokey servers to communicate, but the means of communication is implementation-specific. May I ask the DT how many would like to see this problem being solved in the WG? Wish you a prosperous and healthy New Year:D B. R. Tina ------=_NextPart_000_0037_01C97638.BD9D2B50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tina TSOU [tena@huawei.com] writes:

 

Hi all,

 

Questions as input to Thursday's diameter routing DT meeting are = following.

 

Could we make a decision on how to proceed with explicit routing problem, now = that the problem seems to be there for ERP as well (see Julien's problem = summary mail today)?

Perhaps I wasn't clear in my previous message: there is = no need whatsoever for "explicit routing" for Diameter messages = containing ERP-related AVPs, nor is there any necessity for AAA agents or servers = to be co-located with hokey server.  The hokey WG did not design a = protocol that requires the fundamental operation of Diameter (or RADIUS, for that = matter) to be modified because that would have been, well, stupid (what that = says about the 3GPP "architecture" I leave up to you ;-).  = hokey is a separate & distinct network service that happens to use AAA as a = transport, not a Diameter application.  It is a requirement that AAA agents/servers & hokey servers to communicate, but the means of communication is implementation-specific. 

 

May I ask the DT how many would like to see this problem being solved in the = WG?

 

 

Wish you a prosperous and healthy New Year:D

 

B. R.
Tina

------=_NextPart_000_0037_01C97638.BD9D2B50-- --===============2102539705== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============2102539705==-- From dime-bounces@ietf.org Thu Jan 15 00:04:58 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 819C13A6924; Thu, 15 Jan 2009 00:04:58 -0800 (PST) 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 B90183A6945 for ; Tue, 13 Jan 2009 17:24:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.822 X-Spam-Level: X-Spam-Status: No, score=-0.822 tagged_above=-999 required=5 tests=[AWL=-0.328, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 TotqNcUHc+lJ for ; Tue, 13 Jan 2009 17:24:06 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id F08343A691D for ; Tue, 13 Jan 2009 17:24:04 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDF00AJIT7FMD@szxga04-in.huawei.com> for dime@ietf.org; Wed, 14 Jan 2009 09:23:40 +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 <0KDF00HL3T7FNJ@szxga04-in.huawei.com> for dime@ietf.org; Wed, 14 Jan 2009 09:23:39 +0800 (CST) Received: from z24109b ([10.70.39.116]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KDF00LIET7F8S@szxml04-in.huawei.com> for dime@ietf.org; Wed, 14 Jan 2009 09:23:39 +0800 (CST) Date: Wed, 14 Jan 2009 09:23:38 +0800 From: Tina TSOU To: dime@ietf.org Message-id: <006e01c975e6$bab2fcf0$7427460a@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 X-Priority: 3 X-MSMail-priority: Normal X-Mailman-Approved-At: Thu, 15 Jan 2009 00:04:57 -0800 Subject: [Dime] clearer draft-tsou-dime-routing-problem-statement-01 for the DT meeting on Jan 15th, Thu 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: , Content-Type: multipart/mixed; boundary="===============0247650606==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0247650606== Content-type: multipart/alternative; boundary="Boundary_(ID_gTcVw73nmVlPxItyPoPZWw)" This is a multi-part message in MIME format. --Boundary_(ID_gTcVw73nmVlPxItyPoPZWw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Dear all, The .txt and .xml file could be found in http://groups.google.com/group/diameter-routing http://groups.google.com/group/diameter-routing/browse_thread/thread/899e7568e09634b0 Wish you a prosperous and healthy New Year:D B. R. Tina ----- Original Message ----- From: Tina TSOU To: diameter-routing@googlegroups.com Sent: Wednesday, January 14, 2009 9:15 AM Subject: clearer draft-tsou-dime-routing-problem-statement-01 for the DT meeting on Jan 15th, Thu Dear all, As promised, attached please find a clearer draft-tsou-dime-routing-problem-statement-01 for the DT meeting on Jan 15th, Thu. Problem 3 has been deleted, and more explanation to problem 2 use case has been added. Comments are very welcome before and in the DT meeting. Wish you a prosperous and healthy New Year:D B. R. Tina --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "diameter-routing" group. To post to this group, send email to diameter-routing@googlegroups.com To unsubscribe from this group, send email to diameter-routing+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/diameter-routing?hl=en -~----------~----~----~----~------~----~------~--~--- -------------------------------------------------------------------------------- Internet Engineering Task Force T. Tsou, Ed. Internet-Draft Huawei Technologies Intended status: Informational January 14, 2009 Expires: July 18, 2009 Diameter Routing Problem Statement draft-tsou-dime-routing-problem-statement-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 18, 2009. Abstract This document describes use cases that suggest requirements to be able to add constraints to the existing Diameter routing mechanisms. 1. Introduction In [RFC3588], routing of request messages from source to the destination is based solely on the routing decision made by each node along the path. This document presents three different cases where the basic Diameter routing behaviour is not sufficient to meet the requirements. It then provides three problem statements corresponding to the three cases. Further analysis is required to Tsou Expires July 18, 2009 [Page 1] Internet-Draft Diameter Routing Problem Statement January 2009 determine if the number of problems to be solved can be reduced. 2. Requirements Language This document contains no requirements language. 3. Use Cases 3.1. 3GPP Wireless LAN (WLAN) Access Architecture One example of a stateful proxy is in the 3GPP WLAN IP access architecture [TS23.234]. The 3GPP WLAN interworking architecture extends 3GPP services to the WLAN access side. It enables a 3GPP subscriber to use a WLAN to access 3GPP services. WLAN AAA provides access to the WLAN to be authenticated and authorised through the 3GPP system. This access control can permit or deny a subscriber the access to the WLAN system and/or the interworking with the 3GPP system. There are two WLAN interworking reference models: 1. In the non-roaming case, the model includes the WLAN access network and the 3GPP AAA server in the home network. The 3GPP AAA server is responsible for access control as well as charging. 2. In the roaming case, the model includes the WLAN access network, the 3GPP AAA proxy in the visited network and the 3GPP AAA server in the home network. The 3GPP AAA server is responsible for access control. Charging records may be generated by the AAA proxy and/or the AAA server. The AAA proxy relays access control and charging messages to the AAA server. The AAA proxy will also do offline charging, if required. The roaming case presents two problems for which the Diameter routing mechanism described in [RFC3588] does not offer any unambiguous and standard solution. 1. Network selection: Selecting an initial message path for the Diameter session through (possibly many) alternative visited network(s) to the home network. 2. Explicit Routing: Maintaining the selected message path for all messages in the Diameter session. These problems are discussed in detail in the following sections. Tsou Expires July 18, 2009 [Page 2] Internet-Draft Diameter Routing Problem Statement January 2009 3.1.1. Initial Selection of Routing Path In the 3GPP model we are considering, the WLAN access network is simply a substitute for the radio access network of a cellular operator. Two other operating entities are involved in providing IP service to the roaming user: a visited mobile network to which the WLAN access network is directly connected, and the user's home mobile network. Consider the realistic model where the WLAN access network is connected to multiple mobile networks with which the user's home network has roaming agreements. A particular visited network has to be selected for authentication. There are three possibilities: o the WLAN access network automatically selects a preferred routing; o the WLAN access network advertises the available networks to the UE, which makes an automatic selection based on pre-configured policy; o the WLAN access network advertises the available networks to the UE, which presents the choices to the user and asks the user to make a selection. Once the visited network has been selected, Diameter currently does not fully standardize the means by which the Diameter client in the WLAN access network ensures that its initial request passes through the 3GPP AAA proxy in the chosen network. 3.1.2. Maintaining the Routing Path After a successful authentication, a Diameter session is established involving (at least) the following stateful entities: o The Diameter client in the WLAN AN o a Diameter proxy (the 3GPP AAA proxy) in the selected visited mobile network, and o a Diameter server in the UE's home realm. The functions assigned to the 3GPP AAA proxy include: o reporting charging information to the offline charging system in the visited network; o enforcing policies based on roaming agreements; Tsou Expires July 18, 2009 [Page 3] Internet-Draft Diameter Routing Problem Statement January 2009 o service termination initiated by the visited network operator. These functions all require that state be maintained within the visited network. The 3GPP choice is to maintain that state at the 3GPP AAA proxy. This means that the latter must remain in the messaging path for all subsequent messages relating to the same session. The network model with the client, the proxy and the server as described above is simplistic. Operators would usually deploy more than one proxy in the visited network and more than one server in the home network for better availability and load sharing. Relays are also used at the edges of these networks for topology hiding and load balancing. Thus a realistic network model would typically involve some stateless agents also in the session path. 3.2. Redirect Indication based on realm Consider an Operator; say Operator_A offering some service to Diameter client in its Realm; say Realm_A. For business/maintenance reasons, the operator wants to discontinue the service. However the operator has asked another Operator; say Operator_B (serving Realm_B) to provide the service to the clients. In this case, all the clients should be configured to contact Realm_B instead of Realm_A for the service. For smooth transition, agents may be employed in Realm_A which could answer with a redirect indication suggesting that the service requests may be sent to another realm; Realm_B in this case, so as to be served 4. Problem Statements This section provides problem statements for the three use cases described above. 4.1. Initial Network Selection Note: this problem statement is here for completeness. There is agremeent that work on decorated NAI will go forward to remedy this specific problem. This is the statement of the problem posed by the case presented in Section 3.1.1. 1. Existing Diameter message routing behaviour: it is possible to direct a message through a specific intermediate realm using the Tsou Expires July 18, 2009 [Page 4] Internet-Draft Diameter Routing Problem Statement January 2009 decorated NAI mechanism within the User Name AVP. However, [RFC3588] does not unambiguously specify how to handle the decorated NAI i.e. how the Diameter client and agents participating in request routing may use the decorated NAI to update the Destination-Realm AVP. 2. Undesirable behaviour in the existing method: unpredictable results since the required mechanism has not been fully standardized. 3. Desired behaviour: the intermediate realm specified in the decorated NAI is traversed first, followed by the home user realm. This is required whenever a decorated NAI is presented. Section 3.1.1 describes the sort of environment where this requirement could arise. 4.2. Path Maintenance This is the statement of the problem posed by the case presented in Section 3.1.2. 1. Existing Diameter message routing behaviour: each host along the path makes its own independent routing decisions. 2. Undesirable behaviour in the existing method: routing of all messages for a given session through the selected 3GPP AAA proxy is not guaranteed if the visited mobile network has multiple proxies or if there are other Diameter entities between the WLAN client and the target 3GPP proxy. 3. Desired behaviour: regardless of the intervening set of Diameter elements, all messages for a given session pass through the proxy initially selected. This is required for stateful proxies only. Section 3.1.2 describes the sort of environment where this requirement could arise. 4.3. Redirect Indication based on realm This is the statement of the problem posed by the case presented in Section 3.2. 1. Existing Diameter message routing behaviour: Redirect indication is provided at host level. It provides a list of servers that may be contacted for the request to be served. 2. Undesirable behaviour in the existing method: Redirect indication is not provided at the realm level. There is no option to provide a (list of) realm(s) that may be contacted for the Tsou Expires July 18, 2009 [Page 5] Internet-Draft Diameter Routing Problem Statement January 2009 request to be served. 3. Desired behaviour: Redirect indication could be provided at the realm level also. The indication may specify a (list of) realm(s) which could be contacted for the request to be served. 5. Acknowledgements Text on the 3GPP WLAN use cases was provided by Rajith R. Glen Zorn provided the problem statement template used in Section 4. 6. IANA Considerations This memo includes no request to IANA. 7. Security Considerations It is possible that there are security issues with the problems stated above, but they are not immediately evident. 8. References 8.1. Normative References [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 8.2. Informative References [TS23.234] 3GPP, "TS23.234v7.7.0, 3GPP system to Wireless Local Area Network (WLAN) interworking; System description", June 2008. Tsou Expires July 18, 2009 [Page 6] Internet-Draft Diameter Routing Problem Statement January 2009 Author's Address Tina Tsou (editor) Huawei Technologies Section F, Huawei Industrial Base Bantian Longgang, Shenzhen 518129 P.R. China Phone: +86 755 28972912 Email: tena@huawei.com Tsou Expires July 18, 2009 [Page 7] Internet-Draft Diameter Routing Problem Statement January 2009 Full Copyright Statement Copyright (C) The IETF Trust (2009). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Tsou Expires July 18, 2009 [Page 8] -------------------------------------------------------------------------------- ]> Diameter Routing Problem Statement Huawei Technologies
Section F, Huawei Industrial Base Bantian Longgang Shenzhen 518129 P.R. China +86 755 28972912 tena@huawei.com
Operations and Management Internet Engineering Task Force This document describes use cases that suggest requirements to be able to add constraints to the existing Diameter routing mechanisms.
In , routing of request messages from source to the destination is based solely on the routing decision made by each node along the path. This document presents three different cases where the basic Diameter routing behaviour is not sufficient to meet the requirements. It then provides three problem statements corresponding to the three cases. Further analysis is required to determine if the number of problems to be solved can be reduced.
This document contains no requirements language.
One example of a stateful proxy is in the 3GPP WLAN IP access architecture . The 3GPP WLAN interworking architecture extends 3GPP services to the WLAN access side. It enables a 3GPP subscriber to use a WLAN to access 3GPP services. WLAN AAA provides access to the WLAN to be authenticated and authorised through the 3GPP system. This access control can permit or deny a subscriber the access to the WLAN system and/or the interworking with the 3GPP system. There are two WLAN interworking reference models: In the non-roaming case, the model includes the WLAN access network and the 3GPP AAA server in the home network. The 3GPP AAA server is responsible for access control as well as charging. In the roaming case, the model includes the WLAN access network, the 3GPP AAA proxy in the visited network and the 3GPP AAA server in the home network. The 3GPP AAA server is responsible for access control. Charging records may be generated by the AAA proxy and/or the AAA server. The AAA proxy relays access control and charging messages to the AAA server. The AAA proxy will also do offline charging, if required. The roaming case presents two problems for which the Diameter routing mechanism described in does not offer any unambiguous and standard solution. Network selection: Selecting an initial message path for the Diameter session through (possibly many) alternative visited network(s) to the home network. Explicit Routing: Maintaining the selected message path for all messages in the Diameter session. These problems are discussed in detail in the following sections.
In the 3GPP model we are considering, the WLAN access network is simply a substitute for the radio access network of a cellular operator. Two other operating entities are involved in providing IP service to the roaming user: a visited mobile network to which the WLAN access network is directly connected, and the user's home mobile network. Consider the realistic model where the WLAN access network is connected to multiple mobile networks with which the user's home network has roaming agreements. A particular visited network has to be selected for authentication. There are three possibilities: the WLAN access network automatically selects a preferred routing; the WLAN access network advertises the available networks to the UE, which makes an automatic selection based on pre-configured policy; the WLAN access network advertises the available networks to the UE, which presents the choices to the user and asks the user to make a selection. Once the visited network has been selected, Diameter currently does not fully standardize the means by which the Diameter client in the WLAN access network ensures that its initial request passes through the 3GPP AAA proxy in the chosen network.
After a successful authentication, a Diameter session is established involving (at least) the following stateful entities: The Diameter client in the WLAN AN a Diameter proxy (the 3GPP AAA proxy) in the selected visited mobile network, and a Diameter server in the UE's home realm. The functions assigned to the 3GPP AAA proxy include: reporting charging information to the offline charging system in the visited network; enforcing policies based on roaming agreements; service termination initiated by the visited network operator. These functions all require that state be maintained within the visited network. The 3GPP choice is to maintain that state at the 3GPP AAA proxy. This means that the latter must remain in the messaging path for all subsequent messages relating to the same session. The network model with the client, the proxy and the server as described above is simplistic. Operators would usually deploy more than one proxy in the visited network and more than one server in the home network for better availability and load sharing. Relays are also used at the edges of these networks for topology hiding and load balancing. Thus a realistic network model would typically involve some stateless agents also in the session path.
Consider an Operator; say Operator_A offering some service to Diameter client in its Realm; say Realm_A. For business/maintenance reasons, the operator wants to discontinue the service. However the operator has asked another Operator; say Operator_B (serving Realm_B) to provide the service to the clients. In this case, all the clients should be configured to contact Realm_B instead of Realm_A for the service. For smooth transition, agents may be employed in Realm_A which could answer with a redirect indication suggesting that the service requests may be sent to another realm; Realm_B in this case, so as to be served
This section provides problem statements for the three use cases described above.
Note: this problem statement is here for completeness. There is agremeent that work on decorated NAI will go forward to remedy this specific problem. This is the statement of the problem posed by the case presented in . Existing Diameter message routing behaviour: it is possible to direct a message through a specific intermediate realm using the decorated NAI mechanism within the User Name AVP. However, does not unambiguously specify how to handle the decorated NAI i.e. how the Diameter client and agents participating in request routing may use the decorated NAI to update the Destination-Realm AVP. Undesirable behaviour in the existing method: unpredictable results since the required mechanism has not been fully standardized. Desired behaviour: the intermediate realm specified in the decorated NAI is traversed first, followed by the home user realm. This is required whenever a decorated NAI is presented. describes the sort of environment where this requirement could arise.
This is the statement of the problem posed by the case presented in . Existing Diameter message routing behaviour: each host along the path makes its own independent routing decisions. Undesirable behaviour in the existing method: routing of all messages for a given session through the selected 3GPP AAA proxy is not guaranteed if the visited mobile network has multiple proxies or if there are other Diameter entities between the WLAN client and the target 3GPP proxy. Desired behaviour: regardless of the intervening set of Diameter elements, all messages for a given session pass through the proxy initially selected. This is required for stateful proxies only. describes the sort of environment where this requirement could arise.
This is the statement of the problem posed by the case presented in . Existing Diameter message routing behaviour: Redirect indication is provided at host level. It provides a list of servers that may be contacted for the request to be served. Undesirable behaviour in the existing method: Redirect indication is not provided at the realm level. There is no option to provide a (list of) realm(s) that may be contacted for the request to be served. Desired behaviour: Redirect indication could be provided at the realm level also. The indication may specify a (list of) realm(s) which could be contacted for the request to be served.
Text on the 3GPP WLAN use cases was provided by Rajith R. Glen Zorn provided the problem statement template used in .
This memo includes no request to IANA.
It is possible that there are security issues with the problems stated above, but they are not immediately evident.
&RFC3588; TS23.234v7.7.0, 3GPP system to Wireless Local Area Network (WLAN) interworking; System description 3GPP --Boundary_(ID_gTcVw73nmVlPxItyPoPZWw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Dear all,
The .txt and .xml file could be found in
 
Wish you a prosperous and healthy New Year:D
 
B. R.
Tina
 
----- Original Message -----
From: Tina TSOU
Sent: Wednesday, January 14, 2009 9:15 AM
Subject: clearer draft-tsou-dime-routing-problem-statement-01 for the DT meeting on Jan 15th, Thu

Dear all,
As promised, attached please find a clearer draft-tsou-dime-routing-problem-statement-01 for the DT meeting on Jan 15th, Thu.
Problem 3 has been deleted, and more explanation to problem 2 use case has been added.
 
Comments are very welcome before and in the DT meeting.
 
Wish you a prosperous and healthy New Year:D
 
B. R.
Tina

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "diameter-routing" group.
To post to this group, send email to diameter-routing@googlegroups.com
To unsubscribe from this group, send email to diameter-routing+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/diameter-routing?hl=en
-~----------~----~----~----~------~----~------~--~---




Internet Engineering Task Force                             T. Tsou, Ed.
Internet-Draft                                       Huawei Technologies
Intended status: Informational                          January 14, 2009
Expires: July 18, 2009


                   Diameter Routing Problem Statement
              draft-tsou-dime-routing-problem-statement-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 18, 2009.

Abstract

   This document describes use cases that suggest requirements to be
   able to add constraints to the existing Diameter routing mechanisms.


1.  Introduction

   In [RFC3588], routing of request messages from source to the
   destination is based solely on the routing decision made by each node
   along the path.  This document presents three different cases where
   the basic Diameter routing behaviour is not sufficient to meet the
   requirements.  It then provides three problem statements
   corresponding to the three cases.  Further analysis is required to



Tsou                      Expires July 18, 2009                 [Page 1]

Internet-Draft     Diameter Routing Problem Statement       January 2009


   determine if the number of problems to be solved can be reduced.


2.  Requirements Language

   This document contains no requirements language.


3.  Use Cases

3.1.  3GPP Wireless LAN (WLAN) Access Architecture

   One example of a stateful proxy is in the 3GPP WLAN IP access
   architecture [TS23.234].  The 3GPP WLAN interworking architecture
   extends 3GPP services to the WLAN access side.  It enables a 3GPP
   subscriber to use a WLAN to access 3GPP services.

   WLAN AAA provides access to the WLAN to be authenticated and
   authorised through the 3GPP system.  This access control can permit
   or deny a subscriber the access to the WLAN system and/or the
   interworking with the 3GPP system.

   There are two WLAN interworking reference models:

   1.  In the non-roaming case, the model includes the WLAN access
       network and the 3GPP AAA server in the home network.  The 3GPP
       AAA server is responsible for access control as well as charging.

   2.  In the roaming case, the model includes the WLAN access network,
       the 3GPP AAA proxy in the visited network and the 3GPP AAA server
       in the home network.  The 3GPP AAA server is responsible for
       access control.  Charging records may be generated by the AAA
       proxy and/or the AAA server.  The AAA proxy relays access control
       and charging messages to the AAA server.  The AAA proxy will also
       do offline charging, if required.

   The roaming case presents two problems for which the Diameter routing
   mechanism described in [RFC3588] does not offer any unambiguous and
   standard solution.

   1.  Network selection: Selecting an initial message path for the
       Diameter session through (possibly many) alternative visited
       network(s) to the home network.

   2.  Explicit Routing: Maintaining the selected message path for all
       messages in the Diameter session.

   These problems are discussed in detail in the following sections.



Tsou                      Expires July 18, 2009                 [Page 2]

Internet-Draft     Diameter Routing Problem Statement       January 2009


3.1.1.  Initial Selection of Routing Path

   In the 3GPP model we are considering, the WLAN access network is
   simply a substitute for the radio access network of a cellular
   operator.  Two other operating entities are involved in providing IP
   service to the roaming user: a visited mobile network to which the
   WLAN access network is directly connected, and the user's home mobile
   network.

   Consider the realistic model where the WLAN access network is
   connected to multiple mobile networks with which the user's home
   network has roaming agreements.  A particular visited network has to
   be selected for authentication.  There are three possibilities:

   o  the WLAN access network automatically selects a preferred routing;

   o  the WLAN access network advertises the available networks to the
      UE, which makes an automatic selection based on pre-configured
      policy;

   o  the WLAN access network advertises the available networks to the
      UE, which presents the choices to the user and asks the user to
      make a selection.

   Once the visited network has been selected, Diameter currently does
   not fully standardize the means by which the Diameter client in the
   WLAN access network ensures that its initial request passes through
   the 3GPP AAA proxy in the chosen network.

3.1.2.  Maintaining the Routing Path

   After a successful authentication, a Diameter session is established
   involving (at least) the following stateful entities:

   o  The Diameter client in the WLAN AN

   o  a Diameter proxy (the 3GPP AAA proxy) in the selected visited
      mobile network, and

   o  a Diameter server in the UE's home realm.

   The functions assigned to the 3GPP AAA proxy include:

   o  reporting charging information to the offline charging system in
      the visited network;

   o  enforcing policies based on roaming agreements;




Tsou                      Expires July 18, 2009                 [Page 3]

Internet-Draft     Diameter Routing Problem Statement       January 2009


   o  service termination initiated by the visited network operator.

   These functions all require that state be maintained within the
   visited network.  The 3GPP choice is to maintain that state at the
   3GPP AAA proxy.  This means that the latter must remain in the
   messaging path for all subsequent messages relating to the same
   session.

   The network model with the client, the proxy and the server as
   described above is simplistic.  Operators would usually deploy more
   than one proxy in the visited network and more than one server in the
   home network for better availability and load sharing.  Relays are
   also used at the edges of these networks for topology hiding and load
   balancing.  Thus a realistic network model would typically involve
   some stateless agents also in the session path.

3.2.  Redirect Indication based on realm

   Consider an Operator; say Operator_A offering some service to
   Diameter client in its Realm; say Realm_A. For business/maintenance
   reasons, the operator wants to discontinue the service.  However the
   operator has asked another Operator; say Operator_B (serving Realm_B)
   to provide the service to the clients.  In this case, all the clients
   should be configured to contact Realm_B instead of Realm_A for the
   service.

   For smooth transition, agents may be employed in Realm_A which could
   answer with a redirect indication suggesting that the service
   requests may be sent to another realm; Realm_B in this case, so as to
   be served


4.  Problem Statements

   This section provides problem statements for the three use cases
   described above.

4.1.  Initial Network Selection

   Note: this problem statement is here for completeness.  There is
   agremeent that work on decorated NAI will go forward to remedy this
   specific problem.

   This is the statement of the problem posed by the case presented in
   Section 3.1.1.

   1.  Existing Diameter message routing behaviour: it is possible to
       direct a message through a specific intermediate realm using the



Tsou                      Expires July 18, 2009                 [Page 4]

Internet-Draft     Diameter Routing Problem Statement       January 2009


       decorated NAI mechanism within the User Name AVP.  However,
       [RFC3588] does not unambiguously specify how to handle the
       decorated NAI i.e. how the Diameter client and agents
       participating in request routing may use the decorated NAI to
       update the Destination-Realm AVP.

   2.  Undesirable behaviour in the existing method: unpredictable
       results since the required mechanism has not been fully
       standardized.

   3.  Desired behaviour: the intermediate realm specified in the
       decorated NAI is traversed first, followed by the home user
       realm.  This is required whenever a decorated NAI is presented.
       Section 3.1.1 describes the sort of environment where this
       requirement could arise.

4.2.  Path Maintenance

   This is the statement of the problem posed by the case presented in
   Section 3.1.2.

   1.  Existing Diameter message routing behaviour: each host along the
       path makes its own independent routing decisions.

   2.  Undesirable behaviour in the existing method: routing of all
       messages for a given session through the selected 3GPP AAA proxy
       is not guaranteed if the visited mobile network has multiple
       proxies or if there are other Diameter entities between the WLAN
       client and the target 3GPP proxy.

   3.  Desired behaviour: regardless of the intervening set of Diameter
       elements, all messages for a given session pass through the proxy
       initially selected.  This is required for stateful proxies only.
       Section 3.1.2 describes the sort of environment where this
       requirement could arise.

4.3.  Redirect Indication based on realm

   This is the statement of the problem posed by the case presented in
   Section 3.2.

   1.  Existing Diameter message routing behaviour: Redirect indication
       is provided at host level.  It provides a list of servers that
       may be contacted for the request to be served.

   2.  Undesirable behaviour in the existing method: Redirect indication
       is not provided at the realm level.  There is no option to
       provide a (list of) realm(s) that may be contacted for the



Tsou                      Expires July 18, 2009                 [Page 5]

Internet-Draft     Diameter Routing Problem Statement       January 2009


       request to be served.

   3.  Desired behaviour: Redirect indication could be provided at the
       realm level also.  The indication may specify a (list of)
       realm(s) which could be contacted for the request to be served.


5.  Acknowledgements

   Text on the 3GPP WLAN use cases was provided by Rajith R. Glen Zorn
   provided the problem statement template used in Section 4.


6.  IANA Considerations

   This memo includes no request to IANA.


7.  Security Considerations

   It is possible that there are security issues with the problems
   stated above, but they are not immediately evident.


8.  References

8.1.  Normative References

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

8.2.  Informative References

   [TS23.234]
              3GPP, "TS23.234v7.7.0, 3GPP system to Wireless Local Area
              Network (WLAN) interworking; System description",
              June 2008.














Tsou                      Expires July 18, 2009                 [Page 6]

Internet-Draft     Diameter Routing Problem Statement       January 2009


Author's Address

   Tina Tsou (editor)
   Huawei Technologies
   Section F, Huawei Industrial Base
   Bantian Longgang, Shenzhen  518129
   P.R. China

   Phone: +86 755 28972912
   Email: tena@huawei.com









































Tsou                      Expires July 18, 2009                 [Page 7]

Internet-Draft     Diameter Routing Problem Statement       January 2009


Full Copyright Statement

   Copyright (C) The IETF Trust (2009).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Tsou                      Expires July 18, 2009                 [Page 8]


<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced.
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC3588 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="no"?>
<!-- generate a ToC -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-tsou-dime-routing-problem-statement-01" ipr="full3978">

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the
         full title is longer than 39 characters -->

    <title>Diameter Routing Problem Statement</title>

    <author fullname="Tina Tsou" initials="T." role="editor"
            surname="Tsou">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>Section F, Huawei Industrial Base</street>

          <!-- Reorder these if your country does things differently -->

          <city>Bantian Longgang</city>

          <region>Shenzhen</region>

          <code>518129</code>

          <country>P.R. China</country>
        </postal>

        <phone>+86 755 28972912</phone>

        <email>tena@huawei.com</email>
      </address>
    </author>

    <date month="January" year="2009" />

    <!-- Meta-data Declarations -->

    <area>Operations and Management</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <abstract>
      <t>This document describes use cases that suggest requirements to be able to add constraints to the existing Diameter routing mechanisms. </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>In <xref target="RFC3588"/>, routing of request messages from source to the destination is based solely on the routing decision made by each node along the path.  This document presents three different cases where the basic Diameter routing behaviour is not sufficient to meet the requirements. It then provides three problem statements corresponding to the three cases. Further analysis is required to determine if the number of problems to be solved can be reduced.
</t>
    </section>

      <section title="Requirements Language">
        <t>This document contains no requirements language.</t>      </section>

<section anchor="usecas" title="Use Cases">

<section anchor="wlan" title="3GPP Wireless LAN (WLAN) Access Architecture">

<t>One example of a stateful proxy is in the 3GPP WLAN IP access architecture <xref target="TS23.234"/>.  The 3GPP WLAN interworking architecture extends 3GPP services to the WLAN access side.  It enables a 3GPP subscriber to use a WLAN to access 3GPP services.</t>

<t>   WLAN AAA provides access to the WLAN to be authenticated and authorised through the 3GPP system.  This access control can permit or deny a subscriber the access to the WLAN system and/or the interworking with the 3GPP system.</t>

<t>   There are two WLAN interworking reference models:

<list style="numbers">
<t>   In the non-roaming case, the model includes the WLAN access network and the 3GPP AAA server in the home network.  The 3GPP AAA server is responsible for access control as well as charging.</t>

<t>   In the roaming case, the model includes the WLAN access network, the 3GPP AAA proxy in the visited network and the 3GPP AAA server in the home network.  The 3GPP AAA server is responsible for access control.  Charging records may be generated by the AAA proxy and/or the AAA server.  The AAA proxy relays access control and charging messages to the AAA server.  The AAA proxy will also do offline charging, if required.</t>

</list>

</t>

<t>   The roaming case presents two problems for which the Diameter routing mechanism described in <xref target="RFC3588"/> does not offer any unambiguous and standard solution.

<list style="numbers">
<t>   Network selection: Selecting an initial message path for the Diameter session through (possibly many) alternative visited network(s) to the home network.</t>

<t>   Explicit Routing: Maintaining the selected message path for all messages in the Diameter session.</t>

</list>
</t>

<t>These problems are discussed in detail in the following sections.
</t>

<section anchor="netsel" title="Initial Selection of Routing Path">

<t>In the 3GPP model we are considering, the WLAN access network is simply a substitute for the radio access network of a cellular operator. Two other operating entities are involved in providing IP service to the roaming user: a visited mobile network to which the WLAN access network is directly connected, and the user's home mobile network.</t>

<t>Consider the realistic model where the WLAN access network is connected to multiple mobile networks with which the user's home network has roaming agreements.  A particular visited network has to be selected for authentication. There are three possibilities:
<list style="symbols">
<t>the WLAN access network automatically selects a preferred routing;</t>

<t>the WLAN access network advertises the available networks to the UE, which makes an automatic selection based on pre-configured policy;</t>

<t>the WLAN access network advertises the available networks to the UE, which presents the choices to the user and asks the user to make a selection.</t>

</list>
 
</t>

<t>Once the visited network has been selected, Diameter currently does not fully standardize the means by which the Diameter client in the WLAN access network ensures that its initial request passes through the 3GPP AAA proxy in the chosen network. </t>

</section><!-- netsel -->

<section anchor="keepPath" title="Maintaining the Routing Path">

<t>   After a successful authentication, a Diameter session is established involving (at least) the following stateful entities:

<list style="symbols">
<t>   The Diameter client in the WLAN AN</t>

<t>   a Diameter proxy (the 3GPP AAA proxy) in the selected visited mobile network, and</t>

<t>   a Diameter server in the UE's home realm.</t>

</list>
</t>

<t>   The functions assigned to the 3GPP AAA proxy include:

<list style="symbols">
<t>   reporting charging information to the offline charging system in the visited network;</t>

<t>   enforcing policies based on roaming agreements;</t>

<t>   service termination initiated by the visited network operator.</t>

</list>
</t>

<t>These functions all require that state be maintained within the visited network. The 3GPP choice is to maintain that state at the 3GPP AAA proxy. This means that the latter must remain in the messaging path for all subsequent messages relating to the same session.</t>

<t>The network model with the client, the proxy and the server as described above is simplistic. Operators would usually
deploy more than one proxy in the visited network and more than one server in the home network for better availability
and load sharing. Relays are also used at the edges of these networks for topology hiding and load balancing. Thus a
realistic network model would typically involve some stateless agents also in the session path.</t>

</section><!-- keepPath -->

</section><!-- wlan -->

<section anchor="relmRedir" title="Redirect Indication based on realm">

<!-- Tina and Rajiv add your use case here -->
<t>Consider an Operator; say Operator_A offering some service to Diameter client in its Realm; say Realm_A. For business/maintenance reasons, the operator wants to discontinue the service. However the operator has asked another Operator; say Operator_B (serving Realm_B) to provide the service to the clients. In this case, all the clients should be configured to contact Realm_B instead of Realm_A for the service.</t>
<t>For smooth transition, agents may be employed in Realm_A which could answer with a redirect indication suggesting that the  service requests may be sent to another realm; Realm_B in this case, so as to be served</t>

</section><!-- relmRedir -->


</section><!-- usecas -->

<section anchor="problems" title="Problem Statements">

<t>This section provides problem statements for the three use cases described above.</t>

<section anchor="netselprob" title="Initial Network Selection ">

<t>Note: this problem statement is here for completeness. There is agremeent that work on decorated NAI will go forward to remedy this specific problem. </t>

<t>This is the statement of the problem posed by the case presented in <xref target="netsel"/>.
<list style="numbers">
<t>Existing Diameter message routing behaviour: it is possible to direct a message through a specific intermediate realm using the decorated NAI mechanism within the User Name AVP. However, <xref target="RFC3588"/> does not unambiguously specify how to handle the decorated NAI i.e. how the Diameter client and agents participating in request routing may use the decorated NAI to update the Destination-Realm AVP. </t>

<t>Undesirable behaviour in the existing method: unpredictable results since the required mechanism has not been fully standardized.</t>

<t>Desired behaviour: the intermediate realm specified in the decorated NAI is traversed first, followed by the home user realm. This is required whenever a decorated NAI is presented. <xref target="netsel"/> describes the sort of environment where this requirement could arise. </t>

</list>
</t>

</section><!-- netselprob -->

<section anchor="maintprob" title="Path Maintenance">

<t>This is the statement of the problem posed by the case presented in <xref target="keepPath"/>.
<list style="numbers">
<t>Existing Diameter message routing behaviour: each host along the path makes its own independent routing decisions. </t>

<t>Undesirable behaviour in the existing method: routing of all messages for a given session through the selected 3GPP AAA proxy is not guaranteed if the visited mobile network has multiple proxies or if there are other Diameter entities between the WLAN client and the target 3GPP proxy.</t>

<t>Desired behaviour: regardless of the intervening set of Diameter elements, all messages for a given session pass through the proxy initially selected. This is required for stateful proxies only. <xref target="keepPath"/> describes the sort of environment where this requirement could arise. </t>

</list>
</t>
</section><!-- maintprob -->

<section anchor="redrelmprob" title="Redirect Indication based on realm">

<!-- Tina and Rajiv, put the problem statement here -->
<t>This is the statement of the problem posed by the case presented in <xref target="relmRedir"/>.

<list style="numbers">
<t>Existing Diameter message routing behaviour: Redirect indication is provided at host level. It provides a list of servers that may be contacted for the request to be served.
</t>

<t>Undesirable behaviour in the existing method: Redirect indication is not provided at the realm level. There is no option to provide a (list of) realm(s) that may be contacted for the request to be served.</t>

<t>Desired behaviour: Redirect indication could be provided at the realm level also. The indication may specify a (list of) realm(s) which could be contacted for the request to be served.</t>

</list>
</t>

</section><!-- redrelmprob -->


</section><!-- problems -->


    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>Text on the 3GPP WLAN use cases was provided by Rajith R. Glen Zorn provided the problem statement template used in <xref target="problems"/>.</t>

    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo includes no request to IANA.</t>

    </section>

    <section anchor="Security" title="Security Considerations">
      <t>It is possible that there are security issues with the problems stated above, but they are not immediately evident.</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>

    <references title="Normative References">
      &RFC3588;
    </references>

   <references title="Informative References">

      <reference anchor="TS23.234">
        <front>
          <title>TS23.234v7.7.0, 3GPP system to Wireless Local Area Network (WLAN) interworking; System description</title>

          <author>
            <organization>3GPP</organization>
          </author>

          <date year="2008" month="June" day="9" />
        </front>
      </reference>
    </references>



    <!-- Change Log

v00 2008-10-20  TS    Initial version  -->

<!-- v00 2008-12-05  TS    Added fourth problem  -->
<!-- v01 2009-01-13  RR    Deleted third problem, added more details to second problem  -->

  </back>
</rfc>
--Boundary_(ID_gTcVw73nmVlPxItyPoPZWw)-- --===============0247650606== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0247650606==-- From dime-bounces@ietf.org Thu Jan 15 00:04:58 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6CB83A6A39; Thu, 15 Jan 2009 00:04:58 -0800 (PST) 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 B697A3A6887 for ; Wed, 14 Jan 2009 14:29:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.248 X-Spam-Level: X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[AWL=-2.653, BAYES_00=-2.599, FR_DOT_FEVER_5=3.9, J_BACKHAIR_11=1, J_CHICKENPOX_52=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 HRqHPpK+avEH for ; Wed, 14 Jan 2009 14:29:41 -0800 (PST) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 6094D3A66B4 for ; Wed, 14 Jan 2009 14:29:40 -0800 (PST) Received: from [127.0.0.1] (ns.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id n0EMQifg040946; Wed, 14 Jan 2009 17:26:45 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <496E673C.10103@tari.toshiba.com> Date: Wed, 14 Jan 2009 17:29:16 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20090105) MIME-Version: 1.0 To: hannes.tschofenig@nsn.com, Mark Jones Content-Type: multipart/mixed; boundary="------------060707040308080809050505" X-Mailman-Approved-At: Thu, 15 Jan 2009 00:04:57 -0800 Cc: "dime@ietf.org" Subject: [Dime] Review of draft-ietf-dime-qos-attributes-09.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: , Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --------------060707040308080809050505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Hannes/Mark, Attached is my review of the qos-attribute draft. My comments are inlined under "[Victor: ...". best regards, victor --------------060707040308080809050505 Content-Type: text/plain; name="draft-ietf-dime-qos-attributes-09.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-dime-qos-attributes-09.txt" Diameter Maintenance and J. Korhonen Extensions (DIME) H. Tschofenig Internet-Draft Nokia Siemens Networks Intended status: Standards Track M. Arumaithurai Expires: June 21, 2009 University of Goettingen M. Jones, Ed. A. Lior Bridgewater Systems December 18, 2008 Quality of Service Attributes for Diameter draft-ietf-dime-qos-attributes-09.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 21, 2009. Copyright Notice Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Korhonen, et al. Expires June 21, 2009 [Page 1] Internet-Draft QoS Attributes for Diameter December 2008 Abstract This document extends the IPFilterRule AVP functionality of the Diameter Base protocol and the functionality of the QoS-Filter-Rule AVP defined in RFC 4005. The ability to convey Quality of Service information using the AVPs defined in this document is available to existing and future Diameter applications where permitted by the command ABNF. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Rule Sets and Rules . . . . . . . . . . . . . . . . . . . . . 4 3.1. Rule-Set AVP . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Rule AVP . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Traffic Classifiers . . . . . . . . . . . . . . . . . . . 5 4.1.1. Classifier AVP . . . . . . . . . . . . . . . . . . . . 7 4.1.2. Classifier-ID AVP . . . . . . . . . . . . . . . . . . 8 4.1.3. Protocol AVP . . . . . . . . . . . . . . . . . . . . . 8 4.1.4. Direction AVP . . . . . . . . . . . . . . . . . . . . 8 4.1.5. From-Spec AVP . . . . . . . . . . . . . . . . . . . . 9 4.1.6. To-Spec AVP . . . . . . . . . . . . . . . . . . . . . 10 4.1.7. Source and Destination AVPs . . . . . . . . . . . . . 11 4.1.8. Header Option AVPs . . . . . . . . . . . . . . . . . . 15 4.2. Time Of Day AVPs . . . . . . . . . . . . . . . . . . . . . 21 4.2.1. Time-Of-Day-Condition AVP . . . . . . . . . . . . . . 21 4.2.2. Time-Of-Day-Start AVP . . . . . . . . . . . . . . . . 22 4.2.3. Time-Of-Day-End AVP . . . . . . . . . . . . . . . . . 22 4.2.4. Day-Of-Week-Mask AVP . . . . . . . . . . . . . . . . . 22 4.2.5. Day-Of-Month-Mask AVP . . . . . . . . . . . . . . . . 23 4.2.6. Month-Of-Year-Mask AVP . . . . . . . . . . . . . . . . 23 4.2.7. Absolute-Start-Time AVP . . . . . . . . . . . . . . . 23 4.2.8. Absolute-End-Time AVP . . . . . . . . . . . . . . . . 24 4.2.9. Timezone-Flag AVP . . . . . . . . . . . . . . . . . . 24 4.2.10. Timezone-Offset AVP . . . . . . . . . . . . . . . . . 24 5. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.1. Action AVP . . . . . . . . . . . . . . . . . . . . . . . . 24 5.2. Diameter QoS Defined AVPs . . . . . . . . . . . . . . . . 25 5.2.1. QoS-Profile-Id AVP . . . . . . . . . . . . . . . . . . 25 5.2.2. QoS-Profile-Template AVP . . . . . . . . . . . . . . . 25 5.2.3. QoS-Semantics . . . . . . . . . . . . . . . . . . . . 26 5.2.4. QoS-Parameters AVP . . . . . . . . . . . . . . . . . . 27 5.2.5. Rule-Precedence AVP . . . . . . . . . . . . . . . . . 27 5.2.6. Excess-Treatment AVP . . . . . . . . . . . . . . . . . 28 5.2.7. Excess-Treatment-Action . . . . . . . . . . . . . . . 28 Korhonen, et al. Expires June 21, 2009 [Page 2] Internet-Draft QoS Attributes for Diameter December 2008 6. QoS Capability Indication . . . . . . . . . . . . . . . . . . 29 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.1. Diameter EAP with QoS Information . . . . . . . . . . . . 30 7.2. Diameter NASREQ with QoS Information . . . . . . . . . . . 31 7.3. QoS Authorization . . . . . . . . . . . . . . . . . . . . 32 7.4. Diameter Server Initiated Re-authorization of QoS . . . . 33 7.5. Diameter Credit Control with QoS Information . . . . . . . 34 7.6. Classifier Examples . . . . . . . . . . . . . . . . . . . 35 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 36 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 11. Security Considerations . . . . . . . . . . . . . . . . . . . 39 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 12.1. Normative References . . . . . . . . . . . . . . . . . . . 39 12.2. Informative References . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 Korhonen, et al. Expires June 21, 2009 [Page 3] Internet-Draft QoS Attributes for Diameter December 2008 1. Introduction This document defines a number of Diameter Quality of Service (QoS) related AVPs that can be used in existing and future Diameter applications where permitted by the command ABNF. The Rule AVP thereby replaces the IPFilterRule AVP, defined in RFC 3588 [RFC3588], and the QoS-Filter-Rule AVP, defined in RFC 4005 [RFC4005]. [Victor: Can we deprecate IPFilterRule AVP in 3588bis ?, i.e. leave the definition in bis but declare it as deprecated] The structure of a rule in the entire rule set defined in this document consist of a conditions part and corresponding actions. The AVPs responsible for expressing a condition are defined in Section 4. Capabilities to match all or a subset of the data traffic is provided. Additionally, time-based conditions can be expressed based on the functionality offered in Section 4.2. The action part of a rule contains information for handling conflict resolution, such as a priority value for each individual rule within a rule set, and further description regarding QoS related actions. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Rule Sets and Rules As mentioned in the introduction the top-level element is the Rule- Set AVP that encapsulates one or more Rule AVPs. 3.1. Rule-Set AVP The Rule-Set AVP (AVP Code TBD) is of type Grouped and describes a list of policies.. Rule-Set ::= < AVP Header: XXX > 1*{ Rule } * [ AVP ] 3.2. Rule AVP TheRule AVP (AVP Code TBD) is of type Grouped and defines a specific [Victor: /TheRule/The Rule/] condition and action combination. The QoS related actions defined in this document therefore one or more traffic flows together with a set of QoS parameters that should be applied to the flow(s) by the Resource Management Function. [Victor: I had trouble deciphering the last sentence :) ... can we rephrase this ?] Korhonen, et al. Expires June 21, 2009 [Page 4] Internet-Draft QoS Attributes for Diameter December 2008 Rule ::= < AVP Header: XXX > ; Condition part of a Rule ; ------------------------ [ Classifier ] * [ Time-Of-Day-Condition ] ; Action and Meta-Data ; -------------------- [ Action ] [ Rule-Precedence ] ; Info about QoS related Actions ; ------------------------------ [ QoS-Semantics ] [ QoS-Profile-Template ] [ QoS-Parameters ] [ Excess-Treatment ] ; Extension Point ; --------------- * [ AVP ] If the QoS-Profile-Template AVP is not included in the Rule AVP then the default setting is assumed, namely a setting of the Vendor-Id AVP to 0 (for IETF) and the QoS-Profile-Id AVP to zero (0) (for the profile defined in [I-D.ietf-dime-qos-parameters]). Note that the content of the QoS-Parameters are defined in the respective specification defining the QoS parameters. When the Vendor-Id AVP is set to 0 (for IETF) and the QoS-Profile-Id AVP is set to zero (0) then the AVPs included in the QoS-Parameters AVP are the AVPs defined in [I-D.ietf-dime-qos-parameters]. [Victor: A couple of notes based on last conf call: * I'm in favor of keeping a list of rule-set flat, i.e. no JUMP TO ANOTHER CLASSIFER action. Extension docs can probably do those kind of things. * I understand that the 'mark' action is very useful but we have to make it clear that further actions for marked packets maybe application or deployment specific are not defined in this document] 4. Conditions This section describe the condition part of a rule. 4.1. Traffic Classifiers Classifiers are used in many applications to specify how to select a subset of data packets for subsequent treatment as indicated in the action part of a rule. For example in a QoS application, if a packet matches a classifier then that packet will be treated in accordance Korhonen, et al. Expires June 21, 2009 [Page 5] Internet-Draft QoS Attributes for Diameter December 2008 with a QoS specification associated with that classifier. Figure 1 shows a typical deployment. +-----------+ +-----------+| +--------+ +-------------+ +------------+|| | | IN | | | ||| | +--------->| +------------->| ||| |Managed | | Classifying | | Unmanaged ||| |Terminal| OUT | Entity | | Terminal ||| | |<---------+ |<-------------+ ||+ | | | | | |+ +--------+ +-------------+ +------------+ ^ | Classifiers | +------+------+ | | | AAA | | | +-------------+ Figure 1: Example of a Classifier Architecture The managed terminal, the terminal for which the classifiers are being specified is located on the left of the Classifying Entity. The unmanaged terminal, the terminal that receives packets from the Managed terminal or sends packets to the managed terminal is located to the right side of the Classifying Entity. The Classifying Entity is responsible for classifying packets that are incoming (IN) from the Managed Terminal or packets outgoing (OUT) to the Managed Terminal. A Classifier consists of a group of attributes that specify how to match a packet. Each set of attributes expresses values about aspects of the packet - typically the packet header. Different protocols therefore would use different attributes. In general a Classifier consists of the following: Identifier: The identifier uniquely identifies this classifier and may be used to reference the classifier from another structure. Korhonen, et al. Expires June 21, 2009 [Page 6] Internet-Draft QoS Attributes for Diameter December 2008 From: Specifies the rule for matching the source part of the packet. [Victor: /source/protocol specific source address/s] To: Specifies the rule for matching the destination part of the packet. [Victor: /destination/protocol specific destination address/s] Protocol: Specifies the matching protocol of the packet. Direction: Specifies whether the classifier is to apply to packets flowing from the Managed Terminal (IN) or to packets flowing to the Managed Terminal (OUT), or packets flowing in both direction. Options: Associated with each protocol or layer, or various values specific [Victor: /Associated/Attributes or properties associated/s] to the header of the protocol or layer. Options allow matching on those values. Each protocol type will have a specific set of attributes that can be used to specify a classifier for that protocol. These attributes will be grouped under a grouped AVP called a Classifier AVP. 4.1.1. Classifier AVP The Classifier AVP (AVP Code TBD) is a grouped AVP that consists of a set of attributes that specify how to match a packet. Korhonen, et al. Expires June 21, 2009 [Page 7] Internet-Draft QoS Attributes for Diameter December 2008 Classifier ::= < AVP Header: XXX > { Classifier-ID } { Protocol } { Direction } * [ From-Spec ] * [ To-Spec ] * [ Diffserv-Code-Point ] [ Fragmentation-Flag ] * [ IP-Option ] * [ TCP-Option ] [ TCP-Flags ] * [ ICMP-Type ] * [ ETH-Option ] * [ AVP ] 4.1.2. Classifier-ID AVP The Classifier-ID AVP (AVP Code TBD) is of type OctetString and uniquely identifies the classifier. Each application will define the uniqueness scope of this identifier, e.g. unique per terminal or globally unique. [Victor: What does 'globally unique' mean ? Does it mean globally unique within the context of the application ? If so, would it be better to say: unique within app AND terminal, app AND admin domain, ...] Exactly one Classifier-ID AVP MUST be contained within a Classifier AVP. 4.1.3. Protocol AVP The Protocol AVP (AVP Code TBD) is of type Enumerated and specifies the protocol being matched. The attributes included in the Classifier AVP must be consistent with the value of the Protocol AVP. [Victor: /must/MUST/s ???] Exactly one Protocol AVP MUST be contained within a Classifier AVP. The values for this AVP are managed by IANA under the Protocol Numbers registry [PROTOCOL]. 4.1.4. Direction AVP The Direction AVP (AVP Code TBD) is of type Enumerated that specifies in which direction to apply the Classifier. The values of the enumeration are: "IN","OUT","BOTH". In the "IN" and "BOTH" directions, the From-Spec refers to the address of the Managed Terminal and the To-Spec refers to the unmanaged terminal. In the "OUT" direction, the From-Spec refers to the Unmanaged Terminal whereas the To-Spec refers to the Managed Terminal. Korhonen, et al. Expires June 21, 2009 [Page 8] Internet-Draft QoS Attributes for Diameter December 2008 Value | Name and Semantic ------+-------------------------------------------------- 0 | RESERVED [Victor: Why do we need RESERVED ???] 1 | IN - The classifier applies to flows from the | Managed Terminal. 2 | OUT - The classifier applies to flows to the | Managed Terminal. 3 | BOTH - The classifier applies to flows both to | and from the Managed Terminal. 4.1.5. From-Spec AVP The From-Spec AVP (AVP Code TBD) is a grouped AVP that specifies the Source Specification used to match the packet. Zero or more of these AVPs may appear in the Classifier. If this AVP is absent from the Classifier then all packets are matched regardless of the source address. If more than one instance of this AVP appears in the [Victor: /more than one/one or more/s] Classifier then the source of the packet can match any From-Spec AVP. [Victor: /source/source address/s] The contents of this AVP are protocol specific. If more than one instance of the IP address AVPs (IP-Address, IP- [Victor: /more than one/one or more/s] Address-Range, IP-Address-Mask, Use-Assigned-Address) appear in the From-Spec AVP then the source IP address of the packet must match one [Victor: /must/MUST/s ???] of the addresses represented by these AVPs. If more that one instance of the layer 2 address AVPs (MAC-Address, [Victor: /more than one/one or more/s] MAC-Address-Mask, EUI64-Address, EUI64-Address-Mask) appears in the From-Spec then the the source layer 2 address of the packet must [Victor: /must/MUST/s ???] match one of the addresses represented in these AVPs. If more that one instance of the port AVPs (Port, Port-Range) appears [Victor: /more than one/one or more/s] in the From-Spec AVP then the source port number must match one of [Victor: /must/MUST/s ???] the port numbers represented in these AVPs. If the IP address, MAC address and port AVPs appear in the same From- Spec AVP then the source packet must match all the specifications, [Victor: /must/MUST/s ???] i.e. match the IP address AND MAC address AND port number. Korhonen, et al. Expires June 21, 2009 [Page 9] Internet-Draft QoS Attributes for Diameter December 2008 From-Spec ::= < AVP Header: XXX > * [ IP-Address ] * [ IP-Address-Range ] * [ IP-Address-Mask ] * [ MAC-Address ] * [ MAC-Address-Mask] * [ EUI64-Address ] * [ EUI64-Address-Mask] * [ Port ] * [ Port-Range ] [ Negated ] [ Use-Assigned-Address ] * [ AVP ] [Victor: It seems everything is optional ... what happens if this is empty ? same for To-Spec] 4.1.6. To-Spec AVP The To-Spec AVP (AVP Code TBD) is a grouped AVP that specifies the Destination Specification used to match the packet. Zero or more of these AVPs may appear in the Classifier. If this AVP is absent from the Classifier then all packets are matched regardless of the destination address. If more than one instance of this AVP appears [Victor: /more than one/one or more/s] in the Classifier then the destination of the packet can match any To-Spec AVP. The contents of this AVP are protocol specific. If more than one instance of the IP address AVPs (IP-Address, IP- [Victor: /more than one/one or more/s] Address-Range, IP-Address-Mask, Use-Assigned-Address) appear in the To-Spec AVP then the destination IP address of the packet must match [Victor: /must/MUST/s ???] one of the addresses represented by these AVPs. If more that one instance of the layer 2 address AVPs (MAC-Address, [Victor: /more than one/one or more/s] MAC-Address-Mask, EUI64-Address, EUI64-Address-Mask) appears in the To-Spec then the the destination layer 2 address of the packet must [Victor: /must/MUST/s ???] match one of the addresses represented in these AVPs. If more that one instance of the port AVPs (Port, Port-Range) appears [Victor: /more than one/one or more/s] in the To-Spec AVP then the destination port number must match one of [Victor: /must/MUST/s ???] the port numbers represented in these AVPs. If the IP address, MAC address and port AVPs appear in the same To- Spec AVP then the destination packet must match all the specifications, i.e. match the IP address AND MAC address AND port number. Korhonen, et al. Expires June 21, 2009 [Page 10] Internet-Draft QoS Attributes for Diameter December 2008 To-Spec ::= < AVP Header: XXX > * [ IP-Address ] * [ IP-Address-Range ] * [ IP-Address-Mask ] * [ MAC-Address ] * [ MAC-Address-Mask] * [ EUI64-Address ] * [ EUI64-Address-Mask] * [ Port ] * [ Port-Range ] [ Negated ] [ Use-Assigned-Address ] * [ AVP ] 4.1.7. Source and Destination AVPs For packet classification the contents of the From-Spec and To-Spec can contain the following AVPs. [Victor: what AVPs ?] By combining several of these AVPs within a From-Spec or To-Spec AVP and using more than one From-Spec or To-Spec AVP in the Classifier AVP, one can express many different types of address pools. [Victor: I must admit, I cannot understand what this section is implying :). Is it attempting to say that a match must be From-Spec AND To-Spec if both are present ? or some other combination ?] 4.1.7.1. Negated AVP The Negated AVP (AVP Code TBD) of type Enumerated containing the values of True or False. Exactly zero or one of these AVPs may appear in the From-Spec or To-Spec AVP. When set to True the meaning of the match in the To-Spec and From-Spec are negated, causing all other addresses to be matched instead. [Victor: Re-phrase last sentence to: "When set to True the meaning of the match is inverted. Addresses other than those in the To-Spec and From-Spec are to be matched instead."] When set to False, or when the AVP is not included in the From-Spec or To-Spec AVP then the meaning of the match is not inverted, causing only the addresses specified to be matched. [Victor: Re-phrase: "When set to False, or when the AVP is not included then the address specified To-Spec and From-Spec AVP are to be matched."] Note that the negation does not impact the port comparisons. Value | Name ------+-------- 0 | False 1 | True 4.1.7.2. IP-Address AVP The IP-Address AVP (AVP Code TBD) is of type Address and specifies a single IP address (IPv4 or IPv6) address to match. Korhonen, et al. Expires June 21, 2009 [Page 11] Internet-Draft QoS Attributes for Diameter December 2008 4.1.7.3. IP-Address-Range AVP The IP-Address-Range AVP (AVP Code TBD) is of type Grouped and specifies an inclusive IP address range. IP-Address-Range ::= < AVP Header: XXX > [ IP-Address-Start ] [ IP-Address-End ] * [ AVP ] If the IP-Address-Start AVP is not included then the address range starts from the first valid IP address up to and including the specified IP-Address-End address. If the IP-Address-End AVP is not included then the address range starts at the address specified by the IP-Address-Start AVP and includes all the remaining valid IP addresses. For the IP-Address-Range AVP to be valid, the IP-Address-Start AVP MUST contain a value that is less than that of the IP-Address-End AVP. [Victor: Should at least one of these AVP be present in at any given time ? If not, what is the semantics ?] 4.1.7.4. IP-Address-Start AVP The IP-Address-Start AVP (AVP Code TBD) is of type Address and specifies the first IP address (IPv4 or IPv6) address of an IP address range. 4.1.7.5. IP-Address-End AVP The IP-Address-End AVP (AVP Code TBD) is of type Address and specifies the last IP address (IPv4 or IPv6) address of an address range. 4.1.7.6. IP-Address-Mask AVP The IP-Address-Mask AVP (AVP Code TBD) is of type Grouped and specifies an IP address range using a base IP address and the bit- width of the mask. For example, a range expressed as 1.2.3.0/24 will match all IP addresses from 1.2.3.0 up to and including 1.2.3.255. The bit-width MUST be valid for the type of IP address. IP-Address-Mask ::= < AVP Header: XXX > { IP-Address } { IP-Bit-Mask-Width } * [ AVP ] Korhonen, et al. Expires June 21, 2009 [Page 12] Internet-Draft QoS Attributes for Diameter December 2008 4.1.7.7. IP-Mask-Bit-Mask-Width AVP The IP-Bit-Mask-Width AVP (AVP Code TBD) is of type OctetString. The value is a single octet and specifies the width of an IP address bit- mask. 4.1.7.8. MAC-Address AVP The MAC-Address AVP (AVP Code TBD) is of type OctetString and specifies a single layer 2 address in MAC-48 format. The value is a 6 octets encoding of the address as it would appear in the frame header. 4.1.7.9. MAC-Address-Mask AVP The MAC-Address-Mask AVP (AVP Code TBD) is of type Grouped and specifies a set of MAC addresses using a bit mask to indicate the bits of the MAC addresses which must fit to the specified MAC address attribute. For example, a MAC-Address-Mask with the MAC-Address as 00-10-A4-23-00-00 and with a MAC-Address-Mask-Pattern of FF-FF-FF-FF- 00-00 will match all MAC addresses from 00-10-A4-23-00-00 up to and including 00-10-A4-23-FF-FF. [Victor: Is MAC-Address-Mask-Pattern a bitmask or bitwidth ? The example suggest a bit-width / range but 4.1.7.10 says bit positions which seems does not imply range, i.e.: I can have a bit-mask of FF-FF-00-00-FF-FF for example] MAC-Address-Mask ::= < AVP Header: XXX > { MAC-Address } { MAC-Address-Mask-Pattern } * [ AVP ] 4.1.7.10. MAC-Address-Mask-Pattern AVP The MAC-Address-Mask-Pattern AVP (AVP Code TBD) is of type OctetString. The value is a 6 octets specifying the bit positions of a MAC address, that are taken for matching. 4.1.7.11. EUI64-Address AVP The EUI64-Address AVP (AVP Code TBD) is of type OctetString and specifies a single layer 2 address in EUI-64 format. The value is a 8 octets encoding of the address as it would appear in the frame header. 4.1.7.12. EUI64-Address-Mask AVP The EUI64-Address-Mask AVP (AVP Code TBD) is of type Grouped and specifies a set of EUI64 addresses using a bit mask to indicate the bits of the EUI64 addresses which must fit to the specified EUI64 address attribute. For example, a EUI64-Address-Mask with the EUI64- Address as 00-10-A4-FF-FE-23-00-00 and with a EUI64-Address-Mask- Korhonen, et al. Expires June 21, 2009 [Page 13] Internet-Draft QoS Attributes for Diameter December 2008 Pattern of FF-FF-FF-FF-FF-FF-00-00 will match all EUI64 addresses from 00-10-A4-FF-FE-23-00-00 up to and including 00-10-A4-FF-FE-23- FF-FF. [Victor: same comment as 4.1.7.9] EUI64-Address-Mask ::= < AVP Header: XXX > { EUI64-Address } { EUI64-Address-Mask-Pattern } * [ AVP ] 4.1.7.13. EUI64-Address-Mask-Pattern AVP The EUI64-Address-Mask-Pattern AVP (AVP Code TBD) is of type OctetString. The value is a 8 octets specifying the bit positions of a EUI64 address, that are taken for matching. 4.1.7.14. Port AVP The Port AVP (AVP Code TBD) is of type Integer32 in the range of 0 to 65535 and specifies the TCP or UDP port number to match. [Victor: This is the first time TCP and UDP is mentioned, all of the above text implies a sort of protocol generality. Should it be the same here ? i.e. I can have SCTP ports also] 4.1.7.15. Port-Range AVP The Port-Range AVP (AVP Code TBD) is of type Grouped and specifies an inclusive range of ports. Port-Range ::= < AVP Header: XXX > [ Port-Start ] [ Port-End ] * [ AVP ] If the Port-Start AVP is omitted then port 0 is assumed. If the Port-End AVP is omitted then port 65535 is assumed. [Victor: Do we make sure at least one of these AVPs are present ?] 4.1.7.16. Port-Start AVP The Port-Start AVP (AVP Code TBD) is of type Integer32 and specifies the first port number of an IP port range. 4.1.7.17. Port-End AVP The Port-End AVP (AVP Code TBD) is of type Integer32 and specifies the last port number of an IP port range. 4.1.7.18. Use-Assigned-Address AVP In some scenarios, the AAA does not know the IP address assigned to the Managed Terminal at the time that the Classifier is sent to the Korhonen, et al. Expires June 21, 2009 [Page 14] Internet-Draft QoS Attributes for Diameter December 2008 Classifying Entity. The Use-Assigned-Address AVP (AVP Code TBD) is of type Enumerated containing the values of True or False. When present and set to True, it represents the IP address assigned to the Managed Terminal. Value | Name ------+-------- 0 | False 1 | True [Victor: Are we talking the classifying entity dynamically adding the managed terminals IP into this classifier entry ?, i.e. everytime a new terminal sends packets then a new entry is added with a new From-Spec ? If so, would'nt this be equivalent to a missing From-Spec for IN in the Classifier ?] 4.1.8. Header Option AVPs The Classifier AVP may contain one or more of the following AVPs to match on the various possible IP, TCP or ICMP header options. 4.1.8.1. Diffserv-Code-Point AVP The Diffserv-Code-Point AVP (AVP Code TBD) is of type Enumerated and specifies the Differentiated Services Field Codepoints to match in the IP header. The values are managed by IANA under the Differentiated Services Field Codepoints registry [DSCP]. 4.1.8.2. Fragmentation-Flag AVP The Fragmentation-Flag AVP (AVP Code TBD) is of type Enumerated and specifies the packet fragmentation flags to match in the IP header. Value | Name and Semantic ------+------------------------------------------------------------ 0 | RESERVED [Victor: Why do we need reserved ? Are we checking whether the fragmentation reserved flag in the IP header matches ? ] 1 | Don't Fragment (DF) 2 | More Fragments (MF) 4.1.8.3. IP-Option AVP The IP-Option AVP (AVP Code TBD) is of type Grouped and specifies an IP header option that must be matched. IP-Option ::= < AVP Header: XXX > { IP-Option-Type } * [ IP-Option-Value ] [ Negated ] * [ AVP ] If one or more IP-Option-Value AVPs are present, one of the values Korhonen, et al. Expires June 21, 2009 [Page 15] Internet-Draft QoS Attributes for Diameter December 2008 MUST match the value in the IP header option. If the IP-Option-Value AVP is absent, the option type MUST be present in the IP header but the value is wild carded. The Negated AVP is used in conjunction with the IP-Option-Value AVPs to specify IP header options which do not match specific values. The Negated AVP is used without the IP-Option-Value AVP to specify IP headers which do not contain the option type. 4.1.8.4. IP-Option-Type AVP The IP-Option-Type AVP (AVP Code TBD) is of type Enumerated and the values are managed by IANA under the IP Option Numbers registry [IPOPTIONS]. 4.1.8.5. IP-Option-Value AVP The IP-Option-Value AVP (AVP Code TBD) is of type OctetString and contains the option value that must be matched. 4.1.8.6. TCP-Option AVP The TCP-Option AVP (AVP Code TBD) is of type Grouped and specifies a TCP header option that must be matched. TCP-Option ::= < AVP Header: XXX > { TCP-Option-Type } * [ TCP-Option-Value ] [ Negated ] * [ AVP ] If one or more TCP-Option-Value AVPs are present, one of the values MUST match the value in the TCP header option. If the TCP-Option- Value AVP is absent, the option type MUST be present in the TCP header but the value is wild carded. The Negated AVP is used in conjunction which the TCP-Option-Value AVPs to specify TCP header options which do not match specific values. The Negated AVP is used without the TCP-Option-Value AVP to specify TCP headers which do not contain the option type. 4.1.8.7. TCP-Option-Type AVP The TCP-Option-Type AVP (AVP Code TBD) is of type Enumerated and the values are managed by IANA under the TCP Option Numbers registry [TCPOPTIONS]. Korhonen, et al. Expires June 21, 2009 [Page 16] Internet-Draft QoS Attributes for Diameter December 2008 4.1.8.8. TCP-Option-Value AVP The TCP-Option-Value AVP (AVP Code TBD) is of type OctetString and contains the option value that must be matched. 4.1.8.9. TCP-Flags AVP The TCP-Flags AVP (AVP Code TBD) is of type Grouped and specifies a set of TCP control flags that must be matched. TCP-Flags ::= < AVP Header: XXX > 1* { TCP-Flag-Type } [ Negated ] * [ AVP ] If the Negated AVP is not present, the TCP-Flag-Type AVPs specifies [Victor: /not present/not present or present but set to False/s] which flags MUST be set. If the Negated AVP is present, the TCP- [Victor: /present/set to True/s] Flag-Type AVPs specifies which flags MUST be cleared. 4.1.8.10. TCP-Flag-Type AVP The TCP-Flag-Type AVP (AVP Code TBD) is of type Enumerated and specifies a TCP control flag type that must be matched. Value | Name and Semantic ------+------------------------------------------------------------ 0 | RESERVED [Victor: same comment as in 4.1.8.2] 1 | CWR - Congestion Window Reduced. 2 | ECE - ECN-Echo. TCP peer is ECN capable. 3 | URG - URGent pointer field is significant. 4 | ACK - ACKnowledgment field is significant. 5 | PSH - Push function. 6 | RST - Reset the connection. 7 | SYN - Synchronize sequence numbers. 8 | FIN - No more data from sender. 4.1.8.11. ICMP-Type The ICMP-Type AVP (AVP Code TBD) is of type Grouped and specifies a ICMP message type that must be matched. ICMP-Type ::= < AVP Header: XXX > { ICMP-Type-Number } * [ ICMP-Code ] [ Negated ] Korhonen, et al. Expires June 21, 2009 [Page 17] Internet-Draft QoS Attributes for Diameter December 2008 * [ AVP ] If the ICMP-Code AVP is present, the value MUST match that in the ICMP header. If the ICMP-Code AVP is absent, the ICMP type MUST be present in the ICMP header but the code is wild carded. The Negated AVP is used in conjunction which the ICMP-Code AVPs to specify ICMP codes which do not match specific values. The Negated AVP is used without the ICMP-Code AVP to specify ICMP headers which do not contain the ICMP type. [Victor: Is this the intent of the last sentence ? : "The Negated AVP feature applies to ICMP-Code AVP if it is present. If absent, the Negated AVP feature applies to ICMP-Type-Number"] 4.1.8.12. ICMP-Type-Number AVP The ICMP-Type-Number AVP (AVP Code TBD) is of type Enumerated and the values are managed by IANA under the ICMP Type Numbers registry [ICMPTYPE]. 4.1.8.13. ICMP-Code AVP The ICMP-Code AVP (AVP Code TBD) is of type Enumerated and the values are managed by IANA under the ICMP Type Numbers registry [ICMPTYPE]. 4.1.8.14. ETH-Option AVP The ETH-Option AVP (AVP Code TBD) is of type Grouped and specifies Ethernet specific attributes. ETH-Option ::= < AVP Header: XXX > { ETH-Proto-Type } * [ VLAN-ID-Range ] * [ ETH-Priority-Range ] * [ AVP ] 4.1.8.15. ETH-Proto-Type AVP The Eth-Proto-Type AVP (AVP Code TBD) is of type Grouped and specifies the encapsulated protocol type. ETH-Ether-Type and ETH-SAP are mutually exclusive. ETH-Proto-Type ::= < AVP Header: XXX > * [ ETH-Ether-Type ] * [ ETH-SAP ] * [ AVP ] Korhonen, et al. Expires June 21, 2009 [Page 18] Internet-Draft QoS Attributes for Diameter December 2008 4.1.8.16. ETH-Ether-Type AVP The ETH-Ether-Type AVP (AVP Code TBD) is of type OctetString. The value is a double octet the contains the value of the Ethertype field in the packet to match. This AVP MAY be present in the case of DIX or if SNAP is present at 802.2 but the ETH-SAP AVP MUST NOT be present in this case. 4.1.8.17. ETH-SAP AVP The ETH-SAP AVP (AVP Code TBD) is of type OctetString. The value is a double octet representing the 802.2 SAP as specified in [IEEE802.2]. The first octet contains the DSAP and the second the SSAP. 4.1.8.18. VLAN-ID-Range AVP The VLAN-ID-Range AVP (AVP Code TBD) is of type Grouped and specifies the VLAN range to match. VLAN identities are either specified by a single VLAN-ID according to [IEEE802.1Q] or by a combination of Customer and Service VLAN-IDs according to [IEEE802.1ad]. The single VLAN-ID is represented by the C-VID-Start and C-VID-End AVPs and the S-VID-Start and S-VID-End AVPs SHALL be ommitted in this case. [Victor: What is being omitted ?] If the VLAN-ID-Range AVP is omitted from the Classifier, then comparison of the VLAN identity of the packet is irrelevant. VLAN-ID-Range ::= < AVP Header: XXX > [ S-VID-Start ] [ S-VID-End ] [ C-VID-Start ] [ C-VID-End ] * [ AVP ] When the S-VID-Start AVP is present but the S-VID-End AVP is absent, the S-VID-Start AVP value MUST equal the value of the IEEE 802.1ad S-VID bits specified in [IEEE802.1ad] for a successful match. [Victor: Is this new sematic necessary ? The other range features does not have this semantic. They use only start and end. If an exact match is needed then they use start == end] When both S-VID-Start and S-VID-End AVPs are present, the value of the IEEE 802.1ad S-VID bits MUST be greater than or equal to the S-VID- Start AVP value and less than or equal to the S-VID-End AVP value for a successful match. If the S-VID-Start and S-VID-End AVPs are omitted, then existence of IEEE802.1ad encapsulation or comparison of the IEEE 802.1ad S-VID bits is irrelevamt for this Classifier. If the S-VID-Start and S-VID-End AVPs are specified, then Ethernet packets without IEEE 802.1ad encapsulation MUST NOT match this Classifier. Korhonen, et al. Expires June 21, 2009 [Page 19] Internet-Draft QoS Attributes for Diameter December 2008 When the C-VID-Start AVP is present but the C-VID-End AVP is absent, the C-VID-Start AVP value MUST equal the value of the IEEE 802.1ad C-VID bits specified in [IEEE802.1ad] or the IEEE 802.1Q VLAN-ID bits specified in [IEEE802.1Q] for a successful match. [Victor: same comment as above] When both C-VID- Start and C-VID-End AVPs are present, the value of the IEEE 802.1ad C-VID bits or the IEEE 802.1Q VLAN-ID bits MUST be greater than or equal to the C-VID-Start AVP value and less than or equal to the C-VID-End AVP value for a successful match. If the C-VID-Start and C-VID-End AVPs are omitted, then comparison of the IEEE 802.1ad C-VID bits or IEEE 802.1Q VLAN-ID bits for this Classifier is irrelevant. If the C-VID-Start and C-VID-End AVPs are specified, then Ethernet packets without IEEE 802.1ad or IEEE 802.1Q encapsulation MUST NOT match this Classifier. 4.1.8.19. S-VID-Start AVP The S-VID-Start AVP (AVP Code TBD) is of type Unsigned32. The value MUST be in the range from 0 to 4095. The value of this AVP specifies the start value of the range of S-VID VLAN-IDs to be matched. 4.1.8.20. S-VID-End AVP The S-VID-End AVP (AVP Code TBD) is of type Unsigned32. The value MUST be in the range from 0 to 4095. The value of this AVP specifies the end value of the range of S-VID VLAN-IDs to be matched. 4.1.8.21. C-VID-Start AVP The C-VID-Start AVP (AVP Code TBD) is of type Unsigned32. The value MUST be in the range from 0 to 4095. The value of this AVP specifies the start value of the range of C-VID VLAN-IDs to be matched. 4.1.8.22. C-VID-End AVP The C-VID-End AVP (AVP Code TBD) is of type Unsigned32. The value MUST be in the range from 0 to 4095. The value of this AVP specifies the end value of the range of C-VID VLAN-IDs to be matched. 4.1.8.23. ETH-Priority-Range AVP The ETH-Priority-Range AVP (AVP Code TBD) is of type Grouped and specifies an inclusive range to match the user_priority parameter specified in [IEEE802.1D]. An Ethernet packet containing the user_priority parameter matches this Classifier if the value is greater than or equal to ETH-Low-Priority and less than or equal to ETH-High-Priority. If this AVP is omitted, then comparison of the IEEE 802.1D user_priority parameter for this Classifier is irrelevant. Korhonen, et al. Expires June 21, 2009 [Page 20] Internet-Draft QoS Attributes for Diameter December 2008 ETH-Priority-Range ::= < AVP Header: XXX > * [ ETH-Low-Priority ] * [ ETH-High-Priority ] * [ AVP ] 4.1.8.24. ETH-Low-Priority AVP The ETH-Low-Priority AVP (AVP Code TBD) is of type Unsigned32. The value MUST be in the range from 0 to 7. 4.1.8.25. ETH-High-Priority AVP The ETH-High-Priority AVP (AVP Code TBD) is of type Unsigned32. The value MUST be in the range from 0 to 7. 4.2. Time Of Day AVPs In many QoS applications, the QoS specification applied to the traffic flow is conditional upon the time of day when the flow was observed. The following sections define AVPs that can be used to express one or more time windows which determine when a QoS specification is applicable to a traffic flow. 4.2.1. Time-Of-Day-Condition AVP The Time-Of-Day-Condition AVP (AVP Code TBD) is of type Grouped and specifies one or more time windows. Time-Of-Day-Condition ::= < AVP Header: XXX > [ Time-Of-Day-Start ] [ Time-Of-Day-End ] [ Day-Of-Week-Mask ] [ Day-Of-Month-Mask ] [ Month-Of-Year-Mask ] [ Absolute-Start-Time ] [ Absolute-End-Time ] [ Timezone-Flag ] * [ AVP ] [Victor: We should mention that if most of the AVPs above are present, their evaluation criteria or values are allowed to overlap] If more than one instance of this AVP is present in the Rule AVP, the current time at QoS rule evaluation MUST be within at least one of the time windows specified in one of the Time-Of-Day-Condition AVPs. When the Time-Of-Day-Condition AVP and Classifier AVP are present in the same Rule AVP, both the time of day and packet classification conditions MUST match for the QoS specification to be applied. Korhonen, et al. Expires June 21, 2009 [Page 21] Internet-Draft QoS Attributes for Diameter December 2008 For example, a time window for 9am to 5pm (local time) from Monday to Friday would be expressed as: Time-Of-Day-Condition = { Time-Of-Day-Start = 32400; Time-Of-Day-End = 61200; Day-Of-Week-Mask = ( MONDAY | TUESDAY | WEDNESDAY | THURSDAY | FRIDAY ); Timezone-Flag = LOCAL; } 4.2.2. Time-Of-Day-Start AVP The Time-Of-Day-Start AVP (AVP Code TBD) is of type Unsigned32. The value MUST be in the range from 0 to 86400. The value of this AVP specifies the start of an inclusive time window expressed as the offset in seconds from midnight. If this AVP is absent from the Time-Of-Day-Condition AVP, the time window starts at midnight. 4.2.3. Time-Of-Day-End AVP The Time-Of-Day-End AVP (AVP Code TBD) is of type Unsigned32. The value MUST be in the range from 1 to 86400. The value of this AVP specifies the end of an inclusive time window expressed as the offset in seconds from midnight. If this AVP is absent from the Time-Of- Day-Condition AVP, the time window ends one second before midnight. 4.2.4. Day-Of-Week-Mask AVP The Day-Of-Week-Mask AVP (AVP Code TBD) is of type Unsigned32. The value is a bitmask which specifies the day of the week for the time window to match. This document specifies the following bits: Bit | Name ------+------------ 0 | SUNDAY 1 | MONDAY 2 | TUESDAY 3 | WEDNESDAY 4 | THURSDAY 5 | FRIDAY 6 | SATURDAY The bit MUST be set for the time window to match on the corresponding day of the week. Bit 0 is the most significant bit and unused bits MUST be cleared. If this AVP is absent from the Time-Of-Day- Condition AVP, the time windows match on all days of the week. Korhonen, et al. Expires June 21, 2009 [Page 22] Internet-Draft QoS Attributes for Diameter December 2008 4.2.5. Day-Of-Month-Mask AVP The Day-Of-Week-Month AVP (AVP Code TBD) is of type Unsigned32. The value MUST be in the range from 0 to 2147483647. The value is a bitmask which specifies the days of the month where bit 0 represents the first day of the month through to bit 30 which represents the last day of the month. The bit MUST be set for the time window to match on the corresponding day of the month. Bit 0 is the most significant bit and unused bits MUST be cleared. If this AVP is absent from the Time-Of-Day-Condition AVP, the time windows match on all days of the month. 4.2.6. Month-Of-Year-Mask AVP The Month-Of-Year-Month AVP (AVP Code TBD) is of type Unsigned32. The value is a bitmask which specifies the months of the year for the time window to match. This document specifies the following bits: Bit | Name ------+----------- 0 | JANUARY 1 | FEBRUARY 2 | MARCH 3 | APRIL 4 | MAY 5 | JUNE 6 | JULY 7 | AUGUST 8 | SEPTEMBER 9 | OCTOBER 10 | NOVEMBER 11 | DECEMBER The bit MUST be set for the time window to match on the corresponding month of the year. Bit 0 is the most significant bit and unused bits MUST be cleared. If this AVP is absent from the Time-Of-Day- Condition AVP, the time windows match during all months of the year. 4.2.7. Absolute-Start-Time AVP The Absolute-Start-Time AVP (AVP Code TBD) is of type Time. The value of this AVP specifies the time in seconds since January 1, 1900, 00:00 UTC when the time window starts. If this AVP is absent from the Time-Of-Day-Condition AVP, the time window starts on January 1, 1900, 00:00 UTC. Korhonen, et al. Expires June 21, 2009 [Page 23] Internet-Draft QoS Attributes for Diameter December 2008 4.2.8. Absolute-End-Time AVP The Time-Of-Day-End AVP (AVP Code TBD) is of type Time. The value of this AVP specifies the time in seconds since January 1, 1900, 00:00 UTC when the time window ends. If this AVP is absent from the Time- Of-Day-Condition AVP, the time window is open-ended. 4.2.9. Timezone-Flag AVP The Timezone-Flag AVP (AVP Code TBD) is of type Enumerated and indicates whether the time windows are specified in UTC, local time at the managed terminal or as an offset from UTC. If this AVP is absent from the Time-Of-Day-Condition AVP, the time windows are in UTC. This document defines the following values: Value | Name and Semantic ------+-------------------------------------------------- 0 | RESERVED [Victor: If the value was set to RESERVED then what does it mean ? How do we classify ?] 1 | UTC - The time windows are expressed in UTC. 2 | LOCAL - The time windows are expressed in local | time at the Managed Terminal. 3 | OFFSET - The time windows are expressed as an | offset from UTC (see Timezone-Offset AVP). 4.2.10. Timezone-Offset AVP The Timezone-Offset AVP (AVP Code TBD) is of type Integer32. The value of this AVP MUST be in the range from -43200 to 43200. It specifies the offset in seconds from UTC that was used to express Time-Of-Day-Start, Time-Of-Day-End, Day-Of-Week-Mask, Day-Of-Month- Mask and Month-Of-Year-Mask AVPs. This AVP MUST be present if the Timezone-Flag AVP is set to OFFSET. 5. Actions This section illustrates the actions associated with a rule. This document only defines QoS specific actions but further actions can be specified as extensions. 5.1. Action AVP The Action AVP (AVP Code TBD) is of type Enumerated and lists the actions that are associated with the condition part of a rule. The following actions are defined in this document: Korhonen, et al. Expires June 21, 2009 [Page 24] Internet-Draft QoS Attributes for Diameter December 2008 0: drop 1: shape 2: mark drop: All traffic that is met by the condition part of a rule MUST be dropped. shape: When the action is set to 'shape', it is expected that the QoS- Parameters AVP carries QoS information to indicate how to shape the traffic indicated in the condition part of the rule. mark: When the action is set to 'mark', it is expected that the QoS- Parameters AVP carries information about the QoS class. Further action values can be registered, as described in Section 10.4. 5.2. Diameter QoS Defined AVPs 5.2.1. QoS-Profile-Id AVP The QoS-Profile-Id AVP (AVP Code TBD) is of type Unsigned32 and contains a QoS profile template identifier. An initial QoS profile template is defined with value of 0 and can be found in [I-D.ietf-dime-qos-parameters]. The registry for the QoS profile templates is created with the same document. 5.2.2. QoS-Profile-Template AVP The QoS-Profile-Template AVP (AVP Code TBD) is of type Grouped and defines the namespace of the QoS profile (indicated in the Vendor-ID AVP) followed by the specific value for the profile. The Vendor-Id AVP contains a 32 bit IANA SMI Network Management Private Enterprise Code and the QoS-Profile-Id AVP contains the template identifier assigned by the vendor. The vendor identifier of zero (0) is used for the IETF. Korhonen, et al. Expires June 21, 2009 [Page 25] Internet-Draft QoS Attributes for Diameter December 2008 QoS-Profile-Template ::= < AVP Header: XXX > { Vendor-Id } { QoS-Profile-Id } * [ AVP ] 5.2.3. QoS-Semantics The QoS-Semantics AVP (AVP Code TBD) is of type Enumerated and provides the semantics for the QoS-Profile-Template and QoS- Parameters AVPs in the Rule AVP. This document defines the following values: (0): QoS-Desired (1): QoS-Available (2): QoS-Reserved (3): Minimum-QoS (4): QoS-Authorized The semantic of the QoS parameters depend on the information provided in the list above. The semantics of the different values are as follows: Korhonen, et al. Expires June 21, 2009 [Page 26] Internet-Draft QoS Attributes for Diameter December 2008 Object Type Direction Semantic --------------------------------------------------------------------- QoS-Desired C->S Please authorize the indicated QoS QoS-Desired C<-S NA QoS-Available C->S Admission Control at interface indicates that this QoS is available. (note 1) QoS-Available C<-S Indicated QoS is available. (note 2) QoS-Reserved C->S Used for reporting during accounting. QoS-Reserved C<-S NA Minimum-QoS C->S Indicates that the client is not interested in authorizing QoS that is lower than Min. QoS. Minimum-QoS C<-S The client must not provide QoS guarantees lower than Min. QoS. QoS-Authorized C->S NA QoS-Authorized C<-S Indicated QoS authorized Legend: C: Diameter client S: Diameter server NA: Not applicable to this document; no semantic defined in this specification Notes: (1) QoS-Available is only useful in relationship with QoS-Desired (and optionally with Minimum-QoS). (2) QoS-Available is only useful when the AAA server performs admission control and knows about the resources in the network. 5.2.4. QoS-Parameters AVP The QoS-Parameters AVP (AVP Code TBD) is of type grouped and contains Quality of Service parameters. These parameters are defined in separate documents and depend on the indicated QoS profile template of the QoS-Profile-Template AVP. For an initial QoS parameter specification see [I-D.ietf-dime-qos-parameters]. QoS-Parameters ::= < AVP Header: XXX > * [ AVP ] 5.2.5. Rule-Precedence AVP The Rule-Precedence AVP (AVP Code TBD) is of type Unsigned32 and specifies the execution order of the rules expressed in the Rule-Set AVP. Rules with equal precedence MAY be executed in parallel if [Victor: If run in parallel, what happens if both rules have successful matches but different actions ?] Korhonen, et al. Expires June 21, 2009 [Page 27] Internet-Draft QoS Attributes for Diameter December 2008 supported by the Resource Management Function. If the Rule- Precedence AVP is absent from the Rule AVP, the rules SHOULD be executed in the order in which they appear in the Rule-Set AVP. The lower the numerical value of Rule-Precedence AVP, the higher the rule precedence. 5.2.6. Excess-Treatment AVP The Excess-Treatment AVP (AVP Code TBD) is of type grouped and indicates how out-of- profile traffic, that is, traffic not covered [Victor: /out-of- profile/out-of-profile/s] by the original QoS-Profile-Template and QoS-Parameters AVPs [Victor: add "is treated." to the end of this sentence] . The additional QoS-Profile-Template and QoS-Parameters AVPs carried inside the Excess-Treatment AVP provide information about the QoS treatment of the excess traffic. Excess-Treatment ::= < AVP Header: XXX > { Excess-Treatment-Action } [ QoS-Profile-Template ] [ QoS-Parameters ] * [ AVP ] 5.2.7. Excess-Treatment-Action The Excess-Treatment-Action AVP (AVP Code TBD) is of type Enumerated and lists the actions about how the out-of-traffic regarding a specific QoS profile is treated. 0: drop 1: shape 2: remark 3: no metering or policing is permitted drop: When excess treatment action is set to 'drop', all marked traffic MUST be dropped by a QoS aware node. shape: When excess treatment action is set to 'shape', it is expected that the QoS-Parameters AVP carries QoS information to what QoS parameter to re-shape the traffic. An example would be to use the TMOD parameter defined in [I-D.ietf-dime-qos-parameters] and the excess traffic is then to be shaped to this TMOD. When the shaping causes unbounded queue growth at the shaper traffic can be dropped. [Victor: /at the shaper traffic can be dropped/at the shaper, then traffic can be dropped/s] Korhonen, et al. Expires June 21, 2009 [Page 28] Internet-Draft QoS Attributes for Diameter December 2008 remark: When excess treatment action is set to 'remark', it is expected that the QoS-Parameters AVP carries information about the QoS class. For example, packets may be remarked to drop remarked to pertain to a particular QoS class. In the latter case, remarking relates to a DiffServ-type model, where packets arrive marked as belonging to a certain QoS class, and when they are identified as excess, they should then be remarked to a different QoS Class. no metering or policing is permitted: If 'no metering or policing is permitted' is signaled, the QoS aware node should accept the excess treatment parameter set by the sender with special care so that excess traffic should not cause a problem. To request the Null Meter [RFC3290] is especially strong, and should be used with caution. When the Excess-Treatment AVP is omitted then excess treatment is essentially unspecified and there are no guaranted behavior with regard to excess traffic, i.e., a QoS aware node can do what it finds suitable. Further values can be registered, as described in Section 10.3. 6. QoS Capability Indication The QoS-Capability AVP (AVP Code TBD) is of type Grouped and contains a list of supported Quality of Service profile templates (and therefore the support of the respective parameter AVPs). The QoS-Capability AVP may be used for a simple announcement of the QoS capabilities and QoS profiles supported by a peer. It may also be used to negotiate a mutually supported set of QoS capabilities and QoS profiles between two peers. [Victor: Can we add a sentence: "In such a case, handling of failed negotiations is application and/or deployment specific."] QoS-Capability ::= < AVP Header: XXX > * [ QoS-Profile-Template ] * [ AVP ] The QoS-Profile-Template AVP is defined in Section 5.2.2. 7. Examples This section shows a number of signaling flows where QoS negotiation Korhonen, et al. Expires June 21, 2009 [Page 29] Internet-Draft QoS Attributes for Diameter December 2008 and authorization is part of the conventional NASREQ, EAP or Credit Control applications message exchanges. The signalling flows for the Diameter QoS Application are described in [I-D.ietf-dime-diameter-qos]. 7.1. Diameter EAP with QoS Information Figure 2 shows a simple signaling flow where a NAS (Diameter Client) announces its QoS awareness and capabilities included into the DER message and as part of the access authentication procedure. Upon completion of the EAP exchange, the Diameter Server provides a pre- provisioned QoS profile with the QoS-Semantics in the Rule AVP set to "QoS-Authorized", to the NAS in the final DEA message. Korhonen, et al. Expires June 21, 2009 [Page 30] Internet-Draft QoS Attributes for Diameter December 2008 End Diameter Diameter Host Client Server | | | | (initiate EAP) | | |<----------------------------->| | | | Diameter-EAP-Request | | | EAP-Payload(EAP Start) | | | QoS-Capability | | |------------------------------->| | | | | | Diameter-EAP-Answer | | Result-Code=DIAMETER_MULTI_ROUND_AUTH | | | EAP-Payload(EAP Request #1) | | |<-------------------------------| | EAP Request(Identity) | | |<------------------------------| | : : : : <<>> : : : : | | | | EAP Response #N | | |------------------------------>| | | | Diameter-EAP-Request | | | EAP-Payload(EAP Response #N) | | |------------------------------->| | | | | | Diameter-EAP-Answer | | | Result-Code=DIAMETER_SUCCESS | | | EAP-Payload(EAP Success) | | | [EAP-Master-Session-Key] | | | (authorization AVPs) | | | Rule-Set(QoS-Authorized) | | |<-------------------------------| | | | | EAP Success | | |<------------------------------| | | | | Figure 2: Example of a Diameter EAP enhanced with QoS Information 7.2. Diameter NASREQ with QoS Information Figure 3 shows a similar pre-provisioned QoS signaling as in Figure 2 but using the NASREQ application instead of EAP application. Korhonen, et al. Expires June 21, 2009 [Page 31] Internet-Draft QoS Attributes for Diameter December 2008 End Diameter Host NAS Server | | | | Start Network | | | Attachment | | |<---------------->| | | | | | |AA-Request | | |NASREQ-Payload | | |QoS-Capability | | +----------------------------->| | | | | | AA-Answer| | Result-Code=DIAMETER_MULTI_ROUND_AUTH| | NASREQ-Payload(NASREQ Request #1)| | |<-----------------------------+ | | | | Request | | |<-----------------+ | | | | : : : : <<>> : : : : | Response #N | | +----------------->| | | | | | |AA-Request | | |NASREQ-Payload ( Response #N )| | +----------------------------->| | | | | | AA-Answer| | | Result-Code=DIAMETER_SUCCESS| | | (authorization AVPs)| | | Rule-Set(QoS-Authorized) | | |<-----------------------------+ | | | | Success | | |<-----------------+ | | | | Figure 3: Example of a Diameter NASREQ enhanced with QoS Information 7.3. QoS Authorization Figure 4 shows an example of authorization only QoS signaling as part of the NASREQ message exchange. The NAS provides the Diameter server with the "QoS-Desired" QoS-Semantics AVP included in the Rule-Set AVP. The Diameter server then either authorizes the indicated QoS or Korhonen, et al. Expires June 21, 2009 [Page 32] Internet-Draft QoS Attributes for Diameter December 2008 rejects the request and informs the NAS about the result. In this scenario the NAS does not need to include the QoS-Capability AVP in the AAR message as the Rule-Set AVP implicitly does the same and also the NAS is authorizing a specific QoS profile, not a pre-provisioned one. End Diameter Host NAS Server | | | | | | | QoS Request | | +----------------->| | | | | | |AA-Request | | |Auth-Request-Type=AUTHORIZE_ONLY | |NASREQ-Payload | | |Rule-Set(QoS-Desired) | | +----------------------------->| | | | | | AA-Answer| | | NASREQ-Payload(Success)| | | Rule-Set(QoS-Authorized)| | |<-----------------------------+ | Accept | | |<-----------------+ | | | | | | | | | | Figure 4: Example of an Authorization-Only Message Flow 7.4. Diameter Server Initiated Re-authorization of QoS Figure 5 shows a message exchange for a Diameter server initiated QoS re-authorization procedure. The Diameter server sends the NAS a RAR message requesting re-authorization for an existing session and the NAS acknowledges it with a RAA message. The NAS is aware of its existing QoS profile and information for the ongoing session that the Diameter server requested for re-authorization. Thus, the NAS must initiate re-authorization of the existing QoS profile. The re- authorization procedure is the same as in Figure 4. Korhonen, et al. Expires June 21, 2009 [Page 33] Internet-Draft QoS Attributes for Diameter December 2008 End Diameter Host NAS Server | | | | | | : : : : <<>> : : : : | | | | | RA-Request | | |<-----------------------------+ | | | | |RA-Answer | | |Result-Code=DIAMETER_SUCCESS | | +----------------------------->| | | | | | | | |AA-Request | | |NASREQ-Payload | | |Auth-Request-Type=AUTHORIZE_ONLY | |Rule-Set(QoS-Desired) | | +----------------------------->| | | | | | AA-Answer| | | Result-Code=DIAMETER_SUCCESS| | | (authorization AVPs)| | | Rule-Set(QoS-Authorized) | | |<-----------------------------+ | | | Figure 5: Example of a Server-initiated Re-Authorization Procedure 7.5. Diameter Credit Control with QoS Information In this case the User is charged as soon as the Service Element (CC client) receives the service request. In this case the client uses the "QoS-Desired" QoS-Semantics parameter in the Rule-Set AVP that it sends to the Accounitng server. The server responds with a "QoS- Available" QoS-Semantics parameter in the Rule-Set AVP Korhonen, et al. Expires June 21, 2009 [Page 34] Internet-Draft QoS Attributes for Diameter December 2008 Service Element End User (CC Client) B CC Server | | | | |(1) Service Request | | | |-------------------->| | | | |(2) CCR (event, DIRECT_DEBITING,| | | Rule-Set[QoS-desired]) | | |-------------------------------->| | |(3) CCA (Granted-Units, QoS- | | | Resources[QoS-Authorized]) | | |<--------------------------------| |(4) Service Delivery | | | |<--------------------| | | |(5) Begin service | | | |<------------------------------------>| | | | | | . . . . . . . . Figure 6: Example for a One-Time Diameter Credit Control Charging Event 7.6. Classifier Examples Example: Classify all packets from hosts on subnet 12.34.56.00/24 to ports 80, 8090 or 443 on web servers 23.45.67.123, 23.45.68.124, 23.45.69.125. Classifier = { Classifier-Id = "web_svr_example"; Protocol = TCP; Direction = OUT; From-Spec = { IP-Address-Mask = { IP-Address = 12.34.56.00; IP-Bit-Mask-Width = 24; } } To-Spec = { IP-Address = 23.45.67.123; IP-Address = 23.45.68.124; IP-Address = 23.45.69.125; Port = 80; Port = 8080; Port = 443; } } Korhonen, et al. Expires June 21, 2009 [Page 35] Internet-Draft QoS Attributes for Diameter December 2008 Example: Any SIP signalling traffic from a device with a MAC address of 01:23:45:67:89:ab to servers with IP addresses in the range 34.56.78.90 to 34.56.78.190. Classifier = { Classifier-Id = "web_svr_example"; Protocol = UDP; Direction = OUT; From-Spec = { MAC-Address = 01:23:45:67:89:ab; } To-Spec = { IP-Address-Range = { IP-Address-Start = 34.56.78.90; IP-Address-End = 34.56.78.190; } Port = 5060; Port = 3478; Port-Range = { Port-Start = 16348; Port-End = 32768; } } } 8. Acknowledgments We would like to thank Victor Fajardo, Tseno Tsenov, Robert Hancock, Jukka Manner, Cornelia Kappler, Xiaoming Fu, Frank Alfano, Tolga Asveren, Mike Montemurro, Glen Zorn, Avri Doria, Dong Sun, Tina Tsou, Pete McCann, Georgios Karagiannis, Elwyn Davies, Max Riegel and Yong Li for their comments. 9. Contributors Max Riegel contributed the VLAN sections. 10. IANA Considerations 10.1. AVP Codes IANA is requested to allocate AVP codes for the following AVPs that are defined in this document. Korhonen, et al. Expires June 21, 2009 [Page 36] Internet-Draft QoS Attributes for Diameter December 2008 +--------------------------------------------------------------------+ | AVP Section | | Attribute Name Code Defined Data Type | +--------------------------------------------------------------------+ |Rule-Set TBD 3.1 Grouped | |Rule TBD 3.2 Grouped | |Classifier TBD 4.1.1 Grouped | |Classifier-ID TBD 4.1.2 OctetString | |Protocol TBD 4.1.3 Enumerated | |Direction TBD 4.1.4 Enumerated | |From-Spec TBD 4.1.5 Grouped | |To-Spec TBD 4.1.6 Grouped | |Negated TBD 4.1.7.1 Enumerated | |IP-Address TBD 4.1.7.2 Address | |IP-Address-Range TBD 4.1.7.3 Grouped | |IP-Address-Start TBD 4.1.7.4 Address | |IP-Address-End TBD 4.1.7.5 Address | |IP-Address-Mask TBD 4.1.7.6 Grouped | |IP-Mask-Bit-Mask-Width TBD 4.1.7.7 OctetString | |MAC-Address TBD 4.1.7.8 OctetString | |MAC-Address-Mask TBD 4.1.7.9 Grouped | |MAC-Address-Mask-Pattern TBD 4.1.7.10 OctetString | |EUI64-Address TBD 4.1.7.11 OctetString | |EUI64-Address-Mask TBD 4.1.7.12 Grouped | |EUI64-Address-Mask-Pattern TBD 4.1.7.13 OctetString | |Port TBD 4.1.7.14 Integer32 | |Port-Range TBD 4.1.7.15 Grouped | |Port-Start TBD 4.1.7.16 Integer32 | |Port-End TBD 4.1.7.17 Integer32 | |Use-Assigned-Address TBD 4.1.7.18 Enumerated | |Diffserv-Code-Point TBD 4.1.8.1 Enumerated | |Fragmentation-Flag TBD 4.1.8.2 Enumerated | |IP-Option TBD 4.1.8.3 Grouped | |IP-Option-Type TBD 4.1.8.4 Enumerated | |IP-Option-Value TBD 4.1.8.5 OctetString | |TCP-Option TBD 4.1.8.6 Grouped | |TCP-Option-Type TBD 4.1.8.7 Enumerated | |TCP-Option-Value TBD 4.1.8.8 OctetString | |TCP-Flags TBD 4.1.8.9 Grouped | |TCP-Flag-Type TBD 4.1.8.10 Enumerated | |ICMP-Type TBD 4.1.8.11 Grouped | |ICMP-Type-Number TBD 4.1.8.12 Enumerated | |ICMP-Code TBD 4.1.8.13 Enumerated | |ETH-Option TBD 4.1.8.14 Grouped | |ETH-Proto-Type TBD 4.1.8.15 Grouped | |ETH-Ether-Type TBD 4.1.8.16 OctetString | |ETH-SAP TBD 4.1.8.17 OctetString | |VLAN-ID-Range TBD 4.1.8.18 Grouped | Korhonen, et al. Expires June 21, 2009 [Page 37] Internet-Draft QoS Attributes for Diameter December 2008 |S-VID-Start TBD 4.1.8.19 Unsigned32 | |S-VID-End TBD 4.1.8.20 Unsigned32 | |C-VID-Start TBD 4.1.8.21 Unsigned32 | |C-VID-End TBD 4.1.8.22 Unsigned32 | |ETH-Priority-Range TBD 4.1.8.23 Grouped | |ETH-Low-Priority TBD 4.1.8.24 Unsigned32 | |ETH-High-Priority TBD 4.1.8.25 Unsigned32 | |Time-Of-Day-Condition TBD 4.2.1 Grouped | |Time-Of-Day-Start TBD 4.2.2 Grouped | |Time-Of-Day-End TBD 4.2.3 Unsigned32 | |Day-Of-Week-Mask TBD 4.2.4 Unsigned32 | |Day-Of-Month-Mask TBD 4.2.5 Unsigned32 | |Month-Of-Year-Mask TBD 4.2.6 Unsigned32 | |Absolute-Start-Time TBD 4.2.7 Time | |Absolute-End-Time TBD 4.2.8 Time | |Timezone-Flag TBD 4.2.9 Enumerated | |Timezone-Offset TBD 4.2.10 Integer32 | |Action TBD 5.1 Grouped | |QoS-Profile-Id TBD 5.2.1 Unsigned32 | |QoS-Profile-Template TBD 5.2.2 Grouped | |QoS-Semantics TBD 5.2.3 Enumerated | |QoS-Parameters TBD 5.2.4 OctetString | |Rule-Precedence TBD 5.2.5 Unsigned32 | |Excess-Treatment TBD 5.2.6 Grouped | |Excess-Treatment-Action TBD 5.2.7 Unsigned32 | |QoS-Capability TBD 6 Grouped | +--------------------------------------------------------------------+ 10.2. QoS-Semantics IANA Registry IANA is also requested to allocate a registry for the QoS-Semantics AVP. The following values are allocated by this specification. (0): QoS-Desired (1): QoS-Available (2): QoS-Reserved (3): Minimum-QoS (4): QoS-Authorized A specification is required to add a new value to the registry. 10.3. Excess Treatment Action IANA is also requested to allocate a registry for the Excess- Treatment-Action AVP. The following values are allocated by this specification: Korhonen, et al. Expires June 21, 2009 [Page 38] Internet-Draft QoS Attributes for Diameter December 2008 (0): drop (1): shape (2): remark (3): no metering or policing is permitted A specification is required to add a new value to the registry. 10.4. Action IANA is also requested to allocate a registry for the Action AVP. The following values are allocated by this specification: (0): drop (1): shape (2): mark A specification is required to add a new value to the registry. 11. Security Considerations This document describes the extension of Diameter for conveying Quality of Service information. The security considerations of the Diameter protocol itself have been discussed in RFC 3588 [RFC3588]. Use of the AVPs defined in this document MUST take into consideration the security issues and requirements of the Diameter Base protocol. 12. References 12.1. Normative References [DSCP] IANA, "Differentiated Services Field Codepoints", http://www.iana.org/assignments/dscp-registry. [ICMPTYPE] IANA, "ICMP Type Numbers", http://www.iana.org/assignments/icmp-parameters. [IEEE802.1D] IEEE, "IEEE Standard for Local and metropolitan area networks, Media Access Control (MAC) Bridges", 2004. [IEEE802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks, Virtual Bridged Local Area Networks", 2005. [IEEE802.1ad] Korhonen, et al. Expires June 21, 2009 [Page 39] Internet-Draft QoS Attributes for Diameter December 2008 IEEE, "IEEE Standard for Local and metropolitan area networks, Virtual Bridged Local Area Networks, Amendment 4: Provider Bridges", 2005. [IEEE802.2] IEEE, "IEEE Standard for Information technology, Telecommunications and information exchange between systems, Local and metropolitan area networks, Specific requirements, Part 2: Logical Link Control", 1998. [IPOPTIONS] IANA, "IP Option Numbers", http://www.iana.org/assignments/ip-parameters. [PROTOCOL] IANA, "Protocol Types", http://www.iana.org/assignments/protocol-numbers. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [TCPOPTIONS] IANA, "TCP Option Numbers", http://www.iana.org/assignments/tcp-parameters. 12.2. Informative References [I-D.ietf-dime-diameter-qos] Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., and G. Zorn, "Diameter Quality of Service Application", draft-ietf-dime-diameter-qos-06 (work in progress), July 2008. [I-D.ietf-dime-qos-parameters] Korhonen, J. and H. Tschofenig, "Quality of Service Parameters for Usage with the AAA Framework", draft-ietf-dime-qos-parameters-07 (work in progress), November 2008. [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An Informal Management Model for Diffserv Routers", RFC 3290, May 2002. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, Korhonen, et al. Expires June 21, 2009 [Page 40] Internet-Draft QoS Attributes for Diameter December 2008 August 2005. Authors' Addresses Jouni Korhonen Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland Email: jouni.korhonen@nsn.com Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland Phone: +358 (50) 4871445 Email: Hannes.Tschofenig@gmx.net URI: http://www.tschofenig.priv.at Mayutan Arumaithurai University of Goettingen Email: mayutan.arumaithurai@gmail.com Mark Jones (editor) Bridgewater Systems 303 Terry Fox Drive, Suite 500 Ottawa, Ontario K2K 3J1 Canada Phone: +1 613-591-6655 Email: mark.jones@bridgewatersystems.com Korhonen, et al. Expires June 21, 2009 [Page 41] Internet-Draft QoS Attributes for Diameter December 2008 Avi Lior Bridgewater Systems 303 Terry Fox Drive, Suite 500 Ottawa, Ontario K2K 3J1 Canada Phone: +1 613-591-6655 Email: avi@bridgewatersystems.com Korhonen, et al. Expires June 21, 2009 [Page 42] --------------060707040308080809050505 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --------------060707040308080809050505-- From dime-bounces@ietf.org Thu Jan 15 00:07:27 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CE413A6A39; Thu, 15 Jan 2009 00:07:27 -0800 (PST) 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 70A303A6A39 for ; Thu, 15 Jan 2009 00:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178, 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 uewYunK5OOWm for ; Thu, 15 Jan 2009 00:07:24 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 0834C3A6877 for ; Thu, 15 Jan 2009 00:07:23 -0800 (PST) Received: (qmail invoked by alias); 15 Jan 2009 08:07:07 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp042) with SMTP; 15 Jan 2009 09:07:07 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX183k1BDxno3E1GtDYPRHp6uandto2LK9PHQy+NcRr lIDGjEWPX/zzIb From: "Hannes Tschofenig" To: "ECRIT" , , Date: Thu, 15 Jan 2009 10:08:20 +0200 Message-ID: <000901c976e8$6edd31d0$80b5b70a@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acl2a3AtDPd3bpScQnKA0qVKoQtAZgAATX+wAAB89nAAAB01gAABhNswAAKPi7AAGgROIA== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54 Subject: [Dime] FW: RFC 5378 Implications 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org FYI Two shorter writeups from Bernard Aboba and Paul Hoffman. >-----Original Message----- >From: owner-radiusext@ops.ietf.org >[mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba >Sent: 14 January, 2009 21:50 >To: radiusext@ops.ietf.org >Subject: RFC 5378 Implications > >As some of you may know, as a result of the publication of RFC >5378, the IETF >has changed the boilerplate required for Internet-Draft submissions. > >It is important that all contributors know the terms under >which contributions are made, and to understand the >requirements imposed by RFC 5378, as well as the problems that >some people have had with it. > >Currently, a discussion is underway on the IETF Discuss >mailing list relating to the implications of RFC 5378, as well >as potential fixes to it. > >If you are a contributor or potential contributor within the >RADEXT WG, and are interested in understanding your >obligations and responsibilities under the new policies, >please consult the IETF Discussion archive: >http://www.ietf.org/mail-archive/web/ietf/current/maillist.html > >Discussion of this topic on individual Working Group mailing >lists is discouraged. > >Some recent postings on the IETF Discussion list: >IETF Trustee Request for Review: >http://www.ietf.org/mail-archive/web/ietf/current/msg54839.html >IAD statement: >http://www.ietf.org/mail-archive/web/ietf/current/msg54691.html >IETF Chair statement: >http://www.ietf.org/mail-archive/web/ietf/current/msg54502.html > > >-----Original Message----- >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] >On Behalf Of Paul Hoffman >Sent: 14 January, 2009 23:25 >To: IPsecme WG >Subject: [IPsec] RFC 5378 and this WG > >Greetings again. If you are an author or contributor on in >this WG, please read >l>. It is important. > >The WG Chairs have been asked to make their WGs aware of this >issue. This is a complicated subject, but the executive >summary is that if you have an Internet-Draft that quotes >substantially from one or more older RFCs (ones with a >publication date pre-November 11, 2008), and you did not write >this earlier work yourself (or you wrote it while with another >company), you need to be aware of the likely difficulty of >obtaining RFC 5378 clearances for your new work, and also to >be aware that a work-around is on the way. The work-around >should be in place to allow submissions to the San Francisco >IETF well before the normal deadlines. See the attached text >for more details. > >There is an open question about whether or not an Internet >Draft that quotes from the WG discussion also needs clearance >from the person who proposed text in the discussion. For >example, IKEv2bis has a lot of material that has been proposed >on this mailing list. > >If you feel that you have a draft for which this will be a >problem, please contact me. > >With a chair hat on, I am not going to allow a general >discussion about RFC 5378 on this list (as it is very >off-topic). Please take such comments to the main IETF >discussion list. Questions about specific WG drafts are of >course on topic. > >--Paul Hoffman, Director >--VPN Consortium >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 15 00:34:03 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49A233A68C7; Thu, 15 Jan 2009 00:34:03 -0800 (PST) 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 AF06E3A68C7 for ; Thu, 15 Jan 2009 00:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, J_CHICKENPOX_33=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 Gf3aNZHaFyQU for ; Thu, 15 Jan 2009 00:34:01 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id CE17A3A68B1 for ; Thu, 15 Jan 2009 00:34:00 -0800 (PST) Received: (qmail invoked by alias); 15 Jan 2009 08:07:04 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp042) with SMTP; 15 Jan 2009 09:07:04 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1++9SBup0S+kaO8FfGYzu1v1hVN6sTj2ONaASaw0b wmp+3r7XbGSR3C From: "Hannes Tschofenig" To: "ECRIT" , , Date: Thu, 15 Jan 2009 10:08:14 +0200 Message-ID: <000801c976e8$6c73abe0$80b5b70a@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acl2fTF8EcY7EhAkQnGtbOyw5hhCAAAAOUmgABpKSiA= X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 Subject: [Dime] FW: Copyright issues affecting current Internet-Drafts 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Folks, there are some issues with the new IPR policies outlined in RFC 5378 that I would like to bring to your attention. Please read through the writeups that other folks have provided and make your own judgement. Ciao Hannes >-----Original Message----- >From: owner-radiusext@ops.ietf.org >[mailto:owner-radiusext@ops.ietf.org] On Behalf Of Dave Nelson >Sent: 14 January, 2009 21:53 >To: radiusext@ops.ietf.org >Subject: Copyright issues affecting current Internet-Drafts > >The IETF Chair has requested that all Working Groups be >notified of an intellectual property rights / copyright >"brou-ha-ha" that is being currently discussed on the IETF >General Discussion List. > >As I understand it, there is a minor defect in RFC 5378, the >document that currently governs rights in IETF submissions and >publications. >Specifically, this has to do with rights for derivative works >outside of the IETF standards process. > >There is also ongoing discussion of a workaround for this >problem. If you are interested, please consult the IETF >General Discussion mailing list archives. Any discussion of >the issue should occur on that list. > >One potential impact to the Working Groups is that revised >boilerplate text is likely to be required for submission of >I-Ds. That revised text is expected to be in place well >before the I-D submission cut-off date prior to IETF-74. >There may be some confusion during the transition, however. > >A second potential impact is that any material that has been >derived from a document published prior to the effective date >RFC 5378 (November 11, 2008) may require special restrictions >to be listed in the boilerplate, as to rights for derivative >works outside the IETF standards process. > >The "fair use doctrine" would seem to apply to small sections >of properly quoted and cited text from older documents. The >issue arises with any modifications to such text. We have >seen such re-use of modified text proposed in recent WG list >discussions on open RADEXT Issues. > >All I-D authors need to be generally aware of this issue, and >anyone wishing to include substantial sections of text or any >sections of modified text from a "pre-5378" document need to >be particular aware. It does not appear that this issue will >impact our work, if we pay attention to the details. > >Following is the details of the issue, as summarized in an >announcement from the Trustees of the IETF Trust (the agency >that holds IETF IPR). > >--------------------------------------------------------------- >----------- > >The purpose of this message is twofold: > >1) To summarize the issues that some members of our community > have experienced since the publication of RFC 5378 in >November 2008, > and >2) To invite community review and discussion on a potential >work-around > being considered by the IETF Trustees. > >Some I-D authors are having difficulty implementing RFC 5378. >An example of the difficulty is as follows: > > - an author wants to include pre-5378 content in a new submission > or contribution to the IETF, but > - s/he is not certain that all of the author(s) of the earlier > material have agreed to license it to the IETF Trust according > to RFC 5378. > >If an I-D author includes pre-5378 material in a new document, >then s/he must represent or warrant that all of the authors >who created the >pre-5378 material have granted rights for that material to the >IETF Trust. >If s/he cannot make this assertion, then s/he has a problem. > >This situation has halted the progression of some >Internet-Drafts and interrupted the publication of some RFCs. >The Trustees of the IETF Trust are investigating ways to >implement a temporary work-around so that IETF work can >continue to progress. A permanent solution to this "pre-5378 >problem" may require an update to RFC 5378, for example new >work by the community to create a 5378-bis document. > >The remainder of this message provides an outline of the >temporary work- around being considered by the Trustees. > >RFC 5378 sections 1.j and 5.3.c provide the IETF Trust with >the authority to develop legend text for authors to use in >situations where they wish to limit the granting of rights to >modify and prepare derivatives of the documents they submit. >The Trustees used this authority in 2008 to develop and adopt >the current "Legal Provisions Relating to IETF Documents" >which are posted at: >http://trustee.ietf.org/license-info/. > >The Trustees are now considering the creation of optional new >legend text which could be used by authors experiencing the >"pre-5378 problem". > >The new legend text, if implemented, would do the following: > > a. Provide Authors and Contributors with a way to identify (to the > IETF Trust) that their contributions contain material >from pre-5378 > documents for which RFC 5378 rights to modify the material outside > the IETF standards process may not have been granted, and > > b. Provide the IETF Trust and the community with a clear indication > of every document containing pre-5378 content and having the > "pre-5378 problem". > >So, how could the creation and use of some new legend text >help people work-around the pre-5378 problem? > >The proposed answer is as follows: > > 1. Anyone having a contribution with the "pre-5378" problem >should add > new legend text to the contribution, to clearly flag that >it includes > pre-5378 material for which all of the rights needed >under RFC 5378 > may not have been granted, and > > 2. The IETF Trust will consider authors and contributors (with the > pre-5378 problem) to have met their RFC 5378 obligations if the > new legend text appears on their documents, and > > 3. Authors and contributors should only resort to adding the new > legend text to their documents (per #1) if they cannot develop > certainty that all of the author(s) of pre-5378 material in > their documents have agreed to license the pre-5378 content to > the IETF Trust according to RFC 5378. > >The proposed wording for the new legend text is now available >for your review and comments in section 6.c.iii of a draft >revision to the IETF Trust's "Legal Provisions Relating to >IETF Documents" located at >http://trustee.ietf.org/policyandprocedures.html. > >Please note that the above document also contains new text in >section 5.c dealing with "License Limitations". > >If your review and feedback on this proposed work-around is >positive, then the new text may be adopted by the Trustees in >early February 2009, and then be published as an official >revision to the Legal Provisions document. If so adopted, >Internet-Drafts with pre-5378 material may advance within the >Internet standards process and get published as RFCs where >otherwise qualified to do so. Unless covered by sections >6.c.i or 6.c.ii, authors of documents in which there is no >pre-5378 material must provide a RFC 5378 license with no >limitation on modifications outside the IETF standards process. > >The IETF Trust will not grant the right to modify or prepare >derivative works of any specific RFC or other IETF >Contribution outside the IETF standards process until RFC 5378 >rights pertaining to that document have been obtained from all >authors and after compliance by the IETF Trust with RFC 5377. >The Trustees will establish one or more mechanisms by which >authors of pre-5378 documents may grant RFC 5378 rights. > >The Trustees hereby invite your review, comments and >suggestions on this proposed work-around to the "pre-5378 >problem". The period for this review is 30 days. Microsoft >WORD and PDF versions of the proposed revisions are attached >to this message. Copies are also available on the IETF Trust >website under the heading "DRAFT Policy and Procedures Being >Developed" at: >http://trustee.ietf.org/policyandprocedures.html > >All feedback submitted before the end of February 7th will be >considered by the Trustees. A decision on whether to move >forward with this proposal will be made and communicated to >you before the end of February 15th. > >Please give this your attention. > >Regards and Happy New Year ! > >Ed Juskevicius, on behalf of the IETF Trustees edj.etc at gmail.com > > > >-- >to unsubscribe send a message to >radiusext-request@ops.ietf.org with the word 'unsubscribe' in >a single line as the message text body. >archive: > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 15 08:12:47 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E27B73A6969; Thu, 15 Jan 2009 08:12:47 -0800 (PST) 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 BCE803A6969 for ; Thu, 15 Jan 2009 08:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.157 X-Spam-Level: X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=0.443, 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 ZX4EunnfXb6g for ; Thu, 15 Jan 2009 08:12:46 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id DD7BD3A67AF for ; Thu, 15 Jan 2009 08:12:45 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDI00C4MT0T42@szxga03-in.huawei.com> for dime@ietf.org; Fri, 16 Jan 2009 00:12:29 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDI0059HT0T26@szxga03-in.huawei.com> for dime@ietf.org; Fri, 16 Jan 2009 00:12:29 +0800 (CST) Received: from [192.168.1.4] ([116.24.116.214]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KDI00CIST0SEL@szxml01-in.huawei.com>; Fri, 16 Jan 2009 00:12:29 +0800 (CST) Date: Fri, 16 Jan 2009 00:12:20 +0800 From: Tina TSOU To: diameter-routing@googlegroups.com Message-id: <3566C8C1-2407-413C-9942-F5ED0B391570@huawei.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.929.2) Cc: dime@ietf.org Subject: [Dime] follow up the diameter routing DT meeting on Jan 15th 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Hannes et al, It was a fruitful meeting. Hannes, Would you send out a meeting minutes describing the concrete conclusions and the open issues we need to follow? One thing I remember is a detailed example when NAI fails or breaks down (i.e. when NAI is not enough to solve the problem) is needed in the presentation or the draft. Correct me if I remember not precisely. All, If anybody has the proposed changes to draft-tsou-dime-routing-problem- statement-01 in http://groups.google.com/group/diameter-routing/browse_thread/thread/899e7568e09634b0?hl=en , send me email with comments or word document with revised mark. I will do the editing work. Thank you. B. R. Tina Messengers: MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU Jabber: tina@jabber.org Google talk: tinatsou6@gmail.com +86-13922884380(Mobile) _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 15 20:02:03 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0B303A6893; Thu, 15 Jan 2009 20:02:03 -0800 (PST) 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 702FE3A6893 for ; Thu, 15 Jan 2009 20:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.804 X-Spam-Level: X-Spam-Status: No, score=-1.804 tagged_above=-999 required=5 tests=[AWL=0.794, 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 4ITiH2CP7bPi for ; Thu, 15 Jan 2009 20:02:01 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 37F213A6836 for ; Thu, 15 Jan 2009 20:02:01 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDJ0026TPUWWI@szxga04-in.huawei.com> for dime@ietf.org; Fri, 16 Jan 2009 12:01: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 <0KDJ004DDPUWHG@szxga04-in.huawei.com> for dime@ietf.org; Fri, 16 Jan 2009 12:01:44 +0800 (CST) Received: from z24109b ([10.70.39.116]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KDJ00B5QPUWNA@szxml04-in.huawei.com> for dime@ietf.org; Fri, 16 Jan 2009 12:01:44 +0800 (CST) Date: Fri, 16 Jan 2009 12:01:44 +0800 From: Tina TSOU To: dime@ietf.org Message-id: <00e101c9778f$253ccca0$7427460a@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 X-Priority: 3 X-MSMail-priority: Normal References: <3566C8C1-2407-413C-9942-F5ED0B391570@huawei.com> Subject: Re: [Dime] follow up the diameter routing DT meeting on Jan 15th 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: , Content-Type: multipart/mixed; boundary="===============0403199627==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0403199627== Content-type: multipart/alternative; boundary="Boundary_(ID_9cyrK6eMa8UH6x2IsD4OqQ)" This is a multi-part message in MIME format. --Boundary_(ID_9cyrK6eMa8UH6x2IsD4OqQ) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Dear all, Slides showing the walkthrough showing where Diameter routing with NAI decoration fails could be found in the following. http://groups.google.com/group/diameter-routing http://groups.google.com/group/diameter-routing/browse_thread/thread/23352cd0abe475fd Wish you a prosperous and healthy New Year:D B. R. Tina ----- Original Message ----- From: Tina TSOU To: diameter-routing@googlegroups.com Cc: dime@ietf.org Sent: Friday, January 16, 2009 12:12 AM Subject: [Dime] follow up the diameter routing DT meeting on Jan 15th Hi Hannes et al, It was a fruitful meeting. Hannes, Would you send out a meeting minutes describing the concrete conclusions and the open issues we need to follow? One thing I remember is a detailed example when NAI fails or breaks down (i.e. when NAI is not enough to solve the problem) is needed in the presentation or the draft. Correct me if I remember not precisely. All, If anybody has the proposed changes to draft-tsou-dime-routing-problem- statement-01 in http://groups.google.com/group/diameter-routing/browse_thread/thread/899e7568e09634b0?hl=en , send me email with comments or word document with revised mark. I will do the editing work. Thank you. B. R. Tina Messengers: MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU Jabber: tina@jabber.org Google talk: tinatsou6@gmail.com +86-13922884380(Mobile) _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --Boundary_(ID_9cyrK6eMa8UH6x2IsD4OqQ) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
Dear all,
Slides showing the walkthrough showing where Diameter routing with NAI decoration fails could be found in the following.
http://groups.google.com/group/diameter-routing
http://groups.google.com/group/diameter-routing/browse_thread/thread/23352cd0abe475fd
 
Wish you a prosperous and healthy New Year:D
B. R.
Tina
----- Original Message -----
From: Tina TSOU
Sent: Friday, January 16, 2009 12:12 AM
Subject: [Dime] follow up the diameter routing DT meeting on Jan 15th

Hi Hannes et al,
It was a fruitful meeting.

Hannes,
Would you send out a meeting minutes describing the concrete 
conclusions and the open issues we need to follow?
One thing I remember is a detailed example when NAI fails or breaks 
down (i.e. when NAI is not enough to solve the problem) is needed in 
the presentation or the draft. Correct me if I remember not precisely.

All,
If anybody has the proposed changes to draft-tsou-dime-routing-problem-
statement-01 in http://groups.google.com/group/diameter-routing/browse_thread/thread/899e7568e09634b0?hl=en
, send me email with comments or word document with revised mark. I 
will do the editing work. Thank you.



B. R.
Tina
Messengers:

MSN: tinatsou6@hotmail.com   Yahoo: tina_tsou    Skype: tinaTSOU    
Jabber: tina@jabber.org    Google talk: tinatsou6@gmail.com

+86-13922884380(Mobile)



_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
--Boundary_(ID_9cyrK6eMa8UH6x2IsD4OqQ)-- --===============0403199627== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0403199627==-- From dime-bounces@ietf.org Fri Jan 16 01:33:26 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E42CE28C15B; Fri, 16 Jan 2009 01:33:26 -0800 (PST) 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 AB9E328C15B for ; Fri, 16 Jan 2009 01:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.551 X-Spam-Level: X-Spam-Status: No, score=-5.551 tagged_above=-999 required=5 tests=[AWL=1.047, 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 zfydXfvrSeLr for ; Fri, 16 Jan 2009 01:33:25 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id ABF113A68FC for ; Fri, 16 Jan 2009 01:33:24 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n0G9WqeC004288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 16 Jan 2009 10:32:52 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n0G9Wpwm008014; Fri, 16 Jan 2009 10:32:51 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Jan 2009 10:32:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 16 Jan 2009 11:35:14 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF#74 - Agenda Thread-Index: Acl3vbvJwaa0yWo/R92eVrUPQYhkWQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 16 Jan 2009 09:32:51.0333 (UTC) FILETIME=[66C2B350:01C977BD] Subject: [Dime] IETF#74 - Agenda 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: , Content-Type: multipart/mixed; boundary="===============0101774981==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0101774981== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C977BD.65D9A3D4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C977BD.65D9A3D4 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I requested a 2 1/2 hour slot for the next IETF meeting.=20 We would definitely chat about the charter items and the design team work.=20 Is there something else you would like to present?=20 Logistics: Who from the draft authors is not going to make it? Who is planning to participate from remote? If you do, please drop us a mail since we need to set these things up. Last time it worked pretty nicely.=20 Ciao Hannes, Dave and Victor ------_=_NextPart_001_01C977BD.65D9A3D4 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable IETF#74 - Agenda

I requested a 2 1/2 hour slot for = the next IETF meeting.

We would definitely chat about = the charter items and the design team work.

Is there something else you would = like to present?

Logistics: Who from the draft = authors is not going to make it?
Who is planning to participate = from remote? If you do, please drop us a mail since we need to set these = things up. Last time it worked pretty nicely.

Ciao
Hannes, Dave and Victor

------_=_NextPart_001_01C977BD.65D9A3D4-- --===============0101774981== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0101774981==-- From dime-bounces@ietf.org Sat Jan 17 00:15:39 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E6B328C10E; Sat, 17 Jan 2009 00:15:39 -0800 (PST) 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 B735228C10E for ; Sat, 17 Jan 2009 00:15:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, J_CHICKENPOX_52=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 XSgQPr6k6TKJ for ; Sat, 17 Jan 2009 00:15:37 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 1A1E028C0DC for ; Sat, 17 Jan 2009 00:15:36 -0800 (PST) Received: (qmail invoked by alias); 17 Jan 2009 08:15:19 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp030) with SMTP; 17 Jan 2009 09:15:19 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19vIedhomVvjT9MxiuHED4z4DBnXUTWnZkVZ/jI35 D1y+Vw0Lk+WQsN From: "Hannes Tschofenig" To: "'Victor Fajardo'" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "'Mark Jones'" References: <496E673C.10103@tari.toshiba.com> Date: Sat, 17 Jan 2009 10:16:33 +0200 Message-ID: <01f501c9787b$e993fc30$7e4fa20a@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acl25+4LwiZpp+s/TXmZN/DuYxImPgBkgxuA In-Reply-To: <496E673C.10103@tari.toshiba.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.47 Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-ietf-dime-qos-attributes-09.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Victor, Thanks for the detailed review. A few comments inline 4.1.2. Classifier-ID AVP The Classifier-ID AVP (AVP Code TBD) is of type OctetString and uniquely identifies the classifier. Each application will define the uniqueness scope of this identifier, e.g. unique per terminal or globally unique. [Victor: What does 'globally unique' mean ? Does it mean globally unique within the context of the application ? If so, would it be better to say: unique within app AND terminal, app AND admin domain, ...] [hannes] This is a very good question. I have to figure out what type of uniqueness we demand here. From-Spec ::= < AVP Header: XXX > * [ IP-Address ] * [ IP-Address-Range ] * [ IP-Address-Mask ] * [ MAC-Address ] * [ MAC-Address-Mask] * [ EUI64-Address ] * [ EUI64-Address-Mask] * [ Port ] * [ Port-Range ] [ Negated ] [ Use-Assigned-Address ] * [ AVP ] [Victor: It seems everything is optional ... what happens if this is empty ? same for To-Spec] [hannes] If the From-Spec is empty then this is equivalent to the From-Spec AVP not being there at all. 4.1.7. Source and Destination AVPs For packet classification the contents of the From-Spec and To-Spec can contain the following AVPs. [Victor: what AVPs ?] By combining several of these AVPs within a From-Spec or To-Spec AVP and using more than one From-Spec or To-Spec AVP in the Classifier AVP, one can express many different types of address pools. [Victor: I must admit, I cannot understand what this section is implying :). Is it attempting to say that a match must be From-Spec AND To-Spec if both are present ? or some other combination ?] [hannes] I pushed this ball to Mark to respond. 4.1.7.14. Port AVP The Port AVP (AVP Code TBD) is of type Integer32 in the range of 0 to 65535 and specifies the TCP or UDP port number to match. [Victor: This is the first time TCP and UDP is mentioned, all of the above text implies a sort of protocol generality. Should it be the same here ? i.e. I can have SCTP ports also] [hannes] generalized it. 4.1.7.18. Use-Assigned-Address AVP In some scenarios, the AAA does not know the IP address assigned to the Managed Terminal at the time that the Classifier is sent to the Korhonen, et al. Expires June 21, 2009 [Page 14] Internet-Draft QoS Attributes for Diameter December 2008 Classifying Entity. The Use-Assigned-Address AVP (AVP Code TBD) is of type Enumerated containing the values of True or False. When present and set to True, it represents the IP address assigned to the Managed Terminal. Value | Name ------+-------- 0 | False 1 | True [Victor: Are we talking the classifying entity dynamically adding the managed terminals IP into this classifier entry ?, i.e. everytime a new terminal sends packets then a new entry is added with a new From-Spec ? If so, would'nt this be equivalent to a missing From-Spec for IN in the Classifier ?] [hannes] This is just a way to consider the case where the AAA sends some filters but the IP address of the terminal is not yet assigned to it. Hence, you have to put a placeholder there. 4.1.8.18. VLAN-ID-Range AVP The VLAN-ID-Range AVP (AVP Code TBD) is of type Grouped and specifies the VLAN range to match. VLAN identities are either specified by a single VLAN-ID according to [IEEE802.1Q] or by a combination of Customer and Service VLAN-IDs according to [IEEE802.1ad]. The single VLAN-ID is represented by the C-VID-Start and C-VID-End AVPs and the S-VID-Start and S-VID-End AVPs SHALL be ommitted in this case. [Victor: What is being omitted ?] If the VLAN-ID-Range AVP is omitted from the Classifier, then comparison of the VLAN identity of the packet is irrelevant. VLAN-ID-Range ::= < AVP Header: XXX > [ S-VID-Start ] [ S-VID-End ] [ C-VID-Start ] [ C-VID-End ] * [ AVP ] When the S-VID-Start AVP is present but the S-VID-End AVP is absent, the S-VID-Start AVP value MUST equal the value of the IEEE 802.1ad S-VID bits specified in [IEEE802.1ad] for a successful match. [Victor: Is this new sematic necessary ? The other range features does not have this semantic. They use only start and end. If an exact match is needed then they use start == end] [hannes] Mayutan is going to look at this section to align the semantic with the other classifiers 4.2.1. Time-Of-Day-Condition AVP The Time-Of-Day-Condition AVP (AVP Code TBD) is of type Grouped and specifies one or more time windows. Time-Of-Day-Condition ::= < AVP Header: XXX > [ Time-Of-Day-Start ] [ Time-Of-Day-End ] [ Day-Of-Week-Mask ] [ Day-Of-Month-Mask ] [ Month-Of-Year-Mask ] [ Absolute-Start-Time ] [ Absolute-End-Time ] [ Timezone-Flag ] * [ AVP ] [Victor: We should mention that if most of the AVPs above are present, their evaluation criteria or values are allowed to overlap] [hannes] Not sure what you mean. If you specify, for example, Time-of-Day and Month-of-Year then both need to match. Nevertheless, Mark is going to review again the rule matching algorithm. 5.2.5. Rule-Precedence AVP The Rule-Precedence AVP (AVP Code TBD) is of type Unsigned32 and specifies the execution order of the rules expressed in the Rule-Set AVP. Rules with equal precedence MAY be executed in parallel if [Victor: If run in parallel, what happens if both rules have successful matches but different actions ?] [hannes] Mark is going to look at this issue. This subject is about conflict resolution. The precedence would ensure that this actually never happens. Hence, you cannot give two rules the same precedence. Mark has to clarify this issue. Ciao Hannes >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >Behalf Of Victor Fajardo >Sent: 15 January, 2009 00:29 >To: hannes.tschofenig@nsn.com; Mark Jones >Cc: dime@ietf.org >Subject: [Dime] Review of draft-ietf-dime-qos-attributes-09.txt > >Hi Hannes/Mark, > >Attached is my review of the qos-attribute draft. My comments >are inlined under "[Victor: ...". > >best regards, >victor > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Jan 17 18:35:38 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A5C53A6AB7; Sat, 17 Jan 2009 18:35:38 -0800 (PST) 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 2A5BB3A6AA6 for ; Sat, 17 Jan 2009 18:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_COM=0.311] 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 dOESO1f6a2kX for ; Sat, 17 Jan 2009 18:35:36 -0800 (PST) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 758243A6B45 for ; Sat, 17 Jan 2009 18:35:36 -0800 (PST) Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id n0I2WUbG077335; Sat, 17 Jan 2009 21:32:31 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <4972955F.2010408@tari.toshiba.com> Date: Sat, 17 Jan 2009 21:35:11 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20090105) MIME-Version: 1.0 To: Hannes Tschofenig , "Tschofenig, Hannes \(NSN - FI/Espoo\)" References: <496E673C.10103@tari.toshiba.com> <01f501c9787b$e993fc30$7e4fa20a@nsnintra.net> In-Reply-To: <01f501c9787b$e993fc30$7e4fa20a@nsnintra.net> Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-ietf-dime-qos-attributes-09.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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Hannes, > 4.2.1. Time-Of-Day-Condition AVP > > The Time-Of-Day-Condition AVP (AVP Code TBD) is of type Grouped and > specifies one or more time windows. > > > Time-Of-Day-Condition ::= < AVP Header: XXX > > [ Time-Of-Day-Start ] > [ Time-Of-Day-End ] > [ Day-Of-Week-Mask ] > [ Day-Of-Month-Mask ] > [ Month-Of-Year-Mask ] > [ Absolute-Start-Time ] > [ Absolute-End-Time ] > [ Timezone-Flag ] > * [ AVP ] > > [Victor: We should mention that if most of the AVPs above are present, their > evaluation criteria or values are allowed to overlap] > > [hannes] Not sure what you mean. If you specify, for example, Time-of-Day > and Month-of-Year then both need to match. > I see. I missed the part that where everything is a mask except for the X-Start-Time, X-End-Time and Timezone-Flag AVPs. Masking properties maybe the only thing we need to clarify. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Jan 17 20:11:26 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF6783A6961; Sat, 17 Jan 2009 20:11:26 -0800 (PST) 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 3A2693A6961 for ; Sat, 17 Jan 2009 20:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.47 X-Spam-Level: **** X-Spam-Status: No, score=4.47 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RDNS_NONE=0.1, SARE_RECV_IP_219128=1.666] 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 wP38R5k8vYsM for ; Sat, 17 Jan 2009 20:11:24 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id A97273A6917 for ; Sat, 17 Jan 2009 20:11:23 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDN00L57FM9XF@szxga04-in.huawei.com> for dime@ietf.org; Sun, 18 Jan 2009 12:10:57 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDN00C55FM9QB@szxga04-in.huawei.com> for dime@ietf.org; Sun, 18 Jan 2009 12:10:57 +0800 (CST) Received: from [192.168.1.4] (237.217.133.219.broad.sz.gd.dynamic.163data.com.cn [219.133.217.237]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KDN00B2GFM7AY@szxml02-in.huawei.com> for dime@ietf.org; Sun, 18 Jan 2009 12:10:57 +0800 (CST) Date: Sun, 18 Jan 2009 12:10:55 +0800 From: Tina TSOU To: dime@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.929.2) References: Subject: [Dime] Fwd: Input to Jan 22nd Thu DT meeting 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: , Content-Type: multipart/mixed; boundary="===============1637650806==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1637650806== Content-type: multipart/alternative; boundary="Boundary_(ID_SX5S2P6s/HC3Qg90w2AybQ)" --Boundary_(ID_SX5S2P6s/HC3Qg90w2AybQ) Content-type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-transfer-encoding: quoted-printable Hi all, The .xml and .txt files of updated draft-tsou-dime-routing-problem-=20 statement-01 could be found in = http://groups.google.com/group/diameter-routing/browse_thread/thread/6750c= 39d5970aada?hl=3Den B. R. Tina Begin forwarded message: > From: Tina TSOU > Date: January 18, 2009 12:07:44 PM GMT+08:00 > To: diameter-routing@googlegroups.com > Subject: Input to Jan 22nd Thu DT meeting > > > Hi all, > I did not see the meeting minutes of Jan 15th DT meeting from Hannes =20= > yet. > > So as the editor, I did the input to Jan 22nd Thu DT meeting based =20 > on my own memory. > 1) slides of walkthrough showing where Diameter routing with NAI =20 > decoration fails. (Thanks Mark confirmed the question.) > The slides were sent on Jan 16th. > = http://groups.google.com/group/diameter-routing/browse_thread/thread/23352= cd0abe475fd?hl=3Den > > 2) delete NAI > Attached please find the .xml and .txt files. > > > > 3) Same questions to the DT as following. > Could we make a decision on how to proceed with explicit routing =20 > problem? > How many would like to see this problem being solved in the WG? > > > Hope the slides and the text files are clear enough. A meeting =20 > minutes is appreciated, just in case if I will be in hospital by =20 > that time. > > > BTW, today is Lord of Kitchen's Day in China, the 23th or 24th day =20 > in the twelfth month of the lunar year, a fete day to sacrifice king =20= > of kitchen=EF=BC=88=E7=81=B6=E5=90=9B=EF=BC=8C=E7=81=B6=E7=8E=8B=E7=88=B7= =EF=BC=89. Have a nice day and the weekend. > > > B. R. > Tina > > Messengers: > > MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU =20= > Jabber: tina@jabber.org Google talk: tinatsou6@gmail.com > > +86-13922884380(Mobile) > > > > > --Boundary_(ID_SX5S2P6s/HC3Qg90w2AybQ) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: quoted-printable
Hi all,
The .xml = and .txt files of updated http://groups.google.com/group/diameter-routi= ng/browse_thread/thread/6750c39d5970aada?hl=3Den

B. = R.
Tina

=


Begin forwarded = message:

From: Tina TSOU <tena@huawei.com>
Date: = January 18, 2009 12:07:44 PM GMT+08:00
Subject: Input to Jan 22nd Thu DT = meeting
The slides were sent on Jan = 16th.

<= div>2) delete NAI
Attached please find the .xml and .txt = files.


Could we make a decision on how to = proceed with explicit routing problem?
How many would like to see = this problem being solved in the = WG? 


Hope the slides = and the text files are clear enough. A meeting minutes is appreciated, = just in case if I will be in hospital by that = time.


BTW, today is Lord of = Kitchen's Day in China, the 23th or 24th day in the twelfth = month of the lunar year, a fete day to sacrifice king of = kitchen=EF=BC=88=E7=81=B6=E5=90=9B=EF=BC=8C=E7=81=B6=E7=8E=8B=E7=88=B7= =EF=BC=89. Have a nice day and the weekend.


B. = R.
Tina

Messengers:

MSN: tinatsou6@hotmail.com  = ; Yahoo: tina_tsou    Skype: tinaTSOU    = Jabber: tina@jabber.org    = Google talk: tinatsou6@gmail.com

+86-13922884380(Mobile)

<= /span>



=


= --Boundary_(ID_SX5S2P6s/HC3Qg90w2AybQ)-- --===============1637650806== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1637650806==-- From dime-bounces@ietf.org Sun Jan 18 02:11:32 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73F943A6924; Sun, 18 Jan 2009 02:11:32 -0800 (PST) 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 662713A6924 for ; Sun, 18 Jan 2009 02:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 mt07v1MoT3cQ for ; Sun, 18 Jan 2009 02:11:30 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 86FFD3A677E for ; Sun, 18 Jan 2009 02:11:30 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 7EE9519871D for ; Sun, 18 Jan 2009 12:11:13 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 3CE13198678 for ; Sun, 18 Jan 2009 12:11:13 +0200 (EET) Message-ID: <49730005.9040009@piuha.net> Date: Sun, 18 Jan 2009 12:10:13 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: dime@ietf.org X-Virus-Scanned: ClamAV using ClamSMTP Subject: [Dime] review of rfc3588bis, typos 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I'm going through the bis draft, and also run spell on it. Here's what it complained about: > abrubtly shutdown by comparing the old value of the Origin-State-Id Abruptly > rule MUST be used againts the redirect usage value to resolve the against > routing decisions. Prioritization of redirect routhierarchy > ing criterias criteria (I think) > case, the Failed-AVP MAY contain the grouped AVP heirarchy up to the hierarchy > appropriate value to inidcate the cause of the error. An application indicate > recommnedations in [RFC4690 ] and [RFC3490 ]. Applications that recommendations > application that may or may not have a semantical relationship with semantic (or better yet, drop the entire word) Jari _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Jan 18 02:18:12 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA2193A6A6E; Sun, 18 Jan 2009 02:18:12 -0800 (PST) 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 0F0CB3A6B4A for ; Sun, 18 Jan 2009 02:18:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 eqqr-LaDmTjB for ; Sun, 18 Jan 2009 02:18:10 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id A9C203A6965 for ; Sun, 18 Jan 2009 02:18:09 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 664F419871D for ; Sun, 18 Jan 2009 12:17:53 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 1C773198678 for ; Sun, 18 Jan 2009 12:17:53 +0200 (EET) Message-ID: <49730194.1060207@piuha.net> Date: Sun, 18 Jan 2009 12:16:52 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: dime@ietf.org X-Virus-Scanned: ClamAV using ClamSMTP Subject: [Dime] review of rfc3588bis, until about page 10 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Here's the first part of my review: > The Diameter base protocol is intended to provide an Authentication, > Authorization and Accounting (AAA) framework for applications such as > network access or IP mobility. Diameter is also intended to work in > both local Authentication, Authorization & Accounting and roaming > situations. This document specifies the message format, transport, > error reporting, accounting and security services to be used by all > Diameter applications. The Diameter base application needs to be > supported by all Diameter implementations. > s/intended to provide/provides/ s/intended to work/works/ or are you unsure about this? :-) > Authentication, Authorization and Accounting (AAA) protocols such as > TACACS [RFC1492 ] and RADIUS [RFC2865 ] were initially deployed to > provide dial-up PPP [RFC1661 ] and terminal server access. Over time, > with the growth of the Internet and the introduction of new access > technologies (including wireless, DSL, Mobile IP and Ethernet), both > the amount and complexity of processing performed by routers and > network access servers (NAS) have increased, putting new demands on > AAA protocols. > Maybe ... Over time, AAA was needed on many new access technologies, the scale and complexity of AAA networks grew, and AAA was also used on new applications (such as voice over IP). This lead to new demands on AAA protocols. > Since within [RFC4306 ] authentication > occurs only within Phase 1 prior to the establishment of IPsec SAs > in Phase 2, it is typically not possible to define separate trust > or authorization schemes for each application. What phase 1 and 2? IKEv2 no longer has them... > The Diameter base protocol provides the following facilities: > > o Delivery of AVPs (attribute value pairs) > This reads a bit funny. I'd say o Ability to exchange messages and deliver AVPs (attribute value pairs) > AVPs are > used by the base Diameter protocol to support the following required > features: > > o ... > > o Relaying, proxying and redirecting of Diameter messages through a > server hierarchy. > Maybe "Routing, relaying, ..." (because the basic routing functionality too relies on AVPs). > At this time the focus of Diameter is network > access and accounting applications. I do not know if this is true any more. Maybe "The initial focus of Diameter was network ..." To be continued... Jari _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Jan 18 13:51:38 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DC5E3A6B4F; Sun, 18 Jan 2009 13:51:38 -0800 (PST) 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 8E52A3A6B4F for ; Sun, 18 Jan 2009 13:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 d+qQdYPxtinP for ; Sun, 18 Jan 2009 13:51:36 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 0BBAA3A67BD for ; Sun, 18 Jan 2009 13:51:36 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id EE16019870B for ; Sun, 18 Jan 2009 23:51:17 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 959B01986E2 for ; Sun, 18 Jan 2009 23:51:17 +0200 (EET) Message-ID: <4973A419.5080508@piuha.net> Date: Sun, 18 Jan 2009 23:50:17 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: dime@ietf.org References: <49730194.1060207@piuha.net> In-Reply-To: <49730194.1060207@piuha.net> X-Virus-Scanned: ClamAV using ClamSMTP Subject: [Dime] review of rfc3588bis, roughly between pages 10 and 20, and some parts of Section 11 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org More review... > The Diameter discovery > process now supports only well known discovery schemes. Maybe s/well known/widely used/ > IETF Review [RFC2434 ], Obsolete reference, use 5226. > 11.4. AVP Values > > Certain AVPs in Diameter define a list of values with various > meanings. For attributes other than those specified in this section, > adding additional values to the list can be done on a First Come, > First Served basis by IANA. What does "attributes other than those specified in this section" refer to? AVPs from this spec but not listed here? All AVPs not listed here? If its the latter, then the rules will be in conflict with some other specification, say, RFC 4005 has IETF Consensus rule for an AVP, Accounting-Auth-Method. But even if it would only refer to AVPs from this spec, FCFS does not work for their values, e.g., addresses in Host-IP-Address AVP. Finally, presumably {Auth,Acct}-Application-Id AVPs do not fall under the FCFS rule? Suggested rewrite: 11.4. AVP Values Certain AVPs in Diameter define a list of values with various meanings. This section lists such attributes in the Diameter base protocol and their IANA allocation rules. Allocation of Application Ids was discussed in Section 11.3. Other attributes in the base protocol do not take enumerated values or bit masks or employ existing name spaces such as SMI Network Management Private Enterprise Codes [RFC3232] or IP addresses. The allocation of new values for these existing name spaces is done in accordance with the rules already defined for them. 11.4.x. Experimental-Result-Code AVP Values for this AVP are purely local to the indicated vendor, and no IANA registry of them is maintained. 11.4.1 (the rest of the section continues as in the current draft) > the data types listed in Section 4.2 or 4.3. This would be better as Section 4.2 or Section 4.3, because then the ietfs tools can jump between the sections :-) Now they just recognize the first section reference. > Note: Protocol designer should try to re-use existing functionality, > namely AVP values, AVPs, commands, and Diameter applications. Reuse > simplifies standardization and implementation. To avoid potential > interoperability issues it is important to ensure that the semantics > of the re-used features are well understood. > I would add: "Given that Diameter can also carry RADIUS attributes as Diameter AVPs, such re-use considerations apply also to existing RADIUS attributes that may be useful in a Diameter application." > Every Diameter application specification MUST have an IANA assigned > Application Id (see Section 2.4 and Section 11.3 ). The managed > Application ID space is flat and there is no relationship between > different Diameter applications with respect to their application > IDs. Inconsistent capitalization of Id. The document mostly uses Application Id, but above we can see two instances of Application IDs. I grepped for additional instances and there weren't any, but my tool was unable to search across line endings. > every Diameter application is a standalone > application that may or may not have a semantical relationship with > one or more Diameter applications being defined elsewhere. > I commented this in the other e-mail already. But this would be better rewritten as: ... every Diameter application is a standalone application. If the application has a relationship with other Diameter applications, such a relationship is not known to Diameter. > AVPs may be added arbitrarily to Diameter messages, > so long as the requirements of a message's ABNF are met. This is the first use of "ABNF", and the acronym is not explained or the concept explained. > Before describing the rules for creating new Diameter applications it > is important to discuss the semantics of the AVPs occurrences as > stated in the ABNF and the M-bit flag for an AVP. This is the first use of "M-bit" and the concept is not given with either an explanation or a forward reference. Suggested edit: ... the M-bit flag (Section 4.1) for ... > Broker > > A broker is a business term commonly used in AAA infrastructures. > A broker is either a relay, proxy or redirect agent, and may be > operated by roaming consortiums. Depending on the business model, > a broker may either choose to deploy relay agents or proxy agents. > Unused term, delete? > Diameter Node > > A Diameter node is a host process that implements the Diameter > protocol, and acts either as a Client, Agent or Server. > > > Diameter Peer > > A Diameter Peer is a Diameter Node to which a given Diameter Node > has a direct transport connection. > > What happened with indentation here? Other similar occurrences in the same section. > Roaming Relationships > > Roaming relationships include relationships between companies and > ISPs, relationships among peer ISPs within a roaming consortium, > and relationships between an ISP and a roaming consortium. Unused term, delete? (Section 9.1 has this text that is close to using this term, but not quite, and I think it is self-explanatory anyway: "The authorization server (chain) directs the selection of proper transfer strategy, based on its knowledge of the user and relationships of roaming partnerships.") Jari _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Jan 18 23:00:33 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C81E3A6803; Sun, 18 Jan 2009 23:00:33 -0800 (PST) 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 655D228C157 for ; Sun, 18 Jan 2009 23:00:31 -0800 (PST) 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 kGZG+xa4E8je for ; Sun, 18 Jan 2009 23:00:30 -0800 (PST) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 88DAC3A676A for ; Sun, 18 Jan 2009 23:00:30 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 677AC90020 for ; Mon, 19 Jan 2009 02:00:11 -0500 (EST) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07933-01 for ; Mon, 19 Jan 2009 02:00:11 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Mon, 19 Jan 2009 02:00:11 -0500 (EST) Received: from exchindia3.starentnetworks.com ([10.6.7.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jan 2009 02:00:10 -0500 Received: from [10.6.7.67] ([10.6.7.67]) by exchindia3.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jan 2009 12:30:06 +0530 Message-ID: <497424EA.9060805@starentnetworks.com> Date: Mon, 19 Jan 2009 12:29:54 +0530 From: Sarkar Biplab User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: dime@ietf.org X-Enigmail-Version: 0.95.7 OpenPGP: url=http://pgp.mit.edu:11371/pks/lookup?search=0x6D543EEE&op=index X-OriginalArrivalTime: 19 Jan 2009 07:00:06.0584 (UTC) FILETIME=[8F623B80:01C97A03] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: [Dime] DPA 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: , Content-Type: multipart/mixed; boundary="===============2122761407==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2122761407== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9E2BFCF823ECDF7FE856403D" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9E2BFCF823ECDF7FE856403D Content-Type: multipart/alternative; boundary="------------070209070706020501080707" This is a multi-part message in MIME format. --------------070209070706020501080707 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello All, I have a query. What should the system do when it gets a DPA (Disconnect-Peer-Answer) in reply to a DPR(Disconnect-Peer-Request) with the Result-Code as failure? Should it close the connection or retry? Thanks & Regards, Biplab --------------070209070706020501080707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello All,

I have a query.
What should the system do when it gets a DPA (Disconnect-Peer-Answer) in reply to a DPR(Disconnect-Peer-Request) with the Result-Code as failure?
Should it close the connection or retry?

Thanks & Regards,
Biplab
--------------070209070706020501080707-- --------------enig9E2BFCF823ECDF7FE856403D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJdCTu3rQBTW1UPu4RAqvvAJ45B8INMUnQpIUaGHzzx2BUWFChhACffnIJ 35GrLzNKDnPnNp1y0/yUvM4= =ixXm -----END PGP SIGNATURE----- --------------enig9E2BFCF823ECDF7FE856403D-- --===============2122761407== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============2122761407==-- From dime-bounces@ietf.org Mon Jan 19 13:47:43 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 479423A69A8; Mon, 19 Jan 2009 13:47:43 -0800 (PST) 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 288903A6912 for ; Mon, 19 Jan 2009 13:47:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_52=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 eWQ85VHwj1D3 for ; Mon, 19 Jan 2009 13:47:41 -0800 (PST) Received: from webmail.bridgewatersystems.com (webmail.bridgewatersystems.com [66.46.199.134]) by core3.amsl.com (Postfix) with ESMTP id CD6243A6852 for ; Mon, 19 Jan 2009 13:47:40 -0800 (PST) Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Mon, 19 Jan 2009 16:47:24 -0500 From: Mark Jones To: Hannes Tschofenig , 'Victor Fajardo' , "Tschofenig, Hannes (NSN - FI/Espoo)" Date: Mon, 19 Jan 2009 16:47:23 -0500 Thread-Topic: [Dime] Review of draft-ietf-dime-qos-attributes-09.txt Thread-Index: Acl25+4LwiZpp+s/TXmZN/DuYxImPgBkgxuAAIAkfzA= Message-ID: References: <496E673C.10103@tari.toshiba.com> <01f501c9787b$e993fc30$7e4fa20a@nsnintra.net> In-Reply-To: <01f501c9787b$e993fc30$7e4fa20a@nsnintra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "dime@ietf.org" Subject: Re: [Dime] Review of draft-ietf-dime-qos-attributes-09.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Thanks for the detailed review Victor. Comments inline... > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: January 17, 2009 03:17 > To: 'Victor Fajardo'; Tschofenig, Hannes (NSN - FI/Espoo); Mark Jones > Cc: dime@ietf.org > Subject: RE: [Dime] Review of draft-ietf-dime-qos-attributes-09.txt > > Hi Victor, > > Thanks for the detailed review. > A few comments inline > > > 4.1.2. Classifier-ID AVP > > The Classifier-ID AVP (AVP Code TBD) is of type OctetString and > uniquely identifies the classifier. Each application will > define the > uniqueness scope of this identifier, e.g. unique per terminal or > globally unique. > > [Victor: What does 'globally unique' mean ? Does it mean > globally unique > within the context of the application ? If so, would it be > better to say: > unique within app AND terminal, app AND admin domain, ...] > > [hannes] This is a very good question. I have to figure out > what type of > uniqueness we demand here. > [mj] We're just giving examples here but I agree that 'globally unique' is ambiguous. The application which uses the Classifier AVPs must specify the uniqueness scope. I suggest we change the examples to "unique per Managed Terminal or unique per Classifying Entity". > > From-Spec ::= < AVP Header: XXX > > * [ IP-Address ] > * [ IP-Address-Range ] > * [ IP-Address-Mask ] > * [ MAC-Address ] > * [ MAC-Address-Mask] > * [ EUI64-Address ] > * [ EUI64-Address-Mask] > * [ Port ] > * [ Port-Range ] > [ Negated ] > [ Use-Assigned-Address ] > * [ AVP ] > > [Victor: It seems everything is optional ... what happens if > this is empty ? > same for To-Spec] > > [hannes] If the From-Spec is empty then this is equivalent to > the From-Spec > AVP not being there at all. > [mj] Agreed. > > 4.1.7. Source and Destination AVPs > > For packet classification the contents of the From-Spec and To-Spec > can contain the following AVPs. > > [Victor: what AVPs ?] > [mj] "..can contain the AVPs described in the following subsections." > By combining several of these AVPs within a From-Spec or > To-Spec AVP > and using more than one From-Spec or To-Spec AVP in the Classifier > AVP, one can express many different types of address pools. > > [Victor: I must admit, I cannot understand what this section > is implying :). > Is it attempting to say that a match must be From-Spec AND > To-Spec if both > are present ? or some other combination ?] > > [hannes] I pushed this ball to Mark to respond. > [mj] This was a motherhood statement from the original classifier draft and I think it can be removed now. I've since (hopefully) explained the interaction of multiple From-Spec/To-Spec AVPs in sections 4.1.5 and 4.1.6. > > 4.1.7.14. Port AVP > > The Port AVP (AVP Code TBD) is of type Integer32 in the > range of 0 to > 65535 and specifies the TCP or UDP port number to match. > > [Victor: This is the first time TCP and UDP is mentioned, all > of the above > text implies a sort of protocol generality. Should it be the > same here ? > i.e. I can have SCTP ports also] > > [hannes] generalized it. > [mj] Good point Victor. Thanks Hannes. > 4.1.7.18. Use-Assigned-Address AVP > > In some scenarios, the AAA does not know the IP address assigned to > the Managed Terminal at the time that the Classifier is sent to the > > > > Korhonen, et al. Expires June 21, 2009 > [Page 14] > > Internet-Draft QoS Attributes for Diameter > December 2008 > > > Classifying Entity. The Use-Assigned-Address AVP (AVP Code TBD) is > of type Enumerated containing the values of True or False. When > present and set to True, it represents the IP address > assigned to the > Managed Terminal. > > > Value | Name > ------+-------- > 0 | False > 1 | True > > [Victor: Are we talking the classifying entity dynamically adding the > managed terminals IP into this classifier entry ?, i.e. > everytime a new > terminal sends packets then a new entry is added with a new > From-Spec ? If > so, would'nt this be equivalent to a missing From-Spec for IN in the > Classifier ?] > > [hannes] This is just a way to consider the case where the > AAA sends some > filters but the IP address of the terminal is not yet assigned to it. > Hence, you have to put a placeholder there. > [mj] Agreed. This is a very useful where address allocation happens after policy delivery. > > > 4.1.8.18. VLAN-ID-Range AVP > > The VLAN-ID-Range AVP (AVP Code TBD) is of type Grouped > and specifies > the VLAN range to match. VLAN identities are either specified by a > single VLAN-ID according to [IEEE802.1Q] or by a combination of > Customer and Service VLAN-IDs according to [IEEE802.1ad]. > > The single VLAN-ID is represented by the C-VID-Start and C-VID-End > AVPs and the S-VID-Start and S-VID-End AVPs SHALL be > ommitted in this > case. > [Victor: What is being omitted ?] > > If the VLAN-ID-Range AVP is omitted from the Classifier, then > comparison of the VLAN identity of the packet is irrelevant. > > > VLAN-ID-Range ::= < AVP Header: XXX > > [ S-VID-Start ] > [ S-VID-End ] > [ C-VID-Start ] > [ C-VID-End ] > * [ AVP ] > > When the S-VID-Start AVP is present but the S-VID-End AVP > is absent, > the S-VID-Start AVP value MUST equal the value of the IEEE 802.1ad > S-VID bits specified in [IEEE802.1ad] for a successful match. > > [Victor: Is this new sematic necessary ? The other range > features does not > have this semantic. They use only start and end. If an exact > match is needed > then they use start == end] > > [hannes] Mayutan is going to look at this section to align > the semantic with > the other classifiers > > 4.2.1. Time-Of-Day-Condition AVP > > The Time-Of-Day-Condition AVP (AVP Code TBD) is of type Grouped and > specifies one or more time windows. > > > Time-Of-Day-Condition ::= < AVP Header: XXX > > [ Time-Of-Day-Start ] > [ Time-Of-Day-End ] > [ Day-Of-Week-Mask ] > [ Day-Of-Month-Mask ] > [ Month-Of-Year-Mask ] > [ Absolute-Start-Time ] > [ Absolute-End-Time ] > [ Timezone-Flag ] > * [ AVP ] > > [Victor: We should mention that if most of the AVPs above are > present, their > evaluation criteria or values are allowed to overlap] > > [hannes] Not sure what you mean. If you specify, for example, > Time-of-Day > and Month-of-Year then both need to match. > Nevertheless, Mark is going to review again the rule matching > algorithm. > > 5.2.5. Rule-Precedence AVP > > The Rule-Precedence AVP (AVP Code TBD) is of type Unsigned32 and > specifies the execution order of the rules expressed in > the Rule-Set > AVP. Rules with equal precedence MAY be executed in parallel if > > [Victor: If run in parallel, what happens if both rules have > successful > matches but different actions ?] > > [hannes] Mark is going to look at this issue. This subject is > about conflict > resolution. The precedence would ensure that this actually > never happens. > Hence, you cannot give two rules the same precedence. Mark > has to clarify > this issue. > [mj] Good question. I'd assumed that the Conditions would be mutually exclusive for Rules with equal precedence so the Actions would be operating on different packets. I can state this assumption here or we can forbid rules with equal precedence. Any preferences? > Ciao > Hannes > > >-----Original Message----- > >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > >Behalf Of Victor Fajardo > >Sent: 15 January, 2009 00:29 > >To: hannes.tschofenig@nsn.com; Mark Jones > >Cc: dime@ietf.org > >Subject: [Dime] Review of draft-ietf-dime-qos-attributes-09.txt > > > >Hi Hannes/Mark, > > > >Attached is my review of the qos-attribute draft. My comments > >are inlined under "[Victor: ...". > > > >best regards, > >victor > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jan 21 05:26:54 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71D1828C12E; Wed, 21 Jan 2009 05:26:54 -0800 (PST) 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 915A728C12A for ; Wed, 21 Jan 2009 05:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=0.236, 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 58E-BoPBj623 for ; Wed, 21 Jan 2009 05:26:51 -0800 (PST) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id AB39228C0E4 for ; Wed, 21 Jan 2009 05:26:51 -0800 (PST) Received: from [127.0.0.1] (smtp.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id n0LDNhen015774; Wed, 21 Jan 2009 08:23:43 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <49772289.2090604@tari.toshiba.com> Date: Wed, 21 Jan 2009 08:26:33 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20090105) MIME-Version: 1.0 To: Jari Arkko References: <49730005.9040009@piuha.net> In-Reply-To: <49730005.9040009@piuha.net> Cc: dime@ietf.org Subject: Re: [Dime] review of rfc3588bis, typos 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Thanks Jari. I'll update bis with changes below. > I'm going through the bis draft, and also run spell on it. Here's what > it complained about: > >> abrubtly shutdown by comparing the old value of the Origin-State-Id > Abruptly > >> rule MUST be used againts the redirect usage value to resolve the > against > >> routing decisions. Prioritization of redirect routhierarchy >> ing criterias > criteria (I think) > >> case, the Failed-AVP MAY contain the grouped AVP heirarchy up to the > hierarchy > >> appropriate value to inidcate the cause of the error. An application > indicate > >> recommnedations in [RFC4690 ] >> and [RFC3490 ]. Applications that > recommendations > >> application that may or may not have a semantical relationship with > semantic > > (or better yet, drop the entire word) > > Jari > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jan 21 05:52:28 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 047A93A6B45; Wed, 21 Jan 2009 05:52:28 -0800 (PST) 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 0860F3A6B45 for ; Wed, 21 Jan 2009 05:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, 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 JPEkNneVRH2u for ; Wed, 21 Jan 2009 05:52:26 -0800 (PST) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id C47A43A6B39 for ; Wed, 21 Jan 2009 05:52:20 -0800 (PST) Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id n0LDnCt3016195; Wed, 21 Jan 2009 08:49:13 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <49772883.8080007@tari.toshiba.com> Date: Wed, 21 Jan 2009 08:52:03 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20090105) MIME-Version: 1.0 To: Jari Arkko References: <49730194.1060207@piuha.net> In-Reply-To: <49730194.1060207@piuha.net> Cc: dime@ietf.org Subject: Re: [Dime] review of rfc3588bis, until about page 10 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Jari, Thanks for the review. Btw, I would like to get your opinion on incrementing the version number in the diameter header. There are changes in bis that would not be compatible with 3588 and I think it maybe necessary to rev up the version num. Additional comments inline: > > Here's the first part of my review: > >> The Diameter base protocol is intended to provide an Authentication, >> Authorization and Accounting (AAA) framework for applications such as >> network access or IP mobility. Diameter is also intended to work in >> both local Authentication, Authorization & Accounting and roaming >> situations. This document specifies the message format, transport, >> error reporting, accounting and security services to be used by all >> Diameter applications. The Diameter base application needs to be >> supported by all Diameter implementations. >> > > s/intended to provide/provides/ > s/intended to work/works/ > > or are you unsure about this? :-) maybe we can re-word to: "The Diameter base protocol provides and Auth..." and "Diameter also works in both ..." > >> Authentication, Authorization and Accounting (AAA) protocols such as >> TACACS [RFC1492 ] and RADIUS >> [RFC2865 ] were initially >> deployed to >> provide dial-up PPP [RFC1661 ] >> and terminal server access. Over time, >> with the growth of the Internet and the introduction of new access >> technologies (including wireless, DSL, Mobile IP and Ethernet), both >> the amount and complexity of processing performed by routers and >> network access servers (NAS) have increased, putting new demands on >> AAA protocols. >> > > Maybe ... Over time, AAA was needed on many new access technologies, > the scale and complexity of AAA networks grew, and AAA was also used > on new applications (such as voice over IP). This lead to new demands > on AAA protocols. Ok. > > >> Since within [RFC4306 ] >> authentication >> occurs only within Phase 1 prior to the establishment of IPsec SAs >> in Phase 2, it is typically not possible to define separate trust >> or authorization schemes for each application. > What phase 1 and 2? IKEv2 no longer has them... I guess we can simplify the paragraph to: While [RFC3162] defines the use of IPsec with RADIUS, support for IPsec is not required. In order to provide universal support for transmission-level security, and enable both intra- and inter- domain AAA deployments, Diameter provides support for TLS. Security is discussed in Section 13. > >> The Diameter base protocol provides the following facilities: >> >> o Delivery of AVPs (attribute value pairs) >> > This reads a bit funny. I'd say > > o Ability to exchange messages and deliver AVPs (attribute value pairs) Ok > >> AVPs are >> used by the base Diameter protocol to support the following required >> features: >> >> o ... >> >> o Relaying, proxying and redirecting of Diameter messages through a >> server hierarchy. >> > > Maybe "Routing, relaying, ..." (because the basic routing > functionality too relies on AVPs). Ok > >> At this time the focus of Diameter is network >> access and accounting applications. > I do not know if this is true any more. Maybe "The initial focus of > Diameter was network ..." Ok. regards, victor > > To be continued... > > Jari > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jan 21 07:20:26 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15CF328C155; Wed, 21 Jan 2009 07:20:26 -0800 (PST) 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 6407E28C154 for ; Wed, 21 Jan 2009 07:20:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.214, 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 mrZfNjBbZf1l for ; Wed, 21 Jan 2009 07:20:24 -0800 (PST) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id E89AE28C155 for ; Wed, 21 Jan 2009 07:20:23 -0800 (PST) Received: from [127.0.0.1] (mail.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id n0LFHFU0016929; Wed, 21 Jan 2009 10:17:15 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <49773D25.5090402@tari.toshiba.com> Date: Wed, 21 Jan 2009 10:20:05 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20090105) MIME-Version: 1.0 To: Jari Arkko References: <49730194.1060207@piuha.net> <4973A419.5080508@piuha.net> In-Reply-To: <4973A419.5080508@piuha.net> Cc: dime@ietf.org Subject: Re: [Dime] review of rfc3588bis, roughly between pages 10 and 20, and some parts of Section 11 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Comments inline: > More review... > >> The Diameter discovery >> process now supports only well known discovery schemes. > Maybe s/well known/widely used/ Ok > >> IETF Review [RFC2434 ], > Obsolete reference, use 5226. I'll updated all occurrences of 2434. > >> 11.4. AVP Values >> >> Certain AVPs in Diameter define a list of values with various >> meanings. For attributes other than those specified in this section, >> adding additional values to the list can be done on a First Come, >> First Served basis by IANA. > > What does "attributes other than those specified in this section" > refer to? AVPs from this spec but not listed here? All AVPs not listed > here? I think it meant the former. AVPs within this spec but not listed in this section. We can re-word to clarify. > If its the latter, then the rules will be in conflict with some other > specification, say, RFC 4005 has IETF Consensus rule for an AVP, > Accounting-Auth-Method. > > But even if it would only refer to AVPs from this spec, FCFS does not > work for their values, e.g., addresses in Host-IP-Address AVP. I guess it was refereing to AVPs with enumerated values or int values that are typically constants and have contextual meaning unlike Host-IP-Address. But since all of the AVPs with of this type of values are already listed in this section, mabye the FCFS text in the beginning of the section is not needed ? > > Finally, presumably {Auth,Acct}-Application-Id AVPs do not fall under > the FCFS rule? Yes. They should fall under 11.3. > > Suggested rewrite: > > 11.4. AVP Values > > Certain AVPs in Diameter define a list of values > with various meanings. This section lists such > attributes in the Diameter base protocol and their > IANA allocation rules. I agree. Pls dis-regard my comment above. > > Allocation of Application Ids was discussed in Section > 11.3. Other attributes in the base protocol do not take > enumerated values or bit masks or employ existing > name spaces such as SMI Network Management > Private Enterprise Codes [RFC3232] or IP addresses. > The allocation of new values for these existing name > spaces is done in accordance with the rules already defined > for them. Looks good. > > 11.4.x. Experimental-Result-Code AVP > > Values for this AVP are purely local to the indicated > vendor, and no IANA registry of them is maintained. > > 11.4.1 (the rest of the section continues as in the current draft) Ok. > >> the data types listed in Section 4.2 or 4.3. > > This would be better as Section 4.2 or Section 4.3, because then the > ietfs tools can jump between the sections :-) Now they just recognize > the first section reference. > I see. >> Note: Protocol designer should try to re-use existing functionality, >> namely AVP values, AVPs, commands, and Diameter applications. Reuse >> simplifies standardization and implementation. To avoid potential >> interoperability issues it is important to ensure that the semantics >> of the re-used features are well understood. >> > I would add: "Given that Diameter can also carry RADIUS attributes as > Diameter AVPs, > such re-use considerations apply also to existing RADIUS attributes > that may be useful > in a Diameter application." Ok > >> Every Diameter application specification MUST have an IANA assigned >> Application Id (see Section 2.4 >> >> and Section 11.3 >> ). >> The managed >> Application ID space is flat and there is no relationship between >> different Diameter applications with respect to their application >> IDs. > Inconsistent capitalization of Id. The document mostly uses > Application Id, but above we can see two instances of Application IDs. > I grepped for additional instances and there weren't any, but my tool > was unable to search across line endings. I've searched the docs (manually .. to cover possible phrases broken by line endings) .. seems like it only occurs here. > >> every Diameter application is a standalone >> application that may or may not have a semantical relationship with >> one or more Diameter applications being defined elsewhere. >> > I commented this in the other e-mail already. But this would be better > rewritten as: > > ... every Diameter application is a standalone application. If the > application has a relationship with other Diameter applications, such > a relationship is not known to Diameter. Ok > >> AVPs may be added arbitrarily to Diameter messages, >> so long as the requirements of a message's ABNF are met. > This is the first use of "ABNF", and the acronym is not explained or > the concept explained. Changed to: "message's ABNF (Section 3.2) are met." > >> Before describing the rules for creating new Diameter applications it >> is important to discuss the semantics of the AVPs occurrences as >> stated in the ABNF and the M-bit flag for an AVP. > This is the first use of "M-bit" and the concept is not given with > either an explanation or a forward reference. > > Suggested edit: ... the M-bit flag (Section 4.1) for ... Ok. > >> Broker >> >> A broker is a business term commonly used in AAA infrastructures. >> A broker is either a relay, proxy or redirect agent, and may be >> operated by roaming consortiums. Depending on the business model, >> a broker may either choose to deploy relay agents or proxy agents. >> > > Unused term, delete? I agree. > >> Diameter Node >> >> A Diameter node is a host process that implements the Diameter >> protocol, and acts either as a Client, Agent or Server. >> >> >> Diameter Peer >> >> A Diameter Peer is a Diameter Node to which a given Diameter Node >> has a direct transport connection. >> >> > What happened with indentation here? > > Other similar occurrences in the same section. Fixed it. > >> Roaming Relationships >> >> Roaming relationships include relationships between companies and >> ISPs, relationships among peer ISPs within a roaming consortium, >> and relationships between an ISP and a roaming consortium. > Unused term, delete? > > (Section 9.1 has this text that is close to using this term, but not > quite, and I think it is self-explanatory anyway: "The authorization > server (chain) directs the selection of proper transfer strategy, > based on its knowledge of the user and relationships of roaming > partnerships.") I agree. regards, victor > > Jari > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jan 21 22:08:37 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EECF3A68D8; Wed, 21 Jan 2009 22:08:37 -0800 (PST) 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 C4ECE3A6853 for ; Wed, 21 Jan 2009 22:08:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 nlUEb5HpIWXW for ; Wed, 21 Jan 2009 22:08:32 -0800 (PST) Received: from ns2.nict.go.jp (ns2.nict.go.jp [133.243.3.2]) by core3.amsl.com (Postfix) with ESMTP id 1CA393A6452 for ; Wed, 21 Jan 2009 22:08:31 -0800 (PST) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id n0M64TFe020225 for ; Thu, 22 Jan 2009 15:04:29 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id n0M64TZ7019171 for ; Thu, 22 Jan 2009 15:04:29 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id n0M64Ten019166 for ; Thu, 22 Jan 2009 15:04:29 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by localhost.nict.go.jp (Postfix) with ESMTP id 578336F36 for ; Thu, 22 Jan 2009 15:04:29 +0900 (JST) Received: from [133.243.146.164] (5gou2f-dhcp04.nict.go.jp [133.243.146.164]) by mail2.nict.go.jp (Postfix) with ESMTP id 2BBE46F16 for ; Thu, 22 Jan 2009 15:04:29 +0900 (JST) Message-ID: <49780C66.7010108@nict.go.jp> Date: Thu, 22 Jan 2009 15:04:22 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "dime@ietf.org" X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Subject: [Dime] [ERP] Review and comments, synthesis 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi all, Here is my review of draft-ietf-dime-erp-00, in [Seb] tags. I've also copied some pending comments from other people that have not been addressed yet, AFAIK. BTW, about the reference to RFC3588 or RFC3588bis, according to the Milestones of the WG, the rfc3588bis is due in January 2009 and ERP document is due in May 2009, so I think it makes sense to update the content to the new revision of base protocol (will affect the reference to the document and simplify the AVP description). Do you agree? In short, my main comments are (some are detailed later in the review): - we should add more details on deployment (ER entities on the route of EAP exchanges, ...) and detail interoperability issues (if one or more entity does not support ERP). This document uses the following entities: Peer, ER authenticator, ER local server, ER home server, EAP local server (not directly but it may be involved in some cases), EAP home server. More figures are definitely needed to make the whole thing understandable... - I think grouped AVPs could be used to simplify handling on the ER entities. I also think AVPs should be renamed to ERP-*. - ER home server and EAP home server are mixed in this document, clarification is needed. - In case of implicit ERP bootstrapping, the peer is not notified that ERP was already bootstrapped. How to prevent ERP bootstraping exchange to be initiated? (maybe sending a new AVP between ER local server and authenticator? FFS ;) ). In a general maneer, I think that implicit bootstrapping of ERP adds more problems than it solves (for example, it will occur even if the peer does not support ERP). I think we could simply remove it and mandate explicit bootstrapping for ERP. - We should also consider the simpler case where the peer is in its home network. New AVPs are not used, but some description is needed anyway. - Everytime I write "we should", please read "I can provide a draft for this, if you agree this is needed"... Abstract 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 any EAP/ERP authenticator. [Julien] I'm wondering if we should note that the authenticator may be ERP-aware. [Seb] I agree that only ERP-aware authenticator can be used in Diameter ERP application. A pure EAP-passthrough NAS would not be able (to be verified, though) to extract the content of KeyName-NAI to set the User-Name of the new message, which is mandatory for routing of the ERP message. This should be written in this document. This document specifies Diameter support for ERP. The Diameter EAP application is re-used for encapsulating the newly defined EAP codes specified in the ERP specification. Additionally, this document also defines specific Diameter processing rules relevant to ERP. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Diameter Support for ERP . . . . . . . . . . . . . . . . . . . 3 3.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 3 3.2. DSRK Request and Delivery . . . . . . . . . . . . . . . . . 4 4. Command Codes . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Attribute Value Pair Definitions . . . . . . . . . . . . . . . 5 5.1. EAP-DSRK-Request AVP . . . . . . . . . . . . . . . . . . . 5 5.2. EAP-DSRK AVP . . . . . . . . . . . . . . . . . . . . . . . 5 5.3. EAP-DSRK-Name AVP . . . . . . . . . . . . . . . . . . . . . 5 5.4. EAP-DSRK-Lifetime AVP . . . . . . . . . . . . . . . . . . . 5 6. AVP Occurrence Table . . . . . . . . . . . . . . . . . . . . . 5 7. AVP Flag Rules . . . . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 11.1. Normative References . . . . . . . . . . . . . . . . . . . 7 11.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction RFC 4072 [1] specifies a Diameter application that carries EAP packets between a Diameter client and the Diameter Server/EAP server. [Seb] I think some people will not like the "Diameter client" and "Diameter Server" phrasing... Maybe "EAP authenticator / Diameter EAP client" and "EAP server / Diameter EAP server" would be more precise? [Seb] (editorial) In some other RFC, such as 5296, there are links pointing to the full text of the RFC when a reference appears in the text (in html version), and sometimes also the title of the RFC is copied in the title of the link, such as in 5295. I think it is very convenient, but I don't know if it's a mod in the xml2rfc tool or changes in the xml file. Is it possible to do the same thing here Julien? RFC 5296 [2] defines the EAP Re-authentication Protocol to allow faster re-authentication of a previously authenticated peer. In ERP, a peer is authenticated by the network thanks to keying [Seb] I am not sure about this, but I think that ERP provides mutual authentication of the peer and the network by proof of possession of material derived from a previous mutual authentication (in full EAP exchange). Or does this depend on the EAP method that is used? Anyway, it is probably not important for this document. material obtained during a previous EAP exchange. This keying material is derived from the Extended Master Session Key (EMSK) as defined in the RFC 5295 [5]. To accomplish the EAP reauthentication functionality, ERP defines two new EAP codes - EAP-Initiate and EAP Finish. This document specifies the reuse of Diameter EAP Application to carry these new EAP messages. ERP is executed between the peer and a server located either in the peer's home domain or in the local domain visited by the peer. In the latter case, a Domain Specific Root Key (DSRK) is derived from the EMSK, as defined in the RFC 5295 [5], and is provided by the Home EAP server to the local domain server. [Seb] In my understanding of the ERP mechanism, the home ER server and home EAP server may be different entities (with some out-of-band mechanism to transport the usage-specific keys, such as defined in draft-ietf-hokey-key-mgm-04). I think we should refer to Home ER server here. This server would anyway have to be on the path of the full EAP authentication messages, because of Diameter routing mechanism based on message's application, for ERP to work, since we re-use EAP application number. For that purpose, this document specifies the transport of the DSRK using the Diameter EAP Application. [Seb] What happens if there is no local ER server, or the peer is in its home network and uses ERP? I think the scope of this document is broader than described here. I believe text should be added in the document to describe this situation. I can provide a draft text, if you agree that this is missing. [Seb] By the way, is there a difference between "realm" and "domain"? Sorry for the non-native English speaker's question ^^'. 2. Assumptions This document defines only additional optional AVPs for usage with the Diameter EAP application. This document does not define a new Diameter application and therefore a new Application ID is not required, as described in the Diameter Base protocol [3]. In this document, when EAP re-authentication is performed in the domain visited by the peer, it is assumed that the local ER server is co-located with a Diameter agent in the visited domain present in the path of the full EAP exchange. (Editor's Note: it is not clear at the time of writing wether this document must require this local AAA server to be on the path.) [Seb] I think every previous review of this document had remarks on this part. I'll try to clarify according to my understanding. First of all, this assumption has to be made due to the re-use of Diameter EAP application. An alternative solution using a different application ID for ERP would remove this constraint but adds great complexity and several exchanges to distribute the keys to the ER entities. I personally believe that using the same application id is better, since implementing ERP functions on top of EAP (i.e. colocate ER and EAP servers) is easier than having different boxes for that. - For ERP implicit or explicit bootstrapping to success, the local ER server and home ER server *must* be on the path of full EAP authentication (with home EAP server). - In addition, once ERP is bootstrapped, the local ER server *must* be on the path of a (virtual) full EAP authentication with local EAP server, since the User-Name AVP contains the local domain name (EMSKname@localdomain). - What happens if one of these condition is not met is not trivial. I think in most cases it results in the ERP message not answered, timed out, and a normal full EAP authentication follow. I think a new (3.3 ?) section is needed to describe interoperability and deployment issues such as: what happens if the assumption is not met, or if one of the entities does not support ERP functions. See my note later in this review. Addressing Jouni's comment, we should also consider the current work on Diameter routing. Especially, with Diameter routing as described in Base Protocol, the ER local server may be in the path of first EAP exchange (and add the EAP-DSRK-Request AVP) but not in the next round(s) of a multi-round EAP exchange, and therefore unable to extract the EAP-DSRK from the final Success notification, which breaks a strong requirement of RFC5295. Of course, the ER server could detect that the local ER server was not in the path (thanks to Route-Record AVPs, and provided that this ER home server knows which one is the ER local server) of the last DER and not add this keying material. 3. Diameter Support for ERP 3.1. Protocol Overview The Diameter EAP Application is used to transport ERP messages between the NAS (authenticator) and an authentication server (ER server). In ERP, the peer sends an EAP-Initiate/Re-auth message to the ER server via the authenticator. Alternatively, the NAS may send an EAP-Initiate/Re-auth-Start message to the peer to trigger the start of ERP. In this case, the peer responds with an EAP-Initiate/Re-auth message to the NAS. The general guidelines for encapsulating EAP messages in Diameter from RFC 4072 [1] apply to the new EAP codes defined for ERP as well. The EAP-Initiate/Re-auth message is encapsulated in an EAP-Payload AVP of a Diameter EAP Request (DER) message by the NAS and sent to the Diameter server. The NAS MUST copy the contents of the value field of the 'KeyName-NAI' TLV or the 'peer-id' TLV (when the former is not present) of the EAP Initiate/Re-auth message into a User-Name AVP of the Diameter EAP-Request. [Seb] I can't find a case where 'KeyName-NAI' TLV would not be in the ERP message. I think the second part of this sentence should be removed. If the peer does not have a valid key, it will not initiate ERP at all. The ER server processes the EAP-Initiate/Re-auth message in accordance with [2] and responds with an EAP-Finish/Re-auth message. The Diameter server MUST encapsulate the EAP-Finish/Re-auth message within an EAP-Payload AVP of a Diameter EAP Answer message. In an EAP re-authentication successful case, an EAP-Master-Session-Key AVP is included in the Diameter EAP Answer (DEA) message that contains the Re-authentication Master Session Key (rMSK). The Diameter Result-Code SHOULD be a success Result-Code. In an EAP re- authentication failure case, the Diameter Result-Code AVP of the a Diameter EAP Answer (DEA) message SHOULD be a failure Result-Code and no EAP-Master-Session-Key AVP is present. (Editor's Note: it is FFS if a SHOULD is sufficient) (2nd Editor's Note: add a figure ?) [Seb] I also agree that MUST conditions for the result-codes seems more logical here. It should also be noted that if the EAP server does not support ERP functions it will return a Diameter error, according to RFC4072: "A Diameter server receiving an EAP-Payload AVP that it does not understand SHOULD determine whether the error is fatal or non-fatal based on the EAP Type. A Diameter server determining that a fatal error has occurred MUST send a Diameter-EAP-Answer with a failure Result-Code and an EAP-Payload AVP encapsulating an EAP Failure packet. A Diameter server determining that a non-fatal error has occurred MUST send a Diameter-EAP-Answer with DIAMETER_MULTI_ROUND_AUTH Result-Code, but no EAP-Payload AVP." [Seb] I think a figure is not sufficient here, we need to develop the different situations (peer in local domain, no local ER server, ...), each with a figure. This would rather be a separate section, IMHO. I can provide a draft if you agree. 3.2. DSRK Request and Delivery A local ER server, collocated with a Diameter proxy in the domain visited by the peer, may request a DSRK from the home EAP/ERP server, either in the initial EAP exchange (implicit bootstrapping) or in an ERP bootstrapping exchange (explicit bootstrapping). This is done by including the EAP-DSRK-Request AVP in the Diameter EAP Request (DER) message. The EAP-DSRK-Request AVP contains the domain or server [Seb] "domain or server" => see my note on this topic later in this mail. It should not be "or" here anyway. identity required to derive the DSRK. In successful case, the DSRK is carried by the EAP-DSRK AVP in the Diameter EAP Answer (DEA) message. Along with the EAP-DSRK AVP, an EAP-DSRK-Name AVP MUST be used to send the DSRK's keyname and an EAP- [Seb] It's not the DSRK's keyname, but the EMSKname. I think the name of this AVP is error-prone, we should rename it (see a proposal later in this mail). DSRK-Lifetime AVP MUST be used to send the DSRK's lifetime. (Editor's Note: add a figure ?). [Seb] I think a new section "Interoperability" is needed to examine cases where one of the element does not support ERP functions. [Seb] I think also a new section "Deployment" is needed, to detail the assumptions: ER servers in the path of EAP exchanges, authenticators capable of advertizing the domain name that must match the ER local server's, ... Figures for all the different situations would be very useful to clarify for everbody. Cases to consider: The peer has a valid EMSK? The peer knows the local domain name? A local ER server is present, and bootstrapped for this EAP session? (Actually about this last point, how does the peer know this information, if implicit bootstrapping was used???) I can provide draft text for these sections, if you think they are needed. 4. Command Codes This document re-uses the EAP application commands [1] and does not define new command codes. [LM] this section is not required as there is nothing specific for ERP. We should skip it. [Seb] I agree, unless there is a kind of standard template for Diameter-related RFCs? 5. Attribute Value Pair Definitions This section defines new AVPs for the ERP support within Diameter EAP Application. [Seb] For all the following new AVPs, I think naming convention ERP-* instead of EAP-* would be better (ERP-DSRK-Request, ...). Any thoughts? 5.1. EAP-DSRK-Request AVP [Seb] It has not been discussed (AFAIK) what should happen if several ER servers are in the path of the full EAP authentication. Can this AVP appear several times (if we have hierarchy of re-authentication domains, for example?) I think the answer is no, since the domain name advertized by the authenticator must match the ER server's domain name. Maybe it should be written somewhere that the ER server adds this AVP only if no such AVP is already in the message? The EAP-DSRK Request AVP (AVP Code TBD) is of type DiameterIdentity. This AVP fulfills two purposes: first, it indicates that a ERP server is located in the local domain that is willing to play the role of an ERP server for a particular session. Second, it conveys information about the domain name to the Diameter/EAP/ERP server. (Editor's Note: it is FFS if DiameterIdentity is the correct type). [Seb] Actually both information may be needed, the local ER server name (for authorization purpose on the home server for example, and Autorization Indication TLV in ERP message) and the domain name (can this domain-name be different from the Origin-Realm?). Therefore I think a Grouped AVP would be better, containing two sub-AVP for the Domain name and ER server name. [Seb] By the way, about discussions if DiameterIdentity type is suitable for a domain name, I want to highlight that the Origin-Realm AVP (for example) defined in Diameter Base Protocol is also of DiameterIdentity type, and does not contain a FQDN, AFAIU. [JiK] What happens if Diameter server does not understand this AVP but still returns OK for the full EAP authentication? [Seb] In that case, the DSRK will not be included in the last message of the round of exchanges, and the ER local server will know that home domain does not do ERP, AFAIU. Do you think a note about this is needed? 5.2. EAP-DSRK AVP [Seb] Since the following three AVP are always sent together and parsed together, I believe a Grouped AVP would be nice here. It adds few overhead and makes parsing of the message on the ER server faster. Any opinion? The EAP-DSRK AVP (AVP Code TBD) is of type OctetString. This AVP contains keying material to be used by the visited domain (i.e. the DSRK). Exactly how this keying material is derived is beyond the scope of this document. [Seb] Maybe reference to the ERP's RFC would be better here, such as "Exactly how this keying material is derived is described in RFC 5295 and RFC 5296" ? [Seb] It may also be worth noting that this AVP MUST be removed by the ER local server that added the EAP-DSRK-Request on the first EAP exchange (might be several exchanges earlier, leading to routing constaints...) or ERP bootstrap exchange? 5.3. EAP-DSRK-Name AVP The EAP-DSRK-Name AVP (AVP Code TBD) is of type OctetString. This AVP contains the EMSKname which identifies the keying material. How [Seb] Because the AVP contains the EMSKname, it may be better to rename it to EAP-EMSK-Name (or ERP-EMSK-Name)? Because RFC5295 also defines how to derive DSRKName, so it may be error-prone here. this name is derived is beyond the scope of this document and defined in [5]. [pending JiK's] if this is a plain text name, use UTF8String. Otherwise OctetString is OK. AFter reading a bit of the ERP draft it says there that the 64 bits username part of the NAI is encoded in hexadecimal. In 5.3.2 of ERP draft it is says the username takes up to 128 octets and in 5.3.3 it is though said the username takes up to 16 octets. So I am a bit confused what the username part actually keeps inside in this AVP and how it is encoded. 5.4. EAP-DSRK-Lifetime AVP The EAP-DSRK-Lifetime AVP (AVP Code TBD) is of type Unsigned64 and contains the DSRK lifetime in seconds. (Editor's Note: it is FFS if Unsigned32 is not sufficient). (Editor's Note: it is FFS default value) [Seb] There is also a pending comment from Jouni about the "0" value. Does "default value" refer to this value of 0, or to the case where the AVP is not included? 6. AVP Occurrence Table The following table lists the AVPs that may optionally be present in the DER and DEA commands [1]. +---------------+ | Command-Code | +-+-----+-----+-+ Attribute Name | DER | DEA | -------------------------------|-----+-----+ EAP-DSRK-Request | 0-1 | 0 | EAP-DSRK | 0 | 0-1 | EAP-DSRK-Name | 0 | 0-1 | EAP-DSRK-Lifetime | 0 | 0-1 | +-----+-----+ Figure 1: DER and DEA Commands AVP Table When the EAP-DSRK AVP is present in the DEA then the EAP-DSRK-Name and the EAP-DSRK-Lifetime MUST also be present. 7. AVP Flag Rules The following table describes the Diameter AVPs, their AVP Code values, types, possible flag values, and whether the AVP MAY be encrypted. The Diameter base [3] specifies the AVP Flag rules for AVPs in Section 4.5. +---------------------+ | AVP Flag Rules | +----+-----+----+-----+----+ AVP Section | | |SHLD|MUST | | Attribute Name Code Defined Data Type |MUST| MAY |NOT |NOT |Encr| ------------------------------------------+----+-----+----+-----+----+ EAP-DSRK-Request TBD 4.7.1 DiamIdent | | P | | V,M | Y | EAP-DSRK TBD 4.7.2 OctetString| | P | | V,M | Y | EAP-DSRK-Name TBD 4.7.3 OctetString| | P | | V,M | Y | EAP-DSRK-Lifetime TBD 4.7.4 Unsigned64 | | P | | V,M | Y | ------------------------------------------+----+-----+----+-----+----+ Due to space constraints, the short form DiamIdent is used to represent DiameterIdentity. Figure 2: AVP Flag Rules Table 8. Security Considerations The security considerations specified in RFC 4072 [1], and RFC 3588 [3] are applicable to this document. EAP channel bindings may be necessary to ensure that the Diameter client and the server are in sync regarding the key Requesting Entity's Identity. Specifically, the Requesting Entity advertises its identity through the EAP lower layer, and the user or the EAP peer communicates that identity to the EAP server (and the EAP server communicates that identity to the Diameter server) via the EAP method for user/peer to server verification of the Requesting Entity's Identity. [Seb] I can't see what the threat is here, since the key is given to the authenticator by the AAA proxy (who identifies and authorizes the peer to act as an authenticator, according to rfc3588) and on the peer's side it's derived locally from the EMSK. I may be missing the point, sorry for this... 9. IANA Considerations This document requires IANA registration of the following new AVPs to the AVP registry established by RFC 3588 [3]: o EAP-DSRK-Request o EAP-DSRK o EAP-DSRK-Name o EAP-DSRK-Lifetime 10. Acknowledgments Vidya Narayanan reviewed a rough draft version and found some errors. Many thanks for her input. 11. References 11.1. Normative References [Seb] I am not sure the difference between "Normative" and "Informative" but I think that the RFC defining the rules for key derivation in ERP, 5295, should be in Normative section? [1] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005. [2] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- authentication Protocol (ERP)", RFC 5296, August 2008. [3] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 11.2. Informative References [5] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, "Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)", RFC 5295, August 2008. [6] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. Thank you for reading this veeeeery long mail ^^. 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 dime-bounces@ietf.org Thu Jan 22 07:55:00 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AE443A6B54; Thu, 22 Jan 2009 07:55:00 -0800 (PST) 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 658A73A67E4 for ; Thu, 22 Jan 2009 07:54:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, J_CHICKENPOX_52=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 wy4KQniZaCHG for ; Thu, 22 Jan 2009 07:54:52 -0800 (PST) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 8842928C220 for ; Thu, 22 Jan 2009 07:54:45 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,307,1231131600"; d="scan'208";a="149482738" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 22 Jan 2009 10:54:27 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Jan 2009 10:54:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 22 Jan 2009 16:53:58 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Review of draft-ietf-dime-qos-attributes-09.txt Thread-Index: Acl25+4LwiZpp+s/TXmZN/DuYxImPgBkgxuAAIAkfzAAi3S9UA== References: <496E673C.10103@tari.toshiba.com><01f501c9787b$e993fc30$7e4fa20a@nsnintra.net> From: "Romascanu, Dan (Dan)" To: "Mark Jones" , "Hannes Tschofenig" , "Victor Fajardo" , "Tschofenig, Hannes (NSN - FI/Espoo)" Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-ietf-dime-qos-attributes-09.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Any projection about when a new version will be available? Will this version be ready for IESG review? Also pay attention to the versions number. You are discussing about draft-09 in this thread, but the latest issued version in the repository is 08. Thanks and Regards, Dan > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > Behalf Of Mark Jones > Sent: Monday, January 19, 2009 11:47 PM > To: Hannes Tschofenig; 'Victor Fajardo'; Tschofenig, Hannes > (NSN - FI/Espoo) > Cc: dime@ietf.org > Subject: Re: [Dime] Review of draft-ietf-dime-qos-attributes-09.txt > > Thanks for the detailed review Victor. Comments inline... > > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: January 17, 2009 03:17 > > To: 'Victor Fajardo'; Tschofenig, Hannes (NSN - FI/Espoo); > Mark Jones > > Cc: dime@ietf.org > > Subject: RE: [Dime] Review of draft-ietf-dime-qos-attributes-09.txt > > > > Hi Victor, > > > > Thanks for the detailed review. > > A few comments inline > > > > > > 4.1.2. Classifier-ID AVP > > > > The Classifier-ID AVP (AVP Code TBD) is of type OctetString and > > uniquely identifies the classifier. Each application > will define > > the > > uniqueness scope of this identifier, e.g. unique per terminal or > > globally unique. > > > > [Victor: What does 'globally unique' mean ? Does it mean globally > > unique within the context of the application ? If so, would it be > > better to say: > > unique within app AND terminal, app AND admin domain, ...] > > > > [hannes] This is a very good question. I have to figure out > what type > > of uniqueness we demand here. > > > > [mj] We're just giving examples here but I agree that > 'globally unique' is ambiguous. The application which uses > the Classifier AVPs must specify the uniqueness scope. I > suggest we change the examples to "unique per Managed > Terminal or unique per Classifying Entity". > > > > > From-Spec ::= < AVP Header: XXX > > > * [ IP-Address ] > > * [ IP-Address-Range ] > > * [ IP-Address-Mask ] > > * [ MAC-Address ] > > * [ MAC-Address-Mask] > > * [ EUI64-Address ] > > * [ EUI64-Address-Mask] > > * [ Port ] > > * [ Port-Range ] > > [ Negated ] > > [ Use-Assigned-Address ] > > * [ AVP ] > > > > [Victor: It seems everything is optional ... what happens if > > this is empty ? > > same for To-Spec] > > > > [hannes] If the From-Spec is empty then this is equivalent to > > the From-Spec > > AVP not being there at all. > > > > [mj] Agreed. > > > > > 4.1.7. Source and Destination AVPs > > > > For packet classification the contents of the From-Spec > and To-Spec > > can contain the following AVPs. > > > > [Victor: what AVPs ?] > > > > [mj] "..can contain the AVPs described in the following subsections." > > > By combining several of these AVPs within a From-Spec or > > To-Spec AVP > > and using more than one From-Spec or To-Spec AVP in the > Classifier > > AVP, one can express many different types of address pools. > > > > [Victor: I must admit, I cannot understand what this section > > is implying :). > > Is it attempting to say that a match must be From-Spec AND > > To-Spec if both > > are present ? or some other combination ?] > > > > [hannes] I pushed this ball to Mark to respond. > > > > [mj] This was a motherhood statement from the original > classifier draft and I think it can be removed now. I've > since (hopefully) explained the interaction of multiple > From-Spec/To-Spec AVPs in sections 4.1.5 and 4.1.6. > > > > > 4.1.7.14. Port AVP > > > > The Port AVP (AVP Code TBD) is of type Integer32 in the > > range of 0 to > > 65535 and specifies the TCP or UDP port number to match. > > > > [Victor: This is the first time TCP and UDP is mentioned, all > > of the above > > text implies a sort of protocol generality. Should it be the > > same here ? > > i.e. I can have SCTP ports also] > > > > [hannes] generalized it. > > > > [mj] Good point Victor. Thanks Hannes. > > > 4.1.7.18. Use-Assigned-Address AVP > > > > In some scenarios, the AAA does not know the IP address > assigned to > > the Managed Terminal at the time that the Classifier is > sent to the > > > > > > > > Korhonen, et al. Expires June 21, 2009 > > [Page 14] > > > > Internet-Draft QoS Attributes for Diameter > > December 2008 > > > > > > Classifying Entity. The Use-Assigned-Address AVP (AVP > Code TBD) is > > of type Enumerated containing the values of True or False. When > > present and set to True, it represents the IP address > > assigned to the > > Managed Terminal. > > > > > > Value | Name > > ------+-------- > > 0 | False > > 1 | True > > > > [Victor: Are we talking the classifying entity dynamically > adding the > > managed terminals IP into this classifier entry ?, i.e. > > everytime a new > > terminal sends packets then a new entry is added with a new > > From-Spec ? If > > so, would'nt this be equivalent to a missing From-Spec for IN in the > > Classifier ?] > > > > [hannes] This is just a way to consider the case where the > > AAA sends some > > filters but the IP address of the terminal is not yet > assigned to it. > > Hence, you have to put a placeholder there. > > > > [mj] Agreed. This is a very useful where address allocation > happens after policy delivery. > > > > > > > 4.1.8.18. VLAN-ID-Range AVP > > > > The VLAN-ID-Range AVP (AVP Code TBD) is of type Grouped > > and specifies > > the VLAN range to match. VLAN identities are either > specified by a > > single VLAN-ID according to [IEEE802.1Q] or by a combination of > > Customer and Service VLAN-IDs according to [IEEE802.1ad]. > > > > The single VLAN-ID is represented by the C-VID-Start and > C-VID-End > > AVPs and the S-VID-Start and S-VID-End AVPs SHALL be > > ommitted in this > > case. > > [Victor: What is being omitted ?] > > > > If the VLAN-ID-Range AVP is omitted from the Classifier, then > > comparison of the VLAN identity of the packet is irrelevant. > > > > > > VLAN-ID-Range ::= < AVP Header: XXX > > > [ S-VID-Start ] > > [ S-VID-End ] > > [ C-VID-Start ] > > [ C-VID-End ] > > * [ AVP ] > > > > When the S-VID-Start AVP is present but the S-VID-End AVP > > is absent, > > the S-VID-Start AVP value MUST equal the value of the > IEEE 802.1ad > > S-VID bits specified in [IEEE802.1ad] for a successful match. > > > > [Victor: Is this new sematic necessary ? The other range > > features does not > > have this semantic. They use only start and end. If an exact > > match is needed > > then they use start == end] > > > > [hannes] Mayutan is going to look at this section to align > > the semantic with > > the other classifiers > > > > 4.2.1. Time-Of-Day-Condition AVP > > > > The Time-Of-Day-Condition AVP (AVP Code TBD) is of type > Grouped and > > specifies one or more time windows. > > > > > > Time-Of-Day-Condition ::= < AVP Header: XXX > > > [ Time-Of-Day-Start ] > > [ Time-Of-Day-End ] > > [ Day-Of-Week-Mask ] > > [ Day-Of-Month-Mask ] > > [ Month-Of-Year-Mask ] > > [ Absolute-Start-Time ] > > [ Absolute-End-Time ] > > [ Timezone-Flag ] > > * [ AVP ] > > > > [Victor: We should mention that if most of the AVPs above are > > present, their > > evaluation criteria or values are allowed to overlap] > > > > [hannes] Not sure what you mean. If you specify, for example, > > Time-of-Day > > and Month-of-Year then both need to match. > > Nevertheless, Mark is going to review again the rule matching > > algorithm. > > > > 5.2.5. Rule-Precedence AVP > > > > The Rule-Precedence AVP (AVP Code TBD) is of type Unsigned32 and > > specifies the execution order of the rules expressed in > > the Rule-Set > > AVP. Rules with equal precedence MAY be executed in parallel if > > > > [Victor: If run in parallel, what happens if both rules have > > successful > > matches but different actions ?] > > > > [hannes] Mark is going to look at this issue. This subject is > > about conflict > > resolution. The precedence would ensure that this actually > > never happens. > > Hence, you cannot give two rules the same precedence. Mark > > has to clarify > > this issue. > > > > [mj] Good question. I'd assumed that the Conditions would be > mutually exclusive for Rules with equal precedence so the > Actions would be operating on different packets. I can state > this assumption here or we can forbid rules with equal > precedence. Any preferences? > > > Ciao > > Hannes > > > > >-----Original Message----- > > >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > > >Behalf Of Victor Fajardo > > >Sent: 15 January, 2009 00:29 > > >To: hannes.tschofenig@nsn.com; Mark Jones > > >Cc: dime@ietf.org > > >Subject: [Dime] Review of draft-ietf-dime-qos-attributes-09.txt > > > > > >Hi Hannes/Mark, > > > > > >Attached is my review of the qos-attribute draft. My comments > > >are inlined under "[Victor: ...". > > > > > >best regards, > > >victor > > > > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 22 08:10:09 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9C503A6A44; Thu, 22 Jan 2009 08:10:08 -0800 (PST) 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 EF65E3A6B73 for ; Thu, 22 Jan 2009 08:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.254 X-Spam-Level: X-Spam-Status: No, score=-3.254 tagged_above=-999 required=5 tests=[AWL=-1.255, BAYES_00=-2.599, J_CHICKENPOX_52=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 r8G6aKFkVIt3 for ; Thu, 22 Jan 2009 08:10:05 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 4319D3A6A2E for ; Thu, 22 Jan 2009 08:10:03 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n0MG9cSE018154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 22 Jan 2009 17:09:38 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n0MG9avt011405; Thu, 22 Jan 2009 17:09:37 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Jan 2009 17:09:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 22 Jan 2009 18:10:14 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Review of draft-ietf-dime-qos-attributes-09.txt Thread-Index: Acl25+4LwiZpp+s/TXmZN/DuYxImPgBkgxuAAIAkfzAAi3S9UAAAudCw References: <496E673C.10103@tari.toshiba.com><01f501c9787b$e993fc30$7e4fa20a@nsnintra.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Romascanu, Dan (Dan)" , "Mark Jones" , "Hannes Tschofenig" , "Victor Fajardo" X-OriginalArrivalTime: 22 Jan 2009 16:09:36.0815 (UTC) FILETIME=[D2697BF0:01C97CAB] Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-ietf-dime-qos-attributes-09.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Dan, >Any projection about when a new version will be available? >Will this version be ready for IESG review? We have a version ready for submission and we are going through a couple of final reviews. The idea was that it would then be ready for IESG review. > >Also pay attention to the versions number. You are discussing about >draft-09 in this thread, but the latest issued version in the >repository is 08. Hmm. I thought we submitted the -09 version. > >Thanks and Regards, > Ciao Hannes >Dan > > >> -----Original Message----- >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf >> Of Mark Jones >> Sent: Monday, January 19, 2009 11:47 PM >> To: Hannes Tschofenig; 'Victor Fajardo'; Tschofenig, Hannes (NSN - >> FI/Espoo) >> Cc: dime@ietf.org >> Subject: Re: [Dime] Review of draft-ietf-dime-qos-attributes-09.txt >> >> Thanks for the detailed review Victor. Comments inline... >> >> > -----Original Message----- >> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> > Sent: January 17, 2009 03:17 >> > To: 'Victor Fajardo'; Tschofenig, Hannes (NSN - FI/Espoo); >> Mark Jones >> > Cc: dime@ietf.org >> > Subject: RE: [Dime] Review of draft-ietf-dime-qos-attributes-09.txt >> > >> > Hi Victor, >> > >> > Thanks for the detailed review. >> > A few comments inline >> > >> > >> > 4.1.2. Classifier-ID AVP >> > >> > The Classifier-ID AVP (AVP Code TBD) is of type OctetString and >> > uniquely identifies the classifier. Each application >> will define >> > the >> > uniqueness scope of this identifier, e.g. unique per terminal or >> > globally unique. >> > >> > [Victor: What does 'globally unique' mean ? Does it mean globally >> > unique within the context of the application ? If so, would it be >> > better to say: >> > unique within app AND terminal, app AND admin domain, ...] >> > >> > [hannes] This is a very good question. I have to figure out >> what type >> > of uniqueness we demand here. >> > >> >> [mj] We're just giving examples here but I agree that 'globally >> unique' is ambiguous. The application which uses the Classifier AVPs >> must specify the uniqueness scope. I suggest we change the >examples to >> "unique per Managed Terminal or unique per Classifying Entity". >> >> > >> > From-Spec ::= < AVP Header: XXX > >> > * [ IP-Address ] >> > * [ IP-Address-Range ] >> > * [ IP-Address-Mask ] >> > * [ MAC-Address ] >> > * [ MAC-Address-Mask] >> > * [ EUI64-Address ] >> > * [ EUI64-Address-Mask] >> > * [ Port ] >> > * [ Port-Range ] >> > [ Negated ] >> > [ Use-Assigned-Address ] >> > * [ AVP ] >> > >> > [Victor: It seems everything is optional ... what happens >if this is >> > empty ? >> > same for To-Spec] >> > >> > [hannes] If the From-Spec is empty then this is equivalent to the >> > From-Spec AVP not being there at all. >> > >> >> [mj] Agreed. >> >> > >> > 4.1.7. Source and Destination AVPs >> > >> > For packet classification the contents of the From-Spec >> and To-Spec >> > can contain the following AVPs. >> > >> > [Victor: what AVPs ?] >> > >> >> [mj] "..can contain the AVPs described in the following subsections." >> >> > By combining several of these AVPs within a From-Spec or >> > To-Spec AVP >> > and using more than one From-Spec or To-Spec AVP in the >> Classifier >> > AVP, one can express many different types of address pools. >> > >> > [Victor: I must admit, I cannot understand what this section >> > is implying :). >> > Is it attempting to say that a match must be From-Spec AND >> > To-Spec if both >> > are present ? or some other combination ?] >> > >> > [hannes] I pushed this ball to Mark to respond. >> > >> >> [mj] This was a motherhood statement from the original >> classifier draft and I think it can be removed now. I've >> since (hopefully) explained the interaction of multiple >> From-Spec/To-Spec AVPs in sections 4.1.5 and 4.1.6. >> >> > >> > 4.1.7.14. Port AVP >> > >> > The Port AVP (AVP Code TBD) is of type Integer32 in the >> > range of 0 to >> > 65535 and specifies the TCP or UDP port number to match. >> > >> > [Victor: This is the first time TCP and UDP is mentioned, all >> > of the above >> > text implies a sort of protocol generality. Should it be the >> > same here ? >> > i.e. I can have SCTP ports also] >> > >> > [hannes] generalized it. >> > >> >> [mj] Good point Victor. Thanks Hannes. >> >> > 4.1.7.18. Use-Assigned-Address AVP >> > >> > In some scenarios, the AAA does not know the IP address >> assigned to >> > the Managed Terminal at the time that the Classifier is >> sent to the >> > >> > >> > >> > Korhonen, et al. Expires June 21, 2009 >> > [Page 14] >> > >> > Internet-Draft QoS Attributes for Diameter >> > December 2008 >> > >> > >> > Classifying Entity. The Use-Assigned-Address AVP (AVP >> Code TBD) is >> > of type Enumerated containing the values of True or False. When >> > present and set to True, it represents the IP address >> > assigned to the >> > Managed Terminal. >> > >> > >> > Value | Name >> > ------+-------- >> > 0 | False >> > 1 | True >> > >> > [Victor: Are we talking the classifying entity dynamically >> adding the >> > managed terminals IP into this classifier entry ?, i.e. >> > everytime a new >> > terminal sends packets then a new entry is added with a new >> > From-Spec ? If >> > so, would'nt this be equivalent to a missing From-Spec for >IN in the >> > Classifier ?] >> > >> > [hannes] This is just a way to consider the case where the >> > AAA sends some >> > filters but the IP address of the terminal is not yet >> assigned to it. >> > Hence, you have to put a placeholder there. >> > >> >> [mj] Agreed. This is a very useful where address allocation >> happens after policy delivery. >> >> > >> > >> > 4.1.8.18. VLAN-ID-Range AVP >> > >> > The VLAN-ID-Range AVP (AVP Code TBD) is of type Grouped >> > and specifies >> > the VLAN range to match. VLAN identities are either >> specified by a >> > single VLAN-ID according to [IEEE802.1Q] or by a combination of >> > Customer and Service VLAN-IDs according to [IEEE802.1ad]. >> > >> > The single VLAN-ID is represented by the C-VID-Start and >> C-VID-End >> > AVPs and the S-VID-Start and S-VID-End AVPs SHALL be >> > ommitted in this >> > case. >> > [Victor: What is being omitted ?] >> > >> > If the VLAN-ID-Range AVP is omitted from the Classifier, then >> > comparison of the VLAN identity of the packet is irrelevant. >> > >> > >> > VLAN-ID-Range ::= < AVP Header: XXX > >> > [ S-VID-Start ] >> > [ S-VID-End ] >> > [ C-VID-Start ] >> > [ C-VID-End ] >> > * [ AVP ] >> > >> > When the S-VID-Start AVP is present but the S-VID-End AVP >> > is absent, >> > the S-VID-Start AVP value MUST equal the value of the >> IEEE 802.1ad >> > S-VID bits specified in [IEEE802.1ad] for a successful match. >> > >> > [Victor: Is this new sematic necessary ? The other range >> > features does not >> > have this semantic. They use only start and end. If an exact >> > match is needed >> > then they use start == end] >> > >> > [hannes] Mayutan is going to look at this section to align >> > the semantic with >> > the other classifiers >> > >> > 4.2.1. Time-Of-Day-Condition AVP >> > >> > The Time-Of-Day-Condition AVP (AVP Code TBD) is of type >> Grouped and >> > specifies one or more time windows. >> > >> > >> > Time-Of-Day-Condition ::= < AVP Header: XXX > >> > [ Time-Of-Day-Start ] >> > [ Time-Of-Day-End ] >> > [ Day-Of-Week-Mask ] >> > [ Day-Of-Month-Mask ] >> > [ Month-Of-Year-Mask ] >> > [ Absolute-Start-Time ] >> > [ Absolute-End-Time ] >> > [ Timezone-Flag ] >> > * [ AVP ] >> > >> > [Victor: We should mention that if most of the AVPs above are >> > present, their >> > evaluation criteria or values are allowed to overlap] >> > >> > [hannes] Not sure what you mean. If you specify, for example, >> > Time-of-Day >> > and Month-of-Year then both need to match. >> > Nevertheless, Mark is going to review again the rule matching >> > algorithm. >> > >> > 5.2.5. Rule-Precedence AVP >> > >> > The Rule-Precedence AVP (AVP Code TBD) is of type Unsigned32 and >> > specifies the execution order of the rules expressed in >> > the Rule-Set >> > AVP. Rules with equal precedence MAY be executed in parallel if >> > >> > [Victor: If run in parallel, what happens if both rules have >> > successful >> > matches but different actions ?] >> > >> > [hannes] Mark is going to look at this issue. This subject is >> > about conflict >> > resolution. The precedence would ensure that this actually >> > never happens. >> > Hence, you cannot give two rules the same precedence. Mark >> > has to clarify >> > this issue. >> > >> >> [mj] Good question. I'd assumed that the Conditions would be >> mutually exclusive for Rules with equal precedence so the >> Actions would be operating on different packets. I can state >> this assumption here or we can forbid rules with equal >> precedence. Any preferences? >> >> > Ciao >> > Hannes >> > >> > >-----Original Message----- >> > >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >> > >Behalf Of Victor Fajardo >> > >Sent: 15 January, 2009 00:29 >> > >To: hannes.tschofenig@nsn.com; Mark Jones >> > >Cc: dime@ietf.org >> > >Subject: [Dime] Review of draft-ietf-dime-qos-attributes-09.txt >> > > >> > >Hi Hannes/Mark, >> > > >> > >Attached is my review of the qos-attribute draft. My comments >> > >are inlined under "[Victor: ...". >> > > >> > >best regards, >> > >victor >> > > >> > >> > >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 22 08:20:56 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D7313A69BC; Thu, 22 Jan 2009 08:20:56 -0800 (PST) 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 C1BA128C164 for ; Thu, 22 Jan 2009 08:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 P2V9LvLBg4Vf for ; Thu, 22 Jan 2009 08:20:47 -0800 (PST) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id C7D723A68B6 for ; Thu, 22 Jan 2009 08:20:47 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,307,1231131600"; d="scan'208";a="158692069" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 22 Jan 2009 11:20:30 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Jan 2009 11:20:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 22 Jan 2009 17:20:07 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Review of draft-ietf-dime-qos-attributes-09.txt Thread-Index: Acl25+4LwiZpp+s/TXmZN/DuYxImPgBkgxuAAIAkfzAAi3S9UAAAudCwAAA20sA= References: <496E673C.10103@tari.toshiba.com><01f501c9787b$e993fc30$7e4fa20a@nsnintra.net> From: "Romascanu, Dan (Dan)" To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "Mark Jones" , "Hannes Tschofenig" , "Victor Fajardo" Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-ietf-dime-qos-attributes-09.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org > -----Original Message----- > From: Tschofenig, Hannes (NSN - FI/Espoo) > Hmm. I thought we submitted the -09 version. > The current version in the repository is http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parameters-08.tx t Dan _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 22 10:17:39 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7FED3A68B0; Thu, 22 Jan 2009 10:17:39 -0800 (PST) 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 780783A6836 for ; Thu, 22 Jan 2009 10:17:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.551 X-Spam-Level: X-Spam-Status: No, score=-5.551 tagged_above=-999 required=5 tests=[AWL=1.048, 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 gO-T9HppCpKJ for ; Thu, 22 Jan 2009 10:17:32 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 6DE133A682D for ; Thu, 22 Jan 2009 10:17:32 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n0MIHEJl015139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 22 Jan 2009 19:17:14 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n0MIHDXJ013920 for ; Thu, 22 Jan 2009 19:17:14 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Jan 2009 19:17:13 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 22 Jan 2009 20:17:50 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DIME Virtual Interim Meeting Thread-Index: Acl8vbwyorKW/KgZTZWjS0FknA4C/A== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 22 Jan 2009 18:17:13.0774 (UTC) FILETIME=[A650B4E0:01C97CBD] Subject: [Dime] DIME Virtual Interim Meeting 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi all, to make some progress in DIME we would like to make a proposal for a virtual interim meeting. The concept of virtual interim meetings is floating around in the IETF and we thought it is a pretty good idea. Virtual interim meeting means that we are going to have a phone conference call for about ~2 hours to chat about working group items. So, unless there are strong objections we suggest that DIME holds a virtual interim meeting on 12th February 2009, 12:30pm EST for 2 hours. Proposed agenda: Discuss status and open issues of DIME working group items We will send an update within the next week on the technicalities of the call. Document authors, please make sure that you resubmit your drafts by the 5th February. Ciao Hannes & Dave _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 22 11:17:58 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07CA73A694E; Thu, 22 Jan 2009 11:17:58 -0800 (PST) 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 B2A283A694E for ; Thu, 22 Jan 2009 11:17:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.566 X-Spam-Level: X-Spam-Status: No, score=-5.566 tagged_above=-999 required=5 tests=[AWL=1.033, 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 CkwqyXxfOsXa for ; Thu, 22 Jan 2009 11:17:56 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id AB42D3A67D7 for ; Thu, 22 Jan 2009 11:17:55 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n0MJHbV2026955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 22 Jan 2009 20:17:37 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n0MJHbeM025010 for ; Thu, 22 Jan 2009 20:17:37 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Jan 2009 20:17:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 22 Jan 2009 21:18:13 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Remote participation at IETF#74 Thread-Index: Acl8xivuEIzmIQj0TemlqPrClyJzEA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 22 Jan 2009 19:17:37.0133 (UTC) FILETIME=[160169D0:01C97CC6] Subject: [Dime] Remote participation at IETF#74 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi all, we were wondering who is actually able to show up at IETF#74 given the travel restrictions many are facing these days. Drop us a mail so that we know whether we have to optimize our remote participation capabilities. Ciao Hannes & Dave _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 22 12:00:03 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BE3D28C28E; Thu, 22 Jan 2009 12:00:03 -0800 (PST) X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 12E3228C27F; Thu, 22 Jan 2009 12:00:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090122200002.12E3228C27F@core3.amsl.com> Date: Thu, 22 Jan 2009 12:00:02 -0800 (PST) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-qos-attributes-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: , Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --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 : Quality of Service Attributes for Diameter Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-qos-attributes-10.txt Pages : 41 Date : 2009-01-22 This document extends the IPFilterRule AVP functionality of the Diameter Base protocol and the functionality of the QoS-Filter-Rule AVP defined in RFC 4005. The ability to convey Quality of Service information using the AVPs defined in this document is available to existing and future Diameter applications where permitted by the command ABNF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-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-qos-attributes-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-22115308.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Thu Jan 22 12:00:04 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A00728C298; Thu, 22 Jan 2009 12:00:04 -0800 (PST) X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 17C5F28C286; Thu, 22 Jan 2009 12:00:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090122200002.17C5F28C286@core3.amsl.com> Date: Thu, 22 Jan 2009 12:00:02 -0800 (PST) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-qos-parameters-09.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: , Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --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 : Quality of Service Parameters for Usage with Diameter Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-qos-parameters-09.txt Pages : 12 Date : 2009-01-22 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, bandwidth, defending and preemption priority, admission priority, application-level resource priority, per-hop behavior class, and DiffServ-aware Multiprotocol Label Switching (MPLS) traffic engineering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parameters-09.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-qos-parameters-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-22115734.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Thu Jan 22 13:26:09 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BC763A6985; Thu, 22 Jan 2009 13:26:09 -0800 (PST) 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 062DF3A6938 for ; Thu, 22 Jan 2009 13:26:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 3nEeG7fPpEmC for ; Thu, 22 Jan 2009 13:26:08 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by core3.amsl.com (Postfix) with ESMTP id 404F83A6985 for ; Thu, 22 Jan 2009 13:26:08 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so4436597rvf.49 for ; Thu, 22 Jan 2009 13:25:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=RlXjaHdfPefxh8x9F8A6YAgOyCOF+S4XdEWkFzHiWEY=; b=NHxfrh6tt8NoHIGpXa1ZOIsgGS6x/nfVx+cNNOyhaB0O7+ViXMFS+ZHMz4anuCzTMp Plo69fC6gYyk8rpP4S44n5iyd7E5GltIg6Qi8zBNVE9vbXrgrylDSpOJDjWPqDUYQKs4 lXRCRThQdqAqtxqZbiT5thI4nL0OqJltm7CY4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=S7CG6Nhzdgcxq+eiFzeWeK4BIqE8Ci2VTwyXw5wqYqhQPOVHY6VyqcahhIoVEkSfWu YSiSBwzH+DrdjFq/M5RaepmYKRHhGwbtCdXQgQG+G9GeMRIz3kqL8KAWMInI68AohN2T A/hYRg9MA8QA9PfcE6VzTcTT0lxjmHEvQhDrc= MIME-Version: 1.0 Received: by 10.141.62.15 with SMTP id p15mr2343924rvk.92.1232659550686; Thu, 22 Jan 2009 13:25:50 -0800 (PST) In-Reply-To: References: Date: Thu, 22 Jan 2009 16:25:50 -0500 X-Google-Sender-Auth: 139978534d79cc40 Message-ID: <9cf5ced20901221325w942d120v8b92cdba5b285f3@mail.gmail.com> From: David Frascone To: "Tschofenig, Hannes (NSN - FI/Espoo)" Cc: dime@ietf.org Subject: Re: [Dime] Remote participation at IETF#74 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: , Content-Type: multipart/mixed; boundary="===============2071890574==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============2071890574== Content-Type: multipart/alternative; boundary=000e0cd1b0c4a5cfc6046118ead6 --000e0cd1b0c4a5cfc6046118ead6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit My travel is still a bit ambiguous, but, I think it'd be safer to plan for me to NOT be there. Then, if I do manage to get approval, it will just be a bonus. -Dave On Thu, Jan 22, 2009 at 2:18 PM, Tschofenig, Hannes (NSN - FI/Espoo) < hannes.tschofenig@nsn.com> wrote: > Hi all, > > we were wondering who is actually able to show up at IETF#74 given the > travel restrictions many are facing these days. > Drop us a mail so that we know whether we have to optimize our remote > participation capabilities. > > Ciao > Hannes & Dave > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --000e0cd1b0c4a5cfc6046118ead6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My travel is still a bit ambiguous, but, I think it'd be safer to plan = for me to NOT be there.  Then, if I do manage to get approval, it will= just be a bonus.

-Dave

On Thu, Ja= n 22, 2009 at 2:18 PM, Tschofenig, Hannes (NSN - FI/Espoo) <hannes.tschofenig@nsn.co= m> wrote:
Hi all,

we were wondering who is actually able to show up at IETF#74 given the
travel restrictions many are facing these days.
Drop us a mail so that we know whether we have to optimize our remote
participation capabilities.

Ciao
Hannes & Dave

_______________________________________________
DiME mailing list
DiME@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dime

--000e0cd1b0c4a5cfc6046118ead6-- --===============2071890574== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============2071890574==-- From dime-bounces@ietf.org Thu Jan 22 14:35:30 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A0493A68F4; Thu, 22 Jan 2009 14:35:30 -0800 (PST) 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 AE35A3A68F4 for ; Thu, 22 Jan 2009 14:35:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 50DVSBZLTTEe for ; Thu, 22 Jan 2009 14:35:28 -0800 (PST) Received: from webmail.bridgewatersystems.com (webmail.bridgewatersystems.com [66.46.199.134]) by core3.amsl.com (Postfix) with ESMTP id D289A3A68EB for ; Thu, 22 Jan 2009 14:35:27 -0800 (PST) Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Thu, 22 Jan 2009 17:35:06 -0500 From: Mark Jones To: "Tschofenig, Hannes (NSN - FI/Espoo)" Date: Thu, 22 Jan 2009 17:35:06 -0500 Thread-Topic: DIME Virtual Interim Meeting Thread-Index: Acl8vbwyorKW/KgZTZWjS0FknA4C/AAIkf9A Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "dime@ietf.org" Subject: Re: [Dime] DIME Virtual Interim Meeting 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hannes, I think the virtual interim is a good idea but this clashes with the next 3GPP CT meeting (9-19 Feb) so I will not be able to attend. Regards Mark > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) > Sent: January 22, 2009 13:18 > To: dime@ietf.org > Subject: [Dime] DIME Virtual Interim Meeting > > Hi all, > > to make some progress in DIME we would like to make a proposal for a > virtual interim meeting. The concept of virtual interim meetings is > floating around in the IETF and we thought it is a pretty good idea. > Virtual interim meeting means that we are going to have a phone > conference call for about ~2 hours to chat about working group items. > > So, unless there are strong objections we suggest that DIME holds a > virtual interim meeting on 12th February 2009, 12:30pm EST > for 2 hours. > > Proposed agenda: Discuss status and open issues of DIME working group > items > > We will send an update within the next week on the > technicalities of the > call. > > Document authors, please make sure that you resubmit your > drafts by the > 5th February. > > Ciao > Hannes & Dave > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 22 14:43:49 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83D9928C1FC; Thu, 22 Jan 2009 14:43:49 -0800 (PST) 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 7BA3128C1FC for ; Thu, 22 Jan 2009 14:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.71 X-Spam-Level: X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_05=-1.11] 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 U69h4c0N0Sbs for ; Thu, 22 Jan 2009 14:43:47 -0800 (PST) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id DD0753A6912 for ; Thu, 22 Jan 2009 14:43:47 -0800 (PST) Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id 6dPv1b0070mlR8UA9mjYb4; Thu, 22 Jan 2009 22:43:32 +0000 Received: from gwzPC ([67.160.38.190]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id 6mjX1b006469TLb8XmjXqf; Thu, 22 Jan 2009 22:43:32 +0000 From: "Glen Zorn" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , References: In-Reply-To: Date: Thu, 22 Jan 2009 14:42:53 -0800 Message-ID: <008d01c97ce2$c3d0bd60$4b723820$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acl8vbwyorKW/KgZTZWjS0FknA4C/AAJKkWg Content-Language: en-us Subject: Re: [Dime] DIME Virtual Interim Meeting 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org > Hi all, > > to make some progress in DIME we would like to make a proposal for a > virtual interim meeting. The concept of virtual interim meetings is > floating around in the IETF and we thought it is a pretty good idea. > Virtual interim meeting means that we are going to have a phone > conference call for about ~2 hours to chat about working group items. Conference calls suck. ... _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jan 23 00:47:20 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD1A33A697E; Fri, 23 Jan 2009 00:47:20 -0800 (PST) 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 CC5A23A6997 for ; Fri, 23 Jan 2009 00:47:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.234 X-Spam-Level: X-Spam-Status: No, score=-4.234 tagged_above=-999 required=5 tests=[AWL=-0.985, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-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 QcAbQbXldF3i for ; Fri, 23 Jan 2009 00:47:19 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 8FCD33A68AA for ; Fri, 23 Jan 2009 00:47:18 -0800 (PST) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Jan 2009 09:46:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 23 Jan 2009 09:46:58 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026062CC9A7@ftrdmel2> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] DIME Virtual Interim Meeting Thread-Index: Acl8vbwyorKW/KgZTZWjS0FknA4C/AAIkf9AABV/FFA= References: From: To: , X-OriginalArrivalTime: 23 Jan 2009 08:46:58.0312 (UTC) FILETIME=[26B94880:01C97D37] Cc: dime@ietf.org Subject: Re: [Dime] DIME Virtual Interim Meeting 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Hannes, Same for me! I will be at the 3GPP meeting. BR, Lionel = > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De = > la part de Mark Jones > Envoy=E9 : jeudi 22 janvier 2009 23:35 > =C0 : Tschofenig, Hannes (NSN - FI/Espoo) > Cc : dime@ietf.org > Objet : Re: [Dime] DIME Virtual Interim Meeting > = > Hannes, > = > I think the virtual interim is a good idea but this clashes = > with the next 3GPP CT meeting (9-19 Feb) so I will not be = > able to attend. > = > Regards > Mark > = > > -----Original Message----- > > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] = > On Behalf = > > Of Tschofenig, Hannes (NSN - FI/Espoo) > > Sent: January 22, 2009 13:18 > > To: dime@ietf.org > > Subject: [Dime] DIME Virtual Interim Meeting > > > > Hi all, > > > > to make some progress in DIME we would like to make a = > proposal for a = > > virtual interim meeting. The concept of virtual interim meetings is = > > floating around in the IETF and we thought it is a pretty good idea. > > Virtual interim meeting means that we are going to have a phone = > > conference call for about ~2 hours to chat about working = > group items. > > > > So, unless there are strong objections we suggest that DIME holds a = > > virtual interim meeting on 12th February 2009, 12:30pm EST for 2 = > > hours. > > > > Proposed agenda: Discuss status and open issues of DIME = > working group = > > items > > > > We will send an update within the next week on the = > technicalities of = > > the call. > > > > Document authors, please make sure that you resubmit your drafts by = > > the 5th February. > > > > Ciao > > Hannes & Dave > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > = _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jan 23 02:38:54 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07A3A3A6A22; Fri, 23 Jan 2009 02:38:54 -0800 (PST) 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 515CF3A6A2A for ; Fri, 23 Jan 2009 02:28:18 -0800 (PST) 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 0jm3E1B47ifu for ; Fri, 23 Jan 2009 02:28:12 -0800 (PST) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 5E6BE3A6A22 for ; Fri, 23 Jan 2009 02:28:12 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 1BA3C90006 for ; Fri, 23 Jan 2009 05:27:52 -0500 (EST) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25833-02 for ; Fri, 23 Jan 2009 05:27:51 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Fri, 23 Jan 2009 05:27:51 -0500 (EST) Received: from exchindia3.starentnetworks.com ([10.6.7.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jan 2009 05:27:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 23 Jan 2009 15:57:44 +0530 Message-ID: <69FADB84C90B1248A7DE59422771FA0C04ECEA5A@exchindia3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Session Termination for LTE STa interface specification Thread-Index: Acl9RTqZOTbxN8laRfeCK1RoQeVWIQ== From: "Mulla, Zia" To: X-OriginalArrivalTime: 23 Jan 2009 10:27:51.0529 (UTC) FILETIME=[3EB8E590:01C97D45] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: [Dime] Session Termination for LTE STa interface specification 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: , Content-Type: multipart/mixed; boundary="===============1502980392==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1502980392== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C97D45.3AB6221D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C97D45.3AB6221D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 I have a query regarding session termination and the associated messages that are required to be sent for LTE STa interface (3GPP TS 29.273 v8.0) =20 The 3GPP spec in section 5.1.2.2.1 does not explicitly state that a Session-Termination-Request should be sent to the AAA server after it receives an Abort-Session-Request. =20 But, as per RFC 3588, the Session Termination; Section 8.4 strictly mentions that STR is required to be sent upon reception of ASR from the server. What is the correct behavior that we should be expecting?=20 State is being maintained in this case. =20 Any inputs? =20 Thanks and Regards, Zia =20 =20 ------_=_NextPart_001_01C97D45.3AB6221D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I have a query regarding session termination and the associated messages that are required to be sent for LTE STa interface = (3GPP TS 29.273 v8.0)

 

The 3GPP spec in section 5.1.2.2.1 does not = explicitly state that a Session-Termination-Request should be sent to the AAA server = after it receives an Abort-Session-Request.

 

But, as per RFC 3588, the Session Termination; = Section 8.4 strictly mentions that STR is required to be sent upon reception of ASR = from the server. What is the correct behavior that we should be expecting? =

State is being maintained in this = case.

 

Any inputs?

 

Thanks and Regards,

Zia

 

 

------_=_NextPart_001_01C97D45.3AB6221D-- --===============1502980392== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1502980392==-- From dime-bounces@ietf.org Fri Jan 23 08:32:01 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E8D528C175; Fri, 23 Jan 2009 08:32:01 -0800 (PST) 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 C3A9528C175 for ; Fri, 23 Jan 2009 08:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.023, 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 SEdmK11yuSdW for ; Fri, 23 Jan 2009 08:31:59 -0800 (PST) Received: from webmail.bridgewatersystems.com (webmail.bridgewatersystems.com [66.46.199.134]) by core3.amsl.com (Postfix) with ESMTP id B3BB13A6A51 for ; Fri, 23 Jan 2009 08:31:58 -0800 (PST) Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Fri, 23 Jan 2009 11:31:36 -0500 From: Mark Jones To: "Mulla, Zia" Date: Fri, 23 Jan 2009 11:31:35 -0500 Thread-Topic: Session Termination for LTE STa interface specification Thread-Index: Acl9RTqZOTbxN8laRfeCK1RoQeVWIQALTb3w Message-ID: References: <69FADB84C90B1248A7DE59422771FA0C04ECEA5A@exchindia3.starentnetworks.com> In-Reply-To: <69FADB84C90B1248A7DE59422771FA0C04ECEA5A@exchindia3.starentnetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "dime@ietf.org" Subject: Re: [Dime] Session Termination for LTE STa interface specification 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: , Content-Type: multipart/mixed; boundary="===============1895185342==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1895185342== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_D6824C8074596B4E9CA38F6A62454F5C0A3332E617exchange02bri_" --_000_D6824C8074596B4E9CA38F6A62454F5C0A3332E617exchange02bri_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Zia, ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Mul= la, Zia Sent: January 23, 2009 05:28 To: dime@ietf.org Subject: [Dime] Session Termination for LTE STa interface specification Hi all, I have a query regarding session termination and the associated messages th= at are required to be sent for LTE STa interface (3GPP TS 29.273 v8.0) The 3GPP spec in section 5.1.2.2.1 does not explicitly state that a Session= -Termination-Request should be sent to the AAA server after it receives an = Abort-Session-Request. But, as per RFC 3588, the Session Termination; Section 8.4 strictly mention= s that STR is required to be sent upon reception of ASR from the server. Wh= at is the correct behavior that we should be expecting? TS 29.273 does not define its own authorization session state machine so I = assume it follows the one in RFC3588. I share your understanding that there= should be an STR/STA exchange after ASR/ASA on STa for strict RFC3588 comp= liance. State is being maintained in this case. Any inputs? While I understand that a client may want to send an STR if the ASR was rec= eived from some server other than the one keeping session state, I think th= at making the STR a must in all session termination cases is too strict. If the ASR came from the same server that the client knows is keeping sessi= on state then the STR should be optional. Maybe the server could indicate = whether it requires an STR by including Auth-Session-State =3D NO_STATE_MAI= NTAINED in the ASR to indicate that it will cleanup state when the ASA is r= eceived. What do others think? Regards Mark Thanks and Regards, Zia --_000_D6824C8074596B4E9CA38F6A62454F5C0A3332E617exchange02bri_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Zia,

From: dime-bounces@ietf.org=20 [mailto:dime-bounces@ietf.org] On Behalf Of Mulla, Zia
Sent:= =20 January 23, 2009 05:28
To: dime@ietf.org
Subject: [Di= me]=20 Session Termination for LTE STa interface specification

Hi=20 all,

 

I have a query regarding se= ssion=20 termination and the associated messages that are required to be sent for = LTE=20 STa interface (3GPP TS 29.273 v8.0)

 

The 3GPP spec in section 5.= 1.2.2.1=20 does not explicitly state that a Session-Termination-Request should be se= nt to=20 the AAA server after it receives an=20 Abort-Session-Request.

 

= But, as=20 per RFC 3588, the Session Termination; Section 8.4 strictly mentions that= STR=20 is required to be sent upon reception of ASR from the server. What is the= =20 correct behavior that we should be expecting? =  

= &nb= sp;

= TS 29.273 does not defin= e its own=20 authorization session state machine so I assume it follows the one in RFC= 3588.=20 I share your understanding that there should be an STR/STA exchange after= =20 ASR/ASA on STa for strict RFC3588=20 compliance.

=  

State is being maintained i= n this=20 case.

 

Any=20 inputs?

 

While I understand that a client may want to s= end an=20 STR if the ASR was received from some server other than the one keeping=20 session state, I think that making the STR a must in all session terminat= ion=20 cases is too strict.

 

If the ASR came from the same server that the = client=20 knows is keeping session state then the STR should be optional.  May= be=20 the server could indicate whether it requires an STR by including=20 Auth-Session-State =3D NO_STATE_MAINTAINED in the ASR to indicate that it= will=20 cleanup state when the ASA is received. What do others=20 think?

 

Regards

Mark

&n= bsp;

Thanks and=20 Regards,

Zia

 

 

--_000_D6824C8074596B4E9CA38F6A62454F5C0A3332E617exchange02bri_-- --===============1895185342== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1895185342==-- From dime-bounces@ietf.org Sat Jan 24 02:50:59 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98C0728C1C6; Sat, 24 Jan 2009 02:50:59 -0800 (PST) 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 EF6EE28C1C6 for ; Sat, 24 Jan 2009 02:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[AWL=0.296, 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 uoby5NF0dnyk for ; Sat, 24 Jan 2009 02:50:57 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 522453A67B5 for ; Sat, 24 Jan 2009 02:50:55 -0800 (PST) Received: (qmail invoked by alias); 24 Jan 2009 10:50:37 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp008) with SMTP; 24 Jan 2009 11:50:37 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18OCJkOQGYOzJ2GLwH3fy3Zso8VnJg1ODa2yvsgT8 oLlOQTok56VABg From: "Hannes Tschofenig" To: References: Date: Sat, 24 Jan 2009 12:51:17 +0200 Message-ID: <003401c97e11$af8a73c0$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acl8vbwyorKW/KgZTZWjS0FknA4C/ABRoKgw Importance: High X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Subject: [Dime] DIME Virtual Interim Meeting: Update X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi all, based on the initial feedback about the date we are considering to move the conf. call for 1 week to the 19th. Please give us quick feedback about your preferred time for the 19th Feb: http://www.doodle.com/participation.html?pollId=x3b39byg6q38ypit Ciao Hannes >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >Behalf Of ext Tschofenig, Hannes (NSN - FI/Espoo) >Sent: 22 January, 2009 20:18 >To: dime@ietf.org >Subject: [Dime] DIME Virtual Interim Meeting > >Hi all, > >to make some progress in DIME we would like to make a proposal >for a virtual interim meeting. The concept of virtual interim >meetings is floating around in the IETF and we thought it is a >pretty good idea. >Virtual interim meeting means that we are going to have a >phone conference call for about ~2 hours to chat about working >group items. > >So, unless there are strong objections we suggest that DIME >holds a virtual interim meeting on 12th February 2009, 12:30pm >EST for 2 hours. > >Proposed agenda: Discuss status and open issues of DIME >working group items > >We will send an update within the next week on the >technicalities of the call. > >Document authors, please make sure that you resubmit your >drafts by the 5th February. > >Ciao >Hannes & Dave > > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Jan 24 03:42:14 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62DCF3A6B58; Sat, 24 Jan 2009 03:42:14 -0800 (PST) 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 C7A233A6B3F for ; Sat, 24 Jan 2009 03:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.554 X-Spam-Level: X-Spam-Status: No, score=-5.554 tagged_above=-999 required=5 tests=[AWL=1.045, 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 QYjzklwgYGtW for ; Sat, 24 Jan 2009 03:42:12 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id C9F163A6B64 for ; Sat, 24 Jan 2009 03:42:11 -0800 (PST) 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 n0OBflP0031740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 24 Jan 2009 12:41:47 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n0OBflAC008956; Sat, 24 Jan 2009 12:41:47 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 24 Jan 2009 12:41:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 24 Jan 2009 13:41:46 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45F7FCFF@FIESEXC015.nsn-intra.net> In-Reply-To: <008d01c97ce2$c3d0bd60$4b723820$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] DIME Virtual Interim Meeting Thread-Index: Acl8vbwyorKW/KgZTZWjS0FknA4C/AAJKkWgAEf4c+A= References: <008d01c97ce2$c3d0bd60$4b723820$@net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Glen Zorn" , X-OriginalArrivalTime: 24 Jan 2009 11:41:47.0059 (UTC) FILETIME=[BCEAD030:01C97E18] Subject: Re: [Dime] DIME Virtual Interim Meeting 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org A face-to-face meeting is not an option! >-----Original Message----- >From: ext Glen Zorn [mailto:glenzorn@comcast.net] >Sent: 23 January, 2009 00:43 >To: Tschofenig, Hannes (NSN - FI/Espoo); dime@ietf.org >Subject: RE: [Dime] DIME Virtual Interim Meeting > >> Hi all, >> >> to make some progress in DIME we would like to make a proposal for a >> virtual interim meeting. The concept of virtual interim meetings is >> floating around in the IETF and we thought it is a pretty good idea. >> Virtual interim meeting means that we are going to have a phone >> conference call for about ~2 hours to chat about working group items. > >Conference calls suck. > >... > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Jan 24 03:42:19 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B82913A6B72; Sat, 24 Jan 2009 03:42:19 -0800 (PST) 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 516FC3A6B72 for ; Sat, 24 Jan 2009 03:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.551 X-Spam-Level: X-Spam-Status: No, score=-5.551 tagged_above=-999 required=5 tests=[AWL=1.048, 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 KZsGI-zImDko for ; Sat, 24 Jan 2009 03:42:17 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 39C713A6B80 for ; Sat, 24 Jan 2009 03:42:17 -0800 (PST) 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 n0OBfmLj031746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 24 Jan 2009 12:41:48 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n0OBfm0G008960; Sat, 24 Jan 2009 12:41:48 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 24 Jan 2009 12:41:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 24 Jan 2009 13:41:46 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45F7FD00@FIESEXC015.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Review of draft-ietf-dime-qos-attributes-09.txt Thread-Index: Acl25+4LwiZpp+s/TXmZN/DuYxImPgBkgxuAAIAkfzAAi3S9UAAAudCwAAA20sAAVY4dsA== References: <496E673C.10103@tari.toshiba.com><01f501c9787b$e993fc30$7e4fa20a@nsnintra.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Romascanu, Dan (Dan)" , "Mark Jones" , "Hannes Tschofenig" , "Victor Fajardo" X-OriginalArrivalTime: 24 Jan 2009 11:41:47.0606 (UTC) FILETIME=[BD3E4760:01C97E18] Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-ietf-dime-qos-attributes-09.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org When I tried to submit version -09 the tool told me that it expects -10. Hence, for some reason the previously submitted -09 version did not appear on the page even though it was announced on the list, see http://www.ietf.org/mail-archive/web/dime/current/msg03141.html Anyway, we now have -10 online and I can see it on the webpage. Ciao Hannes >-----Original Message----- >From: ext Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] >Sent: 22 January, 2009 18:20 >To: Tschofenig, Hannes (NSN - FI/Espoo); Mark Jones; Hannes >Tschofenig; Victor Fajardo >Cc: dime@ietf.org >Subject: RE: [Dime] Review of draft-ietf-dime-qos-attributes-09.txt > > > >> -----Original Message----- >> From: Tschofenig, Hannes (NSN - FI/Espoo) > >> Hmm. I thought we submitted the -09 version. >> > >The current version in the repository is >http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-paramet >ers-08.tx >t > >Dan > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Jan 24 13:04:56 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD9603A6809; Sat, 24 Jan 2009 13:04:56 -0800 (PST) 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 8B7DA3A6809 for ; Sat, 24 Jan 2009 13:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.394 X-Spam-Level: X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=0.205, 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 9tnVtOlFlENi for ; Sat, 24 Jan 2009 13:04:54 -0800 (PST) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id CDC7F3A67D9 for ; Sat, 24 Jan 2009 13:04:54 -0800 (PST) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id 7XJd1b00D17UAYkA2Z4eiH; Sat, 24 Jan 2009 21:04:39 +0000 Received: from gwzPC ([67.160.38.190]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id 7Z4c1b00C469TLb8ZZ4djx; Sat, 24 Jan 2009 21:04:38 +0000 From: "Glen Zorn" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" References: <008d01c97ce2$c3d0bd60$4b723820$@net> <3D3C75174CB95F42AD6BCC56E5555B45F7FCFF@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45F7FCFF@FIESEXC015.nsn-intra.net> Date: Sat, 24 Jan 2009 13:03:42 -0800 Message-ID: <000901c97e67$3d8fb810$b8af2830$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acl8vbwyorKW/KgZTZWjS0FknA4C/AAJKkWgAEf4c+AAF5NZ0A== Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] DIME Virtual Interim Meeting 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Tschofenig, Hannes (NSN - FI/Espoo) [mailto:hannes.tschofenig@nsn.com] writes: > A face-to-face meeting is not an option! 2 questions: 1) If what we have to discuss isn't important enough for a face-to-face meeting, why can it not wait until the SF IETF? 2) If we have so much to discuss, why was only a single 2.5 hour slot requested in SF? Further, if we are to be expected to allocate ~2 hours for this exercise I would expect an agenda consisting of somewhat more than 'chatting about working group items'. ... ~gwz At one time in the US, in the mid-nineteenth century, working for wage labor was considered not very different from chattel slavery...anyone who thinks it's legitimate to be a wage laborer is internalizing oppression in a way which would have seemed intolerable to people in the mills 150 years ago. -- Noam Chomsky, "Propaganda & the Public Mind" _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Jan 25 00:16:16 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B0053A692D; Sun, 25 Jan 2009 00:16:16 -0800 (PST) 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 206783A692D for ; Sun, 25 Jan 2009 00:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.314 X-Spam-Level: X-Spam-Status: No, score=-2.314 tagged_above=-999 required=5 tests=[AWL=0.285, 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 3oll3xrbFLlG for ; Sun, 25 Jan 2009 00:16:14 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 2C09928B797 for ; Sun, 25 Jan 2009 00:16:13 -0800 (PST) Received: (qmail invoked by alias); 25 Jan 2009 08:15:54 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp036) with SMTP; 25 Jan 2009 09:15:54 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/lOAp2YS7lQEM4Dfi6HdsCf5QGI7kpK+YFCzxYrM R5DEDvpfwSLNT+ From: "Hannes Tschofenig" To: "'Glen Zorn'" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" References: <008d01c97ce2$c3d0bd60$4b723820$@net><3D3C75174CB95F42AD6BCC56E5555B45F7FCFF@FIESEXC015.nsn-intra.net> <000901c97e67$3d8fb810$b8af2830$@net> Date: Sun, 25 Jan 2009 10:16:33 +0200 Message-ID: <011401c97ec5$3d43cb40$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <000901c97e67$3d8fb810$b8af2830$@net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acl8vbwyorKW/KgZTZWjS0FknA4C/AAJKkWgAEf4c+AAF5NZ0AAY6TYQ X-Y-GMX-Trusted: 0 X-FuHaFi: 0.61 Cc: dime@ietf.org Subject: Re: [Dime] DIME Virtual Interim Meeting 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Glen, >Tschofenig, Hannes (NSN - FI/Espoo) [mailto:hannes.tschofenig@nsn.com] >writes: > >> A face-to-face meeting is not an option! > >2 questions: > >1) If what we have to discuss isn't important enough for a >face-to-face meeting, why can it not wait until the SF IETF? Travel budgets are being cut these days. These virtual interim meetings sounded like a good idea to me. >2) If we have so much to discuss, why was only a single 2.5 >hour slot requested in SF? I thought that this was good already. Do you think I should request an additional slot. Btw, I have concerns that most folks are not going to show up at IETF#74 because they will not get their travel approved. That's why I have distributed my mail regarding the remote participation possibility. >Further, if we are to be expected to allocate ~2 hours for >this exercise I would expect an agenda consisting of somewhat >more than 'chatting about working group items'. As mentioned in my announcement, I will provide more details but I first wanted to find a suitable date. The topics for discussions shouldn't, however, be very surprising for those who follow the work in the group. Ciao Hannes > >... > >~gwz > >At one time in the US, in the mid-nineteenth century, working >for wage labor was considered not very different from chattel >slavery...anyone who thinks it's legitimate to be a wage >laborer is internalizing oppression in a way which would have >seemed intolerable to people in the mills 150 years ago. > -- Noam Chomsky, "Propaganda & the Public Mind" > > > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Jan 25 04:59:22 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F3E73A6847; Sun, 25 Jan 2009 04:59:22 -0800 (PST) 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 0DE933A6847 for ; Sun, 25 Jan 2009 04:59:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.324 X-Spam-Level: X-Spam-Status: No, score=-2.324 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQwZqVG4EXE2 for ; Sun, 25 Jan 2009 04:59:20 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id B7D7C3A6831 for ; Sun, 25 Jan 2009 04:59:19 -0800 (PST) Received: (qmail invoked by alias); 25 Jan 2009 12:59:00 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp041) with SMTP; 25 Jan 2009 13:59:00 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/AIw51AzDA16LO3HC1+5ObU2K3oc7wXaMRh/kFqd QgeNB5as705XzM From: "Hannes Tschofenig" To: "'Hannes Tschofenig'" , References: <003401c97e11$af8a73c0$0201a8c0@nsnintra.net> Date: Sun, 25 Jan 2009 14:59:41 +0200 Message-ID: <013801c97eec$ca747060$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <003401c97e11$af8a73c0$0201a8c0@nsnintra.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acl8vbwyorKW/KgZTZWjS0FknA4C/ABRoKgwADoV8gA= Importance: High X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Subject: [Dime] DIME Virtual Interim Meeting: Update X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I extended the poll for dates from the 16th to the 20th, see http://www.doodle.com/participation.html?pollId=x3b39byg6q38ypit Please enter your preference as soon as possible to finalize the planning. Ciao Hannes >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >Behalf Of Hannes Tschofenig >Sent: 24 January, 2009 12:51 >To: dime@ietf.org >Subject: [Dime] DIME Virtual Interim Meeting: Update >Importance: High > >Hi all, > >based on the initial feedback about the date we are >considering to move the conf. call for 1 week to the 19th. >Please give us quick feedback about your preferred time for >the 19th Feb: >http://www.doodle.com/participation.html?pollId=x3b39byg6q38ypit > >Ciao >Hannes > >>-----Original Message----- >>From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >Behalf Of >>ext Tschofenig, Hannes (NSN - FI/Espoo) >>Sent: 22 January, 2009 20:18 >>To: dime@ietf.org >>Subject: [Dime] DIME Virtual Interim Meeting >> >>Hi all, >> >>to make some progress in DIME we would like to make a proposal for a >>virtual interim meeting. The concept of virtual interim meetings is >>floating around in the IETF and we thought it is a pretty good idea. >>Virtual interim meeting means that we are going to have a phone >>conference call for about ~2 hours to chat about working group items. >> >>So, unless there are strong objections we suggest that DIME holds a >>virtual interim meeting on 12th February 2009, 12:30pm EST >for 2 hours. >> >>Proposed agenda: Discuss status and open issues of DIME working group >>items >> >>We will send an update within the next week on the technicalities of >>the call. >> >>Document authors, please make sure that you resubmit your >drafts by the >>5th February. >> >>Ciao >>Hannes & Dave >> >> >>_______________________________________________ >>DiME mailing list >>DiME@ietf.org >>https://www.ietf.org/mailman/listinfo/dime >> > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jan 27 00:19:50 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94C813A6B16; Tue, 27 Jan 2009 00:19:50 -0800 (PST) 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 6A4B53A6B16 for ; Tue, 27 Jan 2009 00:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 xS1rYHjWzpQA for ; Tue, 27 Jan 2009 00:19:46 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.189]) by core3.amsl.com (Postfix) with ESMTP id 088D63A6A8C for ; Tue, 27 Jan 2009 00:19:45 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id f33so3027488fkf.5 for ; Tue, 27 Jan 2009 00:19:26 -0800 (PST) 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 :content-transfer-encoding; bh=lgXo5biP9uZP9UDYv4/FJcqWCa2WEIcqv03V+ZMgPf8=; b=TGza8adPXXlGG9BPq3HL3OnM2NJmOiBkx3BpgwsQieN64Y70IAZZTJibUfsXYTJ4XX +t4Ww9giIMhZsS4qTI/s9swyzrmA2gKEJyxLviRwl/2VJFrwzYbax0o9HVHBavtq4xrG OfBXZ0OolNWi0A+RmQxdoP397GA/rasE81DT0= 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:content-transfer-encoding; b=f/PtU9uWZam+j6f3RK4bVmydziZ16V0k6IXZi7F4zwTMoacpSgeERKG4aQAoeJ1iB/ Ggjj0/YLXQHmV6fQbzWv7ELrIClIqnWxDD9W/Kj6INR0FFs3g1U18hRdUmcSY/L7md+3 2HkhrNwKS2+spq7/WBkpnDmji7Pp4C8uM3XIQ= MIME-Version: 1.0 Received: by 10.223.105.72 with SMTP id s8mr375775fao.9.1233044366121; Tue, 27 Jan 2009 00:19:26 -0800 (PST) In-Reply-To: <49780C66.7010108@nict.go.jp> References: <49780C66.7010108@nict.go.jp> Date: Tue, 27 Jan 2009 09:19:26 +0100 Message-ID: <5e2406980901270019k795bff98vfa60f2caa0c1de00@mail.gmail.com> From: Julien Bournelle To: Sebastien Decugis Cc: "dime@ietf.org" Subject: Re: [Dime] [ERP] Review and comments, synthesis 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi sebastien, See my comments below and thanks for this careful review. I think that some of the topics you raised would probably benefit from separate threads.. On Thu, Jan 22, 2009 at 7:04 AM, Sebastien Decugis wrote: > Hi all, > > Here is my review of draft-ietf-dime-erp-00, in [Seb] tags. > I've also copied some pending comments from other people that have not > been addressed yet, AFAIK. > > BTW, about the reference to RFC3588 or RFC3588bis, according to the > Milestones of the WG, the rfc3588bis is due in January 2009 and ERP > document is due in May 2009, so I think it makes sense to update the > content to the new revision of base protocol (will affect the reference > to the document and simplify the AVP description). Do you agree? it makes sense. Having opinions from others will help to conclude. > > In short, my main comments are (some are detailed later in the review): > - we should add more details on deployment (ER entities on the route of > EAP exchanges, ...) and detail interoperability issues (if one or more > entity does not support ERP). This document uses the following entities: > Peer, ER authenticator, ER local server, ER home server, EAP local > server (not directly but it may be involved in some cases), hmm, in which case a local EAP server is involved ? maybe you thought to a local AAA server ? > EAP home > server. More figures are definitely needed to make the whole thing > understandable... Agree. > - I think grouped AVPs could be used to simplify handling on the ER > entities. You're probably right. > I also think AVPs should be renamed to ERP-*. good idea. > - ER home server and EAP home server are mixed in this document, > clarification is needed. > - In case of implicit ERP bootstrapping, the peer is not notified that > ERP was already bootstrapped. How to prevent ERP bootstraping exchange > to be initiated? (maybe sending a new AVP between ER local server and > authenticator? FFS ;) ). In a general maneer, I think that implicit > bootstrapping of ERP adds more problems than it solves (for example, it > will occur even if the peer does not support ERP). I think we could > simply remove it and mandate explicit bootstrapping for ERP. If we remove it from AAA support, implicit bootstrapping just won't work in general. Not sure that we can remove it. > - We should also consider the simpler case where the peer is in its home > network. New AVPs are not used, but some description is needed anyway. ok > - Everytime I write "we should", please read "I can provide a draft for > this, if you agree this is needed"... sounds good to me :) > > > Abstract > > 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 any EAP/ERP authenticator. > > > [Julien] I'm wondering if we should note that the authenticator may be > ERP-aware. > > [Seb] I agree that only ERP-aware authenticator can be used in Diameter > ERP application. A pure EAP-passthrough NAS would not be able (to be > verified, though) to extract the content of KeyName-NAI to set the > User-Name of the new message, which is mandatory for routing of the ERP > message. This should be written in this document. Yes, normally it will just drop the packets since EAP Code > 4. > > This document specifies > Diameter support for ERP. The Diameter EAP application is re-used > for encapsulating the newly defined EAP codes specified in the ERP > specification. Additionally, this document also defines specific > Diameter processing rules relevant to ERP. > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 3. Diameter Support for ERP . . . . . . . . . . . . . . . . . . . 3 > 3.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 3 > 3.2. DSRK Request and Delivery . . . . . . . . . . . . . . . . . 4 > 4. Command Codes . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 5. Attribute Value Pair Definitions . . . . . . . . . . . . . . . 5 > 5.1. EAP-DSRK-Request AVP . . . . . . . . . . . . . . . . . . . 5 > 5.2. EAP-DSRK AVP . . . . . . . . . . . . . . . . . . . . . . . 5 > 5.3. EAP-DSRK-Name AVP . . . . . . . . . . . . . . . . . . . . . 5 > 5.4. EAP-DSRK-Lifetime AVP . . . . . . . . . . . . . . . . . . . 5 > 6. AVP Occurrence Table . . . . . . . . . . . . . . . . . . . . . 5 > 7. AVP Flag Rules . . . . . . . . . . . . . . . . . . . . . . . . 6 > 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 > 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 > 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 > 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 > 11.1. Normative References . . . . . . . . . . . . . . . . . . . 7 > 11.2. Informative References . . . . . . . . . . . . . . . . . . 8 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 > > > > 1. Introduction > > RFC 4072 [1] specifies a Diameter application that carries EAP > packets between a Diameter client and the Diameter Server/EAP server. > > > [Seb] I think some people will not like the "Diameter client" and > "Diameter Server" phrasing... Maybe "EAP authenticator / Diameter EAP > client" and "EAP server / Diameter EAP server" would be more precise? Yes > [Seb] (editorial) In some other RFC, such as 5296, there are links > pointing to the full text of the RFC when a reference appears in the > text (in html version), and sometimes also the title of the RFC is > copied in the title of the link, such as in 5295. I think it is very > convenient, but I don't know if it's a mod in the xml2rfc tool or > changes in the xml file. Is it possible to do the same thing here Julien? I don't know. I didn't try to generate the html version. > > RFC 5296 [2] defines the EAP Re-authentication Protocol to allow > faster re-authentication of a previously authenticated peer. > > In ERP, a peer is authenticated by the network thanks to keying > > [Seb] I am not sure about this, but I think that ERP provides mutual > authentication of the peer and the network by proof of possession of > material derived from a previous mutual authentication (in full EAP > exchange). Or does this depend on the EAP method that is used? Anyway, > it is probably not important for this document. it does not depend on the EAP method but the key used as an input to ERP (I think about the EMSK) is first derived from the first EAP exchange. That was the intention of this sentence. > > material obtained during a previous EAP exchange. This keying > material is derived from the Extended Master Session Key (EMSK) as > defined in the RFC 5295 [5]. To accomplish the EAP reauthentication > functionality, ERP defines two new EAP codes - EAP-Initiate and EAP > Finish. This document specifies the reuse of Diameter EAP > Application to carry these new EAP messages. > > ERP is executed between the peer and a server located either in the > peer's home domain or in the local domain visited by the peer. In > the latter case, a Domain Specific Root Key (DSRK) is derived from > the EMSK, as defined in the RFC 5295 [5], and is provided by the Home > EAP server to the local domain server. > > > [Seb] In my understanding of the ERP mechanism, the home ER server and > home EAP server may be different entities (with some out-of-band > mechanism to transport the usage-specific keys, such as defined in > draft-ietf-hokey-key-mgm-04). I think we should refer to Home ER server > here. This server would anyway have to be on the path of the full EAP > authentication messages, because of Diameter routing mechanism based on > message's application, for ERP to work, since we re-use EAP application > number. We thought that it would simplify to say that home ER and home EAP are logically co-located. > > For that purpose, this > document specifies the transport of the DSRK using the Diameter EAP > Application. > > > [Seb] What happens if there is no local ER server, or the peer is in its > home network and uses ERP? I think the scope of this document is broader > than described here. I believe text should be added in the document to > describe this situation. I can provide a draft text, if you agree that > this is missing. Yes, that would be good to document this case. > [Seb] By the way, is there a difference between "realm" and "domain"? > Sorry for the non-native English speaker's question ^^'. AFAIK, there is no difference. > > > 2. Assumptions > > This document defines only additional optional AVPs for usage with > the Diameter EAP application. This document does not define a new > Diameter application and therefore a new Application ID is not > required, as described in the Diameter Base protocol [3]. > > In this document, when EAP re-authentication is performed in the > domain visited by the peer, it is assumed that the local ER server is > co-located with a Diameter agent in the visited domain present in the > path of the full EAP exchange. (Editor's Note: it is not clear at > the time of writing wether this document must require this local AAA > server to be on the path.) > > > [Seb] I think every previous review of this document had remarks on this > part. I'll try to clarify according to my understanding. > First of all, this assumption has to be made due to the re-use of > Diameter EAP application. not really. Diameter EAP application may have the same problem. > An alternative solution using a different > application ID for ERP would remove this constraint but adds great > complexity and several exchanges to distribute the keys to the ER > entities. I personally believe that using the same application id is > better, since implementing ERP functions on top of EAP (i.e. colocate ER > and EAP servers) is easier than having different boxes for that. not sure to understand. Are you saying that you would prefer "great complexity" ? :) I think we should handle this topic in a specific thread. > - For ERP implicit or explicit bootstrapping to success, the local ER > server and home ER server *must* be on the path of full EAP > authentication (with home EAP server). > - In addition, once ERP is bootstrapped, the local ER server *must* be > on the path of a (virtual) full EAP authentication with local EAP > server, since the User-Name AVP contains the local domain name > (EMSKname@localdomain). > - What happens if one of these condition is not met is not trivial. I > think in most cases it results in the ERP message not answered, timed > out, and a normal full EAP authentication follow. > I think a new (3.3 ?) section is needed to describe interoperability and > deployment issues such as: what happens if the assumption is not met, or > if one of the entities does not support ERP functions. See my note later > in this review. Right. > Addressing Jouni's comment, we should also consider the current work on > Diameter routing. Especially, with Diameter routing as described in Base > Protocol, the ER local server may be in the path of first EAP exchange > (and add the EAP-DSRK-Request AVP) but not in the next round(s) of a > multi-round EAP exchange, and therefore unable to extract the EAP-DSRK > from the final Success notification, which breaks a strong requirement > of RFC5295. Of course, the ER server could detect that the local ER > server was not in the path (thanks to Route-Record AVPs, and provided > that this ER home server knows which one is the ER local server) of the > last DER and not add this keying material. > > > 3. Diameter Support for ERP > > 3.1. Protocol Overview > > The Diameter EAP Application is used to transport ERP messages > between the NAS (authenticator) and an authentication server (ER > server). > > In ERP, the peer sends an EAP-Initiate/Re-auth message to the ER > server via the authenticator. Alternatively, the NAS may send an > EAP-Initiate/Re-auth-Start message to the peer to trigger the start > of ERP. In this case, the peer responds with an EAP-Initiate/Re-auth > message to the NAS. > > The general guidelines for encapsulating EAP messages in Diameter > from RFC 4072 [1] apply to the new EAP codes defined for ERP as well. > The EAP-Initiate/Re-auth message is encapsulated in an EAP-Payload > AVP of a Diameter EAP Request (DER) message by the NAS and sent to > the Diameter server. The NAS MUST copy the contents of the value > field of the 'KeyName-NAI' TLV or the 'peer-id' TLV (when the former > is not present) of the EAP Initiate/Re-auth message into a User-Name > AVP of the Diameter EAP-Request. > > > [Seb] I can't find a case where 'KeyName-NAI' TLV would not be in the > ERP message. I think the second part of this sentence should be removed. > If the peer does not have a valid key, it will not initiate ERP at all. I guess you're right. > > The ER server processes the EAP-Initiate/Re-auth message in > accordance with [2] and responds with an EAP-Finish/Re-auth message. > The Diameter server MUST encapsulate the EAP-Finish/Re-auth message > within an EAP-Payload AVP of a Diameter EAP Answer message. In an > EAP re-authentication successful case, an EAP-Master-Session-Key AVP > is included in the Diameter EAP Answer (DEA) message that contains > the Re-authentication Master Session Key (rMSK). The Diameter > Result-Code SHOULD be a success Result-Code. In an EAP re- > authentication failure case, the Diameter Result-Code AVP of the a > Diameter EAP Answer (DEA) message SHOULD be a failure Result-Code and > no EAP-Master-Session-Key AVP is present. (Editor's Note: it is FFS > if a SHOULD is sufficient) (2nd Editor's Note: add a figure ?) > > > [Seb] I also agree that MUST conditions for the result-codes seems more > logical here. It should also be noted that if the EAP server does not > support ERP functions it will return a Diameter error, according to > RFC4072: "A Diameter server receiving an EAP-Payload AVP that it does > not understand SHOULD determine whether the error is fatal or non-fatal > based on the EAP Type. A Diameter server determining that a fatal error > has occurred MUST send a Diameter-EAP-Answer with a failure Result-Code > and an EAP-Payload AVP encapsulating an EAP Failure packet. A Diameter > server determining that a non-fatal error has occurred MUST send a > Diameter-EAP-Answer with DIAMETER_MULTI_ROUND_AUTH Result-Code, but no > EAP-Payload AVP." ok. I also think a MUSt makes sense here. > > [Seb] I think a figure is not sufficient here, we need to develop the > different situations (peer in local domain, no local ER server, ...), > each with a figure. This would rather be a separate section, IMHO. I can > provide a draft if you agree. I agree. > > 3.2. DSRK Request and Delivery > > A local ER server, collocated with a Diameter proxy in the domain > visited by the peer, may request a DSRK from the home EAP/ERP server, > either in the initial EAP exchange (implicit bootstrapping) or in an > ERP bootstrapping exchange (explicit bootstrapping). This is done by > including the EAP-DSRK-Request AVP in the Diameter EAP Request (DER) > message. The EAP-DSRK-Request AVP contains the domain or server > > [Seb] "domain or server" => see my note on this topic later in this > mail. It should not be "or" here anyway. > > identity required to derive the DSRK. > > In successful case, the DSRK is carried by the EAP-DSRK AVP in the > Diameter EAP Answer (DEA) message. Along with the EAP-DSRK AVP, an > EAP-DSRK-Name AVP MUST be used to send the DSRK's keyname and an EAP- > > [Seb] It's not the DSRK's keyname, but the EMSKname. I think the name of > this AVP is error-prone, we should rename it (see a proposal later in > this mail). > > DSRK-Lifetime AVP MUST be used to send the DSRK's lifetime. > (Editor's Note: add a figure ?). > > > [Seb] I think a new section "Interoperability" is needed to examine > cases where one of the element does not support ERP functions. > [Seb] I think also a new section "Deployment" is needed, to detail the > assumptions: ER servers in the path of EAP exchanges, authenticators > capable of advertizing the domain name that must match the ER local > server's, ... Figures for all the different situations would be very > useful to clarify for everbody. Cases to consider: The peer has a valid > EMSK? The peer knows the local domain name? A local ER server is > present, and bootstrapped for this EAP session? (Actually about this > last point, how does the peer know this information, if implicit > bootstrapping was used???) > I can provide draft text for these sections, if you think they are needed. It seems to be a good idea . > > > 4. Command Codes > > This document re-uses the EAP application commands [1] and does not > define new command codes. > > > [LM] this section is not required as there is nothing specific for ERP. > We should skip it. > [Seb] I agree, unless there is a kind of standard template for > Diameter-related RFCs? Lionel's comment was about a old version of this section detailing DER/DEA message. I would prefer to keep it as it is. > > 5. Attribute Value Pair Definitions > > This section defines new AVPs for the ERP support within Diameter EAP > Application. > > > [Seb] For all the following new AVPs, I think naming convention ERP-* > instead of EAP-* would be better (ERP-DSRK-Request, ...). Any thoughts? I'm ok. > > 5.1. EAP-DSRK-Request AVP > > > [Seb] It has not been discussed (AFAIK) what should happen if several ER > servers are in the path of the full EAP authentication. Can this AVP > appear several times (if we have hierarchy of re-authentication domains, > for example?) I think the answer is no, since the domain name advertized > by the authenticator must match the ER server's domain name. Maybe it > should be written somewhere that the ER server adds this AVP only if no > such AVP is already in the message? I'm not sure that we can have multiple domains on a AAA path. But this would probably add security. > > The EAP-DSRK Request AVP (AVP Code TBD) is of type DiameterIdentity. > This AVP fulfills two purposes: first, it indicates that a ERP server > is located in the local domain that is willing to play the role of an > ERP server for a particular session. Second, it conveys information > about the domain name to the Diameter/EAP/ERP server. (Editor's > Note: it is FFS if DiameterIdentity is the correct type). > > [Seb] Actually both information may be needed, the local ER server name > (for authorization purpose on the home server for example, and > Autorization Indication TLV in ERP message) and the domain name (can > this domain-name be different from the Origin-Realm?). Therefore I think > a Grouped AVP would be better, containing two sub-AVP for the Domain > name and ER server name. I think the authorization process will be based on the domain name and not the local ER server name. > [Seb] By the way, about discussions if DiameterIdentity type is suitable > for a domain name, I want to highlight that the Origin-Realm AVP (for > example) defined in Diameter Base Protocol is also of DiameterIdentity > type, and does not contain a FQDN, AFAIU. Interesting since DiameterIdentity is defined as a FQDN. > > [JiK] What happens if Diameter server does not understand this AVP but > still returns OK for the full EAP authentication? > [Seb] In that case, the DSRK will not be included in the last message of > the round of exchanges, and the ER local server will know that home > domain does not do ERP, AFAIU. Do you think a note about this is needed? A clarification may be useful. > > 5.2. EAP-DSRK AVP > > > [Seb] Since the following three AVP are always sent together and parsed > together, I believe a Grouped AVP would be nice here. It adds few > overhead and makes parsing of the message on the ER server faster. Any > opinion? > > The EAP-DSRK AVP (AVP Code TBD) is of type OctetString. This AVP > contains keying material to be used by the visited domain (i.e. the > DSRK). Exactly how this keying material is derived is beyond the > scope of this document. > > [Seb] Maybe reference to the ERP's RFC would be better here, such as > "Exactly how this keying material is derived is described in RFC 5295 > and RFC 5296" ? > right. > [Seb] It may also be worth noting that this AVP MUST be removed by the > ER local server that added the EAP-DSRK-Request on the first EAP > exchange (might be several exchanges earlier, leading to routing > constaints...) or ERP bootstrap exchange? > > 5.3. EAP-DSRK-Name AVP > > The EAP-DSRK-Name AVP (AVP Code TBD) is of type OctetString. This > AVP contains the EMSKname which identifies the keying material. How > > [Seb] Because the AVP contains the EMSKname, it may be better to rename > it to EAP-EMSK-Name (or ERP-EMSK-Name)? Because RFC5295 also defines > how to derive DSRKName, so it may be error-prone here. I think you're right. > > this name is derived is beyond the scope of this document and defined > in [5]. > > > [pending JiK's] if this is a plain text name, use UTF8String. Otherwise > OctetString is OK. AFter reading a bit of the ERP draft it says there > that the 64 bits username part of the NAI is encoded in hexadecimal. In > 5.3.2 of ERP draft it is says the username takes up to 128 octets and in > 5.3.3 it is though said the username takes up to 16 octets. So I am a > bit confused what the username part actually keeps inside in this AVP > and how it is encoded. > > > > 5.4. EAP-DSRK-Lifetime AVP > > The EAP-DSRK-Lifetime AVP (AVP Code TBD) is of type Unsigned64 and > contains the DSRK lifetime in seconds. (Editor's Note: it is FFS if > Unsigned32 is not sufficient). (Editor's Note: it is FFS default > value) > > [Seb] There is also a pending comment from Jouni about the "0" value. > Does "default value" refer to this value of 0, or to the case where the > AVP is not included? "0" value could mean infinite I guess. > > > 6. AVP Occurrence Table > > The following table lists the AVPs that may optionally be present in > the DER and DEA commands [1]. > > > > > +---------------+ > | Command-Code | > +-+-----+-----+-+ > Attribute Name | DER | DEA | > -------------------------------|-----+-----+ > EAP-DSRK-Request | 0-1 | 0 | > EAP-DSRK | 0 | 0-1 | > EAP-DSRK-Name | 0 | 0-1 | > EAP-DSRK-Lifetime | 0 | 0-1 | > +-----+-----+ > > Figure 1: DER and DEA Commands AVP Table > > When the EAP-DSRK AVP is present in the DEA then the EAP-DSRK-Name > and the EAP-DSRK-Lifetime MUST also be present. > > > 7. AVP Flag Rules > > The following table describes the Diameter AVPs, their AVP Code > values, types, possible flag values, and whether the AVP MAY be > encrypted. The Diameter base [3] specifies the AVP Flag rules for > AVPs in Section 4.5. > > > +---------------------+ > | AVP Flag Rules | > +----+-----+----+-----+----+ > AVP Section | | |SHLD|MUST | | > Attribute Name Code Defined Data Type |MUST| MAY |NOT |NOT |Encr| > ------------------------------------------+----+-----+----+-----+----+ > EAP-DSRK-Request TBD 4.7.1 DiamIdent | | P | | V,M | Y | > EAP-DSRK TBD 4.7.2 OctetString| | P | | V,M | Y | > EAP-DSRK-Name TBD 4.7.3 OctetString| | P | | V,M | Y | > EAP-DSRK-Lifetime TBD 4.7.4 Unsigned64 | | P | | V,M | Y | > ------------------------------------------+----+-----+----+-----+----+ > > Due to space constraints, the short form DiamIdent is used to > represent DiameterIdentity. > > Figure 2: AVP Flag Rules Table > > > 8. Security Considerations > > The security considerations specified in RFC 4072 [1], and RFC 3588 > [3] are applicable to this document. > EAP channel bindings may be necessary to ensure that the Diameter > client and the server are in sync regarding the key Requesting > Entity's Identity. Specifically, the Requesting Entity advertises > its identity through the EAP lower layer, and the user or the EAP > peer communicates that identity to the EAP server (and the EAP server > communicates that identity to the Diameter server) via the EAP method > for user/peer to server verification of the Requesting Entity's > Identity. > > > [Seb] I can't see what the threat is here, since the key is given to the > authenticator by the AAA proxy (who identifies and authorizes the peer > to act as an authenticator, according to rfc3588) and on the peer's side > it's derived locally from the EMSK. I may be missing the point, sorry > for this... This is a "known" issue within EAP Keying Framework concerning Channel Binding. You can find more info. in RFC 3748 section 7.15: http://tools.ietf.org/html/rfc3748#page-55 > > > 9. IANA Considerations > > This document requires IANA registration of the following new AVPs to > the AVP registry established by RFC 3588 [3]: > > o EAP-DSRK-Request > > o EAP-DSRK > > o EAP-DSRK-Name > > o EAP-DSRK-Lifetime > > > 10. Acknowledgments > > Vidya Narayanan reviewed a rough draft version and found some errors. > Many thanks for her input. > > > 11. References > > 11.1. Normative References > > > [Seb] I am not sure the difference between "Normative" and "Informative" > but I think that the RFC defining the rules for key derivation in ERP, > 5295, should be in Normative section? I think so. > > [1] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible > Authentication Protocol (EAP) Application", RFC 4072, > August 2005. > > [2] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- > authentication Protocol (ERP)", RFC 5296, August 2008. > > [3] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, > "Diameter Base Protocol", RFC 3588, September 2003. > > [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement > Levels", BCP 14, RFC 2119, March 1997. > > 11.2. Informative References > > [5] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, > "Specification for the Derivation of Root Keys from an Extended > Master Session Key (EMSK)", RFC 5295, August 2008. > > [6] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. > Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, > June 2004. > > > > Thank you for reading this veeeeery long mail ^^. thanks for this careful review ! I'll send you the xml file to produce a -01 version based on your comments. Regards, Julien > > 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 > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 29 06:04:41 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 716F63A6A71; Thu, 29 Jan 2009 06:04:41 -0800 (PST) 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 E92D43A6AF7 for ; Thu, 29 Jan 2009 06:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 ElRlRGIEF+zV for ; Thu, 29 Jan 2009 06:04:40 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id E0CAE3A6A71 for ; Thu, 29 Jan 2009 06:04:39 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so6372557yxg.49 for ; Thu, 29 Jan 2009 06:04:20 -0800 (PST) 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=m4NkWLAA9er/gkUEJwalMVOzpUiI6hpmceM2g05aioU=; b=xJbmL++hlwBQ17QVaPcBrjaual4XirvWEgTtQEizu3s2EQwrUgt6MJq1Vujl03aEYn tPHTu79Mn5yHbYjn1VMTaVF8q+MHPiRLm1k4oNzN60xWFYeNL7oyH6tyqn9JFosX7v58 vpW/RvQEbJSeiektWmZnha04QRl88TpqIML5E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=wFhlxIuCat53U9sTKwi8R3FgqZxhvTG/XUcetc97Lo22ldGro4/rkUBmB2siSn8H5g v6wJVLncHuVZXYWDSbHvQo6+7ThLEOaDMoQv3RI+17rfd1th110Kopft3tw++KH8ZVU3 isCqy7k84xTnjR7JzID4ey/lPFuO8BWy1Ybd8= MIME-Version: 1.0 Received: by 10.100.119.17 with SMTP id r17mr62786anc.130.1233237860445; Thu, 29 Jan 2009 06:04:20 -0800 (PST) Date: Thu, 29 Jan 2009 19:34:20 +0530 Message-ID: <4f9fd9700901290604j6c28b54akcb4526c90fc7343@mail.gmail.com> From: Rashmi Rath To: dime@ietf.org Subject: [Dime] Query Regarding ASR. 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: , Content-Type: multipart/mixed; boundary="===============1816200744==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1816200744== Content-Type: multipart/alternative; boundary=001485f54658986c9e04619f90f2 --001485f54658986c9e04619f90f2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi All, I have a query regarding server initiated termination (ASR) and the associated messages that are required to be sent. As per rfc 4006 server initiate re-authorization in a ongoing session, a credit control client that receives an RAR message with Session-Id equal to a currently active credit-control session MUST acknowledge the request by sending RAA with Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) and MUST initiate the credit re-authorization toward the server by sending a CCR-UPDATE. The Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA message to indicate that an additional message (i.e., CCR-UPDATE) is required to complete the procedure. Similarly nothing is mentioned about server initiated termination (ASR). What should be the Result-Code in ASA "DIAMETER_SUCCESS" or "DIAMETER_LIMITED_SUCCESS"? Is it mandatory to send CCR-T after ASR/ASA? -- Thanks & Regards Ranjan --001485f54658986c9e04619f90f2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi All,


I have a query regarding server initiated term= ination (ASR) and the associated messages that are required to be sent.
=
As per rfc 40= 06 server initiate re-authorization in a ongoing session, a credit control = client that receives an RAR message with Session-Id equal to a currently ac= tive credit-control session MUST acknowledge the request by sending RAA wit= h Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) and MUST initiate the credit = re-authorization toward the server by sending a CCR-UPDATE. The Result-Code= 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA message to indic= ate that an additional message (i.e., CCR-UPDATE) is required to complete t= he procedure.

Similarly nothing is mentioned about server initiated termination (ASR)= .

What should be the Result-Code in ASA &quo= t;DIAMETER_SUCCESS" or "DIAMETER_LIMITED_SUCCESS"?

Is it mandatory to send CCR-T after ASR/ASA?

-- Thanks & Regards

Ranjan
--001485f54658986c9e04619f90f2-- --===============1816200744== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1816200744==-- From dime-bounces@ietf.org Thu Jan 29 07:51:22 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38AEE3A6A22; Thu, 29 Jan 2009 07:51:22 -0800 (PST) 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 96F9028C1A0 for ; Thu, 29 Jan 2009 07:51:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[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 US5uQb28s9Ho for ; Thu, 29 Jan 2009 07:51:20 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id DB16B3A6843 for ; Thu, 29 Jan 2009 07:51:19 -0800 (PST) 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 n0TFowDm014230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 29 Jan 2009 16:50:58 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n0TFovDu011610; Thu, 29 Jan 2009 16:50:57 +0100 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Jan 2009 16:50:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 29 Jan 2009 16:50:56 +0100 Message-ID: <83C460304D3E5445B0388381DC69F2ED01E5F1AC@DEMUEXC013.nsn-intra.net> In-Reply-To: <4f9fd9700901290604j6c28b54akcb4526c90fc7343@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Query Regarding ASR. Thread-Index: AcmCGn72oKsD8yYSQx2wTCd1pYR04gADUhAw References: <4f9fd9700901290604j6c28b54akcb4526c90fc7343@mail.gmail.com> From: "Schendel, Jens (NSN - DE/Berlin)" To: "ext Rashmi Rath" , X-OriginalArrivalTime: 29 Jan 2009 15:50:57.0555 (UTC) FILETIME=[602C3630:01C98229] Subject: Re: [Dime] Query Regarding ASR. 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: , Content-Type: multipart/mixed; boundary="===============1820416255==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1820416255== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C98229.605B6C14" This is a multi-part message in MIME format. ------_=_NextPart_001_01C98229.605B6C14 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 you may check the state machine section 7, there is the appropriate hint. =20 The event 'User service terminated' can be triggered by various reasons, e.g., normal user termination, network failure, and ASR (Abort-Session-Request)... =20 State Event Action New State ---------------------------------------------------------------- Open User service terminated Send PendingT CC termination req. =20 I don't see any rationale for Limited_Success indication and yes, CCR(terminate) is to be send. =20 Jens =20 ________________________________ Von: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] Im Auftrag von ext Rashmi Rath Gesendet: Donnerstag, 29. Januar 2009 15:04 An: dime@ietf.org Betreff: [Dime] Query Regarding ASR. Hi All, I have a query regarding server initiated termination (ASR) and the associated messages that are required to be sent. As per rfc 4006 server initiate re-authorization in a ongoing session, a credit control client that receives an RAR message with Session-Id equal to a currently active credit-control session MUST acknowledge the request by sending RAA with Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) and MUST initiate the credit re-authorization toward the server by sending a CCR-UPDATE. The Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA message to indicate that an additional message (i.e., CCR-UPDATE) is required to complete the procedure. Similarly nothing is mentioned about server initiated termination (ASR). What should be the Result-Code in ASA "DIAMETER_SUCCESS" or "DIAMETER_LIMITED_SUCCESS"? Is it mandatory to send CCR-T after ASR/ASA? --=20 Thanks & Regards Ranjan ------_=_NextPart_001_01C98229.605B6C14 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
you may check the state machine section 7, = there is the=20 appropriate hint.
 
 The event 'User service terminated' can = be triggered=20 by various
   reasons, e.g., normal user termination, = network=20 failure, and ASR
   = (Abort-Session-Request)...
 
State    =20 Event           &n= bsp;           &nb= sp; =20 Action           New=20 State
----------------------------------------------------------------=
Open     =20 User service terminated       =20 Send           &nb= sp; PendingT
        &nbs= p;            = ;            =         CC=20 termination
         &nbs= p;            = ;            =        req.
 
I don't see any rationale for = Limited_Success=20 indication and yes, CCR(terminate) is to be send.
 
Jens
 

Von: dime-bounces@ietf.org=20 [mailto:dime-bounces@ietf.org] Im Auftrag von ext Rashmi=20 Rath
Gesendet: Donnerstag, 29. Januar 2009 15:04
An: = dime@ietf.org
Betreff: [Dime] Query Regarding=20 ASR.

Hi All,


I have a query regarding = server=20 initiated termination (ASR) and the associated messages that are = required to be=20 sent.

As per=20 rfc 4006 server initiate re-authorization in a ongoing session, a credit = control=20 client that receives an RAR message with Session-Id equal to a currently = active=20 credit-control session MUST acknowledge the request by sending RAA with=20 Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) and MUST initiate the credit = re-authorization toward the server by sending a CCR-UPDATE. The = Result-Code 2002=20 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA message to indicate = that an=20 additional message (i.e., CCR-UPDATE) is required to complete the=20 procedure.

Similarly nothing is mentioned about server initiated=20 termination (ASR).

What should = be the=20 Result-Code in ASA "DIAMETER_SUCCESS" or = "DIAMETER_LIMITED_SUCCESS"?

Is=20 it mandatory to send CCR-T after ASR/ASA?

-- =
Thanks &=20 Regards

Ranjan
------_=_NextPart_001_01C98229.605B6C14-- --===============1820416255== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1820416255==-- From dime-bounces@ietf.org Thu Jan 29 20:40:27 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33A473A6851; Thu, 29 Jan 2009 20:40:27 -0800 (PST) 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 D50E13A6851 for ; Thu, 29 Jan 2009 20:40:25 -0800 (PST) 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 HboPP4+BR5tu for ; Thu, 29 Jan 2009 20:40:24 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by core3.amsl.com (Postfix) with ESMTP id 9B31A3A6822 for ; Thu, 29 Jan 2009 20:40:24 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so165426ana.4 for ; Thu, 29 Jan 2009 20:40:06 -0800 (PST) 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=UlhUnl57nP5wq3nhvtPycjMkwwZ+gvRVcPb/ILWnN3A=; b=RAX00XGYqNZxQ/ybKWe26GJAtOhZ0w88g3rJMq8+h2/JE5oITyG2C8iH28YC5HO6vi +oDsxIO2NMyNEk9U1e6gESPkDuM+JYqi+BXM9jDYsoizCmqKlLnYbrK3t1dVRyiuO4wV fq5k/Ntijoy0DWo24cPDx6Igc/OiAlNmSNTJc= 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=grXl1/VZvFI8OORpFxG/qj8r7IIzPZOH2LwJfq31BtfaBJgdnpfINjQkcpX1Rah7Il wfdgkTMkTmCMFb9ghaqrj4iOFoICPGzK/317bJZ2HQ8D0qtm2YuB1l/RAxwyk/7+jaFh 5J/C9CLCY0ibCYQtLdrf3HNPODTxl34LI2IWU= MIME-Version: 1.0 Received: by 10.100.134.10 with SMTP id h10mr766360and.150.1233290406024; Thu, 29 Jan 2009 20:40:06 -0800 (PST) In-Reply-To: <83C460304D3E5445B0388381DC69F2ED01E5F1AC@DEMUEXC013.nsn-intra.net> References: <4f9fd9700901290604j6c28b54akcb4526c90fc7343@mail.gmail.com> <83C460304D3E5445B0388381DC69F2ED01E5F1AC@DEMUEXC013.nsn-intra.net> Date: Fri, 30 Jan 2009 10:10:05 +0530 Message-ID: <4f9fd9700901292040o5bc7bd94p610cbfbe8758498c@mail.gmail.com> From: Rashmi Rath To: "Schendel, Jens (NSN - DE/Berlin)" Cc: dime@ietf.org Subject: Re: [Dime] Query Regarding ASR. 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: , Content-Type: multipart/mixed; boundary="===============1840968955==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1840968955== Content-Type: multipart/alternative; boundary=0016e644c7088e55290461abccf9 --0016e644c7088e55290461abccf9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Jens, Thanks for your response. Since CCR-T is must, I think diameter client should send ASA with Result-Code:DIAMETER_LIMITED_SUCCESS (2002) to indicate session termination is not complete and expecting additional message (i.e. CCR-TERMINATE) to complete the procedure. Thanks Ranjan On Thu, Jan 29, 2009 at 9:20 PM, Schendel, Jens (NSN - DE/Berlin) < jens.schendel@nsn.com> wrote: > Hi, > > you may check the state machine section 7, there is the appropriate hint. > > The event 'User service terminated' can be triggered by various > reasons, e.g., normal user termination, network failure, and ASR > (Abort-Session-Request)... > > State Event Action New State > ---------------------------------------------------------------- > Open User service terminated Send PendingT > CC termination > req. > > I don't see any rationale for Limited_Success indication and yes, > CCR(terminate) is to be send. > > Jens > > > ------------------------------ > *Von:* dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] *Im Auftrag > von *ext Rashmi Rath > *Gesendet:* Donnerstag, 29. Januar 2009 15:04 > *An:* dime@ietf.org > *Betreff:* [Dime] Query Regarding ASR. > > Hi All, > > > I have a query regarding server initiated termination (ASR) and the > associated messages that are required to be sent. > > As per rfc 4006 server initiate re-authorization in a ongoing session, a > credit control client that receives an RAR message with Session-Id equal to > a currently active credit-control session MUST acknowledge the request by > sending RAA with Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) and MUST > initiate the credit re-authorization toward the server by sending a > CCR-UPDATE. The Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used > in the RAA message to indicate that an additional message (i.e., CCR-UPDATE) > is required to complete the procedure. > > Similarly nothing is mentioned about server initiated termination (ASR). > > What should be the Result-Code in ASA "DIAMETER_SUCCESS" or > "DIAMETER_LIMITED_SUCCESS"? > > Is it mandatory to send CCR-T after ASR/ASA? > > -- > Thanks & Regards > > Ranjan > -- Thanks & Regards Ranjan --0016e644c7088e55290461abccf9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Jens,

Thanks for your response.

Since CCR-T is must, I thi= nk diameter client should send ASA with Result-Code:DIAMETER_LIMITED_SUCCES= S (2002) to indicate session termination is not complete and expecting addi= tional message (i.e. CCR-TERMINATE) to complete the procedure.


Thanks
Ranjan

On Thu, Jan 29, = 2009 at 9:20 PM, Schendel, Jens (NSN - DE/Berlin) <jens.schendel@nsn.com> = wrote:
Hi,
 
you may check the state machine section 7, there is the=20 appropriate hint.
 
 The event 'User service terminated' can be= triggered=20 by various
   reasons, e.g., normal user termination, network= =20 failure, and ASR
   (Abort-Session-Request)...
 
State    =20 Event           &nbs= p;            &= nbsp;=20 Action           New=20 State
----------------------------------------------------------------Open     =20 User service terminated       =20 Send            = ; PendingT
         &n= bsp;            = ;            &n= bsp;      CC=20 termination
          =             &nb= sp;            =       req.
 
I don't see any rationale for Limited_Success=20 indication and yes, CCR(terminate) is to be send.
 
Jens
 

Von: dime-bounces@ietf.org=20 [mailto:dime-bou= nces@ietf.org] Im Auftrag von ext Rashmi=20 Rath
Gesendet: Donnerstag, 29. Januar 2009 15:04
An:=20 dime@ietf.org
= Betreff: [Dime] Query Regarding=20 ASR.

Hi All,


I have a query regarding server= =20 initiated termination (ASR) and the associated messages that are required t= o be=20 sent.

= As per=20 rfc 4006 server initiate re-authorization in a ongoing session, a credit co= ntrol=20 client that receives an RAR message with Session-Id equal to a currently ac= tive=20 credit-control session MUST acknowledge the request by sending RAA with=20 Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) and MUST initiate the credit=20 re-authorization toward the server by sending a CCR-UPDATE. The Result-Code= 2002=20 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA message to indicate th= at an=20 additional message (i.e., CCR-UPDATE) is required to complete the=20 procedure.

Similarly nothing is mentioned about server initiated=20 termination (ASR).

What should be the=20 Result-Code in ASA "DIAMETER_SUCCESS" or "DIAMETER_LIMITED_S= UCCESS"?

Is=20 it mandatory to send CCR-T after ASR/ASA?

--
Thank= s &=20 Regards

Ranjan



--
Thanks & Regards
Ranjan
--0016e644c7088e55290461abccf9-- --===============1840968955== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1840968955==-- From dime-bounces@ietf.org Thu Jan 29 22:02:58 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3024C3A6AAA; Thu, 29 Jan 2009 22:02:58 -0800 (PST) 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 7EDB93A688F for ; Thu, 29 Jan 2009 22:02:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 8-CVueB0tvqv for ; Thu, 29 Jan 2009 22:02:53 -0800 (PST) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 74FA13A6AA4 for ; Thu, 29 Jan 2009 22:02:51 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 5E35A901BA for ; Fri, 30 Jan 2009 01:02:29 -0500 (EST) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27051-09 for ; Fri, 30 Jan 2009 01:02:28 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Fri, 30 Jan 2009 01:02:28 -0500 (EST) Received: from exchindia3.starentnetworks.com ([10.6.7.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jan 2009 01:01:48 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 30 Jan 2009 11:31:44 +0530 Message-ID: <69FADB84C90B1248A7DE59422771FA0C07928792@exchindia3.starentnetworks.com> In-Reply-To: <4f9fd9700901292040o5bc7bd94p610cbfbe8758498c@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Query on Disconnecting Peer connections thread-index: AcmClqtD8zUtv8lgSIGZ3mHuqboCAgACP6ig From: "Senapati, Dhirananda" To: X-OriginalArrivalTime: 30 Jan 2009 06:01:48.0937 (UTC) FILETIME=[3D2AE790:01C982A0] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: [Dime] Query on Disconnecting Peer connections 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: , Content-Type: multipart/mixed; boundary="===============1074299108==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1074299108== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C982A0.3A5F0D0E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C982A0.3A5F0D0E Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi All, I was verifying the peer state machine of rfc 3588bis-15.I found some mismatch between section 5.4 and Diameter peer state machine. Section 5.4: Disconnecting Peer connections =20 "Upon receipt of the message, the Disconnect-Peer-Answer is returned, which SHOULD contain an error if messages have recently been forwarded, and are likely in flight, which would otherwise cause a race condition. The receiver of the Disconnect-Peer-Answer initiates the transport disconnects. The sender of the Disconnect-Peer-Answer should be able to detect the transport closure and cleanup the connection." Section 5.6: Peer state machine=20 R-Open R-Rcv-DPR R-Snd-DPA, Closed R-Disc The transport layer connection is disconnected, and local resources are freed. As per state machine sender of the Disconnect-Peer-Answer is the one who initiate the transport disconnect but as per the section 5.4 the receiver of the Disconnect-Peer-Answer initiates the transport disconnect. Please let me know which one is correct. Thanks and Regards, Dhirananda =20 ------_=_NextPart_001_01C982A0.3A5F0D0E Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi All,

I was verifying the peer state machine of rfc 3588bis-15.I found some = mismatch between section 5.4 and Diameter peer state machine.

Section 5.4:  Disconnecting Peer = connections

 

   "Upon receipt of the =
message, the Disconnect-Peer-Answer is returned, which SHOULD contain an =
error if messages have recently been forwarded, and are likely in =
flight, which would otherwise cause a race condition. The receiver of =
the Disconnect-Peer-Answer initiates the transport disconnects. The =
sender of the Disconnect-Peer-Answer should be able to detect the =
transport closure and cleanup the =
connection."


Section 5.6: Peer state machine

R-Open           R-Rcv-DPR        R-Snd-DPA,       Closed           &= nbsp;           &n= bsp;     
                   &= nbsp;           &n= bsp;  R-Disc


The transport layer connection is disconnected, and local resources are = freed.

As per state machine sender of the Disconnect-Peer-Answer is the one who initiate the transport disconnect but as per the section 5.4 the = receiver of the Disconnect-Peer-Answer initiates the transport disconnect.

Please let me know which one is correct.


Thanks and Regards,
Dhirananda

 

------_=_NextPart_001_01C982A0.3A5F0D0E-- --===============1074299108== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1074299108==-- From dime-bounces@ietf.org Fri Jan 30 03:44:03 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D45BA28C249; Fri, 30 Jan 2009 03:44:03 -0800 (PST) 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 1D4B228C23B for ; Fri, 30 Jan 2009 03:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[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 HDsrv7BGeN01 for ; Fri, 30 Jan 2009 03:44:01 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 6467B3A67D2 for ; Fri, 30 Jan 2009 03:44:00 -0800 (PST) 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 n0UBhdZB004498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 30 Jan 2009 12:43:39 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n0UBhdVs027687; Fri, 30 Jan 2009 12:43:39 +0100 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Jan 2009 12:43:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 30 Jan 2009 12:43:37 +0100 Message-ID: <83C460304D3E5445B0388381DC69F2ED01E5F485@DEMUEXC013.nsn-intra.net> In-Reply-To: <4f9fd9700901292040o5bc7bd94p610cbfbe8758498c@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Query Regarding ASR. Thread-Index: AcmClNVW6onToawaSNyRpI7ar1BW2AAOdqzQ References: <4f9fd9700901290604j6c28b54akcb4526c90fc7343@mail.gmail.com> <83C460304D3E5445B0388381DC69F2ED01E5F1AC@DEMUEXC013.nsn-intra.net> <4f9fd9700901292040o5bc7bd94p610cbfbe8758498c@mail.gmail.com> From: "Schendel, Jens (NSN - DE/Berlin)" To: "ext Rashmi Rath" X-OriginalArrivalTime: 30 Jan 2009 11:43:39.0163 (UTC) FILETIME=[FE3706B0:01C982CF] Cc: dime@ietf.org Subject: Re: [Dime] Query Regarding ASR. 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: , Content-Type: multipart/mixed; boundary="===============0202074040==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0202074040== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C982CF.FE84A7D2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C982CF.FE84A7D2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ranjan, =20 hmm, not sure whether sending of ASR and following CCR should be considerd as procedure (as it is done for RAR).=20 RFC3588 says about this result code "additional processing is required by the application in order to provide service to the user." Here it is just about service termination. Anyway, most important is the sending of CCR(terminate) to finalize the session correctly. =20 Jens ________________________________ Von: ext Rashmi Rath [mailto:rashmir.rath@gmail.com]=20 Gesendet: Freitag, 30. Januar 2009 05:40 An: Schendel, Jens (NSN - DE/Berlin) Cc: dime@ietf.org Betreff: Re: [Dime] Query Regarding ASR. Hi Jens, Thanks for your response. Since CCR-T is must, I think diameter client should send ASA with Result-Code:DIAMETER_LIMITED_SUCCESS (2002) to indicate session termination is not complete and expecting additional message (i.e. CCR-TERMINATE) to complete the procedure. Thanks Ranjan On Thu, Jan 29, 2009 at 9:20 PM, Schendel, Jens (NSN - DE/Berlin) wrote: Hi, =20 you may check the state machine section 7, there is the appropriate hint. =20 The event 'User service terminated' can be triggered by various reasons, e.g., normal user termination, network failure, and ASR (Abort-Session-Request)... =20 State Event Action New State ---------------------------------------------------------------- Open User service terminated Send PendingT CC termination req. =20 I don't see any rationale for Limited_Success indication and yes, CCR(terminate) is to be send. =20 Jens =20 ________________________________ Von: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] Im Auftrag von ext Rashmi Rath Gesendet: Donnerstag, 29. Januar 2009 15:04 An: dime@ietf.org Betreff: [Dime] Query Regarding ASR. =09 =09 Hi All, =09 =09 I have a query regarding server initiated termination (ASR) and the associated messages that are required to be sent. =09 As per rfc 4006 server initiate re-authorization in a ongoing session, a credit control client that receives an RAR message with Session-Id equal to a currently active credit-control session MUST acknowledge the request by sending RAA with Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) and MUST initiate the credit re-authorization toward the server by sending a CCR-UPDATE. The Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA message to indicate that an additional message (i.e., CCR-UPDATE) is required to complete the procedure. =09 Similarly nothing is mentioned about server initiated termination (ASR). =09 What should be the Result-Code in ASA "DIAMETER_SUCCESS" or "DIAMETER_LIMITED_SUCCESS"? =09 Is it mandatory to send CCR-T after ASR/ASA? =09 --=20 Thanks & Regards =09 Ranjan =09 --=20 Thanks & Regards Ranjan ------_=_NextPart_001_01C982CF.FE84A7D2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Ranjan,
 
hmm, not sure whether sending of ASR and = following CCR=20 should be considerd as procedure (as it is done for RAR). =
RFC3588 says about this result code "additional = processing=20 is required by the application in order to provide service to the = user."=20 Here it is just about service termination.
Anyway, most important is the sending of = CCR(terminate) to=20 finalize the session correctly.
 
Jens

Von: ext Rashmi Rath=20 [mailto:rashmir.rath@gmail.com]
Gesendet: Freitag, 30. Januar = 2009=20 05:40
An: Schendel, Jens (NSN - DE/Berlin)
Cc:=20 dime@ietf.org
Betreff: Re: [Dime] Query Regarding=20 ASR.

Hi Jens,

Thanks for your response.

Since CCR-T = is must,=20 I think diameter client should send ASA with=20 Result-Code:DIAMETER_LIMITED_SUCCESS (2002) to indicate session = termination is=20 not complete and expecting additional message (i.e. CCR-TERMINATE) to = complete=20 the procedure.


Thanks
Ranjan

On Thu, Jan 29, 2009 at 9:20 PM, Schendel, Jens = (NSN -=20 DE/Berlin) <jens.schendel@nsn.com>=20 wrote:
Hi,
 
you may=20 check the state machine section 7, there is the appropriate=20 hint.
 
 The event 'User service terminated' can be triggered by = various
   reasons, e.g., normal user termination, = network=20 failure, and ASR
  =20 (Abort-Session-Request)...
 
State    =20 = Event           &n= bsp;           &nb= sp; =20 Action           New = = State
----------------------------------------------------------------=
Open     =20 User service terminated       =20 = Send           &nb= sp; PendingT
        &nbs= p;            = ;            =         CC=20 = termination
         &nbs= p;            = ;            =        req.
 
I don't=20 see any rationale for Limited_Success indication and yes, = CCR(terminate)=20 is to be send.
 
Jens
 

Von: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org]=20 Im Auftrag von ext Rashmi Rath
Gesendet: Donnerstag, = 29.=20 Januar 2009 15:04
An: dime@ietf.org
Betreff: [Dime] Query = Regarding=20 ASR.

Hi All,


I have a query regarding = server=20 initiated termination (ASR) and the associated messages that are = required to=20 be sent.

As per=20 rfc 4006 server initiate re-authorization in a ongoing session, a = credit=20 control client that receives an RAR message with Session-Id equal to a = currently active credit-control session MUST acknowledge the request = by=20 sending RAA with Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) and MUST = initiate=20 the credit re-authorization toward the server by sending a CCR-UPDATE. = The=20 Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA = message=20 to indicate that an additional message (i.e., CCR-UPDATE) is required = to=20 complete the procedure.

Similarly nothing is mentioned about = server=20 initiated termination (ASR).

What = should be the=20 Result-Code in ASA "DIAMETER_SUCCESS" or = "DIAMETER_LIMITED_SUCCESS"?

Is=20 it mandatory to send CCR-T after ASR/ASA?

-- =
Thanks &=20 Regards

Ranjan


--
Thanks & = Regards

Ranjan
------_=_NextPart_001_01C982CF.FE84A7D2-- --===============0202074040== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0202074040==-- From dime-bounces@ietf.org Fri Jan 30 04:43:12 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00F7828C10A; Fri, 30 Jan 2009 04:43:12 -0800 (PST) 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 845AD3A6B34 for ; Fri, 30 Jan 2009 04:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.105 X-Spam-Level: ** X-Spam-Status: No, score=2.105 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJdvDDn-61bW for ; Fri, 30 Jan 2009 04:43:10 -0800 (PST) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 064DD3A68E0 for ; Fri, 30 Jan 2009 04:43:08 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KEA00ENPBB2HU@szxga02-in.huawei.com> for dime@ietf.org; Fri, 30 Jan 2009 20:42:39 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KEA00HU6BB2FT@szxga02-in.huawei.com> for dime@ietf.org; Fri, 30 Jan 2009 20:42:38 +0800 (CST) Received: from santosh ([10.18.28.85]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KEA00064BB1J9@szxml06-in.huawei.com> for dime@ietf.org; Fri, 30 Jan 2009 20:42:38 +0800 (CST) Date: Fri, 30 Jan 2009 18:12:37 +0530 From: Santhosh In-reply-to: <83C460304D3E5445B0388381DC69F2ED01E5F485@DEMUEXC013.nsn-intra.net> To: dime@ietf.org Message-id: <002a01c982d8$3be3a010$551c120a@china.huawei.com> Organization: HTIPL MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcmClNVW6onToawaSNyRpI7ar1BW2AAOdqzQAAIcfvA= Subject: [Dime] I jave a query regarding rfc-4006 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: santhoshkk@huawei.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, I have been trying to understand the credit control application usage. I could not understand 2 points. 1)what is the meaning of "queue termination event". what application will have to do with this 2) second question is regarding "Change in rating condition". I want to know as per the state machine change in rating condition will indicate the application to queue the rating condition event. But I want to know how will application will come about change in rating condition. Waiting for answers..... In rfc-4006 PendingI User service terminated Queue PendingI termination event PendingI Change in rating condition Queue PendingI changed rating condition event Regds Santhosh _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Jan 31 14:04:04 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 923233A67D7; Sat, 31 Jan 2009 14:04:04 -0800 (PST) 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 3C9D13A67D7 for ; Sat, 31 Jan 2009 14:04:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=-0.964, BAYES_40=-0.185] 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 jKh8SaoGPecK for ; Sat, 31 Jan 2009 14:04:02 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 19F9F3A67A1 for ; Sat, 31 Jan 2009 14:04:01 -0800 (PST) Received: (qmail invoked by alias); 31 Jan 2009 22:03:42 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp037) with SMTP; 31 Jan 2009 23:03:42 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+RFUYENQiRJcUNlPaAcVER/YM/Y2wQ/Icp/zwHZy ONHHhuFG0bSlt9 From: "Hannes Tschofenig" To: Date: Sun, 1 Feb 2009 00:04:26 +0200 Message-ID: <045901c983ef$e232eb20$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcmD7+GOxQGZ3s4qS6y+dIdt3wMUVg== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.78 Subject: [Dime] Virtual Interim Meeting 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi all, Based on the entered preferences we have a "winner". Thanks for the feedback. >>> 19th February 8PM PST <<< I will setup a conference bridge and Webex. Details will follow Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime