From dime-bounces@ietf.org Wed Nov 01 16:21:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNWO-0001S4-1i; Wed, 01 Nov 2006 16:21:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNWM-0001QD-1B for dime@ietf.org; Wed, 01 Nov 2006 16:21:14 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfNWK-0004S8-KE for dime@ietf.org; Wed, 01 Nov 2006 16:21:14 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 01 Nov 2006 13:21:12 -0800 X-IronPort-AV: i="4.09,379,1157353200"; d="scan'208"; a="83839066:sNHT47475765" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA1LLCXJ016317; Wed, 1 Nov 2006 13:21:12 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA1LLBAo008864; Wed, 1 Nov 2006 13:21:11 -0800 (PST) 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); Wed, 1 Nov 2006 13:21:11 -0800 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] Address format confusion Date: Wed, 1 Nov 2006 13:21:10 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262502E5EE1A@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Address format confusion Thread-Index: Acb8KIEfi1V88OwMQpukrmFIo2oFdwB0Z9+A From: "Glen Zorn \(gwz\)" To: "Ulf Bodin" , X-OriginalArrivalTime: 01 Nov 2006 21:21:11.0606 (UTC) FILETIME=[A7897560:01C6FDFB] DKIM-Signature: a=rsa-sha1; q=dns; l=1333; t=1162416072; x=1163280072; c=relaxed/simple; s=sjdkim1002; 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]=20Address=20format=20confusion=20; X=v=3Dcisco.com=3B=20h=3DL5A+TqmPPlR2oZvhZtLWSqEqPuw=3D; b=YLipy/EqXEQpqjptFPRdpqbJW0GZZPHhw9SEcuSwfevMrllYKWI4aQSwhNx2shPH79+6DWk1 Z493689W+vZfVzSD04nkqIQVujWgLI1FJOgiSH8zXJHDQ6NIVqXVoyLb; Authentication-Results: sj-dkim-1.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Erik Lundgren 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 Ulf Bodin supposedly scribbled on Monday, October 30, 2006 5:37 AM: > Hi, >=20 > We're somewhat confused about what format to use for the > Framed-IP-Address AVP. It seems that NASREQ uses the pre-draft-v16 > (Diameter base protocol) format of the IPv4 address (i.e. four > octets) instead of the Address format defined in RFC3588, section > 4.3: =20 >=20 > Address > The Address format is derived from the OctetString AVP Base Format. > It is a discriminated union, representing, for example a 32-bit > (IPv4) [IPV4] or 128-bit (IPv6) [IPV6] address, most significant > octet first. =20 > The first two octets of the Address AVP represents the AddressType, > which contains an Address Family defined in [IANAADFAM]. The > AddressType is used to discriminate the content and format of the > remaining octets. =20 >=20 > Our question is if the pre-draft-v16 format should be still used,=20 Yes. > or if the new format in RFC3588 should be adopted=20 No. > (which should result > in a change in RFC4005 as we understand the procedure). =20 The format specified for the Framed-IP-Address AVP is the same as that of the Framed-IP-Address RADIUS attribute, on purpose. If you need to send an IPv6 address, I believe that you can use the Framed-IPv6-Prefix AVP. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Nov 03 09:31:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg04O-0003fp-8i; Fri, 03 Nov 2006 09:30:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg04L-0003dL-T9 for dime@ietf.org; Fri, 03 Nov 2006 09:30:53 -0500 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg03K-0003zh-Ku for dime@ietf.org; Fri, 03 Nov 2006 09:29:51 -0500 Received: by ug-out-1314.google.com with SMTP id 72so375421ugd for ; Fri, 03 Nov 2006 06:29:49 -0800 (PST) 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=JtjgNHsA6zH60iDpPK/H5d34blJFTi2wd5alU0zF1URD2RgyBH1rxTj2L6nNO7Hy85vjWWAZofznX0X+chgKyxKWMLKeUONm1GSUsOwthQZ1ppVNGnAPSiz48F3vyJ0mrQH3C6NQRE9QAfh2mLle8P4UKWqa2cnaF+qSm1Ivj+k= Received: by 10.67.121.18 with SMTP id y18mr2758409ugm.1162564189528; Fri, 03 Nov 2006 06:29:49 -0800 (PST) Received: by 10.66.243.16 with HTTP; Fri, 3 Nov 2006 06:29:49 -0800 (PST) Message-ID: Date: Fri, 3 Nov 2006 15:29:49 +0100 From: "Gerardo Giaretta" To: "Madjid Nakhjiri" Subject: Re: [Dime] Fwd: [Mip6] WG LC for I-d: draft-ietf-mip6-aaa-ha-goals-03 In-Reply-To: <001c01c6eca2$215232d0$2f01a8c0@huawei6cc10c70> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <001c01c6eca2$215232d0$2f01a8c0@huawei6cc10c70> X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 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, thanks for the review. Most comments are editorial and I'll fix them in next version. Just one more detailed question below. > > 5.1. General goals > > G1.1 The AAAH server and the HA MUST be able to authenticate each > other (mutual authentication) in order to prevent the installation > of unauthorized state on the HA. In some deployment scenarios, it > may not be feasible for HA and AAAH to mutually authenticate each > other. For example, let us consider the case where MSP is not the > MSA. In such a case, several AAA intermediate proxies could > forward MIP6 bootstrapping information back and forth between HA > and AAA. Thus, to prevent the installation of unauthorized state > on the HA, the path between HA and AAAH should be trustworthy>/ > > > Madjid>>again MSP versus MSA terminology issue. Plus the text is venturing > into something that is more of a > > AAA infrastructure issue than an HA-AAAH issue. Also the text is mixing end > point authentication and AAA > > signaling security all in one requirement. Mutual authentication of HA and > home AAA is one thing, protecting > > bootstrapping info over AAA messaging is another. This should be broken into > two requirements. I believe you > > have text on confidentiality in G1.4. The AAA signaling security issue is > that of a AAA client in visited > > AAA domain dealing with a home AAA domain are well known. for instance if > you don't like the transitive > > trust provided by the hop by hop security in RADIUS, so you need external > ways to cure the transitive trust > > problem. On the other hand providing a mutual authentication procedure > between HA and home AAA server > > without intervention of AAA intermediaries in a whole different problem. So > we need to be careful, otherwise > > we may end up ruling RADIUS out of here. Is that the intention? > > I would simply state the well known issues in the security consideration > section. > sorry but I cannot get your point clearly. which is your suggestion? Removing the requirement? Rephrasing it? Can you please provide some text? Thanks, --Gerardo > > Giaretta, et al. Expires March 16, 2007 [Page 6] > > > Internet-Draft AAA Goals for Mobile IPv6 September 2006 > > > G1.2 The AAA-HA interface MUST provide integrity protection in order > to prevent any alteration of exchanged data (e.g., Mobile IPv6 > configuration parameters). > > G1.3 The AAA-HA interface MUST provide replay protection. > > G1.4 The AAA-HA interface SHOULD provide confidentiality since it > may be used to transfer keying material (e.g., shared key > generated during EAP method authentication). > > Madjid>>same comment as that on security in G1.1. > > G1.5 The AAA-HA interface SHOULD support inactive peer detection. > This functionality can be used by the AAAH server to maintain a > list of active HAs. > > > 5.2. Service Authorization > > Madjid>>Typically authorization follows a successful authentication. It > seems that the burden of the making > > sure the MN is authenticated falls into the lap of the HA, should we not > have a requirement on this? > > G2.1 The AAA-HA interface SHOULD allow the use of Network Access > Identifier (NAI) to identify the user. > > Madjid>>I believe for the split scenario. We were saying that the > Diameter_EAP and Diameter-MIP need to use > > the same ID. does this cover that? Is NAI always the ID used for EAP? > > G2.2 The HA SHOULD be able to query the AAAH server to verify Mobile > IPv6 service authorization for the mobile node. > > G2.3 The AAAH server MAY assign explicit operational limitations and > authorization restrictions on the HA (e.g., packet filters, QoS > parameters). > > G2.4 The AAAH server MUST be able to send an authorization lifetime > to the HA to limit Mobile IPv6 session duration for the MN. > > G2.5 The HA MUST be able to request to the AAAH server an extension > of the authorization lifetime granted to the MN. > > G2.6 The AAAH server MUST be able to force the HA to terminate an > active Mobile IPv6 session for authorization policy reasons (e.g., > credit exhaustion). > > > 5.3. Accounting > > G3.1 The AAA-HA interface MUST support the transfer of accounting > records needed for service control and charging. These include > (but may not be limited to): time of binding cache entry creation > and deletion, octets sent and received by the mobile node in bi- > directional tunneling, etc. > > > > > > > Giaretta, et al. Expires March 16, 2007 [Page 7] > > > Internet-Draft AAA Goals for Mobile IPv6 September 2006 > > > 5.4. Mobile Node Authentication > > G4.1 The AAA-HA interface MUST support pass-through EAP > authentication with the HA working as EAP authenticator operating > in pass-through mode and the AAAH server working as back-end > authentication server. > > Madjid>>Does this really have to be a MUST? > > 5.5. Provisioning of Configuration Parameters > > G5.1 The HA SHOULD be able to communicate to the AAAH server the > Home Address allocated to the MN (e.g., for allowing the AAAH > server to perform a DNS update on behalf of the MN). > > G5.2 The AAAH SHOULD be able to indicate to the HA if the MN is > authorized to autoconfigure its Home Address. > > > > 6. Goals for the Integrated Scenario > > In the integrated scenario, the AAA server provides the HA > information to the NAS as part of the whole AAA operations for > network access. Next goals are considered in addition to those > described in section Section 5. > > G6.1 The AAAH server MUST be able to communicate the Home Agent > Information (IP Address or FQDN) to the NAS. > > G6.2 The NAS SHOULD be able to notify that it supports the > functionalities described in [4]. > > G6.3 The ASP/MSP SHOULD be able to indicate to the MSA if it can > allocate a Home Agent to the MN. > > G6.4 The AAA server of the MSA MUST be able to indicate to the NAS > whether the MN is authorized to use a local Home Agent (i.e. a > Home Agent in the ASP/MSP) > > > > Giaretta, et al. Expires March 16, 2007 [Page 8] > > > Internet-Draft AAA Goals for Mobile IPv6 September 2006 > > > 8. Security Considerations > > As stated in Section 5.1 the AAA-HA interface must provide mutual > authentication, integrity and replay protection. Furthermore, if > security parameters (e.g., IKE pre-shared key) are transferred > through this interface, confidentiality is strongly recommended to be > supported. However note that AAA protocols does not support this > unless it exists a direct connection between corresponding entities. > > Madjid>> Diameter supports this. should say "some AAA protocols". > > > > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > Sent: Tuesday, October 03, 2006 8:13 AM > To: dime@ietf.org > Subject: [Dime] Fwd: [Mip6] WG LC for I-d: draft-ietf-mip6-aaa-ha-goals-03 > > FYI, please review the document. > > --Gerardo > > ---------- Forwarded message ---------- > From: Basavaraj Patil > Date: Oct 3, 2006 4:49 PM > Subject: [Mip6] WG LC for I-d: draft-ietf-mip6-aaa-ha-goals-03 > To: mip6@ietf.org > > > > Hello, > > This is a Working group last call for the WG I-D: AAA Goals for Mobile > IPv6 (draft-ietf-mip6-aaa-ha-goals-03). The draft is intended to serve > as the AAA requirements for Mobile IPv6. > > Please review the I-D and submit your comments to the authors or to > the list directly. > > The WGLC expires on Oct 18th, 06. > > The I-D is intended to be published as an Informational RFC. > > -Raj > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ > 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 Nov 04 17:15:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgTnE-0004ZS-UZ; Sat, 04 Nov 2006 17:15:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgTnD-0004ZJ-Nr; Sat, 04 Nov 2006 17:15:11 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgTnD-0006Bd-5V; Sat, 04 Nov 2006 17:15:11 -0500 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 <0J8800HBS8C36R@usaga01-in.huawei.com>; Sat, 04 Nov 2006 14:12:03 -0800 (PST) Received: from N737011 ([10.192.25.84]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J88002248BYSP@usaga01-in.huawei.com>; Sat, 04 Nov 2006 14:12:03 -0800 (PST) Date: Sat, 04 Nov 2006 14:15:02 -0800 From: Madjid Nakhjiri Subject: RE: [Dime] Fwd: [Mip6] WG LC for I-d: draft-ietf-mip6-aaa-ha-goals-03 In-reply-to: To: 'Gerardo Giaretta' Message-id: <001401c7005e$ac712310$5419c00a@china.huawei.com> 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: Acb/VStGDKC68u7AQ+2UxwfvSqUwGwBAsp1w X-Spam-Score: 0.0 (/) X-Scan-Signature: 918f4bd8440e8de4700bcf6d658bc801 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 The doc calls itself AAA-HA goals, so We need to see what we need to accomplish by the document 1) define AAA function requirements on HA and on HA-AAA server protocol? 2) what is vendor required to put inside MIP6 HA to support AAA interaction. If the goal is 1) and you are not careful, you can unintentionally rule out RADIUS. Plus some of the requirements are beyond the scope of those for AAA client (HA) and AAA protocols. I am just pointing out that unless trying to set up a set of goals for the Dime drafts, we need to be careful about the side-effect of ruling out use of RADIUS for MIP6. Let me go through the goal > G1.1 The AAAH server and the HA MUST be able to authenticate each > other (mutual authentication) in order to prevent the installation > of unauthorized state on the HA. In some deployment scenarios, it > may not be feasible for HA and AAAH to mutually authenticate each > other. For example, let us consider the case where MSP is not the > MSA. In such a case, several AAA intermediate proxies could > forward MIP6 bootstrapping information back and forth between HA > and AAA. Thus, to prevent the installation of unauthorized state > on the HA, the path between HA and AAAH should be trustworthy>/ > Madjid>>I am going to assume HA is AAA client, not sure, if authentication between a AAA client and a AAA is an explicit requirement in any of the AAA protocols. First it means a direct SA between the HA and AAAH. If there are proxies on the AAA path, RADIUS for one does not support the end to end SA directly, let alone the act of end to end authentication. I understand that sending keys from AAAH to HA requires tight security, but this is not a "AAA requirement", since it may not be covered by some AAA protocols, it is part of security provisioning for the entire HA design. You may want to bring this up in "security consideration section". You already seem to have this part of security consideration, so not sure why it is also mentioned as AAA-HA goal, unless the goal of the doc is the (2) mentioned above. I hope I have been helpful. R, Madjid -----Original Message----- From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] Sent: Friday, November 03, 2006 6:30 AM To: Madjid Nakhjiri Cc: dime@ietf.org; mip6@ietf.org; Julien Bournelle Subject: Re: [Dime] Fwd: [Mip6] WG LC for I-d: draft-ietf-mip6-aaa-ha-goals-03 Hi Madjid, thanks for the review. Most comments are editorial and I'll fix them in next version. Just one more detailed question below. > > 5.1. General goals > > G1.1 The AAAH server and the HA MUST be able to authenticate each > other (mutual authentication) in order to prevent the installation > of unauthorized state on the HA. In some deployment scenarios, it > may not be feasible for HA and AAAH to mutually authenticate each > other. For example, let us consider the case where MSP is not the > MSA. In such a case, several AAA intermediate proxies could > forward MIP6 bootstrapping information back and forth between HA > and AAA. Thus, to prevent the installation of unauthorized state > on the HA, the path between HA and AAAH should be trustworthy>/ > > > Madjid>>again MSP versus MSA terminology issue. Plus the text is venturing > into something that is more of a > > AAA infrastructure issue than an HA-AAAH issue. Also the text is mixing end > point authentication and AAA > > signaling security all in one requirement. Mutual authentication of HA and > home AAA is one thing, protecting > > bootstrapping info over AAA messaging is another. This should be broken into > two requirements. I believe you > > have text on confidentiality in G1.4. The AAA signaling security issue is > that of a AAA client in visited > > AAA domain dealing with a home AAA domain are well known. for instance if > you don't like the transitive > > trust provided by the hop by hop security in RADIUS, so you need external > ways to cure the transitive trust > > problem. On the other hand providing a mutual authentication procedure > between HA and home AAA server > > without intervention of AAA intermediaries in a whole different problem. So > we need to be careful, otherwise > > we may end up ruling RADIUS out of here. Is that the intention? > > I would simply state the well known issues in the security consideration > section. > sorry but I cannot get your point clearly. which is your suggestion? Removing the requirement? Rephrasing it? Can you please provide some text? Thanks, --Gerardo > > Giaretta, et al. Expires March 16, 2007 [Page 6] > > > Internet-Draft AAA Goals for Mobile IPv6 September 2006 > > > G1.2 The AAA-HA interface MUST provide integrity protection in order > to prevent any alteration of exchanged data (e.g., Mobile IPv6 > configuration parameters). > > G1.3 The AAA-HA interface MUST provide replay protection. > > G1.4 The AAA-HA interface SHOULD provide confidentiality since it > may be used to transfer keying material (e.g., shared key > generated during EAP method authentication). > > Madjid>>same comment as that on security in G1.1. > > G1.5 The AAA-HA interface SHOULD support inactive peer detection. > This functionality can be used by the AAAH server to maintain a > list of active HAs. > > > 5.2. Service Authorization > > Madjid>>Typically authorization follows a successful authentication. It > seems that the burden of the making > > sure the MN is authenticated falls into the lap of the HA, should we not > have a requirement on this? > > G2.1 The AAA-HA interface SHOULD allow the use of Network Access > Identifier (NAI) to identify the user. > > Madjid>>I believe for the split scenario. We were saying that the > Diameter_EAP and Diameter-MIP need to use > > the same ID. does this cover that? Is NAI always the ID used for EAP? > > G2.2 The HA SHOULD be able to query the AAAH server to verify Mobile > IPv6 service authorization for the mobile node. > > G2.3 The AAAH server MAY assign explicit operational limitations and > authorization restrictions on the HA (e.g., packet filters, QoS > parameters). > > G2.4 The AAAH server MUST be able to send an authorization lifetime > to the HA to limit Mobile IPv6 session duration for the MN. > > G2.5 The HA MUST be able to request to the AAAH server an extension > of the authorization lifetime granted to the MN. > > G2.6 The AAAH server MUST be able to force the HA to terminate an > active Mobile IPv6 session for authorization policy reasons (e.g., > credit exhaustion). > > > 5.3. Accounting > > G3.1 The AAA-HA interface MUST support the transfer of accounting > records needed for service control and charging. These include > (but may not be limited to): time of binding cache entry creation > and deletion, octets sent and received by the mobile node in bi- > directional tunneling, etc. > > > > > > > Giaretta, et al. Expires March 16, 2007 [Page 7] > > > Internet-Draft AAA Goals for Mobile IPv6 September 2006 > > > 5.4. Mobile Node Authentication > > G4.1 The AAA-HA interface MUST support pass-through EAP > authentication with the HA working as EAP authenticator operating > in pass-through mode and the AAAH server working as back-end > authentication server. > > Madjid>>Does this really have to be a MUST? > > 5.5. Provisioning of Configuration Parameters > > G5.1 The HA SHOULD be able to communicate to the AAAH server the > Home Address allocated to the MN (e.g., for allowing the AAAH > server to perform a DNS update on behalf of the MN). > > G5.2 The AAAH SHOULD be able to indicate to the HA if the MN is > authorized to autoconfigure its Home Address. > > > > 6. Goals for the Integrated Scenario > > In the integrated scenario, the AAA server provides the HA > information to the NAS as part of the whole AAA operations for > network access. Next goals are considered in addition to those > described in section Section 5. > > G6.1 The AAAH server MUST be able to communicate the Home Agent > Information (IP Address or FQDN) to the NAS. > > G6.2 The NAS SHOULD be able to notify that it supports the > functionalities described in [4]. > > G6.3 The ASP/MSP SHOULD be able to indicate to the MSA if it can > allocate a Home Agent to the MN. > > G6.4 The AAA server of the MSA MUST be able to indicate to the NAS > whether the MN is authorized to use a local Home Agent (i.e. a > Home Agent in the ASP/MSP) > > > > Giaretta, et al. Expires March 16, 2007 [Page 8] > > > Internet-Draft AAA Goals for Mobile IPv6 September 2006 > > > 8. Security Considerations > > As stated in Section 5.1 the AAA-HA interface must provide mutual > authentication, integrity and replay protection. Furthermore, if > security parameters (e.g., IKE pre-shared key) are transferred > through this interface, confidentiality is strongly recommended to be > supported. However note that AAA protocols does not support this > unless it exists a direct connection between corresponding entities. > > Madjid>> Diameter supports this. should say "some AAA protocols". > > > > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > Sent: Tuesday, October 03, 2006 8:13 AM > To: dime@ietf.org > Subject: [Dime] Fwd: [Mip6] WG LC for I-d: draft-ietf-mip6-aaa-ha-goals-03 > > FYI, please review the document. > > --Gerardo > > ---------- Forwarded message ---------- > From: Basavaraj Patil > Date: Oct 3, 2006 4:49 PM > Subject: [Mip6] WG LC for I-d: draft-ietf-mip6-aaa-ha-goals-03 > To: mip6@ietf.org > > > > Hello, > > This is a Working group last call for the WG I-D: AAA Goals for Mobile > IPv6 (draft-ietf-mip6-aaa-ha-goals-03). The draft is intended to serve > as the AAA requirements for Mobile IPv6. > > Please review the I-D and submit your comments to the authors or to > the list directly. > > The WGLC expires on Oct 18th, 06. > > The I-D is intended to be published as an Informational RFC. > > -Raj > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ > 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 Nov 06 02:51:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgzG3-0007XW-2L; Mon, 06 Nov 2006 02:51:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgzG1-0007XI-56 for dime@ietf.org; Mon, 06 Nov 2006 02:51:01 -0500 Received: from net-internal.operax.com ([213.50.74.197] helo=smtp.operax.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GgzFz-0007Wc-Lw for dime@ietf.org; Mon, 06 Nov 2006 02:51:01 -0500 Received: (qmail 34065 invoked by uid 0); 6 Nov 2006 07:50:53 -0000 Received: from lulex02.ad.operax.com (192.168.2.13) by treo.operax.com with SMTP; 6 Nov 2006 07:50:53 -0000 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] Address format confusion Date: Mon, 6 Nov 2006 08:50:52 +0100 Message-ID: <33656995C5C5094A983DE84DA649A924B1A306@lulex02.ad.operax.com> In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB262502E5EE1A@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Address format confusion Thread-Index: Acb8KIEfi1V88OwMQpukrmFIo2oFdwB0Z9+AAN9xNGA= From: "Ulf Bodin" To: "Glen Zorn \(gwz\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Erik Lundgren 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 Thanks Glen,=20 I'm happy to have this sorted out as it has caused confusion in an interoperability matter of ours.=20 Best regards,=20 Ulf =20 -----Original Message----- From: Glen Zorn (gwz) [mailto:gwz@cisco.com]=20 Sent: den 1 november 2006 22:21 To: Ulf Bodin; dime@ietf.org Cc: Erik Lundgren Subject: RE: [Dime] Address format confusion=20 Ulf Bodin supposedly scribbled on Monday, October 30, 2006 5:37 AM: > Hi, >=20 > We're somewhat confused about what format to use for the=20 > Framed-IP-Address AVP. It seems that NASREQ uses the pre-draft-v16=20 > (Diameter base protocol) format of the IPv4 address (i.e. four > octets) instead of the Address format defined in RFC3588, section > 4.3: =20 >=20 > Address > The Address format is derived from the OctetString AVP Base Format. > It is a discriminated union, representing, for example a 32-bit > (IPv4) [IPV4] or 128-bit (IPv6) [IPV6] address, most significant > octet first. =20 > The first two octets of the Address AVP represents the AddressType,=20 > which contains an Address Family defined in [IANAADFAM]. The=20 > AddressType is used to discriminate the content and format of the > remaining octets. =20 >=20 > Our question is if the pre-draft-v16 format should be still used, Yes. > or if the new format in RFC3588 should be adopted No. > (which should result > in a change in RFC4005 as we understand the procedure). =20 The format specified for the Framed-IP-Address AVP is the same as that of the Framed-IP-Address RADIUS attribute, on purpose. If you need to send an IPv6 address, I believe that you can use the Framed-IPv6-Prefix AVP. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Nov 06 13:01:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh8mS-0004NB-5k; Mon, 06 Nov 2006 13:01:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh8mQ-0004N6-Sj for dime@ietf.org; Mon, 06 Nov 2006 13:01:06 -0500 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh8mM-00039O-4Q for dime@ietf.org; Mon, 06 Nov 2006 13:01:06 -0500 Received: by ug-out-1314.google.com with SMTP id 72so802486ugd for ; Mon, 06 Nov 2006 10:01:01 -0800 (PST) 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=LUyRU0Ky1VeMhQddqpNifqZ6um/0WD3Nm2GYWn2MjYQ7X2VoCt3wRGhTkJKndB3T5mVWNVGLn0mh5zAw4AQWve/qQjOidGBGaniLRRrRcF3H7FcyEDtgctYx2B6gQMg0gSe4h4dDSfWbEhn9830T6LGsSI4bksS78RFjNM1EU6A= Received: by 10.66.232.11 with SMTP id e11mr7745895ugh.1162836060611; Mon, 06 Nov 2006 10:01:00 -0800 (PST) Received: by 10.66.243.16 with HTTP; Mon, 6 Nov 2006 10:01:00 -0800 (PST) Message-ID: Date: Mon, 6 Nov 2006 10:01:00 -0800 From: "Gerardo Giaretta" To: "Madjid Nakhjiri" Subject: Re: [Dime] Fwd: [Mip6] WG LC for I-d: draft-ietf-mip6-aaa-ha-goals-03 In-Reply-To: <001401c7005e$ac712310$5419c00a@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: <001401c7005e$ac712310$5419c00a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b3349545af520ba354ccdc9e1a03fc1 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, On 11/4/06, Madjid Nakhjiri wrote: > The doc calls itself AAA-HA goals, so We need to see what we need to > accomplish by the document > > 1) define AAA function requirements on HA and on HA-AAA server protocol? > > > 2) what is vendor required to put inside MIP6 HA to support AAA interaction. > > If the goal is 1) and you are not careful, you can unintentionally rule out > RADIUS. Plus some of the requirements are beyond the scope of those for AAA > client (HA) and AAA protocols. I am just pointing out that unless trying to > set up a set of goals for the Dime drafts, we need to be careful about the > side-effect of ruling out use of RADIUS for MIP6. > > Let me go through the goal > > > G1.1 The AAAH server and the HA MUST be able to authenticate each > > other (mutual authentication) in order to prevent the installation > > of unauthorized state on the HA. In some deployment scenarios, it > > may not be feasible for HA and AAAH to mutually authenticate each > > other. For example, let us consider the case where MSP is not the > > MSA. In such a case, several AAA intermediate proxies could > > forward MIP6 bootstrapping information back and forth between HA > > and AAA. Thus, to prevent the installation of unauthorized state > > on the HA, the path between HA and AAAH should be trustworthy>/ > > > > Madjid>>I am going to assume HA is AAA client, not sure, if authentication > between a AAA client and a AAA is an explicit requirement in any of the AAA > protocols. First it means a direct SA between the HA and AAAH. If there are > proxies on the AAA path, RADIUS for one does not support the end to end SA > directly, let alone the act of end to end authentication. > I understand that sending keys from AAAH to HA requires tight security, but > this is not a "AAA requirement", since it may not be covered by some AAA > protocols, it is part of security provisioning for the entire HA design. You > may want to bring this up in "security consideration section". > > You already seem to have this part of security consideration, so not sure > why it is also mentioned as AAA-HA goal, unless the goal of the doc is the > (2) mentioned above. > ok, now I get your point. However in the goal text we have already added this sentence: In some deployment scenarios, it may not be feasible for HA and AAAH to mutually authenticate each other. For example, let us consider the case where MSP is not the MSA. In such a case, several AAA intermediate proxies could forward MIP6 bootstrapping information back and forth between HA and AAA. Thus, to prevent the installation of unauthorized state on the HA, the path between HA and AAAH should be trustworthy. This was added exactly for RADIUS. Doesn't this text solve your issue? --Gerardo > I hope I have been helpful. > > R, > > Madjid > > > > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > Sent: Friday, November 03, 2006 6:30 AM > To: Madjid Nakhjiri > Cc: dime@ietf.org; mip6@ietf.org; Julien Bournelle > Subject: Re: [Dime] Fwd: [Mip6] WG LC for I-d: > draft-ietf-mip6-aaa-ha-goals-03 > > Hi Madjid, > > thanks for the review. Most comments are editorial and I'll fix them > in next version. Just one more detailed question below. > > > > > > 5.1. General goals > > > > G1.1 The AAAH server and the HA MUST be able to authenticate each > > other (mutual authentication) in order to prevent the installation > > of unauthorized state on the HA. In some deployment scenarios, it > > may not be feasible for HA and AAAH to mutually authenticate each > > other. For example, let us consider the case where MSP is not the > > MSA. In such a case, several AAA intermediate proxies could > > forward MIP6 bootstrapping information back and forth between HA > > and AAA. Thus, to prevent the installation of unauthorized state > > on the HA, the path between HA and AAAH should be trustworthy>/ > > > > > > Madjid>>again MSP versus MSA terminology issue. Plus the text is venturing > > into something that is more of a > > > > AAA infrastructure issue than an HA-AAAH issue. Also the text is mixing > end > > point authentication and AAA > > > > signaling security all in one requirement. Mutual authentication of HA and > > home AAA is one thing, protecting > > > > bootstrapping info over AAA messaging is another. This should be broken > into > > two requirements. I believe you > > > > have text on confidentiality in G1.4. The AAA signaling security issue is > > that of a AAA client in visited > > > > AAA domain dealing with a home AAA domain are well known. for instance if > > you don't like the transitive > > > > trust provided by the hop by hop security in RADIUS, so you need external > > ways to cure the transitive trust > > > > problem. On the other hand providing a mutual authentication procedure > > between HA and home AAA server > > > > without intervention of AAA intermediaries in a whole different problem. > So > > we need to be careful, otherwise > > > > we may end up ruling RADIUS out of here. Is that the intention? > > > > I would simply state the well known issues in the security consideration > > section. > > > > sorry but I cannot get your point clearly. > > which is your suggestion? Removing the requirement? Rephrasing it? Can > you please provide some text? > > Thanks, > --Gerardo > > > > > Giaretta, et al. Expires March 16, 2007 [Page 6] > > > > > > Internet-Draft AAA Goals for Mobile IPv6 September 2006 > > > > > > G1.2 The AAA-HA interface MUST provide integrity protection in order > > to prevent any alteration of exchanged data (e.g., Mobile IPv6 > > configuration parameters). > > > > G1.3 The AAA-HA interface MUST provide replay protection. > > > > G1.4 The AAA-HA interface SHOULD provide confidentiality since it > > may be used to transfer keying material (e.g., shared key > > generated during EAP method authentication). > > > > Madjid>>same comment as that on security in G1.1. > > > > G1.5 The AAA-HA interface SHOULD support inactive peer detection. > > This functionality can be used by the AAAH server to maintain a > > list of active HAs. > > > > > > 5.2. Service Authorization > > > > Madjid>>Typically authorization follows a successful authentication. It > > seems that the burden of the making > > > > sure the MN is authenticated falls into the lap of the HA, should we not > > have a requirement on this? > > > > G2.1 The AAA-HA interface SHOULD allow the use of Network Access > > Identifier (NAI) to identify the user. > > > > Madjid>>I believe for the split scenario. We were saying that the > > Diameter_EAP and Diameter-MIP need to use > > > > the same ID. does this cover that? Is NAI always the ID used for EAP? > > > > G2.2 The HA SHOULD be able to query the AAAH server to verify Mobile > > IPv6 service authorization for the mobile node. > > > > G2.3 The AAAH server MAY assign explicit operational limitations and > > authorization restrictions on the HA (e.g., packet filters, QoS > > parameters). > > > > G2.4 The AAAH server MUST be able to send an authorization lifetime > > to the HA to limit Mobile IPv6 session duration for the MN. > > > > G2.5 The HA MUST be able to request to the AAAH server an extension > > of the authorization lifetime granted to the MN. > > > > G2.6 The AAAH server MUST be able to force the HA to terminate an > > active Mobile IPv6 session for authorization policy reasons (e.g., > > credit exhaustion). > > > > > > 5.3. Accounting > > > > G3.1 The AAA-HA interface MUST support the transfer of accounting > > records needed for service control and charging. These include > > (but may not be limited to): time of binding cache entry creation > > and deletion, octets sent and received by the mobile node in bi- > > directional tunneling, etc. > > > > > > > > > > > > > > Giaretta, et al. Expires March 16, 2007 [Page 7] > > > > > > Internet-Draft AAA Goals for Mobile IPv6 September 2006 > > > > > > 5.4. Mobile Node Authentication > > > > G4.1 The AAA-HA interface MUST support pass-through EAP > > authentication with the HA working as EAP authenticator operating > > in pass-through mode and the AAAH server working as back-end > > authentication server. > > > > Madjid>>Does this really have to be a MUST? > > > > 5.5. Provisioning of Configuration Parameters > > > > G5.1 The HA SHOULD be able to communicate to the AAAH server the > > Home Address allocated to the MN (e.g., for allowing the AAAH > > server to perform a DNS update on behalf of the MN). > > > > G5.2 The AAAH SHOULD be able to indicate to the HA if the MN is > > authorized to autoconfigure its Home Address. > > > > > > > > 6. Goals for the Integrated Scenario > > > > In the integrated scenario, the AAA server provides the HA > > information to the NAS as part of the whole AAA operations for > > network access. Next goals are considered in addition to those > > described in section Section 5. > > > > G6.1 The AAAH server MUST be able to communicate the Home Agent > > Information (IP Address or FQDN) to the NAS. > > > > G6.2 The NAS SHOULD be able to notify that it supports the > > functionalities described in [4]. > > > > G6.3 The ASP/MSP SHOULD be able to indicate to the MSA if it can > > allocate a Home Agent to the MN. > > > > G6.4 The AAA server of the MSA MUST be able to indicate to the NAS > > whether the MN is authorized to use a local Home Agent (i.e. a > > Home Agent in the ASP/MSP) > > > > > > > > Giaretta, et al. Expires March 16, 2007 [Page 8] > > > > > > Internet-Draft AAA Goals for Mobile IPv6 September 2006 > > > > > > 8. Security Considerations > > > > As stated in Section 5.1 the AAA-HA interface must provide mutual > > authentication, integrity and replay protection. Furthermore, if > > security parameters (e.g., IKE pre-shared key) are transferred > > through this interface, confidentiality is strongly recommended to be > > supported. However note that AAA protocols does not support this > > unless it exists a direct connection between corresponding entities. > > > > Madjid>> Diameter supports this. should say "some AAA protocols". > > > > > > > > -----Original Message----- > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > Sent: Tuesday, October 03, 2006 8:13 AM > > To: dime@ietf.org > > Subject: [Dime] Fwd: [Mip6] WG LC for I-d: draft-ietf-mip6-aaa-ha-goals-03 > > > > FYI, please review the document. > > > > --Gerardo > > > > ---------- Forwarded message ---------- > > From: Basavaraj Patil > > Date: Oct 3, 2006 4:49 PM > > Subject: [Mip6] WG LC for I-d: draft-ietf-mip6-aaa-ha-goals-03 > > To: mip6@ietf.org > > > > > > > > Hello, > > > > This is a Working group last call for the WG I-D: AAA Goals for Mobile > > IPv6 (draft-ietf-mip6-aaa-ha-goals-03). The draft is intended to serve > > as the AAA requirements for Mobile IPv6. > > > > Please review the I-D and submit your comments to the authors or to > > the list directly. > > > > The WGLC expires on Oct 18th, 06. > > > > The I-D is intended to be published as an Informational RFC. > > > > -Raj > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ > > 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 Nov 06 16:58:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhCTt-00049i-G0; Mon, 06 Nov 2006 16:58:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhCTs-00047W-3Y for dime@ietf.org; Mon, 06 Nov 2006 16:58:12 -0500 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhCTq-0001MA-Rl for dime@ietf.org; Mon, 06 Nov 2006 16:58:12 -0500 Received: (qmail invoked by alias); 06 Nov 2006 21:58:08 -0000 Received: from dhcp66-103.ietf67.org (EHLO [130.129.66.103]) [130.129.66.103] by mail.gmx.net (mp022) with SMTP; 06 Nov 2006 22:58:08 +0100 X-Authenticated: #29516787 Message-ID: <454FAFF1.7000500@gmx.net> Date: Mon, 06 Nov 2006 13:58:09 -0800 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-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [Dime] Diameter Tutorial: Room 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, we are going to have our tutorial in the Seabreeze room. The tutorial starts at 8pm. Ciao Hannes & John _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Nov 06 17:27:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhCwZ-00023B-Qy; Mon, 06 Nov 2006 17:27:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhCwY-00020z-DU; Mon, 06 Nov 2006 17:27:50 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhCwW-000698-PL; Mon, 06 Nov 2006 17:27:50 -0500 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 <0J8B00EGVY97BC@usaga01-in.huawei.com>; Mon, 06 Nov 2006 14:24:43 -0800 (PST) Received: from N737011 (dhcp70-96.ietf67.org [130.129.70.96]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J8B00AHPY929V@usaga01-in.huawei.com>; Mon, 06 Nov 2006 14:24:43 -0800 (PST) Date: Mon, 06 Nov 2006 14:27:43 -0800 From: Madjid Nakhjiri Subject: RE: [Dime] Fwd: [Mip6] WG LC for I-d: draft-ietf-mip6-aaa-ha-goals-03 In-reply-to: To: 'Gerardo Giaretta' Message-id: <002e01c701f2$c6dceff0$60468182@china.huawei.com> 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: AccBzisFShQSWSVATZ28r33lstjelwAJBHNA X-Spam-Score: 0.0 (/) X-Scan-Signature: e06437eb72f6703f11713d345be8298a 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 -----Original Message----- From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] Sent: Monday, November 06, 2006 10:01 AM To: Madjid Nakhjiri Cc: dime@ietf.org; mip6@ietf.org; Julien Bournelle Subject: Re: [Dime] Fwd: [Mip6] WG LC for I-d: draft-ietf-mip6-aaa-ha-goals-03 Hi Madjid, On 11/4/06, Madjid Nakhjiri wrote: > The doc calls itself AAA-HA goals, so We need to see what we need to > accomplish by the document > > 1) define AAA function requirements on HA and on HA-AAA server protocol? > > > 2) what is vendor required to put inside MIP6 HA to support AAA interaction. > > If the goal is 1) and you are not careful, you can unintentionally rule out > RADIUS. Plus some of the requirements are beyond the scope of those for AAA > client (HA) and AAA protocols. I am just pointing out that unless trying to > set up a set of goals for the Dime drafts, we need to be careful about the > side-effect of ruling out use of RADIUS for MIP6. > > Let me go through the goal > > > G1.1 The AAAH server and the HA MUST be able to authenticate each > > other (mutual authentication) in order to prevent the installation > > of unauthorized state on the HA. In some deployment scenarios, it > > may not be feasible for HA and AAAH to mutually authenticate each > > other. For example, let us consider the case where MSP is not the > > MSA. In such a case, several AAA intermediate proxies could > > forward MIP6 bootstrapping information back and forth between HA > > and AAA. Thus, to prevent the installation of unauthorized state > > on the HA, the path between HA and AAAH should be trustworthy>/ > > > > Madjid>>I am going to assume HA is AAA client, not sure, if authentication > between a AAA client and a AAA is an explicit requirement in any of the AAA > protocols. First it means a direct SA between the HA and AAAH. If there are > proxies on the AAA path, RADIUS for one does not support the end to end SA > directly, let alone the act of end to end authentication. > I understand that sending keys from AAAH to HA requires tight security, but > this is not a "AAA requirement", since it may not be covered by some AAA > protocols, it is part of security provisioning for the entire HA design. You > may want to bring this up in "security consideration section". > > You already seem to have this part of security consideration, so not sure > why it is also mentioned as AAA-HA goal, unless the goal of the doc is the > (2) mentioned above. > ok, now I get your point. However in the goal text we have already added this sentence: In some deployment scenarios, it may not be feasible for HA and AAAH to mutually authenticate each other. For example, let us consider the case where MSP is not the MSA. In such a case, several AAA intermediate proxies could forward MIP6 bootstrapping information back and forth between HA and AAA. Thus, to prevent the installation of unauthorized state on the HA, the path between HA and AAAH should be trustworthy. This was added exactly for RADIUS. Doesn't this text solve your issue? Madjid>>Yes, hence my comments, you are raising a well-known issue for RADIUS in a "AAA requirement section". Everybody knows RADIUS has this issue, so are trying to say RADIUS cannot/should not be used. If this is not your intentention (I don't think it is), you should simply remove the entire comment into the security section. It does not belong as a "AAA requirement". Madjid --Gerardo > I hope I have been helpful. > > R, > > Madjid > > > > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > Sent: Friday, November 03, 2006 6:30 AM > To: Madjid Nakhjiri > Cc: dime@ietf.org; mip6@ietf.org; Julien Bournelle > Subject: Re: [Dime] Fwd: [Mip6] WG LC for I-d: > draft-ietf-mip6-aaa-ha-goals-03 > > Hi Madjid, > > thanks for the review. Most comments are editorial and I'll fix them > in next version. Just one more detailed question below. > > > > > > 5.1. General goals > > > > G1.1 The AAAH server and the HA MUST be able to authenticate each > > other (mutual authentication) in order to prevent the installation > > of unauthorized state on the HA. In some deployment scenarios, it > > may not be feasible for HA and AAAH to mutually authenticate each > > other. For example, let us consider the case where MSP is not the > > MSA. In such a case, several AAA intermediate proxies could > > forward MIP6 bootstrapping information back and forth between HA > > and AAA. Thus, to prevent the installation of unauthorized state > > on the HA, the path between HA and AAAH should be trustworthy>/ > > > > > > Madjid>>again MSP versus MSA terminology issue. Plus the text is venturing > > into something that is more of a > > > > AAA infrastructure issue than an HA-AAAH issue. Also the text is mixing > end > > point authentication and AAA > > > > signaling security all in one requirement. Mutual authentication of HA and > > home AAA is one thing, protecting > > > > bootstrapping info over AAA messaging is another. This should be broken > into > > two requirements. I believe you > > > > have text on confidentiality in G1.4. The AAA signaling security issue is > > that of a AAA client in visited > > > > AAA domain dealing with a home AAA domain are well known. for instance if > > you don't like the transitive > > > > trust provided by the hop by hop security in RADIUS, so you need external > > ways to cure the transitive trust > > > > problem. On the other hand providing a mutual authentication procedure > > between HA and home AAA server > > > > without intervention of AAA intermediaries in a whole different problem. > So > > we need to be careful, otherwise > > > > we may end up ruling RADIUS out of here. Is that the intention? > > > > I would simply state the well known issues in the security consideration > > section. > > > > sorry but I cannot get your point clearly. > > which is your suggestion? Removing the requirement? Rephrasing it? Can > you please provide some text? > > Thanks, > --Gerardo > > > > > Giaretta, et al. Expires March 16, 2007 [Page 6] > > > > > > Internet-Draft AAA Goals for Mobile IPv6 September 2006 > > > > > > G1.2 The AAA-HA interface MUST provide integrity protection in order > > to prevent any alteration of exchanged data (e.g., Mobile IPv6 > > configuration parameters). > > > > G1.3 The AAA-HA interface MUST provide replay protection. > > > > G1.4 The AAA-HA interface SHOULD provide confidentiality since it > > may be used to transfer keying material (e.g., shared key > > generated during EAP method authentication). > > > > Madjid>>same comment as that on security in G1.1. > > > > G1.5 The AAA-HA interface SHOULD support inactive peer detection. > > This functionality can be used by the AAAH server to maintain a > > list of active HAs. > > > > > > 5.2. Service Authorization > > > > Madjid>>Typically authorization follows a successful authentication. It > > seems that the burden of the making > > > > sure the MN is authenticated falls into the lap of the HA, should we not > > have a requirement on this? > > > > G2.1 The AAA-HA interface SHOULD allow the use of Network Access > > Identifier (NAI) to identify the user. > > > > Madjid>>I believe for the split scenario. We were saying that the > > Diameter_EAP and Diameter-MIP need to use > > > > the same ID. does this cover that? Is NAI always the ID used for EAP? > > > > G2.2 The HA SHOULD be able to query the AAAH server to verify Mobile > > IPv6 service authorization for the mobile node. > > > > G2.3 The AAAH server MAY assign explicit operational limitations and > > authorization restrictions on the HA (e.g., packet filters, QoS > > parameters). > > > > G2.4 The AAAH server MUST be able to send an authorization lifetime > > to the HA to limit Mobile IPv6 session duration for the MN. > > > > G2.5 The HA MUST be able to request to the AAAH server an extension > > of the authorization lifetime granted to the MN. > > > > G2.6 The AAAH server MUST be able to force the HA to terminate an > > active Mobile IPv6 session for authorization policy reasons (e.g., > > credit exhaustion). > > > > > > 5.3. Accounting > > > > G3.1 The AAA-HA interface MUST support the transfer of accounting > > records needed for service control and charging. These include > > (but may not be limited to): time of binding cache entry creation > > and deletion, octets sent and received by the mobile node in bi- > > directional tunneling, etc. > > > > > > > > > > > > > > Giaretta, et al. Expires March 16, 2007 [Page 7] > > > > > > Internet-Draft AAA Goals for Mobile IPv6 September 2006 > > > > > > 5.4. Mobile Node Authentication > > > > G4.1 The AAA-HA interface MUST support pass-through EAP > > authentication with the HA working as EAP authenticator operating > > in pass-through mode and the AAAH server working as back-end > > authentication server. > > > > Madjid>>Does this really have to be a MUST? > > > > 5.5. Provisioning of Configuration Parameters > > > > G5.1 The HA SHOULD be able to communicate to the AAAH server the > > Home Address allocated to the MN (e.g., for allowing the AAAH > > server to perform a DNS update on behalf of the MN). > > > > G5.2 The AAAH SHOULD be able to indicate to the HA if the MN is > > authorized to autoconfigure its Home Address. > > > > > > > > 6. Goals for the Integrated Scenario > > > > In the integrated scenario, the AAA server provides the HA > > information to the NAS as part of the whole AAA operations for > > network access. Next goals are considered in addition to those > > described in section Section 5. > > > > G6.1 The AAAH server MUST be able to communicate the Home Agent > > Information (IP Address or FQDN) to the NAS. > > > > G6.2 The NAS SHOULD be able to notify that it supports the > > functionalities described in [4]. > > > > G6.3 The ASP/MSP SHOULD be able to indicate to the MSA if it can > > allocate a Home Agent to the MN. > > > > G6.4 The AAA server of the MSA MUST be able to indicate to the NAS > > whether the MN is authorized to use a local Home Agent (i.e. a > > Home Agent in the ASP/MSP) > > > > > > > > Giaretta, et al. Expires March 16, 2007 [Page 8] > > > > > > Internet-Draft AAA Goals for Mobile IPv6 September 2006 > > > > > > 8. Security Considerations > > > > As stated in Section 5.1 the AAA-HA interface must provide mutual > > authentication, integrity and replay protection. Furthermore, if > > security parameters (e.g., IKE pre-shared key) are transferred > > through this interface, confidentiality is strongly recommended to be > > supported. However note that AAA protocols does not support this > > unless it exists a direct connection between corresponding entities. > > > > Madjid>> Diameter supports this. should say "some AAA protocols". > > > > > > > > -----Original Message----- > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > Sent: Tuesday, October 03, 2006 8:13 AM > > To: dime@ietf.org > > Subject: [Dime] Fwd: [Mip6] WG LC for I-d: draft-ietf-mip6-aaa-ha-goals-03 > > > > FYI, please review the document. > > > > --Gerardo > > > > ---------- Forwarded message ---------- > > From: Basavaraj Patil > > Date: Oct 3, 2006 4:49 PM > > Subject: [Mip6] WG LC for I-d: draft-ietf-mip6-aaa-ha-goals-03 > > To: mip6@ietf.org > > > > > > > > Hello, > > > > This is a Working group last call for the WG I-D: AAA Goals for Mobile > > IPv6 (draft-ietf-mip6-aaa-ha-goals-03). The draft is intended to serve > > as the AAA requirements for Mobile IPv6. > > > > Please review the I-D and submit your comments to the authors or to > > the list directly. > > > > The WGLC expires on Oct 18th, 06. > > > > The I-D is intended to be published as an Informational RFC. > > > > -Raj > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ > > 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 Nov 07 13:26:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhVeN-0005JF-D7; Tue, 07 Nov 2006 13:26:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhVeM-0005JA-04 for dime@ietf.org; Tue, 07 Nov 2006 13:26:18 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhVeH-000298-I6 for dime@ietf.org; Tue, 07 Nov 2006 13:26:17 -0500 Received: (qmail invoked by alias); 07 Nov 2006 18:26:01 -0000 Received: from dhcp66-103.ietf67.org (EHLO [130.129.66.103]) [130.129.66.103] by mail.gmx.net (mp028) with SMTP; 07 Nov 2006 19:26:01 +0100 X-Authenticated: #29516787 Message-ID: <4550CFBA.8080206@gmx.net> Date: Tue, 07 Nov 2006 10:26:02 -0800 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-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Dime] Diameter Tutorial Slides 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 put the slides from yesterday's tutorial to http://www.tschofenig.priv.at/cgi-bin/tutorial/wiki.pl?Organization Here are the direct links: Diameter Base: http://www.tschofenig.priv.at/dime/IETF67/ietf67-diameter-tutorial.ppt Diameter Credit Control: http://www.tschofenig.priv.at/dime/IETF67/ietf67_diameter_credit_control_tutorial.ppt Thanks to the presenters! I got the impression that the participants liked the idea and hence we will talk to the EDU team to see whether we can schedule a similar tutorial for the next IETF meeting (and the tutorial could be in the early afternoon). Ciao Hannes & John PS: Someone has recorded the entire tutorial. The person might want to send me a mail so that we could potentially put the video online. That would be nice as well. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 07 14:22:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWWa-000131-37; Tue, 07 Nov 2006 14:22:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWWY-0000yg-Ge for dime@ietf.org; Tue, 07 Nov 2006 14:22:18 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhWWX-0001MO-8f for dime@ietf.org; Tue, 07 Nov 2006 14:22:18 -0500 Received: (qmail invoked by alias); 07 Nov 2006 19:22:15 -0000 Received: from dhcp66-103.ietf67.org (EHLO [130.129.66.103]) [130.129.66.103] by mail.gmx.net (mp001) with SMTP; 07 Nov 2006 20:22:15 +0100 X-Authenticated: #29516787 Message-ID: <4550DCE7.2030801@gmx.net> Date: Tue, 07 Nov 2006 11:22:15 -0800 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-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [Dime] Slides, please 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 need to upload the slides to have them ready for the meeting. Please send them to us asap. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 08 13:13:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhrvW-0005QF-1W; Wed, 08 Nov 2006 13:13:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhrvT-0005Ph-VO for dime@ietf.org; Wed, 08 Nov 2006 13:13:27 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhrvS-0004BO-LM for dime@ietf.org; Wed, 08 Nov 2006 13:13:27 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA8IDOn12213 for ; Wed, 8 Nov 2006 13:13:24 -0500 (EST) Received: from [47.102.178.90] ([47.102.178.90] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 13:13:22 -0500 Message-ID: <45521E39.3010901@nortel.com> Date: Wed, 08 Nov 2006 10:13:13 -0800 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2006 18:13:23.0025 (UTC) FILETIME=[93D4B410:01C70361] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Dime] Redirection question 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'm a little unclear on the coexistence of Redirect-xx AVPs and other application-specific (as opposed to Diameter housekeeping) AVPs in command answers. My understanding is that an answer with the Redirect-xx AVPs in it hasn't really been answered -- it is still in the process of being routed. Am I right in my surmise that the receiver of an answer with Redirect-xx AVPs uses them to update its routing tables, but then strips them out of the redirected request? With the result that a real answer will never contain the Redirect-xx AVPs? Tom Taylor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 08 16:34:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghv42-0008A0-NI; Wed, 08 Nov 2006 16:34:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghv40-00089p-Mx for dime@ietf.org; Wed, 08 Nov 2006 16:34:28 -0500 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghv3z-00085o-8E for dime@ietf.org; Wed, 08 Nov 2006 16:34:28 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA8LYMoc000515; Wed, 8 Nov 2006 23:34:25 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 23:34:23 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 23:34:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 8 Nov 2006 23:34:22 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AAA-WG]: [AAA-WG] Two-factor authentication support Thread-Index: AccBzpbSrh109iHZSpKRN8NjgiDRxgBrvs5A From: To: X-OriginalArrivalTime: 08 Nov 2006 21:34:22.0344 (UTC) FILETIME=[A7BEC080:01C7037D] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: smustaoglu@gmail.com Subject: [Dime] FW: [AAA-WG]: [AAA-WG] Two-factor authentication support 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="===============1686173262==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1686173262== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7037D.A7DADCC3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7037D.A7DADCC3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Forwarded to the DiME mailing list. =20 John ________________________________ From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of ext serdar mustaoglu Sent: 06 November, 2006 19:42 To: aaa-wg@merit.edu Subject: [AAA-WG]: [AAA-WG] Two-factor authentication support =09 =09 =09 =09 =20 Is there any support for Two-factor authentication in diameter protocol? Or password AVP is used for keep the passcode and otp at the same time?=20 =20 =20 for reference, Two-factor authentication : http://en.wikipedia.org/wiki/Strong_authentication=20 =20 Thanks, =09 Serdar =20 ------_=_NextPart_001_01C7037D.A7DADCC3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Forwarded to the DiME mailing = list.
 
John

From: owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu] On Behalf Of ext serdar=20 mustaoglu
Sent: 06 November, 2006 19:42
To:=20 aaa-wg@merit.edu
Subject: [AAA-WG]: [AAA-WG] Two-factor=20 authentication support
 
Is there any support for Two-factor authentication in diameter = protocol?=20 Or password AVP is used for keep the passcode and otp at the same = time?
 
 
for reference, Two-factor authentication : http://en.wikipedia.org/wiki/Strong_authentication =
 
Thanks,
Serdar
 
------_=_NextPart_001_01C7037D.A7DADCC3-- --===============1686173262== 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 --===============1686173262==-- From dime-bounces@ietf.org Thu Nov 09 08:00:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi9Vb-0001Zg-DE; Thu, 09 Nov 2006 07:59:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi9VZ-0001ZV-WB for dime@ietf.org; Thu, 09 Nov 2006 07:59:54 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi9VX-0007FC-Is for dime@ietf.org; Thu, 09 Nov 2006 07:59:53 -0500 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 <0J8G00F9ZRYMMK@usaga01-in.huawei.com> for dime@ietf.org; Thu, 09 Nov 2006 04:56:46 -0800 (PST) Received: from huawei.com ([172.17.1.188]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8G00ATHRYL9P@usaga01-in.huawei.com> for dime@ietf.org; Thu, 09 Nov 2006 04:56:46 -0800 (PST) Received: from [172.24.1.24] (Forwarded-For: [10.164.5.61]) by szxmc01-in.huawei.com (mshttpd); Thu, 09 Nov 2006 20:59:48 +0800 Date: Thu, 09 Nov 2006 20:59:48 +0800 From: lijijun 41867 Subject: =?gb2312?B?u9i4tA==?=:[Dime] Diameter Event-Timestamp To: Paulo Rolo Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: multipart/mixed; boundary="Boundary_(ID_vmAPP8cG0wNp5O/I+RUbLw)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal X-Spam-Score: 0.3 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 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 This is a multi-part message in MIME format. --Boundary_(ID_vmAPP8cG0wNp5O/I+RUbLw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline >Paulo Rolo writed: >I have a question concerning Diameter Event-Timestamp AVP data type. > >RFC 3588 states that its type is Time, and the same rfc presents Time as derived from >OctectString. However, I have found that several Diameter implementations use Unsigned32 >type. some Diameter implementations use Unsigned32 as Time type ,just because it is easy to transform between Unsigned32 and OctectString. On the case of the four octets and actual time format(NTP Timestamp format),it don't arose errors. Note that,RFC2030 NTP timestamps are represented as a 64-bit unsigned fixed-point number, in seconds relative to 0h on 1 January 1900. The integer part is in the first 32 bits and the fraction part in the last 32 bits. In the fraction part, the non-significant low order can be set to 0. Jimmy li --Boundary_(ID_vmAPP8cG0wNp5O/I+RUbLw) Content-type: multipart/alternative; boundary="Boundary_(ID_41gVJE/Js91KZitmP1ZE6A)" Content-class: urn:content-classes:message --Boundary_(ID_41gVJE/Js91KZitmP1ZE6A) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hello all, I have a question concerning Diameter Event-Timestamp AVP data type. RFC 3588 states that its type is Time, and the same rfc presents Time as derived from OctectString. However, I have found that several Diameter implementations use Unsigned32 type. Thanks in advance, Paulo Rolo --Boundary_(ID_41gVJE/Js91KZitmP1ZE6A) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hello all,

 

I have a question concerning Diameter Event-Timestamp AVP data type.

RFC 3588 states that its type is Time, and the same rfc presents Time as derived from OctectString. However, I have found that several Diameter implementations use Unsigned32 type.

 

Thanks in advance,

Paulo Rolo

 

 

 

--Boundary_(ID_41gVJE/Js91KZitmP1ZE6A)-- --Boundary_(ID_vmAPP8cG0wNp5O/I+RUbLw) MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --Boundary_(ID_vmAPP8cG0wNp5O/I+RUbLw) 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 --Boundary_(ID_vmAPP8cG0wNp5O/I+RUbLw)-- From dime-bounces@ietf.org Thu Nov 09 08:27:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi9vs-0006xl-Rc; Thu, 09 Nov 2006 08:27:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi9vs-0006xE-2B for dime@ietf.org; Thu, 09 Nov 2006 08:27:04 -0500 Received: from moutng.kundenserver.de ([212.227.126.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi9vn-00062v-JS for dime@ietf.org; Thu, 09 Nov 2006 08:27:04 -0500 Received: from [87.139.124.104] (helo=[192.168.10.16]) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1Gi9vm3Jql-0001Cl; Thu, 09 Nov 2006 14:26:59 +0100 Message-ID: <45532CA2.7050609@TriaGnoSys.com> Date: Thu, 09 Nov 2006 14:26:58 +0100 From: Frank Kuehndel User-Agent: Mozilla Thunderbird (X11/20050322) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dime@ietf.org X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Provags-ID: kundenserver.de abuse@kundenserver.de login:a40d15b21f2b77d10fb308d4de5f241f X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: [Dime] RFC3588 Missing States in the Auth State Machine 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 Hello everybody, I was ask by Victor Fajardo to forward some text to this mailing list. This text bases on an email, which I send earlier to the OpenDiameter mailing list. It occurs to me that there are two issues missing in Section 8.1 "Authorization Session State Machine" of RFC3588 from September 2003: 1) User Initiated Termination on the Clint Side. The client state machine permits the sending of STR (Session-Termination-Request) in open state only for "Session-Timeout" and "ARA received" but not on user request. What when the user wants to terminate the session? (See also closed OpenDiameter bug "1465587 Client cannot terminate a session") 2) Server Sends Requests to the User Slide 30 (titled "Improvements over Radius") of the Diameter Tutorial shows the point "Server-initiated messages". Yet, in the authorization server state machine the server sends only answers or ASR (Abort-Session- Requests) to the client in open state. (See also closed OpenDiameter bug "1338402 client cannot receive service/application specific requests") I have never worked with the Accounting-State-Machine, so I do not know whether the same points apply there, too. Greetings, Frank References OpenDiameter mailing list https://lists.sourceforge.net/lists/listinfo/diameter-developers OpenDiameter bug 1465587 http://sourceforge.net/tracker/index.php?func=detail&aid=1465587&group_id=43533&atid=436637 OpenDiameter bug 1338402 http://sourceforge.net/tracker/index.php?func=detail&aid=1338402&group_id=43533&atid=436637 RFC3588 from September 2003 http://www.rfc-editor.org/rfc/rfc3588.txt Victor's "Diameter Protocol Errata and Issues" http://www.opendiameter.org/public/draft-fajardo-dime-diameter-errata-00.txt Victor and Yoshihiro Ohba's "Diameter Base Protocol Details" tutorial slides http://www.opendiameter.org/public/ietf67-diameter-tutorial.ppt _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Nov 10 19:20:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GigbN-0006QU-Hf; Fri, 10 Nov 2006 19:20:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GigbM-0006QP-LU for dime@ietf.org; Fri, 10 Nov 2006 19:20:04 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GigbL-0005x7-7v for dime@ietf.org; Fri, 10 Nov 2006 19:20:04 -0500 Received: (qmail invoked by alias); 11 Nov 2006 00:13:22 -0000 Received: from 0127bhost175.starwoodbroadband.com (EHLO [12.105.247.175]) [12.105.247.175] by mail.gmx.net (mp028) with SMTP; 11 Nov 2006 01:13:22 +0100 X-Authenticated: #29516787 Message-ID: <455515A0.9050106@gmx.net> Date: Fri, 10 Nov 2006 16:13:20 -0800 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: dime@ietf.org 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: de4f315c9369b71d7dd5909b42224370 Cc: lionel.morand@francetelecom.com, mamuhanna@nortel.com, "Glen Zorn \(gwz\)" Subject: [Dime] Expert Reviewers Nominated 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, during the DIME meeting we selected expert reviewers for the HA<->AAAH document (http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-01.txt): * Glen Zorn * Lionel Morand * Ahmad Muhanna Since a number of issues have been raised during the meeting I would suggest to also jump into the discussions. I will send a separate mail with a description of the raised aspects. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Nov 10 19:25:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gigh4-0007xI-0q; Fri, 10 Nov 2006 19:25:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gigh3-0007xC-2U for dime@ietf.org; Fri, 10 Nov 2006 19:25:57 -0500 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gigh1-0006NL-L3 for dime@ietf.org; Fri, 10 Nov 2006 19:25:57 -0500 Received: (qmail invoked by alias); 11 Nov 2006 00:25:54 -0000 Received: from 0127bhost175.starwoodbroadband.com (EHLO [12.105.247.175]) [12.105.247.175] by mail.gmx.net (mp017) with SMTP; 11 Nov 2006 01:25:54 +0100 X-Authenticated: #29516787 Message-ID: <4555188F.9080604@gmx.net> Date: Fri, 10 Nov 2006 16:25:51 -0800 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: dime@ietf.org 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: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split 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, during the DIME meeting Glen raised an important question that impacts the design of the protocol, namely: " Do we need to support the scenario where the Diameter EAP authentication and the Diameter MIPv6 authorization exchange terminate at different servers? " Currently, we assume that these two exchanges could be terminated at different servers. As a consequence, security concerns were raised (see slide 5 of http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt). How do people think about restricting the Diameter MIPv6 HA-to-AAAH document to terminate the authentication and authorization exchange at the same server? Ciao Hannes PS: Glen also suggested to consider using the Diameter MIPv6 App-ID for the Diameter EAP exchange if we decide that both exchanges terminate at the same server. As a consequence the open issue described at slide 6 of http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt would also be resolved. The changes to the existing document would be minimal (about 2 additional sentences). _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 14 08:00:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjxtv-0007BN-Ij; Tue, 14 Nov 2006 08:00:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjxtu-0007AI-TP for dime@ietf.org; Tue, 14 Nov 2006 08:00:30 -0500 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjxts-00070X-CA for dime@ietf.org; Tue, 14 Nov 2006 08:00:30 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAECwjYj028300; Tue, 14 Nov 2006 15:00:12 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 14:59:57 +0200 Received: from [172.21.34.112] ([172.21.34.112]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 14 Nov 2006 14:59:56 +0200 Message-ID: <4559BDCC.6060200@nokia.com> Date: Tue, 14 Nov 2006 14:59:56 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: AAA mailing list , dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Nov 2006 12:59:56.0773 (UTC) FILETIME=[C8E8E150:01C707EC] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Mari Carmen belinchon , Miguel-Angel Pallares , "Carolina Canales \(ML/EEM\)" Subject: [Dime] Diameter SIP app in AUTH48 state 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 My apologies for cross posting to both Dime and AAA. The Diameter SIP application is in AUTH48 state. The authors have gone through one more review of the document, and found an issue that requires your review and comments. So please review the issue and comment (both agreements and complaints). Issue 4: The Diameter server must store the SIP server URI received in the MAR message and return it in the UAA and LIA messages. However the MAR can be either related to stateless proxy authentication (figure 4) or to UA authentication where the proxy remains as main SIP server and in the path for signaling (figure 2 and 3). We don't want that in a mix scenario a stateless SIP proxy request authentication and overrides with its own URI the SIP server assignment in the Diameter server. So we need a mechanism for the Diameter server to distinguish to which scenario the MAR is related and whether it has to store a SIP server or not. Our proposal is that the MAR contains a SIP-Server AVP depending on whether the SIP server is stateful and pretends to remain in the signaling path. So please comment on this proposal to modify Section 8.7, 2nd paragraph. Replace OLD: The MAR command also registers the SIP server's own URI to the Diameter server, so that future LIR/LIA messages can return this URI. With NEW: The MAR command also registers the SIP server's own URI to the Diameter server, so that future LIR/LIA messages can return this URI. In scenarios where a SIP server (Diameter client) does not intend to remain in the signaling path as the main SIP server for that user, such as the scenario presented in Section 6.4, the Diameter client (SIP server) MUST NOT include a SIP-Server-URI AVP in the MAR message. In scenarios where a SIP server (Diameter client) intends to remain in the signaling path as the main SIP server for that user, such as the scenarios presented in Sections 6.2 and 6.3, the Diameter Client (SIP server) MUST include its own SIP URI in the SIP-Server-URI AVP in the MAR message. For your convenience, the latest version of the draft is: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-sip-app-12.txt BR, Miguel -- 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 Tue Nov 14 09:08:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjyxY-0000Mz-3Y; Tue, 14 Nov 2006 09:08:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjyxW-0000Mn-RY for dime@ietf.org; Tue, 14 Nov 2006 09:08:18 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjyxV-0007dN-Cy for dime@ietf.org; Tue, 14 Nov 2006 09:08:18 -0500 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 15:08:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter SIP app in AUTH48 state Date: Tue, 14 Nov 2006 15:08:11 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02604073A42@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter SIP app in AUTH48 state Thread-Index: AccH70rw2mCyQWQUTzuBTz8NoyRJowAA77/w From: "MORAND Lionel RD-CORE-ISS" To: "Miguel Garcia" , "AAA mailing list" , X-OriginalArrivalTime: 14 Nov 2006 14:08:08.0587 (UTC) FILETIME=[4FD225B0:01C707F6] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: Mari Carmen belinchon , Miguel-Angel Pallares , "Carolina Canales \(ML/EEM\)" 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 Miguel, I'm OK with the general intent. But I have a couple of questions: - Is the wording "as the main SIP server for that user" refers to the = function of SIP registrar? - Do you agree that the diameter shall only store the URI of a SIP = registrar? If "yes" is the answer to both questions, would it be better to simplify = the text as follow: "The MAR command may also register the SIP server's own URI to the = Diameter server, so that future LIR/LIA messages can return this URI. The Diameter client of a SIP server acting as a SIP registrar MUST = include a SIP-Server-URI AVP in the MAR command. In any other case, the = SIP-Server-URI AVP MUST NOT be present in the MAR command." But I may miss some specific configuration cases. If it is the case, = sorry for that and forget my proposal! BR, Lionel > -----Message d'origine----- > De : Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com]=20 > Envoy=E9 : mardi 14 novembre 2006 14:00 > =C0 : AAA mailing list; dime@ietf.org > Cc : Mari Carmen belinchon; Miguel-Angel Pallares; Carolina=20 > Canales (ML/EEM) > Objet : [Dime] Diameter SIP app in AUTH48 state >=20 > My apologies for cross posting to both Dime and AAA. >=20 > The Diameter SIP application is in AUTH48 state. The authors=20 > have gone through one more review of the document, and found=20 > an issue that requires your review and comments. So please=20 > review the issue and comment (both agreements and complaints). >=20 > Issue 4: The Diameter server must store the SIP server URI=20 > received in the MAR message and return it in the UAA and LIA=20 > messages. However the MAR can be either related to stateless=20 > proxy authentication (figure 4) or to UA authentication where=20 > the proxy remains as main SIP server and in the path for=20 > signaling (figure 2 and 3). We don't want that in a mix=20 > scenario a stateless SIP proxy request authentication and=20 > overrides with its own URI the SIP server assignment in the=20 > Diameter server. So we need a mechanism for the Diameter=20 > server to distinguish to which scenario the MAR is related=20 > and whether it has to store a SIP server or not. >=20 > Our proposal is that the MAR contains a SIP-Server AVP=20 > depending on whether the SIP server is stateful and pretends=20 > to remain in the signaling path. >=20 > So please comment on this proposal to modify Section 8.7, 2nd=20 > paragraph. >=20 > Replace OLD: > The MAR command also registers the SIP server's own URI to=20 > the Diameter server, so that future LIR/LIA messages can=20 > return this URI. >=20 > With NEW: > The MAR command also registers the SIP server's own URI to=20 > the Diameter server, so that future LIR/LIA messages can=20 > return this URI. > In scenarios where a SIP server (Diameter client) does not=20 > intend to remain in the signaling path as the main SIP server=20 > for that user, such as the scenario presented in Section 6.4,=20 > the Diameter client (SIP server) MUST NOT include a=20 > SIP-Server-URI AVP in the MAR message. In scenarios where a=20 > SIP server (Diameter client) intends to remain in the=20 > signaling path as the main SIP server for that user, such as=20 > the scenarios presented in Sections 6.2 and 6.3, the Diameter=20 > Client (SIP server) MUST include its own SIP URI in the=20 > SIP-Server-URI AVP in the MAR message. >=20 >=20 > For your convenience, the latest version of the draft is: > http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-si > p-app-12.txt >=20 >=20 > BR, >=20 > Miguel > --=20 > Miguel A. Garcia tel:+358-50-4804586 > sip:miguel.garcia@neonsite.net > Nokia Research Center Helsinki, Finland >=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 Nov 14 10:29:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0EH-0002KN-Tk; Tue, 14 Nov 2006 10:29:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0EG-0002KH-IY for dime@ietf.org; Tue, 14 Nov 2006 10:29:40 -0500 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk0EE-0002lF-TN for dime@ietf.org; Tue, 14 Nov 2006 10:29:40 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAEFROrm026672; Tue, 14 Nov 2006 17:28:57 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 17:27:24 +0200 Received: from [172.21.34.112] ([172.21.34.112]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 14 Nov 2006 17:27:23 +0200 Message-ID: <4559E05B.9050705@nokia.com> Date: Tue, 14 Nov 2006 17:27:23 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: MORAND Lionel RD-CORE-ISS Subject: Re: [Dime] Diameter SIP app in AUTH48 state References: <7DBAFEC6A76F3E42817DF1EBE64CB02604073A42@FTRDMEL2.rd.francetelecom.fr> In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB02604073A42@FTRDMEL2.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 14 Nov 2006 15:27:23.0822 (UTC) FILETIME=[62296CE0:01C70801] X-Nokia-AV: Clean Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mgw-ext12.nokia.com id kAEFROrm026672 X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: Mari Carmen belinchon , Miguel-Angel Pallares , AAA mailing list , dime@ietf.org, "Carolina Canales \(ML/EEM\)" 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 Lionel: I think you are correct. I am fine with your improved wording. /Miguel MORAND Lionel RD-CORE-ISS wrote: > Hi Miguel, >=20 > I'm OK with the general intent. But I have a couple of questions: >=20 > - Is the wording "as the main SIP server for that user" refers to the f= unction of SIP registrar? > - Do you agree that the diameter shall only store the URI of a SIP regi= strar? >=20 > If "yes" is the answer to both questions, would it be better to simplif= y the text as follow: >=20 > "The MAR command may also register the SIP server's own URI to the Diam= eter server, so that future LIR/LIA messages can return this URI. > The Diameter client of a SIP server acting as a SIP registrar MUST incl= ude a SIP-Server-URI AVP in the MAR command. In any other case, the SIP-S= erver-URI AVP MUST NOT be present in the MAR command." >=20 > But I may miss some specific configuration cases. If it is the case, so= rry for that and forget my proposal! >=20 > BR, >=20 > Lionel >=20 >> -----Message d'origine----- >> De : Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com]=20 >> Envoy=E9 : mardi 14 novembre 2006 14:00 >> =C0 : AAA mailing list; dime@ietf.org >> Cc : Mari Carmen belinchon; Miguel-Angel Pallares; Carolina=20 >> Canales (ML/EEM) >> Objet : [Dime] Diameter SIP app in AUTH48 state >> >> My apologies for cross posting to both Dime and AAA. >> >> The Diameter SIP application is in AUTH48 state. The authors=20 >> have gone through one more review of the document, and found=20 >> an issue that requires your review and comments. So please=20 >> review the issue and comment (both agreements and complaints). >> >> Issue 4: The Diameter server must store the SIP server URI=20 >> received in the MAR message and return it in the UAA and LIA=20 >> messages. However the MAR can be either related to stateless=20 >> proxy authentication (figure 4) or to UA authentication where=20 >> the proxy remains as main SIP server and in the path for=20 >> signaling (figure 2 and 3). We don't want that in a mix=20 >> scenario a stateless SIP proxy request authentication and=20 >> overrides with its own URI the SIP server assignment in the=20 >> Diameter server. So we need a mechanism for the Diameter=20 >> server to distinguish to which scenario the MAR is related=20 >> and whether it has to store a SIP server or not. >> >> Our proposal is that the MAR contains a SIP-Server AVP=20 >> depending on whether the SIP server is stateful and pretends=20 >> to remain in the signaling path. >> >> So please comment on this proposal to modify Section 8.7, 2nd=20 >> paragraph. >> >> Replace OLD: >> The MAR command also registers the SIP server's own URI to=20 >> the Diameter server, so that future LIR/LIA messages can=20 >> return this URI. >> >> With NEW: >> The MAR command also registers the SIP server's own URI to=20 >> the Diameter server, so that future LIR/LIA messages can=20 >> return this URI. >> In scenarios where a SIP server (Diameter client) does not=20 >> intend to remain in the signaling path as the main SIP server=20 >> for that user, such as the scenario presented in Section 6.4,=20 >> the Diameter client (SIP server) MUST NOT include a=20 >> SIP-Server-URI AVP in the MAR message. In scenarios where a=20 >> SIP server (Diameter client) intends to remain in the=20 >> signaling path as the main SIP server for that user, such as=20 >> the scenarios presented in Sections 6.2 and 6.3, the Diameter=20 >> Client (SIP server) MUST include its own SIP URI in the=20 >> SIP-Server-URI AVP in the MAR message. >> >> >> For your convenience, the latest version of the draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-si >> p-app-12.txt >> >> >> BR, >> >> Miguel >> --=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 >> --=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 Tue Nov 14 15:46:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk5AV-0007he-ME; Tue, 14 Nov 2006 15:46:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk5AV-0007hZ-6c for dime@ietf.org; Tue, 14 Nov 2006 15:46:07 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gk5AT-0001s6-UZ for dime@ietf.org; Tue, 14 Nov 2006 15:46:07 -0500 Received: (qmail invoked by alias); 14 Nov 2006 20:46:04 -0000 Received: from p549849D0.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.73.208] by mail.gmx.net (mp044) with SMTP; 14 Nov 2006 21:46:04 +0100 X-Authenticated: #29516787 Message-ID: <455A2B12.9090005@gmx.net> Date: Tue, 14 Nov 2006 21:46:10 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: dime@ietf.org 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: 7aefe408d50e9c7c47615841cb314bed Subject: [Dime] Meeting Minutes 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, here are the meeting minutes. Please take a look at: http://www3.ietf.org/proceedings/06nov/minutes/dime.txt Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 14 16:34:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk5vG-0005vj-9g; Tue, 14 Nov 2006 16:34:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk5vE-0005tW-Np for dime@ietf.org; Tue, 14 Nov 2006 16:34:24 -0500 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 1Gk5v9-0000aN-N4 for dime@ietf.org; Tue, 14 Nov 2006 16:34:24 -0500 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 kAELXYSX018033 for ; Tue, 14 Nov 2006 16:33:34 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <455A366A.1030503@tari.toshiba.com> Date: Tue, 14 Nov 2006 16:34:34 -0500 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Dime] Updated errata draft for 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, An updated version of diameter errata draft can be found in: http://www.opendiameter.org/public/draft-fajardo-dime-diameter-errata-01.txt This version includes the comments and decisions made during IETF67 DIME meeting. Note that all open issues now have proposed solutions. Pls review them so we can move forward. best regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 14 23:57:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkCpl-0002oo-Tg; Tue, 14 Nov 2006 23:57:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkCpk-0002fj-Qx for dime@ietf.org; Tue, 14 Nov 2006 23:57:12 -0500 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkCcY-0005DP-BQ for dime@ietf.org; Tue, 14 Nov 2006 23:43:37 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 953791E02A9 for ; Tue, 14 Nov 2006 23:43:30 -0500 (EST) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05835-18 for ; Tue, 14 Nov 2006 23:43:26 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Tue, 14 Nov 2006 23:43:26 -0500 (EST) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 23:43:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split Date: Tue, 14 Nov 2006 23:43:26 -0500 Message-ID: <7CCD07160348804497EF29E9EA5560D7FBD4E9@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split Thread-Index: AccFKAZ94vmkmxRDTxe3d8IahZiZFADRWa3w From: "Chowdhury, Kuntal" To: "Hannes Tschofenig" , X-OriginalArrivalTime: 15 Nov 2006 04:43:26.0649 (UTC) FILETIME=[97067290:01C70870] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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, IMHO, at the time of EAP authentication the MS needs to be authorized for MIP6 service. This is because: Regardless of whether EAP is used or some other auth method is used to authenticate the MN, the entity that is authenticating the MN is the MSA. The MSA by definition (Mobility Service Authorizer) needs to Authenticate and Authorize the MN. For HoA bootstrapping, at the time of IKEv2 transaction the HA needs to know whether the MN is authorized for mobility service (MIP6 in this case) or not. Therefore, the AAA server needs to either return an AVP along with EAP-Success to indicate to the HA that the MN is authorized for MIP6 service or the AAA server can return the address of another AAA server in the MSA that needs to be contacted for MIP6 authorization for the MN.=20 I think the former (MIP6 authorization AVP along with EAP success) is a better option. In that case a single server for both auth and authz should be suffice. -Kuntal > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Friday, November 10, 2006 6:26 PM > To: dime@ietf.org > Subject: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split >=20 > Hi all, >=20 > during the DIME meeting Glen raised an important question that impacts > the design of the protocol, namely: > " > Do we need to support the scenario where the Diameter EAP authentication > and the Diameter MIPv6 authorization exchange terminate at different > servers? > " >=20 > Currently, we assume that these two exchanges could be terminated at > different servers. As a consequence, security concerns were raised (see > slide 5 > of http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt). >=20 > How do people think about restricting the Diameter MIPv6 HA-to-AAAH > document to terminate the authentication and authorization exchange at > the same server? >=20 > Ciao > Hannes >=20 > PS: Glen also suggested to consider using the Diameter MIPv6 App-ID for > the Diameter EAP exchange if we decide that both exchanges terminate at > the same server. As a consequence the open issue described at slide 6 of > http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt would also be > resolved. The changes to the existing document would be minimal (about 2 > additional sentences). >=20 >=20 > _______________________________________________ > 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 Nov 15 07:34:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkJy7-0005GZ-BE; Wed, 15 Nov 2006 07:34:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkJy6-0005GU-E0 for dime@ietf.org; Wed, 15 Nov 2006 07:34:18 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GkJy3-0003mO-6j for dime@ietf.org; Wed, 15 Nov 2006 07:34:18 -0500 X-VirusChecked: Checked X-Env-Sender: vishnu@motorola.com X-Msg-Ref: server-15.tower-128.messagelabs.com!1163594054!5261837!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.9] Received: (qmail 7474 invoked from network); 15 Nov 2006 12:34:14 -0000 Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-15.tower-128.messagelabs.com with SMTP; 15 Nov 2006 12:34:14 -0000 Received: from az33exr02.mot.com ([10.64.251.232]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id kAFCYDLJ012376 for ; Wed, 15 Nov 2006 06:34:13 -0600 (CST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id kAFCYBk1029636 for ; Wed, 15 Nov 2006 06:34:12 -0600 (CST) 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 Mobile IPv6 HA-to-AAAH Support: Server Split Date: Wed, 15 Nov 2006 20:34:09 +0800 Message-ID: In-Reply-To: <7CCD07160348804497EF29E9EA5560D7FBD4E9@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split thread-index: AccFKAZ94vmkmxRDTxe3d8IahZiZFADRWa3wABCgXcA= From: "Ram O V Vishnu-A14676" To: "Chowdhury, Kuntal" , "Hannes Tschofenig" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 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 think this "split-within-split" (if I may call it so) is hard to understand.=20 In slide-5, I don't see any interface between AAA-EAP Server and AAA-MIP6 Server, but I definitely see that they are boxed together as an MSA. Hence I conclude that there is no question of interoperability or something between these. It's the MSA's job to authenticate & authorize MIP. It could do it using 2 server, 3, 4 etc. It could do it using 2 processes, 2 tasks, 2 threads too. In either of these cases, since it has taken up the responsibility of doing the auth & auth, it has to have some mechanism of making sure no security hole exist.=20 So, as it stands, in slide-5, the AAA-EAP server and AAA-MIP6 server might as well be not shown. MSA could be shown as a black box. If someone could shed some light on the motivation behind the split, any other arrows/interfaces which might land on AAA-EAP Server or on AAA-MIP6 Server, it would be interesting to discuss those. Regards, Vishnu. Motorola +91 9844178052 [] General [*] Motorola Internal Use Only -----Original Message----- From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20 Sent: Wednesday, November 15, 2006 10:13 AM To: Hannes Tschofenig; dime@ietf.org Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split Hi Hannes, IMHO, at the time of EAP authentication the MS needs to be authorized for MIP6 service. This is because: Regardless of whether EAP is used or some other auth method is used to authenticate the MN, the entity that is authenticating the MN is the MSA. The MSA by definition (Mobility Service Authorizer) needs to Authenticate and Authorize the MN. For HoA bootstrapping, at the time of IKEv2 transaction the HA needs to know whether the MN is authorized for mobility service (MIP6 in this case) or not. Therefore, the AAA server needs to either return an AVP along with EAP-Success to indicate to the HA that the MN is authorized for MIP6 service or the AAA server can return the address of another AAA server in the MSA that needs to be contacted for MIP6 authorization for the MN.=20 I think the former (MIP6 authorization AVP along with EAP success) is a better option. In that case a single server for both auth and authz should be suffice. -Kuntal > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Friday, November 10, 2006 6:26 PM > To: dime@ietf.org > Subject: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split >=20 > Hi all, >=20 > during the DIME meeting Glen raised an important question that impacts > the design of the protocol, namely: " > Do we need to support the scenario where the Diameter EAP authentication > and the Diameter MIPv6 authorization exchange terminate at different=20 > servers? " >=20 > Currently, we assume that these two exchanges could be terminated at=20 > different servers. As a consequence, security concerns were raised (see > slide 5 > of http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt). >=20 > How do people think about restricting the Diameter MIPv6 HA-to-AAAH=20 > document to terminate the authentication and authorization exchange at > the same server? >=20 > Ciao > Hannes >=20 > PS: Glen also suggested to consider using the Diameter MIPv6 App-ID for > the Diameter EAP exchange if we decide that both exchanges terminate at > the same server. As a consequence the open issue described at slide 6 of > http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt would also be > resolved. The changes to the existing document would be minimal (about 2 > additional sentences). >=20 >=20 > _______________________________________________ > 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 Wed Nov 15 15:48:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkRgJ-0004Ik-VM; Wed, 15 Nov 2006 15:48:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkRgJ-0004If-8u for dime@ietf.org; Wed, 15 Nov 2006 15:48:27 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GkRgG-0001fo-Ph for dime@ietf.org; Wed, 15 Nov 2006 15:48:27 -0500 Received: (qmail invoked by alias); 15 Nov 2006 20:48:23 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp032) with SMTP; 15 Nov 2006 21:48:23 +0100 X-Authenticated: #29516787 Message-ID: <455B7D18.5060708@gmx.net> Date: Wed, 15 Nov 2006 21:48:24 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Chowdhury, Kuntal" Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split References: <7CCD07160348804497EF29E9EA5560D7FBD4E9$0001@exchtewks2.starentnetworks.com> In-Reply-To: <7CCD07160348804497EF29E9EA5560D7FBD4E9$0001@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: 32b73d73e8047ed17386f9799119ce43 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, thanks for your response. you vote for a single server solution. At what time exactly the authorization decision is made requires a separate discussion since it depends to some extend on the message exchanges between the MIPv6 bootstrapping solution and the AAA exchange. As such, the answer is different for the NAS<->AAAH and the HA<->AAAH protocol interaction. Julien posted some message flows to the list describing some of the challenges. We need to investigate these aspects in a separate mailing list thread. Ciao Hannes Chowdhury, Kuntal wrote: > Hi Hannes, > > IMHO, at the time of EAP authentication the MS needs to be authorized > for MIP6 service. This is because: > > Regardless of whether EAP is used or some other auth method is used to > authenticate the MN, the entity that is authenticating the MN is the > MSA. The MSA by definition (Mobility Service Authorizer) needs to > Authenticate and Authorize the MN. For HoA bootstrapping, at the time of > IKEv2 transaction the HA needs to know whether the MN is authorized for > mobility service (MIP6 in this case) or not. Therefore, the AAA server > needs to either return an AVP along with EAP-Success to indicate to the > HA that the MN is authorized for MIP6 service or the AAA server can > return the address of another AAA server in the MSA that needs to be > contacted for MIP6 authorization for the MN. > > I think the former (MIP6 authorization AVP along with EAP success) is a > better option. In that case a single server for both auth and authz > should be suffice. > > -Kuntal > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Friday, November 10, 2006 6:26 PM >> To: dime@ietf.org >> Subject: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split >> >> Hi all, >> >> during the DIME meeting Glen raised an important question that impacts >> the design of the protocol, namely: >> " >> Do we need to support the scenario where the Diameter EAP > authentication >> and the Diameter MIPv6 authorization exchange terminate at different >> servers? >> " >> >> Currently, we assume that these two exchanges could be terminated at >> different servers. As a consequence, security concerns were raised > (see >> slide 5 >> of http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt). >> >> How do people think about restricting the Diameter MIPv6 HA-to-AAAH >> document to terminate the authentication and authorization exchange at >> the same server? >> >> Ciao >> Hannes >> >> PS: Glen also suggested to consider using the Diameter MIPv6 App-ID > for >> the Diameter EAP exchange if we decide that both exchanges terminate > at >> the same server. As a consequence the open issue described at slide 6 > of >> http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt would also be >> resolved. The changes to the existing document would be minimal (about > 2 >> additional sentences). >> >> >> _______________________________________________ >> 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 Nov 15 16:06:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkRxp-0003ZW-Is; Wed, 15 Nov 2006 16:06:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkRxn-0003Yw-O9 for dime@ietf.org; Wed, 15 Nov 2006 16:06:32 -0500 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GkRxb-0005Zr-S5 for dime@ietf.org; Wed, 15 Nov 2006 16:06:31 -0500 Received: (qmail invoked by alias); 15 Nov 2006 20:59:38 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp038) with SMTP; 15 Nov 2006 21:59:38 +0100 X-Authenticated: #29516787 Message-ID: <455B7FBC.2050403@gmx.net> Date: Wed, 15 Nov 2006 21:59:40 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Ram O V Vishnu-A14676 Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split References: In-Reply-To: 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: 93e7fb8fef2e780414389440f367c879 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 Vishnu, it is true that the figure in the slide set does not highlight the split between the entity that terminates the Diameter EAP application and the entity that performs the authorization decision is not clearly shown. The main reason for this is that the issue was brought to our attention during the working group meeting when Glen pointed specifically to the App-ID usage. With the current document is it quite possible that the Diameter EAP application terminates at a different server than the subsequent Diameter MIP application since they use different App-IDs and the message routing can be different as well. I also agree that the solution must not introduce new security holes. With the feedback so far I can only assume that the split between the two servers is not so urgently desired. But let's wait for more feedback. Ciao Hannes Ram O V Vishnu-A14676 wrote: > Hannes, > > I think this "split-within-split" (if I may call it so) is hard to > understand. > > In slide-5, I don't see any interface between AAA-EAP Server and > AAA-MIP6 Server, but I definitely see that they are boxed together as an > MSA. Hence I conclude that there is no question of interoperability or > something between these. It's the MSA's job to authenticate & authorize > MIP. It could do it using 2 server, 3, 4 etc. It could do it using 2 > processes, 2 tasks, 2 threads too. In either of these cases, since it > has taken up the responsibility of doing the auth & auth, it has to have > some mechanism of making sure no security hole exist. > > So, as it stands, in slide-5, the AAA-EAP server and AAA-MIP6 server > might as well be not shown. MSA could be shown as a black box. > > If someone could shed some light on the motivation behind the split, any > other arrows/interfaces which might land on AAA-EAP Server or on > AAA-MIP6 Server, it would be interesting to discuss those. > > Regards, > Vishnu. > > Motorola > +91 9844178052 > [] General > [*] Motorola Internal Use Only > > > > -----Original Message----- > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > Sent: Wednesday, November 15, 2006 10:13 AM > To: Hannes Tschofenig; dime@ietf.org > Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server > Split > > > Hi Hannes, > > IMHO, at the time of EAP authentication the MS needs to be authorized > for MIP6 service. This is because: > > Regardless of whether EAP is used or some other auth method is used to > authenticate the MN, the entity that is authenticating the MN is the > MSA. The MSA by definition (Mobility Service Authorizer) needs to > Authenticate and Authorize the MN. For HoA bootstrapping, at the time of > IKEv2 transaction the HA needs to know whether the MN is authorized for > mobility service (MIP6 in this case) or not. Therefore, the AAA server > needs to either return an AVP along with EAP-Success to indicate to the > HA that the MN is authorized for MIP6 service or the AAA server can > return the address of another AAA server in the MSA that needs to be > contacted for MIP6 authorization for the MN. > > I think the former (MIP6 authorization AVP along with EAP success) is a > better option. In that case a single server for both auth and authz > should be suffice. > > -Kuntal > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Friday, November 10, 2006 6:26 PM >> To: dime@ietf.org >> Subject: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split >> >> Hi all, >> >> during the DIME meeting Glen raised an important question that impacts > >> the design of the protocol, namely: " >> Do we need to support the scenario where the Diameter EAP > authentication >> and the Diameter MIPv6 authorization exchange terminate at different >> servers? " >> >> Currently, we assume that these two exchanges could be terminated at >> different servers. As a consequence, security concerns were raised > (see >> slide 5 >> of http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt). >> >> How do people think about restricting the Diameter MIPv6 HA-to-AAAH >> document to terminate the authentication and authorization exchange at > >> the same server? >> >> Ciao >> Hannes >> >> PS: Glen also suggested to consider using the Diameter MIPv6 App-ID > for >> the Diameter EAP exchange if we decide that both exchanges terminate > at >> the same server. As a consequence the open issue described at slide 6 > of >> http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt would also be > >> resolved. The changes to the existing document would be minimal (about > 2 >> additional sentences). >> >> >> _______________________________________________ >> 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 Wed Nov 15 16:19:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSAC-0001Py-5u; Wed, 15 Nov 2006 16:19:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSAA-0001PS-V9; Wed, 15 Nov 2006 16:19:18 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkSA6-0008D5-Ob; Wed, 15 Nov 2006 16:19:18 -0500 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 <0J8S002CBJ7ZHU@usaga01-in.huawei.com>; Wed, 15 Nov 2006 13:19:11 -0800 (PST) Received: from N737011 (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 <0J8S002FOJ7T2B@usaga01-in.huawei.com>; Wed, 15 Nov 2006 13:19:11 -0800 (PST) Date: Wed, 15 Nov 2006 13:19:07 -0800 From: Madjid Nakhjiri In-reply-to: To: 'Gerardo Giaretta' Message-id: <002201c708fb$afef0840$2f01a8c0@china.huawei.com> 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: AccIROjOnFtEd7gWRFmXGaLfZ/cAvgAswaVg X-Spam-Score: 0.6 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: "'Gopal Dommety \(gdommety\)'" , "'Kent Leung \(kleung\)'" , mip6@ietf.org, dime@ietf.org Subject: [Dime] RE: [Mip6] Should we add the requirements that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? 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, If you remember, the first time people asked this question, I said we should simply be careful about rubber stamping the Dime drafts as supporting 4285. Unless the HA-AAA goal doc includes specific requirements on supporting 4285, we should refrain from making the promise that Dime draft do too. If we design something based on a requirement that excludes support for 4285, then the solution has no obligation to support it either. I am going to reiterate all my points. 1) "AAA goal/requirement document" means requirements for both RADIUS and Diameter. Unless you want to change the name, we need to realize that this document can a) create requirements that RADIUS cannot meet and hence rule out RADIUS for MIP6 support (some of the current goals related to key transport fit that category) b) create requirement for all AAA functionality, i.e both requirements on AAA functionality within HA and on AAA protocol. This means if an HA works according to 4285, then the document needs to include requirement for supporting 4285 as well. Dime drafts can come and state whether they fulfill all requirements, including 4285 requirements. We already have two dime drafts for two different designs. Currently, the document seemed to be treated as "requirement for Dime bootstrapping drafts". Is that the intention? The answer seems to be yes from your email. So the HA-AAA goals is not a generic requirement goal for MIP6. The current HA-AAA goals document should specifically state that it is the requirements for Diameter EAP based solutions and not for 4285 to clear all the issues above. Personally I think support for 4285 is a lot simpler than people think, and might not require much more than some AVPs and look similar to 4004 for MIP4 support in case of CCOA, but I have not done a detail analysis. If that is true all 4285 needs in way of requirements is probably being allowed to have some new AVPs (or possibly same as those used in MIP4). The problem of excluding these from HA-AAA goal is that you may need a new Diameter MIP6 App ID for 4285, if the AVPs are brand new? Hope THIS clarifies some more :) Regards, Madjid -----Original Message----- From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] Sent: Tuesday, November 14, 2006 3:31 PM To: Madjid Nakhjiri Cc: Kent Leung (kleung); Vijay Devarapalli; Gopal Dommety (gdommety); mip6@ietf.org Subject: Re: [Mip6] Should we add the requirements that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? Current work in DIME WG is based on rfc3775/3776 and on the IPsec bootstrapping solution. This has lead so far to a re-use of rfc4072 for EAP packets transport between HA and AAAH and STR/STA/ASR/ASR re-use for the session management. This means that in case rfc4285 is used, the Diameter application we are designing cannot be used. The session management and authorization part can be kept the same, but there would be a need to specify how the HA authenticates the BUs in case of dynamic keying (something similar to MIP4 approach). So the question is: should the AAA requirements doc (and consequently the DIME solution - but this is a question for DIME WG) list also that the HA-AAA communication may be able to bootstrap and authenticate rfc4285 security associations? I hope this clarifies. --Gerardo On 11/14/06, Madjid Nakhjiri wrote: > Personally, I suspect that 4285 support simply needs a bunch of attributes. > I suggest people propose a couple of requirements related to 4285 support > and after that we could easily see if those can be added to the current set > of goals. Once we did that we can simply say the HA-AAAH support 4285. > > Madjid > > -----Original Message----- > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > Sent: Tuesday, November 14, 2006 12:08 PM > To: Vijay Devarapalli; Gopal Dommety (gdommety) > Cc: mip6@ietf.org > Subject: RE: [Mip6] Should we add the requirements that arise from RFC > 4285inthe draft-ietf-mip6-aaa-ha-goals-03? > > > My vote is YES. > > I assume this question is intended for HA-AAA interface support for RFC > 4285. But it would be definitely nice to have standards-based AAA > attributes for bootstrapping in terms of completeness. > > Kent > > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Tuesday, November 14, 2006 10:26 AM > To: Gopal Dommety (gdommety) > Cc: mip6@ietf.org > Subject: Re: [Mip6] Should we add the requirements that arise from RFC > 4285in the draft-ietf-mip6-aaa-ha-goals-03? > > Gopal, > > lets step back a bit. what is the point of adding of 4285-specific > requirements in draft-ietf-mip6-aaa-ha-goals? is it just for basic > 4285 operation where the HA-AAAH interface is used for MN > authentication? or does it include bootstrapping for 4285 too? > > will the requirements be added to > draft-ietf-mip6-aaa-ha-goals-03 just to capture all the requirements in > one place with no binding to develop any solutions yet? > > other bootstrapping related questions, do we want to standardize > bootstrapping solutions for 4285 too? has the DIME WG agreed to > developing solutions for 4285-based MIP6 operation? > > Vijay > > Gopal Dommety (gdommety) wrote: > > Hello All, > > > > Wanted to get the MIP6 Working groups preference on whether we > > should we add the requirements that arise from RFC 4285 in the > > draft-ietf-mip6-aaa-ha-goals-03 > > > > We would like to hear the Working Groups opinion of the following > question: > > > > Should we add the requirements that arise from RFC 4285 in the > > draft-ietf-mip6-aaa-ha-goals-03? > > > > Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there > > were > > 14 people for "yes" and 5 for "No". > > > > Cheers, > > Gopal and Raj > > > > > > ---------------------------------------------------------------------- > > -- > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 15 16:39:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSTO-00087a-OY; Wed, 15 Nov 2006 16:39:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSTM-00086T-WD; Wed, 15 Nov 2006 16:39:09 -0500 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkSTI-0003fV-5p; Wed, 15 Nov 2006 16:39:08 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id kAFLctfx003698; Wed, 15 Nov 2006 22:38:55 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id kAFLcto0019772; Wed, 15 Nov 2006 22:38:55 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.146]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 22:38:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Dime] RE: [Mip6] Should we add the requirements that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? Date: Wed, 15 Nov 2006 22:38:49 +0100 Message-ID: In-Reply-To: <002201c708fb$afef0840$2f01a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: [Mip6] Should we add the requirements that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? Thread-Index: AccIROjOnFtEd7gWRFmXGaLfZ/cAvgAswaVgAAFngaA= From: "Tschofenig, Hannes" To: "Madjid Nakhjiri" , "Gerardo Giaretta" X-OriginalArrivalTime: 15 Nov 2006 21:38:55.0014 (UTC) FILETIME=[73292460:01C708FE] X-Spam-Score: 0.6 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Cc: "Gopal Dommety \(gdommety\)" , mip6@ietf.org, "Kent Leung \(kleung\)" , 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,=20 you make things quite complicated. Gerardo and myself have asked the = following question to the MIP6 working group: Should = draft-ietf-mip6-aaa-ha-goals-03 say something about RFC 4285? Possible = answers are: a) Don't say anything about RFC 4285.=20 b) Explicitly rule out support for RFC 4285.=20 c) Explicitly support RFC 4285. =20 If draft-ietf-mip6-aaa-ha-goals-03 has to support both, RFC 4285 and = IKEv2/EAP based authentication, then that's fine with us. I know that = this is not difficult todo. We just need to get the documents written in = such a way. We just thought it is better to ask before we finish the = documents and suddently get told that this was not in the scope of our = work.=20 Furthermore, nobody said that draft-ietf-mip6-aaa-ha-goals-03 only = impacts the DIME work. It obviously also impacts the corresponding = RADIUS work since we are supposed to align the two designs. We just came = across this issue when we worked on the Diameter document.=20 Ciao Hannes > -----Urspr=FCngliche Nachricht----- > Von: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com]=20 > Gesendet: Mittwoch, 15. November 2006 22:19 > An: 'Gerardo Giaretta' > Cc: 'Gopal Dommety (gdommety)'; 'Kent Leung (kleung)';=20 > mip6@ietf.org; dime@ietf.org > Betreff: [Dime] RE: [Mip6] Should we add the requirements=20 > that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? >=20 > Hi Gerardo, >=20 >=20 > If you remember, the first time people asked this question, I=20 > said we should > simply be careful about rubber stamping the Dime drafts as=20 > supporting 4285. > Unless the HA-AAA goal doc includes specific requirements on=20 > supporting > 4285, we should refrain from making the promise that Dime=20 > draft do too. > If we design something based on a requirement that excludes=20 > support for > 4285, then the solution has no obligation to support it either.=20 >=20 > I am going to reiterate all my points. > 1) "AAA goal/requirement document" means requirements for=20 > both RADIUS and > Diameter. Unless you want to change the name, we need to=20 > realize that this > document can=20 > a) create requirements that RADIUS cannot meet and hence rule=20 > out RADIUS for > MIP6 support (some of the current goals related to key=20 > transport fit that > category) > b) create requirement for all AAA functionality, i.e both=20 > requirements on > AAA functionality within HA and on AAA protocol. This means=20 > if an HA works > according to 4285, then the document needs to include requirement for > supporting 4285 as well. Dime drafts can come and state=20 > whether they fulfill > all requirements, including 4285 requirements. We already=20 > have two dime > drafts for two different designs. >=20 > Currently, the document seemed to be treated as "requirement for Dime > bootstrapping drafts". Is that the intention? The answer=20 > seems to be yes > from your email. So the HA-AAA goals is not a generic=20 > requirement goal for > MIP6. The current HA-AAA goals document should specifically=20 > state that it is > the requirements for Diameter EAP based solutions and not for=20 > 4285 to clear > all the issues above. >=20 > Personally I think support for 4285 is a lot simpler than=20 > people think, and > might not require much more than some AVPs and look similar=20 > to 4004 for MIP4 > support in case of CCOA, but I have not done a detail=20 > analysis. If that is > true all 4285 needs in way of requirements is probably being=20 > allowed to have > some new AVPs (or possibly same as those used in MIP4).=20 >=20 > The problem of excluding these from HA-AAA goal is that you=20 > may need a new > Diameter MIP6 App ID for 4285, if the AVPs are brand new? >=20 > Hope THIS clarifies some more :) >=20 > Regards, >=20 > Madjid >=20 > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com]=20 > Sent: Tuesday, November 14, 2006 3:31 PM > To: Madjid Nakhjiri > Cc: Kent Leung (kleung); Vijay Devarapalli; Gopal Dommety (gdommety); > mip6@ietf.org > Subject: Re: [Mip6] Should we add the requirements that arise from RFC > 4285inthe draft-ietf-mip6-aaa-ha-goals-03? >=20 > Current work in DIME WG is based on rfc3775/3776 and on the IPsec > bootstrapping solution. This has lead so far to a re-use of rfc4072 > for EAP packets transport between HA and AAAH and STR/STA/ASR/ASR > re-use for the session management. >=20 > This means that in case rfc4285 is used, the Diameter application we > are designing cannot be used. The session management and authorization > part can be kept the same, but there would be a need to specify how > the HA authenticates the BUs in case of dynamic keying (something > similar to MIP4 approach). >=20 > So the question is: should the AAA requirements doc (and consequently > the DIME solution - but this is a question for DIME WG) list also that > the HA-AAA communication may be able to bootstrap and authenticate > rfc4285 security associations? >=20 > I hope this clarifies. >=20 > --Gerardo >=20 > On 11/14/06, Madjid Nakhjiri wrote: > > Personally, I suspect that 4285 support simply needs a bunch of > attributes. > > I suggest people propose a couple of requirements related=20 > to 4285 support > > and after that we could easily see if those can be added to=20 > the current > set > > of goals. Once we did that we can simply say the HA-AAAH=20 > support 4285. > > > > Madjid > > > > -----Original Message----- > > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > > Sent: Tuesday, November 14, 2006 12:08 PM > > To: Vijay Devarapalli; Gopal Dommety (gdommety) > > Cc: mip6@ietf.org > > Subject: RE: [Mip6] Should we add the requirements that=20 > arise from RFC > > 4285inthe draft-ietf-mip6-aaa-ha-goals-03? > > > > > > My vote is YES. > > > > I assume this question is intended for HA-AAA interface=20 > support for RFC > > 4285. But it would be definitely nice to have standards-based AAA > > attributes for bootstrapping in terms of completeness. > > > > Kent > > > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > > Sent: Tuesday, November 14, 2006 10:26 AM > > To: Gopal Dommety (gdommety) > > Cc: mip6@ietf.org > > Subject: Re: [Mip6] Should we add the requirements that=20 > arise from RFC > > 4285in the draft-ietf-mip6-aaa-ha-goals-03? > > > > Gopal, > > > > lets step back a bit. what is the point of adding of 4285-specific > > requirements in draft-ietf-mip6-aaa-ha-goals? is it just for basic > > 4285 operation where the HA-AAAH interface is used for MN > > authentication? or does it include bootstrapping for 4285 too? > > > > will the requirements be added to > > draft-ietf-mip6-aaa-ha-goals-03 just to capture all the=20 > requirements in > > one place with no binding to develop any solutions yet? > > > > other bootstrapping related questions, do we want to standardize > > bootstrapping solutions for 4285 too? has the DIME WG agreed to > > developing solutions for 4285-based MIP6 operation? > > > > Vijay > > > > Gopal Dommety (gdommety) wrote: > > > Hello All, > > > > > > Wanted to get the MIP6 Working groups preference on whether we > > > should we add the requirements that arise from RFC 4285 in the > > > draft-ietf-mip6-aaa-ha-goals-03 > > > > > > We would like to hear the Working Groups opinion of the following > > question: > > > > > > Should we add the requirements that arise from RFC 4285 in the > > > draft-ietf-mip6-aaa-ha-goals-03? > > > > > > Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there > > > were > > > 14 people for "yes" and 5 for "No". > > > > > > Cheers, > > > Gopal and Raj > > > > > > > > >=20 > ---------------------------------------------------------------------- > > > -- > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > >=20 >=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 Wed Nov 15 17:05:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSso-000712-H3; Wed, 15 Nov 2006 17:05:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSsn-00070t-DQ; Wed, 15 Nov 2006 17:05:25 -0500 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkSsm-0007J4-ML; Wed, 15 Nov 2006 17:05:25 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAFM40Bi016890; Thu, 16 Nov 2006 00:05:07 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 00:03:27 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 16:03:23 -0600 Received: from 172.19.244.84 ([172.19.244.84]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 15 Nov 2006 22:03:23 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Wed, 15 Nov 2006 16:03:37 -0600 From: Basavaraj Patil To: ext Madjid Nakhjiri , "'Gerardo Giaretta'" Message-ID: Thread-Topic: [Mip6] Should we add the requirements that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? Thread-Index: AccIROjOnFtEd7gWRFmXGaLfZ/cAvgAswaVgAAJ9x9A= In-Reply-To: <002201c708fb$afef0840$2f01a8c0@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Nov 2006 22:03:23.0903 (UTC) FILETIME=[DEAFD0F0:01C70901] X-Nokia-AV: Clean X-Spam-Score: 0.6 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: Gopal Dommety , mip6@ietf.org, "Kent Leung \(kleung\)" , dime@ietf.org Subject: [Dime] Re: [Mip6] Should we add the requirements that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? 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 Madjid has raised a good point here. To restate the MIP6 WGs charter objective: The AAA goals I-D is intended to capture requirements (or goals which is the terminology used here) for MIP6 that are generic, i.e the actual AAA solution may be based on Radius or Diameter. And there may be requirements that can be met only by Diameter (as Madjid has mentioned below), but that can be stated in the solution doc. But the requirements are not intended to be limited for consideration by the DIME WG only. -Raj On 11/15/06 3:19 PM, "ext Madjid Nakhjiri" wrote: > Hi Gerardo, > > > If you remember, the first time people asked this question, I said we should > simply be careful about rubber stamping the Dime drafts as supporting 4285. > Unless the HA-AAA goal doc includes specific requirements on supporting > 4285, we should refrain from making the promise that Dime draft do too. > If we design something based on a requirement that excludes support for > 4285, then the solution has no obligation to support it either. > > I am going to reiterate all my points. > 1) "AAA goal/requirement document" means requirements for both RADIUS and > Diameter. Unless you want to change the name, we need to realize that this > document can > a) create requirements that RADIUS cannot meet and hence rule out RADIUS for > MIP6 support (some of the current goals related to key transport fit that > category) > b) create requirement for all AAA functionality, i.e both requirements on > AAA functionality within HA and on AAA protocol. This means if an HA works > according to 4285, then the document needs to include requirement for > supporting 4285 as well. Dime drafts can come and state whether they fulfill > all requirements, including 4285 requirements. We already have two dime > drafts for two different designs. > > Currently, the document seemed to be treated as "requirement for Dime > bootstrapping drafts". Is that the intention? The answer seems to be yes > from your email. So the HA-AAA goals is not a generic requirement goal for > MIP6. The current HA-AAA goals document should specifically state that it is > the requirements for Diameter EAP based solutions and not for 4285 to clear > all the issues above. > > Personally I think support for 4285 is a lot simpler than people think, and > might not require much more than some AVPs and look similar to 4004 for MIP4 > support in case of CCOA, but I have not done a detail analysis. If that is > true all 4285 needs in way of requirements is probably being allowed to have > some new AVPs (or possibly same as those used in MIP4). > > The problem of excluding these from HA-AAA goal is that you may need a new > Diameter MIP6 App ID for 4285, if the AVPs are brand new? > > Hope THIS clarifies some more :) > > Regards, > > Madjid > > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > Sent: Tuesday, November 14, 2006 3:31 PM > To: Madjid Nakhjiri > Cc: Kent Leung (kleung); Vijay Devarapalli; Gopal Dommety (gdommety); > mip6@ietf.org > Subject: Re: [Mip6] Should we add the requirements that arise from RFC > 4285inthe draft-ietf-mip6-aaa-ha-goals-03? > > Current work in DIME WG is based on rfc3775/3776 and on the IPsec > bootstrapping solution. This has lead so far to a re-use of rfc4072 > for EAP packets transport between HA and AAAH and STR/STA/ASR/ASR > re-use for the session management. > > This means that in case rfc4285 is used, the Diameter application we > are designing cannot be used. The session management and authorization > part can be kept the same, but there would be a need to specify how > the HA authenticates the BUs in case of dynamic keying (something > similar to MIP4 approach). > > So the question is: should the AAA requirements doc (and consequently > the DIME solution - but this is a question for DIME WG) list also that > the HA-AAA communication may be able to bootstrap and authenticate > rfc4285 security associations? > > I hope this clarifies. > > --Gerardo > > On 11/14/06, Madjid Nakhjiri wrote: >> Personally, I suspect that 4285 support simply needs a bunch of > attributes. >> I suggest people propose a couple of requirements related to 4285 support >> and after that we could easily see if those can be added to the current > set >> of goals. Once we did that we can simply say the HA-AAAH support 4285. >> >> Madjid >> >> -----Original Message----- >> From: Kent Leung (kleung) [mailto:kleung@cisco.com] >> Sent: Tuesday, November 14, 2006 12:08 PM >> To: Vijay Devarapalli; Gopal Dommety (gdommety) >> Cc: mip6@ietf.org >> Subject: RE: [Mip6] Should we add the requirements that arise from RFC >> 4285inthe draft-ietf-mip6-aaa-ha-goals-03? >> >> >> My vote is YES. >> >> I assume this question is intended for HA-AAA interface support for RFC >> 4285. But it would be definitely nice to have standards-based AAA >> attributes for bootstrapping in terms of completeness. >> >> Kent >> >> -----Original Message----- >> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] >> Sent: Tuesday, November 14, 2006 10:26 AM >> To: Gopal Dommety (gdommety) >> Cc: mip6@ietf.org >> Subject: Re: [Mip6] Should we add the requirements that arise from RFC >> 4285in the draft-ietf-mip6-aaa-ha-goals-03? >> >> Gopal, >> >> lets step back a bit. what is the point of adding of 4285-specific >> requirements in draft-ietf-mip6-aaa-ha-goals? is it just for basic >> 4285 operation where the HA-AAAH interface is used for MN >> authentication? or does it include bootstrapping for 4285 too? >> >> will the requirements be added to >> draft-ietf-mip6-aaa-ha-goals-03 just to capture all the requirements in >> one place with no binding to develop any solutions yet? >> >> other bootstrapping related questions, do we want to standardize >> bootstrapping solutions for 4285 too? has the DIME WG agreed to >> developing solutions for 4285-based MIP6 operation? >> >> Vijay >> >> Gopal Dommety (gdommety) wrote: >>> Hello All, >>> >>> Wanted to get the MIP6 Working groups preference on whether we >>> should we add the requirements that arise from RFC 4285 in the >>> draft-ietf-mip6-aaa-ha-goals-03 >>> >>> We would like to hear the Working Groups opinion of the following >> question: >>> >>> Should we add the requirements that arise from RFC 4285 in the >>> draft-ietf-mip6-aaa-ha-goals-03? >>> >>> Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there >>> were >>> 14 people for "yes" and 5 for "No". >>> >>> Cheers, >>> Gopal and Raj >>> >>> >>> ---------------------------------------------------------------------- >>> -- >>> >>> _______________________________________________ >>> Mip6 mailing list >>> Mip6@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mip6 >> >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> >> >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 15 17:08:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSvv-0001wO-Ud; Wed, 15 Nov 2006 17:08:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSvv-0001wG-1R for dime@ietf.org; Wed, 15 Nov 2006 17:08:39 -0500 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 1GkSvt-0007eo-Du for dime@ietf.org; Wed, 15 Nov 2006 17:08:39 -0500 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 kAFM7wWx024166; Wed, 15 Nov 2006 17:07:59 -0500 (EST) (envelope-from yohba@tari.toshiba.com) Date: Wed, 15 Nov 2006 17:08:03 -0500 To: Hannes Tschofenig Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split Message-ID: <20061115220803.GI29175@steelhead> References: <4555188F.9080604@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <4555188F.9080604@gmx.net> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 56 X-Spam-Score: -2.4 (--) 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 I'd not much care whether authentication and authorization use different servers, but I have no technical problem with use of different servers since we already allow to use different servers for accounting and authentication/authorization. I'd rather care whether authentication and authorization are separated even if the same server is used authentication and authorization. I am not convinced with combining MIP6 authorization and EAP authentication in the same application. MIP6 authorization with AAA could happen without EAP, e.g., when EAP is not used for IKEv2 authentication. It is more modular and flexible to separate MIP6 authorization and EAP authentication. Also, this discussion might depend on the ongoing discussion in MIP6 WG on RFC4285 support in draft-ietf-mip6-aaa-ha-goals draft. Regards, Yoshihiro Ohba On Fri, Nov 10, 2006 at 04:25:51PM -0800, Hannes Tschofenig wrote: > Hi all, > > during the DIME meeting Glen raised an important question that impacts > the design of the protocol, namely: > " > Do we need to support the scenario where the Diameter EAP authentication > and the Diameter MIPv6 authorization exchange terminate at different > servers? > " > > Currently, we assume that these two exchanges could be terminated at > different servers. As a consequence, security concerns were raised (see > slide 5 > of http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt). > > How do people think about restricting the Diameter MIPv6 HA-to-AAAH > document to terminate the authentication and authorization exchange at > the same server? > > Ciao > Hannes > > PS: Glen also suggested to consider using the Diameter MIPv6 App-ID for > the Diameter EAP exchange if we decide that both exchanges terminate at > the same server. As a consequence the open issue described at slide 6 of > http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt would also be > resolved. The changes to the existing document would be minimal (about 2 > additional sentences). > > > _______________________________________________ > 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 Nov 15 17:21:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkT8a-0006H7-1O; Wed, 15 Nov 2006 17:21:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkT8Y-0006Gz-RG for dime@ietf.org; Wed, 15 Nov 2006 17:21:42 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkT8V-0000qK-Gw for dime@ietf.org; Wed, 15 Nov 2006 17:21:42 -0500 Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id kAFMLTm4007952; Wed, 15 Nov 2006 16:21:30 -0600 (CST) Received: from phal.lucentradius.com (phil.aaa.lucent.com [135.140.160.4]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id kAFMLTM6025457; Wed, 15 Nov 2006 16:21:29 -0600 (CST) Received: from [135.140.160.28] (rocinante.lucentradius.com [135.140.160.28]) by phal.lucentradius.com (8.12.9+Sun/8.12.9) with ESMTP id kAFMLTXk020810; Wed, 15 Nov 2006 14:21:29 -0800 (PST) Message-ID: <455B927C.5010302@lucent.com> Date: Wed, 15 Nov 2006 14:19:40 -0800 From: Jan Nordqvist User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Victor Fajardo Subject: Re: [Dime] Updated errata draft for RFC 3588bis References: <455A366A.1030503@tari.toshiba.com> In-Reply-To: <455A366A.1030503@tari.toshiba.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 Sorry if this got duplicated, my email source address has changed. Another suggestion for something to be include in the draft would be to replace that absolutely horrible section 5.6.4 in 3588. How about something like this: 5.6.4. The Election Process The election is performed on the responder. The responder compares the Origin-Host received in the CER with its own Origin-Host as two streams of octets. If the local Origin-Host lexicographically succeeds the received Origin-Host a Win-Election event is issued locally. To be consistent with DNS case insensitivity, octets that fall in the ASCII range 'a' through 'z' MUST compare equal to their upper-case counterparts between 'A' and 'Z', i.e. value 0x41 compares equal to 0x61, 0x42 to 0x62 and so forth up to and including 0x5a and 0x7a. Victor Fajardo wrote: > Hi all, > > An updated version of diameter errata draft can be found in: > > http://www.opendiameter.org/public/draft-fajardo-dime-diameter-errata-01.txt > > > This version includes the comments and decisions made during IETF67 > DIME meeting. Note that all open issues now have proposed solutions. > Pls review them so we can move forward. > > 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 Wed Nov 15 17:23:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkTA1-0006Ox-K9; Wed, 15 Nov 2006 17:23:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkTA1-0006Os-2c for dime@ietf.org; Wed, 15 Nov 2006 17:23:13 -0500 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 1GkTA0-00012J-PX for dime@ietf.org; Wed, 15 Nov 2006 17:23:13 -0500 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 kAFMMX9x024236; Wed, 15 Nov 2006 17:22:33 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <455B934F.7080906@tari.toshiba.com> Date: Wed, 15 Nov 2006 17:23:11 -0500 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: Jan Nordqvist Subject: Re: [Dime] Updated errata draft for RFC 3588bis References: <455A366A.1030503@tari.toshiba.com> <455B90DD.6020507@lucent.com> In-Reply-To: <455B90DD.6020507@lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 Good point. I'll updated the tracker. > Another suggestion for something to be include in the draft would be > to replace that absolutely horrible section 5.6.4 in 3588. > How about something like this: > > 5.6.4. The Election Process > > The election is performed on the responder. The responder compares the > Origin-Host received in the CER with its own Origin-Host > as two streams of octets. If the local Origin-Host lexicographically > succeeds the received Origin-Host a Win-Election event is > issued locally. > To be consistent with DNS case insensitivity, octets that fall in the > ASCII range 'a' through 'z' MUST compare equal to their upper-case > counterparts between 'A' and 'Z', i.e. value 0x41 compares equal to > 0x61, 0x42 to 0x62 and so forth up to and including > 0x5a and 0x7a. > > > Victor Fajardo wrote: >> Hi all, >> >> An updated version of diameter errata draft can be found in: >> >> http://www.opendiameter.org/public/draft-fajardo-dime-diameter-errata-01.txt >> >> >> This version includes the comments and decisions made during IETF67 >> DIME meeting. Note that all open issues now have proposed solutions. >> Pls review them so we can move forward. >> >> 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 Wed Nov 15 17:35:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkTM6-0007Ti-Bv; Wed, 15 Nov 2006 17:35:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkTM5-0007TW-1u for dime@ietf.org; Wed, 15 Nov 2006 17:35:41 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkTM2-00031I-OV for dime@ietf.org; Wed, 15 Nov 2006 17:35:41 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-6.cisco.com with ESMTP; 15 Nov 2006 14:35:38 -0800 X-IronPort-AV: i="4.09,426,1157353200"; d="scan'208"; a="88183866:sNHT44487405" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kAFMZbJG015143; Wed, 15 Nov 2006 17:35:37 -0500 Received: from [161.44.55.136] (dhcp-161-44-55-136.cisco.com [161.44.55.136]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kAFMZbDM006424; Wed, 15 Nov 2006 17:35:37 -0500 (EST) Message-ID: <455B9637.5010201@cisco.com> Date: Wed, 15 Nov 2006 17:35:35 -0500 From: Anders Kristensen User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=913; t=1163630137; x=1164494137; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andersk@cisco.com; z=From:=20Anders=20Kristensen=20 |Subject:=20IPFilterRule=20grammar |Sender:=20 |To:=20dime@ietf.org; bh=T6OmuopL3DPTGk7aUgxHONAflCVC4/K6O227DXs/GxY=; b=VKhYNPaQ7dProTL0tpbAhWozxr/JPsFYtxs57Q6foEFkuGaXTR27bZZcIGIL+4f3Ld5GIhLr 7lsK79c4vAYG/QB5kUxMPF/A6KYfiNPlG5wuOIbtFd8+vvrlJefuWB7Z; Authentication-Results: rtp-dkim-1; header.From=andersk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Dime] IPFilterRule grammar 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 RFC 3588 defines the IPFilterRule AVP type as being an OctetString that conforms to the grammar: action dir proto from src to dst [options] action permit - Allow packets that match the rule. deny - Drop packets that match the rule. dir "in" is from the terminal, "out" is to the terminal. proto An IP protocol specified by number. The "ip" keyword means any protocol will match. src and dst
[ports] ... It's not clear to me from this description whether "from" and "to" are literals supposed to appear in the actual IPFilterRule or not. I've seen both interpretations used. Which is right? If 3588 is being rev'ed I think it would be a good idea to rewrite this grammar to follow RFC 4234. Thanks, Anders _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 15 17:58:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkThw-0001gP-Ew; Wed, 15 Nov 2006 17:58:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkThv-0001gE-CW; Wed, 15 Nov 2006 17:58:15 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkThs-0006Po-O5; Wed, 15 Nov 2006 17:58:15 -0500 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 <0J8S00261NT0HU@usaga01-in.huawei.com>; Wed, 15 Nov 2006 14:58:12 -0800 (PST) Received: from N737011 (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 <0J8S005QQNST0A@usaga01-in.huawei.com>; Wed, 15 Nov 2006 14:58:12 -0800 (PST) Date: Wed, 15 Nov 2006 14:58:07 -0800 From: Madjid Nakhjiri Subject: RE: [Dime] RE: [Mip6] Should we add the requirements that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? In-reply-to: To: "'Tschofenig, Hannes'" , 'Gerardo Giaretta' Message-id: <003a01c70909$84de5f30$2f01a8c0@china.huawei.com> 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=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: AccIROjOnFtEd7gWRFmXGaLfZ/cAvgAswaVgAAFngaAAArx5wA== X-Spam-Score: 0.6 (/) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc Cc: "'Gopal Dommety \(gdommety\)'" , mip6@ietf.org, "'Kent Leung \(kleung\)'" , 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 Well, NO pun intended, but I am not sure what is so complicated about = this, anybody who has gone through a product cycle does a requirement first = and then the design based on the requirements... I reacted to voting on whether Dime drafts/ designs should/must support 4285, without specifying what 4285 requirements are and without = including these requirements into the generic design document. That is poor salesmanship promising something that your product may or may not do. = Comes IESG review, this will come back and bite us. Then people started voting on support of 4285 in the requirements = without specifying what 4285 needs are. >From what I understood the intention of aaa-ha goal doc is (based on = Raj's comments), it is generic and should include 4285 support (as a SHOULD, = or whatever the applicability statement says). So none of your options = below:) Then the Dime drafts can simply say that they don't support that = "SHOULD" requirements. I don't have a strong opinion on whether 4285 is very important or not, = but I think we should follow a design process, we can answer for, later. Regards, Madjid -----Original Message----- From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 Sent: Wednesday, November 15, 2006 1:39 PM To: Madjid Nakhjiri; Gerardo Giaretta Cc: Gopal Dommety (gdommety); Kent Leung (kleung); mip6@ietf.org; dime@ietf.org Subject: AW: [Dime] RE: [Mip6] Should we add the requirements that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? Hi Madjid,=20 you make things quite complicated. Gerardo and myself have asked the following question to the MIP6 working group: Should draft-ietf-mip6-aaa-ha-goals-03 say something about RFC 4285? Possible answers are: a) Don't say anything about RFC 4285.=20 b) Explicitly rule out support for RFC 4285.=20 c) Explicitly support RFC 4285. =20 If draft-ietf-mip6-aaa-ha-goals-03 has to support both, RFC 4285 and IKEv2/EAP based authentication, then that's fine with us. I know that = this is not difficult todo. We just need to get the documents written in such = a way. We just thought it is better to ask before we finish the documents = and suddently get told that this was not in the scope of our work.=20 Furthermore, nobody said that draft-ietf-mip6-aaa-ha-goals-03 only = impacts the DIME work. It obviously also impacts the corresponding RADIUS work = since we are supposed to align the two designs. We just came across this issue when we worked on the Diameter document.=20 Ciao Hannes > -----Urspr=FCngliche Nachricht----- > Von: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com]=20 > Gesendet: Mittwoch, 15. November 2006 22:19 > An: 'Gerardo Giaretta' > Cc: 'Gopal Dommety (gdommety)'; 'Kent Leung (kleung)';=20 > mip6@ietf.org; dime@ietf.org > Betreff: [Dime] RE: [Mip6] Should we add the requirements=20 > that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? >=20 > Hi Gerardo, >=20 >=20 > If you remember, the first time people asked this question, I=20 > said we should > simply be careful about rubber stamping the Dime drafts as=20 > supporting 4285. > Unless the HA-AAA goal doc includes specific requirements on=20 > supporting > 4285, we should refrain from making the promise that Dime=20 > draft do too. > If we design something based on a requirement that excludes=20 > support for > 4285, then the solution has no obligation to support it either.=20 >=20 > I am going to reiterate all my points. > 1) "AAA goal/requirement document" means requirements for=20 > both RADIUS and > Diameter. Unless you want to change the name, we need to=20 > realize that this > document can=20 > a) create requirements that RADIUS cannot meet and hence rule=20 > out RADIUS for > MIP6 support (some of the current goals related to key=20 > transport fit that > category) > b) create requirement for all AAA functionality, i.e both=20 > requirements on > AAA functionality within HA and on AAA protocol. This means=20 > if an HA works > according to 4285, then the document needs to include requirement for > supporting 4285 as well. Dime drafts can come and state=20 > whether they fulfill > all requirements, including 4285 requirements. We already=20 > have two dime > drafts for two different designs. >=20 > Currently, the document seemed to be treated as "requirement for Dime > bootstrapping drafts". Is that the intention? The answer=20 > seems to be yes > from your email. So the HA-AAA goals is not a generic=20 > requirement goal for > MIP6. The current HA-AAA goals document should specifically=20 > state that it is > the requirements for Diameter EAP based solutions and not for=20 > 4285 to clear > all the issues above. >=20 > Personally I think support for 4285 is a lot simpler than=20 > people think, and > might not require much more than some AVPs and look similar=20 > to 4004 for MIP4 > support in case of CCOA, but I have not done a detail=20 > analysis. If that is > true all 4285 needs in way of requirements is probably being=20 > allowed to have > some new AVPs (or possibly same as those used in MIP4).=20 >=20 > The problem of excluding these from HA-AAA goal is that you=20 > may need a new > Diameter MIP6 App ID for 4285, if the AVPs are brand new? >=20 > Hope THIS clarifies some more :) >=20 > Regards, >=20 > Madjid >=20 > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com]=20 > Sent: Tuesday, November 14, 2006 3:31 PM > To: Madjid Nakhjiri > Cc: Kent Leung (kleung); Vijay Devarapalli; Gopal Dommety (gdommety); > mip6@ietf.org > Subject: Re: [Mip6] Should we add the requirements that arise from RFC > 4285inthe draft-ietf-mip6-aaa-ha-goals-03? >=20 > Current work in DIME WG is based on rfc3775/3776 and on the IPsec > bootstrapping solution. This has lead so far to a re-use of rfc4072 > for EAP packets transport between HA and AAAH and STR/STA/ASR/ASR > re-use for the session management. >=20 > This means that in case rfc4285 is used, the Diameter application we > are designing cannot be used. The session management and authorization > part can be kept the same, but there would be a need to specify how > the HA authenticates the BUs in case of dynamic keying (something > similar to MIP4 approach). >=20 > So the question is: should the AAA requirements doc (and consequently > the DIME solution - but this is a question for DIME WG) list also that > the HA-AAA communication may be able to bootstrap and authenticate > rfc4285 security associations? >=20 > I hope this clarifies. >=20 > --Gerardo >=20 > On 11/14/06, Madjid Nakhjiri wrote: > > Personally, I suspect that 4285 support simply needs a bunch of > attributes. > > I suggest people propose a couple of requirements related=20 > to 4285 support > > and after that we could easily see if those can be added to=20 > the current > set > > of goals. Once we did that we can simply say the HA-AAAH=20 > support 4285. > > > > Madjid > > > > -----Original Message----- > > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > > Sent: Tuesday, November 14, 2006 12:08 PM > > To: Vijay Devarapalli; Gopal Dommety (gdommety) > > Cc: mip6@ietf.org > > Subject: RE: [Mip6] Should we add the requirements that=20 > arise from RFC > > 4285inthe draft-ietf-mip6-aaa-ha-goals-03? > > > > > > My vote is YES. > > > > I assume this question is intended for HA-AAA interface=20 > support for RFC > > 4285. But it would be definitely nice to have standards-based AAA > > attributes for bootstrapping in terms of completeness. > > > > Kent > > > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > > Sent: Tuesday, November 14, 2006 10:26 AM > > To: Gopal Dommety (gdommety) > > Cc: mip6@ietf.org > > Subject: Re: [Mip6] Should we add the requirements that=20 > arise from RFC > > 4285in the draft-ietf-mip6-aaa-ha-goals-03? > > > > Gopal, > > > > lets step back a bit. what is the point of adding of 4285-specific > > requirements in draft-ietf-mip6-aaa-ha-goals? is it just for basic > > 4285 operation where the HA-AAAH interface is used for MN > > authentication? or does it include bootstrapping for 4285 too? > > > > will the requirements be added to > > draft-ietf-mip6-aaa-ha-goals-03 just to capture all the=20 > requirements in > > one place with no binding to develop any solutions yet? > > > > other bootstrapping related questions, do we want to standardize > > bootstrapping solutions for 4285 too? has the DIME WG agreed to > > developing solutions for 4285-based MIP6 operation? > > > > Vijay > > > > Gopal Dommety (gdommety) wrote: > > > Hello All, > > > > > > Wanted to get the MIP6 Working groups preference on whether we > > > should we add the requirements that arise from RFC 4285 in the > > > draft-ietf-mip6-aaa-ha-goals-03 > > > > > > We would like to hear the Working Groups opinion of the following > > question: > > > > > > Should we add the requirements that arise from RFC 4285 in the > > > draft-ietf-mip6-aaa-ha-goals-03? > > > > > > Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there > > > were > > > 14 people for "yes" and 5 for "No". > > > > > > Cheers, > > > Gopal and Raj > > > > > > > > >=20 > ---------------------------------------------------------------------- > > > -- > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > >=20 >=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 Wed Nov 15 18:03:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkTnF-0006DQ-0h; Wed, 15 Nov 2006 18:03:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkTnD-0006DI-C4 for dime@ietf.org; Wed, 15 Nov 2006 18:03:43 -0500 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 1GkTnD-0007Q5-AT for dime@ietf.org; Wed, 15 Nov 2006 18:03:43 -0500 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GkTnB-00039o-VF for dime@ietf.org; Wed, 15 Nov 2006 18:03:43 -0500 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 kAFMvskt024371; Wed, 15 Nov 2006 17:57:54 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <455B9B9A.8030508@tari.toshiba.com> Date: Wed, 15 Nov 2006 17:58:34 -0500 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: Anders Kristensen Subject: Re: [Dime] IPFilterRule grammar References: <455B9637.5010201@cisco.com> In-Reply-To: <455B9637.5010201@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 Anders, > RFC 3588 defines the IPFilterRule AVP type as being an OctetString > that conforms to the grammar: > > action dir proto from src to dst [options] > > action permit - Allow packets that match the rule. > deny - Drop packets that match the rule. > > dir "in" is from the terminal, "out" is to the > terminal. > > proto An IP protocol specified by number. The "ip" > keyword means any protocol will match. > > src and dst
[ports] > ... > > It's not clear to me from this description whether "from" and "to" are > literals supposed to appear in the actual IPFilterRule or not. I've > seen both interpretations used. Which is right? > > If 3588 is being rev'ed I think it would be a good idea to rewrite > this grammar to follow RFC 4234. My reading on this is that they are literals that can appear in the text rule. Some derivative examples can be found in draft-ietf-radext-filter-rules-01.txt. Given that, I'm not sure there is really a problem that needs to be fixed. best regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 15 20:51:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkWPP-0003Wp-Nb; Wed, 15 Nov 2006 20:51:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkWPO-0003Wj-Ni for dime@ietf.org; Wed, 15 Nov 2006 20:51:18 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkWPM-0005qN-Ed for dime@ietf.org; Wed, 15 Nov 2006 20:51:18 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-5.cisco.com with ESMTP; 15 Nov 2006 17:51:15 -0800 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/8.12.11) with ESMTP id kAG1pFuX017333; Wed, 15 Nov 2006 20:51:15 -0500 Received: from [10.86.242.4] (che-vpn-cluster-2-4.cisco.com [10.86.242.4]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAG1pEYJ021075; Wed, 15 Nov 2006 20:51:15 -0500 (EST) Message-ID: <455BC40C.3080806@cisco.com> Date: Wed, 15 Nov 2006 20:51:08 -0500 From: Anders Kristensen User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Victor Fajardo Subject: Re: [Dime] IPFilterRule grammar References: <455B9637.5010201@cisco.com> <455B9B9A.8030508@tari.toshiba.com> In-Reply-To: <455B9B9A.8030508@tari.toshiba.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1573; t=1163641875; x=1164505875; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andersk@cisco.com; z=From:=20Anders=20Kristensen=20 |Subject:=20Re=3A=20[Dime]=20IPFilterRule=20grammar |Sender:=20 |To:=20Victor=20Fajardo=20; bh=jYhvtjEpYGUzMkOtrVeojkuALY7sUdpA/ocqK9eTfmY=; b=t/mX9xobHz8ClDzBz80JFK+7dIbeLoeWKB4wYQFjb0S3DAjeW2ztesGUqgrnznnSAHXKAaED qOvEc+r/msoHO3iLBlDylIzd9BB7cchMXp5PxQZ1yxgXJ78VDC89ZHiR; Authentication-Results: rtp-dkim-2; header.From=andersk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 Victor Fajardo wrote: > Hi Anders, >> RFC 3588 defines the IPFilterRule AVP type as being an OctetString >> that conforms to the grammar: >> >> action dir proto from src to dst [options] >> >> action permit - Allow packets that match the rule. >> deny - Drop packets that match the rule. >> >> dir "in" is from the terminal, "out" is to the >> terminal. >> >> proto An IP protocol specified by number. The "ip" >> keyword means any protocol will match. >> >> src and dst
[ports] >> ... >> >> It's not clear to me from this description whether "from" and "to" are >> literals supposed to appear in the actual IPFilterRule or not. I've >> seen both interpretations used. Which is right? >> >> If 3588 is being rev'ed I think it would be a good idea to rewrite >> this grammar to follow RFC 4234. > > My reading on this is that they are literals that can appear in the text > rule. Some derivative examples can be found in > draft-ietf-radext-filter-rules-01.txt. Given that, I'm not sure there is > really a problem that needs to be fixed. The grammar is supposed to clearly and unambiguously define valid strings. If you have to resort to looking at examples to figure out what the intention is then that's probably a good indication that the grammar is not well defined. IMHO, that's what we have here. Thanks, Anders > > best regards, > victor > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 15 22:14:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkXi4-0005j5-Gd; Wed, 15 Nov 2006 22:14:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkXi2-0005iw-LW for dime@ietf.org; Wed, 15 Nov 2006 22:14:38 -0500 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 1GkXhy-0008Im-9u for dime@ietf.org; Wed, 15 Nov 2006 22:14:38 -0500 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id kAG3DmkI025419; Wed, 15 Nov 2006 22:13:49 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <455BD76D.6070202@tari.toshiba.com> Date: Wed, 15 Nov 2006 22:13:49 -0500 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: Anders Kristensen Subject: Re: [Dime] IPFilterRule grammar References: <455B9637.5010201@cisco.com> <455B9B9A.8030508@tari.toshiba.com> <455BC40C.3080806@cisco.com> In-Reply-To: <455BC40C.3080806@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 Anders, >> >> My reading on this is that they are literals that can appear in the >> text rule. Some derivative examples can be found in >> draft-ietf-radext-filter-rules-01.txt. Given that, I'm not sure there >> is really a problem that needs to be fixed. > > The grammar is supposed to clearly and unambiguously define valid > strings. If you have to resort to looking at examples to figure out > what the intention is then that's probably a good indication that the > grammar is not well defined. IMHO, that's what we have here. I guess I would argue the opposite. My thinking was that the semantics and usage was well defined and well understood and hence there were derivative usages in new/existing drafts. In anycase, we can get more feedback and see if this is really an issue where syntax changes are required or just the addition of clarifying text would be sufficient. Note that changing the syntax have implications on existing implementations as well as ongoing protocol work. best regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 15 23:17:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkYgd-0000lx-8u; Wed, 15 Nov 2006 23:17:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkYgc-0000ls-0P for dime@ietf.org; Wed, 15 Nov 2006 23:17:14 -0500 Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkYgW-0006XS-U5 for dime@ietf.org; Wed, 15 Nov 2006 23:17:13 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id D24662060C for ; Thu, 16 Nov 2006 09:40:56 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id BF18E205F4 for ; Thu, 16 Nov 2006 09:40:56 +0530 (IST) Received: from blr-m2-msg.wipro.com ([10.116.50.99]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 09:46:39 +0530 Received: from wipro-vhbw5mgjf ([10.116.8.11]) by blr-m2-msg.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 09:46:42 +0530 Subject: Re: [Dime] Diameter Tutorial From: venkatesh devalapura nagabhushana To: "Tschofenig, Hannes" In-Reply-To: References: Content-Type: text/plain Date: Thu, 16 Nov 2006 09:49:17 +0530 Message-Id: <1163650757.3290.17.camel@m3-sqa-smadhu.wipro.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Nov 2006 04:16:42.0200 (UTC) FILETIME=[051CB580:01C70936] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 Is the ppt slides available ? Thanks, Venkatesh On Tue, 2006-10-24 at 22:07 +0200, Tschofenig, Hannes wrote: > Hi all, > > in a discussion with John we came up with the idea of scheduling a > tutorial about Diameter, accounting, and credit control. > > WHEN? Monday, starting at 8pm for about 1 1/2 or 2 hours (after the > afternoon session iii) > > WHERE? Room yet to be defined; depending on the number of participants > > WHY? With the recent work on mobility and Quality of Service we noticed > that we have experts in specific problem domains but there is room for > improvement regarding the Diameter knowledge. > > WHO: Focus: Authors of Diameter applications. > But: Everyone with interest in Diameter is welcome. > > Please send a note to the chairs with the Subject line > "diameter-tutorial" if you plan to attend the tutorial. > > Ciao > Hannes & John > > > _______________________________________________ > 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 Nov 15 23:51:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkZDC-0006Jx-VX; Wed, 15 Nov 2006 23:50:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkZDB-0006Jp-80 for dime@ietf.org; Wed, 15 Nov 2006 23:50:53 -0500 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkZD9-00010k-P0 for dime@ietf.org; Wed, 15 Nov 2006 23:50:53 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAG4okcp006153; Thu, 16 Nov 2006 06:50:48 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 06:50:46 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 06:50:46 +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 Tutorial Date: Thu, 16 Nov 2006 06:50:45 +0200 Message-ID: In-Reply-To: <1163650757.3290.17.camel@m3-sqa-smadhu.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter Tutorial Thread-Index: AccJNyoaI2xY8I+USL+Gp2nTWs+b7AAA3mng From: To: , X-OriginalArrivalTime: 16 Nov 2006 04:50:46.0475 (UTC) FILETIME=[C79851B0:01C7093A] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061116065049-17BFEBB0-22925DD6/0-0/0-0 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 They are posted at the proceding pages, here: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=3D6= 7 Specifically, DiME base: http://www3.ietf.org/proceedings/06nov/slides/dime-3.ppt DCC: http://www3.ietf.org/proceedings/06nov/slides/dime-2.ppt =20 John >-----Original Message----- >From: ext venkatesh devalapura nagabhushana=20 >[mailto:venkatesh.nag@wipro.com]=20 >Sent: 16 November, 2006 06:19 >To: Tschofenig, Hannes >Cc: dime@ietf.org >Subject: Re: [Dime] Diameter Tutorial > >Is the ppt slides available ? > >Thanks, >Venkatesh > >On Tue, 2006-10-24 at 22:07 +0200, Tschofenig, Hannes wrote: >> Hi all, >>=20 >> in a discussion with John we came up with the idea of scheduling a=20 >> tutorial about Diameter, accounting, and credit control. >>=20 >> WHEN? Monday, starting at 8pm for about 1 1/2 or 2 hours (after the=20 >> afternoon session iii) >>=20 >> WHERE? Room yet to be defined; depending on the number of=20 >participants >>=20 >> WHY? With the recent work on mobility and Quality of Service we=20 >> noticed that we have experts in specific problem domains but=20 >there is=20 >> room for improvement regarding the Diameter knowledge. >>=20 >> WHO: Focus: Authors of Diameter applications.=20 >> But: Everyone with interest in Diameter is welcome. >>=20 >> Please send a note to the chairs with the Subject line=20 >> "diameter-tutorial" if you plan to attend the tutorial. >>=20 >> Ciao >> Hannes & John >>=20 >>=20 >> _______________________________________________ >> 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 Nov 16 01:40:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkau6-0000sX-GA; Thu, 16 Nov 2006 01:39:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkau5-0000ct-HM for dime@ietf.org; Thu, 16 Nov 2006 01:39:17 -0500 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkaiP-0001Cf-Ik for dime@ietf.org; Thu, 16 Nov 2006 01:27:15 -0500 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.10) with ESMTP id kAG6QwCr015812 for ; Thu, 16 Nov 2006 08:27:09 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 08:26:52 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 08:26:52 +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 Date: Thu, 16 Nov 2006 08:26:52 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: transport directorate review of draft-asveren-dime-cong-00.txt Thread-Index: AccJSDQGo4tdZ1l+Qp2wILPuTvoXlQ== From: To: X-OriginalArrivalTime: 16 Nov 2006 06:26:52.0808 (UTC) FILETIME=[3498E880:01C70948] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061116082711-3D6AABB0-31794EE2/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: [Dime] transport directorate review of draft-asveren-dime-cong-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 Hi all, Some comments from the Transport Directorate. The transport area general is concerned about congestion issues, so an analysis of=20 this document was requested. Tolga didn't have time to discuss this at the last IETF document, but it would be good for the wg to read the draft and comment on the importance of this issue. =20 thanks, John=20 >-----Original Message----- >From: Bernard Aboba [mailto:aboba@internaut.com]=20 >Sent: 13 November, 2006 19:01 >To: Magnus Westerlund >Cc: TSV Dir >Subject: Re: [tsv-dir] [Fwd: I-D ACTION:draft-asveren-dime-cong-00.txt] > >I agree that this document is insufficiently specified and could lead to=20 >interoperability problems as well as operational issues. =20 > >Diameter is different from RADIUS in that the failover and=20 >load balancing behavior is specified in "AAA Transport=20 >Profile" RFC 3539.=20 > >Diameter deployments typically involve many clients, so that=20 >load balancing can be achieved by distributing the clients=20 >between the Diameter servers. =20 >Schemes which move clients to "unloaded" Diameter servers (as=20 >this document does) can result in load oscillations unless the=20 >algorithms are carefully specified, which this document does not do.=20 > >Also, this document relies on explicit congestion signalling,=20 >rather than piggybacking on existing exchanges (e.g. the=20 >watchdog specified in RFC 3539): > > A diameter node SHOULD send a CM to its > neighboring peers when it determines that its congestion level > changes. =20 > >In the situation where a node is congested, adding additional=20 >load in the form of Congestion Messages is not helpful.=20 > >Also, it is not clear from the document how the congestion=20 >states interact with the state machine specified in RFC 3539: > > CONGESTION_LEVEL_0 0 > > This value indicates that the load on the sender node is below the > manageable limit and the node are ready to handle new messages. > > CONGESTION_LEVEL_1 1 > > This value indicates that the node can still handle messages but > if there is an alternative node, it SHOULD be preferred when > sending requests. > > CONGESTION_LEVEL_2 2 > > This value indicates that no new requests SHOULD be sent to the > node. A node in this state MAY drop request messages. However, > answer messages still SHOULD be sent to the node. > > CONGESTION_LEVEL_3 3 > > This value indicates that no new messages (neither requests nor > answers) SHOULD be sent to the node. A node in this state MAY > drop any received message. > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Nov 16 03:15:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkcP1-0002tj-Bj; Thu, 16 Nov 2006 03:15:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkcP0-0002rN-9F for dime@ietf.org; Thu, 16 Nov 2006 03:15:18 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkcOr-0000Ra-J6 for dime@ietf.org; Thu, 16 Nov 2006 03:15:18 -0500 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 <0J8T00KM2DIFQQ@szxga02-in.huawei.com> for dime@ietf.org; Thu, 16 Nov 2006 16:13:28 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8T00APWDIFQS@szxga02-in.huawei.com> for dime@ietf.org; Thu, 16 Nov 2006 16:13:27 +0800 (CST) Received: from huawei1515 ([10.18.4.60]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J8T00892DIB0M@szxml04-in.huawei.com> for dime@ietf.org; Thu, 16 Nov 2006 16:13:27 +0800 (CST) Date: Thu, 16 Nov 2006 13:43:22 +0530 From: Rajith R Subject: RE: [Dime] Updated errata draft for RFC 3588bis In-reply-to: <455A366A.1030503@tari.toshiba.com> To: 'Victor Fajardo' Message-id: <002a01c70957$15f4adb0$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: AccINN6k+y2tOvCRSxiydCX9Rn00ZgBFNgkg X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: dime@ietf.org 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 (1) Some typo/exclusion: 2.11.2. Text Changes ... -------------------------------------------------- Proposed Changes, Sec 11.3, 4th Paragraph, Ver-00: -------------------------------------------------- Both Auth-Application-Id and Acct-Application-Id AVPs use the same Application Identifier space. A diameter node advertising itself as a relay agent MUST set either Application-Id or Change to (the phrase "either Application-Id or" in the last line to be changed to "either Auth-Application-Id or") 2.11.2. Text Changes ... -------------------------------------------------- Proposed Changes, Sec 11.3, 4th Paragraph, Ver-00: -------------------------------------------------- Both Auth-Application-Id and Acct-Application-Id AVPs use the same Application Identifier space. A diameter node advertising itself as a relay agent MUST set either Auth-Application-Id or (2) I have the following comment on Predictive loop avoidance 6.1.7. Predictive Loop Avoidance Before forwarding or routing a request, Diameter agents, in addition to processing done in Section 6.1.3, SHOULD check for the presence of candidate route's peer identity in any of the Route-Record AVPs. In an event of the agent detecting the presence of a candidate route's peer identity in a Route-Record AVP, the agent MUST ignore such route for the Diameter request message and attempt alternate routes if any. >> [Rajith]: I suppose in the request forward case, on loop prediction, the agent SHOULD return DIAMETER_UNABLE_TO_DELIVER message. Right? So, I suggest this mechanism be used only in Request Routing case. In case all the candidate routes are eliminated by the above criteria, the agent SHOULD return DIAMETER_UNABLE_TO_DELIVER message. Rajith >-----Original Message----- >From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >Sent: Wednesday, November 15, 2006 3:05 AM >To: dime@ietf.org >Subject: [Dime] Updated errata draft for RFC 3588bis > >Hi all, > >An updated version of diameter errata draft can be found in: > >http://www.opendiameter.org/public/draft-fajardo-dime-diameter- >errata-01.txt > >This version includes the comments and decisions made during >IETF67 DIME meeting. Note that all open issues now have >proposed solutions. Pls review them so we can move forward. > >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 Nov 16 10:02:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkikQ-0000tt-JX; Thu, 16 Nov 2006 10:01:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkikP-0000te-Nx for dime@ietf.org; Thu, 16 Nov 2006 10:01:49 -0500 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 1GkikO-0006xn-5l for dime@ietf.org; Thu, 16 Nov 2006 10:01:49 -0500 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 kAGExlgR027593; Thu, 16 Nov 2006 09:59:47 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <455C7CE6.108@tari.toshiba.com> Date: Thu, 16 Nov 2006 09:59:50 -0500 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: rajithr@huawei.com Subject: Re: [Dime] Updated errata draft for RFC 3588bis References: <002a01c70957$15f4adb0$3c04120a@china.huawei.com> In-Reply-To: <002a01c70957$15f4adb0$3c04120a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) 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 Hi Rajith, See inline: > (1) Some typo/exclusion: > 2.11.2. Text Changes > > > ... > > -------------------------------------------------- > Proposed Changes, Sec 11.3, 4th Paragraph, Ver-00: > -------------------------------------------------- > > Both Auth-Application-Id and Acct-Application-Id AVPs use the > same Application Identifier space. A diameter node advertising > itself as a relay agent MUST set either Application-Id or > > Change to (the phrase "either Application-Id or" in the last line to be > changed to "either Auth-Application-Id or") > ok. thanks. > 2.11.2. Text Changes > > > ... > > -------------------------------------------------- > Proposed Changes, Sec 11.3, 4th Paragraph, Ver-00: > -------------------------------------------------- > > Both Auth-Application-Id and Acct-Application-Id AVPs use the > same Application Identifier space. A diameter node advertising > itself as a relay agent MUST set either Auth-Application-Id or > > > (2) I have the following comment on Predictive loop avoidance > > 6.1.7. Predictive Loop Avoidance > > Before forwarding or routing a request, Diameter agents, in > addition to processing done in Section 6.1.3, SHOULD check > for the presence of candidate route's peer identity in any > of the Route-Record AVPs. In an event of the agent detecting > the presence of a candidate route's peer identity in a > Route-Record AVP, the agent MUST ignore such route for the > Diameter request message and attempt alternate routes if any. > > >>> [Rajith]: I suppose in the request forward case, on loop prediction, >>> > the agent SHOULD return DIAMETER_UNABLE_TO_DELIVER message. Right? So, > I suggest this mechanism be used only in Request Routing case. > Yes. This has always been the case as stated in the first sentence of this paragraph. best regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Nov 16 11:25:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkk3M-0005OZ-Pj; Thu, 16 Nov 2006 11:25:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkk3M-0005Lm-8l for dime@ietf.org; Thu, 16 Nov 2006 11:25:28 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkk3K-0001ki-Sd for dime@ietf.org; Thu, 16 Nov 2006 11:25:28 -0500 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 1660C8C1A9 for ; Thu, 16 Nov 2006 11:25:14 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id kAGGPCPv013899 for ; Thu, 16 Nov 2006 11:25:12 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] transport directorate review ofdraft-asveren-dime-cong-00.txt Date: Thu, 16 Nov 2006 11:22:11 -0500 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 Importance: Normal In-Reply-To: Received-SPF: none X-Spam-Score: 2.3 (++) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a 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 A few comments/questions/ are below for people which are interested in this topic. Thanks, Tolga > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Thursday, November 16, 2006 1:27 AM > To: dime@ietf.org > Subject: [Dime] transport directorate review > ofdraft-asveren-dime-cong-00.txt > > > Hi all, > > Some comments from the Transport Directorate. The transport area > general is concerned about congestion issues, so an analysis of > this document was requested. > > Tolga didn't have time to discuss this at the last IETF document, > but it would be good for the wg to read the draft and comment > on the importance of this issue. > > thanks, > John > > >-----Original Message----- > >From: Bernard Aboba [mailto:aboba@internaut.com] > >Sent: 13 November, 2006 19:01 > >To: Magnus Westerlund > >Cc: TSV Dir > >Subject: Re: [tsv-dir] [Fwd: I-D ACTION:draft-asveren-dime-cong-00.txt] > > > >I agree that this document is insufficiently specified and could lead > to > >interoperability problems as well as operational issues. > > > >Diameter is different from RADIUS in that the failover and > >load balancing behavior is specified in "AAA Transport > >Profile" RFC 3539. > > > >Diameter deployments typically involve many clients, so that > >load balancing can be achieved by distributing the clients > >between the Diameter servers. > >Schemes which move clients to "unloaded" Diameter servers (as > >this document does) can result in load oscillations unless the > >algorithms are carefully specified, which this document does not do. [TOLGA]We thought that it could be better to decide for local congestion by local policy. Especially for the cases where multiple application/functionalities are running on the same node, it could be quite difficult to tie congestion levels just to Diameter related parameters. I agree that deciding for congestion levels should be done in a decent way on each node (like providing hysteresis etc..). We can specify guidelines the nodes should follow. I am also interested to hear more about what else could be done on Diameter level about this issue. > > > >Also, this document relies on explicit congestion signalling, > >rather than piggybacking on existing exchanges (e.g. the > >watchdog specified in RFC 3539): > > > > A diameter node SHOULD send a CM to its > > neighboring peers when it determines that its congestion level > > changes. > > > >In the situation where a node is congested, adding additional > >load in the form of Congestion Messages is not helpful. [TOLGA]The idea was to signal congestion before it reaches a level where it impacts the operation of the node significantly. We can explore piggybacking strategies as well. We may send congestion information in DWR/DWA but they are not exchanges when traffic is flowing between two nodes. We may define an AVP to communicate congestion information, which can be piggybacked to any message, but this would be useful only as long as a message is sent from the congested node to its neighbor. To me -at least for now-, an explicit congestion message still seems more attractive because it commnicates congestion information whenever congestion status changes without relying on some other event happening. > > > >Also, it is not clear from the document how the congestion > >states interact with the state machine specified in RFC 3539: > > > > CONGESTION_LEVEL_0 0 > > > > This value indicates that the load on the sender node is below > the > > manageable limit and the node are ready to handle new messages. > > > > CONGESTION_LEVEL_1 1 > > > > This value indicates that the node can still handle messages but > > if there is an alternative node, it SHOULD be preferred when > > sending requests. > > > > CONGESTION_LEVEL_2 2 > > > > This value indicates that no new requests SHOULD be sent to the > > node. A node in this state MAY drop request messages. However, > > answer messages still SHOULD be sent to the node. > > > > CONGESTION_LEVEL_3 3 > > > > This value indicates that no new messages (neither requests nor > > answers) SHOULD be sent to the node. A node in this state MAY > > drop any received message. > > [TOLGA]We may clarify this further. > > _______________________________________________ > 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 Nov 16 12:44:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GklHU-0001J7-Hf; Thu, 16 Nov 2006 12:44:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GklHS-0001Iu-NA for dime@ietf.org; Thu, 16 Nov 2006 12:44:06 -0500 Received: from e31.co.us.ibm.com ([32.97.110.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GklHR-0004pu-3A for dime@ietf.org; Thu, 16 Nov 2006 12:44:06 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e31.co.us.ibm.com (8.13.8/8.12.11) with ESMTP id kAGHi4q0028703 for ; Thu, 16 Nov 2006 12:44:04 -0500 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kAGHi4m0180080 for ; Thu, 16 Nov 2006 10:44:04 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kAGHi3In005735 for ; Thu, 16 Nov 2006 10:44:03 -0700 Received: from d03nm114.boulder.ibm.com (d03nm114.boulder.ibm.com [9.17.195.140]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kAGHi3kr005726; Thu, 16 Nov 2006 10:44:03 -0700 In-Reply-To: To: Subject: Re: [Dime] Diameter Interop MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 Message-ID: From: Timothy Smith Date: Thu, 16 Nov 2006 12:44:02 -0500 X-MIMETrack: Serialize by Router on D03NM114/03/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 11/16/2006 10:44:03, Serialize complete at 11/16/2006 10:44:03 X-Spam-Score: 0.1 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e 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="===============1200699847==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============1200699847== Content-Type: multipart/alternative; boundary="=_alternative 00616A8A85257228_=" This is a multipart message in MIME format. --=_alternative 00616A8A85257228_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgSm9obiAmIEhhbm5lcywNCg0KSSB0aG9yb3VnaGx5IGVuam95ZWQgdGhlIGxhc3QgaW50ZXJv cCBldmVudC4gICBJIHRoaW5rIHRoZSBzcG9uc29yaW5nIA0KY29tcGFueSBkaWQgYSBncmVhdCBq b2IuICBJIHRob3VnaHQgdGhlIGV2ZW50ICB3YXMgYW4gZXhjZWxsZW50IGZvcnVtIHRvIA0KbGVh cm4gYW5kIGltcHJvdmUgb3VyIHVuZGVyc3RhbmRpbmcgYW5kIG91ciBpbXBsZW1lbnRhdGlvbiBv ZiB0aGUgDQpzcGVjaWZpY2F0aW9ucy4gIFNvLCBJJ20gdmVyeSBpbnRlcmVzdGVkIGluIHBhcnRp Y2lwYXRpbmcgYW5kIGhvcGVmdWxsIA0KdGhhdCB3ZSBjYW4gZml0IGl0IGludG8gb3VyIHNjaGVk dWxlcy4gIEl0IGlzIGFib3V0IDMgbW9udGhzIGVhcmxpZXIgdGhhbiANCkkgd291bGQgbGlrZS4g ICBNeSBwcmVmZXJlbmNlIHdvdWxkIGJlIGluIHRoZSBBcHJpbC9NYXkgdGltZWZyYW1lLCBidXQg d2UgDQp3aWxsIHNlZSB3aGF0IHdlIGNhbiBkby4NCg0KU29tZSBjb21tZW50cyBvbiB5b3VyIHF1 ZXN0aW9uczoNCmEuIENvbm5lY3Rpdml0eSB3YXMgZmluZSBpbiBOZXcgSmVyc2V5LiAgSSBkb24n dCB0aGluayB3ZSBuZWVkIHRvIGhhdmUgRE5TIA0Kc3VwcG9ydCBvciB3aWZpIHN1cHBvcnQuICBU aGlzIHdhcyBub3QgYSBwcm9ibGVtLg0KYi4gSSB0aGluayByZW1vdGUgYWNjZXNzIGFuZCB0ZXN0 aW5nIHdvdWxkIGJlIHZlcnkgZGlmZmljdWx0IGFzIHdlIHdlcmUgaW4gDQpuZWVkIG9mIGEgY29u c3RhbnQgZGlhbG9nIGV4Y2hhbmdlIGJldHdlZW4gcGFydGljaXBhbnRzIHdoZW4gd2Ugd2VyZSAN CnNldHRpbmcgdXAgY29ubmVjdGlvbnMuDQpjLiBJIHRoaW5rIG15IG9yZ2FuaXphdGlvbiBpcyBt b3N0bHkgaW50ZXJlc3RlZCBpbiAzR1BQIHByb3RvY29scyB0aGF0IGFuIA0KSU1TIEFwcGxpY2F0 aW9uIFNlcnZlciB3b3VsZCB1c2UgaW5jbHVkaW5nIEFjY291bnRpbmcsIENyZWRpdCBDb250cm9s LCANCmV0Yy4uDQpkLiBJJ20gZmluZSB3aXRoIDQgZGF5cy4gDQoNCkJlc3QgUmVnYXJkcywNClRp bW90aHkgU21pdGgNCg0KdGpzbWl0aEB1cy5pYm0uY29tDQooOTE5KSAyNTQtNDcyMw0KDQoNCg0K DQo8am9obi5sb3VnaG5leUBub2tpYS5jb20+IA0KMTAvMzAvMjAwNiAwNTo0NiBBTQ0KDQpUbw0K PGRpbWVAaWV0Zi5vcmc+DQpjYw0KDQpTdWJqZWN0DQpbRGltZV0gRGlhbWV0ZXIgSW50ZXJvcA0K DQoNCg0KDQoNCg0KSGkgYWxsLA0KDQpXZSBoYXZlIGEgc3BvbnNvciBmb3IgdGhlIG5leHQgRGlh bWV0ZXIgaW50ZXJvcC4gIEFyZSBwZW9wbGUgaW50ZXJlc3RlZCANCmFuZCB3aWxsaW5nIHRvIHBh cnRpY2lwYXRlLiAgU29tZSBkZXRhaWxzIGJlbG93Lg0KIA0KVGhhbmtzLA0KSm9obiAmIEhhbm5l cw0KDQogDQpXZSBoYXZlIGlkZW50aWZpZWQgYSB2ZW51ZSBpbiBPcmxhbmRvLCBGbG9yaWRhLiAN CiANClRoaXMgaXMgc2ltaWxhciB0byB0aGUgcHJldmlvdXMgaW50ZXJvcCBzaXRlLCB3aGljaCB3 YXMgYXQgdGhlIEVudGVycHJpc2UgDQpDZW50ZXIgb2YgdGhlIEJ1cmxpbmd0b24gQ291bnR5IENv bGxlZ2UgY2FtcHVzLiBJdCBpcyBhdCB0aGUgVmFsZW5jaWEgDQpDb3VudHkgQ29sbGVnZSBFbnRl cnByaXNlIENlbnRlci4gVGhpcyBpcyBpbiBhIHZlcnkgY2VudHJhbCBsb2NhdGlvbi4gDQogDQpU aGUgcm9vbSBpcyBhYm91dCBhcyBiaWcgYXMgdGhlIHByZXZpb3VzIG9uZSwgd2hpY2ggY2FuIHNl YXQgYWJvdXQgMzAgDQpwYXJ0aWNpcGFudHMgYW5kIGhhcyBwb3dlciBhbmQgd2lyZWQtSVAgYXQg ZXZlcnkgc2VhdC4gVGhlcmUgaXMgDQp3aXJlbGVzcy1MQU4gYWxzbyBhdmFpbGFibGUuIEkgYW0g b2YgdGhlIG9waW5pb24gdG8gdXNlIHRoZSB3aXJlZCBMQU4gZm9yIA0KdGhlIHRlc3RpbmcsIHdo aWNoIGNhbiBiZSBtYWRlIHByaXZhdGUgZm9yIHRoZSBncm91cCBhbmQgdXNlIHdpcmVsZXNzIGZv ciANCmludGVybmV0IGNvbm5lY3Rpdml0eS4NCiANCldlIGhhdmUgYWxzbyBsb29rZWQgYXQgYSBo b3RlbCB3aXRoaW4gb25lIG1pbGUgb2YgdGhlIHZlbnVlLCB3aGljaCBpcyANCnF1aXRlIGF0dHJh Y3RpdmUgYW5kIGlzIGNvLWxvY2F0ZWQgd2l0aCBvbmUgb2YgT3JsYW5kb+KAmXMgYmlnZ2VzdCBz aG9wcGluZyANCm1hbGwuIEJvdGggdGhlIHZlbnVlIGFuZCB0aGUgaG90ZWwgYXJlIGFib3V0IDYt NyBtaWxlcyBmcm9tIHRoZSBhaXJwb3J0Lg0KIA0KV2UgYXJlIGxvb2tpbmcgYXQgc3VpdGFibGUg ZGF0ZXMgYmV0d2VlbiAyMHRoIEphbiDigJMgMTB0aCBGZWIuIFRoZSBXZWF0aGVyIA0KaW4gRmxv cmlkYSB3aWxsIGJlIHN1bm55IGFuZCBpbiB0aGUgNTBzLg0KIA0KUGxlYXNlIGxldCBtZSBrbm93 IHlvdXIgb3Bpbmlvbi4NCiANCkkgaGF2ZSBhbHNvIHNvbWUgb3RoZXIgcXVlc3Rpb25zLi4NCiAN CmEuICAgICAgSW4gdGVybXMgb2YgbmV0d29yayBjb25uZWN0aXZpdHksIEkgYW0gYXNzdW1pbmcg dGhhdCBzdGF0aWMgSVAgDQphZGRyZXNzZXMgc2hvdWxkIHN1ZmZpY2UuIFdlIHdpbGwgYWxsb2Nh dGUgYW5kIHByZXBhcmUgdGhlIHBhcnRpY2lwYW50cyBhIA0KbGlzdCwgc28gdGhhdCBpdCB3aWxs IHNhdmUgdGltZS4gRm9yIHJlYWxtLWJhc2VkIHJvdXRpbmcsIEkgYXNzdW1lIHRoYXQgDQpmb2xr cyB3aWxsIGJlIGFibGUgdG8gdXNlIHRoZWlyIG93biBtZWNoYW5pc20gc3VjaCBhcyB0aGUgL2V0 Yy9yZXNvbHYuY29uZiANCi9ldGMvaG9zdHMgdG8gcmVzb2x2ZSB0aGUgaG9zdG5hbWUgdG8gSVAg YW5kIG5vIEROUyBpcyByZXF1aXJlZC4gDQogDQpiLiAgICAgIFdlIGhhdmUgbG9va2VkIGF0IG9w dGlvbnMgZm9yIHJlbW90ZSBjb25uZWN0aXZpdHkuIEl0IGlzIHBvc3NpYmxlLCANCmJ1dCB0aGUg cmVtb3RlIHNpZGUgd2lsbCBoYXZlIHRvIGluc3RhbGwgYSBDaXNjbyBWUE4gY2xpZW50LCBiZWNh dXNlIHRoaXMgDQpuZXR3b3JrIGhhcyBhIENpc2NvIFZQTiBzdXBwb3J0LiBEbyB5b3UgdGhpbmsg dGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCBhbmQgDQp2aWFibGU/IA0KIA0KYy4gICAgICBJbiB0aGUg cmVnaXN0cmF0aW9uLCB3ZSB3aWxsIGVucXVpcmUgYWJvdXQgdGhlIHBhcnRpY2lwYW504oCZcyAN CmludGVyZXN0cyBhbmQgY2FuIGJlIGJldHRlciBwcmVwYXJlZC4gVGhlIGFyZWFzIG9mIGludGVy ZXN0IGFyZSANCjNHUFAgYW5kIFRJU1BBTiBhcHBsaWNhdGlvbnMg4oCTIEN4LCBEeCBldGMuLg0K TW9iaWxlSVAsIEVBUCwgTkFTUkVRIA0KRGlhbWV0ZXJTSVANClRMUw0KLi5Xb3VsZCB5b3UgbGlr ZSB0byBhZGQgdG8gdGhpcyBsaXN0Lg0KIA0KZC4gICAgICBIb3cgYWJvdXQgdGhlIGR1cmF0aW9u IG9mIHRoZSBldmVudC4gTGFzdCB0aW1lLCBpdCB3YXMgc2NoZWR1bGVkIA0KZm9yIGZpdmUgZGF5 cy4gTW9zdCBwZW9wbGUgbGVmdCBieSB0aGUgZm91cnRoIGRheS4gU2hvdWxkIHdlIHBsYW4gZm9y IGEgDQp0aHJlZSBkYXkgZXZlbnQgaW5zdGVhZD8gDQogDQplLiBJbiBhZGRpdGlvbiB0byBwdXR0 aW5nIHVwIHRoZSB3ZWItcGFnZSBmb3IgdGhlIHJlZ2lzdHJhdGlvbiwgd2Ugd2lsbCANCnBsYW4g dG8gc2VuZCBhbiBpbnZpdGUgdG8gb3VyIHByZXZpb3VzIHBhcnRpY2lwYW50IGxpc3QgYW5kIGFs c28gc29tZSANCmFkZGl0aW9uYWwgaW1wbGVtZW50YXRpb25zIHRoYXQgd2UgaGF2ZSBiZWVuIGlu dGVyYWN0aW5nIHdpdGguDQogX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkRpTUUgbWFpbGluZyBsaXN0DQpEaU1FQGlldGYub3JnDQpodHRwczovL3d3dzEu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQoNCg0K --=_alternative 00616A8A85257228_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEpvaG4gJmFtcDsgSGFubmVz LDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSB0aG9y b3VnaGx5IGVuam95ZWQgdGhlIGxhc3QgaW50ZXJvcA0KZXZlbnQuICZuYnNwOyBJIHRoaW5rIHRo ZSBzcG9uc29yaW5nIGNvbXBhbnkgZGlkIGEgZ3JlYXQgam9iLiAmbmJzcDtJIHRob3VnaHQNCnRo ZSBldmVudCAmbmJzcDt3YXMgYW4gZXhjZWxsZW50IGZvcnVtIHRvIGxlYXJuIGFuZCBpbXByb3Zl IG91ciB1bmRlcnN0YW5kaW5nDQphbmQgb3VyIGltcGxlbWVudGF0aW9uIG9mIHRoZSBzcGVjaWZp Y2F0aW9ucy4gJm5ic3A7U28sIEknbSB2ZXJ5IGludGVyZXN0ZWQNCmluIHBhcnRpY2lwYXRpbmcg YW5kIGhvcGVmdWxsIHRoYXQgd2UgY2FuIGZpdCBpdCBpbnRvIG91ciBzY2hlZHVsZXMuICZuYnNw O0l0DQppcyBhYm91dCAzIG1vbnRocyBlYXJsaWVyIHRoYW4gSSB3b3VsZCBsaWtlLiAmbmJzcDsg TXkgcHJlZmVyZW5jZSB3b3VsZA0KYmUgaW4gdGhlIEFwcmlsL01heSB0aW1lZnJhbWUsIGJ1dCB3 ZSB3aWxsIHNlZSB3aGF0IHdlIGNhbiBkby48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPlNvbWUgY29tbWVudHMgb24geW91ciBxdWVzdGlvbnM6PC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5hLiBDb25uZWN0aXZpdHkgd2Fz IGZpbmUgaW4gTmV3IEplcnNleS4NCiZuYnNwO0kgZG9uJ3QgdGhpbmsgd2UgbmVlZCB0byBoYXZl IEROUyBzdXBwb3J0IG9yIHdpZmkgc3VwcG9ydC4gJm5ic3A7VGhpcw0Kd2FzIG5vdCBhIHByb2Js ZW0uPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5iLiBJIHRoaW5r IHJlbW90ZSBhY2Nlc3MgYW5kIHRlc3RpbmcNCndvdWxkIGJlIHZlcnkgZGlmZmljdWx0IGFzIHdl IHdlcmUgaW4gbmVlZCBvZiBhIGNvbnN0YW50IGRpYWxvZyBleGNoYW5nZQ0KYmV0d2VlbiBwYXJ0 aWNpcGFudHMgd2hlbiB3ZSB3ZXJlIHNldHRpbmcgdXAgY29ubmVjdGlvbnMuPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5jLiBJIHRoaW5rIG15IG9yZ2FuaXphdGlv biBpcyBtb3N0bHkNCmludGVyZXN0ZWQgaW4gM0dQUCBwcm90b2NvbHMgdGhhdCBhbiBJTVMgQXBw bGljYXRpb24gU2VydmVyIHdvdWxkIHVzZSBpbmNsdWRpbmcNCkFjY291bnRpbmcsIENyZWRpdCBD b250cm9sLCBldGMuLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ ZC4gSSdtIGZpbmUgd2l0aCA0IGRheXMuICZuYnNwOzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QmVzdCBSZWdhcmRzLDwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGltb3RoeSBTbWl0aDwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KdGpzbWl0aEB1cy5pYm0uY29tPGJyPg0KKDkx OSkgMjU0LTQ3MjM8YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9 MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTQwJT48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+PGI+Jmx0O2pvaG4ubG91Z2huZXlAbm9raWEuY29tJmd0OzwvYj4NCjwvZm9u dD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4xMC8zMC8yMDA2IDA1OjQ2IEFN PC9mb250Pg0KPHRkIHdpZHRoPTU5JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij5UbzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Jmx0 O2RpbWVAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFs aWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5jYzwvZm9udD48L2Rpdj4N Cjx0ZD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+U3ViamVjdDwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+W0RpbWVdIERpYW1ldGVyIEludGVyb3A8L2ZvbnQ+PC90YWJs ZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8 YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNl PSJBcmlhbCI+SGkgYWxsLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNl PSJBcmlhbCI+PGJyPg0KV2UgaGF2ZSBhIHNwb25zb3IgZm9yIHRoZSBuZXh0IERpYW1ldGVyIGlu dGVyb3AuICZuYnNwO0FyZSBwZW9wbGUgaW50ZXJlc3RlZA0KYW5kIHdpbGxpbmcgdG8gcGFydGlj aXBhdGUuICZuYnNwO1NvbWUgZGV0YWlscyBiZWxvdy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0z PiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+ VGhhbmtzLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+ Sm9obiAmYW1wOyBIYW5uZXM8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFy aWFsIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5XZSBoYXZl IGlkZW50aWZpZWQgYSB2ZW51ZSBpbiBPcmxhbmRvLCBGbG9yaWRhLg0KPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJBcmlhbCI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJBcmlhbCI+VGhpcyBpcyBzaW1pbGFyIHRvIHRoZSBwcmV2aW91cyBpbnRlcm9wIHNpdGUs DQp3aGljaCB3YXMgYXQgdGhlIEVudGVycHJpc2UgQ2VudGVyIG9mIHRoZSBCdXJsaW5ndG9uIENv dW50eSBDb2xsZWdlIGNhbXB1cy4NCkl0IGlzIGF0IHRoZSBWYWxlbmNpYSBDb3VudHkgQ29sbGVn ZSBFbnRlcnByaXNlIENlbnRlci4gVGhpcyBpcyBpbiBhIHZlcnkNCmNlbnRyYWwgbG9jYXRpb24u IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPlRoZSByb29tIGlzIGFib3V0IGFzIGJpZyBhcyB0 aGUgcHJldmlvdXMNCm9uZSwgd2hpY2ggY2FuIHNlYXQgYWJvdXQgMzAgcGFydGljaXBhbnRzIGFu ZCBoYXMgcG93ZXIgYW5kIHdpcmVkLUlQIGF0DQpldmVyeSBzZWF0LiBUaGVyZSBpcyB3aXJlbGVz cy1MQU4gYWxzbyBhdmFpbGFibGUuIEkgYW0gb2YgdGhlIG9waW5pb24gdG8NCnVzZSB0aGUgd2ly ZWQgTEFOIGZvciB0aGUgdGVzdGluZywgd2hpY2ggY2FuIGJlIG1hZGUgcHJpdmF0ZSBmb3IgdGhl IGdyb3VwDQphbmQgdXNlIHdpcmVsZXNzIGZvciBpbnRlcm5ldCBjb25uZWN0aXZpdHkuPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJBcmlhbCI+V2UgaGF2ZSBhbHNvIGxvb2tlZCBhdCBhIGhvdGVsIHdpdGhp biBvbmUNCm1pbGUgb2YgdGhlIHZlbnVlLCB3aGljaCBpcyBxdWl0ZSBhdHRyYWN0aXZlIGFuZCBp cyBjby1sb2NhdGVkIHdpdGggb25lDQpvZiBPcmxhbmRv4oCZcyBiaWdnZXN0IHNob3BwaW5nIG1h bGwuIEJvdGggdGhlIHZlbnVlIGFuZCB0aGUgaG90ZWwgYXJlIGFib3V0DQo2LTcgbWlsZXMgZnJv bSB0aGUgYWlycG9ydC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJz cDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5XZSBhcmUgbG9va2luZyBh dCBzdWl0YWJsZSBkYXRlcyBiZXR3ZWVuDQoyMDxzdXA+dGg8L3N1cD4gSmFuIOKAkyAxMDxzdXA+ dGg8L3N1cD4gRmViLiBUaGUgV2VhdGhlciBpbiBGbG9yaWRhIHdpbGwNCmJlIHN1bm55IGFuZCBp biB0aGUgNTBzLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPiZuYnNwOzwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPlBsZWFzZSBsZXQgbWUga25vdyB5 b3VyIG9waW5pb24uPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+Jm5ic3A7 PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+SSBoYXZlIGFsc28gc29tZSBv dGhlciBxdWVzdGlvbnMuLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPiZu YnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+YS4gJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+SW4N CnRlcm1zIG9mIG5ldHdvcmsgY29ubmVjdGl2aXR5LCBJIGFtIGFzc3VtaW5nIHRoYXQgc3RhdGlj IElQIGFkZHJlc3NlcyBzaG91bGQNCnN1ZmZpY2UuIFdlIHdpbGwgYWxsb2NhdGUgYW5kIHByZXBh cmUgdGhlIHBhcnRpY2lwYW50cyBhIGxpc3QsIHNvIHRoYXQNCml0IHdpbGwgc2F2ZSB0aW1lLiBG b3IgcmVhbG0tYmFzZWQgcm91dGluZywgSSBhc3N1bWUgdGhhdCBmb2xrcyB3aWxsIGJlDQphYmxl IHRvIHVzZSB0aGVpciBvd24gbWVjaGFuaXNtIHN1Y2ggYXMgdGhlIC9ldGMvcmVzb2x2LmNvbmYg L2V0Yy9ob3N0cw0KdG8gcmVzb2x2ZSB0aGUgaG9zdG5hbWUgdG8gSVAgYW5kIG5vIEROUyBpcyBy ZXF1aXJlZC48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmIuICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPldlDQpoYXZlIGxvb2tlZCBhdCBvcHRp b25zIGZvciByZW1vdGUgY29ubmVjdGl2aXR5LiBJdCBpcyBwb3NzaWJsZSwgYnV0IHRoZQ0KcmVt b3RlIHNpZGUgd2lsbCBoYXZlIHRvIGluc3RhbGwgYSBDaXNjbyBWUE4gY2xpZW50LCBiZWNhdXNl IHRoaXMgbmV0d29yaw0KaGFzIGEgQ2lzY28gVlBOIHN1cHBvcnQuIERvIHlvdSB0aGluayB0aGF0 IGl0IHdpbGwgYmUgdXNlZnVsIGFuZCB2aWFibGU/PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+ Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5jLiAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5J bg0KdGhlIHJlZ2lzdHJhdGlvbiwgd2Ugd2lsbCBlbnF1aXJlIGFib3V0IHRoZSBwYXJ0aWNpcGFu dOKAmXMgaW50ZXJlc3RzIGFuZA0KY2FuIGJlIGJldHRlciBwcmVwYXJlZC4gVGhlIGFyZWFzIG9m IGludGVyZXN0IGFyZTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4N CjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjNHUFAgYW5kIFRJU1BBTiBh cHBsaWNhdGlvbnMg4oCTIEN4LCBEeCBldGMuLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0iQXJpYWwiPk1vYmlsZUlQLCBFQVAsIE5BU1JFUSA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9IkFyaWFsIj5EaWFtZXRlclNJUDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i QXJpYWwiPlRMUzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPi4uV291bGQg eW91IGxpa2UgdG8gYWRkIHRvIHRoaXMgbGlzdC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPmQuICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgZmFj ZT0iQXJpYWwiPkhvdw0KYWJvdXQgdGhlIGR1cmF0aW9uIG9mIHRoZSBldmVudC4gTGFzdCB0aW1l LCBpdCB3YXMgc2NoZWR1bGVkIGZvciBmaXZlIGRheXMuDQpNb3N0IHBlb3BsZSBsZWZ0IGJ5IHRo ZSBmb3VydGggZGF5LiBTaG91bGQgd2UgcGxhbiBmb3IgYSB0aHJlZSBkYXkgZXZlbnQNCmluc3Rl YWQ/PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9IkFyaWFsIj5lLiBJbiBhZGRpdGlvbiB0byBwdXR0aW5nIHVwIHRoZSB3ZWItcGFn ZQ0KZm9yIHRoZSByZWdpc3RyYXRpb24sIHdlIHdpbGwgcGxhbiB0byBzZW5kIGFuIGludml0ZSB0 byBvdXIgcHJldmlvdXMgcGFydGljaXBhbnQNCmxpc3QgYW5kIGFsc28gc29tZSBhZGRpdGlvbmFs IGltcGxlbWVudGF0aW9ucyB0aGF0IHdlIGhhdmUgYmVlbiBpbnRlcmFjdGluZw0Kd2l0aC48L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250 Pjx0dD48Zm9udCBzaXplPTI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpEaU1FIG1haWxpbmcgbGlzdDxicj4NCkRpTUVAaWV0Zi5vcmc8YnI+DQpo dHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lPGJyPg0KPC9mb250Pjwv dHQ+DQo8YnI+DQo= --=_alternative 00616A8A85257228_=-- --===============1200699847== 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 --===============1200699847==-- From dime-bounces@ietf.org Thu Nov 16 14:53:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GknIP-0000sq-UF; Thu, 16 Nov 2006 14:53:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GknIO-0000sj-ND for dime@ietf.org; Thu, 16 Nov 2006 14:53:12 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GknIN-000147-FO for dime@ietf.org; Thu, 16 Nov 2006 14:53:12 -0500 Received: (qmail invoked by alias); 16 Nov 2006 19:53:09 -0000 Received: from p54987F64.dip.t-dialin.net (EHLO [192.168.2.32]) [84.152.127.100] by mail.gmx.net (mp028) with SMTP; 16 Nov 2006 20:53:09 +0100 X-Authenticated: #29516787 Message-ID: <455CC1A7.7000601@gmx.net> Date: Thu, 16 Nov 2006 20:53:11 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Tom-PT Taylor 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: 7aefe408d50e9c7c47615841cb314bed Cc: dime@ietf.org Subject: [Dime] Input for Diameter Test Cases 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 Tom, during the DIME meeting you mentioned that you could provide us with some test cases (collected from another interop event). Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Nov 16 15:16:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkned-0003fY-77; Thu, 16 Nov 2006 15:16:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkneb-0003ei-S8 for dime@ietf.org; Thu, 16 Nov 2006 15:16:09 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GkneZ-0005t8-EX for dime@ietf.org; Thu, 16 Nov 2006 15:16:09 -0500 Received: (qmail invoked by alias); 16 Nov 2006 20:16:05 -0000 Received: from p54987F64.dip.t-dialin.net (EHLO [192.168.2.32]) [84.152.127.100] by mail.gmx.net (mp036) with SMTP; 16 Nov 2006 21:16:05 +0100 X-Authenticated: #29516787 Message-ID: <455CC708.8030601@gmx.net> Date: Thu, 16 Nov 2006 21:16:08 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: dime@ietf.org 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: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Dime] Starting Work on Diameter Interop Test Cases 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, at the DIME working group meeting we indicated that it would be good to start with the preparation of the Diameter interop by working on the diameter test cases draft to ensure that we are well prepared. Here is the current draft: http://tools.ietf.org/wg/dime/draft-fajardo-dime-interop-test-suite-01.txt Those people who plan to participate at the next interop and who likes to provide input should send us (John and myself) a mail. Ciao Hannes & John _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Nov 17 04:13:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkzmp-0006Bb-OW; Fri, 17 Nov 2006 04:13:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkzmo-0006BL-Uz for dime@ietf.org; Fri, 17 Nov 2006 04:13:26 -0500 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkzmn-0002UU-Ds for dime@ietf.org; Fri, 17 Nov 2006 04:13:26 -0500 Received: by ug-out-1314.google.com with SMTP id 72so593302ugd for ; Fri, 17 Nov 2006 01:13:23 -0800 (PST) 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=saratnIappJHIJeRggHW7Wfgbs/ftAMAW06H0J/HNMCvZ2apdIytIq4MWPwjg4iWQ0XuRTSxsPjqxfn5idNGu0K63sDd6d3RInWXjTLAMukNMlGUsnTwRJHMCtaP+pqTP/iRJCXjKPieF2nR6scDqGeS0RuasSP4hf1cwexZFII= Received: by 10.67.22.7 with SMTP id z7mr2313507ugi.1163754802836; Fri, 17 Nov 2006 01:13:22 -0800 (PST) Received: by 10.66.216.9 with HTTP; Fri, 17 Nov 2006 01:13:22 -0800 (PST) Message-ID: <5e2406980611170113w2da79e35vf4a755f7c9cb78e2@mail.gmail.com> Date: Fri, 17 Nov 2006 10:13:22 +0100 From: "Julien Bournelle" To: "Ram O V Vishnu-A14676" Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7CCD07160348804497EF29E9EA5560D7FBD4E9@exchtewks2.starentnetworks.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c 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 11/15/06, Ram O V Vishnu-A14676 wrote: > Hannes, > > I think this "split-within-split" (if I may call it so) is hard to > understand. > > In slide-5, I don't see any interface between AAA-EAP Server and > AAA-MIP6 Server, but I definitely see that they are boxed together as an > MSA. Hence I conclude that there is no question of interoperability or > something between these. It's the MSA's job to authenticate & authorize > MIP. It could do it using 2 server, 3, 4 etc. It could do it using 2 > processes, 2 tasks, 2 threads too. In either of these cases, since it > has taken up the responsibility of doing the auth & auth, it has to have > some mechanism of making sure no security hole exist. > > So, as it stands, in slide-5, the AAA-EAP server and AAA-MIP6 server > might as well be not shown. MSA could be shown as a black box. > > If someone could shed some light on the motivation behind the split, any > other arrows/interfaces which might land on AAA-EAP Server or on > AAA-MIP6 Server, it would be interesting to discuss those. basically, as we will have 2 application-id (one for EAP and one for mip6-Authorization/accounting), AAA messages may be routed to different AAA servers. That's why we draw 2 different boxes. regards, Julien > > Regards, > Vishnu. > > Motorola > +91 9844178052 > [] General > [*] Motorola Internal Use Only > > > > -----Original Message----- > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > Sent: Wednesday, November 15, 2006 10:13 AM > To: Hannes Tschofenig; dime@ietf.org > Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server > Split > > > Hi Hannes, > > IMHO, at the time of EAP authentication the MS needs to be authorized > for MIP6 service. This is because: > > Regardless of whether EAP is used or some other auth method is used to > authenticate the MN, the entity that is authenticating the MN is the > MSA. The MSA by definition (Mobility Service Authorizer) needs to > Authenticate and Authorize the MN. For HoA bootstrapping, at the time of > IKEv2 transaction the HA needs to know whether the MN is authorized for > mobility service (MIP6 in this case) or not. Therefore, the AAA server > needs to either return an AVP along with EAP-Success to indicate to the > HA that the MN is authorized for MIP6 service or the AAA server can > return the address of another AAA server in the MSA that needs to be > contacted for MIP6 authorization for the MN. > > I think the former (MIP6 authorization AVP along with EAP success) is a > better option. In that case a single server for both auth and authz > should be suffice. > > -Kuntal > > > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Friday, November 10, 2006 6:26 PM > > To: dime@ietf.org > > Subject: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split > > > > Hi all, > > > > during the DIME meeting Glen raised an important question that impacts > > > the design of the protocol, namely: " > > Do we need to support the scenario where the Diameter EAP > authentication > > and the Diameter MIPv6 authorization exchange terminate at different > > servers? " > > > > Currently, we assume that these two exchanges could be terminated at > > different servers. As a consequence, security concerns were raised > (see > > slide 5 > > of http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt). > > > > How do people think about restricting the Diameter MIPv6 HA-to-AAAH > > document to terminate the authentication and authorization exchange at > > > the same server? > > > > Ciao > > Hannes > > > > PS: Glen also suggested to consider using the Diameter MIPv6 App-ID > for > > the Diameter EAP exchange if we decide that both exchanges terminate > at > > the same server. As a consequence the open issue described at slide 6 > of > > http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt would also be > > > resolved. The changes to the existing document would be minimal (about > 2 > > additional sentences). > > > > > > _______________________________________________ > > 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 Nov 17 11:00:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl68t-0003Me-Aq; Fri, 17 Nov 2006 11:00:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl68r-0003MV-JK for dime@ietf.org; Fri, 17 Nov 2006 11:00:38 -0500 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl68a-00068D-Q0 for dime@ietf.org; Fri, 17 Nov 2006 11:00:37 -0500 Received: by ug-out-1314.google.com with SMTP id 72so670043ugd for ; Fri, 17 Nov 2006 08:00:17 -0800 (PST) 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=t/4/r5E7JlIVbvb4KLsojBXHiskW2NrJvPur4NB7Z5dsuufK0lXOfHMxPPnO3MRljSCXTspW2LneYJw+0tIWdfOwNOsDiygMMpedfuBTDXK/47gC4w1WdRlTY721ZnY4kM3H9wWz7A8AYMuhl0ffe9H7gmDgzFbiU5kB4k7EIXI= Received: by 10.66.221.6 with SMTP id t6mr2296225ugg.1163779217122; Fri, 17 Nov 2006 08:00:17 -0800 (PST) Received: by 10.66.216.9 with HTTP; Fri, 17 Nov 2006 08:00:16 -0800 (PST) Message-ID: <5e2406980611170800u625edd31x382ce18459c258fe@mail.gmail.com> Date: Fri, 17 Nov 2006 17:00:16 +0100 From: "Julien Bournelle" To: "Madjid Nakhjiri" Subject: Re: [Dime] RE: [Mip6] Should we add the requirements that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? In-Reply-To: <002201c708fb$afef0840$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: <002201c708fb$afef0840$2f01a8c0@china.huawei.com> X-Spam-Score: 0.6 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: "Gopal Dommety \(gdommety\)" , "Kent Leung \(kleung\)" , dime@ietf.org, mip6@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, all, On 11/15/06, Madjid Nakhjiri wrote: > Hi Gerardo, > > > If you remember, the first time people asked this question, I said we should > simply be careful about rubber stamping the Dime drafts as supporting 4285. > Unless the HA-AAA goal doc includes specific requirements on supporting > 4285, we should refrain from making the promise that Dime draft do too. > If we design something based on a requirement that excludes support for > 4285, then the solution has no obligation to support it either. can't we have requirements for 4285 in aaa-ha-goals and have separate AAA solutions for IPsec and 4285 case ? > > I am going to reiterate all my points. > 1) "AAA goal/requirement document" means requirements for both RADIUS and > Diameter. Unless you want to change the name, we need to realize that this > document can > a) create requirements that RADIUS cannot meet and hence rule out RADIUS for > MIP6 support (some of the current goals related to key transport fit that > category) what do you propose ? > b) create requirement for all AAA functionality, i.e both requirements on > AAA functionality within HA and on AAA protocol. This means if an HA works > according to 4285, then the document needs to include requirement for > supporting 4285 as well. Dime drafts can come and state whether they fulfill > all requirements, including 4285 requirements. We already have two dime > drafts for two different designs. > > Currently, the document seemed to be treated as "requirement for Dime > bootstrapping drafts". Is that the intention? The answer seems to be yes > from your email. So the HA-AAA goals is not a generic requirement goal for > MIP6. The current HA-AAA goals document should specifically state that it is > the requirements for Diameter EAP based solutions and not for 4285 to clear > all the issues above. this was not the intention. > > Personally I think support for 4285 is a lot simpler than people think, and > might not require much more than some AVPs and look similar to 4004 for MIP4 > support in case of CCOA, but I have not done a detail analysis. If that is > true all 4285 needs in way of requirements is probably being allowed to have > some new AVPs (or possibly same as those used in MIP4). > > The problem of excluding these from HA-AAA goal is that you may need a new > Diameter MIP6 App ID for 4285, if the AVPs are brand new? For the Diameter case, I think we may need another application to support 4285. But i don't think that the problem of the mip6 WG. I think we could have some requirements for 4285 in aaa-ha-goals and then it's up to related AAA groups to deal with that. regards, Julien > > Hope THIS clarifies some more :) > > Regards, > > Madjid > > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > Sent: Tuesday, November 14, 2006 3:31 PM > To: Madjid Nakhjiri > Cc: Kent Leung (kleung); Vijay Devarapalli; Gopal Dommety (gdommety); > mip6@ietf.org > Subject: Re: [Mip6] Should we add the requirements that arise from RFC > 4285inthe draft-ietf-mip6-aaa-ha-goals-03? > > Current work in DIME WG is based on rfc3775/3776 and on the IPsec > bootstrapping solution. This has lead so far to a re-use of rfc4072 > for EAP packets transport between HA and AAAH and STR/STA/ASR/ASR > re-use for the session management. > > This means that in case rfc4285 is used, the Diameter application we > are designing cannot be used. The session management and authorization > part can be kept the same, but there would be a need to specify how > the HA authenticates the BUs in case of dynamic keying (something > similar to MIP4 approach). > > So the question is: should the AAA requirements doc (and consequently > the DIME solution - but this is a question for DIME WG) list also that > the HA-AAA communication may be able to bootstrap and authenticate > rfc4285 security associations? > > I hope this clarifies. > > --Gerardo > > On 11/14/06, Madjid Nakhjiri wrote: > > Personally, I suspect that 4285 support simply needs a bunch of > attributes. > > I suggest people propose a couple of requirements related to 4285 support > > and after that we could easily see if those can be added to the current > set > > of goals. Once we did that we can simply say the HA-AAAH support 4285. > > > > Madjid > > > > -----Original Message----- > > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > > Sent: Tuesday, November 14, 2006 12:08 PM > > To: Vijay Devarapalli; Gopal Dommety (gdommety) > > Cc: mip6@ietf.org > > Subject: RE: [Mip6] Should we add the requirements that arise from RFC > > 4285inthe draft-ietf-mip6-aaa-ha-goals-03? > > > > > > My vote is YES. > > > > I assume this question is intended for HA-AAA interface support for RFC > > 4285. But it would be definitely nice to have standards-based AAA > > attributes for bootstrapping in terms of completeness. > > > > Kent > > > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > > Sent: Tuesday, November 14, 2006 10:26 AM > > To: Gopal Dommety (gdommety) > > Cc: mip6@ietf.org > > Subject: Re: [Mip6] Should we add the requirements that arise from RFC > > 4285in the draft-ietf-mip6-aaa-ha-goals-03? > > > > Gopal, > > > > lets step back a bit. what is the point of adding of 4285-specific > > requirements in draft-ietf-mip6-aaa-ha-goals? is it just for basic > > 4285 operation where the HA-AAAH interface is used for MN > > authentication? or does it include bootstrapping for 4285 too? > > > > will the requirements be added to > > draft-ietf-mip6-aaa-ha-goals-03 just to capture all the requirements in > > one place with no binding to develop any solutions yet? > > > > other bootstrapping related questions, do we want to standardize > > bootstrapping solutions for 4285 too? has the DIME WG agreed to > > developing solutions for 4285-based MIP6 operation? > > > > Vijay > > > > Gopal Dommety (gdommety) wrote: > > > Hello All, > > > > > > Wanted to get the MIP6 Working groups preference on whether we > > > should we add the requirements that arise from RFC 4285 in the > > > draft-ietf-mip6-aaa-ha-goals-03 > > > > > > We would like to hear the Working Groups opinion of the following > > question: > > > > > > Should we add the requirements that arise from RFC 4285 in the > > > draft-ietf-mip6-aaa-ha-goals-03? > > > > > > Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there > > > were > > > 14 people for "yes" and 5 for "No". > > > > > > Cheers, > > > Gopal and Raj > > > > > > > > > ---------------------------------------------------------------------- > > > -- > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > _______________________________________________ > 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 Nov 17 11:13:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl6LO-0001Ee-7g; Fri, 17 Nov 2006 11:13:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl6LM-0001EU-W8; Fri, 17 Nov 2006 11:13:33 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl6LI-0007gk-5a; Fri, 17 Nov 2006 11:13:32 -0500 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 <0J8V00KR7UED9V@usaga01-in.huawei.com>; Fri, 17 Nov 2006 08:13:25 -0800 (PST) Received: from N737011 (c-24-17-254-79.hsd1.mn.comcast.net [24.17.254.79]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J8V00BDQUE64C@usaga01-in.huawei.com>; Fri, 17 Nov 2006 08:13:25 -0800 (PST) Date: Fri, 17 Nov 2006 08:13:17 -0800 From: Madjid Nakhjiri Subject: RE: [Dime] RE: [Mip6] Should we add the requirements that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? In-reply-to: <5e2406980611170800u625edd31x382ce18459c258fe@mail.gmail.com> To: 'Julien Bournelle' Message-id: <002301c70a63$4bc12e20$02fda8c0@china.huawei.com> 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: AccKYX5G9ERyUGnZTcuPa2bxg1xEzQAAMVCQ X-Spam-Score: 0.6 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Cc: "'Gopal Dommety \(gdommety\)'" , "'Kent Leung \(kleung\)'" , 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 Julien, -----Original Message----- From: Julien Bournelle [mailto:julien.bournelle@gmail.com] Sent: Friday, November 17, 2006 8:00 AM To: Madjid Nakhjiri Cc: Gerardo Giaretta; Gopal Dommety (gdommety); Kent Leung (kleung); mip6@ietf.org; dime@ietf.org Subject: Re: [Dime] RE: [Mip6] Should we add the requirements that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? Hi madjid, all, On 11/15/06, Madjid Nakhjiri wrote: > Hi Gerardo, > > > If you remember, the first time people asked this question, I said we should > simply be careful about rubber stamping the Dime drafts as supporting 4285. > Unless the HA-AAA goal doc includes specific requirements on supporting > 4285, we should refrain from making the promise that Dime draft do too. > If we design something based on a requirement that excludes support for > 4285, then the solution has no obligation to support it either. can't we have requirements for 4285 in aaa-ha-goals and have separate AAA solutions for IPsec and 4285 case ? Madjid>>Absolutely, especially if the requirement for 4285 support is not MUST, and from Raj that seems to be the case. However, the 4285 experts should add a few words about what these requirements are. > > I am going to reiterate all my points. > 1) "AAA goal/requirement document" means requirements for both RADIUS and > Diameter. Unless you want to change the name, we need to realize that this > document can > a) create requirements that RADIUS cannot meet and hence rule out RADIUS for > MIP6 support (some of the current goals related to key transport fit that > category) what do you propose ? Madjid>>I am proposing to the remove the goal that requires secure key transport (I had a discussion on that with Gerarado already, I believe it was called a general goal) and just leave the note in the security consideration section. That way, RADIUS is not ruled out unintentionally. > b) create requirement for all AAA functionality, i.e both requirements on > AAA functionality within HA and on AAA protocol. This means if an HA works > according to 4285, then the document needs to include requirement for > supporting 4285 as well. Dime drafts can come and state whether they fulfill > all requirements, including 4285 requirements. We already have two dime > drafts for two different designs. > > Currently, the document seemed to be treated as "requirement for Dime > bootstrapping drafts". Is that the intention? The answer seems to be yes > from your email. So the HA-AAA goals is not a generic requirement goal for > MIP6. The current HA-AAA goals document should specifically state that it is > the requirements for Diameter EAP based solutions and not for 4285 to clear > all the issues above. this was not the intention. Madjid>> seems to be the outcome:) > > Personally I think support for 4285 is a lot simpler than people think, and > might not require much more than some AVPs and look similar to 4004 for MIP4 > support in case of CCOA, but I have not done a detail analysis. If that is > true all 4285 needs in way of requirements is probably being allowed to have > some new AVPs (or possibly same as those used in MIP4). > > The problem of excluding these from HA-AAA goal is that you may need a new > Diameter MIP6 App ID for 4285, if the AVPs are brand new? For the Diameter case, I think we may need another application to support 4285. But i don't think that the problem of the mip6 WG. I think we could have some requirements for 4285 in aaa-ha-goals and then it's up to related AAA groups to deal with that. Madjid>>Again, I feel that only AVPs are needed, but I am not sure. We (people who want 4285) need to look closely and see whether these AVPs can be supported by 4004 or by the future RFCs supporting IKEv2 solutions. If it turns out we need mandatory AVPs that cannot be supported by these RFCs that we need a new Diameter application. And yes, all this means the work is to be done in Dime, if there is enough interest. Regards, Madjid regards, Julien > > Hope THIS clarifies some more :) > > Regards, > > Madjid > > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > Sent: Tuesday, November 14, 2006 3:31 PM > To: Madjid Nakhjiri > Cc: Kent Leung (kleung); Vijay Devarapalli; Gopal Dommety (gdommety); > mip6@ietf.org > Subject: Re: [Mip6] Should we add the requirements that arise from RFC > 4285inthe draft-ietf-mip6-aaa-ha-goals-03? > > Current work in DIME WG is based on rfc3775/3776 and on the IPsec > bootstrapping solution. This has lead so far to a re-use of rfc4072 > for EAP packets transport between HA and AAAH and STR/STA/ASR/ASR > re-use for the session management. > > This means that in case rfc4285 is used, the Diameter application we > are designing cannot be used. The session management and authorization > part can be kept the same, but there would be a need to specify how > the HA authenticates the BUs in case of dynamic keying (something > similar to MIP4 approach). > > So the question is: should the AAA requirements doc (and consequently > the DIME solution - but this is a question for DIME WG) list also that > the HA-AAA communication may be able to bootstrap and authenticate > rfc4285 security associations? > > I hope this clarifies. > > --Gerardo > > On 11/14/06, Madjid Nakhjiri wrote: > > Personally, I suspect that 4285 support simply needs a bunch of > attributes. > > I suggest people propose a couple of requirements related to 4285 support > > and after that we could easily see if those can be added to the current > set > > of goals. Once we did that we can simply say the HA-AAAH support 4285. > > > > Madjid > > > > -----Original Message----- > > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > > Sent: Tuesday, November 14, 2006 12:08 PM > > To: Vijay Devarapalli; Gopal Dommety (gdommety) > > Cc: mip6@ietf.org > > Subject: RE: [Mip6] Should we add the requirements that arise from RFC > > 4285inthe draft-ietf-mip6-aaa-ha-goals-03? > > > > > > My vote is YES. > > > > I assume this question is intended for HA-AAA interface support for RFC > > 4285. But it would be definitely nice to have standards-based AAA > > attributes for bootstrapping in terms of completeness. > > > > Kent > > > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > > Sent: Tuesday, November 14, 2006 10:26 AM > > To: Gopal Dommety (gdommety) > > Cc: mip6@ietf.org > > Subject: Re: [Mip6] Should we add the requirements that arise from RFC > > 4285in the draft-ietf-mip6-aaa-ha-goals-03? > > > > Gopal, > > > > lets step back a bit. what is the point of adding of 4285-specific > > requirements in draft-ietf-mip6-aaa-ha-goals? is it just for basic > > 4285 operation where the HA-AAAH interface is used for MN > > authentication? or does it include bootstrapping for 4285 too? > > > > will the requirements be added to > > draft-ietf-mip6-aaa-ha-goals-03 just to capture all the requirements in > > one place with no binding to develop any solutions yet? > > > > other bootstrapping related questions, do we want to standardize > > bootstrapping solutions for 4285 too? has the DIME WG agreed to > > developing solutions for 4285-based MIP6 operation? > > > > Vijay > > > > Gopal Dommety (gdommety) wrote: > > > Hello All, > > > > > > Wanted to get the MIP6 Working groups preference on whether we > > > should we add the requirements that arise from RFC 4285 in the > > > draft-ietf-mip6-aaa-ha-goals-03 > > > > > > We would like to hear the Working Groups opinion of the following > > question: > > > > > > Should we add the requirements that arise from RFC 4285 in the > > > draft-ietf-mip6-aaa-ha-goals-03? > > > > > > Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there > > > were > > > 14 people for "yes" and 5 for "No". > > > > > > Cheers, > > > Gopal and Raj > > > > > > > > > ---------------------------------------------------------------------- > > > -- > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > _______________________________________________ > 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 Nov 19 10:14:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GloNW-0005i4-LN; Sun, 19 Nov 2006 10:14:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GloNV-0005hw-4t for dime@ietf.org; Sun, 19 Nov 2006 10:14:41 -0500 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 1GloNP-0005XN-PR for dime@ietf.org; Sun, 19 Nov 2006 10:14:41 -0500 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id kAJFDkra039237; Sun, 19 Nov 2006 10:13:47 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <456074AA.3010203@tari.toshiba.com> Date: Sun, 19 Nov 2006 10:13:46 -0500 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: Glenn McGregor Subject: Re: [Dime] Updated errata draft for RFC 3588bis References: <455A366A.1030503@tari.toshiba.com> <455E3D49.4060007@lucentradius.com> In-Reply-To: <455E3D49.4060007@lucentradius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 Ok. Thanks. For non-technical issues such as these (and others previously reported), I've directly updated the errata draft. The latest version is in: http://www.opendiameter.org/public/draft-fajardo-dime-diameter-errata-01.txt best regards, victor > Victor Fajardo wrote: >> Hi all, >> >> An updated version of diameter errata draft can be found in: >> >> http://www.opendiameter.org/public/draft-fajardo-dime-diameter-errata-01.txt >> >> >> This version includes the comments and decisions made during IETF67 >> DIME meeting. Note that all open issues now have proposed solutions. >> Pls review them so we can move forward. >> >> best regards, >> victor >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime > > Here's another... > > > Section 5.5.2 > > Original-State-Id should be Origin-State-Id in the DWA ABNF. > > > Glenn McGregor > Lucent Technologies _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Nov 20 07:54:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm8fI-0005UT-CT; Mon, 20 Nov 2006 07:54:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm8fH-0005UO-MV for dime@ietf.org; Mon, 20 Nov 2006 07:54:23 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gm8fF-0003MC-Cw for dime@ietf.org; Mon, 20 Nov 2006 07:54:23 -0500 Received: (qmail invoked by alias); 20 Nov 2006 12:54:19 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp037) with SMTP; 20 Nov 2006 13:54:19 +0100 X-Authenticated: #29516787 Message-ID: <4561A56C.6010700@gmx.net> Date: Mon, 20 Nov 2006 13:54:04 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: dime@ietf.org 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Dime] WGLC for Diameter API Document 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 an announcement of another working group last call on draft-ietf-dime-diameter-api-00.txt, which may be found at: http://tools.ietf.org/wg/dime/draft-ietf-dime-diameter-api/draft-ietf-dime-diameter-api-00.txt This WGLC will end on Monday 4th December. Please mail technical comments to the DIME list and to the authors. Ciao Hannes & John _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Nov 20 09:42:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmALs-0005KM-IE; Mon, 20 Nov 2006 09:42:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmALr-0005K0-Sz for dime@ietf.org; Mon, 20 Nov 2006 09:42:27 -0500 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmALq-00042o-Bf for dime@ietf.org; Mon, 20 Nov 2006 09:42:27 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAKDnOnZ010306; Mon, 20 Nov 2006 15:49:34 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Nov 2006 15:49:23 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Nov 2006 15:49:22 +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] WGLC for Diameter API Document Date: Mon, 20 Nov 2006 15:49:22 +0200 Message-ID: In-Reply-To: <4561A56C.6010700@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] WGLC for Diameter API Document Thread-Index: AccMpE2Pzipqs4eYSK+3GPlL5ImydAABduVg From: To: , X-OriginalArrivalTime: 20 Nov 2006 13:49:22.0996 (UTC) FILETIME=[AF651740:01C70CAA] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 Just as a follow-on. The document authors indicate that there are no open technical issues. During the previous WGLC, there were no technical issues raised, but more procedural issues raised. If there are no techincal issues raised, but only procedural issues raised, we may seek to have this published as an individual RFC.=20 All technical issues will be considered. Any procedural issues will be considered seperately. However, as the authors feel that this document is ready for publication, we will seek to have it published as an information RFC. thanks, Hannes & John=20 >-----Original Message----- >From: ext Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 >Sent: 20 November, 2006 14:54 >To: dime@ietf.org >Subject: [Dime] WGLC for Diameter API Document > >Hi all, > >This is an announcement of another working group last call on=20 >draft-ietf-dime-diameter-api-00.txt, which may be found at: > >http://tools.ietf.org/wg/dime/draft-ietf-dime-diameter-api/draf >t-ietf-dime-diameter-api-00.txt > >This WGLC will end on Monday 4th December. > >Please mail technical comments to the DIME list and to the authors. > >Ciao >Hannes & John > >_______________________________________________ >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 Nov 21 10:05:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmXBP-0004a8-Ko; Tue, 21 Nov 2006 10:05:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmXBN-0004Xn-Rx for dime@ietf.org; Tue, 21 Nov 2006 10:05:10 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmXBK-0003N0-6W for dime@ietf.org; Tue, 21 Nov 2006 10:05:09 -0500 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 A7AD483E64 for ; Tue, 21 Nov 2006 10:04:53 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id kALF4qYd003630 for ; Tue, 21 Nov 2006 10:04:52 -0500 (EST) From: "Tolga Asveren" To: Date: Tue, 21 Nov 2006 10:02:16 -0500 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: 42e3ed3f10a1d8bef690f09da16f507a Subject: [Dime] Redundancy support AVPs 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, During the interoperability testing there were some ideas about having more support in Diameter to facilitate redundant implementations. I guess also during some threads in DIME WG similar opinions were expressed. During the last IETF DIME WG meeting, I had the chance to briefly mention about this issue as well and said that I will provide some text for review/to get opinions. The initial version of the text is below. I also entered it to the issue tracker (#25). Does this look good to others? Shall/can we include this in the bis? Thanks, Tolga ============================================================================ = Some generic support to preserve opaque session data in messages and to communicate server support for session level failover could be very useful to facilitate development of redundant systems. The following changes are proposed: ================================================================ 8.22 Session-Info AVP is used by application sessions to store session related opaque data in the messages. This AVP carries state information that are communicated between Diameter application end-points only. It provides applications with a generic method to store opaque data in messages for high availability, redundancy or other purposes that may not be defined in the Diameter application itself. AVP Flag Rules AVP Data SHLD MUST MAY Attribute Name Code Type MUST MAY NOT NOT Encr Session-Info XYZ Grouped M P V Y Origin-Host 264 DiamIdent M P V Y Session-Data XYZ OctetString M P V Y Session-Info AVP The Session-Info AVP (AVP code xyz) is of type Grouped and is used by Diameter entities serving as application endpoints to send and receive session related opaque data. An application originating a request or answer message MAY include the Session-Info AVP in the message. The receiver of the message that includes a Session-Info AVP inserted by the remote peer MUST include the same Session-Info AVP in the subsequent request or answer messages. Diameter endpoints MAY update the opaque data carried in Session-info AVP. Diameter endpoints MUST use the last received Session-Info AVP in the subsequent request and answers they generate. Session-Info ::= < AVP Header: XYZ > { Origin-Host } { Session-Data } Origin-Host AVP The Origin-Host AVP contains the identity of the host that added the Session-Info AVP. Session-Data AVP The Session-Data AVP (AVP code xyz) is of type OctetString and contains opaque session related data. The maximum length of Session-Data AVP is 4096 octets. An endpoint receiving a Session-Data AVP more than 4096 octets in size MUST terminate the session. Addition to 10.1 Command Code Attribute Name CER CEA DPR DPA DWR DWA RAR RAA ASR ASA STR STA Session-Info 0 0 0 0 0 0 0+ 0+ 0+ 0+ 0+ 0+ Addition to 10.2 Command Code Attribute Name ACR ACA Session-Info 0+ 0+ ================================================= 8.23 Application-Failover-Info AVP is used by applications that can support failover at the application level. It can be used by any applications for communicating information regarding backup or alternate nodes which can takeover traffic for an ongoing session in case of failover. This allows a sessions to retransmit messages to the alternate node if present. Note that the application level failover is independent of the base protocol failover but both can be used concurrently. AVP Flag Rules AVP Data SHLD MUST MAY Attribute Name Code Type MUST MAY NOT NOT Encr Application-Failover-Info XYZ Grouped M P V Y Application-Failover-Host XYZ DiamIdent M P V Y Application-Failover-Priority XYZ Unsigned32 M P V Y Application-Failover-Info AVP The Application-Failover-Info AVP (AVP code xyz) is of type Grouped and is used by a Diameter endpoint to communicate information about its backup peers, which can takeover traffic for ongoing sessions, in case this Diameter endpoint fails. There may be multiple Application-Failover-Info AVPs present in a message. Application-Failover-Info ::= < AVP Header: XYZ > { Application-Failover-Host } { Application-Failvoer-Priority } Application-Failover-Host The Application-Failover-Host AVP (AVP code xyz) is of type DiameterIdentity and contains the identity of a backup host, which is able to takeover traffic for ongoing sessions active on the host, which originated the message containing this AVP. Application-Failover-Priority The Application-Failover-Priority AVP (AVP code xyz) is of type Unsigned32. It contains the priority associated with a backup host. When messages need to be retransmitted on application level for an ongoing session, the backup host with the highest Application-Failover-Priority value SHOULD be tried first. A bigger Application-Failover-Priority AVP value indicates that the corresponding backup server is preferred. It is up to the implementations to choose between two backup hosts with the same Application-Failover-Priority value. Addition to 10.1 Command Code Attribute Name CER CEA DPR DPA DWR DWA RAR RAA ASR ASA STR STA Application-Failover-Info 0 0 0 0 0 0 0+ 0+ 0 0 0 0 Addition to 10.2 Command Code Attribute Name ACR ACA Application-Failover-Info 0+ 0+ _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 21 13:46:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmadq-0001I3-BP; Tue, 21 Nov 2006 13:46:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmadp-0001Hl-3v for dime@ietf.org; Tue, 21 Nov 2006 13:46:45 -0500 Received: from maile.telecomitalia.it ([156.54.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmadh-0006LS-Fz for dime@ietf.org; Tue, 21 Nov 2006 13:46:45 -0500 Received: from ptpxch009ba020.idc.cww.telecomitalia.it ([156.54.240.52]) by maile.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 19:46:33 +0100 Received: from PTPEVS108BA020.idc.cww.telecomitalia.it ([156.54.241.227]) by ptpxch009ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 19:46:33 +0100 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: R: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split Importance: normal Priority: normal Date: Tue, 21 Nov 2006 19:46:32 +0100 Message-ID: In-Reply-To: <4555188F.9080604@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split thread-index: AccFJ/3khBCMuUheQcml/bxwOVq+1wIbR4qA From: "La Monaca Michele" To: "Hannes Tschofenig" , X-OriginalArrivalTime: 21 Nov 2006 18:46:33.0098 (UTC) FILETIME=[5D607EA0:01C70D9D] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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, I think it doesn't make much sense to separate authentication and authorization and, at the same time, to mandate that the two AAA servers are the same server. I think that the main advantage of this kind of solution is that you can leverage a common infrastructure for authentication while deploying ad-hoc solutions for authorization. Worse, in a roaming scenario, NASes and local HAs might not know the exact Diameter Identity of the home AAA. Therefore AAA routing would be based only on the Destination-Realm-AVP and the Application ID (i.e. EAP). Does this imply that the MIPv6 AAAH must be also in charge to handle AAA EAP requests for the access? What if another service want to use the same mechanism (EAP for authentication and a dedicated Diameter app for authorization)? Are you thinking at some sort of AAA source routing based on the type of node sending the message?=20 Last, but not least, I still miss a real understanding of the threats you considered to motivate the "servers merge". In http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt I read "AAA-MIP6 has no proof that MN has been correctly authenticated (by AAA-EAP)". Why not? AAA-MIP6 trusts its HAs and HAs guarantee for MNs. Concerns for roaming scenarios? Btw, the simple statement that "the same device handles EAP and MIPv6" doesn't add any security if you don't specify how the Diameter EAP and MIPv6 servers interact. Actually, putting two different functionalities on the same device seems to me a weakness rather than a point of strength: one machine violated -> both functionalities compromised. My 5 cent. Regards, --Michele > -----Messaggio originale----- > Da: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Inviato: sabato 11 novembre 2006 1.26 > A: dime@ietf.org > Oggetto: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split >=20 > Hi all, >=20 > during the DIME meeting Glen raised an important question that impacts > the design of the protocol, namely: > " > Do we need to support the scenario where the Diameter EAP authentication > and the Diameter MIPv6 authorization exchange terminate at different > servers? > " >=20 > Currently, we assume that these two exchanges could be terminated at > different servers. As a consequence, security concerns were raised (see > slide 5 > of http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt). >=20 > How do people think about restricting the Diameter MIPv6 HA-to-AAAH > document to terminate the authentication and authorization exchange at > the same server? >=20 > Ciao > Hannes >=20 > PS: Glen also suggested to consider using the Diameter MIPv6 App-ID for > the Diameter EAP exchange if we decide that both exchanges terminate at > the same server. As a consequence the open issue described at slide 6 of > http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt would also be > resolved. The changes to the existing document would be minimal (about 2 > additional sentences). >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons = above and may contain confidential information. If you have received the = message in error, be informed that any use of the content hereof is = prohibited. Please return it immediately to the sender and delete the = message. Should you have any questions, please contact us by replying to = webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 22 06:09:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmpyN-0008AL-Lc; Wed, 22 Nov 2006 06:08:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmpyM-00088v-O7 for dime@ietf.org; Wed, 22 Nov 2006 06:08:58 -0500 Received: from mail12.opentransfer.com ([69.6.255.182]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GmpyL-00069F-81 for dime@ietf.org; Wed, 22 Nov 2006 06:08:58 -0500 Received: (qmail 2447 invoked by uid 399); 22 Nov 2006 10:27:27 -0000 Received: from unknown (HELO KRISHNA) (61.95.206.132) by mail12.opentransfer.com with SMTP; 22 Nov 2006 10:27:27 -0000 From: To: "'Tolga Asveren'" , Subject: RE: [Dime] Redundancy support AVPs Date: Wed, 22 Nov 2006 15:57:26 +0530 Message-ID: <000201c70e20$cfe6cbe0$0801a8c0@KRISHNA> 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 Importance: Normal In-reply-to: X-Spam-Score: 1.2 (+) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba 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 me, the AVPs you suggested are very much required and needs to be added in bis, but it will be useful if you clarify the following two small points. 1) Is there any specific reason for length constraint(4096) on Session-Data AVP? 2) Does it more helpful if we add some text saying that these AVPs MAY included in any 'service specific requests/responses' (not just in RAR,ASR,STR ..etc). Thanks Prasad. -----Original Message----- From: Tolga Asveren [mailto:asveren@ulticom.com] Sent: Tuesday, November 21, 2006 8:32 PM To: dime@ietf.org Subject: [Dime] Redundancy support AVPs Hi All, During the interoperability testing there were some ideas about having more support in Diameter to facilitate redundant implementations. I guess also during some threads in DIME WG similar opinions were expressed. During the last IETF DIME WG meeting, I had the chance to briefly mention about this issue as well and said that I will provide some text for review/to get opinions. The initial version of the text is below. I also entered it to the issue tracker (#25). Does this look good to others? Shall/can we include this in the bis? Thanks, Tolga ======================================================================== ==== = Some generic support to preserve opaque session data in messages and to communicate server support for session level failover could be very useful to facilitate development of redundant systems. The following changes are proposed: ================================================================ 8.22 Session-Info AVP is used by application sessions to store session related opaque data in the messages. This AVP carries state information that are communicated between Diameter application end-points only. It provides applications with a generic method to store opaque data in messages for high availability, redundancy or other purposes that may not be defined in the Diameter application itself. AVP Flag Rules AVP Data SHLD MUST MAY Attribute Name Code Type MUST MAY NOT NOT Encr Session-Info XYZ Grouped M P V Y Origin-Host 264 DiamIdent M P V Y Session-Data XYZ OctetString M P V Y Session-Info AVP The Session-Info AVP (AVP code xyz) is of type Grouped and is used by Diameter entities serving as application endpoints to send and receive session related opaque data. An application originating a request or answer message MAY include the Session-Info AVP in the message. The receiver of the message that includes a Session-Info AVP inserted by the remote peer MUST include the same Session-Info AVP in the subsequent request or answer messages. Diameter endpoints MAY update the opaque data carried in Session-info AVP. Diameter endpoints MUST use the last received Session-Info AVP in the subsequent request and answers they generate. Session-Info ::= < AVP Header: XYZ > { Origin-Host } { Session-Data } Origin-Host AVP The Origin-Host AVP contains the identity of the host that added the Session-Info AVP. Session-Data AVP The Session-Data AVP (AVP code xyz) is of type OctetString and contains opaque session related data. The maximum length of Session-Data AVP is 4096 octets. An endpoint receiving a Session-Data AVP more than 4096 octets in size MUST terminate the session. Addition to 10.1 Command Code Attribute Name CER CEA DPR DPA DWR DWA RAR RAA ASR ASA STR STA Session-Info 0 0 0 0 0 0 0+ 0+ 0+ 0+ 0+ 0+ Addition to 10.2 Command Code Attribute Name ACR ACA Session-Info 0+ 0+ ================================================= 8.23 Application-Failover-Info AVP is used by applications that can support failover at the application level. It can be used by any applications for communicating information regarding backup or alternate nodes which can takeover traffic for an ongoing session in case of failover. This allows a sessions to retransmit messages to the alternate node if present. Note that the application level failover is independent of the base protocol failover but both can be used concurrently. AVP Flag Rules AVP Data SHLD MUST MAY Attribute Name Code Type MUST MAY NOT NOT Encr Application-Failover-Info XYZ Grouped M P V Y Application-Failover-Host XYZ DiamIdent M P V Y Application-Failover-Priority XYZ Unsigned32 M P V Y Application-Failover-Info AVP The Application-Failover-Info AVP (AVP code xyz) is of type Grouped and is used by a Diameter endpoint to communicate information about its backup peers, which can takeover traffic for ongoing sessions, in case this Diameter endpoint fails. There may be multiple Application-Failover-Info AVPs present in a message. Application-Failover-Info ::= < AVP Header: XYZ > { Application-Failover-Host } { Application-Failvoer-Priority } Application-Failover-Host The Application-Failover-Host AVP (AVP code xyz) is of type DiameterIdentity and contains the identity of a backup host, which is able to takeover traffic for ongoing sessions active on the host, which originated the message containing this AVP. Application-Failover-Priority The Application-Failover-Priority AVP (AVP code xyz) is of type Unsigned32. It contains the priority associated with a backup host. When messages need to be retransmitted on application level for an ongoing session, the backup host with the highest Application-Failover-Priority value SHOULD be tried first. A bigger Application-Failover-Priority AVP value indicates that the corresponding backup server is preferred. It is up to the implementations to choose between two backup hosts with the same Application-Failover-Priority value. Addition to 10.1 Command Code Attribute Name CER CEA DPR DPA DWR DWA RAR RAA ASR ASA STR STA Application-Failover-Info 0 0 0 0 0 0 0+ 0+ 0 0 0 0 Addition to 10.2 Command Code Attribute Name ACR ACA Application-Failover-Info 0+ 0+ _______________________________________________ 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.409 / Virus Database: 268.14.8/539 - Release Date: 11/19/2006 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 22 08:45:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmsPk-0003l3-Ru; Wed, 22 Nov 2006 08:45:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmjdb-0001Zv-CT for dime@ietf.org; Tue, 21 Nov 2006 23:23:07 -0500 Received: from jaguar.hughesbpo.net ([61.246.186.17]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GmjdX-0005KK-Nk for dime@ietf.org; Tue, 21 Nov 2006 23:23:07 -0500 Received: from jaguar.hughesbpo.net (localhost.localdomain [127.0.0.1]) by jaguar.hughesbpo.net (8.13.8/8.13.8) with ESMTP id kAM4PprT022869 for ; Wed, 22 Nov 2006 09:55:51 +0530 Received: from sandesh.hss.hns.com (sandesh [10.203.142.21]) by jaguar.hughesbpo.net (8.13.8/8.13.8) with ESMTP id kAM4PnRc022788; Wed, 22 Nov 2006 09:55:50 +0530 In-Reply-To: To: "Tolga Asveren" Subject: Re: [Dime] Redundancy support AVPs MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Preeti Shandilya Date: Wed, 22 Nov 2006 09:56:39 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 22/11/2006 09:52:58 AM, Serialize complete at 22/11/2006 09:52:58 AM X-Spam-Score: 0.2 (/) X-Scan-Signature: 57b3d456dc4730784e7070d5c6b7d14f X-Mailman-Approved-At: Wed, 22 Nov 2006 08:45:23 -0500 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="===============1610512565==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============1610512565== Content-Type: multipart/related; boundary="=_related 001807506525722E_=" This is a multipart message in MIME format. --=_related 001807506525722E_= Content-Type: multipart/alternative; boundary="=_alternative 001807516525722E_=" --=_alternative 001807516525722E_= Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: base64 SGkgVG9sZ2EgIQ0KDQpJIGhhdmUgZmV3IHN1Z2dlc3Rpb24gaW4gdGhpcyByZWdhcmQuDQoNCjEu IFNlbmQgIEFwcGxpY2F0aW9uIGZhaWxvdmVyIEFWUCBpbiBDRVIvQ0VBIG9ubHkuIEluZm9ybSBw ZWVyIG5vZGUgYWJvdXQgDQp0aGUgcmVkdW5kYW50IG5vZGUgZHVyaW5nIGNhcGFiaWxpdHkgZXhj aGFuZ2UNCjIuIEVuaGFuY2UgIEFwcGxpY2F0aW9uIGZhaWxvdmVyIEFWUCB0byBpbmNsdWRlIEF1 dGgtQXBwbGljYXRpb24tSWQgQVZQIA0KYW5kIEFjY3QtQXBwbGljYXRpb24tSWQgQVZQIGFzIHdl bGwgdG8gaW5kaWNhdGUgZm9yIHdoYXQga2luZCBvZiANCmFwcGxpY2F0aW9uIHJlZHVuZGFuY3kg c3VwcG9ydCBpcyBhdmFpbGFibGUuDQoNCkluIHRoaXMgbWV0aG9kLCBub2RlIHdpbGwgaGF2ZSB0 byBwcm9jZXNzIHRoaXMgQVZQIG9ubHkgZHVyaW5nIGNhcGFiaWxpdHkgDQpleGNoYW5nZSBhbmQg bm9kZXMgd2lsbCB1cGRhdGUgaXRzJyBkYXRhYmFzZSBmb3IgcmVkdW5kYW50IG5vZGVzLg0KSSBo YXZlIGNhcHR1cmVkIHRoaXMgaW4gZm9sbG93aW5nIGZpZ3VyZQ0KDQoNCg0KDQoNCg0KDQoNCk5v ZGUxIHNoYWxsIHNlbmQgQXBwbGljYXRpb24tRmFpbG92ZXItUHJpb3JpdHkgYXMgMShoaWdoKSBh bmQgTm9kZTIgc2hhbGwgDQpzZW5kIEFwcGxpY2F0aW9uLUZhaWxvdmVyLVByaW9yaXR5IGFzIDIo bG93KS4gUGVlciBub2RlIHdpbGwgYWx3YXlzIHNlbmQgDQptZXNzYWdlcyB0byBOb2RlMSBvbmx5 IGFzIGl0IGlzIG9uIGhpZ2ggcHJpb3JpdHkuIEluY2FzZSBvZiBOb2RlMSBmYWlscywgDQpwZWVy IG5vZGUgc2hhbGwgc3RhcnQgc2VuZGluZyBkYXRhIHRvIE5vZGUyLg0KDQpMZXQgbWUga25vdyBp ZiB0aGlzIGFwcHJvYWNoIGhhcyBhbnkgcHJvYmxlbS4NCg0KUmVnYXJkcw0KUHJlZXRpDQoNCg0K DQoNCg0KIlRvbGdhIEFzdmVyZW4iIDxhc3ZlcmVuQHVsdGljb20uY29tPiANCjExLzIxLzIwMDYg MDg6MzIgUE0NCg0KDQpUbw0KPGRpbWVAaWV0Zi5vcmc+DQpjYw0KDQpTdWJqZWN0DQpbRGltZV0g UmVkdW5kYW5jeSBzdXBwb3J0IEFWUHMNCg0KDQoNCg0KDQoNCkhpIEFsbCwNCg0KRHVyaW5nIHRo ZSBpbnRlcm9wZXJhYmlsaXR5IHRlc3RpbmcgdGhlcmUgd2VyZSBzb21lIGlkZWFzIGFib3V0IGhh dmluZyANCm1vcmUNCnN1cHBvcnQgaW4gRGlhbWV0ZXIgdG8gZmFjaWxpdGF0ZSByZWR1bmRhbnQg aW1wbGVtZW50YXRpb25zLiBJIGd1ZXNzIGFsc28NCmR1cmluZyBzb21lIHRocmVhZHMgaW4gRElN RSBXRyBzaW1pbGFyIG9waW5pb25zIHdlcmUgZXhwcmVzc2VkLiBEdXJpbmcgdGhlDQpsYXN0IElF VEYgRElNRSBXRyBtZWV0aW5nLCBJIGhhZCB0aGUgY2hhbmNlIHRvIGJyaWVmbHkgbWVudGlvbiBh Ym91dCB0aGlzDQppc3N1ZSBhcyB3ZWxsIGFuZCBzYWlkIHRoYXQgSSB3aWxsIHByb3ZpZGUgc29t ZSB0ZXh0IGZvciByZXZpZXcvdG8gZ2V0DQpvcGluaW9ucy4NCg0KVGhlIGluaXRpYWwgdmVyc2lv biBvZiB0aGUgdGV4dCBpcyBiZWxvdy4gSSBhbHNvIGVudGVyZWQgaXQgdG8gdGhlIGlzc3VlDQp0 cmFja2VyICgjMjUpLiBEb2VzIHRoaXMgbG9vayBnb29kIHRvIG90aGVycz8gU2hhbGwvY2FuIHdl IGluY2x1ZGUgdGhpcyBpbg0KdGhlIGJpcz8NCg0KICAgVGhhbmtzLA0KICAgVG9sZ2ENCg0KDQoN Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0NCj0NClNvbWUgZ2VuZXJpYyBzdXBwb3J0IHRvIHByZXNlcnZl IG9wYXF1ZSBzZXNzaW9uIGRhdGEgaW4gbWVzc2FnZXMgYW5kIHRvDQpjb21tdW5pY2F0ZSBzZXJ2 ZXIgc3VwcG9ydCBmb3Igc2Vzc2lvbiBsZXZlbCBmYWlsb3ZlciBjb3VsZCBiZSB2ZXJ5IHVzZWZ1 bA0KdG8gZmFjaWxpdGF0ZSBkZXZlbG9wbWVudCBvZiByZWR1bmRhbnQgc3lzdGVtcy4NCg0KDQoN Cg0KDQoNClRoZSBmb2xsb3dpbmcgY2hhbmdlcyBhcmUgcHJvcG9zZWQ6DQoNCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCjgu MjINClNlc3Npb24tSW5mbyBBVlAgaXMgdXNlZCBieSBhcHBsaWNhdGlvbiBzZXNzaW9ucyB0byBz dG9yZSBzZXNzaW9uIHJlbGF0ZWQNCm9wYXF1ZSBkYXRhIGluIHRoZSBtZXNzYWdlcy4gVGhpcyBB VlAgY2FycmllcyBzdGF0ZSBpbmZvcm1hdGlvbiB0aGF0IGFyZQ0KY29tbXVuaWNhdGVkIGJldHdl ZW4gRGlhbWV0ZXIgYXBwbGljYXRpb24gZW5kLXBvaW50cyBvbmx5LiBJdCBwcm92aWRlcw0KYXBw bGljYXRpb25zIHdpdGggYSBnZW5lcmljIG1ldGhvZCB0byBzdG9yZSBvcGFxdWUgZGF0YSBpbiBt ZXNzYWdlcyBmb3IgDQpoaWdoDQphdmFpbGFiaWxpdHksIHJlZHVuZGFuY3kgb3Igb3RoZXIgcHVy cG9zZXMgdGhhdCBtYXkgbm90IGJlIGRlZmluZWQgaW4gdGhlDQpEaWFtZXRlciBhcHBsaWNhdGlv biBpdHNlbGYuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg QVZQIEZsYWcgUnVsZXMNCiAgICAgICAgICAgICAgICAgIEFWUCAgIERhdGEgICAgICAgICAgICAg ICAgICAgICBTSExEICBNVVNUICBNQVkNCkF0dHJpYnV0ZSBOYW1lICAgIENvZGUgIFR5cGUgICAg ICAgICBNVVNUICBNQVkgICBOT1QgICBOT1QgIEVuY3INClNlc3Npb24tSW5mbyAgICAgICBYWVog IEdyb3VwZWQgICAgICAgIE0gICAgUCAgICAgICAgICAgViAgICAgWQ0KT3JpZ2luLUhvc3QgICAg ICAgIDI2NCAgRGlhbUlkZW50ICAgICAgTSAgICBQICAgICAgICAgICBWICAgICBZDQpTZXNzaW9u LURhdGEgICAgICAgWFlaICBPY3RldFN0cmluZyAgICBNICAgIFAgICAgICAgICAgIFYgICAgIFkN Cg0KU2Vzc2lvbi1JbmZvIEFWUA0KVGhlIFNlc3Npb24tSW5mbyBBVlAgKEFWUCBjb2RlIHh5eikg aXMgb2YgdHlwZSBHcm91cGVkIGFuZCBpcyB1c2VkIGJ5DQpEaWFtZXRlciBlbnRpdGllcyBzZXJ2 aW5nIGFzIGFwcGxpY2F0aW9uIGVuZHBvaW50cyB0byBzZW5kIGFuZCByZWNlaXZlDQpzZXNzaW9u IHJlbGF0ZWQgb3BhcXVlIGRhdGEuIEFuIGFwcGxpY2F0aW9uIG9yaWdpbmF0aW5nIGEgcmVxdWVz dCBvciANCmFuc3dlcg0KbWVzc2FnZSBNQVkgaW5jbHVkZSB0aGUgU2Vzc2lvbi1JbmZvIEFWUCBp biB0aGUgbWVzc2FnZS4gVGhlIHJlY2VpdmVyIG9mIA0KdGhlDQptZXNzYWdlIHRoYXQgaW5jbHVk ZXMgYSBTZXNzaW9uLUluZm8gQVZQIGluc2VydGVkIGJ5IHRoZSByZW1vdGUgcGVlciBNVVNUDQpp bmNsdWRlIHRoZSBzYW1lIFNlc3Npb24tSW5mbyBBVlAgaW4gdGhlIHN1YnNlcXVlbnQgcmVxdWVz dCBvciBhbnN3ZXINCm1lc3NhZ2VzLiBEaWFtZXRlciBlbmRwb2ludHMgTUFZIHVwZGF0ZSB0aGUg b3BhcXVlIGRhdGEgY2FycmllZCBpbg0KU2Vzc2lvbi1pbmZvIEFWUC4gRGlhbWV0ZXIgZW5kcG9p bnRzIE1VU1QgdXNlIHRoZSBsYXN0IHJlY2VpdmVkIA0KU2Vzc2lvbi1JbmZvDQpBVlAgaW4gdGhl IHN1YnNlcXVlbnQgcmVxdWVzdCBhbmQgYW5zd2VycyB0aGV5IGdlbmVyYXRlLg0KDQogICAgIFNl c3Npb24tSW5mbyA6Oj0gPCBBVlAgSGVhZGVyOiBYWVogPg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHsgT3JpZ2luLUhvc3QgfQ0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHsgU2Vzc2lvbi1EYXRhIH0NCg0K T3JpZ2luLUhvc3QgQVZQDQpUaGUgT3JpZ2luLUhvc3QgQVZQIGNvbnRhaW5zIHRoZSBpZGVudGl0 eSBvZiB0aGUgaG9zdCB0aGF0IGFkZGVkIHRoZQ0KU2Vzc2lvbi1JbmZvIEFWUC4NCg0KU2Vzc2lv bi1EYXRhIEFWUA0KVGhlIFNlc3Npb24tRGF0YSBBVlAgKEFWUCBjb2RlIHh5eikgaXMgb2YgdHlw ZSBPY3RldFN0cmluZyBhbmQgY29udGFpbnMNCm9wYXF1ZSBzZXNzaW9uIHJlbGF0ZWQgZGF0YS4g VGhlIG1heGltdW0gbGVuZ3RoIG9mIFNlc3Npb24tRGF0YSBBVlAgaXMgDQo0MDk2DQpvY3RldHMu IEFuIGVuZHBvaW50IHJlY2VpdmluZyBhIFNlc3Npb24tRGF0YSBBVlAgbW9yZSB0aGFuIDQwOTYg b2N0ZXRzIGluDQpzaXplIE1VU1QgdGVybWluYXRlIHRoZSBzZXNzaW9uLg0KDQoNCkFkZGl0aW9u IHRvIDEwLjENCiAgICAgICAgICAgICAgICAgICAgICAgICAgQ29tbWFuZCBDb2RlDQpBdHRyaWJ1 dGUgTmFtZSAgIENFUiBDRUEgRFBSIERQQSBEV1IgRFdBIFJBUiBSQUEgQVNSIEFTQSBTVFIgU1RB DQpTZXNzaW9uLUluZm8gICAgICAwICAgMCAgIDAgICAwICAgMCAgIDAgICAwKyAgMCsgIDArICAw KyAgMCsgIDArDQoNCkFkZGl0aW9uIHRvIDEwLjINCiAgICAgICAgICAgICAgICAgICAgICAgICAg IENvbW1hbmQgQ29kZQ0KQXR0cmlidXRlIE5hbWUgICAgQUNSIEFDQQ0KU2Vzc2lvbi1JbmZvICAg ICAgIDArICAwKw0KDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0NCjguMjMNCkFwcGxpY2F0aW9uLUZhaWxvdmVyLUluZm8gQVZQIGlzIHVzZWQgYnkg YXBwbGljYXRpb25zIHRoYXQgY2FuIHN1cHBvcnQNCmZhaWxvdmVyIGF0IHRoZSBhcHBsaWNhdGlv biBsZXZlbC4gSXQgY2FuIGJlIHVzZWQgYnkgYW55IGFwcGxpY2F0aW9ucyBmb3INCmNvbW11bmlj YXRpbmcgaW5mb3JtYXRpb24gcmVnYXJkaW5nIGJhY2t1cCBvciBhbHRlcm5hdGUgbm9kZXMgd2hp Y2ggY2FuDQp0YWtlb3ZlciB0cmFmZmljIGZvciBhbiBvbmdvaW5nIHNlc3Npb24gaW4gY2FzZSBv ZiBmYWlsb3Zlci4gVGhpcyBhbGxvd3MgYQ0Kc2Vzc2lvbnMgdG8gcmV0cmFuc21pdCBtZXNzYWdl cyB0byB0aGUgYWx0ZXJuYXRlIG5vZGUgaWYgcHJlc2VudC4gTm90ZSANCnRoYXQNCnRoZSBhcHBs aWNhdGlvbiBsZXZlbCBmYWlsb3ZlciBpcyBpbmRlcGVuZGVudCBvZiB0aGUgYmFzZSBwcm90b2Nv bCANCmZhaWxvdmVyDQpidXQgYm90aCBjYW4gYmUgdXNlZCBjb25jdXJyZW50bHkuDQoNCg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFW UCBGbGFnIFJ1bGVzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFWUCAgIERhdGEg ICAgICAgICAgICAgICAgICAgICBTSExEICBNVVNUDQpNQVkNCkF0dHJpYnV0ZSBOYW1lICAgICAg ICAgICAgICAgICAgQ29kZSAgVHlwZSAgICAgICAgIE1VU1QgIE1BWSAgIE5PVCAgIE5PVA0KRW5j cg0KQXBwbGljYXRpb24tRmFpbG92ZXItSW5mbyAgICAgICBYWVogIEdyb3VwZWQgICAgICAgIE0g ICAgUCAgICAgICAgICAgViBZDQpBcHBsaWNhdGlvbi1GYWlsb3Zlci1Ib3N0ICAgICAgIFhZWiAg RGlhbUlkZW50ICAgICAgTSAgICBQICAgICAgICAgICBWIFkNCkFwcGxpY2F0aW9uLUZhaWxvdmVy LVByaW9yaXR5ICAgWFlaICBVbnNpZ25lZDMyICAgICBNICAgIFAgICAgICAgICAgIFYgWQ0KDQoN CkFwcGxpY2F0aW9uLUZhaWxvdmVyLUluZm8gQVZQDQpUaGUgQXBwbGljYXRpb24tRmFpbG92ZXIt SW5mbyBBVlAgKEFWUCBjb2RlIHh5eikgaXMgb2YgdHlwZSBHcm91cGVkIGFuZCBpcw0KdXNlZCBi eSBhIERpYW1ldGVyIGVuZHBvaW50IHRvIGNvbW11bmljYXRlIGluZm9ybWF0aW9uIGFib3V0IGl0 cyBiYWNrdXANCnBlZXJzLCB3aGljaCBjYW4gdGFrZW92ZXIgdHJhZmZpYyBmb3Igb25nb2luZyBz ZXNzaW9ucywgaW4gY2FzZSB0aGlzDQpEaWFtZXRlciBlbmRwb2ludCBmYWlscy4gVGhlcmUgbWF5 IGJlIG11bHRpcGxlIEFwcGxpY2F0aW9uLUZhaWxvdmVyLUluZm8NCkFWUHMgcHJlc2VudCBpbiBh IG1lc3NhZ2UuDQoNCiAgICAgQXBwbGljYXRpb24tRmFpbG92ZXItSW5mbyA6Oj0gPCBBVlAgSGVh ZGVyOiBYWVogPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB7IA0KQXBwbGljYXRpb24tRmFpbG92ZXItSG9zdCB9DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHsgDQpBcHBsaWNhdGlvbi1GYWlsdm9lci1Qcmlvcml0eSB9DQoNCkFwcGxpY2F0 aW9uLUZhaWxvdmVyLUhvc3QNClRoZSBBcHBsaWNhdGlvbi1GYWlsb3Zlci1Ib3N0IEFWUCAoQVZQ IGNvZGUgeHl6KSBpcyBvZiB0eXBlIA0KRGlhbWV0ZXJJZGVudGl0eQ0KYW5kIGNvbnRhaW5zIHRo ZSBpZGVudGl0eSBvZiBhIGJhY2t1cCBob3N0LCB3aGljaCBpcyBhYmxlIHRvIHRha2VvdmVyDQp0 cmFmZmljIGZvciBvbmdvaW5nIHNlc3Npb25zIGFjdGl2ZSBvbiB0aGUgaG9zdCwgd2hpY2ggb3Jp Z2luYXRlZCB0aGUNCm1lc3NhZ2UgY29udGFpbmluZyB0aGlzIEFWUC4NCg0KQXBwbGljYXRpb24t RmFpbG92ZXItUHJpb3JpdHkNClRoZSBBcHBsaWNhdGlvbi1GYWlsb3Zlci1Qcmlvcml0eSBBVlAg KEFWUCBjb2RlIHh5eikgaXMgb2YgdHlwZSANClVuc2lnbmVkMzIuDQpJdCBjb250YWlucyB0aGUg cHJpb3JpdHkgYXNzb2NpYXRlZCB3aXRoIGEgYmFja3VwIGhvc3QuIFdoZW4gbWVzc2FnZXMgbmVl ZA0KdG8gYmUgcmV0cmFuc21pdHRlZCBvbiBhcHBsaWNhdGlvbiBsZXZlbCBmb3IgYW4gb25nb2lu ZyBzZXNzaW9uLCB0aGUgDQpiYWNrdXANCmhvc3Qgd2l0aCB0aGUgaGlnaGVzdCBBcHBsaWNhdGlv bi1GYWlsb3Zlci1Qcmlvcml0eSB2YWx1ZSBTSE9VTEQgYmUgdHJpZWQNCmZpcnN0LiBBIGJpZ2dl ciBBcHBsaWNhdGlvbi1GYWlsb3Zlci1Qcmlvcml0eSBBVlAgdmFsdWUgaW5kaWNhdGVzIHRoYXQg dGhlDQpjb3JyZXNwb25kaW5nIGJhY2t1cCBzZXJ2ZXIgaXMgcHJlZmVycmVkLiBJdCBpcyB1cCB0 byB0aGUgaW1wbGVtZW50YXRpb25zIA0KdG8NCmNob29zZSBiZXR3ZWVuIHR3byBiYWNrdXAgaG9z dHMgd2l0aCB0aGUgc2FtZSANCkFwcGxpY2F0aW9uLUZhaWxvdmVyLVByaW9yaXR5DQp2YWx1ZS4N Cg0KQWRkaXRpb24gdG8gMTAuMQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBDb21tYW5kIENvZGUNCkF0dHJpYnV0ZSBOYW1lICAgICAgICAgICAgICAgICBD RVIgQ0VBIERQUiBEUEEgRFdSIERXQSBSQVIgUkFBIEFTUiBBU0EgU1RSDQpTVEENCkFwcGxpY2F0 aW9uLUZhaWxvdmVyLUluZm8gICAgICAwICAgMCAgIDAgICAwICAgMCAgIDAgICAwKyAgMCsgICAw ICAgMCAgIDANCjANCg0KDQpBZGRpdGlvbiB0byAxMC4yDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgQ29tbWFuZCBDb2RlDQpBdHRyaWJ1dGUgTmFtZSAgICAgICAgICAgICAgICAgIEFD UiBBQ0ENCkFwcGxpY2F0aW9uLUZhaWxvdmVyLUluZm8gICAgICAgMCsgIDArDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkRpTUUgbWFpbGluZyBs aXN0DQpEaU1FQGlldGYub3JnDQpodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9kaW1lDQoNCg0KDQoqKioqKioqKioqKioqKioqKioqKioqKiAgQXJpY2VudC1VbmNsYXNzaWZp ZWQgICAqKioqKioqKioqKioqKioqKioqKioqKg0KIkRJU0NMQUlNRVI6IFRoaXMgbWVzc2FnZSBp cyBwcm9wcmlldGFyeSB0byBBcmljZW50ICBhbmQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUg dXNlIG9mIAp0aGUgaW5kaXZpZHVhbCB0byB3aG9tIGl0IGlzIGFkZHJlc3NlZC4gSXQgbWF5IGNv bnRhaW4gcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gYW5kIHNob3VsZCBu b3QgYmUgCmNpcmN1bGF0ZWQgb3IgdXNlZCBmb3IgYW55IHB1cnBvc2Ugb3RoZXIgdGhhbiBmb3Ig d2hhdCBpdCBpcyBpbnRlbmRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGlu IGVycm9yLCAKcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBpbW1lZGlhdGVseS4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBub3RpZmllZCB0aGF0IHlv dSBhcmUgc3RyaWN0bHkKcHJvaGliaXRlZCBmcm9tIHVzaW5nLCBjb3B5aW5nLCBhbHRlcmluZywg b3IgZGlzY2xvc2luZyB0aGUgY29udGVudHMgb2YgdGhpcyBtZXNzYWdlLiBBcmljZW50IGFjY2Vw dHMgbm8gcmVzcG9uc2liaWxpdHkgZm9yIApsb3NzIG9yIGRhbWFnZSBhcmlzaW5nIGZyb20gdGhl IHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gdHJhbnNtaXR0ZWQgYnkgdGhpcyBlbWFpbCBpbmNsdWRp bmcgZGFtYWdlIGZyb20gdmlydXMuIgo= --=_alternative 001807516525722E_= Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFRvbGdhICE8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgaGF2ZSBmZXcgc3VnZ2Vz dGlvbiBpbiB0aGlzIHJlZ2FyZC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPjEuIFNlbmQgJm5ic3A7QXBwbGljYXRpb24gZmFpbG92ZXIgQVZQDQppbiBD RVIvQ0VBIG9ubHkuIEluZm9ybSBwZWVyIG5vZGUgYWJvdXQgdGhlIHJlZHVuZGFudCBub2RlIGR1 cmluZyBjYXBhYmlsaXR5DQpleGNoYW5nZTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+Mi4gRW5oYW5jZSAmbmJzcDtBcHBsaWNhdGlvbiBmYWlsb3Zlcg0KQVZQIHRv IGluY2x1ZGUgPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+QXV0aC1BcHBs aWNhdGlvbi1JZA0KQVZQPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4gYW5k IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPkFjY3QtQXBwbGljYXRpb24t SWQNCkFWUDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+IGFzIHdlbGwgdG8g aW5kaWNhdGUgZm9yIHdoYXQNCmtpbmQgb2YgYXBwbGljYXRpb24gcmVkdW5kYW5jeSBzdXBwb3J0 IGlzIGF2YWlsYWJsZS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPkluIHRoaXMgbWV0aG9kLCBub2RlIHdpbGwgaGF2ZSB0byBwcm9jZXNzDQp0aGlzIEFW UCBvbmx5IGR1cmluZyBjYXBhYmlsaXR5IGV4Y2hhbmdlIGFuZCBub2RlcyB3aWxsIHVwZGF0ZSBp dHMnIGRhdGFiYXNlDQpmb3IgcmVkdW5kYW50IG5vZGVzLjwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+SSBoYXZlIGNhcHR1cmVkIHRoaXMgaW4gZm9sbG93aW5nIGZp Z3VyZTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj48aW1nIHNyYz1j aWQ6XzFfMDYwQTc2ODgwNjBBNzI3QzAwMTgwNzRFNjUyNTcyMkU+DQo8YnI+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk5vZGUxIHNoYWxsIHNlbmQgPC9mb250Pjxm b250IHNpemU9Mj48dHQ+QXBwbGljYXRpb24tRmFpbG92ZXItUHJpb3JpdHk8L3R0PjwvZm9udD48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+DQphcyAxKGhpZ2gpIGFuZCBOb2RlMiBzaGFs bCBzZW5kIDwvZm9udD48Zm9udCBzaXplPTI+PHR0PkFwcGxpY2F0aW9uLUZhaWxvdmVyLVByaW9y aXR5PC90dD48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxiPg0KPC9iPmFz IDIobG93KS4gUGVlciBub2RlIHdpbGwgYWx3YXlzIHNlbmQgbWVzc2FnZXMgdG8gTm9kZTEgb25s eSBhcyBpdA0KaXMgb24gaGlnaCBwcmlvcml0eS4gSW5jYXNlIG9mIE5vZGUxIGZhaWxzLCBwZWVy IG5vZGUgc2hhbGwgc3RhcnQgc2VuZGluZw0KZGF0YSB0byBOb2RlMi48L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkxldCBtZSBrbm93IGlmIHRoaXMgYXBw cm9hY2ggaGFzIGFueQ0KcHJvYmxlbS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPlJlZ2FyZHM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPlByZWV0aTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0 YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9NDAlPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj4mcXVvdDtUb2xnYSBBc3ZlcmVuJnF1b3Q7DQombHQ7 YXN2ZXJlbkB1bHRpY29tLmNvbSZndDs8L2I+IDwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj4xMS8yMS8yMDA2IDA4OjMyIFBNPC9mb250Pg0KPGJyPg0KPHRkIHdpZHRo PTU5JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+VG88L2ZvbnQ+PC9kaXY+DQo8dGQgdmFsaWdu PXRvcD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Jmx0O2RpbWVAaWV0Zi5vcmcmZ3Q7 PC9mb250Pg0KPHRyPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+Y2M8L2ZvbnQ+PC9kaXY+DQo8dGQgdmFsaWduPXRvcD4NCjx0cj4NCjx0ZD4N CjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlN1YmplY3Q8 L2ZvbnQ+PC9kaXY+DQo8dGQgdmFsaWduPXRvcD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+W0RpbWVdIFJlZHVuZGFuY3kgc3VwcG9ydA0KQVZQczwvZm9udD48L3RhYmxlPg0KPGJyPg0K PHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxl Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+SGkgQWxsLDxicj4NCjxicj4NCkR1 cmluZyB0aGUgaW50ZXJvcGVyYWJpbGl0eSB0ZXN0aW5nIHRoZXJlIHdlcmUgc29tZSBpZGVhcyBh Ym91dCBoYXZpbmcNCm1vcmU8YnI+DQpzdXBwb3J0IGluIERpYW1ldGVyIHRvIGZhY2lsaXRhdGUg cmVkdW5kYW50IGltcGxlbWVudGF0aW9ucy4gSSBndWVzcyBhbHNvPGJyPg0KZHVyaW5nIHNvbWUg dGhyZWFkcyBpbiBESU1FIFdHIHNpbWlsYXIgb3BpbmlvbnMgd2VyZSBleHByZXNzZWQuIER1cmlu Zw0KdGhlPGJyPg0KbGFzdCBJRVRGIERJTUUgV0cgbWVldGluZywgSSBoYWQgdGhlIGNoYW5jZSB0 byBicmllZmx5IG1lbnRpb24gYWJvdXQgdGhpczxicj4NCmlzc3VlIGFzIHdlbGwgYW5kIHNhaWQg dGhhdCBJIHdpbGwgcHJvdmlkZSBzb21lIHRleHQgZm9yIHJldmlldy90byBnZXQ8YnI+DQpvcGlu aW9ucy48YnI+DQo8YnI+DQpUaGUgaW5pdGlhbCB2ZXJzaW9uIG9mIHRoZSB0ZXh0IGlzIGJlbG93 LiBJIGFsc28gZW50ZXJlZCBpdCB0byB0aGUgaXNzdWU8YnI+DQp0cmFja2VyICgjMjUpLiBEb2Vz IHRoaXMgbG9vayBnb29kIHRvIG90aGVycz8gU2hhbGwvY2FuIHdlIGluY2x1ZGUgdGhpcw0KaW48 YnI+DQp0aGUgYmlzPzxicj4NCjxicj4NCiAmbmJzcDsgVGhhbmtzLDxicj4NCiAmbmJzcDsgVG9s Z2E8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KPTxicj4N ClNvbWUgZ2VuZXJpYyBzdXBwb3J0IHRvIHByZXNlcnZlIG9wYXF1ZSBzZXNzaW9uIGRhdGEgaW4g bWVzc2FnZXMgYW5kIHRvPGJyPg0KY29tbXVuaWNhdGUgc2VydmVyIHN1cHBvcnQgZm9yIHNlc3Np b24gbGV2ZWwgZmFpbG92ZXIgY291bGQgYmUgdmVyeSB1c2VmdWw8YnI+DQp0byBmYWNpbGl0YXRl IGRldmVsb3BtZW50IG9mIHJlZHVuZGFudCBzeXN0ZW1zLjxicj4NCjxicj4NCjxicj4NCjxicj4N Cjxicj4NCjxicj4NCjxicj4NClRoZSBmb2xsb3dpbmcgY2hhbmdlcyBhcmUgcHJvcG9zZWQ6PGJy Pg0KPGJyPg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PTxicj4NCjguMjI8YnI+DQpTZXNzaW9uLUluZm8gQVZQIGlzIHVzZWQg YnkgYXBwbGljYXRpb24gc2Vzc2lvbnMgdG8gc3RvcmUgc2Vzc2lvbiByZWxhdGVkPGJyPg0Kb3Bh cXVlIGRhdGEgaW4gdGhlIG1lc3NhZ2VzLiBUaGlzIEFWUCBjYXJyaWVzIHN0YXRlIGluZm9ybWF0 aW9uIHRoYXQgYXJlPGJyPg0KY29tbXVuaWNhdGVkIGJldHdlZW4gRGlhbWV0ZXIgYXBwbGljYXRp b24gZW5kLXBvaW50cyBvbmx5LiBJdCBwcm92aWRlczxicj4NCmFwcGxpY2F0aW9ucyB3aXRoIGEg Z2VuZXJpYyBtZXRob2QgdG8gc3RvcmUgb3BhcXVlIGRhdGEgaW4gbWVzc2FnZXMgZm9yDQpoaWdo PGJyPg0KYXZhaWxhYmlsaXR5LCByZWR1bmRhbmN5IG9yIG90aGVyIHB1cnBvc2VzIHRoYXQgbWF5 IG5vdCBiZSBkZWZpbmVkIGluIHRoZTxicj4NCkRpYW1ldGVyIGFwcGxpY2F0aW9uIGl0c2VsZi48 YnI+DQo8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDtBVlAg RmxhZyBSdWxlczxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO0FWUCAmbmJzcDsNCkRhdGEgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpTSExE ICZuYnNwO01VU1QgJm5ic3A7TUFZPGJyPg0KQXR0cmlidXRlIE5hbWUgJm5ic3A7ICZuYnNwO0Nv ZGUgJm5ic3A7VHlwZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCk1VU1QgJm5ic3A7TUFZ ICZuYnNwOyBOT1QgJm5ic3A7IE5PVCAmbmJzcDtFbmNyPGJyPg0KU2Vzc2lvbi1JbmZvICZuYnNw OyAmbmJzcDsgJm5ic3A7IFhZWiAmbmJzcDtHcm91cGVkICZuYnNwOyAmbmJzcDsgJm5ic3A7DQom bmJzcDtNICZuYnNwOyAmbmJzcDtQICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg ViAmbmJzcDsgJm5ic3A7DQpZPGJyPg0KT3JpZ2luLUhvc3QgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7MjY0ICZuYnNwO0RpYW1JZGVudCAmbmJzcDsgJm5ic3A7DQombmJzcDtNICZuYnNwOyAm bmJzcDtQICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgViAmbmJzcDsgJm5ic3A7 DQpZPGJyPg0KU2Vzc2lvbi1EYXRhICZuYnNwOyAmbmJzcDsgJm5ic3A7IFhZWiAmbmJzcDtPY3Rl dFN0cmluZyAmbmJzcDsgJm5ic3A7TQ0KJm5ic3A7ICZuYnNwO1AgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBWICZuYnNwOyAmbmJzcDsgWTxicj4NCjxicj4NClNlc3Npb24tSW5m byBBVlA8YnI+DQpUaGUgU2Vzc2lvbi1JbmZvIEFWUCAoQVZQIGNvZGUgeHl6KSBpcyBvZiB0eXBl IEdyb3VwZWQgYW5kIGlzIHVzZWQgYnk8YnI+DQpEaWFtZXRlciBlbnRpdGllcyBzZXJ2aW5nIGFz IGFwcGxpY2F0aW9uIGVuZHBvaW50cyB0byBzZW5kIGFuZCByZWNlaXZlPGJyPg0Kc2Vzc2lvbiBy ZWxhdGVkIG9wYXF1ZSBkYXRhLiBBbiBhcHBsaWNhdGlvbiBvcmlnaW5hdGluZyBhIHJlcXVlc3Qg b3IgYW5zd2VyPGJyPg0KbWVzc2FnZSBNQVkgaW5jbHVkZSB0aGUgU2Vzc2lvbi1JbmZvIEFWUCBp biB0aGUgbWVzc2FnZS4gVGhlIHJlY2VpdmVyIG9mDQp0aGU8YnI+DQptZXNzYWdlIHRoYXQgaW5j bHVkZXMgYSBTZXNzaW9uLUluZm8gQVZQIGluc2VydGVkIGJ5IHRoZSByZW1vdGUgcGVlciBNVVNU PGJyPg0KaW5jbHVkZSB0aGUgc2FtZSBTZXNzaW9uLUluZm8gQVZQIGluIHRoZSBzdWJzZXF1ZW50 IHJlcXVlc3Qgb3IgYW5zd2VyPGJyPg0KbWVzc2FnZXMuIERpYW1ldGVyIGVuZHBvaW50cyBNQVkg dXBkYXRlIHRoZSBvcGFxdWUgZGF0YSBjYXJyaWVkIGluPGJyPg0KU2Vzc2lvbi1pbmZvIEFWUC4g RGlhbWV0ZXIgZW5kcG9pbnRzIE1VU1QgdXNlIHRoZSBsYXN0IHJlY2VpdmVkIFNlc3Npb24tSW5m bzxicj4NCkFWUCBpbiB0aGUgc3Vic2VxdWVudCByZXF1ZXN0IGFuZCBhbnN3ZXJzIHRoZXkgZ2Vu ZXJhdGUuPGJyPg0KPGJyPg0KICZuYnNwOyAmbmJzcDsgU2Vzc2lvbi1JbmZvIDo6PSAmbHQ7IEFW UCBIZWFkZXI6IFhZWiAmZ3Q7PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQp7IE9yaWdpbi1Ib3N0IH08YnI+DQogJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCnsgU2Vzc2lvbi1EYXRhIH08YnI+DQo8YnI+DQpPcmlnaW4tSG9zdCBBVlA8YnI+DQpUaGUg T3JpZ2luLUhvc3QgQVZQIGNvbnRhaW5zIHRoZSBpZGVudGl0eSBvZiB0aGUgaG9zdCB0aGF0IGFk ZGVkIHRoZTxicj4NClNlc3Npb24tSW5mbyBBVlAuPGJyPg0KPGJyPg0KU2Vzc2lvbi1EYXRhIEFW UDxicj4NClRoZSBTZXNzaW9uLURhdGEgQVZQIChBVlAgY29kZSB4eXopIGlzIG9mIHR5cGUgT2N0 ZXRTdHJpbmcgYW5kIGNvbnRhaW5zPGJyPg0Kb3BhcXVlIHNlc3Npb24gcmVsYXRlZCBkYXRhLiBU aGUgbWF4aW11bSBsZW5ndGggb2YgU2Vzc2lvbi1EYXRhIEFWUCBpcw0KNDA5Njxicj4NCm9jdGV0 cy4gQW4gZW5kcG9pbnQgcmVjZWl2aW5nIGEgU2Vzc2lvbi1EYXRhIEFWUCBtb3JlIHRoYW4gNDA5 NiBvY3RldHMNCmluPGJyPg0Kc2l6ZSBNVVNUIHRlcm1pbmF0ZSB0aGUgc2Vzc2lvbi48YnI+DQo8 YnI+DQo8YnI+DQpBZGRpdGlvbiB0byAxMC4xPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZu YnNwOyAmbmJzcDtDb21tYW5kIENvZGU8YnI+DQpBdHRyaWJ1dGUgTmFtZSAmbmJzcDsgQ0VSIENF QSBEUFIgRFBBIERXUiBEV0EgUkFSIFJBQSBBU1IgQVNBIFNUUiBTVEE8YnI+DQpTZXNzaW9uLUlu Zm8gJm5ic3A7ICZuYnNwOyAmbmJzcDswICZuYnNwOyAwICZuYnNwOyAwICZuYnNwOyAwICZuYnNw OyAwDQombmJzcDsgMCAmbmJzcDsgMCsgJm5ic3A7MCsgJm5ic3A7MCsgJm5ic3A7MCsgJm5ic3A7 MCsgJm5ic3A7MCs8YnI+DQo8YnI+DQpBZGRpdGlvbiB0byAxMC4yPGJyPg0KICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Ow0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgQ29tbWFuZCBDb2RlPGJyPg0KQXR0cmlidXRlIE5hbWUg Jm5ic3A7ICZuYnNwO0FDUiBBQ0E8YnI+DQpTZXNzaW9uLUluZm8gJm5ic3A7ICZuYnNwOyAmbmJz cDsgMCsgJm5ic3A7MCs8YnI+DQo8YnI+DQo8YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KOC4yMzxicj4NCkFwcGxpY2F0aW9uLUZhaWxv dmVyLUluZm8gQVZQIGlzIHVzZWQgYnkgYXBwbGljYXRpb25zIHRoYXQgY2FuIHN1cHBvcnQ8YnI+ DQpmYWlsb3ZlciBhdCB0aGUgYXBwbGljYXRpb24gbGV2ZWwuIEl0IGNhbiBiZSB1c2VkIGJ5IGFu eSBhcHBsaWNhdGlvbnMgZm9yPGJyPg0KY29tbXVuaWNhdGluZyBpbmZvcm1hdGlvbiByZWdhcmRp bmcgYmFja3VwIG9yIGFsdGVybmF0ZSBub2RlcyB3aGljaCBjYW48YnI+DQp0YWtlb3ZlciB0cmFm ZmljIGZvciBhbiBvbmdvaW5nIHNlc3Npb24gaW4gY2FzZSBvZiBmYWlsb3Zlci4gVGhpcyBhbGxv d3MNCmE8YnI+DQpzZXNzaW9ucyB0byByZXRyYW5zbWl0IG1lc3NhZ2VzIHRvIHRoZSBhbHRlcm5h dGUgbm9kZSBpZiBwcmVzZW50LiBOb3RlDQp0aGF0PGJyPg0KdGhlIGFwcGxpY2F0aW9uIGxldmVs IGZhaWxvdmVyIGlzIGluZGVwZW5kZW50IG9mIHRoZSBiYXNlIHByb3RvY29sIGZhaWxvdmVyPGJy Pg0KYnV0IGJvdGggY2FuIGJlIHVzZWQgY29uY3VycmVudGx5Ljxicj4NCjxicj4NCjxicj4NCiAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtBVlAgRmxhZyBSdWxlczxicj4NCiAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QVZQICZu YnNwOyBEYXRhICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgU0hMRCAmbmJzcDtNVVNUPGJyPg0KTUFZPGJyPg0KQXR0 cmlidXRlIE5hbWUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KJm5ic3A7Q29kZSAmbmJzcDtUeXBlICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBNVVNUICZuYnNwO01BWSAmbmJzcDsNCk5PVCAmbmJzcDsgTk9UPGJyPg0KRW5jcjxicj4N CkFwcGxpY2F0aW9uLUZhaWxvdmVyLUluZm8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgWFlaICZuYnNw O0dyb3VwZWQgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwO00gJm5ic3A7ICZuYnNwO1AgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KViAmbmJzcDsgJm5ic3A7IFk8YnI+DQpB cHBsaWNhdGlvbi1GYWlsb3Zlci1Ib3N0ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFhZWiAmbmJzcDtE aWFtSWRlbnQgJm5ic3A7DQombmJzcDsgJm5ic3A7TSAmbmJzcDsgJm5ic3A7UCAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFYgJm5ic3A7DQombmJzcDsgWTxicj4NCkFwcGxpY2F0 aW9uLUZhaWxvdmVyLVByaW9yaXR5ICZuYnNwOyBYWVogJm5ic3A7VW5zaWduZWQzMiAmbmJzcDsg Jm5ic3A7DQpNICZuYnNwOyAmbmJzcDtQICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgViAmbmJzcDsgJm5ic3A7IFk8YnI+DQo8YnI+DQo8YnI+DQpBcHBsaWNhdGlvbi1GYWlsb3Zl ci1JbmZvIEFWUDxicj4NClRoZSBBcHBsaWNhdGlvbi1GYWlsb3Zlci1JbmZvIEFWUCAoQVZQIGNv ZGUgeHl6KSBpcyBvZiB0eXBlIEdyb3VwZWQgYW5kDQppczxicj4NCnVzZWQgYnkgYSBEaWFtZXRl ciBlbmRwb2ludCB0byBjb21tdW5pY2F0ZSBpbmZvcm1hdGlvbiBhYm91dCBpdHMgYmFja3VwPGJy Pg0KcGVlcnMsIHdoaWNoIGNhbiB0YWtlb3ZlciB0cmFmZmljIGZvciBvbmdvaW5nIHNlc3Npb25z LCBpbiBjYXNlIHRoaXM8YnI+DQpEaWFtZXRlciBlbmRwb2ludCBmYWlscy4gVGhlcmUgbWF5IGJl IG11bHRpcGxlIEFwcGxpY2F0aW9uLUZhaWxvdmVyLUluZm88YnI+DQpBVlBzIHByZXNlbnQgaW4g YSBtZXNzYWdlLjxicj4NCjxicj4NCiAmbmJzcDsgJm5ic3A7IEFwcGxpY2F0aW9uLUZhaWxvdmVy LUluZm8gOjo9ICZsdDsgQVZQIEhlYWRlcjogWFlaICZndDs8YnI+DQogJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQom bmJzcDsgeyBBcHBsaWNhdGlvbi1GYWlsb3Zlci1Ib3N0IH08YnI+DQogJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQom bmJzcDsgeyBBcHBsaWNhdGlvbi1GYWlsdm9lci1Qcmlvcml0eSB9PGJyPg0KPGJyPg0KQXBwbGlj YXRpb24tRmFpbG92ZXItSG9zdDxicj4NClRoZSBBcHBsaWNhdGlvbi1GYWlsb3Zlci1Ib3N0IEFW UCAoQVZQIGNvZGUgeHl6KSBpcyBvZiB0eXBlIERpYW1ldGVySWRlbnRpdHk8YnI+DQphbmQgY29u dGFpbnMgdGhlIGlkZW50aXR5IG9mIGEgYmFja3VwIGhvc3QsIHdoaWNoIGlzIGFibGUgdG8gdGFr ZW92ZXI8YnI+DQp0cmFmZmljIGZvciBvbmdvaW5nIHNlc3Npb25zIGFjdGl2ZSBvbiB0aGUgaG9z dCwgd2hpY2ggb3JpZ2luYXRlZCB0aGU8YnI+DQptZXNzYWdlIGNvbnRhaW5pbmcgdGhpcyBBVlAu PGJyPg0KPGJyPg0KQXBwbGljYXRpb24tRmFpbG92ZXItUHJpb3JpdHk8YnI+DQpUaGUgQXBwbGlj YXRpb24tRmFpbG92ZXItUHJpb3JpdHkgQVZQIChBVlAgY29kZSB4eXopIGlzIG9mIHR5cGUgVW5z aWduZWQzMi48YnI+DQpJdCBjb250YWlucyB0aGUgcHJpb3JpdHkgYXNzb2NpYXRlZCB3aXRoIGEg YmFja3VwIGhvc3QuIFdoZW4gbWVzc2FnZXMgbmVlZDxicj4NCnRvIGJlIHJldHJhbnNtaXR0ZWQg b24gYXBwbGljYXRpb24gbGV2ZWwgZm9yIGFuIG9uZ29pbmcgc2Vzc2lvbiwgdGhlIGJhY2t1cDxi cj4NCmhvc3Qgd2l0aCB0aGUgaGlnaGVzdCBBcHBsaWNhdGlvbi1GYWlsb3Zlci1Qcmlvcml0eSB2 YWx1ZSBTSE9VTEQgYmUgdHJpZWQ8YnI+DQpmaXJzdC4gQSBiaWdnZXIgQXBwbGljYXRpb24tRmFp bG92ZXItUHJpb3JpdHkgQVZQIHZhbHVlIGluZGljYXRlcyB0aGF0DQp0aGU8YnI+DQpjb3JyZXNw b25kaW5nIGJhY2t1cCBzZXJ2ZXIgaXMgcHJlZmVycmVkLiBJdCBpcyB1cCB0byB0aGUgaW1wbGVt ZW50YXRpb25zDQp0bzxicj4NCmNob29zZSBiZXR3ZWVuIHR3byBiYWNrdXAgaG9zdHMgd2l0aCB0 aGUgc2FtZSBBcHBsaWNhdGlvbi1GYWlsb3Zlci1Qcmlvcml0eTxicj4NCnZhbHVlLjxicj4NCjxi cj4NCkFkZGl0aW9uIHRvIDEwLjE8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7DQombmJzcDsgJm5ic3A7IENvbW1hbmQgQ29kZTxicj4NCkF0dHJpYnV0ZSBOYW1lICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCkNFUiBD RUEgRFBSIERQQSBEV1IgRFdBIFJBUiBSQUEgQVNSIEFTQSBTVFI8YnI+DQpTVEE8YnI+DQpBcHBs aWNhdGlvbi1GYWlsb3Zlci1JbmZvICZuYnNwOyAmbmJzcDsgJm5ic3A7MCAmbmJzcDsgMCAmbmJz cDsgMCAmbmJzcDsNCjAgJm5ic3A7IDAgJm5ic3A7IDAgJm5ic3A7IDArICZuYnNwOzArICZuYnNw OyAwICZuYnNwOyAwICZuYnNwOyAwPGJyPg0KMDxicj4NCjxicj4NCjxicj4NCkFkZGl0aW9uIHRv IDEwLjI8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IENvbW1hbmQgQ29kZTxicj4NCkF0dHJpYnV0ZSBOYW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwO0FDUiBBQ0E8YnI+DQpB cHBsaWNhdGlvbi1GYWlsb3Zlci1JbmZvICZuYnNwOyAmbmJzcDsgJm5ic3A7IDArICZuYnNwOzAr PGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpEaU1FIG1haWxpbmcgbGlzdDxicj4NCkRpTUVAaWV0Zi5vcmc8YnI+DQpo dHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lPGJyPg0KPC90dD48L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NCioqKioq KioqKioqKioqKioqKioqKioqICZuYnNwO0FyaWNlbnQtVW5jbGFzc2lmaWVkICZuYnNwOyAqKioq KioqKioqKioqKioqKioqKioqKjwvZm9udD4NCjx0YWJsZT48dHI+PHRkIGJnY29sb3I9I2ZmZmZm Zj48Zm9udCBjb2xvcj0jMDAwMDAwPjxwcmU+IkRJU0NMQUlNRVI6IFRoaXMgbWVzc2FnZSBpcyBw cm9wcmlldGFyeSB0byBBcmljZW50ICBhbmQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNl IG9mIAp0aGUgaW5kaXZpZHVhbCB0byB3aG9tIGl0IGlzIGFkZHJlc3NlZC4gSXQgbWF5IGNvbnRh aW4gcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gYW5kIHNob3VsZCBub3Qg YmUgCmNpcmN1bGF0ZWQgb3IgdXNlZCBmb3IgYW55IHB1cnBvc2Ugb3RoZXIgdGhhbiBmb3Igd2hh dCBpdCBpcyBpbnRlbmRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVy cm9yLCAKcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBpbW1lZGlhdGVseS4gSWYgeW91IGFy ZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBub3RpZmllZCB0aGF0IHlvdSBh cmUgc3RyaWN0bHkKcHJvaGliaXRlZCBmcm9tIHVzaW5nLCBjb3B5aW5nLCBhbHRlcmluZywgb3Ig ZGlzY2xvc2luZyB0aGUgY29udGVudHMgb2YgdGhpcyBtZXNzYWdlLiBBcmljZW50IGFjY2VwdHMg bm8gcmVzcG9uc2liaWxpdHkgZm9yIApsb3NzIG9yIGRhbWFnZSBhcmlzaW5nIGZyb20gdGhlIHVz ZSBvZiB0aGUgaW5mb3JtYXRpb24gdHJhbnNtaXR0ZWQgYnkgdGhpcyBlbWFpbCBpbmNsdWRpbmcg ZGFtYWdlIGZyb20gdmlydXMuIgo8L3ByZT48L2ZvbnQ+PC90ZD48L3RyPjwvdGFibGU+ --=_alternative 001807516525722E_=-- --=_related 001807506525722E_= Content-Type: image/gif Content-ID: <_1_060A7688060A727C0018074E6525722E> Content-Transfer-Encoding: base64 R0lGODlhdgIJAecAAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAdgIJAUAI/wABBBhI sKDBgwgTKlzIsKHDhxAjOgRAsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBFBug4k2LN jzc1EozJs+fFnDGBYsxZk6hNi0J9KpU5dGlQj0l9Rg059WTVl1dxOoVZdKvXr1yVZgUrlazVlmOx /nza1Kzbt1+7Qs2YdmNdqnBV3i05FujNv0hHypWbt+zcwEcrGmXKuC1NsHsdoy1M+bFArYfXVt5s V+zSyHEncx5NOilo0qjPXk6tmOTpvEUPsqyKMLPi1yl37kytezdH3zqBz349kLXx42pXrzSNfPNp g79/Cy+4GrpN6ten/8Ru3W7x3d27X/+Hqjt7ce/fY3OXLVug+KHle6sXDv+7+flEsQef6Tv97b/p RSWfeUhNp194wPWWXYH9NcjfeftBqKBeiTVnIUq44fTehRx26OGHIHpFGF0B3ubefyiC5yCE7q0I 4IMo/iehig8CFpZhnd3HonKWJSZga9H5iFiOytlYpGZI8kiYhEA2qWSTfWmWIZKDGWllhUfqRGWF TGL5JJROhmiYRGSWaeaZaKapkFhqtunmm3DGKeecdNZp55145hmRmHz2ieGGfgYq6KCE9glooYi6 dmhyiVLY6KOQwjZlpJQulFuPPGL4JUiTYkbpp6BK9dyiRJrUaahmnYqoqqi2CuqOgoX/KdRiV3IZ WK3Vacmqq6XyGqSvwAYrnbDEWqopsVoiq6ywsDIGHpg+dmlrlkYu2yJ9nlk7pLbcPrpmt86RCu64 5JYrmrlc6Yfuuuy26y5Z4r4r77yJ7jrvXvHSq+++rV4Vm5f8ITaVvXwaS56eCCes8MIMN+zww3s2 R/C7GdKWbJITGzfrh1llTNeljDbq8bm9XlvtiIth/LGTP8o6LWQgi4ztaOrq1WxQft1s1Y4zyzvy bPwCfeyvqr3lF7Re4rXtqpxuiWVk+K6MqcgWpiXtyU9nWq3LkkVJYqoxB71VzX/+LLZTZjt6dtGm etp2yDgODXbSbrMJo4bk8UTccWmH/63rkFtPm/LAUt8X5ra0sswW25zyrPPakIPbt9yRN/b2sHzd 9XjekpG8HNmbn7hgiyaHGLp3hXtuM42sTl55h67H2vnrsM/ebuy0Swz3xUvDm/vviwOPLO7CF0+1 8cUir7y+xC/v/PPQVxp977tPb/31uQZ53tG0tkc3sB5bvHLijwVs8vaO5/wskLV1Zv7hG3+fNdfs I31ZbSmXnKWS7ROJ9aaZml99WNQygL2sZO9hDtds1L+RjSh64cOeBLH3wNTtj3wCRFyE8qdBgR0O bdny362o5xqnySp0+TuaBw9YI+pw0DFGUeHBTJhA3omwdNDqn9T+l8LCCUhdBdSa4P+8Zzr5Kc9g fpugEo9oRNIBTnFPkqECZVSeD3auZ5852OmSRKKbybCD9RMS4CrIoO2tRYolFCJ6JkSg8RAwP0oT Hcostz8xWrE1g/ugGaMDxyJVcIp+nB/hoChHtwFIaM2zlqqsk8glOpJXZDzjE+m2x8EFMXubGqQg 53ijnvywipm8o+HaiMM15ud07/OPG+MXoxTJiIoM2s6MRGebOg4QhdX5Vynvd8pDOkiWMwrmG9Xn y0YiJ5LLi2Bu8vXIZkLSmYZiJjSnaTxjRo6IkIGYNhtCzd99q5toSYjQumVNcEZqi+Z0ztSSxsqu 1ZGTykwn7dC5w/psh5fjOQqs7OP/RH2eMkX0XFc5UTNQea6qoDCb57gQatBBBZSLMWNooRgyTm5J tKF+eugkj5RKQuZScKI8pzQ/s82SihOjaxupN1WK0pa6VKRYfKlMJ2rSmjosnDGdqU595S9k2s6G 4NMR2XZKVHddtF9JLKpSQ8i3ujWxlssRU8WIRj2f6hOTwYGPIFfYtPexE4ZE4yAaWRjAF/7UqzGU yYG4CkCPejSIKgycOnXnVFna1VxTXapes0hXjaWxdpRLnVh9uCW5PnWUVw1p0zb6vccNdmlLyhog OwbEtuINpPQjodN6aNjSVG046kNXXvdK2uD5lSajimonZbdavqC2P2w1q2zBqDKu//rLnVWFLB7v WBcGYsyshL3nsNh4LRPpbHN5tGMAabvcQmrWtKw5Km/0ltTSWjew13VLx0JJSfaJB61I+6JbYSm/ Hg6xZublY2xzeqDwxHG8TUnu1ia7Qd6CsbO6Pexiswsb/vqXcf9NKGg3OkVONrestT1wevEbYI41 WLsPjvA6JcxUClv4wDSjYIUvzGEIYxh58eywiH334T2WEkHaWVaIz5rBgfETsSgWZhnRh8UB9ZOU +HztgISpSxq7iLxrjKV8WBelFxFZvAZaURljOeNVanHJrYTsemo0SuIm57bKvR9bLRusFeMWg7c1 H/ckOUIocQeiZO5dZJv4XS5WSf9xY1bsA8FroudeMLa5dZl5vxhXOSe4u/TrKGOp++FqbnjEiM6W dEPl5UQ7mi3bjS8V8YPk9Mn4lVHGoSpJ7Mm5JJfLdbvb6IC8QSrzOJ8+PjVi3cdY4J6YlsVFc6Fz HOsFEdnTk9aRmy1tZCiPusqiZlqhWclD5mZQy1Dks5QUC93qDVq8lztgW2lT2fzqMoppLnFmD9tn 5UKb27vV87ZpiGc96nbPf8bkolWz7k81+tHwRiQFT6raeNtbND1VEaoZGWP10BKI7Y1pkjWqtlsD WNas5fRzxrZp1DautQlXnQVnzewJHzxuCJed+MIoLax61ZZijDO4x83XxuWUzbj/NXegQV5x30rZ zseG9deI216Z1zmsObTzY4WrRvQQuJ7S+XTg6PvlUgndkDBfbLult0z6LP3eqUrfvfQLPIKxFOpY 3zJQJ57IXVmdqQiK0ZCfzvPMTVxtoPVxusyOdonTy6o3xtUkPz07ZZe3g/9zttub7HH2uojBaoY5 ne+c58aulXdHryV+sfkxXBVYgJqUMmwR//OFUl1ZX8c4Va7+2Z9mnVxwL967TcX5zxeV7NRkvOlX L2LVs/71FHY97GffRb3KntDkpH00S29Q7xF865jXfaB+r1MdXtx+Seyt2VAv/K81P6SOt9XMXO5t VFc84s/3EPEfjeXNhtGCGMyl/6D1nn2J4cbVZ3/vI5kvovKb7vzsPPP3o8+yWj3+mpZ3P8dG1aBM v5ifNuZGpFMiNOJ5/MJ+Y6N/++d+CAhCCgg7DXg2xhdt2hKBz0d83VdXKbUh25dxzPKAEDg09Jdu AGiAPMV7badIIMghHeg8t7eCqzeB1/OCMJh9J5c7NFiDOlhNQ7WDPghiPfiDQrhSNziED2aBgnJ+ QWiE8EZtv4Y6r6ViBXJLTHiB5YNVyJZl38ZT54OEVZh6QcclAWdwu9Rl1fWFENR51jNaQdaF58N0 mMOCBYWBgLR32qeGU0OH6YddnsWHhjdMyIVsIpdY8LNVzzVfdedTKdQVY/VOWv+DfoDmiFsYboYY c9OWciRofdPVV/ozeB5XeD0HX5foXAJGgV1EaVRmc8YlR2NoZL1GbEtIiGUYTDemPQBnIKz4Y2/o cFfUimFIhv0GZDHGP3ynaSVCUHhodMcYjDDmiwTSR81YgEVohxqIhtDTbl6YUWc4hU7VgjsjZAEy jUKlipfHG33xT2MHNZozK5QFh01FKKiUYX4oSt/2WNQnhig3iKWXMwZEcsdmRt32ifqoFfq4hHFF RvV4WfeHhRKFjVS1Zl+SVmMkbQNpG5PYafNYa8WFH8KIXsDEkb9IQL6WdP1kY8zoKd8FcCdykrcX gPyDSlPmRC4UjY61jKD0iOL/GBqceIpwlGodSYY3d2KkcpI6eXzW6ILJeI3bmE+kt4dGqSjxwo5G c4wEFY4zxItYkVqndUwalpFZGJHGNophOYomFiE2RHTz14+kWF+PaELOknHs0UvGBY30dEifuF// GIol947qtW+rFmw190vF6IxPuB4yZy9saE/ASJgseZOA6Iq2dlwDJ36qNosfuWr7IZNT5jgaAoAG OSHtgT/89pn2YZJDWUWNmZNLOVc39FEvc4+dNVZ2aUvoZokpiH1HqZQ7qZtPmZuGtpvPk5iNV2c+ iUdFNpfIuWuh1Wt/aWnJqXgvxmqQB31jSGo8OZLSuZL/sk935UqklJLE9Jx5/3h9UKWA3cdAI3ie 4UVytflvmZV4mDKbFwON+hV+gwZWoLaedpSQyXZziEhIgKdGi6SD2eibBUOgBrqGCDoZ8MmNBuZF yzadlGdm5WigBQqGn5OK2tlKplmZQvlLtPiTL1KLCUpVD3ihJXqHNYiiKcqCC9qiyfSiMApiSRmc dmNTOJqjOrqjPNqj21ShrzN6M7pUoSc8Qjqkp2dENHZZFseFmjdA45iDhsI5ckgzSuiUpvg5eMmU LlpiRTprLOqV23hJtgkp7XQhkdZ+YoqbuNebyKhtYpZtc0aSr3JoVnSLgRinZUaJXwWWhzhuUolh iyiL6gZnclqecsczuNaf8P+1c6Joj3C3cZEooN+HjxSXRlhWll+piCr4pHc6PrhmVfsET1qnXtBG bDi3bRApkel2dp4YUO5VqbOlcrZpj37GXGgpffalaGHoR39Hk2HqWp4KZaJ5bVp1N6kpY7DIXi/J mZFpNc2ZIMjKmFFZh6OJXDapix9amTMZlMzoklD6SiC5rZUGlDcSrCqKkTLjjaLCrqrZlEyGU93p Ul/qTXaKpEpVrzh4r/hKVEXKj99oglnah+oKhc+6i2oFHccVTVQ6gKmGL+vofHGINlcqsMKaPGCK pU3qptHFrytXpuPpLaH2VmyqPxlblAO7pkE1bMPJqJboqLVqbfpaUc2WbZv/GosPOaf+CEAAGaGS eKhXuKeYKbOT2lzn2KeYBX0822LBVYifukAzi6ZPxY6TV320ulzplYkst5c1S2qeyDj/qVVGl19p KVlNy5aECrE5549es6lpto5Ve5eTmqtw5bPBGnroWJzkKqKvyI3AerCl2LUOu4jNYjW0uJhFOK67 pErJKpkaipOUJY1qp7inaWo3CbnUloqNy7fi6rd7O7j1Up9RGK+g57H18q61N01JJkFRWzlH2q8z 1brXRG+3Cbv+CqR807aV0ULseqm2i1Gyq6Z0pIa0m7Iga6LCu3AUy6UTK7a9i7vQa7CCoXzLpLEl S3pO1ymcalsu+5WBRJtA/xufHhg8xKS8OSKXmQYwMWlwVoafn6uRZmmdiklpuoawQRmuGyq/+Ft/ 0sqsdqm3tJadm9ZwJ7ScmAaewCSeOftx7PZwr4lnjUi2Yylrz7ulpjS8PmuZmFiobqi+jFSp4mex H4o3NNd/9IZChye3F4w4iqpz3IW13rVW8HmmtSp/Z2t/NSSKmKpjPTmu3wo6veSKmeuhwrt5zGqi MJuXhBjBvzKnspmqF4k+sBaYPYx0SattHwvCG4ee+imoXTx0N2ypYfvCuiufx6K9UodXZQOhv8sZ dXg70ZtSaQeJbdxSwSvHWYmzdQy8cSyB7VrBezw9kaqVq3mx16uyb4OCgf88g1P7vQAMmCYcoiLq tc6Zv+SpfhD3wQB6ycgLfIdcnohcb1kmylvXdaLXyA26ttIGiq82oftJpxjsEkMcfotXbpfaTtvV R/+LZpYkoWGsiSHru4tKeML1oJcEkVu7tMCce1hMLenpy1c0f3KnzHkny6Z7UnQMqtaLYHImkg8M imgZeal8lpzcq8Q8d/fptJvsyudsUX2MVIJLynaVjk+ItosLk+jrc6wzkskKjlE2jIDLlnpsxJr5 b4erdtHKrQP8mJgGupLzzkHzukGHuosMOXfsx8M6vQNd0a4L0QdoulBJ0RxNMcInpSN90hmlyCi9 0rm70Sz90nLo0jA90y3/LdI0fdOFYdI4vX7oyiwq/VfuvNMTTVo6XchOKtQ82dOKlMPUaIZIfUs2 LU9IZNTP9NTSG2AyaMgficZBbMFtatVlh9XFq9UbHLDkuXxgnVXll4EjyqE2h8xvnUqALMwzPdex p2N8p8lAV2wxDMhKjXV2LWEZqM676p/lJtE7HdgR5mLZ+08k2maeK4D1TLNpzbysFbFm3Ux/zbE4 jYGwLJxLtNnG+9R0yJ1DdF6b5MyD0cV4zMyVHdmXDVFgxtrbqco2i9Gu/dqWbTmJh5om1j1SnLQA i38Prdv3C88dXdzGTY4iZa/KbdyKnXoyvbEfuNzMnV1jDdQVaN3XPdGn/xLV7JLdZC2F1u3ZnezJ Fn2tTb2yy23etBaTxhlwpAve3nIorZN/7Q1/39zKlPRH0w1T9B3Lw8Pd7j2CtHWPHj18Px3KqCLa 9kZw4qRvo7bPDvtrAQ6B/83d1+jgCp7hGh6cWT1vHv7ha7jgEmjiJA5BF/52KJ7i86biI+7iKd7i Mq7bNF7jlX3jOA7WOr7jpB3jPl7eQB7kb9eVa8zhRN6xjBzSSJ7kXLnkdzrkTh6kPdJbVR58bdTj U47bag2ZfyvCTBfiW75+lqGpdKZDTe7dWj7mFn3lQmSfFy1snM3mDgacSMngdC61dh6jeJ7ney6P CpqRtHy8oTu+b3reX/+t3fI8UTV650bZMlk7z4NJrY+puPPrb/zc3W/IRmGXi7ooLrc4uNoqwNfa wv5XnQ1di/ym6XDhkIhK1ZjcpY+eLPY5nKhYmLy2SUPpvTRcy27ViFhDu2laef6062SlzK36l+zM wYfOl53oq0emnJeJY6Ge18GGsuONd9xrqgY0iG5bZR7IwPEzzVSoqt5lqJ4baRWZtk3cvbPa7dqO q6vMms4OVInKtGWt7GfL7Niu6Mfz5/6OcYi5zaLV6IF37JGel+2pxAEKcZ/s53X+5NRdtPg92hAf 8fXOmxZ/8YAl8YK8mlNiysQuzKtN1x0fzNXs1ciru/+e8TYq6P3r2Mr/uaTsS8Atu98m/+YyP7Rb HZnkJcW+R5h9ifOzbJzYCcOels8dGt1z3uoer/IuL+Dw45EbvGYNtF+smvNupqq4ZO7bHkPsIXjo TnUpBu386eb8fevNvpUC3WOl7uWcHvNe7nPF2O+fbHdXi0ZhC61q+c5MnMR1r5dvhm1Cm6ZItqVW L8HMBpt7epFOD/Blz9fsXrT4k3Sh5WFN7ypH9d0d5urk7Jp+OvlI78SWr/gOmPkcz/aqj11pnu2x nvog4vkf3+ewT7BRz+duCtqwLjfmOzcmnzbB3bD7a80b//hPr/GuT4mhydS4rmSpPnDbqe78XLjT vvT+1vVmT5Od2dUh/1m/y6+SeO1k+nv05Tv+Bbv6L/+U947sYwnZVX9e8sf9eW+34xh/eu3Epr39 be1wJTxLJwwQAQAMJFhwYACECAkKPNhwoUGICRUWZLhwosOHEDVu5MixYkeQIUWK/OiRpMaSI1We XMmypcuXGDdWpElR5seUAHAaFLgzY0mfPzOa5GnTaNGhGHsm1cm0Y82mFIEKfWp0qkeGCi/qTGiR q1SvVYdCDYry6M2iV2PGzLnW7ci2NoNC5ZkV7cG2V+lG5RvxbFa7Tt8KXhlXLNLBiRUvZtzY8WPI kSVPfmuYckvLXOcKJns0bkq1fD//VXqWcWaQqC+vZt3a9WvYsWW7Vf89mzDenhe10tS9G3DvrhaD awb+FbfU4RKPJ4dce6Zt6NGlT6denbpz29ity9YOd3D37eHFjydf/jJ42OjNr0e8Vj17+PHlz6/+ vrV9+uLfo+ZvtvB3x/D777mQyqJLwL5SU0w9BGVaTa/GGpxMIgortPBCDDPUcEMOO/TwQxC3YqvA vg5EKbCqcEJxotCS4u2uBEkbC8XDRMtsKapKI8qhzbxr78YSA2OxPRfD6tE/GIck0bPT8nPyySZT 28pEvxw88ci9YiwRSdF23FJHBYuU0qeyVKLRtBphxKrHLHMqM0kvsYSpy8UkhPJO9gzrKrnchPNz uIh8w03FKZUblLf/Qvs8TjjgENXsKUMfFRG5R/GitMBIiSOUpEQt25NFPjtFtFFKi2N01D8nRQ5U VSvD81VYl9RPREBjtdU1QGu9lTI7d/V1tl5/FXZYYiULtlhkm0t2WWabxdVZaK+LELxWMVM2Wmyz 1VJbbieENNPnXjSOQrkIfTHUukIdddNVvaq2W3jXOzZeevUkV0E5q4zqSH1Nu3fbL8Gcl16CAyz4 4CgXHMtSgXOkk0s6xX1YTSoRtti6gS+GNmONO/b42o9D9lJkkkuOjmOTf0U5ZZZbttJljVeGeeaQ ZaYZSptv1vngnHeer2efg9YWaKHlLfpopAFOeuOlm9aZaKcxDnFqFKqrtvpqrLPWemuuu/b6a7Cp Xi8gADs= --=_related 001807506525722E_=-- --===============1610512565== 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 --===============1610512565==-- From dime-bounces@ietf.org Wed Nov 22 11:34:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmv3G-0005At-0h; Wed, 22 Nov 2006 11:34:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmv3F-0005Aj-13 for dime@ietf.org; Wed, 22 Nov 2006 11:34:21 -0500 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 1Gmv3C-0007yH-Mr for dime@ietf.org; Wed, 22 Nov 2006 11:34:21 -0500 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id kAMGXciE007764; Wed, 22 Nov 2006 11:33:38 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <45647BE2.9020601@tari.toshiba.com> Date: Wed, 22 Nov 2006 11:33:38 -0500 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: prasadsv@condornetworks.com Subject: Re: [Dime] Redundancy support AVPs References: <000201c70e20$cfe6cbe0$0801a8c0@KRISHNA> In-Reply-To: <000201c70e20$cfe6cbe0$0801a8c0@KRISHNA> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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, > 1) Is there any specific reason for length constraint(4096) on > Session-Data AVP? > I think the idea was to mimic the constraints set by Class AVP but we can remove this restriction since Session-Data is opaque. > 2) Does it more helpful if we add some text saying that these AVPs MAY > included in any 'service specific requests/responses' (not just in > RAR,ASR,STR ..etc). > The AVPs are not limited to base protocol messages only. They are for general end-to-end use and can be optionally attached to service specific messages. We can add text to clarify this if needed. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 22 11:37:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmv6d-0006I7-F9; Wed, 22 Nov 2006 11:37:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmv6b-0006Hk-T9 for dime@ietf.org; Wed, 22 Nov 2006 11:37:49 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmv6a-0000FP-Bz for dime@ietf.org; Wed, 22 Nov 2006 11:37:49 -0500 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 C06BBE4962; Wed, 22 Nov 2006 11:37:47 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id kAMGbee9021707; Wed, 22 Nov 2006 11:37:44 -0500 (EST) From: "Tolga Asveren" To: "Preeti Shandilya" Subject: RE: [Dime] Redundancy support AVPs Date: Wed, 22 Nov 2006 11:34:57 -0500 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 Importance: Normal In-Reply-To: Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 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 Preeti, I think there are a few issues related with using CER/CEA for that purpose: a) It could be the case that a node supports more than one application, where failover support characteristics are different (this could be addressed with an Application-Id AVP) b) This infomration exchange has to happen end-to-end between applications, they are not neighbors necessarily. Thanks, Tolga -----Original Message----- From: Preeti Shandilya [mailto:preeti.shandilya@aricent.com] Sent: Tuesday, November 21, 2006 11:27 PM To: Tolga Asveren Cc: dime@ietf.org Subject: Re: [Dime] Redundancy support AVPs Hi Tolga ! I have few suggestion in this regard. 1. Send Application failover AVP in CER/CEA only. Inform peer node about the redundant node during capability exchange 2. Enhance Application failover AVP to include Auth-Application-Id AVP and Acct-Application-Id AVP as well to indicate for what kind of application redundancy support is available. In this method, node will have to process this AVP only during capability exchange and nodes will update its' database for redundant nodes. I have captured this in following figure Node1 shall send Application-Failover-Priority as 1(high) and Node2 shall send Application-Failover-Priority as 2(low). Peer node will always send messages to Node1 only as it is on high priority. Incase of Node1 fails, peer node shall start sending data to Node2. Let me know if this approach has any problem. Regards Preeti "Tolga Asveren" 11/21/2006 08:32 PM To cc Subject[Dime] Redundancy support AVPs Hi All, During the interoperability testing there were some ideas about having more support in Diameter to facilitate redundant implementations. I guess also during some threads in DIME WG similar opinions were expressed. During the last IETF DIME WG meeting, I had the chance to briefly mention about this issue as well and said that I will provide some text for review/to get opinions. The initial version of the text is below. I also entered it to the issue tracker (#25). Does this look good to others? Shall/can we include this in the bis? Thanks, Tolga ============================================================================ = Some generic support to preserve opaque session data in messages and to communicate server support for session level failover could be very useful to facilitate development of redundant systems. The following changes are proposed: ================================================================ 8.22 Session-Info AVP is used by application sessions to store session related opaque data in the messages. This AVP carries state information that are communicated between Diameter application end-points only. It provides applications with a generic method to store opaque data in messages for high availability, redundancy or other purposes that may not be defined in the Diameter application itself. AVP Flag Rules AVP Data SHLD MUST MAY Attribute Name Code Type MUST MAY NOT NOT Encr Session-Info XYZ Grouped M P V Y Origin-Host 264 DiamIdent M P V Y Session-Data XYZ OctetString M P V Y Session-Info AVP The Session-Info AVP (AVP code xyz) is of type Grouped and is used by Diameter entities serving as application endpoints to send and receive session related opaque data. An application originating a request or answer message MAY include the Session-Info AVP in the message. The receiver of the message that includes a Session-Info AVP inserted by the remote peer MUST include the same Session-Info AVP in the subsequent request or answer messages. Diameter endpoints MAY update the opaque data carried in Session-info AVP. Diameter endpoints MUST use the last received Session-Info AVP in the subsequent request and answers they generate. Session-Info ::= < AVP Header: XYZ > { Origin-Host } { Session-Data } Origin-Host AVP The Origin-Host AVP contains the identity of the host that added the Session-Info AVP. Session-Data AVP The Session-Data AVP (AVP code xyz) is of type OctetString and contains opaque session related data. The maximum length of Session-Data AVP is 4096 octets. An endpoint receiving a Session-Data AVP more than 4096 octets in size MUST terminate the session. Addition to 10.1 Command Code Attribute Name CER CEA DPR DPA DWR DWA RAR RAA ASR ASA STR STA Session-Info 0 0 0 0 0 0 0+ 0+ 0+ 0+ 0+ 0+ Addition to 10.2 Command Code Attribute Name ACR ACA Session-Info 0+ 0+ ================================================= 8.23 Application-Failover-Info AVP is used by applications that can support failover at the application level. It can be used by any applications for communicating information regarding backup or alternate nodes which can takeover traffic for an ongoing session in case of failover. This allows a sessions to retransmit messages to the alternate node if present. Note that the application level failover is independent of the base protocol failover but both can be used concurrently. AVP Flag Rules AVP Data SHLD MUST MAY Attribute Name Code Type MUST MAY NOT NOT Encr Application-Failover-Info XYZ Grouped M P V Y Application-Failover-Host XYZ DiamIdent M P V Y Application-Failover-Priority XYZ Unsigned32 M P V Y Application-Failover-Info AVP The Application-Failover-Info AVP (AVP code xyz) is of type Grouped and is used by a Diameter endpoint to communicate information about its backup peers, which can takeover traffic for ongoing sessions, in case this Diameter endpoint fails. There may be multiple Application-Failover-Info AVPs present in a message. Application-Failover-Info ::= < AVP Header: XYZ > { Application-Failover-Host } { Application-Failvoer-Priority } Application-Failover-Host The Application-Failover-Host AVP (AVP code xyz) is of type DiameterIdentity and contains the identity of a backup host, which is able to takeover traffic for ongoing sessions active on the host, which originated the message containing this AVP. Application-Failover-Priority The Application-Failover-Priority AVP (AVP code xyz) is of type Unsigned32. It contains the priority associated with a backup host. When messages need to be retransmitted on application level for an ongoing session, the backup host with the highest Application-Failover-Priority value SHOULD be tried first. A bigger Application-Failover-Priority AVP value indicates that the corresponding backup server is preferred. It is up to the implementations to choose between two backup hosts with the same Application-Failover-Priority value. Addition to 10.1 Command Code Attribute Name CER CEA DPR DPA DWR DWA RAR RAA ASR ASA STR STA Application-Failover-Info 0 0 0 0 0 0 0+ 0+ 0 0 0 0 Addition to 10.2 Command Code Attribute Name ACR ACA Application-Failover-Info 0+ 0+ _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime *********************** Aricent-Unclassified *********************** "DISCLAIMER: This message is proprietary to Aricent 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. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 22 12:17:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmvj4-0005ut-Nt; Wed, 22 Nov 2006 12:17:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmvj3-0005ul-B8 for dime@ietf.org; Wed, 22 Nov 2006 12:17:33 -0500 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 1Gmvj2-0006wn-29 for dime@ietf.org; Wed, 22 Nov 2006 12:17:33 -0500 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id kAMHGnv0007996; Wed, 22 Nov 2006 12:16:49 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <45648601.3030601@tari.toshiba.com> Date: Wed, 22 Nov 2006 12:16:49 -0500 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] Redundancy support AVPs References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Preeti Shandilya , 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, > a) It could be the case that a node supports more than one application, > where failover support characteristics are different (this could be > addressed with an Application-Id AVP) > We may need to add clarifying text which says that when this AVP is present in a message, redundancy support applies to the application specified by the message (app-id in the header or app-id avps etc). regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 22 13:58:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmxIb-0000v3-9g; Wed, 22 Nov 2006 13:58:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmxIZ-0000tt-DL for dime@ietf.org; Wed, 22 Nov 2006 13:58:19 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmxIW-0004XN-W6 for dime@ietf.org; Wed, 22 Nov 2006 13:58:19 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id kAMIpCk05067; Wed, 22 Nov 2006 13:51:12 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Expert Reviewers Nominated Date: Wed, 22 Nov 2006 12:58:12 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371119947E6@zrc2hxm2.corp.nortel.com> In-Reply-To: <455515A0.9050106@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Expert Reviewers Nominated Thread-Index: AccFJ5Wp45xcEi+kSPiL/aW5ZjYiQwH+3uTQ From: "Ahmad Muhanna" To: "Hannes Tschofenig" , X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: lionel.morand@francetelecom.com, mamuhanna@nortel.com, "Glen Zorn \(gwz\)" 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 find below my technical comments after reviewing this draft. The following is the type of comments I have: 1. Editorial comments 1.1. Comment 1: Abstract ................................. This document also specifies the role of the Home Agent as part of the AAA infrastructure supporting the Diameter Mobile IPv6 Authorization Application. I am not sure what we mean by the HA part of the AAA infrastructure. May be we can say "..... The Home Agent as a Diameter MIP6 Authorization client." 1.2. Comment 2: Introduction " With the Mobile IPv6 protocol [1], a Mobile Node (MN) is assigned a Home Agent which is in charge of relaying IPv6 packets destined to MN's Home Address to the MN's current address. " Can we reword this sentence as follows: "A Mobile Node (MN) that support Mobile IPv6 protocol [1] is assigned a Home Agent to register its Mobile IPv6 session in order facilitate its reachability and mobility at all time when it is a way from home." 1.3. Comment 3: " ....................For this reason, it is important for the Home Agent to act as part of the service provider's AAA infrastructure." Can we replace it with the following: "....................For this reason, it is important for the Home Agent to act as Diameter MIP6 Authorization client." 1.4. Comment 4: Under section 3.0,=20 "When the verification of user authorization to receive Mobile IPv6 service is complete, the Home Agent..............................." Can we replace it with the following: "When the user Mobile IPv6 service authorization process is successful,=20 the Home Agent..............................." 1.5. Comment 5: Under section 4: "...................................................... As EAP is considered as a strong choice in performing authentication, this document explains the use of Diameter EAP application in cases where the prior authentication between MN and HA is done through use of EAP. Therefore, the HA performs AAA operations for Mobile IPv6 by using two Diameter Applications, namely: Diameter EAP[6] and Diameter Mobile IPv6 (specified by this document)." Can we reword this one, may be as follows: "...................................................... As EAP is very possibly the choice for performing user authentication, this document explains the use of Diameter EAP application when the MN and HA use it for their authentication. Therefore HA performs user=20 authentication using Diameter EAP [6] and Mobile IPv6 service=20 authorization using Diameter Mobile IPv6 as specified in this document" 2. Non Completed sections comments All non completed section need to be updated and completed. 3. Proposed New functionality comments Under section 4.3 Accounting, it reads: " ........................................................ However, due to routing optimization techniques introduced with Mobile IPv6 the HA does not see the entire traffic exchanged between the MN and the CN." Proposed Functionality: I would propose that it become part of this application the authorization for=20 the user route optimization. This means that AAAH-MIP6 server will indicate=20 to the HA if route optimization is allowed for this user or not using an AVP, like: MIP6-Route-Optimization-Capabilities. This will give the MSA more power over the=20 their billing modulation and offering. This probably requires some change to allow the HA to communicate to MN that route optimization authorization status. 4. The main technical issue, AAAH-EAP and AAAH-MIP6 servers are Different. (IMO) this needs to be addressed depending on the bootstrapping and authentication Model, as described below: 4.1. Integrated Bootstrapping In this case, I do not see any need for the AAAH-EAP and AAAH-MIP6 to be the same. Both the Diameter Client and Diameter server belong to the same operator and there SHOULD be an existing trust relationship. In this case, the Diameter server AAAH-MIP6 does not need to verify or know that the user has been authenticated or NOT. It ONLY needs to verify if the user is authorized to receive Mobile IPv6 service or not. (Also the proposed idea below can be adopted here) 4.2. Split Bootstrapping: In this case, I believe there are two different scenarios: (4.2.1. HA in the Home Network, 4.2.2. HA in the visited network) 4.2.1. HA in the Home Network This case is similar to 4.1. 4.2.2. HA in the Visited Network Although communication to the AAAH-EAP and AAAH-MIP6 servers is through some kind of SLA, there is still a need for the AAAH-MIP6 to be assured that the authorization request is for an authenticated user. Please see some thoughts about a possible idea for a solution below. 4.3. Using RFC4285 I think this RFC should be considered for this Diameter MIP6 Authorization application. Proposed solutions: I will use the other thread for it. Many Thanks. Regards, Ahmad =20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Friday, November 10, 2006 6:13 PM > To: dime@ietf.org > Cc: lionel.morand@francetelecom.com; mamuhanna@nortel.com;=20 > Glen Zorn (gwz) > Subject: [Dime] Expert Reviewers Nominated >=20 > Hi all, >=20 > during the DIME meeting we selected expert reviewers for the=20 > HA<->AAAH document > (http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-01.txt): >=20 > * Glen Zorn > * Lionel Morand > * Ahmad Muhanna >=20 > Since a number of issues have been raised during the meeting=20 > I would suggest to also jump into the discussions. I will=20 > send a separate mail with a description of the raised aspects. >=20 > Ciao > Hannes >=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 Wed Nov 22 14:05:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmxPF-0006OA-SA; Wed, 22 Nov 2006 14:05:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmxPE-0006Nr-H6 for dime@ietf.org; Wed, 22 Nov 2006 14:05:12 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmxPD-0005du-8D for dime@ietf.org; Wed, 22 Nov 2006 14:05:12 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kAMJ58F09860; Wed, 22 Nov 2006 14:05:08 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split Date: Wed, 22 Nov 2006 13:05:07 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437111994801@zrc2hxm2.corp.nortel.com> In-Reply-To: <4555188F.9080604@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split Thread-Index: AccFKAVd+L/TzvfoRkiBKocXL0OaLAIBKB5w From: "Ahmad Muhanna" To: "Hannes Tschofenig" , X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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, The following is an idea that I would like to throw out as a possible solution: I believe the easiest way is for the HA to include an explicit attribute that the user has been authenticated successfully. This way, the AAAH-MIP6 have an explicit indication and record from the serving HA, regardless if it is in the Home or Visited Network. We may also require that the HA include the identity of the AAAH-EAP server which did the authentication. Comments:=20 ?? Regards, Ahmad > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Friday, November 10, 2006 6:26 PM > To: dime@ietf.org > Subject: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split >=20 > Hi all, >=20 > during the DIME meeting Glen raised an important question=20 > that impacts the design of the protocol, namely: > " > Do we need to support the scenario where the Diameter EAP=20 > authentication and the Diameter MIPv6 authorization exchange=20 > terminate at different servers? > " >=20 > Currently, we assume that these two exchanges could be=20 > terminated at different servers. As a consequence, security=20 > concerns were raised (see slide 5 of=20 > http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt). >=20 > How do people think about restricting the Diameter MIPv6=20 > HA-to-AAAH document to terminate the authentication and=20 > authorization exchange at the same server? >=20 > Ciao > Hannes >=20 > PS: Glen also suggested to consider using the Diameter MIPv6=20 > App-ID for the Diameter EAP exchange if we decide that both=20 > exchanges terminate at the same server. As a consequence the=20 > open issue described at slide 6 of=20 > http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt=20 > would also be resolved. The changes to the existing document=20 > would be minimal (about 2 additional sentences). >=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 Thu Nov 23 03:17:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn9mB-0007zK-AU; Thu, 23 Nov 2006 03:17:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn9m9-0007z8-KR for dime@ietf.org; Thu, 23 Nov 2006 03:17:41 -0500 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gn9m7-0001Ej-W6 for dime@ietf.org; Thu, 23 Nov 2006 03:17:41 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAN8H2be019008 for ; Thu, 23 Nov 2006 10:17:31 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 10:16:06 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 10:16:08 +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 Date: Thu, 23 Nov 2006 10:16:06 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Inclusion of Filter-Id and NAS-Filter-Rule AVPs Thread-Index: AccL4J6zK15IbIj2TUKR75nex/7kugC9sfzw From: To: X-OriginalArrivalTime: 23 Nov 2006 08:16:08.0400 (UTC) FILETIME=[A0ED1D00:01C70ED7] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [Dime] FW: Inclusion of Filter-Id and NAS-Filter-Rule AVPs 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 The RADEXT WG currently has the RADIUS Filter Rule document in WG last all: http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-05.txt One of the questions that has arisen is how a NAS should treat an Access-Accept that contains both a Filter-Id attribute and a NAS-Filter-Rule attribute.=20 Currently Section 2 states: The NAS-Filter-Rule attribute is not intended to be used concurrently with any other filter rule attribute, including Filter-Id (11) and NAS-Traffic-Rule [Traffic] attributes, and MUST NOT appear in the same RADIUS packet. If a Filter-Id or NAS- Traffic-Rule attribute is present, then implementations of this specification MUST silently discard NAS-Filter-Rule attributes, if present. RFC 4005 Section 6.7 states the following with respect to the Filter-Id AVP:=20 In non-RADIUS environments, it is RECOMMENDED that the NAS-Filter- Rule AVP be used instead. However, since this is a recommendation, it appears possible that an RFC 4005 implementation could send a NAS-Filter-Rule AVP along with a Filter-Id AVP. Based on the Section 2 text above, such a message would not be translatable to an equivalent RADIUS packet.=20 Some questions: a. Does the DIME WG have an opinion on the appropriate normative language for the Section 2 text above? For example, is the "MUST NOT" too strict?=20 b. Is there a situation in which both the NAS-Filter-Rule and Filter-Id AVPs will need to be sent in a Diameter message? c. If such a situation exists, how is a NAS to interpret such a message? Does one AVP take precedence? Or are the AVPs combined somehow?=20 ----------------------------------------- To: Bernard Aboba Subject: RE: Issue on filter-rules-01 From: David Nelson Date: Sat, 11 Nov 2006 10:42:30 -0500 I think it ought to be MUST NOT. I think the Diameter specification is defective in that it allows both kinds of filtering attributes, but fails to specify how to correctly apply them (i.e. a precedence order) so as to allow interoperability. I recommend that we not compound that error in this draft. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Nov 23 03:37:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnA5f-0001OR-30; Thu, 23 Nov 2006 03:37:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnA3v-0000Mq-Ug for dime@ietf.org; Thu, 23 Nov 2006 03:36:03 -0500 Received: from ceiling.dave.sonera.fi ([131.177.130.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnA2r-0003pp-T3 for dime@ietf.org; Thu, 23 Nov 2006 03:34:59 -0500 Received: from ceiling.dave.sonera.fi (localhost [127.0.0.1]) by ceiling.dave.sonera.fi (Sendmail) with ESMTP id kAN8Yo6Q011491 for ; Thu, 23 Nov 2006 10:34:50 +0200 (EET) Received: from [131.177.37.116] (l50029133.pool.sonera.fi [131.177.37.116]) by ceiling.dave.sonera.fi (Sendmail) with ESMTP id kAN8Ynm4011481; Thu, 23 Nov 2006 10:34:50 +0200 (EET) Message-ID: <45655D2A.9070709@teliasonera.com> Date: Thu, 23 Nov 2006 10:34:50 +0200 From: Jouni Korhonen User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: [Dime] FW: Inclusion of Filter-Id and NAS-Filter-Rule AVPs References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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 Comments inline.. john.loughney@nokia.com kirjoitti: > The RADEXT WG currently has the RADIUS Filter Rule document in WG last > all: > http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-05.txt > > One of the questions that has arisen is how a NAS should treat an > Access-Accept that contains both a Filter-Id attribute and a > NAS-Filter-Rule attribute. > > Currently Section 2 states: > > The NAS-Filter-Rule attribute is not intended to be used > concurrently with any other filter rule attribute, including > Filter-Id (11) and NAS-Traffic-Rule [Traffic] attributes, and MUST > NOT appear in the same RADIUS packet. If a Filter-Id or NAS- > Traffic-Rule attribute is present, then implementations of this > specification MUST silently discard NAS-Filter-Rule attributes, if > present. > > RFC 4005 Section 6.7 states the following with respect to the Filter-Id > AVP: > > In non-RADIUS environments, it is RECOMMENDED that the NAS-Filter- > Rule AVP be used instead. > > However, since this is a recommendation, it appears possible that an RFC > 4005 implementation could send a NAS-Filter-Rule AVP along with a > Filter-Id AVP. Based on the Section 2 text above, such a message would > not be translatable to an equivalent RADIUS packet. > > Some questions: > > a. Does the DIME WG have an opinion on the appropriate normative > language for the Section 2 text above? For example, is the "MUST NOT" > too strict? > > b. Is there a situation in which both the NAS-Filter-Rule and Filter-Id > AVPs will need to be sent in a Diameter message? I would assume that some inbound proxy could always add Filter-Id for admin domain internal default rules (as RFC4005 would allow this). This has been thought as a use case in some circumstances. > c. If such a situation exists, how is a NAS to interpret such a message? I would assume (again) that Filter-Id rules get applied first and then 'patched' with NAS-Filter-Rule. But given the fact this has not been defined in RFC4005 all this is just assuming ;-) > Does one AVP take precedence? Or are the AVPs combined somehow? > /Jouni > ----------------------------------------- > To: Bernard Aboba > Subject: RE: Issue on filter-rules-01 > From: David Nelson > Date: Sat, 11 Nov 2006 10:42:30 -0500 > > I think it ought to be MUST NOT. I think the Diameter specification is > defective in that it allows both kinds of filtering attributes, but > fails to specify how to correctly apply them (i.e. a precedence order) > so as to allow interoperability. I recommend that we not compound that > error in this draft. > > > > > _______________________________________________ > 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 Nov 23 03:42:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnA9p-0004D0-4j; Thu, 23 Nov 2006 03:42:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnA9o-0004Cs-Ch for dime@ietf.org; Thu, 23 Nov 2006 03:42:08 -0500 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnA9m-0004pM-00 for dime@ietf.org; Thu, 23 Nov 2006 03:42:08 -0500 Received: by ug-out-1314.google.com with SMTP id 72so334629ugd for ; Thu, 23 Nov 2006 00:42:05 -0800 (PST) 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=cF/Oi5tHKoyqFedCWmmuE6/EGotUXbbTmPGczJXQ8kPBQzshkufnmKlD9uf/KyOPPhLhOcNSYcxNxZIbHCuVqk1QCixkRyZ9vyMyp5N0ogBu5CmTRU/LSTSPWbzzjGjOehYrhlK3Iv+Z/uLLLLAUIM+ZEih2DXOBbmQZTsy2ktg= Received: by 10.66.216.20 with SMTP id o20mr4619987ugg.1164271325096; Thu, 23 Nov 2006 00:42:05 -0800 (PST) Received: by 10.67.15.18 with HTTP; Thu, 23 Nov 2006 00:42:04 -0800 (PST) Message-ID: <5e2406980611230042n642f6d7dua442db4e7839a4e9@mail.gmail.com> Date: Thu, 23 Nov 2006 09:42:05 +0100 From: "Julien Bournelle" To: "Ahmad Muhanna" Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437111994801@zrc2hxm2.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4555188F.9080604@gmx.net> <6FC4416DDE56C44DA0AEE67BC7CA437111994801@zrc2hxm2.corp.nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 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 Ahmad, thanks a lot for your review. I respond to your proposal and try to sum up a little our current situation with this highligting three different ways to move forward. On 11/22/06, Ahmad Muhanna wrote: > > Hi all, > > The following is an idea that I would like to throw out as a possible > solution: > > I believe the easiest way is for the HA to include an explicit attribute > that the user has been authenticated successfully. This way, the > AAAH-MIP6 have an explicit indication and record from the serving HA, > regardless if it is in the Home or Visited Network. We may also require > that the HA include the identity of the AAAH-EAP server which did the > authentication. > > Comments: > ?? hmm, the threat mentionned by madjid was that the HA is compromised and uses a fake AAA-EAP server. In this case, the HA would be able to send your proposed attribute. I'm not sure this solve the issue. Personnally, before solving this issue, I think we should agree or not on the fact that it si effectivily an issue. The fact that we use 4072 in AUTHENTICATE_ONLY mode for Authentication and define a new application for the Authorization/Accounting part was to avoid to update all Diameter Application using EAP for Authentication if 4072 has to be updated. As we define a new application for Authorization/Accounting, we lost the binding between Authentication and Authorization/Accounting at the AAA server. However, AAAH-EAP and AAAH-MIP6 belong to the MSA and finally the HA is now responsible of this binding. To move forward with this I see 3 options: 1/ We continue with the current approach and decide that this is not an issue if the Authz/Acctg server has no "proof" that the user has been authenticated. The HA is responsible for this. We consider that this is an issue. So we consider that the Authz/Acctg need to be bound to the Authentication. Then we have 2 options: 2/ We include DER/DEA messages in the MIP6 Application but define a new command-code. An update of 4072 would certainly lead to an update of this application. 3/ We define a generic mechanism that permits to give a proof to the AAAH-MIP6 that AAAH-EAP has correctly authenticated the user. Comments ? Let me know if you see others options. Julien > > > Regards, > Ahmad > > > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Friday, November 10, 2006 6:26 PM > > To: dime@ietf.org > > Subject: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split > > > > Hi all, > > > > during the DIME meeting Glen raised an important question > > that impacts the design of the protocol, namely: > > " > > Do we need to support the scenario where the Diameter EAP > > authentication and the Diameter MIPv6 authorization exchange > > terminate at different servers? > > " > > > > Currently, we assume that these two exchanges could be > > terminated at different servers. As a consequence, security > > concerns were raised (see slide 5 of > > http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt). > > > > How do people think about restricting the Diameter MIPv6 > > HA-to-AAAH document to terminate the authentication and > > authorization exchange at the same server? > > > > Ciao > > Hannes > > > > PS: Glen also suggested to consider using the Diameter MIPv6 > > App-ID for the Diameter EAP exchange if we decide that both > > exchanges terminate at the same server. As a consequence the > > open issue described at slide 6 of > > http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt > > would also be resolved. The changes to the existing document > > would be minimal (about 2 additional sentences). > > > > > > _______________________________________________ > > 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 Nov 23 17:08:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnMk1-0007t5-AU; Thu, 23 Nov 2006 17:08:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnMk0-0007sz-P4 for dime@ietf.org; Thu, 23 Nov 2006 17:08:20 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnMjz-0004x5-Ac for dime@ietf.org; Thu, 23 Nov 2006 17:08:20 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id kANM1DR06891; Thu, 23 Nov 2006 17:01:13 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split Date: Thu, 23 Nov 2006 16:08:14 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437111994AE2@zrc2hxm2.corp.nortel.com> In-Reply-To: <5e2406980611230042n642f6d7dua442db4e7839a4e9@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split Thread-Index: AccO20N8NWCglhV0TWOY16RnYbzNyAAWS/Ww From: "Ahmad Muhanna" To: "Julien Bournelle" X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b 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, Thanks for your comments. Please see my comments below. Regards, Ahmad =20 > -----Original Message----- > From: Julien Bournelle [mailto:julien.bournelle@gmail.com]=20 > Sent: Thursday, November 23, 2006 2:42 AM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: Hannes Tschofenig; dime@ietf.org > Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support:=20 > Server Split >=20 > HI Ahmad, >=20 > thanks a lot for your review. I respond to your proposal and=20 > try to sum up a little our current situation with this=20 > highligting three different ways to move forward. >=20 > On 11/22/06, Ahmad Muhanna wrote: > > > > Hi all, > > > > The following is an idea that I would like to throw out as=20 > a possible > > solution: > > > > I believe the easiest way is for the HA to include an explicit=20 > > attribute that the user has been authenticated=20 > successfully. This way,=20 > > the > > AAAH-MIP6 have an explicit indication and record from the=20 > serving HA,=20 > > regardless if it is in the Home or Visited Network. We may also=20 > > require that the HA include the identity of the AAAH-EAP=20 > server which=20 > > did the authentication. > > > > Comments: > > ?? >=20 > hmm, the threat mentionned by madjid was that the HA is=20 > compromised and uses a fake AAA-EAP server. In this case, the=20 > HA would be able to send your proposed attribute. I'm not=20 > sure this solve the issue. [Ahmad] I am not sure what the exact meaning and the extent of the HA being compromised? (IMO) If the HA is compromised, why the HA needs authorization from AAAH-MIP6 to start with. HA will be able to offer the service without the need to contact the AAAH-MIP6 server.=20 On the other hand, we probably should come up with a mechanism which allows the HA to communicate both Authentication and authorization to the same server. Please see some thoughts below. >=20 > Personnally, before solving this issue, I think we should=20 > agree or not on the fact that it si effectivily an issue. The=20 > fact that we use > 4072 in AUTHENTICATE_ONLY mode for Authentication and define=20 > a new application for the Authorization/Accounting part was=20 > to avoid to update all Diameter Application using EAP for=20 > Authentication if 4072 has to be updated. As we define a new=20 > application for Authorization/Accounting, we lost the binding=20 > between Authentication and Authorization/Accounting at the=20 > AAA server. However, AAAH-EAP and > AAAH-MIP6 belong to the MSA and finally the HA is now=20 > responsible of this binding. >=20 > To move forward with this I see 3 options: >=20 > 1/ We continue with the current approach and decide that=20 > this is not an issue if the Authz/Acctg server has no "proof"=20 > that the user has been authenticated. The HA is responsible for this. >=20 [Ahmad] It is ok as long as the HA include something to indicate that the user has been authenticated. Possibly: HA include an attribute to indicate that user have been authenticated and/or the identity of the AAAH-EAP server which done the authentication. At least there will be some record that HA has communicated that. Especially when HA is in the visited network. > We consider that this is an issue. So we consider that the=20 > Authz/Acctg need to be bound to the Authentication. Then we have 2 > options: >=20 > 2/ We include DER/DEA messages in the MIP6 Application but=20 > define a new command-code. An update of 4072 would certainly=20 > lead to an update of this application. [Ahmad] Basically this option assumes that the same AAAH server support authentication and authorization. Right? What about if we think of a mechanism that allows the HA to send the MAR to the same AAAH which done EAP authentication and at the same time it supports AAAH-MIP6. This way we avoid the update for the existing RFC and at the same time guarantee that the same server does both operations. Here I am throwing a couple of thoughts: Option 1: 1. Mandating that AAAH server which support EAP to support MIP6 Authorization. 2. Then HA always sends the MAR to the same server which done the EAP authentication via the AAAH-EAP identity. Option 2 (this gives more flexibility): 1. HA and/or proxy Diameter server should track Diameter servers which support both EAP and MIP6 Authorization during capabilities exchange. 2. HA and/or Proxy Diameter Server should forward the EAP authentication to a server that support both EAP authentication + MIP6 authorization. 3. HA sends the MIP6 Authorization request (MAR) to the same AAAH-EAP server which performed the EAP authentication. Comments ? >=20 > 3/ We define a generic mechanism that permits to give a proof to the > AAAH-MIP6 that AAAH-EAP has correctly authenticated the user. [Ahmad] If we agree on one of the options above, then this is already addressed. >=20 > Comments ? >=20 >=20 > Let me know if you see others options. >=20 > Julien >=20 >=20 >=20 > > > > > > Regards, > > Ahmad > > > > > > > -----Original Message----- > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > Sent: Friday, November 10, 2006 6:26 PM > > > To: dime@ietf.org > > > Subject: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server=20 > > > Split > > > > > > Hi all, > > > > > > during the DIME meeting Glen raised an important question that=20 > > > impacts the design of the protocol, namely: > > > " > > > Do we need to support the scenario where the Diameter EAP=20 > > > authentication and the Diameter MIPv6 authorization exchange=20 > > > terminate at different servers? > > > " > > > > > > Currently, we assume that these two exchanges could be=20 > terminated at=20 > > > different servers. As a consequence, security concerns=20 > were raised=20 > > > (see slide 5 of=20 > > > http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt). > > > > > > How do people think about restricting the Diameter MIPv6=20 > HA-to-AAAH=20 > > > document to terminate the authentication and=20 > authorization exchange=20 > > > at the same server? > > > > > > Ciao > > > Hannes > > > > > > PS: Glen also suggested to consider using the Diameter=20 > MIPv6 App-ID=20 > > > for the Diameter EAP exchange if we decide that both exchanges=20 > > > terminate at the same server. As a consequence the open issue=20 > > > described at slide 6 of=20 > > > http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt > > > would also be resolved. The changes to the existing=20 > document would=20 > > > be minimal (about 2 additional sentences). > > > > > > > > > _______________________________________________ > > > 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 From dime-bounces@ietf.org Wed Nov 29 11:59:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpSma-0005mr-Ju; Wed, 29 Nov 2006 11:59:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpSmZ-0005md-Ny for dime@ietf.org; Wed, 29 Nov 2006 11:59:39 -0500 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GpSmV-0002rx-Ch for dime@ietf.org; Wed, 29 Nov 2006 11:59:39 -0500 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 kATGrl42083609 for ; Wed, 29 Nov 2006 11:53:47 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <456DBACB.2020807@tari.toshiba.com> Date: Wed, 29 Nov 2006 11:52:27 -0500 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: dime@ietf.org Subject: Re: [Dime] Starting Work on Diameter Interop Test Cases References: <455CC708.8030601@gmx.net> In-Reply-To: <455CC708.8030601@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 an update to this effort, a new version of the interop test suite is currently available at: http://www.opendiameter.org/public/draft-fajardo-dime-interop-test-suite-02.txt The updates reflects comments from the last interop event as well as a few additional test cases. To make this document more useful for the upcoming interop event, it would be best if folks can contribute more. Especially those who will be attending the event, we need help in adding more test cases for diameter applications you are interested in testing. In case you wish to test applications not currently covered in this document, it would be great if you can contribute some test cases for those as well. If you wish to provide input pls send us (John, Hannes or myself) an email. best regards, victor > Hi all, > > at the DIME working group meeting we indicated that it would be good > to start with the preparation of the Diameter interop by working on > the diameter test cases draft to ensure that we are well prepared. > > Here is the current draft: > http://tools.ietf.org/wg/dime/draft-fajardo-dime-interop-test-suite-01.txt > > > Those people who plan to participate at the next interop and who likes > to provide input should send us (John and myself) a mail. > > Ciao > Hannes & John > > _______________________________________________ > 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 Nov 30 13:48:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpqxt-0008K0-In; Thu, 30 Nov 2006 13:48:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpqxp-0008FP-R3 for dime@ietf.org; Thu, 30 Nov 2006 13:48:53 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpquU-0003zL-Q1 for dime@ietf.org; Thu, 30 Nov 2006 13:45:28 -0500 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 <0J9K0041443NC5@usaga01-in.huawei.com> for dime@ietf.org; Thu, 30 Nov 2006 10:45:23 -0800 (PST) Received: from N737011 (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 <0J9K0091543JUC@usaga01-in.huawei.com> for dime@ietf.org; Thu, 30 Nov 2006 10:45:23 -0800 (PST) Date: Thu, 30 Nov 2006 10:45:18 -0800 From: Madjid Nakhjiri Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split In-reply-to: <6FC4416DDE56C44DA0AEE67BC7CA437111994801@zrc2hxm2.corp.nortel.com> To: 'Ahmad Muhanna' , 'Hannes Tschofenig' , dime@ietf.org Message-id: <001601c714af$aed845b0$2f01a8c0@china.huawei.com> 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: AccFKAVd+L/TzvfoRkiBKocXL0OaLAIBKB5wAeCF0FA= X-Spam-Score: 0.0 (/) 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 Ahmad, Yes, this is what is needed, that is why I called this "authorization token" when raised the issue. The authentication assurance (token) comes from AAAH-EAP in form of an attribute to the AAA client (presumably the same as the HA, although that is debatable too, if MSP and ASP are different), gets to HA, and then forwarded to the AAAH-MIP through an attribute. However, it is a bit more complicated than that, the assurance must be certified, i.e. a AAAH-EAP signature would be needed, otherwise any HA or proxy can create that token and insert it in the attribute. The AAAH-MIP must also be able to verify the AAAH-EAP signature, which means some trust relationship between AAAH-EAP and AAAH-MIP is required as well. Still a manageable problem IMO. R, Madjid -----Original Message----- From: Ahmad Muhanna [mailto:amuhanna@nortel.com] Sent: Wednesday, November 22, 2006 11:05 AM To: Hannes Tschofenig; dime@ietf.org Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split Hi all, The following is an idea that I would like to throw out as a possible solution: I believe the easiest way is for the HA to include an explicit attribute that the user has been authenticated successfully. This way, the AAAH-MIP6 have an explicit indication and record from the serving HA, regardless if it is in the Home or Visited Network. We may also require that the HA include the identity of the AAAH-EAP server which did the authentication. Comments: ?? Regards, Ahmad > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Friday, November 10, 2006 6:26 PM > To: dime@ietf.org > Subject: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split > > Hi all, > > during the DIME meeting Glen raised an important question > that impacts the design of the protocol, namely: > " > Do we need to support the scenario where the Diameter EAP > authentication and the Diameter MIPv6 authorization exchange > terminate at different servers? > " > > Currently, we assume that these two exchanges could be > terminated at different servers. As a consequence, security > concerns were raised (see slide 5 of > http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt). > > How do people think about restricting the Diameter MIPv6 > HA-to-AAAH document to terminate the authentication and > authorization exchange at the same server? > > Ciao > Hannes > > PS: Glen also suggested to consider using the Diameter MIPv6 > App-ID for the Diameter EAP exchange if we decide that both > exchanges terminate at the same server. As a consequence the > open issue described at slide 6 of > http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt > would also be resolved. The changes to the existing document > would be minimal (about 2 additional sentences). > > > _______________________________________________ > 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 Nov 30 14:02:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GprB7-0006as-En; Thu, 30 Nov 2006 14:02:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GprB6-0006an-1r for dime@ietf.org; Thu, 30 Nov 2006 14:02:36 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GprAz-0006IS-QW for dime@ietf.org; Thu, 30 Nov 2006 14:02:36 -0500 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 <0J9K004GZ4U5C5@usaga01-in.huawei.com> for dime@ietf.org; Thu, 30 Nov 2006 11:01:17 -0800 (PST) Received: from N737011 (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 <0J9K009AW4U0WI@usaga01-in.huawei.com> for dime@ietf.org; Thu, 30 Nov 2006 11:01:17 -0800 (PST) Date: Thu, 30 Nov 2006 11:01:11 -0800 From: Madjid Nakhjiri Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split In-reply-to: <5e2406980611230042n642f6d7dua442db4e7839a4e9@mail.gmail.com> To: 'Julien Bournelle' , 'Ahmad Muhanna' Message-id: <001701c714b1$e71294b0$2f01a8c0@china.huawei.com> 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: AccO22bhzBmK0HAMQwueTZWW6Cs//gF1ItMA X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 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 Actually Julien, let me explain, The issue is that since you are decoupling the authentication from authorization, during the authorization you have no assurance that the client identity has actually been authenticated. Things that cause problem are when the AAA-MIP is different from AAA_EAP, or if the AAA server does not keep any authentication state (ok for Diameter), or if the client uses a different ID for authorization (we agreed that we should not do this), or issues related to HA: 1) HA change is needed (e.g. keeping AAA_EAP ID, and other MN-authentication state to send to AAA_MIP). Currently, we are saying that the HA needs to keep state on the authentication. 2) HA must be trusted with its reporting (it does not fake an authentication that never happened), so it does not launch DoS attacks on the AAA_MIP by sending a lot of fake authorization requests. 3) HA is under attack itself, where its databases are manipulated. Now back to your options, I don't think you can sweep this under the rug. This is probably the first place in the IETF where you are separating authentication from authorization, so you will get a lot of scrutiny down the road and you cannot ignore the security issues for the scenario you are presenting (especially the separation of the AAA servers and service providers). So option 1 is out. I think we should take the issue seriously. However, I don't think the solution you present in option 2 is needed. You don't need new command modes, you simply need attributes that carry information related to a previous authentication of the MN by the AAA-EAP and this can be done by attributes. Please see my other email to Ahmad. Yes, we need to find a way to carry the new attributes, and may be that has to be through Diameter EAP, not sure, need to investigate. R, Madjid -----Original Message----- From: Julien Bournelle [mailto:julien.bournelle@gmail.com] Sent: Thursday, November 23, 2006 12:42 AM To: Ahmad Muhanna Cc: dime@ietf.org Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split HI Ahmad, thanks a lot for your review. I respond to your proposal and try to sum up a little our current situation with this highligting three different ways to move forward. On 11/22/06, Ahmad Muhanna wrote: > > Hi all, > > The following is an idea that I would like to throw out as a possible > solution: > > I believe the easiest way is for the HA to include an explicit attribute > that the user has been authenticated successfully. This way, the > AAAH-MIP6 have an explicit indication and record from the serving HA, > regardless if it is in the Home or Visited Network. We may also require > that the HA include the identity of the AAAH-EAP server which did the > authentication. > > Comments: > ?? hmm, the threat mentionned by madjid was that the HA is compromised and uses a fake AAA-EAP server. In this case, the HA would be able to send your proposed attribute. I'm not sure this solve the issue. Personnally, before solving this issue, I think we should agree or not on the fact that it si effectivily an issue. The fact that we use 4072 in AUTHENTICATE_ONLY mode for Authentication and define a new application for the Authorization/Accounting part was to avoid to update all Diameter Application using EAP for Authentication if 4072 has to be updated. As we define a new application for Authorization/Accounting, we lost the binding between Authentication and Authorization/Accounting at the AAA server. However, AAAH-EAP and AAAH-MIP6 belong to the MSA and finally the HA is now responsible of this binding. To move forward with this I see 3 options: 1/ We continue with the current approach and decide that this is not an issue if the Authz/Acctg server has no "proof" that the user has been authenticated. The HA is responsible for this. We consider that this is an issue. So we consider that the Authz/Acctg need to be bound to the Authentication. Then we have 2 options: 2/ We include DER/DEA messages in the MIP6 Application but define a new command-code. An update of 4072 would certainly lead to an update of this application. 3/ We define a generic mechanism that permits to give a proof to the AAAH-MIP6 that AAAH-EAP has correctly authenticated the user. Comments ? Let me know if you see others options. Julien > > > Regards, > Ahmad > > > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Friday, November 10, 2006 6:26 PM > > To: dime@ietf.org > > Subject: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split > > > > Hi all, > > > > during the DIME meeting Glen raised an important question > > that impacts the design of the protocol, namely: > > " > > Do we need to support the scenario where the Diameter EAP > > authentication and the Diameter MIPv6 authorization exchange > > terminate at different servers? > > " > > > > Currently, we assume that these two exchanges could be > > terminated at different servers. As a consequence, security > > concerns were raised (see slide 5 of > > http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt). > > > > How do people think about restricting the Diameter MIPv6 > > HA-to-AAAH document to terminate the authentication and > > authorization exchange at the same server? > > > > Ciao > > Hannes > > > > PS: Glen also suggested to consider using the Diameter MIPv6 > > App-ID for the Diameter EAP exchange if we decide that both > > exchanges terminate at the same server. As a consequence the > > open issue described at slide 6 of > > http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt > > would also be resolved. The changes to the existing document > > would be minimal (about 2 additional sentences). > > > > > > _______________________________________________ > > 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 Thu Nov 30 14:02:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GprB8-0006bh-P6; Thu, 30 Nov 2006 14:02:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GprB7-0006aw-Mm for dime@ietf.org; Thu, 30 Nov 2006 14:02:37 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GprB6-0006IS-5Y for dime@ietf.org; Thu, 30 Nov 2006 14:02:37 -0500 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 <0J9K004MJ4VKC5@usaga01-in.huawei.com> for dime@ietf.org; Thu, 30 Nov 2006 11:02:09 -0800 (PST) Received: from N737011 (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 <0J9K008G54VFF9@usaga01-in.huawei.com> for dime@ietf.org; Thu, 30 Nov 2006 11:02:08 -0800 (PST) Date: Thu, 30 Nov 2006 11:02:03 -0800 From: Madjid Nakhjiri Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split In-reply-to: <5e2406980611230042n642f6d7dua442db4e7839a4e9@mail.gmail.com> To: 'Julien Bournelle' , 'Ahmad Muhanna' Message-id: <001801c714b2$05c4db70$2f01a8c0@china.huawei.com> 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: AccO22bhzBmK0HAMQwueTZWW6Cs//gF1omfQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d 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 PS. I missed your 3rd option. I agree this can be a generic mechanism, but not sure about the details, can you elaborate? Madjid -----Original Message----- From: Julien Bournelle [mailto:julien.bournelle@gmail.com] Sent: Thursday, November 23, 2006 12:42 AM To: Ahmad Muhanna Cc: dime@ietf.org Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split HI Ahmad, thanks a lot for your review. I respond to your proposal and try to sum up a little our current situation with this highligting three different ways to move forward. On 11/22/06, Ahmad Muhanna wrote: > > Hi all, > > The following is an idea that I would like to throw out as a possible > solution: > > I believe the easiest way is for the HA to include an explicit attribute > that the user has been authenticated successfully. This way, the > AAAH-MIP6 have an explicit indication and record from the serving HA, > regardless if it is in the Home or Visited Network. We may also require > that the HA include the identity of the AAAH-EAP server which did the > authentication. > > Comments: > ?? hmm, the threat mentionned by madjid was that the HA is compromised and uses a fake AAA-EAP server. In this case, the HA would be able to send your proposed attribute. I'm not sure this solve the issue. Personnally, before solving this issue, I think we should agree or not on the fact that it si effectivily an issue. The fact that we use 4072 in AUTHENTICATE_ONLY mode for Authentication and define a new application for the Authorization/Accounting part was to avoid to update all Diameter Application using EAP for Authentication if 4072 has to be updated. As we define a new application for Authorization/Accounting, we lost the binding between Authentication and Authorization/Accounting at the AAA server. However, AAAH-EAP and AAAH-MIP6 belong to the MSA and finally the HA is now responsible of this binding. To move forward with this I see 3 options: 1/ We continue with the current approach and decide that this is not an issue if the Authz/Acctg server has no "proof" that the user has been authenticated. The HA is responsible for this. We consider that this is an issue. So we consider that the Authz/Acctg need to be bound to the Authentication. Then we have 2 options: 2/ We include DER/DEA messages in the MIP6 Application but define a new command-code. An update of 4072 would certainly lead to an update of this application. 3/ We define a generic mechanism that permits to give a proof to the AAAH-MIP6 that AAAH-EAP has correctly authenticated the user. Comments ? Let me know if you see others options. Julien > > > Regards, > Ahmad > > > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Friday, November 10, 2006 6:26 PM > > To: dime@ietf.org > > Subject: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split > > > > Hi all, > > > > during the DIME meeting Glen raised an important question > > that impacts the design of the protocol, namely: > > " > > Do we need to support the scenario where the Diameter EAP > > authentication and the Diameter MIPv6 authorization exchange > > terminate at different servers? > > " > > > > Currently, we assume that these two exchanges could be > > terminated at different servers. As a consequence, security > > concerns were raised (see slide 5 of > > http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt). > > > > How do people think about restricting the Diameter MIPv6 > > HA-to-AAAH document to terminate the authentication and > > authorization exchange at the same server? > > > > Ciao > > Hannes > > > > PS: Glen also suggested to consider using the Diameter MIPv6 > > App-ID for the Diameter EAP exchange if we decide that both > > exchanges terminate at the same server. As a consequence the > > open issue described at slide 6 of > > http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt > > would also be resolved. The changes to the existing document > > would be minimal (about 2 additional sentences). > > > > > > _______________________________________________ > > 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 Thu Nov 30 14:21:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GprTp-00088Q-CP; Thu, 30 Nov 2006 14:21:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GprTn-00082u-GA for dime@ietf.org; Thu, 30 Nov 2006 14:21:55 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GprTm-000067-1m for dime@ietf.org; Thu, 30 Nov 2006 14:21:55 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id kAUJEZJ08004; Thu, 30 Nov 2006 14:14:35 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split Date: Thu, 30 Nov 2006 13:21:40 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437111B07C8A@zrc2hxm2.corp.nortel.com> In-Reply-To: <001601c714af$aed845b0$2f01a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split Thread-Index: AccFKAVd+L/TzvfoRkiBKocXL0OaLAIBKB5wAeCF0FAAAViNoA== From: "Ahmad Muhanna" To: "Madjid Nakhjiri" , "Hannes Tschofenig" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b 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 Madjid, I assume that you mean the AAA-EAP signature is identical per user per session. Right? On the other hand, could you please comment on the other options I sent in response to Julien's options. Thanks. Regards, Ahmad =20 > -----Original Message----- > From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com]=20 > Sent: Thursday, November 30, 2006 12:45 PM > To: Muhanna, Ahmad (RICH1:2H10); 'Hannes Tschofenig'; dime@ietf.org > Cc: 'Madjid Nakhjiri' > Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support:=20 > Server Split >=20 > Hi Ahmad, >=20 > Yes, this is what is needed, that is why I called this=20 > "authorization token" > when raised the issue. > The authentication assurance (token) comes from AAAH-EAP in=20 > form of an attribute to the AAA client (presumably the same=20 > as the HA, although that is debatable too, if MSP and ASP are=20 > different), gets to HA, and then forwarded to the AAAH-MIP=20 > through an attribute. > However, it is a bit more complicated than that, the=20 > assurance must be certified, i.e. a AAAH-EAP signature would=20 > be needed, otherwise any HA or proxy can create that token=20 > and insert it in the attribute. > The AAAH-MIP must also be able to verify the AAAH-EAP=20 > signature, which means some trust relationship between=20 > AAAH-EAP and AAAH-MIP is required as well. > Still a manageable problem IMO. >=20 > R, >=20 > Madjid >=20 >=20 > -----Original Message----- > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > Sent: Wednesday, November 22, 2006 11:05 AM > To: Hannes Tschofenig; dime@ietf.org > Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support:=20 > Server Split >=20 >=20 > Hi all, >=20 > The following is an idea that I would like to throw out as a possible > solution: >=20 > I believe the easiest way is for the HA to include an=20 > explicit attribute > that the user has been authenticated successfully. This way, the > AAAH-MIP6 have an explicit indication and record from the serving HA, > regardless if it is in the Home or Visited Network. We may=20 > also require > that the HA include the identity of the AAAH-EAP server which did the > authentication. >=20 > Comments:=20 > ?? >=20 >=20 > Regards, > Ahmad >=20 >=20 > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > > Sent: Friday, November 10, 2006 6:26 PM > > To: dime@ietf.org > > Subject: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support:=20 > Server Split > >=20 > > Hi all, > >=20 > > during the DIME meeting Glen raised an important question=20 > > that impacts the design of the protocol, namely: > > " > > Do we need to support the scenario where the Diameter EAP=20 > > authentication and the Diameter MIPv6 authorization exchange=20 > > terminate at different servers? > > " > >=20 > > Currently, we assume that these two exchanges could be=20 > > terminated at different servers. As a consequence, security=20 > > concerns were raised (see slide 5 of=20 > > http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt). > >=20 > > How do people think about restricting the Diameter MIPv6=20 > > HA-to-AAAH document to terminate the authentication and=20 > > authorization exchange at the same server? > >=20 > > Ciao > > Hannes > >=20 > > PS: Glen also suggested to consider using the Diameter MIPv6=20 > > App-ID for the Diameter EAP exchange if we decide that both=20 > > exchanges terminate at the same server. As a consequence the=20 > > open issue described at slide 6 of=20 > > http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt=20 > > would also be resolved. The changes to the existing document=20 > > would be minimal (about 2 additional sentences). > >=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 >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Nov 30 17:37:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpuWk-0005Gv-WE; Thu, 30 Nov 2006 17:37:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpuWj-0005Et-RQ for dime@ietf.org; Thu, 30 Nov 2006 17:37:09 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpuWi-0005Mv-FM for dime@ietf.org; Thu, 30 Nov 2006 17:37:09 -0500 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 <0J9K003T8ETVD1@usaga01-in.huawei.com> for dime@ietf.org; Thu, 30 Nov 2006 14:37:07 -0800 (PST) Received: from N737011 (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 <0J9K009ZAETQVG@usaga01-in.huawei.com> for dime@ietf.org; Thu, 30 Nov 2006 14:37:07 -0800 (PST) Date: Thu, 30 Nov 2006 14:37:01 -0800 From: Madjid Nakhjiri Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split In-reply-to: <6FC4416DDE56C44DA0AEE67BC7CA437111B07C8A@zrc2hxm2.corp.nortel.com> To: 'Ahmad Muhanna' , 'Hannes Tschofenig' , dime@ietf.org Message-id: <002d01c714d0$0d95e970$2f01a8c0@china.huawei.com> 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: AccFKAVd+L/TzvfoRkiBKocXL0OaLAIBKB5wAeCF0FAAAViNoAAG5hLw X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d 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 Ahmad, Not sure what you mean by "identical", if you mean unique? Yes. As far as the other option, do you mean the HA including the id of AAA_EAP for AAA_MIP? I think that would be needed too. It could be included in the signature as well. If you mean something else, please let me know, what it was? Thanks. R, Madjid -----Original Message----- From: Ahmad Muhanna [mailto:amuhanna@nortel.com] Sent: Thursday, November 30, 2006 11:22 AM To: Madjid Nakhjiri; Hannes Tschofenig; dime@ietf.org Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split Hi Madjid, I assume that you mean the AAA-EAP signature is identical per user per session. Right? On the other hand, could you please comment on the other options I sent in response to Julien's options. Thanks. Regards, Ahmad > -----Original Message----- > From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com] > Sent: Thursday, November 30, 2006 12:45 PM > To: Muhanna, Ahmad (RICH1:2H10); 'Hannes Tschofenig'; dime@ietf.org > Cc: 'Madjid Nakhjiri' > Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: > Server Split > > Hi Ahmad, > > Yes, this is what is needed, that is why I called this > "authorization token" > when raised the issue. > The authentication assurance (token) comes from AAAH-EAP in > form of an attribute to the AAA client (presumably the same > as the HA, although that is debatable too, if MSP and ASP are > different), gets to HA, and then forwarded to the AAAH-MIP > through an attribute. > However, it is a bit more complicated than that, the > assurance must be certified, i.e. a AAAH-EAP signature would > be needed, otherwise any HA or proxy can create that token > and insert it in the attribute. > The AAAH-MIP must also be able to verify the AAAH-EAP > signature, which means some trust relationship between > AAAH-EAP and AAAH-MIP is required as well. > Still a manageable problem IMO. > > R, > > Madjid > > > -----Original Message----- > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > Sent: Wednesday, November 22, 2006 11:05 AM > To: Hannes Tschofenig; dime@ietf.org > Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: > Server Split > > > Hi all, > > The following is an idea that I would like to throw out as a possible > solution: > > I believe the easiest way is for the HA to include an > explicit attribute > that the user has been authenticated successfully. This way, the > AAAH-MIP6 have an explicit indication and record from the serving HA, > regardless if it is in the Home or Visited Network. We may > also require > that the HA include the identity of the AAAH-EAP server which did the > authentication. > > Comments: > ?? > > > Regards, > Ahmad > > > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Friday, November 10, 2006 6:26 PM > > To: dime@ietf.org > > Subject: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: > Server Split > > > > Hi all, > > > > during the DIME meeting Glen raised an important question > > that impacts the design of the protocol, namely: > > " > > Do we need to support the scenario where the Diameter EAP > > authentication and the Diameter MIPv6 authorization exchange > > terminate at different servers? > > " > > > > Currently, we assume that these two exchanges could be > > terminated at different servers. As a consequence, security > > concerns were raised (see slide 5 of > > http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt). > > > > How do people think about restricting the Diameter MIPv6 > > HA-to-AAAH document to terminate the authentication and > > authorization exchange at the same server? > > > > Ciao > > Hannes > > > > PS: Glen also suggested to consider using the Diameter MIPv6 > > App-ID for the Diameter EAP exchange if we decide that both > > exchanges terminate at the same server. As a consequence the > > open issue described at slide 6 of > > http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt > > would also be resolved. The changes to the existing document > > would be minimal (about 2 additional sentences). > > > > > > _______________________________________________ > > 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 Nov 30 20:14:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpwyY-0008Rj-75; Thu, 30 Nov 2006 20:14:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpwyX-0008RS-4h for dime@ietf.org; Thu, 30 Nov 2006 20:14:01 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpwyU-0002JQ-Lh for dime@ietf.org; Thu, 30 Nov 2006 20:14:01 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id kB116ml10163; Thu, 30 Nov 2006 20:06:49 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split Date: Thu, 30 Nov 2006 19:13:54 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437111B690DD@zrc2hxm2.corp.nortel.com> In-Reply-To: <002d01c714d0$0d95e970$2f01a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split Thread-Index: AccFKAVd+L/TzvfoRkiBKocXL0OaLAIBKB5wAeCF0FAAAViNoAAG5hLwAANg2sA= From: "Ahmad Muhanna" To: "Madjid Nakhjiri" , "Hannes Tschofenig" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a 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 Thanks Madjid.=20 Please see comments inline. Regards, Ahmad =20 > -----Original Message----- > From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com]=20 > Sent: Thursday, November 30, 2006 4:37 PM > To: Muhanna, Ahmad (RICH1:2H10); 'Hannes Tschofenig'; dime@ietf.org > Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support:=20 > Server Split >=20 > Hi Ahmad, >=20 > Not sure what you mean by "identical", if you mean unique? Yes. [Ahmad] Yep. that's exactly what I meant. > As far as the other option, do you mean the HA including the=20 > id of AAA_EAP for AAA_MIP? I think that would be needed too.=20 > It could be included in the signature as well. If you mean=20 > something else, please let me know, what it was? Thanks. [Ahmad] The other option basically is to facilitate to the HA to communicate Authorization request with the same server which performed the EAP-Authentication (which also support AAA-MIP6), I understand that requires maintaining a state at the AAA-EAP server and minor changes on the HA side; What do you think, is that an option? Thanks again. Ahmad > > R, >=20 > Madjid >=20 > -----Original Message----- > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > Sent: Thursday, November 30, 2006 11:22 AM > To: Madjid Nakhjiri; Hannes Tschofenig; dime@ietf.org > Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support:=20 > Server Split >=20 > Hi Madjid, >=20 > I assume that you mean the AAA-EAP signature is identical per=20 > user per session. Right? > On the other hand, could you please comment on the other=20 > options I sent in response to Julien's options. Thanks. >=20 > Regards, > Ahmad > =20 >=20 > > -----Original Message----- > > From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com] > > Sent: Thursday, November 30, 2006 12:45 PM > > To: Muhanna, Ahmad (RICH1:2H10); 'Hannes Tschofenig'; dime@ietf.org > > Cc: 'Madjid Nakhjiri' > > Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support:=20 > > Server Split > >=20 > > Hi Ahmad, > >=20 > > Yes, this is what is needed, that is why I called this=20 > "authorization=20 > > token" > > when raised the issue. > > The authentication assurance (token) comes from AAAH-EAP in=20 > form of an=20 > > attribute to the AAA client (presumably the same as the HA,=20 > although=20 > > that is debatable too, if MSP and ASP are different), gets=20 > to HA, and=20 > > then forwarded to the AAAH-MIP through an attribute. > > However, it is a bit more complicated than that, the=20 > assurance must be=20 > > certified, i.e. a AAAH-EAP signature would be needed,=20 > otherwise any HA=20 > > or proxy can create that token and insert it in the attribute. > > The AAAH-MIP must also be able to verify the AAAH-EAP=20 > signature, which=20 > > means some trust relationship between AAAH-EAP and AAAH-MIP is=20 > > required as well. > > Still a manageable problem IMO. > >=20 > > R, > >=20 > > Madjid > >=20 > >=20 > > -----Original Message----- > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > Sent: Wednesday, November 22, 2006 11:05 AM > > To: Hannes Tschofenig; dime@ietf.org > > Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support:=20 > > Server Split > >=20 > >=20 > > Hi all, > >=20 > > The following is an idea that I would like to throw out as=20 > a possible > > solution: > >=20 > > I believe the easiest way is for the HA to include an explicit=20 > > attribute that the user has been authenticated=20 > successfully. This way,=20 > > the > > AAAH-MIP6 have an explicit indication and record from the=20 > serving HA,=20 > > regardless if it is in the Home or Visited Network. We may also=20 > > require that the HA include the identity of the AAAH-EAP=20 > server which=20 > > did the authentication. > >=20 > > Comments:=20 > > ?? > >=20 > >=20 > > Regards, > > Ahmad > >=20 > >=20 > > > -----Original Message----- > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > Sent: Friday, November 10, 2006 6:26 PM > > > To: dime@ietf.org > > > Subject: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support:=20 > > Server Split > > >=20 > > > Hi all, > > >=20 > > > during the DIME meeting Glen raised an important question that=20 > > > impacts the design of the protocol, namely: > > > " > > > Do we need to support the scenario where the Diameter EAP=20 > > > authentication and the Diameter MIPv6 authorization exchange=20 > > > terminate at different servers? > > > " > > >=20 > > > Currently, we assume that these two exchanges could be=20 > terminated at=20 > > > different servers. As a consequence, security concerns=20 > were raised=20 > > > (see slide 5 of=20 > > > http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt). > > >=20 > > > How do people think about restricting the Diameter MIPv6=20 > HA-to-AAAH=20 > > > document to terminate the authentication and=20 > authorization exchange=20 > > > at the same server? > > >=20 > > > Ciao > > > Hannes > > >=20 > > > PS: Glen also suggested to consider using the Diameter=20 > MIPv6 App-ID=20 > > > for the Diameter EAP exchange if we decide that both exchanges=20 > > > terminate at the same server. As a consequence the open issue=20 > > > described at slide 6 of=20 > > > http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt > > > would also be resolved. The changes to the existing=20 > document would=20 > > > be minimal (about 2 additional sentences). > > >=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 > >=20 > >=20 >=20 >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime