From dime-bounces@ietf.org Mon Jan 01 07:05:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1LvL-0008Ea-Um; Mon, 01 Jan 2007 07:05:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1LvK-0008Du-JN for dime@ietf.org; Mon, 01 Jan 2007 07:05:50 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H1LvJ-0000mv-6T for dime@ietf.org; Mon, 01 Jan 2007 07:05:50 -0500 Received: (qmail invoked by alias); 01 Jan 2007 12:05:47 -0000 Received: from p54985848.dip.t-dialin.net (EHLO [192.168.2.32]) [84.152.88.72] by mail.gmx.net (mp032) with SMTP; 01 Jan 2007 13:05:47 +0100 X-Authenticated: #29516787 Message-ID: <4598F92C.3060801@gmx.net> Date: Mon, 01 Jan 2007 13:06:04 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: Ulf Bodin , Tolga Asveren References: <33656995C5C5094A983DE84DA649A924CB5559@lulex02.ad.operax.com> In-Reply-To: <33656995C5C5094A983DE84DA649A924CB5559@lulex02.ad.operax.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: 93238566e09e6e262849b4f805833007 Cc: dime@ietf.org Subject: [Dime] The Auditing Problem 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 Ulf, Hi Tolga, I think that the discussion triggered by Tolga was quite helpful in order to get a better understanding of the auditing work. What I would like to see is a more detailed example scenario (possibly with message flows). Tolga provided a scenario with a figure but it needs to be enhanced when it comes to the "service logic functionality". I think that this is important since there is a front-end and a back-end part to the entire story. The TISPAN QoS scenario has been mentioned as a potential customer of this work and it could be a nice example to see how the failure cases happen and how state is requested and moved around. I can imagine that there are a number of issues that need to be discussed when we jump into the details. I have also noticed that a number of terms are used without clearly describing them. For example, there are a number of different failover cases that need more description to ensure that we are on the same page. Another example: What is the definition for "session leaking"? Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jan 01 07:52:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1Mei-0002TP-GD; Mon, 01 Jan 2007 07:52:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1Meh-0002S3-2h for dime@ietf.org; Mon, 01 Jan 2007 07:52:43 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H1Mec-000567-L2 for dime@ietf.org; Mon, 01 Jan 2007 07:52:43 -0500 Received: (qmail invoked by alias); 01 Jan 2007 12:52:36 -0000 Received: from p54985848.dip.t-dialin.net (EHLO [192.168.2.32]) [84.152.88.72] by mail.gmx.net (mp026) with SMTP; 01 Jan 2007 13:52:36 +0100 X-Authenticated: #29516787 Message-ID: <45990425.1020505@gmx.net> Date: Mon, 01 Jan 2007 13:52:53 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: aaa-wg@merit.edu, dime@ietf.org, radiusext@ops.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: c1c65599517f9ac32519d043c37c5336 Cc: Subject: [Dime] Reminder: Diameter Interop 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 Please don't forget to register! -------- Original Message -------- Subject: Upcoming Diameter Interop Date: Fri, 8 Dec 2006 16:05:06 +0100 From: Tschofenig, Hannes To: , Hi all, our interop event planning is finished. WHAT? Diameter Interoperability Event Further information regarding agenda, test framework, venue and travel information as well as on-line registration are available at: http://www.diameterinterop.com WHEN? January 29 - February 2, 2007 WHERE? Orlando, Florida (hosted by IntelliNet Technologies) WHO? Companies implementing Diameter, Diameter extensions and Diameter applications A copy-and-paste from the press announcement: " The Diameter Interoperability Event provides an excellent opportunity for vendors of the Diameter protocol and applications to test their implementations in a friendly setting and get a better understanding of the protocol behavior. Discussions with peers and the experts from DiME provide a forum to realize an industry leading implementation. We are expecting a substantial number of participating companies and products, including the base protocol from several vendors as well as a broad range of applications using the protocol. This offers you the opportunity to further refine your own products and assure their interoperability. " IMPORTANT: Please register at http://www.diameterinterop.com (deadline: January 15, 2007) Ciao Hannes & John _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jan 01 11:22:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1PvT-0004th-Kd; Mon, 01 Jan 2007 11:22:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1PvS-0004tW-Fv for dime@ietf.org; Mon, 01 Jan 2007 11:22:14 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H1PvR-0003zc-2R for dime@ietf.org; Mon, 01 Jan 2007 11:22:14 -0500 Received: (qmail invoked by alias); 01 Jan 2007 16:22:11 -0000 Received: from p54985848.dip.t-dialin.net (EHLO [192.168.2.32]) [84.152.88.72] by mail.gmx.net (mp046) with SMTP; 01 Jan 2007 17:22:11 +0100 X-Authenticated: #29516787 Message-ID: <45993543.7060601@gmx.net> Date: Mon, 01 Jan 2007 17:22:27 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b1 (Windows/20061206) 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: cf4fa59384e76e63313391b70cd0dd25 Subject: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Security X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, it seems that we came across a security issue that requires more thoughts. Interestingly, David Nelson gave a presentation at the IETF#66 meeting that dealt with a similar problem when RADIUS is used in the ISMS context. You can find his presentation here: http://www3.ietf.org/proceedings/06jul/slides/radext-7/sld1.htm We need to investigate the potential security threats in more detail before we immediately jump to the solution space. Who has time and would be interested to brainstorm about this subject a little bit? The goal is to have a more detailed description of the security threats. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jan 03 00:58:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1z8f-00060A-5R; Wed, 03 Jan 2007 00:58:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1z8d-0005va-V2 for dime@ietf.org; Wed, 03 Jan 2007 00:58:11 -0500 Received: from [59.145.147.70] (helo=ricky.india.internal.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1z8b-0003uf-Rx for dime@ietf.org; Wed, 03 Jan 2007 00:58:11 -0500 X-Anti-Virus: Cyberoam Anti-Virus for SMTP; Kaspersky 5.5.3/RELEASE, bases: 03012007 #241332; status: clean Received: from klk ([172.16.2.32]) by ricky.india.internal.net (8.12.10/8.11.6) with ESMTP id l035iZPX020865; Wed, 3 Jan 2007 11:14:36 +0530 From: "kamakshi" To: "'Preeti Shandilya'" , Subject: RE: [Dime] AVP code for 3GPP-charging Id AVP Date: Wed, 3 Jan 2007 11:30:44 +0530 Message-ID: <000001c72efc$83092780$200210ac@klk> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Spam-Score: 0.2 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0294961230==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0294961230== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C72F2A.9CC4E5F0" This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C72F2A.9CC4E5F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Hi Preeti, The AVP code for 3GPP-Charging-Id is 2. It is defined in =93GPP TS = 29.061 V7.2.0 (2006-12)=94 =20 Regards, Kamakshi =20 =20 -----Original Message----- From: Preeti Shandilya [mailto:preeti.shandilya@aricent.com]=20 Sent: Friday, December 22, 2006 2:22 PM To: dime@ietf.org Subject: [Dime] AVP code for 3GPP-charging Id AVP =20 Hi !=20 Can someone tell me the AVP code for 3GPP-charging Id AVP. Also specification number in which it is mentioned=20 Regards=20 Preeti. *********************** Aricent-Unclassified *********************** ------=_NextPart_000_0001_01C72F2A.9CC4E5F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

Hi Preeti,

=A0The AVP code for 3GPP-Charging-Id is 2. It is defined in “GPP TS = 29.061 V7.2.0 (2006-12)”

 

Regards,

Kamakshi

 

 

-----Original = Message-----
From: Preeti Shandilya [mailto:preeti.shandilya@aricent.com]
Sent: Friday, December = 22, 2006 2:22 PM
To: dime@ietf.org
Subject: [Dime] AVP code = for 3GPP-charging Id AVP

 


Hi !

Can someone tell me the AVP code for 3GPP-charging Id AVP. Also = specification number in which it is mentioned

Regards
Preeti.

***********************  Aricent-Unclassified   ***********************

------=_NextPart_000_0001_01C72F2A.9CC4E5F0-- --===============0294961230== 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 --===============0294961230==-- From dime-bounces@ietf.org Wed Jan 03 01:46:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1ztO-0004ws-QP; Wed, 03 Jan 2007 01:46:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1ztO-0004wk-7C for dime@ietf.org; Wed, 03 Jan 2007 01:46:30 -0500 Received: from [59.145.147.70] (helo=ricky.india.internal.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1ztM-0003Ll-Dy for dime@ietf.org; Wed, 03 Jan 2007 01:46:30 -0500 X-Anti-Virus: Cyberoam Anti-Virus for SMTP; Kaspersky 5.5.3/RELEASE, bases: 03012007 #241343; status: clean Received: from hemant ([172.16.12.212]) by ricky.india.internal.net (8.12.10/8.11.6) with SMTP id l036XOPX024338 for ; Wed, 3 Jan 2007 12:03:24 +0530 Message-ID: <008501c72f04$46a4d250$d40c10ac@india.internal.net> From: "Hemant" To: Date: Wed, 3 Jan 2007 12:26:15 +0530 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [Dime] RFC 4004 Missing AVP Code and definition 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 would appreciate if anybody can provide some information on this. Thanks and Regards, Hemant Bhatnagar Software Engineer IntelliNet Technologies India Pvt. Ltd. Accelerating Convergence hbhatnagar@intellinet-india.com 413/4 Oxford Towers, 139 Airport Road, Bangalore - 560 017 Off-Phone.....: + 91 80 51256018 Ext: 2311 Off - Fax.......: + 91 80 25202947 ----- Original Message ----- From: Hemant To: dime@ietf.org ; dime-request@ietf.org Cc: imsdia@intellinet-india.com Sent: Tuesday, December 26, 2006 12:40 PM Subject: Missing AVP Code and definition Hi All, In RFC 4004 there are some AVPs which have reference in the specification but are not declared formally with AVP code. Following are the AVP's: 1. MIP-HA-to-MN-SPI used in the Grouped AVP MIP-HA-to-MN-MSA. 2. MIP-MN-FA-SPI used in the Grouped AVP MIP-MN-to-FA-MSA. 3. MIP-MN-HA-SPI used in the Grouped AVP MIP-MN-to-HA-MSA. Are they defined in some other RFC or do we have to use internally defined values for them? Thanks in Advance. Regards, Hemant Bhatnagar Software Engineer IntelliNet Technologies India Pvt. Ltd. Accelerating Convergence hbhatnagar@intellinet-india.com 413/4 Oxford Towers, 139 Airport Road, Bangalore - 560 017 Off-Phone.....: + 91 80 51256018 Ext: 2311 Off - Fax.......: + 91 80 25202947 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jan 03 03:12:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H21En-0000Kz-HJ; Wed, 03 Jan 2007 03:12:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H21El-0000Ku-Vu for dime@ietf.org; Wed, 03 Jan 2007 03:12:39 -0500 Received: from nf-out-0910.google.com ([64.233.182.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H21Ek-0000xD-N1 for dime@ietf.org; Wed, 03 Jan 2007 03:12:39 -0500 Received: by nf-out-0910.google.com with SMTP id l36so5205099nfa for ; Wed, 03 Jan 2007 00:12:37 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=dj6tL42WSwvOJyPy58G9yv2Wwknyzf0ELyJ2sRBnhuSnlWd+ymQeHcFs4aKOimxBfcSATl0IQNMrSF1Xg6KxoEqkyNJeXOyKaQZle2s710vEiAD+s5c0oItiSchTulUT5dglpxbeYua98Gpd1eruHZ8IiAryGX419apB9Hk0Ctg= Received: by 10.82.107.15 with SMTP id f15mr1728675buc.1167811957473; Wed, 03 Jan 2007 00:12:37 -0800 (PST) Received: by 10.82.170.17 with HTTP; Wed, 3 Jan 2007 00:12:37 -0800 (PST) Message-ID: <9addac050701030012k655e1bf5p8e4525e647d690c8@mail.gmail.com> Date: Wed, 3 Jan 2007 13:42:37 +0530 From: "Himanshu Rawat" To: dime@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Dime] Ro or CCA 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="===============1175873218==" Errors-To: dime-bounces@ietf.org --===============1175873218== Content-Type: multipart/alternative; boundary="----=_Part_197147_27297080.1167811957459" ------=_Part_197147_27297080.1167811957459 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I'm trying to find out the answers of below questions. Please can anyone answer them. 1) Which one to use for "real-time, on-line, prepaid services". Ro or CCA?? and why? 2) AVPs for SMS and circuit-switched voice calls in Ro and CCA?. 3) Rating related AVPS in Ro and CCA? Thanks -- Himanshu Rawat ------=_Part_197147_27297080.1167811957459 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

I'm trying to find out the answers of below questions. Please can anyone answer them.

1) Which one to use for "real-time, on-line, prepaid services". Ro or CCA?? and why?

2) AVPs for SMS and circuit-switched voice calls in Ro and CCA?.

3) Rating related AVPS in Ro and CCA?


Thanks
--
Himanshu Rawat ------=_Part_197147_27297080.1167811957459-- --===============1175873218== 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 --===============1175873218==-- From dime-bounces@ietf.org Wed Jan 03 23:18:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2K3W-0005y8-QT; Wed, 03 Jan 2007 23:18:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2K3V-0005xy-PE for dime@ietf.org; Wed, 03 Jan 2007 23:18:17 -0500 Received: from jaguar.hughesbpo.net ([61.246.186.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2K3S-00056n-Ru for dime@ietf.org; Wed, 03 Jan 2007 23:18:17 -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 l044JZEO018579 for ; Thu, 4 Jan 2007 09:49:35 +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 l044JXsT018550; Thu, 4 Jan 2007 09:49:34 +0530 In-Reply-To: <000001c72efc$83092780$200210ac@klk> To: "kamakshi" Subject: RE: [Dime] AVP code for 3GPP-charging Id AVP MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Preeti Shandilya Date: Thu, 4 Jan 2007 09:52:24 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.5.5|November 30, 2005) at 04/01/2007 09:52:04 AM, Serialize complete at 04/01/2007 09:52:05 AM, Serialize by Router on Sandesh/HSS(Release 6.5.5|November 30, 2005) at 04/01/2007 09:52:05 AM X-Spam-Score: 0.1 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 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="===============0149021624==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============0149021624== Content-Type: multipart/alternative; boundary="=_alternative 0017C1EB65257259_=" This is a multipart message in MIME format. --=_alternative 0017C1EB65257259_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi=20Kamakshi=0D=0A=0D=0AThanks=20for=20the=20response=0D=0ADo=20you=20fi= nd=20AVP=20code=20for=20following=20AVPs=20as=20well=0D=0AAPN=20Info=20an= d=20=20SGSN-PLMN-Id=20.=0D=0A=0D=0AThese=20AVPs=20are=20used=20in=20PS-In= formation=20AVP=2032299-650=0D=0A=0D=0ARegards=0D=0APreeti.=0D=0A=0D=0A= =0D=0A=0D=0A=0D=0A"kamakshi"=20=20=0D=0A= 01/03/2007=2011:30=20AM=0D=0A=0D=0A=0D=0ATo=0D=0APreeti=20Shandilya/HSS@H= SS,=20=0D=0Acc=0D=0A=0D=0ASubject=0D=0ARE:=20[Dime]=20AVP= =20code=20for=203GPP-charging=20Id=20AVP=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D= =0A=0D=0A=20=0D=0AHi=20Preeti,=0D=0A=20The=20AVP=20code=20for=203GPP-Char= ging-Id=20is=202.=20It=20is=20defined=20in=20?GPP=20TS=2029.061=20=0D=0AV= 7.2.0=20(2006-12)?=0D=0A=20=0D=0ARegards,=0D=0AKamakshi=0D=0A=20=0D=0A=20= =0D=0A-----Original=20Message-----=0D=0AFrom:=20Preeti=20Shandilya=20[mai= lto:preeti.shandilya@aricent.com]=20=0D=0ASent:=20Friday,=20December=2022= ,=202006=202:22=20PM=0D=0ATo:=20dime@ietf.org=0D=0ASubject:=20[Dime]=20AV= P=20code=20for=203GPP-charging=20Id=20AVP=0D=0A=20=0D=0A=0D=0AHi=20!=20= =0D=0A=0D=0ACan=20someone=20tell=20me=20the=20AVP=20code=20for=203GPP-cha= rging=20Id=20AVP.=20Also=20=0D=0Aspecification=20number=20in=20which=20it= =20is=20mentioned=20=0D=0A=0D=0ARegards=20=0D=0APreeti.=0D=0A=0D=0A******= *****************=20=20Aricent-Unclassified=20=20=20*********************= **=0D=0A_______________________________________________=0D=0ADiME=20maili= ng=20list=0D=0ADiME@ietf.org=0D=0Ahttps://www1.ietf.org/mailman/listinfo/= dime=0D=0A=0D=0A=0D=0A=0D=0A***********************=20=20Aricent-=20Confi= dential=20=20=20***********************=0D=0A"DISCLAIMER:=20This=20messag= e=20is=20proprietary=20to=20Aricent=20=20and=20is=20intended=20solely=20f= or=20the=20use=20of=20=0Athe=20individual=20to=20whom=20it=20is=20address= ed.=20It=20may=20contain=20privileged=20or=20confidential=20information= =20and=20should=20not=20be=20=0Acirculated=20or=20used=20for=20any=20purp= ose=20other=20than=20for=20what=20it=20is=20intended.=20If=20you=20have= =20received=20this=20message=20in=20error,=20=0Aplease=20notify=20the=20o= riginator=20immediately.=20If=20you=20are=20not=20the=20intended=20recipi= ent,=20you=20are=20notified=20that=20you=20are=20strictly=0Aprohibited=20= from=20using,=20copying,=20altering,=20or=20disclosing=20the=20contents= =20of=20this=20message.=20Aricent=20accepts=20no=20responsibility=20for= =20=0Aloss=20or=20damage=20arising=20from=20the=20use=20of=20the=20inform= ation=20transmitted=20by=20this=20email=20including=20damage=20from=20vir= us."=0A --=_alternative 0017C1EB65257259_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0D=0A
Hi=20Kamakshi=0D=0A=0D=0A
Thanks=20for=20the=20respons= e=0D=0A
Do=20you=20find=20AVP= =20code=20for=20following=20AVPs=20as=0D=0Awell=0D=0A
APN=20Info=20and=20 SGSN-PLMN-Id=20.= =0D=0A
=0D=0A
These=20AVPs=20are= =20used=20in=20PS-Information=20AVP=0D=0A32299-650=0D=0A
=0D=0A=
Regards=0D=0A
Preeti.=0D=0A
=0D=0A
=0D=0A
=0D=0A=
=0D=0A=0D=0A=0D=0A"kamakshi"=20= <kamakshilk@intellinet-india.com>=0D=0A=0D=0A

01/03/2007=2011:30=20AM=0D=0A
= =0D=0A=0D=0A=0D=0A=0D=0A= =0D=0ATo=0D=0AP= reeti=20Shandilya/HSS@HSS,=0D=0A<dime@ietf.org>=0D=0A=0D= =0A=0D=0A= cc=0D=0A=0D=0A=0D=0A=0D=0ASubject= =0D=0ARE:=20[Di= me]=20AVP=20code=20for=203GPP-charging=0D=0AId=20AVP=0D=0A=
=0D=0A=0D=0A=0D=0A
=0D=0A
=0D= =0A
=0D=0A
=0D=0A
=0D=0A
 =0D=0A

Hi=20Preeti,=0D=0A

 The=20AVP=20code=20for=203GPP-Charg= ing-Id=0D=0Ais=202.=20It=20is=20defined=20in=20“GPP=20TS=2029.061= =20V7.2.0=20(2006-12)”=0D=0A

 =0D=0A

Regards,=0D=0A

Kamakshi=0D=0A

 =0D=0A

 =0D=0A

-----Original=20Message-----
=0D=0AFrom:=20Pree= ti=20Shandilya=20[mailto:preeti.shandilya@aricent.com]=20
=0D=0ASen= t:=20Friday,=20December=2022,=202006=202:22=20PM
=0D=0ATo:= =20dime@ietf.org
=0D=0ASubject:=20[Dime]=20AVP=20code=20for=203= GPP-charging=20Id=20AVP=0D=0A

 =0D=0A


=0D=0AHi=20!=20
=0D=0A
=0D=0ACan=20someone=20tell=20me=20the= =20AVP=20code=20for=203GPP-charging=20Id=20AVP.=20Also=20specification=0D= =0Anumber=20in=20which=20it=20is=20mentioned=20=0D=0A
=0D=0ARegards=20=0D=0APreeti.
=0D=0A
=0D=0A***********************=20 Aricen= t-Unclassified=20 =20***********************= _______________________________________________
=0D=0ADiME=20maili= ng=20list
=0D=0ADiME@ietf.org
=0D=0Ahttps://www1.ietf.org/mailman/l= istinfo/dime
=0D=0A=0D=0A


=0D=0A
=0D=0A***********************=20 Aricent-=20C= onfidential=20 =20***********************=0D=0A
"DISCLAIMER:=20This=20m=
essage=20is=20proprietary=20to=20Aricent=20=20and=20is=20intended=20solel=
y=20for=20the=20use=20of=20=0Athe=20individual=20to=20whom=20it=20is=20ad=
dressed.=20It=20may=20contain=20privileged=20or=20confidential=20informat=
ion=20and=20should=20not=20be=20=0Acirculated=20or=20used=20for=20any=20p=
urpose=20other=20than=20for=20what=20it=20is=20intended.=20If=20you=20hav=
e=20received=20this=20message=20in=20error,=20=0Aplease=20notify=20the=20=
originator=20immediately.=20If=20you=20are=20not=20the=20intended=20recip=
ient,=20you=20are=20notified=20that=20you=20are=20strictly=0Aprohibited=
=20from=20using,=20copying,=20altering,=20or=20disclosing=20the=20content=
s=20of=20this=20message.=20Aricent=20accepts=20no=20responsibility=20for=
=20=0Aloss=20or=20damage=20arising=20from=20the=20use=20of=20the=20inform=
ation=20transmitted=20by=20this=20email=20including=20damage=20from=20vir=
us."=0A
--=_alternative 0017C1EB65257259_=-- --===============0149021624== 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 --===============0149021624==-- From dime-bounces@ietf.org Wed Jan 03 23:58:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2KgD-0004r5-Vu; Wed, 03 Jan 2007 23:58:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2KgD-0004qp-7Q for dime@ietf.org; Wed, 03 Jan 2007 23:58:17 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2KgB-00010W-No for dime@ietf.org; Wed, 03 Jan 2007 23:58:17 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l044uqYw017360; Thu, 4 Jan 2007 06:57:09 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 06:57:11 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 06:57:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Ro or CCA Date: Thu, 4 Jan 2007 06:57:14 +0200 Message-ID: In-Reply-To: <9addac050701030012k655e1bf5p8e4525e647d690c8@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Ro or CCA Thread-Index: AccvDxWsFZMAUpIWSDytBp0h+3WzCQArZMgw From: To: , X-OriginalArrivalTime: 04 Jan 2007 04:57:10.0977 (UTC) FILETIME=[CB046B10:01C72FBC] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1241322267==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1241322267== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C72FBC.CAB2C9CF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C72FBC.CAB2C9CF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is probably the wrong forum to ask this. Ro is defined by 3GPP, DCCA is defined here. Someone else can speak to the relationship to the specs for Ro and DCCA. =20 =20 John ________________________________ From: ext Himanshu Rawat [mailto:himanshu.rawat@gmail.com]=20 Sent: 03 January, 2007 10:13 To: dime@ietf.org Subject: [Dime] Ro or CCA =09 =09 Hi, =09 I'm trying to find out the answers of below questions. Please can anyone answer them. =09 1) Which one to use for "real-time, on-line, prepaid services". Ro or CCA?? and why? =09 2) AVPs for SMS and circuit-switched voice calls in Ro and CCA?. =09 3) Rating related AVPS in Ro and CCA? =09 =09 Thanks --=20 Himanshu Rawat=20 ------_=_NextPart_001_01C72FBC.CAB2C9CF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is probably the wrong forum to ask = this.  Ro is=20 defined by 3GPP, DCCA is defined here.  Someone else can speak to = the=20 relationship to the specs for Ro and DCCA. 
 
John

From: ext Himanshu Rawat=20 [mailto:himanshu.rawat@gmail.com]
Sent: 03 January, 2007=20 10:13
To: dime@ietf.org
Subject: [Dime] Ro or=20 CCA

Hi,

I'm trying to find out the answers of below = questions.=20 Please can anyone answer them.

1) Which one to use for = "real-time,=20 on-line, prepaid services". Ro or CCA?? and why?

2) AVPs for = SMS and=20 circuit-switched voice calls in Ro and CCA?.

3) Rating related = AVPS in=20 Ro and CCA?


Thanks
--
Himanshu Rawat=20 ------_=_NextPart_001_01C72FBC.CAB2C9CF-- --===============1241322267== 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 --===============1241322267==-- From dime-bounces@ietf.org Thu Jan 04 01:36:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2MDO-0003hC-UL; Thu, 04 Jan 2007 01:36:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2MDN-0003gs-J3 for dime@ietf.org; Thu, 04 Jan 2007 01:36:37 -0500 Received: from [59.145.147.70] (helo=ricky.india.internal.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2MDK-0008Gn-0M for dime@ietf.org; Thu, 04 Jan 2007 01:36:37 -0500 X-Anti-Virus: Cyberoam Anti-Virus for SMTP; Kaspersky 5.5.3/RELEASE, bases: 04012007 #241588; status: clean Received: from klk ([172.16.2.32]) by ricky.india.internal.net (8.12.10/8.11.6) with ESMTP id l046MWPX024958; Thu, 4 Jan 2007 11:52:42 +0530 From: "kamakshi" To: "'Preeti Shandilya'" Subject: RE: [Dime] AVP code for 3GPP-charging Id AVP Date: Thu, 4 Jan 2007 12:08:32 +0530 Message-ID: <004a01c72fca$fa9a1650$200210ac@klk> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: 04b84659b2acb599bee006e63124a606 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="===============2048985956==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============2048985956== Content-Type: multipart/alternative; boundary="----=_NextPart_000_004B_01C72FF9.14525250" This is a multi-part message in MIME format. ------=_NextPart_000_004B_01C72FF9.14525250 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Hi Preeti, These AVPs have been removed from PS-Information AVP from Release6.6 onwards. May be you can find them in 32.251 which is for PS domain charging. =20 Regards, Kamakshi =20 =20 -----Original Message----- From: Preeti Shandilya [mailto:preeti.shandilya@aricent.com]=20 Sent: Thursday, January 04, 2007 9:52 AM To: kamakshi Cc: dime@ietf.org Subject: RE: [Dime] AVP code for 3GPP-charging Id AVP =20 Hi Kamakshi=20 Thanks for the response=20 Do you find AVP code for following AVPs as well=20 APN Info and SGSN-PLMN-Id .=20 These AVPs are used in PS-Information AVP 32299-650=20 Regards=20 Preeti.=20 "kamakshi" =20 01/03/2007 11:30 AM=20 To Preeti Shandilya/HSS@HSS, =20 cc =20 Subject RE: [Dime] AVP code for 3GPP-charging Id AVP =20 =20 =20 =20 Hi Preeti,=20 The AVP code for 3GPP-Charging-Id is 2. It is defined in =93GPP TS = 29.061 V7.2.0 (2006-12)=94=20 =20 Regards,=20 Kamakshi=20 =20 =20 -----Original Message----- From: Preeti Shandilya [mailto:preeti.shandilya@aricent.com]=20 Sent: Friday, December 22, 2006 2:22 PM To: dime@ietf.org Subject: [Dime] AVP code for 3GPP-charging Id AVP=20 =20 Hi !=20 Can someone tell me the AVP code for 3GPP-charging Id AVP. Also specification number in which it is mentioned=20 Regards=20 Preeti. *********************** Aricent-Unclassified ***********************_______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime *********************** Aricent- Confidential *********************** "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of=20 the individual to whom it is addressed. It may contain privileged or confidential information and should not be=20 circulated or used for any purpose other than for what it is intended. If you have received this message in error,=20 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=20 loss or damage arising from the use of the information transmitted by this email including damage from virus." =20 ------=_NextPart_000_004B_01C72FF9.14525250 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

Hi = Preeti,

These AVPs have been removed from PS-Information AVP from Release6.6 onwards.

May be you can find them in 32.251 = which is for PS domain charging.

 

Regards,

Kamakshi

 

 

-----Original = Message-----
From: Preeti Shandilya [mailto:preeti.shandilya@aricent.com]
Sent: Thursday, January = 04, 2007 9:52 AM
To: kamakshi
Cc: dime@ietf.org
Subject: RE: [Dime] AVP = code for 3GPP-charging Id AVP

 


Hi Kamakshi

Thanks for the response
Do you find AVP code for following AVPs as well
APN Info and  SGSN-PLMN-Id .

These AVPs are used in PS-Information AVP 32299-650

Regards
Preeti.


"kamakshi" <kamakshilk@intellinet-india.com> =

01/03/2007 11:30 AM

To

Preeti Shandilya/HSS@HSS, <dime@ietf.org>

cc

 

Subject

RE: [Dime] AVP code for 3GPP-charging = Id AVP

 

 

 




 

Hi = Preeti,

 The AVP = code for 3GPP-Charging-Id is 2. It is defined in “GPP TS 29.061 V7.2.0 (2006-12)”

 

Regards,

Kamakshi

 

 

-----Original Message-----
From: Preeti Shandilya [mailto:preeti.shandilya@aricent.com] =
Sent: Friday, December 22, 2006 2:22 PM
To: dime@ietf.org
Subject: [Dime] AVP code for 3GPP-charging Id = AVP

 


Hi !

Can someone tell me the AVP code for 3GPP-charging Id AVP. Also = specification number in which it is mentioned

Regards
Preeti.

***********************  Aricent-Unclassified   ***********************______________________________________________= _
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime



***********************  Aricent- Confidential   *********************** 

"DISCLAIMER: This message is proprietary to =
Aricent=A0 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."

 

------=_NextPart_000_004B_01C72FF9.14525250-- --===============2048985956== 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 --===============2048985956==-- From dime-bounces@ietf.org Thu Jan 04 01:42:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2MJM-0006rb-Bc; Thu, 04 Jan 2007 01:42:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2MJK-0006rT-RB for dime@ietf.org; Thu, 04 Jan 2007 01:42:46 -0500 Received: from jaguar.hughesbpo.net ([61.246.186.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2MJI-0001gS-QG for dime@ietf.org; Thu, 04 Jan 2007 01:42:46 -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 l046i7C1029883 for ; Thu, 4 Jan 2007 12:14:07 +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 l046i48L029852; Thu, 4 Jan 2007 12:14:05 +0530 In-Reply-To: <004a01c72fca$fa9a1650$200210ac@klk> To: "kamakshi" Subject: RE: [Dime] AVP code for 3GPP-charging Id AVP MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Preeti Shandilya Date: Thu, 4 Jan 2007 12:16:55 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.5.5|November 30, 2005) at 04/01/2007 12:16:37 PM, Serialize complete at 04/01/2007 12:16:37 PM X-Spam-Score: 0.1 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af 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="===============0378720575==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============0378720575== Content-Type: multipart/alternative; boundary="=_alternative 0024FD5865257259_=" This is a multipart message in MIME format. --=_alternative 0024FD5865257259_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi=20Kamakshi=20!=0D=0A=0D=0AYou=20are=20correct=20that=20these=20APIs=20= have=20been=20removed=20from=20Release=206.6=20onward.=20=0D=0ABut=20sinc= e=20they=20are=20present=20in=206.5,=20a=20node=20complying=20to=206.5=20= may=20send=20these=20=0D=0AAVPs=20as=20well.=20I=20could=20not=20find=20t= hese=20defined=20in=2032.251=0D=0A=0D=0ARegards=0D=0APreeti=0D=0A=0D=0A= =0D=0A=0D=0A"kamakshi"=20=20=0D=0A01/04/= 2007=2012:08=20PM=0D=0A=0D=0A=0D=0ATo=0D=0APreeti=20Shandilya/HSS@HSS=0D= =0Acc=0D=0A=0D=0ASubject=0D=0ARE:=20[Dime]=20AVP=20code=20= for=203GPP-charging=20Id=20AVP=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A= =20=0D=0AHi=20Preeti,=0D=0AThese=20AVPs=20have=20been=20removed=20from=20= PS-Information=20AVP=20from=20Release6.6=20=0D=0Aonwards.=0D=0AMay=20be= =20you=20can=20find=20them=20in=2032.251=20which=20is=20for=20PS=20domain= =20charging.=0D=0A=20=0D=0ARegards,=0D=0AKamakshi=0D=0A=20=0D=0A=20=0D=0A= -----Original=20Message-----=0D=0AFrom:=20Preeti=20Shandilya=20[mailto:pr= eeti.shandilya@aricent.com]=20=0D=0ASent:=20Thursday,=20January=2004,=202= 007=209:52=20AM=0D=0ATo:=20kamakshi=0D=0ACc:=20dime@ietf.org=0D=0ASubject= :=20RE:=20[Dime]=20AVP=20code=20for=203GPP-charging=20Id=20AVP=0D=0A=20= =0D=0A=0D=0AHi=20Kamakshi=20=0D=0A=0D=0AThanks=20for=20the=20response=20= =0D=0ADo=20you=20find=20AVP=20code=20for=20following=20AVPs=20as=20well= =20=0D=0AAPN=20Info=20and=20=20SGSN-PLMN-Id=20.=20=0D=0A=0D=0AThese=20AVP= s=20are=20used=20in=20PS-Information=20AVP=2032299-650=20=0D=0A=0D=0ARega= rds=20=0D=0APreeti.=20=0D=0A=0D=0A=0D=0A=0D=0A"kamakshi"=20=20=0D=0A01/03/2007=2011:30=20AM=20=0D=0A=0D=0A=0D=0AT= o=0D=0APreeti=20Shandilya/HSS@HSS,=20=20=0D=0Acc=0D=0A=20= =0D=0ASubject=0D=0ARE:=20[Dime]=20AVP=20code=20for=203GPP-charging=20Id= =20AVP=0D=0A=20=0D=0A=0D=0A=0D=0A=20=0D=0A=20=0D=0A=0D=0A=0D=0A=0D=0A=0D= =0A=20=20=0D=0AHi=20Preeti,=20=0D=0A=20The=20AVP=20code=20for=203GPP-Char= ging-Id=20is=202.=20It=20is=20defined=20in=20?GPP=20TS=2029.061=20=0D=0AV= 7.2.0=20(2006-12)?=20=0D=0A=20=20=0D=0ARegards,=20=0D=0AKamakshi=20=0D=0A= =20=20=0D=0A=20=20=0D=0A-----Original=20Message-----=0D=0AFrom:=20Preeti= =20Shandilya=20[mailto:preeti.shandilya@aricent.com]=20=0D=0ASent:=20Frid= ay,=20December=2022,=202006=202:22=20PM=0D=0ATo:=20dime@ietf.org=0D=0ASub= ject:=20[Dime]=20AVP=20code=20for=203GPP-charging=20Id=20AVP=20=0D=0A=20= =0D=0A=0D=0AHi=20!=20=0D=0A=0D=0ACan=20someone=20tell=20me=20the=20AVP=20= code=20for=203GPP-charging=20Id=20AVP.=20Also=20=0D=0Aspecification=20num= ber=20in=20which=20it=20is=20mentioned=20=0D=0A=0D=0ARegards=20=0D=0APree= ti.=0D=0A=0D=0A***********************=20=20Aricent-Unclassified=20=20=20= ***********************=0D=0A____________________________________________= ___=0D=0ADiME=20mailing=20list=0D=0ADiME@ietf.org=0D=0Ahttps://www1.ietf.= org/mailman/listinfo/dime=0D=0A=0D=0A=0D=0A***********************=20=20A= ricent-=20Confidential=20=20=20***********************=20=0D=0A=0D=0A"DIS= CLAIMER:=20This=20message=20is=20proprietary=20to=20Aricent=20=20and=20is= =20intended=20=0D=0Asolely=20for=20the=20use=20of=20=0D=0Athe=20individua= l=20to=20whom=20it=20is=20addressed.=20It=20may=20contain=20privileged=20= or=20=0D=0Aconfidential=20information=20and=20should=20not=20be=20=0D=0Ac= irculated=20or=20used=20for=20any=20purpose=20other=20than=20for=20what= =20it=20is=20intended.=20If=20=0D=0Ayou=20have=20received=20this=20messag= e=20in=20error,=20=0D=0Aplease=20notify=20the=20originator=20immediately.= =20If=20you=20are=20not=20the=20intended=20=0D=0Arecipient,=20you=20are= =20notified=20that=20you=20are=20strictly=0D=0Aprohibited=20from=20using,= =20copying,=20altering,=20or=20disclosing=20the=20contents=20of=20=0D=0At= his=20message.=20Aricent=20accepts=20no=20responsibility=20for=20=0D=0Alo= ss=20or=20damage=20arising=20from=20the=20use=20of=20the=20information=20= transmitted=20by=20this=20=0D=0Aemail=20including=20damage=20from=20virus= ."=0D=0A=20=0D=0A=0D=0A=0D=0A***********************=20=20Aricent-=20Conf= idential=20=20=20***********************=0D=0A"DISCLAIMER:=20This=20messa= ge=20is=20proprietary=20to=20Aricent=20=20and=20is=20intended=20solely=20= for=20the=20use=20of=20=0Athe=20individual=20to=20whom=20it=20is=20addres= sed.=20It=20may=20contain=20privileged=20or=20confidential=20information= =20and=20should=20not=20be=20=0Acirculated=20or=20used=20for=20any=20purp= ose=20other=20than=20for=20what=20it=20is=20intended.=20If=20you=20have= =20received=20this=20message=20in=20error,=20=0Aplease=20notify=20the=20o= riginator=20immediately.=20If=20you=20are=20not=20the=20intended=20recipi= ent,=20you=20are=20notified=20that=20you=20are=20strictly=0Aprohibited=20= from=20using,=20copying,=20altering,=20or=20disclosing=20the=20contents= =20of=20this=20message.=20Aricent=20accepts=20no=20responsibility=20for= =20=0Aloss=20or=20damage=20arising=20from=20the=20use=20of=20the=20inform= ation=20transmitted=20by=20this=20email=20including=20damage=20from=20vir= us."=0A --=_alternative 0024FD5865257259_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0D=0A
Hi=20Kamakshi=20!= =0D=0A
=0D=0A
You=20are=20co= rrect=20that=20these=20APIs=20have=0D=0Abeen=20removed=20from=20Release= =206.6=20onward.=20But=20since=20they=20are=20present=20in=206.5,=0D=0Aa= =20node=20complying=20to=206.5=20may=20send=20these=20AVPs=20as=20well.= =20I=20could=20not=20find=20these=0D=0Adefined=20in=2032.251=0D=0A=
=0D=0A
Regards=0D=0A=
Preeti=0D=0A
=0D=0A<= br>=0D=0A
=0D=0A=0D=0A=0D=0A<= td=20width=3D40%>"kamakshi= "=20<kamakshilk@intellinet-india.com>=0D=0A=0D=0A01/04/2007=2012:08=20PM=0D= =0A
=0D=0A=0D=0A=0D=0A=0D= =0A=0D=0A= To=0D=0APreeti=20Shandilya/HSS@HSS=0D=0A=0D=0A=0D=0Acc=0D=0A= <dime@ietf.o= rg>=0D=0A=0D=0A=0D=0ASubject=0D=0A<= font=20size=3D1=20face=3D"sans-serif">RE:=20[Dime]=20AVP=20code=20for=203= GPP-charging=0D=0AId=20AVP=0D=0A
=0D=0A=0D=0A=0D=0A
=0D=0A
=0D=0A
=0D=0A
= =0D=0A
=0D=0A
&= nbsp;=0D=0A

= Hi=20Preeti,=0D=0A

These=20AVPs=20have=20been=20removed=0D=0Afrom=20PS-Information=20= AVP=20from=20Release6.6=20onwards.=0D=0A

May=20be=20you=20can=20find=20them=20in=0D= =0A32.251=20which=20is=20for=20PS=20domain=20charging.=0D=0A

 =0D=0A

Regards,=0D=0AKamakshi=0D= =0A

 = =0D=0A

 =0D=0A

-----Original=20Message-----=
=0D=0AFrom:=20Preeti=20Shandilya=20[mailto:preeti.shandilya@ar= icent.com]=20
=0D=0ASent:=20Thursday,=20January=2004,=202007=20= 9:52=20AM
=0D=0ATo:=20kamakshi
=0D=0ACc:=20dime@ietf.= org
=0D=0ASubject:=20RE:=20[Dime]=20AVP=20code=20for=203GPP-cha= rging=20Id=20AVP=0D=0A

 =0D=0A


=0D=0A= Hi=20Kamakshi=20=0D=0A
=0D=0AThanks=20for= =20the=20response= =20
=0D=0ADo=20you=20find=20A= VP=20code=20for=20following=20AVPs=20as=20well=0D=0A
=0D=0AAPN=20Info=20and=20 SGSN-PLMN-Id=20.=0D=0A
=0D=0A
=0D=0AThese=20AVPs=20are=20used=20in=20PS-Infor= mation=20AVP=2032299-650=0D=0A
=0D=0A
=0D=0A= Regards=20<= font=20size=3D2=20face=3D"Arial">
=0D=0APreeti.=20
=0D=0A
=0D=0A=0D=0A

= =0D=0A=0D=0A=0D=0A"kamakshi"=20<= kamakshilk@intellinet-india.com>=0D=0A=0D=0A

01/03/2007=2011:30=20AM=0D=0A=0D=0A=0D= =0A
=0D=0A=0D=0A=0D=0A=0D= =0ATo<= /div>=0D=0APreeti=20Shandilya/HSS@HSS,=0D=0A<dime@ietf.org>=20=0D=0A=0D=0A<= td>=0D=0Acc=0D=0A =0D=0A=0D=0A=0D=0ASubject=0D=0ARE:=20[Dime]=20AVP=20code= =20for=203GPP-charging=0D=0AId=20AVP=0D=0A

 =0D=0A

=0D=0A
=0D= =0A=0D=0A=0D=0A =0D=0A =0D=0A
=0D=0A


=0D=0A
=0D=0A
=0D=0A=20 =0D=0A

Hi=20Preeti,=0D=0A=0D=0A

 The=20AVP=20code=20for=203GPP-Charging-Id=0D=0Ais=202.= =20It=20is=20defined=20in=20“GPP=20TS=2029.061=20V7.2.0=20(2006-12)= ”=0D=0A=0D=0A

 =0D=0A=0D=0A

= Regards,=0D=0A=0D=0A

Kamakshi=0D=0A=0D=0A

 =0D=0A=0D=0A

 =0D=0A=0D=0A

= -----Original=20Message-----
=0D=0AFrom:=20Preeti=20Shandilya= =20[mailto:preeti.shandilya@aricent.com]=20
=0D=0ASent:=20Frida= y,=20December=2022,=202006=202:22=20PM
=0D=0ATo:=20dime@ietf.or= g
=0D=0ASubject:=20[Dime]=20AVP=20code=20for=203GPP-charging=20= Id=20AVP=0D=0A=0D=0A

 =20=0D=0A


=0D=0AHi=20!=20
=0D=0A
=0D=0ACan=20someone=20tell=20me= =20the=20AVP=20code=20for=203GPP-charging=20Id=20AVP.=20Also=20specificat= ion=0D=0Anumber=20in=20which=20it=20is=20mentioned=0D=0A
=0D=0A
=0D=0ARegards=20
= =0D=0APreeti.
=0D=0A
=0D=0A***********************=20 Aricent-= Unclassified=20 =20***********************_______________________________________________=0D=0ADiME=20mailing=20list
=0D=0ADiME@ietf.org
=0D=0Ahttps://www1= .ietf.org/mailman/listinfo/dime=0D=0A


=0D=0A
=0D=0A***********************=20 Aricent-= =20Confidential=20 =20***********************=0D=0A=0D=0A

=0D=0A=0D=0A= =0D=0A"DISCLAIMER:=20This=0D=0Amessage=20is=20proprietary=20to=20Aricent&= nbsp;=20and=20is=20intended=20solely=20for=20the=0D=0Ause=20of=20= =0D=0A
the=20individual=20to= =20whom=20it=20is=20addressed.=0D=0AIt=20may=20contain=20privileged=20or= =20confidential=20information=20and=20should=20not=20be=0D=0A=0D= =0A
circulated=20or=20used= =20for=20any=20purpose=0D=0Aother=20than=20for=20what=20it=20is=20intende= d.=20If=20you=20have=20received=20this=20message=20in=0D=0Aerror,=20=0D=0A
please=20notify=20t= he=20originator=20immediately.=0D=0AIf=20you=20are=20not=20the=20intended= =20recipient,=20you=20are=20notified=20that=20you=20are=20strictly= =0D=0A
prohibited=20from=20u= sing,=20copying,=20altering,=0D=0Aor=20disclosing=20the=20contents=20of= =20this=20message.=20Aricent=20accepts=20no=20responsibility=0D=0Afor=20<= /font>=0D=0A
loss=20or=20dam= age=20arising=20from=20the=20use=0D=0Aof=20the=20information=20transmitte= d=20by=20this=20email=20including=20damage=20from=20virus."=0D=0A

 =0D=0A


=0D=0A
=0D=0A**= *********************=20 Aricent-=20Confidential=20 =20********= ***************=0D=0A

"DISCLAIMER:=20This=20message=20is=20proprietary=20to=
=20Aricent=20=20and=20is=20intended=20solely=20for=20the=20use=20of=20=0A=
the=20individual=20to=20whom=20it=20is=20addressed.=20It=20may=20contain=
=20privileged=20or=20confidential=20information=20and=20should=20not=20be=
=20=0Acirculated=20or=20used=20for=20any=20purpose=20other=20than=20for=
=20what=20it=20is=20intended.=20If=20you=20have=20received=20this=20messa=
ge=20in=20error,=20=0Aplease=20notify=20the=20originator=20immediately.=
=20If=20you=20are=20not=20the=20intended=20recipient,=20you=20are=20notif=
ied=20that=20you=20are=20strictly=0Aprohibited=20from=20using,=20copying,=
=20altering,=20or=20disclosing=20the=20contents=20of=20this=20message.=20=
Aricent=20accepts=20no=20responsibility=20for=20=0Aloss=20or=20damage=20a=
rising=20from=20the=20use=20of=20the=20information=20transmitted=20by=20t=
his=20email=20including=20damage=20from=20virus."=0A
--=_alternative 0024FD5865257259_=-- --===============0378720575== 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 --===============0378720575==-- From dime-bounces@ietf.org Thu Jan 04 08:05:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2SHc-0006DM-HV; Thu, 04 Jan 2007 08:05:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Ae3-0000b1-56 for dime@ietf.org; Wed, 03 Jan 2007 13:15:23 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H2Acg-0003By-LO for dime@ietf.org; Wed, 03 Jan 2007 13:13:59 -0500 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-8.tower-119.messagelabs.com!1167848033!14055473!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 15497 invoked from network); 3 Jan 2007 18:13:53 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-119.messagelabs.com with SMTP; 3 Jan 2007 18:13:53 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l03IDrCW019830 for ; Wed, 3 Jan 2007 11:13:53 -0700 (MST) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l03IDr8N028479 for ; Wed, 3 Jan 2007 12:13:53 -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] RFC 4004 Missing AVP Code and definition Date: Wed, 3 Jan 2007 13:13:52 -0500 Message-ID: In-Reply-To: <008501c72f04$46a4d250$d40c10ac@india.internal.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RFC 4004 Missing AVP Code and definition Thread-Index: AccvAwJIgOB4qX5WQTWyZTofD4ttygAWU6kg From: "McCann Peter-A001034" To: "Hemant" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-Mailman-Approved-At: Thu, 04 Jan 2007 08:05:22 -0500 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 These look like oversights to me. Either those AVPs should have been defined or they should not have appeared in the Grouped AVPs at all. For instance, the HA-to-MN SPI is chosen by the MN and is available to the HA from the encapsulated Registration Request. The MN-to-FA SPI is chosen by the FA and is sent back in the Registration Reply, so perhaps it isn't needed either. Similarly, the MN-to-HA SPI is chosen by the HA and sent back in the Registration Reply. This definitely seems to call for at least an errata. -Pete Hemant wrote: > Hi All, > I would appreciate if anybody can provide some information on this. >=20 > Thanks and Regards, > Hemant Bhatnagar > Software Engineer > IntelliNet Technologies India Pvt. Ltd. > Accelerating Convergence > hbhatnagar@intellinet-india.com > 413/4 Oxford Towers, 139 Airport Road, > Bangalore - 560 017 > Off-Phone.....: + 91 80 51256018 Ext: 2311 > Off - Fax.......: + 91 80 25202947 > ----- Original Message ----- > From: Hemant > To: dime@ietf.org ; dime-request@ietf.org > Cc: imsdia@intellinet-india.com > Sent: Tuesday, December 26, 2006 12:40 PM > Subject: Missing AVP Code and definition >=20 >=20 > Hi All, > In RFC 4004 there are some AVPs which have reference in the > specification but are not declared formally with AVP code. >=20 > Following are the AVP's: > 1. MIP-HA-to-MN-SPI used in the Grouped AVP MIP-HA-to-MN-MSA. > 2. MIP-MN-FA-SPI used in the Grouped AVP MIP-MN-to-FA-MSA. > 3. MIP-MN-HA-SPI used in the Grouped AVP MIP-MN-to-HA-MSA. >=20 > Are they defined in some other RFC or do we have to use internally > defined values for them? >=20 > Thanks in Advance. >=20 > Regards, > Hemant Bhatnagar > Software Engineer > IntelliNet Technologies India Pvt. Ltd. > Accelerating Convergence > hbhatnagar@intellinet-india.com > 413/4 Oxford Towers, 139 Airport Road, > Bangalore - 560 017 > Off-Phone.....: + 91 80 51256018 Ext: 2311 > Off - Fax.......: + 91 80 25202947 >=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 Fri Jan 05 07:27:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2oAt-0008W9-EN; Fri, 05 Jan 2007 07:27:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2oAr-0008Vc-Eh for dime@ietf.org; Fri, 05 Jan 2007 07:27:53 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2oAp-0007kX-Td for dime@ietf.org; Fri, 05 Jan 2007 07:27:53 -0500 Received: from mail1.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id l05CRo6e002883; Fri, 5 Jan 2007 13:27:50 +0100 Received: from blnss35a.ww100.siemens.net (blnss35a.ww100.siemens.net [194.138.127.221]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id l05CRoJM001968; Fri, 5 Jan 2007 13:27:50 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: [Dime] Ro or CCA Date: Fri, 5 Jan 2007 13:27:48 +0100 Message-ID: <9455E8227DC5C14E82337653F583A9AC048D1783@blnss35a.ww100.siemens.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Ro or CCA Thread-Index: AccvDxWsFZMAUpIWSDytBp0h+3WzCQArZMgwAEEdJeA= From: "Schendel, Jens" To: , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1225500063==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1225500063== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C730C4.EA2FB219" This is a multi-part message in MIME format. ------_=_NextPart_001_01C730C4.EA2FB219 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Himanshu, =20 as mentioned by John, 3GPP is actually the appropriate forum. Some brief info: =20 1) 3GPP Ro bases on DCCA framework. 3GPP added vendor specific AVP to cover service specific online charging use cases, e.g. MMS, PoC. So the answer is: both. 2) DCCA is the service unspecific framework. There are no standardized solutions (3GPP) for SMS and CS (decentralized IN server with SS7 connection) DCCA yet. Some proprietary realizations do exist. 3) 3GPP rating related AVP are grouped in Service-Information AVP according to the service, e.g. MMS-Information AVP. Note that DCCA Service-Parameter-Info AVP (as an alternative) is not used by 3GPP. 3GPP charging AVP definition is in TS 32.299. =20 Jens =20 ________________________________ Von: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Gesendet: Donnerstag, 4. Januar 2007 05:57 An: himanshu.rawat@gmail.com; dime@ietf.org Betreff: RE: [Dime] Ro or CCA This is probably the wrong forum to ask this. Ro is defined by 3GPP, DCCA is defined here. Someone else can speak to the relationship to the specs for Ro and DCCA. =20 =20 John ________________________________ From: ext Himanshu Rawat [mailto:himanshu.rawat@gmail.com]=20 Sent: 03 January, 2007 10:13 To: dime@ietf.org Subject: [Dime] Ro or CCA =09 =09 Hi, =09 I'm trying to find out the answers of below questions. Please can anyone answer them. =09 1) Which one to use for "real-time, on-line, prepaid services". Ro or CCA?? and why? =09 2) AVPs for SMS and circuit-switched voice calls in Ro and CCA?. =09 3) Rating related AVPS in Ro and CCA? =09 =09 Thanks --=20 Himanshu Rawat=20 ------_=_NextPart_001_01C730C4.EA2FB219 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Himanshu,
 
as mentioned by John, 3GPP is actually the = appropriate=20 forum. Some brief info:
 
1) 3GPP Ro bases on DCCA framework. = 3GPP added vendor=20 specific AVP to cover service specific online charging use cases, e.g. = MMS, PoC.=20 So the answer is: both.
2) DCCA is the service unspecific framework. = There are no=20 standardized solutions (3GPP) for SMS and CS (decentralized IN server = with SS7=20 connection) DCCA yet. Some proprietary realizations do=20 exist.
3) 3GPP rating related AVP are grouped in=20 Service-Information AVP according to the service, e.g. MMS-Information = AVP. Note=20 that DCCA Service-Parameter-Info AVP (as an alternative) is = not used=20 by 3GPP. 3GPP charging AVP definition is in TS = 32.299.
 
Jens
 

Von: john.loughney@nokia.com=20 [mailto:john.loughney@nokia.com]
Gesendet: Donnerstag, 4. = Januar 2007=20 05:57
An: himanshu.rawat@gmail.com; = dime@ietf.org
Betreff:=20 RE: [Dime] Ro or CCA

This is probably the wrong forum to ask = this.  Ro is=20 defined by 3GPP, DCCA is defined here.  Someone else can speak to = the=20 relationship to the specs for Ro and DCCA. 
 
John

From: ext Himanshu Rawat=20 [mailto:himanshu.rawat@gmail.com]
Sent: 03 January, 2007=20 10:13
To: dime@ietf.org
Subject: [Dime] Ro or=20 CCA

Hi,

I'm trying to find out the answers of below = questions.=20 Please can anyone answer them.

1) Which one to use for = "real-time,=20 on-line, prepaid services". Ro or CCA?? and why?

2) AVPs for = SMS and=20 circuit-switched voice calls in Ro and CCA?.

3) Rating related = AVPS in=20 Ro and CCA?


Thanks
--
Himanshu Rawat=20 ------_=_NextPart_001_01C730C4.EA2FB219-- --===============1225500063== 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 --===============1225500063==-- From dime-bounces@ietf.org Fri Jan 05 07:50:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2oX7-0002WD-Et; Fri, 05 Jan 2007 07:50:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2oX6-0002W3-6l for dime@ietf.org; Fri, 05 Jan 2007 07:50:52 -0500 Received: from mailout-1.omnitel.it ([194.20.77.121] helo=fmis437.omnitel.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2oX3-00069q-Oo for dime@ietf.org; Fri, 05 Jan 2007 07:50:52 -0500 Received: from omini96.omnitel.it (omini96.omnitel.it [10.21.18.148]) by fmis437.omnitel.it (Switch-3.2.5/Switch-3.2.5) with ESMTP id l05CokMT000826 for ; Fri, 5 Jan 2007 13:50:46 +0100 (MET) Received: from oivmexo01.omnitel.it ([10.31.32.12]) by ominc74.omnitel.it with Microsoft SMTPSVC(5.0.2195.6713); Fri, 5 Jan 2007 13:50:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 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] Contradicting AVPs in 4006 ? Date: Fri, 5 Jan 2007 13:50:32 +0100 Message-ID: <5371BE300539E6439919CF97203DDEC2088AD957@OIVMEXO01.omnitel.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Contradicting AVPs in 4006 ? Thread-Index: AccpzQneN3mSOO6GTsG/q/J16SJ1ogG6zu5A From: "STURA, Marco, VF-IT" To: "Tolga Asveren" , X-OriginalArrivalTime: 05 Jan 2007 12:50:44.0970 (UTC) FILETIME=[1D7D6CA0:01C730C8] X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 >BTW, I am not sure whether event based scenarios for CHECK_BALANCE and >PRICE_ENQUIRY can be used with multiple services. The multiple services concept is defined only for session based CC to enable multiplexing control of several credit chunks (or quotas) within the same diameter session, it is not meant to be used with one time event based operations. Br, Marco _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jan 05 07:51:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2oY1-0002ap-R1; Fri, 05 Jan 2007 07:51:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2oY0-0002ai-MH for dime@ietf.org; Fri, 05 Jan 2007 07:51:48 -0500 Received: from mailout-1.omnitel.it ([194.20.77.121] helo=fmis437.omnitel.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2oXx-0006St-LZ for dime@ietf.org; Fri, 05 Jan 2007 07:51:48 -0500 Received: from omini95.omnitel.it (omini95.omnitel.it [10.21.18.147]) by fmis437.omnitel.it (Switch-3.2.5/Switch-3.2.5) with ESMTP id l05CpiRs001033 for ; Fri, 5 Jan 2007 13:51:44 +0100 (MET) Received: from oivmexo01.omnitel.it ([10.31.32.12]) by ominc75.omnitel.it with Microsoft SMTPSVC(5.0.2195.6713); Fri, 5 Jan 2007 13:51:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Contradicting AVPs in 4006 ? Date: Fri, 5 Jan 2007 13:51:31 +0100 Message-ID: <5371BE300539E6439919CF97203DDEC2088AD958@OIVMEXO01.omnitel.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Contradicting AVPs in 4006 ? Thread-Index: AccqedEC1NzNas//QGOSXzqQF4xwlwGQLszQ From: "STURA, Marco, VF-IT" To: "Liyaqatali" , "Tolga Asveren" X-OriginalArrivalTime: 05 Jan 2007 12:51:43.0779 (UTC) FILETIME=[408AF730:01C730C8] X-Spam-Score: 0.1 (/) X-Scan-Signature: 1b82b4ba484bbe86cdae6d5f8b2d2ccb 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="===============0594954188==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0594954188== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C730C8.393C7788" This is a multi-part message in MIME format. ------_=_NextPart_001_01C730C8.393C7788 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Actually in section 5.1.2 there is a paragraph saying =20 If the client indicated support for independent credit-control of multiple services, a credit-control server that wishes to use the feature MUST return the granted units within the Multiple-Services- Credit-Control AVP associated to the corresponding service-identifier and/or rating-group. =20 Although I admit it is not crystal clear, but a client may request units = for a service in CCR initial at command level (without using the M-S-C-C = AVP) and the server may decide to use the multiple service feature by = returning granted units for the service within the M-S-C-C AVP. This = implies that no service-id is present at command level for subsequent = requests. As a general rule the service-id should be present either at = command level if no M-S-C-C is used, or at M-S-C-C level otherwise. An = example of this is given in Flow IX. =20 Br, Marco =20 _____ =20 From: Liyaqatali [mailto:a21917@motorola.com]=20 Sent: gioved=EC 28 dicembre 2006 13.11 To: Tolga Asveren Cc: dime@ietf.org Subject: Re: [Dime] Contradicting AVPs in 4006 ? =20 Hi Tolga, Thanks for your response.=20 Well, I agree with you that Service-Identifier AVP should not be = present, if multiple services are used, but apparently, this isn't = mentioned in the RFC hence I was a bit confused. I also agree that there = may not be many scenarios where multiple parallel event based services = are necessary but the reason I considered event based services is = because it clearly brings out the contradiction.=20 I also feel that conditional AVPs should be mentioned in the RFC like = the way the presence of Subscription-Id AVP is mentioned in most of the = sections of the RFC because these are optional AVPs at the command = level.=20 I was wondering, Is there a reason why it isn't explicitly mentioned in = the RFC? Regards, Liyaqatali G Nadaf =20 Tolga Asveren wrote:=20 Hi Liyaqatali, =20 I guess it makes sense to use the values present in Multiple-Services-Credit-Control AVP if there is a contradiction. I even would expect Service-Identifier AVP not to be present if multiple = services are used. =20 BTW, I am not sure whether event based scenarios for CHECK_BALANCE and PRICE_ENQUIRY can be used with multiple services. Multiple-Services-Credit-Control AVP does not have Cost-Information/Check-Balance-Result AVPs. There is of course the = wildcard *[ AVP ], but I would expect these AVPs to be specifically mentioned, if there was an intention to use them. There are probably not many = scenarios, where multiple parallel event based services are necessary to provide a "single service experience" from user point of view. =20 Thanks, Tolga =20 -----Original Message----- From: Liyaqatali [mailto:a21917@motorola.com] Sent: Wednesday, December 27, 2006 9:04 AM To: vfajardo@tari.toshiba.com; dime@ietf.org Cc: hannes.tschofenig@siemens.com Subject: [Dime] Contradicting AVPs in 4006 ? =20 =20 =20 Hi All, =20 I had a couple of questions about the command level AVP's and the Multiple-service-credit-control AVP. =20 Suppose a event based CCR, with CHECK_BALANCE as the value in Requested-Action AVP, is sent by the credit control client to the = server, so, which of the following AVP combinations should be considered by the server to check the balance. -service-identifier AVP at the command level or -service-identifier AVP(s) in the Multiple-service-credit-control = AVP or -both of the above AVPs =20 Similarly, in the above scenario if the requested-action AVP had PRICE_ENQUIRY as the AVP value, then wouldn't the service-identifier AVP = at the command level and the Multiple-service-credit-control AVP be contradicting? =20 At a higher level, when should the command level AVPs in CCR gain = priority than the Multiple-service-credit-control AVPs? =20 I would appreciate if anybody can provide some inputs on this. =20 -- =20 Regards, Liyaqatali G Nadaf =20 =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime =20 =20 ------_=_NextPart_001_01C730C8.393C7788 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Actually in section 5.1.2 there is = a paragraph saying

 

=A0=A0 If the client indicated support for independent credit-control = of

=A0=A0 multiple services, a credit-control server that wishes to use = the

=A0=A0 feature MUST return the granted units within the = Multiple-Services-

=A0=A0 Credit-Control AVP associated to the corresponding = service-identifier

=A0=A0 and/or rating-group.

 

Although I admit it is not crystal = clear, but a client may request units for a service in CCR initial at command = level (without using the M-S-C-C AVP) and the server may decide to use the = multiple service feature by returning granted units for the service within the = M-S-C-C AVP. This implies that no service-id is present at command level for = subsequent requests. As a general rule the service-id should be present either at = command level if no M-S-C-C is used, or at M-S-C-C level otherwise. An example = of this is given in Flow IX.

 

Br,

Marco

 

From: Liyaqatali [mailto:a21917@motorola.com]
Sent: gioved=EC 28 = dicembre 2006 13.11
To: Tolga Asveren
Cc: dime@ietf.org
Subject: Re: [Dime] = Contradicting AVPs in 4006 ?

 


Hi Tolga,

Thanks for your response.
Well, I agree with you that Service-Identifier AVP should not be = present, if multiple services are used, but apparently, this isn't mentioned in the = RFC hence I was a bit confused. I also agree that there may not be many = scenarios where multiple parallel event based services are necessary but the = reason I considered event based services is because it clearly brings out the contradiction.
I also feel that conditional AVPs should be mentioned in the RFC like = the way the presence of Subscription-Id AVP is mentioned in most of the sections = of the RFC because these are optional AVPs at the command level.
I was wondering, Is there a reason why it isn't explicitly mentioned in = the RFC?


Regards,
Liyaqatali G =
Nadaf
 


Tolga Asveren wrote: 

Hi =
Liyaqatali,
 
I guess it makes sense to use the values =
present in
Multiple-Services-Credit-Control AVP if there =
is a contradiction. I even
would expect Service-Identifier AVP not to be =
present if multiple services
are =
used.
 
BTW, I am not sure whether event based =
scenarios for CHECK_BALANCE and
PRICE_ENQUIRY can be used with multiple =
services.
Multiple-Services-Credit-Control AVP does not =
have
Cost-Information/Check-Balance-Result AVPs. =
There is of course the wildcard
*[ AVP ], but I would expect these AVPs to be =
specifically mentioned, if
there was an intention to use them. There are =
probably not many scenarios,
where multiple parallel event based services =
are necessary to provide a
"single service experience" from =
user point of view.
 
=A0=A0=A0 =
Thanks,
=A0=A0=A0 =
Tolga
 
-----Original =
Message-----
From: Liyaqatali [mailto:a21917@motorola.com]<=
/o:p>
Sent: Wednesday, December 27, 2006 9:04 =
AM
To: vfajardo@tari.toshiba.com; =
dime@ietf.org<=
/pre>
Cc: hannes.tschofenig@siemens.c=
om
Subject: [Dime] Contradicting AVPs in 4006 =
?
 
 
 
Hi =
All,
 
I had a couple of questions about the command =
level AVP's and the
Multiple-service-credit-control =
AVP.
 
Suppose a event based CCR, with CHECK_BALANCE =
as the value in
Requested-Action AVP, is sent by the credit =
control client to the server,
so, which of the following AVP combinations =
should be considered by the
server to check the =
balance.
=A0=A0=A0 -service-identifier AVP at the =
command level or
=A0=A0=A0 -service-identifier AVP(s) in the =
Multiple-service-credit-control AVP =
or
=A0=A0=A0 -both of the above =
AVPs
 
Similarly,=A0 in the above scenario if the =
requested-action AVP had
PRICE_ENQUIRY as the AVP value, then wouldn't =
the service-identifier AVP at
the command level =
and
the Multiple-service-credit-control AVP be =
contradicting?
 
At a higher level, when should the command =
level AVPs in CCR gain priority
than the Multiple-service-credit-control =
AVPs?
 
I would appreciate if anybody can provide =
some inputs on this.
 
--
 
Regards,
Liyaqatali G =
Nadaf
 
 
______________________________________________=
_
DiME mailing =
list
DiME@ietf.org<=
/pre>
https://www1.ietf.or=
g/mailman/listinfo/dime
 
=A0
------_=_NextPart_001_01C730C8.393C7788-- --===============0594954188== 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 --===============0594954188==-- From dime-bounces@ietf.org Fri Jan 05 08:15:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2ouv-0005PB-NR; Fri, 05 Jan 2007 08:15:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2ouu-0005P6-O6 for dime@ietf.org; Fri, 05 Jan 2007 08:15:28 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H2our-0002wi-W9 for dime@ietf.org; Fri, 05 Jan 2007 08:15:28 -0500 X-VirusChecked: Checked X-Env-Sender: liyaqatali@motorola.com X-Msg-Ref: server-3.tower-128.messagelabs.com!1168002920!3333773!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 18931 invoked from network); 5 Jan 2007 13:15:20 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-3.tower-128.messagelabs.com with SMTP; 5 Jan 2007 13:15:20 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l05DFJ5r011766 for ; Fri, 5 Jan 2007 06:15:19 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l05DFHXI023287 for ; Fri, 5 Jan 2007 07:15:18 -0600 (CST) Received: from [10.232.37.39] ([10.232.37.39]) by ZMY16EXM66.ds.mot.com with Microsoft SMTPSVC(6.0.3790.2709); Fri, 5 Jan 2007 21:15:16 +0800 Message-ID: <459E4E89.5080803@motorola.com> Date: Fri, 05 Jan 2007 18:41:37 +0530 From: Liyaqatali User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: "STURA, Marco, VF-IT" Subject: Re: [Dime] Contradicting AVPs in 4006 ? References: <5371BE300539E6439919CF97203DDEC2088AD958@OIVMEXO01.omnitel.it> In-Reply-To: <5371BE300539E6439919CF97203DDEC2088AD958@OIVMEXO01.omnitel.it> X-OriginalArrivalTime: 05 Jan 2007 13:15:16.0554 (UTC) FILETIME=[8A9F52A0:01C730CB] X-Spam-Score: 1.7 (+) X-Scan-Signature: fac892abe0c719c7bb99f6e7c710cdae Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1854334296==" Errors-To: dime-bounces@ietf.org --===============1854334296== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I agree with you on that. Surely section 5.1.2 hints towards that but yet doesn't state it clearly. My main intension was to bring out the contradictory and conditional AVPs which are not mentioned in the RFC.
Since RFC says that Subscription-Id AVP MUST be present in almost all the cases, similarly, other, conditional required AVPs should be mentioned.

For example: During Balance inquiry, server checks whether the account balance can cover the cost of a certain service, without reserving any units from the account at the time of the inquiry.
It is not mentioned in the RFC that Requested-Service-Unit AVP MUST be present in case of CHECK_BALANCE. (Sorry for considering Event based charging again). But it can be guessed that its a rating error.


BTW, Can you tell me does Event-Time-Stamp AVP, which is added in every request, serves other purposes apart from being informational at the server side?

Thanks in Advance.

Regards,
Liyaqatali G Nadaf


STURA, Marco, VF-IT wrote:

Actually in section 5.1.2 there is a paragraph saying

 

   If the client indicated support for independent credit-control of

   multiple services, a credit-control server that wishes to use the

   feature MUST return the granted units within the Multiple-Services-

   Credit-Control AVP associated to the corresponding service-identifier

   and/or rating-group.

 

Although I admit it is not crystal clear, but a client may request units for a service in CCR initial at command level (without using the M-S-C-C AVP) and the server may decide to use the multiple service feature by returning granted units for the service within the M-S-C-C AVP. This implies that no service-id is present at command level for subsequent requests. As a general rule the service-id should be present either at command level if no M-S-C-C is used, or at M-S-C-C level otherwise. An example of this is given in Flow IX.

 

Br,

Marco

 

From: Liyaqatali [mailto:a21917@motorola.com]
Sent: giovedì 28 dicembre 2006 13.11
To: Tolga Asveren
Cc: dime@ietf.org
Subject: Re: [Dime] Contradicting AVPs in 4006 ?

 


Hi Tolga,

Thanks for your response.
Well, I agree with you that Service-Identifier AVP should not be present, if multiple services are used, but apparently, this isn't mentioned in the RFC hence I was a bit confused. I also agree that there may not be many scenarios where multiple parallel event based services are necessary but the reason I considered event based services is because it clearly brings out the contradiction.
I also feel that conditional AVPs should be mentioned in the RFC like the way the presence of Subscription-Id AVP is mentioned in most of the sections of the RFC because these are optional AVPs at the command level.
I was wondering, Is there a reason why it isn't explicitly mentioned in the RFC?


Regards,
Liyaqatali G Nadaf
 


Tolga Asveren wrote: 

Hi Liyaqatali,
 
I guess it makes sense to use the values present in
Multiple-Services-Credit-Control AVP if there is a contradiction. I even
would expect Service-Identifier AVP not to be present if multiple services
are used.
 
BTW, I am not sure whether event based scenarios for CHECK_BALANCE and
PRICE_ENQUIRY can be used with multiple services.
Multiple-Services-Credit-Control AVP does not have
Cost-Information/Check-Balance-Result AVPs. There is of course the wildcard
*[ AVP ], but I would expect these AVPs to be specifically mentioned, if
there was an intention to use them. There are probably not many scenarios,
where multiple parallel event based services are necessary to provide a
"single service experience" from user point of view.
 
    Thanks,
    Tolga
 
-----Original Message-----
From: Liyaqatali [mailto:a21917@motorola.com]
Sent: Wednesday, December 27, 2006 9:04 AM
To: vfajardo@tari.toshiba.com; dime@ietf.org
Cc: hannes.tschofenig@siemens.com
Subject: [Dime] Contradicting AVPs in 4006 ?
 
 
 
Hi All,
 
I had a couple of questions about the command level AVP's and the
Multiple-service-credit-control AVP.
 
Suppose a event based CCR, with CHECK_BALANCE as the value in
Requested-Action AVP, is sent by the credit control client to the server,
so, which of the following AVP combinations should be considered by the
server to check the balance.
    -service-identifier AVP at the command level or
    -service-identifier AVP(s) in the Multiple-service-credit-control AVP or
    -both of the above AVPs
 
Similarly,  in the above scenario if the requested-action AVP had
PRICE_ENQUIRY as the AVP value, then wouldn't the service-identifier AVP at
the command level and
the Multiple-service-credit-control AVP be contradicting?
 
At a higher level, when should the command level AVPs in CCR gain priority
than the Multiple-service-credit-control AVPs?
 
I would appreciate if anybody can provide some inputs on this.
 
--
 
Regards,
Liyaqatali G Nadaf
 
 
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime
 
 
--===============1854334296== 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 --===============1854334296==-- From dime-bounces@ietf.org Fri Jan 05 09:52:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2qQo-0006nR-OQ; Fri, 05 Jan 2007 09:52:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2qQm-0006lh-WD for dime@ietf.org; Fri, 05 Jan 2007 09:52:29 -0500 Received: from mailout-1.omnitel.it ([194.20.77.121] helo=fmis437.omnitel.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2qQk-0008Pd-CH for dime@ietf.org; Fri, 05 Jan 2007 09:52:28 -0500 Received: from omini95.omnitel.it (omini95.omnitel.it [10.21.18.147]) by fmis437.omnitel.it (Switch-3.2.5/Switch-3.2.5) with ESMTP id l05EqPfP002539 for ; Fri, 5 Jan 2007 15:52:25 +0100 (MET) Received: from oivmexo01.omnitel.it ([10.31.32.12]) by ominc75.omnitel.it with Microsoft SMTPSVC(5.0.2195.6713); Fri, 5 Jan 2007 15:52:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Contradicting AVPs in 4006 ? Date: Fri, 5 Jan 2007 15:52:20 +0100 Message-ID: <5371BE300539E6439919CF97203DDEC2088AD959@OIVMEXO01.omnitel.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Contradicting AVPs in 4006 ? Thread-Index: Accwy4vSipeFEj1JTE+iyoY9JOOY7QAA0AsA From: "STURA, Marco, VF-IT" To: "Liyaqatali" X-OriginalArrivalTime: 05 Jan 2007 14:52:23.0263 (UTC) FILETIME=[1B9C8EF0:01C730D9] X-Spam-Score: 0.1 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd 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="===============0170837023==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0170837023== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C730D9.1A044092" This is a multi-part message in MIME format. ------_=_NextPart_001_01C730D9.1A044092 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >It is not mentioned in the RFC that Requested-Service-Unit AVP MUST be present in case of CHECK_BALANCE. (Sorry for considering >Event based charging again). But it can be guessed that its a rating error. =20 R-S-U may be used in direct debiting if the service node knows the *cost* of the service, but not in the balance check operation. In the sections defining each of the event operations it is mentioned what the client is expected to send, what is not mentioned it's supposed to not be sent. Other stuff should be defined in service specific documents. =20 For the balance check in particular section 6.2 second paragraph defines what the client is supposed to send, R-S-U is not mentioned. =20 A Diameter credit-control client requesting the balance check MUST set the CC-Request-Type AVP equal to EVENT_REQUEST, include a Requested-Action AVP set to CHECK_BALANCE, and include the Subscription-Id AVP in order to identify the end user in the credit- control server. The Service-Context-Id AVP indicates the service specific document applicable to the request. =20 >BTW, Can you tell me does Event-Time-Stamp AVP, which is added in every request, serves other purposes apart from being informational >at the server side? =20 The event-time-stamp contains the time when the service event is requested at the client. What the server does with it is not defined in the specification, but a typical application is to record it along with other information for auditing purposes. =20 Br, Marco =20 ------_=_NextPart_001_01C730D9.1A044092 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>It is not mentioned in the RFC that Requested-Service-Unit AVP MUST be present in case of CHECK_BALANCE. = (Sorry for considering >Event based charging again). But it can be guessed that = its a rating error.

 

R-S-U may be used in direct = debiting if the service node knows the *cost* of the service, but not in the balance check operation. In the sections defining each of the event operations it is mentioned what the client is expected to send, what is not mentioned it’s supposed to not be = sent. Other stuff should be defined in service specific = documents.

 

For the balance check in particular section 6.2 second paragraph defines what the client is supposed to = send, R-S-U is not mentioned.

 

   A Diameter credit-control client requesting the balance check = MUST

   set the CC-Request-Type AVP equal to EVENT_REQUEST, include = a

   Requested-Action AVP set to CHECK_BALANCE, and include = the

   Subscription-Id AVP in order to identify the end user in the = credit-

   control server.  The Service-Context-Id AVP indicates the = service

   specific document applicable to the request.

 

>BTW, Can you tell me does = Event-Time-Stamp AVP, which is added in every request, serves other purposes apart from being informational >at the server side?

 

The event-time-stamp contains the = time when the service event is requested at the client. What the server does = with it is not defined in the specification, but a typical application is to = record it along with other information for auditing = purposes.

 

Br,

Marco

 

------_=_NextPart_001_01C730D9.1A044092-- --===============0170837023== 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 --===============0170837023==-- From dime-bounces@ietf.org Mon Jan 08 06:15:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3sTA-0001Wb-EJ; Mon, 08 Jan 2007 06:15:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3sRp-00018E-0Q for dime@ietf.org; Mon, 08 Jan 2007 06:13:49 -0500 Received: from nf-out-0910.google.com ([64.233.182.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3sDW-00044k-6J for dime@ietf.org; Mon, 08 Jan 2007 05:59:04 -0500 Received: by nf-out-0910.google.com with SMTP id l36so7020692nfa for ; Mon, 08 Jan 2007 02:59: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=bcBcFiScbz1hgJD5R1J57WqmKr5sPcjRTlqZdY2jkxqTGsqKfJw3MD94KKzyvVwYemauwf5Qxqj4yOdi7I3DswWROwLm/GjpwMaoSpAqRoRYCrlZz1Z0YIfZBZbJ6fSSkbUyv//WJZfkBdtXYttRRVcBXLyNqY3XyfM7DKtKP+4= Received: by 10.49.41.3 with SMTP id t3mr10153240nfj.1168253941272; Mon, 08 Jan 2007 02:59:01 -0800 (PST) Received: by 10.48.222.20 with HTTP; Mon, 8 Jan 2007 02:59:01 -0800 (PST) Message-ID: <5e2406980701080259we892279k8aaba84daec22a0@mail.gmail.com> Date: Mon, 8 Jan 2007 11:59:01 +0100 From: "Julien Bournelle" To: "Hannes Tschofenig" Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Security In-Reply-To: <45993543.7060601@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45993543.7060601@gmx.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org hi hannes, all ok, so let's try to investigate this. In our current document, we have the following architecture: MN <--- IKEv2 -----> HA <------> AAA_EAP ^ | +------------> AAA_MIP6 HA authenticates the MN by using 4072 in AUTHENTICATE_ONLY mode (if EAP used within IKEv2) and we have defined 2 new messages for Authorization purposes at AAA_MIP6. HA uses identiy provided by MN in IDii field of the 3rd IKEv2 message to route messages to the corresponding realm.Thus, in the picture above, we consider that AAA_EAP and AAA_MIP6 are in the same realm. Howver, as we have a different App-Id, AAA_EAP and AAA_MIP6 may be located in different servers. Note that this is not a requirement, that's possible. Advantages are modularity and flexibility. This approach may also be used by other applications that use EAP for authentication. However, we do not require use of EAP. The problem that we have with this approach is to investigate if it creates a security hole to separate Authentication and Authorization. As it has been mentionned in the ML, the HA may be compromised. So, the first thing I think we should do is to catch and to agree on the goals of such an attack. I can see: a/ DoS on the Mobile IPv6 service (shutdown) with loss of revenues for an operator b/ Steal the service 1. The attacker compromises the HA to obtain free mip6 service for himself 2. The attacker compromises the HA for a group of people to obtain free mip6 service 3. The attacker compromises the HA for all to obtain free mip6 service. c/ Identity spoofing to charge someone else others ? Julien On 1/1/07, Hannes Tschofenig wrote: > Hi all, > > it seems that we came across a security issue that requires more > thoughts. Interestingly, David Nelson gave a presentation at the IETF#66 > meeting that dealt with a similar problem when RADIUS is used in the > ISMS context. You can find his presentation here: > http://www3.ietf.org/proceedings/06jul/slides/radext-7/sld1.htm > > We need to investigate the potential security threats in more detail > before we immediately jump to the solution space. > Who has time and would be interested to brainstorm about this subject a > little bit? > The goal is to have a more detailed description of the security threats. > > Ciao > Hannes > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jan 08 13:27:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3zD9-0007sJ-PO; Mon, 08 Jan 2007 13:27:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3zD9-0007sD-3T for dime@ietf.org; Mon, 08 Jan 2007 13:27:07 -0500 Received: from maild.telecomitalia.it ([156.54.233.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3zD4-0000jt-T9 for dime@ietf.org; Mon, 08 Jan 2007 13:27:07 -0500 Received: from ptpxch008ba020.idc.cww.telecomitalia.it ([156.54.240.51]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jan 2007 19:26:59 +0100 Received: from PTPEVS108BA020.idc.cww.telecomitalia.it ([156.54.241.228]) by ptpxch008ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jan 2007 19:26:59 +0100 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 Content-Class: urn:content-classes:message Importance: normal Priority: normal 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: Security Date: Mon, 8 Jan 2007 19:26:57 +0100 Message-ID: In-Reply-To: <5e2406980701080259we892279k8aaba84daec22a0@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Security thread-index: AcczFmsw3xUvNCGKRvyN4+Dqf/UebgANSaig From: "La Monaca Michele" To: X-OriginalArrivalTime: 08 Jan 2007 18:26:59.0254 (UTC) FILETIME=[958A1D60:01C73352] X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Julien,=20 as you said the separation between auth and autz takes along modularity and flexibility but it raises security concerns if the HA is compromised. Therefore, I think that it would be better to compare what a compromised HA can/cannot do in the two cases: "Split" AAA approach=20 1) Deny service to regular users (i.e. DoS) YES=20 2) Grant service to fake users (i.e. steal the service) YES 3) DoS to the AAA infrastructure YES 4) Identity spoofing to charge someone else YES 5) something else? "Integrated" AAA approach 1) Deny service to regular users (i.e. DoS) YES 2) Grant service to fake users (i.e. steal the service) YES 3) DoS to the AAA infrastructure YES 4) Identity spoofing to charge someone else YES? 5) something else? Btw, the separation between auth and autz might improve the overall security in some circumstances. For example, an attacker may succeed to tear down the AAA-EAP functionality but not the AAA-MIPv6 one, so already authenticated users may continue to use the mipv6 service. My 2 cents, --Michele >-----Messaggio originale----- >Da: Julien Bournelle [mailto:julien.bournelle@gmail.com] >Inviato: Monday, January 08, 2007 11:59 AM >A: Hannes Tschofenig >Cc: dime@ietf.org >Oggetto: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Security > >hi hannes, all > > ok, so let's try to investigate this. > > In our current document, we have the following architecture: > > MN <--- IKEv2 -----> HA <------> AAA_EAP > ^ > | > +------------> AAA_MIP6 > > HA authenticates the MN by using 4072 in AUTHENTICATE_ONLY mode > (if EAP used within IKEv2) and we have defined 2 new messages for >Authorization purposes at AAA_MIP6. > HA uses identiy provided by MN in IDii field of the 3rd IKEv2 message to >route > messages to the corresponding realm.Thus, in the picture above, we >consider that AAA_EAP and AAA_MIP6 are in the same realm. > Howver, as we have a different App-Id, AAA_EAP and AAA_MIP6 may be located >in > different servers. Note that this is not a requirement, that's possible. > > Advantages are modularity and flexibility. This approach may also be >used by other > applications that use EAP for authentication. However, we do not require > use of EAP. > > The problem that we have with this approach is to investigate if it >creates a security > hole to separate Authentication and Authorization. > > As it has been mentionned in the ML, the HA may be compromised. > > So, the first thing I think we should do is to catch and to agree on the >goals > of such an attack. I can see: > > a/ DoS on the Mobile IPv6 service (shutdown) with loss of revenues >for an operator > > b/ Steal the service > > 1. The attacker compromises the HA to obtain free mip6 service for >himself > > 2. The attacker compromises the HA for a group of people to > obtain free mip6 service > > 3. The attacker compromises the HA for all to obtain free mip6 >service. > >c/ Identity spoofing to charge someone else > > others ? > > Julien > > > > > > >On 1/1/07, Hannes Tschofenig wrote: >> Hi all, >> >> it seems that we came across a security issue that requires more >> thoughts. Interestingly, David Nelson gave a presentation at the IETF#66 >> meeting that dealt with a similar problem when RADIUS is used in the >> ISMS context. You can find his presentation here: >> http://www3.ietf.org/proceedings/06jul/slides/radext-7/sld1.htm >> >> We need to investigate the potential security threats in more detail >> before we immediately jump to the solution space. >> Who has time and would be interested to brainstorm about this subject a >> little bit? >> The goal is to have a more detailed description of the security threats. >> >> Ciao >> Hannes >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www1.ietf.org/mailman/listinfo/dime -------------------------------------------------------------------- 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 Tue Jan 09 03:21:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4CEs-0008P0-DH; Tue, 09 Jan 2007 03:21:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4CEr-0008Os-Ik for dime@ietf.org; Tue, 09 Jan 2007 03:21:45 -0500 Received: from jaguar.hughesbpo.net ([61.246.186.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4CEp-0003ae-J8 for dime@ietf.org; Tue, 09 Jan 2007 03:21:45 -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 l098Mrgk013427 for ; Tue, 9 Jan 2007 13:52:53 +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 l098MqQW013400 for ; Tue, 9 Jan 2007 13:52:52 +0530 In-Reply-To: <5e2406980701080259we892279k8aaba84daec22a0@mail.gmail.com> To: dime@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Preeti Shandilya Date: Tue, 9 Jan 2007 13:56:30 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.5.5|November 30, 2005) at 09/01/2007 01:55:34 PM, Serialize complete at 09/01/2007 01:55:34 PM X-Spam-Score: 0.6 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Subject: [Dime] Query regarding failed 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: , Content-Type: multipart/mixed; boundary="===============1804622216==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============1804622216== Content-Type: multipart/alternative; boundary="=_alternative 002E1B506525725E_=" This is a multipart message in MIME format. --=_alternative 002E1B506525725E_= Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: base64 SGkgIQ0KDQpJIGhhdmUgYSBjb25mdXNpb24gcmVnYXJkaW5nIGZhaWxlZCBBVlAgZGVzY3JpcHRp b24gIG1lbnRpb25lZCBpbiBSRkMgDQozNTg4LiBJdCBzZWVtcyB0aGF0IFJGQyBpcyBub3QgY2xl YXIgYWJvdXQgdGhlIGluY2x1c2lvbiBvZiBBVlAgaW4gDQpGYWlsZWQtQVZQLCAgaWYgYSBtYW5k YXRvcnkgQVZQIGlzIG1pc3NpbmcgZnJvbSBhIGdyb3VwZWQgQVZQIGluIGEgDQpyZWNlaXZlZCBy ZXF1ZXN0IG1lc3NhZ2UuIEluIG15IG9waW5pb24sIGlmIGEgbWFuZGF0b3J5IEFWUCBpcyBtaXNz aW5nIA0KZnJvbSBhIGdyb3VwZWQgQVZQLCBBVlAgY29kZSBvZiBncm91cGVkIEFWUCBzaG91bGQg YmUgaW5jbHVkZWQgaW4gdGhlIA0KZmFpbGVkIEFWUCBpbiB0aGUgcmVzcG9uc2UgbWVzc2FnZSBy YXRoZXIgdGhhbiB0aGUgQVZQIGNvZGUgb2YgdGhlIG1pc3NpbmcgDQpBVlAuDQoNClRoaXMgaXMg c29tZXRoaW5nIGRpZmZlcmVudCBmcm9tIHRoZSBtYWlsIGNoYWluIGF0IA0KaHR0cDovL3d3dzEu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9kaW1lL2N1cnJlbnQvbXNnMDA1MzIuaHRtbA0KDQpG b2xsb3dpbmcgc2NlbmFyaW8gc2hhbGwgaGF2ZSBwcm9ibGVtIGlmIHdlIGluY2x1ZGUgdGhlIEFW UCBjb2RlIG9mIHRoZSANCm1pc3NpbmcgQVZQIGluIGZhaWxlZCBBVlAgcmF0aGVyIHRoYW4gZ3Jv dXBlZCBBVlAgY29kZS4NCg0KVGhlcmUgaXMgYSByZXF1ZXN0IG1lc3NhZ2UgaW4gd2hpY2ggIGFu IEFWUCBpcyBtYW5kYXRvcnkgYW5kIGlzIG1hbmRhdG9yeSANCmluIGEgZ3J1cGVkIEFWUCBhbHNv LiBJZiBpbiBhIHJlY2VpdmVkIHJlcXVlc3QgbWVzc2FnZSB0aGlzIEFWUCBpcyBtaXNzaW5nIA0K YnV0IHByZXNlbnQgaW4gdGhlIGdvdXBlZCBBVlAgYW5kIGRpYW1ldGVyIG5vZGUgcmV0dXJucyB0 aGUgYW5zd2VyIG1lc3NhZ2UgDQp3aXRoIGVycm9yIGNvZGUgYXMgRElBTUVURVJfTUlTU0lOR19B VlAgYW5kIGluY2x1ZGUgQVZQIGNvZGUgb2YgbWlzc2luZyANCkFWUCBpbiB0aHIgYW5zd2VyIG1l c3NhZ2UsIHRoZSBub2RlIHdoaWNoIG9yaWdpbmF0ZWQgdGhlIHJlcXVlc3Qgc2hhbGwgbm90IA0K cmVjZWl2ZSB0aGUgY29ycmVjdCBpbmZvcm1hdGlvbiBhcyB0byB3aGV0aGVyIG1lc3NhZ2UgaXMg ZmFpbGVkIGJlY2F1c2Ugb2YgDQpBVlAgaXMgbWlzc2luZyBpbiB0aGUgbWVzc2FnZSBvciBpcyBt aXNzaW5nIGluIGEgZ3JvdXBlZCBBVlAuDQoNClBsIGxldCBtZSBrbm93IHlvdXIgb3BpbmlvbiBh Ym91dCB0aGlzDQoNCnJlZ2FyZHMNClByZWV0aQ0KDQoqKioqKioqKioqKioqKioqKioqKioqKiAg QXJpY2VudC0gQ29uZmlkZW50aWFsICAgKioqKioqKioqKioqKioqKioqKioqKioNCiJESVNDTEFJ TUVSOiBUaGlzIG1lc3NhZ2UgaXMgcHJvcHJpZXRhcnkgdG8gQXJpY2VudCAgYW5kIGlzIGludGVu ZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiAKdGhlIGluZGl2aWR1YWwgdG8gd2hvbSBpdCBpcyBh ZGRyZXNzZWQuIEl0IG1heSBjb250YWluIHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsIGluZm9y bWF0aW9uIGFuZCBzaG91bGQgbm90IGJlIApjaXJjdWxhdGVkIG9yIHVzZWQgZm9yIGFueSBwdXJw b3NlIG90aGVyIHRoYW4gZm9yIHdoYXQgaXQgaXMgaW50ZW5kZWQuIElmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgCnBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Ig aW1tZWRpYXRlbHkuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBh cmUgbm90aWZpZWQgdGhhdCB5b3UgYXJlIHN0cmljdGx5CnByb2hpYml0ZWQgZnJvbSB1c2luZywg Y29weWluZywgYWx0ZXJpbmcsIG9yIGRpc2Nsb3NpbmcgdGhlIGNvbnRlbnRzIG9mIHRoaXMgbWVz c2FnZS4gQXJpY2VudCBhY2NlcHRzIG5vIHJlc3BvbnNpYmlsaXR5IGZvciAKbG9zcyBvciBkYW1h Z2UgYXJpc2luZyBmcm9tIHRoZSB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIHRyYW5zbWl0dGVkIGJ5 IHRoaXMgZW1haWwgaW5jbHVkaW5nIGRhbWFnZSBmcm9tIHZpcnVzLiIK --=_alternative 002E1B506525725E_= Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpICE8L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgaGF2ZSBhIGNvbmZ1c2lvbiByZWdh cmRpbmcgZmFpbGVkDQpBVlAgZGVzY3JpcHRpb24gJm5ic3A7bWVudGlvbmVkIGluIFJGQyAzNTg4 LiBJdCBzZWVtcyB0aGF0IFJGQyBpcyBub3QgY2xlYXINCmFib3V0IHRoZSBpbmNsdXNpb24gb2Yg QVZQIGluIEZhaWxlZC1BVlAsICZuYnNwO2lmIGEgbWFuZGF0b3J5IEFWUCBpcyBtaXNzaW5nDQpm cm9tIGEgZ3JvdXBlZCBBVlAgaW4gYSByZWNlaXZlZCByZXF1ZXN0IG1lc3NhZ2UuIEluIG15IG9w aW5pb24sIGlmIGEgbWFuZGF0b3J5DQpBVlAgaXMgbWlzc2luZyBmcm9tIGEgZ3JvdXBlZCBBVlAs IEFWUCBjb2RlIG9mIGdyb3VwZWQgQVZQIHNob3VsZCBiZSBpbmNsdWRlZA0KaW4gdGhlIGZhaWxl ZCBBVlAgaW4gdGhlIHJlc3BvbnNlIG1lc3NhZ2UgcmF0aGVyIHRoYW4gdGhlIEFWUCBjb2RlIG9m IHRoZQ0KbWlzc2luZyBBVlAuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj5UaGlzIGlzIHNvbWV0aGluZyBkaWZmZXJlbnQgZnJvbSB0aGUNCm1haWwgY2hh aW4gYXQgaHR0cDovL3d3dzEuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9kaW1lL2N1cnJlbnQv bXNnMDA1MzIuaHRtbDxicj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+Rm9sbG93aW5nIHNjZW5hcmlvIHNoYWxsIGhhdmUgcHJvYmxlbQ0KaWYgd2UgaW5jbHVk ZSB0aGUgQVZQIGNvZGUgb2YgdGhlIG1pc3NpbmcgQVZQIGluIGZhaWxlZCBBVlAgcmF0aGVyIHRo YW4NCmdyb3VwZWQgQVZQIGNvZGUuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5UaGVyZSBpcyBhIHJlcXVlc3QgbWVzc2FnZSBpbiB3aGljaA0KJm5ic3A7 YW4gQVZQIGlzIG1hbmRhdG9yeSBhbmQgaXMgbWFuZGF0b3J5IGluIGEgZ3J1cGVkIEFWUCBhbHNv LiBJZiBpbg0KYSByZWNlaXZlZCByZXF1ZXN0IG1lc3NhZ2UgdGhpcyBBVlAgaXMgbWlzc2luZyBi dXQgcHJlc2VudCBpbiB0aGUgZ291cGVkDQpBVlAgYW5kIGRpYW1ldGVyIG5vZGUgcmV0dXJucyB0 aGUgYW5zd2VyIG1lc3NhZ2Ugd2l0aCBlcnJvciBjb2RlIGFzIDwvZm9udD48Zm9udCBzaXplPTM+ PHR0PkRJQU1FVEVSX01JU1NJTkdfQVZQPC90dD48L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0KPC9mb250 Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5hbmQgaW5jbHVkZSBBVlAgY29kZSBvZiBt aXNzaW5nIEFWUA0KaW4gdGhyIGFuc3dlciBtZXNzYWdlLCB0aGUgbm9kZSB3aGljaCBvcmlnaW5h dGVkIHRoZSByZXF1ZXN0IHNoYWxsIG5vdA0KcmVjZWl2ZSB0aGUgY29ycmVjdCBpbmZvcm1hdGlv biBhcyB0byB3aGV0aGVyIG1lc3NhZ2UgaXMgZmFpbGVkIGJlY2F1c2UNCm9mIEFWUCBpcyBtaXNz aW5nIGluIHRoZSBtZXNzYWdlIG9yIGlzIG1pc3NpbmcgaW4gYSBncm91cGVkIEFWUC48L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlBsIGxldCBtZSBrbm93 IHlvdXIgb3BpbmlvbiBhYm91dCB0aGlzPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5yZWdhcmRzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj5QcmVldGk8YnI+DQo8YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKiAmbmJz cDtBcmljZW50LSBDb25maWRlbnRpYWwgJm5ic3A7ICoqKioqKioqKioqKioqKioqKioqKioqPC9m b250Pg0KPHRhYmxlPjx0cj48dGQgYmdjb2xvcj0jZmZmZmZmPjxmb250IGNvbG9yPSMwMDAwMDA+ PHByZT4iRElTQ0xBSU1FUjogVGhpcyBtZXNzYWdlIGlzIHByb3ByaWV0YXJ5IHRvIEFyaWNlbnQg IGFuZCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgCnRoZSBpbmRpdmlkdWFsIHRv IHdob20gaXQgaXMgYWRkcmVzc2VkLiBJdCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIG9yIGNvbmZp ZGVudGlhbCBpbmZvcm1hdGlvbiBhbmQgc2hvdWxkIG5vdCBiZSAKY2lyY3VsYXRlZCBvciB1c2Vk IGZvciBhbnkgcHVycG9zZSBvdGhlciB0aGFuIGZvciB3aGF0IGl0IGlzIGludGVuZGVkLiBJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIApwbGVhc2Ugbm90aWZ5IHRo ZSBvcmlnaW5hdG9yIGltbWVkaWF0ZWx5LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVj aXBpZW50LCB5b3UgYXJlIG5vdGlmaWVkIHRoYXQgeW91IGFyZSBzdHJpY3RseQpwcm9oaWJpdGVk IGZyb20gdXNpbmcsIGNvcHlpbmcsIGFsdGVyaW5nLCBvciBkaXNjbG9zaW5nIHRoZSBjb250ZW50 cyBvZiB0aGlzIG1lc3NhZ2UuIEFyaWNlbnQgYWNjZXB0cyBubyByZXNwb25zaWJpbGl0eSBmb3Ig Cmxvc3Mgb3IgZGFtYWdlIGFyaXNpbmcgZnJvbSB0aGUgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiB0 cmFuc21pdHRlZCBieSB0aGlzIGVtYWlsIGluY2x1ZGluZyBkYW1hZ2UgZnJvbSB2aXJ1cy4iCjwv cHJlPjwvZm9udD48L3RkPjwvdHI+PC90YWJsZT4= --=_alternative 002E1B506525725E_=-- --===============1804622216== 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 --===============1804622216==-- From dime-bounces@ietf.org Tue Jan 09 06:49:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4FTu-0000Jy-Ik; Tue, 09 Jan 2007 06:49:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4FTt-0000Jt-MU for dime@ietf.org; Tue, 09 Jan 2007 06:49:29 -0500 Received: from wx-out-0506.google.com ([66.249.82.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4FTs-0004LQ-Gd for dime@ietf.org; Tue, 09 Jan 2007 06:49:29 -0500 Received: by wx-out-0506.google.com with SMTP id h31so353318wxd for ; Tue, 09 Jan 2007 03:49:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=qXglA9iNpG64YaN1FSTGlUBb/80QpG1jP9+DV/rHISx/AafsTUpHEI9+LJGQxSgCYEZAYfOKPtgWMs3F4nJ4niStaznLo9NGy9c14uLBbb9qG22nRC0pAwbUbyX5uN+kUcvUS/1iCvgjkr+BQyn5gs53VCcYtWe+LPJ5jaHZSyE= Received: by 10.90.50.1 with SMTP id x1mr2899386agx.1168343368329; Tue, 09 Jan 2007 03:49:28 -0800 (PST) Received: by 10.90.101.8 with HTTP; Tue, 9 Jan 2007 03:49:28 -0800 (PST) Message-ID: <14e6c76f0701090349q290675fcw25d179406286ab31@mail.gmail.com> Date: Tue, 9 Jan 2007 17:19:28 +0530 From: "Nimish Bhargava" To: dime@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Dime] Result code of Multiple failed 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: , Content-Type: multipart/mixed; boundary="===============0553689046==" Errors-To: dime-bounces@ietf.org --===============0553689046== Content-Type: multipart/alternative; boundary="----=_Part_19985_5402479.1168343368211" ------=_Part_19985_5402479.1168343368211 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi everyone While sending a response containing multiple failed AVPs, what should be the value of result code AVP? since different AVPs may fail due to different reasons, should the error code of the first failed AVP be sent as result code? Thanks Nimish ------=_Part_19985_5402479.1168343368211 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi everyone

While sending a response containing multiple failed AVPs, what should be the value of result code AVP?
since different AVPs may fail due to different reasons, should the error code of the first failed AVP be sent as result code?

Thanks
Nimish

------=_Part_19985_5402479.1168343368211-- --===============0553689046== 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 --===============0553689046==-- From dime-bounces@ietf.org Tue Jan 09 08:55:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4HRN-0003nX-06; Tue, 09 Jan 2007 08:55:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4HRM-0003nO-Jw for dime@ietf.org; Tue, 09 Jan 2007 08:55:00 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4HRK-0003EY-HN for dime@ietf.org; Tue, 09 Jan 2007 08:55:00 -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 <0JBL00KJWSE3WS@szxga02-in.huawei.com> for dime@ietf.org; Tue, 09 Jan 2007 21:34:52 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JBL00FXSSE3O4@szxga02-in.huawei.com> for dime@ietf.org; Tue, 09 Jan 2007 21:34:51 +0800 (CST) Received: from huawei1515 ([10.18.4.60]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JBL005EFSDZ0G@szxml03-in.huawei.com> for dime@ietf.org; Tue, 09 Jan 2007 21:34:51 +0800 (CST) Date: Tue, 09 Jan 2007 19:04:47 +0530 From: Rajith R Subject: RE: [Dime] Result code of Multiple failed Avps In-reply-to: <14e6c76f0701090349q290675fcw25d179406286ab31@mail.gmail.com> To: 'Nimish Bhargava' , dime@ietf.org Message-id: <007a01c733f2$ee6ef5e0$3c04120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Thread-index: Accz5GfG/NxDx+QvSYizg6AoIZIPygADmUyg X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rajithr@huawei.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0034421292==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0034421292== Content-type: multipart/alternative; boundary="Boundary_(ID_VCBivsYOzv4WElY939lX3Q)" This is a multi-part message in MIME format. --Boundary_(ID_VCBivsYOzv4WElY939lX3Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT A Diameter message may contain one (and only one) Failed-AVP AVP. _____ From: Nimish Bhargava [mailto:nimish.bhargava@gmail.com] Sent: Tuesday, January 09, 2007 5:19 PM To: dime@ietf.org Subject: [Dime] Result code of Multiple failed Avps Hi everyone While sending a response containing multiple failed AVPs, what should be the value of result code AVP? since different AVPs may fail due to different reasons, should the error code of the first failed AVP be sent as result code? Thanks Nimish --Boundary_(ID_VCBivsYOzv4WElY939lX3Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
A Diameter message may contain one (and only one) Failed-AVP AVP.
 

From: Nimish Bhargava [mailto:nimish.bhargava@gmail.com]
Sent: Tuesday, January 09, 2007 5:19 PM
To: dime@ietf.org
Subject: [Dime] Result code of Multiple failed Avps

Hi everyone

While sending a response containing multiple failed AVPs, what should be the value of result code AVP?
since different AVPs may fail due to different reasons, should the error code of the first failed AVP be sent as result code?

Thanks
Nimish

--Boundary_(ID_VCBivsYOzv4WElY939lX3Q)-- --===============0034421292== 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 --===============0034421292==-- From dime-bounces@ietf.org Tue Jan 09 23:25:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4V1u-000487-Ey; Tue, 09 Jan 2007 23:25:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4V1t-000482-Jv for dime@ietf.org; Tue, 09 Jan 2007 23:25:37 -0500 Received: from wx-out-0506.google.com ([66.249.82.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4V1s-0001im-BD for dime@ietf.org; Tue, 09 Jan 2007 23:25:37 -0500 Received: by wx-out-0506.google.com with SMTP id h31so577947wxd for ; Tue, 09 Jan 2007 20:25:36 -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:references; b=bRfOPiCMqjepQCwBqwoJ4ixRJ6FfgkKj5JAu7Wq4UQFhIuBpWLZEHJ/0ssY7ZkrRMkojH1inPnPN850iIb1hGTjdN6Hvosvb0R3j0+YBWkCN0TxQyO1bkiiCZFXw6In78zcmMMNfroAjOD2TKV+rYZ2k7TPQ+k1EIfjyZjlN2QM= Received: by 10.90.118.12 with SMTP id q12mr3591598agc.1168403136143; Tue, 09 Jan 2007 20:25:36 -0800 (PST) Received: by 10.90.101.8 with HTTP; Tue, 9 Jan 2007 20:25:36 -0800 (PST) Message-ID: <14e6c76f0701092025l4fb74e52x67789adbcaa19318@mail.gmail.com> Date: Wed, 10 Jan 2007 09:55:36 +0530 From: "Nimish Bhargava" To: rajithr@huawei.com Subject: Re: [Dime] Result code of Multiple failed Avps In-Reply-To: <007a01c733f2$ee6ef5e0$3c04120a@china.huawei.com> MIME-Version: 1.0 References: <14e6c76f0701090349q290675fcw25d179406286ab31@mail.gmail.com> <007a01c733f2$ee6ef5e0$3c04120a@china.huawei.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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="===============2038267347==" Errors-To: dime-bounces@ietf.org --===============2038267347== Content-Type: multipart/alternative; boundary="----=_Part_57_25768629.1168403136133" ------=_Part_57_25768629.1168403136133 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline well it is not compulsory, diameter messages may contain multiple Failed-AVP avps. As per section 5.3.2 , 5.4.2 , 5.5.2 of the DIAMETER Base RFC 3588 and various applications specifications specify support for multiple Failed-AVP avps. On 1/9/07, Rajith R wrote: > > A Diameter message may contain one (and only one) Failed-AVP AVP. > > > ------------------------------ > *From:* Nimish Bhargava [mailto:nimish.bhargava@gmail.com] > *Sent:* Tuesday, January 09, 2007 5:19 PM > *To:* dime@ietf.org > *Subject:* [Dime] Result code of Multiple failed Avps > > Hi everyone > > While sending a response containing multiple failed AVPs, what should be > the value of result code AVP? > since different AVPs may fail due to different reasons, should the error > code of the first failed AVP be sent as result code? > > Thanks > Nimish > > -- Real programmers don't work from 9 to 5. If any real programmers are around at 9am it's because they were up all night. ------=_Part_57_25768629.1168403136133 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline well it is not compulsory, diameter messages may contain multiple Failed-AVP avps.

As per section 5.3.2 , 5.4.2 , 5.5.2 of the DIAMETER Base RFC 3588 and various applications specifications specify support for multiple Failed-AVP avps.


On 1/9/07, Rajith R <rajithr@huawei.com> wrote:
A Diameter message may contain one (and only one) Failed-AVP AVP.
 

From: Nimish Bhargava [mailto:nimish.bhargava@gmail.com]
Sent: Tuesday, January 09, 2007 5:19 PM
To: dime@ietf.org
Subject: [Dime] Result code of Multiple failed Avps

Hi everyone

While sending a response containing multiple failed AVPs, what should be the value of result code AVP?
since different AVPs may fail due to different reasons, should the error code of the first failed AVP be sent as result code?

Thanks
Nimish




--
Real programmers don't work from 9 to 5. If any real programmers are around at 9am it's because they were up all night. ------=_Part_57_25768629.1168403136133-- --===============2038267347== 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 --===============2038267347==-- From dime-bounces@ietf.org Tue Jan 09 23:53:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4VT6-0007Ex-3W; Tue, 09 Jan 2007 23:53:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4VT4-0007CY-SF for dime@ietf.org; Tue, 09 Jan 2007 23:53:42 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4VSy-0004gS-7s for dime@ietf.org; Tue, 09 Jan 2007 23:53:42 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JBM00HCTYL1SE@szxga01-in.huawei.com> for dime@ietf.org; Wed, 10 Jan 2007 12:46:13 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JBM00C64YL0O0@szxga01-in.huawei.com> for dime@ietf.org; Wed, 10 Jan 2007 12:46:13 +0800 (CST) Received: from huawei1515 ([10.18.4.60]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JBM002WXYKWHY@szxml03-in.huawei.com> for dime@ietf.org; Wed, 10 Jan 2007 12:46:12 +0800 (CST) Date: Wed, 10 Jan 2007 10:16:07 +0530 From: Rajith R Subject: RE: [Dime] Result code of Multiple failed Avps In-reply-to: <14e6c76f0701092025l4fb74e52x67789adbcaa19318@mail.gmail.com> To: 'Nimish Bhargava' Message-id: <008b01c73472$3ec60770$3c04120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acc0b2JiIlmcoakqTg6U1wIRCv9xcwAAmKVw X-Spam-Score: 0.1 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d 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: , Content-Type: multipart/mixed; boundary="===============0462715907==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0462715907== Content-type: multipart/alternative; boundary="Boundary_(ID_Rf6J/0RB3LlGCnaHq43f3A)" This is a multi-part message in MIME format. --Boundary_(ID_Rf6J/0RB3LlGCnaHq43f3A) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Since we can have only one Result-Code AVP, I think it is better to have only one Failed-AVP AVP. However all the erroneous AVPs (related to the error specified by the result code) could be added in this AVP itself, e.g.: contradicting AVPs case. As you mentioned the RFC seems to suggest otherwise in the ABNF of DWA, description of contradicting AVPs result code etc. Should we consider this in the 3588-errata? _____ From: Nimish Bhargava [mailto:nimish.bhargava@gmail.com] Sent: Wednesday, January 10, 2007 9:56 AM To: rajithr@huawei.com Cc: dime@ietf.org Subject: Re: [Dime] Result code of Multiple failed Avps well it is not compulsory, diameter messages may contain multiple Failed-AVP avps. As per section 5.3.2 , 5.4.2 , 5.5.2 of the DIAMETER Base RFC 3588 and various applications specifications specify support for multiple Failed-AVP avps. On 1/9/07, Rajith R wrote: A Diameter message may contain one (and only one) Failed-AVP AVP. _____ From: Nimish Bhargava [mailto:nimish.bhargava@gmail.com] Sent: Tuesday, January 09, 2007 5:19 PM To: dime@ietf.org Subject: [Dime] Result code of Multiple failed Avps Hi everyone While sending a response containing multiple failed AVPs, what should be the value of result code AVP? since different AVPs may fail due to different reasons, should the error code of the first failed AVP be sent as result code? Thanks Nimish -- Real programmers don't work from 9 to 5. If any real programmers are around at 9am it's because they were up all night. --Boundary_(ID_Rf6J/0RB3LlGCnaHq43f3A) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
    Since we can have only one Result-Code AVP, I think it is better to have only one Failed-AVP AVP. However all the erroneous AVPs (related to the error specified by the result code) could be added in this AVP itself, e.g.: contradicting AVPs case.
    As you mentioned the RFC seems to suggest otherwise in the ABNF of DWA, description of contradicting AVPs result code etc.
    Should we consider this in the 3588-errata?

From: Nimish Bhargava [mailto:nimish.bhargava@gmail.com]
Sent: Wednesday, January 10, 2007 9:56 AM
To: rajithr@huawei.com
Cc: dime@ietf.org
Subject: Re: [Dime] Result code of Multiple failed Avps

well it is not compulsory, diameter messages may contain multiple Failed-AVP avps.

As per section 5.3.2 , 5.4.2 , 5.5.2 of the DIAMETER Base RFC 3588 and various applications specifications specify support for multiple Failed-AVP avps.


On 1/9/07, Rajith R <rajithr@huawei.com> wrote:
A Diameter message may contain one (and only one) Failed-AVP AVP.
 

From: Nimish Bhargava [mailto:nimish.bhargava@gmail.com]
Sent: Tuesday, January 09, 2007 5:19 PM
To: dime@ietf.org
Subject: [Dime] Result code of Multiple failed Avps

Hi everyone

While sending a response containing multiple failed AVPs, what should be the value of result code AVP?
since different AVPs may fail due to different reasons, should the error code of the first failed AVP be sent as result code?

Thanks
Nimish




--
Real programmers don't work from 9 to 5. If any real programmers are around at 9am it's because they were up all night.
--Boundary_(ID_Rf6J/0RB3LlGCnaHq43f3A)-- --===============0462715907== 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 --===============0462715907==-- From dime-bounces@ietf.org Wed Jan 10 00:19:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4VrS-0000ts-GQ; Wed, 10 Jan 2007 00:18:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4VrR-0000tn-ND for dime@ietf.org; Wed, 10 Jan 2007 00:18:53 -0500 Received: from wx-out-0506.google.com ([66.249.82.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4VrG-0002Wb-6l for dime@ietf.org; Wed, 10 Jan 2007 00:18:53 -0500 Received: by wx-out-0506.google.com with SMTP id h31so589870wxd for ; Tue, 09 Jan 2007 21:18:42 -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:references; b=XZILHmKfAxANYcFRkO2VqiPF+yVUoXo8qN0XYURoGg9T2LoF0ThSQJ4o0iAxYtPF6K7mwf+du7S18hvQWb3krLj+wEOIKZPKzRyXbryYMZXSQtVibsTRCVoSm8Ezq08ZUn7+oEqrlMtUos8ezayykDTMJU1Rl9+nzstUSchWfqY= Received: by 10.90.79.6 with SMTP id c6mr3656957agb.1168406321985; Tue, 09 Jan 2007 21:18:41 -0800 (PST) Received: by 10.90.101.8 with HTTP; Tue, 9 Jan 2007 21:18:41 -0800 (PST) Message-ID: <14e6c76f0701092118y7986c310u3bcbadbe22661b30@mail.gmail.com> Date: Wed, 10 Jan 2007 10:48:41 +0530 From: "Nimish Bhargava" To: rajithr@huawei.com Subject: Re: [Dime] Result code of Multiple failed Avps In-Reply-To: <008b01c73472$3ec60770$3c04120a@china.huawei.com> MIME-Version: 1.0 References: <14e6c76f0701092025l4fb74e52x67789adbcaa19318@mail.gmail.com> <008b01c73472$3ec60770$3c04120a@china.huawei.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 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="===============0433144053==" Errors-To: dime-bounces@ietf.org --===============0433144053== Content-Type: multipart/alternative; boundary="----=_Part_371_9598571.1168406321822" ------=_Part_371_9598571.1168406321822 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline As proposed by you that all the avps having the error code as the result code should be sent, in that case we shall have to neglect all other erroneous avps.. should that be considered as a valid behavior? Also what should be the basis of deciding the result code in that case ? I mean now that we have avps failing due different reasons, which group should be selected for sending in the response? should the error code occurring the maximum time be considered as the result code or the first error code encountered? I do agree that this can be considered as 3588-errata. Thanks Nimish On 1/10/07, Rajith R wrote: > > Since we can have only one Result-Code AVP, I think it is better to > have only one Failed-AVP AVP. However all the erroneous AVPs (related to the > error specified by the result code) could be added in this AVP itself, e.g.: > contradicting AVPs case. > As you mentioned the RFC seems to suggest otherwise in the ABNF of > DWA, description of contradicting AVPs result code etc. > Should we consider this in the 3588-errata? > > ------------------------------ > *From:* Nimish Bhargava [mailto:nimish.bhargava@gmail.com] > *Sent:* Wednesday, January 10, 2007 9:56 AM > *To:* rajithr@huawei.com > *Cc:* dime@ietf.org > *Subject:* Re: [Dime] Result code of Multiple failed Avps > > well it is not compulsory, diameter messages may contain multiple > Failed-AVP avps. > > As per section 5.3.2 , 5.4.2 , 5.5.2 of the DIAMETER Base RFC 3588 and > various applications specifications specify support for multiple Failed-AVP > avps. > > > On 1/9/07, Rajith R wrote: > > > > A Diameter message may contain one (and only one) Failed-AVP AVP. > > > > > > ------------------------------ > > *From:* Nimish Bhargava [mailto:nimish.bhargava@gmail.com] > > *Sent:* Tuesday, January 09, 2007 5:19 PM > > *To:* dime@ietf.org > > *Subject:* [Dime] Result code of Multiple failed Avps > > > > Hi everyone > > > > While sending a response containing multiple failed AVPs, what should be > > the value of result code AVP? > > since different AVPs may fail due to different reasons, should the error > > code of the first failed AVP be sent as result code? > > > > Thanks > > Nimish > > > > > > ------=_Part_371_9598571.1168406321822 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline As proposed by you that all the avps having the error code as the result code should be sent, in that case we shall have to neglect all other erroneous avps.. should that be considered as a valid behavior?

Also what should be the basis of deciding the result code in that case ?
I mean now that we have avps failing due different reasons, which group should be selected for sending in the response?
should the error code occurring the maximum time be considered as the result code or the first error code encountered?

I do agree that this can be considered as 3588-errata.

Thanks
Nimish

On 1/10/07, Rajith R <rajithr@huawei.com > wrote:
    Since we can have only one Result-Code AVP, I think it is better to have only one Failed-AVP AVP. However all the erroneous AVPs (related to the error specified by the result code) could be added in this AVP itself, e.g.: contradicting AVPs case.
    As you mentioned the RFC seems to suggest otherwise in the ABNF of DWA, description of contradicting AVPs result code etc.
    Should we consider this in the 3588-errata?

From: Nimish Bhargava [mailto:nimish.bhargava@gmail.com]
Sent: Wednesday, January 10, 2007 9:56 AM
To: rajithr@huawei.com
Cc: dime@ietf.org
Subject: Re: [Dime] Result code of Multiple failed Avps

well it is not compulsory, diameter messages may contain multiple Failed-AVP avps.

As per section 5.3.2 , 5.4.2 , 5.5.2 of the DIAMETER Base RFC 3588 and various applications specifications specify support for multiple Failed-AVP avps.


On 1/9/07, Rajith R <rajithr@huawei.com> wrote:
A Diameter message may contain one (and only one) Failed-AVP AVP.
 

From: Nimish Bhargava [mailto:nimish.bhargava@gmail.com]
Sent: Tuesday, January 09, 2007 5:19 PM
To: dime@ietf.org
Subject: [Dime] Result code of Multiple failed Avps

Hi everyone

While sending a response containing multiple failed AVPs, what should be the value of result code AVP?
since different AVPs may fail due to different reasons, should the error code of the first failed AVP be sent as result code?

Thanks
Nimish





------=_Part_371_9598571.1168406321822-- --===============0433144053== 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 --===============0433144053==-- From dime-bounces@ietf.org Wed Jan 10 01:07:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4WcG-0005gY-0f; Wed, 10 Jan 2007 01:07:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4WcE-0005gB-Mp for dime@ietf.org; Wed, 10 Jan 2007 01:07:14 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4Wc3-00070r-SX for dime@ietf.org; Wed, 10 Jan 2007 01:07:14 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JBN00HTC1ZNFZ@szxga01-in.huawei.com> for dime@ietf.org; Wed, 10 Jan 2007 13:59:48 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JBN00AD71ZMJQ@szxga01-in.huawei.com> for dime@ietf.org; Wed, 10 Jan 2007 13:59:47 +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 <0JBN000CH1ZIUJ@szxml04-in.huawei.com> for dime@ietf.org; Wed, 10 Jan 2007 13:59:46 +0800 (CST) Date: Wed, 10 Jan 2007 11:29:42 +0530 From: Rajith R Subject: RE: [Dime] Result code of Multiple failed Avps In-reply-to: <14e6c76f0701092118y7986c310u3bcbadbe22661b30@mail.gmail.com> To: 'Nimish Bhargava' Message-id: <009901c7347c$860b1210$3c04120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acc0dtlP2EEd1gOIROmMR5jbtSD1FwABWYqg X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 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: , Content-Type: multipart/mixed; boundary="===============0320394228==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0320394228== Content-type: multipart/alternative; boundary="Boundary_(ID_1UhO5T/wCjDYRMMgYtVn0Q)" This is a multi-part message in MIME format. --Boundary_(ID_1UhO5T/wCjDYRMMgYtVn0Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT see inline _____ From: Nimish Bhargava [mailto:nimish.bhargava@gmail.com] Sent: Wednesday, January 10, 2007 10:49 AM To: rajithr@huawei.com Cc: dime@ietf.org Subject: Re: [Dime] Result code of Multiple failed Avps As proposed by you that all the avps having the error code as the result code should be sent, in that case we shall have to neglect all other erroneous avps.. should that be considered as a valid behavior? Also what should be the basis of deciding the result code in that case ? I mean now that we have avps failing due different reasons, which group should be selected for sending in the response? should the error code occurring the maximum time be considered as the result code or the first error code encountered? First error encountered might be a desirable implementation considering any further processing of the request is "useless" anyway. I do agree that this can be considered as 3588-errata. Thanks Nimish On 1/10/07, Rajith R > wrote: Since we can have only one Result-Code AVP, I think it is better to have only one Failed-AVP AVP. However all the erroneous AVPs (related to the error specified by the result code) could be added in this AVP itself, e.g.: contradicting AVPs case. As you mentioned the RFC seems to suggest otherwise in the ABNF of DWA, description of contradicting AVPs result code etc. Should we consider this in the 3588-errata? _____ From: Nimish Bhargava [mailto:nimish.bhargava@gmail.com] Sent: Wednesday, January 10, 2007 9:56 AM To: rajithr@huawei.com Cc: dime@ietf.org Subject: Re: [Dime] Result code of Multiple failed Avps well it is not compulsory, diameter messages may contain multiple Failed-AVP avps. As per section 5.3.2 , 5.4.2 , 5.5.2 of the DIAMETER Base RFC 3588 and various applications specifications specify support for multiple Failed-AVP avps. On 1/9/07, Rajith R wrote: A Diameter message may contain one (and only one) Failed-AVP AVP. _____ From: Nimish Bhargava [mailto:nimish.bhargava@gmail.com] Sent: Tuesday, January 09, 2007 5:19 PM To: dime@ietf.org Subject: [Dime] Result code of Multiple failed Avps Hi everyone While sending a response containing multiple failed AVPs, what should be the value of result code AVP? since different AVPs may fail due to different reasons, should the error code of the first failed AVP be sent as result code? Thanks Nimish --Boundary_(ID_1UhO5T/wCjDYRMMgYtVn0Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
see inline

From: Nimish Bhargava [mailto:nimish.bhargava@gmail.com]
Sent: Wednesday, January 10, 2007 10:49 AM
To: rajithr@huawei.com
Cc: dime@ietf.org
Subject: Re: [Dime] Result code of Multiple failed Avps

As proposed by you that all the avps having the error code as the result code should be sent, in that case we shall have to neglect all other erroneous avps.. should that be considered as a valid behavior?

Also what should be the basis of deciding the result code in that case ?
I mean now that we have avps failing due different reasons, which group should be selected for sending in the response?
should the error code occurring the maximum time be considered as the result code or the first error code encountered?  
 
First error encountered might be a desirable implementation considering any further processing of the request is "useless" anyway.

I do agree that this can be considered as 3588-errata.

Thanks
Nimish

On 1/10/07, Rajith R <rajithr@huawei.com > wrote:
    Since we can have only one Result-Code AVP, I think it is better to have only one Failed-AVP AVP. However all the erroneous AVPs (related to the error specified by the result code) could be added in this AVP itself, e.g.: contradicting AVPs case.
    As you mentioned the RFC seems to suggest otherwise in the ABNF of DWA, description of contradicting AVPs result code etc.
    Should we consider this in the 3588-errata?

From: Nimish Bhargava [mailto:nimish.bhargava@gmail.com]
Sent: Wednesday, January 10, 2007 9:56 AM
To: rajithr@huawei.com
Cc: dime@ietf.org
Subject: Re: [Dime] Result code of Multiple failed Avps

well it is not compulsory, diameter messages may contain multiple Failed-AVP avps.

As per section 5.3.2 , 5.4.2 , 5.5.2 of the DIAMETER Base RFC 3588 and various applications specifications specify support for multiple Failed-AVP avps.


On 1/9/07, Rajith R <rajithr@huawei.com> wrote:
A Diameter message may contain one (and only one) Failed-AVP AVP.
 

From: Nimish Bhargava [mailto:nimish.bhargava@gmail.com]
Sent: Tuesday, January 09, 2007 5:19 PM
To: dime@ietf.org
Subject: [Dime] Result code of Multiple failed Avps

Hi everyone

While sending a response containing multiple failed AVPs, what should be the value of result code AVP?
since different AVPs may fail due to different reasons, should the error code of the first failed AVP be sent as result code?

Thanks
Nimish





--Boundary_(ID_1UhO5T/wCjDYRMMgYtVn0Q)-- --===============0320394228== 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 --===============0320394228==-- From dime-bounces@ietf.org Wed Jan 10 07:28:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4cYz-0002Pg-F4; Wed, 10 Jan 2007 07:28:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4cYy-0002Pb-5h for dime@ietf.org; Wed, 10 Jan 2007 07:28:16 -0500 Received: from nf-out-0910.google.com ([64.233.182.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4cYu-0000EC-9Q for dime@ietf.org; Wed, 10 Jan 2007 07:28:16 -0500 Received: by nf-out-0910.google.com with SMTP id l36so495387nfa for ; Wed, 10 Jan 2007 04:28:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DhYdWohUvTGj/qSkDkKTl/iUXWs1SLfIwUwrhQ4tcKeoU6ywFrNKb5JHhVfBh3YIWbWoYvQ+koYxQvZXg8r1gL1EXXZaLvJG4tnhDwjQXvDhf5d5KY8z6cVrSSzgpwQmMfXvWP/L/YEQcRa4x8MiLEBrGWcu4KMA4cZRQTx19lQ= Received: by 10.49.21.8 with SMTP id y8mr1145240nfi.1168432091413; Wed, 10 Jan 2007 04:28:11 -0800 (PST) Received: by 10.48.222.20 with HTTP; Wed, 10 Jan 2007 04:28:11 -0800 (PST) Message-ID: <5e2406980701100428l253eef09rb3da31a882800793@mail.gmail.com> Date: Wed, 10 Jan 2007 13:28:11 +0100 From: "Julien Bournelle" To: "La Monaca Michele" Subject: Re: R: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Security 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: <5e2406980701080259we892279k8aaba84daec22a0@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi michele, On 1/8/07, La Monaca Michele wrote: > Hi Julien, > > as you said the separation between auth and autz takes along modularity > and flexibility but it raises security concerns if the HA is > compromised. Therefore, I think that it would be better to compare what > a compromised HA can/cannot do in the two cases: > > "Split" AAA approach > > 1) Deny service to regular users (i.e. DoS) YES > 2) Grant service to fake users (i.e. steal the service) YES > 3) DoS to the AAA infrastructure YES > 4) Identity spoofing to charge someone else YES The fact is that by separating authentitcation and authorization, if HA is compromised, a non-authenticated user can be authorized. This threat does not exist if authentication and authorization are binded. The question is what are the consequence of this. If Alice compromised the HA and asks an authorization for Bob. The problem that has been evoked is that Bob could be charged for the Mobile IPv6 service. But wouldn't this problem also exist if authentication and authorization are tied and if the HA is compromised ? Julien > 5) something else? > > "Integrated" AAA approach > > 1) Deny service to regular users (i.e. DoS) YES > 2) Grant service to fake users (i.e. steal the service) YES > 3) DoS to the AAA infrastructure YES > 4) Identity spoofing to charge someone else YES? > 5) something else? > > Btw, the separation between auth and autz might improve the overall > security in some circumstances. For example, an attacker may succeed to > tear down the AAA-EAP functionality but not the AAA-MIPv6 one, so > already authenticated users may continue to use the mipv6 service. > > My 2 cents, > > --Michele > > > >-----Messaggio originale----- > >Da: Julien Bournelle [mailto:julien.bournelle@gmail.com] > >Inviato: Monday, January 08, 2007 11:59 AM > >A: Hannes Tschofenig > >Cc: dime@ietf.org > >Oggetto: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Security > > > >hi hannes, all > > > > ok, so let's try to investigate this. > > > > In our current document, we have the following architecture: > > > > MN <--- IKEv2 -----> HA <------> AAA_EAP > > ^ > > | > > +------------> AAA_MIP6 > > > > HA authenticates the MN by using 4072 in AUTHENTICATE_ONLY mode > > (if EAP used within IKEv2) and we have defined 2 new messages for > >Authorization purposes at AAA_MIP6. > > HA uses identiy provided by MN in IDii field of the 3rd IKEv2 message > to > >route > > messages to the corresponding realm.Thus, in the picture above, we > >consider that AAA_EAP and AAA_MIP6 are in the same realm. > > Howver, as we have a different App-Id, AAA_EAP and AAA_MIP6 may be > located > >in > > different servers. Note that this is not a requirement, that's > possible. > > > > Advantages are modularity and flexibility. This approach may also be > >used by other > > applications that use EAP for authentication. However, we do not > require > > use of EAP. > > > > The problem that we have with this approach is to investigate if it > >creates a security > > hole to separate Authentication and Authorization. > > > > As it has been mentionned in the ML, the HA may be compromised. > > > > So, the first thing I think we should do is to catch and to agree on > the > >goals > > of such an attack. I can see: > > > > a/ DoS on the Mobile IPv6 service (shutdown) with loss of revenues > >for an operator > > > > b/ Steal the service > > > > 1. The attacker compromises the HA to obtain free mip6 service for > >himself > > > > 2. The attacker compromises the HA for a group of people to > > obtain free mip6 service > > > > 3. The attacker compromises the HA for all to obtain free mip6 > >service. > > > >c/ Identity spoofing to charge someone else > > > > others ? > > > > Julien > > > > > > > > > > > > > >On 1/1/07, Hannes Tschofenig wrote: > >> Hi all, > >> > >> it seems that we came across a security issue that requires more > >> thoughts. Interestingly, David Nelson gave a presentation at the > IETF#66 > >> meeting that dealt with a similar problem when RADIUS is used in the > >> ISMS context. You can find his presentation here: > >> http://www3.ietf.org/proceedings/06jul/slides/radext-7/sld1.htm > >> > >> We need to investigate the potential security threats in more detail > >> before we immediately jump to the solution space. > >> Who has time and would be interested to brainstorm about this subject > a > >> little bit? > >> The goal is to have a more detailed description of the security > threats. > >> > >> Ciao > >> Hannes > >> > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www1.ietf.org/mailman/listinfo/dime > >> > > > >_______________________________________________ > >DiME mailing list > >DiME@ietf.org > >https://www1.ietf.org/mailman/listinfo/dime > -------------------------------------------------------------------- > > 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 > > -------------------------------------------------------------------- > > > _______________________________________________ > 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 Jan 10 12:22:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4h9v-0004UU-4k; Wed, 10 Jan 2007 12:22:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4h9u-0004UM-I1 for dime@ietf.org; Wed, 10 Jan 2007 12:22:42 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4h9X-0005xW-Lf for dime@ietf.org; Wed, 10 Jan 2007 12:22:42 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 10 Jan 2007 09:22:19 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0AHMJD6017468; Wed, 10 Jan 2007 09:22:19 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l0AHMDUk001566; Wed, 10 Jan 2007 09:22:18 -0800 (PST) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 09:22:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Result code of Multiple failed Avps Date: Wed, 10 Jan 2007 09:22:12 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262503392DDA@xmb-sjc-215.amer.cisco.com> In-Reply-To: <14e6c76f0701092025l4fb74e52x67789adbcaa19318@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Result code of Multiple failed Avps Thread-Index: Acc0b3wY0t1e7Wv9QT2teqh49/UDtAAa5Bdw From: "Glen Zorn \(gwz\)" To: "Nimish Bhargava" , X-OriginalArrivalTime: 10 Jan 2007 17:22:14.0807 (UTC) FILETIME=[DF0E0A70:01C734DB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4852; t=1168449739; x=1169313739; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[Dime]=20Result=20code=20of=20Multiple=20failed=20Avp s |Sender:=20; bh=Z77nNc/VIbRzHH505feR95pJWZ5Lr1OPXD8ivKGu2pw=; b=ZlT4yqtU9eddCoVJIuoGzX9d3Qz+8kINuaap15uoHmeUANtvoAtnjdDbwfm3xMyRKZi1f9NA nw2o9YgoWiB7W3c2UkNdCenTYxnNMUGruhHJbmlu6ukUuC5JKdumQAdZ; Authentication-Results: sj-dkim-1; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 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="===============1110510538==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1110510538== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C734DB.DEE0CF5F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C734DB.DEE0CF5F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 well it is not compulsory, diameter messages may contain multiple Failed-AVP avps. Right.=20 As per section 5.3.2 , 5.4.2 , 5.5.2 of the DIAMETER Base RFC 3588 and various applications specifications specify support for multiple Failed-AVP avps.=20 On 1/9/07, Rajith R wrote:=20 A Diameter message may contain one (and only one) Failed-AVP AVP. Not true. =09 =09 ________________________________ From: Nimish Bhargava [mailto:nimish.bhargava@gmail.com] Sent: Tuesday, January 09, 2007 5:19 PM To: dime@ietf.org Subject: [Dime] Result code of Multiple failed Avps =09 =09 =09 Hi everyone =09 While sending a response containing multiple failed AVPs, what should be the value of result code AVP? since different AVPs may fail due to different reasons, should the error code of the first failed AVP be sent as result code?=20 I think that the assumption was that received message processing would halt on the first invalid AVP & an error returned. It might be a good idea to change the Failed-AVP to include an error code...=20 =20 Thanks Nimish=20 =09 =09 --=20 Real programmers don't work from 9 to 5. If any real programmers are around at 9am it's because they were up all night.=20 ------_=_NextPart_001_01C734DB.DEE0CF5F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
well it is not compulsory, diameter messages may contain = multiple=20 Failed-AVP avps.
 Right. 
As per = section 5.3.2 ,=20 5.4.2 , 5.5.2 of the DIAMETER Base RFC 3588 and various applications=20 specifications specify support for multiple Failed-AVP avps. =


On 1/9/07, Rajith R=20 <rajithr@huawei.com> = wrote:
A Diameter=20 message may contain one (and only one) Failed-AVP = AVP.
Not=20 true.

From: Nimish Bhargava [mailto:nimish.bhargava@gmail.com]
Sent: = Tuesday,=20 January 09, 2007 5:19 PM
To: dime@ietf.org
Subject: [Dime] Result = code of=20 Multiple failed Avps

Hi everyone

While sending a response containing multiple = failed=20 AVPs, what should be the value of result code AVP?
since = different AVPs=20 may fail due to different reasons, should the error code of the = first failed=20 AVP be sent as result code? 
I think that = the assumption was that=20 received message processing would halt on the = first invalid AVP=20 &  an error returned.  It might be a good idea to = change=20 the Failed-AVP to include an error = code... 
 
Thanks
Nimish


--
Real programmers don't work from 9 to 5. If any = real=20 programmers are around at 9am it's because they were up all night.=20 ------_=_NextPart_001_01C734DB.DEE0CF5F-- --===============1110510538== 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 --===============1110510538==-- From dime-bounces@ietf.org Thu Jan 11 04:00:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4vng-0005GL-JX; Thu, 11 Jan 2007 04:00:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4vnf-0005GG-Av for dime@ietf.org; Thu, 11 Jan 2007 04:00:43 -0500 Received: from rvil-eframer.radvision.com ([80.74.106.104] helo=eframer.radvision.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4vnd-0006kX-PB for dime@ietf.org; Thu, 11 Jan 2007 04:00:43 -0500 Received: (from root@localhost) by eframer.radvision.com (8.13.4/8.12.9) id l0B94rCK016808 for dime@ietf.org; Thu, 11 Jan 2007 11:04:53 +0200 Received: from rvil-mail1.RADVISION.com (rvil-mail1.radvision.com [172.20.2.100]) by eframer.radvision.com (8.13.4/8.12.9) with ESMTP id l0B94rAL016802 for ; Thu, 11 Jan 2007 11:04:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 11 Jan 2007 11:02:37 +0200 Message-ID: <7579E2B4F92E89429C01EA57E4E6DBBB66D6EF@rvil-mail1.RADVISION.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Host-IP-Address transport type and port Thread-Index: Acc1Xz2cvQwNBuT0TLC0LL7m4FySnQ== From: "Ran Arad" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [Dime] Host-IP-Address transport type and port 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="===============0818054695==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0818054695== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7355F.3E0EF748" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7355F.3E0EF748 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R29vZCBEYXkNCiANCkkgaGF2ZSBhIHF1ZXN0aW9uIHJlZ2FyZGluZyB0aGUgQWRkcmVzcyBBVlAg dHlwZTogaXQgY29udGFpbnMgdGhlIGFkZHJlc3MgdHlwZSAoSVAgb3IgSVA2KSBhbmQgdGhlIGFk ZHJlc3MgaXRzZWxmLCB3aXRob3V0IGEgcG9ydCBvciB0cmFuc3BvcnQgdHlwZSAoU0NUUCwgVExT KS4gRm9yIGluc3RhbmNlLCBpZiBJJ20gcnVubmluZyBhIHNlcnZlciBzdXBwb3J0aW5nIGJvdGgg U0NUUCBhbmQgVExTLCBJIGNhbm5vdCBhZHZlcnRpc2UgYm90aCBhZGRyZXNzIHR5cGVzOyBpZiBJ J20gcnVubmluZyB0d28gZGlhbWV0ZXIgcHJvY2Vzc2VzIG9uIHRoZSBzYW1lIG1hY2hpbmUsIHRo ZXkgY2Fubm90IGFkdmVydGlzZSBhIGRpZmZlcmVudCBwb3J0IGZvciBlYWNoLg0KIA0KSXMgdGhl cmUgYW55IHdheSB0byBzb2x2ZSB0aGlzIGlzc3VlIGFwYXJ0IGZyb20gdmVuZG9yIHNwZWNpZmlj IEFWUHM/DQogDQpSYW4NCg== ------_=_NextPart_001_01C7355F.3E0EF748 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI5MDAuMzAyMCIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElWPjxTUEFO IGNsYXNzPTA2MjAwNTEwOC0xMTAxMjAwNz48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5Hb29kIA0K RGF5PC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MDYyMDA1MTA4LTExMDEy MDA3PjxGT05UIGZhY2U9QXJpYWwgDQpzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4N CjxESVY+PFNQQU4gY2xhc3M9MDYyMDA1MTA4LTExMDEyMDA3PjxGT05UIGZhY2U9QXJpYWwgc2l6 ZT0yPkkgaGF2ZSBhIHF1ZXN0aW9uIA0KcmVnYXJkaW5nIHRoZSBBZGRyZXNzIEFWUCZuYnNwO3R5 cGU6IGl0IGNvbnRhaW5zIHRoZSBhZGRyZXNzIHR5cGUgKElQIG9yIElQNikgDQphbmQgdGhlIGFk ZHJlc3MgaXRzZWxmLCB3aXRob3V0IGEgcG9ydCBvciB0cmFuc3BvcnQgdHlwZSAoU0NUUCwgVExT KS4gRm9yIA0KaW5zdGFuY2UsIGlmIEknbSBydW5uaW5nIGEgc2VydmVyIHN1cHBvcnRpbmcgYm90 aCBTQ1RQIGFuZCBUTFMsIEkgY2Fubm90IA0KYWR2ZXJ0aXNlIGJvdGggYWRkcmVzcyB0eXBlczsg aWYgSSdtIHJ1bm5pbmcgdHdvIGRpYW1ldGVyIHByb2Nlc3NlcyBvbiB0aGUgc2FtZSANCm1hY2hp bmUsIHRoZXkgY2Fubm90IGFkdmVydGlzZSBhIGRpZmZlcmVudCBwb3J0IGZvciBlYWNoLjwvRk9O VD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTA2MjAwNTEwOC0xMTAxMjAwNz48Rk9O VCBmYWNlPUFyaWFsIA0Kc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxT UEFOIGNsYXNzPTA2MjAwNTEwOC0xMTAxMjAwNz48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5JcyB0 aGVyZSBhbnkgd2F5IHRvIA0Kc29sdmUgdGhpcyBpc3N1ZSBhcGFydCBmcm9tIHZlbmRvciBzcGVj aWZpYyBBVlBzPzwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTA2MjAwNTEw OC0xMTAxMjAwNz48Rk9OVCBmYWNlPUFyaWFsIA0Kc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7 PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTA2MjAwNTEwOC0xMTAxMjAwNz48Rk9OVCBmYWNlPUFy aWFsIA0Kc2l6ZT0yPlJhbjwvRk9OVD48L1NQQU4+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------_=_NextPart_001_01C7355F.3E0EF748-- --===============0818054695== 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 --===============0818054695==-- From dime-bounces@ietf.org Thu Jan 11 04:14:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4w1N-0004Xi-AJ; Thu, 11 Jan 2007 04:14:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4w1M-0004Uv-03 for dime@ietf.org; Thu, 11 Jan 2007 04:14:52 -0500 Received: from rvil-eframer.radvision.com ([80.74.106.104] helo=eframer.radvision.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4w1K-00051Q-0b for dime@ietf.org; Thu, 11 Jan 2007 04:14:51 -0500 Received: (from root@localhost) by eframer.radvision.com (8.13.4/8.12.9) id l0B9J3cp017137 for dime@ietf.org; Thu, 11 Jan 2007 11:19:03 +0200 Received: from rvil-mail1.RADVISION.com (rvil-mail1.radvision.com [172.20.2.100]) by eframer.radvision.com (8.13.4/8.12.9) with ESMTP id l0B9J3VU017130 for ; Thu, 11 Jan 2007 11:19:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 11 Jan 2007 11:16:48 +0200 Message-ID: <7579E2B4F92E89429C01EA57E4E6DBBB66D6FA@rvil-mail1.RADVISION.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Wait-Conn-Ack/Elect State Thread-Index: Acc1YTjhHTHZSIXAQ6GpbBNoJv2Gcg== From: "Ran Arad" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: [Dime] Wait-Conn-Ack/Elect 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: , Content-Type: multipart/mixed; boundary="===============0099468699==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0099468699== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73561.390490DE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C73561.390490DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R29vZCBEYXkNCiANCkluIHRoZSBwZWVyIHN0YXRlIG1hY2hpbmUsIHRoZSBXYWl0LUNvbm4tQWNr L0VsZWN0IFN0YXRlIHdhaXRzIGZvciBlaXRoZXIgdG8gb3V0Z29pbmcgY29ubmVjdGlvbiB0byBj b25uZWN0LCBmb3IgaXQgdG8gZGlzY29ubmVjdCwgZm9yIHRoZSByZW1vdGUgcGVlciB0byBkaXNj b25uZWN0IHRoZSBhY3RpdmUgY29ubmVjdGlvbiwgb3IgZm9yIGEgdGltZW91dC4gV2hlbiB0aW1p bmcgb3V0LCBpdCBpZ25vcmVzIHRoZSBwZXJmZWN0bHkgZ29vZCBjb25uZWN0aW9uIGl0IGFscmVh ZHkgaGFzIHdpdGggdGhlIHBlZXIsIGFuZCBjbG9zZXMgaXQuIEl0IHdvdWxkIHNlZW0gdGhhdCBh YmFuZG9uaW5nIHRoZSBvdXRnb2luZyBjb25uZWN0aW9uIGFuZCB1c2luZyB0aGUgYWN0aXZlIG9u ZSB3b3VsZCBiZSBwcmVmZXJhYmxlLg0KIA0KVGFrZSwgZm9yIGV4YW1wbGUsIHR3byBwZWVycywg YW5kIG9uZSBoYXMgYSBwcm9ibGVtIGluIGl0cyBETlMgdGFibGUuIFRoZXkgdHJ5IHRvIGNvbm5l Y3QgdG8gZWFjaCBvdGhlciwgYW5kIHdoaWxlIHRoZSBmYXVsdHkgb25lIGluaXRpYXRlcyBhIGNv bm5lY3Rpb24gdG8gc29tZSB1bmtub3duIGFkZHJlc3MsIHRoZSBvdGhlciBjb25uZWN0cyB0byBp dC4gaWYgdGhlIGZhdWx0eSBwZWVyIG5ldmVyIHJlY2VpdmVzIGEgcmVzcG9uc2UgdG8gaXQncyBj b25uZWN0aW9uIHJlcXVlc3QsIHRoZSBwZWVycyB3aWxsIG5vdCBjb25uZWN0IC0gZXZlbiBpZiB0 aGV5IGtlZXAgdHJ5aW5nIHRvIGNvbm5lY3QsIHVudGlsIHRoZSBETlMgdGFibGUgdXBkYXRlcy4g SW4gY2FzZSB3ZSBjaGFuZ2UgdGhlIHRpbWVvdXQgYmVoYXZpb3IgdG8gYmUgdGhlIHNhbWUgYXMg dG8gIkktUmN2LUNvbm4tTmFjayIsIHRoZSBmYXVsdHkgY29ubmVjdGlvbiB3aWxsIGFjY2VwdCB0 aGUgY29ubmVjdGlvbiBmcm9tIHRoZSBvdGhlciBwZWVyLg0KIA0KUmFuDQo= ------_=_NextPart_001_01C73561.390490DE Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI5MDAuMzAyMCIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElWPjxGT05U IGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGNsYXNzPTYwOTU5MDcwOS0xMTAxMjAwNz5Hb29kIA0K RGF5PC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQ QU4gDQpjbGFzcz02MDk1OTA3MDktMTEwMTIwMDc+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gY2xhc3M9NjA5NTkwNzA5LTExMDEy MDA3PkluIHRoZSBwZWVyIHN0YXRlIA0KbWFjaGluZSwgdGhlIFdhaXQtQ29ubi1BY2svRWxlY3Qg U3RhdGUgd2FpdHMgZm9yIGVpdGhlciB0byBvdXRnb2luZyBjb25uZWN0aW9uIA0KdG8gY29ubmVj dCwgZm9yIGl0IHRvIGRpc2Nvbm5lY3QsIGZvciB0aGUgcmVtb3RlIHBlZXIgdG8gZGlzY29ubmVj dCB0aGUgYWN0aXZlIA0KY29ubmVjdGlvbiwgb3IgZm9yIGEgdGltZW91dC4gV2hlbiB0aW1pbmcg b3V0LCBpdCBpZ25vcmVzIHRoZSBwZXJmZWN0bHkgZ29vZCANCmNvbm5lY3Rpb24gaXQgYWxyZWFk eSBoYXMgd2l0aCB0aGUgcGVlciwgYW5kIGNsb3NlcyBpdC4gSXQgd291bGQgc2VlbSB0aGF0IA0K YWJhbmRvbmluZyB0aGUgb3V0Z29pbmcgY29ubmVjdGlvbiBhbmQgdXNpbmcgdGhlIGFjdGl2ZSBv bmUgd291bGQgYmUgDQpwcmVmZXJhYmxlLjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9NjA5NTkwNzA5LTExMDEyMDA3PjwvU1BB Tj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFO IGNsYXNzPTYwOTU5MDcwOS0xMTAxMjAwNz5UYWtlLCBmb3IgZXhhbXBsZSwgDQp0d28gcGVlcnMs IGFuZCBvbmUgaGFzIGEgcHJvYmxlbSBpbiBpdHMgRE5TIHRhYmxlLiBUaGV5IHRyeSB0byBjb25u ZWN0IHRvIGVhY2ggDQpvdGhlciwgYW5kIHdoaWxlIHRoZSBmYXVsdHkgb25lIGluaXRpYXRlcyBh IGNvbm5lY3Rpb24gdG8gc29tZSB1bmtub3duIGFkZHJlc3MsIA0KdGhlIG90aGVyIGNvbm5lY3Rz IHRvIGl0LiBpZiB0aGUgZmF1bHR5IHBlZXIgbmV2ZXIgcmVjZWl2ZXMgYSByZXNwb25zZSB0byBp dCdzIA0KY29ubmVjdGlvbiByZXF1ZXN0LCB0aGUgcGVlcnMgd2lsbCBub3QgY29ubmVjdCAtIGV2 ZW4gaWYgdGhleSBrZWVwIHRyeWluZyB0byANCmNvbm5lY3QsIHVudGlsIHRoZSBETlMgdGFibGUg dXBkYXRlcy4gSW4gY2FzZSB3ZSBjaGFuZ2UgdGhlIHRpbWVvdXQgYmVoYXZpb3IgdG8gDQpiZSB0 aGUgc2FtZSBhcyB0byAiSS1SY3YtQ29ubi1OYWNrIiwgdGhlIGZhdWx0eSBjb25uZWN0aW9uIHdp bGwgYWNjZXB0IHRoZSANCmNvbm5lY3Rpb24gZnJvbSB0aGUgb3RoZXIgcGVlci48L1NQQU4+PC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCmNsYXNzPTYw OTU5MDcwOS0xMTAxMjAwNz48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBm YWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCmNsYXNzPTYwOTU5MDcwOS0xMTAxMjAwNz5SYW48L1NQ QU4+PC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------_=_NextPart_001_01C73561.390490DE-- --===============0099468699== 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 --===============0099468699==-- From dime-bounces@ietf.org Thu Jan 11 08:36:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H506Z-0004C7-MV; Thu, 11 Jan 2007 08:36:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H506Y-0004C0-Kp for dime@ietf.org; Thu, 11 Jan 2007 08:36:30 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H506X-0004iS-ES for dime@ietf.org; Thu, 11 Jan 2007 08:36:30 -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 B0685C5821 for ; Thu, 11 Jan 2007 08:36:25 -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 l0BDaO0Q010137 for ; Thu, 11 Jan 2007 08:36:24 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] Host-IP-Address transport type and port Date: Thu, 11 Jan 2007 08:31:53 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <7579E2B4F92E89429C01EA57E4E6DBBB66D6EF@rvil-mail1.RADVISION.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 Ran, I think Host-IP Address includes addresses used only for the connection, = for which CER/CEA is sent.=20 I actually wonder what it is used for. Thanks, Tolga -----Original Message----- From: Ran Arad [mailto:Rana@radvision.com] Sent: Thursday, January 11, 2007 4:03 AM To: dime@ietf.org Subject: [Dime] Host-IP-Address transport type and port Good Day I have a question regarding the Address AVP type: it contains the = address type (IP or IP6) and the address itself, without a port or = transport type (SCTP, TLS). For instance, if I'm running a server = supporting both SCTP and TLS, I cannot advertise both address types; if = I'm running two diameter processes on the same machine, they cannot = advertise a different port for each. Is there any way to solve this issue apart from vendor specific AVPs? Ran _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 11 09:25:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H50sO-0002XX-Ah; Thu, 11 Jan 2007 09:25:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H50sM-0002Wn-GS for dime@ietf.org; Thu, 11 Jan 2007 09:25:54 -0500 Received: from mail12.opentransfer.com ([69.6.255.182]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H50s6-0006dg-5d for dime@ietf.org; Thu, 11 Jan 2007 09:25:54 -0500 Received: (qmail 2196 invoked by uid 399); 11 Jan 2007 14:25:34 -0000 Received: from unknown (HELO KRISHNA) (61.95.206.132) by mail12.opentransfer.com with SMTP; 11 Jan 2007 14:25:34 -0000 From: To: "'Ran Arad'" , Subject: RE: [Dime] Wait-Conn-Ack/Elect State Date: Thu, 11 Jan 2007 19:55:33 +0530 Message-ID: <005701c7358c$5c0f0410$0801a8c0@KRISHNA> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <7579E2B4F92E89429C01EA57E4E6DBBB66D6FA@rvil-mail1.RADVISION.com> Importance: Normal X-Spam-Score: 1.2 (+) X-Scan-Signature: e16ce0269ccb2f59707d16700199d13b Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1370647859==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1370647859== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0058_01C735BA.75C74010" This is a multi-part message in MIME format. ------=_NextPart_000_0058_01C735BA.75C74010 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Ran, I think your suggestion is valid. The 'action' column against Timeout event in Wait-Conn-Ack/Elect should have been some thing other than 'Error' . The action can be ignore the out-going connection (in fact there is no connection yet) and probably we also need to send the CEA to peer. Prasad. -----Original Message----- From: Ran Arad [mailto:Rana@radvision.com] Sent: Thursday, January 11, 2007 2:47 PM To: dime@ietf.org Subject: [Dime] Wait-Conn-Ack/Elect State Good Day In the peer state machine, the Wait-Conn-Ack/Elect State waits for either to outgoing connection to connect, for it to disconnect, for the remote peer to disconnect the active connection, or for a timeout. When timing out, it ignores the perfectly good connection it already has with the peer, and closes it. It would seem that abandoning the outgoing connection and using the active one would be preferable. Take, for example, two peers, and one has a problem in its DNS table. They try to connect to each other, and while the faulty one initiates a connection to some unknown address, the other connects to it. if the faulty peer never receives a response to it's connection request, the peers will not connect - even if they keep trying to connect, until the DNS table updates. In case we change the timeout behavior to be the same as to "I-Rcv-Conn-Nack", the faulty connection will accept the connection from the other peer. Ran ------=_NextPart_000_0058_01C735BA.75C74010 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Ran,

 I think your suggestion is = valid. The ‘action’ column against  Timeout event in Wait-Conn-Ack/Elect should have = been some thing other than ‘Error’ . The action can be ignore the out-going connection (in fact there is no connection yet) and = probably we also need to send the CEA to peer.

 

Prasad.

 

-----Original = Message-----
From: Ran Arad [mailto:Rana@radvision.com]
Sent: Thursday, January = 11, 2007 2:47 PM
To: dime@ietf.org
Subject: [Dime] Wait-Conn-Ack/Elect State

 

Good = Day

 

In the peer state machine, = the Wait-Conn-Ack/Elect State waits for either to outgoing connection to = connect, for it to disconnect, for the remote peer to disconnect the active = connection, or for a timeout. When timing out, it ignores the perfectly good = connection it already has with the peer, and closes it. It would seem that abandoning = the outgoing connection and using the active one would be = preferable.

 

Take, for example, two = peers, and one has a problem in its DNS table. They try to connect to each other, = and while the faulty one initiates a connection to some unknown address, the = other connects to it. if the faulty peer never receives a response to it's = connection request, the peers will not connect - even if they keep trying to = connect, until the DNS table updates. In case we change the timeout behavior to = be the same as to "I-Rcv-Conn-Nack", the faulty connection will = accept the connection from the other peer.

 

Ran=

------=_NextPart_000_0058_01C735BA.75C74010-- --===============1370647859== 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 --===============1370647859==-- From dime-bounces@ietf.org Thu Jan 11 10:21:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H51k2-0007ol-GH; Thu, 11 Jan 2007 10:21:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H51k1-0007oT-B6 for dime@ietf.org; Thu, 11 Jan 2007 10:21:21 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H51jz-0002Y6-Au for dime@ietf.org; Thu, 11 Jan 2007 10:21:20 -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 2F9A43A7D3 for ; Thu, 11 Jan 2007 10:21:13 -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 l0BFLC7c018192 for ; Thu, 11 Jan 2007 10:21:12 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] Wait-Conn-Ack/Elect State Date: Thu, 11 Jan 2007 10:16:40 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <7579E2B4F92E89429C01EA57E4E6DBBB66D6FA@rvil-mail1.RADVISION.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 Ran, Please see below for comments. Thanks, Tolga -----Original Message----- From: Ran Arad [mailto:Rana@radvision.com] Sent: Thursday, January 11, 2007 4:17 AM To: dime@ietf.org Subject: [Dime] Wait-Conn-Ack/Elect State Good Day In the peer state machine, the Wait-Conn-Ack/Elect State waits for = either to outgoing connection to connect, for it to disconnect, for the = remote peer to disconnect the active connection, or for a timeout. When = timing out, it ignores the perfectly good connection it already has with = the peer, and closes it. It would seem that abandoning the outgoing = connection and using the active one would be preferable. [TOLGA]I think one should also consider why the timeout occurs, e.g. the = peer going down or some other reason like the DNS update problem you = mentioned below. Take, for example, two peers, and one has a problem in its DNS table. = They try to connect to each other, and while the faulty one initiates a = connection to some unknown address, the other connects to it. if the = faulty peer never receives a response to it's connection request, the = peers will not connect - even if they keep trying to connect, until the = DNS table updates. In case we change the timeout behavior to be the same = as to "I-Rcv-Conn-Nack", the faulty connection will accept the = connection from the other peer. [TOLGA]If you consider the peer not being able to accept/reject the = connection because it went down case, it may be more desirable not to = establish the Diameter connection. Otherwise, we would wrongly assume = that we have an active Diameter connection to that peer, which isn't the = case. We would need to wait for watchdog mechanism to detect that the = connection is actually down, possibly after we already sent quite some = messages to that peer. For wrong DNS entry case, it sounds better to declare the Diameter = connection active. OTOH, not establishing the Diameter connection could = also be preferred so that the problem gets immeadiate attentioan and = somebody deals witht the wrong DNS entry.=20 For the "wrong DNS entry" scenario another important factor is the = behavior of the peer which initiated/established the connection. I am = not sure how long this peer will wait for CEA after sending CEA, but I = think it is very likely that it will drop the connection before the = transport connection establishment attempt to the wrong destination = times out. The nice thing about this problem seem to be that whatever behavior one = chooses locally, it won't break interoperability.=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 11 10:57:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H52J3-0000Cl-Nz; Thu, 11 Jan 2007 10:57:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H52J2-0000Bm-3K for dime@ietf.org; Thu, 11 Jan 2007 10:57:32 -0500 Received: from rvil-eframer.radvision.com ([80.74.106.104] helo=eframer.radvision.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H52J0-0004Ik-HC for dime@ietf.org; Thu, 11 Jan 2007 10:57:32 -0500 Received: (from root@localhost) by eframer.radvision.com (8.13.4/8.12.9) id l0BG1eM7026082 for dime@ietf.org; Thu, 11 Jan 2007 18:01:40 +0200 Received: from rvil-mail1.RADVISION.com (rvil-mail1.radvision.com [172.20.2.100]) by eframer.radvision.com (8.13.4/8.12.9) with ESMTP id l0BG1e3K026076 for ; Thu, 11 Jan 2007 18:01:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: RE: [Dime] Wait-Conn-Ack/Elect State Date: Thu, 11 Jan 2007 17:59:24 +0200 Message-ID: <7579E2B4F92E89429C01EA57E4E6DBBB66D7D3@rvil-mail1.RADVISION.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Wait-Conn-Ack/Elect State Thread-Index: Acc1lI4IFUNQXroPS4GiwgFFm/TmuQAA8hjQ From: "Ran Arad" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by eframer.radvision.com id l0BG1e3K026076 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 Day I have considered the interoperability issue: if the remote side did not close its outgoing connection during the timeout, it should not have a problem with it being used. As for the remote side crash: currently, we decide that an error occurred and close both connections. In the suggested scenario, we close one connection, and try to send CEA on the other - if we get an error than, we can close the other connection as well. Ran _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 11 11:20:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H52fE-00041S-BY; Thu, 11 Jan 2007 11:20:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H52fD-00041M-5L for dime@ietf.org; Thu, 11 Jan 2007 11:20:27 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H52f8-0000m1-2H for dime@ietf.org; Thu, 11 Jan 2007 11:20:27 -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 7BC5540DFC for ; Thu, 11 Jan 2007 11:20:15 -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 l0BGKFCu023005 for ; Thu, 11 Jan 2007 11:20:15 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] Wait-Conn-Ack/Elect State Date: Thu, 11 Jan 2007 11:15:43 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <7579E2B4F92E89429C01EA57E4E6DBBB66D7D3@rvil-mail1.RADVISION.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 Ran, > -----Original Message----- > From: Ran Arad [mailto:Rana@radvision.com] > Sent: Thursday, January 11, 2007 10:59 AM > To: dime@ietf.org > Subject: RE: [Dime] Wait-Conn-Ack/Elect State >=20 >=20 > Good Day >=20 > I have considered the interoperability issue: if the remote side=20 > did not close its outgoing connection during the timeout, it=20 > should not have a problem with it being used. [TOLGA]Yes, this is true, if the connection is not torn down yet it can = be used. I also do not see any interoperability issue, whichevery method = one picks. It is just a decision based on the expected behavior for = certain cases. >=20 > As for the remote side crash: currently, we decide that an error=20 > occurred and close both connections. In the suggested scenario,=20 > we close one connection, and try to send CEA on the other - if we=20 > get an error than, we can close the other connection as well. [TOLGA]If you send the CEA, the Diameter connection will be seen locally = as active, whereas the peer may be actually down. If the peer crashes, = it is not very likely to get an error after sending CEA. Not the end of = the world but could be nice to avoid that. >=20 > Ran >=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 Thu Jan 11 11:41:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H52zq-00068W-KL; Thu, 11 Jan 2007 11:41:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H52zp-00062V-CU for dime@ietf.org; Thu, 11 Jan 2007 11:41:45 -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 1H52zn-0005VL-Si for dime@ietf.org; Thu, 11 Jan 2007 11:41:45 -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 l0BGfXMC081504; Thu, 11 Jan 2007 11:41:33 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <45A668BE.3020201@tari.toshiba.com> Date: Thu, 11 Jan 2007 11:41:34 -0500 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] Wait-Conn-Ack/Elect State References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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: > [TOLGA]If you consider the peer not being able to accept/reject the connection because it went down case, it may be more desirable not to establish the Diameter connection. Otherwise, we would wrongly assume that we have an active Diameter connection to that peer, which isn't the case. We would need to wait for watchdog mechanism to detect that the connection is actually down, possibly after we already sent quite some messages to that peer. > Right. > For wrong DNS entry case, it sounds better to declare the Diameter connection active. This maybe a more optimistic and cause more problems that it tries to solve. I think the current state machine takes a cautious approach on by closing connections on suspect peers given that we cannot tell why the outgoing connection failed. > OTOH, not establishing the Diameter connection could also be preferred so that the problem gets immeadiate attentioan and somebody deals witht the wrong DNS entry. > > For the "wrong DNS entry" scenario another important factor is the behavior of the peer which initiated/established the connection. I am not sure how long this peer will wait for CEA after sending CEA, but I think it is very likely that it will drop the connection before the transport connection establishment attempt to the wrong destination times out. > Right. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jan 12 09:36:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5NWQ-0005mQ-OD; Fri, 12 Jan 2007 09:36:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5NWO-0005XV-Tl for dime@ietf.org; Fri, 12 Jan 2007 09:36:44 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H5NWL-0000yX-71 for dime@ietf.org; Fri, 12 Jan 2007 09:36:44 -0500 Received: (qmail invoked by alias); 12 Jan 2007 14:36:39 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp017) with SMTP; 12 Jan 2007 15:36:39 +0100 X-Authenticated: #29516787 Message-ID: <45A79CF7.8080002@gmx.net> Date: Fri, 12 Jan 2007 15:36:39 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: dime@ietf.org Content-Type: multipart/mixed; boundary="------------060003050903050403050801" X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Subject: [Dime] [Fwd: LS for your Organization from ETSI TB TISPAN] 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. --------------060003050903050403050801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, we have just received a liaison document from ETSI TISPAN regarding the Diameter Auditing work. Ciao Hannes -------- Original Message -------- Subject: LS for your Organization from ETSI TB TISPAN Date: Fri, 12 Jan 2007 15:13:06 +0100 From: David Boswarthick To: , CC: Aline Luther-Ascencio Hello, I see you are the identified contact(s) for your organization for this Liaison. Please consider the attached LS to your organization for your next meeting. If you are not the correct contact person to receive such documents please let me know. all the best David David Boswarthick Technical Officer for ETSI TB TISPAN ETSI - (European Telecommunications Standards Institute) Phone: +33.(0).4.92.94.42.78 Fax: +33.(0).4.92.38.52.49 mailto: david.boswarthick@etsi.org http://www.etsi.org --------------060003050903050403050801 Content-Type: application/x-zip-compressed; name="12bTD184r1 LS_to_IETF_on_diameter_auditing.zip" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="12bTD184r1 LS_to_IETF_on_diameter_auditing.zip" UEsDBBQAAgAIAJx4LDY+rBr0thwAAACaAAAuAAAAMTJiVEQxODRyMSBMU190b19JRVRGX29u X2RpYW1ldGVyX2F1ZGl0aW5nLmRvY+xdDXQUVZa+1d1Jd34akpCEfykgYEDoNAiIUWMIBENg EEJU3FGGTnclXdDpbro6xIx7FJCZYUbH8axHj+OMIrM6x1FW2XVmPaN7/JlRd3QcxT9cXV2d M+66o4wTf9YRRbPffVXVXV3dHUMED2Iefnn1/u57995337v1qqrd/3T563v+ecIfyRYayEmf DRRRoSVPAlrMRBlRq5H32cDAAGedAwyMhK9UOHjbwzR9Y5GL6KOKB1OaRYDimyqIRlHHpo5N F/ku8lFWKHJV0+JFmCvLJIFnivT8OOUOAwOjP/faDLeKv60FlIqt1/niSguFDUZ+8djseDHi JsRzEEcRX2SpH5tKdBDxAeSvQjxtnJ6fLz5/fO74HZnIgbhf1tNDiWsQf3MaURgNf4vER0hX YjxVOaRp8m32Zw/5xmXGTDcXPTM2+TMDpxfA3GehXTXS903S8+0x0//fHHTs6XfkTPpm+yMN VnkPRs9M2/kcbjDpmfw8gflSinhfw0Vv3nPSv0tmPXPeNUzQ5WIf17enECVR+2zI1W/MPyv9 +2fo8cyJ4NGSHq68cvFRaaFrnw9PoXyvI3v+WPU92Dwc6rw056N9XuYLlej/51+gP1POn2cn 9vWE4xDi3yB2YcV7bBTRMk9mORnlHLjc3t4atx5hPGDstg4qlWgkjIQvFLyr1ICqxaLyumQg qXQr0aS3XU1GlHr3up54PJZIyp2xhBzoCalJNdolq1F52Yol32hub26T3W7v8kSsu97tdp+b 6ApEVS2QVGPRevcFscRmrtyViPXE5VPl2ngilowFYxFtltu9JI7U1kBEXob+uG27EgxH1SBy lsaiyUAwWe8+L9IpN8VC6MztblPikT45Gat3LwtsVUPI13oDiWRYDW6Wa8fILReuaW5btWL1 Snlad0CNoF6Iq/k60tUalaSm+mKJrmmyVJm/tEqeZfbW0SfXqp1yQtnSoyaU0Cweprc9ls3p iub25XNk/guxfKNZvuAct9vgQl6jJDSu0xoLR+VVsZ6ucFTpmyO3BKJRRZPbtWA41qlE1S63 W5nLQ6935+JmE1r7IkbrxmhssxrwBWPdzEqeoqo5ci5Cer++dL+NXd2X+KJKkknlLawSWo4l wPqSoM7zerd7RRSTotuQASroRXXLlKCq4UJug+AULamE6r2roGV5vt+/UG5uX7dCbl+xbs2S 1XK8pyOiamElJKtJTe5UE1oS0o4oAU2RY51yMqxkVF99zmo5kAiG1aQSTPYkFJ/cHla1jCzM zGCkJwSKIaVTjao8II1pdfZExegwvzC5kQ/hB6IhdNepJJRoUJHjMTWKUWC2od9uuUNJ9ipK 1Jee6IF4PIIJqpPsRSu9D/TFtqEpW5UEqItxx8CAnbJP9nrbP4cjmdmJZmYxcbU7HhFWKXrn PsJqV1gObIVSAx1qRE32yVBTLyxOZ0tTEltV7joSSLKS0PsKTYM2WL7QRQimhEsNTcUQuU0n iMXABLpXWAZgIIYrRdNYYmANTSyD98lLkuk2nVgC5IAcT6jdgUQfpKglA9zKHG8gSwN9hqgH Fwj65LnREQhuxiKSSTa9HGncdQw66ezhYcbEWJWoJiiEA0nRT5B5TabEg0GnVBuNhYRoYCRR HpbWFw3KvWoyjLyuQCKkMT3QUBMstDjGpm5VQEUT81zjNVPj2QhBdmhCoMyyZYTdWN14wegW 6kz1i4GnBa1huvGaY5VHgDlLYgHtiCharFuRI2q3mp4FzFaKmLm8mmZhjCQIawqBCg9b7VSD 5nrG08lUQRuI9ySMebAk1K3qjPEaloAw1/V0aH0w5G65tm3J0nWzUrT0gXxz3sUsnw42iIjC k6tD50hNyr3gIGXmPqao8aoQTfJqzqyzDII9iYSeFY1lDM8yWVOiZAFmWW2PxkVpueps5ZtU oViwh+kLm7SKO4zRRmNJWE4oPW/S63pvxo7GAwc7akhJcKYukz6+DNj0nXPfrFV9WMEy1uhw Mhmvr6vjCaz5VCXZyRtSXW9XXUjtVupCiUBncm4Hb4hzOWOuSXYuRKbN9c/zJS8Ry/hRIFM1 y5cxD1lTmJrKJfEErwearFncAhYSi0aOsdghljT3PJ8C2mYtLUioUl82ISXRSOV5ZZLJJ2u0 MuQrqqU6wLIWFTMcAwqGLQTZAIJBJc6zx8oIZosS1e1ZFdtXulvYU1Tptc4/bdgTMKBlSAX7 MRcbe5s2lM2NzTmoKCExR9tS3XnZ2PSGzevk+Yvny37/qfL583z4J9dih100179olux1er0u r/HX0s30ef4OVSsqQtS+bP369V5b6fwmUTofpfMWL0jM866LxcNqQF6CRTcegxXP8c6bN3fe QhmbvNLdgTWUuwQV74gP/ZUOhUQS7l4rgDHABOAM4EzgLKABaPLod7jLgXYgBmwBtgE7gOuA 3cAtwB7gTuAB4EHgHeD9P73w+EOP/+udu6/dde22XfiTCOy69rzm8zIHMsW5iaPqcHjl67S0 tYLO80gbWh3U3VLq0oDqdIk1m6ZWhV/zn452k0ftpabZklkhgDgeZpITq8OzJ1+bu2yUXmYW UKWVWip3rDV3kWe7WVBtzV/o2Y6iXFTKdCpjqsI/PP/FdG3OLNP7t7StttUy8yfa8pe2ygYv tXSSrayei2tTxZnjtxTSOFP/pu6temedNwN/s6opI/GmNfGyNfEja+J71kSfNRE9llO7BGzd WknVNdKKTj4q6Qq1X9pJo4icNZkFgRqjjNyiUKRZVPyIY3NITMsaaaxZ3XF9hDwH/OT4JR12 lU6lwhZXtlmVpY7nXMYxTeWHuBj7oRNS5z8TDnj4NIcxMX05KX05OX254EAhScXOCAU+dMqS l/k6kypvrbXzVmbwZiu08ScFaiSDPw/r/5lyoiUVRJ9+OrIcfn2Cy0WS5Gi2rOtxy7q+Hfil tXrGUetPrIk1Q6s2zCAs8I38FnhZEVvgE55sC7x6rGl5R90CB1lZHLaVxWFYnuAjcZzxQYXb LXu4uX/n1/sN1sTMrKFuYR5/J2XzWHBgXCGuc8HGvv35pMk+X5vxmAP8nGSgUJfGkOJsiRnH 6Cwxs69J6dzJ6dxMiQ22e3y+/s+XjjP9u0x/bVQR0WjgZKAWeNc6hD/ZlJwO+asdP0HMymuc I7Myx6wsYP/8r0A/UAy9lwBey1yYBcwG5gA+wA80AGuANqADiAM7gJ3AVcAPgVuAO4BfA/cB 9wN/ful3L/3bP+25/srL91y/pxf/Ra7fs7E30rt6Y27FTXd4tjs3heGhFHqkqvB106sp7a0b dwdjzbsGWz48cM6xefd2b//I/PcjuzeYZI7AWjt115LvbkauCivSW8ZdkL+1PLvG590nnSKk 9n2HIbU0tRx1aUKtRces3zrWn1UJl+e1/c7jzdCH4e/DlfY+VkLO3e5Z3r/wWyhcz/CNxbqx 1nUirxvkqrPY9FqLTV9RdDz5fzsLTgz/r2J4fByzO0kqvMKybk8rxppb/EX9v0WekZ02n/4/ LDje/D/el58FngNeAA7wPg04MA9cQAFQCEwBZGBqcXqe1AC1wGxgPnAqsBBoApYBzcBGYBOw FVBgNl3AZuAHwNXAT4A/Am8A77/52puvPf/ab97Exb1791x35eWv7b1879ZuVVEDF18YuFi9 WMijOtxa/rKIi/xXiLipfLeIeb/leE/4BaIy674sdury1Fnb0tZKkZVv7x5j8wuO/Kwvt69Q mcsnMPycle7B/Jyh+TP5vKFxVqpWr2KaqcdZFj0uKB7Msb/Tmrgp75nfCRGERUs2i5aGYO2n sbX/zZPL2ieQNEm6rIgKO7JsPcOu9zsmHHDpNu3S7dml27LLbse7pGH7OAULLDa7tHjIvt/X QYdiN2suOvLdjNW7upQVnL2b7XfYx3csdjNj/bftZtnzhpxLbWt1p7FGfwzRfALcXE60G7ij XD8nfq7cNke25U1cOozE1ryJLXlLYoMoX9J3za7Qp+GLcMWe2vfUV40rsV2USjR6J/YGYAOw cWeqROj/rRNb/6W875aWgn9gInAq8AesGHdC908Dh4A+LBrfBr4LPA78HngS+ANQVoa2QCXw a+Cmcn3O3A08Dew35s2zwPPAC8CLwH8ALwP/CbwK/B/wEXAI+AQ4/NEHHx3uP9h/+I3Drx5+ 9o3H3zj8aP/D/fcdvO9f7tL//XRn5OAgiq+rCu8o92HHm7rsNmO3Fs//JhkPxWTcA5e49GeA Gq7y1Zfz1J+WXd+szBW5Cnsir5b4iEabuzKnsCOXVoV5OlaLv6KW/1YRi6lZZu7V7NXwXk1V wj/4UbHwD/R8nQpfGd5Pqg+jtFAfGVM1ezG9JdN74poznjP0csDQy0uGXl4x9ML6+NjQyfgK olOAs4HGCv2ZEX8jkvHY6Ogm3rYm/jy0aq9aE88NrZ+njs9HNKn1qmg09nC3lJClW6dgf3rk W3CFSzivgKSWmY6K0POfcV2RL8Esy3nPL3Isr2gaK62XHaNwA63XuRhXXSGeumJtLGO9joEO x1Xo+pWBBpt+3/uvJ967/9579o48Mxt6yLZxXglMq5ycWjfsKwwvHDNTpYMuWWSrl2+povFZ vaWWKM8imrmmiOZdE5bq4zdsXk5T9u3wyfseWzJ130LXtH0F7unX3FJQA8zYhx1n36OOcUDp NY84RjR8YoR4hncjXS9LU7eSIywtPICVxdniQiw5nGWTpm/FQuOavlVylE2qP79E+EHCDREe iL123YESySHuU/jIQvgc/PWKOHMYvMcnPDqNq8dyj094uMerx+brMV1b9Fjw9e3xwS/Q43A9 0HyDxA5kOryZQxap4oyDtRQDbpQv+6Kzef/jb/Uduu+p8qt20B208hclvEzx6elE4m+2Arhv UBH7qAM3DRr1IidBSQojN0ibqZEUpDSkfChPUBdavW6jyF+KdqOdShHUjVH9MOn2rd/+wRmT L2+5e86Oix/5zslBHv1tdxJ95fX4lWfgGNru13hF5CPEY2be/AXuJphWmKIwsQiuemBknFKo D+YXRc5mmF8ApUFcd+cw7IYswz5Sim8fSxYnEP/2QgAd8xA0dNuOv0EMKUadyIliMF0YWBeG cglKo2LNyWazKYvN4VD9yhv5KhsDu5gByWSgw8MD7/DYp/x+h1lupbZL+sdc1Bxpavpo9zt0 qiyO/Y6jKI50B5ni+AoO8jvH0gtgwmHM3yS83nqqwz+2gBgsgWe+KuZ2Z2qPrsM+zn9DKOlG GV8lYCudqDVX7PRcEsW1WWMuSntEKilKupCTQP4W0J9LfpoH2knYUS673HUcjW0kjISR8PUI 33WMoQqS6Kc0mlzWg8eRMBK+xBAmanx3wIGYf0NHPJumQlot9jv2VyNIzyJ+XOv0PjaKXD8o 4LPtfRO3ISysodNqaHENnb7MQS38+Y4TtwTntjpoLfCtFsnV3VLk0YBkS5HrGpJET9dYeiqC F6ygl5CxN8rYD4mWwi7QX0GNVFgjiaP2Rx00euejjvKdZ3xaEernJ/a39lNG940zeQQbUGkj KvFIpugHr/kHlCWLZbSk8b2BPYhLU79RVI2Ugv2dd3H23GVaI04ZAhgt/41DcjIth7yixh7e Rmrj+wP3IE5TKYV/H4B/EAEt2SbdSfoTxdQDQt0xcwrHjH9tpgR1anHT88HAw4gpRdMt6Mi0 CrLTRN/m4fACmtIo0XuIS11pnZqSVoi/hvASP8XwkOP0soQsOUQrGa0cUmar5cIbSqZaldla LaLzGn9G5dIi0Uo8vxVa7YNkuE1EaHazkEHDbKlptoMPyAdQ48fobZrUIqTEr8lyjSYhk4jo Mwre2kHjEoO3CqoUr/mc2+qEOp20AQi06j+axm9RVPJgKP07PaPg0o6W9LcrNl0NV8uvS8dh PJ5meP5yhxv3d9PJb7ayBrnA2s76oz+VY/a4zbwxxl3imcBZxL/gp3u8zcByoJ30X2bbYjyn 3w7sAK4DbgH2GO/2mOM9Gajl3/sCZgM+vqUC/EADsBZoAzqAK4CdwFXANPFGE1ENMAuYDcwH FgALgSZgKQBjoWZgI9CJGdYFfFxI9AlwcxHRbuMN8meMt9OeN95OexF4CXgZeAV4FTgEfAx8 AoyHnE8BzgYajbdaxHuLfstLCtts7zTmKftFVhkY3C90MmjZj3OVPa+Xfdn9jdA8YprSlz3O kTlx/Mv6ROCd3ziU8vA+WFmmzBIZT3+HWSYdg3bSIDzY2u0vyqDZmHdOuMN59l7smO4ToR2X jc6n97zttg1SpstzMJpH3h98szz8PVn29fGBDhi+zysjvs7IvnYENO/MX+Ye8XVGfJ0RX2do a+RgZTfSIHvsMNsNVlacnwd3vvOCg7W3uy99PPsMQg9t7hsH8ROGW5arP8bBBwbvb7g+RPgp 8rss/WFLFYdVD03+UMgs1Z8IhX6HeYxl1C00UET673kzZpP+mYEdCdIr81f0/CUdv03Pb9Ty W7PcF58KVRovKEww6jYbv67Cv7xQa3xxzV9hTje+vOI9/DmDRok46xLfsBB/uYNsqjD8nCrS f4edn2yON2jzG7s83geAvwLFhj9yH/As8AJQAIanAH3g+EmgzKOfW41ZXzlQtVP83Wb9i377 G3VZiZ+qd5TqcnLYYOq1kU56t0ycf4lTMNq2bRv/aFQZGHD0/4Numv0es4GLGXP2+wWDrv5a kV/UX5bjiNhBxaIdP50oMOo3CYHo+UyLJbWOSvpP4pcUJO7192J+D/C3GeRyslLPdkqi7/J+ lzkKHlqL0Fd6aLxIHPHQPOmDUd5zvSDUBcSALUAvcAmww9DLc4ZOZAjwUKEO1ks56NxUpGO/ 4f+ZPqB5FjbYedhHhn84rlj3ERss/qEb8nPTJAtcOeAwrhy2kgL8NeHI4NPOz5WYJDc68/O1 F7jnKPE32/CDs/k0cWqO9FB4TPMpGTbcYOF5dA6+awy/Ph/fu4fJ8yGbz5/Jqz5WV+qvy8iz clZwFLR6NGdpbk0NZRZyiUQ3bPnt2vQ9pwN5txnPLtkW/9so4P+TyK9OdtJd8wvIebqHNs/x 0qkrvfSzM0bRzKbRdLuznG6fXk7fX1xJq/6+mu5aPY486yfR7rYpdMsMme6fOZU2NU6lh0pm 0IyOGbRy9UxavnYm3a3MpAvOOZmCl51Ca8bPIe2kOcQv+fO3FYsW+ejpxDxyu+bTzzctoqe2 nEY7Vywm/iT45pJ6enZVPU0fcyZ9cvJZtHLDWVRY0ECX1TVQmb+J/mdaM7U3NBO/jT9HW073 Os+hN4rOoZtoNVH0XKq/aC1dOK6NqirWUfVp59PD/r8j/siAv/04e8UGzI8Ave0P0KExQfrV +P9v79pjqq7i+Od3X15A4+IrTJKfOFMnXEChUHBwA9SrPNRLiRnYFS7jKnB5XPJRmayctTkD W+iIzNZqOMusXHPaH+TMbNO5Hi4N1nxsprXUMk3blM73nHPhXhADtM3q92GH37m/x/n+zu9x fudzzud8TwloLOMaYylSMpehqaYMBU9WYm1kFSrv92JNkRdhQSvwc+pqnDI/gz+V5xCnroU3 qg7DJtbhTGwdaNiQKW4dYmvWoXTmehTmv4Tmig0wuTfiakE9vjQ1YG1EA36yb+L9LqUhryE5 vhG/5DZiVF4jFi1qRHHwFiyd1ITYGc1o8DajafkbeGfqVtAQJLttGzaY3gINgqJhCl8N245P wrfznp+3M95HlnEv9ufuhfr4PhQUteJl034sivkcyREHcWPsQWTNP4iOGYcwc+VhFFqPoj31 KJJsR1E442t8Zv4GvxZ+CxoQPjfrO5CTxA8KjiNizXGkrD6BncHfg4ZDfapvw+XpbVi8oA2z l7Vh2PB2XB3RjmZXO2j8DfULDU8+hU2Zp+FIOAPbs2dgCj2LD51ncaH4HJqizuPA/PN4N+4C Xom7iB+mXcQqxyVsnnUZK0dcQciUK4iuvIKW4X/g6eXXsHjETf5s/hvbK9KDu+rQOkWERgUG /99b2e+BxgeSlv8xt9unIy2UMYQMeZUzwquGUFUgo7PfVX7NfZ94qhalKaxWkEbVGYXXEh/j 3Yik/1zB/tNa/2HcYi9R+dH5qkB+cSqcZo2sp1PSmfRGg1GnN6xfDapXrfWlI5NgN19It2p4 V62L2VOxgGtNndxvZiJLRwejUdEpg0w64yB5uH/9hFeLHVjFjlnKxWTA1Ie49RCTQUfo1bqN VW7dsms4sfMYdsoGfowz8BhFnrGTS0fL+eYoltt484ZwXKJBr6V8l5HL3yspZUFcCzpVqhI9 YabPq5Gv01vCeqwNk3bG6sGrX9q8JwNBomGbcTd2o65uaAI9JqP4NDZEHQ4HiXAn6GqHN095 oYruk/m2+8/Op/9BlzpYuaWkMupk4F3mz/cWhBCAFUsBqSj8/Roqf0Uhnm1/lAsRVMRwUYKd Pcl29g7ksndIZcs89juPFbDZLOSwmOjcL2fFbBl7aklgMImtoSPmsT1zMC4gzWy23dUpoYzm Kdr4Mp79xbCQyOIk1SiClcWmcO77sBRf2KQMwcXPrJYPESFxggXpLFYtBRRu/n6rmMOlHm4u w/7HcJMVS0al53A+urAn17352/XcUsuOBjMmT/j4BDEh8u4YJrfXy9u+RTLnA7KAuyYZt0UR TDpCEfR6oiK+GimKYNf5imCzxYpgy/Q1IvZKhQ2x3mZFMN8WRbDfXYoo3fYo4svZqgj79OgQ 4aPZ07gjczVGzbLb7I7cHNWRZ8vLzM7MyVPzXOU0KYZL7Eszv/n7PlezXS5y8h6tOmzRaqer cyt3cw5xDNm2lZEH+6xamsIAcr1PwdM9TnnJoYlSyqzFHq9YR60B6aXV7hqv21mhzqmlqSn8 j02QcWoxyHYXVXtqPCVeNbekhCb1WOipLuYMm+GphBSdL54Seq5lzBcKj9dvPEKzj+nlPdLL wpSWVKDqtXJQgwYNGjRo0KBBgwYNGv6X6I3/817dY0eONVtHW17dzPh/9PWd1D5q7LbOK1uX h0i+Sa3VxNlXQnD2F2VbwDaItoAWiPaDXRA913sgerlbJb8+BMHtSeBBvdvHIdI+Kfl0aDfO 78+3iVvzSc0crqJql9dZ7XbyoTB6adOnBNDLJi9a7ogM4fYhz+NWyzEWkbdxfWtfGGwRpzhG ZpnPpwsfIWco03XxcFWuTpLXPE3+1sn8Lplnz1gym2YJdHTm2wbRUh8u85KKOL4MQle6vrxG 4t4a9xzZeRlOD9bzNpvCTtXFrc6dJum+c38FPe3mI5nb0fdiNxJ36g6ip81UZtXfVnebUbg7 vmX87WolnAYNGjRo0KBBgwYNGnzwcU295NJGycWov94sOWWw5MKDEahGtyBQkU7821+VTvyU 5CWkcBvN2xo6Oh6UxDhSct+xkveMk9vHQ0wsNAHkbUL4/CD1/WSIPvsYFqwsxEII+clPB0lC pkL0nSdCuF+gtIhTT2NhOgvJCFTZ0Xbi2sSlSUSejkDlHW2/wYJdxn3hv4YF0q+GynJOnkOq A+dn/luMhFHxpcV5fJBoS2oVm2f671v5etWPpE2Yi64BGxlcdOMc8PMbDJ0SMMNCH8BnZpYy uXg/jygDwX3MviLfmb7aJ53KvvEivpCz9mJ2HTyMz9fy9pSKfnhhe4DZ18n3tq/2CUlCk8SO c3Cr5bxdYRXszHpJp18Yas/x3FZ+NHEA1/8Rv+tv7JHz/p1PErNvkHnvq/1UP/sKe/M9XP6V y56CZf2+/0O5tLN/+Sfczdl0BmLfv/z/L5ZrGvoGhd19fbB4hrqX3fSNvqUGTc3wFNWWuyq8 vGqQ7aB1bBV/pyhu9W23JuH3aR9VadWsexZ/AVBLAQIWCxQAAgAIAJx4LDY+rBr0thwAAACa AAAuAAAAAAAAAAAAIACAgQAAAAAxMmJURDE4NHIxIExTX3RvX0lFVEZfb25fZGlhbWV0ZXJf YXVkaXRpbmcuZG9jUEsFBgAAAAABAAEAXAAAAAIdAAAAAA== --------------060003050903050403050801 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 --------------060003050903050403050801-- From dime-bounces@ietf.org Fri Jan 12 10:16:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5O8j-0005dL-Fi; Fri, 12 Jan 2007 10:16:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5O8i-0005cI-0M for dime@ietf.org; Fri, 12 Jan 2007 10:16:20 -0500 Received: from jaguar.hughesbpo.net ([61.246.186.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5O8f-0002nL-PR for dime@ietf.org; Fri, 12 Jan 2007 10:16:19 -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 l0CFHNQB015033 for ; Fri, 12 Jan 2007 20:47:23 +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 l0CFHL04015007; Fri, 12 Jan 2007 20:47:22 +0530 To: dime@ietf.org, vfajardo@tari.toshiba.com, john.loughney@nokia.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Himanshu Bahl Date: Fri, 12 Jan 2007 20:44:58 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.5.5|November 30, 2005) at 12/01/2007 08:50:00 PM, Serialize complete at 12/01/2007 08:50:00 PM X-Spam-Score: 0.2 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: Subject: [Dime] Query - Processing of Unrecognized AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1249713182==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============1249713182== Content-Type: multipart/alternative; boundary="=_alternative 0054061865257261_=" This is a multipart message in MIME format. --=_alternative 0054061865257261_= Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: base64 SGkgQWxsLA0KSSBoYXZlIGEgcXVlcnkuDQpJZiB3ZSBzZW5kIGFuIEFWUCBpbnNpZGUgYSBkaWFt ZXRlciBjb21tYW5kL21lc3NhZ2Ugd2hpY2ggaXMgbm90IGEgcGFydCBvZiANCnRoYXQgY29tbWFu ZCBhcyBwZXIgZGlhbWV0ZXIgUkZDL3NwZWNpZmljYXRpb24gYnV0IHBhcnQgb2YgYW5vdGhlciBj b21tYW5kIA0KaW4gdGhhdCBhcHBsaWNhdGlvbi4gV2hhdCBzaG91bGQgYmUgdGhlIGJlaGF2aW9y IG9mIGRpYW1ldGVyIHN0YWNrL25vZGUuDQoNCkNhc2UgMSkgV2hlbiBNIGJpdCBpcyBzZXQgaW4g dGhhdCBBVlANCiAgICAgICAgV2Ugc3VwcG9zZWQgdG8gcmV0dXJuIHRoZSBlcnJvciBBVlAgdW5z dXBwb3J0ZWQgKEFWUF9OT1RfQUxMT1dFRCA9IA0KNTAwOCkgIHRvIHBlZXI/IA0KICAgICAgICBX ZSBzaG91bGQgcmV0dXJuIGFuIGVycm9yIEFWUCBub3QgYWxsb3dlZCAoQVZQX05PVF9BTExPV0VE ID0gNTAwOCkgDQp0byBwZWVyPw0KICAgICAgICBXZSBzaG91bGQgZGVsaXZlciB0aGUgbWVzc2Fn ZSB0byBhcHBsaWNhdGlvbiBhbG9uZyB3aXRoIHRoZSANCmRlY29kZWQgQVZQIGZvciB0aGF0IGFw cGxpY2F0aW9uLg0KDQpDYXNlIDIpIFdoZW4gTSBiaXQgaXMgbm90IHNldCBpbiB0aGF0IEFWUC4N CiAgICAgICAgV2Ugc2hvdWxkIGRpc2NhcmQgdGhlIEFWUCBhbmQgZGVsaXZlciB0aGUgbWVzc2Fn ZSB0byBhcHBsaWNhdGlvbiANCndpdGggcmVzdCBvZiBkZWNvZGVkIEFWUCdzLg0KICAgICAgICBX ZSBzaG91bGQgcmV0dXJuIGFuIGVycm9yIEFWUCBub3QgYWxsb3dlZCB0byBwZWVyIChBVlBfTk9U X0FMTE9XRUQgDQo9IDUwMDgpPw0KDQpPdXIgbWFpbiBjb25jZXJuIGluIHRoaXMgY2FzZSBpcyB0 byBjbGFyaWZ5IHdoZXRoZXIgdGhlIA0KcGFyc2luZy9lbmNvZGluZy9kZWNvZGluZyBvZiBhbiBB VlAgaW4gYSBkaWFtZXRlciBub2RlIGlzIGFzc29jaWF0ZWQgd2l0aCANCmEgY29tbWFuZCBvciBh IGFwcGxpY2F0aW9uLg0KDQpJbiB0aGlzIGNhc2UgYSBBVlBzIGFzc29jaWF0ZWQgd2l0aCBhIGNv bW1hbmQgbWVhbnMgYWxsIHRoZSBBVlBzIHRoYXQgYXJlIA0KZGVmaW5lZCBvcHRpb25hbCBhbmQg KnJlcXVpcmVkIEFWUHMgaW4gdGhlIGNvbW1hbmQgZGVzY3JpcHRpb24gYXMgcGVyIA0KUkZDL3Nw ZWNpZmljYXRpb24uDQpXZSBoYXZlIGFsc28gbm90IGluY2x1ZGVkIHRoaXMgQVZQIGFzIHBhcnQg b2YgQ3VzdG9tIEFWUCBkZWZpbml0aW9uIGZvciANCnRoYXQgY29tbWFuZC4NCg0KKiByZXF1aXJl ZCBBVlAgYXJlIHRoZSBvbmVzIGRlZmluZWQgaW5zaWRlIHt9IGJyYWNrZXRzIGluIHRoZSANCnNw ZWNpZmljYXRpb25zIGFuZCBvcHRpb25hbCBhcmUgdGhvc2Ugd2hpY2ggYXJlIGRlZmluZWQgaW5z aWRlIHt9IA0KYnJhY2tldHMuLg0KDQpXZSBjYW4gdGFrZSB0aGUgZXhhbXBsZSBvZiBzZW5kaW5n IFJlc3VsdC1Db2RlLUFWUCBpbiBhIFVEUiBSZXF1ZXN0IA0KY29tbWFuZCBmb3IgU2ggYXBwbGlj YXRpb24od2l0aCBNIGJpdCBzZXQgYW5kIHJlc2V0IG9wdGlvbikuDQoNCkhvcGluZyBmb3IgYSBx dWljayByZXNvbHV0aW9uIC4NCg0KU2luY2VyZWx5LA0KSGltYW5zaHUuDQoNCg0KDQoNCioqKioq KioqKioqKioqKioqKioqKioqICBBcmljZW50LVByaXZhdGUgICAqKioqKioqKioqKioqKioqKioq KioqKg0KIkRJU0NMQUlNRVI6IFRoaXMgbWVzc2FnZSBpcyBwcm9wcmlldGFyeSB0byBBcmljZW50 ICBhbmQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIAp0aGUgaW5kaXZpZHVhbCB0 byB3aG9tIGl0IGlzIGFkZHJlc3NlZC4gSXQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBvciBjb25m aWRlbnRpYWwgaW5mb3JtYXRpb24gYW5kIHNob3VsZCBub3QgYmUgCmNpcmN1bGF0ZWQgb3IgdXNl ZCBmb3IgYW55IHB1cnBvc2Ugb3RoZXIgdGhhbiBmb3Igd2hhdCBpdCBpcyBpbnRlbmRlZC4gSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCAKcGxlYXNlIG5vdGlmeSB0 aGUgb3JpZ2luYXRvciBpbW1lZGlhdGVseS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJl Y2lwaWVudCwgeW91IGFyZSBub3RpZmllZCB0aGF0IHlvdSBhcmUgc3RyaWN0bHkKcHJvaGliaXRl ZCBmcm9tIHVzaW5nLCBjb3B5aW5nLCBhbHRlcmluZywgb3IgZGlzY2xvc2luZyB0aGUgY29udGVu dHMgb2YgdGhpcyBtZXNzYWdlLiBBcmljZW50IGFjY2VwdHMgbm8gcmVzcG9uc2liaWxpdHkgZm9y IApsb3NzIG9yIGRhbWFnZSBhcmlzaW5nIGZyb20gdGhlIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24g dHJhbnNtaXR0ZWQgYnkgdGhpcyBlbWFpbCBpbmNsdWRpbmcgZGFtYWdlIGZyb20gdmlydXMuIgo= --=_alternative 0054061865257261_= Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEFsbCw8YnI+DQpJIGhhdmUg YSBxdWVyeS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPklmIHdl IHNlbmQgYW4gQVZQIGluc2lkZSBhIGRpYW1ldGVyDQpjb21tYW5kL21lc3NhZ2Ugd2hpY2ggaXMg bm90IGEgcGFydCBvZiB0aGF0IGNvbW1hbmQgYXMgcGVyIGRpYW1ldGVyIFJGQy9zcGVjaWZpY2F0 aW9uDQpidXQgcGFydCBvZiBhbm90aGVyIGNvbW1hbmQgaW4gdGhhdCBhcHBsaWNhdGlvbi4gV2hh dCBzaG91bGQgYmUgdGhlIGJlaGF2aW9yDQpvZiBkaWFtZXRlciBzdGFjay9ub2RlLjwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Q2FzZSAxKSBXaGVuIE0g Yml0IGlzIHNldCBpbiB0aGF0IEFWUDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFdlDQpzdXBwb3NlZCB0byByZXR1 cm4gdGhlIGVycm9yIEFWUCB1bnN1cHBvcnRlZCAoQVZQX05PVF9BTExPV0VEID0gNTAwOCkgJm5i c3A7dG8NCnBlZXI/IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFdlDQpzaG91bGQgcmV0dXJuIGFuIGVycm9yIEFW UCBub3QgYWxsb3dlZCAoQVZQX05PVF9BTExPV0VEID0gNTAwOCkgdG8gcGVlcj88L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBXZQ0Kc2hvdWxkIGRlbGl2ZXIgdGhlIG1lc3NhZ2UgdG8gYXBwbGljYXRpb24gYWxvbmcg d2l0aCB0aGUgZGVjb2RlZCBBVlAgZm9yDQp0aGF0IGFwcGxpY2F0aW9uLjwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Q2FzZSAyKSBXaGVuIE0gYml0IGlz IG5vdCBzZXQgaW4gdGhhdA0KQVZQLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFdlDQpzaG91bGQgZGlzY2FyZCB0 aGUgQVZQIGFuZCBkZWxpdmVyIHRoZSBtZXNzYWdlIHRvIGFwcGxpY2F0aW9uIHdpdGggcmVzdA0K b2YgZGVjb2RlZCBBVlAncy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBXZQ0Kc2hvdWxkIHJldHVybiBhbiBlcnJv ciBBVlAgbm90IGFsbG93ZWQgdG8gcGVlciAoQVZQX05PVF9BTExPV0VEID0gNTAwOCk/PC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5PdXIgbWFpbiBjb25j ZXJuIGluIHRoaXMgY2FzZSBpcyB0bw0KY2xhcmlmeSB3aGV0aGVyIHRoZSBwYXJzaW5nL2VuY29k aW5nL2RlY29kaW5nIG9mIGFuIEFWUCBpbiBhIGRpYW1ldGVyIG5vZGUNCmlzIGFzc29jaWF0ZWQg d2l0aCBhIGNvbW1hbmQgb3IgYSBhcHBsaWNhdGlvbi48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkluIHRoaXMgY2FzZSBhIEFWUHMgYXNzb2NpYXRlZCB3 aXRoDQphIGNvbW1hbmQgbWVhbnMgYWxsIHRoZSBBVlBzIHRoYXQgYXJlIGRlZmluZWQgb3B0aW9u YWwgYW5kICpyZXF1aXJlZCBBVlBzDQppbiB0aGUgY29tbWFuZCBkZXNjcmlwdGlvbiBhcyBwZXIg UkZDL3NwZWNpZmljYXRpb24uPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5XZSBoYXZlIGFsc28gbm90IGluY2x1ZGVkIHRoaXMgQVZQIGFzDQpwYXJ0IG9mIEN1c3Rv bSBBVlAgZGVmaW5pdGlvbiBmb3IgdGhhdCBjb21tYW5kLjwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+KiByZXF1aXJlZCBBVlAgYXJlIHRoZSBvbmVzIGRl ZmluZWQNCmluc2lkZSB7fSBicmFja2V0cyBpbiB0aGUgc3BlY2lmaWNhdGlvbnMgYW5kIG9wdGlv bmFsIGFyZSB0aG9zZSB3aGljaCBhcmUNCmRlZmluZWQgaW5zaWRlIHt9IGJyYWNrZXRzLi48L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPldlIGNhbiB0YWtl IHRoZSBleGFtcGxlIG9mIHNlbmRpbmcgUmVzdWx0LUNvZGUtQVZQDQppbiBhIFVEUiBSZXF1ZXN0 IGNvbW1hbmQgZm9yIFNoIGFwcGxpY2F0aW9uKHdpdGggTSBiaXQgc2V0IGFuZCByZXNldCBvcHRp b24pLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SG9w aW5nIGZvciBhIHF1aWNrIHJlc29sdXRpb24gLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+U2luY2VyZWx5LDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+SGltYW5zaHUuPC9mb250Pg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8 dHI+DQo8dGQgd2lkdGg9MTAwJT4NCjx0cj4NCjx0ZD48L3RhYmxlPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKiAm bmJzcDtBcmljZW50LVByaXZhdGUgJm5ic3A7ICoqKioqKioqKioqKioqKioqKioqKioqPC9mb250 Pg0KPHRhYmxlPjx0cj48dGQgYmdjb2xvcj0jZmZmZmZmPjxmb250IGNvbG9yPSMwMDAwMDA+PHBy ZT4iRElTQ0xBSU1FUjogVGhpcyBtZXNzYWdlIGlzIHByb3ByaWV0YXJ5IHRvIEFyaWNlbnQgIGFu ZCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgCnRoZSBpbmRpdmlkdWFsIHRvIHdo b20gaXQgaXMgYWRkcmVzc2VkLiBJdCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIG9yIGNvbmZpZGVu dGlhbCBpbmZvcm1hdGlvbiBhbmQgc2hvdWxkIG5vdCBiZSAKY2lyY3VsYXRlZCBvciB1c2VkIGZv ciBhbnkgcHVycG9zZSBvdGhlciB0aGFuIGZvciB3aGF0IGl0IGlzIGludGVuZGVkLiBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIApwbGVhc2Ugbm90aWZ5IHRoZSBv cmlnaW5hdG9yIGltbWVkaWF0ZWx5LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50LCB5b3UgYXJlIG5vdGlmaWVkIHRoYXQgeW91IGFyZSBzdHJpY3RseQpwcm9oaWJpdGVkIGZy b20gdXNpbmcsIGNvcHlpbmcsIGFsdGVyaW5nLCBvciBkaXNjbG9zaW5nIHRoZSBjb250ZW50cyBv ZiB0aGlzIG1lc3NhZ2UuIEFyaWNlbnQgYWNjZXB0cyBubyByZXNwb25zaWJpbGl0eSBmb3IgCmxv c3Mgb3IgZGFtYWdlIGFyaXNpbmcgZnJvbSB0aGUgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiB0cmFu c21pdHRlZCBieSB0aGlzIGVtYWlsIGluY2x1ZGluZyBkYW1hZ2UgZnJvbSB2aXJ1cy4iCjwvcHJl PjwvZm9udD48L3RkPjwvdHI+PC90YWJsZT4= --=_alternative 0054061865257261_=-- --===============1249713182== 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 --===============1249713182==-- From dime-bounces@ietf.org Fri Jan 12 13:33:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5RDq-0006LR-2K; Fri, 12 Jan 2007 13:33:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5RDo-0006Kn-OT for dime@ietf.org; Fri, 12 Jan 2007 13:33:48 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5RDm-0005z6-9m for dime@ietf.org; Fri, 12 Jan 2007 13:33:48 -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 <0JBR0059TQ852O@usaga01-in.huawei.com> for dime@ietf.org; Fri, 12 Jan 2007 10:33:41 -0800 (PST) Received: from huawei.com ([172.18.4.47]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JBR00L7YQ83HE@usaga01-in.huawei.com> for dime@ietf.org; Fri, 12 Jan 2007 10:33:41 -0800 (PST) Received: from N737011 (pool-71-112-126-182.sttlwa.dsl-w.verizon.net [71.112.126.182]) by usaml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JBR00LDMQPUHM@usaml03-in.huawei.com> for dime@ietf.org; Fri, 12 Jan 2007 10:44:23 -0800 (PST) Date: Fri, 12 Jan 2007 10:33:39 -0800 From: Madjid Nakhjiri Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Security In-reply-to: <5e2406980701080259we892279k8aaba84daec22a0@mail.gmail.com> To: 'Julien Bournelle' , 'Hannes Tschofenig' Message-id: <002701c73678$2eee19c0$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: AcczFmdgWmaa7jvmSoSucG39q6o4cgDYCXNQ 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 Julien, While I appreciate the threat analysis here, the problem is pretty easy to solve. Unless, we want to leave this vulnerability as something only for the security consideration, I suggest we add the security measure. I am working on a draft that shows how you can separate authentication and authorization while binding the two together. The draft will be submitted soon (or at least before next IETF deadline). There is one problem remaining and that is I am wondering about the messaging triggers (see below). If people like the solution we can use it for the WG draft. It is just hard to show a solution over ML, sorry. For now, I say, we can use the EAP method to generate MSK/EMSK and then use those keys in assurance for previous authentication (Diameter EAP) to the authorization server for Diameter MIP. The issue is that based on the threat analysis that you provided, we cannot trust HA to provide this assurance. It has to come from the peer and/or AAA server. One way would be for the peer to generate the key sign its request with this key. Without getting into the details right now, the issue would be: What message would carry this signature from the peer? And this is why I have been asking the question of what message would trigger the Mobile IP Authorization (MAR) message and what is the timing of MAR/MAA w.r.t IKEv2. The problem is that we need to perform all Mobile IP bootstrapping after MAA, i.e. after the MN is actually authorized for Mobile IP, so if there is any message (even an IKEv2 message) that carries a Mobile IP parameter, it has to come after MAA. Hope I am making sense, Madjid -----Original Message----- From: Julien Bournelle [mailto:julien.bournelle@gmail.com] Sent: Monday, January 08, 2007 2:59 AM To: Hannes Tschofenig Cc: dime@ietf.org Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Security hi hannes, all ok, so let's try to investigate this. In our current document, we have the following architecture: MN <--- IKEv2 -----> HA <------> AAA_EAP ^ | +------------> AAA_MIP6 HA authenticates the MN by using 4072 in AUTHENTICATE_ONLY mode (if EAP used within IKEv2) and we have defined 2 new messages for Authorization purposes at AAA_MIP6. HA uses identiy provided by MN in IDii field of the 3rd IKEv2 message to route messages to the corresponding realm.Thus, in the picture above, we consider that AAA_EAP and AAA_MIP6 are in the same realm. Howver, as we have a different App-Id, AAA_EAP and AAA_MIP6 may be located in different servers. Note that this is not a requirement, that's possible. Advantages are modularity and flexibility. This approach may also be used by other applications that use EAP for authentication. However, we do not require use of EAP. The problem that we have with this approach is to investigate if it creates a security hole to separate Authentication and Authorization. As it has been mentionned in the ML, the HA may be compromised. So, the first thing I think we should do is to catch and to agree on the goals of such an attack. I can see: a/ DoS on the Mobile IPv6 service (shutdown) with loss of revenues for an operator b/ Steal the service 1. The attacker compromises the HA to obtain free mip6 service for himself 2. The attacker compromises the HA for a group of people to obtain free mip6 service 3. The attacker compromises the HA for all to obtain free mip6 service. c/ Identity spoofing to charge someone else others ? Julien On 1/1/07, Hannes Tschofenig wrote: > Hi all, > > it seems that we came across a security issue that requires more > thoughts. Interestingly, David Nelson gave a presentation at the IETF#66 > meeting that dealt with a similar problem when RADIUS is used in the > ISMS context. You can find his presentation here: > http://www3.ietf.org/proceedings/06jul/slides/radext-7/sld1.htm > > We need to investigate the potential security threats in more detail > before we immediately jump to the solution space. > Who has time and would be interested to brainstorm about this subject a > little bit? > The goal is to have a more detailed description of the security threats. > > Ciao > Hannes > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jan 12 15:23:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5SwB-0005C3-J9; Fri, 12 Jan 2007 15:23:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Sw9-00050o-GY for dime@ietf.org; Fri, 12 Jan 2007 15:23:41 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Sw7-0008Fy-95 for dime@ietf.org; Fri, 12 Jan 2007 15:23:41 -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 5D4B5FA772 for ; Fri, 12 Jan 2007 15:23:32 -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 l0CKNVnF022428 for ; Fri, 12 Jan 2007 15:23:31 -0500 (EST) From: "Tolga Asveren" To: Date: Fri, 12 Jan 2007 15:19:52 -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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Dime] dime-cong-01 available X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, Based on the comments we received for the 00 version, Victor and I updated the Diameter congestion signaling draft: http://www.ietf.org/internet-drafts/draft-asveren-dime-cong-01.txt Comments are appreciated. Thanks, Tolga _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jan 15 04:09:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Nql-0000wq-1Z; Mon, 15 Jan 2007 04:09:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Nqj-0000wl-Iz for dime@ietf.org; Mon, 15 Jan 2007 04:09:54 -0500 Received: from [2001:5c0:8fff:ffff::195] (helo=laganier.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H6Nq5-0001dG-Jg for dime@ietf.org; Mon, 15 Jan 2007 04:09:53 -0500 From: Julien Laganier X-KMail-Identity: 598191740 To: "Julien Bournelle" Subject: Re: R: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Security User-Agent: KMail/1.8.2 References: <5e2406980701080259we892279k8aaba84daec22a0@mail.gmail.com> <5e2406980701100428l253eef09rb3da31a882800793@mail.gmail.com> In-Reply-To: <5e2406980701100428l253eef09rb3da31a882800793@mail.gmail.com> X-KMail-Link-Message: 1177773 X-KMail-Link-Type: reply MIME-Version: 1.0 Content-Disposition: inline Status: RO X-Status: RFSC X-KMail-EncryptionState: N X-KMail-SignatureState: N Date: Mon, 15 Jan 2007 09:56:19 +0100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200701150956.20284.julien.IETF@laposte.net> X-KMail-MDN-Sent: X-Spam-Score: -2.8 (--) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 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, Some thoughts below, On 1/10/07, Julien Bournelle wrote: > Hi michele, > > On 1/8/07, La Monaca Michele wrote: > > Hi Julien, > > > > as you said the separation between auth and autz > > takes along modularity and flexibility but it > > raises security concerns if the HA is > > compromised. Therefore, I think that it would be > > better to compare what a compromised HA > > can/cannot do in the two cases: > > > > "Split" AAA approach > > > > 1) Deny service to regular users (i.e. DoS) YES > > 2) Grant service to fake users (i.e. steal the > > service) YES 3) DoS to the AAA infrastructure > > YES > > 4) Identity spoofing to charge someone else YES > > The fact is that by separating authentitcation > and authorization, if HA is compromised, a > non-authenticated user can be authorized. I understand what you mean but I think it would be more be more precise to say: When separate authentication and authorization are used and the HA is compromised (by Mallory), it is possible that the HA submit the identity of another user (Alice) to the authorization server, have this other user (Alice) be authorized by the authorization server, although the user that will be provided with the service is different (e.g. Mallory, or whoever else.) That is, the HA cannot render a unauthenticated user *authorized*, but rather provide it with the service in spite of the user being unauthorized. This sounds somehow like the contrary of what you said :) Let me try to reword your sentence into: The fact is that by separating authentication and authorization, if HA is compromised, a non-authenticated user can be unauthorized and use the service. Then this would contradict your statement below... > This threat does not exist if authentication and > authorization are binded. ..because even if authentication and authorization are bound together, still a compromise HA could provide the service to *anyone* in spite of a particular instance of this anyone not being authenticated or/neither authorized. > The question is what are the consequence of this. I therefore think there's no consequences. > If Alice compromised the HA and asks an > authorization for Bob. The problem that has been > evoked is that Bob could be charged for the Mobile > IPv6 service. The problem with charging/accounting is different, and is caused by authentication being decoupled from accounting. That was evocated last year by Yoshi in one of his message: > But wouldn't this problem also exist if > authentication and authorization are tied > and if the HA is compromised ? That's exactly my point. I think a problem with accounting would primarily be caused by decoupling of accounting and authentication, and would be orthogonal to a decoupling of authentication and authorization. --julien > > Julien his sounds somehow like the contrary of what you said :) Let me try to reword your sentence into: The fact is that by separating authentication and authorization, if HA is compromised, a non-authenticated user can be unauthorized and use the service. Then this would contradict your statement below... > This threat does not exist if authentication and > authorization are binded. ..because even if authentication and authorization are bound together, still a compromise HA could provide the service to *anyone* in spite of a particular instance of this anyone not being authenticated or/neither authorized. > The question is what are the consequence of this. I therefore think there's no consequences. > If Alice compromised the HA and asks an > authorization for Bob. The problem that has been > evoked is that Bob could be charged for the Mobile > IPv6 service. The problem with charging/accounting is different, and is caused by authentication being decoupled from accounting. That was evocated last year by Yoshi in one of his message: > But wouldn't this problem also exist if > authentication and authorization are tied > and if the HA is compromised ? That's exactly my point. I think a problem with accounting would primarily be caused by decoupling of accounting and authentication, and would be orthogonal to a decoupling of authentication and authorization. --julien > > Julien _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jan 15 05:13:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6OqZ-0002A6-MV; Mon, 15 Jan 2007 05:13:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6OqY-00029v-OA for dime@ietf.org; Mon, 15 Jan 2007 05:13:46 -0500 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6OqV-00048x-La for dime@ietf.org; Mon, 15 Jan 2007 05:13:46 -0500 Received: by ug-out-1314.google.com with SMTP id 72so1175836ugd for ; Mon, 15 Jan 2007 02:13:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:user-agent:cc:references:in-reply-to:mime-version:content-disposition:date:content-type:content-transfer-encoding:message-id:sender; b=nw8sbeFytIgKY3UQekrhRbgk+bL36OCpeNnt867kJyFAmsYQ10GE7fU9vxzmCzxGE2J6MeDaqqitFhIarIdXTELyJ7IRZ0LbQPo0VWy7R1aHcinEfMV0ctImydlwUKvcRNGhr120AZU0pIFkmHLE/li8ahXwjo/nqtfXV+OBjxc= Received: by 10.67.117.2 with SMTP id u2mr5144277ugm.1168856022604; Mon, 15 Jan 2007 02:13:42 -0800 (PST) Received: from ?192.168.1.110? ( [212.119.9.178]) by mx.google.com with ESMTP id p32sm5331276ugc.2007.01.15.02.13.41; Mon, 15 Jan 2007 02:13:41 -0800 (PST) From: Julien Laganier To: dime@ietf.org, Madjid Nakhjiri Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Security User-Agent: KMail/1.8.2 References: <002701c73678$2eee19c0$2f01a8c0@china.huawei.com> In-Reply-To: <002701c73678$2eee19c0$2f01a8c0@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline Date: Mon, 15 Jan 2007 11:12:41 +0100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200701151112.41918.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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 On Friday 12 January 2007 19:33, Madjid Nakhjiri wrote: > Hi Julien, Hi Madjid, > While I appreciate the threat analysis here, the > problem is pretty easy to solve. Unless, we want to > leave this vulnerability as something only for the > security consideration, I suggest we add the > security measure. Solving the problem implies that we understand it. I am still not convinced that separation of authentication and authorization does indeed introduce a new vulnerability -- see my other note on the subject: http://www1.ietf.org/mail-archive/web/dime/current/msg01178.html Until we determine what are the threats and attacks, and determine whether each of them does represent a sufficiently important risk which deserve a countermeasure, I really think it is premature to devise solutions. Best, --julien > I am working on a draft that shows how you can > separate authentication and authorization while > binding the two together. The draft will be > submitted soon (or at least before next IETF > deadline). There is one problem remaining and that > is I am wondering about the messaging triggers (see > below). If people like the solution we can use it > for the WG draft. It is just hard to show a solution > over ML, sorry. > > For now, I say, we can use the EAP method to > generate MSK/EMSK and then use those keys in > assurance for previous authentication (Diameter EAP) > to the authorization server for Diameter MIP. > The issue is that based on the threat analysis that > you provided, we cannot trust HA to provide this > assurance. It has to come from the peer and/or AAA > server. > One way would be for the peer to generate the key > sign its request with this key. Without getting into > the details right now, the issue would be: What > message would carry this signature from the peer? > And this is why I have been asking the question of > what message would trigger the Mobile IP > Authorization (MAR) message and what is the timing > of MAR/MAA w.r.t IKEv2. > > The problem is that we need to perform all Mobile IP > bootstrapping after MAA, i.e. after the MN is > actually authorized for Mobile IP, so if there is > any message (even an IKEv2 message) that carries a > Mobile IP parameter, it has to come after MAA. > > Hope I am making sense, > > Madjid _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jan 16 00:43:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6h6Z-0006SD-1c; Tue, 16 Jan 2007 00:43:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6h6X-0006S0-S7 for dime@ietf.org; Tue, 16 Jan 2007 00:43:29 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6h4c-0005bd-EE for dime@ietf.org; Tue, 16 Jan 2007 00:43:29 -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 <0JBY00HGQ4RW5U@szxga02-in.huawei.com> for dime@ietf.org; Tue, 16 Jan 2007 13:33:33 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JBY00L594RVJ6@szxga02-in.huawei.com> for dime@ietf.org; Tue, 16 Jan 2007 13:33:32 +0800 (CST) Received: from huawei1515 ([10.18.4.60]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JBY00KPR4RRZ5@szxml03-in.huawei.com> for dime@ietf.org; Tue, 16 Jan 2007 13:33:31 +0800 (CST) Date: Tue, 16 Jan 2007 11:03:26 +0530 From: Rajith R Subject: RE: [Dime] Query - Processing of Unrecognized AVP In-reply-to: To: 'Himanshu Bahl' , dime@ietf.org Message-id: <001e01c7392f$d90702f0$3c04120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acc2XLhI2r+2hstlS8KWyCi7y/Wt8gC0qkRA X-Spam-Score: 0.3 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rajithr@huawei.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1334573241==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1334573241== Content-type: multipart/alternative; boundary="Boundary_(ID_QzemIHk2QgYP/0cr/i5hTQ)" This is a multi-part message in MIME format. --Boundary_(ID_QzemIHk2QgYP/0cr/i5hTQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT For the example you have cited (Result-Code AVP in UDR): Case 1:DIAMETER_AVP_NOT_ALLOWED 5008 unless the ABNF of UDR has *[AVP] Case 2: DIAMETER_INVALID_AVP_BITS 3009 Result-Code AVP MUST have M bit set by definition [see RFC 3588, section 4.5]. _____ From: Himanshu Bahl [mailto:himanshu.bahl@aricent.com] Sent: Friday, January 12, 2007 8:45 PM To: dime@ietf.org; vfajardo@tari.toshiba.com; john.loughney@nokia.com Subject: [Dime] Query - Processing of Unrecognized AVP Hi All, I have a query. If we send an AVP inside a diameter command/message which is not a part of that command as per diameter RFC/specification but part of another command in that application. What should be the behavior of diameter stack/node. Case 1) When M bit is set in that AVP We supposed to return the error AVP unsupported (AVP_NOT_ALLOWED = 5008) to peer? We should return an error AVP not allowed (AVP_NOT_ALLOWED = 5008) to peer? We should deliver the message to application along with the decoded AVP for that application. Case 2) When M bit is not set in that AVP. We should discard the AVP and deliver the message to application with rest of decoded AVP's. We should return an error AVP not allowed to peer (AVP_NOT_ALLOWED = 5008)? Our main concern in this case is to clarify whether the parsing/encoding/decoding of an AVP in a diameter node is associated with a command or a application. In this case a AVPs associated with a command means all the AVPs that are defined optional and *required AVPs in the command description as per RFC/specification. We have also not included this AVP as part of Custom AVP definition for that command. * required AVP are the ones defined inside {} brackets in the specifications and optional are those which are defined inside {} brackets.. We can take the example of sending Result-Code-AVP in a UDR Request command for Sh application(with M bit set and reset option). Hoping for a quick resolution . Sincerely, Himanshu. *********************** Aricent-Private *********************** "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." --Boundary_(ID_QzemIHk2QgYP/0cr/i5hTQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
For the example you have cited (Result-Code AVP in UDR):
Case 1:DIAMETER_AVP_NOT_ALLOWED           5008
unless the ABNF of UDR has *[AVP]
 
Case 2: DIAMETER_INVALID_AVP_BITS          3009
Result-Code AVP MUST have M bit set by definition [see RFC 3588, section 4.5].


From: Himanshu Bahl [mailto:himanshu.bahl@aricent.com]
Sent: Friday, January 12, 2007 8:45 PM
To: dime@ietf.org; vfajardo@tari.toshiba.com; john.loughney@nokia.com
Subject: [Dime] Query - Processing of Unrecognized AVP


Hi All,
I have a query.
If we send an AVP inside a diameter command/message which is not a part of that command as per diameter RFC/specification but part of another command in that application. What should be the behavior of diameter stack/node.

Case 1) When M bit is set in that AVP
        We supposed to return the error AVP unsupported (AVP_NOT_ALLOWED = 5008)  to peer?
        We should return an error AVP not allowed (AVP_NOT_ALLOWED = 5008) to peer?
        We should deliver the message to application along with the decoded AVP for that application.

Case 2) When M bit is not set in that AVP.
        We should discard the AVP and deliver the message to application with rest of decoded AVP's.
        We should return an error AVP not allowed to peer (AVP_NOT_ALLOWED = 5008)?

Our main concern in this case is to clarify whether the parsing/encoding/decoding of an AVP in a diameter node is associated with a command or a application.

In this case a AVPs associated with a command means all the AVPs that are defined optional and *required AVPs in the command description as per RFC/specification.
We have also not included this AVP as part of Custom AVP definition for that command.

* required AVP are the ones defined inside {} brackets in the specifications and optional are those which are defined inside {} brackets..

We can take the example of sending Result-Code-AVP in a UDR Request command for Sh application(with M bit set and reset option).

Hoping for a quick resolution .

Sincerely,
Himanshu.



***********************  Aricent-Private   *********************** 
"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."
--Boundary_(ID_QzemIHk2QgYP/0cr/i5hTQ)-- --===============1334573241== 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 --===============1334573241==-- From dime-bounces@ietf.org Tue Jan 16 01:06:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6hT5-0004pK-Ca; Tue, 16 Jan 2007 01:06:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6hT3-0004pE-KK for dime@ietf.org; Tue, 16 Jan 2007 01:06:45 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6hSk-0008L9-FD for dime@ietf.org; Tue, 16 Jan 2007 01:06:45 -0500 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JBY009F461OW7@szxga04-in.huawei.com> for dime@ietf.org; Tue, 16 Jan 2007 14:01:00 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JBY001HQ61N6S@szxga04-in.huawei.com> for dime@ietf.org; Tue, 16 Jan 2007 14:01:00 +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 <0JBY00CA961JDN@szxml04-in.huawei.com> for dime@ietf.org; Tue, 16 Jan 2007 14:00:59 +0800 (CST) Date: Tue, 16 Jan 2007 11:30:55 +0530 From: Rajith R Subject: RE: [Dime] Result code of Multiple failed Avps In-reply-to: <4C0FAAC489C8B74F96BEAD85EAEB262503392DDA@xmb-sjc-215.amer.cisco.com> To: "'Glen Zorn (gwz)'" , 'Nimish Bhargava' Message-id: <002901c73933$afdc1560$3c04120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acc0b3wY0t1e7Wv9QT2teqh49/UDtAAa5BdwARWHeYA= X-Spam-Score: 0.1 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 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: , Content-Type: multipart/mixed; boundary="===============1176394607==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1176394607== Content-type: multipart/alternative; boundary="Boundary_(ID_OI01y3WlkU0taexVsDrNHA)" This is a multi-part message in MIME format. --Boundary_(ID_OI01y3WlkU0taexVsDrNHA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT If the assumption is that message processing would halt on first failure, I can't see why a Diameter message might have more than one Failed-AVP AVP. The RFC 3588 mandates that there MUST be only one Result-Code AVP in an answer message & implies ("The value of the Result-Code AVP will provide information on the reason for the Failed-AVP AVP.") a relation b/w the Result-Code AVP & the Failed-AVP AVP, all the more reason on why there MAY be only one Failed-AVP AVP. However, all erroneous AVPs associated with the error (for eg: the "contradicting" AVPs in the case of DIAMETER_CONTRADICTING_AVPS) may be filled in one Failed-AVP AVP only (the ABNF allows this provision) _____ From: Glen Zorn (gwz) [mailto:gwz@cisco.com] Sent: Wednesday, January 10, 2007 10:52 PM To: Nimish Bhargava; rajithr@huawei.com Cc: dime@ietf.org Subject: RE: [Dime] Result code of Multiple failed Avps well it is not compulsory, diameter messages may contain multiple Failed-AVP avps. Right. As per section 5.3.2 , 5.4.2 , 5.5.2 of the DIAMETER Base RFC 3588 and various applications specifications specify support for multiple Failed-AVP avps. On 1/9/07, Rajith R wrote: A Diameter message may contain one (and only one) Failed-AVP AVP. Not true. _____ From: Nimish Bhargava [mailto:nimish.bhargava@gmail.com] Sent: Tuesday, January 09, 2007 5:19 PM To: dime@ietf.org Subject: [Dime] Result code of Multiple failed Avps Hi everyone While sending a response containing multiple failed AVPs, what should be the value of result code AVP? since different AVPs may fail due to different reasons, should the error code of the first failed AVP be sent as result code? I think that the assumption was that received message processing would halt on the first invalid AVP & an error returned. It might be a good idea to change the Failed-AVP to include an error code... Thanks Nimish -- Real programmers don't work from 9 to 5. If any real programmers are around at 9am it's because they were up all night. --Boundary_(ID_OI01y3WlkU0taexVsDrNHA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
If the assumption is that message processing would halt on first failure, I can't see why a Diameter message might have more than one Failed-AVP AVP. The RFC 3588 mandates that there MUST be only one Result-Code AVP in an answer message & implies ("The value of the Result-Code AVP will provide information on the reason for the Failed-AVP AVP.") a relation b/w the Result-Code AVP & the Failed-AVP AVP, all the more reason on why there MAY be only one Failed-AVP AVP.
 
However, all erroneous AVPs associated with the error (for eg: the "contradicting" AVPs in the case of DIAMETER_CONTRADICTING_AVPS) may be filled in one Failed-AVP AVP only (the ABNF allows this provision)

From: Glen Zorn (gwz) [mailto:gwz@cisco.com]
Sent: Wednesday, January 10, 2007 10:52 PM
To: Nimish Bhargava; rajithr@huawei.com
Cc: dime@ietf.org
Subject: RE: [Dime] Result code of Multiple failed Avps

 
well it is not compulsory, diameter messages may contain multiple Failed-AVP avps.
 Right. 
As per section 5.3.2 , 5.4.2 , 5.5.2 of the DIAMETER Base RFC 3588 and various applications specifications specify support for multiple Failed-AVP avps.


On 1/9/07, Rajith R <rajithr@huawei.com> wrote:
A Diameter message may contain one (and only one) Failed-AVP AVP.
Not true.

From: Nimish Bhargava [mailto:nimish.bhargava@gmail.com]
Sent: Tuesday, January 09, 2007 5:19 PM
To: dime@ietf.org
Subject: [Dime] Result code of Multiple failed Avps

Hi everyone

While sending a response containing multiple failed AVPs, what should be the value of result code AVP?
since different AVPs may fail due to different reasons, should the error code of the first failed AVP be sent as result code? 
I think that the assumption was that received message processing would halt on the first invalid AVP &  an error returned.  It might be a good idea to change the Failed-AVP to include an error code... 

Thanks
Nimish




--
Real programmers don't work from 9 to 5. If any real programmers are around at 9am it's because they were up all night.
--Boundary_(ID_OI01y3WlkU0taexVsDrNHA)-- --===============1176394607== 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 --===============1176394607==-- From dime-bounces@ietf.org Tue Jan 16 02:21:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6id8-0007h2-6S; Tue, 16 Jan 2007 02:21:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6id7-0007gt-5i for dime@ietf.org; Tue, 16 Jan 2007 02:21:13 -0500 Received: from jaguar.hughesbpo.net ([61.246.186.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6id5-0000uv-Oc for dime@ietf.org; Tue, 16 Jan 2007 02:21:13 -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 l0G7M8lQ002794 for ; Tue, 16 Jan 2007 12:52:09 +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 l0G7M78X002711; Tue, 16 Jan 2007 12:52:08 +0530 In-Reply-To: <002901c73933$afdc1560$3c04120a@china.huawei.com> To: rajithr@huawei.com Subject: RE: [Dime] Result code of Multiple failed Avps MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: Nimish Bhargava Date: Tue, 16 Jan 2007 12:56:24 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.5.5|November 30, 2005) at 16/01/2007 12:54:50 PM, Serialize complete at 16/01/2007 12:54:50 PM X-Spam-Score: 0.2 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: dime@ietf.org, "'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: , Content-Type: multipart/mixed; boundary="===============1551781491==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============1551781491== Content-Type: multipart/alternative; boundary="=_alternative 002889AE65257265_=" This is a multipart message in MIME format. --=_alternative 002889AE65257265_= Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: base64 SWYgd2UgcmVzdHJpY3QgdGhlIGZhaWxlZCBBVlBzIGp1c3Qgb24gdGhlIGJhc2lzIG9mIFJlc3Vs dC1Db2RlIEFWUCB3ZSBtYXkgDQpub3QgYmUgYWJsZSB0byBwcm92aWRlIGFsbCB0aGUgaW5mb3Jt YXRpb24gcmVnYXJkaW5nIHRoZSBmYWlsZWQgQVZQcyB0byANCnRoZSBhcHBsaWNhdGlvbi4NClNp bmNlIHRoZSB3aG9sZSBtZXNzYWdlIHN0aWxsIG5lZWRzIHRvIGJlIHBhcnNlZCBpbiBvcmRlciB0 byBmaW5kIG91dCB0aGUgDQpBVlBzIGZhaWxpbmcgZHVlIHRvIGEgcGFydGljdWxhciBSZXN1bHQg Q29kZSwgaXQgd291bGQgYmUgYmV0dGVyIHRvIA0KaW5jbHVkZSBhIFJlc3VsdC1Db2RlIEFWUCBp biB0aGUgRmFpbGVkLUFWUCBBQk5GLg0KDQpUaGF0IHdheSBvbmUgY2FuIGltcGxlbWVudCBib3Ro IHRoZSBzY2VuYXJpb3MgaS5lLiBzZW5kIEFWUHMgZmFpbGluZyBkdWUgDQp0byBhIHBhcnRpY3Vs YXIgUmVzdWx0IENvZGUgYW5kIHNlbmRpbmcgRmFpbGVkLUFWUHMgY2l0aW5nIG11bHRpcGxlIFJl c3VsdCANCkNvZGVzLg0KDQpSZWdhcmRzLA0KTmltaXNoDQoNCg0KDQoNClJhaml0aCBSIDxyYWpp dGhyQGh1YXdlaS5jb20+IA0KMDEvMTYvMjAwNyAxMTozMCBBTQ0KDQpQbGVhc2UgcmVzcG9uZCB0 bw0KcmFqaXRockBodWF3ZWkuY29tDQoNCg0KVG8NCiInR2xlbiBab3JuIChnd3opJyIgPGd3ekBj aXNjby5jb20+LCAiJ05pbWlzaCBCaGFyZ2F2YSciIA0KPG5pbWlzaC5iaGFyZ2F2YUBnbWFpbC5j b20+DQpjYw0KZGltZUBpZXRmLm9yZw0KU3ViamVjdA0KUkU6IFtEaW1lXSBSZXN1bHQgY29kZSBv ZiBNdWx0aXBsZSBmYWlsZWQgQXZwcw0KDQoNCg0KDQoNCg0KSWYgdGhlIGFzc3VtcHRpb24gaXMg dGhhdCBtZXNzYWdlIHByb2Nlc3Npbmcgd291bGQgaGFsdCBvbiBmaXJzdCBmYWlsdXJlLCANCkkg Y2FuJ3Qgc2VlIHdoeSBhIERpYW1ldGVyIG1lc3NhZ2UgbWlnaHQgaGF2ZSBtb3JlIHRoYW4gb25l IEZhaWxlZC1BVlAgDQpBVlAuIFRoZSBSRkMgMzU4OCBtYW5kYXRlcyB0aGF0IHRoZXJlIE1VU1Qg YmUgb25seSBvbmUgUmVzdWx0LUNvZGUgQVZQIGluIA0KYW4gYW5zd2VyIG1lc3NhZ2UgJiBpbXBs aWVzICgiVGhlIHZhbHVlIG9mIHRoZSBSZXN1bHQtQ29kZSBBVlAgd2lsbCANCnByb3ZpZGUgaW5m b3JtYXRpb24gb24gdGhlIHJlYXNvbiBmb3IgdGhlIEZhaWxlZC1BVlAgQVZQLiIpIGEgcmVsYXRp b24gYi93IA0KdGhlIFJlc3VsdC1Db2RlIEFWUCAmIHRoZSBGYWlsZWQtQVZQIEFWUCwgYWxsIHRo ZSBtb3JlIHJlYXNvbiBvbiB3aHkgdGhlcmUgDQpNQVkgYmUgb25seSBvbmUgRmFpbGVkLUFWUCBB VlAuDQogDQpIb3dldmVyLCBhbGwgZXJyb25lb3VzIEFWUHMgYXNzb2NpYXRlZCB3aXRoIHRoZSBl cnJvciAoZm9yIGVnOiB0aGUgDQoiY29udHJhZGljdGluZyIgQVZQcyBpbiB0aGUgY2FzZSBvZiBE SUFNRVRFUl9DT05UUkFESUNUSU5HX0FWUFMpIG1heSBiZSANCmZpbGxlZCBpbiBvbmUgRmFpbGVk LUFWUCBBVlAgb25seSAodGhlIEFCTkYgYWxsb3dzIHRoaXMgcHJvdmlzaW9uKQ0KDQpGcm9tOiBH bGVuIFpvcm4gKGd3eikgW21haWx0bzpnd3pAY2lzY28uY29tXSANClNlbnQ6IFdlZG5lc2RheSwg SmFudWFyeSAxMCwgMjAwNyAxMDo1MiBQTQ0KVG86IE5pbWlzaCBCaGFyZ2F2YTsgcmFqaXRockBo dWF3ZWkuY29tDQpDYzogZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtEaW1lXSBSZXN1bHQg Y29kZSBvZiBNdWx0aXBsZSBmYWlsZWQgQXZwcw0KDQogDQp3ZWxsIGl0IGlzIG5vdCBjb21wdWxz b3J5LCBkaWFtZXRlciBtZXNzYWdlcyBtYXkgY29udGFpbiBtdWx0aXBsZSANCkZhaWxlZC1BVlAg YXZwcy4NCiBSaWdodC4gDQpBcyBwZXIgc2VjdGlvbiA1LjMuMiAsIDUuNC4yICwgNS41LjIgb2Yg dGhlIERJQU1FVEVSIEJhc2UgUkZDIDM1ODggYW5kIA0KdmFyaW91cyBhcHBsaWNhdGlvbnMgc3Bl Y2lmaWNhdGlvbnMgc3BlY2lmeSBzdXBwb3J0IGZvciBtdWx0aXBsZSANCkZhaWxlZC1BVlAgYXZw cy4gDQoNCg0KT24gMS85LzA3LCBSYWppdGggUiA8cmFqaXRockBodWF3ZWkuY29tPiB3cm90ZTog DQpBIERpYW1ldGVyIG1lc3NhZ2UgbWF5IGNvbnRhaW4gb25lIChhbmQgb25seSBvbmUpIEZhaWxl ZC1BVlAgQVZQLg0KTm90IHRydWUuDQoNCkZyb206IE5pbWlzaCBCaGFyZ2F2YSBbbWFpbHRvOm5p bWlzaC5iaGFyZ2F2YUBnbWFpbC5jb21dIA0KU2VudDogVHVlc2RheSwgSmFudWFyeSAwOSwgMjAw NyA1OjE5IFBNDQpUbzogZGltZUBpZXRmLm9yZw0KU3ViamVjdDogW0RpbWVdIFJlc3VsdCBjb2Rl IG9mIE11bHRpcGxlIGZhaWxlZCBBdnBzDQoNCkhpIGV2ZXJ5b25lDQoNCldoaWxlIHNlbmRpbmcg YSByZXNwb25zZSBjb250YWluaW5nIG11bHRpcGxlIGZhaWxlZCBBVlBzLCB3aGF0IHNob3VsZCBi ZSANCnRoZSB2YWx1ZSBvZiByZXN1bHQgY29kZSBBVlA/DQpzaW5jZSBkaWZmZXJlbnQgQVZQcyBt YXkgZmFpbCBkdWUgdG8gZGlmZmVyZW50IHJlYXNvbnMsIHNob3VsZCB0aGUgZXJyb3IgDQpjb2Rl IG9mIHRoZSBmaXJzdCBmYWlsZWQgQVZQIGJlIHNlbnQgYXMgcmVzdWx0IGNvZGU/IA0KSSB0aGlu ayB0aGF0IHRoZSBhc3N1bXB0aW9uIHdhcyB0aGF0IHJlY2VpdmVkIG1lc3NhZ2UgcHJvY2Vzc2lu ZyB3b3VsZCANCmhhbHQgb24gdGhlIGZpcnN0IGludmFsaWQgQVZQICYgIGFuIGVycm9yIHJldHVy bmVkLiAgSXQgbWlnaHQgYmUgYSBnb29kIA0KaWRlYSB0byBjaGFuZ2UgdGhlIEZhaWxlZC1BVlAg dG8gaW5jbHVkZSBhbiBlcnJvciBjb2RlLi4uIA0KDQpUaGFua3MNCk5pbWlzaCANCg0KDQoNCg0K LS0gDQpSZWFsIHByb2dyYW1tZXJzIGRvbid0IHdvcmsgZnJvbSA5IHRvIDUuIElmIGFueSByZWFs IHByb2dyYW1tZXJzIGFyZSANCmFyb3VuZCBhdCA5YW0gaXQncyBiZWNhdXNlIHRoZXkgd2VyZSB1 cCBhbGwgbmlnaHQuIA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCkRpTUUgbWFpbGluZyBsaXN0DQpEaU1FQGlldGYub3JnDQpodHRwczovL3d3dzEuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQoNCg0KDQoqKioqKioqKioqKioqKioqKioqKioq KiAgQXJpY2VudC1Qcml2YXRlICAgKioqKioqKioqKioqKioqKioqKioqKioNCiJESVNDTEFJTUVS OiBUaGlzIG1lc3NhZ2UgaXMgcHJvcHJpZXRhcnkgdG8gQXJpY2VudCAgYW5kIGlzIGludGVuZGVk IHNvbGVseSBmb3IgdGhlIHVzZSBvZiAKdGhlIGluZGl2aWR1YWwgdG8gd2hvbSBpdCBpcyBhZGRy ZXNzZWQuIEl0IG1heSBjb250YWluIHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsIGluZm9ybWF0 aW9uIGFuZCBzaG91bGQgbm90IGJlIApjaXJjdWxhdGVkIG9yIHVzZWQgZm9yIGFueSBwdXJwb3Nl IG90aGVyIHRoYW4gZm9yIHdoYXQgaXQgaXMgaW50ZW5kZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgCnBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3IgaW1t ZWRpYXRlbHkuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUg bm90aWZpZWQgdGhhdCB5b3UgYXJlIHN0cmljdGx5CnByb2hpYml0ZWQgZnJvbSB1c2luZywgY29w eWluZywgYWx0ZXJpbmcsIG9yIGRpc2Nsb3NpbmcgdGhlIGNvbnRlbnRzIG9mIHRoaXMgbWVzc2Fn ZS4gQXJpY2VudCBhY2NlcHRzIG5vIHJlc3BvbnNpYmlsaXR5IGZvciAKbG9zcyBvciBkYW1hZ2Ug YXJpc2luZyBmcm9tIHRoZSB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIHRyYW5zbWl0dGVkIGJ5IHRo aXMgZW1haWwgaW5jbHVkaW5nIGRhbWFnZSBmcm9tIHZpcnVzLiIK --=_alternative 002889AE65257265_= Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5JZiB3ZSByZXN0cmljdCB0aGUgZmFpbGVk IEFWUHMganVzdCBvbiB0aGUNCmJhc2lzIG9mIFJlc3VsdC1Db2RlIEFWUCB3ZSBtYXkgbm90IGJl IGFibGUgdG8gcHJvdmlkZSBhbGwgdGhlIGluZm9ybWF0aW9uDQpyZWdhcmRpbmcgdGhlIGZhaWxl ZCBBVlBzIHRvIHRoZSBhcHBsaWNhdGlvbi48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 IkFyaWFsIj5TaW5jZSB0aGUgd2hvbGUgbWVzc2FnZSBzdGlsbCBuZWVkcyB0byBiZQ0KcGFyc2Vk IGluIG9yZGVyIHRvIGZpbmQgb3V0IHRoZSBBVlBzIGZhaWxpbmcgZHVlIHRvIGEgcGFydGljdWxh ciBSZXN1bHQNCkNvZGUsIGl0IHdvdWxkIGJlIGJldHRlciB0byBpbmNsdWRlIGEgUmVzdWx0LUNv ZGUgQVZQIGluIHRoZSBGYWlsZWQtQVZQDQpBQk5GLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQXJpYWwiPlRoYXQgd2F5IG9uZSBjYW4gaW1wbGVtZW50IGJvdGggdGhlIHNj ZW5hcmlvcw0KaS5lLiBzZW5kIEFWUHMgZmFpbGluZyBkdWUgdG8gYSBwYXJ0aWN1bGFyIFJlc3Vs dCBDb2RlIGFuZCBzZW5kaW5nIEZhaWxlZC1BVlBzDQpjaXRpbmcgbXVsdGlwbGUgUmVzdWx0IENv ZGVzLjxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KTmltaXNoPC9mb250Pjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUg d2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTQwJT48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+PGI+UmFqaXRoIFIgJmx0O3Jhaml0aHJAaHVhd2VpLmNvbSZndDs8 L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MDEvMTYvMjAw NyAxMTozMCBBTTwvZm9udD4NCjxicj4NCjx0YWJsZSBib3JkZXI+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZCBiZ2NvbG9yPXdoaXRlPg0KPGRpdiBhbGlnbj1jZW50ZXI+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPlBsZWFzZSByZXNwb25kIHRvPGJyPg0KcmFqaXRockBodWF3ZWkuY29tPC9m b250PjwvZGl2PjwvdGFibGU+DQo8YnI+DQo8dGQgd2lkdGg9NTklPg0KPHRhYmxlIHdpZHRoPTEw MCU+DQo8dHI+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj5UbzwvZm9udD48L2Rpdj4NCjx0ZCB2YWxpZ249dG9wPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj4mcXVvdDsnR2xlbiBab3JuIChnd3opJyZxdW90Ow0KJmx0O2d3ekBjaXNj by5jb20mZ3Q7LCAmcXVvdDsnTmltaXNoIEJoYXJnYXZhJyZxdW90OyAmbHQ7bmltaXNoLmJoYXJn YXZhQGdtYWlsLmNvbSZndDs8L2ZvbnQ+DQo8dHI+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5jYzwvZm9udD48L2Rpdj4NCjx0ZCB2YWxpZ249 dG9wPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5kaW1lQGlldGYub3JnPC9mb250Pg0K PHRyPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+U3ViamVjdDwvZm9udD48L2Rpdj4NCjx0ZCB2YWxpZ249dG9wPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj5SRTogW0RpbWVdIFJlc3VsdCBjb2RlIG9mDQpNdWx0aXBsZSBmYWlsZWQg QXZwczwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj5JZiB0aGUgYXNzdW1wdGlvbiBpcyB0aGF0IG1lc3Nh Z2UNCnByb2Nlc3Npbmcgd291bGQgaGFsdCBvbiBmaXJzdCBmYWlsdXJlLCBJIGNhbid0IHNlZSB3 aHkgYSBEaWFtZXRlciBtZXNzYWdlDQptaWdodCBoYXZlIG1vcmUgdGhhbiBvbmUgRmFpbGVkLUFW UCBBVlAuIFRoZSBSRkMgMzU4OCBtYW5kYXRlcyB0aGF0IHRoZXJlDQpNVVNUIGJlIG9ubHkgb25l IFJlc3VsdC1Db2RlIEFWUCBpbiBhbiBhbnN3ZXIgbWVzc2FnZSAmYW1wOyBpbXBsaWVzICgmcXVv dDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj5UaGUNCnZhbHVlIG9mIHRoZSBSZXN1 bHQtQ29kZSBBVlAgd2lsbCBwcm92aWRlIGluZm9ybWF0aW9uIG9uIHRoZSByZWFzb24gZm9yDQp0 aGUgRmFpbGVkLUFWUCBBVlAuPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkFy aWFsIj4mcXVvdDspDQphIHJlbGF0aW9uIGIvdyB0aGUgUmVzdWx0LUNvZGUgQVZQICZhbXA7IHRo ZSBGYWlsZWQtQVZQIEFWUCwgYWxsIHRoZSBtb3JlDQpyZWFzb24gb24gd2h5IHRoZXJlIE1BWSBi ZSBvbmx5IG9uZSBGYWlsZWQtQVZQIEFWUC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNw OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+SG93ZXZl ciwgYWxsIGVycm9uZW91cyBBVlBzIGFzc29jaWF0ZWQNCndpdGggdGhlIGVycm9yIChmb3IgZWc6 IHRoZSAmcXVvdDtjb250cmFkaWN0aW5nJnF1b3Q7IEFWUHMgaW4gdGhlIGNhc2UNCm9mIERJQU1F VEVSX0NPTlRSQURJQ1RJTkdfQVZQUykgbWF5IGJlIGZpbGxlZCBpbiBvbmUgRmFpbGVkLUFWUCBB VlAgb25seQ0KKHRoZSBBQk5GIGFsbG93cyB0aGlzIHByb3Zpc2lvbik8L2ZvbnQ+DQo8YnI+DQo8 YnI+DQo8aHI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+RnJvbTo8L2I+IEdsZW4gWm9y biAoZ3d6KSBbbWFpbHRvOmd3ekBjaXNjby5jb21dDQo8Yj48YnI+DQpTZW50OjwvYj4gV2VkbmVz ZGF5LCBKYW51YXJ5IDEwLCAyMDA3IDEwOjUyIFBNPGI+PGJyPg0KVG86PC9iPiBOaW1pc2ggQmhh cmdhdmE7IHJhaml0aHJAaHVhd2VpLmNvbTxiPjxicj4NCkNjOjwvYj4gZGltZUBpZXRmLm9yZzxi Pjxicj4NClN1YmplY3Q6PC9iPiBSRTogW0RpbWVdIFJlc3VsdCBjb2RlIG9mIE11bHRpcGxlIGZh aWxlZCBBdnBzPC9mb250Pjxmb250IHNpemU9Mz48YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0zPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+d2VsbCBpdCBpcyBub3QgY29tcHVs c29yeSwgZGlhbWV0ZXIgbWVzc2FnZXMgbWF5IGNvbnRhaW4NCm11bHRpcGxlIEZhaWxlZC1BVlAg YXZwcy48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSM4MDAwODAgZmFjZT0iQXJpYWwiPjxicj4N CiBSaWdodC48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPiA8L2Zv bnQ+PGZvbnQgc2l6ZT0zPjxicj4NCkFzIHBlciBzZWN0aW9uIDUuMy4yICwgNS40LjIgLCA1LjUu MiBvZiB0aGUgRElBTUVURVIgQmFzZSBSRkMgMzU4OCBhbmQNCnZhcmlvdXMgYXBwbGljYXRpb25z IHNwZWNpZmljYXRpb25zIHNwZWNpZnkgc3VwcG9ydCBmb3IgbXVsdGlwbGUgRmFpbGVkLUFWUA0K YXZwcy4gPGJyPg0KPGJyPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz5PbiAxLzkvMDcsIDxi PlJhaml0aCBSPC9iPiAmbHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOnJhaml0aHJAaHVhd2VpLmNv bT48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT5yYWppdGhyQGh1YXdlaS5jb208L3U+PC9mb250 PjwvYT48Zm9udCBzaXplPTM+Jmd0Ow0Kd3JvdGU6IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg Y29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+QSBEaWFtZXRlciBtZXNzYWdlIG1heSBjb250YWluDQpv bmUgKGFuZCBvbmx5IG9uZSkgRmFpbGVkLUFWUCBBVlAuPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBjb2xvcj0jODAwMDgwIGZhY2U9IkFyaWFsIj5Ob3QgdHJ1ZS48L2ZvbnQ+DQo8YnI+DQo8YnI+ DQo8aHI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+RnJvbTo8L2I+IE5pbWlzaCBCaGFy Z2F2YSBbbWFpbHRvOjwvZm9udD48YSBocmVmPW1haWx0bzpuaW1pc2guYmhhcmdhdmFAZ21haWwu Y29tIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48 dT5uaW1pc2guYmhhcmdhdmFAZ21haWwuY29tPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZh Y2U9IlRhaG9tYSI+XQ0KPGI+PGJyPg0KU2VudDo8L2I+IFR1ZXNkYXksIEphbnVhcnkgMDksIDIw MDcgNToxOSBQTTxiPjxicj4NClRvOjwvYj4gPC9mb250PjxhIGhyZWY9bWFpbHRvOmRpbWVAaWV0 Zi5vcmcgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEi Pjx1PmRpbWVAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21h Ij48Yj48YnI+DQpTdWJqZWN0OjwvYj4gW0RpbWVdIFJlc3VsdCBjb2RlIG9mIE11bHRpcGxlIGZh aWxlZCBBdnBzPC9mb250Pjxmb250IHNpemU9Mz48YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0zPkhpIGV2ZXJ5b25lPGJyPg0KPGJyPg0KV2hpbGUgc2VuZGluZyBhIHJlc3BvbnNlIGNvbnRh aW5pbmcgbXVsdGlwbGUgZmFpbGVkIEFWUHMsIHdoYXQgc2hvdWxkIGJlDQp0aGUgdmFsdWUgb2Yg cmVzdWx0IGNvZGUgQVZQPzxicj4NCnNpbmNlIGRpZmZlcmVudCBBVlBzIG1heSBmYWlsIGR1ZSB0 byBkaWZmZXJlbnQgcmVhc29ucywgc2hvdWxkIHRoZSBlcnJvcg0KY29kZSBvZiB0aGUgZmlyc3Qg ZmFpbGVkIEFWUCBiZSBzZW50IGFzIHJlc3VsdCBjb2RlPyA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNv bG9yPSM4MDAwODAgZmFjZT0iQXJpYWwiPjxicj4NCkkgdGhpbmsgdGhhdCB0aGUgYXNzdW1wdGlv biB3YXMgdGhhdCByZWNlaXZlZCBtZXNzYWdlIHByb2Nlc3Npbmcgd291bGQNCmhhbHQgb24gdGhl IGZpcnN0IGludmFsaWQgQVZQICZhbXA7ICZuYnNwO2FuIGVycm9yIHJldHVybmVkLiAmbmJzcDtJ dCBtaWdodA0KYmUgYSBnb29kIGlkZWEgdG8gY2hhbmdlIHRoZSBGYWlsZWQtQVZQIHRvIGluY2x1 ZGUgYW4gZXJyb3IgY29kZS4uLiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPjxicj4NClRoYW5r czxicj4NCk5pbWlzaCA8YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPjxicj4NCjxicj4N Cjxicj4NCi0tIDxicj4NClJlYWwgcHJvZ3JhbW1lcnMgZG9uJ3Qgd29yayBmcm9tIDkgdG8gNS4g SWYgYW55IHJlYWwgcHJvZ3JhbW1lcnMgYXJlIGFyb3VuZA0KYXQgOWFtIGl0J3MgYmVjYXVzZSB0 aGV5IHdlcmUgdXAgYWxsIG5pZ2h0LiA8L2ZvbnQ+PHR0Pjxmb250IHNpemU9Mj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkRpTUUgbWFpbGluZyBs aXN0PGJyPg0KRGlNRUBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2RpbWU8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KKioqKioqKioqKioqKioqKioqKioqKiogJm5ic3A7QXJp Y2VudC1Qcml2YXRlICZuYnNwOyAqKioqKioqKioqKioqKioqKioqKioqKjwvZm9udD4NCjx0YWJs ZT48dHI+PHRkIGJnY29sb3I9I2ZmZmZmZj48Zm9udCBjb2xvcj0jMDAwMDAwPjxwcmU+IkRJU0NM QUlNRVI6IFRoaXMgbWVzc2FnZSBpcyBwcm9wcmlldGFyeSB0byBBcmljZW50ICBhbmQgaXMgaW50 ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIAp0aGUgaW5kaXZpZHVhbCB0byB3aG9tIGl0IGlz IGFkZHJlc3NlZC4gSXQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwgaW5m b3JtYXRpb24gYW5kIHNob3VsZCBub3QgYmUgCmNpcmN1bGF0ZWQgb3IgdXNlZCBmb3IgYW55IHB1 cnBvc2Ugb3RoZXIgdGhhbiBmb3Igd2hhdCBpdCBpcyBpbnRlbmRlZC4gSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCAKcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRv ciBpbW1lZGlhdGVseS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91 IGFyZSBub3RpZmllZCB0aGF0IHlvdSBhcmUgc3RyaWN0bHkKcHJvaGliaXRlZCBmcm9tIHVzaW5n LCBjb3B5aW5nLCBhbHRlcmluZywgb3IgZGlzY2xvc2luZyB0aGUgY29udGVudHMgb2YgdGhpcyBt ZXNzYWdlLiBBcmljZW50IGFjY2VwdHMgbm8gcmVzcG9uc2liaWxpdHkgZm9yIApsb3NzIG9yIGRh bWFnZSBhcmlzaW5nIGZyb20gdGhlIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gdHJhbnNtaXR0ZWQg YnkgdGhpcyBlbWFpbCBpbmNsdWRpbmcgZGFtYWdlIGZyb20gdmlydXMuIgo8L3ByZT48L2ZvbnQ+ PC90ZD48L3RyPjwvdGFibGU+ --=_alternative 002889AE65257265_=-- --===============1551781491== 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 --===============1551781491==-- From dime-bounces@ietf.org Tue Jan 16 07:06:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6n4g-0006oE-1V; Tue, 16 Jan 2007 07:05:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6n4e-0006o9-OW for dime@ietf.org; Tue, 16 Jan 2007 07:05:56 -0500 Received: from smtp.operax.com ([213.50.74.226] helo=smtp-dmz.operax.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6n4e-0008NS-0j for dime@ietf.org; Tue, 16 Jan 2007 07:05:56 -0500 Received: from lulex02.ad.operax.com (ad.operax.com [192.168.2.13]) by smtp-dmz.operax.com (8.13.1/8.13.1) with ESMTP id l0GC5nqu072721 for ; Tue, 16 Jan 2007 13:05:49 +0100 (CET) (envelope-from Ulf.Bodin@operax.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jan 2007 13:05:48 +0100 Message-ID: <33656995C5C5094A983DE84DA649A924EB0CE9@lulex02.ad.operax.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The Auditing Problem Thread-Index: AcctnTPxae5ySD5URAqDhd9ad4a6eQIk+xPgAM1g5wA= From: "Ulf Bodin" To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (smtp-dmz.operax.com [172.16.1.4]); Tue, 16 Jan 2007 13:05:49 +0100 (CET) X-Spam-Status: No, score=-102.6 required=4.7 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on smtp-dmz.operax.com X-Virus-Scanned: ClamAV 0.88.7/2456/Tue Jan 16 10:02:32 2007 on smtp-dmz.operax.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Subject: [Dime] RE: The Auditing Problem 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 Folks,=20 Following Hannes advice I've put together a first proposal for more detailed example scenarios/use cases.=20 Before going into those use cases I just want to remind of the earlier discussion on applicability by repeating my opinion of that a good design approach would be to for a new application first explore if soft-state without auditing is sufficient before considering designing for auditing (in case we manage to specify a solution for auditing that is :-). Such an apporach is in my view beneficial since auditing adds complexity and creates excess signaling traffic (potentially at times when additional signaling load should be avoided).=20 Anyway, considering applications for which auditing is deemed needed I beleive the following use cases to represent typical scenarios for which auditing provides a clear value.=20 I'm starting with describing the last one (I think the hard-state use cases more clearly need auditing). Also, I believe the requirements to be quite similar for both client and server failover. Hence, for now I'm only considering server failover (i.e. to not take a too big bite too soon ... ).=20 Use case 1: Hard-state without state replication In general this type of use case can be expected to only apply to low-volume and long holding-time applications. For such applications the overhead of performing state rebuild through auditing may be tolerated as it can spare resources (i.e. state replication may consume hardware (CPU and memory) and network resources).=20 Use case TBD. =20 Use case 2: Hard-state with replication=20 Server failover=20 This use case would be basically the same as use case 4 for server failover except that the period for which the server sB operats on inaccurate information will last until a management function terminates malicious states.=20 Use case 3: Soft-state without replication=20 Use case TBD.=20 Use case 4: Soft-state with replication=20 Server failover=20 The application I have in mind for this use case is a resource reservation made by a client to ETSI TISPAN RACS. I think this use case should prefereably be agnostic to the particular application though. Hence, the text does not refer explicitly to this application (which I believe is a good example, but not necessarily the only example).=20 Server (B) is a backup for server (A). States of server (A) is replicated via its database (a) (e.g. using high availability middleware for replicating data). Writing data to database (a) is asyncronous and so is the replication between the two databases.=20 +------------+ 1 +------------+ 2 +---------------+ | soft-state +------>+ soft-state +------>+ replicated | | client (cA)+ | server (sA)| | database (DBa)| +------------+ +------------+ +------+--------+ 3 | v +------------+ +------------+ +---------------+ | soft-state | | soft-state | 5 | replicated | | client (cB)+------>+ server (sB)|<------+ database (DBb)| +------------+ 4 +------------+ +---------------+ Now, say that the client cA "1" requests a service from server sA resulting in that a soft-state is created in this server. Server sA replies to the request in parallel with "2" storing the state in its database DBa, whereafter this database "3" replicates the state to database DBb. After cA receives the reply sA however craches and subsequent requests of this client will therefore go to sB (e.g. automatically selected through SCTP multihoming or gratuitous ARP for IP takeover). The change of server is transparant to the client.=20 The state established by client cA may not have been written to database DBa before server sA crached. In case it was not written the state would not have been replicated to DBb either. Alternatively, the state may have been written to DBa, but not replicated to DBb. This means that when sB receives "4" a request from cB (which may has had sB as its primary server since before or also has switched from sA because it chrached) and uses the "5" obtained set of states from DBb, which is inaccurate. Consequently, sB will produce the wrong answer to cB. E.g. in case of RACS accept (or deny) a reservation request because it didn't know that the requested resources are already booked (or released) by cA.=20 The state is indeed soft and client cA will hence eventually learn that it's no longer valid. Client cA will however believe the state to be valid for a period up to the timer value, which can be several hundereds of seconds. E.g. in case of reservations for telephony the mean holding time for calls can be in the order of 300 seconds and setting the timer to this value make sence since that keeps the signaling traffic for updates sufficiently low. =20 An optimization of this use case using auditing is to have server sB ask its clients for lists of their respective active sessions (i.e. lists of active sessions IDs). Such auditing request would be triggered by the event of that sB learns that it has taken over clients from sA. Based on these lists sB can determine of sessions it believes being active are really terminated and identify active but unknown sessions. For sessions being unknown to sB it can chose to either just wait until they expires, or explicitly ask the clients for more information on those sessions (i.e. in order to completely or partly re-create the missing states). The benefit of auditing is in this use case the period for which sB operates on inaccurate information can be reduced to a few seconds instead of potentially several hundreds of seconds.=20 To summarize; the auditing mechanisms involved in this use case are (1) request from server to client for all active sessions and (2) request from server to client for all details known by the client on a specific session. =20 Comments? Best regards, Ulf=20 -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: den 1 januari 2007 13:06 To: Ulf Bodin; Tolga Asveren Cc: dime@ietf.org Subject: The Auditing Problem Hi Ulf, Hi Tolga, I think that the discussion triggered by Tolga was quite helpful in order to get a better understanding of the auditing work. What I would like to see is a more detailed example scenario (possibly with message flows). Tolga provided a scenario with a figure but it needs to be enhanced when it comes to the "service logic functionality". I think that this is important since there is a front-end and a back-end part to the entire story. The TISPAN QoS scenario has been mentioned as a potential customer of this work and it could be a nice example to see how the failure cases happen and how state is requested and moved around. I can imagine that there are a number of issues that need to be discussed when we jump into the details. I have also noticed that a number of terms are used without clearly describing them. For example, there are a number of different failover cases that need more description to ensure that we are on the same page. Another example: What is the definition for "session leaking"? Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jan 16 08:02:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6nxP-0006DR-Oi; Tue, 16 Jan 2007 08:02:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6OhW-0005UO-S1 for dime@ietf.org; Mon, 15 Jan 2007 05:04:26 -0500 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6OhT-0002cl-DC for dime@ietf.org; Mon, 15 Jan 2007 05:04:26 -0500 Received: by ug-out-1314.google.com with SMTP id 72so1174127ugd for ; Mon, 15 Jan 2007 02:04:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=DX6qNWuLiv2DMwaEor1ZvJGATlnx97xCzazlP4B3MyWR6MvulXKrSeVn1nOFYp6kQe6IfeaeKuADfDtDKD5HPQYtn+8wQ0kTtHi5q4sfjVc+/U8LENGkTd6/ymcBLH5tEigWo3lkPPpChSLMGKIQm5567OhddLawcCVQEOLuW4g= Received: by 10.67.119.13 with SMTP id w13mr5163162ugm.1168855461838; Mon, 15 Jan 2007 02:04:21 -0800 (PST) Received: from ?192.168.1.110? ( [212.119.9.178]) by mx.google.com with ESMTP id 20sm5378492uga.2007.01.15.02.04.20; Mon, 15 Jan 2007 02:04:21 -0800 (PST) From: Julien Laganier To: dime@ietf.org, Madjid Nakhjiri Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Security Date: Mon, 15 Jan 2007 11:03:21 +0100 User-Agent: KMail/1.8.2 References: <002701c73678$2eee19c0$2f01a8c0@china.huawei.com> In-Reply-To: <002701c73678$2eee19c0$2f01a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701151103.21533.julien.laganier@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c X-Mailman-Approved-At: Tue, 16 Jan 2007 08:02:31 -0500 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 On Friday 12 January 2007 19:33, Madjid Nakhjiri wrote: > Hi Julien, Hi Madjid, > While I appreciate the threat analysis here, the > problem is pretty easy to solve. Unless, we want to > leave this vulnerability as something only for the > security consideration, I suggest we add the > security measure. Solving the problem implies that we understand it. I am still not convinced that separation of authentication and authorization does indeed introduce a new vulnerability -- see my other note on the subject: http://www1.ietf.org/mail-archive/web/dime/current/msg01178.html Until we determine what are the threats and attacks, and determine whether each of them does represent a sufficiently important risk which deserve a countermeasure, I really think it is premature to devise solutions. Best, --julien > I am working on a draft that shows how you can > separate authentication and authorization while > binding the two together. The draft will be > submitted soon (or at least before next IETF > deadline). There is one problem remaining and that > is I am wondering about the messaging triggers (see > below). If people like the solution we can use it > for the WG draft. It is just hard to show a solution > over ML, sorry. > > For now, I say, we can use the EAP method to > generate MSK/EMSK and then use those keys in > assurance for previous authentication (Diameter EAP) > to the authorization server for Diameter MIP. > The issue is that based on the threat analysis that > you provided, we cannot trust HA to provide this > assurance. It has to come from the peer and/or AAA > server. > One way would be for the peer to generate the key > sign its request with this key. Without getting into > the details right now, the issue would be: What > message would carry this signature from the peer? > And this is why I have been asking the question of > what message would trigger the Mobile IP > Authorization (MAR) message and what is the timing > of MAR/MAA w.r.t IKEv2. > > The problem is that we need to perform all Mobile IP > bootstrapping after MAA, i.e. after the MN is > actually authorized for Mobile IP, so if there is > any message (even an IKEv2 message) that carries a > Mobile IP parameter, it has to come after MAA. > > Hope I am making sense, > > Madjid _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jan 16 13:38:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6tCB-0005yY-50; Tue, 16 Jan 2007 13:38:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6tC9-0005xr-4F for dime@ietf.org; Tue, 16 Jan 2007 13:38:05 -0500 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6tC7-0007iV-GX for dime@ietf.org; Tue, 16 Jan 2007 13:38:05 -0500 Received: by ug-out-1314.google.com with SMTP id 72so1592782ugd for ; Tue, 16 Jan 2007 10:38:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=OV0Fd+gabzyntyTQfcxaTopOjG6eRkYgck5kIzLtjXhzx2ITBRCVe0ILH5Opx4iboUCrT3Es6ku7LH75OHV5LLL9f9Phn/vQ+7dZOqthl+IAeBmAqjCt7QTKXS7a9KiFcpm25KXZWdAdIwAogu3qfIT+FuN7dds7wEivzNWkDRo= Received: by 10.82.182.8 with SMTP id e8mr1314750buf.1168972681771; Tue, 16 Jan 2007 10:38:01 -0800 (PST) Received: by 10.82.158.4 with HTTP; Tue, 16 Jan 2007 10:38:01 -0800 (PST) Message-ID: <5be720c40701161038w1d42de60ud0519d4ef04d1cf3@mail.gmail.com> Date: Wed, 17 Jan 2007 00:08:01 +0530 From: "Monal Sengar" To: dime@ietf.org In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.5 (/) X-Scan-Signature: 9724479da43a8325ad975c1a9b841870 Subject: [Dime] Re: DiME Digest, Vol 13, Issue 10 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="===============0929030645==" Errors-To: dime-bounces@ietf.org --===============0929030645== Content-Type: multipart/alternative; boundary="----=_Part_78797_3749369.1168972681555" ------=_Part_78797_3749369.1168972681555 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I agree with Rajith as as per section Section 7 (page 83) " The Result-Code AVP describes the error that the Diameter node encountered in its processing. In case there are multiple errors, the Diameter node MUST report only the first error it encountered." So there shouldnt be the case when we need to report multiple Failed AVP. Regards Monal On 1/16/07, dime-request@ietf.org wrote: > > Send DiME mailing list submissions to > dime@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/dime > or, via email, send a message with subject or body 'help' to > dime-request@ietf.org > > You can reach the person managing the list at > dime-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of DiME digest..." > > > Today's Topics: > > 1. RE: Result code of Multiple failed Avps (Rajith R) > 2. RE: Result code of Multiple failed Avps (Nimish Bhargava) > 3. RE: The Auditing Problem (Ulf Bodin) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 16 Jan 2007 11:30:55 +0530 > From: Rajith R > Subject: RE: [Dime] Result code of Multiple failed Avps > To: "'Glen Zorn (gwz)'" , 'Nimish Bhargava' > > Cc: dime@ietf.org > Message-ID: <002901c73933$afdc1560$3c04120a@china.huawei.com> > Content-Type: text/plain; charset="us-ascii" > > If the assumption is that message processing would halt on first failure, > I > can't see why a Diameter message might have more than one Failed-AVP AVP. > The RFC 3588 mandates that there MUST be only one Result-Code AVP in an > answer message & implies ("The value of the Result-Code AVP will provide > information on the reason for the Failed-AVP AVP.") a relation b/w the > Result-Code AVP & the Failed-AVP AVP, all the more reason on why there MAY > be only one Failed-AVP AVP. > > However, all erroneous AVPs associated with the error (for eg: the > "contradicting" AVPs in the case of DIAMETER_CONTRADICTING_AVPS) may be > filled in one Failed-AVP AVP only (the ABNF allows this provision) > > > _____ > > From: Glen Zorn (gwz) [mailto:gwz@cisco.com] > Sent: Wednesday, January 10, 2007 10:52 PM > To: Nimish Bhargava; rajithr@huawei.com > Cc: dime@ietf.org > Subject: RE: [Dime] Result code of Multiple failed Avps > > > > well it is not compulsory, diameter messages may contain multiple > Failed-AVP > avps. > Right. > As per section 5.3.2 , 5.4.2 , 5.5.2 of the DIAMETER Base RFC 3588 and > various applications specifications specify support for multiple > Failed-AVP > avps. > > > > On 1/9/07, Rajith R wrote: > > A Diameter message may contain one (and only one) Failed-AVP AVP. > Not true. > > > > _____ > > From: Nimish Bhargava [mailto:nimish.bhargava@gmail.com] > Sent: Tuesday, January 09, 2007 5:19 PM > To: dime@ietf.org > Subject: [Dime] Result code of Multiple failed Avps > > > > Hi everyone > > While sending a response containing multiple failed AVPs, what should be > the > value of result code AVP? > since different AVPs may fail due to different reasons, should the error > code of the first failed AVP be sent as result code? > I think that the assumption was that received message processing would > halt > on the first invalid AVP & an error returned. It might be a good idea to > change the Failed-AVP to include an error code... > > Thanks > Nimish > > > > > > > -- > Real programmers don't work from 9 to 5. If any real programmers are > around > at 9am it's because they were up all night. > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://www1.ietf.org/pipermail/dime/attachments/20070116/c269a5c5/attachment-0001.html > > ------------------------------ > > Message: 2 > Date: Tue, 16 Jan 2007 12:56:24 +0530 > From: Nimish Bhargava > Subject: RE: [Dime] Result code of Multiple failed Avps > To: rajithr@huawei.com > Cc: dime@ietf.org, "'Glen Zorn \(gwz\)'" > Message-ID: > < > OFF6958C05.DB9D3DD5-ON65257265.0027EC42-65257265.002889B1@flextronicssoftware.com > > > > Content-Type: text/plain; charset="us-ascii" > > If we restrict the failed AVPs just on the basis of Result-Code AVP we may > not be able to provide all the information regarding the failed AVPs to > the application. > Since the whole message still needs to be parsed in order to find out the > AVPs failing due to a particular Result Code, it would be better to > include a Result-Code AVP in the Failed-AVP ABNF. > > That way one can implement both the scenarios i.e. send AVPs failing due > to a particular Result Code and sending Failed-AVPs citing multiple Result > Codes. > > Regards, > Nimish > > > > > Rajith R > 01/16/2007 11:30 AM > > Please respond to > rajithr@huawei.com > > > To > "'Glen Zorn (gwz)'" , "'Nimish Bhargava'" > > cc > dime@ietf.org > Subject > RE: [Dime] Result code of Multiple failed Avps > > > > > > > If the assumption is that message processing would halt on first failure, > I can't see why a Diameter message might have more than one Failed-AVP > AVP. The RFC 3588 mandates that there MUST be only one Result-Code AVP in > an answer message & implies ("The value of the Result-Code AVP will > provide information on the reason for the Failed-AVP AVP.") a relation b/w > the Result-Code AVP & the Failed-AVP AVP, all the more reason on why there > MAY be only one Failed-AVP AVP. > > However, all erroneous AVPs associated with the error (for eg: the > "contradicting" AVPs in the case of DIAMETER_CONTRADICTING_AVPS) may be > filled in one Failed-AVP AVP only (the ABNF allows this provision) > > From: Glen Zorn (gwz) [mailto:gwz@cisco.com] > Sent: Wednesday, January 10, 2007 10:52 PM > To: Nimish Bhargava; rajithr@huawei.com > Cc: dime@ietf.org > Subject: RE: [Dime] Result code of Multiple failed Avps > > > well it is not compulsory, diameter messages may contain multiple > Failed-AVP avps. > Right. > As per section 5.3.2 , 5.4.2 , 5.5.2 of the DIAMETER Base RFC 3588 and > various applications specifications specify support for multiple > Failed-AVP avps. > > > On 1/9/07, Rajith R wrote: > A Diameter message may contain one (and only one) Failed-AVP AVP. > Not true. > > From: Nimish Bhargava [mailto:nimish.bhargava@gmail.com] > Sent: Tuesday, January 09, 2007 5:19 PM > To: dime@ietf.org > Subject: [Dime] Result code of Multiple failed Avps > > Hi everyone > > While sending a response containing multiple failed AVPs, what should be > the value of result code AVP? > since different AVPs may fail due to different reasons, should the error > code of the first failed AVP be sent as result code? > I think that the assumption was that received message processing would > halt on the first invalid AVP & an error returned. It might be a good > idea to change the Failed-AVP to include an error code... > > Thanks > Nimish > > > > > -- > Real programmers don't work from 9 to 5. If any real programmers are > around at 9am it's because they were up all night. > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > > *********************** Aricent-Private *********************** > "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." > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://www1.ietf.org/pipermail/dime/attachments/20070116/65bf6b68/attachment-0001.html > > ------------------------------ > > Message: 3 > Date: Tue, 16 Jan 2007 13:05:48 +0100 > From: "Ulf Bodin" > Subject: [Dime] RE: The Auditing Problem > To: > Message-ID: > <33656995C5C5094A983DE84DA649A924EB0CE9@lulex02.ad.operax.com> > Content-Type: text/plain; charset="us-ascii" > > Folks, > > Following Hannes advice I've put together a first proposal for more > detailed example scenarios/use cases. > > Before going into those use cases I just want to remind of the earlier > discussion on applicability by repeating my opinion of that a good > design approach would be to for a new application first explore if > soft-state without auditing is sufficient before considering designing > for auditing (in case we manage to specify a solution for auditing that > is :-). Such an apporach is in my view beneficial since auditing adds > complexity and creates excess signaling traffic (potentially at times > when additional signaling load should be avoided). > > Anyway, considering applications for which auditing is deemed needed I > beleive the following use cases to represent typical scenarios for which > auditing provides a clear value. > > I'm starting with describing the last one (I think the hard-state use > cases more clearly need auditing). Also, I believe the requirements to > be quite similar for both client and server failover. Hence, for now I'm > only considering server failover (i.e. to not take a too big bite too > soon ... ). > > Use case 1: Hard-state without state replication > > In general this type of use case can be expected to only apply to > low-volume and long holding-time applications. For such applications the > overhead of performing state rebuild through auditing may be tolerated > as it can spare resources (i.e. state replication may consume hardware > (CPU and memory) and network resources). > > Use case TBD. > > Use case 2: Hard-state with replication > > Server failover > > This use case would be basically the same as use case 4 for server > failover except that the period for which the server sB operats on > inaccurate information will last until a management function terminates > malicious states. > > Use case 3: Soft-state without replication > > Use case TBD. > > Use case 4: Soft-state with replication > > Server failover > > The application I have in mind for this use case is a resource > reservation made by a client to ETSI TISPAN RACS. I think this use case > should prefereably be agnostic to the particular application though. > Hence, the text does not refer explicitly to this application (which I > believe is a good example, but not necessarily the only example). > > Server (B) is a backup for server (A). States of server (A) is > replicated via its database (a) (e.g. using high availability middleware > for replicating data). Writing data to database (a) is asyncronous and > so is the replication between the two databases. > > +------------+ 1 +------------+ 2 +---------------+ > | soft-state +------>+ soft-state +------>+ replicated | > | client (cA)+ | server (sA)| | database (DBa)| > +------------+ +------------+ +------+--------+ > 3 | > v > +------------+ +------------+ +---------------+ > | soft-state | | soft-state | 5 | replicated | > | client (cB)+------>+ server (sB)|<------+ database (DBb)| > +------------+ 4 +------------+ +---------------+ > > Now, say that the client cA "1" requests a service from server sA > resulting in that a soft-state is created in this server. Server sA > replies to the request in parallel with "2" storing the state in its > database DBa, whereafter this database "3" replicates the state to > database DBb. After cA receives the reply sA however craches and > subsequent requests of this client will therefore go to sB (e.g. > automatically selected through SCTP multihoming or gratuitous ARP for IP > takeover). The change of server is transparant to the client. > > The state established by client cA may not have been written to database > DBa before server sA crached. In case it was not written the state would > not have been replicated to DBb either. Alternatively, the state may > have been written to DBa, but not replicated to DBb. This means that > when sB receives "4" a request from cB (which may has had sB as its > primary server since before or also has switched from sA because it > chrached) and uses the "5" obtained set of states from DBb, which is > inaccurate. Consequently, sB will produce the wrong answer to cB. E.g. > in case of RACS accept (or deny) a reservation request because it didn't > know that the requested resources are already booked (or released) by > cA. > > The state is indeed soft and client cA will hence eventually learn that > it's no longer valid. Client cA will however believe the state to be > valid for a period up to the timer value, which can be several hundereds > of seconds. E.g. in case of reservations for telephony the mean holding > time for calls can be in the order of 300 seconds and setting the timer > to this value make sence since that keeps the signaling traffic for > updates sufficiently low. > > An optimization of this use case using auditing is to have server sB ask > its clients for lists of their respective active sessions (i.e. lists of > active sessions IDs). Such auditing request would be triggered by the > event of that sB learns that it has taken over clients from sA. Based on > these lists sB can determine of sessions it believes being active are > really terminated and identify active but unknown sessions. For sessions > being unknown to sB it can chose to either just wait until they expires, > or explicitly ask the clients for more information on those sessions > (i.e. in order to completely or partly re-create the missing states). > The benefit of auditing is in this use case the period for which sB > operates on inaccurate information can be reduced to a few seconds > instead of potentially several hundreds of seconds. > > To summarize; the auditing mechanisms involved in this use case are (1) > request from server to client for all active sessions and (2) request > from server to client for all details known by the client on a specific > session. > > Comments? > > Best regards, > Ulf > > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: den 1 januari 2007 13:06 > To: Ulf Bodin; Tolga Asveren > Cc: dime@ietf.org > Subject: The Auditing Problem > > Hi Ulf, > Hi Tolga, > > I think that the discussion triggered by Tolga was quite helpful in > order to get a better understanding of the auditing work. > > What I would like to see is a more detailed example scenario (possibly > with message flows). Tolga provided a scenario with a figure but it > needs to be enhanced when it comes to the "service logic functionality". > > I think that this is important since there is a front-end and a back-end > part to the entire story. The TISPAN QoS scenario has been mentioned as > a potential customer of this work and it could be a nice example to see > how the failure cases happen and how state is requested and moved > around. I can imagine that there are a number of issues that need to be > discussed when we jump into the details. > > I have also noticed that a number of terms are used without clearly > describing them. For example, there are a number of different failover > cases that need more description to ensure that we are on the same page. > > Another example: What is the definition for "session leaking"? > > Ciao > Hannes > > > > > ------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > End of DiME Digest, Vol 13, Issue 10 > ************************************ > ------=_Part_78797_3749369.1168972681555 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

I agree with Rajith as as per section Section 7 (page 83) " The Result-Code AVP describes the error that the Diameter node  encountered in its processing.  In case there are multiple errors, the Diameter node MUST report only the first error it encountered."

 So there shouldnt be the case when we need to report multiple Failed AVP.

Regards

Monal

 



On 1/16/07, dime-request@ietf.org <dime-request@ietf.org> wrote:
Send DiME mailing list submissions to
        dime@ietf.org

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

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

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


Today's Topics:

   1. RE: Result code of Multiple failed Avps (Rajith R)
   2. RE: Result code of Multiple failed Avps (Nimish Bhargava)
   3. RE: The Auditing Problem (Ulf Bodin)


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

Message: 1
Date: Tue, 16 Jan 2007 11:30:55 +0530
From: Rajith R <rajithr@huawei.com >
Subject: RE: [Dime] Result code of Multiple failed Avps
To: "'Glen Zorn (gwz)'" <gwz@cisco.com>,        'Nimish Bhargava'
        < nimish.bhargava@gmail.com>
Cc: dime@ietf.org
Message-ID: <002901c73933$afdc1560$3c04120a@china.huawei.com >
Content-Type: text/plain; charset="us-ascii"

If the assumption is that message processing would halt on first failure, I
can't see why a Diameter message might have more than one Failed-AVP AVP.
The RFC 3588 mandates that there MUST be only one Result-Code AVP in an
answer message & implies ("The value of the Result-Code AVP will provide
information on the reason for the Failed-AVP AVP.") a relation b/w the
Result-Code AVP & the Failed-AVP AVP, all the more reason on why there MAY
be only one Failed-AVP AVP.

However, all erroneous AVPs associated with the error (for eg: the
"contradicting" AVPs in the case of DIAMETER_CONTRADICTING_AVPS) may be
filled in one Failed-AVP AVP only (the ABNF allows this provision)


  _____

From: Glen Zorn (gwz) [mailto:gwz@cisco.com]
Sent: Wednesday, January 10, 2007 10:52 PM
To: Nimish Bhargava; rajithr@huawei.com
Cc: dime@ietf.org
Subject: RE: [Dime] Result code of Multiple failed Avps



well it is not compulsory, diameter messages may contain multiple Failed-AVP
avps.
Right.
As per section 5.3.2 , 5.4.2 , 5.5.2 of the DIAMETER Base RFC 3588 and
various applications specifications specify support for multiple Failed-AVP
avps.



On 1/9/07, Rajith R < rajithr@huawei.com> wrote:

A Diameter message may contain one (and only one) Failed-AVP AVP.
Not true.



  _____

From: Nimish Bhargava [mailto: nimish.bhargava@gmail.com]
Sent: Tuesday, January 09, 2007 5:19 PM
To: dime@ietf.org
Subject: [Dime] Result code of Multiple failed Avps



Hi everyone

While sending a response containing multiple failed AVPs, what should be the
value of result code AVP?
since different AVPs may fail due to different reasons, should the error
code of the first failed AVP be sent as result code?
I think that the assumption was that received message processing would halt
on the first invalid AVP &  an error returned.  It might be a good idea to
change the Failed-AVP to include an error code...

Thanks
Nimish






--
Real programmers don't work from 9 to 5. If any real programmers are around
at 9am it's because they were up all night.

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

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

Message: 2
Date: Tue, 16 Jan 2007 12:56:24 +0530
From: Nimish Bhargava < nimish.bhargava@aricent.com>
Subject: RE: [Dime] Result code of Multiple failed Avps
To: rajithr@huawei.com
Cc: dime@ietf.org, "'Glen Zorn \(gwz\)'" < gwz@cisco.com>
Message-ID:
        <OFF6958C05.DB9D3DD5-ON65257265.0027EC42-65257265.002889B1@flextronicssoftware.com >

Content-Type: text/plain; charset="us-ascii"

If we restrict the failed AVPs just on the basis of Result-Code AVP we may
not be able to provide all the information regarding the failed AVPs to
the application.
Since the whole message still needs to be parsed in order to find out the
AVPs failing due to a particular Result Code, it would be better to
include a Result-Code AVP in the Failed-AVP ABNF.

That way one can implement both the scenarios i.e. send AVPs failing due
to a particular Result Code and sending Failed-AVPs citing multiple Result
Codes.

Regards,
Nimish




Rajith R < rajithr@huawei.com>
01/16/2007 11:30 AM

Please respond to
rajithr@huawei.com


To
"'Glen Zorn (gwz)'" < gwz@cisco.com>, "'Nimish Bhargava'"
<nimish.bhargava@gmail.com>
cc
dime@ietf.org
Subject
RE: [Dime] Result code of Multiple failed Avps






If the assumption is that message processing would halt on first failure,
I can't see why a Diameter message might have more than one Failed-AVP
AVP. The RFC 3588 mandates that there MUST be only one Result-Code AVP in
an answer message & implies ("The value of the Result-Code AVP will
provide information on the reason for the Failed-AVP AVP.") a relation b/w
the Result-Code AVP & the Failed-AVP AVP, all the more reason on why there
MAY be only one Failed-AVP AVP.

However, all erroneous AVPs associated with the error (for eg: the
"contradicting" AVPs in the case of DIAMETER_CONTRADICTING_AVPS) may be
filled in one Failed-AVP AVP only (the ABNF allows this provision)

From: Glen Zorn (gwz) [mailto:gwz@cisco.com]
Sent: Wednesday, January 10, 2007 10:52 PM
To: Nimish Bhargava; rajithr@huawei.com
Cc: dime@ietf.org
Subject: RE: [Dime] Result code of Multiple failed Avps


well it is not compulsory, diameter messages may contain multiple
Failed-AVP avps.
Right.
As per section 5.3.2 , 5.4.2 , 5.5.2 of the DIAMETER Base RFC 3588 and
various applications specifications specify support for multiple
Failed-AVP avps.


On 1/9/07, Rajith R < rajithr@huawei.com> wrote:
A Diameter message may contain one (and only one) Failed-AVP AVP.
Not true.

From: Nimish Bhargava [mailto: nimish.bhargava@gmail.com]
Sent: Tuesday, January 09, 2007 5:19 PM
To: dime@ietf.org
Subject: [Dime] Result code of Multiple failed Avps

Hi everyone

While sending a response containing multiple failed AVPs, what should be
the value of result code AVP?
since different AVPs may fail due to different reasons, should the error
code of the first failed AVP be sent as result code?
I think that the assumption was that received message processing would
halt on the first invalid AVP &  an error returned.  It might be a good
idea to change the Failed-AVP to include an error code...

Thanks
Nimish




--
Real programmers don't work from 9 to 5. If any real programmers are
around at 9am it's because they were up all night.
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime



***********************  Aricent-Private   ***********************
"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."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www1.ietf.org/pipermail/dime/attachments/20070116/65bf6b68/attachment-0001.html

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

Message: 3
Date: Tue, 16 Jan 2007 13:05:48 +0100
From: "Ulf Bodin" < Ulf.Bodin@operax.com>
Subject: [Dime] RE: The Auditing Problem
To: <dime@ietf.org>
Message-ID:
        < 33656995C5C5094A983DE84DA649A924EB0CE9@lulex02.ad.operax.com>
Content-Type: text/plain;       charset="us-ascii"

Folks,

Following Hannes advice I've put together a first proposal for more
detailed example scenarios/use cases.

Before going into those use cases I just want to remind of the earlier
discussion on applicability by repeating my opinion of that a good
design approach would be to for a new application first explore if
soft-state without auditing is sufficient before considering designing
for auditing (in case we manage to specify a solution for auditing that
is :-). Such an apporach is in my view beneficial since auditing adds
complexity and creates excess signaling traffic (potentially at times
when additional signaling load should be avoided).

Anyway, considering applications for which auditing is deemed needed I
beleive the following use cases to represent typical scenarios for which
auditing provides a clear value.

I'm starting with describing the last one (I think the hard-state use
cases more clearly need auditing). Also, I believe the requirements to
be quite similar for both client and server failover. Hence, for now I'm
only considering server failover (i.e. to not take a too big bite too
soon ... ).

Use case 1: Hard-state without state replication

In general this type of use case can be expected to only apply to
low-volume and long holding-time applications. For such applications the
overhead of performing state rebuild through auditing may be tolerated
as it can spare resources (i.e. state replication may consume hardware
(CPU and memory) and network resources).

Use case TBD.

Use case 2: Hard-state with replication

Server failover

This use case would be basically the same as use case 4 for server
failover except that the period for which the server sB operats on
inaccurate information will last until a management function terminates
malicious states.

Use case 3: Soft-state without replication

Use case TBD.

Use case 4: Soft-state with replication

Server failover

The application I have in mind for this use case is a resource
reservation made by a client to ETSI TISPAN RACS. I think this use case
should prefereably be agnostic to the particular application though.
Hence, the text does not refer explicitly to this application (which I
believe is a good example, but not necessarily the only example).

Server (B) is a backup for server (A). States of server (A) is
replicated via its database (a) ( e.g. using high availability middleware
for replicating data). Writing data to database (a) is asyncronous and
so is the replication between the two databases.

+------------+   1   +------------+   2   +---------------+
| soft-state +------>+ soft-state +------>+ replicated    |
| client (cA)+       | server (sA)|       | database (DBa)|
+------------+       +------------+       +------+--------+
                                               3 |
                                                 v
+------------+       +------------+       +---------------+
| soft-state |       | soft-state |   5   | replicated    |
| client (cB)+------>+ server (sB)|<------+ database (DBb)|
+------------+   4   +------------+       +---------------+

Now, say that the client cA "1" requests a service from server sA
resulting in that a soft-state is created in this server. Server sA
replies to the request in parallel with "2" storing the state in its
database DBa, whereafter this database "3" replicates the state to
database DBb. After cA receives the reply sA however craches and
subsequent requests of this client will therefore go to sB (e.g.
automatically selected through SCTP multihoming or gratuitous ARP for IP
takeover). The change of server is transparant to the client.

The state established by client cA may not have been written to database
DBa before server sA crached. In case it was not written the state would
not have been replicated to DBb either. Alternatively, the state may
have been written to DBa, but not replicated to DBb. This means that
when sB receives "4" a request from cB (which may has had sB as its
primary server since before or also has switched from sA because it
chrached) and uses the "5" obtained set of states from DBb, which is
inaccurate. Consequently, sB will produce the wrong answer to cB. E.g.
in case of RACS accept (or deny) a reservation request because it didn't
know that the requested resources are already booked (or released) by
cA.

The state is indeed soft and client cA will hence eventually learn that
it's no longer valid. Client cA will however believe the state to be
valid for a period up to the timer value, which can be several hundereds
of seconds. E.g. in case of reservations for telephony the mean holding
time for calls can be in the order of 300 seconds and setting the timer
to this value make sence since that keeps the signaling traffic for
updates sufficiently low.

An optimization of this use case using auditing is to have server sB ask
its clients for lists of their respective active sessions (i.e. lists of
active sessions IDs). Such auditing request would be triggered by the
event of that sB learns that it has taken over clients from sA. Based on
these lists sB can determine of sessions it believes being active are
really terminated and identify active but unknown sessions. For sessions
being unknown to sB it can chose to either just wait until they expires,
or explicitly ask the clients for more information on those sessions
(i.e. in order to completely or partly re-create the missing states).
The benefit of auditing is in this use case the period for which sB
operates on inaccurate information can be reduced to a few seconds
instead of potentially several hundreds of seconds.

To summarize; the auditing mechanisms involved in this use case are (1)
request from server to client for all active sessions and (2) request
from server to client for all details known by the client on a specific
session.

Comments?

Best regards,
Ulf

-----Original Message-----
From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
Sent: den 1 januari 2007 13:06
To: Ulf Bodin; Tolga Asveren
Cc: dime@ietf.org
Subject: The Auditing Problem

Hi Ulf,
Hi Tolga,

I think that the discussion triggered by Tolga was quite helpful in
order to get a better understanding of the auditing work.

What I would like to see is a more detailed example scenario (possibly
with message flows). Tolga provided a scenario with a figure but it
needs to be enhanced when it comes to the "service logic functionality".

I think that this is important since there is a front-end and a back-end
part to the entire story. The TISPAN QoS scenario has been mentioned as
a potential customer of this work and it could be a nice example to see
how the failure cases happen and how state is requested and moved
around. I can imagine that there are a number of issues that need to be
discussed when we jump into the details.

I have also noticed that a number of terms are used without clearly
describing them. For example, there are a number of different failover
cases that need more description to ensure that we are on the same page.

Another example: What is the definition for "session leaking"?

Ciao
Hannes




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

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


End of DiME Digest, Vol 13, Issue 10
************************************

------=_Part_78797_3749369.1168972681555-- --===============0929030645== 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 --===============0929030645==-- From dime-bounces@ietf.org Tue Jan 16 14:30:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6u10-0002Aw-Rn; Tue, 16 Jan 2007 14:30:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6u0z-0002Ad-I8 for dime@ietf.org; Tue, 16 Jan 2007 14:30:37 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6u0y-0000Qo-2Y for dime@ietf.org; Tue, 16 Jan 2007 14:30: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 <0JBZ003W47IZ5Z@usaga01-in.huawei.com> for dime@ietf.org; Tue, 16 Jan 2007 11:30:35 -0800 (PST) Received: from huawei.com ([172.18.4.47]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JBZ00I1O7IX39@usaga01-in.huawei.com> for dime@ietf.org; Tue, 16 Jan 2007 11:30:35 -0800 (PST) Received: from N737011 (pool-71-112-126-182.sttlwa.dsl-w.verizon.net [71.112.126.182]) by usaml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JBZ00C5O80RAB@usaml03-in.huawei.com> for dime@ietf.org; Tue, 16 Jan 2007 11:41:20 -0800 (PST) Date: Tue, 16 Jan 2007 11:30:29 -0800 From: Madjid Nakhjiri Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Security In-reply-to: <200701151103.21533.julien.laganier@laposte.net> To: 'Julien Laganier' , dime@ietf.org Message-id: <002401c739a4$cb1f3bb0$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: Acc4jKgWrGvlEjx0QiuJq8VhM1PL1ABEmCdw X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 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 Julien, Unless you are looking for a formal threat analysis document, the attacks have been described several times on the mailing list. I am not against protocol decoupling, I am against complete state-decoupling. I think the email you are referring to (your own) debates whether the issue is with accounting or with authorization when a decoupling happens. There is a little bit of difference in threats for authorization versus accounting. Many authorization frameworks, don't separate authorization from authentication. Immediately following an authentication, the AAA server also authorizes for services for the same authenticated peer, assuming the resources are available. The solution being presented here is saying lets authorize the peer through a separate signaling exchange and without proof of prior authentication. Essentially decoupling the first A of AAA from the other two AAs, causes spoofing problems, since the network is relying on an intermediary (HA) that (1) initially has not been part of the authentication and (2) later can be compromised to request authorization for an unauthenticated peer. Since the authorization is separated from authentication, this means the authorization signaling requires a separate trigger. I am saying the trigger needs to come from the peer itself with a proof of identity and message integrity. The HA should simply relay this message to the AAA server. Not that the HA starts an authorization request on its own for an arbitrary peer. This just sounds like a perfect DoS attack. The prevention does not require a huge overhead, since the peer is already doing EAP and thus has shared keys with the AAA servers and can easily sign follow-up authorization messages. We just have to make sure we have a trigger from the peer in the bootstrapping process. The accounting signaling on the other hand is different. Accounting happens without intervention of the peer and is between AAA client and AAA server. The accounting needs to use whatever security mechanism available for accounting framework. That is a AAA problem. The AAA server and AAA client need to have mechanisms to protect against false accounting and that is beyond scope of this work. In summary, by decoupling authorization and authentication we ARE adding threats to the existing network (by allowing a compromised AAA client to request authorization for unauthenticated peer). But accounting is typically decoupled from authentication anyway and we are not adding any new threats to the existing accounting framework. Hope this clarifies, Madjid -----Original Message----- From: julien laganier [mailto:julien.laganier@gmail.com] On Behalf Of Julien Laganier Sent: Monday, January 15, 2007 2:03 AM To: dime@ietf.org; Madjid Nakhjiri Cc: 'Julien Bournelle'; 'Hannes Tschofenig' Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Security On Friday 12 January 2007 19:33, Madjid Nakhjiri wrote: > Hi Julien, Hi Madjid, > While I appreciate the threat analysis here, the > problem is pretty easy to solve. Unless, we want to > leave this vulnerability as something only for the > security consideration, I suggest we add the > security measure. Solving the problem implies that we understand it. I am still not convinced that separation of authentication and authorization does indeed introduce a new vulnerability -- see my other note on the subject: http://www1.ietf.org/mail-archive/web/dime/current/msg01178.html Until we determine what are the threats and attacks, and determine whether each of them does represent a sufficiently important risk which deserve a countermeasure, I really think it is premature to devise solutions. Best, --julien > I am working on a draft that shows how you can > separate authentication and authorization while > binding the two together. The draft will be > submitted soon (or at least before next IETF > deadline). There is one problem remaining and that > is I am wondering about the messaging triggers (see > below). If people like the solution we can use it > for the WG draft. It is just hard to show a solution > over ML, sorry. > > For now, I say, we can use the EAP method to > generate MSK/EMSK and then use those keys in > assurance for previous authentication (Diameter EAP) > to the authorization server for Diameter MIP. > The issue is that based on the threat analysis that > you provided, we cannot trust HA to provide this > assurance. It has to come from the peer and/or AAA > server. > One way would be for the peer to generate the key > sign its request with this key. Without getting into > the details right now, the issue would be: What > message would carry this signature from the peer? > And this is why I have been asking the question of > what message would trigger the Mobile IP > Authorization (MAR) message and what is the timing > of MAR/MAA w.r.t IKEv2. > > The problem is that we need to perform all Mobile IP > bootstrapping after MAA, i.e. after the MN is > actually authorized for Mobile IP, so if there is > any message (even an IKEv2 message) that carries a > Mobile IP parameter, it has to come after MAA. > > Hope I am making sense, > > Madjid _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jan 16 17:09:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6wUI-0005i5-CI; Tue, 16 Jan 2007 17:09:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6wUE-0005hy-J4 for dime@ietf.org; Tue, 16 Jan 2007 17:08:58 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6wUC-00007Q-BB for dime@ietf.org; Tue, 16 Jan 2007 17:08:58 -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 FA0381498A for ; Tue, 16 Jan 2007 17:08:56 -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 l0GM8sb5009276 for ; Tue, 16 Jan 2007 17:08:54 -0500 (EST) From: "Tolga Asveren" To: Date: Tue, 16 Jan 2007 17:04:46 -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) Importance: Normal In-Reply-To: <33656995C5C5094A983DE84DA649A924EB0CE9@lulex02.ad.operax.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [Dime] The Auditing Problem: Soft v.s. Hard States 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 Ulf, Please see below for some comments/questions. I will try to reply in multiple messages (and change the subject line), so that it is easier to track different issues. Thanks, Tolga > -----Original Message----- > From: Ulf Bodin [mailto:Ulf.Bodin@operax.com] > Sent: Tuesday, January 16, 2007 7:06 AM > To: dime@ietf.org > Subject: [Dime] RE: The Auditing Problem > > > Folks, > > Following Hannes advice I've put together a first proposal for more > detailed example scenarios/use cases. > > Before going into those use cases I just want to remind of the earlier > discussion on applicability by repeating my opinion of that a good > design approach would be to for a new application first explore if > soft-state without auditing is sufficient before considering designing > for auditing (in case we manage to specify a solution for auditing that > is :-). Such an apporach is in my view beneficial since auditing adds > complexity and creates excess signaling traffic (potentially at times > when additional signaling load should be avoided). [TOLGA]Just to make sure that I have the correct understanding of soft v.s. hard states: I guess we have the soft state if both of the following are present: a) The protocol dictates periodic requests, e.g. a timer is running on the client, where after expiry of it, client generates a request. b) A timer is running on the server and server drops the session if the timer expires before another requests is received for the session. IMHO, that type of timers are always necessary (regardless of the presence/absence of an auditing mechanism), because: i) Client and server may not have a direct Diameter connection where one isn't able to detect failure of the client by base protocol procedures, e.g. watchdog mechanism. ii) There is no gurantee that a backup node will be present to run auditing type of procedures to clean up the session on the peer. In such a case, client may sit indefinetly with the assumption everything is fine (or till the entity, which actually requested the service complains about it). This approach seems risky to me. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jan 16 17:32:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6wr8-0001mM-3v; Tue, 16 Jan 2007 17:32:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6wr6-0001mH-H8 for dime@ietf.org; Tue, 16 Jan 2007 17:32:36 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6wr5-00052V-A4 for dime@ietf.org; Tue, 16 Jan 2007 17:32:36 -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 38E688C14F for ; Tue, 16 Jan 2007 17:32:28 -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 l0GMWSj8010410 for ; Tue, 16 Jan 2007 17:32:28 -0500 (EST) From: "Tolga Asveren" To: Date: Tue, 16 Jan 2007 17:28:20 -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) Importance: Normal In-Reply-To: <33656995C5C5094A983DE84DA649A924EB0CE9@lulex02.ad.operax.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Dime] The Auditing Problem : Selection of the backup 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 Ulf, > +------------+ 1 +------------+ 2 +---------------+ > | soft-state +------>+ soft-state +------>+ replicated | > | client (cA)+ | server (sA)| | database (DBa)| > +------------+ +------------+ +------+--------+ > 3 | > v > +------------+ +------------+ +---------------+ > | soft-state | | soft-state | 5 | replicated | > | client (cB)+------>+ server (sB)|<------+ database (DBb)| > +------------+ 4 +------------+ +---------------+ > > Now, say that the client cA "1" requests a service from server sA > resulting in that a soft-state is created in this server. Server sA > replies to the request in parallel with "2" storing the state in its > database DBa, whereafter this database "3" replicates the state to > database DBb. After cA receives the reply sA however craches and > subsequent requests of this client will therefore go to sB (e.g. > automatically selected through SCTP multihoming or gratuitous ARP for IP > takeover). The change of server is transparant to the client. [TOLGA] This is probably a side issue for auditing but IMHO still an important one for the whole failover concept in Diameter: a) Unless one comes up with a SCTP implementation distributed over multiple hosts (which probably is not practical to implement), SCTP multihoming won't provide a seamless failover during host failures. b) Similarly IP takeover will cause the TCP/SCTP connection to be dropped, unless one can synchronize TCP/SCTP state variables among different hosts. Again, loss of TCP/SCTP connection will be visible to the application. IMHO, the proper way of handling Diameter failovers after server crashes is that the request is retried with an alternate server identity. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jan 16 17:59:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6xHD-0003FZ-Qj; Tue, 16 Jan 2007 17:59:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6xHC-0003FH-Iz for dime@ietf.org; Tue, 16 Jan 2007 17:59:34 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6xHB-0002LQ-Ae for dime@ietf.org; Tue, 16 Jan 2007 17:59:34 -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 D113F7A7DA for ; Tue, 16 Jan 2007 17:59:29 -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 l0GMxSjW011581 for ; Tue, 16 Jan 2007 17:59:28 -0500 (EST) From: "Tolga Asveren" To: Date: Tue, 16 Jan 2007 17:55:20 -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) Importance: Normal In-Reply-To: <33656995C5C5094A983DE84DA649A924EB0CE9@lulex02.ad.operax.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [Dime] The Auditing Problem: General Concerns 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 Ulf, > -----Original Message----- > From: Ulf Bodin [mailto:Ulf.Bodin@operax.com] > Sent: Tuesday, January 16, 2007 7:06 AM > To: dime@ietf.org > Subject: [Dime] RE: The Auditing Problem > > > Folks, > > Following Hannes advice I've put together a first proposal for more > detailed example scenarios/use cases. > > Before going into those use cases I just want to remind of the earlier > discussion on applicability by repeating my opinion of that a good > design approach would be to for a new application first explore if > soft-state without auditing is sufficient before considering designing > for auditing (in case we manage to specify a solution for auditing that > is :-). Such an apporach is in my view beneficial since auditing adds > complexity and creates excess signaling traffic (potentially at times > when additional signaling load should be avoided). [TOLGA] Recovery after failovers is definitly an interesting problem and may or may not require some heavier than lightweight solution. In general my concerns for auditing type of functionality are: a)It seems to expect too much from the peer to succeed for recovery. One could argue that this is what protocols are for but maybe there is a difference between necesary communication to provide services and communication to aide for local recovery. Usually, operators don't like to have much dependency between entities, especially if the entity they rely for recovery is controlled by some other organization. Of course, this is open to argument (like any statement with subjective words like "much"), but just an observation. Maybe that level of interaction is unavoidable. b)It is not clear to me whether such a mechanism should be generic or per application. Here I am not talking about whether all applications have to use it but rather the mechanics of the procedure. Having said all of that, I am definitly for exploring this problem and hopefully coming up with a solution. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jan 17 04:34:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H77Bk-0002LT-Qy; Wed, 17 Jan 2007 04:34:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H77Bj-0002Kx-0o for dime@ietf.org; Wed, 17 Jan 2007 04:34:35 -0500 Received: from smtp.operax.com ([213.50.74.226] helo=smtp-dmz.operax.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H77Bh-0001FQ-De for dime@ietf.org; Wed, 17 Jan 2007 04:34:35 -0500 Received: from lulex02.ad.operax.com (ad.operax.com [192.168.2.13]) by smtp-dmz.operax.com (8.13.1/8.13.1) with ESMTP id l0H9YQHR084348 for ; Wed, 17 Jan 2007 10:34:26 +0100 (CET) (envelope-from Ulf.Bodin@operax.com) 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] The Auditing Problem: Soft v.s. Hard States Date: Wed, 17 Jan 2007 10:34:28 +0100 Message-ID: <33656995C5C5094A983DE84DA649A924EB0EBC@lulex02.ad.operax.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] The Auditing Problem: Soft v.s. Hard States Thread-Index: Acc5uwQ59RU4zqfkRDOUiXBr43wOlQASQ0Dg From: "Ulf Bodin" To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (smtp-dmz.operax.com [172.16.1.4]); Wed, 17 Jan 2007 10:34:26 +0100 (CET) X-Spam-Status: No, score=-52.6 required=4.7 tests=ALL_TRUSTED,BAYES_00, USER_IN_BLACKLIST autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on smtp-dmz.operax.com X-Virus-Scanned: ClamAV 0.88.7/2459/Tue Jan 16 23:03:34 2007 on smtp-dmz.operax.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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,=20 My replies below; [Ulf].=20 Best regards,=20 Ulf=20 > > Folks, > > Following Hannes advice I've put together a first proposal for more=20 > detailed example scenarios/use cases. > > Before going into those use cases I just want to remind of the earlier > discussion on applicability by repeating my opinion of that a good=20 > design approach would be to for a new application first explore if=20 > soft-state without auditing is sufficient before considering designing > for auditing (in case we manage to specify a solution for auditing=20 > that is :-). Such an apporach is in my view beneficial since auditing=20 > adds complexity and creates excess signaling traffic (potentially at=20 > times when additional signaling load should be avoided). [TOLGA]Just to make sure that I have the correct understanding of soft v.s. hard states: I guess we have the soft state if both of the following are present: a) The protocol dictates periodic requests, e.g. a timer is running on the client, where after expiry of it, client generates a request. b) A timer is running on the server and server drops the session if the timer expires before another requests is received for the session. [Ulf] Yes. I'm thinking of using the existing AVPs for soft-state as they're defined. I.e. the Authorization-Lifetime AVP, which to my understanding relates to the time of the client timer setting and the Auth-Grace-Period AVP, which is the additional time used for the server timer setting.=20 IMHO, that type of timers are always necessary (regardless of the presence/absence of an auditing mechanism), because: i) Client and server may not have a direct Diameter connection where one isn't able to detect failure of the client by base protocol procedures, e.g. watchdog mechanism. ii) There is no gurantee that a backup node will be present to run auditing type of procedures to clean up the session on the peer. In such a case, client may sit indefinetly with the assumption everything is fine (or till the entity, which actually requested the service complains about it). This approach seems risky to me. [Ulf] Indefinite Diameter states may indeed not be the legacy we want to leave our children :-). I completely agree that timers are needed also for hard-state. I'm not sure such timers should be visible in the protocol though. This is because a would prefer having the timers triggered at loss of connectivity instead of having them initiated by a Diameter message.=20 I picture that the death of a server (or client) may need to be confirmed by other means than timers only. E.g. say that a server died and that the client fails to connect to its hot backup (because it's dead as well). However, as the fault management system detects this event operational people may decide to boot a new device and have it take over as a cold backup. When coming up this server will audit the client when it connects.=20 Indeed, also in this scenario a timer needs to be present in the client in case this procedure fails in its entire. This timer may be set to a number of minutes or even an hour or so and could be started at the event of loss of connectivity to the primary server (i.e. if a backup server has not been brought up within this time all states will be removed in the affected clients). I'm not an expert on COPS, but I believe it implements such timers (should look before saying that, but I hope you take it for what it is: more or less a guess :-)).=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 Jan 17 05:17:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H77qp-0007te-FE; Wed, 17 Jan 2007 05:17:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H77qo-0007tZ-3Q for dime@ietf.org; Wed, 17 Jan 2007 05:17:02 -0500 Received: from smtp.operax.com ([213.50.74.226] helo=smtp-dmz.operax.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H77qm-0001oZ-I1 for dime@ietf.org; Wed, 17 Jan 2007 05:17:02 -0500 Received: from lulex02.ad.operax.com (ad.operax.com [192.168.2.13]) by smtp-dmz.operax.com (8.13.1/8.13.1) with ESMTP id l0HAGrQ6084792 for ; Wed, 17 Jan 2007 11:16:54 +0100 (CET) (envelope-from Ulf.Bodin@operax.com) 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] The Auditing Problem : Selection of the backup Date: Wed, 17 Jan 2007 11:16:56 +0100 Message-ID: <33656995C5C5094A983DE84DA649A924EB0ED3@lulex02.ad.operax.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] The Auditing Problem : Selection of the backup Thread-Index: Acc5vlcsTlBiGOnERYmPE4zzPrCsPAAXGHGQ From: "Ulf Bodin" To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (smtp-dmz.operax.com [172.16.1.4]); Wed, 17 Jan 2007 11:16:54 +0100 (CET) X-Spam-Status: No, score=-52.6 required=4.7 tests=ALL_TRUSTED,BAYES_00, USER_IN_BLACKLIST autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on smtp-dmz.operax.com X-Virus-Scanned: ClamAV 0.88.7/2459/Tue Jan 16 23:03:34 2007 on smtp-dmz.operax.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 Again, replies below [Ulf].=20 Best regards,=20 Ulf=20 -----Original Message----- From: Tolga Asveren [mailto:asveren@ulticom.com]=20 Sent: den 16 januari 2007 23:28 To: dime@ietf.org Subject: [Dime] The Auditing Problem : Selection of the backup Hi Ulf, > +------------+ 1 +------------+ 2 +---------------+ > | soft-state +------>+ soft-state +------>+ replicated | > | client (cA)+ | server (sA)| | database (DBa)| > +------------+ +------------+ +------+--------+ > 3 | > v > +------------+ +------------+ +---------------+ > | soft-state | | soft-state | 5 | replicated | > | client (cB)+------>+ server (sB)|<------+ database (DBb)| > +------------+ 4 +------------+ +---------------+ > > Now, say that the client cA "1" requests a service from server sA=20 > resulting in that a soft-state is created in this server. Server sA=20 > replies to the request in parallel with "2" storing the state in its=20 > database DBa, whereafter this database "3" replicates the state to=20 > database DBb. After cA receives the reply sA however craches and=20 > subsequent requests of this client will therefore go to sB (e.g. > automatically selected through SCTP multihoming or gratuitous ARP for=20 > IP takeover). The change of server is transparant to the client. [TOLGA] This is probably a side issue for auditing but IMHO still an important one for the whole failover concept in Diameter: a) Unless one comes up with a SCTP implementation distributed over multiple hosts (which probably is not practical to implement), SCTP multihoming won't provide a seamless failover during host failures. b) Similarly IP takeover will cause the TCP/SCTP connection to be dropped, unless one can synchronize TCP/SCTP state variables among different hosts. Again, loss of TCP/SCTP connection will be visible to the application. [Ulf] You're right of course. Loss of connectivity is certainly visible to the client and the failover os thus not completely transparent. I ment that the failover would be transparent to the client in the sense that the application service should not be affected. A wird and inadequate way of saing that referring to tranparency though.=20 IMHO, the proper way of handling Diameter failovers after server crashes is that the request is retried with an alternate server identity. [Ulf] Yes, that is fine when failing over to a backup server. However, when using SCTP multihoming for path failover the SCTP stack can transparntly reconnect to the same server but using an IP address different from the one used when the connection broke. That is, two alternative paths are configured through the network between client and server. As I see it, having the client retry with a different server identity is mainly an alternative to IP takeover.=20 In case IP takover is not to be used at all maybe failover to a backup server could be implemented either with alternative server identities in the application or using SCTP multihoming. To be honest, I don't know why either one of those approaches would be better then the other one.=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 Jan 17 05:35:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H788H-0000hC-Dh; Wed, 17 Jan 2007 05:35:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H788G-0000gz-2L for dime@ietf.org; Wed, 17 Jan 2007 05:35:04 -0500 Received: from smtp.operax.com ([213.50.74.226] helo=smtp-dmz.operax.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H788E-0005mE-H2 for dime@ietf.org; Wed, 17 Jan 2007 05:35:04 -0500 Received: from lulex02.ad.operax.com (ad.operax.com [192.168.2.13]) by smtp-dmz.operax.com (8.13.1/8.13.1) with ESMTP id l0HAYtfH084917 for ; Wed, 17 Jan 2007 11:34:56 +0100 (CET) (envelope-from Ulf.Bodin@operax.com) 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] The Auditing Problem: General Concerns Date: Wed, 17 Jan 2007 11:34:57 +0100 Message-ID: <33656995C5C5094A983DE84DA649A924EB0EDD@lulex02.ad.operax.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] The Auditing Problem: General Concerns Thread-Index: Acc5wiDr9Ro4fbJRTDyjrMoiZ6evwAAXoQhA From: "Ulf Bodin" To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (smtp-dmz.operax.com [172.16.1.4]); Wed, 17 Jan 2007 11:34:56 +0100 (CET) X-Spam-Status: No, score=-52.6 required=4.7 tests=ALL_TRUSTED,BAYES_00, USER_IN_BLACKLIST autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on smtp-dmz.operax.com X-Virus-Scanned: ClamAV 0.88.7/2459/Tue Jan 16 23:03:34 2007 on smtp-dmz.operax.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 Replies below [Ulf].=20 Best regards,=20 Ulf=20 -----Original Message----- From: Tolga Asveren [mailto:asveren@ulticom.com]=20 Sent: den 16 januari 2007 23:55 To: dime@ietf.org Subject: [Dime] The Auditing Problem: General Concerns Hi Ulf, > -----Original Message----- > From: Ulf Bodin [mailto:Ulf.Bodin@operax.com] > Sent: Tuesday, January 16, 2007 7:06 AM > To: dime@ietf.org > Subject: [Dime] RE: The Auditing Problem > > > Folks, > > Following Hannes advice I've put together a first proposal for more=20 > detailed example scenarios/use cases. > > Before going into those use cases I just want to remind of the earlier > discussion on applicability by repeating my opinion of that a good=20 > design approach would be to for a new application first explore if=20 > soft-state without auditing is sufficient before considering designing > for auditing (in case we manage to specify a solution for auditing=20 > that is :-). Such an apporach is in my view beneficial since auditing=20 > adds complexity and creates excess signaling traffic (potentially at=20 > times when additional signaling load should be avoided). [TOLGA] Recovery after failovers is definitly an interesting problem and may or may not require some heavier than lightweight solution. In general my concerns for auditing type of functionality are: a)It seems to expect too much from the peer to succeed for recovery. One could argue that this is what protocols are for but maybe there is a difference between necesary communication to provide services and communication to aide for local recovery. Usually, operators don't like to have much dependency between entities, especially if the entity they rely for recovery is controlled by some other organization. Of course, this is open to argument (like any statement with subjective words like "much"), but just an observation. Maybe that level of interaction is unavoidable. [Ulf: I agree that dependency between entities is something that introduce risk and may reduce system reliability as such. I believe that this is important to have in mind when looking into mechanisms for auditing. In particular, system reliability should (must) not be put at risk by the use of auditing. Having said that I think we need to see (and design) auditing mechanisms as something to use for optimization rather than to ensure correct functioning of a system. Your notes on that timers are needed also for hard-states is a good example following that observation I think. =20 b)It is not clear to me whether such a mechanism should be generic or per application. Here I am not talking about whether all applications have to use it but rather the mechanics of the procedure. [Ulf: In my view support for auditing can be deveoped per application, but I also believe a generic mechanism fitting most if not all applications that need auditing is within reach (i.e. I think the Calhoun draft on the topic is already quite close). IMHO, a generic mechanism is preferable to avoid people doing different solutions and potentially make different (or the same) misstakes :-}.=20 Having said all of that, I am definitly for exploring this problem and hopefully coming up with a solution. _______________________________________________ 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 Jan 17 11:43:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7DsH-0001Jm-Bw; Wed, 17 Jan 2007 11:42:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7DsG-0001Ja-Bx for dime@ietf.org; Wed, 17 Jan 2007 11:42:56 -0500 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7DsC-0004Ey-IM for dime@ietf.org; Wed, 17 Jan 2007 11:42:56 -0500 Received: by ug-out-1314.google.com with SMTP id 72so1842086ugd for ; Wed, 17 Jan 2007 08:42:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=YrBOVJAxM2aVcMQqwOrfU8TKi0SEFNZVE+B0H1L4cQjkja4LQWHoajWdu1YDKAI0gRf2rfE8I4o5FKJeMF5lBXkmYiYtP3pUNy8XtykqS+goUtlgn9lf2oKp+iv+SLgfTMYpsWH2Cb0txjmbFK6oFR/S6ry8aFzRZygLzt6ENsA= Received: by 10.67.117.18 with SMTP id u18mr9755785ugm.1169052170897; Wed, 17 Jan 2007 08:42:50 -0800 (PST) Received: from ?192.168.1.110? ( [212.119.9.178]) by mx.google.com with ESMTP id j34sm8750421ugc.2007.01.17.08.42.49; Wed, 17 Jan 2007 08:42:49 -0800 (PST) From: Julien Laganier To: dime@ietf.org Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Security Date: Wed, 17 Jan 2007 17:40:03 +0100 User-Agent: KMail/1.8.2 References: <002401c739a4$cb1f3bb0$2f01a8c0@china.huawei.com> In-Reply-To: <002401c739a4$cb1f3bb0$2f01a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701171740.03961.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 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, Thanks for your reply. No I am not looking for a formal threat analysis document. I am rather looking to understand what are the threat, and which attacks derive from them. As I wrote in a previous note I disagree it is of value to block an attack in which a compromised HA presents fake identities to a mobility authorization server. If the HA is compromised it can just furnish the mobility service to anyone it wants; it doesn't need to lie to the authorization server as I described in a previous note, quoted below (sorry to repeat myself): When separate authentication and authorization are used and the HA is compromised (by Mallory), it is possible that the HA submit the identity of another user (Alice) to the authorization server, have this other user (Alice) be authorized by the authorization server, although the user that will be provided with the service is different (e.g. Mallory, or whoever else.) That is, the HA cannot render a unauthenticated user *authorized*, but rather provide it with the service in spite of the user being unauthorized. Binding authentication and authorization together doesn't prevent a compromised HA to provide the service to *anyone* in spite of a particular instance of this anyone not being authenticated or/neither authorized. In other words, the attack I've seen described doesn't IMHO represent a threat since someone who managed to compromise the HA can anyway provide mobility service to any unauthenticated and/or unauthorized user. Am I missing something? --julien On Tuesday 16 January 2007 20:30, Madjid Nakhjiri wrote: > Hi Julien, > > Unless you are looking for a formal threat analysis > document, the attacks have been described several > times on the mailing list. > > I am not against protocol decoupling, I am against > complete state-decoupling. > > I think the email you are referring to (your own) > debates whether the issue is with accounting or with > authorization when a decoupling happens. There is a > little bit of difference in threats for > authorization versus accounting. Many authorization > frameworks, don't separate authorization from > authentication. Immediately following an > authentication, the AAA server also authorizes for > services for the same authenticated peer, assuming > the resources are available. > > The solution being presented here is saying lets > authorize the peer through a separate signaling > exchange and without proof of prior authentication. > Essentially decoupling the first A of AAA from the > other two AAs, causes spoofing problems, since the > network is relying on an intermediary (HA) that (1) > initially has not been part of the authentication > and (2) later can be compromised to request > authorization for an unauthenticated peer. > > Since the authorization is separated from > authentication, this means the authorization > signaling requires a separate trigger. I am saying > the trigger needs to come from the peer itself with > a proof of identity and message integrity. The HA > should simply relay this message to the AAA server. > Not that the HA starts an authorization request on > its own for an arbitrary peer. This just sounds like > a perfect DoS attack. The prevention does not > require a huge overhead, since the peer is already > doing EAP and thus has shared keys with the AAA > servers and can easily sign follow-up authorization > messages. We just have to make sure we have a > trigger from the peer in the bootstrapping process. > > The accounting signaling on the other hand is > different. Accounting happens without intervention > of the peer and is between AAA client and AAA > server. The accounting needs to use whatever > security mechanism available for accounting > framework. That is a AAA problem. The AAA server and > AAA client need to have mechanisms to protect > against false accounting and that is beyond scope of > this work. > > In summary, by decoupling authorization and > authentication we ARE adding threats to the existing > network (by allowing a compromised AAA client to > request authorization for unauthenticated peer). But > accounting is typically decoupled from > authentication anyway and we are not adding any new > threats to the existing accounting framework. > > Hope this clarifies, > > Madjid > > > > > > -----Original Message----- > From: julien laganier > [mailto:julien.laganier@gmail.com] On Behalf Of > Julien Laganier > Sent: Monday, January 15, 2007 2:03 AM > To: dime@ietf.org; Madjid Nakhjiri > Cc: 'Julien Bournelle'; 'Hannes Tschofenig' > Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH > Support: Security > > On Friday 12 January 2007 19:33, Madjid Nakhjiri wrote: > > Hi Julien, > > Hi Madjid, > > > While I appreciate the threat analysis here, the > > problem is pretty easy to solve. Unless, we want > > to leave this vulnerability as something only for > > the security consideration, I suggest we add the > > security measure. > > Solving the problem implies that we understand it. > > I am still not convinced that separation of > authentication and authorization does indeed > introduce a new vulnerability -- see my other note > on the subject: > > http://www1.ietf.org/mail-archive/web/dime/current/m >sg01178.html > > Until we determine what are the threats and attacks, > and determine whether each of them does represent a > sufficiently important risk which deserve a > countermeasure, I really think it is premature to > devise solutions. > > Best, > > --julien > > > I am working on a draft that shows how you can > > separate authentication and authorization while > > binding the two together. The draft will be > > submitted soon (or at least before next IETF > > deadline). There is one problem remaining and that > > is I am wondering about the messaging triggers > > (see below). If people like the solution we can > > use it for the WG draft. It is just hard to show a > > solution over ML, sorry. > > > > For now, I say, we can use the EAP method to > > generate MSK/EMSK and then use those keys in > > assurance for previous authentication (Diameter > > EAP) to the authorization server for Diameter MIP. > > The issue is that based on the threat analysis > > that you provided, we cannot trust HA to provide > > this assurance. It has to come from the peer > > and/or AAA server. > > One way would be for the peer to generate the key > > sign its request with this key. Without getting > > into the details right now, the issue would be: > > What message would carry this signature from the > > peer? And this is why I have been asking the > > question of what message would trigger the Mobile > > IP > > Authorization (MAR) message and what is the timing > > of MAR/MAA w.r.t IKEv2. > > > > The problem is that we need to perform all Mobile > > IP bootstrapping after MAA, i.e. after the MN is > > actually authorized for Mobile IP, so if there is > > any message (even an IKEv2 message) that carries a > > Mobile IP parameter, it has to come after MAA. > > > > Hope I am making sense, > > > > Madjid > > _______________________________________________ > 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 Jan 17 17:24:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7JCw-000454-RB; Wed, 17 Jan 2007 17:24:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7JCu-00044z-MC for dime@ietf.org; Wed, 17 Jan 2007 17:24:36 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7JCg-0006T8-UE for dime@ietf.org; Wed, 17 Jan 2007 17:24:36 -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 B659E07A60 for ; Wed, 17 Jan 2007 17:24:16 -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 l0HMOFjF022104 for ; Wed, 17 Jan 2007 17:24:15 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] The Auditing Problem: Soft v.s. Hard States Date: Wed, 17 Jan 2007 17:20:00 -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) Importance: Normal In-Reply-To: <33656995C5C5094A983DE84DA649A924EB0EBC@lulex02.ad.operax.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 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 Ulf, Please see for comments/questions below. Thanks, Tolga > [TOLGA]Just to make sure that I have the correct understanding of soft > v.s. > hard states: I guess we have the soft state if both of the following are > present: > a) The protocol dictates periodic requests, e.g. a timer is running on > the client, where after expiry of it, client generates a request. > b) A timer is running on the server and server drops the session if the > timer expires before another requests is received for the session. > > [Ulf] Yes. I'm thinking of using the existing AVPs for soft-state as > they're defined. I.e. the Authorization-Lifetime AVP, which to my > understanding relates to the time of the client timer setting and the > Auth-Grace-Period AVP, which is the additional time used for the server > timer setting. [TOLGA]One dummy question about hard-state case, let's assume the following abstract configuration: Requester for the Resource Middleman Resources <--Diameter-------> <--XYZ---> <------Resource usage------------> relationship If I (as the requeser) want the resource to be available, until I explicitly indicate that I don't want to use it anymore, what is bad if the Middleman dies? Let's say the requester wants to release the resource, sends the corresponding request to the middleman it used when requesting the resources. It gets back an error answer "UNABLE_TO_DELIVER" and can try with another middleman. The "new" middleman would release the resources. Here I assume that the middleman is stateless or able to reconstruct the state based on the content of the release message and some additional queries on some other entities but I guess this is not unrealistic with careful protocol design (as a negative example, if the release resources message contains only the Session-Id, it won't work) I guess the question is, why do I need to "resurrect" sessions on a "new" middleman in advance, if I can do it whenever I need the services of the middleman? > > IMHO, that type of timers are always necessary (regardless of the > presence/absence of an auditing mechanism), because: > i) Client and server may not have a direct Diameter connection where one > isn't able to detect failure of the client by base protocol procedures, > e.g. > watchdog mechanism. > ii) There is no gurantee that a backup node will be present to run > auditing type of procedures to clean up the session on the peer. > > In such a case, client may sit indefinetly with the assumption > everything is fine (or till the entity, which actually requested the > service complains about it). This approach seems risky to me. > > [Ulf] Indefinite Diameter states may indeed not be the legacy we want to > leave our children :-). I completely agree that timers are needed also > for hard-state. I'm not sure such timers should be visible in the > protocol though. This is because a would prefer having the timers > triggered at loss of connectivity instead of having them initiated by a > Diameter message. > > I picture that the death of a server (or client) may need to be > confirmed by other means than timers only. E.g. say that a server died > and that the client fails to connect to its hot backup (because it's > dead as well). However, as the fault management system detects this > event operational people may decide to boot a new device and have it > take over as a cold backup. When coming up this server will audit the > client when it connects. > > Indeed, also in this scenario a timer needs to be present in the client > in case this procedure fails in its entire. This timer may be set to a > number of minutes or even an hour or so and could be started at the > event of loss of connectivity to the primary server (i.e. if a backup > server has not been brought up within this time all states will be > removed in the affected clients). I'm not an expert on COPS, but I > believe it implements such timers (should look before saying that, but I > hope you take it for what it is: more or less a guess :-)). [TOLGA] I think if it is necessary to detect failure of servers from protocol machinery point of view, a protocol timer is required. Like you indicated, we can't assume that a certain type of configuration will be present on the peer side. With the possible presence of intermediaries, e.g. relay agents, there is also no straightforward way of determining crash of a server. Currently one may use an "UNABLE_TO_DELIVER" error answer for a subsequent request sent to a specific server as an indication that it went down/unreachable. Actually, maybe this is what we need, a message with which backups/cluster members can notify clients about failure of a particular server. I agree with you that to guard against local resource leaking, e.g. memory, one can use a local non-protocol timer, if a protocol timer is not available. Still, such a timer is also not without its worries if it is completely decoupled from protocol processing. It must run longer than the maximum expected life for a session, which could be quite a while for certain types of applications (but again this is an implementation issue) _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jan 17 17:34:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7JMt-0000TU-Qe; Wed, 17 Jan 2007 17:34:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7JMs-0000TP-SX for dime@ietf.org; Wed, 17 Jan 2007 17:34:54 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7JMr-0007bg-J4 for dime@ietf.org; Wed, 17 Jan 2007 17:34:54 -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 77C3B06B3A for ; Wed, 17 Jan 2007 17:34:49 -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 l0HMYmqJ022555 for ; Wed, 17 Jan 2007 17:34:48 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] The Auditing Problem : Selection of the backup Date: Wed, 17 Jan 2007 17:30:33 -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) Importance: Normal In-Reply-To: <33656995C5C5094A983DE84DA649A924EB0ED3@lulex02.ad.operax.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Ulf, Please see below for comments/questions. Thanks, Tolga > -----Original Message----- > From: Ulf Bodin [mailto:Ulf.Bodin@operax.com] > Sent: Wednesday, January 17, 2007 5:17 AM > To: dime@ietf.org > Subject: RE: [Dime] The Auditing Problem : Selection of the backup > > > Again, replies below [Ulf]. > Best regards, > Ulf > > -----Original Message----- > From: Tolga Asveren [mailto:asveren@ulticom.com] > Sent: den 16 januari 2007 23:28 > To: dime@ietf.org > Subject: [Dime] The Auditing Problem : Selection of the backup > > Hi Ulf, > > > +------------+ 1 +------------+ 2 +---------------+ > > | soft-state +------>+ soft-state +------>+ replicated | > > | client (cA)+ | server (sA)| | database (DBa)| > > +------------+ +------------+ +------+--------+ > > 3 | > > v > > +------------+ +------------+ +---------------+ > > | soft-state | | soft-state | 5 | replicated | > > | client (cB)+------>+ server (sB)|<------+ database (DBb)| > > +------------+ 4 +------------+ +---------------+ > > > > Now, say that the client cA "1" requests a service from server sA > > resulting in that a soft-state is created in this server. Server sA > > replies to the request in parallel with "2" storing the state in its > > database DBa, whereafter this database "3" replicates the state to > > database DBb. After cA receives the reply sA however craches and > > subsequent requests of this client will therefore go to sB (e.g. > > automatically selected through SCTP multihoming or gratuitous ARP for > > IP takeover). The change of server is transparant to the client. > [TOLGA] This is probably a side issue for auditing but IMHO still an > important one for the whole failover concept in Diameter: > a) Unless one comes up with a SCTP implementation distributed over > multiple hosts (which probably is not practical to implement), SCTP > multihoming won't provide a seamless failover during host failures. > b) Similarly IP takeover will cause the TCP/SCTP connection to be > dropped, unless one can synchronize TCP/SCTP state variables among > different hosts. > Again, loss of TCP/SCTP connection will be visible to the application. > > [Ulf] You're right of course. Loss of connectivity is certainly visible > to the client and the failover os thus not completely transparent. I > ment that the failover would be transparent to the client in the sense > that the application service should not be affected. A wird and > inadequate way of saing that referring to tranparency though. > > IMHO, the proper way of handling Diameter failovers after server crashes > is that the request is retried with an alternate server identity. > > [Ulf] Yes, that is fine when failing over to a backup server. However, > when using SCTP multihoming for path failover the SCTP stack can > transparntly reconnect to the same server but using an IP address > different from the one used when the connection broke. That is, two > alternative paths are configured through the network between client and > server. As I see it, having the client retry with a different server > identity is mainly an alternative to IP takeover. [TOLGA]Yes, SCTP provides network/NIC redundancy. It is host failures where it doesn't help much. > > In case IP takover is not to be used at all maybe failover to a backup > server could be implemented either with alternative server identities in > the application or using SCTP multihoming. To be honest, I don't know > why either one of those approaches would be better then the other one. [TOLGA]I think IP failover is a dead end. Both TCP and SCTP are connection oriented protocols, which makes IP takeover approach non-seamless. The connection needs to be reestablished. For SCTP case, I guess I am missing something in what you describe. I don't see how multihoming could be helpfull when the host goes down. Regarding host failures, it is essentially the same as TCP, no redundancy :-) _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jan 17 18:20:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7K5L-0006J6-DW; Wed, 17 Jan 2007 18:20:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7K5K-0006Ct-7I for dime@ietf.org; Wed, 17 Jan 2007 18:20:50 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7K5I-0004vm-UQ for dime@ietf.org; Wed, 17 Jan 2007 18:20:50 -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 8DAD512F74 for ; Wed, 17 Jan 2007 18:20:44 -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 l0HNKhrQ025017 for ; Wed, 17 Jan 2007 18:20:44 -0500 (EST) From: "Tolga Asveren" To: Date: Wed, 17 Jan 2007 18:16:28 -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) Importance: Normal In-Reply-To: <33656995C5C5094A983DE84DA649A924EB0CE9@lulex02.ad.operax.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Subject: [Dime] The Auditing Problem: Possible approaches 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 Ulf, Please see below for comments/questions. Thanks, Tolga > An optimization of this use case using auditing is to have server sB ask > its clients for lists of their respective active sessions (i.e. lists of > active sessions IDs). Such auditing request would be triggered by the > event of that sB learns that it has taken over clients from sA. Based on > these lists sB can determine of sessions it believes being active are > really terminated and identify active but unknown sessions. For sessions > being unknown to sB it can chose to either just wait until they expires, > or explicitly ask the clients for more information on those sessions > (i.e. in order to completely or partly re-create the missing states). > The benefit of auditing is in this use case the period for which sB > operates on inaccurate information can be reduced to a few seconds > instead of potentially several hundreds of seconds. > > To summarize; the auditing mechanisms involved in this use case are (1) > request from server to client for all active sessions and (2) request > from server to client for all details known by the client on a specific > session. [TOLGA] I will skip the local/implementation dependent solution, afterall it is not what we are trying to standardize but I guess also in that domain we have quite a few different approaches which have been used in telecom industry with more or less success in many years. In terms of protocol aided solution, initially I can think of the following list (they may or may not make sense for particular applications and I am not claiming it is a full list :-)): i- Client triggered refresh upon expiry of a timer on the client This is essentially the soft state case, where the client can send a message to an alternate server after expiry of a protocol timer with enough information embedded in the message, so that the alternate server can process it. ii- Client triggered refresh upon receipt of an error answer Similar to i-, except that it is triggered upon receip of an "UNABLE_TO_DELIVER" error answer. iii- Peer triggered state data transfer upon receipt of a notification from a peer This is the approach described in the draft-calhoun-diameter-res-mgmt-08.txt iv- Peer triggered refresh This is similar to iii- but relies on the application messages to rebuild the state. A notification message is sent from a peer informing the client that a server went down. The client refreshes sessions on the alternate server. The message can be sent immediately after receiving the notification or could be delayed till the corresponding session(s) actually require a message to be sent to update/delete. i and ii seem to work with existing Diameter wisdom, but they may run into issues, if servers also generate autonomous requests to clients (actually this would probably answer the question I asked in a previous message about the necessity of resurrection sessions/states on backup servers immediately after they take over the role of a failed host) For iii and iv, a backup peer needs to know which clients it needs to send a notification to. This probably can be synchronized between peers of a cluster. It could be useful to think over different alternatives considering the RACS scenario. For RACS, which interface are we talking about, Gq', Rq , any or both? _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jan 17 19:50:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7LUR-0007cL-6n; Wed, 17 Jan 2007 19:50:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7LUQ-0007cG-1A for dime@ietf.org; Wed, 17 Jan 2007 19:50:50 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7LUN-0001Ju-CA for dime@ietf.org; Wed, 17 Jan 2007 19:50: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 <0JC100715H0KGC@usaga01-in.huawei.com> for dime@ietf.org; Wed, 17 Jan 2007 16:50:45 -0800 (PST) Received: from huawei.com ([172.18.4.47]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JC100J7KH0JPF@usaga01-in.huawei.com> for dime@ietf.org; Wed, 17 Jan 2007 16:50:44 -0800 (PST) Received: from N737011 (pool-71-112-126-182.sttlwa.dsl-w.verizon.net [71.112.126.182]) by usaml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JC100G6HHIF1Y@usaml03-in.huawei.com> for dime@ietf.org; Wed, 17 Jan 2007 17:01:32 -0800 (PST) Date: Wed, 17 Jan 2007 16:50:42 -0800 From: Madjid Nakhjiri Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Security In-reply-to: <200701171740.03961.julien.IETF@laposte.net> To: 'Julien Laganier' , dime@ietf.org Message-id: <00a601c73a9a$af74f200$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: Acc6Voxfq1+ex1yWQOWeLPdKAFSC9wAQXOQQ X-Spam-Score: 0.0 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 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, If we are going based on a premise that the HA can authorize anybody regardless of AAA server's authorization, then why are we bothering with authorization messaging to begin with. The HA should just go ahead and authorize MIP6 service. No AAA server and no amount of AAA messaging security can prevent a AAA client from being a misbehaving Network access server. So based on your reasoning we do not need any authorization messaging or AAA protocol security either, since it does not prevent a misbehaving AAA client. BTW, we don't need AAA authentication either. An analogy here is that we don't need Mobile IP signaling security, since a the HA can simply dump all the packets it receives or send them to timbaktu if it wants. We are not trying to boil the ocean by solving all security problems within AAA infrastructures, we are simply trying to see we are not adding new issues. Most of authorization models today, authenticate and authorize the peer at the same time and authorization ALWAYS follows successful authentication. Here we are separating the two and saying that heck the servers can be different too, without providing any assurance that the peer is previously authenticated and this is a new threat. One threat is that the HA can launch a DoS on the AAA server and bombard it with Authorization requests. If the AAA server is to authorize somebody, it must make sure that somebody is authenticated, the proof must either come from that somebody or from within the AAA server (states). The HA cannot do this, because it has no part of the EAP authentication. Furthermore, people are suggesting that the Authenticating AAA server is different from Authorizing AAA server, so that rules out the inner AAA state thing. And yes, even AAA authorization does not guarantee that the HA lies when sending accounting data, but I guess one problem at the time:) My main issue here is actually something else and that is why Mobile IPv6 bootstrapping parameters are provided to the peer before the actual authorization. R, Madjid -----Original Message----- From: julien laganier [mailto:julien.laganier@gmail.com] On Behalf Of Julien Laganier Sent: Wednesday, January 17, 2007 8:40 AM To: dime@ietf.org Cc: Madjid Nakhjiri Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Security Hi Madjid, Thanks for your reply. No I am not looking for a formal threat analysis document. I am rather looking to understand what are the threat, and which attacks derive from them. As I wrote in a previous note I disagree it is of value to block an attack in which a compromised HA presents fake identities to a mobility authorization server. If the HA is compromised it can just furnish the mobility service to anyone it wants; it doesn't need to lie to the authorization server as I described in a previous note, quoted below (sorry to repeat myself): When separate authentication and authorization are used and the HA is compromised (by Mallory), it is possible that the HA submit the identity of another user (Alice) to the authorization server, have this other user (Alice) be authorized by the authorization server, although the user that will be provided with the service is different (e.g. Mallory, or whoever else.) That is, the HA cannot render a unauthenticated user *authorized*, but rather provide it with the service in spite of the user being unauthorized. Binding authentication and authorization together doesn't prevent a compromised HA to provide the service to *anyone* in spite of a particular instance of this anyone not being authenticated or/neither authorized. In other words, the attack I've seen described doesn't IMHO represent a threat since someone who managed to compromise the HA can anyway provide mobility service to any unauthenticated and/or unauthorized user. Am I missing something? --julien On Tuesday 16 January 2007 20:30, Madjid Nakhjiri wrote: > Hi Julien, > > Unless you are looking for a formal threat analysis > document, the attacks have been described several > times on the mailing list. > > I am not against protocol decoupling, I am against > complete state-decoupling. > > I think the email you are referring to (your own) > debates whether the issue is with accounting or with > authorization when a decoupling happens. There is a > little bit of difference in threats for > authorization versus accounting. Many authorization > frameworks, don't separate authorization from > authentication. Immediately following an > authentication, the AAA server also authorizes for > services for the same authenticated peer, assuming > the resources are available. > > The solution being presented here is saying lets > authorize the peer through a separate signaling > exchange and without proof of prior authentication. > Essentially decoupling the first A of AAA from the > other two AAs, causes spoofing problems, since the > network is relying on an intermediary (HA) that (1) > initially has not been part of the authentication > and (2) later can be compromised to request > authorization for an unauthenticated peer. > > Since the authorization is separated from > authentication, this means the authorization > signaling requires a separate trigger. I am saying > the trigger needs to come from the peer itself with > a proof of identity and message integrity. The HA > should simply relay this message to the AAA server. > Not that the HA starts an authorization request on > its own for an arbitrary peer. This just sounds like > a perfect DoS attack. The prevention does not > require a huge overhead, since the peer is already > doing EAP and thus has shared keys with the AAA > servers and can easily sign follow-up authorization > messages. We just have to make sure we have a > trigger from the peer in the bootstrapping process. > > The accounting signaling on the other hand is > different. Accounting happens without intervention > of the peer and is between AAA client and AAA > server. The accounting needs to use whatever > security mechanism available for accounting > framework. That is a AAA problem. The AAA server and > AAA client need to have mechanisms to protect > against false accounting and that is beyond scope of > this work. > > In summary, by decoupling authorization and > authentication we ARE adding threats to the existing > network (by allowing a compromised AAA client to > request authorization for unauthenticated peer). But > accounting is typically decoupled from > authentication anyway and we are not adding any new > threats to the existing accounting framework. > > Hope this clarifies, > > Madjid > > > > > > -----Original Message----- > From: julien laganier > [mailto:julien.laganier@gmail.com] On Behalf Of > Julien Laganier > Sent: Monday, January 15, 2007 2:03 AM > To: dime@ietf.org; Madjid Nakhjiri > Cc: 'Julien Bournelle'; 'Hannes Tschofenig' > Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH > Support: Security > > On Friday 12 January 2007 19:33, Madjid Nakhjiri wrote: > > Hi Julien, > > Hi Madjid, > > > While I appreciate the threat analysis here, the > > problem is pretty easy to solve. Unless, we want > > to leave this vulnerability as something only for > > the security consideration, I suggest we add the > > security measure. > > Solving the problem implies that we understand it. > > I am still not convinced that separation of > authentication and authorization does indeed > introduce a new vulnerability -- see my other note > on the subject: > > http://www1.ietf.org/mail-archive/web/dime/current/m >sg01178.html > > Until we determine what are the threats and attacks, > and determine whether each of them does represent a > sufficiently important risk which deserve a > countermeasure, I really think it is premature to > devise solutions. > > Best, > > --julien > > > I am working on a draft that shows how you can > > separate authentication and authorization while > > binding the two together. The draft will be > > submitted soon (or at least before next IETF > > deadline). There is one problem remaining and that > > is I am wondering about the messaging triggers > > (see below). If people like the solution we can > > use it for the WG draft. It is just hard to show a > > solution over ML, sorry. > > > > For now, I say, we can use the EAP method to > > generate MSK/EMSK and then use those keys in > > assurance for previous authentication (Diameter > > EAP) to the authorization server for Diameter MIP. > > The issue is that based on the threat analysis > > that you provided, we cannot trust HA to provide > > this assurance. It has to come from the peer > > and/or AAA server. > > One way would be for the peer to generate the key > > sign its request with this key. Without getting > > into the details right now, the issue would be: > > What message would carry this signature from the > > peer? And this is why I have been asking the > > question of what message would trigger the Mobile > > IP > > Authorization (MAR) message and what is the timing > > of MAR/MAA w.r.t IKEv2. > > > > The problem is that we need to perform all Mobile > > IP bootstrapping after MAA, i.e. after the MN is > > actually authorized for Mobile IP, so if there is > > any message (even an IKEv2 message) that carries a > > Mobile IP parameter, it has to come after MAA. > > > > Hope I am making sense, > > > > Madjid > > _______________________________________________ > 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 Jan 18 08:46:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Xb1-00052y-RI; Thu, 18 Jan 2007 08:46:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Xb0-00052s-Jc for dime@ietf.org; Thu, 18 Jan 2007 08:46:26 -0500 Received: from smtp.operax.com ([213.50.74.226] helo=smtp-dmz.operax.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7Xay-0007PB-QB for dime@ietf.org; Thu, 18 Jan 2007 08:46:26 -0500 Received: from lulex02.ad.operax.com (ad.operax.com [192.168.2.13]) by smtp-dmz.operax.com (8.13.1/8.13.1) with ESMTP id l0IDkEZd003177 for ; Thu, 18 Jan 2007 14:46:14 +0100 (CET) (envelope-from Ulf.Bodin@operax.com) 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] The Auditing Problem: Soft v.s. Hard States Date: Thu, 18 Jan 2007 14:46:30 +0100 Message-ID: <33656995C5C5094A983DE84DA649A924EB118E@lulex02.ad.operax.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] The Auditing Problem: Soft v.s. Hard States Thread-Index: Acc6hlk91hNWF0xqTC+4utH17GXrzQAd/ySw From: "Ulf Bodin" To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (smtp-dmz.operax.com [172.16.1.4]); Thu, 18 Jan 2007 14:46:14 +0100 (CET) X-Spam-Status: No, score=-52.6 required=4.7 tests=ALL_TRUSTED,BAYES_00, USER_IN_BLACKLIST autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on smtp-dmz.operax.com X-Virus-Scanned: ClamAV 0.88.7/2462/Thu Jan 18 11:07:46 2007 on smtp-dmz.operax.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 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,=20 Replies below.=20 Best regards,=20 Ulf=20 -----Original Message----- From: Tolga Asveren [mailto:asveren@ulticom.com]=20 Sent: den 17 januari 2007 23:20 To: dime@ietf.org Subject: RE: [Dime] The Auditing Problem: Soft v.s. Hard States Hi Ulf, Please see for comments/questions below. Thanks, Tolga > [TOLGA]Just to make sure that I have the correct understanding of soft > v.s. > hard states: I guess we have the soft state if both of the following=20 > are > present: > a) The protocol dictates periodic requests, e.g. a timer is running on > the client, where after expiry of it, client generates a request. > b) A timer is running on the server and server drops the session if=20 > the timer expires before another requests is received for the session. > > [Ulf] Yes. I'm thinking of using the existing AVPs for soft-state as=20 > they're defined. I.e. the Authorization-Lifetime AVP, which to my=20 > understanding relates to the time of the client timer setting and the=20 > Auth-Grace-Period AVP, which is the additional time used for the=20 > server timer setting. [TOLGA]One dummy question about hard-state case, let's assume the following abstract configuration: Requester for the Resource Middleman Resources <--Diameter-------> <--XYZ---> <------Resource usage------------> relationship If I (as the requeser) want the resource to be available, until I explicitly indicate that I don't want to use it anymore, what is bad if the Middleman dies? Let's say the requester wants to release the resource, sends the corresponding request to the middleman it used when requesting the resources. It gets back an error answer "UNABLE_TO_DELIVER" and can try with another middleman. The "new" middleman would release the resources. Here I assume that the middleman is stateless or able to reconstruct the state based on the content of the release message and some additional queries on some other entities but I guess this is not unrealistic with careful protocol design (as a negative example, if the release resources message contains only the Session-Id, it won't work) [Ulf2] Firstly, (this doesn't matter for the question though) shouldn't the requester detect loss of connection followed by failing to re-connect and not get a UNABLE_TO_DELIVER? I mean, the middleman is dead and shouldn't hence return anything (I might miss something here). Of course, if it's instead the server that died the middleman could/should return an UNABLE_TO_DELIVER. Anyway, a stateless middleman performing message routing is basically a Diameter relay agent. Isn't it? In that case I agee to that state replication and/or auditing isn't needed.=20 On the other hand, for a middleman performing application layer processing (maybe the term middleman is inappropriate for such an entity?) or a middleman that is more of a proxy agent keeping states for routing the above won't work as you say. In fact the SPDF can be either one of the above-mention types of an entity (i.e. a relay agent, a proxy agent or a entity performing application layer processing). As I see it, the role of the SPDF currently depends on the actual deployment and the vendor chosen. =20 I guess the question is, why do I need to "resurrect" sessions on a "new" middleman in advance, if I can do it whenever I need the services of the middleman? [Ulf2] No, you don't need to in case we're talking about a relay agent (if I understand your question correctly).=20 > > IMHO, that type of timers are always necessary (regardless of the=20 > presence/absence of an auditing mechanism), because: > i) Client and server may not have a direct Diameter connection where=20 > one isn't able to detect failure of the client by base protocol=20 > procedures, e.g. > watchdog mechanism. > ii) There is no gurantee that a backup node will be present to run=20 > auditing type of procedures to clean up the session on the peer. > > In such a case, client may sit indefinetly with the assumption=20 > everything is fine (or till the entity, which actually requested the=20 > service complains about it). This approach seems risky to me. > > [Ulf] Indefinite Diameter states may indeed not be the legacy we want=20 > to leave our children :-). I completely agree that timers are needed=20 > also for hard-state. I'm not sure such timers should be visible in the > protocol though. This is because a would prefer having the timers=20 > triggered at loss of connectivity instead of having them initiated by=20 > a Diameter message. > > I picture that the death of a server (or client) may need to be=20 > confirmed by other means than timers only. E.g. say that a server died > and that the client fails to connect to its hot backup (because it's=20 > dead as well). However, as the fault management system detects this=20 > event operational people may decide to boot a new device and have it=20 > take over as a cold backup. When coming up this server will audit the=20 > client when it connects. > > Indeed, also in this scenario a timer needs to be present in the=20 > client in case this procedure fails in its entire. This timer may be=20 > set to a number of minutes or even an hour or so and could be started=20 > at the event of loss of connectivity to the primary server (i.e. if a=20 > backup server has not been brought up within this time all states will > be removed in the affected clients). I'm not an expert on COPS, but I=20 > believe it implements such timers (should look before saying that, but > I hope you take it for what it is: more or less a guess :-)). [TOLGA] I think if it is necessary to detect failure of servers from protocol machinery point of view, a protocol timer is required. Like you indicated, we can't assume that a certain type of configuration will be present on the peer side. With the possible presence of intermediaries, e.g. relay agents, there is also no straightforward way of determining crash of a server. Currently one may use an "UNABLE_TO_DELIVER" error answer for a subsequent request sent to a specific server as an indication that it went down/unreachable. Actually, maybe this is what we need, a message with which backups/cluster members can notify clients about failure of a particular server. [Ulf2] Question: how would such a result code differ from the current definition of UNABLE_TO_DELIVER? I'm asking because the answer will hopefully help me understand better what you have in mind :-).=20 I agree with you that to guard against local resource leaking, e.g. memory, one can use a local non-protocol timer, if a protocol timer is not available. Still, such a timer is also not without its worries if it is completely decoupled from protocol processing. It must run longer than the maximum expected life for a session, which could be quite a while for certain types of applications (but again this is an implementation issue) [Ulf2] Do you really think it must run longer than the maximum expected life of a session (would be troublesome if the session lengths distribution is heavy tailed). In my view it could just be long enough to allow for defined actions to be excecuted (e.g. actions taken by the operationals).=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 Thu Jan 18 08:49:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7XeM-000739-It; Thu, 18 Jan 2007 08:49:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7XeK-00071x-UG for dime@ietf.org; Thu, 18 Jan 2007 08:49:53 -0500 Received: from ug-out-1314.google.com ([66.249.92.169]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H7XeH-0007u8-19 for dime@ietf.org; Thu, 18 Jan 2007 08:49:52 -0500 Received: by ug-out-1314.google.com with SMTP id 72so158833ugd for ; Thu, 18 Jan 2007 05:49:45 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=pCnqj7hnyoD6hPtLUg0u4/0hoU17ZqgrtQGew8wtyn3nStW6vR9I4kTGvmMiL0TS3hOAtN7Vtd4xehfgJCRwvTGQ19ai2/gFQavVG68RPC8FddLnXT9hu56sj8zOK9rh+Pm03Dn8gwyaQaPkOxizzhCk9FY3jOq7MDrXv8yrvmI= Received: by 10.66.216.20 with SMTP id o20mr1247159ugg.1169128185351; Thu, 18 Jan 2007 05:49:45 -0800 (PST) Received: from ?192.168.1.110? ( [212.119.9.178]) by mx.google.com with ESMTP id y1sm829699uge.2007.01.18.05.49.43; Thu, 18 Jan 2007 05:49:43 -0800 (PST) From: Julien Laganier To: Madjid Nakhjiri Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Security Date: Thu, 18 Jan 2007 14:48:40 +0100 User-Agent: KMail/1.8.2 References: <00a601c73a9a$af74f200$2f01a8c0@china.huawei.com> In-Reply-To: <00a601c73a9a$af74f200$2f01a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701181448.41060.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d9ae72af46718088458d214998cc683 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Madjid, I get the feeling that we are talking past to each others, so let me reply to you inline. On Thursday 18 January 2007 01:50, Madjid Nakhjiri wrote: > Hi, > > If we are going based on a premise that the HA can > authorize anybody regardless of AAA server's > authorization, then why are we bothering with > authorization messaging to begin with. I thought the attack supposedly introduced by decoupling of authorization and authentication becomes possible when the HA is compromised. Isn't it the case? If not, could you please describe (or give a pointer to a description of it) what the attack really is? If the attack is possible when HA is compromised, then certainly the HA doesn't need to lie to AAA server for authorizing the MIP6 service since it can provide it to whomever it wants. > The HA should > just go ahead and authorize MIP6 service. No AAA > server and no amount of AAA messaging security can > prevent a AAA client from being a misbehaving > Network access server. So based on your reasoning we > do not need any authorization messaging or AAA > protocol security either, since it does not prevent > a misbehaving AAA client. BTW, we don't need AAA > authentication either. Madjid, this is not based on my reasoning at all, I never said that. You are putting words in my mouth. Please abstain from doing that, this really isn't helping the discussion. > An analogy here is that we don't need Mobile IP > signaling security, since a the HA can simply dump > all the packets it receives or send them to timbaktu > if it wants. This is simply irrelevant. > We are not trying to boil the ocean by solving all > security problems within AAA infrastructures, we are > simply trying to see we are not adding new issues. This is exactly what I am trying to do: understand if new issues are introduced by decoupling. > Most of authorization models today, authenticate and > authorize the peer at the same time and > authorization ALWAYS follows successful > authentication. Here we are separating the two and > saying that heck the servers can be different too, > without providing any assurance that the peer is > previously authenticated and this is a new threat. The HA checks with the authentication server if the peer is authenticated, then it checks with the authorization server if it authorized. At the HA, there is assurance that the peer is authenticated since it just checked if it was. So I do not see what the threat is. > One threat is that the HA can launch a DoS on the > AAA server and bombard it with Authorization > requests. But this is unrelated to decoupling of authorization and authentication. If the two were coupled, still the HA would be able to launch a DoS on the AAA server and bombard it with authentication and authorization requests. So this threat is not introduced by decoupling. > If the AAA server is to authorize somebody, it must > make sure that somebody is authenticated, the proof > must either come from that somebody or from within > the AAA server (states). > The HA cannot do this, > because it has no part of the EAP authentication. The AAA server isn't really in control of who gets the mobility server and who doesn't since at the end this is up to the HA to provide the service or not. So certainly the AAA server can trust the HA to provide reliable authenticated identities for authorization. What would be a reason for the HA not do so (it doesn't need to ask the AAA server to provide the service to anyone it wants) and what attacks would that realize (it doesn't need to ask the AAA server to provide the service to anyone it wants). But I guess I am just repeating myself so better to stop here. Best, --julien > Furthermore, people are suggesting that the > Authenticating AAA server is different from > Authorizing AAA server, so that rules out the inner > AAA state thing. > > And yes, even AAA authorization does not guarantee > that the HA lies when sending accounting data, but I > guess one problem at the time:) > > My main issue here is actually something else and > that is why Mobile IPv6 bootstrapping parameters are > provided to the peer before the actual > authorization. > > > R, > > Madjid > > > > > -----Original Message----- > From: julien laganier > [mailto:julien.laganier@gmail.com] On Behalf Of > Julien Laganier > Sent: Wednesday, January 17, 2007 8:40 AM > To: dime@ietf.org > Cc: Madjid Nakhjiri > Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH > Support: Security > > Hi Madjid, > > Thanks for your reply. > > No I am not looking for a formal threat analysis > document. I am rather looking to understand what are > the threat, and which attacks derive from them. > > As I wrote in a previous note I disagree it is of > value to block an attack in which a compromised HA > presents fake identities to a mobility authorization > server. > > If the HA is compromised it can just furnish the > mobility service to anyone it wants; it doesn't need > to lie to the authorization server as I described in > a previous note, quoted below (sorry to repeat > myself): > > When separate authentication and authorization > are used and the HA is compromised (by Mallory), it > is possible that the HA submit the identity of > another user (Alice) to the authorization server, > have this other user (Alice) be authorized by the > authorization server, although the user that will > be provided with the service is different (e.g. > Mallory, or whoever else.) > > That is, the HA cannot render a unauthenticated > user *authorized*, but rather provide it with the > service in spite of the user being unauthorized. > > Binding authentication and authorization together > doesn't prevent a compromised HA to provide the > service to *anyone* in spite of a particular > instance of this anyone not being authenticated > or/neither authorized. > > In other words, the attack I've seen described > doesn't IMHO represent a threat since someone who > managed to compromise the HA can anyway provide > mobility service to any unauthenticated and/or > unauthorized user. > > Am I missing something? > > --julien > > On Tuesday 16 January 2007 20:30, Madjid Nakhjiri > > wrote: > > Hi Julien, > > > > Unless you are looking for a formal threat > > analysis document, the attacks have been described > > several times on the mailing list. > > > > I am not against protocol decoupling, I am against > > complete state-decoupling. > > > > I think the email you are referring to (your own) > > debates whether the issue is with accounting or > > with authorization when a decoupling happens. > > There is a little bit of difference in threats for > > authorization versus accounting. Many > > authorization frameworks, don't separate > > authorization from authentication. Immediately > > following an > > authentication, the AAA server also authorizes for > > services for the same authenticated peer, assuming > > the resources are available. > > > > The solution being presented here is saying lets > > authorize the peer through a separate signaling > > exchange and without proof of prior > > authentication. Essentially decoupling the first A > > of AAA from the other two AAs, causes spoofing > > problems, since the network is relying on an > > intermediary (HA) that (1) initially has not been > > part of the authentication and (2) later can be > > compromised to request authorization for an > > unauthenticated peer. > > > > Since the authorization is separated from > > authentication, this means the authorization > > signaling requires a separate trigger. I am saying > > the trigger needs to come from the peer itself > > with a proof of identity and message integrity. > > The HA should simply relay this message to the AAA > > server. Not that the HA starts an authorization > > request on its own for an arbitrary peer. This > > just sounds like a perfect DoS attack. The > > prevention does not require a huge overhead, since > > the peer is already doing EAP and thus has shared > > keys with the AAA servers and can easily sign > > follow-up authorization messages. We just have to > > make sure we have a trigger from the peer in the > > bootstrapping process. > > > > The accounting signaling on the other hand is > > different. Accounting happens without intervention > > of the peer and is between AAA client and AAA > > server. The accounting needs to use whatever > > security mechanism available for accounting > > framework. That is a AAA problem. The AAA server > > and AAA client need to have mechanisms to protect > > against false accounting and that is beyond scope > > of this work. > > > > In summary, by decoupling authorization and > > authentication we ARE adding threats to the > > existing network (by allowing a compromised AAA > > client to request authorization for > > unauthenticated peer). But accounting is typically > > decoupled from > > authentication anyway and we are not adding any > > new threats to the existing accounting framework. > > > > Hope this clarifies, > > > > Madjid > > > > > > > > > > > > -----Original Message----- > > From: julien laganier > > [mailto:julien.laganier@gmail.com] On Behalf Of > > Julien Laganier > > Sent: Monday, January 15, 2007 2:03 AM > > To: dime@ietf.org; Madjid Nakhjiri > > Cc: 'Julien Bournelle'; 'Hannes Tschofenig' > > Subject: Re: [Dime] Diameter Mobile IPv6 > > HA-to-AAAH Support: Security > > > > On Friday 12 January 2007 19:33, Madjid Nakhjiri > > wrote: > > > Hi Julien, > > > > Hi Madjid, > > > > > While I appreciate the threat analysis here, the > > > problem is pretty easy to solve. Unless, we want > > > to leave this vulnerability as something only > > > for the security consideration, I suggest we add > > > the security measure. > > > > Solving the problem implies that we understand it. > > > > I am still not convinced that separation of > > authentication and authorization does indeed > > introduce a new vulnerability -- see my other note > > on the subject: > > > > http://www1.ietf.org/mail-archive/web/dime/current > >/m sg01178.html > > > > Until we determine what are the threats and > > attacks, and determine whether each of them does > > represent a sufficiently important risk which > > deserve a countermeasure, I really think it is > > premature to devise solutions. > > > > Best, > > > > --julien > > > > > I am working on a draft that shows how you can > > > separate authentication and authorization while > > > binding the two together. The draft will be > > > submitted soon (or at least before next IETF > > > deadline). There is one problem remaining and > > > that is I am wondering about the messaging > > > triggers (see below). If people like the > > > solution we can use it for the WG draft. It is > > > just hard to show a solution over ML, sorry. > > > > > > For now, I say, we can use the EAP method to > > > generate MSK/EMSK and then use those keys in > > > assurance for previous authentication (Diameter > > > EAP) to the authorization server for Diameter > > > MIP. The issue is that based on the threat > > > analysis that you provided, we cannot trust HA > > > to provide this assurance. It has to come from > > > the peer and/or AAA server. > > > One way would be for the peer to generate the > > > key sign its request with this key. Without > > > getting into the details right now, the issue > > > would be: What message would carry this > > > signature from the peer? And this is why I have > > > been asking the question of what message would > > > trigger the Mobile IP > > > Authorization (MAR) message and what is the > > > timing of MAR/MAA w.r.t IKEv2. > > > > > > The problem is that we need to perform all > > > Mobile IP bootstrapping after MAA, i.e. after > > > the MN is actually authorized for Mobile IP, so > > > if there is any message (even an IKEv2 message) > > > that carries a Mobile IP parameter, it has to > > > come after MAA. > > > > > > Hope I am making sense, > > > > > > Madjid > > > > _______________________________________________ > > 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 Jan 18 08:51:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7XgK-0007lL-4G; Thu, 18 Jan 2007 08:51:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7XgI-0007l7-V6 for dime@ietf.org; Thu, 18 Jan 2007 08:51:54 -0500 Received: from smtp.operax.com ([213.50.74.226] helo=smtp-dmz.operax.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7XgH-0007vJ-7l for dime@ietf.org; Thu, 18 Jan 2007 08:51:54 -0500 Received: from lulex02.ad.operax.com (ad.operax.com [192.168.2.13]) by smtp-dmz.operax.com (8.13.1/8.13.1) with ESMTP id l0IDpkWi003290 for ; Thu, 18 Jan 2007 14:51:46 +0100 (CET) (envelope-from Ulf.Bodin@operax.com) 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] The Auditing Problem : Selection of the backup Date: Thu, 18 Jan 2007 14:52:00 +0100 Message-ID: <33656995C5C5094A983DE84DA649A924EB1199@lulex02.ad.operax.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] The Auditing Problem : Selection of the backup Thread-Index: Acc6h8lP0QplHRehTui3WBC9+HDlrQAf06xA From: "Ulf Bodin" To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (smtp-dmz.operax.com [172.16.1.4]); Thu, 18 Jan 2007 14:51:47 +0100 (CET) X-Spam-Status: No, score=-52.6 required=4.7 tests=ALL_TRUSTED,BAYES_00, USER_IN_BLACKLIST autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on smtp-dmz.operax.com X-Virus-Scanned: ClamAV 0.88.7/2462/Thu Jan 18 11:07:46 2007 on smtp-dmz.operax.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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,=20 Replies below.=20 Best regards,=20 Ulf=20 > > IMHO, the proper way of handling Diameter failovers after server=20 > crashes is that the request is retried with an alternate server identity. > > [Ulf] Yes, that is fine when failing over to a backup server. However, > when using SCTP multihoming for path failover the SCTP stack can=20 > transparntly reconnect to the same server but using an IP address=20 > different from the one used when the connection broke. That is, two=20 > alternative paths are configured through the network between client=20 > and server. As I see it, having the client retry with a different=20 > server identity is mainly an alternative to IP takeover. [TOLGA]Yes, SCTP provides network/NIC redundancy. It is host failures where it doesn't help much. > > In case IP takover is not to be used at all maybe failover to a backup > server could be implemented either with alternative server identities=20 > in the application or using SCTP multihoming. To be honest, I don't=20 > know why either one of those approaches would be better then the other one. [TOLGA]I think IP failover is a dead end. Both TCP and SCTP are connection oriented protocols, which makes IP takeover approach non-seamless. The connection needs to be reestablished. For SCTP case, I guess I am missing something in what you describe. I don't see how multihoming could be helpfull when the host goes down. Regarding host failures, it is essentially the same as TCP, no redundancy :-) [Ulf2] Yes. I guess IP failover is only potentially useful in case connection information can be replicated as well (far fetched to my knowledge), or with UDP. Gq' and Rq mandates SCTP so UDP is out of reach at least for those application though. And, no, multihoming would not provide any additional value (bad idea, sorry).=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 Thu Jan 18 14:06:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7cay-0002tD-3T; Thu, 18 Jan 2007 14:06:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7caw-0002mS-3h for dime@ietf.org; Thu, 18 Jan 2007 14:06:42 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7caq-00042T-SL for dime@ietf.org; Thu, 18 Jan 2007 14:06:42 -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 <0JC200J9NVQYES@usaga01-in.huawei.com> for dime@ietf.org; Thu, 18 Jan 2007 11:06:34 -0800 (PST) Received: from huawei.com ([172.18.4.47]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JC20070MVQS8C@usaga01-in.huawei.com> for dime@ietf.org; Thu, 18 Jan 2007 11:06:33 -0800 (PST) Received: from N737011 (pool-71-112-126-182.sttlwa.dsl-w.verizon.net [71.112.126.182]) by usaml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JC200E0HW8ODT@usaml03-in.huawei.com> for dime@ietf.org; Thu, 18 Jan 2007 11:17:18 -0800 (PST) Date: Thu, 18 Jan 2007 11:06:27 -0800 From: Madjid Nakhjiri Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Security In-reply-to: <200701181448.41060.julien.IETF@laposte.net> To: 'Julien Laganier' Message-id: <000801c73b33$c27273c0$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: Acc7B4jXHj3GH121RcGj50Ua61+hIQAJ5lFw X-Spam-Score: 0.0 (/) X-Scan-Signature: bfef20db74c24e87b6dbcd42ea7ba67c Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Julien, Hi Julien, Let me start again: First I think only authenticated users should be authorized for service. Do you agree? If yes, then when decoupling authentication and authorization, you can potentially go to one server for authentication (AAAn) and a different one for authorization (AAAz). The AAAz has no idea that the MN has previously been authenticated by AAAn. The proof of authentication at AAAn cannot be provided by HA to the AAAz. It should be provided by either MN or AAAn. I realize that the HA can authorize service to whomever it wants regardless of what AAAz says. But that threat exists even when authentication and authorization are done at the same time. It does not cause any disruption for the AAA CPU or memory or AAA channel, etc. But, when you decouple the two, and allow the HA to create many fake service requests, you are introducing a new threat to the AAAz: It is processing many requests, it is depleting the resources off the resource database, it may be allocating HA to people and bring the other HA s down as well. As far as you other statements: "At the HA, there is assurance that the peer is authenticated since it just checked if it was. " I don't think assurance at HA is relevant for AAAz, since HA was not involved in EAP. "If the two were coupled, still the HA would be able to launch a DoS on the AAA server and bombard it with authentication and authorization requests." If the authentication failed, then there would be no authorization. "The AAA server isn't really in control of who gets the mobility server and who doesn't since at the end this is up to the HA to provide the service or not." AAA server is the authority that authorizes the resource, it does not police the resource usage, since it is not on the path, but we are talking about authorization not policing. You can feel free to stop the conversation if you want. The solution to the problem is pretty simple, the MN simply signs the trigger for the service request. So instead of getting you frustrated, I will just work to see if I can get the draft out. Madjid -----Original Message----- From: julien laganier [mailto:julien.laganier@gmail.com] On Behalf Of Julien Laganier Sent: Thursday, January 18, 2007 5:49 AM To: Madjid Nakhjiri Cc: dime@ietf.org Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Security Hi Madjid, I get the feeling that we are talking past to each others, so let me reply to you inline. On Thursday 18 January 2007 01:50, Madjid Nakhjiri wrote: > Hi, > > If we are going based on a premise that the HA can > authorize anybody regardless of AAA server's > authorization, then why are we bothering with > authorization messaging to begin with. I thought the attack supposedly introduced by decoupling of authorization and authentication becomes possible when the HA is compromised. Isn't it the case? If not, could you please describe (or give a pointer to a description of it) what the attack really is? If the attack is possible when HA is compromised, then certainly the HA doesn't need to lie to AAA server for authorizing the MIP6 service since it can provide it to whomever it wants. > The HA should > just go ahead and authorize MIP6 service. No AAA > server and no amount of AAA messaging security can > prevent a AAA client from being a misbehaving > Network access server. So based on your reasoning we > do not need any authorization messaging or AAA > protocol security either, since it does not prevent > a misbehaving AAA client. BTW, we don't need AAA > authentication either. Madjid, this is not based on my reasoning at all, I never said that. You are putting words in my mouth. Please abstain from doing that, this really isn't helping the discussion. > An analogy here is that we don't need Mobile IP > signaling security, since a the HA can simply dump > all the packets it receives or send them to timbaktu > if it wants. This is simply irrelevant. > We are not trying to boil the ocean by solving all > security problems within AAA infrastructures, we are > simply trying to see we are not adding new issues. This is exactly what I am trying to do: understand if new issues are introduced by decoupling. > Most of authorization models today, authenticate and > authorize the peer at the same time and > authorization ALWAYS follows successful > authentication. Here we are separating the two and > saying that heck the servers can be different too, > without providing any assurance that the peer is > previously authenticated and this is a new threat. The HA checks with the authentication server if the peer is authenticated, then it checks with the authorization server if it authorized. At the HA, there is assurance that the peer is authenticated since it just checked if it was. So I do not see what the threat is. > One threat is that the HA can launch a DoS on the > AAA server and bombard it with Authorization > requests. But this is unrelated to decoupling of authorization and authentication. If the two were coupled, still the HA would be able to launch a DoS on the AAA server and bombard it with authentication and authorization requests. So this threat is not introduced by decoupling. > If the AAA server is to authorize somebody, it must > make sure that somebody is authenticated, the proof > must either come from that somebody or from within > the AAA server (states). > The HA cannot do this, > because it has no part of the EAP authentication. The AAA server isn't really in control of who gets the mobility server and who doesn't since at the end this is up to the HA to provide the service or not. So certainly the AAA server can trust the HA to provide reliable authenticated identities for authorization. What would be a reason for the HA not do so (it doesn't need to ask the AAA server to provide the service to anyone it wants) and what attacks would that realize (it doesn't need to ask the AAA server to provide the service to anyone it wants). But I guess I am just repeating myself so better to stop here. Best, --julien > Furthermore, people are suggesting that the > Authenticating AAA server is different from > Authorizing AAA server, so that rules out the inner > AAA state thing. > > And yes, even AAA authorization does not guarantee > that the HA lies when sending accounting data, but I > guess one problem at the time:) > > My main issue here is actually something else and > that is why Mobile IPv6 bootstrapping parameters are > provided to the peer before the actual > authorization. > > > R, > > Madjid > > > > > -----Original Message----- > From: julien laganier > [mailto:julien.laganier@gmail.com] On Behalf Of > Julien Laganier > Sent: Wednesday, January 17, 2007 8:40 AM > To: dime@ietf.org > Cc: Madjid Nakhjiri > Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH > Support: Security > > Hi Madjid, > > Thanks for your reply. > > No I am not looking for a formal threat analysis > document. I am rather looking to understand what are > the threat, and which attacks derive from them. > > As I wrote in a previous note I disagree it is of > value to block an attack in which a compromised HA > presents fake identities to a mobility authorization > server. > > If the HA is compromised it can just furnish the > mobility service to anyone it wants; it doesn't need > to lie to the authorization server as I described in > a previous note, quoted below (sorry to repeat > myself): > > When separate authentication and authorization > are used and the HA is compromised (by Mallory), it > is possible that the HA submit the identity of > another user (Alice) to the authorization server, > have this other user (Alice) be authorized by the > authorization server, although the user that will > be provided with the service is different (e.g. > Mallory, or whoever else.) > > That is, the HA cannot render a unauthenticated > user *authorized*, but rather provide it with the > service in spite of the user being unauthorized. > > Binding authentication and authorization together > doesn't prevent a compromised HA to provide the > service to *anyone* in spite of a particular > instance of this anyone not being authenticated > or/neither authorized. > > In other words, the attack I've seen described > doesn't IMHO represent a threat since someone who > managed to compromise the HA can anyway provide > mobility service to any unauthenticated and/or > unauthorized user. > > Am I missing something? > > --julien > > On Tuesday 16 January 2007 20:30, Madjid Nakhjiri > > wrote: > > Hi Julien, > > > > Unless you are looking for a formal threat > > analysis document, the attacks have been described > > several times on the mailing list. > > > > I am not against protocol decoupling, I am against > > complete state-decoupling. > > > > I think the email you are referring to (your own) > > debates whether the issue is with accounting or > > with authorization when a decoupling happens. > > There is a little bit of difference in threats for > > authorization versus accounting. Many > > authorization frameworks, don't separate > > authorization from authentication. Immediately > > following an > > authentication, the AAA server also authorizes for > > services for the same authenticated peer, assuming > > the resources are available. > > > > The solution being presented here is saying lets > > authorize the peer through a separate signaling > > exchange and without proof of prior > > authentication. Essentially decoupling the first A > > of AAA from the other two AAs, causes spoofing > > problems, since the network is relying on an > > intermediary (HA) that (1) initially has not been > > part of the authentication and (2) later can be > > compromised to request authorization for an > > unauthenticated peer. > > > > Since the authorization is separated from > > authentication, this means the authorization > > signaling requires a separate trigger. I am saying > > the trigger needs to come from the peer itself > > with a proof of identity and message integrity. > > The HA should simply relay this message to the AAA > > server. Not that the HA starts an authorization > > request on its own for an arbitrary peer. This > > just sounds like a perfect DoS attack. The > > prevention does not require a huge overhead, since > > the peer is already doing EAP and thus has shared > > keys with the AAA servers and can easily sign > > follow-up authorization messages. We just have to > > make sure we have a trigger from the peer in the > > bootstrapping process. > > > > The accounting signaling on the other hand is > > different. Accounting happens without intervention > > of the peer and is between AAA client and AAA > > server. The accounting needs to use whatever > > security mechanism available for accounting > > framework. That is a AAA problem. The AAA server > > and AAA client need to have mechanisms to protect > > against false accounting and that is beyond scope > > of this work. > > > > In summary, by decoupling authorization and > > authentication we ARE adding threats to the > > existing network (by allowing a compromised AAA > > client to request authorization for > > unauthenticated peer). But accounting is typically > > decoupled from > > authentication anyway and we are not adding any > > new threats to the existing accounting framework. > > > > Hope this clarifies, > > > > Madjid > > > > > > > > > > > > -----Original Message----- > > From: julien laganier > > [mailto:julien.laganier@gmail.com] On Behalf Of > > Julien Laganier > > Sent: Monday, January 15, 2007 2:03 AM > > To: dime@ietf.org; Madjid Nakhjiri > > Cc: 'Julien Bournelle'; 'Hannes Tschofenig' > > Subject: Re: [Dime] Diameter Mobile IPv6 > > HA-to-AAAH Support: Security > > > > On Friday 12 January 2007 19:33, Madjid Nakhjiri > > wrote: > > > Hi Julien, > > > > Hi Madjid, > > > > > While I appreciate the threat analysis here, the > > > problem is pretty easy to solve. Unless, we want > > > to leave this vulnerability as something only > > > for the security consideration, I suggest we add > > > the security measure. > > > > Solving the problem implies that we understand it. > > > > I am still not convinced that separation of > > authentication and authorization does indeed > > introduce a new vulnerability -- see my other note > > on the subject: > > > > http://www1.ietf.org/mail-archive/web/dime/current > >/m sg01178.html > > > > Until we determine what are the threats and > > attacks, and determine whether each of them does > > represent a sufficiently important risk which > > deserve a countermeasure, I really think it is > > premature to devise solutions. > > > > Best, > > > > --julien > > > > > I am working on a draft that shows how you can > > > separate authentication and authorization while > > > binding the two together. The draft will be > > > submitted soon (or at least before next IETF > > > deadline). There is one problem remaining and > > > that is I am wondering about the messaging > > > triggers (see below). If people like the > > > solution we can use it for the WG draft. It is > > > just hard to show a solution over ML, sorry. > > > > > > For now, I say, we can use the EAP method to > > > generate MSK/EMSK and then use those keys in > > > assurance for previous authentication (Diameter > > > EAP) to the authorization server for Diameter > > > MIP. The issue is that based on the threat > > > analysis that you provided, we cannot trust HA > > > to provide this assurance. It has to come from > > > the peer and/or AAA server. > > > One way would be for the peer to generate the > > > key sign its request with this key. Without > > > getting into the details right now, the issue > > > would be: What message would carry this > > > signature from the peer? And this is why I have > > > been asking the question of what message would > > > trigger the Mobile IP > > > Authorization (MAR) message and what is the > > > timing of MAR/MAA w.r.t IKEv2. > > > > > > The problem is that we need to perform all > > > Mobile IP bootstrapping after MAA, i.e. after > > > the MN is actually authorized for Mobile IP, so > > > if there is any message (even an IKEv2 message) > > > that carries a Mobile IP parameter, it has to > > > come after MAA. > > > > > > Hope I am making sense, > > > > > > Madjid > > > > _______________________________________________ > > 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 Jan 18 15:11:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7dbo-0001iE-Ff; Thu, 18 Jan 2007 15:11:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7dbl-0001S5-92 for dime@ietf.org; Thu, 18 Jan 2007 15:11:38 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7dbj-0006yZ-QM for dime@ietf.org; Thu, 18 Jan 2007 15:11:37 -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 D6AB3894F2 for ; Thu, 18 Jan 2007 15:11:35 -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 l0IKBY6d024744 for ; Thu, 18 Jan 2007 15:11:35 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] The Auditing Problem: Soft v.s. Hard States Date: Thu, 18 Jan 2007 15:07:13 -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) Importance: Normal In-Reply-To: <33656995C5C5094A983DE84DA649A924EB118E@lulex02.ad.operax.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 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 Ulf, Please see below for comments/questions. Thanks, Tolga > [TOLGA]One dummy question about hard-state case, let's assume the > following abstract configuration: > > Requester > for the > Resource Middleman Resources > > <--Diameter-------> <--XYZ---> > > > <------Resource usage------------> > relationship > > If I (as the requeser) want the resource to be available, until I > explicitly indicate that I don't want to use it anymore, what is bad if > the Middleman dies? Let's say the requester wants to release the > resource, sends the corresponding request to the middleman it used when > requesting the resources. It gets back an error answer > "UNABLE_TO_DELIVER" and can try with another middleman. The "new" > middleman would release the resources. Here I assume that the middleman > is stateless or able to reconstruct the state based on the content of > the release message and some additional queries on some other entities > but I guess this is not unrealistic with careful protocol design (as a > negative example, if the release resources message contains only the > Session-Id, it won't work) > > [Ulf2] Firstly, (this doesn't matter for the question though) shouldn't > the requester detect loss of connection followed by failing to > re-connect and not get a UNABLE_TO_DELIVER? I mean, the middleman is > dead and shouldn't hence return anything (I might miss something here). > Of course, if it's instead the server that died the middleman > could/should return an UNABLE_TO_DELIVER. Anyway, a stateless middleman > performing message routing is basically a Diameter relay agent. Isn't > it? In that case I agee to that state replication and/or auditing isn't > needed. [TOLGA]My bad not being clear on this example. What I had in mind was that the middleman is a Diameter server, it is not a middleman from Diameter relaying perspective, just the middleman in terms of the whole service (physical reservation/allocation of the resource). It gets a request to reserve some resource, checks it against policy and relays a corresponding request for the physical owner/controller of the resource. If the Diameter client and server are directly connected, failure of server would result a transport error/Diameter watchdog failure but if there are relay agents/proxies etc.. between them, what the client gets will be UNABLE_TO_DELIVER. So, what I refer as stateless middleman was a stateless (or better said where the state can be constructed based on the messages received from the client) Diameter server. > > On the other hand, for a middleman performing application layer > processing (maybe the term middleman is inappropriate for such an > entity?) or a middleman that is more of a proxy agent keeping states for > routing the above won't work as you say. In fact the SPDF can be either > one of the above-mention types of an entity (i.e. a relay agent, a proxy > agent or a entity performing application layer processing). As I see it, > the role of the SPDF currently depends on the actual deployment and the > vendor chosen. [TOLGA]If the application processing entity is unable to reconstruct state based on messages received, is there any way at all to achieve what we are looking for? We try to come up with a mechanism, where the state is reconstructed on a backup server by processing incoming messages. If this is not possible, local implementation dependent mechanisms are all what we can utilize for state recovery/replication. > > I guess the question is, why do I need to "resurrect" sessions on a > "new" > middleman in advance, if I can do it whenever I need the services of the > middleman? > > [Ulf2] No, you don't need to in case we're talking about a relay agent > (if I understand your question correctly). [TOLGA]Again sorry for the misrepresentation of what I thought. I was refering to an application processing entity. Basically the question (after rewording) is, why do I need to "resurrect" sessions on a "new" Diameter server, if I can do that whenever the client need the services of the server? Actually I guess now I have an idea what the answer might be: If the server needs to generate autonomous requests for sessions. AFAICS, for any application, which doesn't have that characeristic, there is no need for premature session resurrection on a backup server, after its active pair fails. > > > > IMHO, that type of timers are always necessary (regardless of the > > presence/absence of an auditing mechanism), because: > > i) Client and server may not have a direct Diameter connection where > > one isn't able to detect failure of the client by base protocol > > procedures, e.g. > > watchdog mechanism. > > ii) There is no gurantee that a backup node will be present to run > > auditing type of procedures to clean up the session on the peer. > > > > In such a case, client may sit indefinetly with the assumption > > everything is fine (or till the entity, which actually requested the > > service complains about it). This approach seems risky to me. > > > > [Ulf] Indefinite Diameter states may indeed not be the legacy we want > > to leave our children :-). I completely agree that timers are needed > > also for hard-state. I'm not sure such timers should be visible in the > > > protocol though. This is because a would prefer having the timers > > triggered at loss of connectivity instead of having them initiated by > > a Diameter message. > > > > I picture that the death of a server (or client) may need to be > > confirmed by other means than timers only. E.g. say that a server died > > > and that the client fails to connect to its hot backup (because it's > > dead as well). However, as the fault management system detects this > > event operational people may decide to boot a new device and have it > > take over as a cold backup. When coming up this server will audit the > > client when it connects. > > > > Indeed, also in this scenario a timer needs to be present in the > > client in case this procedure fails in its entire. This timer may be > > set to a number of minutes or even an hour or so and could be started > > at the event of loss of connectivity to the primary server (i.e. if a > > backup server has not been brought up within this time all states will > > > be removed in the affected clients). I'm not an expert on COPS, but I > > believe it implements such timers (should look before saying that, but > > > I hope you take it for what it is: more or less a guess :-)). > [TOLGA] I think if it is necessary to detect failure of servers from > protocol machinery point of view, a protocol timer is required. Like you > indicated, we can't assume that a certain type of configuration will be > present on the peer side. With the possible presence of intermediaries, > e.g. > relay agents, there is also no straightforward way of determining crash > of a server. Currently one may use an "UNABLE_TO_DELIVER" error answer > for a subsequent request sent to a specific server as an indication that > it went down/unreachable. Actually, maybe this is what we need, a > message with which backups/cluster members can notify clients about > failure of a particular server. > > [Ulf2] Question: how would such a result code differ from the current > definition of UNABLE_TO_DELIVER? I'm asking because the answer will > hopefully help me understand better what you have in mind :-). [TOLGA]If it were a result code, it wouldn't differ at all :-) What I think is a message, which can indicate failure of a particular host. Of course it needs to be sent from another host and should include the identity of the failed host in an AVP. Without such a message, a client can be aware of a server failure only after it send a request with Destination-Host AVP equal to the identity to the failed server (even then, such an assumprtion would require that the network between client and server is well engineered so that a problem in IP or Diameter network won't cause lack of connectivity). I guess if we want to provide premature state reconstruction on backup servers, there has to be some sort of notification from this server to the clients. I guess the overall problem can be split in two chunks: a) How to notify clients b) How to get the data necessary for state reconstruction from the clients > > I agree with you that to guard against local resource leaking, e.g. > memory, one can use a local non-protocol timer, if a protocol timer is > not available. Still, such a timer is also not without its worries if it > is completely decoupled from protocol processing. It must run longer > than the maximum expected life for a session, which could be quite a > while for certain types of applications (but again this is an > implementation issue) > > [Ulf2] Do you really think it must run longer than the maximum expected > life of a session (would be troublesome if the session lengths > distribution is heavy tailed). In my view it could just be long enough > to allow for defined actions to be excecuted (e.g. actions taken by the > operationals). [TOLGA]You may be right, one probably can come up with some clever way of dealing with this problem. Initially I thought of a very simple mechanism of deleting session which hang around for longer than anticipated. In any case, this type of timer is probably implementation dependent and people will come up with some mechanism depending on their environment/the application type running etc... _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jan 19 05:19:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7qpk-0002DF-Ps; Fri, 19 Jan 2007 05:18:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7qpj-0002D4-Qc for dime@ietf.org; Fri, 19 Jan 2007 05:18:55 -0500 Received: from smtp.operax.com ([213.50.74.226] helo=smtp-dmz.operax.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7qpg-0003bo-Of for dime@ietf.org; Fri, 19 Jan 2007 05:18:55 -0500 Received: from lulex02.ad.operax.com (ad.operax.com [192.168.2.13]) by smtp-dmz.operax.com (8.13.1/8.13.1) with ESMTP id l0JAIj3R015145 for ; Fri, 19 Jan 2007 11:18:45 +0100 (CET) (envelope-from Ulf.Bodin@operax.com) 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] The Auditing Problem: Possible approaches Date: Fri, 19 Jan 2007 11:18:44 +0100 Message-ID: <33656995C5C5094A983DE84DA649A924EB12F9@lulex02.ad.operax.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] The Auditing Problem: Possible approaches Thread-Index: Acc6jkKb+wNb2f4MTTOcuGOG5aTKEwBEPqSg From: "Ulf Bodin" To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (smtp-dmz.operax.com [172.16.1.4]); Fri, 19 Jan 2007 11:18:45 +0100 (CET) X-Spam-Status: No, score=-52.6 required=4.7 tests=ALL_TRUSTED,BAYES_00, USER_IN_BLACKLIST autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on smtp-dmz.operax.com X-Virus-Scanned: ClamAV 0.88.7/2466/Fri Jan 19 00:49:11 2007 on smtp-dmz.operax.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a 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,=20 Replies below.=20 Best regards,=20 Ulf=20 -----Original Message----- From: Tolga Asveren [mailto:asveren@ulticom.com]=20 Sent: den 18 januari 2007 00:16 To: dime@ietf.org Subject: [Dime] The Auditing Problem: Possible approaches Hi Ulf, Please see below for comments/questions. Thanks, Tolga > An optimization of this use case using auditing is to have server sB=20 > ask its clients for lists of their respective active sessions (i.e.=20 > lists of active sessions IDs). Such auditing request would be=20 > triggered by the event of that sB learns that it has taken over=20 > clients from sA. Based on these lists sB can determine of sessions it=20 > believes being active are really terminated and identify active but=20 > unknown sessions. For sessions being unknown to sB it can chose to=20 > either just wait until they expires, or explicitly ask the clients for > more information on those sessions (i.e. in order to completely or partly re-create the missing states). > The benefit of auditing is in this use case the period for which sB=20 > operates on inaccurate information can be reduced to a few seconds=20 > instead of potentially several hundreds of seconds. > > To summarize; the auditing mechanisms involved in this use case are=20 > (1) request from server to client for all active sessions and (2)=20 > request from server to client for all details known by the client on a > specific session. [TOLGA] I will skip the local/implementation dependent solution, afterall it is not what we are trying to standardize but I guess also in that domain we have quite a few different approaches which have been used in telecom industry with more or less success in many years. In terms of protocol aided solution, initially I can think of the following list (they may or may not make sense for particular applications and I am not claiming it is a full list :-)): [Ulf2] Ok. My intent was to identify requirements on a auditing mechanisms from use cases (which tend to be local/implementation dependent I guess :-). I agree that we are not to standardize local/implementation dependent solutions. For the list of protocol aided solutions I'm not sure if we need to explicitly account for whether states are replicated or not. That is, a general enough auditing mechansim may support both cases. Hence, I think your list is a good start.=20 i- Client triggered refresh upon expiry of a timer on the client This is essentially the soft state case, where the client can send a message to an alternate server after expiry of a protocol timer with enough information embedded in the message, so that the alternate server can process it. [Ulf2] Yes.=20 ii- Client triggered refresh upon receipt of an error answer Similar to i-, except that it is triggered upon receip of an "UNABLE_TO_DELIVER" error answer. [Ulf2] Question for clarificaiton; would this mean to refresh all session states associated with the target that could not be reached, or just the session for which the error was given?=20 iii- Peer triggered state data transfer upon receipt of a notification from a peer This is the approach described in the draft-calhoun-diameter-res-mgmt-08.txt [Ulf2] Ok.=20 iv- Peer triggered refresh This is similar to iii- but relies on the application messages to rebuild the state. A notification message is sent from a peer informing the client that a server went down. The client refreshes sessions on the alternate server. The message can be sent immediately after receiving the notification or could be delayed till the corresponding session(s) actually require a message to be sent to update/delete. [Ulf2] Ok. What come to my mind though is the amount of messages that'll be generated (this concern applies also to ii in case all session states are to be refreshed). In my view some recommendations on how to control the rate of messages and/or to make it driven by a receiver of the updates would be needed. I might be jumping ahead too quick to the solution now though. =20 i and ii seem to work with existing Diameter wisdom, but they may run into issues, if servers also generate autonomous requests to clients (actually this would probably answer the question I asked in a previous message about the necessity of resurrection sessions/states on backup servers immediately after they take over the role of a failed host) [Ulf2] Yes, autonomous requests/unsolicited call backs is a reason for resurrection sessions/states on backup servers. I believe an additional reason for why states should for some applications be resurrected is that the application are controlling access to scarce resources (e.g. RACS).=20 For iii and iv, a backup peer needs to know which clients it needs to send a notification to. This probably can be synchronized between peers of a cluster. [Ulf2] Yes.=20 It could be useful to think over different alternatives considering the RACS scenario. For RACS, which interface are we talking about, Gq', Rq , any or both? [Ulf2] I'm considering both Gq' and Rq as well as the corresponding interfaces as of ITU and 3GPP. I believe all your list items to applicable to those interfaces. Which specific approach that'll be adopted for each individual deployment (and by different vendors) remains to be seen. My personal belief is that most A-RACF entities (the part of RACS performing admission control) will replicate both session and reservation states. The A-RACF is likely to offer soft-state only to the SPDF (the part of RACS facing application frameworks such as e.g. SIP proxies). The SPDF will probably also replicate states and offer soft-state to its clients. The SPDF is however likely to also offer hard-state to some application frameworks (e.g. leased line application level servers).=20 Given the above assumptions i and ii will be used without complete information in refresh messages to rebuld states. In addition, iii will be used to ensure syncronisation after failover (and potentially periodically between application and SPDF in the case of hard-state). Since states are replicated iv would not apply (if I understand the approach correctly it applies to non cases when data is not replicated only). However, for a deployment without replication for e.g. the A-RACF iv would however apply.=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 Fri Jan 19 07:03:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7sSl-0006pI-UQ; Fri, 19 Jan 2007 07:03:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7sSk-0006pC-IS for dime@ietf.org; Fri, 19 Jan 2007 07:03:18 -0500 Received: from smtp.operax.com ([213.50.74.226] helo=smtp-dmz.operax.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7sSh-0001e7-Lc for dime@ietf.org; Fri, 19 Jan 2007 07:03:18 -0500 Received: from lulex02.ad.operax.com (ad.operax.com [192.168.2.13]) by smtp-dmz.operax.com (8.13.1/8.13.1) with ESMTP id l0JC383l016297 for ; Fri, 19 Jan 2007 13:03:08 +0100 (CET) (envelope-from Ulf.Bodin@operax.com) 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] The Auditing Problem: Soft v.s. Hard States Date: Fri, 19 Jan 2007 13:03:07 +0100 Message-ID: <33656995C5C5094A983DE84DA649A924EB1334@lulex02.ad.operax.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] The Auditing Problem: Soft v.s. Hard States Thread-Index: Acc7PPTQ7On31AkTQNSo2O1FGyZYOQAgIV+Q From: "Ulf Bodin" To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (smtp-dmz.operax.com [172.16.1.4]); Fri, 19 Jan 2007 13:03:08 +0100 (CET) X-Spam-Status: No, score=-52.6 required=4.7 tests=ALL_TRUSTED,BAYES_00, USER_IN_BLACKLIST autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on smtp-dmz.operax.com X-Virus-Scanned: ClamAV 0.88.7/2466/Fri Jan 19 00:49:11 2007 on smtp-dmz.operax.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 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,=20 Replies below.=20 Best regards,=20 Ulf=20 -----Original Message----- From: Tolga Asveren [mailto:asveren@ulticom.com]=20 Sent: den 18 januari 2007 21:07 To: dime@ietf.org Subject: RE: [Dime] The Auditing Problem: Soft v.s. Hard States Hi Ulf, Please see below for comments/questions. Thanks, Tolga > [TOLGA]One dummy question about hard-state case, let's assume the=20 > following abstract configuration: > > Requester > for the > Resource Middleman Resources > > <--Diameter-------> <--XYZ---> > > > <------Resource usage------------> > relationship > > If I (as the requeser) want the resource to be available, until I=20 > explicitly indicate that I don't want to use it anymore, what is bad=20 > if the Middleman dies? Let's say the requester wants to release the=20 > resource, sends the corresponding request to the middleman it used=20 > when requesting the resources. It gets back an error answer=20 > "UNABLE_TO_DELIVER" and can try with another middleman. The "new" > middleman would release the resources. Here I assume that the=20 > middleman is stateless or able to reconstruct the state based on the=20 > content of the release message and some additional queries on some=20 > other entities but I guess this is not unrealistic with careful=20 > protocol design (as a negative example, if the release resources=20 > message contains only the Session-Id, it won't work) > > [Ulf2] Firstly, (this doesn't matter for the question though)=20 > shouldn't the requester detect loss of connection followed by failing=20 > to re-connect and not get a UNABLE_TO_DELIVER? I mean, the middleman=20 > is dead and shouldn't hence return anything (I might miss something here). > Of course, if it's instead the server that died the middleman=20 > could/should return an UNABLE_TO_DELIVER. Anyway, a stateless=20 > middleman performing message routing is basically a Diameter relay=20 > agent. Isn't it? In that case I agee to that state replication and/or=20 > auditing isn't needed. [TOLGA]My bad not being clear on this example. What I had in mind was that the middleman is a Diameter server, it is not a middleman from Diameter relaying perspective, just the middleman in terms of the whole service (physical reservation/allocation of the resource). It gets a request to reserve some resource, checks it against policy and relays a corresponding request for the physical owner/controller of the resource. If the Diameter client and server are directly connected, failure of server would result a transport error/Diameter watchdog failure but if there are relay agents/proxies etc.. between them, what the client gets will be UNABLE_TO_DELIVER. So, what I refer as stateless middleman was a stateless (or better said where the state can be constructed based on the messages received from the client) Diameter server. > > On the other hand, for a middleman performing application layer=20 > processing (maybe the term middleman is inappropriate for such an > entity?) or a middleman that is more of a proxy agent keeping states=20 > for routing the above won't work as you say. In fact the SPDF can be=20 > either one of the above-mention types of an entity (i.e. a relay=20 > agent, a proxy agent or a entity performing application layer=20 > processing). As I see it, the role of the SPDF currently depends on=20 > the actual deployment and the vendor chosen. [TOLGA]If the application processing entity is unable to reconstruct state based on messages received, is there any way at all to achieve what we are looking for? We try to come up with a mechanism, where the state is reconstructed on a backup server by processing incoming messages. If this is not possible, local implementation dependent mechanisms are all what we can utilize for state recovery/replication. [Ulf3] You're right of course. If the client cannot provide complete enough state information in refresh messages it cannot be expected to do that for explicit re-establishmen of states through auditing either. Maybe there are cases when the client can reconstruct state informaiton on demand for such an auditing action (i.e. states it doesn't normally keep), but such scenario is in my view too specific to design general mechanisms for. =20 > > I guess the question is, why do I need to "resurrect" sessions on a=20 > "new" > middleman in advance, if I can do it whenever I need the services of=20 > the middleman? > > [Ulf2] No, you don't need to in case we're talking about a relay agent > (if I understand your question correctly). [TOLGA]Again sorry for the misrepresentation of what I thought. I was refering to an application processing entity. Basically the question (after rewording) is, why do I need to "resurrect" sessions on a "new" Diameter server, if I can do that whenever the client need the services of the server? Actually I guess now I have an idea what the answer might be: If the server needs to generate autonomous requests for sessions. AFAICS, for any application, which doesn't have that characeristic, there is no need for premature session resurrection on a backup server, after its active pair fails. [Ulf3] I actually see an additional reason for resurrecting states being that the server is performing admission control to resources. That is, an active session may have reserved resources which other sessions should not get access to (since they're booked already).=20 > > > > IMHO, that type of timers are always necessary (regardless of the=20 > > presence/absence of an auditing mechanism), because: > > i) Client and server may not have a direct Diameter connection where > > one isn't able to detect failure of the client by base protocol=20 > > procedures, e.g. > > watchdog mechanism. > > ii) There is no gurantee that a backup node will be present to run=20 > > auditing type of procedures to clean up the session on the peer. > > > > In such a case, client may sit indefinetly with the assumption=20 > > everything is fine (or till the entity, which actually requested the > > service complains about it). This approach seems risky to me. > > > > [Ulf] Indefinite Diameter states may indeed not be the legacy we=20 > > want to leave our children :-). I completely agree that timers are=20 > > needed also for hard-state. I'm not sure such timers should be=20 > > visible in the > > > protocol though. This is because a would prefer having the timers=20 > > triggered at loss of connectivity instead of having them initiated=20 > > by a Diameter message. > > > > I picture that the death of a server (or client) may need to be=20 > > confirmed by other means than timers only. E.g. say that a server=20 > > died > > > and that the client fails to connect to its hot backup (because it's > > dead as well). However, as the fault management system detects this=20 > > event operational people may decide to boot a new device and have it > > take over as a cold backup. When coming up this server will audit=20 > > the client when it connects. > > > > Indeed, also in this scenario a timer needs to be present in the=20 > > client in case this procedure fails in its entire. This timer may be > > set to a number of minutes or even an hour or so and could be=20 > > started at the event of loss of connectivity to the primary server=20 > > (i.e. if a backup server has not been brought up within this time=20 > > all states will > > > be removed in the affected clients). I'm not an expert on COPS, but=20 > > I believe it implements such timers (should look before saying that, > > but > > > I hope you take it for what it is: more or less a guess :-)). > [TOLGA] I think if it is necessary to detect failure of servers from=20 > protocol machinery point of view, a protocol timer is required. Like=20 > you indicated, we can't assume that a certain type of configuration=20 > will be present on the peer side. With the possible presence of=20 > intermediaries, e.g. > relay agents, there is also no straightforward way of determining=20 > crash of a server. Currently one may use an "UNABLE_TO_DELIVER" error=20 > answer for a subsequent request sent to a specific server as an=20 > indication that it went down/unreachable. Actually, maybe this is what > we need, a message with which backups/cluster members can notify=20 > clients about failure of a particular server. > > [Ulf2] Question: how would such a result code differ from the current=20 > definition of UNABLE_TO_DELIVER? I'm asking because the answer will=20 > hopefully help me understand better what you have in mind :-). [TOLGA]If it were a result code, it wouldn't differ at all :-) What I think is a message, which can indicate failure of a particular host. Of course it needs to be sent from another host and should include the identity of the failed host in an AVP. Without such a message, a client can be aware of a server failure only after it send a request with Destination-Host AVP equal to the identity to the failed server (even then, such an assumprtion would require that the network between client and server is well engineered so that a problem in IP or Diameter network won't cause lack of connectivity). I guess if we want to provide premature state reconstruction on backup servers, there has to be some sort of notification from this server to the clients. I guess the overall problem can be split in two chunks: a) How to notify clients b) How to get the data necessary for state reconstruction from the clients [Ulf3] Ok. Now I understand what you're saying. And, I completely agree to a). Regarding b) I would suggest to also consider the case when data is replicated. This case would mean to extend b) to also allow for state synchronization (e.g. by sharing a list of active sesisons to identify potential discrepancies).=20 > > I agree with you that to guard against local resource leaking, e.g. > memory, one can use a local non-protocol timer, if a protocol timer is > not available. Still, such a timer is also not without its worries if=20 > it is completely decoupled from protocol processing. It must run=20 > longer than the maximum expected life for a session, which could be=20 > quite a while for certain types of applications (but again this is an=20 > implementation issue) > > [Ulf2] Do you really think it must run longer than the maximum=20 > expected life of a session (would be troublesome if the session=20 > lengths distribution is heavy tailed). In my view it could just be=20 > long enough to allow for defined actions to be excecuted (e.g. actions > taken by the operationals). [TOLGA]You may be right, one probably can come up with some clever way of dealing with this problem. Initially I thought of a very simple mechanism of deleting session which hang around for longer than anticipated. In any case, this type of timer is probably implementation dependent and people will come up with some mechanism depending on their environment/the application type running etc... [Ulf3] Yes, I agree. And, I certainly believe recommendations and even some strics rules for how to use a timer (protocol or non-protocol) detecting that the connection is lost would be good to have. I think such rules should be related to the values of the authorization-timeout and auth-grace-period rather than expected lifetime of sesisons though.=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 Fri Jan 19 09:10:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7uRN-000736-2Y; Fri, 19 Jan 2007 09:10:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7uRL-00072t-9n for dime@ietf.org; Fri, 19 Jan 2007 09:09:59 -0500 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7uRI-0005J5-88 for dime@ietf.org; Fri, 19 Jan 2007 09:09:59 -0500 Received: by ug-out-1314.google.com with SMTP id 72so415547ugd for ; Fri, 19 Jan 2007 06:09:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=kYZrD2Lkax7WtK28eYBFiWj4fvanNBjBhIHgJ2R1I//s/jW6MQPr3w0MhwrY3N8GSzXf2O1+Fc9kJrOHphC0xzHRCuufBb8MyWUpFsrZGZP3K2OIU2Rp9UEl76k+xSUkdoSGGHwf0WudaUtY8JJduh/YPMK/UQ/njrcEp53QS7w= Received: by 10.66.232.10 with SMTP id e10mr3048608ugh.1169215795026; Fri, 19 Jan 2007 06:09:55 -0800 (PST) Received: from ?192.168.1.110? ( [212.119.9.178]) by mx.google.com with ESMTP id 29sm2172296uga.2007.01.19.06.09.52; Fri, 19 Jan 2007 06:09:53 -0800 (PST) From: Julien Laganier To: dime@ietf.org Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Security Date: Fri, 19 Jan 2007 15:08:49 +0100 User-Agent: KMail/1.8.2 References: <000801c73b33$c27273c0$2f01a8c0@china.huawei.com> In-Reply-To: <000801c73b33$c27273c0$2f01a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701191508.50360.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5df1f98f3253c63b673ea560243aa58f 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 On Thursday 18 January 2007 20:06, Madjid Nakhjiri wrote: > Hi Julien, Hi Madjid, > Hi Julien, Hi again, > Let me start again: First I think only authenticated > users should be authorized for service. Do you > agree? In this case, since authorization is delivered or not based on the user identity, certainly the user shall be authenticated. > If yes, then when decoupling authentication and > authorization, you can potentially go to one server > for authentication (AAAn) and a different one for > authorization (AAAz). Right: this is the split between authentication and authorization we've been discussing. > The AAAz has no idea that the MN has previously been > authenticated by AAAn. Why should it know about authentication -- we're talking about separating the two here. AAAz is giving an authorization status for a MN identity to an HA requesting this information. Authentication of the MN is orthogonal to that. > The proof of authentication at AAAn cannot be > provided by HA to the AAAz. The question isn't if it can or if it cannot. The AAAz isn't in charge of veryfing authentication proof, it is in charge of delivering authorization status to a AAA client requesting it. > It should be provided by either MN or AAAn. No it shouldn't, that's the whole point of split. If you want the AAAz to know about authentication, then don't split entities and use a single AAAn/z. Further, I am reading your statement as somehow saying that the MN is more trustworthy than the HA (you said "The proof of authentication at AAAn cannot be provided by HA to the AAAz. It should be provided by either MN or AAAn."), and I find it surprising. Maybe I read you wrong... > I realize that the HA can authorize service to > whomever it wants regardless of what AAAz > says. Good. > But that threat exists even when authentication and > authorization are done at the same time. Nobody argued about that. > It does not cause any disruption for the AAA CPU or > memory or AAA channel, etc. Right. > But, when you decouple the two, and allow the HA to > create many fake service requests, you are > introducing a new threat to the AAAz: It is > processing many requests, it is depleting the > resources off the resource database, it may be > allocating HA to people and bring the other HA s down > as well. So if I read you correctly, in the threat you're describing there is a rogue HA launching a denial of service attack against the AAAz, right? And this DoS takes the form of a flooding attack? First of all, I think that such an attack isn't caused by decoupling of AAAn and AAAz. It is caused by the rogue HA flooding a AAA server. Second, I do not think how the AAAz would be protected from a flooding attack launched by a rogue HA if it had a "proof of authentication at AAAn [...] provided by either MN or AAAn". AFAIK authentication does not protect from flooding. > As far as you other statements: > "At the HA, there is assurance that the peer is > authenticated since it just checked if it was. " > > I don't think assurance at HA is relevant for AAAz, > since HA was not involved in EAP. But HA is involved in the EAP exchange! It acts as a passtrough, and gets authentication assurance from AAAn. > "If the two were coupled, still the > HA would be able to launch a DoS on the AAA server > and bombard it with authentication and authorization > requests." > > If the authentication failed, then there would be no > authorization. AFAICS the mechanism you want to provide protect from a rogue HA. If the HA is rogue it can ask for authorization request when it wants. It doesn't need authentication to succeed for that. > "The AAA server isn't really in control of who gets > the mobility server and who doesn't since at the end > this is up to the HA to provide the service or not." > > AAA server is the authority that authorizes the > resource, it does not police the resource usage, > since it is not on the path, but we are talking > about authorization not policing. > > You can feel free to stop the conversation if you > want. The solution to the problem is pretty simple, > the MN simply signs the trigger for the service > request. So instead of getting you frustrated, I > will just work to see if I can get the draft out. The solution to this discussion is pretty simple too: What is the problem? :) --julien > -----Original Message----- > From: julien laganier > [mailto:julien.laganier@gmail.com] On Behalf Of > Julien Laganier > Sent: Thursday, January 18, 2007 5:49 AM > To: Madjid Nakhjiri > Cc: dime@ietf.org > Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH > Support: Security > > Hi Madjid, > > I get the feeling that we are talking past to each > others, so let me reply to you inline. > > On Thursday 18 January 2007 01:50, Madjid Nakhjiri > > wrote: > > Hi, > > > > If we are going based on a premise that the HA can > > authorize anybody regardless of AAA server's > > authorization, then why are we bothering with > > authorization messaging to begin with. > > I thought the attack supposedly introduced by > decoupling of authorization and authentication > becomes possible when the HA is compromised. Isn't > it the case? If not, could you please describe (or > give a pointer to a description of it) what the > attack really is? > > If the attack is possible when HA is compromised, > then certainly the HA doesn't need to lie to AAA > server for authorizing the MIP6 service since it can > provide it to whomever it wants. > > > The HA should > > just go ahead and authorize MIP6 service. No AAA > > server and no amount of AAA messaging security can > > prevent a AAA client from being a misbehaving > > Network access server. So based on your reasoning > > we do not need any authorization messaging or AAA > > protocol security either, since it does not > > prevent a misbehaving AAA client. BTW, we don't > > need AAA authentication either. > > Madjid, this is not based on my reasoning at all, I > never said that. You are putting words in my mouth. > Please abstain from doing that, this really isn't > helping the discussion. > > > An analogy here is that we don't need Mobile IP > > signaling security, since a the HA can simply dump > > all the packets it receives or send them to > > timbaktu if it wants. > > This is simply irrelevant. > > > We are not trying to boil the ocean by solving all > > security problems within AAA infrastructures, we > > are simply trying to see we are not adding new > > issues. > > This is exactly what I am trying to do: understand > if new issues are introduced by decoupling. > > > Most of authorization models today, authenticate > > and authorize the peer at the same time and > > authorization ALWAYS follows successful > > authentication. Here we are separating the two and > > saying that heck the servers can be different too, > > without providing any assurance that the peer is > > previously authenticated and this is a new threat. > > The HA checks with the authentication server if the > peer is authenticated, then it checks with the > authorization server if it authorized. > > At the HA, there is assurance that the peer is > authenticated since it just checked if it was. > > So I do not see what the threat is. > > > One threat is that the HA can launch a DoS on the > > AAA server and bombard it with Authorization > > requests. > > But this is unrelated to decoupling of authorization > and authentication. If the two were coupled, still > the HA would be able to launch a DoS on the AAA > server and bombard it with authentication and > authorization requests. > > So this threat is not introduced by decoupling. > > > If the AAA server is to authorize somebody, it > > must make sure that somebody is authenticated, the > > proof must either come from that somebody or from > > within the AAA server (states). > > The HA cannot do this, > > because it has no part of the EAP authentication. > > The AAA server isn't really in control of who gets > the mobility server and who doesn't since at the end > this is up to the HA to provide the service or not. > So certainly the AAA server can trust the HA to > provide reliable authenticated identities for > authorization. > > What would be a reason for the HA not do so (it > doesn't need to ask the AAA server to provide the > service to anyone it wants) and what attacks would > that realize (it doesn't need to ask the AAA server > to provide the service to anyone it wants). > > But I guess I am just repeating myself so better to > stop here. > > Best, > > --julien > > > Furthermore, people are suggesting that the > > Authenticating AAA server is different from > > Authorizing AAA server, so that rules out the > > inner AAA state thing. > > > > And yes, even AAA authorization does not guarantee > > that the HA lies when sending accounting data, but > > I guess one problem at the time:) > > > > My main issue here is actually something else and > > that is why Mobile IPv6 bootstrapping parameters > > are provided to the peer before the actual > > authorization. > > > > > > R, > > > > Madjid > > > > > > > > > > -----Original Message----- > > From: julien laganier > > [mailto:julien.laganier@gmail.com] On Behalf Of > > Julien Laganier > > Sent: Wednesday, January 17, 2007 8:40 AM > > To: dime@ietf.org > > Cc: Madjid Nakhjiri > > Subject: Re: [Dime] Diameter Mobile IPv6 > > HA-to-AAAH Support: Security > > > > Hi Madjid, > > > > Thanks for your reply. > > > > No I am not looking for a formal threat analysis > > document. I am rather looking to understand what > > are the threat, and which attacks derive from > > them. > > > > As I wrote in a previous note I disagree it is of > > value to block an attack in which a compromised HA > > presents fake identities to a mobility > > authorization server. > > > > If the HA is compromised it can just furnish the > > mobility service to anyone it wants; it doesn't > > need to lie to the authorization server as I > > described in a previous note, quoted below (sorry > > to repeat myself): > > > > When separate authentication and authorization > > are used and the HA is compromised (by Mallory), > > it is possible that the HA submit the identity of > > another user (Alice) to the authorization server, > > have this other user (Alice) be authorized by the > > authorization server, although the user that will > > be provided with the service is different (e.g. > > Mallory, or whoever else.) > > > > That is, the HA cannot render a unauthenticated > > user *authorized*, but rather provide it with the > > service in spite of the user being unauthorized. > > > > Binding authentication and authorization > > together doesn't prevent a compromised HA to > > provide the service to *anyone* in spite of a > > particular instance of this anyone not being > > authenticated or/neither authorized. > > > > In other words, the attack I've seen described > > doesn't IMHO represent a threat since someone who > > managed to compromise the HA can anyway provide > > mobility service to any unauthenticated and/or > > unauthorized user. > > > > Am I missing something? > > > > --julien > > > > On Tuesday 16 January 2007 20:30, Madjid Nakhjiri > > > > wrote: > > > Hi Julien, > > > > > > Unless you are looking for a formal threat > > > analysis document, the attacks have been > > > described several times on the mailing list. > > > > > > I am not against protocol decoupling, I am > > > against complete state-decoupling. > > > > > > I think the email you are referring to (your > > > own) debates whether the issue is with > > > accounting or with authorization when a > > > decoupling happens. There is a little bit of > > > difference in threats for authorization versus > > > accounting. Many > > > authorization frameworks, don't separate > > > authorization from authentication. Immediately > > > following an > > > authentication, the AAA server also authorizes > > > for services for the same authenticated peer, > > > assuming the resources are available. > > > > > > The solution being presented here is saying lets > > > authorize the peer through a separate signaling > > > exchange and without proof of prior > > > authentication. Essentially decoupling the first > > > A of AAA from the other two AAs, causes spoofing > > > problems, since the network is relying on an > > > intermediary (HA) that (1) initially has not > > > been part of the authentication and (2) later > > > can be compromised to request authorization for > > > an unauthenticated peer. > > > > > > Since the authorization is separated from > > > authentication, this means the authorization > > > signaling requires a separate trigger. I am > > > saying the trigger needs to come from the peer > > > itself with a proof of identity and message > > > integrity. The HA should simply relay this > > > message to the AAA server. Not that the HA > > > starts an authorization request on its own for > > > an arbitrary peer. This just sounds like a > > > perfect DoS attack. The prevention does not > > > require a huge overhead, since the peer is > > > already doing EAP and thus has shared keys with > > > the AAA servers and can easily sign follow-up > > > authorization messages. We just have to make > > > sure we have a trigger from the peer in the > > > bootstrapping process. > > > > > > The accounting signaling on the other hand is > > > different. Accounting happens without > > > intervention of the peer and is between AAA > > > client and AAA server. The accounting needs to > > > use whatever security mechanism available for > > > accounting framework. That is a AAA problem. The > > > AAA server and AAA client need to have > > > mechanisms to protect against false accounting > > > and that is beyond scope of this work. > > > > > > In summary, by decoupling authorization and > > > authentication we ARE adding threats to the > > > existing network (by allowing a compromised AAA > > > client to request authorization for > > > unauthenticated peer). But accounting is > > > typically decoupled from > > > authentication anyway and we are not adding any > > > new threats to the existing accounting > > > framework. > > > > > > Hope this clarifies, > > > > > > Madjid > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: julien laganier > > > [mailto:julien.laganier@gmail.com] On Behalf Of > > > Julien Laganier > > > Sent: Monday, January 15, 2007 2:03 AM > > > To: dime@ietf.org; Madjid Nakhjiri > > > Cc: 'Julien Bournelle'; 'Hannes Tschofenig' > > > Subject: Re: [Dime] Diameter Mobile IPv6 > > > HA-to-AAAH Support: Security > > > > > > On Friday 12 January 2007 19:33, Madjid Nakhjiri > > > > wrote: > > > > Hi Julien, > > > > > > Hi Madjid, > > > > > > > While I appreciate the threat analysis here, > > > > the problem is pretty easy to solve. Unless, > > > > we want to leave this vulnerability as > > > > something only for the security consideration, > > > > I suggest we add the security measure. > > > > > > Solving the problem implies that we understand > > > it. > > > > > > I am still not convinced that separation of > > > authentication and authorization does indeed > > > introduce a new vulnerability -- see my other > > > note on the subject: > > > > > > http://www1.ietf.org/mail-archive/web/dime/curre > > >nt /m sg01178.html > > > > > > Until we determine what are the threats and > > > attacks, and determine whether each of them does > > > represent a sufficiently important risk which > > > deserve a countermeasure, I really think it is > > > premature to devise solutions. > > > > > > Best, > > > > > > --julien > > > > > > > I am working on a draft that shows how you can > > > > separate authentication and authorization > > > > while binding the two together. The draft will > > > > be submitted soon (or at least before next > > > > IETF deadline). There is one problem remaining > > > > and that is I am wondering about the messaging > > > > triggers (see below). If people like the > > > > solution we can use it for the WG draft. It is > > > > just hard to show a solution over ML, sorry. > > > > > > > > For now, I say, we can use the EAP method to > > > > generate MSK/EMSK and then use those keys in > > > > assurance for previous authentication > > > > (Diameter EAP) to the authorization server for > > > > Diameter MIP. The issue is that based on the > > > > threat analysis that you provided, we cannot > > > > trust HA to provide this assurance. It has to > > > > come from the peer and/or AAA server. > > > > One way would be for the peer to generate the > > > > key sign its request with this key. Without > > > > getting into the details right now, the issue > > > > would be: What message would carry this > > > > signature from the peer? And this is why I > > > > have been asking the question of what message > > > > would trigger the Mobile IP > > > > Authorization (MAR) message and what is the > > > > timing of MAR/MAA w.r.t IKEv2. > > > > > > > > The problem is that we need to perform all > > > > Mobile IP bootstrapping after MAA, i.e. after > > > > the MN is actually authorized for Mobile IP, > > > > so if there is any message (even an IKEv2 > > > > message) that carries a Mobile IP parameter, > > > > it has to come after MAA. > > > > > > > > Hope I am making sense, > > > > > > > > Madjid > > > > > > _______________________________________________ > > > 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 Jan 19 10:25:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7vcq-0004i2-AE; Fri, 19 Jan 2007 10:25:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7vcp-0004hr-1l for dime@ietf.org; Fri, 19 Jan 2007 10:25:55 -0500 Received: from uswgco34.uswest.com ([199.168.32.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7vcm-0000TS-9Z for dime@ietf.org; Fri, 19 Jan 2007 10:25:54 -0500 Received: from egate-co7.uswc.uswest.com (egate-co7.uswc.uswest.com [151.119.87.234]) by uswgco34.uswest.com (8/8) with ESMTP id l0JFPptM017482 for ; Fri, 19 Jan 2007 08:25:51 -0700 (MST) Received: from itomae2ksm02.AD.QINTRA.COM (localhost [127.0.0.1]) by egate-co7.uswc.uswest.com (8/8.13.7) with ESMTP id l0JFPa24026758 for ; Fri, 19 Jan 2007 08:25:51 -0700 (MST) Received: from itomae2km03.AD.QINTRA.COM ([10.6.9.152]) by itomae2ksm02.AD.QINTRA.COM with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 09:25:46 -0600 X-MessageTextProcessor: DisclaimIt (2.70.270) [Qwest Communications International Inc.] X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Jan 2007 09:25:37 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Supplicant X.509 AVP? thread-index: Acc73hI+KFYuRDTJSoKyIySx/wkdVw== Importance: normal Priority: normal From: "Morrow, Glenn" To: X-OriginalArrivalTime: 19 Jan 2007 15:25:46.0398 (UTC) FILETIME=[175B33E0:01C73BDE] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Dime] Supplicant X.509 AVP? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Greetings to all, We'd like to begin exploring the use of certificates as credentials for several AAA applications and would prefer to use the keying material for integrity and authentication at the application signaling level itself. The flows for this type of deployment and thus application latency of application setup are greatly reduced (no need for yet another SA setup and message exchange to yet another network entity such as a secure directory/repository for public certs, No EAP-TLS overhead) if the certificates are transpoted over Diameter from the server to the client. I'd like to float this concept to the WG and see if others have existing or planned implementations and would like to colloborate on an ID to define a supplicant certificate AVP to be a base Diameter AVP such that it could be used for any Diameter application. I have not floated this to the Radius extension WG due to the UDP transport. I think that if Radius is used, the EAP-TLS or a separate directory lookup from the client is the only option available. There should be no such limitation on Diameter though. Thanks, Glenn This communication is the property of Qwest and may contain confidential = or privileged information. Unauthorized use of this communication is = strictly=20 prohibited and may be unlawful. If you have received this communication = in error, please immediately notify the sender by reply e-mail and = destroy=20 all copies of the communication and any attachments. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jan 19 13:02:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7y4e-0006Co-Pm; Fri, 19 Jan 2007 13:02:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7y4e-0006Ce-70 for dime@ietf.org; Fri, 19 Jan 2007 13:02:48 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7y4a-0006Hs-TY for dime@ietf.org; Fri, 19 Jan 2007 13:02:48 -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 l0JI2dv05368; Fri, 19 Jan 2007 13:02:39 -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: Security Date: Fri, 19 Jan 2007 12:02:37 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711251A04C@zrc2hxm2.corp.nortel.com> In-Reply-To: <200701191508.50360.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Security Thread-index: Acc709nKW3f/dVG+R/q0Ijo6e4bf/AAHlI3A From: "Ahmad Muhanna" To: "Julien Laganier" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 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 Julien, Please see one comment below. Regards, Ahmad =20 > -----Original Message----- > From: Julien Laganier [mailto:julien.IETF@laposte.net]=20 > Sent: Friday, January 19, 2007 8:09 AM > To: dime@ietf.org > Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Security >=20 > On Thursday 18 January 2007 20:06, Madjid Nakhjiri > wrote: > > Hi Julien, >=20 > Hi Madjid, >=20 > > Hi Julien, >=20 > Hi again, >=20 > > Let me start again: First I think only authenticated > > users should be authorized for service. Do you > > agree? >=20 > In this case, since authorization is delivered or not=20 > based on the user identity, certainly the user shall=20 > be authenticated. >=20 > > If yes, then when decoupling authentication and > > authorization, you can potentially go to one server > > for authentication (AAAn) and a different one for > > authorization (AAAz). >=20 > Right: this is the split between authentication and=20 > authorization we've been discussing. >=20 > > The AAAz has no idea that the MN has previously been > > authenticated by AAAn. >=20 > Why should it know about authentication -- we're=20 > talking about separating the two here. >=20 > AAAz is giving an authorization status for a MN=20 > identity to an HA requesting this information.=20 > Authentication of the MN is orthogonal to that. >=20 > > The proof of authentication at AAAn cannot be > > provided by HA to the AAAz.=20 >=20 > The question isn't if it can or if it cannot. The AAAz=20 > isn't in charge of veryfing authentication proof, it=20 > is in charge of delivering authorization status to a=20 > AAA client requesting it. >=20 > > It should be provided by either MN or AAAn. >=20 > No it shouldn't, that's the whole point of split. If=20 > you want the AAAz to know about authentication, then=20 > don't split entities and use a single AAAn/z. >=20 > Further, I am reading your statement as somehow saying=20 > that the MN is more trustworthy than the HA (you said=20 > "The proof of authentication at AAAn cannot be=20 > provided by HA to the AAAz. It should be provided by=20 > either MN or AAAn."), and I find it surprising. Maybe=20 > I read you wrong... >=20 > > I realize that the HA can authorize service to > > whomever it wants regardless of what AAAz=20 > > says.=20 >=20 > Good. >=20 > > But that threat exists even when authentication and > > authorization are done at the same time.=20 >=20 > Nobody argued about that. >=20 > > It does not cause any disruption for the AAA CPU or > > memory or AAA channel, etc.=20 >=20 > Right. >=20 > > But, when you decouple the two, and allow the HA to > > create many fake service requests, you are > > introducing a new threat to the AAAz: It is > > processing many requests, it is depleting the > > resources off the resource database, it may be > > allocating HA to people and bring the other HA s down > > as well.=20 >=20 > So if I read you correctly, in the threat you're=20 > describing there is a rogue HA launching a denial of=20 > service attack against the AAAz, right? And this DoS=20 > takes the form of a flooding attack? >=20 > First of all, I think that such an attack isn't caused=20 > by decoupling of AAAn and AAAz. It is caused by the=20 > rogue HA flooding a AAA server. >=20 > Second, I do not think how the AAAz would be protected=20 > from a flooding attack launched by a rogue HA if it=20 > had a "proof of authentication at AAAn [...] provided=20 > by either MN or AAAn". AFAIK authentication does not=20 > protect from flooding. [Ahmad] If the proposed solution requires the HA to provide authentication material to AAAz to ensure that MN has been authenticated, the AAAz will have the chance to drop these Authorization Requests if authentication material is not authentic, which I assume it is not in this scenario. Also, if AAAz receives too many of these Requests from the same HA, AAAz can close the connection to the HA or just ignore all of its traffic. Theoretically, I agree with Madjid that there is an issue that needs to be addressed. On the other hand, we need to assess the possibility for this security vulnerability to happen in the field and make an educated decision to address it or not. One more thing, we can recognize the issue and provide an optional solution that any deployment which does not guarantee that HA wont be comprised Shall implement the proposed solution. Just an idea. >=20 > > As far as you other statements: > > "At the HA, there is assurance that the peer is > > authenticated since it just checked if it was. " > > > > I don't think assurance at HA is relevant for AAAz, > > since HA was not involved in EAP. >=20 > But HA is involved in the EAP exchange! It acts as a=20 > passtrough, and gets authentication assurance from=20 > AAAn. >=20 > > "If the two were coupled, still the > > HA would be able to launch a DoS on the AAA server > > and bombard it with authentication and authorization > > requests." > > > > If the authentication failed, then there would be no > > authorization. >=20 > AFAICS the mechanism you want to provide protect from a=20 > rogue HA. If the HA is rogue it can ask for=20 > authorization request when it wants. It doesn't need=20 > authentication to succeed for that. >=20 > > "The AAA server isn't really in control of who gets > > the mobility server and who doesn't since at the end > > this is up to the HA to provide the service or not." > > > > AAA server is the authority that authorizes the > > resource, it does not police the resource usage, > > since it is not on the path, but we are talking > > about authorization not policing. > > > > You can feel free to stop the conversation if you > > want. The solution to the problem is pretty simple, > > the MN simply signs the trigger for the service > > request. So instead of getting you frustrated, I > > will just work to see if I can get the draft out. >=20 > The solution to this discussion is pretty simple too:=20 > What is the problem? :) >=20 > --julien >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Jan 20 07:10:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8F3A-0002xz-Gp; Sat, 20 Jan 2007 07:10:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8F39-0002xu-Np for dime@ietf.org; Sat, 20 Jan 2007 07:10:23 -0500 Received: from nf-out-0910.google.com ([64.233.182.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8F38-0003WT-Az for dime@ietf.org; Sat, 20 Jan 2007 07:10:23 -0500 Received: by nf-out-0910.google.com with SMTP id l36so762841nfa for ; Sat, 20 Jan 2007 04:10:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=ICpSRLCgDVRaURgUbzzgW9aeCBx78UOtcLyHZ8V6MYR3HjDppzjBtLeoUFG9RhfFnbyVPc83xgplvWpt24FVDgtqyc8EPyKoZSvR3RRJsX7ThSBTevp20ar1ssGKbgXjCl4kpO417rzI0twBP+7h2VKnjgjkiiP6mvNzDGPSnQM= Received: by 10.49.65.19 with SMTP id s19mr3595426nfk.1169295021448; Sat, 20 Jan 2007 04:10:21 -0800 (PST) Received: by 10.48.222.20 with HTTP; Sat, 20 Jan 2007 04:10:21 -0800 (PST) Message-ID: <5e2406980701200410q1b8274f4m4dc526f64ea851d3@mail.gmail.com> Date: Sat, 20 Jan 2007 13:10:21 +0100 From: "Julien Bournelle" To: "Ahmad Muhanna" Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Issue or not Issue ? MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: dime@ietf.org, Julien Laganier 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, let me answer to your comments On 1/19/07, Ahmad Muhanna wrote: > > > First of all, I think that such an attack isn't caused > > by decoupling of AAAn and AAAz. It is caused by the > > rogue HA flooding a AAA server. > > > > Second, I do not think how the AAAz would be protected > > from a flooding attack launched by a rogue HA if it > > had a "proof of authentication at AAAn [...] provided > > by either MN or AAAn". AFAIK authentication does not > > protect from flooding. > > [Ahmad] > If the proposed solution requires the HA to provide authentication > material to AAAz to ensure that MN has been authenticated, the AAAz will > have the chance to drop these Authorization Requests if authentication > material is not authentic, which I assume it is not in this scenario. i'm not sure to well understand your comment. Which "proposed solution" ? Moreover, I would say that this not the role of the AAAz to perform a kind of authentication. The HA needs to know if the user is the person she claimed to be: it uses the AAAn for this. Then, it needs to know if the user is authorized: it uses the AAAz for this. If we want the AAAz to know if the user is authenticated, we shouldn't decoupled the 2 process. > Also, if AAAz receives too many of these Requests from the same HA, AAAz > can close the connection to the HA or just ignore all of its traffic. right > > Theoretically, I agree with Madjid that there is an issue that needs to > be addressed. I'm still not convinced. > On the other hand, we need to assess the possibility for > this security vulnerability to happen in the field and make an educated > decision to address it or not. One more thing, we can recognize the > issue > and provide an optional solution that any deployment which does > not guarantee that HA wont be comprised Shall implement the proposed > solution. Just an idea. that's indeed the question: do we introduce a threat here ? or in other terms do we have an issue here ? I think no. Madjid and you think "yes". We clearly need a way to move forward but I don't think we (as a WG) can say: if you think there is an issue then use this optional mechanism, if you don't think it is an issue then you don't need this optional mechanism. We must know if it is an issue or not. regards, --Julien (B.) > > > > > > > As far as you other statements: > > > "At the HA, there is assurance that the peer is > > > authenticated since it just checked if it was. " > > > > > > I don't think assurance at HA is relevant for AAAz, > > > since HA was not involved in EAP. > > > > But HA is involved in the EAP exchange! It acts as a > > passtrough, and gets authentication assurance from > > AAAn. > > > > > "If the two were coupled, still the > > > HA would be able to launch a DoS on the AAA server > > > and bombard it with authentication and authorization > > > requests." > > > > > > If the authentication failed, then there would be no > > > authorization. > > > > AFAICS the mechanism you want to provide protect from a > > rogue HA. If the HA is rogue it can ask for > > authorization request when it wants. It doesn't need > > authentication to succeed for that. > > > > > "The AAA server isn't really in control of who gets > > > the mobility server and who doesn't since at the end > > > this is up to the HA to provide the service or not." > > > > > > AAA server is the authority that authorizes the > > > resource, it does not police the resource usage, > > > since it is not on the path, but we are talking > > > about authorization not policing. > > > > > > You can feel free to stop the conversation if you > > > want. The solution to the problem is pretty simple, > > > the MN simply signs the trigger for the service > > > request. So instead of getting you frustrated, I > > > will just work to see if I can get the draft out. > > > > The solution to this discussion is pretty simple too: > > What is the problem? :) > > > > --julien > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Jan 21 09:38:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8dqC-0001hV-6k; Sun, 21 Jan 2007 09:38:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8dqB-0001hQ-Fj for dime@ietf.org; Sun, 21 Jan 2007 09:38:39 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H8dqA-0001QM-0N for dime@ietf.org; Sun, 21 Jan 2007 09:38:39 -0500 Received: (qmail invoked by alias); 21 Jan 2007 14:38:35 -0000 Received: from p54987103.dip.t-dialin.net (EHLO [192.168.178.21]) [84.152.113.3] by mail.gmx.net (mp028) with SMTP; 21 Jan 2007 15:38:35 +0100 X-Authenticated: #29516787 Message-ID: <45B37AEB.2040102@gmx.net> Date: Sun, 21 Jan 2007 15:38:35 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: "Morrow, Glenn" Subject: Re: [Dime] Supplicant X.509 AVP? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 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 Glenn, Thanks for raising security questions. Let me describe three different usage scenarios and you tell me which one you have in mind: 1) Security protection between neighboring Diameter entities 2) Security protection between the Diameter client and the Diameter server 3) Establishment of security associations between an end host and the Diameter client Ad 1) The classical solution is to use TLS or IPsec. See the Security Considerations section in http://www.ietf.org/rfc/rfc3588.txt Ad 2) A solution was once proposed that uses certificates as part of CMS. This work was done as part of the AAA working group but stopped due to lack of interest. Here is the latest document: http://tools.ietf.org/wg/aaa/draft-ietf-aaa-diameter-cms-sec/draft-ietf-aaa-diameter-cms-sec-04.txt The main benefit of CMS is to digitally sign or encrypt AVPs in an end-to-end fashion between the Diameter client and the Diameter server. Ad 3) This solution is an entirely different usage scenario and might, for example, be used for network access authentication where the user/end host is authenticated to the Diameter Server (or EAP server) via the Authenticator (Diameter client). If network access authentication was successful then the Diameter Server (or EAP server) transports keying material to the Diameter Client and uses it in a subsequent protocol exchange between the end host and the Diameter client. For network access a number of documents are available and you might want to look at: * Diameter Network Access Server Application http://www.ietf.org/rfc/rfc4005.txt * Diameter Extensible Authentication Protocol (EAP) Application http://www.ietf.org/rfc/rfc4072.txt * Extensible Authentication Protocol (EAP) Key Management Framework: http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-16.txt * EAP (see http://www.ietf.org/rfc/rfc3748.txt) and various EAP methods Ciao Hannes > -----Ursprüngliche Nachricht----- > Von: Morrow, Glenn [mailto:Glenn.Morrow@qwest.com] > Gesendet: Freitag, 19. Januar 2007 16:26 > An: dime@ietf.org > Betreff: [Dime] Supplicant X.509 AVP? > > Greetings to all, > > We'd like to begin exploring the use of certificates as > credentials for > several AAA applications and would prefer to use the keying > material for > integrity and authentication at the application signaling > level itself. > The flows for this type of deployment and thus application latency of > application setup are greatly reduced (no need for yet > another SA setup > and message exchange to yet another network entity such as a secure > directory/repository for public certs, No EAP-TLS overhead) if the > certificates are transpoted over Diameter from the server to > the client. > > I'd like to float this concept to the WG and see if others > have existing > or planned implementations and would like to colloborate on an ID to > define a supplicant certificate AVP to be a base Diameter AVP > such that > it could be used for any Diameter application. I have not floated this > to the Radius extension WG due to the UDP transport. I think that if > Radius is used, the EAP-TLS or a separate directory lookup from the > client is the only option available. There should be no such > limitation > on Diameter though. > > Thanks, > Glenn > > > This communication is the property of Qwest and may contain > confidential or > privileged information. Unauthorized use of this > communication is strictly > prohibited and may be unlawful. If you have received this > communication > in error, please immediately notify the sender by reply > e-mail and destroy > all copies of the communication and any attachments. > > _______________________________________________ > 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 Jan 22 03:21:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8uQp-00071h-PD; Mon, 22 Jan 2007 03:21:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8uQo-0006xb-Iz for dime@ietf.org; Mon, 22 Jan 2007 03:21:34 -0500 Received: from cluster-e.mailcontrol.com ([217.79.216.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8uQj-0007bX-Oc for dime@ietf.org; Mon, 22 Jan 2007 03:21:34 -0500 Received: from c2-ex002.groupinfra.com ([212.123.206.142]) by rly32e.srv.mailcontrol.com (MailControl) with ESMTP id l0M8HgnY007347 for ; Mon, 22 Jan 2007 08:21:22 GMT Received: from in-ex002.groupinfra.com ([158.234.200.107]) by c2-ex002.groupinfra.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Jan 2007 09:17:26 +0100 Received: from in-ex001.groupinfra.com ([158.234.200.12]) by in-ex002.groupinfra.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Jan 2007 13:47:24 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 22 Jan 2007 13:47:23 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Stack Configuration parameters Thread-Index: Acc9/b68KoNoW7HMRF+JJwJjcMgRgA== From: "Rawat, Himanshu" To: X-OriginalArrivalTime: 22 Jan 2007 08:17:24.0361 (UTC) FILETIME=[BEFCD790:01C73DFD] X-Scanned-By: MailControl A-07-06-80 (www.mailcontrol.com) on 10.69.0.142 X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Subject: [Dime] Stack Configuration parameters 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="===============0573626554==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0573626554== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73DFD.BF07C889" This is a multi-part message in MIME format. ------_=_NextPart_001_01C73DFD.BF07C889 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 1) Can anybody tell me "What are the Diameter Stack Configuration Parameters required for initializing the stack with Ro client" w.r.t Voice, for e.g. Request Timeout, TLS, and Watchdog timeout? =20 2) Can anybody throw some light on Thread management? =20 =20 =20 Thanks & Regards Himanshu Rawat =20 "Anyone who has never made a mistake has never tried anything new" =20 This e-mail and any attachment is for authorised use by the intended recipi= ent(s) only. It may contain proprietary material, confidential information = and/or be subject to legal privilege. It should not be copied, disclosed to= , retained or used by, any other party. If you are not an intended recipien= t then please promptly delete this e-mail and any attachment and all copies= and inform the sender. Thank you. ------_=_NextPart_001_01C73DFD.BF07C889 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

1) Can anybody tell me “What are the Diameter Stac= k Configuration Parameters required for initializing the stack with Ro client” w.r.t Voice, for e.g. Request Timeout, TLS, and Watchdog timeout?

 

2) Can anybody throw some light on Thread management?

 

 

 

Thanks & Regards

Hi= manshu Rawat<= /o:p>

 

<= span style=3D'font-size:12.0pt;color:navy'>"Anyone who has never made a mis= take has never tried anything new"

 



This e-mail and= any attachment is for authorised use by the intended recipient(s) only. It= may contain proprietary material, confidential information and/or be subje= ct to legal privilege. It should not be copied, disclosed to, retained or u= sed by, any other party. If you are not an intended recipient then please p= romptly delete this e-mail and any attachment and all copies and inform the= sender. Thank you.

------_=_NextPart_001_01C73DFD.BF07C889-- --===============0573626554== 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 --===============0573626554==-- From dime-bounces@ietf.org Mon Jan 22 10:36:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H91DY-0002fv-9Y; Mon, 22 Jan 2007 10:36:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H91DW-0002fp-Sk for dime@ietf.org; Mon, 22 Jan 2007 10:36:18 -0500 Received: from uswgne22.uswest.com ([204.26.87.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H91DV-0004DF-Bb for dime@ietf.org; Mon, 22 Jan 2007 10:36:18 -0500 Received: from egate-ne7.uswc.uswest.com (egate-ne7.uswc.uswest.com [151.117.69.18]) by uswgne22.uswest.com (8/8) with ESMTP id l0MFa7S3001037; Mon, 22 Jan 2007 09:36:07 -0600 (CST) Received: from itomae2ksm02.AD.QINTRA.COM (localhost [127.0.0.1]) by egate-ne7.uswc.uswest.com (8/8.13.7) with ESMTP id l0MFa6T9003623; Mon, 22 Jan 2007 09:36:06 -0600 (CST) Received: from itomae2km03.AD.QINTRA.COM ([10.6.9.152]) by itomae2ksm02.AD.QINTRA.COM with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Jan 2007 09:36:06 -0600 X-MessageTextProcessor: DisclaimIt (2.70.270) [Qwest Communications International Inc.] X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 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] Supplicant X.509 AVP? Date: Mon, 22 Jan 2007 09:36:05 -0600 Message-ID: In-Reply-To: <45B37AEB.2040102@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Supplicant X.509 AVP? thread-index: Acc9i2IhUMpmDMG3TcmfC5AoU7EeSgAqjwFg From: "Morrow, Glenn" Importance: normal Priority: normal To: "Hannes Tschofenig" X-OriginalArrivalTime: 22 Jan 2007 15:36:06.0951 (UTC) FILETIME=[08795370:01C73E3B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Hannes, The decription on Scenario 3 is similar to what we are looking for i.e. we want to apply assymetric cryptography enabled via certs directly to the real signaling application (whatever it is) that Diameter is AAAing without the extra signaling latency overhead of an EAP-TLS server or another SA setup with a cert directory from the Diameter client or end-application itself. As a simple example, if we had a UDP application that had a client component and a network server component, We want the UDP application client to sign their packet with their private key and send the message to the network server component.=20 We then want the Diameter client (co-resident with the network server component) to retrieve the public key from a Diameter server which then retrieves it from a cert directory or whatever PKI backend solution there is and relay it down to the Diameter client along with any additional application specific authorization information for the end-user application. =20 The Diameter client then passes this information to the network server component of the application which then uses the public key in the public cert to check the integrity of the UDP application packet and authenticate the supplicant (end-user/device/whatever). Once authenticated the authorization policies of both the public cert and any Diameter application policies are allowed/enforced.=20 We are quite happy with existing Diameter to Diameter server/client security and transport i.e. scenario 1. Again - we want to avoid the extra signaling latency overhead of an EAP-TLS server or another SA setup with a cert directory from the Diameter client or end-application itself. Passing the public cert down is far more efficient and greatly improves the application setup delay. Please let me know if this clarifies the terminology and what we are looking for. Thanks, Glenn This communication is the property of Qwest and may contain confidential = or privileged information. Unauthorized use of this communication is = strictly=20 prohibited and may be unlawful. If you have received this communication = in error, please immediately notify the sender by reply e-mail and = destroy=20 all copies of the communication and any attachments. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jan 22 12:11:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H92h8-000487-TA; Mon, 22 Jan 2007 12:10:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H92h8-00047q-7K for dime@ietf.org; Mon, 22 Jan 2007 12:10:58 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H92h6-0004Gw-OI for dime@ietf.org; Mon, 22 Jan 2007 12:10:58 -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 l0MH33w22770; Mon, 22 Jan 2007 12:03:04 -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: Issue or not Issue ? Date: Mon, 22 Jan 2007 11:10:39 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437112570CE8@zrc2hxm2.corp.nortel.com> In-Reply-To: <5e2406980701200410q1b8274f4m4dc526f64ea851d3@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Issue or not Issue ? Thread-index: Acc8i/jQSIlecpxFQwu6I4WjVGaYrABo3a2w From: "Ahmad Muhanna" To: "Julien Bournelle" X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Cc: dime@ietf.org, Julien Laganier 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, Please see my comments inline. Regards, Ahmad =20 > -----Original Message----- > From: Julien Bournelle [mailto:julien.bournelle@gmail.com]=20 > Sent: Saturday, January 20, 2007 6:10 AM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: Julien Laganier; dime@ietf.org > Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support:=20 > Issue or not Issue ? >=20 > Hi Ahmad, >=20 > let me answer to your comments >=20 > On 1/19/07, Ahmad Muhanna wrote: > > > > > First of all, I think that such an attack isn't caused by=20 > decoupling=20 > > > of AAAn and AAAz. It is caused by the rogue HA flooding a AAA=20 > > > server. > > > > > > Second, I do not think how the AAAz would be protected from a=20 > > > flooding attack launched by a rogue HA if it had a "proof of=20 > > > authentication at AAAn [...] provided by either MN or=20 > AAAn". AFAIK=20 > > > authentication does not protect from flooding. > > > > [Ahmad] > > If the proposed solution requires the HA to provide authentication=20 > > material to AAAz to ensure that MN has been authenticated, the AAAz=20 > > will have the chance to drop these Authorization Requests if=20 > > authentication material is not authentic, which I assume it=20 > is not in this scenario. >=20 > i'm not sure to well understand your comment. Which=20 > "proposed solution" ? [Ahmad] So far there is no proposed solution, but I think at one point long time back and probably on this thread there was a discussion which briefly mentioned from High Level that the HA needs to provide AAAz a token/something to prove that this user has been authenticated/Authentic. > Moreover, I would say that this not the role of the AAAz to=20 > perform a kind of authentication.=20 [Ahmad] To some extent I agree. However, AAAz does not need to authenticate the user rather it needs to be offered an assurance that this user has been authentication. I think this is a side effect of decoupling the Authentication and Authorization processes. > The HA needs to know if=20 > the user is the person she claimed to be: it uses the AAAn for this. Then, it needs to know if the user is > authorized: it uses > the AAAz for this. If we want the AAAz to know if the user is=20 > authenticated, we shouldn't decoupled the 2 process. [Ahmad] We are probably splitting hair here, apparently there are two arguments here: 1. AAAz is an authorization server and since it has a security relationship with the HA, AAAz relies on the HA to do two things:=20 1.1. HA makes sure that the user has been authenticated by AAAn.=20 1.2. HA will not send any Authorization requests for any user(s) who has not been authenticated. (In normal conditions, the above two conditions are ALWAYS TRUE except in one condition, HA has been compromised)=20 2. AAAz is an authorization server and has a security association with the HA, however, due to the fact that the HA could be compromised, a process needs to be in place for the HA to ALWAYS provide the AAAz, Authorization server, with a proof (token, etc.) that the user has been authenticated by AAAn. I assume here that the difference in opinion is about the possibility of the HA to be compromised or NOT. Because due to the decoupling of Authentication and Authorization processes and using different application IDs, I clearly see an issue when HA is compromised which does not exist if Authorization and Authentication are not decoupled. I agree with you, we have two options here: 1. If Authorization and Authentication processes are NOT decoupled, then this issue goes away. 2. In the case of decoupling Authorization and Authentication, we clearly need to highlight the new security risk/vulnerability introduced by decoupling and provide a solution. In the case that vulnerability is not applicable to any deployment, then that solution becomes an optional/not-needed one. (I am not sure what is the problem with this approach.) >=20 > > Also, if AAAz receives too many of these Requests from the same HA,=20 > > AAAz can close the connection to the HA or just ignore all of its traffic. >=20 > right [Ahmad] Thanks Julien. It seems you agree that AAAz can do this to avoid this attack by a compromised HA; then I assume that you agree decoupling the Authentication and Authorization processes introduces a security vulnerability/risk in the case when HA is compromised which does not exist if both Authentication and Authorization processes are not decoupled. Right? > > > > Theoretically, I agree with Madjid that there is an issue=20 > that needs=20 > > to be addressed. >=20 > I'm still not convinced. [Ahmad] Please see my comments above. I hope it helps in clarifying the issue. >=20 > > On the other hand, we need to assess the possibility for=20 > this security=20 > > vulnerability to happen in the field and make an educated=20 > decision to=20 > > address it or not. One more thing, we can recognize the issue and=20 > > provide an optional solution that any deployment which does not=20 > > guarantee that HA wont be comprised Shall implement the proposed=20 > > solution. Just an idea. >=20 > that's indeed the question: do we introduce a threat here ?=20 > or in other terms do we have an issue here ? >=20 > I think no. Madjid and you think "yes". >=20 > We clearly need a way to move forward but I don't think we=20 > (as a WG) can say: if you think there is an issue then use=20 > this optional mechanism, if you don't think it is an issue=20 > then you don't need this optional mechanism. >=20 > We must know if it is an issue or not. >=20 > regards, >=20 > --Julien (B.) >=20 > > > > > > > > > > > As far as you other statements: > > > > "At the HA, there is assurance that the peer is authenticated=20 > > > > since it just checked if it was. " > > > > > > > > I don't think assurance at HA is relevant for AAAz,=20 > since HA was=20 > > > > not involved in EAP. > > > > > > But HA is involved in the EAP exchange! It acts as a=20 > passtrough, and=20 > > > gets authentication assurance from AAAn. > > > > > > > "If the two were coupled, still the HA would be able to=20 > launch a=20 > > > > DoS on the AAA server and bombard it with authentication and=20 > > > > authorization requests." > > > > > > > > If the authentication failed, then there would be no=20 > > > > authorization. > > > > > > AFAICS the mechanism you want to provide protect from a=20 > rogue HA. If=20 > > > the HA is rogue it can ask for authorization request when=20 > it wants.=20 > > > It doesn't need authentication to succeed for that. > > > > > > > "The AAA server isn't really in control of who gets the=20 > mobility=20 > > > > server and who doesn't since at the end this is up to the HA to=20 > > > > provide the service or not." > > > > > > > > AAA server is the authority that authorizes the=20 > resource, it does=20 > > > > not police the resource usage, since it is not on the=20 > path, but we=20 > > > > are talking about authorization not policing. > > > > > > > > You can feel free to stop the conversation if you want. The=20 > > > > solution to the problem is pretty simple, the MN simply=20 > signs the=20 > > > > trigger for the service request. So instead of getting you=20 > > > > frustrated, I will just work to see if I can get the draft out. > > > > > > The solution to this discussion is pretty simple too: > > > What is the problem? :) > > > > > > --julien > > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jan 22 15:41:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H95yJ-0003lu-AW; Mon, 22 Jan 2007 15:40:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H95yI-0003jx-Ms for dime@ietf.org; Mon, 22 Jan 2007 15:40:54 -0500 Received: from uswgco34.uswest.com ([199.168.32.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H95yG-000630-BG for dime@ietf.org; Mon, 22 Jan 2007 15:40:54 -0500 Received: from egate-co5.uswc.uswest.com (egate-co5.uswc.uswest.com [151.119.87.232]) by uswgco34.uswest.com (8/8) with ESMTP id l0MKeiiZ010295; Mon, 22 Jan 2007 13:40:44 -0700 (MST) Received: from itomae2ksm02.AD.QINTRA.COM (localhost [127.0.0.1]) by egate-co5.uswc.uswest.com (8/8.13.7) with ESMTP id l0MKehmx005453; Mon, 22 Jan 2007 13:40:43 -0700 (MST) Received: from itomae2km03.AD.QINTRA.COM ([10.6.9.152]) by itomae2ksm02.AD.QINTRA.COM with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Jan 2007 14:40:43 -0600 X-MessageTextProcessor: DisclaimIt (2.70.270) [Qwest Communications International Inc.] X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 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] Supplicant X.509 AVP? Date: Mon, 22 Jan 2007 14:40:42 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Supplicant X.509 AVP? thread-index: Acc9i2IhUMpmDMG3TcmfC5AoU7EeSgAqjwFgAAvcpdA= From: "Morrow, Glenn" Importance: normal Priority: normal To: "Hannes Tschofenig" X-OriginalArrivalTime: 22 Jan 2007 20:40:43.0257 (UTC) FILETIME=[96004E90:01C73E65] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org We also want to avoid the overhead of having the applications send the public certificate for the supplicant in the application signaling.=20 -----Original Message----- From: Morrow, Glenn=20 Sent: Monday, January 22, 2007 8:36 AM To: 'Hannes Tschofenig' Cc: dime@ietf.org Subject: RE: [Dime] Supplicant X.509 AVP? Hi Hannes, The decription on Scenario 3 is similar to what we are looking for i.e. we want to apply assymetric cryptography enabled via certs directly to the real signaling application (whatever it is) that Diameter is AAAing without the extra signaling latency overhead of an EAP-TLS server or another SA setup with a cert directory from the Diameter client or end-application itself. As a simple example, if we had a UDP application that had a client component and a network server component, We want the UDP application client to sign their packet with their private key and send the message to the network server component.=20 We then want the Diameter client (co-resident with the network server component) to retrieve the public key from a Diameter server which then retrieves it from a cert directory or whatever PKI backend solution there is and relay it down to the Diameter client along with any additional application specific authorization information for the end-user application. =20 The Diameter client then passes this information to the network server component of the application which then uses the public key in the public cert to check the integrity of the UDP application packet and authenticate the supplicant (end-user/device/whatever). Once authenticated the authorization policies of both the public cert and any Diameter application policies are allowed/enforced.=20 We are quite happy with existing Diameter to Diameter server/client security and transport i.e. scenario 1. Again - we want to avoid the extra signaling latency overhead of an EAP-TLS server or another SA setup with a cert directory from the Diameter client or end-application itself. Passing the public cert down is far more efficient and greatly improves the application setup delay. Please let me know if this clarifies the terminology and what we are looking for. Thanks, Glenn This communication is the property of Qwest and may contain confidential = or privileged information. Unauthorized use of this communication is = strictly=20 prohibited and may be unlawful. If you have received this communication = in error, please immediately notify the sender by reply e-mail and = destroy=20 all copies of the communication and any attachments. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jan 22 16:16:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H96Wx-0001Mp-0b; Mon, 22 Jan 2007 16:16:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H96Wv-0001Mi-Jt for dime@ietf.org; Mon, 22 Jan 2007 16:16:41 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H96Wt-0000Hc-4s for dime@ietf.org; Mon, 22 Jan 2007 16:16:41 -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 42FAE0B603 for ; Mon, 22 Jan 2007 15:57:43 -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 l0MKvgu2027363 for ; Mon, 22 Jan 2007 15:57:42 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] The Auditing Problem: Possible approaches Date: Mon, 22 Jan 2007 15:53:53 -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) Importance: Normal In-Reply-To: <33656995C5C5094A983DE84DA649A924EB12F9@lulex02.ad.operax.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 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 Ulf, Hannes and all, I feel like now we are ready for detailed investigation/documentation of the problems/choices we discussed. What would be a good way to proceed, producing drafts? If so, what would be the content? To me it makes sense to start with a draft which explains different choices, their applicability and how they handle different functional aspects (notification of clients, transfer of session data, load distribution etc...) Some of the methods described may require separate drafts defining new messages/AVPs. Another alternative is to continue discussing with e-mail messages on the list but I think this started to get a little bit hard to follow and we may loose track of issues discussed. Thanks, Tolga > > i- Client triggered refresh upon expiry of a timer on the client This is > essentially the soft state case, where the client can send a message to > an alternate server after expiry of a protocol timer with enough > information embedded in the message, so that the alternate server can > process it. > > [Ulf2] Yes. > > ii- Client triggered refresh upon receipt of an error answer Similar to > i-, except that it is triggered upon receip of an "UNABLE_TO_DELIVER" > error answer. > > [Ulf2] Question for clarificaiton; would this mean to refresh all > session states associated with the target that could not be reached, or > just the session for which the error was given? > > iii- Peer triggered state data transfer upon receipt of a notification > from a peer This is the approach described in the > draft-calhoun-diameter-res-mgmt-08.txt > > [Ulf2] Ok. > > iv- Peer triggered refresh > This is similar to iii- but relies on the application messages to > rebuild the state. A notification message is sent from a peer informing > the client that a server went down. The client refreshes sessions on the > alternate server. The message can be sent immediately after receiving > the notification or could be delayed till the corresponding session(s) > actually require a message to be sent to update/delete. > > [Ulf2] Ok. What come to my mind though is the amount of messages that'll > be generated (this concern applies also to ii in case all session states > are to be refreshed). In my view some recommendations on how to control > the rate of messages and/or to make it driven by a receiver of the > updates would be needed. I might be jumping ahead too quick to the > solution now though. > > i and ii seem to work with existing Diameter wisdom, but they may run > into issues, if servers also generate autonomous requests to clients > (actually this would probably answer the question I asked in a previous > message about the necessity of resurrection sessions/states on backup > servers immediately after they take over the role of a failed host) > > [Ulf2] Yes, autonomous requests/unsolicited call backs is a reason for > resurrection sessions/states on backup servers. I believe an additional > reason for why states should for some applications be resurrected is > that the application are controlling access to scarce resources (e.g. > RACS). > > For iii and iv, a backup peer needs to know which clients it needs to > send a notification to. This probably can be synchronized between peers > of a cluster. > > [Ulf2] Yes. > > It could be useful to think over different alternatives considering the > RACS scenario. For RACS, which interface are we talking about, Gq', Rq , > any or both? > > [Ulf2] I'm considering both Gq' and Rq as well as the corresponding > interfaces as of ITU and 3GPP. I believe all your list items to > applicable to those interfaces. Which specific approach that'll be > adopted for each individual deployment (and by different vendors) > remains to be seen. My personal belief is that most A-RACF entities (the > part of RACS performing admission control) will replicate both session > and reservation states. The A-RACF is likely to offer soft-state only to > the SPDF (the part of RACS facing application frameworks such as e.g. > SIP proxies). The SPDF will probably also replicate states and offer > soft-state to its clients. The SPDF is however likely to also offer > hard-state to some application frameworks (e.g. leased line application > level servers). > > Given the above assumptions i and ii will be used without complete > information in refresh messages to rebuld states. In addition, iii will > be used to ensure syncronisation after failover (and potentially > periodically between application and SPDF in the case of hard-state). > Since states are replicated iv would not apply (if I understand the > approach correctly it applies to non cases when data is not replicated > only). However, for a deployment without replication for e.g. the A-RACF > iv would however apply. > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jan 23 04:42:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9IAM-0004HV-0H; Tue, 23 Jan 2007 04:42:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9IAK-0004G2-Nl for dime@ietf.org; Tue, 23 Jan 2007 04:42:08 -0500 Received: from an-out-0708.google.com ([209.85.132.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9IAI-0007Ux-Ak for dime@ietf.org; Tue, 23 Jan 2007 04:42:08 -0500 Received: by an-out-0708.google.com with SMTP id d30so567305and for ; Tue, 23 Jan 2007 01:42:06 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=H1f1gb8q7b8aKJ+zQv6X5tL8023eqf59tTvuB872o8kJD1J+R6neas/7BltB3RfactVmyijcu+orgSpY4WdgWSQgfF9ZXNZK0lD2j2goEhaSCEHUMaGcjZiKWRD7HL54WCmZX5gMFsDO68S7450ZFAhBrtIM85YvMvdAVuTePk4= Received: by 10.78.149.15 with SMTP id w15mr214667hud.1169545323356; Tue, 23 Jan 2007 01:42:03 -0800 (PST) Received: from ?192.168.1.102? ( [212.119.9.178]) by mx.google.com with ESMTP id 32sm7616184hui.2007.01.23.01.42.01; Tue, 23 Jan 2007 01:42:02 -0800 (PST) From: Julien Laganier To: "Ahmad Muhanna" Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Issue or not Issue ? Date: Tue, 23 Jan 2007 10:41:58 +0100 User-Agent: KMail/1.8.2 References: <6FC4416DDE56C44DA0AEE67BC7CA437112570CE8@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437112570CE8@zrc2hxm2.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701231041.58700.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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, Cutting a bit thru your message, I have some comments below: On Monday 22 January 2007 18:10, Ahmad Muhanna wrote: > > >[...] > > [Ahmad] > We are probably splitting hair here, apparently > there are two arguments here: I don't think this is hair splitting. Understand the issue should be a prerequisite to solving it. > 1. AAAz is an authorization server and since it has > a security relationship with the HA, AAAz relies on > the HA to do two things: 1.1. HA makes sure that the > user has been authenticated by AAAn. 1.2. HA will > not send any Authorization requests for any user(s) > who has not been authenticated. > > (In normal conditions, the above two conditions are > ALWAYS TRUE except in one condition, HA has been > compromised) Right. So we both agree there's no problem unless the HA is compromised I think what the first step is to agree on a threat model. I do not agree that we should defend against a compromised HA. The HA should be deemed secure against attackers. We have to place a limit on what is entity X when asking the question "what if entity X is compromised". Since nothing is really impossible in the real world, we cannot defend against compromission of any entity implicated in a protocol. Security is a tradeoff. More below... > 2. AAAz is an authorization server and has a > security association with the HA, however, due to > the fact that the HA could be compromised, a process > needs to be in place for the HA to ALWAYS provide > the AAAz, Authorization server, with a proof (token, > etc.) that the user has been authenticated by AAAn. OK, if HA can be compromised. But why are we stopping here? Why not considering the case where the AAAn is compromised? Is is it more likely for an HA to be compromised than for a AAAn? We really have to agree on a threat model first. > I assume here that the difference in opinion is > about the possibility of the HA to be compromised or > NOT. Exactly. Best, --julien (L.) _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jan 23 06:35:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9JwR-0001w7-FM; Tue, 23 Jan 2007 06:35:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9JwQ-0001vz-MH for dime@ietf.org; Tue, 23 Jan 2007 06:35:54 -0500 Received: from ceiling.dave.sonera.fi ([131.177.130.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9JwD-0006BC-9L for dime@ietf.org; Tue, 23 Jan 2007 06:35:54 -0500 Received: from ceiling.dave.sonera.fi (localhost [127.0.0.1]) by ceiling.dave.sonera.fi (Sendmail) with ESMTP id l0NBZXS1006187 for ; Tue, 23 Jan 2007 13:35:33 +0200 (EET) Received: from [131.177.107.100] (ws400.secureuser.sonera.fi [131.177.107.100]) by ceiling.dave.sonera.fi (Sendmail) with ESMTP id l0NBZSF4006170 for ; Tue, 23 Jan 2007 13:35:33 +0200 (EET) Message-ID: <45B5F2FC.2030102@teliasonera.com> Date: Tue, 23 Jan 2007 13:35:24 +0200 From: Jouni Korhonen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) 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: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Dime] New I-D: draft-ietf-dime-mip6-integrated-02 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, A new -02 version of the MIP6 integrated bootstrapping draft has been submitted to the I-D repository. Before the draft shows up in the official place it is available at url: http://www.tschofenig.priv.at/svn/draft-ietf-dime-mip6-integrated/draft-ietf-dime-mip6-integrated-02.txt Changes since -01 are shortly: o Section 8 NAS - HAAA Interface AVPs flags. 'M' flag was listed as MUST even if it should have been MUST NOT. o General shortening of the text. o Addition of the MIP6-Home-Address AVP. o Checked against draft-ietf-mip6-radius-01 (no complete overlap) o Addition of noted & constrains to AVP tables. o Miscellaneous corrections like Mobile IPv6 -> MIPv6. o Added signaling examples for HA assignment from MSP, and local HA assignment. Cheers, Jouni _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jan 23 10:12:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9NK7-0006Xs-LG; Tue, 23 Jan 2007 10:12:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9NK6-0006XY-Al for dime@ietf.org; Tue, 23 Jan 2007 10:12:34 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9NK5-0002A6-Q3 for dime@ietf.org; Tue, 23 Jan 2007 10:12:34 -0500 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jan 2007 16:11:52 +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 Mobile IPv6 HA-to-AAAH Support: Issue or notIssue ? Date: Tue, 23 Jan 2007 16:11:49 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026043BC087@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Issue or notIssue ? thread-index: Acc+0s22USDiJddWShOfYJVGYuMU3QACXRGw From: "MORAND Lionel RD-CORE-ISS" To: "Julien Laganier" , "Ahmad Muhanna" X-OriginalArrivalTime: 23 Jan 2007 15:11:52.0798 (UTC) FILETIME=[D024EFE0:01C73F00] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd 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 Folks, There is a new guy in the game ;) After reviewing the draft and the mail exchange on the topic, I would = say that the conclusion on "issue/no issue" depends on the side you are = considering the problem (as often ;). If you are considering the AAA-MIP6 as a "simple" database providing the = HA with specific user/service information after a separate = authentication (performed with Diameter authentication), the username = conveyed over the HA/AAA-MIP6 is just used as a key entry in the = database. There is no need for the AAA-MIP6 to authenticate this = username or to be sure that the username was previously authenticated. = The client of the database is the HA and not the user. In that case, the = AAA-MIP6 has to trust the HA and it is up to the HA to authenticate the = username provided by the mn during the SA set-up. This could be compared = to interfaces between HSS (Home Subscriber Server) and SIP application = servers defined in the 3GPP architecture, over which Diameter = applications are used to access database. =20 In this context, the HA may use: 1) the Diameter EAP application to authenticate the user. =20 2) the Diameter MIP6 application to download user related service = information Authentication and authorization are performed by the AAA-EAP. But there = is no way for the AAA-EAP to know what is the service requested by the = user. Successful authentication implies implicte authorization. This is = the problem with Diameter EAP as it is not possible to route Diameter = EAP request to a service-specific EAP server. In another hand, if the AAA-MIP6 is an authority handling MIP6 service = access authorization rights i.e. the AAA-MIP6 must verify that the user = is authorized to use the Mobile IPv6 service, this authority has to be = able to verify the identity of the user before authorizing this user to = access the service. It is not possible to authorize someone to do = something without being sure of its identity as the authority must stand = surety of the user access rights. Now, it is not possible to rely on the = Diameter EAP application to perform the authentication procedure as = there is no way to direct the Diameter EAP requests to a specifc EAP = server (as the Diameter routing is based on App-Id and Realm). We might = think about some specific things to link authentication procedures and = authorization/service profile handling. But for me, the simpliest way = would be to define the required authentication mechanism within one and = only one application i.e. the application that requires this = authentication. Therefore, Diameter EAP would not be used and = application-specific commands would be specified in the application. One = command pair would be added to the Diameter MIP6 application. And to = support EAP, AVPs defined in 4072 would be at least (re-)used. IMHO, the context described in the draft looks like more a service = access authorization management than the use of a simple external = database. I would be therefore in favor of defining authentication = commands within the Diameter MIP6 application instead of trying to reuse = the Diameter EAP application, which is not possible without = modifications. EAP authentication and MIP6 service access authorization = are performed with the same application. Since a application-Id is = whatever needed for the HA/AAA-MIP6, what would be the benefit to look = for solutions binding Diameter EAP and Diameter MIP6 (with some key = derivation, etc.) while a single Diameter MIP6 application with = intrinsic authentication commands would be fully appropriate? I'm pretty sure that the content of this mail may be challenged line by = line ;) But at the end, if authentication and authorization are needed = to provide MIP6 services, why do not having a single application to do = it? Of course, I don't say that it would not be possible to do something = more complex... BR, Lionel > -----Message d'origine----- > De : Julien Laganier [mailto:julien.IETF@laposte.net]=20 > Envoy=E9 : mardi 23 janvier 2007 10:42 > =C0 : Ahmad Muhanna > Cc : dime@ietf.org > Objet : Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support:=20 > Issue or notIssue ? >=20 > Hi Ahmad, >=20 > Cutting a bit thru your message, I have some comments > below: >=20 > On Monday 22 January 2007 18:10, Ahmad Muhanna wrote: > > > > > >[...] > > > > [Ahmad] > > We are probably splitting hair here, apparently there are two=20 > > arguments here: >=20 > I don't think this is hair splitting. Understand the issue=20 > should be a prerequisite to solving it. >=20 > > 1. AAAz is an authorization server and since it has a security=20 > > relationship with the HA, AAAz relies on the HA to do two=20 > things: 1.1.=20 > > HA makes sure that the user has been authenticated by AAAn. 1.2. HA=20 > > will not send any Authorization requests for any user(s)=20 > who has not=20 > > been authenticated. > > > > (In normal conditions, the above two conditions are ALWAYS=20 > TRUE except=20 > > in one condition, HA has been > > compromised) >=20 > Right. So we both agree there's no problem unless the HA is=20 > compromised >=20 > I think what the first step is to agree on a threat model. I=20 > do not agree that we should defend against a compromised HA.=20 > The HA should be deemed secure against attackers. >=20 > We have to place a limit on what is entity X when asking the=20 > question "what if entity X is compromised".=20 > Since nothing is really impossible in the real world, we=20 > cannot defend against compromission of any entity implicated=20 > in a protocol. Security is a tradeoff.=20 >=20 > More below... >=20 > > 2. AAAz is an authorization server and has a security=20 > association with=20 > > the HA, however, due to the fact that the HA could be=20 > compromised, a=20 > > process needs to be in place for the HA to ALWAYS provide the AAAz,=20 > > Authorization server, with a proof (token, > > etc.) that the user has been authenticated by AAAn. >=20 > OK, if HA can be compromised. But why are we stopping here?=20 > Why not considering the case where the AAAn is compromised?=20 > Is is it more likely for an HA to be compromised than for a AAAn? >=20 > We really have to agree on a threat model first. >=20 > > I assume here that the difference in opinion is about the=20 > possibility=20 > > of the HA to be compromised or NOT. >=20 > Exactly. >=20 > Best, >=20 > --julien (L.) >=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 From dime-bounces@ietf.org Tue Jan 23 14:35:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9RQL-0003yE-84; Tue, 23 Jan 2007 14:35:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9RQK-0003xs-J6 for dime@ietf.org; Tue, 23 Jan 2007 14:35:16 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H9RQH-0002Ad-U9 for dime@ietf.org; Tue, 23 Jan 2007 14:35:16 -0500 Received: (qmail invoked by alias); 23 Jan 2007 19:35:05 -0000 Received: from p549848B0.dip.t-dialin.net (EHLO [192.168.178.21]) [84.152.72.176] by mail.gmx.net (mp041) with SMTP; 23 Jan 2007 20:35:05 +0100 X-Authenticated: #29516787 Message-ID: <45B66364.3010305@gmx.net> Date: Tue, 23 Jan 2007 20:35:00 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] The Auditing Problem: Possible approaches 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.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga, I went through the discussion thread and noticed that it is indeed a bit difficult to follow the individual issues. Your mail entitled with "[Dime] The Auditing Problem: Possible approaches" http://www1.ietf.org/mail-archive/web/dime/current/msg01196.html might be a good starting point for further descriptions. I am interested in a description that tells me: * How and who detects the failure of the server? * What messages need to be exchanged to establish the state at the new server? * What are the assumptions made with each proposal? Let us consider other protocols with respect to their ability to deal with server failure, such as: ftp://ftp.isi.edu/in-notes/rfc4507.txt http://www.ietf.org/internet-drafts/draft-sheffer-ike-session-resumption-00.txt http://www.ietf.org/internet-drafts/draft-vidya-ipsec-failover-ps-00.txt The first two documents explain a procedure to quickly establish state at a new server after the old server failed based on an encrypted ticket that is sent to the client and presented at the new server during session setup. Ciao Hannes Tolga Asveren wrote: > Hi Ulf, Hannes and all, > > I feel like now we are ready for detailed investigation/documentation of the > problems/choices we discussed. > > What would be a good way to proceed, producing drafts? If so, what would be > the content? To me it makes sense to start with a draft which explains > different choices, their applicability and how they handle different > functional aspects (notification of clients, transfer of session data, load > distribution etc...) Some of the methods described may require separate > drafts defining new messages/AVPs. > > Another alternative is to continue discussing with e-mail messages on the > list but I think this started to get a little bit hard to follow and we may > loose track of issues discussed. > > Thanks, > Tolga > > >> i- Client triggered refresh upon expiry of a timer on the client This is >> essentially the soft state case, where the client can send a message to >> an alternate server after expiry of a protocol timer with enough >> information embedded in the message, so that the alternate server can >> process it. >> >> [Ulf2] Yes. >> >> ii- Client triggered refresh upon receipt of an error answer Similar to >> i-, except that it is triggered upon receip of an "UNABLE_TO_DELIVER" >> error answer. >> >> [Ulf2] Question for clarificaiton; would this mean to refresh all >> session states associated with the target that could not be reached, or >> just the session for which the error was given? >> >> iii- Peer triggered state data transfer upon receipt of a notification >> from a peer This is the approach described in the >> draft-calhoun-diameter-res-mgmt-08.txt >> >> [Ulf2] Ok. >> >> iv- Peer triggered refresh >> This is similar to iii- but relies on the application messages to >> rebuild the state. A notification message is sent from a peer informing >> the client that a server went down. The client refreshes sessions on the >> alternate server. The message can be sent immediately after receiving >> the notification or could be delayed till the corresponding session(s) >> actually require a message to be sent to update/delete. >> >> [Ulf2] Ok. What come to my mind though is the amount of messages that'll >> be generated (this concern applies also to ii in case all session states >> are to be refreshed). In my view some recommendations on how to control >> the rate of messages and/or to make it driven by a receiver of the >> updates would be needed. I might be jumping ahead too quick to the >> solution now though. >> >> i and ii seem to work with existing Diameter wisdom, but they may run >> into issues, if servers also generate autonomous requests to clients >> (actually this would probably answer the question I asked in a previous >> message about the necessity of resurrection sessions/states on backup >> servers immediately after they take over the role of a failed host) >> >> [Ulf2] Yes, autonomous requests/unsolicited call backs is a reason for >> resurrection sessions/states on backup servers. I believe an additional >> reason for why states should for some applications be resurrected is >> that the application are controlling access to scarce resources (e.g. >> RACS). >> >> For iii and iv, a backup peer needs to know which clients it needs to >> send a notification to. This probably can be synchronized between peers >> of a cluster. >> >> [Ulf2] Yes. >> >> It could be useful to think over different alternatives considering the >> RACS scenario. For RACS, which interface are we talking about, Gq', Rq , >> any or both? >> >> [Ulf2] I'm considering both Gq' and Rq as well as the corresponding >> interfaces as of ITU and 3GPP. I believe all your list items to >> applicable to those interfaces. Which specific approach that'll be >> adopted for each individual deployment (and by different vendors) >> remains to be seen. My personal belief is that most A-RACF entities (the >> part of RACS performing admission control) will replicate both session >> and reservation states. The A-RACF is likely to offer soft-state only to >> the SPDF (the part of RACS facing application frameworks such as e.g. >> SIP proxies). The SPDF will probably also replicate states and offer >> soft-state to its clients. The SPDF is however likely to also offer >> hard-state to some application frameworks (e.g. leased line application >> level servers). >> >> Given the above assumptions i and ii will be used without complete >> information in refresh messages to rebuld states. In addition, iii will >> be used to ensure syncronisation after failover (and potentially >> periodically between application and SPDF in the case of hard-state). >> Since states are replicated iv would not apply (if I understand the >> approach correctly it applies to non cases when data is not replicated >> only). However, for a deployment without replication for e.g. the A-RACF >> iv would however apply. >> >> >> >> _______________________________________________ >> 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 Tue Jan 23 15:50:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9SbA-0006RT-4Y; Tue, 23 Jan 2007 15:50:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Saj-0006Jd-2R; Tue, 23 Jan 2007 15:50:05 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9Sai-00064v-N3; Tue, 23 Jan 2007 15:50:05 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 0B0B026F20; Tue, 23 Jan 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H9Sag-00045L-Mu; Tue, 23 Jan 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 23 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-mip6-integrated-02.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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Mobile IPv6: NAS <-> HAAA Support Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-mip6-integrated-02.txt Pages : 27 Date : 2007-1-23 A Mobile IPv6 node requires a Home Agent address, a home address, and a security association with its Home Agent before it can start utilizing Mobile IPv6. RFC 3775 requires that some or all of these parameters are statically configured. Ongoing Mobile IPv6 bootstrapping work aims to make this information dynamically available to the Mobile Node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing authentication, authorization and accounting infrastructure. This document describes the MIPv6 bootstrapping using the Diameter Network Access Server (NAS) <-> home Authentication, Authorization and Accounting server (HAAA) interface. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-integrated-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-mip6-integrated-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dime-mip6-integrated-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-23145044.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-mip6-integrated-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-mip6-integrated-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-23145044.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Tue Jan 23 17:15:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Tvl-00063X-BW; Tue, 23 Jan 2007 17:15:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Tvk-00063P-6U for dime@ietf.org; Tue, 23 Jan 2007 17:15:52 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9Tvh-0006wN-Jf for dime@ietf.org; Tue, 23 Jan 2007 17:15:52 -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 B88D41B684 for ; Tue, 23 Jan 2007 17:15:45 -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 l0NMFhTY016098 for ; Tue, 23 Jan 2007 17:15:44 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] The Auditing Problem: Possible approaches Date: Tue, 23 Jan 2007 17:11:47 -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) Importance: Normal In-Reply-To: <45B66364.3010305@gmx.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4 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, Let me try to summarize the discussion till now (or better said my understanding of it) and try to answer your questions (Ulf, please feel free to add, correct etc...) >From functionality point of view, I see three different pieces (which probbaly will answer your first two questions and possibly the third one to some degree): 1- Notification of client about server failure a) Relying on an application layer timer The protocol specification mandates periodic messaging from client to server and use of a timer for the maximum allowed time to wait for a corresponding answer, e.g. Diameter Credit Control Application. If no answer is received in time, the server is assumed as down. This is the soft state approach. For this to work, there is no need to change anything in the base Diameter infrastructure, application protocol authors need to define the periodic messaging behavior. b) Relying on receipt of an error answer Here again we assume that the client is sending periodic requests during a session. Because mid-session requests will have a Destination-Host AVP, if an UNABLE_TO_DELIVER answer is received, this would be interpreted as the server being down. Here, we assume that Diaemter network is properly engineered, i.e. transport problems won't cause a message not being delivered successfully. This aproach is similar to a), probably will be used if Tw granularity on the message path is acceptable for the application. Again, what is needed is that application protocol authors defining periodci mid-session requests mechanism. c) A notification from the backup server When the backup server detects failure of an active server and is ready to take over its responsibilities, it sends a notification to the clients, with which the active server had ongoing sessions. The identity of such clients needs to be synchronized between active and standby servers. Currently, there is no generic message defined in Diameter for this purpose. Such a message could be defined by applications or we can have a generic one. 2- Transfer of session state data a) Using application messages Mid-session application messages can be used to transfer the state data. Applications can define an AVP to mark that certain mid-session request is a "refresh" or this could be done with a separate mid-session application message. The message should carry enough information to reconstruct session state at the server. If a special application message is used, this could carry session state for multiple sessions. b) Using a generic message A generic message can be defined to carry session data to the backup server. In this approach, although the message itself could be generic, still each application needs to define the content of the message so that it contains enough information to recosntruct the state. 3- Backup Server Selection / Load Distribution a) Backup information fed by the active server Information about backup servers could be sent to clients by the active server, when it was up and running. This information could indicate on a per session basis, which backup server should be used for that particulat session if the active server fails before the session terminates. Alternatively, a list of backup servers with priorities could be indicated, which is applicable for all sessions. b) Acceptable load fed by backup server If the backup server sendsa notification to the client ( approach c) for issue 1) ), the notification may contain number of sessions, backup server is willing to take over. c) Trial and error Client sends messages to backup server candidates. If the answer result code is not SUCCESS, it tries another one. Another important question seems to be, when does the need arise for servers to trigger the session reconstruction mechanism rather than waiting for the client to send a message for that purpose. AFAICS, we came up with two different reasons for this: a) The server needs to send autonomous requests to the client, e.g. for some type of periodic reporting b) The server needs to know about existing sessions at any given time to be able to process new sessions requests properly, e.g. so that it can know whether accepting a new reservation would exceed the available free resources (I didn't think abouth this throughly but I feel like this can be done just by relying on responses from the physical owner of resources rather than relying on Diameter session state) I checked briefly RFC4507 you mentioned. There it seems for 1- a) and b) (depending on whether the host or the application crashes), for 2- a), for 3- c) is used. What makes this problem interesting is that at the end it will be the decision of the application protocol author what counts. What we can provide is some guidelines about different protocol design choices and if we see it necesary some generic infrastructure messages/AVPs. Thanks, Tolga > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Tuesday, January 23, 2007 2:35 PM > To: Tolga Asveren > Cc: dime@ietf.org > Subject: Re: [Dime] The Auditing Problem: Possible approaches > > > Hi Tolga, > > I went through the discussion thread and noticed that it is indeed a bit > difficult to follow the individual issues. > > Your mail entitled with "[Dime] The Auditing Problem: Possible > approaches" > http://www1.ietf.org/mail-archive/web/dime/current/msg01196.html > might be a good starting point for further descriptions. > > I am interested in a description that tells me: > * How and who detects the failure of the server? > * What messages need to be exchanged to establish the state at the new > server? > * What are the assumptions made with each proposal? > > Let us consider other protocols with respect to their ability to deal > with server failure, such as: > > ftp://ftp.isi.edu/in-notes/rfc4507.txt > http://www.ietf.org/internet-drafts/draft-sheffer-ike-session-resu > mption-00.txt > http://www.ietf.org/internet-drafts/draft-vidya-ipsec-failover-ps-00.txt > > > The first two documents explain a procedure to quickly establish state > at a new server after the old server failed based on an encrypted ticket > that is sent to the client and presented at the new server during > session setup. > > Ciao > Hannes > > Tolga Asveren wrote: > > Hi Ulf, Hannes and all, > > > > I feel like now we are ready for detailed > investigation/documentation of the > > problems/choices we discussed. > > > > What would be a good way to proceed, producing drafts? If so, > what would be > > the content? To me it makes sense to start with a draft which explains > > different choices, their applicability and how they handle different > > functional aspects (notification of clients, transfer of > session data, load > > distribution etc...) Some of the methods described may require separate > > drafts defining new messages/AVPs. > > > > Another alternative is to continue discussing with e-mail > messages on the > > list but I think this started to get a little bit hard to > follow and we may > > loose track of issues discussed. > > > > Thanks, > > Tolga > > > > > >> i- Client triggered refresh upon expiry of a timer on the > client This is > >> essentially the soft state case, where the client can send a message to > >> an alternate server after expiry of a protocol timer with enough > >> information embedded in the message, so that the alternate server can > >> process it. > >> > >> [Ulf2] Yes. > >> > >> ii- Client triggered refresh upon receipt of an error answer Similar to > >> i-, except that it is triggered upon receip of an "UNABLE_TO_DELIVER" > >> error answer. > >> > >> [Ulf2] Question for clarificaiton; would this mean to refresh all > >> session states associated with the target that could not be reached, or > >> just the session for which the error was given? > >> > >> iii- Peer triggered state data transfer upon receipt of a notification > >> from a peer This is the approach described in the > >> draft-calhoun-diameter-res-mgmt-08.txt > >> > >> [Ulf2] Ok. > >> > >> iv- Peer triggered refresh > >> This is similar to iii- but relies on the application messages to > >> rebuild the state. A notification message is sent from a peer informing > >> the client that a server went down. The client refreshes > sessions on the > >> alternate server. The message can be sent immediately after receiving > >> the notification or could be delayed till the corresponding session(s) > >> actually require a message to be sent to update/delete. > >> > >> [Ulf2] Ok. What come to my mind though is the amount of > messages that'll > >> be generated (this concern applies also to ii in case all > session states > >> are to be refreshed). In my view some recommendations on how to control > >> the rate of messages and/or to make it driven by a receiver of the > >> updates would be needed. I might be jumping ahead too quick to the > >> solution now though. > >> > >> i and ii seem to work with existing Diameter wisdom, but they may run > >> into issues, if servers also generate autonomous requests to clients > >> (actually this would probably answer the question I asked in a previous > >> message about the necessity of resurrection sessions/states on backup > >> servers immediately after they take over the role of a failed host) > >> > >> [Ulf2] Yes, autonomous requests/unsolicited call backs is a reason for > >> resurrection sessions/states on backup servers. I believe an additional > >> reason for why states should for some applications be resurrected is > >> that the application are controlling access to scarce resources (e.g. > >> RACS). > >> > >> For iii and iv, a backup peer needs to know which clients it needs to > >> send a notification to. This probably can be synchronized between peers > >> of a cluster. > >> > >> [Ulf2] Yes. > >> > >> It could be useful to think over different alternatives considering the > >> RACS scenario. For RACS, which interface are we talking about, > Gq', Rq , > >> any or both? > >> > >> [Ulf2] I'm considering both Gq' and Rq as well as the corresponding > >> interfaces as of ITU and 3GPP. I believe all your list items to > >> applicable to those interfaces. Which specific approach that'll be > >> adopted for each individual deployment (and by different vendors) > >> remains to be seen. My personal belief is that most A-RACF > entities (the > >> part of RACS performing admission control) will replicate both session > >> and reservation states. The A-RACF is likely to offer > soft-state only to > >> the SPDF (the part of RACS facing application frameworks such as e.g. > >> SIP proxies). The SPDF will probably also replicate states and offer > >> soft-state to its clients. The SPDF is however likely to also offer > >> hard-state to some application frameworks (e.g. leased line application > >> level servers). > >> > >> Given the above assumptions i and ii will be used without complete > >> information in refresh messages to rebuld states. In addition, iii will > >> be used to ensure syncronisation after failover (and potentially > >> periodically between application and SPDF in the case of hard-state). > >> Since states are replicated iv would not apply (if I understand the > >> approach correctly it applies to non cases when data is not replicated > >> only). However, for a deployment without replication for e.g. > the A-RACF > >> iv would however apply. > >> > >> > >> > >> _______________________________________________ > >> 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 Wed Jan 24 02:57:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9d0B-0007T7-PO; Wed, 24 Jan 2007 02:57:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9d0A-0007Sz-GU for dime@ietf.org; Wed, 24 Jan 2007 02:57:02 -0500 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9d09-000528-UE for dime@ietf.org; Wed, 24 Jan 2007 02:57:02 -0500 Received: by ug-out-1314.google.com with SMTP id 72so87247ugd for ; Tue, 23 Jan 2007 23:56:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=iqQrzG33By3hV998D9gSyqos6cnkpV/7P7Zp5ANQ3f4LezWVcOM93SnF/VyohUHS1ldvttZiUGs5Gmgs6tG61xB+jrIp/R+kETPQQ/poq80moaqL1YQhjIUTnHjYxlZNsBtqK3oLEHAzmnZX1xvBbh9R65Qcgazuw8FnPoIpWPU= Received: by 10.66.243.2 with SMTP id q2mr662502ugh.1169625416638; Tue, 23 Jan 2007 23:56:56 -0800 (PST) Received: by 10.66.237.10 with HTTP; Tue, 23 Jan 2007 23:56:56 -0800 (PST) Message-ID: Date: Wed, 24 Jan 2007 08:56:56 +0100 From: "Gerardo Giaretta" To: "MORAND Lionel RD-CORE-ISS" Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Issue or notIssue ? In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB026043BC087@FTRDMEL2.rd.francetelecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <7DBAFEC6A76F3E42817DF1EBE64CB026043BC087@FTRDMEL2.rd.francetelecom.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: dime@ietf.org, Julien Laganier 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 agree with Lionel. The proposal of having a split between authentication and authorization was made by Yoshi in order to avoid changes to 4072 and avoid duplicating functionality between Diameter applications. However, it seems that there are more drawbacks than benefits as discussed in this month. And I don't see a strong issue in having the MIP6 Diameter application supporting both authentication and authorization. Note that if we want to add support for rfc4285, we'll have to define an authentication application for MIP6 anyway. Therefore my suggestion is: close the issue stating that the AAA servers for authentication and authorization are co-located and that the same application is used for both. Does it sound good to everybody? If not, I would like to hear strong motivations and benefits to have the servers/application split since during these months I have not heard any (a part from the documentation issue mentioned above). --Gerardo On 1/23/07, MORAND Lionel RD-CORE-ISS wr= ote: > Hi Folks, > > There is a new guy in the game ;) > > After reviewing the draft and the mail exchange on the topic, I would say= that the conclusion on "issue/no issue" depends on the side you are consid= ering the problem (as often ;). > > If you are considering the AAA-MIP6 as a "simple" database providing the = HA with specific user/service information after a separate authentication (= performed with Diameter authentication), the username conveyed over the HA/= AAA-MIP6 is just used as a key entry in the database. There is no need for = the AAA-MIP6 to authenticate this username or to be sure that the username = was previously authenticated. The client of the database is the HA and not = the user. In that case, the AAA-MIP6 has to trust the HA and it is up to th= e HA to authenticate the username provided by the mn during the SA set-up. = This could be compared to interfaces between HSS (Home Subscriber Server) a= nd SIP application servers defined in the 3GPP architecture, over which Dia= meter applications are used to access database. > > In this context, the HA may use: > 1) the Diameter EAP application to authenticate the user. > 2) the Diameter MIP6 application to download user related service informa= tion > Authentication and authorization are performed by the AAA-EAP. But there = is no way for the AAA-EAP to know what is the service requested by the user= . Successful authentication implies implicte authorization. This is the pro= blem with Diameter EAP as it is not possible to route Diameter EAP request = to a service-specific EAP server. > > In another hand, if the AAA-MIP6 is an authority handling MIP6 service ac= cess authorization rights i.e. the AAA-MIP6 must verify that the user is au= thorized to use the Mobile IPv6 service, this authority has to be able to v= erify the identity of the user before authorizing this user to access the s= ervice. It is not possible to authorize someone to do something without bei= ng sure of its identity as the authority must stand surety of the user acce= ss rights. Now, it is not possible to rely on the Diameter EAP application = to perform the authentication procedure as there is no way to direct the Di= ameter EAP requests to a specifc EAP server (as the Diameter routing is bas= ed on App-Id and Realm). We might think about some specific things to link = authentication procedures and authorization/service profile handling. But f= or me, the simpliest way would be to define the required authentication mec= hanism within one and only one application i.e. the application that requir= es this authentication. Therefore, Diameter EAP would not be used and appli= cation-specific commands would be specified in the application. One command= pair would be added to the Diameter MIP6 application. And to support EAP, = AVPs defined in 4072 would be at least (re-)used. > > IMHO, the context described in the draft looks like more a service access= authorization management than the use of a simple external database. I wou= ld be therefore in favor of defining authentication commands within the Dia= meter MIP6 application instead of trying to reuse the Diameter EAP applicat= ion, which is not possible without modifications. EAP authentication and MI= P6 service access authorization are performed with the same application. Si= nce a application-Id is whatever needed for the HA/AAA-MIP6, what would be = the benefit to look for solutions binding Diameter EAP and Diameter MIP6 (w= ith some key derivation, etc.) while a single Diameter MIP6 application wit= h intrinsic authentication commands would be fully appropriate? > > I'm pretty sure that the content of this mail may be challenged line by l= ine ;) But at the end, if authentication and authorization are needed to pr= ovide MIP6 services, why do not having a single application to do it? Of co= urse, I don't say that it would not be possible to do something more comple= x... > > BR, > > Lionel > > > > -----Message d'origine----- > > De : Julien Laganier [mailto:julien.IETF@laposte.net] > > Envoy=E9 : mardi 23 janvier 2007 10:42 > > =C0 : Ahmad Muhanna > > Cc : dime@ietf.org > > Objet : Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: > > Issue or notIssue ? > > > > Hi Ahmad, > > > > Cutting a bit thru your message, I have some comments > > below: > > > > On Monday 22 January 2007 18:10, Ahmad Muhanna wrote: > > > > > > > > >[...] > > > > > > [Ahmad] > > > We are probably splitting hair here, apparently there are two > > > arguments here: > > > > I don't think this is hair splitting. Understand the issue > > should be a prerequisite to solving it. > > > > > 1. AAAz is an authorization server and since it has a security > > > relationship with the HA, AAAz relies on the HA to do two > > things: 1.1. > > > HA makes sure that the user has been authenticated by AAAn. 1.2. HA > > > will not send any Authorization requests for any user(s) > > who has not > > > been authenticated. > > > > > > (In normal conditions, the above two conditions are ALWAYS > > TRUE except > > > in one condition, HA has been > > > compromised) > > > > Right. So we both agree there's no problem unless the HA is > > compromised > > > > I think what the first step is to agree on a threat model. I > > do not agree that we should defend against a compromised HA. > > The HA should be deemed secure against attackers. > > > > We have to place a limit on what is entity X when asking the > > question "what if entity X is compromised". > > Since nothing is really impossible in the real world, we > > cannot defend against compromission of any entity implicated > > in a protocol. Security is a tradeoff. > > > > More below... > > > > > 2. AAAz is an authorization server and has a security > > association with > > > the HA, however, due to the fact that the HA could be > > compromised, a > > > process needs to be in place for the HA to ALWAYS provide the AAAz, > > > Authorization server, with a proof (token, > > > etc.) that the user has been authenticated by AAAn. > > > > OK, if HA can be compromised. But why are we stopping here? > > Why not considering the case where the AAAn is compromised? > > Is is it more likely for an HA to be compromised than for a AAAn? > > > > We really have to agree on a threat model first. > > > > > I assume here that the difference in opinion is about the > > possibility > > > of the HA to be compromised or NOT. > > > > Exactly. > > > > Best, > > > > --julien (L.) > > > > _______________________________________________ > > 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 Jan 24 07:52:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9hbX-0006Of-03; Wed, 24 Jan 2007 07:51:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9hbV-0006OJ-9L for dime@ietf.org; Wed, 24 Jan 2007 07:51:53 -0500 Received: from cluster-e.mailcontrol.com ([217.79.216.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9hbS-00052h-CS for dime@ietf.org; Wed, 24 Jan 2007 07:51:53 -0500 Received: from c2-ex001.groupinfra.com ([212.123.206.140]) by rly49e.srv.mailcontrol.com (MailControl) with ESMTP id l0OCnLxr014358 for ; Wed, 24 Jan 2007 12:51:40 GMT Received: from in-ex002.groupinfra.com ([158.234.200.107]) by c2-ex001.groupinfra.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 13:51:05 +0100 Received: from in-ex001.groupinfra.com ([158.234.200.12]) by in-ex002.groupinfra.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 18:20:56 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 24 Jan 2007 18:20:55 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Query regarding CER Thread-Index: Acc/tkll2KAXh5aWRSus25YKHbKSTw== From: "Rawat, Himanshu" To: X-OriginalArrivalTime: 24 Jan 2007 12:50:56.0341 (UTC) FILETIME=[4A1DC050:01C73FB6] X-Scanned-By: MailControl A-06-00-00 (www.mailcontrol.com) on 10.69.0.159 X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Subject: [Dime] Query regarding CER 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="===============0325984037==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0325984037== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73FB6.4A14B905" This is a multi-part message in MIME format. ------_=_NextPart_001_01C73FB6.4A14B905 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I have a query regarding "How to discard CER's received from unknown peers". I've gone through the RFC 3588, there one term is mentioned i.e. "local policy". =20 What exactly this local policy is? Does it contain information about the authorized peers like IP address? What are the contents? How can we use this policy in discarding CER's?. =20 Second, suppose we have a diameter client which needs to connect to diameter server. How this diameter client does know to connect to which server while sending the CER (I think there is no destination AVP included in CER)? Is there some sort of configuration file has to be maintained on client side which has all the connection parameters related to the server? =20 Looking for answers!!!! =20 =20 Thanks & Regards Himanshu Rawat =20 "Anyone who has never made a mistake has never tried anything new" =20 This e-mail and any attachment is for authorised use by the intended recipi= ent(s) only. It may contain proprietary material, confidential information = and/or be subject to legal privilege. It should not be copied, disclosed to= , retained or used by, any other party. If you are not an intended recipien= t then please promptly delete this e-mail and any attachment and all copies= and inform the sender. Thank you. ------_=_NextPart_001_01C73FB6.4A14B905 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

 I have a query regarding “How to discard CER’s received from unknown= peers”. I’ve gone through the RFC 3588, there one term is mentioned i.e. R= 20;local policy”.

 

 What exactly this local policy is? Does it contain information about the authorized peers like IP address?

 What are the contents?

 How can we use this policy in discarding CER’= ;s?.

 

Second, suppose we have a diameter client which needs to connect to diameter server. How this diameter client does know to connect to which server while sending the CER (I think there is no destination AVP inc= luded in CER)? Is there some sort of configuration file has to be maintained on client side which has all the connection parameters related to the server?<= o:p>

 

Looking for answers!!!!

 

 

Thanks & Regards

Hi= manshu Rawat<= /o:p>

 

<= span style=3D'font-size:12.0pt;color:navy'>"Anyone who has never made a mis= take has never tried anything new"

 



This e-mail and= any attachment is for authorised use by the intended recipient(s) only. It= may contain proprietary material, confidential information and/or be subje= ct to legal privilege. It should not be copied, disclosed to, retained or u= sed by, any other party. If you are not an intended recipient then please p= romptly delete this e-mail and any attachment and all copies and inform the= sender. Thank you.

------_=_NextPart_001_01C73FB6.4A14B905-- --===============0325984037== 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 --===============0325984037==-- From dime-bounces@ietf.org Wed Jan 24 09:13:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9isL-0008Jc-UW; Wed, 24 Jan 2007 09:13:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9isJ-0008JU-UW for dime@ietf.org; Wed, 24 Jan 2007 09:13:19 -0500 Received: from nf-out-0910.google.com ([64.233.182.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9irr-0000B5-QZ for dime@ietf.org; Wed, 24 Jan 2007 09:13:19 -0500 Received: by nf-out-0910.google.com with SMTP id l36so605159nfa for ; Wed, 24 Jan 2007 06:12:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fDR4QhbnIzPDpfFub0ZOmHjJF5KObuOQdVymDgmLe/V0WJv1gvhbhsWSEBGrRVzUoKuUabmRm1BPD+wyZA4E7Xq/uSuxd2zTxHaXV7nFR67QrdwsKdDJ4Alwq08q8Nqireupr9UUcGavsszLlEwb4nUBMnG3oJOhvFG84SOKge8= Received: by 10.48.217.11 with SMTP id p11mr2875912nfg.1169647966516; Wed, 24 Jan 2007 06:12:46 -0800 (PST) Received: by 10.48.222.20 with HTTP; Wed, 24 Jan 2007 06:12:46 -0800 (PST) Message-ID: <5e2406980701240612k7b0bc716y9610fc0e63bb6bb6@mail.gmail.com> Date: Wed, 24 Jan 2007 15:12:46 +0100 From: "Julien Bournelle" To: "Gerardo Giaretta" Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Issue or notIssue ? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <7DBAFEC6A76F3E42817DF1EBE64CB026043BC087@FTRDMEL2.rd.francetelecom.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Cc: dime@ietf.org, Julien Laganier 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, On 1/24/07, Gerardo Giaretta wrote: > Hi all, > > I agree with Lionel. The proposal of having a split between > authentication and authorization was made by Yoshi in order to avoid > changes to 4072 and avoid duplicating functionality between Diameter > applications. > > However, it seems that there are more drawbacks than benefits as > discussed in this month. And I don't see a strong issue in having the > MIP6 Diameter application supporting both authentication and > authorization. Note that if we want to add support for rfc4285, we'll > have to define an authentication application for MIP6 anyway. > > Therefore my suggestion is: close the issue stating that the AAA > servers for authentication and authorization are co-located and that > the same application is used for both. > > Does it sound good to everybody? In order to move forward, I agree to go in this direction. Julien > > If not, I would like to hear strong motivations and benefits to have > the servers/application split since during these months I have not > heard any (a part from the documentation issue mentioned above). > > --Gerardo > > On 1/23/07, MORAND Lionel RD-CORE-ISS = wrote: > > Hi Folks, > > > > There is a new guy in the game ;) > > > > After reviewing the draft and the mail exchange on the topic, I would s= ay that the conclusion on "issue/no issue" depends on the side you are cons= idering the problem (as often ;). > > > > If you are considering the AAA-MIP6 as a "simple" database providing th= e HA with specific user/service information after a separate authentication= (performed with Diameter authentication), the username conveyed over the H= A/AAA-MIP6 is just used as a key entry in the database. There is no need fo= r the AAA-MIP6 to authenticate this username or to be sure that the usernam= e was previously authenticated. The client of the database is the HA and no= t the user. In that case, the AAA-MIP6 has to trust the HA and it is up to = the HA to authenticate the username provided by the mn during the SA set-up= . This could be compared to interfaces between HSS (Home Subscriber Server)= and SIP application servers defined in the 3GPP architecture, over which D= iameter applications are used to access database. > > > > In this context, the HA may use: > > 1) the Diameter EAP application to authenticate the user. > > 2) the Diameter MIP6 application to download user related service infor= mation > > Authentication and authorization are performed by the AAA-EAP. But ther= e is no way for the AAA-EAP to know what is the service requested by the us= er. Successful authentication implies implicte authorization. This is the p= roblem with Diameter EAP as it is not possible to route Diameter EAP reques= t to a service-specific EAP server. > > > > In another hand, if the AAA-MIP6 is an authority handling MIP6 service = access authorization rights i.e. the AAA-MIP6 must verify that the user is = authorized to use the Mobile IPv6 service, this authority has to be able to= verify the identity of the user before authorizing this user to access the= service. It is not possible to authorize someone to do something without b= eing sure of its identity as the authority must stand surety of the user ac= cess rights. Now, it is not possible to rely on the Diameter EAP applicatio= n to perform the authentication procedure as there is no way to direct the = Diameter EAP requests to a specifc EAP server (as the Diameter routing is b= ased on App-Id and Realm). We might think about some specific things to lin= k authentication procedures and authorization/service profile handling. But= for me, the simpliest way would be to define the required authentication m= echanism within one and only one application i.e. the application that requ= ires this authentication. Therefore, Diameter EAP would not be used and app= lication-specific commands would be specified in the application. One comma= nd pair would be added to the Diameter MIP6 application. And to support EAP= , AVPs defined in 4072 would be at least (re-)used. > > > > IMHO, the context described in the draft looks like more a service acce= ss authorization management than the use of a simple external database. I w= ould be therefore in favor of defining authentication commands within the D= iameter MIP6 application instead of trying to reuse the Diameter EAP applic= ation, which is not possible without modifications. EAP authentication and = MIP6 service access authorization are performed with the same application. = Since a application-Id is whatever needed for the HA/AAA-MIP6, what would b= e the benefit to look for solutions binding Diameter EAP and Diameter MIP6 = (with some key derivation, etc.) while a single Diameter MIP6 application w= ith intrinsic authentication commands would be fully appropriate? > > > > I'm pretty sure that the content of this mail may be challenged line by= line ;) But at the end, if authentication and authorization are needed to = provide MIP6 services, why do not having a single application to do it? Of = course, I don't say that it would not be possible to do something more comp= lex... > > > > BR, > > > > Lionel > > > > > > > -----Message d'origine----- > > > De : Julien Laganier [mailto:julien.IETF@laposte.net] > > > Envoy=E9 : mardi 23 janvier 2007 10:42 > > > =C0 : Ahmad Muhanna > > > Cc : dime@ietf.org > > > Objet : Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: > > > Issue or notIssue ? > > > > > > Hi Ahmad, > > > > > > Cutting a bit thru your message, I have some comments > > > below: > > > > > > On Monday 22 January 2007 18:10, Ahmad Muhanna wrote: > > > > > > > > > > > >[...] > > > > > > > > [Ahmad] > > > > We are probably splitting hair here, apparently there are two > > > > arguments here: > > > > > > I don't think this is hair splitting. Understand the issue > > > should be a prerequisite to solving it. > > > > > > > 1. AAAz is an authorization server and since it has a security > > > > relationship with the HA, AAAz relies on the HA to do two > > > things: 1.1. > > > > HA makes sure that the user has been authenticated by AAAn. 1.2. HA > > > > will not send any Authorization requests for any user(s) > > > who has not > > > > been authenticated. > > > > > > > > (In normal conditions, the above two conditions are ALWAYS > > > TRUE except > > > > in one condition, HA has been > > > > compromised) > > > > > > Right. So we both agree there's no problem unless the HA is > > > compromised > > > > > > I think what the first step is to agree on a threat model. I > > > do not agree that we should defend against a compromised HA. > > > The HA should be deemed secure against attackers. > > > > > > We have to place a limit on what is entity X when asking the > > > question "what if entity X is compromised". > > > Since nothing is really impossible in the real world, we > > > cannot defend against compromission of any entity implicated > > > in a protocol. Security is a tradeoff. > > > > > > More below... > > > > > > > 2. AAAz is an authorization server and has a security > > > association with > > > > the HA, however, due to the fact that the HA could be > > > compromised, a > > > > process needs to be in place for the HA to ALWAYS provide the AAAz, > > > > Authorization server, with a proof (token, > > > > etc.) that the user has been authenticated by AAAn. > > > > > > OK, if HA can be compromised. But why are we stopping here? > > > Why not considering the case where the AAAn is compromised? > > > Is is it more likely for an HA to be compromised than for a AAAn? > > > > > > We really have to agree on a threat model first. > > > > > > > I assume here that the difference in opinion is about the > > > possibility > > > > of the HA to be compromised or NOT. > > > > > > Exactly. > > > > > > Best, > > > > > > --julien (L.) > > > > > > _______________________________________________ > > > 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 Wed Jan 24 09:14:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9ita-00007C-Be; Wed, 24 Jan 2007 09:14:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9itZ-00006t-4K for dime@ietf.org; Wed, 24 Jan 2007 09:14:37 -0500 Received: from smtp.operax.com ([213.50.74.226] helo=smtp-dmz.operax.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H9itT-000768-VH for dime@ietf.org; Wed, 24 Jan 2007 09:14:37 -0500 Received: from lulex02.ad.operax.com (ad.operax.com [192.168.2.13]) by smtp-dmz.operax.com (8.13.1/8.13.1) with ESMTP id l0OEEM1f079421 for ; Wed, 24 Jan 2007 15:14:22 +0100 (CET) (envelope-from Ulf.Bodin@operax.com) 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] The Auditing Problem: Possible approaches Date: Wed, 24 Jan 2007 15:14:23 +0100 Message-ID: <33656995C5C5094A983DE84DA649A924EB1917@lulex02.ad.operax.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] The Auditing Problem: Possible approaches Thread-Index: Acc/PDDoiJiluNywSy62B14POLA90gAZuzAg From: "Ulf Bodin" To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (smtp-dmz.operax.com [172.16.1.4]); Wed, 24 Jan 2007 15:14:23 +0100 (CET) X-Spam-Status: No, score=-52.6 required=4.7 tests=ALL_TRUSTED,BAYES_00, USER_IN_BLACKLIST autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on smtp-dmz.operax.com X-Virus-Scanned: ClamAV 0.88.7/2483/Wed Jan 24 10:45:20 2007 on smtp-dmz.operax.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: bc102ac530ba955ef81f1f75b8bebe44 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 and Hannes,=20 I agree to the summary as of below, but would like to add a few pieces:=20 1) Prior to transferring session state data I believe for the case of state replication that either part would benefit from a way to query the other part for a list of active sessions (i.e. to synchronize the views of clients and their server). This is useful e.g. to not unnecessarily send state information for states that have been sucessfully replicated. 2) I think we need to explore client failover somewhat further. This applies to some of the bullets below: 1.a no messages from a client for for a period means its dead, 2.b and 2.c may apply if the server sends autonomous requests to the client. 2.a don't apply since state information don't normally travel in the direction from server to client, 2.b may apply since a generic message could be defined for usage in both directions. The 3.a, 3.b and 3.c approaches could be applied to the client side.=20 Also, just a quick comment to the session reconstruction and/or replication issue. I agree to a) and for b) I would like to add that I see the Diameter server as the physical owner of the mentioned resources. I might miss something here, but in my view that means to rely on Dimater sesison state.=20 >From my perspective it might be a good time to gather information in a draft as you suggest Hannes. I'm not completely sure exactly how sujch draft would materialize. Explaining different choices, thri applicability and how thay handle different functional aspects sounds good to me (starting from the list below).=20 Best regards,=20 Ulf=20 -----Original Message----- From: Tolga Asveren [mailto:asveren@ulticom.com]=20 Sent: den 23 januari 2007 23:12 To: dime@ietf.org Subject: RE: [Dime] The Auditing Problem: Possible approaches Hi Hannes, Let me try to summarize the discussion till now (or better said my understanding of it) and try to answer your questions (Ulf, please feel free to add, correct etc...) >From functionality point of view, I see three different pieces (which probbaly will answer your first two questions and possibly the third one to some degree): 1- Notification of client about server failure a) Relying on an application layer timer The protocol specification mandates periodic messaging from client to server and use of a timer for the maximum allowed time to wait for a corresponding answer, e.g. Diameter Credit Control Application. If no answer is received in time, the server is assumed as down. This is the soft state approach. For this to work, there is no need to change anything in the base Diameter infrastructure, application protocol authors need to define the periodic messaging behavior. b) Relying on receipt of an error answer Here again we assume that the client is sending periodic requests during a session. Because mid-session requests will have a Destination-Host AVP, if an UNABLE_TO_DELIVER answer is received, this would be interpreted as the server being down. Here, we assume that Diaemter network is properly engineered, i.e. transport problems won't cause a message not being delivered successfully. This aproach is similar to a), probably will be used if Tw granularity on the message path is acceptable for the application. Again, what is needed is that application protocol authors defining periodci mid-session requests mechanism. c) A notification from the backup server When the backup server detects failure of an active server and is ready to take over its responsibilities, it sends a notification to the clients, with which the active server had ongoing sessions. The identity of such clients needs to be synchronized between active and standby servers. Currently, there is no generic message defined in Diameter for this purpose. Such a message could be defined by applications or we can have a generic one. 2- Transfer of session state data a) Using application messages Mid-session application messages can be used to transfer the state data. Applications can define an AVP to mark that certain mid-session request is a "refresh" or this could be done with a separate mid-session application message. The message should carry enough information to reconstruct session state at the server. If a special application message is used, this could carry session state for multiple sessions. b) Using a generic message A generic message can be defined to carry session data to the backup server. In this approach, although the message itself could be generic, still each application needs to define the content of the message so that it contains enough information to recosntruct the state. 3- Backup Server Selection / Load Distribution a) Backup information fed by the active server Information about backup servers could be sent to clients by the active server, when it was up and running. This information could indicate on a per session basis, which backup server should be used for that particulat session if the active server fails before the session terminates. Alternatively, a list of backup servers with priorities could be indicated, which is applicable for all sessions. b) Acceptable load fed by backup server If the backup server sendsa notification to the client ( approach c) for issue 1) ), the notification may contain number of sessions, backup server is willing to take over. c) Trial and error Client sends messages to backup server candidates. If the answer result code is not SUCCESS, it tries another one. Another important question seems to be, when does the need arise for servers to trigger the session reconstruction mechanism rather than waiting for the client to send a message for that purpose. AFAICS, we came up with two different reasons for this: a) The server needs to send autonomous requests to the client, e.g. for some type of periodic reporting b) The server needs to know about existing sessions at any given time to be able to process new sessions requests properly, e.g. so that it can know whether accepting a new reservation would exceed the available free resources (I didn't think abouth this throughly but I feel like this can be done just by relying on responses from the physical owner of resources rather than relying on Diameter session state) I checked briefly RFC4507 you mentioned. There it seems for 1- a) and b) (depending on whether the host or the application crashes), for 2- a), for 3- c) is used. What makes this problem interesting is that at the end it will be the decision of the application protocol author what counts. What we can provide is some guidelines about different protocol design choices and if we see it necesary some generic infrastructure messages/AVPs. Thanks, Tolga > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Tuesday, January 23, 2007 2:35 PM > To: Tolga Asveren > Cc: dime@ietf.org > Subject: Re: [Dime] The Auditing Problem: Possible approaches > > > Hi Tolga, > > I went through the discussion thread and noticed that it is indeed a=20 > bit difficult to follow the individual issues. > > Your mail entitled with "[Dime] The Auditing Problem: Possible=20 > approaches" > http://www1.ietf.org/mail-archive/web/dime/current/msg01196.html > might be a good starting point for further descriptions. > > I am interested in a description that tells me: > * How and who detects the failure of the server? > * What messages need to be exchanged to establish the state at the new > server? > * What are the assumptions made with each proposal? > > Let us consider other protocols with respect to their ability to deal=20 > with server failure, such as: > > ftp://ftp.isi.edu/in-notes/rfc4507.txt > http://www.ietf.org/internet-drafts/draft-sheffer-ike-session-resu > mption-00.txt > http://www.ietf.org/internet-drafts/draft-vidya-ipsec-failover-ps-00.t > xt > > > The first two documents explain a procedure to quickly establish state > at a new server after the old server failed based on an encrypted=20 > ticket that is sent to the client and presented at the new server=20 > during session setup. > > Ciao > Hannes > > Tolga Asveren wrote: > > Hi Ulf, Hannes and all, > > > > I feel like now we are ready for detailed > investigation/documentation of the > > problems/choices we discussed. > > > > What would be a good way to proceed, producing drafts? If so, > what would be > > the content? To me it makes sense to start with a draft which=20 > > explains different choices, their applicability and how they handle=20 > > different functional aspects (notification of clients, transfer of > session data, load > > distribution etc...) Some of the methods described may require=20 > > separate drafts defining new messages/AVPs. > > > > Another alternative is to continue discussing with e-mail > messages on the > > list but I think this started to get a little bit hard to > follow and we may > > loose track of issues discussed. > > > > Thanks, > > Tolga > > > > > >> i- Client triggered refresh upon expiry of a timer on the > client This is > >> essentially the soft state case, where the client can send a=20 > >> message to an alternate server after expiry of a protocol timer=20 > >> with enough information embedded in the message, so that the=20 > >> alternate server can process it. > >> > >> [Ulf2] Yes. > >> > >> ii- Client triggered refresh upon receipt of an error answer=20 > >> Similar to i-, except that it is triggered upon receip of an "UNABLE_TO_DELIVER" > >> error answer. > >> > >> [Ulf2] Question for clarificaiton; would this mean to refresh all=20 > >> session states associated with the target that could not be=20 > >> reached, or just the session for which the error was given? > >> > >> iii- Peer triggered state data transfer upon receipt of a=20 > >> notification from a peer This is the approach described in the=20 > >> draft-calhoun-diameter-res-mgmt-08.txt > >> > >> [Ulf2] Ok. > >> > >> iv- Peer triggered refresh > >> This is similar to iii- but relies on the application messages to=20 > >> rebuild the state. A notification message is sent from a peer=20 > >> informing the client that a server went down. The client refreshes > sessions on the > >> alternate server. The message can be sent immediately after=20 > >> receiving the notification or could be delayed till the=20 > >> corresponding session(s) actually require a message to be sent to update/delete. > >> > >> [Ulf2] Ok. What come to my mind though is the amount of > messages that'll > >> be generated (this concern applies also to ii in case all > session states > >> are to be refreshed). In my view some recommendations on how to=20 > >> control the rate of messages and/or to make it driven by a receiver > >> of the updates would be needed. I might be jumping ahead too quick=20 > >> to the solution now though. > >> > >> i and ii seem to work with existing Diameter wisdom, but they may=20 > >> run into issues, if servers also generate autonomous requests to=20 > >> clients (actually this would probably answer the question I asked=20 > >> in a previous message about the necessity of resurrection=20 > >> sessions/states on backup servers immediately after they take over=20 > >> the role of a failed host) > >> > >> [Ulf2] Yes, autonomous requests/unsolicited call backs is a reason=20 > >> for resurrection sessions/states on backup servers. I believe an=20 > >> additional reason for why states should for some applications be=20 > >> resurrected is that the application are controlling access to scarce resources (e.g. > >> RACS). > >> > >> For iii and iv, a backup peer needs to know which clients it needs=20 > >> to send a notification to. This probably can be synchronized=20 > >> between peers of a cluster. > >> > >> [Ulf2] Yes. > >> > >> It could be useful to think over different alternatives considering > >> the RACS scenario. For RACS, which interface are we talking about, > Gq', Rq , > >> any or both? > >> > >> [Ulf2] I'm considering both Gq' and Rq as well as the corresponding > >> interfaces as of ITU and 3GPP. I believe all your list items to=20 > >> applicable to those interfaces. Which specific approach that'll be=20 > >> adopted for each individual deployment (and by different vendors)=20 > >> remains to be seen. My personal belief is that most A-RACF > entities (the > >> part of RACS performing admission control) will replicate both=20 > >> session and reservation states. The A-RACF is likely to offer > soft-state only to > >> the SPDF (the part of RACS facing application frameworks such as e.g. > >> SIP proxies). The SPDF will probably also replicate states and=20 > >> offer soft-state to its clients. The SPDF is however likely to also > >> offer hard-state to some application frameworks (e.g. leased line=20 > >> application level servers). > >> > >> Given the above assumptions i and ii will be used without complete=20 > >> information in refresh messages to rebuld states. In addition, iii=20 > >> will be used to ensure syncronisation after failover (and=20 > >> potentially periodically between application and SPDF in the case of hard-state). > >> Since states are replicated iv would not apply (if I understand the > >> approach correctly it applies to non cases when data is not=20 > >> replicated only). However, for a deployment without replication for e.g. > the A-RACF > >> iv would however apply. > >> > >> > >> > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www1.ietf.org/mailman/listinfo/dime > >> > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www1.ietf.org/mailman/listinfo/dime > >> > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jan 24 13:54:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9nGb-000664-Dq; Wed, 24 Jan 2007 13:54:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9nGZ-00065t-Sl for dime@ietf.org; Wed, 24 Jan 2007 13:54:39 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H9nGX-0006NV-RC for dime@ietf.org; Wed, 24 Jan 2007 13:54:39 -0500 Received: (qmail invoked by alias); 24 Jan 2007 18:54:34 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp035) with SMTP; 24 Jan 2007 19:54:34 +0100 X-Authenticated: #29516787 Message-ID: <45B7AB67.7040103@gmx.net> Date: Wed, 24 Jan 2007 19:54:31 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] The Auditing Problem: Possible approaches 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.0 (/) X-Scan-Signature: 1df8e4abc9851cb4adb45bd64d8514ae Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga, thanks for the nice summary. Please find my response below: Tolga Asveren wrote: > Hi Hannes, > > Let me try to summarize the discussion till now (or better said my > understanding of it) and try to answer your questions (Ulf, please feel free > to add, correct etc...) > > >> >From functionality point of view, I see three different pieces (which >> > probbaly will answer your first two questions and possibly the third one to > some degree): > > 1- Notification of client about server failure > a) Relying on an application layer timer > The protocol specification mandates periodic messaging from client to server > and use of a timer for the maximum allowed time to wait for a corresponding > answer, e.g. Diameter Credit Control Application. If no answer is received > in time, the server is assumed as down. This is the soft state approach. For > this to work, there is no need to change anything in the base Diameter > infrastructure, application protocol authors need to define the periodic > messaging behavior. > > Ok > b) Relying on receipt of an error answer > Here again we assume that the client is sending periodic requests during a > session. Because mid-session requests will have a Destination-Host AVP, if > an UNABLE_TO_DELIVER answer is received, this would be interpreted as the > server being down. Here, we assume that Diaemter network is properly > engineered, i.e. transport problems won't cause a message not being > delivered successfully. This aproach is similar to a), probably will be used > if Tw granularity on the message path is acceptable for the application. > Again, what is needed is that application protocol authors defining periodci > mid-session requests mechanism. > > This approach assumes that there is an intermediate node that provides the error message or that the error message is offered from a lower layer. > c) A notification from the backup server > When the backup server detects failure of an active server and is ready to > take over its responsibilities, it sends a notification to the clients, with > which the active server had ongoing sessions. The identity of such clients > needs to be synchronized between active and standby servers. Currently, > there is no generic message defined in Diameter for this purpose. Such a > message could be defined by applications or we can have a generic one. > With this approach the backup server at least has to know Session IDs and Diameter client identifiers. It would also be necessary to determine (on a per-application basis) which state the Diameter client would sent back to the Diameter server. The state that is kept at the server and at the client might be different. I could also imagine that there are security issues: The Diameter client might not know the backup server and hence any arbitrary server could just retrieve state from the client. > 2- Transfer of session state data > a) Using application messages > Mid-session application messages can be used to transfer the state data > I am not sure why you mean that it would be a mid-session message? Who would sent the message? > Applications can define an AVP to mark that certain mid-session request is a > "refresh" or this could be done with a separate mid-session application > message. The message should carry enough information to reconstruct session > state at the server. If a special application message is used, this could > carry session state for multiple sessions. > > b) Using a generic message > A generic message can be defined to carry session data to the backup server. > In this approach, although the message itself could be generic, still each > application needs to define the content of the message so that it contains > enough information to recosntruct the state. > I think that there are three possible modes: (*) State is sent from the Diameter server to the Diameter client and in case of a failure from the Diameter client to the Diameter backup server. This is similar to what is done with RFC 4507. This approach does not require state to be synchronized between the backup and the original Diameter server. (**) The backup server asks the Diameter client for a state transfer from the client to the backup server. This obviously requires state synchronization between the two Diameter servers to let the backup server to know the identity of the Diameter client. (***) The Diameter client knows the backup server and contacts it when the main server is not reachable anymore. > 3- Backup Server Selection / Load Distribution > a) Backup information fed by the active server > Information about backup servers could be sent to clients by the active > server, when it was up and running. This information could indicate on a per > session basis, which backup server should be used for that particulat > session if the active server fails before the session terminates. > Alternatively, a list of backup servers with priorities could be indicated, > which is applicable for all sessions. > Agree. > b) Acceptable load fed by backup server > If the backup server sendsa notification to the client ( approach c) for > issue 1) ), the notification may contain number of sessions, backup server > is willing to take over. > > True. > c) Trial and error > Client sends messages to backup server candidates. If the answer result code > is not SUCCESS, it tries another one. > > > Another important question seems to be, when does the need arise for servers > to trigger the session reconstruction mechanism rather than waiting for the > client to send a message for that purpose. AFAICS, we came up with two > different reasons for this: > a) The server needs to send autonomous requests to the client, e.g. for some > type of periodic reporting > b) The server needs to know about existing sessions at any given time to be > able to process new sessions requests properly, e.g. so that it can know > whether accepting a new reservation would exceed the available free > resources (I didn't think abouth this throughly but I feel like this can be > done just by relying on responses from the physical owner of resources > rather than relying on Diameter session state) > > I checked briefly RFC4507 you mentioned. There it seems for 1- a) and b) > (depending on whether the host or the application crashes), for 2- a), for > 3- c) is used. > It would probably be something like 1a or 1b but the details are not mentioned. Not sure about (2) since I have some questions. Regarding 3c: > What makes this problem interesting is that at the end it will be the > decision of the application protocol author what counts. What we can provide > is some guidelines about different protocol design choices and if we see it > necesary some generic infrastructure messages/AVPs. > > Thanks, > Tolga > > > Ciao Hannes >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Tuesday, January 23, 2007 2:35 PM >> To: Tolga Asveren >> Cc: dime@ietf.org >> Subject: Re: [Dime] The Auditing Problem: Possible approaches >> >> >> Hi Tolga, >> >> I went through the discussion thread and noticed that it is indeed a bit >> difficult to follow the individual issues. >> >> Your mail entitled with "[Dime] The Auditing Problem: Possible >> approaches" >> http://www1.ietf.org/mail-archive/web/dime/current/msg01196.html >> might be a good starting point for further descriptions. >> >> I am interested in a description that tells me: >> * How and who detects the failure of the server? >> * What messages need to be exchanged to establish the state at the new >> server? >> * What are the assumptions made with each proposal? >> >> Let us consider other protocols with respect to their ability to deal >> with server failure, such as: >> >> ftp://ftp.isi.edu/in-notes/rfc4507.txt >> http://www.ietf.org/internet-drafts/draft-sheffer-ike-session-resu >> mption-00.txt >> http://www.ietf.org/internet-drafts/draft-vidya-ipsec-failover-ps-00.txt >> >> >> The first two documents explain a procedure to quickly establish state >> at a new server after the old server failed based on an encrypted ticket >> that is sent to the client and presented at the new server during >> session setup. >> >> Ciao >> Hannes >> >> Tolga Asveren wrote: >> >>> Hi Ulf, Hannes and all, >>> >>> I feel like now we are ready for detailed >>> >> investigation/documentation of the >> >>> problems/choices we discussed. >>> >>> What would be a good way to proceed, producing drafts? If so, >>> >> what would be >> >>> the content? To me it makes sense to start with a draft which explains >>> different choices, their applicability and how they handle different >>> functional aspects (notification of clients, transfer of >>> >> session data, load >> >>> distribution etc...) Some of the methods described may require separate >>> drafts defining new messages/AVPs. >>> >>> Another alternative is to continue discussing with e-mail >>> >> messages on the >> >>> list but I think this started to get a little bit hard to >>> >> follow and we may >> >>> loose track of issues discussed. >>> >>> Thanks, >>> Tolga >>> >>> >>> >>>> i- Client triggered refresh upon expiry of a timer on the >>>> >> client This is >> >>>> essentially the soft state case, where the client can send a message to >>>> an alternate server after expiry of a protocol timer with enough >>>> information embedded in the message, so that the alternate server can >>>> process it. >>>> >>>> [Ulf2] Yes. >>>> >>>> ii- Client triggered refresh upon receipt of an error answer Similar to >>>> i-, except that it is triggered upon receip of an "UNABLE_TO_DELIVER" >>>> error answer. >>>> >>>> [Ulf2] Question for clarificaiton; would this mean to refresh all >>>> session states associated with the target that could not be reached, or >>>> just the session for which the error was given? >>>> >>>> iii- Peer triggered state data transfer upon receipt of a notification >>>> from a peer This is the approach described in the >>>> draft-calhoun-diameter-res-mgmt-08.txt >>>> >>>> [Ulf2] Ok. >>>> >>>> iv- Peer triggered refresh >>>> This is similar to iii- but relies on the application messages to >>>> rebuild the state. A notification message is sent from a peer informing >>>> the client that a server went down. The client refreshes >>>> >> sessions on the >> >>>> alternate server. The message can be sent immediately after receiving >>>> the notification or could be delayed till the corresponding session(s) >>>> actually require a message to be sent to update/delete. >>>> >>>> [Ulf2] Ok. What come to my mind though is the amount of >>>> >> messages that'll >> >>>> be generated (this concern applies also to ii in case all >>>> >> session states >> >>>> are to be refreshed). In my view some recommendations on how to control >>>> the rate of messages and/or to make it driven by a receiver of the >>>> updates would be needed. I might be jumping ahead too quick to the >>>> solution now though. >>>> >>>> i and ii seem to work with existing Diameter wisdom, but they may run >>>> into issues, if servers also generate autonomous requests to clients >>>> (actually this would probably answer the question I asked in a previous >>>> message about the necessity of resurrection sessions/states on backup >>>> servers immediately after they take over the role of a failed host) >>>> >>>> [Ulf2] Yes, autonomous requests/unsolicited call backs is a reason for >>>> resurrection sessions/states on backup servers. I believe an additional >>>> reason for why states should for some applications be resurrected is >>>> that the application are controlling access to scarce resources (e.g. >>>> RACS). >>>> >>>> For iii and iv, a backup peer needs to know which clients it needs to >>>> send a notification to. This probably can be synchronized between peers >>>> of a cluster. >>>> >>>> [Ulf2] Yes. >>>> >>>> It could be useful to think over different alternatives considering the >>>> RACS scenario. For RACS, which interface are we talking about, >>>> >> Gq', Rq , >> >>>> any or both? >>>> >>>> [Ulf2] I'm considering both Gq' and Rq as well as the corresponding >>>> interfaces as of ITU and 3GPP. I believe all your list items to >>>> applicable to those interfaces. Which specific approach that'll be >>>> adopted for each individual deployment (and by different vendors) >>>> remains to be seen. My personal belief is that most A-RACF >>>> >> entities (the >> >>>> part of RACS performing admission control) will replicate both session >>>> and reservation states. The A-RACF is likely to offer >>>> >> soft-state only to >> >>>> the SPDF (the part of RACS facing application frameworks such as e.g. >>>> SIP proxies). The SPDF will probably also replicate states and offer >>>> soft-state to its clients. The SPDF is however likely to also offer >>>> hard-state to some application frameworks (e.g. leased line application >>>> level servers). >>>> >>>> Given the above assumptions i and ii will be used without complete >>>> information in refresh messages to rebuld states. In addition, iii will >>>> be used to ensure syncronisation after failover (and potentially >>>> periodically between application and SPDF in the case of hard-state). >>>> Since states are replicated iv would not apply (if I understand the >>>> approach correctly it applies to non cases when data is not replicated >>>> only). However, for a deployment without replication for e.g. >>>> >> the A-RACF >> >>>> iv would however apply. >>>> >>>> >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/dime >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/dime >>>> >>>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >>> >>> > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jan 24 14:00:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9nMM-0007sy-4c; Wed, 24 Jan 2007 14:00:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9nM6-0007jR-Bd for dime@ietf.org; Wed, 24 Jan 2007 14:00:22 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H9nM4-0007g3-Iz for dime@ietf.org; Wed, 24 Jan 2007 14:00:22 -0500 Received: (qmail invoked by alias); 24 Jan 2007 19:00:17 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp040) with SMTP; 24 Jan 2007 20:00:17 +0100 X-Authenticated: #29516787 Message-ID: <45B7ACC2.4080405@gmx.net> Date: Wed, 24 Jan 2007 20:00:18 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Ulf Bodin Subject: Re: [Dime] The Auditing Problem: Possible approaches References: <33656995C5C5094A983DE84DA649A924EB1917@lulex02.ad.operax.com> In-Reply-To: <33656995C5C5094A983DE84DA649A924EB1917@lulex02.ad.operax.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: 6379955759c38e2371a49573a0932fc7 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 Ulf, Ulf Bodin wrote: > Hi Tolga and Hannes, > > I agree to the summary as of below, but would like to add a few pieces: > 1) Prior to transferring session state data I believe for the case of > state replication that either part would benefit from a way to query the > other part for a list of active sessions (i.e. to synchronize the views > of clients and their server). This is useful e.g. to not unnecessarily > send state information for states that have been sucessfully replicated. > > Wouldn't be the right way to ensure that you are only authorized to retrieve the state that you previously created. > 2) I think we need to explore client failover somewhat further. This > applies to some of the bullets below: 1.a no messages from a client for > for a period means its dead, 2.b and 2.c may apply if the server sends > autonomous requests to the client. 2.a don't apply since state > information don't normally travel in the direction from server to > client, 2.b may apply since a generic message could be defined for usage > in both directions. The 3.a, 3.b and 3.c approaches could be applied to > the client side. > > Also, just a quick comment to the session reconstruction and/or > replication issue. I agree to a) and for b) I would like to add that I > see the Diameter server as the physical owner of the mentioned > resources. I might miss something here, but in my view that means to > rely on Dimater sesison state. > > I agree that we also have to consider client failover. At the moment we are still focusing on the server failover case. The two might be a bit different. >> >From my perspective it might be a good time to gather information in a >> > draft as you suggest Hannes. I'm not completely sure exactly how sujch > draft would materialize. Explaining different choices, thri > applicability and how thay handle different functional aspects sounds > good to me (starting from the list below). > > I have one question for you: Do you consider a stateless solution at the backup server, i.e., where the backup server does not ever store Session Ids or the identities of the Diameter clients? Ciao Hannes > Best regards, > Ulf > > -----Original Message----- > From: Tolga Asveren [mailto:asveren@ulticom.com] > Sent: den 23 januari 2007 23:12 > To: dime@ietf.org > Subject: RE: [Dime] The Auditing Problem: Possible approaches > > Hi Hannes, > > Let me try to summarize the discussion till now (or better said my > understanding of it) and try to answer your questions (Ulf, please feel > free to add, correct etc...) > > >> >From functionality point of view, I see three different pieces (which >> > probbaly will answer your first two questions and possibly the third one > to some degree): > > 1- Notification of client about server failure > a) Relying on an application layer timer The protocol specification > mandates periodic messaging from client to server and use of a timer for > the maximum allowed time to wait for a corresponding answer, e.g. > Diameter Credit Control Application. If no answer is received in time, > the server is assumed as down. This is the soft state approach. For this > to work, there is no need to change anything in the base Diameter > infrastructure, application protocol authors need to define the periodic > messaging behavior. > > b) Relying on receipt of an error answer Here again we assume that the > client is sending periodic requests during a session. Because > mid-session requests will have a Destination-Host AVP, if an > UNABLE_TO_DELIVER answer is received, this would be interpreted as the > server being down. Here, we assume that Diaemter network is properly > engineered, i.e. transport problems won't cause a message not being > delivered successfully. This aproach is similar to a), probably will be > used if Tw granularity on the message path is acceptable for the > application. > Again, what is needed is that application protocol authors defining > periodci mid-session requests mechanism. > > c) A notification from the backup server When the backup server detects > failure of an active server and is ready to take over its > responsibilities, it sends a notification to the clients, with which the > active server had ongoing sessions. The identity of such clients needs > to be synchronized between active and standby servers. Currently, there > is no generic message defined in Diameter for this purpose. Such a > message could be defined by applications or we can have a generic one. > > 2- Transfer of session state data > a) Using application messages > Mid-session application messages can be used to transfer the state data. > Applications can define an AVP to mark that certain mid-session request > is a "refresh" or this could be done with a separate mid-session > application message. The message should carry enough information to > reconstruct session state at the server. If a special application > message is used, this could carry session state for multiple sessions. > > b) Using a generic message > A generic message can be defined to carry session data to the backup > server. > In this approach, although the message itself could be generic, still > each application needs to define the content of the message so that it > contains enough information to recosntruct the state. > > 3- Backup Server Selection / Load Distribution > a) Backup information fed by the active server Information about backup > servers could be sent to clients by the active server, when it was up > and running. This information could indicate on a per session basis, > which backup server should be used for that particulat session if the > active server fails before the session terminates. > Alternatively, a list of backup servers with priorities could be > indicated, which is applicable for all sessions. > > b) Acceptable load fed by backup server > If the backup server sendsa notification to the client ( approach c) for > issue 1) ), the notification may contain number of sessions, backup > server is willing to take over. > > c) Trial and error > Client sends messages to backup server candidates. If the answer result > code is not SUCCESS, it tries another one. > > > Another important question seems to be, when does the need arise for > servers to trigger the session reconstruction mechanism rather than > waiting for the client to send a message for that purpose. AFAICS, we > came up with two different reasons for this: > a) The server needs to send autonomous requests to the client, e.g. for > some type of periodic reporting > b) The server needs to know about existing sessions at any given time to > be able to process new sessions requests properly, e.g. so that it can > know whether accepting a new reservation would exceed the available free > resources (I didn't think abouth this throughly but I feel like this can > be done just by relying on responses from the physical owner of > resources rather than relying on Diameter session state) > > I checked briefly RFC4507 you mentioned. There it seems for 1- a) and b) > (depending on whether the host or the application crashes), for 2- a), > for > 3- c) is used. > > What makes this problem interesting is that at the end it will be the > decision of the application protocol author what counts. What we can > provide is some guidelines about different protocol design choices and > if we see it necesary some generic infrastructure messages/AVPs. > > Thanks, > Tolga > > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Tuesday, January 23, 2007 2:35 PM >> To: Tolga Asveren >> Cc: dime@ietf.org >> Subject: Re: [Dime] The Auditing Problem: Possible approaches >> >> >> Hi Tolga, >> >> I went through the discussion thread and noticed that it is indeed a >> bit difficult to follow the individual issues. >> >> Your mail entitled with "[Dime] The Auditing Problem: Possible >> approaches" >> http://www1.ietf.org/mail-archive/web/dime/current/msg01196.html >> might be a good starting point for further descriptions. >> >> I am interested in a description that tells me: >> * How and who detects the failure of the server? >> * What messages need to be exchanged to establish the state at the new >> > > >> server? >> * What are the assumptions made with each proposal? >> >> Let us consider other protocols with respect to their ability to deal >> with server failure, such as: >> >> ftp://ftp.isi.edu/in-notes/rfc4507.txt >> http://www.ietf.org/internet-drafts/draft-sheffer-ike-session-resu >> mption-00.txt >> http://www.ietf.org/internet-drafts/draft-vidya-ipsec-failover-ps-00.t >> xt >> >> >> The first two documents explain a procedure to quickly establish state >> > > >> at a new server after the old server failed based on an encrypted >> ticket that is sent to the client and presented at the new server >> during session setup. >> >> Ciao >> Hannes >> >> Tolga Asveren wrote: >> >>> Hi Ulf, Hannes and all, >>> >>> I feel like now we are ready for detailed >>> >> investigation/documentation of the >> >>> problems/choices we discussed. >>> >>> What would be a good way to proceed, producing drafts? If so, >>> >> what would be >> >>> the content? To me it makes sense to start with a draft which >>> explains different choices, their applicability and how they handle >>> different functional aspects (notification of clients, transfer of >>> >> session data, load >> >>> distribution etc...) Some of the methods described may require >>> separate drafts defining new messages/AVPs. >>> >>> Another alternative is to continue discussing with e-mail >>> >> messages on the >> >>> list but I think this started to get a little bit hard to >>> >> follow and we may >> >>> loose track of issues discussed. >>> >>> Thanks, >>> Tolga >>> >>> >>> >>>> i- Client triggered refresh upon expiry of a timer on the >>>> >> client This is >> >>>> essentially the soft state case, where the client can send a >>>> message to an alternate server after expiry of a protocol timer >>>> with enough information embedded in the message, so that the >>>> alternate server can process it. >>>> >>>> [Ulf2] Yes. >>>> >>>> ii- Client triggered refresh upon receipt of an error answer >>>> Similar to i-, except that it is triggered upon receip of an >>>> > "UNABLE_TO_DELIVER" > >>>> error answer. >>>> >>>> [Ulf2] Question for clarificaiton; would this mean to refresh all >>>> session states associated with the target that could not be >>>> reached, or just the session for which the error was given? >>>> >>>> iii- Peer triggered state data transfer upon receipt of a >>>> notification from a peer This is the approach described in the >>>> draft-calhoun-diameter-res-mgmt-08.txt >>>> >>>> [Ulf2] Ok. >>>> >>>> iv- Peer triggered refresh >>>> This is similar to iii- but relies on the application messages to >>>> rebuild the state. A notification message is sent from a peer >>>> informing the client that a server went down. The client refreshes >>>> >> sessions on the >> >>>> alternate server. The message can be sent immediately after >>>> receiving the notification or could be delayed till the >>>> corresponding session(s) actually require a message to be sent to >>>> > update/delete. > >>>> [Ulf2] Ok. What come to my mind though is the amount of >>>> >> messages that'll >> >>>> be generated (this concern applies also to ii in case all >>>> >> session states >> >>>> are to be refreshed). In my view some recommendations on how to >>>> control the rate of messages and/or to make it driven by a receiver >>>> > > >>>> of the updates would be needed. I might be jumping ahead too quick >>>> to the solution now though. >>>> >>>> i and ii seem to work with existing Diameter wisdom, but they may >>>> run into issues, if servers also generate autonomous requests to >>>> clients (actually this would probably answer the question I asked >>>> in a previous message about the necessity of resurrection >>>> sessions/states on backup servers immediately after they take over >>>> the role of a failed host) >>>> >>>> [Ulf2] Yes, autonomous requests/unsolicited call backs is a reason >>>> for resurrection sessions/states on backup servers. I believe an >>>> additional reason for why states should for some applications be >>>> resurrected is that the application are controlling access to >>>> > scarce resources (e.g. > >>>> RACS). >>>> >>>> For iii and iv, a backup peer needs to know which clients it needs >>>> to send a notification to. This probably can be synchronized >>>> between peers of a cluster. >>>> >>>> [Ulf2] Yes. >>>> >>>> It could be useful to think over different alternatives considering >>>> > > >>>> the RACS scenario. For RACS, which interface are we talking about, >>>> >> Gq', Rq , >> >>>> any or both? >>>> >>>> [Ulf2] I'm considering both Gq' and Rq as well as the corresponding >>>> > > >>>> interfaces as of ITU and 3GPP. I believe all your list items to >>>> applicable to those interfaces. Which specific approach that'll be >>>> adopted for each individual deployment (and by different vendors) >>>> remains to be seen. My personal belief is that most A-RACF >>>> >> entities (the >> >>>> part of RACS performing admission control) will replicate both >>>> session and reservation states. The A-RACF is likely to offer >>>> >> soft-state only to >> >>>> the SPDF (the part of RACS facing application frameworks such as >>>> > e.g. > >>>> SIP proxies). The SPDF will probably also replicate states and >>>> offer soft-state to its clients. The SPDF is however likely to also >>>> > > >>>> offer hard-state to some application frameworks (e.g. leased line >>>> application level servers). >>>> >>>> Given the above assumptions i and ii will be used without complete >>>> information in refresh messages to rebuld states. In addition, iii >>>> will be used to ensure syncronisation after failover (and >>>> potentially periodically between application and SPDF in the case >>>> > of hard-state). > >>>> Since states are replicated iv would not apply (if I understand the >>>> > > >>>> approach correctly it applies to non cases when data is not >>>> replicated only). However, for a deployment without replication for >>>> > e.g. > >> the A-RACF >> >>>> iv would however apply. >>>> >>>> >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/dime >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/dime >>>> >>>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >>> >>> > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jan 24 14:13:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9nYa-0007Eu-70; Wed, 24 Jan 2007 14:13:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9nYZ-0007Ep-0t for dime@ietf.org; Wed, 24 Jan 2007 14:13:15 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9nYX-0002hi-OG for dime@ietf.org; Wed, 24 Jan 2007 14:13:15 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l0OJD2s12726; Wed, 24 Jan 2007 14:13:03 -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: Issue or not Issue ? Date: Wed, 24 Jan 2007 13:13:01 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437112630947@zrc2hxm2.corp.nortel.com> In-Reply-To: <200701231041.58700.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Issue or not Issue ? Thread-index: Acc+0sFvjT9gA/eSSeiL2A4jDR16egBF+L+A From: "Ahmad Muhanna" To: "Julien Laganier" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Julien, Please see response inline. Regards, Ahmad =20 > -----Original Message----- > From: julien laganier [mailto:julien.laganier@gmail.com] On=20 > Behalf Of Julien Laganier > Sent: Tuesday, January 23, 2007 3:42 AM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: Julien Bournelle; dime@ietf.org > Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support:=20 > Issue or not Issue ? >=20 > Hi Ahmad, >=20 > Cutting a bit thru your message, I have some comments > below: >=20 > On Monday 22 January 2007 18:10, Ahmad Muhanna wrote: > > > > > >[...] > > > > [Ahmad] > > We are probably splitting hair here, apparently there are two=20 > > arguments here: >=20 > I don't think this is hair splitting. Understand the issue=20 > should be a prerequisite to solving it. [Ahmad] OK. >=20 > > 1. AAAz is an authorization server and since it has a security=20 > > relationship with the HA, AAAz relies on the HA to do two=20 > things: 1.1.=20 > > HA makes sure that the user has been authenticated by AAAn. 1.2. HA=20 > > will not send any Authorization requests for any user(s)=20 > who has not=20 > > been authenticated. > > > > (In normal conditions, the above two conditions are ALWAYS=20 > TRUE except=20 > > in one condition, HA has been > > compromised) >=20 > Right. So we both agree there's no problem unless the HA is=20 > compromised [Ahmad] Agree. >=20 > I think what the first step is to agree on a threat model. I=20 > do not agree that we should defend against a compromised HA.=20 > The HA should be deemed secure against attackers. >=20 > We have to place a limit on what is entity X when asking the=20 > question "what if entity X is compromised".=20 > Since nothing is really impossible in the real world, we=20 > cannot defend against compromission of any entity implicated=20 > in a protocol. Security is a tradeoff.=20 [Ahmad] I agree.=20 However, we need to capture this somewhere in the draft and if people are ok to live with the limitation without offering a solution to address it, hay. I am fine too. >=20 > More below... >=20 > > 2. AAAz is an authorization server and has a security=20 > association with=20 > > the HA, however, due to the fact that the HA could be=20 > compromised, a=20 > > process needs to be in place for the HA to ALWAYS provide the AAAz,=20 > > Authorization server, with a proof (token, > > etc.) that the user has been authenticated by AAAn. >=20 > OK, if HA can be compromised. But why are we stopping here?=20 > Why not considering the case where the AAAn is compromised?=20 > Is is it more likely for an HA to be compromised than for a AAAn? [Ahmad] I am not sure this will help resolving the issue. However, in my opinion, AAAn only respond to requests by nature and yes; I believe it is more secure than the HA for the simple fact that ONLY very specific traffic is allowed to the AAA server anyway. Right? >=20 > We really have to agree on a threat model first. >=20 > > I assume here that the difference in opinion is about the=20 > possibility=20 > > of the HA to be compromised or NOT. >=20 > Exactly. >=20 > Best, >=20 > --julien (L.) >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jan 24 17:06:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9qGX-0004Fz-BV; Wed, 24 Jan 2007 17:06:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9qGV-0004Fs-EQ for dime@ietf.org; Wed, 24 Jan 2007 17:06:47 -0500 Received: from inet-tsb5.toshiba.co.jp ([202.33.96.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9qGU-00027O-K9 for dime@ietf.org; Wed, 24 Jan 2007 17:06:47 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb5.toshiba.co.jp with ESMTP id l0OM6ieF003908; Thu, 25 Jan 2007 07:06:44 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id l0OM6iEN028955; Thu, 25 Jan 2007 07:06:44 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with ESMTP id HAA28954; Thu, 25 Jan 2007 07:06:44 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id l0OM6i9o025930; Thu, 25 Jan 2007 07:06:44 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id l0OM6ioG018340; Thu, 25 Jan 2007 07:06:44 +0900 (JST) Received: from steelhead ([172.30.24.105]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0JCE008C0833NPA1@mail.po.toshiba.co.jp>; Thu, 25 Jan 2007 07:06:44 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.63) (envelope-from ) id 1H9qGN-0003le-7V; Wed, 24 Jan 2007 14:06:39 -0800 Date: Wed, 24 Jan 2007 17:06:39 -0500 From: Yoshihiro Ohba Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Issue or notIssue ? In-reply-to: <7DBAFEC6A76F3E42817DF1EBE64CB026043BC087@FTRDMEL2.rd.francetelecom.fr> To: MORAND Lionel RD-CORE-ISS Message-id: <20070124220639.GB12447@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=euc-jp Content-transfer-encoding: quoted-printable Content-disposition: inline References: <7DBAFEC6A76F3E42817DF1EBE64CB026043BC087@FTRDMEL2.rd.francetelecom.fr> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: dime@ietf.org, Julien Laganier 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, On Tue, Jan 23, 2007 at 04:11:49PM +0100, MORAND Lionel RD-CORE-ISS wrote: > Hi Folks, >=20 > There is a new guy in the game ;) >=20 > After reviewing the draft and the mail exchange on the topic, I would say= that the conclusion on "issue/no issue" depends on the side you are consid= ering the problem (as often ;). >=20 > If you are considering the AAA-MIP6 as a "simple" database providing the = HA with specific user/service information after a separate authentication (= performed with Diameter authentication), the username conveyed over the HA/= AAA-MIP6 is just used as a key entry in the database. There is no need for = the AAA-MIP6 to authenticate this username or to be sure that the username = was previously authenticated. The client of the database is the HA and not = the user. In that case, the AAA-MIP6 has to trust the HA and it is up to th= e HA to authenticate the username provided by the mn during the SA set-up. = This could be compared to interfaces between HSS (Home Subscriber Server) a= nd SIP application servers defined in the 3GPP architecture, over which Dia= meter applications are used to access database. =20 >=20 > In this context, the HA may use: > 1) the Diameter EAP application to authenticate the user. =20 > 2) the Diameter MIP6 application to download user related service informa= tion > Authentication and authorization are performed by the AAA-EAP. But there = is no way for the AAA-EAP to know what is the service requested by the user= =2E Successful authentication implies implicte authorization. This is the p= roblem with Diameter EAP as it is not possible to route Diameter EAP reques= t to a service-specific EAP server. If AAA-MIP6 provides authorizatin, AAA-EAP provides authentication, but does not provide authorization. For this purpose, the HA needs to set Auth-Request-Type set to AUTHENTICATE_ONLY in AAA-EAP. In this case, AAA-EAP server does not need to know what kind of authorization will be made. The authorization decision will be made by AAA-MIP6. Am I missing something? >=20 > In another hand, if the AAA-MIP6 is an authority handling MIP6 service ac= cess authorization rights i.e. the AAA-MIP6 must verify that the user is au= thorized to use the Mobile IPv6 service, this authority has to be able to v= erify the identity of the user before authorizing this user to access the s= ervice. It is not possible to authorize someone to do something without bei= ng sure of its identity as the authority must stand surety of the user acce= ss rights. Now, it is not possible to rely on the Diameter EAP application = to perform the authentication procedure as there is no way to direct the Di= ameter EAP requests to a specifc EAP server (as the Diameter routing is bas= ed on App-Id and Realm). We might think about some specific things to link = authentication procedures and authorization/service profile handling. But f= or me, the simpliest way would be to define the required authentication mec= hanism within one and only one application i.e. the application that requir= es this authentication. Therefore, Diameter EAP would not be used and appli= cation-specific commands would be specified in the application. One command= pair would be added to the Diameter MIP6 application. And to support EAP, = AVPs defined in 4072 would be at least (re-)used. I don't understand the difference between the two cases you mentioned above. I believe that more or less the AAA servers need to trust the HA in both cases. Depending on threat model which we don't seem to exactly know right now, the AAA-MIP6 server may or may not need an evidence that the user has been authenticated by a AAA-EAP server. >=20 > IMHO, the context described in the draft looks like more a service access= authorization management than the use of a simple external database. I wou= ld be therefore in favor of defining authentication commands within the Dia= meter MIP6 application instead of trying to reuse the Diameter EAP applicat= ion, which is not possible without modifications. EAP authentication and MI= P6 service access authorization are performed with the same application. Si= nce a application-Id is whatever needed for the HA/AAA-MIP6, what would be = the benefit to look for solutions binding Diameter EAP and Diameter MIP6 (w= ith some key derivation, etc.) while a single Diameter MIP6 application wit= h intrinsic authentication commands would be fully appropriate? I don't understand what is the point of discussing "service access authorization management" and "simple external database". If MIP6 application needs to support multiple authentication methods such as EAP and RFC 4285, I believe it is more appropriate to consider separation of authentication and authorization if security is reasonably handled. Also, there is some authentication method (e.g., authentication based on IKEv2-cert without using EAP) does not require any AAA interacation for authentication. I was pointing this out several times but no one seems to pay attention to it. >=20 > I'm pretty sure that the content of this mail may be challenged line by l= ine ;) But at the end, if authentication and authorization are needed to pr= ovide MIP6 services, why do not having a single application to do it? Of co= urse, I don't say that it would not be possible to do something more comple= x... To me, discussion on coupling vs. decoupling authentication and authorization is not just a MIP6 issue. This is a fundamental discussion that will decide the future direction of AAA. Yoshihiro Ohba >=20 > BR, >=20 > Lionel >=20 >=20 > > -----Message d'origine----- > > De : Julien Laganier [mailto:julien.IETF@laposte.net]=20 > > Envoy=8F=AB=B1 : mardi 23 janvier 2007 10:42 > > =8F=AA=A2 : Ahmad Muhanna > > Cc : dime@ietf.org > > Objet : Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support:=20 > > Issue or notIssue ? > >=20 > > Hi Ahmad, > >=20 > > Cutting a bit thru your message, I have some comments > > below: > >=20 > > On Monday 22 January 2007 18:10, Ahmad Muhanna wrote: > > > > > > > > >[...] > > > > > > [Ahmad] > > > We are probably splitting hair here, apparently there are two=20 > > > arguments here: > >=20 > > I don't think this is hair splitting. Understand the issue=20 > > should be a prerequisite to solving it. > >=20 > > > 1. AAAz is an authorization server and since it has a security=20 > > > relationship with the HA, AAAz relies on the HA to do two=20 > > things: 1.1.=20 > > > HA makes sure that the user has been authenticated by AAAn. 1.2. HA= =20 > > > will not send any Authorization requests for any user(s)=20 > > who has not=20 > > > been authenticated. > > > > > > (In normal conditions, the above two conditions are ALWAYS=20 > > TRUE except=20 > > > in one condition, HA has been > > > compromised) > >=20 > > Right. So we both agree there's no problem unless the HA is=20 > > compromised > >=20 > > I think what the first step is to agree on a threat model. I=20 > > do not agree that we should defend against a compromised HA.=20 > > The HA should be deemed secure against attackers. > >=20 > > We have to place a limit on what is entity X when asking the=20 > > question "what if entity X is compromised".=20 > > Since nothing is really impossible in the real world, we=20 > > cannot defend against compromission of any entity implicated=20 > > in a protocol. Security is a tradeoff.=20 > >=20 > > More below... > >=20 > > > 2. AAAz is an authorization server and has a security=20 > > association with=20 > > > the HA, however, due to the fact that the HA could be=20 > > compromised, a=20 > > > process needs to be in place for the HA to ALWAYS provide the AAAz,= =20 > > > Authorization server, with a proof (token, > > > etc.) that the user has been authenticated by AAAn. > >=20 > > OK, if HA can be compromised. But why are we stopping here?=20 > > Why not considering the case where the AAAn is compromised?=20 > > Is is it more likely for an HA to be compromised than for a AAAn? > >=20 > > We really have to agree on a threat model first. > >=20 > > > I assume here that the difference in opinion is about the=20 > > possibility=20 > > > of the HA to be compromised or NOT. > >=20 > > Exactly. > >=20 > > Best, > >=20 > > --julien (L.) > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > >=20 > >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jan 24 17:12:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9qLp-0006cP-Ke; Wed, 24 Jan 2007 17:12:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9qLn-0006Vj-S2 for dime@ietf.org; Wed, 24 Jan 2007 17:12:15 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9qKo-000386-BW for dime@ietf.org; Wed, 24 Jan 2007 17:11:15 -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 95881CE351 for ; Wed, 24 Jan 2007 17:11: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 l0OMBDIv022855 for ; Wed, 24 Jan 2007 17:11:13 -0500 (EST) From: "Tolga Asveren" To: Date: Wed, 24 Jan 2007 17:07:10 -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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [Dime] The Auditing Problem : Ownership of resources 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 Ulf, I wanted to dig in a bit more into the ownership of resources concept, which came up during the last couple of e-mails we exchanged for auditing problem. This again is probably a relatively side-issue but still it could be good to clarify it. I see the following elements in this problem: a) User to physical address mapping I guess, in the context of this problem we assume this is already done and this mapping data can be accessed by other entities. b) Delivery of user resource reservation request This will happen with a Diameter request from Diameter client to Diameter server. c) Policy enforcement Diameter server enforces policy based on user identity and the policy applicable for the user. d) Reserving/Providing the physical resource The Diameter server queries the physical mapping for the user and requests reservation of the resources from the physical device providing the resource (e.g. a router). Depending on the answer received from the device providing the resource, Diameter server generates the answer to the Diameter client. In this model, physical device would always have the information of all reservations for which it is providing the resources. Even after a Diameter server restart/backup takeover, physical device can approve/disapprove new reservation requests based on that information, i.e. the check to make sure that resources are not overbooked can be done on the physical resource provider (Diameter server still would perform policy enforcement) It could be the case that c) and d) is performed in the same entity. In such a case failure of that entity would cause the resources to be unavailable and after a restart all of the resources would be available. I am not claiming this is the only way of reserving the resources, nor the best way. I just wanted to clarify the model I had in mind regarding ownership/reservation of resources. Thanks, Tolga _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jan 24 17:44:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9qqg-0000uE-Uk; Wed, 24 Jan 2007 17:44:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9qqg-0000u8-3i for dime@ietf.org; Wed, 24 Jan 2007 17:44:10 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9qqe-0008Kq-C9 for dime@ietf.org; Wed, 24 Jan 2007 17:44:10 -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 57A5A8B6BC for ; Wed, 24 Jan 2007 17:44:03 -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 l0OMhufE024335 for ; Wed, 24 Jan 2007 17:44:00 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] The Auditing Problem: Possible approaches Date: Wed, 24 Jan 2007 17:39:52 -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) Importance: Normal In-Reply-To: <45B7AB67.7040103@gmx.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 8df1ceff7d5e1ba4a25ab9834397277b 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, Please see below for questions/comments. Thanks, Tolga > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Wednesday, January 24, 2007 1:55 PM > To: Tolga Asveren > Cc: dime@ietf.org > Subject: Re: [Dime] The Auditing Problem: Possible approaches > > > Hi Tolga, > > thanks for the nice summary. Please find my response below: > > > Tolga Asveren wrote: > > Hi Hannes, > > > > Let me try to summarize the discussion till now (or better said my > > understanding of it) and try to answer your questions (Ulf, > please feel free > > to add, correct etc...) > > > > > >> >From functionality point of view, I see three different pieces (which > >> > > probbaly will answer your first two questions and possibly the > third one to > > some degree): > > > > 1- Notification of client about server failure > > a) Relying on an application layer timer > > The protocol specification mandates periodic messaging from > client to server > > and use of a timer for the maximum allowed time to wait for a > corresponding > > answer, e.g. Diameter Credit Control Application. If no answer > is received > > in time, the server is assumed as down. This is the soft state > approach. For > > this to work, there is no need to change anything in the base Diameter > > infrastructure, application protocol authors need to define the periodic > > messaging behavior. > > > > > Ok > > > b) Relying on receipt of an error answer > > Here again we assume that the client is sending periodic > requests during a > > session. Because mid-session requests will have a > Destination-Host AVP, if > > an UNABLE_TO_DELIVER answer is received, this would be > interpreted as the > > server being down. Here, we assume that Diaemter network is properly > > engineered, i.e. transport problems won't cause a message not being > > delivered successfully. This aproach is similar to a), probably > will be used > > if Tw granularity on the message path is acceptable for the application. > > Again, what is needed is that application protocol authors > defining periodci > > mid-session requests mechanism. > > > > > This approach assumes that there is an intermediate node that provides > the error message or that the error message is offered from a lower layer. > > > c) A notification from the backup server > > When the backup server detects failure of an active server and > is ready to > > take over its responsibilities, it sends a notification to the > clients, with > > which the active server had ongoing sessions. The identity of > such clients > > needs to be synchronized between active and standby servers. Currently, > > there is no generic message defined in Diameter for this purpose. Such a > > message could be defined by applications or we can have a generic one. > > > With this approach the backup server at least has to know Session IDs > and Diameter client identifiers. [TOLGA]I guess the need for the knowledge of Session-Id may be avoided. Diameter client would probably be able to determine sessions to be transferred to the backup server based on the identity of the failed active server. > > It would also be necessary to determine (on a per-application basis) > which state the Diameter client would sent back to the Diameter server. > The state that is kept at the server and at the client might be different. [TOLGA]This is one of the key issues. What comprises the state should be defined by the protocol specification of the corresponding application and servers should be able to reconstruct a working context based on that. > > I could also imagine that there are security issues: The Diameter client > might not know the backup server and hence any arbitrary server could > just retrieve state from the client. [TOLGA]Maybe that active server provides a list of backup candidates could help. > > > 2- Transfer of session state data > > a) Using application messages > > Mid-session application messages can be used to transfer the state data > > > > I am not sure why you mean that it would be a mid-session message? > Who would sent the message? [TOLGA]I was referring to the case that a mid-session message is sent from client to server. Let's asume the client is sending periodic requests to the server during the session. If an answer is not received for such a request in a predetermined amount of time, the request could be resent to an alternate server. Alternatively, the client could start a new session to a new server for the saem user service context. > > > Applications can define an AVP to mark that certain mid-session > request is a > > "refresh" or this could be done with a separate mid-session application > > message. The message should carry enough information to > reconstruct session > > state at the server. If a special application message is used, > this could > > carry session state for multiple sessions. > > > > b) Using a generic message > > A generic message can be defined to carry session data to the > backup server. > > In this approach, although the message itself could be generic, > still each > > application needs to define the content of the message so that > it contains > > enough information to recosntruct the state. > > > I think that there are three possible modes: > > (*) State is sent from the Diameter server to the Diameter client and in > case of a failure from the Diameter client to the Diameter backup server. > This is similar to what is done with RFC 4507. This approach does not > require state to be synchronized between the backup and the original > Diameter server. > > (**) The backup server asks the Diameter client for a state transfer > from the client to the backup server. This obviously requires state > synchronization between the two Diameter servers to let the backup > server to know the identity of the Diameter client. > > (***) The Diameter client knows the backup server and contacts it when > the main server is not reachable anymore. > > > 3- Backup Server Selection / Load Distribution > > a) Backup information fed by the active server > > Information about backup servers could be sent to clients by the active > > server, when it was up and running. This information could > indicate on a per > > session basis, which backup server should be used for that particulat > > session if the active server fails before the session terminates. > > Alternatively, a list of backup servers with priorities could > be indicated, > > which is applicable for all sessions. > > > Agree. > > > b) Acceptable load fed by backup server > > If the backup server sendsa notification to the client ( approach c) for > > issue 1) ), the notification may contain number of sessions, > backup server > > is willing to take over. > > > > > True. > > > c) Trial and error > > Client sends messages to backup server candidates. If the > answer result code > > is not SUCCESS, it tries another one. > > > > > > Another important question seems to be, when does the need > arise for servers > > to trigger the session reconstruction mechanism rather than > waiting for the > > client to send a message for that purpose. AFAICS, we came up with two > > different reasons for this: > > a) The server needs to send autonomous requests to the client, > e.g. for some > > type of periodic reporting > > b) The server needs to know about existing sessions at any > given time to be > > able to process new sessions requests properly, e.g. so that it can know > > whether accepting a new reservation would exceed the available free > > resources (I didn't think abouth this throughly but I feel like > this can be > > done just by relying on responses from the physical owner of resources > > rather than relying on Diameter session state) > > > > I checked briefly RFC4507 you mentioned. There it seems for 1- a) and b) > > (depending on whether the host or the application crashes), for > 2- a), for > > 3- c) is used. > > > It would probably be something like 1a or 1b but the details are not > mentioned. > > Not sure about (2) since I have some questions. > > Regarding 3c: > > > > What makes this problem interesting is that at the end it will be the > > decision of the application protocol author what counts. What > we can provide > > is some guidelines about different protocol design choices and > if we see it > > necesary some generic infrastructure messages/AVPs. > > > > Thanks, > > Tolga > > > > > > > > Ciao > Hannes > > >> -----Original Message----- > >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> Sent: Tuesday, January 23, 2007 2:35 PM > >> To: Tolga Asveren > >> Cc: dime@ietf.org > >> Subject: Re: [Dime] The Auditing Problem: Possible approaches > >> > >> > >> Hi Tolga, > >> > >> I went through the discussion thread and noticed that it is > indeed a bit > >> difficult to follow the individual issues. > >> > >> Your mail entitled with "[Dime] The Auditing Problem: Possible > >> approaches" > >> http://www1.ietf.org/mail-archive/web/dime/current/msg01196.html > >> might be a good starting point for further descriptions. > >> > >> I am interested in a description that tells me: > >> * How and who detects the failure of the server? > >> * What messages need to be exchanged to establish the state at the new > >> server? > >> * What are the assumptions made with each proposal? > >> > >> Let us consider other protocols with respect to their ability to deal > >> with server failure, such as: > >> > >> ftp://ftp.isi.edu/in-notes/rfc4507.txt > >> http://www.ietf.org/internet-drafts/draft-sheffer-ike-session-resu > >> mption-00.txt > >> > http://www.ietf.org/internet-drafts/draft-vidya-ipsec-failover-ps-00.txt > >> > >> > >> The first two documents explain a procedure to quickly establish state > >> at a new server after the old server failed based on an > encrypted ticket > >> that is sent to the client and presented at the new server during > >> session setup. > >> > >> Ciao > >> Hannes > >> > >> Tolga Asveren wrote: > >> > >>> Hi Ulf, Hannes and all, > >>> > >>> I feel like now we are ready for detailed > >>> > >> investigation/documentation of the > >> > >>> problems/choices we discussed. > >>> > >>> What would be a good way to proceed, producing drafts? If so, > >>> > >> what would be > >> > >>> the content? To me it makes sense to start with a draft which explains > >>> different choices, their applicability and how they handle different > >>> functional aspects (notification of clients, transfer of > >>> > >> session data, load > >> > >>> distribution etc...) Some of the methods described may > require separate > >>> drafts defining new messages/AVPs. > >>> > >>> Another alternative is to continue discussing with e-mail > >>> > >> messages on the > >> > >>> list but I think this started to get a little bit hard to > >>> > >> follow and we may > >> > >>> loose track of issues discussed. > >>> > >>> Thanks, > >>> Tolga > >>> > >>> > >>> > >>>> i- Client triggered refresh upon expiry of a timer on the > >>>> > >> client This is > >> > >>>> essentially the soft state case, where the client can send a > message to > >>>> an alternate server after expiry of a protocol timer with enough > >>>> information embedded in the message, so that the alternate server can > >>>> process it. > >>>> > >>>> [Ulf2] Yes. > >>>> > >>>> ii- Client triggered refresh upon receipt of an error answer > Similar to > >>>> i-, except that it is triggered upon receip of an "UNABLE_TO_DELIVER" > >>>> error answer. > >>>> > >>>> [Ulf2] Question for clarificaiton; would this mean to refresh all > >>>> session states associated with the target that could not be > reached, or > >>>> just the session for which the error was given? > >>>> > >>>> iii- Peer triggered state data transfer upon receipt of a > notification > >>>> from a peer This is the approach described in the > >>>> draft-calhoun-diameter-res-mgmt-08.txt > >>>> > >>>> [Ulf2] Ok. > >>>> > >>>> iv- Peer triggered refresh > >>>> This is similar to iii- but relies on the application messages to > >>>> rebuild the state. A notification message is sent from a > peer informing > >>>> the client that a server went down. The client refreshes > >>>> > >> sessions on the > >> > >>>> alternate server. The message can be sent immediately after receiving > >>>> the notification or could be delayed till the corresponding > session(s) > >>>> actually require a message to be sent to update/delete. > >>>> > >>>> [Ulf2] Ok. What come to my mind though is the amount of > >>>> > >> messages that'll > >> > >>>> be generated (this concern applies also to ii in case all > >>>> > >> session states > >> > >>>> are to be refreshed). In my view some recommendations on how > to control > >>>> the rate of messages and/or to make it driven by a receiver of the > >>>> updates would be needed. I might be jumping ahead too quick to the > >>>> solution now though. > >>>> > >>>> i and ii seem to work with existing Diameter wisdom, but they may run > >>>> into issues, if servers also generate autonomous requests to clients > >>>> (actually this would probably answer the question I asked in > a previous > >>>> message about the necessity of resurrection sessions/states on backup > >>>> servers immediately after they take over the role of a failed host) > >>>> > >>>> [Ulf2] Yes, autonomous requests/unsolicited call backs is a > reason for > >>>> resurrection sessions/states on backup servers. I believe an > additional > >>>> reason for why states should for some applications be resurrected is > >>>> that the application are controlling access to scarce resources (e.g. > >>>> RACS). > >>>> > >>>> For iii and iv, a backup peer needs to know which clients it needs to > >>>> send a notification to. This probably can be synchronized > between peers > >>>> of a cluster. > >>>> > >>>> [Ulf2] Yes. > >>>> > >>>> It could be useful to think over different alternatives > considering the > >>>> RACS scenario. For RACS, which interface are we talking about, > >>>> > >> Gq', Rq , > >> > >>>> any or both? > >>>> > >>>> [Ulf2] I'm considering both Gq' and Rq as well as the corresponding > >>>> interfaces as of ITU and 3GPP. I believe all your list items to > >>>> applicable to those interfaces. Which specific approach that'll be > >>>> adopted for each individual deployment (and by different vendors) > >>>> remains to be seen. My personal belief is that most A-RACF > >>>> > >> entities (the > >> > >>>> part of RACS performing admission control) will replicate > both session > >>>> and reservation states. The A-RACF is likely to offer > >>>> > >> soft-state only to > >> > >>>> the SPDF (the part of RACS facing application frameworks such as e.g. > >>>> SIP proxies). The SPDF will probably also replicate states and offer > >>>> soft-state to its clients. The SPDF is however likely to also offer > >>>> hard-state to some application frameworks (e.g. leased line > application > >>>> level servers). > >>>> > >>>> Given the above assumptions i and ii will be used without complete > >>>> information in refresh messages to rebuld states. In > addition, iii will > >>>> be used to ensure syncronisation after failover (and potentially > >>>> periodically between application and SPDF in the case of hard-state). > >>>> Since states are replicated iv would not apply (if I understand the > >>>> approach correctly it applies to non cases when data is not > replicated > >>>> only). However, for a deployment without replication for e.g. > >>>> > >> the A-RACF > >> > >>>> iv would however apply. > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> DiME mailing list > >>>> DiME@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/dime > >>>> > >>>> _______________________________________________ > >>>> DiME mailing list > >>>> DiME@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/dime > >>>> > >>>> > >>> _______________________________________________ > >>> DiME mailing list > >>> DiME@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/dime > >>> > >>> > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 25 02:57:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9zTc-0004MN-Gz; Thu, 25 Jan 2007 02:56:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9zTb-0004MI-B1 for dime@ietf.org; Thu, 25 Jan 2007 02:56:55 -0500 Received: from smtp.operax.com ([213.50.74.226] helo=smtp-dmz.operax.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9zTZ-0003Mp-2m for dime@ietf.org; Thu, 25 Jan 2007 02:56:55 -0500 Received: from lulex02.ad.operax.com (ad.operax.com [192.168.2.13]) by smtp-dmz.operax.com (8.13.1/8.13.1) with ESMTP id l0P7ui07089417 for ; Thu, 25 Jan 2007 08:56:44 +0100 (CET) (envelope-from Ulf.Bodin@operax.com) 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] The Auditing Problem: Possible approaches Date: Thu, 25 Jan 2007 08:56:43 +0100 Message-ID: <33656995C5C5094A983DE84DA649A924EB19C0@lulex02.ad.operax.com> In-Reply-To: <45B7ACC2.4080405@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] The Auditing Problem: Possible approaches Thread-Index: Acc/6e3CR8cWm/gARReVyZz7roxzMwAaoQsg From: "Ulf Bodin" To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (smtp-dmz.operax.com [172.16.1.4]); Thu, 25 Jan 2007 08:56:44 +0100 (CET) X-Spam-Status: No, score=-52.6 required=4.7 tests=ALL_TRUSTED,BAYES_00, USER_IN_BLACKLIST autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on smtp-dmz.operax.com X-Virus-Scanned: ClamAV 0.88.7/2487/Wed Jan 24 16:53:17 2007 on smtp-dmz.operax.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8e9fbe727bc2159b431d624c595c1eab 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: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: den 24 januari 2007 20:00 To: Ulf Bodin Cc: dime@ietf.org Subject: Re: [Dime] The Auditing Problem: Possible approaches Hi Ulf, Ulf Bodin wrote: > Hi Tolga and Hannes, > > I agree to the summary as of below, but would like to add a few pieces:=20 > 1) Prior to transferring session state data I believe for the case of=20 > state replication that either part would benefit from a way to query=20 > the other part for a list of active sessions (i.e. to synchronize the=20 > views of clients and their server). This is useful e.g. to not=20 > unnecessarily send state information for states that have been sucessfully replicated. > > =20 Wouldn't be the right way to ensure that you are only authorized to retrieve the state that you previously created. [Ulf] Good point. A query from a client should not result in that the reserver returns a list of all its active sessions. It should only return those sessions installed by the querying client. =20 > 2) I think we need to explore client failover somewhat further. This=20 > applies to some of the bullets below: 1.a no messages from a client=20 > for for a period means its dead, 2.b and 2.c may apply if the server=20 > sends autonomous requests to the client. 2.a don't apply since state=20 > information don't normally travel in the direction from server to=20 > client, 2.b may apply since a generic message could be defined for=20 > usage in both directions. The 3.a, 3.b and 3.c approaches could be=20 > applied to the client side. > > Also, just a quick comment to the session reconstruction and/or=20 > replication issue. I agree to a) and for b) I would like to add that I > see the Diameter server as the physical owner of the mentioned=20 > resources. I might miss something here, but in my view that means to=20 > rely on Dimater sesison state. > > =20 I agree that we also have to consider client failover. At the moment we are still focusing on the server failover case. The two might be a bit different. [Ulf] Ok. I try to be a litte more patient :-).=20 >> >From my perspective it might be a good time to gather information in >> >a >> =20 > draft as you suggest Hannes. I'm not completely sure exactly how sujch > draft would materialize. Explaining different choices, thri=20 > applicability and how thay handle different functional aspects sounds=20 > good to me (starting from the list below). > > =20 I have one question for you: Do you consider a stateless solution at the backup server, i.e., where the backup server does not ever store Session Ids or the identities of the Diameter clients? [Ulf] Yes, I see that as an option. In my view list item 2 in Tolga's list can apply to both the case of when the backup server is completely stateless and when it has access to replicated session data. In both cases I agree to that we need a method to differentiate between mid-session updates and initial messages creating a new session. In both Gq (3GPP) and Gq' (TISPAN) mid-session messages are separated from initial message by known and unknown session ids only. A flag making this separation or a separate messages is clearly needed (generic or application specific).=20 Ciao Hannes > Best regards, > Ulf > > -----Original Message----- > From: Tolga Asveren [mailto:asveren@ulticom.com] > Sent: den 23 januari 2007 23:12 > To: dime@ietf.org > Subject: RE: [Dime] The Auditing Problem: Possible approaches > > Hi Hannes, > > Let me try to summarize the discussion till now (or better said my=20 > understanding of it) and try to answer your questions (Ulf, please=20 > feel free to add, correct etc...) > > =20 >> >From functionality point of view, I see three different pieces=20 >> >(which >> =20 > probbaly will answer your first two questions and possibly the third=20 > one to some degree): > > 1- Notification of client about server failure > a) Relying on an application layer timer The protocol specification=20 > mandates periodic messaging from client to server and use of a timer=20 > for the maximum allowed time to wait for a corresponding answer, e.g. > Diameter Credit Control Application. If no answer is received in time, > the server is assumed as down. This is the soft state approach. For=20 > this to work, there is no need to change anything in the base Diameter > infrastructure, application protocol authors need to define the=20 > periodic messaging behavior. > > b) Relying on receipt of an error answer Here again we assume that the > client is sending periodic requests during a session. Because=20 > mid-session requests will have a Destination-Host AVP, if an=20 > UNABLE_TO_DELIVER answer is received, this would be interpreted as the > server being down. Here, we assume that Diaemter network is properly=20 > engineered, i.e. transport problems won't cause a message not being=20 > delivered successfully. This aproach is similar to a), probably will=20 > be used if Tw granularity on the message path is acceptable for the=20 > application. > Again, what is needed is that application protocol authors defining=20 > periodci mid-session requests mechanism. > > c) A notification from the backup server When the backup server=20 > detects failure of an active server and is ready to take over its=20 > responsibilities, it sends a notification to the clients, with which=20 > the active server had ongoing sessions. The identity of such clients=20 > needs to be synchronized between active and standby servers.=20 > Currently, there is no generic message defined in Diameter for this=20 > purpose. Such a message could be defined by applications or we can have a generic one. > > 2- Transfer of session state data > a) Using application messages > Mid-session application messages can be used to transfer the state data. > Applications can define an AVP to mark that certain mid-session=20 > request is a "refresh" or this could be done with a separate=20 > mid-session application message. The message should carry enough=20 > information to reconstruct session state at the server. If a special=20 > application message is used, this could carry session state for multiple sessions. > > b) Using a generic message > A generic message can be defined to carry session data to the backup=20 > server. > In this approach, although the message itself could be generic, still=20 > each application needs to define the content of the message so that it > contains enough information to recosntruct the state. > > 3- Backup Server Selection / Load Distribution > a) Backup information fed by the active server Information about=20 > backup servers could be sent to clients by the active server, when it=20 > was up and running. This information could indicate on a per session=20 > basis, which backup server should be used for that particulat session=20 > if the active server fails before the session terminates. > Alternatively, a list of backup servers with priorities could be=20 > indicated, which is applicable for all sessions. > > b) Acceptable load fed by backup server If the backup server sendsa=20 > notification to the client ( approach c) for issue 1) ), the=20 > notification may contain number of sessions, backup server is willing=20 > to take over. > > c) Trial and error > Client sends messages to backup server candidates. If the answer=20 > result code is not SUCCESS, it tries another one. > > > Another important question seems to be, when does the need arise for=20 > servers to trigger the session reconstruction mechanism rather than=20 > waiting for the client to send a message for that purpose. AFAICS, we=20 > came up with two different reasons for this: > a) The server needs to send autonomous requests to the client, e.g.=20 > for some type of periodic reporting > b) The server needs to know about existing sessions at any given time=20 > to be able to process new sessions requests properly, e.g. so that it=20 > can know whether accepting a new reservation would exceed the=20 > available free resources (I didn't think abouth this throughly but I=20 > feel like this can be done just by relying on responses from the=20 > physical owner of resources rather than relying on Diameter session=20 > state) > > I checked briefly RFC4507 you mentioned. There it seems for 1- a) and=20 > b) (depending on whether the host or the application crashes), for 2-=20 > a), for > 3- c) is used. > > What makes this problem interesting is that at the end it will be the=20 > decision of the application protocol author what counts. What we can=20 > provide is some guidelines about different protocol design choices and > if we see it necesary some generic infrastructure messages/AVPs. > > Thanks, > Tolga > > > =20 >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Tuesday, January 23, 2007 2:35 PM >> To: Tolga Asveren >> Cc: dime@ietf.org >> Subject: Re: [Dime] The Auditing Problem: Possible approaches >> >> >> Hi Tolga, >> >> I went through the discussion thread and noticed that it is indeed a=20 >> bit difficult to follow the individual issues. >> >> Your mail entitled with "[Dime] The Auditing Problem: Possible=20 >> approaches" >> http://www1.ietf.org/mail-archive/web/dime/current/msg01196.html >> might be a good starting point for further descriptions. >> >> I am interested in a description that tells me: >> * How and who detects the failure of the server? >> * What messages need to be exchanged to establish the state at the=20 >> new >> =20 > > =20 >> server? >> * What are the assumptions made with each proposal? >> >> Let us consider other protocols with respect to their ability to deal >> with server failure, such as: >> >> ftp://ftp.isi.edu/in-notes/rfc4507.txt >> http://www.ietf.org/internet-drafts/draft-sheffer-ike-session-resu >> mption-00.txt >> http://www.ietf.org/internet-drafts/draft-vidya-ipsec-failover-ps-00. >> t >> xt >> >> >> The first two documents explain a procedure to quickly establish=20 >> state >> =20 > > =20 >> at a new server after the old server failed based on an encrypted=20 >> ticket that is sent to the client and presented at the new server=20 >> during session setup. >> >> Ciao >> Hannes >> >> Tolga Asveren wrote: >> =20 >>> Hi Ulf, Hannes and all, >>> >>> I feel like now we are ready for detailed >>> =20 >> investigation/documentation of the >> =20 >>> problems/choices we discussed. >>> >>> What would be a good way to proceed, producing drafts? If so, >>> =20 >> what would be >> =20 >>> the content? To me it makes sense to start with a draft which=20 >>> explains different choices, their applicability and how they handle=20 >>> different functional aspects (notification of clients, transfer of >>> =20 >> session data, load >> =20 >>> distribution etc...) Some of the methods described may require=20 >>> separate drafts defining new messages/AVPs. >>> >>> Another alternative is to continue discussing with e-mail >>> =20 >> messages on the >> =20 >>> list but I think this started to get a little bit hard to >>> =20 >> follow and we may >> =20 >>> loose track of issues discussed. >>> >>> Thanks, >>> Tolga >>> >>> >>> =20 >>>> i- Client triggered refresh upon expiry of a timer on the >>>> =20 >> client This is >> =20 >>>> essentially the soft state case, where the client can send a=20 >>>> message to an alternate server after expiry of a protocol timer=20 >>>> with enough information embedded in the message, so that the=20 >>>> alternate server can process it. >>>> >>>> [Ulf2] Yes. >>>> >>>> ii- Client triggered refresh upon receipt of an error answer=20 >>>> Similar to i-, except that it is triggered upon receip of an >>>> =20 > "UNABLE_TO_DELIVER" > =20 >>>> error answer. >>>> >>>> [Ulf2] Question for clarificaiton; would this mean to refresh all=20 >>>> session states associated with the target that could not be=20 >>>> reached, or just the session for which the error was given? >>>> >>>> iii- Peer triggered state data transfer upon receipt of a=20 >>>> notification from a peer This is the approach described in the=20 >>>> draft-calhoun-diameter-res-mgmt-08.txt >>>> >>>> [Ulf2] Ok. >>>> >>>> iv- Peer triggered refresh >>>> This is similar to iii- but relies on the application messages to=20 >>>> rebuild the state. A notification message is sent from a peer=20 >>>> informing the client that a server went down. The client refreshes >>>> =20 >> sessions on the >> =20 >>>> alternate server. The message can be sent immediately after=20 >>>> receiving the notification or could be delayed till the=20 >>>> corresponding session(s) actually require a message to be sent to >>>> =20 > update/delete. > =20 >>>> [Ulf2] Ok. What come to my mind though is the amount of >>>> =20 >> messages that'll >> =20 >>>> be generated (this concern applies also to ii in case all >>>> =20 >> session states >> =20 >>>> are to be refreshed). In my view some recommendations on how to=20 >>>> control the rate of messages and/or to make it driven by a receiver >>>> =20 > > =20 >>>> of the updates would be needed. I might be jumping ahead too quick=20 >>>> to the solution now though. >>>> >>>> i and ii seem to work with existing Diameter wisdom, but they may=20 >>>> run into issues, if servers also generate autonomous requests to=20 >>>> clients (actually this would probably answer the question I asked=20 >>>> in a previous message about the necessity of resurrection=20 >>>> sessions/states on backup servers immediately after they take over=20 >>>> the role of a failed host) >>>> >>>> [Ulf2] Yes, autonomous requests/unsolicited call backs is a reason=20 >>>> for resurrection sessions/states on backup servers. I believe an=20 >>>> additional reason for why states should for some applications be=20 >>>> resurrected is that the application are controlling access to >>>> =20 > scarce resources (e.g. > =20 >>>> RACS). >>>> >>>> For iii and iv, a backup peer needs to know which clients it needs=20 >>>> to send a notification to. This probably can be synchronized=20 >>>> between peers of a cluster. >>>> >>>> [Ulf2] Yes. >>>> >>>> It could be useful to think over different alternatives considering >>>> =20 > > =20 >>>> the RACS scenario. For RACS, which interface are we talking about, >>>> =20 >> Gq', Rq , >> =20 >>>> any or both? >>>> >>>> [Ulf2] I'm considering both Gq' and Rq as well as the corresponding >>>> =20 > > =20 >>>> interfaces as of ITU and 3GPP. I believe all your list items to=20 >>>> applicable to those interfaces. Which specific approach that'll be=20 >>>> adopted for each individual deployment (and by different vendors)=20 >>>> remains to be seen. My personal belief is that most A-RACF >>>> =20 >> entities (the >> =20 >>>> part of RACS performing admission control) will replicate both=20 >>>> session and reservation states. The A-RACF is likely to offer >>>> =20 >> soft-state only to >> =20 >>>> the SPDF (the part of RACS facing application frameworks such as >>>> =20 > e.g. > =20 >>>> SIP proxies). The SPDF will probably also replicate states and=20 >>>> offer soft-state to its clients. The SPDF is however likely to also >>>> =20 > > =20 >>>> offer hard-state to some application frameworks (e.g. leased line=20 >>>> application level servers). >>>> >>>> Given the above assumptions i and ii will be used without complete=20 >>>> information in refresh messages to rebuld states. In addition, iii=20 >>>> will be used to ensure syncronisation after failover (and=20 >>>> potentially periodically between application and SPDF in the case >>>> =20 > of hard-state). > =20 >>>> Since states are replicated iv would not apply (if I understand the >>>> =20 > > =20 >>>> approach correctly it applies to non cases when data is not=20 >>>> replicated only). However, for a deployment without replication for >>>> =20 > e.g. > =20 >> the A-RACF >> =20 >>>> iv would however apply. >>>> >>>> >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/dime >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/dime >>>> >>>> =20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >>> >>> =20 > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ > 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 Jan 25 03:41:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA0AL-00037y-3k; Thu, 25 Jan 2007 03:41:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA0AK-00037o-Fj for dime@ietf.org; Thu, 25 Jan 2007 03:41:04 -0500 Received: from smtp.operax.com ([213.50.74.226] helo=smtp-dmz.operax.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA0AI-0007Uk-U8 for dime@ietf.org; Thu, 25 Jan 2007 03:41:04 -0500 Received: from lulex02.ad.operax.com (ad.operax.com [192.168.2.13]) by smtp-dmz.operax.com (8.13.1/8.13.1) with ESMTP id l0P8etjN089943 for ; Thu, 25 Jan 2007 09:40:56 +0100 (CET) (envelope-from Ulf.Bodin@operax.com) 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] The Auditing Problem : Ownership of resources Date: Thu, 25 Jan 2007 09:40:55 +0100 Message-ID: <33656995C5C5094A983DE84DA649A924EB19D0@lulex02.ad.operax.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] The Auditing Problem : Ownership of resources Thread-Index: AcdABMkcvomUq7inSHurbyNQMTPYiQAVPuKw From: "Ulf Bodin" To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (smtp-dmz.operax.com [172.16.1.4]); Thu, 25 Jan 2007 09:40:56 +0100 (CET) X-Spam-Status: No, score=-52.6 required=4.7 tests=ALL_TRUSTED,BAYES_00, USER_IN_BLACKLIST autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on smtp-dmz.operax.com X-Virus-Scanned: ClamAV 0.88.7/2487/Wed Jan 24 16:53:17 2007 on smtp-dmz.operax.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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,=20 I absolutely agree to that your scenario as of below is valid and I also agree that the physical device can be expected to correctly approve/disapprove new reservation requests after a failover of a Diameter server controlling the device.=20 The model defined by ETSI TISPAN differs from the above scenario in the sence that the Diameter server bing the so called A-RACF is a booking system for resources. It keeps knowledge of aggregate resources in the underlying transport network (e.g. bandwidth allocated to the DiffServ EF PHB on network interfaces) and may install policies for traffic conditioning in transport devices dedicated to that task (e.g. a BRAS). This means that reservations of resources are not knowned by network devices (i.e. except policies for traffic conditioning) and consequently the Diameter server cannot rely on states kept in network devices to correctly answer reservation reqiuests (before and after a failover).=20 Best regards,=20 Ulf=20 -----Original Message----- From: Tolga Asveren [mailto:asveren@ulticom.com]=20 Sent: den 24 januari 2007 23:07 To: dime@ietf.org Subject: [Dime] The Auditing Problem : Ownership of resources Hi Ulf, I wanted to dig in a bit more into the ownership of resources concept, which came up during the last couple of e-mails we exchanged for auditing problem. This again is probably a relatively side-issue but still it could be good to clarify it. I see the following elements in this problem: a) User to physical address mapping I guess, in the context of this problem we assume this is already done and this mapping data can be accessed by other entities. b) Delivery of user resource reservation request This will happen with a Diameter request from Diameter client to Diameter server. c) Policy enforcement Diameter server enforces policy based on user identity and the policy applicable for the user. d) Reserving/Providing the physical resource The Diameter server queries the physical mapping for the user and requests reservation of the resources from the physical device providing the resource (e.g. a router). Depending on the answer received from the device providing the resource, Diameter server generates the answer to the Diameter client. In this model, physical device would always have the information of all reservations for which it is providing the resources. Even after a Diameter server restart/backup takeover, physical device can approve/disapprove new reservation requests based on that information, i.e. the check to make sure that resources are not overbooked can be done on the physical resource provider (Diameter server still would perform policy enforcement) It could be the case that c) and d) is performed in the same entity. In such a case failure of that entity would cause the resources to be unavailable and after a restart all of the resources would be available. I am not claiming this is the only way of reserving the resources, nor the best way. I just wanted to clarify the model I had in mind regarding ownership/reservation of resources. Thanks, Tolga _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 25 06:11:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA2WG-0001AB-5J; Thu, 25 Jan 2007 06:11:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA2WF-0001A5-7k for dime@ietf.org; Thu, 25 Jan 2007 06:11:51 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA2WE-0006Bg-HM for dime@ietf.org; Thu, 25 Jan 2007 06:11:51 -0500 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 12:11:33 +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-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Issue or notIssue ? Date: Thu, 25 Jan 2007 12:11:23 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026043F74D2@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Issue or notIssue ? thread-index: AcdAA/r5nUIvzJ8ATjeXOadoEt8alwAWd2gA From: "MORAND Lionel RD-CORE-ISS" To: "Yoshihiro Ohba" X-OriginalArrivalTime: 25 Jan 2007 11:11:33.0310 (UTC) FILETIME=[92492DE0:01C74071] X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Cc: dime@ietf.org, Julien Laganier X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Yoshi, 1) If authentication procedures may be performed apart from authorization procedures (I totally agree), authorization procedures must be able to rely on its own authentication procedures if needed (cf. AAA requirements in RFC 2906). Are you OK with that? 2) As it is now, providing authentication with Diameter EAP application and authorization with Diameter MIP6 does not allow the AAA-MIP6 to be sure that the username carried in the authorization request was previously authenticated by the AAA-EAP. Are you OK with that? 3) If the AAA-MIP6 provides the HA with service related information without being sure that the key entry (username) was previously authenticated, what is the difference between the AAA-MIP6 and a "simple" external database providing information data to any authorized entity (HA in the present case)? What/where is the authorization process in that case? 4) If combining Diameter EAP and Diameter MIP6 is more complex than including authentication procedures with Diameter MIP6 that is coherent with AAA requirements, why are we still discussing as much? ;) 5) If the discussion is beyond the scope of the draft and related to the future of global AAA framework, why do not "decouple" the discussions and create a separate thread? But for now, I can see that a Diameter MIP6 application with authentication procedure would be consistent with the current AAA framework while a combinaison of Diameter EAP and Diameter MIP6 will not meet all the AAA requirements without introducing specific functionalites/enhancements. I would have no problem with a solution proposing EAP authentication procedures and MIP6 authorization procedures supported by to different diameter applications IF it could be possible to bind both procedures in the same equipment in the MSA. That is not the case with the current solution. BR, Lionel > > There is a new guy in the game ;) > > > > After reviewing the draft and the mail exchange on the > topic, I would say that the conclusion on "issue/no issue" > depends on the side you are considering the problem (as often ;). > > > > If you are considering the AAA-MIP6 as a "simple" database > providing the HA with specific user/service information after > a separate authentication (performed with Diameter > authentication), the username conveyed over the HA/AAA-MIP6 > is just used as a key entry in the database. There is no need > for the AAA-MIP6 to authenticate this username or to be sure > that the username was previously authenticated. The client of > the database is the HA and not the user. In that case, the > AAA-MIP6 has to trust the HA and it is up to the HA to > authenticate the username provided by the mn during the SA > set-up. This could be compared to interfaces between HSS > (Home Subscriber Server) and SIP application servers defined > in the 3GPP architecture, over which Diameter applications > are used to access database. > > > > In this context, the HA may use: > > 1) the Diameter EAP application to authenticate the user. > > 2) the Diameter MIP6 application to download user related service > > information Authentication and authorization are performed > by the AAA-EAP. But there is no way for the AAA-EAP to know > what is the service requested by the user. Successful > authentication implies implicte authorization. This is the > problem with Diameter EAP as it is not possible to route > Diameter EAP request to a service-specific EAP server. > > If AAA-MIP6 provides authorizatin, AAA-EAP provides > authentication, but does not provide authorization. For this > purpose, the HA needs to set Auth-Request-Type set to > AUTHENTICATE_ONLY in AAA-EAP. In this case, AAA-EAP server > does not need to know what kind of authorization will be > made. The authorization decision will be made by AAA-MIP6. > Am I missing something? > > > > > In another hand, if the AAA-MIP6 is an authority handling > MIP6 service access authorization rights i.e. the AAA-MIP6 > must verify that the user is authorized to use the Mobile > IPv6 service, this authority has to be able to verify the > identity of the user before authorizing this user to access > the service. It is not possible to authorize someone to do > something without being sure of its identity as the authority > must stand surety of the user access rights. Now, it is not > possible to rely on the Diameter EAP application to perform > the authentication procedure as there is no way to direct the > Diameter EAP requests to a specifc EAP server (as the > Diameter routing is based on App-Id and Realm). We might > think about some specific things to link authentication > procedures and authorization/service profile handling. But > for me, the simpliest way would be to define the required > authentication mechanism within one and only one application > i.e. the application that requires this authentication. > Therefore, Diameter EAP would not be used and > application-specific commands would be specified in the > application. One command pair would be added to the Diameter > MIP6 application. And to support EAP, AVPs defined in 4072 > would be at least (re-)used. > > I don't understand the difference between the two cases you > mentioned above. I believe that more or less the AAA servers > need to trust the HA in both cases. Depending on threat > model which we don't seem to exactly know right now, the > AAA-MIP6 server may or may not need an evidence that the user > has been authenticated by a AAA-EAP server. > > > > > IMHO, the context described in the draft looks like more a > service access authorization management than the use of a > simple external database. I would be therefore in favor of > defining authentication commands within the Diameter MIP6 > application instead of trying to reuse the Diameter EAP > application, which is not possible without modifications. EAP > authentication and MIP6 service access authorization are > performed with the same application. Since a application-Id > is whatever needed for the HA/AAA-MIP6, what would be the > benefit to look for solutions binding Diameter EAP and > Diameter MIP6 (with some key derivation, etc.) while a single > Diameter MIP6 application with intrinsic authentication > commands would be fully appropriate? > > I don't understand what is the point of discussing "service > access authorization management" and "simple external > database". If MIP6 application needs to support multiple > authentication methods such as EAP and RFC 4285, I believe it > is more appropriate to consider separation of authentication > and authorization if security is reasonably handled. Also, > there is some authentication method (e.g., authentication > based on IKEv2-cert without using EAP) does not require any > AAA interacation for authentication. I was pointing this out > several times but no one seems to pay attention to it. > > > > > I'm pretty sure that the content of this mail may be > challenged line by line ;) But at the end, if authentication > and authorization are needed to provide MIP6 services, why do > not having a single application to do it? Of course, I don't > say that it would not be possible to do something more complex... > > To me, discussion on coupling vs. decoupling authentication > and authorization is not just a MIP6 issue. This is a > fundamental discussion that will decide the future direction of AAA. > > Yoshihiro Ohba > > > > > BR, > > > > Lionel > > > > > > > -----Message d'origine----- > > > De : Julien Laganier [mailto:julien.IETF@laposte.net] > > > Envoy$B!)(J : mardi 23 janvier 2007 10:42 > > > $B!)(J : Ahmad Muhanna > > > Cc : dime@ietf.org > > > Objet : Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: > > > Issue or notIssue ? > > > > > > Hi Ahmad, > > > > > > Cutting a bit thru your message, I have some comments > > > below: > > > > > > On Monday 22 January 2007 18:10, Ahmad Muhanna wrote: > > > > > > > > > > > >[...] > > > > > > > > [Ahmad] > > > > We are probably splitting hair here, apparently there are two > > > > arguments here: > > > > > > I don't think this is hair splitting. Understand the > issue should be > > > a prerequisite to solving it. > > > > > > > 1. AAAz is an authorization server and since it has a security > > > > relationship with the HA, AAAz relies on the HA to do two > > > things: 1.1. > > > > HA makes sure that the user has been authenticated by > AAAn. 1.2. > > > > HA will not send any Authorization requests for any user(s) > > > who has not > > > > been authenticated. > > > > > > > > (In normal conditions, the above two conditions are ALWAYS > > > TRUE except > > > > in one condition, HA has been > > > > compromised) > > > > > > Right. So we both agree there's no problem unless the HA is > > > compromised > > > > > > I think what the first step is to agree on a threat > model. I do not > > > agree that we should defend against a compromised HA. > > > The HA should be deemed secure against attackers. > > > > > > We have to place a limit on what is entity X when asking the > > > question "what if entity X is compromised". > > > Since nothing is really impossible in the real world, we cannot > > > defend against compromission of any entity implicated in > a protocol. > > > Security is a tradeoff. > > > > > > More below... > > > > > > > 2. AAAz is an authorization server and has a security > > > association with > > > > the HA, however, due to the fact that the HA could be > > > compromised, a > > > > process needs to be in place for the HA to ALWAYS provide the > > > > AAAz, Authorization server, with a proof (token, > > > > etc.) that the user has been authenticated by AAAn. > > > > > > OK, if HA can be compromised. But why are we stopping here? > > > Why not considering the case where the AAAn is compromised? > > > Is is it more likely for an HA to be compromised than for a AAAn? > > > > > > We really have to agree on a threat model first. > > > > > > > I assume here that the difference in opinion is about the > > > possibility > > > > of the HA to be compromised or NOT. > > > > > > Exactly. > > > > > > Best, > > > > > > --julien (L.) > > > > > > _______________________________________________ > > > 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 Jan 25 09:42:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA5ng-00022a-Mw; Thu, 25 Jan 2007 09:42:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA5nf-00022N-JJ for dime@ietf.org; Thu, 25 Jan 2007 09:42:03 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA5nf-0004Ta-2n for dime@ietf.org; Thu, 25 Jan 2007 09:42:03 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l0PEfq000147; Thu, 25 Jan 2007 09:41:52 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Issue or notIssue ? Date: Thu, 25 Jan 2007 08:41:35 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437112682B24@zrc2hxm2.corp.nortel.com> In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB026043F74D2@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Issue or notIssue ? Thread-index: AcdAA/r5nUIvzJ8ATjeXOadoEt8alwAWd2gAAAvsElA= From: "Ahmad Muhanna" To: "MORAND Lionel RD-CORE-ISS" , "Yoshihiro Ohba" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e Cc: dime@ietf.org, Julien Laganier 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, Please see some one comment inline. Regards, Ahmad > -----Original Message----- > From: MORAND Lionel RD-CORE-ISS > [mailto:lionel.morand@orange-ftgroup.com] > Sent: Thursday, January 25, 2007 5:11 AM > To: Yoshihiro Ohba > Cc: Julien Laganier; Muhanna, Ahmad (RICH1:2H10); dime@ietf.org > Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: > Issue or notIssue ? > > Hi Yoshi, > > 1) If authentication procedures may be performed apart from > authorization procedures (I totally agree), authorization > procedures must be able to rely on its own authentication > procedures if needed (cf. AAA requirements in RFC 2906). Are > you OK with that? [Ahmad] Just for my education, could you please give me a pointer to which requirement you are referring in RFC2906. Thanks. > > 2) As it is now, providing authentication with Diameter EAP > application and authorization with Diameter MIP6 does not > allow the AAA-MIP6 to be sure that the username carried in > the authorization request was previously authenticated by the > AAA-EAP. Are you OK with that? > > 3) If the AAA-MIP6 provides the HA with service related > information without being sure that the key entry (username) > was previously authenticated, what is the difference between > the AAA-MIP6 and a "simple" external database providing > information data to any authorized entity (HA in the present > case)? What/where is the authorization process in that case? > > 4) If combining Diameter EAP and Diameter MIP6 is more > complex than including authentication procedures with > Diameter MIP6 that is coherent with AAA requirements, why are > we still discussing as much? ;) > > 5) If the discussion is beyond the scope of the draft and > related to the future of global AAA framework, why do not > "decouple" the discussions and create a separate thread? But > for now, I can see that a Diameter MIP6 application with > authentication procedure would be consistent with the current > AAA framework while a combinaison of Diameter EAP and > Diameter MIP6 will not meet all the AAA requirements without > introducing specific functionalites/enhancements. > > I would have no problem with a solution proposing EAP > authentication procedures and MIP6 authorization procedures > supported by to different diameter applications IF it could > be possible to bind both procedures in the same equipment in > the MSA. That is not the case with the current solution. > > BR, > > Lionel > > > > There is a new guy in the game ;) > > > > > > After reviewing the draft and the mail exchange on the > > topic, I would say that the conclusion on "issue/no issue" > > depends on the side you are considering the problem (as often ;). > > > > > > If you are considering the AAA-MIP6 as a "simple" database > > providing the HA with specific user/service information after a > > separate authentication (performed with Diameter > authentication), the > > username conveyed over the HA/AAA-MIP6 is just used as a > key entry in > > the database. There is no need for the AAA-MIP6 to > authenticate this > > username or to be sure that the username was previously > authenticated. > > The client of the database is the HA and not the user. In > that case, > > the > > AAA-MIP6 has to trust the HA and it is up to the HA to authenticate > > the username provided by the mn during the SA set-up. This could be > > compared to interfaces between HSS (Home Subscriber Server) and SIP > > application servers defined in the 3GPP architecture, over which > > Diameter applications are used to access database. > > > > > > In this context, the HA may use: > > > 1) the Diameter EAP application to authenticate the user. > > > 2) the Diameter MIP6 application to download user related service > > > information Authentication and authorization are performed > > by the AAA-EAP. But there is no way for the AAA-EAP to know what is > > the service requested by the user. Successful > authentication implies > > implicte authorization. This is the problem with Diameter > EAP as it is > > not possible to route Diameter EAP request to a > service-specific EAP > > server. > > > > If AAA-MIP6 provides authorizatin, AAA-EAP provides authentication, > > but does not provide authorization. For this purpose, the > HA needs to > > set Auth-Request-Type set to AUTHENTICATE_ONLY in AAA-EAP. In this > > case, AAA-EAP server does not need to know what kind of > authorization > > will be made. The authorization decision will be made by AAA-MIP6. > > Am I missing something? > > > > > > > > In another hand, if the AAA-MIP6 is an authority handling > > MIP6 service access authorization rights i.e. the AAA-MIP6 > must verify > > that the user is authorized to use the Mobile > > IPv6 service, this authority has to be able to verify the > identity of > > the user before authorizing this user to access the > service. It is not > > possible to authorize someone to do something without being sure of > > its identity as the authority must stand surety of the user access > > rights. Now, it is not possible to rely on the Diameter EAP > > application to perform the authentication procedure as > there is no way > > to direct the Diameter EAP requests to a specifc EAP server (as the > > Diameter routing is based on App-Id and Realm). We might > think about > > some specific things to link authentication procedures and > > authorization/service profile handling. But for me, the > simpliest way > > would be to define the required authentication mechanism within one > > and only one application i.e. the application that requires this > > authentication. > > Therefore, Diameter EAP would not be used and application-specific > > commands would be specified in the application. One command > pair would > > be added to the Diameter > > MIP6 application. And to support EAP, AVPs defined in 4072 > would be at > > least (re-)used. > > > > I don't understand the difference between the two cases you > mentioned > > above. I believe that more or less the AAA servers need to > trust the > > HA in both cases. Depending on threat model which we don't seem to > > exactly know right now, the > > AAA-MIP6 server may or may not need an evidence that the > user has been > > authenticated by a AAA-EAP server. > > > > > > > > IMHO, the context described in the draft looks like more a > > service access authorization management than the use of a simple > > external database. I would be therefore in favor of defining > > authentication commands within the Diameter MIP6 > application instead > > of trying to reuse the Diameter EAP application, which is > not possible > > without modifications. EAP authentication and MIP6 service access > > authorization are performed with the same application. Since a > > application-Id is whatever needed for the HA/AAA-MIP6, what > would be > > the benefit to look for solutions binding Diameter EAP and Diameter > > MIP6 (with some key derivation, etc.) while a single Diameter MIP6 > > application with intrinsic authentication commands would be fully > > appropriate? > > > > I don't understand what is the point of discussing "service access > > authorization management" and "simple external database". If MIP6 > > application needs to support multiple authentication > methods such as > > EAP and RFC 4285, I believe it is more appropriate to consider > > separation of authentication and authorization if security is > > reasonably handled. Also, there is some authentication > method (e.g., > > authentication based on IKEv2-cert without using EAP) does > not require > > any AAA interacation for authentication. I was pointing this out > > several times but no one seems to pay attention to it. > > > > > > > > I'm pretty sure that the content of this mail may be > > challenged line by line ;) But at the end, if authentication and > > authorization are needed to provide MIP6 services, why do > not having a > > single application to do it? Of course, I don't say that it > would not > > be possible to do something more complex... > > > > To me, discussion on coupling vs. decoupling authentication and > > authorization is not just a MIP6 issue. This is a fundamental > > discussion that will decide the future direction of AAA. > > > > Yoshihiro Ohba > > > > > > > > BR, > > > > > > Lionel > > > > > > > > > > -----Message d'origine----- > > > > De : Julien Laganier [mailto:julien.IETF@laposte.net] > > > > Envoy$B!)(J : mardi 23 janvier 2007 10:42 > > > > $B!)(J : Ahmad Muhanna > > > > Cc : dime@ietf.org > > > > Objet : Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: > > > > Issue or notIssue ? > > > > > > > > Hi Ahmad, > > > > > > > > Cutting a bit thru your message, I have some comments > > > > below: > > > > > > > > On Monday 22 January 2007 18:10, Ahmad Muhanna wrote: > > > > > > > > > > > > > > >[...] > > > > > > > > > > [Ahmad] > > > > > We are probably splitting hair here, apparently there are two > > > > > arguments here: > > > > > > > > I don't think this is hair splitting. Understand the > > issue should be > > > > a prerequisite to solving it. > > > > > > > > > 1. AAAz is an authorization server and since it has a > security > > > > > relationship with the HA, AAAz relies on the HA to do two > > > > things: 1.1. > > > > > HA makes sure that the user has been authenticated by > > AAAn. 1.2. > > > > > HA will not send any Authorization requests for any user(s) > > > > who has not > > > > > been authenticated. > > > > > > > > > > (In normal conditions, the above two conditions are ALWAYS > > > > TRUE except > > > > > in one condition, HA has been > > > > > compromised) > > > > > > > > Right. So we both agree there's no problem unless the HA is > > > > compromised > > > > > > > > I think what the first step is to agree on a threat > > model. I do not > > > > agree that we should defend against a compromised HA. > > > > The HA should be deemed secure against attackers. > > > > > > > > We have to place a limit on what is entity X when asking the > > > > question "what if entity X is compromised". > > > > Since nothing is really impossible in the real world, we cannot > > > > defend against compromission of any entity implicated in > > a protocol. > > > > Security is a tradeoff. > > > > > > > > More below... > > > > > > > > > 2. AAAz is an authorization server and has a security > > > > association with > > > > > the HA, however, due to the fact that the HA could be > > > > compromised, a > > > > > process needs to be in place for the HA to ALWAYS provide the > > > > > AAAz, Authorization server, with a proof (token, > > > > > etc.) that the user has been authenticated by AAAn. > > > > > > > > OK, if HA can be compromised. But why are we stopping here? > > > > Why not considering the case where the AAAn is compromised? > > > > Is is it more likely for an HA to be compromised than > for a AAAn? > > > > > > > > We really have to agree on a threat model first. > > > > > > > > > I assume here that the difference in opinion is about the > > > > possibility > > > > > of the HA to be compromised or NOT. > > > > > > > > Exactly. > > > > > > > > Best, > > > > > > > > --julien (L.) > > > > > > > > _______________________________________________ > > > > 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 Jan 25 10:17:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA6LT-0006Mj-BW; Thu, 25 Jan 2007 10:16:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA6LS-0006Kp-CR for dime@ietf.org; Thu, 25 Jan 2007 10:16:58 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15] helo=p-mail1.rd.orange-ftgroup.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA6LQ-0003mf-HB for dime@ietf.org; Thu, 25 Jan 2007 10:16:58 -0500 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 16:16:08 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Issue or notIssue ? Date: Thu, 25 Jan 2007 16:16:00 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026043F76A1@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Issue or notIssue ? thread-index: AcdAA/r5nUIvzJ8ATjeXOadoEt8alwAWd2gAAAvsElAAASCtUA== From: "MORAND Lionel RD-CORE-ISS" To: "Ahmad Muhanna" , "Yoshihiro Ohba" X-OriginalArrivalTime: 25 Jan 2007 15:16:08.0427 (UTC) FILETIME=[BD5653B0:01C74093] X-Spam-Score: 0.1 (/) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 Cc: dime@ietf.org, Julien Laganier 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="===============0225096963==" Errors-To: dime-bounces@ietf.org --===============0225096963== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWhtYWQsDQoNCkp1c3QgYSBjb3VwbGUgb2YgcmVxdWlyZW1lbnRzOg0KDQoyLjcuMyANCiAg IFdpdGhpbiBhIHNpbmdsZSBzZXNzaW9uIG9yIHRyYW5zYWN0aW9uLCBpdCBNVVNUIGJlIHBvc3Np YmxlIHRvDQogICBpbnRlcmxlYXZlIGF1dGhlbnRpY2F0aW9uLCBhdXRob3JpemF0aW9uIGFuZCBh Y2NvdW50aW5nIEFBQSBtZXNzYWdlcy4NCg0KICAgVGhpcyBzdGF0ZXMsIHRoYXQgZS5nLiBhIHNl c3Npb24gbWF5IGhhdmUgdG8gdXNlIGluaXRpYWwNCiAgIGF1dGhlbnRpY2F0aW9uLCBhdXRob3Jp emF0aW9uIGFuZCBhY2NvdW50aW5nIEFBQSBtZXNzYWdlKHMpLCBidXQgYWxzbw0KICAgaGF2ZSB0 byBpbmNsdWRlIGUuZy4gcmUtYXV0aGVudGljYXRpb24gZXZlcnkgMzAgbWludXRlcywgb3IgYQ0K ICAgY29udGludW91cyAiZHJpcC1kcmlwIiBvZiBhY2NvdW50aW5nIEFBQSBtZXNzYWdlcy4NCg0K Mi45LjENCiAgIEF1dGhvcml6YXRpb24gc2VwYXJhdGUgZnJvbSBhdXRoZW50aWNhdGlvbiBTSE9V TEQgYmUgYWxsb3dlZA0KICAgd2hlbiBuZWNlc3NhcnksIGJ1dCB0aGUgQUFBIHByb3RvY29scyBN VVNUIGFsc28gYWxsb3cgZm9yIGEgc2luZ2xlDQogICBtZXNzYWdlIHRvIHJlcXVlc3QgYm90aCBh dXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbi4NCg0KICAgQUFBIHByb3RvY29scyBoYXZl IHRvIGFsbG93IGEgc3BsaXQgYmV0d2VlbiBhdXRoZW50aWNhdGlvbiBhbmQNCiAgIGF1dGhvcml6 YXRpb24gc28gdGhhdCBkaWZmZXJlbnQgbWVjaGFuaXNtcyBhcmUgdXNlZCBmb3IgZWFjaC4gVGhp cw0KICAgc3RhdGVzIHRoYXQgc29tZXRpbWVzIGJvdGggdHlwZXMgb2YgaW5mb3JtYXRpb24gbmVl ZCB0byBiZSBjYXJyaWVkIGluDQogICB0aGUgc2FtZSBtZXNzYWdlLg0KDQpCdXQgeW91IGNhbiBm aW5kIHNldmVyYWwgb3RoZXIgcGxhY2VzIGluIHRoZSBkb2N1bWVudCB3aGVyZSAgYXV0aGVudGlj YXRpb24gJiBhdXRob3JpemF0aW9uIGFyZSBib3VuZC4NCg0KQlIsDQoNCkxpb25lbA0KDQo+IC0t LS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZSA6IEFobWFkIE11aGFubmEgW21haWx0bzph bXVoYW5uYUBub3J0ZWwuY29tXSANCj4gRW52b3nDqSA6IGpldWRpIDI1IGphbnZpZXIgMjAwNyAx NTo0Mg0KPiDDgCA6IE1PUkFORCBMaW9uZWwgUkQtQ09SRS1JU1M7IFlvc2hpaGlybyBPaGJhDQo+ IENjIDogSnVsaWVuIExhZ2FuaWVyOyBkaW1lQGlldGYub3JnDQo+IE9iamV0IDogUkU6IFtEaW1l XSBEaWFtZXRlciBNb2JpbGUgSVB2NiBIQS10by1BQUFIIFN1cHBvcnQ6IA0KPiBJc3N1ZSBvciBu b3RJc3N1ZSA/DQo+IA0KPiBIaSBMaW9uZWwsDQo+IFBsZWFzZSBzZWUgc29tZSBvbmUgY29tbWVu dCBpbmxpbmUuDQo+IA0KPiBSZWdhcmRzLA0KPiBBaG1hZA0KPiAgDQo+IA0KPiA+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogTU9SQU5EIExpb25lbCBSRC1DT1JFLUlTUw0K PiA+IFttYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UtZnRncm91cC5jb21dDQo+ID4gU2VudDog VGh1cnNkYXksIEphbnVhcnkgMjUsIDIwMDcgNToxMSBBTQ0KPiA+IFRvOiBZb3NoaWhpcm8gT2hi YQ0KPiA+IENjOiBKdWxpZW4gTGFnYW5pZXI7IE11aGFubmEsIEFobWFkIChSSUNIMToySDEwKTsg ZGltZUBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJFOiBbRGltZV0gRGlhbWV0ZXIgTW9iaWxlIElQ djYgSEEtdG8tQUFBSCBTdXBwb3J0OiANCj4gPiBJc3N1ZSBvciBub3RJc3N1ZSA/DQo+ID4gDQo+ ID4gSGkgWW9zaGksDQo+ID4gDQo+ID4gMSkgSWYgYXV0aGVudGljYXRpb24gcHJvY2VkdXJlcyBt YXkgYmUgcGVyZm9ybWVkIGFwYXJ0IGZyb20gDQo+ID4gYXV0aG9yaXphdGlvbiBwcm9jZWR1cmVz IChJIHRvdGFsbHkgYWdyZWUpLCBhdXRob3JpemF0aW9uIA0KPiBwcm9jZWR1cmVzIA0KPiA+IG11 c3QgYmUgYWJsZSB0byByZWx5IG9uIGl0cyBvd24gYXV0aGVudGljYXRpb24gcHJvY2VkdXJlcyBp ZiBuZWVkZWQgDQo+ID4gKGNmLiBBQUEgcmVxdWlyZW1lbnRzIGluIFJGQyAyOTA2KS4gQXJlIHlv dSBPSyB3aXRoIHRoYXQ/DQo+IA0KPiBbQWhtYWRdDQo+IEp1c3QgZm9yIG15IGVkdWNhdGlvbiwg Y291bGQgeW91IHBsZWFzZSBnaXZlIG1lIGEgcG9pbnRlciB0byANCj4gd2hpY2ggcmVxdWlyZW1l bnQgeW91IGFyZSByZWZlcnJpbmcgaW4gUkZDMjkwNi4NCj4gVGhhbmtzLg0KPiANCj4gPiANCj4g PiAyKSBBcyBpdCBpcyBub3csIHByb3ZpZGluZyBhdXRoZW50aWNhdGlvbiB3aXRoIERpYW1ldGVy IEVBUCANCj4gPiBhcHBsaWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiB3aXRoIERpYW1ldGVyIE1J UDYgZG9lcyBub3QgYWxsb3cgdGhlIA0KPiA+IEFBQS1NSVA2IHRvIGJlIHN1cmUgdGhhdCB0aGUg dXNlcm5hbWUgY2FycmllZCBpbiB0aGUgYXV0aG9yaXphdGlvbiANCj4gPiByZXF1ZXN0IHdhcyBw cmV2aW91c2x5IGF1dGhlbnRpY2F0ZWQgYnkgdGhlIEFBQS1FQVAuIEFyZSANCj4geW91IE9LIHdp dGggDQo+ID4gdGhhdD8NCj4gPiANCj4gPiAzKSBJZiB0aGUgQUFBLU1JUDYgcHJvdmlkZXMgdGhl IEhBIHdpdGggc2VydmljZSByZWxhdGVkIGluZm9ybWF0aW9uIA0KPiA+IHdpdGhvdXQgYmVpbmcg c3VyZSB0aGF0IHRoZSBrZXkgZW50cnkgKHVzZXJuYW1lKSB3YXMgcHJldmlvdXNseSANCj4gPiBh dXRoZW50aWNhdGVkLCB3aGF0IGlzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIEFBQS1NSVA2 IGFuZCBhIA0KPiA+ICJzaW1wbGUiIGV4dGVybmFsIGRhdGFiYXNlIHByb3ZpZGluZyBpbmZvcm1h dGlvbiBkYXRhIHRvIGFueSANCj4gPiBhdXRob3JpemVkIGVudGl0eSAoSEEgaW4gdGhlIHByZXNl bnQgY2FzZSk/IFdoYXQvd2hlcmUgaXMgdGhlIA0KPiA+IGF1dGhvcml6YXRpb24gcHJvY2VzcyBp biB0aGF0IGNhc2U/DQo+ID4gDQo+ID4gNCkgSWYgY29tYmluaW5nIERpYW1ldGVyIEVBUCBhbmQg RGlhbWV0ZXIgTUlQNiBpcyBtb3JlIGNvbXBsZXggdGhhbiANCj4gPiBpbmNsdWRpbmcgYXV0aGVu dGljYXRpb24gcHJvY2VkdXJlcyB3aXRoIERpYW1ldGVyIE1JUDYgdGhhdCBpcyANCj4gPiBjb2hl cmVudCB3aXRoIEFBQSByZXF1aXJlbWVudHMsIHdoeSBhcmUgd2Ugc3RpbGwgZGlzY3Vzc2luZyAN Cj4gYXMgbXVjaD8gDQo+ID4gOykNCj4gPiANCj4gPiA1KSBJZiB0aGUgZGlzY3Vzc2lvbiBpcyBi ZXlvbmQgdGhlIHNjb3BlIG9mIHRoZSBkcmFmdCBhbmQgDQo+IHJlbGF0ZWQgdG8gDQo+ID4gdGhl IGZ1dHVyZSBvZiBnbG9iYWwgQUFBIGZyYW1ld29yaywgd2h5IGRvIG5vdCAiZGVjb3VwbGUiIHRo ZSANCj4gPiBkaXNjdXNzaW9ucyBhbmQgY3JlYXRlIGEgc2VwYXJhdGUgdGhyZWFkPyBCdXQgZm9y IG5vdywgSSANCj4gY2FuIHNlZSB0aGF0IA0KPiA+IGEgRGlhbWV0ZXIgTUlQNiBhcHBsaWNhdGlv biB3aXRoIGF1dGhlbnRpY2F0aW9uIHByb2NlZHVyZSB3b3VsZCBiZSANCj4gPiBjb25zaXN0ZW50 IHdpdGggdGhlIGN1cnJlbnQgQUFBIGZyYW1ld29yayB3aGlsZSBhIGNvbWJpbmFpc29uIG9mIA0K PiA+IERpYW1ldGVyIEVBUCBhbmQgRGlhbWV0ZXIgTUlQNiB3aWxsIG5vdCBtZWV0IGFsbCB0aGUg QUFBIA0KPiByZXF1aXJlbWVudHMgDQo+ID4gd2l0aG91dCBpbnRyb2R1Y2luZyBzcGVjaWZpYyBm dW5jdGlvbmFsaXRlcy9lbmhhbmNlbWVudHMuDQo+ID4gDQo+ID4gSSB3b3VsZCBoYXZlIG5vIHBy b2JsZW0gd2l0aCBhIHNvbHV0aW9uIHByb3Bvc2luZyBFQVAgDQo+IGF1dGhlbnRpY2F0aW9uIA0K PiA+IHByb2NlZHVyZXMgYW5kIE1JUDYgYXV0aG9yaXphdGlvbiBwcm9jZWR1cmVzIHN1cHBvcnRl ZCBieSANCj4gdG8gZGlmZmVyZW50IA0KPiA+IGRpYW1ldGVyIGFwcGxpY2F0aW9ucyBJRiBpdCBj b3VsZCBiZSBwb3NzaWJsZSB0byBiaW5kIGJvdGggDQo+IHByb2NlZHVyZXMgDQo+ID4gaW4gdGhl IHNhbWUgZXF1aXBtZW50IGluIHRoZSBNU0EuIFRoYXQgaXMgbm90IHRoZSBjYXNlIHdpdGggdGhl IA0KPiA+IGN1cnJlbnQgc29sdXRpb24uDQo+ID4gDQo+ID4gQlIsDQo+ID4gDQo+ID4gTGlvbmVs DQo+ID4gDQo+ID4gPiA+IFRoZXJlIGlzIGEgbmV3IGd1eSBpbiB0aGUgZ2FtZSA7KQ0KPiA+ID4g PiANCj4gPiA+ID4gQWZ0ZXIgcmV2aWV3aW5nIHRoZSBkcmFmdCBhbmQgdGhlIG1haWwgZXhjaGFu Z2Ugb24gdGhlDQo+ID4gPiB0b3BpYywgSSB3b3VsZCBzYXkgdGhhdCB0aGUgY29uY2x1c2lvbiBv biAiaXNzdWUvbm8gaXNzdWUiIA0KPiA+ID4gZGVwZW5kcyBvbiB0aGUgc2lkZSB5b3UgYXJlIGNv bnNpZGVyaW5nIHRoZSBwcm9ibGVtIChhcyBvZnRlbiA7KS4NCj4gPiA+ID4gDQo+ID4gPiA+IElm IHlvdSBhcmUgY29uc2lkZXJpbmcgdGhlIEFBQS1NSVA2IGFzIGEgInNpbXBsZSIgZGF0YWJhc2UN Cj4gPiA+IHByb3ZpZGluZyB0aGUgSEEgd2l0aCBzcGVjaWZpYyB1c2VyL3NlcnZpY2UgaW5mb3Jt YXRpb24gYWZ0ZXIgYSANCj4gPiA+IHNlcGFyYXRlIGF1dGhlbnRpY2F0aW9uIChwZXJmb3JtZWQg d2l0aCBEaWFtZXRlcg0KPiA+IGF1dGhlbnRpY2F0aW9uKSwgdGhlDQo+ID4gPiB1c2VybmFtZSBj b252ZXllZCBvdmVyIHRoZSBIQS9BQUEtTUlQNiBpcyBqdXN0IHVzZWQgYXMgYQ0KPiA+IGtleSBl bnRyeSBpbg0KPiA+ID4gdGhlIGRhdGFiYXNlLiBUaGVyZSBpcyBubyBuZWVkIGZvciB0aGUgQUFB LU1JUDYgdG8NCj4gPiBhdXRoZW50aWNhdGUgdGhpcw0KPiA+ID4gdXNlcm5hbWUgb3IgdG8gYmUg c3VyZSB0aGF0IHRoZSB1c2VybmFtZSB3YXMgcHJldmlvdXNseQ0KPiA+IGF1dGhlbnRpY2F0ZWQu IA0KPiA+ID4gVGhlIGNsaWVudCBvZiB0aGUgZGF0YWJhc2UgaXMgdGhlIEhBIGFuZCBub3QgdGhl IHVzZXIuIEluDQo+ID4gdGhhdCBjYXNlLA0KPiA+ID4gdGhlDQo+ID4gPiBBQUEtTUlQNiBoYXMg dG8gdHJ1c3QgdGhlIEhBIGFuZCBpdCBpcyB1cCB0byB0aGUgSEEgdG8gDQo+IGF1dGhlbnRpY2F0 ZSANCj4gPiA+IHRoZSB1c2VybmFtZSBwcm92aWRlZCBieSB0aGUgbW4gZHVyaW5nIHRoZSBTQSBz ZXQtdXAuIA0KPiBUaGlzIGNvdWxkIGJlIA0KPiA+ID4gY29tcGFyZWQgdG8gaW50ZXJmYWNlcyBi ZXR3ZWVuIEhTUyAoSG9tZSBTdWJzY3JpYmVyIA0KPiBTZXJ2ZXIpIGFuZCBTSVAgDQo+ID4gPiBh cHBsaWNhdGlvbiBzZXJ2ZXJzIGRlZmluZWQgaW4gdGhlIDNHUFAgYXJjaGl0ZWN0dXJlLCBvdmVy IHdoaWNoIA0KPiA+ID4gRGlhbWV0ZXIgYXBwbGljYXRpb25zIGFyZSB1c2VkIHRvIGFjY2VzcyBk YXRhYmFzZS4NCj4gPiA+ID4gDQo+ID4gPiA+IEluIHRoaXMgY29udGV4dCwgdGhlIEhBIG1heSB1 c2U6DQo+ID4gPiA+IDEpIHRoZSBEaWFtZXRlciBFQVAgYXBwbGljYXRpb24gdG8gYXV0aGVudGlj YXRlIHRoZSB1c2VyLiAgDQo+ID4gPiA+IDIpIHRoZSBEaWFtZXRlciBNSVA2IGFwcGxpY2F0aW9u IHRvIGRvd25sb2FkIHVzZXIgDQo+IHJlbGF0ZWQgc2VydmljZSANCj4gPiA+ID4gaW5mb3JtYXRp b24gQXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gYXJlIHBlcmZvcm1lZA0KPiA+ID4g YnkgdGhlIEFBQS1FQVAuIEJ1dCB0aGVyZSBpcyBubyB3YXkgZm9yIHRoZSBBQUEtRUFQIHRvIA0K PiBrbm93IHdoYXQgaXMgDQo+ID4gPiB0aGUgc2VydmljZSByZXF1ZXN0ZWQgYnkgdGhlIHVzZXIu IFN1Y2Nlc3NmdWwNCj4gPiBhdXRoZW50aWNhdGlvbiBpbXBsaWVzDQo+ID4gPiBpbXBsaWN0ZSBh dXRob3JpemF0aW9uLiBUaGlzIGlzIHRoZSBwcm9ibGVtIHdpdGggRGlhbWV0ZXINCj4gPiBFQVAg YXMgaXQgaXMNCj4gPiA+IG5vdCBwb3NzaWJsZSB0byByb3V0ZSBEaWFtZXRlciBFQVAgcmVxdWVz dCB0byBhDQo+ID4gc2VydmljZS1zcGVjaWZpYyBFQVANCj4gPiA+IHNlcnZlci4NCj4gPiA+IA0K PiA+ID4gSWYgQUFBLU1JUDYgcHJvdmlkZXMgYXV0aG9yaXphdGluLCBBQUEtRUFQIHByb3ZpZGVz IA0KPiBhdXRoZW50aWNhdGlvbiwgDQo+ID4gPiBidXQgZG9lcyBub3QgcHJvdmlkZSBhdXRob3Jp emF0aW9uLiAgRm9yIHRoaXMgcHVycG9zZSwgdGhlDQo+ID4gSEEgbmVlZHMgdG8NCj4gPiA+IHNl dCBBdXRoLVJlcXVlc3QtVHlwZSBzZXQgdG8gQVVUSEVOVElDQVRFX09OTFkgaW4gDQo+IEFBQS1F QVAuICBJbiB0aGlzIA0KPiA+ID4gY2FzZSwgQUFBLUVBUCBzZXJ2ZXIgZG9lcyBub3QgbmVlZCB0 byBrbm93IHdoYXQga2luZCBvZg0KPiA+IGF1dGhvcml6YXRpb24NCj4gPiA+IHdpbGwgYmUgbWFk ZS4gIFRoZSBhdXRob3JpemF0aW9uIGRlY2lzaW9uIHdpbGwgYmUgbWFkZSBieSANCj4gQUFBLU1J UDYuDQo+ID4gPiBBbSBJIG1pc3Npbmcgc29tZXRoaW5nPw0KPiA+ID4gDQo+ID4gPiA+IA0KPiA+ ID4gPiBJbiBhbm90aGVyIGhhbmQsIGlmIHRoZSBBQUEtTUlQNiBpcyBhbiBhdXRob3JpdHkgaGFu ZGxpbmcNCj4gPiA+IE1JUDYgc2VydmljZSBhY2Nlc3MgYXV0aG9yaXphdGlvbiByaWdodHMgaS5l LiB0aGUgQUFBLU1JUDYNCj4gPiBtdXN0IHZlcmlmeQ0KPiA+ID4gdGhhdCB0aGUgdXNlciBpcyBh dXRob3JpemVkIHRvIHVzZSB0aGUgTW9iaWxlDQo+ID4gPiBJUHY2IHNlcnZpY2UsIHRoaXMgYXV0 aG9yaXR5IGhhcyB0byBiZSBhYmxlIHRvIHZlcmlmeSB0aGUNCj4gPiBpZGVudGl0eSBvZg0KPiA+ ID4gdGhlIHVzZXIgYmVmb3JlIGF1dGhvcml6aW5nIHRoaXMgdXNlciB0byBhY2Nlc3MgdGhlDQo+ ID4gc2VydmljZS4gSXQgaXMgbm90DQo+ID4gPiBwb3NzaWJsZSB0byBhdXRob3JpemUgc29tZW9u ZSB0byBkbyBzb21ldGhpbmcgd2l0aG91dCANCj4gYmVpbmcgc3VyZSBvZiANCj4gPiA+IGl0cyBp ZGVudGl0eSBhcyB0aGUgYXV0aG9yaXR5IG11c3Qgc3RhbmQgc3VyZXR5IG9mIHRoZSANCj4gdXNl ciBhY2Nlc3MgDQo+ID4gPiByaWdodHMuIE5vdywgaXQgaXMgbm90IHBvc3NpYmxlIHRvIHJlbHkg b24gdGhlIERpYW1ldGVyIEVBUCANCj4gPiA+IGFwcGxpY2F0aW9uIHRvIHBlcmZvcm0gdGhlIGF1 dGhlbnRpY2F0aW9uIHByb2NlZHVyZSBhcw0KPiA+IHRoZXJlIGlzIG5vIHdheQ0KPiA+ID4gdG8g ZGlyZWN0IHRoZSBEaWFtZXRlciBFQVAgcmVxdWVzdHMgdG8gYSBzcGVjaWZjIEVBUCANCj4gc2Vy dmVyIChhcyB0aGUgDQo+ID4gPiBEaWFtZXRlciByb3V0aW5nIGlzIGJhc2VkIG9uIEFwcC1JZCBh bmQgUmVhbG0pLiBXZSBtaWdodA0KPiA+IHRoaW5rIGFib3V0DQo+ID4gPiBzb21lIHNwZWNpZmlj IHRoaW5ncyB0byBsaW5rIGF1dGhlbnRpY2F0aW9uIHByb2NlZHVyZXMgYW5kIA0KPiA+ID4gYXV0 aG9yaXphdGlvbi9zZXJ2aWNlIHByb2ZpbGUgaGFuZGxpbmcuIEJ1dCBmb3IgbWUsIHRoZQ0KPiA+ IHNpbXBsaWVzdCB3YXkNCj4gPiA+IHdvdWxkIGJlIHRvIGRlZmluZSB0aGUgcmVxdWlyZWQgYXV0 aGVudGljYXRpb24gbWVjaGFuaXNtIA0KPiB3aXRoaW4gb25lIA0KPiA+ID4gYW5kIG9ubHkgb25l IGFwcGxpY2F0aW9uIGkuZS4gdGhlIGFwcGxpY2F0aW9uIHRoYXQgcmVxdWlyZXMgdGhpcyANCj4g PiA+IGF1dGhlbnRpY2F0aW9uLg0KPiA+ID4gVGhlcmVmb3JlLCBEaWFtZXRlciBFQVAgd291bGQg bm90IGJlIHVzZWQgYW5kIA0KPiBhcHBsaWNhdGlvbi1zcGVjaWZpYyANCj4gPiA+IGNvbW1hbmRz IHdvdWxkIGJlIHNwZWNpZmllZCBpbiB0aGUgYXBwbGljYXRpb24uIE9uZSBjb21tYW5kDQo+ID4g cGFpciB3b3VsZA0KPiA+ID4gYmUgYWRkZWQgdG8gdGhlIERpYW1ldGVyDQo+ID4gPiBNSVA2IGFw cGxpY2F0aW9uLiBBbmQgdG8gc3VwcG9ydCBFQVAsIEFWUHMgZGVmaW5lZCBpbiA0MDcyDQo+ID4g d291bGQgYmUgYXQNCj4gPiA+IGxlYXN0IChyZS0pdXNlZC4NCj4gPiA+IA0KPiA+ID4gSSBkb24n dCB1bmRlcnN0YW5kIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIHR3byBjYXNlcyB5b3UNCj4g PiBtZW50aW9uZWQNCj4gPiA+IGFib3ZlLiAgSSBiZWxpZXZlIHRoYXQgbW9yZSBvciBsZXNzIHRo ZSBBQUEgc2VydmVycyBuZWVkIHRvDQo+ID4gdHJ1c3QgdGhlDQo+ID4gPiBIQSBpbiBib3RoIGNh c2VzLiAgRGVwZW5kaW5nIG9uIHRocmVhdCBtb2RlbCB3aGljaCB3ZSANCj4gZG9uJ3Qgc2VlbSB0 byANCj4gPiA+IGV4YWN0bHkga25vdyByaWdodCBub3csIHRoZQ0KPiA+ID4gQUFBLU1JUDYgc2Vy dmVyIG1heSBvciBtYXkgbm90IG5lZWQgYW4gZXZpZGVuY2UgdGhhdCB0aGUNCj4gPiB1c2VyIGhh cyBiZWVuDQo+ID4gPiBhdXRoZW50aWNhdGVkIGJ5IGEgQUFBLUVBUCBzZXJ2ZXIuDQo+ID4gPiAN Cj4gPiA+ID4gDQo+ID4gPiA+IElNSE8sIHRoZSBjb250ZXh0IGRlc2NyaWJlZCBpbiB0aGUgZHJh ZnQgbG9va3MgbGlrZSBtb3JlIGENCj4gPiA+IHNlcnZpY2UgYWNjZXNzIGF1dGhvcml6YXRpb24g bWFuYWdlbWVudCB0aGFuIHRoZSB1c2Ugb2YgYSBzaW1wbGUgDQo+ID4gPiBleHRlcm5hbCBkYXRh YmFzZS4gSSB3b3VsZCBiZSB0aGVyZWZvcmUgaW4gZmF2b3Igb2YgZGVmaW5pbmcgDQo+ID4gPiBh dXRoZW50aWNhdGlvbiBjb21tYW5kcyB3aXRoaW4gdGhlIERpYW1ldGVyIE1JUDYNCj4gPiBhcHBs aWNhdGlvbiBpbnN0ZWFkDQo+ID4gPiBvZiB0cnlpbmcgdG8gcmV1c2UgdGhlIERpYW1ldGVyIEVB UCBhcHBsaWNhdGlvbiwgd2hpY2ggaXMNCj4gPiBub3QgcG9zc2libGUNCj4gPiA+IHdpdGhvdXQg bW9kaWZpY2F0aW9ucy4gRUFQIGF1dGhlbnRpY2F0aW9uIGFuZCBNSVA2IHNlcnZpY2UgYWNjZXNz IA0KPiA+ID4gYXV0aG9yaXphdGlvbiBhcmUgcGVyZm9ybWVkIHdpdGggdGhlIHNhbWUgYXBwbGlj YXRpb24uIFNpbmNlIGEgDQo+ID4gPiBhcHBsaWNhdGlvbi1JZCBpcyB3aGF0ZXZlciBuZWVkZWQg Zm9yIHRoZSBIQS9BQUEtTUlQNiwgd2hhdA0KPiA+IHdvdWxkIGJlDQo+ID4gPiB0aGUgYmVuZWZp dCB0byBsb29rIGZvciBzb2x1dGlvbnMgYmluZGluZyBEaWFtZXRlciBFQVAgDQo+IGFuZCBEaWFt ZXRlcg0KPiA+ID4gTUlQNiAod2l0aCBzb21lIGtleSBkZXJpdmF0aW9uLCBldGMuKSB3aGlsZSBh IHNpbmdsZSANCj4gRGlhbWV0ZXIgTUlQNiANCj4gPiA+IGFwcGxpY2F0aW9uIHdpdGggaW50cmlu c2ljIGF1dGhlbnRpY2F0aW9uIGNvbW1hbmRzIHdvdWxkIGJlIGZ1bGx5IA0KPiA+ID4gYXBwcm9w cmlhdGU/DQo+ID4gPiANCj4gPiA+IEkgZG9uJ3QgdW5kZXJzdGFuZCB3aGF0IGlzIHRoZSBwb2lu dCBvZiBkaXNjdXNzaW5nIA0KPiAic2VydmljZSBhY2Nlc3MgDQo+ID4gPiBhdXRob3JpemF0aW9u IG1hbmFnZW1lbnQiIGFuZCAic2ltcGxlIGV4dGVybmFsIGRhdGFiYXNlIi4gDQo+ICBJZiBNSVA2 IA0KPiA+ID4gYXBwbGljYXRpb24gbmVlZHMgdG8gc3VwcG9ydCBtdWx0aXBsZSBhdXRoZW50aWNh dGlvbg0KPiA+IG1ldGhvZHMgc3VjaCBhcw0KPiA+ID4gRUFQIGFuZCBSRkMgNDI4NSwgSSBiZWxp ZXZlIGl0IGlzIG1vcmUgYXBwcm9wcmlhdGUgdG8gY29uc2lkZXIgDQo+ID4gPiBzZXBhcmF0aW9u IG9mIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIGlmIHNlY3VyaXR5IGlzIA0KPiA+ ID4gcmVhc29uYWJseSBoYW5kbGVkLiAgQWxzbywgdGhlcmUgaXMgc29tZSBhdXRoZW50aWNhdGlv bg0KPiA+IG1ldGhvZCAoZS5nLiwNCj4gPiA+IGF1dGhlbnRpY2F0aW9uIGJhc2VkIG9uIElLRXYy LWNlcnQgd2l0aG91dCB1c2luZyBFQVApIGRvZXMNCj4gPiBub3QgcmVxdWlyZQ0KPiA+ID4gYW55 IEFBQSBpbnRlcmFjYXRpb24gZm9yIGF1dGhlbnRpY2F0aW9uLiAgSSB3YXMgcG9pbnRpbmcgdGhp cyBvdXQgDQo+ID4gPiBzZXZlcmFsIHRpbWVzIGJ1dCBubyBvbmUgc2VlbXMgdG8gcGF5IGF0dGVu dGlvbiB0byBpdC4NCj4gPiA+IA0KPiA+ID4gPiANCj4gPiA+ID4gSSdtIHByZXR0eSBzdXJlIHRo YXQgdGhlIGNvbnRlbnQgb2YgdGhpcyBtYWlsIG1heSBiZQ0KPiA+ID4gY2hhbGxlbmdlZCBsaW5l IGJ5IGxpbmUgOykgQnV0IGF0IHRoZSBlbmQsIGlmIGF1dGhlbnRpY2F0aW9uIGFuZCANCj4gPiA+ IGF1dGhvcml6YXRpb24gYXJlIG5lZWRlZCB0byBwcm92aWRlIE1JUDYgc2VydmljZXMsIHdoeSBk bw0KPiA+IG5vdCBoYXZpbmcgYQ0KPiA+ID4gc2luZ2xlIGFwcGxpY2F0aW9uIHRvIGRvIGl0PyBP ZiBjb3Vyc2UsIEkgZG9uJ3Qgc2F5IHRoYXQgaXQNCj4gPiB3b3VsZCBub3QNCj4gPiA+IGJlIHBv c3NpYmxlIHRvIGRvIHNvbWV0aGluZyBtb3JlIGNvbXBsZXguLi4NCj4gPiA+IA0KPiA+ID4gVG8g bWUsIGRpc2N1c3Npb24gb24gY291cGxpbmcgdnMuIGRlY291cGxpbmcgYXV0aGVudGljYXRpb24g YW5kIA0KPiA+ID4gYXV0aG9yaXphdGlvbiBpcyBub3QganVzdCBhIE1JUDYgaXNzdWUuICBUaGlz IGlzIGEgZnVuZGFtZW50YWwgDQo+ID4gPiBkaXNjdXNzaW9uIHRoYXQgd2lsbCBkZWNpZGUgdGhl IGZ1dHVyZSBkaXJlY3Rpb24gb2YgQUFBLg0KPiA+ID4gDQo+ID4gPiBZb3NoaWhpcm8gT2hiYQ0K PiA+ID4gDQo+ID4gPiA+IA0KPiA+ID4gPiBCUiwNCj4gPiA+ID4gDQo+ID4gPiA+IExpb25lbA0K PiA+ID4gPiANCj4gPiA+ID4gDQo+ID4gPiA+ID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0t DQo+ID4gPiA+ID4gRGUgOiBKdWxpZW4gTGFnYW5pZXIgW21haWx0bzpqdWxpZW4uSUVURkBsYXBv c3RlLm5ldF0NCj4gPiA+ID4gPiBFbnZvee+8nyA6IG1hcmRpIDIzIGphbnZpZXIgMjAwNyAxMDo0 Mg0KPiA+ID4gPiA+IO+8nyA6IEFobWFkIE11aGFubmENCj4gPiA+ID4gPiBDYyA6IGRpbWVAaWV0 Zi5vcmcNCj4gPiA+ID4gPiBPYmpldCA6IFJlOiBbRGltZV0gRGlhbWV0ZXIgTW9iaWxlIElQdjYg SEEtdG8tQUFBSCBTdXBwb3J0OiANCj4gPiA+ID4gPiBJc3N1ZSBvciBub3RJc3N1ZSA/DQo+ID4g PiA+ID4gDQo+ID4gPiA+ID4gSGkgQWhtYWQsDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gQ3V0dGlu ZyBhIGJpdCB0aHJ1IHlvdXIgbWVzc2FnZSwgSSBoYXZlIHNvbWUgY29tbWVudHMNCj4gPiA+ID4g PiBiZWxvdzoNCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBPbiBNb25kYXkgMjIgSmFudWFyeSAyMDA3 IDE4OjEwLCBBaG1hZCBNdWhhbm5hIHdyb3RlOg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+DQo+ ID4gPiA+ID4gPlsuLi5dDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gW0FobWFkXQ0KPiA+ID4g PiA+ID4gV2UgYXJlIHByb2JhYmx5IHNwbGl0dGluZyBoYWlyIGhlcmUsIGFwcGFyZW50bHkgDQo+ IHRoZXJlIGFyZSB0d28gDQo+ID4gPiA+ID4gPiBhcmd1bWVudHMgaGVyZToNCj4gPiA+ID4gPiAN Cj4gPiA+ID4gPiBJIGRvbid0IHRoaW5rIHRoaXMgaXMgaGFpciBzcGxpdHRpbmcuIFVuZGVyc3Rh bmQgdGhlDQo+ID4gPiBpc3N1ZSBzaG91bGQgYmUNCj4gPiA+ID4gPiBhIHByZXJlcXVpc2l0ZSB0 byBzb2x2aW5nIGl0Lg0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gMS4gQUFBeiBpcyBhbiBhdXRo b3JpemF0aW9uIHNlcnZlciBhbmQgc2luY2UgaXQgaGFzIGENCj4gPiBzZWN1cml0eQ0KPiA+ID4g PiA+ID4gcmVsYXRpb25zaGlwIHdpdGggdGhlIEhBLCBBQUF6IHJlbGllcyBvbiB0aGUgSEEgdG8g ZG8gdHdvDQo+ID4gPiA+ID4gdGhpbmdzOiAxLjEuIA0KPiA+ID4gPiA+ID4gSEEgbWFrZXMgc3Vy ZSB0aGF0IHRoZSB1c2VyIGhhcyBiZWVuIGF1dGhlbnRpY2F0ZWQgYnkNCj4gPiA+IEFBQW4uIDEu Mi4gDQo+ID4gPiA+ID4gPiBIQSB3aWxsIG5vdCBzZW5kIGFueSBBdXRob3JpemF0aW9uIHJlcXVl c3RzIGZvciBhbnkgdXNlcihzKQ0KPiA+ID4gPiA+IHdobyBoYXMgbm90DQo+ID4gPiA+ID4gPiBi ZWVuIGF1dGhlbnRpY2F0ZWQuDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gKEluIG5vcm1hbCBj b25kaXRpb25zLCB0aGUgYWJvdmUgdHdvIGNvbmRpdGlvbnMgYXJlIEFMV0FZUw0KPiA+ID4gPiA+ IFRSVUUgZXhjZXB0DQo+ID4gPiA+ID4gPiBpbiBvbmUgY29uZGl0aW9uLCBIQSBoYXMgYmVlbg0K PiA+ID4gPiA+ID4gY29tcHJvbWlzZWQpDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gUmlnaHQuIFNv IHdlIGJvdGggYWdyZWUgdGhlcmUncyBubyBwcm9ibGVtIHVubGVzcyB0aGUgSEEgaXMgDQo+ID4g PiA+ID4gY29tcHJvbWlzZWQNCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBJIHRoaW5rIHdoYXQgdGhl IGZpcnN0IHN0ZXAgaXMgdG8gYWdyZWUgb24gYSB0aHJlYXQNCj4gPiA+IG1vZGVsLiBJIGRvIG5v dA0KPiA+ID4gPiA+IGFncmVlIHRoYXQgd2Ugc2hvdWxkIGRlZmVuZCBhZ2FpbnN0IGEgY29tcHJv bWlzZWQgSEEuDQo+ID4gPiA+ID4gVGhlIEhBIHNob3VsZCBiZSBkZWVtZWQgc2VjdXJlIGFnYWlu c3QgYXR0YWNrZXJzLg0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IFdlIGhhdmUgdG8gcGxhY2UgYSBs aW1pdCBvbiB3aGF0IGlzIGVudGl0eSBYIHdoZW4gYXNraW5nIHRoZSANCj4gPiA+ID4gPiBxdWVz dGlvbiAid2hhdCBpZiBlbnRpdHkgWCBpcyBjb21wcm9taXNlZCIuDQo+ID4gPiA+ID4gU2luY2Ug bm90aGluZyBpcyByZWFsbHkgaW1wb3NzaWJsZSBpbiB0aGUgcmVhbCB3b3JsZCwgDQo+IHdlIGNh bm5vdCANCj4gPiA+ID4gPiBkZWZlbmQgYWdhaW5zdCBjb21wcm9taXNzaW9uIG9mIGFueSBlbnRp dHkgaW1wbGljYXRlZCBpbg0KPiA+ID4gYSBwcm90b2NvbC4gDQo+ID4gPiA+ID4gU2VjdXJpdHkg aXMgYSB0cmFkZW9mZi4NCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBNb3JlIGJlbG93Li4uDQo+ID4g PiA+ID4gDQo+ID4gPiA+ID4gPiAyLiBBQUF6IGlzIGFuIGF1dGhvcml6YXRpb24gc2VydmVyIGFu ZCBoYXMgYSBzZWN1cml0eQ0KPiA+ID4gPiA+IGFzc29jaWF0aW9uIHdpdGgNCj4gPiA+ID4gPiA+ IHRoZSBIQSwgaG93ZXZlciwgZHVlIHRvIHRoZSBmYWN0IHRoYXQgdGhlIEhBIGNvdWxkIGJlDQo+ ID4gPiA+ID4gY29tcHJvbWlzZWQsIGENCj4gPiA+ID4gPiA+IHByb2Nlc3MgbmVlZHMgdG8gYmUg aW4gcGxhY2UgZm9yIHRoZSBIQSB0byBBTFdBWVMgDQo+IHByb3ZpZGUgdGhlIA0KPiA+ID4gPiA+ ID4gQUFBeiwgQXV0aG9yaXphdGlvbiBzZXJ2ZXIsIHdpdGggYSBwcm9vZiAodG9rZW4sDQo+ID4g PiA+ID4gPiBldGMuKSB0aGF0IHRoZSB1c2VyIGhhcyBiZWVuIGF1dGhlbnRpY2F0ZWQgYnkgQUFB bi4NCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBPSywgaWYgSEEgY2FuIGJlIGNvbXByb21pc2VkLiBC dXQgd2h5IGFyZSB3ZSBzdG9wcGluZyBoZXJlPyANCj4gPiA+ID4gPiBXaHkgbm90IGNvbnNpZGVy aW5nIHRoZSBjYXNlIHdoZXJlIHRoZSBBQUFuIGlzIGNvbXByb21pc2VkPyANCj4gPiA+ID4gPiBJ cyBpcyBpdCBtb3JlIGxpa2VseSBmb3IgYW4gSEEgdG8gYmUgY29tcHJvbWlzZWQgdGhhbg0KPiA+ IGZvciBhIEFBQW4/DQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gV2UgcmVhbGx5IGhhdmUgdG8gYWdy ZWUgb24gYSB0aHJlYXQgbW9kZWwgZmlyc3QuDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiBJIGFz c3VtZSBoZXJlIHRoYXQgdGhlIGRpZmZlcmVuY2UgaW4gb3BpbmlvbiBpcyBhYm91dCB0aGUNCj4g PiA+ID4gPiBwb3NzaWJpbGl0eQ0KPiA+ID4gPiA+ID4gb2YgdGhlIEhBIHRvIGJlIGNvbXByb21p c2VkIG9yIE5PVC4NCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBFeGFjdGx5Lg0KPiA+ID4gPiA+IA0K PiA+ID4gPiA+IEJlc3QsDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gLS1qdWxpZW4gKEwuKQ0KPiA+ ID4gPiA+IA0KPiA+ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4gPiA+ID4gRGlNRSBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gPiBEaU1FQGll dGYub3JnDQo+ID4gPiA+ID4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZGltZQ0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IA0KPiA+ID4gPiANCj4gPiA+ID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gRGlNRSBtYWls aW5nIGxpc3QNCj4gPiA+ID4gRGlNRUBpZXRmLm9yZw0KPiA+ID4gPiBodHRwczovL3d3dzEuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQo+ID4gPiA+IA0KPiA+ID4gPiANCj4gPiA+IA0K PiA+IA0KPiANCg== --===============0225096963== 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 --===============0225096963==-- From dime-bounces@ietf.org Thu Jan 25 10:26:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA6UD-0004pP-2Z; Thu, 25 Jan 2007 10:26:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA6UC-0004kV-7p for dime@ietf.org; Thu, 25 Jan 2007 10:26:00 -0500 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA6U3-0005DN-S6 for dime@ietf.org; Thu, 25 Jan 2007 10:26:00 -0500 Received: by ug-out-1314.google.com with SMTP id 72so430842ugd for ; Thu, 25 Jan 2007 07:25:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=nDk9bOg/YQNcC4mLIYWvsVZ6U03wIC0GCu3v/WTGcdpbFQworRVEy6Vs0E604JZSPdr5wQ6dYn+aj42FurtRAb4Ae9WozdLGCcrlZKl6cDwnmmUSpMQpcJJpvPjgKCrpHJ3ItEv34xjk5HjRzNnvvOgXXMPrHZTy68DzMhENQcw= Received: by 10.66.244.11 with SMTP id r11mr2877644ugh.1169738750565; Thu, 25 Jan 2007 07:25:50 -0800 (PST) Received: from ?10.129.21.195? ( [80.187.149.253]) by mx.google.com with ESMTP id o1sm2412375uge.2007.01.25.07.25.48; Thu, 25 Jan 2007 07:25:49 -0800 (PST) From: Julien Laganier To: dime@ietf.org Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Issue or notIssue ? Date: Thu, 25 Jan 2007 16:25:46 +0100 User-Agent: KMail/1.8.2 References: <7DBAFEC6A76F3E42817DF1EBE64CB026043BC087@FTRDMEL2.rd.francetelecom.fr> <20070124220639.GB12447@steelhead> In-Reply-To: <20070124220639.GB12447@steelhead> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701251625.46459.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 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 Yoshi, Lionel, Folks, Cutting quite a lot thru the message: On Wednesday 24 January 2007 23:06, Yoshihiro Ohba wrote: > [...] > > On Tue, Jan 23, 2007 at 04:11:49PM +0100, MORAND Lionel RD-CORE-ISS wrote: > > > > [...] > > If AAA-MIP6 provides authorizatin, AAA-EAP provides > authentication, but does not provide authorization. > For this purpose, the HA needs to set > Auth-Request-Type set to AUTHENTICATE_ONLY in > AAA-EAP. In this case, AAA-EAP server does not need > to know what kind of authorization will be made. > The authorization decision will be made by AAA-MIP6. > Am I missing something? Agree. [...] > I don't understand what is the point of discussing > "service access authorization management" and > "simple external database". If MIP6 application > needs to support multiple authentication methods > such as EAP and RFC 4285, I believe it is more > appropriate to consider separation of authentication > and authorization if security is reasonably handled. > Also, there is some authentication method (e.g., > authentication based on IKEv2-cert without using > EAP) does not require any AAA interacation for > authentication. I was pointing this out several > times but no one seems to pay attention to it. I think at the minimum standardized MIPv6 MN-HA authentication schemes MUST be supported. This includes the simplest scheme where MN and HA use a static shared key for ESP (in addition to IKE-based schemes you are mentioning). It would also be consistent with the last sentence of provision 2.2.6 of AAA Authorization Requirements (RFC2906) AAA protocols MUST be capable of leveraging any underlying peer entity authentication mechanisms that may have been applied - this MAY provide additional assurance that the owner of the authorization information is the same as the authenticated entity. For example, if IPSec provides sufficient authentication, then it must be possible to omit AAA protocol authentication. > > I'm pretty sure that the content of this mail may > > be challenged line by line ;) Can we? :) > > But at the end, if authentication and authorization > > are needed to provide MIP6 services, why do not > > having a single application to do it? Modularity. Allow for the different authentication mechanisms (EAP/AAA, IKE, ESP w/ static key) to be leveraged on. > > Of course, I don't say that it would not be > > possible to do something more complex... Modular solutions usually makes things more simple by decoupling aspects of a problem which are independents. > To me, discussion on coupling vs. decoupling > authentication and authorization is not just a MIP6 > issue. This is a fundamental discussion that will > decide the future direction of AAA. Agree completely. Best, --julien _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 25 11:23:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7O8-0008Kf-6b; Thu, 25 Jan 2007 11:23:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7O6-0008KP-O0 for dime@ietf.org; Thu, 25 Jan 2007 11:23:46 -0500 Received: from imx12.toshiba.co.jp ([61.202.160.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA7O0-0000Ug-M3 for dime@ietf.org; Thu, 25 Jan 2007 11:23:46 -0500 Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx12.toshiba.co.jp with ESMTP id l0PGNIYI025336; Fri, 26 Jan 2007 01:23:18 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id l0PGNHLB018995; Fri, 26 Jan 2007 01:23:17 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with ESMTP id BAA18994; Fri, 26 Jan 2007 01:23:17 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id l0PGNGfI026965; Fri, 26 Jan 2007 01:23:16 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id l0PGNGpl027890; Fri, 26 Jan 2007 01:23:16 +0900 (JST) Received: from steelhead ([172.30.24.105]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0JCF008N3MULNES1@mail.po.toshiba.co.jp>; Fri, 26 Jan 2007 01:23:16 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.63) (envelope-from ) id 1HA7NX-0006SE-Re; Thu, 25 Jan 2007 08:23:11 -0800 Date: Thu, 25 Jan 2007 11:23:11 -0500 From: Yoshihiro Ohba Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Issue or notIssue ? In-reply-to: <7DBAFEC6A76F3E42817DF1EBE64CB026043F74D2@FTRDMEL2.rd.francetelecom.fr> To: MORAND Lionel RD-CORE-ISS Message-id: <20070125162311.GA22988@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <7DBAFEC6A76F3E42817DF1EBE64CB026043F74D2@FTRDMEL2.rd.francetelecom.fr> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4515df9441674711565101d9d5c4f63f Cc: dime@ietf.org, Julien Laganier 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, On Thu, Jan 25, 2007 at 12:11:23PM +0100, MORAND Lionel RD-CORE-ISS wrote: > Hi Yoshi, > > 1) If authentication procedures may be performed apart from authorization procedures (I totally agree), authorization procedures must be able to rely on its own authentication procedures if needed (cf. AAA requirements in RFC 2906). Are you OK with that? I am not sure which requirement in RFC 2906 you are reffering to, but let me quote some text in RFC 2906 relating to relationship between authentication and authorization: " 2.2.6 AAA protocols MUST be capable of leveraging any underlying peer entity authentication mechanisms that may have been applied - this MAY provide additional assurance that the owner of the authorization information is the same as the authenticated entity. For example, if IPSec provides sufficient authentication, then it must be possible to omit AAA protocol authentication. 2.2.8 AAA protocols MUST be usable even in environments where no peer entity authentication is required (e.g. a network address on a secure LAN may be enough to decide). 2.9.1 Authorization separate from authentication SHOULD be allowed when necessary, but the AAA protocols MUST also allow for a single message to request both authentication and authorization. AAA protocols have to allow a split between authentication and authorization so that different mechanisms are used for each. This states that sometimes both types of information need to be carried in the same message. 3. Security Considerations This document includes specific security requirements. This document does not state any detailed requirements for the interplay with authentication, accounting or accountability (audit). A AAA protocol, which meets all of the above requirements, may still leave vulnerabilities due to such interactions. Such issues must be considered as part of AAA protocol design. " > > 2) As it is now, providing authentication with Diameter EAP application and authorization with Diameter MIP6 does not allow the AAA-MIP6 to be sure that the username carried in the authorization request was previously authenticated by the AAA-EAP. Are you OK with that? It depends on threat model as Julien Laganier mentioned. In my personal opinion, if AAA clients and servers trust each other, and the assurance of binding between authorization and authentication is made by the AAA clients, I don't think we need a special mechanism. > > 3) If the AAA-MIP6 provides the HA with service related information without being sure that the key entry (username) was previously authenticated, what is the difference between the AAA-MIP6 and a "simple" external database providing information data to any authorized entity (HA in the present case)? What/where is the authorization process in that case? I don't see a difference between the two. In both cases, authorization decision is made by AAA-MIP6. > > 4) If combining Diameter EAP and Diameter MIP6 is more complex than including authentication procedures with Diameter MIP6 that is coherent with AAA requirements, why are we still discussing as much? ;) Including authentication procedures with Diameter MIP6 will be more complex if we need to support multiple authentication methods (EAP and non-EAP) within a single application. Also, Diameter EAP application may be revised due to new work such as HOKEY. If we include EAP within Diameter MIP6, Diameter MIP6 would need to duplicate the same revision in its specification. Isn't it a mess? Also, what happens if we need to suppport QoS for MIP6? Do you want to include QoS support in MIP6 application, or do you want to include MIP6 support in Diameter QoS application, or do you want to decouple QoS and MIP6? > > 5) If the discussion is beyond the scope of the draft and related to the future of global AAA framework, why do not "decouple" the discussions and create a separate thread? But for now, I can see that a Diameter MIP6 application with authentication procedure would be consistent with the current AAA framework while a combinaison of Diameter EAP and Diameter MIP6 will not meet all the AAA requirements without introducing specific functionalites/enhancements. Can you elaborate on which AAA requirements will not be met? > > I would have no problem with a solution proposing EAP authentication procedures and MIP6 authorization procedures supported by to different diameter applications IF it could be possible to bind both procedures in the same equipment in the MSA. That is not the case with the current solution. It is possible by just routing the two different applications to the same server. Yoshihiro Ohba > > BR, > > Lionel > > > > There is a new guy in the game ;) > > > > > > After reviewing the draft and the mail exchange on the > > topic, I would say that the conclusion on "issue/no issue" > > depends on the side you are considering the problem (as often ;). > > > > > > If you are considering the AAA-MIP6 as a "simple" database > > providing the HA with specific user/service information after > > a separate authentication (performed with Diameter > > authentication), the username conveyed over the HA/AAA-MIP6 > > is just used as a key entry in the database. There is no need > > for the AAA-MIP6 to authenticate this username or to be sure > > that the username was previously authenticated. The client of > > the database is the HA and not the user. In that case, the > > AAA-MIP6 has to trust the HA and it is up to the HA to > > authenticate the username provided by the mn during the SA > > set-up. This could be compared to interfaces between HSS > > (Home Subscriber Server) and SIP application servers defined > > in the 3GPP architecture, over which Diameter applications > > are used to access database. > > > > > > In this context, the HA may use: > > > 1) the Diameter EAP application to authenticate the user. > > > 2) the Diameter MIP6 application to download user related service > > > information Authentication and authorization are performed > > by the AAA-EAP. But there is no way for the AAA-EAP to know > > what is the service requested by the user. Successful > > authentication implies implicte authorization. This is the > > problem with Diameter EAP as it is not possible to route > > Diameter EAP request to a service-specific EAP server. > > > > If AAA-MIP6 provides authorizatin, AAA-EAP provides > > authentication, but does not provide authorization. For this > > purpose, the HA needs to set Auth-Request-Type set to > > AUTHENTICATE_ONLY in AAA-EAP. In this case, AAA-EAP server > > does not need to know what kind of authorization will be > > made. The authorization decision will be made by AAA-MIP6. > > Am I missing something? > > > > > > > > In another hand, if the AAA-MIP6 is an authority handling > > MIP6 service access authorization rights i.e. the AAA-MIP6 > > must verify that the user is authorized to use the Mobile > > IPv6 service, this authority has to be able to verify the > > identity of the user before authorizing this user to access > > the service. It is not possible to authorize someone to do > > something without being sure of its identity as the authority > > must stand surety of the user access rights. Now, it is not > > possible to rely on the Diameter EAP application to perform > > the authentication procedure as there is no way to direct the > > Diameter EAP requests to a specifc EAP server (as the > > Diameter routing is based on App-Id and Realm). We might > > think about some specific things to link authentication > > procedures and authorization/service profile handling. But > > for me, the simpliest way would be to define the required > > authentication mechanism within one and only one application > > i.e. the application that requires this authentication. > > Therefore, Diameter EAP would not be used and > > application-specific commands would be specified in the > > application. One command pair would be added to the Diameter > > MIP6 application. And to support EAP, AVPs defined in 4072 > > would be at least (re-)used. > > > > I don't understand the difference between the two cases you > > mentioned above. I believe that more or less the AAA servers > > need to trust the HA in both cases. Depending on threat > > model which we don't seem to exactly know right now, the > > AAA-MIP6 server may or may not need an evidence that the user > > has been authenticated by a AAA-EAP server. > > > > > > > > IMHO, the context described in the draft looks like more a > > service access authorization management than the use of a > > simple external database. I would be therefore in favor of > > defining authentication commands within the Diameter MIP6 > > application instead of trying to reuse the Diameter EAP > > application, which is not possible without modifications. EAP > > authentication and MIP6 service access authorization are > > performed with the same application. Since a application-Id > > is whatever needed for the HA/AAA-MIP6, what would be the > > benefit to look for solutions binding Diameter EAP and > > Diameter MIP6 (with some key derivation, etc.) while a single > > Diameter MIP6 application with intrinsic authentication > > commands would be fully appropriate? > > > > I don't understand what is the point of discussing "service > > access authorization management" and "simple external > > database". If MIP6 application needs to support multiple > > authentication methods such as EAP and RFC 4285, I believe it > > is more appropriate to consider separation of authentication > > and authorization if security is reasonably handled. Also, > > there is some authentication method (e.g., authentication > > based on IKEv2-cert without using EAP) does not require any > > AAA interacation for authentication. I was pointing this out > > several times but no one seems to pay attention to it. > > > > > > > > I'm pretty sure that the content of this mail may be > > challenged line by line ;) But at the end, if authentication > > and authorization are needed to provide MIP6 services, why do > > not having a single application to do it? Of course, I don't > > say that it would not be possible to do something more complex... > > > > To me, discussion on coupling vs. decoupling authentication > > and authorization is not just a MIP6 issue. This is a > > fundamental discussion that will decide the future direction of AAA. > > > > Yoshihiro Ohba > > > > > > > > BR, > > > > > > Lionel > > > > > > > > > > -----Message d'origine----- > > > > De : Julien Laganier [mailto:julien.IETF@laposte.net] > > > > Envoy$B!)(B : mardi 23 janvier 2007 10:42 > > > > $B!)(B : Ahmad Muhanna > > > > Cc : dime@ietf.org > > > > Objet : Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: > > > > Issue or notIssue ? > > > > > > > > Hi Ahmad, > > > > > > > > Cutting a bit thru your message, I have some comments > > > > below: > > > > > > > > On Monday 22 January 2007 18:10, Ahmad Muhanna wrote: > > > > > > > > > > > > > > >[...] > > > > > > > > > > [Ahmad] > > > > > We are probably splitting hair here, apparently there are two > > > > > arguments here: > > > > > > > > I don't think this is hair splitting. Understand the > > issue should be > > > > a prerequisite to solving it. > > > > > > > > > 1. AAAz is an authorization server and since it has a security > > > > > relationship with the HA, AAAz relies on the HA to do two > > > > things: 1.1. > > > > > HA makes sure that the user has been authenticated by > > AAAn. 1.2. > > > > > HA will not send any Authorization requests for any user(s) > > > > who has not > > > > > been authenticated. > > > > > > > > > > (In normal conditions, the above two conditions are ALWAYS > > > > TRUE except > > > > > in one condition, HA has been > > > > > compromised) > > > > > > > > Right. So we both agree there's no problem unless the HA is > > > > compromised > > > > > > > > I think what the first step is to agree on a threat > > model. I do not > > > > agree that we should defend against a compromised HA. > > > > The HA should be deemed secure against attackers. > > > > > > > > We have to place a limit on what is entity X when asking the > > > > question "what if entity X is compromised". > > > > Since nothing is really impossible in the real world, we cannot > > > > defend against compromission of any entity implicated in > > a protocol. > > > > Security is a tradeoff. > > > > > > > > More below... > > > > > > > > > 2. AAAz is an authorization server and has a security > > > > association with > > > > > the HA, however, due to the fact that the HA could be > > > > compromised, a > > > > > process needs to be in place for the HA to ALWAYS provide the > > > > > AAAz, Authorization server, with a proof (token, > > > > > etc.) that the user has been authenticated by AAAn. > > > > > > > > OK, if HA can be compromised. But why are we stopping here? > > > > Why not considering the case where the AAAn is compromised? > > > > Is is it more likely for an HA to be compromised than for a AAAn? > > > > > > > > We really have to agree on a threat model first. > > > > > > > > > I assume here that the difference in opinion is about the > > > > possibility > > > > > of the HA to be compromised or NOT. > > > > > > > > Exactly. > > > > > > > > Best, > > > > > > > > --julien (L.) > > > > > > > > _______________________________________________ > > > > 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 Jan 25 11:57:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7v0-00045l-H2; Thu, 25 Jan 2007 11:57:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7uy-00044p-T7 for dime@ietf.org; Thu, 25 Jan 2007 11:57:44 -0500 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA7uu-0006pG-D3 for dime@ietf.org; Thu, 25 Jan 2007 11:57:44 -0500 Received: by ug-out-1314.google.com with SMTP id 72so451886ugd for ; Thu, 25 Jan 2007 08:57:39 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=WJiTrkUwJ/gHrjsRtvic+HDIuOBuTaDzCiiBR4yvhHZfpGB6eqmb/mwXfYJ99WZViRO80xjKuXepVDaHwVEkd7HATs05X8Zm8MWoxWaXMC/HtDlnyZmATRcw2UOMePoBcoa0q4wd1mInlEJmHzH5Ee0pzp4ugh8ESAsp95USoJ0= Received: by 10.67.99.1 with SMTP id b1mr2994595ugm.1169744259000; Thu, 25 Jan 2007 08:57:39 -0800 (PST) Received: from ?10.129.21.195? ( [80.187.149.253]) by mx.google.com with ESMTP id 39sm2534226ugb.2007.01.25.08.57.33; Thu, 25 Jan 2007 08:57:38 -0800 (PST) From: Julien Laganier To: lionel.morand@orange-ftgroup.com Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Issue or notIssue ? Date: Thu, 25 Jan 2007 17:57:26 +0100 User-Agent: KMail/1.8.2 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701251757.27990.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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 Lionel, Interfering a bit in your discussion: > Hi Yoshi, > > 1) If authentication procedures may be performed > apart from authorization procedures (I totally > agree), authorization procedures must be able to rely > on its own authentication procedures if needed (cf. > AAA requirements in RFC 2906). Are you OK with that? Sure. I think nobody argued about combining the two where it makes sense. But, we also want to support situations in which they are not combined. As per RFC2906. > 2) As it is now, providing authentication with > Diameter EAP application and authorization with > Diameter MIP6 does not allow the AAA-MIP6 to be sure > that the username carried in the authorization > request was previously authenticated by the AAA-EAP. > Are you OK with that? But this is the whole point of the split between Authorization and Authentication split. You do not want the AAA-MIP6 to be sure of anything about whether the username is right or false. That is the role of authentication. To quote the Handbook of Applied Cryptography [1]: entity authentication: corroboration of the identity of an entity (e.g., a person, a computer terminal, a credit card, etc.). authorization: conveyance, to another entity, of official sanction to do or be something. There's nothing in the above definition that states that the authorizer has to verify authentication. > 3) If the AAA-MIP6 provides the HA with service > related information without being sure that the key > entry (username) was previously authenticated, what > is the difference between the AAA-MIP6 and a "simple" > external database providing information data to any > authorized entity (HA in the present case)? > What/where is the authorization process in that case? See above. > 4) If combining Diameter EAP and Diameter MIP6 is > more complex than including authentication procedures > with Diameter MIP6 that is coherent with AAA > requirements, why are we still discussing as much? ;) Because people like to argue :) We have to support non-AAA-based MIP6 authentication, and that is not possible by combining the two. Hence, it's not consistent with AAA requirement 2.2.6 ("For example, if IPSec provides sufficient authentication, then it must be possible to omit AAA protocol authentication.) > 5) If the discussion is beyond the scope of the draft > and related to the future of global AAA framework, > why do not "decouple" the discussions and create a > separate thread? But for now, I can see that a > Diameter MIP6 application with authentication > procedure would be consistent with the current AAA > framework while a combinaison of Diameter EAP and > Diameter MIP6 will not meet all the AAA requirements > without introducing specific > functionalites/enhancements. No, that's combining the two that breaks requirement. > I would have no problem with a solution proposing EAP > authentication procedures and MIP6 authorization > procedures supported by to different diameter > applications IF it could be possible to bind both > procedures in the same equipment in the MSA. That is > not the case with the current solution. Authorization hasn't to be bound to authentication. However, at the enforcement point (HA) it has to be made sure that authenticated user are authorized to access one service. Best, --julien [1] Handbook of Applied Cryptography, by A. Menezes, P. van Oorschot, and S. Vanstone, CRC Press, 1996. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jan 25 12:37:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA8X8-00041h-Hf; Thu, 25 Jan 2007 12:37:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA8X6-00041T-PG for dime@ietf.org; Thu, 25 Jan 2007 12:37:08 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA8X6-00067u-5m for dime@ietf.org; Thu, 25 Jan 2007 12:37:08 -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 l0PHaxl21089; Thu, 25 Jan 2007 12:36:59 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Issue or notIssue ? Date: Thu, 25 Jan 2007 11:36:47 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437112682F9C@zrc2hxm2.corp.nortel.com> In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB026043F76A1@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Issue or notIssue ? Thread-index: AcdAA/r5nUIvzJ8ATjeXOadoEt8alwAWd2gAAAvsElAAASCtUAAEcmeg From: "Ahmad Muhanna" To: "MORAND Lionel RD-CORE-ISS" , "Yoshihiro Ohba" X-Spam-Score: 0.0 (/) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 Cc: dime@ietf.org, Julien Laganier 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="===============1649437853==" Errors-To: dime-bounces@ietf.org --===============1649437853== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTGlvbmVsLA0KVGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlLiBQbGVhc2Ugc2VlIHNvbWUgY29t bWVudHMgaW5saW5lLg0KDQpSZWdhcmRzLA0KQWhtYWQNCiANCg0KPiBTdWJqZWN0OiBSRTogW0Rp bWVdIERpYW1ldGVyIE1vYmlsZSBJUHY2IEhBLXRvLUFBQUggU3VwcG9ydDogDQo+IElzc3VlIG9y IG5vdElzc3VlID8NCj4gDQo+IEhpIEFobWFkLA0KPiANCj4gSnVzdCBhIGNvdXBsZSBvZiByZXF1 aXJlbWVudHM6DQo+IA0KPiAyLjcuMyANCj4gICAgV2l0aGluIGEgc2luZ2xlIHNlc3Npb24gb3Ig dHJhbnNhY3Rpb24sIGl0IE1VU1QgYmUgcG9zc2libGUgdG8NCj4gICAgaW50ZXJsZWF2ZSBhdXRo ZW50aWNhdGlvbiwgYXV0aG9yaXphdGlvbiBhbmQgYWNjb3VudGluZyBBQUEgbWVzc2FnZXMuDQo+ IA0KPiAgICBUaGlzIHN0YXRlcywgdGhhdCBlLmcuIGEgc2Vzc2lvbiBtYXkgaGF2ZSB0byB1c2Ug aW5pdGlhbA0KPiAgICBhdXRoZW50aWNhdGlvbiwgYXV0aG9yaXphdGlvbiBhbmQgYWNjb3VudGlu ZyBBQUEgDQo+IG1lc3NhZ2UocyksIGJ1dCBhbHNvDQo+ICAgIGhhdmUgdG8gaW5jbHVkZSBlLmcu IHJlLWF1dGhlbnRpY2F0aW9uIGV2ZXJ5IDMwIG1pbnV0ZXMsIG9yIGENCj4gICAgY29udGludW91 cyAiZHJpcC1kcmlwIiBvZiBhY2NvdW50aW5nIEFBQSBtZXNzYWdlcy4NCg0KW0FobWFkXQ0KVGhp cyBvbmUgaXMgYSBsaXR0bGUgdHJpY2t5LiBJTU8sIEluIHRoZSBjYXNlIG9mIEF1dGhlbnRpY2F0 aW9uIGFuZCBBdXRob3JpemF0aW9uIHNlcGFyYXRpb24sIHRoZXJlIHdpbGwgYmUgYXV0aGVudGlj YXRpb24sIGF1dGhvcml6YXRpb24sIGFuZCBhY2NvdW50aW5nIGZvciBldmVyeSBzZXNzaW9uLiBE TyB5b3UgdGhpbmsgb3RoZXJ3aXNlPyBJIGRvIG5vdCBzZWUgaGVyZSB0aGF0IHRoZXJlIGlzIGFu IGluZGljYXRpb24gdGhhdCBBdXRob3JpemF0aW9uIGFuZCBBdXRoZW50aWNhdGlvbiBuZWVkcyB0 byBiZSBjb21iaW5lZCBhZ2Fpbi4NCg0KPiANCj4gMi45LjENCj4gICAgQXV0aG9yaXphdGlvbiBz ZXBhcmF0ZSBmcm9tIGF1dGhlbnRpY2F0aW9uIFNIT1VMRCBiZSBhbGxvd2VkDQo+ICAgIHdoZW4g bmVjZXNzYXJ5LCBidXQgdGhlIEFBQSBwcm90b2NvbHMgTVVTVCBhbHNvIGFsbG93IGZvciBhIHNp bmdsZQ0KPiAgICBtZXNzYWdlIHRvIHJlcXVlc3QgYm90aCBhdXRoZW50aWNhdGlvbiBhbmQgYXV0 aG9yaXphdGlvbi4NCj4gDQo+ICAgIEFBQSBwcm90b2NvbHMgaGF2ZSB0byBhbGxvdyBhIHNwbGl0 IGJldHdlZW4gYXV0aGVudGljYXRpb24gYW5kDQo+ICAgIGF1dGhvcml6YXRpb24gc28gdGhhdCBk aWZmZXJlbnQgbWVjaGFuaXNtcyBhcmUgdXNlZCBmb3IgZWFjaC4gVGhpcw0KPiAgICBzdGF0ZXMg dGhhdCBzb21ldGltZXMgYm90aCB0eXBlcyBvZiBpbmZvcm1hdGlvbiBuZWVkIHRvIGJlIA0KPiBj YXJyaWVkIGluDQo+ICAgIHRoZSBzYW1lIG1lc3NhZ2UuDQoNCltBaG1hZF0NCkkgYW0gbm90IHN1 cmUgSSBjYW4gcmVhZCB0aGlzIHJlcXVpcmVtZW50IGFzIGEgcmVxdWlyZW1lbnQgdGhhdCB3aGVu IEF1dGhlbnRpY2F0aW9uIGFuZCBBdXRob3JpemF0aW9uIGFyZSBzZXBhcmF0ZWQsIEF1dGhvcml6 YXRpb24gbWVzc2FnZXMgTVVTVCBwcm92aWRlIGF1dGhlbnRpY2F0aW9uIHRvby4gQmVjYXVzZSBp ZiB0aGF0IHdhcyB0aGUgaW50ZW50aW9uLCB0aGVuIHRoaXMgcmVxdWlyZW1lbnQgZG9lcyBub3Qg bWFrZSBhbnkgc2Vuc2UuIFRoZSBzZWNvbmQgcG9ydGlvbiBvZiBpdCBuZWdhdGUgd2hhdCB0aGUg Zmlyc3QgcG9ydGlvbiBhbHJlYWR5IGFsbG93ZWQgdG8gaGFwcGVuLg0KTXkgaW50ZXJwcmV0YXRp b24gaXMgdGhlIEF1dGhlbnRpY2F0aW9uIGFuZCBBdXRob3JpemF0aW9uIGlzIGZpbmUgYW5kIGFs bG93ZWQsIGhvd2V2ZXIsIEFBQSBwcm90b2NvbHMgc2hvdWxkIGdpdmUgdGhlIG9wdGlvbiBmb3Ig aW50ZWdyYXRlZCBzb2x1dGlvbiwgaS5lLiBBdXRoZW50aWNhdGlvbiBhbmQgQXV0aG9yaXphdGlv biBpbiB0aGUgc2FtZSBtZXNzYWdlIGFuZCBhdCB0aGUgc2FtZSB0aW1lLg0KDQoNCkluIGdlbmVy YWwsIGFzIGxvbmcgYXMgUkZDMjYwOSBBTExPV0VEIHRoZSBzZXBhcmF0aW9uIGJldHdlZW4gQXV0 aGVudGljYXRpb24gYW5kIEF1dGhvcml6YXRpb24sIGl0IGRvZXMgbm90IG1ha2Ugc2Vuc2UgdG8g bWFuZGF0ZSBpbnRlZ3JhdGlvbiBpbiBjYXNlIHNlcGFyYXRpb24gb3B0aW9uIGlzIGFkb3B0ZWQu IEFtIEkgbWFraW5nIHNvbWUgc2Vuc2UgaGVyZS4NCg0KPiANCj4gQnV0IHlvdSBjYW4gZmluZCBz ZXZlcmFsIG90aGVyIHBsYWNlcyBpbiB0aGUgZG9jdW1lbnQgd2hlcmUgIA0KPiBhdXRoZW50aWNh dGlvbiAmIGF1dGhvcml6YXRpb24gYXJlIGJvdW5kLg0KPiANCj4gQlIsDQo+IA0KPiBMaW9uZWwN Cj4gDQo+ID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4gRGUgOiBBaG1hZCBNdWhh bm5hIFttYWlsdG86YW11aGFubmFAbm9ydGVsLmNvbV0gRW52b3nDqSA6IGpldWRpIDI1IA0KPiA+ IGphbnZpZXIgMjAwNyAxNTo0MiDDgCA6IE1PUkFORCBMaW9uZWwgUkQtQ09SRS1JU1M7IFlvc2hp aGlybyANCj4gT2hiYSBDYyA6IA0KPiA+IEp1bGllbiBMYWdhbmllcjsgZGltZUBpZXRmLm9yZyBP YmpldCA6IFJFOiBbRGltZV0gRGlhbWV0ZXIgDQo+IE1vYmlsZSBJUHY2IA0KPiA+IEhBLXRvLUFB QUggU3VwcG9ydDoNCj4gPiBJc3N1ZSBvciBub3RJc3N1ZSA/DQo+ID4gDQo+ID4gSGkgTGlvbmVs LA0KPiA+IFBsZWFzZSBzZWUgc29tZSBvbmUgY29tbWVudCBpbmxpbmUuDQo+ID4gDQo+ID4gUmVn YXJkcywNCj4gPiBBaG1hZA0KPiA+ICANCj4gPiANCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+ID4gPiBGcm9tOiBNT1JBTkQgTGlvbmVsIFJELUNPUkUtSVNTDQo+ID4gPiBbbWFp bHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLWZ0Z3JvdXAuY29tXQ0KPiA+ID4gU2VudDogVGh1cnNk YXksIEphbnVhcnkgMjUsIDIwMDcgNToxMSBBTQ0KPiA+ID4gVG86IFlvc2hpaGlybyBPaGJhDQo+ ID4gPiBDYzogSnVsaWVuIExhZ2FuaWVyOyBNdWhhbm5hLCBBaG1hZCAoUklDSDE6MkgxMCk7IGRp bWVAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJFOiBbRGltZV0gRGlhbWV0ZXIgTW9iaWxlIElQ djYgSEEtdG8tQUFBSCBTdXBwb3J0OiANCj4gPiA+IElzc3VlIG9yIG5vdElzc3VlID8NCj4gPiA+ IA0KPiA+ID4gSGkgWW9zaGksDQo+ID4gPiANCj4gPiA+IDEpIElmIGF1dGhlbnRpY2F0aW9uIHBy b2NlZHVyZXMgbWF5IGJlIHBlcmZvcm1lZCBhcGFydCBmcm9tIA0KPiA+ID4gYXV0aG9yaXphdGlv biBwcm9jZWR1cmVzIChJIHRvdGFsbHkgYWdyZWUpLCBhdXRob3JpemF0aW9uDQo+ID4gcHJvY2Vk dXJlcw0KPiA+ID4gbXVzdCBiZSBhYmxlIHRvIHJlbHkgb24gaXRzIG93biBhdXRoZW50aWNhdGlv biBwcm9jZWR1cmVzIA0KPiBpZiBuZWVkZWQgDQo+ID4gPiAoY2YuIEFBQSByZXF1aXJlbWVudHMg aW4gUkZDIDI5MDYpLiBBcmUgeW91IE9LIHdpdGggdGhhdD8NCj4gPiANCj4gPiBbQWhtYWRdDQo+ ID4gSnVzdCBmb3IgbXkgZWR1Y2F0aW9uLCBjb3VsZCB5b3UgcGxlYXNlIGdpdmUgbWUgYSBwb2lu dGVyIHRvIHdoaWNoIA0KPiA+IHJlcXVpcmVtZW50IHlvdSBhcmUgcmVmZXJyaW5nIGluIFJGQzI5 MDYuDQo+ID4gVGhhbmtzLg0KPiA+IA0KPiA+ID4gDQo+ID4gPiAyKSBBcyBpdCBpcyBub3csIHBy b3ZpZGluZyBhdXRoZW50aWNhdGlvbiB3aXRoIERpYW1ldGVyIEVBUCANCj4gPiA+IGFwcGxpY2F0 aW9uIGFuZCBhdXRob3JpemF0aW9uIHdpdGggRGlhbWV0ZXIgTUlQNiBkb2VzIG5vdCANCj4gYWxs b3cgdGhlDQo+ID4gPiBBQUEtTUlQNiB0byBiZSBzdXJlIHRoYXQgdGhlIHVzZXJuYW1lIGNhcnJp ZWQgaW4gdGhlIA0KPiBhdXRob3JpemF0aW9uIA0KPiA+ID4gcmVxdWVzdCB3YXMgcHJldmlvdXNs eSBhdXRoZW50aWNhdGVkIGJ5IHRoZSBBQUEtRUFQLiBBcmUNCj4gPiB5b3UgT0sgd2l0aA0KPiA+ ID4gdGhhdD8NCj4gPiA+IA0KPiA+ID4gMykgSWYgdGhlIEFBQS1NSVA2IHByb3ZpZGVzIHRoZSBI QSB3aXRoIHNlcnZpY2UgcmVsYXRlZCANCj4gaW5mb3JtYXRpb24gDQo+ID4gPiB3aXRob3V0IGJl aW5nIHN1cmUgdGhhdCB0aGUga2V5IGVudHJ5ICh1c2VybmFtZSkgd2FzIHByZXZpb3VzbHkgDQo+ ID4gPiBhdXRoZW50aWNhdGVkLCB3aGF0IGlzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIEFB QS1NSVA2IGFuZCBhIA0KPiA+ID4gInNpbXBsZSIgZXh0ZXJuYWwgZGF0YWJhc2UgcHJvdmlkaW5n IGluZm9ybWF0aW9uIGRhdGEgdG8gYW55IA0KPiA+ID4gYXV0aG9yaXplZCBlbnRpdHkgKEhBIGlu IHRoZSBwcmVzZW50IGNhc2UpPyBXaGF0L3doZXJlIGlzIHRoZSANCj4gPiA+IGF1dGhvcml6YXRp b24gcHJvY2VzcyBpbiB0aGF0IGNhc2U/DQo+ID4gPiANCj4gPiA+IDQpIElmIGNvbWJpbmluZyBE aWFtZXRlciBFQVAgYW5kIERpYW1ldGVyIE1JUDYgaXMgbW9yZSANCj4gY29tcGxleCB0aGFuIA0K PiA+ID4gaW5jbHVkaW5nIGF1dGhlbnRpY2F0aW9uIHByb2NlZHVyZXMgd2l0aCBEaWFtZXRlciBN SVA2IHRoYXQgaXMgDQo+ID4gPiBjb2hlcmVudCB3aXRoIEFBQSByZXF1aXJlbWVudHMsIHdoeSBh cmUgd2Ugc3RpbGwgZGlzY3Vzc2luZw0KPiA+IGFzIG11Y2g/IA0KPiA+ID4gOykNCj4gPiA+IA0K PiA+ID4gNSkgSWYgdGhlIGRpc2N1c3Npb24gaXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGUgZHJh ZnQgYW5kDQo+ID4gcmVsYXRlZCB0bw0KPiA+ID4gdGhlIGZ1dHVyZSBvZiBnbG9iYWwgQUFBIGZy YW1ld29yaywgd2h5IGRvIG5vdCAiZGVjb3VwbGUiIHRoZSANCj4gPiA+IGRpc2N1c3Npb25zIGFu ZCBjcmVhdGUgYSBzZXBhcmF0ZSB0aHJlYWQ/IEJ1dCBmb3Igbm93LCBJDQo+ID4gY2FuIHNlZSB0 aGF0DQo+ID4gPiBhIERpYW1ldGVyIE1JUDYgYXBwbGljYXRpb24gd2l0aCBhdXRoZW50aWNhdGlv biBwcm9jZWR1cmUgDQo+IHdvdWxkIGJlIA0KPiA+ID4gY29uc2lzdGVudCB3aXRoIHRoZSBjdXJy ZW50IEFBQSBmcmFtZXdvcmsgd2hpbGUgYSBjb21iaW5haXNvbiBvZiANCj4gPiA+IERpYW1ldGVy IEVBUCBhbmQgRGlhbWV0ZXIgTUlQNiB3aWxsIG5vdCBtZWV0IGFsbCB0aGUgQUFBDQo+ID4gcmVx dWlyZW1lbnRzDQo+ID4gPiB3aXRob3V0IGludHJvZHVjaW5nIHNwZWNpZmljIGZ1bmN0aW9uYWxp dGVzL2VuaGFuY2VtZW50cy4NCj4gPiA+IA0KPiA+ID4gSSB3b3VsZCBoYXZlIG5vIHByb2JsZW0g d2l0aCBhIHNvbHV0aW9uIHByb3Bvc2luZyBFQVANCj4gPiBhdXRoZW50aWNhdGlvbg0KPiA+ID4g cHJvY2VkdXJlcyBhbmQgTUlQNiBhdXRob3JpemF0aW9uIHByb2NlZHVyZXMgc3VwcG9ydGVkIGJ5 DQo+ID4gdG8gZGlmZmVyZW50DQo+ID4gPiBkaWFtZXRlciBhcHBsaWNhdGlvbnMgSUYgaXQgY291 bGQgYmUgcG9zc2libGUgdG8gYmluZCBib3RoDQo+ID4gcHJvY2VkdXJlcw0KPiA+ID4gaW4gdGhl IHNhbWUgZXF1aXBtZW50IGluIHRoZSBNU0EuIFRoYXQgaXMgbm90IHRoZSBjYXNlIHdpdGggdGhl IA0KPiA+ID4gY3VycmVudCBzb2x1dGlvbi4NCj4gPiA+IA0KPiA+ID4gQlIsDQo+ID4gPiANCj4g PiA+IExpb25lbA0KPiA+ID4gDQo+ID4gPiA+ID4gVGhlcmUgaXMgYSBuZXcgZ3V5IGluIHRoZSBn YW1lIDspDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gQWZ0ZXIgcmV2aWV3aW5nIHRoZSBkcmFmdCBh bmQgdGhlIG1haWwgZXhjaGFuZ2Ugb24gdGhlDQo+ID4gPiA+IHRvcGljLCBJIHdvdWxkIHNheSB0 aGF0IHRoZSBjb25jbHVzaW9uIG9uICJpc3N1ZS9ubyBpc3N1ZSIgDQo+ID4gPiA+IGRlcGVuZHMg b24gdGhlIHNpZGUgeW91IGFyZSBjb25zaWRlcmluZyB0aGUgcHJvYmxlbSAoYXMgDQo+IG9mdGVu IDspLg0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IElmIHlvdSBhcmUgY29uc2lkZXJpbmcgdGhlIEFB QS1NSVA2IGFzIGEgInNpbXBsZSIgZGF0YWJhc2UNCj4gPiA+ID4gcHJvdmlkaW5nIHRoZSBIQSB3 aXRoIHNwZWNpZmljIHVzZXIvc2VydmljZSBpbmZvcm1hdGlvbiBhZnRlciBhIA0KPiA+ID4gPiBz ZXBhcmF0ZSBhdXRoZW50aWNhdGlvbiAocGVyZm9ybWVkIHdpdGggRGlhbWV0ZXINCj4gPiA+IGF1 dGhlbnRpY2F0aW9uKSwgdGhlDQo+ID4gPiA+IHVzZXJuYW1lIGNvbnZleWVkIG92ZXIgdGhlIEhB L0FBQS1NSVA2IGlzIGp1c3QgdXNlZCBhcyBhDQo+ID4gPiBrZXkgZW50cnkgaW4NCj4gPiA+ID4g dGhlIGRhdGFiYXNlLiBUaGVyZSBpcyBubyBuZWVkIGZvciB0aGUgQUFBLU1JUDYgdG8NCj4gPiA+ IGF1dGhlbnRpY2F0ZSB0aGlzDQo+ID4gPiA+IHVzZXJuYW1lIG9yIHRvIGJlIHN1cmUgdGhhdCB0 aGUgdXNlcm5hbWUgd2FzIHByZXZpb3VzbHkNCj4gPiA+IGF1dGhlbnRpY2F0ZWQuIA0KPiA+ID4g PiBUaGUgY2xpZW50IG9mIHRoZSBkYXRhYmFzZSBpcyB0aGUgSEEgYW5kIG5vdCB0aGUgdXNlci4g SW4NCj4gPiA+IHRoYXQgY2FzZSwNCj4gPiA+ID4gdGhlDQo+ID4gPiA+IEFBQS1NSVA2IGhhcyB0 byB0cnVzdCB0aGUgSEEgYW5kIGl0IGlzIHVwIHRvIHRoZSBIQSB0bw0KPiA+IGF1dGhlbnRpY2F0 ZQ0KPiA+ID4gPiB0aGUgdXNlcm5hbWUgcHJvdmlkZWQgYnkgdGhlIG1uIGR1cmluZyB0aGUgU0Eg c2V0LXVwLiANCj4gPiBUaGlzIGNvdWxkIGJlDQo+ID4gPiA+IGNvbXBhcmVkIHRvIGludGVyZmFj ZXMgYmV0d2VlbiBIU1MgKEhvbWUgU3Vic2NyaWJlcg0KPiA+IFNlcnZlcikgYW5kIFNJUA0KPiA+ ID4gPiBhcHBsaWNhdGlvbiBzZXJ2ZXJzIGRlZmluZWQgaW4gdGhlIDNHUFAgYXJjaGl0ZWN0dXJl LCANCj4gb3ZlciB3aGljaCANCj4gPiA+ID4gRGlhbWV0ZXIgYXBwbGljYXRpb25zIGFyZSB1c2Vk IHRvIGFjY2VzcyBkYXRhYmFzZS4NCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBJbiB0aGlzIGNvbnRl eHQsIHRoZSBIQSBtYXkgdXNlOg0KPiA+ID4gPiA+IDEpIHRoZSBEaWFtZXRlciBFQVAgYXBwbGlj YXRpb24gdG8gYXV0aGVudGljYXRlIHRoZSB1c2VyLiAgDQo+ID4gPiA+ID4gMikgdGhlIERpYW1l dGVyIE1JUDYgYXBwbGljYXRpb24gdG8gZG93bmxvYWQgdXNlcg0KPiA+IHJlbGF0ZWQgc2Vydmlj ZQ0KPiA+ID4gPiA+IGluZm9ybWF0aW9uIEF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9u IGFyZSBwZXJmb3JtZWQNCj4gPiA+ID4gYnkgdGhlIEFBQS1FQVAuIEJ1dCB0aGVyZSBpcyBubyB3 YXkgZm9yIHRoZSBBQUEtRUFQIHRvDQo+ID4ga25vdyB3aGF0IGlzDQo+ID4gPiA+IHRoZSBzZXJ2 aWNlIHJlcXVlc3RlZCBieSB0aGUgdXNlci4gU3VjY2Vzc2Z1bA0KPiA+ID4gYXV0aGVudGljYXRp b24gaW1wbGllcw0KPiA+ID4gPiBpbXBsaWN0ZSBhdXRob3JpemF0aW9uLiBUaGlzIGlzIHRoZSBw cm9ibGVtIHdpdGggRGlhbWV0ZXINCj4gPiA+IEVBUCBhcyBpdCBpcw0KPiA+ID4gPiBub3QgcG9z c2libGUgdG8gcm91dGUgRGlhbWV0ZXIgRUFQIHJlcXVlc3QgdG8gYQ0KPiA+ID4gc2VydmljZS1z cGVjaWZpYyBFQVANCj4gPiA+ID4gc2VydmVyLg0KPiA+ID4gPiANCj4gPiA+ID4gSWYgQUFBLU1J UDYgcHJvdmlkZXMgYXV0aG9yaXphdGluLCBBQUEtRUFQIHByb3ZpZGVzDQo+ID4gYXV0aGVudGlj YXRpb24sDQo+ID4gPiA+IGJ1dCBkb2VzIG5vdCBwcm92aWRlIGF1dGhvcml6YXRpb24uICBGb3Ig dGhpcyBwdXJwb3NlLCB0aGUNCj4gPiA+IEhBIG5lZWRzIHRvDQo+ID4gPiA+IHNldCBBdXRoLVJl cXVlc3QtVHlwZSBzZXQgdG8gQVVUSEVOVElDQVRFX09OTFkgaW4NCj4gPiBBQUEtRUFQLiAgSW4g dGhpcw0KPiA+ID4gPiBjYXNlLCBBQUEtRUFQIHNlcnZlciBkb2VzIG5vdCBuZWVkIHRvIGtub3cg d2hhdCBraW5kIG9mDQo+ID4gPiBhdXRob3JpemF0aW9uDQo+ID4gPiA+IHdpbGwgYmUgbWFkZS4g IFRoZSBhdXRob3JpemF0aW9uIGRlY2lzaW9uIHdpbGwgYmUgbWFkZSBieQ0KPiA+IEFBQS1NSVA2 Lg0KPiA+ID4gPiBBbSBJIG1pc3Npbmcgc29tZXRoaW5nPw0KPiA+ID4gPiANCj4gPiA+ID4gPiAN Cj4gPiA+ID4gPiBJbiBhbm90aGVyIGhhbmQsIGlmIHRoZSBBQUEtTUlQNiBpcyBhbiBhdXRob3Jp dHkgaGFuZGxpbmcNCj4gPiA+ID4gTUlQNiBzZXJ2aWNlIGFjY2VzcyBhdXRob3JpemF0aW9uIHJp Z2h0cyBpLmUuIHRoZSBBQUEtTUlQNg0KPiA+ID4gbXVzdCB2ZXJpZnkNCj4gPiA+ID4gdGhhdCB0 aGUgdXNlciBpcyBhdXRob3JpemVkIHRvIHVzZSB0aGUgTW9iaWxlDQo+ID4gPiA+IElQdjYgc2Vy dmljZSwgdGhpcyBhdXRob3JpdHkgaGFzIHRvIGJlIGFibGUgdG8gdmVyaWZ5IHRoZQ0KPiA+ID4g aWRlbnRpdHkgb2YNCj4gPiA+ID4gdGhlIHVzZXIgYmVmb3JlIGF1dGhvcml6aW5nIHRoaXMgdXNl ciB0byBhY2Nlc3MgdGhlDQo+ID4gPiBzZXJ2aWNlLiBJdCBpcyBub3QNCj4gPiA+ID4gcG9zc2li bGUgdG8gYXV0aG9yaXplIHNvbWVvbmUgdG8gZG8gc29tZXRoaW5nIHdpdGhvdXQNCj4gPiBiZWlu ZyBzdXJlIG9mDQo+ID4gPiA+IGl0cyBpZGVudGl0eSBhcyB0aGUgYXV0aG9yaXR5IG11c3Qgc3Rh bmQgc3VyZXR5IG9mIHRoZQ0KPiA+IHVzZXIgYWNjZXNzDQo+ID4gPiA+IHJpZ2h0cy4gTm93LCBp dCBpcyBub3QgcG9zc2libGUgdG8gcmVseSBvbiB0aGUgRGlhbWV0ZXIgRUFQIA0KPiA+ID4gPiBh cHBsaWNhdGlvbiB0byBwZXJmb3JtIHRoZSBhdXRoZW50aWNhdGlvbiBwcm9jZWR1cmUgYXMNCj4g PiA+IHRoZXJlIGlzIG5vIHdheQ0KPiA+ID4gPiB0byBkaXJlY3QgdGhlIERpYW1ldGVyIEVBUCBy ZXF1ZXN0cyB0byBhIHNwZWNpZmMgRUFQDQo+ID4gc2VydmVyIChhcyB0aGUNCj4gPiA+ID4gRGlh bWV0ZXIgcm91dGluZyBpcyBiYXNlZCBvbiBBcHAtSWQgYW5kIFJlYWxtKS4gV2UgbWlnaHQNCj4g PiA+IHRoaW5rIGFib3V0DQo+ID4gPiA+IHNvbWUgc3BlY2lmaWMgdGhpbmdzIHRvIGxpbmsgYXV0 aGVudGljYXRpb24gcHJvY2VkdXJlcyBhbmQgDQo+ID4gPiA+IGF1dGhvcml6YXRpb24vc2Vydmlj ZSBwcm9maWxlIGhhbmRsaW5nLiBCdXQgZm9yIG1lLCB0aGUNCj4gPiA+IHNpbXBsaWVzdCB3YXkN Cj4gPiA+ID4gd291bGQgYmUgdG8gZGVmaW5lIHRoZSByZXF1aXJlZCBhdXRoZW50aWNhdGlvbiBt ZWNoYW5pc20NCj4gPiB3aXRoaW4gb25lDQo+ID4gPiA+IGFuZCBvbmx5IG9uZSBhcHBsaWNhdGlv biBpLmUuIHRoZSBhcHBsaWNhdGlvbiB0aGF0IA0KPiByZXF1aXJlcyB0aGlzIA0KPiA+ID4gPiBh dXRoZW50aWNhdGlvbi4NCj4gPiA+ID4gVGhlcmVmb3JlLCBEaWFtZXRlciBFQVAgd291bGQgbm90 IGJlIHVzZWQgYW5kDQo+ID4gYXBwbGljYXRpb24tc3BlY2lmaWMNCj4gPiA+ID4gY29tbWFuZHMg d291bGQgYmUgc3BlY2lmaWVkIGluIHRoZSBhcHBsaWNhdGlvbi4gT25lIGNvbW1hbmQNCj4gPiA+ IHBhaXIgd291bGQNCj4gPiA+ID4gYmUgYWRkZWQgdG8gdGhlIERpYW1ldGVyDQo+ID4gPiA+IE1J UDYgYXBwbGljYXRpb24uIEFuZCB0byBzdXBwb3J0IEVBUCwgQVZQcyBkZWZpbmVkIGluIDQwNzIN Cj4gPiA+IHdvdWxkIGJlIGF0DQo+ID4gPiA+IGxlYXN0IChyZS0pdXNlZC4NCj4gPiA+ID4gDQo+ ID4gPiA+IEkgZG9uJ3QgdW5kZXJzdGFuZCB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSB0d28g Y2FzZXMgeW91DQo+ID4gPiBtZW50aW9uZWQNCj4gPiA+ID4gYWJvdmUuICBJIGJlbGlldmUgdGhh dCBtb3JlIG9yIGxlc3MgdGhlIEFBQSBzZXJ2ZXJzIG5lZWQgdG8NCj4gPiA+IHRydXN0IHRoZQ0K PiA+ID4gPiBIQSBpbiBib3RoIGNhc2VzLiAgRGVwZW5kaW5nIG9uIHRocmVhdCBtb2RlbCB3aGlj aCB3ZQ0KPiA+IGRvbid0IHNlZW0gdG8NCj4gPiA+ID4gZXhhY3RseSBrbm93IHJpZ2h0IG5vdywg dGhlDQo+ID4gPiA+IEFBQS1NSVA2IHNlcnZlciBtYXkgb3IgbWF5IG5vdCBuZWVkIGFuIGV2aWRl bmNlIHRoYXQgdGhlDQo+ID4gPiB1c2VyIGhhcyBiZWVuDQo+ID4gPiA+IGF1dGhlbnRpY2F0ZWQg YnkgYSBBQUEtRUFQIHNlcnZlci4NCj4gPiA+ID4gDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gSU1I TywgdGhlIGNvbnRleHQgZGVzY3JpYmVkIGluIHRoZSBkcmFmdCBsb29rcyBsaWtlIG1vcmUgYQ0K PiA+ID4gPiBzZXJ2aWNlIGFjY2VzcyBhdXRob3JpemF0aW9uIG1hbmFnZW1lbnQgdGhhbiB0aGUg dXNlIG9mIA0KPiBhIHNpbXBsZSANCj4gPiA+ID4gZXh0ZXJuYWwgZGF0YWJhc2UuIEkgd291bGQg YmUgdGhlcmVmb3JlIGluIGZhdm9yIG9mIGRlZmluaW5nIA0KPiA+ID4gPiBhdXRoZW50aWNhdGlv biBjb21tYW5kcyB3aXRoaW4gdGhlIERpYW1ldGVyIE1JUDYNCj4gPiA+IGFwcGxpY2F0aW9uIGlu c3RlYWQNCj4gPiA+ID4gb2YgdHJ5aW5nIHRvIHJldXNlIHRoZSBEaWFtZXRlciBFQVAgYXBwbGlj YXRpb24sIHdoaWNoIGlzDQo+ID4gPiBub3QgcG9zc2libGUNCj4gPiA+ID4gd2l0aG91dCBtb2Rp ZmljYXRpb25zLiBFQVAgYXV0aGVudGljYXRpb24gYW5kIE1JUDYgDQo+IHNlcnZpY2UgYWNjZXNz IA0KPiA+ID4gPiBhdXRob3JpemF0aW9uIGFyZSBwZXJmb3JtZWQgd2l0aCB0aGUgc2FtZSBhcHBs aWNhdGlvbi4gU2luY2UgYSANCj4gPiA+ID4gYXBwbGljYXRpb24tSWQgaXMgd2hhdGV2ZXIgbmVl ZGVkIGZvciB0aGUgSEEvQUFBLU1JUDYsIHdoYXQNCj4gPiA+IHdvdWxkIGJlDQo+ID4gPiA+IHRo ZSBiZW5lZml0IHRvIGxvb2sgZm9yIHNvbHV0aW9ucyBiaW5kaW5nIERpYW1ldGVyIEVBUA0KPiA+ IGFuZCBEaWFtZXRlcg0KPiA+ID4gPiBNSVA2ICh3aXRoIHNvbWUga2V5IGRlcml2YXRpb24sIGV0 Yy4pIHdoaWxlIGEgc2luZ2xlDQo+ID4gRGlhbWV0ZXIgTUlQNg0KPiA+ID4gPiBhcHBsaWNhdGlv biB3aXRoIGludHJpbnNpYyBhdXRoZW50aWNhdGlvbiBjb21tYW5kcyANCj4gd291bGQgYmUgZnVs bHkgDQo+ID4gPiA+IGFwcHJvcHJpYXRlPw0KPiA+ID4gPiANCj4gPiA+ID4gSSBkb24ndCB1bmRl cnN0YW5kIHdoYXQgaXMgdGhlIHBvaW50IG9mIGRpc2N1c3NpbmcNCj4gPiAic2VydmljZSBhY2Nl c3MNCj4gPiA+ID4gYXV0aG9yaXphdGlvbiBtYW5hZ2VtZW50IiBhbmQgInNpbXBsZSBleHRlcm5h bCBkYXRhYmFzZSIuIA0KPiA+ICBJZiBNSVA2DQo+ID4gPiA+IGFwcGxpY2F0aW9uIG5lZWRzIHRv IHN1cHBvcnQgbXVsdGlwbGUgYXV0aGVudGljYXRpb24NCj4gPiA+IG1ldGhvZHMgc3VjaCBhcw0K PiA+ID4gPiBFQVAgYW5kIFJGQyA0Mjg1LCBJIGJlbGlldmUgaXQgaXMgbW9yZSBhcHByb3ByaWF0 ZSB0byBjb25zaWRlciANCj4gPiA+ID4gc2VwYXJhdGlvbiBvZiBhdXRoZW50aWNhdGlvbiBhbmQg YXV0aG9yaXphdGlvbiBpZiBzZWN1cml0eSBpcyANCj4gPiA+ID4gcmVhc29uYWJseSBoYW5kbGVk LiAgQWxzbywgdGhlcmUgaXMgc29tZSBhdXRoZW50aWNhdGlvbg0KPiA+ID4gbWV0aG9kIChlLmcu LA0KPiA+ID4gPiBhdXRoZW50aWNhdGlvbiBiYXNlZCBvbiBJS0V2Mi1jZXJ0IHdpdGhvdXQgdXNp bmcgRUFQKSBkb2VzDQo+ID4gPiBub3QgcmVxdWlyZQ0KPiA+ID4gPiBhbnkgQUFBIGludGVyYWNh dGlvbiBmb3IgYXV0aGVudGljYXRpb24uICBJIHdhcyANCj4gcG9pbnRpbmcgdGhpcyBvdXQgDQo+ ID4gPiA+IHNldmVyYWwgdGltZXMgYnV0IG5vIG9uZSBzZWVtcyB0byBwYXkgYXR0ZW50aW9uIHRv IGl0Lg0KPiA+ID4gPiANCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBJJ20gcHJldHR5IHN1cmUgdGhh dCB0aGUgY29udGVudCBvZiB0aGlzIG1haWwgbWF5IGJlDQo+ID4gPiA+IGNoYWxsZW5nZWQgbGlu ZSBieSBsaW5lIDspIEJ1dCBhdCB0aGUgZW5kLCBpZiANCj4gYXV0aGVudGljYXRpb24gYW5kIA0K PiA+ID4gPiBhdXRob3JpemF0aW9uIGFyZSBuZWVkZWQgdG8gcHJvdmlkZSBNSVA2IHNlcnZpY2Vz LCB3aHkgZG8NCj4gPiA+IG5vdCBoYXZpbmcgYQ0KPiA+ID4gPiBzaW5nbGUgYXBwbGljYXRpb24g dG8gZG8gaXQ/IE9mIGNvdXJzZSwgSSBkb24ndCBzYXkgdGhhdCBpdA0KPiA+ID4gd291bGQgbm90 DQo+ID4gPiA+IGJlIHBvc3NpYmxlIHRvIGRvIHNvbWV0aGluZyBtb3JlIGNvbXBsZXguLi4NCj4g PiA+ID4gDQo+ID4gPiA+IFRvIG1lLCBkaXNjdXNzaW9uIG9uIGNvdXBsaW5nIHZzLiBkZWNvdXBs aW5nIGF1dGhlbnRpY2F0aW9uIGFuZCANCj4gPiA+ID4gYXV0aG9yaXphdGlvbiBpcyBub3QganVz dCBhIE1JUDYgaXNzdWUuICBUaGlzIGlzIGEgZnVuZGFtZW50YWwgDQo+ID4gPiA+IGRpc2N1c3Np b24gdGhhdCB3aWxsIGRlY2lkZSB0aGUgZnV0dXJlIGRpcmVjdGlvbiBvZiBBQUEuDQo+ID4gPiA+ IA0KPiA+ID4gPiBZb3NoaWhpcm8gT2hiYQ0KPiA+ID4gPiANCj4gPiA+ID4gPiANCj4gPiA+ID4g PiBCUiwNCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBMaW9uZWwNCj4gPiA+ID4gPiANCj4gPiA+ID4g PiANCj4gPiA+ID4gPiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+ID4gPiA+ID4g RGUgOiBKdWxpZW4gTGFnYW5pZXIgW21haWx0bzpqdWxpZW4uSUVURkBsYXBvc3RlLm5ldF0NCj4g PiA+ID4gPiA+IEVudm9577yfIDogbWFyZGkgMjMgamFudmllciAyMDA3IDEwOjQyDQo+ID4gPiA+ ID4gPiDvvJ8gOiBBaG1hZCBNdWhhbm5hDQo+ID4gPiA+ID4gPiBDYyA6IGRpbWVAaWV0Zi5vcmcN Cj4gPiA+ID4gPiA+IE9iamV0IDogUmU6IFtEaW1lXSBEaWFtZXRlciBNb2JpbGUgSVB2NiBIQS10 by1BQUFIIFN1cHBvcnQ6IA0KPiA+ID4gPiA+ID4gSXNzdWUgb3Igbm90SXNzdWUgPw0KPiA+ID4g PiA+ID4gDQo+ID4gPiA+ID4gPiBIaSBBaG1hZCwNCj4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4g Q3V0dGluZyBhIGJpdCB0aHJ1IHlvdXIgbWVzc2FnZSwgSSBoYXZlIHNvbWUgY29tbWVudHMNCj4g PiA+ID4gPiA+IGJlbG93Og0KPiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiBPbiBNb25kYXkgMjIg SmFudWFyeSAyMDA3IDE4OjEwLCBBaG1hZCBNdWhhbm5hIHdyb3RlOg0KPiA+ID4gPiA+ID4gPg0K PiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPlsuLi5dDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ ID4gPiA+IFtBaG1hZF0NCj4gPiA+ID4gPiA+ID4gV2UgYXJlIHByb2JhYmx5IHNwbGl0dGluZyBo YWlyIGhlcmUsIGFwcGFyZW50bHkNCj4gPiB0aGVyZSBhcmUgdHdvDQo+ID4gPiA+ID4gPiA+IGFy Z3VtZW50cyBoZXJlOg0KPiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiBJIGRvbid0IHRoaW5rIHRo aXMgaXMgaGFpciBzcGxpdHRpbmcuIFVuZGVyc3RhbmQgdGhlDQo+ID4gPiA+IGlzc3VlIHNob3Vs ZCBiZQ0KPiA+ID4gPiA+ID4gYSBwcmVyZXF1aXNpdGUgdG8gc29sdmluZyBpdC4NCj4gPiA+ID4g PiA+IA0KPiA+ID4gPiA+ID4gPiAxLiBBQUF6IGlzIGFuIGF1dGhvcml6YXRpb24gc2VydmVyIGFu ZCBzaW5jZSBpdCBoYXMgYQ0KPiA+ID4gc2VjdXJpdHkNCj4gPiA+ID4gPiA+ID4gcmVsYXRpb25z aGlwIHdpdGggdGhlIEhBLCBBQUF6IHJlbGllcyBvbiB0aGUgSEEgdG8gZG8gdHdvDQo+ID4gPiA+ ID4gPiB0aGluZ3M6IDEuMS4gDQo+ID4gPiA+ID4gPiA+IEhBIG1ha2VzIHN1cmUgdGhhdCB0aGUg dXNlciBoYXMgYmVlbiBhdXRoZW50aWNhdGVkIGJ5DQo+ID4gPiA+IEFBQW4uIDEuMi4gDQo+ID4g PiA+ID4gPiA+IEhBIHdpbGwgbm90IHNlbmQgYW55IEF1dGhvcml6YXRpb24gcmVxdWVzdHMgZm9y IA0KPiBhbnkgdXNlcihzKQ0KPiA+ID4gPiA+ID4gd2hvIGhhcyBub3QNCj4gPiA+ID4gPiA+ID4g YmVlbiBhdXRoZW50aWNhdGVkLg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiAoSW4gbm9y bWFsIGNvbmRpdGlvbnMsIHRoZSBhYm92ZSB0d28gY29uZGl0aW9ucyBhcmUgQUxXQVlTDQo+ID4g PiA+ID4gPiBUUlVFIGV4Y2VwdA0KPiA+ID4gPiA+ID4gPiBpbiBvbmUgY29uZGl0aW9uLCBIQSBo YXMgYmVlbg0KPiA+ID4gPiA+ID4gPiBjb21wcm9taXNlZCkNCj4gPiA+ID4gPiA+IA0KPiA+ID4g PiA+ID4gUmlnaHQuIFNvIHdlIGJvdGggYWdyZWUgdGhlcmUncyBubyBwcm9ibGVtIHVubGVzcyB0 aGUgSEEgaXMgDQo+ID4gPiA+ID4gPiBjb21wcm9taXNlZA0KPiA+ID4gPiA+ID4gDQo+ID4gPiA+ ID4gPiBJIHRoaW5rIHdoYXQgdGhlIGZpcnN0IHN0ZXAgaXMgdG8gYWdyZWUgb24gYSB0aHJlYXQN Cj4gPiA+ID4gbW9kZWwuIEkgZG8gbm90DQo+ID4gPiA+ID4gPiBhZ3JlZSB0aGF0IHdlIHNob3Vs ZCBkZWZlbmQgYWdhaW5zdCBhIGNvbXByb21pc2VkIEhBLg0KPiA+ID4gPiA+ID4gVGhlIEhBIHNo b3VsZCBiZSBkZWVtZWQgc2VjdXJlIGFnYWluc3QgYXR0YWNrZXJzLg0KPiA+ID4gPiA+ID4gDQo+ ID4gPiA+ID4gPiBXZSBoYXZlIHRvIHBsYWNlIGEgbGltaXQgb24gd2hhdCBpcyBlbnRpdHkgWCB3 aGVuIA0KPiBhc2tpbmcgdGhlIA0KPiA+ID4gPiA+ID4gcXVlc3Rpb24gIndoYXQgaWYgZW50aXR5 IFggaXMgY29tcHJvbWlzZWQiLg0KPiA+ID4gPiA+ID4gU2luY2Ugbm90aGluZyBpcyByZWFsbHkg aW1wb3NzaWJsZSBpbiB0aGUgcmVhbCB3b3JsZCwNCj4gPiB3ZSBjYW5ub3QNCj4gPiA+ID4gPiA+ IGRlZmVuZCBhZ2FpbnN0IGNvbXByb21pc3Npb24gb2YgYW55IGVudGl0eSBpbXBsaWNhdGVkIGlu DQo+ID4gPiA+IGEgcHJvdG9jb2wuIA0KPiA+ID4gPiA+ID4gU2VjdXJpdHkgaXMgYSB0cmFkZW9m Zi4NCj4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gTW9yZSBiZWxvdy4uLg0KPiA+ID4gPiA+ID4g DQo+ID4gPiA+ID4gPiA+IDIuIEFBQXogaXMgYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIGhh cyBhIHNlY3VyaXR5DQo+ID4gPiA+ID4gPiBhc3NvY2lhdGlvbiB3aXRoDQo+ID4gPiA+ID4gPiA+ IHRoZSBIQSwgaG93ZXZlciwgZHVlIHRvIHRoZSBmYWN0IHRoYXQgdGhlIEhBIGNvdWxkIGJlDQo+ ID4gPiA+ID4gPiBjb21wcm9taXNlZCwgYQ0KPiA+ID4gPiA+ID4gPiBwcm9jZXNzIG5lZWRzIHRv IGJlIGluIHBsYWNlIGZvciB0aGUgSEEgdG8gQUxXQVlTDQo+ID4gcHJvdmlkZSB0aGUNCj4gPiA+ ID4gPiA+ID4gQUFBeiwgQXV0aG9yaXphdGlvbiBzZXJ2ZXIsIHdpdGggYSBwcm9vZiAodG9rZW4s DQo+ID4gPiA+ID4gPiA+IGV0Yy4pIHRoYXQgdGhlIHVzZXIgaGFzIGJlZW4gYXV0aGVudGljYXRl ZCBieSBBQUFuLg0KPiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiBPSywgaWYgSEEgY2FuIGJlIGNv bXByb21pc2VkLiBCdXQgd2h5IGFyZSB3ZSBzdG9wcGluZyBoZXJlPyANCj4gPiA+ID4gPiA+IFdo eSBub3QgY29uc2lkZXJpbmcgdGhlIGNhc2Ugd2hlcmUgdGhlIEFBQW4gaXMgY29tcHJvbWlzZWQ/ IA0KPiA+ID4gPiA+ID4gSXMgaXMgaXQgbW9yZSBsaWtlbHkgZm9yIGFuIEhBIHRvIGJlIGNvbXBy b21pc2VkIHRoYW4NCj4gPiA+IGZvciBhIEFBQW4/DQo+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+ IFdlIHJlYWxseSBoYXZlIHRvIGFncmVlIG9uIGEgdGhyZWF0IG1vZGVsIGZpcnN0Lg0KPiA+ID4g PiA+ID4gDQo+ID4gPiA+ID4gPiA+IEkgYXNzdW1lIGhlcmUgdGhhdCB0aGUgZGlmZmVyZW5jZSBp biBvcGluaW9uIGlzIGFib3V0IHRoZQ0KPiA+ID4gPiA+ID4gcG9zc2liaWxpdHkNCj4gPiA+ID4g PiA+ID4gb2YgdGhlIEhBIHRvIGJlIGNvbXByb21pc2VkIG9yIE5PVC4NCj4gPiA+ID4gPiA+IA0K PiA+ID4gPiA+ID4gRXhhY3RseS4NCj4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gQmVzdCwNCj4g PiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gLS1qdWxpZW4gKEwuKQ0KPiA+ID4gPiA+ID4gDQo+ID4g PiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+ID4gPiA+ID4gRGlNRSBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gPiA+IERpTUVAaWV0Zi5vcmcN Cj4gPiA+ID4gPiA+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUN Cj4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gPiBEaU1F IG1haWxpbmcgbGlzdA0KPiA+ID4gPiA+IERpTUVAaWV0Zi5vcmcNCj4gPiA+ID4gPiBodHRwczov L3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQo+ID4gPiA+ID4gDQo+ID4gPiA+ ID4gDQo+ID4gPiA+IA0KPiA+ID4gDQo+ID4gDQo+IA0K --===============1649437853== 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 --===============1649437853==-- From dime-bounces@ietf.org Thu Jan 25 13:01:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA8uS-000289-T7; Thu, 25 Jan 2007 13:01:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA8uR-000284-O6 for dime@ietf.org; Thu, 25 Jan 2007 13:01:15 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16] helo=p-mail2.rd.orange-ftgroup.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA8uQ-0001zG-MR for dime@ietf.org; Thu, 25 Jan 2007 13:01:15 -0500 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 19:00:46 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Issue or notIssue ? Date: Thu, 25 Jan 2007 19:00:40 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026043F77B1@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Issue or notIssue ? thread-index: AcdAA/r5nUIvzJ8ATjeXOadoEt8alwAWd2gAAAvsElAAASCtUAAEcmegAAF0xzA= From: "MORAND Lionel RD-CORE-ISS" To: "Ahmad Muhanna" , "Yoshihiro Ohba" X-OriginalArrivalTime: 25 Jan 2007 18:00:46.0806 (UTC) FILETIME=[BD4F5760:01C740AA] X-Spam-Score: 0.1 (/) X-Scan-Signature: 9cc83ac38bbbabacbf00f656311dd8d8 Cc: dime@ietf.org, Julien Laganier 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="===============0085606759==" Errors-To: dime-bounces@ietf.org --===============0085606759== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWhtYWQsDQoNCkkgdGhpbmsgdGhhdCB0aGVyZSBpcyBhIGNvbmZ1c2lvbiBiZXR3ZWVuICJB QUEgbWVzc2FnZXMiIGFuZCAiQUFBIHByb3RvY29scyIuDQpUaGVyZWZvcmUsIHdoZW4gdGhleSBz cGVhayBhYm91dCAic2VwYXJhdGlvbiIsIGl0J3MgYWJvdXQgc2VwYXJhdGlvbiBvZiBBQUEgbWVz c2FnZXMgd2l0aGluIHRoZSBzYW1lIEFBQSBwcm90b2NvbCwgYW5kIG5vdCBzZXBhcmF0aW9uIG9m IEFBQSBwcm90b2NvbHMuDQoNCklmIHdlIGhhdmUgdG8ga2VlcCBvbmx5IG9uZSBzdGF0ZW1lbnQs IGl0IHdvdWxkIGJlOg0KDQoidGhlIEFBQSBwcm90b2NvbHMgTVVTVCBhbHNvIGFsbG93IGZvciBh IHNpbmdsZSBtZXNzYWdlIHRvIHJlcXVlc3QgYm90aCBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9y aXphdGlvbi4iDQoNCkxpb25lbA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBE ZSA6IEFobWFkIE11aGFubmEgW21haWx0bzphbXVoYW5uYUBub3J0ZWwuY29tXSANCj4gRW52b3nD qSA6IGpldWRpIDI1IGphbnZpZXIgMjAwNyAxODozNw0KPiDDgCA6IE1PUkFORCBMaW9uZWwgUkQt Q09SRS1JU1M7IFlvc2hpaGlybyBPaGJhDQo+IENjIDogSnVsaWVuIExhZ2FuaWVyOyBkaW1lQGll dGYub3JnDQo+IE9iamV0IDogUkU6IFtEaW1lXSBEaWFtZXRlciBNb2JpbGUgSVB2NiBIQS10by1B QUFIIFN1cHBvcnQ6IA0KPiBJc3N1ZSBvciBub3RJc3N1ZSA/DQo+IA0KPiBIaSBMaW9uZWwsDQo+ IFRoYW5rcyBmb3IgeW91ciByZXNwb25zZS4gUGxlYXNlIHNlZSBzb21lIGNvbW1lbnRzIGlubGlu ZS4NCj4gDQo+IFJlZ2FyZHMsDQo+IEFobWFkDQo+ICANCj4gDQo+ID4gU3ViamVjdDogUkU6IFtE aW1lXSBEaWFtZXRlciBNb2JpbGUgSVB2NiBIQS10by1BQUFIIFN1cHBvcnQ6IA0KPiA+IElzc3Vl IG9yIG5vdElzc3VlID8NCj4gPiANCj4gPiBIaSBBaG1hZCwNCj4gPiANCj4gPiBKdXN0IGEgY291 cGxlIG9mIHJlcXVpcmVtZW50czoNCj4gPiANCj4gPiAyLjcuMyANCj4gPiAgICBXaXRoaW4gYSBz aW5nbGUgc2Vzc2lvbiBvciB0cmFuc2FjdGlvbiwgaXQgTVVTVCBiZSBwb3NzaWJsZSB0bw0KPiA+ ICAgIGludGVybGVhdmUgYXV0aGVudGljYXRpb24sIGF1dGhvcml6YXRpb24gYW5kIGFjY291bnRp bmcgDQo+IEFBQSBtZXNzYWdlcy4NCj4gPiANCj4gPiAgICBUaGlzIHN0YXRlcywgdGhhdCBlLmcu IGEgc2Vzc2lvbiBtYXkgaGF2ZSB0byB1c2UgaW5pdGlhbA0KPiA+ICAgIGF1dGhlbnRpY2F0aW9u LCBhdXRob3JpemF0aW9uIGFuZCBhY2NvdW50aW5nIEFBQSBtZXNzYWdlKHMpLCBidXQgDQo+ID4g YWxzbw0KPiA+ICAgIGhhdmUgdG8gaW5jbHVkZSBlLmcuIHJlLWF1dGhlbnRpY2F0aW9uIGV2ZXJ5 IDMwIG1pbnV0ZXMsIG9yIGENCj4gPiAgICBjb250aW51b3VzICJkcmlwLWRyaXAiIG9mIGFjY291 bnRpbmcgQUFBIG1lc3NhZ2VzLg0KPiANCj4gW0FobWFkXQ0KPiBUaGlzIG9uZSBpcyBhIGxpdHRs ZSB0cmlja3kuIElNTywgSW4gdGhlIGNhc2Ugb2YgDQo+IEF1dGhlbnRpY2F0aW9uIGFuZCBBdXRo b3JpemF0aW9uIHNlcGFyYXRpb24sIHRoZXJlIHdpbGwgYmUgDQo+IGF1dGhlbnRpY2F0aW9uLCBh dXRob3JpemF0aW9uLCBhbmQgYWNjb3VudGluZyBmb3IgZXZlcnkgDQo+IHNlc3Npb24uIERPIHlv dSB0aGluayBvdGhlcndpc2U/IEkgZG8gbm90IHNlZSBoZXJlIHRoYXQgdGhlcmUgDQo+IGlzIGFu IGluZGljYXRpb24gdGhhdCBBdXRob3JpemF0aW9uIGFuZCBBdXRoZW50aWNhdGlvbiBuZWVkcyAN Cj4gdG8gYmUgY29tYmluZWQgYWdhaW4uDQo+IA0KPiA+IA0KPiA+IDIuOS4xDQo+ID4gICAgQXV0 aG9yaXphdGlvbiBzZXBhcmF0ZSBmcm9tIGF1dGhlbnRpY2F0aW9uIFNIT1VMRCBiZSBhbGxvd2Vk DQo+ID4gICAgd2hlbiBuZWNlc3NhcnksIGJ1dCB0aGUgQUFBIHByb3RvY29scyBNVVNUIGFsc28g YWxsb3cgDQo+IGZvciBhIHNpbmdsZQ0KPiA+ICAgIG1lc3NhZ2UgdG8gcmVxdWVzdCBib3RoIGF1 dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uLg0KPiA+IA0KPiA+ICAgIEFBQSBwcm90b2Nv bHMgaGF2ZSB0byBhbGxvdyBhIHNwbGl0IGJldHdlZW4gYXV0aGVudGljYXRpb24gYW5kDQo+ID4g ICAgYXV0aG9yaXphdGlvbiBzbyB0aGF0IGRpZmZlcmVudCBtZWNoYW5pc21zIGFyZSB1c2VkIGZv ciANCj4gZWFjaC4gVGhpcw0KPiA+ICAgIHN0YXRlcyB0aGF0IHNvbWV0aW1lcyBib3RoIHR5cGVz IG9mIGluZm9ybWF0aW9uIG5lZWQgdG8gDQo+IGJlIGNhcnJpZWQgDQo+ID4gaW4NCj4gPiAgICB0 aGUgc2FtZSBtZXNzYWdlLg0KPiANCj4gW0FobWFkXQ0KPiBJIGFtIG5vdCBzdXJlIEkgY2FuIHJl YWQgdGhpcyByZXF1aXJlbWVudCBhcyBhIHJlcXVpcmVtZW50IA0KPiB0aGF0IHdoZW4gQXV0aGVu dGljYXRpb24gYW5kIEF1dGhvcml6YXRpb24gYXJlIHNlcGFyYXRlZCwgDQo+IEF1dGhvcml6YXRp b24gbWVzc2FnZXMgTVVTVCBwcm92aWRlIGF1dGhlbnRpY2F0aW9uIHRvby4gDQo+IEJlY2F1c2Ug aWYgdGhhdCB3YXMgdGhlIGludGVudGlvbiwgdGhlbiB0aGlzIHJlcXVpcmVtZW50IGRvZXMgDQo+ IG5vdCBtYWtlIGFueSBzZW5zZS4gVGhlIHNlY29uZCBwb3J0aW9uIG9mIGl0IG5lZ2F0ZSB3aGF0 IHRoZSANCj4gZmlyc3QgcG9ydGlvbiBhbHJlYWR5IGFsbG93ZWQgdG8gaGFwcGVuLg0KPiBNeSBp bnRlcnByZXRhdGlvbiBpcyB0aGUgQXV0aGVudGljYXRpb24gYW5kIEF1dGhvcml6YXRpb24gaXMg DQo+IGZpbmUgYW5kIGFsbG93ZWQsIGhvd2V2ZXIsIEFBQSBwcm90b2NvbHMgc2hvdWxkIGdpdmUg dGhlIA0KPiBvcHRpb24gZm9yIGludGVncmF0ZWQgc29sdXRpb24sIGkuZS4gQXV0aGVudGljYXRp b24gYW5kIA0KPiBBdXRob3JpemF0aW9uIGluIHRoZSBzYW1lIG1lc3NhZ2UgYW5kIGF0IHRoZSBz YW1lIHRpbWUuDQo+IA0KPiANCj4gSW4gZ2VuZXJhbCwgYXMgbG9uZyBhcyBSRkMyNjA5IEFMTE9X RUQgdGhlIHNlcGFyYXRpb24gYmV0d2VlbiANCj4gQXV0aGVudGljYXRpb24gYW5kIEF1dGhvcml6 YXRpb24sIGl0IGRvZXMgbm90IG1ha2Ugc2Vuc2UgdG8gDQo+IG1hbmRhdGUgaW50ZWdyYXRpb24g aW4gY2FzZSBzZXBhcmF0aW9uIG9wdGlvbiBpcyBhZG9wdGVkLiBBbSANCj4gSSBtYWtpbmcgc29t ZSBzZW5zZSBoZXJlLg0KPiANCj4gPiANCj4gPiBCdXQgeW91IGNhbiBmaW5kIHNldmVyYWwgb3Ro ZXIgcGxhY2VzIGluIHRoZSBkb2N1bWVudCB3aGVyZSANCj4gPiBhdXRoZW50aWNhdGlvbiAmIGF1 dGhvcml6YXRpb24gYXJlIGJvdW5kLg0KPiA+IA0KPiA+IEJSLA0KPiA+IA0KPiA+IExpb25lbA0K PiA+IA0KPiA+ID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4gPiBEZSA6IEFobWFk IE11aGFubmEgW21haWx0bzphbXVoYW5uYUBub3J0ZWwuY29tXSBFbnZvecOpIDogamV1ZGkgMjUg DQo+ID4gPiBqYW52aWVyIDIwMDcgMTU6NDIgw4AgOiBNT1JBTkQgTGlvbmVsIFJELUNPUkUtSVNT OyBZb3NoaWhpcm8NCj4gPiBPaGJhIENjIDogDQo+ID4gPiBKdWxpZW4gTGFnYW5pZXI7IGRpbWVA aWV0Zi5vcmcgT2JqZXQgOiBSRTogW0RpbWVdIERpYW1ldGVyDQo+ID4gTW9iaWxlIElQdjYNCj4g PiA+IEhBLXRvLUFBQUggU3VwcG9ydDoNCj4gPiA+IElzc3VlIG9yIG5vdElzc3VlID8NCj4gPiA+ IA0KPiA+ID4gSGkgTGlvbmVsLA0KPiA+ID4gUGxlYXNlIHNlZSBzb21lIG9uZSBjb21tZW50IGlu bGluZS4NCj4gPiA+IA0KPiA+ID4gUmVnYXJkcywNCj4gPiA+IEFobWFkDQo+ID4gPiAgDQo+ID4g PiANCj4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gRnJvbTogTU9S QU5EIExpb25lbCBSRC1DT1JFLUlTUw0KPiA+ID4gPiBbbWFpbHRvOmxpb25lbC5tb3JhbmRAb3Jh bmdlLWZ0Z3JvdXAuY29tXQ0KPiA+ID4gPiBTZW50OiBUaHVyc2RheSwgSmFudWFyeSAyNSwgMjAw NyA1OjExIEFNDQo+ID4gPiA+IFRvOiBZb3NoaWhpcm8gT2hiYQ0KPiA+ID4gPiBDYzogSnVsaWVu IExhZ2FuaWVyOyBNdWhhbm5hLCBBaG1hZCAoUklDSDE6MkgxMCk7IGRpbWVAaWV0Zi5vcmcNCj4g PiA+ID4gU3ViamVjdDogUkU6IFtEaW1lXSBEaWFtZXRlciBNb2JpbGUgSVB2NiBIQS10by1BQUFI IFN1cHBvcnQ6IA0KPiA+ID4gPiBJc3N1ZSBvciBub3RJc3N1ZSA/DQo+ID4gPiA+IA0KPiA+ID4g PiBIaSBZb3NoaSwNCj4gPiA+ID4gDQo+ID4gPiA+IDEpIElmIGF1dGhlbnRpY2F0aW9uIHByb2Nl ZHVyZXMgbWF5IGJlIHBlcmZvcm1lZCBhcGFydCBmcm9tIA0KPiA+ID4gPiBhdXRob3JpemF0aW9u IHByb2NlZHVyZXMgKEkgdG90YWxseSBhZ3JlZSksIGF1dGhvcml6YXRpb24NCj4gPiA+IHByb2Nl ZHVyZXMNCj4gPiA+ID4gbXVzdCBiZSBhYmxlIHRvIHJlbHkgb24gaXRzIG93biBhdXRoZW50aWNh dGlvbiBwcm9jZWR1cmVzDQo+ID4gaWYgbmVlZGVkDQo+ID4gPiA+IChjZi4gQUFBIHJlcXVpcmVt ZW50cyBpbiBSRkMgMjkwNikuIEFyZSB5b3UgT0sgd2l0aCB0aGF0Pw0KPiA+ID4gDQo+ID4gPiBb QWhtYWRdDQo+ID4gPiBKdXN0IGZvciBteSBlZHVjYXRpb24sIGNvdWxkIHlvdSBwbGVhc2UgZ2l2 ZSBtZSBhIHBvaW50ZXIgDQo+IHRvIHdoaWNoIA0KPiA+ID4gcmVxdWlyZW1lbnQgeW91IGFyZSBy ZWZlcnJpbmcgaW4gUkZDMjkwNi4NCj4gPiA+IFRoYW5rcy4NCj4gPiA+IA0KPiA+ID4gPiANCj4g PiA+ID4gMikgQXMgaXQgaXMgbm93LCBwcm92aWRpbmcgYXV0aGVudGljYXRpb24gd2l0aCBEaWFt ZXRlciBFQVAgDQo+ID4gPiA+IGFwcGxpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIHdpdGggRGlh bWV0ZXIgTUlQNiBkb2VzIG5vdA0KPiA+IGFsbG93IHRoZQ0KPiA+ID4gPiBBQUEtTUlQNiB0byBi ZSBzdXJlIHRoYXQgdGhlIHVzZXJuYW1lIGNhcnJpZWQgaW4gdGhlDQo+ID4gYXV0aG9yaXphdGlv bg0KPiA+ID4gPiByZXF1ZXN0IHdhcyBwcmV2aW91c2x5IGF1dGhlbnRpY2F0ZWQgYnkgdGhlIEFB QS1FQVAuIEFyZQ0KPiA+ID4geW91IE9LIHdpdGgNCj4gPiA+ID4gdGhhdD8NCj4gPiA+ID4gDQo+ ID4gPiA+IDMpIElmIHRoZSBBQUEtTUlQNiBwcm92aWRlcyB0aGUgSEEgd2l0aCBzZXJ2aWNlIHJl bGF0ZWQNCj4gPiBpbmZvcm1hdGlvbg0KPiA+ID4gPiB3aXRob3V0IGJlaW5nIHN1cmUgdGhhdCB0 aGUga2V5IGVudHJ5ICh1c2VybmFtZSkgd2FzIHByZXZpb3VzbHkgDQo+ID4gPiA+IGF1dGhlbnRp Y2F0ZWQsIHdoYXQgaXMgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgDQo+IEFBQS1NSVA2IGFu ZCBhIA0KPiA+ID4gPiAic2ltcGxlIiBleHRlcm5hbCBkYXRhYmFzZSBwcm92aWRpbmcgaW5mb3Jt YXRpb24gZGF0YSB0byBhbnkgDQo+ID4gPiA+IGF1dGhvcml6ZWQgZW50aXR5IChIQSBpbiB0aGUg cHJlc2VudCBjYXNlKT8gV2hhdC93aGVyZSBpcyB0aGUgDQo+ID4gPiA+IGF1dGhvcml6YXRpb24g cHJvY2VzcyBpbiB0aGF0IGNhc2U/DQo+ID4gPiA+IA0KPiA+ID4gPiA0KSBJZiBjb21iaW5pbmcg RGlhbWV0ZXIgRUFQIGFuZCBEaWFtZXRlciBNSVA2IGlzIG1vcmUNCj4gPiBjb21wbGV4IHRoYW4N Cj4gPiA+ID4gaW5jbHVkaW5nIGF1dGhlbnRpY2F0aW9uIHByb2NlZHVyZXMgd2l0aCBEaWFtZXRl ciBNSVA2IHRoYXQgaXMgDQo+ID4gPiA+IGNvaGVyZW50IHdpdGggQUFBIHJlcXVpcmVtZW50cywg d2h5IGFyZSB3ZSBzdGlsbCBkaXNjdXNzaW5nDQo+ID4gPiBhcyBtdWNoPyANCj4gPiA+ID4gOykN Cj4gPiA+ID4gDQo+ID4gPiA+IDUpIElmIHRoZSBkaXNjdXNzaW9uIGlzIGJleW9uZCB0aGUgc2Nv cGUgb2YgdGhlIGRyYWZ0IGFuZA0KPiA+ID4gcmVsYXRlZCB0bw0KPiA+ID4gPiB0aGUgZnV0dXJl IG9mIGdsb2JhbCBBQUEgZnJhbWV3b3JrLCB3aHkgZG8gbm90ICJkZWNvdXBsZSIgdGhlIA0KPiA+ ID4gPiBkaXNjdXNzaW9ucyBhbmQgY3JlYXRlIGEgc2VwYXJhdGUgdGhyZWFkPyBCdXQgZm9yIG5v dywgSQ0KPiA+ID4gY2FuIHNlZSB0aGF0DQo+ID4gPiA+IGEgRGlhbWV0ZXIgTUlQNiBhcHBsaWNh dGlvbiB3aXRoIGF1dGhlbnRpY2F0aW9uIHByb2NlZHVyZQ0KPiA+IHdvdWxkIGJlDQo+ID4gPiA+ IGNvbnNpc3RlbnQgd2l0aCB0aGUgY3VycmVudCBBQUEgZnJhbWV3b3JrIHdoaWxlIGEgDQo+IGNv bWJpbmFpc29uIG9mIA0KPiA+ID4gPiBEaWFtZXRlciBFQVAgYW5kIERpYW1ldGVyIE1JUDYgd2ls bCBub3QgbWVldCBhbGwgdGhlIEFBQQ0KPiA+ID4gcmVxdWlyZW1lbnRzDQo+ID4gPiA+IHdpdGhv dXQgaW50cm9kdWNpbmcgc3BlY2lmaWMgZnVuY3Rpb25hbGl0ZXMvZW5oYW5jZW1lbnRzLg0KPiA+ ID4gPiANCj4gPiA+ID4gSSB3b3VsZCBoYXZlIG5vIHByb2JsZW0gd2l0aCBhIHNvbHV0aW9uIHBy b3Bvc2luZyBFQVANCj4gPiA+IGF1dGhlbnRpY2F0aW9uDQo+ID4gPiA+IHByb2NlZHVyZXMgYW5k IE1JUDYgYXV0aG9yaXphdGlvbiBwcm9jZWR1cmVzIHN1cHBvcnRlZCBieQ0KPiA+ID4gdG8gZGlm ZmVyZW50DQo+ID4gPiA+IGRpYW1ldGVyIGFwcGxpY2F0aW9ucyBJRiBpdCBjb3VsZCBiZSBwb3Nz aWJsZSB0byBiaW5kIGJvdGgNCj4gPiA+IHByb2NlZHVyZXMNCj4gPiA+ID4gaW4gdGhlIHNhbWUg ZXF1aXBtZW50IGluIHRoZSBNU0EuIFRoYXQgaXMgbm90IHRoZSBjYXNlIHdpdGggdGhlIA0KPiA+ ID4gPiBjdXJyZW50IHNvbHV0aW9uLg0KPiA+ID4gPiANCj4gPiA+ID4gQlIsDQo+ID4gPiA+IA0K PiA+ID4gPiBMaW9uZWwNCj4gPiA+ID4gDQo+ID4gPiA+ID4gPiBUaGVyZSBpcyBhIG5ldyBndXkg aW4gdGhlIGdhbWUgOykNCj4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gQWZ0ZXIgcmV2aWV3aW5n IHRoZSBkcmFmdCBhbmQgdGhlIG1haWwgZXhjaGFuZ2Ugb24gdGhlDQo+ID4gPiA+ID4gdG9waWMs IEkgd291bGQgc2F5IHRoYXQgdGhlIGNvbmNsdXNpb24gb24gImlzc3VlL25vIGlzc3VlIiANCj4g PiA+ID4gPiBkZXBlbmRzIG9uIHRoZSBzaWRlIHlvdSBhcmUgY29uc2lkZXJpbmcgdGhlIHByb2Js ZW0gKGFzDQo+ID4gb2Z0ZW4gOykuDQo+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+IElmIHlvdSBh cmUgY29uc2lkZXJpbmcgdGhlIEFBQS1NSVA2IGFzIGEgInNpbXBsZSIgZGF0YWJhc2UNCj4gPiA+ ID4gPiBwcm92aWRpbmcgdGhlIEhBIHdpdGggc3BlY2lmaWMgdXNlci9zZXJ2aWNlIA0KPiBpbmZv cm1hdGlvbiBhZnRlciBhIA0KPiA+ID4gPiA+IHNlcGFyYXRlIGF1dGhlbnRpY2F0aW9uIChwZXJm b3JtZWQgd2l0aCBEaWFtZXRlcg0KPiA+ID4gPiBhdXRoZW50aWNhdGlvbiksIHRoZQ0KPiA+ID4g PiA+IHVzZXJuYW1lIGNvbnZleWVkIG92ZXIgdGhlIEhBL0FBQS1NSVA2IGlzIGp1c3QgdXNlZCBh cyBhDQo+ID4gPiA+IGtleSBlbnRyeSBpbg0KPiA+ID4gPiA+IHRoZSBkYXRhYmFzZS4gVGhlcmUg aXMgbm8gbmVlZCBmb3IgdGhlIEFBQS1NSVA2IHRvDQo+ID4gPiA+IGF1dGhlbnRpY2F0ZSB0aGlz DQo+ID4gPiA+ID4gdXNlcm5hbWUgb3IgdG8gYmUgc3VyZSB0aGF0IHRoZSB1c2VybmFtZSB3YXMg cHJldmlvdXNseQ0KPiA+ID4gPiBhdXRoZW50aWNhdGVkLiANCj4gPiA+ID4gPiBUaGUgY2xpZW50 IG9mIHRoZSBkYXRhYmFzZSBpcyB0aGUgSEEgYW5kIG5vdCB0aGUgdXNlci4gSW4NCj4gPiA+ID4g dGhhdCBjYXNlLA0KPiA+ID4gPiA+IHRoZQ0KPiA+ID4gPiA+IEFBQS1NSVA2IGhhcyB0byB0cnVz dCB0aGUgSEEgYW5kIGl0IGlzIHVwIHRvIHRoZSBIQSB0bw0KPiA+ID4gYXV0aGVudGljYXRlDQo+ ID4gPiA+ID4gdGhlIHVzZXJuYW1lIHByb3ZpZGVkIGJ5IHRoZSBtbiBkdXJpbmcgdGhlIFNBIHNl dC11cC4gDQo+ID4gPiBUaGlzIGNvdWxkIGJlDQo+ID4gPiA+ID4gY29tcGFyZWQgdG8gaW50ZXJm YWNlcyBiZXR3ZWVuIEhTUyAoSG9tZSBTdWJzY3JpYmVyDQo+ID4gPiBTZXJ2ZXIpIGFuZCBTSVAN Cj4gPiA+ID4gPiBhcHBsaWNhdGlvbiBzZXJ2ZXJzIGRlZmluZWQgaW4gdGhlIDNHUFAgYXJjaGl0 ZWN0dXJlLA0KPiA+IG92ZXIgd2hpY2gNCj4gPiA+ID4gPiBEaWFtZXRlciBhcHBsaWNhdGlvbnMg YXJlIHVzZWQgdG8gYWNjZXNzIGRhdGFiYXNlLg0KPiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiBJ biB0aGlzIGNvbnRleHQsIHRoZSBIQSBtYXkgdXNlOg0KPiA+ID4gPiA+ID4gMSkgdGhlIERpYW1l dGVyIEVBUCBhcHBsaWNhdGlvbiB0byBhdXRoZW50aWNhdGUgdGhlIHVzZXIuICANCj4gPiA+ID4g PiA+IDIpIHRoZSBEaWFtZXRlciBNSVA2IGFwcGxpY2F0aW9uIHRvIGRvd25sb2FkIHVzZXINCj4g PiA+IHJlbGF0ZWQgc2VydmljZQ0KPiA+ID4gPiA+ID4gaW5mb3JtYXRpb24gQXV0aGVudGljYXRp b24gYW5kIGF1dGhvcml6YXRpb24gYXJlIHBlcmZvcm1lZA0KPiA+ID4gPiA+IGJ5IHRoZSBBQUEt RUFQLiBCdXQgdGhlcmUgaXMgbm8gd2F5IGZvciB0aGUgQUFBLUVBUCB0bw0KPiA+ID4ga25vdyB3 aGF0IGlzDQo+ID4gPiA+ID4gdGhlIHNlcnZpY2UgcmVxdWVzdGVkIGJ5IHRoZSB1c2VyLiBTdWNj ZXNzZnVsDQo+ID4gPiA+IGF1dGhlbnRpY2F0aW9uIGltcGxpZXMNCj4gPiA+ID4gPiBpbXBsaWN0 ZSBhdXRob3JpemF0aW9uLiBUaGlzIGlzIHRoZSBwcm9ibGVtIHdpdGggRGlhbWV0ZXINCj4gPiA+ ID4gRUFQIGFzIGl0IGlzDQo+ID4gPiA+ID4gbm90IHBvc3NpYmxlIHRvIHJvdXRlIERpYW1ldGVy IEVBUCByZXF1ZXN0IHRvIGENCj4gPiA+ID4gc2VydmljZS1zcGVjaWZpYyBFQVANCj4gPiA+ID4g PiBzZXJ2ZXIuDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gSWYgQUFBLU1JUDYgcHJvdmlkZXMgYXV0 aG9yaXphdGluLCBBQUEtRUFQIHByb3ZpZGVzDQo+ID4gPiBhdXRoZW50aWNhdGlvbiwNCj4gPiA+ ID4gPiBidXQgZG9lcyBub3QgcHJvdmlkZSBhdXRob3JpemF0aW9uLiAgRm9yIHRoaXMgcHVycG9z ZSwgdGhlDQo+ID4gPiA+IEhBIG5lZWRzIHRvDQo+ID4gPiA+ID4gc2V0IEF1dGgtUmVxdWVzdC1U eXBlIHNldCB0byBBVVRIRU5USUNBVEVfT05MWSBpbg0KPiA+ID4gQUFBLUVBUC4gIEluIHRoaXMN Cj4gPiA+ID4gPiBjYXNlLCBBQUEtRUFQIHNlcnZlciBkb2VzIG5vdCBuZWVkIHRvIGtub3cgd2hh dCBraW5kIG9mDQo+ID4gPiA+IGF1dGhvcml6YXRpb24NCj4gPiA+ID4gPiB3aWxsIGJlIG1hZGUu ICBUaGUgYXV0aG9yaXphdGlvbiBkZWNpc2lvbiB3aWxsIGJlIG1hZGUgYnkNCj4gPiA+IEFBQS1N SVA2Lg0KPiA+ID4gPiA+IEFtIEkgbWlzc2luZyBzb21ldGhpbmc/DQo+ID4gPiA+ID4gDQo+ID4g PiA+ID4gPiANCj4gPiA+ID4gPiA+IEluIGFub3RoZXIgaGFuZCwgaWYgdGhlIEFBQS1NSVA2IGlz IGFuIGF1dGhvcml0eSBoYW5kbGluZw0KPiA+ID4gPiA+IE1JUDYgc2VydmljZSBhY2Nlc3MgYXV0 aG9yaXphdGlvbiByaWdodHMgaS5lLiB0aGUgQUFBLU1JUDYNCj4gPiA+ID4gbXVzdCB2ZXJpZnkN Cj4gPiA+ID4gPiB0aGF0IHRoZSB1c2VyIGlzIGF1dGhvcml6ZWQgdG8gdXNlIHRoZSBNb2JpbGUN Cj4gPiA+ID4gPiBJUHY2IHNlcnZpY2UsIHRoaXMgYXV0aG9yaXR5IGhhcyB0byBiZSBhYmxlIHRv IHZlcmlmeSB0aGUNCj4gPiA+ID4gaWRlbnRpdHkgb2YNCj4gPiA+ID4gPiB0aGUgdXNlciBiZWZv cmUgYXV0aG9yaXppbmcgdGhpcyB1c2VyIHRvIGFjY2VzcyB0aGUNCj4gPiA+ID4gc2VydmljZS4g SXQgaXMgbm90DQo+ID4gPiA+ID4gcG9zc2libGUgdG8gYXV0aG9yaXplIHNvbWVvbmUgdG8gZG8g c29tZXRoaW5nIHdpdGhvdXQNCj4gPiA+IGJlaW5nIHN1cmUgb2YNCj4gPiA+ID4gPiBpdHMgaWRl bnRpdHkgYXMgdGhlIGF1dGhvcml0eSBtdXN0IHN0YW5kIHN1cmV0eSBvZiB0aGUNCj4gPiA+IHVz ZXIgYWNjZXNzDQo+ID4gPiA+ID4gcmlnaHRzLiBOb3csIGl0IGlzIG5vdCBwb3NzaWJsZSB0byBy ZWx5IG9uIHRoZSBEaWFtZXRlciBFQVAgDQo+ID4gPiA+ID4gYXBwbGljYXRpb24gdG8gcGVyZm9y bSB0aGUgYXV0aGVudGljYXRpb24gcHJvY2VkdXJlIGFzDQo+ID4gPiA+IHRoZXJlIGlzIG5vIHdh eQ0KPiA+ID4gPiA+IHRvIGRpcmVjdCB0aGUgRGlhbWV0ZXIgRUFQIHJlcXVlc3RzIHRvIGEgc3Bl Y2lmYyBFQVANCj4gPiA+IHNlcnZlciAoYXMgdGhlDQo+ID4gPiA+ID4gRGlhbWV0ZXIgcm91dGlu ZyBpcyBiYXNlZCBvbiBBcHAtSWQgYW5kIFJlYWxtKS4gV2UgbWlnaHQNCj4gPiA+ID4gdGhpbmsg YWJvdXQNCj4gPiA+ID4gPiBzb21lIHNwZWNpZmljIHRoaW5ncyB0byBsaW5rIGF1dGhlbnRpY2F0 aW9uIHByb2NlZHVyZXMgYW5kIA0KPiA+ID4gPiA+IGF1dGhvcml6YXRpb24vc2VydmljZSBwcm9m aWxlIGhhbmRsaW5nLiBCdXQgZm9yIG1lLCB0aGUNCj4gPiA+ID4gc2ltcGxpZXN0IHdheQ0KPiA+ ID4gPiA+IHdvdWxkIGJlIHRvIGRlZmluZSB0aGUgcmVxdWlyZWQgYXV0aGVudGljYXRpb24gbWVj aGFuaXNtDQo+ID4gPiB3aXRoaW4gb25lDQo+ID4gPiA+ID4gYW5kIG9ubHkgb25lIGFwcGxpY2F0 aW9uIGkuZS4gdGhlIGFwcGxpY2F0aW9uIHRoYXQNCj4gPiByZXF1aXJlcyB0aGlzDQo+ID4gPiA+ ID4gYXV0aGVudGljYXRpb24uDQo+ID4gPiA+ID4gVGhlcmVmb3JlLCBEaWFtZXRlciBFQVAgd291 bGQgbm90IGJlIHVzZWQgYW5kDQo+ID4gPiBhcHBsaWNhdGlvbi1zcGVjaWZpYw0KPiA+ID4gPiA+ IGNvbW1hbmRzIHdvdWxkIGJlIHNwZWNpZmllZCBpbiB0aGUgYXBwbGljYXRpb24uIE9uZSBjb21t YW5kDQo+ID4gPiA+IHBhaXIgd291bGQNCj4gPiA+ID4gPiBiZSBhZGRlZCB0byB0aGUgRGlhbWV0 ZXINCj4gPiA+ID4gPiBNSVA2IGFwcGxpY2F0aW9uLiBBbmQgdG8gc3VwcG9ydCBFQVAsIEFWUHMg ZGVmaW5lZCBpbiA0MDcyDQo+ID4gPiA+IHdvdWxkIGJlIGF0DQo+ID4gPiA+ID4gbGVhc3QgKHJl LSl1c2VkLg0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IEkgZG9uJ3QgdW5kZXJzdGFuZCB0aGUgZGlm ZmVyZW5jZSBiZXR3ZWVuIHRoZSB0d28gY2FzZXMgeW91DQo+ID4gPiA+IG1lbnRpb25lZA0KPiA+ ID4gPiA+IGFib3ZlLiAgSSBiZWxpZXZlIHRoYXQgbW9yZSBvciBsZXNzIHRoZSBBQUEgc2VydmVy cyBuZWVkIHRvDQo+ID4gPiA+IHRydXN0IHRoZQ0KPiA+ID4gPiA+IEhBIGluIGJvdGggY2FzZXMu ICBEZXBlbmRpbmcgb24gdGhyZWF0IG1vZGVsIHdoaWNoIHdlDQo+ID4gPiBkb24ndCBzZWVtIHRv DQo+ID4gPiA+ID4gZXhhY3RseSBrbm93IHJpZ2h0IG5vdywgdGhlDQo+ID4gPiA+ID4gQUFBLU1J UDYgc2VydmVyIG1heSBvciBtYXkgbm90IG5lZWQgYW4gZXZpZGVuY2UgdGhhdCB0aGUNCj4gPiA+ ID4gdXNlciBoYXMgYmVlbg0KPiA+ID4gPiA+IGF1dGhlbnRpY2F0ZWQgYnkgYSBBQUEtRUFQIHNl cnZlci4NCj4gPiA+ID4gPiANCj4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gSU1ITywgdGhlIGNv bnRleHQgZGVzY3JpYmVkIGluIHRoZSBkcmFmdCBsb29rcyBsaWtlIG1vcmUgYQ0KPiA+ID4gPiA+ IHNlcnZpY2UgYWNjZXNzIGF1dGhvcml6YXRpb24gbWFuYWdlbWVudCB0aGFuIHRoZSB1c2Ugb2YN Cj4gPiBhIHNpbXBsZQ0KPiA+ID4gPiA+IGV4dGVybmFsIGRhdGFiYXNlLiBJIHdvdWxkIGJlIHRo ZXJlZm9yZSBpbiBmYXZvciBvZiBkZWZpbmluZyANCj4gPiA+ID4gPiBhdXRoZW50aWNhdGlvbiBj b21tYW5kcyB3aXRoaW4gdGhlIERpYW1ldGVyIE1JUDYNCj4gPiA+ID4gYXBwbGljYXRpb24gaW5z dGVhZA0KPiA+ID4gPiA+IG9mIHRyeWluZyB0byByZXVzZSB0aGUgRGlhbWV0ZXIgRUFQIGFwcGxp Y2F0aW9uLCB3aGljaCBpcw0KPiA+ID4gPiBub3QgcG9zc2libGUNCj4gPiA+ID4gPiB3aXRob3V0 IG1vZGlmaWNhdGlvbnMuIEVBUCBhdXRoZW50aWNhdGlvbiBhbmQgTUlQNg0KPiA+IHNlcnZpY2Ug YWNjZXNzDQo+ID4gPiA+ID4gYXV0aG9yaXphdGlvbiBhcmUgcGVyZm9ybWVkIHdpdGggdGhlIHNh bWUgDQo+IGFwcGxpY2F0aW9uLiBTaW5jZSBhIA0KPiA+ID4gPiA+IGFwcGxpY2F0aW9uLUlkIGlz IHdoYXRldmVyIG5lZWRlZCBmb3IgdGhlIEhBL0FBQS1NSVA2LCB3aGF0DQo+ID4gPiA+IHdvdWxk IGJlDQo+ID4gPiA+ID4gdGhlIGJlbmVmaXQgdG8gbG9vayBmb3Igc29sdXRpb25zIGJpbmRpbmcg RGlhbWV0ZXIgRUFQDQo+ID4gPiBhbmQgRGlhbWV0ZXINCj4gPiA+ID4gPiBNSVA2ICh3aXRoIHNv bWUga2V5IGRlcml2YXRpb24sIGV0Yy4pIHdoaWxlIGEgc2luZ2xlDQo+ID4gPiBEaWFtZXRlciBN SVA2DQo+ID4gPiA+ID4gYXBwbGljYXRpb24gd2l0aCBpbnRyaW5zaWMgYXV0aGVudGljYXRpb24g Y29tbWFuZHMNCj4gPiB3b3VsZCBiZSBmdWxseQ0KPiA+ID4gPiA+IGFwcHJvcHJpYXRlPw0KPiA+ ID4gPiA+IA0KPiA+ID4gPiA+IEkgZG9uJ3QgdW5kZXJzdGFuZCB3aGF0IGlzIHRoZSBwb2ludCBv ZiBkaXNjdXNzaW5nDQo+ID4gPiAic2VydmljZSBhY2Nlc3MNCj4gPiA+ID4gPiBhdXRob3JpemF0 aW9uIG1hbmFnZW1lbnQiIGFuZCAic2ltcGxlIGV4dGVybmFsIGRhdGFiYXNlIi4gDQo+ID4gPiAg SWYgTUlQNg0KPiA+ID4gPiA+IGFwcGxpY2F0aW9uIG5lZWRzIHRvIHN1cHBvcnQgbXVsdGlwbGUg YXV0aGVudGljYXRpb24NCj4gPiA+ID4gbWV0aG9kcyBzdWNoIGFzDQo+ID4gPiA+ID4gRUFQIGFu ZCBSRkMgNDI4NSwgSSBiZWxpZXZlIGl0IGlzIG1vcmUgYXBwcm9wcmlhdGUgdG8gDQo+IGNvbnNp ZGVyIA0KPiA+ID4gPiA+IHNlcGFyYXRpb24gb2YgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6 YXRpb24gaWYgc2VjdXJpdHkgaXMgDQo+ID4gPiA+ID4gcmVhc29uYWJseSBoYW5kbGVkLiAgQWxz bywgdGhlcmUgaXMgc29tZSBhdXRoZW50aWNhdGlvbg0KPiA+ID4gPiBtZXRob2QgKGUuZy4sDQo+ ID4gPiA+ID4gYXV0aGVudGljYXRpb24gYmFzZWQgb24gSUtFdjItY2VydCB3aXRob3V0IHVzaW5n IEVBUCkgZG9lcw0KPiA+ID4gPiBub3QgcmVxdWlyZQ0KPiA+ID4gPiA+IGFueSBBQUEgaW50ZXJh Y2F0aW9uIGZvciBhdXRoZW50aWNhdGlvbi4gIEkgd2FzDQo+ID4gcG9pbnRpbmcgdGhpcyBvdXQN Cj4gPiA+ID4gPiBzZXZlcmFsIHRpbWVzIGJ1dCBubyBvbmUgc2VlbXMgdG8gcGF5IGF0dGVudGlv biB0byBpdC4NCj4gPiA+ID4gPiANCj4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gSSdtIHByZXR0 eSBzdXJlIHRoYXQgdGhlIGNvbnRlbnQgb2YgdGhpcyBtYWlsIG1heSBiZQ0KPiA+ID4gPiA+IGNo YWxsZW5nZWQgbGluZSBieSBsaW5lIDspIEJ1dCBhdCB0aGUgZW5kLCBpZg0KPiA+IGF1dGhlbnRp Y2F0aW9uIGFuZA0KPiA+ID4gPiA+IGF1dGhvcml6YXRpb24gYXJlIG5lZWRlZCB0byBwcm92aWRl IE1JUDYgc2VydmljZXMsIHdoeSBkbw0KPiA+ID4gPiBub3QgaGF2aW5nIGENCj4gPiA+ID4gPiBz aW5nbGUgYXBwbGljYXRpb24gdG8gZG8gaXQ/IE9mIGNvdXJzZSwgSSBkb24ndCBzYXkgdGhhdCBp dA0KPiA+ID4gPiB3b3VsZCBub3QNCj4gPiA+ID4gPiBiZSBwb3NzaWJsZSB0byBkbyBzb21ldGhp bmcgbW9yZSBjb21wbGV4Li4uDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gVG8gbWUsIGRpc2N1c3Np b24gb24gY291cGxpbmcgdnMuIGRlY291cGxpbmcgDQo+IGF1dGhlbnRpY2F0aW9uIGFuZCANCj4g PiA+ID4gPiBhdXRob3JpemF0aW9uIGlzIG5vdCBqdXN0IGEgTUlQNiBpc3N1ZS4gIFRoaXMgaXMg YSANCj4gZnVuZGFtZW50YWwgDQo+ID4gPiA+ID4gZGlzY3Vzc2lvbiB0aGF0IHdpbGwgZGVjaWRl IHRoZSBmdXR1cmUgZGlyZWN0aW9uIG9mIEFBQS4NCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBZb3No aWhpcm8gT2hiYQ0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiBCUiwNCj4g PiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gTGlvbmVsDQo+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+ IA0KPiA+ID4gPiA+ID4gPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPiA+ID4gPiA+ ID4gRGUgOiBKdWxpZW4gTGFnYW5pZXIgW21haWx0bzpqdWxpZW4uSUVURkBsYXBvc3RlLm5ldF0N Cj4gPiA+ID4gPiA+ID4gRW52b3nvvJ8gOiBtYXJkaSAyMyBqYW52aWVyIDIwMDcgMTA6NDINCj4g PiA+ID4gPiA+ID4g77yfIDogQWhtYWQgTXVoYW5uYQ0KPiA+ID4gPiA+ID4gPiBDYyA6IGRpbWVA aWV0Zi5vcmcNCj4gPiA+ID4gPiA+ID4gT2JqZXQgOiBSZTogW0RpbWVdIERpYW1ldGVyIE1vYmls ZSBJUHY2IA0KPiBIQS10by1BQUFIIFN1cHBvcnQ6IA0KPiA+ID4gPiA+ID4gPiBJc3N1ZSBvciBu b3RJc3N1ZSA/DQo+ID4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gPiBIaSBBaG1hZCwNCj4gPiA+ ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiA+IEN1dHRpbmcgYSBiaXQgdGhydSB5b3VyIG1lc3NhZ2Us IEkgaGF2ZSBzb21lIGNvbW1lbnRzDQo+ID4gPiA+ID4gPiA+IGJlbG93Og0KPiA+ID4gPiA+ID4g PiANCj4gPiA+ID4gPiA+ID4gT24gTW9uZGF5IDIyIEphbnVhcnkgMjAwNyAxODoxMCwgQWhtYWQg TXVoYW5uYSB3cm90ZToNCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ ID4gPiA+ID5bLi4uXQ0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gW0FobWFkXQ0K PiA+ID4gPiA+ID4gPiA+IFdlIGFyZSBwcm9iYWJseSBzcGxpdHRpbmcgaGFpciBoZXJlLCBhcHBh cmVudGx5DQo+ID4gPiB0aGVyZSBhcmUgdHdvDQo+ID4gPiA+ID4gPiA+ID4gYXJndW1lbnRzIGhl cmU6DQo+ID4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gPiBJIGRvbid0IHRoaW5rIHRoaXMgaXMg aGFpciBzcGxpdHRpbmcuIFVuZGVyc3RhbmQgdGhlDQo+ID4gPiA+ID4gaXNzdWUgc2hvdWxkIGJl DQo+ID4gPiA+ID4gPiA+IGEgcHJlcmVxdWlzaXRlIHRvIHNvbHZpbmcgaXQuDQo+ID4gPiA+ID4g PiA+IA0KPiA+ID4gPiA+ID4gPiA+IDEuIEFBQXogaXMgYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIg YW5kIHNpbmNlIGl0IGhhcyBhDQo+ID4gPiA+IHNlY3VyaXR5DQo+ID4gPiA+ID4gPiA+ID4gcmVs YXRpb25zaGlwIHdpdGggdGhlIEhBLCBBQUF6IHJlbGllcyBvbiB0aGUgSEEgDQo+IHRvIGRvIHR3 bw0KPiA+ID4gPiA+ID4gPiB0aGluZ3M6IDEuMS4gDQo+ID4gPiA+ID4gPiA+ID4gSEEgbWFrZXMg c3VyZSB0aGF0IHRoZSB1c2VyIGhhcyBiZWVuIGF1dGhlbnRpY2F0ZWQgYnkNCj4gPiA+ID4gPiBB QUFuLiAxLjIuIA0KPiA+ID4gPiA+ID4gPiA+IEhBIHdpbGwgbm90IHNlbmQgYW55IEF1dGhvcml6 YXRpb24gcmVxdWVzdHMgZm9yDQo+ID4gYW55IHVzZXIocykNCj4gPiA+ID4gPiA+ID4gd2hvIGhh cyBub3QNCj4gPiA+ID4gPiA+ID4gPiBiZWVuIGF1dGhlbnRpY2F0ZWQuDQo+ID4gPiA+ID4gPiA+ ID4NCj4gPiA+ID4gPiA+ID4gPiAoSW4gbm9ybWFsIGNvbmRpdGlvbnMsIHRoZSBhYm92ZSB0d28g Y29uZGl0aW9ucyANCj4gYXJlIEFMV0FZUw0KPiA+ID4gPiA+ID4gPiBUUlVFIGV4Y2VwdA0KPiA+ ID4gPiA+ID4gPiA+IGluIG9uZSBjb25kaXRpb24sIEhBIGhhcyBiZWVuDQo+ID4gPiA+ID4gPiA+ ID4gY29tcHJvbWlzZWQpDQo+ID4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gPiBSaWdodC4gU28g d2UgYm90aCBhZ3JlZSB0aGVyZSdzIG5vIHByb2JsZW0gdW5sZXNzIA0KPiB0aGUgSEEgaXMgDQo+ ID4gPiA+ID4gPiA+IGNvbXByb21pc2VkDQo+ID4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gPiBJ IHRoaW5rIHdoYXQgdGhlIGZpcnN0IHN0ZXAgaXMgdG8gYWdyZWUgb24gYSB0aHJlYXQNCj4gPiA+ ID4gPiBtb2RlbC4gSSBkbyBub3QNCj4gPiA+ID4gPiA+ID4gYWdyZWUgdGhhdCB3ZSBzaG91bGQg ZGVmZW5kIGFnYWluc3QgYSBjb21wcm9taXNlZCBIQS4NCj4gPiA+ID4gPiA+ID4gVGhlIEhBIHNo b3VsZCBiZSBkZWVtZWQgc2VjdXJlIGFnYWluc3QgYXR0YWNrZXJzLg0KPiA+ID4gPiA+ID4gPiAN Cj4gPiA+ID4gPiA+ID4gV2UgaGF2ZSB0byBwbGFjZSBhIGxpbWl0IG9uIHdoYXQgaXMgZW50aXR5 IFggd2hlbg0KPiA+IGFza2luZyB0aGUNCj4gPiA+ID4gPiA+ID4gcXVlc3Rpb24gIndoYXQgaWYg ZW50aXR5IFggaXMgY29tcHJvbWlzZWQiLg0KPiA+ID4gPiA+ID4gPiBTaW5jZSBub3RoaW5nIGlz IHJlYWxseSBpbXBvc3NpYmxlIGluIHRoZSByZWFsIHdvcmxkLA0KPiA+ID4gd2UgY2Fubm90DQo+ ID4gPiA+ID4gPiA+IGRlZmVuZCBhZ2FpbnN0IGNvbXByb21pc3Npb24gb2YgYW55IGVudGl0eSBp bXBsaWNhdGVkIGluDQo+ID4gPiA+ID4gYSBwcm90b2NvbC4gDQo+ID4gPiA+ID4gPiA+IFNlY3Vy aXR5IGlzIGEgdHJhZGVvZmYuDQo+ID4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gPiBNb3JlIGJl bG93Li4uDQo+ID4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gPiA+IDIuIEFBQXogaXMgYW4gYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIGhhcyBhIHNlY3VyaXR5DQo+ID4gPiA+ID4gPiA+IGFzc29j aWF0aW9uIHdpdGgNCj4gPiA+ID4gPiA+ID4gPiB0aGUgSEEsIGhvd2V2ZXIsIGR1ZSB0byB0aGUg ZmFjdCB0aGF0IHRoZSBIQSBjb3VsZCBiZQ0KPiA+ID4gPiA+ID4gPiBjb21wcm9taXNlZCwgYQ0K PiA+ID4gPiA+ID4gPiA+IHByb2Nlc3MgbmVlZHMgdG8gYmUgaW4gcGxhY2UgZm9yIHRoZSBIQSB0 byBBTFdBWVMNCj4gPiA+IHByb3ZpZGUgdGhlDQo+ID4gPiA+ID4gPiA+ID4gQUFBeiwgQXV0aG9y aXphdGlvbiBzZXJ2ZXIsIHdpdGggYSBwcm9vZiAodG9rZW4sDQo+ID4gPiA+ID4gPiA+ID4gZXRj LikgdGhhdCB0aGUgdXNlciBoYXMgYmVlbiBhdXRoZW50aWNhdGVkIGJ5IEFBQW4uDQo+ID4gPiA+ ID4gPiA+IA0KPiA+ID4gPiA+ID4gPiBPSywgaWYgSEEgY2FuIGJlIGNvbXByb21pc2VkLiBCdXQg d2h5IGFyZSB3ZSANCj4gc3RvcHBpbmcgaGVyZT8gDQo+ID4gPiA+ID4gPiA+IFdoeSBub3QgY29u c2lkZXJpbmcgdGhlIGNhc2Ugd2hlcmUgdGhlIEFBQW4gaXMgDQo+IGNvbXByb21pc2VkPyANCj4g PiA+ID4gPiA+ID4gSXMgaXMgaXQgbW9yZSBsaWtlbHkgZm9yIGFuIEhBIHRvIGJlIGNvbXByb21p c2VkIHRoYW4NCj4gPiA+ID4gZm9yIGEgQUFBbj8NCj4gPiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4g PiA+IFdlIHJlYWxseSBoYXZlIHRvIGFncmVlIG9uIGEgdGhyZWF0IG1vZGVsIGZpcnN0Lg0KPiA+ ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+ID4gPiBJIGFzc3VtZSBoZXJlIHRoYXQgdGhlIGRpZmZl cmVuY2UgaW4gb3BpbmlvbiBpcyANCj4gYWJvdXQgdGhlDQo+ID4gPiA+ID4gPiA+IHBvc3NpYmls aXR5DQo+ID4gPiA+ID4gPiA+ID4gb2YgdGhlIEhBIHRvIGJlIGNvbXByb21pc2VkIG9yIE5PVC4N Cj4gPiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiA+IEV4YWN0bHkuDQo+ID4gPiA+ID4gPiA+IA0K PiA+ID4gPiA+ID4gPiBCZXN0LA0KPiA+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+ID4gLS1qdWxp ZW4gKEwuKQ0KPiA+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+ID4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gPiA+ID4gRGlNRSBtYWlsaW5n IGxpc3QNCj4gPiA+ID4gPiA+ID4gRGlNRUBpZXRmLm9yZw0KPiA+ID4gPiA+ID4gPiBodHRwczov L3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQo+ID4gPiA+ID4gPiA+IA0KPiA+ ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gPiA+IERpTUUgbWFpbGluZyBs aXN0DQo+ID4gPiA+ID4gPiBEaU1FQGlldGYub3JnDQo+ID4gPiA+ID4gPiBodHRwczovL3d3dzEu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQo+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+ IA0KPiA+ID4gPiA+IA0KPiA+ID4gPiANCj4gPiA+IA0KPiA+IA0KPiANCg== --===============0085606759== 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 --===============0085606759==-- From dime-bounces@ietf.org Thu Jan 25 14:04:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA9tz-0000Or-QF; Thu, 25 Jan 2007 14:04:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA9tx-0000Ol-RW for dime@ietf.org; Thu, 25 Jan 2007 14:04:49 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA9tw-0003dI-0V for dime@ietf.org; Thu, 25 Jan 2007 14:04:49 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l0PJ4Or18281; Thu, 25 Jan 2007 14:04:24 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C740B3.A01C5639" Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Issue or notIssue ? Date: Thu, 25 Jan 2007 13:04:22 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437112683123@zrc2hxm2.corp.nortel.com> In-Reply-To: <20070125162311.GA22988@steelhead> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Issue or notIssue ? Thread-index: AcdAnTwD+5jZxoOhRjO7tpPqxi2g/AAFLizg From: "Ahmad Muhanna" To: "Yoshihiro Ohba" , "MORAND Lionel RD-CORE-ISS" X-Spam-Score: 0.0 (/) X-Scan-Signature: 847361531d5cb2b89126844012e81b58 Cc: dime@ietf.org, Julien Laganier 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. ------_=_NextPart_001_01C740B3.A01C5639 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit All, cutting some text for clarity. One comment below from an old posting which is attached. Regards, Ahmad > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Thursday, January 25, 2007 10:23 AM > To: MORAND Lionel RD-CORE-ISS > Cc: Yoshihiro Ohba; Julien Laganier; Muhanna, Ahmad > (RICH1:2H10); dime@ietf.org > Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: > Issue or notIssue ? > > > > > I would have no problem with a solution proposing EAP > authentication procedures and MIP6 authorization procedures > supported by to different diameter applications IF it could > be possible to bind both procedures in the same equipment in > the MSA. That is not the case with the current solution. > > It is possible by just routing the two different applications > to the same server. > [Ahmad] This was one of the suggestions that I proposed after reviewing the draft, cutting and pasting from the original email which is attached: " [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 ? " > Yoshihiro Ohba > > > > > > BR, > > > > Lionel > > > > > > There is a new guy in the game ;) > > > > > > > > After reviewing the draft and the mail exchange on the > > > topic, I would say that the conclusion on "issue/no issue" > > > depends on the side you are considering the problem (as often ;). > > > > > > > > If you are considering the AAA-MIP6 as a "simple" database > > > providing the HA with specific user/service information after a > > > separate authentication (performed with Diameter authentication), > > > the username conveyed over the HA/AAA-MIP6 is just used as a key > > > entry in the database. There is no need for the AAA-MIP6 to > > > authenticate this username or to be sure that the username was > > > previously authenticated. The client of the database is > the HA and > > > not the user. In that case, the > > > AAA-MIP6 has to trust the HA and it is up to the HA to > authenticate > > > the username provided by the mn during the SA set-up. > This could be > > > compared to interfaces between HSS (Home Subscriber > Server) and SIP > > > application servers defined in the 3GPP architecture, over which > > > Diameter applications are used to access database. > > > > > > > > In this context, the HA may use: > > > > 1) the Diameter EAP application to authenticate the user. > > > > 2) the Diameter MIP6 application to download user > related service > > > > information Authentication and authorization are performed > > > by the AAA-EAP. But there is no way for the AAA-EAP to > know what is > > > the service requested by the user. Successful > authentication implies > > > implicte authorization. This is the problem with Diameter > EAP as it > > > is not possible to route Diameter EAP request to a > service-specific > > > EAP server. > > > > > > If AAA-MIP6 provides authorizatin, AAA-EAP provides > authentication, > > > but does not provide authorization. For this purpose, > the HA needs > > > to set Auth-Request-Type set to AUTHENTICATE_ONLY in AAA-EAP. In > > > this case, AAA-EAP server does not need to know what kind of > > > authorization will be made. The authorization decision > will be made > > > by AAA-MIP6. > > > Am I missing something? > > > > > > > > > > > In another hand, if the AAA-MIP6 is an authority handling > > > MIP6 service access authorization rights i.e. the AAA-MIP6 must > > > verify that the user is authorized to use the Mobile > > > IPv6 service, this authority has to be able to verify the > identity > > > of the user before authorizing this user to access the > service. It > > > is not possible to authorize someone to do something > without being > > > sure of its identity as the authority must stand surety > of the user > > > access rights. Now, it is not possible to rely on the > Diameter EAP > > > application to perform the authentication procedure as > there is no > > > way to direct the Diameter EAP requests to a specifc EAP > server (as > > > the Diameter routing is based on App-Id and Realm). We > might think > > > about some specific things to link authentication procedures and > > > authorization/service profile handling. But for me, the simpliest > > > way would be to define the required authentication > mechanism within > > > one and only one application i.e. the application that > requires this > > > authentication. > > > Therefore, Diameter EAP would not be used and > application-specific > > > commands would be specified in the application. One command pair > > > would be added to the Diameter > > > MIP6 application. And to support EAP, AVPs defined in > 4072 would be > > > at least (re-)used. > > > > > > I don't understand the difference between the two cases you > > > mentioned above. I believe that more or less the AAA > servers need > > > to trust the HA in both cases. Depending on threat model > which we > > > don't seem to exactly know right now, the > > > AAA-MIP6 server may or may not need an evidence that the user has > > > been authenticated by a AAA-EAP server. > > > > > > > > > > > IMHO, the context described in the draft looks like more a > > > service access authorization management than the use of a simple > > > external database. I would be therefore in favor of defining > > > authentication commands within the Diameter MIP6 > application instead > > > of trying to reuse the Diameter EAP application, which is not > > > possible without modifications. EAP authentication and > MIP6 service > > > access authorization are performed with the same > application. Since > > > a application-Id is whatever needed for the HA/AAA-MIP6, > what would > > > be the benefit to look for solutions binding Diameter EAP and > > > Diameter MIP6 (with some key derivation, etc.) while a single > > > Diameter MIP6 application with intrinsic authentication commands > > > would be fully appropriate? > > > > > > I don't understand what is the point of discussing > "service access > > > authorization management" and "simple external database". > If MIP6 > > > application needs to support multiple authentication > methods such as > > > EAP and RFC 4285, I believe it is more appropriate to consider > > > separation of authentication and authorization if security is > > > reasonably handled. Also, there is some authentication method > > > (e.g., authentication based on IKEv2-cert without using EAP) does > > > not require any AAA interacation for authentication. I > was pointing > > > this out several times but no one seems to pay attention to it. > > > > > > > > > > > I'm pretty sure that the content of this mail may be > > > challenged line by line ;) But at the end, if authentication and > > > authorization are needed to provide MIP6 services, why do > not having > > > a single application to do it? Of course, I don't say > that it would > > > not be possible to do something more complex... > > > > > > To me, discussion on coupling vs. decoupling authentication and > > > authorization is not just a MIP6 issue. This is a fundamental > > > discussion that will decide the future direction of AAA. > > > > > > Yoshihiro Ohba > > > > > > > > > > > BR, > > > > > > > > Lionel > > > > > > > > > > > > > -----Message d'origine----- > > > > > De : Julien Laganier [mailto:julien.IETF@laposte.net] > > > > > Envoy$B!)(J : mardi 23 janvier 2007 10:42 > > > > > $B!)(J : Ahmad Muhanna > > > > > Cc : dime@ietf.org > > > > > Objet : Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: > > > > > Issue or notIssue ? > > > > > > > > > > Hi Ahmad, > > > > > > > > > > Cutting a bit thru your message, I have some comments > > > > > below: > > > > > > > > > > On Monday 22 January 2007 18:10, Ahmad Muhanna wrote: > > > > > > > > > > > > > > > > > >[...] > > > > > > > > > > > > [Ahmad] > > > > > > We are probably splitting hair here, apparently > there are two > > > > > > arguments here: > > > > > > > > > > I don't think this is hair splitting. Understand the > > > issue should be > > > > > a prerequisite to solving it. > > > > > > > > > > > 1. AAAz is an authorization server and since it has > a security > > > > > > relationship with the HA, AAAz relies on the HA to do two > > > > > things: 1.1. > > > > > > HA makes sure that the user has been authenticated by > > > AAAn. 1.2. > > > > > > HA will not send any Authorization requests for any user(s) > > > > > who has not > > > > > > been authenticated. > > > > > > > > > > > > (In normal conditions, the above two conditions are ALWAYS > > > > > TRUE except > > > > > > in one condition, HA has been > > > > > > compromised) > > > > > > > > > > Right. So we both agree there's no problem unless the HA is > > > > > compromised > > > > > > > > > > I think what the first step is to agree on a threat > > > model. I do not > > > > > agree that we should defend against a compromised HA. > > > > > The HA should be deemed secure against attackers. > > > > > > > > > > We have to place a limit on what is entity X when asking the > > > > > question "what if entity X is compromised". > > > > > Since nothing is really impossible in the real world, > we cannot > > > > > defend against compromission of any entity implicated in > > > a protocol. > > > > > Security is a tradeoff. > > > > > > > > > > More below... > > > > > > > > > > > 2. AAAz is an authorization server and has a security > > > > > association with > > > > > > the HA, however, due to the fact that the HA could be > > > > > compromised, a > > > > > > process needs to be in place for the HA to ALWAYS > provide the > > > > > > AAAz, Authorization server, with a proof (token, > > > > > > etc.) that the user has been authenticated by AAAn. > > > > > > > > > > OK, if HA can be compromised. But why are we stopping here? > > > > > Why not considering the case where the AAAn is compromised? > > > > > Is is it more likely for an HA to be compromised than > for a AAAn? > > > > > > > > > > We really have to agree on a threat model first. > > > > > > > > > > > I assume here that the difference in opinion is about the > > > > > possibility > > > > > > of the HA to be compromised or NOT. > > > > > > > > > > Exactly. > > > > > > > > > > Best, > > > > > > > > > > --julien (L.) > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > > > > > > > > > > > ------_=_NextPart_001_01C740B3.A01C5639 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from zrtphxs0.corp.nortel.com ([47.140.202.45]) by zrc2hxm2.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 16:09:18 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Received: from zrtps0kk.us.nortel.com ([47.140.192.53]) by zrtphxs0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 17:09:18 -0500 Received: from ertps003.nortelnetworks.com (ertps003.nortel.com [47.234.0.37]) by zrtps0kk.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id kANM9Hk03693; Thu, 23 Nov 2006 17:09:17 -0500 (EST) Received: from megatron.ietf.org (optimus.ietf.ORG [156.154.16.145]) by ertps003.nortelnetworks.com with SMTP (Lyris MailShield SOLARIS/SPARC version 4.0d standard); Thu, 23 Nov 2006 17:09:16 -0500 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnMk1-0007t5-Cv; 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) Content-class: urn:content-classes:message 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 List-Help: List-Subscribe: , List-Unsubscribe: , From: "Muhanna, Ahmad \(RICH1:2H10\)" To: "Julien Bournelle" Cc: 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 ------_=_NextPart_001_01C740B3.A01C5639 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 ------_=_NextPart_001_01C740B3.A01C5639-- From dime-bounces@ietf.org Fri Jan 26 12:38:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAV1g-0007Eh-Oc; Fri, 26 Jan 2007 12:38:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAV1f-0007Ea-Ii for dime@ietf.org; Fri, 26 Jan 2007 12:38:11 -0500 Received: from nf-out-0910.google.com ([64.233.182.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAV1d-0000J2-0M for dime@ietf.org; Fri, 26 Jan 2007 12:38:11 -0500 Received: by nf-out-0910.google.com with SMTP id l36so1234232nfa for ; Fri, 26 Jan 2007 09:38:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HsrgS6+Vmf6fgqs1VYUcM/vk9Lv3Lc1pgnzU1ZSka1fwggRtDBUtugP14A30RqdvUB6uTpVdH9JEll786uCgP1EXjbyAIDG7HI0zOVLTUQ3rUgy4okpPsGChZdsujpZgLVyP/YfHhKhV15xUtOOyc9fz9Z4LvWiaiPDaTxHnOkY= Received: by 10.48.230.5 with SMTP id c5mr5867886nfh.1169833088050; Fri, 26 Jan 2007 09:38:08 -0800 (PST) Received: by 10.48.222.20 with HTTP; Fri, 26 Jan 2007 09:38:07 -0800 (PST) Message-ID: <5e2406980701260938q7948a289q83453d7c16936b72@mail.gmail.com> Date: Fri, 26 Jan 2007 18:38:07 +0100 From: "Julien Bournelle" To: "Ahmad Muhanna" Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Issue or not Issue ? In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437112570CE8@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: <5e2406980701200410q1b8274f4m4dc526f64ea851d3@mail.gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437112570CE8@zrc2hxm2.corp.nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Cc: dime@ietf.org, Julien Laganier 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, sorry for the delay. some answers below On 1/22/07, Ahmad Muhanna wrote: > So far there is no proposed solution, but I think at one point long time > back and probably on this thread there was a discussion which briefly > mentioned from High Level that the HA needs to provide AAAz a > token/something to prove that this user has been > authenticated/Authentic. ok. > > 1. AAAz is an authorization server and since it has a security > relationship with the HA, AAAz relies on the HA to do two things: > 1.1. HA makes sure that the user has been authenticated by AAAn. > 1.2. HA will not send any Authorization requests for any user(s) who has > not been authenticated. > > (In normal conditions, the above two conditions are ALWAYS TRUE except > in one condition, HA has been compromised) > > 2. AAAz is an authorization server and has a security association with > the HA, however, due to the fact that the HA could be compromised, a > process needs to be in place for the HA to ALWAYS provide the AAAz, > Authorization server, with a proof (token, etc.) that the user has been > authenticated by AAAn. I have one question here: if the HA is compromised, why do it will contact the AAAz ? > I assume here that the difference in opinion is about the possibility of > the HA to be compromised or NOT. the HA may be compromised. > Because due to the decoupling of > Authentication and Authorization processes and using different > application IDs, I clearly see an issue when HA is compromised which > does not exist if Authorization and Authentication are not decoupled. > > > I agree with you, we have two options here: > > 1. If Authorization and Authentication processes are NOT decoupled, then > this issue goes away. > > 2. In the case of decoupling Authorization and Authentication, we > clearly need to highlight the new security risk/vulnerability introduced > by decoupling yes. > and provide a solution. if we all agree, I guess the simpler solution may be to re-couple AAAn and AAAz. > In the case that vulnerability is > not applicable to any deployment, then that solution becomes an > optional/not-needed one. (I am not sure what is the problem with this > approach.) > > > > > > Also, if AAAz receives too many of these Requests from the same HA, > > > AAAz can close the connection to the HA or just ignore all of its > traffic. > > > > right > > [Ahmad] > Thanks Julien. It seems you agree that AAAz can do this to avoid this > attack by a compromised HA; I was saying "right" because the AAAz may have an internal mechanism to protect himself against DoS from a HA. >then I assume that you agree decoupling the > Authentication and Authorization processes introduces a security > vulnerability/risk in the case when HA is compromised which does not > exist if both Authentication and Authorization processes are not > decoupled. Right? I'm still not convinced, a compromised HA may also perform a DoS on a AAA coupling authn and authz. To be honest, I don't have strong opinion on this subject. I think that both sides seem to have valid arguments. However, if we think that the AAAz should have a way to get an assurance that the user has been authenticated, I would prefer to have a unique application to do so. In this case, I'm wondering if we could design an application that would support different kind of authentication (EAP, RFC4285, others ?). But, I saw that in the past, NASREQ and EAP application were coupled and have been split. It could be interesting to know the reason. My 2 cents, Julien > > > > > > > > Theoretically, I agree with Madjid that there is an issue > > that needs > > > to be addressed. > > > > I'm still not convinced. > > [Ahmad] > Please see my comments above. I hope it helps in clarifying the issue. > > > > > > On the other hand, we need to assess the possibility for > > this security > > > vulnerability to happen in the field and make an educated > > decision to > > > address it or not. One more thing, we can recognize the issue and > > > provide an optional solution that any deployment which does not > > > guarantee that HA wont be comprised Shall implement the proposed > > > solution. Just an idea. > > > > that's indeed the question: do we introduce a threat here ? > > or in other terms do we have an issue here ? > > > > I think no. Madjid and you think "yes". > > > > We clearly need a way to move forward but I don't think we > > (as a WG) can say: if you think there is an issue then use > > this optional mechanism, if you don't think it is an issue > > then you don't need this optional mechanism. > > > > We must know if it is an issue or not. > > > > regards, > > > > --Julien (B.) > > > > > > > > > > > > > > > > > As far as you other statements: > > > > > "At the HA, there is assurance that the peer is authenticated > > > > > since it just checked if it was. " > > > > > > > > > > I don't think assurance at HA is relevant for AAAz, > > since HA was > > > > > not involved in EAP. > > > > > > > > But HA is involved in the EAP exchange! It acts as a > > passtrough, and > > > > gets authentication assurance from AAAn. > > > > > > > > > "If the two were coupled, still the HA would be able to > > launch a > > > > > DoS on the AAA server and bombard it with authentication and > > > > > authorization requests." > > > > > > > > > > If the authentication failed, then there would be no > > > > > authorization. > > > > > > > > AFAICS the mechanism you want to provide protect from a > > rogue HA. If > > > > the HA is rogue it can ask for authorization request when > > it wants. > > > > It doesn't need authentication to succeed for that. > > > > > > > > > "The AAA server isn't really in control of who gets the > > mobility > > > > > server and who doesn't since at the end this is up to the HA to > > > > > provide the service or not." > > > > > > > > > > AAA server is the authority that authorizes the > > resource, it does > > > > > not police the resource usage, since it is not on the > > path, but we > > > > > are talking about authorization not policing. > > > > > > > > > > You can feel free to stop the conversation if you want. The > > > > > solution to the problem is pretty simple, the MN simply > > signs the > > > > > trigger for the service request. So instead of getting you > > > > > frustrated, I will just work to see if I can get the draft out. > > > > > > > > The solution to this discussion is pretty simple too: > > > > What is the problem? :) > > > > > > > > --julien > > > > > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jan 29 19:21:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBgkA-00037w-2Q; Mon, 29 Jan 2007 19:21:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBgk9-00037n-0n for dime@ietf.org; Mon, 29 Jan 2007 19:21:01 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBgk7-0004GE-EX for dime@ietf.org; Mon, 29 Jan 2007 19:21:01 -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 <0JCN00MSANMZJ4@usaga01-in.huawei.com> for dime@ietf.org; Mon, 29 Jan 2007 16:20:59 -0800 (PST) Received: from huawei.com ([172.18.4.47]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCN00562NMTLU@usaga01-in.huawei.com> for dime@ietf.org; Mon, 29 Jan 2007 16:20:59 -0800 (PST) Received: from N737011 (pool-71-112-126-182.sttlwa.dsl-w.verizon.net [71.112.126.182]) by usaml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JCN00FYDO50DW@usaml03-in.huawei.com> for dime@ietf.org; Mon, 29 Jan 2007 16:31:55 -0800 (PST) Date: Mon, 29 Jan 2007 16:20:51 -0800 From: Madjid Nakhjiri In-reply-to: <7DBAFEC6A76F3E42817DF1EBE64CB026043BC087@FTRDMEL2.rd.francetelecom.fr> To: 'MORAND Lionel RD-CORE-ISS' , 'Julien Laganier' , 'Ahmad Muhanna' Message-id: <004801c74404$81cc5b40$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: Acc+0s22USDiJddWShOfYJVGYuMU3QACXRGwAUk3fvA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df Cc: dime@ietf.org Subject: [Dime] new darft: nakhjiri-dime-mip6-nsi to deal with.. was: Diameter Mobile IPv6 HA-to-AAAH Support: Issue or notIssue ? 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, Thanks for the nice break down of the problem that arises from = separation of Authentication and authorization. You may be new in the game, but you certainly started a juicy thread. The problem is that AAA-MIP6 is seen as a database operation on the user profile to do authorization. I actually go further than you and say heck = if the AAA-MIP6 authorization process is separate from the authentication, = then why even bother to use the same identity? We are not checking the authentication state, so we might as well use two different identities = for AAA-EAP and AAA-MIP6 (I hope people realize the sarcasm here). And yes, when AAA-MIP6 and AAA-EAP are separate, as you mentioned the AAA-EAP just does EAP authentication and has no idea about future = service requests including those for MIP6 service and this creates another = issue. Once Hokey WG defines the method for using EAP MSK/EMSK to generate keys = for MIP6 and so on, the AAA-EAP actually needs to create the keying material = for MIP6, while it has no idea about MIP6 service, since that service is = being authorized by AAA-MIP6. I personally am on the fence on one versus two applications. The easiest = way out is to define one application that re-uses EAP. The more grand way is = to allow for separation of Authentication and authorization, but then we = have to take care of the arising issues, which are: 1) AAA-MIP6 making sure MN is authenticated. 2) AAA-EAP getting access to service data to create MIP6 keys. Having debating this for so long, we have written a draft that tries to tackle the issues. The main idea is to use the initial Authentication (either MN or AAA-EAP, but not HA) to create an verifiable assurance of = the authentication to the AAA-MIP and define an interaction between AAA-MIP = and AAA-EAP to get MIP6 key material. There are some other bells and = whistles such as the Authentication ID that could help the future AAA work (as = Yoshi mentioned), where you can have separate authentication and authorization servers=20 http://www.ietf.org/internet-drafts/draft-nakhjiri-dime-mip6-nsi-00.txt Regards, Madjid -----Original Message----- From: MORAND Lionel RD-CORE-ISS = [mailto:lionel.morand@orange-ftgroup.com]=20 Sent: Tuesday, January 23, 2007 7:12 AM To: Julien Laganier; Ahmad Muhanna Cc: dime@ietf.org Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Issue or notIssue ? Hi Folks, There is a new guy in the game ;) After reviewing the draft and the mail exchange on the topic, I would = say that the conclusion on "issue/no issue" depends on the side you are considering the problem (as often ;). If you are considering the AAA-MIP6 as a "simple" database providing the = HA with specific user/service information after a separate authentication (performed with Diameter authentication), the username conveyed over the HA/AAA-MIP6 is just used as a key entry in the database. There is no = need for the AAA-MIP6 to authenticate this username or to be sure that the username was previously authenticated. The client of the database is the = HA and not the user. In that case, the AAA-MIP6 has to trust the HA and it = is up to the HA to authenticate the username provided by the mn during the = SA set-up. This could be compared to interfaces between HSS (Home = Subscriber Server) and SIP application servers defined in the 3GPP architecture, = over which Diameter applications are used to access database. =20 In this context, the HA may use: 1) the Diameter EAP application to authenticate the user. =20 2) the Diameter MIP6 application to download user related service information Authentication and authorization are performed by the AAA-EAP. But there = is no way for the AAA-EAP to know what is the service requested by the = user. Successful authentication implies implicte authorization. This is the problem with Diameter EAP as it is not possible to route Diameter EAP request to a service-specific EAP server. In another hand, if the AAA-MIP6 is an authority handling MIP6 service access authorization rights i.e. the AAA-MIP6 must verify that the user = is authorized to use the Mobile IPv6 service, this authority has to be able = to verify the identity of the user before authorizing this user to access = the service. It is not possible to authorize someone to do something without being sure of its identity as the authority must stand surety of the = user access rights. Now, it is not possible to rely on the Diameter EAP application to perform the authentication procedure as there is no way = to direct the Diameter EAP requests to a specifc EAP server (as the = Diameter routing is based on App-Id and Realm). We might think about some = specific things to link authentication procedures and authorization/service = profile handling. But for me, the simpliest way would be to define the required authentication mechanism within one and only one application i.e. the application that requires this authentication. Therefore, Diameter EAP = would not be used and application-specific commands would be specified in the application. One command pair would be added to the Diameter MIP6 application. And to support EAP, AVPs defined in 4072 would be at least (re-)used. IMHO, the context described in the draft looks like more a service = access authorization management than the use of a simple external database. I = would be therefore in favor of defining authentication commands within the Diameter MIP6 application instead of trying to reuse the Diameter EAP application, which is not possible without modifications. EAP = authentication and MIP6 service access authorization are performed with the same application. Since a application-Id is whatever needed for the = HA/AAA-MIP6, what would be the benefit to look for solutions binding Diameter EAP and Diameter MIP6 (with some key derivation, etc.) while a single Diameter = MIP6 application with intrinsic authentication commands would be fully appropriate? I'm pretty sure that the content of this mail may be challenged line by = line ;) But at the end, if authentication and authorization are needed to = provide MIP6 services, why do not having a single application to do it? Of = course, I don't say that it would not be possible to do something more complex... BR, Lionel > -----Message d'origine----- > De : Julien Laganier [mailto:julien.IETF@laposte.net]=20 > Envoy=E9 : mardi 23 janvier 2007 10:42 > =C0 : Ahmad Muhanna > Cc : dime@ietf.org > Objet : Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support:=20 > Issue or notIssue ? >=20 > Hi Ahmad, >=20 > Cutting a bit thru your message, I have some comments > below: >=20 > On Monday 22 January 2007 18:10, Ahmad Muhanna wrote: > > > > > >[...] > > > > [Ahmad] > > We are probably splitting hair here, apparently there are two=20 > > arguments here: >=20 > I don't think this is hair splitting. Understand the issue=20 > should be a prerequisite to solving it. >=20 > > 1. AAAz is an authorization server and since it has a security=20 > > relationship with the HA, AAAz relies on the HA to do two=20 > things: 1.1.=20 > > HA makes sure that the user has been authenticated by AAAn. 1.2. HA=20 > > will not send any Authorization requests for any user(s)=20 > who has not=20 > > been authenticated. > > > > (In normal conditions, the above two conditions are ALWAYS=20 > TRUE except=20 > > in one condition, HA has been > > compromised) >=20 > Right. So we both agree there's no problem unless the HA is=20 > compromised >=20 > I think what the first step is to agree on a threat model. I=20 > do not agree that we should defend against a compromised HA.=20 > The HA should be deemed secure against attackers. >=20 > We have to place a limit on what is entity X when asking the=20 > question "what if entity X is compromised".=20 > Since nothing is really impossible in the real world, we=20 > cannot defend against compromission of any entity implicated=20 > in a protocol. Security is a tradeoff.=20 >=20 > More below... >=20 > > 2. AAAz is an authorization server and has a security=20 > association with=20 > > the HA, however, due to the fact that the HA could be=20 > compromised, a=20 > > process needs to be in place for the HA to ALWAYS provide the AAAz,=20 > > Authorization server, with a proof (token, > > etc.) that the user has been authenticated by AAAn. >=20 > OK, if HA can be compromised. But why are we stopping here?=20 > Why not considering the case where the AAAn is compromised?=20 > Is is it more likely for an HA to be compromised than for a AAAn? >=20 > We really have to agree on a threat model first. >=20 > > I assume here that the difference in opinion is about the=20 > possibility=20 > > of the HA to be compromised or NOT. >=20 > Exactly. >=20 > Best, >=20 > --julien (L.) >=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 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jan 29 19:26:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBgpj-0005Ki-P6; Mon, 29 Jan 2007 19:26:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBgpi-0005KY-P8 for dime@ietf.org; Mon, 29 Jan 2007 19:26:46 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBgph-0005Se-64 for dime@ietf.org; Mon, 29 Jan 2007 19:26:46 -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 <0JCN00MBNNWKJ4@usaga01-in.huawei.com> for dime@ietf.org; Mon, 29 Jan 2007 16:26:45 -0800 (PST) Received: from huawei.com ([172.18.4.47]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCN001GQNWI8E@usaga01-in.huawei.com> for dime@ietf.org; Mon, 29 Jan 2007 16:26:44 -0800 (PST) Received: from N737011 (pool-71-112-126-182.sttlwa.dsl-w.verizon.net [71.112.126.182]) by usaml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JCN00F3NOESDW@usaml03-in.huawei.com> for dime@ietf.org; Mon, 29 Jan 2007 16:37:44 -0800 (PST) Date: Mon, 29 Jan 2007 16:26:44 -0800 From: Madjid Nakhjiri Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Issue or notIssue ? In-reply-to: To: 'Gerardo Giaretta' , 'MORAND Lionel RD-CORE-ISS' Message-id: <004901c74405$522e74d0$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: Acc/jW3k24sgmjyqRNSnodM2ZjHI/QEdyy8Q X-Spam-Score: 0.0 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Cc: dime@ietf.org, 'Julien Laganier' 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, This is a good short term solution for solving parts of the current = MIPv6 split scenario problems. I don't see why we need to change 4072, when we = are using its AVPs? If you define a new Diameter MIP6 application, all the = 4285 needs is probably to add AVPs to the same application, possibly through = a separate RFC (if the AVPs don't come in time:)). However, in the long term, I think it is good to investigate how authentication and authorization can be dealt with separate, this will probably as Yoshi mentioned be the way to go in the future. We can deal = with that in a separate context. I am hoping that our draft http://www.ietf.org/internet-drafts/draft-nakhjiri-dime-mip6-nsi-00.txt can shed some light on the issues. Regards, Madjid -----Original Message----- From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com]=20 Sent: Tuesday, January 23, 2007 11:57 PM To: MORAND Lionel RD-CORE-ISS Cc: dime@ietf.org; Julien Laganier Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Issue or notIssue ? Hi all, I agree with Lionel. The proposal of having a split between authentication and authorization was made by Yoshi in order to avoid changes to 4072 and avoid duplicating functionality between Diameter applications. However, it seems that there are more drawbacks than benefits as discussed in this month. And I don't see a strong issue in having the MIP6 Diameter application supporting both authentication and authorization. Note that if we want to add support for rfc4285, we'll have to define an authentication application for MIP6 anyway. Therefore my suggestion is: close the issue stating that the AAA servers for authentication and authorization are co-located and that the same application is used for both. Does it sound good to everybody? If not, I would like to hear strong motivations and benefits to have the servers/application split since during these months I have not heard any (a part from the documentation issue mentioned above). --Gerardo On 1/23/07, MORAND Lionel RD-CORE-ISS wrote: > Hi Folks, > > There is a new guy in the game ;) > > After reviewing the draft and the mail exchange on the topic, I would = say that the conclusion on "issue/no issue" depends on the side you are considering the problem (as often ;). > > If you are considering the AAA-MIP6 as a "simple" database providing = the HA with specific user/service information after a separate = authentication (performed with Diameter authentication), the username conveyed over the HA/AAA-MIP6 is just used as a key entry in the database. There is no = need for the AAA-MIP6 to authenticate this username or to be sure that the username was previously authenticated. The client of the database is the = HA and not the user. In that case, the AAA-MIP6 has to trust the HA and it = is up to the HA to authenticate the username provided by the mn during the = SA set-up. This could be compared to interfaces between HSS (Home = Subscriber Server) and SIP application servers defined in the 3GPP architecture, = over which Diameter applications are used to access database. > > In this context, the HA may use: > 1) the Diameter EAP application to authenticate the user. > 2) the Diameter MIP6 application to download user related service information > Authentication and authorization are performed by the AAA-EAP. But = there is no way for the AAA-EAP to know what is the service requested by the = user. Successful authentication implies implicte authorization. This is the problem with Diameter EAP as it is not possible to route Diameter EAP request to a service-specific EAP server. > > In another hand, if the AAA-MIP6 is an authority handling MIP6 service access authorization rights i.e. the AAA-MIP6 must verify that the user = is authorized to use the Mobile IPv6 service, this authority has to be able = to verify the identity of the user before authorizing this user to access = the service. It is not possible to authorize someone to do something without being sure of its identity as the authority must stand surety of the = user access rights. Now, it is not possible to rely on the Diameter EAP application to perform the authentication procedure as there is no way = to direct the Diameter EAP requests to a specifc EAP server (as the = Diameter routing is based on App-Id and Realm). We might think about some = specific things to link authentication procedures and authorization/service = profile handling. But for me, the simpliest way would be to define the required authentication mechanism within one and only one application i.e. the application that requires this authentication. Therefore, Diameter EAP = would not be used and application-specific commands would be specified in the application. One command pair would be added to the Diameter MIP6 application. And to support EAP, AVPs defined in 4072 would be at least (re-)used. > > IMHO, the context described in the draft looks like more a service = access authorization management than the use of a simple external database. I = would be therefore in favor of defining authentication commands within the Diameter MIP6 application instead of trying to reuse the Diameter EAP application, which is not possible without modifications. EAP = authentication and MIP6 service access authorization are performed with the same application. Since a application-Id is whatever needed for the = HA/AAA-MIP6, what would be the benefit to look for solutions binding Diameter EAP and Diameter MIP6 (with some key derivation, etc.) while a single Diameter = MIP6 application with intrinsic authentication commands would be fully appropriate? > > I'm pretty sure that the content of this mail may be challenged line = by line ;) But at the end, if authentication and authorization are needed = to provide MIP6 services, why do not having a single application to do it? = Of course, I don't say that it would not be possible to do something more complex... > > BR, > > Lionel > > > > -----Message d'origine----- > > De : Julien Laganier [mailto:julien.IETF@laposte.net] > > Envoy=E9 : mardi 23 janvier 2007 10:42 > > =C0 : Ahmad Muhanna > > Cc : dime@ietf.org > > Objet : Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: > > Issue or notIssue ? > > > > Hi Ahmad, > > > > Cutting a bit thru your message, I have some comments > > below: > > > > On Monday 22 January 2007 18:10, Ahmad Muhanna wrote: > > > > > > > > >[...] > > > > > > [Ahmad] > > > We are probably splitting hair here, apparently there are two > > > arguments here: > > > > I don't think this is hair splitting. Understand the issue > > should be a prerequisite to solving it. > > > > > 1. AAAz is an authorization server and since it has a security > > > relationship with the HA, AAAz relies on the HA to do two > > things: 1.1. > > > HA makes sure that the user has been authenticated by AAAn. 1.2. = HA > > > will not send any Authorization requests for any user(s) > > who has not > > > been authenticated. > > > > > > (In normal conditions, the above two conditions are ALWAYS > > TRUE except > > > in one condition, HA has been > > > compromised) > > > > Right. So we both agree there's no problem unless the HA is > > compromised > > > > I think what the first step is to agree on a threat model. I > > do not agree that we should defend against a compromised HA. > > The HA should be deemed secure against attackers. > > > > We have to place a limit on what is entity X when asking the > > question "what if entity X is compromised". > > Since nothing is really impossible in the real world, we > > cannot defend against compromission of any entity implicated > > in a protocol. Security is a tradeoff. > > > > More below... > > > > > 2. AAAz is an authorization server and has a security > > association with > > > the HA, however, due to the fact that the HA could be > > compromised, a > > > process needs to be in place for the HA to ALWAYS provide the = AAAz, > > > Authorization server, with a proof (token, > > > etc.) that the user has been authenticated by AAAn. > > > > OK, if HA can be compromised. But why are we stopping here? > > Why not considering the case where the AAAn is compromised? > > Is is it more likely for an HA to be compromised than for a AAAn? > > > > We really have to agree on a threat model first. > > > > > I assume here that the difference in opinion is about the > > possibility > > > of the HA to be compromised or NOT. > > > > Exactly. > > > > Best, > > > > --julien (L.) > > > > _______________________________________________ > > 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 Mon Jan 29 19:35:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBgyE-0007lj-2g; Mon, 29 Jan 2007 19:35:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBgyC-0007jf-IT for dime@ietf.org; Mon, 29 Jan 2007 19:35:32 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBgy6-0006qc-4v for dime@ietf.org; Mon, 29 Jan 2007 19:35: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 <0JCN00M65OB1J4@usaga01-in.huawei.com> for dime@ietf.org; Mon, 29 Jan 2007 16:35:25 -0800 (PST) Received: from huawei.com ([172.18.4.47]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCN0017ROAZ8E@usaga01-in.huawei.com> for dime@ietf.org; Mon, 29 Jan 2007 16:35:25 -0800 (PST) Received: from N737011 (pool-71-112-126-182.sttlwa.dsl-w.verizon.net [71.112.126.182]) by usaml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JCN00AYOOT38Q@usaml03-in.huawei.com> for dime@ietf.org; Mon, 29 Jan 2007 16:46:24 -0800 (PST) Date: Mon, 29 Jan 2007 16:35:19 -0800 From: Madjid Nakhjiri Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Issue or notIssue ? In-reply-to: <7DBAFEC6A76F3E42817DF1EBE64CB026043F77B1@FTRDMEL2.rd.francetelecom.fr> To: 'MORAND Lionel RD-CORE-ISS' , 'Ahmad Muhanna' , 'Yoshihiro Ohba' Message-id: <005301c74406$88785af0$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=utf-8 Content-transfer-encoding: quoted-printable Thread-index: AcdAA/r5nUIvzJ8ATjeXOadoEt8alwAWd2gAAAvsElAAASCtUAAEcmegAAF0xzAA1zPeEA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f251f249fc9a04067ce354aa0943ab98 Cc: dime@ietf.org, 'Julien Laganier' 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 But there is also a possible separation of AAA servers:) -----Original Message----- From: MORAND Lionel RD-CORE-ISS = [mailto:lionel.morand@orange-ftgroup.com]=20 Sent: Thursday, January 25, 2007 10:01 AM To: Ahmad Muhanna; Yoshihiro Ohba Cc: dime@ietf.org; Julien Laganier Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Issue or = notIssue ? Hi Ahmad, I think that there is a confusion between "AAA messages" and "AAA = protocols". Therefore, when they speak about "separation", it's about separation of = AAA messages within the same AAA protocol, and not separation of AAA = protocols. If we have to keep only one statement, it would be: "the AAA protocols MUST also allow for a single message to request both = authentication and authorization." Lionel > -----Message d'origine----- > De : Ahmad Muhanna [mailto:amuhanna@nortel.com]=20 > Envoy=C3=A9 : jeudi 25 janvier 2007 18:37 > =C3=80 : MORAND Lionel RD-CORE-ISS; Yoshihiro Ohba > Cc : Julien Laganier; dime@ietf.org > Objet : RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support:=20 > Issue or notIssue ? >=20 > Hi Lionel, > Thanks for your response. Please see some comments inline. >=20 > Regards, > Ahmad > =20 >=20 > > Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support:=20 > > Issue or notIssue ? > >=20 > > Hi Ahmad, > >=20 > > Just a couple of requirements: > >=20 > > 2.7.3=20 > > Within a single session or transaction, it MUST be possible to > > interleave authentication, authorization and accounting=20 > AAA messages. > >=20 > > This states, that e.g. a session may have to use initial > > authentication, authorization and accounting AAA message(s), but=20 > > also > > have to include e.g. re-authentication every 30 minutes, or a > > continuous "drip-drip" of accounting AAA messages. >=20 > [Ahmad] > This one is a little tricky. IMO, In the case of=20 > Authentication and Authorization separation, there will be=20 > authentication, authorization, and accounting for every=20 > session. DO you think otherwise? I do not see here that there=20 > is an indication that Authorization and Authentication needs=20 > to be combined again. >=20 > >=20 > > 2.9.1 > > Authorization separate from authentication SHOULD be allowed > > when necessary, but the AAA protocols MUST also allow=20 > for a single > > message to request both authentication and authorization. > >=20 > > AAA protocols have to allow a split between authentication and > > authorization so that different mechanisms are used for=20 > each. This > > states that sometimes both types of information need to=20 > be carried=20 > > in > > the same message. >=20 > [Ahmad] > I am not sure I can read this requirement as a requirement=20 > that when Authentication and Authorization are separated,=20 > Authorization messages MUST provide authentication too.=20 > Because if that was the intention, then this requirement does=20 > not make any sense. The second portion of it negate what the=20 > first portion already allowed to happen. > My interpretation is the Authentication and Authorization is=20 > fine and allowed, however, AAA protocols should give the=20 > option for integrated solution, i.e. Authentication and=20 > Authorization in the same message and at the same time. >=20 >=20 > In general, as long as RFC2609 ALLOWED the separation between=20 > Authentication and Authorization, it does not make sense to=20 > mandate integration in case separation option is adopted. Am=20 > I making some sense here. >=20 > >=20 > > But you can find several other places in the document where=20 > > authentication & authorization are bound. > >=20 > > BR, > >=20 > > Lionel > >=20 > > > -----Message d'origine----- > > > De : Ahmad Muhanna [mailto:amuhanna@nortel.com] Envoy=C3=A9 : = jeudi 25=20 > > > janvier 2007 15:42 =C3=80 : MORAND Lionel RD-CORE-ISS; Yoshihiro > > Ohba Cc :=20 > > > Julien Laganier; dime@ietf.org Objet : RE: [Dime] Diameter > > Mobile IPv6 > > > HA-to-AAAH Support: > > > Issue or notIssue ? > > >=20 > > > Hi Lionel, > > > Please see some one comment inline. > > >=20 > > > Regards, > > > Ahmad > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: MORAND Lionel RD-CORE-ISS > > > > [mailto:lionel.morand@orange-ftgroup.com] > > > > Sent: Thursday, January 25, 2007 5:11 AM > > > > To: Yoshihiro Ohba > > > > Cc: Julien Laganier; Muhanna, Ahmad (RICH1:2H10); dime@ietf.org > > > > Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support:=20 > > > > Issue or notIssue ? > > > >=20 > > > > Hi Yoshi, > > > >=20 > > > > 1) If authentication procedures may be performed apart from=20 > > > > authorization procedures (I totally agree), authorization > > > procedures > > > > must be able to rely on its own authentication procedures > > if needed > > > > (cf. AAA requirements in RFC 2906). Are you OK with that? > > >=20 > > > [Ahmad] > > > Just for my education, could you please give me a pointer=20 > to which=20 > > > requirement you are referring in RFC2906. > > > Thanks. > > >=20 > > > >=20 > > > > 2) As it is now, providing authentication with Diameter EAP=20 > > > > application and authorization with Diameter MIP6 does not > > allow the > > > > AAA-MIP6 to be sure that the username carried in the > > authorization > > > > request was previously authenticated by the AAA-EAP. Are > > > you OK with > > > > that? > > > >=20 > > > > 3) If the AAA-MIP6 provides the HA with service related > > information > > > > without being sure that the key entry (username) was previously=20 > > > > authenticated, what is the difference between the=20 > AAA-MIP6 and a=20 > > > > "simple" external database providing information data to any=20 > > > > authorized entity (HA in the present case)? What/where is the=20 > > > > authorization process in that case? > > > >=20 > > > > 4) If combining Diameter EAP and Diameter MIP6 is more > > complex than > > > > including authentication procedures with Diameter MIP6 that is=20 > > > > coherent with AAA requirements, why are we still discussing > > > as much?=20 > > > > ;) > > > >=20 > > > > 5) If the discussion is beyond the scope of the draft and > > > related to > > > > the future of global AAA framework, why do not "decouple" the=20 > > > > discussions and create a separate thread? But for now, I > > > can see that > > > > a Diameter MIP6 application with authentication procedure > > would be > > > > consistent with the current AAA framework while a=20 > combinaison of=20 > > > > Diameter EAP and Diameter MIP6 will not meet all the AAA > > > requirements > > > > without introducing specific functionalites/enhancements. > > > >=20 > > > > I would have no problem with a solution proposing EAP > > > authentication > > > > procedures and MIP6 authorization procedures supported by > > > to different > > > > diameter applications IF it could be possible to bind both > > > procedures > > > > in the same equipment in the MSA. That is not the case with the=20 > > > > current solution. > > > >=20 > > > > BR, > > > >=20 > > > > Lionel > > > >=20 > > > > > > There is a new guy in the game ;) > > > > > >=20 > > > > > > After reviewing the draft and the mail exchange on the > > > > > topic, I would say that the conclusion on "issue/no issue"=20 > > > > > depends on the side you are considering the problem (as > > often ;). > > > > > >=20 > > > > > > If you are considering the AAA-MIP6 as a "simple" database > > > > > providing the HA with specific user/service=20 > information after a=20 > > > > > separate authentication (performed with Diameter > > > > authentication), the > > > > > username conveyed over the HA/AAA-MIP6 is just used as a > > > > key entry in > > > > > the database. There is no need for the AAA-MIP6 to > > > > authenticate this > > > > > username or to be sure that the username was previously > > > > authenticated.=20 > > > > > The client of the database is the HA and not the user. In > > > > that case, > > > > > the > > > > > AAA-MIP6 has to trust the HA and it is up to the HA to > > > authenticate > > > > > the username provided by the mn during the SA set-up.=20 > > > This could be > > > > > compared to interfaces between HSS (Home Subscriber > > > Server) and SIP > > > > > application servers defined in the 3GPP architecture, > > over which > > > > > Diameter applications are used to access database. > > > > > >=20 > > > > > > In this context, the HA may use: > > > > > > 1) the Diameter EAP application to authenticate the user. =20 > > > > > > 2) the Diameter MIP6 application to download user > > > related service > > > > > > information Authentication and authorization are performed > > > > > by the AAA-EAP. But there is no way for the AAA-EAP to > > > know what is > > > > > the service requested by the user. Successful > > > > authentication implies > > > > > implicte authorization. This is the problem with Diameter > > > > EAP as it is > > > > > not possible to route Diameter EAP request to a > > > > service-specific EAP > > > > > server. > > > > >=20 > > > > > If AAA-MIP6 provides authorizatin, AAA-EAP provides > > > authentication, > > > > > but does not provide authorization. For this purpose, the > > > > HA needs to > > > > > set Auth-Request-Type set to AUTHENTICATE_ONLY in > > > AAA-EAP. In this > > > > > case, AAA-EAP server does not need to know what kind of > > > > authorization > > > > > will be made. The authorization decision will be made by > > > AAA-MIP6. > > > > > Am I missing something? > > > > >=20 > > > > > >=20 > > > > > > In another hand, if the AAA-MIP6 is an authority handling > > > > > MIP6 service access authorization rights i.e. the AAA-MIP6 > > > > must verify > > > > > that the user is authorized to use the Mobile > > > > > IPv6 service, this authority has to be able to verify the > > > > identity of > > > > > the user before authorizing this user to access the > > > > service. It is not > > > > > possible to authorize someone to do something without > > > being sure of > > > > > its identity as the authority must stand surety of the > > > user access > > > > > rights. Now, it is not possible to rely on the Diameter EAP=20 > > > > > application to perform the authentication procedure as > > > > there is no way > > > > > to direct the Diameter EAP requests to a specifc EAP > > > server (as the > > > > > Diameter routing is based on App-Id and Realm). We might > > > > think about > > > > > some specific things to link authentication procedures and=20 > > > > > authorization/service profile handling. But for me, the > > > > simpliest way > > > > > would be to define the required authentication mechanism > > > within one > > > > > and only one application i.e. the application that > > requires this > > > > > authentication. > > > > > Therefore, Diameter EAP would not be used and > > > application-specific > > > > > commands would be specified in the application. One command > > > > pair would > > > > > be added to the Diameter > > > > > MIP6 application. And to support EAP, AVPs defined in 4072 > > > > would be at > > > > > least (re-)used. > > > > >=20 > > > > > I don't understand the difference between the two cases you > > > > mentioned > > > > > above. I believe that more or less the AAA servers need to > > > > trust the > > > > > HA in both cases. Depending on threat model which we > > > don't seem to > > > > > exactly know right now, the > > > > > AAA-MIP6 server may or may not need an evidence that the > > > > user has been > > > > > authenticated by a AAA-EAP server. > > > > >=20 > > > > > >=20 > > > > > > IMHO, the context described in the draft looks like more a > > > > > service access authorization management than the use of > > a simple > > > > > external database. I would be therefore in favor of defining=20 > > > > > authentication commands within the Diameter MIP6 > > > > application instead > > > > > of trying to reuse the Diameter EAP application, which is > > > > not possible > > > > > without modifications. EAP authentication and MIP6 > > service access > > > > > authorization are performed with the same=20 > application. Since a=20 > > > > > application-Id is whatever needed for the HA/AAA-MIP6, what > > > > would be > > > > > the benefit to look for solutions binding Diameter EAP > > > and Diameter > > > > > MIP6 (with some key derivation, etc.) while a single > > > Diameter MIP6 > > > > > application with intrinsic authentication commands > > would be fully > > > > > appropriate? > > > > >=20 > > > > > I don't understand what is the point of discussing > > > "service access > > > > > authorization management" and "simple external database".=20 > > > If MIP6 > > > > > application needs to support multiple authentication > > > > methods such as > > > > > EAP and RFC 4285, I believe it is more appropriate to=20 > consider=20 > > > > > separation of authentication and authorization if security is=20 > > > > > reasonably handled. Also, there is some authentication > > > > method (e.g., > > > > > authentication based on IKEv2-cert without using EAP) does > > > > not require > > > > > any AAA interacation for authentication. I was > > pointing this out > > > > > several times but no one seems to pay attention to it. > > > > >=20 > > > > > >=20 > > > > > > I'm pretty sure that the content of this mail may be > > > > > challenged line by line ;) But at the end, if > > authentication and > > > > > authorization are needed to provide MIP6 services, why do > > > > not having a > > > > > single application to do it? Of course, I don't say that it > > > > would not > > > > > be possible to do something more complex... > > > > >=20 > > > > > To me, discussion on coupling vs. decoupling=20 > authentication and=20 > > > > > authorization is not just a MIP6 issue. This is a=20 > fundamental=20 > > > > > discussion that will decide the future direction of AAA. > > > > >=20 > > > > > Yoshihiro Ohba > > > > >=20 > > > > > >=20 > > > > > > BR, > > > > > >=20 > > > > > > Lionel > > > > > >=20 > > > > > >=20 > > > > > > > -----Message d'origine----- > > > > > > > De : Julien Laganier [mailto:julien.IETF@laposte.net] > > > > > > > Envoy=EF=BC=9F : mardi 23 janvier 2007 10:42 > > > > > > > =EF=BC=9F : Ahmad Muhanna > > > > > > > Cc : dime@ietf.org > > > > > > > Objet : Re: [Dime] Diameter Mobile IPv6=20 > HA-to-AAAH Support:=20 > > > > > > > Issue or notIssue ? > > > > > > >=20 > > > > > > > Hi Ahmad, > > > > > > >=20 > > > > > > > Cutting a bit thru your message, I have some comments > > > > > > > below: > > > > > > >=20 > > > > > > > On Monday 22 January 2007 18:10, Ahmad Muhanna wrote: > > > > > > > > > > > > > > > > > > > > > > > >[...] > > > > > > > > > > > > > > > > [Ahmad] > > > > > > > > We are probably splitting hair here, apparently > > > there are two > > > > > > > > arguments here: > > > > > > >=20 > > > > > > > I don't think this is hair splitting. Understand the > > > > > issue should be > > > > > > > a prerequisite to solving it. > > > > > > >=20 > > > > > > > > 1. AAAz is an authorization server and since it has a > > > > security > > > > > > > > relationship with the HA, AAAz relies on the HA=20 > to do two > > > > > > > things: 1.1.=20 > > > > > > > > HA makes sure that the user has been authenticated by > > > > > AAAn. 1.2.=20 > > > > > > > > HA will not send any Authorization requests for > > any user(s) > > > > > > > who has not > > > > > > > > been authenticated. > > > > > > > > > > > > > > > > (In normal conditions, the above two conditions=20 > are ALWAYS > > > > > > > TRUE except > > > > > > > > in one condition, HA has been > > > > > > > > compromised) > > > > > > >=20 > > > > > > > Right. So we both agree there's no problem unless=20 > the HA is=20 > > > > > > > compromised > > > > > > >=20 > > > > > > > I think what the first step is to agree on a threat > > > > > model. I do not > > > > > > > agree that we should defend against a compromised HA. > > > > > > > The HA should be deemed secure against attackers. > > > > > > >=20 > > > > > > > We have to place a limit on what is entity X when > > asking the > > > > > > > question "what if entity X is compromised". > > > > > > > Since nothing is really impossible in the real world, > > > we cannot > > > > > > > defend against compromission of any entity implicated in > > > > > a protocol.=20 > > > > > > > Security is a tradeoff. > > > > > > >=20 > > > > > > > More below... > > > > > > >=20 > > > > > > > > 2. AAAz is an authorization server and has a security > > > > > > > association with > > > > > > > > the HA, however, due to the fact that the HA could be > > > > > > > compromised, a > > > > > > > > process needs to be in place for the HA to ALWAYS > > > provide the > > > > > > > > AAAz, Authorization server, with a proof (token, > > > > > > > > etc.) that the user has been authenticated by AAAn. > > > > > > >=20 > > > > > > > OK, if HA can be compromised. But why are we=20 > stopping here?=20 > > > > > > > Why not considering the case where the AAAn is=20 > compromised?=20 > > > > > > > Is is it more likely for an HA to be compromised than > > > > for a AAAn? > > > > > > >=20 > > > > > > > We really have to agree on a threat model first. > > > > > > >=20 > > > > > > > > I assume here that the difference in opinion is=20 > about the > > > > > > > possibility > > > > > > > > of the HA to be compromised or NOT. > > > > > > >=20 > > > > > > > Exactly. > > > > > > >=20 > > > > > > > Best, > > > > > > >=20 > > > > > > > --julien (L.) > > > > > > >=20 > > > > > > > _______________________________________________ > > > > > > > DiME mailing list > > > > > > > DiME@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > >=20 > > > > > > >=20 > > > > > >=20 > > > > > > _______________________________________________ > > > > > > DiME mailing list > > > > > > DiME@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > >=20 > > > > > >=20 > > > > >=20 > > > >=20 > > >=20 > >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jan 29 19:50:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBhC8-00079A-LL; Mon, 29 Jan 2007 19:49:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBhC7-000795-DJ for dime@ietf.org; Mon, 29 Jan 2007 19:49:55 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBhC6-00016R-1f for dime@ietf.org; Mon, 29 Jan 2007 19:49:55 -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 <0JCN00MQXOZ5J4@usaga01-in.huawei.com> for dime@ietf.org; Mon, 29 Jan 2007 16:49:54 -0800 (PST) Received: from huawei.com ([172.18.4.47]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCN001VPOZ58E@usaga01-in.huawei.com> for dime@ietf.org; Mon, 29 Jan 2007 16:49:53 -0800 (PST) Received: from N737011 (pool-71-112-126-182.sttlwa.dsl-w.verizon.net [71.112.126.182]) by usaml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JCN00A7HPHA8Q@usaml03-in.huawei.com> for dime@ietf.org; Mon, 29 Jan 2007 17:00:53 -0800 (PST) Date: Mon, 29 Jan 2007 16:49:49 -0800 From: Madjid Nakhjiri Subject: RE: [Dime] Supplicant X.509 AVP? In-reply-to: To: "'Morrow, Glenn'" , 'Hannes Tschofenig' Message-id: <005701c74408$8d407f70$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: Acc9i2IhUMpmDMG3TcmfC5AoU7EeSgAqjwFgAXSUe1A= X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Glenn, Hannes, In an old BoF, we presented a similar problem as "application keying", there we assumed that we already had done EAP method (e.g. EAP-TLS) but we wanted to use the keying material resulting from EAP to generate keying material for the application at hand. It seems that Glenn wants to avoid the EAP latency all together, but use Diameter as a method to help out with public key fetch. If the PKI is present to provide client certs, why not. I think exploring support for certs handling and application keying is interesting and I am interested in scenario described. R, Madjid -----Original Message----- From: Morrow, Glenn [mailto:Glenn.Morrow@qwest.com] Sent: Monday, January 22, 2007 7:36 AM To: Hannes Tschofenig Cc: dime@ietf.org Subject: RE: [Dime] Supplicant X.509 AVP? Hi Hannes, The decription on Scenario 3 is similar to what we are looking for i.e. we want to apply assymetric cryptography enabled via certs directly to the real signaling application (whatever it is) that Diameter is AAAing without the extra signaling latency overhead of an EAP-TLS server or another SA setup with a cert directory from the Diameter client or end-application itself. As a simple example, if we had a UDP application that had a client component and a network server component, We want the UDP application client to sign their packet with their private key and send the message to the network server component. We then want the Diameter client (co-resident with the network server component) to retrieve the public key from a Diameter server which then retrieves it from a cert directory or whatever PKI backend solution there is and relay it down to the Diameter client along with any additional application specific authorization information for the end-user application. The Diameter client then passes this information to the network server component of the application which then uses the public key in the public cert to check the integrity of the UDP application packet and authenticate the supplicant (end-user/device/whatever). Once authenticated the authorization policies of both the public cert and any Diameter application policies are allowed/enforced. We are quite happy with existing Diameter to Diameter server/client security and transport i.e. scenario 1. Again - we want to avoid the extra signaling latency overhead of an EAP-TLS server or another SA setup with a cert directory from the Diameter client or end-application itself. Passing the public cert down is far more efficient and greatly improves the application setup delay. Please let me know if this clarifies the terminology and what we are looking for. Thanks, Glenn This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. _______________________________________________ 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 Jan 29 22:44:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBjvU-0005HN-ME; Mon, 29 Jan 2007 22:44:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBjvT-0005Gq-5H for dime@ietf.org; Mon, 29 Jan 2007 22:44:55 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBjvR-0002Fh-M2 for dime@ietf.org; Mon, 29 Jan 2007 22:44:55 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 29 Jan 2007 19:44:53 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l0U3ior4002206; Mon, 29 Jan 2007 19:44:50 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0U3innF016650; Mon, 29 Jan 2007 19:44:49 -0800 (PST) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jan 2007 19:44:49 -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] Supplicant X.509 AVP? Date: Mon, 29 Jan 2007 19:44:48 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262503512400@xmb-sjc-215.amer.cisco.com> In-Reply-To: <005701c74408$8d407f70$2f01a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Supplicant X.509 AVP? Thread-Index: Acc9i2IhUMpmDMG3TcmfC5AoU7EeSgAqjwFgAXSUe1AABgIAUA== References: <005701c74408$8d407f70$2f01a8c0@china.huawei.com> From: "Glen Zorn \(gwz\)" To: "Madjid Nakhjiri" , "Morrow, Glenn" , "Hannes Tschofenig" X-OriginalArrivalTime: 30 Jan 2007 03:44:49.0471 (UTC) FILETIME=[FE04ACF0:01C74420] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4101; t=1170128690; x=1170992690; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[Dime]=20Supplicant=20X.509=20AVP? |Sender:=20; bh=adwbcfiFPv/QgZvWC2cOZj9IUpUrl5MjnzSiUvw2Ues=; b=Ub4oxFFLZl3OTqb9+H9QMlY9/LPwjZXRMsW+kfwxQ6XngbuoO09DD1dVZlLS+91IRf7w7W5w i233icm+tB96ArfTKUsaOuem2lEbaWOFlkZJ9Rglq1vUDXpzVbt0WdIA; Authentication-Results: sj-dkim-6; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 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 Madjid Nakhjiri allegedly scribbled on Monday, January 29, 2007 4:50 PM: > Hi Glenn, Hannes, >=20 > In an old BoF, we presented a similar problem as "application > keying", there we assumed that we already had done EAP method (e.g. > EAP-TLS) but we wanted to use the keying material resulting from EAP > to generate keying material for the application at hand. It seems > that Glenn wants to avoid the EAP latency all together, but use > Diameter as a method to help out with public key fetch. If the PKI is > present to provide client certs What is meant by "client" here? > , why not. =20 Depends to a large extent upon the answer to my question above, IMHO. More comments below. =20 >=20 > I think exploring support for certs handling and application keying > is interesting and I am interested in scenario described.=20 >=20 > R, >=20 > Madjid >=20 > -----Original Message----- > From: Morrow, Glenn [mailto:Glenn.Morrow@qwest.com] > Sent: Monday, January 22, 2007 7:36 AM > To: Hannes Tschofenig > Cc: dime@ietf.org > Subject: RE: [Dime] Supplicant X.509 AVP? >=20 >=20 > Hi Hannes, >=20 > The decription on Scenario 3 is similar to what we are looking for > i.e.=20 > we want to apply assymetric cryptography enabled via certs directly to > the real signaling application (whatever it is) that Diameter is > AAAing=20 > without the extra signaling latency overhead of an EAP-TLS server or > another SA setup with a cert directory from the Diameter client or > end-application itself. >=20 > As a simple example, if we had a UDP application that had a client > component and a network server component, We want the UDP application > client to sign their packet with their private key and send the > message=20 > to the network server component. >=20 > We then want the Diameter client (co-resident with the network server > component) to retrieve the public key from a Diameter server which > then=20 > retrieves it from a cert directory or whatever PKI backend solution > there is and relay it down to the Diameter client along with any > additional application specific authorization information for the > end-user application. >=20 > The Diameter client then passes this information to the network server > component of the application which then uses the public key in the > public cert to check the integrity of the UDP application packet and > authenticate the supplicant (end-user/device/whatever). Once > authenticated the authorization policies of both the public cert and > any=20 > Diameter application policies are allowed/enforced. How do you authenticate a supplicant using the cert for an app client? >=20 > We are quite happy with existing Diameter to Diameter server/client > security and transport i.e. scenario 1. That's too bad, since the existing Diameter security is little better than that of RADIUS (in the best case). >=20 > Again - we want to avoid the extra signaling latency overhead of an > EAP-TLS server or another SA setup with a cert directory from the > Diameter client or end-application itself. Passing the public cert > down=20 > is far more efficient and greatly improves the application setup > delay.=20 >=20 > Please let me know if this clarifies the terminology and what we are > looking for. >=20 > Thanks, >=20 > Glenn >=20 >=20 > This communication is the property of Qwest and may contain > confidential or=20 > privileged information. Unauthorized use of this communication is > strictly=20 > prohibited and may be unlawful. If you have received this > communication=20 > in error, please immediately notify the sender by reply e-mail and > destroy=20 > all copies of the communication and any attachments. >=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 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jan 30 11:33:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBvue-00012J-Vc; Tue, 30 Jan 2007 11:32:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBvud-000122-DW for dime@ietf.org; Tue, 30 Jan 2007 11:32:51 -0500 Received: from uswgne22.uswest.com ([204.26.87.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBvua-0003Gl-Am for dime@ietf.org; Tue, 30 Jan 2007 11:32:51 -0500 Received: from egate-ne8.uswc.uswest.com (egate-ne8.uswc.uswest.com [151.117.69.22]) by uswgne22.uswest.com (8/8) with ESMTP id l0UGWYG1003501; Tue, 30 Jan 2007 10:32:35 -0600 (CST) Received: from itomae2ksm02.AD.QINTRA.COM (localhost [127.0.0.1]) by egate-ne8.uswc.uswest.com (8/8.13.7) with ESMTP id l0UGWQVC012178; Tue, 30 Jan 2007 10:32:34 -0600 (CST) Received: from itomae2km03.AD.QINTRA.COM ([10.6.9.152]) by itomae2ksm02.AD.QINTRA.COM with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 10:32:33 -0600 X-MessageTextProcessor: DisclaimIt (2.70.270) [Qwest Communications International Inc.] X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 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] Supplicant X.509 AVP? Date: Tue, 30 Jan 2007 10:32:32 -0600 Message-ID: In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB262503512400@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Supplicant X.509 AVP? thread-index: Acc9i2IhUMpmDMG3TcmfC5AoU7EeSgAqjwFgAXSUe1AABgIAUAAZZJIw From: "Morrow, Glenn" Importance: normal Priority: normal To: "Glen Zorn \(gwz\)" , "Madjid Nakhjiri" , "Hannes Tschofenig" X-OriginalArrivalTime: 30 Jan 2007 16:32:33.0819 (UTC) FILETIME=[3E825EB0:01C7448C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Inline GM> -----Original Message----- From: Glen Zorn (gwz) [mailto:gwz@cisco.com]=20 Sent: Monday, January 29, 2007 8:45 PM To: Madjid Nakhjiri; Morrow, Glenn; Hannes Tschofenig Cc: dime@ietf.org Subject: RE: [Dime] Supplicant X.509 AVP? Madjid Nakhjiri allegedly scribbled on Monday, January 29, 2007 4:50 PM: > Hi Glenn, Hannes, >=20 > In an old BoF, we presented a similar problem as "application keying", > there we assumed that we already had done EAP method (e.g. > EAP-TLS) but we wanted to use the keying material resulting from EAP=20 > to generate keying material for the application at hand. It seems that > Glenn wants to avoid the EAP latency all together, but use Diameter as > a method to help out with public key fetch. If the PKI is present to=20 > provide client certs What is meant by "client" here? GM> Madjid knows for sure but I believe he meant the end-application client. I.e. not the diameter client. > , why not. Depends to a large extent upon the answer to my question above, IMHO. More comments below. =20 >=20 > I think exploring support for certs handling and application keying is > interesting and I am interested in scenario described. >=20 > R, >=20 > Madjid >=20 > -----Original Message----- > From: Morrow, Glenn [mailto:Glenn.Morrow@qwest.com] > Sent: Monday, January 22, 2007 7:36 AM > To: Hannes Tschofenig > Cc: dime@ietf.org > Subject: RE: [Dime] Supplicant X.509 AVP? >=20 >=20 > Hi Hannes, >=20 > The decription on Scenario 3 is similar to what we are looking for=20 > i.e. we want to apply assymetric cryptography enabled via certs=20 > directly to the real signaling application (whatever it is) that=20 > Diameter is AAAing > without the extra signaling latency overhead of an EAP-TLS server or > another SA setup with a cert directory from the Diameter client or > end-application itself. >=20 > As a simple example, if we had a UDP application that had a client=20 > component and a network server component, We want the UDP application=20 > client to sign their packet with their private key and send the=20 > message to the network server component. >=20 > We then want the Diameter client (co-resident with the network server > component) to retrieve the public key from a Diameter server which=20 > then retrieves it from a cert directory or whatever PKI backend=20 > solution there is and relay it down to the Diameter client along with=20 > any additional application specific authorization information for the > end-user application. >=20 > The Diameter client then passes this information to the network server > component of the application which then uses the public key in the=20 > public cert to check the integrity of the UDP application packet and=20 > authenticate the supplicant (end-user/device/whatever). Once=20 > authenticated the authorization policies of both the public cert and=20 > any Diameter application policies are allowed/enforced. How do you authenticate a supplicant using the cert for an app client? GM> Digital Signatures, encrypted confidential fields, Message Hashes with Salt and Nonce material using the public and private keys instead of symmetric keys. The public cert chains (for the application servers) are either predistributed or retrieved once from a secured directory and cached in a ring as needed.=20 >=20 > We are quite happy with existing Diameter to Diameter server/client=20 > security and transport i.e. scenario 1. That's too bad, since the existing Diameter security is little better than that of RADIUS (in the best case). GM> Please discuss more or do an ID or point to a URL/Wiki with a list of what needs to change? >=20 > Again - we want to avoid the extra signaling latency overhead of an=20 > EAP-TLS server or another SA setup with a cert directory from the=20 > Diameter client or end-application itself. Passing the public cert=20 > down is far more efficient and greatly improves the application setup > delay.=20 >=20 > Please let me know if this clarifies the terminology and what we are=20 > looking for. >=20 > Thanks, >=20 > Glenn >=20 >=20 > This communication is the property of Qwest and may contain=20 > confidential or privileged information. Unauthorized use of this=20 > communication is strictly > prohibited and may be unlawful. If you have received this > communication=20 > in error, please immediately notify the sender by reply e-mail and > destroy=20 > all copies of the communication and any attachments. >=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 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jan 30 11:54:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwFV-0003vh-DI; Tue, 30 Jan 2007 11:54:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwFU-0003vb-V6 for dime@ietf.org; Tue, 30 Jan 2007 11:54:24 -0500 Received: from rvil-eframer.radvision.com ([80.74.106.104] helo=eframer.radvision.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBwFR-0007Y9-7J for dime@ietf.org; Tue, 30 Jan 2007 11:54:24 -0500 Received: (from root@localhost) by eframer.radvision.com (8.13.4/8.12.9) id l0UGx7fd007250 for dime@ietf.org; Tue, 30 Jan 2007 18:59:07 +0200 Received: from rvil-mail1.RADVISION.com (rvil-mail1.radvision.com [172.20.2.100]) by eframer.radvision.com (8.13.4/8.12.9) with ESMTP id l0UGx7PI007244 for ; Tue, 30 Jan 2007 18:59:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 30 Jan 2007 18:56:27 +0200 Message-ID: <7579E2B4F92E89429C01EA57E4E6DBBB6AD141@rvil-mail1.RADVISION.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Host-IP-Address and port Thread-Index: AcdEj5UaRCx2Nr+CRd6WBK6e4niLVA== From: "Ran Arad" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [Dime] Host-IP-Address and port 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="===============0290653587==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0290653587== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7448F.94CE7081" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7448F.94CE7081 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R29vZCBEYXkNCiANCkkgaGF2ZSBtZW50aW9uZWQgYSBwcm9ibGVtIEkgaGFkIHdpdGggdGhlIEFk ZHJlc3MgQVZQIHR5cGU6IGl0IGNvbnRhaW5zIHRoZSBhZGRyZXNzIHR5cGUgKElQIG9yIElQNikg YW5kIHRoZSBhZGRyZXNzIGl0c2VsZiwgd2l0aG91dCBhIHBvcnQgb3IgdHJhbnNwb3J0IHR5cGUg KFNDVFAsIFRMUykuIEkgY29uc2lkZXJlZCB0aGUgcG9zc2liaWxpdHkgb2YgYWRkaW5nIHR3byBt b3JlIGJ5dGVzIGFmdGVyIHRoZSBhZGRyZXNzIHRvIGluZGljYXRlIHRoZSBwb3J0IHVzZWQuIEkg dW5kZXJzdGFuZCB0aGF0IHRoaXMgd2lsbCBvbmx5IHdvcmsgYmV0d2VlbiBvdXIgb3duIGltcGxl bWVudGF0aW9ucyAodW5sZXNzIGFkZGVkIHRvIHRoZSBSRkMpLCBidXQgdGhhbiBhZ2Fpbiwgc28g d291bGQgdmVuZG9yIHNwZWNpZmljIEFWUHMuIHRoZSBxdWVzdGlvbiBpczogQ291bGQgdGhpcyBj YXVzZSBwcm9ibGVtcyB3aXRoIGRlY29kZXJzIHdoaWNoIGV4cGVjdCB0aGUgYWRkcmVzcyBBVlAg dG8gaGF2ZSBvbmUgb2YgdHdvIHBvc3NpYmxlIHNpemVzPw0KIA0KVGhhbmsgeW91DQpSYW4NCg== ------_=_NextPart_001_01C7448F.94CE7081 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI5MDAuMzAyMCIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElWPjxGT05U IGZhY2U9QXJpYWw+PEZPTlQgc2l6ZT0yPkdvb2QgRGF5PEJSPiZuYnNwOzxCUj5JIGhhdmUmbmJz cDs8U1BBTiANCmNsYXNzPTI0MzE1NTAxNi0zMDAxMjAwNz5tZW50aW9uZWQgYSBwcm9ibGVtIEkg aGFkIHdpdGggdGhlJm5ic3A7PC9TUEFOPkFkZHJlc3MgDQpBVlAgdHlwZTogaXQgY29udGFpbnMg dGhlIGFkZHJlc3MgdHlwZSAoSVAgb3IgSVA2KSBhbmQgdGhlIGFkZHJlc3MgaXRzZWxmLCANCndp dGhvdXQgYSBwb3J0IG9yIHRyYW5zcG9ydCB0eXBlIChTQ1RQLCBUTFMpLjxTUEFOIGNsYXNzPTI0 MzE1NTAxNi0zMDAxMjAwNz4gDQo8L1NQQU4+PFNQQU4gY2xhc3M9MjQzMTU1MDE2LTMwMDEyMDA3 PkkgY29uc2lkZXJlZCB0aGUgcG9zc2liaWxpdHkgb2YgYWRkaW5nIHR3byANCm1vcmUgYnl0ZXMg YWZ0ZXIgdGhlIGFkZHJlc3MgdG8gaW5kaWNhdGUgdGhlIHBvcnQgdXNlZC4gSSB1bmRlcnN0YW5k IHRoYXQgdGhpcyANCndpbGwgb25seSB3b3JrIGJldHdlZW4gb3VyIG93biBpbXBsZW1lbnRhdGlv bnMgKHVubGVzcyBhZGRlZCB0byB0aGUgUkZDKSwgYnV0IA0KdGhhbiBhZ2Fpbiwgc28gd291bGQg dmVuZG9yIHNwZWNpZmljIEFWUHMuIHRoZSBxdWVzdGlvbiBpczogQ291bGQgdGhpcyBjYXVzZSAN CnByb2JsZW1zIHdpdGggZGVjb2RlcnMgd2hpY2ggZXhwZWN0IHRoZSBhZGRyZXNzIEFWUCB0byBo YXZlIG9uZSBvZiB0d28gcG9zc2libGUgDQpzaXplcz88L1NQQU4+PC9GT05UPjwvRk9OVD48L0RJ Vj4NCjxESVY+PFNQQU4gY2xhc3M9MjQzMTU1MDE2LTMwMDEyMDA3PjxGT05UIGZhY2U9QXJpYWwg c2l6ZT0yPjwvRk9OVD48L1NQQU4+PEZPTlQgDQpmYWNlPUFyaWFsIHNpemU9Mj48L0ZPTlQ+Jm5i c3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTI0MzE1NTAxNi0zMDAxMjAwNz48Rk9OVCBmYWNl PUFyaWFsIHNpemU9Mj5UaGFuayANCnlvdTwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFO IGNsYXNzPTI0MzE1NTAxNi0zMDAxMjAwNz48Rk9OVCBmYWNlPUFyaWFsIA0Kc2l6ZT0yPlJhbjwv Rk9OVD48L1NQQU4+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------_=_NextPart_001_01C7448F.94CE7081-- --===============0290653587== 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 --===============0290653587==-- From dime-bounces@ietf.org Tue Jan 30 12:29:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwn5-0005In-CC; Tue, 30 Jan 2007 12:29:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwn4-0005Gr-Jz for dime@ietf.org; Tue, 30 Jan 2007 12:29:06 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HBwn3-0000qp-4p for dime@ietf.org; Tue, 30 Jan 2007 12:29:06 -0500 Received: (qmail invoked by alias); 30 Jan 2007 17:29:03 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp025) with SMTP; 30 Jan 2007 18:29:03 +0100 X-Authenticated: #29516787 Message-ID: <45BF805A.7020906@gmx.net> Date: Tue, 30 Jan 2007 12:28:58 -0500 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) 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: 00e94c813bef7832af255170dca19e36 Subject: [Dime] [Fwd: REVISED ANNOUNCEMENT Protocol Action: 'RADIUS Filter Rule Attribute' to Proposed Standard] 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 FYI -------- Original Message -------- Subject: REVISED ANNOUNCEMENT Protocol Action: 'RADIUS Filter Rule Attribute' to Proposed Standard Date: Tue, 30 Jan 2007 12:07:16 -0500 From: The IESG To: IETF-Announce CC: Internet Architecture Board , RFC Editor , radext mailing list , radext chair The IESG has approved the following document: - 'RADIUS Filter Rule Attribute ' as a Proposed Standard This document is the product of the RADIUS EXTensions Working Group. The IESG contact persons are David Kessens and Dan Romascanu. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-08.txt Technical Summary While RFC 2865 defines the Filter-Id attribute, this requires that the Network Access Server (NAS) be pre-populated with the desired filters. However, in situations where the server operator does not know which filters have been pre-populated, it useful to specify filter rules explicitly. This document defines the NAS-Filter-Rule attribute within the Remote Authentication Dial In User Service (RADIUS). This attribute is based on the Diameter NAS-Filter-Rule Attribute Value Pair (AVP) described in RFC 4005, and the IPFilterRule syntax defined in RFC 3588. Working Group Summary This document is a product of the radext working group. Protocol Quality David Kessens has reviewed this document for the IESG. Note to RFC Editor In '1. Introduction': OLD: However, in situations where the server operator does not know which filters have been pre-populated, it useful to specify filter rules explicitly. NEW: However, in situations where the server operator does not know which filters have been pre-populated, it is useful to specify filter rules explicitly. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jan 30 13:50:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBy3N-0003Kp-Jo; Tue, 30 Jan 2007 13:50:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBy3L-0003K4-4z for dime@ietf.org; Tue, 30 Jan 2007 13:49:59 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBy3J-0000Fk-Lr for dime@ietf.org; Tue, 30 Jan 2007 13:49:59 -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 <0JCP00CT62Z9JV@usaga01-in.huawei.com> for dime@ietf.org; Tue, 30 Jan 2007 10:49:57 -0800 (PST) Received: from huawei.com ([172.18.4.47]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCP00I7B2Z6PW@usaga01-in.huawei.com> for dime@ietf.org; Tue, 30 Jan 2007 10:49:57 -0800 (PST) Received: from N737011 (pool-71-112-126-182.sttlwa.dsl-w.verizon.net [71.112.126.182]) by usaml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JCP00A4W3HFDD@usaml03-in.huawei.com> for dime@ietf.org; Tue, 30 Jan 2007 11:00:56 -0800 (PST) Date: Tue, 30 Jan 2007 10:49:54 -0800 From: Madjid Nakhjiri Subject: RE: [Dime] Supplicant X.509 AVP? In-reply-to: <4C0FAAC489C8B74F96BEAD85EAEB262503512400@xmb-sjc-215.amer.cisco.com> To: "'Glen Zorn (gwz)'" , "'Morrow, Glenn'" , 'Hannes Tschofenig' Message-id: <01b301c7449f$6f853c40$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: Acc9i2IhUMpmDMG3TcmfC5AoU7EeSgAqjwFgAXSUe1AABgIAUAAfgEaw X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Glen, I picked the term "client" off Glenn's description: " As a simple example, if we had a UDP application that had a client > component and a network server component,..." Glenn assumes there is a application server and an application client. The app client signs a message/request with a private key. He wants to use Diameter infrastructure to help the application server (a network service equipment) to get a public key and verify the signature. This is architecture I see: Client------>Net server------Diameter------------>Diameter app app Client server <------ <------ ^ | | V X.501 directory Seems like a Diameter based cert status checking mechanism.. R, Madjid -----Original Message----- From: Glen Zorn (gwz) [mailto:gwz@cisco.com] Sent: Monday, January 29, 2007 7:45 PM To: Madjid Nakhjiri; Morrow, Glenn; Hannes Tschofenig Cc: dime@ietf.org Subject: RE: [Dime] Supplicant X.509 AVP? Madjid Nakhjiri allegedly scribbled on Monday, January 29, 2007 4:50 PM: > Hi Glenn, Hannes, > > In an old BoF, we presented a similar problem as "application > keying", there we assumed that we already had done EAP method (e.g. > EAP-TLS) but we wanted to use the keying material resulting from EAP > to generate keying material for the application at hand. It seems > that Glenn wants to avoid the EAP latency all together, but use > Diameter as a method to help out with public key fetch. If the PKI is > present to provide client certs What is meant by "client" here? > , why not. Depends to a large extent upon the answer to my question above, IMHO. More comments below. > > I think exploring support for certs handling and application keying > is interesting and I am interested in scenario described. > > R, > > Madjid > > -----Original Message----- > From: Morrow, Glenn [mailto:Glenn.Morrow@qwest.com] > Sent: Monday, January 22, 2007 7:36 AM > To: Hannes Tschofenig > Cc: dime@ietf.org > Subject: RE: [Dime] Supplicant X.509 AVP? > > > Hi Hannes, > > The decription on Scenario 3 is similar to what we are looking for > i.e. > we want to apply assymetric cryptography enabled via certs directly to > the real signaling application (whatever it is) that Diameter is > AAAing > without the extra signaling latency overhead of an EAP-TLS server or > another SA setup with a cert directory from the Diameter client or > end-application itself. > > As a simple example, if we had a UDP application that had a client > component and a network server component, We want the UDP application > client to sign their packet with their private key and send the > message > to the network server component. > > We then want the Diameter client (co-resident with the network server > component) to retrieve the public key from a Diameter server which > then > retrieves it from a cert directory or whatever PKI backend solution > there is and relay it down to the Diameter client along with any > additional application specific authorization information for the > end-user application. > > The Diameter client then passes this information to the network server > component of the application which then uses the public key in the > public cert to check the integrity of the UDP application packet and > authenticate the supplicant (end-user/device/whatever). Once > authenticated the authorization policies of both the public cert and > any > Diameter application policies are allowed/enforced. How do you authenticate a supplicant using the cert for an app client? > > We are quite happy with existing Diameter to Diameter server/client > security and transport i.e. scenario 1. That's too bad, since the existing Diameter security is little better than that of RADIUS (in the best case). > > Again - we want to avoid the extra signaling latency overhead of an > EAP-TLS server or another SA setup with a cert directory from the > Diameter client or end-application itself. Passing the public cert > down > is far more efficient and greatly improves the application setup > delay. > > Please let me know if this clarifies the terminology and what we are > looking for. > > Thanks, > > Glenn > > > This communication is the property of Qwest and may contain > confidential or > privileged information. Unauthorized use of this communication is > strictly > prohibited and may be unlawful. If you have received this > communication > in error, please immediately notify the sender by reply e-mail and > destroy > all copies of the communication and any attachments. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jan 30 16:24:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC0SI-0006Wt-98; Tue, 30 Jan 2007 16:23:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC0SH-0006Wn-6G for dime@ietf.org; Tue, 30 Jan 2007 16:23:53 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC0SE-0004Mv-Rv for dime@ietf.org; Tue, 30 Jan 2007 16:23:53 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 30 Jan 2007 13:23:50 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l0ULNnVK031032; Tue, 30 Jan 2007 13:23:49 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0ULNnnF026365; Tue, 30 Jan 2007 13:23:49 -0800 (PST) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 13:23:44 -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] Supplicant X.509 AVP? Date: Tue, 30 Jan 2007 13:23:42 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250357079A@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Supplicant X.509 AVP? Thread-Index: Acc9i2IhUMpmDMG3TcmfC5AoU7EeSgAqjwFgAXSUe1AABgIAUAAZZJIwAAsRugA= References: <4C0FAAC489C8B74F96BEAD85EAEB262503512400@xmb-sjc-215.amer.cisco.com> From: "Glen Zorn \(gwz\)" To: "Morrow, Glenn" X-OriginalArrivalTime: 30 Jan 2007 21:23:44.0135 (UTC) FILETIME=[EBA10970:01C744B4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2220; t=1170192229; x=1171056229; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[Dime]=20Supplicant=20X.509=20AVP? |Sender:=20; bh=BI3rH40IrzD+5irVfkT15gsR77ULSGITwfNlqqLRciQ=; b=Fwi5vU7sUZCH0WCLRwLnH2fn90hYhmMGoxjRQ+2+VaTaC5maTxLo3+3KBoT/DsUcrhWPdjta B9hTuzQLiQ6+8AQX9a0jEJAKrJ5/9NtB53k+/ZSGvp0hPf74j8BNQRnl; Authentication-Results: sj-dkim-8; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 Morrow, Glenn allegedly scribbled on Tuesday, January 30, 2007 8:33 AM: ... >=20 > How do you authenticate a supplicant using the cert for an app client? >=20 >> Digital Signatures, encrypted confidential fields, Message Hashes > with Salt and Nonce material using the public and private keys instead > of symmetric keys. The public cert chains (for the application > servers)=20 > are either predistributed or retrieved once from a secured directory > and=20 > cached in a ring as needed. >=20 Supplicant !=3D app client (at least in any architecture of which I'm aware). Diameter facilitates the authentication & authorization of users, not random pieces of software. BTW, I am aware of methods for X.509-based authentication, thanks -- my question was WRT identities, not methods. >=20 >=20 >>=20 >> We are quite happy with existing Diameter to Diameter server/client >> security and transport i.e. scenario 1. >=20 > That's too bad, since the existing Diameter security is little better > than that of RADIUS (in the best case). >=20 >> Please discuss more or do an ID or point to a URL/Wiki with a list >> of what needs to change?=20 There are two methods stipulated for the cryptographic protection of Diameter messages: IPsec & TLS. Both are hop-by-hop only, just like RADIUS (despite the nonsense about redirection in RFC 4072). Furthermore, IPsec only authenticates IP addresses, not software entities, making it actually less secure than the RADIUS method (which at least can authenticate the RADIUS client to the RADIUS server instead of the boxes upon which the software components happen to be running. >=20 >=20 >>=20 >> Again - we want to avoid the extra signaling latency overhead of an >> EAP-TLS server or another SA setup with a cert directory from the >> Diameter client or end-application itself. Passing the public cert >> down is far more efficient and greatly improves the application >> setup delay.=20 >>=20 >> Please let me know if this clarifies the terminology and what we are >> looking for.=20 Not really, or maybe I'm just dense. What or whom, exactly is being authenticated here? ... _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jan 30 16:56:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC0xi-0006Gi-PT; Tue, 30 Jan 2007 16:56:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC0xh-0006Gb-Kg for dime@ietf.org; Tue, 30 Jan 2007 16:56:21 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC0xg-0001Fh-AJ for dime@ietf.org; Tue, 30 Jan 2007 16:56:21 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 30 Jan 2007 13:56:19 -0800 X-IronPort-AV: i="4.13,259,1167638400"; d="scan'208"; a="384064583:sNHT46476620" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l0ULuJUf013715; Tue, 30 Jan 2007 13:56:19 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0ULuAhw013054; Tue, 30 Jan 2007 13:56:19 -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); Tue, 30 Jan 2007 13:56:13 -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] Supplicant X.509 AVP? Date: Tue, 30 Jan 2007 13:56:12 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625035707E9@xmb-sjc-215.amer.cisco.com> In-Reply-To: <01b301c7449f$6f853c40$2f01a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Supplicant X.509 AVP? Thread-Index: Acc9i2IhUMpmDMG3TcmfC5AoU7EeSgAqjwFgAXSUe1AABgIAUAAfgEawAAbK7EA= References: <4C0FAAC489C8B74F96BEAD85EAEB262503512400@xmb-sjc-215.amer.cisco.com> <01b301c7449f$6f853c40$2f01a8c0@china.huawei.com> From: "Glen Zorn \(gwz\)" To: "Madjid Nakhjiri" X-OriginalArrivalTime: 30 Jan 2007 21:56:13.0814 (UTC) FILETIME=[75BA7160:01C744B9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1057; t=1170194179; x=1171058179; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[Dime]=20Supplicant=20X.509=20AVP? |Sender:=20; bh=Cm43n8yqtWC9vEIH4Qcq+G7EFHs1wvg6A/XXdvT0OhM=; b=gc1/jT11zv7+B4EVV2MGqkoI/OXm9PUq7dsa6PWJjooLQ5UqCsy0ldrjpIaiAd3PmMy+ox2H sGAUUJlXXS7DgfOOMDW0m77CQuSCZMb8pF6JaLw0VOdenWz3c9620gSd; Authentication-Results: sj-dkim-7; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: "Morrow, Glenn" , 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 Madjid Nakhjiri allegedly scribbled on Tuesday, January 30, 2007 10:50 AM: > Glen, >=20 > I picked the term "client" off Glenn's description: >=20 > " As a simple example, if we had a UDP application that had a client >> component and a network server component,..." >=20 > Glenn assumes there is a application server and an application client. > The app client signs a message/request with a private key. > He wants to use Diameter infrastructure to help the application > server (a network service equipment) to get a public key and verify > the signature. This is architecture I see:=20 >=20 >=20 > Client------>Net server------Diameter------------>Diameter > app app Client server > <------ <------ ^ | > | V > X.501 > directory >=20 > Seems like a Diameter based cert status checking mechanism.. Hmm -- that's not what I'm getting at all, but if you're right it seems like there are already at least a couple of other standard protocols that do this... ... _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jan 30 18:52:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC2m4-0003tH-Nm; Tue, 30 Jan 2007 18:52:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC2m3-0003tB-N7 for dime@ietf.org; Tue, 30 Jan 2007 18:52:27 -0500 Received: from uswgco34.uswest.com ([199.168.32.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC2m2-0003Wn-9K for dime@ietf.org; Tue, 30 Jan 2007 18:52:27 -0500 Received: from egate-co7.uswc.uswest.com (egate-co7.uswc.uswest.com [151.119.87.234]) by uswgco34.uswest.com (8/8) with ESMTP id l0UNq7RJ024715; Tue, 30 Jan 2007 16:52:08 -0700 (MST) Received: from itomae2ksm01.AD.QINTRA.COM (localhost [127.0.0.1]) by egate-co7.uswc.uswest.com (8/8.13.7) with ESMTP id l0UNq1aJ014867; Tue, 30 Jan 2007 16:52:07 -0700 (MST) Received: from itomae2km03.AD.QINTRA.COM ([10.6.9.152]) by itomae2ksm01.AD.QINTRA.COM with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 17:52:04 -0600 X-MessageTextProcessor: DisclaimIt (2.70.270) [Qwest Communications International Inc.] X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 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] Supplicant X.509 AVP? Date: Tue, 30 Jan 2007 17:52:03 -0600 Message-ID: In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB26250357079A@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Supplicant X.509 AVP? thread-index: Acc9i2IhUMpmDMG3TcmfC5AoU7EeSgAqjwFgAXSUe1AABgIAUAAZZJIwAAsRugAAAWb+kA== Importance: normal Priority: normal From: "Morrow, Glenn" To: "Glen Zorn \(gwz\)" X-OriginalArrivalTime: 30 Jan 2007 23:52:04.0983 (UTC) FILETIME=[A4F2A870:01C744C9] X-Spam-Score: 0.0 (/) 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 Morrow, Glenn allegedly scribbled on Tuesday, January 30, 2007 8:33 AM: ... Quite true - perhaps we can work together on the baby steps necessary to at least get rid of the alleged. Not sure what we can do about the scribbles though :) >=20 > How do you authenticate a supplicant using the cert for an app client? >=20 >> Digital Signatures, encrypted confidential fields, Message Hashes > with Salt and Nonce material using the public and private keys instead > of symmetric keys. The public cert chains (for the application > servers) > are either predistributed or retrieved once from a secured directory > and=20 > cached in a ring as needed. >=20 Supplicant !=3D app client (at least in any architecture of which I'm aware). GM> I am thinking that "access" is one such "application" or "service" if you will? If access is the application does supplicant=3Dapp client then? If supplicant is the wrong term. What shall we use as the correct term to represent the entity being AAA'd for all such services or applications which can be AAA'd? I am certainly open to a new term. I am happy with "application client" as the terminology as long as "access" is an application whereby the certificate can be used. I don't care what we call it just as long as we know what it is. Pick a term and let's just use it. Diameter facilitates the authentication & authorization of users, not random pieces of software. GM> Not sure how to respond to this other than to attempt to re-scribble :) it to say," AAA protocols facilitate the AAAing of users to use services and perhaps it might be odd that quite often these services are actually implemented using seemingly random pieces of software." :) BTW, I am aware of methods for X.509-based authentication, thanks -- my question was WRT identities, not methods. GM> Sorry about my interpretation of the question. Did not mean to insult you. You are definitely not someone I'd like to have on my bad side :) GM> As far as entities go. I see the advantage of using certs on the applications or services if you will, themselves, to be that the applications can include extra fields such as: user and device and subscriber id, "random software or protected memory" :) checksum hashes, account ids etc... instead of just relying on a transport or can'd authentication-only security mechanism such as EAP or TLS or IPSEC. I suppose it is this random software through OS protected memories, password protected dongles or other external devices, etc.. with physical and software protections in place to attempt to protect the credentials contained in the certificates with the credentials being used for the application. ACLs and security policy can be used to enhance transport solutions in an infrastructure solution i.e. a bunch of static servers deployed statically by a provider of some sort. Even with ACLs and policy, the security is still limited for transport only solutions and your points below about Diameter, itself, are exactly why EAP and TLS/IPSEC don't fix the wagon by themselves. Simple transport only ACLs and Policies fail completely when applied to a roaming user which may be on a plethora of devices using different OSs and different credential systems, etc.. - much less trying to do single sign on in a federated service environment. GM> Sorry the scribble ramble there. Answer is user/device and/or both depends on the application and the application should define this. >=20 >=20 >>=20 >> We are quite happy with existing Diameter to Diameter server/client=20 >> security and transport i.e. scenario 1. >=20 > That's too bad, since the existing Diameter security is little better=20 > than that of RADIUS (in the best case). >=20 >> Please discuss more or do an ID or point to a URL/Wiki with a list of >> what needs to change? There are two methods stipulated for the cryptographic protection of Diameter messages: IPsec & TLS. Both are hop-by-hop only, just like RADIUS (despite the nonsense about redirection in RFC 4072). Furthermore, IPsec only authenticates IP addresses, not software entities, making it actually less secure than the RADIUS method (which at least can authenticate the RADIUS client to the RADIUS server instead of the boxes upon which the software components happen to be running. GM > Agreed - I could discuss ACLs and policy in an infrastructure environment but you are right in that there is room for considerable improvement. E.g. we could add a digest to Diameter as well? I am not apposed to this as long as the keying material for the digests are derived from an initial transacation utilizing asymmetric keys and all subsequent server to server communication can be encrypted.=20 >=20 >=20 >>=20 >> Again - we want to avoid the extra signaling latency overhead of an=20 >> EAP-TLS server or another SA setup with a cert directory from the=20 >> Diameter client or end-application itself. Passing the public cert=20 >> down is far more efficient and greatly improves the application setup >> delay. >>=20 >> Please let me know if this clarifies the terminology and what we are=20 >> looking for. Not really, or maybe I'm just dense. What or whom, exactly is being authenticated here? GM> Believe me - you are not dense. The user, device or both simultaneously depending on the nature of the service or application being AAA'd. ... This communication is the property of Qwest and may contain confidential = or privileged information. Unauthorized use of this communication is = strictly=20 prohibited and may be unlawful. If you have received this communication = in error, please immediately notify the sender by reply e-mail and = destroy=20 all copies of the communication and any attachments. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jan 30 19:49:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC3f5-0007PZ-Hr; Tue, 30 Jan 2007 19:49:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC3f3-0007PT-QL for dime@ietf.org; Tue, 30 Jan 2007 19:49:17 -0500 Received: from uswgne22.uswest.com ([204.26.87.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC3f2-0003Mu-Hh for dime@ietf.org; Tue, 30 Jan 2007 19:49:17 -0500 Received: from egate-co5.uswc.uswest.com (egate-co5.uswc.uswest.com [151.119.87.232]) by uswgne22.uswest.com (8/8) with ESMTP id l0V0mvTF011470; Tue, 30 Jan 2007 18:48:57 -0600 (CST) Received: from itomae2ksm01.AD.QINTRA.COM (localhost [127.0.0.1]) by egate-co5.uswc.uswest.com (8/8.13.7) with ESMTP id l0V0muZb021416; Tue, 30 Jan 2007 17:48:57 -0700 (MST) Received: from itomae2km03.AD.QINTRA.COM ([10.6.9.152]) by itomae2ksm01.AD.QINTRA.COM with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 18:48:57 -0600 X-MessageTextProcessor: DisclaimIt (2.70.270) [Qwest Communications International Inc.] X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 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] Supplicant X.509 AVP? Date: Tue, 30 Jan 2007 18:48:56 -0600 Message-ID: In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB2625035707E9@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Supplicant X.509 AVP? thread-index: Acc9i2IhUMpmDMG3TcmfC5AoU7EeSgAqjwFgAXSUe1AABgIAUAAfgEawAAbK7EAABfHRIA== Importance: normal Priority: normal From: "Morrow, Glenn" To: "Glen Zorn \(gwz\)" , "Madjid Nakhjiri" X-OriginalArrivalTime: 31 Jan 2007 00:48:57.0204 (UTC) FILETIME=[96CA4340:01C744D1] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Yes there are other protocols that pass certs and these would likely be used as the backend for the Diameter Server. I.e. the Diameter Server is the application to these existing protocols. We just don't want to have to do two dips and that is why we want to transport the cert with Diameter - get it all done with one transaction from the Diameter client/Application Server perspective - not two.=20 >=20 > Seems like a Diameter based cert status checking mechanism.. Hmm -- that's not what I'm getting at all, but if you're right it seems like there are already at least a couple of other standard protocols that do this... ... This communication is the property of Qwest and may contain confidential = or privileged information. Unauthorized use of this communication is = strictly=20 prohibited and may be unlawful. If you have received this communication = in error, please immediately notify the sender by reply e-mail and = destroy=20 all copies of the communication and any attachments. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jan 30 19:55:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC3kf-0001Ra-0S; Tue, 30 Jan 2007 19:55:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC3kd-0001RB-Dl for dime@ietf.org; Tue, 30 Jan 2007 19:55:03 -0500 Received: from uswgne22.uswest.com ([204.26.87.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC3kc-0004KM-4R for dime@ietf.org; Tue, 30 Jan 2007 19:55:03 -0500 Received: from egate-co7.uswc.uswest.com (egate-co7.uswc.uswest.com [151.119.87.234]) by uswgne22.uswest.com (8/8) with ESMTP id l0V0smKR012501; Tue, 30 Jan 2007 18:54:48 -0600 (CST) Received: from itomae2ksm01.AD.QINTRA.COM (localhost [127.0.0.1]) by egate-co7.uswc.uswest.com (8/8.13.7) with ESMTP id l0V0sl50019476; Tue, 30 Jan 2007 17:54:47 -0700 (MST) Received: from itomae2km03.AD.QINTRA.COM ([10.6.9.152]) by itomae2ksm01.AD.QINTRA.COM with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 18:54:47 -0600 X-MessageTextProcessor: DisclaimIt (2.70.270) [Qwest Communications International Inc.] X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 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] Supplicant X.509 AVP? Date: Tue, 30 Jan 2007 18:54:46 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Supplicant X.509 AVP? thread-index: Acc9i2IhUMpmDMG3TcmfC5AoU7EeSgAqjwFgAXSUe1AABgIAUAAfgEawAAbK7EAABfHRIAAAQgtA Importance: normal From: "Morrow, Glenn" Priority: normal To: "Morrow, Glenn" , "Glen Zorn \(gwz\)" , "Madjid Nakhjiri" X-OriginalArrivalTime: 31 Jan 2007 00:54:47.0789 (UTC) FILETIME=[67C149D0:01C744D2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org We also don't want to have to have to transport the cert at all at the application level - just start signing and digesting from the get go - granted challenge/nonce etc.. needed later as well. -----Original Message----- From: Morrow, Glenn=20 Sent: Tuesday, January 30, 2007 5:49 PM To: 'Glen Zorn (gwz)'; Madjid Nakhjiri Cc: dime@ietf.org; Hannes Tschofenig Subject: RE: [Dime] Supplicant X.509 AVP? Yes there are other protocols that pass certs and these would likely be used as the backend for the Diameter Server. I.e. the Diameter Server is the application to these existing protocols. We just don't want to have to do two dips and that is why we want to transport the cert with Diameter - get it all done with one transaction from the Diameter client/Application Server perspective - not two.=20 >=20 > Seems like a Diameter based cert status checking mechanism.. Hmm -- that's not what I'm getting at all, but if you're right it seems like there are already at least a couple of other standard protocols that do this... ... This communication is the property of Qwest and may contain confidential = or privileged information. Unauthorized use of this communication is = strictly=20 prohibited and may be unlawful. If you have received this communication = in error, please immediately notify the sender by reply e-mail and = destroy=20 all copies of the communication and any attachments. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jan 31 08:10:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCFEV-0000iu-Kt; Wed, 31 Jan 2007 08:10:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwz0-0003Qp-8Y for dime@ietf.org; Tue, 30 Jan 2007 12:41:26 -0500 Received: from nz-out-0506.google.com ([64.233.162.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBwyz-0004sc-0x for dime@ietf.org; Tue, 30 Jan 2007 12:41:26 -0500 Received: by nz-out-0506.google.com with SMTP id z6so1855525nzd for ; Tue, 30 Jan 2007 09:41:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=N513ARGY0xb/rOyb7xrykdqXu32kGRcNAu2OlOGvMJksSwTjhVpWGT1mB6+C3p30pRpcTnNd8FuW/umXX8mnMFNGwlZhkKpIX7CY7PX9lT6pAOC6+N39dnYsEsTH0zjCUDx8Cz9X441BP/OQSDl/4Hpy37n5G0jqPlfigqvWkC0= Received: by 10.65.224.11 with SMTP id b11mr12357166qbr.1170178884376; Tue, 30 Jan 2007 09:41:24 -0800 (PST) Received: by 10.64.153.5 with HTTP; Tue, 30 Jan 2007 09:41:24 -0800 (PST) Message-ID: <8986a650701300941t7f428ef2g8cd6e7adf62fe9f0@mail.gmail.com> Date: Tue, 30 Jan 2007 23:11:24 +0530 From: "Diameter K" To: dime@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-Mailman-Approved-At: Wed, 31 Jan 2007 08:10:38 -0500 Subject: [Dime] QoS-Filter-Rule Query! 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="===============1386070781==" Errors-To: dime-bounces@ietf.org --===============1386070781== Content-Type: multipart/alternative; boundary="----=_Part_71507_3123802.1170178884324" ------=_Part_71507_3123802.1170178884324 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All,* *As per RFC 4005 QoS-Filter-Rule may be used to send Authorization Related information to the serving NAS. The format specified is "action dir proto from src to dst [options]" where options format is "DSCP metering ". I want to know how can i send service characteristics such as "Max Traffic Burst", "Allowed Jitter" etc. As per my understanding i feel the RFC allows only for sending the traffic rate. Or Should these characteristics be know at the NAS itself and the AAA Server can only send the DSCP of the service it is authorizing the user to use. But in this case why should the AAA server send the parameter. This also can very well be configured at the NAS. Thanks and Regards, Shiv ------=_Part_71507_3123802.1170178884324 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All,
      As per RFC 4005 QoS-Filter-Rule may be used to send Authorization Related information to the serving NAS. The format specified is "action dir proto from src to dst [options]" where options format is "DSCP <color> metering <rate> <color_under> <color_over>".
   I want to know how can i send service characteristics such as "Max Traffic Burst", "Allowed Jitter" etc. As per my understanding i feel the RFC allows only for sending the traffic rate.
  Or Should these characteristics be know at the NAS itself and the AAA Server can only send the DSCP of the service it is authorizing the user to use. But in this case why should the AAA server send the <rate> parameter. This also can very well be configured at the NAS.

Thanks and Regards,
Shiv ------=_Part_71507_3123802.1170178884324-- --===============1386070781== 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 --===============1386070781==-- From dime-bounces@ietf.org Wed Jan 31 08:10:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCFEV-0000iy-Qt; Wed, 31 Jan 2007 08:10:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBx0M-0004PP-HE for dime@ietf.org; Tue, 30 Jan 2007 12:42:50 -0500 Received: from nz-out-0506.google.com ([64.233.162.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBx0L-00056z-BX for dime@ietf.org; Tue, 30 Jan 2007 12:42:50 -0500 Received: by nz-out-0506.google.com with SMTP id z6so1855897nzd for ; Tue, 30 Jan 2007 09:42:48 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=nHp3pahihFuCivMNiIcP0Lyg4R+MM8qVTGbO7De8enkncPSvuR8Kc6R+24WGn3mi4d0MeG95HXs1645Dvl/Ibg0waVlDCZL/HmCjJ2DpHc8F7kC56rXUsUasqH2NwYz2S1hmwOm6hWFtxNbDS7ZpyrVBvMs0oRF2r5imxr+lAWA= Received: by 10.65.233.16 with SMTP id k16mr12466746qbr.1170178968608; Tue, 30 Jan 2007 09:42:48 -0800 (PST) Received: by 10.64.153.5 with HTTP; Tue, 30 Jan 2007 09:42:48 -0800 (PST) Message-ID: <8986a650701300942y6e0b4ea3i38125e0d168435f1@mail.gmail.com> Date: Tue, 30 Jan 2007 23:12:48 +0530 From: "Diameter K" To: dime@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.7 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-Mailman-Approved-At: Wed, 31 Jan 2007 08:10:38 -0500 Subject: [Dime] subscribe 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="===============0105621732==" Errors-To: dime-bounces@ietf.org --===============0105621732== Content-Type: multipart/alternative; boundary="----=_Part_71531_753667.1170178968568" ------=_Part_71531_753667.1170178968568 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline ------=_Part_71531_753667.1170178968568 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
------=_Part_71531_753667.1170178968568-- --===============0105621732== 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 --===============0105621732==-- From dime-bounces@ietf.org Wed Jan 31 08:31:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCFYr-0001hF-3J; Wed, 31 Jan 2007 08:31:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCFYq-0001h6-Nq for dime@ietf.org; Wed, 31 Jan 2007 08:31:40 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCFYj-0006g0-OE for dime@ietf.org; Wed, 31 Jan 2007 08:31:40 -0500 Received: from mail2.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id l0VDVV5J021712; Wed, 31 Jan 2007 14:31:31 +0100 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id l0VDVVfY024295; Wed, 31 Jan 2007 14:31:32 +0100 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 14:31:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: AW: [Dime] QoS-Filter-Rule Query! Date: Wed, 31 Jan 2007 14:31:29 +0100 Message-ID: <8F6CBC7005099442AECDB784C9E9D7E701746228@MCHP7R6A.ww002.siemens.net> In-Reply-To: <8986a650701300941t7f428ef2g8cd6e7adf62fe9f0@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] QoS-Filter-Rule Query! Thread-Index: AcdFOcK8TwN6/m6ARkWACp5ailK1wgAAeG0Q From: "Tschofenig, Hannes" To: "Diameter K" , X-OriginalArrivalTime: 31 Jan 2007 13:31:31.0918 (UTC) FILETIME=[1EB98EE0:01C7453C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Shiv,=20 =20 RFC 4005 provides some basic functionality and it does not allow to send more sophisticated QoS parameters.=20 =20 We are currently working on an extended version of the QoS functionality. You might want to take a look at=20 http://tools.ietf.org/wg/dime/draft-tschofenig-dime-diameter-qos-01.txt =20 A new version of the document will be available in the next few days, I hope.=20 Ciao Hannes ________________________________ Von: Diameter K [mailto:diametera@gmail.com]=20 Gesendet: Dienstag, 30. Januar 2007 12:41 An: dime@ietf.org Betreff: [Dime] QoS-Filter-Rule Query! =09 =09 Hi All, As per RFC 4005 QoS-Filter-Rule may be used to send Authorization Related information to the serving NAS. The format specified is "action dir proto from src to dst [options]" where options format is "DSCP metering ".=20 I want to know how can i send service characteristics such as "Max Traffic Burst", "Allowed Jitter" etc. As per my understanding i feel the RFC allows only for sending the traffic rate.=20 Or Should these characteristics be know at the NAS itself and the AAA Server can only send the DSCP of the service it is authorizing the user to use. But in this case why should the AAA server send the parameter. This also can very well be configured at the NAS. =09 Thanks and Regards, Shiv=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jan 31 15:50:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCMPg-0003jG-LK; Wed, 31 Jan 2007 15:50:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCMPZ-0003cY-S4; Wed, 31 Jan 2007 15:50:33 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HCMPY-0004vc-I0; Wed, 31 Jan 2007 15:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 76AF72AC9D; Wed, 31 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HCMP4-0004xY-7n; Wed, 31 Jan 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 31 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-rfc3588bis-01.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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Base Protocol Author(s) : V. Fajardo, J. Loughney Filename : draft-ietf-dime-rfc3588bis-01.txt Pages : 167 Date : 2007-1-31 The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also intended to work in both local Authentication, Authorization & Accounting and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services to be used by all Diameter applications. The Diameter base application needs to be supported by all Diameter implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-rfc3588bis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dime-rfc3588bis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-31115054.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-rfc3588bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-rfc3588bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-31115054.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Wed Jan 31 17:11:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCNft-0006dE-02; Wed, 31 Jan 2007 17:11:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCNfr-0006d9-9u for dime@ietf.org; Wed, 31 Jan 2007 17:11:27 -0500 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCNfq-0000Lq-8x for dime@ietf.org; Wed, 31 Jan 2007 17:11:27 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id D91E590048 for ; Wed, 31 Jan 2007 17:11:22 -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 27172-16 for ; Wed, 31 Jan 2007 17:11:18 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 31 Jan 2007 17:11:18 -0500 (EST) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 17:11:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Issue ornotIssue ? Date: Wed, 31 Jan 2007 17:11:17 -0500 Message-ID: <7CCD07160348804497EF29E9EA5560D7FBD843@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Issue ornotIssue ? Thread-Index: AcdAA/r5nUIvzJ8ATjeXOadoEt8alwAWd2gAAAvsElAAASCtUAAEcmegAAF0xzAA1zPeEABfAJhA From: "Chowdhury, Kuntal" To: "Madjid Nakhjiri" , "MORAND Lionel RD-CORE-ISS" , "Ahmad Muhanna" , "Yoshihiro Ohba" X-OriginalArrivalTime: 31 Jan 2007 22:11:18.0252 (UTC) FILETIME=[BB3A7AC0:01C74584] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 46ad68ada464411807db2a0edd5648ae Cc: dime@ietf.org, Julien Laganier 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="===============1949629511==" Errors-To: dime-bounces@ietf.org --===============1949629511== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRm9sa3MsDQoNCkl0IGlzIHBvc3NpYmxlIHRoYXQgdGhlIEFBQSBzZXJ2ZXIgdXNlZCBmb3Ig RUFQIGF1dGhlbnRpY2F0aW9uIChmb3IgSUtFdjIpIGFuZCB0aGUgQUFBIHNlcnZlciB1c2VkIHRv IGF1dGhvcml6ZSBNSVA2IHNlcnZpY2UgdG8gdGhlIE1OIG1heSBiZSBkaWZmZXJlbnQuIEhvd2V2 ZXIsIGluIG9yZGVyIHRvIHN1cHBvcnQgdGhpcyBzY2VuYXJpbywgd2UgZG9uJ3QgbmVjZXNzYXJp bHkgaGF2ZSB0byBkZWZpbmUgdG90YWxseSBzZXBhcmF0ZSBBQUEgdHJhbnNhY3Rpb25zIGJ5IHRo ZSBIb21lIEFnZW50LiBUaGUgTUlQNiBzZXJ2aWNlIGNhbiBiZSBhdXRob3JpemVkIGJ5IGxldHRp bmcgdGhlIEFBQSBzZXJ2ZXIgKEVBUCkgdG8gY29tbXVuaWNhdGUgd2l0aCB0aGUgQUFBIHNlcnZl ciAoTW9iaWxpdHkpLiBUaGUgQUFBIHNldmVyIHRoYXQgaXMgYXV0aGVudGljYXRpbmcgdGhlIE1O ICh2aWEgRUFQKSBjYW4gY29udGFjdCB0aGUgQUFBIHNlcnZlciBmb3IgbW9iaWxpdHkgc2Vydmlj ZSB0byBhdXRob3JpemUgdGhlIHVzZXIgZm9yIE1JUDYgc2VydmljZS4gVGhlIGluZGljYXRpb24g Zm9yIE1JUDYgc2VydmljZSBhdXRob3JpemF0aW9uIGNhbiBiZSBjYXJyaWVkIGFsb25nIHdpdGgg dGhlIHNhbWUgQUFBIG1lc3NhZ2UgdGhhdCBjYXJyaWVzIEVBUCBTdWNjZXNzLiBUaGF0IHdheSB0 aGUgTU4gY2FuIGdldCBhdXRoZW50aWNhdGVkIGFuZCBhdXRob3JpemVkIGluIG9uZSBzaG90LiBN b3Jlb3ZlciwgdGhlIGlzc3VlIG9mIHdoZXRoZXIgdGhlIEhvbWUgQWdlbnQgbmVlZHMgdG8gcHJl c2VudCBzb21lIGF1dGhlbnRpY2F0aW9uIHRva2VuIHRvIHRoZSBBQUEgc2VydmVyIHRoYXQgaXMg YXV0aG9yaXppbmcgdGhlIG1vYmlsaXR5IHNlcnZpY2UgZ29lcyBhd2F5LiANCg0KUmVnYXJkcywN Ckt1bnRhbA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFkamlk IE5ha2hqaXJpIFttYWlsdG86bW5ha2hqaXJpQGh1YXdlaS5jb21dDQo+IFNlbnQ6IE1vbmRheSwg SmFudWFyeSAyOSwgMjAwNyA2OjM1IFBNDQo+IFRvOiAnTU9SQU5EIExpb25lbCBSRC1DT1JFLUlT Uyc7ICdBaG1hZCBNdWhhbm5hJzsgJ1lvc2hpaGlybyBPaGJhJw0KPiBDYzogZGltZUBpZXRmLm9y ZzsgJ0p1bGllbiBMYWdhbmllcicNCj4gU3ViamVjdDogUkU6IFtEaW1lXSBEaWFtZXRlciBNb2Jp bGUgSVB2NiBIQS10by1BQUFIIFN1cHBvcnQ6IElzc3VlDQo+IG9ybm90SXNzdWUgPw0KPiANCj4g QnV0IHRoZXJlIGlzIGFsc28gYSBwb3NzaWJsZSBzZXBhcmF0aW9uIG9mIEFBQSBzZXJ2ZXJzOikN Cj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1PUkFORCBMaW9uZWwg UkQtQ09SRS1JU1MgW21haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS1mdGdyb3VwLmNvbV0NCj4g U2VudDogVGh1cnNkYXksIEphbnVhcnkgMjUsIDIwMDcgMTA6MDEgQU0NCj4gVG86IEFobWFkIE11 aGFubmE7IFlvc2hpaGlybyBPaGJhDQo+IENjOiBkaW1lQGlldGYub3JnOyBKdWxpZW4gTGFnYW5p ZXINCj4gU3ViamVjdDogUkU6IFtEaW1lXSBEaWFtZXRlciBNb2JpbGUgSVB2NiBIQS10by1BQUFI IFN1cHBvcnQ6IElzc3VlIG9yDQo+IG5vdElzc3VlID8NCj4gDQo+IEhpIEFobWFkLA0KPiANCj4g SSB0aGluayB0aGF0IHRoZXJlIGlzIGEgY29uZnVzaW9uIGJldHdlZW4gIkFBQSBtZXNzYWdlcyIg YW5kICJBQUENCj4gcHJvdG9jb2xzIi4NCj4gVGhlcmVmb3JlLCB3aGVuIHRoZXkgc3BlYWsgYWJv dXQgInNlcGFyYXRpb24iLCBpdCdzIGFib3V0IHNlcGFyYXRpb24gb2YNCj4gQUFBIG1lc3NhZ2Vz IHdpdGhpbiB0aGUgc2FtZSBBQUEgcHJvdG9jb2wsIGFuZCBub3Qgc2VwYXJhdGlvbiBvZiBBQUEN Cj4gcHJvdG9jb2xzLg0KPiANCj4gSWYgd2UgaGF2ZSB0byBrZWVwIG9ubHkgb25lIHN0YXRlbWVu dCwgaXQgd291bGQgYmU6DQo+IA0KPiAidGhlIEFBQSBwcm90b2NvbHMgTVVTVCBhbHNvIGFsbG93 IGZvciBhIHNpbmdsZSBtZXNzYWdlIHRvIHJlcXVlc3QgYm90aA0KPiBhdXRoZW50aWNhdGlvbiBh bmQgYXV0aG9yaXphdGlvbi4iDQo+IA0KPiBMaW9uZWwNCj4gDQo+ID4gLS0tLS1NZXNzYWdlIGQn b3JpZ2luZS0tLS0tDQo+ID4gRGUgOiBBaG1hZCBNdWhhbm5hIFttYWlsdG86YW11aGFubmFAbm9y dGVsLmNvbV0NCj4gPiBFbnZvecOpIDogamV1ZGkgMjUgamFudmllciAyMDA3IDE4OjM3DQo+ID4g w4AgOiBNT1JBTkQgTGlvbmVsIFJELUNPUkUtSVNTOyBZb3NoaWhpcm8gT2hiYQ0KPiA+IENjIDog SnVsaWVuIExhZ2FuaWVyOyBkaW1lQGlldGYub3JnDQo+ID4gT2JqZXQgOiBSRTogW0RpbWVdIERp YW1ldGVyIE1vYmlsZSBJUHY2IEhBLXRvLUFBQUggU3VwcG9ydDoNCj4gPiBJc3N1ZSBvciBub3RJ c3N1ZSA/DQo+ID4NCj4gPiBIaSBMaW9uZWwsDQo+ID4gVGhhbmtzIGZvciB5b3VyIHJlc3BvbnNl LiBQbGVhc2Ugc2VlIHNvbWUgY29tbWVudHMgaW5saW5lLg0KPiA+DQo+ID4gUmVnYXJkcywNCj4g PiBBaG1hZA0KPiA+DQo+ID4NCj4gPiA+IFN1YmplY3Q6IFJFOiBbRGltZV0gRGlhbWV0ZXIgTW9i aWxlIElQdjYgSEEtdG8tQUFBSCBTdXBwb3J0Og0KPiA+ID4gSXNzdWUgb3Igbm90SXNzdWUgPw0K PiA+ID4NCj4gPiA+IEhpIEFobWFkLA0KPiA+ID4NCj4gPiA+IEp1c3QgYSBjb3VwbGUgb2YgcmVx dWlyZW1lbnRzOg0KPiA+ID4NCj4gPiA+IDIuNy4zDQo+ID4gPiAgICBXaXRoaW4gYSBzaW5nbGUg c2Vzc2lvbiBvciB0cmFuc2FjdGlvbiwgaXQgTVVTVCBiZSBwb3NzaWJsZSB0bw0KPiA+ID4gICAg aW50ZXJsZWF2ZSBhdXRoZW50aWNhdGlvbiwgYXV0aG9yaXphdGlvbiBhbmQgYWNjb3VudGluZw0K PiA+IEFBQSBtZXNzYWdlcy4NCj4gPiA+DQo+ID4gPiAgICBUaGlzIHN0YXRlcywgdGhhdCBlLmcu IGEgc2Vzc2lvbiBtYXkgaGF2ZSB0byB1c2UgaW5pdGlhbA0KPiA+ID4gICAgYXV0aGVudGljYXRp b24sIGF1dGhvcml6YXRpb24gYW5kIGFjY291bnRpbmcgQUFBIG1lc3NhZ2UocyksIGJ1dA0KPiA+ ID4gYWxzbw0KPiA+ID4gICAgaGF2ZSB0byBpbmNsdWRlIGUuZy4gcmUtYXV0aGVudGljYXRpb24g ZXZlcnkgMzAgbWludXRlcywgb3IgYQ0KPiA+ID4gICAgY29udGludW91cyAiZHJpcC1kcmlwIiBv ZiBhY2NvdW50aW5nIEFBQSBtZXNzYWdlcy4NCj4gPg0KPiA+IFtBaG1hZF0NCj4gPiBUaGlzIG9u ZSBpcyBhIGxpdHRsZSB0cmlja3kuIElNTywgSW4gdGhlIGNhc2Ugb2YNCj4gPiBBdXRoZW50aWNh dGlvbiBhbmQgQXV0aG9yaXphdGlvbiBzZXBhcmF0aW9uLCB0aGVyZSB3aWxsIGJlDQo+ID4gYXV0 aGVudGljYXRpb24sIGF1dGhvcml6YXRpb24sIGFuZCBhY2NvdW50aW5nIGZvciBldmVyeQ0KPiA+ IHNlc3Npb24uIERPIHlvdSB0aGluayBvdGhlcndpc2U/IEkgZG8gbm90IHNlZSBoZXJlIHRoYXQg dGhlcmUNCj4gPiBpcyBhbiBpbmRpY2F0aW9uIHRoYXQgQXV0aG9yaXphdGlvbiBhbmQgQXV0aGVu dGljYXRpb24gbmVlZHMNCj4gPiB0byBiZSBjb21iaW5lZCBhZ2Fpbi4NCj4gPg0KPiA+ID4NCj4g PiA+IDIuOS4xDQo+ID4gPiAgICBBdXRob3JpemF0aW9uIHNlcGFyYXRlIGZyb20gYXV0aGVudGlj YXRpb24gU0hPVUxEIGJlIGFsbG93ZWQNCj4gPiA+ICAgIHdoZW4gbmVjZXNzYXJ5LCBidXQgdGhl IEFBQSBwcm90b2NvbHMgTVVTVCBhbHNvIGFsbG93DQo+ID4gZm9yIGEgc2luZ2xlDQo+ID4gPiAg ICBtZXNzYWdlIHRvIHJlcXVlc3QgYm90aCBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlv bi4NCj4gPiA+DQo+ID4gPiAgICBBQUEgcHJvdG9jb2xzIGhhdmUgdG8gYWxsb3cgYSBzcGxpdCBi ZXR3ZWVuIGF1dGhlbnRpY2F0aW9uIGFuZA0KPiA+ID4gICAgYXV0aG9yaXphdGlvbiBzbyB0aGF0 IGRpZmZlcmVudCBtZWNoYW5pc21zIGFyZSB1c2VkIGZvcg0KPiA+IGVhY2guIFRoaXMNCj4gPiA+ ICAgIHN0YXRlcyB0aGF0IHNvbWV0aW1lcyBib3RoIHR5cGVzIG9mIGluZm9ybWF0aW9uIG5lZWQg dG8NCj4gPiBiZSBjYXJyaWVkDQo+ID4gPiBpbg0KPiA+ID4gICAgdGhlIHNhbWUgbWVzc2FnZS4N Cj4gPg0KPiA+IFtBaG1hZF0NCj4gPiBJIGFtIG5vdCBzdXJlIEkgY2FuIHJlYWQgdGhpcyByZXF1 aXJlbWVudCBhcyBhIHJlcXVpcmVtZW50DQo+ID4gdGhhdCB3aGVuIEF1dGhlbnRpY2F0aW9uIGFu ZCBBdXRob3JpemF0aW9uIGFyZSBzZXBhcmF0ZWQsDQo+ID4gQXV0aG9yaXphdGlvbiBtZXNzYWdl cyBNVVNUIHByb3ZpZGUgYXV0aGVudGljYXRpb24gdG9vLg0KPiA+IEJlY2F1c2UgaWYgdGhhdCB3 YXMgdGhlIGludGVudGlvbiwgdGhlbiB0aGlzIHJlcXVpcmVtZW50IGRvZXMNCj4gPiBub3QgbWFr ZSBhbnkgc2Vuc2UuIFRoZSBzZWNvbmQgcG9ydGlvbiBvZiBpdCBuZWdhdGUgd2hhdCB0aGUNCj4g PiBmaXJzdCBwb3J0aW9uIGFscmVhZHkgYWxsb3dlZCB0byBoYXBwZW4uDQo+ID4gTXkgaW50ZXJw cmV0YXRpb24gaXMgdGhlIEF1dGhlbnRpY2F0aW9uIGFuZCBBdXRob3JpemF0aW9uIGlzDQo+ID4g ZmluZSBhbmQgYWxsb3dlZCwgaG93ZXZlciwgQUFBIHByb3RvY29scyBzaG91bGQgZ2l2ZSB0aGUN Cj4gPiBvcHRpb24gZm9yIGludGVncmF0ZWQgc29sdXRpb24sIGkuZS4gQXV0aGVudGljYXRpb24g YW5kDQo+ID4gQXV0aG9yaXphdGlvbiBpbiB0aGUgc2FtZSBtZXNzYWdlIGFuZCBhdCB0aGUgc2Ft ZSB0aW1lLg0KPiA+DQo+ID4NCj4gPiBJbiBnZW5lcmFsLCBhcyBsb25nIGFzIFJGQzI2MDkgQUxM T1dFRCB0aGUgc2VwYXJhdGlvbiBiZXR3ZWVuDQo+ID4gQXV0aGVudGljYXRpb24gYW5kIEF1dGhv cml6YXRpb24sIGl0IGRvZXMgbm90IG1ha2Ugc2Vuc2UgdG8NCj4gPiBtYW5kYXRlIGludGVncmF0 aW9uIGluIGNhc2Ugc2VwYXJhdGlvbiBvcHRpb24gaXMgYWRvcHRlZC4gQW0NCj4gPiBJIG1ha2lu ZyBzb21lIHNlbnNlIGhlcmUuDQo+ID4NCj4gPiA+DQo+ID4gPiBCdXQgeW91IGNhbiBmaW5kIHNl dmVyYWwgb3RoZXIgcGxhY2VzIGluIHRoZSBkb2N1bWVudCB3aGVyZQ0KPiA+ID4gYXV0aGVudGlj YXRpb24gJiBhdXRob3JpemF0aW9uIGFyZSBib3VuZC4NCj4gPiA+DQo+ID4gPiBCUiwNCj4gPiA+ DQo+ID4gPiBMaW9uZWwNCj4gPiA+DQo+ID4gPiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0t LQ0KPiA+ID4gPiBEZSA6IEFobWFkIE11aGFubmEgW21haWx0bzphbXVoYW5uYUBub3J0ZWwuY29t XSBFbnZvecOpIDogamV1ZGkgMjUNCj4gPiA+ID4gamFudmllciAyMDA3IDE1OjQyIMOAIDogTU9S QU5EIExpb25lbCBSRC1DT1JFLUlTUzsgWW9zaGloaXJvDQo+ID4gPiBPaGJhIENjIDoNCj4gPiA+ ID4gSnVsaWVuIExhZ2FuaWVyOyBkaW1lQGlldGYub3JnIE9iamV0IDogUkU6IFtEaW1lXSBEaWFt ZXRlcg0KPiA+ID4gTW9iaWxlIElQdjYNCj4gPiA+ID4gSEEtdG8tQUFBSCBTdXBwb3J0Og0KPiA+ ID4gPiBJc3N1ZSBvciBub3RJc3N1ZSA/DQo+ID4gPiA+DQo+ID4gPiA+IEhpIExpb25lbCwNCj4g PiA+ID4gUGxlYXNlIHNlZSBzb21lIG9uZSBjb21tZW50IGlubGluZS4NCj4gPiA+ID4NCj4gPiA+ ID4gUmVnYXJkcywNCj4gPiA+ID4gQWhtYWQNCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiA+IEZyb206IE1PUkFORCBMaW9uZWwg UkQtQ09SRS1JU1MNCj4gPiA+ID4gPiBbbWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLWZ0Z3Jv dXAuY29tXQ0KPiA+ID4gPiA+IFNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDI1LCAyMDA3IDU6MTEg QU0NCj4gPiA+ID4gPiBUbzogWW9zaGloaXJvIE9oYmENCj4gPiA+ID4gPiBDYzogSnVsaWVuIExh Z2FuaWVyOyBNdWhhbm5hLCBBaG1hZCAoUklDSDE6MkgxMCk7IGRpbWVAaWV0Zi5vcmcNCj4gPiA+ ID4gPiBTdWJqZWN0OiBSRTogW0RpbWVdIERpYW1ldGVyIE1vYmlsZSBJUHY2IEhBLXRvLUFBQUgg U3VwcG9ydDoNCj4gPiA+ID4gPiBJc3N1ZSBvciBub3RJc3N1ZSA/DQo+ID4gPiA+ID4NCj4gPiA+ ID4gPiBIaSBZb3NoaSwNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IDEpIElmIGF1dGhlbnRpY2F0aW9u IHByb2NlZHVyZXMgbWF5IGJlIHBlcmZvcm1lZCBhcGFydCBmcm9tDQo+ID4gPiA+ID4gYXV0aG9y aXphdGlvbiBwcm9jZWR1cmVzIChJIHRvdGFsbHkgYWdyZWUpLCBhdXRob3JpemF0aW9uDQo+ID4g PiA+IHByb2NlZHVyZXMNCj4gPiA+ID4gPiBtdXN0IGJlIGFibGUgdG8gcmVseSBvbiBpdHMgb3du IGF1dGhlbnRpY2F0aW9uIHByb2NlZHVyZXMNCj4gPiA+IGlmIG5lZWRlZA0KPiA+ID4gPiA+IChj Zi4gQUFBIHJlcXVpcmVtZW50cyBpbiBSRkMgMjkwNikuIEFyZSB5b3UgT0sgd2l0aCB0aGF0Pw0K PiA+ID4gPg0KPiA+ID4gPiBbQWhtYWRdDQo+ID4gPiA+IEp1c3QgZm9yIG15IGVkdWNhdGlvbiwg Y291bGQgeW91IHBsZWFzZSBnaXZlIG1lIGEgcG9pbnRlcg0KPiA+IHRvIHdoaWNoDQo+ID4gPiA+ IHJlcXVpcmVtZW50IHlvdSBhcmUgcmVmZXJyaW5nIGluIFJGQzI5MDYuDQo+ID4gPiA+IFRoYW5r cy4NCj4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IDIpIEFzIGl0IGlzIG5vdywgcHJvdmlk aW5nIGF1dGhlbnRpY2F0aW9uIHdpdGggRGlhbWV0ZXIgRUFQDQo+ID4gPiA+ID4gYXBwbGljYXRp b24gYW5kIGF1dGhvcml6YXRpb24gd2l0aCBEaWFtZXRlciBNSVA2IGRvZXMgbm90DQo+ID4gPiBh bGxvdyB0aGUNCj4gPiA+ID4gPiBBQUEtTUlQNiB0byBiZSBzdXJlIHRoYXQgdGhlIHVzZXJuYW1l IGNhcnJpZWQgaW4gdGhlDQo+ID4gPiBhdXRob3JpemF0aW9uDQo+ID4gPiA+ID4gcmVxdWVzdCB3 YXMgcHJldmlvdXNseSBhdXRoZW50aWNhdGVkIGJ5IHRoZSBBQUEtRUFQLiBBcmUNCj4gPiA+ID4g eW91IE9LIHdpdGgNCj4gPiA+ID4gPiB0aGF0Pw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gMykgSWYg dGhlIEFBQS1NSVA2IHByb3ZpZGVzIHRoZSBIQSB3aXRoIHNlcnZpY2UgcmVsYXRlZA0KPiA+ID4g aW5mb3JtYXRpb24NCj4gPiA+ID4gPiB3aXRob3V0IGJlaW5nIHN1cmUgdGhhdCB0aGUga2V5IGVu dHJ5ICh1c2VybmFtZSkgd2FzIHByZXZpb3VzbHkNCj4gPiA+ID4gPiBhdXRoZW50aWNhdGVkLCB3 aGF0IGlzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlDQo+ID4gQUFBLU1JUDYgYW5kIGENCj4g PiA+ID4gPiAic2ltcGxlIiBleHRlcm5hbCBkYXRhYmFzZSBwcm92aWRpbmcgaW5mb3JtYXRpb24g ZGF0YSB0byBhbnkNCj4gPiA+ID4gPiBhdXRob3JpemVkIGVudGl0eSAoSEEgaW4gdGhlIHByZXNl bnQgY2FzZSk/IFdoYXQvd2hlcmUgaXMgdGhlDQo+ID4gPiA+ID4gYXV0aG9yaXphdGlvbiBwcm9j ZXNzIGluIHRoYXQgY2FzZT8NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IDQpIElmIGNvbWJpbmluZyBE aWFtZXRlciBFQVAgYW5kIERpYW1ldGVyIE1JUDYgaXMgbW9yZQ0KPiA+ID4gY29tcGxleCB0aGFu DQo+ID4gPiA+ID4gaW5jbHVkaW5nIGF1dGhlbnRpY2F0aW9uIHByb2NlZHVyZXMgd2l0aCBEaWFt ZXRlciBNSVA2IHRoYXQgaXMNCj4gPiA+ID4gPiBjb2hlcmVudCB3aXRoIEFBQSByZXF1aXJlbWVu dHMsIHdoeSBhcmUgd2Ugc3RpbGwgZGlzY3Vzc2luZw0KPiA+ID4gPiBhcyBtdWNoPw0KPiA+ID4g PiA+IDspDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiA1KSBJZiB0aGUgZGlzY3Vzc2lvbiBpcyBiZXlv bmQgdGhlIHNjb3BlIG9mIHRoZSBkcmFmdCBhbmQNCj4gPiA+ID4gcmVsYXRlZCB0bw0KPiA+ID4g PiA+IHRoZSBmdXR1cmUgb2YgZ2xvYmFsIEFBQSBmcmFtZXdvcmssIHdoeSBkbyBub3QgImRlY291 cGxlIiB0aGUNCj4gPiA+ID4gPiBkaXNjdXNzaW9ucyBhbmQgY3JlYXRlIGEgc2VwYXJhdGUgdGhy ZWFkPyBCdXQgZm9yIG5vdywgSQ0KPiA+ID4gPiBjYW4gc2VlIHRoYXQNCj4gPiA+ID4gPiBhIERp YW1ldGVyIE1JUDYgYXBwbGljYXRpb24gd2l0aCBhdXRoZW50aWNhdGlvbiBwcm9jZWR1cmUNCj4g PiA+IHdvdWxkIGJlDQo+ID4gPiA+ID4gY29uc2lzdGVudCB3aXRoIHRoZSBjdXJyZW50IEFBQSBm cmFtZXdvcmsgd2hpbGUgYQ0KPiA+IGNvbWJpbmFpc29uIG9mDQo+ID4gPiA+ID4gRGlhbWV0ZXIg RUFQIGFuZCBEaWFtZXRlciBNSVA2IHdpbGwgbm90IG1lZXQgYWxsIHRoZSBBQUENCj4gPiA+ID4g cmVxdWlyZW1lbnRzDQo+ID4gPiA+ID4gd2l0aG91dCBpbnRyb2R1Y2luZyBzcGVjaWZpYyBmdW5j dGlvbmFsaXRlcy9lbmhhbmNlbWVudHMuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBJIHdvdWxkIGhh dmUgbm8gcHJvYmxlbSB3aXRoIGEgc29sdXRpb24gcHJvcG9zaW5nIEVBUA0KPiA+ID4gPiBhdXRo ZW50aWNhdGlvbg0KPiA+ID4gPiA+IHByb2NlZHVyZXMgYW5kIE1JUDYgYXV0aG9yaXphdGlvbiBw cm9jZWR1cmVzIHN1cHBvcnRlZCBieQ0KPiA+ID4gPiB0byBkaWZmZXJlbnQNCj4gPiA+ID4gPiBk aWFtZXRlciBhcHBsaWNhdGlvbnMgSUYgaXQgY291bGQgYmUgcG9zc2libGUgdG8gYmluZCBib3Ro DQo+ID4gPiA+IHByb2NlZHVyZXMNCj4gPiA+ID4gPiBpbiB0aGUgc2FtZSBlcXVpcG1lbnQgaW4g dGhlIE1TQS4gVGhhdCBpcyBub3QgdGhlIGNhc2Ugd2l0aCB0aGUNCj4gPiA+ID4gPiBjdXJyZW50 IHNvbHV0aW9uLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gQlIsDQo+ID4gPiA+ID4NCj4gPiA+ID4g PiBMaW9uZWwNCj4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBUaGVyZSBpcyBhIG5ldyBndXkgaW4g dGhlIGdhbWUgOykNCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gQWZ0ZXIgcmV2aWV3aW5n IHRoZSBkcmFmdCBhbmQgdGhlIG1haWwgZXhjaGFuZ2Ugb24gdGhlDQo+ID4gPiA+ID4gPiB0b3Bp YywgSSB3b3VsZCBzYXkgdGhhdCB0aGUgY29uY2x1c2lvbiBvbiAiaXNzdWUvbm8gaXNzdWUiDQo+ ID4gPiA+ID4gPiBkZXBlbmRzIG9uIHRoZSBzaWRlIHlvdSBhcmUgY29uc2lkZXJpbmcgdGhlIHBy b2JsZW0gKGFzDQo+ID4gPiBvZnRlbiA7KS4NCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4g SWYgeW91IGFyZSBjb25zaWRlcmluZyB0aGUgQUFBLU1JUDYgYXMgYSAic2ltcGxlIiBkYXRhYmFz ZQ0KPiA+ID4gPiA+ID4gcHJvdmlkaW5nIHRoZSBIQSB3aXRoIHNwZWNpZmljIHVzZXIvc2Vydmlj ZQ0KPiA+IGluZm9ybWF0aW9uIGFmdGVyIGENCj4gPiA+ID4gPiA+IHNlcGFyYXRlIGF1dGhlbnRp Y2F0aW9uIChwZXJmb3JtZWQgd2l0aCBEaWFtZXRlcg0KPiA+ID4gPiA+IGF1dGhlbnRpY2F0aW9u KSwgdGhlDQo+ID4gPiA+ID4gPiB1c2VybmFtZSBjb252ZXllZCBvdmVyIHRoZSBIQS9BQUEtTUlQ NiBpcyBqdXN0IHVzZWQgYXMgYQ0KPiA+ID4gPiA+IGtleSBlbnRyeSBpbg0KPiA+ID4gPiA+ID4g dGhlIGRhdGFiYXNlLiBUaGVyZSBpcyBubyBuZWVkIGZvciB0aGUgQUFBLU1JUDYgdG8NCj4gPiA+ ID4gPiBhdXRoZW50aWNhdGUgdGhpcw0KPiA+ID4gPiA+ID4gdXNlcm5hbWUgb3IgdG8gYmUgc3Vy ZSB0aGF0IHRoZSB1c2VybmFtZSB3YXMgcHJldmlvdXNseQ0KPiA+ID4gPiA+IGF1dGhlbnRpY2F0 ZWQuDQo+ID4gPiA+ID4gPiBUaGUgY2xpZW50IG9mIHRoZSBkYXRhYmFzZSBpcyB0aGUgSEEgYW5k IG5vdCB0aGUgdXNlci4gSW4NCj4gPiA+ID4gPiB0aGF0IGNhc2UsDQo+ID4gPiA+ID4gPiB0aGUN Cj4gPiA+ID4gPiA+IEFBQS1NSVA2IGhhcyB0byB0cnVzdCB0aGUgSEEgYW5kIGl0IGlzIHVwIHRv IHRoZSBIQSB0bw0KPiA+ID4gPiBhdXRoZW50aWNhdGUNCj4gPiA+ID4gPiA+IHRoZSB1c2VybmFt ZSBwcm92aWRlZCBieSB0aGUgbW4gZHVyaW5nIHRoZSBTQSBzZXQtdXAuDQo+ID4gPiA+IFRoaXMg Y291bGQgYmUNCj4gPiA+ID4gPiA+IGNvbXBhcmVkIHRvIGludGVyZmFjZXMgYmV0d2VlbiBIU1Mg KEhvbWUgU3Vic2NyaWJlcg0KPiA+ID4gPiBTZXJ2ZXIpIGFuZCBTSVANCj4gPiA+ID4gPiA+IGFw cGxpY2F0aW9uIHNlcnZlcnMgZGVmaW5lZCBpbiB0aGUgM0dQUCBhcmNoaXRlY3R1cmUsDQo+ID4g PiBvdmVyIHdoaWNoDQo+ID4gPiA+ID4gPiBEaWFtZXRlciBhcHBsaWNhdGlvbnMgYXJlIHVzZWQg dG8gYWNjZXNzIGRhdGFiYXNlLg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBJbiB0aGlz IGNvbnRleHQsIHRoZSBIQSBtYXkgdXNlOg0KPiA+ID4gPiA+ID4gPiAxKSB0aGUgRGlhbWV0ZXIg RUFQIGFwcGxpY2F0aW9uIHRvIGF1dGhlbnRpY2F0ZSB0aGUgdXNlci4NCj4gPiA+ID4gPiA+ID4g MikgdGhlIERpYW1ldGVyIE1JUDYgYXBwbGljYXRpb24gdG8gZG93bmxvYWQgdXNlcg0KPiA+ID4g PiByZWxhdGVkIHNlcnZpY2UNCj4gPiA+ID4gPiA+ID4gaW5mb3JtYXRpb24gQXV0aGVudGljYXRp b24gYW5kIGF1dGhvcml6YXRpb24gYXJlIHBlcmZvcm1lZA0KPiA+ID4gPiA+ID4gYnkgdGhlIEFB QS1FQVAuIEJ1dCB0aGVyZSBpcyBubyB3YXkgZm9yIHRoZSBBQUEtRUFQIHRvDQo+ID4gPiA+IGtu b3cgd2hhdCBpcw0KPiA+ID4gPiA+ID4gdGhlIHNlcnZpY2UgcmVxdWVzdGVkIGJ5IHRoZSB1c2Vy LiBTdWNjZXNzZnVsDQo+ID4gPiA+ID4gYXV0aGVudGljYXRpb24gaW1wbGllcw0KPiA+ID4gPiA+ ID4gaW1wbGljdGUgYXV0aG9yaXphdGlvbi4gVGhpcyBpcyB0aGUgcHJvYmxlbSB3aXRoIERpYW1l dGVyDQo+ID4gPiA+ID4gRUFQIGFzIGl0IGlzDQo+ID4gPiA+ID4gPiBub3QgcG9zc2libGUgdG8g cm91dGUgRGlhbWV0ZXIgRUFQIHJlcXVlc3QgdG8gYQ0KPiA+ID4gPiA+IHNlcnZpY2Utc3BlY2lm aWMgRUFQDQo+ID4gPiA+ID4gPiBzZXJ2ZXIuDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gSWYg QUFBLU1JUDYgcHJvdmlkZXMgYXV0aG9yaXphdGluLCBBQUEtRUFQIHByb3ZpZGVzDQo+ID4gPiA+ IGF1dGhlbnRpY2F0aW9uLA0KPiA+ID4gPiA+ID4gYnV0IGRvZXMgbm90IHByb3ZpZGUgYXV0aG9y aXphdGlvbi4gIEZvciB0aGlzIHB1cnBvc2UsIHRoZQ0KPiA+ID4gPiA+IEhBIG5lZWRzIHRvDQo+ ID4gPiA+ID4gPiBzZXQgQXV0aC1SZXF1ZXN0LVR5cGUgc2V0IHRvIEFVVEhFTlRJQ0FURV9PTkxZ IGluDQo+ID4gPiA+IEFBQS1FQVAuICBJbiB0aGlzDQo+ID4gPiA+ID4gPiBjYXNlLCBBQUEtRUFQ IHNlcnZlciBkb2VzIG5vdCBuZWVkIHRvIGtub3cgd2hhdCBraW5kIG9mDQo+ID4gPiA+ID4gYXV0 aG9yaXphdGlvbg0KPiA+ID4gPiA+ID4gd2lsbCBiZSBtYWRlLiAgVGhlIGF1dGhvcml6YXRpb24g ZGVjaXNpb24gd2lsbCBiZSBtYWRlIGJ5DQo+ID4gPiA+IEFBQS1NSVA2Lg0KPiA+ID4gPiA+ID4g QW0gSSBtaXNzaW5nIHNvbWV0aGluZz8NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+DQo+ID4g PiA+ID4gPiA+IEluIGFub3RoZXIgaGFuZCwgaWYgdGhlIEFBQS1NSVA2IGlzIGFuIGF1dGhvcml0 eSBoYW5kbGluZw0KPiA+ID4gPiA+ID4gTUlQNiBzZXJ2aWNlIGFjY2VzcyBhdXRob3JpemF0aW9u IHJpZ2h0cyBpLmUuIHRoZSBBQUEtTUlQNg0KPiA+ID4gPiA+IG11c3QgdmVyaWZ5DQo+ID4gPiA+ ID4gPiB0aGF0IHRoZSB1c2VyIGlzIGF1dGhvcml6ZWQgdG8gdXNlIHRoZSBNb2JpbGUNCj4gPiA+ ID4gPiA+IElQdjYgc2VydmljZSwgdGhpcyBhdXRob3JpdHkgaGFzIHRvIGJlIGFibGUgdG8gdmVy aWZ5IHRoZQ0KPiA+ID4gPiA+IGlkZW50aXR5IG9mDQo+ID4gPiA+ID4gPiB0aGUgdXNlciBiZWZv cmUgYXV0aG9yaXppbmcgdGhpcyB1c2VyIHRvIGFjY2VzcyB0aGUNCj4gPiA+ID4gPiBzZXJ2aWNl LiBJdCBpcyBub3QNCj4gPiA+ID4gPiA+IHBvc3NpYmxlIHRvIGF1dGhvcml6ZSBzb21lb25lIHRv IGRvIHNvbWV0aGluZyB3aXRob3V0DQo+ID4gPiA+IGJlaW5nIHN1cmUgb2YNCj4gPiA+ID4gPiA+ IGl0cyBpZGVudGl0eSBhcyB0aGUgYXV0aG9yaXR5IG11c3Qgc3RhbmQgc3VyZXR5IG9mIHRoZQ0K PiA+ID4gPiB1c2VyIGFjY2Vzcw0KPiA+ID4gPiA+ID4gcmlnaHRzLiBOb3csIGl0IGlzIG5vdCBw b3NzaWJsZSB0byByZWx5IG9uIHRoZSBEaWFtZXRlciBFQVANCj4gPiA+ID4gPiA+IGFwcGxpY2F0 aW9uIHRvIHBlcmZvcm0gdGhlIGF1dGhlbnRpY2F0aW9uIHByb2NlZHVyZSBhcw0KPiA+ID4gPiA+ IHRoZXJlIGlzIG5vIHdheQ0KPiA+ID4gPiA+ID4gdG8gZGlyZWN0IHRoZSBEaWFtZXRlciBFQVAg cmVxdWVzdHMgdG8gYSBzcGVjaWZjIEVBUA0KPiA+ID4gPiBzZXJ2ZXIgKGFzIHRoZQ0KPiA+ID4g PiA+ID4gRGlhbWV0ZXIgcm91dGluZyBpcyBiYXNlZCBvbiBBcHAtSWQgYW5kIFJlYWxtKS4gV2Ug bWlnaHQNCj4gPiA+ID4gPiB0aGluayBhYm91dA0KPiA+ID4gPiA+ID4gc29tZSBzcGVjaWZpYyB0 aGluZ3MgdG8gbGluayBhdXRoZW50aWNhdGlvbiBwcm9jZWR1cmVzIGFuZA0KPiA+ID4gPiA+ID4g YXV0aG9yaXphdGlvbi9zZXJ2aWNlIHByb2ZpbGUgaGFuZGxpbmcuIEJ1dCBmb3IgbWUsIHRoZQ0K PiA+ID4gPiA+IHNpbXBsaWVzdCB3YXkNCj4gPiA+ID4gPiA+IHdvdWxkIGJlIHRvIGRlZmluZSB0 aGUgcmVxdWlyZWQgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtDQo+ID4gPiA+IHdpdGhpbiBvbmUN Cj4gPiA+ID4gPiA+IGFuZCBvbmx5IG9uZSBhcHBsaWNhdGlvbiBpLmUuIHRoZSBhcHBsaWNhdGlv biB0aGF0DQo+ID4gPiByZXF1aXJlcyB0aGlzDQo+ID4gPiA+ID4gPiBhdXRoZW50aWNhdGlvbi4N Cj4gPiA+ID4gPiA+IFRoZXJlZm9yZSwgRGlhbWV0ZXIgRUFQIHdvdWxkIG5vdCBiZSB1c2VkIGFu ZA0KPiA+ID4gPiBhcHBsaWNhdGlvbi1zcGVjaWZpYw0KPiA+ID4gPiA+ID4gY29tbWFuZHMgd291 bGQgYmUgc3BlY2lmaWVkIGluIHRoZSBhcHBsaWNhdGlvbi4gT25lIGNvbW1hbmQNCj4gPiA+ID4g PiBwYWlyIHdvdWxkDQo+ID4gPiA+ID4gPiBiZSBhZGRlZCB0byB0aGUgRGlhbWV0ZXINCj4gPiA+ ID4gPiA+IE1JUDYgYXBwbGljYXRpb24uIEFuZCB0byBzdXBwb3J0IEVBUCwgQVZQcyBkZWZpbmVk IGluIDQwNzINCj4gPiA+ID4gPiB3b3VsZCBiZSBhdA0KPiA+ID4gPiA+ID4gbGVhc3QgKHJlLSl1 c2VkLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IEkgZG9uJ3QgdW5kZXJzdGFuZCB0aGUgZGlm ZmVyZW5jZSBiZXR3ZWVuIHRoZSB0d28gY2FzZXMgeW91DQo+ID4gPiA+ID4gbWVudGlvbmVkDQo+ ID4gPiA+ID4gPiBhYm92ZS4gIEkgYmVsaWV2ZSB0aGF0IG1vcmUgb3IgbGVzcyB0aGUgQUFBIHNl cnZlcnMgbmVlZCB0bw0KPiA+ID4gPiA+IHRydXN0IHRoZQ0KPiA+ID4gPiA+ID4gSEEgaW4gYm90 aCBjYXNlcy4gIERlcGVuZGluZyBvbiB0aHJlYXQgbW9kZWwgd2hpY2ggd2UNCj4gPiA+ID4gZG9u J3Qgc2VlbSB0bw0KPiA+ID4gPiA+ID4gZXhhY3RseSBrbm93IHJpZ2h0IG5vdywgdGhlDQo+ID4g PiA+ID4gPiBBQUEtTUlQNiBzZXJ2ZXIgbWF5IG9yIG1heSBub3QgbmVlZCBhbiBldmlkZW5jZSB0 aGF0IHRoZQ0KPiA+ID4gPiA+IHVzZXIgaGFzIGJlZW4NCj4gPiA+ID4gPiA+IGF1dGhlbnRpY2F0 ZWQgYnkgYSBBQUEtRUFQIHNlcnZlci4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+DQo+ID4g PiA+ID4gPiA+IElNSE8sIHRoZSBjb250ZXh0IGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQgbG9va3Mg bGlrZSBtb3JlIGENCj4gPiA+ID4gPiA+IHNlcnZpY2UgYWNjZXNzIGF1dGhvcml6YXRpb24gbWFu YWdlbWVudCB0aGFuIHRoZSB1c2Ugb2YNCj4gPiA+IGEgc2ltcGxlDQo+ID4gPiA+ID4gPiBleHRl cm5hbCBkYXRhYmFzZS4gSSB3b3VsZCBiZSB0aGVyZWZvcmUgaW4gZmF2b3Igb2YgZGVmaW5pbmcN Cj4gPiA+ID4gPiA+IGF1dGhlbnRpY2F0aW9uIGNvbW1hbmRzIHdpdGhpbiB0aGUgRGlhbWV0ZXIg TUlQNg0KPiA+ID4gPiA+IGFwcGxpY2F0aW9uIGluc3RlYWQNCj4gPiA+ID4gPiA+IG9mIHRyeWlu ZyB0byByZXVzZSB0aGUgRGlhbWV0ZXIgRUFQIGFwcGxpY2F0aW9uLCB3aGljaCBpcw0KPiA+ID4g PiA+IG5vdCBwb3NzaWJsZQ0KPiA+ID4gPiA+ID4gd2l0aG91dCBtb2RpZmljYXRpb25zLiBFQVAg YXV0aGVudGljYXRpb24gYW5kIE1JUDYNCj4gPiA+IHNlcnZpY2UgYWNjZXNzDQo+ID4gPiA+ID4g PiBhdXRob3JpemF0aW9uIGFyZSBwZXJmb3JtZWQgd2l0aCB0aGUgc2FtZQ0KPiA+IGFwcGxpY2F0 aW9uLiBTaW5jZSBhDQo+ID4gPiA+ID4gPiBhcHBsaWNhdGlvbi1JZCBpcyB3aGF0ZXZlciBuZWVk ZWQgZm9yIHRoZSBIQS9BQUEtTUlQNiwgd2hhdA0KPiA+ID4gPiA+IHdvdWxkIGJlDQo+ID4gPiA+ ID4gPiB0aGUgYmVuZWZpdCB0byBsb29rIGZvciBzb2x1dGlvbnMgYmluZGluZyBEaWFtZXRlciBF QVANCj4gPiA+ID4gYW5kIERpYW1ldGVyDQo+ID4gPiA+ID4gPiBNSVA2ICh3aXRoIHNvbWUga2V5 IGRlcml2YXRpb24sIGV0Yy4pIHdoaWxlIGEgc2luZ2xlDQo+ID4gPiA+IERpYW1ldGVyIE1JUDYN Cj4gPiA+ID4gPiA+IGFwcGxpY2F0aW9uIHdpdGggaW50cmluc2ljIGF1dGhlbnRpY2F0aW9uIGNv bW1hbmRzDQo+ID4gPiB3b3VsZCBiZSBmdWxseQ0KPiA+ID4gPiA+ID4gYXBwcm9wcmlhdGU/DQo+ ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gSSBkb24ndCB1bmRlcnN0YW5kIHdoYXQgaXMgdGhlIHBv aW50IG9mIGRpc2N1c3NpbmcNCj4gPiA+ID4gInNlcnZpY2UgYWNjZXNzDQo+ID4gPiA+ID4gPiBh dXRob3JpemF0aW9uIG1hbmFnZW1lbnQiIGFuZCAic2ltcGxlIGV4dGVybmFsIGRhdGFiYXNlIi4N Cj4gPiA+ID4gIElmIE1JUDYNCj4gPiA+ID4gPiA+IGFwcGxpY2F0aW9uIG5lZWRzIHRvIHN1cHBv cnQgbXVsdGlwbGUgYXV0aGVudGljYXRpb24NCj4gPiA+ID4gPiBtZXRob2RzIHN1Y2ggYXMNCj4g PiA+ID4gPiA+IEVBUCBhbmQgUkZDIDQyODUsIEkgYmVsaWV2ZSBpdCBpcyBtb3JlIGFwcHJvcHJp YXRlIHRvDQo+ID4gY29uc2lkZXINCj4gPiA+ID4gPiA+IHNlcGFyYXRpb24gb2YgYXV0aGVudGlj YXRpb24gYW5kIGF1dGhvcml6YXRpb24gaWYgc2VjdXJpdHkgaXMNCj4gPiA+ID4gPiA+IHJlYXNv bmFibHkgaGFuZGxlZC4gIEFsc28sIHRoZXJlIGlzIHNvbWUgYXV0aGVudGljYXRpb24NCj4gPiA+ ID4gPiBtZXRob2QgKGUuZy4sDQo+ID4gPiA+ID4gPiBhdXRoZW50aWNhdGlvbiBiYXNlZCBvbiBJ S0V2Mi1jZXJ0IHdpdGhvdXQgdXNpbmcgRUFQKSBkb2VzDQo+ID4gPiA+ID4gbm90IHJlcXVpcmUN Cj4gPiA+ID4gPiA+IGFueSBBQUEgaW50ZXJhY2F0aW9uIGZvciBhdXRoZW50aWNhdGlvbi4gIEkg d2FzDQo+ID4gPiBwb2ludGluZyB0aGlzIG91dA0KPiA+ID4gPiA+ID4gc2V2ZXJhbCB0aW1lcyBi dXQgbm8gb25lIHNlZW1zIHRvIHBheSBhdHRlbnRpb24gdG8gaXQuDQo+ID4gPiA+ID4gPg0KPiA+ ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBJJ20gcHJldHR5IHN1cmUgdGhhdCB0aGUgY29udGVu dCBvZiB0aGlzIG1haWwgbWF5IGJlDQo+ID4gPiA+ID4gPiBjaGFsbGVuZ2VkIGxpbmUgYnkgbGlu ZSA7KSBCdXQgYXQgdGhlIGVuZCwgaWYNCj4gPiA+IGF1dGhlbnRpY2F0aW9uIGFuZA0KPiA+ID4g PiA+ID4gYXV0aG9yaXphdGlvbiBhcmUgbmVlZGVkIHRvIHByb3ZpZGUgTUlQNiBzZXJ2aWNlcywg d2h5IGRvDQo+ID4gPiA+ID4gbm90IGhhdmluZyBhDQo+ID4gPiA+ID4gPiBzaW5nbGUgYXBwbGlj YXRpb24gdG8gZG8gaXQ/IE9mIGNvdXJzZSwgSSBkb24ndCBzYXkgdGhhdCBpdA0KPiA+ID4gPiA+ IHdvdWxkIG5vdA0KPiA+ID4gPiA+ID4gYmUgcG9zc2libGUgdG8gZG8gc29tZXRoaW5nIG1vcmUg Y29tcGxleC4uLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IFRvIG1lLCBkaXNjdXNzaW9uIG9u IGNvdXBsaW5nIHZzLiBkZWNvdXBsaW5nDQo+ID4gYXV0aGVudGljYXRpb24gYW5kDQo+ID4gPiA+ ID4gPiBhdXRob3JpemF0aW9uIGlzIG5vdCBqdXN0IGEgTUlQNiBpc3N1ZS4gIFRoaXMgaXMgYQ0K PiA+IGZ1bmRhbWVudGFsDQo+ID4gPiA+ID4gPiBkaXNjdXNzaW9uIHRoYXQgd2lsbCBkZWNpZGUg dGhlIGZ1dHVyZSBkaXJlY3Rpb24gb2YgQUFBLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IFlv c2hpaGlybyBPaGJhDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBC UiwNCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gTGlvbmVsDQo+ID4gPiA+ID4gPiA+DQo+ ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0t DQo+ID4gPiA+ID4gPiA+ID4gRGUgOiBKdWxpZW4gTGFnYW5pZXIgW21haWx0bzpqdWxpZW4uSUVU RkBsYXBvc3RlLm5ldF0NCj4gPiA+ID4gPiA+ID4gPiBFbnZvee+8nyA6IG1hcmRpIDIzIGphbnZp ZXIgMjAwNyAxMDo0Mg0KPiA+ID4gPiA+ID4gPiA+IO+8nyA6IEFobWFkIE11aGFubmENCj4gPiA+ ID4gPiA+ID4gPiBDYyA6IGRpbWVAaWV0Zi5vcmcNCj4gPiA+ID4gPiA+ID4gPiBPYmpldCA6IFJl OiBbRGltZV0gRGlhbWV0ZXIgTW9iaWxlIElQdjYNCj4gPiBIQS10by1BQUFIIFN1cHBvcnQ6DQo+ ID4gPiA+ID4gPiA+ID4gSXNzdWUgb3Igbm90SXNzdWUgPw0KPiA+ID4gPiA+ID4gPiA+DQo+ID4g PiA+ID4gPiA+ID4gSGkgQWhtYWQsDQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiBD dXR0aW5nIGEgYml0IHRocnUgeW91ciBtZXNzYWdlLCBJIGhhdmUgc29tZSBjb21tZW50cw0KPiA+ ID4gPiA+ID4gPiA+IGJlbG93Og0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gT24g TW9uZGF5IDIyIEphbnVhcnkgMjAwNyAxODoxMCwgQWhtYWQgTXVoYW5uYSB3cm90ZToNCj4gPiA+ ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID5bLi4uXQ0K PiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+IFtBaG1hZF0NCj4gPiA+ID4gPiA+ ID4gPiA+IFdlIGFyZSBwcm9iYWJseSBzcGxpdHRpbmcgaGFpciBoZXJlLCBhcHBhcmVudGx5DQo+ ID4gPiA+IHRoZXJlIGFyZSB0d28NCj4gPiA+ID4gPiA+ID4gPiA+IGFyZ3VtZW50cyBoZXJlOg0K PiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gSSBkb24ndCB0aGluayB0aGlzIGlzIGhh aXIgc3BsaXR0aW5nLiBVbmRlcnN0YW5kIHRoZQ0KPiA+ID4gPiA+ID4gaXNzdWUgc2hvdWxkIGJl DQo+ID4gPiA+ID4gPiA+ID4gYSBwcmVyZXF1aXNpdGUgdG8gc29sdmluZyBpdC4NCj4gPiA+ID4g PiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4gMS4gQUFBeiBpcyBhbiBhdXRob3JpemF0aW9uIHNl cnZlciBhbmQgc2luY2UgaXQgaGFzIGENCj4gPiA+ID4gPiBzZWN1cml0eQ0KPiA+ID4gPiA+ID4g PiA+ID4gcmVsYXRpb25zaGlwIHdpdGggdGhlIEhBLCBBQUF6IHJlbGllcyBvbiB0aGUgSEENCj4g PiB0byBkbyB0d28NCj4gPiA+ID4gPiA+ID4gPiB0aGluZ3M6IDEuMS4NCj4gPiA+ID4gPiA+ID4g PiA+IEhBIG1ha2VzIHN1cmUgdGhhdCB0aGUgdXNlciBoYXMgYmVlbiBhdXRoZW50aWNhdGVkIGJ5 DQo+ID4gPiA+ID4gPiBBQUFuLiAxLjIuDQo+ID4gPiA+ID4gPiA+ID4gPiBIQSB3aWxsIG5vdCBz ZW5kIGFueSBBdXRob3JpemF0aW9uIHJlcXVlc3RzIGZvcg0KPiA+ID4gYW55IHVzZXIocykNCj4g PiA+ID4gPiA+ID4gPiB3aG8gaGFzIG5vdA0KPiA+ID4gPiA+ID4gPiA+ID4gYmVlbiBhdXRoZW50 aWNhdGVkLg0KPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+IChJbiBub3JtYWwg Y29uZGl0aW9ucywgdGhlIGFib3ZlIHR3byBjb25kaXRpb25zDQo+ID4gYXJlIEFMV0FZUw0KPiA+ ID4gPiA+ID4gPiA+IFRSVUUgZXhjZXB0DQo+ID4gPiA+ID4gPiA+ID4gPiBpbiBvbmUgY29uZGl0 aW9uLCBIQSBoYXMgYmVlbg0KPiA+ID4gPiA+ID4gPiA+ID4gY29tcHJvbWlzZWQpDQo+ID4gPiA+ ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiBSaWdodC4gU28gd2UgYm90aCBhZ3JlZSB0aGVyZSdz IG5vIHByb2JsZW0gdW5sZXNzDQo+ID4gdGhlIEhBIGlzDQo+ID4gPiA+ID4gPiA+ID4gY29tcHJv bWlzZWQNCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+IEkgdGhpbmsgd2hhdCB0aGUg Zmlyc3Qgc3RlcCBpcyB0byBhZ3JlZSBvbiBhIHRocmVhdA0KPiA+ID4gPiA+ID4gbW9kZWwuIEkg ZG8gbm90DQo+ID4gPiA+ID4gPiA+ID4gYWdyZWUgdGhhdCB3ZSBzaG91bGQgZGVmZW5kIGFnYWlu c3QgYSBjb21wcm9taXNlZCBIQS4NCj4gPiA+ID4gPiA+ID4gPiBUaGUgSEEgc2hvdWxkIGJlIGRl ZW1lZCBzZWN1cmUgYWdhaW5zdCBhdHRhY2tlcnMuDQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4g PiA+ID4gPiBXZSBoYXZlIHRvIHBsYWNlIGEgbGltaXQgb24gd2hhdCBpcyBlbnRpdHkgWCB3aGVu DQo+ID4gPiBhc2tpbmcgdGhlDQo+ID4gPiA+ID4gPiA+ID4gcXVlc3Rpb24gIndoYXQgaWYgZW50 aXR5IFggaXMgY29tcHJvbWlzZWQiLg0KPiA+ID4gPiA+ID4gPiA+IFNpbmNlIG5vdGhpbmcgaXMg cmVhbGx5IGltcG9zc2libGUgaW4gdGhlIHJlYWwgd29ybGQsDQo+ID4gPiA+IHdlIGNhbm5vdA0K PiA+ID4gPiA+ID4gPiA+IGRlZmVuZCBhZ2FpbnN0IGNvbXByb21pc3Npb24gb2YgYW55IGVudGl0 eSBpbXBsaWNhdGVkIGluDQo+ID4gPiA+ID4gPiBhIHByb3RvY29sLg0KPiA+ID4gPiA+ID4gPiA+ IFNlY3VyaXR5IGlzIGEgdHJhZGVvZmYuDQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4g PiBNb3JlIGJlbG93Li4uDQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+IDIuIEFB QXogaXMgYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIGhhcyBhIHNlY3VyaXR5DQo+ID4gPiA+ ID4gPiA+ID4gYXNzb2NpYXRpb24gd2l0aA0KPiA+ID4gPiA+ID4gPiA+ID4gdGhlIEhBLCBob3dl dmVyLCBkdWUgdG8gdGhlIGZhY3QgdGhhdCB0aGUgSEEgY291bGQgYmUNCj4gPiA+ID4gPiA+ID4g PiBjb21wcm9taXNlZCwgYQ0KPiA+ID4gPiA+ID4gPiA+ID4gcHJvY2VzcyBuZWVkcyB0byBiZSBp biBwbGFjZSBmb3IgdGhlIEhBIHRvIEFMV0FZUw0KPiA+ID4gPiBwcm92aWRlIHRoZQ0KPiA+ID4g PiA+ID4gPiA+ID4gQUFBeiwgQXV0aG9yaXphdGlvbiBzZXJ2ZXIsIHdpdGggYSBwcm9vZiAodG9r ZW4sDQo+ID4gPiA+ID4gPiA+ID4gPiBldGMuKSB0aGF0IHRoZSB1c2VyIGhhcyBiZWVuIGF1dGhl bnRpY2F0ZWQgYnkgQUFBbi4NCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+IE9LLCBp ZiBIQSBjYW4gYmUgY29tcHJvbWlzZWQuIEJ1dCB3aHkgYXJlIHdlDQo+ID4gc3RvcHBpbmcgaGVy ZT8NCj4gPiA+ID4gPiA+ID4gPiBXaHkgbm90IGNvbnNpZGVyaW5nIHRoZSBjYXNlIHdoZXJlIHRo ZSBBQUFuIGlzDQo+ID4gY29tcHJvbWlzZWQ/DQo+ID4gPiA+ID4gPiA+ID4gSXMgaXMgaXQgbW9y ZSBsaWtlbHkgZm9yIGFuIEhBIHRvIGJlIGNvbXByb21pc2VkIHRoYW4NCj4gPiA+ID4gPiBmb3Ig YSBBQUFuPw0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gV2UgcmVhbGx5IGhhdmUg dG8gYWdyZWUgb24gYSB0aHJlYXQgbW9kZWwgZmlyc3QuDQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ ID4gPiA+ID4gPiA+IEkgYXNzdW1lIGhlcmUgdGhhdCB0aGUgZGlmZmVyZW5jZSBpbiBvcGluaW9u IGlzDQo+ID4gYWJvdXQgdGhlDQo+ID4gPiA+ID4gPiA+ID4gcG9zc2liaWxpdHkNCj4gPiA+ID4g PiA+ID4gPiA+IG9mIHRoZSBIQSB0byBiZSBjb21wcm9taXNlZCBvciBOT1QuDQo+ID4gPiA+ID4g PiA+ID4NCj4gPiA+ID4gPiA+ID4gPiBFeGFjdGx5Lg0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ ID4gPiA+ID4gQmVzdCwNCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+IC0tanVsaWVu IChMLikNCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+ID4gPiA+ID4gRGlNRSBtYWls aW5nIGxpc3QNCj4gPiA+ID4gPiA+ID4gPiBEaU1FQGlldGYub3JnDQo+ID4gPiA+ID4gPiA+ID4g aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0KPiA+ID4gPiA+ID4g PiA+DQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gPiA+ID4g RGlNRSBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gPiA+ID4gRGlNRUBpZXRmLm9yZw0KPiA+ID4gPiA+ ID4gPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQo+ID4gPiA+ ID4gPiA+DQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+DQo+ ID4gPg0KPiA+DQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IERpTUUgbWFpbGluZyBsaXN0DQo+IERpTUVAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0K --===============1949629511== 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 --===============1949629511==--