From dime-bounces@ietf.org Fri Sep 01 05:37:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ5Sk-0007Xf-7X; Fri, 01 Sep 2006 05:37:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ5Sj-0007XX-GL for dime@ietf.org; Fri, 01 Sep 2006 05:37:21 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ5Si-0003lB-6V for dime@ietf.org; Fri, 01 Sep 2006 05:37:21 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 899A22FDA1; Fri, 1 Sep 2006 11:37:11 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1GJ5VM-00044W-Gy; Fri, 01 Sep 2006 11:40:04 +0200 Date: Fri, 1 Sep 2006 11:40:04 +0200 From: Julien Bournelle To: Hannes Tschofenig Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Message-ID: <20060901094004.GA15632@ipv6-3.int-evry.fr> References: <44F75D9B.6030808@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44F75D9B.6030808@gmx.net> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi hannes, all, On Fri, Sep 01, 2006 at 12:07:23AM +0200, Hannes Tschofenig wrote: > Hi all, > > we have had long discussions about the App-ID vs. Service-Type usage for > Diameter MIPv6 Bootstrapping. > > It is time to see what the group thinks. Please indicate whether you > prefer (1) an App-ID or (2) a Service-Type solution for > > (a) NAS-to-AAAH communication (as required by the integrated scenario; > as one part of the solution component) I would prefer (2) or a NAS-Port-Type AVP. The reason is that here we're doing AAA for network access. And as part of this process we deliver the HA to the NAS. Then the MN gets this info by using DHCP (cf. draft-ietf-mip6-integrated-dhc). Adding an AVP to the AAA exchanges (Diameter NASREQ/EAP) helps the AAA server to know if the NAS supports what is described in the mentionned draft (mip6-integrated). > (b) HA-to-AAAH communication (as used by the split scenario and the > integrated scenario) I would prefer (1) The reason is that the AAA server must know that it is doing AAA for the Mobile IPv6 service and not for network access. And to have this, from what we've discussed in the list (and from what I've understood), we need an App-ID. regards, Julien Bournelle > > It might be useful to state a reason for your decision. > > Please also indicate whether some aspects are still unclear to you. > > Ciao > Hannes > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime -- julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Sep 01 20:27:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJJM7-00080t-2V; Fri, 01 Sep 2006 20:27:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJJM5-00080b-7X for dime@ietf.org; Fri, 01 Sep 2006 20:27:25 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJJM3-0001w9-UL for dime@ietf.org; Fri, 01 Sep 2006 20:27:25 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4X002A9VSFWU@usaga01-in.huawei.com> for dime@ietf.org; Fri, 01 Sep 2006 17:24:15 -0700 (PDT) Received: from Nakhjiri73701 (pool-71-112-12-134.sttlwa.dsl-w.verizon.net [71.112.12.134]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4X00IW3VS9LD@usaga01-in.huawei.com> for dime@ietf.org; Fri, 01 Sep 2006 17:24:15 -0700 (PDT) Date: Fri, 01 Sep 2006 17:27:15 -0700 From: Madjid Nakhjiri Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type In-reply-to: <44F75D9B.6030808@gmx.net> To: 'Hannes Tschofenig' , dime@ietf.org Message-id: <003301c6ce26$8aa3d670$2f01a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcbNSpD2LBD2LGwqSyiysjZ6Lj8coQA2307Q X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Hannes, For b) I prefer an App ID (1) as it is not clear whether the MIP6 within Diameter will be similar to that of MIP4 (messaging, functionality and all), in fact they may be quite different. For a) I still prefer a new App ID (1) for the same reason as above. Although in this case you may still need a new NAS-type (=HA) if HA is also a NAS. Madjid -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: Thursday, August 31, 2006 3:07 PM To: dime@ietf.org Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Hi all, we have had long discussions about the App-ID vs. Service-Type usage for Diameter MIPv6 Bootstrapping. It is time to see what the group thinks. Please indicate whether you prefer (1) an App-ID or (2) a Service-Type solution for (a) NAS-to-AAAH communication (as required by the integrated scenario; as one part of the solution component) (b) HA-to-AAAH communication (as used by the split scenario and the integrated scenario) It might be useful to state a reason for your decision. Please also indicate whether some aspects are still unclear to you. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Sep 02 10:16:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJWIi-0003Jm-8M; Sat, 02 Sep 2006 10:16:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJWIh-0003Jh-F1 for dime@ietf.org; Sat, 02 Sep 2006 10:16:47 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJWIg-0005dU-12 for dime@ietf.org; Sat, 02 Sep 2006 10:16:47 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id B0BF82FD62; Sat, 2 Sep 2006 16:16:39 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1GJWLL-0004rZ-6V; Sat, 02 Sep 2006 16:19:31 +0200 Date: Sat, 2 Sep 2006 16:19:31 +0200 From: Julien Bournelle To: Madjid Nakhjiri Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Message-ID: <20060902141931.GA18687@ipv6-3.int-evry.fr> References: <44F75D9B.6030808@gmx.net> <003301c6ce26$8aa3d670$2f01a8c0@china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003301c6ce26$8aa3d670$2f01a8c0@china.huawei.com> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi madjid, Just some clarifications: On Fri, Sep 01, 2006 at 05:27:15PM -0700, Madjid Nakhjiri wrote: > Hi Hannes, > > For b) I prefer an App ID (1) as it is not clear whether the MIP6 within > Diameter will be similar to that of MIP4 (messaging, functionality and all), > in fact they may be quite different. As I already explained in a previous mail, mip6 case and mip4 case are totally different. To sum up a little, in mip4, the MN sends a Reg-Req with a MN-AAA-Auth field to the HA. The HA then uses RFC4004 with the AAA server. The message sent by the HA carry the MN-AAA-Auth for the authentication. RFC4004 is a little more complicated since the Reg-Req could be sent to the FA and some keys may be distributed. In the mip6 case, the MN uses IKEv2 with the HA to setup necessary IPsec SAs and EAP is used by the HA to authenticate the MN. The HA relies on a AAA/EAP server. Thus we'll have DER/DEA messages but in the same time, the AAA/EAP server need to know that it is for mip6 service and not for network access. > > For a) I still prefer a new App ID (1) for the same reason as above. > Although in this case you may still need a new NAS-type (=HA) if HA is also > a NAS. for a/ the NAS is a NAS for network access. It can't be a HA. The MN (or not MN) contacts the NAS to be authenticated for network access. The NAS even doesn't know if it's a MN or not. I don't understand how it can be similar to (b). Based on the user'profile, the AAA may decide to provide him HA info through AAA messages (AAA if NASREQ is used, DEA if it's DIameter EAP). Then the MN gets the HA info with DHCP. And finally it contacts the HA as it is described in the split document. Hope it helps, Julien > > Madjid > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Thursday, August 31, 2006 3:07 PM > To: dime@ietf.org > Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type > > Hi all, > > we have had long discussions about the App-ID vs. Service-Type usage for > Diameter MIPv6 Bootstrapping. > > It is time to see what the group thinks. Please indicate whether you > prefer (1) an App-ID or (2) a Service-Type solution for > > (a) NAS-to-AAAH communication (as required by the integrated scenario; > as one part of the solution component) > > (b) HA-to-AAAH communication (as used by the split scenario and the > integrated scenario) > > It might be useful to state a reason for your decision. > > Please also indicate whether some aspects are still unclear to you. > > Ciao > Hannes > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime -- julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Sep 04 10:35:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKFXn-0007ds-52; Mon, 04 Sep 2006 10:35:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKFXm-0007dn-FE for dime@ietf.org; Mon, 04 Sep 2006 10:35:22 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKFXl-000539-5T for dime@ietf.org; Mon, 04 Sep 2006 10:35:22 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k84EZEsN000672 for ; Mon, 4 Sep 2006 07:35:18 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k84EZDwd003424 for ; Mon, 4 Sep 2006 09:35:14 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Date: Mon, 4 Sep 2006 22:35:12 +0800 Message-ID: In-Reply-To: <44F75D9B.6030808@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Thread-Index: AcbNSgwhiQaTcWNsSfes6cwAocklEAC3cEpA From: "Ram O V Vishnu-A14676" To: "Hannes Tschofenig" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hannes, I prefer=20 - (1) for (a): because the peers (agents for example) could decide based on the advertisement of the app that its capable of, lets say, the integrated scenario. - (1) for (b): But I don't understand how a node in the middle (like the HA) can decide the purpose of the EAP authentication (for mip6 service or network access), EAP being an e-2-e protocol. It runs between the MN (EAP peer) and the Backend Server (AAA). So if the AAA is confused about what its trying to authenticate for, then shouldn't the MN be too? Regards, Vishnu. Motorola +91 9844178052 [*] General [] Motorola Internal Use Only -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: Friday, September 01, 2006 3:37 AM To: dime@ietf.org Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type=20 Hi all, we have had long discussions about the App-ID vs. Service-Type usage for Diameter MIPv6 Bootstrapping. It is time to see what the group thinks. Please indicate whether you=20 prefer (1) an App-ID or (2) a Service-Type solution for (a) NAS-to-AAAH communication (as required by the integrated scenario;=20 as one part of the solution component) (b) HA-to-AAAH communication (as used by the split scenario and the=20 integrated scenario) It might be useful to state a reason for your decision. Please also indicate whether some aspects are still unclear to you. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Sep 04 12:37:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKHS1-00083K-FA; Mon, 04 Sep 2006 12:37:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKHS0-00083A-0J for dime@ietf.org; Mon, 04 Sep 2006 12:37:32 -0400 Received: from ns1.nitro.ca ([216.209.86.226] helo=mailscanner.nitro.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKHRy-0001lB-HO for dime@ietf.org; Mon, 04 Sep 2006 12:37:31 -0400 Received: from bws14.bridgewatersystems.com (bws14.bridgewatersystems.com [216.113.7.14]) by mailscanner.nitro.ca (8.12.11/8.12.11) with ESMTP id k84GbAII010654 for ; Mon, 4 Sep 2006 12:37:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Date: Mon, 4 Sep 2006 12:37:21 -0400 Message-ID: In-Reply-To: <44F75D9B.6030808@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Thread-Index: AcbNSjfF4kE7A2hYREuHEJgU4Nl51gC9W/fQ From: "Avi Lior" To: "Hannes Tschofenig" , X-Nitro-MailScanner-Information: Please contact the ISP for more information X-Nitro-MailScanner: Found to be clean X-Nitro-MailScanner-SpamCheck: not spam, SpamAssassin (score=0.477, required 4, BAYES_00 -2.60, RCVD_IN_XBL 3.08) X-MailScanner-From: avi@bridgewatersystems.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I need to resynch on the scenarios. However, if we decide to modify ServiceType or NAS Port type we should modify NAS Port Type to add a MIPv6 port type etc. We should not touch ServiceType (this will help us in RADIUS as well). > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Thursday, August 31, 2006 6:07 PM > To: dime@ietf.org > Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type >=20 > Hi all, >=20 > we have had long discussions about the App-ID vs.=20 > Service-Type usage for Diameter MIPv6 Bootstrapping. >=20 > It is time to see what the group thinks. Please indicate=20 > whether you prefer (1) an App-ID or (2) a Service-Type solution for >=20 > (a) NAS-to-AAAH communication (as required by the integrated=20 > scenario; as one part of the solution component) >=20 > (b) HA-to-AAAH communication (as used by the split scenario=20 > and the integrated scenario) >=20 > It might be useful to state a reason for your decision. >=20 > Please also indicate whether some aspects are still unclear to you. >=20 > Ciao > Hannes >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Sep 04 12:42:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKHWT-0002t9-91; Mon, 04 Sep 2006 12:42:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKHWS-0002sz-39 for dime@ietf.org; Mon, 04 Sep 2006 12:42:08 -0400 Received: from ns1.nitro.ca ([216.209.86.226] helo=mailscanner.nitro.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKHWQ-0002rf-JV for dime@ietf.org; Mon, 04 Sep 2006 12:42:08 -0400 Received: from bws14.bridgewatersystems.com (bws14.bridgewatersystems.com [216.113.7.14]) by mailscanner.nitro.ca (8.12.11/8.12.11) with ESMTP id k84Gfort010826 for ; Mon, 4 Sep 2006 12:41:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Date: Mon, 4 Sep 2006 12:42:02 -0400 Message-ID: In-Reply-To: <20060901094004.GA15632@ipv6-3.int-evry.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Thread-Index: AcbNqn54RfA9aSOxS9S0wh88k+TMxgClhgGg From: "Avi Lior" To: "Julien Bournelle" , "Hannes Tschofenig" X-Nitro-MailScanner-Information: Please contact the ISP for more information X-Nitro-MailScanner: Found to be clean X-Nitro-MailScanner-SpamCheck: not spam, SpamAssassin (score=0.477, required 4, BAYES_00 -2.60, RCVD_IN_XBL 3.08) X-MailScanner-From: avi@bridgewatersystems.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Julien, =20 > -----Original Message----- > From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]=20 > Sent: Friday, September 01, 2006 5:40 AM > To: Hannes Tschofenig > Cc: dime@ietf.org > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs.=20 > Service-Type >=20 > Hi hannes, all, >=20 > On Fri, Sep 01, 2006 at 12:07:23AM +0200, Hannes Tschofenig wrote: > > Hi all, > >=20 > > we have had long discussions about the App-ID vs.=20 > Service-Type usage=20 > > for Diameter MIPv6 Bootstrapping. > >=20 > > It is time to see what the group thinks. Please indicate=20 > whether you=20 > > prefer (1) an App-ID or (2) a Service-Type solution for > >=20 > > (a) NAS-to-AAAH communication (as required by the=20 > integrated scenario;=20 > > as one part of the solution component) >=20 > I would prefer (2) or a NAS-Port-Type AVP. >=20 > The reason is that here we're doing AAA for network access.=20 > And as part of this process we deliver the HA to the NAS.=20 > Then the MN gets this info by using DHCP (cf.=20 > draft-ietf-mip6-integrated-dhc). > Adding an AVP to the AAA exchanges (Diameter NASREQ/EAP)=20 > helps the AAA server to know if the NAS supports what is=20 > described in the mentionned draft (mip6-integrated). I prefer NAS-Port-Type but what would you set the value of the NAS-Port-Type to? And similarly the if you were to use Service-Type, what value would you set it to to provide a hint. How does the AAA know that the NAS can support the attribute it will send to it. If it doesn't support the attributes the NAS will just throw the attributes away no? =20 > > (b) HA-to-AAAH communication (as used by the split scenario and the=20 > > integrated scenario) >=20 > I would prefer (1)=20 > =20 > The reason is that the AAA server must know that it is doing=20 > AAA for the Mobile IPv6 service and not for network access.=20 > And to have this, from what we've discussed in the list (and=20 > from what I've understood), we need an App-ID. I agree. > regards, >=20 > Julien Bournelle >=20 > >=20 > > It might be useful to state a reason for your decision. > >=20 > > Please also indicate whether some aspects are still unclear to you. > >=20 > > Ciao > > Hannes > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime >=20 > -- > julien.bournelle at int-evry.fr >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 05 02:00:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKTzQ-0003tq-Ra; Tue, 05 Sep 2006 02:00:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKTzQ-0003tl-9x for dime@ietf.org; Tue, 05 Sep 2006 02:00:52 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKTzO-0007Jz-SD for dime@ietf.org; Tue, 05 Sep 2006 02:00:52 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Sep 2006 08:00:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Date: Tue, 5 Sep 2006 07:58:34 +0200 Message-ID: <5D25AEFB114D034FBDC8B156FCA78E0301359AC1@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Thread-Index: AcbNSg2hbYJTZZqtSoqOxe246C6gYADYn3pQ From: To: , X-OriginalArrivalTime: 05 Sep 2006 06:00:47.0159 (UTC) FILETIME=[A1A7D470:01C6D0B0] X-Spam-Score: 0.2 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi HAnnes,=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: 1. syyskuuta 2006 1:07 > To: dime@ietf.org > Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type=20 >=20 > Hi all, >=20 > we have had long discussions about the App-ID vs.=20 > Service-Type usage for=20 > Diameter MIPv6 Bootstrapping. >=20 > It is time to see what the group thinks. Please indicate whether you=20 > prefer (1) an App-ID or (2) a Service-Type solution for >=20 > (a) NAS-to-AAAH communication (as required by the integrated=20 > scenario;=20 > as one part of the solution component) I would prefer (2) for now.. or as long as the NAS-2-AAAH main function is to provide access authentication, where the backend AAA may return MIP6 bootstrapping info (as an enhancement) based e.g. on the user subscription profile. If we go for more stuff on NAS-2-AAAH like HoA/prefix etc then (1) might be better. > (b) HA-to-AAAH communication (as used by the split scenario and the=20 > integrated scenario) I would prefer (1) here. The use of EAP for MIP6 bootstrapping purposes and for 'normal' EAP-based access authentication are different applications imho. (although in IKEv2 vs 802.1X case e.g. NAS-Port-Type could be used to make this distinction.. e.g. how 3GPP WLAN stuff does it) > It might be useful to state a reason for your decision. >=20 > Please also indicate whether some aspects are still unclear to you. >=20 > Ciao > Hannes Cheers, Jouni >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 05 03:35:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKVSk-0006xo-VC; Tue, 05 Sep 2006 03:35:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKVSi-0006xX-Sc for dime@ietf.org; Tue, 05 Sep 2006 03:35:12 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKVSh-0002hK-Hw for dime@ietf.org; Tue, 05 Sep 2006 03:35:12 -0400 Received: by ug-out-1314.google.com with SMTP id m2so2039623uge for ; Tue, 05 Sep 2006 00:35:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=uF0PEx+oPkrlbLZ/NJdeKMYHsI2+yYYn9i7tfkYTCS9w37tifT4q2lIfEP2PdSRiSFp/BMAvj9fqch6Tek8LnJ9GE7L9bMQLc4IZUoUGW7IAqvl3o+DcDUd52SXrnKqfZaMIoWUrfd6kqCwFZiDCrka2yEwf4tClNUHTmYct7tE= Received: by 10.67.93.7 with SMTP id v7mr3441597ugl; Tue, 05 Sep 2006 00:35:10 -0700 (PDT) Received: by 10.66.243.16 with HTTP; Tue, 5 Sep 2006 00:35:10 -0700 (PDT) Message-ID: Date: Tue, 5 Sep 2006 09:35:10 +0200 From: "Gerardo Giaretta" To: Hannes.Tschofenig@gmx.net Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type In-Reply-To: <5D25AEFB114D034FBDC8B156FCA78E0301359AC1@SEHAN021MB.tcad.telia.se> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5D25AEFB114D034FBDC8B156FCA78E0301359AC1@SEHAN021MB.tcad.telia.se> X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Hannes, I agree with Jouni. I prefer (2) for NAS-AAAH and (1) for AAAH-HA. In my understanding, there are no mandatory AVPs for NAS-AAAH and therefore I don't see a need of a new application; it's just a MIP-specific information that is piggybacked in the network access authentication procedure. Concerning AAAH-HA, I think it is a much cleaner approach to define a new application, since it does not anything to do with network authentication. --Gerardo On 9/5/06, jouni.korhonen@teliasonera.com wrote: > Hi HAnnes, > > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: 1. syyskuuta 2006 1:07 > > To: dime@ietf.org > > Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type > > > > Hi all, > > > > we have had long discussions about the App-ID vs. > > Service-Type usage for > > Diameter MIPv6 Bootstrapping. > > > > It is time to see what the group thinks. Please indicate whether you > > prefer (1) an App-ID or (2) a Service-Type solution for > > > > (a) NAS-to-AAAH communication (as required by the integrated > > scenario; > > as one part of the solution component) > > I would prefer (2) for now.. or as long as the NAS-2-AAAH main function > is to provide access authentication, where the backend AAA may return > MIP6 > bootstrapping info (as an enhancement) based e.g. on the user > subscription > profile. If we go for more stuff on NAS-2-AAAH like HoA/prefix etc then > (1) > might be better. > > > (b) HA-to-AAAH communication (as used by the split scenario and the > > integrated scenario) > > I would prefer (1) here. The use of EAP for MIP6 bootstrapping purposes > and for 'normal' EAP-based access authentication are different > applications > imho. (although in IKEv2 vs 802.1X case e.g. NAS-Port-Type could be used > to > make this distinction.. e.g. how 3GPP WLAN stuff does it) > > > It might be useful to state a reason for your decision. > > > > Please also indicate whether some aspects are still unclear to you. > > > > Ciao > > Hannes > > Cheers, > Jouni > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 05 07:07:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKYmB-0006kw-1H; Tue, 05 Sep 2006 07:07:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKYm9-0006h8-Gq for dime@ietf.org; Tue, 05 Sep 2006 07:07:29 -0400 Received: from ns1.nitro.ca ([216.209.86.226] helo=mailscanner.nitro.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKYm7-0008Mc-T1 for dime@ietf.org; Tue, 05 Sep 2006 07:07:29 -0400 Received: from bws14.bridgewatersystems.com (bws14.bridgewatersystems.com [216.113.7.14]) by mailscanner.nitro.ca (8.12.11/8.12.11) with ESMTP id k85B6tap019897 for ; Tue, 5 Sep 2006 07:06:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Date: Tue, 5 Sep 2006 07:07:13 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Thread-Index: AcbQvh7bPvAj9t8NS7OQLZqLFIeXqwAG0/MQ From: "Avi Lior" To: "Gerardo Giaretta" , X-Nitro-MailScanner-Information: Please contact the ISP for more information X-Nitro-MailScanner: Found to be clean X-Nitro-MailScanner-SpamCheck: not spam, SpamAssassin (score=0.477, required 4, BAYES_00 -2.60, RCVD_IN_XBL 3.08) X-MailScanner-From: avi@bridgewatersystems.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I must be missing something. In the integrated scenario, what would the NAS put in Service-Type? I think in the integrated scenario neither Port-Type or Service-Type needs to be touched. As far as I understand the NAS is either executing EAP Application or NAS REQ. It does not know whether the user will result in having subsequent Mobile IP service or not. The only thing the AAA server can do is to send the MIPv6 attributes as optional (M bit off) and hope that if the NAS does not understand the attributes it would have some logic to bootstrap a different way. We could improve the situration somewhat. We could have the NAS indicate that it supports MIPv6 bootstrapping by including hints in the AR (a capability hint). Where the NAS includes HA-IP address AVP both indicating that it can support bootstrapping and if the HA-IP address is not ALL-ZEROS or ALL ONES it provides a hint that it can support dynamic HA assignement. Ofcourse we could introduce the concept of capability hints more formally in Diameter -- This is missing today. =20 > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com]=20 > Sent: Tuesday, September 05, 2006 3:35 AM > To: Hannes.Tschofenig@gmx.net > Cc: dime@ietf.org > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs.=20 > Service-Type >=20 > Hi Hannes, >=20 > I agree with Jouni. I prefer (2) for NAS-AAAH and (1) for=20 > AAAH-HA. In my understanding, there are no mandatory AVPs for=20 > NAS-AAAH and therefore I don't see a need of a new=20 > application; it's just a MIP-specific information that is=20 > piggybacked in the network access authentication procedure. >=20 > Concerning AAAH-HA, I think it is a much cleaner approach to=20 > define a new application, since it does not anything to do=20 > with network authentication. >=20 > --Gerardo >=20 > On 9/5/06, jouni.korhonen@teliasonera.com=20 > wrote: > > Hi HAnnes, > > > > > -----Original Message----- > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > Sent: 1. syyskuuta 2006 1:07 > > > To: dime@ietf.org > > > Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs.=20 > > > Service-Type > > > > > > Hi all, > > > > > > we have had long discussions about the App-ID vs. > > > Service-Type usage for > > > Diameter MIPv6 Bootstrapping. > > > > > > It is time to see what the group thinks. Please indicate=20 > whether you=20 > > > prefer (1) an App-ID or (2) a Service-Type solution for > > > > > > (a) NAS-to-AAAH communication (as required by the integrated=20 > > > scenario; as one part of the solution component) > > > > I would prefer (2) for now.. or as long as the NAS-2-AAAH main=20 > > function is to provide access authentication, where the backend AAA=20 > > may return > > MIP6 > > bootstrapping info (as an enhancement) based e.g. on the user=20 > > subscription profile. If we go for more stuff on NAS-2-AAAH like=20 > > HoA/prefix etc then > > (1) > > might be better. > > > > > (b) HA-to-AAAH communication (as used by the split=20 > scenario and the=20 > > > integrated scenario) > > > > I would prefer (1) here. The use of EAP for MIP6 bootstrapping=20 > > purposes and for 'normal' EAP-based access authentication are=20 > > different applications imho. (although in IKEv2 vs 802.1X case e.g.=20 > > NAS-Port-Type could be used to make this distinction.. e.g.=20 > how 3GPP=20 > > WLAN stuff does it) > > > > > It might be useful to state a reason for your decision. > > > > > > Please also indicate whether some aspects are still=20 > unclear to you. > > > > > > Ciao > > > Hannes > > > > Cheers, > > Jouni > > > > > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 05 07:38:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKZGZ-0006Wg-Fy; Tue, 05 Sep 2006 07:38:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKZGY-0006WY-Eb for dime@ietf.org; Tue, 05 Sep 2006 07:38:54 -0400 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKZGW-0005nl-Pq for dime@ietf.org; Tue, 05 Sep 2006 07:38:54 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Sep 2006 13:38:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Date: Tue, 5 Sep 2006 13:38:45 +0200 Message-ID: <5D25AEFB114D034FBDC8B156FCA78E0301359AF4@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Thread-Index: AcbQvh7bPvAj9t8NS7OQLZqLFIeXqwAG0/MQAAD7olA= From: To: , , X-OriginalArrivalTime: 05 Sep 2006 11:38:49.0667 (UTC) FILETIME=[DAF8F130:01C6D0DF] X-Spam-Score: 0.2 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Avi,=20 > I must be missing something. >=20 > In the integrated scenario, what would the NAS put in Service-Type? Something MIP6 indicating that is not defined yet. > I think in the integrated scenario neither Port-Type or Service-Type > needs to be touched. >=20 > As far as I understand the NAS is either executing EAP Application or > NAS REQ. It does not know whether the user will result in having > subsequent Mobile IP service or not. Yes. But there was this discussion/idea earlier that it could be benefical from the AAA server point of view to have a hint whether the NAS supports intergrated scenario at all. > The only thing the AAA server can do is to send the MIPv6=20 > attributes as > optional (M bit off) and hope that if the NAS does not understand the > attributes it would have some logic to bootstrap a different way. >=20 > We could improve the situration somewhat. We could have the NAS > indicate that it supports MIPv6 bootstrapping by including=20 > hints in the > AR (a capability hint). Where the NAS includes HA-IP=20 > address AVP both And why can't the Service-Type or NAS-Port-type serve as a hint? e.g. NAS-Port-Type has been used in some architectures to distinguish between .1X or IKEv2 originating EAP requests. Well.. we could also put a bunch of AVPs to the access requests that would serve as a capability hint. > indicating that it can support bootstrapping and if the HA-IP=20 > address is > not ALL-ZEROS or ALL ONES it provides a hint that it can=20 > support dynamic > HA assignement. >=20 > Ofcourse we could introduce the concept of capability hints more > formally in Diameter -- This is missing today. Cheers, Jouni >=20 >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com]=20 > > Sent: Tuesday, September 05, 2006 3:35 AM > > To: Hannes.Tschofenig@gmx.net > > Cc: dime@ietf.org > > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs.=20 > > Service-Type > >=20 > > Hi Hannes, > >=20 > > I agree with Jouni. I prefer (2) for NAS-AAAH and (1) for=20 > > AAAH-HA. In my understanding, there are no mandatory AVPs for=20 > > NAS-AAAH and therefore I don't see a need of a new=20 > > application; it's just a MIP-specific information that is=20 > > piggybacked in the network access authentication procedure. > >=20 > > Concerning AAAH-HA, I think it is a much cleaner approach to=20 > > define a new application, since it does not anything to do=20 > > with network authentication. > >=20 > > --Gerardo > >=20 > > On 9/5/06, jouni.korhonen@teliasonera.com=20 > > wrote: > > > Hi HAnnes, > > > > > > > -----Original Message----- > > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > Sent: 1. syyskuuta 2006 1:07 > > > > To: dime@ietf.org > > > > Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs.=20 > > > > Service-Type > > > > > > > > Hi all, > > > > > > > > we have had long discussions about the App-ID vs. > > > > Service-Type usage for > > > > Diameter MIPv6 Bootstrapping. > > > > > > > > It is time to see what the group thinks. Please indicate=20 > > whether you=20 > > > > prefer (1) an App-ID or (2) a Service-Type solution for > > > > > > > > (a) NAS-to-AAAH communication (as required by the integrated=20 > > > > scenario; as one part of the solution component) > > > > > > I would prefer (2) for now.. or as long as the NAS-2-AAAH main=20 > > > function is to provide access authentication, where the=20 > backend AAA=20 > > > may return > > > MIP6 > > > bootstrapping info (as an enhancement) based e.g. on the user=20 > > > subscription profile. If we go for more stuff on NAS-2-AAAH like=20 > > > HoA/prefix etc then > > > (1) > > > might be better. > > > > > > > (b) HA-to-AAAH communication (as used by the split=20 > > scenario and the=20 > > > > integrated scenario) > > > > > > I would prefer (1) here. The use of EAP for MIP6 bootstrapping=20 > > > purposes and for 'normal' EAP-based access authentication are=20 > > > different applications imho. (although in IKEv2 vs 802.1X=20 > case e.g.=20 > > > NAS-Port-Type could be used to make this distinction.. e.g.=20 > > how 3GPP=20 > > > WLAN stuff does it) > > > > > > > It might be useful to state a reason for your decision. > > > > > > > > Please also indicate whether some aspects are still=20 > > unclear to you. > > > > > > > > Ciao > > > > Hannes > > > > > > Cheers, > > > Jouni > > > > > > > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 05 14:01:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKfEM-0001hu-5s; Tue, 05 Sep 2006 14:01:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKfEL-0001hd-5u for dime@ietf.org; Tue, 05 Sep 2006 14:01:01 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKfEI-0007gQ-Lq for dime@ietf.org; Tue, 05 Sep 2006 14:01:01 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 7BCBB9003F; Tue, 5 Sep 2006 14:00:54 -0400 (EDT) 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 15429-08; Tue, 5 Sep 2006 14:00:52 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP; Tue, 5 Sep 2006 14:00:52 -0400 (EDT) X-MessageTextProcessor: DisclaimIt (2.70.271) [Starent Networks Corp.] Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Sep 2006 14:00:52 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Date: Tue, 5 Sep 2006 14:00:52 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D78372F7@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type thread-index: AcbQve32DsTzli0VTBqGsho6+y743gAVyDsA From: "Chowdhury, Kuntal" To: "Gerardo Giaretta" , Importance: normal Priority: normal X-OriginalArrivalTime: 05 Sep 2006 18:00:52.0628 (UTC) FILETIME=[3A1F3540:01C6D115] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Gerardo, Are there any mandatory AVP between HA-HAAA for IKEv2 auth for MIP6? -Kuntal > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > Sent: Tuesday, September 05, 2006 2:35 AM > To: Hannes.Tschofenig@gmx.net > Cc: dime@ietf.org > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type >=20 > Hi Hannes, >=20 > I agree with Jouni. I prefer (2) for NAS-AAAH and (1) for AAAH-HA. In > my understanding, there are no mandatory AVPs for NAS-AAAH and > therefore I don't see a need of a new application; it's just a > MIP-specific information that is piggybacked in the network access > authentication procedure. >=20 > Concerning AAAH-HA, I think it is a much cleaner approach to define a > new application, since it does not anything to do with network > authentication. >=20 > --Gerardo >=20 > On 9/5/06, jouni.korhonen@teliasonera.com > wrote: > > Hi HAnnes, > > > > > -----Original Message----- > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > Sent: 1. syyskuuta 2006 1:07 > > > To: dime@ietf.org > > > Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type > > > > > > Hi all, > > > > > > we have had long discussions about the App-ID vs. > > > Service-Type usage for > > > Diameter MIPv6 Bootstrapping. > > > > > > It is time to see what the group thinks. Please indicate whether you > > > prefer (1) an App-ID or (2) a Service-Type solution for > > > > > > (a) NAS-to-AAAH communication (as required by the integrated > > > scenario; > > > as one part of the solution component) > > > > I would prefer (2) for now.. or as long as the NAS-2-AAAH main function > > is to provide access authentication, where the backend AAA may return > > MIP6 > > bootstrapping info (as an enhancement) based e.g. on the user > > subscription > > profile. If we go for more stuff on NAS-2-AAAH like HoA/prefix etc then > > (1) > > might be better. > > > > > (b) HA-to-AAAH communication (as used by the split scenario and the > > > integrated scenario) > > > > I would prefer (1) here. The use of EAP for MIP6 bootstrapping purposes > > and for 'normal' EAP-based access authentication are different > > applications > > imho. (although in IKEv2 vs 802.1X case e.g. NAS-Port-Type could be used > > to > > make this distinction.. e.g. how 3GPP WLAN stuff does it) > > > > > It might be useful to state a reason for your decision. > > > > > > Please also indicate whether some aspects are still unclear to you. > > > > > > Ciao > > > Hannes > > > > Cheers, > > Jouni > > > > > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime "This email message and any attachments are confidential information of = Starent Networks, Corp. The information transmitted may not be used to = create or change any contractual obligations of Starent Networks, Corp. = Any review, retransmission, dissemination or other use of, or taking of = any action in reliance upon this e-mail and its attachments by persons = or entities other than the intended recipient is prohibited. If you are = not the intended recipient, please notify the sender immediately -- by = replying to this message or by sending an email to = postmaster@starentnetworks.com -- and destroy all copies of this message = and any attachments without reading or disclosing their contents. Thank = you." _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 05 14:09:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKfMe-0004Zg-FS; Tue, 05 Sep 2006 14:09:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKfMd-0004ZS-8E for dime@ietf.org; Tue, 05 Sep 2006 14:09:35 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKfMb-0000v9-NE for dime@ietf.org; Tue, 05 Sep 2006 14:09:35 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 4B8BD90014; Tue, 5 Sep 2006 14:09:30 -0400 (EDT) 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 15617-02; Tue, 5 Sep 2006 14:09:29 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP; Tue, 5 Sep 2006 14:09:29 -0400 (EDT) X-MessageTextProcessor: DisclaimIt (2.70.271) [Starent Networks Corp.] Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Sep 2006 14:09:29 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Date: Tue, 5 Sep 2006 14:09:28 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D78372F8@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type thread-index: AcbQvh7bPvAj9t8NS7OQLZqLFIeXqwAG0/MQAA7zb8A= From: "Chowdhury, Kuntal" To: "Avi Lior" , "Gerardo Giaretta" , Importance: normal Priority: normal X-OriginalArrivalTime: 05 Sep 2006 18:09:29.0220 (UTC) FILETIME=[6E08E440:01C6D116] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org All, Here is a scenario that may need to be covered. In some cases, local HA assignment is optimal for transport efficiency perspective. Diameter MIP4 application allows this. In such a case the ASP =3D=3D MSP and the = HA is assigned locally (in the visited network).=20 To enable this case, in the integrated scenario, the NAS/VAAA needs to indicate it's capability to assign an HA in the local network to the HAAA. The HAAA may allow or disallow this local HA assignment based on policy of the MSA.=20 The NAS/VAAA may need to include a hint in the AAA message to the HAAA at the time of access authentication that it is capable of providing an HA to the MN. This capability indication (hint) can be either sent via a new MIP6 specific AVP or it can be conveyed via an existing AVP (I don't know if one exists). If we decide to include this (local HA assignment), and we decide to include this mip6 specific hint in the NAS-HAAA communication, we may have to choose the most appropriate option (1) vs. (2). Comments? -Kuntal > -----Original Message----- > From: Avi Lior [mailto:avi@bridgewatersystems.com] > Sent: Tuesday, September 05, 2006 6:07 AM > To: Gerardo Giaretta; Hannes.Tschofenig@gmx.net > Cc: dime@ietf.org > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type >=20 > I must be missing something. >=20 > In the integrated scenario, what would the NAS put in Service-Type? >=20 > I think in the integrated scenario neither Port-Type or Service-Type > needs to be touched. >=20 > As far as I understand the NAS is either executing EAP Application or > NAS REQ. It does not know whether the user will result in having > subsequent Mobile IP service or not. >=20 > The only thing the AAA server can do is to send the MIPv6 attributes as > optional (M bit off) and hope that if the NAS does not understand the > attributes it would have some logic to bootstrap a different way. >=20 > We could improve the situration somewhat. We could have the NAS > indicate that it supports MIPv6 bootstrapping by including hints in the > AR (a capability hint). Where the NAS includes HA-IP address AVP both > indicating that it can support bootstrapping and if the HA-IP address is > not ALL-ZEROS or ALL ONES it provides a hint that it can support dynamic > HA assignement. >=20 > Ofcourse we could introduce the concept of capability hints more > formally in Diameter -- This is missing today. >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > Sent: Tuesday, September 05, 2006 3:35 AM > > To: Hannes.Tschofenig@gmx.net > > Cc: dime@ietf.org > > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > Service-Type > > > > Hi Hannes, > > > > I agree with Jouni. I prefer (2) for NAS-AAAH and (1) for > > AAAH-HA. In my understanding, there are no mandatory AVPs for > > NAS-AAAH and therefore I don't see a need of a new > > application; it's just a MIP-specific information that is > > piggybacked in the network access authentication procedure. > > > > Concerning AAAH-HA, I think it is a much cleaner approach to > > define a new application, since it does not anything to do > > with network authentication. > > > > --Gerardo > > > > On 9/5/06, jouni.korhonen@teliasonera.com > > wrote: > > > Hi HAnnes, > > > > > > > -----Original Message----- > > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > Sent: 1. syyskuuta 2006 1:07 > > > > To: dime@ietf.org > > > > Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > Service-Type > > > > > > > > Hi all, > > > > > > > > we have had long discussions about the App-ID vs. > > > > Service-Type usage for > > > > Diameter MIPv6 Bootstrapping. > > > > > > > > It is time to see what the group thinks. Please indicate > > whether you > > > > prefer (1) an App-ID or (2) a Service-Type solution for > > > > > > > > (a) NAS-to-AAAH communication (as required by the integrated > > > > scenario; as one part of the solution component) > > > > > > I would prefer (2) for now.. or as long as the NAS-2-AAAH main > > > function is to provide access authentication, where the backend AAA > > > may return > > > MIP6 > > > bootstrapping info (as an enhancement) based e.g. on the user > > > subscription profile. If we go for more stuff on NAS-2-AAAH like > > > HoA/prefix etc then > > > (1) > > > might be better. > > > > > > > (b) HA-to-AAAH communication (as used by the split > > scenario and the > > > > integrated scenario) > > > > > > I would prefer (1) here. The use of EAP for MIP6 bootstrapping > > > purposes and for 'normal' EAP-based access authentication are > > > different applications imho. (although in IKEv2 vs 802.1X case e.g. > > > NAS-Port-Type could be used to make this distinction.. e.g. > > how 3GPP > > > WLAN stuff does it) > > > > > > > It might be useful to state a reason for your decision. > > > > > > > > Please also indicate whether some aspects are still > > unclear to you. > > > > > > > > Ciao > > > > Hannes > > > > > > Cheers, > > > Jouni > > > > > > > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime "This email message and any attachments are confidential information of = Starent Networks, Corp. The information transmitted may not be used to = create or change any contractual obligations of Starent Networks, Corp. = Any review, retransmission, dissemination or other use of, or taking of = any action in reliance upon this e-mail and its attachments by persons = or entities other than the intended recipient is prohibited. If you are = not the intended recipient, please notify the sender immediately -- by = replying to this message or by sending an email to = postmaster@starentnetworks.com -- and destroy all copies of this message = and any attachments without reading or disclosing their contents. Thank = you." _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 05 23:21:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKnyR-0004ai-6E; Tue, 05 Sep 2006 23:21:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKnyP-0004aR-Q1 for dime@ietf.org; Tue, 05 Sep 2006 23:21:09 -0400 Received: from ns1.nitro.ca ([216.209.86.226] helo=mailscanner.nitro.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKnyF-0005fM-R6 for dime@ietf.org; Tue, 05 Sep 2006 23:21:09 -0400 Received: from bws14.bridgewatersystems.com (bws14.bridgewatersystems.com [216.113.7.14]) by mailscanner.nitro.ca (8.12.11/8.12.11) with ESMTP id k863K1pu021274 for ; Tue, 5 Sep 2006 23:20:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Date: Tue, 5 Sep 2006 23:21:22 -0400 Message-ID: In-Reply-To: <7CCD07160348804497EF29E9EA5560D78372F8@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Thread-Index: AcbQvh7bPvAj9t8NS7OQLZqLFIeXqwAG0/MQAA7zb8AAEuw2IA== From: "Avi Lior" To: "Chowdhury, Kuntal" , "Gerardo Giaretta" , X-Nitro-MailScanner-Information: Please contact the ISP for more information X-Nitro-MailScanner: Found to be clean X-Nitro-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.599, required 4, autolearn=not spam, BAYES_00 -2.60) X-MailScanner-From: avi@bridgewatersystems.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Kuntal, Neither option 1 or option 2 will work. A new application id just wont scale in the long run. What if another 'capability' were to be added for instance prepaid. Since Diameter messages contain only one Application ID, you would have to create an Application Id that covered both EAP, Prepaid and Mobile IP. And what if a third application were added? The approach is not scalable as the applications are increased -- you would have to cope with all the different permutations of Applications. The same argument goes for ServiceType and PortType and these are actually more problematic. IMO the only thing we can do is to hint at the capability of the NAS. =20 A proper solution should be concieved for this problem. =20 > -----Original Message----- > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20 > Sent: Tuesday, September 05, 2006 2:09 PM > To: Avi Lior; Gerardo Giaretta; Hannes.Tschofenig@gmx.net > Cc: dime@ietf.org > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs.=20 > Service-Type >=20 > All, >=20 > Here is a scenario that may need to be covered. In some=20 > cases, local HA assignment is optimal for transport=20 > efficiency perspective. Diameter > MIP4 application allows this. In such a case the ASP =3D=3D MSP=20 > and the HA is assigned locally (in the visited network).=20 >=20 > To enable this case, in the integrated scenario, the NAS/VAAA=20 > needs to indicate it's capability to assign an HA in the=20 > local network to the HAAA. The HAAA may allow or disallow=20 > this local HA assignment based on policy of the MSA.=20 >=20 > The NAS/VAAA may need to include a hint in the AAA message to=20 > the HAAA at the time of access authentication that it is=20 > capable of providing an HA to the MN. This capability=20 > indication (hint) can be either sent via a new MIP6 specific=20 > AVP or it can be conveyed via an existing AVP (I don't know=20 > if one exists). >=20 > If we decide to include this (local HA assignment), and we=20 > decide to include this mip6 specific hint in the NAS-HAAA=20 > communication, we may have to choose the most appropriate=20 > option (1) vs. (2). >=20 > Comments? >=20 > -Kuntal >=20 >=20 > > -----Original Message----- > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > Sent: Tuesday, September 05, 2006 6:07 AM > > To: Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > Cc: dime@ietf.org > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > Service-Type > >=20 > > I must be missing something. > >=20 > > In the integrated scenario, what would the NAS put in Service-Type? > >=20 > > I think in the integrated scenario neither Port-Type or=20 > Service-Type=20 > > needs to be touched. > >=20 > > As far as I understand the NAS is either executing EAP=20 > Application or=20 > > NAS REQ. It does not know whether the user will result in having=20 > > subsequent Mobile IP service or not. > >=20 > > The only thing the AAA server can do is to send the MIPv6 attributes > as > > optional (M bit off) and hope that if the NAS does not=20 > understand the=20 > > attributes it would have some logic to bootstrap a different way. > >=20 > > We could improve the situration somewhat. We could have the NAS=20 > > indicate that it supports MIPv6 bootstrapping by including hints in > the > > AR (a capability hint). Where the NAS includes HA-IP address AVP > both > > indicating that it can support bootstrapping and if the=20 > HA-IP address > is > > not ALL-ZEROS or ALL ONES it provides a hint that it can support > dynamic > > HA assignement. > >=20 > > Ofcourse we could introduce the concept of capability hints more=20 > > formally in Diameter -- This is missing today. > >=20 > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > > Sent: Tuesday, September 05, 2006 3:35 AM > > > To: Hannes.Tschofenig@gmx.net > > > Cc: dime@ietf.org > > > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > Service-Type > > > > > > Hi Hannes, > > > > > > I agree with Jouni. I prefer (2) for NAS-AAAH and (1) for=20 > AAAH-HA.=20 > > > In my understanding, there are no mandatory AVPs for NAS-AAAH and=20 > > > therefore I don't see a need of a new application; it's just a=20 > > > MIP-specific information that is piggybacked in the=20 > network access=20 > > > authentication procedure. > > > > > > Concerning AAAH-HA, I think it is a much cleaner approach=20 > to define=20 > > > a new application, since it does not anything to do with network=20 > > > authentication. > > > > > > --Gerardo > > > > > > On 9/5/06, jouni.korhonen@teliasonera.com=20 > > > wrote: > > > > Hi HAnnes, > > > > > > > > > -----Original Message----- > > > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > > Sent: 1. syyskuuta 2006 1:07 > > > > > To: dime@ietf.org > > > > > Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > Service-Type > > > > > > > > > > Hi all, > > > > > > > > > > we have had long discussions about the App-ID vs. > > > > > Service-Type usage for > > > > > Diameter MIPv6 Bootstrapping. > > > > > > > > > > It is time to see what the group thinks. Please indicate > > > whether you > > > > > prefer (1) an App-ID or (2) a Service-Type solution for > > > > > > > > > > (a) NAS-to-AAAH communication (as required by the integrated=20 > > > > > scenario; as one part of the solution component) > > > > > > > > I would prefer (2) for now.. or as long as the NAS-2-AAAH main=20 > > > > function is to provide access authentication, where the backend > AAA > > > > may return > > > > MIP6 > > > > bootstrapping info (as an enhancement) based e.g. on the user=20 > > > > subscription profile. If we go for more stuff on=20 > NAS-2-AAAH like=20 > > > > HoA/prefix etc then > > > > (1) > > > > might be better. > > > > > > > > > (b) HA-to-AAAH communication (as used by the split > > > scenario and the > > > > > integrated scenario) > > > > > > > > I would prefer (1) here. The use of EAP for MIP6 bootstrapping=20 > > > > purposes and for 'normal' EAP-based access authentication are=20 > > > > different applications imho. (although in IKEv2 vs 802.1X case > e.g. > > > > NAS-Port-Type could be used to make this distinction.. e.g. > > > how 3GPP > > > > WLAN stuff does it) > > > > > > > > > It might be useful to state a reason for your decision. > > > > > > > > > > Please also indicate whether some aspects are still > > > unclear to you. > > > > > > > > > > Ciao > > > > > Hannes > > > > > > > > Cheers, > > > > Jouni > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > DiME mailing list > > > > > DiME@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime >=20 >=20 > "This email message and any attachments are confidential=20 > information of Starent Networks, Corp. The information=20 > transmitted may not be used to create or change any=20 > contractual obligations of Starent Networks, Corp. Any=20 > review, retransmission, dissemination or other use of, or=20 > taking of any action in reliance upon this e-mail and its=20 > attachments by persons or entities other than the intended=20 > recipient is prohibited. If you are not the intended=20 > recipient, please notify the sender immediately -- by=20 > replying to this message or by sending an email to=20 > postmaster@starentnetworks.com -- and destroy all copies of=20 > this message and any attachments without reading or=20 > disclosing their contents. Thank you." >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 06 10:56:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKypB-0003x0-Ln; Wed, 06 Sep 2006 10:56:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKyp9-0003w3-T6 for dime@ietf.org; Wed, 06 Sep 2006 10:56:19 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKyp6-0000QV-UT for dime@ietf.org; Wed, 06 Sep 2006 10:56:19 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 8830E9004D; Wed, 6 Sep 2006 10:56:11 -0400 (EDT) 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 03498-02; Wed, 6 Sep 2006 10:56:10 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP; Wed, 6 Sep 2006 10:55:01 -0400 (EDT) X-MessageTextProcessor: DisclaimIt (2.70.271) [Starent Networks Corp.] Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Sep 2006 10:55:01 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Date: Wed, 6 Sep 2006 10:55:01 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7837305@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type thread-index: AcbQvh7bPvAj9t8NS7OQLZqLFIeXqwAG0/MQAA7zb8AAEuw2IAAYxaGw From: "Chowdhury, Kuntal" Importance: normal Priority: normal To: "Avi Lior" , "Gerardo Giaretta" , X-OriginalArrivalTime: 06 Sep 2006 14:55:01.0484 (UTC) FILETIME=[6DEF6AC0:01C6D1C4] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Avi, > IMO the only thing we can do is to hint at the capability of the NAS. If we decide to convey NAS capability via an AVP, we may have to make the AVP mandatory, right? If so, can we avoid a new APP-ID? -Kuntal > -----Original Message----- > From: Avi Lior [mailto:avi@bridgewatersystems.com] > Sent: Tuesday, September 05, 2006 10:21 PM > To: Chowdhury, Kuntal; Gerardo Giaretta; Hannes.Tschofenig@gmx.net > Cc: dime@ietf.org > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type >=20 > Hi Kuntal, >=20 > Neither option 1 or option 2 will work. A new application id just wont > scale in the long run. What if another 'capability' were to be added > for instance prepaid. Since Diameter messages contain only one > Application ID, you would have to create an Application Id that covered > both EAP, Prepaid and Mobile IP. And what if a third application were > added? The approach is not scalable as the applications are increased > -- you would have to cope with all the different permutations of > Applications. The same argument goes for ServiceType and PortType and > these are actually more problematic. >=20 > IMO the only thing we can do is to hint at the capability of the NAS. >=20 > A proper solution should be concieved for this problem. >=20 >=20 > > -----Original Message----- > > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > Sent: Tuesday, September 05, 2006 2:09 PM > > To: Avi Lior; Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > Cc: dime@ietf.org > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > Service-Type > > > > All, > > > > Here is a scenario that may need to be covered. In some > > cases, local HA assignment is optimal for transport > > efficiency perspective. Diameter > > MIP4 application allows this. In such a case the ASP =3D=3D MSP > > and the HA is assigned locally (in the visited network). > > > > To enable this case, in the integrated scenario, the NAS/VAAA > > needs to indicate it's capability to assign an HA in the > > local network to the HAAA. The HAAA may allow or disallow > > this local HA assignment based on policy of the MSA. > > > > The NAS/VAAA may need to include a hint in the AAA message to > > the HAAA at the time of access authentication that it is > > capable of providing an HA to the MN. This capability > > indication (hint) can be either sent via a new MIP6 specific > > AVP or it can be conveyed via an existing AVP (I don't know > > if one exists). > > > > If we decide to include this (local HA assignment), and we > > decide to include this mip6 specific hint in the NAS-HAAA > > communication, we may have to choose the most appropriate > > option (1) vs. (2). > > > > Comments? > > > > -Kuntal > > > > > > > -----Original Message----- > > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > Sent: Tuesday, September 05, 2006 6:07 AM > > > To: Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > > Cc: dime@ietf.org > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > Service-Type > > > > > > I must be missing something. > > > > > > In the integrated scenario, what would the NAS put in Service-Type? > > > > > > I think in the integrated scenario neither Port-Type or > > Service-Type > > > needs to be touched. > > > > > > As far as I understand the NAS is either executing EAP > > Application or > > > NAS REQ. It does not know whether the user will result in having > > > subsequent Mobile IP service or not. > > > > > > The only thing the AAA server can do is to send the MIPv6 attributes > > as > > > optional (M bit off) and hope that if the NAS does not > > understand the > > > attributes it would have some logic to bootstrap a different way. > > > > > > We could improve the situration somewhat. We could have the NAS > > > indicate that it supports MIPv6 bootstrapping by including hints in > > the > > > AR (a capability hint). Where the NAS includes HA-IP address AVP > > both > > > indicating that it can support bootstrapping and if the > > HA-IP address > > is > > > not ALL-ZEROS or ALL ONES it provides a hint that it can support > > dynamic > > > HA assignement. > > > > > > Ofcourse we could introduce the concept of capability hints more > > > formally in Diameter -- This is missing today. > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > > > Sent: Tuesday, September 05, 2006 3:35 AM > > > > To: Hannes.Tschofenig@gmx.net > > > > Cc: dime@ietf.org > > > > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > Service-Type > > > > > > > > Hi Hannes, > > > > > > > > I agree with Jouni. I prefer (2) for NAS-AAAH and (1) for > > AAAH-HA. > > > > In my understanding, there are no mandatory AVPs for NAS-AAAH and > > > > therefore I don't see a need of a new application; it's just a > > > > MIP-specific information that is piggybacked in the > > network access > > > > authentication procedure. > > > > > > > > Concerning AAAH-HA, I think it is a much cleaner approach > > to define > > > > a new application, since it does not anything to do with network > > > > authentication. > > > > > > > > --Gerardo > > > > > > > > On 9/5/06, jouni.korhonen@teliasonera.com > > > > wrote: > > > > > Hi HAnnes, > > > > > > > > > > > -----Original Message----- > > > > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > > > Sent: 1. syyskuuta 2006 1:07 > > > > > > To: dime@ietf.org > > > > > > Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > Service-Type > > > > > > > > > > > > Hi all, > > > > > > > > > > > > we have had long discussions about the App-ID vs. > > > > > > Service-Type usage for > > > > > > Diameter MIPv6 Bootstrapping. > > > > > > > > > > > > It is time to see what the group thinks. Please indicate > > > > whether you > > > > > > prefer (1) an App-ID or (2) a Service-Type solution for > > > > > > > > > > > > (a) NAS-to-AAAH communication (as required by the integrated > > > > > > scenario; as one part of the solution component) > > > > > > > > > > I would prefer (2) for now.. or as long as the NAS-2-AAAH main > > > > > function is to provide access authentication, where the backend > > AAA > > > > > may return > > > > > MIP6 > > > > > bootstrapping info (as an enhancement) based e.g. on the user > > > > > subscription profile. If we go for more stuff on > > NAS-2-AAAH like > > > > > HoA/prefix etc then > > > > > (1) > > > > > might be better. > > > > > > > > > > > (b) HA-to-AAAH communication (as used by the split > > > > scenario and the > > > > > > integrated scenario) > > > > > > > > > > I would prefer (1) here. The use of EAP for MIP6 bootstrapping > > > > > purposes and for 'normal' EAP-based access authentication are > > > > > different applications imho. (although in IKEv2 vs 802.1X case > > e.g. > > > > > NAS-Port-Type could be used to make this distinction.. e.g. > > > > how 3GPP > > > > > WLAN stuff does it) > > > > > > > > > > > It might be useful to state a reason for your decision. > > > > > > > > > > > > Please also indicate whether some aspects are still > > > > unclear to you. > > > > > > > > > > > > Ciao > > > > > > Hannes > > > > > > > > > > Cheers, > > > > > Jouni > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > DiME mailing list > > > > > > DiME@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > _______________________________________________ > > > > > DiME mailing list > > > > > DiME@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > "This email message and any attachments are confidential > > information of Starent Networks, Corp. The information > > transmitted may not be used to create or change any > > contractual obligations of Starent Networks, Corp. Any > > review, retransmission, dissemination or other use of, or > > taking of any action in reliance upon this e-mail and its > > attachments by persons or entities other than the intended > > recipient is prohibited. If you are not the intended > > recipient, please notify the sender immediately -- by > > replying to this message or by sending an email to > > postmaster@starentnetworks.com -- and destroy all copies of > > this message and any attachments without reading or > > disclosing their contents. Thank you." > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 06 12:55:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL0ge-0008Bx-2r; Wed, 06 Sep 2006 12:55:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL0gc-0008B1-4V for dime@ietf.org; Wed, 06 Sep 2006 12:55:38 -0400 Received: from ns1.nitro.ca ([216.209.86.226] helo=mailscanner.nitro.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL0gY-00027X-6H for dime@ietf.org; Wed, 06 Sep 2006 12:55:38 -0400 Received: from bws14.bridgewatersystems.com (bws14.bridgewatersystems.com [216.113.7.14]) by mailscanner.nitro.ca (8.12.11/8.12.11) with ESMTP id k86GsWmw000942 for ; Wed, 6 Sep 2006 12:54:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Date: Wed, 6 Sep 2006 12:53:57 -0400 Message-ID: In-Reply-To: <7CCD07160348804497EF29E9EA5560D7837305@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Thread-Index: AcbQvh7bPvAj9t8NS7OQLZqLFIeXqwAG0/MQAA7zb8AAEuw2IAAYxaGwAAHfOvA= From: "Avi Lior" To: "Chowdhury, Kuntal" , "Gerardo Giaretta" , X-Nitro-MailScanner-Information: Please contact the ISP for more information X-Nitro-MailScanner: Found to be clean X-Nitro-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.599, required 4, autolearn=not spam, BAYES_00 -2.60) X-MailScanner-From: avi@bridgewatersystems.com X-Spam-Score: 0.1 (/) X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org We if we use NASPortType we would have to make it mandatory (it is optional to use but must understand) but we will add a new value, then we would need a new Application ID. Same for Service-Type. Only a new NASREQ or EAP AAA server will understand the new value for these attributes. So inorder to make sure you land at the correct server you need an Application ID. So yes we could create a new Application ID. This is not a very good situation. For integrated scenario I think we need to introduce an optional attribute which is both optional to use and optional to understand. Hence we don't need a new Application ID. If a NAS does support bootstrapping for MIPv6 it includes the attribute in AR (NASREQ or EAP). If it lands at a Server that understands this attribute, then it will respond correctly if it wants to bootstrap MIPv6. If it lands at a Server that doesn't understand the attribute then bootstrapping via AAA will not occur. Note that if the NAI routes to a AAA server in the home network that doesn't recognize the hint then most likely the operator doesn't want to use bootstrapping or the integrated scenario. > -----Original Message----- > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20 > Sent: Wednesday, September 06, 2006 10:55 AM > To: Avi Lior; Gerardo Giaretta; Hannes.Tschofenig@gmx.net > Cc: dime@ietf.org > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs.=20 > Service-Type >=20 > Avi, >=20 > > IMO the only thing we can do is to hint at the capability=20 > of the NAS. >=20 > If we decide to convey NAS capability via an AVP, we may have=20 > to make the AVP mandatory, right? If so, can we avoid a new APP-ID? >=20 > -Kuntal >=20 >=20 > > -----Original Message----- > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > Sent: Tuesday, September 05, 2006 10:21 PM > > To: Chowdhury, Kuntal; Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > Cc: dime@ietf.org > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > Service-Type > >=20 > > Hi Kuntal, > >=20 > > Neither option 1 or option 2 will work. A new application id just > wont > > scale in the long run. What if another 'capability' were=20 > to be added=20 > > for instance prepaid. Since Diameter messages contain only one=20 > > Application ID, you would have to create an Application Id that > covered > > both EAP, Prepaid and Mobile IP. And what if a third=20 > application were=20 > > added? The approach is not scalable as the applications=20 > are increased > > -- you would have to cope with all the different permutations of=20 > > Applications. The same argument goes for ServiceType and=20 > PortType and=20 > > these are actually more problematic. > >=20 > > IMO the only thing we can do is to hint at the capability=20 > of the NAS. > >=20 > > A proper solution should be concieved for this problem. > >=20 > >=20 > > > -----Original Message----- > > > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > > Sent: Tuesday, September 05, 2006 2:09 PM > > > To: Avi Lior; Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > > Cc: dime@ietf.org > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > Service-Type > > > > > > All, > > > > > > Here is a scenario that may need to be covered. In some=20 > cases, local=20 > > > HA assignment is optimal for transport efficiency perspective.=20 > > > Diameter > > > MIP4 application allows this. In such a case the ASP =3D=3D=20 > MSP and the=20 > > > HA is assigned locally (in the visited network). > > > > > > To enable this case, in the integrated scenario, the=20 > NAS/VAAA needs=20 > > > to indicate it's capability to assign an HA in the local=20 > network to=20 > > > the HAAA. The HAAA may allow or disallow this local HA assignment=20 > > > based on policy of the MSA. > > > > > > The NAS/VAAA may need to include a hint in the AAA message to the=20 > > > HAAA at the time of access authentication that it is capable of=20 > > > providing an HA to the MN. This capability indication=20 > (hint) can be=20 > > > either sent via a new MIP6 specific AVP or it can be=20 > conveyed via an=20 > > > existing AVP (I don't know if one exists). > > > > > > If we decide to include this (local HA assignment), and=20 > we decide to=20 > > > include this mip6 specific hint in the NAS-HAAA communication, we=20 > > > may have to choose the most appropriate option (1) vs. (2). > > > > > > Comments? > > > > > > -Kuntal > > > > > > > > > > -----Original Message----- > > > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > > Sent: Tuesday, September 05, 2006 6:07 AM > > > > To: Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > > > Cc: dime@ietf.org > > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > Service-Type > > > > > > > > I must be missing something. > > > > > > > > In the integrated scenario, what would the NAS put in > Service-Type? > > > > > > > > I think in the integrated scenario neither Port-Type or > > > Service-Type > > > > needs to be touched. > > > > > > > > As far as I understand the NAS is either executing EAP > > > Application or > > > > NAS REQ. It does not know whether the user will result=20 > in having=20 > > > > subsequent Mobile IP service or not. > > > > > > > > The only thing the AAA server can do is to send the MIPv6 > attributes > > > as > > > > optional (M bit off) and hope that if the NAS does not > > > understand the > > > > attributes it would have some logic to bootstrap a=20 > different way. > > > > > > > > We could improve the situration somewhat. We could=20 > have the NAS=20 > > > > indicate that it supports MIPv6 bootstrapping by including hints > in > > > the > > > > AR (a capability hint). Where the NAS includes HA-IP=20 > address AVP > > > both > > > > indicating that it can support bootstrapping and if the > > > HA-IP address > > > is > > > > not ALL-ZEROS or ALL ONES it provides a hint that it can support > > > dynamic > > > > HA assignement. > > > > > > > > Ofcourse we could introduce the concept of capability=20 > hints more=20 > > > > formally in Diameter -- This is missing today. > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > > > > Sent: Tuesday, September 05, 2006 3:35 AM > > > > > To: Hannes.Tschofenig@gmx.net > > > > > Cc: dime@ietf.org > > > > > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > Service-Type > > > > > > > > > > Hi Hannes, > > > > > > > > > > I agree with Jouni. I prefer (2) for NAS-AAAH and (1) for > > > AAAH-HA. > > > > > In my understanding, there are no mandatory AVPs for NAS-AAAH > and > > > > > therefore I don't see a need of a new application;=20 > it's just a=20 > > > > > MIP-specific information that is piggybacked in the > > > network access > > > > > authentication procedure. > > > > > > > > > > Concerning AAAH-HA, I think it is a much cleaner approach > > > to define > > > > > a new application, since it does not anything to do=20 > with network=20 > > > > > authentication. > > > > > > > > > > --Gerardo > > > > > > > > > > On 9/5/06, jouni.korhonen@teliasonera.com=20 > > > > > wrote: > > > > > > Hi HAnnes, > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > > > > Sent: 1. syyskuuta 2006 1:07 > > > > > > > To: dime@ietf.org > > > > > > > Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > Service-Type > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > we have had long discussions about the App-ID vs. > > > > > > > Service-Type usage for > > > > > > > Diameter MIPv6 Bootstrapping. > > > > > > > > > > > > > > It is time to see what the group thinks. Please indicate > > > > > whether you > > > > > > > prefer (1) an App-ID or (2) a Service-Type solution for > > > > > > > > > > > > > > (a) NAS-to-AAAH communication (as required by the=20 > integrated=20 > > > > > > > scenario; as one part of the solution component) > > > > > > > > > > > > I would prefer (2) for now.. or as long as the=20 > NAS-2-AAAH main=20 > > > > > > function is to provide access authentication, where the > backend > > > AAA > > > > > > may return > > > > > > MIP6 > > > > > > bootstrapping info (as an enhancement) based e.g.=20 > on the user=20 > > > > > > subscription profile. If we go for more stuff on > > > NAS-2-AAAH like > > > > > > HoA/prefix etc then > > > > > > (1) > > > > > > might be better. > > > > > > > > > > > > > (b) HA-to-AAAH communication (as used by the split > > > > > scenario and the > > > > > > > integrated scenario) > > > > > > > > > > > > I would prefer (1) here. The use of EAP for MIP6=20 > bootstrapping=20 > > > > > > purposes and for 'normal' EAP-based access=20 > authentication are=20 > > > > > > different applications imho. (although in IKEv2 vs=20 > 802.1X case > > > e.g. > > > > > > NAS-Port-Type could be used to make this distinction.. e.g. > > > > > how 3GPP > > > > > > WLAN stuff does it) > > > > > > > > > > > > > It might be useful to state a reason for your decision. > > > > > > > > > > > > > > Please also indicate whether some aspects are still > > > > > unclear to you. > > > > > > > > > > > > > > Ciao > > > > > > > Hannes > > > > > > > > > > > > Cheers, > > > > > > Jouni > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > DiME mailing list > > > > > > > DiME@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > DiME mailing list > > > > > > DiME@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > _______________________________________________ > > > > > DiME mailing list > > > > > DiME@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > "This email message and any attachments are confidential=20 > information=20 > > > of Starent Networks, Corp. The information transmitted may not be=20 > > > used to create or change any contractual obligations of Starent=20 > > > Networks, Corp. Any review, retransmission,=20 > dissemination or other=20 > > > use of, or taking of any action in reliance upon this=20 > e-mail and its=20 > > > attachments by persons or entities other than the=20 > intended recipient=20 > > > is prohibited. If you are not the intended recipient,=20 > please notify=20 > > > the sender immediately -- by replying to this message or=20 > by sending=20 > > > an email to postmaster@starentnetworks.com -- and destroy=20 > all copies=20 > > > of this message and any attachments without reading or disclosing=20 > > > their contents. Thank you." > > > >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 06 14:17:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL1xX-0004n0-S1; Wed, 06 Sep 2006 14:17:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL1xW-0004mk-9e for dime@ietf.org; Wed, 06 Sep 2006 14:17:10 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL1xT-0003t8-E9 for dime@ietf.org; Wed, 06 Sep 2006 14:17:10 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id k86IGtvE012005; Thu, 7 Sep 2006 03:16:55 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id k86IGtpd024997; Thu, 7 Sep 2006 03:16:55 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with ESMTP id DAA24995; Thu, 7 Sep 2006 03:16:55 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id k86IGsQq002987; Thu, 7 Sep 2006 03:16:54 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k86IGr7h009760; Thu, 7 Sep 2006 03:16:54 +0900 (JST) Received: from steelhead ([172.30.24.105]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J5600IOWO3Z3V30@mail.po.toshiba.co.jp>; Thu, 07 Sep 2006 03:16:53 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.63) (envelope-from ) id 1GL1x5-0002XH-TY; Wed, 06 Sep 2006 11:16:43 -0700 Date: Wed, 06 Sep 2006 14:16:43 -0400 From: Yoshihiro Ohba Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type In-reply-to: To: Avi Lior Message-id: <20060906181643.GE5241@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <7CCD07160348804497EF29E9EA5560D78372F8@exchtewks2.starentnetworks.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I agree with Avi that defining a new application for MIP6 bootstrapping by assigning a new application identifier but borrowing and modifying ABNF of existing applications (i.e., Diameter EAP and NASREQ) will end up with "a lot of permutations in Diameter specifications" problem in a future when other applications need to be developed that use EAP for authentication purpose and requires new mandatory AVPs for authorization purpose. I don't agree with this option. I also agree with Avi that defining a new application for MIP6 bootstrapping on top of existing applications (Diameter EAP) without defining a new application id but with defining new values for existing AVPs or new optional AVPs has some issue, but this option might not be as bad as the first option since backward compatibility can be easily maintained unlike the first option. However, there is a forward compatibility problem (i.e., a Diameter message may be forwarded to a AAA server that does not support the new application). Besides this problem, it might be worth pursuing this option because it works in an optimized way (i.e., bootstrapping AVPs are piggybacked in Diameter EAP or NASREQ message) as long as both NAS and AAA server support the AVPs. In order to deal with the forward compatibility problem of the second option, a third option is to define a new application for MIP6 bootstrapping as a totally new authorization application that carries new mandatory AVPs specific to that application. This option can be run when execution of the second option succeeds in authentication but fails in carrying bootstrapping AVPs. Regards, Yoshihiro Ohba On Tue, Sep 05, 2006 at 11:21:22PM -0400, Avi Lior wrote: > Hi Kuntal, > > Neither option 1 or option 2 will work. A new application id just wont > scale in the long run. What if another 'capability' were to be added > for instance prepaid. Since Diameter messages contain only one > Application ID, you would have to create an Application Id that covered > both EAP, Prepaid and Mobile IP. And what if a third application were > added? The approach is not scalable as the applications are increased > -- you would have to cope with all the different permutations of > Applications. The same argument goes for ServiceType and PortType and > these are actually more problematic. > > IMO the only thing we can do is to hint at the capability of the NAS. > > A proper solution should be concieved for this problem. > > > > -----Original Message----- > > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > Sent: Tuesday, September 05, 2006 2:09 PM > > To: Avi Lior; Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > Cc: dime@ietf.org > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > Service-Type > > > > All, > > > > Here is a scenario that may need to be covered. In some > > cases, local HA assignment is optimal for transport > > efficiency perspective. Diameter > > MIP4 application allows this. In such a case the ASP == MSP > > and the HA is assigned locally (in the visited network). > > > > To enable this case, in the integrated scenario, the NAS/VAAA > > needs to indicate it's capability to assign an HA in the > > local network to the HAAA. The HAAA may allow or disallow > > this local HA assignment based on policy of the MSA. > > > > The NAS/VAAA may need to include a hint in the AAA message to > > the HAAA at the time of access authentication that it is > > capable of providing an HA to the MN. This capability > > indication (hint) can be either sent via a new MIP6 specific > > AVP or it can be conveyed via an existing AVP (I don't know > > if one exists). > > > > If we decide to include this (local HA assignment), and we > > decide to include this mip6 specific hint in the NAS-HAAA > > communication, we may have to choose the most appropriate > > option (1) vs. (2). > > > > Comments? > > > > -Kuntal > > > > > > > -----Original Message----- > > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > Sent: Tuesday, September 05, 2006 6:07 AM > > > To: Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > > Cc: dime@ietf.org > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > Service-Type > > > > > > I must be missing something. > > > > > > In the integrated scenario, what would the NAS put in Service-Type? > > > > > > I think in the integrated scenario neither Port-Type or > > Service-Type > > > needs to be touched. > > > > > > As far as I understand the NAS is either executing EAP > > Application or > > > NAS REQ. It does not know whether the user will result in having > > > subsequent Mobile IP service or not. > > > > > > The only thing the AAA server can do is to send the MIPv6 attributes > > as > > > optional (M bit off) and hope that if the NAS does not > > understand the > > > attributes it would have some logic to bootstrap a different way. > > > > > > We could improve the situration somewhat. We could have the NAS > > > indicate that it supports MIPv6 bootstrapping by including hints in > > the > > > AR (a capability hint). Where the NAS includes HA-IP address AVP > > both > > > indicating that it can support bootstrapping and if the > > HA-IP address > > is > > > not ALL-ZEROS or ALL ONES it provides a hint that it can support > > dynamic > > > HA assignement. > > > > > > Ofcourse we could introduce the concept of capability hints more > > > formally in Diameter -- This is missing today. > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > > > Sent: Tuesday, September 05, 2006 3:35 AM > > > > To: Hannes.Tschofenig@gmx.net > > > > Cc: dime@ietf.org > > > > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > Service-Type > > > > > > > > Hi Hannes, > > > > > > > > I agree with Jouni. I prefer (2) for NAS-AAAH and (1) for > > AAAH-HA. > > > > In my understanding, there are no mandatory AVPs for NAS-AAAH and > > > > therefore I don't see a need of a new application; it's just a > > > > MIP-specific information that is piggybacked in the > > network access > > > > authentication procedure. > > > > > > > > Concerning AAAH-HA, I think it is a much cleaner approach > > to define > > > > a new application, since it does not anything to do with network > > > > authentication. > > > > > > > > --Gerardo > > > > > > > > On 9/5/06, jouni.korhonen@teliasonera.com > > > > wrote: > > > > > Hi HAnnes, > > > > > > > > > > > -----Original Message----- > > > > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > > > Sent: 1. syyskuuta 2006 1:07 > > > > > > To: dime@ietf.org > > > > > > Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > Service-Type > > > > > > > > > > > > Hi all, > > > > > > > > > > > > we have had long discussions about the App-ID vs. > > > > > > Service-Type usage for > > > > > > Diameter MIPv6 Bootstrapping. > > > > > > > > > > > > It is time to see what the group thinks. Please indicate > > > > whether you > > > > > > prefer (1) an App-ID or (2) a Service-Type solution for > > > > > > > > > > > > (a) NAS-to-AAAH communication (as required by the integrated > > > > > > scenario; as one part of the solution component) > > > > > > > > > > I would prefer (2) for now.. or as long as the NAS-2-AAAH main > > > > > function is to provide access authentication, where the backend > > AAA > > > > > may return > > > > > MIP6 > > > > > bootstrapping info (as an enhancement) based e.g. on the user > > > > > subscription profile. If we go for more stuff on > > NAS-2-AAAH like > > > > > HoA/prefix etc then > > > > > (1) > > > > > might be better. > > > > > > > > > > > (b) HA-to-AAAH communication (as used by the split > > > > scenario and the > > > > > > integrated scenario) > > > > > > > > > > I would prefer (1) here. The use of EAP for MIP6 bootstrapping > > > > > purposes and for 'normal' EAP-based access authentication are > > > > > different applications imho. (although in IKEv2 vs 802.1X case > > e.g. > > > > > NAS-Port-Type could be used to make this distinction.. e.g. > > > > how 3GPP > > > > > WLAN stuff does it) > > > > > > > > > > > It might be useful to state a reason for your decision. > > > > > > > > > > > > Please also indicate whether some aspects are still > > > > unclear to you. > > > > > > > > > > > > Ciao > > > > > > Hannes > > > > > > > > > > Cheers, > > > > > Jouni > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > DiME mailing list > > > > > > DiME@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > _______________________________________________ > > > > > DiME mailing list > > > > > DiME@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > "This email message and any attachments are confidential > > information of Starent Networks, Corp. The information > > transmitted may not be used to create or change any > > contractual obligations of Starent Networks, Corp. Any > > review, retransmission, dissemination or other use of, or > > taking of any action in reliance upon this e-mail and its > > attachments by persons or entities other than the intended > > recipient is prohibited. If you are not the intended > > recipient, please notify the sender immediately -- by > > replying to this message or by sending an email to > > postmaster@starentnetworks.com -- and destroy all copies of > > this message and any attachments without reading or > > disclosing their contents. Thank you." > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 07 00:52:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLBsP-0008VY-8u; Thu, 07 Sep 2006 00:52:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLBsN-0008UI-JG for dime@ietf.org; Thu, 07 Sep 2006 00:52:31 -0400 Received: from ns1.nitro.ca ([216.209.86.226] helo=mailscanner.nitro.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLBox-0002D0-PP for dime@ietf.org; Thu, 07 Sep 2006 00:49:00 -0400 Received: from bws14.bridgewatersystems.com (bws14.bridgewatersystems.com [216.113.7.14]) by mailscanner.nitro.ca (8.12.11/8.12.11) with ESMTP id k874mA5S011858 for ; Thu, 7 Sep 2006 00:48:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Date: Thu, 7 Sep 2006 00:48:22 -0400 Message-ID: In-Reply-To: <20060906181643.GE5241@steelhead> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Thread-Index: AcbR4NqOpbrwqAcfTRac48n6IPA68QAVydrg From: "Avi Lior" To: "Yoshihiro Ohba" X-Nitro-MailScanner-Information: Please contact the ISP for more information X-Nitro-MailScanner: Found to be clean X-Nitro-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.599, required 4, autolearn=not spam, BAYES_00 -2.60) X-MailScanner-From: avi@bridgewatersystems.com X-Spam-Score: 0.1 (/) X-Scan-Signature: fac892abe0c719c7bb99f6e7c710cdae Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Yoshi=20 See inline.... > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]=20 > Sent: Wednesday, September 06, 2006 2:17 PM > To: Avi Lior > Cc: Chowdhury, Kuntal; Gerardo Giaretta;=20 > Hannes.Tschofenig@gmx.net; dime@ietf.org > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs.=20 > Service-Type >=20 > I agree with Avi that defining a new application for MIP6=20 > bootstrapping by assigning a new application identifier but=20 > borrowing and modifying ABNF of existing applications (i.e.,=20 > Diameter EAP and > NASREQ) will end up with "a lot of permutations in Diameter=20 > specifications" problem in a future when other applications=20 > need to be developed that use EAP for authentication purpose=20 > and requires new mandatory AVPs for authorization purpose. I=20 > don't agree with this option. >=20 > I also agree with Avi that defining a new application for=20 > MIP6 bootstrapping on top of existing applications (Diameter=20 > EAP) without defining a new application id but with defining=20 > new values for existing AVPs or new optional AVPs has some=20 > issue, but this option might not be as bad as the first=20 > option since backward compatibility can be easily maintained=20 > unlike the first option. However, there is a forward=20 > compatibility problem (i.e., a Diameter message may be=20 > forwarded to a AAA server that does not support the new=20 > application). Besides this problem, it might be worth=20 > pursuing this option because it works in an optimized way=20 > (i.e., bootstrapping AVPs are piggybacked in Diameter EAP or=20 > NASREQ message) as long as both NAS and AAA server support the AVPs. >=20 > In order to deal with the forward compatibility problem of=20 > the second option, a third option is to define a new=20 > application for MIP6 bootstrapping as a totally new=20 > authorization application that carries new mandatory AVPs=20 > specific to that application. This option can be run when=20 > execution of the second option succeeds in authentication but=20 > fails in carrying bootstrapping AVPs. Unless I am missing something I think your forward compatibility problem has issues with it. How would the NAS know to use the MobileIPv6 application id? It doesn't have any knowledge that MobileIPv6 bootstrapping is required? If it selects that Application and the home network doesn't support MobileIPv6 bootstrapping then the user will not get service. And going on in the future when there are other Applications which will the NAS select?=20 =20 > Regards, > Yoshihiro Ohba >=20 >=20 >=20 >=20 >=20 > On Tue, Sep 05, 2006 at 11:21:22PM -0400, Avi Lior wrote: > > Hi Kuntal, > >=20 > > Neither option 1 or option 2 will work. A new application id just=20 > > wont scale in the long run. What if another 'capability'=20 > were to be=20 > > added for instance prepaid. Since Diameter messages=20 > contain only one=20 > > Application ID, you would have to create an Application Id that=20 > > covered both EAP, Prepaid and Mobile IP. And what if a third=20 > > application were added? The approach is not scalable as the=20 > > applications are increased > > -- you would have to cope with all the different permutations of=20 > > Applications. The same argument goes for ServiceType and=20 > PortType and=20 > > these are actually more problematic. > >=20 > > IMO the only thing we can do is to hint at the capability=20 > of the NAS. =20 > >=20 > > A proper solution should be concieved for this problem. > > =20 > >=20 > > > -----Original Message----- > > > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > > Sent: Tuesday, September 05, 2006 2:09 PM > > > To: Avi Lior; Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > > Cc: dime@ietf.org > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs.=20 > > > Service-Type > > >=20 > > > All, > > >=20 > > > Here is a scenario that may need to be covered. In some=20 > cases, local=20 > > > HA assignment is optimal for transport efficiency perspective.=20 > > > Diameter > > > MIP4 application allows this. In such a case the ASP =3D=3D=20 > MSP and the=20 > > > HA is assigned locally (in the visited network). > > >=20 > > > To enable this case, in the integrated scenario, the=20 > NAS/VAAA needs=20 > > > to indicate it's capability to assign an HA in the local=20 > network to=20 > > > the HAAA. The HAAA may allow or disallow this local HA assignment=20 > > > based on policy of the MSA. > > >=20 > > > The NAS/VAAA may need to include a hint in the AAA message to the=20 > > > HAAA at the time of access authentication that it is capable of=20 > > > providing an HA to the MN. This capability indication=20 > (hint) can be=20 > > > either sent via a new MIP6 specific AVP or it can be=20 > conveyed via an=20 > > > existing AVP (I don't know if one exists). > > >=20 > > > If we decide to include this (local HA assignment), and=20 > we decide to=20 > > > include this mip6 specific hint in the NAS-HAAA communication, we=20 > > > may have to choose the most appropriate option (1) vs. (2). > > >=20 > > > Comments? > > >=20 > > > -Kuntal > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > > Sent: Tuesday, September 05, 2006 6:07 AM > > > > To: Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > > > Cc: dime@ietf.org > > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > Service-Type > > > >=20 > > > > I must be missing something. > > > >=20 > > > > In the integrated scenario, what would the NAS put in=20 > Service-Type? > > > >=20 > > > > I think in the integrated scenario neither Port-Type or > > > Service-Type > > > > needs to be touched. > > > >=20 > > > > As far as I understand the NAS is either executing EAP > > > Application or > > > > NAS REQ. It does not know whether the user will result=20 > in having=20 > > > > subsequent Mobile IP service or not. > > > >=20 > > > > The only thing the AAA server can do is to send the MIPv6=20 > > > > attributes > > > as > > > > optional (M bit off) and hope that if the NAS does not > > > understand the > > > > attributes it would have some logic to bootstrap a=20 > different way. > > > >=20 > > > > We could improve the situration somewhat. We could=20 > have the NAS=20 > > > > indicate that it supports MIPv6 bootstrapping by=20 > including hints=20 > > > > in > > > the > > > > AR (a capability hint). Where the NAS includes HA-IP=20 > address AVP > > > both > > > > indicating that it can support bootstrapping and if the > > > HA-IP address > > > is > > > > not ALL-ZEROS or ALL ONES it provides a hint that it can support > > > dynamic > > > > HA assignement. > > > >=20 > > > > Ofcourse we could introduce the concept of capability=20 > hints more=20 > > > > formally in Diameter -- This is missing today. > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > > > > Sent: Tuesday, September 05, 2006 3:35 AM > > > > > To: Hannes.Tschofenig@gmx.net > > > > > Cc: dime@ietf.org > > > > > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > Service-Type > > > > > > > > > > Hi Hannes, > > > > > > > > > > I agree with Jouni. I prefer (2) for NAS-AAAH and (1) for > > > AAAH-HA.=20 > > > > > In my understanding, there are no mandatory AVPs for NAS-AAAH=20 > > > > > and therefore I don't see a need of a new=20 > application; it's just=20 > > > > > a MIP-specific information that is piggybacked in the > > > network access > > > > > authentication procedure. > > > > > > > > > > Concerning AAAH-HA, I think it is a much cleaner approach > > > to define > > > > > a new application, since it does not anything to do=20 > with network=20 > > > > > authentication. > > > > > > > > > > --Gerardo > > > > > > > > > > On 9/5/06, jouni.korhonen@teliasonera.com=20 > > > > > wrote: > > > > > > Hi HAnnes, > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > > > > Sent: 1. syyskuuta 2006 1:07 > > > > > > > To: dime@ietf.org > > > > > > > Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > Service-Type > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > we have had long discussions about the App-ID vs. > > > > > > > Service-Type usage for > > > > > > > Diameter MIPv6 Bootstrapping. > > > > > > > > > > > > > > It is time to see what the group thinks. Please indicate > > > > > whether you > > > > > > > prefer (1) an App-ID or (2) a Service-Type solution for > > > > > > > > > > > > > > (a) NAS-to-AAAH communication (as required by the=20 > integrated=20 > > > > > > > scenario; as one part of the solution component) > > > > > > > > > > > > I would prefer (2) for now.. or as long as the=20 > NAS-2-AAAH main=20 > > > > > > function is to provide access authentication, where the=20 > > > > > > backend > > > AAA > > > > > > may return > > > > > > MIP6 > > > > > > bootstrapping info (as an enhancement) based e.g.=20 > on the user=20 > > > > > > subscription profile. If we go for more stuff on > > > NAS-2-AAAH like > > > > > > HoA/prefix etc then > > > > > > (1) > > > > > > might be better. > > > > > > > > > > > > > (b) HA-to-AAAH communication (as used by the split > > > > > scenario and the > > > > > > > integrated scenario) > > > > > > > > > > > > I would prefer (1) here. The use of EAP for MIP6=20 > bootstrapping=20 > > > > > > purposes and for 'normal' EAP-based access=20 > authentication are=20 > > > > > > different applications imho. (although in IKEv2 vs=20 > 802.1X case > > > e.g. > > > > > > NAS-Port-Type could be used to make this distinction.. e.g. > > > > > how 3GPP > > > > > > WLAN stuff does it) > > > > > > > > > > > > > It might be useful to state a reason for your decision. > > > > > > > > > > > > > > Please also indicate whether some aspects are still > > > > > unclear to you. > > > > > > > > > > > > > > Ciao > > > > > > > Hannes > > > > > > > > > > > > Cheers, > > > > > > Jouni > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > DiME mailing list > > > > > > > DiME@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > DiME mailing list > > > > > > DiME@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > _______________________________________________ > > > > > DiME mailing list > > > > > DiME@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > >=20 > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > >=20 > > >=20 > > > "This email message and any attachments are confidential=20 > information=20 > > > of Starent Networks, Corp. The information transmitted may not be=20 > > > used to create or change any contractual obligations of Starent=20 > > > Networks, Corp. Any review, retransmission,=20 > dissemination or other=20 > > > use of, or taking of any action in reliance upon this=20 > e-mail and its=20 > > > attachments by persons or entities other than the=20 > intended recipient=20 > > > is prohibited. If you are not the intended recipient,=20 > please notify=20 > > > the sender immediately -- by replying to this message or=20 > by sending=20 > > > an email to postmaster@starentnetworks.com -- and destroy=20 > all copies=20 > > > of this message and any attachments without reading or disclosing=20 > > > their contents. Thank you." > > >=20 > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > >=20 > >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 07 05:07:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLFr4-0006FS-Df; Thu, 07 Sep 2006 05:07:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLFr3-0006FL-9P for dime@ietf.org; Thu, 07 Sep 2006 05:07:25 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLFr1-0008Pb-OC for dime@ietf.org; Thu, 07 Sep 2006 05:07:25 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 47A3B2FD67; Thu, 7 Sep 2006 11:07:17 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1GLFta-0006qH-9D; Thu, 07 Sep 2006 11:10:02 +0200 Date: Thu, 7 Sep 2006 11:10:02 +0200 From: Julien Bournelle To: jouni.korhonen@teliasonera.com Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Message-ID: <20060907091002.GA26293@ipv6-3.int-evry.fr> References: <5D25AEFB114D034FBDC8B156FCA78E0301359AF4@SEHAN021MB.tcad.telia.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5D25AEFB114D034FBDC8B156FCA78E0301359AF4@SEHAN021MB.tcad.telia.se> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, On Tue, Sep 05, 2006 at 01:38:45PM +0200, jouni.korhonen@teliasonera.com wrote: > Something MIP6 indicating that is not defined yet. > > > I think in the integrated scenario neither Port-Type or Service-Type > > needs to be touched. > > > > As far as I understand the NAS is either executing EAP Application or > > NAS REQ. It does not know whether the user will result in having > > subsequent Mobile IP service or not. > > Yes. But there was this discussion/idea earlier that it could be > benefical > from the AAA server point of view to have a hint whether the NAS > supports intergrated scenario at all. > > > The only thing the AAA server can do is to send the MIPv6 > > attributes as > > optional (M bit off) and hope that if the NAS does not understand the > > attributes it would have some logic to bootstrap a different way. > > > > We could improve the situration somewhat. We could have the NAS > > indicate that it supports MIPv6 bootstrapping by including > > hints in the > > AR (a capability hint). Where the NAS includes HA-IP > > address AVP both > > And why can't the Service-Type or NAS-Port-type serve as a hint? e.g. > NAS-Port-Type has been used in some architectures to distinguish > between .1X or IKEv2 originating EAP requests. I'm thinking that the NAS will certainly add a NAS-Port-Type even if it supports mip6 integrated case. So this would mean that it will add 2 NAS-Port-Type ? > > Well.. we could also put a bunch of AVPs to the access requests > that would serve as a capability hint. yes. I tend to think that a sort of capability AVP here is interesting and may solve what we want. Julien > > > indicating that it can support bootstrapping and if the HA-IP > > address is > > not ALL-ZEROS or ALL ONES it provides a hint that it can > > support dynamic > > HA assignement. > > > > Ofcourse we could introduce the concept of capability hints more > > formally in Diameter -- This is missing today. > > Cheers, > Jouni > > > > > > > > > > > > > > -----Original Message----- > > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > > Sent: Tuesday, September 05, 2006 3:35 AM > > > To: Hannes.Tschofenig@gmx.net > > > Cc: dime@ietf.org > > > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > Service-Type > > > > > > Hi Hannes, > > > > > > I agree with Jouni. I prefer (2) for NAS-AAAH and (1) for > > > AAAH-HA. In my understanding, there are no mandatory AVPs for > > > NAS-AAAH and therefore I don't see a need of a new > > > application; it's just a MIP-specific information that is > > > piggybacked in the network access authentication procedure. > > > > > > Concerning AAAH-HA, I think it is a much cleaner approach to > > > define a new application, since it does not anything to do > > > with network authentication. > > > > > > --Gerardo > > > > > > On 9/5/06, jouni.korhonen@teliasonera.com > > > wrote: > > > > Hi HAnnes, > > > > > > > > > -----Original Message----- > > > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > > Sent: 1. syyskuuta 2006 1:07 > > > > > To: dime@ietf.org > > > > > Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > Service-Type > > > > > > > > > > Hi all, > > > > > > > > > > we have had long discussions about the App-ID vs. > > > > > Service-Type usage for > > > > > Diameter MIPv6 Bootstrapping. > > > > > > > > > > It is time to see what the group thinks. Please indicate > > > whether you > > > > > prefer (1) an App-ID or (2) a Service-Type solution for > > > > > > > > > > (a) NAS-to-AAAH communication (as required by the integrated > > > > > scenario; as one part of the solution component) > > > > > > > > I would prefer (2) for now.. or as long as the NAS-2-AAAH main > > > > function is to provide access authentication, where the > > backend AAA > > > > may return > > > > MIP6 > > > > bootstrapping info (as an enhancement) based e.g. on the user > > > > subscription profile. If we go for more stuff on NAS-2-AAAH like > > > > HoA/prefix etc then > > > > (1) > > > > might be better. > > > > > > > > > (b) HA-to-AAAH communication (as used by the split > > > scenario and the > > > > > integrated scenario) > > > > > > > > I would prefer (1) here. The use of EAP for MIP6 bootstrapping > > > > purposes and for 'normal' EAP-based access authentication are > > > > different applications imho. (although in IKEv2 vs 802.1X > > case e.g. > > > > NAS-Port-Type could be used to make this distinction.. e.g. > > > how 3GPP > > > > WLAN stuff does it) > > > > > > > > > It might be useful to state a reason for your decision. > > > > > > > > > > Please also indicate whether some aspects are still > > > unclear to you. > > > > > > > > > > Ciao > > > > > Hannes > > > > > > > > Cheers, > > > > Jouni > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > DiME mailing list > > > > > DiME@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime -- julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 07 05:12:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLFw1-0006wS-EO; Thu, 07 Sep 2006 05:12:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLFw0-0006wN-MT for dime@ietf.org; Thu, 07 Sep 2006 05:12:32 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLFvz-0001XV-Sv for dime@ietf.org; Thu, 07 Sep 2006 05:12:32 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 7A96F2FF40; Thu, 7 Sep 2006 11:12:28 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1GLFyb-0006qQ-GL; Thu, 07 Sep 2006 11:15:13 +0200 Date: Thu, 7 Sep 2006 11:15:13 +0200 From: Julien Bournelle To: Avi Lior Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Message-ID: <20060907091513.GB26293@ipv6-3.int-evry.fr> References: <7CCD07160348804497EF29E9EA5560D7837305@exchtewks2.starentnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: fac892abe0c719c7bb99f6e7c710cdae Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org On Wed, Sep 06, 2006 at 12:53:57PM -0400, Avi Lior wrote: > We if we use NASPortType we would have to make it mandatory (it is > optional to use but must understand) but we will add a new value, then > we would need a new Application ID. Same for Service-Type. Only a new > NASREQ or EAP AAA server will understand the new value for these > attributes. So inorder to make sure you land at the correct server you > need an Application ID. > > So yes we could create a new Application ID. > > This is not a very good situation. > > For integrated scenario I think we need to introduce an optional > attribute which is both optional to use and optional to understand. > Hence we don't need a new Application ID. > > If a NAS does support bootstrapping for MIPv6 it includes the attribute > in AR (NASREQ or EAP). > > If it lands at a Server that understands this attribute, then it will > respond correctly if it wants to bootstrap MIPv6. If it lands at a > Server that doesn't understand the attribute then bootstrapping via AAA > will not occur. Note that if the NAI routes to a AAA server in the home > network that doesn't recognize the hint then most likely the operator > doesn't want to use bootstrapping or the integrated scenario. I agree with this approach for the "NAS-AAAH" part of the mip6 bootstrapping. Julien > > > > > > > -----Original Message----- > > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > Sent: Wednesday, September 06, 2006 10:55 AM > > To: Avi Lior; Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > Cc: dime@ietf.org > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > Service-Type > > > > Avi, > > > > > IMO the only thing we can do is to hint at the capability > > of the NAS. > > > > If we decide to convey NAS capability via an AVP, we may have > > to make the AVP mandatory, right? If so, can we avoid a new APP-ID? > > > > -Kuntal > > > > > > > -----Original Message----- > > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > Sent: Tuesday, September 05, 2006 10:21 PM > > > To: Chowdhury, Kuntal; Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > > Cc: dime@ietf.org > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > Service-Type > > > > > > Hi Kuntal, > > > > > > Neither option 1 or option 2 will work. A new application id just > > wont > > > scale in the long run. What if another 'capability' were > > to be added > > > for instance prepaid. Since Diameter messages contain only one > > > Application ID, you would have to create an Application Id that > > covered > > > both EAP, Prepaid and Mobile IP. And what if a third > > application were > > > added? The approach is not scalable as the applications > > are increased > > > -- you would have to cope with all the different permutations of > > > Applications. The same argument goes for ServiceType and > > PortType and > > > these are actually more problematic. > > > > > > IMO the only thing we can do is to hint at the capability > > of the NAS. > > > > > > A proper solution should be concieved for this problem. > > > > > > > > > > -----Original Message----- > > > > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > > > Sent: Tuesday, September 05, 2006 2:09 PM > > > > To: Avi Lior; Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > > > Cc: dime@ietf.org > > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > Service-Type > > > > > > > > All, > > > > > > > > Here is a scenario that may need to be covered. In some > > cases, local > > > > HA assignment is optimal for transport efficiency perspective. > > > > Diameter > > > > MIP4 application allows this. In such a case the ASP == > > MSP and the > > > > HA is assigned locally (in the visited network). > > > > > > > > To enable this case, in the integrated scenario, the > > NAS/VAAA needs > > > > to indicate it's capability to assign an HA in the local > > network to > > > > the HAAA. The HAAA may allow or disallow this local HA assignment > > > > based on policy of the MSA. > > > > > > > > The NAS/VAAA may need to include a hint in the AAA message to the > > > > HAAA at the time of access authentication that it is capable of > > > > providing an HA to the MN. This capability indication > > (hint) can be > > > > either sent via a new MIP6 specific AVP or it can be > > conveyed via an > > > > existing AVP (I don't know if one exists). > > > > > > > > If we decide to include this (local HA assignment), and > > we decide to > > > > include this mip6 specific hint in the NAS-HAAA communication, we > > > > may have to choose the most appropriate option (1) vs. (2). > > > > > > > > Comments? > > > > > > > > -Kuntal > > > > > > > > > > > > > -----Original Message----- > > > > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > > > Sent: Tuesday, September 05, 2006 6:07 AM > > > > > To: Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > > > > Cc: dime@ietf.org > > > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > Service-Type > > > > > > > > > > I must be missing something. > > > > > > > > > > In the integrated scenario, what would the NAS put in > > Service-Type? > > > > > > > > > > I think in the integrated scenario neither Port-Type or > > > > Service-Type > > > > > needs to be touched. > > > > > > > > > > As far as I understand the NAS is either executing EAP > > > > Application or > > > > > NAS REQ. It does not know whether the user will result > > in having > > > > > subsequent Mobile IP service or not. > > > > > > > > > > The only thing the AAA server can do is to send the MIPv6 > > attributes > > > > as > > > > > optional (M bit off) and hope that if the NAS does not > > > > understand the > > > > > attributes it would have some logic to bootstrap a > > different way. > > > > > > > > > > We could improve the situration somewhat. We could > > have the NAS > > > > > indicate that it supports MIPv6 bootstrapping by including hints > > in > > > > the > > > > > AR (a capability hint). Where the NAS includes HA-IP > > address AVP > > > > both > > > > > indicating that it can support bootstrapping and if the > > > > HA-IP address > > > > is > > > > > not ALL-ZEROS or ALL ONES it provides a hint that it can support > > > > dynamic > > > > > HA assignement. > > > > > > > > > > Ofcourse we could introduce the concept of capability > > hints more > > > > > formally in Diameter -- This is missing today. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > > > > > Sent: Tuesday, September 05, 2006 3:35 AM > > > > > > To: Hannes.Tschofenig@gmx.net > > > > > > Cc: dime@ietf.org > > > > > > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > Service-Type > > > > > > > > > > > > Hi Hannes, > > > > > > > > > > > > I agree with Jouni. I prefer (2) for NAS-AAAH and (1) for > > > > AAAH-HA. > > > > > > In my understanding, there are no mandatory AVPs for NAS-AAAH > > and > > > > > > therefore I don't see a need of a new application; > > it's just a > > > > > > MIP-specific information that is piggybacked in the > > > > network access > > > > > > authentication procedure. > > > > > > > > > > > > Concerning AAAH-HA, I think it is a much cleaner approach > > > > to define > > > > > > a new application, since it does not anything to do > > with network > > > > > > authentication. > > > > > > > > > > > > --Gerardo > > > > > > > > > > > > On 9/5/06, jouni.korhonen@teliasonera.com > > > > > > wrote: > > > > > > > Hi HAnnes, > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > > > > > Sent: 1. syyskuuta 2006 1:07 > > > > > > > > To: dime@ietf.org > > > > > > > > Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > > Service-Type > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > we have had long discussions about the App-ID vs. > > > > > > > > Service-Type usage for > > > > > > > > Diameter MIPv6 Bootstrapping. > > > > > > > > > > > > > > > > It is time to see what the group thinks. Please indicate > > > > > > whether you > > > > > > > > prefer (1) an App-ID or (2) a Service-Type solution for > > > > > > > > > > > > > > > > (a) NAS-to-AAAH communication (as required by the > > integrated > > > > > > > > scenario; as one part of the solution component) > > > > > > > > > > > > > > I would prefer (2) for now.. or as long as the > > NAS-2-AAAH main > > > > > > > function is to provide access authentication, where the > > backend > > > > AAA > > > > > > > may return > > > > > > > MIP6 > > > > > > > bootstrapping info (as an enhancement) based e.g. > > on the user > > > > > > > subscription profile. If we go for more stuff on > > > > NAS-2-AAAH like > > > > > > > HoA/prefix etc then > > > > > > > (1) > > > > > > > might be better. > > > > > > > > > > > > > > > (b) HA-to-AAAH communication (as used by the split > > > > > > scenario and the > > > > > > > > integrated scenario) > > > > > > > > > > > > > > I would prefer (1) here. The use of EAP for MIP6 > > bootstrapping > > > > > > > purposes and for 'normal' EAP-based access > > authentication are > > > > > > > different applications imho. (although in IKEv2 vs > > 802.1X case > > > > e.g. > > > > > > > NAS-Port-Type could be used to make this distinction.. e.g. > > > > > > how 3GPP > > > > > > > WLAN stuff does it) > > > > > > > > > > > > > > > It might be useful to state a reason for your decision. > > > > > > > > > > > > > > > > Please also indicate whether some aspects are still > > > > > > unclear to you. > > > > > > > > > > > > > > > > Ciao > > > > > > > > Hannes > > > > > > > > > > > > > > Cheers, > > > > > > > Jouni > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > DiME mailing list > > > > > > > > DiME@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > DiME mailing list > > > > > > > DiME@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > DiME mailing list > > > > > > DiME@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > _______________________________________________ > > > > > DiME mailing list > > > > > DiME@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > "This email message and any attachments are confidential > > information > > > > of Starent Networks, Corp. The information transmitted may not be > > > > used to create or change any contractual obligations of Starent > > > > Networks, Corp. Any review, retransmission, > > dissemination or other > > > > use of, or taking of any action in reliance upon this > > e-mail and its > > > > attachments by persons or entities other than the > > intended recipient > > > > is prohibited. If you are not the intended recipient, > > please notify > > > > the sender immediately -- by replying to this message or > > by sending > > > > an email to postmaster@starentnetworks.com -- and destroy > > all copies > > > > of this message and any attachments without reading or disclosing > > > > their contents. Thank you." > > > > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime -- julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 07 05:32:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLGFO-0006xs-CI; Thu, 07 Sep 2006 05:32:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLGFM-0006xn-Rf for dime@ietf.org; Thu, 07 Sep 2006 05:32:32 -0400 Received: from ns1.nitro.ca ([216.209.86.226] helo=mailscanner.nitro.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLGFL-00067G-W7 for dime@ietf.org; Thu, 07 Sep 2006 05:32:32 -0400 Received: from bws14.bridgewatersystems.com (bws14.bridgewatersystems.com [216.113.7.14]) by mailscanner.nitro.ca (8.12.11/8.12.11) with ESMTP id k879VcVm024770 for ; Thu, 7 Sep 2006 05:31:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Date: Thu, 7 Sep 2006 05:31:48 -0400 Message-ID: In-Reply-To: <20060907091002.GA26293@ipv6-3.int-evry.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Thread-Index: AcbSXTs0bBmH28ShQmeO/A1ZlLNcEwAARNjQ From: "Avi Lior" To: "Julien Bournelle" , X-Nitro-MailScanner-Information: Please contact the ISP for more information X-Nitro-MailScanner: Found to be clean X-Nitro-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.599, required 4, autolearn=not spam, BAYES_00 -2.60) X-MailScanner-From: avi@bridgewatersystems.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org At the NAS the NAS should not report NAS-Port-Type =3D MIP because it = does not support MIP necessarily, it is just bootstrapping some DHCP parameters. Maybe NAS-Port-Type =3D MIPv6DHCPBoot? Yuk. Here is the Defn of NAS Port type: The NAS-Port-Type AVP (AVP Code 61) is of type Enumerated and contains the type of the port on which the NAS is authenticating the user. This AVP SHOULD be present if the NAS uses the same NAS-Port number ranges for different service types concurrently. Forgetting the last sentence. The NAS is not authenticating the user for MIP necessarily. It really doesn't know in all cases what the user will get in the integrated case. IMO a fair usage for NAS-Port-Type is for example in WiMAX, setting NAS-Port-Type =3D WiMAX. Now the home aaa will know that the NAS is authenticating a WiMAX type Port -- which could be MIPv4, PMIPv4, MIPv6 etc.... In the case of WiMAX for example, the HAAA will know that a WiMAX NAS can support bootstrapping -- because it may be a requirement on the NAS to do so. So that is sufficient. But in general we may need something better then that. Secondly the last time I looked you MAY only have one instance of NAS-Port-Type. I think using NAS-Port-Type as a hint in this case is not possible and IMO not recommended. > -----Original Message----- > From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]=20 > Sent: Thursday, September 07, 2006 5:10 AM > To: jouni.korhonen@teliasonera.com > Cc: Avi Lior; gerardo.giaretta@gmail.com;=20 > Hannes.Tschofenig@gmx.net; dime@ietf.org > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs.=20 > Service-Type >=20 > Hi, >=20 > On Tue, Sep 05, 2006 at 01:38:45PM +0200,=20 > jouni.korhonen@teliasonera.com wrote: > > Something MIP6 indicating that is not defined yet. > >=20 > > > I think in the integrated scenario neither Port-Type or=20 > Service-Type=20 > > > needs to be touched. > > >=20 > > > As far as I understand the NAS is either executing EAP=20 > Application=20 > > > or NAS REQ. It does not know whether the user will=20 > result in having=20 > > > subsequent Mobile IP service or not. > >=20 > > Yes. But there was this discussion/idea earlier that it could be=20 > > benefical from the AAA server point of view to have a hint=20 > whether the=20 > > NAS supports intergrated scenario at all. > >=20 > > > The only thing the AAA server can do is to send the MIPv6=20 > attributes=20 > > > as optional (M bit off) and hope that if the NAS does not=20 > understand=20 > > > the attributes it would have some logic to bootstrap a different=20 > > > way. > > >=20 > > > We could improve the situration somewhat. We could have the NAS=20 > > > indicate that it supports MIPv6 bootstrapping by=20 > including hints in=20 > > > the > > > AR (a capability hint). Where the NAS includes HA-IP=20 > > > address AVP both > >=20 > > And why can't the Service-Type or NAS-Port-type serve as a=20 > hint? e.g. > > NAS-Port-Type has been used in some architectures to distinguish=20 > > between .1X or IKEv2 originating EAP requests. >=20 > I'm thinking that the NAS will certainly add a NAS-Port-Type=20 > even if it supports mip6 integrated case. So this would mean=20 > that it will add 2 NAS-Port-Type ? > >=20 > > Well.. we could also put a bunch of AVPs to the access=20 > requests that=20 > > would serve as a capability hint. >=20 > yes. I tend to think that a sort of capability AVP here is=20 > interesting and may solve what we want. >=20 > Julien >=20 > >=20 > > > indicating that it can support bootstrapping and if the HA-IP=20 > > > address is not ALL-ZEROS or ALL ONES it provides a hint=20 > that it can=20 > > > support dynamic HA assignement. > > >=20 > > > Ofcourse we could introduce the concept of capability hints more=20 > > > formally in Diameter -- This is missing today. > >=20 > > Cheers, > > Jouni > >=20 > > >=20 > > >=20 > > >=20 > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > > > Sent: Tuesday, September 05, 2006 3:35 AM > > > > To: Hannes.Tschofenig@gmx.net > > > > Cc: dime@ietf.org > > > > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs.=20 > > > > Service-Type > > > >=20 > > > > Hi Hannes, > > > >=20 > > > > I agree with Jouni. I prefer (2) for NAS-AAAH and (1)=20 > for AAAH-HA.=20 > > > > In my understanding, there are no mandatory AVPs for=20 > NAS-AAAH and=20 > > > > therefore I don't see a need of a new application; it's just a=20 > > > > MIP-specific information that is piggybacked in the=20 > network access=20 > > > > authentication procedure. > > > >=20 > > > > Concerning AAAH-HA, I think it is a much cleaner approach to=20 > > > > define a new application, since it does not anything to do with=20 > > > > network authentication. > > > >=20 > > > > --Gerardo > > > >=20 > > > > On 9/5/06, jouni.korhonen@teliasonera.com=20 > > > > wrote: > > > > > Hi HAnnes, > > > > > > > > > > > -----Original Message----- > > > > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > > > Sent: 1. syyskuuta 2006 1:07 > > > > > > To: dime@ietf.org > > > > > > Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs.=20 > > > > > > Service-Type > > > > > > > > > > > > Hi all, > > > > > > > > > > > > we have had long discussions about the App-ID vs. > > > > > > Service-Type usage for > > > > > > Diameter MIPv6 Bootstrapping. > > > > > > > > > > > > It is time to see what the group thinks. Please indicate > > > > whether you > > > > > > prefer (1) an App-ID or (2) a Service-Type solution for > > > > > > > > > > > > (a) NAS-to-AAAH communication (as required by the=20 > integrated=20 > > > > > > scenario; as one part of the solution component) > > > > > > > > > > I would prefer (2) for now.. or as long as the=20 > NAS-2-AAAH main=20 > > > > > function is to provide access authentication, where the > > > backend AAA > > > > > may return > > > > > MIP6 > > > > > bootstrapping info (as an enhancement) based e.g. on the user=20 > > > > > subscription profile. If we go for more stuff on=20 > NAS-2-AAAH like=20 > > > > > HoA/prefix etc then > > > > > (1) > > > > > might be better. > > > > > > > > > > > (b) HA-to-AAAH communication (as used by the split > > > > scenario and the > > > > > > integrated scenario) > > > > > > > > > > I would prefer (1) here. The use of EAP for MIP6=20 > bootstrapping=20 > > > > > purposes and for 'normal' EAP-based access authentication are=20 > > > > > different applications imho. (although in IKEv2 vs 802.1X > > > case e.g.=20 > > > > > NAS-Port-Type could be used to make this distinction.. e.g.=20 > > > > how 3GPP > > > > > WLAN stuff does it) > > > > > > > > > > > It might be useful to state a reason for your decision. > > > > > > > > > > > > Please also indicate whether some aspects are still > > > > unclear to you. > > > > > > > > > > > > Ciao > > > > > > Hannes > > > > > > > > > > Cheers, > > > > > Jouni > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > DiME mailing list > > > > > > DiME@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > _______________________________________________ > > > > > DiME mailing list > > > > > DiME@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > >=20 > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > >=20 > > >=20 > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > >=20 > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime >=20 > -- > julien.bournelle at int-evry.fr >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 07 08:45:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLJGL-00060g-Ts; Thu, 07 Sep 2006 08:45:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLJGK-00060F-JY for dime@ietf.org; Thu, 07 Sep 2006 08:45:44 -0400 Received: from imx11.toshiba.co.jp ([61.202.160.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLJGI-0005BE-W3 for dime@ietf.org; Thu, 07 Sep 2006 08:45:44 -0400 Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx11.toshiba.co.jp with ESMTP id k87CjOuO008901; Thu, 7 Sep 2006 21:45:24 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id k87CjN4f005641; Thu, 7 Sep 2006 21:45:23 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with ESMTP id XAA05636; Thu, 7 Sep 2006 21:45:23 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id k87CjNvS025218; Thu, 7 Sep 2006 21:45:23 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k87CjMkb005622; Thu, 7 Sep 2006 21:45:22 +0900 (JST) Received: from steelhead ([172.30.24.105]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J58000NZ3FHAM60@mail.po.toshiba.co.jp>; Thu, 07 Sep 2006 21:45:22 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.63) (envelope-from ) id 1GLJFt-0003xu-JW; Thu, 07 Sep 2006 05:45:17 -0700 Date: Thu, 07 Sep 2006 08:45:17 -0400 From: Yoshihiro Ohba Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type In-reply-to: To: Avi Lior Message-id: <20060907124517.GA15012@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <20060906181643.GE5241@steelhead> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Avi, On Thu, Sep 07, 2006 at 12:48:22AM -0400, Avi Lior wrote: (snip) > > Unless I am missing something I think your forward compatibility problem > has issues with it. > > How would the NAS know to use the MobileIPv6 application id? It doesn't > have any knowledge that MobileIPv6 bootstrapping is required? > > If it selects that Application and the home network doesn't support > MobileIPv6 bootstrapping then the user will not get service. > > And going on in the future when there are other Applications which will > the NAS select? I think this specific issue you are raising is not specific to MIP6 bootstrapping application. It seems that the issue of "application discovery" is generally applicable to all applications, i.e., if NAS supports application X but it does not know which AAA server or realm actually support the application before running the application. The application discovery issue should be discussed separately (this maybe a new issue related to RFC3588bis). Regards, Yoshihiro Ohba _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 07 09:25:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLJsr-0002sU-4Z; Thu, 07 Sep 2006 09:25:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLJsp-0002sO-UA for dime@ietf.org; Thu, 07 Sep 2006 09:25:31 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLJso-0002Yb-M8 for dime@ietf.org; Thu, 07 Sep 2006 09:25:31 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id A98172FD53 for ; Thu, 7 Sep 2006 15:25:28 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1GLJvR-000736-FO for dime@ietf.org; Thu, 07 Sep 2006 15:28:13 +0200 Date: Thu, 7 Sep 2006 15:28:13 +0200 From: Julien Bournelle To: dime@ietf.org Message-ID: <20060907132813.GA27082@ipv6-3.int-evry.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Dime] Diameter MIPv6 Bootstrapping: case HA-AAAH X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, from the recent polling, it appears that we agree to define an new App-ID for the HA-AAAH case. So we'll move forward with this for the draft-ietf-dime-split-00.txt document. Thanks, Julien _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 07 09:43:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLK9m-0000wx-Nh; Thu, 07 Sep 2006 09:43:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLK9l-0000wr-IY for dime@ietf.org; Thu, 07 Sep 2006 09:43:01 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLK9b-0005S0-Tk for dime@ietf.org; Thu, 07 Sep 2006 09:43:01 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id k87DgnLx028136; Thu, 7 Sep 2006 22:42:49 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id k87DgoZl000346; Thu, 7 Sep 2006 22:42:50 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with ESMTP id YAA00343; Thu, 7 Sep 2006 22:42:49 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id k87Dgmds021082; Thu, 7 Sep 2006 22:42:48 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k87DgmVF003089; Thu, 7 Sep 2006 22:42:48 +0900 (JST) Received: from steelhead ([172.30.24.105]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J580004D635AM70@mail.po.toshiba.co.jp>; Thu, 07 Sep 2006 22:42:48 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.63) (envelope-from ) id 1GLK9R-0004Bf-9q; Thu, 07 Sep 2006 06:42:41 -0700 Date: Thu, 07 Sep 2006 09:42:41 -0400 From: Yoshihiro Ohba Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: case HA-AAAH In-reply-to: <20060907132813.GA27082@ipv6-3.int-evry.fr> To: Julien Bournelle Message-id: <20060907134240.GB15012@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <20060907132813.GA27082@ipv6-3.int-evry.fr> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Julien, I am not sure what level of agreement you mean. At least I have a concern on the following text in Section 4.2 of draft-ietf-dime-mip6-split-00.txt: " However, the protocol description requires that the new application needs to copy the Diameter messages from the Diameter EAP application. " When defining a new application with a new application identifier, if we define it by copying and modifying Diameter EAP ABNF, it will end up with permutation problem in a future. I don't agree with this specific way of defining a new application id as I already mentioned. Yoshihiro Ohba On Thu, Sep 07, 2006 at 03:28:13PM +0200, Julien Bournelle wrote: > Hi all, > > from the recent polling, it appears that we agree to define an new > App-ID for the HA-AAAH case. > > So we'll move forward with this for the draft-ietf-dime-split-00.txt > document. > > Thanks, > > Julien > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 07 10:03:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLKTd-0001G5-9j; Thu, 07 Sep 2006 10:03:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLKTc-0001G0-OV for dime@ietf.org; Thu, 07 Sep 2006 10:03:32 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLKTb-00007t-EX for dime@ietf.org; Thu, 07 Sep 2006 10:03:32 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id D1F572FF89; Thu, 7 Sep 2006 16:03:28 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1GLKWD-00076t-JR; Thu, 07 Sep 2006 16:06:13 +0200 Date: Thu, 7 Sep 2006 16:06:13 +0200 From: Julien Bournelle To: Yoshihiro Ohba Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: case HA-AAAH Message-ID: <20060907140613.GA27327@ipv6-3.int-evry.fr> References: <20060907132813.GA27082@ipv6-3.int-evry.fr> <20060907134240.GB15012@steelhead> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060907134240.GB15012@steelhead> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Yoshi, On Thu, Sep 07, 2006 at 09:42:41AM -0400, Yoshihiro Ohba wrote: > Hi Julien, > > I am not sure what level of agreement you mean. I can count 6 persons in favor of this. > At least I have a concern on the following text in Section 4.2 of > draft-ietf-dime-mip6-split-00.txt: > > " > However, the protocol > description requires that the new application needs to copy the > Diameter messages from the Diameter EAP application. > " maybe the sentence is a little bit strong. We need to carry the EAP packets between the HA and the AAAH. > When defining a new application with a new application identifier, if > we define it by copying and modifying Diameter EAP ABNF, it will end > up with permutation problem in a future. what do you mean ? Julien > I don't agree with this > specific way of defining a new application id as I already mentioned. > > Yoshihiro Ohba > > On Thu, Sep 07, 2006 at 03:28:13PM +0200, Julien Bournelle wrote: > > Hi all, > > > > from the recent polling, it appears that we agree to define an new > > App-ID for the HA-AAAH case. > > > > So we'll move forward with this for the draft-ietf-dime-split-00.txt > > document. > > > > Thanks, > > > > Julien > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > -- julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 07 10:16:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLKfi-0005vp-Lv; Thu, 07 Sep 2006 10:16:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLKfh-0005vk-G8 for dime@ietf.org; Thu, 07 Sep 2006 10:16:01 -0400 Received: from imx11.toshiba.co.jp ([61.202.160.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLKfa-0002jp-Qm for dime@ietf.org; Thu, 07 Sep 2006 10:16:01 -0400 Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx11.toshiba.co.jp with ESMTP id k87EFqLB001871; Thu, 7 Sep 2006 23:15:52 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id k87EFqx7020125; Thu, 7 Sep 2006 23:15:52 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with ESMTP id ZAA20120; Thu, 7 Sep 2006 23:15:51 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id k87EFpIx010413; Thu, 7 Sep 2006 23:15:51 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k87EFo62015547; Thu, 7 Sep 2006 23:15:50 +0900 (JST) Received: from steelhead ([172.30.24.105]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J58000087M8AP70@mail.po.toshiba.co.jp>; Thu, 07 Sep 2006 23:15:50 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.63) (envelope-from ) id 1GLKfO-0004IG-Ol; Thu, 07 Sep 2006 07:15:42 -0700 Date: Thu, 07 Sep 2006 10:15:42 -0400 From: Yoshihiro Ohba Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: case HA-AAAH In-reply-to: <20060907140613.GA27327@ipv6-3.int-evry.fr> To: Julien Bournelle Message-id: <20060907141542.GC15012@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <20060907132813.GA27082@ipv6-3.int-evry.fr> <20060907134240.GB15012@steelhead> <20060907140613.GA27327@ipv6-3.int-evry.fr> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org On Thu, Sep 07, 2006 at 04:06:13PM +0200, Julien Bournelle wrote: > > > At least I have a concern on the following text in Section 4.2 of > > draft-ietf-dime-mip6-split-00.txt: > > > > " > > However, the protocol > > description requires that the new application needs to copy the > > Diameter messages from the Diameter EAP application. > > " > > maybe the sentence is a little bit strong. We need to carry the EAP > packets between the HA and the AAAH. Why does a new application with a new application id need to carry EAP packets? Why can't it be defined as a totally separate application that is executed after running EAP application? > > > When defining a new application with a new application identifier, if > > we define it by copying and modifying Diameter EAP ABNF, it will end > > up with permutation problem in a future. > > what do you mean ? Please see the following email: http://www1.ietf.org/mail-archive/web/dime/current/msg00706.html Yoshihiro Ohba > > Julien > > > I don't agree with this > > specific way of defining a new application id as I already mentioned. > > > > Yoshihiro Ohba > > > > On Thu, Sep 07, 2006 at 03:28:13PM +0200, Julien Bournelle wrote: > > > Hi all, > > > > > > from the recent polling, it appears that we agree to define an new > > > App-ID for the HA-AAAH case. > > > > > > So we'll move forward with this for the draft-ietf-dime-split-00.txt > > > document. > > > > > > Thanks, > > > > > > Julien > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > -- > julien.bournelle at int-evry.fr > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 07 10:31:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLKue-0002Rl-Dv; Thu, 07 Sep 2006 10:31:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLKuc-0002Qo-Vt for dime@ietf.org; Thu, 07 Sep 2006 10:31:26 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLKuc-0005U6-4X for dime@ietf.org; Thu, 07 Sep 2006 10:31:26 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 7468A9000E; Thu, 7 Sep 2006 10:31:22 -0400 (EDT) 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 28171-10; Thu, 7 Sep 2006 10:31:21 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP; Thu, 7 Sep 2006 10:31:21 -0400 (EDT) X-MessageTextProcessor: DisclaimIt (2.70.271) [Starent Networks Corp.] Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Sep 2006 10:31:21 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Date: Thu, 7 Sep 2006 10:31:20 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7837317@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type thread-index: AcbSXTs0bBmH28ShQmeO/A1ZlLNcEwAARNjQAAqxjOA= From: "Chowdhury, Kuntal" To: "Avi Lior" , "Julien Bournelle" , Importance: normal Priority: normal X-OriginalArrivalTime: 07 Sep 2006 14:31:21.0175 (UTC) FILETIME=[49C73670:01C6D28A] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org All, For NAS-HAAA transaction, all we need the NAS to do is to send a hint to the HAAA that it can handle mip6 bootstrap attribute(s) if the HAAA decides to send those in the Diameter EAP/NASREQ response, that's all. Now, let's see the options we have to convey this hint: 1. APP-id: may be an overkill for a hint, but may be the cleanest solution. 2. NAS-port-type: the new value may need to be overloaded to convey more than one hint. 3. Capability AVP: the NAS that support mip6bootstrapping can include this optional AVP in the Diameter EAP/NASREQ messages. Option 3, seems to be simple enough to serve the purpose i.e. convey the hint, IMHO. Let me know if you think otherwise. -Kuntal > -----Original Message----- > From: Avi Lior [mailto:avi@bridgewatersystems.com]=20 > Sent: Thursday, September 07, 2006 4:32 AM > To: Julien Bournelle; jouni.korhonen@teliasonera.com > Cc: dime@ietf.org > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs.=20 > Service-Type >=20 > At the NAS the NAS should not report NAS-Port-Type =3D MIP=20 > because it does not support MIP necessarily, it is just=20 > bootstrapping some DHCP parameters. >=20 > Maybe NAS-Port-Type =3D MIPv6DHCPBoot? Yuk. >=20 > Here is the Defn of NAS Port type: >=20 > The NAS-Port-Type AVP (AVP Code 61) is of type Enumerated and > contains the type of the port on which the NAS is=20 > authenticating the > user. This AVP SHOULD be present if the NAS uses the same NAS-Port > number ranges for different service types concurrently. >=20 > Forgetting the last sentence. The NAS is not authenticating=20 > the user for MIP necessarily. It really doesn't know in all=20 > cases what the user will get in the integrated case. >=20 > IMO a fair usage for NAS-Port-Type is for example in WiMAX,=20 > setting NAS-Port-Type =3D WiMAX. Now the home aaa will know=20 > that the NAS is authenticating a WiMAX type Port -- which=20 > could be MIPv4, PMIPv4, MIPv6 etc.... >=20 > In the case of WiMAX for example, the HAAA will know that a=20 > WiMAX NAS can support bootstrapping -- because it may be a=20 > requirement on the NAS to do so. So that is sufficient. But=20 > in general we may need something better then that. >=20 >=20 > Secondly the last time I looked you MAY only have one=20 > instance of NAS-Port-Type. >=20 > I think using NAS-Port-Type as a hint in this case is not=20 > possible and IMO not recommended. >=20 > > -----Original Message----- > > From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > > Sent: Thursday, September 07, 2006 5:10 AM > > To: jouni.korhonen@teliasonera.com > > Cc: Avi Lior; gerardo.giaretta@gmail.com;=20 > Hannes.Tschofenig@gmx.net;=20 > > dime@ietf.org > > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs.=20 > > Service-Type > >=20 > > Hi, > >=20 > > On Tue, Sep 05, 2006 at 01:38:45PM +0200,=20 > > jouni.korhonen@teliasonera.com wrote: > > > Something MIP6 indicating that is not defined yet. > > >=20 > > > > I think in the integrated scenario neither Port-Type or > > Service-Type > > > > needs to be touched. > > > >=20 > > > > As far as I understand the NAS is either executing EAP > > Application > > > > or NAS REQ. It does not know whether the user will > > result in having > > > > subsequent Mobile IP service or not. > > >=20 > > > Yes. But there was this discussion/idea earlier that it could be=20 > > > benefical from the AAA server point of view to have a hint > > whether the > > > NAS supports intergrated scenario at all. > > >=20 > > > > The only thing the AAA server can do is to send the MIPv6 > > attributes > > > > as optional (M bit off) and hope that if the NAS does not > > understand > > > > the attributes it would have some logic to bootstrap a=20 > different=20 > > > > way. > > > >=20 > > > > We could improve the situration somewhat. We could=20 > have the NAS=20 > > > > indicate that it supports MIPv6 bootstrapping by > > including hints in > > > > the > > > > AR (a capability hint). Where the NAS includes HA-IP=20 > > > > address AVP both > > >=20 > > > And why can't the Service-Type or NAS-Port-type serve as a > > hint? e.g. > > > NAS-Port-Type has been used in some architectures to distinguish=20 > > > between .1X or IKEv2 originating EAP requests. > >=20 > > I'm thinking that the NAS will certainly add a=20 > NAS-Port-Type even if=20 > > it supports mip6 integrated case. So this would mean that=20 > it will add=20 > > 2 NAS-Port-Type ? > > >=20 > > > Well.. we could also put a bunch of AVPs to the access > > requests that > > > would serve as a capability hint. > >=20 > > yes. I tend to think that a sort of capability AVP here is=20 > > interesting and may solve what we want. > >=20 > > Julien > >=20 > > >=20 > > > > indicating that it can support bootstrapping and if the HA-IP=20 > > > > address is not ALL-ZEROS or ALL ONES it provides a hint > > that it can > > > > support dynamic HA assignement. > > > >=20 > > > > Ofcourse we could introduce the concept of capability=20 > hints more=20 > > > > formally in Diameter -- This is missing today. > > >=20 > > > Cheers, > > > Jouni > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > =20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > > > > Sent: Tuesday, September 05, 2006 3:35 AM > > > > > To: Hannes.Tschofenig@gmx.net > > > > > Cc: dime@ietf.org > > > > > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs.=20 > > > > > Service-Type > > > > >=20 > > > > > Hi Hannes, > > > > >=20 > > > > > I agree with Jouni. I prefer (2) for NAS-AAAH and (1) > > for AAAH-HA.=20 > > > > > In my understanding, there are no mandatory AVPs for > > NAS-AAAH and > > > > > therefore I don't see a need of a new application;=20 > it's just a=20 > > > > > MIP-specific information that is piggybacked in the > > network access > > > > > authentication procedure. > > > > >=20 > > > > > Concerning AAAH-HA, I think it is a much cleaner approach to=20 > > > > > define a new application, since it does not anything=20 > to do with=20 > > > > > network authentication. > > > > >=20 > > > > > --Gerardo > > > > >=20 > > > > > On 9/5/06, jouni.korhonen@teliasonera.com=20 > > > > > wrote: > > > > > > Hi HAnnes, > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > > > > Sent: 1. syyskuuta 2006 1:07 > > > > > > > To: dime@ietf.org > > > > > > > Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs.=20 > > > > > > > Service-Type > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > we have had long discussions about the App-ID vs. > > > > > > > Service-Type usage for > > > > > > > Diameter MIPv6 Bootstrapping. > > > > > > > > > > > > > > It is time to see what the group thinks. Please indicate > > > > > whether you > > > > > > > prefer (1) an App-ID or (2) a Service-Type solution for > > > > > > > > > > > > > > (a) NAS-to-AAAH communication (as required by the > > integrated > > > > > > > scenario; as one part of the solution component) > > > > > > > > > > > > I would prefer (2) for now.. or as long as the > > NAS-2-AAAH main > > > > > > function is to provide access authentication, where the > > > > backend AAA > > > > > > may return > > > > > > MIP6 > > > > > > bootstrapping info (as an enhancement) based e.g.=20 > on the user=20 > > > > > > subscription profile. If we go for more stuff on > > NAS-2-AAAH like > > > > > > HoA/prefix etc then > > > > > > (1) > > > > > > might be better. > > > > > > > > > > > > > (b) HA-to-AAAH communication (as used by the split > > > > > scenario and the > > > > > > > integrated scenario) > > > > > > > > > > > > I would prefer (1) here. The use of EAP for MIP6 > > bootstrapping > > > > > > purposes and for 'normal' EAP-based access=20 > authentication are=20 > > > > > > different applications imho. (although in IKEv2 vs 802.1X > > > > case e.g.=20 > > > > > > NAS-Port-Type could be used to make this distinction.. e.g.=20 > > > > > how 3GPP > > > > > > WLAN stuff does it) > > > > > > > > > > > > > It might be useful to state a reason for your decision. > > > > > > > > > > > > > > Please also indicate whether some aspects are still > > > > > unclear to you. > > > > > > > > > > > > > > Ciao > > > > > > > Hannes > > > > > > > > > > > > Cheers, > > > > > > Jouni > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > DiME mailing list > > > > > > > DiME@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > DiME mailing list > > > > > > DiME@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > >=20 > > > > > _______________________________________________ > > > > > DiME mailing list > > > > > DiME@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > >=20 > > >=20 > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > >=20 > > -- > > julien.bournelle at int-evry.fr > >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 "This email message and any attachments are confidential information of = Starent Networks, Corp. The information transmitted may not be used to = create or change any contractual obligations of Starent Networks, Corp. = Any review, retransmission, dissemination or other use of, or taking of = any action in reliance upon this e-mail and its attachments by persons = or entities other than the intended recipient is prohibited. If you are = not the intended recipient, please notify the sender immediately -- by = replying to this message or by sending an email to = postmaster@starentnetworks.com -- and destroy all copies of this message = and any attachments without reading or disclosing their contents. Thank = you." _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 07 11:17:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLLcj-0001nO-8j; Thu, 07 Sep 2006 11:17:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLLci-0001mi-46 for dime@ietf.org; Thu, 07 Sep 2006 11:17:00 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLLUZ-0001vt-S3 for dime@ietf.org; Thu, 07 Sep 2006 11:08:37 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 062342FDFF; Thu, 7 Sep 2006 17:08:19 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1GLLWx-000796-N8; Thu, 07 Sep 2006 17:11:03 +0200 Date: Thu, 7 Sep 2006 17:11:03 +0200 From: Julien Bournelle To: Yoshihiro Ohba Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: case HA-AAAH Message-ID: <20060907151103.GA27450@ipv6-3.int-evry.fr> References: <20060907132813.GA27082@ipv6-3.int-evry.fr> <20060907134240.GB15012@steelhead> <20060907140613.GA27327@ipv6-3.int-evry.fr> <20060907141542.GC15012@steelhead> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060907141542.GC15012@steelhead> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi yoshi, On Thu, Sep 07, 2006 at 10:15:42AM -0400, Yoshihiro Ohba wrote: > On Thu, Sep 07, 2006 at 04:06:13PM +0200, Julien Bournelle wrote: > > > > > At least I have a concern on the following text in Section 4.2 of > > > draft-ietf-dime-mip6-split-00.txt: > > > > > > " > > > However, the protocol > > > description requires that the new application needs to copy the > > > Diameter messages from the Diameter EAP application. > > > " > > > > maybe the sentence is a little bit strong. We need to carry the EAP > > packets between the HA and the AAAH. > > Why does a new application with a new application id need to carry EAP > packets? Why can't it be defined as a totally separate application > that is executed after running EAP application? because EAP application has been defined for network access service whereas EAP is basically only for Authentication. " This document specifies the Diameter EAP application that carries EAP packets between a Network Access Server (NAS) working as an EAP Authenticator and a back-end authentication server. The Diameter EAP application is based on the Diameter Network Access Server Application [NASREQ] and is intended for environments similar to NASREQ. " So in the EAP Application, EAP is used for the Authentication and the AAA server receiving a message with App-ID set to 5 (Diameter-EAP) "knows" implicitely that it is doing this for authorizing network access. NAS-Port-Type or Service-Type helps him to know if it's WiMAX for example. At least, this is my understanding. In our case, as it has already been said, we need to do AAA for the Mobile IPv6 service. The "problem" is that the first "A" of AAA is done with EAP so we have a sort of overlapping with Diameter EAP. If the authentication was done in a totally different way, I guess we won't have this problem of App-Id or not. > > > When defining a new application with a new application identifier, if > > > we define it by copying and modifying Diameter EAP ABNF, it will end > > > up with permutation problem in a future. > > > > what do you mean ? > > Please see the following email: > http://www1.ietf.org/mail-archive/web/dime/current/msg00706.html ok. Let me respond to this in your mail. Thanks, Julien > > Yoshihiro Ohba > > > > > > Julien > > > > > I don't agree with this > > > specific way of defining a new application id as I already mentioned. > > > > > > Yoshihiro Ohba > > > > > > On Thu, Sep 07, 2006 at 03:28:13PM +0200, Julien Bournelle wrote: > > > > Hi all, > > > > > > > > from the recent polling, it appears that we agree to define an new > > > > App-ID for the HA-AAAH case. > > > > > > > > So we'll move forward with this for the draft-ietf-dime-split-00.txt > > > > document. > > > > > > > > Thanks, > > > > > > > > Julien > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > -- > > julien.bournelle at int-evry.fr > > -- julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 07 11:19:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLLfA-0002vm-LZ; Thu, 07 Sep 2006 11:19:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLLf9-0002vd-6r for dime@ietf.org; Thu, 07 Sep 2006 11:19:31 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLLf8-0003Y2-DH for dime@ietf.org; Thu, 07 Sep 2006 11:19:31 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 3C36D2FD48; Thu, 7 Sep 2006 17:19:27 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1GLLhj-00079S-SL; Thu, 07 Sep 2006 17:22:11 +0200 Date: Thu, 7 Sep 2006 17:22:11 +0200 From: Julien Bournelle To: Yoshihiro Ohba Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Message-ID: <20060907152211.GA27475@ipv6-3.int-evry.fr> References: <7CCD07160348804497EF29E9EA5560D78372F8@exchtewks2.starentnetworks.com> <20060906181643.GE5241@steelhead> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060906181643.GE5241@steelhead> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 4515df9441674711565101d9d5c4f63f Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, On Wed, Sep 06, 2006 at 02:16:43PM -0400, Yoshihiro Ohba wrote: > I agree with Avi that defining a new application for MIP6 > bootstrapping by assigning a new application identifier but borrowing > and modifying ABNF of existing applications (i.e., Diameter EAP and > NASREQ) will end up with "a lot of permutations in Diameter > specifications" problem in a future when other applications need to be > developed that use EAP for authentication purpose and requires new > mandatory AVPs for authorization purpose. I don't agree with this > option. ok I understand what do you mean by "permutations" now. Personnally I don't think this is really an issue and I'm not sure we can avoid this. EAP is used for the first A of AAA and the 2 others AA may need specific things depending on the application and differents servers may be deployed depending on this application. > > I also agree with Avi that defining a new application for MIP6 > bootstrapping on top of existing applications (Diameter EAP) without > defining a new application id but with defining new values for > existing AVPs or new optional AVPs has some issue, but this option > might not be as bad as the first option since backward compatibility > can be easily maintained unlike the first option. However, there is a > forward compatibility problem (i.e., a Diameter message may be forwarded > to a AAA server that does not support the new application). Besides > this problem, it might be worth pursuing this option because it works > in an optimized way (i.e., bootstrapping AVPs are piggybacked in > Diameter EAP or NASREQ message) as long as both NAS and AAA server > support the AVPs. I'm not in favor of having an app-id for the nas-aaah part of the mip6 bootstrapping problem. > > In order to deal with the forward compatibility problem of the second > option, a third option is to define a new application for MIP6 > bootstrapping as a totally new authorization application that carries > new mandatory AVPs specific to that application. This option can be > run when execution of the second option succeeds in authentication but > fails in carrying bootstrapping AVPs. hmm, i guess i have to think more of this option but this would mandate now that all EAP Application server should know that maybe they are not doing this for network access and that maybe they are going to receive a special authorization request. And in this case, wouldn't it mean that network access should be treated as a special service and this would also require a new authorization application ? regards, Julien > > Regards, > Yoshihiro Ohba > > > > > > On Tue, Sep 05, 2006 at 11:21:22PM -0400, Avi Lior wrote: > > Hi Kuntal, > > > > Neither option 1 or option 2 will work. A new application id just wont > > scale in the long run. What if another 'capability' were to be added > > for instance prepaid. Since Diameter messages contain only one > > Application ID, you would have to create an Application Id that covered > > both EAP, Prepaid and Mobile IP. And what if a third application were > > added? The approach is not scalable as the applications are increased > > -- you would have to cope with all the different permutations of > > Applications. The same argument goes for ServiceType and PortType and > > these are actually more problematic. > > > > IMO the only thing we can do is to hint at the capability of the NAS. > > > > A proper solution should be concieved for this problem. > > > > > > > -----Original Message----- > > > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > > Sent: Tuesday, September 05, 2006 2:09 PM > > > To: Avi Lior; Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > > Cc: dime@ietf.org > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > Service-Type > > > > > > All, > > > > > > Here is a scenario that may need to be covered. In some > > > cases, local HA assignment is optimal for transport > > > efficiency perspective. Diameter > > > MIP4 application allows this. In such a case the ASP == MSP > > > and the HA is assigned locally (in the visited network). > > > > > > To enable this case, in the integrated scenario, the NAS/VAAA > > > needs to indicate it's capability to assign an HA in the > > > local network to the HAAA. The HAAA may allow or disallow > > > this local HA assignment based on policy of the MSA. > > > > > > The NAS/VAAA may need to include a hint in the AAA message to > > > the HAAA at the time of access authentication that it is > > > capable of providing an HA to the MN. This capability > > > indication (hint) can be either sent via a new MIP6 specific > > > AVP or it can be conveyed via an existing AVP (I don't know > > > if one exists). > > > > > > If we decide to include this (local HA assignment), and we > > > decide to include this mip6 specific hint in the NAS-HAAA > > > communication, we may have to choose the most appropriate > > > option (1) vs. (2). > > > > > > Comments? > > > > > > -Kuntal > > > > > > > > > > -----Original Message----- > > > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > > Sent: Tuesday, September 05, 2006 6:07 AM > > > > To: Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > > > Cc: dime@ietf.org > > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > Service-Type > > > > > > > > I must be missing something. > > > > > > > > In the integrated scenario, what would the NAS put in Service-Type? > > > > > > > > I think in the integrated scenario neither Port-Type or > > > Service-Type > > > > needs to be touched. > > > > > > > > As far as I understand the NAS is either executing EAP > > > Application or > > > > NAS REQ. It does not know whether the user will result in having > > > > subsequent Mobile IP service or not. > > > > > > > > The only thing the AAA server can do is to send the MIPv6 attributes > > > as > > > > optional (M bit off) and hope that if the NAS does not > > > understand the > > > > attributes it would have some logic to bootstrap a different way. > > > > > > > > We could improve the situration somewhat. We could have the NAS > > > > indicate that it supports MIPv6 bootstrapping by including hints in > > > the > > > > AR (a capability hint). Where the NAS includes HA-IP address AVP > > > both > > > > indicating that it can support bootstrapping and if the > > > HA-IP address > > > is > > > > not ALL-ZEROS or ALL ONES it provides a hint that it can support > > > dynamic > > > > HA assignement. > > > > > > > > Ofcourse we could introduce the concept of capability hints more > > > > formally in Diameter -- This is missing today. > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > > > > Sent: Tuesday, September 05, 2006 3:35 AM > > > > > To: Hannes.Tschofenig@gmx.net > > > > > Cc: dime@ietf.org > > > > > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > Service-Type > > > > > > > > > > Hi Hannes, > > > > > > > > > > I agree with Jouni. I prefer (2) for NAS-AAAH and (1) for > > > AAAH-HA. > > > > > In my understanding, there are no mandatory AVPs for NAS-AAAH and > > > > > therefore I don't see a need of a new application; it's just a > > > > > MIP-specific information that is piggybacked in the > > > network access > > > > > authentication procedure. > > > > > > > > > > Concerning AAAH-HA, I think it is a much cleaner approach > > > to define > > > > > a new application, since it does not anything to do with network > > > > > authentication. > > > > > > > > > > --Gerardo > > > > > > > > > > On 9/5/06, jouni.korhonen@teliasonera.com > > > > > wrote: > > > > > > Hi HAnnes, > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > > > > Sent: 1. syyskuuta 2006 1:07 > > > > > > > To: dime@ietf.org > > > > > > > Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > Service-Type > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > we have had long discussions about the App-ID vs. > > > > > > > Service-Type usage for > > > > > > > Diameter MIPv6 Bootstrapping. > > > > > > > > > > > > > > It is time to see what the group thinks. Please indicate > > > > > whether you > > > > > > > prefer (1) an App-ID or (2) a Service-Type solution for > > > > > > > > > > > > > > (a) NAS-to-AAAH communication (as required by the integrated > > > > > > > scenario; as one part of the solution component) > > > > > > > > > > > > I would prefer (2) for now.. or as long as the NAS-2-AAAH main > > > > > > function is to provide access authentication, where the backend > > > AAA > > > > > > may return > > > > > > MIP6 > > > > > > bootstrapping info (as an enhancement) based e.g. on the user > > > > > > subscription profile. If we go for more stuff on > > > NAS-2-AAAH like > > > > > > HoA/prefix etc then > > > > > > (1) > > > > > > might be better. > > > > > > > > > > > > > (b) HA-to-AAAH communication (as used by the split > > > > > scenario and the > > > > > > > integrated scenario) > > > > > > > > > > > > I would prefer (1) here. The use of EAP for MIP6 bootstrapping > > > > > > purposes and for 'normal' EAP-based access authentication are > > > > > > different applications imho. (although in IKEv2 vs 802.1X case > > > e.g. > > > > > > NAS-Port-Type could be used to make this distinction.. e.g. > > > > > how 3GPP > > > > > > WLAN stuff does it) > > > > > > > > > > > > > It might be useful to state a reason for your decision. > > > > > > > > > > > > > > Please also indicate whether some aspects are still > > > > > unclear to you. > > > > > > > > > > > > > > Ciao > > > > > > > Hannes > > > > > > > > > > > > Cheers, > > > > > > Jouni > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > DiME mailing list > > > > > > > DiME@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > DiME mailing list > > > > > > DiME@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > _______________________________________________ > > > > > DiME mailing list > > > > > DiME@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > "This email message and any attachments are confidential > > > information of Starent Networks, Corp. The information > > > transmitted may not be used to create or change any > > > contractual obligations of Starent Networks, Corp. Any > > > review, retransmission, dissemination or other use of, or > > > taking of any action in reliance upon this e-mail and its > > > attachments by persons or entities other than the intended > > > recipient is prohibited. If you are not the intended > > > recipient, please notify the sender immediately -- by > > > replying to this message or by sending an email to > > > postmaster@starentnetworks.com -- and destroy all copies of > > > this message and any attachments without reading or > > > disclosing their contents. Thank you." > > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime -- julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 07 15:31:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLPaX-0005TD-66; Thu, 07 Sep 2006 15:31:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLPaV-0005Sx-T5 for dime@ietf.org; Thu, 07 Sep 2006 15:30:59 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLPaS-0004m1-J1 for dime@ietf.org; Thu, 07 Sep 2006 15:30:59 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 07 Sep 2006 12:30:54 -0700 X-IronPort-AV: i="4.08,226,1154934000"; d="scan'208"; a="1852451863:sNHT6687106704" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k87JUrOu000607 for ; Thu, 7 Sep 2006 12:30:53 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k87JUr1E022774 for ; Thu, 7 Sep 2006 12:30:53 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Sep 2006 12:30:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Sep 2006 12:30:52 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250295B0E6@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Diameter MIP Thread-Index: AcbSkwQKJBcZ+dlIROWxziMwJd8uhAAIKC6g From: "Glen Zorn \(gwz\)" To: X-OriginalArrivalTime: 07 Sep 2006 19:30:53.0185 (UTC) FILETIME=[21EE4F10:01C6D2B4] DKIM-Signature: a=rsa-sha1; q=dns; l=228; t=1157657453; x=1158521453; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20Diameter=20MIP; X=v=3Dcisco.com=3B=20h=3DQdGiM9tdn8IoUgRqPHhiqbqB2+w=3D; b=EHkBZr/y1u/vwdF/DymVf3QBhAchKIrbTlELrWwQuLN5M3GFGrkCf8gZJ55lEadqYZHVKZ9u BBlQgFHzq1bEuKKXo8S8L1zT1GozMCwJ52uWxNN//Js3H+0+47oSm52R; Authentication-Results: sj-dkim-4.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Subject: [Dime] Diameter MIP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org One reason that I don't think has been mentioned yet for defining new App IDs for both flavors of MIP is that accounting for MIP is likely to be defined differently than that for generic network access (i.e. NASREQ or EAP). _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 07 15:57:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLQ0B-00016n-6k; Thu, 07 Sep 2006 15:57:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLQ0A-00013D-2X for dime@ietf.org; Thu, 07 Sep 2006 15:57:30 -0400 Received: from imx11.toshiba.co.jp ([61.202.160.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLQ08-0007wU-EK for dime@ietf.org; Thu, 07 Sep 2006 15:57:30 -0400 Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx11.toshiba.co.jp with ESMTP id k87JvQGb009287; Fri, 8 Sep 2006 04:57:26 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id k87JvQ6Z016986; Fri, 8 Sep 2006 04:57:26 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with ESMTP id EAA16983; Fri, 8 Sep 2006 04:57:25 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id k87JvPJQ009782; Fri, 8 Sep 2006 04:57:25 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k87JvP40002111; Fri, 8 Sep 2006 04:57:25 +0900 (JST) Received: from steelhead ([172.30.24.105]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J5800005NFJAM90@mail.po.toshiba.co.jp>; Fri, 08 Sep 2006 04:57:24 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.63) (envelope-from ) id 1GLPzz-00054n-41; Thu, 07 Sep 2006 12:57:19 -0700 Date: Thu, 07 Sep 2006 15:57:19 -0400 From: Yoshihiro Ohba Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: case HA-AAAH In-reply-to: <20060907151103.GA27450@ipv6-3.int-evry.fr> To: Julien Bournelle Message-id: <20060907195719.GA18410@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <20060907132813.GA27082@ipv6-3.int-evry.fr> <20060907134240.GB15012@steelhead> <20060907140613.GA27327@ipv6-3.int-evry.fr> <20060907141542.GC15012@steelhead> <20060907151103.GA27450@ipv6-3.int-evry.fr> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Julien, I was not saying that first A (authentication) should be done in different way. What I am saying that second A (authorization) can be defined separately from the first A and can be run sequencially (i.e., an application for second A (e.g., MIP6 bootstrapping) follows another application for first A (e.g., EAP). Yoshihiro Ohba On Thu, Sep 07, 2006 at 05:11:03PM +0200, Julien Bournelle wrote: > Hi yoshi, > > On Thu, Sep 07, 2006 at 10:15:42AM -0400, Yoshihiro Ohba wrote: > > On Thu, Sep 07, 2006 at 04:06:13PM +0200, Julien Bournelle wrote: > > > > > > > At least I have a concern on the following text in Section 4.2 of > > > > draft-ietf-dime-mip6-split-00.txt: > > > > > > > > " > > > > However, the protocol > > > > description requires that the new application needs to copy the > > > > Diameter messages from the Diameter EAP application. > > > > " > > > > > > maybe the sentence is a little bit strong. We need to carry the EAP > > > packets between the HA and the AAAH. > > > > Why does a new application with a new application id need to carry EAP > > packets? Why can't it be defined as a totally separate application > > that is executed after running EAP application? > > because EAP application has been defined for network access > service whereas EAP is basically only for Authentication. > > " > This document specifies the Diameter EAP application that carries EAP > packets between a Network Access Server (NAS) working as an EAP > Authenticator and a back-end authentication server. The Diameter > EAP application is based on the Diameter Network Access Server > Application [NASREQ] and is intended for environments similar to > NASREQ. > " > > So in the EAP Application, EAP is used for the Authentication and the > AAA server receiving a message with App-ID set to 5 (Diameter-EAP) > "knows" implicitely that it is doing this for authorizing > network access. NAS-Port-Type or Service-Type helps him to know if it's > WiMAX for example. At least, this is my understanding. > > In our case, as it has already been said, we need to do AAA for the > Mobile IPv6 service. The "problem" is that the first "A" of AAA is done > with EAP so we have a sort of overlapping with Diameter EAP. If the > authentication was done in a totally different way, I guess we won't > have this problem of App-Id or not. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 07 16:34:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLQZg-0000Mn-U9; Thu, 07 Sep 2006 16:34:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLQZf-0000FU-B2 for dime@ietf.org; Thu, 07 Sep 2006 16:34:11 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLQZW-0005cl-DU for dime@ietf.org; Thu, 07 Sep 2006 16:34:11 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id k87KXtAp020030; Fri, 8 Sep 2006 05:33:55 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id k87KXuvM028338; Fri, 8 Sep 2006 05:33:56 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with ESMTP id FAA28337; Fri, 8 Sep 2006 05:33:56 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id k87KXst6017860; Fri, 8 Sep 2006 05:33:55 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k87KXsVE014162; Fri, 8 Sep 2006 05:33:54 +0900 (JST) Received: from steelhead ([172.30.24.105]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J5800062P4CAM90@mail.po.toshiba.co.jp>; Fri, 08 Sep 2006 05:33:54 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.63) (envelope-from ) id 1GLQYy-0005EB-CL; Thu, 07 Sep 2006 13:33:28 -0700 Date: Thu, 07 Sep 2006 16:33:28 -0400 From: Yoshihiro Ohba Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type In-reply-to: <20060907152211.GA27475@ipv6-3.int-evry.fr> To: Julien Bournelle Message-id: <20060907203328.GB18410@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <7CCD07160348804497EF29E9EA5560D78372F8@exchtewks2.starentnetworks.com> <20060906181643.GE5241@steelhead> <20060907152211.GA27475@ipv6-3.int-evry.fr> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ba9b8496764663b12c333825fbf6b3d Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Julien, On Thu, Sep 07, 2006 at 05:22:11PM +0200, Julien Bournelle wrote: > Hi, > > On Wed, Sep 06, 2006 at 02:16:43PM -0400, Yoshihiro Ohba wrote: > > I agree with Avi that defining a new application for MIP6 > > bootstrapping by assigning a new application identifier but borrowing > > and modifying ABNF of existing applications (i.e., Diameter EAP and > > NASREQ) will end up with "a lot of permutations in Diameter > > specifications" problem in a future when other applications need to be > > developed that use EAP for authentication purpose and requires new > > mandatory AVPs for authorization purpose. I don't agree with this > > option. > > ok I understand what do you mean by "permutations" now. > Personnally I don't think this is really an issue and I'm not sure we > can avoid this. Why you don't think this is not an issue? It is true that Diameter EAP was copied and modified from NASREQ, but I think we should stop doing the same thing for future applications. Otherwise, when either Diameter EAP or NASREQ specification is revised, then the changes will affect specifications of all copied applications. To me this issue is very similar to an obvious issue that can happen when defining a class in C++ programming by copying and modifying other class instead of using class inheritance. > EAP is used for the first A of AAA and the 2 others > AA may need specific things depending on the application and differents > servers may be deployed depending on this application. Is there any pre-requisite that MIP6 bootstrapping needs to be designed as a single authentication/authorization application or can it be realized as two combined apllications (EAP/NASREQ + MIP6)? Regards, Yoshihiro Ohba > > > > > I also agree with Avi that defining a new application for MIP6 > > bootstrapping on top of existing applications (Diameter EAP) without > > defining a new application id but with defining new values for > > existing AVPs or new optional AVPs has some issue, but this option > > might not be as bad as the first option since backward compatibility > > can be easily maintained unlike the first option. However, there is a > > forward compatibility problem (i.e., a Diameter message may be forwarded > > to a AAA server that does not support the new application). Besides > > this problem, it might be worth pursuing this option because it works > > in an optimized way (i.e., bootstrapping AVPs are piggybacked in > > Diameter EAP or NASREQ message) as long as both NAS and AAA server > > support the AVPs. > > I'm not in favor of having an app-id for the nas-aaah part of the mip6 > bootstrapping problem. > > > > > In order to deal with the forward compatibility problem of the second > > option, a third option is to define a new application for MIP6 > > bootstrapping as a totally new authorization application that carries > > new mandatory AVPs specific to that application. This option can be > > run when execution of the second option succeeds in authentication but > > fails in carrying bootstrapping AVPs. > > hmm, i guess i have to think more of this option but this would mandate > now that all EAP Application server should know that maybe they are not > doing this for network access and that maybe they are going to receive > a special authorization request. And in this case, wouldn't it mean > that network access should be treated as a special service and this > would also require a new authorization application ? > > regards, > > Julien > > > > Regards, > > Yoshihiro Ohba > > > > > > > > > > > > On Tue, Sep 05, 2006 at 11:21:22PM -0400, Avi Lior wrote: > > > Hi Kuntal, > > > > > > Neither option 1 or option 2 will work. A new application id just wont > > > scale in the long run. What if another 'capability' were to be added > > > for instance prepaid. Since Diameter messages contain only one > > > Application ID, you would have to create an Application Id that covered > > > both EAP, Prepaid and Mobile IP. And what if a third application were > > > added? The approach is not scalable as the applications are increased > > > -- you would have to cope with all the different permutations of > > > Applications. The same argument goes for ServiceType and PortType and > > > these are actually more problematic. > > > > > > IMO the only thing we can do is to hint at the capability of the NAS. > > > > > > A proper solution should be concieved for this problem. > > > > > > > > > > -----Original Message----- > > > > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > > > Sent: Tuesday, September 05, 2006 2:09 PM > > > > To: Avi Lior; Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > > > Cc: dime@ietf.org > > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > Service-Type > > > > > > > > All, > > > > > > > > Here is a scenario that may need to be covered. In some > > > > cases, local HA assignment is optimal for transport > > > > efficiency perspective. Diameter > > > > MIP4 application allows this. In such a case the ASP == MSP > > > > and the HA is assigned locally (in the visited network). > > > > > > > > To enable this case, in the integrated scenario, the NAS/VAAA > > > > needs to indicate it's capability to assign an HA in the > > > > local network to the HAAA. The HAAA may allow or disallow > > > > this local HA assignment based on policy of the MSA. > > > > > > > > The NAS/VAAA may need to include a hint in the AAA message to > > > > the HAAA at the time of access authentication that it is > > > > capable of providing an HA to the MN. This capability > > > > indication (hint) can be either sent via a new MIP6 specific > > > > AVP or it can be conveyed via an existing AVP (I don't know > > > > if one exists). > > > > > > > > If we decide to include this (local HA assignment), and we > > > > decide to include this mip6 specific hint in the NAS-HAAA > > > > communication, we may have to choose the most appropriate > > > > option (1) vs. (2). > > > > > > > > Comments? > > > > > > > > -Kuntal > > > > > > > > > > > > > -----Original Message----- > > > > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > > > Sent: Tuesday, September 05, 2006 6:07 AM > > > > > To: Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > > > > Cc: dime@ietf.org > > > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > Service-Type > > > > > > > > > > I must be missing something. > > > > > > > > > > In the integrated scenario, what would the NAS put in Service-Type? > > > > > > > > > > I think in the integrated scenario neither Port-Type or > > > > Service-Type > > > > > needs to be touched. > > > > > > > > > > As far as I understand the NAS is either executing EAP > > > > Application or > > > > > NAS REQ. It does not know whether the user will result in having > > > > > subsequent Mobile IP service or not. > > > > > > > > > > The only thing the AAA server can do is to send the MIPv6 attributes > > > > as > > > > > optional (M bit off) and hope that if the NAS does not > > > > understand the > > > > > attributes it would have some logic to bootstrap a different way. > > > > > > > > > > We could improve the situration somewhat. We could have the NAS > > > > > indicate that it supports MIPv6 bootstrapping by including hints in > > > > the > > > > > AR (a capability hint). Where the NAS includes HA-IP address AVP > > > > both > > > > > indicating that it can support bootstrapping and if the > > > > HA-IP address > > > > is > > > > > not ALL-ZEROS or ALL ONES it provides a hint that it can support > > > > dynamic > > > > > HA assignement. > > > > > > > > > > Ofcourse we could introduce the concept of capability hints more > > > > > formally in Diameter -- This is missing today. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > > > > > Sent: Tuesday, September 05, 2006 3:35 AM > > > > > > To: Hannes.Tschofenig@gmx.net > > > > > > Cc: dime@ietf.org > > > > > > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > Service-Type > > > > > > > > > > > > Hi Hannes, > > > > > > > > > > > > I agree with Jouni. I prefer (2) for NAS-AAAH and (1) for > > > > AAAH-HA. > > > > > > In my understanding, there are no mandatory AVPs for NAS-AAAH and > > > > > > therefore I don't see a need of a new application; it's just a > > > > > > MIP-specific information that is piggybacked in the > > > > network access > > > > > > authentication procedure. > > > > > > > > > > > > Concerning AAAH-HA, I think it is a much cleaner approach > > > > to define > > > > > > a new application, since it does not anything to do with network > > > > > > authentication. > > > > > > > > > > > > --Gerardo > > > > > > > > > > > > On 9/5/06, jouni.korhonen@teliasonera.com > > > > > > wrote: > > > > > > > Hi HAnnes, > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > > > > > Sent: 1. syyskuuta 2006 1:07 > > > > > > > > To: dime@ietf.org > > > > > > > > Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > > Service-Type > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > we have had long discussions about the App-ID vs. > > > > > > > > Service-Type usage for > > > > > > > > Diameter MIPv6 Bootstrapping. > > > > > > > > > > > > > > > > It is time to see what the group thinks. Please indicate > > > > > > whether you > > > > > > > > prefer (1) an App-ID or (2) a Service-Type solution for > > > > > > > > > > > > > > > > (a) NAS-to-AAAH communication (as required by the integrated > > > > > > > > scenario; as one part of the solution component) > > > > > > > > > > > > > > I would prefer (2) for now.. or as long as the NAS-2-AAAH main > > > > > > > function is to provide access authentication, where the backend > > > > AAA > > > > > > > may return > > > > > > > MIP6 > > > > > > > bootstrapping info (as an enhancement) based e.g. on the user > > > > > > > subscription profile. If we go for more stuff on > > > > NAS-2-AAAH like > > > > > > > HoA/prefix etc then > > > > > > > (1) > > > > > > > might be better. > > > > > > > > > > > > > > > (b) HA-to-AAAH communication (as used by the split > > > > > > scenario and the > > > > > > > > integrated scenario) > > > > > > > > > > > > > > I would prefer (1) here. The use of EAP for MIP6 bootstrapping > > > > > > > purposes and for 'normal' EAP-based access authentication are > > > > > > > different applications imho. (although in IKEv2 vs 802.1X case > > > > e.g. > > > > > > > NAS-Port-Type could be used to make this distinction.. e.g. > > > > > > how 3GPP > > > > > > > WLAN stuff does it) > > > > > > > > > > > > > > > It might be useful to state a reason for your decision. > > > > > > > > > > > > > > > > Please also indicate whether some aspects are still > > > > > > unclear to you. > > > > > > > > > > > > > > > > Ciao > > > > > > > > Hannes > > > > > > > > > > > > > > Cheers, > > > > > > > Jouni > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > DiME mailing list > > > > > > > > DiME@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > DiME mailing list > > > > > > > DiME@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > DiME mailing list > > > > > > DiME@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > _______________________________________________ > > > > > DiME mailing list > > > > > DiME@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > "This email message and any attachments are confidential > > > > information of Starent Networks, Corp. The information > > > > transmitted may not be used to create or change any > > > > contractual obligations of Starent Networks, Corp. Any > > > > review, retransmission, dissemination or other use of, or > > > > taking of any action in reliance upon this e-mail and its > > > > attachments by persons or entities other than the intended > > > > recipient is prohibited. If you are not the intended > > > > recipient, please notify the sender immediately -- by > > > > replying to this message or by sending an email to > > > > postmaster@starentnetworks.com -- and destroy all copies of > > > > this message and any attachments without reading or > > > > disclosing their contents. Thank you." > > > > > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > -- > julien.bournelle at int-evry.fr > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Sep 08 02:22:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLZkd-0002JX-At; Fri, 08 Sep 2006 02:22:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLZkc-0002JR-De for dime@ietf.org; Fri, 08 Sep 2006 02:22:06 -0400 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLZka-0004RN-H2 for dime@ietf.org; Fri, 08 Sep 2006 02:22:05 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 08:21:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Date: Fri, 8 Sep 2006 08:21:51 +0200 Message-ID: <5D25AEFB114D034FBDC8B156FCA78E0301359B95@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Thread-Index: AcbSXcprxw1ABtZ1Rb62F7311lcUUAAsTZ7w From: To: , X-OriginalArrivalTime: 08 Sep 2006 06:21:53.0254 (UTC) FILETIME=[138BD860:01C6D30F] X-Spam-Score: 0.2 (/) X-Scan-Signature: df1883a27a831c1ea5e8cfe5eb3ad38e Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org =20 > -----Original Message----- > From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]=20 > Sent: 7. syyskuuta 2006 12:15 > To: Avi Lior > Cc: dime@ietf.org > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs.=20 > Service-Type >=20 > On Wed, Sep 06, 2006 at 12:53:57PM -0400, Avi Lior wrote: > > We if we use NASPortType we would have to make it mandatory (it is > > optional to use but must understand) but we will add a new=20 > value, then > > we would need a new Application ID. Same for Service-Type.=20 > Only a new > > NASREQ or EAP AAA server will understand the new value for these > > attributes. So inorder to make sure you land at the=20 > correct server you > > need an Application ID. > >=20 > > So yes we could create a new Application ID. > >=20 > > This is not a very good situation. > >=20 > > For integrated scenario I think we need to introduce an optional > > attribute which is both optional to use and optional to understand. > > Hence we don't need a new Application ID. > >=20 > > If a NAS does support bootstrapping for MIPv6 it includes=20 > the attribute > > in AR (NASREQ or EAP). > >=20 > > If it lands at a Server that understands this attribute,=20 > then it will > > respond correctly if it wants to bootstrap MIPv6. If it lands at a > > Server that doesn't understand the attribute then=20 > bootstrapping via AAA > > will not occur. Note that if the NAI routes to a AAA=20 > server in the home > > network that doesn't recognize the hint then most likely=20 > the operator > > doesn't want to use bootstrapping or the integrated scenario. Right.. agree. /Jouni >=20 > I agree with this approach for the "NAS-AAAH" part of the mip6 > bootstrapping. >=20 > Julien >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20 > > > Sent: Wednesday, September 06, 2006 10:55 AM > > > To: Avi Lior; Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > > Cc: dime@ietf.org > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs.=20 > > > Service-Type > > >=20 > > > Avi, > > >=20 > > > > IMO the only thing we can do is to hint at the capability=20 > > > of the NAS. > > >=20 > > > If we decide to convey NAS capability via an AVP, we may have=20 > > > to make the AVP mandatory, right? If so, can we avoid a=20 > new APP-ID? > > >=20 > > > -Kuntal > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > > Sent: Tuesday, September 05, 2006 10:21 PM > > > > To: Chowdhury, Kuntal; Gerardo Giaretta;=20 > Hannes.Tschofenig@gmx.net > > > > Cc: dime@ietf.org > > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > Service-Type > > > >=20 > > > > Hi Kuntal, > > > >=20 > > > > Neither option 1 or option 2 will work. A new=20 > application id just > > > wont > > > > scale in the long run. What if another 'capability' were=20 > > > to be added=20 > > > > for instance prepaid. Since Diameter messages contain only one=20 > > > > Application ID, you would have to create an Application Id that > > > covered > > > > both EAP, Prepaid and Mobile IP. And what if a third=20 > > > application were=20 > > > > added? The approach is not scalable as the applications=20 > > > are increased > > > > -- you would have to cope with all the different=20 > permutations of=20 > > > > Applications. The same argument goes for ServiceType and=20 > > > PortType and=20 > > > > these are actually more problematic. > > > >=20 > > > > IMO the only thing we can do is to hint at the capability=20 > > > of the NAS. > > > >=20 > > > > A proper solution should be concieved for this problem. > > > >=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Chowdhury, Kuntal=20 > [mailto:kchowdhury@starentnetworks.com] > > > > > Sent: Tuesday, September 05, 2006 2:09 PM > > > > > To: Avi Lior; Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > > > > Cc: dime@ietf.org > > > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > Service-Type > > > > > > > > > > All, > > > > > > > > > > Here is a scenario that may need to be covered. In some=20 > > > cases, local=20 > > > > > HA assignment is optimal for transport efficiency=20 > perspective.=20 > > > > > Diameter > > > > > MIP4 application allows this. In such a case the ASP =3D=3D=20 > > > MSP and the=20 > > > > > HA is assigned locally (in the visited network). > > > > > > > > > > To enable this case, in the integrated scenario, the=20 > > > NAS/VAAA needs=20 > > > > > to indicate it's capability to assign an HA in the local=20 > > > network to=20 > > > > > the HAAA. The HAAA may allow or disallow this local=20 > HA assignment=20 > > > > > based on policy of the MSA. > > > > > > > > > > The NAS/VAAA may need to include a hint in the AAA=20 > message to the=20 > > > > > HAAA at the time of access authentication that it is=20 > capable of=20 > > > > > providing an HA to the MN. This capability indication=20 > > > (hint) can be=20 > > > > > either sent via a new MIP6 specific AVP or it can be=20 > > > conveyed via an=20 > > > > > existing AVP (I don't know if one exists). > > > > > > > > > > If we decide to include this (local HA assignment), and=20 > > > we decide to=20 > > > > > include this mip6 specific hint in the NAS-HAAA=20 > communication, we=20 > > > > > may have to choose the most appropriate option (1) vs. (2). > > > > > > > > > > Comments? > > > > > > > > > > -Kuntal > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > > > > Sent: Tuesday, September 05, 2006 6:07 AM > > > > > > To: Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > > > > > Cc: dime@ietf.org > > > > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > Service-Type > > > > > > > > > > > > I must be missing something. > > > > > > > > > > > > In the integrated scenario, what would the NAS put in > > > Service-Type? > > > > > > > > > > > > I think in the integrated scenario neither Port-Type or > > > > > Service-Type > > > > > > needs to be touched. > > > > > > > > > > > > As far as I understand the NAS is either executing EAP > > > > > Application or > > > > > > NAS REQ. It does not know whether the user will result=20 > > > in having=20 > > > > > > subsequent Mobile IP service or not. > > > > > > > > > > > > The only thing the AAA server can do is to send the MIPv6 > > > attributes > > > > > as > > > > > > optional (M bit off) and hope that if the NAS does not > > > > > understand the > > > > > > attributes it would have some logic to bootstrap a=20 > > > different way. > > > > > > > > > > > > We could improve the situration somewhat. We could=20 > > > have the NAS=20 > > > > > > indicate that it supports MIPv6 bootstrapping by=20 > including hints > > > in > > > > > the > > > > > > AR (a capability hint). Where the NAS includes HA-IP=20 > > > address AVP > > > > > both > > > > > > indicating that it can support bootstrapping and if the > > > > > HA-IP address > > > > > is > > > > > > not ALL-ZEROS or ALL ONES it provides a hint that=20 > it can support > > > > > dynamic > > > > > > HA assignement. > > > > > > > > > > > > Ofcourse we could introduce the concept of capability=20 > > > hints more=20 > > > > > > formally in Diameter -- This is missing today. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > > > > > > Sent: Tuesday, September 05, 2006 3:35 AM > > > > > > > To: Hannes.Tschofenig@gmx.net > > > > > > > Cc: dime@ietf.org > > > > > > > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping:=20 > App-ID vs. > > > > > > > Service-Type > > > > > > > > > > > > > > Hi Hannes, > > > > > > > > > > > > > > I agree with Jouni. I prefer (2) for NAS-AAAH and (1) for > > > > > AAAH-HA. > > > > > > > In my understanding, there are no mandatory AVPs=20 > for NAS-AAAH > > > and > > > > > > > therefore I don't see a need of a new application;=20 > > > it's just a=20 > > > > > > > MIP-specific information that is piggybacked in the > > > > > network access > > > > > > > authentication procedure. > > > > > > > > > > > > > > Concerning AAAH-HA, I think it is a much cleaner approach > > > > > to define > > > > > > > a new application, since it does not anything to do=20 > > > with network=20 > > > > > > > authentication. > > > > > > > > > > > > > > --Gerardo > > > > > > > > > > > > > > On 9/5/06, jouni.korhonen@teliasonera.com=20 > > > > > > > wrote: > > > > > > > > Hi HAnnes, > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Hannes Tschofenig=20 > [mailto:Hannes.Tschofenig@gmx.net] > > > > > > > > > Sent: 1. syyskuuta 2006 1:07 > > > > > > > > > To: dime@ietf.org > > > > > > > > > Subject: [Dime] Diameter MIPv6 Bootstrapping:=20 > App-ID vs. > > > > > > > > > Service-Type > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > we have had long discussions about the App-ID vs. > > > > > > > > > Service-Type usage for > > > > > > > > > Diameter MIPv6 Bootstrapping. > > > > > > > > > > > > > > > > > > It is time to see what the group thinks.=20 > Please indicate > > > > > > > whether you > > > > > > > > > prefer (1) an App-ID or (2) a Service-Type=20 > solution for > > > > > > > > > > > > > > > > > > (a) NAS-to-AAAH communication (as required by the=20 > > > integrated=20 > > > > > > > > > scenario; as one part of the solution component) > > > > > > > > > > > > > > > > I would prefer (2) for now.. or as long as the=20 > > > NAS-2-AAAH main=20 > > > > > > > > function is to provide access authentication, where the > > > backend > > > > > AAA > > > > > > > > may return > > > > > > > > MIP6 > > > > > > > > bootstrapping info (as an enhancement) based e.g.=20 > > > on the user=20 > > > > > > > > subscription profile. If we go for more stuff on > > > > > NAS-2-AAAH like > > > > > > > > HoA/prefix etc then > > > > > > > > (1) > > > > > > > > might be better. > > > > > > > > > > > > > > > > > (b) HA-to-AAAH communication (as used by the split > > > > > > > scenario and the > > > > > > > > > integrated scenario) > > > > > > > > > > > > > > > > I would prefer (1) here. The use of EAP for MIP6=20 > > > bootstrapping=20 > > > > > > > > purposes and for 'normal' EAP-based access=20 > > > authentication are=20 > > > > > > > > different applications imho. (although in IKEv2 vs=20 > > > 802.1X case > > > > > e.g. > > > > > > > > NAS-Port-Type could be used to make this=20 > distinction.. e.g. > > > > > > > how 3GPP > > > > > > > > WLAN stuff does it) > > > > > > > > > > > > > > > > > It might be useful to state a reason for your=20 > decision. > > > > > > > > > > > > > > > > > > Please also indicate whether some aspects are still > > > > > > > unclear to you. > > > > > > > > > > > > > > > > > > Ciao > > > > > > > > > Hannes > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Jouni > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > DiME mailing list > > > > > > > > > DiME@ietf.org > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > DiME mailing list > > > > > > > > DiME@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > DiME mailing list > > > > > > > DiME@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > DiME mailing list > > > > > > DiME@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > "This email message and any attachments are confidential=20 > > > information=20 > > > > > of Starent Networks, Corp. The information=20 > transmitted may not be=20 > > > > > used to create or change any contractual obligations=20 > of Starent=20 > > > > > Networks, Corp. Any review, retransmission,=20 > > > dissemination or other=20 > > > > > use of, or taking of any action in reliance upon this=20 > > > e-mail and its=20 > > > > > attachments by persons or entities other than the=20 > > > intended recipient=20 > > > > > is prohibited. If you are not the intended recipient,=20 > > > please notify=20 > > > > > the sender immediately -- by replying to this message or=20 > > > by sending=20 > > > > > an email to postmaster@starentnetworks.com -- and destroy=20 > > > all copies=20 > > > > > of this message and any attachments without reading=20 > or disclosing=20 > > > > > their contents. Thank you." > > > > > > > >=20 > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime >=20 > --=20 > julien.bournelle at int-evry.fr >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Sep 08 05:51:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLd0c-0005Af-BC; Fri, 08 Sep 2006 05:50:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLd0b-0005AZ-Tf for dime@ietf.org; Fri, 08 Sep 2006 05:50:49 -0400 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLd0a-0007eA-21 for dime@ietf.org; Fri, 08 Sep 2006 05:50:48 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 11:50:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Date: Fri, 8 Sep 2006 11:50:30 +0200 Message-ID: <5D25AEFB114D034FBDC8B156FCA78E0301359BB5@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Thread-Index: AcbSXTs0bBmH28ShQmeO/A1ZlLNcEwAARNjQAAqxjOAAIZuegA== From: To: , , X-OriginalArrivalTime: 08 Sep 2006 09:50:32.0288 (UTC) FILETIME=[3978D600:01C6D32C] X-Spam-Score: 0.2 (/) X-Scan-Signature: 5ba9b8496764663b12c333825fbf6b3d Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Kuntal, I agree more or less ;) Cheers, Jouni > -----Original Message----- > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20 > Sent: 7. syyskuuta 2006 17:31 > To: Avi Lior; Julien Bournelle; Korhonen, Jouni /TeliaSonera=20 > Finland Oyj > Cc: dime@ietf.org > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs.=20 > Service-Type >=20 > All, >=20 > For NAS-HAAA transaction, all we need the NAS to do is to=20 > send a hint to > the HAAA that it can handle mip6 bootstrap attribute(s) if the HAAA > decides to send those in the Diameter EAP/NASREQ response, that's all. >=20 > Now, let's see the options we have to convey this hint: >=20 > 1. APP-id: may be an overkill for a hint, but may be the cleanest > solution. >=20 > 2. NAS-port-type: the new value may need to be overloaded to=20 > convey more > than one hint. >=20 > 3. Capability AVP: the NAS that support mip6bootstrapping can include > this optional AVP in the Diameter EAP/NASREQ messages. >=20 > Option 3, seems to be simple enough to serve the purpose i.e.=20 > convey the > hint, IMHO. Let me know if you think otherwise. >=20 > -Kuntal >=20 >=20 > > -----Original Message----- > > From: Avi Lior [mailto:avi@bridgewatersystems.com]=20 > > Sent: Thursday, September 07, 2006 4:32 AM > > To: Julien Bournelle; jouni.korhonen@teliasonera.com > > Cc: dime@ietf.org > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs.=20 > > Service-Type > >=20 > > At the NAS the NAS should not report NAS-Port-Type =3D MIP=20 > > because it does not support MIP necessarily, it is just=20 > > bootstrapping some DHCP parameters. > >=20 > > Maybe NAS-Port-Type =3D MIPv6DHCPBoot? Yuk. > >=20 > > Here is the Defn of NAS Port type: > >=20 > > The NAS-Port-Type AVP (AVP Code 61) is of type Enumerated and > > contains the type of the port on which the NAS is=20 > > authenticating the > > user. This AVP SHOULD be present if the NAS uses the=20 > same NAS-Port > > number ranges for different service types concurrently. > >=20 > > Forgetting the last sentence. The NAS is not authenticating=20 > > the user for MIP necessarily. It really doesn't know in all=20 > > cases what the user will get in the integrated case. > >=20 > > IMO a fair usage for NAS-Port-Type is for example in WiMAX,=20 > > setting NAS-Port-Type =3D WiMAX. Now the home aaa will know=20 > > that the NAS is authenticating a WiMAX type Port -- which=20 > > could be MIPv4, PMIPv4, MIPv6 etc.... > >=20 > > In the case of WiMAX for example, the HAAA will know that a=20 > > WiMAX NAS can support bootstrapping -- because it may be a=20 > > requirement on the NAS to do so. So that is sufficient. But=20 > > in general we may need something better then that. > >=20 > >=20 > > Secondly the last time I looked you MAY only have one=20 > > instance of NAS-Port-Type. > >=20 > > I think using NAS-Port-Type as a hint in this case is not=20 > > possible and IMO not recommended. > >=20 > > > -----Original Message----- > > > From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > > > Sent: Thursday, September 07, 2006 5:10 AM > > > To: jouni.korhonen@teliasonera.com > > > Cc: Avi Lior; gerardo.giaretta@gmail.com;=20 > > Hannes.Tschofenig@gmx.net;=20 > > > dime@ietf.org > > > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs.=20 > > > Service-Type > > >=20 > > > Hi, > > >=20 > > > On Tue, Sep 05, 2006 at 01:38:45PM +0200,=20 > > > jouni.korhonen@teliasonera.com wrote: > > > > Something MIP6 indicating that is not defined yet. > > > >=20 > > > > > I think in the integrated scenario neither Port-Type or > > > Service-Type > > > > > needs to be touched. > > > > >=20 > > > > > As far as I understand the NAS is either executing EAP > > > Application > > > > > or NAS REQ. It does not know whether the user will > > > result in having > > > > > subsequent Mobile IP service or not. > > > >=20 > > > > Yes. But there was this discussion/idea earlier that it=20 > could be=20 > > > > benefical from the AAA server point of view to have a hint > > > whether the > > > > NAS supports intergrated scenario at all. > > > >=20 > > > > > The only thing the AAA server can do is to send the MIPv6 > > > attributes > > > > > as optional (M bit off) and hope that if the NAS does not > > > understand > > > > > the attributes it would have some logic to bootstrap a=20 > > different=20 > > > > > way. > > > > >=20 > > > > > We could improve the situration somewhat. We could=20 > > have the NAS=20 > > > > > indicate that it supports MIPv6 bootstrapping by > > > including hints in > > > > > the > > > > > AR (a capability hint). Where the NAS includes HA-IP=20 > > > > > address AVP both > > > >=20 > > > > And why can't the Service-Type or NAS-Port-type serve as a > > > hint? e.g. > > > > NAS-Port-Type has been used in some architectures to=20 > distinguish=20 > > > > between .1X or IKEv2 originating EAP requests. > > >=20 > > > I'm thinking that the NAS will certainly add a=20 > > NAS-Port-Type even if=20 > > > it supports mip6 integrated case. So this would mean that=20 > > it will add=20 > > > 2 NAS-Port-Type ? > > > >=20 > > > > Well.. we could also put a bunch of AVPs to the access > > > requests that > > > > would serve as a capability hint. > > >=20 > > > yes. I tend to think that a sort of capability AVP here is=20 > > > interesting and may solve what we want. > > >=20 > > > Julien > > >=20 > > > >=20 > > > > > indicating that it can support bootstrapping and if the HA-IP=20 > > > > > address is not ALL-ZEROS or ALL ONES it provides a hint > > > that it can > > > > > support dynamic HA assignement. > > > > >=20 > > > > > Ofcourse we could introduce the concept of capability=20 > > hints more=20 > > > > > formally in Diameter -- This is missing today. > > > >=20 > > > > Cheers, > > > > Jouni > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > > =20 > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > > > > > Sent: Tuesday, September 05, 2006 3:35 AM > > > > > > To: Hannes.Tschofenig@gmx.net > > > > > > Cc: dime@ietf.org > > > > > > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping:=20 > App-ID vs.=20 > > > > > > Service-Type > > > > > >=20 > > > > > > Hi Hannes, > > > > > >=20 > > > > > > I agree with Jouni. I prefer (2) for NAS-AAAH and (1) > > > for AAAH-HA.=20 > > > > > > In my understanding, there are no mandatory AVPs for > > > NAS-AAAH and > > > > > > therefore I don't see a need of a new application;=20 > > it's just a=20 > > > > > > MIP-specific information that is piggybacked in the > > > network access > > > > > > authentication procedure. > > > > > >=20 > > > > > > Concerning AAAH-HA, I think it is a much cleaner=20 > approach to=20 > > > > > > define a new application, since it does not anything=20 > > to do with=20 > > > > > > network authentication. > > > > > >=20 > > > > > > --Gerardo > > > > > >=20 > > > > > > On 9/5/06, jouni.korhonen@teliasonera.com=20 > > > > > > wrote: > > > > > > > Hi HAnnes, > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Hannes Tschofenig=20 > [mailto:Hannes.Tschofenig@gmx.net] > > > > > > > > Sent: 1. syyskuuta 2006 1:07 > > > > > > > > To: dime@ietf.org > > > > > > > > Subject: [Dime] Diameter MIPv6 Bootstrapping:=20 > App-ID vs.=20 > > > > > > > > Service-Type > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > we have had long discussions about the App-ID vs. > > > > > > > > Service-Type usage for > > > > > > > > Diameter MIPv6 Bootstrapping. > > > > > > > > > > > > > > > > It is time to see what the group thinks. Please indicate > > > > > > whether you > > > > > > > > prefer (1) an App-ID or (2) a Service-Type solution for > > > > > > > > > > > > > > > > (a) NAS-to-AAAH communication (as required by the > > > integrated > > > > > > > > scenario; as one part of the solution component) > > > > > > > > > > > > > > I would prefer (2) for now.. or as long as the > > > NAS-2-AAAH main > > > > > > > function is to provide access authentication, where the > > > > > backend AAA > > > > > > > may return > > > > > > > MIP6 > > > > > > > bootstrapping info (as an enhancement) based e.g.=20 > > on the user=20 > > > > > > > subscription profile. If we go for more stuff on > > > NAS-2-AAAH like > > > > > > > HoA/prefix etc then > > > > > > > (1) > > > > > > > might be better. > > > > > > > > > > > > > > > (b) HA-to-AAAH communication (as used by the split > > > > > > scenario and the > > > > > > > > integrated scenario) > > > > > > > > > > > > > > I would prefer (1) here. The use of EAP for MIP6 > > > bootstrapping > > > > > > > purposes and for 'normal' EAP-based access=20 > > authentication are=20 > > > > > > > different applications imho. (although in IKEv2 vs 802.1X > > > > > case e.g.=20 > > > > > > > NAS-Port-Type could be used to make this=20 > distinction.. e.g.=20 > > > > > > how 3GPP > > > > > > > WLAN stuff does it) > > > > > > > > > > > > > > > It might be useful to state a reason for your decision. > > > > > > > > > > > > > > > > Please also indicate whether some aspects are still > > > > > > unclear to you. > > > > > > > > > > > > > > > > Ciao > > > > > > > > Hannes > > > > > > > > > > > > > > Cheers, > > > > > > > Jouni > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > DiME mailing list > > > > > > > > DiME@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > DiME mailing list > > > > > > > DiME@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > >=20 > > > > > > _______________________________________________ > > > > > > DiME mailing list > > > > > > DiME@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > >=20 > > > > >=20 > > > > > _______________________________________________ > > > > > DiME mailing list > > > > > DiME@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > >=20 > > > -- > > > julien.bournelle at int-evry.fr > > >=20 > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > >=20 >=20 >=20 > "This email message and any attachments are confidential=20 > information of Starent Networks, Corp. The information=20 > transmitted may not be used to create or change any=20 > contractual obligations of Starent Networks, Corp. Any=20 > review, retransmission, dissemination or other use of, or=20 > taking of any action in reliance upon this e-mail and its=20 > attachments by persons or entities other than the intended=20 > recipient is prohibited. If you are not the intended=20 > recipient, please notify the sender immediately -- by=20 > replying to this message or by sending an email to=20 > postmaster@starentnetworks.com -- and destroy all copies of=20 > this message and any attachments without reading or=20 > disclosing their contents. Thank you." >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Sep 08 09:02:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLfzb-0008Lj-QA; Fri, 08 Sep 2006 09:01:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLfza-0008Ld-Uc for dime@ietf.org; Fri, 08 Sep 2006 09:01:58 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLfzZ-0001NH-GY for dime@ietf.org; Fri, 08 Sep 2006 09:01:58 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 5B7BB2FD73; Fri, 8 Sep 2006 15:01:47 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1GLg22-0007Ox-S5; Fri, 08 Sep 2006 15:04:30 +0200 Date: Fri, 8 Sep 2006 15:04:30 +0200 From: Julien Bournelle To: Yoshihiro Ohba Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: case HA-AAAH Message-ID: <20060908130430.GB28411@ipv6-3.int-evry.fr> References: <20060907132813.GA27082@ipv6-3.int-evry.fr> <20060907134240.GB15012@steelhead> <20060907140613.GA27327@ipv6-3.int-evry.fr> <20060907141542.GC15012@steelhead> <20060907151103.GA27450@ipv6-3.int-evry.fr> <20060907195719.GA18410@steelhead> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060907195719.GA18410@steelhead> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi yoshi, On Thu, Sep 07, 2006 at 03:57:19PM -0400, Yoshihiro Ohba wrote: > Hi Julien, > > I was not saying that first A (authentication) should be done in > different way. I didn't assume that. My formulation was probably unclear. > What I am saying that second A (authorization) can be > defined separately from the first A and can be run sequencially (i.e., > an application for second A (e.g., MIP6 bootstrapping) follows another > application for first A (e.g., EAP). ok. I understood this. Let me rephrase the question I asked you in the mail http://www1.ietf.org/mail-archive/web/dime/current/msg00718.html. So what you proposed is to consider that Diameter-EAP is used only for Authentication and to define specific messages to Authorize Mobile IPv6. If i'm correct this brings 3 questions in my mind: 1/ do these messages will have a new Application-Id for mip6 ? 2/ how does the AAA server know that it is using Diameter EAP only for Authentication and not to do full AAA for network access ? 3/ if we do what you proposed, we would have specific messages authorizing mip6 service, but then wouldn't it require specific messages authorizing network access ? regards, Julien > > Yoshihiro Ohba > > On Thu, Sep 07, 2006 at 05:11:03PM +0200, Julien Bournelle wrote: > > Hi yoshi, > > > > On Thu, Sep 07, 2006 at 10:15:42AM -0400, Yoshihiro Ohba wrote: > > > On Thu, Sep 07, 2006 at 04:06:13PM +0200, Julien Bournelle wrote: > > > > > > > > > At least I have a concern on the following text in Section 4.2 of > > > > > draft-ietf-dime-mip6-split-00.txt: > > > > > > > > > > " > > > > > However, the protocol > > > > > description requires that the new application needs to copy the > > > > > Diameter messages from the Diameter EAP application. > > > > > " > > > > > > > > maybe the sentence is a little bit strong. We need to carry the EAP > > > > packets between the HA and the AAAH. > > > > > > Why does a new application with a new application id need to carry EAP > > > packets? Why can't it be defined as a totally separate application > > > that is executed after running EAP application? > > > > because EAP application has been defined for network access > > service whereas EAP is basically only for Authentication. > > > > " > > This document specifies the Diameter EAP application that carries EAP > > packets between a Network Access Server (NAS) working as an EAP > > Authenticator and a back-end authentication server. The Diameter > > EAP application is based on the Diameter Network Access Server > > Application [NASREQ] and is intended for environments similar to > > NASREQ. > > " > > > > So in the EAP Application, EAP is used for the Authentication and the > > AAA server receiving a message with App-ID set to 5 (Diameter-EAP) > > "knows" implicitely that it is doing this for authorizing > > network access. NAS-Port-Type or Service-Type helps him to know if it's > > WiMAX for example. At least, this is my understanding. > > > > In our case, as it has already been said, we need to do AAA for the > > Mobile IPv6 service. The "problem" is that the first "A" of AAA is done > > with EAP so we have a sort of overlapping with Diameter EAP. If the > > authentication was done in a totally different way, I guess we won't > > have this problem of App-Id or not. > -- julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Sep 08 09:23:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLgKI-0000IX-IR; Fri, 08 Sep 2006 09:23:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLgKH-0000F3-OP for dime@ietf.org; Fri, 08 Sep 2006 09:23:21 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLgKF-0008Ox-GR for dime@ietf.org; Fri, 08 Sep 2006 09:23:21 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id k88DLr32004948; Fri, 8 Sep 2006 16:22:51 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 16:21:27 +0300 Received: from [172.21.35.180] ([172.21.35.180]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 8 Sep 2006 16:21:27 +0300 Message-ID: <45016E57.70804@nokia.com> Date: Fri, 08 Sep 2006 16:21:27 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Hannes Tschofenig References: <44E37D07.107@gmx.net> In-Reply-To: <44E37D07.107@gmx.net> Content-Type: text/plain; charset=UTF-8; format=flowed X-OriginalArrivalTime: 08 Sep 2006 13:21:27.0544 (UTC) FILETIME=[B097A780:01C6D349] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mgw-ext11.nokia.com id k88DLr32004948 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: dime@ietf.org Subject: [Dime] Re: Next Steps for draft-garcia-dime-aaa-uri-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I think there hasn't been any discussion on this e-mail, so let me think=20 out loud... - As a minimum, we should take an action with IANA and register what is=20 otherwise defined in RFC 3588. Does anyone disagree that the lack of=20 registration of the AAA URI scheme with IANA is an oversight that we=20 ought to fix? - On doing so, we can rework the schema definition or leave it as is.=20 Since I suspect there might be already deployments which are able to=20 understand AAA URIs as defined in RFC 3588, I would propose not doing=20 any change to the AAA URI scheme, and just do the IANA registration. Proposal #1: Register with IANA the current AAA URI scheme definition as=20 per RFC 3588. - The other thing we should discuss is whether we are happy with this=20 URI scheme or not. In my opinion the current AAA URI scheme does not=20 follow the guidelines for URI Generic Syntax described in RFC 3986, but=20 none has complained so far. So, we don't need to fix something for which=20 there isn't a complain Proposal #2: Do not create a new (potentially 'Diameter') URI scheme (a=20 successor of the AAA URI scheme) until people complain that the current=20 AAA URI scheme has problems. We are not there yet, we are not even sure=20 if someone is using AAA URIs at all. I would like to hear comments about the proposal /Miguel Hannes Tschofenig wrote: > Hi all, >=20 > Miguel discovered a bug in RFC 3588 regarding the definition of the=20 > "aaa" and "aaas" scheme. His presentation at the IETF#66 DIME working=20 > group meeting showed that we have several options. There was no clear=20 > conclusion and we agreed to move the discussion to the list. >=20 > Please find the draft at: > http://tools.ietf.org/wg/dime/draft-garcia-dime-aaa-uri-00.txt >=20 > Slide 5 of http://www3.ietf.org/proceedings/06jul/slides/dime-9/sld1.ht= m=20 > defines possible next steps: >=20 > * We don=E2=80=99t care, so we do nothing > * We fix the IANA the AAA/AAAS URI scheme in a backwards compatible way= ,=20 > and we register with IANA. > * We register with IANA the AAA/AAAS URI scheme (with no changes toward= s=20 > RFC 3588) and work in a definition of a =E2=80=98diameter=E2=80=99 URI = scheme that need=20 > not necessarily be backwards compatible with the AAA URI scheme. > * We register with IANA the AAA/AAAS URI scheme (with no changes toward= s=20 > RFC 3588). >=20 > Please state your opinion. Please let us also know if you have no clue=20 > what the stuff is about. >=20 > Ciao > Hannes & John >=20 --=20 Miguel A. Garcia tel:+358-50-4804586 sip:miguel.garcia@neonsite.net Nokia Research Center Helsinki, Finland _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Sep 08 09:46:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLgge-0001CE-GM; Fri, 08 Sep 2006 09:46:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLggd-0001C9-3z for dime@ietf.org; Fri, 08 Sep 2006 09:46:27 -0400 Received: from imx11.toshiba.co.jp ([61.202.160.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLggW-0007Z1-DA for dime@ietf.org; Fri, 08 Sep 2006 09:46:27 -0400 Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx11.toshiba.co.jp with ESMTP id k88DkA15000621; Fri, 8 Sep 2006 22:46:10 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id k88Dk9X9003632; Fri, 8 Sep 2006 22:46:09 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with ESMTP id YAA03629; Fri, 8 Sep 2006 22:46:09 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id k88Dk99m003401; Fri, 8 Sep 2006 22:46:09 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k88Dk8PF011877; Fri, 8 Sep 2006 22:46:08 +0900 (JST) Received: from steelhead ([172.30.24.105]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J5A005BH0WQX750@mail.po.toshiba.co.jp>; Fri, 08 Sep 2006 22:46:08 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.63) (envelope-from ) id 1GLggE-0006Or-U8; Fri, 08 Sep 2006 06:46:02 -0700 Date: Fri, 08 Sep 2006 09:46:02 -0400 From: Yoshihiro Ohba Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: case HA-AAAH In-reply-to: <20060908130430.GB28411@ipv6-3.int-evry.fr> To: Julien Bournelle Message-id: <20060908134602.GC23183@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <20060907132813.GA27082@ipv6-3.int-evry.fr> <20060907134240.GB15012@steelhead> <20060907140613.GA27327@ipv6-3.int-evry.fr> <20060907141542.GC15012@steelhead> <20060907151103.GA27450@ipv6-3.int-evry.fr> <20060907195719.GA18410@steelhead> <20060908130430.GB28411@ipv6-3.int-evry.fr> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Julien, On Fri, Sep 08, 2006 at 03:04:30PM +0200, Julien Bournelle wrote: > Hi yoshi, > > On Thu, Sep 07, 2006 at 03:57:19PM -0400, Yoshihiro Ohba wrote: > > Hi Julien, > > > > I was not saying that first A (authentication) should be done in > > different way. > > I didn't assume that. My formulation was probably unclear. > > > What I am saying that second A (authorization) can be > > defined separately from the first A and can be run sequencially (i.e., > > an application for second A (e.g., MIP6 bootstrapping) follows another > > application for first A (e.g., EAP). > > ok. I understood this. Let me rephrase the question I asked you in the > mail http://www1.ietf.org/mail-archive/web/dime/current/msg00718.html. > > So what you proposed is to consider that Diameter-EAP is used only for > Authentication and to define specific messages to Authorize Mobile > IPv6. If i'm correct this brings 3 questions in my mind: > > 1/ do these messages will have a new Application-Id for mip6 ? Yes. > > 2/ how does the AAA server know that it is using Diameter EAP only for > Authentication and not to do full AAA for network access ? The AAA server for Diameter EAP is always doing network access authentication/authorization. In the case of split scenario, the AAA server for Diameter EAP would be authorizing the use of IPsec between MN and HA, but the NAS should not respond to MN at this point because from MIPv6 perspective this is not a full authorization. In the case of integrated scenario, the AAA server for Diameter EAP is authorizing the use of the link in the visited network. In both cases, additional MIPv6 specific information will be obtained from the other Diameter application specific to MIPv6. > > 3/ if we do what you proposed, we would have specific messages > authorizing mip6 service, but then wouldn't it require specific > messages authorizing network access ? I may not fully understand this question, but if you are asking whether Diameter EAP application needs to be modified to support MIPv6 bootstrapping, my answer is no. Yoshihiro Ohba > > regards, > > Julien > > > > > Yoshihiro Ohba > > > > On Thu, Sep 07, 2006 at 05:11:03PM +0200, Julien Bournelle wrote: > > > Hi yoshi, > > > > > > On Thu, Sep 07, 2006 at 10:15:42AM -0400, Yoshihiro Ohba wrote: > > > > On Thu, Sep 07, 2006 at 04:06:13PM +0200, Julien Bournelle wrote: > > > > > > > > > > > At least I have a concern on the following text in Section 4.2 of > > > > > > draft-ietf-dime-mip6-split-00.txt: > > > > > > > > > > > > " > > > > > > However, the protocol > > > > > > description requires that the new application needs to copy the > > > > > > Diameter messages from the Diameter EAP application. > > > > > > " > > > > > > > > > > maybe the sentence is a little bit strong. We need to carry the EAP > > > > > packets between the HA and the AAAH. > > > > > > > > Why does a new application with a new application id need to carry EAP > > > > packets? Why can't it be defined as a totally separate application > > > > that is executed after running EAP application? > > > > > > because EAP application has been defined for network access > > > service whereas EAP is basically only for Authentication. > > > > > > " > > > This document specifies the Diameter EAP application that carries EAP > > > packets between a Network Access Server (NAS) working as an EAP > > > Authenticator and a back-end authentication server. The Diameter > > > EAP application is based on the Diameter Network Access Server > > > Application [NASREQ] and is intended for environments similar to > > > NASREQ. > > > " > > > > > > So in the EAP Application, EAP is used for the Authentication and the > > > AAA server receiving a message with App-ID set to 5 (Diameter-EAP) > > > "knows" implicitely that it is doing this for authorizing > > > network access. NAS-Port-Type or Service-Type helps him to know if it's > > > WiMAX for example. At least, this is my understanding. > > > > > > In our case, as it has already been said, we need to do AAA for the > > > Mobile IPv6 service. The "problem" is that the first "A" of AAA is done > > > with EAP so we have a sort of overlapping with Diameter EAP. If the > > > authentication was done in a totally different way, I guess we won't > > > have this problem of App-Id or not. > > > > -- > julien.bournelle at int-evry.fr > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Sep 08 10:10:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLh46-0001QX-9k; Fri, 08 Sep 2006 10:10:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLh45-0001QH-N4 for dime@ietf.org; Fri, 08 Sep 2006 10:10:41 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLh3w-0005ab-1z for dime@ietf.org; Fri, 08 Sep 2006 10:10:41 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id k88EAOf3004961; Fri, 8 Sep 2006 23:10:24 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id k88EAPUF003178; Fri, 8 Sep 2006 23:10:25 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with ESMTP id ZAA03177; Fri, 8 Sep 2006 23:10:25 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id k88EAONQ021883; Fri, 8 Sep 2006 23:10:24 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k88EAN6l019593; Fri, 8 Sep 2006 23:10:23 +0900 (JST) Received: from steelhead ([172.30.24.105]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J5A005JJ216X750@mail.po.toshiba.co.jp>; Fri, 08 Sep 2006 23:10:23 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.63) (envelope-from ) id 1GLh3l-0006UA-IE; Fri, 08 Sep 2006 07:10:21 -0700 Date: Fri, 08 Sep 2006 10:10:21 -0400 From: Yoshihiro Ohba Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type In-reply-to: <44F75D9B.6030808@gmx.net> To: Hannes Tschofenig Message-id: <20060908141021.GD23183@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <44F75D9B.6030808@gmx.net> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I forgot to explicitly answer to this question. My answer is (1) for both (a) and (b), but define MIP6 application as a totally separate authprization application from EAP and NASREQ (For more details and reasons, please see related discussion with Julien). Regards, Yoshihiro Ohba On Fri, Sep 01, 2006 at 12:07:23AM +0200, Hannes Tschofenig wrote: > Hi all, > > we have had long discussions about the App-ID vs. Service-Type usage for > Diameter MIPv6 Bootstrapping. > > It is time to see what the group thinks. Please indicate whether you > prefer (1) an App-ID or (2) a Service-Type solution for > > (a) NAS-to-AAAH communication (as required by the integrated scenario; > as one part of the solution component) > > (b) HA-to-AAAH communication (as used by the split scenario and the > integrated scenario) > > It might be useful to state a reason for your decision. > > Please also indicate whether some aspects are still unclear to you. > > Ciao > Hannes > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Sep 11 11:32:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMnlt-00028Q-8N; Mon, 11 Sep 2006 11:32:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMnlr-00028K-Ts for dime@ietf.org; Mon, 11 Sep 2006 11:32:27 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GMnlq-00071a-Eu for dime@ietf.org; Mon, 11 Sep 2006 11:32:27 -0400 Received: (qmail invoked by alias); 11 Sep 2006 15:32:24 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp032) with SMTP; 11 Sep 2006 17:32:24 +0200 X-Authenticated: #29516787 Message-ID: <4505817A.2000109@gmx.net> Date: Mon, 11 Sep 2006 17:32:10 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Miguel Garcia References: <44E37D07.107@gmx.net> <45016E57.70804@nokia.com> In-Reply-To: <45016E57.70804@nokia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: dime@ietf.org Subject: [Dime] Question about RFC 3588 AAAS Usage X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, Hi Miguel, thanks for your feedback and your assessment. There is one big question to the group: Is someone actually using AAAS? Does someone plan use it? Based on the SIP discussions around SIPS I get the impression that a) AAAS is not really specified sufficiently enough and b) the definition of AAAS might not offer the perceived security benefit (as SIPS does not provide security). If we still like the AAAS concept then we should take a look at draft-audet-sip-sips-guidelines-03.txt since the aspects are extremely similar. In fact, we could just copy-and-paste some parts from the sips-guidelines document and replace the occurrence of SIP with Diameter. I am working on a short text that addresses some aspects that are relevant for our work. I think we need to discuss this issue. Ciao Hannes Miguel Garcia schrieb: > I think there hasn't been any discussion on this e-mail, so let me think > out loud... > > - As a minimum, we should take an action with IANA and register what is > otherwise defined in RFC 3588. Does anyone disagree that the lack of > registration of the AAA URI scheme with IANA is an oversight that we > ought to fix? > > - On doing so, we can rework the schema definition or leave it as is. > Since I suspect there might be already deployments which are able to > understand AAA URIs as defined in RFC 3588, I would propose not doing > any change to the AAA URI scheme, and just do the IANA registration. > > Proposal #1: Register with IANA the current AAA URI scheme definition as > per RFC 3588. > > - The other thing we should discuss is whether we are happy with this > URI scheme or not. In my opinion the current AAA URI scheme does not > follow the guidelines for URI Generic Syntax described in RFC 3986, but > none has complained so far. So, we don't need to fix something for which > there isn't a complain > > Proposal #2: Do not create a new (potentially 'Diameter') URI scheme (a > successor of the AAA URI scheme) until people complain that the current > AAA URI scheme has problems. We are not there yet, we are not even sure > if someone is using AAA URIs at all. > > I would like to hear comments about the proposal > > /Miguel > > Hannes Tschofenig wrote: >> Hi all, >> >> Miguel discovered a bug in RFC 3588 regarding the definition of the >> "aaa" and "aaas" scheme. His presentation at the IETF#66 DIME working >> group meeting showed that we have several options. There was no clear >> conclusion and we agreed to move the discussion to the list. >> >> Please find the draft at: >> http://tools.ietf.org/wg/dime/draft-garcia-dime-aaa-uri-00.txt >> >> Slide 5 of >> http://www3.ietf.org/proceedings/06jul/slides/dime-9/sld1.htm defines >> possible next steps: >> >> * We don’t care, so we do nothing >> * We fix the IANA the AAA/AAAS URI scheme in a backwards compatible >> way, and we register with IANA. >> * We register with IANA the AAA/AAAS URI scheme (with no changes >> towards RFC 3588) and work in a definition of a ‘diameter’ URI scheme >> that need not necessarily be backwards compatible with the AAA URI >> scheme. >> * We register with IANA the AAA/AAAS URI scheme (with no changes >> towards RFC 3588). >> >> Please state your opinion. Please let us also know if you have no clue >> what the stuff is about. >> >> Ciao >> Hannes & John >> > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Sep 11 12:27:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GModF-0001k3-Nm; Mon, 11 Sep 2006 12:27:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GModE-0001jx-RL for dime@ietf.org; Mon, 11 Sep 2006 12:27:36 -0400 Received: from ns1.nitro.ca ([216.209.86.226] helo=mailscanner.nitro.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GModB-0004la-OJ for dime@ietf.org; Mon, 11 Sep 2006 12:27:36 -0400 Received: from bws14.bridgewatersystems.com (bws14.bridgewatersystems.com [216.113.7.14]) by mailscanner.nitro.ca (8.12.11/8.12.11) with ESMTP id k8BGQbB0017957 for ; Mon, 11 Sep 2006 12:26:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Date: Mon, 11 Sep 2006 12:26:46 -0400 Message-ID: In-Reply-To: <5D25AEFB114D034FBDC8B156FCA78E0301359BB5@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Thread-Index: AcbSXTs0bBmH28ShQmeO/A1ZlLNcEwAARNjQAAqxjOAAIZuegACr3RNQ From: "Avi Lior" To: , , X-Nitro-MailScanner-Information: Please contact the ISP for more information X-Nitro-MailScanner: Found to be clean X-Nitro-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.599, required 4, autolearn=not spam, BAYES_00 -2.60) X-MailScanner-From: avi@bridgewatersystems.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 17cf8eab1d6bbd2874a56f9e3554d91d Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I think we may be converging. I like option 3. Option 2 and Option 1 are not appropriate at all.=20 > -----Original Message----- > From: jouni.korhonen@teliasonera.com=20 > [mailto:jouni.korhonen@teliasonera.com]=20 > Sent: Friday, September 08, 2006 5:51 AM > To: kchowdhury@starentnetworks.com; Avi Lior;=20 > julien.bournelle@int-evry.fr > Cc: dime@ietf.org > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs.=20 > Service-Type >=20 > Kuntal, >=20 > I agree more or less ;) >=20 > Cheers, > Jouni >=20 > > -----Original Message----- > > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > Sent: 7. syyskuuta 2006 17:31 > > To: Avi Lior; Julien Bournelle; Korhonen, Jouni=20 > /TeliaSonera Finland=20 > > Oyj > > Cc: dime@ietf.org > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs.=20 > > Service-Type > >=20 > > All, > >=20 > > For NAS-HAAA transaction, all we need the NAS to do is to=20 > send a hint=20 > > to the HAAA that it can handle mip6 bootstrap attribute(s)=20 > if the HAAA=20 > > decides to send those in the Diameter EAP/NASREQ response,=20 > that's all. > >=20 > > Now, let's see the options we have to convey this hint: > >=20 > > 1. APP-id: may be an overkill for a hint, but may be the cleanest=20 > > solution. > >=20 > > 2. NAS-port-type: the new value may need to be overloaded to convey=20 > > more than one hint. > >=20 > > 3. Capability AVP: the NAS that support mip6bootstrapping=20 > can include=20 > > this optional AVP in the Diameter EAP/NASREQ messages. > >=20 > > Option 3, seems to be simple enough to serve the purpose i.e.=20 > > convey the > > hint, IMHO. Let me know if you think otherwise. > >=20 > > -Kuntal > >=20 > >=20 > > > -----Original Message----- > > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > Sent: Thursday, September 07, 2006 4:32 AM > > > To: Julien Bournelle; jouni.korhonen@teliasonera.com > > > Cc: dime@ietf.org > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs.=20 > > > Service-Type > > >=20 > > > At the NAS the NAS should not report NAS-Port-Type =3D MIP=20 > because it=20 > > > does not support MIP necessarily, it is just=20 > bootstrapping some DHCP=20 > > > parameters. > > >=20 > > > Maybe NAS-Port-Type =3D MIPv6DHCPBoot? Yuk. > > >=20 > > > Here is the Defn of NAS Port type: > > >=20 > > > The NAS-Port-Type AVP (AVP Code 61) is of type Enumerated and > > > contains the type of the port on which the NAS is=20 > authenticating=20 > > > the > > > user. This AVP SHOULD be present if the NAS uses the > > same NAS-Port > > > number ranges for different service types concurrently. > > >=20 > > > Forgetting the last sentence. The NAS is not authenticating the=20 > > > user for MIP necessarily. It really doesn't know in all=20 > cases what=20 > > > the user will get in the integrated case. > > >=20 > > > IMO a fair usage for NAS-Port-Type is for example in=20 > WiMAX, setting=20 > > > NAS-Port-Type =3D WiMAX. Now the home aaa will know that=20 > the NAS is=20 > > > authenticating a WiMAX type Port -- which could be MIPv4, PMIPv4,=20 > > > MIPv6 etc.... > > >=20 > > > In the case of WiMAX for example, the HAAA will know that a WiMAX=20 > > > NAS can support bootstrapping -- because it may be a=20 > requirement on=20 > > > the NAS to do so. So that is sufficient. But in general=20 > we may need=20 > > > something better then that. > > >=20 > > >=20 > > > Secondly the last time I looked you MAY only have one instance of=20 > > > NAS-Port-Type. > > >=20 > > > I think using NAS-Port-Type as a hint in this case is not=20 > possible=20 > > > and IMO not recommended. > > >=20 > > > > -----Original Message----- > > > > From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > > > > Sent: Thursday, September 07, 2006 5:10 AM > > > > To: jouni.korhonen@teliasonera.com > > > > Cc: Avi Lior; gerardo.giaretta@gmail.com; > > > Hannes.Tschofenig@gmx.net; > > > > dime@ietf.org > > > > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs.=20 > > > > Service-Type > > > >=20 > > > > Hi, > > > >=20 > > > > On Tue, Sep 05, 2006 at 01:38:45PM +0200,=20 > > > > jouni.korhonen@teliasonera.com wrote: > > > > > Something MIP6 indicating that is not defined yet. > > > > >=20 > > > > > > I think in the integrated scenario neither Port-Type or > > > > Service-Type > > > > > > needs to be touched. > > > > > >=20 > > > > > > As far as I understand the NAS is either executing EAP > > > > Application > > > > > > or NAS REQ. It does not know whether the user will > > > > result in having > > > > > > subsequent Mobile IP service or not. > > > > >=20 > > > > > Yes. But there was this discussion/idea earlier that it > > could be > > > > > benefical from the AAA server point of view to have a hint > > > > whether the > > > > > NAS supports intergrated scenario at all. > > > > >=20 > > > > > > The only thing the AAA server can do is to send the MIPv6 > > > > attributes > > > > > > as optional (M bit off) and hope that if the NAS does not > > > > understand > > > > > > the attributes it would have some logic to bootstrap a > > > different > > > > > > way. > > > > > >=20 > > > > > > We could improve the situration somewhat. We could > > > have the NAS > > > > > > indicate that it supports MIPv6 bootstrapping by > > > > including hints in > > > > > > the > > > > > > AR (a capability hint). Where the NAS includes HA-IP=20 > > > > > > address AVP both > > > > >=20 > > > > > And why can't the Service-Type or NAS-Port-type serve as a > > > > hint? e.g. > > > > > NAS-Port-Type has been used in some architectures to > > distinguish > > > > > between .1X or IKEv2 originating EAP requests. > > > >=20 > > > > I'm thinking that the NAS will certainly add a > > > NAS-Port-Type even if > > > > it supports mip6 integrated case. So this would mean that > > > it will add > > > > 2 NAS-Port-Type ? > > > > >=20 > > > > > Well.. we could also put a bunch of AVPs to the access > > > > requests that > > > > > would serve as a capability hint. > > > >=20 > > > > yes. I tend to think that a sort of capability AVP here is=20 > > > > interesting and may solve what we want. > > > >=20 > > > > Julien > > > >=20 > > > > >=20 > > > > > > indicating that it can support bootstrapping and if=20 > the HA-IP=20 > > > > > > address is not ALL-ZEROS or ALL ONES it provides a hint > > > > that it can > > > > > > support dynamic HA assignement. > > > > > >=20 > > > > > > Ofcourse we could introduce the concept of capability > > > hints more > > > > > > formally in Diameter -- This is missing today. > > > > >=20 > > > > > Cheers, > > > > > Jouni > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > =20 > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > > > > > > Sent: Tuesday, September 05, 2006 3:35 AM > > > > > > > To: Hannes.Tschofenig@gmx.net > > > > > > > Cc: dime@ietf.org > > > > > > > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping:=20 > > App-ID vs.=20 > > > > > > > Service-Type > > > > > > >=20 > > > > > > > Hi Hannes, > > > > > > >=20 > > > > > > > I agree with Jouni. I prefer (2) for NAS-AAAH and (1) > > > > for AAAH-HA.=20 > > > > > > > In my understanding, there are no mandatory AVPs for > > > > NAS-AAAH and > > > > > > > therefore I don't see a need of a new application; > > > it's just a > > > > > > > MIP-specific information that is piggybacked in the > > > > network access > > > > > > > authentication procedure. > > > > > > >=20 > > > > > > > Concerning AAAH-HA, I think it is a much cleaner > > approach to > > > > > > > define a new application, since it does not anything > > > to do with > > > > > > > network authentication. > > > > > > >=20 > > > > > > > --Gerardo > > > > > > >=20 > > > > > > > On 9/5/06, jouni.korhonen@teliasonera.com=20 > > > > > > > wrote: > > > > > > > > Hi HAnnes, > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Hannes Tschofenig > > [mailto:Hannes.Tschofenig@gmx.net] > > > > > > > > > Sent: 1. syyskuuta 2006 1:07 > > > > > > > > > To: dime@ietf.org > > > > > > > > > Subject: [Dime] Diameter MIPv6 Bootstrapping:=20 > > App-ID vs.=20 > > > > > > > > > Service-Type > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > we have had long discussions about the App-ID vs. > > > > > > > > > Service-Type usage for > > > > > > > > > Diameter MIPv6 Bootstrapping. > > > > > > > > > > > > > > > > > > It is time to see what the group thinks.=20 > Please indicate > > > > > > > whether you > > > > > > > > > prefer (1) an App-ID or (2) a Service-Type=20 > solution for > > > > > > > > > > > > > > > > > > (a) NAS-to-AAAH communication (as required by the > > > > integrated > > > > > > > > > scenario; as one part of the solution component) > > > > > > > > > > > > > > > > I would prefer (2) for now.. or as long as the > > > > NAS-2-AAAH main > > > > > > > > function is to provide access authentication, where the > > > > > > backend AAA > > > > > > > > may return > > > > > > > > MIP6 > > > > > > > > bootstrapping info (as an enhancement) based e.g.=20 > > > on the user > > > > > > > > subscription profile. If we go for more stuff on > > > > NAS-2-AAAH like > > > > > > > > HoA/prefix etc then > > > > > > > > (1) > > > > > > > > might be better. > > > > > > > > > > > > > > > > > (b) HA-to-AAAH communication (as used by the split > > > > > > > scenario and the > > > > > > > > > integrated scenario) > > > > > > > > > > > > > > > > I would prefer (1) here. The use of EAP for MIP6 > > > > bootstrapping > > > > > > > > purposes and for 'normal' EAP-based access > > > authentication are > > > > > > > > different applications imho. (although in IKEv2=20 > vs 802.1X > > > > > > case e.g.=20 > > > > > > > > NAS-Port-Type could be used to make this > > distinction.. e.g.=20 > > > > > > > how 3GPP > > > > > > > > WLAN stuff does it) > > > > > > > > > > > > > > > > > It might be useful to state a reason for your=20 > decision. > > > > > > > > > > > > > > > > > > Please also indicate whether some aspects are still > > > > > > > unclear to you. > > > > > > > > > > > > > > > > > > Ciao > > > > > > > > > Hannes > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Jouni > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > DiME mailing list > > > > > > > > > DiME@ietf.org > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > DiME mailing list > > > > > > > > DiME@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > >=20 > > > > > > > _______________________________________________ > > > > > > > DiME mailing list > > > > > > > DiME@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > >=20 > > > > > >=20 > > > > > > _______________________________________________ > > > > > > DiME mailing list > > > > > > DiME@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > >=20 > > > > >=20 > > > > > _______________________________________________ > > > > > DiME mailing list > > > > > DiME@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > >=20 > > > > -- > > > > julien.bournelle at int-evry.fr > > > >=20 > > >=20 > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > >=20 > >=20 > >=20 > > "This email message and any attachments are confidential=20 > information=20 > > of Starent Networks, Corp. The information transmitted may=20 > not be used=20 > > to create or change any contractual obligations of Starent=20 > Networks,=20 > > Corp. Any review, retransmission, dissemination or other=20 > use of, or=20 > > taking of any action in reliance upon this e-mail and its=20 > attachments=20 > > by persons or entities other than the intended recipient is=20 > > prohibited. If you are not the intended recipient, please=20 > notify the=20 > > sender immediately -- by replying to this message or by sending an=20 > > email to postmaster@starentnetworks.com -- and destroy all=20 > copies of=20 > > this message and any attachments without reading or=20 > disclosing their=20 > > contents. Thank you." > >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Sep 11 12:30:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMofx-0003W6-B9; Mon, 11 Sep 2006 12:30:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMofw-0003W1-87 for dime@ietf.org; Mon, 11 Sep 2006 12:30:24 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMofv-0005KR-Ba for dime@ietf.org; Mon, 11 Sep 2006 12:30:24 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id DAB1B2FE14; Mon, 11 Sep 2006 18:30:15 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1GMoiN-0000C6-7n; Mon, 11 Sep 2006 18:32:55 +0200 Date: Mon, 11 Sep 2006 18:32:55 +0200 From: Julien Bournelle To: Avi Lior Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Message-ID: <20060911163255.GA736@ipv6-3.int-evry.fr> References: <5D25AEFB114D034FBDC8B156FCA78E0301359BB5@SEHAN021MB.tcad.telia.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: fca7d4b87f391aa4d413f865ce6efe79 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi kuntal, option 3 also sounds good to me. Julien On Mon, Sep 11, 2006 at 12:26:46PM -0400, Avi Lior wrote: > I think we may be converging. > > I like option 3. Option 2 and Option 1 are not appropriate at all. > > > -----Original Message----- > > From: jouni.korhonen@teliasonera.com > > [mailto:jouni.korhonen@teliasonera.com] > > Sent: Friday, September 08, 2006 5:51 AM > > To: kchowdhury@starentnetworks.com; Avi Lior; > > julien.bournelle@int-evry.fr > > Cc: dime@ietf.org > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > Service-Type > > > > Kuntal, > > > > I agree more or less ;) > > > > Cheers, > > Jouni > > > > > -----Original Message----- > > > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > > Sent: 7. syyskuuta 2006 17:31 > > > To: Avi Lior; Julien Bournelle; Korhonen, Jouni > > /TeliaSonera Finland > > > Oyj > > > Cc: dime@ietf.org > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > Service-Type > > > > > > All, > > > > > > For NAS-HAAA transaction, all we need the NAS to do is to > > send a hint > > > to the HAAA that it can handle mip6 bootstrap attribute(s) > > if the HAAA > > > decides to send those in the Diameter EAP/NASREQ response, > > that's all. > > > > > > Now, let's see the options we have to convey this hint: > > > > > > 1. APP-id: may be an overkill for a hint, but may be the cleanest > > > solution. > > > > > > 2. NAS-port-type: the new value may need to be overloaded to convey > > > more than one hint. > > > > > > 3. Capability AVP: the NAS that support mip6bootstrapping > > can include > > > this optional AVP in the Diameter EAP/NASREQ messages. > > > > > > Option 3, seems to be simple enough to serve the purpose i.e. > > > convey the > > > hint, IMHO. Let me know if you think otherwise. > > > > > > -Kuntal > > > > > > > > > > -----Original Message----- > > > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > > Sent: Thursday, September 07, 2006 4:32 AM > > > > To: Julien Bournelle; jouni.korhonen@teliasonera.com > > > > Cc: dime@ietf.org > > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > Service-Type > > > > > > > > At the NAS the NAS should not report NAS-Port-Type = MIP > > because it > > > > does not support MIP necessarily, it is just > > bootstrapping some DHCP > > > > parameters. > > > > > > > > Maybe NAS-Port-Type = MIPv6DHCPBoot? Yuk. > > > > > > > > Here is the Defn of NAS Port type: > > > > > > > > The NAS-Port-Type AVP (AVP Code 61) is of type Enumerated and > > > > contains the type of the port on which the NAS is > > authenticating > > > > the > > > > user. This AVP SHOULD be present if the NAS uses the > > > same NAS-Port > > > > number ranges for different service types concurrently. > > > > > > > > Forgetting the last sentence. The NAS is not authenticating the > > > > user for MIP necessarily. It really doesn't know in all > > cases what > > > > the user will get in the integrated case. > > > > > > > > IMO a fair usage for NAS-Port-Type is for example in > > WiMAX, setting > > > > NAS-Port-Type = WiMAX. Now the home aaa will know that > > the NAS is > > > > authenticating a WiMAX type Port -- which could be MIPv4, PMIPv4, > > > > MIPv6 etc.... > > > > > > > > In the case of WiMAX for example, the HAAA will know that a WiMAX > > > > NAS can support bootstrapping -- because it may be a > > requirement on > > > > the NAS to do so. So that is sufficient. But in general > > we may need > > > > something better then that. > > > > > > > > > > > > Secondly the last time I looked you MAY only have one instance of > > > > NAS-Port-Type. > > > > > > > > I think using NAS-Port-Type as a hint in this case is not > > possible > > > > and IMO not recommended. > > > > > > > > > -----Original Message----- > > > > > From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > > > > > Sent: Thursday, September 07, 2006 5:10 AM > > > > > To: jouni.korhonen@teliasonera.com > > > > > Cc: Avi Lior; gerardo.giaretta@gmail.com; > > > > Hannes.Tschofenig@gmx.net; > > > > > dime@ietf.org > > > > > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > Service-Type > > > > > > > > > > Hi, > > > > > > > > > > On Tue, Sep 05, 2006 at 01:38:45PM +0200, > > > > > jouni.korhonen@teliasonera.com wrote: > > > > > > Something MIP6 indicating that is not defined yet. > > > > > > > > > > > > > I think in the integrated scenario neither Port-Type or > > > > > Service-Type > > > > > > > needs to be touched. > > > > > > > > > > > > > > As far as I understand the NAS is either executing EAP > > > > > Application > > > > > > > or NAS REQ. It does not know whether the user will > > > > > result in having > > > > > > > subsequent Mobile IP service or not. > > > > > > > > > > > > Yes. But there was this discussion/idea earlier that it > > > could be > > > > > > benefical from the AAA server point of view to have a hint > > > > > whether the > > > > > > NAS supports intergrated scenario at all. > > > > > > > > > > > > > The only thing the AAA server can do is to send the MIPv6 > > > > > attributes > > > > > > > as optional (M bit off) and hope that if the NAS does not > > > > > understand > > > > > > > the attributes it would have some logic to bootstrap a > > > > different > > > > > > > way. > > > > > > > > > > > > > > We could improve the situration somewhat. We could > > > > have the NAS > > > > > > > indicate that it supports MIPv6 bootstrapping by > > > > > including hints in > > > > > > > the > > > > > > > AR (a capability hint). Where the NAS includes HA-IP > > > > > > > address AVP both > > > > > > > > > > > > And why can't the Service-Type or NAS-Port-type serve as a > > > > > hint? e.g. > > > > > > NAS-Port-Type has been used in some architectures to > > > distinguish > > > > > > between .1X or IKEv2 originating EAP requests. > > > > > > > > > > I'm thinking that the NAS will certainly add a > > > > NAS-Port-Type even if > > > > > it supports mip6 integrated case. So this would mean that > > > > it will add > > > > > 2 NAS-Port-Type ? > > > > > > > > > > > > Well.. we could also put a bunch of AVPs to the access > > > > > requests that > > > > > > would serve as a capability hint. > > > > > > > > > > yes. I tend to think that a sort of capability AVP here is > > > > > interesting and may solve what we want. > > > > > > > > > > Julien > > > > > > > > > > > > > > > > > > indicating that it can support bootstrapping and if > > the HA-IP > > > > > > > address is not ALL-ZEROS or ALL ONES it provides a hint > > > > > that it can > > > > > > > support dynamic HA assignement. > > > > > > > > > > > > > > Ofcourse we could introduce the concept of capability > > > > hints more > > > > > > > formally in Diameter -- This is missing today. > > > > > > > > > > > > Cheers, > > > > > > Jouni > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > > > > > > > Sent: Tuesday, September 05, 2006 3:35 AM > > > > > > > > To: Hannes.Tschofenig@gmx.net > > > > > > > > Cc: dime@ietf.org > > > > > > > > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: > > > App-ID vs. > > > > > > > > Service-Type > > > > > > > > > > > > > > > > Hi Hannes, > > > > > > > > > > > > > > > > I agree with Jouni. I prefer (2) for NAS-AAAH and (1) > > > > > for AAAH-HA. > > > > > > > > In my understanding, there are no mandatory AVPs for > > > > > NAS-AAAH and > > > > > > > > therefore I don't see a need of a new application; > > > > it's just a > > > > > > > > MIP-specific information that is piggybacked in the > > > > > network access > > > > > > > > authentication procedure. > > > > > > > > > > > > > > > > Concerning AAAH-HA, I think it is a much cleaner > > > approach to > > > > > > > > define a new application, since it does not anything > > > > to do with > > > > > > > > network authentication. > > > > > > > > > > > > > > > > --Gerardo > > > > > > > > > > > > > > > > On 9/5/06, jouni.korhonen@teliasonera.com > > > > > > > > wrote: > > > > > > > > > Hi HAnnes, > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Hannes Tschofenig > > > [mailto:Hannes.Tschofenig@gmx.net] > > > > > > > > > > Sent: 1. syyskuuta 2006 1:07 > > > > > > > > > > To: dime@ietf.org > > > > > > > > > > Subject: [Dime] Diameter MIPv6 Bootstrapping: > > > App-ID vs. > > > > > > > > > > Service-Type > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > we have had long discussions about the App-ID vs. > > > > > > > > > > Service-Type usage for > > > > > > > > > > Diameter MIPv6 Bootstrapping. > > > > > > > > > > > > > > > > > > > > It is time to see what the group thinks. > > Please indicate > > > > > > > > whether you > > > > > > > > > > prefer (1) an App-ID or (2) a Service-Type > > solution for > > > > > > > > > > > > > > > > > > > > (a) NAS-to-AAAH communication (as required by the > > > > > integrated > > > > > > > > > > scenario; as one part of the solution component) > > > > > > > > > > > > > > > > > > I would prefer (2) for now.. or as long as the > > > > > NAS-2-AAAH main > > > > > > > > > function is to provide access authentication, where the > > > > > > > backend AAA > > > > > > > > > may return > > > > > > > > > MIP6 > > > > > > > > > bootstrapping info (as an enhancement) based e.g. > > > > on the user > > > > > > > > > subscription profile. If we go for more stuff on > > > > > NAS-2-AAAH like > > > > > > > > > HoA/prefix etc then > > > > > > > > > (1) > > > > > > > > > might be better. > > > > > > > > > > > > > > > > > > > (b) HA-to-AAAH communication (as used by the split > > > > > > > > scenario and the > > > > > > > > > > integrated scenario) > > > > > > > > > > > > > > > > > > I would prefer (1) here. The use of EAP for MIP6 > > > > > bootstrapping > > > > > > > > > purposes and for 'normal' EAP-based access > > > > authentication are > > > > > > > > > different applications imho. (although in IKEv2 > > vs 802.1X > > > > > > > case e.g. > > > > > > > > > NAS-Port-Type could be used to make this > > > distinction.. e.g. > > > > > > > > how 3GPP > > > > > > > > > WLAN stuff does it) > > > > > > > > > > > > > > > > > > > It might be useful to state a reason for your > > decision. > > > > > > > > > > > > > > > > > > > > Please also indicate whether some aspects are still > > > > > > > > unclear to you. > > > > > > > > > > > > > > > > > > > > Ciao > > > > > > > > > > Hannes > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > Jouni > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > DiME mailing list > > > > > > > > > > DiME@ietf.org > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > DiME mailing list > > > > > > > > > DiME@ietf.org > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > DiME mailing list > > > > > > > > DiME@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > DiME mailing list > > > > > > > DiME@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > DiME mailing list > > > > > > DiME@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > -- > > > > > julien.bournelle at int-evry.fr > > > > > > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > "This email message and any attachments are confidential > > information > > > of Starent Networks, Corp. The information transmitted may > > not be used > > > to create or change any contractual obligations of Starent > > Networks, > > > Corp. Any review, retransmission, dissemination or other > > use of, or > > > taking of any action in reliance upon this e-mail and its > > attachments > > > by persons or entities other than the intended recipient is > > > prohibited. If you are not the intended recipient, please > > notify the > > > sender immediately -- by replying to this message or by sending an > > > email to postmaster@starentnetworks.com -- and destroy all > > copies of > > > this message and any attachments without reading or > > disclosing their > > > contents. Thank you." > > > > > -- julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 12 08:11:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN76y-0000po-RY; Tue, 12 Sep 2006 08:11:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN76x-0000pb-F8 for dime@ietf.org; Tue, 12 Sep 2006 08:11:31 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GN76v-00036i-TO for dime@ietf.org; Tue, 12 Sep 2006 08:11:31 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id B4E6B2FDCC; Tue, 12 Sep 2006 14:11:22 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1GN79M-0000fH-W5; Tue, 12 Sep 2006 14:14:01 +0200 Date: Tue, 12 Sep 2006 14:14:00 +0200 From: Julien Bournelle To: Yoshihiro Ohba Message-ID: <20060912121400.GA2527@ipv6-3.int-evry.fr> References: <7CCD07160348804497EF29E9EA5560D78372F8@exchtewks2.starentnetworks.com> <20060906181643.GE5241@steelhead> <20060907152211.GA27475@ipv6-3.int-evry.fr> <20060907203328.GB18410@steelhead> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060907203328.GB18410@steelhead> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: fca741f5016e6ff607eaed2fd431d10d Cc: dime@ietf.org Subject: [Dime] Using Diameter EAP --only-- for Authentication ? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi yoshi, as a reminder for everybody, we are talking of the HA-AAAH interface. On Thu, Sep 07, 2006 at 04:33:28PM -0400, Yoshihiro Ohba wrote: > > Why you don't think this is not an issue? It is true that Diameter > EAP was copied and modified from NASREQ, but I think we should stop > doing the same thing for future applications. Otherwise, when either > Diameter EAP or NASREQ specification is revised, then the changes will > affect specifications of all copied applications. well i don't think it's an issue because I think that even if an application wants to use EAP for Authentication purpose, an update of the RFC 4072 won't necessary imply an update of this new application. As you know, RFC4072 also do Authorization for network access and also defines accouting for the network access. Some of the AVPs defined in Diameter EAP are not necessary for mip6. > To me this issue is > very similar to an obvious issue that can happen when defining a class > in C++ programming by copying and modifying other class instead of > using class inheritance. > > > EAP is used for the first A of AAA and the 2 others > > AA may need specific things depending on the application and differents > > servers may be deployed depending on this application. > > Is there any pre-requisite that MIP6 bootstrapping needs to be > designed as a single authentication/authorization application or can > it be realized as two combined apllications (EAP/NASREQ + MIP6)? I think before answering to this question, we should ask wether it makes sense to use RFC4072 -- only -- for Authentication. How do a AAA server would know that this particular DER request is --only-- for authentication and that it has to wait for a particular Authorization message (with another app-id) for a service. If we "push" a little what you propose, we could define an "Authentication based on EAP" Application (only doing Authentication) used by other Application that would only define their messages for Authorization and Accounting (such as MIP6). That's why I talked to you in a previous mail about also consider network access as a special service and thus define Authz/Accounting messages for the "network access" service. regards, Julien > > Regards, > Yoshihiro Ohba > > > > > > > > > I also agree with Avi that defining a new application for MIP6 > > > bootstrapping on top of existing applications (Diameter EAP) without > > > defining a new application id but with defining new values for > > > existing AVPs or new optional AVPs has some issue, but this option > > > might not be as bad as the first option since backward compatibility > > > can be easily maintained unlike the first option. However, there is a > > > forward compatibility problem (i.e., a Diameter message may be forwarded > > > to a AAA server that does not support the new application). Besides > > > this problem, it might be worth pursuing this option because it works > > > in an optimized way (i.e., bootstrapping AVPs are piggybacked in > > > Diameter EAP or NASREQ message) as long as both NAS and AAA server > > > support the AVPs. > > > > I'm not in favor of having an app-id for the nas-aaah part of the mip6 > > bootstrapping problem. > > > > > > > > In order to deal with the forward compatibility problem of the second > > > option, a third option is to define a new application for MIP6 > > > bootstrapping as a totally new authorization application that carries > > > new mandatory AVPs specific to that application. This option can be > > > run when execution of the second option succeeds in authentication but > > > fails in carrying bootstrapping AVPs. > > > > hmm, i guess i have to think more of this option but this would mandate > > now that all EAP Application server should know that maybe they are not > > doing this for network access and that maybe they are going to receive > > a special authorization request. And in this case, wouldn't it mean > > that network access should be treated as a special service and this > > would also require a new authorization application ? > > > > regards, > > > > Julien > > > > > > Regards, > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > On Tue, Sep 05, 2006 at 11:21:22PM -0400, Avi Lior wrote: > > > > Hi Kuntal, > > > > > > > > Neither option 1 or option 2 will work. A new application id just wont > > > > scale in the long run. What if another 'capability' were to be added > > > > for instance prepaid. Since Diameter messages contain only one > > > > Application ID, you would have to create an Application Id that covered > > > > both EAP, Prepaid and Mobile IP. And what if a third application were > > > > added? The approach is not scalable as the applications are increased > > > > -- you would have to cope with all the different permutations of > > > > Applications. The same argument goes for ServiceType and PortType and > > > > these are actually more problematic. > > > > > > > > IMO the only thing we can do is to hint at the capability of the NAS. > > > > > > > > A proper solution should be concieved for this problem. > > > > > > > > > > > > > -----Original Message----- > > > > > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > > > > Sent: Tuesday, September 05, 2006 2:09 PM > > > > > To: Avi Lior; Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > > > > Cc: dime@ietf.org > > > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > Service-Type > > > > > > > > > > All, > > > > > > > > > > Here is a scenario that may need to be covered. In some > > > > > cases, local HA assignment is optimal for transport > > > > > efficiency perspective. Diameter > > > > > MIP4 application allows this. In such a case the ASP == MSP > > > > > and the HA is assigned locally (in the visited network). > > > > > > > > > > To enable this case, in the integrated scenario, the NAS/VAAA > > > > > needs to indicate it's capability to assign an HA in the > > > > > local network to the HAAA. The HAAA may allow or disallow > > > > > this local HA assignment based on policy of the MSA. > > > > > > > > > > The NAS/VAAA may need to include a hint in the AAA message to > > > > > the HAAA at the time of access authentication that it is > > > > > capable of providing an HA to the MN. This capability > > > > > indication (hint) can be either sent via a new MIP6 specific > > > > > AVP or it can be conveyed via an existing AVP (I don't know > > > > > if one exists). > > > > > > > > > > If we decide to include this (local HA assignment), and we > > > > > decide to include this mip6 specific hint in the NAS-HAAA > > > > > communication, we may have to choose the most appropriate > > > > > option (1) vs. (2). > > > > > > > > > > Comments? > > > > > > > > > > -Kuntal > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > > > > Sent: Tuesday, September 05, 2006 6:07 AM > > > > > > To: Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > > > > > Cc: dime@ietf.org > > > > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > Service-Type > > > > > > > > > > > > I must be missing something. > > > > > > > > > > > > In the integrated scenario, what would the NAS put in Service-Type? > > > > > > > > > > > > I think in the integrated scenario neither Port-Type or > > > > > Service-Type > > > > > > needs to be touched. > > > > > > > > > > > > As far as I understand the NAS is either executing EAP > > > > > Application or > > > > > > NAS REQ. It does not know whether the user will result in having > > > > > > subsequent Mobile IP service or not. > > > > > > > > > > > > The only thing the AAA server can do is to send the MIPv6 attributes > > > > > as > > > > > > optional (M bit off) and hope that if the NAS does not > > > > > understand the > > > > > > attributes it would have some logic to bootstrap a different way. > > > > > > > > > > > > We could improve the situration somewhat. We could have the NAS > > > > > > indicate that it supports MIPv6 bootstrapping by including hints in > > > > > the > > > > > > AR (a capability hint). Where the NAS includes HA-IP address AVP > > > > > both > > > > > > indicating that it can support bootstrapping and if the > > > > > HA-IP address > > > > > is > > > > > > not ALL-ZEROS or ALL ONES it provides a hint that it can support > > > > > dynamic > > > > > > HA assignement. > > > > > > > > > > > > Ofcourse we could introduce the concept of capability hints more > > > > > > formally in Diameter -- This is missing today. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > > > > > > Sent: Tuesday, September 05, 2006 3:35 AM > > > > > > > To: Hannes.Tschofenig@gmx.net > > > > > > > Cc: dime@ietf.org > > > > > > > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > Service-Type > > > > > > > > > > > > > > Hi Hannes, > > > > > > > > > > > > > > I agree with Jouni. I prefer (2) for NAS-AAAH and (1) for > > > > > AAAH-HA. > > > > > > > In my understanding, there are no mandatory AVPs for NAS-AAAH and > > > > > > > therefore I don't see a need of a new application; it's just a > > > > > > > MIP-specific information that is piggybacked in the > > > > > network access > > > > > > > authentication procedure. > > > > > > > > > > > > > > Concerning AAAH-HA, I think it is a much cleaner approach > > > > > to define > > > > > > > a new application, since it does not anything to do with network > > > > > > > authentication. > > > > > > > > > > > > > > --Gerardo > > > > > > > > > > > > > > On 9/5/06, jouni.korhonen@teliasonera.com > > > > > > > wrote: > > > > > > > > Hi HAnnes, > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > > > > > > Sent: 1. syyskuuta 2006 1:07 > > > > > > > > > To: dime@ietf.org > > > > > > > > > Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > > > Service-Type > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > we have had long discussions about the App-ID vs. > > > > > > > > > Service-Type usage for > > > > > > > > > Diameter MIPv6 Bootstrapping. > > > > > > > > > > > > > > > > > > It is time to see what the group thinks. Please indicate > > > > > > > whether you > > > > > > > > > prefer (1) an App-ID or (2) a Service-Type solution for > > > > > > > > > > > > > > > > > > (a) NAS-to-AAAH communication (as required by the integrated > > > > > > > > > scenario; as one part of the solution component) > > > > > > > > > > > > > > > > I would prefer (2) for now.. or as long as the NAS-2-AAAH main > > > > > > > > function is to provide access authentication, where the backend > > > > > AAA > > > > > > > > may return > > > > > > > > MIP6 > > > > > > > > bootstrapping info (as an enhancement) based e.g. on the user > > > > > > > > subscription profile. If we go for more stuff on > > > > > NAS-2-AAAH like > > > > > > > > HoA/prefix etc then > > > > > > > > (1) > > > > > > > > might be better. > > > > > > > > > > > > > > > > > (b) HA-to-AAAH communication (as used by the split > > > > > > > scenario and the > > > > > > > > > integrated scenario) > > > > > > > > > > > > > > > > I would prefer (1) here. The use of EAP for MIP6 bootstrapping > > > > > > > > purposes and for 'normal' EAP-based access authentication are > > > > > > > > different applications imho. (although in IKEv2 vs 802.1X case > > > > > e.g. > > > > > > > > NAS-Port-Type could be used to make this distinction.. e.g. > > > > > > > how 3GPP > > > > > > > > WLAN stuff does it) > > > > > > > > > > > > > > > > > It might be useful to state a reason for your decision. > > > > > > > > > > > > > > > > > > Please also indicate whether some aspects are still > > > > > > > unclear to you. > > > > > > > > > > > > > > > > > > Ciao > > > > > > > > > Hannes > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Jouni > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > DiME mailing list > > > > > > > > > DiME@ietf.org > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > DiME mailing list > > > > > > > > DiME@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > DiME mailing list > > > > > > > DiME@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > DiME mailing list > > > > > > DiME@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > "This email message and any attachments are confidential > > > > > information of Starent Networks, Corp. The information > > > > > transmitted may not be used to create or change any > > > > > contractual obligations of Starent Networks, Corp. Any > > > > > review, retransmission, dissemination or other use of, or > > > > > taking of any action in reliance upon this e-mail and its > > > > > attachments by persons or entities other than the intended > > > > > recipient is prohibited. If you are not the intended > > > > > recipient, please notify the sender immediately -- by > > > > > replying to this message or by sending an email to > > > > > postmaster@starentnetworks.com -- and destroy all copies of > > > > > this message and any attachments without reading or > > > > > disclosing their contents. Thank you." > > > > > > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > -- > > julien.bournelle at int-evry.fr > > -- julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 12 11:08:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN9sX-0001jo-2K; Tue, 12 Sep 2006 11:08:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN9sV-0001iL-51 for dime@ietf.org; Tue, 12 Sep 2006 11:08:47 -0400 Received: from [203.199.83.126] (helo=rediffmail.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GN9sP-0005oI-4V for dime@ietf.org; Tue, 12 Sep 2006 11:08:47 -0400 Received: (qmail 18386 invoked by uid 510); 12 Sep 2006 10:50:20 -0000 Date: 12 Sep 2006 10:50:20 -0000 Message-ID: <20060912105020.18385.qmail@webmail66.rediffmail.com> Received: from unknown (202.131.155.13) by rediffmail.com via HTTP; 12 sep 2006 10:50:13 -0000 MIME-Version: 1.0 From: "Valesh Chandu" To: dime@ietf.org X-Spam-Score: 1.5 (+) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [Dime] Framed-ipv6-prefix data format X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Valesh Chandu List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1223900391==" Errors-To: dime-bounces@ietf.org This is a multipart mime message --===============1223900391== Content-type: multipart/alternative; boundary="Next_1158058213---0-203.199.83.126-18207" This is a multipart mime message --Next_1158058213---0-203.199.83.126-18207 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =A0=0AHi all,=0A=0AI have a small doubt regarding the Framed-ipv6-prefix A= vp data field, this AVP is a Radius(RFC-3162) Avp that contains prefix leng= th and the actual prefix in binary format, in Diameter (RFC 4005) it is def= ined as a Octet String, but not explicitly mentioned about the data filed o= f the Avp i.e whether the data field contains both the prefix length and ip= v6 prefix or only the ipv6 prefix etc.=0A=0Ai think the data field of this = Avp in Diameter should contain both the prefix length & actual prefix as in= Radius but there is no evidence to confirm this.=0A=0ASo please any one co= uld tell some standard document that is making clear this issue. Just I wan= t this for standard compliance and to avoid interoperability issues.=0A=0A= =0AThanks in advance.=0A=0ABest Regards,=0AChandu --Next_1158058213---0-203.199.83.126-18207 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0A 
=0AHi all,
=0A
=0AI have a small doubt regarding the= Framed-ipv6-prefix Avp data field, this AVP is a Radius(RFC-3162) Avp that= contains prefix length and the actual prefix in binary format, in Diameter= (RFC 4005) it is defined as a Octet String, but not explicitly mentioned a= bout the data filed of the Avp i.e whether the data field contains both the= prefix length and ipv6 prefix or only the ipv6 prefix etc.
=0A
=0Ai = think the data field of this Avp in Diameter should contain both the prefix= length & actual prefix as in Radius but there is no evidence to confir= m this.
=0A
=0ASo please any one could tell some standard document th= at is making clear this issue. Just I want this for standard compliance and= to avoid interoperability issues.
=0A
=0A
=0AThanks in advance.=0A
=0ABest Regards,
=0AChandu=0A

=0A

=0A=0A --Next_1158058213---0-203.199.83.126-18207-- --===============1223900391== 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://www1.ietf.org/mailman/listinfo/dime --===============1223900391==-- From dime-bounces@ietf.org Tue Sep 12 11:17:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNA0a-00055X-9f; Tue, 12 Sep 2006 11:17:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNA0Z-00055S-EI for dime@ietf.org; Tue, 12 Sep 2006 11:17:07 -0400 Received: from imx11.toshiba.co.jp ([61.202.160.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNA0U-0007Nv-J2 for dime@ietf.org; Tue, 12 Sep 2006 11:17:07 -0400 Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx11.toshiba.co.jp with ESMTP id k8CFGfwH001493; Wed, 13 Sep 2006 00:16:41 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id k8CFGfec014192; Wed, 13 Sep 2006 00:16:41 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with ESMTP id AAA14191; Wed, 13 Sep 2006 00:16:41 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id k8CFGeHd015187; Wed, 13 Sep 2006 00:16:40 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k8CFGedD015994; Wed, 13 Sep 2006 00:16:40 +0900 (JST) Received: from steelhead ([172.30.24.105]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J5H004WUJRLC1B0@mail.po.toshiba.co.jp>; Wed, 13 Sep 2006 00:16:40 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.63) (envelope-from ) id 1GNA02-0001AT-VV; Tue, 12 Sep 2006 08:16:34 -0700 Date: Tue, 12 Sep 2006 11:16:34 -0400 From: Yoshihiro Ohba Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type In-reply-to: <7CCD07160348804497EF29E9EA5560D7837317@exchtewks2.starentnetworks.com> To: "Chowdhury, Kuntal" Message-id: <20060912151634.GE2857@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <7CCD07160348804497EF29E9EA5560D7837317@exchtewks2.starentnetworks.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Kuntal, In option 3, what does "optinal AVP" means? Does it mean that 'M' bit of the AVP is unset, or 'M' bit of the AVP is set but the AVP is defined to appear in optional part in ABNF? Yoshihiro Ohba On Thu, Sep 07, 2006 at 10:31:20AM -0400, Chowdhury, Kuntal wrote: > All, > > For NAS-HAAA transaction, all we need the NAS to do is to send a hint to > the HAAA that it can handle mip6 bootstrap attribute(s) if the HAAA > decides to send those in the Diameter EAP/NASREQ response, that's all. > > Now, let's see the options we have to convey this hint: > > 1. APP-id: may be an overkill for a hint, but may be the cleanest > solution. > > 2. NAS-port-type: the new value may need to be overloaded to convey more > than one hint. > > 3. Capability AVP: the NAS that support mip6bootstrapping can include > this optional AVP in the Diameter EAP/NASREQ messages. > > Option 3, seems to be simple enough to serve the purpose i.e. convey the > hint, IMHO. Let me know if you think otherwise. > > -Kuntal > > > > -----Original Message----- > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > Sent: Thursday, September 07, 2006 4:32 AM > > To: Julien Bournelle; jouni.korhonen@teliasonera.com > > Cc: dime@ietf.org > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > Service-Type > > > > At the NAS the NAS should not report NAS-Port-Type = MIP > > because it does not support MIP necessarily, it is just > > bootstrapping some DHCP parameters. > > > > Maybe NAS-Port-Type = MIPv6DHCPBoot? Yuk. > > > > Here is the Defn of NAS Port type: > > > > The NAS-Port-Type AVP (AVP Code 61) is of type Enumerated and > > contains the type of the port on which the NAS is > > authenticating the > > user. This AVP SHOULD be present if the NAS uses the same NAS-Port > > number ranges for different service types concurrently. > > > > Forgetting the last sentence. The NAS is not authenticating > > the user for MIP necessarily. It really doesn't know in all > > cases what the user will get in the integrated case. > > > > IMO a fair usage for NAS-Port-Type is for example in WiMAX, > > setting NAS-Port-Type = WiMAX. Now the home aaa will know > > that the NAS is authenticating a WiMAX type Port -- which > > could be MIPv4, PMIPv4, MIPv6 etc.... > > > > In the case of WiMAX for example, the HAAA will know that a > > WiMAX NAS can support bootstrapping -- because it may be a > > requirement on the NAS to do so. So that is sufficient. But > > in general we may need something better then that. > > > > > > Secondly the last time I looked you MAY only have one > > instance of NAS-Port-Type. > > > > I think using NAS-Port-Type as a hint in this case is not > > possible and IMO not recommended. > > > > > -----Original Message----- > > > From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > > > Sent: Thursday, September 07, 2006 5:10 AM > > > To: jouni.korhonen@teliasonera.com > > > Cc: Avi Lior; gerardo.giaretta@gmail.com; > > Hannes.Tschofenig@gmx.net; > > > dime@ietf.org > > > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > Service-Type > > > > > > Hi, > > > > > > On Tue, Sep 05, 2006 at 01:38:45PM +0200, > > > jouni.korhonen@teliasonera.com wrote: > > > > Something MIP6 indicating that is not defined yet. > > > > > > > > > I think in the integrated scenario neither Port-Type or > > > Service-Type > > > > > needs to be touched. > > > > > > > > > > As far as I understand the NAS is either executing EAP > > > Application > > > > > or NAS REQ. It does not know whether the user will > > > result in having > > > > > subsequent Mobile IP service or not. > > > > > > > > Yes. But there was this discussion/idea earlier that it could be > > > > benefical from the AAA server point of view to have a hint > > > whether the > > > > NAS supports intergrated scenario at all. > > > > > > > > > The only thing the AAA server can do is to send the MIPv6 > > > attributes > > > > > as optional (M bit off) and hope that if the NAS does not > > > understand > > > > > the attributes it would have some logic to bootstrap a > > different > > > > > way. > > > > > > > > > > We could improve the situration somewhat. We could > > have the NAS > > > > > indicate that it supports MIPv6 bootstrapping by > > > including hints in > > > > > the > > > > > AR (a capability hint). Where the NAS includes HA-IP > > > > > address AVP both > > > > > > > > And why can't the Service-Type or NAS-Port-type serve as a > > > hint? e.g. > > > > NAS-Port-Type has been used in some architectures to distinguish > > > > between .1X or IKEv2 originating EAP requests. > > > > > > I'm thinking that the NAS will certainly add a > > NAS-Port-Type even if > > > it supports mip6 integrated case. So this would mean that > > it will add > > > 2 NAS-Port-Type ? > > > > > > > > Well.. we could also put a bunch of AVPs to the access > > > requests that > > > > would serve as a capability hint. > > > > > > yes. I tend to think that a sort of capability AVP here is > > > interesting and may solve what we want. > > > > > > Julien > > > > > > > > > > > > indicating that it can support bootstrapping and if the HA-IP > > > > > address is not ALL-ZEROS or ALL ONES it provides a hint > > > that it can > > > > > support dynamic HA assignement. > > > > > > > > > > Ofcourse we could introduce the concept of capability > > hints more > > > > > formally in Diameter -- This is missing today. > > > > > > > > Cheers, > > > > Jouni > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > > > > > Sent: Tuesday, September 05, 2006 3:35 AM > > > > > > To: Hannes.Tschofenig@gmx.net > > > > > > Cc: dime@ietf.org > > > > > > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > Service-Type > > > > > > > > > > > > Hi Hannes, > > > > > > > > > > > > I agree with Jouni. I prefer (2) for NAS-AAAH and (1) > > > for AAAH-HA. > > > > > > In my understanding, there are no mandatory AVPs for > > > NAS-AAAH and > > > > > > therefore I don't see a need of a new application; > > it's just a > > > > > > MIP-specific information that is piggybacked in the > > > network access > > > > > > authentication procedure. > > > > > > > > > > > > Concerning AAAH-HA, I think it is a much cleaner approach to > > > > > > define a new application, since it does not anything > > to do with > > > > > > network authentication. > > > > > > > > > > > > --Gerardo > > > > > > > > > > > > On 9/5/06, jouni.korhonen@teliasonera.com > > > > > > wrote: > > > > > > > Hi HAnnes, > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > > > > > Sent: 1. syyskuuta 2006 1:07 > > > > > > > > To: dime@ietf.org > > > > > > > > Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > > Service-Type > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > we have had long discussions about the App-ID vs. > > > > > > > > Service-Type usage for > > > > > > > > Diameter MIPv6 Bootstrapping. > > > > > > > > > > > > > > > > It is time to see what the group thinks. Please indicate > > > > > > whether you > > > > > > > > prefer (1) an App-ID or (2) a Service-Type solution for > > > > > > > > > > > > > > > > (a) NAS-to-AAAH communication (as required by the > > > integrated > > > > > > > > scenario; as one part of the solution component) > > > > > > > > > > > > > > I would prefer (2) for now.. or as long as the > > > NAS-2-AAAH main > > > > > > > function is to provide access authentication, where the > > > > > backend AAA > > > > > > > may return > > > > > > > MIP6 > > > > > > > bootstrapping info (as an enhancement) based e.g. > > on the user > > > > > > > subscription profile. If we go for more stuff on > > > NAS-2-AAAH like > > > > > > > HoA/prefix etc then > > > > > > > (1) > > > > > > > might be better. > > > > > > > > > > > > > > > (b) HA-to-AAAH communication (as used by the split > > > > > > scenario and the > > > > > > > > integrated scenario) > > > > > > > > > > > > > > I would prefer (1) here. The use of EAP for MIP6 > > > bootstrapping > > > > > > > purposes and for 'normal' EAP-based access > > authentication are > > > > > > > different applications imho. (although in IKEv2 vs 802.1X > > > > > case e.g. > > > > > > > NAS-Port-Type could be used to make this distinction.. e.g. > > > > > > how 3GPP > > > > > > > WLAN stuff does it) > > > > > > > > > > > > > > > It might be useful to state a reason for your decision. > > > > > > > > > > > > > > > > Please also indicate whether some aspects are still > > > > > > unclear to you. > > > > > > > > > > > > > > > > Ciao > > > > > > > > Hannes > > > > > > > > > > > > > > Cheers, > > > > > > > Jouni > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > DiME mailing list > > > > > > > > DiME@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > DiME mailing list > > > > > > > DiME@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > DiME mailing list > > > > > > DiME@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > _______________________________________________ > > > > > DiME mailing list > > > > > DiME@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > -- > > > julien.bournelle at int-evry.fr > > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > > "This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster@starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you." > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 12 11:53:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNAZg-0000AX-9d; Tue, 12 Sep 2006 11:53:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNAZg-0000AS-0o for dime@ietf.org; Tue, 12 Sep 2006 11:53:24 -0400 Received: from imx11.toshiba.co.jp ([61.202.160.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNAZe-0005IV-WF for dime@ietf.org; Tue, 12 Sep 2006 11:53:23 -0400 Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx11.toshiba.co.jp with ESMTP id k8CFrJru012377; Wed, 13 Sep 2006 00:53:19 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id k8CFrIJl018850; Wed, 13 Sep 2006 00:53:18 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with ESMTP id AAA18849; Wed, 13 Sep 2006 00:53:18 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id k8CFrIHa029672; Wed, 13 Sep 2006 00:53:18 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k8CFrH0t024294; Wed, 13 Sep 2006 00:53:17 +0900 (JST) Received: from steelhead ([172.30.24.105]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J5H004HDLGNC1C0@mail.po.toshiba.co.jp>; Wed, 13 Sep 2006 00:53:17 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.63) (envelope-from ) id 1GNAZS-0001MQ-HO; Tue, 12 Sep 2006 08:53:10 -0700 Date: Tue, 12 Sep 2006 11:53:10 -0400 From: Yoshihiro Ohba In-reply-to: <20060912121400.GA2527@ipv6-3.int-evry.fr> To: Julien Bournelle Message-id: <20060912155310.GF2857@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <7CCD07160348804497EF29E9EA5560D78372F8@exchtewks2.starentnetworks.com> <20060906181643.GE5241@steelhead> <20060907152211.GA27475@ipv6-3.int-evry.fr> <20060907203328.GB18410@steelhead> <20060912121400.GA2527@ipv6-3.int-evry.fr> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: d49da3f50144c227c0d2fac65d3953e6 Cc: dime@ietf.org Subject: [Dime] Re: Using Diameter EAP --only-- for Authentication ? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org On Tue, Sep 12, 2006 at 02:14:00PM +0200, Julien Bournelle wrote: > Hi yoshi, > > as a reminder for everybody, we are talking of the HA-AAAH interface. OK. > > On Thu, Sep 07, 2006 at 04:33:28PM -0400, Yoshihiro Ohba wrote: > > > > Why you don't think this is not an issue? It is true that Diameter > > EAP was copied and modified from NASREQ, but I think we should stop > > doing the same thing for future applications. Otherwise, when either > > Diameter EAP or NASREQ specification is revised, then the changes will > > affect specifications of all copied applications. > > well i don't think it's an issue because I think that even if an > application wants to use EAP for Authentication purpose, an update of > the RFC 4072 won't > necessary imply an update of this new application. > > As you know, RFC4072 also do Authorization for network access and also > defines accouting for the network access. Some of the AVPs defined in > Diameter EAP are not necessary for mip6. Sure, if an updated part of RFC 4072 is not used by a new application, then this would not be an issue. But can we safely conclude that any future update for RFC 4072 will be nothing to do with MIP6 (or other new applications)? > > > To me this issue is > > very similar to an obvious issue that can happen when defining a class > > in C++ programming by copying and modifying other class instead of > > using class inheritance. > > > > > EAP is used for the first A of AAA and the 2 others > > > AA may need specific things depending on the application and differents > > > servers may be deployed depending on this application. > > > > Is there any pre-requisite that MIP6 bootstrapping needs to be > > designed as a single authentication/authorization application or can > > it be realized as two combined apllications (EAP/NASREQ + MIP6)? > > I think before answering to this question, we should ask wether it > makes sense to use RFC4072 -- only -- for Authentication. How do a AAA > server would know that this particular DER request is --only-- for > authentication and that it has to wait for a particular Authorization > message (with another app-id) for a service. A AAA server that receives DER does not need to know whether additional authorization is needed as long as HA knows about it as I mentioned in http://www1.ietf.org/mail-archive/web/dime/current/msg00726.html. However, if the AAA server somehow needs to know about it, the HA(NAS) can indicate it by including Auth-Request-Type AVP in DER with specifying "AUTHENTICATE_ONLY". > > If we "push" a little what you propose, we could define an > "Authentication based on EAP" Application (only doing Authentication) > used by other Application that would only define their messages for > Authorization and Accounting (such as MIP6). That's why I talked to you > in a previous mail about also consider network access as a special > service and thus define Authz/Accounting messages for the "network > access" service. Yes, in the case of network access, you could use NASREQ for authorization purpose in additon to Diameter EAP for authentication purpose as specified in RFC 4072. Regards, Yoshihiro Ohba > > regards, > > Julien > > > > > Regards, > > Yoshihiro Ohba > > > > > > > > > > > > > I also agree with Avi that defining a new application for MIP6 > > > > bootstrapping on top of existing applications (Diameter EAP) without > > > > defining a new application id but with defining new values for > > > > existing AVPs or new optional AVPs has some issue, but this option > > > > might not be as bad as the first option since backward compatibility > > > > can be easily maintained unlike the first option. However, there is a > > > > forward compatibility problem (i.e., a Diameter message may be forwarded > > > > to a AAA server that does not support the new application). Besides > > > > this problem, it might be worth pursuing this option because it works > > > > in an optimized way (i.e., bootstrapping AVPs are piggybacked in > > > > Diameter EAP or NASREQ message) as long as both NAS and AAA server > > > > support the AVPs. > > > > > > I'm not in favor of having an app-id for the nas-aaah part of the mip6 > > > bootstrapping problem. > > > > > > > > > > > In order to deal with the forward compatibility problem of the second > > > > option, a third option is to define a new application for MIP6 > > > > bootstrapping as a totally new authorization application that carries > > > > new mandatory AVPs specific to that application. This option can be > > > > run when execution of the second option succeeds in authentication but > > > > fails in carrying bootstrapping AVPs. > > > > > > hmm, i guess i have to think more of this option but this would mandate > > > now that all EAP Application server should know that maybe they are not > > > doing this for network access and that maybe they are going to receive > > > a special authorization request. And in this case, wouldn't it mean > > > that network access should be treated as a special service and this > > > would also require a new authorization application ? > > > > > > regards, > > > > > > Julien > > > > > > > > Regards, > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Sep 05, 2006 at 11:21:22PM -0400, Avi Lior wrote: > > > > > Hi Kuntal, > > > > > > > > > > Neither option 1 or option 2 will work. A new application id just wont > > > > > scale in the long run. What if another 'capability' were to be added > > > > > for instance prepaid. Since Diameter messages contain only one > > > > > Application ID, you would have to create an Application Id that covered > > > > > both EAP, Prepaid and Mobile IP. And what if a third application were > > > > > added? The approach is not scalable as the applications are increased > > > > > -- you would have to cope with all the different permutations of > > > > > Applications. The same argument goes for ServiceType and PortType and > > > > > these are actually more problematic. > > > > > > > > > > IMO the only thing we can do is to hint at the capability of the NAS. > > > > > > > > > > A proper solution should be concieved for this problem. > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > > > > > Sent: Tuesday, September 05, 2006 2:09 PM > > > > > > To: Avi Lior; Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > > > > > Cc: dime@ietf.org > > > > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > Service-Type > > > > > > > > > > > > All, > > > > > > > > > > > > Here is a scenario that may need to be covered. In some > > > > > > cases, local HA assignment is optimal for transport > > > > > > efficiency perspective. Diameter > > > > > > MIP4 application allows this. In such a case the ASP == MSP > > > > > > and the HA is assigned locally (in the visited network). > > > > > > > > > > > > To enable this case, in the integrated scenario, the NAS/VAAA > > > > > > needs to indicate it's capability to assign an HA in the > > > > > > local network to the HAAA. The HAAA may allow or disallow > > > > > > this local HA assignment based on policy of the MSA. > > > > > > > > > > > > The NAS/VAAA may need to include a hint in the AAA message to > > > > > > the HAAA at the time of access authentication that it is > > > > > > capable of providing an HA to the MN. This capability > > > > > > indication (hint) can be either sent via a new MIP6 specific > > > > > > AVP or it can be conveyed via an existing AVP (I don't know > > > > > > if one exists). > > > > > > > > > > > > If we decide to include this (local HA assignment), and we > > > > > > decide to include this mip6 specific hint in the NAS-HAAA > > > > > > communication, we may have to choose the most appropriate > > > > > > option (1) vs. (2). > > > > > > > > > > > > Comments? > > > > > > > > > > > > -Kuntal > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > > > > > Sent: Tuesday, September 05, 2006 6:07 AM > > > > > > > To: Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > > > > > > Cc: dime@ietf.org > > > > > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > Service-Type > > > > > > > > > > > > > > I must be missing something. > > > > > > > > > > > > > > In the integrated scenario, what would the NAS put in Service-Type? > > > > > > > > > > > > > > I think in the integrated scenario neither Port-Type or > > > > > > Service-Type > > > > > > > needs to be touched. > > > > > > > > > > > > > > As far as I understand the NAS is either executing EAP > > > > > > Application or > > > > > > > NAS REQ. It does not know whether the user will result in having > > > > > > > subsequent Mobile IP service or not. > > > > > > > > > > > > > > The only thing the AAA server can do is to send the MIPv6 attributes > > > > > > as > > > > > > > optional (M bit off) and hope that if the NAS does not > > > > > > understand the > > > > > > > attributes it would have some logic to bootstrap a different way. > > > > > > > > > > > > > > We could improve the situration somewhat. We could have the NAS > > > > > > > indicate that it supports MIPv6 bootstrapping by including hints in > > > > > > the > > > > > > > AR (a capability hint). Where the NAS includes HA-IP address AVP > > > > > > both > > > > > > > indicating that it can support bootstrapping and if the > > > > > > HA-IP address > > > > > > is > > > > > > > not ALL-ZEROS or ALL ONES it provides a hint that it can support > > > > > > dynamic > > > > > > > HA assignement. > > > > > > > > > > > > > > Ofcourse we could introduce the concept of capability hints more > > > > > > > formally in Diameter -- This is missing today. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > > > > > > > Sent: Tuesday, September 05, 2006 3:35 AM > > > > > > > > To: Hannes.Tschofenig@gmx.net > > > > > > > > Cc: dime@ietf.org > > > > > > > > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > > Service-Type > > > > > > > > > > > > > > > > Hi Hannes, > > > > > > > > > > > > > > > > I agree with Jouni. I prefer (2) for NAS-AAAH and (1) for > > > > > > AAAH-HA. > > > > > > > > In my understanding, there are no mandatory AVPs for NAS-AAAH and > > > > > > > > therefore I don't see a need of a new application; it's just a > > > > > > > > MIP-specific information that is piggybacked in the > > > > > > network access > > > > > > > > authentication procedure. > > > > > > > > > > > > > > > > Concerning AAAH-HA, I think it is a much cleaner approach > > > > > > to define > > > > > > > > a new application, since it does not anything to do with network > > > > > > > > authentication. > > > > > > > > > > > > > > > > --Gerardo > > > > > > > > > > > > > > > > On 9/5/06, jouni.korhonen@teliasonera.com > > > > > > > > wrote: > > > > > > > > > Hi HAnnes, > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > > > > > > > Sent: 1. syyskuuta 2006 1:07 > > > > > > > > > > To: dime@ietf.org > > > > > > > > > > Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > > > > Service-Type > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > we have had long discussions about the App-ID vs. > > > > > > > > > > Service-Type usage for > > > > > > > > > > Diameter MIPv6 Bootstrapping. > > > > > > > > > > > > > > > > > > > > It is time to see what the group thinks. Please indicate > > > > > > > > whether you > > > > > > > > > > prefer (1) an App-ID or (2) a Service-Type solution for > > > > > > > > > > > > > > > > > > > > (a) NAS-to-AAAH communication (as required by the integrated > > > > > > > > > > scenario; as one part of the solution component) > > > > > > > > > > > > > > > > > > I would prefer (2) for now.. or as long as the NAS-2-AAAH main > > > > > > > > > function is to provide access authentication, where the backend > > > > > > AAA > > > > > > > > > may return > > > > > > > > > MIP6 > > > > > > > > > bootstrapping info (as an enhancement) based e.g. on the user > > > > > > > > > subscription profile. If we go for more stuff on > > > > > > NAS-2-AAAH like > > > > > > > > > HoA/prefix etc then > > > > > > > > > (1) > > > > > > > > > might be better. > > > > > > > > > > > > > > > > > > > (b) HA-to-AAAH communication (as used by the split > > > > > > > > scenario and the > > > > > > > > > > integrated scenario) > > > > > > > > > > > > > > > > > > I would prefer (1) here. The use of EAP for MIP6 bootstrapping > > > > > > > > > purposes and for 'normal' EAP-based access authentication are > > > > > > > > > different applications imho. (although in IKEv2 vs 802.1X case > > > > > > e.g. > > > > > > > > > NAS-Port-Type could be used to make this distinction.. e.g. > > > > > > > > how 3GPP > > > > > > > > > WLAN stuff does it) > > > > > > > > > > > > > > > > > > > It might be useful to state a reason for your decision. > > > > > > > > > > > > > > > > > > > > Please also indicate whether some aspects are still > > > > > > > > unclear to you. > > > > > > > > > > > > > > > > > > > > Ciao > > > > > > > > > > Hannes > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > Jouni > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > DiME mailing list > > > > > > > > > > DiME@ietf.org > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > DiME mailing list > > > > > > > > > DiME@ietf.org > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > DiME mailing list > > > > > > > > DiME@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > DiME mailing list > > > > > > > DiME@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > "This email message and any attachments are confidential > > > > > > information of Starent Networks, Corp. The information > > > > > > transmitted may not be used to create or change any > > > > > > contractual obligations of Starent Networks, Corp. Any > > > > > > review, retransmission, dissemination or other use of, or > > > > > > taking of any action in reliance upon this e-mail and its > > > > > > attachments by persons or entities other than the intended > > > > > > recipient is prohibited. If you are not the intended > > > > > > recipient, please notify the sender immediately -- by > > > > > > replying to this message or by sending an email to > > > > > > postmaster@starentnetworks.com -- and destroy all copies of > > > > > > this message and any attachments without reading or > > > > > > disclosing their contents. Thank you." > > > > > > > > > > > > > > > > _______________________________________________ > > > > > DiME mailing list > > > > > DiME@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > -- > > > julien.bournelle at int-evry.fr > > > > > -- > julien.bournelle at int-evry.fr > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 12 18:48:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNH3e-0003Wi-8B; Tue, 12 Sep 2006 18:48:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNH3d-0003Wd-Da for dime@ietf.org; Tue, 12 Sep 2006 18:48:45 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GNH3b-0003tS-VC for dime@ietf.org; Tue, 12 Sep 2006 18:48:45 -0400 Received: (qmail invoked by alias); 12 Sep 2006 22:48:42 -0000 Received: from unknown (EHLO [10.75.119.218]) [64.251.112.98] by mail.gmx.net (mp038) with SMTP; 13 Sep 2006 00:48:42 +0200 X-Authenticated: #29516787 Message-ID: <45073945.5000109@gmx.net> Date: Wed, 13 Sep 2006 00:48:37 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Subject: [Dime] [Fwd: I-D ACTION:draft-ietf-mip6-aaa-ha-goals-03.txt] X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, please take a look at this draft since it defines the requirements for the Diameter Mobile IP bootstrapping work. Ciao Hannes -------- Original-Nachricht -------- Betreff: I-D ACTION:draft-ietf-mip6-aaa-ha-goals-03.txt Datum: Tue, 12 Sep 2006 15:50:01 -0400 Von: Internet-Drafts@ietf.org Antwort an: internet-drafts@ietf.org An: i-d-announce@ietf.org CC: mip6@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : AAA Goals for Mobile IPv6 Author(s) : G. Giaretta, et al. Filename : draft-ietf-mip6-aaa-ha-goals-03.txt Pages : 12 Date : 2006-9-12 In commercial deployments Mobile IPv6 can be a service offered by a Mobility Services Provider (MSP). In this case all protocol operations may need to be explicitly authorized and traced, requiring the interaction between Mobile IPv6 and the AAA infrastructure. Integrating the AAA infrastructure offers also a solution component for Mobile IPv6 bootstrapping in integrated and split scenarios. This document describes various scenarios where a AAA interface for Mobile IPv6 is actually required. Additionally, it lists design goals and requirements for such an interface. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-aaa-ha-goals-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-aaa-ha-goals-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-aaa-ha-goals-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 12 23:51:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNLmN-0000wv-DN; Tue, 12 Sep 2006 23:51:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNLmM-0000wo-6m for dime@ietf.org; Tue, 12 Sep 2006 23:51:14 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNLmK-0001Rh-Ml for dime@ietf.org; Tue, 12 Sep 2006 23:51:14 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 12 Sep 2006 20:51:13 -0700 X-IronPort-AV: i="4.09,157,1157353200"; d="scan'208,217"; a="320554102:sNHT52553280" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8D3pCma020393; Tue, 12 Sep 2006 20:51:12 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k8D3pC1E028199; Tue, 12 Sep 2006 20:51:12 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Sep 2006 20:51:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Framed-ipv6-prefix data format Date: Tue, 12 Sep 2006 20:51:09 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625029CBF71@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Framed-ipv6-prefix data format Thread-Index: AcbWfYNkMQ2sSGAESUO2/PeQzC6XmQAaC+sQ From: "Glen Zorn \(gwz\)" To: "Valesh Chandu" X-OriginalArrivalTime: 13 Sep 2006 03:51:11.0876 (UTC) FILETIME=[DA87CC40:01C6D6E7] DKIM-Signature: a=rsa-sha1; q=dns; l=4556; t=1158119472; x=1158983472; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20[Dime]=20Framed-ipv6-prefix=20data=20format=20; X=v=3Dcisco.com=3B=20h=3DPDIeFgwJXcG8dB/O8KyyfXp1xBM=3D; b=UomX+Ns/8wFTaxvr+4HH1tjAj1aGwhnvr3lWG/sIIKszcxxCq37ZLGF/QDI21L+4qtQQMmbV taTSt8SV06QTasSMmR/lpG8LNVfIzWoUYRC3O6B203co/zPzFqtL9UxC; Authentication-Results: sj-dkim-3.cisco.com; header.From=gwz@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 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="===============0542379799==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0542379799== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D6E7.DA36B894" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D6E7.DA36B894 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I have a small doubt regarding the Framed-ipv6-prefix Avp data field, this AVP is a Radius(RFC-3162) Avp that contains prefix length and the actual prefix in binary format, in Diameter (RFC 4005) it is defined as a Octet String, but not explicitly mentioned about the data filed of the Avp i.e whether the data field contains both the prefix length and ipv6 prefix or only the ipv6 prefix etc. i think the data field of this Avp in Diameter should contain both the prefix length & actual prefix as in Radius but there is no evidence to confirm this.=20 In general, I think that in the absence of other evidence Diameter AVPs & RADIUS attributes that have the same type (in this case, 97) also have the same data format. So, yes, the Framed-IPV6-Prefix AVP includes the prefix length as the first octet of the Data field. In retrospect, it probably would have been better to make this a grouped AVP with explicit rather than implicit structure. Oh, well...=20 So please any one could tell some standard document that is making clear this issue. Just I want this for standard compliance and to avoid interoperability issues.=20 Though not explicit, RFC 3588 strongly implies that the data format of AVPs 1-255 is essentially identical to that of RADIUS attributes with the same type codes; see sections 4.1 & 11.1.1 of 3588. Thanks in advance. Best Regards, Chandu=20 =20 =20 ------_=_NextPart_001_01C6D6E7.DA36B894 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi all,

I have a small doubt = regarding the=20 Framed-ipv6-prefix Avp data field, this AVP is a Radius(RFC-3162) Avp = that=20 contains prefix length and the actual prefix in binary format, in = Diameter (RFC=20 4005) it is defined as a Octet String, but not explicitly mentioned = about the=20 data filed of the Avp i.e whether the data field contains both the = prefix length=20 and ipv6 prefix or only the ipv6 prefix etc.

i think the data = field of=20 this Avp in Diameter should contain both the prefix length & actual = prefix=20 as in Radius but there is no evidence to confirm this. 
In general, I think that in the absence of = other=20 evidence Diameter AVPs & RADIUS attributes that have the same type = (in this=20 case, 97) also have the same data format.  So, yes, the=20 Framed-IPV6-Prefix AVP includes the prefix length as the first octet of = the Data=20 field.  In retrospect, it probably would have been better = to make=20 this a grouped AVP with explicit rather than implicit structure.  = Oh,=20 well... 

So please any one could tell some = standard=20 document that is making clear this issue. Just I want this for standard=20 compliance and to avoid interoperability issues. 
Though not explicit, RFC 3588 = strongly implies that=20 the data format of AVPs 1-255 is essentially identical to that of RADIUS = attributes with the same type codes; see sections 4.1 & 11.1.1 of=20 3588.

Thanks in advance.

Best = Regards,
Chandu=20


------_=_NextPart_001_01C6D6E7.DA36B894-- --===============0542379799== 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://www1.ietf.org/mailman/listinfo/dime --===============0542379799==-- From dime-bounces@ietf.org Wed Sep 13 04:50:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNQRz-0008OB-RO; Wed, 13 Sep 2006 04:50:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNQRy-0008O6-7e for dime@ietf.org; Wed, 13 Sep 2006 04:50:30 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNQRw-00087R-AZ for dime@ietf.org; Wed, 13 Sep 2006 04:50:30 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 61D7C2FD56; Wed, 13 Sep 2006 10:50:18 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1GNQUJ-000133-IR; Wed, 13 Sep 2006 10:52:55 +0200 Date: Wed, 13 Sep 2006 10:52:55 +0200 From: Julien Bournelle To: Yoshihiro Ohba Message-ID: <20060913085255.GA4025@ipv6-3.int-evry.fr> References: <7CCD07160348804497EF29E9EA5560D78372F8@exchtewks2.starentnetworks.com> <20060906181643.GE5241@steelhead> <20060907152211.GA27475@ipv6-3.int-evry.fr> <20060907203328.GB18410@steelhead> <20060912121400.GA2527@ipv6-3.int-evry.fr> <20060912155310.GF2857@steelhead> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060912155310.GF2857@steelhead> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 4cbeb0f20efb229aa93fae1468d20275 Cc: dime@ietf.org Subject: [Dime] Re: Using Diameter EAP --only-- for Authentication ? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi yoshi, On Tue, Sep 12, 2006 at 11:53:10AM -0400, Yoshihiro Ohba wrote: > > as a reminder for everybody, we are talking of the HA-AAAH interface. > > OK. > > > > > On Thu, Sep 07, 2006 at 04:33:28PM -0400, Yoshihiro Ohba wrote: > > > > > > Why you don't think this is not an issue? It is true that Diameter > > > EAP was copied and modified from NASREQ, but I think we should stop > > > doing the same thing for future applications. Otherwise, when either > > > Diameter EAP or NASREQ specification is revised, then the changes will > > > affect specifications of all copied applications. > > > > well i don't think it's an issue because I think that even if an > > application wants to use EAP for Authentication purpose, an update of > > the RFC 4072 won't > > necessary imply an update of this new application. > > > > As you know, RFC4072 also do Authorization for network access and also > > defines accouting for the network access. Some of the AVPs defined in > > Diameter EAP are not necessary for mip6. > > Sure, if an updated part of RFC 4072 is not used by a new application, > then this would not be an issue. But can we safely conclude that any > future update for RFC 4072 will be nothing to do with MIP6 (or other > new applications)? I guess no. > > I think before answering to this question, we should ask wether it > > makes sense to use RFC4072 -- only -- for Authentication. How do a AAA > > server would know that this particular DER request is --only-- for > > authentication and that it has to wait for a particular Authorization > > message (with another app-id) for a service. > > A AAA server that receives DER does not need to know whether > additional authorization is needed as long as HA knows about it as > I mentioned in http://www1.ietf.org/mail-archive/web/dime/current/msg00726.html. > I don't fully agree on that. If the AAA server thinks it's a NAS and it is doing AAA for network access, it may send unnecessary/inadequate AVP to the HA. > However, if the AAA server somehow needs to know about it, the HA(NAS) > can indicate it by including Auth-Request-Type AVP in DER with > specifying "AUTHENTICATE_ONLY". ok. I see. I forgot this possibility. So to sump up, the HA will use Diameter EAP with the Auth-Request-Type aVP set to AUTHENTICATE_ONLY and the App-ID set to 5. If it receives a success, it will switch to a Authorization/Accounting MIP6 Application with a new App-ID. Is that right ? I think it can work but we need to investigate a little more before moving with this. Points that I can see for now are: - The session-id must be shared between the Application. - We must be sure that messages will reach the same AAA server. - We may have trouble with RADIUS compatibility Anyone has an opinion on this way to solve our issue ? Thanks yoshi, Julien > > > > > If we "push" a little what you propose, we could define an > > "Authentication based on EAP" Application (only doing Authentication) > > used by other Application that would only define their messages for > > Authorization and Accounting (such as MIP6). That's why I talked to you > > in a previous mail about also consider network access as a special > > service and thus define Authz/Accounting messages for the "network > > access" service. > > Yes, in the case of network access, you could use NASREQ for > authorization purpose in additon to Diameter EAP for authentication > purpose as specified in RFC 4072. > > Regards, > Yoshihiro Ohba > > > > > > regards, > > > > Julien > > > > > > > > Regards, > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > I also agree with Avi that defining a new application for MIP6 > > > > > bootstrapping on top of existing applications (Diameter EAP) without > > > > > defining a new application id but with defining new values for > > > > > existing AVPs or new optional AVPs has some issue, but this option > > > > > might not be as bad as the first option since backward compatibility > > > > > can be easily maintained unlike the first option. However, there is a > > > > > forward compatibility problem (i.e., a Diameter message may be forwarded > > > > > to a AAA server that does not support the new application). Besides > > > > > this problem, it might be worth pursuing this option because it works > > > > > in an optimized way (i.e., bootstrapping AVPs are piggybacked in > > > > > Diameter EAP or NASREQ message) as long as both NAS and AAA server > > > > > support the AVPs. > > > > > > > > I'm not in favor of having an app-id for the nas-aaah part of the mip6 > > > > bootstrapping problem. > > > > > > > > > > > > > > In order to deal with the forward compatibility problem of the second > > > > > option, a third option is to define a new application for MIP6 > > > > > bootstrapping as a totally new authorization application that carries > > > > > new mandatory AVPs specific to that application. This option can be > > > > > run when execution of the second option succeeds in authentication but > > > > > fails in carrying bootstrapping AVPs. > > > > > > > > hmm, i guess i have to think more of this option but this would mandate > > > > now that all EAP Application server should know that maybe they are not > > > > doing this for network access and that maybe they are going to receive > > > > a special authorization request. And in this case, wouldn't it mean > > > > that network access should be treated as a special service and this > > > > would also require a new authorization application ? > > > > > > > > regards, > > > > > > > > Julien > > > > > > > > > > Regards, > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Sep 05, 2006 at 11:21:22PM -0400, Avi Lior wrote: > > > > > > Hi Kuntal, > > > > > > > > > > > > Neither option 1 or option 2 will work. A new application id just wont > > > > > > scale in the long run. What if another 'capability' were to be added > > > > > > for instance prepaid. Since Diameter messages contain only one > > > > > > Application ID, you would have to create an Application Id that covered > > > > > > both EAP, Prepaid and Mobile IP. And what if a third application were > > > > > > added? The approach is not scalable as the applications are increased > > > > > > -- you would have to cope with all the different permutations of > > > > > > Applications. The same argument goes for ServiceType and PortType and > > > > > > these are actually more problematic. > > > > > > > > > > > > IMO the only thing we can do is to hint at the capability of the NAS. > > > > > > > > > > > > A proper solution should be concieved for this problem. > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > > > > > > Sent: Tuesday, September 05, 2006 2:09 PM > > > > > > > To: Avi Lior; Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > > > > > > Cc: dime@ietf.org > > > > > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > Service-Type > > > > > > > > > > > > > > All, > > > > > > > > > > > > > > Here is a scenario that may need to be covered. In some > > > > > > > cases, local HA assignment is optimal for transport > > > > > > > efficiency perspective. Diameter > > > > > > > MIP4 application allows this. In such a case the ASP == MSP > > > > > > > and the HA is assigned locally (in the visited network). > > > > > > > > > > > > > > To enable this case, in the integrated scenario, the NAS/VAAA > > > > > > > needs to indicate it's capability to assign an HA in the > > > > > > > local network to the HAAA. The HAAA may allow or disallow > > > > > > > this local HA assignment based on policy of the MSA. > > > > > > > > > > > > > > The NAS/VAAA may need to include a hint in the AAA message to > > > > > > > the HAAA at the time of access authentication that it is > > > > > > > capable of providing an HA to the MN. This capability > > > > > > > indication (hint) can be either sent via a new MIP6 specific > > > > > > > AVP or it can be conveyed via an existing AVP (I don't know > > > > > > > if one exists). > > > > > > > > > > > > > > If we decide to include this (local HA assignment), and we > > > > > > > decide to include this mip6 specific hint in the NAS-HAAA > > > > > > > communication, we may have to choose the most appropriate > > > > > > > option (1) vs. (2). > > > > > > > > > > > > > > Comments? > > > > > > > > > > > > > > -Kuntal > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > > > > > > Sent: Tuesday, September 05, 2006 6:07 AM > > > > > > > > To: Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > > > > > > > Cc: dime@ietf.org > > > > > > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > Service-Type > > > > > > > > > > > > > > > > I must be missing something. > > > > > > > > > > > > > > > > In the integrated scenario, what would the NAS put in Service-Type? > > > > > > > > > > > > > > > > I think in the integrated scenario neither Port-Type or > > > > > > > Service-Type > > > > > > > > needs to be touched. > > > > > > > > > > > > > > > > As far as I understand the NAS is either executing EAP > > > > > > > Application or > > > > > > > > NAS REQ. It does not know whether the user will result in having > > > > > > > > subsequent Mobile IP service or not. > > > > > > > > > > > > > > > > The only thing the AAA server can do is to send the MIPv6 attributes > > > > > > > as > > > > > > > > optional (M bit off) and hope that if the NAS does not > > > > > > > understand the > > > > > > > > attributes it would have some logic to bootstrap a different way. > > > > > > > > > > > > > > > > We could improve the situration somewhat. We could have the NAS > > > > > > > > indicate that it supports MIPv6 bootstrapping by including hints in > > > > > > > the > > > > > > > > AR (a capability hint). Where the NAS includes HA-IP address AVP > > > > > > > both > > > > > > > > indicating that it can support bootstrapping and if the > > > > > > > HA-IP address > > > > > > > is > > > > > > > > not ALL-ZEROS or ALL ONES it provides a hint that it can support > > > > > > > dynamic > > > > > > > > HA assignement. > > > > > > > > > > > > > > > > Ofcourse we could introduce the concept of capability hints more > > > > > > > > formally in Diameter -- This is missing today. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > > > > > > > > Sent: Tuesday, September 05, 2006 3:35 AM > > > > > > > > > To: Hannes.Tschofenig@gmx.net > > > > > > > > > Cc: dime@ietf.org > > > > > > > > > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > > > Service-Type > > > > > > > > > > > > > > > > > > Hi Hannes, > > > > > > > > > > > > > > > > > > I agree with Jouni. I prefer (2) for NAS-AAAH and (1) for > > > > > > > AAAH-HA. > > > > > > > > > In my understanding, there are no mandatory AVPs for NAS-AAAH and > > > > > > > > > therefore I don't see a need of a new application; it's just a > > > > > > > > > MIP-specific information that is piggybacked in the > > > > > > > network access > > > > > > > > > authentication procedure. > > > > > > > > > > > > > > > > > > Concerning AAAH-HA, I think it is a much cleaner approach > > > > > > > to define > > > > > > > > > a new application, since it does not anything to do with network > > > > > > > > > authentication. > > > > > > > > > > > > > > > > > > --Gerardo > > > > > > > > > > > > > > > > > > On 9/5/06, jouni.korhonen@teliasonera.com > > > > > > > > > wrote: > > > > > > > > > > Hi HAnnes, > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > > > > > > > > Sent: 1. syyskuuta 2006 1:07 > > > > > > > > > > > To: dime@ietf.org > > > > > > > > > > > Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > > > > > Service-Type > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > we have had long discussions about the App-ID vs. > > > > > > > > > > > Service-Type usage for > > > > > > > > > > > Diameter MIPv6 Bootstrapping. > > > > > > > > > > > > > > > > > > > > > > It is time to see what the group thinks. Please indicate > > > > > > > > > whether you > > > > > > > > > > > prefer (1) an App-ID or (2) a Service-Type solution for > > > > > > > > > > > > > > > > > > > > > > (a) NAS-to-AAAH communication (as required by the integrated > > > > > > > > > > > scenario; as one part of the solution component) > > > > > > > > > > > > > > > > > > > > I would prefer (2) for now.. or as long as the NAS-2-AAAH main > > > > > > > > > > function is to provide access authentication, where the backend > > > > > > > AAA > > > > > > > > > > may return > > > > > > > > > > MIP6 > > > > > > > > > > bootstrapping info (as an enhancement) based e.g. on the user > > > > > > > > > > subscription profile. If we go for more stuff on > > > > > > > NAS-2-AAAH like > > > > > > > > > > HoA/prefix etc then > > > > > > > > > > (1) > > > > > > > > > > might be better. > > > > > > > > > > > > > > > > > > > > > (b) HA-to-AAAH communication (as used by the split > > > > > > > > > scenario and the > > > > > > > > > > > integrated scenario) > > > > > > > > > > > > > > > > > > > > I would prefer (1) here. The use of EAP for MIP6 bootstrapping > > > > > > > > > > purposes and for 'normal' EAP-based access authentication are > > > > > > > > > > different applications imho. (although in IKEv2 vs 802.1X case > > > > > > > e.g. > > > > > > > > > > NAS-Port-Type could be used to make this distinction.. e.g. > > > > > > > > > how 3GPP > > > > > > > > > > WLAN stuff does it) > > > > > > > > > > > > > > > > > > > > > It might be useful to state a reason for your decision. > > > > > > > > > > > > > > > > > > > > > > Please also indicate whether some aspects are still > > > > > > > > > unclear to you. > > > > > > > > > > > > > > > > > > > > > > Ciao > > > > > > > > > > > Hannes > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Jouni > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > DiME mailing list > > > > > > > > > > > DiME@ietf.org > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > DiME mailing list > > > > > > > > > > DiME@ietf.org > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > DiME mailing list > > > > > > > > > DiME@ietf.org > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > DiME mailing list > > > > > > > > DiME@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > "This email message and any attachments are confidential > > > > > > > information of Starent Networks, Corp. The information > > > > > > > transmitted may not be used to create or change any > > > > > > > contractual obligations of Starent Networks, Corp. Any > > > > > > > review, retransmission, dissemination or other use of, or > > > > > > > taking of any action in reliance upon this e-mail and its > > > > > > > attachments by persons or entities other than the intended > > > > > > > recipient is prohibited. If you are not the intended > > > > > > > recipient, please notify the sender immediately -- by > > > > > > > replying to this message or by sending an email to > > > > > > > postmaster@starentnetworks.com -- and destroy all copies of > > > > > > > this message and any attachments without reading or > > > > > > > disclosing their contents. Thank you." > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > DiME mailing list > > > > > > DiME@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > DiME mailing list > > > > > DiME@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > -- > > > > julien.bournelle at int-evry.fr > > > > > > > > -- > > julien.bournelle at int-evry.fr > > -- julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 13 05:20:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNQuX-00024k-8t; Wed, 13 Sep 2006 05:20:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNQuW-00024e-Cy for dime@ietf.org; Wed, 13 Sep 2006 05:20:00 -0400 Received: from mail12.opentransfer.com ([69.6.255.182]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GNQuQ-0004Cm-TA for dime@ietf.org; Wed, 13 Sep 2006 05:20:00 -0400 Received: (qmail 27591 invoked by uid 399); 13 Sep 2006 09:11:30 -0000 Received: from unknown (HELO prasad) (61.95.206.132) by mail12.opentransfer.com with SMTP; 13 Sep 2006 09:11:30 -0000 From: To: Date: Wed, 13 Sep 2006 14:41:28 +0530 Message-ID: <000d01c6d714$99e642c0$0801a8c0@prasad> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 Subject: [Dime] question on Fail-over X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 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="===============1318545943==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1318545943== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C6D742.B39E7EC0" This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C6D742.B39E7EC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I have a question on behavior of server at the time of Fail-over of a client. I will try to explain my doubt with the help of following scenario. 1. Assume that there are two diameter client Nodes, one configured as ACTIVE and other as STANDBY. Similarly there are two server Nodes configured. 2. There are some active sessions (either authorization or accounting) are on going between ACTIVE Client Node and ACTIVE server Node. According to RFC 3588, all the messages in these sessions will have Origin-Host as say, 'active.example.com' and Session-Id AVP as 'active.example.com; XXXX;YYYY'. 3. While there are active sessions, suppose ACTIVE client Node goes down, and the STANDBY starts to take over the sessions and tries to send messages to server. My doubt is: In step 3, when STANDBY client starts handling the ACTIVE sessions, what will be the session-Id AVP? Will it be 'standby.example.com;XXXX;YYYY' ,since this time messages are originated from the STANDBY client. or will it be the same as previous('active.example.com; XXXX;YYYY'). If it is first one, is it allowed at server Node? I think the server considers this as an error, since with in the same session messages with two different Session-Id AVPs are not allowed. If it is second one, then the Origin-Host AVP (in this case standby.example.com) will be different than in the host-identity portion of the session-Id AVP and I think this is not allowed according Base RFC. So, What will be behavior at server Node in this scenario. Any feed back/response is highly appreciated. Thanks PRASAD. ------=_NextPart_000_000E_01C6D742.B39E7EC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I have a question on behavior of server at the time = of Fail-over of a client. I will try to explain my doubt with the help of = following scenario.

        = ;    1. Assume that there are two diameter client Nodes, one configured as = ACTIVE and other as STANDBY. Similarly there are two server Nodes = configured.

        = ;    2. There are some active sessions (either authorization or accounting) are = on going between ACTIVE Client Node and ACTIVE server Node. According to = RFC 3588, all the messages in these sessions will have Origin-Host as say, = ‘active.example.com’ and Session-Id AVP as ‘active.example.com;XXXX;YYYY’. =

        = ;    3. While there are active sessions, suppose ACTIVE client Node goes down, = and the STANDBY starts to take over the sessions and tries to send messages to = server.

My doubt is:

        = ;    In step 3, when STANDBY client starts handling the ACTIVE sessions, what = will be the session-Id AVP? Will it be ‘standby.example.com;XXXX;YYYY’ ,since this time messages are originated from the STANDBY client. or will it be the same as = previous(‘active.example.com;XXXX;YYYY’). If it is = first one, is it allowed at server Node? I think the server considers this as = an error, since with in the same session messages with two different = Session-Id AVPs are not allowed. If it is second one, then the Origin-Host AVP (in = this case standby.example.com) will be different than in the host-identity = portion of the session-Id AVP and I think this is not allowed according Base = RFC. So, What will be behavior at server Node in this = scenario.

 

 

Any feed back/response is highly = appreciated.

 

 

Thanks

PRASAD.=

------=_NextPart_000_000E_01C6D742.B39E7EC0-- --===============1318545943== 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://www1.ietf.org/mailman/listinfo/dime --===============1318545943==-- From dime-bounces@ietf.org Wed Sep 13 09:15:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNUZx-0007TS-Sr; Wed, 13 Sep 2006 09:15:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNUZw-0007TH-Gx for dime@ietf.org; Wed, 13 Sep 2006 09:15:00 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNUZv-00077j-7K for dime@ietf.org; Wed, 13 Sep 2006 09:15:00 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 63CBBAD002 for ; Wed, 13 Sep 2006 09:14:58 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k8DDEvXY028766 for ; Wed, 13 Sep 2006 09:14:58 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Dime] question on Fail-over Date: Wed, 13 Sep 2006 09:14:24 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-Reply-To: <000d01c6d714$99e642c0$0801a8c0@prasad> Importance: Normal Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Prasad, I would say the second one. The session-Id for a single session must stay the same and session-Id must be globally unique. I don't see a reason, why those principles would be violated with the second option. Thanks, Tolga -----Original Message----- From: prasadsv@condornetworks.com [mailto:prasadsv@condornetworks.com] Sent: Wednesday, September 13, 2006 5:11 AM To: dime@ietf.org Subject: [Dime] question on Fail-over Hi, I have a question on behavior of server at the time of Fail-over of a client. I will try to explain my doubt with the help of following scenario. 1. Assume that there are two diameter client Nodes, one configured as ACTIVE and other as STANDBY. Similarly there are two server Nodes configured. 2. There are some active sessions (either authorization or accounting) are on going between ACTIVE Client Node and ACTIVE server Node. According to RFC 3588, all the messages in these sessions will have Origin-Host as say, 'active.example.com' and Session-Id AVP as 'active.example.com;XXXX;YYYY'. 3. While there are active sessions, suppose ACTIVE client Node goes down, and the STANDBY starts to take over the sessions and tries to send messages to server. My doubt is: In step 3, when STANDBY client starts handling the ACTIVE sessions, what will be the session-Id AVP? Will it be 'standby.example.com;XXXX;YYYY' ,since this time messages are originated from the STANDBY client. or will it be the same as previous('active.example.com;XXXX;YYYY'). If it is first one, is it allowed at server Node? I think the server considers this as an error, since with in the same session messages with two different Session-Id AVPs are not allowed. If it is second one, then the Origin-Host AVP (in this case standby.example.com) will be different than in the host-identity portion of the session-Id AVP and I think this is not allowed according Base RFC. So, What will be behavior at server Node in this scenario. Any feed back/response is highly appreciated. Thanks PRASAD. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 13 09:43:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNV1U-0001dx-1u; Wed, 13 Sep 2006 09:43:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNV1T-0001dp-2k for dime@ietf.org; Wed, 13 Sep 2006 09:43:27 -0400 Received: from imx11.toshiba.co.jp ([61.202.160.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNV1O-0003jv-2v for dime@ietf.org; Wed, 13 Sep 2006 09:43:27 -0400 Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx11.toshiba.co.jp with ESMTP id k8DDhGV5001294; Wed, 13 Sep 2006 22:43:16 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id k8DDhGV3005327; Wed, 13 Sep 2006 22:43:16 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with ESMTP id YAA05323; Wed, 13 Sep 2006 22:43:15 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id k8DDhEA4026229; Wed, 13 Sep 2006 22:43:15 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k8DDhEV5024081; Wed, 13 Sep 2006 22:43:14 +0900 (JST) Received: from steelhead ([172.30.24.105]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J5J007WTA3U8D50@mail.po.toshiba.co.jp>; Wed, 13 Sep 2006 22:43:14 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.63) (envelope-from ) id 1GNV18-0004DU-8k; Wed, 13 Sep 2006 06:43:06 -0700 Date: Wed, 13 Sep 2006 09:43:06 -0400 From: Yoshihiro Ohba In-reply-to: <20060913085255.GA4025@ipv6-3.int-evry.fr> To: Julien Bournelle Message-id: <20060913134306.GC15246@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <7CCD07160348804497EF29E9EA5560D78372F8@exchtewks2.starentnetworks.com> <20060906181643.GE5241@steelhead> <20060907152211.GA27475@ipv6-3.int-evry.fr> <20060907203328.GB18410@steelhead> <20060912121400.GA2527@ipv6-3.int-evry.fr> <20060912155310.GF2857@steelhead> <20060913085255.GA4025@ipv6-3.int-evry.fr> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: bdfdd9dd835c9bb499f7c92933fef080 Cc: dime@ietf.org Subject: [Dime] Re: Using Diameter EAP --only-- for Authentication ? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Julien, On Wed, Sep 13, 2006 at 10:52:55AM +0200, Julien Bournelle wrote: (snip) > > > However, if the AAA server somehow needs to know about it, the HA(NAS) > > can indicate it by including Auth-Request-Type AVP in DER with > > specifying "AUTHENTICATE_ONLY". > > ok. I see. I forgot this possibility. > So to sump up, the HA will use Diameter EAP with the Auth-Request-Type > aVP set to AUTHENTICATE_ONLY and the App-ID set to 5. If it receives a > success, it will switch to a Authorization/Accounting MIP6 Application > with a new App-ID. Is that right ? > > I think it can work but we need to investigate a little more before > moving with this. Points that I can see for now are: > > - The session-id must be shared between the Application. Why session-id must be shared? NASREQ usage for authorization purpose in RFC 4072 does not require it. Instead, User-Name AVP can be shared between the applications. In case the NAS(HA) is not able to retrieve the username from EAP messages, the AAA server can tell the NAS about the username by carrying User-Name AVP in DEA message, as described in RFC 4072. > - We must be sure that messages will reach the same AAA server. Why Diameter EAP messages and Diameter MIP6 messages need to hit the same AAA server? Again, NASREQ usage for authorization purpse in RFC 4072 does not require NASREQ and Diameter EAP messages to use the same AAA server. In general, authentication, authorization and accouting can use different AAA servers, and there should be no exception to MIP6 bootstrapping, IMO. > - We may have trouble with RADIUS compatibility This can be handled later. Yoshihiro Ohba > > Anyone has an opinion on this way to solve our issue ? > > Thanks yoshi, > > Julien > > > > > > > > > If we "push" a little what you propose, we could define an > > > "Authentication based on EAP" Application (only doing Authentication) > > > used by other Application that would only define their messages for > > > Authorization and Accounting (such as MIP6). That's why I talked to you > > > in a previous mail about also consider network access as a special > > > service and thus define Authz/Accounting messages for the "network > > > access" service. > > > > Yes, in the case of network access, you could use NASREQ for > > authorization purpose in additon to Diameter EAP for authentication > > purpose as specified in RFC 4072. > > > > Regards, > > Yoshihiro Ohba > > > > > > > > > > regards, > > > > > > Julien > > > > > > > > > > > Regards, > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > I also agree with Avi that defining a new application for MIP6 > > > > > > bootstrapping on top of existing applications (Diameter EAP) without > > > > > > defining a new application id but with defining new values for > > > > > > existing AVPs or new optional AVPs has some issue, but this option > > > > > > might not be as bad as the first option since backward compatibility > > > > > > can be easily maintained unlike the first option. However, there is a > > > > > > forward compatibility problem (i.e., a Diameter message may be forwarded > > > > > > to a AAA server that does not support the new application). Besides > > > > > > this problem, it might be worth pursuing this option because it works > > > > > > in an optimized way (i.e., bootstrapping AVPs are piggybacked in > > > > > > Diameter EAP or NASREQ message) as long as both NAS and AAA server > > > > > > support the AVPs. > > > > > > > > > > I'm not in favor of having an app-id for the nas-aaah part of the mip6 > > > > > bootstrapping problem. > > > > > > > > > > > > > > > > > In order to deal with the forward compatibility problem of the second > > > > > > option, a third option is to define a new application for MIP6 > > > > > > bootstrapping as a totally new authorization application that carries > > > > > > new mandatory AVPs specific to that application. This option can be > > > > > > run when execution of the second option succeeds in authentication but > > > > > > fails in carrying bootstrapping AVPs. > > > > > > > > > > hmm, i guess i have to think more of this option but this would mandate > > > > > now that all EAP Application server should know that maybe they are not > > > > > doing this for network access and that maybe they are going to receive > > > > > a special authorization request. And in this case, wouldn't it mean > > > > > that network access should be treated as a special service and this > > > > > would also require a new authorization application ? > > > > > > > > > > regards, > > > > > > > > > > Julien > > > > > > > > > > > > Regards, > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Sep 05, 2006 at 11:21:22PM -0400, Avi Lior wrote: > > > > > > > Hi Kuntal, > > > > > > > > > > > > > > Neither option 1 or option 2 will work. A new application id just wont > > > > > > > scale in the long run. What if another 'capability' were to be added > > > > > > > for instance prepaid. Since Diameter messages contain only one > > > > > > > Application ID, you would have to create an Application Id that covered > > > > > > > both EAP, Prepaid and Mobile IP. And what if a third application were > > > > > > > added? The approach is not scalable as the applications are increased > > > > > > > -- you would have to cope with all the different permutations of > > > > > > > Applications. The same argument goes for ServiceType and PortType and > > > > > > > these are actually more problematic. > > > > > > > > > > > > > > IMO the only thing we can do is to hint at the capability of the NAS. > > > > > > > > > > > > > > A proper solution should be concieved for this problem. > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > > > > > > > Sent: Tuesday, September 05, 2006 2:09 PM > > > > > > > > To: Avi Lior; Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > > > > > > > Cc: dime@ietf.org > > > > > > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > > Service-Type > > > > > > > > > > > > > > > > All, > > > > > > > > > > > > > > > > Here is a scenario that may need to be covered. In some > > > > > > > > cases, local HA assignment is optimal for transport > > > > > > > > efficiency perspective. Diameter > > > > > > > > MIP4 application allows this. In such a case the ASP == MSP > > > > > > > > and the HA is assigned locally (in the visited network). > > > > > > > > > > > > > > > > To enable this case, in the integrated scenario, the NAS/VAAA > > > > > > > > needs to indicate it's capability to assign an HA in the > > > > > > > > local network to the HAAA. The HAAA may allow or disallow > > > > > > > > this local HA assignment based on policy of the MSA. > > > > > > > > > > > > > > > > The NAS/VAAA may need to include a hint in the AAA message to > > > > > > > > the HAAA at the time of access authentication that it is > > > > > > > > capable of providing an HA to the MN. This capability > > > > > > > > indication (hint) can be either sent via a new MIP6 specific > > > > > > > > AVP or it can be conveyed via an existing AVP (I don't know > > > > > > > > if one exists). > > > > > > > > > > > > > > > > If we decide to include this (local HA assignment), and we > > > > > > > > decide to include this mip6 specific hint in the NAS-HAAA > > > > > > > > communication, we may have to choose the most appropriate > > > > > > > > option (1) vs. (2). > > > > > > > > > > > > > > > > Comments? > > > > > > > > > > > > > > > > -Kuntal > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > > > > > > > Sent: Tuesday, September 05, 2006 6:07 AM > > > > > > > > > To: Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > > > > > > > > Cc: dime@ietf.org > > > > > > > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > > Service-Type > > > > > > > > > > > > > > > > > > I must be missing something. > > > > > > > > > > > > > > > > > > In the integrated scenario, what would the NAS put in Service-Type? > > > > > > > > > > > > > > > > > > I think in the integrated scenario neither Port-Type or > > > > > > > > Service-Type > > > > > > > > > needs to be touched. > > > > > > > > > > > > > > > > > > As far as I understand the NAS is either executing EAP > > > > > > > > Application or > > > > > > > > > NAS REQ. It does not know whether the user will result in having > > > > > > > > > subsequent Mobile IP service or not. > > > > > > > > > > > > > > > > > > The only thing the AAA server can do is to send the MIPv6 attributes > > > > > > > > as > > > > > > > > > optional (M bit off) and hope that if the NAS does not > > > > > > > > understand the > > > > > > > > > attributes it would have some logic to bootstrap a different way. > > > > > > > > > > > > > > > > > > We could improve the situration somewhat. We could have the NAS > > > > > > > > > indicate that it supports MIPv6 bootstrapping by including hints in > > > > > > > > the > > > > > > > > > AR (a capability hint). Where the NAS includes HA-IP address AVP > > > > > > > > both > > > > > > > > > indicating that it can support bootstrapping and if the > > > > > > > > HA-IP address > > > > > > > > is > > > > > > > > > not ALL-ZEROS or ALL ONES it provides a hint that it can support > > > > > > > > dynamic > > > > > > > > > HA assignement. > > > > > > > > > > > > > > > > > > Ofcourse we could introduce the concept of capability hints more > > > > > > > > > formally in Diameter -- This is missing today. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > > > > > > > > > Sent: Tuesday, September 05, 2006 3:35 AM > > > > > > > > > > To: Hannes.Tschofenig@gmx.net > > > > > > > > > > Cc: dime@ietf.org > > > > > > > > > > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > > > > Service-Type > > > > > > > > > > > > > > > > > > > > Hi Hannes, > > > > > > > > > > > > > > > > > > > > I agree with Jouni. I prefer (2) for NAS-AAAH and (1) for > > > > > > > > AAAH-HA. > > > > > > > > > > In my understanding, there are no mandatory AVPs for NAS-AAAH and > > > > > > > > > > therefore I don't see a need of a new application; it's just a > > > > > > > > > > MIP-specific information that is piggybacked in the > > > > > > > > network access > > > > > > > > > > authentication procedure. > > > > > > > > > > > > > > > > > > > > Concerning AAAH-HA, I think it is a much cleaner approach > > > > > > > > to define > > > > > > > > > > a new application, since it does not anything to do with network > > > > > > > > > > authentication. > > > > > > > > > > > > > > > > > > > > --Gerardo > > > > > > > > > > > > > > > > > > > > On 9/5/06, jouni.korhonen@teliasonera.com > > > > > > > > > > wrote: > > > > > > > > > > > Hi HAnnes, > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > > > > > > > > > Sent: 1. syyskuuta 2006 1:07 > > > > > > > > > > > > To: dime@ietf.org > > > > > > > > > > > > Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > > > > > > Service-Type > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > we have had long discussions about the App-ID vs. > > > > > > > > > > > > Service-Type usage for > > > > > > > > > > > > Diameter MIPv6 Bootstrapping. > > > > > > > > > > > > > > > > > > > > > > > > It is time to see what the group thinks. Please indicate > > > > > > > > > > whether you > > > > > > > > > > > > prefer (1) an App-ID or (2) a Service-Type solution for > > > > > > > > > > > > > > > > > > > > > > > > (a) NAS-to-AAAH communication (as required by the integrated > > > > > > > > > > > > scenario; as one part of the solution component) > > > > > > > > > > > > > > > > > > > > > > I would prefer (2) for now.. or as long as the NAS-2-AAAH main > > > > > > > > > > > function is to provide access authentication, where the backend > > > > > > > > AAA > > > > > > > > > > > may return > > > > > > > > > > > MIP6 > > > > > > > > > > > bootstrapping info (as an enhancement) based e.g. on the user > > > > > > > > > > > subscription profile. If we go for more stuff on > > > > > > > > NAS-2-AAAH like > > > > > > > > > > > HoA/prefix etc then > > > > > > > > > > > (1) > > > > > > > > > > > might be better. > > > > > > > > > > > > > > > > > > > > > > > (b) HA-to-AAAH communication (as used by the split > > > > > > > > > > scenario and the > > > > > > > > > > > > integrated scenario) > > > > > > > > > > > > > > > > > > > > > > I would prefer (1) here. The use of EAP for MIP6 bootstrapping > > > > > > > > > > > purposes and for 'normal' EAP-based access authentication are > > > > > > > > > > > different applications imho. (although in IKEv2 vs 802.1X case > > > > > > > > e.g. > > > > > > > > > > > NAS-Port-Type could be used to make this distinction.. e.g. > > > > > > > > > > how 3GPP > > > > > > > > > > > WLAN stuff does it) > > > > > > > > > > > > > > > > > > > > > > > It might be useful to state a reason for your decision. > > > > > > > > > > > > > > > > > > > > > > > > Please also indicate whether some aspects are still > > > > > > > > > > unclear to you. > > > > > > > > > > > > > > > > > > > > > > > > Ciao > > > > > > > > > > > > Hannes > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > Jouni > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > DiME mailing list > > > > > > > > > > > > DiME@ietf.org > > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > DiME mailing list > > > > > > > > > > > DiME@ietf.org > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > DiME mailing list > > > > > > > > > > DiME@ietf.org > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > DiME mailing list > > > > > > > > > DiME@ietf.org > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > "This email message and any attachments are confidential > > > > > > > > information of Starent Networks, Corp. The information > > > > > > > > transmitted may not be used to create or change any > > > > > > > > contractual obligations of Starent Networks, Corp. Any > > > > > > > > review, retransmission, dissemination or other use of, or > > > > > > > > taking of any action in reliance upon this e-mail and its > > > > > > > > attachments by persons or entities other than the intended > > > > > > > > recipient is prohibited. If you are not the intended > > > > > > > > recipient, please notify the sender immediately -- by > > > > > > > > replying to this message or by sending an email to > > > > > > > > postmaster@starentnetworks.com -- and destroy all copies of > > > > > > > > this message and any attachments without reading or > > > > > > > > disclosing their contents. Thank you." > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > DiME mailing list > > > > > > > DiME@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > DiME mailing list > > > > > > DiME@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > -- > > > > > julien.bournelle at int-evry.fr > > > > > > > > > > > -- > > > julien.bournelle at int-evry.fr > > > > > -- > julien.bournelle at int-evry.fr > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 13 10:51:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNW56-0003co-M1; Wed, 13 Sep 2006 10:51:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNW55-0003bM-F8 for dime@ietf.org; Wed, 13 Sep 2006 10:51:15 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GNW51-0007fM-2K for dime@ietf.org; Wed, 13 Sep 2006 10:51:15 -0400 Received: (qmail invoked by alias); 13 Sep 2006 14:51:09 -0000 Received: from unknown (EHLO [10.75.119.218]) [64.251.112.98] by mail.gmx.net (mp044) with SMTP; 13 Sep 2006 16:51:09 +0200 X-Authenticated: #29516787 Message-ID: <45081AE1.3000006@gmx.net> Date: Wed, 13 Sep 2006 16:51:13 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Dime] Open Issues of RFC 3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, together with Victor I went through the list of open issues: http://www.tschofenig.priv.at:8080/diameter-interop/ Please take a look at them and see whether you could contribute text to resolve the issue. You might also recognize that we closed a few issues (look for 'done-cbb' n the status column). Furthermore, we also included text as a resolution for some issues. I would also suggest not to focus on the issues grouped under 'feature' for now. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 13 12:06:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNXFv-00063P-FJ; Wed, 13 Sep 2006 12:06:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNXFu-00063K-V2 for dime@ietf.org; Wed, 13 Sep 2006 12:06:30 -0400 Received: from mail12.opentransfer.com ([69.6.255.182]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GNXFs-0001Wb-9j for dime@ietf.org; Wed, 13 Sep 2006 12:06:30 -0400 Received: (qmail 11361 invoked by uid 399); 13 Sep 2006 16:06:26 -0000 Received: from unknown (HELO prasad) (59.144.53.59) by mail12.opentransfer.com with SMTP; 13 Sep 2006 16:06:26 -0000 From: To: "'Tolga Asveren'" , Subject: RE: [Dime] question on Fail-over Date: Wed, 13 Sep 2006 21:36:24 +0530 Message-ID: <000201c6d74e$91361760$0801a8c0@prasad> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga, According to section 8.8 in Base RFC, the session-Id MUST start with diameter Identity. I think this is nothing but the value in the Origin-Host AVP. So we consider the second option as allowed, don't this differ the section 8.8? Or in this particular scenario, since the sever knows that active client is down and it should be ready to receive the messages from standby (with mandatory portion of the session-Id starting with active client's Identity)? But in general, I feel the mandatory portion of the session-Id AVP should be Same as the value in the origin-Host AVP. Thanks Prasad. -----Original Message----- From: Tolga Asveren [mailto:asveren@ulticom.com] Sent: Wednesday, September 13, 2006 6:44 PM To: dime@ietf.org Subject: RE: [Dime] question on Fail-over Prasad, I would say the second one. The session-Id for a single session must stay the same and session-Id must be globally unique. I don't see a reason, why those principles would be violated with the second option. Thanks, Tolga -----Original Message----- From: prasadsv@condornetworks.com [mailto:prasadsv@condornetworks.com] Sent: Wednesday, September 13, 2006 5:11 AM To: dime@ietf.org Subject: [Dime] question on Fail-over Hi, I have a question on behavior of server at the time of Fail-over of a client. I will try to explain my doubt with the help of following scenario. 1. Assume that there are two diameter client Nodes, one configured as ACTIVE and other as STANDBY. Similarly there are two server Nodes configured. 2. There are some active sessions (either authorization or accounting) are on going between ACTIVE Client Node and ACTIVE server Node. According to RFC 3588, all the messages in these sessions will have Origin-Host as say, 'active.example.com' and Session-Id AVP as 'active.example.com;XXXX;YYYY'. 3. While there are active sessions, suppose ACTIVE client Node goes down, and the STANDBY starts to take over the sessions and tries to send messages to server. My doubt is: In step 3, when STANDBY client starts handling the ACTIVE sessions, what will be the session-Id AVP? Will it be 'standby.example.com;XXXX;YYYY' ,since this time messages are originated from the STANDBY client. or will it be the same as previous('active.example.com;XXXX;YYYY'). If it is first one, is it allowed at server Node? I think the server considers this as an error, since with in the same session messages with two different Session-Id AVPs are not allowed. If it is second one, then the Origin-Host AVP (in this case standby.example.com) will be different than in the host-identity portion of the session-Id AVP and I think this is not allowed according Base RFC. So, What will be behavior at server Node in this scenario. Any feed back/response is highly appreciated. Thanks PRASAD. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.12.3/446 - Release Date: 9/12/2006 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 13 12:31:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNXdd-00005z-Bq; Wed, 13 Sep 2006 12:31:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNXdd-00005u-1t for dime@ietf.org; Wed, 13 Sep 2006 12:31:01 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNXdb-0005FJ-Kc for dime@ietf.org; Wed, 13 Sep 2006 12:31:01 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 37F5717A0C for ; Wed, 13 Sep 2006 12:30:54 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k8DGUm33017860 for ; Wed, 13 Sep 2006 12:30:52 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Dime] question on Fail-over Date: Wed, 13 Sep 2006 12:30:13 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-Reply-To: <000201c6d74e$91361760$0801a8c0@prasad> Importance: Normal Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Prasad, I would think 8.8 mentions it just a way to guarantee the globally uniqueness of the Session-Id. In the scenario you described if you use the existing session-Id, that property is still there. It is not so that one host is using another ones id for the session-Id it generates, but it simply takes over ownership of an existing session. In general I agree with you that each host should use its own id when generating new session-Ids, but in the sceanrio we are discussing, the session is not newly created by the standby host. Thanks, Tolga > -----Original Message----- > From: prasadsv@condornetworks.com [mailto:prasadsv@condornetworks.com] > Sent: Wednesday, September 13, 2006 12:06 PM > To: 'Tolga Asveren'; dime@ietf.org > Subject: RE: [Dime] question on Fail-over > > > Hi Tolga, > According to section 8.8 in Base RFC, the session-Id MUST start with > diameter Identity. I think this is nothing but the value in the > Origin-Host AVP. So we consider the second option as allowed, don't this > differ the section 8.8? Or in this particular scenario, since the sever > knows that active client is down and it should be ready to receive the > messages from standby (with mandatory portion of the session-Id starting > with active client's Identity)? > > But in general, I feel the mandatory portion of the session-Id AVP > should be > Same as the value in the origin-Host AVP. > > Thanks > Prasad. > > -----Original Message----- > From: Tolga Asveren [mailto:asveren@ulticom.com] > Sent: Wednesday, September 13, 2006 6:44 PM > To: dime@ietf.org > Subject: RE: [Dime] question on Fail-over > > Prasad, > > I would say the second one. The session-Id for a single session must > stay > the same and session-Id must be globally unique. I don't see a reason, > why > those principles would be violated with the second option. > > Thanks, > Tolga > > -----Original Message----- > From: prasadsv@condornetworks.com [mailto:prasadsv@condornetworks.com] > Sent: Wednesday, September 13, 2006 5:11 AM > To: dime@ietf.org > Subject: [Dime] question on Fail-over > > > Hi, > I have a question on behavior of server at the time of Fail-over of a > client. I will try to explain my doubt with the help of following > scenario. > 1. Assume that there are two diameter client Nodes, one > configured as ACTIVE and other as STANDBY. Similarly there are two > server > Nodes configured. > 2. There are some active sessions (either authorization or > accounting) are on going between ACTIVE Client Node and ACTIVE server > Node. > According to RFC 3588, all the messages in these sessions will have > Origin-Host as say, 'active.example.com' and Session-Id AVP as > 'active.example.com;XXXX;YYYY'. > 3. While there are active sessions, suppose ACTIVE client > Node > goes down, and the STANDBY starts to take over the sessions and tries to > send messages to server. > My doubt is: > In step 3, when STANDBY client starts handling the ACTIVE > sessions, what will be the session-Id AVP? Will it be > 'standby.example.com;XXXX;YYYY' ,since this time messages are originated > from the STANDBY client. or will it be the same as > previous('active.example.com;XXXX;YYYY'). If it is first one, is it > allowed > at server Node? I think the server considers this as an error, since > with in > the same session messages with two different Session-Id AVPs are not > allowed. If it is second one, then the Origin-Host AVP (in this case > standby.example.com) will be different than in the host-identity portion > of > the session-Id AVP and I think this is not allowed according Base RFC. > So, > What will be behavior at server Node in this scenario. > > > Any feed back/response is highly appreciated. > > > Thanks > PRASAD. > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.405 / Virus Database: 268.12.3/446 - Release Date: > 9/12/2006 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 13 13:21:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNYQf-0003Yy-4u; Wed, 13 Sep 2006 13:21:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNYQd-0003Y3-Qi for dime@ietf.org; Wed, 13 Sep 2006 13:21:39 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNYQa-00038v-BT for dime@ietf.org; Wed, 13 Sep 2006 13:21:39 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 71AF850D16 for ; Wed, 13 Sep 2006 13:21:31 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k8DHLVQc021829 for ; Wed, 13 Sep 2006 13:21:31 -0400 (EDT) From: "Tolga Asveren" To: Date: Wed, 13 Sep 2006 13:20:56 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [Dime] Error Code issues for bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi All, There already is an item related with error codes in the issue tracker "Inconsistent Result-code Error classification". I want to bring the use of E-bit to the lists attention as well. E-bit is used to indicate that the grammar will follow the definion in 7.2 . The question is, what does qualify an error code to use that special grammar? It looks to me, all errors defined in 7.1 can use this grammar. I would exclude DIAMETER_AUTHENTICATION_REJECTED, DIAMETER_AUTHORIZATION_REJECTED (and maybe also DIAMETER_REDIRECT_INDICATION), because they are not really errors from base protocol point of view but rather some issues on application level. For other error codes, why do we need the full set of AVPs (except special AVPs which may be used for routing purposes like Proxy-Info AVP)? This would could have a few advantages AFAICS: i- An answer with E-bit not set needs to comply to the grammar of the corresponding answer message definition. This may require adding some mandatory AVPs which are part of the answer message grammar requiring application logic involvement. With E-bit set, as soon as the decoding error is detected, answer message can be generated. ii- For certain error codes, which are currently listed as not using error answer grammar, it could not be possible to further decode a message, e.g. DIAMETER_INVALID_AVP_LENGTH generated because of an AVP, whose length field exceeds the message boundary. With error answer message grammar, the error answer can be generated as soon as such a case is detected. iii- It would be clear when and why the special error answer grammer is used. This shouldn't create backward compatibility issues, because error answers will be validated based on the grammer indicated with persence/absence of E-bit. I propose, we include that change as well as part of the bis effort. Thanks, Tolga _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 13 13:23:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNYSS-0004k9-Vu; Wed, 13 Sep 2006 13:23:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNYSR-0004k3-T2 for dime@ietf.org; Wed, 13 Sep 2006 13:23:31 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNYSP-0003ZC-Hj for dime@ietf.org; Wed, 13 Sep 2006 13:23:31 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 13 Sep 2006 10:23:29 -0700 X-IronPort-AV: i="4.09,160,1157353200"; d="scan'208"; a="41475483:sNHT32966060" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8DHNT92002711; Wed, 13 Sep 2006 13:23:29 -0400 Received: from [10.86.240.188] (che-vpn-cluster-1-188.cisco.com [10.86.240.188]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k8DHNSdM026852; Wed, 13 Sep 2006 13:23:28 -0400 (EDT) Message-ID: <45083E90.3020704@cisco.com> Date: Wed, 13 Sep 2006 13:23:28 -0400 From: Anders Kristensen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] question on Fail-over References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=4720; t=1158168209; x=1159032209; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andersk@cisco.com; z=From:Anders=20Kristensen=20 |Subject:Re=3A=20[Dime]=20question=20on=20Fail-over |To:Tolga=20Asveren=20; X=v=3Dcisco.com=3B=20h=3Dvy9jQ2cly33ho2ZwZdLAefsrUmU=3D; b=zTbl+p9HVrq+jxN6iOIRR8s5MWXUiut3U4YJPkRVswFqLIyC/p7j7P9TED3iKquA+CM9QGwz FW6zS5A6oL0LBynvQyZtcau0h2s2z8UpGj+DtgBtKeDiOKKH4rjN+Vt7; Authentication-Results: rtp-dkim-2.cisco.com; header.From=andersk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I agree with Tolga and would add that it's probably a very bad idea for the server to make any assumptions about the Session-Id, including that the FQDN part euals the Origin-Host, even in the session initiating request. IMHO, it should be treated just as an opaque ID. Anders Tolga Asveren wrote: > Hi Prasad, > > I would think 8.8 mentions it just a way to guarantee the globally > uniqueness of the Session-Id. In the scenario you described if you use the > existing session-Id, that property is still there. It is not so that one > host is using another ones id for the session-Id it generates, but it simply > takes over ownership of an existing session. > > In general I agree with you that each host should use its own id when > generating new session-Ids, but in the sceanrio we are discussing, the > session is not newly created by the standby host. > > Thanks, > Tolga > > >>-----Original Message----- >>From: prasadsv@condornetworks.com [mailto:prasadsv@condornetworks.com] >>Sent: Wednesday, September 13, 2006 12:06 PM >>To: 'Tolga Asveren'; dime@ietf.org >>Subject: RE: [Dime] question on Fail-over >> >> >>Hi Tolga, >>According to section 8.8 in Base RFC, the session-Id MUST start with >>diameter Identity. I think this is nothing but the value in the >>Origin-Host AVP. So we consider the second option as allowed, don't this >>differ the section 8.8? Or in this particular scenario, since the sever >>knows that active client is down and it should be ready to receive the >>messages from standby (with mandatory portion of the session-Id starting >>with active client's Identity)? >> >>But in general, I feel the mandatory portion of the session-Id AVP >>should be >>Same as the value in the origin-Host AVP. >> >>Thanks >>Prasad. >> >>-----Original Message----- >>From: Tolga Asveren [mailto:asveren@ulticom.com] >>Sent: Wednesday, September 13, 2006 6:44 PM >>To: dime@ietf.org >>Subject: RE: [Dime] question on Fail-over >> >>Prasad, >> >>I would say the second one. The session-Id for a single session must >>stay >>the same and session-Id must be globally unique. I don't see a reason, >>why >>those principles would be violated with the second option. >> >> Thanks, >> Tolga >> >>-----Original Message----- >>From: prasadsv@condornetworks.com [mailto:prasadsv@condornetworks.com] >>Sent: Wednesday, September 13, 2006 5:11 AM >>To: dime@ietf.org >>Subject: [Dime] question on Fail-over >> >> >>Hi, >>I have a question on behavior of server at the time of Fail-over of a >>client. I will try to explain my doubt with the help of following >>scenario. >> 1. Assume that there are two diameter client Nodes, one >>configured as ACTIVE and other as STANDBY. Similarly there are two >>server >>Nodes configured. >> 2. There are some active sessions (either authorization or >>accounting) are on going between ACTIVE Client Node and ACTIVE server >>Node. >>According to RFC 3588, all the messages in these sessions will have >>Origin-Host as say, 'active.example.com' and Session-Id AVP as >>'active.example.com;XXXX;YYYY'. >> 3. While there are active sessions, suppose ACTIVE client >>Node >>goes down, and the STANDBY starts to take over the sessions and tries to >>send messages to server. >>My doubt is: >> In step 3, when STANDBY client starts handling the ACTIVE >>sessions, what will be the session-Id AVP? Will it be >>'standby.example.com;XXXX;YYYY' ,since this time messages are originated >>from the STANDBY client. or will it be the same as >>previous('active.example.com;XXXX;YYYY'). If it is first one, is it >>allowed >>at server Node? I think the server considers this as an error, since >>with in >>the same session messages with two different Session-Id AVPs are not >>allowed. If it is second one, then the Origin-Host AVP (in this case >>standby.example.com) will be different than in the host-identity portion >>of >>the session-Id AVP and I think this is not allowed according Base RFC. >>So, >>What will be behavior at server Node in this scenario. >> >> >>Any feed back/response is highly appreciated. >> >> >>Thanks >>PRASAD. >> >> >>_______________________________________________ >>DiME mailing list >>DiME@ietf.org >>https://www1.ietf.org/mailman/listinfo/dime >> >> >> >>-- >>No virus found in this incoming message. >>Checked by AVG Free Edition. >>Version: 7.1.405 / Virus Database: 268.12.3/446 - Release Date: >>9/12/2006 > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 13 14:19:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNZKz-0002mo-5G; Wed, 13 Sep 2006 14:19:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNZKy-0002mg-1N for dime@ietf.org; Wed, 13 Sep 2006 14:19:52 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNZKw-0003Gu-Ky for dime@ietf.org; Wed, 13 Sep 2006 14:19:52 -0400 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 k8DIIT0B044811; Wed, 13 Sep 2006 14:18:29 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <45084B76.7020108@tari.toshiba.com> Date: Wed, 13 Sep 2006 14:18:30 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.5 (X11/20060812) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] Error Code issues for bis References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga, Comments inline: > There already is an item related with error codes in the issue tracker > "Inconsistent Result-code Error classification". I want to bring the use of > E-bit to the lists attention as well. > > E-bit is used to indicate that the grammar will follow the definion in 7.2 . > The question is, what does qualify an error code to use that special > grammar? It looks to me, all errors defined in 7.1 can use this grammar. I > would exclude DIAMETER_AUTHENTICATION_REJECTED, > DIAMETER_AUTHORIZATION_REJECTED (and maybe also > DIAMETER_REDIRECT_INDICATION), because they are not really errors from base > protocol point of view but rather some issues on application level. For > other error codes, why do we need the full set of AVPs (except special AVPs > which may be used for routing purposes like Proxy-Info AVP)? > This maybe an easy way of performing error handling with just sending the error grammar but it maybe to harsh (??). A node receiving a result code set to some non-protocol failure value may find it more useful to receive the application specific answer message rather than just the error message in 7.2 since the error may not be grave and the both end-point application can attempt to recover and continue on. An example would be when the result code is set to MISSING_AVP or INVALID_AVP_VALUE and the answer message carries a Failed-AVP. Depending on the application, the sender of the error may choose to continue processing the remainder of the request if the offending AVP is not crucial. The receiver of the error would view the error as a hint maybe able to compensate/recover and continue on also. > This would could have a few advantages AFAICS: > i- An answer with E-bit not set needs to comply to the grammar of the > corresponding answer message definition. This may require adding some > mandatory AVPs which are part of the answer message grammar requiring > application logic involvement. With E-bit set, as soon as the decoding error > is detected, answer message can be generated. > I guess this would depend if the implementation is doing full or partial parsing in the base protocol layer. > ii- For certain error codes, which are currently listed as not using error > answer grammar, it could not be possible to further decode a message, e.g. > DIAMETER_INVALID_AVP_LENGTH generated because of an AVP, whose length field > exceeds the message boundary. With error answer message grammar, the error > answer can be generated as soon as such a case is detected. > > iii- It would be clear when and why the special error answer grammer is > used. > > > This shouldn't create backward compatibility issues, because error answers > will be validated based on the grammer indicated with persence/absence of > E-bit. > > I propose, we include that change as well as part of the bis effort. > In another note, there are also other issues with proposed text. Pls feel free to comment on the as well. best regards, victor > > Thanks, > Tolga > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 13 14:58:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNZvs-00021o-Bc; Wed, 13 Sep 2006 14:58:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNZvr-00021j-Nj for dime@ietf.org; Wed, 13 Sep 2006 14:57:59 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNZvp-00037W-FA for dime@ietf.org; Wed, 13 Sep 2006 14:57:59 -0400 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 k8DIuYht044976; Wed, 13 Sep 2006 14:56:34 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <45085463.9090401@tari.toshiba.com> Date: Wed, 13 Sep 2006 14:56:35 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.5 (X11/20060812) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Dime] Open Issues of RFC 3588bis References: <45081AE1.3000006@gmx.net> In-Reply-To: <45081AE1.3000006@gmx.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, As noted by Hannes, we have attempted to consolidate the comments for some open issues and generate proposed text based on them. These includes issues #9, 13, 24, 14 and 16. Pls feel free to comment on existing proposals or add text for those issues that have none. best regards, victor > Hi all, > > together with Victor I went through the list of open issues: > > http://www.tschofenig.priv.at:8080/diameter-interop/ > > Please take a look at them and see whether you could contribute text > to resolve the issue. You might also recognize that we closed a few > issues (look for 'done-cbb' n the status column). Furthermore, we also > included text as a resolution for some issues. > > I would also suggest not to focus on the issues grouped under > 'feature' for now. > > Ciao > Hannes > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 13 20:17:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNeuj-0006I5-45; Wed, 13 Sep 2006 20:17:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNeui-0006Hv-Iq for dime@ietf.org; Wed, 13 Sep 2006 20:17:08 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNeuh-0008RE-6o for dime@ietf.org; Wed, 13 Sep 2006 20:17:08 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 13 Sep 2006 17:17:06 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8E0H6V2019030; Wed, 13 Sep 2006 17:17:06 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k8E0H61E015355; Wed, 13 Sep 2006 17:17:06 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Sep 2006 17:17:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] question on Fail-over Date: Wed, 13 Sep 2006 17:17:02 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625029CC297@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] question on Fail-over Thread-Index: AcbXNrtlT2Xj6CmSSeym85/wrtC/+QAW24Dg From: "Glen Zorn \(gwz\)" To: X-OriginalArrivalTime: 14 Sep 2006 00:17:06.0041 (UTC) FILETIME=[1C3AAE90:01C6D793] DKIM-Signature: a=rsa-sha1; q=dns; l=2967; t=1158193026; x=1159057026; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20[Dime]=20question=20on=20Fail-over; X=v=3Dcisco.com=3B=20h=3DS81HbzESDCF46ohsi7jD+XUD7s0=3D; b=Q3Am6AHeIw+dbtxHQ4XCqjYklJSK5rme8WxgBjAfjVrBoVQNavIHQhQN1EnSTPDMiZQW20Q7 YrGCinXk7tDJwBGyxZaRH5rv6V7/fYtWX4BqxyW+IFlRhTrbXCwj07w5; Authentication-Results: sj-dkim-3.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Tolga Asveren scribbled on Wednesday, September 13, 2006 6:14 AM: > Prasad, >=20 > I would say the second one. The session-Id for a single session must > stay the same and session-Id must be globally unique. I don't see a > reason, why those principles would be violated with the second > option. =20 I don't think that this is a realistic question, nor one that Diameter fail-over was designed to deal with (unless the "client" is actually an agent). If the Diameter client is a NAS/switch/etc., presumably it has some kind of _physical_ connection to _its_ client_, so how is it supposed to "fail-over" this physical connection (unless that connection is to both Diameter clients simultaneously all the time)? >=20 > Thanks, > Tolga >=20 > -----Original Message----- > From: prasadsv@condornetworks.com [mailto:prasadsv@condornetworks.com] > Sent: Wednesday, September 13, 2006 5:11 AM > To: dime@ietf.org > Subject: [Dime] question on Fail-over >=20 >=20 > Hi, > I have a question on behavior of server at the time of Fail-over of a > client. I will try to explain my doubt with the help of following > scenario. =20 > 1. Assume that there are two diameter client Nodes, one > configured as ACTIVE and other as STANDBY. Similarly there are two > server Nodes configured. =20 > 2. There are some active sessions (either authorization or > accounting) are on going between ACTIVE Client Node and ACTIVE server > Node.=20 > According to RFC 3588, all the messages in these sessions will have > Origin-Host as say, 'active.example.com' and Session-Id AVP as > 'active.example.com;XXXX;YYYY'. =20 > 3. While there are active sessions, suppose ACTIVE client > Node goes down, and the STANDBY starts to take over the sessions and > tries to send messages to server. =20 > My doubt is: > In step 3, when STANDBY client starts handling the ACTIVE > sessions, what will be the session-Id AVP? Will it be > 'standby.example.com;XXXX;YYYY' ,since this time messages are > originated from the STANDBY client. or will it be the same as > previous('active.example.com;XXXX;YYYY'). If it is first one, is it > allowed at server Node? I think the server considers this as an > error, since with in the same session messages with two different > Session-Id AVPs are not allowed. If it is second one, then the > Origin-Host AVP (in this case standby.example.com) will be different > than in the host-identity portion of the session-Id AVP and I think > this is not allowed according Base RFC. So, What will be behavior at > server Node in this scenario. =20 >=20 >=20 > Any feed back/response is highly appreciated. >=20 >=20 > Thanks > PRASAD. >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime Hope this helps, ~gwz _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 13 23:54:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNiIm-0003fD-2H; Wed, 13 Sep 2006 23:54:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNiIk-0003et-Id for dime@ietf.org; Wed, 13 Sep 2006 23:54:10 -0400 Received: from mail12.opentransfer.com ([69.6.255.182]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GNiIi-00089v-6S for dime@ietf.org; Wed, 13 Sep 2006 23:54:10 -0400 Received: (qmail 22006 invoked by uid 399); 14 Sep 2006 03:54:02 -0000 Received: from unknown (HELO prasad) (61.95.206.132) by mail12.opentransfer.com with SMTP; 14 Sep 2006 03:54:02 -0000 From: To: "'Glen Zorn \(gwz\)'" Subject: RE: [Dime] question on Fail-over Date: Thu, 14 Sep 2006 09:23:59 +0530 Message-ID: <000001c6d7b1$6a263570$0801a8c0@prasad> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB2625029CC297@xmb-sjc-215.amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.2 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Inline... -----Original Message----- From: Glen Zorn (gwz) [mailto:gwz@cisco.com] Sent: Thursday, September 14, 2006 5:47 AM To: prasadsv@condornetworks.com Cc: dime@ietf.org; Tolga Asveren Subject: RE: [Dime] question on Fail-over Tolga Asveren scribbled on Wednesday, September 13, 2006 6:14 AM: > Prasad, > > I would say the second one. The session-Id for a single session must > stay the same and session-Id must be globally unique. I don't see a > reason, why those principles would be violated with the second > option. I don't think that this is a realistic question, nor one that Diameter fail-over was designed to deal with (unless the "client" is actually an agent). If the Diameter client is a NAS/switch/etc., presumably it has some kind of _physical_ connection to _its_ client_, so how is it supposed to "fail-over" this physical connection (unless that connection is to both Diameter clients simultaneously all the time)? [PRASAD]I agree with you that Diameter Fail-over was not designed to deal with this, but the question is not a hypothetical, and it is the real time issue we are Currently facing. What my real intention was to know how the server side implementation should behave in these kind of scenarios. The server we are currently interoperating is throwing error. Thanks Prasad. > > Thanks, > Tolga > > -----Original Message----- > From: prasadsv@condornetworks.com [mailto:prasadsv@condornetworks.com] > Sent: Wednesday, September 13, 2006 5:11 AM > To: dime@ietf.org > Subject: [Dime] question on Fail-over > > > Hi, > I have a question on behavior of server at the time of Fail-over of a > client. I will try to explain my doubt with the help of following > scenario. > 1. Assume that there are two diameter client Nodes, one > configured as ACTIVE and other as STANDBY. Similarly there are two > server Nodes configured. > 2. There are some active sessions (either authorization or > accounting) are on going between ACTIVE Client Node and ACTIVE server > Node. > According to RFC 3588, all the messages in these sessions will have > Origin-Host as say, 'active.example.com' and Session-Id AVP as > 'active.example.com;XXXX;YYYY'. > 3. While there are active sessions, suppose ACTIVE client > Node goes down, and the STANDBY starts to take over the sessions and > tries to send messages to server. > My doubt is: > In step 3, when STANDBY client starts handling the ACTIVE > sessions, what will be the session-Id AVP? Will it be > 'standby.example.com;XXXX;YYYY' ,since this time messages are > originated from the STANDBY client. or will it be the same as > previous('active.example.com;XXXX;YYYY'). If it is first one, is it > allowed at server Node? I think the server considers this as an > error, since with in the same session messages with two different > Session-Id AVPs are not allowed. If it is second one, then the > Origin-Host AVP (in this case standby.example.com) will be different > than in the host-identity portion of the session-Id AVP and I think > this is not allowed according Base RFC. So, What will be behavior at > server Node in this scenario. > > > Any feed back/response is highly appreciated. > > > Thanks > PRASAD. > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime Hope this helps, ~gwz -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.12.3/446 - Release Date: 9/12/2006 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 14 09:15:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNr4A-0003ox-DQ; Thu, 14 Sep 2006 09:15:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNr49-0003oC-Bw for dime@ietf.org; Thu, 14 Sep 2006 09:15:41 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNr46-0007IW-TK for dime@ietf.org; Thu, 14 Sep 2006 09:15:41 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 5FDDB2E3D4; Thu, 14 Sep 2006 09:15:34 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k8EDFXqv024168; Thu, 14 Sep 2006 09:15:33 -0400 (EDT) From: "Tolga Asveren" To: "Glen Zorn (gwz)" , Subject: RE: [Dime] question on Fail-over Date: Thu, 14 Sep 2006 09:14:52 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB2625029CC297@xmb-sjc-215.amer.cisco.com> Importance: Normal Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Glen, For certain application types/configurations this may not make sense but I believe there are applications where the concept is applicable. I agree with you that this behavior is not something related with Diameter base protocol failover but failover on application level. Thanks, Tolga > -----Original Message----- > From: Glen Zorn (gwz) [mailto:gwz@cisco.com] > Sent: Wednesday, September 13, 2006 8:17 PM > To: prasadsv@condornetworks.com > Cc: dime@ietf.org; Tolga Asveren > Subject: RE: [Dime] question on Fail-over > > > Tolga Asveren scribbled on Wednesday, > September 13, 2006 6:14 AM: > > > Prasad, > > > > I would say the second one. The session-Id for a single session must > > stay the same and session-Id must be globally unique. I don't see a > > reason, why those principles would be violated with the second > > option. > > I don't think that this is a realistic question, nor one that Diameter > fail-over was designed to deal with (unless the "client" is actually an > agent). If the Diameter client is a NAS/switch/etc., presumably it has > some kind of _physical_ connection to _its_ client_, so how is it > supposed to "fail-over" this physical connection (unless that connection > is to both Diameter clients simultaneously all the time)? > > > > > Thanks, > > Tolga > > > > -----Original Message----- > > From: prasadsv@condornetworks.com [mailto:prasadsv@condornetworks.com] > > Sent: Wednesday, September 13, 2006 5:11 AM > > To: dime@ietf.org > > Subject: [Dime] question on Fail-over > > > > > > Hi, > > I have a question on behavior of server at the time of Fail-over of a > > client. I will try to explain my doubt with the help of following > > scenario. > > 1. Assume that there are two diameter client Nodes, one > > configured as ACTIVE and other as STANDBY. Similarly there are two > > server Nodes configured. > > 2. There are some active sessions (either authorization or > > accounting) are on going between ACTIVE Client Node and ACTIVE server > > Node. > > According to RFC 3588, all the messages in these sessions will have > > Origin-Host as say, 'active.example.com' and Session-Id AVP as > > 'active.example.com;XXXX;YYYY'. > > 3. While there are active sessions, suppose ACTIVE client > > Node goes down, and the STANDBY starts to take over the sessions and > > tries to send messages to server. > > My doubt is: > > In step 3, when STANDBY client starts handling the ACTIVE > > sessions, what will be the session-Id AVP? Will it be > > 'standby.example.com;XXXX;YYYY' ,since this time messages are > > originated from the STANDBY client. or will it be the same as > > previous('active.example.com;XXXX;YYYY'). If it is first one, is it > > allowed at server Node? I think the server considers this as an > > error, since with in the same session messages with two different > > Session-Id AVPs are not allowed. If it is second one, then the > > Origin-Host AVP (in this case standby.example.com) will be different > > than in the host-identity portion of the session-Id AVP and I think > > this is not allowed according Base RFC. So, What will be behavior at > > server Node in this scenario. > > > > > > Any feed back/response is highly appreciated. > > > > > > Thanks > > PRASAD. > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > Hope this helps, > > ~gwz _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 14 09:26:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNrEI-0007Qj-6y; Thu, 14 Sep 2006 09:26:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNrEG-0007Qe-JM for dime@ietf.org; Thu, 14 Sep 2006 09:26:08 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNrEF-0007k7-M0 for dime@ietf.org; Thu, 14 Sep 2006 09:26:08 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 54C1F2FE6F; Thu, 14 Sep 2006 15:26:00 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1GNrGd-0001NQ-QR; Thu, 14 Sep 2006 15:28:35 +0200 Date: Thu, 14 Sep 2006 15:28:35 +0200 From: Julien Bournelle To: Yoshihiro Ohba Message-ID: <20060914132835.GA5285@ipv6-3.int-evry.fr> References: <7CCD07160348804497EF29E9EA5560D78372F8@exchtewks2.starentnetworks.com> <20060906181643.GE5241@steelhead> <20060907152211.GA27475@ipv6-3.int-evry.fr> <20060907203328.GB18410@steelhead> <20060912121400.GA2527@ipv6-3.int-evry.fr> <20060912155310.GF2857@steelhead> <20060913085255.GA4025@ipv6-3.int-evry.fr> <20060913134306.GC15246@steelhead> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060913134306.GC15246@steelhead> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 441f623df000f14368137198649cb083 Cc: dime@ietf.org Subject: [Dime] Re: Using Diameter EAP --only-- for Authentication ? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi yoshi, On Wed, Sep 13, 2006 at 09:43:06AM -0400, Yoshihiro Ohba wrote: > > > However, if the AAA server somehow needs to know about it, the HA(NAS) > > > can indicate it by including Auth-Request-Type AVP in DER with > > > specifying "AUTHENTICATE_ONLY". > > > > ok. I see. I forgot this possibility. > > So to sump up, the HA will use Diameter EAP with the Auth-Request-Type > > aVP set to AUTHENTICATE_ONLY and the App-ID set to 5. If it receives a > > success, it will switch to a Authorization/Accounting MIP6 Application > > with a new App-ID. Is that right ? > > > > I think it can work but we need to investigate a little more before > > moving with this. Points that I can see for now are: > > > > - The session-id must be shared between the Application. > > Why session-id must be shared? Indeed that's a good question. At first I thought that we should have only one-session ID per client but if we separate Authentication from Authorization/Accouting, we could have 2. > NASREQ usage for authorization purpose in RFC 4072 does not require > it. Instead, User-Name AVP can be shared between the applications. > In case the NAS(HA) is not able to retrieve the username from EAP > messages, the AAA server can tell the NAS about the username by > carrying User-Name AVP in DEA message, as described in RFC 4072. > > > - We must be sure that messages will reach the same AAA server. > > Why Diameter EAP messages and Diameter MIP6 messages need to hit the > same AAA server? > > Again, NASREQ usage for authorization purpse in RFC 4072 does not > require NASREQ and Diameter EAP messages to use the same AAA server. > In general, authentication, authorization and accouting can use > different AAA servers, and there should be no exception to MIP6 > bootstrapping, IMO. yes you're right. I guess this could be handled by 2 separate servers. Thanks for your clarifications, I understand better what you propose. regards, Julien > > > - We may have trouble with RADIUS compatibility > > This can be handled later. > > Yoshihiro Ohba > > > > > > Anyone has an opinion on this way to solve our issue ? > > > > Thanks yoshi, > > > > Julien > > > > > > > > > > > > > If we "push" a little what you propose, we could define an > > > > "Authentication based on EAP" Application (only doing Authentication) > > > > used by other Application that would only define their messages for > > > > Authorization and Accounting (such as MIP6). That's why I talked to you > > > > in a previous mail about also consider network access as a special > > > > service and thus define Authz/Accounting messages for the "network > > > > access" service. > > > > > > Yes, in the case of network access, you could use NASREQ for > > > authorization purpose in additon to Diameter EAP for authentication > > > purpose as specified in RFC 4072. > > > > > > Regards, > > > Yoshihiro Ohba > > > > > > > > > > > > > > regards, > > > > > > > > Julien > > > > > > > > > > > > > > Regards, > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > > I also agree with Avi that defining a new application for MIP6 > > > > > > > bootstrapping on top of existing applications (Diameter EAP) without > > > > > > > defining a new application id but with defining new values for > > > > > > > existing AVPs or new optional AVPs has some issue, but this option > > > > > > > might not be as bad as the first option since backward compatibility > > > > > > > can be easily maintained unlike the first option. However, there is a > > > > > > > forward compatibility problem (i.e., a Diameter message may be forwarded > > > > > > > to a AAA server that does not support the new application). Besides > > > > > > > this problem, it might be worth pursuing this option because it works > > > > > > > in an optimized way (i.e., bootstrapping AVPs are piggybacked in > > > > > > > Diameter EAP or NASREQ message) as long as both NAS and AAA server > > > > > > > support the AVPs. > > > > > > > > > > > > I'm not in favor of having an app-id for the nas-aaah part of the mip6 > > > > > > bootstrapping problem. > > > > > > > > > > > > > > > > > > > > In order to deal with the forward compatibility problem of the second > > > > > > > option, a third option is to define a new application for MIP6 > > > > > > > bootstrapping as a totally new authorization application that carries > > > > > > > new mandatory AVPs specific to that application. This option can be > > > > > > > run when execution of the second option succeeds in authentication but > > > > > > > fails in carrying bootstrapping AVPs. > > > > > > > > > > > > hmm, i guess i have to think more of this option but this would mandate > > > > > > now that all EAP Application server should know that maybe they are not > > > > > > doing this for network access and that maybe they are going to receive > > > > > > a special authorization request. And in this case, wouldn't it mean > > > > > > that network access should be treated as a special service and this > > > > > > would also require a new authorization application ? > > > > > > > > > > > > regards, > > > > > > > > > > > > Julien > > > > > > > > > > > > > > Regards, > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Sep 05, 2006 at 11:21:22PM -0400, Avi Lior wrote: > > > > > > > > Hi Kuntal, > > > > > > > > > > > > > > > > Neither option 1 or option 2 will work. A new application id just wont > > > > > > > > scale in the long run. What if another 'capability' were to be added > > > > > > > > for instance prepaid. Since Diameter messages contain only one > > > > > > > > Application ID, you would have to create an Application Id that covered > > > > > > > > both EAP, Prepaid and Mobile IP. And what if a third application were > > > > > > > > added? The approach is not scalable as the applications are increased > > > > > > > > -- you would have to cope with all the different permutations of > > > > > > > > Applications. The same argument goes for ServiceType and PortType and > > > > > > > > these are actually more problematic. > > > > > > > > > > > > > > > > IMO the only thing we can do is to hint at the capability of the NAS. > > > > > > > > > > > > > > > > A proper solution should be concieved for this problem. > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > > > > > > > > Sent: Tuesday, September 05, 2006 2:09 PM > > > > > > > > > To: Avi Lior; Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > > > > > > > > Cc: dime@ietf.org > > > > > > > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > > > Service-Type > > > > > > > > > > > > > > > > > > All, > > > > > > > > > > > > > > > > > > Here is a scenario that may need to be covered. In some > > > > > > > > > cases, local HA assignment is optimal for transport > > > > > > > > > efficiency perspective. Diameter > > > > > > > > > MIP4 application allows this. In such a case the ASP == MSP > > > > > > > > > and the HA is assigned locally (in the visited network). > > > > > > > > > > > > > > > > > > To enable this case, in the integrated scenario, the NAS/VAAA > > > > > > > > > needs to indicate it's capability to assign an HA in the > > > > > > > > > local network to the HAAA. The HAAA may allow or disallow > > > > > > > > > this local HA assignment based on policy of the MSA. > > > > > > > > > > > > > > > > > > The NAS/VAAA may need to include a hint in the AAA message to > > > > > > > > > the HAAA at the time of access authentication that it is > > > > > > > > > capable of providing an HA to the MN. This capability > > > > > > > > > indication (hint) can be either sent via a new MIP6 specific > > > > > > > > > AVP or it can be conveyed via an existing AVP (I don't know > > > > > > > > > if one exists). > > > > > > > > > > > > > > > > > > If we decide to include this (local HA assignment), and we > > > > > > > > > decide to include this mip6 specific hint in the NAS-HAAA > > > > > > > > > communication, we may have to choose the most appropriate > > > > > > > > > option (1) vs. (2). > > > > > > > > > > > > > > > > > > Comments? > > > > > > > > > > > > > > > > > > -Kuntal > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > > > > > > > > Sent: Tuesday, September 05, 2006 6:07 AM > > > > > > > > > > To: Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > > > > > > > > > Cc: dime@ietf.org > > > > > > > > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > > > Service-Type > > > > > > > > > > > > > > > > > > > > I must be missing something. > > > > > > > > > > > > > > > > > > > > In the integrated scenario, what would the NAS put in Service-Type? > > > > > > > > > > > > > > > > > > > > I think in the integrated scenario neither Port-Type or > > > > > > > > > Service-Type > > > > > > > > > > needs to be touched. > > > > > > > > > > > > > > > > > > > > As far as I understand the NAS is either executing EAP > > > > > > > > > Application or > > > > > > > > > > NAS REQ. It does not know whether the user will result in having > > > > > > > > > > subsequent Mobile IP service or not. > > > > > > > > > > > > > > > > > > > > The only thing the AAA server can do is to send the MIPv6 attributes > > > > > > > > > as > > > > > > > > > > optional (M bit off) and hope that if the NAS does not > > > > > > > > > understand the > > > > > > > > > > attributes it would have some logic to bootstrap a different way. > > > > > > > > > > > > > > > > > > > > We could improve the situration somewhat. We could have the NAS > > > > > > > > > > indicate that it supports MIPv6 bootstrapping by including hints in > > > > > > > > > the > > > > > > > > > > AR (a capability hint). Where the NAS includes HA-IP address AVP > > > > > > > > > both > > > > > > > > > > indicating that it can support bootstrapping and if the > > > > > > > > > HA-IP address > > > > > > > > > is > > > > > > > > > > not ALL-ZEROS or ALL ONES it provides a hint that it can support > > > > > > > > > dynamic > > > > > > > > > > HA assignement. > > > > > > > > > > > > > > > > > > > > Ofcourse we could introduce the concept of capability hints more > > > > > > > > > > formally in Diameter -- This is missing today. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > > > > > > > > > > Sent: Tuesday, September 05, 2006 3:35 AM > > > > > > > > > > > To: Hannes.Tschofenig@gmx.net > > > > > > > > > > > Cc: dime@ietf.org > > > > > > > > > > > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > > > > > Service-Type > > > > > > > > > > > > > > > > > > > > > > Hi Hannes, > > > > > > > > > > > > > > > > > > > > > > I agree with Jouni. I prefer (2) for NAS-AAAH and (1) for > > > > > > > > > AAAH-HA. > > > > > > > > > > > In my understanding, there are no mandatory AVPs for NAS-AAAH and > > > > > > > > > > > therefore I don't see a need of a new application; it's just a > > > > > > > > > > > MIP-specific information that is piggybacked in the > > > > > > > > > network access > > > > > > > > > > > authentication procedure. > > > > > > > > > > > > > > > > > > > > > > Concerning AAAH-HA, I think it is a much cleaner approach > > > > > > > > > to define > > > > > > > > > > > a new application, since it does not anything to do with network > > > > > > > > > > > authentication. > > > > > > > > > > > > > > > > > > > > > > --Gerardo > > > > > > > > > > > > > > > > > > > > > > On 9/5/06, jouni.korhonen@teliasonera.com > > > > > > > > > > > wrote: > > > > > > > > > > > > Hi HAnnes, > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > > > > > > > > > > Sent: 1. syyskuuta 2006 1:07 > > > > > > > > > > > > > To: dime@ietf.org > > > > > > > > > > > > > Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > > > > > > > Service-Type > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > we have had long discussions about the App-ID vs. > > > > > > > > > > > > > Service-Type usage for > > > > > > > > > > > > > Diameter MIPv6 Bootstrapping. > > > > > > > > > > > > > > > > > > > > > > > > > > It is time to see what the group thinks. Please indicate > > > > > > > > > > > whether you > > > > > > > > > > > > > prefer (1) an App-ID or (2) a Service-Type solution for > > > > > > > > > > > > > > > > > > > > > > > > > > (a) NAS-to-AAAH communication (as required by the integrated > > > > > > > > > > > > > scenario; as one part of the solution component) > > > > > > > > > > > > > > > > > > > > > > > > I would prefer (2) for now.. or as long as the NAS-2-AAAH main > > > > > > > > > > > > function is to provide access authentication, where the backend > > > > > > > > > AAA > > > > > > > > > > > > may return > > > > > > > > > > > > MIP6 > > > > > > > > > > > > bootstrapping info (as an enhancement) based e.g. on the user > > > > > > > > > > > > subscription profile. If we go for more stuff on > > > > > > > > > NAS-2-AAAH like > > > > > > > > > > > > HoA/prefix etc then > > > > > > > > > > > > (1) > > > > > > > > > > > > might be better. > > > > > > > > > > > > > > > > > > > > > > > > > (b) HA-to-AAAH communication (as used by the split > > > > > > > > > > > scenario and the > > > > > > > > > > > > > integrated scenario) > > > > > > > > > > > > > > > > > > > > > > > > I would prefer (1) here. The use of EAP for MIP6 bootstrapping > > > > > > > > > > > > purposes and for 'normal' EAP-based access authentication are > > > > > > > > > > > > different applications imho. (although in IKEv2 vs 802.1X case > > > > > > > > > e.g. > > > > > > > > > > > > NAS-Port-Type could be used to make this distinction.. e.g. > > > > > > > > > > > how 3GPP > > > > > > > > > > > > WLAN stuff does it) > > > > > > > > > > > > > > > > > > > > > > > > > It might be useful to state a reason for your decision. > > > > > > > > > > > > > > > > > > > > > > > > > > Please also indicate whether some aspects are still > > > > > > > > > > > unclear to you. > > > > > > > > > > > > > > > > > > > > > > > > > > Ciao > > > > > > > > > > > > > Hannes > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Jouni > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > DiME mailing list > > > > > > > > > > > > > DiME@ietf.org > > > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > DiME mailing list > > > > > > > > > > > > DiME@ietf.org > > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > DiME mailing list > > > > > > > > > > > DiME@ietf.org > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > DiME mailing list > > > > > > > > > > DiME@ietf.org > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > > > "This email message and any attachments are confidential > > > > > > > > > information of Starent Networks, Corp. The information > > > > > > > > > transmitted may not be used to create or change any > > > > > > > > > contractual obligations of Starent Networks, Corp. Any > > > > > > > > > review, retransmission, dissemination or other use of, or > > > > > > > > > taking of any action in reliance upon this e-mail and its > > > > > > > > > attachments by persons or entities other than the intended > > > > > > > > > recipient is prohibited. If you are not the intended > > > > > > > > > recipient, please notify the sender immediately -- by > > > > > > > > > replying to this message or by sending an email to > > > > > > > > > postmaster@starentnetworks.com -- and destroy all copies of > > > > > > > > > this message and any attachments without reading or > > > > > > > > > disclosing their contents. Thank you." > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > DiME mailing list > > > > > > > > DiME@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > DiME mailing list > > > > > > > DiME@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > -- > > > > > > julien.bournelle at int-evry.fr > > > > > > > > > > > > > > -- > > > > julien.bournelle at int-evry.fr > > > > > > > > -- > > julien.bournelle at int-evry.fr > > -- julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 14 09:56:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNrhs-0001l1-WB; Thu, 14 Sep 2006 09:56:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNrhr-0001kw-Ff for dime@ietf.org; Thu, 14 Sep 2006 09:56:43 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNrhp-0001NE-HP for dime@ietf.org; Thu, 14 Sep 2006 09:56:43 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 832EB1D077; Thu, 14 Sep 2006 09:56:40 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k8EDuUTk027901; Thu, 14 Sep 2006 09:56:39 -0400 (EDT) From: "Tolga Asveren" To: "Victor Fajardo" Subject: RE: [Dime] Error Code issues for bis Date: Thu, 14 Sep 2006 09:55:50 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-Reply-To: <45084B76.7020108@tari.toshiba.com> Importance: Normal Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Victor, > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Wednesday, September 13, 2006 2:19 PM > To: Tolga Asveren > Cc: dime@ietf.org > Subject: Re: [Dime] Error Code issues for bis > > > Hi Tolga, > > Comments inline: > > There already is an item related with error codes in the issue tracker > > "Inconsistent Result-code Error classification". I want to > bring the use of > > E-bit to the lists attention as well. > > > > E-bit is used to indicate that the grammar will follow the > definion in 7.2 . > > The question is, what does qualify an error code to use that special > > grammar? It looks to me, all errors defined in 7.1 can use this > grammar. I > > would exclude DIAMETER_AUTHENTICATION_REJECTED, > > DIAMETER_AUTHORIZATION_REJECTED (and maybe also > > DIAMETER_REDIRECT_INDICATION), because they are not really > errors from base > > protocol point of view but rather some issues on application level. For > > other error codes, why do we need the full set of AVPs (except > special AVPs > > which may be used for routing purposes like Proxy-Info AVP)? > > > > This maybe an easy way of performing error handling with just sending > the error grammar but it maybe to harsh (??). A node receiving a result > code set to some non-protocol failure value may find it more useful to > receive the application specific answer message rather than just the > error message in 7.2 since the error may not be grave and the both > end-point application can attempt to recover and continue on. An example > would be when the result code is set to MISSING_AVP or INVALID_AVP_VALUE > and the answer message carries a Failed-AVP. Depending on the > application, the sender of the error may choose to continue processing > the remainder of the request if the offending AVP is not crucial. The > receiver of the error would view the error as a hint maybe able to > compensate/recover and continue on also. [TOLGA]This is an interesting point but if such an answer is generated, how could the peer know the real result of the request processing? Let's say Result-Code contains MISSING_AVP, how could the request originator determine whether the request processing is done successfully? I also would exptect if the request can be processed without an AVP, that AVP shouldn't be listed as a mandatory AVP. Similarly for other error situations, if they don't prevent request processing, they shouldn't be errors. > > > > This would could have a few advantages AFAICS: > > i- An answer with E-bit not set needs to comply to the grammar of the > > corresponding answer message definition. This may require adding some > > mandatory AVPs which are part of the answer message grammar requiring > > application logic involvement. With E-bit set, as soon as the > decoding error > > is detected, answer message can be generated. > > > > I guess this would depend if the implementation is doing full or partial > parsing in the base protocol layer. [TOLGA]I think I was not clear about this one. The message is parsed (or parsed as much as possible depending the type of the error). Now an answer message needs to be generated. If the grammar of the answer for that specific command code is used, all mandatory AVPs which are specified in the grammar need to be present. Those AVPs possibly could be filled without application logic involvement, but I would think this would require to put some dummy values there. In such a case, what is the point of inserting them? > > > ii- For certain error codes, which are currently listed as > not using error > > answer grammar, it could not be possible to further decode a > message, e.g. > > DIAMETER_INVALID_AVP_LENGTH generated because of an AVP, whose > length field > > exceeds the message boundary. With error answer message > grammar, the error > > answer can be generated as soon as such a case is detected. > > > > iii- It would be clear when and why the special error answer grammer is > > used. > > > > > > This shouldn't create backward compatibility issues, because > error answers > > will be validated based on the grammer indicated with > persence/absence of > > E-bit. > > > > I propose, we include that change as well as part of the bis effort. > > > > In another note, there are also other issues with proposed text. Pls > feel free to comment on the as well. > > best regards, > victor > > > > > > Thanks, > > Tolga > > > > > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 14 10:18:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNs37-0002kG-Al; Thu, 14 Sep 2006 10:18:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNs36-0002kA-H9 for dime@ietf.org; Thu, 14 Sep 2006 10:18:40 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNs31-0003xH-3P for dime@ietf.org; Thu, 14 Sep 2006 10:18:40 -0400 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 k8EEHAwL048680; Thu, 14 Sep 2006 10:17:11 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <45096467.5050601@tari.toshiba.com> Date: Thu, 14 Sep 2006 10:17:11 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.5 (X11/20060812) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] Error Code issues for bis References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga, Comments inline: >>> >> This maybe an easy way of performing error handling with just sending >> the error grammar but it maybe to harsh (??). A node receiving a result >> code set to some non-protocol failure value may find it more useful to >> receive the application specific answer message rather than just the >> error message in 7.2 since the error may not be grave and the both >> end-point application can attempt to recover and continue on. An example >> would be when the result code is set to MISSING_AVP or INVALID_AVP_VALUE >> and the answer message carries a Failed-AVP. Depending on the >> application, the sender of the error may choose to continue processing >> the remainder of the request if the offending AVP is not crucial. The >> receiver of the error would view the error as a hint maybe able to >> compensate/recover and continue on also. >> > [TOLGA]This is an interesting point but if such an answer is generated, how > could the peer know the real result of the request processing? Let's say > Result-Code contains MISSING_AVP, how could the request originator determine > whether the request processing is done successfully? I was thinking through other avp's in the application specific answer grammar ... though that maybe stretching the success/failure significance of the result-code avp against other avps in the message so may not as advisable. >> I guess this would depend if the implementation is doing full or partial >> parsing in the base protocol layer. >> > [TOLGA]I think I was not clear about this one. The message is parsed (or > parsed as much as possible depending the type of the error). Now an answer > message needs to be generated. If the grammar of the answer for that > specific command code is used, all mandatory AVPs which are specified in the > grammar need to be present. Those AVPs possibly could be filled without > application logic involvement, but I would think this would require to put > some dummy values there. In such a case, what is the point of inserting > them? > I was thinking in the case where the base protocol part of the implementation does only partial parsing of message header and avps it requires and leaves full parsing of the remaining application specific avps to the applications themselves. The scenario you mentioned fits well when the failure occurs during the partial parsing. During full parsing, application logic can be introduced. best regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 14 14:15:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNvk7-0000Bo-Et; Thu, 14 Sep 2006 14:15:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNvk6-0000Bj-EX for dime@ietf.org; Thu, 14 Sep 2006 14:15:18 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNvk5-000192-3L for dime@ietf.org; Thu, 14 Sep 2006 14:15:18 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 3929674970 for ; Thu, 14 Sep 2006 14:15:12 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k8EIFBNT022868 for ; Thu, 14 Sep 2006 14:15:11 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Dime] Error Code issues for bis Date: Thu, 14 Sep 2006 14:14:29 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-Reply-To: <45096467.5050601@tari.toshiba.com> Importance: Normal Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Victor, I had a look to Issue14. I already thought that use of E-bit is exclusively for protocol errors based on "Note that these and only these erors MUST only be used in answer messages whose 'E' bit is set." in 7.1.3. The proposed text further supports this idea. I see a value of using E-bit for permanent failures as I tried to explain before. I think your concern is that people may choose not to use error answer-message grammar defined in 7.2 for certain permanent failures. To address both concerns, I suggest we allow use of E-bit for permanent failures but leave it as an implementation choice to use it or not. This again would be backward compatible AFAICS. Thanks, Tolga > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Thursday, September 14, 2006 10:17 AM > To: Tolga Asveren > Cc: dime@ietf.org > Subject: Re: [Dime] Error Code issues for bis > > > Hi Tolga, > > Comments inline: > >>> > >> This maybe an easy way of performing error handling with just sending > >> the error grammar but it maybe to harsh (??). A node receiving a result > >> code set to some non-protocol failure value may find it more useful to > >> receive the application specific answer message rather than just the > >> error message in 7.2 since the error may not be grave and the both > >> end-point application can attempt to recover and continue on. > An example > >> would be when the result code is set to MISSING_AVP or > INVALID_AVP_VALUE > >> and the answer message carries a Failed-AVP. Depending on the > >> application, the sender of the error may choose to continue processing > >> the remainder of the request if the offending AVP is not crucial. The > >> receiver of the error would view the error as a hint maybe able to > >> compensate/recover and continue on also. > >> > > [TOLGA]This is an interesting point but if such an answer is > generated, how > > could the peer know the real result of the request processing? Let's say > > Result-Code contains MISSING_AVP, how could the request > originator determine > > whether the request processing is done successfully? > > I was thinking through other avp's in the application specific answer > grammar ... though that maybe stretching the success/failure > significance of the result-code avp against other avps in the message so > may not as advisable. > > >> I guess this would depend if the implementation is doing full > or partial > >> parsing in the base protocol layer. > >> > > [TOLGA]I think I was not clear about this one. The message is parsed (or > > parsed as much as possible depending the type of the error). > Now an answer > > message needs to be generated. If the grammar of the answer for that > > specific command code is used, all mandatory AVPs which are > specified in the > > grammar need to be present. Those AVPs possibly could be filled without > > application logic involvement, but I would think this would > require to put > > some dummy values there. In such a case, what is the point of inserting > > them? > > > > I was thinking in the case where the base protocol part of the > implementation does only partial parsing of message header and avps it > requires and leaves full parsing of the remaining application specific > avps to the applications themselves. The scenario you mentioned fits > well when the failure occurs during the partial parsing. During full > parsing, application logic can be introduced. > > best regards, > victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 14 14:42:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNwAE-0005HT-Nv; Thu, 14 Sep 2006 14:42:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNwAD-0005HO-VG for dime@ietf.org; Thu, 14 Sep 2006 14:42:17 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNwAA-0005yE-Ge for dime@ietf.org; Thu, 14 Sep 2006 14:42:17 -0400 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 k8EIerZY050088; Thu, 14 Sep 2006 14:40:53 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <4509A235.4000902@tari.toshiba.com> Date: Thu, 14 Sep 2006 14:40:53 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.5 (X11/20060812) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] Error Code issues for bis References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga, > I had a look to Issue14. I already thought that use of E-bit is exclusively > for protocol errors based on "Note that these and only these erors MUST only > be used in answer messages whose 'E' bit is set." in 7.1.3. The proposed > text further supports this idea. > Yes. I can't remember precisely but #14 may have been on of those "editorial" issue that was brought up during the interop. > I see a value of using E-bit for permanent failures as I tried to explain > before. I think your concern is that people may choose not to use error > answer-message grammar defined in 7.2 for certain permanent failures. To > address both concerns, I suggest we allow use of E-bit for permanent > failures but leave it as an implementation choice to use it or not. This > again would be backward compatible AFAICS. > Ok. Hopefully, we can try to get more feedback on this topic. best regards, victor > Thanks, > Tolga > > > > >> -----Original Message----- >> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >> Sent: Thursday, September 14, 2006 10:17 AM >> To: Tolga Asveren >> Cc: dime@ietf.org >> Subject: Re: [Dime] Error Code issues for bis >> >> >> Hi Tolga, >> >> Comments inline: >> >>>> This maybe an easy way of performing error handling with just sending >>>> the error grammar but it maybe to harsh (??). A node receiving a result >>>> code set to some non-protocol failure value may find it more useful to >>>> receive the application specific answer message rather than just the >>>> error message in 7.2 since the error may not be grave and the both >>>> end-point application can attempt to recover and continue on. >>>> >> An example >> >>>> would be when the result code is set to MISSING_AVP or >>>> >> INVALID_AVP_VALUE >> >>>> and the answer message carries a Failed-AVP. Depending on the >>>> application, the sender of the error may choose to continue processing >>>> the remainder of the request if the offending AVP is not crucial. The >>>> receiver of the error would view the error as a hint maybe able to >>>> compensate/recover and continue on also. >>>> >>>> >>> [TOLGA]This is an interesting point but if such an answer is >>> >> generated, how >> >>> could the peer know the real result of the request processing? Let's say >>> Result-Code contains MISSING_AVP, how could the request >>> >> originator determine >> >>> whether the request processing is done successfully? >>> >> I was thinking through other avp's in the application specific answer >> grammar ... though that maybe stretching the success/failure >> significance of the result-code avp against other avps in the message so >> may not as advisable. >> >> >>>> I guess this would depend if the implementation is doing full >>>> >> or partial >> >>>> parsing in the base protocol layer. >>>> >>>> >>> [TOLGA]I think I was not clear about this one. The message is parsed (or >>> parsed as much as possible depending the type of the error). >>> >> Now an answer >> >>> message needs to be generated. If the grammar of the answer for that >>> specific command code is used, all mandatory AVPs which are >>> >> specified in the >> >>> grammar need to be present. Those AVPs possibly could be filled without >>> application logic involvement, but I would think this would >>> >> require to put >> >>> some dummy values there. In such a case, what is the point of inserting >>> them? >>> >>> >> I was thinking in the case where the base protocol part of the >> implementation does only partial parsing of message header and avps it >> requires and leaves full parsing of the remaining application specific >> avps to the applications themselves. The scenario you mentioned fits >> well when the failure occurs during the partial parsing. During full >> parsing, application logic can be introduced. >> >> best regards, >> victor >> > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 14 18:27:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNzfg-0002gY-2D; Thu, 14 Sep 2006 18:27:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNzfe-0002g9-LV; Thu, 14 Sep 2006 18:26:58 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNzfd-0000ON-DN; Thu, 14 Sep 2006 18:26:58 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J5L002TJSVQCK@usaga01-in.huawei.com>; Thu, 14 Sep 2006 15:23:50 -0700 (PDT) Received: from Nakhjiri73701 (pool-71-112-12-134.sttlwa.dsl-w.verizon.net [71.112.12.134]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J5L00H8GSVL8X@usaga01-in.huawei.com>; Thu, 14 Sep 2006 15:23:50 -0700 (PDT) Date: Thu, 14 Sep 2006 15:26:49 -0700 From: Madjid Nakhjiri In-reply-to: To: mip6@ietf.org Message-id: <00b401c6d84c$df637870$2f01a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcbWp/9vCD8b8y9yT+G/Kq12lEfX5wBodXag X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: dime@ietf.org Subject: [Dime] Acronym MSA in MIP6 docs is unfortunate!! X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Sorry for chiming in so late: The term "Mobility Security Association" is used heavily in Mobile IPv4 security and AAA interaction documentation: MIPv4 base spec 3344 MIPv4 AAA key management 3957, Diameter MIPv4, 4004 Draft-nakhjiri-radius-mip4-02 Furthermore, Diameter spec (4004) uses the acronym MSA to refer to these security association and uses "MSA" in naming a large number of AVPs for Mobile IPv4 application. We followed the same terminology for defining RADIUS attributes in the radius-mip4 draft. It is unfortunate that MIP6 WG has picked MSA as an acronym for "Mobility service authorizer". As the work on bootstrapping MIP6 in Dime picks up, there will be more and more confusion as people try to define AVPs to address the security associations. Please replace the acronym for "Mobility service authorizer". Thanks, Madjid Nakhjiri _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 14 23:34:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO4Sr-00017A-Ie; Thu, 14 Sep 2006 23:34:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO4Sq-000172-OK for dime@ietf.org; Thu, 14 Sep 2006 23:34:04 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GO4Sp-0001hg-7H for dime@ietf.org; Thu, 14 Sep 2006 23:34:04 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k8F3XseJ029366; Fri, 15 Sep 2006 06:34:02 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Sep 2006 06:34:01 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Sep 2006 06:34:01 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Error Code issues for bis Date: Fri, 15 Sep 2006 06:33:59 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Error Code issues for bis Thread-Index: AcbYKebk0hy6URabTBO0O1slItegBwATbuag From: To: , X-OriginalArrivalTime: 15 Sep 2006 03:34:01.0284 (UTC) FILETIME=[C9137040:01C6D877] X-Spam-Score: 0.2 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Tolga, If it is optional, that means you can't count that any implementations will support it. However, are you suggesting the E-bit could be used as a hint for=20 permantant failures? John=20 >-----Original Message----- >From: ext Tolga Asveren [mailto:asveren@ulticom.com]=20 >Sent: 14 September, 2006 21:14 >To: dime@ietf.org >Subject: RE: [Dime] Error Code issues for bis > >Hi Victor, > >I had a look to Issue14. I already thought that use of E-bit=20 >is exclusively for protocol errors based on "Note that these=20 >and only these erors MUST only be used in answer messages=20 >whose 'E' bit is set." in 7.1.3. The proposed text further=20 >supports this idea. > >I see a value of using E-bit for permanent failures as I tried=20 >to explain before. I think your concern is that people may=20 >choose not to use error answer-message grammar defined in 7.2=20 >for certain permanent failures. To address both concerns, I=20 >suggest we allow use of E-bit for permanent failures but leave=20 >it as an implementation choice to use it or not. This again=20 >would be backward compatible AFAICS. > > Thanks, > Tolga > > > >> -----Original Message----- >> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >> Sent: Thursday, September 14, 2006 10:17 AM >> To: Tolga Asveren >> Cc: dime@ietf.org >> Subject: Re: [Dime] Error Code issues for bis >> >> >> Hi Tolga, >> >> Comments inline: >> >>> >> >> This maybe an easy way of performing error handling with just=20 >> >> sending the error grammar but it maybe to harsh (??). A node=20 >> >> receiving a result code set to some non-protocol failure=20 >value may=20 >> >> find it more useful to receive the application specific answer=20 >> >> message rather than just the error message in 7.2 since the error=20 >> >> may not be grave and the both end-point application can=20 >attempt to recover and continue on. >> An example >> >> would be when the result code is set to MISSING_AVP or >> INVALID_AVP_VALUE >> >> and the answer message carries a Failed-AVP. Depending on the=20 >> >> application, the sender of the error may choose to continue=20 >> >> processing the remainder of the request if the offending=20 >AVP is not=20 >> >> crucial. The receiver of the error would view the error as a hint=20 >> >> maybe able to compensate/recover and continue on also. >> >> >> > [TOLGA]This is an interesting point but if such an answer is >> generated, how >> > could the peer know the real result of the request=20 >processing? Let's=20 >> > say Result-Code contains MISSING_AVP, how could the request >> originator determine >> > whether the request processing is done successfully? >> >> I was thinking through other avp's in the application=20 >specific answer=20 >> grammar ... though that maybe stretching the success/failure=20 >> significance of the result-code avp against other avps in=20 >the message=20 >> so may not as advisable. >> >> >> I guess this would depend if the implementation is doing full >> or partial >> >> parsing in the base protocol layer. >> >> >> > [TOLGA]I think I was not clear about this one. The message=20 >is parsed=20 >> > (or parsed as much as possible depending the type of the error). >> Now an answer >> > message needs to be generated. If the grammar of the=20 >answer for that=20 >> > specific command code is used, all mandatory AVPs which are >> specified in the >> > grammar need to be present. Those AVPs possibly could be filled=20 >> > without application logic involvement, but I would think this would >> require to put >> > some dummy values there. In such a case, what is the point of=20 >> > inserting them? >> > >> >> I was thinking in the case where the base protocol part of the=20 >> implementation does only partial parsing of message header=20 >and avps it=20 >> requires and leaves full parsing of the remaining=20 >application specific=20 >> avps to the applications themselves. The scenario you mentioned fits=20 >> well when the failure occurs during the partial parsing. During full=20 >> parsing, application logic can be introduced. >> >> best regards, >> victor > > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Sep 15 04:55:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO9U8-0003z3-2S; Fri, 15 Sep 2006 04:55:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO9U7-0003yy-5S for dime@ietf.org; Fri, 15 Sep 2006 04:55:43 -0400 Received: from jaguar.hughesbpo.net ([61.246.186.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GO9Ty-0008Kh-7Q for dime@ietf.org; Fri, 15 Sep 2006 04:55:43 -0400 Received: from jaguar.hughesbpo.net (localhost [127.0.0.1]) by jaguar.hughesbpo.net (8.13.6/8.12.10) with ESMTP id k8F8v5Mi022346 for ; Fri, 15 Sep 2006 14:27:05 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by jaguar.hughesbpo.net (8.13.6/8.13.6) with ESMTP id k8F8uv42022316 for ; Fri, 15 Sep 2006 14:27:00 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id k8F8u1K10097 for ; Fri, 15 Sep 2006 14:26:03 +0530 (IST) Sensitivity: To: X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Preeti Shandilya Date: Fri, 15 Sep 2006 14:24:06 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 09/15/2006 14:25:04 MIME-Version: 1.0 X-Spam-Score: 2.0 (++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Dime] Question of TCP and SCTP simultaneoous support in Diameter X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 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="===============0191352595==" Errors-To: dime-bounces@ietf.org --===============0191352595== Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Hi !

I have question regarding the compliance of s product with RFC 3588.

If a diameter stack product complying to RFC 3588 does not support TCP and SCTP simultaneously, will that be considered as noncompliance.
At some place RFC speaks that TCP and SCTP support is mandatory but at some place it indicates that support of TCP and SCTP support simultaneously is optional

Early reply is appreciated.

Regards
Preeti
***************** FSS-Unclassified *************
"DISCLAIMER: This message is proprietary to Flextronics Software
Systems Limited (FSS) and is intended solely for the use of the
individual to whom it is addressed. It may contain privileged or
confidential information and should not be circulated or used for
any purpose other than for what it is intended. If you have received
this message in error, please notify the originator immediately.
If you are not the intended recipient, you are notified that you are
strictly prohibited from using, copying, altering, or disclosing
the contents of this message. FSS accepts no responsibility for
loss or damage arising from the use of the information transmitted
by this email including damage from virus." --===============0191352595== 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://www1.ietf.org/mailman/listinfo/dime --===============0191352595==-- From dime-bounces@ietf.org Fri Sep 15 05:28:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO9zY-0005hz-QC; Fri, 15 Sep 2006 05:28:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO9zX-0005ht-JM for dime@ietf.org; Fri, 15 Sep 2006 05:28:11 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GO9zW-0003DO-Kp for dime@ietf.org; Fri, 15 Sep 2006 05:28:11 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id E60E22FDF5; Fri, 15 Sep 2006 11:27:59 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1GOA1q-0001e9-9e; Fri, 15 Sep 2006 11:30:34 +0200 Date: Fri, 15 Sep 2006 11:30:34 +0200 From: Julien Bournelle To: Yoshihiro Ohba Message-ID: <20060915093034.GA6298@ipv6-3.int-evry.fr> References: <7CCD07160348804497EF29E9EA5560D78372F8@exchtewks2.starentnetworks.com> <20060906181643.GE5241@steelhead> <20060907152211.GA27475@ipv6-3.int-evry.fr> <20060907203328.GB18410@steelhead> <20060912121400.GA2527@ipv6-3.int-evry.fr> <20060912155310.GF2857@steelhead> <20060913085255.GA4025@ipv6-3.int-evry.fr> <20060913134306.GC15246@steelhead> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060913134306.GC15246@steelhead> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3d702b63698072ba67a75ce9e0fc9e Cc: dime@ietf.org Subject: [Dime] Authentication through 2 different "NAS" in the same time ? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi yoshi, I have one more question concerning your approach. Considering the following scenario: MN <------> NAS <---4072 -(1)---> AAAH ^ ^ | | +----------> HA <---4072 (2)------+ First, the MN is authenticated throught the NAS. The NAS uses Diameter EAP and asks the AAAH for AAA for network access. Then, the MN acquires the HA and uses IKEv2 with it. If we use your approach, the HA uses Diameter EAP with the AVP Auth-Request-Type set to AUTHENTICATE_ONLY. I was wondering if it won't cause trouble to the AAAH since it has already authenticated the MN through the NAS. Any comments on this ? regards, Julien On Wed, Sep 13, 2006 at 09:43:06AM -0400, Yoshihiro Ohba wrote: > Hi Julien, > > On Wed, Sep 13, 2006 at 10:52:55AM +0200, Julien Bournelle wrote: > > (snip) > > > > > > However, if the AAA server somehow needs to know about it, the HA(NAS) > > > can indicate it by including Auth-Request-Type AVP in DER with > > > specifying "AUTHENTICATE_ONLY". > > > > ok. I see. I forgot this possibility. > > So to sump up, the HA will use Diameter EAP with the Auth-Request-Type > > aVP set to AUTHENTICATE_ONLY and the App-ID set to 5. If it receives a > > success, it will switch to a Authorization/Accounting MIP6 Application > > with a new App-ID. Is that right ? > > > > I think it can work but we need to investigate a little more before > > moving with this. Points that I can see for now are: > > > > - The session-id must be shared between the Application. > > Why session-id must be shared? > > NASREQ usage for authorization purpose in RFC 4072 does not require > it. Instead, User-Name AVP can be shared between the applications. > In case the NAS(HA) is not able to retrieve the username from EAP > messages, the AAA server can tell the NAS about the username by > carrying User-Name AVP in DEA message, as described in RFC 4072. > > > - We must be sure that messages will reach the same AAA server. > > Why Diameter EAP messages and Diameter MIP6 messages need to hit the > same AAA server? > > Again, NASREQ usage for authorization purpse in RFC 4072 does not > require NASREQ and Diameter EAP messages to use the same AAA server. > In general, authentication, authorization and accouting can use > different AAA servers, and there should be no exception to MIP6 > bootstrapping, IMO. > > > - We may have trouble with RADIUS compatibility > > This can be handled later. > > Yoshihiro Ohba > > > > > > Anyone has an opinion on this way to solve our issue ? > > > > Thanks yoshi, > > > > Julien > > > > > > > > > > > > > If we "push" a little what you propose, we could define an > > > > "Authentication based on EAP" Application (only doing Authentication) > > > > used by other Application that would only define their messages for > > > > Authorization and Accounting (such as MIP6). That's why I talked to you > > > > in a previous mail about also consider network access as a special > > > > service and thus define Authz/Accounting messages for the "network > > > > access" service. > > > > > > Yes, in the case of network access, you could use NASREQ for > > > authorization purpose in additon to Diameter EAP for authentication > > > purpose as specified in RFC 4072. > > > > > > Regards, > > > Yoshihiro Ohba > > > > > > > > > > > > > > regards, > > > > > > > > Julien > > > > > > > > > > > > > > Regards, > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > > I also agree with Avi that defining a new application for MIP6 > > > > > > > bootstrapping on top of existing applications (Diameter EAP) without > > > > > > > defining a new application id but with defining new values for > > > > > > > existing AVPs or new optional AVPs has some issue, but this option > > > > > > > might not be as bad as the first option since backward compatibility > > > > > > > can be easily maintained unlike the first option. However, there is a > > > > > > > forward compatibility problem (i.e., a Diameter message may be forwarded > > > > > > > to a AAA server that does not support the new application). Besides > > > > > > > this problem, it might be worth pursuing this option because it works > > > > > > > in an optimized way (i.e., bootstrapping AVPs are piggybacked in > > > > > > > Diameter EAP or NASREQ message) as long as both NAS and AAA server > > > > > > > support the AVPs. > > > > > > > > > > > > I'm not in favor of having an app-id for the nas-aaah part of the mip6 > > > > > > bootstrapping problem. > > > > > > > > > > > > > > > > > > > > In order to deal with the forward compatibility problem of the second > > > > > > > option, a third option is to define a new application for MIP6 > > > > > > > bootstrapping as a totally new authorization application that carries > > > > > > > new mandatory AVPs specific to that application. This option can be > > > > > > > run when execution of the second option succeeds in authentication but > > > > > > > fails in carrying bootstrapping AVPs. > > > > > > > > > > > > hmm, i guess i have to think more of this option but this would mandate > > > > > > now that all EAP Application server should know that maybe they are not > > > > > > doing this for network access and that maybe they are going to receive > > > > > > a special authorization request. And in this case, wouldn't it mean > > > > > > that network access should be treated as a special service and this > > > > > > would also require a new authorization application ? > > > > > > > > > > > > regards, > > > > > > > > > > > > Julien > > > > > > > > > > > > > > Regards, > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Sep 05, 2006 at 11:21:22PM -0400, Avi Lior wrote: > > > > > > > > Hi Kuntal, > > > > > > > > > > > > > > > > Neither option 1 or option 2 will work. A new application id just wont > > > > > > > > scale in the long run. What if another 'capability' were to be added > > > > > > > > for instance prepaid. Since Diameter messages contain only one > > > > > > > > Application ID, you would have to create an Application Id that covered > > > > > > > > both EAP, Prepaid and Mobile IP. And what if a third application were > > > > > > > > added? The approach is not scalable as the applications are increased > > > > > > > > -- you would have to cope with all the different permutations of > > > > > > > > Applications. The same argument goes for ServiceType and PortType and > > > > > > > > these are actually more problematic. > > > > > > > > > > > > > > > > IMO the only thing we can do is to hint at the capability of the NAS. > > > > > > > > > > > > > > > > A proper solution should be concieved for this problem. > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > > > > > > > > Sent: Tuesday, September 05, 2006 2:09 PM > > > > > > > > > To: Avi Lior; Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > > > > > > > > Cc: dime@ietf.org > > > > > > > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > > > Service-Type > > > > > > > > > > > > > > > > > > All, > > > > > > > > > > > > > > > > > > Here is a scenario that may need to be covered. In some > > > > > > > > > cases, local HA assignment is optimal for transport > > > > > > > > > efficiency perspective. Diameter > > > > > > > > > MIP4 application allows this. In such a case the ASP == MSP > > > > > > > > > and the HA is assigned locally (in the visited network). > > > > > > > > > > > > > > > > > > To enable this case, in the integrated scenario, the NAS/VAAA > > > > > > > > > needs to indicate it's capability to assign an HA in the > > > > > > > > > local network to the HAAA. The HAAA may allow or disallow > > > > > > > > > this local HA assignment based on policy of the MSA. > > > > > > > > > > > > > > > > > > The NAS/VAAA may need to include a hint in the AAA message to > > > > > > > > > the HAAA at the time of access authentication that it is > > > > > > > > > capable of providing an HA to the MN. This capability > > > > > > > > > indication (hint) can be either sent via a new MIP6 specific > > > > > > > > > AVP or it can be conveyed via an existing AVP (I don't know > > > > > > > > > if one exists). > > > > > > > > > > > > > > > > > > If we decide to include this (local HA assignment), and we > > > > > > > > > decide to include this mip6 specific hint in the NAS-HAAA > > > > > > > > > communication, we may have to choose the most appropriate > > > > > > > > > option (1) vs. (2). > > > > > > > > > > > > > > > > > > Comments? > > > > > > > > > > > > > > > > > > -Kuntal > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > > > > > > > > Sent: Tuesday, September 05, 2006 6:07 AM > > > > > > > > > > To: Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > > > > > > > > > Cc: dime@ietf.org > > > > > > > > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > > > Service-Type > > > > > > > > > > > > > > > > > > > > I must be missing something. > > > > > > > > > > > > > > > > > > > > In the integrated scenario, what would the NAS put in Service-Type? > > > > > > > > > > > > > > > > > > > > I think in the integrated scenario neither Port-Type or > > > > > > > > > Service-Type > > > > > > > > > > needs to be touched. > > > > > > > > > > > > > > > > > > > > As far as I understand the NAS is either executing EAP > > > > > > > > > Application or > > > > > > > > > > NAS REQ. It does not know whether the user will result in having > > > > > > > > > > subsequent Mobile IP service or not. > > > > > > > > > > > > > > > > > > > > The only thing the AAA server can do is to send the MIPv6 attributes > > > > > > > > > as > > > > > > > > > > optional (M bit off) and hope that if the NAS does not > > > > > > > > > understand the > > > > > > > > > > attributes it would have some logic to bootstrap a different way. > > > > > > > > > > > > > > > > > > > > We could improve the situration somewhat. We could have the NAS > > > > > > > > > > indicate that it supports MIPv6 bootstrapping by including hints in > > > > > > > > > the > > > > > > > > > > AR (a capability hint). Where the NAS includes HA-IP address AVP > > > > > > > > > both > > > > > > > > > > indicating that it can support bootstrapping and if the > > > > > > > > > HA-IP address > > > > > > > > > is > > > > > > > > > > not ALL-ZEROS or ALL ONES it provides a hint that it can support > > > > > > > > > dynamic > > > > > > > > > > HA assignement. > > > > > > > > > > > > > > > > > > > > Ofcourse we could introduce the concept of capability hints more > > > > > > > > > > formally in Diameter -- This is missing today. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > > > > > > > > > > Sent: Tuesday, September 05, 2006 3:35 AM > > > > > > > > > > > To: Hannes.Tschofenig@gmx.net > > > > > > > > > > > Cc: dime@ietf.org > > > > > > > > > > > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > > > > > Service-Type > > > > > > > > > > > > > > > > > > > > > > Hi Hannes, > > > > > > > > > > > > > > > > > > > > > > I agree with Jouni. I prefer (2) for NAS-AAAH and (1) for > > > > > > > > > AAAH-HA. > > > > > > > > > > > In my understanding, there are no mandatory AVPs for NAS-AAAH and > > > > > > > > > > > therefore I don't see a need of a new application; it's just a > > > > > > > > > > > MIP-specific information that is piggybacked in the > > > > > > > > > network access > > > > > > > > > > > authentication procedure. > > > > > > > > > > > > > > > > > > > > > > Concerning AAAH-HA, I think it is a much cleaner approach > > > > > > > > > to define > > > > > > > > > > > a new application, since it does not anything to do with network > > > > > > > > > > > authentication. > > > > > > > > > > > > > > > > > > > > > > --Gerardo > > > > > > > > > > > > > > > > > > > > > > On 9/5/06, jouni.korhonen@teliasonera.com > > > > > > > > > > > wrote: > > > > > > > > > > > > Hi HAnnes, > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > > > > > > > > > > Sent: 1. syyskuuta 2006 1:07 > > > > > > > > > > > > > To: dime@ietf.org > > > > > > > > > > > > > Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > > > > > > > Service-Type > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > we have had long discussions about the App-ID vs. > > > > > > > > > > > > > Service-Type usage for > > > > > > > > > > > > > Diameter MIPv6 Bootstrapping. > > > > > > > > > > > > > > > > > > > > > > > > > > It is time to see what the group thinks. Please indicate > > > > > > > > > > > whether you > > > > > > > > > > > > > prefer (1) an App-ID or (2) a Service-Type solution for > > > > > > > > > > > > > > > > > > > > > > > > > > (a) NAS-to-AAAH communication (as required by the integrated > > > > > > > > > > > > > scenario; as one part of the solution component) > > > > > > > > > > > > > > > > > > > > > > > > I would prefer (2) for now.. or as long as the NAS-2-AAAH main > > > > > > > > > > > > function is to provide access authentication, where the backend > > > > > > > > > AAA > > > > > > > > > > > > may return > > > > > > > > > > > > MIP6 > > > > > > > > > > > > bootstrapping info (as an enhancement) based e.g. on the user > > > > > > > > > > > > subscription profile. If we go for more stuff on > > > > > > > > > NAS-2-AAAH like > > > > > > > > > > > > HoA/prefix etc then > > > > > > > > > > > > (1) > > > > > > > > > > > > might be better. > > > > > > > > > > > > > > > > > > > > > > > > > (b) HA-to-AAAH communication (as used by the split > > > > > > > > > > > scenario and the > > > > > > > > > > > > > integrated scenario) > > > > > > > > > > > > > > > > > > > > > > > > I would prefer (1) here. The use of EAP for MIP6 bootstrapping > > > > > > > > > > > > purposes and for 'normal' EAP-based access authentication are > > > > > > > > > > > > different applications imho. (although in IKEv2 vs 802.1X case > > > > > > > > > e.g. > > > > > > > > > > > > NAS-Port-Type could be used to make this distinction.. e.g. > > > > > > > > > > > how 3GPP > > > > > > > > > > > > WLAN stuff does it) > > > > > > > > > > > > > > > > > > > > > > > > > It might be useful to state a reason for your decision. > > > > > > > > > > > > > > > > > > > > > > > > > > Please also indicate whether some aspects are still > > > > > > > > > > > unclear to you. > > > > > > > > > > > > > > > > > > > > > > > > > > Ciao > > > > > > > > > > > > > Hannes > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Jouni > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > DiME mailing list > > > > > > > > > > > > > DiME@ietf.org > > > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > DiME mailing list > > > > > > > > > > > > DiME@ietf.org > > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > DiME mailing list > > > > > > > > > > > DiME@ietf.org > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > DiME mailing list > > > > > > > > > > DiME@ietf.org > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > > > "This email message and any attachments are confidential > > > > > > > > > information of Starent Networks, Corp. The information > > > > > > > > > transmitted may not be used to create or change any > > > > > > > > > contractual obligations of Starent Networks, Corp. Any > > > > > > > > > review, retransmission, dissemination or other use of, or > > > > > > > > > taking of any action in reliance upon this e-mail and its > > > > > > > > > attachments by persons or entities other than the intended > > > > > > > > > recipient is prohibited. If you are not the intended > > > > > > > > > recipient, please notify the sender immediately -- by > > > > > > > > > replying to this message or by sending an email to > > > > > > > > > postmaster@starentnetworks.com -- and destroy all copies of > > > > > > > > > this message and any attachments without reading or > > > > > > > > > disclosing their contents. Thank you." > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > DiME mailing list > > > > > > > > DiME@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > DiME mailing list > > > > > > > DiME@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > -- > > > > > > julien.bournelle at int-evry.fr > > > > > > > > > > > > > > -- > > > > julien.bournelle at int-evry.fr > > > > > > > > -- > > julien.bournelle at int-evry.fr > > -- julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Sep 15 05:58:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOASe-0007o0-IH; Fri, 15 Sep 2006 05:58:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOASd-0007nn-Uj for dime@ietf.org; Fri, 15 Sep 2006 05:58:15 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOASd-0007AA-2a for dime@ietf.org; Fri, 15 Sep 2006 05:58:15 -0400 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k8F9umgW052821; Fri, 15 Sep 2006 05:56:49 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Date: Fri, 15 Sep 2006 05:56:52 -0400 To: Julien Bournelle Message-ID: <20060915095651.GE30516@steelhead> References: <7CCD07160348804497EF29E9EA5560D78372F8@exchtewks2.starentnetworks.com> <20060906181643.GE5241@steelhead> <20060907152211.GA27475@ipv6-3.int-evry.fr> <20060907203328.GB18410@steelhead> <20060912121400.GA2527@ipv6-3.int-evry.fr> <20060912155310.GF2857@steelhead> <20060913085255.GA4025@ipv6-3.int-evry.fr> <20060913134306.GC15246@steelhead> <20060915093034.GA6298@ipv6-3.int-evry.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <20060915093034.GA6298@ipv6-3.int-evry.fr> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 429 X-Spam-Score: -2.4 (--) X-Scan-Signature: dfc64cf6e4c6efdbf6b8f4c995df04df Cc: dime@ietf.org Subject: [Dime] Re: Authentication through 2 different "NAS" in the same time ? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Julien, On Fri, Sep 15, 2006 at 11:30:34AM +0200, Julien Bournelle wrote: > Hi yoshi, > > I have one more question concerning your approach. > > Considering the following scenario: > > MN <------> NAS <---4072 -(1)---> AAAH > ^ ^ > | | > +----------> HA <---4072 (2)------+ > > First, the MN is authenticated throught the NAS. The NAS uses Diameter > EAP and asks the AAAH for AAA for network access. > > Then, the MN acquires the HA and uses IKEv2 with it. If we use your > approach, the HA uses Diameter EAP with the AVP Auth-Request-Type set > to AUTHENTICATE_ONLY. > > I was wondering if it won't cause trouble to the AAAH since it has > already authenticated the MN through the NAS. If the operational policy of AAAH allows MN to perform multiple back-to-back authentication/authorization attempts via different authenticators, then there should be no issue. BTW, I have two questions. - Do the EAP via NAS and the EAP via HA need to hit the same AAAH server? I guess not. - Do the EAP via NAS and the EAP via HA need to use the same Idenity? I guess not. Regards, Yoshihiro Ohba > > Any comments on this ? > > regards, > > Julien > > > On Wed, Sep 13, 2006 at 09:43:06AM -0400, Yoshihiro Ohba wrote: > > Hi Julien, > > > > On Wed, Sep 13, 2006 at 10:52:55AM +0200, Julien Bournelle wrote: > > > > (snip) > > > > > > > > > However, if the AAA server somehow needs to know about it, the HA(NAS) > > > > can indicate it by including Auth-Request-Type AVP in DER with > > > > specifying "AUTHENTICATE_ONLY". > > > > > > ok. I see. I forgot this possibility. > > > So to sump up, the HA will use Diameter EAP with the Auth-Request-Type > > > aVP set to AUTHENTICATE_ONLY and the App-ID set to 5. If it receives a > > > success, it will switch to a Authorization/Accounting MIP6 Application > > > with a new App-ID. Is that right ? > > > > > > I think it can work but we need to investigate a little more before > > > moving with this. Points that I can see for now are: > > > > > > - The session-id must be shared between the Application. > > > > Why session-id must be shared? > > > > NASREQ usage for authorization purpose in RFC 4072 does not require > > it. Instead, User-Name AVP can be shared between the applications. > > In case the NAS(HA) is not able to retrieve the username from EAP > > messages, the AAA server can tell the NAS about the username by > > carrying User-Name AVP in DEA message, as described in RFC 4072. > > > > > - We must be sure that messages will reach the same AAA server. > > > > Why Diameter EAP messages and Diameter MIP6 messages need to hit the > > same AAA server? > > > > Again, NASREQ usage for authorization purpse in RFC 4072 does not > > require NASREQ and Diameter EAP messages to use the same AAA server. > > In general, authentication, authorization and accouting can use > > different AAA servers, and there should be no exception to MIP6 > > bootstrapping, IMO. > > > > > - We may have trouble with RADIUS compatibility > > > > This can be handled later. > > > > Yoshihiro Ohba > > > > > > > > > > Anyone has an opinion on this way to solve our issue ? > > > > > > Thanks yoshi, > > > > > > Julien > > > > > > > > > > > > > > > > > If we "push" a little what you propose, we could define an > > > > > "Authentication based on EAP" Application (only doing Authentication) > > > > > used by other Application that would only define their messages for > > > > > Authorization and Accounting (such as MIP6). That's why I talked to you > > > > > in a previous mail about also consider network access as a special > > > > > service and thus define Authz/Accounting messages for the "network > > > > > access" service. > > > > > > > > Yes, in the case of network access, you could use NASREQ for > > > > authorization purpose in additon to Diameter EAP for authentication > > > > purpose as specified in RFC 4072. > > > > > > > > Regards, > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > regards, > > > > > > > > > > Julien > > > > > > > > > > > > > > > > > Regards, > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I also agree with Avi that defining a new application for MIP6 > > > > > > > > bootstrapping on top of existing applications (Diameter EAP) without > > > > > > > > defining a new application id but with defining new values for > > > > > > > > existing AVPs or new optional AVPs has some issue, but this option > > > > > > > > might not be as bad as the first option since backward compatibility > > > > > > > > can be easily maintained unlike the first option. However, there is a > > > > > > > > forward compatibility problem (i.e., a Diameter message may be forwarded > > > > > > > > to a AAA server that does not support the new application). Besides > > > > > > > > this problem, it might be worth pursuing this option because it works > > > > > > > > in an optimized way (i.e., bootstrapping AVPs are piggybacked in > > > > > > > > Diameter EAP or NASREQ message) as long as both NAS and AAA server > > > > > > > > support the AVPs. > > > > > > > > > > > > > > I'm not in favor of having an app-id for the nas-aaah part of the mip6 > > > > > > > bootstrapping problem. > > > > > > > > > > > > > > > > > > > > > > > In order to deal with the forward compatibility problem of the second > > > > > > > > option, a third option is to define a new application for MIP6 > > > > > > > > bootstrapping as a totally new authorization application that carries > > > > > > > > new mandatory AVPs specific to that application. This option can be > > > > > > > > run when execution of the second option succeeds in authentication but > > > > > > > > fails in carrying bootstrapping AVPs. > > > > > > > > > > > > > > hmm, i guess i have to think more of this option but this would mandate > > > > > > > now that all EAP Application server should know that maybe they are not > > > > > > > doing this for network access and that maybe they are going to receive > > > > > > > a special authorization request. And in this case, wouldn't it mean > > > > > > > that network access should be treated as a special service and this > > > > > > > would also require a new authorization application ? > > > > > > > > > > > > > > regards, > > > > > > > > > > > > > > Julien > > > > > > > > > > > > > > > > Regards, > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Sep 05, 2006 at 11:21:22PM -0400, Avi Lior wrote: > > > > > > > > > Hi Kuntal, > > > > > > > > > > > > > > > > > > Neither option 1 or option 2 will work. A new application id just wont > > > > > > > > > scale in the long run. What if another 'capability' were to be added > > > > > > > > > for instance prepaid. Since Diameter messages contain only one > > > > > > > > > Application ID, you would have to create an Application Id that covered > > > > > > > > > both EAP, Prepaid and Mobile IP. And what if a third application were > > > > > > > > > added? The approach is not scalable as the applications are increased > > > > > > > > > -- you would have to cope with all the different permutations of > > > > > > > > > Applications. The same argument goes for ServiceType and PortType and > > > > > > > > > these are actually more problematic. > > > > > > > > > > > > > > > > > > IMO the only thing we can do is to hint at the capability of the NAS. > > > > > > > > > > > > > > > > > > A proper solution should be concieved for this problem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > > > > > > > > > Sent: Tuesday, September 05, 2006 2:09 PM > > > > > > > > > > To: Avi Lior; Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > > > > > > > > > Cc: dime@ietf.org > > > > > > > > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > > > > Service-Type > > > > > > > > > > > > > > > > > > > > All, > > > > > > > > > > > > > > > > > > > > Here is a scenario that may need to be covered. In some > > > > > > > > > > cases, local HA assignment is optimal for transport > > > > > > > > > > efficiency perspective. Diameter > > > > > > > > > > MIP4 application allows this. In such a case the ASP == MSP > > > > > > > > > > and the HA is assigned locally (in the visited network). > > > > > > > > > > > > > > > > > > > > To enable this case, in the integrated scenario, the NAS/VAAA > > > > > > > > > > needs to indicate it's capability to assign an HA in the > > > > > > > > > > local network to the HAAA. The HAAA may allow or disallow > > > > > > > > > > this local HA assignment based on policy of the MSA. > > > > > > > > > > > > > > > > > > > > The NAS/VAAA may need to include a hint in the AAA message to > > > > > > > > > > the HAAA at the time of access authentication that it is > > > > > > > > > > capable of providing an HA to the MN. This capability > > > > > > > > > > indication (hint) can be either sent via a new MIP6 specific > > > > > > > > > > AVP or it can be conveyed via an existing AVP (I don't know > > > > > > > > > > if one exists). > > > > > > > > > > > > > > > > > > > > If we decide to include this (local HA assignment), and we > > > > > > > > > > decide to include this mip6 specific hint in the NAS-HAAA > > > > > > > > > > communication, we may have to choose the most appropriate > > > > > > > > > > option (1) vs. (2). > > > > > > > > > > > > > > > > > > > > Comments? > > > > > > > > > > > > > > > > > > > > -Kuntal > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > > > > > > > > > Sent: Tuesday, September 05, 2006 6:07 AM > > > > > > > > > > > To: Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > > > > > > > > > > Cc: dime@ietf.org > > > > > > > > > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > > > > Service-Type > > > > > > > > > > > > > > > > > > > > > > I must be missing something. > > > > > > > > > > > > > > > > > > > > > > In the integrated scenario, what would the NAS put in Service-Type? > > > > > > > > > > > > > > > > > > > > > > I think in the integrated scenario neither Port-Type or > > > > > > > > > > Service-Type > > > > > > > > > > > needs to be touched. > > > > > > > > > > > > > > > > > > > > > > As far as I understand the NAS is either executing EAP > > > > > > > > > > Application or > > > > > > > > > > > NAS REQ. It does not know whether the user will result in having > > > > > > > > > > > subsequent Mobile IP service or not. > > > > > > > > > > > > > > > > > > > > > > The only thing the AAA server can do is to send the MIPv6 attributes > > > > > > > > > > as > > > > > > > > > > > optional (M bit off) and hope that if the NAS does not > > > > > > > > > > understand the > > > > > > > > > > > attributes it would have some logic to bootstrap a different way. > > > > > > > > > > > > > > > > > > > > > > We could improve the situration somewhat. We could have the NAS > > > > > > > > > > > indicate that it supports MIPv6 bootstrapping by including hints in > > > > > > > > > > the > > > > > > > > > > > AR (a capability hint). Where the NAS includes HA-IP address AVP > > > > > > > > > > both > > > > > > > > > > > indicating that it can support bootstrapping and if the > > > > > > > > > > HA-IP address > > > > > > > > > > is > > > > > > > > > > > not ALL-ZEROS or ALL ONES it provides a hint that it can support > > > > > > > > > > dynamic > > > > > > > > > > > HA assignement. > > > > > > > > > > > > > > > > > > > > > > Ofcourse we could introduce the concept of capability hints more > > > > > > > > > > > formally in Diameter -- This is missing today. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > > > > > > > > > > > Sent: Tuesday, September 05, 2006 3:35 AM > > > > > > > > > > > > To: Hannes.Tschofenig@gmx.net > > > > > > > > > > > > Cc: dime@ietf.org > > > > > > > > > > > > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > > > > > > Service-Type > > > > > > > > > > > > > > > > > > > > > > > > Hi Hannes, > > > > > > > > > > > > > > > > > > > > > > > > I agree with Jouni. I prefer (2) for NAS-AAAH and (1) for > > > > > > > > > > AAAH-HA. > > > > > > > > > > > > In my understanding, there are no mandatory AVPs for NAS-AAAH and > > > > > > > > > > > > therefore I don't see a need of a new application; it's just a > > > > > > > > > > > > MIP-specific information that is piggybacked in the > > > > > > > > > > network access > > > > > > > > > > > > authentication procedure. > > > > > > > > > > > > > > > > > > > > > > > > Concerning AAAH-HA, I think it is a much cleaner approach > > > > > > > > > > to define > > > > > > > > > > > > a new application, since it does not anything to do with network > > > > > > > > > > > > authentication. > > > > > > > > > > > > > > > > > > > > > > > > --Gerardo > > > > > > > > > > > > > > > > > > > > > > > > On 9/5/06, jouni.korhonen@teliasonera.com > > > > > > > > > > > > wrote: > > > > > > > > > > > > > Hi HAnnes, > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > > > > > > > > > > > Sent: 1. syyskuuta 2006 1:07 > > > > > > > > > > > > > > To: dime@ietf.org > > > > > > > > > > > > > > Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > > > > > > > > Service-Type > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > we have had long discussions about the App-ID vs. > > > > > > > > > > > > > > Service-Type usage for > > > > > > > > > > > > > > Diameter MIPv6 Bootstrapping. > > > > > > > > > > > > > > > > > > > > > > > > > > > > It is time to see what the group thinks. Please indicate > > > > > > > > > > > > whether you > > > > > > > > > > > > > > prefer (1) an App-ID or (2) a Service-Type solution for > > > > > > > > > > > > > > > > > > > > > > > > > > > > (a) NAS-to-AAAH communication (as required by the integrated > > > > > > > > > > > > > > scenario; as one part of the solution component) > > > > > > > > > > > > > > > > > > > > > > > > > > I would prefer (2) for now.. or as long as the NAS-2-AAAH main > > > > > > > > > > > > > function is to provide access authentication, where the backend > > > > > > > > > > AAA > > > > > > > > > > > > > may return > > > > > > > > > > > > > MIP6 > > > > > > > > > > > > > bootstrapping info (as an enhancement) based e.g. on the user > > > > > > > > > > > > > subscription profile. If we go for more stuff on > > > > > > > > > > NAS-2-AAAH like > > > > > > > > > > > > > HoA/prefix etc then > > > > > > > > > > > > > (1) > > > > > > > > > > > > > might be better. > > > > > > > > > > > > > > > > > > > > > > > > > > > (b) HA-to-AAAH communication (as used by the split > > > > > > > > > > > > scenario and the > > > > > > > > > > > > > > integrated scenario) > > > > > > > > > > > > > > > > > > > > > > > > > > I would prefer (1) here. The use of EAP for MIP6 bootstrapping > > > > > > > > > > > > > purposes and for 'normal' EAP-based access authentication are > > > > > > > > > > > > > different applications imho. (although in IKEv2 vs 802.1X case > > > > > > > > > > e.g. > > > > > > > > > > > > > NAS-Port-Type could be used to make this distinction.. e.g. > > > > > > > > > > > > how 3GPP > > > > > > > > > > > > > WLAN stuff does it) > > > > > > > > > > > > > > > > > > > > > > > > > > > It might be useful to state a reason for your decision. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please also indicate whether some aspects are still > > > > > > > > > > > > unclear to you. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ciao > > > > > > > > > > > > > > Hannes > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > Jouni > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > DiME mailing list > > > > > > > > > > > > > > DiME@ietf.org > > > > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > DiME mailing list > > > > > > > > > > > > > DiME@ietf.org > > > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > DiME mailing list > > > > > > > > > > > > DiME@ietf.org > > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > DiME mailing list > > > > > > > > > > > DiME@ietf.org > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > "This email message and any attachments are confidential > > > > > > > > > > information of Starent Networks, Corp. The information > > > > > > > > > > transmitted may not be used to create or change any > > > > > > > > > > contractual obligations of Starent Networks, Corp. Any > > > > > > > > > > review, retransmission, dissemination or other use of, or > > > > > > > > > > taking of any action in reliance upon this e-mail and its > > > > > > > > > > attachments by persons or entities other than the intended > > > > > > > > > > recipient is prohibited. If you are not the intended > > > > > > > > > > recipient, please notify the sender immediately -- by > > > > > > > > > > replying to this message or by sending an email to > > > > > > > > > > postmaster@starentnetworks.com -- and destroy all copies of > > > > > > > > > > this message and any attachments without reading or > > > > > > > > > > disclosing their contents. Thank you." > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > DiME mailing list > > > > > > > > > DiME@ietf.org > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > DiME mailing list > > > > > > > > DiME@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > -- > > > > > > > julien.bournelle at int-evry.fr > > > > > > > > > > > > > > > > > -- > > > > > julien.bournelle at int-evry.fr > > > > > > > > > > > -- > > > julien.bournelle at int-evry.fr > > > > > -- > julien.bournelle at int-evry.fr > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Sep 15 06:05:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOAZH-0001td-Eu; Fri, 15 Sep 2006 06:05:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOAZG-0001pN-37 for dime@ietf.org; Fri, 15 Sep 2006 06:05:06 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOAZE-0008Si-WD for dime@ietf.org; Fri, 15 Sep 2006 06:05:06 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id B6F7F2FDF5; Fri, 15 Sep 2006 12:05:02 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1GOAbh-0001gB-5B; Fri, 15 Sep 2006 12:07:37 +0200 Date: Fri, 15 Sep 2006 12:07:37 +0200 From: Julien Bournelle To: Yoshihiro Ohba Message-ID: <20060915100737.GA6449@ipv6-3.int-evry.fr> References: <20060906181643.GE5241@steelhead> <20060907152211.GA27475@ipv6-3.int-evry.fr> <20060907203328.GB18410@steelhead> <20060912121400.GA2527@ipv6-3.int-evry.fr> <20060912155310.GF2857@steelhead> <20060913085255.GA4025@ipv6-3.int-evry.fr> <20060913134306.GC15246@steelhead> <20060915093034.GA6298@ipv6-3.int-evry.fr> <20060915095651.GE30516@steelhead> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060915095651.GE30516@steelhead> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 054490fec19f6a94c68e63428d06db69 Cc: dime@ietf.org Subject: [Dime] Re: Authentication through 2 different "NAS" in the same time ? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org On Fri, Sep 15, 2006 at 05:56:52AM -0400, Yoshihiro Ohba wrote: > Hi Julien, > > On Fri, Sep 15, 2006 at 11:30:34AM +0200, Julien Bournelle wrote: > > Hi yoshi, > > > > I have one more question concerning your approach. > > > > Considering the following scenario: > > > > MN <------> NAS <---4072 -(1)---> AAAH > > ^ ^ > > | | > > +----------> HA <---4072 (2)------+ > > > > First, the MN is authenticated throught the NAS. The NAS uses Diameter > > EAP and asks the AAAH for AAA for network access. > > > > Then, the MN acquires the HA and uses IKEv2 with it. If we use your > > approach, the HA uses Diameter EAP with the AVP Auth-Request-Type set > > to AUTHENTICATE_ONLY. > > > > I was wondering if it won't cause trouble to the AAAH since it has > > already authenticated the MN through the NAS. > > If the operational policy of AAAH allows MN to perform multiple > back-to-back authentication/authorization attempts via different > authenticators, then there should be no issue. ok. I think that if we move forward with your approach we should add a little text about this. > BTW, I have two questions. > > - Do the EAP via NAS and the EAP via HA need to hit the same AAAH > server? I guess not. I don't think so. > - Do the EAP via NAS and the EAP via HA need to use the same Idenity? > I guess not. I don't think so. regards, Julien > > Regards, > Yoshihiro Ohba > > > > > > Any comments on this ? > > > > regards, > > > > Julien > > > > > > On Wed, Sep 13, 2006 at 09:43:06AM -0400, Yoshihiro Ohba wrote: > > > Hi Julien, > > > > > > On Wed, Sep 13, 2006 at 10:52:55AM +0200, Julien Bournelle wrote: > > > > > > (snip) > > > > > > > > > > > > However, if the AAA server somehow needs to know about it, the HA(NAS) > > > > > can indicate it by including Auth-Request-Type AVP in DER with > > > > > specifying "AUTHENTICATE_ONLY". > > > > > > > > ok. I see. I forgot this possibility. > > > > So to sump up, the HA will use Diameter EAP with the Auth-Request-Type > > > > aVP set to AUTHENTICATE_ONLY and the App-ID set to 5. If it receives a > > > > success, it will switch to a Authorization/Accounting MIP6 Application > > > > with a new App-ID. Is that right ? > > > > > > > > I think it can work but we need to investigate a little more before > > > > moving with this. Points that I can see for now are: > > > > > > > > - The session-id must be shared between the Application. > > > > > > Why session-id must be shared? > > > > > > NASREQ usage for authorization purpose in RFC 4072 does not require > > > it. Instead, User-Name AVP can be shared between the applications. > > > In case the NAS(HA) is not able to retrieve the username from EAP > > > messages, the AAA server can tell the NAS about the username by > > > carrying User-Name AVP in DEA message, as described in RFC 4072. > > > > > > > - We must be sure that messages will reach the same AAA server. > > > > > > Why Diameter EAP messages and Diameter MIP6 messages need to hit the > > > same AAA server? > > > > > > Again, NASREQ usage for authorization purpse in RFC 4072 does not > > > require NASREQ and Diameter EAP messages to use the same AAA server. > > > In general, authentication, authorization and accouting can use > > > different AAA servers, and there should be no exception to MIP6 > > > bootstrapping, IMO. > > > > > > > - We may have trouble with RADIUS compatibility > > > > > > This can be handled later. > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > Anyone has an opinion on this way to solve our issue ? > > > > > > > > Thanks yoshi, > > > > > > > > Julien > > > > > > > > > > > > > > > > > > > > > If we "push" a little what you propose, we could define an > > > > > > "Authentication based on EAP" Application (only doing Authentication) > > > > > > used by other Application that would only define their messages for > > > > > > Authorization and Accounting (such as MIP6). That's why I talked to you > > > > > > in a previous mail about also consider network access as a special > > > > > > service and thus define Authz/Accounting messages for the "network > > > > > > access" service. > > > > > > > > > > Yes, in the case of network access, you could use NASREQ for > > > > > authorization purpose in additon to Diameter EAP for authentication > > > > > purpose as specified in RFC 4072. > > > > > > > > > > Regards, > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > regards, > > > > > > > > > > > > Julien > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I also agree with Avi that defining a new application for MIP6 > > > > > > > > > bootstrapping on top of existing applications (Diameter EAP) without > > > > > > > > > defining a new application id but with defining new values for > > > > > > > > > existing AVPs or new optional AVPs has some issue, but this option > > > > > > > > > might not be as bad as the first option since backward compatibility > > > > > > > > > can be easily maintained unlike the first option. However, there is a > > > > > > > > > forward compatibility problem (i.e., a Diameter message may be forwarded > > > > > > > > > to a AAA server that does not support the new application). Besides > > > > > > > > > this problem, it might be worth pursuing this option because it works > > > > > > > > > in an optimized way (i.e., bootstrapping AVPs are piggybacked in > > > > > > > > > Diameter EAP or NASREQ message) as long as both NAS and AAA server > > > > > > > > > support the AVPs. > > > > > > > > > > > > > > > > I'm not in favor of having an app-id for the nas-aaah part of the mip6 > > > > > > > > bootstrapping problem. > > > > > > > > > > > > > > > > > > > > > > > > > > In order to deal with the forward compatibility problem of the second > > > > > > > > > option, a third option is to define a new application for MIP6 > > > > > > > > > bootstrapping as a totally new authorization application that carries > > > > > > > > > new mandatory AVPs specific to that application. This option can be > > > > > > > > > run when execution of the second option succeeds in authentication but > > > > > > > > > fails in carrying bootstrapping AVPs. > > > > > > > > > > > > > > > > hmm, i guess i have to think more of this option but this would mandate > > > > > > > > now that all EAP Application server should know that maybe they are not > > > > > > > > doing this for network access and that maybe they are going to receive > > > > > > > > a special authorization request. And in this case, wouldn't it mean > > > > > > > > that network access should be treated as a special service and this > > > > > > > > would also require a new authorization application ? > > > > > > > > > > > > > > > > regards, > > > > > > > > > > > > > > > > Julien > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Sep 05, 2006 at 11:21:22PM -0400, Avi Lior wrote: > > > > > > > > > > Hi Kuntal, > > > > > > > > > > > > > > > > > > > > Neither option 1 or option 2 will work. A new application id just wont > > > > > > > > > > scale in the long run. What if another 'capability' were to be added > > > > > > > > > > for instance prepaid. Since Diameter messages contain only one > > > > > > > > > > Application ID, you would have to create an Application Id that covered > > > > > > > > > > both EAP, Prepaid and Mobile IP. And what if a third application were > > > > > > > > > > added? The approach is not scalable as the applications are increased > > > > > > > > > > -- you would have to cope with all the different permutations of > > > > > > > > > > Applications. The same argument goes for ServiceType and PortType and > > > > > > > > > > these are actually more problematic. > > > > > > > > > > > > > > > > > > > > IMO the only thing we can do is to hint at the capability of the NAS. > > > > > > > > > > > > > > > > > > > > A proper solution should be concieved for this problem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > > > > > > > > > > Sent: Tuesday, September 05, 2006 2:09 PM > > > > > > > > > > > To: Avi Lior; Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > > > > > > > > > > Cc: dime@ietf.org > > > > > > > > > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > > > > > Service-Type > > > > > > > > > > > > > > > > > > > > > > All, > > > > > > > > > > > > > > > > > > > > > > Here is a scenario that may need to be covered. In some > > > > > > > > > > > cases, local HA assignment is optimal for transport > > > > > > > > > > > efficiency perspective. Diameter > > > > > > > > > > > MIP4 application allows this. In such a case the ASP == MSP > > > > > > > > > > > and the HA is assigned locally (in the visited network). > > > > > > > > > > > > > > > > > > > > > > To enable this case, in the integrated scenario, the NAS/VAAA > > > > > > > > > > > needs to indicate it's capability to assign an HA in the > > > > > > > > > > > local network to the HAAA. The HAAA may allow or disallow > > > > > > > > > > > this local HA assignment based on policy of the MSA. > > > > > > > > > > > > > > > > > > > > > > The NAS/VAAA may need to include a hint in the AAA message to > > > > > > > > > > > the HAAA at the time of access authentication that it is > > > > > > > > > > > capable of providing an HA to the MN. This capability > > > > > > > > > > > indication (hint) can be either sent via a new MIP6 specific > > > > > > > > > > > AVP or it can be conveyed via an existing AVP (I don't know > > > > > > > > > > > if one exists). > > > > > > > > > > > > > > > > > > > > > > If we decide to include this (local HA assignment), and we > > > > > > > > > > > decide to include this mip6 specific hint in the NAS-HAAA > > > > > > > > > > > communication, we may have to choose the most appropriate > > > > > > > > > > > option (1) vs. (2). > > > > > > > > > > > > > > > > > > > > > > Comments? > > > > > > > > > > > > > > > > > > > > > > -Kuntal > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > > > > > > > > > > Sent: Tuesday, September 05, 2006 6:07 AM > > > > > > > > > > > > To: Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > > > > > > > > > > > Cc: dime@ietf.org > > > > > > > > > > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > > > > > Service-Type > > > > > > > > > > > > > > > > > > > > > > > > I must be missing something. > > > > > > > > > > > > > > > > > > > > > > > > In the integrated scenario, what would the NAS put in Service-Type? > > > > > > > > > > > > > > > > > > > > > > > > I think in the integrated scenario neither Port-Type or > > > > > > > > > > > Service-Type > > > > > > > > > > > > needs to be touched. > > > > > > > > > > > > > > > > > > > > > > > > As far as I understand the NAS is either executing EAP > > > > > > > > > > > Application or > > > > > > > > > > > > NAS REQ. It does not know whether the user will result in having > > > > > > > > > > > > subsequent Mobile IP service or not. > > > > > > > > > > > > > > > > > > > > > > > > The only thing the AAA server can do is to send the MIPv6 attributes > > > > > > > > > > > as > > > > > > > > > > > > optional (M bit off) and hope that if the NAS does not > > > > > > > > > > > understand the > > > > > > > > > > > > attributes it would have some logic to bootstrap a different way. > > > > > > > > > > > > > > > > > > > > > > > > We could improve the situration somewhat. We could have the NAS > > > > > > > > > > > > indicate that it supports MIPv6 bootstrapping by including hints in > > > > > > > > > > > the > > > > > > > > > > > > AR (a capability hint). Where the NAS includes HA-IP address AVP > > > > > > > > > > > both > > > > > > > > > > > > indicating that it can support bootstrapping and if the > > > > > > > > > > > HA-IP address > > > > > > > > > > > is > > > > > > > > > > > > not ALL-ZEROS or ALL ONES it provides a hint that it can support > > > > > > > > > > > dynamic > > > > > > > > > > > > HA assignement. > > > > > > > > > > > > > > > > > > > > > > > > Ofcourse we could introduce the concept of capability hints more > > > > > > > > > > > > formally in Diameter -- This is missing today. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > > > > > > > > > > > > Sent: Tuesday, September 05, 2006 3:35 AM > > > > > > > > > > > > > To: Hannes.Tschofenig@gmx.net > > > > > > > > > > > > > Cc: dime@ietf.org > > > > > > > > > > > > > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > > > > > > > Service-Type > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Hannes, > > > > > > > > > > > > > > > > > > > > > > > > > > I agree with Jouni. I prefer (2) for NAS-AAAH and (1) for > > > > > > > > > > > AAAH-HA. > > > > > > > > > > > > > In my understanding, there are no mandatory AVPs for NAS-AAAH and > > > > > > > > > > > > > therefore I don't see a need of a new application; it's just a > > > > > > > > > > > > > MIP-specific information that is piggybacked in the > > > > > > > > > > > network access > > > > > > > > > > > > > authentication procedure. > > > > > > > > > > > > > > > > > > > > > > > > > > Concerning AAAH-HA, I think it is a much cleaner approach > > > > > > > > > > > to define > > > > > > > > > > > > > a new application, since it does not anything to do with network > > > > > > > > > > > > > authentication. > > > > > > > > > > > > > > > > > > > > > > > > > > --Gerardo > > > > > > > > > > > > > > > > > > > > > > > > > > On 9/5/06, jouni.korhonen@teliasonera.com > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > Hi HAnnes, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > > > > > > > > > > > > Sent: 1. syyskuuta 2006 1:07 > > > > > > > > > > > > > > > To: dime@ietf.org > > > > > > > > > > > > > > > Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > > > > > > > > > Service-Type > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > we have had long discussions about the App-ID vs. > > > > > > > > > > > > > > > Service-Type usage for > > > > > > > > > > > > > > > Diameter MIPv6 Bootstrapping. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It is time to see what the group thinks. Please indicate > > > > > > > > > > > > > whether you > > > > > > > > > > > > > > > prefer (1) an App-ID or (2) a Service-Type solution for > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (a) NAS-to-AAAH communication (as required by the integrated > > > > > > > > > > > > > > > scenario; as one part of the solution component) > > > > > > > > > > > > > > > > > > > > > > > > > > > > I would prefer (2) for now.. or as long as the NAS-2-AAAH main > > > > > > > > > > > > > > function is to provide access authentication, where the backend > > > > > > > > > > > AAA > > > > > > > > > > > > > > may return > > > > > > > > > > > > > > MIP6 > > > > > > > > > > > > > > bootstrapping info (as an enhancement) based e.g. on the user > > > > > > > > > > > > > > subscription profile. If we go for more stuff on > > > > > > > > > > > NAS-2-AAAH like > > > > > > > > > > > > > > HoA/prefix etc then > > > > > > > > > > > > > > (1) > > > > > > > > > > > > > > might be better. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (b) HA-to-AAAH communication (as used by the split > > > > > > > > > > > > > scenario and the > > > > > > > > > > > > > > > integrated scenario) > > > > > > > > > > > > > > > > > > > > > > > > > > > > I would prefer (1) here. The use of EAP for MIP6 bootstrapping > > > > > > > > > > > > > > purposes and for 'normal' EAP-based access authentication are > > > > > > > > > > > > > > different applications imho. (although in IKEv2 vs 802.1X case > > > > > > > > > > > e.g. > > > > > > > > > > > > > > NAS-Port-Type could be used to make this distinction.. e.g. > > > > > > > > > > > > > how 3GPP > > > > > > > > > > > > > > WLAN stuff does it) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It might be useful to state a reason for your decision. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please also indicate whether some aspects are still > > > > > > > > > > > > > unclear to you. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ciao > > > > > > > > > > > > > > > Hannes > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > Jouni > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > DiME mailing list > > > > > > > > > > > > > > > DiME@ietf.org > > > > > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > DiME mailing list > > > > > > > > > > > > > > DiME@ietf.org > > > > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > DiME mailing list > > > > > > > > > > > > > DiME@ietf.org > > > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > DiME mailing list > > > > > > > > > > > > DiME@ietf.org > > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > "This email message and any attachments are confidential > > > > > > > > > > > information of Starent Networks, Corp. The information > > > > > > > > > > > transmitted may not be used to create or change any > > > > > > > > > > > contractual obligations of Starent Networks, Corp. Any > > > > > > > > > > > review, retransmission, dissemination or other use of, or > > > > > > > > > > > taking of any action in reliance upon this e-mail and its > > > > > > > > > > > attachments by persons or entities other than the intended > > > > > > > > > > > recipient is prohibited. If you are not the intended > > > > > > > > > > > recipient, please notify the sender immediately -- by > > > > > > > > > > > replying to this message or by sending an email to > > > > > > > > > > > postmaster@starentnetworks.com -- and destroy all copies of > > > > > > > > > > > this message and any attachments without reading or > > > > > > > > > > > disclosing their contents. Thank you." > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > DiME mailing list > > > > > > > > > > DiME@ietf.org > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > DiME mailing list > > > > > > > > > DiME@ietf.org > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > -- > > > > > > > > julien.bournelle at int-evry.fr > > > > > > > > > > > > > > > > > > > > -- > > > > > > julien.bournelle at int-evry.fr > > > > > > > > > > > > > > -- > > > > julien.bournelle at int-evry.fr > > > > > > > > -- > > julien.bournelle at int-evry.fr > > -- julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Sep 15 06:18:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOAmS-0006Rj-TN; Fri, 15 Sep 2006 06:18:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOAmS-0006QT-26 for dime@ietf.org; Fri, 15 Sep 2006 06:18:44 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOAmP-0001vC-OQ for dime@ietf.org; Fri, 15 Sep 2006 06:18:44 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id CBCAA2FE77 for ; Fri, 15 Sep 2006 12:18:39 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1GOAos-0001hS-7E for dime@ietf.org; Fri, 15 Sep 2006 12:21:14 +0200 Date: Fri, 15 Sep 2006 12:21:14 +0200 From: Julien Bournelle To: dime@ietf.org Message-ID: <20060915102114.GA6527@ipv6-3.int-evry.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.8 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part 2) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, this is a new polling concerning the ha-aaah interface for the Mobile IPv6 Boostrapping. To date, at the previous one, there was a consensus on moving forward with a new App-ID. But, yoshi has proposed an interesting idea that should be considered by the WG. As you may recall, in the ha-aaah case, the MN is authenticated by EAP (IKEv2 is used between MN and the HA) and thus the HA-AAAH interface must, at least, be able to carry EAP packets. It appears that we now have 2 options: (1) We define a new Diameter application for Mobile IPv6 with a new App-ID that carry EAP packets as it is done in RFC 4072 (Diameter EAP) but Authorization and Accouting is specific to Mobile IPv6 (thus the need for a new App-ID). The risk, as noted by yoshi, is that an update of the RFC4072 may result in an update of this application. (2) We define a new Diameter Application for Mobile IPv6 but which is used for Authorization and Accounting. We continue to use Diameter EAP for the Authentication. Thus the HA will use Diameter EAP with the AVP Auth-Request-Type set to AUTHENTICATE_ONLY and then the HA will use this MIP6 Application for Authorization/Accounting of the Mobile IPv6 service. This new application will have its own App-ID. This would avoid to update the application if 4072 is updated and this could be a way to proceed if other applications need EAP for Authentication but have different needs for the Authorization and Accounting part. Please indicate wether you prefer (1) or (2). As in the previous polling: - it might be useful to state a reason for your decision. - indicate wether some aspects are still unclear to you. Regards, Julien _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Sep 15 09:03:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GODLP-0001rP-5o; Fri, 15 Sep 2006 09:02:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GODLN-0001ko-Mm for dime@ietf.org; Fri, 15 Sep 2006 09:02:57 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOD9L-0008Gc-2W for dime@ietf.org; Fri, 15 Sep 2006 08:50:32 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 1139FCA720; Fri, 15 Sep 2006 08:50:25 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k8FCoOI0016564; Fri, 15 Sep 2006 08:50:24 -0400 (EDT) From: "Tolga Asveren" To: , Subject: RE: [Dime] Error Code issues for bis Date: Fri, 15 Sep 2006 08:49:37 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-Reply-To: Importance: Normal Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org John, My only goal is being able to use the grammar described in 7.2 for permanent answers as well. For certain situations it is impossible to continue decoding a message, e.g. invalid AVP length for an AVP which is of type OctetString. In such a case, it may not be possible to generate an answer message based on the command's answer grammar, nor does it seem necessary to me. What I suggest is allowing E-bit to be set for permanent failures as well, so that grammar in 7.2 can be used. It is not important that all implementations follow that path, only the ones which consider it necessary/usefull for certain cases can use it. On receiver end, this shouldn't be a problem because if the E-bit is set, receiver will decode the message based on 7.2 grammar, otherwise command answer grammar will be used. this rule is already there in RFC3588. After thinking a bit more, the only possible backward compatibility issue I see is, if some implementation checks whether E-bit is set for an answer with Result-Code other than Protocol Error. Considering that for some Permanent Failures 7.2 grammar is really necessary, I believe that shouldn't be a big issue. Thanks, Tolga > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Thursday, September 14, 2006 11:34 PM > To: asveren@ulticom.com; dime@ietf.org > Subject: RE: [Dime] Error Code issues for bis > > > Tolga, > > If it is optional, that means you can't count that any implementations > will support it. > > However, are you suggesting the E-bit could be used as a hint for > permantant failures? > > John > > >-----Original Message----- > >From: ext Tolga Asveren [mailto:asveren@ulticom.com] > >Sent: 14 September, 2006 21:14 > >To: dime@ietf.org > >Subject: RE: [Dime] Error Code issues for bis > > > >Hi Victor, > > > >I had a look to Issue14. I already thought that use of E-bit > >is exclusively for protocol errors based on "Note that these > >and only these erors MUST only be used in answer messages > >whose 'E' bit is set." in 7.1.3. The proposed text further > >supports this idea. > > > >I see a value of using E-bit for permanent failures as I tried > >to explain before. I think your concern is that people may > >choose not to use error answer-message grammar defined in 7.2 > >for certain permanent failures. To address both concerns, I > >suggest we allow use of E-bit for permanent failures but leave > >it as an implementation choice to use it or not. This again > >would be backward compatible AFAICS. > > > > Thanks, > > Tolga > > > > > > > >> -----Original Message----- > >> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > >> Sent: Thursday, September 14, 2006 10:17 AM > >> To: Tolga Asveren > >> Cc: dime@ietf.org > >> Subject: Re: [Dime] Error Code issues for bis > >> > >> > >> Hi Tolga, > >> > >> Comments inline: > >> >>> > >> >> This maybe an easy way of performing error handling with just > >> >> sending the error grammar but it maybe to harsh (??). A node > >> >> receiving a result code set to some non-protocol failure > >value may > >> >> find it more useful to receive the application specific answer > >> >> message rather than just the error message in 7.2 since the error > >> >> may not be grave and the both end-point application can > >attempt to recover and continue on. > >> An example > >> >> would be when the result code is set to MISSING_AVP or > >> INVALID_AVP_VALUE > >> >> and the answer message carries a Failed-AVP. Depending on the > >> >> application, the sender of the error may choose to continue > >> >> processing the remainder of the request if the offending > >AVP is not > >> >> crucial. The receiver of the error would view the error as a hint > >> >> maybe able to compensate/recover and continue on also. > >> >> > >> > [TOLGA]This is an interesting point but if such an answer is > >> generated, how > >> > could the peer know the real result of the request > >processing? Let's > >> > say Result-Code contains MISSING_AVP, how could the request > >> originator determine > >> > whether the request processing is done successfully? > >> > >> I was thinking through other avp's in the application > >specific answer > >> grammar ... though that maybe stretching the success/failure > >> significance of the result-code avp against other avps in > >the message > >> so may not as advisable. > >> > >> >> I guess this would depend if the implementation is doing full > >> or partial > >> >> parsing in the base protocol layer. > >> >> > >> > [TOLGA]I think I was not clear about this one. The message > >is parsed > >> > (or parsed as much as possible depending the type of the error). > >> Now an answer > >> > message needs to be generated. If the grammar of the > >answer for that > >> > specific command code is used, all mandatory AVPs which are > >> specified in the > >> > grammar need to be present. Those AVPs possibly could be filled > >> > without application logic involvement, but I would think this would > >> require to put > >> > some dummy values there. In such a case, what is the point of > >> > inserting them? > >> > > >> > >> I was thinking in the case where the base protocol part of the > >> implementation does only partial parsing of message header > >and avps it > >> requires and leaves full parsing of the remaining > >application specific > >> avps to the applications themselves. The scenario you mentioned fits > >> well when the failure occurs during the partial parsing. During full > >> parsing, application logic can be introduced. > >> > >> best regards, > >> victor > > > > > >_______________________________________________ > >DiME mailing list > >DiME@ietf.org > >https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Sep 15 09:19:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GODbc-0007TE-9I; Fri, 15 Sep 2006 09:19:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GODba-0007Sh-W4 for dime@ietf.org; Fri, 15 Sep 2006 09:19:43 -0400 Received: from [203.199.83.120] (helo=rediffmail.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GODbU-0004Xo-PC for dime@ietf.org; Fri, 15 Sep 2006 09:19:42 -0400 Received: (qmail 23745 invoked by uid 510); 15 Sep 2006 13:16:46 -0000 Date: 15 Sep 2006 13:16:46 -0000 Message-ID: <20060915131646.23743.qmail@webmail52.rediffmail.com> Received: from unknown (202.131.155.13) by rediffmail.com via HTTP; 15 sep 2006 13:16:45 -0000 MIME-Version: 1.0 From: "Valesh Chandu" To: dime@ietf.org Subject: Re: RE: [Dime] Framed-ipv6-prefix data format X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: gwz@cisco.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Valesh Chandu List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0864784257==" Errors-To: dime-bounces@ietf.org This is a multipart mime message --===============0864784257== Content-type: multipart/alternative; boundary="Next_1158326205---0-203.199.83.120-23725" This is a multipart mime message --Next_1158326205---0-203.199.83.120-23725 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi all,=0A=0AOne more Query regarding this Framed-ipv6-prefix.=0A=0AMy doub= t is whether we have to include the Reserved Filed(one byte) also in the Da= ta filed of the Diameter Framed-ipv6-prefix AVP or not?=0A=0AHere is the Av= p Description from RFC(3162):=0A 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9= 0 1 2 3 4 5 6 7 8 9 0 1=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+=0A | Type | Length | Reserved |= Prefix-Length |=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+=0A Prefix=0A +-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A = Prefix=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+=0A Prefix=0A +-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A = Prefix |=0A +-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=0ASo what fields the data of Fr= amed-ipv6-prefix of Diameter AVP contains?=0A=0A=0AThanks in Advance.=0A=0A= Best Regards,=0AChandu. =0A=0AOn Wed, 13 Sep 2006 Glen Zorn(gwz) wrote :=0A= >Hi all,=0A>=0A>I have a small doubt regarding the Framed-ipv6-prefix Avp d= ata field,=0A>this AVP is a Radius(RFC-3162) Avp that contains prefix lengt= h and the=0A>actual prefix in binary format, in Diameter (RFC 4005) it is d= efined as=0A>a Octet String, but not explicitly mentioned about the data fi= led of the=0A>Avp i.e whether the data field contains both the prefix lengt= h and ipv6=0A>prefix or only the ipv6 prefix etc.=0A>=0A>i think the data f= ield of this Avp in Diameter should contain both the=0A>prefix length & act= ual prefix as in Radius but there is no evidence to=0A>confirm this.=0A>In = general, I think that in the absence of other evidence Diameter AVPs=0A>& R= ADIUS attributes that have the same type (in this case, 97) also have=0A>th= e same data format. So, yes, the Framed-IPV6-Prefix AVP includes the=0A>pr= efix length as the first octet of the Data field. In retrospect, it=0A>pro= bably would have been better to make this a grouped AVP with explicit=0A>ra= ther than implicit structure. Oh, well...=0A>=0A>So please any one could t= ell some standard document that is making clear=0A>this issue. Just I want = this for standard compliance and to avoid=0A>interoperability issues.=0A>Th= ough not explicit, RFC 3588 strongly implies that the data format of=0A>AVP= s 1-255 is essentially identical to that of RADIUS attributes with=0A>the s= ame type codes; see sections 4.1 & 11.1.1 of 3588.=0A>=0A>Thanks in advance= .=0A>=0A>Best Regards,=0A>Chandu=0A>=0A>=0A>=0A>ignature-home.htm/15071914= 90@Middle5?PARTNER=3D3>=0A --Next_1158326205---0-203.199.83.120-23725 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0AHi all,
=0A
=0AOne more Query regarding this Framed-ipv6-prefix= .
=0A
=0AMy doubt is whether we have to include the Reserved Filed(on= e byte) also in the Data filed of the Diameter Framed-ipv6-prefix AVP or no= t?
=0A
=0AHere is the Avp Description from RFC(3162):
=0A  &n= bsp; 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=0A=   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A  |    Type      |    Length=     |  Reserved    | Prefix-Length |
=0A = ; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A=                      = ;           Prefix
=0A  +-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A     =                     &nbs= p;     Prefix
=0A  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A           = ;                     Pre= fix
=0A  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
=0A                &nbs= p;               Prefix    &nb= sp;                     &= nbsp; |
=0A  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+
=0A
=0ASo what fields the data of Framed-ipv6-prefix of= Diameter AVP contains?
=0A
=0A
=0AThanks in Advance.
=0A
= =0ABest Regards,
=0AChandu.
=0A
=0AOn Wed, 13 Sep 2006 Glen Zorn(= gwz) wrote :
=0A>Hi all,
=0A>
=0A>I have a small doubt re= garding the Framed-ipv6-prefix Avp data field,
=0A>this AVP is a Radi= us(RFC-3162) Avp that contains prefix length and the
=0A>actual prefi= x in binary format, in Diameter (RFC 4005) it is defined as
=0A>a Oct= et String, but not explicitly mentioned about the data filed of the
=0A&= gt;Avp i.e whether the data field contains both the prefix length and ipv6<= BR>=0A>prefix or only the ipv6 prefix etc.
=0A>
=0A>i think = the data field of this Avp in Diameter should contain both the
=0A>pr= efix length & actual prefix as in Radius but there is no evidence to=0A>confirm this.
=0A>In general, I think that in the absence of = other evidence Diameter AVPs
=0A>& RADIUS attributes that have th= e same type (in this case, 97) also have
=0A>the same data format.&nb= sp; So, yes, the Framed-IPV6-Prefix AVP includes the
=0A>prefix lengt= h as the first octet of the Data field.  In retrospect, it
=0A>p= robably would have been better to make this a grouped AVP with explicit
= =0A>rather than implicit structure.  Oh, well...
=0A>
=0A&= gt;So please any one could tell some standard document that is making clear=
=0A>this issue. Just I want this for standard compliance and to avoi= d
=0A>interoperability issues.
=0A>Though not explicit, RFC 358= 8 strongly implies that the data format of
=0A>AVPs 1-255 is essentia= lly identical to that of RADIUS attributes with
=0A>the same type cod= es; see sections 4.1 & 11.1.1 of 3588.
=0A>
=0A>Thanks in a= dvance.
=0A>
=0A>Best Regards,
=0A>Chandu
=0A>
= =0A>
=0A>
=0A><http://adworks.rediff.com/cgi-bin/AdWorks/= sigclick.cgi/www.rediff.com/s
=0A>ignature-home.htm/1507191490@Middle= 5?PARTNER=3D3>
=0A=0A

=0A

=0A=0A --Next_1158326205---0-203.199.83.120-23725-- --===============0864784257== 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://www1.ietf.org/mailman/listinfo/dime --===============0864784257==-- From dime-bounces@ietf.org Fri Sep 15 11:25:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOFZ6-0006Cx-VT; Fri, 15 Sep 2006 11:25:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOFZ5-0006Cp-LO for dime@ietf.org; Fri, 15 Sep 2006 11:25:15 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOFZ4-0001W9-Mt for dime@ietf.org; Fri, 15 Sep 2006 11:25:15 -0400 Received: by ug-out-1314.google.com with SMTP id 72so148561ugd for ; Fri, 15 Sep 2006 08:25:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aVpuqrTdJPviMnnJADozykO4oAbP0LnDrY2cKmfy5kkq/c6RSRRU9doNWeTJaId2VAGFApdxHiRo64jVOb97imo1T92hdDGy8JC4EhsHiwyDMX+2+UB99+RZnw+s3l+FK3zsdysSpc0b6FgcBBXHDZPJ+b9e8ye1FpHVnEWctWs= Received: by 10.67.24.13 with SMTP id b13mr5438190ugj; Fri, 15 Sep 2006 08:25:13 -0700 (PDT) Received: by 10.66.243.16 with HTTP; Fri, 15 Sep 2006 08:25:13 -0700 (PDT) Message-ID: Date: Fri, 15 Sep 2006 17:25:13 +0200 From: "Gerardo Giaretta" To: "Julien Bournelle" Subject: Re: [Dime] Re: Authentication through 2 different "NAS" in the same time ? In-Reply-To: <20060915100737.GA6449@ipv6-3.int-evry.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060907152211.GA27475@ipv6-3.int-evry.fr> <20060907203328.GB18410@steelhead> <20060912121400.GA2527@ipv6-3.int-evry.fr> <20060912155310.GF2857@steelhead> <20060913085255.GA4025@ipv6-3.int-evry.fr> <20060913134306.GC15246@steelhead> <20060915093034.GA6298@ipv6-3.int-evry.fr> <20060915095651.GE30516@steelhead> <20060915100737.GA6449@ipv6-3.int-evry.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de8c36679aaa17b008853e74231c885 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Julien, maybe the MN does not need to use the same identity, but may use the same identity. It really depends on the identity management policies of the operator. So we should have a solution that works regardless the identity used by the MN is the same during network access and mip6 authentication or not. --Gerardo On 9/15/06, Julien Bournelle wrote: > On Fri, Sep 15, 2006 at 05:56:52AM -0400, Yoshihiro Ohba wrote: > > Hi Julien, > > > > On Fri, Sep 15, 2006 at 11:30:34AM +0200, Julien Bournelle wrote: > > > Hi yoshi, > > > > > > I have one more question concerning your approach. > > > > > > Considering the following scenario: > > > > > > MN <------> NAS <---4072 -(1)---> AAAH > > > ^ ^ > > > | | > > > +----------> HA <---4072 (2)------+ > > > > > > First, the MN is authenticated throught the NAS. The NAS uses Diameter > > > EAP and asks the AAAH for AAA for network access. > > > > > > Then, the MN acquires the HA and uses IKEv2 with it. If we use your > > > approach, the HA uses Diameter EAP with the AVP Auth-Request-Type set > > > to AUTHENTICATE_ONLY. > > > > > > I was wondering if it won't cause trouble to the AAAH since it has > > > already authenticated the MN through the NAS. > > > > If the operational policy of AAAH allows MN to perform multiple > > back-to-back authentication/authorization attempts via different > > authenticators, then there should be no issue. > > ok. I think that if we move forward with your approach we should add a > little text about this. > > > BTW, I have two questions. > > > > - Do the EAP via NAS and the EAP via HA need to hit the same AAAH > > server? I guess not. > > I don't think so. > > > - Do the EAP via NAS and the EAP via HA need to use the same Idenity? > > I guess not. > > I don't think so. > > regards, > > Julien > > > > > Regards, > > Yoshihiro Ohba > > > > > > > > > > Any comments on this ? > > > > > > regards, > > > > > > Julien > > > > > > > > > On Wed, Sep 13, 2006 at 09:43:06AM -0400, Yoshihiro Ohba wrote: > > > > Hi Julien, > > > > > > > > On Wed, Sep 13, 2006 at 10:52:55AM +0200, Julien Bournelle wrote: > > > > > > > > (snip) > > > > > > > > > > > > > > > However, if the AAA server somehow needs to know about it, the HA(NAS) > > > > > > can indicate it by including Auth-Request-Type AVP in DER with > > > > > > specifying "AUTHENTICATE_ONLY". > > > > > > > > > > ok. I see. I forgot this possibility. > > > > > So to sump up, the HA will use Diameter EAP with the Auth-Request-Type > > > > > aVP set to AUTHENTICATE_ONLY and the App-ID set to 5. If it receives a > > > > > success, it will switch to a Authorization/Accounting MIP6 Application > > > > > with a new App-ID. Is that right ? > > > > > > > > > > I think it can work but we need to investigate a little more before > > > > > moving with this. Points that I can see for now are: > > > > > > > > > > - The session-id must be shared between the Application. > > > > > > > > Why session-id must be shared? > > > > > > > > NASREQ usage for authorization purpose in RFC 4072 does not require > > > > it. Instead, User-Name AVP can be shared between the applications. > > > > In case the NAS(HA) is not able to retrieve the username from EAP > > > > messages, the AAA server can tell the NAS about the username by > > > > carrying User-Name AVP in DEA message, as described in RFC 4072. > > > > > > > > > - We must be sure that messages will reach the same AAA server. > > > > > > > > Why Diameter EAP messages and Diameter MIP6 messages need to hit the > > > > same AAA server? > > > > > > > > Again, NASREQ usage for authorization purpse in RFC 4072 does not > > > > require NASREQ and Diameter EAP messages to use the same AAA server. > > > > In general, authentication, authorization and accouting can use > > > > different AAA servers, and there should be no exception to MIP6 > > > > bootstrapping, IMO. > > > > > > > > > - We may have trouble with RADIUS compatibility > > > > > > > > This can be handled later. > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > Anyone has an opinion on this way to solve our issue ? > > > > > > > > > > Thanks yoshi, > > > > > > > > > > Julien > > > > > > > > > > > > > > > > > > > > > > > > > If we "push" a little what you propose, we could define an > > > > > > > "Authentication based on EAP" Application (only doing Authentication) > > > > > > > used by other Application that would only define their messages for > > > > > > > Authorization and Accounting (such as MIP6). That's why I talked to you > > > > > > > in a previous mail about also consider network access as a special > > > > > > > service and thus define Authz/Accounting messages for the "network > > > > > > > access" service. > > > > > > > > > > > > Yes, in the case of network access, you could use NASREQ for > > > > > > authorization purpose in additon to Diameter EAP for authentication > > > > > > purpose as specified in RFC 4072. > > > > > > > > > > > > Regards, > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > > > regards, > > > > > > > > > > > > > > Julien > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I also agree with Avi that defining a new application for MIP6 > > > > > > > > > > bootstrapping on top of existing applications (Diameter EAP) without > > > > > > > > > > defining a new application id but with defining new values for > > > > > > > > > > existing AVPs or new optional AVPs has some issue, but this option > > > > > > > > > > might not be as bad as the first option since backward compatibility > > > > > > > > > > can be easily maintained unlike the first option. However, there is a > > > > > > > > > > forward compatibility problem (i.e., a Diameter message may be forwarded > > > > > > > > > > to a AAA server that does not support the new application). Besides > > > > > > > > > > this problem, it might be worth pursuing this option because it works > > > > > > > > > > in an optimized way (i.e., bootstrapping AVPs are piggybacked in > > > > > > > > > > Diameter EAP or NASREQ message) as long as both NAS and AAA server > > > > > > > > > > support the AVPs. > > > > > > > > > > > > > > > > > > I'm not in favor of having an app-id for the nas-aaah part of the mip6 > > > > > > > > > bootstrapping problem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In order to deal with the forward compatibility problem of the second > > > > > > > > > > option, a third option is to define a new application for MIP6 > > > > > > > > > > bootstrapping as a totally new authorization application that carries > > > > > > > > > > new mandatory AVPs specific to that application. This option can be > > > > > > > > > > run when execution of the second option succeeds in authentication but > > > > > > > > > > fails in carrying bootstrapping AVPs. > > > > > > > > > > > > > > > > > > hmm, i guess i have to think more of this option but this would mandate > > > > > > > > > now that all EAP Application server should know that maybe they are not > > > > > > > > > doing this for network access and that maybe they are going to receive > > > > > > > > > a special authorization request. And in this case, wouldn't it mean > > > > > > > > > that network access should be treated as a special service and this > > > > > > > > > would also require a new authorization application ? > > > > > > > > > > > > > > > > > > regards, > > > > > > > > > > > > > > > > > > Julien > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Sep 05, 2006 at 11:21:22PM -0400, Avi Lior wrote: > > > > > > > > > > > Hi Kuntal, > > > > > > > > > > > > > > > > > > > > > > Neither option 1 or option 2 will work. A new application id just wont > > > > > > > > > > > scale in the long run. What if another 'capability' were to be added > > > > > > > > > > > for instance prepaid. Since Diameter messages contain only one > > > > > > > > > > > Application ID, you would have to create an Application Id that covered > > > > > > > > > > > both EAP, Prepaid and Mobile IP. And what if a third application were > > > > > > > > > > > added? The approach is not scalable as the applications are increased > > > > > > > > > > > -- you would have to cope with all the different permutations of > > > > > > > > > > > Applications. The same argument goes for ServiceType and PortType and > > > > > > > > > > > these are actually more problematic. > > > > > > > > > > > > > > > > > > > > > > IMO the only thing we can do is to hint at the capability of the NAS. > > > > > > > > > > > > > > > > > > > > > > A proper solution should be concieved for this problem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > > > > > > > > > > > Sent: Tuesday, September 05, 2006 2:09 PM > > > > > > > > > > > > To: Avi Lior; Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > > > > > > > > > > > Cc: dime@ietf.org > > > > > > > > > > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > > > > > > Service-Type > > > > > > > > > > > > > > > > > > > > > > > > All, > > > > > > > > > > > > > > > > > > > > > > > > Here is a scenario that may need to be covered. In some > > > > > > > > > > > > cases, local HA assignment is optimal for transport > > > > > > > > > > > > efficiency perspective. Diameter > > > > > > > > > > > > MIP4 application allows this. In such a case the ASP == MSP > > > > > > > > > > > > and the HA is assigned locally (in the visited network). > > > > > > > > > > > > > > > > > > > > > > > > To enable this case, in the integrated scenario, the NAS/VAAA > > > > > > > > > > > > needs to indicate it's capability to assign an HA in the > > > > > > > > > > > > local network to the HAAA. The HAAA may allow or disallow > > > > > > > > > > > > this local HA assignment based on policy of the MSA. > > > > > > > > > > > > > > > > > > > > > > > > The NAS/VAAA may need to include a hint in the AAA message to > > > > > > > > > > > > the HAAA at the time of access authentication that it is > > > > > > > > > > > > capable of providing an HA to the MN. This capability > > > > > > > > > > > > indication (hint) can be either sent via a new MIP6 specific > > > > > > > > > > > > AVP or it can be conveyed via an existing AVP (I don't know > > > > > > > > > > > > if one exists). > > > > > > > > > > > > > > > > > > > > > > > > If we decide to include this (local HA assignment), and we > > > > > > > > > > > > decide to include this mip6 specific hint in the NAS-HAAA > > > > > > > > > > > > communication, we may have to choose the most appropriate > > > > > > > > > > > > option (1) vs. (2). > > > > > > > > > > > > > > > > > > > > > > > > Comments? > > > > > > > > > > > > > > > > > > > > > > > > -Kuntal > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > > > > > > > > > > > Sent: Tuesday, September 05, 2006 6:07 AM > > > > > > > > > > > > > To: Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > > > > > > > > > > > > Cc: dime@ietf.org > > > > > > > > > > > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > > > > > > Service-Type > > > > > > > > > > > > > > > > > > > > > > > > > > I must be missing something. > > > > > > > > > > > > > > > > > > > > > > > > > > In the integrated scenario, what would the NAS put in Service-Type? > > > > > > > > > > > > > > > > > > > > > > > > > > I think in the integrated scenario neither Port-Type or > > > > > > > > > > > > Service-Type > > > > > > > > > > > > > needs to be touched. > > > > > > > > > > > > > > > > > > > > > > > > > > As far as I understand the NAS is either executing EAP > > > > > > > > > > > > Application or > > > > > > > > > > > > > NAS REQ. It does not know whether the user will result in having > > > > > > > > > > > > > subsequent Mobile IP service or not. > > > > > > > > > > > > > > > > > > > > > > > > > > The only thing the AAA server can do is to send the MIPv6 attributes > > > > > > > > > > > > as > > > > > > > > > > > > > optional (M bit off) and hope that if the NAS does not > > > > > > > > > > > > understand the > > > > > > > > > > > > > attributes it would have some logic to bootstrap a different way. > > > > > > > > > > > > > > > > > > > > > > > > > > We could improve the situration somewhat. We could have the NAS > > > > > > > > > > > > > indicate that it supports MIPv6 bootstrapping by including hints in > > > > > > > > > > > > the > > > > > > > > > > > > > AR (a capability hint). Where the NAS includes HA-IP address AVP > > > > > > > > > > > > both > > > > > > > > > > > > > indicating that it can support bootstrapping and if the > > > > > > > > > > > > HA-IP address > > > > > > > > > > > > is > > > > > > > > > > > > > not ALL-ZEROS or ALL ONES it provides a hint that it can support > > > > > > > > > > > > dynamic > > > > > > > > > > > > > HA assignement. > > > > > > > > > > > > > > > > > > > > > > > > > > Ofcourse we could introduce the concept of capability hints more > > > > > > > > > > > > > formally in Diameter -- This is missing today. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > > > > > > > > > > > > > Sent: Tuesday, September 05, 2006 3:35 AM > > > > > > > > > > > > > > To: Hannes.Tschofenig@gmx.net > > > > > > > > > > > > > > Cc: dime@ietf.org > > > > > > > > > > > > > > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > > > > > > > > Service-Type > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Hannes, > > > > > > > > > > > > > > > > > > > > > > > > > > > > I agree with Jouni. I prefer (2) for NAS-AAAH and (1) for > > > > > > > > > > > > AAAH-HA. > > > > > > > > > > > > > > In my understanding, there are no mandatory AVPs for NAS-AAAH and > > > > > > > > > > > > > > therefore I don't see a need of a new application; it's just a > > > > > > > > > > > > > > MIP-specific information that is piggybacked in the > > > > > > > > > > > > network access > > > > > > > > > > > > > > authentication procedure. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Concerning AAAH-HA, I think it is a much cleaner approach > > > > > > > > > > > > to define > > > > > > > > > > > > > > a new application, since it does not anything to do with network > > > > > > > > > > > > > > authentication. > > > > > > > > > > > > > > > > > > > > > > > > > > > > --Gerardo > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 9/5/06, jouni.korhonen@teliasonera.com > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > Hi HAnnes, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > > > > > > > > > > > > > Sent: 1. syyskuuta 2006 1:07 > > > > > > > > > > > > > > > > To: dime@ietf.org > > > > > > > > > > > > > > > > Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > > > > > > > > > > > > > > > > Service-Type > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > we have had long discussions about the App-ID vs. > > > > > > > > > > > > > > > > Service-Type usage for > > > > > > > > > > > > > > > > Diameter MIPv6 Bootstrapping. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It is time to see what the group thinks. Please indicate > > > > > > > > > > > > > > whether you > > > > > > > > > > > > > > > > prefer (1) an App-ID or (2) a Service-Type solution for > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (a) NAS-to-AAAH communication (as required by the integrated > > > > > > > > > > > > > > > > scenario; as one part of the solution component) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I would prefer (2) for now.. or as long as the NAS-2-AAAH main > > > > > > > > > > > > > > > function is to provide access authentication, where the backend > > > > > > > > > > > > AAA > > > > > > > > > > > > > > > may return > > > > > > > > > > > > > > > MIP6 > > > > > > > > > > > > > > > bootstrapping info (as an enhancement) based e.g. on the user > > > > > > > > > > > > > > > subscription profile. If we go for more stuff on > > > > > > > > > > > > NAS-2-AAAH like > > > > > > > > > > > > > > > HoA/prefix etc then > > > > > > > > > > > > > > > (1) > > > > > > > > > > > > > > > might be better. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (b) HA-to-AAAH communication (as used by the split > > > > > > > > > > > > > > scenario and the > > > > > > > > > > > > > > > > integrated scenario) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I would prefer (1) here. The use of EAP for MIP6 bootstrapping > > > > > > > > > > > > > > > purposes and for 'normal' EAP-based access authentication are > > > > > > > > > > > > > > > different applications imho. (although in IKEv2 vs 802.1X case > > > > > > > > > > > > e.g. > > > > > > > > > > > > > > > NAS-Port-Type could be used to make this distinction.. e.g. > > > > > > > > > > > > > > how 3GPP > > > > > > > > > > > > > > > WLAN stuff does it) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It might be useful to state a reason for your decision. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please also indicate whether some aspects are still > > > > > > > > > > > > > > unclear to you. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ciao > > > > > > > > > > > > > > > > Hannes > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > Jouni > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > DiME mailing list > > > > > > > > > > > > > > > > DiME@ietf.org > > > > > > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > DiME mailing list > > > > > > > > > > > > > > > DiME@ietf.org > > > > > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > DiME mailing list > > > > > > > > > > > > > > DiME@ietf.org > > > > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > DiME mailing list > > > > > > > > > > > > > DiME@ietf.org > > > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > "This email message and any attachments are confidential > > > > > > > > > > > > information of Starent Networks, Corp. The information > > > > > > > > > > > > transmitted may not be used to create or change any > > > > > > > > > > > > contractual obligations of Starent Networks, Corp. Any > > > > > > > > > > > > review, retransmission, dissemination or other use of, or > > > > > > > > > > > > taking of any action in reliance upon this e-mail and its > > > > > > > > > > > > attachments by persons or entities other than the intended > > > > > > > > > > > > recipient is prohibited. If you are not the intended > > > > > > > > > > > > recipient, please notify the sender immediately -- by > > > > > > > > > > > > replying to this message or by sending an email to > > > > > > > > > > > > postmaster@starentnetworks.com -- and destroy all copies of > > > > > > > > > > > > this message and any attachments without reading or > > > > > > > > > > > > disclosing their contents. Thank you." > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > DiME mailing list > > > > > > > > > > > DiME@ietf.org > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > DiME mailing list > > > > > > > > > > DiME@ietf.org > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > -- > > > > > > > > > julien.bournelle at int-evry.fr > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > julien.bournelle at int-evry.fr > > > > > > > > > > > > > > > > > -- > > > > > julien.bournelle at int-evry.fr > > > > > > > > > > > -- > > > julien.bournelle at int-evry.fr > > > > > -- > julien.bournelle at int-evry.fr > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Sep 15 11:36:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOFkD-0002tk-RT; Fri, 15 Sep 2006 11:36:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOFkC-0002tV-SK for dime@ietf.org; Fri, 15 Sep 2006 11:36:45 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOFkA-0002OH-HK for dime@ietf.org; Fri, 15 Sep 2006 11:36:44 -0400 Received: by ug-out-1314.google.com with SMTP id 72so149357ugd for ; Fri, 15 Sep 2006 08:36:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Fx3snMvhgpXaJw4Fic7V1jbVShq/sTQjDAg7mzvYpaMNMX/QoCXtC1t5jtqW/VeO5o8qJjh5dV9xlrbHbjUsrGeeWS/2hxXKARn3Z2vjkClCtE5xrVg1YQvnvm7hzOzWYFDNUJBvyZ5b4ZxUHei7HUQR08KwSyoc0DOrVojUOpQ= Received: by 10.67.89.5 with SMTP id r5mr5449799ugl; Fri, 15 Sep 2006 08:36:39 -0700 (PDT) Received: by 10.66.243.16 with HTTP; Fri, 15 Sep 2006 08:36:38 -0700 (PDT) Message-ID: Date: Fri, 15 Sep 2006 17:36:38 +0200 From: "Gerardo Giaretta" To: "Madjid Nakhjiri" Subject: Re: [Dime] Acronym MSA in MIP6 docs is unfortunate!! In-Reply-To: <00b401c6d84c$df637870$2f01a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <00b401c6d84c$df637870$2f01a8c0@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: mip6@ietf.org, dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Madjid, the acronym MSA has been used since the beginning of the Design Team work in mip6 and it's used in several drafts related to bootstrapping. I guess it would be really difficult to replace it. Moreover, Alpesh and I have already acked the PS draft during AUTH48 and therefore it would be not possible to make any change anyway. In my view, we can live with this acronym. The meaning of the acronym can be easily derived from the context of the sentence, imo. --Gerardo On 9/15/06, Madjid Nakhjiri wrote: > Sorry for chiming in so late: > > The term "Mobility Security Association" is used heavily in Mobile IPv4 > security and AAA interaction documentation: > > MIPv4 base spec 3344 > MIPv4 AAA key management 3957, > Diameter MIPv4, 4004 > Draft-nakhjiri-radius-mip4-02 > > Furthermore, Diameter spec (4004) uses the acronym MSA to refer to these > security association and uses "MSA" in naming a large number of AVPs for > Mobile IPv4 application. We followed the same terminology for defining > RADIUS attributes in the radius-mip4 draft. > > It is unfortunate that MIP6 WG has picked MSA as an acronym for "Mobility > service authorizer". As the work on bootstrapping MIP6 in Dime picks up, > there will be more and more confusion as people try to define AVPs to > address the security associations. > > Please replace the acronym for "Mobility service authorizer". > > Thanks, > > Madjid Nakhjiri > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Sep 15 12:55:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOGyU-0003ci-Ay; Fri, 15 Sep 2006 12:55:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOGyT-0003cV-26; Fri, 15 Sep 2006 12:55:33 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOGyR-0005ic-OJ; Fri, 15 Sep 2006 12:55:33 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J5N00DWD87BYO@usaga01-in.huawei.com>; Fri, 15 Sep 2006 09:52:23 -0700 (PDT) Received: from Nakhjiri73701 (pool-71-112-12-134.sttlwa.dsl-w.verizon.net [71.112.12.134]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J5N00DUM8772G@usaga01-in.huawei.com>; Fri, 15 Sep 2006 09:52:23 -0700 (PDT) Date: Fri, 15 Sep 2006 09:55:23 -0700 From: Madjid Nakhjiri Subject: RE: [Dime] Acronym MSA in MIP6 docs is unfortunate!! In-reply-to: To: 'Gerardo Giaretta' Message-id: <003c01c6d8e7$bce30f40$2f01a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcbY3VC0TBCiwoUTR2KOsa1+nRF1wAACbXTA X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: mip6@ietf.org, dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Gerardo, Not sure how long design team in mip6 has been working, but the mip4-AAA work went on since before I started at IETF!! I had AUTH48s that lasted more than 48 days, let alone 48 hours, but if you passed it within 48 hours, good for you. The warning was just too hard to resist:) I just hope you will never need an AVP that describes an "MSA assigned from a specific MSA", because then you need a lot more imagination naming that AVP:) Madjid -----Original Message----- From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] Sent: Friday, September 15, 2006 8:37 AM To: Madjid Nakhjiri Cc: mip6@ietf.org; dime@ietf.org Subject: Re: [Dime] Acronym MSA in MIP6 docs is unfortunate!! Hi Madjid, the acronym MSA has been used since the beginning of the Design Team work in mip6 and it's used in several drafts related to bootstrapping. I guess it would be really difficult to replace it. Moreover, Alpesh and I have already acked the PS draft during AUTH48 and therefore it would be not possible to make any change anyway. In my view, we can live with this acronym. The meaning of the acronym can be easily derived from the context of the sentence, imo. --Gerardo On 9/15/06, Madjid Nakhjiri wrote: > Sorry for chiming in so late: > > The term "Mobility Security Association" is used heavily in Mobile IPv4 > security and AAA interaction documentation: > > MIPv4 base spec 3344 > MIPv4 AAA key management 3957, > Diameter MIPv4, 4004 > Draft-nakhjiri-radius-mip4-02 > > Furthermore, Diameter spec (4004) uses the acronym MSA to refer to these > security association and uses "MSA" in naming a large number of AVPs for > Mobile IPv4 application. We followed the same terminology for defining > RADIUS attributes in the radius-mip4 draft. > > It is unfortunate that MIP6 WG has picked MSA as an acronym for "Mobility > service authorizer". As the work on bootstrapping MIP6 in Dime picks up, > there will be more and more confusion as people try to define AVPs to > address the security associations. > > Please replace the acronym for "Mobility service authorizer". > > Thanks, > > Madjid Nakhjiri > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Sep 15 13:39:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOHey-0005sy-4F; Fri, 15 Sep 2006 13:39:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOHew-0005sa-CK for dime@ietf.org; Fri, 15 Sep 2006 13:39:26 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOHeu-00039O-19 for dime@ietf.org; Fri, 15 Sep 2006 13:39:26 -0400 Received: from [10.1.201.0] ([10.1.201.0]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Sep 2006 10:38:24 -0700 Message-ID: <450AE47F.90707@azairenet.com> Date: Fri, 15 Sep 2006 10:35:59 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.5 (X11/20060812) MIME-Version: 1.0 To: Julien Bournelle Subject: Re: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part 2) References: <20060915102114.GA6527@ipv6-3.int-evry.fr> In-Reply-To: <20060915102114.GA6527@ipv6-3.int-evry.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Sep 2006 17:38:24.0470 (UTC) FILETIME=[BEB01F60:01C6D8ED] X-Spam-Score: 0.8 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Julien Bournelle wrote: > Hi all, > > this is a new polling concerning the ha-aaah interface for the Mobile > IPv6 Boostrapping. To date, at the previous one, there was a > consensus on moving forward with a new App-ID. But, yoshi has > proposed an interesting idea that should be considered by the WG. > > As you may recall, in the ha-aaah case, the MN is authenticated by > EAP (IKEv2 is used between MN and the HA) and thus the HA-AAAH > interface must, at least, be able to carry EAP packets. there was never an intention to restrict HA-AAAH interface to EAP only. other mechanisms are possible. using EAP over IKEv2 is just one way of using the AAA for the HA to authenticate a mobile node. Vijay It appears that > we now have 2 options: > > (1) We define a new Diameter application for Mobile IPv6 with a new > App-ID that carry EAP packets as it is done in RFC 4072 (Diameter > EAP) but Authorization and Accouting is specific to Mobile IPv6 > (thus the need for a new App-ID). The risk, as noted by yoshi, is > that an update of the RFC4072 may result in an update of this > application. > > > (2) We define a new Diameter Application for Mobile IPv6 but which is > used for Authorization and Accounting. We continue to use > Diameter EAP for the Authentication. Thus the HA will use > Diameter EAP with the AVP Auth-Request-Type set to > AUTHENTICATE_ONLY and then the HA will use this MIP6 Application > for Authorization/Accounting of the Mobile IPv6 service. This new > application will have its own App-ID. > > This would avoid to update the application if 4072 is updated and > this could be a way to proceed if other applications need EAP for > Authentication but have different needs for the Authorization and > Accounting part. > > Please indicate wether you prefer (1) or (2). > > As in the previous polling: > - it might be useful to state a reason for your decision. > - indicate wether some aspects are still unclear to you. > > Regards, > > Julien > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Sep 15 21:04:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOObJ-0000fp-5f; Fri, 15 Sep 2006 21:04:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOObI-0000fj-Al for dime@ietf.org; Fri, 15 Sep 2006 21:04:08 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOObG-0004QD-01 for dime@ietf.org; Fri, 15 Sep 2006 21:04:08 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J5N0012MUTNJW@usaga01-in.huawei.com> for dime@ietf.org; Fri, 15 Sep 2006 18:00:59 -0700 (PDT) Received: from Nakhjiri73701 (pool-71-112-12-134.sttlwa.dsl-w.verizon.net [71.112.12.134]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J5N003XAUTIFV@usaga01-in.huawei.com> for dime@ietf.org; Fri, 15 Sep 2006 18:00:59 -0700 (PDT) Date: Fri, 15 Sep 2006 18:03:57 -0700 From: Madjid Nakhjiri Subject: RE: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part 2) In-reply-to: <450AE47F.90707@azairenet.com> To: 'Vijay Devarapalli' , 'Julien Bournelle' Message-id: <00f801c6d92b$fcf47c60$2f01a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcbY7otyK5eFUJl1T7efMHKyndoe9wAPWvNg X-Spam-Score: 0.8 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I agree with Vijay. -----Original Message----- From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] Sent: Friday, September 15, 2006 10:36 AM To: Julien Bournelle Cc: dime@ietf.org Subject: Re: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part 2) Julien Bournelle wrote: > Hi all, > > this is a new polling concerning the ha-aaah interface for the Mobile > IPv6 Boostrapping. To date, at the previous one, there was a > consensus on moving forward with a new App-ID. But, yoshi has > proposed an interesting idea that should be considered by the WG. > > As you may recall, in the ha-aaah case, the MN is authenticated by > EAP (IKEv2 is used between MN and the HA) and thus the HA-AAAH > interface must, at least, be able to carry EAP packets. there was never an intention to restrict HA-AAAH interface to EAP only. other mechanisms are possible. using EAP over IKEv2 is just one way of using the AAA for the HA to authenticate a mobile node. Vijay It appears that > we now have 2 options: > > (1) We define a new Diameter application for Mobile IPv6 with a new > App-ID that carry EAP packets as it is done in RFC 4072 (Diameter > EAP) but Authorization and Accouting is specific to Mobile IPv6 > (thus the need for a new App-ID). The risk, as noted by yoshi, is > that an update of the RFC4072 may result in an update of this > application. > > > (2) We define a new Diameter Application for Mobile IPv6 but which is > used for Authorization and Accounting. We continue to use > Diameter EAP for the Authentication. Thus the HA will use > Diameter EAP with the AVP Auth-Request-Type set to > AUTHENTICATE_ONLY and then the HA will use this MIP6 Application > for Authorization/Accounting of the Mobile IPv6 service. This new > application will have its own App-ID. > > This would avoid to update the application if 4072 is updated and > this could be a way to proceed if other applications need EAP for > Authentication but have different needs for the Authorization and > Accounting part. > > Please indicate wether you prefer (1) or (2). > > As in the previous polling: > - it might be useful to state a reason for your decision. > - indicate wether some aspects are still unclear to you. > > Regards, > > Julien > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Sep 17 02:59:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOqcv-0000Ri-QI; Sun, 17 Sep 2006 02:59:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOqcu-0000Rc-40 for dime@ietf.org; Sun, 17 Sep 2006 02:59:40 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOqco-0003Ft-IF for dime@ietf.org; Sun, 17 Sep 2006 02:59:40 -0400 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k8H6w0Wa059612; Sun, 17 Sep 2006 02:58:01 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Date: Sun, 17 Sep 2006 02:57:56 -0400 To: Julien Bournelle Subject: Re: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part 2) Message-ID: <20060917065756.GA498@steelhead> References: <20060915102114.GA6527@ipv6-3.int-evry.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <20060915102114.GA6527@ipv6-3.int-evry.fr> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 69 X-Spam-Score: -1.6 (-) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Thank you for taking a new poll. I am in favor of option 2. Let me note that option 2 can also work for: - HA-AAAH case where non-EAP authentication is used for the authentication part. - NAS-AAAH case (I am not sure there is already a consensus on a solution for NAS-AAAH case). Again not only EAP but also non-EAP authentication application can be used for the authentication part. A difference from the HA-AAAH case is that Auth-Request-Type AVP of the authentication application would be set to AUTHORIZE_AUTHENTICATE in the NAS-AAAH case because network access service should be provided if authentication succeeds regardless of MIP6 service. Regards, Yoshihiro Ohba On Fri, Sep 15, 2006 at 12:21:14PM +0200, Julien Bournelle wrote: > Hi all, > > this is a new polling concerning the ha-aaah interface for the Mobile > IPv6 Boostrapping. To date, at the previous one, there was a > consensus on moving forward with a new App-ID. But, yoshi has > proposed an interesting idea that should be considered by the WG. > > As you may recall, in the ha-aaah case, the MN is authenticated by > EAP (IKEv2 is used between MN and the HA) and thus the HA-AAAH > interface must, at least, be able to carry EAP packets. It appears that > we now have 2 options: > > (1) We define a new Diameter application for Mobile IPv6 with a new > App-ID that carry EAP packets as it is done in RFC 4072 (Diameter > EAP) but Authorization and Accouting is specific to Mobile IPv6 > (thus the need for a new App-ID). The risk, as noted by yoshi, is > that an update of the RFC4072 may result in an update of this > application. > > > (2) We define a new Diameter Application for Mobile IPv6 but which is > used for Authorization and Accounting. We continue to use > Diameter EAP for the Authentication. Thus the HA will use > Diameter EAP with the AVP Auth-Request-Type set to > AUTHENTICATE_ONLY and then the HA will use this MIP6 Application > for Authorization/Accounting of the Mobile IPv6 service. This new > application will have its own App-ID. > > This would avoid to update the application if 4072 is updated and > this could be a way to proceed if other applications need EAP for > Authentication but have different needs for the Authorization and > Accounting part. > > Please indicate wether you prefer (1) or (2). > > As in the previous polling: > - it might be useful to state a reason for your decision. > - indicate wether some aspects are still unclear to you. > > Regards, > > Julien > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Sep 17 22:18:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP8i7-0000Q1-Kz; Sun, 17 Sep 2006 22:18:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP8i6-0000Pw-Hq for dime@ietf.org; Sun, 17 Sep 2006 22:18:14 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP8i4-000068-Uf for dime@ietf.org; Sun, 17 Sep 2006 22:18:14 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k8I2I2Hx003651; Mon, 18 Sep 2006 05:18:03 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Sep 2006 05:18:02 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Sep 2006 05:18:02 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Question of TCP and SCTP simultaneoous support in Diameter Date: Mon, 18 Sep 2006 05:18:02 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Question of TCP and SCTP simultaneoous support in Diameter Thread-Index: AcbYpQXZuNhKAmWURLWQ98xVSVdZsQCIz3IA From: To: , X-OriginalArrivalTime: 18 Sep 2006 02:18:02.0315 (UTC) FILETIME=[AAF539B0:01C6DAC8] X-Spam-Score: 0.3 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 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="===============1433029178==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1433029178== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6DAC8.AAD89BE5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6DAC8.AAD89BE5 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Preeti, =20 First, the IETF doesn't rate compliance. Are you asking if 3588 requires concurrent useage of TCP & SCTP, or something else. =20 Section 2.1 states: =20 Diameter clients MUST support either TCP or SCTP, while agents and servers MUST support both. Future versions of this specification MAY mandate that clients support SCTP. So, if you are concerned about complience, it would be safe to support both TCP and SCTP. =20 John ________________________________ From: ext Preeti Shandilya [mailto:preeti.shandilya@flextronicssoftware.com]=20 Sent: 15 September, 2006 11:54 To: dime@ietf.org Subject: [Dime] Question of TCP and SCTP simultaneoous support in Diameter =09 =09 Hi ! =09 I have question regarding the compliance of s product with RFC 3588. =09 If a diameter stack product complying to RFC 3588 does not support TCP and SCTP simultaneously, will that be considered as noncompliance. At some place RFC speaks that TCP and SCTP support is mandatory but at some place it indicates that support of TCP and SCTP support simultaneously is optional =09 Early reply is appreciated. =09 Regards Preeti ***************** FSS-Unclassified *************=20 "DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for the use of the=20 individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for=20 any purpose other than for what it is intended. If you have received=20 this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."=20 ------_=_NextPart_001_01C6DAC8.AAD89BE5 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Preeti,
 
First, the IETF doesn't rate compliance. Are = you asking if=20 3588 requires concurrent useage of TCP & SCTP, or something=20 else.
 
Section 2.1 states:
 
   =
Diameter clients MUST support either TCP or SCTP, while =
agents and
   servers MUST support both.  Future versions of this =
specification MAY
   mandate that clients support SCTP.
So, if you are concerned about com= plience, it would be safe to support b= oth TCP and SCTP.
 
John<= /DIV>

From: ext Preeti Shandilya=20 [mailto:preeti.shandilya@flextronicssoftware.com]
Sent: 15=20 September, 2006 11:54
To: dime@ietf.org
Subject: = [Dime]=20 Question of TCP and SCTP simultaneoous support in=20 Diameter

Hi !

I have question regarding the compliance of s product = with RFC=20 3588.

If a diameter stack product complying to RFC 3588 does = not=20 support TCP and SCTP simultaneously, will that be considered as=20 noncompliance.
At some place RFC speaks that TCP and SCTP support = is=20 mandatory but at some place it indicates that support of TCP and SCTP = support=20 simultaneously is optional

Early reply is=20 appreciated.

Regards
Preeti
***************** = FSS-Unclassified=20 *************
"DISCLAIMER: This message is proprietary to = Flextronics=20 Software
Systems Limited (FSS) and is intended solely for the use = of the=20
individual to whom it is addressed. It may contain privileged or=20
confidential information and should not be circulated or used for =
any=20 purpose other than for what it is intended. If you have received =
this=20 message in error, please notify the originator immediately.
If you = are not=20 the intended recipient, you are notified that you are
strictly = prohibited=20 from using, copying, altering, or disclosing
the contents of this = message.=20 FSS accepts no responsibility for
loss or damage arising from the = use of=20 the information transmitted
by this email including damage from = virus."=20

------_=_NextPart_001_01C6DAC8.AAD89BE5-- --===============1433029178== 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://www1.ietf.org/mailman/listinfo/dime --===============1433029178==-- From dime-bounces@ietf.org Sun Sep 17 22:24:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP8nm-0002AP-Jd; Sun, 17 Sep 2006 22:24:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP8nl-0002AK-5I for dime@ietf.org; Sun, 17 Sep 2006 22:24:05 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP8nj-0000yN-Md for dime@ietf.org; Sun, 17 Sep 2006 22:24:05 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k8I2Nw4I032273; Mon, 18 Sep 2006 05:23:59 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Sep 2006 05:23:59 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Sep 2006 05:23:58 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part 2) Date: Mon, 18 Sep 2006 05:23:58 +0300 Message-ID: In-Reply-To: <450AE47F.90707@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part 2) Thread-Index: AcbY7ghZQxUzHJZNSSeZXRxhRFrUuAB209mw From: To: , X-OriginalArrivalTime: 18 Sep 2006 02:23:58.0765 (UTC) FILETIME=[7F6B2DD0:01C6DAC9] X-Spam-Score: 1.0 (+) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Vijay, >> Hi all, >>=20 >> this is a new polling concerning the ha-aaah interface for the Mobile >> IPv6 Boostrapping. To date, at the previous one, there was a =20 >> consensus on moving forward with a new App-ID. But, yoshi has =20 >> proposed an interesting idea that should be considered by the WG. >>=20 >> As you may recall, in the ha-aaah case, the MN is authenticated by =20 >> EAP (IKEv2 is used between MN and the HA) and thus the HA-AAAH =20 >> interface must, at least, be able to carry EAP packets. > >there was never an intention to restrict HA-AAAH interface to=20 >EAP only. other mechanisms are possible. using EAP over IKEv2=20 >is just one way of using the AAA for the HA to authenticate a=20 >mobile node. I think Julien is suggesting that EAP could be the minimum requirement, but not restricting the solution to EAP. =20 Do you have a general opinion on any of the options that Julien is asking? John _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Sep 17 22:33:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP8wy-0004sU-I0; Sun, 17 Sep 2006 22:33:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP8wx-0004rq-5m for dime@ietf.org; Sun, 17 Sep 2006 22:33:35 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP8wv-0001nK-HU for dime@ietf.org; Sun, 17 Sep 2006 22:33:35 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k8I2XWY8010645; Mon, 18 Sep 2006 05:33:32 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Sep 2006 05:33:32 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Sep 2006 05:33:32 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Error Code issues for bis Date: Mon, 18 Sep 2006 05:33:31 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Error Code issues for bis Thread-Index: AcbYxaCCkS+/SmrWQ6uRvxizH1QqUwCBSk9Q From: To: , X-OriginalArrivalTime: 18 Sep 2006 02:33:32.0358 (UTC) FILETIME=[D54E8660:01C6DACA] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Tolga, I think that seems reasonable - does anyone else have comments on this - supporting or otherwise? It would be good to wrap this issue up. John=20 >-----Original Message----- >From: ext Tolga Asveren [mailto:asveren@ulticom.com]=20 >Sent: 15 September, 2006 15:50 >To: Loughney John (Nokia-NRC/Helsinki); dime@ietf.org >Subject: RE: [Dime] Error Code issues for bis > >John, > >My only goal is being able to use the grammar described in 7.2=20 >for permanent answers as well. For certain situations it is=20 >impossible to continue decoding a message, e.g. invalid AVP=20 >length for an AVP which is of type OctetString. In such a=20 >case, it may not be possible to generate an answer message=20 >based on the command's answer grammar, nor does it seem=20 >necessary to me. > >What I suggest is allowing E-bit to be set for permanent=20 >failures as well, so that grammar in 7.2 can be used. > >It is not important that all implementations follow that path,=20 >only the ones which consider it necessary/usefull for certain=20 >cases can use it. > >On receiver end, this shouldn't be a problem because if the=20 >E-bit is set, receiver will decode the message based on 7.2=20 >grammar, otherwise command answer grammar will be used. this=20 >rule is already there in RFC3588. > >After thinking a bit more, the only possible backward=20 >compatibility issue I see is, if some implementation checks=20 >whether E-bit is set for an answer with Result-Code other than=20 >Protocol Error. Considering that for some Permanent Failures=20 >7.2 grammar is really necessary, I believe that shouldn't be a=20 >big issue. > > Thanks, > Tolga > >> -----Original Message----- >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >> Sent: Thursday, September 14, 2006 11:34 PM >> To: asveren@ulticom.com; dime@ietf.org >> Subject: RE: [Dime] Error Code issues for bis >> >> >> Tolga, >> >> If it is optional, that means you can't count that any=20 >implementations=20 >> will support it. >> >> However, are you suggesting the E-bit could be used as a hint for=20 >> permantant failures? >> >> John >> >> >-----Original Message----- >> >From: ext Tolga Asveren [mailto:asveren@ulticom.com] >> >Sent: 14 September, 2006 21:14 >> >To: dime@ietf.org >> >Subject: RE: [Dime] Error Code issues for bis >> > >> >Hi Victor, >> > >> >I had a look to Issue14. I already thought that use of E-bit is=20 >> >exclusively for protocol errors based on "Note that these and only=20 >> >these erors MUST only be used in answer messages whose 'E' bit is=20 >> >set." in 7.1.3. The proposed text further supports this idea. >> > >> >I see a value of using E-bit for permanent failures as I tried to=20 >> >explain before. I think your concern is that people may=20 >choose not to=20 >> >use error answer-message grammar defined in 7.2 for certain=20 >permanent=20 >> >failures. To address both concerns, I suggest we allow use of E-bit=20 >> >for permanent failures but leave it as an implementation choice to=20 >> >use it or not. This again would be backward compatible AFAICS. >> > >> > Thanks, >> > Tolga >> > >> > >> > >> >> -----Original Message----- >> >> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >> >> Sent: Thursday, September 14, 2006 10:17 AM >> >> To: Tolga Asveren >> >> Cc: dime@ietf.org >> >> Subject: Re: [Dime] Error Code issues for bis >> >> >> >> >> >> Hi Tolga, >> >> >> >> Comments inline: >> >> >>> >> >> >> This maybe an easy way of performing error handling with just=20 >> >> >> sending the error grammar but it maybe to harsh (??). A node=20 >> >> >> receiving a result code set to some non-protocol failure >> >value may >> >> >> find it more useful to receive the application specific answer=20 >> >> >> message rather than just the error message in 7.2 since the=20 >> >> >> error may not be grave and the both end-point application can >> >attempt to recover and continue on. >> >> An example >> >> >> would be when the result code is set to MISSING_AVP or >> >> INVALID_AVP_VALUE >> >> >> and the answer message carries a Failed-AVP. Depending on the=20 >> >> >> application, the sender of the error may choose to continue=20 >> >> >> processing the remainder of the request if the offending >> >AVP is not >> >> >> crucial. The receiver of the error would view the error as a=20 >> >> >> hint maybe able to compensate/recover and continue on also. >> >> >> >> >> > [TOLGA]This is an interesting point but if such an answer is >> >> generated, how >> >> > could the peer know the real result of the request >> >processing? Let's >> >> > say Result-Code contains MISSING_AVP, how could the request >> >> originator determine >> >> > whether the request processing is done successfully? >> >> >> >> I was thinking through other avp's in the application >> >specific answer >> >> grammar ... though that maybe stretching the success/failure=20 >> >> significance of the result-code avp against other avps in >> >the message >> >> so may not as advisable. >> >> >> >> >> I guess this would depend if the implementation is doing full >> >> or partial >> >> >> parsing in the base protocol layer. >> >> >> >> >> > [TOLGA]I think I was not clear about this one. The message >> >is parsed >> >> > (or parsed as much as possible depending the type of the error). >> >> Now an answer >> >> > message needs to be generated. If the grammar of the >> >answer for that >> >> > specific command code is used, all mandatory AVPs which are >> >> specified in the >> >> > grammar need to be present. Those AVPs possibly could be filled=20 >> >> > without application logic involvement, but I would think this=20 >> >> > would >> >> require to put >> >> > some dummy values there. In such a case, what is the point of=20 >> >> > inserting them? >> >> > >> >> >> >> I was thinking in the case where the base protocol part of the=20 >> >> implementation does only partial parsing of message header >> >and avps it >> >> requires and leaves full parsing of the remaining >> >application specific >> >> avps to the applications themselves. The scenario you mentioned=20 >> >> fits well when the failure occurs during the partial parsing.=20 >> >> During full parsing, application logic can be introduced. >> >> >> >> best regards, >> >> victor >> > >> > >> >_______________________________________________ >> >DiME mailing list >> >DiME@ietf.org >> >https://www1.ietf.org/mailman/listinfo/dime >> > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Sep 18 04:54:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPEtY-0003QF-3B; Mon, 18 Sep 2006 04:54:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPEtW-0003Q5-AR for dime@ietf.org; Mon, 18 Sep 2006 04:54:26 -0400 Received: from jaguar.hughesbpo.net ([61.246.186.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPEtU-0008HZ-03 for dime@ietf.org; Mon, 18 Sep 2006 04:54:26 -0400 Received: from jaguar.hughesbpo.net (localhost [127.0.0.1]) by jaguar.hughesbpo.net (8.13.6/8.12.10) with ESMTP id k8I8u7j2018941 for ; Mon, 18 Sep 2006 14:26:08 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by jaguar.hughesbpo.net (8.13.6/8.13.6) with ESMTP id k8I8u7tH018915 for ; Mon, 18 Sep 2006 14:26:07 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id k8I8tAC05927 for ; Mon, 18 Sep 2006 14:25:10 +0530 (IST) In-Reply-To: <20060918065348.GK3916@steelhead> Sensitivity: To: dime@ietf.org X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Preeti Shandilya Date: Mon, 18 Sep 2006 14:23:14 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 18/09/2006 02:24:12 PM MIME-Version: 1.0 X-Spam-Score: 1.7 (+) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Subject: [Dime] Session timeout AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 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="===============1000773671==" Errors-To: dime-bounces@ietf.org --===============1000773671== Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable

Hi !

I have little confusion regarding session timeout AVP

RFC 3588 mentions about Session Timeout AVP. According to RFC, at the e= xpiry of the session timer, STR should be sent to peer node to clear th= e session.

Following specifications for Ro, Sh.Cx. Rf and CCA, do not refer to thi= s AVP in the messages.


    IETF Specifications

=B7 RFC 4006, Diamete= r Credit Control, March 2005
      3GPP Specifications
    =B7 3GPP TS 32.225 an= d 3GPP TS 32.299 v650 : Diameter Ro Interface
    =B7 3GPP TS 32.299 v6= 50 : Diameter Rf Interface
    =B7 3GPP TS 29.228: C= x and Dx interfaces : signaling flows and message contents
    =B7 3GPP TS 29.229: C= x and Dx Interfaces based on the Diameter protocol; Protocol Details
    =B7 3GPP TS 29.230: 3= GPP specific codes and identifiers
    =B7 3GPP TS 29.328: S= h interface : signaling flows and message content
    =B7 3GPP TS 29.329: S= h interface; Protocol details
    =B7 3GPP TS 32.240 v6= .3.0 Telecommunication management; Charging management; Charging archit= ecture and Principles

    So is this AVP meant for future version of the specification ?

    Regards
    Preeti
    ***************** FSS-Restricted *************
    "DISCLAIMER: This message is proprietary to Flextronics Software <= br> Systems Limited (FSS) and is intended solely for the use of the
    individual to whom it is addressed. It may contain privileged or
    confidential information and should not be circulated or used for
    any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately.
    If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing
    = the contents of this message. FSS accepts no responsibility for
    = loss or damage arising from the use of the information transmitted
    = by this email including damage from virus."= --===============1000773671== 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://www1.ietf.org/mailman/listinfo/dime --===============1000773671==-- From dime-bounces@ietf.org Mon Sep 18 11:35:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPL9y-0000MW-Gi; Mon, 18 Sep 2006 11:35:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPL9x-0000MQ-1X for dime@ietf.org; Mon, 18 Sep 2006 11:35:49 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPL9r-0005Eb-0d for dime@ietf.org; Mon, 18 Sep 2006 11:35:49 -0400 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 k8IFYIjV064678; Mon, 18 Sep 2006 11:34:18 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <450EBC7A.1000701@tari.toshiba.com> Date: Mon, 18 Sep 2006 11:34:18 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.5 (X11/20060812) MIME-Version: 1.0 To: Yoshihiro Ohba Subject: Re: [Dime] Error Code issues for bis References: <20060918065348.GK3916@steelhead> In-Reply-To: <20060918065348.GK3916@steelhead> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I've updated issue 14 to reflect the current opinion of which I also agree. Pls review the text if it is appropriate or if other folks has other opinions. regards, victor > I support Tolga's proposal on using E-bit and grammar described in 7.2 > for permanent errors in addition to protocol errors. > > Yoshihiro Ohba > > On Mon, Sep 18, 2006 at 05:33:31AM +0300, john.loughney@nokia.com wrote: > >> Tolga, >> >> I think that seems reasonable - does anyone else have comments >> on this - supporting or otherwise? It would be good to wrap >> this issue up. >> >> John >> >> >>> -----Original Message----- >>> From: ext Tolga Asveren [mailto:asveren@ulticom.com] >>> Sent: 15 September, 2006 15:50 >>> To: Loughney John (Nokia-NRC/Helsinki); dime@ietf.org >>> Subject: RE: [Dime] Error Code issues for bis >>> >>> John, >>> >>> My only goal is being able to use the grammar described in 7.2 >>> for permanent answers as well. For certain situations it is >>> impossible to continue decoding a message, e.g. invalid AVP >>> length for an AVP which is of type OctetString. In such a >>> case, it may not be possible to generate an answer message >>> based on the command's answer grammar, nor does it seem >>> necessary to me. >>> >>> What I suggest is allowing E-bit to be set for permanent >>> failures as well, so that grammar in 7.2 can be used. >>> >>> It is not important that all implementations follow that path, >>> only the ones which consider it necessary/usefull for certain >>> cases can use it. >>> >>> On receiver end, this shouldn't be a problem because if the >>> E-bit is set, receiver will decode the message based on 7.2 >>> grammar, otherwise command answer grammar will be used. this >>> rule is already there in RFC3588. >>> >>> After thinking a bit more, the only possible backward >>> compatibility issue I see is, if some implementation checks >>> whether E-bit is set for an answer with Result-Code other than >>> Protocol Error. Considering that for some Permanent Failures >>> 7.2 grammar is really necessary, I believe that shouldn't be a >>> big issue. >>> >>> Thanks, >>> Tolga >>> >>> >>>> -----Original Message----- >>>> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >>>> Sent: Thursday, September 14, 2006 11:34 PM >>>> To: asveren@ulticom.com; dime@ietf.org >>>> Subject: RE: [Dime] Error Code issues for bis >>>> >>>> >>>> Tolga, >>>> >>>> If it is optional, that means you can't count that any >>>> >>> implementations >>> >>>> will support it. >>>> >>>> However, are you suggesting the E-bit could be used as a hint for >>>> permantant failures? >>>> >>>> John >>>> >>>> >>>>> -----Original Message----- >>>>> From: ext Tolga Asveren [mailto:asveren@ulticom.com] >>>>> Sent: 14 September, 2006 21:14 >>>>> To: dime@ietf.org >>>>> Subject: RE: [Dime] Error Code issues for bis >>>>> >>>>> Hi Victor, >>>>> >>>>> I had a look to Issue14. I already thought that use of E-bit is >>>>> exclusively for protocol errors based on "Note that these and only >>>>> these erors MUST only be used in answer messages whose 'E' bit is >>>>> set." in 7.1.3. The proposed text further supports this idea. >>>>> >>>>> I see a value of using E-bit for permanent failures as I tried to >>>>> explain before. I think your concern is that people may >>>>> >>> choose not to >>> >>>>> use error answer-message grammar defined in 7.2 for certain >>>>> >>> permanent >>> >>>>> failures. To address both concerns, I suggest we allow use of E-bit >>>>> for permanent failures but leave it as an implementation choice to >>>>> use it or not. This again would be backward compatible AFAICS. >>>>> >>>>> Thanks, >>>>> Tolga >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >>>>>> Sent: Thursday, September 14, 2006 10:17 AM >>>>>> To: Tolga Asveren >>>>>> Cc: dime@ietf.org >>>>>> Subject: Re: [Dime] Error Code issues for bis >>>>>> >>>>>> >>>>>> Hi Tolga, >>>>>> >>>>>> Comments inline: >>>>>> >>>>>>>> This maybe an easy way of performing error handling with just >>>>>>>> sending the error grammar but it maybe to harsh (??). A node >>>>>>>> receiving a result code set to some non-protocol failure >>>>>>>> >>>>> value may >>>>> >>>>>>>> find it more useful to receive the application specific answer >>>>>>>> message rather than just the error message in 7.2 since the >>>>>>>> error may not be grave and the both end-point application can >>>>>>>> >>>>> attempt to recover and continue on. >>>>> >>>>>> An example >>>>>> >>>>>>>> would be when the result code is set to MISSING_AVP or >>>>>>>> >>>>>> INVALID_AVP_VALUE >>>>>> >>>>>>>> and the answer message carries a Failed-AVP. Depending on the >>>>>>>> application, the sender of the error may choose to continue >>>>>>>> processing the remainder of the request if the offending >>>>>>>> >>>>> AVP is not >>>>> >>>>>>>> crucial. The receiver of the error would view the error as a >>>>>>>> hint maybe able to compensate/recover and continue on also. >>>>>>>> >>>>>>>> >>>>>>> [TOLGA]This is an interesting point but if such an answer is >>>>>>> >>>>>> generated, how >>>>>> >>>>>>> could the peer know the real result of the request >>>>>>> >>>>> processing? Let's >>>>> >>>>>>> say Result-Code contains MISSING_AVP, how could the request >>>>>>> >>>>>> originator determine >>>>>> >>>>>>> whether the request processing is done successfully? >>>>>>> >>>>>> I was thinking through other avp's in the application >>>>>> >>>>> specific answer >>>>> >>>>>> grammar ... though that maybe stretching the success/failure >>>>>> significance of the result-code avp against other avps in >>>>>> >>>>> the message >>>>> >>>>>> so may not as advisable. >>>>>> >>>>>> >>>>>>>> I guess this would depend if the implementation is doing full >>>>>>>> >>>>>> or partial >>>>>> >>>>>>>> parsing in the base protocol layer. >>>>>>>> >>>>>>>> >>>>>>> [TOLGA]I think I was not clear about this one. The message >>>>>>> >>>>> is parsed >>>>> >>>>>>> (or parsed as much as possible depending the type of the error). >>>>>>> >>>>>> Now an answer >>>>>> >>>>>>> message needs to be generated. If the grammar of the >>>>>>> >>>>> answer for that >>>>> >>>>>>> specific command code is used, all mandatory AVPs which are >>>>>>> >>>>>> specified in the >>>>>> >>>>>>> grammar need to be present. Those AVPs possibly could be filled >>>>>>> without application logic involvement, but I would think this >>>>>>> would >>>>>>> >>>>>> require to put >>>>>> >>>>>>> some dummy values there. In such a case, what is the point of >>>>>>> inserting them? >>>>>>> >>>>>>> >>>>>> I was thinking in the case where the base protocol part of the >>>>>> implementation does only partial parsing of message header >>>>>> >>>>> and avps it >>>>> >>>>>> requires and leaves full parsing of the remaining >>>>>> >>>>> application specific >>>>> >>>>>> avps to the applications themselves. The scenario you mentioned >>>>>> fits well when the failure occurs during the partial parsing. >>>>>> During full parsing, application logic can be introduced. >>>>>> >>>>>> best regards, >>>>>> victor >>>>>> >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/dime >>>>> >>>>> >>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> >> >> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Sep 18 15:08:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPOTN-0003b5-17; Mon, 18 Sep 2006 15:08:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPOTL-0003aw-UY for dime@ietf.org; Mon, 18 Sep 2006 15:08:03 -0400 Received: from ns1.nitro.ca ([216.209.86.226] helo=mailscanner.nitro.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPOTK-0001v9-Fm for dime@ietf.org; Mon, 18 Sep 2006 15:08:03 -0400 Received: from bws14.bridgewatersystems.com (bws14.bridgewatersystems.com [216.113.7.14]) by mailscanner.nitro.ca (8.12.11/8.12.11) with ESMTP id k8IJ7bKb026941; Mon, 18 Sep 2006 15:07:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Sep 2006 15:07:44 -0400 Message-ID: In-Reply-To: <20060915100737.GA6449@ipv6-3.int-evry.fr> From: "Avi Lior" To: "Julien Bournelle" , "Yoshihiro Ohba" X-Nitro-MailScanner-Information: Please contact the ISP for more information X-Nitro-MailScanner: Found to be clean X-Nitro-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.599, required 4, autolearn=not spam, BAYES_00 -2.60) X-MailScanner-From: avi@bridgewatersystems.com X-Spam-Score: 0.1 (/) X-Scan-Signature: d273fad2623d4a35a7bb17d92c76f399 Cc: dime@ietf.org Subject: [Dime] RE: Authentication through 2 different "NAS" in the same time ? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I do have a question/comment. In the second part where the HA authenticates you specify that the HA uses AUTHENTICATE-ONLY. I don't think that that should be necessarily true. There may be authorization attributes that could be delivered to the HA. We shouldn't limit that transaction to AUTHENTICATE-ONLY. In fact it may be AUTHORIZE-ONLY but that depends on what your draft is doing. =20 > -----Original Message----- > From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]=20 > Sent: Friday, September 15, 2006 6:08 AM > To: Yoshihiro Ohba > Cc: Julien Bournelle; Avi Lior; dime@ietf.org > Subject: Re: Authentication through 2 different "NAS" in the=20 > same time ? >=20 > On Fri, Sep 15, 2006 at 05:56:52AM -0400, Yoshihiro Ohba wrote: > > Hi Julien, > >=20 > > On Fri, Sep 15, 2006 at 11:30:34AM +0200, Julien Bournelle wrote: > > > Hi yoshi, > > >=20 > > > I have one more question concerning your approach. > > >=20 > > > Considering the following scenario: > > >=20 > > > MN <------> NAS <---4072 -(1)---> AAAH > > > ^ ^ > > > | | > > > +----------> HA <---4072 (2)------+ > > > =20 > > > First, the MN is authenticated throught the NAS. The NAS uses=20 > > > Diameter EAP and asks the AAAH for AAA for network access. > > >=20 > > > Then, the MN acquires the HA and uses IKEv2 with it. If=20 > we use your =20 > > > approach, the HA uses Diameter EAP with the AVP Auth-Request-Type=20 > > > set to AUTHENTICATE_ONLY. > > >=20 > > > I was wondering if it won't cause trouble to the AAAH=20 > since it has =20 > > > already authenticated the MN through the NAS. > >=20 > > If the operational policy of AAAH allows MN to perform multiple=20 > > back-to-back authentication/authorization attempts via different=20 > > authenticators, then there should be no issue. >=20 > ok. I think that if we move forward with your approach we=20 > should add a little text about this. >=20 > > BTW, I have two questions. > >=20 > > - Do the EAP via NAS and the EAP via HA need to hit the same AAAH=20 > > server? I guess not. >=20 > I don't think so. >=20 > > - Do the EAP via NAS and the EAP via HA need to use the=20 > same Idenity? > > I guess not. >=20 > I don't think so. >=20 > regards, >=20 > Julien >=20 > >=20 > > Regards, > > Yoshihiro Ohba > >=20 > >=20 > > >=20 > > > Any comments on this ? > > >=20 > > > regards, > > >=20 > > > Julien > > > =20 > > >=20 > > > On Wed, Sep 13, 2006 at 09:43:06AM -0400, Yoshihiro Ohba wrote: > > > > Hi Julien, > > > >=20 > > > > On Wed, Sep 13, 2006 at 10:52:55AM +0200, Julien=20 > Bournelle wrote: > > > >=20 > > > > (snip) > > > >=20 > > > > >=20 > > > > > > However, if the AAA server somehow needs to know=20 > about it, the=20 > > > > > > HA(NAS) can indicate it by including=20 > Auth-Request-Type AVP in=20 > > > > > > DER with specifying "AUTHENTICATE_ONLY". > > > > >=20 > > > > > ok. I see. I forgot this possibility. > > > > > So to sump up, the HA will use Diameter EAP with the=20 > > > > > Auth-Request-Type aVP set to AUTHENTICATE_ONLY and=20 > the App-ID=20 > > > > > set to 5. If it receives a success, it will switch to a=20 > > > > > Authorization/Accounting MIP6 Application with a new=20 > App-ID. Is that right ? > > > > >=20 > > > > > I think it can work but we need to investigate a little more=20 > > > > > before moving with this. Points that I can see for now are: > > > > >=20 > > > > > - The session-id must be shared between the Application. > > > >=20 > > > > Why session-id must be shared? =20 > > > >=20 > > > > NASREQ usage for authorization purpose in RFC 4072 does not=20 > > > > require it. Instead, User-Name AVP can be shared=20 > between the applications. > > > > In case the NAS(HA) is not able to retrieve the=20 > username from EAP=20 > > > > messages, the AAA server can tell the NAS about the username by=20 > > > > carrying User-Name AVP in DEA message, as described in RFC 4072. > > > >=20 > > > > > - We must be sure that messages will reach the same=20 > AAA server. > > > >=20 > > > > Why Diameter EAP messages and Diameter MIP6 messages=20 > need to hit=20 > > > > the same AAA server? > > > >=20 > > > > Again, NASREQ usage for authorization purpse in RFC=20 > 4072 does not=20 > > > > require NASREQ and Diameter EAP messages to use the=20 > same AAA server. > > > > In general, authentication, authorization and accouting can use=20 > > > > different AAA servers, and there should be no exception to MIP6=20 > > > > bootstrapping, IMO. > > > >=20 > > > > > - We may have trouble with RADIUS compatibility > > > >=20 > > > > This can be handled later. > > > >=20 > > > > Yoshihiro Ohba > > > >=20 > > > >=20 > > > > > =20 > > > > > Anyone has an opinion on this way to solve our issue ?=20 > > > > >=20 > > > > > Thanks yoshi, > > > > >=20 > > > > > Julien > > > > >=20 > > > > > >=20 > > > > > > >=20 > > > > > > > If we "push" a little what you propose, we could=20 > define an =20 > > > > > > > "Authentication based on EAP" Application (only doing=20 > > > > > > > Authentication) used by other Application that=20 > would only=20 > > > > > > > define their messages for Authorization and Accounting=20 > > > > > > > (such as MIP6). That's why I talked to you in a previous=20 > > > > > > > mail about also consider network access as a special =20 > > > > > > > service and thus define Authz/Accounting messages=20 > for the "network access" service. > > > > > >=20 > > > > > > Yes, in the case of network access, you could use=20 > NASREQ for=20 > > > > > > authorization purpose in additon to Diameter EAP for=20 > > > > > > authentication purpose as specified in RFC 4072. > > > > > >=20 > > > > > > Regards, > > > > > > Yoshihiro Ohba > > > > > >=20 > > > > > >=20 > > > > > > >=20 > > > > > > > regards, > > > > > > >=20 > > > > > > > Julien > > > > > > >=20 > > > > > > > >=20 > > > > > > > > Regards, > > > > > > > > Yoshihiro Ohba > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > > I also agree with Avi that defining a new=20 > application=20 > > > > > > > > > > for MIP6 bootstrapping on top of existing=20 > applications=20 > > > > > > > > > > (Diameter EAP) without defining a new=20 > application id=20 > > > > > > > > > > but with defining new values for existing=20 > AVPs or new=20 > > > > > > > > > > optional AVPs has some issue, but this option might=20 > > > > > > > > > > not be as bad as the first option since backward=20 > > > > > > > > > > compatibility can be easily maintained unlike the=20 > > > > > > > > > > first option. However, there is a forward=20 > > > > > > > > > > compatibility problem (i.e., a Diameter=20 > message may be=20 > > > > > > > > > > forwarded to a AAA server that does not support the=20 > > > > > > > > > > new application). Besides this problem, it=20 > might be=20 > > > > > > > > > > worth pursuing this option because it works=20 > in an optimized way (i.e., bootstrapping AVPs are piggybacked=20 > in Diameter EAP or NASREQ message) as long as both NAS and=20 > AAA server support the AVPs. > > > > > > > > >=20 > > > > > > > > > I'm not in favor of having an app-id for the=20 > nas-aaah=20 > > > > > > > > > part of the mip6 bootstrapping problem. > > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > > In order to deal with the forward compatibility=20 > > > > > > > > > > problem of the second option, a third option is to=20 > > > > > > > > > > define a new application for MIP6=20 > bootstrapping as a=20 > > > > > > > > > > totally new authorization application that=20 > carries new=20 > > > > > > > > > > mandatory AVPs specific to that application. This=20 > > > > > > > > > > option can be run when execution of the=20 > second option succeeds in authentication but fails in=20 > carrying bootstrapping AVPs. > > > > > > > > >=20 > > > > > > > > > hmm, i guess i have to think more of this option but=20 > > > > > > > > > this would mandate now that all EAP=20 > Application server=20 > > > > > > > > > should know that maybe they are not doing this for=20 > > > > > > > > > network access and that maybe they are going=20 > to receive =20 > > > > > > > > > a special authorization request. And in this case,=20 > > > > > > > > > wouldn't it mean that network access should=20 > be treated as a special service and this would also require=20 > a new authorization application ? > > > > > > > > >=20 > > > > > > > > > regards, > > > > > > > > >=20 > > > > > > > > > Julien > > > > > > > > > >=20 > > > > > > > > > > Regards, > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > > On Tue, Sep 05, 2006 at 11:21:22PM -0400,=20 > Avi Lior wrote: > > > > > > > > > > > Hi Kuntal, > > > > > > > > > > >=20 > > > > > > > > > > > Neither option 1 or option 2 will work. A new=20 > > > > > > > > > > > application id just wont scale in the long run. =20 > > > > > > > > > > > What if another 'capability' were to be added for=20 > > > > > > > > > > > instance prepaid. Since Diameter=20 > messages contain=20 > > > > > > > > > > > only one Application ID, you would have=20 > to create=20 > > > > > > > > > > > an Application Id that covered both EAP,=20 > Prepaid and=20 > > > > > > > > > > > Mobile IP. And what if a third application were=20 > > > > > > > > > > > added? The approach is not scalable as the=20 > > > > > > > > > > > applications are increased > > > > > > > > > > > -- you would have to cope with all the different=20 > > > > > > > > > > > permutations of Applications. The same argument=20 > > > > > > > > > > > goes for ServiceType and PortType and=20 > these are actually more problematic. > > > > > > > > > > >=20 > > > > > > > > > > > IMO the only thing we can do is to hint=20 > at the capability of the NAS. =20 > > > > > > > > > > >=20 > > > > > > > > > > > A proper solution should be concieved for=20 > this problem. > > > > > > > > > > > =20 > > > > > > > > > > >=20 > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Chowdhury, Kuntal=20 > > > > > > > > > > > > [mailto:kchowdhury@starentnetworks.com] > > > > > > > > > > > > Sent: Tuesday, September 05, 2006 2:09 PM > > > > > > > > > > > > To: Avi Lior; Gerardo Giaretta;=20 > > > > > > > > > > > > Hannes.Tschofenig@gmx.net > > > > > > > > > > > > Cc: dime@ietf.org > > > > > > > > > > > > Subject: RE: [Dime] Diameter MIPv6=20 > Bootstrapping: App-ID vs.=20 > > > > > > > > > > > > Service-Type > > > > > > > > > > > >=20 > > > > > > > > > > > > All, > > > > > > > > > > > >=20 > > > > > > > > > > > > Here is a scenario that may need to be=20 > covered. In=20 > > > > > > > > > > > > some cases, local HA assignment is optimal for=20 > > > > > > > > > > > > transport efficiency perspective. Diameter > > > > > > > > > > > > MIP4 application allows this. In such a=20 > case the=20 > > > > > > > > > > > > ASP =3D=3D MSP and the HA is assigned=20 > locally (in the visited network). > > > > > > > > > > > >=20 > > > > > > > > > > > > To enable this case, in the integrated=20 > scenario,=20 > > > > > > > > > > > > the NAS/VAAA needs to indicate it's=20 > capability to=20 > > > > > > > > > > > > assign an HA in the local network to=20 > the HAAA. The=20 > > > > > > > > > > > > HAAA may allow or disallow this local=20 > HA assignment based on policy of the MSA. > > > > > > > > > > > >=20 > > > > > > > > > > > > The NAS/VAAA may need to include a hint=20 > in the AAA=20 > > > > > > > > > > > > message to the HAAA at the time of access=20 > > > > > > > > > > > > authentication that it is capable of=20 > providing an=20 > > > > > > > > > > > > HA to the MN. This capability indication (hint)=20 > > > > > > > > > > > > can be either sent via a new MIP6=20 > specific AVP or=20 > > > > > > > > > > > > it can be conveyed via an existing AVP=20 > (I don't know if one exists). > > > > > > > > > > > >=20 > > > > > > > > > > > > If we decide to include this (local HA=20 > > > > > > > > > > > > assignment), and we decide to include this mip6=20 > > > > > > > > > > > > specific hint in the NAS-HAAA communication, we=20 > > > > > > > > > > > > may have to choose the most appropriate=20 > option (1) vs. (2). > > > > > > > > > > > >=20 > > > > > > > > > > > > Comments? > > > > > > > > > > > >=20 > > > > > > > > > > > > -Kuntal > > > > > > > > > > > >=20 > > > > > > > > > > > >=20 > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > From: Avi Lior=20 > > > > > > > > > > > > > [mailto:avi@bridgewatersystems.com] > > > > > > > > > > > > > Sent: Tuesday, September 05, 2006 6:07 AM > > > > > > > > > > > > > To: Gerardo Giaretta;=20 > Hannes.Tschofenig@gmx.net > > > > > > > > > > > > > Cc: dime@ietf.org > > > > > > > > > > > > > Subject: RE: [Dime] Diameter MIPv6=20 > Bootstrapping: App-ID vs. > > > > > > > > > > > > Service-Type > > > > > > > > > > > > >=20 > > > > > > > > > > > > > I must be missing something. > > > > > > > > > > > > >=20 > > > > > > > > > > > > > In the integrated scenario, what=20 > would the NAS put in Service-Type? > > > > > > > > > > > > >=20 > > > > > > > > > > > > > I think in the integrated scenario neither=20 > > > > > > > > > > > > > Port-Type or > > > > > > > > > > > > Service-Type > > > > > > > > > > > > > needs to be touched. > > > > > > > > > > > > >=20 > > > > > > > > > > > > > As far as I understand the NAS is either=20 > > > > > > > > > > > > > executing EAP > > > > > > > > > > > > Application or > > > > > > > > > > > > > NAS REQ. It does not know whether=20 > the user will=20 > > > > > > > > > > > > > result in having subsequent Mobile IP=20 > service or not. > > > > > > > > > > > > >=20 > > > > > > > > > > > > > The only thing the AAA server can do=20 > is to send=20 > > > > > > > > > > > > > the MIPv6 attributes > > > > > > > > > > > > as > > > > > > > > > > > > > optional (M bit off) and hope that if the NAS=20 > > > > > > > > > > > > > does not > > > > > > > > > > > > understand the > > > > > > > > > > > > > attributes it would have some logic=20 > to bootstrap a different way. > > > > > > > > > > > > >=20 > > > > > > > > > > > > > We could improve the situration somewhat. We=20 > > > > > > > > > > > > > could have the NAS indicate that it supports=20 > > > > > > > > > > > > > MIPv6 bootstrapping by including hints in > > > > > > > > > > > > the > > > > > > > > > > > > > AR (a capability hint). Where the=20 > NAS includes HA-IP address AVP > > > > > > > > > > > > both > > > > > > > > > > > > > indicating that it can support=20 > bootstrapping and=20 > > > > > > > > > > > > > if the > > > > > > > > > > > > HA-IP address > > > > > > > > > > > > is > > > > > > > > > > > > > not ALL-ZEROS or ALL ONES it provides a hint=20 > > > > > > > > > > > > > that it can support > > > > > > > > > > > > dynamic > > > > > > > > > > > > > HA assignement. > > > > > > > > > > > > >=20 > > > > > > > > > > > > > Ofcourse we could introduce the concept of=20 > > > > > > > > > > > > > capability hints more formally in=20 > Diameter -- This is missing today. > > > > > > > > > > > > >=20 > > > > > > > > > > > > >=20 > > > > > > > > > > > > >=20 > > > > > > > > > > > > >=20 > > > > > > > > > > > > >=20 > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > From: Gerardo Giaretta=20 > > > > > > > > > > > > > > [mailto:gerardo.giaretta@gmail.com] > > > > > > > > > > > > > > Sent: Tuesday, September 05, 2006 3:35 AM > > > > > > > > > > > > > > To: Hannes.Tschofenig@gmx.net > > > > > > > > > > > > > > Cc: dime@ietf.org > > > > > > > > > > > > > > Subject: Re: [Dime] Diameter MIPv6=20 > Bootstrapping: App-ID vs. > > > > > > > > > > > > > > Service-Type > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Hannes, > > > > > > > > > > > > > > > > > > > > > > > > > > > > I agree with Jouni. I prefer (2)=20 > for NAS-AAAH=20 > > > > > > > > > > > > > > and (1) for > > > > > > > > > > > > AAAH-HA.=20 > > > > > > > > > > > > > > In my understanding, there are no mandatory=20 > > > > > > > > > > > > > > AVPs for NAS-AAAH and therefore I=20 > don't see a=20 > > > > > > > > > > > > > > need of a new application; it's just a=20 > > > > > > > > > > > > > > MIP-specific information that is=20 > piggybacked=20 > > > > > > > > > > > > > > in the > > > > > > > > > > > > network access > > > > > > > > > > > > > > authentication procedure. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Concerning AAAH-HA, I think it is a much=20 > > > > > > > > > > > > > > cleaner approach > > > > > > > > > > > > to define > > > > > > > > > > > > > > a new application, since it does=20 > not anything=20 > > > > > > > > > > > > > > to do with network authentication. > > > > > > > > > > > > > > > > > > > > > > > > > > > > --Gerardo > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 9/5/06, jouni.korhonen@teliasonera.com=20 > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > Hi HAnnes, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > > From: Hannes Tschofenig=20 > > > > > > > > > > > > > > > > [mailto:Hannes.Tschofenig@gmx.net] > > > > > > > > > > > > > > > > Sent: 1. syyskuuta 2006 1:07 > > > > > > > > > > > > > > > > To: dime@ietf.org > > > > > > > > > > > > > > > > Subject: [Dime] Diameter MIPv6=20 > Bootstrapping: App-ID vs. > > > > > > > > > > > > > > > > Service-Type > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > we have had long discussions=20 > about the App-ID vs. > > > > > > > > > > > > > > > > Service-Type usage for Diameter MIPv6=20 > > > > > > > > > > > > > > > > Bootstrapping. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It is time to see what the=20 > group thinks.=20 > > > > > > > > > > > > > > > > Please indicate > > > > > > > > > > > > > > whether you > > > > > > > > > > > > > > > > prefer (1) an App-ID or (2) a=20 > Service-Type=20 > > > > > > > > > > > > > > > > solution for > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (a) NAS-to-AAAH communication=20 > (as required=20 > > > > > > > > > > > > > > > > by the integrated scenario; as=20 > one part of=20 > > > > > > > > > > > > > > > > the solution component) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I would prefer (2) for now.. or=20 > as long as=20 > > > > > > > > > > > > > > > the NAS-2-AAAH main function is=20 > to provide=20 > > > > > > > > > > > > > > > access authentication, where the backend > > > > > > > > > > > > AAA > > > > > > > > > > > > > > > may return > > > > > > > > > > > > > > > MIP6 > > > > > > > > > > > > > > > bootstrapping info (as an=20 > enhancement) based=20 > > > > > > > > > > > > > > > e.g. on the user subscription=20 > profile. If we=20 > > > > > > > > > > > > > > > go for more stuff on > > > > > > > > > > > > NAS-2-AAAH like > > > > > > > > > > > > > > > HoA/prefix etc then > > > > > > > > > > > > > > > (1) > > > > > > > > > > > > > > > might be better. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (b) HA-to-AAAH communication=20 > (as used by=20 > > > > > > > > > > > > > > > > the split > > > > > > > > > > > > > > scenario and the > > > > > > > > > > > > > > > > integrated scenario) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I would prefer (1) here. The use=20 > of EAP for=20 > > > > > > > > > > > > > > > MIP6 bootstrapping purposes and=20 > for 'normal'=20 > > > > > > > > > > > > > > > EAP-based access authentication are=20 > > > > > > > > > > > > > > > different applications imho. (although in=20 > > > > > > > > > > > > > > > IKEv2 vs 802.1X case > > > > > > > > > > > > e.g. > > > > > > > > > > > > > > > NAS-Port-Type could be used to=20 > make this distinction.. e.g. > > > > > > > > > > > > > > how 3GPP > > > > > > > > > > > > > > > WLAN stuff does it) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It might be useful to state a=20 > reason for your decision. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please also indicate whether=20 > some aspects=20 > > > > > > > > > > > > > > > > are still > > > > > > > > > > > > > > unclear to you. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ciao > > > > > > > > > > > > > > > > Hannes > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > Jouni > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 > __________________________________________ > > > > > > > > > > > > > > > > _____ DiME mailing list DiME@ietf.org=20 > > > > > > > > > > > > > > > >=20 > https://www1.ietf.org/mailman/listinfo/dim > > > > > > > > > > > > > > > > e > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 > ____________________________________________ > > > > > > > > > > > > > > > ___ DiME mailing list DiME@ietf.org=20 > > > > > > > > > > > > > > >=20 > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 > _______________________________________________ > > > > > > > > > > > > > > DiME mailing list > > > > > > > > > > > > > > DiME@ietf.org > > > > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 > > > > > > > > > > > > >=20 > _______________________________________________ > > > > > > > > > > > > > DiME mailing list > > > > > > > > > > > > > DiME@ietf.org > > > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > >=20 > > > > > > > > > > > >=20 > > > > > > > > > > > > "This email message and any attachments=20 > are confidential=20 > > > > > > > > > > > > information of Starent Networks, Corp.=20 > The information=20 > > > > > > > > > > > > transmitted may not be used to create=20 > or change any=20 > > > > > > > > > > > > contractual obligations of Starent=20 > Networks, Corp. Any=20 > > > > > > > > > > > > review, retransmission, dissemination=20 > or other use of, or=20 > > > > > > > > > > > > taking of any action in reliance upon=20 > this e-mail and its=20 > > > > > > > > > > > > attachments by persons or entities=20 > other than the intended=20 > > > > > > > > > > > > recipient is prohibited. If you are not=20 > the intended=20 > > > > > > > > > > > > recipient, please notify the sender=20 > immediately -- by=20 > > > > > > > > > > > > replying to this message or by sending=20 > an email to=20 > > > > > > > > > > > > postmaster@starentnetworks.com -- and=20 > destroy all copies of=20 > > > > > > > > > > > > this message and any attachments=20 > without reading or=20 > > > > > > > > > > > > disclosing their contents. Thank you." > > > > > > > > > > > >=20 > > > > > > > > > > >=20 > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > DiME mailing list > > > > > > > > > > > DiME@ietf.org > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > >=20 > > > > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > > _______________________________________________ > > > > > > > > > > DiME mailing list > > > > > > > > > > DiME@ietf.org > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > >=20 > > > > > > > > > --=20 > > > > > > > > > julien.bournelle at int-evry.fr > > > > > > > > >=20 > > > > > > >=20 > > > > > > > --=20 > > > > > > > julien.bournelle at int-evry.fr > > > > > > >=20 > > > > >=20 > > > > > --=20 > > > > > julien.bournelle at int-evry.fr > > > > >=20 > > >=20 > > > --=20 > > > julien.bournelle at int-evry.fr > > >=20 >=20 > --=20 > julien.bournelle at int-evry.fr >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Sep 18 15:10:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPOWA-0004Py-7U; Mon, 18 Sep 2006 15:10:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPOW9-0004Ps-7J for dime@ietf.org; Mon, 18 Sep 2006 15:10:57 -0400 Received: from ns1.nitro.ca ([216.209.86.226] helo=mailscanner.nitro.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPOW7-0002Ko-HZ for dime@ietf.org; Mon, 18 Sep 2006 15:10:57 -0400 Received: from bws14.bridgewatersystems.com (bws14.bridgewatersystems.com [216.113.7.14]) by mailscanner.nitro.ca (8.12.11/8.12.11) with ESMTP id k8IJ9sTk027543; Mon, 18 Sep 2006 15:09:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Sep 2006 15:10:01 -0400 Message-ID: In-Reply-To: <20060915095651.GE30516@steelhead> From: "Avi Lior" To: "Yoshihiro Ohba" , "Julien Bournelle" X-Nitro-MailScanner-Information: Please contact the ISP for more information X-Nitro-MailScanner: Found to be clean X-Nitro-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.599, required 4, autolearn=not spam, BAYES_00 -2.60) X-MailScanner-From: avi@bridgewatersystems.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 64592953d6410e1f725ee21266e2f396 Cc: dime@ietf.org Subject: [Dime] RE: Authentication through 2 different "NAS" in the same time ? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I agree with Yoshi, this should not be a problem. One is performing an access authentication and authroization the other is performing a MIP authentication and authorization. =20 > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]=20 > Sent: Friday, September 15, 2006 5:57 AM > To: Julien Bournelle > Cc: Yoshihiro Ohba; Avi Lior; dime@ietf.org > Subject: Re: Authentication through 2 different "NAS" in the=20 > same time ? >=20 > Hi Julien, >=20 > On Fri, Sep 15, 2006 at 11:30:34AM +0200, Julien Bournelle wrote: > > Hi yoshi, > >=20 > > I have one more question concerning your approach. > >=20 > > Considering the following scenario: > >=20 > > MN <------> NAS <---4072 -(1)---> AAAH > > ^ ^ > > | | > > +----------> HA <---4072 (2)------+ > > =20 > > First, the MN is authenticated throught the NAS. The NAS uses=20 > > Diameter EAP and asks the AAAH for AAA for network access. > >=20 > > Then, the MN acquires the HA and uses IKEv2 with it. If we=20 > use your =20 > > approach, the HA uses Diameter EAP with the AVP=20 > Auth-Request-Type set =20 > > to AUTHENTICATE_ONLY. > >=20 > > I was wondering if it won't cause trouble to the AAAH=20 > since it has =20 > > already authenticated the MN through the NAS. >=20 > If the operational policy of AAAH allows MN to perform=20 > multiple back-to-back authentication/authorization attempts=20 > via different authenticators, then there should be no issue. >=20 > BTW, I have two questions. >=20 > - Do the EAP via NAS and the EAP via HA need to hit the same=20 > AAAH server? I guess not. >=20 > - Do the EAP via NAS and the EAP via HA need to use the same Idenity? > I guess not. >=20 > Regards, > Yoshihiro Ohba >=20 >=20 > >=20 > > Any comments on this ? > >=20 > > regards, > >=20 > > Julien > > =20 > >=20 > > On Wed, Sep 13, 2006 at 09:43:06AM -0400, Yoshihiro Ohba wrote: > > > Hi Julien, > > >=20 > > > On Wed, Sep 13, 2006 at 10:52:55AM +0200, Julien Bournelle wrote: > > >=20 > > > (snip) > > >=20 > > > >=20 > > > > > However, if the AAA server somehow needs to know=20 > about it, the=20 > > > > > HA(NAS) can indicate it by including Auth-Request-Type AVP in=20 > > > > > DER with specifying "AUTHENTICATE_ONLY". > > > >=20 > > > > ok. I see. I forgot this possibility. > > > > So to sump up, the HA will use Diameter EAP with the=20 > > > > Auth-Request-Type aVP set to AUTHENTICATE_ONLY and the=20 > App-ID set=20 > > > > to 5. If it receives a success, it will switch to a=20 > > > > Authorization/Accounting MIP6 Application with a new=20 > App-ID. Is that right ? > > > >=20 > > > > I think it can work but we need to investigate a little more=20 > > > > before moving with this. Points that I can see for now are: > > > >=20 > > > > - The session-id must be shared between the Application. > > >=20 > > > Why session-id must be shared? =20 > > >=20 > > > NASREQ usage for authorization purpose in RFC 4072 does=20 > not require=20 > > > it. Instead, User-Name AVP can be shared between the=20 > applications. > > > In case the NAS(HA) is not able to retrieve the username from EAP=20 > > > messages, the AAA server can tell the NAS about the username by=20 > > > carrying User-Name AVP in DEA message, as described in RFC 4072. > > >=20 > > > > - We must be sure that messages will reach the same AAA server. > > >=20 > > > Why Diameter EAP messages and Diameter MIP6 messages need=20 > to hit the=20 > > > same AAA server? > > >=20 > > > Again, NASREQ usage for authorization purpse in RFC 4072 does not=20 > > > require NASREQ and Diameter EAP messages to use the same=20 > AAA server. > > > In general, authentication, authorization and accouting can use=20 > > > different AAA servers, and there should be no exception to MIP6=20 > > > bootstrapping, IMO. > > >=20 > > > > - We may have trouble with RADIUS compatibility > > >=20 > > > This can be handled later. > > >=20 > > > Yoshihiro Ohba > > >=20 > > >=20 > > > > =20 > > > > Anyone has an opinion on this way to solve our issue ?=20 > > > >=20 > > > > Thanks yoshi, > > > >=20 > > > > Julien > > > >=20 > > > > >=20 > > > > > >=20 > > > > > > If we "push" a little what you propose, we could=20 > define an =20 > > > > > > "Authentication based on EAP" Application (only doing=20 > > > > > > Authentication) used by other Application that would only=20 > > > > > > define their messages for Authorization and=20 > Accounting (such=20 > > > > > > as MIP6). That's why I talked to you in a previous=20 > mail about=20 > > > > > > also consider network access as a special service and thus=20 > > > > > > define Authz/Accounting messages for the "network =20 > access" service. > > > > >=20 > > > > > Yes, in the case of network access, you could use NASREQ for=20 > > > > > authorization purpose in additon to Diameter EAP for=20 > > > > > authentication purpose as specified in RFC 4072. > > > > >=20 > > > > > Regards, > > > > > Yoshihiro Ohba > > > > >=20 > > > > >=20 > > > > > >=20 > > > > > > regards, > > > > > >=20 > > > > > > Julien > > > > > >=20 > > > > > > >=20 > > > > > > > Regards, > > > > > > > Yoshihiro Ohba > > > > > > >=20 > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > I also agree with Avi that defining a new application=20 > > > > > > > > > for MIP6 bootstrapping on top of existing=20 > applications=20 > > > > > > > > > (Diameter EAP) without defining a new=20 > application id but=20 > > > > > > > > > with defining new values for existing AVPs or new=20 > > > > > > > > > optional AVPs has some issue, but this option=20 > might not=20 > > > > > > > > > be as bad as the first option since backward=20 > > > > > > > > > compatibility can be easily maintained unlike=20 > the first=20 > > > > > > > > > option. However, there is a forward compatibility=20 > > > > > > > > > problem (i.e., a Diameter message may be=20 > forwarded to a=20 > > > > > > > > > AAA server that does not support the new=20 > application). =20 > > > > > > > > > Besides this problem, it might be worth pursuing this=20 > > > > > > > > > option because it works in an optimized way=20 > (i.e., bootstrapping AVPs are piggybacked in Diameter EAP or=20 > NASREQ message) as long as both NAS and AAA server support the AVPs. > > > > > > > >=20 > > > > > > > > I'm not in favor of having an app-id for the nas-aaah=20 > > > > > > > > part of the mip6 bootstrapping problem. > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > In order to deal with the forward=20 > compatibility problem=20 > > > > > > > > > of the second option, a third option is to=20 > define a new=20 > > > > > > > > > application for MIP6 bootstrapping as a totally new=20 > > > > > > > > > authorization application that carries new mandatory=20 > > > > > > > > > AVPs specific to that application. This=20 > option can be=20 > > > > > > > > > run when execution of the second option=20 > succeeds in authentication but fails in carrying bootstrapping AVPs. > > > > > > > >=20 > > > > > > > > hmm, i guess i have to think more of this=20 > option but this=20 > > > > > > > > would mandate now that all EAP Application=20 > server should=20 > > > > > > > > know that maybe they are not doing this for network=20 > > > > > > > > access and that maybe they are going to receive=20 > a special=20 > > > > > > > > authorization request. And in this case,=20 > wouldn't it mean =20 > > > > > > > > that network access should be treated as a=20 > special service and this would also require a new=20 > authorization application ? > > > > > > > >=20 > > > > > > > > regards, > > > > > > > >=20 > > > > > > > > Julien > > > > > > > > >=20 > > > > > > > > > Regards, > > > > > > > > > Yoshihiro Ohba > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > On Tue, Sep 05, 2006 at 11:21:22PM -0400, Avi=20 > Lior wrote: > > > > > > > > > > Hi Kuntal, > > > > > > > > > >=20 > > > > > > > > > > Neither option 1 or option 2 will work. A new=20 > > > > > > > > > > application id just wont scale in the long=20 > run. What=20 > > > > > > > > > > if another 'capability' were to be added=20 > for instance=20 > > > > > > > > > > prepaid. Since Diameter messages contain only one=20 > > > > > > > > > > Application ID, you would have to create an=20 > > > > > > > > > > Application Id that covered both EAP, Prepaid and=20 > > > > > > > > > > Mobile IP. And what if a third application=20 > were added? =20 > > > > > > > > > > The approach is not scalable as the=20 > applications are=20 > > > > > > > > > > increased > > > > > > > > > > -- you would have to cope with all the different=20 > > > > > > > > > > permutations of Applications. The same=20 > argument goes=20 > > > > > > > > > > for ServiceType and PortType and these are=20 > actually more problematic. > > > > > > > > > >=20 > > > > > > > > > > IMO the only thing we can do is to hint at=20 > the capability of the NAS. =20 > > > > > > > > > >=20 > > > > > > > > > > A proper solution should be concieved for=20 > this problem. > > > > > > > > > > =20 > > > > > > > > > >=20 > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Chowdhury, Kuntal=20 > > > > > > > > > > > [mailto:kchowdhury@starentnetworks.com] > > > > > > > > > > > Sent: Tuesday, September 05, 2006 2:09 PM > > > > > > > > > > > To: Avi Lior; Gerardo Giaretta;=20 > > > > > > > > > > > Hannes.Tschofenig@gmx.net > > > > > > > > > > > Cc: dime@ietf.org > > > > > > > > > > > Subject: RE: [Dime] Diameter MIPv6=20 > Bootstrapping: App-ID vs.=20 > > > > > > > > > > > Service-Type > > > > > > > > > > >=20 > > > > > > > > > > > All, > > > > > > > > > > >=20 > > > > > > > > > > > Here is a scenario that may need to be=20 > covered. In=20 > > > > > > > > > > > some cases, local HA assignment is optimal for=20 > > > > > > > > > > > transport efficiency perspective. Diameter > > > > > > > > > > > MIP4 application allows this. In such a=20 > case the ASP=20 > > > > > > > > > > > =3D=3D MSP and the HA is assigned locally (in=20 > the visited network). > > > > > > > > > > >=20 > > > > > > > > > > > To enable this case, in the integrated=20 > scenario, the=20 > > > > > > > > > > > NAS/VAAA needs to indicate it's=20 > capability to assign=20 > > > > > > > > > > > an HA in the local network to the HAAA.=20 > The HAAA may=20 > > > > > > > > > > > allow or disallow this local HA=20 > assignment based on policy of the MSA. > > > > > > > > > > >=20 > > > > > > > > > > > The NAS/VAAA may need to include a hint=20 > in the AAA=20 > > > > > > > > > > > message to the HAAA at the time of access=20 > > > > > > > > > > > authentication that it is capable of=20 > providing an HA=20 > > > > > > > > > > > to the MN. This capability indication=20 > (hint) can be=20 > > > > > > > > > > > either sent via a new MIP6 specific AVP=20 > or it can be=20 > > > > > > > > > > > conveyed via an existing AVP (I don't=20 > know if one exists). > > > > > > > > > > >=20 > > > > > > > > > > > If we decide to include this (local HA=20 > assignment),=20 > > > > > > > > > > > and we decide to include this mip6=20 > specific hint in=20 > > > > > > > > > > > the NAS-HAAA communication, we may have to choose=20 > > > > > > > > > > > the most appropriate option (1) vs. (2). > > > > > > > > > > >=20 > > > > > > > > > > > Comments? > > > > > > > > > > >=20 > > > > > > > > > > > -Kuntal > > > > > > > > > > >=20 > > > > > > > > > > >=20 > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Avi Lior=20 > [mailto:avi@bridgewatersystems.com] > > > > > > > > > > > > Sent: Tuesday, September 05, 2006 6:07 AM > > > > > > > > > > > > To: Gerardo Giaretta; Hannes.Tschofenig@gmx.net > > > > > > > > > > > > Cc: dime@ietf.org > > > > > > > > > > > > Subject: RE: [Dime] Diameter MIPv6=20 > Bootstrapping: App-ID vs. > > > > > > > > > > > Service-Type > > > > > > > > > > > >=20 > > > > > > > > > > > > I must be missing something. > > > > > > > > > > > >=20 > > > > > > > > > > > > In the integrated scenario, what would=20 > the NAS put in Service-Type? > > > > > > > > > > > >=20 > > > > > > > > > > > > I think in the integrated scenario neither=20 > > > > > > > > > > > > Port-Type or > > > > > > > > > > > Service-Type > > > > > > > > > > > > needs to be touched. > > > > > > > > > > > >=20 > > > > > > > > > > > > As far as I understand the NAS is=20 > either executing=20 > > > > > > > > > > > > EAP > > > > > > > > > > > Application or > > > > > > > > > > > > NAS REQ. It does not know whether the=20 > user will=20 > > > > > > > > > > > > result in having subsequent Mobile IP=20 > service or not. > > > > > > > > > > > >=20 > > > > > > > > > > > > The only thing the AAA server can do is to send=20 > > > > > > > > > > > > the MIPv6 attributes > > > > > > > > > > > as > > > > > > > > > > > > optional (M bit off) and hope that if=20 > the NAS does=20 > > > > > > > > > > > > not > > > > > > > > > > > understand the > > > > > > > > > > > > attributes it would have some logic to=20 > bootstrap a different way. > > > > > > > > > > > >=20 > > > > > > > > > > > > We could improve the situration somewhat. We=20 > > > > > > > > > > > > could have the NAS indicate that it=20 > supports MIPv6=20 > > > > > > > > > > > > bootstrapping by including hints in > > > > > > > > > > > the > > > > > > > > > > > > AR (a capability hint). Where the NAS=20 > includes HA-IP address AVP > > > > > > > > > > > both > > > > > > > > > > > > indicating that it can support=20 > bootstrapping and=20 > > > > > > > > > > > > if the > > > > > > > > > > > HA-IP address > > > > > > > > > > > is > > > > > > > > > > > > not ALL-ZEROS or ALL ONES it provides a=20 > hint that=20 > > > > > > > > > > > > it can support > > > > > > > > > > > dynamic > > > > > > > > > > > > HA assignement. > > > > > > > > > > > >=20 > > > > > > > > > > > > Ofcourse we could introduce the concept of=20 > > > > > > > > > > > > capability hints more formally in=20 > Diameter -- This is missing today. > > > > > > > > > > > >=20 > > > > > > > > > > > >=20 > > > > > > > > > > > >=20 > > > > > > > > > > > >=20 > > > > > > > > > > > >=20 > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > From: Gerardo Giaretta=20 > > > > > > > > > > > > > [mailto:gerardo.giaretta@gmail.com] > > > > > > > > > > > > > Sent: Tuesday, September 05, 2006 3:35 AM > > > > > > > > > > > > > To: Hannes.Tschofenig@gmx.net > > > > > > > > > > > > > Cc: dime@ietf.org > > > > > > > > > > > > > Subject: Re: [Dime] Diameter MIPv6=20 > Bootstrapping: App-ID vs. > > > > > > > > > > > > > Service-Type > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Hannes, > > > > > > > > > > > > > > > > > > > > > > > > > > I agree with Jouni. I prefer (2) for NAS-AAAH=20 > > > > > > > > > > > > > and (1) for > > > > > > > > > > > AAAH-HA.=20 > > > > > > > > > > > > > In my understanding, there are no=20 > mandatory AVPs=20 > > > > > > > > > > > > > for NAS-AAAH and therefore I don't=20 > see a need of=20 > > > > > > > > > > > > > a new application; it's just a MIP-specific=20 > > > > > > > > > > > > > information that is piggybacked in the > > > > > > > > > > > network access > > > > > > > > > > > > > authentication procedure. > > > > > > > > > > > > > > > > > > > > > > > > > > Concerning AAAH-HA, I think it is a=20 > much cleaner=20 > > > > > > > > > > > > > approach > > > > > > > > > > > to define > > > > > > > > > > > > > a new application, since it does not=20 > anything to=20 > > > > > > > > > > > > > do with network authentication. > > > > > > > > > > > > > > > > > > > > > > > > > > --Gerardo > > > > > > > > > > > > > > > > > > > > > > > > > > On 9/5/06, jouni.korhonen@teliasonera.com=20 > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > Hi HAnnes, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > From: Hannes Tschofenig=20 > > > > > > > > > > > > > > > [mailto:Hannes.Tschofenig@gmx.net] > > > > > > > > > > > > > > > Sent: 1. syyskuuta 2006 1:07 > > > > > > > > > > > > > > > To: dime@ietf.org > > > > > > > > > > > > > > > Subject: [Dime] Diameter MIPv6=20 > Bootstrapping: App-ID vs. > > > > > > > > > > > > > > > Service-Type > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > we have had long discussions=20 > about the App-ID vs. > > > > > > > > > > > > > > > Service-Type usage for Diameter MIPv6=20 > > > > > > > > > > > > > > > Bootstrapping. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It is time to see what the group thinks.=20 > > > > > > > > > > > > > > > Please indicate > > > > > > > > > > > > > whether you > > > > > > > > > > > > > > > prefer (1) an App-ID or (2) a=20 > Service-Type=20 > > > > > > > > > > > > > > > solution for > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (a) NAS-to-AAAH communication (as=20 > required=20 > > > > > > > > > > > > > > > by the integrated scenario; as=20 > one part of=20 > > > > > > > > > > > > > > > the solution component) > > > > > > > > > > > > > > > > > > > > > > > > > > > > I would prefer (2) for now.. or as=20 > long as the=20 > > > > > > > > > > > > > > NAS-2-AAAH main function is to=20 > provide access=20 > > > > > > > > > > > > > > authentication, where the backend > > > > > > > > > > > AAA > > > > > > > > > > > > > > may return > > > > > > > > > > > > > > MIP6 > > > > > > > > > > > > > > bootstrapping info (as an=20 > enhancement) based=20 > > > > > > > > > > > > > > e.g. on the user subscription=20 > profile. If we=20 > > > > > > > > > > > > > > go for more stuff on > > > > > > > > > > > NAS-2-AAAH like > > > > > > > > > > > > > > HoA/prefix etc then > > > > > > > > > > > > > > (1) > > > > > > > > > > > > > > might be better. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (b) HA-to-AAAH communication (as=20 > used by the=20 > > > > > > > > > > > > > > > split > > > > > > > > > > > > > scenario and the > > > > > > > > > > > > > > > integrated scenario) > > > > > > > > > > > > > > > > > > > > > > > > > > > > I would prefer (1) here. The use of EAP for=20 > > > > > > > > > > > > > > MIP6 bootstrapping purposes and for=20 > 'normal'=20 > > > > > > > > > > > > > > EAP-based access authentication are=20 > different=20 > > > > > > > > > > > > > > applications imho. (although in IKEv2 vs=20 > > > > > > > > > > > > > > 802.1X case > > > > > > > > > > > e.g. > > > > > > > > > > > > > > NAS-Port-Type could be used to make=20 > this distinction.. e.g. > > > > > > > > > > > > > how 3GPP > > > > > > > > > > > > > > WLAN stuff does it) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It might be useful to state a=20 > reason for your decision. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please also indicate whether some aspects=20 > > > > > > > > > > > > > > > are still > > > > > > > > > > > > > unclear to you. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ciao > > > > > > > > > > > > > > > Hannes > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > Jouni > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 > ____________________________________________ > > > > > > > > > > > > > > > ___ DiME mailing list DiME@ietf.org=20 > > > > > > > > > > > > > > >=20 > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 > _______________________________________________ > > > > > > > > > > > > > > DiME mailing list > > > > > > > > > > > > > > DiME@ietf.org > > > > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 > _______________________________________________ > > > > > > > > > > > > > DiME mailing list > > > > > > > > > > > > > DiME@ietf.org > > > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > >=20 > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > DiME mailing list > > > > > > > > > > > > DiME@ietf.org > > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > >=20 > > > > > > > > > > >=20 > > > > > > > > > > > "This email message and any attachments=20 > are confidential=20 > > > > > > > > > > > information of Starent Networks, Corp.=20 > The information=20 > > > > > > > > > > > transmitted may not be used to create or=20 > change any=20 > > > > > > > > > > > contractual obligations of Starent=20 > Networks, Corp. Any=20 > > > > > > > > > > > review, retransmission, dissemination or=20 > other use of, or=20 > > > > > > > > > > > taking of any action in reliance upon=20 > this e-mail and its=20 > > > > > > > > > > > attachments by persons or entities other=20 > than the intended=20 > > > > > > > > > > > recipient is prohibited. If you are not=20 > the intended=20 > > > > > > > > > > > recipient, please notify the sender=20 > immediately -- by=20 > > > > > > > > > > > replying to this message or by sending an=20 > email to=20 > > > > > > > > > > > postmaster@starentnetworks.com -- and=20 > destroy all copies of=20 > > > > > > > > > > > this message and any attachments without=20 > reading or=20 > > > > > > > > > > > disclosing their contents. Thank you." > > > > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > > _______________________________________________ > > > > > > > > > > DiME mailing list > > > > > > > > > > DiME@ietf.org > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > _______________________________________________ > > > > > > > > > DiME mailing list > > > > > > > > > DiME@ietf.org > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > >=20 > > > > > > > > --=20 > > > > > > > > julien.bournelle at int-evry.fr > > > > > > > >=20 > > > > > >=20 > > > > > > --=20 > > > > > > julien.bournelle at int-evry.fr > > > > > >=20 > > > >=20 > > > > --=20 > > > > julien.bournelle at int-evry.fr > > > >=20 > >=20 > > --=20 > > julien.bournelle at int-evry.fr > >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 19 05:17:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPbio-00022v-8t; Tue, 19 Sep 2006 05:16:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPbim-00022p-Jy for dime@ietf.org; Tue, 19 Sep 2006 05:16:52 -0400 Received: from [203.199.83.32] (helo=rediffmail.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GPbik-00036V-Lg for dime@ietf.org; Tue, 19 Sep 2006 05:16:52 -0400 Received: (qmail 9842 invoked by uid 510); 19 Sep 2006 09:13:57 -0000 Date: 19 Sep 2006 09:13:57 -0000 Message-ID: <20060919091357.9841.qmail@webmail32.rediffmail.com> Received: from unknown (202.131.155.13) by rediffmail.com via HTTP; 19 sep 2006 09:13:56 -0000 MIME-Version: 1.0 From: "Valesh Chandu" To: dime@ietf.org X-Spam-Score: 1.8 (+) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [Dime] receving connections from 3868 with multiple instances. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Valesh Chandu List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1002249810==" Errors-To: dime-bounces@ietf.org This is a multipart mime message --===============1002249810== Content-type: multipart/alternative; boundary="Next_1158657236---0-203.199.83.32-9818" This is a multipart mime message --Next_1158657236---0-203.199.83.32-9818 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi all,=0A=0AI have a doubt regarding receiving connection requests/listeni= ng on port 3868 in case of multiple instances on a single host with one int= erface.=0A=0ASnippet from sec 2.1 of RFC 3588:=0AA Diameter node MAY initia= te connections from a source port other than the one that it declares it = accepts incoming connections on, and MUST be prepared to receive connection= s on port 3868.A given Diameter instance of the peer state machine MUST NOT= use more than one transport connection to communicate with a given peer, u= nless multiple instances exist on the peer in which case a separate connect= ion per process is allowed.=0ADiameter Node is defined as :=0AA Diameter no= de is a host process that implements the Diameter protocol, and acts ei= ther as a Client, Agent or Server.=0A=0AMy understanding of the above secti= on is that multiple instances of the diameter stack is possible on the same= host machine.=0A=0ASo, if we have multiple instances on a single host then= how it is possible to listen on the same port 3868 from all the instances?= =0A=0A=0APlease any one clarify my doubt? =0A=0ABest Regards,=0AChandu=0A = =A0=0A --Next_1158657236---0-203.199.83.32-9818 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

    =0AHi all,
    =0A
    =0AI have a doubt regarding receiving connection re= quests/listening on port 3868 in case of multiple instances on a single hos= t with one interface.
    =0A
    =0ASnippet from sec 2.1 of RFC 3588:
    =0A= A Diameter node MAY initiate connections from a source port other  th= an the one that it declares it accepts incoming connections on, and MUST be= prepared to receive connections on port 3868.A given Diameter instance of = the peer state machine MUST NOT use more than one transport connection to c= ommunicate with a given peer, unless multiple instances exist on the peer i= n which case a separate connection per process is allowed.
    =0ADiameter N= ode is defined as :
    =0AA Diameter node is a host process that implements= the Diameter    protocol, and acts either as a Client, Agent or= Server.
    =0A
    =0AMy understanding of the above section is that multipl= e instances of the diameter stack is possible on the same host machine.
    = =0A
    =0ASo, if we have multiple instances on a single host then how it is= possible to listen on the same port 3868 from all the instances?
    =0A=0A
    =0APlease any one clarify my doubt?
    =0A
    =0ABest Regards,
    = =0AChandu
    =0A 
    =0A=0A

    =0A

    =0A=0A --Next_1158657236---0-203.199.83.32-9818-- --===============1002249810== 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://www1.ietf.org/mailman/listinfo/dime --===============1002249810==-- From dime-bounces@ietf.org Tue Sep 19 06:47:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPd8E-0005R5-AV; Tue, 19 Sep 2006 06:47:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPd8C-0005Qu-Jc for dime@ietf.org; Tue, 19 Sep 2006 06:47:12 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPd89-000500-Fo for dime@ietf.org; Tue, 19 Sep 2006 06:47:12 -0400 Received: by ug-out-1314.google.com with SMTP id 72so411202ugd for ; Tue, 19 Sep 2006 03:47:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=JrvnRnL+jBPJxGEX5Euh0E8JUTSZBBwjMveGqK76M1qSjuF1Gp6P3CHuwnYrC/fwSWELHj/B9DK1WeoY4vKfqkHBFxfl2A18mTmh3FHUILKl8UGUTQn8WH21PJwnujBExYoPYef/BsLOUBQq091iXP2fELBqQv6iPS4F2WmH5/I= Received: by 10.67.103.7 with SMTP id f7mr7860414ugm; Tue, 19 Sep 2006 03:47:08 -0700 (PDT) Received: by 10.67.95.7 with HTTP; Tue, 19 Sep 2006 03:47:07 -0700 (PDT) Message-ID: <4f9fd9700609190347y69205418r936b1f2c49c725d6@mail.gmail.com> Date: Tue, 19 Sep 2006 16:17:07 +0530 From: "Rashmi Rath" To: dime@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: bfef20db74c24e87b6dbcd42ea7ba67c Subject: [Dime] DiME Digest, Vol 9, Issue 30 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 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="===============1230841580==" Errors-To: dime-bounces@ietf.org --===============1230841580== Content-Type: multipart/alternative; boundary="----=_Part_105061_11433958.1158662827731" ------=_Part_105061_11433958.1158662827731 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All, I have a question. In Disconnect Peer Request, If i put disconnect cause other than BUSY, REBOOTING and DO_NOT_WANT_TO_TALK_TO_YOU, should it disconnect the peer connection. Thanks & Regds Rashmi Rath Software Engineer IntelliNet Technologies On 9/18/06, dime-request@ietf.org wrote: > > Send DiME mailing list submissions to > dime@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/dime > or, via email, send a message with subject or body 'help' to > dime-request@ietf.org > > You can reach the person managing the list at > dime-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of DiME digest..." > > > Today's Topics: > > 1. Re: Error Code issues for bis (Victor Fajardo) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 18 Sep 2006 11:34:18 -0400 > From: Victor Fajardo > Subject: Re: [Dime] Error Code issues for bis > To: Yoshihiro Ohba > Cc: dime@ietf.org > Message-ID: <450EBC7A.1000701@tari.toshiba.com> > Content-Type: text/plain; charset=ISO-2022-JP > > I've updated issue 14 to reflect the current opinion of which I also > agree. Pls review the text if it is appropriate or if other folks has > other opinions. > > regards, > victor > > > > I support Tolga's proposal on using E-bit and grammar described in 7.2 > > for permanent errors in addition to protocol errors. > > > > Yoshihiro Ohba > > > > On Mon, Sep 18, 2006 at 05:33:31AM +0300, john.loughney@nokia.com wrote: > > > >> Tolga, > >> > >> I think that seems reasonable - does anyone else have comments > >> on this - supporting or otherwise? It would be good to wrap > >> this issue up. > >> > >> John > >> > >> > >>> -----Original Message----- > >>> From: ext Tolga Asveren [mailto:asveren@ulticom.com] > >>> Sent: 15 September, 2006 15:50 > >>> To: Loughney John (Nokia-NRC/Helsinki); dime@ietf.org > >>> Subject: RE: [Dime] Error Code issues for bis > >>> > >>> John, > >>> > >>> My only goal is being able to use the grammar described in 7.2 > >>> for permanent answers as well. For certain situations it is > >>> impossible to continue decoding a message, e.g. invalid AVP > >>> length for an AVP which is of type OctetString. In such a > >>> case, it may not be possible to generate an answer message > >>> based on the command's answer grammar, nor does it seem > >>> necessary to me. > >>> > >>> What I suggest is allowing E-bit to be set for permanent > >>> failures as well, so that grammar in 7.2 can be used. > >>> > >>> It is not important that all implementations follow that path, > >>> only the ones which consider it necessary/usefull for certain > >>> cases can use it. > >>> > >>> On receiver end, this shouldn't be a problem because if the > >>> E-bit is set, receiver will decode the message based on 7.2 > >>> grammar, otherwise command answer grammar will be used. this > >>> rule is already there in RFC3588. > >>> > >>> After thinking a bit more, the only possible backward > >>> compatibility issue I see is, if some implementation checks > >>> whether E-bit is set for an answer with Result-Code other than > >>> Protocol Error. Considering that for some Permanent Failures > >>> 7.2 grammar is really necessary, I believe that shouldn't be a > >>> big issue. > >>> > >>> Thanks, > >>> Tolga > >>> > >>> > >>>> -----Original Message----- > >>>> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > >>>> Sent: Thursday, September 14, 2006 11:34 PM > >>>> To: asveren@ulticom.com; dime@ietf.org > >>>> Subject: RE: [Dime] Error Code issues for bis > >>>> > >>>> > >>>> Tolga, > >>>> > >>>> If it is optional, that means you can't count that any > >>>> > >>> implementations > >>> > >>>> will support it. > >>>> > >>>> However, are you suggesting the E-bit could be used as a hint for > >>>> permantant failures? > >>>> > >>>> John > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: ext Tolga Asveren [mailto:asveren@ulticom.com] > >>>>> Sent: 14 September, 2006 21:14 > >>>>> To: dime@ietf.org > >>>>> Subject: RE: [Dime] Error Code issues for bis > >>>>> > >>>>> Hi Victor, > >>>>> > >>>>> I had a look to Issue14. I already thought that use of E-bit is > >>>>> exclusively for protocol errors based on "Note that these and only > >>>>> these erors MUST only be used in answer messages whose 'E' bit is > >>>>> set." in 7.1.3. The proposed text further supports this idea. > >>>>> > >>>>> I see a value of using E-bit for permanent failures as I tried to > >>>>> explain before. I think your concern is that people may > >>>>> > >>> choose not to > >>> > >>>>> use error answer-message grammar defined in 7.2 for certain > >>>>> > >>> permanent > >>> > >>>>> failures. To address both concerns, I suggest we allow use of E-bit > >>>>> for permanent failures but leave it as an implementation choice to > >>>>> use it or not. This again would be backward compatible AFAICS. > >>>>> > >>>>> Thanks, > >>>>> Tolga > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > >>>>>> Sent: Thursday, September 14, 2006 10:17 AM > >>>>>> To: Tolga Asveren > >>>>>> Cc: dime@ietf.org > >>>>>> Subject: Re: [Dime] Error Code issues for bis > >>>>>> > >>>>>> > >>>>>> Hi Tolga, > >>>>>> > >>>>>> Comments inline: > >>>>>> > >>>>>>>> This maybe an easy way of performing error handling with just > >>>>>>>> sending the error grammar but it maybe to harsh (??). A node > >>>>>>>> receiving a result code set to some non-protocol failure > >>>>>>>> > >>>>> value may > >>>>> > >>>>>>>> find it more useful to receive the application specific answer > >>>>>>>> message rather than just the error message in 7.2 since the > >>>>>>>> error may not be grave and the both end-point application can > >>>>>>>> > >>>>> attempt to recover and continue on. > >>>>> > >>>>>> An example > >>>>>> > >>>>>>>> would be when the result code is set to MISSING_AVP or > >>>>>>>> > >>>>>> INVALID_AVP_VALUE > >>>>>> > >>>>>>>> and the answer message carries a Failed-AVP. Depending on the > >>>>>>>> application, the sender of the error may choose to continue > >>>>>>>> processing the remainder of the request if the offending > >>>>>>>> > >>>>> AVP is not > >>>>> > >>>>>>>> crucial. The receiver of the error would view the error as a > >>>>>>>> hint maybe able to compensate/recover and continue on also. > >>>>>>>> > >>>>>>>> > >>>>>>> [TOLGA]This is an interesting point but if such an answer is > >>>>>>> > >>>>>> generated, how > >>>>>> > >>>>>>> could the peer know the real result of the request > >>>>>>> > >>>>> processing? Let's > >>>>> > >>>>>>> say Result-Code contains MISSING_AVP, how could the request > >>>>>>> > >>>>>> originator determine > >>>>>> > >>>>>>> whether the request processing is done successfully? > >>>>>>> > >>>>>> I was thinking through other avp's in the application > >>>>>> > >>>>> specific answer > >>>>> > >>>>>> grammar ... though that maybe stretching the success/failure > >>>>>> significance of the result-code avp against other avps in > >>>>>> > >>>>> the message > >>>>> > >>>>>> so may not as advisable. > >>>>>> > >>>>>> > >>>>>>>> I guess this would depend if the implementation is doing full > >>>>>>>> > >>>>>> or partial > >>>>>> > >>>>>>>> parsing in the base protocol layer. > >>>>>>>> > >>>>>>>> > >>>>>>> [TOLGA]I think I was not clear about this one. The message > >>>>>>> > >>>>> is parsed > >>>>> > >>>>>>> (or parsed as much as possible depending the type of the error). > >>>>>>> > >>>>>> Now an answer > >>>>>> > >>>>>>> message needs to be generated. If the grammar of the > >>>>>>> > >>>>> answer for that > >>>>> > >>>>>>> specific command code is used, all mandatory AVPs which are > >>>>>>> > >>>>>> specified in the > >>>>>> > >>>>>>> grammar need to be present. Those AVPs possibly could be filled > >>>>>>> without application logic involvement, but I would think this > >>>>>>> would > >>>>>>> > >>>>>> require to put > >>>>>> > >>>>>>> some dummy values there. In such a case, what is the point of > >>>>>>> inserting them? > >>>>>>> > >>>>>>> > >>>>>> I was thinking in the case where the base protocol part of the > >>>>>> implementation does only partial parsing of message header > >>>>>> > >>>>> and avps it > >>>>> > >>>>>> requires and leaves full parsing of the remaining > >>>>>> > >>>>> application specific > >>>>> > >>>>>> avps to the applications themselves. The scenario you mentioned > >>>>>> fits well when the failure occurs during the partial parsing. > >>>>>> During full parsing, application logic can be introduced. > >>>>>> > >>>>>> best regards, > >>>>>> victor > >>>>>> > >>>>> _______________________________________________ > >>>>> DiME mailing list > >>>>> DiME@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/dime > >>>>> > >>>>> > >>> > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www1.ietf.org/mailman/listinfo/dime > >> > >> > >> > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > ______________________________________________________________________ > > This email has been scanned by the MessageLabs Email Security System. > > For more information please visit http://www.messagelabs.com/email > > ______________________________________________________________________ > > > > > > > > > > > ------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > End of DiME Digest, Vol 9, Issue 29 > *********************************** > -- Regards Rashmi Ranjan Rath ------=_Part_105061_11433958.1158662827731 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
    Hi All,
     
    I have a question.
    In Disconnect Peer Request, If i put disconnect cause other than BUSY, REBOOTING and DO_NOT_WANT_TO_TALK_TO_YOU, should it disconnect the peer connection.
     
     
     
    Thanks & Regds
     
    Rashmi Rath
    Software Engineer
    IntelliNet Technologies

     
    On 9/18/06, dime-request@ietf.org <dime-request@ietf.org> wrote:
    Send DiME mailing list submissions to
           dime@ietf.org

    To subscribe or unsubscribe via the World Wide Web, visit
           https://www1.ietf.org/mailman/listinfo/dime
    or, via email, send a message with subject or body 'help' to
           dime-request@ietf.org

    You can reach the person managing the list at
           dime-owner@ietf.org

    When replying, please edit your Subject line so it is more specific
    than "Re: Contents of DiME digest..."


    Today's Topics:

      1. Re: Error Code issues for bis (Victor Fajardo)


    ----------------------------------------------------------------------

    Message: 1
    Date: Mon, 18 Sep 2006 11:34:18 -0400
    From: Victor Fajardo <vfajardo@tari.toshiba.com>
    Subject: Re: [Dime] Error Code issues for bis
    To: Yoshihiro Ohba < yohba@tari.toshiba.com>
    Cc: dime@ietf.org
    Message-ID: <450EBC7A.1000701@tari.toshiba.com >
    Content-Type: text/plain; charset=ISO-2022-JP

    I've updated issue 14 to reflect the current opinion of which I also
    agree. Pls review the text if it is appropriate or if other folks has
    other opinions.

    regards,
    victor


    > I support Tolga's proposal on using E-bit and grammar described in 7.2
    > for permanent errors in addition to protocol errors.
    >
    > Yoshihiro Ohba
    >
    > On Mon, Sep 18, 2006 at 05:33:31AM +0300, john.loughney@nokia.com wrote:
    >
    >> Tolga,
    >>
    >> I think that seems reasonable - does anyone else have comments
    >> on this - supporting or otherwise?  It would be good to wrap
    >> this issue up.
    >>
    >> John
    >>
    >>
    >>> -----Original Message-----
    >>> From: ext Tolga Asveren [mailto:asveren@ulticom.com ]
    >>> Sent: 15 September, 2006 15:50
    >>> To: Loughney John (Nokia-NRC/Helsinki); dime@ietf.org
    >>> Subject: RE: [Dime] Error Code issues for bis
    >>>
    >>> John,
    >>>
    >>> My only goal is being able to use the grammar described in 7.2
    >>> for permanent answers as well. For certain situations it is
    >>> impossible to continue decoding a message, e.g. invalid AVP
    >>> length for an AVP which is of type OctetString. In such a
    >>> case, it may not be possible to generate an answer message
    >>> based on the command's answer grammar, nor does it seem
    >>> necessary to me.
    >>>
    >>> What I suggest is allowing E-bit to be set for permanent
    >>> failures as well, so that grammar in 7.2 can be used.
    >>>
    >>> It is not important that all implementations follow that path,
    >>> only the ones which consider it necessary/usefull for certain
    >>> cases can use it.
    >>>
    >>> On receiver end, this shouldn't be a problem because if the
    >>> E-bit is set, receiver will decode the message based on 7.2
    >>> grammar, otherwise command answer grammar will be used. this
    >>> rule is already there in RFC3588.
    >>>
    >>> After thinking a bit more, the only possible backward
    >>> compatibility issue I see is, if some implementation checks
    >>> whether E-bit is set for an answer with Result-Code other than
    >>> Protocol Error. Considering that for some Permanent Failures
    >>> 7.2 grammar is really necessary, I believe that shouldn't be a
    >>> big issue.
    >>>
    >>>     Thanks,
    >>>     Tolga
    >>>
    >>>
    >>>> -----Original Message-----
    >>>> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
    >>>> Sent: Thursday, September 14, 2006 11:34 PM
    >>>> To: asveren@ulticom.com; dime@ietf.org
    >>>> Subject: RE: [Dime] Error Code issues for bis
    >>>>
    >>>>
    >>>> Tolga,
    >>>>
    >>>> If it is optional, that means you can't count that any
    >>>>
    >>> implementations
    >>>
    >>>> will support it.
    >>>>
    >>>> However, are you suggesting the E-bit could be used as a hint for
    >>>> permantant failures?
    >>>>
    >>>> John
    >>>>
    >>>>
    >>>>> -----Original Message-----
    >>>>> From: ext Tolga Asveren [mailto: asveren@ulticom.com]
    >>>>> Sent: 14 September, 2006 21:14
    >>>>> To: dime@ietf.org
    >>>>> Subject: RE: [Dime] Error Code issues for bis
    >>>>>
    >>>>> Hi Victor,
    >>>>>
    >>>>> I had a look to Issue14. I already thought that use of E-bit is
    >>>>> exclusively for protocol errors based on "Note that these and only
    >>>>> these erors MUST only be used in answer messages whose 'E' bit is
    >>>>> set." in 7.1.3. The proposed text further supports this idea.
    >>>>>
    >>>>> I see a value of using E-bit for permanent failures as I tried to
    >>>>> explain before. I think your concern is that people may
    >>>>>
    >>> choose not to
    >>>
    >>>>> use error answer-message grammar defined in 7.2 for certain
    >>>>>
    >>> permanent
    >>>
    >>>>> failures. To address both concerns, I suggest we allow use of E-bit
    >>>>> for permanent failures but leave it as an implementation choice to
    >>>>> use it or not. This again would be backward compatible AFAICS.
    >>>>>
    >>>>>    Thanks,
    >>>>>    Tolga
    >>>>>
    >>>>>
    >>>>>
    >>>>>
    >>>>>> -----Original Message-----
    >>>>>> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com ]
    >>>>>> Sent: Thursday, September 14, 2006 10:17 AM
    >>>>>> To: Tolga Asveren
    >>>>>> Cc: dime@ietf.org
    >>>>>> Subject: Re: [Dime] Error Code issues for bis
    >>>>>>
    >>>>>>
    >>>>>> Hi Tolga,
    >>>>>>
    >>>>>> Comments inline:
    >>>>>>
    >>>>>>>> This maybe an easy way of performing error handling with just
    >>>>>>>> sending the error grammar but it maybe to harsh (??). A node
    >>>>>>>> receiving a result code set to some non-protocol failure
    >>>>>>>>
    >>>>> value may
    >>>>>
    >>>>>>>> find it more useful to receive the application specific answer
    >>>>>>>> message rather than just the error message in 7.2 since the
    >>>>>>>> error may not be grave and the both end-point application can
    >>>>>>>>
    >>>>> attempt to recover and continue on.
    >>>>>
    >>>>>> An example
    >>>>>>
    >>>>>>>> would be when the result code is set to MISSING_AVP or
    >>>>>>>>
    >>>>>> INVALID_AVP_VALUE
    >>>>>>
    >>>>>>>> and the answer message carries a Failed-AVP. Depending on the
    >>>>>>>> application, the sender of the error may choose to continue
    >>>>>>>> processing the remainder of the request if the offending
    >>>>>>>>
    >>>>> AVP is not
    >>>>>
    >>>>>>>> crucial. The receiver of the error would view the error as a
    >>>>>>>> hint maybe able to compensate/recover and continue on also.
    >>>>>>>>
    >>>>>>>>
    >>>>>>> [TOLGA]This is an interesting point but if such an answer is
    >>>>>>>
    >>>>>> generated, how
    >>>>>>
    >>>>>>> could the peer know the real result of the request
    >>>>>>>
    >>>>> processing? Let's
    >>>>>
    >>>>>>> say Result-Code contains MISSING_AVP, how could the request
    >>>>>>>
    >>>>>> originator determine
    >>>>>>
    >>>>>>> whether the request processing is done successfully?
    >>>>>>>
    >>>>>> I was thinking through other avp's in the application
    >>>>>>
    >>>>> specific answer
    >>>>>
    >>>>>> grammar ... though that maybe stretching the success/failure
    >>>>>> significance of the result-code avp against other avps in
    >>>>>>
    >>>>> the message
    >>>>>
    >>>>>> so may not as advisable.
    >>>>>>
    >>>>>>
    >>>>>>>> I guess this would depend if the implementation is doing full
    >>>>>>>>
    >>>>>> or partial
    >>>>>>
    >>>>>>>> parsing in the base protocol layer.
    >>>>>>>>
    >>>>>>>>
    >>>>>>> [TOLGA]I think I was not clear about this one. The message
    >>>>>>>
    >>>>> is parsed
    >>>>>
    >>>>>>> (or parsed as much as possible depending the type of the error).
    >>>>>>>
    >>>>>> Now an answer
    >>>>>>
    >>>>>>> message needs to be generated. If the grammar of the
    >>>>>>>
    >>>>> answer for that
    >>>>>
    >>>>>>> specific command code is used, all mandatory AVPs which are
    >>>>>>>
    >>>>>> specified in the
    >>>>>>
    >>>>>>> grammar need to be present. Those AVPs possibly could be filled
    >>>>>>> without application logic involvement, but I would think this
    >>>>>>> would
    >>>>>>>
    >>>>>> require to put
    >>>>>>
    >>>>>>> some dummy values there. In such a case, what is the point of
    >>>>>>> inserting them?
    >>>>>>>
    >>>>>>>
    >>>>>> I was thinking in the case where the base protocol part of the
    >>>>>> implementation does only partial parsing of message header
    >>>>>>
    >>>>> and avps it
    >>>>>
    >>>>>> requires and leaves full parsing of the remaining
    >>>>>>
    >>>>> application specific
    >>>>>
    >>>>>> avps to the applications themselves. The scenario you mentioned
    >>>>>> fits well when the failure occurs during the partial parsing.
    >>>>>> During full parsing, application logic can be introduced.
    >>>>>>
    >>>>>> best regards,
    >>>>>> victor
    >>>>>>
    >>>>> _______________________________________________
    >>>>> DiME mailing list
    >>>>> DiME@ietf.org
    >>>>> https://www1.ietf.org/mailman/listinfo/dime
    >>>>>
    >>>>>
    >>>
    >> _______________________________________________
    >> DiME mailing list
    >> DiME@ietf.org
    >> https://www1.ietf.org/mailman/listinfo/dime
    >>
    >>
    >>
    >
    > _______________________________________________
    > DiME mailing list
    > DiME@ietf.org
    > https://www1.ietf.org/mailman/listinfo/dime
    >
    > ______________________________________________________________________
    > This email has been scanned by the MessageLabs Email Security System.
    > For more information please visit http://www.messagelabs.com/email
    > ______________________________________________________________________
    >
    >
    >




    ------------------------------

    _______________________________________________
    DiME mailing list
    DiME@ietf.org
    https://www1.ietf.org/mailman/listinfo/dime


    End of DiME Digest, Vol 9, Issue 29
    ***********************************



    --
    Regards

    Rashmi Ranjan Rath ------=_Part_105061_11433958.1158662827731-- --===============1230841580== 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://www1.ietf.org/mailman/listinfo/dime --===============1230841580==-- From dime-bounces@ietf.org Tue Sep 19 08:56:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPf9g-0002Ud-HH; Tue, 19 Sep 2006 08:56:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPf81-00010W-SJ for dime@ietf.org; Tue, 19 Sep 2006 08:55:09 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPf35-0000YI-FM for dime@ietf.org; Tue, 19 Sep 2006 08:50:04 -0400 Received: by ug-out-1314.google.com with SMTP id 72so419155ugd for ; Tue, 19 Sep 2006 05:50:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=Sgg0hszUg7hweM+H+uVkMBdfgLsgjPgrd73BCHXNawwRpsYBLnUMCWuAxREhwOTfePrd0pR4PhwiUBkWFYRzp0a61eLbmOK72kTR3IsdUV+k7gW5JCbFuVUo5FfDlBbLvoRunRc5RHQI7Ub5C2a0h+kcGUV6+EzI3lBLUv2IcI8= Received: by 10.66.224.3 with SMTP id w3mr7895892ugg; Tue, 19 Sep 2006 05:50:02 -0700 (PDT) Received: by 10.67.95.7 with HTTP; Tue, 19 Sep 2006 05:50:02 -0700 (PDT) Message-ID: <4f9fd9700609190550q33f1c24cga480cd500eb3de04@mail.gmail.com> Date: Tue, 19 Sep 2006 08:50:02 -0400 From: "Rashmi Rath" To: dime@ietf.org In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.1 (/) X-Scan-Signature: 398dc098b38497efe55f044562a219e7 Subject: [Dime] Re: DiME Digest, Vol 9, Issue 31 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 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="===============0289880014==" Errors-To: dime-bounces@ietf.org --===============0289880014== Content-Type: multipart/alternative; boundary="----=_Part_106946_11223308.1158670202074" ------=_Part_106946_11223308.1158670202074 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Chandu, Your understanding is absolutely right. A diameter peer can accept message from more one peer. ie multiple instance of diameter is possible in a single host. Thanks & Regds Rashmi Rath Software Engineer IntelliNet Technologies On 9/19/06, dime-request@ietf.org wrote: > > Send DiME mailing list submissions to > dime@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/dime > or, via email, send a message with subject or body 'help' to > dime-request@ietf.org > > You can reach the person managing the list at > dime-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of DiME digest..." > > > Today's Topics: > > 1. receving connections from 3868 with multiple instances. > (Valesh Chandu) > 2. DiME Digest, Vol 9, Issue 30 (Rashmi Rath) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: 19 Sep 2006 09:13:57 -0000 > From: "Valesh Chandu" > Subject: [Dime] receving connections from 3868 with multiple > instances. > To: dime@ietf.org > Message-ID: <20060919091357.9841.qmail@webmail32.rediffmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Hi all, > > I have a doubt regarding receiving connection requests/listening on port > 3868 in case of multiple instances on a single host with one interface. > > Snippet from sec 2.1 of RFC 3588: > A Diameter node MAY initiate connections from a source port other than > the one that it declares it accepts incoming connections on, and MUST be > prepared to receive connections on port 3868.A given Diameter instance of > the peer state machine MUST NOT use more than one transport connection to > communicate with a given peer, unless multiple instances exist on the peer > in which case a separate connection per process is allowed. > Diameter Node is defined as : > A Diameter node is a host process that implements the Diameter > protocol, and acts either as a Client, Agent or Server. > > My understanding of the above section is that multiple instances of the > diameter stack is possible on the same host machine. > > So, if we have multiple instances on a single host then how it is possible > to listen on the same port 3868 from all the instances? > > > Please any one clarify my doubt? > > Best Regards, > Chandu > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://www1.ietf.org/pipermail/dime/attachments/20060919/2fa54a99/attachment-0001.html > > ------------------------------ > > Message: 2 > Date: Tue, 19 Sep 2006 16:17:07 +0530 > From: "Rashmi Rath" > Subject: [Dime] DiME Digest, Vol 9, Issue 30 > To: dime@ietf.org > Message-ID: > <4f9fd9700609190347y69205418r936b1f2c49c725d6@mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Hi All, > > I have a question. > In Disconnect Peer Request, If i put disconnect cause other than BUSY, > REBOOTING and DO_NOT_WANT_TO_TALK_TO_YOU, should it disconnect the peer > connection. > > > > Thanks & Regds > > Rashmi Rath > Software Engineer > IntelliNet Technologies > > > On 9/18/06, dime-request@ietf.org wrote: > > > > Send DiME mailing list submissions to > > dime@ietf.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://www1.ietf.org/mailman/listinfo/dime > > or, via email, send a message with subject or body 'help' to > > dime-request@ietf.org > > > > You can reach the person managing the list at > > dime-owner@ietf.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of DiME digest..." > > > > > > Today's Topics: > > > > 1. Re: Error Code issues for bis (Victor Fajardo) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Mon, 18 Sep 2006 11:34:18 -0400 > > From: Victor Fajardo > > Subject: Re: [Dime] Error Code issues for bis > > To: Yoshihiro Ohba > > Cc: dime@ietf.org > > Message-ID: <450EBC7A.1000701@tari.toshiba.com> > > Content-Type: text/plain; charset=ISO-2022-JP > > > > I've updated issue 14 to reflect the current opinion of which I also > > agree. Pls review the text if it is appropriate or if other folks has > > other opinions. > > > > regards, > > victor > > > > > > > I support Tolga's proposal on using E-bit and grammar described in 7.2 > > > for permanent errors in addition to protocol errors. > > > > > > Yoshihiro Ohba > > > > > > On Mon, Sep 18, 2006 at 05:33:31AM +0300, john.loughney@nokia.comwrote: > > > > > >> Tolga, > > >> > > >> I think that seems reasonable - does anyone else have comments > > >> on this - supporting or otherwise? It would be good to wrap > > >> this issue up. > > >> > > >> John > > >> > > >> > > >>> -----Original Message----- > > >>> From: ext Tolga Asveren [mailto:asveren@ulticom.com] > > >>> Sent: 15 September, 2006 15:50 > > >>> To: Loughney John (Nokia-NRC/Helsinki); dime@ietf.org > > >>> Subject: RE: [Dime] Error Code issues for bis > > >>> > > >>> John, > > >>> > > >>> My only goal is being able to use the grammar described in 7.2 > > >>> for permanent answers as well. For certain situations it is > > >>> impossible to continue decoding a message, e.g. invalid AVP > > >>> length for an AVP which is of type OctetString. In such a > > >>> case, it may not be possible to generate an answer message > > >>> based on the command's answer grammar, nor does it seem > > >>> necessary to me. > > >>> > > >>> What I suggest is allowing E-bit to be set for permanent > > >>> failures as well, so that grammar in 7.2 can be used. > > >>> > > >>> It is not important that all implementations follow that path, > > >>> only the ones which consider it necessary/usefull for certain > > >>> cases can use it. > > >>> > > >>> On receiver end, this shouldn't be a problem because if the > > >>> E-bit is set, receiver will decode the message based on 7.2 > > >>> grammar, otherwise command answer grammar will be used. this > > >>> rule is already there in RFC3588. > > >>> > > >>> After thinking a bit more, the only possible backward > > >>> compatibility issue I see is, if some implementation checks > > >>> whether E-bit is set for an answer with Result-Code other than > > >>> Protocol Error. Considering that for some Permanent Failures > > >>> 7.2 grammar is really necessary, I believe that shouldn't be a > > >>> big issue. > > >>> > > >>> Thanks, > > >>> Tolga > > >>> > > >>> > > >>>> -----Original Message----- > > >>>> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > >>>> Sent: Thursday, September 14, 2006 11:34 PM > > >>>> To: asveren@ulticom.com; dime@ietf.org > > >>>> Subject: RE: [Dime] Error Code issues for bis > > >>>> > > >>>> > > >>>> Tolga, > > >>>> > > >>>> If it is optional, that means you can't count that any > > >>>> > > >>> implementations > > >>> > > >>>> will support it. > > >>>> > > >>>> However, are you suggesting the E-bit could be used as a hint for > > >>>> permantant failures? > > >>>> > > >>>> John > > >>>> > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: ext Tolga Asveren [mailto:asveren@ulticom.com] > > >>>>> Sent: 14 September, 2006 21:14 > > >>>>> To: dime@ietf.org > > >>>>> Subject: RE: [Dime] Error Code issues for bis > > >>>>> > > >>>>> Hi Victor, > > >>>>> > > >>>>> I had a look to Issue14. I already thought that use of E-bit is > > >>>>> exclusively for protocol errors based on "Note that these and only > > >>>>> these erors MUST only be used in answer messages whose 'E' bit is > > >>>>> set." in 7.1.3. The proposed text further supports this idea. > > >>>>> > > >>>>> I see a value of using E-bit for permanent failures as I tried to > > >>>>> explain before. I think your concern is that people may > > >>>>> > > >>> choose not to > > >>> > > >>>>> use error answer-message grammar defined in 7.2 for certain > > >>>>> > > >>> permanent > > >>> > > >>>>> failures. To address both concerns, I suggest we allow use of > E-bit > > >>>>> for permanent failures but leave it as an implementation choice to > > >>>>> use it or not. This again would be backward compatible AFAICS. > > >>>>> > > >>>>> Thanks, > > >>>>> Tolga > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > > >>>>>> Sent: Thursday, September 14, 2006 10:17 AM > > >>>>>> To: Tolga Asveren > > >>>>>> Cc: dime@ietf.org > > >>>>>> Subject: Re: [Dime] Error Code issues for bis > > >>>>>> > > >>>>>> > > >>>>>> Hi Tolga, > > >>>>>> > > >>>>>> Comments inline: > > >>>>>> > > >>>>>>>> This maybe an easy way of performing error handling with just > > >>>>>>>> sending the error grammar but it maybe to harsh (??). A node > > >>>>>>>> receiving a result code set to some non-protocol failure > > >>>>>>>> > > >>>>> value may > > >>>>> > > >>>>>>>> find it more useful to receive the application specific answer > > >>>>>>>> message rather than just the error message in 7.2 since the > > >>>>>>>> error may not be grave and the both end-point application can > > >>>>>>>> > > >>>>> attempt to recover and continue on. > > >>>>> > > >>>>>> An example > > >>>>>> > > >>>>>>>> would be when the result code is set to MISSING_AVP or > > >>>>>>>> > > >>>>>> INVALID_AVP_VALUE > > >>>>>> > > >>>>>>>> and the answer message carries a Failed-AVP. Depending on the > > >>>>>>>> application, the sender of the error may choose to continue > > >>>>>>>> processing the remainder of the request if the offending > > >>>>>>>> > > >>>>> AVP is not > > >>>>> > > >>>>>>>> crucial. The receiver of the error would view the error as a > > >>>>>>>> hint maybe able to compensate/recover and continue on also. > > >>>>>>>> > > >>>>>>>> > > >>>>>>> [TOLGA]This is an interesting point but if such an answer is > > >>>>>>> > > >>>>>> generated, how > > >>>>>> > > >>>>>>> could the peer know the real result of the request > > >>>>>>> > > >>>>> processing? Let's > > >>>>> > > >>>>>>> say Result-Code contains MISSING_AVP, how could the request > > >>>>>>> > > >>>>>> originator determine > > >>>>>> > > >>>>>>> whether the request processing is done successfully? > > >>>>>>> > > >>>>>> I was thinking through other avp's in the application > > >>>>>> > > >>>>> specific answer > > >>>>> > > >>>>>> grammar ... though that maybe stretching the success/failure > > >>>>>> significance of the result-code avp against other avps in > > >>>>>> > > >>>>> the message > > >>>>> > > >>>>>> so may not as advisable. > > >>>>>> > > >>>>>> > > >>>>>>>> I guess this would depend if the implementation is doing full > > >>>>>>>> > > >>>>>> or partial > > >>>>>> > > >>>>>>>> parsing in the base protocol layer. > > >>>>>>>> > > >>>>>>>> > > >>>>>>> [TOLGA]I think I was not clear about this one. The message > > >>>>>>> > > >>>>> is parsed > > >>>>> > > >>>>>>> (or parsed as much as possible depending the type of the error). > > >>>>>>> > > >>>>>> Now an answer > > >>>>>> > > >>>>>>> message needs to be generated. If the grammar of the > > >>>>>>> > > >>>>> answer for that > > >>>>> > > >>>>>>> specific command code is used, all mandatory AVPs which are > > >>>>>>> > > >>>>>> specified in the > > >>>>>> > > >>>>>>> grammar need to be present. Those AVPs possibly could be filled > > >>>>>>> without application logic involvement, but I would think this > > >>>>>>> would > > >>>>>>> > > >>>>>> require to put > > >>>>>> > > >>>>>>> some dummy values there. In such a case, what is the point of > > >>>>>>> inserting them? > > >>>>>>> > > >>>>>>> > > >>>>>> I was thinking in the case where the base protocol part of the > > >>>>>> implementation does only partial parsing of message header > > >>>>>> > > >>>>> and avps it > > >>>>> > > >>>>>> requires and leaves full parsing of the remaining > > >>>>>> > > >>>>> application specific > > >>>>> > > >>>>>> avps to the applications themselves. The scenario you mentioned > > >>>>>> fits well when the failure occurs during the partial parsing. > > >>>>>> During full parsing, application logic can be introduced. > > >>>>>> > > >>>>>> best regards, > > >>>>>> victor > > >>>>>> > > >>>>> _______________________________________________ > > >>>>> DiME mailing list > > >>>>> DiME@ietf.org > > >>>>> https://www1.ietf.org/mailman/listinfo/dime > > >>>>> > > >>>>> > > >>> > > >> _______________________________________________ > > >> DiME mailing list > > >> DiME@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/dime > > >> > > >> > > >> > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > ______________________________________________________________________ > > > This email has been scanned by the MessageLabs Email Security System. > > > For more information please visit http://www.messagelabs.com/email > > > ______________________________________________________________________ > > > > > > > > > > > > > > > > > > > ------------------------------ > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > End of DiME Digest, Vol 9, Issue 29 > > *********************************** > > > > > > -- > Regards > > Rashmi Ranjan Rath > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://www1.ietf.org/pipermail/dime/attachments/20060919/defcaa8b/attachment.html > > ------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > End of DiME Digest, Vol 9, Issue 31 > *********************************** > -- Regards Rashmi Ranjan Rath ------=_Part_106946_11223308.1158670202074 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Chandu,

    Your understanding is absolutely right. A diameter peer can accept message from more one peer. ie multiple instance  of  diameter is possible in a single host.

    Thanks & Regds

    Rashmi Rath
    Software Engineer

    IntelliNet Technologies

    On 9/19/06, dime-request@ietf.org <dime-request@ietf.org > wrote:
    Send DiME mailing list submissions to
             dime@ietf.org

    To subscribe or unsubscribe via the World Wide Web, visit
            https://www1.ietf.org/mailman/listinfo/dime
    or, via email, send a message with subject or body 'help' to
            dime-request@ietf.org

    You can reach the person managing the list at
            dime-owner@ietf.org

    When replying, please edit your Subject line so it is more specific
    than "Re: Contents of DiME digest..."


    Today's Topics:

       1. receving connections from 3868 with multiple instances.
          (Valesh  Chandu)
       2. DiME Digest, Vol 9, Issue 30 (Rashmi Rath)


    ----------------------------------------------------------------------

    Message: 1
    Date: 19 Sep 2006 09:13:57 -0000
    From: "Valesh  Chandu" < chanduvalesh@rediffmail.com>
    Subject: [Dime] receving connections from 3868 with multiple
            instances.
    To: dime@ietf.org
    Message-ID: < 20060919091357.9841.qmail@webmail32.rediffmail.com>
    Content-Type: text/plain; charset="iso-8859-1"

    Hi all,

    I have a doubt regarding receiving connection requests/listening on port 3868 in case of multiple instances on a single host with one interface.

    Snippet from sec 2.1 of RFC 3588:
    A Diameter node MAY initiate connections from a source port other   than the one that it declares it accepts incoming connections on, and MUST be prepared to receive connections on port 3868.A given Diameter instance of the peer state machine MUST NOT use more than one transport connection to communicate with a given peer, unless multiple instances exist on the peer in which case a separate connection per process is allowed.
    Diameter Node is defined as :
    A Diameter node is a host process that implements the Diameter     protocol, and acts either as a Client, Agent or Server.

    My understanding of the above section is that multiple instances of the diameter stack is possible on the same host machine.

    So, if we have multiple instances on a single host then how it is possible to listen on the same port 3868 from all the instances?


    Please any one clarify my doubt?

    Best Regards,
    Chandu

    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://www1.ietf.org/pipermail/dime/attachments/20060919/2fa54a99/attachment-0001.html

    ------------------------------

    Message: 2
    Date: Tue, 19 Sep 2006 16:17:07 +0530
    From: "Rashmi Rath" <rashmir.rath@gmail.com>
    Subject: [Dime] DiME Digest, Vol 9, Issue 30
    To: dime@ietf.org
    Message-ID:
            <4f9fd9700609190347y69205418r936b1f2c49c725d6@mail.gmail.com>
    Content-Type: text/plain; charset="iso-8859-1"

    Hi All,

    I have a question.
    In Disconnect Peer Request, If i put disconnect cause other than BUSY,
    REBOOTING and DO_NOT_WANT_TO_TALK_TO_YOU, should it disconnect the peer
    connection.



    Thanks & Regds

    Rashmi Rath
    Software Engineer
    IntelliNet Technologies


    On 9/18/06, dime-request@ietf.org < dime-request@ietf.org> wrote:
    >
    > Send DiME mailing list submissions to
    >        dime@ietf.org
    >
    > To subscribe or unsubscribe via the World Wide Web, visit
    >        https://www1.ietf.org/mailman/listinfo/dime
    > or, via email, send a message with subject or body 'help' to
    >         dime-request@ietf.org
    >
    > You can reach the person managing the list at
    >        dime-owner@ietf.org
    >
    > When replying, please edit your Subject line so it is more specific
    > than "Re: Contents of DiME digest..."
    >
    >
    > Today's Topics:
    >
    >   1. Re: Error Code issues for bis (Victor Fajardo)
    >
    >
    > ----------------------------------------------------------------------
    >
    > Message: 1
    > Date: Mon, 18 Sep 2006 11:34:18 -0400
    > From: Victor Fajardo <vfajardo@tari.toshiba.com>
    > Subject: Re: [Dime] Error Code issues for bis
    > To: Yoshihiro Ohba <yohba@tari.toshiba.com>
    > Cc: dime@ietf.org
    > Message-ID: < 450EBC7A.1000701@tari.toshiba.com>
    > Content-Type: text/plain; charset=ISO-2022-JP
    >
    > I've updated issue 14 to reflect the current opinion of which I also
    > agree. Pls review the text if it is appropriate or if other folks has
    > other opinions.
    >
    > regards,
    > victor
    >
    >
    > > I support Tolga's proposal on using E-bit and grammar described in 7.2
    > > for permanent errors in addition to protocol errors.
    > >
    > > Yoshihiro Ohba
    > >
    > > On Mon, Sep 18, 2006 at 05:33:31AM +0300, john.loughney@nokia.com wrote:
    > >
    > >> Tolga,
    > >>
    > >> I think that seems reasonable - does anyone else have comments
    > >> on this - supporting or otherwise?  It would be good to wrap
    > >> this issue up.
    > >>
    > >> John
    > >>
    > >>
    > >>> -----Original Message-----
    > >>> From: ext Tolga Asveren [mailto:asveren@ulticom.com]
    > >>> Sent: 15 September, 2006 15:50
    > >>> To: Loughney John (Nokia-NRC/Helsinki); dime@ietf.org
    > >>> Subject: RE: [Dime] Error Code issues for bis
    > >>>
    > >>> John,
    > >>>
    > >>> My only goal is being able to use the grammar described in 7.2
    > >>> for permanent answers as well. For certain situations it is
    > >>> impossible to continue decoding a message, e.g. invalid AVP
    > >>> length for an AVP which is of type OctetString. In such a
    > >>> case, it may not be possible to generate an answer message
    > >>> based on the command's answer grammar, nor does it seem
    > >>> necessary to me.
    > >>>
    > >>> What I suggest is allowing E-bit to be set for permanent
    > >>> failures as well, so that grammar in 7.2 can be used.
    > >>>
    > >>> It is not important that all implementations follow that path,
    > >>> only the ones which consider it necessary/usefull for certain
    > >>> cases can use it.
    > >>>
    > >>> On receiver end, this shouldn't be a problem because if the
    > >>> E-bit is set, receiver will decode the message based on 7.2
    > >>> grammar, otherwise command answer grammar will be used. this
    > >>> rule is already there in RFC3588.
    > >>>
    > >>> After thinking a bit more, the only possible backward
    > >>> compatibility issue I see is, if some implementation checks
    > >>> whether E-bit is set for an answer with Result-Code other than
    > >>> Protocol Error. Considering that for some Permanent Failures
    > >>> 7.2 grammar is really necessary, I believe that shouldn't be a
    > >>> big issue.
    > >>>
    > >>>     Thanks,
    > >>>     Tolga
    > >>>
    > >>>
    > >>>> -----Original Message-----
    > >>>> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
    > >>>> Sent: Thursday, September 14, 2006 11:34 PM
    > >>>> To: asveren@ulticom.com; dime@ietf.org
    > >>>> Subject: RE: [Dime] Error Code issues for bis
    > >>>>
    > >>>>
    > >>>> Tolga,
    > >>>>
    > >>>> If it is optional, that means you can't count that any
    > >>>>
    > >>> implementations
    > >>>
    > >>>> will support it.
    > >>>>
    > >>>> However, are you suggesting the E-bit could be used as a hint for
    > >>>> permantant failures?
    > >>>>
    > >>>> John
    > >>>>
    > >>>>
    > >>>>> -----Original Message-----
    > >>>>> From: ext Tolga Asveren [mailto: asveren@ulticom.com]
    > >>>>> Sent: 14 September, 2006 21:14
    > >>>>> To: dime@ietf.org
    > >>>>> Subject: RE: [Dime] Error Code issues for bis
    > >>>>>
    > >>>>> Hi Victor,
    > >>>>>
    > >>>>> I had a look to Issue14. I already thought that use of E-bit is
    > >>>>> exclusively for protocol errors based on "Note that these and only
    > >>>>> these erors MUST only be used in answer messages whose 'E' bit is
    > >>>>> set." in 7.1.3. The proposed text further supports this idea.
    > >>>>>
    > >>>>> I see a value of using E-bit for permanent failures as I tried to
    > >>>>> explain before. I think your concern is that people may
    > >>>>>
    > >>> choose not to
    > >>>
    > >>>>> use error answer-message grammar defined in 7.2 for certain
    > >>>>>
    > >>> permanent
    > >>>
    > >>>>> failures. To address both concerns, I suggest we allow use of E-bit
    > >>>>> for permanent failures but leave it as an implementation choice to
    > >>>>> use it or not. This again would be backward compatible AFAICS.
    > >>>>>
    > >>>>>    Thanks,
    > >>>>>    Tolga
    > >>>>>
    > >>>>>
    > >>>>>
    > >>>>>
    > >>>>>> -----Original Message-----
    > >>>>>> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com]
    > >>>>>> Sent: Thursday, September 14, 2006 10:17 AM
    > >>>>>> To: Tolga Asveren
    > >>>>>> Cc: dime@ietf.org
    > >>>>>> Subject: Re: [Dime] Error Code issues for bis
    > >>>>>>
    > >>>>>>
    > >>>>>> Hi Tolga,
    > >>>>>>
    > >>>>>> Comments inline:
    > >>>>>>
    > >>>>>>>> This maybe an easy way of performing error handling with just
    > >>>>>>>> sending the error grammar but it maybe to harsh (??). A node
    > >>>>>>>> receiving a result code set to some non-protocol failure
    > >>>>>>>>
    > >>>>> value may
    > >>>>>
    > >>>>>>>> find it more useful to receive the application specific answer
    > >>>>>>>> message rather than just the error message in 7.2 since the
    > >>>>>>>> error may not be grave and the both end-point application can
    > >>>>>>>>
    > >>>>> attempt to recover and continue on.
    > >>>>>
    > >>>>>> An example
    > >>>>>>
    > >>>>>>>> would be when the result code is set to MISSING_AVP or
    > >>>>>>>>
    > >>>>>> INVALID_AVP_VALUE
    > >>>>>>
    > >>>>>>>> and the answer message carries a Failed-AVP. Depending on the
    > >>>>>>>> application, the sender of the error may choose to continue
    > >>>>>>>> processing the remainder of the request if the offending
    > >>>>>>>>
    > >>>>> AVP is not
    > >>>>>
    > >>>>>>>> crucial. The receiver of the error would view the error as a
    > >>>>>>>> hint maybe able to compensate/recover and continue on also.
    > >>>>>>>>
    > >>>>>>>>
    > >>>>>>> [TOLGA]This is an interesting point but if such an answer is
    > >>>>>>>
    > >>>>>> generated, how
    > >>>>>>
    > >>>>>>> could the peer know the real result of the request
    > >>>>>>>
    > >>>>> processing? Let's
    > >>>>>
    > >>>>>>> say Result-Code contains MISSING_AVP, how could the request
    > >>>>>>>
    > >>>>>> originator determine
    > >>>>>>
    > >>>>>>> whether the request processing is done successfully?
    > >>>>>>>
    > >>>>>> I was thinking through other avp's in the application
    > >>>>>>
    > >>>>> specific answer
    > >>>>>
    > >>>>>> grammar ... though that maybe stretching the success/failure
    > >>>>>> significance of the result-code avp against other avps in
    > >>>>>>
    > >>>>> the message
    > >>>>>
    > >>>>>> so may not as advisable.
    > >>>>>>
    > >>>>>>
    > >>>>>>>> I guess this would depend if the implementation is doing full
    > >>>>>>>>
    > >>>>>> or partial
    > >>>>>>
    > >>>>>>>> parsing in the base protocol layer.
    > >>>>>>>>
    > >>>>>>>>
    > >>>>>>> [TOLGA]I think I was not clear about this one. The message
    > >>>>>>>
    > >>>>> is parsed
    > >>>>>
    > >>>>>>> (or parsed as much as possible depending the type of the error).
    > >>>>>>>
    > >>>>>> Now an answer
    > >>>>>>
    > >>>>>>> message needs to be generated. If the grammar of the
    > >>>>>>>
    > >>>>> answer for that
    > >>>>>
    > >>>>>>> specific command code is used, all mandatory AVPs which are
    > >>>>>>>
    > >>>>>> specified in the
    > >>>>>>
    > >>>>>>> grammar need to be present. Those AVPs possibly could be filled
    > >>>>>>> without application logic involvement, but I would think this
    > >>>>>>> would
    > >>>>>>>
    > >>>>>> require to put
    > >>>>>>
    > >>>>>>> some dummy values there. In such a case, what is the point of
    > >>>>>>> inserting them?
    > >>>>>>>
    > >>>>>>>
    > >>>>>> I was thinking in the case where the base protocol part of the
    > >>>>>> implementation does only partial parsing of message header
    > >>>>>>
    > >>>>> and avps it
    > >>>>>
    > >>>>>> requires and leaves full parsing of the remaining
    > >>>>>>
    > >>>>> application specific
    > >>>>>
    > >>>>>> avps to the applications themselves. The scenario you mentioned
    > >>>>>> fits well when the failure occurs during the partial parsing.
    > >>>>>> During full parsing, application logic can be introduced.
    > >>>>>>
    > >>>>>> best regards,
    > >>>>>> victor
    > >>>>>>
    > >>>>> _______________________________________________
    > >>>>> DiME mailing list
    > >>>>> DiME@ietf.org
    > >>>>> https://www1.ietf.org/mailman/listinfo/dime
    > >>>>>
    > >>>>>
    > >>>
    > >> _______________________________________________
    > >> DiME mailing list
    > >> DiME@ietf.org
    > >> https://www1.ietf.org/mailman/listinfo/dime
    > >>
    > >>
    > >>
    > >
    > > _______________________________________________
    > > DiME mailing list
    > > DiME@ietf.org
    > > https://www1.ietf.org/mailman/listinfo/dime
    > >
    > > ______________________________________________________________________
    > > This email has been scanned by the MessageLabs Email Security System.
    > > For more information please visit http://www.messagelabs.com/email
    > > ______________________________________________________________________
    > >
    > >
    > >
    >
    >
    >
    >
    > ------------------------------
    >
    > _______________________________________________
    > DiME mailing list
    > DiME@ietf.org
    > https://www1.ietf.org/mailman/listinfo/dime
    >
    >
    > End of DiME Digest, Vol 9, Issue 29
    > ***********************************
    >



    --
    Regards

    Rashmi Ranjan Rath
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://www1.ietf.org/pipermail/dime/attachments/20060919/defcaa8b/attachment.html

    ------------------------------

    _______________________________________________
    DiME mailing list
    DiME@ietf.org
    https://www1.ietf.org/mailman/listinfo/dime


    End of DiME Digest, Vol 9, Issue 31
    ***********************************



    --
    Regards

    Rashmi Ranjan Rath ------=_Part_106946_11223308.1158670202074-- --===============0289880014== 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://www1.ietf.org/mailman/listinfo/dime --===============0289880014==-- From dime-bounces@ietf.org Wed Sep 20 08:50:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ1X4-0001Pj-2A; Wed, 20 Sep 2006 08:50:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ1X2-0001Pb-SR for dime@ietf.org; Wed, 20 Sep 2006 08:50:28 -0400 Received: from e31.co.us.ibm.com ([32.97.110.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ1X0-0001nc-AA for dime@ietf.org; Wed, 20 Sep 2006 08:50:28 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.13.8/8.12.11) with ESMTP id k8KCoPlD027867 for ; Wed, 20 Sep 2006 08:50:25 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k8KCoPnl337550 for ; Wed, 20 Sep 2006 06:50:25 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k8KCoPH2024098 for ; Wed, 20 Sep 2006 06:50:25 -0600 Received: from d03nm114.boulder.ibm.com (d03nm114.boulder.ibm.com [9.17.195.140]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k8KCoPrT024095; Wed, 20 Sep 2006 06:50:25 -0600 In-Reply-To: <20060919091357.9841.qmail@webmail32.rediffmail.com> To: Valesh Chandu Subject: Re: [Dime] receving connections from 3868 with multiple instances. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 Message-ID: From: Timothy Smith Date: Wed, 20 Sep 2006 08:50:24 -0400 X-MIMETrack: Serialize by Router on D03NM114/03/M/IBM(Release 7.0.1HF343 | August 2, 2006) at 09/20/2006 06:50:25, Serialize complete at 09/20/2006 06:50:25 X-Spam-Score: 0.1 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 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="===============1169236032==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============1169236032== Content-Type: multipart/alternative; boundary="=_alternative 0046883B852571EF_=" This is a multipart message in MIME format. --=_alternative 0046883B852571EF_= Content-Type: text/plain; charset="US-ASCII" Hi Chandu, I think you have touched on an area where there are a couple of unclear points. I also interpret that you can have multiple Diameter nodes on the same host. I think this implies: 1) Each node must listen on a different port as you have pointed out. So, only one of the nodes can use the recommended port 3868. 2) The Origin-Host AVP is also problematic in that its value conflicts in a host with multiple Diameter nodes. The Origin-Host is of type Diameter Identity, and "The value of the Origin-Host AVP is guaranteed to be unique within a single host". But also, "DiameterIdentity value is used to uniquely identify a Diameter node for purposes of duplicate connection..." These two statements are inconsistent on a host with multiple Diameter nodes. The Diameter Identity is a FQDN which realistically means you can only have a single Origin-Host name for all of the nodes on a given host. So, the dilemma is that if you have multiple Diameter nodes on host A and multiple Diameter nodes on host B, then because of the single connection rule, you will only be able to set up one connection between one of the nodes on host A and one of the nodes on host B. This is something that I think should be clarified in the BIS document. My preference would be to say that the Origin-Host AVP should be a FQDN, but not that it must be a FQDN. That way, you could assign a unique Origin-Host name to each Diameter node on a host. And any or all nodes on Host A could establish a connection to any or all nodes on Host B. Best Regards, Timothy Smith tjsmith@us.ibm.com (919) 254-4723 "Valesh Chandu" 09/19/2006 05:13 AM Please respond to Valesh Chandu To dime@ietf.org cc Subject [Dime] receving connections from 3868 with multiple instances. Hi all, I have a doubt regarding receiving connection requests/listening on port 3868 in case of multiple instances on a single host with one interface. Snippet from sec 2.1 of RFC 3588: A Diameter node MAY initiate connections from a source port other than the one that it declares it accepts incoming connections on, and MUST be prepared to receive connections on port 3868.A given Diameter instance of the peer state machine MUST NOT use more than one transport connection to communicate with a given peer, unless multiple instances exist on the peer in which case a separate connection per process is allowed. Diameter Node is defined as : A Diameter node is a host process that implements the Diameter protocol, and acts either as a Client, Agent or Server. My understanding of the above section is that multiple instances of the diameter stack is possible on the same host machine. So, if we have multiple instances on a single host then how it is possible to listen on the same port 3868 from all the instances? Please any one clarify my doubt? Best Regards, Chandu https://www1.ietf.org/mailman/listinfo/dime --=_alternative 0046883B852571EF_= Content-Type: text/html; charset="US-ASCII"
    Hi Chandu,

    I think you have touched on an area where there are a couple of unclear points.  I also interpret that you can have multiple Diameter nodes on the same host.  I think this implies:
    1) Each node must listen on a different port as you have pointed out.  So, only one of the nodes can use the recommended port 3868.
    2) The Origin-Host AVP is also problematic in that its value conflicts in a host with multiple Diameter nodes.  The Origin-Host is of type Diameter Identity, and "The value of the Origin-Host AVP is guaranteed to be unique within a single host".  But also, "DiameterIdentity value is used to uniquely identify a Diameter node for purposes of duplicate connection..."   These two statements are inconsistent on a host with multiple Diameter nodes.  The Diameter Identity is a FQDN which realistically means you can only have a single Origin-Host name for all of the nodes on a given host.  So, the dilemma is that if you have multiple Diameter nodes on host A and multiple Diameter nodes on host B, then because of the single connection rule, you will only be able to set up one connection between one of the nodes on host A and one of the nodes on host B.   This is something that I think should be clarified in the BIS document.  My preference would be to say that the Origin-Host AVP should be a FQDN, but not that it must be a FQDN.  That way, you could assign a unique Origin-Host name to each Diameter node on a host.  And any or all nodes on Host A could establish a connection to any or all nodes on Host B.

    Best Regards,
    Timothy Smith

    tjsmith@us.ibm.com
    (919) 254-4723


    "Valesh  Chandu" <chanduvalesh@rediffmail.com>

    09/19/2006 05:13 AM
    Please respond to
    Valesh  Chandu <chanduvalesh@rediffmail.com>
    To
    		dime@ietf.org
    cc
    Subject
    		[Dime] receving connections from 3868 with multiple instances.





    Hi all,

    I have a doubt regarding receiving connection requests/listening on port 3868 in case of multiple instances on a single host with one interface.

    Snippet from sec 2.1 of RFC 3588:
    A Diameter node MAY initiate connections from a source port other  than the one that it declares it accepts incoming connections on, and MUST be prepared to receive connections on port 3868.A given Diameter instance of the peer state machine MUST NOT use more than one transport connection to communicate with a given peer, unless multiple instances exist on the peer in which case a separate connection per process is allowed.
    Diameter Node is defined as :
    A Diameter node is a host process that implements the Diameter    protocol, and acts either as a Client, Agent or Server.

    My understanding of the above section is that multiple instances of the diameter stack is possible on the same host machine.

    So, if we have multiple instances on a single host then how it is possible to listen on the same port 3868 from all the instances?


    Please any one clarify my doubt?

    Best Regards,
    Chandu
     



    https://www1.ietf.org/mailman/listinfo/dime

    --=_alternative 0046883B852571EF_=-- --===============1169236032== 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://www1.ietf.org/mailman/listinfo/dime --===============1169236032==-- From dime-bounces@ietf.org Wed Sep 20 09:13:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ1t5-00015O-DK; Wed, 20 Sep 2006 09:13:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ1t4-00015G-FQ for dime@ietf.org; Wed, 20 Sep 2006 09:13:14 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ1t3-0004EL-4M for dime@ietf.org; Wed, 20 Sep 2006 09:13:14 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id DD83572F1A; Wed, 20 Sep 2006 09:13:10 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k8KDD8R6007717; Wed, 20 Sep 2006 09:13:09 -0400 (EDT) From: "Tolga Asveren" To: "Timothy Smith" , "Valesh Chandu" Subject: RE: [Dime] receving connections from 3868 with multiple instances. Date: Wed, 20 Sep 2006 09:11:46 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-Reply-To: Importance: Normal Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Timothy, Please see below for comments. Thanks, Tolga -----Original Message----- From: Timothy Smith [mailto:tjsmith@us.ibm.com] Sent: Wednesday, September 20, 2006 8:50 AM To: Valesh Chandu Cc: dime@ietf.org Subject: Re: [Dime] receving connections from 3868 with multiple instances. Hi Chandu, I think you have touched on an area where there are a couple of unclear points. I also interpret that you can have multiple Diameter nodes on the same host. I think this implies: 1) Each node must listen on a different port as you have pointed out. So, only one of the nodes can use the recommended port 3868. [TOLGA]I agree. 2) The Origin-Host AVP is also problematic in that its value conflicts in a host with multiple Diameter nodes. The Origin-Host is of type Diameter Identity, and "The value of the Origin-Host AVP is guaranteed to be unique within a single host". But also, "DiameterIdentity value is used to uniquely identify a Diameter node for purposes of duplicate connection..." These two statements are inconsistent on a host with multiple Diameter nodes. The Diameter Identity is a FQDN which realistically means you can only have a single Origin-Host name for all of the nodes on a given host. So, the dilemma is that if you have multiple Diameter nodes on host A and multiple Diameter nodes on host B, then because of the single connection rule, you will only be able to set up one connection between one of the nodes on host A and one of the nodes on host B. This is something that I think should be clarified in the BIS document. My preference would be to say that the Origin-Host AVP should be a FQDN, but not that it must be a FQDN. That way, you could assign a unique Origin-Host name to each Diameter node on a host. And any or all nodes on Host A could establish a connection to any or all nodes on Host B. [TOLGA]Is this really a problem? A physical host can have multiple FQDN, where each of them refer to a single Diameter node. I think this is already covered in definition of Diameter Identity in 4.3. Best Regards, Timothy Smith tjsmith@us.ibm.com (919) 254-4723 "Valesh Chandu" 09/19/2006 05:13 AM Please respond to Valesh Chandu Todime@ietf.org cc Subject[Dime] receving connections from 3868 with multiple instances. Hi all, I have a doubt regarding receiving connection requests/listening on port 3868 in case of multiple instances on a single host with one interface. Snippet from sec 2.1 of RFC 3588: A Diameter node MAY initiate connections from a source port other than the one that it declares it accepts incoming connections on, and MUST be prepared to receive connections on port 3868.A given Diameter instance of the peer state machine MUST NOT use more than one transport connection to communicate with a given peer, unless multiple instances exist on the peer in which case a separate connection per process is allowed. Diameter Node is defined as : A Diameter node is a host process that implements the Diameter protocol, and acts either as a Client, Agent or Server. My understanding of the above section is that multiple instances of the diameter stack is possible on the same host machine. So, if we have multiple instances on a single host then how it is possible to listen on the same port 3868 from all the instances? Please any one clarify my doubt? Best Regards, Chandu https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 20 14:24:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ6jr-00025E-Cu; Wed, 20 Sep 2006 14:24:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ6jq-00022l-AG for dime@ietf.org; Wed, 20 Sep 2006 14:24:02 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ6ji-00069T-EA for dime@ietf.org; Wed, 20 Sep 2006 14:24:02 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id D157FC948E for ; Wed, 20 Sep 2006 14:23:54 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k8KINr2R005714 for ; Wed, 20 Sep 2006 14:23:53 -0400 (EDT) From: "Tolga Asveren" To: Date: Wed, 20 Sep 2006 14:22:29 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Dime] RFC3588bis Issue12 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org >From issue tracker, Issue12: " There seems to be two concepts of node identity in the base spec. 1. FQDN for indexing the peer table 2. FQDN+port (+more) in redirect URI. " AFACS, there is no problem here.The Host Identity in peer table is of type DiameterIdentity, whereas Redirect-Host AVP is of type DiameterURI. This makes sense to me, because one needs to know transport/port in addition to FQDN, to be able to establish a connection after an asnwer with DIAMETER_REDIRECT_INDICATION result code. If one wants first to perform a check in peer table based on Redirect-Host AVP value, this is also possible by extracting FQDN portion of it. Should this issue be closed with no action or am I missing something? Thanks, Tolga _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 20 14:31:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ6rO-0003Jv-1u; Wed, 20 Sep 2006 14:31:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ6rM-0003Jq-Ub for dime@ietf.org; Wed, 20 Sep 2006 14:31:48 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ6rL-0007le-JW for dime@ietf.org; Wed, 20 Sep 2006 14:31:48 -0400 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 k8KIUP2n077447; Wed, 20 Sep 2006 14:30:25 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <4510E12B.6000009@tari.toshiba.com> Date: Wed, 20 Sep 2006 02:35:23 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.5 (X11/20060812) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] RFC3588bis Issue12 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.2 (--) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga, I agree. The issue will be closed. regards, victor > >From issue tracker, Issue12: > > " > There seems to be two concepts of node identity in the base spec. > > 1. FQDN for indexing the peer table > 2. FQDN+port (+more) in redirect URI. > " > > AFACS, there is no problem here.The Host Identity in peer table is of type > DiameterIdentity, whereas Redirect-Host AVP is of type DiameterURI. This > makes sense to me, because one needs to know transport/port in addition to > FQDN, to be able to establish a connection after an asnwer with > DIAMETER_REDIRECT_INDICATION result code. If one wants first to perform a > check in peer table based on Redirect-Host AVP value, this is also possible > by extracting FQDN portion of it. > > Should this issue be closed with no action or am I missing something? > > Thanks, > Tolga > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 20 16:41:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ8sv-0001CQ-DR; Wed, 20 Sep 2006 16:41:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ8su-0001CC-Hb for dime@ietf.org; Wed, 20 Sep 2006 16:41:32 -0400 Received: from e36.co.us.ibm.com ([32.97.110.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ8ss-0004F0-T8 for dime@ietf.org; Wed, 20 Sep 2006 16:41:32 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e36.co.us.ibm.com (8.13.8/8.12.11) with ESMTP id k8KKfQPP000989 for ; Wed, 20 Sep 2006 16:41:26 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k8KKfQK0209400 for ; Wed, 20 Sep 2006 14:41:26 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k8KKfQxf020183 for ; Wed, 20 Sep 2006 14:41:26 -0600 Received: from d03nm114.boulder.ibm.com (d03nm114.boulder.ibm.com [9.17.195.140]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k8KKfQTo020180; Wed, 20 Sep 2006 14:41:26 -0600 In-Reply-To: To: "Tolga Asveren" Subject: RE: [Dime] receving connections from 3868 with multiple instances. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 Message-ID: From: Timothy Smith Date: Wed, 20 Sep 2006 16:41:18 -0400 X-MIMETrack: Serialize by Router on D03NM114/03/M/IBM(Release 7.0.1HF343 | August 2, 2006) at 09/20/2006 14:41:26, Serialize complete at 09/20/2006 14:41:26 X-Spam-Score: 0.5 (/) X-Scan-Signature: 3f2cf88677bfbdeff30feb2c80e2257d Cc: dime@ietf.org, Valesh Chandu X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 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="===============0185412015==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============0185412015== Content-Type: multipart/alternative; boundary="=_alternative 0071A4D6852571EF_=" This is a multipart message in MIME format. --=_alternative 0071A4D6852571EF_= Content-Type: text/plain; charset="US-ASCII" Hi Tolga, Thanks for your note. I think I was stuck in a rut. From your note, I would assume that we can update a DNS server with any number of aliases to provide a unique FQDN for each node on the same host, correct? Best Regards, Timothy Smith tjsmith@us.ibm.com (919) 254-4723 "Tolga Asveren" 09/20/2006 09:11 AM To Timothy Smith/Raleigh/IBM@IBMUS, "Valesh Chandu" cc Subject RE: [Dime] receving connections from 3868 with multiple instances. Hi Timothy, Please see below for comments. Thanks, Tolga -----Original Message----- From: Timothy Smith [mailto:tjsmith@us.ibm.com] Sent: Wednesday, September 20, 2006 8:50 AM To: Valesh Chandu Cc: dime@ietf.org Subject: Re: [Dime] receving connections from 3868 with multiple instances. Hi Chandu, I think you have touched on an area where there are a couple of unclear points. I also interpret that you can have multiple Diameter nodes on the same host. I think this implies: 1) Each node must listen on a different port as you have pointed out. So, only one of the nodes can use the recommended port 3868. [TOLGA]I agree. 2) The Origin-Host AVP is also problematic in that its value conflicts in a host with multiple Diameter nodes. The Origin-Host is of type Diameter Identity, and "The value of the Origin-Host AVP is guaranteed to be unique within a single host". But also, "DiameterIdentity value is used to uniquely identify a Diameter node for purposes of duplicate connection..." These two statements are inconsistent on a host with multiple Diameter nodes. The Diameter Identity is a FQDN which realistically means you can only have a single Origin-Host name for all of the nodes on a given host. So, the dilemma is that if you have multiple Diameter nodes on host A and multiple Diameter nodes on host B, then because of the single connection rule, you will only be able to set up one connection between one of the nodes on host A and one of the nodes on host B. This is something that I think should be clarified in the BIS document. My preference would be to say that the Origin-Host AVP should be a FQDN, but not that it must be a FQDN. That way, you could assign a unique Origin-Host name to each Diameter node on a host. And any or all nodes on Host A could establish a connection to any or all nodes on Host B. [TOLGA]Is this really a problem? A physical host can have multiple FQDN, where each of them refer to a single Diameter node. I think this is already covered in definition of Diameter Identity in 4.3. Best Regards, Timothy Smith tjsmith@us.ibm.com (919) 254-4723 "Valesh Chandu" 09/19/2006 05:13 AM Please respond to Valesh Chandu Todime@ietf.org cc Subject[Dime] receving connections from 3868 with multiple instances. Hi all, I have a doubt regarding receiving connection requests/listening on port 3868 in case of multiple instances on a single host with one interface. Snippet from sec 2.1 of RFC 3588: A Diameter node MAY initiate connections from a source port other than the one that it declares it accepts incoming connections on, and MUST be prepared to receive connections on port 3868.A given Diameter instance of the peer state machine MUST NOT use more than one transport connection to communicate with a given peer, unless multiple instances exist on the peer in which case a separate connection per process is allowed. Diameter Node is defined as : A Diameter node is a host process that implements the Diameter protocol, and acts either as a Client, Agent or Server. My understanding of the above section is that multiple instances of the diameter stack is possible on the same host machine. So, if we have multiple instances on a single host then how it is possible to listen on the same port 3868 from all the instances? Please any one clarify my doubt? Best Regards, Chandu https://www1.ietf.org/mailman/listinfo/dime --=_alternative 0071A4D6852571EF_= Content-Type: text/html; charset="US-ASCII"
    Hi Tolga,

    Thanks for your note.  I think I was stuck in a rut.  From your note, I would assume that we can update a DNS server with any number of aliases to provide a unique FQDN for each node on the same host, correct?  

    Best Regards,
    Timothy Smith

    tjsmith@us.ibm.com
    (919) 254-4723


    "Tolga Asveren" <asveren@ulticom.com>

    09/20/2006 09:11 AM

    To
    		Timothy Smith/Raleigh/IBM@IBMUS, "Valesh Chandu" <chanduvalesh@rediffmail.com>
    cc
    		<dime@ietf.org>
    Subject
    		RE: [Dime] receving connections from 3868 with multiple instances.





    Hi Timothy,

    Please see below for comments.

     Thanks,
     Tolga


    -----Original Message-----
    From: Timothy Smith [mailto:tjsmith@us.ibm.com]
    Sent: Wednesday, September 20, 2006 8:50 AM
    To: Valesh Chandu
    Cc: dime@ietf.org
    Subject: Re: [Dime] receving connections from 3868 with multiple instances.



    Hi Chandu,

    I think you have touched on an area where there are a couple of unclear
    points.  I also interpret that you can have multiple Diameter nodes on the
    same host.  I think this implies:
    1) Each node must listen on a different port as you have pointed out.  So,
    only one of the nodes can use the recommended port 3868.
    [TOLGA]I agree.
    2) The Origin-Host AVP is also problematic in that its value conflicts in a
    host with multiple Diameter nodes.  The Origin-Host is of type Diameter
    Identity, and "The value of the Origin-Host AVP is guaranteed to be unique
    within a single host".  But also, "DiameterIdentity value is used to
    uniquely identify a Diameter node for purposes of duplicate connection..."
    These two statements are inconsistent on a host with multiple Diameter
    nodes.  The Diameter Identity is a FQDN which realistically means you can
    only have a single Origin-Host name for all of the nodes on a given host.
    So, the dilemma is that if you have multiple Diameter nodes on host A and
    multiple Diameter nodes on host B, then because of the single connection
    rule, you will only be able to set up one connection between one of the
    nodes on host A and one of the nodes on host B.   This is something that I
    think should be clarified in the BIS document.  My preference would be to
    say that the Origin-Host AVP should be a FQDN, but not that it must be a
    FQDN.  That way, you could assign a unique Origin-Host name to each Diameter
    node on a host.  And any or all nodes on Host A could establish a connection
    to any or all nodes on Host B.
    [TOLGA]Is this really a problem? A physical host can have multiple FQDN,
    where each of them refer to a single Diameter node. I think this is already
    covered in definition of Diameter Identity in 4.3.

    Best Regards,
    Timothy Smith

    tjsmith@us.ibm.com
    (919) 254-4723



    "Valesh  Chandu" <chanduvalesh@rediffmail.com>
    09/19/2006 05:13 AM Please respond to
    Valesh  Chandu <chanduvalesh@rediffmail.com>

    Todime@ietf.org
    cc
    Subject[Dime] receving connections from 3868 with multiple instances.







    Hi all,

    I have a doubt regarding receiving connection requests/listening on port
    3868 in case of multiple instances on a single host with one interface.

    Snippet from sec 2.1 of RFC 3588:
    A Diameter node MAY initiate connections from a source port other  than the
    one that it declares it accepts incoming connections on, and MUST be
    prepared to receive connections on port 3868.A given Diameter instance of
    the peer state machine MUST NOT use more than one transport connection to
    communicate with a given peer, unless multiple instances exist on the peer
    in which case a separate connection per process is allowed.
    Diameter Node is defined as :
    A Diameter node is a host process that implements the Diameter    protocol,
    and acts either as a Client, Agent or Server.

    My understanding of the above section is that multiple instances of the
    diameter stack is possible on the same host machine.

    So, if we have multiple instances on a single host then how it is possible
    to listen on the same port 3868 from all the instances?


    Please any one clarify my doubt?

    Best Regards,
    Chandu



    https://www1.ietf.org/mailman/listinfo/dime
    --=_alternative 0071A4D6852571EF_=-- --===============0185412015== 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://www1.ietf.org/mailman/listinfo/dime --===============0185412015==-- From dime-bounces@ietf.org Wed Sep 20 23:02:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQEpM-0005Bw-Vn; Wed, 20 Sep 2006 23:02:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQEpM-00059X-CT; Wed, 20 Sep 2006 23:02:16 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQEpH-0008Md-RD; Wed, 20 Sep 2006 23:02:16 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 095899000D; Wed, 20 Sep 2006 23:02:08 -0400 (EDT) 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 21317-06; Wed, 20 Sep 2006 23:02:07 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP; Wed, 20 Sep 2006 23:02:07 -0400 (EDT) X-MessageTextProcessor: DisclaimIt (2.70.271) [Starent Networks Corp.] Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 23:02:07 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 20 Sep 2006 23:02:07 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D78373C4@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: renaming and re-scoping of the Dime MIP6 I-Ds thread-index: AcbdKk/QQ9L3YERDRbKvIzRS6ThgJQ== From: "Chowdhury, Kuntal" To: , Importance: normal Priority: normal X-OriginalArrivalTime: 21 Sep 2006 03:02:07.0470 (UTC) FILETIME=[52D518E0:01C6DD2A] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Cc: charliep@iprg.nokia.com, hannes.tschofenig@siemens.com Subject: [Dime] renaming and re-scoping of the Dime MIP6 I-Ds X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 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="===============2009456153==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============2009456153== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6DD2A.52A5EC0E" Content-Transfer-Encoding: 7bit This is a multi-part message in MIME format. ------_=_NextPart_001_01C6DD2A.52A5EC0E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 We had an offline discussion on the scope of the two Diameter mip6 bootstrapping I-Ds that are being defined at this time. The current titles and scopes of the documents seem to convey inaccurate information of the actual intent of each of them. For example, the mip6 bootstrapping solutions as developed in MIP6 WG need the Diameter components for the following interfaces: =20 NAS-HAAA: Integrated scenario HA-HAAA: Integrated and Split scenarios =20 What we need to do in Dime WG is to define these two components. The current structures of the drafts introduce unnecessary dependencies between them by focusing on the individual mip6 bootstrapping scenarios rather than the actual purpose i.e. defining the Diameter (AAA) components needed for both the mip6 bootstrapping solutions. Moreover, the HA - HAAA interface can be defined in such a way that it covers mip6 in general.=20 =20 So, the suggestion is to rename and re-scope the documents as follows: =20 1. Filename =3D dime-mip6-nas-aaa-interface: Title =3D The NAS - HAAA interface for mip6 bootstrapping 2. Filename =3D dime-mip6-ha-aaa-interface: Title =3D The HA - HAAA interface for mip6 Please let us know your comments. Regards, Kuntal "This email message and any attachments are confidential information of = Starent Networks, Corp. The information transmitted may not be used to = create or change any contractual obligations of Starent Networks, Corp. = Any review, retransmission, dissemination or other use of, or taking of = any action in reliance upon this e-mail and its attachments by persons = or entities other than the intended recipient is prohibited. If you are = not the intended recipient, please notify the sender immediately -- by = replying to this message or by sending an email to = postmaster@starentnetworks.com -- and destroy all copies of this message = and any attachments without reading or disclosing their contents. Thank = you." ------_=_NextPart_001_01C6DD2A.52A5EC0E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi all,

     

    We had an offline discussion on the scope of the two = Diameter mip6 bootstrapping I-Ds that are being defined at this time. The current titles and scopes of the documents seem to convey = inaccurate information of the actual intent of each of them. For example, the mip6 bootstrapping solutions as developed in MIP6 WG need the Diameter = components for the following interfaces:

     

    NAS-HAAA: Integrated = scenario

    HA-HAAA: Integrated and Split = scenarios

     

    What we need to do in Dime WG is to define these two components. The current structures of the drafts introduce unnecessary dependencies between them by focusing on the individual mip6 = bootstrapping scenarios rather than the actual purpose i.e. defining the Diameter = (AAA) components needed for both the mip6 bootstrapping solutions. Moreover, the HA = – HAAA interface can be defined in such a way that it covers mip6 in general. =

     

    So, the suggestion is to rename and re-scope the = documents as follows:

     

    1. Filename =3D dime-mip6-nas-aaa-interface: Title = =3D The NAS - HAAA interface for mip6 bootstrapping

    2. Filename =3D dime-mip6-ha-aaa-interface: Title =3D The HA - HAAA interface for = mip6

    Please let us know your comments.

    Regards,

    Kuntal

    "This email message and any attachments are confidential information = of Starent Networks, Corp. The information transmitted may not be used = to create or change any contractual obligations of Starent Networks, = Corp. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon this e-mail and its attachments by = persons or entities other than the intended recipient is prohibited. If = you are not the intended recipient, please notify the sender immediately = -- by replying to this message or by sending an email to = postmaster@starentnetworks.com -- and destroy all copies of this message = and any attachments without reading or disclosing their contents. Thank = you." ------_=_NextPart_001_01C6DD2A.52A5EC0E-- --===============2009456153== 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://www1.ietf.org/mailman/listinfo/dime --===============2009456153==-- From dime-bounces@ietf.org Wed Sep 20 23:14:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQF0u-0003ZA-0P; Wed, 20 Sep 2006 23:14:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQF0r-0003Mi-Uv; Wed, 20 Sep 2006 23:14:09 -0400 Received: from dsl092-223-006.sfo1.dsl.speakeasy.net ([66.92.223.6] helo=moe.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQF0n-0001PQ-Hq; Wed, 20 Sep 2006 23:14:09 -0400 Received: from [192.168.1.102] ([24.6.251.221]) by moe.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 20:12:47 -0700 Message-ID: <4512033A.2080809@azairenet.com> Date: Wed, 20 Sep 2006 20:12:58 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Chowdhury, Kuntal" Subject: Re: [Dime] renaming and re-scoping of the Dime MIP6 I-Ds References: <7CCD07160348804497EF29E9EA5560D78373C4@exchtewks2.starentnetworks.com> In-Reply-To: <7CCD07160348804497EF29E9EA5560D78373C4@exchtewks2.starentnetworks.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 21 Sep 2006 03:12:47.0713 (UTC) FILETIME=[D0726D10:01C6DD2B] X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: mip6@ietf.org, dime@ietf.org, charliep@iprg.nokia.com, hannes.tschofenig@siemens.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org sounds like a good idea. Chowdhury, Kuntal wrote: > We had an offline discussion on the scope of the two Diameter mip6 > bootstrapping I-Ds that are being defined at this time. The > current titles and scopes of the documents seem to convey inaccurate > information of the actual intent of each of them. For example, the mip6 > bootstrapping solutions as developed in MIP6 WG need the Diameter > components for the following interfaces: > > NAS-HAAA: Integrated scenario this would be for MIP6 service authorization + MIP6 HA/HoA information, correct? > HA-HAAA: Integrated and Split scenarios this would include authentication + authorization, correct? Vijay > > > > What we need to do in Dime WG is to define these two components. The > current structures of the drafts introduce unnecessary dependencies > between them by focusing on the individual mip6 bootstrapping scenarios > rather than the actual purpose i.e. defining the Diameter (AAA) > components needed for both the mip6 bootstrapping solutions. Moreover, > the HA – HAAA interface can be defined in such a way that it covers mip6 > in general. > > > > So, the suggestion is to rename and re-scope the documents as follows: > > > > 1. Filename = dime-mip6-nas-aaa-interface: Title = The NAS - HAAA > interface for mip6 bootstrapping > > 2. Filename = dime-mip6-ha-aaa-interface: Title = The HA - HAAA > interface for mip6 > > Please let us know your comments. > > Regards, > > Kuntal > > "This email message and any attachments are confidential information of > Starent Networks, Corp. The information transmitted may not be used to > create or change any contractual obligations of Starent Networks, Corp. > Any review, retransmission, dissemination or other use of, or taking of > any action in reliance upon this e-mail and its attachments by persons > or entities other than the intended recipient is prohibited. If you are > not the intended recipient, please notify the sender immediately -- by > replying to this message or by sending an email to > postmaster@starentnetworks.com -- and destroy all copies of this message > and any attachments without reading or disclosing their contents. Thank > you." > > > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 21 03:06:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQIdp-0004uZ-B1; Thu, 21 Sep 2006 03:06:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQIdp-0004uU-4o for dime@ietf.org; Thu, 21 Sep 2006 03:06:37 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GQIdl-0004hx-MP for dime@ietf.org; Thu, 21 Sep 2006 03:06:37 -0400 Received: (qmail invoked by alias); 21 Sep 2006 07:06:32 -0000 Received: from ip-80-226-194-40.vodafone-net.de (EHLO [10.227.54.70]) [80.226.194.40] by mail.gmx.net (mp018) with SMTP; 21 Sep 2006 09:06:32 +0200 X-Authenticated: #29516787 Message-ID: <451239FD.7000801@gmx.net> Date: Thu, 21 Sep 2006 03:06:37 -0400 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: julien.bournelle@int-evry.fr Subject: Integration of QoS? AW: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part 2) Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.9 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Julien, Hi Yoshi, as part of the current charter we are working on two broad topics: mobility ad QoS How would I combine MIP6 bootstrapping with QoS when, for example, additional AVPs have to be returned to the NAS/HA in the Diameter-EAP-Answer together with mobility specific parameters? If I understood Yoshi right then he would define another Authorization/Accounting application for QoS and hence we would need three separate exchanges instead of one. Correct? How would we combine the QoS with DCC when real-time accounting? Ciao Hannes PS: Ideally we would like to avoid too many dependencies between the different Diameter document. For example, we don't want to modify a bootstrapping document when RFC 4072 is updated. We don't want to write a new document when we realize that it would be useful to have QoS, Mobility & Credit Control combined. > -----Ursprüngliche Nachricht----- > Von: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > Gesendet: Freitag, 15. September 2006 06:21 > An: dime@ietf.org > Betreff: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) > (polling part 2) > > Hi all, > > this is a new polling concerning the ha-aaah interface for the Mobile > IPv6 Boostrapping. To date, at the previous one, there was a > consensus on moving forward with a new App-ID. But, yoshi has > proposed an interesting idea that should be considered by the WG. > > As you may recall, in the ha-aaah case, the MN is authenticated by > EAP (IKEv2 is used between MN and the HA) and thus the HA-AAAH > interface must, at least, be able to carry EAP packets. It > appears that > we now have 2 options: > > (1) We define a new Diameter application for Mobile IPv6 with a new > App-ID that carry EAP packets as it is done in RFC 4072 (Diameter > EAP) but Authorization and Accouting is specific to Mobile IPv6 > (thus the need for a new App-ID). The risk, as noted by yoshi, is > that an update of the RFC4072 may result in an update of this > application. > > > (2) We define a new Diameter Application for Mobile IPv6 but which is > used for Authorization and Accounting. We continue to use > Diameter EAP fFrom dime-bounces@ietf.org Thu Sep 21 03:06:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQIdp-0004uZ-B1; Thu, 21 Sep 2006 03:06:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQIdp-0004uU-4o for dime@ietf.org; Thu, 21 Sep 2006 03:06:37 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GQIdl-0004hx-MP for dime@ietf.org; Thu, 21 Sep 2006 03:06:37 -0400 Received: (qmail invoked by alias); 21 Sep 2006 07:06:32 -0000 Received: from ip-80-226-194-40.vodafone-net.de (EHLO [10.227.54.70]) [80.226.194.40] by mail.gmx.net (mp018) with SMTP; 21 Sep 2006 09:06:32 +0200 X-Authenticated: #29516787 Message-ID: <451239FD.7000801@gmx.net> Date: Thu, 21 Sep 2006 03:06:37 -0400 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: julien.bournelle@int-evry.fr Subject: Integration of QoS? AW: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part 2) Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.9 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Julien, Hi Yoshi, as part of the current charter we are working on two broad topics: mobility ad QoS How would I combine MIP6 bootstrapping with QoS when, for example, additional AVPs have to be returned to the NAS/HA in the Diameter-EAP-Answer together with mobility specific parameters? If I understood Yoshi right then he would define another Authorization/Accounting application for QoS and hence we would need three separate exchanges instead of one. Correct? How would we combine the QoS with DCC when real-time accounting? Ciao Hannes PS: Ideally we would like to avoid too many dependencies between the different Diameter document. For example, we don't want to modify a bootstrapping document when RFC 4072 is updated. We don't want to write a new document when we realize that it would be useful to have QoS, Mobility & Credit Control combined. > -----Ursprüngliche Nachricht----- > Von: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > Gesendet: Freitag, 15. September 2006 06:21 > An: dime@ietf.org > Betreff: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) > (polling part 2) > > Hi all, > > this is a new polling concerning the ha-aaah interface for the Mobile > IPv6 Boostrapping. To date, at the previous one, there was a > consensus on moving forward with a new App-ID. But, yoshi has > proposed an interesting idea that should be considered by the WG. > > As you may recall, in the ha-aaah case, the MN is authenticated by > EAP (IKEv2 is used between MN and the HA) and thus the HA-AAAH > interface must, at least, be able to carry EAP packets. It > appears that > we now have 2 options: > > (1) We define a new Diameter application for Mobile IPv6 with a new > App-ID that carry EAP packets as it is done in RFC 4072 (Diameter > EAP) but Authorization and Accouting is specific to Mobile IPv6 > (thus the need for a new App-ID). The risk, as noted by yoshi, is > that an update of the RFC4072 may result in an update of this > application. > > > (2) We define a new Diameter Application for Mobile IPv6 but which is > used for Authorization and Accounting. We continue to use > Diameter EAP for the Authentication. Thus the HA will use > Diameter EAP with the AVP Auth-Request-Type set to > AUTHENTICATE_ONLY and then the HA will use this MIP6 Application > for Authorization/Accounting of the Mobile IPv6 service. This new > application will have its own App-ID. > > This would avoid to update the application if 4072 is updated and > this could be a way to proceed if other applications need EAP for > Authentication but have different needs for the Authorization and > Accounting part. > > Please indicate wether you prefer (1) or (2). > > As in the previous polling: > - it might be useful to state a reason for your decision. > - indicate wether some aspects are still unclear to you. > > Regards, > > Julien > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 21 03:06:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQIdm-0004uQ-6D; Thu, 21 Sep 2006 03:06:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQIdk-0004tL-Ct for dime@ietf.org; Thu, 21 Sep 2006 03:06:32 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GQIdf-0004hn-NU for dime@ietf.org; Thu, 21 Sep 2006 03:06:32 -0400 Received: (qmail invoked by alias); 21 Sep 2006 07:06:25 -0000 Received: from ip-80-226-194-40.vodafone-net.de (EHLO [10.227.54.70]) [80.226.194.40] by mail.gmx.net (mp045) with SMTP; 21 Sep 2006 09:06:25 +0200 X-Authenticated: #29516787 Message-ID: <451239F4.4010202@gmx.net> Date: Thu, 21 Sep 2006 03:06:28 -0400 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Chowdhury, Kuntal" Subject: Integrated Scenario: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type References: <7CCD07160348804497EF29E9EA5560D78372F8@exchtewks2.starentnetworks.com> In-Reply-To: <7CCD07160348804497EF29E9EA5560D78372F8@exchtewks2.starentnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Kuntal, we need to support this scenario given that it is part of the integrated scenario design. Regarding the capability mechanism: I recall the 1 year discussion in RADEXT when we made the proposal to provide a generic capability mechanism. I never saw it as a bad idea but others obviously had a different view about it. Ciao Hannes Chowdhury, Kuntal schrieb: > All, > > Here is a scenario that may need to be covered. In some cases, local HA > assignment is optimal for transport efficiency perspective. Diameter > MIP4 application allows this. In such a case the ASP == MSP and the HA > is assigned locally (in the visited network). > > To enable this case, in the integrated scenario, the NAS/VAAA needs to > indicate it's capability to assign an HA in the local network to the > HAAA. The HAAA may allow or disallow this local HA assignment based on > policy of the MSA. > > The NAS/VAAA may need to include a hint in the AAA message to the HAAA > at the timeor the Authentication. Thus the HA will use > Diameter EAP with the AVP Auth-Request-Type set to > AUTHENTICATE_ONLY and then the HA will use this MIP6 Application > for Authorization/Accounting of the Mobile IPv6 service. This new > application will have its own App-ID. > > This would avoid to update the application if 4072 is updated and > this could be a way to proceed if other applications need EAP for > Authentication but have different needs for the Authorization and > Accounting part. > > Please indicate wether you prefer (1) or (2). > > As in the previous polling: > - it might be useful to state a reason for your decision. > - indicate wether some aspects are still unclear to you. > > Regards, > > Julien > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 21 03:06:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQIdm-0004uQ-6D; Thu, 21 Sep 2006 03:06:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQIdk-0004tL-Ct for dime@ietf.org; Thu, 21 Sep 2006 03:06:32 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GQIdf-0004hn-NU for dime@ietf.org; Thu, 21 Sep 2006 03:06:32 -0400 Received: (qmail invoked by alias); 21 Sep 2006 07:06:25 -0000 Received: from ip-80-226-194-40.vodafone-net.de (EHLO [10.227.54.70]) [80.226.194.40] by mail.gmx.net (mp045) with SMTP; 21 Sep 2006 09:06:25 +0200 X-Authenticated: #29516787 Message-ID: <451239F4.4010202@gmx.net> Date: Thu, 21 Sep 2006 03:06:28 -0400 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Chowdhury, Kuntal" Subject: Integrated Scenario: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type References: <7CCD07160348804497EF29E9EA5560D78372F8@exchtewks2.starentnetworks.com> In-Reply-To: <7CCD07160348804497EF29E9EA5560D78372F8@exchtewks2.starentnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Kuntal, we need to support this scenario given that it is part of the integrated scenario design. Regarding the capability mechanism: I recall the 1 year discussion in RADEXT when we made the proposal to provide a generic capability mechanism. I never saw it as a bad idea but others obviously had a different view about it. Ciao Hannes Chowdhury, Kuntal schrieb: > All, > > Here is a scenario that may need to be covered. In some cases, local HA > assignment is optimal for transport efficiency perspective. Diameter > MIP4 application allows this. In such a case the ASP == MSP and the HA > is assigned locally (in the visited network). > > To enable this case, in the integrated scenario, the NAS/VAAA needs to > indicate it's capability to assign an HA in the local network to the > HAAA. The HAAA may allow or disallow this local HA assignment based on > policy of the MSA. > > The NAS/VAAA may need to include a hint in the AAA message to the HAAA > at the time of access authentication that it is capable of providing an > HA to the MN. This capability indication (hint) can be either sent via a > new MIP6 specific AVP or it can be conveyed via an existing AVP (I don't > know if one exists). > > If we decide to include this (local HA assignment), and we decide to > include this mip6 specific hint in the NAS-HAAA communication, we may > have to choose the most appropriate option (1) vs. (2). > > Comments? > > -Kuntal > > >> -----Original Message----- >> From: Avi Lior [mailto:avi@bridgewatersystems.com] >> Sent: Tuesday, September 05, 2006 6:07 AM >> To: Gerardo Giaretta; Hannes.Tschofenig@gmx.net >> Cc: dime@ietf.org >> Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > Service-Type >> I must be missing something. >> >> In the integrated scenario, what would the NAS put in Service-Type? >> >> I think in the integrated scenario neither Port-Type or Service-Type >> needs to be touched. >> >> As far as I understand the NAS is either executing EAP Application or >> NAS REQ. It does not know whether the user will result in having >> subsequent Mobile IP service or not. >> >> The only thing the AAA server can do is to send the MIPv6 attributes > as >> optional (M bit off) and hope that if the NAS does not understand the >> attributes it would have some logic to bootstrap a different way. >> >> We could improve the situration somewhat. We could have the NAS >> indicate that it supports MIPv6 bootstrapping by including hints in > the >> AR (a capability hint). Where the NAS includes HA-IP address AVP > both >> indicating that it can support bootstrapping and if the HA-IP address > is >> not ALL-ZEROS or ALL ONES it provides a hint that it can support > dynamic >> HA assignement. >> >> Ofcourse we could introduce the concept of capability hints more >> formally in Diameter -- This is missing today. >> >> >> >> >> >>> -----Original Message----- >>> From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] >>> Sent: Tuesday, September 05, 2006 3:35 AM >>> To: Hannes.Tschofenig@gmx.net >>> Cc: dime@ietf.org >>> Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. >>> Service-Type >>> >>> Hi Hannes, >>> >>> I agree with Jouni. I prefer (2) for NAS-AAAH and (1) for >>> AAAH-HA. In my understanding, there are no mandatory AVPs for >>> NAS-AAAH and therefore I don't see a need of a new >>> application; it's just a MIP-specific information that is >>> piggybacked in the network access authentication procedure. >>> >>> Concerning AAAH-HA, I think it is a much cleaner approach to >>> define a new application, since it does not anything to do >>> with network authentication. >>> >>> --Gerardo >>> >>> On 9/5/06, jouni.korhonen@teliasonera.com >>> wrote: >>>> Hi HAnnes, >>>> >>>>> -----Original Message----- >>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>> Sent: 1. syyskuuta 2006 1:07 >>>>> To: dime@ietf.org >>>>> Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. >>>>> Service-Type >>>>> >>>>> Hi all, >>>>> >>>>> we have had long discussions about the App-ID vs. >>>>> Service-Type usage for >>>>> Diameter MIPv6 Bootstrapping. >>>>> >>>>> It is time to see what the group thinks. Please indicate >>> whether you >>>>> prefer (1) an App-ID or (2) a Service-Type solution for >>>>> >>>>> (a) NAS-to-AAAH communication (as required by the integrated >>>>> scenario; as one part of the solution component) >>>> I would prefer (2) for now.. or as long as the NAS-2-AAAH main >>>> function is to provide access authentication, where the backend > AAA >>>> may return >>>> MIP6 >>>> bootstrapping info (as an enhancement) based e.g. on the user >>>> subscription profile. If we go for more stuff on NAS-2-AAAH like >>>> HoA/prefix etc then >>>> (1) >>>> might be better. >>>> >>>>> (b) HA-to-AAAH communication (as used by the split >>> scenario and the >>>>> integrated scenario) >>>> I would prefer (1) here. The use of EAP for MIP6 bootstrapping >>>> purposes and for 'normal' EAP-based access authentication are >>>> different appli of access authentication that it is capable of providing an > HA to the MN. This capability indication (hint) can be either sent via a > new MIP6 specific AVP or it can be conveyed via an existing AVP (I don't > know if one exists). > > If we decide to include this (local HA assignment), and we decide to > include this mip6 specific hint in the NAS-HAAA communication, we may > have to choose the most appropriate option (1) vs. (2). > > Comments? > > -Kuntal > > >> -----Original Message----- >> From: Avi Lior [mailto:avi@bridgewatersystems.com] >> Sent: Tuesday, September 05, 2006 6:07 AM >> To: Gerardo Giaretta; Hannes.Tschofenig@gmx.net >> Cc: dime@ietf.org >> Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. > Service-Type >> I must be missing something. >> >> In the integrated scenario, what would the NAS put in Service-Type? >> >> I think in the integrated scenario neither Port-Type or Service-Type >> needs to be touched. >> >> As far as I understand the NAS is either executing EAP Application or >> NAS REQ. It does not know whether the user will result in having >> subsequent Mobile IP service or not. >> >> The only thing the AAA server can do is to send the MIPv6 attributes > as >> optional (M bit off) and hope that if the NAS does not understand the >> attributes it would have some logic to bootstrap a different way. >> >> We could improve the situration somewhat. We could have the NAS >> indicate that it supports MIPv6 bootstrapping by including hints in > the >> AR (a capability hint). Where the NAS includes HA-IP address AVP > both >> indicating that it can support bootstrapping and if the HA-IP address > is >> not ALL-ZEROS or ALL ONES it provides a hint that it can support > dynamic >> HA assignement. >> >> Ofcourse we could introduce the concept of capability hints more >> formally in Diameter -- This is missing today. >> >> >> >> >> >>> -----Original Message----- >>> From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] >>> Sent: Tuesday, September 05, 2006 3:35 AM >>> To: Hannes.Tschofenig@gmx.net >>> Cc: dime@ietf.org >>> Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. >>> Service-Type >>> >>> Hi Hannes, >>> >>> I agree with Jouni. I prefer (2) for NAS-AAAH and (1) for >>> AAAH-HA. In my understanding, there are no mandatory AVPs for >>> NAS-AAAH and therefore I don't see a need of a new >>> application; it's just a MIP-specific information that is >>> piggybacked in the network access authentication procedure. >>> >>> Concerning AAAH-HA, I think it is a much cleaner approach to >>> define a new application, since it does not anything to do >>> with network authentication. >>> >>> --Gerardo >>> >>> On 9/5/06, jouni.korhonen@teliasonera.com >>> wrote: >>>> Hi HAnnes, >>>> >>>>> -----Original Message----- >>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>> Sent: 1. syyskuuta 2006 1:07 >>>>> To: dime@ietf.org >>>>> Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. >>>>> Service-Type >>>>> >>>>> Hi all, >>>>> >>>>> we have had long discussions about the App-ID vs. >>>>> Service-Type usage for >>>>> Diameter MIPv6 Bootstrapping. >>>>> >>>>> It is time to see what the group thinks. Please indicate >>> whether you >>>>> prefer (1) an App-ID or (2) a Service-Type solution for >>>>> >>>>> (a) NAS-to-AAAH communication (as required by the integrated >>>>> scenario; as one part of the solution component) >>>> I would prefer (2) for now.. or as long as the NAS-2-AAAH main >>>> function is to provide access authentication, where the backend > AAA >>>> may return >>>> MIP6 >>>> bootstrapping info (as an enhancement) based e.g. on the user >>>> subscription profile. If we go for more stuff on NAS-2-AAAH like >>>> HoA/prefix etc then >>>> (1) >>>> might be better. >>>> >>>>> (b) HA-to-AAAH communication (as used by the split >>> scenario and the >>>>> integrated scenario) >>>> I would prefer (1) here. The use of EAP for MIP6 bootstrapping >>>> purposes and for 'normal' EAP-based access authentication are >>>> different applications imho. (although in IKEv2 vs 802.1X case > e.g. >>>> NAS-Port-Type could be used to make this distinction.. e.g. >>> how 3GPP >>>> WLAN stuff does it) >>>> >>>>> It might be useful to state a reason for your decision. >>>>> >>>>> Please also indicate whether some aspects are still >>> unclear to you. >>>>> Ciao >>>>> Hannes >>>> Cheers, >>>> Jouni >>>> >>>> >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/dime >>>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/dime >>>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime > > > "This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster@starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you." > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime cations imho. (although in IKEv2 vs 802.1X case > e.g. >>>> NAS-Port-Type could be used to make this distinction.. e.g. >>> how 3GPP >>>> WLAN stuff does it) >>>> >>>>> It might be useful to state a reason for your decision. >>>>> >>>>> Please also indicate whether some aspects are still >>> unclear to you. >>>>> Ciao >>>>> Hannes >>>> Cheers, >>>> Jouni >>>> >>>> >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/dime >>>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/dime >>>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime > > > "This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster@starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you." > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 21 03:06:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQIe1-00054L-Fl; Thu, 21 Sep 2006 03:06:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQIdz-0004yy-KD for dime@ietf.org; Thu, 21 Sep 2006 03:06:47 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GQIdv-0004iG-5D for dime@ietf.org; Thu, 21 Sep 2006 03:06:47 -0400 Received: (qmail invoked by alias); 21 Sep 2006 07:06:41 -0000 Received: from ip-80-226-194-40.vodafone-net.de (EHLO [10.227.54.70]) [80.226.194.40] by mail.gmx.net (mp035) with SMTP; 21 Sep 2006 09:06:41 +0200 X-Authenticated: #29516787 Message-ID: <45123A06.1010106@gmx.net> Date: Thu, 21 Sep 2006 03:06:46 -0400 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Yoshihiro Ohba Subject: Efficiency: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type References: <44F75D9B.6030808@gmx.net> <20060908141021.GD23183@steelhead> In-Reply-To: <20060908141021.GD23183@steelhead> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Yoshi, the drawback is that this approach is less efficient. If we see this in relationship with RADIUS I already see people saying that the Diameter approach is a performance hit. Still, I think it is worth investigating in the current document. Ciao Hannes Yoshihiro Ohba schrieb: > I forgot to explicitly answer to this question. > > My answer is (1) for both (a) and (b), but define MIP6 application as > a totally separate authprization application from EAP and NASREQ (For > more details and reasons, please see related discussion with Julien). > > Regards, > Yoshihiro Ohba > > > > On Fri, Sep 01, 2006 at 12:07:23AM +0200, Hannes Tschofenig wrote: >> Hi all, >> >> we have had long discussions about the App-ID vs. Service-Type usage for >> Diameter MIPv6 Bootstrapping. >> >> It is time to see what the group thinks. Please indicate whether you >> prefer (1) an App-ID or (2) a Service-Type solution for >> >> (a) NAS-to-AAAH communication (as required by the integrated scenario; >> as one part of the solution component) >> >> (b) HA-to-AAAH communication (as used by the split scenario and the >> integrated scenario) >> >> It might be useful to state a reason for your decision. >> >> Please also indicate whether some aspects are still unclear to you. >> >> Ciao >> Hannes >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 21 03:06:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQIe6-00058B-Ti; Thu, 21 Sep 2006 03:06:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQIe5-000586-Du for dime@ietf.org; Thu, 21 Sep 2006 03:06:53 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GQIe0-0004iU-VF for dime@ietf.org; Thu, 21 Sep 2006 03:06:53 -0400 Received: (qmail invoked by alias); 21 Sep 2006 07:06:47 -0000 Received: from ip-80-226-194-40.vodafone-net.de (EHLO [10.227.54.70]) [80.226.194.40] by mail.gmx.net (mp041) with SMTP; 21 Sep 2006 09:06:47 +0200 X-Authenticated: #29516787 Message-ID: <45123A0C.2090105@gmx.net> Date: Thu, 21 Sep 2006 03:06:52 -0400 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Yoshihiro Ohba Subject: Design Decisions for RFC 4072: Re: [Dime] Re: Using Diameter EAP --only-- for Authentication ? References: <7CCD07160348804497EF29E9EA5560D78372F8@exchtewks2.starentnetworks.com> <20060906181643.GE5241@steelhead> <20060907152211.GA27475@ipv6-3.int-evry.fr> <20060907203328.GB18410@steelhead> <20060912121400.GA2527@ipv6-3.int-evry.fr> <20060912155310.GF2857@steelhead> In-Reply-To: <20060912155310.GF2857@steelhead> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Yoshi, ~snip~ > A AAA server that receives DER does not need to know whether > additional authorization is needed as long as HA knows about it as > I mentioned in http://www1.ietf.org/mail-archive/web/dime/current/msg00726.html. > > However, if the AAA server somehow needs to know about it, the HA(NAS) > can indicate it by including Auth-Request-Type AVP in DER with > specifying "AUTHENTICATE_ONLY". > >> If we "push" a little what you propose, we could define an >> "Authentication based on EAP" Application (only doing Authentication) >> used by other Application that would only define their messages for >> Authorization and Accounting (such as MIP6). That's why I talked to you >> in a previous mail about also consider network access as a special >> service and thus define Authz/Accounting messages for the "network >> access" service. > > Yes, in the case of network access, you could use NASREQ for > authorization purpose in additon to Diameter EAP for authentication > purpose as specified in RFC 4072. I wonder why the Diameter EAP authors have decided not to use this approach. It would be interesting to learn something about their design decisions. > > Regards, > Yoshihiro Ohba Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 21 03:06:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQIeB-0005B9-96; Thu, 21 Sep 2006 03:06:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQIe9-0005A4-HN for dime@ietf.org; Thu, 21 Sep 2006 03:06:57 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GQIe5-0004iZ-34 for dime@ietf.org; Thu, 21 Sep 2006 03:06:57 -0400 Received: (qmail invoked by alias); 21 Sep 2006 07:06:51 -0000 Received: from ip-80-226-194-40.vodafone-net.de (EHLO [10.227.54.70]) [80.226.194.40] by mail.gmx.net (mp031) with SMTP; 21 Sep 2006 09:06:51 +0200 X-Authenticated: #29516787 Message-ID: <45123A0F.2070606@gmx.net> Date: Thu, 21 Sep 2006 03:06:55 -0400 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Glen Zorn (gwz)" Subject: Accounting: Re: [Dime] Diameter MIP References: <4C0FAAC489C8B74F96BEAD85EAEB26250295B0E6@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB26250295B0E6@xmb-sjc-215.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Glen, in what sense do you think accounting is going to be different? Ciao Hannes Glen Zorn (gwz) schrieb: > One reason that I don't think has been mentioned yet for defining new > App IDs for both flavors of MIP is that accounting for MIP is likely to > be defined differently than that for generic network access (i.e. NASREQ > or EAP). > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 21 03:07:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQIeH-0005Yl-EZ; Thu, 21 Sep 2006 03:07:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQIeF-0005QL-RL for dime@ietf.org; Thu, 21 Sep 2006 03:07:03 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GQIeA-0004ir-Sg for dime@ietf.org; Thu, 21 Sep 2006 03:07:03 -0400 Received: (qmail invoked by alias); 21 Sep 2006 07:06:55 -0000 Received: from ip-80-226-194-40.vodafone-net.de (EHLO [10.227.54.70]) [80.226.194.40] by mail.gmx.net (mp028) with SMTP; 21 Sep 2006 09:06:55 +0200 X-Authenticated: #29516787 Message-ID: <45123A14.9060807@gmx.net> Date: Thu, 21 Sep 2006 03:07:00 -0400 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Yoshihiro Ohba Subject: Re: [Dime] Re: Authentication through 2 different "NAS" in the same time ? References: <7CCD07160348804497EF29E9EA5560D78372F8@exchtewks2.starentnetworks.com> <20060906181643.GE5241@steelhead> <20060907152211.GA27475@ipv6-3.int-evry.fr> <20060907203328.GB18410@steelhead> <20060912121400.GA2527@ipv6-3.int-evry.fr> <20060912155310.GF2857@steelhead> <20060913085255.GA4025@ipv6-3.int-evry.fr> <20060913134306.GC15246@steelhead> <20060915093034.GA6298@ipv6-3.int-evry.fr> <20060915095651.GE30516@steelhead> In-Reply-To: <20060915095651.GE30516@steelhead> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd000eda3d43531d5b01b5d305410e3c Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Yoshi, ~snip~ > BTW, I have two questions. > > - Do the EAP via NAS and the EAP via HA need to hit the same AAAH > server? I guess not. There is no requirement to use the same server but in reality it is most likely the same server. > > - Do the EAP via NAS and the EAP via HA need to use the same Idenity? > I guess not. There is no requirement to use the identity for network access and for MIP6 bootstrapping but in reality it is most likely the same for operational and cost reasons. (With some of the work done in Wimax there are pseudonyms being used but that's another story.) Ciao Hannes > > Regards, > Yoshihiro Ohba > > >> Any comments on this ? >> >> regards, >> >> Julien >> >> >> On Wed, Sep 13, 2006 at 09:43:06AM -0400, Yoshihiro Ohba wrote: >>> Hi Julien, >>> >>> On Wed, Sep 13, 2006 at 10:52:55AM +0200, Julien Bournelle wrote: >>> >>> (snip) >>> >>>>> However, if the AAA server somehow needs to know about it, the HA(NAS) >>>>> can indicate it by including Auth-Request-Type AVP in DER with >>>>> specifying "AUTHENTICATE_ONLY". >>>> ok. I see. I forgot this possibility. >>>> So to sump up, the HA will use Diameter EAP with the Auth-Request-Type >>>> aVP set to AUTHENTICATE_ONLY and the App-ID set to 5. If it receives a >>>> success, it will switch to a Authorization/Accounting MIP6 Application >>>> with a new App-ID. Is that right ? >>>> >>>> I think it can work but we need to investigate a little more before >>>> moving with this. Points that I can see for now are: >>>> >>>> - The session-id must be shared between the Application. >>> Why session-id must be shared? >>> >>> NASREQ usage for authorization purpose in RFC 4072 does not require >>> it. Instead, User-Name AVP can be shared between the applications. >>> In case the NAS(HA) is not able to retrieve the username from EAP >>> messages, the AAA server can tell the NAS about the username by >>> carrying User-Name AVP in DEA message, as described in RFC 4072. >>> >>>> - We must be sure that messages will reach the same AAA server. >>> Why Diameter EAP messages and Diameter MIP6 messages need to hit the >>> same AAA server? >>> >>> Again, NASREQ usage for authorization purpse in RFC 4072 does not >>> require NASREQ and Diameter EAP messages to use the same AAA server. >>> In general, authentication, authorization and accouting can use >>> different AAA servers, and there should be no exception to MIP6 >>> bootstrapping, IMO. >>> >>>> - We may have trouble with RADIUS compatibility >>> This can be handled later. >>> >>> Yoshihiro Ohba >>> >>> >>>> >>>> Anyone has an opinion on this way to solve our issue ? >>>> >>>> Thanks yoshi, >>>> >>>> Julien >>>> >>>>>> If we "push" a little what you propose, we could define an >>>>>> "Authentication based on EAP" Application (only doing Authentication) >>>>>> used by other Application that would only define their messages for >>>>>> Authorization and Accounting (such as MIP6). That's why I talked to you >>>>>> in a previous mail about also consider network access as a special >>>>>> service and thus define Authz/Accounting messages for the "network >>>>>> access" service. >>>>> Yes, in the case of network access, you could use NASREQ for >>>>> authorization purpose in additon to Diameter EAP for authentication >>>>> purpose as specified in RFC 4072. >>>>> >>>>> Regards, >>>>> Yoshihiro Ohba >>>>> >>>>> >>>>>> regards, >>>>>> >>>>>> Julien >>>>>> >>>>>>> Regards, >>>>>>> Yoshihiro Ohba >>>>>>> >>>>>>>>> I also agree with Avi that defining a new application for MIP6 >>>>>>>>> bootstrapping on top of existing applications (Diameter EAP) without >>>>>>>>> defining a new application id but with defining new values for >>>>>>>>> existing AVPs or new optional AVPs has some issue, but this option >>>>>>>>> might not be as bad as the first option since backward compatibility >>>>>>>>> can be easily maintained unlike the first option. However, there is a >>>>>>>>> forward compatibility problem (i.e., a Diameter message may be forwarded >>>>>>>>> to a AAA server that does not support the new application). Besides >>>>>>>>> this problem, it might be worth pursuing this option because it works >>>>>>>>> in an optimized way (i.e., bootstrapping AVPs are piggybacked in >>>>>>>>> Diameter EAP or NASREQ message) as long as both NAS and AAA server >>>>>>>>> support the AVPs. >>>>>>>> I'm not in favor of having an app-id for the nas-aaah part of the mip6 >>>>>>>> bootstrapping problem. >>>>>>>> >>>>>>>>> In order to deal with the forward compatibility problem of the second >>>>>>>>> option, a third option is to define a new application for MIP6 >>>>>>>>> bootstrapping as a totally new authorization application that carries >>>>>>>>> new mandatory AVPs specific to that application. This option can be >>>>>>>>> run when execution of the second option succeeds in authentication but >>>>>>>>> fails in carrying bootstrapping AVPs. >>>>>>>> hmm, i guess i have to think more of this option but this would mandate >>>>>>>> now that all EAP Application server should know that maybe they are not >>>>>>>> doing this for network access and that maybe they are going to receive >>>>>>>> a special authorization request. And in this case, wouldn't it mean >>>>>>>> that network access should be treated as a special service and this >>>>>>>> would also require a new authorization application ? >>>>>>>> >>>>>>>> regards, >>>>>>>> >>>>>>>> Julien >>>>>>>>> Regards, >>>>>>>>> Yoshihiro Ohba >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Sep 05, 2006 at 11:21:22PM -0400, Avi Lior wrote: >>>>>>>>>> Hi Kuntal, >>>>>>>>>> >>>>>>>>>> Neither option 1 or option 2 will work. A new application id just wont >>>>>>>>>> scale in the long run. What if another 'capability' were to be added >>>>>>>>>> for instance prepaid. Since Diameter messages contain only one >>>>>>>>>> Application ID, you would have to create an Application Id that covered >>>>>>>>>> both EAP, Prepaid and Mobile IP. And what if a third application were >>>>>>>>>> added? The approach is not scalable as the applications are increased >>>>>>>>>> -- you would have to cope with all the different permutations of >>>>>>>>>> Applications. The same argument goes for ServiceType and PortType and >>>>>>>>>> these are actually more problematic. >>>>>>>>>> >>>>>>>>>> IMO the only thing we can do is to hint at the capability of the NAS. >>>>>>>>>> >>>>>>>>>> A proper solution should be concieved for this problem. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] >>>>>>>>>>> Sent: Tuesday, September 05, 2006 2:09 PM >>>>>>>>>>> To: Avi Lior; Gerardo Giaretta; Hannes.Tschofenig@gmx.net >>>>>>>>>>> Cc: dime@ietf.org >>>>>>>>>>> Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. >>>>>>>>>>> Service-Type >>>>>>>>>>> >>>>>>>>>>> All, >>>>>>>>>>> >>>>>>>>>>> Here is a scenario that may need to be covered. In some >>>>>>>>>>> cases, local HA assignment is optimal for transport >>>>>>>>>>> efficiency perspective. Diameter >>>>>>>>>>> MIP4 application allows this. In such a case the ASP == MSP >>>>>>>>>>> and the HA is assigned locally (in the visited network). >>>>>>>>>>> >>>>>>>>>>> To enable this case, in the integrated scenario, the NAS/VAAA >>>>>>>>>>> needs to indicate it's capability to assign an HA in the >>>>>>>>>>> local network to the HAAA. The HAAA may allow or disallow >>>>>>>>>>> this local HA assignment based on policy of the MSA. >>>>>>>>>>> >>>>>>>>>>> The NAS/VAAA may need to include a hint in the AAA message to >>>>>>>>>>> the HAAA at the time of access authentication that it is >>>>>>>>>>> capable of providing an HA to the MN. This capability >>>>>>>>>>> indication (hint) can be either sent via a new MIP6 specific >>>>>>>>>>> AVP or it can be conveyed via an existing AVP (I don't know >>>>>>>>>>> if one exists). >>>>>>>>>>> >>>>>>>>>>> If we decide to include this (local HA assignment), and we >>>>>>>>>>> decide to include this mip6 specific hint in the NAS-HAAA >>>>>>>>>>> communication, we may have to choose the most appropriate >>>>>>>>>>> option (1) vs. (2). >>>>>>>>>>> >>>>>>>>>>> Comments? >>>>>>>>>>> >>>>>>>>>>> -Kuntal >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Avi Lior [mailto:avi@bridgewatersystems.com] >>>>>>>>>>>> Sent: Tuesday, September 05, 2006 6:07 AM >>>>>>>>>>>> To: Gerardo Giaretta; Hannes.Tschofenig@gmx.net >>>>>>>>>>>> Cc: dime@ietf.org >>>>>>>>>>>> Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. >>>>>>>>>>> Service-Type >>>>>>>>>>>> I must be missing something. >>>>>>>>>>>> >>>>>>>>>>>> In the integrated scenario, what would the NAS put in Service-Type? >>>>>>>>>>>> >>>>>>>>>>>> I think in the integrated scenario neither Port-Type or >>>>>>>>>>> Service-Type >>>>>>>>>>>> needs to be touched. >>>>>>>>>>>> >>>>>>>>>>>> As far as I understand the NAS is either executing EAP >>>>>>>>>>> Application or >>>>>>>>>>>> NAS REQ. It does not know whether the user will result in having >>>>>>>>>>>> subsequent Mobile IP service or not. >>>>>>>>>>>> >>>>>>>>>>>> The only thing the AAA server can do is to send the MIPv6 attributes >>>>>>>>>>> as >>>>>>>>>>>> optional (M bit off) and hope that if the NAS does not >>>>>>>>>>> understand the >>>>>>>>>>>> attributes it would have some logic to bootstrap a different way. >>>>>>>>>>>> >>>>>>>>>>>> We could improve the situration somewhat. We could have the NAS >>>>>>>>>>>> indicate that it supports MIPv6 bootstrapping by including hints in >>>>>>>>>>> the >>>>>>>>>>>> AR (a capability hint). Where the NAS includes HA-IP address AVP >>>>>>>>>>> both >>>>>>>>>>>> indicating that it can support bootstrapping and if the >>>>>>>>>>> HA-IP address >>>>>>>>>>> is >>>>>>>>>>>> not ALL-ZEROS or ALL ONES it provides a hint that it can support >>>>>>>>>>> dynamic >>>>>>>>>>>> HA assignement. >>>>>>>>>>>> >>>>>>>>>>>> Ofcourse we could introduce the concept of capability hints more >>>>>>>>>>>> formally in Diameter -- This is missing today. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] >>>>>>>>>>>>> Sent: Tuesday, September 05, 2006 3:35 AM >>>>>>>>>>>>> To: Hannes.Tschofenig@gmx.net >>>>>>>>>>>>> Cc: dime@ietf.org >>>>>>>>>>>>> Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. >>>>>>>>>>>>> Service-Type >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Hannes, >>>>>>>>>>>>> >>>>>>>>>>>>> I agree with Jouni. I prefer (2) for NAS-AAAH and (1) for >>>>>>>>>>> AAAH-HA. >>>>>>>>>>>>> In my understanding, there are no mandatory AVPs for NAS-AAAH and >>>>>>>>>>>>> therefore I don't see a need of a new application; it's just a >>>>>>>>>>>>> MIP-specific information that is piggybacked in the >>>>>>>>>>> network access >>>>>>>>>>>>> authentication procedure. >>>>>>>>>>>>> >>>>>>>>>>>>> Concerning AAAH-HA, I think it is a much cleaner approach >>>>>>>>>>> to define >>>>>>>>>>>>> a new application, since it does not anything to do with network >>>>>>>>>>>>> authentication. >>>>>>>>>>>>> >>>>>>>>>>>>> --Gerardo >>>>>>>>>>>>> >>>>>>>>>>>>> On 9/5/06, jouni.korhonen@teliasonera.com >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> Hi HAnnes, >>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>>>>>>>>>> Sent: 1. syyskuuta 2006 1:07 >>>>>>>>>>>>>>> To: dime@ietf.org >>>>>>>>>>>>>>> Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. >>>>>>>>>>>>>>> Service-Type >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> we have had long discussions about the App-ID vs. >>>>>>>>>>>>>>> Service-Type usage for >>>>>>>>>>>>>>> Diameter MIPv6 Bootstrapping. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It is time to see what the group thinks. Please indicate >>>>>>>>>>>>> whether you >>>>>>>>>>>>>>> prefer (1) an App-ID or (2) a Service-Type solution for >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> (a) NAS-to-AAAH communication (as required by the integrated >>>>>>>>>>>>>>> scenario; as one part of the solution component) >>>>>>>>>>>>>> I would prefer (2) for now.. or as long as the NAS-2-AAAH main >>>>>>>>>>>>>> function is to provide access authentication, where the backend >>>>>>>>>>> AAA >>>>>>>>>>>>>> may return >>>>>>>>>>>>>> MIP6 >>>>>>>>>>>>>> bootstrapping info (as an enhancement) based e.g. on the user >>>>>>>>>>>>>> subscription profile. If we go for more stuff on >>>>>>>>>>> NAS-2-AAAH like >>>>>>>>>>>>>> HoA/prefix etc then >>>>>>>>>>>>>> (1) >>>>>>>>>>>>>> might be better. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> (b) HA-to-AAAH communication (as used by the split >>>>>>>>>>>>> scenario and the >>>>>>>>>>>>>>> integrated scenario) >>>>>>>>>>>>>> I would prefer (1) here. The use of EAP for MIP6 bootstrapping >>>>>>>>>>>>>> purposes and for 'normal' EAP-based access authentication are >>>>>>>>>>>>>> different applications imho. (although in IKEv2 vs 802.1X case >>>>>>>>>>> e.g. >>>>>>>>>>>>>> NAS-Port-Type could be used to make this distinction.. e.g. >>>>>>>>>>>>> how 3GPP >>>>>>>>>>>>>> WLAN stuff does it) >>>>>>>>>>>>>> >>>>>>>>>>>>>>> It might be useful to state a reason for your decision. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please also indicate whether some aspects are still >>>>>>>>>>>>> unclear to you. >>>>>>>>>>>>>>> Ciao >>>>>>>>>>>>>>> Hannes >>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>> Jouni >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> DiME mailing list >>>>>>>>>>>>>>> DiME@ietf.org >>>>>>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/dime >>>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> DiME mailing list >>>>>>>>>>>>>> DiME@ietf.org >>>>>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/dime >>>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> DiME mailing list >>>>>>>>>>>>> DiME@ietf.org >>>>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/dime >>>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> DiME mailing list >>>>>>>>>>>> DiME@ietf.org >>>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/dime >>>>>>>>>>> >>>>>>>>>>> "This email message and any attachments are confidential >>>>>>>>>>> information of Starent Networks, Corp. The information >>>>>>>>>>> transmitted may not be used to create or change any >>>>>>>>>>> contractual obligations of Starent Networks, Corp. Any >>>>>>>>>>> review, retransmission, dissemination or other use of, or >>>>>>>>>>> taking of any action in reliance upon this e-mail and its >>>>>>>>>>> attachments by persons or entities other than the intended >>>>>>>>>>> recipient is prohibited. If you are not the intended >>>>>>>>>>> recipient, please notify the sender immediately -- by >>>>>>>>>>> replying to this message or by sending an email to >>>>>>>>>>> postmaster@starentnetworks.com -- and destroy all copies of >>>>>>>>>>> this message and any attachments without reading or >>>>>>>>>>> disclosing their contents. Thank you." >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> DiME mailing list >>>>>>>>>> DiME@ietf.org >>>>>>>>>> https://www1.ietf.org/mailman/listinfo/dime >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> DiME mailing list >>>>>>>>> DiME@ietf.org >>>>>>>>> https://www1.ietf.org/mailman/listinfo/dime >>>>>>>> -- >>>>>>>> julien.bournelle at int-evry.fr >>>>>>>> >>>>>> -- >>>>>> julien.bournelle at int-evry.fr >>>>>> >>>> -- >>>> julien.bournelle at int-evry.fr >>>> >> -- >> julien.bournelle at int-evry.fr >> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 21 03:07:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQIeM-0005i4-Kd; Thu, 21 Sep 2006 03:07:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQIeK-0005hy-Tb for dime@ietf.org; Thu, 21 Sep 2006 03:07:08 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GQIeF-0004j3-SY for dime@ietf.org; Thu, 21 Sep 2006 03:07:08 -0400 Received: (qmail invoked by alias); 21 Sep 2006 07:07:01 -0000 Received: from ip-80-226-194-40.vodafone-net.de (EHLO [10.227.54.70]) [80.226.194.40] by mail.gmx.net (mp009) with SMTP; 21 Sep 2006 09:07:01 +0200 X-Authenticated: #29516787 Message-ID: <45123A19.8050504@gmx.net> Date: Thu, 21 Sep 2006 03:07:05 -0400 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Yoshihiro Ohba Subject: Yoshi's Proposal: Re: [Dime] Re: Using Diameter EAP --only-- for Authentication ? References: <7CCD07160348804497EF29E9EA5560D78372F8@exchtewks2.starentnetworks.com> <20060906181643.GE5241@steelhead> <20060907152211.GA27475@ipv6-3.int-evry.fr> <20060907203328.GB18410@steelhead> <20060912121400.GA2527@ipv6-3.int-evry.fr> <20060912155310.GF2857@steelhead> <20060913085255.GA4025@ipv6-3.int-evry.fr> <20060913134306.GC15246@steelhead> In-Reply-To: <20060913134306.GC15246@steelhead> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: bdfdd9dd835c9bb499f7c92933fef080 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Yoshi, Yoshihiro Ohba schrieb: > Hi Julien, > > On Wed, Sep 13, 2006 at 10:52:55AM +0200, Julien Bournelle wrote: > > (snip) > >>> However, if the AAA server somehow needs to know about it, the HA(NAS) >>> can indicate it by including Auth-Request-Type AVP in DER with >>> specifying "AUTHENTICATE_ONLY". >> ok. I see. I forgot this possibility. >> So to sump up, the HA will use Diameter EAP with the Auth-Request-Type >> aVP set to AUTHENTICATE_ONLY and the App-ID set to 5. If it receives a >> success, it will switch to a Authorization/Accounting MIP6 Application >> with a new App-ID. Is that right ? >> >> I think it can work but we need to investigate a little more before >> moving with this. Points that I can see for now are: >> >> - The session-id must be shared between the Application. > > Why session-id must be shared? > > NASREQ usage for authorization purpose in RFC 4072 does not require > it. Instead, User-Name AVP can be shared between the applications. > In case the NAS(HA) is not able to retrieve the username from EAP > messages, the AAA server can tell the NAS about the username by > carrying User-Name AVP in DEA message, as described in RFC 4072. To carry the User-Name AVP in the DEA message partially destroys the benefit of user identity confidentiality in the EAP. This is a really bad approach. > >> - We must be sure that messages will reach the same AAA server. > > Why Diameter EAP messages and Diameter MIP6 messages need to hit the > same AAA server? > > Again, NASREQ usage for authorization purpse in RFC 4072 does not > require NASREQ and Diameter EAP messages to use the same AAA server. > In general, authentication, authorization and accouting can use > different AAA servers, and there should be no exception to MIP6 > bootstrapping, IMO. I agree that it is not necessary to hit the same AAA server. In reality you have to access the same database in the background because you need to refer to the previous authentication session and the same user profile. Doing this via the User-Name AVP is not good. > >> - We may have trouble with RADIUS compatibility > > This can be handled later. I already see the problems looming on the horizon: Dynamic Authorization Extensions for RADIUS Ciao Hannes > > Yoshihiro Ohba > > >> >> Anyone has an opinion on this way to solve our issue ? >> >> Thanks yoshi, >> >> Julien >> >>>> If we "push" a little what you propose, we could define an >>>> "Authentication based on EAP" Application (only doing Authentication) >>>> used by other Application that would only define their messages for >>>> Authorization and Accounting (such as MIP6). That's why I talked to you >>>> in a previous mail about also consider network access as a special >>>> service and thus define Authz/Accounting messages for the "network >>>> access" service. >>> Yes, in the case of network access, you could use NASREQ for >>> authorization purpose in additon to Diameter EAP for authentication >>> purpose as specified in RFC 4072. >>> >>> Regards, >>> Yoshihiro Ohba >>> >>> >>>> regards, >>>> >>>> Julien >>>> >>>>> Regards, >>>>> Yoshihiro Ohba >>>>> >>>>>>> I also agree with Avi that defining a new application for MIP6 >>>>>>> bootstrapping on top of existing applications (Diameter EAP) without >>>>>>> defining a new application id but with defining new values for >>>>>>> existing AVPs or new optional AVPs has some issue, but this option >>>>>>> might not be as bad as the first option since backward compatibility >>>>>>> can be easily maintained unlike the first option. However, there is a >>>>>>> forward compatibility problem (i.e., a Diameter message may be forwarded >>>>>>> to a AAA server that does not support the new application). Besides >>>>>>> this problem, it might be worth pursuing this option because it works >>>>>>> in an optimized way (i.e., bootstrapping AVPs are piggybacked in >>>>>>> Diameter EAP or NASREQ message) as long as both NAS and AAA server >>>>>>> support the AVPs. >>>>>> I'm not in favor of having an app-id for the nas-aaah part of the mip6 >>>>>> bootstrapping problem. >>>>>> >>>>>>> In order to deal with the forward compatibility problem of the second >>>>>>> option, a third option is to define a new application for MIP6 >>>>>>> bootstrapping as a totally new authorization application that carries >>>>>>> new mandatory AVPs specific to that application. This option can be >>>>>>> run when execution of the second option succeeds in authentication but >>>>>>> fails in carrying bootstrapping AVPs. >>>>>> hmm, i guess i have to think more of this option but this would mandate >>>>>> now that all EAP Application server should know that maybe they are not >>>>>> doing this for network access and that maybe they are going to receive >>>>>> a special authorization request. And in this case, wouldn't it mean >>>>>> that network access should be treated as a special service and this >>>>>> would also require a new authorization application ? >>>>>> >>>>>> regards, >>>>>> >>>>>> Julien >>>>>>> Regards, >>>>>>> Yoshihiro Ohba >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Sep 05, 2006 at 11:21:22PM -0400, Avi Lior wrote: >>>>>>>> Hi Kuntal, >>>>>>>> >>>>>>>> Neither option 1 or option 2 will work. A new application id just wont >>>>>>>> scale in the long run. What if another 'capability' were to be added >>>>>>>> for instance prepaid. Since Diameter messages contain only one >>>>>>>> Application ID, you would have to create an Application Id that covered >>>>>>>> both EAP, Prepaid and Mobile IP. And what if a third application were >>>>>>>> added? The approach is not scalable as the applications are increased >>>>>>>> -- you would have to cope with all the different permutations of >>>>>>>> Applications. The same argument goes for ServiceType and PortType and >>>>>>>> these are actually more problematic. >>>>>>>> >>>>>>>> IMO the only thing we can do is to hint at the capability of the NAS. >>>>>>>> >>>>>>>> A proper solution should be concieved for this problem. >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] >>>>>>>>> Sent: Tuesday, September 05, 2006 2:09 PM >>>>>>>>> To: Avi Lior; Gerardo Giaretta; Hannes.Tschofenig@gmx.net >>>>>>>>> Cc: dime@ietf.org >>>>>>>>> Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. >>>>>>>>> Service-Type >>>>>>>>> >>>>>>>>> All, >>>>>>>>> >>>>>>>>> Here is a scenario that may need to be covered. In some >>>>>>>>> cases, local HA assignment is optimal for transport >>>>>>>>> efficiency perspective. Diameter >>>>>>>>> MIP4 application allows this. In such a case the ASP == MSP >>>>>>>>> and the HA is assigned locally (in the visited network). >>>>>>>>> >>>>>>>>> To enable this case, in the integrated scenario, the NAS/VAAA >>>>>>>>> needs to indicate it's capability to assign an HA in the >>>>>>>>> local network to the HAAA. The HAAA may allow or disallow >>>>>>>>> this local HA assignment based on policy of the MSA. >>>>>>>>> >>>>>>>>> The NAS/VAAA may need to include a hint in the AAA message to >>>>>>>>> the HAAA at the time of access authentication that it is >>>>>>>>> capable of providing an HA to the MN. This capability >>>>>>>>> indication (hint) can be either sent via a new MIP6 specific >>>>>>>>> AVP or it can be conveyed via an existing AVP (I don't know >>>>>>>>> if one exists). >>>>>>>>> >>>>>>>>> If we decide to include this (local HA assignment), and we >>>>>>>>> decide to include this mip6 specific hint in the NAS-HAAA >>>>>>>>> communication, we may have to choose the most appropriate >>>>>>>>> option (1) vs. (2). >>>>>>>>> >>>>>>>>> Comments? >>>>>>>>> >>>>>>>>> -Kuntal >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Avi Lior [mailto:avi@bridgewatersystems.com] >>>>>>>>>> Sent: Tuesday, September 05, 2006 6:07 AM >>>>>>>>>> To: Gerardo Giaretta; Hannes.Tschofenig@gmx.net >>>>>>>>>> Cc: dime@ietf.org >>>>>>>>>> Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. >>>>>>>>> Service-Type >>>>>>>>>> I must be missing something. >>>>>>>>>> >>>>>>>>>> In the integrated scenario, what would the NAS put in Service-Type? >>>>>>>>>> >>>>>>>>>> I think in the integrated scenario neither Port-Type or >>>>>>>>> Service-Type >>>>>>>>>> needs to be touched. >>>>>>>>>> >>>>>>>>>> As far as I understand the NAS is either executing EAP >>>>>>>>> Application or >>>>>>>>>> NAS REQ. It does not know whether the user will result in having >>>>>>>>>> subsequent Mobile IP service or not. >>>>>>>>>> >>>>>>>>>> The only thing the AAA server can do is to send the MIPv6 attributes >>>>>>>>> as >>>>>>>>>> optional (M bit off) and hope that if the NAS does not >>>>>>>>> understand the >>>>>>>>>> attributes it would have some logic to bootstrap a different way. >>>>>>>>>> >>>>>>>>>> We could improve the situration somewhat. We could have the NAS >>>>>>>>>> indicate that it supports MIPv6 bootstrapping by including hints in >>>>>>>>> the >>>>>>>>>> AR (a capability hint). Where the NAS includes HA-IP address AVP >>>>>>>>> both >>>>>>>>>> indicating that it can support bootstrapping and if the >>>>>>>>> HA-IP address >>>>>>>>> is >>>>>>>>>> not ALL-ZEROS or ALL ONES it provides a hint that it can support >>>>>>>>> dynamic >>>>>>>>>> HA assignement. >>>>>>>>>> >>>>>>>>>> Ofcourse we could introduce the concept of capability hints more >>>>>>>>>> formally in Diameter -- This is missing today. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] >>>>>>>>>>> Sent: Tuesday, September 05, 2006 3:35 AM >>>>>>>>>>> To: Hannes.Tschofenig@gmx.net >>>>>>>>>>> Cc: dime@ietf.org >>>>>>>>>>> Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. >>>>>>>>>>> Service-Type >>>>>>>>>>> >>>>>>>>>>> Hi Hannes, >>>>>>>>>>> >>>>>>>>>>> I agree with Jouni. I prefer (2) for NAS-AAAH and (1) for >>>>>>>>> AAAH-HA. >>>>>>>>>>> In my understanding, there are no mandatory AVPs for NAS-AAAH and >>>>>>>>>>> therefore I don't see a need of a new application; it's just a >>>>>>>>>>> MIP-specific information that is piggybacked in the >>>>>>>>> network access >>>>>>>>>>> authentication procedure. >>>>>>>>>>> >>>>>>>>>>> Concerning AAAH-HA, I think it is a much cleaner approach >>>>>>>>> to define >>>>>>>>>>> a new application, since it does not anything to do with network >>>>>>>>>>> authentication. >>>>>>>>>>> >>>>>>>>>>> --Gerardo >>>>>>>>>>> >>>>>>>>>>> On 9/5/06, jouni.korhonen@teliasonera.com >>>>>>>>>>> wrote: >>>>>>>>>>>> Hi HAnnes, >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>>>>>>>> Sent: 1. syyskuuta 2006 1:07 >>>>>>>>>>>>> To: dime@ietf.org >>>>>>>>>>>>> Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. >>>>>>>>>>>>> Service-Type >>>>>>>>>>>>> >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>> >>>>>>>>>>>>> we have had long discussions about the App-ID vs. >>>>>>>>>>>>> Service-Type usage for >>>>>>>>>>>>> Diameter MIPv6 Bootstrapping. >>>>>>>>>>>>> >>>>>>>>>>>>> It is time to see what the group thinks. Please indicate >>>>>>>>>>> whether you >>>>>>>>>>>>> prefer (1) an App-ID or (2) a Service-Type solution for >>>>>>>>>>>>> >>>>>>>>>>>>> (a) NAS-to-AAAH communication (as required by the integrated >>>>>>>>>>>>> scenario; as one part of the solution component) >>>>>>>>>>>> I would prefer (2) for now.. or as long as the NAS-2-AAAH main >>>>>>>>>>>> function is to provide access authentication, where the backend >>>>>>>>> AAA >>>>>>>>>>>> may return >>>>>>>>>>>> MIP6 >>>>>>>>>>>> bootstrapping info (as an enhancement) based e.g. on the user >>>>>>>>>>>> subscription profile. If we go for more stuff on >>>>>>>>> NAS-2-AAAH like >>>>>>>>>>>> HoA/prefix etc then >>>>>>>>>>>> (1) >>>>>>>>>>>> might be better. >>>>>>>>>>>> >>>>>>>>>>>>> (b) HA-to-AAAH communication (as used by the split >>>>>>>>>>> scenario and the >>>>>>>>>>>>> integrated scenario) >>>>>>>>>>>> I would prefer (1) here. The use of EAP for MIP6 bootstrapping >>>>>>>>>>>> purposes and for 'normal' EAP-based access authentication are >>>>>>>>>>>> different applications imho. (although in IKEv2 vs 802.1X case >>>>>>>>> e.g. >>>>>>>>>>>> NAS-Port-Type could be used to make this distinction.. e.g. >>>>>>>>>>> how 3GPP >>>>>>>>>>>> WLAN stuff does it) >>>>>>>>>>>> >>>>>>>>>>>>> It might be useful to state a reason for your decision. >>>>>>>>>>>>> >>>>>>>>>>>>> Please also indicate whether some aspects are still >>>>>>>>>>> unclear to you. >>>>>>>>>>>>> Ciao >>>>>>>>>>>>> Hannes >>>>>>>>>>>> Cheers, >>>>>>>>>>>> Jouni >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> DiME mailing list >>>>>>>>>>>>> DiME@ietf.org >>>>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/dime >>>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> DiME mailing list >>>>>>>>>>>> DiME@ietf.org >>>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/dime >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> DiME mailing list >>>>>>>>>>> DiME@ietf.org >>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/dime >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> DiME mailing list >>>>>>>>>> DiME@ietf.org >>>>>>>>>> https://www1.ietf.org/mailman/listinfo/dime >>>>>>>>> >>>>>>>>> "This email message and any attachments are confidential >>>>>>>>> information of Starent Networks, Corp. The information >>>>>>>>> transmitted may not be used to create or change any >>>>>>>>> contractual obligations of Starent Networks, Corp. Any >>>>>>>>> review, retransmission, dissemination or other use of, or >>>>>>>>> taking of any action in reliance upon this e-mail and its >>>>>>>>> attachments by persons or entities other than the intended >>>>>>>>> recipient is prohibited. If you are not the intended >>>>>>>>> recipient, please notify the sender immediately -- by >>>>>>>>> replying to this message or by sending an email to >>>>>>>>> postmaster@starentnetworks.com -- and destroy all copies of >>>>>>>>> this message and any attachments without reading or >>>>>>>>> disclosing their contents. Thank you." >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> DiME mailing list >>>>>>>> DiME@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/dime >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> DiME mailing list >>>>>>> DiME@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/dime >>>>>> -- >>>>>> julien.bournelle at int-evry.fr >>>>>> >>>> -- >>>> julien.bournelle at int-evry.fr >>>> >> -- >> julien.bournelle at int-evry.fr >> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 21 03:07:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQIeT-0005s0-Lb; Thu, 21 Sep 2006 03:07:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQIeR-0005rv-W6 for dime@ietf.org; Thu, 21 Sep 2006 03:07:15 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GQIeN-0004je-6b for dime@ietf.org; Thu, 21 Sep 2006 03:07:15 -0400 Received: (qmail invoked by alias); 21 Sep 2006 07:07:10 -0000 Received: from ip-80-226-194-40.vodafone-net.de (EHLO [10.227.54.70]) [80.226.194.40] by mail.gmx.net (mp036) with SMTP; 21 Sep 2006 09:07:10 +0200 X-Authenticated: #29516787 Message-ID: <45123A23.7090405@gmx.net> Date: Thu, 21 Sep 2006 03:07:15 -0400 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: [Dime] My Summary of the MIPv6 Bootstrapping Discussion X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, let me try to summarize what was discussed recently with regard to MIPv6 bootstrapping. We agreed that it would be useful to differentiate the following two cases: (1) NAS<->AAA Server (2) HA<->AAA Server [We need to change the titles of our document a bit.] With regard to (1) a number of folks were in favor of introducing a capability mechanism that allows the NAS to indicate that it supports a certain functionality. As Avi said, this newly required AVP would be optional to use and optional to understand. If a NAS does support bootstrapping for MIPv6 it includes the attribute in AR (NASREQ or EAP). If it lands at a server that understands this attribute, then it will respond correctly if it wants to bootstrap MIPv6. If it lands at a server that doesn't understand the attribute then bootstrapping via AAA will not occur. Defining a new AppID is not needed and consequently the Diameter NASREQ/EAP message would hit the same server that also supports MIPv6 bootstrapping. As an alternative, Yoshi suggested to go along the same approach as in (2). The drawback would be the performance hit. This would, however, allow the two servers to be different (if this is at all useful). With regard to (2) Yoshi suggested a new AppID to be used for Authorization and Accounting and not to reuse the EAP/NASREQ ABNF. As Julien wrote, we are able to continue to use Diameter EAP for Authentication. Thus, the HA will use Diameter EAP with the AVP Auth-Request-Type set to AUTHENTICATE_ONLY and then the HA will use this MIP6 Application for Authorization/Accounting of the Mobile IPv6 service. This would avoid to update the application if RFC 4072 is updated and this could be a way to proceed if other applications need EAP for Authentication but have different needs for the Authorization and Accounting part. Again, there is a performance disadvantage if a separate exchange is used instead of piggybacking functionality. [I am still not sure how this nicely interworks with the QoS work we do in the group. That's for further investigation.] I think we made progress in our discussions. Julien has initiated a poll to see what todo regarding (2) and whether the group likes Yoshi's suggestion. For (1) I got the impression that the focus currently is more on the capability exchange but we might need to initiate another poll there as well. Btw, the conclusions we make in this discussion can also be reused for the Diameter QoS work. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 21 03:27:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQIxu-0000Ae-T4; Thu, 21 Sep 2006 03:27:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQIxt-0000AZ-Gd for dime@ietf.org; Thu, 21 Sep 2006 03:27:21 -0400 Received: from scalix.digitalroute.se ([213.142.6.19] helo=scalix.digitalroute.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQIxm-0000ds-Tx for dime@ietf.org; Thu, 21 Sep 2006 03:27:21 -0400 Received: from scalix.digitalroute.com (localhost [127.0.0.1]) by scalix.digitalroute.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id k8L7R9LQ028374; Thu, 21 Sep 2006 09:27:10 +0200 Received: from scalix.digitalroute.com (root@localhost) by scalix.digitalroute.com (8.12.11.20060308/8.12.11/Submit) with ESMTP id k8L7R9af028372; Thu, 21 Sep 2006 09:27:09 +0200 Received: from [10.0.0.234] ( 10.0.0.234) by scalix.digitalroute.com (Scalix SMTP Relay 10.0.1.3) via ESMTP; Thu, 21 Sep 2006 09:27:09 +0200 (CEST) Date: Thu, 21 Sep 2006 09:27:06 +0200 From: Andreas Fredriksson To: Timothy Smith Message-ID: <45123ECA.6010405@digitalroute.com> In-Reply-To: References: Subject: Re: [Dime] receving connections from 3868 with multiple instances. x-scalix-Hops: 1 User-Agent: Thunderbird 1.5.0.7 (X11/20060915) MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Disposition: inline X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: dime@ietf.org, Valesh Chandu X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Timothy Smith wrote: > > Hi Chandu, > > I think you have touched on an area where there are a couple of > unclear points. I also interpret that you can have multiple Diameter > nodes on the same host. I think this implies: > 1) Each node must listen on a different port as you have pointed out. > So, only one of the nodes can use the recommended port 3868. > 2) The Origin-Host AVP is also problematic in that its value conflicts > in a host with multiple Diameter nodes. The Origin-Host is of type > Diameter Identity, and "The value of the Origin-Host AVP is guaranteed > to be unique within a single host". But also, "DiameterIdentity value > is used to uniquely identify a Diameter node for purposes of duplicate > connection..." These two statements are inconsistent on a host with > multiple Diameter nodes. The Diameter Identity is a FQDN which > realistically means you can only have a single Origin-Host name for > all of the nodes on a given host. So, the dilemma is that if you have > multiple Diameter nodes on host A and multiple Diameter nodes on host > B, then because of the single connection rule, you will only be able > to set up one connection between one of the nodes on host A and one of > the nodes on host B. This is something that I think should be > clarified in the BIS document. My preference would be to say that the > Origin-Host AVP should be a FQDN, but not that it must be a FQDN. > That way, you could assign a unique Origin-Host name to each Diameter > node on a host. And any or all nodes on Host A could establish a > connection to any or all nodes on Host B. Hi, I think the port 3868 restriction helps when you're doing dynamic peer discovery. If an implementation sees an unknown diameter identity it could try the various discovery options outlined in the RFC (e.g. DNS lookups). These do not include a port anywhere IIRC and if there are multiple stacks running on a single IP messages could end up on the wrong stack. However, it's perfectly fine to use several IP addresses (using ethernet aliases) on a single box which map to different FQDNs. This removes the above limitation and is fine as far as the RFC goes. Best regards, Andreas _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 21 04:56:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQKML-0007Zb-PG; Thu, 21 Sep 2006 04:56:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQKMK-0007ZW-Lm for dime@ietf.org; Thu, 21 Sep 2006 04:56:40 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQKMJ-0001ey-7j for dime@ietf.org; Thu, 21 Sep 2006 04:56:40 -0400 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k8L8t9Jd081482; Thu, 21 Sep 2006 04:55:10 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Date: Thu, 21 Sep 2006 04:55:10 -0400 To: Hannes Tschofenig Subject: Re: Integration of QoS? AW: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part 2) Message-ID: <20060921085509.GB30111@steelhead> References: <451239FD.7000801@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=euc-jp Content-Disposition: inline In-Reply-To: <451239FD.7000801@gmx.net> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 99 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by toshi17.tari.toshiba.com id k8L8t9Jd081482 X-Spam-Score: -1.6 (-) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Hannes, On Thu, Sep 21, 2006 at 03:06:37AM -0400, Hannes Tschofenig wrote: > Hi Julien, > Hi Yoshi, >=20 > as part of the current charter we are working on two broad topics:=20 > mobility ad QoS >=20 > How would I combine MIP6 bootstrapping with QoS when, for example,=20 > additional AVPs have to be returned to the NAS/HA in the=20 > Diameter-EAP-Answer together with mobility specific parameters? >=20 > If I understood Yoshi right then he would define another=20 > Authorization/Accounting application for QoS and hence we would need=20 > three separate exchanges instead of one. Correct?=20 Yes, that is correct. I would like to also note that those applications as well as EAP application can be executed in parallel. So it does not necessarily has a performance issue unlike you mentioned in another email that summarizes the discussion. > How would we combine=20 > the QoS with DCC when real-time accounting? I don't know what issue would arise when we run QoS and DCC as different applications with real-time accounting. Can you elaborate on possible issue? Yoshihiro Ohba >=20 > Ciao > Hannes >=20 > PS: Ideally we would like to avoid too many dependencies between the=20 > different Diameter document. For example, we don't want to modify a=20 > bootstrapping document when RFC 4072 is updated. We don't want to write= =20 > a new document when we realize that it would be useful to have QoS,=20 > Mobility & Credit Control combined. >=20 > > -----Urspr=8F=AB=E4ngliche Nachricht----- > > Von: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > > Gesendet: Freitag, 15. September 2006 06:21 > > An: dime@ietf.org > > Betreff: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) > > (polling part 2) > > > > Hi all, > > > > this is a new polling concerning the ha-aaah interface for the Mobil= e > > IPv6 Boostrapping. To date, at the previous one, there was a > > consensus on moving forward with a new App-ID. But, yoshi has > > proposed an interesting idea that should be considered by the WG. > > > > As you may recall, in the ha-aaah case, the MN is authenticated by > > EAP (IKEv2 is used between MN and the HA) and thus the HA-AAAH > > interface must, at least, be able to carry EAP packets. It > > appears that > > we now have 2 options: > > > > (1) We define a new Diameter application for Mobile IPv6 with a new > > App-ID that carry EAP packets as it is done in RFC 4072 (Diamete= r > > EAP) but Authorization and Accouting is specific to Mobile IPv6 > > (thus the need for a new App-ID). The risk, as noted by yoshi, i= s > > that an update of the RFC4072 may result in an update of this > > application. > > > > > > (2) We define a new Diameter Application for Mobile IPv6 but which i= s > > used for Authorization and Accounting. We continue to use > > Diameter EAP for the Authentication. Thus the HA will use > > Diameter EAP with the AVP Auth-Request-Type set to > > AUTHENTICATE_ONLY and then the HA will use this MIP6 Application > > for Authorization/Accounting of the Mobile IPv6 service. This ne= w > > application will have its own App-ID. > > > > This would avoid to update the application if 4072 is updated an= d > > this could be a way to proceed if other applications need EAP fo= r > > Authentication but have different needs for the Authorization an= d > > Accounting part. > > > > Please indicate wether you prefer (1) or (2). > > > > As in the previous polling: > > - it might be useful to state a reason for your decision. > > - indicate wether some aspects are still unclear to you. > > > > Regards, > > > > Julien > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 21 05:20:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQKiq-0001kW-8p; Thu, 21 Sep 2006 05:19:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQKip-0001kM-3I for dime@ietf.org; Thu, 21 Sep 2006 05:19:55 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQKil-0003kJ-MF for dime@ietf.org; Thu, 21 Sep 2006 05:19:55 -0400 Received: by ug-out-1314.google.com with SMTP id 72so96613ugd for ; Thu, 21 Sep 2006 02:19:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FiNHwXymKrDxfey4ZhtseD5tS0Y4lS5XztfH3oCwFEi/ByfP+sGyWEQIXfq7Ivro7xx0vBUPcnwbUxzLbZ6ATg1HD1gNJO4UhO18Qcr5kE9hwuUjbbJbN87hycctkXLxw1MOVC/GCZFao8OUeoX/gR3c6EWKt/+dA/dVZeeSivg= Received: by 10.67.91.6 with SMTP id t6mr1561748ugl; Thu, 21 Sep 2006 02:19:50 -0700 (PDT) Received: by 10.66.243.16 with HTTP; Thu, 21 Sep 2006 02:19:50 -0700 (PDT) Message-ID: Date: Thu, 21 Sep 2006 11:19:50 +0200 From: "Gerardo Giaretta" To: "Chowdhury, Kuntal" Subject: Re: [Dime] renaming and re-scoping of the Dime MIP6 I-Ds In-Reply-To: <7CCD07160348804497EF29E9EA5560D78373C4@exchtewks2.starentnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <7CCD07160348804497EF29E9EA5560D78373C4@exchtewks2.starentnetworks.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: mip6@ietf.org, dime@ietf.org, charliep@iprg.nokia.com, hannes.tschofenig@siemens.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Kuntal, the proposal sounds good and I think it is the correct way forward. I agree that we do not need to differentiate the scenario we are considering during the specification of AAA-HA interface. Based on AAA-HA goals draft, I think most (or even all) goals are common to both scenarios. --Gerardo On 9/21/06, Chowdhury, Kuntal wrote: > > > Hi all, > > We had an offline discussion on the scope of the two Diameter mip6 > bootstrapping I-Ds that are being defined at this time. The current title= s > and scopes of the documents seem to convey inaccurate information of the > actual intent of each of them. For example, the mip6 bootstrapping soluti= ons > as developed in MIP6 WG need the Diameter components for the following > interfaces: > > > > NAS-HAAA: Integrated scenario > > HA-HAAA: Integrated and Split scenarios > > > > What we need to do in Dime WG is to define these two components. The curr= ent > structures of the drafts introduce unnecessary dependencies between them = by > focusing on the individual mip6 bootstrapping scenarios rather than the > actual purpose i.e. defining the Diameter (AAA) components needed for bot= h > the mip6 bootstrapping solutions. Moreover, the HA =96 HAAA interface can= be > defined in such a way that it covers mip6 in general. > > > > So, the suggestion is to rename and re-scope the documents as follows: > > > > 1. Filename =3D dime-mip6-nas-aaa-interface: Title =3D The NAS - HAAA int= erface > for mip6 bootstrapping > > 2. Filename =3D dime-mip6-ha-aaa-interface: Title =3D The HA - HAAA inter= face > for mip6 > > Please let us know your comments. > > Regards, > > Kuntal > > "This email message and any attachments are confidential information of > Starent Networks, Corp. The information transmitted may not be used to > create or change any contractual obligations of Starent Networks, Corp. A= ny > review, retransmission, dissemination or other use of, or taking of any > action in reliance upon this e-mail and its attachments by persons or > entities other than the intended recipient is prohibited. If you are not = the > intended recipient, please notify the sender immediately -- by replying t= o > this message or by sending an email to postmaster@starentnetworks.com -- = and > destroy all copies of this message and any attachments without reading or > disclosing their contents. Thank you." > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 21 05:24:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQKmz-0005Np-Kk; Thu, 21 Sep 2006 05:24:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQKmy-0005Nf-M6 for dime@ietf.org; Thu, 21 Sep 2006 05:24:12 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQKmu-0004D6-9J for dime@ietf.org; Thu, 21 Sep 2006 05:24:12 -0400 Received: by ug-out-1314.google.com with SMTP id 72so96990ugd for ; Thu, 21 Sep 2006 02:24:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fOlJ8pk7+VJLH/QpCOMyV1GxlGgW4QvNUzSFWpv2r74C9NYBNnxIp4eHUMS0c9r2s1YafdnIdpOWdWxwf0RkeGahoPq0NKWl8I3Mmqz8TG3B13m3nXZgJClzs5C0rSUVkDT/41cwsjWao1QfY8YPSdC5EWGYG7Ur/ebVAb1dcPg= Received: by 10.67.119.5 with SMTP id w5mr9024471ugm; Thu, 21 Sep 2006 02:24:07 -0700 (PDT) Received: by 10.66.243.16 with HTTP; Thu, 21 Sep 2006 02:24:07 -0700 (PDT) Message-ID: Date: Thu, 21 Sep 2006 11:24:07 +0200 From: "Gerardo Giaretta" To: "Vijay Devarapalli" Subject: Re: [Dime] renaming and re-scoping of the Dime MIP6 I-Ds In-Reply-To: <4512033A.2080809@azairenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <7CCD07160348804497EF29E9EA5560D78373C4@exchtewks2.starentnetworks.com> <4512033A.2080809@azairenet.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: mip6@ietf.org, dime@ietf.org, charliep@iprg.nokia.com, hannes.tschofenig@siemens.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org > Chowdhury, Kuntal wrote: > > We had an offline discussion on the scope of the two Diameter mip6 > > bootstrapping I-Ds that are being defined at this time. The > > current titles and scopes of the documents seem to convey inaccurate > > information of the actual intent of each of them. For example, the mip6 > > bootstrapping solutions as developed in MIP6 WG need the Diameter > > components for the following interfaces: > > > > NAS-HAAA: Integrated scenario > > this would be for MIP6 service authorization + MIP6 > HA/HoA information, correct? > > > HA-HAAA: Integrated and Split scenarios > > this would include authentication + authorization, > correct? > In general this will define a solution that takes into account all goals listed in draft-ietf-mip6-aaa-ha-goals (e.g. authorization, session termination, etc.) --Gerardo > Vijay > > > > > > > > > What we need to do in Dime WG is to define these two components. The > > current structures of the drafts introduce unnecessary dependencies > > between them by focusing on the individual mip6 bootstrapping scenarios > > rather than the actual purpose i.e. defining the Diameter (AAA) > > components needed for both the mip6 bootstrapping solutions. Moreover, > > the HA =96 HAAA interface can be defined in such a way that it covers m= ip6 > > in general. > > > > > > > > So, the suggestion is to rename and re-scope the documents as follows: > > > > > > > > 1. Filename =3D dime-mip6-nas-aaa-interface: Title =3D The NAS - HAAA > > interface for mip6 bootstrapping > > > > 2. Filename =3D dime-mip6-ha-aaa-interface: Title =3D The HA - HAAA > > interface for mip6 > > > > Please let us know your comments. > > > > Regards, > > > > Kuntal > > > > "This email message and any attachments are confidential information of > > Starent Networks, Corp. The information transmitted may not be used to > > create or change any contractual obligations of Starent Networks, Corp. > > Any review, retransmission, dissemination or other use of, or taking of > > any action in reliance upon this e-mail and its attachments by persons > > or entities other than the intended recipient is prohibited. If you are > > not the intended recipient, please notify the sender immediately -- by > > replying to this message or by sending an email to > > postmaster@starentnetworks.com -- and destroy all copies of this messag= e > > and any attachments without reading or disclosing their contents. Thank > > you." > > > > > > -----------------------------------------------------------------------= - > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 21 07:30:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQMkm-0000Mi-8X; Thu, 21 Sep 2006 07:30:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQMkl-0000LP-I4 for dime@ietf.org; Thu, 21 Sep 2006 07:30:03 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQMkh-0007gu-0k for dime@ietf.org; Thu, 21 Sep 2006 07:30:03 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k8LBTvNn019159 for ; Thu, 21 Sep 2006 14:29:57 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Sep 2006 14:29:57 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Sep 2006 14:29:57 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Design Decisions for RFC 4072: Re: [Dime] Re: Using Diameter EAP--only-- for Authentication ? Date: Thu, 21 Sep 2006 14:30:02 +0300 Message-ID: In-Reply-To: <45123A0C.2090105@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Design Decisions for RFC 4072: Re: [Dime] Re: Using Diameter EAP--only-- for Authentication ? Thread-Index: AcbdTUG8F81A+jw/TdG6mGkI8PDVwAAIWw2g From: To: X-OriginalArrivalTime: 21 Sep 2006 11:29:57.0387 (UTC) FILETIME=[445175B0:01C6DD71] X-Spam-Score: 0.2 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hannes Tschofenig wrote: > > Yes, in the case of network access, you could use NASREQ for > > authorization purpose in additon to Diameter EAP for=20 > > authentication purpose as specified in RFC 4072. > > I wonder why the Diameter EAP authors have decided not to use > this approach. > > It would be interesting to learn something about their design > decisions. Diameter EAP was modeled as the Diameter counterpart of RFC3579+2548, so it followed the RADIUS way of doing things: the mandatory AVPs are about authentication and basic Diameter functionality, and then you add whatever authorization AVPs your specific service needs (which would depend on what you're doing, e.g. 802.1X/11 would be different from IKEv2 etc.). And the authorization AVPs are piggybacked in the=20 same messages (essentially first request and the success response). One important reason why it was done this way was the need=20 for RADIUS translation. This might be relevant for MIP6 as well=20 (cf. draft-chowdhury-mip6-radius). Interestingly enough, 3GPP "Wm" reference point (TS 29.234) does use RFC 4072 in AUTHENTICATE_ONLY mode, and then does authorization using NASREQ. I have no idea why they did it this way, though. Best regards, Pasi _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 21 09:22:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQOVB-0007EO-Kb; Thu, 21 Sep 2006 09:22:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQOVA-00079f-Oz for dime@ietf.org; Thu, 21 Sep 2006 09:22:04 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQOUd-00022T-HX for dime@ietf.org; Thu, 21 Sep 2006 09:22:04 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 1C6C6A6B05; Thu, 21 Sep 2006 09:21:28 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k8LDLQu8006198; Thu, 21 Sep 2006 09:21:27 -0400 (EDT) From: "Tolga Asveren" To: "Andreas Fredriksson" , "Timothy Smith" Subject: RE: [Dime] receving connections from 3868 with multiple instances. Date: Thu, 21 Sep 2006 09:19:57 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-Reply-To: <45123ECA.6010405@digitalroute.com> Importance: Normal Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: dime@ietf.org, Valesh Chandu X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Andreas, For a truly dynamic discovery, wouldn't the "Port" in SRV lookup result address your concern of not being able to distinguish between multiple instances on the same host? Thanks, Tolga > -----Original Message----- > From: Andreas Fredriksson [mailto:Andreas.Fredriksson@digitalroute.com] > Sent: Thursday, September 21, 2006 3:27 AM > To: Timothy Smith > Cc: dime@ietf.org; Valesh Chandu > Subject: Re: [Dime] receving connections from 3868 with multiple > instances. > > > Timothy Smith wrote: > > > > Hi Chandu, > > > > I think you have touched on an area where there are a couple of > > unclear points. I also interpret that you can have multiple Diameter > > nodes on the same host. I think this implies: > > 1) Each node must listen on a different port as you have pointed out. > > So, only one of the nodes can use the recommended port 3868. > > 2) The Origin-Host AVP is also problematic in that its value conflicts > > in a host with multiple Diameter nodes. The Origin-Host is of type > > Diameter Identity, and "The value of the Origin-Host AVP is guaranteed > > to be unique within a single host". But also, "DiameterIdentity value > > is used to uniquely identify a Diameter node for purposes of duplicate > > connection..." These two statements are inconsistent on a host with > > multiple Diameter nodes. The Diameter Identity is a FQDN which > > realistically means you can only have a single Origin-Host name for > > all of the nodes on a given host. So, the dilemma is that if you have > > multiple Diameter nodes on host A and multiple Diameter nodes on host > > B, then because of the single connection rule, you will only be able > > to set up one connection between one of the nodes on host A and one of > > the nodes on host B. This is something that I think should be > > clarified in the BIS document. My preference would be to say that the > > Origin-Host AVP should be a FQDN, but not that it must be a FQDN. > > That way, you could assign a unique Origin-Host name to each Diameter > > node on a host. And any or all nodes on Host A could establish a > > connection to any or all nodes on Host B. > Hi, > I think the port 3868 restriction helps when you're doing dynamic peer > discovery. If an implementation sees an unknown diameter identity it > could try the various discovery options outlined in the RFC (e.g. DNS > lookups). These do not include a port anywhere IIRC and if there are > multiple stacks running on a single IP messages could end up on the > wrong stack. > > However, it's perfectly fine to use several IP addresses (using ethernet > aliases) on a single box which map to different FQDNs. This removes the > above limitation and is fine as far as the RFC goes. > > Best regards, > Andreas > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 21 12:25:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQRMP-0003dQ-4b; Thu, 21 Sep 2006 12:25:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQRMO-0003c5-IB for dime@ietf.org; Thu, 21 Sep 2006 12:25:12 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQOV7-000231-Ca for dime@ietf.org; Thu, 21 Sep 2006 09:22:01 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GQOIM-0002Dt-1x for dime@ietf.org; Thu, 21 Sep 2006 09:08:52 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 8CE867D0E1; Thu, 21 Sep 2006 09:08:48 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k8LD8kb5004935; Thu, 21 Sep 2006 09:08:47 -0400 (EDT) From: "Tolga Asveren" To: "Timothy Smith" Subject: RE: [Dime] receving connections from 3868 with multiple instances. Date: Thu, 21 Sep 2006 09:07:17 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-Reply-To: Importance: Normal Received-SPF: none X-Spam-Score: -1.7 (-) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: dime@ietf.org, Valesh Chandu X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tim, Yes, multiple FQDN can resolve to the same IP. Thanks, Tolga -----Original Message----- From: Timothy Smith [mailto:tjsmith@us.ibm.com] Sent: Wednesday, September 20, 2006 4:41 PM To: Tolga Asveren Cc: Valesh Chandu; dime@ietf.org Subject: RE: [Dime] receving connections from 3868 with multiple instances. Hi Tolga, Thanks for your note. I think I was stuck in a rut. From your note, I would assume that we can update a DNS server with any number of aliases to provide a unique FQDN for each node on the same host, correct? Best Regards, Timothy Smith tjsmith@us.ibm.com (919) 254-4723 "Tolga Asveren" 09/20/2006 09:11 AM ToTimothy Smith/Raleigh/IBM@IBMUS, "Valesh Chandu" cc SubjectRE: [Dime] receving connections from 3868 with multiple instances. Hi Timothy, Please see below for comments. Thanks, Tolga -----Original Message----- From: Timothy Smith [mailto:tjsmith@us.ibm.com] Sent: Wednesday, September 20, 2006 8:50 AM To: Valesh Chandu Cc: dime@ietf.org Subject: Re: [Dime] receving connections from 3868 with multiple instances. Hi Chandu, I think you have touched on an area where there are a couple of unclear points. I also interpret that you can have multiple Diameter nodes on the same host. I think this implies: 1) Each node must listen on a different port as you have pointed out. So, only one of the nodes can use the recommended port 3868. [TOLGA]I agree. 2) The Origin-Host AVP is also problematic in that its value conflicts in a host with multiple Diameter nodes. The Origin-Host is of type Diameter Identity, and "The value of the Origin-Host AVP is guaranteed to be unique within a single host". But also, "DiameterIdentity value is used to uniquely identify a Diameter node for purposes of duplicate connection..." These two statements are inconsistent on a host with multiple Diameter nodes. The Diameter Identity is a FQDN which realistically means you can only have a single Origin-Host name for all of the nodes on a given host. So, the dilemma is that if you have multiple Diameter nodes on host A and multiple Diameter nodes on host B, then because of the single connection rule, you will only be able to set up one connection between one of the nodes on host A and one of the nodes on host B. This is something that I think should be clarified in the BIS document. My preference would be to say that the Origin-Host AVP should be a FQDN, but not that it must be a FQDN. That way, you could assign a unique Origin-Host name to each Diameter node on a host. And any or all nodes on Host A could establish a connection to any or all nodes on Host B. [TOLGA]Is this really a problem? A physical host can have multiple FQDN, where each of them refer to a single Diameter node. I think this is already covered in definition of Diameter Identity in 4.3. Best Regards, Timothy Smith tjsmith@us.ibm.com (919) 254-4723 "Valesh Chandu" 09/19/2006 05:13 AM Please respond to Valesh Chandu Todime@ietf.org cc Subject[Dime] receving connections from 3868 with multiple instances. Hi all, I have a doubt regarding receiving connection requests/listening on port 3868 in case of multiple instances on a single host with one interface. Snippet from sec 2.1 of RFC 3588: A Diameter node MAY initiate connections from a source port other than the one that it declares it accepts incoming connections on, and MUST be prepared to receive connections on port 3868.A given Diameter instance of the peer state machine MUST NOT use more than one transport connection to communicate with a given peer, unless multiple instances exist on the peer in which case a separate connection per process is allowed. Diameter Node is defined as : A Diameter node is a host process that implements the Diameter protocol, and acts either as a Client, Agent or Server. My understanding of the above section is that multiple instances of the diameter stack is possible on the same host machine. So, if we have multiple instances on a single host then how it is possible to listen on the same port 3868 from all the instances? Please any one clarify my doubt? Best Regards, Chandu https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Sep 22 07:09:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQity-0006sG-LV; Fri, 22 Sep 2006 07:09:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQitx-0006rx-HU; Fri, 22 Sep 2006 07:09:01 -0400 Received: from [59.145.147.70] (helo=ricky.india.internal.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQitu-00070q-HM; Fri, 22 Sep 2006 07:09:01 -0400 X-Anti-Virus: Cyberoam Anti-Virus for SMTP; Kaspersky 5.5.3/RELEASE, bases: 22092006 #212396; status: clean Received: from klk ([172.16.2.32]) by ricky.india.internal.net (8.12.10/8.11.6) with ESMTP id k8MB3LBI011779; Fri, 22 Sep 2006 16:33:30 +0530 From: "kamakshi" To: Subject: [Dime] Base Accounting Date: Fri, 22 Sep 2006 16:40:34 +0530 Message-ID: <000701c6de37$c100f1f0$200210ac@klk> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: X-SpamTest-Info: Profile: Formal (548/060921) X-SpamTest-Info: Profile: Detect Hard (4/030526) X-SpamTest-Info: Profile: SysLog X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [0124], KAS/Release X-Spam-Score: 0.1 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: mip6@ietf.org, dime@ietf.org, charliep@iprg.nokia.com, hannes.tschofenig@siemens.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi All, It is mentioned in the rc3588 that the Accounting state machine is server directed and it uses Accounting-Realtime-Required AVP to instruct the client how it has to operate(when the transfer of records is delayed or not delivered). But the RFC does not specify under what conditions are this AVP values set to DELIVER_AND_GRANT, GRANT_AND_STORE or GRANT_AND_LOSE. The Rf application doesn't use this AVP and the NASREQ application also doesn't define how this has to be set. Is there any other application which tells how it has to used at the server side ? Thanks, Kamakshi L K -----Original Message----- From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com]=20 Sent: Thursday, September 21, 2006 2:54 PM To: Vijay Devarapalli Cc: mip6@ietf.org; dime@ietf.org; charliep@iprg.nokia.com; hannes.tschofenig@siemens.com Subject: Re: [Dime] renaming and re-scoping of the Dime MIP6 I-Ds > Chowdhury, Kuntal wrote: > > We had an offline discussion on the scope of the two Diameter mip6 > > bootstrapping I-Ds that are being defined at this time. The > > current titles and scopes of the documents seem to convey inaccurate > > information of the actual intent of each of them. For example, the mip6 > > bootstrapping solutions as developed in MIP6 WG need the Diameter > > components for the following interfaces: > > > > NAS-HAAA: Integrated scenario > > this would be for MIP6 service authorization + MIP6 > HA/HoA information, correct? > > > HA-HAAA: Integrated and Split scenarios > > this would include authentication + authorization, > correct? > In general this will define a solution that takes into account all goals listed in draft-ietf-mip6-aaa-ha-goals (e.g. authorization, session termination, etc.) --Gerardo > Vijay > > > > > > > > > What we need to do in Dime WG is to define these two components. The > > current structures of the drafts introduce unnecessary dependencies > > between them by focusing on the individual mip6 bootstrapping scenarios > > rather than the actual purpose i.e. defining the Diameter (AAA) > > components needed for both the mip6 bootstrapping solutions. Moreover, > > the HA =96 HAAA interface can be defined in such a way that it = covers mip6 > > in general. > > > > > > > > So, the suggestion is to rename and re-scope the documents as follows: > > > > > > > > 1. Filename =3D dime-mip6-nas-aaa-interface: Title =3D The NAS - = HAAA > > interface for mip6 bootstrapping > > > > 2. Filename =3D dime-mip6-ha-aaa-interface: Title =3D The HA - HAAA > > interface for mip6 > > > > Please let us know your comments. > > > > Regards, > > > > Kuntal > > > > "This email message and any attachments are confidential information of > > Starent Networks, Corp. The information transmitted may not be used to > > create or change any contractual obligations of Starent Networks, Corp. > > Any review, retransmission, dissemination or other use of, or taking of > > any action in reliance upon this e-mail and its attachments by persons > > or entities other than the intended recipient is prohibited. If you are > > not the intended recipient, please notify the sender immediately -- by > > replying to this message or by sending an email to > > postmaster@starentnetworks.com -- and destroy all copies of this message > > and any attachments without reading or disclosing their contents. Thank > > you." > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Sep 22 07:10:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQivM-0007i1-Ha; Fri, 22 Sep 2006 07:10:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQivL-0007ht-PX; Fri, 22 Sep 2006 07:10:27 -0400 Received: from [59.145.147.70] (helo=ricky.india.internal.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQivJ-0007B4-Uo; Fri, 22 Sep 2006 07:10:27 -0400 X-Anti-Virus: Cyberoam Anti-Virus for SMTP; Kaspersky 5.5.3/RELEASE, bases: 22092006 #212396; status: clean Received: from klk ([172.16.2.32]) by ricky.india.internal.net (8.12.10/8.11.6) with ESMTP id k8MB51BI011893; Fri, 22 Sep 2006 16:35:01 +0530 From: "kamakshi" To: Subject: RE: [Dime] Base Accounting Date: Fri, 22 Sep 2006 16:42:14 +0530 Message-ID: <000801c6de37$f58a0ab0$200210ac@klk> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: X-SpamTest-Info: Profile: Formal (548/060921) X-SpamTest-Info: Profile: Detect Hard (4/030526) X-SpamTest-Info: Profile: SysLog X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [0124], KAS/Release X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: mip6@ietf.org, dime@ietf.org, charliep@iprg.nokia.com, hannes.tschofenig@siemens.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi All, It is mentioned in the rc3588 that the Accounting state machine is server directed and it uses Accounting-Realtime-Required AVP to instruct the client how it has to operate(when the transfer of records is delayed or not delivered). But the RFC does not specify under what conditions are this AVP values set to DELIVER_AND_GRANT, GRANT_AND_STORE or GRANT_AND_LOSE. The Rf application doesn't use this AVP and the NASREQ application also doesn't define how this has to be set. Is there any other application which tells how it has to used at the server side ? Thanks, Kamakshi L K _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Sep 22 09:46:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQlMR-0001Xa-Aq; Fri, 22 Sep 2006 09:46:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQlMQ-0001XV-BS for dime@ietf.org; Fri, 22 Sep 2006 09:46:34 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQlMO-0006ue-VZ for dime@ietf.org; Fri, 22 Sep 2006 09:46:34 -0400 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k8MDjkid087411; Fri, 22 Sep 2006 09:45:47 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Date: Fri, 22 Sep 2006 09:45:49 -0400 To: Hannes Tschofenig Subject: Re: Efficiency: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type Message-ID: <20060922134549.GC610@steelhead> References: <44F75D9B.6030808@gmx.net> <20060908141021.GD23183@steelhead> <45123A06.1010106@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <45123A06.1010106@gmx.net> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 62 X-Spam-Score: -2.4 (--) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org On Thu, Sep 21, 2006 at 03:06:46AM -0400, Hannes Tschofenig wrote: > Hi Yoshi, > > the drawback is that this approach is less efficient. > If we see this in relationship with RADIUS I already see people saying > that the Diameter approach is a performance hit. But can't EAP application and MIP6 application be executed in parallel? I believe parallel run is possible once after NAS or HA obtains user's identity or equivalent from EAP application. Yoshihiro Ohba > > Still, I think it is worth investigating in the current document. > > Ciao > Hannes > > Yoshihiro Ohba schrieb: > > I forgot to explicitly answer to this question. > > > > My answer is (1) for both (a) and (b), but define MIP6 application as > > a totally separate authprization application from EAP and NASREQ (For > > more details and reasons, please see related discussion with Julien). > > > > Regards, > > Yoshihiro Ohba > > > > > > > > On Fri, Sep 01, 2006 at 12:07:23AM +0200, Hannes Tschofenig wrote: > >> Hi all, > >> > >> we have had long discussions about the App-ID vs. Service-Type usage for > >> Diameter MIPv6 Bootstrapping. > >> > >> It is time to see what the group thinks. Please indicate whether you > >> prefer (1) an App-ID or (2) a Service-Type solution for > >> > >> (a) NAS-to-AAAH communication (as required by the integrated scenario; > >> as one part of the solution component) > >> > >> (b) HA-to-AAAH communication (as used by the split scenario and the > >> integrated scenario) > >> > >> It might be useful to state a reason for your decision. > >> > >> Please also indicate whether some aspects are still unclear to you. > >> > >> Ciao > >> Hannes > >> > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www1.ietf.org/mailman/listinfo/dime > >> > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Sep 25 15:58:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRwaQ-0006Q3-Ue; Mon, 25 Sep 2006 15:57:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRwaQ-0006O9-6o; Mon, 25 Sep 2006 15:57:54 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRwaO-0004Wk-Mh; Mon, 25 Sep 2006 15:57:54 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id DEB069004B; Mon, 25 Sep 2006 15:57:47 -0400 (EDT) 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 01305-02; Mon, 25 Sep 2006 15:57:47 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP; Mon, 25 Sep 2006 15:57:47 -0400 (EDT) X-MessageTextProcessor: DisclaimIt (2.70.271) [Starent Networks Corp.] Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Sep 2006 15:57:42 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] renaming and re-scoping of the Dime MIP6 I-Ds Date: Mon, 25 Sep 2006 15:57:42 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D78373E0@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] renaming and re-scoping of the Dime MIP6 I-Ds thread-index: AcbdX7P5aSeU4MqzT226plZ5ncJEsgDeYeKA From: "Chowdhury, Kuntal" To: "Gerardo Giaretta" , "Vijay Devarapalli" Importance: normal Priority: normal X-OriginalArrivalTime: 25 Sep 2006 19:57:42.0906 (UTC) FILETIME=[DCD5BDA0:01C6E0DC] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: mip6@ietf.org, dime@ietf.org, charliep@iprg.nokia.com, hannes.tschofenig@siemens.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Gerardo, Vijay, Thanks for your comments. We will move ahead accordingly. -Kuntal > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > Sent: Thursday, September 21, 2006 4:24 AM > To: Vijay Devarapalli > Cc: Chowdhury, Kuntal; mip6@ietf.org; dime@ietf.org; > charliep@iprg.nokia.com; hannes.tschofenig@siemens.com > Subject: Re: [Dime] renaming and re-scoping of the Dime MIP6 I-Ds >=20 > > Chowdhury, Kuntal wrote: > > > We had an offline discussion on the scope of the two Diameter mip6 > > > bootstrapping I-Ds that are being defined at this time. The > > > current titles and scopes of the documents seem to convey inaccurate > > > information of the actual intent of each of them. For example, the > mip6 > > > bootstrapping solutions as developed in MIP6 WG need the Diameter > > > components for the following interfaces: > > > > > > NAS-HAAA: Integrated scenario > > > > this would be for MIP6 service authorization + MIP6 > > HA/HoA information, correct? > > > > > HA-HAAA: Integrated and Split scenarios > > > > this would include authentication + authorization, > > correct? > > >=20 > In general this will define a solution that takes into account all > goals listed in draft-ietf-mip6-aaa-ha-goals (e.g. authorization, > session termination, etc.) >=20 > --Gerardo >=20 > > Vijay > > > > > > > > > > > > > > What we need to do in Dime WG is to define these two components. The > > > current structures of the drafts introduce unnecessary dependencies > > > between them by focusing on the individual mip6 bootstrapping > scenarios > > > rather than the actual purpose i.e. defining the Diameter (AAA) > > > components needed for both the mip6 bootstrapping solutions. Moreover, > > > the HA - HAAA interface can be defined in such a way that it covers > mip6 > > > in general. > > > > > > > > > > > > So, the suggestion is to rename and re-scope the documents as follows: > > > > > > > > > > > > 1. Filename =3D dime-mip6-nas-aaa-interface: Title =3D The NAS - = HAAA > > > interface for mip6 bootstrapping > > > > > > 2. Filename =3D dime-mip6-ha-aaa-interface: Title =3D The HA - = HAAA > > > interface for mip6 > > > > > > Please let us know your comments. > > > > > > Regards, > > > > > > Kuntal > > > > > > "This email message and any attachments are confidential information > of > > > Starent Networks, Corp. The information transmitted may not be used to > > > create or change any contractual obligations of Starent Networks, Corp. > > > Any review, retransmission, dissemination or other use of, or taking > of > > > any action in reliance upon this e-mail and its attachments by persons > > > or entities other than the intended recipient is prohibited. If you > are > > > not the intended recipient, please notify the sender immediately -- by > > > replying to this message or by sending an email to > > > postmaster@starentnetworks.com -- and destroy all copies of this > message > > > and any attachments without reading or disclosing their contents. > Thank > > > you." > > > > > > > > > ---------------------------------------------------------------------- > -- > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Sep 25 16:08:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRwl3-000433-2j; Mon, 25 Sep 2006 16:08:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRwl1-00042u-GW; Mon, 25 Sep 2006 16:08:51 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRwl0-0005mt-10; Mon, 25 Sep 2006 16:08:51 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 62A149004A; Mon, 25 Sep 2006 16:08:46 -0400 (EDT) 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 01504-02; Mon, 25 Sep 2006 16:08:45 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP; Mon, 25 Sep 2006 16:08:45 -0400 (EDT) X-MessageTextProcessor: DisclaimIt (2.70.271) [Starent Networks Corp.] Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Sep 2006 16:08:45 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] renaming and re-scoping of the Dime MIP6 I-Ds Date: Mon, 25 Sep 2006 16:08:45 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D78373E1@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] renaming and re-scoping of the Dime MIP6 I-Ds thread-index: AcbdK/+txGsK9O1+TGurqivbphKYbwDsOKVw From: "Chowdhury, Kuntal" To: "Vijay Devarapalli" Importance: normal Priority: normal X-OriginalArrivalTime: 25 Sep 2006 20:08:45.0503 (UTC) FILETIME=[67C604F0:01C6E0DE] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: mip6@ietf.org, dime@ietf.org, charliep@iprg.nokia.com, hannes.tschofenig@siemens.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Wednesday, September 20, 2006 10:13 PM > To: Chowdhury, Kuntal > Cc: dime@ietf.org; mip6@ietf.org; charliep@iprg.nokia.com; > hannes.tschofenig@siemens.com > Subject: Re: [Dime] renaming and re-scoping of the Dime MIP6 I-Ds >=20 > sounds like a good idea. >=20 > Chowdhury, Kuntal wrote: > > We had an offline discussion on the scope of the two Diameter mip6 > > bootstrapping I-Ds that are being defined at this time. The > > current titles and scopes of the documents seem to convey inaccurate > > information of the actual intent of each of them. For example, the mip6 > > bootstrapping solutions as developed in MIP6 WG need the Diameter > > components for the following interfaces: > > > > NAS-HAAA: Integrated scenario >=20 > this would be for MIP6 service authorization + MIP6 > HA/HoA information, correct? >=20 [KC>] AFAIK, the NAS is not involved in MIP6 service authorization. Hence NAS-HAAA interface won't be used for this purpose. But it will certainly be used for bootstrapping MIP6 parameters e.g. HA address. > > HA-HAAA: Integrated and Split scenarios >=20 > this would include authentication + authorization, > correct? >=20 [KC>] Yes. It may also include accounting messages for MIP6 service. > Vijay >=20 > > > > > > > > What we need to do in Dime WG is to define these two components. The > > current structures of the drafts introduce unnecessary dependencies > > between them by focusing on the individual mip6 bootstrapping scenarios > > rather than the actual purpose i.e. defining the Diameter (AAA) > > components needed for both the mip6 bootstrapping solutions. Moreover, > > the HA - HAAA interface can be defined in such a way that it covers mip6 > > in general. > > > > > > > > So, the suggestion is to rename and re-scope the documents as follows: > > > > > > > > 1. Filename =3D dime-mip6-nas-aaa-interface: Title =3D The NAS - = HAAA > > interface for mip6 bootstrapping > > > > 2. Filename =3D dime-mip6-ha-aaa-interface: Title =3D The HA - HAAA > > interface for mip6 > > > > Please let us know your comments. > > > > Regards, > > > > Kuntal > > > > "This email message and any attachments are confidential information of > > Starent Networks, Corp. The information transmitted may not be used to > > create or change any contractual obligations of Starent Networks, Corp. > > Any review, retransmission, dissemination or other use of, or taking of > > any action in reliance upon this e-mail and its attachments by persons > > or entities other than the intended recipient is prohibited. If you are > > not the intended recipient, please notify the sender immediately -- by > > replying to this message or by sending an email to > > postmaster@starentnetworks.com -- and destroy all copies of this message > > and any attachments without reading or disclosing their contents. Thank > > you." > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 26 11:31:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSEuR-0008Bl-RI; Tue, 26 Sep 2006 11:31:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSEuQ-0008Bd-II for dime@ietf.org; Tue, 26 Sep 2006 11:31:46 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSEuP-0001Rj-9i for dime@ietf.org; Tue, 26 Sep 2006 11:31:46 -0400 Received: by ug-out-1314.google.com with SMTP id 72so550487ugd for ; Tue, 26 Sep 2006 08:31:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=Oij7b7Akj7fBsxTkzucuh9I8EAd2Htz0uJKzRvwwIA63XeIc+bXQrhfDbDJOmfyOUPkLyd0RjtYkShGvYuRlL//PQCp253tBcllsXVfarpCfijNGJO2ok1CnCX4921bXzBpL98jnq0drd58q0qU17edcxU/A3mSOCo8htM4UNAU= Received: by 10.67.101.8 with SMTP id d8mr783647ugm; Tue, 26 Sep 2006 08:31:44 -0700 (PDT) Received: by 10.67.31.14 with HTTP; Tue, 26 Sep 2006 08:31:44 -0700 (PDT) Message-ID: Date: Tue, 26 Sep 2006 11:31:44 -0400 From: "Ajay Kolambekar" To: dime@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [Dime] Using Redirect agents in application servers X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi All, I have one query related to usage of Redirect Agent from application server (AS) What should be the Hop-By-Hop id while sending message to the HSS indicated by the response received from SLF in Redirect-Host AVP, is that should be same as the one is sent in the request sent to SLF or it should be again a unique identifier. AS SLF HSS | Req HbH = "X" | | |--------------------------------------------->| | | | | | Resp. HbH = "X" | | | Redirect-Host="HSS" | | |<---------------------------------------------| | | | | Req HbH=??????? | |-------------------------------------------------------------------------->| HbH shoud be "X" or some unique value Regards, Ajay _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 27 00:46:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSRJu-0007fY-Of; Wed, 27 Sep 2006 00:46:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSRJu-0007bL-5P for dime@ietf.org; Wed, 27 Sep 2006 00:46:54 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSRJs-0002zT-8Q for dime@ietf.org; Wed, 27 Sep 2006 00:46:54 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J6800H5EJ12Y6@szxga02-in.huawei.com> for dime@ietf.org; Wed, 27 Sep 2006 12:55:50 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J6800314J124C@szxga02-in.huawei.com> for dime@ietf.org; Wed, 27 Sep 2006 12:55:50 +0800 (CST) Received: from huawei1515 ([10.18.4.60]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J6800D15IEC1S@szxml03-in.huawei.com> for dime@ietf.org; Wed, 27 Sep 2006 12:42:16 +0800 (CST) Date: Wed, 27 Sep 2006 10:06:55 +0530 From: Rajith R Subject: RE: [Dime] Using Redirect agents in application servers In-reply-to: To: 'Ajay Kolambekar' , dime@ietf.org Message-id: <001201c6e1ee$902cf7d0$3c04120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcbhgPnStww0N8ylTFqhvwNmIseo5QAbIk0g X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rajithr@huawei.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi In my opinion it is better to be different. Otherwise there could be some problems in some situations; for eg: consider a cross over of a fail(ed) over request from AS and the redirect response from SLF. (I assume for the failed over request, most implementations use the same hop id as the original). If the same hop id is used for the redirected request, then the response to the (crossed over) duplicate request or the response to the redirected request may result in a transaction match. To avoid this ambiguity (may be there are more), it is better to use a different hop id in the redirected request. Rajith >-----Original Message----- >From: Ajay Kolambekar [mailto:ajaykolambekar@gmail.com] >Sent: Tuesday, September 26, 2006 9:02 PM >To: dime@ietf.org >Subject: [Dime] Using Redirect agents in application servers > >Hi All, > >I have one query related to usage of Redirect Agent from >application server (AS) What should be the Hop-By-Hop id while >sending message to the HSS indicated by the response received >from SLF in Redirect-Host AVP, is that should be same as the >one is sent in the request sent to SLF or it should be again a >unique identifier. > > AS SLF HSS > | Req HbH = "X" | | > |--------------------------------------------->| > | > | | > | > | Resp. HbH = "X" | | > | Redirect-Host="HSS" | | > |<---------------------------------------------| > | > | > | > | Req HbH=??????? | > >|-------------------------------------------------------------- >------------>| > >HbH shoud be "X" or some unique value > >Regards, >Ajay > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 27 03:07:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSTVW-0000yb-Tk; Wed, 27 Sep 2006 03:07:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSTVV-0000yP-8k for DiME@ietf.org; Wed, 27 Sep 2006 03:07:01 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSTVT-0005Mu-Vv for DiME@ietf.org; Wed, 27 Sep 2006 03:07:01 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J6800B7SPLTAO@szxga02-in.huawei.com> for DiME@ietf.org; Wed, 27 Sep 2006 15:17:53 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J680035XPLS4L@szxga02-in.huawei.com> for DiME@ietf.org; Wed, 27 Sep 2006 15:17:53 +0800 (CST) Received: from CMTEST6 ([10.70.149.108]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J6800DB9PRZLR@szxml01-in.huawei.com>; Wed, 27 Sep 2006 15:21:35 +0800 (CST) Date: Wed, 27 Sep 2006 14:59:00 +0800 From: Tina TSOU Subject: Re: [Dime] My Summary of the MIPv6 Bootstrapping Discussion To: DiME@ietf.org, Hannes Tschofenig Message-id: <00ca01c6e202$69326480$6c95460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=ISO-8859-15 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <45123A23.7090405@gmx.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, Regarding Diameter MIPv6 work, in my understanding, (1) If we consider NAS and HA authenticate/ authorize to different AAA Servers, I suggest to define a new Application ID for NAS<-->AAA Server, and define another new Application ID for HA<-->AAA Server. (2)If we consider NAS and HA authenticate/ authorize to a same AAA Server, I suggest to only define MIPv6 related AVPs in MIPv6 Appl. Document. For case 1 NAS<-->AAA Server, I suggest to use EAP Appl. (RFC4072), carry added MIPv6 related AVPs. RFC4072 itself supports AVP extension, so it could be considered as not modifying RFC4072. For case 1 HA<-->AAA Server, I suggest to use NAS Appl. (RFC4005), carry added MIPv6 related AVPs. RFC4005 itself supports AVP extension, so it could be considered as not modifying RFC4005. (1) can bring more flexibility, however we have risk not stop extending Application ID. If in the real world, the AAA servers for NAS and HA are the same one, (2) is better. Regarding Diameter QoS work, in my understanding, QoS appl. is needed for every call/session procedure, MIPv6 appl. is only needed for the UE registration procedure. If we don't combine QoS appl., it might cause signaling delay; hence the response to user call behaves slowly. So QoS appl. is strongly suggested to be piggybacking with other procedure. And even if MIPv6 is not piggybacking with other procedure, from the user perspective, it represents a bit slower registration, users could live with it. B. R. Tina Messengers: MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU Jabber: tina@jabber.org ----- Original Message ----- From: "Hannes Tschofenig" To: Sent: Thursday, September 21, 2006 3:07 PM Subject: [Dime] My Summary of the MIPv6 Bootstrapping Discussion > Hi all, > > let me try to summarize what was discussed recently with regard to MIPv6 > bootstrapping. > > We agreed that it would be useful to differentiate the following two cases: > > (1) NAS<->AAA Server > > (2) HA<->AAA Server > > [We need to change the titles of our document a bit.] > > With regard to (1) a number of folks were in favor of introducing a > capability mechanism that allows the NAS to indicate that it supports a > certain functionality. As Avi said, this newly required AVP would be > optional to use and optional to understand. If a NAS does support > bootstrapping for MIPv6 it includes the attribute in AR (NASREQ or EAP). > If it lands at a server that understands this attribute, then it will > respond correctly if it wants to bootstrap MIPv6. If it lands at a > server that doesn't understand the attribute then bootstrapping via AAA > will not occur. > > Defining a new AppID is not needed and consequently the Diameter > NASREQ/EAP message would hit the same server that also supports MIPv6 > bootstrapping. > > As an alternative, Yoshi suggested to go along the same approach as in > (2). The drawback would be the performance hit. This would, however, > allow the two servers to be different (if this is at all useful). > > With regard to (2) Yoshi suggested a new AppID to be used for > Authorization and Accounting and not to reuse the EAP/NASREQ ABNF. > As Julien wrote, we are able to continue to use Diameter EAP for > Authentication. Thus, the HA will use Diameter EAP with the AVP > Auth-Request-Type set to AUTHENTICATE_ONLY and then the HA will use this > MIP6 Application for Authorization/Accounting of the Mobile IPv6 service. > > This would avoid to update the application if RFC 4072 is updated and > this could be a way to proceed if other applications need EAP for > Authentication but have different needs for the Authorization and > Accounting part. > > Again, there is a performance disadvantage if a separate exchange is > used instead of piggybacking functionality. > > [I am still not sure how this nicely interworks with the QoS work we do > in the group. That's for further investigation.] > > I think we made progress in our discussions. Julien has initiated a poll > to see what todo regarding (2) and whether the group likes Yoshi's > suggestion. For (1) I got the impression that the focus currently is > more on the capability exchange but we might need to initiate another > poll there as well. > > Btw, the conclusions we make in this discussion can also be reused for > the Diameter QoS work. > > Ciao > Hannes > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 27 04:09:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSUU3-0000VF-6t; Wed, 27 Sep 2006 04:09:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSUU1-0000U8-V0 for DiME@ietf.org; Wed, 27 Sep 2006 04:09:33 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GSUU0-0007k4-Dq for DiME@ietf.org; Wed, 27 Sep 2006 04:09:33 -0400 Received: (qmail invoked by alias); 27 Sep 2006 08:09:31 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp045) with SMTP; 27 Sep 2006 10:09:31 +0200 X-Authenticated: #29516787 Message-ID: <451A31BA.20702@gmx.net> Date: Wed, 27 Sep 2006 10:09:30 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Tina TSOU Subject: Re: [Dime] My Summary of the MIPv6 Bootstrapping Discussion References: <45123A23.7090405@gmx.net> <00ca01c6e202$69326480$6c95460a@china.huawei.com> In-Reply-To: <00ca01c6e202$69326480$6c95460a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: DiME@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tina, thanks for your response. Tina TSOU schrieb: > Hi all, Regarding Diameter MIPv6 work, in my understanding, (1) If we > consider NAS and HA authenticate/ authorize to different AAA Servers, > I suggest to define a new Application ID for NAS<-->AAA Server, and > define another new Application ID for HA<-->AAA Server. So far everyone was questioning the need to use different servers. > > (2)If we consider NAS and HA authenticate/ authorize to a same AAA > Server, I suggest to only define MIPv6 related AVPs in MIPv6 Appl. > Document. For case 1 NAS<-->AAA Server, I suggest to use EAP Appl. > (RFC4072), carry added MIPv6 related AVPs. RFC4072 itself supports > AVP extension, so it could be considered as not modifying RFC4072. Folks raised two issues: * Are these attributes mandatory? So far we said "no". * Do we need something like a capability exchange? I saw a few "yes". > For case 1 HA<-->AAA Server, I suggest to use NAS Appl. (RFC4005), > carry added MIPv6 related AVPs. RFC4005 itself supports AVP > extension, so it could be considered as not modifying RFC4005. If you only add a non-mandatory AVP then you don't need to touch NASREQ or EAP at all. > > (1) can bring more flexibility, however we have risk not stop > extending Application ID. If in the real world, the AAA servers for > NAS and HA are the same one, (2) is better. That's also the conclusion folks came to on the mailing list (from what I can tell). > > Regarding Diameter QoS work, in my understanding, QoS appl. is needed > for every call/session procedure, MIPv6 appl. is only needed for the > UE registration procedure. If we don't combine QoS appl., it might > cause signaling delay; hence the response to user call behaves > slowly. So QoS appl. is strongly suggested to be piggybacking with > other procedure. And even if MIPv6 is not piggybacking with other > procedure, from the user perspective, it represents a bit slower > registration, users could live with it. I am not so sure I understand what you mean. I guess you need to provide a little bit more details particularly with regard to the scenario you have in mind. Ciao Hannes > B. R. Tina Messengers: MSN: tinatsou6@hotmail.com Yahoo: tina_tsou > Skype: tinaTSOU Jabber: tina@jabber.org > > ----- Original Message ----- From: "Hannes Tschofenig" > To: Sent: Thursday, > September 21, 2006 3:07 PM Subject: [Dime] My Summary of the MIPv6 > Bootstrapping Discussion > > >> Hi all, >> >> let me try to summarize what was discussed recently with regard to >> MIPv6 bootstrapping. >> >> We agreed that it would be useful to differentiate the following >> two cases: >> >> (1) NAS<->AAA Server >> >> (2) HA<->AAA Server >> >> [We need to change the titles of our document a bit.] >> >> With regard to (1) a number of folks were in favor of introducing a >> capability mechanism that allows the NAS to indicate that it >> supports a certain functionality. As Avi said, this newly required >> AVP would be optional to use and optional to understand. If a NAS >> does support bootstrapping for MIPv6 it includes the attribute in >> AR (NASREQ or EAP). If it lands at a server that understands this >> attribute, then it will respond correctly if it wants to bootstrap >> MIPv6. If it lands at a server that doesn't understand the >> attribute then bootstrapping via AAA will not occur. >> >> Defining a new AppID is not needed and consequently the Diameter >> NASREQ/EAP message would hit the same server that also supports >> MIPv6 bootstrapping. >> >> As an alternative, Yoshi suggested to go along the same approach as >> in (2). The drawback would be the performance hit. This would, >> however, allow the two servers to be different (if this is at all >> useful). >> >> With regard to (2) Yoshi suggested a new AppID to be used for >> Authorization and Accounting and not to reuse the EAP/NASREQ ABNF. >> As Julien wrote, we are able to continue to use Diameter EAP for >> Authentication. Thus, the HA will use Diameter EAP with the AVP >> Auth-Request-Type set to AUTHENTICATE_ONLY and then the HA will use >> this MIP6 Application for Authorization/Accounting of the Mobile >> IPv6 service. >> >> This would avoid to update the application if RFC 4072 is updated >> and this could be a way to proceed if other applications need EAP >> for Authentication but have different needs for the Authorization >> and Accounting part. >> >> Again, there is a performance disadvantage if a separate exchange >> is used instead of piggybacking functionality. >> >> [I am still not sure how this nicely interworks with the QoS work >> we do in the group. That's for further investigation.] >> >> I think we made progress in our discussions. Julien has initiated a >> poll to see what todo regarding (2) and whether the group likes >> Yoshi's suggestion. For (1) I got the impression that the focus >> currently is more on the capability exchange but we might need to >> initiate another poll there as well. >> >> Btw, the conclusions we make in this discussion can also be reused >> for the Diameter QoS work. >> >> Ciao Hannes >> >> _______________________________________________ DiME mailing list >> DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime >> > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 27 09:17:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSZIG-0004pX-Gw; Wed, 27 Sep 2006 09:17:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSZIE-0004pK-HN for dime@ietf.org; Wed, 27 Sep 2006 09:17:42 -0400 Received: from outgoing.persistent.co.in ([202.54.11.87] helo=bmapps.persistent.co.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSZID-0006bt-0r for dime@ietf.org; Wed, 27 Sep 2006 09:17:42 -0400 Received: from mail.persistent.co.in (unknown [10.12.0.1]) by bmapps.persistent.co.in (Symantec Mail Security) with ESMTP id 0631A420; Wed, 27 Sep 2006 18:46:55 +0530 (IST) Received: from PS2838 ([10.11.25.65]) by mail.persistent.co.in (MOS 3.8.1-FCS) with ESMTP id ASL34735 (AUTH rohan_hathiwala); Wed, 27 Sep 2006 18:46:54 +0530 (IST) From: Rohan Hathiwala Organization: Persistent Systems Date: Wed, 27 Sep 2006 18:51:14 +0530 User-Agent: KMail/1.7 To: dime@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200609271851.14114.rohan_hathiwala@persistent.co.in> X-Junkmail-Whitelist: YES (by domain whitelist at mail6.persistent.co.in) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: diameter-developers@lists.sourceforge.net Subject: [Dime] Doubt regarding behavior of redirect agents. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, When a redirect agent receives a diameter request message should it create a new diameter message where a) The Request flag is cleared. b) The Error flag and set. c) Result-Code AVP is set to AAA_REDIRECT_INDICATION. d) Redirect-Host AVP is added. or should the redirect agent take the original request message and do the following. a) Clear the Request flag. b) Set the Error flag. c) Result-Code AVP is set to AAA_REDIRECT_INDICATION. d) Redirect-Host AVP is added. e) Existing AVP's in the request message are preserved in answer. Section 6.1.7 of Diameter RFC 3588 does not=EE=80=80clarify which of the abo= ve implementation would be correct. We would greatly appreciate if someone could throw some light on this. Does anyone have an idea of what the current diameter implementations support. Regards, Rohan Hathiwala. DISCLAIMER=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= This e-mail may contain privileged and confidential information which is the= property of Persistent Systems Pvt. Ltd. It is intended only for the use of= the individual or entity to which it is addressed. If you are not the inten= ded recipient, you are not authorized to read, retain, copy, print, distribu= te or use this message. If you have received this communication in error, pl= ease notify the sender and delete all copies of this message. Persistent Sys= tems Pvt. Ltd. does not accept any liability for virus infected mails. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 27 09:30:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSZUr-0002uU-GM; Wed, 27 Sep 2006 09:30:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSZUq-0002uP-OR for dime@ietf.org; Wed, 27 Sep 2006 09:30:44 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSZUp-0000nb-DR for dime@ietf.org; Wed, 27 Sep 2006 09:30:44 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 5601B6B638 for ; Wed, 27 Sep 2006 09:30:39 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k8RDUcV0009578 for ; Wed, 27 Sep 2006 09:30:38 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Dime] Doubt regarding behavior of redirect agents. Date: Wed, 27 Sep 2006 09:29:27 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-Reply-To: <200609271851.14114.rohan_hathiwala@persistent.co.in> Importance: Normal Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Rohan, I think both of them are compliant with the specification. 6.1.7 = mandates that E-bit needs to be set for redirect answers. This means the = grammar in 7.2 needs to be followed and if one chooses to do so, I think = *[AVP] would justify adding AVPs present in the request. >From client point of view, I wouldn't rely on redirect answer containing = all request AVPs though. Thanks, Tolga > -----Original Message----- > From: Rohan Hathiwala [mailto:rohan_hathiwala@persistent.co.in] > Sent: Wednesday, September 27, 2006 9:21 AM > To: dime@ietf.org > Cc: diameter-developers@lists.sourceforge.net > Subject: [Dime] Doubt regarding behavior of redirect agents. >=20 >=20 > Hi, > When a redirect agent receives a diameter request message should=20 > it create a > new diameter message where > a) The Request flag is cleared. > b) The Error flag and set. > c) Result-Code AVP is set to AAA_REDIRECT_INDICATION. > d) Redirect-Host AVP is added. >=20 > or should the redirect agent take the original request message and do = the > following. >=20 > a) Clear the Request flag. > b) Set the Error flag. > c) Result-Code AVP is set to AAA_REDIRECT_INDICATION. > d) Redirect-Host AVP is added. > e) Existing AVP's in the request message are preserved in answer. >=20 > Section 6.1.7 of Diameter RFC 3588 does not=EE=80=80clarify which of = the above > implementation would be correct. > We would greatly appreciate if someone could throw some light on=20 > this. Does > anyone have an idea of what the current > diameter implementations support. >=20 > Regards, > Rohan Hathiwala. >=20 > DISCLAIMER > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > This e-mail may contain privileged and confidential information=20 > which is the property of Persistent Systems Pvt. Ltd. It is=20 > intended only for the use of the individual or entity to which it=20 > is addressed. If you are not the intended recipient, you are not=20 > authorized to read, retain, copy, print, distribute or use this=20 > message. If you have received this communication in error, please=20 > notify the sender and delete all copies of this message.=20 > Persistent Systems Pvt. Ltd. does not accept any liability for=20 > virus infected mails. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 28 03:50:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSqfD-0002YN-I3; Thu, 28 Sep 2006 03:50:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSqfB-0002YD-Un for dime@ietf.org; Thu, 28 Sep 2006 03:50:33 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GSqfA-0002yf-IF for dime@ietf.org; Thu, 28 Sep 2006 03:50:33 -0400 Received: (qmail invoked by alias); 28 Sep 2006 07:50:30 -0000 Received: from ip-80-226-153-60.vodafone-net.de (EHLO [10.226.213.171]) [80.226.153.60] by mail.gmx.net (mp015) with SMTP; 28 Sep 2006 09:50:30 +0200 X-Authenticated: #29516787 Message-ID: <451B7EC0.70801@gmx.net> Date: Thu, 28 Sep 2006 09:50:24 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: mip6@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: dime@ietf.org Subject: [Dime] Impact of RFC 4285 for Diameter MIP6 Bootstrapping Work X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, in the DIME working group we are currently producing documents that relate to the backend solution of the * Integrated Scenario draft-ietf-mip6-bootstrapping-integrated-dhc-01 * Split Scenario draft-ietf-mip6-bootstrapping-split-02 Now, the question came up whether we have to consider RFC 4285 ('Authentication Protocol for Mobile IPv6') for our work as well. Thoughts? Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 28 04:59:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSrjQ-0000CG-N9; Thu, 28 Sep 2006 04:59:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSrjP-0000AA-Su for dime@ietf.org; Thu, 28 Sep 2006 04:58:59 -0400 Received: from wx-out-0506.google.com ([66.249.82.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSrjO-00031k-LF for dime@ietf.org; Thu, 28 Sep 2006 04:58:59 -0400 Received: by wx-out-0506.google.com with SMTP id t4so273988wxc for ; Thu, 28 Sep 2006 01:58:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=RFvP8ylCx32vO/4SKY1v2jjpWUkaCqURcuoAC6d1eMsy/vDM9oPwC0A5w73iti6m6HHz7BtUy2v0ox9OMnhDKsOFqkh3f6P543oXtsMawTlbWzhw4z5p5+QJvFMbRrkC4erdfigc+MmKysW/FhwMWiQLAiHjTo/jMr9Q5es6bdU= Received: by 10.90.94.2 with SMTP id r2mr667757agb; Thu, 28 Sep 2006 01:58:58 -0700 (PDT) Received: by 10.90.91.17 with HTTP; Thu, 28 Sep 2006 01:58:58 -0700 (PDT) Message-ID: <5e2406980609280158x6fbbaf2bpa2c6761963957061@mail.gmail.com> Date: Thu, 28 Sep 2006 10:58:58 +0200 From: "Julien Bournelle" To: dime@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Hannes Tschofenig Subject: [Dime] DIME MIP6 HA-to-AAAH support: next steps X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, based on recent discussions on the ML, we'll move forward with the approach proposed by yoshi: 4072 for EAP authentication + new Application for mip6 Authz/Acc. FYI, this is the TOC on which we plan to work. We are not sure to finally include the section 5.1.2. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Mobile IPv6 Bootstrapping overview . . . . . . . . . . . . . . 3 3.1. The split scenario . . . . . . . . . . . . . . . . . . . . 3 3.2. The Integrated Scenario . . . . . . . . . . . . . . . . . . 3 4. Diameter MIP6 HA-to-AAAH overview . . . . . . . . . . . . . . . 3 5. Diameter Mobile IPv6 HA-to-AAAH support . . . . . . . . . . . . 3 5.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 3 5.1.1. HA with EAP support . . . . . . . . . . . . . . . . . . 3 (4072 with AUTHENTICATE_ONLY) 5.1.2. HA without EAP support . . . . . . . . . . . . . . . . 3 5.2. Authorization . . . . . . . . . . . . . . . . . . . . . . . 3 (define 2 new messages for this and may be some new AVPs) 5.3. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 3 5.4. Mobile IPv6 Session Management . . . . . . . . . . . . . . 4 5.4.1. Session-Termination Command . . . . . . . . . . . . . . 4 5.4.2. Abort-Session Command . . . . . . . . . . . . . . . . . 4 6. Command-Code Values . . . . . . . . . . . . . . . . . . . . . . 4 6.1. MIP6-Authorization-Request . . . . . . . . . . . . . . . . 4 6.2. MIP6-Authorization-Answer . . . . . . . . . . . . . . . . . 4 7. Result-Code AVPs . . . . . . . . . . . . . . . . . . . . . . . 4 8. Mandatory AVPs . . . . . . . . . . . . . . . . . . . . . . . . 4 9. Accounting AVPs . . . . . . . . . . . . . . . . . . . . . . . . 4 10. AVP Occurence Tables . . . . . . . . . . . . . . . . . . . . . 4 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 12. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 14.1. Normative References . . . . . . . . . . . . . . . . . . . 5 14.2. Informative References . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . . . 7 regards, Julien _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 28 21:49:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT7Vb-0000GH-0k; Thu, 28 Sep 2006 21:49:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT7VZ-0000A7-PP for DiME@ietf.org; Thu, 28 Sep 2006 21:49:45 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT7VY-0001Hd-JP for DiME@ietf.org; Thu, 28 Sep 2006 21:49:45 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J6C00B8Q0KTNM@szxga02-in.huawei.com> for DiME@ietf.org; Fri, 29 Sep 2006 10:07:41 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J6C00HLF0KS4U@szxga02-in.huawei.com> for DiME@ietf.org; Fri, 29 Sep 2006 10:07:41 +0800 (CST) Received: from CMTEST6 ([10.70.149.108]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J6C00HO30K31O@szxml02-in.huawei.com>; Fri, 29 Sep 2006 10:07:16 +0800 (CST) Date: Fri, 29 Sep 2006 09:48:49 +0800 From: Tina TSOU Subject: Re: [Dime] My Summary of the MIPv6 Bootstrapping Discussion To: Hannes Tschofenig Message-id: <007401c6e369$689a6d20$6c95460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=ISO-8859-15 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <45123A23.7090405@gmx.net> <00ca01c6e202$69326480$6c95460a@china.huawei.com> <451A31BA.20702@gmx.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: DiME@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Hannes, See in line(: B. R. Tina ----- Original Message ----- From: "Hannes Tschofenig" To: "Tina TSOU" Cc: Sent: Wednesday, September 27, 2006 4:09 PM Subject: Re: [Dime] My Summary of the MIPv6 Bootstrapping Discussion > Hi Tina, > > thanks for your response. > > Tina TSOU schrieb: > > Hi all, Regarding Diameter MIPv6 work, in my understanding, (1) If we > > consider NAS and HA authenticate/ authorize to different AAA Servers, > > I suggest to define a new Application ID for NAS<-->AAA Server, and > > define another new Application ID for HA<-->AAA Server. > > So far everyone was questioning the need to use different servers. > > > > > > (2)If we consider NAS and HA authenticate/ authorize to a same AAA > > Server, I suggest to only define MIPv6 related AVPs in MIPv6 Appl. > > Document. For case 1 NAS<-->AAA Server, I suggest to use EAP Appl. > > (RFC4072), carry added MIPv6 related AVPs. RFC4072 itself supports > > AVP extension, so it could be considered as not modifying RFC4072. > > Folks raised two issues: > > * Are these attributes mandatory? So far we said "no". > * Do we need something like a capability exchange? I saw a few "yes". > > > For case 1 HA<-->AAA Server, I suggest to use NAS Appl. (RFC4005), > > carry added MIPv6 related AVPs. RFC4005 itself supports AVP > > extension, so it could be considered as not modifying RFC4005. > > If you only add a non-mandatory AVP then you don't need to touch NASREQ > or EAP at all. > > > > > (1) can bring more flexibility, however we have risk not stop > > extending Application ID. If in the real world, the AAA servers for > > NAS and HA are the same one, (2) is better. > > That's also the conclusion folks came to on the mailing list (from what > I can tell). > > > > > Regarding Diameter QoS work, in my understanding, QoS appl. is needed > > for every call/session procedure, MIPv6 appl. is only needed for the > > UE registration procedure. If we don't combine QoS appl., it might > > cause signaling delay; hence the response to user call behaves > > slowly. So QoS appl. is strongly suggested to be piggybacking with > > other procedure. And even if MIPv6 is not piggybacking with other > > procedure, from the user perspective, it represents a bit slower > > registration, users could live with it. > > I am not so sure I understand what you mean. I guess you need to provide > a little bit more details particularly with regard to the scenario you > have in mind. In my mind, the scenarios are PCC (piggyback charging and QoS), and Rs/Gq/Gq' (piggyback authorization and QoS). > > Ciao > Hannes > > > B. R. Tina Messengers: MSN: tinatsou6@hotmail.com Yahoo: tina_tsou > > Skype: tinaTSOU Jabber: tina@jabber.org > > > > ----- Original Message ----- From: "Hannes Tschofenig" > > To: Sent: Thursday, > > September 21, 2006 3:07 PM Subject: [Dime] My Summary of the MIPv6 > > Bootstrapping Discussion > > > > > >> Hi all, > >> > >> let me try to summarize what was discussed recently with regard to > >> MIPv6 bootstrapping. > >> > >> We agreed that it would be useful to differentiate the following > >> two cases: > >> > >> (1) NAS<->AAA Server > >> > >> (2) HA<->AAA Server > >> > >> [We need to change the titles of our document a bit.] > >> > >> With regard to (1) a number of folks were in favor of introducing a > >> capability mechanism that allows the NAS to indicate that it > >> supports a certain functionality. As Avi said, this newly required > >> AVP would be optional to use and optional to understand. If a NAS > >> does support bootstrapping for MIPv6 it includes the attribute in > >> AR (NASREQ or EAP). If it lands at a server that understands this > >> attribute, then it will respond correctly if it wants to bootstrap > >> MIPv6. If it lands at a server that doesn't understand the > >> attribute then bootstrapping via AAA will not occur. > >> > >> Defining a new AppID is not needed and consequently the Diameter > >> NASREQ/EAP message would hit the same server that also supports > >> MIPv6 bootstrapping. > >> > >> As an alternative, Yoshi suggested to go along the same approach as > >> in (2). The drawback would be the performance hit. This would, > >> however, allow the two servers to be different (if this is at all > >> useful). > >> > >> With regard to (2) Yoshi suggested a new AppID to be used for > >> Authorization and Accounting and not to reuse the EAP/NASREQ ABNF. > >> As Julien wrote, we are able to continue to use Diameter EAP for > >> Authentication. Thus, the HA will use Diameter EAP with the AVP > >> Auth-Request-Type set to AUTHENTICATE_ONLY and then the HA will use > >> this MIP6 Application for Authorization/Accounting of the Mobile > >> IPv6 service. > >> > >> This would avoid to update the application if RFC 4072 is updated > >> and this could be a way to proceed if other applications need EAP > >> for Authentication but have different needs for the Authorization > >> and Accounting part. > >> > >> Again, there is a performance disadvantage if a separate exchange > >> is used instead of piggybacking functionality. > >> > >> [I am still not sure how this nicely interworks with the QoS work > >> we do in the group. That's for further investigation.] > >> > >> I think we made progress in our discussions. Julien has initiated a > >> poll to see what todo regarding (2) and whether the group likes > >> Yoshi's suggestion. For (1) I got the impression that the focus > >> currently is more on the capability exchange but we might need to > >> initiate another poll there as well. > >> > >> Btw, the conclusions we make in this discussion can also be reused > >> for the Diameter QoS work. > >> > >> Ciao Hannes > >> > >> _______________________________________________ DiME mailing list > >> DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime > >> > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Sep 29 00:40:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTAAY-0003Ac-V9; Fri, 29 Sep 2006 00:40:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTAAX-0003AM-E2 for DiME@ietf.org; Fri, 29 Sep 2006 00:40:13 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTAAU-0003ri-U2 for DiME@ietf.org; Fri, 29 Sep 2006 00:40:13 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id DB18590005; Fri, 29 Sep 2006 00:40:05 -0400 (EDT) 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 25436-05; Fri, 29 Sep 2006 00:40:04 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP; Fri, 29 Sep 2006 00:40:04 -0400 (EDT) X-MessageTextProcessor: DisclaimIt (2.70.271) [Starent Networks Corp.] Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 00:40:04 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] My Summary of the MIPv6 Bootstrapping Discussion Date: Fri, 29 Sep 2006 00:40:04 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7837455@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] My Summary of the MIPv6 Bootstrapping Discussion thread-index: AcbjaabwaN2u9LaYSFKZIWgTcQsrvAAFtgjQ From: "Chowdhury, Kuntal" To: "Tina TSOU" , "Hannes Tschofenig" Importance: normal Priority: normal X-OriginalArrivalTime: 29 Sep 2006 04:40:04.0782 (UTC) FILETIME=[5549BCE0:01C6E381] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Cc: DiME@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Tina, > In my mind, the scenarios are PCC (piggyback charging and QoS), and > Rs/Gq/Gq' (piggyback authorization and QoS). AFAIK, PCC interactions (3GPP:Gx/ 3GPP2:Ty) are kept separate from auth/authz steps for network entry. -Kuntal > -----Original Message----- > From: Tina TSOU [mailto:tena@huawei.com] > Sent: Thursday, September 28, 2006 8:49 PM > To: Hannes Tschofenig > Cc: DiME@ietf.org > Subject: Re: [Dime] My Summary of the MIPv6 Bootstrapping Discussion >=20 > Hi Hannes, > See in line(: >=20 > B. R. > Tina > ----- Original Message ----- > From: "Hannes Tschofenig" > To: "Tina TSOU" > Cc: > Sent: Wednesday, September 27, 2006 4:09 PM > Subject: Re: [Dime] My Summary of the MIPv6 Bootstrapping Discussion >=20 >=20 > > Hi Tina, > > > > thanks for your response. > > > > Tina TSOU schrieb: > > > Hi all, Regarding Diameter MIPv6 work, in my understanding, (1) If we > > > consider NAS and HA authenticate/ authorize to different AAA Servers, > > > I suggest to define a new Application ID for NAS<-->AAA Server, and > > > define another new Application ID for HA<-->AAA Server. > > > > So far everyone was questioning the need to use different servers. > > > > > > > > > > (2)If we consider NAS and HA authenticate/ authorize to a same AAA > > > Server, I suggest to only define MIPv6 related AVPs in MIPv6 Appl. > > > Document. For case 1 NAS<-->AAA Server, I suggest to use EAP Appl. > > > (RFC4072), carry added MIPv6 related AVPs. RFC4072 itself supports > > > AVP extension, so it could be considered as not modifying RFC4072. > > > > Folks raised two issues: > > > > * Are these attributes mandatory? So far we said "no". > > * Do we need something like a capability exchange? I saw a few "yes". > > > > > For case 1 HA<-->AAA Server, I suggest to use NAS Appl. (RFC4005), > > > carry added MIPv6 related AVPs. RFC4005 itself supports AVP > > > extension, so it could be considered as not modifying RFC4005. > > > > If you only add a non-mandatory AVP then you don't need to touch NASREQ > > or EAP at all. > > > > > > > > (1) can bring more flexibility, however we have risk not stop > > > extending Application ID. If in the real world, the AAA servers for > > > NAS and HA are the same one, (2) is better. > > > > That's also the conclusion folks came to on the mailing list (from what > > I can tell). > > > > > > > > Regarding Diameter QoS work, in my understanding, QoS appl. is needed > > > for every call/session procedure, MIPv6 appl. is only needed for the > > > UE registration procedure. If we don't combine QoS appl., it might > > > cause signaling delay; hence the response to user call behaves > > > slowly. So QoS appl. is strongly suggested to be piggybacking with > > > other procedure. And even if MIPv6 is not piggybacking with other > > > procedure, from the user perspective, it represents a bit slower > > > registration, users could live with it. > > > > I am not so sure I understand what you mean. I guess you need to provide > > a little bit more details particularly with regard to the scenario you > > have in mind. > In my mind, the scenarios are PCC (piggyback charging and QoS), and > Rs/Gq/Gq' (piggyback authorization and QoS). > > > > Ciao > > Hannes > > > > > B. R. Tina Messengers: MSN: tinatsou6@hotmail.com Yahoo: tina_tsou > > > Skype: tinaTSOU Jabber: tina@jabber.org > > > > > > ----- Original Message ----- From: "Hannes Tschofenig" > > > To: Sent: Thursday, > > > September 21, 2006 3:07 PM Subject: [Dime] My Summary of the MIPv6 > > > Bootstrapping Discussion > > > > > > > > >> Hi all, > > >> > > >> let me try to summarize what was discussed recently with regard to > > >> MIPv6 bootstrapping. > > >> > > >> We agreed that it would be useful to differentiate the following > > >> two cases: > > >> > > >> (1) NAS<->AAA Server > > >> > > >> (2) HA<->AAA Server > > >> > > >> [We need to change the titles of our document a bit.] > > >> > > >> With regard to (1) a number of folks were in favor of introducing a > > >> capability mechanism that allows the NAS to indicate that it > > >> supports a certain functionality. As Avi said, this newly required > > >> AVP would be optional to use and optional to understand. If a NAS > > >> does support bootstrapping for MIPv6 it includes the attribute in > > >> AR (NASREQ or EAP). If it lands at a server that understands this > > >> attribute, then it will respond correctly if it wants to bootstrap > > >> MIPv6. If it lands at a server that doesn't understand the > > >> attribute then bootstrapping via AAA will not occur. > > >> > > >> Defining a new AppID is not needed and consequently the Diameter > > >> NASREQ/EAP message would hit the same server that also supports > > >> MIPv6 bootstrapping. > > >> > > >> As an alternative, Yoshi suggested to go along the same approach as > > >> in (2). The drawback would be the performance hit. This would, > > >> however, allow the two servers to be different (if this is at all > > >> useful). > > >> > > >> With regard to (2) Yoshi suggested a new AppID to be used for > > >> Authorization and Accounting and not to reuse the EAP/NASREQ ABNF. > > >> As Julien wrote, we are able to continue to use Diameter EAP for > > >> Authentication. Thus, the HA will use Diameter EAP with the AVP > > >> Auth-Request-Type set to AUTHENTICATE_ONLY and then the HA will use > > >> this MIP6 Application for Authorization/Accounting of the Mobile > > >> IPv6 service. > > >> > > >> This would avoid to update the application if RFC 4072 is updated > > >> and this could be a way to proceed if other applications need EAP > > >> for Authentication but have different needs for the Authorization > > >> and Accounting part. > > >> > > >> Again, there is a performance disadvantage if a separate exchange > > >> is used instead of piggybacking functionality. > > >> > > >> [I am still not sure how this nicely interworks with the QoS work > > >> we do in the group. That's for further investigation.] > > >> > > >> I think we made progress in our discussions. Julien has initiated a > > >> poll to see what todo regarding (2) and whether the group likes > > >> Yoshi's suggestion. For (1) I got the impression that the focus > > >> currently is more on the capability exchange but we might need to > > >> initiate another poll there as well. > > >> > > >> Btw, the conclusions we make in this discussion can also be reused > > >> for the Diameter QoS work. > > >> > > >> Ciao Hannes > > >> > > >> _______________________________________________ DiME mailing list > > >> DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime > > >> > > > > > > > > > > >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime "This email message and any attachments are confidential information of = Starent Networks, Corp. The information transmitted may not be used to = create or change any contractual obligations of Starent Networks, Corp. = Any review, retransmission, dissemination or other use of, or taking of = any action in reliance upon this e-mail and its attachments by persons = or entities other than the intended recipient is prohibited. If you are = not the intended recipient, please notify the sender immediately -- by = replying to this message or by sending an email to = postmaster@starentnetworks.com -- and destroy all copies of this message = and any attachments without reading or disclosing their contents. Thank = you." _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Sep 29 02:38:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTC14-0004z5-DZ; Fri, 29 Sep 2006 02:38:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTC13-0004yz-Ds for DiME@ietf.org; Fri, 29 Sep 2006 02:38:33 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTC12-000365-5W for DiME@ietf.org; Fri, 29 Sep 2006 02:38:33 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J6C00IOKDO7YS@szxga02-in.huawei.com> for DiME@ietf.org; Fri, 29 Sep 2006 14:50:31 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J6C00EV0DO69Q@szxga02-in.huawei.com> for DiME@ietf.org; Fri, 29 Sep 2006 14:50:31 +0800 (CST) Received: from CMTEST6 ([10.70.149.108]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J6C0028YDNHYO@szxml02-in.huawei.com>; Fri, 29 Sep 2006 14:50:06 +0800 (CST) Date: Fri, 29 Sep 2006 14:31:35 +0800 From: Tina TSOU Subject: Re: [Dime] My Summary of the MIPv6 Bootstrapping Discussion To: "Chowdhury, Kuntal" , Hannes Tschofenig Message-id: <00d301c6e390$e96f0240$6c95460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <7CCD07160348804497EF29E9EA5560D7837455@exchtewks2.starentnetworks.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Cc: DiME@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Kuntal, Yes, you are right. However, I was misunderstood. I meant two scenarios (i.e. they are two examples). Scenario a: PCC (piggyback charging and QoS) Scenario b: Rs/Gq/Gq' (piggyback authorization and QoS) I'm going to start drafting, could Hannes parse the drafting work a bit specifically? 1) Add more binding mechanisms 2) Editorial change 3) Harmonization of AVPs with other QoS-related profiles B. R. Tina ----- Original Message ----- From: "Chowdhury, Kuntal" To: "Tina TSOU" ; "Hannes Tschofenig" Cc: Sent: Friday, September 29, 2006 12:40 PM Subject: RE: [Dime] My Summary of the MIPv6 Bootstrapping Discussion Tina, > In my mind, the scenarios are PCC (piggyback charging and QoS), and > Rs/Gq/Gq' (piggyback authorization and QoS). AFAIK, PCC interactions (3GPP:Gx/ 3GPP2:Ty) are kept separate from auth/authz steps for network entry. -Kuntal > -----Original Message----- > From: Tina TSOU [mailto:tena@huawei.com] > Sent: Thursday, September 28, 2006 8:49 PM > To: Hannes Tschofenig > Cc: DiME@ietf.org > Subject: Re: [Dime] My Summary of the MIPv6 Bootstrapping Discussion > > Hi Hannes, > See in line(: > > B. R. > Tina > ----- Original Message ----- > From: "Hannes Tschofenig" > To: "Tina TSOU" > Cc: > Sent: Wednesday, September 27, 2006 4:09 PM > Subject: Re: [Dime] My Summary of the MIPv6 Bootstrapping Discussion > > > > Hi Tina, > > > > thanks for your response. > > > > Tina TSOU schrieb: > > > Hi all, Regarding Diameter MIPv6 work, in my understanding, (1) If we > > > consider NAS and HA authenticate/ authorize to different AAA Servers, > > > I suggest to define a new Application ID for NAS<-->AAA Server, and > > > define another new Application ID for HA<-->AAA Server. > > > > So far everyone was questioning the need to use different servers. > > > > > > > > > > (2)If we consider NAS and HA authenticate/ authorize to a same AAA > > > Server, I suggest to only define MIPv6 related AVPs in MIPv6 Appl. > > > Document. For case 1 NAS<-->AAA Server, I suggest to use EAP Appl. > > > (RFC4072), carry added MIPv6 related AVPs. RFC4072 itself supports > > > AVP extension, so it could be considered as not modifying RFC4072. > > > > Folks raised two issues: > > > > * Are these attributes mandatory? So far we said "no". > > * Do we need something like a capability exchange? I saw a few "yes". > > > > > For case 1 HA<-->AAA Server, I suggest to use NAS Appl. (RFC4005), > > > carry added MIPv6 related AVPs. RFC4005 itself supports AVP > > > extension, so it could be considered as not modifying RFC4005. > > > > If you only add a non-mandatory AVP then you don't need to touch NASREQ > > or EAP at all. > > > > > > > > (1) can bring more flexibility, however we have risk not stop > > > extending Application ID. If in the real world, the AAA servers for > > > NAS and HA are the same one, (2) is better. > > > > That's also the conclusion folks came to on the mailing list (from what > > I can tell). > > > > > > > > Regarding Diameter QoS work, in my understanding, QoS appl. is needed > > > for every call/session procedure, MIPv6 appl. is only needed for the > > > UE registration procedure. If we don't combine QoS appl., it might > > > cause signaling delay; hence the response to user call behaves > > > slowly. So QoS appl. is strongly suggested to be piggybacking with > > > other procedure. And even if MIPv6 is not piggybacking with other > > > procedure, from the user perspective, it represents a bit slower > > > registration, users could live with it. > > > > I am not so sure I understand what you mean. I guess you need to provide > > a little bit more details particularly with regard to the scenario you > > have in mind. > In my mind, the scenarios are PCC (piggyback charging and QoS), and > Rs/Gq/Gq' (piggyback authorization and QoS). > > > > Ciao > > Hannes > > > > > B. R. Tina Messengers: MSN: tinatsou6@hotmail.com Yahoo: tina_tsou > > > Skype: tinaTSOU Jabber: tina@jabber.org > > > > > > ----- Original Message ----- From: "Hannes Tschofenig" > > > To: Sent: Thursday, > > > September 21, 2006 3:07 PM Subject: [Dime] My Summary of the MIPv6 > > > Bootstrapping Discussion > > > > > > > > >> Hi all, > > >> > > >> let me try to summarize what was discussed recently with regard to > > >> MIPv6 bootstrapping. > > >> > > >> We agreed that it would be useful to differentiate the following > > >> two cases: > > >> > > >> (1) NAS<->AAA Server > > >> > > >> (2) HA<->AAA Server > > >> > > >> [We need to change the titles of our document a bit.] > > >> > > >> With regard to (1) a number of folks were in favor of introducing a > > >> capability mechanism that allows the NAS to indicate that it > > >> supports a certain functionality. As Avi said, this newly required > > >> AVP would be optional to use and optional to understand. If a NAS > > >> does support bootstrapping for MIPv6 it includes the attribute in > > >> AR (NASREQ or EAP). If it lands at a server that understands this > > >> attribute, then it will respond correctly if it wants to bootstrap > > >> MIPv6. If it lands at a server that doesn't understand the > > >> attribute then bootstrapping via AAA will not occur. > > >> > > >> Defining a new AppID is not needed and consequently the Diameter > > >> NASREQ/EAP message would hit the same server that also supports > > >> MIPv6 bootstrapping. > > >> > > >> As an alternative, Yoshi suggested to go along the same approach as > > >> in (2). The drawback would be the performance hit. This would, > > >> however, allow the two servers to be different (if this is at all > > >> useful). > > >> > > >> With regard to (2) Yoshi suggested a new AppID to be used for > > >> Authorization and Accounting and not to reuse the EAP/NASREQ ABNF. > > >> As Julien wrote, we are able to continue to use Diameter EAP for > > >> Authentication. Thus, the HA will use Diameter EAP with the AVP > > >> Auth-Request-Type set to AUTHENTICATE_ONLY and then the HA will use > > >> this MIP6 Application for Authorization/Accounting of the Mobile > > >> IPv6 service. > > >> > > >> This would avoid to update the application if RFC 4072 is updated > > >> and this could be a way to proceed if other applications need EAP > > >> for Authentication but have different needs for the Authorization > > >> and Accounting part. > > >> > > >> Again, there is a performance disadvantage if a separate exchange > > >> is used instead of piggybacking functionality. > > >> > > >> [I am still not sure how this nicely interworks with the QoS work > > >> we do in the group. That's for further investigation.] > > >> > > >> I think we made progress in our discussions. Julien has initiated a > > >> poll to see what todo regarding (2) and whether the group likes > > >> Yoshi's suggestion. For (1) I got the impression that the focus > > >> currently is more on the capability exchange but we might need to > > >> initiate another poll there as well. > > >> > > >> Btw, the conclusions we make in this discussion can also be reused > > >> for the Diameter QoS work. > > >> > > >> Ciao Hannes > > >> > > >> _______________________________________________ DiME mailing list > > >> DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime > > >> > > > > > > > > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime "This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster@starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you." _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime